Artigo OLAP e DM Comercial

CENTRO UNIVERSITRIO FEEVALE
EDMILSON J. W. FELBER
PROPOSTA DE UMA FERRAMENTA OLAP EM UM DATA MART

COMERCIAL: UMA APLICAO PRTICA NA INDSTRIA
CALADISTA
Novo Hamburgo, novembro de 2005.
EDMILSON J. W. FELBER
PROPOSTA DE UMA FERRAMENTA OLAP EM UM DATA MART

COMERCIAL: UMA APLICAO PRTICA NA INDSTRIA
CALADISTA
Centro Universitrio Feevale

Instituto de Cincias Exatas e Tecnolgicas
Curso de Cincia da Computao
Trabalho de Concluso de Curso
Professor orientador: Juliano Varella de Carvalho
Novo Hamburgo, novembro de 2005.
Agradecimentos
Agradeo a todos que me apoiaram,
principalmente ao meu orientador, Juliano
Varella de Carvalho, que acrescentou o seu
conhecimento para o enriquecimento desse
trabalho.
RESUMO
No contexto econmico atual, onde a competio entre as empresas est cada vez
mais relacionada sua capacidade de transformar informao em conhecimento e este ltimo
em decises e aes de negcio, o Data Warehouse (DW) exerce um papel fundamental como
ferramenta de apoio aos processos de tomada de deciso. Contudo, para que se possa tirar
vantagem dos recursos de informao de forma satisfatria, cada vez mais imperativo que as
empresas otimizem e dem mais nfase qualidade durante o processo de tomada de deciso.
Neste contexto, so empregados ferramentas e conceitos que organizam as
informaes de negcios das empresas. Dentre estes conceitos e ferramentas, alm do DW,
destacam-se tambm, Data Mart (DM), Business Intelligence (BI), modelagem dimensional e
ferramentas OLAP, que constituem os pilares estratgicos dos Sistemas de Apoio a Deciso
(SAD).
O presente trabalho apresenta uma proposta de criao de um DM e uma ferramenta
OLAP para a anlise das informaes do departamento comercial de uma indstria caladista.
A construo da soluo ser baseada em softwares de distribuio gratuita e/ou Open Source.
Para tanto, o texto do trabalho aborda os conceitos sobre as tecnologias relacionadas.
Por fim, feita uma descrio das principais caractersticas das ferramentas
Mondrian, Jpivot, OpenI e Pentaho, visando escolher aquelas mais adequadas ao
desenvolvimento da soluo proposta.
Palavras-chave: Sistemas de Informao, Sistema de Apoio Deciso, Data

Warehouse, Data Mart, Modelagem Dimensional, OLAP.
ABSTRACT
In the current economic context, where the competition between the companies is
each time more related to its capacity to transform information into knowledge and after to
transform this knowledge in decisions and action of business, Data Warehouse (DW) exerts a
basic paper as tool of support to the processes of decision-making. However, to take off
advantage of the resources of information of satisfactory form, it is necessary that the
companies optimize and give more emphasis in the quality to the process of decision-making.
In this context, tools and concepts are used to organize the business-oriented
information of the companies. Amongst these concepts and tools, it can be cited, beyond DW,
Data Mart (DM), Business Intelligence (BI), dimensional modeling and OLAP tools, that
constitute the strategical pillars of the Decision Support System (DSS).
The present work shows a proposal of a DM creation and a OLAP tool for analysis
of information of a shoe industry commercial department. The development of the solution
will be based on free and/or Open Source software. So, the work's text approaches the
concepts on the related technologies.
Finally, a description of the main characteristics of the tools Mondrian, Jpivot, OpenI
and Pentaho is made, aiming at to choose the solution more adequate to the development of
the solution proposal.
Keywords: Information Systems, Decision Support System, Data Warehouse, Data

Mart, Dimensional Modeling, OLAP.
LISTA DE FIGURAS
Figura 1.1 Componentes de um ambiente BI............................................................................17

Figura 1.2 Definio do DW.....................................................................................................19
Figura 1.3 Ambiente operacional X DW.................................................................................. 19
Figura 1.4 Granularidade dos dados......................................................................................... 21
Figura 1.5 DW X DM............................................................................................................... 22
Figura 1.6 Extrao, transformao e carga de dados...............................................................25
Figura 2.1 Exemplo de tabela de fatos...................................................................................... 31
Figura 2.2 Exemplo de tabela de dimenso.............................................................................. 32
Figura 2.3 Exemplo de tabela de agregados............................................................................. 33
Figura 2.4 Modelo Star Schema................................................................................................33
Figura 2.5 Modelo Snowflake................................................................................................... 34
Figura 2.6 Cubo de dados......................................................................................................... 35
Figura 2.7 Arquitetura MOLAP................................................................................................39
Figura 2.8 Arquitetura ROLAP.................................................................................................39
Figura 2.9 Arquitetura HOLAP................................................................................................ 40
Figura 2.10 Arquitetura DOLAP.............................................................................................. 40
Figura 2.11 Arquitetura WOLAP..............................................................................................41
Figura 3.1 Instruo MDX........................................................................................................ 44
Figura 3.2 Retorno de uma consulta MDX............................................................................... 44
Figura 3.3 Arquitetura do Mondrian.........................................................................................45
Figura 3.4 Exemplo de arquivo XML definindo um Schema................................................... 47
Figura 3.5 Definio de um cubo..............................................................................................47
Figura 3.6 Definio de medidas.............................................................................................. 48
Figura 3.7 Definio de dimenses, hierarquias e nveis..........................................................48
Figura 3.8 Definio de membros calculados........................................................................... 49
Figura 3.9 Retorno de uma consulta pelo Jpivot.......................................................................51
7
Figura 3.10 Arquitetura do OpenI.............................................................................................53
Figura 3.11 Arquitetura do Pentaho......................................................................................... 54
LISTA DE QUADROS
Quadro 1.1 Diferenas entre o ambiente operacional e DW...................................................20
LISTA DE ABREVIATURAS E SIGLAS
API
Application Programming Interface
BI
Business Intelligence
BD
Banco de Dados
DM
Data Mart
DOLAP
Desktop On-Line Analytical Processing
DW
Data Warehouse
ER
Modelo Entidade-Relacionamento
HOLAP
Hybrid On-Line Analytical Processing
J2EE
Java2 Plataform Enterprise Edition
JSP
Java Server Pages
MDX
Multidimensional Expressions
MOLAP
Multidimensional On-Line Analytical Processing
OLAP
On-Line Analytical Processing
OLTP
On-Line Transaction Processing
RDBMS
Relational Data Base Management System
ROLAP
Relational On-Line Analytical Processing
SAD
Sistemas de Apoio Deciso
SGBD
Sistema de Gerenciamento de Banco de Dados
SQL
Structured Query Language
TI
Tecnologia de Informao
WCF
Web Component Framework
WWW
World Wide Web
WOLAP
Web On-Line Analytical Processing
XML
eXtensible Markup Language
XMLA
XML for Analysis
SUMRIO
INTRODUO........................................................................................................................ 13
1 SISTEMAS DE APOIO DECISO (SAD)......................................................................16
1.1 Data Warehouse (DW)..................................................................................................18
1.1.1 Caractersticas de um DW..................................................................................... 18
1.1.2 Diferenas entre o Ambiente Operacional e o Ambiente DW.............................. 19
1.1.3 Granularidade........................................................................................................ 20
1.2 Data Mart (DM)............................................................................................................22
1.2.1 Abordagens de construo do DM........................................................................ 23
1.2.2 Tipos de Arquitetura do DM / DW........................................................................23
1.3 Metadados..................................................................................................................... 24
1.4 Data Staging Area extrao, transformao e carga de dados................................... 25
1.4.1 Extrao................................................................................................................. 26
1.4.2 Transformao de dados........................................................................................ 26
1.4.3 Carga de dados.......................................................................................................27
2 A MODELAGEM DIMENSIONAL.................................................................................... 29
2.1 Tabela de fatos ..............................................................................................................30
2.2 Tabela de Dimenso...................................................................................................... 31
2.3 Agregados......................................................................................................................32
2.4 Tcnicas de Modelagem................................................................................................33
2.4.1 Star Schema........................................................................................................... 33
2.4.2 Snowflake...............................................................................................................34
2.5 Cubo de dados .............................................................................................................. 34
2.6 OLAP.............................................................................................................................36
2.6.1 Operaes OLAP................................................................................................... 37
2.6.2 Arquiteturas OLAP................................................................................................38
2.6.3 Tendncias............................................................................................................. 41
12
3 FERRAMENTAS OLAP...................................................................................................... 43
3.1 Mondrian....................................................................................................................... 43
3.1.1 Linguagem MDX..................................................................................................43
3.1.2 Arquitetura do Mondrian.......................................................................................44
3.1.3 Estratgia de armazenamento e agregao............................................................ 45
3.1.4 Mondrian Schema..................................................................................................46
3.1.4.1 Cubos............................................................................................................. 47
3.1.4.2 Medidas..........................................................................................................48
3.1.4.3 Dimenses, hierarquias, nveis e membros....................................................48
3.2 Jpivot............................................................................................................................. 49
3.2.1 WCF.......................................................................................................................49
3.2.2 Arquitetura.............................................................................................................50
3.3 OpenI............................................................................................................................. 51
3.4 Pentaho .........................................................................................................................53
CONCLUSO ......................................................................................................................... 56
REFERNCIAS BIBLIOGRFICAS .....................................................................................57
INTRODUO
Desde o incio da era computacional, as organizaes tm usado os dados de suas

