desenvolvimento de um data warehouse para o processo de
TRANSCRIPT
FÁBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO
Desenvolvimento de um data warehouse para o processo de decisão em uma empresa de telecomunicações
São Paulo 2009
2
FÁBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO
Desenvolvimento de um data warehouse para o processo de decisão em uma empresa de telecomunicações
Monografia apresentada à Escola Politécnica da Universidade de São Paulo para Conclusão do Curso de
Engenharia de Computação
Orientador: Prof. Dr. Jorge Rady de Almeida Jr.
São Paulo 2009
3
4
5
FÁBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO
Desenvolvimento de um data warehouse para o processo de decisão em uma empresa de telecomunicações
Monografia apresentada à Escola Politécnica da Universidade de São Paulo para Conclusão do Curso de
Engenharia de Computação
São Paulo 2009
6
ERRATA
PÁGINA LINHA ONDE SE LÊ LEIA-SE
7
DEDICATÓRIA
A todas as pessoas que nos ajudaram diretamente ou indiretamente na
realização deste trabalho.
8
AGRADECIMENTOS
Prof. Dr. Jorge Rady de Almeida Jr., pela orientação durante todo o
desenvolvimento do trabalho, e também pela compreensão nas fases onde a
dedicação ao trabalho não pode ser grande.
Toda a equipe da empresa In.voice que esteve envolvida com o sistema, por
disponibilizarem as informações necessárias e por se colocarem a disposição para
ajudar.
Raphael Mielle Trintinalia e Vitor Araujo Romera, por aceitarem liberar um
integrante da equipe para que este trabalho pudesse ser realizado.
Deus, por ter evitado que meu laptop fosse roubado com grande parte da
monografia.
9
10
11
RESUMO
O sistema baseado em data warehouse desenvolvido tem por objetivo auxiliar
a solução de problemas da empresa In.voice, a empresa cliente deste projeto. O
grande problema abordado diz respeito à manipulação de uma grande quantidade
de dados e, conseqüentemente a perda de eficiência na geração de relatórios que
utilizam bases de dados tradicionais. O uso de um data warehouse é uma das
possíveis soluções para reduzir o tempo de resposta do sistema e apresentar as
informações de maneira mais fácil de ser visualizada, assim, este trabalho propõe a
modelagem e desenvolvimento da solução baseada em data warehouse para a
empresa em questão.
O trabalho desenvolvido foi realizado e documentado por etapas com a
finalidade de facilitar futuros trabalhos que tenham por objetivo desenvolver sistemas
baseados em data warehouse.
12
ABSTRACT
The data warehouse system developed aims to solve real problems of
In.voice, a company considered the client of this project. The main problem analyzed
was about the great amount of data managed by usual relational database systems
that took a long time to generate reports. The data warehouse technology seemed to
be one of the possible solutions for this kind of problem, aiming the quality of
information provided by data and response time of the entire system. This work
proposes to model and develop the data warehouse solution for In.voice company.
The development was made and wrote by steps, so future articles that aim to
implement data warehouse systems will find this document useful.
13
LISTA DE ILUSTRAÇÕES
Figura 1 - Modelo Estrela Genérico ........................................................................... 27
Figura 2 - Interface de usuário do pgAdminIII ........................................................... 32
Figura 3 - Interface de Usuário do Pentaho Data Integration .................................... 33
Figura 4 - Interface de usuário do jPivot, acessando o serviço OLAP do Mondrian .. 35
Figura 5 - Interface de usuário do Schema Workbench ............................................ 36
Figura 6 - Interface de usuário do Pentaho BI Studio ................................................ 37
Figura 7 – Modelo dimensional modelado ................................................................. 41
Figura 8 - Modelo básico de ETL de carga de dimensões ........................................ 44
Figura 9 - Modelos de ETL de carga de tabelas-fato (a) série; (b) paralelo .............. 46
Figura 10 – Modelo Multidimensional no Schema Workbench. ................................. 47
Figura 11 - Hierarquia de tempo definida .................................................................. 49
Figura 12 - Diversos fluxos de carga das dimensões ................................................ 50
Figura 13 - ETL da Tabela fato_registro .................................................................... 51
Figura 14 – Tela de boas vindas do sistema web Pentaho BI Studio. ....................... 53
Figura 15 – Tela de entrada no sistema. ................................................................... 54
Figura 16 – Controle de logins e políticas de segurança. .......................................... 55
Figura 17 – Execução da ETL de carga de dimensões através da interface de
usuário. ..................................................................................................................... 56
Figura 18 – Execução da ETL de Fato através da ferramenta Pentaho Data
Integration. ................................................................................................................ 57
Figura 19 – Análise de dados armazenados no data warehouse. ............................. 58
Figura 20 – Saída típica de análise de performance após execução de ETL pelo
Pentaho Data Integration .......................................................................................... 59
14
LISTA DE TABELAS
Tabela 1 - Especificação dos atributos da entidade Fato - Registro ......................... 42
Tabela 2 – Variáveis de desempenho e resultados obtidos. ..................................... 60
15
LISTA DE ABREVIATURAS E SIGLAS
ACID: Atomicity, Consistency, Isolation, Durability
ETL: Extract Transform Load
OLAP: Online Analytical Processing
OLTP: Online Transaction Processing
SGBD: Sistema de Gerenciamento de Banco de Dados
SQL: Structured Query Language
DW: Data Warehouse
OP: Operational System (Ambiente Operacional)
16
SUMÁRIO
1. Introdução ........................................................................................................... 19
1.1 Objetivo ........................................................................................................ 19
1.2 Motivação ..................................................................................................... 19
1.3 Justificativa ................................................................................................... 19
1.4 Metodologia de trabalho ............................................................................... 20
1.5 Estrutura de trabalho .................................................................................... 21
1.6 Restrições .................................................................................................... 22
2 Conceitos ............................................................................................................ 23
2.1 Ambiente Operacional .................................................................................. 23
2.1.1 Modelo ACID ......................................................................................... 23
2.1.2 Processamento de transação on-line .................................................... 24
2.2 Sistemas de Tomada de Decisão ................................................................ 24
2.2.1 Processamento analítico on-line ............................................................ 25
2.3 Data warehouse ........................................................................................... 25
2.3.1 Modelo Estrela ....................................................................................... 27
2.4 Siglas, Termos e Definições ......................................................................... 27
3 Aplicação ............................................................................................................ 30
3.1 Descrição do problema ................................................................................ 30
3.2 Idéia para resolução ..................................................................................... 30
3.2.1 Ferramentas .......................................................................................... 31
4 Etapas do projeto ................................................................................................ 38
4.1 Primeiros Passos ......................................................................................... 38
4.2 Análise do banco de dados operacional....................................................... 38
17
4.3 Especificação de Requisitos ........................................................................ 39
4.3.1 Modelagem do banco de dados dimensional ........................................ 40
4.3.2 Extração, Transformação e Carga ......................................................... 43
4.3.3 Desenvolvimento da base multidimensional (Data warehouse) ............ 46
4.4 Desenvolvimento das ETLs .......................................................................... 49
4.5 Desenvolvimento do Data warehouse .......................................................... 52
5 Resultados .......................................................................................................... 53
5.1 Interfaces de usuário .................................................................................... 53
5.1.1 Interface de usuário de carga de dados ................................................ 55
5.1.2 Interface de usuário de análise de dados e relatórios ........................... 57
5.2 Testes .......................................................................................................... 58
5.2.1 Teste das ETLs ...................................................................................... 59
5.2.2 Teste do data warehouse ...................................................................... 59
5.3 Desempenho ................................................................................................ 59
6 Considerações finais........................................................................................... 61
6.1 Conclusões .................................................................................................. 61
6.2 Contribuições ............................................................................................... 61
6.3 Trabalhos futuros ......................................................................................... 62
7 Referências Bibliográficas .................................................................................. 63
8 Anexos ................................................................................................................ 65
8.1 Anexo I ......................................................................................................... 65
8.2 Anexo II ........................................................................................................ 67
8.2.1 Anexo II.a - Tabela Dimensão Cliente ................................................... 67
8.2.2 Anexo II.b - Tabela Dimensão Operadora ............................................. 68
8.2.3 Anexo II.c - Tabela Dimensão Inventario ............................................... 69
8.2.4 Anexo II.d - Tabela Dimensão Tempo ................................................... 70
8.2.5 Anexo II.e - Tabela Dimensão Tipo de Serviço ..................................... 71
18
8.2.6 Anexo II.f - Tabela Dimensão Centro de Custo ..................................... 72
8.2.7 Anexo II.g - Tabela Dimensão Unidade de Negocio .............................. 73
8.2.8 Anexo II.h - Tabela Dimensão Entidade ................................................ 74
8.2.9 Anexo II.i - Tabela Dimensão Contas .................................................... 75
8.2.10 Anexo II.j – Tabela Dimensão Fatura ................................................. 76
8.3 Anexo III ....................................................................................................... 77
19
1. Introdução
1.1 Objetivo
Este trabalho de formatura tem como objetivo modelar e criar um sistema
baseado em um data warehouse, para auxiliar no processo de decisão de uma
empresa de gestão em telecomunicações.
O sistema, desenvolvido com o fornecimento de dados da empresa In.voice,
utiliza dados de um banco de dados relacional já existente, transforma esses dados,
armazena em um data warehouse e fornece informações relevantes por meio de
relatórios.
1.2 Motivação
Um dos ativos mais importantes das empresas é a informação (INMON &
HACKATHORN, 1994), e, o principal motivo que leva uma empresa a investir tempo
e dinheiro em um data warehouse, é o ambiente competitivo. A fim de se destacar
no mercado, é preciso diferenciação, sendo que o data warehouse leva esse
benefício à empresa, pois permite que dados dos sistemas que estão em operação
em uma empresa sejam coletados e armazenados no decorrer do tempo, para então
serem analisados pelos tomadores de decisão/steakholders de uma empresa. A
aplicação em telecomunicação se torna interessante ao passo que o volume,
granularidade e complexidade de dados neste setor são muito grandes quando se
procura registrar todos os eventos telefônicos de uma determinada região por menor
que seja.
Atualmente, os sistemas baseados em data warehouse não são estudados
em cursos comuns de graduação em engenharia de computação, e, além disso, no
meio empresarial, muitas empresas ainda utilizam soluções proprietárias.
1.3 Justificativa
As justificativas para a realização do trabalho são: a aplicabilidade prática do
sistema; a ampliação de conhecimento para criação de alternativas para sistemas de
20
tomada de decisões, baseadas em software de código aberto; além do aprendizado
devido à utilização de ferramentas não conhecidas por parte do grupo.
A possibilidade de utilizar software de código aberto em um sistema de data
warehouse permite que o conhecimento na área de Business Intelligence possa se
difundir, além de criar uma alternativa de baixo custo para empresas que necessitam
de um sistema de tomada de decisões.
O aprendizado dos conceitos teóricos da construção de um data warehouse
realiza-se com maior facilidade quando os estudos são acompanhados de uma
aplicação prática de tais conceitos (KIMBALL & ROSS, 2002). Portanto, pode-se
dizer que a aplicação deste trabalho objetiva a construção de um data warehouse
para uma empresa que atua no setor de gestão em telecomunicações, a qual provê
serviços para outras empresas que procuram organizar seus gastos com telefonia de
forma transparente e eficiente, obtendo, assim controle sobre os gastos dos diversos
setores dentro da empresa.
Regras de negócio da empresa no que diz respeito à gestão em
telecomunicações são baseadas nos registros das faturas de operadoras. Desta
forma, o uso de data warehouse para o armazenamento desses dados representaria
uma forma eficiente de armazenamento e extração de relatórios, uma vez que o
volume de dados é muito grande – da ordem de 40 milhões de registros mensais – e
há necessidade de processamento destes dados para a geração de relatórios que
auxiliam o entendimento e análise dos gastos em telecomunicações das empresas
que contratam o serviço.
1.4 Metodologia de trabalho
A metodologia de desenvolvimento do sistema é constituída das seguintes
etapas:
� Estudo dos conceitos e ferramentas disponíveis: Consiste principalmente
do estudo da teoria de data warehouse, analisando as aplicações, os
pontos positivos e negativos, e estudo das ferramentas de código aberto
disponíveis para apoiar a criação de um sistema baseado em data
warehouse.
21
� Análise do Banco de Dados Operacional (Relacional): Análise do banco de
dados relacional da empresa cliente, levantando os principais dados alvos
do projeto.
� Elaboração dos requisitos: Levantamento dos principais requisitos do
sistema, de forma a delimitar o escopo e estabelecer a meta a ser
alcançada com o sistema.
� Modelagem do banco de dados dimensional: Criação do modelo do banco
de dados dimensional, com o objetivo de alterar a modelagem dos dados
para a migração para o data warehouse.
� Carga de dados do ambiente operacional: Transporte de dados originários
do ambiente operacional para a base dimensional de dados. Esta carga é
realizada através de rotinas denominadas ETL – Extract, Transform and
Load (conforme é definido na seção 2.4).
� Criação do data warehouse: Modelagem do Data warehouse utilizando a
ferramenta Mondrian e o modelo dimensional como base.
� Geração de relatórios: Compreende a modelagem de formas de se obter
das informações e apresentação das mesmas para os usuários do
sistema.
Os documentos de andamento e a monografia foram elaborados
paralelamente às etapas descritas, bem como reuniões com a empresa cliente.
1.5 Estrutura de trabalho
O capítulo 1 contém uma introdução ao trabalho de conclusão de curso,
apresentando o objetivo, motivações, justificativas, a metodologia, a estrutura e as
restrições do trabalho.
No capítulo 2 são abordados os conceitos mais importantes que embasam o
trabalho.
O capítulo 3 contém a descrição do problema, e o raciocínio para a resolução
do mesmo, bem como as ferramentas utilizadas.
No capítulo 4 são abordadas, de forma seqüencial, todas as atividades
desenvolvidas desde o início do projeto até sua conclusão.
22
No capítulo 5 são apresentados os resultados obtidos com o sistema
desenvolvido, e os testes realizados.
O capítulo 6 contém as conclusões, contribuições e trabalhos futuros
relacionados ao projeto.
1.6 Restrições
As restrições impostas inicialmente foram relativas às ferramentas a serem
utilizadas.
A fim de desenvolver a capacidade de buscar conhecimento de novas
tecnologias, uma das restrições foi a utilização de ferramentas de código aberto para
a realização do trabalho.
O projeto também teve como restrição a utilização de um banco de dados
relacional específico, uma vez que a empresa cliente mantinha sua base de dados
com essa ferramenta. Portanto, em toda a parte de banco de dados relacional, foi
utilizado o sistema gerenciador de banco de dados PostgreSQL.
23
2 Conceitos
Este capítulo contém os elementos teóricos essenciais que envolvem um
sistema baseado em data warehouse.
2.1 Ambiente Operacional
O ambiente operacional – também conhecido como ambiente transacional – é
o ambiente necessário para o funcionamento do dia-a-dia da empresa (KIMBALL &
ROSS, 2002), normalmente composto por sistemas que operam sobre massas de
dados através de operações transacionais (definidas na seção Processamento de
transação on-line - item 2.1.2). É neste ambiente que as operações de domínio da
empresa acontecem com foco em controle de processos de negócio.
Devido à alta taxa de modificações de dados, este ambiente é otimizado para
este tipo de tarefa, e normalmente a base do ambiente operacional é um banco de
dados relacional, cujos dados são inseridos, alterados, consultados ou removidos.
2.1.1 Modelo ACID
As preocupações mais relevantes do ambiente operacional podem ser
resumidas nas propriedades ACID (sigla inglesa para Atomicity, Consistency,
Isolation, Durability):
� Atomicity: As transações que ocorrem na base de dados só devem ser
concluídas com sucesso se todas as etapas que as compõem forem
concluídas com sucesso, caso uma falhe, a transação deve ser cancelada;
� Consistency: A consistência dos dados deve ser mantida, e, no caso da
tentativa de inserção de um dado com tipo incorreto, a transação deve ser
cancelada;
� Isolation: As transações que ocorrem no banco de dados não interferem
entre si, ou seja, há um isolamento entre elas;
24
� Durability: Os dados inseridos não serão perdidos, mesmo no caso de os
mesmos não serem acessados por um longo período.
O modelo caracteriza as operações que ocorrem no nível das aplicações e
negócios da empresa.
2.1.2 Processamento de transação on-line
O processamento mais utilizado pelas empresas para tratar da manipulação
de dados (basicamente para inserção, remoção, consulta e alteração de linhas de
tabelas) nos bancos de dados relacionais é o processamento conhecido por OLTP
(sigla inglesa para On-Line Transaction Processing).
A utilidade do processamento de transação on-line pode ser resumido pelas
suas funcionalidades (BROWNING, 2001):
� Suportar operações de negócio em tempo real;
� Otimizar transações de inserção ou consulta de linhas no banco de dados;
� Otimizar a validação de dados;
� Suportar milhares de usuários.
2.2 Sistemas de Tomada de Decisão
O desenvolvimento dos sistemas de informação começou na década de 60
com os “master files”, arquivos que armazenavam informações. E, com o passar do
tempo, a grande quantidade de arquivos de informação tornou esse método de
armazenagem inviável (principalmente devido à redundância de informação e ao
elevado tempo de resposta), foi então criado o modelo de base de dados (SGBD,
“uma fonte de dados para todo processo”) (INMON, 1996).
Com o advento dos PCs, mais usuários começaram a ter acesso aos dados, o
que culminou com a criação de transições online de alto desempenho. E,
posteriormente, os chamados programas de extração, que apenas copiam os dados
de um sistema para outro segundo algum critério. Esses programas de extração
foram sendo utilizados cada vez mais, criando-se uma teia de informações
(chamada de Arquitetura Evoluída Naturalmente), onde programas de extração eram
utilizados em cima de outro programa de extração, e assim sucessivamente. Mas
25
essa nova arquitetura gerou três problemas principais: perda da credibilidade de
dados; produtividade; e impossibilidade de transformar dados em informações
(INMON, 1996).
O data warehouse foi uma das alternativas criadas para resolver essa
questão devido suas características (conforme é descrito na seção 2.3).
Atualmente, os sistemas de Tomada de Decisão, também conhecidos como
sistemas de apoio à decisão (SADs), “ajudam os gerentes de nível médio a tomar
decisões não usuais” (LAUDON & LAUDON, 2007). Sendo que o principal propósito
desses sistemas é o de fornecer informações sobre o negócio da empresa (ou
partes da mesma), e, através de relatórios, permitir analisar o desempenho corrente
da empresa (LAUDON & LAUDON, 2007).
O processo de análise das informações utiliza as informações que são
inseridas através dos aplicativos da empresa. Pode-se perceber o problema que
surge, uma vez que a manipulação de dados e a consulta dos mesmos para a
geração de relatórios causam uma sobrecarga. Naturalmente, imagina-se que a
melhor solução é separar os dados em dois ambientes, um destinado apenas para o
processamento operacional dos dados e outro para a consulta por parte da gerência,
e é exatamente isso que um sistema com data warehouse disponibiliza.
2.2.1 Processamento analítico on-line
O processamento analítico on-line (em inglês OLAP – Online Analytical
Processing) é utilizado por sistemas que têm como objetivo principal consultar uma
grande quantidade de dados e disponibilizá-los, para que possam ser analisados. “O
OLAP permite a análise multidimensional de dados, de forma que os usuários vejam
os mesmos dados de diferentes maneiras” (LAUDON & LAUDON, 2007).
2.3 Data warehouse
O data warehouse é um repositório de dados centralizado, caracterizado por:
orientação ao assunto, variante no tempo, não volátil e integrado (INMON, 1996).
26
O ambiente operacional é projetado com base nas aplicações e funções da
empresa. Por outro lado, o data warehouse é projetado com base nos principais
assuntos da empresa, por isso diz-se que ele é orientado ao assunto (INMON &
HACKATHORN, 1994).
Os dados no ambiente operacional muitas vezes ficam espalhados em
diversos bancos de dados, o que pode causar redundância e incoerência nos dados.
O data warehouse é estruturado de forma a garantir a integridade dos dados,
eliminando alguns dos problemas citados do ambiente operacional.
O data warehouse é variante no tempo, ou seja, as informações contidas nele
são referentes à evolução ao longo do tempo (usualmente em um período de alguns
anos), diferentemente dos dados no ambiente operacional, que representam os
dados mais recentes, e normalmente são utilizados em um período da ordem
somente poucos de meses (INMON, 1996).
A não volatilidade é a característica que diz respeito à alta durabilidade da
base de dados, ou seja, o data warehouse permite que os dados sejam
armazenados de forma histórica ao longo de vários (INMON, 1996).
A consistência dos dados armazenados é garantida ao passo que os dados
são somente carregados e acessados. As operações de alteração e remoção de
dados são realizadas apenas no ambiente operacional. Assim, uma vez garantida a
consistência da massa de dados carregada ao data warehouse, a consistência dos
dados armazenados é mantida independentemente da quantidade de vezes que os
dados do data warehouse são acessados.
De forma diferente dos dados do ambiente operacional – necessários para o
dia-a-dia da empresa – os dados do data warehouse são voltados para a análise e
tendência (por isso diz-se que auxiliam no processo de tomada de decisões).
Segundo (KIMBALL & ROSS, 2002), o data warehouse deve garantir algumas
propriedades. Entre elas:
� Deve organizar as informações tal que possam ser facilmente acessadas e
de forma consistente;
� Deve ser facilmente adaptável;
� Deve garantir segurança de dados (do inglês security); e
� Deve ser essencial para a tomada de decisão.
27
2.3.1 Modelo Estrela
O data warehouse é baseado em modelagem multidimensional, deste modo,
há conceitos de informações do tipo fato e do tipo dimensões. O primeiro deles diz
respeito à informação que se deseja medir, normalmente são eventos temporais aos
quais se relacionam um número – quantidade de unidades de produto vendidas,
receitas de uma venda e duração de uma ligação telefônica são exemplos claros de
informações do tipo fato. O tipo dimensão refere-se aos dados que qualificam as o
evento retratado – nome do produto, data da ocorrência da venda e cliente
relacionado ao evento são exemplos de possíveis dimensões.
O modelo estrela consiste em uma forma de modelagem do banco
dimensional, separando os dados em fatos e dimensões com relacionamentos
apenas do tipo fato-dimensão (dimensão-dimensão não é possível neste modelo),
este tipo de modelagem é representado ilustrado pela Figura 1.
Figura 1 - Modelo Estrela Genérico
2.4 Siglas, Termos e Definições
As principais siglas, termos e definições que são utilizadas neste documento
são:
� Banco/Base Operacional : Entidade de armazenamento de dados das
transações que ocorrem no dia-a-dia da empresa.
28
� Chave de negócio : (business key) É o elemento identificador de um
registro que faz sentido no contexto do negócio da empresa.
� Chave substituta : (surrogate key) É um identificador atribuído a um
registro sem que tenha valor semântico no contexto do negócio da
empresa. Normalmente definem-se chaves substitutas para otimizar o
tempo de junções entre tabelas de dados.
� Data Mart (DM): Representa uma parte do data warehouse, normalmente
pertencendo a apenas um setor da empresa.
� Data Warehouse (DW): Segundo (Inmon, 1996), data warehouse é um
repositório centralizado que abrange toda a empresa. Sendo que ele é
caracterizado por: orientação ao assunto, variante no tempo, não volátil e
integrado.
� Drill-Through : Ato de alterar a visualização de informações para obter um
maior ou menor grau de detalhamento dos dados.
� ETL (Extract, Transform and Load): São rotinas executadas
periodicamente que alimentam bases de dados a partir de uma ou mais
origens. Envolvem os três passos: extrair (Extract) dados de uma
determinada fonte, transformá-los (Transform) de modo a adequá-los ao
modelo destino e finalmente carregá-los (Load) na base destino. No
contexto de data warehouse, são utilizadas para o transporte de
informações originárias do ambiente operacional para o banco
dimensional.
� Linguagem MDX: Multidimensional Expressions é uma linguagem
introduzida pela Microsoft em 1997 que provê sintaxes para a obtenção e
manipulação de dados multidimensionais.
� Matriz de Barramento: A matriz de barramento realiza o mapeamento das
áreas de negócio da empresa, e as dimensões que são aplicadas a cada
uma dessas áreas.
� Metadados: Dados sobre dados, utilizados para funções relacionadas a
ETL, na transferência de dados de OLPT para o data warehouse.
� Modelo Dimensional : Modelagem específica, onde dados numéricos são
organizados de forma a serem agregados de acordo com suas
características em comum - dimensões.
29
� Modelo Relacional: Modelagem específica na qual as tabelas do banco
de dados mantêm relações entre si (através de chaves), modelando as
entidades reais do negócio da empresa.
� OLAP (Online Analytical Processing ): Análise de uma grande
quantidade de dados, normalmente executando operações que não
alteram os dados do banco de dados (read-only).
� OLTP (Online Transaction Processing ): Processo utilizado em
aplicações orientadas a transações, tais como os bancos de dados
relacionais convencionais, que utiliza operações que podem alterar os
dados do banco de dados.
� PostgreSQL: Sistema de Gerenciamento de Banco de Dados (SGBD).
� Script SQL: Descrição passo-a-passo em linguagem SQL (Structured
Query Language) que define operações de consulta, inserção ou remoção
de dados de uma base de dados.
� Tabela Dimensão: As tabelas dimensão são as tabelas "auxiliares", que
ficam ao redor da tabela fato (central), e contém os atributos de uma
dimensão do negócio.
� Tabela Fato: A tabela fato é a tabela central, que contém os fatos, valores
numéricos, importantes para uma determinada área do negócio.
30
3 Aplicação
3.1 Descrição do problema
O aplicativo da empresa In.voice que gera relatórios a partir de sua base de
dados operacionais começou a apresentar problemas de desempenho depois que o
banco de dados relacional passou a ter uma quantidade muito grande de dados. O
aumento do número de clientes fez com que mais informações fossem
armazenadas, conseqüentemente o tempo demandado para a geração de relatórios
cresceu de modo a inviabilizar algumas operações no sistema.
Segundo informações da diretoria da empresa In.voice – os relatórios
demandavam um tempo de até 6 horas para serem gerados. Para então serem
enviados para os respectivos clientes, embora a necessidade devesse ser atendida
no momento da requisição.
A idéia era disponibilizar informações em tempo hábil para os clientes através
de uma interface web. Mas, com a quantidade de tempo demandado para geração
dos relatórios, isso era inviável até que esse problema fosse resolvido.
3.2 Idéia para resolução
O problema de desempenho apresentado pela empresa In.voice demonstra
que utilizar o ambiente operacional para levantar relatórios de análise e suporte
pode comprometer o banco de dados relacional por um período, além de não
responder em um tempo satisfatório.
A idéia principal é separar os dois ambientes, para que um suporte os
processos e operações do dia-a-dia da empresa, e o outro ambiente suporte o
levantamento de informações para relatórios de análise. Com isso surge a idéia de
criar um data warehouse.
A empresa possui um banco de dados operacional, o que facilita a
implementação de um data warehouse, pois todos os dados inseridos já estão sendo
armazenados em meio digital.
31
3.2.1 Ferramentas
A criação do data warehouse foi feita em etapas. Sendo que em cada etapa
um determinado software (de código aberto) foi essencial para auxiliar no processo.
Segue uma breve descrição de cada uma das ferramentas utilizadas durante
o projeto.
3.2.1.1 PostgreSQL
O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional
de código aberto. Ele suporta os principais tipos de operações realizadas nos banco
de dados relacionais comuns, como criação de tabelas, chaves, relacionamentos,
entre outros.
O banco de dados utilizado pela empresa In.voice é acessado através desta
ferramenta. E, através dela, foi criado o modelo dimensional.
A manipulação dos esquemas e tabelas pode ser realizado através do
PgAdmin III, um software de manipulação e manutenção do banco de dados cuja
interface de usuário é ilustrada pela Figura 2.
32
Figura 2 - Interface de usuário do pgAdminIII
3.2.1.2 Pentaho Data Integration
O Pentaho Data Integration, chamado anteriormente de Kettle, é a ferramenta
responsável por extrair, transformar e carregar (em inglês, ETL) processos. O
objetivo a ser alcançado com a utilização do Kettle é automatizar a transformação
dos dados a partir do banco de dados relacional do usuário para o banco de dados
dimensional. Sua interface é ilustrada pela Figura 3.
33
Figura 3 - Interface de Usuário do Pentaho Data Integration
A modelagem da ETL se dá através do encadeamento de operações menores
que realizam diversas ações sobre o fluxo de dados representado. Cada uma
dessas operações é representada por um bloco e o transporte de dados entre dois
blocos é representado por uma flecha do bloco fornecedor ao bloco receptor. As
principais operações desta ferramenta que serão utilizadas no desenvolvimento no
projeto são:
� “Table input” (Entrada do tipo tabela): Lê o conteúdo de uma tabela em
uma base de dados relacional e o adiciona ao fluxo de dados.
� “Lookup” (Consulta): Baseado em uma coluna já pertencente ao fluxo,
consulta uma fonte de dados para procurar outro valor que tenha
correspondência àquela do fluxo.
� “Table output” (Saída do tipo tabela): Grava o conteúdo do fluxo em uma
tabela de um banco de dados relacional.
34
� “Lookup/Update Combination” (Combinação de consulta e atualização):
Realiza a consulta de um dado em uma base relacional, e compara seus
valores com o fluxo. Se houver mudança a base é atualizada conforme a
fonte.
3.2.1.3 Mondrian
Mondrian (ou Pentaho Analysis Services) é um mecanismo OLAP
desenvolvido com a finalidade de apresentar dados de uma forma multidimensional.
Esta ferramenta basicamente é um software que provê o serviço de bases OLAP
através de interfaces web com outros aplicativos. Ele recebe como entrada um
arquivo XML definido pelo desenvolvedor do data warehouse e, através das
informações contidas nele, realiza as agregações de informações contidas no
modelo dimensional utilizado.
O objetivo a ser alcançado com a utilização do Mondrian é a criação de um
data warehouse a partir do modelo de banco de dados dimensional previamente
modelado. O Mondrian é um serviço executado através de servidores de aplicações
Web e inclui em seu pacote o componente jPivot que consiste em uma interface de
acesso a dados que é ilustrada pela Figura 4.
35
Figura 4 - Interface de usuário do jPivot, acessando o serviço OLAP do Mondrian
3.2.1.4 Schema Workbench
A modelagem do data warehouse é baseada na definição em XML do modelo
multidimensional. Esta ferramenta auxilia esta edição, apresentando o documento
sob uma forma de árvore e lista as propriedades de cada um dos atributos em uma
lista, para cada um dos níveis da árvore. A Figura 5 ilustra sua interface de edição.
36
Figura 5 - Interface de usuário do Schema Workbench
3.2.1.5 Pentaho BI Studio
Esta ferramenta é responsável por integrar funcionalidades das demais
ferramentas integradas a um sistema web com suporte a definição de políticas de
segurança e grupos de usuários. Integra Mondrian (seção 3.2.1.3), Pentaho
Reporting e Pentaho Data Integration (seção 3.2.1.2). A interface de usuário
baseada em Web está ilutrada na Figura 6.
37
Figura 6 - Interface de usuário do Pentaho BI Studio
38
4 Etapas do projeto
4.1 Primeiros Passos
Em etapas iniciais de idealização e definição do tema do projeto, havia a
preocupação em modelar e desenvolver uma aplicação de data warehouse para um
setor para o qual este tipo de modelagem fosse adequada, de modo que fosse
possível obter resultados concretos de desempenho e ganho de eficiência
operacional, ao passo que se agilizava a capacidade analítica e performática dos
relatórios utilizados. Neste foco, a melhor alternativa encontrada foi pesquisar um
caso problemático real, segundo o qual fosse possível retirar todas as conclusões e
resultados desejados, comparando ganhos antes e depois da implantação da
aplicação através de depoimentos de usuários.
A empresa In.Voice se dispôs a apresentar o problema de desempenho que
enfrentava, e disponibilizou seus sistemas e ambiente operacional para que o
projeto pudesse ser desenvolvido.
Iniciou-se, assim, um ciclo de reuniões que possibilitaram o início do projeto
com a análise dos dados operacionais que, por sua vez, fez parte do levantamento
de requisitos do projeto, que definiu aspectos como escopo e restrições no momento
inicial.
4.2 Análise do banco de dados operacional
A empresa In.Voice apresentou o sistema de manipulação de informações
que, além de editar o conteúdo da base de dados, é também utilizado para a
geração de relatórios. Este sistema é baseado em um modelo relacional
implementado sobre uma base de dados PostgreSQL 8 (conforme definido na seção
3.2.1.1).
O rápido crescimento da empresa e a desorganização de projetos de
desenvolvimento do sistema mencionado, unidas à complexidade das operações de
negócio realizadas, fez com que a base incorporasse mais de 100 tabelas de dados
dispostas de maneiras muitas vezes redundantes e com normalizações
39
inadequadas. O modelo representa o ambiente operacional do projeto de data
warehouse de onde se extraem os dados para alimentação da base dimensional.
O escopo do trabalho junto à análise de tal estrutura permitiu um refinamento
através de um processo de engenharia reversa o qual tomou como ponto de partida
os sistemas de geração de relatórios para a conseqüente análise do fluxo de dados
e suas respectivas origens na base relacional, resultando na extração da parcela
mais significativa (disponível no Anexo I) para a modelagem dimensional e nas quais
as próximas etapas do projeto são baseadas.
No modelo refinado apresentado, pode-se observar o papel central sobre o
conjunto de tabelas “Fatura” e “Inventário”, uma vez que estas entidades têm grande
importância na análise de custos em telecomunicações das empresas, e uma vez
que o significado de negócio dos registros de “Fatura” são as consolidações de
registros telefônicos em conjuntos limitados por data bem definida da ocorrência do
evento. A tabela “Inventário” representa o vínculo entre clientes e suas faturas. O
papel centralizador apresentou um caminho para a definição dos dados do tipo
“Fato”, cujas características principais estão em seus atributos temporais e
representações numéricas quantitativas. O processo de identificação é descrito
posteriormente na etapa de levantamento de requisitos (seção 4.3).
4.3 Especificação de Requisitos
As reuniões que se desencadearam após o primeiro contato com a empresa
resultou no levantamento de requisitos do projeto de data warehouse, que por fim
levou à criação do documento de Especificação de Requisitos, entregue como
produto final do primeiro quadrimestre de 2009 da disciplina PCS-2040 (Projeto de
Formatura I), porém, após o final desta disciplina, novas reuniões e redefinições do
negócio da empresa resultaram em algumas modificações no modelo apresentado
que será detalhado nos próximos itens.
O principal requisito da empresa era um sistema para geração de relatórios
que respondesse em quantidade satisfatória de tempo. Assim, os principais aspectos
levantados foram:
a. Novo ambiente de geração de relatórios (data warehouse);
40
b. Geração de relatórios em tempo aceitável;
c. Aumentar o ganho de informação de um relatório;
d. Prover métodos analíticos mais eficientes.
O item “a” desta lista representa a independência de um sistema de data
warehouse que não deve influenciar os sistemas em operação na empresa. Os itens
“b”, “c” e “d” apresentados acima são requisitos relacionados aos antigos sistemas
da empresa em operação. No item “b” da lista, o termo “tempo aceitável” faz menção
ao tempo de geração de um relatório específico de um cliente que varia de alguns
minutos a horas de tempo de espera. Para o item “c” espera-se que, uma vez que
relatórios serão gerados em tempos menores, é possível incluir mais informações,
facilitando assim o cumprimento da função básica de relatórios que é o auxílio na
tomada de decisões. O item “d” representa o requisito de maior dinamismo no
sistema que, uma vez mais ágil, possa oferecer métodos analíticos de dados mais
eficientes como recursos de drill-through em tabelas de dados.
Após concluído o primeiro documento de especificação, modificações
mostraram-se necessárias, dentre estas a principal diz respeito aos dados
armazenados no data warehouse cuja granularidade diminuiu, uma vez que o nível
de detalhamento requisitado passou do nível de faturas para o nível de registros.
Esta modificação gerou um aumento na massa de dados tratados na proporção
dada pelo número médio de registros por fatura, ou seja, cada dado de fatura passa
a inserir uma quantidade “N” de registros de telefonia, onde “N” é o número médio de
registros por fatura. O valor depende do porte da empresa.
4.3.1 Modelagem do banco de dados dimensional
A modelagem do banco de dados dimensional inicia-se com a identificação
dos dados que representam valores e quantidades relacionados a eventos discretos
no tempo e de papel central nas regras de negócio. Define-se, assim, dados do tipo
“fato” e, conseqüentemente, a tabela fato com os diversos atributos do evento.
Características do evento de importância relevante ao negócio e definição de
relatórios podem ser modeladas em dimensões junto aos seus respectivos atributos.
Uma vez concluídas as tabelas, o esquema com as tabelas e relações é criado
através de um sistema gerenciador de banco de dados.
41
O diagrama representativo do modelo dimensional é ilustrado pela Figura 7 e
cada uma das dimensões tem seus atributos detalhados no Anexo II. O método
utilizado baseia-se no modelo estrela (conforme descrito na seção 2.3.1). Sua
vantagem está em sua simplicidade construtiva e velocidade de acesso aos atributos
de uma dimensão. Em contra partida, dados acabam tornando-se mais esparsos e o
nível normalização é baixo. Como há poucas dimensões no projeto que possuem
mais de três atributos, e o número de dimensões hierarquizadas é pequeno, isto é,
não prejudica a normalização dos dados, o modelo “estrela” foi adotado a priori.
Figura 7 – Modelo dimensional modelado
42
4.3.1.1 Tabela Fato
A tabela fato é produto do levantamento de requisitos e especificação do
sistema e pode ser visualizada nos diagrama relacional (Anexo II) da modelagem
dimensional; identificada pelo nome “Fato_Registro”. Os dados da tabela fato dizem
respeito à entidade de negócio denominada “Registro”, o qual, por sua vez,
representa a ocorrência de uma chamada telefônica de um cliente e seus atributos
de negócio mais relevantes para o uso em relatórios. Esses atributos estão
enumerados e detalhados na tabela abaixo (apenas atributos relativos ao negócio
são detalhados nesta tabela).
Campo Tipo de dado Significado de Negócio
Dt_inicio_registro Data Representa a data de início
da chamada telefônica
Dt_termino_registro Data Representa a data de
término da chamada
telefônica
Fato_duracao Decimal Representa o valor em
segundos da duração da
chamada telefônica
Fato_valor_original Decimal Representa o valor original
cobrado pela chamada sem
imposto.
Fato_valor_retarifado Decimal Representa o valor retarifado
da chamada telefônica.
Fato_valor_rebilled Decimal
Fato_quantidade Inteiro Representa a quantidade
Tabela 1 - Especificação dos atributos da entidade Fato - Registro
Ao modelo dimensional foram adicionadas colunas responsáveis por fazer a
ligação entre os registros da tabela fato e suas dimensões quando aplicáveis
(colunas identificadas com o prefixo “sk_” em nosso modelo dimensional). Estas
colunas são chaves estrangeiras (termo definido na seção 2.4) que “apontam” para
chaves substitutas (surrogate keys, termo definido na seção 2.4), a importância do
uso deste tipo de chaves (que não possuem significado de negócio) está em seu tipo
43
inteiro que torna a associação entre entidades mais ágil e simples de ser tratada em
relação ao uso de chaves de negócio que poderiam ser muitas vezes do tipo cadeia
de caracteres o que prejudicaria o desempenho do banco de dados.
Uma perda de desempenho em tarefas de união (join) afeta diretamente a
etapa de carga de informações ao data warehouse que, ao fazer pré-processamento
de dados, internamente realiza diversas vezes esta operação para obter dados sob
a forma adequada para ser armazenada em sua arquitetura interna.
4.3.1.2 Tabelas Dimensão
Assim como a tabela fato, o levantamento de requisitos levou às
especificações das tabelas de dimensão. De forma geral as dimensões modeladas
foram:
� dim_unidade_de_negocio : Dimensão da unidade de negócio.
� dim_ centro_custo : Dimensão do centro de custo.
� dim_ fatura : Dimensão da fatura.
� dim_ cliente : Dimensão de cliente.
� dim_ operadora : Dimensão da operadora.
� dim_tempo : Dimensão de tempo.
� dim_ entidade : Dimensão da entidade.
� dim_ inventario : Dimensão do inventário.
� dim_ tipo_servico : Dimensão do tipo de serviço.
� dim_ conta : Dimensão da conta.
Os atributos das tabelas dimensão e seus significados de negócio estão no
anexo 8.2.
4.3.2 Extração, Transformação e Carga
As ETLs foram divididas em dois grupos: ETLs das tabelas dimensão; e ETL
da tabela fato. Em teoria as ETLs são modeladas de forma a oferecerem um recurso
automatizado de extrair dados de fontes distintas; consolidá-los sob um formato
padronizado e então inseri-los em uma base centralizada. Esta idéia é utilizada no
projeto, sendo que o banco operacional representa a fonte de dados e o banco
44
dimensional representa o destino. Para tais processos de carga foram elaborados
dois modelos básicos de carga em regras gerais que serão apresentados nas
seções 4.3.2.1 e 4.3.2.2. O primeiro deles é voltado à carga de tabelas-dimensões e
o segundo, carga de tabelas-fato.
4.3.2.1 ETL das tabelas dimensão
O Modelo de carga de Dimensões é apresentado na Figura 8.
Figura 8 - Modelo básico de ETL de carga de dimensões
O processo, em palavras gerais, consiste em extrair dados da fonte e
compará-los com os dados presentes no modelo dimensional a fim de identificar
linhas que foram modificadas, inseridas ou removidas desde a última carga.
Baseado nestas informações, a base dimensional deve ser atualizada a fim de
manter o conteúdo sincronizado entre ambos ambientes.
4.3.2.2 ETL da tabela fato
Em termos de linhas da tabela fato, deve existir uma ligação de cada um dos
registros com as respectivas dimensões, quando estas forem aplicáveis. Porém, esta
ligação não é explícita no momento em que ocorre a extração desses dados, devido
às diferenças entre os modelos operacional e dimensional, uma vez que cada um
45
deles têm conceitos para identificadores diferentes. No modelo relacional tradicional
utiliza-se o conceito de chaves primárias, normalmente numéricas e únicas para
cada registro, de forma similar, o modelo dimensional utiliza o conceito de “chave de
negócio” que por sua vez são mapeadas em colunas numéricas – surrogate keys
(definidas na seção 2.4) – para otimizar a performance do banco, assim deve haver
um mapeamento entre ambas as chaves para se manter a consistência entre elas.
Foram levantadas duas formas diferentes de realizar a carga da tabela fato:
buscas em série ou buscas em paralelo. A Figura 9 ilustra ambos os modelos e suas
diferenças construtivas. No modelo em série, após a extração dos dados, as buscas
por chaves substitutas ocorre linearmente uma após a outra (Figura 9.a), após o
termino das buscas insere-se o fluxo resultante no modelo dimensional; em contra-
partida, o modelo paralelo (Figura 9.b) realiza buscas simultâneas de chaves
substitutas para então realizar a junção do fluxo novamente para então armazená-lo
na base dimensional.
O modelo utilizado para o desenvolvimento desta ETL é o modelo de busca
em série (Figura 9.a). Inicialmente o modelo em paralelo havia sido desenvolvido,
mas devido à ocorrência de deadlocks de acesso ao banco de dados no momento
das atividades em paralelo, optou-se pelo modelo em série por evitar este tipo de
conflito embora ofereça relativa perda de desempenho.
46
Extração de
dados no modelo
operacional
Busca da PK da
dimensão 1
Busca da PK da
dimensão 2
Busca da PK da
dimensão n...
União dos fluxos
de dados
Inserção dos
dados na base
dimensional
Modelo ETL: Carga da Fato (paralelo)
Extração de
dados de registros
no modelo
operacional.
Busca da PK da
dimensão 1
Busca da PK da
dimensão 2
Busca da PK da
dimensão n
Inserção dos
dados na base
dimensional
...
Modelo ETL: Carga da Fato (série)
(a)
(b) Figura 9 - Modelos de ETL de carga de tabelas-fato (a) série; (b) paralelo
4.3.3 Desenvolvimento da base multidimensional ( Data warehouse )
A modelagem em estrela, conforme previamente apresentado na seção 4.3.1,
coloca a tabela fato no centro do modelo e, relacionadas diretamente a ela, uma a
uma, as dimensões. Assim, tal modelo deve ser mapeado ao Mondrian de modo que
47
este seja capaz de instanciar o cubo e, assim, gerar o data warehouse com os dados
organizados em dimensões, cumprindo os objetivos do trabalho. Este mapeamento é
realizado através da ferramenta Schema Workbench (apresentado na seção 3.2.1.4)
que gera um arquivo XML com a sintaxe entendida.
A etapa seguinte corresponde à definição das hierarquias dimensionais e por
fim, o acabamento final de tratamento de formatações de dados e nomes de
campos.
Figura 10 – Modelo Multidimensional no Schema Workbench.
A seguir, são especificadas os detalhes mais relevantes da modelagem
multidimensional do data warehouse.
48
4.3.3.1 Métricas
As métricas de um modelo multidimensional representam os dados dos
eventos do negócio em si. Normalmente são temporais e numéricas, ou seja, têm
ocorrência bem definida no tempo e representam entidades quantificáveis no
negócio, possibilitando sua agregação em diversos níveis de detalhamento
utilizando-se funções matemáticas de agregação (adição, contagem, máximo,
mínimo, entre outras).
Para o projeto em questão foram definidas como métricas os valores a
respeito de uma chamada telefônica (entidade “Registro”):
� Duração;
� Quantidade;
� Valor Original;
� Valor Recobrado;
� Valor Retarifado.
Valores que têm representatividade na criação de relatórios de tomada de
decisão para a empresa In.Voice.
4.3.3.2 Dimensões sem hierarquia
Dimensões simples, sem uma hierarquização de seus membros, seguem a
um mesmo modelo em que a dimensão aponta para a tabela do modelo dimensional
e extrai dali todos seus membros e atributos, sem organizá-los hierarquicamente.
Para o projeto, a maioria das dimensões, exceto da dimensão de tempo, possuem
essas características, uma vez que o nível único de detalhamento de cada uma das
dimensões é suficiente para a geração dos relatórios.
4.3.3.3 Dimensão de tempo
A hierarquização de dimensão foi aplicada à dimensão de tempo. Desta
forma, houve a hierarquização da tabela “dim_tempo” em “Ano > Trimestre > Mês >
Dia”.
49
Figura 11 - Hierarquia de tempo definida
4.3.3.4 Granularidade
A granularidade temporal do modelo em questão segue a mesma
granularidade dos dados carregados do ambiente operacional da empresa, que é do
nível de registros telefônicos diários. Desta forma, a granularidade permite uma
análise profunda e possibilita tanto a análise de registros diários no nível mais baixo,
quanto uma análise macro que agrega dados por mês, trimestre ou ano; além da
segmentação pelas demais dimensões como “fatura” ou “centros de custo”
relacionadas. Assim, os usuários desde a tomada de decisão gerencial (pontual) à
tomada de decisão estratégica (mais abrangente) são atendidos pelo sistema.
4.4 Desenvolvimento das ETLs
Os fluxos de ETLs das tabelas dimensão são muito semelhantes, portanto foi
decidido que todas seriam agrupadas em duas ETLs, sendo que os fluxos seriam
executados paralelamente.
As dimensões dim_unidade_de_negocio, dim_centro_custo, dim_fatura,
dim_cliente, dim_operadora, dim_entidade, dim_inventario, dim_tipo_servico e
dim_conta tiveram o seguinte fluxo criado:
1. Entrada de dados (Extract): O mecanismo utilizado no software Pentaho
Kettle foi o “Table input” (seção 3.2.1.2), apontando para o banco de
dados “Bunge” (nome do banco de dados do ambiente operacional),
esquema “GP4” (nome do esquema do banco de dados do ambiente
operacional), e cada tabela possui um script escrito em SQL, que
50
seleciona as informações importantes (sendo que cada dimensão teve
origem em uma tabela do modelo relacional);
2. Carga de dados da dimensão (Transform & Load): Os novos dados
devem ser comparados com os dados já existentes na dimensão a fim de
sincronizar ambas e evitar duplicidade de registros.
A Figura 12 ilustra os fluxos de ETL das dimensões.
Figura 12 - Diversos fluxos de carga das dimensões
A tabela dim_tempo pertence a uma ETL das dimensões, mas possui o fluxo
diferente. Isso ocorre pois, para a criação da tabela dim_tempo, foi utilizado um
arquivo CSV. O que difere esta dimensão das demais no contexto da ETL é que a
entrada de dado é feita não por um script SQL, mas sim por um arquivo do tipo CSV.
A ETL da tabela fato segue um fluxo diferente das ETLs das dimensões
(Figura 13). O fluxo é o seguinte:
51
1. Entrada de dados (Extract): O mecanismo utilizado também foi o “Table
Input” (conforme definido na seção 3.2.1.2) do Pentaho Kettle, apontando
para o base de dados operacional, utilizando um script na linguagem SQL,
o qual é bastante diferente dos utilizados para as ETLs das dimensões,
uma vez que a tabela inicial possui todas as chaves de negócio que serão
trocadas por chaves substitutas;
2. Busca de Chaves (Transform): Para cada chave de negócio extraída,
deve-se saber a correspondente chave substituta, para isto, uma busca
baseada na chave de negócio deve ser realizada. Este tipo de busca é
realizada pelo componente “Lookup” (detalhado em 3.2.1.2). Têm-se
então, 9 etapas de lookup – uma para cada dimensão.
3. Inserção (Load): Cada um dos registros chega nesta etapa com seus
valores originais extraídos adicionados às chaves substitutas, desta forma,
basta mapear as colunas entre o fluxo de dados e a tabela destino, que no
caso é a tabela Fato_Registro. O processo de inserção dos dados é
realizado pelo componente “Table output”.
Figura 13 - ETL da Tabela fato_registro
52
Em termos de desempenho, utilizou-se o armazenamento temporário em
memória cachê em cada uma das etapas do fluxo, os resultados comparativos são
apresentados neste documento na seção 5.3.
4.5 Desenvolvimento do Data warehouse
O modelo multidimensional especificado na seção 4.3.4 foi implementado
utilizando o framework Pentaho, que utiliza como servidor OLAP a ferramenta
Mondrian. O data warehouse, assim, foi modelado inicialmente pela definição de um
XML no formato reconhecido pelo Mondrian seguindo as especificações do projeto.
Após o início do desenvolvimento, tomou-se conhecimento da ferramenta lançada
durante o desenvolvimento Schema Workbench que facilita a edição do XML através
de uma interface gráfica.
Uma vez desenvolvido, o modelo deve ser publicado no Mondrian, isto é feito
através da edição de um arquivo de configuração interno à ferramenta e consiste na
edição das strings de conexão e definição dos dados apontados.
53
5 Resultados
5.1 Interfaces de usuário
A ferramenta Pentaho BI Studio contém uma interface baseada em Web. A
Figura 14 ilustra a tela de boas vindas do sistema.
Figura 14 – Tela de boas vindas do sistema web Pentaho BI Studio.
54
Após a autenticação na tela de boas vindas, a tela de entrada do sistema,
ilustrada pela Figura 15, é exibida. A partir desta tela é possível realizar todas as
operações do ciclo do data warehouse:
� Carga de dados através das ETLs;
� Atualização dos dados do repositório;
� Geração e consulta de relatórios administrativos utilizando dados do data
warehouse;
� Navegação analítica através das métricas e dimensões do data
warehouse.
Em termos de segurança há controle administrativo de login, fornecido por
outra interface administrativa, ilustrado pela Figura 16.
Figura 15 – Tela de entrada no sistema.
55
Figura 16 – Controle de logins e políticas de segurança.
5.1.1 Interface de usuário de carga de dados
Para realizar a carga de dados, foram preparadas para os usuários duas
possibilidades: executar o pacote ETL utilizando a interface de usuário ou a
ferramenta Pentaho Data Integration. No primeiro caso, a carga é executada de
maneira muito simples, basta um duplo clique no menu à esquerda da interface que
corresponde à carga de dado selecionada, e então a rotina se inicia. No momento do
término é exibida uma tela com informações do processo executado como sucesso
da operação e um conjunto de dados carregados para verificação rápida. A Figura 17
ilustra a tela de término de execução.
Outro método é através da ferramenta Pentaho Data Integration, que possui
uma interface amigável, porém com mais recursos de personalização e relatório de
desempenho. Para obter o pacote não há necessidade de busca entre os arquivos
do sistema, foi desenvolvido um repositório onde a ferramenta consegue buscar as
rotinas de carga de forma imediata. A Figura 18 ilustra este método de execução.
56
Figura 17 – Execução da ETL de carga de dimensões através da interface de usuário.
57
Figura 18 – Execução da ETL de Fato através da ferramenta Pentaho Data Integration.
Além destas duas formas de manter o sistema através de execuções manuais
há possibilidade de agendar a execução para uma data específica ou de forma
recorrente.
5.1.2 Interface de usuário de análise de dados e re latórios
A análise de dados pode ser realizada através do componente nativo do
Mondrian jPivot. Sua interface é ilustrada pela Figura 19.
58
Figura 19 – Análise de dados armazenados no data warehouse.
5.2 Testes
Os testes realizados foram divididos em:
� Teste de ETLs
� Teste do Data warehouse
Cada um destes é detalhado nos subitens seguintes.
59
5.2.1 Teste das ETLs
Os testes de ETLs foram realizados através do próprio mecanismo de
execução da ferramenta Pentaho Data Integration. A ilustra uma saída típica com
dados a respeito de uma execução da ETL.
Figura 20 – Saída típica de análise de performance após execução de ETL pelo Pentaho Data
Integration
Através destes dados, foram realizados testes de desempenho, além dos
testes de consistência de dados entre o ambiente operacional e a base dimensional
após a execução das ETLs.
5.2.2 Teste do data warehouse
O data warehouse foi testado através da interface padrão do Mondrian, que
utiliza o componente jPivot. O teste consiste em comparação entre dados contidos
no ambiente operacional e os dados que o data warehouse. No caso, as agregações
do data warehouse foram testadas uma a uma com amostras de dados que fossem
pertinentes aos mesmos filtros, e validades através da soma manual dos registros no
ambiente operacional para então serem comparados entre si. Os recursos de drill-
through também são testados da mesma forma, com a diferença da comparação ser
realizada a cada drill-down realizado.
5.3 Desempenho
A partir da execução de etapas isoladas e ciclos completos desde a carga de
dados e geração de relatórios, a seguinte tabela pôde ser levantada:
60
Variável Medida Massa de dados
(registros)
Valor
(DW) Unidade de Medida
Tempo médio de execução das ETLs
de dimensão 1x106 27 Segundos
Tempo médio de execução da ETL de
tabela-fato 1x106 15,8 Minutos
Maior tempo medido para geração da
tabela de dados analíticos pelo jPivot 1x106 18 Segundos
Tempo médio estimado para geração
de relatórios de complexidade baixa. 1x106 30 Segundos
Tempo de ciclo completo mínimo
(soma) 1x106 17,05 Minutos
Tabela 2 – Variáveis de desempenho e resultados obtidos.
De acordo com a tabela, o tempo de execução de ETLs foi de cerca de 16
minutos, este é o tempo crítico para a disponibilidade dos dados, pois é responsável
por disponibilizá-los no data warehouse após o devido processamento do modelo
dimensional realizado automaticamente pela ferramenta Mondrian. Com os dados
disponibilizados os tempos medidos são referentes à geração de relatórios, ou seja,
estão mais relacionados à ferramenta de relatório do que ao data warehouse em si.
Desta forma chega-se ao valor total de ciclo de aproximadamente 17 minutos.
A título de comparação levantou-se o dado de desempenho dos sistemas
atuais da empresa In.Voice para um ciclo: um relatório de cerca de 10 milhões de
registros leva em média 6 horas para ser gerado. Assim, pela análise dos dados de
maneira qualitativa, o ganho em desempenho percebido pelo usuário foi alto.
61
6 Considerações finais
6.1 Conclusões
O ambiente competitivo em que as empresas se encontram atualmente revela
a grande necessidade de possuir diferenciais no momento da tomada de decisões
responsáveis por guiá-las rumo ao sucesso perante seus concorrentes. Neste
contexto, o uso de tecnologias relativamente recentes como o uso de data
warehouses mostram-se muito eficientes ao aumentar a capacidade analítica dos
estrategistas que por sua vez podem destacar suas empresas ao tomar as decisões
de sucesso.
Nota-se um sensível crescimento do mercado que envolve tecnologias de
auxílio estratégico, e data warehouse está dentre elas. O aumento de investimento
populariza cada vez mais os projetos de Business Intelligence que comumente faz
uso de data warehouses devido à alta eficiência na aquisição de dados através de
tecnologias OLAP. Com este tipo de crescimento, desenvolvem-se também todas as
demais atividades relacionadas às etapas do projeto de data warehouses, como a
integração de dados, definição de processos estruturados, definição de dados
estratégicos, definição de métodos de análise de dados, dentre outras.
Uma vez com a especificação pronta e validada, inicia-se o desenvolvimento
do projeto. O ciclo de vida de desenvolvimento de um data warehouse difere do
modelo clássico (requisitos, análise, desenvolvimento, testes e implantação), o novo
modelo é mais iterativo, partindo da criação de um primeiro data warehouse, e só
depois ocorre um entendimento dos requisitos (INMON, 1996). Isso não reduz a
importância da especificação, mas deixa subentendido que novas versões da
especificação serão necessárias por conta de eventuais alterações.
6.2 Contribuições
As contribuições que o sistema deixa para o futuro é uma aplicação prática de
data warehouse que vai ajudar principalmente a empresa In.voice a solucionar o
problema de geração de relatórios, e vai ser utilizado como base para um
remodelamento do banco de dados operacional.
62
Outra contribuição importante é a monografia, que foi escrita de maneira a
fornecer uma visão geral sobre data warehouse, apresentar os conceitos, e elaborar
um passo a passo para desenvolver um sistema baseado em data warehouse
utilizando apenas softwares de código aberto, sendo útil para qualquer pessoa que
necessite de referências em língua portuguesa sobre sistemas com data warehouse.
Os membros do grupo tiveram um aprendizado substancial com este trabalho.
Desde os estudos dos conceitos relacionados a data warehouse, passando pelas
ferramentas de software de código aberto – nunca antes utilizadas pelos membros
do grupo –, e culminando na realização do projeto, que envolveu reuniões com a
empresa In.voice e sua implementação. Tudo isso contribuiu para um importante
crescimento acadêmico prático e para consolidar muitos assuntos vistos ao longo do
curso de graduação.
6.3 Trabalhos futuros
O sistema baseado em data warehouse foi totalmente desenvolvido e testado
utilizando uma cópia do banco de dados da empresa In.voice. Apesar de essa etapa
ter sido concluída com sucesso, outros trabalhos futuros podem ser desenvolvidos a
partir deste.
A aplicabilidade prática pode ser traduzida na utilização que o sistema terá na
empresa cliente com a implementação do mesmo. A empresa In.voice planeja
remodelar todo o banco de dados relacional baseado no data warehouse resultante
do presente trabalho.
O data warehouse desenvolvido tem como base apenas um repositório
central e foi baseado em apenas uma tabela fato e modelo estrela. Portanto, como
contribuição teórica e prática para este trabalho, possíveis sugestões são:
� Desenvolvimento do conceito e da aplicação de um sistema baseado em
data warehouse com diversos data marts, atendendo setores distribuídos
em uma empresa;
� Desenvolvimento de um data warehouse utilizando o modelo snowflake.
� Desenvolvimento de um sistema utilizando data mining para analisar as
tendências das informações contidas no data warehouse desenvolvido.
63
7 Referências Bibliográficas
INMON, William Harvey. Building the Data warehouse . 2a Ed. USA: Wiley, 1996.
KIMBALL, Ralph; ROSS, Margy. The data warehouse toolkit: the complete guide
to dimensional modeling . 2a Ed. USA: Wiley, 2002.
INMON, William Harvey; HACKATHORN, Richard D.. Using the Data warehouse .
1a Ed. USA: Wiley, 1994.
LAUDON, Kenneth C.; LAUDON, Jane P.. Sistemas de informação gerenciais . 7a
Ed. São Paulo: Pearson Prentice Hall, 2007.
TUERK, Miriam. The Open Source Data warehouse Revolution . Artigo sobre data
warehouse desenvolvidos com tecnologia de código aberto. Disponível em
<http://www.ittoday.info/Articles/Open_Source_Data_Warehouse.htm>. Acesso em:
28 nov 2009.
Sourceforce.Net. Documentação do PostgreSQL 8.0.0 . Documentação traduzida
sobre PostgreSQL versão 8.0.0 pela comunidade Sourceforce.Net. Disponível em
<http://pgdocptbr.sourceforge.net/pg80/preface.html>. Acesso em: 28 nov 2009.
Pentaho Community. Latest Pentaho Data Integration (aka Kettle)
Documentation . Última documentação atualizada disponível sobre o aplicativo Data
Integration da Pentaho Open Source Business Intelligence. Disponível em
<http://wiki.pentaho.com/display/EAI/>. Acesso em: 28 nov 2009.
Pentaho Open Source Business Inteligence. Mondrian Overview . Documentação
sobre o aplicativo Mondrian da Pentaho Open Source Business Intelligence.
64
Disponível em <http://mondrian.pentaho.org/documentation/doc.php>. Acesso em:
28 nov 2009.
Pentaho Open Source Business Intelligence. Pentaho Reporting Home Page .
Pagina principal do projeto Pentaho Reporting da Pentaho Open Source Business
Intelligence. Disponível em <http://reporting.pentaho.org/>. Acesso em: 28 nov 2009.
About.com Databases. The Acid Model . Descrição sucinta sobre o modelo ACID.
Disponível em <http://databases.about.com/od/specificproducts/a/acid.htm>. Acesso
em: 28 nov 2009.
BROWNING, Dave; MUNDY, Joy. Data warehouse Design Considerations .
Considerações na construção de um data warehouse. Disponível em
<http://msdn.microsoft.com/en-us/library/aa902672(SQL.80).aspx>. Acesso em: 28
nov 2009.
65
8 Anexos
8.1 Anexo I
Base de dados operacional – parcela mais significativa para a modelagem
dimensional.
66
67
8.2 Anexo II
Modelo dimensional modelado
8.2.1 Anexo II.a - Tabela Dimensão Cliente
68
8.2.2 Anexo II.b - Tabela Dimensão Operadora
69
8.2.3 Anexo II.c - Tabela Dimensão Inventario
Fato_Registro
sk_registro
sk_inventario
dim_contas
dim_entidade
dim_unidade_de_negocio
dim_centro_de_custo
dim_tipo_servico
dim_tempo
dim_operadora
dim_cliente
dim_inventario
PK sk_inventario
tipo
dt_ativacao
dt_desativacao
dia_vcto
ncr
numero_inventario
codigo_local
codigo_pais
situacao
recurso_logico
dat_operation
70
8.2.4 Anexo II.d - Tabela Dimensão Tempo
Fato_Registro
sk_registro
dt_cadastro
dim_contas
dim_entidade
dim_unidade_de_negocio
dim_centro_de_custo
dim_tipo_servico
dim_inventario
dim_operadora
dim_cliente
dim_tempo
PK sk_tempo
dia
mes
ano
trimestre
71
8.2.5 Anexo II.e - Tabela Dimensão Tipo de Serviço
72
8.2.6 Anexo II.f - Tabela Dimensão Centro de Custo
Fato_Registro
sk_registro
sk_centro_de_custo
dim_contas
dim_entidade
dim_unidade_de_negocio
dim_tipo_servico
dim_tempo
dim_inventario
dim_operadora
dim_cliente
dim_centro_de_custo
PK sk_centro_de_custo
codigo
descricao
parent_id
codigo_antigo
descricao_antigo
id_temp
parent_id_temp
autor
73
8.2.7 Anexo II.g - Tabela Dimensão Unidade de Negoc io
74
8.2.8 Anexo II.h - Tabela Dimensão Entidade
75
8.2.9 Anexo II.i - Tabela Dimensão Contas
76
8.2.10 Anexo II.j – Tabela Dimensão Fatura
77
8.3 Anexo III
Xml interpretado pelo Mondrian para instanciar o data warehouse
<Schema name="Bunge_v1">
<Cube name="BungeCube" cache="true" enabled="true">
<Table name="fato_registro" schema="Dimensional">
</Table>
<Dimension type="StandardDimension" foreignKey="sk_unidade_de_negocio" name="Unidade de Negocio">
<Hierarchy name="Unidade de Negocio" hasAll="true" allMemberName="Todas Unidades de Negocio" primaryKey="sk_unidade_de_negocio">
<Table name="dim_unidade_de_negocio" schema="Dimensional">
</Table>
<Level name="Unidade de Negocio" column="sk_unidade_de_negocio" nameColumn="codigo" type="Numeric" uniqueMembers="true" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_centro_custo" name="Centro de Custo">
<Hierarchy name="Centro de Custo" hasAll="true" allMemberName="Todos Centros de Custo" primaryKey="sk_centro_de_custo">
<Table name="dim_centro_de_custo" schema="Dimensional">
</Table>
<Level name="Centro de Custo" column="sk_centro_de_custo" nameColumn="codigo" type="Numeric" uniqueMembers="true" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_fatura" name="Fatura">
<Hierarchy name="Fatura" hasAll="true" allMemberName="Todas Faturas" primaryKey="sk_fatura">
<Table name="dim_fatura" schema="Dimensional">
</Table>
<Level name="Fatura" column="sk_fatura" nameColumn="nr_protocolo" type="String" uniqueMembers="true" levelType="Regular" hideMemberIf="Never">
<Property name="Fornecedor" column="fornecedor" type="String">
</Property>
78
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_cliente" name="Cliente">
<Hierarchy hasAll="true" allMemberName="Todos Clientes" primaryKey="sk_cliente">
<Table name="dim_cliente" schema="Dimensional" alias="">
</Table>
<Level name="Cliente" column="sk_cliente" nameColumn="nome" ordinalColumn="nome" type="String" uniqueMembers="true" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_operadora" name="Operadora">
<Hierarchy hasAll="true" allMemberName="Todas Operadoras" primaryKey="sk_operadora">
<Table name="dim_operadora" schema="Dimensional">
</Table>
<Level name="Operadora" column="sk_operadora" nameColumn="codigo" ordinalColumn="codigo" type="String" uniqueMembers="true" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="TimeDimension" foreignKey="dt_dia" name="Tempo">
<Hierarchy hasAll="true" allMemberName="Todos os Anos" primaryKey="dia">
<Table name="dim_tempo" schema="Dimensional" alias="">
</Table>
<Level name="Ano" column="ano" nameColumn="ano_nm" ordinalColumn="ano" type="String" uniqueMembers="false" levelType="TimeYears">
</Level>
<Level name="Trimestre" column="trimestre" nameColumn="trimestre_nm" ordinalColumn="trimestre" type="String" uniqueMembers="true" levelType="TimeQuarters">
</Level>
<Level name="Mes" column="mes" nameColumn="mes_nm" ordinalColumn="mes" type="String" uniqueMembers="false" levelType="TimeMonths">
</Level>
<Level name="Dia" column="dia" nameColumn="dia_nm" ordinalColumn="dia" type="String" uniqueMembers="true" levelType="TimeDays">
</Level>
79
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_entidade" name="Entidade">
<Hierarchy hasAll="true" allMemberName="Todas Entidades" primaryKey="sk_entidade">
<Table name="dim_entidade" schema="Dimensional" alias="">
</Table>
<Level name="Entidade" column="sk_entidade" nameColumn="sigla" ordinalColumn="sigla" type="String" uniqueMembers="true" levelType="Regular">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_inventario" name="Inventario">
<Hierarchy hasAll="true" allMemberName="Todos Inventarios" primaryKey="sk_inventario">
<Table name="dim_inventario" schema="Dimensional" alias="">
</Table>
<Level name="Inventario" column="sk_inventario" nameColumn="numero_inventario" ordinalColumn="numero_inventario" type="String" uniqueMembers="false" levelType="Regular">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_tipo_servico" name="Tipo Servico">
<Hierarchy hasAll="true" allMemberName="Todos Tipos Servico" primaryKey="sk_tipo_servico">
<Table name="dim_tipo_servico" schema="Dimensional" alias="">
</Table>
<Level name="Tipo Servico" column="sk_tipo_servico" nameColumn="numero" ordinalColumn="numero" type="String" uniqueMembers="false" levelType="Regular">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="sk_conta" name="Contas">
<Hierarchy hasAll="true" allMemberName="Todas Contas" primaryKey="sk_conta">
<Table name="dim_conta" schema="Dimensional">
</Table>
<Level name="Conta" column="sk_conta" nameColumn="conta" ordinalColumn="conta" type="String" uniqueMembers="false" levelType="Regular">
80
</Level>
</Hierarchy>
</Dimension>
<Measure name="Duracao" column="fato_duracao" aggregator="sum" visible="true">
</Measure>
<Measure name="Quantidade" column="fato_quantidade" aggregator="sum" visible="true">
</Measure>
<Measure name="Valor Original" column="fato_valor_original" aggregator="sum" visible="true">
</Measure>
<Measure name="Valor Rebilled" column="fato_valor_rebilled" aggregator="sum" visible="true">
</Measure>
<Measure name="Valor Retarifado" column="fato_valor_retarifado" aggregator="sum" visible="true">
</Measure>
</Cube>
</Schema>