-
FBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO
Desenvolvimento de um data warehouse para o processo de deciso em uma empresa de telecomunicaes
So Paulo 2009
-
2
FBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO
Desenvolvimento de um data warehouse para o processo de deciso em uma empresa de telecomunicaes
Monografia apresentada Escola Politcnica da Universidade de So Paulo para Concluso do Curso de
Engenharia de Computao
Orientador: Prof. Dr. Jorge Rady de Almeida Jr.
So Paulo 2009
-
3
-
4
-
5
FBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO
Desenvolvimento de um data warehouse para o processo de deciso em uma empresa de telecomunicaes
Monografia apresentada Escola Politcnica da Universidade de So Paulo para Concluso do Curso de
Engenharia de Computao
So Paulo 2009
-
6
ERRATA
PGINA LINHA ONDE SE L LEIA-SE
-
7
DEDICATRIA
A todas as pessoas que nos ajudaram diretamente ou indiretamente na
realizao deste trabalho.
-
8
AGRADECIMENTOS
Prof. Dr. Jorge Rady de Almeida Jr., pela orientao durante todo o
desenvolvimento do trabalho, e tambm pela compreenso nas fases onde a
dedicao ao trabalho no pode ser grande.
Toda a equipe da empresa In.voice que esteve envolvida com o sistema, por
disponibilizarem as informaes necessrias e por se colocarem a disposio 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 soluo de problemas da empresa In.voice, a empresa cliente deste projeto. O
grande problema abordado diz respeito manipulao de uma grande quantidade
de dados e, conseqentemente a perda de eficincia na gerao de relatrios que
utilizam bases de dados tradicionais. O uso de um data warehouse uma das
possveis solues para reduzir o tempo de resposta do sistema e apresentar as
informaes de maneira mais fcil de ser visualizada, assim, este trabalho prope a
modelagem e desenvolvimento da soluo baseada em data warehouse para a
empresa em questo.
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 ILUSTRAES
Figura 1 - Modelo Estrela Genrico ........................................................................... 27
Figura 2 - Interface de usurio do pgAdminIII ........................................................... 32
Figura 3 - Interface de Usurio do Pentaho Data Integration .................................... 33
Figura 4 - Interface de usurio do jPivot, acessando o servio OLAP do Mondrian .. 35
Figura 5 - Interface de usurio do Schema Workbench ............................................ 36
Figura 6 - Interface de usurio do Pentaho BI Studio ................................................ 37
Figura 7 Modelo dimensional modelado ................................................................. 41
Figura 8 - Modelo bsico de ETL de carga de dimenses ........................................ 44
Figura 9 - Modelos de ETL de carga de tabelas-fato (a) srie; (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 dimenses ................................................ 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 polticas de segurana. .......................................... 55
Figura 17 Execuo da ETL de carga de dimenses atravs da interface de
usurio. ..................................................................................................................... 56
Figura 18 Execuo da ETL de Fato atravs da ferramenta Pentaho Data
Integration. ................................................................................................................ 57
Figura 19 Anlise de dados armazenados no data warehouse. ............................. 58
Figura 20 Sada tpica de anlise de performance aps execuo de ETL pelo
Pentaho Data Integration .......................................................................................... 59
-
14
LISTA DE TABELAS
Tabela 1 - Especificao dos atributos da entidade Fato - Registro ......................... 42
Tabela 2 Variveis 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
SUMRIO
1. Introduo ........................................................................................................... 19
1.1 Objetivo ........................................................................................................ 19
1.2 Motivao ..................................................................................................... 19
1.3 Justificativa ................................................................................................... 19
1.4 Metodologia de trabalho ............................................................................... 20
1.5 Estrutura de trabalho .................................................................................... 21
1.6 Restries .................................................................................................... 22
2 Conceitos ............................................................................................................ 23
2.1 Ambiente Operacional .................................................................................. 23
2.1.1 Modelo ACID ......................................................................................... 23
2.1.2 Processamento de transao on-line .................................................... 24
2.2 Sistemas de Tomada de Deciso ................................................................ 24
2.2.1 Processamento analtico on-line ............................................................ 25
2.3 Data warehouse ........................................................................................... 25
2.3.1 Modelo Estrela ....................................................................................... 27
2.4 Siglas, Termos e Definies ......................................................................... 27
3 Aplicao ............................................................................................................ 30
3.1 Descrio do problema ................................................................................ 30
3.2 Idia para resoluo ..................................................................................... 30
3.2.1 Ferramentas .......................................................................................... 31
4 Etapas do projeto ................................................................................................ 38
4.1 Primeiros Passos ......................................................................................... 38
4.2 Anlise do banco de dados operacional....................................................... 38
-
17
4.3 Especificao de Requisitos ........................................................................ 39
4.3.1 Modelagem do banco de dados dimensional ........................................ 40
4.3.2 Extrao, Transformao 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 usurio .................................................................................... 53
5.1.1 Interface de usurio de carga de dados ................................................ 55
5.1.2 Interface de usurio de anlise de dados e relatrios ........................... 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 Consideraes finais........................................................................................... 61
6.1 Concluses .................................................................................................. 61
6.2 Contribuies ............................................................................................... 61
6.3 Trabalhos futuros ......................................................................................... 62
7 Referncias Bibliogrficas .................................................................................. 63
8 Anexos ................................................................................................................ 65
8.1 Anexo I ......................................................................................................... 65
8.2 Anexo II ........................................................................................................ 67
8.2.1 Anexo II.a - Tabela Dimenso Cliente ................................................... 67
8.2.2 Anexo II.b - Tabela Dimenso Operadora ............................................. 68
8.2.3 Anexo II.c - Tabela Dimenso Inventario ............................................... 69
8.2.4 Anexo II.d - Tabela Dimenso Tempo ................................................... 70
8.2.5 Anexo II.e - Tabela Dimenso Tipo de Servio ..................................... 71
-
18
8.2.6 Anexo II.f - Tabela Dimenso Centro de Custo ..................................... 72
8.2.7 Anexo II.g - Tabela Dimenso Unidade de Negocio .............................. 73
8.2.8 Anexo II.h - Tabela Dimenso Entidade ................................................ 74
8.2.9 Anexo II.i - Tabela Dimenso Contas .................................................... 75
8.2.10 Anexo II.j Tabela Dimenso Fatura ................................................. 76
8.3 Anexo III ....................................................................................................... 77
-
19
1. Introduo
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 deciso de uma
empresa de gesto em telecomunicaes.
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 informaes relevantes por meio de
relatrios.
1.2 Motivao
Um dos ativos mais importantes das empresas a informao (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 diferenciao, sendo que o data warehouse leva esse
benefcio empresa, pois permite que dados dos sistemas que esto em operao
em uma empresa sejam coletados e armazenados no decorrer do tempo, para ento
serem analisados pelos tomadores de deciso/steakholders de uma empresa. A
aplicao em telecomunicao se torna interessante ao passo que o volume,
granularidade e complexidade de dados neste setor so muito grandes quando se
procura registrar todos os eventos telefnicos de uma determinada regio por menor
que seja.
Atualmente, os sistemas baseados em data warehouse no so estudados
em cursos comuns de graduao em engenharia de computao, e, alm disso, no
meio empresarial, muitas empresas ainda utilizam solues proprietrias.
1.3 Justificativa
As justificativas para a realizao do trabalho so: a aplicabilidade prtica do
sistema; a ampliao de conhecimento para criao de alternativas para sistemas de
-
20
tomada de decises, baseadas em software de cdigo aberto; alm do aprendizado
devido utilizao de ferramentas no conhecidas por parte do grupo.
A possibilidade de utilizar software de cdigo aberto em um sistema de data
warehouse permite que o conhecimento na rea de Business Intelligence possa se
difundir, alm de criar uma alternativa de baixo custo para empresas que necessitam
de um sistema de tomada de decises.
O aprendizado dos conceitos tericos da construo de um data warehouse
realiza-se com maior facilidade quando os estudos so acompanhados de uma
aplicao prtica de tais conceitos (KIMBALL & ROSS, 2002). Portanto, pode-se
dizer que a aplicao deste trabalho objetiva a construo de um data warehouse
para uma empresa que atua no setor de gesto em telecomunicaes, a qual prov
servios 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 negcio da empresa no que diz respeito gesto em
telecomunicaes so 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 extrao de relatrios, uma vez que o
volume de dados muito grande da ordem de 40 milhes de registros mensais e
h necessidade de processamento destes dados para a gerao de relatrios que
auxiliam o entendimento e anlise dos gastos em telecomunicaes das empresas
que contratam o servio.
1.4 Metodologia de trabalho
A metodologia de desenvolvimento do sistema constituda das seguintes
etapas:
Estudo dos conceitos e ferramentas disponveis: Consiste principalmente
do estudo da teoria de data warehouse, analisando as aplicaes, os
pontos positivos e negativos, e estudo das ferramentas de cdigo aberto
disponveis para apoiar a criao de um sistema baseado em data
warehouse.
-
21
Anlise do Banco de Dados Operacional (Relacional): Anlise do banco de
dados relacional da empresa cliente, levantando os principais dados alvos
do projeto.
Elaborao dos requisitos: Levantamento dos principais requisitos do
sistema, de forma a delimitar o escopo e estabelecer a meta a ser
alcanada com o sistema.
Modelagem do banco de dados dimensional: Criao do modelo do banco
de dados dimensional, com o objetivo de alterar a modelagem dos dados
para a migrao para o data warehouse.
Carga de dados do ambiente operacional: Transporte de dados originrios
do ambiente operacional para a base dimensional de dados. Esta carga
realizada atravs de rotinas denominadas ETL Extract, Transform and
Load (conforme definido na seo 2.4).
Criao do data warehouse: Modelagem do Data warehouse utilizando a
ferramenta Mondrian e o modelo dimensional como base.
Gerao de relatrios: Compreende a modelagem de formas de se obter
das informaes e apresentao das mesmas para os usurios do
sistema.
Os documentos de andamento e a monografia foram elaborados
paralelamente s etapas descritas, bem como reunies com a empresa cliente.
1.5 Estrutura de trabalho
O captulo 1 contm uma introduo ao trabalho de concluso de curso,
apresentando o objetivo, motivaes, justificativas, a metodologia, a estrutura e as
restries do trabalho.
No captulo 2 so abordados os conceitos mais importantes que embasam o
trabalho.
O captulo 3 contm a descrio do problema, e o raciocnio para a resoluo
do mesmo, bem como as ferramentas utilizadas.
No captulo 4 so abordadas, de forma seqencial, todas as atividades
desenvolvidas desde o incio do projeto at sua concluso.
-
22
No captulo 5 so apresentados os resultados obtidos com o sistema
desenvolvido, e os testes realizados.
O captulo 6 contm as concluses, contribuies e trabalhos futuros
relacionados ao projeto.
1.6 Restries
As restries impostas inicialmente foram relativas s ferramentas a serem
utilizadas.
A fim de desenvolver a capacidade de buscar conhecimento de novas
tecnologias, uma das restries foi a utilizao de ferramentas de cdigo aberto para
a realizao do trabalho.
O projeto tambm teve como restrio a utilizao de um banco de dados
relacional especfico, 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 captulo contm os elementos tericos essenciais que envolvem um
sistema baseado em data warehouse.
2.1 Ambiente Operacional
O ambiente operacional tambm conhecido como ambiente transacional
o ambiente necessrio para o funcionamento do dia-a-dia da empresa (KIMBALL &
ROSS, 2002), normalmente composto por sistemas que operam sobre massas de
dados atravs de operaes transacionais (definidas na seo Processamento de
transao on-line - item 2.1.2). neste ambiente que as operaes de domnio da
empresa acontecem com foco em controle de processos de negcio.
Devido alta taxa de modificaes de dados, este ambiente otimizado para
este tipo de tarefa, e normalmente a base do ambiente operacional um banco de
dados relacional, cujos dados so inseridos, alterados, consultados ou removidos.
2.1.1 Modelo ACID
As preocupaes mais relevantes do ambiente operacional podem ser
resumidas nas propriedades ACID (sigla inglesa para Atomicity, Consistency,
Isolation, Durability):
Atomicity: As transaes que ocorrem na base de dados s devem ser
concludas com sucesso se todas as etapas que as compem forem
concludas com sucesso, caso uma falhe, a transao deve ser cancelada;
Consistency: A consistncia dos dados deve ser mantida, e, no caso da
tentativa de insero de um dado com tipo incorreto, a transao deve ser
cancelada;
Isolation: As transaes que ocorrem no banco de dados no interferem
entre si, ou seja, h um isolamento entre elas;
-
24
Durability: Os dados inseridos no sero perdidos, mesmo no caso de os
mesmos no serem acessados por um longo perodo.
O modelo caracteriza as operaes que ocorrem no nvel das aplicaes e
negcios da empresa.
2.1.2 Processamento de transao on-line
O processamento mais utilizado pelas empresas para tratar da manipulao
de dados (basicamente para insero, remoo, consulta e alterao 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 transao on-line pode ser resumido pelas
suas funcionalidades (BROWNING, 2001):
Suportar operaes de negcio em tempo real;
Otimizar transaes de insero ou consulta de linhas no banco de dados;
Otimizar a validao de dados;
Suportar milhares de usurios.
2.2 Sistemas de Tomada de Deciso
O desenvolvimento dos sistemas de informao comeou na dcada de 60
com os master files, arquivos que armazenavam informaes. E, com o passar do
tempo, a grande quantidade de arquivos de informao tornou esse mtodo de
armazenagem invivel (principalmente devido redundncia de informao e ao
elevado tempo de resposta), foi ento criado o modelo de base de dados (SGBD,
uma fonte de dados para todo processo) (INMON, 1996).
Com o advento dos PCs, mais usurios comearam a ter acesso aos dados, o
que culminou com a criao de transies online de alto desempenho. E,
posteriormente, os chamados programas de extrao, que apenas copiam os dados
de um sistema para outro segundo algum critrio. Esses programas de extrao
foram sendo utilizados cada vez mais, criando-se uma teia de informaes
(chamada de Arquitetura Evoluda Naturalmente), onde programas de extrao eram
utilizados em cima de outro programa de extrao, e assim sucessivamente. Mas
-
25
essa nova arquitetura gerou trs problemas principais: perda da credibilidade de
dados; produtividade; e impossibilidade de transformar dados em informaes
(INMON, 1996).
O data warehouse foi uma das alternativas criadas para resolver essa
questo devido suas caractersticas (conforme descrito na seo 2.3).
Atualmente, os sistemas de Tomada de Deciso, tambm conhecidos como
sistemas de apoio deciso (SADs), ajudam os gerentes de nvel mdio a tomar
decises no usuais (LAUDON & LAUDON, 2007). Sendo que o principal propsito
desses sistemas o de fornecer informaes sobre o negcio da empresa (ou
partes da mesma), e, atravs de relatrios, permitir analisar o desempenho corrente
da empresa (LAUDON & LAUDON, 2007).
O processo de anlise das informaes utiliza as informaes que so
inseridas atravs dos aplicativos da empresa. Pode-se perceber o problema que
surge, uma vez que a manipulao de dados e a consulta dos mesmos para a
gerao de relatrios causam uma sobrecarga. Naturalmente, imagina-se que a
melhor soluo separar os dados em dois ambientes, um destinado apenas para o
processamento operacional dos dados e outro para a consulta por parte da gerncia,
e exatamente isso que um sistema com data warehouse disponibiliza.
2.2.1 Processamento analtico on-line
O processamento analtico on-line (em ingls OLAP Online Analytical
Processing) utilizado por sistemas que tm como objetivo principal consultar uma
grande quantidade de dados e disponibiliz-los, para que possam ser analisados. O
OLAP permite a anlise multidimensional de dados, de forma que os usurios vejam
os mesmos dados de diferentes maneiras (LAUDON & LAUDON, 2007).
2.3 Data warehouse
O data warehouse um repositrio de dados centralizado, caracterizado por:
orientao ao assunto, variante no tempo, no voltil e integrado (INMON, 1996).
-
26
O ambiente operacional projetado com base nas aplicaes e funes 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 redundncia e incoerncia 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 informaes contidas nele
so referentes evoluo ao longo do tempo (usualmente em um perodo de alguns
anos), diferentemente dos dados no ambiente operacional, que representam os
dados mais recentes, e normalmente so utilizados em um perodo da ordem
somente poucos de meses (INMON, 1996).
A no volatilidade a caracterstica que diz respeito alta durabilidade da
base de dados, ou seja, o data warehouse permite que os dados sejam
armazenados de forma histrica ao longo de vrios (INMON, 1996).
A consistncia dos dados armazenados garantida ao passo que os dados
so somente carregados e acessados. As operaes de alterao e remoo de
dados so realizadas apenas no ambiente operacional. Assim, uma vez garantida a
consistncia da massa de dados carregada ao data warehouse, a consistncia dos
dados armazenados mantida independentemente da quantidade de vezes que os
dados do data warehouse so acessados.
De forma diferente dos dados do ambiente operacional necessrios para o
dia-a-dia da empresa os dados do data warehouse so voltados para a anlise e
tendncia (por isso diz-se que auxiliam no processo de tomada de decises).
Segundo (KIMBALL & ROSS, 2002), o data warehouse deve garantir algumas
propriedades. Entre elas:
Deve organizar as informaes tal que possam ser facilmente acessadas e
de forma consistente;
Deve ser facilmente adaptvel;
Deve garantir segurana de dados (do ingls security); e
Deve ser essencial para a tomada de deciso.
-
27
2.3.1 Modelo Estrela
O data warehouse baseado em modelagem multidimensional, deste modo,
h conceitos de informaes do tipo fato e do tipo dimenses. O primeiro deles diz
respeito informao que se deseja medir, normalmente so eventos temporais aos
quais se relacionam um nmero quantidade de unidades de produto vendidas,
receitas de uma venda e durao de uma ligao telefnica so exemplos claros de
informaes do tipo fato. O tipo dimenso refere-se aos dados que qualificam as o
evento retratado nome do produto, data da ocorrncia da venda e cliente
relacionado ao evento so exemplos de possveis dimenses.
O modelo estrela consiste em uma forma de modelagem do banco
dimensional, separando os dados em fatos e dimenses com relacionamentos
apenas do tipo fato-dimenso (dimenso-dimenso no possvel neste modelo),
este tipo de modelagem representado ilustrado pela Figura 1.
Figura 1 - Modelo Estrela Genrico
2.4 Siglas, Termos e Definies
As principais siglas, termos e definies que so utilizadas neste documento
so:
Banco/Base Operacional : Entidade de armazenamento de dados das
transaes que ocorrem no dia-a-dia da empresa.
-
28
Chave de negcio : (business key) o elemento identificador de um
registro que faz sentido no contexto do negcio da empresa.
Chave substituta : (surrogate key) um identificador atribudo a um
registro sem que tenha valor semntico no contexto do negcio da
empresa. Normalmente definem-se chaves substitutas para otimizar o
tempo de junes 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
repositrio centralizado que abrange toda a empresa. Sendo que ele
caracterizado por: orientao ao assunto, variante no tempo, no voltil e
integrado.
Drill-Through : Ato de alterar a visualizao de informaes para obter um
maior ou menor grau de detalhamento dos dados.
ETL (Extract, Transform and Load): So rotinas executadas
periodicamente que alimentam bases de dados a partir de uma ou mais
origens. Envolvem os trs 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, so utilizadas para o transporte de
informaes originrias do ambiente operacional para o banco
dimensional.
Linguagem MDX: Multidimensional Expressions uma linguagem
introduzida pela Microsoft em 1997 que prov sintaxes para a obteno e
manipulao de dados multidimensionais.
Matriz de Barramento: A matriz de barramento realiza o mapeamento das
reas de negcio da empresa, e as dimenses que so aplicadas a cada
uma dessas reas.
Metadados: Dados sobre dados, utilizados para funes relacionadas a
ETL, na transferncia de dados de OLPT para o data warehouse.
Modelo Dimensional : Modelagem especfica, onde dados numricos so
organizados de forma a serem agregados de acordo com suas
caractersticas em comum - dimenses.
-
29
Modelo Relacional: Modelagem especfica na qual as tabelas do banco
de dados mantm relaes entre si (atravs de chaves), modelando as
entidades reais do negcio da empresa.
OLAP (Online Analytical Processing ): Anlise de uma grande
quantidade de dados, normalmente executando operaes que no
alteram os dados do banco de dados (read-only).
OLTP (Online Transaction Processing ): Processo utilizado em
aplicaes orientadas a transaes, tais como os bancos de dados
relacionais convencionais, que utiliza operaes que podem alterar os
dados do banco de dados.
PostgreSQL: Sistema de Gerenciamento de Banco de Dados (SGBD).
Script SQL: Descrio passo-a-passo em linguagem SQL (Structured
Query Language) que define operaes de consulta, insero ou remoo
de dados de uma base de dados.
Tabela Dimenso: As tabelas dimenso so as tabelas "auxiliares", que
ficam ao redor da tabela fato (central), e contm os atributos de uma
dimenso do negcio.
Tabela Fato: A tabela fato a tabela central, que contm os fatos, valores
numricos, importantes para uma determinada rea do negcio.
-
30
3 Aplicao
3.1 Descrio do problema
O aplicativo da empresa In.voice que gera relatrios a partir de sua base de
dados operacionais comeou a apresentar problemas de desempenho depois que o
banco de dados relacional passou a ter uma quantidade muito grande de dados. O
aumento do nmero de clientes fez com que mais informaes fossem
armazenadas, conseqentemente o tempo demandado para a gerao de relatrios
cresceu de modo a inviabilizar algumas operaes no sistema.
Segundo informaes da diretoria da empresa In.voice os relatrios
demandavam um tempo de at 6 horas para serem gerados. Para ento serem
enviados para os respectivos clientes, embora a necessidade devesse ser atendida
no momento da requisio.
A idia era disponibilizar informaes em tempo hbil para os clientes atravs
de uma interface web. Mas, com a quantidade de tempo demandado para gerao
dos relatrios, isso era invivel at que esse problema fosse resolvido.
3.2 Idia para resoluo
O problema de desempenho apresentado pela empresa In.voice demonstra
que utilizar o ambiente operacional para levantar relatrios de anlise e suporte
pode comprometer o banco de dados relacional por um perodo, alm de no
responder em um tempo satisfatrio.
A idia principal separar os dois ambientes, para que um suporte os
processos e operaes do dia-a-dia da empresa, e o outro ambiente suporte o
levantamento de informaes para relatrios de anlise. Com isso surge a idia de
criar um data warehouse.
A empresa possui um banco de dados operacional, o que facilita a
implementao de um data warehouse, pois todos os dados inseridos j esto sendo
armazenados em meio digital.
-
31
3.2.1 Ferramentas
A criao do data warehouse foi feita em etapas. Sendo que em cada etapa
um determinado software (de cdigo aberto) foi essencial para auxiliar no processo.
Segue uma breve descrio 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 cdigo aberto. Ele suporta os principais tipos de operaes realizadas nos banco
de dados relacionais comuns, como criao de tabelas, chaves, relacionamentos,
entre outros.
O banco de dados utilizado pela empresa In.voice acessado atravs desta
ferramenta. E, atravs dela, foi criado o modelo dimensional.
A manipulao dos esquemas e tabelas pode ser realizado atravs do
PgAdmin III, um software de manipulao e manuteno do banco de dados cuja
interface de usurio ilustrada pela Figura 2.
-
32
Figura 2 - Interface de usurio do pgAdminIII
3.2.1.2 Pentaho Data Integration
O Pentaho Data Integration, chamado anteriormente de Kettle, a ferramenta
responsvel por extrair, transformar e carregar (em ingls, ETL) processos. O
objetivo a ser alcanado com a utilizao do Kettle automatizar a transformao
dos dados a partir do banco de dados relacional do usurio para o banco de dados
dimensional. Sua interface ilustrada pela Figura 3.
-
33
Figura 3 - Interface de Usurio do Pentaho Data Integration
A modelagem da ETL se d atravs do encadeamento de operaes menores
que realizam diversas aes sobre o fluxo de dados representado. Cada uma
dessas operaes representada por um bloco e o transporte de dados entre dois
blocos representado por uma flecha do bloco fornecedor ao bloco receptor. As
principais operaes desta ferramenta que sero utilizadas no desenvolvimento no
projeto so:
Table input (Entrada do tipo tabela): L o contedo 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
correspondncia quela do fluxo.
Table output (Sada do tipo tabela): Grava o contedo do fluxo em uma
tabela de um banco de dados relacional.
-
34
Lookup/Update Combination (Combinao de consulta e atualizao):
Realiza a consulta de um dado em uma base relacional, e compara seus
valores com o fluxo. Se houver mudana 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 servio de bases OLAP
atravs de interfaces web com outros aplicativos. Ele recebe como entrada um
arquivo XML definido pelo desenvolvedor do data warehouse e, atravs das
informaes contidas nele, realiza as agregaes de informaes contidas no
modelo dimensional utilizado.
O objetivo a ser alcanado com a utilizao do Mondrian a criao de um
data warehouse a partir do modelo de banco de dados dimensional previamente
modelado. O Mondrian um servio executado atravs de servidores de aplicaes
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 usurio do jPivot, acessando o servio OLAP do Mondrian
3.2.1.4 Schema Workbench
A modelagem do data warehouse baseada na definio em XML do modelo
multidimensional. Esta ferramenta auxilia esta edio, apresentando o documento
sob uma forma de rvore e lista as propriedades de cada um dos atributos em uma
lista, para cada um dos nveis da rvore. A Figura 5 ilustra sua interface de edio.
-
36
Figura 5 - Interface de usurio do Schema Workbench
3.2.1.5 Pentaho BI Studio
Esta ferramenta responsvel por integrar funcionalidades das demais
ferramentas integradas a um sistema web com suporte a definio de polticas de
segurana e grupos de usurios. Integra Mondrian (seo 3.2.1.3), Pentaho
Reporting e Pentaho Data Integration (seo 3.2.1.2). A interface de usurio
baseada em Web est ilutrada na Figura 6.
-
37
Figura 6 - Interface de usurio do Pentaho BI Studio
-
38
4 Etapas do projeto
4.1 Primeiros Passos
Em etapas iniciais de idealizao e definio do tema do projeto, havia a
preocupao em modelar e desenvolver uma aplicao de data warehouse para um
setor para o qual este tipo de modelagem fosse adequada, de modo que fosse
possvel obter resultados concretos de desempenho e ganho de eficincia
operacional, ao passo que se agilizava a capacidade analtica e performtica dos
relatrios utilizados. Neste foco, a melhor alternativa encontrada foi pesquisar um
caso problemtico real, segundo o qual fosse possvel retirar todas as concluses e
resultados desejados, comparando ganhos antes e depois da implantao da
aplicao atravs de depoimentos de usurios.
A empresa In.Voice se disps 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 reunies que possibilitaram o incio do projeto
com a anlise dos dados operacionais que, por sua vez, fez parte do levantamento
de requisitos do projeto, que definiu aspectos como escopo e restries no momento
inicial.
4.2 Anlise do banco de dados operacional
A empresa In.Voice apresentou o sistema de manipulao de informaes
que, alm de editar o contedo da base de dados, tambm utilizado para a
gerao de relatrios. Este sistema baseado em um modelo relacional
implementado sobre uma base de dados PostgreSQL 8 (conforme definido na seo
3.2.1.1).
O rpido crescimento da empresa e a desorganizao de projetos de
desenvolvimento do sistema mencionado, unidas complexidade das operaes de
negcio realizadas, fez com que a base incorporasse mais de 100 tabelas de dados
dispostas de maneiras muitas vezes redundantes e com normalizaes
-
39
inadequadas. O modelo representa o ambiente operacional do projeto de data
warehouse de onde se extraem os dados para alimentao da base dimensional.
O escopo do trabalho junto anlise de tal estrutura permitiu um refinamento
atravs de um processo de engenharia reversa o qual tomou como ponto de partida
os sistemas de gerao de relatrios para a conseqente anlise do fluxo de dados
e suas respectivas origens na base relacional, resultando na extrao da parcela
mais significativa (disponvel no Anexo I) para a modelagem dimensional e nas quais
as prximas etapas do projeto so baseadas.
No modelo refinado apresentado, pode-se observar o papel central sobre o
conjunto de tabelas Fatura e Inventrio, uma vez que estas entidades tm grande
importncia na anlise de custos em telecomunicaes das empresas, e uma vez
que o significado de negcio dos registros de Fatura so as consolidaes de
registros telefnicos em conjuntos limitados por data bem definida da ocorrncia do
evento. A tabela Inventrio representa o vnculo entre clientes e suas faturas. O
papel centralizador apresentou um caminho para a definio dos dados do tipo
Fato, cujas caractersticas principais esto em seus atributos temporais e
representaes numricas quantitativas. O processo de identificao descrito
posteriormente na etapa de levantamento de requisitos (seo 4.3).
4.3 Especificao de Requisitos
As reunies que se desencadearam aps o primeiro contato com a empresa
resultou no levantamento de requisitos do projeto de data warehouse, que por fim
levou criao do documento de Especificao de Requisitos, entregue como
produto final do primeiro quadrimestre de 2009 da disciplina PCS-2040 (Projeto de
Formatura I), porm, aps o final desta disciplina, novas reunies e redefinies do
negcio da empresa resultaram em algumas modificaes no modelo apresentado
que ser detalhado nos prximos itens.
O principal requisito da empresa era um sistema para gerao de relatrios
que respondesse em quantidade satisfatria de tempo. Assim, os principais aspectos
levantados foram:
a. Novo ambiente de gerao de relatrios (data warehouse);
-
40
b. Gerao de relatrios em tempo aceitvel;
c. Aumentar o ganho de informao de um relatrio;
d. Prover mtodos analticos mais eficientes.
O item a desta lista representa a independncia de um sistema de data
warehouse que no deve influenciar os sistemas em operao na empresa. Os itens
b, c e d apresentados acima so requisitos relacionados aos antigos sistemas
da empresa em operao. No item b da lista, o termo tempo aceitvel faz meno
ao tempo de gerao de um relatrio especfico de um cliente que varia de alguns
minutos a horas de tempo de espera. Para o item c espera-se que, uma vez que
relatrios sero gerados em tempos menores, possvel incluir mais informaes,
facilitando assim o cumprimento da funo bsica de relatrios que o auxlio na
tomada de decises. O item d representa o requisito de maior dinamismo no
sistema que, uma vez mais gil, possa oferecer mtodos analticos de dados mais
eficientes como recursos de drill-through em tabelas de dados.
Aps concludo o primeiro documento de especificao, modificaes
mostraram-se necessrias, dentre estas a principal diz respeito aos dados
armazenados no data warehouse cuja granularidade diminuiu, uma vez que o nvel
de detalhamento requisitado passou do nvel de faturas para o nvel de registros.
Esta modificao gerou um aumento na massa de dados tratados na proporo
dada pelo nmero mdio de registros por fatura, ou seja, cada dado de fatura passa
a inserir uma quantidade N de registros de telefonia, onde N o nmero mdio 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 identificao
dos dados que representam valores e quantidades relacionados a eventos discretos
no tempo e de papel central nas regras de negcio. Define-se, assim, dados do tipo
fato e, conseqentemente, a tabela fato com os diversos atributos do evento.
Caractersticas do evento de importncia relevante ao negcio e definio de
relatrios podem ser modeladas em dimenses junto aos seus respectivos atributos.
Uma vez concludas as tabelas, o esquema com as tabelas e relaes criado
atravs de um sistema gerenciador de banco de dados.
-
41
O diagrama representativo do modelo dimensional ilustrado pela Figura 7 e
cada uma das dimenses tem seus atributos detalhados no Anexo II. O mtodo
utilizado baseia-se no modelo estrela (conforme descrito na seo 2.3.1). Sua
vantagem est em sua simplicidade construtiva e velocidade de acesso aos atributos
de uma dimenso. Em contra partida, dados acabam tornando-se mais esparsos e o
nvel normalizao baixo. Como h poucas dimenses no projeto que possuem
mais de trs atributos, e o nmero de dimenses hierarquizadas pequeno, isto ,
no prejudica a normalizao 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 especificao 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 negcio denominada Registro, o qual, por sua vez,
representa a ocorrncia de uma chamada telefnica de um cliente e seus atributos
de negcio mais relevantes para o uso em relatrios. Esses atributos esto
enumerados e detalhados na tabela abaixo (apenas atributos relativos ao negcio
so detalhados nesta tabela).
Campo Tipo de dado Significado de Negcio
Dt_inicio_registro Data Representa a data de incio
da chamada telefnica
Dt_termino_registro Data Representa a data de
trmino da chamada
telefnica
Fato_duracao Decimal Representa o valor em
segundos da durao da
chamada telefnica
Fato_valor_original Decimal Representa o valor original
cobrado pela chamada sem
imposto.
Fato_valor_retarifado Decimal Representa o valor retarifado
da chamada telefnica.
Fato_valor_rebilled Decimal
Fato_quantidade Inteiro Representa a quantidade
Tabela 1 - Especificao dos atributos da entidade Fato - Registro
Ao modelo dimensional foram adicionadas colunas responsveis por fazer a
ligao entre os registros da tabela fato e suas dimenses quando aplicveis
(colunas identificadas com o prefixo sk_ em nosso modelo dimensional). Estas
colunas so chaves estrangeiras (termo definido na seo 2.4) que apontam para
chaves substitutas (surrogate keys, termo definido na seo 2.4), a importncia do
uso deste tipo de chaves (que no possuem significado de negcio) est em seu tipo
-
43
inteiro que torna a associao entre entidades mais gil e simples de ser tratada em
relao ao uso de chaves de negcio 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 unio (join) afeta diretamente a
etapa de carga de informaes ao data warehouse que, ao fazer pr-processamento
de dados, internamente realiza diversas vezes esta operao para obter dados sob
a forma adequada para ser armazenada em sua arquitetura interna.
4.3.1.2 Tabelas Dimenso
Assim como a tabela fato, o levantamento de requisitos levou s
especificaes das tabelas de dimenso. De forma geral as dimenses modeladas
foram:
dim_unidade_de_negocio : Dimenso da unidade de negcio.
dim_ centro_custo : Dimenso do centro de custo.
dim_ fatura : Dimenso da fatura.
dim_ cliente : Dimenso de cliente.
dim_ operadora : Dimenso da operadora.
dim_tempo : Dimenso de tempo.
dim_ entidade : Dimenso da entidade.
dim_ inventario : Dimenso do inventrio.
dim_ tipo_servico : Dimenso do tipo de servio.
dim_ conta : Dimenso da conta.
Os atributos das tabelas dimenso e seus significados de negcio esto no
anexo 8.2.
4.3.2 Extrao, Transformao e Carga
As ETLs foram divididas em dois grupos: ETLs das tabelas dimenso; e ETL
da tabela fato. Em teoria as ETLs so modeladas de forma a oferecerem um recurso
automatizado de extrair dados de fontes distintas; consolid-los sob um formato
padronizado e ento inseri-los em uma base centralizada. Esta idia 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 bsicos de carga em regras gerais que sero apresentados nas
sees 4.3.2.1 e 4.3.2.2. O primeiro deles voltado carga de tabelas-dimenses e
o segundo, carga de tabelas-fato.
4.3.2.1 ETL das tabelas dimenso
O Modelo de carga de Dimenses apresentado na Figura 8.
Figura 8 - Modelo bsico de ETL de carga de dimenses
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 informaes, a base dimensional deve ser atualizada a fim de
manter o contedo sincronizado entre ambos ambientes.
4.3.2.2 ETL da tabela fato
Em termos de linhas da tabela fato, deve existir uma ligao de cada um dos
registros com as respectivas dimenses, quando estas forem aplicveis. Porm, esta
ligao no explcita no momento em que ocorre a extrao desses dados, devido
s diferenas entre os modelos operacional e dimensional, uma vez que cada um
-
45
deles tm conceitos para identificadores diferentes. No modelo relacional tradicional
utiliza-se o conceito de chaves primrias, normalmente numricas e nicas para
cada registro, de forma similar, o modelo dimensional utiliza o conceito de chave de
negcio que por sua vez so mapeadas em colunas numricas surrogate keys
(definidas na seo 2.4) para otimizar a performance do banco, assim deve haver
um mapeamento entre ambas as chaves para se manter a consistncia entre elas.
Foram levantadas duas formas diferentes de realizar a carga da tabela fato:
buscas em srie ou buscas em paralelo. A Figura 9 ilustra ambos os modelos e suas
diferenas construtivas. No modelo em srie, aps a extrao dos dados, as buscas
por chaves substitutas ocorre linearmente uma aps a outra (Figura 9.a), aps o
termino das buscas insere-se o fluxo resultante no modelo dimensional; em contra-
partida, o modelo paralelo (Figura 9.b) realiza buscas simultneas de chaves
substitutas para ento realizar a juno do fluxo novamente para ento armazen-lo
na base dimensional.
O modelo utilizado para o desenvolvimento desta ETL o modelo de busca
em srie (Figura 9.a). Inicialmente o modelo em paralelo havia sido desenvolvido,
mas devido ocorrncia de deadlocks de acesso ao banco de dados no momento
das atividades em paralelo, optou-se pelo modelo em srie por evitar este tipo de
conflito embora oferea relativa perda de desempenho.
-
46
Extrao de
dados no modelo
operacional
Busca da PK da
dimenso 1
Busca da PK da
dimenso 2
Busca da PK da
dimenso n...
Unio dos fluxos
de dados
Insero dos
dados na base
dimensional
Modelo ETL: Carga da Fato (paralelo)
Extrao de
dados de registros
no modelo
operacional.
Busca da PK da
dimenso 1
Busca da PK da
dimenso 2
Busca da PK da
dimenso n
Insero dos
dados na base
dimensional
...
Modelo ETL: Carga da Fato (srie)
(a)
(b) Figura 9 - Modelos de ETL de carga de tabelas-fato (a) srie; (b) paralelo
4.3.3 Desenvolvimento da base multidimensional ( Data warehouse )
A modelagem em estrela, conforme previamente apresentado na seo 4.3.1,
coloca a tabela fato no centro do modelo e, relacionadas diretamente a ela, uma a
uma, as dimenses. 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 dimenses, cumprindo os objetivos do trabalho. Este mapeamento
realizado atravs da ferramenta Schema Workbench (apresentado na seo 3.2.1.4)
que gera um arquivo XML com a sintaxe entendida.
A etapa seguinte corresponde definio das hierarquias dimensionais e por
fim, o acabamento final de tratamento de formataes de dados e nomes de
campos.
Figura 10 Modelo Multidimensional no Schema Workbench.
A seguir, so especificadas os detalhes mais relevantes da modelagem
multidimensional do data warehouse.
-
48
4.3.3.1 Mtricas
As mtricas de um modelo multidimensional representam os dados dos
eventos do negcio em si. Normalmente so temporais e numricas, ou seja, tm
ocorrncia bem definida no tempo e representam entidades quantificveis no
negcio, possibilitando sua agregao em diversos nveis de detalhamento
utilizando-se funes matemticas de agregao (adio, contagem, mximo,
mnimo, entre outras).
Para o projeto em questo foram definidas como mtricas os valores a
respeito de uma chamada telefnica (entidade Registro):
Durao;
Quantidade;
Valor Original;
Valor Recobrado;
Valor Retarifado.
Valores que tm representatividade na criao de relatrios de tomada de
deciso para a empresa In.Voice.
4.3.3.2 Dimenses sem hierarquia
Dimenses simples, sem uma hierarquizao de seus membros, seguem a
um mesmo modelo em que a dimenso 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 dimenses, exceto da dimenso de tempo, possuem
essas caractersticas, uma vez que o nvel nico de detalhamento de cada uma das
dimenses suficiente para a gerao dos relatrios.
4.3.3.3 Dimenso de tempo
A hierarquizao de dimenso foi aplicada dimenso de tempo. Desta
forma, houve a hierarquizao da tabela dim_tempo em Ano > Trimestre > Ms >
Dia.
-
49
Figura 11 - Hierarquia de tempo definida
4.3.3.4 Granularidade
A granularidade temporal do modelo em questo segue a mesma
granularidade dos dados carregados do ambiente operacional da empresa, que do
nvel de registros telefnicos dirios. Desta forma, a granularidade permite uma
anlise profunda e possibilita tanto a anlise de registros dirios no nvel mais baixo,
quanto uma anlise macro que agrega dados por ms, trimestre ou ano; alm da
segmentao pelas demais dimenses como fatura ou centros de custo
relacionadas. Assim, os usurios desde a tomada de deciso gerencial (pontual)
tomada de deciso estratgica (mais abrangente) so atendidos pelo sistema.
4.4 Desenvolvimento das ETLs
Os fluxos de ETLs das tabelas dimenso so muito semelhantes, portanto foi
decidido que todas seriam agrupadas em duas ETLs, sendo que os fluxos seriam
executados paralelamente.
As dimenses 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 (seo 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 informaes importantes (sendo que cada dimenso teve
origem em uma tabela do modelo relacional);
2. Carga de dados da dimenso (Transform & Load): Os novos dados
devem ser comparados com os dados j existentes na dimenso a fim de
sincronizar ambas e evitar duplicidade de registros.
A Figura 12 ilustra os fluxos de ETL das dimenses.
Figura 12 - Diversos fluxos de carga das dimenses
A tabela dim_tempo pertence a uma ETL das dimenses, mas possui o fluxo
diferente. Isso ocorre pois, para a criao da tabela dim_tempo, foi utilizado um
arquivo CSV. O que difere esta dimenso das demais no contexto da ETL que a
entrada de dado feita no por um script SQL, mas sim por um arquivo do tipo CSV.
A ETL da tabela fato segue um fluxo diferente das ETLs das dimenses
(Figura 13). O fluxo o seguinte:
-
51
1. Entrada de dados (Extract): O mecanismo utilizado tambm foi o Table
Input (conforme definido na seo 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 dimenses,
uma vez que a tabela inicial possui todas as chaves de negcio que sero
trocadas por chaves substitutas;
2. Busca de Chaves (Transform): Para cada chave de negcio extrada,
deve-se saber a correspondente chave substituta, para isto, uma busca
baseada na chave de negcio deve ser realizada. Este tipo de busca
realizada pelo componente Lookup (detalhado em 3.2.1.2). Tm-se
ento, 9 etapas de lookup uma para cada dimenso.
3. Insero (Load): Cada um dos registros chega nesta etapa com seus
valores originais extrados 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 insero dos dados
realizado pelo componente Table output.
Figura 13 - ETL da Tabela fato_registro
-
52
Em termos de desempenho, utilizou-se o armazenamento temporrio em
memria cach em cada uma das etapas do fluxo, os resultados comparativos so
apresentados neste documento na seo 5.3.
4.5 Desenvolvimento do Data warehouse
O modelo multidimensional especificado na seo 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 definio de um
XML no formato reconhecido pelo Mondrian seguindo as especificaes do projeto.
Aps o incio do desenvolvimento, tomou-se conhecimento da ferramenta lanada
durante o desenvolvimento Schema Workbench que facilita a edio do XML atravs
de uma interface grfica.
Uma vez desenvolvido, o modelo deve ser publicado no Mondrian, isto feito
atravs da edio de um arquivo de configurao interno ferramenta e consiste na
edio das strings de conexo e definio dos dados apontados.
-
53
5 Resultados
5.1 Interfaces de usurio
A ferramenta Pentaho BI Studio contm 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
Aps a autenticao na tela de boas vindas, a tela de entrada do sistema,
ilustrada pela Figura 15, exibida. A partir desta tela possvel realizar todas as
operaes do ciclo do data warehouse:
Carga de dados atravs das ETLs;
Atualizao dos dados do repositrio;
Gerao e consulta de relatrios administrativos utilizando dados do data
warehouse;
Navegao analtica atravs das mtricas e dimenses do data
warehouse.
Em termos de segurana 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 polticas de segurana.
5.1.1 Interface de usurio de carga de dados
Para realizar a carga de dados, foram preparadas para os usurios duas
possibilidades: executar o pacote ETL utilizando a interface de usurio 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 ento a rotina se inicia. No momento do
trmino exibida uma tela com informaes do processo executado como sucesso
da operao e um conjunto de dados carregados para verificao rpida. A Figura 17
ilustra a tela de trmino de execuo.
Outro mtodo atravs da ferramenta Pentaho Data Integration, que possui
uma interface amigvel, porm com mais recursos de personalizao e relatrio de
desempenho. Para obter o pacote no h necessidade de busca entre os arquivos
do sistema, foi desenvolvido um repositrio onde a ferramenta consegue buscar as
rotinas de carga de forma imediata. A Figura 18 ilustra este mtodo de execuo.
-
56
Figura 17 Execuo da ETL de carga de dimenses atravs da interface de usurio.
-
57
Figura 18 Execuo da ETL de Fato atravs da ferramenta Pentaho Data Integration.
Alm destas duas formas de manter o sistema atravs de execues manuais
h possibilidade de agendar a execuo para uma data especfica ou de forma
recorrente.
5.1.2 Interface de usurio de anlise de dados e re latrios
A anlise de dados pode ser realizada atravs do componente nativo do
Mondrian jPivot. Sua interface ilustrada pela Figura 19.
-
58
Figura 19 Anlise 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 atravs do prprio mecanismo de
execuo da ferramenta Pentaho Data Integration. A ilustra uma sada tpica com
dados a respeito de uma execuo da ETL.
Figura 20 Sada tpica de anlise de performance aps execuo de ETL pelo Pentaho Data
Integration
Atravs destes dados, foram realizados testes de desempenho, alm dos
testes de consistncia de dados entre o ambiente operacional e a base dimensional
aps a execuo das ETLs.
5.2.2 Teste do data warehouse
O data warehouse foi testado atravs da interface padro do Mondrian, que
utiliza o componente jPivot. O teste consiste em comparao entre dados contidos
no ambiente operacional e os dados que o data warehouse. No caso, as agregaes
do data warehouse foram testadas uma a uma com amostras de dados que fossem
pertinentes aos mesmos filtros, e validades atravs da soma manual dos registros no
ambiente operacional para ento serem comparados entre si. Os recursos de drill-
through tambm so testados da mesma forma, com a diferena da comparao ser
realizada a cada drill-down realizado.
5.3 Desempenho
A partir da execuo de etapas isoladas e ciclos completos desde a carga de
dados e gerao de relatrios, a seguinte tabela pde ser levantada:
-
60
Varivel Medida Massa de dados
(registros)
Valor
(DW) Unidade de Medida
Tempo mdio de execuo das ETLs
de dimenso 1x106 27 Segundos
Tempo mdio de execuo da ETL de
tabela-fato 1x106 15,8 Minutos
Maior tempo medido para gerao da
tabela de dados analticos pelo jPivot 1x106 18 Segundos
Tempo mdio estimado para gerao
de relatrios de complexidade baixa. 1x106 30 Segundos
Tempo de ciclo completo mnimo
(soma) 1x106 17,05 Minutos
Tabela 2 Variveis de desempenho e resultados obtidos.
De acordo com a tabela, o tempo de execuo de ETLs foi de cerca de 16
minutos, este o tempo crtico para a disponibilidade dos dados, pois responsvel
por disponibiliz-los no data warehouse aps o devido processamento do modelo
dimensional realizado automaticamente pela ferramenta Mondrian. Com os dados
disponibilizados os tempos medidos so referentes gerao de relatrios, ou seja,
esto mais relacionados ferramenta de relatrio do que ao data warehouse em si.
Desta forma chega-se ao valor total de ciclo de aproximadamente 17 minutos.
A ttulo de comparao levantou-se o dado de desempenho dos sistemas
atuais da empresa In.Voice para um ciclo: um relatrio de cerca de 10 milhes de
registros leva em mdia 6 horas para ser gerado. Assim, pela anlise dos dados de
maneira qualitativa, o ganho em desempenho percebido pelo usurio foi alto.
-
61
6 Consideraes finais
6.1 Concluses
O ambiente competitivo em que as empresas se encontram atualmente revela
a grande necessidade de possuir diferenciais no momento da tomada de decises
responsveis 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 analtica dos
estrategistas que por sua vez podem destacar suas empresas ao tomar as decises
de sucesso.
Nota-se um sensvel crescimento do mercado que envolve tecnologias de
auxlio estratgico, 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 eficincia na aquisio de dados atravs de
tecnologias OLAP. Com este tipo de crescimento, desenvolvem-se tambm todas as
demais atividades relacionadas s etapas do projeto de data warehouses, como a
integrao de dados, definio de processos estruturados, definio de dados
estratgicos, definio de mtodos de anlise de dados, dentre outras.
Uma vez com a especificao pronta e validada, inicia-se o desenvolvimento
do projeto. O ciclo de vida de desenvolvimento de um data warehouse difere do
modelo clssico (requisitos, anlise, desenvolvimento, testes e implantao), o novo
modelo mais iterativo, partindo da criao de um primeiro data warehouse, e s
depois ocorre um entendimento dos requisitos (INMON, 1996). Isso no reduz a
importncia da especificao, mas deixa subentendido que novas verses da
especificao sero necessrias por conta de eventuais alteraes.
6.2 Contribuies
As contribuies que o sistema deixa para o futuro uma aplicao prtica de
data warehouse que vai ajudar principalmente a empresa In.voice a solucionar o
problema de gerao de relatrios, e vai ser utilizado como base para um
remodelamento do banco de dados operacional.
-
62
Outra contribuio importante a monografia, que foi escrita de maneira a
fornecer uma viso 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 cdigo aberto, sendo til para qualquer pessoa que
necessite de referncias em lngua 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 cdigo aberto nunca antes utilizadas pelos membros
do grupo , e culminando na realizao do projeto, que envolveu reunies com a
empresa In.voice e sua implementao. Tudo isso contribuiu para um importante
crescimento acadmico prtico e para consolidar muitos assuntos vistos ao longo do
curso de graduao.
6.3 Trabalhos futuros
O sistema baseado em data warehouse foi totalmente desenvolvido e testado
utilizando uma cpia do banco de dados da empresa In.voice. Apesar de essa etapa
ter sido concluda com sucesso, outros trabalhos futuros podem ser desenvolvidos a
partir deste.
A aplicabilidade prtica pode ser traduzida na utilizao que o sistema ter na
empresa cliente com a implementao 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 repositrio
central e foi baseado em apenas uma tabela fato e modelo estrela. Portanto, como
contribuio terica e prtica para este trabalho, possveis sugestes so:
Desenvolvimento do conceito e da aplicao de um sistema baseado em
data warehouse com diversos data marts, atendendo setores distribudos
em uma empresa;
Desenvolvimento de um data warehouse utilizando o modelo snowflake.
Desenvolvimento de um sistema utilizando data mining para analisar as
tendncias das informaes contidas no data warehouse desenvolvido.
-
63
7 Referncias Bibliogrficas
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 informao gerenciais . 7a
Ed. So Paulo: Pearson Prentice Hall, 2007.
TUERK, Miriam. The Open Source Data warehouse Revolution . Artigo sobre data
warehouse desenvolvidos com tecnologia de cdigo aberto. Disponvel em
. Acesso em:
28 nov 2009.
Sourceforce.Net. Documentao do PostgreSQL 8.0.0 . Documentao traduzida
sobre PostgreSQL verso 8.0.0 pela comunidade Sourceforce.Net. Disponvel em
. Acesso em: 28 nov 2009.
Pentaho Community. Latest Pentaho Data Integration (aka Kettle)
Documentation . ltima documentao atualizada disponvel sobre o aplicativo Data
Integration da Pentaho Open Source Business Intelligence. Disponvel em
. Acesso em: 28 nov 2009.
Pentaho Open Source Business Inteligence. Mondrian Overview . Documentao
sobre o aplicativo Mondrian da Pentaho Open Source Business Intelligence.
-
64
Disponvel em . 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. Disponvel em . Acesso em: 28 nov 2009.
About.com Databases. The Acid Model . Descrio sucinta sobre o modelo ACID.
Disponvel em . Acesso
em: 28 nov 2009.
BROWNING, Dave; MUNDY, Joy. Data warehouse Design Considerations .
Consideraes na construo de um data warehouse. Disponvel em
. 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 Dimenso Cliente
-
68
8.2.2 Anexo II.b - Tabela Dimenso Operadora
-
69
8.2.3 Anexo II.c - Tabela Dimenso 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 Dimenso 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 Dimenso Tipo de Servio
-
72
8.2.6 Anexo II.f - Tabela Dimenso 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 Dimenso Unidade de Negoc io
-
74
8.2.8 Anexo II.h - Tabela Dimenso Entidade
-
75
8.2.9 Anexo II.i - Tabela Dimenso Contas
-
76
8.2.10 Anexo II.j Tabela Dimenso Fatura
-
77
8.3 Anexo III
Xml interpretado pelo Mondrian para instanciar o data warehouse
-
78
-
79
-
80