bases operacionais para atender as necessidades de informaes. Nesta situao, alm da
dificuldade de encontr-los, diversas vezes, dados inconsistentes so utilizados como base
para tomada de decises importantes.
Uma das grandes dificuldades das empresas o gerenciamento dos dados oriundos
de diversos sistemas do ambiente operacional. Grandes bases de dados so criadas pelo
acmulo de informaes resultantes de operaes transacionais, pouco aproveitadas pelos
responsveis pelas tomadas de decises, devido a complexidade de extrao das mesmas.
Agrupar essas informaes, interpret-las e tirar concluses, no uma tarefa fcil. preciso
extrair de cada base de dados, as informaes que realmente interessam e padroniz-las para
que possam ser analisadas.
As aplicaes para suporte de tomadas de deciso, baseadas em DW, podem tornar
mais prtica e fcil a explorao dos dados visando uma maior eficcia do negcio. Isto o
oposto de utilizar somente os dados provenientes das aplicaes operacionais, os quais
ajudam nas operaes da empresa, em suas atividades dirias, mas que tornam complexa a
obteno de informaes para uso gerencial.
Segundo Inmon (1997, p. 33), [...] Data warehouse um conjunto de dados baseado
em assuntos, integrado, no-voltil, e varivel em relao ao tempo, de apoio s decises
gerenciais" [...].
A criao de um DW requer tempo, capital e um considervel esforo gerencial. Por
estes motivos, em diversas situaes, as empresas iniciam o projeto de DW focando nas
necessidades de reas especficas dentro da organizao. Estas estruturas menores de
armazenamento de dados so chamadas Data Marts (DM). Um DM um pequeno DW que
fornece suporte a um nmero reduzido de pessoas, com uma viso mais especializada e
14
limitada dos dados.
Singh (2001, p. 14) define DM como sendo um subconjunto do data warehouse
empresa-inteira. Tipicamente, desempenha o papel de um data warehouse departamental,
regional ou funcional [...].
Atualmente, diversas empresas optam pelo DM por causa do seu custo mais baixo e
do tempo menor de implementao da soluo e, alm disto, estes podem servir como um
laboratrio de teste quelas empresas que desejam investigar e explorar os benefcios do DW.
A idia, via DW, armazenar os dados em vrios graus de
relacionamento e sumariao, de forma a facilitar e agilizar os
processos de tomada de deciso por diferentes nveis gerenciais. [...]
Esses dados, oriundos de sistemas de informao de produo,
devero estar mastigados, integrados e disponveis, permitindo
diversas formas de consultas, atravs dos mecanismos amistosos das
ferramentas de usurios (BARBIERI, 2001, p. 51).
Dentre estas ferramentas, destaca-se a tecnologia denominada OLAP - On-line
Analytical Processing, que se caracteriza por transformar dados em informaes eficientes,
dinmicas e flexveis. O Conselho OLAP1, apud Inmon et al. (1999, p.175), define esta
tecnologia como [...]categoria da tecnologia de software que permite que analistas, gerentes
e executivos obtenham, de maneira rpida, consistente e interativa, acesso a uma variedade de
visualizaes possveis de informaes que foi transformada de dados puros para refletir a
dimenso real do empreendimento do ponto de vista do usurio".
O objetivo de uma ferramenta OLAP transformar dados em informaes capazes
de dar suporte a decises gerenciais de forma flexvel e em tempo hbil. Assim, OLAP
precisa oferecer informaes existentes, oportunas, precisas e inteligveis (THOMSEN, 2002,
p. 8).
Conforme Bispo (1998), as ferramentas OLAP permitem aos usurios analisar os
dados em vrias dimenses, como regio, produto, tempo e vendedor. Cada dimenso tambm
pode conter hierarquias, por exemplo, a dimenso tempo pode conter as hierarquias ano,
semestre, ms, semana ou dia. Pode-se navegar livremente de uma hierarquia para outra, at
chegar-se na mxima granularidade dos dados.
O Conselho OLAP (OLAP Council) uma organizao sem fins lucrativos, patrocinada por vrios
fornecedores de ferramentas OLAP, cujo objetivo promover a educao sobre a tecnologia OLAP.
15
Uma das caractersticas das solues proprietrias das ferramentas de anlise
baseadas em DW / DM o alto custo da implementao destas solues, o que, na maioria
das vezes, torna proibitivo a sua utilizao em pequenas, mdias e em certas situaes at em
grandes empresas.
De acordo com Grimes (2005), este universo est comeando a ser descoberto pelo
movimento Open Source, fato esse que fornecer ferramentas para que os desenvolvedores de
aplicaes ofeream a seus clientes, solues de gesto de informao com qualidade a um
custo razovel. (Traduo nossa).
Considerando as tecnologias apresentadas, este trabalho prope o desenvolvimento
de um SAD composto por um DM e uma ferramenta OLAP para a anlise das informaes do
departamento comercial de uma indstria caladista, utilizando ferramentas de distribuio
gratuita e/ou Open Source. Desta forma, espera-se que o mesmo agregue valor organizao,
provendo uma soluo vivel em termos de qualidade e custo para o auxlio tomada de
decises gerenciais.
Nesse trabalho de concluso I, sero feitos o embasamento terico e a escolha das
ferramentas que sero utilizadas no desenvolvimento da soluo. A implementao da soluo
ser concluda durante o trabalho de concluso II.
Esse trabalho composto de trs captulos. No primeiro e segundo captulos, so
abordados os conceitos que embasam o trabalho. No terceiro captulo, so descritas as
caractersticas das ferramentas OLAP, visando escolher aquelas mais adequadas ao
desenvolvimento da soluo proposta.
1 SISTEMAS DE APOIO DECISO (SAD)
Para competir em um mercado globalizado, as empresas necessitam cada vez mais

deter conhecimento sobre os seus clientes, mercados, tecnologias e processos. Ter
informaes disponveis uma ferramenta poderosa para quem necessita tomar decises e,
tendo em vista esse princpio, as empresas comearam a extrair dados dos seus sistemas
operacionais e armazen-los separadamente em um ambiente com a finalidade de prover
informaes para o auxlio tomada de decises.
Segundo Inmon (1997), os SADs tiveram seu incio na dcada de 1960. Neste
perodo, o processamento era feito em aplicaes baseadas em relatrios e programas. Com os
anos, na medida em que o volume de dados foi crescendo, a tarefa de anlise dos mesmos se
tornou bastante complexa e trabalhosa.
Com a crescente evoluo da tecnologia e o armazenamento de dados em disco,
surgiram os Sistemas Gerenciadores de Bancos de Dados (SGBD), com o objetivo de facilitar
o armazenamento e o acesso aos dados. Porm, mesmo com as facilidades trazidas pelos
SGBDs, o volume de dados continuava crescendo e, como no havia o devido planejamento
no armazenamento das base de dados, sua compreenso se tornava cada vez mais complexa.
Atualmente estes SGBDs armazenam uma quantidade muito grande de dados, mas as
ferramentas de anlise destes dados no evoluram na mesma velocidade que a tecnologia
utilizada para armazen-los (MAZETTO, 2004).
Todos esses problemas enfrentados no passado, e que hoje ainda desafiam muitos
profissionais de Tecnologia de Informao (TI), tem origem no fato de que, tradicionalmente,
o foco da tecnologia da computao tem sido em automatizar tarefas rotineiras e melhorar a
eficincia de processos existentes (MAZETTO, 2004).
Os sistemas de produo de uma empresa recuperam e atualizam um registro por
vez, normalmente atendendo a muitos usurios de forma concorrente, exigindo tambm um
17
tempo de resposta muito baixo. J os SADs, usualmente lidam com poucos usurios por vez e
os requisitos em termos de tempo de resposta podem no ser crticos. No entanto, geralmente
lidam com consultas complexas, no antecipadas ou previstas, envolvendo grande quantidade
de registros referentes aos processos operacionais da empresa (CAMPOS; FILHO 2005).
Os SADs visam atender as necessidades dos executivos de uma organizao, quanto
obteno de informaes para a tomada de deciso. O SAD estruturado de forma a atender
os diferentes nveis de conhecimento das pessoas que o acessam. Geralmente, os resultados
das pesquisas so demonstrados atravs de grficos e tabelas, sendo que as informaes
apresentadas tm alto ndice de valor agregado.
O termo SAD, propriamente dito, tem sido utilizado cada vez menos, tanto em livros
e revistas quanto em Websites na internet. No seu lugar tem sido cada vez mais freqente o
uso do termo Business Intelligence (BI). BI um conceito empregado a ferramentas,
tecnologias e metodologias, que tem como objetivo fornecer informaes estratgicas, que
apiam na tomada de deciso.
Segundo Barbieri (2001, p. 5), BI representa a habilidade de se estruturar, acessar
e explorar informaes, normalmente guardadas em DW/DM (Data Warehouse Data Mart),
com o objetivo de desenvolver percepes, entendimentos, conhecimentos, os quais podem
produzir um melhor processo de tomada de deciso.
BI a utilizao de uma srie de ferramentas para coletar, analisar e extrair
informaes, que sero utilizadas no auxlio ao processo de gesto e tomada de deciso. A
Figura 1.1 mostra os principais componentes deste ambiente.
Figura 1.1 Componentes de um ambiente BI.

Fonte: Adaptao do autor segundo (BARBIERI, 2001).
18
O objetivo do BI transformar no s dados em informaes, mas principalmente
em conhecimento, suportando o processo decisrio, com o objetivo de gerar vantagens
competitivas. Este termo foi criado pelo Gartner Group1 nos anos 80 (WIKIPEDIA, 2005).
Aps uma melhor compreenso do que representa um SAD e da sua evoluo, a
seguir sero abordados os conceitos que fazem parte deste universo.
1.1 Data Warehouse (DW)
Conforme Fortulan; Filho (2005), ao longo do tempo, os bancos de dados foram
desenvolvidos para fins de processamentos de dados operacionais e analticos, havendo maior
nfase no primeiro caso, ainda que ambos tivessem usurios com diferentes necessidades.
Uma vez compreendida essa diferena, foram criados bancos de dados separados para fins
analticos, chamados de DW.
O DW oferece os fundamentos e os recursos necessrios para uma estrutura de BI
eficiente, fornecendo dados integrados e histricos que servem desde a alta direo, que
necessita de informaes mais resumidas, at as gerncias de baixo nvel, onde os dados
detalhados ajudam a observar aspectos mais tticos da empresa.
1.1.1 Caractersticas de um DW
Segundo Inmon (1997, p. 33), [...] Data warehouse um conjunto de dados baseado
em assuntos, integrado, no-voltil, e varivel em relao ao tempo, de apoio s decises
gerenciais" [...]. Por estas caractersticas, de acordo com Singh (2001), entende-se:
Baseado em assuntos: Significa que o DW foca as principais entidades do negcio.
Integrado: Significa que os dados esto armazenados em formato consistente (ou
seja, especificando convenes, restries de domnio, atributos fsicos e medies).
No voltil: Significa que os dados no se alteram depois de includos no DW. Os
novos dados so adicionados ao DW, integrando-se com queles previamente armazenados.
Variante no tempo: Significa que os dados esto associados a um ponto no tempo,
como por exemplo, ano, semestre, ms, trimestre, perodo de pagamento, etc...
1
Consultoria de pesquisas de mercado na rea de tecnologia da informao. GARTNER. Gartner Group.

Disponvel em: <http://www.gartner.com>. Acesso em: 26 ago. 2005.
19
Figura 1.2 Definio do DW.

Fonte: (INMON, 1997).
1.1.2 Diferenas entre o Ambiente Operacional e o Ambiente DW

O ambiente operacional composto por sistemas que tm como finalidade
automatizar e suportar as principais atividades do dia-a-dia de uma empresa, e que geram um
alto volume de transaes. Estes sistemas so chamados de sistemas OLTP (On-Line
Transaction Processing). Por esta razo, os sistemas que compem este ambiente devem ter
alto desempenho e tempos de respostas baixos, visto que isto causa impacto diretamente na
eficincia dos processos da empresa. Os dados operacionais so parte da infra-estrutura
corporativa: so detalhados, atualizveis e no-redundantes (COSTA; ANCIES, 2001).
Por outro lado, o ambiente de DW foi projetado para fornecer informaes que
auxiliem o processo de tomada de deciso. Em geral, os dados informacionais so sumariados
e redundantes, suportando diferentes vises sobre eles, alm de no serem atualizveis. O
ambiente de DW no difere do ambiente operacional somente quanto ao foco, mas tambm
quanto ao escopo. Os dados transacionais so normalmente focados em reas especficas,
enquanto o ambiente de DW precisa englobar grandes volumes de dados de diferentes reas
da empresa, e transform-los em dados consistentes para poderem ser utilizados para anlise
(COSTA; ANCIES, 2001). A Figura 1.3 ilustra essa diferena.
Figura 1.3 Ambiente operacional X DW.
20
O Quadro 1.1 lista as principais diferenas existentes entre o ambiente operacional e
DW:
Quadro 1.1 Diferenas entre o ambiente operacional e DW.
Operacional
DW
Usurios
Funcionrios
Alta Administrao
Utilizao
Tarefas cotidianas
Decises estratgicas
Padro de uso
Previsvel
Difcil de prever
Princpio de funcionamento Baseado em transaes
Baseado em anlise de dados
Valores dos dados
Valores atuais e volteis
Valores histricos e imutveis
Detalhamento
Alto
Sumariado
Organizao dos dados
Orientado a aplicaes
Orientado a assunto
Contedo
Dados correntes, atmicos, isolados
Dados histricos, integrados,

sumariados
Natureza dos dados
Dinmicos, com atualizaes

contnuas
Estticos, com atualizaes

programadas
Tipo de Acesso
Grande volume de inseres,

atualizaes e consultas
Grande volume de consultas

complexas
Tempo de resposta
Em segundos
De segundos a minutos
Fonte: Adaptao pelo autor segundo ( Inmon, 1999, p. 14; Singh, 2001, p. 37; Barbieri, 2001, p. 47).
1.1.3 Granularidade
A mais importante questo de projeto que o desenvolvedor
do data warehouse precisa enfrentar, refere-se definio da
granularidade do data warehouse, ou seja, o nvel de detalhe ou de
resumo dos dados existentes no data warehouse. Quando a
granularidade de um data warehouse apropriadamente
estabelecida, os demais aspectos de projeto e implementao fluem
tranqilamente; quando ela no estabelecida, todos os outros
aspectos se complicam (INMON, 1997, p. 143).
medida que o nvel de granularidade aumenta, o nmero de consultas que podem
ser atendidas diminui, sendo que em uma granularidade mnima as consultas mais detalhadas
podem ser respondidas. Portanto, necessrio encontrar um ponto de equilbrio. O nvel
adequado de granularidade deve ser definido de tal forma que atenda as necessidades do
usurio, tendo como limitao os recursos disponveis (HOKAMA et al, 2004).
21
A Figura 1.4 mostra um exemplo de granularidade diferentes em um mesmo assunto:
Figura 1.4 Granularidade dos dados.

Fonte: (MACHADO, 2000, p. 45).
A definio da granularidade de dados a etapa mais importante do projeto de um

DW, porque ela afeta profundamente o volume de dados que reside no DW e, ao mesmo
tempo, afeta o tipo de consulta que pode ser atendida. Devem-se definir nveis adequados de
granularidade, de acordo com as necessidades do usurio (MACHADO, 2000).
A granularidade diz respeito ao nvel de detalhe ou de resumo contido nas unidades
de dados existentes no data warehouse. Quanto mais detalhe, mais baixo o nvel de
granularidade. Quanto menos detalhe, mais alto o nvel de granularidade. (INMON, 1997, p.
45).
Existe a possibilidade de utilizar um nvel duplo de granularidade (nveis duais de
granularidade). Esta tcnica se enquadra nos requisitos da maioria das empresas. So criadas
duas camadas: uma camada para os dados levemente resumidos e outra para os dados
histricos. Com a criao de dois nveis de granularidade, possvel atender a todos os tipos
de consultas, com um melhor desempenho, visto que a maior parte do processamento analtico
dirige-se aos dados levemente resumidos que so compactos e de fcil acesso e para as
ocasies em que um maior nvel de detalhe deve ser analisado, existe o nvel de dados
histricos, o qual complexo e de alto custo (INMON, 1997).
22
1.2 Data Mart (DM)
Um DM representa um subconjunto de dados do DW. Por ser menor, possibilita a
anlise multidimensional com uma viso mais especializada e limitada dos dados, visando
aumentar a velocidade na consulta das informaes, possuindo riscos e prazos menores para a
sua implementao.
Data Mart um subconjunto do data warehouse empresainteira. Tipicamente, desempenha o papel de um data warehouse
departamental, regional ou funcional. Como parte do processo
interativo do data warehouse, a empresa pode construir uma srie de
data marts ao longo do tempo e eventualmente vincul-los atravs de
um data warehouse lgico empresa-inteira (SINGH, 2001, p. 14).
Em um DM, os dados podem ser obtidos diretamente dos sistemas de informao
operacionais ou do DW da empresa, e as anlises tambm so orientadas para reas de
interesse de uma unidade ou departamento. Os DMs so muito bem aceitos no campo
empresarial, pois por suas caractersticas exigem menos investimento de infra-estrutura,
produzem resultados mais rapidamente e so escalveis at um DW.
O DM apresenta um custo inferior para o seu desenvolvimento em relao ao do DW
e pode ser visto como um conjunto de solues particionadas em termos das reas de negcios
das organizaes, de forma que se pode ter DM relativos a reas como vendas, marketing,
finanas e estoque, conforme pode ser observado na Figura 1.5.
Figura 1.5 DW X DM.

Fonte: Adaptao do autor segundo (MACHADO,2000).
23
1.2.1 Abordagens de construo do DM
A construo do DM pode seguir duas abordagens distintas: top-down e bottom-up.
Na abordagem top-down, os DMs so criados a partir do DW, isto , primeiramente
constri-se o DW global, para s depois se construir os DMs. Esta abordagem defendida por
Bill Inmon (INMON, 1997), considerado um dos precursores do DW. J na abordagem
bottom-up, que tem como seu principal defensor Ralph Kimball (KIMBALL; ROSS, 2002),
os DMs devem ser construdos de forma a representarem as diversas reas setoriais das
organizaes e, aps a criao deles, parte-se para a construo do DW que dever representar
o conjunto de todas reas das organizaes.
1.2.2 Tipos de Arquitetura do DM / DW
Segundo Machado (2000), a escolha da arquitetura uma deciso gerencial,
geralmente baseada nos fatores relativos infra-estrutura disponvel, ao tamanho da empresa,
o escopo do projeto e aos recursos disponibilizados para investimento. A seguir so descritas
estas arquiteturas.
a) Arquitetura Global: De acordo com Machado (2000, p. 32), esta arquitetura
considerada como a que suporta toda ou a maior parte das necessidades de um data
warehouse integrado com grande grau de acesso e utilizao das informaes para todos os
departamentos de uma empresa. Machado (2000) afirma ainda que seu custo de
implementao muito alto, pois este tipo de ambiente consome muito tempo de
desenvolvimento e administrao. A arquitetura global pode ser fisicamente centralizada ou
fisicamente distribuda. Na arquitetura global distribuda, o DW est distribudo em vrios
locais diferentes, enquanto na arquitetura global centralizada ele se encontra em um nico
local.
b) Arquitetura de DM Independente: Este tipo de arquitetura controlado por um
grupo determinado de usurios e atende as necessidades especficas e departamentais desse
grupo, sem nenhum foco corporativo, ou seja, um DM de um departamento no tem ligao
alguma com qualquer outro DM de qualquer outro departamento (MACHADO, 2000).
Essa arquitetura possibilita uma rpida implementao e no tm impacto nos
recursos de TI, caractersticas que podem ser consideradas como vantagens. Os problemas
apresentados por ela so o fato de no possuir integrao corporativa e falta de uma viso
24
global. Alm disso, este tipo de DM geralmente est acessvel somente ao pessoal do
departamento ao qual faz referncia (MACHADO, 2000).
c) Arquitetura de DM Integrado: Machado (2000) explica que na arquitetura de
DMs Integrados, esses so implementados separadamente por departamentos e integrados, a
fim de prover uma viso corporativa. Apesar da maior complexidade de implementao, essa
arquitetura apresenta vantagens em relao arquitetura de DM Independente, como permitir
aos usurios de um departamento o acesso e utilizao dos dados de um DM de outro
departamento e a maior quantidade de funes e informaes fornecidas.
1.3 Metadados
Toda e qualquer informao no ambiente DW que no so os dados propriamente
ditos, so chamados metadados. Estes so como uma enciclopdia para o DW. Eles esto
presentes em uma variedade de formas e formatos para suportar as necessidades desiguais dos
grupos de usurios tcnicos, administrativos e de negcio do DW (KIMBALL; ROSS, 2002).
Em termos simples, metadado definido como sendo dado sobre o dado. Ou seja, o
metadado descreve ou qualifica outro dado, incorporando, a este, significado. Sem metadado,
a informao se restringe a um conjunto de dados sem significado. Atravs de uma soluo
eficaz de metadados possvel avaliar o impacto das mudanas nos sistemas transacionais e,
portanto, a tarefa de manuteno desses sistemas torna-se menos complexa. Da mesma forma,
os metadados auxiliam o processo de construo e manuteno do DW (PEREIRA, 2000).
Singh (2001, p. 78) afirma: O metadado representa para o data warehouse o mesmo
que o catlogo de livros representa para a biblioteca. Ele serve para identificar o contedo e a
localizao dos dados no data warehouse.
O motivo central de um SAD apresentar informaes de cunho prtico aos
analistas. Para tal, os metadados devem traduzir a terminologia tcnica para os termos dos
negcios. O suporte proporcionado deve ser enfocado sob o ponto de vista do usurio final e
no apenas sob a tica dos desenvolvedores (PEREIRA, 2000).
Em um ambiente operacional, os metadados so especialmente valiosos para os
desenvolvedores de aplicao e os administradores do banco de dados. Os bancos de dados
operacionais so usualmente utilizados via aplicaes, que j contm as definies de dados
embutidas. Seus usurios simplesmente interagem com as telas do sistema, sem precisar
25
conhecer como os dados so mantidos pelo banco de dados (CAMPOS; FILHO, 2005).
O ambiente de suporte deciso, por sua vez, bastante distinto. Nele, analistas de
dados e executivos procuram por fatos no usuais e correlaes que sero reconhecidas
quando encontradas. Aplicaes rotineiras e pr-definidas no fazem sentido neste ambiente.
Os usurios de um DW precisam examinar seus dados e para tal, conhecer sua estrutura e
significado (CAMPOS; FILHO, 2005).
1.4 Data Staging Area extrao, transformao e carga de dados
No ambiente de DW, os dados so inicialmente extrados de sistemas operacionais e
de fontes externas, posteriormente so integrados e transformados (limpos, eliminados,
combinados, validados, consolidados, agregados e sumariados) antes de serem carregados no
DW.
Esta uma etapa crtica da construo de um DW, pois envolve toda a
movimentao dos dados. A mesma se d basicamente em trs passos, conhecidos como ETC:
Extrao, Transformao (passo este que inclui a limpeza dos dados) e Carga dos dados.
De acordo com Kimball;Ross (2002, p. 10), A data staging area abrange tudo entre
os sistemas operacionais de origem e a rea de apresentao dos dados.
A Figura 1.6 exemplifica o processo de extrao, transformao e carga dos dados.
Figura 1.6 Extrao, transformao e carga de dados.

Fonte: (PEREIRA, 2000, p. 6).
26
1.4.1 Extrao
A extrao o primeiro passo na obteno de dados para o ambiente do DW.
Significa basicamente ler e entender as fontes de dados e copiar as partes necessrias para a
rea de transformao de dados, a fim de serem trabalhadas posteriormente (KIMBALL;
ROSS, 2002).
Conforme Pereira (2000), a tarefa de extrao de dados est relacionada com as
seguintes etapas do ciclo de vida de DW: definio do escopo do projeto de DW, anlise dos
sistemas fontes e a especificao dos programas de extrao.
No escopo do projeto so identificados os grupos de usurios que interagiro direta
ou indiretamente com o sistema e definidos os requisitos de informao para os processos de
negcios a serem suportados por uma abordagem DW.
A anlise dos sistemas fontes tem por objetivo compreender os dados distribudos
pela organizao e integr-los de forma a refletir a perspectiva histrica de interesse s
anlises do ambiente de deciso.
Os programas de extrao devem dar suporte a captura incremental dos dados que
equivale a uma replicao baseada em dados modificados para posterior distribuio ao DW.
1.4.2 Transformao de dados
Uma vez que os dados tenham sido extrados dos sistemas fontes, um conjunto de
transformaes deve ser processado sobre esses dados. A transformao dos dados pode ser
simples ou complexa, dependendo da natureza dos sistemas fontes. Em algumas situaes,
mltiplos estgios de transformaes so necessrios (PEREIRA, 2000).
As rotinas de limpeza e integrao atuam sobre os dados extrados. A execuo
dessas rotinas de limpeza sobre os dados coletados permite assegurar sua consistncia. Dados
migrados para o DW, sem integrao, no podem ser empregados no suporte a uma viso
corporativa dos dados (INMON, 1997).
Segundo Hokama et al. (2004), aps a extrao dos dados dos sistemas fontes, so
realizadas uma srie de atividades sobre esses dados de modo a convert-los em formato
vlido para o negcio e adequado para carga. A transformao dos dados poder envolver um
27
ou vrios processos, dependendo da necessidade e situao. Alguns dos processos mais
comumente utilizados so:
Limpeza: constitui no conjunto de atividades realizadas, sobre os dados extrados, de
modo a corrigir o uso incorreto ou inconsistente de cdigos e caracteres especiais, resolver
problemas de conflito de domnios, tratar dados perdidos, corrigir os valores duplicados ou
errados. Independente do problema a ser solucionado pelo processo de limpeza, a finalidade
deixar os elementos de dados dentro de formatos padres (uniformizados), no duplicados,
corretos, consistentes e espelhando a realidade.
Combinao: realizada quando fontes de dados possuem exatamente os mesmos
valores de chaves representando registros iguais ou complementares.
Desnormalizao e normalizao: o padro no processo de transformao reunir
as hierarquias de dados, separadas em vrias tabelas devido normalizao, dentro de uma
nica dimenso, de forma desnormalizada. Pode ocorrer, entretanto, que dados provenientes
do processo de extrao estejam completamente desnormalizados dentro de arquivos texto,
nesse caso possvel que seja necessrio normalizar partes dos registros.
Clculos, derivao e alocao: so transformaes a serem aplicadas s regras do
negcio identificadas durante o processo de levantamento de requisitos. conveniente que as
ferramentas a serem empregadas possuam um conjunto de funes, tais como manipulao de
textos, aritmtica de data e hora, entre outras.
1.4.3 Carga de dados
Conforme Hokama et al. (2004), aps os dados serem transformados, eles so
carregados no DW. A parte de carga dos dados tambm possui uma enorme complexidade,
sendo que os seguintes fatores devem ser levados em conta:
Integridade dos dados: no momento da carga, necessrio checar os campos que
so chaves estrangeiras2 com suas respectivas tabelas para certificar-se de que os dados
existentes na tabela da chave estrangeira esto de acordo com a tabela da chave primria;
Tipo de carga a ser realizada - incremental ou total: a carga incremental
Chave estrangeira uma chave formada pela chave primria de outra tabela e a chave de um campo da tabela
que recebe o relacionamento. a chave que define um relacionamento entre as tabelas (WIKIPEDIA, 2005).
28
normalmente feita para tabelas de fatos e a carga total feita em tabelas de dimenso onde o
analista ter que excluir os dados existentes e inclu-los novamente. Mas isso depende da
necessidade do negcio em questo.
Otimizao do processo de carga: todo banco de dados possui um conjunto de
tcnicas para otimizar o processo de carga, tais como evitar a gerao de log3 durante o
processo, criar ndices e agregar dados. Muitas dessas caractersticas podem ser invocadas dos
bancos de dados ou registradas em scripts atravs da utilizao de ferramentas sobre a rea de
organizao de dados.
Suporte completo ao processo de carga: o servio de carga tambm precisa
suportar as exigncias antes e depois da carga atual, como eliminar e recriar ndices e
particionamento fsico de tabelas e ndices.
Log a nomenclatura dada aos registros que um sistema mantm, de todos os eventos dignos de nota que
acontecem enquanto ele est rodando.
2 A MODELAGEM DIMENSIONAL
Nos bancos de dados relacionais, a redundncia dos dados evitada, sendo aceita
somente em determinados casos em que realmente necessria. Esta redundncia eliminada
atravs de processos de normalizao.
A normalizao das tabelas traz benefcios nos casos em que muitas transaes so
efetuadas, pois estas se tornam mais simples e rpidas. J no caso do DW ocorre o contrrio,
as transaes operam sobre um grande volume de dados e no so simples nem freqentes,
no sendo conveniente a normalizao das tabelas, pois no ambiente de DW ocorrem poucas
transaes concorrentes e cada transao acessa um grande nmero de registros (PERNAS,
2003).
Conforme Pernas (2003), um outro ponto que distingue o banco de dados relacional
do DW est relacionado modelagem dos dados. Enquanto o banco de dado relacional
geralmente utiliza a modelagem EntidadeRelacionamento (ER)1, o DW utiliza-se de uma
modelagem lgica chamada de modelagem dimensional. A modelagem dimensional a
tcnica utilizada para se ter uma viso multidimensional dos dados.
De acordo com Barbieri (2001, p. 74), a modelagem de dados seguramente um
dos fatores crticos de sucesso num projeto de Data Warehouse, e pode representar a fronteira
entre o sucesso e o seu fracasso.
Como o modelo relacional trabalha com normalizao, suas
tabelas possuem menos registros e no tm redundncias,
apresentando assim uma melhor performance nas tarefas do dia a
dia, como incluses, alteraes e excluses de registros, mas ele s
adequado para consultas simples de poucos registros. Para anlises
mais complexas com um universo de registros maior, o modelo
1
Proposta por Peter P. Chen em 1976, A modelagem Entidade-Relacionamento (ER) envolve identificando, os
elementos de importncia na organizao (entidades), as propriedades destes elementos (atributos) e como eles
esto relacionados uns aos outros (relacionamentos). O modelo resultante da informao independente de
qualquer armazenamento de dados ou mtodo de acesso (LOBO, 1998).
30
dimensional oferece uma melhor alternativa, economizando em
junes com vrias tabelas, e armazenando dados que facilitam a
anlise das informaes (HOKAMA et al, 2004, p. 32).
O modelo dimensional assimtrico, ou seja, possui uma grande tabela, que a
principal, est localizada no centro do diagrama e possui outras tabelas secundrias ao seu
redor, que so menores e que se relacionam com a tabela principal. A tabela central
chamada de tabela de fatos e as demais so chamadas tabelas de dimenso (BISPO, 1999, p.
24).
Um modelo dimensional composto basicamente pela tabela de fatos e pelas tabelas
de dimenses. A tabela fato traz o resultado da consulta, valores de medio. As restries,
objees e questionamentos ficam nas tabelas dimenses, que trazem informaes textuais
sobre o valor medido na tabela fato. Perguntas como, por exemplo: Qual? Quem? Onde? Por
qu? So respondidas com informaes das tabelas dimenses (BARBALHO, 2003).
2.1 Tabela de fatos
Segundo Kimball; Ross (2002), a tabela de fatos a principal tabela de um modelo
dimensional, onde as medies numricas de interesse da empresa esto armazenadas. A
palavra fato usada para representar uma medio de negcio, como quantidades, valores e
indicadores. A tabela de fatos registra os fatos que sero analisados. composta por uma
chave primria (formada por uma combinao nica de valores de chaves de dimenso) e
pelas mtricas de interesse para o negcio.
Em uma tabela de fatos, uma linha corresponde a uma medio. Uma medio
uma linha em um tabela de fatos. Todas as medies em uma tabela de fatos devem estar
alinhadas na mesma granularidade (KIMBALL; ROSS, 2002, p. 21).
De acordo com Hokama et al. (2004), a tabela de fatos sempre esparsa, ou seja,
possui um nmero relativamente pequeno de todas as combinaes possveis de valores de
chaves. Por exemplo, no caso de um banco de dados de uma rea comercial, a presena de
todas as combinaes possveis representaria que todos os clientes compram para todas as
datas de entrega, todos os produtos da empresa, o que praticamente impossvel. Por isso
podemos concluir que esse banco extremamente esparso, pois uma porcentagem muito
pequena de todas as combinaes possveis de clientes, produtos e datas de entrega aparecer
nele.
31
Um aspecto importante que a tabela de fatos deve representar uma unidade do
processo do negcio, no devendo misturar assuntos diferentes numa mesma tabela de fatos.
Os atributos mais comuns em uma tabela de fatos so
valores numricos. Estes valores so, em sua maioria, aditivos. As
mtricas aditivas so as que permitem operaes como adio,
subtrao e mdia de valores por todas as dimenses, em quaisquer
combinaes de registros, como "total de itens vendidos" por
combinao de data, produto e loja. Mtricas aditivas so
importantes porque normalmente as aplicaes de DW no retornam
uma linha da tabela de fatos, mas sim centenas, milhares e at
milhes (HOKAMA et al, 2004, p. 36).
A Figura 2.1 mostra um exemplo de uma tabela de fatos, chamada VENDA,
composta pelas chaves das dimenses de data, cliente e produto e pelas medidas quantidade,
valor, custo e lucro. (Grifo nosso).
Figura 2.1 Exemplo de tabela de fatos.

2.2 Tabela de Dimenso
Kimball; Ross (2002) afirmam que a tabela de dimenso contm as descries
textuais do negcio. Seus atributos so fonte das restries das consultas, agrupamento dos
resultados, e cabealhos para relatrios. As dimenses so os aspectos pelos quais se pretende
observar as mtricas relativas ao processo que est sendo modelado.
A qualidade do DW est diretamente ligada qualidade dos atributos de dimenses,
portanto devem ser dedicados tempo e ateno a sua descrio, ao seu preenchimento e a
garantia da qualidade dos valores dos seus atributos.
Kimball; Ross (2002) dizem ainda que cada dimenso deve ser identificada com uma
nica chave primria. Essa chave a base da integridade referencial no relacionamento com a
tabela de fatos. Uma tabela de dimenso composta tambm de atributos, os melhores
32
atributos so textuais e discretos, e devem consistir de palavras reais, evitando-se o uso de
cdigos e abreviaes. Esses atributos descrevem as linhas na tabela de dimenso. A Figura
2.2 mostra um exemplo de tabela de dimenso PRODUTO, identificada pela chave
codigo_produto e composta pelos demais atributos que o caracterizam. (Grifo nosso).
Figura 2.2 Exemplo de tabela de dimenso.

2.3 Agregados
Devido ao grande volume de dados envolvidos nas consultas para anlise de dados, o
tempo de resposta pode se tornar um fator crtico. Uma tcnica utilizada para obter ganhos de
performance a criao de tabelas agregadas, sendo um dos principais recursos para ajuste de
desempenho do DW. Basicamente, consiste em criar novas tabelas com os dados da tabela de
fatos, mas alterando a granularidade da mesma, gerando assim tabelas menores, com dados
sumariados (HOKAMA et al. 2004).
Os valores agregados podem representar uma soluo e ao mesmo tempo um
problema. Soluo, porque com a criao de tabelas sumariadas facilitam o acesso aos dados
e agilizam o processo de tomada de deciso. Problema, pois de certa forma contrariam os
conceitos estabelecidos de no-redundncia para os banco de dados. Alm disso, ocupa mais
espao para o armazenamento dos dados em um estado pr-processado (BARBIERI, 2001).
A Figura 2.3 mostra um exemplo da utilizao de tabelas de agregados com base na
tabela de fatos. Foram criadas duas tabelas agregadas: a tabela AGREGADA_1, onde as
informaes esto sumariadas para todos os clientes e a tabela AGREGADA_2 onde as
informaes esto sumariadas por produto. (Grifo nosso).
33
Figura 2.3 Exemplo de tabela de agregados.

2.4 Tcnicas de Modelagem
Existem tcnicas especficas de modelagem dimensional. As mais conhecidas e mais
utilizadas so a Star schema (esquema estrela) e a Snowflake schema (esquema flocos de
neve), as quais so explicadas a seguir:
2.4.1 Star Schema
O esquema estrela uma estrutura simples, com poucas tabelas e relacionamentos.
Assemelha-se ao modelo de negcio, o que facilita a leitura e entendimento, no s pelos
analistas, como por usurios finais no familiarizados com estruturas de banco de dados.
O nome estrela est associado disposio das tabelas no modelo, que consiste de
uma tabela central, a tabela de fatos, que se relaciona com diversas outras tabelas, as tabelas
de dimenso. A Figura 2.4 demonstra este relacionamento.
Figura 2.4 Modelo Star Schema.

Fonte: (BRAGA, 2004, p. 20)
34
De acordo com Machado (2000), neste modelo o relacionamento entre a tabela de
fatos e as tabelas dimenso a ligao entre duas entidades, representando relacionamento de
um para muitos no sentido da dimenso para o fato.
2.4.2 Snowflake
O modelo Snowflake o resultado da aplicao da terceira forma normal sobre as
entidades dimenso. Este modelo o resultado da decomposio de uma ou mais dimenses
que possuem hierarquias entre seus membros (MACHADO, 2000).
Para ser criado necessrio remover os atributos de cardinalidade mnima de uma
tabela de dimenso, para coloc-los em outra tabela de dimenso, conectados por uma chave
(snowflake key) (KIMBALL, 2000).
A Figura 2.5 exemplifica essa tcnica de modelagem, onde pode-se observar a
normalizao das tabelas de dimenso.
Figura 2.5 Modelo Snowflake.

Fonte: (BRAGA, 2004, p. 21).
2.5 Cubo de dados

Cubo de dados uma estrutura multidimensional que
expressa a forma na qual os tipos de informaes se relacionam entre
si. formado pela tabela de fatos e pelas tabelas de dimenso que a
35
circundam e representam possveis formas de visualizar e consultar os
dados. O cubo armazena todas as informaes relacionadas a um
determinado assunto, de maneira a permitir que sejam montadas
vrias combinaes entre elas, resultando na extrao de vrias
vises sobre o mesmo tema (HOKAMA et al. 2004, p. 49).
Brito (2004), afirma que a idia fundamental que praticamente todo o tipo de
negcio pode ser representado por uma espcie de cubo de dados, onde as clulas do cubo
contm valores mensurveis e as bordas do cubo definem as dimenses naturais dos dados.
Pode-se necessitar utilizar mais de trs dimenses nos modelos, passando o cubo a ser
chamado de hiper-cubo.
De forma resumida, o cubo uma estrutura multidimensional que armazena os dados
tornando-os mais fceis de se analisar. Cada cubo contm uma tabela de fatos e vrias
dimenses. Por exemplo, um cubo contendo informaes de vendas poder ser composto
pelas dimenses tempo, regio, produto, cliente, cenrio (orado ou real) e medidas. Medidas
tpicas seriam, por exemplo, valor de venda, unidades vendidas, custos, margem de lucro, etc.
De acordo com Fortulan; Filho (2005), os cubos so os principais objetos de uma
ferramenta OLAP. Construdos com tecnologia que permite rpido acesso aos dados,
normalmente eles so construdos a partir de subconjuntos de um DW e so organizados e
sumariados dentro de estruturas multidimensionais definidas por dimenses e medidas.
A Figura 2.6 mostra um exemplo de um cubo de dados, contendo as dimenses
tempo, produto e local, sendo quantidade vendida uma de suas medidas.
Figura 2.6 Cubo de dados.
36
2.6 OLAP
O termo OLAP possui vrios significados, pois sua tecnologia est presente em
vrias camadas como: armazenamento, acesso, compiladores, linguagem e conceitos. Pode-se
falar em conceitos OLAP, linguagens OLAP, camadas de produtos OLAP e produtos
completos OLAP (THOMSEN, 2002).
O DW utilizado para armazenar informaes e o OLAP
para recuper-las, ambos so especializados para exercer suas
funes de forma eficiente. As duas tecnologias so complementares
de modo que um bom DW planejado com produo de relatrios em
mente. Desta forma, para explorar o DW completamente necessrio
o OLAP que ir extrair e alavancar totalmente as informaes nele
contidas (ANZANELLO, 2005, p. 5).
OLAP uma ferramenta de BI utilizada para apoiar as empresas na anlise de suas
informaes, em vrios nveis estratgicos, visando obter novos conhecimentos que sero
empregados na tomada de deciso.
A modelagem OLAP descritiva. Nela no se utiliza cdigo, nem siglas, e sim
nomes representativos que permitem a identificao por qualquer pessoa, que, mesmo no
sendo da rea, entenda os valores apresentados em um relatrio (THOMSEN, 2002).
A aplicao OLAP bastante diversificada e seu uso encontra-se em diversas reas
de uma empresa. Por exemplo, em uma aplicao na rea de vendas, o OLAP pode ser
utilizado para fazer anlises de vendas (por regio, produto, vendedor, etc.), previses,
lucratividade de cliente/pedido, anlise de canais de distribuio, dentre outros.
As operaes utilizando ferramentas OLAP podem responder inmeras questes,
como por exemplo:
Qual foi o valor das vendas realizadas por um determinado vendedor no ms

de outubro?
Quais foram os clientes atendidos por um determinado vendedor no primeiro

semestre do ano anterior que resultou em lucros inferiores a 10%?
Qual o produto que traz maior lucratividade para a empresa nos diversos
meses do ano?
37
Quais clientes ou grupos de clientes so mais lucrativos para a empresa?
A Empresa necessita contratar mais vendedores? Quais regies necessitam de

tais vendedores?
2.6.1 Operaes OLAP

De acordo com Machado (2000), Barbieri (2001), Singh (2001), as ferramentas
OLAP permitem ao usurio, navegar entre diferentes granularidades de um cubo de dados. As
mais freqentes funcionalidades oferecidas pelas ferramentas OLAP so:
Drill-across: a requisio de dados das tabelas de dimenso com o valor das
consultas modificado, ocorre quando o usurio pula um nvel intermedirio dentro de uma
mesma dimenso. Por exemplo, em uma dimenso tempo composta por ano, semestre,
trimestre, ms e dia. O usurio estar executando um drill-across quando ele passar de ano
direto para trimestre ou ms. (Grifo nosso).
Drill-down: aumento do nvel de detalhe da informao, por parte do usurio, para
solicitar uma viso mais detalhada em um conjunto de dados. Por exemplo, se os dados de
vendas estiverem sumariadas e o usurio desejar informaes mais detalhadas, por vendedor
que realizou a venda, por exemplo, realiza-se ento um drill-down para que os dados sejam
especficos de cada vendedor.
Drill-up: o contrrio do drill-down, ocorre quando o usurio diminui o nvel de
detalhe da informao, solicitando uma viso menos detalhada de um conjunto de dados. Por
exemplo, se o usurio est visualizando a venda de um determinado vendedor e passa a
analisar as vendas sumariadas de todos os vendedores.
Drill-through: quando se deseja uma informao em um nvel de detalhe menor do
que aquele armazenado na tabela de fato e permitido pela sua granularidade. Por exemplo,
em um nvel de granularidade de produto por dia e por loja deseja-se uma informao que est
presente na nota fiscal. O drill-through a operao que busca esta informao alm do nvel
granularidade existente na estrutura dimensional. Esta busca poderia ser no prprio sistema
transacional de origem, no caso de compatibilidade entre ambos.
Slice-dice: a descrio padro para a habilidade de acessar os dados do DW atravs
de qualquer uma das dimenses de forma igual. Serve para modificar a posio de uma
38
informao, alterar linhas por colunas de maneira a facilitar a compreenso dos usurios e
mudar de dimenso sempre que necessrio. Esta operao equivale a fatiar o cubo de dados,
ou seja, um determinado valor de uma dimenso fixado. Por exemplo, podemos fixar o valor
Sul para a dimenso Localidade, e analisar as outras dimenses. Assim, pode ser conhecida a
eficincia de entrega desta regio em funo dos produtos (explorando os valores da dimenso
Produtos) e da forma de distribuio utilizada (dimenso Distribuio). Esta operao permite
conhecer em detalhes o relacionamento de um valor de uma dimenso com as outras
dimenses. (Grifo nosso).
Pivoting (pivoteamento): a mudana do arranjo das linhas e colunas em um
relatrio tabular, onde freqentemente as linhas ou as colunas so derivadas de dimenses
diferentes. a inverso dos eixos das dimenses, para obter-se novas vises de consultas. Em
algumas ferramentas, para que seja realizada esta operao, podem-se simplesmente utilizar
as funes de "arrastar e soltar" com o mouse. (Grifo nosso).
Consultas ad-hoc: de acordo com Inmon, apud Cielio (2005), so consultas com
acesso casual nico e tratamento dos dados segundo parmetros nunca antes utilizados,
geralmente executadas de forma iterativa e heurstica. Isso tudo nada mais do que o prprio
usurio gerar consultas de acordo com suas necessidades de cruzar as informaes de uma
forma no vista e com mtodos que o levem a descoberta daquilo que procura.
2.6.2 Arquiteturas OLAP
De acordo com Cunha (2004), Cielio (2005), a arquitetura OLAP diz respeito ao
mtodo de armazenamento de dados utilizado para uma aplicao OLAP. Os mtodos de
armazenamento de dados so MOLAP, ROLAP, HOLAP, DOLAP e WOLAP. Cada um deles
tem uma funo especfica e deve ser utilizada quando melhor atender s necessidades de
anlise pela ferramenta de OLAP. Segundo os autores citados, as caractersticas destas
arquiteturas so:
MOLAP (Multidimensional On Line Analytical Processing): Processa-se da
seguinte forma: com um servidor multidimensional o acesso aos dados ocorre diretamente no
banco de dados, ou seja, o usurio trabalha, monta e manipula os dados do cubo diretamente
no servidor. Isso traz grandes benefcios aos usurios no que diz respeito performance, mas
tem problemas com escalabilidade alm de ter um custo alto para aquisio. A Figura 2.7
demonstra esta arquitetura.
39
Figura 2.7 Arquitetura MOLAP.

Fonte: (CUNHA, 2004).
ROLAP (Relational On Line Analytical Processing): Possuem uma engenharia de

acesso aos dados e anlise OLAP com uma arquitetura um pouco diferente. Nesse caso a
consulta enviada ao servidor de banco de dados relacional e processada no mesmo,
mantendo o cubo no servidor. O que se pode notar nesse caso que o processamento OLAP
se dar somente no servidor. A principal vantagem dessa arquitetura que ela permite analisar
enormes volumes de dados, em contra partida uma grande quantidade de usurios acessando
simultaneamente poder causar srios problemas de performance no servidor. A Figura 2.8
exemplifica esta arquitetura.
Figura 2.8 Arquitetura ROLAP.

HOLAP (Hybrid On Line Analytical Processing): Essa forma de acessar os dados

uma mistura de tecnologias onde h uma combinao entre ROLAP e MOLAP. A vantagem
que com esta mistura de tecnologias pode-se extrair o que h de melhor de cada uma, ou seja,
40
a alta performance do MOLAP com a melhor escalabilidade do ROLAP. A Figura 2.9 mostra
o exemplo desta arquitetura.
Figura 2.9 Arquitetura HOLAP.

DOLAP (Desktop On Line Analytical Processing): So as ferramentas que, a partir

de um cliente qualquer, emitem uma consulta para o servidor e recebem o cubo de
informaes de volta para ser analisado na estao cliente. O ganho com essa arquitetura o
pouco trfego que se d na rede, visto que todo o processamento OLAP acontece na mquina
cliente, e a maior agilidade de anlise, alm do servidor de banco de dados no ficar
sobrecarregado, sem incorrer em problemas de escalabilidade. A desvantagem que o
tamanho do cubo de dados no pode ser muito grande, caso contrrio, a anlise passa a ser
demorada e/ou a mquina do cliente pode no suportar em funo de sua configurao. Esta
arquitetura exemplificada na figura 2.10.
Figura 2.10 Arquitetura DOLAP.

Fonte: Adaptao pelo autor conforme (CUNHA, 2004).
41
WOLAP (Web On Line Analytical Processing): a utilizao de uma ferramenta
OLAP a partir de um navegador Web (browser). A arquitetura das ferramentas WOLAP
uma variao da cliente/servidor. A diferena est na utilizao de um middleware2 do lado
servidor que ser o responsvel pela comunicao entre o cliente e uma aplicao servidora,
neste caso, o banco de dados. A Figura 2.11 exemplifica esta arquitetura.
Figura 2.11 Arquitetura WOLAP.

2.6.3 Tendncias
JOLAP - um esforo da Java Community Process (JCP)3 de projetar uma API
Java4 para servidores e aplicaes OLAP, aderentes ao ambiente Java2 Plataform Enterprise
Edition (J2EE)5. Ela est sendo especificada para suportar a criao e manuteno de dados e
metadados OLAP, independente de fornecedor. JOLAP baseada em uma forte
generalizao, orientada a objeto e nos conceitos de OLAP. Este modelo suporta conceitos
referentes a trs reas que so chave para as aplicaes OLAP: Metadados, dados e pesquisas
(ANZANELLO, 2005).
XMLA (XML6 for Analysis) O XMLA tem como proposta prover
2
Middleware uma camada de software localizada entre as aplicaes e o sistema operacional. Seu objetivo
tanto facilitar o desenvolvimento de aplicaes por parte dos programadores quanto esconder os detalhes das
camadas inferiores e a heterogeneidade entre diferentes sistemas operacionais (WIKIPEDIA, 2005).
3
O Java Community Process tem o objetivo de desenvolver e rever as especificaes da tecnologia Java. JCP.
Java Community Process. Disponvel em: <http://www.jcp.org>. Acesso em: 06 ago. 2005.
4
JAVA. Java Technology. Disponvel em: < http://java.sun.com>. Acesso em: 06 ago. 2005.
5
Plataforma Java para desenvolvimento e execuo de aplicaes servidoras, com capacidade de suporte ao
desenvolvimento de aplicaes robustas e escalveis. JAVA. Java Technology. Disponvel em:
<http://java.sun.com>. Acesso em: 06 ago. 2005.
6
XML. Extensible markup language. Disponvel em: <http://www.w3.org/XML>. Acesso em: 02 out. 2005.
42
interoperabilidade em ambientes OLAP heterogneos, utilizando a Web como infra-estrutura
de comunicao (XMLA.ORG, 2005).
O XMLA um padro comercial aberto para interface de servio Web, projetado
especificamente para processamento OLAP e para funes de data mining7 (XMLA.ORG,
2005). Ele tem como objetivo fornecer uma API (Application Program Interface) de acesso
padro para os provedores de OLAP do mercado. Ele define um modo padro para conexo a
fontes de dados OLAP ou servidores de banco de dados multidimensionais, anlogo ao
ODBC (Open DataBase Connection)8 para os bancos de dados relacionais. Alm disso, prev
consultas a dados e metadados, usando a sintaxe de uma linguagem de consulta padro
(AMARAL, 2003).
Essa linguagem o mdXML, que uma verso encapsulada da linguagem MDX
(Multidimensional Expressions)9. A MDX uma linguagem de expresso multidimensional
definida na especificao OLE DB para OLAP10 (MICROSOFT apud AMARAL, 2003, p.
64).
Data Mining ou Minerao de Dados consiste em um processo analtico projetado para explorar grandes
quantidades de dados (tipicamente relacionados a negcios, mercado ou pesquisas cientficas), na busca de
padres consistentes e/ou relacionamentos sistemticos entre variveis e, ento, valid-los aplicando os padres
detectados a novos subconjuntos de dados. O processo consiste basicamente em 3 etapas: explorao; construo
de modelo ou definio do padro; e validao/verificao (PUC-RIO, 2005).
8
O ODBC um mtodo de acesso a banco de dados, com a finalidade de tornar possvel acessar qualquer dado
de qualquer aplicao independentemente do banco de dados usado.
9
A linguagem MDX ser descrita em detalhes no captulo 3.
10
O Microsoft OLE DB para OLAP um conjunto de objetos e interfaces que estendem a habilidade do OLE
DB para prover acesso a armazenagem de dados multidimensional. MICROSOFT. Microsoft Corporation.
Disponvel em: <http://www.microsfot.com>. Acesso em: 06 ago. 2005.
3 FERRAMENTAS OLAP
Neste captulo ser feito o estudo de alguns softwares dentre os quais sero
selecionados aqueles com os quais pretende-se implementar a soluo proposta por esse
trabalho. Os softwares a serem avaliados so Mondrian1, Jpivot2, OpenI3 e Pentaho4. O estudo
ser feito com base nas informaes disponveis em suas respectivas pginas na Internet, j
que elas so ferramentas muito recentes e ainda carecem de documentao.
3.1 Mondrian
Mondrian um servidor OLAP Open Source escrito em linguagem Java. Ele executa
consultas escritas em linguagem MDX, lendo os dados de um RDBMS, e apresentando o
resultado em um formato multidimensional atravs de uma API Java. A caracterstica de
realizar consultas OLAP em dados armazenados em um banco de dados relacional e retornar
consultas em forma multidimensional classifica o Mondrian como um software ROLAP
(BRITO, 2004).
3.1.1 Linguagem MDX
A Linguagem MDX uma linguagem de consulta semelhante a linguagem SQL 5,
porm exclusiva para consultas multidimensionais em bancos de dados. A linguagem MDX
foi originalmente criada pela Microsoft para utilizao com o produto SQL Server OLAP
Services como parte da especificao OLE DB/OLAP API (MICROSOFT, 2005).
Recentemente foi introduzida como parte da API do XMLA, o que motivou a adoo dela por
1
MONDRIAN. Mondrian OLAP Server. Disponvel em: <http://mondrian.sourceforge.net>. Acesso em: 06

ago. 2005.
2
JPIVOT. A JSP based OLAP. Disponvel em: < http://jpivot.sourceforge.net>. Acesso em: 06 ago. 2005.
3
OPENI. Open Source Web Application for OLAP Reporting. Disponvel em: <http://www.openi.org>. Acesso
em: 06 ago. 2005.
4
PENTAHO. Open Source business intelligence. Disponvel em: <http://www.pentaho.org>. Acesso em: 06
ago. 2005.
5
SQL uma sintaxe, criada pela IBM, usada para a definio e manipulao de dados em um banco de dados
relacional (WIKIPEDIA, 2005).
44
outros desenvolvedores de aplicaes OLAP. Ela a linguagem de consulta implementada
pelo Mondrian e um exemplo de sentena MDX exibido na Figura 3.1.
Figura 3.1 Instruo MDX.

Fonte: Adaptao do autor segundo (MONDRIAN, 2005).
Este exemplo faz uma consulta ao cubo Sales ([Sales]), a cada uma das dimenses
[Time], [Gender] e alguns de seus membros. O resultado exibido na Figura 3.2:
Figura 3.2 Retorno de uma consulta MDX.

3.1.2 Arquitetura do Mondrian

O servidor OLAP Mondrian composto por quatro camadas: a camada de
apresentao (presentation layer), a camada dimensional (dimensional layer), a camada
estrela (star layer) e a camada de armazenamento (storage layer).
A camada de apresentao determina o que o usurio final v em seu monitor, e
como ele pode interagir para fazer novas consultas. H muitas maneiras de apresentar
conjuntos de dados multidimensionais, incluindo pivot tables6, grficos estticos em diversos
formatos (pizza, linha, barra, etc...) e ferramentas avanadas de visualizao, tais como mapas
interativos e grficos dinmicos. Estas ferramentas podem ser escritas em interface Java
Swing7 ou JSP (Java Server Pages)8 , os grficos, renderizados no formato JPEG ou GIF.
A segunda camada a camada dimensional. A camada dimensional analisa
6
Pivot table um recurso que permite uma tabela fazer um agrupamento dinmico, onde o usurio
simplesmente arrasta um atributo para linha ou coluna, e a tabela recalculada e reagrupada para os novos
valores.
7
Swing um Framework (conjunto de classes que constitui um design abstrato para solues de uma famlia de
problemas) para a criao de aplicaes grficas em Java (JAVA, 2005).
8
JSP uma tecnologia baseada em Java utilizada para o desenvolvimento de sites dinmicos (JAVA, 2005).
45
gramaticalmente, valida e executa consultas MDX. Um transformador de consultas (query
transformer) permite que a aplicao manipule as consultas existentes, ao invs de construir
uma nova instruo MDX para cada solicitao.
A terceira camada a camada estrela, que responsvel por apresentar valores
relacionados a determinados nveis de informao. Estes valores podem ser resultados de uma
consulta ao banco de dados relacional, ou ser o resultado de muitas consultas armazenadas em
memria. responsabilidade desta camada obter os valores, seja qual for a sua origem.
(BRITO, 2004, p. 96).
A camada do armazenamento um RDBMS. Ela responsvel por fornecer os dados
utilizados nas consultas.
Todos estes componentes podem existir em uma mesma mquina, ou podem ser
distribudos entre vrias mquinas, sendo que as camadas dimensional e estrela, que
compreendem ao servidor Mondrian, devem estar na mesma mquina. A camada de
armazenamento pode estar em uma outra mquina, acessada atravs da conexo remota com o
uso de drivers JDBC9. A Figura 3.3 exibe a arquitetura do Mondrian.
Figura 3.3 Arquitetura do Mondrian.

3.1.3 Estratgia de armazenamento e agregao

Na estrutura do Mondrian, basicamente trs tipos de dados precisam ser
armazenados: dados das tabelas fato, dimenses e agregados.
JDBC um conjunto de classes e interfaces (API) escritas em Java que fazem o envio de clusulas SQL para
qualquer banco de dados relacional compatvel (JAVA, 2005).
46
Agregados pr-computados so necessrios para grandes conjuntos de dados, caso
contrrio, certas consultas no poderiam ser executadas sem que fosse efetuada uma leitura
completa do contedo da tabela de fatos. Na arquitetura ROLAP, os dados agregados so
armazenados em tabelas separadas.
O componente final da estratgia de agregao o cache. O cache mantm os
agregados pr-computados em memria e ento as consultas seguintes podem acess-las sem
a necessidade de consultar o disco.
A estratgia de agregao do Mondrian manter os dados da tabela de fatos
armazenados no RDBMS e ter os dados agregados no cache atravs da submisso de
consultas group by10. A idia geral delegar ao servidor de banco de dados o que especfico
do banco de dados.
3.1.4 Mondrian Schema
De acordo com Brito (2004), a lgica do Mondrian implementada atravs de
Schemas, que definem o modelo multidimensional lgico e o mapeamento deste modelo em
um modelo fsico e relacional.
O modelo lgico consiste de elementos definidos pelo Schema. Estes elementos so:
cubos, dimenses, hierarquias, nveis e membros.
O modelo fsico a fonte de dados que mapeada pelo modelo lgico atravs do
Schema. Tipicamente, um banco de dados onde as informaes ficam armazenadas em
tabelas relacionais.
Conforme Brito (2004), a representao destes Schemas feita atravs de arquivos
XML, utilizando os mesmos conceitos relacionados anlise dimensional: cubo (cube),
representando, em alto nvel, a lgica multidimensional do sistema, bem como os fatos
(measures) e dimenses (dimensions). Atualmente, uma das maneiras de criar um Schema
editar manualmente o arquivo XML em um editor de texto. Existe tambm um plugin para o
ambiente Eclipse11 que facilita a edio do mesmo (JPIVOT, 2005).
A Figura 3.4 exibe um exemplo de arquivo XML definindo um Schema.
10
11
Clusula de grupo da linguagem de consulta SQL.

ECLIPSE. Eclipse Foundation. Disponvel em: <http://www.eclipse.org>. Acesso em: 06 ago. 2005.
47
Figura 3.4 Exemplo de arquivo XML definindo um Schema.

Este Schema contem um nico cubo, chamado Vendas. Este cubo possui duas
dimenses, Tempo e Genero, e dois fatos, Quantidade Vendida e Vendas da Loja. A
seguir sero detalhados cada um dos componentes do Schema. (Grifo nosso):
3.1.4.1 Cubos
Um cubo uma coleo de medidas e dimenses. A nica coisa que as medidas e

dimenses tem em comum a tabela de fatos, vendas_geral, no nosso exemplo. A tabela de
fatos definida usando a tag <Table> conforme exemplo na Figura 3.5:
Figura 3.5 Definio de um cubo.

48
3.1.4.2 Medidas
Cada medida tem um nome, uma coluna na tabela de fatos e um agregador. O

agregador geralmente o operador "sum", mas "count", "min", "max", "avg" e "distinct
count" tambm so permitidos. O atributo formatString opcional e especifica como o
valor deve ser exibido (Grifo nosso). A Figura 3.6 mostra um exemplo da definio de
medidas.
Figura 3.6 Definio de medidas.

3.1.4.3 Dimenses, hierarquias, nveis e membros
Um nvel uma coleo de membros que possuem a mesma distncia da raiz da

hierarquia. Um membro um ponto em uma dimenso, determinado por um conjunto
particular de valores de atributo. Uma hierarquia um conjunto de membros organizados em
uma estrutura conveniente para anlise, por exemplo, a hierarquia de tempo pode consistir do
dia, ms, trimestre, ano, etc. Uma dimenso uma coleo de hierarquias na qual cada uma
delas esta associada a um atributo da tabela de fatos. A definio destas estruturas mostrada
na Figura 3.7.
Figura 3.7 Definio de dimenses, hierarquias e nveis.

Membros calculados: So medidas calculadas a partir de colunas das tabelas de

fatos. Ou seja, so valores que podem ser obtidos baseados nos valores armazenados nas
colunas das tabelas de fatos. Na Figura 3.8, mostrado o exemplo do membro calculado
lucro que apurado a partir das quantidades vendidas da loja descontando-se os custos
49
operacionais da mesma. (Grifo nosso).
Figura 3.8 Definio de membros calculados.

3.2 Jpivot
Conforme Brito (2004), O Mondrian,
executa as consultas e as retorna. Este
retorno, porm, no tem uma sada definida. A visualizao das consultas retornadas depende
de outro software, como por exemplo, o Jpivot. O Jpivot uma tag library12 que possibilita o
acesso e disponibilizao de tabelas de forma multidimensional, alm de permitir operaes
bsicas em consultas OLAP, como slice and dice e drill down. Com o uso deste software,
possvel escrever aplicativos na forma de JSP, utilizando comandos especficos e gerando
sadas atravs de tabelas e grficos.
O Jpivot estruturado para suportar diversos servidores OLAP, especialmente
Mondrian e XMLA. O Jpivot no utiliza a API do Mondrian diretamente. Ele define sua
prpria interface OLAP. Para fazer o Jpivot funcionar com o Mondrian, estas interfaces
precisam ser implementadas usando as APIs do Mondrian.
3.2.1 WCF
O Jpivot utiliza um conjunto de APIs, empacotadas sobre o nome de WCF - Web
Component Framework, para dar suporte a construo de componentes de interface com o
usurio (JPIVOT, 2005).
O WCF um conjunto de classes Java que auxilia a criao, apresentao e
validao de formulrios HTML via XML e XSLT13. O WCF encapsula componentes
reusveis desenvolvidos para o Jpivot.
12
O WCF foi desenvolvido para ser facilmente
Tag Library uma coleo de Tags personalizveis que auxiliam no desenvolvimento de sistemas baseados
em HTML. Alguns exemplos de tarefas que podem ser feitas por Tag Libraries incluem processamento de
formulrios, acesso banco de dados, personalizao de componentes e outros.
13
XSLT uma linguagem de marcao XML usada para transformar documentos XML (WIKIPEDIA, 2005).
50
integrado com outras aplicaes Web como portais14, JSF (JavaServer Faces)15, Struts16 entre
outros.
3.2.2 Arquitetura
Brito (2004) explica que os scripts escritos em JSP devem conter as consultas na
linguagem MDX, tags relativas sintaxe JSP e tags pertencentes JSP tag library. Estes
scripts devem ser executados atravs de um navegador Web. O navegador submete o script a
um Web Server17 (Apache Tomcat18). O Web Server tratar a requisio e submeter a consulta
ao Mondrian, que por sua vez, submeter ao banco de dados relacional. A consulta retornada
pelo banco de dados ser processada pelo Mondrian atravs das camadas dimensional e
estrela, sendo os resultados remetidos camada de apresentao, neste caso, representada pelo
Jpivot. O Jpivot transforma em uma pgina Web, que visualizada pelo mesmo navegador
Web que fez a solicitao inicial.
A Figura 3.9 mostra um exemplo do retorno de uma consulta pelo Jpivot, onde se
pode observar uma operao de drill-down na dimenso de produtos. Nesta figura, observa-se
tambm a barra de ferramentas padro do Jpivot, onde esto disponveis todas as opes do
software, tais como consultas ad-hoc em linguagem MDX, operaes drill-down, drill-across,
gerao de grficos, impresso e exportao em formato xls, etc...
14
Um portal pode ser definido como o ponto nico de acesso, via Web, s informaes, servios e aplicaes de
uma empresa.
15
JSF. JavaServer Faces. Disponvel em: <https://javaserverfaces.dev.java.net.>. Acesso em: 20 set. 2005.
16
STRUTS. Apache Struts Project. Disponvel em: <http://struts.apache.org>. Acesso em: 20 set. 2005.
17
Um Web Server (Servidor Web) um aplicativo responsvel por fornecer ao computador do cliente (usurios
de sites e pginas eletrnicas), em tempo real, os dados solicitados (WIKIPEDIA, 2005).
18
O software Tomcat desenvolvido pela Fundao Apache, permite a execuo de aplicaes para web. Sua
principal caracterstica tcnica estar centrado na linguagem de programao Java, mais especificamente nas
tecnologias de Servlets e de Java Server Pages (JSP). TOMCAT. Apache Tomcat. Disponvel em:
<http://tomcat.apache.org>. Acesso em: 06 ago. 2005.
51
Figura 3.9 Retorno de uma consulta pelo Jpivot.

Fonte: (JPIVOT, 2005).
3.3 OpenI
O OpenI uma aplicao BI Open Source, em fase inicial de desenvolvimento
(atualmente na verso 1.1), que fornece uma soluo para anlise OLAP. O OpenI
disponibilizado como uma aplicao Web J2EE, e suporta servidores OLAP compatveis com
o padro XMLA, incluindo o Microsoft Analysis Services e Mondrian. O principal objetivo
desta ferramenta permitir ao usurio final analisar os dados de forma fcil e intuitiva. Devese salientar tambm, que esta ferramenta possui ainda pouca documentao disponvel.
O OpenI uma aplicao Web J2EE com a implementao padro executando no
servidor Web Apache Tomcat. Ele publica relatrios analticos baseados na Web a partir de
trs tipos de servidores de dados: Servidores OLAP, servidores de bancos de dados
relacionais e servidores de data mining.
A arquitetura do OpenI formada basicamente pelos seguintes componentes:
Componente de conexo (Connectors): A funo dos conectores "falar" o idioma
52
nativo das fontes de dados de anlise. Para os bancos de dados relacionais, o OpenI utiliza o
JDBC. Para os servidores OLAP, ele usa o XMLA como o protocolo padro de comunicao.
Para os servios de data mining, o OpenI integrado com a plataforma Open Source de data
mining The R project19. At a presente release, somente a conexo atravs do XMLA est
operacional. (Grifo nosso).
Componente de Relatrio (Report Definitions): O OpenI utiliza linguagens
especficas de definio de relatrio (RDL - Report Definition Language) para definir e
explorar os relatrios criados na plataforma. Para os relatrios em base de dados relacionais,
ele utiliza a RDL .jrmxl do JasperReports20. Para relatrios OLAP e data mining, ele
implementa sua prpria RDL baseada em XML.
Componente de interface com o usurio (User Interface): A Interface com o
usurio disponibilizada pelo OpenI rene outros projetos em uma nica plataforma, tornandoa amigvel aos usurios no-tcnicos, como os analistas de negcio. So utilizados
componentes dos projetos Jpivot e JfreeChart21, unificando-os como um consistente
framework Web de navegao.
Segurana: O OpenI utiliza a estrutura de segurana da plataforma J2EE, podendo
integr-la camada de segurana da base de dados de origem, permitindo desta forma um
completo controle de permisso de acesso a informao.
A Figura 3.10, mostra em detalhes a arquitetura do OpenI, onde pode-se observar os
componentes de interface com o usurio, relatrio, conexo e segurana ancorados no
servidor de aplicaes J2EE, alm das fontes de dados que podem ser servidores OLAP,
bancos de dados relacionais ou data mining.
19
THE R PROJECT. The R Project for Statistical Computing. Disponvel em: <http://www.rproject.org>.
Acesso em: 03 out. 2005
20
JASPERREPORTS. Free Java reporting library. Disponvel em: <http://jasperreports.sourceforge.net>.
Acesso em: 03 out. 2005.
21
JFREECHART. A free Java chart library. Disponvel em: <http://www.jfree.org/jfreechart>. Acesso em: 03
oct. 2005.
53
Figura 3.10 Arquitetura do OpenI.

Fonte: (OPENI, 2005).
3.4 Pentaho
O projeto Pentaho BI est em fase inicial de desenvolvimento e pretende ser uma
soluo Open Source completa para aplicaes BI, com o objetivo de fornecer s
organizaes solues de qualidade para o atendimento das necessidades de BI destas.
O projeto Pentaho BI planeja apresentar um conjunto completo de ferramentas de BI,
sendo uma soluo com suporte a relatrios, anlises, data mining e workflow22, mdias e
grandes empresas, atravs de uma srie de componentes que podem ser distribudos juntos ou
separados. O software ser capaz de emitir relatrios financeiros, anlises de vendas, anlises
de produtos e outras funes de negcios. Ele utiliza um mtodo de desenvolvimento,
distribuio e suporte, tornando possvel o modelo de negcios Open Source.
O Pentaho BI abrange principalmente as seguintes reas de aplicao:
Relatrios (Reporting): Fornece desde simples relatrios em uma pgina web at
22
Workflow a automao do processo de negcio, na totalidade ou em partes, onde documentos, informaes

ou tarefas so passadas de um participante para o outro para execuo de uma ao, de acordo com um conjunto
de regras de procedimentos (WIKIPEDIA, 2005).
54
relatrios de alta qualidade tais como relatrios de indicaes financeiras e relatrios ricos em
contedos como tabelas, grficos entre outros.
Anlises (Analysis): Permite consultas ad hoc, explorao interativa com operaes
slice-and-dice, drill-down e pivoting. Inclui front-end23 grfico para explorao dos cubos
OLAP.
Painis (Dashboards): Rene relatrios, anlises e outras exposies em um nico
local para simplificar o acesso, podendo ser customizado por usurio, role ou assunto.
Data mining: Descobre relacionamentos ocultos nos dados, que podem ser utilizados
para otimizar os processos de negcio e prever resultados futuros. Permite que os resultados
sejam exibidos em um formato de fcil entendimento ao usurio.
Workflow: Liga diretamente as medidas de desempenho de negcio aos processos,
promovendo um ciclo contnuo de melhorias.
A Figura 3.11 apresenta a arquitetura do Pentaho composta pelos mdulos de
apresentao, de infraestrutura, de integrao de dados e a origem destes dados.
Figura 3.11 Arquitetura do Pentaho.

Fonte: (PENTAHO, 2005).
23
Front-end uma interface de usurio que facilita a interao com a aplicao.
55
O projeto Pentaho BI, planeja oferecer uma soluo que poder ser utilizada por
desenvolvedores Java que utilizaro componentes do projeto para montar rapidamente
solues BI sob medida. Permite tambm a utilizao para empresas desenvolvedoras de
software que adicionem as funcionalidades de BI em seus produtos. O projeto pretende ainda
permitir aos usurios finais solues de BI com a qualidade dos softwares tradicionais, porm
com uma custo bem mais acessvel.
CONCLUSO
O DW e demais tecnologias relacionadas mostram-se ferramentas muito

interessantes para empresas que possuem grandes volumes de dados gerados e acumulados
durante sua existncia e necessitam utilizar estes dados de uma forma que eles possam
auxiliar os administradores destas empresas a tomarem decises estratgicas rpidas e com
segurana.
Esse trabalho apresentou uma fundamentao terica sobre as tecnologias
relacionadas com a soluo proposta, visando criar o embasamento necessrio para a
implementao desta soluo. Foi feita tambm, uma descrio das caractersticas das
ferramentas de distribuio gratuita e/ou Open Source visando escolher quelas que atendem
as necessidades do projeto.
Pela anlise efetuada, as ferramentas escolhidas foram o Mondrian e o Jpivot, devido
ao seu maior grau de maturidade e principalmente uma maior disponibilidade de
documentao em relao s outras ferramentas analisadas. Outro ponto importante para a
escolha, foi a comprovao por Brito (BRITO, 2004) sobre a qualidade e flexibilidade
apresentadas por estas duas ferramentas.
Os projetos OpenI e Pentaho encontram-se ainda em fase inicial de
desenvolvimento, carecendo de documentao e comprovao de casos de uso, no possuindo
portanto, a maturidade necessria para a utilizao no desenvolvimento do projeto. Cabe
observar que, principalmente a ferramenta Pentaho, apresenta uma proposta bastante
promissora alm de um processo acelerado de desenvolvimento, o que a credencia para que
possa vir a ser avaliada em projetos semelhantes no futuro.
As ferramentas escolhidas sero utilizadas para o desenvolvimento da soluo
proposta que, de acordo com o cronograma apresentado no anteprojeto, ser efetuado durante
o Trabalho de concluso II.
REFERNCIAS BIBLIOGRFICAS
AMARAL, Glenda Carla Moura. AQUAWARE: Um ambiente de suporte qualidade de

dados em Data Warehouse. Rio de Janeiro, 2003. Dissertao (Mestrado em Informtica) Universidade
Federal
do
Rio
de
Janeiro
UFRJ.
Disponvel
em
<http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Glenda/Tese_Glenda.pdf>. Acesso
em 02 out. 2005.
ANZANELLO, Cynthia Aurora. OLAP conceitos e utilizao. Instituto de Informtica,
UFRGS.
Disponvel
em:
<http://www.inf.ufrgs.br/~clesio/cmp151/cmp15120021/
artigo_cynthia.pdf>. Acesso em 02 out. 2005.
BARBALHO, Patrcia. Descubra o Data Warehouse: produtividade e rapidez. Revista SQL
magazine. Edio 3, 2003.
BARBIERI, Carlos. Business Intelligence: modelagem e tecnologia. Rio de Janeiro: Axcel
Books, 2001.
BISPO, Carlos Alberto Ferreira. Uma anlise da nova gerao de sistemas de apoio
deciso. So Carlos, 1998. 160 p. Dissertao (Mestrado) - Escola de Engenharia de So
Carlos, Universidade de So Paulo. Disponvel em: <http://www.teses.usp.br
/teses/disponiveis/18/18140/tde-04042004-152849/publico/dissertacao_carlos.pdf>. Acesso
em: 06 ago. 2005.
BRAGA, Andr Luiz. Um arcabouo para a implementao de Data Warehouses
estendidos com tipos abstratos de dados. Rio de Janeiro, 2004, 280 p. (COPPE/UFRJ, D.
Sc., Engenharia de Sistemas e Computao, 1998) Tese - Universidade Federal do Rio de
Janeiro. Disponvel em: <http://ge.cos.ufrj.br/twiki/pub/Main/TesesDeDoutoradoOrientadas/
DataWarehouseparaTADs-10102004-Versaofinalregistro.pdf>. Acesso em: 20 set. 2005.
BRITO, Maiquel de. Proposta de um Data Warehouse de informaes acadmicas. Novo
Hamburgo: 2004. 111 p. Projeto de Diplomao (Bacharelado em Cincia da Computao)
Instituto de Cincias Exatas e Tecnolgicas, Centro Universitrio Feevale, Novo Hamburgo.
CAMPOS, Maria Luiza; FILHO, Arnaldo V. Rocha. Data Warehouse. Disponvel em
<http://genesis.nce.ufrj.br/dataware/tutorial/home.html>. Acesso em: 20 de set. 2005.
CIELO, Iv. Arquiteturas OLAP. Disponvel em <http://www.datawarehouse.inf.br/artigos/
olap.asp>. Acesso em: 20 de set. 2005.
58
COSTA, Andr Fernandes; ANCIES, Felipe Curvello. Aspectos de criao e carga de um
ambiente de Data Warehouse. Rio de Janeiro: 2001. 111 p. Projeto de Diplomao
(Bacharelado em Informtica) Departamento de Cincia da Computao, Universidade
Federal do Rio de Janeiro. Disponvel em: <http://dataware.nce.ufrj.br:8080/dataware/
publicacoes/dataware/fisico/projetosFinais/datawarehousing/COSTA-ANCIAES-2001.pdf>.
Acesso em: 20 de set. 2005.
CUNHA, Jos Antonio da. Arquiteturas de ferramentas OLAP. 2004. Disponvel em:
<http://www.engcomp.ufrn.br/~max/cefet/banco2/Arquitetura_OLAP.ppt>. Acesso em: 20
set. 2005.
ECLIPSE. Eclipse Foundation. Disponvel em: <http://www.eclipse.org>. Acesso em: 06
ago. 2005.
FORTULAN, Marcos Roberto; FILHO, Eduardo Vila Gonalves. Uma proposta de
aplicao de Business Intelligence no cho-de-fbrica. So Carlos, SP: 2005. Disponvel
em: <http://www.scielo.br/pdf/gp/v12n1/a06v12n1.pdf>. Acesso em: 03 out. 2005.
GARTNER. Gartner Group. Disponvel em: <http://www.gartner.com>. Acesso em: 26 ago.
2005.
GRIMES, Seth. Open-Source Releases Invade the Reporting Market. Intelligent Enterprise.
Estados Unidos, 2005. Disponvel em: <http://www.iemagazine.com/showArticle.jhtml?
articleID=163100786>. Acesso em: 06 ago. 2005.
HOKAMA, Daniele Del Bianco et al. A modelagem de dados no ambiente Data
Warehouse. So Paulo: 2004. 121 p. Projeto de Diplomao (Bacharelado em Sistemas de
Informao) Faculdade de Computao e Informtica, Universidade Presbiteriana
Mackenzie.
Disponvel
em:
<http://meusite.mackenzie.com.br/rogerio/tgi/
2004ModelagemDW.pdf>. Acesso em: 20 set. 2005.
INMON, W. H. Como construir o Data Warehouse. 2. ed. Rio de Janeiro: Campus, 1997.
INMON, W. H. et al. Gerenciando Data Warehouse. So Paulo: Makron Books, 1999.
JASPERREPORTS.
Free
Java
reporting
library.
<http://jasperreports.sourceforge.net>. Acesso em: 03 out. 2005.
Disponvel
em:
JAVA. Java Technology. Disponvel em: < http://java.sun.com>. Acesso em: 06 ago. 2005.
JCP. Java Community Process. Disponvel em: <http://www.jcp.org>. Acesso em: 06 ago.
2005.
JFREECHART. A free Java chart library. Disponvel em: <http://www.jfree.org/jfreechart>.
Acesso em: 03 oct. 2005.
JSF. JavaServer Faces. Disponvel em: <https://javaserverfaces.dev.java.net.>. Acesso em:
20 set. 2005.
59
JPIVOT. A JSP based OLAP. Disponvel em: <http://jpivot.sourceforge.net>. Acesso em: 06
ago. 2005.
KIMBALL, Ralph; MERZ, Richard. Data Webhouse: Construindo o Data Warehouse para
a Web. Traduo: Edson Furmankiewicz, Joana Figueiredo. 1. ed. Rio de Janeiro: Campus,
2000.
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit: guia completo para
modelagem dimensional. 2. ed. Rio de Janeiro: Campus, 2002.
LOBO, Adilton. Modelagem de um estudo de caso utilizando a ferramenta
entidade/relacionamento, baseada no modelo de Peter Chen. Joinville, SC: 1998.
Disponvel em: <http://pages.udesc.br/~r4al/artentre.htm>. Acesso em: 14 nov. 2005.
MACHADO, Felipe N. R. Projeto de Data Warehouse: uma viso multidimensional. So
Paulo: rica, 2000.
MAZETTO, Carlos Alberto et al. SAD BI. Americana: 2004. 82 p. Projeto de Diplomao
(Bacharelado em Anlise de Sistemas) Centro Universitrio Salesiano de So Paulo,
Campus
Dom
Bosco
Americana,
SP.
Disponvel
em:
<http://geocities.yahoo.com.br/projetosadg7/Monografia.pdf>. Acesso em: 20 set. 2005.
MICROSOFT. Microsoft Corporation. Disponvel em: <http://www.microsoft.com>.
Acesso em: 06 ago. 2005.
MONDRIAN. Mondrian OLAP Server. Disponvel em: <http://mondrian.sourceforge.net>.
OPENI. Open Source Web Application for OLAP Reporting. Disponvel em:
<http://www.openi.org>. Acesso em: 06 ago. 2005.
PENTAHO. Open Source Business Intelligence. Disponvel em: <http://www.pentaho.org>.
PEREIRA, Denise Maciel. Uso do padro OIM de metadados no suporte s
transformaes de dados em ambiente de Data Warehouse. Rio de Janeiro, 2000.
Dissertao (Mestrado) Universidade Federal do Rio de Janeiro. Disponvel em: <
http://dataware.nce.ufrj.br:8080/dataware/publicacoes/dataware/fisico/teses/metadados/PEREI
RA-2000.pdf>. Acesso em: 01 out. 2005.
PERNAS, Ana Marilza da Rosa. Modelagem de um Data Webhouse voltado a produo e
comercializao de sementes. Pelotas: 2003. 70 p. Projeto de Diplomao (Bacharelado em
Cincia da Computao) Instituto de Fsica e Matemtica, Universidade Federal de Pelotas,
Pelotas.
Disponvel
em:
<http://www.ufpel.edu.br/prg/sisbi/bibct/acervo/info/2003/
mono_ana_pernas.pdf>. Acesso em: 20 set. 2005.
PRODANOV, Cleber C. Manual de metodologia cientfica. 3. ed. Novo Hamburgo:
Feevale, 2003.
60
PUC-RIO. Data Mining - conceitos, tcnicas, ferramentas e aplicaes. Rio de Janeiro,
2005. Disponvel em: <http://www.cce.puc-rio.br/informatica/dataminingcentro.htm>. Acesso
em: 03 out. 2005.
SING, Harry. Data Warehouse. So Paulo: Makron Books, 2001.
SPRAGUE, R. H.; WATSON, H. J. Sistemas de apoio deciso: colocando a teoria em
prtica. Rio de Janeiro: Campus, 1991.
STRUTS. Apache Struts Project. Disponvel em: <http://struts.apache.org>. Acesso em: 20
set. 2005.
THE R PROJECT. The R Project for Statistical Computing. Disponvel em: <http://www.rproject.org>. Acesso em: 03 out. 2005.
THOMSEN, Erik. OLAP: construindo sistemas de informaes multidimensionais. 2. ed.
Rio de Janeiro: Campus, 2002.
TOMCAT. Apache Tomcat. Disponvel em: <http://tomcat.apache.org>. Acesso em: 06 ago.
2005.
WIKIPEDIA. The free encyclopedia. Disponvel em <http://pt.wikipedia.org> Acesso em: 03
out. de 2005.
XML. Extensible markup language. Disponvel em: <http://www.w3.org/XML>. Acesso
em: 02 out. 2005.
XMLA.ORG.
XML
for
Analysis
Specification.
<http://www.xmla.org/docs_pub.asp>. Acesso em: 02 out. 2005.
Disponvel
em:

Artigo OLAP e DM Comercial

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Artigo OLAP e DM Comercial

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITRIO FEEVALE

PROPOSTA DE UMA FERRAMENTA OLAP EM UM DATA MART

Novo Hamburgo, novembro de 2005.

PROPOSTA DE UMA FERRAMENTA OLAP EM UM DATA MART

Centro Universitrio Feevale

Professor orientador: Juliano Varella de Carvalho

Novo Hamburgo, novembro de 2005.

Palavras-chave: Sistemas de Informao, Sistema de Apoio Deciso, Data

Keywords: Information Systems, Decision Support System, Data Warehouse, Data

Figura 1.1 Componentes de um ambiente BI............................................................................17

Quadro 1.1 Diferenas entre o ambiente operacional e DW...................................................20

LISTA DE ABREVIATURAS E SIGLAS

Application Programming Interface

Desktop On-Line Analytical Processing

Hybrid On-Line Analytical Processing

Java2 Plataform Enterprise Edition

Java Server Pages

Multidimensional On-Line Analytical Processing

On-Line Analytical Processing

On-Line Transaction Processing

Relational Data Base Management System

Relational On-Line Analytical Processing

Sistemas de Apoio Deciso

Sistema de Gerenciamento de Banco de Dados

Structured Query Language

Web Component Framework

World Wide Web

Web On-Line Analytical Processing

eXtensible Markup Language

XML for Analysis

Desde o incio da era computacional, as organizaes tm usado os dados de suas

1 SISTEMAS DE APOIO DECISO (SAD)

Para competir em um mercado globalizado, as empresas necessitam cada vez mais

Figura 1.1 Componentes de um ambiente BI.

Consultoria de pesquisas de mercado na rea de tecnologia da informao. GARTNER. Gartner Group.

Figura 1.2 Definio do DW.

1.1.2 Diferenas entre o Ambiente Operacional e o Ambiente DW

Figura 1.3 Ambiente operacional X DW.

Princpio de funcionamento Baseado em transaes

Baseado em anlise de dados

Valores dos dados

Valores atuais e volteis

Valores histricos e imutveis

Organizao dos dados

Dados correntes, atmicos, isolados

Dados histricos, integrados,

Natureza dos dados

Dinmicos, com atualizaes

Estticos, com atualizaes

Grande volume de inseres,

Grande volume de consultas

Figura 1.4 Granularidade dos dados.

A definio da granularidade de dados a etapa mais importante do projeto de um

Figura 1.5 DW X DM.

Figura 1.6 Extrao, transformao e carga de dados.

Figura 2.1 Exemplo de tabela de fatos.

Figura 2.2 Exemplo de tabela de dimenso.

Figura 2.3 Exemplo de tabela de agregados.

Figura 2.4 Modelo Star Schema.

Figura 2.5 Modelo Snowflake.

2.5 Cubo de dados

Figura 2.6 Cubo de dados.

Qual foi o valor das vendas realizadas por um determinado vendedor no ms

Quais foram os clientes atendidos por um determinado vendedor no primeiro