Data Warehiuse Na Prática

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO
RAFAEL GASTO COIMBRA FERREIRA
Data Warehouse na Prtica: Fundamentos e Implantao
Dissertao apresentada como requisito parcial

para a obteno do grau de Mestre em Cincia
da Computao
Prof. Dr. Marcelo Soares Pimenta

Orientador
Porto Alegre, abril de 2002.
CIP CATALOGAO NA PUBLICAO
Ferreira, Rafael Gasto Coimbra

Normas para Apresentao de Dissertaes do Instituto de
Informtica e do PPGC / Rafael Gasto Coimbra Ferreira Porto
Alegre: Programa de Ps-Graduao em Computao, 2002
71 f.:il.
Dissertao (mestrado) Universidade Federal do Rio Grande
do Sul. Programa de Ps-Graduao em Computao. Porto
Alegre, BR RS, 2002 Orientador: Marcelo Soares Pimenta.
1.Data WareHouse. 2.ETL 3.Metadados. 4. OLTP. 5.OLAP I.
Pimenta, Marcelo Soares. II. Titulo.
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitor: Profa Wrana Panizzi
Pr-Reitor de Ensino: Prof. Jos Carlos Ferraz Hennemann
Pr-Reitor Adjunto de Ps-Graduao: Prof Jaime Evaldo Fensterseifer
Diretor do Instituto de Informtica: Prof. Fhilippe Olivier Alexandre Navaux
Coordenador do PPGC: Prof. Carlos Alberto Heuser
Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro
AGRADECIMENTOS
Gostaria de agradecer a Deus,

minha querida esposa,
minha famlia, em especial a meus pais,
meus amigos,
meu orientador,
enfim, a todos aqueles que de alguma forma me ajudaram na realizao deste
trabalho.
SUMRIO
LISTA DE ABREVIATURAS E SIGLAS.........................................................7

LISTA DE FIGURAS.......................................................................................8
LISTA DE TABELAS....................................................................................10
RESUMO.......................................................................................................11
ABSTRACT...................................................................................................12
1INTRODUO............................................................................................13
1.1Proposta do Trabalho....................................................................................................................14
2CONCEITOS BSICOS..............................................................................15
2.1Sistema de apoio deciso.............................................................................................................15
2.2Data Warehouse ............................................................................................................................15
2.2.1Caractersticas bsicas de um Data Warehouse......................................................................16
2.3Processamento OLAP e modelagem de dados.............................................................................18
2.3.1Processamento OLAP...............................................................................................................19
2.3.2Modelagem de dados................................................................................................................19
2.4Data Marts .....................................................................................................................................22
2.5Arquitetura de Dados ...................................................................................................................22
3FERRAMENTAS PARA O PROJETO DE DATA WAREHOUSE.............25

3.1Microsoft Data Warehouse ..........................................................................................................25
3.1.1Componentes do Data Warehouse Framework........................................................................25
3.1.2Capacidades analticas de OLAP.............................................................................................26
3.1.3Arquitetura de servio de transformao de dados..................................................................26
3.1.4Anlise e apresentao dos dados............................................................................................26
3.2Oracle Data Warehouse ...............................................................................................................27

3.2.1Oracle Data Warehouse Framework........................................................................................27
3.2.2Processameto analtico on-line - OLAP...................................................................................28
3.2.3Arquitetura de servio de transformao de dados..................................................................28
3.3Sybase Data Warehouse ..............................................................................................................31
3.3.1Infra-estrutura para o Data Warehouse....................................................................................31
4METODOLOGIAS DE PROJETO DE DW: UMA ANLISE......................33

4.1A Metodologia de James Martin...................................................................................................33
4.2A Metodologia de Ralph Kimball.................................................................................................38
4.3A Metodologia de Vidette Poe.......................................................................................................40
4.4A Metodologia de Alan Perkins....................................................................................................43
4.4.1As fases para cada etapa da metodologia [PER 2000].............................................................43
4.4.2Fase de prottipo......................................................................................................................44
4.5Anlise das metodologias...............................................................................................................45
5PROPOSTA DE UMA METODOLOGIA PARA CRIAO DE DW..........46

5.1Ciclo de vida da metodologia........................................................................................................46
5.1.1Iteraes....................................................................................................................................48
5.1.2Ciclo de desenvolvimento........................................................................................................48
5.2Fluxo de trabalho da metodologia................................................................................................49
5.2.1Anteprojeto...............................................................................................................................49
5.2.2Definio..................................................................................................................................50
5.2.3Execuo..................................................................................................................................52
6ESTUDO DE CASO: DESENVOLVIMENTO DE UM PROJETO DE DW. 53

6.1Ambiente da Cia Zaffari................................................................................................................53
6.1.1Histrico...................................................................................................................................53
6.1.2Estrutura Operacional...............................................................................................................53
6.1.3Estrutura dos Dados..................................................................................................................54
6.1.4Transferncia de Dados............................................................................................................54
6.2Etapa de anteprojeto..................................................................................................................55
6.2.1Levantamento...........................................................................................................................55
6.2.2Planejamento............................................................................................................................56
6.3Etapa de definio......................................................................................................................57
6.3.1Planejamento detalhado............................................................................................................57
6.3.2Mdulo de atividades preparatrias......................................................................................57
6.3.3Mdulo de requisitos detalhados..........................................................................................57
6.3.4Arquitetura de dados................................................................................................................58
6.3.5Arquitetura funcional...............................................................................................................60
6.3.6Infra-estrutura...........................................................................................................................60
6.3.7Modelagem dimensional..........................................................................................................60
6.3.8Projeto da base de dados..........................................................................................................63
6.3.9Avaliao de produtos..............................................................................................................63
6.3.10Execuo da arquitetura funcional.........................................................................................63
6.3.11Aplicaes finais....................................................................................................................64
6.3.12Auditoria de dados..................................................................................................................64
6.4Etapa de execuo......................................................................................................................64
6.5Consideraes finais.......................................................................................................................64
7CONCLUSO..............................................................................................66
REFERNCIAS.............................................................................................69
LISTA DE ABREVIATURAS E SIGLAS
SSD
Sistemas de Suporte a Deciso
BD
Banco de Dados
DW
Data Warehouse
OLE
Object Linking and Embedding
OLAP On-Line Analytical Processing

OLTP On-Line Transation Processing
SGBD Sistema Gerenciador em Banco de Dados
SGBDM
Sistema Gerenciador em Banco de Dados Multidimensional
SGBDR
Sistema Gerenciador em Banco de Dados Relacional
SIG
Sistema de Informao Gerencial
SQL
Structure Query Language
SAD Sistema de Apoio a Deciso

DTS
Servio de Transformao dos Dados
LISTA DE FIGURAS
FIGURA 2.1: EXEMPLO DE DADOS BASEADOS EM ASSUNTOS..........16

FIGURA 2.2:EXEMPLO DE DADOS INTEGRADOS...................................17
FIGURA 2.3: EXEMPLO DE GRANULARIDADE........................................18
FIGURA 2.4: EXEMPLO DE UM CUBO.......................................................20
FIGURA 2.5: EXEMPLO DE UM CUBO.......................................................21
FIGURA 2.6: EXEMPLO SIMPLES DO MODELO ESTRELA.....................21
FIGURA 2.7: TOPOLOGIAS DE UM DATA WAREHOUSE........................23
FIGURA 2.8: ARQUITETURA DE UM DATA WAREHOUSE......................24
FIGURA 3.1: CAMADA INTERMEDIRIA DO SERVIDOR OLAP.............26
FIGURA 3.2: ARQUITETURA DE TRANSFORMAO DOS DADOS......26
FIGURA 3.3: ARQUITETURA ORACLE (FONTE [MIC 2000])...................27
FIGURA 3.4: EXEMPLO DA TABELA EXTERNA.......................................29
FIGURA 3.5: EXEMPLO DA INSERO DE MLTIPLAS TABELAS.......30
FIGURA 3.6: ESTRUTURA DO IQ ADAPTIVE SERVER............................31
FIGURA 4.1: MAPA DE ESTRADA DO PROCESSO.................................33
FIGURA 4.2: CICLO DE VIDA DE [KIM 98A]..............................................38
FIGURA 4.3: CICLO DE VIDA DE [POE 98]................................................41

FIGURA 4.4: CICLO DE VIDA DE [PER 2000]............................................43
FIGURA 5.1: CICLO DE VIDA REPETITIVO...............................................48
FIGURA 5.2: FLUXO DE TRABALHO DA METODOLOGIA......................49
FIGURA 6.1: BASES DE DADOS DE UM SERVIDOR...............................54
FIGURA 6.3: ESTRUTURA DE REPLICAO DOS DADOS....................59
FIGURA 6.4: ARQUITETURA FUNCIONAL................................................61
FIGURA 6.5: MODELO ESTRELA PARA O MODELO PROPOSTO.........62
LISTA DE TABELAS
TABELA 1 ANLISE DAS METODOLOGIAS DE PROJETO DE DW....45

TABELA 2 DESCRIO DOS SERVIDORES..........................................54
TABELA 3 RESUMO DAS METODOLOGIAS DE PROJETO DE DW E
PROPOSTA........................................................................................................66
RESUMO
Embora o conceito de Data Warehouse (doravante abreviado DW), em suas vrias

formas, continue atraindo interesse, muitos projetos de DW no esto gerando os
benefcios esperados e muitos esto provando ser excessivamente caro de desenvolver e
manter.
O presente trabalho visa organizar os conceitos de DW atravs de uma reviso
bibliogrfica, discutindo seu real benefcio e tambm de como perceber este benefcio a
um custo que aceitvel ao empreendimento. Em particular so analisadas
metodologias que serviro de embasamento para a proposta de uma metodologia de
projeto de DW, que ser aplicada a um estudo de caso real para a Cia Zaffari, levando
em conta critrios que so encontrados atualmente no desenvolvimento de um Data
Warehouse, um subconjunto das quais ser tratado no trabalho de dissertao.
Palavras-Chave: data warehouse, banco de dados, OLAP.
Date Warehouse in Practice: Foundations and Implementation
ABSTRACT
Although the concept of Data Warehouse (DW), in its various forms, still attracting
interest, many DW projects are not generating the benefits expected and many are
proving to be too expensive to develop and to keep.
This work organizes the concepts of DW through a literature review, discussing its
real benefit and how to realize this benefit at a cost that is acceptable to the company. In
particular methods are discussed to serve as a foundation for proposing a design
methodology for DW, which will be applied to a real case study for the CIA Zaffari,
taking into account criteria that are currently found in developing a data warehouse, a
subset of which will be treated in the dissertation.
Keywords: data warehouse, database, OLAP.
13
1 INTRODUO
Desde que as organizaes passaram a dar a devida importncia a bancos de dados

relacionais, todo o hardware e software, as metodologias e ferramentas, se concentraram
em mover grande volume de dados para os computadores, de forma to rpida, segura e
barata quanto possvel. As empresas passaram por uma fase de processamento de dados,
onde os computadores, conhecidos por mainframes (grandes computadores),
processavam um volume muito grande de dados. A partir da dcada de 90, as empresas
passaram a considerar que no s os dados processados eram valiosos mas tambm a
informao. A partir dela, se buscava atingir os principais objetivos da corporao.
Muitos sistemas de apoio a deciso surgiram para se poder manipular tais informaes.
Estvamos entrando na era da informao, configurando o que se convencionou
denominar de "Era da Informao.
Atualmente as empresas esto passando por uma nova era, onde se procura no
apenas gerar um volume enorme de informaes, mas aprender a trabalhar com elas,
obtendo as respostas necessrias. Por isto este perodo denominado "Era do
conhecimento", caracterizada pela capacidade que as pessoas tem em ver e conhecer o
mundo via informao.
Para [GEN 98] os especialistas da informtica tem estimado que somente uma
pequena frao dos dados processados em uma empresa est realmente disponvel para
usurios tomadores de decises, o que nos leva a concluso de que as empresas so ricas
em grande volume de dados, mas pobres em dados realmente teis. Para resolver esta
questo as organizaes esto implantando a tecnologia de Data Warehouse (DW) ,
provendo as pessoas chaves dentro da empresa com acesso a todo tipo de informao
necessria para a empresa sobreviver e prosperar no mercado competitivo.
Por exemplo, numa rede de supermercados, o setor de marketing est preocupado
em saber qual a faixa etria de seus clientes e os produtos mais consumidos por estes.
Os dados utilizados para gerar estas informaes podem ser extrados de uma fonte
nica ou mltipla, permitindo anlises e correlaes entre as vendas e clientes.
Por definio, um DW um banco de dados com informaes integradas atravs da
coleo de um ou mais sistemas que se tornam a base para a tomada de deciso [POE
98] . Um projeto em DW permite a obteno de dados (informaes) gerenciais a partir
de um grande volume de dados operacionais. Organizaes que buscam melhorar a
habilidade na tomada de suas decises podem ser prejudicadas pelo grande volume e
complexidade de dados disponveis em seus sistemas de produo operacional. Fazer
estes dados acessveis um dos desafios mais significantes para os profissionais de
informtica de hoje. Com respeito a este desafio, muitas organizaes escolhem
construir um Data Warehouse para elaborar informaes a partir dos seus dados
operacionais.
14
1.1 Proposta do Trabalho

O objetivo deste trabalho organizar e discutir os conceitos de Data Warehouse e de
sua real utilizao, abordando desde tpicos gerenciais como o real benefcio de DW e
de como perceber este benefcio a um custo que aceitvel ao empreendimento at
tpicos tecnolgicos envolvidos na construo de DW. Sero aplicados conceitos e
tarefas prticas na modelagem de um DW, usando como estudo de caso a modelagem
de DW para a empresa Cia. Zaffari, local de trabalho do autor.
O texto da presente dissertao est estruturado da seguinte forma:
Captulo 2Conceitos Bsicos: apresenta algumas definies relacionadas ao DW,
suas caractersticas, arquitetura e modelos.
Captulo 3Ferramentas para o projeto de Data Warehouse: descreve as
principais ferramentas para o projeto de DW, levando em conta seus componentes, sua
arquitetura e formatos de apresentao.
Captulo 4Metodologias de projeto de Data Warehouse: uma anlise: apresenta
uma abordagem sobre as metodologias de desenvolvimento para a construo de um
DW, considerando as principais caractersticas e os problemas de cada uma. Uma
anlise ainda feita sobre as ferramentas atuais dos principais fabricantes de DW,
mostrando suas solues, facilidades e vantagens de uso.
Captulo 5Proposta da metodologia para o desenvolvimento de Data
Warehouse para a Cia Zaffari: descreve uma proposta de metodologia para o projeto
de DW, apresentando um conjunto de critrios importantes para o sucesso do projeto e
abordando os problemas para a construo de um DW, levando em conta a extrao,
converso e migrao dos dados.
Captulo 6Estudo de Caso: apresenta uma aplicao sobre a metodologia proposta
no captulo anterior, considerando a sua aplicao na Cia Zaffari Comercio e Industria.
Os principais aspectos para o empreendimento de DW sero abordados, tais como: um
custo aceitvel, principais problemas e solues adotadas, alm dos seus reais
benefcios.
Captulo 7 Concluses: onde resumidos a contribuio deste trabalho, os
resultados alcanados e as limitaes existentes, alm da enumerao de alguns temas
de pesquisa interessantes (ou em aberto) neste domnio.
15
2 CONCEITOS BSICOS
Neste captulo, sero abordados conceitos bsicos necessrios para a compreenso

da proposta. Estes conceitos incluem sistemas de apoio a deciso (seo 2.1), Data
Warehouse (seo 2.2), processamento e modelagem de dados (seo 2.3), Data Marts
(seo 2.4) e arquitetura de dados (seo 2.5).
2.1 Sistema de apoio deciso

No passado, uma das principais preocupaes de uma empresa, estava no
armazenamento correto dos dados necessrios ao apoio da tomada de decises. Com
advento das novas tecnologias na rea de hardware e seu baixo custo de
armazenamento, permitiram que as empresas pudessem armazenar grandes volumes de
dados, para posterior extrao.Desde que as organizaes passaram a dar a devida
importncia a bancos de dados
Atualmente, se pode dizer que a grande riqueza de uma empresa, no est no
volume de dados armazenados, e nem nas informaes geradas pelos sistemas de
aplicao comercial (estoque, contabilidades e outros) e sistemas de informaes
gerenciais, mas pelo conhecimento da informao, isto , a forma correta de uso da
mesma.
Sistemas de apoio deciso (SAD), so sistemas que ajudam decisores a tomar
decises em situaes onde o julgamento humano uma contribuio importante ao
processo de resoluo, mas a limitao humana para processar informaes atrapalha.
2.2 Data Warehouse

Data Warehouse (DW) pode ser definido como um tipo de SAD, sendo uma fonte
de consultas de um empreendimento, uma base de dados analtica que d apoio a
processos decisrios. Segundo [PEK 96], Um processo um produto para a montagem
e administrao de dados provenientes de vrias fontes com o propsito de obter uma
viso simples e detalhada de parte de todo o negcio.
Um dos conceitos mais simples para a definir de maneira fcil e clara um DW :
Uma cpia dos dados de transaes, estruturada especificamente para consultas e
anlises, segundo [KIM 98].
Mas existem outros conceitos que podem ser usados para caracterizar um DW, tais
como:
16
Para [POE 98], um banco de dados analtico que usado como base
para os sistemas SAD. planejado para armazenar um grande volume de dados
somente de leitura, provendo acesso intuitivo;
Para [INM 97], um conjunto de bancos de dados integrados e baseados

em assuntos projetados para suportar as funes dos SAD, onde cada unidade de
dados est relacionada a um determinado momento;
DW um processo que aglutina dados de fontes heterogneas, incluindo

dados histricos e dados externos para atender a necessidade de consultas
estruturadas e ad hoc, relatrios analticos e de suporte a deciso, conforme
[HAR 96];
Para [GAR 98] um processo, no um produto, para a montagem e

administrao de dados provenientes de vrias fontes com o propsito de obter
uma simples e detalha viso de parte de todo o negcio.
De acordo com [COR 97], o principal objetivo de um DW de fornecer os subsdios
necessrios para a transformao de uma base de dados de uma organizao, geralmente
transacionais, on-line e operacional denominado banco de dados OLTP (On-Line
Transation Processing), para uma base de dados maior que contenha o histrico de
todos os dados de interesse existentes na organizao, denominado de banco de dados
OLAP (On-Line Analytical Processing) e tambm conhecido como DW propriamente
dito.
No contexto deste trabalho ser adotado como referencial conceitual a definio de
[POE 98] para o DW.
2.2.1
Caractersticas bsicas de um Data Warehouse
Um resumo das principais caractersticas bsicas de um DW ser apresentado a

seguir, a partir de [KIM 98]. Um maior detalhamento destas caractersticas pode ser
obtido em [PER 99], [INM 97] e [GRA 98].
2.2.1.1Organizao em assuntos
DW orientado aos principais assuntos, temas ou reas de negcio do
empreendimento. Sistemas comerciais clssicos so organizados em torno das
aplicaes da empresa. A Figura 2.1 mostra no caso de uma empresa de supermercados,
as aplicaes podem ser compra, estoque e venda de produtos. Os principais assuntos
podem ser fornecedor, anlise dos custos e cliente.
dados operacionais
data warehouse
comp
ra
ue
aplicaes
fornecedor
estoq
venda
anlise
assuntos
Figura 2.1: Exemplo de dados baseados em assuntos.
cliente
17
2.2.1.2Organizao em assuntos
De todos os aspectos do DW o mais importante o fato de ser integrado, no qual
ocorre quando os dados passam do ambiente operacional baseado em aplicaes para o
DW. A Figura 2.2 mostra um exemplo desta integrao.
dados
data
Aplicao 1:
m/f
m/f
Aplicao 2:
1/0
converso
Aplicao 3:
x/y
Aplicao 4:
mas/fem
Figura 2.2:Exemplo de dados integrados.

Nesta passagem, os dados fonte de sistemas OLTP so modificados e convertidos
para um estado uniforme de modo a permitir a carga no DW. Segundo [INM 97], o
processo de introduo dos dados no DW conduzido de forma que as muitas
inconsistncias da aplicao sejam desfeitas. Pouco importa, por exemplo, que os dados
existentes no DW, usados para representar masculino/feminino, so codificados como
m/f ou 1/0. O que realmente importa que alm de a codificao para o DW ser feito,
ele deve, ainda, ser feita de forma consistente e independente da aplicao de origem.
Caso os dados de uma aplicao estejam codificados como x/y, eles sero convertidos
medida que forem transferidos para o DW. Este processo de transferncia chamado de
extrao e ser melhor definido no terceiro captulo.
2.2.1.3No voltil
Os dados aps serem extrados, transformados e transportados para o DW esto
disponveis aos usurios somente para a consulta, logo no podem ser alterados. J no
ambiente de OLTP, os dados normalmente sofrem operaes de update, isto ,
operaes de insero, alterao e excluso, alm da consulta.
2.2.1.4Variao de tempo
O tempo de tem grande importncia no tratamento das informaes. So
necessrios, por exemplo, para se representar: a durao de eventos, o calendrio, as
previses e o tempo de vida de documentos ou de operaes. Restries temporais a
determinadas atividades so fatores fundamentais para modelar a interao entre as
diferentes atividades que podem ser executadas neste tipo de aplicaes. fundamental
a capacidade de manipulao do tempo e de informaes histricas para o planejamento
empresarial, a investigao de relaes causais e anlise retrospectiva [EDE 94].
18
No DW o elemento tempo fundamental. Dados existentes no DW no passam de
uma srie sofisticada de instantneos, capturados num determinado momento.
importante salientar que pelo grande volume de dados, a estrutura de chave de um DW
sempre contm algum elemento de tempo.
Quando os dados so considerados antigos, passam do detalhe corrente para o
detalhe mais antigo. medida que os dados so resumidos, passam do detalhe corrente
para os dados levemente resumidos e a seguir, dos dados levemente resumidos para os
dados altamente resumidos.
2.2.1.5 Metadados
Os metadados so os dados que descrevem e caracterizam dados ou conjuntos de
dados. A disponibilizao de metadados permite que usurios, com pouco
conhecimento sobre os dados, possam avaliar a compatibilidade dos dados com suas
aplicaes, sendo fundamental a existncia de metadados adequados tanto para
caracterizao quanto para a descrio e compreenso dos dados.
Provm informaes sobre a estrutura de dados e as relaes entre estas dentro ou
entre bancos de dados. So tambm informaes mantidas a cerca do DW em lugar das
providas pelo warehouse.
2.2.1.6 Granularidade
o nvel de detalhes dentro do banco de dados DW. Quanto mais detalhe, menor o
nvel de granularidade, consequentemente, maior o volume de dados armazenado. Esta
caracterstica uma das mais importantes, pois afeta profundamente o volume dos
dados que residem no DW e, ao mesmo tempo, afeta o tipo de consulta que pode ser
atendida. O volume de dados contidos no DW balanceado de acordo com o nvel de
detalhe de uma consulta. A Figura 2.3 mostra um exemplo de granularidade sobre o
registro de vendas de uma rede de supermercado contendo 24 lojas.
alto nvel de detalhe
baixo nvel de granularidade
baixo nvel de detalhe
alto nvel de granularidade
Figura 2.3: Exemplo de granularidade.

No alto nvel de detalhe, as vendas registradas so dirias, por loja, num total de 400
mil bytes por ms ou 2 mil registros por ms. Para o baixo nvel de detalhe, as vendas
so registradas por ms e loja, num total de 2 mil bytes ou 24 registros.
2.3 Processamento OLAP e modelagem de dados

Os dados armazenados em um DW so otimizados para a recuperao atravs de
processamento analtico e devem ser modelados de forma a apresentar os dados em uma
estrutura padronizada que permite alto desempenho de acesso. As prximas sees
apresentam os principais conceitos referentes ao processamento analtico e quanto
modelagem necessria para suport-lo.
19
2.3.1
Processamento OLAP
O processamento analtico On-Line (On-line Analytic Porcessing OLAP)

constitui-se de todas as atividades gerais de consulta e apresentao de dados numricos
e textos provenientes do DW, assim como as formas especficas de consulta e
apresentao que so exemplificadas por uma grande quantidade de ferramentas OLAP
[KIM 98a]. Sistemas OLAP ajudam analisas e gerentes a sintetizarem informaes
sobre a empresa atravs de comparaes, vises personalizadas, projeo dos dados e
anlise histrica em vrios cenrios sob situaes variadas e no uniformes.
Para a representao OLAP, podemos considerar trs diferentes abordagens: (a)
ROLAP (relacional OLAP Relational OLAPI), (b) MOLAP (Multidimensional OLAP
Multidimensional OLAP) e (c) HOLAP (Hbrido OLAP Hybrid OLAP).
ROLAP constitui-se de um conjunto de interfaces de usurio e aplicaes que d ao
banco de dados relacional caractersticas dimensionais [KIM 98a]. As tabelas de
sumrios so criadas no SGBD relacional, sendo que nenhum dado movido para o
OLAP Server. As tabelas de sumrios, quando necessrias so totalmente derivveis e
seus ndices criados automaticamente. A consulta tem baixo desempenho mas permite a
utilizao do padro SQL.
MOLAP constitui-se basicamente de um banco de dados multidimensional
(Multidimensional database MDDB) , atravs de um conjunto de interfaces de
usurio, aplicaes e banco de dados, com tecnologia proprietria [KIM 98a]. Os
MDDB armazenam seus dados em um cubo com vrias dimenses. Os dados so
trazidos para o servidor OLAP e organizados em arranjos com alto gro de agregao,
permitem consultas mais rpidas, quando comparadas a abordagem relacional. Suas
limitaes para a soluo MOLAP referem-se ao fato de serem sistemas proprietrios,
que no utilizam solues padro de banco de dados, a exemplo de que mudanas que
podem ocorrer no modelo dimensional provocam a reorganizao do prprio banco de
dados, pouca escabilidade, alm de no suportar a criao de ad hoc de vises
multidimensionais.
HOLAP constitui-se de uma nova tecnologia o qual combina as principais
caractersticas das abordagens ROLAP e MOLAP, com o objetivo de resolver os
principais problemas descritos anteriormente, em ambas abordagens. Os dados ficam
retidos no banco de dados SGBD, enquanto as agregaes ficam no MOLAP. Com
desvantagem, torna-se mais lento do que o modelo MOLAP quando a consulta feita
sobre dados bsicos.
2.3.2
Modelagem de dados
A modelagem pode ser descrita sobre dois aspectos: (a) a modelagem de dados
tradicional e (b) a modelagem multidimensional. Na modelagem tradicional as
entidades podem ser objetos (clientes, produtos, lojas) ou transaes (vendas, pedidos,
notas fiscais). Seus relacionamentos so explcitos, em outras palavras, as entidades se
relacionam de forma direta atravs dos atributos chave. As operaes esto direcionadas
a dados transacionais, orientada a dados atuais que mudam constantemente.
J na modelagem multidimensional, as entidades so dimenses que representam
resultados para um determinado perodo de tempo. Os relacionamentos so implcitos,
onde as entidades se relacionam indiretamente, atravs de outra entidade. As operaes
so direcionadas a dados analticos, orientada a dados histricos estveis.
20
2.3.2.1 Modelagem Dimensional
A principal caracterstica dos sistemas OLAP permitir a viso conceitual
multidimensional dos dados de uma organizao. A viso multidimensional mais
natural, fcil e intuitiva para o usurio, permitindo a viso dos negcios da empresa em
diferentes perspectivas. Para este tipo de anlise necessria uma modelagem
dimensional, uma alternativa para a modelagem entidade relacionamento e contm as
mesmas informaes [KIM 98a].
A idia da modelagem dimensional representar os tipos de dados de negcio em
uma estrutura do tipo cubo de dados. As clulas deste cubo contm valores medidos,
tais como unidades vendidas, lucro ou venda liquida e os lados do cubo definem
as dimenses dos dados, a exemplo de cliente, produto, fornecedor e tempo.
Um exemplo da representao do negcio em uma estrutura do tipo cubo, seria a
descrio que um executivo faz aos processos de sua empresa, como a venda de
produtos em uma variedade de lojas e verificar a performance ao longo do tempo,
conforme mostra a Figura 2.4. Se pensarmos no negcio em termos de um cubo com
nossas dimenses formando a base do cubo, o ponto de interseo das trs dimenses
dentro do cubo equivale a um ponto de medio para o negcio.
Lojas
Tempo
Produto
Figura 2.4: Exemplo de um cubo.
Nos banco de dados analticos que manipulam multidimenses, existem dois tipos
principais esquemas que so utilizados: (a) o esquema estrela (star scheme) e o (b)
esquema floco de neve (snowflake schema).
O esquema estrela utiliza-se dos mesmos componentes do diagrama entidaderelacionamento, como entidades, atributos, relacionamentos e chaves primrias,
existindo basicamente dois tipos de tabelas (entidades) denominadas de fato e
dimenso [KIM 98a]. Este modelo construdo por uma estrutura formada por uma
nica tabela de fatos (contendo dados numricos) relacionada com uma ou mais tabelas
de dimenso, conforme a Figura 2.5(a).
A tabela fato armazena instncias da realidade, representando as medidas do
negcio, que podem ser mensuradas de forma quantitativa [GRA 98]. Por exemplo, a
Figura 2.5(a) mostra a tabela de fato venda, o qual possui os atributos de valor da
venda, quantidade vendida e o custo de venda de um produto relacionada com as tabelas
de dimenso produto e cliente, permitindo identificar a quantidade vendida de um
produto por um certo cliente. A tabela de fato armazena grande quantidade de dados,
possuindo chave primria composta, formada por chaves estrangeiras, atravs das quais
se ligam as chaves primrias das tabelas dimenso.
21
Dimenso
estado
Dimenso
loja
Fato
venda
Dimenso
cliente
Dimenso
fornecedor
Dimenso
produto
(a) Esquema estrela
Dimenso
loja
Dimenso
fornecedor
Tabela
Fato
Dimenso
cliente
Dimenso
produto
Dimenso
Preo
(b) Esquema floco de neve

Figura 2.5: Exemplo de um cubo.
Para [KIM 98], as medidas do negcio, tambm chamadas de mtricas ou
indicadores, so informaes numricas sobre o negcio e so definidas em trs tipos
diferentes:
Aditivas: so as mais freqentes, podem ser somadas cruzando-se qualquer uma

de suas dimenses. Exemplo: lucro liquido;
Semi-aditivas: podem ser somadas atravs de apenas uma parte de suas

dimenses. Exemplo: quantidade em estoque, uma vez que no faz sentido
som-la atravs da dimenso tempo;
No aditivas: no podem ser somadas por nenhuma de suas dimenses. O

exemplo mais comum desse tipo de medidas so valores percentuais.
As tabelas dimensionais armazenam as descries textuais que ajudam na

identificao de um componente (registro) da respectiva dimenso [KIM 98]. Cada
tabela dimenso uma tabela no normalizada que armazena os dados sobre a dimenso
[HAR 96]. Armazenam pequena quantidade de dados, quando comparadas a tabela de
fatos. Possuem chave primria simples, permitindo a ligao com a tabela de fato ou
entre as tabelas de dimenso. Repare que a chave primria da tabela de fato,
representada pela Figura 2.6, composta pelas chaves primrias das tabelas de
dimenso com as quais ela se relaciona.
As tabelas dimensionais contm atributos sobre as entidades que so relacionadas s
medidas, ou seja sobre os dados que do alguma informao sobre a medida.
Dimenso
Produto
Dimenso
Vendedor
Fato
Vendas
CodProd
Descr
Medida
Dimenso
Loja
CodLoja
Nome
CodProd
CodLoja
CodVend
CodDia
QtdVend
VlVend
CodVend
Nome
Dimenso
Tempo
CodDia
CodMes
Figura 2.6: Exemplo simples do modelo estrela.
22
Um exemplo descrito na Figura 2.6 seria com relao medida quantidade
vendida. Existem vrios parmetros ou dimenses que atravs dos quais se pode
analis-la: (a) em que loja a compra foi feita? (b) quando ocorreu a venda? (c) que
produto foi vendido e (d) quem realizou a venda?
Como se pode ver na Figura 2.6, o esquema estrela altamente desnormalizado,
com o intuito bvio de reduzir o nmero de joins envolvidos nas consultas. Na verdade,
o modelo final de um DW composto por vrias tabelas de fato, contendo diferentes
subconjuntos de informaes sobre o negcio com diversas tabelas de dimenso, ligadas
a uma ou mais tabelas de fato.
O esquema floco de neve, representado pela Figura 2.5(b), uma variao do
esquema estrela os quais as tabelas dimenso so normalizadas, permitindo que se
liguem entre si, alm da tabela fato. Possui como vantagem no uso deste esquema a
economia de espao no armazenamento, tabelas dimenso menores, mas possui como a
principal desvantagem a complexidade sobre o numero de tabelas relacionadas,
tornando as consultas complexas.
2.3.2.2 Agregao de Dados
Em aplicaes de anlise de dados, um dos fatores mais crticos o tempo de
resposta ao usurio devido ao grande volume de dados envolvido nas consultas desse
tipo de aplicao. A nica maneira de reduzir o tempo de execuo das consultas de
maneira consistente pr-navegar ou consolidar os dados em totais e subtotais atravs
das dimenses envolvidas no assunto em questo. Mas de que forma se poderia agregar
cada dimenso? Essa uma questo mais simples do que se parece a princpio, j que
inerente ao ser humano agrupar em hierarquias todas as entidades que o cercam.
Agrupamos cidades em estados, regies e pases, produtos em linhas de produtos, meses
em trimestres e anos. Apesar das hierarquias no serem partes necessrias das
dimenses, as aplicaes que refletem negcios do mundo real com um mnimo de
complexidade sempre apresentam algumas hierarquias dimensionais a exemplo das
listadas acima. Sendo assim, a base para a agregao dos dados ser justamente o
conjunto das hierarquias existentes.
2.4 Data Marts

Segundo [COR 97], representa um subconjunto dos dados destinados a um usurio
especfico ou a um conjunto de grupos de usurios, implementados em servidores
departamentais de baixo custo, em plataforma Unix ou Windows NT.
Data Marts (DM) podem ser capturados de uma ou mais bases operacionais ou de
informaes externas. Em alguns casos, os dados armazenados no DM podem tambm
ter sido gerados localmente dentro de um departamento particular ou de uma rea
demogrfica.
2.5 Arquitetura de Dados

A arquitetura de dados para um projeto de DW pode ser dividida em duas partes: (a)
arquitetura geral dos dados ou topologias e (b) funcional. Na arquitetura geral dos
dados, se permite identificar e entender como os dados fluem atravs do DW. As
arquiteturas de dados mais comuns so:
23
Centralizada, caracterizada por um nico DW que atende a toda a

comunidade de usurios;
Data Marts dependentes, constitui-se de vrios DM ligados a um DW.
Cada DM tem um escopo de dados limitados orientados a um tema especfico do
negcio. Os usurios podem se conectar aos seus DM como ao DW;
Data Marts independentes, caracteriza-se pela ligao dos usurios aos

respectivos DM, as quais fornecem as informaes necessrias. Esta arquitetura
oferece uma rapidez no desenvolvimento, baixo custo e controle local, ao invs
do centralizado;
Data Warehouse Distribudo, consiste de vrios DW interligados atravs

de rede com forte suporte a processamento distribudo.
DW
DM
DW
DM
Topologia Centralizada
DM
Topologia DM
DM independente
Topologia DW e DM
DM dependente
Figura 2.7: Topologias de um Data Warehouse.

A maioria das organizaes tende a implementar um DW multi-tier, ou seja, um
DW em camadas, que amarram vrios DMs integrados a um DW corporativo em uma
arquitetura semelhante Figura 2.7, onde mostra algumas topologias de DW.
Para a arquitetura funcional, o DW, conforme a Figura 2.8, construdo a partir de
duas partes distintas. A primeira parte definida como rea interna, onde so feitas as
aquisies de dados a partir dos sistemas tradicionais ou de outras fontes quaisquer. O
dado identificado, copiado, formatado e preparado para ser carregado no repositrio
de dados do DW, que pode ser administrado atravs de banco de dados relacionais ou
multidimensionais. A rea de Staging armazena os dados que foram extrados de fontes
externas. A partir da os dados so tratados, limpos e carregados ao DW.
Area interna
Area externa
Data Warehouse
Fontes externas
Usurio
Staging Area
Extrao
Transformao,
limpeza e
agregao
CIP Catlogo na Plublicao
Ferramentas de acesso
aos dados, aplicao
Figura 2.8: Arquitetura de um Data Warehouse.
24
Segundo [PER 2000], ainda se pode descrever como partes desta rea: (a) a carga
dos dados, permitindo o armazenamento dos dados transformados no servidor de
apresentao, (b) controle dos dados organizados, permitindo o monitoramento sobre o
fluxo de dados, atravs dos metadados, (c) gerenciamento dos recursos da rea interna,
possibilitando que o DW volte a trabalhar normalmente aps a ocorrncia do problema.
A segunda parte definida como a rea externa, sendo a interface do usurio com o
sistema. , basicamente, o front-end que visto e no qual se trabalha, principalmente
atravs de consultas. [PER 2000] Fazem parte desta rea: (a) o servidor de apresentao,
onde os dados provenientes da parte interna, ficando a disposio dos usurios finais e
(b) ferramentas de acesso a dados e geradores de relatrios, permitindo aos usurios
finais consultas ad hoc. Tais ferramentas permitem operaes que facilitam o acesso aos
dados, possibilitando aumentar ou diminuir o nvel de detalhes das consultas as tabelas
dimenso e fato atravs dos seguintes recursos:
Drill-up/drill-down: permite navegar entre nveis de agregao, por

agrupar e desagrupar dados progressivamente [POE 98];
Pivoting: permite agregar duas dimenses para comparar o resultado. Na
prtica, corresponde a modificao da posio das dimenses em um grfico ou
troca de linhas por colunas em uma tabela [DBM 2001];
Slice and dice: possibilita ver os dados de diferentes pontos de vista,
reduzindo a dimensionalidade dos dados. Slice compreende a extrao de
informaes sumarizadas em um cubo de dados e Dice a extrao de um
subcubo ou a interseco de vrios slices;
Data Mining: o [DWM 2001] processo de encontrar padres ou
correlaes entre milhares de campos em grandes bases de dados. Informaes,
que aparentemente esto camufladas ou escondidas, permitindo agilidade na
tomada de decises. Maiores detalhes sobre Data Minig esto disponveis em
[FAY 96], [DAM 2000] e [GRA 98].
Se pode ainda obter um maior detalhamento sobre a rea externa em [KIM 98a].
25
3 FERRAMENTAS PARA O PROJETO DE DATA

WAREHOUSE
A informao em Data Warehouse se encontra integrada e organizada em reas de

interesse para a empresa. Sua arquitetura se modificar ao longo do tempo, refletindo a
natureza iterativa do processo. O processo de DW inerentemente complexo, caro e
longo, requerendo mudanas constantes ao longo do ciclo de vida dos aplicativos
operacionais. Este captulo apresenta um estudo de alguma das principais ferramentas
disponveis no mercado, Microsoft DW (seo 3.1), Oracle DW (seo 3.2), Sybase
DW (seo 3.3).
3.1 Microsoft Data Warehouse

A Microsoft, ao longo de vrios anos, tem tentado criar uma plataforma para Data
Warehouse que possa ser usada para diminuir custos e melhorar a eficincia dos
processos relativos ao ciclo de vida de tal sistema. Esta plataforma foi batizada de
Microsoft Data Warehouseing Framework, possibilitando a integrao de produtos de
diversos fabricantes, na tentativa de prover ao cliente uma escolha livre e facilitada na
hora de desenvolver sua poltica para DW. Adicionalmente, existe a necessidade de se
ter metadados integrados, das mais diferentes fases do projeto do DW. Finalmente,
deve-se prestar ateno nos servios bsicos de gerenciamento, armazenamento, ajuste
de desempenho, alertas e notificaes.
3.1.1
Componentes do Data Warehouse Framework
Data Warehouse Framework descreve os relacionamentos entre vrios componentes

usados no processo de construo, uso e gerenciamento de sistema DW Os dois
componentes bsicos dessa abordagem so: (a) a camada de transporte de dados (OLE
BD) e o repositrio integrado de metadados. A construo do DW requer um conjunto
de ferramentas para descrever o projeto lgico e fsico das fontes de dados e seus
destinos nos DWs e DMs. J as ferramentas para usurios finais devem acessar um
servio de diretrio que permita a busca de dados apropriados e relevantes para resolver
as questes do negcio, alm de uma camada de segurana entre usurios e os sistemas
servidores.
Microsoft Repository prov a integrao para o metadados de todo o ciclo de projeto
possibilitando compartilhamento das informaes e a integrao transparente de vrias
ferramentas heterogneas, sem a necessidade de interfaces especializadas entre cada
produto.
26
3.1.2
Capacidades analticas de OLAP
Microsoft Decision Support Services (DSS) um aplicativo OLAP, dotado de vastas

funcionalidades, componente da Microsoft SQL Server 7.0. Microsoft DSS inclui um
servidor na camada intermediria (middle-tier), conforme a Figura 3.1, que permite aos
usurios efetuar anlises sofisticadas em grande volume de dados, gerando resultados
altamente satisfatrios. Um segundo componente do Microsoft DSS um servidor (do
lado do cliente, para cache e clculos) chamado PivotTable. Este ajuda na melhoria do
desempenho das consultas e na reduo do trfego na rede.
Transaction
Database
DTS
SQL Server
Aggs
Details
Analysis DB
OLE DB
MS DSS
Server
MD Cache
OLE DB
For
OLAP
Clients
SQL Server
Figura 3.1: Camada intermediria do servidor OLAP.

3.1.3
Arquitetura de servio de transformao de dados
A definio do servio de transformao de dados so armazenados no repositrio

da Microsoft SQL Server ou em arquivos estruturados COM. Os dados operacionais so
acessados usando OLE DB, fornecendo acesso a fontes de dados relacionais e a fonte de
dados no relacionais. A Figura 3.2 descreve a estrutura de transformao dos dados,
onde o data pump executa funes de um script para copiar, validar ou transformar os
dados da fonte para o destino. Podem ser criados objetos de transformao padronizados
para a busca de dados avanada. Os novos valores para o destino so retornados ao data
pump e enviados ao destino atravs da transferncia de dados de alta velocidade.
Origem
Xforms
Destino
DTS Data Pump
IN
OUT
Figura 3.2: Arquitetura de transformao dos dados.

Transformaes complexas e validao de dados lgica podem ser implementadas
usando um componente activex script. Estes scripts podem invocar mtodos de qualquer
objeto OLE para modificar ou validar o valor de coluna.
3.1.4
Anlise e apresentao dos dados
A Microsoft prov aplicativos para consultas em DW. Por exemplo, Microsoft

Access e Excel oferecem recursos para formulao de consultas e anlises da
informao no DW. Em anexo ao SQL Server 7.0, existe um componente denominado
English Query, que permite aos usurios formular consultas utilizando sentenas da
27
lngua Inglesa. Adicionalmente, atravs do DW Framework, muitos outros produtos

tornam-se disponveis para visualizao e anlise dos dados.
A filosofia fundamental do Microsoft Data Warehousing Framewowrk a abertura
da soluo a outras companhias de software. Atravs da utilizao dos padres de
interfaces para banco de dados ODBC e OLE DB, dzias de produtos podem acessar e
manipular dados guardados em sistemas relacionais. Devido a essas funcionalidades,
empresas so capazes de selecionar as ferramentas analticas mais apropriadas para suas
necessidades.
3.2 Oracle Data Warehouse

O Oracle9i Database oferece uma infra-estrutura completa e integrada para anlise e
data warehouse. As solues de business intelligence do Oracle9i so menos complexas,
menos caras e mais rpidas de implementar. A lista abaixo destaca os recursos do banco
de dados Oracle9i e seus compomentes associados, proporcionando uma plataforma de
e-business intelligence completa:
Inovadores recursos de ETL (Extration, Transformation and Load ou

Extrao, Transformao e Carga) incorporados ao banco de dados atualizados
dinamicamente;
Servios de OLAP e funes SQL fornecem anlise comercial e de

mercado rica, robusta e de alta qualidade.
Os recursos de extrao, transformao e carga (ETL, Extraction, Transformation
and Load) do Oracle9i Database tornam mais fcil integrar dados de muitas fontes
diferentes. Os recursos de data warehouse lhe permitem armazenar e acessar grandes
volumes de dados com alta performance. A funcionalidade avanada de OLAP
(processamento analtico on-line) e data mining o ajudam a detectar tendncias e fazer
previses.
3.2.1
Oracle Data Warehouse Framework
A arquitetura Oracle Web chamada de NetWork Computing Architecture (NCA)

que um framework e que faz a mudana da tecnologia cliente/servidor para Web. Esta
arquitetura, conforme a Figura 3.3, tem cinco camadas lgicas que so: (a) source, (b)
data, (c) olap/application, (d) publication e (e) presentation.
Figura 3.3: Arquitetura Oracle (fonte [MIC 2000]).
28
A camada Source onde ficam os vrios tipos de dados transacionais, dados de

sistemas legados nos maiframes, das aplicaes clliente/servidor e tambm configurar
dados externos. Esses dados so transformados e desnormalizados para atingirmos uma
tima performance de consulta. Eles so transportados para as tabelas Oracle do
Dataware ou Data Mart.
J na camada Date, ficam armazenados os dados de apoio a deciso. A Oracle
implementa uma estratgica bem interessante onde ela coloca tanto os dados de DW e
DM. Os dados de DM para consultas ah hoc, a Oracle utiliza o Express Server com
acesso relacional.
na camada OLAP/Application aonde se realiza toda a lgica do processamento.
Alm do software que faz o processamento so colocados cartuchos de ligao para
integrarem o processamento aos dados.
3.2.2
Processameto analtico on-line - OLAP
A Oracle Express uma famlia de produtos voltada para o processamento OLAP,

includo funes de consulta, anlise e relatrio. Dentre os produtos que compem a
famlia Oracle Express, se destaca:
Oracle Express Server: baseado no modelo multidimensional,

otimizado para consultas e anlises de dados corporativos tais como vendas,
marketing, manufatura ou recursos humanos, sem necessitar de programas ou
relatrios especiais dos sistemas de informao;
Oracle Express Analyzer: uma ferramenta orientada-objeto de

navegao, acesso e anlise de dados sumarizados em um DW ou DM Com um
conjunto visual de ferramentas desktop para seleo, visualizao, anlise,
anotao e compartilhamento dos dados da corporao, Express Analyser
disponibiliza o poder do processamento analtico on-line para usurios de
qualquer rea, inclundo vendas, marketing, operaes, vendas, manufatura e
finana;
Oracle Express Objects: um ambiente de desenvolvimento de
aplicaes orientado-objeto que tem controles data-aware para visualizao e
manipulao dos dados e suporta desenvolvimento visual como programao
orientada a evento.
3.2.3
Arquitetura de servio de transformao de dados
O banco de dados de Oracle9i introduz uma nova abordagem para entrada de dados
integrando isto no prprio banco de dados. A maioria de produtos de ETL no tem o
paralelismo e extensa otimizao, caractersticas existentes no banco de dados Oracle9i.
Esta verso de banco de dados, permite criar um novo paradigma de ETL,
possibilitando a eliminao de certas etapas e redefinindo (remodelando) outras etapas
para aumentar o fluxo de dados e transformao dos dados, aumentando e escabilidade e
eliminando as interrupes. Possui o conceito de ETL toolkit, um conjunto de
ferramentas que possibilita aumentar a capacidade de ETL no DW, tais como:
29
Change Data Capture: a captura de dado alterado um importante

elemento para otimizar a extrao de uma base de dados de origem. Em vez de
fazer a extrao completa de todos os dados de origem, somente as alteraes e
incluses de novos dados so considerados;
External Tables: vrias interaes so necessrias entre os dados
armazenados na base de dados destino e dados na base de origem. Tabelas
Externas do Oracle9i permitem que dados externos possam ser expostos para
usurios como qualquer outro dado armazenado em tabelas normais. Como
resultado, a tabela externa atua como uma tabela virtual, possibilitando a
manipulao e juno com os dados de origem, antes dos dados serem realmente
carregados, como mostra a Figura 3.4;
Create table produto_ext (id prod,
nome prod, , preo) organization
external as
Arquivo da base de origem
10, Carne, , 10,00
20, Po, , 0,50
30, Bolacha, , 1,10
Criao
Uso
Produto_ext
Id Prod
.
.
Nome Prod
.
.
Preo
.
.
Select * from produto_ext
Figura 3.4: Exemplo da Tabela Externa.
Multi-Table Insert: em certas situaes, dados de origem devem ser

carregados, baseados na lgica de atributos, em diferentes objetos de
destino.Freqentemente nos ambientes de DW os dados de origens so
carregados na mesma tabela destino. Multi-Table Insert oferece um novo
comando de SQL para resolver esta questo de transformao e carga, onde
dados podem ir para diferentes tabelas de destino, dependendo das regras de
transformao do negcio. Como mostra a Figura 3.5, o comando Insert...Select
permite que diferentes tabelas de destino participem, dependendo de condies
estabelecidas na clausula where do comando Insert;
30
Clientes
Arquivo da base de origem
Id Cli
30
10, Joo,, 1000,00

20, Jos,, 5000,00
30, Telmo,, 300,00
Insero
em mltiplas
tabelas
Nome
Telmo
Compra
300,00
Clientes especiais
Id Cli
10
20
Nome
Joo
Jos
Compra
1000,00
5000,00
Figura 3.5: Exemplo da Insero de Mltiplas Tabelas.
Upserver: depois da carga inicial, o ambiente de DW precisa ser vrias

vezes atualizado para refletir as mudanas geradas pelos dados de origem.
Muitas vezes, os sistemas de origem dos dados no destinguem as recentes
incluses ou alteraes durante a extrao. Desta forma, o Upserver extende o
comando Merge no SQL para oferecer a capacidade de alterar ou inserir
condicionalmente linhas na tabela destino. O exemplo abaixo mostra o comando
Merge o qual permite identificar quando ocorreu uma alterao ou incluso,
sobre os dados de origem, provocando a mesma operao na tabela destino.
Exemplo: MERGE INTO produtos t USING produtos_origem s
ON t.codproduto=s.codproduto
WHEN MATCHED THEN
UPDATE SET t.preco = s.preco
WHEN NOT MATCHED THEN
INSERT (t.codproduto, , t.preco) VALUES
(s.codproduto,...,s.preco)
3.2.4
A Oracle Discoverer uma ferramenta de consulta e de anlise que permite obter

informaes especficas dos complexos bancos de dados de produo. Projetada tanto
para usurio final quanto para especialistas de gerenciamento de sistemas de
informao, ela permite que usurios executem anlise de negcios, criem relatrios de
negcios e grficos sem qualquer necessidade de conhecimento de programao ou
experincia em banco de dados. O objetivo esconder do usurio a complexidade de
banco de dados.
31
3.3 Sybase Data Warehouse

A Sybase desenvolveu uma nova abordagem de DW permitindo que uma grande
quantidade de usurios possam manipular repositrios em escala de terabytes de dados.
Estas propriedades so encontradas no Sybase Adaptive Server IQ Multiplex (ASIQ).
Com o ASIQ, os processos de churning, dataming e anlises feitas por um grande
nmero de usurios passaram a ser uma realidade em empresas de diferentes reas do
mercado. As principais caractersticas do ASIQ so descritas a seguir:
possibilita acesso rpido s informaes da empresa;
finaliza as consultas sem retorno, quando da no liberao dos dados pelo

usurio ou por tempo excessivo despendido;
oferece uma reduo na rea fsica de armazenamento de dados de at 80%;
compatvel com as melhores ferramentas de visualizao e informao existentes

no mercado.
A Figura 3.6 abaixo mostra e estrutura e funcionalidade do IQ Adaptive Server da

Sybase, oferecendo um suporte heterogneo a dados de diferentes origens, incluindo
Oracle, DB2, Informix e demais arquivos de origem de aplicao, como planilhas e
editores.
Sysbase
DB2
Adaptive
Server
Oracle
Sysbase
Adaptive
Server
Query
Tools
OLAP
Tools
Data
Mining
Tools
Browsers
Others
Figura 3.6: Estrutura do IQ Adaptive Server.
3.3.1
Infra-estrutura para o Data Warehouse
A Sybase possui o Industry Warehouse Studio IWS, uma infra-estrutura de Data

Warehouse pr-construda, disponvel na forma de um pacote, que consiste em um
modelo empresarial vertical para atender s necessidades de setores e clientes
especficos. um sistema flexvel e aberto que se integra de modo compatvel com os
investimentos tecnolgicos existentes nas empresas. O IWS oferece aplicativos para
diversos setores verticais, tais como: servios bancrios, seguradoras, cartes de crdito,
telecomunicaes. Possui uma viso de escala empresarial, permitindo que as empresas
construam DW que possam integrar dados provenientes de diferentes setores,
flexibilizando o ambiente empresarial. Possui como principais caractersticas:
32
Uso de tcnicas de modelagem dimensionais, que aperfeioam o

desenvolvimento do DW, melhorando a escabilidade e tornando os dados mais
acessveis aos usurios;
Possui arquitetura modular, capaz de suportar as implementaes em fases e

aquelas que renem aplicativos para diversos setores, a exemplo de um banco
fundir-se com uma seguradora;
Um processo simples de personalizao para o cliente, usando as ferramentas

CASE (Engenharia de Software Auxiliada por Computador) da Sybase, o Power
Designer Warehouse Architect e Warehouse Control Center;
Suporte a uma ampla variedade de plataformas RDMS, tais como IBM DB2,
Microsoft SQL Server, Oracle e Informix.
3.3.2
O IWS oferece uma parceria com os fornecedores de ferramentas de visualizao

estratgicas, tais como: Business Objects, Cognos, MicroStrategy e SGI. Estas
ferramentas podem proporcionar um nvel de integrao que assegura a implementao
mais rpida de mdulos empresariais com base no ambiente IWS embutido.
33
4 METODOLOGIAS DE PROJETO DE DW: UMA

ANLISE
Este captulo apresenta um estudo de algumas metodologias de projeto de DW que

serviro como fundamentao terica para a proposta de uma metodologia a ser
aplicada no projeto de DW da Cia Zaffari.
Inicialmente sero descritas as propostas encontradas em [MAR 99], [KIM 98a],
[POE 98] e [PER 2000]. No final deste, encontra-se uma anlise das propostas
levantadas e suas limitaes, permitindo selecionar as caractersticas mais adequadas a
serem utilizadas como referencial para o resto deste trabalho.
4.1 A Metodologia de James Martin

A proposta de [MAR 99] apresenta um conceito PACE (Planejar, Ativar, Controlar e
Encerrar) no qual os processos que compem o ciclo de vida do projeto (o qual
referenciado como sendo o mapa de estrada do processo) do DW so iterativos, portanto
alguns so repetidos. As fases do ciclo de vida, conforme mostra a Figura 4.1, do
projeto de DW so: (a) viso estratgica, (b) avaliao da engenharia da empresa, (c)
avaliao do fluxo de valores, (d) caso comercial do DW, (e) projeto e reviso da
arquitetura, (f) avaliao da questo comercial, (g) plano de implementao da iterao,
(h) projeto detalhado, (i) implementao, (j) transio para a produo e (k)
manuteno.
Viso estratgica
Avaliao da
engenharia da
empresa
Avaliao do
fluxo de valores
Avaliao da
questo comercial
Projeto/ Reviso
da arquitetura
Caso comercial do
DW
Plano de
implementao da
iterao
Projeto detalhado
Implementao
Manuteno
Transio para a
produo
Figura 4.1: Mapa de estrada do processo.
34
Na fase de viso estratgica, tambm chamada por [MAR 99] de plano de
informaes estratgicas (SIP- Strategic Information Plan), um processo contnuo que
alinha as estratgicas comercial e tecnolgica da empresa dentro do mercado. Esse um
pr-requisito para os estgios de engenharia da empresa e re-engenharia do processo
comercial. Algumas empresas possuem um SIP pronto, e ele pode servir como semente
da qual o projeto do data warehouse se desenvolve.
A fase de avaliao da engenharia da empresa (EEA-Enterprise Engineering
Assessment) desenvolve uma viso em nvel de empresa da necessidade de mudana da
organizao e sua prontido em aceit-la. Um data warehouse no uma soluo para
tudo. Se uma organizao no possui fontes e recursos de dados, um warehouse no
poder ser eficiente. Antes de realizar um projeto de data warehouse, a organizao
deve decidir se deseja resolver problemas de dados operacionais por meio da reengenharia comercial, desenvolvimento de sistemas ou planejamento de sistemas de
informao. Essa avaliao normalmente um pr-requisito para a reengenharia do
processo comercial ou para uma avaliao do fluxo de valores.
Pela fase de avaliao do fluxo de valores (VSA- Value Stream Assessment) se
podem solucionar problemas comerciais estudando o(s) fluxo(s) de valores de uma
empresa a partir de um alto nvel por um pequeno perodo (seis a oito semanas),
procurando meios de melhorar os desempenhos gerenciais, operacionais, sociais e
tecnolgicos. O processo identifica o fluxo de valor predatrio a capacidade exclusiva
que lhe permite mover mais rpido e produzir melhor do que seus concorrentes e suas
reas vulnerveis da fatia de mercado. O conhecimento fornecido pela tecnologia de
data warehouse d suporte para a VSA.
Na fase de desenvolvimento do caso comercial se podem identificar as tarefas
necessrias para a criao do caso comercial para data warehouse. Nesse ponto, e
equipe que justificar, projetar e implementar o data warehouse entra no processo.
Eles usam pessoal colateral j desenvolvido pelos consultores ou pessoal interno
(entrevistas, sesses de enfoque, anlises estatsticas) para documentar: (a) uma
estrutura de desmembramento de trabalho de alto nvel para o projeto inteiro, (b) uma
anlise custo/benefcio, incluindo um retorno do investimento, se possvel, (c) os fatores
crticos para o sucesso e (d) os impedimentos tpicos do sucesso.
Para a estrutura de desmembramento de trabalho de alto nvel para o projeto inteiro,
no se precisa incluir as tarefas de baixo nvel que seriam usadas no projeto real, mas
dever conter as tarefas e estgios em nvel de resumo que refletem os principais
esforos.
[MAR 99] ressalta o fato importante de que se ningum na equipe tiver experincia
com projeto de data warehouse, a especificao de tarefas poder ser muito mais difcil,
logo a contratao de um consultor experiente se faz necessrio.
Na anlise do custo e do benefcio, [MAR 99] descreve a importncia em se
trabalhar com os gerentes comerciais e principais usurios comerciais para identificar e
atribuir pesos relativos para os benefcios comerciais de alto nvel da implementao de
um data warehouse, a fim de dar suporte aos fluxos de valores ou iniciativas
estratgicas. A gerncia e os principais usurios comerciais podem fornecer os
objetivos, os fatores crticos do sucesso e os planos de desenvolvimento futuros para a
empresa, junto com uma estratgia para alcan-los. Um data warehouse projetado
efetivamente dever ajudar uma organizao a tomar decises estratgicas que no
podem ser feitas por meio de sistemas de transao em operao.
35
[MAR 99] apresenta os fatores crticos para o sucesso (CSFs-critical success

factors) que precisam ser estabelecidos para que o projeto tenha sucesso, citando como
fatores crticos: o caso comercial bem definido, projeto de arquitetura sadio, incluindo
potencial para crescimento, uma quantidade de dados possvel de ser gerenciada, um
oramento aprovado e disponvel e um pessoal interno e externo dedicado.
[MAR 99] tambm cita os impedimentos crticos do sucesso (CSIs-critical success
inhibitors) que podem impedir ou descarrilar o projeto, tais como:a falta de
comprometimento e conscincia dos patrocinadores executivos, o impacto de outros
projetos estratgicos de tecnologia de informao, a incapacidade de extrair dados de
sistemas de origem sem afetar contrariamente o desempenho do sistema de transao, o
grau incontrolvel de mudana organizacional durante o projeto, a falta de acesso aos
dados de origem necessrios, atribuies de pessoal em tempo parcial e a falta de uso de
padres e modelos para o gerenciamento de dados.
A fase de reviso e projeto da arquitetura define a tecnologia geral e a estrutura do
processo. O estgio de reviso e projeto da arquitetura avalia quais partes da arquitetura
j existem na organizao (uma anlise de lacunas). Essa fase desenvolve a arquitetura
lgica do DW o mapa de configurao dos locais de armazenamento de dados de
componentes necessrios, incluindo um local de armazenamento de dados central da
empresa, um local de armazenamento de dados operacional opcional, um ou mais
datamarts da rea comercial individual (opcional) e um ou mais locais de
armazenamento de metadados (contendo dois tipos diferentes de informaes de
referncia de catlogo sobre os dados principais).
Em seguida, as arquiteturas de dados, aplicao, tcnica e de suporte so criadas
para implementar fisicamente a arquitetura lgica. Os requisitos para essas arquiteturas
(explicados a seguir) so analisados cuidadosamente de modo que o DW possa ser
otimizado para os usurios. Uma anlise de lacuna descobre quais componentes de cada
arquitetura j existem na organizao e podem ser reutilizados, e quais devem ser
desenvolvidos (ou comprados) e configurados.
A arquitetura de dados organiza as origens e locais de armazenamento das
informaes comerciais e define os padres de qualidade e de gerenciamento para dados
e metadados. Ela define a estrutura na qual os usurios v-em o significado comercial
para os dados nos seus locais de armazenamento, alm de oferecer um mecanismo para
catalogar os processos de transformao de dados que so necessrios para o
desenvolvimento do warehouse.
A arquitetura de aplicao a estrutura de software que orienta a implementao
geral da funcionalidade comercial dentro do ambiente do warehouse. Ela controla o
movimento de dados da origem para o usurio, incluindo a extrao, a limpeza, a
transformao, o carregamento, a atualizao e o acesso (relatrios, consultas).
A arquitetura tcnica oferece a infra-estrutura de computao bsica que capacita as
arquiteturas de dados e de aplicao. Ela inclui plataforma/servidor, rede,
hardware/software/middleware de comunicaes e conectividade, SGBD, mtodo
cliente/servidor de duas ou trs camadas e hardware/software de estao de trabalho do
usurio final. O projeto de arquitetura tcnica deve atender aos requisitos de tratamento
de escalabilidade, capacidade e volume (incluindo tamanho e particionamento de
tabela), desempenho, disponibilidade, estabilidade, cobrana e segurana.
36
A arquitetura de suporte inclui as funes necessrias para gerenciar o investimento
de tecnologia de modo eficaz e os componentes do software de DW, tais como:
ferramentas e estruturas para backup e recuperao, monitorao de desempenho,
gerenciamento de controle/configurao de verso.
[MAR 99] enfatiza que esta fase de reviso e projeto da arquitetura aplica-se
estratgia de longo prazo para o desenvolvimento e refinamento do DW e no
realizada simplesmente numa nica iterao.
A fase de avaliao da questo comercial (BQA business question assessment)
estabelece as reas de assunto do DW, o escopo das iteraes individuais do projeto e a
estratgia de implementao em curto prazo, definindo e priorizando os requisitos
comerciais, conforme estabelecidos no caso comercial, e outras necessidades de
informaes que o DW focalizar. Permite medir a qualidade, a disponibilidade e os
custos relacionados dos dados de origem necessrios em alto nvel.
[MAR 99] sugere uma anlise do fluxo de valores predatrios priorizados ou a
iniciativa estratgica mais importante para decidir quais questes comerciais a
implementao ter de responder. As questes comerciais impem problemas que
determinam a direo estratgica. Por exemplo, uma questo comercial para um
revendedor poderia ser: Quais foram os dez itens mais vendidos em todas as lojas da
regio X no segundo trimestre deste ano fiscal, onde dez mais vendidos so definidos
como os dez itens mais altos em termos de receita total por item?
Se analise cada questo para avaliar sua importncia geral para a organizao, e
depois realize uma anlise de alto nvel dos dados necessrios para fornecer as
respostas. Analise-se a qualidade, a disponibilidade e o custo dos dados (para lev-los
para o data warehouse). Use-se essa informao para re-priorizar as questes comerciais
de acordo com a importncia, o custo e a viabilidade (de adquirir os dados exigidos).
Use-se essa anlise para decidir sobre o escopo das iteraes previsveis do DW, na
forma de projetos de preenchimento de dados. Estima-se, com limites prticos de
aquisio de dados, quantas questes comerciais podero ser respondidas em uma
implementao de trs a seis meses. Uma questo comercial dever ser responsvel pela
anlise objetiva dos dados disponveis. As questes comerciais precisam:
Enfocar aspectos verificveis. Uma implementao de DW no pode ser criada

para satisfazer a uma necessidade que no possa ser expressa como uma questo
comercial. A consulta mais fcil possui pouco ou nenhum valor no projeto de
uma soluo tcnica;
Ajudar a definir o escopo do projeto;
Orientar diretamente o desenvolvimento do modelo lgico de dados

identificando os objetos de dados que oferecem as informaes necessrias ao
warehouse;
Definir os testes de aceitao do sistema. O sistema desenvolvido dever

responder a quaisquer comerciais no escopo.
[MAR 99] ainda sugere a realizao de sesses de enfoque e entrevistas para

desenvolver a lista das principais questes comerciais para as quais o DW dever
fornecer respostas. Identificar as aes que possam ser realizadas por meio de consultas
do usurio e na aquisio de dados.
37
A fase de plano de implementao da iterao permite revisar o plano de projeto

original para incluir um plano de trabalho para as tarefas de preenchimento desse ciclo.
Caso novos enfoques mudarem o escopo original, a reviso ao escopo ser necessria
atravs de novas iteraes ao estudo do caso comercial.
Enquanto o que a arquitetura define a estratgia e os processos gerais pelos quais o
DW desenvolvido, a fase de projeto detalhado mapeia a implementao desses
processos para a iterao. Esta fase desenvolve o modelo fsico do DW (esquema de
banco de dados), os metadados e atualiza o inventrio de dados de origem necessrios
para a implementao da rea de assunto.
A fase de implementao pode ser caracterizada pelo fato de que tudo que foi
realizado at esse ponto prepara o caminho para uma implementao fcil. [MAR 99]
cita que nesta fase necessrio executar algumas etapas, tais como: (a) compra e
instalao dos componentes do DW, (b) preparao da base de teste, (c) teste do
processo de ETL, (d) testes nos programas de atualizao, (e) criao dos mdulos de
acesso aos usurios, (f) criao e teste das consultas OLAP e (g) registro da aceitao
dos usurios.
Para [MAR 99] a fase de transio para a produo pode ser vista como um
termmetro de que se a execuo das fases anteriores foi bem feita, a transio dever
ser rpida e tranquila. Porm, se algo no ficou bem planejado, a equipe do projeto ter
que realizar tarefas de desenvolvimento e produo durante a prxima iterao. As
principais atividades desta fase so: (a) mover todos os componentes do sistema do
ambiente de desenvolvimento para o ambiente de produo, (b) treinar o pessoal de
operaes e usurios finais, (c) realizar a documentao do sistema operacional e (d)
oferecer um warehouse que seja totalmente operacional e disponvel aos usurios.
A ltima fase descrita por [MAR 99] a fase de manuteno, necessria uma vez
que um DW cresce e muda com o tempo. Podem ocorrer alteraes de hardware,
software, sistemas de origem adicionais, processos de aplicao adicionais, mudanas
no ciclo de atualizao, mudanas nas atividades e responsabilidades de controle de
verso.
Para a execuo das fases, [MAR 99] descreve a necessidade de uma abordagem de
quatro reas comuns a qualquer projeto: (a) Planejar, (b) Ativar, (c) Controlar e (d)
Encerrar.
Na rea de planejamento so estabelecidos os objetivos, o escopo e os padres do
projeto. [MAR 99] enfatiza a necessidade de considerar, nesta etapa, um mtodo para
posterior contratao de consultores especializados em projetos de DW.
Para ativar o projeto, [MAR 99] descreve que necessrio publicar o projeto,
equipar e treinar os membros da equipe. Os usurios comerciais devero conduzir a
tecnologia ajudando a definir os requisitos iniciais e os requisitos para iteraes futuras.
O pessoal de TI (Tecnologia da Informao) dever saber das necessidades gerais da
comunidade comercial, mas so necessrios analistas comerciais para conduzir os
requisitos reais de informao com base nas necessidades da comunidade de usurios.
importante, no final deste estgio, o treinamento da equipe de projeto sobre as
ferramentas que sero utilizadas no decorrer do projeto, como e-mail, gerenciador de
projetos e processadores de texto. As ferramentas de DW sero obtidas mais tarde.
Na rea de controle, [MAR 99] afirma que o mesmo ocorrer at o final do projeto e
se divide em quatro etapas: (a) atribuir tarefas de projeto, (b) motivar os participantes do
38
projeto, (c) rastrear o processo do projeto e (f) revisar o plano do projeto. A etapa de
atribuir tarefas combinar a cada atividade planejada, o recurso mais apropriado para a
sua execuo. Como um projeto de DW contnuo, deve-se trabalhar, na etapa de
motivao, para promover o desenvolvimento individual, criar incentivos para o
trabalho de equipe, reconhecendo as realizaes. A etapa de rastreamento se caracteriza
por um acompanhamento sobre o estado do projeto e apresentar as informaes para os
membros da equipe e responsveis pelo projeto. Para [MAR 99], a etapa de revisar a
mais importante, pois se deve avaliar cuidadosamente as sugestes e os pedidos do
usurio para filtrar os recursos mais interessantes, que podem aumentar o custo final do
projeto.
Para [MAR 99], a rea de encerrar algo mais que o simples trmino do projeto de
DW, o qual afirma que se deve arquivar o material do projeto, gerar relatrio sobre o
andamento do projeto, passar os resultados do projeto para o pessoal de operao e
suporte e liberar os recursos do projeto para uso em outros projetos.
4.2 A Metodologia de Ralph Kimball

A proposta de [KIM 98a] destaca-se por ser no geral o que mais caracteriza e detalha
as diversas fases da metodologia, considerando as fases de: (a) planejamento, (b)
levantamento de requisitos, (c) arquitetura funcional, (d) projeto da base de dados, (e)
aplicaes de usurios finais, (f) auditoria nos dados e (g) uso, suporte e extenso do
DW.
A Figura 4.2 mostra o ciclo de vida na qual apresenta as fases so executadas
sequencialmente e em paralelo. Ao final de cada uma, [KIM 98a] descreve a
necessidade de executar as atividades de reviso e aceitao pelo usurio final, alm da
reviso do projeto.
Projeto da
arquitetura
tcnica
Planejamento
Modelagem
dimensional
Definio de
requisitos do
negcio
Seleo e
instalao de
produtos
Projeto fsico
Projeto e
desenvolvim
ento da
organizao
de dados
Disponibiliz
ao do DW
Manuteno e
crescimento
Especificao de
aplicaes de
usurio final
Gerenciamento do projeto
Figura 4.2: Ciclo de vida de [KIM 98a].

O ciclo de vida do desenvolvimento comea com o planejamento, que segundo
[KIM 98a] pode variar de empresa para empresa. uma das atividades mais crticas
pois a qualidade dos levantamentos e definies afetaro o projeto como um todo.
O principal resultado desta fase um Plano de Projeto, com os dados levantados tais
como: a justificativa do projeto, custos envolvidos, identificao dos integrantes do
39
projeto, especificao do cronograma do projeto e das diferentes fases e atividades do

DW.
Na fase de requisitos do negcio so definidos os fatores chaves do negcio do
usurio, imprescindveis para as prximas etapas. Esta fase se caracteriza pela
identificao e preparao da equipe de entrevistas, seleo de entrevistadores para cada
entrevista, anlise dos resultados de cada entrevista e reviso do Plano de Projeto.
Segundo [KIM 98a], a fase de projeto da arquitetura tcnica uma das mais
importantes no projeto DW, onde se define uma arquitetura de alto nvel (rea interna e
externa), e a especificao da infra-estrutura tcnica e os respectivos componentes
necessrios para permitir a criao do DW. Na fase de seleo e instalao de produtos
consiste na realizao de pesquisa, estudo e seleo dos produtos relacionados a
construo de um DW, desenvolvimento de prottipos para melhor avaliao das
funcionalidades dos softwares e sua aceitao pelo usurio final, alm da reviso do
projeto.
A fase de modelagem dimensional consiste em agregar os dados levantados na fase
de requisitos do negcio para desenvolver um modelo de dados. Durante esta fase
tambm realizada a anlise das diversas fontes de dados de modo a identificar aquelas
que possuem os dados necessrios para atender o modelo de dados, assim como
procurar especificar dentre estas as melhores fontes de dados. Essa anlise compreende
as seguintes atividades:
Identificao das fontes de dados candidatas, verificando detalhes tais como

sistema OLTP que integra, plataforma (e.g.UNIX, Windows NT, etc.), estrutura
fsica dos arquivos (e.g. flat files, Oracle, Excel, etc.), volume de dados (e.g.
nmero de transaes por semana, etc.), identificao de chaves primrias e
estrangeiras e caractersticas dos campos de dados (e.g. tipos de dados,
comprimento, preciso, etc.);
Estudo do mapeamento de dados das fontes candidatas para as tabelas de destino

dos dados;
Estimativa do nmero de linhas ou registros das fontes de dados candidatas.
Na fase de projeto fsico so realizadas as seguintes atividades de definio de

nomes padronizados para os objetos da base de dados, a execuo do projeto fsico,
criando os objetos da base de dados analtica e o desenvolvimento de um plano inicial
de indexao, agregao e particionamento.
A fase projeto e desenvolvimento da rea de organizao de dados, diz respeito a
atividades fundamentais a serem realizadas no DW: a extrao, transformao e carga
de dados. As principais atividades que compreendem esta fase so a criao de uma
arquitetura de alto nvel que represente o fluxo de dados dos sistemas fonte para a base
de dados analtica de destino, o teste e escolha de ferramentas de terceiros ou
desenvolvimento de programas especficos para a realizao das atividades de
organizao de dados e o detalhamento da arquitetura de alto nvel, determinando, por
exemplo, quais tabelas e em que ordem ser realizada, a atividade de extrao,
transformao e carga, quais as atividades de transformao que sero realizadas nas
diversas tabelas, etc.
Para uma definio e realizao de modificaes lgicas e atualizao dos registros
das dimenses, quando necessrio. [KIM 98a] propem trs tcnicas bsicas quando um
registro da dimenso atualizado: substituio pelo registro mais recente, criao de
40
novo registro na dimenso ou, por ltimo, criao de um novo campo na dimenso que
armazene somente o campo alterado, de forma que sejam armazenados os campos
novos e antigos.
[KIM 98a] enfatiza nesta fase ainda a realizao do processo de organizao de
dados com as demais dimenses, assim como a tabela fato, o desenvolvimento de
procedimentos que permitam a carga incremental de tabelas fato que sejam muito
grandes, utilizando os recursos baseados em novas transaes, logs de bancos de
dados, replicao, realizao de mltiplos passos de carga e execuo paralela e carga
de tabelas de agregados.
Na fase especificaes de aplicaes de usurio final deve-se procurar identificar as
reas prioritrias e, a partir destas, definir um conjunto padronizado de aplicaes
destinadas aos usurios finais, uma vez que no so todos os usurios que necessitam
Ter acesso ad hoc aos dados do DW.
Na fase desenvolvimento de aplicaes de usurio final so desenvolvidas as
aplicaes necessrias de acordo com levantamentos realizados na fase de
especificaes de aplicaes de usurio final. A seleo do ambiente de
desenvolvimento dos relatrios e o desenvolvimento de procedimentos de manuteno e
atualizao das aplicaes de usurio final, so atividades que compreendem esta fase.
Para [KIM 98a] a fase de disponibilizao do DW composta basicamente pelas
seguintes atividades de montar o plano de verificao da infra-estrutura, estratgia de
treinamento dos usurios finais, estratgia de suporte ao usurio final, plano de
atualizao de verso do DW, um teste completo do sistema e a disponibilizao do DW
propriamente dita aos usurios finais.
Na fase de manuteno e crescimento do DW composta basicamente pelo contnuo
suporte e treinamento dos usurios e manuteno da infra-estrutura tcnica, alm do
monitoramento de consultas realizadas pelos usurios finais, desempenho da
organizao de dados e o contnuo sucesso do DW.
4.3 A Metodologia de Vidette Poe

O trabalho de [POE 98] em relao aos outros j mencionados, apresenta o
diferencial que o detalhamento de variaes de esquemas multidimensionais e um
enfoque bastante significativo sobre projeto piloto.
Em seu trabalho [POE 98] deixa bem claro a importncia de se estabelecer, antes da
construo do DW, uma arquitetura de dados adequada, que realmente atenda s
necessidades da corporao. A grande importncia da abordagem de [POE 98] quanto
ao estabelecimento inicial de uma arquitetura de dados deve-se ao fato de que, em
decorrncia desta escolha, derivar-se- a infra-estrutura tcnica necessria para atender
o DW, normalmente composta por tecnologias e itens tais como treinamentos em
tecnologias de suporte deciso, plataformas, bases de dados, ferramentas de converso
de dados, hardware, software, rede local, ferramentas de acesso aos dados, etc. Ressaltase novamente que a arquitetura de dados est intimamente relacionada com a infraestrutura, ou seja, os componentes e tecnologias da infra-estrutura a serem utilizados
dependero diretamente da arquitetura de dados escolhida.
A Figura 4.3 descreve as etapas do ciclo de desenvolvimento do projeto de DW,
proposto por [POE 98].
41
A fase de planejamento preocupa-se com a definio e/ou clarificao do escopo do

projeto, a criao de um plano de projeto, definio dos participantes e
responsabilidades, alm das tarefas e prazos de concluso e a montagem de um
cronograma, incluindo o prazo final de entrega do projeto. Segundo [POE 98] no
conveniente construir um DW antes de estabelecer corretamente a arquitetura e a infraestrutura, o que poder acarretar insucesso no seu desenvolvimento e uso, desta forma,
caso a infra-estrutura no esteja pronta, devero tambm fazer parte do planejamento do
DW.
A fase de levantamento de requisitos e modelagem preocupa-se com a definio do
negcio, exigncias e necessidades dos usurios, e por ltimo, a modelagem do universo
de discurso, do qual fazem parte as referidas exigncias e necessidades. Esta fase
apresenta duas etapas distintas, denominadas de levantamento de requisitos e
modelagem.
Na etapa de levantamento de requisitos so realizadas atividades para a identificao
do entendimento de como o usurio realiza as diversas atividades de negcio, quais os
fatores que dirigem o negcio, quais os atributos o usurio necessita e so
absolutamente requeridos e quais so desejados, a estrutura organizacional, quais as
ferramentas de acesso aos dados e quais os resultados o usurio espera em suas
consultas.
Por sua vez a modelagem de dados refere-se ao processo de traduo dos conceitos
dos conceitos do negcio em um modelo dimensional em formato diagramtico que
inclua fatos, dimenses, hierarquias, relacionamentos, chaves candidatas, etc. [POE 98]
apresenta, alm dos tradicionais esquemas estrela e flocos de neve, diversas
variaes, tais como esquema estrela com mltiplas tabelas fato, esquema estrela
com tabelas associativas, esquema estrela com tabelas externas e esquema multiestrela, descrevendo a necessidade de adequao de um modelo de dados s condies
locais da corporao e seus negcios, apresentando um modelo hbrido.
Planejamento
Levantamento de requisitos e modelagem
Projeto fsico da base de dados e desenvolvimento
Determinao e mapeamento das fonts de dados
Populao do DW
Automao dos processos de carga de dados
Criao do conjunto inicial de relatrios
Validao e testes de dados
Treinamento
Produo
Figura 4.3: Ciclo de vida de [POE 98].
42
Na etapa de projeto fsico da base de dados e desenvolvimento so criadas
fisicamente na base de dados, as tabelas de fato e dimenso e seus relacionamentos, a
desnormalizao de dados e as estratgias de criao de ndices, de agregao e
particionamento.
Segundo [POE 98] a fase de determinao, integrao e mapeamento das fontes de
dados so a que consome mais tempo de desenvolvimento, devido necessidade de
localizar os dados adequados dispersos em sistemas OLTP, analisar e entender os tipos
de dados, implementar os processos de transformao necessrios e mapear os campos
das fontes de dados para os objetos da base de dados, o desenvolvimento de programas
que permitam realizar as converses de dados para cada campo e refinar a estratgia de
integrao.
Na fase de populao do DW feito o desenvolvimento de: programas ou utilizao
de ferramentas de converso de dados para integrar os dados, para extrair e mover os
dados, carga de dados dentro do DW, desenvolvimento de estratgias de reconsulta e
atualizao de dados e a execuo de programas e procedimentos de extrao,
transformao e carga de dados.
A fase de automao dos processos de carga de dados caracteriza-se pelo
agendamento dos processos de extrao, converso e carga de dados, construo de
procedimentos de backup e recuperao de dados.
Na fase de criao de conjunto inicial de relatrios so realizadas as construes de
relatrios pr-definidos.
[POE 98] descreve a fase de validao e teste de dados como sendo a validao de
dados utilizando o conjunto inicial de relatrios e a validao dos dados atravs de
processos padronizados.
Na fase de treinamento tem-se a criao de programas de treinamento para atender
especificamente a comunidade de usurios, levando em conta o treinamento nas
ferramentas de acesso aos dados, obtendo as informaes desejadas no DW.
A fase de produo inclui as tarefas necessrias para a disponibilizao do DW e o
correspondente suporte necessrio aos usurios finais, a exemplo de aplicaes de
suporte deciso.
[POE 98] considera que a interao contnua dos usurios com o DW, aps a sua
disponibilizao atravs de ferramentas e aplicaes, possibilita o surgimento de novas
exigncias e consequentemente se fazendo necessrio a execuo, novamente, do ciclo
de desenvolvimento do DW, para que as modificaes sejam feitas.
Para [POE 98] o desenvolvimento de DW exige que a equipe de profissionais
responsvel pela sua construo seja integrada por pessoas experientes no assunto. Mas
mesmo assim existem ainda muitas empresas que, antes de desenvolverem um DW,
constroem inicialmente um Projeto Piloto de modo a evitar um possvel insucesso,
assim como possibilitar ganho de experincia, dentre outros motivos.
[POE 98] aborda a construo do Projeto Piloto de duas formas distintas: via prova
de concepo e via arquitetura e infra-estrutura. A prova de concepo possibilita uma
apresentao prtica ao comit diretor da corporao sobre as possibilidades de um DW.
Neste tipo de Projeto Piloto, os usurios podem interagir com o sistema obtendo
algumas informaes de suporte deciso, possibilitando entender como elas podero
assisti-los na tomada de decises. Normalmente este tipo de Projeto Piloto
43
desenvolvido rapidamente, quando comparado com a segunda forma, uma vez que se
apoia sobre um pequeno conjunto de dados. Adicionalmente, no h necessidade de que
todos os componentes tcnicos e de infra-estrutura estejam disponveis.
J na forma via arquitetura e infra-estrutura, por sua vez, usado para se verificar
como todos os componentes do DW trabalham juntos, bem como para entender e
ganhar experincia em todas fases do ciclo de vida de desenvolvimento. Esse tipo de
Projeto Piloto apoia-se tambm sobre um conjunto restrito de dados, os quais,
entretanto, passam por todas as fases do ciclo de vida de desenvolvimento, incluindo as
arquiteturas do DW correspondentes.
4.4 A Metodologia de Alan Perkins

O trabalho de [PER 2000] em relao aos outros j mencionados, apresenta de forma
completa e bastante detalhada toda a metodologia de desenvolvimento de um DW. Sua
principal contribuio est na elaborao de um prottipo, o qual [PER 2000] conceitua
como sendo um pr-projeto piloto, que se apoia sobre um conjunto restrito de dados,
passando por todas as etapas do desenvolvimento, tais como: arquitetura, tcnicas de
modelagem dimensional, projeto de banco de dados, etc.
A Figura 4.4 descreve as fases do ciclo de desenvolvimento do projeto de DW, que
segundo [PER 2000] so divididas em trs etapas distintas: (a) experimentao, (b)
definio e (c) execuo. A experimentao possibilita um contato inicial com as
tcnicas de desenvolvimento de DW, obter experincia com novas ferramentas,
tecnologias, definio de prazos, alem de levantar os requisitos necessrios para gerar as
informaes de suporte a deciso. A etapa de definio permite a reduo das incertezas
e utilizao das experincias obtidas na etapa anterior para a definio do projeto de
DW como um todo. Na etapa de execuo se desenvolve efetivamente o projeto de DW,
considerando os resultados gerados pelas etapas anteriores. [PER 2000] enfatiza em sua
proposta que existem dois momentos distintos: a construo de um projeto piloto,
considerando todas as fases de cada uma das etapas acima descritas e o prottipo,
montado na etapa de experimentao, servindo como um teste para a equipe de projeto
de DW.
Experimentao
Levantamento
preliminar
Planejamento
preliminar
Levantamento
detalhado
Protti
po
Definio
Execuo
Definies do
projeto e
atualizao do
planejamento
Projeto Piloto do
DW
Gerenciamento do projeto piloto de DW
Figura 4.4: Ciclo de vida de [PER 2000].

4.4.1 As fases para cada etapa da metodologia [PER 2000]
A etapa de experimentao composta pelas seguintes fases: (a) levantamento
preliminar, (b) planejamento preliminar, (c) levantamento detalhado e o (d) prottipo.
44
A fase de levantamento preliminar consiste no maior levantamento possvel de
dados a respeito do ambiente organizacional, os usurios finais e o grau de participao
deles no projeto. Nesta fase tambm so realizadas as reunies de requisito para que se
possam levantar os requisitos gerais do negcio da organizao e se procura identificar
as possveis fontes de dados, que serviro para a definio das atividades de extrao,
transformao e carga.
Na fase de planejamento preliminar os dados descritos na fase anterior so
analisados e repassados para um documento chamado por [PER 2000] de Plano de
Projeto, contendo a estrutura do projeto, anlise de sua viabilidade e necessidade, que
norteiam o principal objetivo do projeto de DW. Fazem ainda parte desta fase as
estratgias de: levantamento de requisitos mais detalhados, integrao ou transformao
de dados, segurana e atualizao dos dados. [PER 2000] enfatiza a necessidade de
apresentar o Plano de Projeto aos usurios finais do projeto, para possveis ajustes,
aprovao ou at mesmo reprovao.
A fase de prottipo a mais detalhada por [PER 2000], pois representa uma fase
similar no ciclo de vida de desenvolvimento de DW. Esta fase a principal dentro da
etapa de experimentao, pois sustenta a execuo de um pr-projeto piloto atravs de
um conjunto de dados restritos. [PER 2000] sustenta que este prottipo permite
estabelecer o contato inicial com as diferentes tcnicas de desenvolvimento de DW,
ganhar experincia com novas ferramentas e tecnologias e aprender as diversas tarefas
que compem cada fase do desenvolvimento do DW.
A etapa de definio permite reduzir as incertezas e a transformar as experincias
obtidas nas fases da etapa de experimentao, em definies de projeto que serviro
como base para a construo do projeto piloto de DW.
4.4.2 Fase de prottipo
Esta fase, como j descrita anteriormente, apresenta-se como um projeto piloto,
conforme descrito na etapa de arquitetura e infra-estrutura, proposta por [POE 98],
porm detalhando as etapas do projeto de DW. a fase mais importante da etapa de
experimentao, pois permite uma prvia do projeto, seguindo todas as etapas de
desenvolvimento do projeto de DW. [PER 2000] enfatiza que esta fase o principal
diferencial sobre as outras metodologias propostas, pois sustenta uma de suas primcias
de que um projeto de DW pode ser elaborado por uma equipe sem experincia.
Uma das principais vantagens, sobre este modelo, que se permite que a fase de
prottipo, como um todo, possa ser repetida tantas vezes quantas forem necessrias,
dentro das disponibilidades de tempo, pessoal, ferramentas, etc. [PER 2000] enfatiza
que o prottipo permitir o teste aprofundado e repetitivo de produtos e ferramentas a
partir das diversas configuraes e tecnologias adotadas nos mdulos precedentes.
Para que isto possa ocorrer, [PER 2000] descreve que esta fase se divide nos
seguintes mdulos: (a) planejamento, (b) arquitetura de dados, (c) arquitetura funcional,
(d) infra-estrutura, (e) teste de produtos, (f) modelagem dimensional, (g) projeto do BD,
(h) execuo da arquitetura funcional, (i) aplicaes de usurios finais, (j) auditoria nos
dados, (k) uso, suporte e extenso e (l) gerenciamento do prottipo.
45
4.5 Anlise das metodologias

As metodologias, apresentadas nas sees anteriores, apresentam caractersticas e
limitaes com relao ao processo de desenvolvimento do projeto de DW. Para esta
anlise, se enfatiza os seguinte conjunto de critrios: (a) ser completa, considerando
todas as etapas do projeto de DW, (b) exigir experincia em projetos de DW anteriores,
(c) detalhamento na definio de cada etapa apresentada, (d) apresentao de um
anteprojeto para anlise teste de tecnologias, (e) iterao completa sobre todas as etapas
do projeto de DW e (f) anlise dos riscos sobre o projeto de DW.
A tabela 1 descreve uma anlise comparativa das metodologias estudadas,
considerando os critrios citados anteriormente. importante lembrar que o resultado
apresentado sobre este estudo justifica a necessidade de definio de uma metodologia
adequada, como ser discutida no Captulo 5 e analisada no Captulo 6 a partir de um
estudo de caso para a Cia Zaffari, j que as metodologias apresentadas no satisfazem a
todos os critrios estabelecidos.
Tabela 1 Anlise das metodologias de projeto de DW.
Critrios
[MAR 99]
[KIM 98a]
[POE 98]
[PER 2000]
Completa
Sim
Sim
Sim
Sim
Experincia
Sim
Sim
Sim
No
Detalhamento
Pouco
detalha
Detalha
Detalha
Detalha
Anteprojeto
No possui
Possui
Possui
Possui
Iterao completa
No
No
No
No
Anlise de riscos
No
Sim
Sim
Sim
46
5 PROPOSTA DE UMA METODOLOGIA PARA

CRIAO DE DW
Este captulo apresenta uma proposta de metodologia para o desenvolvimento de

projeto de DW. Pelo fato, j descrito no captulo anterior, sobre a no adequao de
uma metodologia existente, considerando principalmente os critrios sobre a
completude, iterao, detalhamento, anteprojeto, anlise de riscos e experincia em
projetos j elaborados, se faz necessrio apresentao de uma descrio detalhada da
metodologia. Inicialmente ser apresentada uma viso sucinta da metodologia para
posterior detalhamento.
Entre as metodologias estudadas no captulo anterior, pode-se observar que [POE
98], [KIM 98a] e [PER 2000] so as mais detalhadas e completas, sendo desta forma,
utilizados como referencial conceitual para a definio da metodologia de projeto de
DW. Vale ainda descrever que a proposta est embasada na metodologia apresentada
em [FUR 98] e [BOO 2000], atravs dos conceitos do Processo Racional Unificado RUP (Rational Unified Process).
5.1 Ciclo de vida da metodologia

O ciclo de vida de desenvolvimento de sistemas clssico no pode ser aplicado ao
usurio de um EIS (Executive Information System Sistema de Informaes
Executivas). Em sistemas tradicionais, a metodologia clssica destina-se ao ambiente
operacional, parte-se do princpio que todos os requisitos sejam conhecidos ou
desvendados na parte de anlise e projeto, o que no acontece no desenvolvimento de
um EIS ou DW. O DW funciona segundo um ciclo de vida diferente, comeando pela
identificao dos dados, sua integrao e testes para verificar distores. Ento feita a
codificao dos programas de interface para os dados. Os resultados so analisados
pelos usurios e finalmente os requisitos do sistema so compreendidos.
A proposta de metodologia possui um ciclo de vida denominado ciclo de vida
repetitivo, o qual descreve uma iterao gradativa sobre a execuo de todas as etapas
do projeto de DW. Esta metodologia possui como principais caractersticas:
um processo iterativo o qual requer uma compreenso crescente do problema

por meio de aperfeioamentos sucessivos e o desenvolvimento incremental de
uma soluo efetiva em vrios ciclos;
Possui flexibilidade para a acomodao de novos requisitos ou de mudanas

tticas de objetivos de negcio;
Permite que o projeto identifique e solucione riscos de incio, em vez de

posteriormente;
47
Encoraja o controle de qualidade e o gerenciamento de riscos, contnuos e

objetivos a avaliao da qualidade inserida no processo, em todas as
atividades e envolvendo todos os participantes, com a utilizao de medidas e
critrios objetivos;
O gerenciamento de riscos inserido no processo, de forma que os riscos para o

sucesso do projeto so identificados e atacados no incio do processo de
desenvolvimento, quando h tempo suficiente para uma reao adequada.
Existem quatro fases no ciclo de desenvolvimento de um projeto de DW, como

mostra a Figura 5.1: concepo, elaborao, construo e transio. Cada fase e iterao
tm algum foco de reduo de riscos e concluem um marco de progresso bem-definido.
A considerao do marco de progresso proporciona um ponto no tempo para avaliar
como as metas foram alcanadas e se o projeto necessitar ser re-estruturado de alguma
maneira para prosseguir.
Para [BOO 2000], a fase de Concepo a fase onde estabelecido o caso do
negcio para o sistema e delimitado o escopo do projeto. O caso de negcio inclui
critrios de sucesso, a avaliao de riscos, estimativa de recursos necessrios e um plano
para cada fase, mostrando a programao de principais marcos de progresso. Durante a
concepo, comum a criao de um prottipo executvel, servindo como teste para a
concepo. No final desta fase os objetivos do ciclo de vida do projeto so examinados
para poder decidir se deve prosseguir com o desenvolvimento em plena escala.
A fase de Elaborao a fase onde feita uma anlise do domnio do problema, o
estabelecimento da fundao de uma arquitetura slida, o desenvolvimento de um plano
do projeto e a eliminao dos elementos de mais alto risco do projeto. [BOO 2000]
descreve que as decises de arquitetura devem ser feitas com uma compreenso de todo
o sistema. No final desta fase examinado o escopo e os objetivos detalhados do
projeto, a escolha da arquitetura e a soluo para os principais riscos, alm de decidir se
deve prosseguir com a construo.
Na fase de Construo desenvolvido de maneira iterativa e incremental, um
produto completo, pronto para a transio junto a comunidade de usurio. Isso implica
uma descrio dos requisitos restantes e de critrios de aceitao, dando corpo ao
projeto e concluindo a implementao e o teste do DW. No final desta fase decidido se
o ambiente e usurios esto todos prontos para se tornarem operacionais.
A fase de Transio ocorre quando o software se torna disponvel aos usurios.
Quando o sistema colocado nas mos dos usurios finais surgem questes que
requerem algum desenvolvimento adicional, com a finalidade de ajustar o sistema ou
corrigir alguns problemas identificados. Essa fase tipicamente iniciada com uma
verso beta do projeto, que depois substituda pelo projeto de produo.
No final dessa fase feita uma avaliao para ver se os objetivos do ciclo de vida do
projeto foram alcanados e determinado se dever iniciar outro ciclo de
desenvolvimento. Esse tambm um ponto em que as lies aprendidas no projeto
devero ser assimiladas para aprimorar o processo de desenvolvimento e serem
aplicadas no prximo projeto.
48
Fases do Ciclo de vida

Etapas
AnteProjeto
Fases de cada etapa
Incepo
Elaborao
Construo
Transio
Levantamento
Planejamento
Planejamento detalhado
Definio
Arquitetura de dados
Arquitetura funcional
Infra-estrutura
Modelagem dimensional
Projeto da Base de Dados
Avaliao de produtos
Execuo da arq.funcional
Aplicaes finais
Auditoria de dados
Uso e gerenciamento
de verses
Execuo
Iterao
Iterao
Iterao
Iterao
1...n
n+1m
n+2 ...m+2
k...k+1
Figura 5.1: Ciclo de vida repetitivo.

5.1.1 Iteraes
Cada fase da metodologia ainda pode ser dividida em iteraes. Uma iterao um
ciclo completo de desenvolvimento, resultando em uma verso (interna ou externa) de
um produto executvel que constitui um subconjunto do produto final em
desenvolvimento e cresce de modo incremental de uma iterao para outra para se
tornar o sistema final. Cada iterao passa pelos vrios fluxos de trabalho do processo,
embora com uma nfase diferente em cada um deles, dependendo da fase. Durante a
concepo, o foco est na captao de requisitos. Durante a elaborao, o foco passa a
ser a anlise e o projeto. A implementao a atividade central na construo e a
transio, na entrega.
Desta forma, podemos conceituar a iterao como sendo uma execuo completa de
as etapas de um projeto de DW (anteprojeto, definio e execuo) para cada uma as
etapas do ciclo de desenvolvimento, iniciando na fase de incepo e terminando na fase
de transio. Para cada fase do ciclo de desenvolvimento podemos ter vrias repeties
de execuo, dependendo do nvel de definio do projeto.
5.1.2 Ciclo de desenvolvimento
A passagem pelas quatro principais fases chamada um ciclo de desenvolvimento e
resulta na gerao de um projeto de DW. O primeiro passo das quatro fases chamado
49
o ciclo inicial do desenvolvimento. A menos que a vida do produto seja interrompida,

um produto existente evoluir para sua prxima gerao pela repetio da mesma
sequencia de fases de concepo, elaborao, construo e transio. Isso a evoluo
do produto, de modo que os ciclos de desenvolvimento posteriores aos ciclos iniciais
so seus ciclos de evoluo [BOO 2000].
5.2 Fluxo de trabalho da metodologia

A metodologia proposta composta basicamente de trs etapas, ilustradas na Figura
5.2, aqui denominada de fluxos de trabalho, so descritas a seguir.
Anteprojeto
Levantamento
Definio
Planejamento
Definio do
projeto de DW
Execuo
Uso e
gerenciamento
Gerenciamento de
verses
Figura 5.2: Fluxo de trabalho da metodologia.

5.2.1 Anteprojeto
A etapa de anteprojeto, algo similar s apresentadas em [POE 98], [KIM 98a] e
[PER 2000], permite se fazer o levantamento das necessidades inerentes ao projeto de
DW. Possibilita aos diretores e decisores de mais alto nvel uma viso de como o DW
pode ser vivel e valioso para a corporao. Um planejamento no detalhado sobre as
possibilidades de um DW tambm descrito nesta etapa.
A fase de levantamento, considerando os trabalhos apresentados em [DYC 98] e
[POE 98], deve ser iniciada atravs da definio dos recursos tcnicos necessrios, o
entendimento do negcio e as necessidades dos usurios. As principais caractersticas
desta fase so:
Identificar o ambiente e influncia organizacional, para levantar os fatores

humanos que cercam o ambiente organizacional, tais como a disposio
poltica da cpula da corporao para realizar o projeto de DW;
Realizar reunio para a coleta e o entendimento dos requisitos, junto aos

usurios e tomadores de deciso;
Analisar os requisitos levantados, definindo quais os dados que o usurio utiliza

e quais deveriam utilizar;
Definir o nvel de detalhes que o usurio necessita;
Definio do processo a modelar, considerando os requisitos levantados;
Determinar as fontes de dados que sero necessrias para realizar as atividades

de ETL.
Depois de concluda a fase de levantamento, pode-se realizar a fase de

planejamento, considerando alguns itens importantes definidos nos trabalhos de [GAR
98], [POE 98] e [KIM 98a], tais como:
Identificao dos membros da equipe do projeto de DW, assim como de suas

funes;
50
Levantamento dos fatores que permitem mensurar o sucesso assim como os

riscos do projeto de DW;
Prever as ferramentas necessrias tanto para a efetiva construo do DW, como

para as consultas a base de dados analtica;
Estabelecimento de cronogramas temporais, no detalhados, que permitam a

efetiva construo do DW;
Elaborao das justificativas para o projeto, considerando os investimentos

necessrios e os seus reais custos, alm dos resultados e principais benefcios a
serem alcanados.
Esta etapa do projeto se conclui com a elaborao de um Plano de Projeto, contendo

os dados levantados e analisados. Deve possuir um ttulo para a identificao do projeto
de DW, a definio dos participantes do projeto, tais como os membros da equipe e
usurios tomadores de deciso, assim como de suas correspondentes tarefas. Este Plano
de Projeto dever ser atualizado e completado pelas prximas etapas.
5.2.2 Definio
A etapa de definio do projeto inicia logo aps o anteprojeto ter sido concludo.
Esta etapa possibilita uma definio completa sobre o Plano de Projeto, baseado nos
trabalhos de [POE 98], [KIM 98] e [PER 2000], contendo as fases de: (a) planejamento
detalhado, (b) arquitetura de dados, (c) arquitetura funcional, (d) infra-estrutura, (e)
modelagem dimensional, (f) projeto da base de dados, (g) avaliao de produtos, (h)
execuo da arquitetura funcional, (i) aplicaes finais e (j) auditoria de dados. A Figura
5.3 descreve o fluxo da etapa de definio.
A fase de planejamento detalhado destina-se ao aprofundamento dos dados
levantados na etapa de Ante-Projeto. realizado o planejamento das diversas
atividades a serem realizadas, devendo conter a definio clara dos objetivos a serem
alcanados. Com a identificao dos participantes do projeto, definido na etapa anterior,
se atribui a cada atividade os prazos e suas responsabilidades. Mapeia-se uma rea de
negcio para o desenvolvimento do projeto, incluindo os relatrios necessrios a
demanda dos usurios, inclusive a sua estrutura de apresentao. Ressalta-se pelo fato
de que no ciclo existe o conceito de iterao, novas situaes podero ser impostas ao
Plano do Projeto. Desta forma, a execuo desta fase apresenta um Plano de Projeto
mais detalhado.
Arquitetura
funcional
Arquitetura
de dados
Planejamento
detalhado
Infra-estrutura
Modelagem dimensional
Avaliao de
produtos
Execuo da
arq.funcional
Projeto do BD
Aplicaes
finais
Figura 5.3: Fluxo de trabalho da etapa de definio.
Auditoria
de dados
51
Para uma melhor definio dos dados, esta fase foi subdividida em mdulos,
provenientes do trabalho de [PER 2000], tais como: (a)atividades preparatrias e (b)
requisitos detalhados. As principais caractersticas destes mdulos so:
Atividades preparatrias: permite descrever as estratgias de entrevista, levando

em conta a quem entrevistar, o que perguntar, documentao das reunies e
sequencia das mesmas;
Requisitos detalhados: permitem descrever de forma detalhada todos os

requisitos identificados na etapa anterior. Em outras palavras, a traduo dos
requisitos do negcio em objetos fsicos na base de dados (e.g. tabelas de
dimenso e fato, granularidade, agregaes, etc.). Permite ainda identificar as
fontes necessrias ao projeto de DW (uma vez definidas na etapa anterior) a sua
localizao (e.g. externas, internas), as plataformas em que se situam e a
estrutura dos arquivos correspondentes, para as tarefas de ETL.
A fase de arquitetura de dados destina-se basicamente escolha da arquitetura que

servir como um mapa de alto nvel, atravs do qual possvel entender como os dados
se organizam no projeto. Vale lembrar, como descrito no Capitulo 2, sobre arquitetura
de dados, que se deve considerar a forma como os dados fluem atravs do DW e so
utilizados pelos usurios finais, isto , arquitetura centralizada, DM dependentes, DM
independentes ou distribuda.
Na fase da arquitetura funcional, o Plano de Projeto deve conter a definio do que
se deseja do DW quando estiver concludo. Em outras palavras, deve conter o fluxo dos
dados dos sistemas fontes at os usurios e os servios correspondentes, a exemplo da
extrao, transformao, carga, consulta, ect [PER 2000].
A fase de infra-estrutura permite definir os recursos de hardware e software
necessrios para dar subsdio na definio da arquitetura funcional.
na fase de modelagem dimensional que se define o modelo de esquema (e.g.
estrela, floco de neve) que ser adotado ou uma variao hbrida [POE 98] necessria
para adequ-la junto a corporao, para se obter melhores resultados. A concluso desta
fase se d pela montagem da modelagem conceitual, considerando os requisitos da rea
de negcio selecionada.
O projeto da base de dados a fase onde so realizadas as atividades que
possibilitem preparar adequadamente a base de dados analtica para receber os dados
oriundos da etapa de ETL. So feitas as estimativas com relao ao tamanho do BD,
particionamento fsico da base de dados, proteo e segurana dos dados, criao de
ndices, otimizao da base de dados, etc [PER 2000];
A fase de avaliao de produtos tem como principal objetivo [PER 2000] a
definio de quais produtos testados que sero necessrios para atender a todos os
usurios do ambiente de DW, que vo desde a extrao at as consultas. Dependo da
situao e necessidades, se pode acrescentar ao Plano do Projeto, a especificao de
rotinas que devero ser customizadas.
A fase de execuo da arquitetura funcional tem por finalidade realizar atividades
para atender s especificaes resultantes da fase de arquitetura funcional. Durante a
execuo desta fase, os dados so identificados das fontes de dados, extrados,
transformados e carregados para o DW, atravs das ferramentas previamente escolhidas.
52
Devem-se acrescentar os resultados obtidos no Plano de Projeto, para manter um
histrico das execues realizadas [PER 2000].
Na fase de aplicaes finais, relatrios e consultas so criadas para atender ao
pblico de usurios tomadores de deciso e que participaram das especificaes
necessrias ao projeto de DW. Se faz um levantamento do mximo de detalhes
referentes apresentao dos dados aos usurios decisores.
Em linhas gerais, a ltima fase sobre auditoria de dados permite a verificao sobre
a qualidade dos dados armazenados, atravs de atividades de validao dos dados
atravs de consultas, anlise nos processos de ETL, estudo dos arquivos de log, etc.
5.2.3 Execuo
medida que novas iteraes vo surgindo, esta etapa permite realizar a execuo
do Plano de Projeto, incluindo as tarefas necessrias para a disponibilizao do DW.
Esta etapa possibilita uma viso prtica de todas as definies de projeto e experincias
adquiridas nas fases anteriores. Esta etapa, considerando os trabalhos de [POE 98] e
[KIM 98], possui duas fases: (a) uso e gerenciamento e (b) gerenciamento de verses.
A fase de uso e gerenciamento permite, mediante o nvel de iterao, a simples
construo das definies descritas no plano, at a montagem, propriamente dita do
DW. Permite a criao de um plano de disponibilizao (contendo um plano de
verificao da infra-estrutura, estratgia de treinamentos dos usurios finais, de
suporte).
Na fase de gerenciamento de verses, um plano de atualizao de verso do DW
pode ser elaborado, para o monitoramento de consultas realizadas pelos usurios,
desempenho da organizao de dados e o contnuo sucesso do DW.
53
6 ESTUDO DE CASO: DESENVOLVIMENTO DE UM

PROJETO DE DW
Este captulo apresenta uma aplicao da metodologia para o projeto de DW junto

Cia Zaffari, utilizando o sistema OLTP da rea comercial, como estudo de caso, para o
levantamento dos dados e informaes necessrias ao projeto. Inicialmente ser
apresentado um breve histrico da empresa, para posterior descrio da metodologia.
Como este projeto desempenha um modelo real da Cia Zaffari, descrevendo dados e
informaes gerenciais, o modelo proposto foi sumarizado e dados foram simplificados
e/ou alterados, de forma a se preservar o sigilo das informaes. Alm disto, mesmo
tendo sido autorizada a execuo do projeto de DW pela Cia. Zaffari,, a sua
implementao no ficou definida em que momento ser feita, e desta forma, os
processos relativos execuo no foram realizadas.
6.1 Ambiente da Cia Zaffari

As prximas sees apresentam um breve histrico sobre a Cia Zaffari e descrevem
a empresa quanto a sua estrutura operacional e de como os dados esto definidos quanto
a sua estrutura e replicao.
6.1.1 Histrico
A Companhia Zaffari uma empresa que atua a mais de 65 anos, no ramo de
comrcio no Rio Grande do Sul. Na capital gacha, a empresa conta 42 anos de trabalho
no varejo de alimentos e auto-servio, a partir da primeira loja, no ano de 1960. Desta
dada at hoje, a Companhia Zaffari montou uma rede de mais de 20 supermercados e
hipermercados que atendem a capital e o interior do estado, alm de seis shopping
centers, um deles em So Paulo. Atua tambm na industrializao de alimentos, com a
indstria de leos Vegetais e a fbrica de caf e biscoitos Haiti- Plic-Plac.
6.1.2 Estrutura Operacional
Sua estrutura formada pelas seguintes reas: (a) administrativa, (b) depsitos e (c)
lojas. Na rea administrativa, so executadas as tarefas de controle e gesto das
compras, preos, pedidos e planejamentos, alm das atividades que envolvem toda parte
financeira e contbil. J na rea das lojas, situadas nas cidades do estado do Rio Grande
do Sul e So Paulo, so concentradas as principais operaes de venda dos produtos,
alm dos recebimentos provenientes dos depsitos ou fornecedores. Os depsitos so as
reas responsveis pelo recebimento e armazenamento dos produtos entregues pelo
fornecedor.
54
6.1.3 Estrutura dos Dados
Cada uma das reas, definidas na Seo anterior, tambm so chamadas de locais e
possuem um servidor prprio. Atualmente a companhia Zaffari possui 30 servidores
HP-UX e 6 servidores NT. Cada local possui um servidor prprio identificado pelo
prprio nome do local (Loja X, Loja Y, Depsito Z). No setor de suporte, localizado na
rea administrativa, ficam alguns desses servidores, conforme mostra a tabela 2:
Tabela 2 Descrio dos Servidores.
Nome
Modelo
Descrio
ZAFFARI
HP K590
Servidor Sybase Zaffari um dos node do cluster

(MC/ServiceGuard).
ZAFFARI2
HP K420
Servidor Sybase Zaffari outro node do cluster

(MC/ServiceGuard). Open View Network Node Manager.
ZAFNT1
HP NetServer 5/100 LH
Servidor WEB, servidor de arquivos e de impresso.
ZAFNT2
HP NetServer 5/100 LH
Servidor Exchange Server.
DESENV
HP E55
Servidor da rea de desenvolvimento.
Para cada servidor existe um Banco de Dados (SyBase) e vrias Base de Dados
(ZafA, ZafB, ZafC e outros.) conforme Figura 6.1. Estas Bases de Dados representam
os dados que podem estar organizados por sistemas e/ou processos.
BD
Out
Servidor
Loja Xros BD
ZafA
BD
ZafC
BD
ZafB
Figura 6.1: Bases de Dados de um Servidor.

6.1.4 Transferncia de Dados
Alm do servidor de dados, cada local possui um servidor de replicao (SR)
responsvel pelo envio e/ou recebimento dos dados processados para outros servidores,
tais como o pedidos de loja para o depsito e dados que ficam centralizados no servidor
central (rea administrativa).
O Servidor de Replicao utiliza dois objetos: (a) Replication Definition
Administration (RDA) e (b) Subscription Administration (SBA). O RDA descreve uma
tabela que pode ser replicada para muitos servidores. Nesta parte, se identifica dados
referentes a tabela que ir replicar (e.g. o nome da replication definition, o nome da
tabela primria, a localizao da tabela primria no qual vai ser copiada, o nome e o
tipo de dado das colunas da tabela primria, etc.).
A SBA usada para replicar os dados da tabela primria de um banco de dados de
um servidor. Define o nome da replication definition para a tabela que est sendo
replicada e o Banco de Dados onde a tabela ser copiada. A clausula where permite
especificar as linhas (registros) que podero ser replicados. O padro da replicao
sobre toda tabela.
55
Quando se cria uma subscription, existem registros de ajuste da subscription

especificadas que devem ser copiadas da tabela primria para a tabela de replicao.
Este processo chamado de subscription materilization. Depois da materilizao ser
definida, o SR distribui para os servidores de rplica, assim como se muda no servidor
primrio.
O servidor de replicao est definido para a transferncia on-line, fazendo com que
os dados sejam enviados imediatamente aps a sua transao. A Figura 6.2 ilustra como
seria a estrutura de replicao dos dados entre os servidores.
6.2 Etapa de anteprojeto

Com j descrito no captulo 5, na etapa de anteprojeto que se executa das fases
de levantamento e planejamento, necessrio para o andamento do projeto de DW. As
prximas sees apresentam e detalham cada uma destas fases.
6.2.1 Levantamento
Nesta fase foram levantadas, de forma sucinta, as principais caractersticas que
cercam a companhia Zaffari. Os dados foram coletados de forma a que se pode escolher
um processo do negcio para modelar. Um processo do negcio uma operao
importante na organizao, suportada por algum tipo de sistema legado de onde
possvel coletar dados para o DW. No geral foram realizadas as seguintes atividades:
Identificao dos fatores humanos que cercam o ambiente organizacional, tais

como o interesse e expectativa de gerentes e administradores em geral com o
desenvolvimento e implantao do projeto de DW;
Capacidade e disposio de investimentos da corporao no projeto de DW;
Reunies para a identificao dos requisitos necessrios para a definio do

processo do negcio a se modelar;
Levantamento de dados e informaes sobre os sistemas OLTP da Cia. Zaffari,

atravs do estudo dos documentos e relatrios;
Levantamento de informaes analticas de natureza ttica e estratgica da Cia.

Zaffari, atravs de relatrios, planilhas e entrevistas junto a coordenadores,
gerentes e potenciais usurios do sistema.
6.2.1.1Resultados do Levantamento
Em consequncia dos levantamentos realizados nesta fase, se pode apresentar
diversas particularidades a respeito do ambiente de desenvolvimento do projeto:
Apesar de ter sido autorizada a execuo do projeto de DW pela Cia. Zaffari,,

como j mencionado anteriormente, a sua implementao no ficou definida em
que momento ser feita, desta forma nenhum patrocinador de alto nvel e
influente foi designado. Este fator refletiu-se mais tarde na dificuldade da
obteno de certos dados e informaes, especialmente de natureza gerencial;
Pelo fato da no definio exata do cronograma de implantao do projeto de

DW, constatou-se que no seria necessrio nenhum investimento financeiro para
o estudo de caso;
56
Com a divulgao do projeto junto aos usurios da gerncia e coordenao,

criou-se uma grande expectativa dos potenciais usurios, especialmente na rea
de compras do setor comercial, os quais puderam enxergar claramente os
benefcios e contriburam para a realizao do trabalho proposto.
Usurios do setor comercial esto preocupados com a logstica de organizao e

com o abastecimento das gndolas;
O processo a ser modelado, considerando as necessidades dos usurios

envolvidos, ser no movimento dirio de itens;
Quanto fonte de dados, os sistemas ditos convencionais (estoque, credirio e

outros) da Cia Zaffari utilizam a maioria das vezes fontes de dados internas,
cujos dados provm de arquivos independentes denominados de Tabelas,
Cadastros e Movimentos.
6.2.2
Planejamento
Considerando os dados levantados na fase anterior, nesta fase foram definidas as

principais caractersticas que completam o plano do projeto, com j visto na Seo
5.2.1. No geral foram realizadas as seguintes atividades:
Identificao dos membros da equipe de projeto e suas funes;
Entrevistas e reunies para identificar os fatores que permitem mensurar o

sucesso assim com os riscos do projeto;
Levantamento das ferramentas necessrias para construo do DW, como para as

consultas a base de dados analtica;
Definio do cronograma no detalhado para a efetiva construo.
6.2.2.1Resultados obtidos no Planejamento

Como resultado das definies feitas nesta fase, se pode obter o Plano de Projeto,
contendo: os dados levantados e analisados at o momento, identificado por um ttulo
para a identificao do projeto de DW e a definio dos participantes do projeto, tais
como os membros da equipe e usurios tomadores de deciso, assim como de suas
correspondentes tarefas. Este plano ainda apresenta:
Os principais fatores que permitem mensurar o sucesso do projeto de DW foram

identificados como sendo a necessidade de disponibilizao de relatrios prformatados de acordo com as necessidades dos decisores e no menor tempo
possvel e relatrios gerenciais que integrem dados e informaes de anos
distintos;
exceo do Sistema Gerenciador de Banco de Dados Sybase (SGBD) e das

ferramentas de desenvolvimento (e.g. linguagem de programao e CASE) a Cia
Zaffari no dispunha de nenhuma linguagem de software ou ferramenta
especfica para o desenvolvimento de projeto de DW (e.g. ferramentas de ETL,
consultas, etc.), e como j descrito, no havia a disponibilidade de aquisio
devido a falta de investimentos para este estudo de caso;
Quanto aos prazos de desenvolvimento deste estudo de caso, para a aplicao do

modelo de metodologia proposta para o projeto de DW, foi estimado
inicialmente como sendo em 2 meses, levando em conta os objetivos propostos.
57
Os resultados obtidos aps diversas reunies e levantamentos de dados, foram

apresentados ao grupo de usurios finais para que possveis correes e adequaes
ainda fossem verificadas e possveis sugestes e melhorias fossem consideradas ao
plano do projeto. Ao final desta etapa foi necessria uma aprovao do plano do projeto
perante a cpula de gerentes e coordenadores participantes, para a continuidade do
projeto.
6.3 Etapa de definio

Para o modelo proposto foi utilizada a etapa de definio apresentada na Seo
5.2.2, sendo executadas as seguintes fases:
6.3.1
Planejamento detalhado
Esta fase se constitui especificamente no aprofundamento dos levantamentos

realizados na etapa de definio e atualizao do Plano do Projeto. No geral foram
realizadas as seguintes atividades, as quais foram organizadas em dois mdulos
distintos, conforme j abordados.
6.3.2
Mdulo de atividades preparatrias
Quanto a este mdulo, verificam-se as seguintes atividades preparatrias:
Estudo de bases de dados, anlise dos arquivos de dados, sistemas OLTP,

inclusive o cdigo fonte de programas;
Anlise de relatrios e documentos disponveis, levando em conta os requisitos

preliminares levantados nas fases anteriores;
Na definio de quem entrevistar, levando em conta as definies feitas nas fases

anteriores, foram entrevistados os gerentes e coordenadores do setor de
compras;
Quanto ao que se perguntar, foi questionado tudo referente a proposta que foi
modelada, por exemplo, que tipos de informaes so importantes na transao
das vendas de uma loja, etc;
Os tempos das entrevistas variaram em mdia de 30 a 60 minutos, entre os

gerentes e coordenadores do setor comercial.
6.3.3
Mdulo de requisitos detalhados
Levando em conta a execuo do mdulo anterior, verificam-se , neste mdulo, as

seguintes definies:
Cada uma das lojas um supermercado moderno, levando em conta o conceito de
shopping, composto por uma variedade de departamentos, incluindo mercearia,
congelados, laticnios, aougue, verduras e legumes, padaria, flores, bens durveis,
bebidas e toda a rea de bazar. Cada loja trabalha, dependendo do tamanho, com
aproximadamente 50 mil produtos individuais em suas prateleiras. Os produtos
individuais so chamados aqui, como unidades de estoque (UNE).
Cerca de 30 mil das UNEs provm de fornecedores externos e apresentam cdigos
de barras nas embalagens. Estes cdigos de barras so chamados de EANs e
58
representam o mesmo gro que uma UNE individual. Cada variao de embalagem de
um produto possui um a UNE diferente e, portanto, uma EAN diferente.
As 20 mil UNEs restantes provm de setores como aougue, verduras e legumes,
padaria ou flores e no possuem cdigos EAN reconhecidos em mbito nacional.
Entretanto se deve atribuir um nmero UNE a esses produtos e se colocar etiquetas para
a leitura ptica.
Considerando que o processo a ser modelado no movimento das vendas, o banco
de dados permitir ver em detalhes quais produtos esto sendo vendidos em que lojas, a
que preo e em que dias. Usurios do setor comercial, alm da preocupao com a
logstica de organizao e com o abastecimento das gndolas, esto preocupados com a
venda dos produtos, assim como a maximizao do lucro em cada loja.
Ficou definido que a granularidade dentro do banco de dados por venda do cliente
(transao). Uma vez que quanto mais detalhes, menor o nvel de granularidade,
consequentemente, maior o volume de dados armazenado, foi prevista uma grande rea
de armazenamento. O fato de se poderem identificar os clientes, por transao de venda,
possibilita buscar informaes a respeito da logstica de comportamento de compras,
por exemplo, o perfil de clientes numa loja, produtos mais vendidos na regio, produtos
menos vendidos, produtos indispensveis, etc.
O lucro resulta principalmente de cobrar o mximo possvel por um produto, reduzir
os custos de aquisio e custos indiretos do produto e, ao mesmo tempo, de atrair o
maior nmero possvel de clientes por meio de uma poltica de preos altamente
competitiva. As decises administrativas mais significativas que podem ser tomadas em
tempo real relacionando-se com promoes e poltica de preos.
Tanto o setor comercial, como o setor de marketing, gasta muito tempo ajustando
preos e lanando promoes. As promoes em um supermercado incluem redues
temporrias de preos, anncios e encartes em jornais, display nos supermercados. A
maneira mais objetiva e eficaz de criar um aumento no volume (quantidade do produto
vendida) diminuir o preo drasticamente.
Uma reduo de 50 centavos no preo de toalhas de papel, especialmente quando
conjugada a um anuncio e a um display, pode aumentar em 10 vezes o volume de
vendas de toalhas de papel. Infelizmente, uma reduo de preo como esta no
sustentvel porque provavelmente as toalhas estaro sendo vendidas com prejuzo.
Pode-se concluir que a visualizao de todos os tipos de promoo consiste em uma
parte importante da anlise das operaes do setor comercial.
6.3.4 Arquitetura de dados
Dentre as arquiteturas apresentadas no Capitulo 2, se definiu pela utilizao da
arquitetura centralizada, uma vez que os dados propostos na modelagem deste estudo de
caso ficam centralizados no servidor da Administrao e pela facilidade de sua
implementao.
59
BD
BD
DW
Figura 6.2:Topologia Centralizada.

Para os registros das vendas, as lojas digitalizam os cdigos de barras diretamente
para o sistema de ponto-de-venda (PV). Os PVs ficam na entrada da loja e onde os
clientes fazem as suas compras. Os dados registrados de uma transao de venda so
acumulados e transferidos de tempos em tempos para uma tabela temporria do banco
de dados local, para que possam replicar para o servidor da Administrao.
Para o processo de controle das O conceito de RPD, se d sobre a forma no qual os
dados esto dispostos em Banco de Dados(BD). Esta replicao ocorre via Servidor de
Replicao (SR), no qual gerencia a atualizao das Tabelas dos BDs. No caso da Cia.
Zaffari, a estrutura para o processo de replicao do ponto de venda (PV) pode ser
representada conforme Figura 6.2.
Cada local possui um servidor contendo o Banco de Dados Sybase (BD), o Servidor
de Replicao (SR), o Servidor de Backup (SBK) e o Arquivo de Log (Log). Em cada
servidor, os Banco de Dados possui seus dados originais e dados replicados, oriundos de
outros Bancos de Dados. claro, que isto vai depender de definies fsicas sobre cada
Loja e/ou Depsito (e.g. a estrutura fsica da Loja X pode ser composta do Depsito
(CD) e da prpria Loja X).
Na Figura 6.3 os dados sobre a venda do servidor da Loja X so replicados para o
servidor o ADM, pelas rotas B1 e B2, no qual retornam uma mensagem de status
(envio de ok ou no). Observe que nas rotas A1 e A2 representam a replicao de outras
Lojas para a Administrao, uma vez elas tambm participam deste processo.
rota
B2
Log
SR
rota
B1
BD
DW
Log
SR
BD
rota
A2
SBK
SBK
rota
A1
SR
Log
BD
SBK
Figura 6.3: Estrutura de Replicao dos dados.
60
Outra definio importante, que os dados do BD, a cada transao, so copiados
para o arquivo de Log e limpos de hora em hora, aps serem transferidos para o
Backup.
6.3.5 Arquitetura funcional
Para esta fase foram consideradas as propostas de [KIM 98a] e [PER 2000] para a
definio da arquitetura funcional interna. Esta arquitetura foi adaptada ao projeto
proposta a Cia Zaffari, conforme mostra a Figura 6.4, permitindo identificar os objetos
a serem criados na base de dados, influenciando nas fases de infra-estrutura e projeto de
banco de dados.
Como j apresentada na Seo 2.5 (Figura 2.8), a rea interna pode ser classificada
em: (a) rea de sistemas fontes, (b) rea de organizao dos dados (Staging), onde os
dados de fontes tradicionais (sistemas e outras) so copiados, formatados e armazenados
e (c) a rea do DW (servidor de apresentao), onde os dados tratados so carregados.
6.3.6 Infra-estrutura
Para a execuo do modelo proposto, ser utilizado a arquitetura de servidor HP
K580 e sistema operacional Unix. Ser utilizada para a construo de programas de
transformao e carga, para a arquitetura funcional, a linguagem de programao que
atualmente utilizada para a construo das aplicaes convencionais da prpria Cia
Zaffari.
6.3.7 Modelagem dimensional
Nesta fase foram definidas as tabelas necessrias para atender as definies da
arquitetura funcional, alm de modelar as tabelas de dimenso e fato.
Levando em conta as definies sobre os esquemas multidimensionais apresentadas
na Seo 2.3.2.1 (Figura 2.5), foi definida a utilizao do esquema estrela pelo fato de
ser mais eficiente na recuperao de dados e informaes, alm da facilidade de
compreenso do modelo. O esquema floco-de-neve no foi utilizado pelo fato de no
haver relacionamentos muitos para muitos entre as tabelas dimenso e por apresentar
a desvantagem do aumento da complexidade da arquitetura.
Por definio, a tabela de fatos em uma estrutura dimensional de natureza
altamente normalizada e a maior tabela do banco de dados dimensional. As tabelas
dimensionais, por definio, so quase sempre geometricamente menores que a tabela
de fatos. Qualquer estimativa realista do espao em disco necessrio para o DW pode
efetivamente ignorar as tabelas de dimenso.
Considerando o processo de registro de vendas, cada loja deve gerar um relatrio
completo de todas as vendas de produtos de cada cliente. Levando em conta o grande
volume de vendas dirias, tomou-se como abordagem a transferncia a cada transao
individual de venda para o servidor da administrao e desta forma executar o resumo
dirio. Esta transferncia feita atravs de uma programao nos PVs, para que de
tempos em tempos faam o processo de atualizao e envio.
61
Sistemas Fontes
rea Interna
Tabelas de Descries
p/ as Dimenses
Bases de dados
Nome de atributos.
sobre as vendas
ocorridas nas lojas.
Extrao
(Ferramentas)
Tabela de Vendas Extrados

Armazena todos os dados extrados.
Transformao
(Programas)
Transformao
(Programas)
Extrao
(Ferramentas)
Tabela de Vendas Organizados

Tabela de Erros Transformao
Armazena os registros com

problemas.
Organizao
(Ferramentas)
Transformao (Programas)
Tabela de Vendas Com Erros
rea de
Carga de dados
Armazena todos os dados transformados

e no transformados.
Armazena todos os dados no

transformados de vendas.
Tabela de Vendas
Transformados
Armazena todos os dados
transformados corretamente.
Carga de dados
(Programas)
Carga de dados
Tabela de Auditoria na transformao

Armazena resultados de auditoria nos dados
transformados.
Tabela de Erros
Carga de dados
Armazena os registros
com problemas.
(Ferramentas)
Tabela de Fatos - Vendas

Armazena os fatos sobre as
vendas.
Carga de dados (Programas)
Tabela de
Auditoria na
Carga de
dados.
Tabelas Dimenso
rea do
Armazena as dimenses referentes a

tabela de fato venda.
Carga de dados (Programas)
DW
Figura 6.4: Arquitetura Funcional.
62
Dimenso
Produto
Fato
Dimenso
Promoo
Venda
Dimenso
Loja
Dimenso
Dimenso
Tempo
Cliente
Figura 6.5: Modelo Estrela para o modelo proposto.

Levando em conta as necessidades levantadas para este modelo, definiu-se que o
modelo proposto ser composto pela tabela de fato venda e pelas tabelas de dimenso:
produto, cliente, tempo, promoo e loja . A Figura 6.5 descreve o relacionamento
existente entre a tabela fato e as dimenses.
Uma vez que se prope a modelar a transao de venda por cliente , a tabela de
dimenso tempo necessria para que se possam separar os dados por dias teis e
feriados, por perodos fiscais, por estaes ou ainda por eventos. Cada registro da
tabela de dimenso tempo representa um dia e ao contrrio das demais tabelas de
dimenso, pode ser construda com antecedncia, podendo gerar de cinco a dez anos de
registros. Os campos que representam a tabela de dimenso tempo so: chave-tempo,
dia-da-semana, numero-do-dia-do-ms, numero-em-dia, ms, trimestre, perodo-fiscal,
indicador-fiscal, temporada, evento.
A tabela de dimenso produto descreve cada UNE, o qual identificado pelo
cdigo de barra EAN. Um produto representado por uma estrutura aqui chamada de
hierarquia de mercadoria , composta de grupo, classe, seo e departamento. Desta
forma, os atributos que representam a tabela de dimenso produto so: chave-produto,
nome-produto, EAN, embalagem, data-da-estrutura, grupo, classe, seo, departamento,
peso, tipo-dieta, embalagem-por-palete e outros.
A tabela dimenso loja descreve cada loja da rede de supermercado da Cia Zaffari, e
pode ser considerado como sendo um elemento geogrfico. Os atributos que
representam a dimenso loja so: chave-loja, nome-loja, numero-loja, endereo-loja,
cidade-loja, municpio-loja, estado-loja, cep-loja, regio-loja, gerente-loja, fone-loja,
tipo-planta-loja, data-abertura, data-ultima-reforma, numero-de-habitantes, renda-percapita e outros.
A tabela dimenso promoo descreve todas as condies de promoo aplicadas
venda de um produto na rede de supermercado da Cia. Zaffari. Condies de promoo
incluem redues temporrias de preos, terminais promocionais, anncios de jornais e
cupons. Os atributos da tabela dimenso promoo so: chave-promoo, nomepromoo, tipo-de-preo, tipo-anuncio, tipo-cupom, nome-mdia, fornecedor-promoo,
data-inicio-promoo, data-trmino-promoo e outros.
A tabela dimenso cliente ascende para todos os clientes que efetuam uma transao
de venda, gerando um cupom de venda. Esta dimenso importante pois possibilita
uma anlise de comportamento de compras, identificando o perfil de compra, por
63
regio e loja. Os atributos da tabela dimenso cliente so: chave_cliente, nome-cliente,

endereo-cliente, fone-cliente, e-mail-cliente, e outros.
A tabela de fato venda representa as medidas do negcio, que so mensuradas de
forma quantitativa, tais como os atributos de valor da venda, quantidade vendida e o
custo de venda de um produto relacionada com as tabelas de dimenso produto e
cliente, permitindo identificar a quantidade vendida de um produto por um certo
cliente. A tabela de fato armazena grande quantidade de dados, possuindo chave
primria composta, formada por chaves estrangeiras, atravs das quais se ligam as
chaves primrias das tabelas dimenso. Desta forma, os atributos chave que representam
a tabela de fato venda so: chave-tempo, chave-cliente, chave-produto, chavepromoo, chave-loja. Os atributos fatos (medidas) so: valor-da-venda, quantidadevendida, custo-da-venda, e so considerados fatos aditivos pelo fato de que podem ser
somados cruzando-se qualquer uma de suas dimenses.
6.3.8 Projeto da base de dados
Nesta fase, a participao do administrador de banco de dados fundamental para a
definio de uma alocao de espao de disco necessrio para armazenar os dados da
base analtica, assim como para as atividades de organizao de dados para a construo
de um DW. Para o clculo de estimativa do numero de linhas de itens das transaes
individuais em uma das lojas, se identifica a receita bruta da rede como um todo, por
exemplo, quatro bilhes ao ano. Alm disto, se mensura o preo mdio de um produto
vendido, por exemplo, o valor de dois reais. Considerando estes dois parmetros, podese afirmar que existiro dois bilhes de linhas de itens, por ano (4 bilhes divididos por
2 reais). Pode-se concluir que, o numero bsico de linhas de item nas transaes de
venda de um negcio pode ser estimado dividindo-se a receita bruta do negcio pelo
preo mdio do item.
Levando em conta o clculo sobre as transaes de venda, o tamanho do DW podese dividir o numero de linhas de item, por ano, para toda a rede de lojas (2 bilhes) por
365 dias e pelo numero de lojas, por exemplo, 20 e desta forma, teremos o valor de 11
mil itens por dia e loja.
6.3.9 Avaliao de produtos
Para esta fase, se devem testar as ferramentas necessrias para o projeto e construo
do DW. Por motivos de no se ter uma aplicao mais prtica para o estudo de caso,
uma vez que a Cia Zaffari no aprovou a execuo do projeto, esta fase fica apenas
descrita com uma definio mais conceitual. Como um dos critrios para viabilizar e
justificar o uso desta metodologia, a necessidade de experincia em projetos de DW,
uma empresa de consultoria e desenvolvimento se fez necessria, e desta forma,
produtos sero apresentados e analisados, em tempo de aprovao da execuo do
projeto, propriamente dito.
6.3.10 Execuo da arquitetura funcional
Esta fase, assim como a fase anterior, no foi aplicada. a fase que mais consome
tempo, pois se constitui da efetiva execuo da arquitetura funcional, levando em conta
a criao de rotinas para a transformao e organizao, alem das tabelas auxiliares
destinadas a armazenar informaes sobre os dados errados ou rejeitados.
64
6.3.11 Aplicaes finais
Esta fase representa a construo de relatrios previstos na fase de planejamento
detalhado, levando em conta as ferramentas que devero ser escolhidas para esta
funo.
6.3.12 Auditoria de dados
Esta fase se constitui na utilizao intensiva dos relatrios gerados na fase de
aplicaes finais, pela equipe do projeto com o objetivo de verificar se os resultados
obtidos estaro corretos e consistentes, alm disto, um acompanhamento na fase de
extrao, organizao, transformao e carga se fazem necessria, para se obter uma
melhor performance.
6.4 Etapa de execuo

Como j recomendado anteriormente, apesar de ter sido autorizada a execuo do
projeto de DW pela Cia. Zaffari,, a sua implementao no ficou definida em que
momento ser feita. Desta forma a execuo do Plano de Projeto de DW no pode ser
executada e este fator refletiu-se mais tarde na dificuldade da obteno de certos dados a
respeito desta fase. Apesar deste fato, um aspecto que ficou evidenciado, durante a
montagem do Plano de Projeto, foi a facilidade e rapidez na obteno de informaes
para o projeto de DW.
6.5 Consideraes finais

Pode-se observar que dentre os resultados obtidos com a aplicao da metodologia
proposta, confirmou-se a grande demanda por informaes gerenciais ainda no
dispostas, e que pelo grande volume de dados, a necessidade de implantao do projeto
de DW. No geral foram obtidas as seguintes consideraes:
Consegue-se, a partir da metodologia proposta, se fazer um levantamento

completo a respeito do movimento de venda, por cliente e desta forma,
apresentar ao grupo de usurios os principais resultados obtidos;
Comprova-se que o esquema estrela apresenta uma maior eficincia na

recuperao de dados e informaes quando comparado com o modelo floco de
neve;
Pelo fato de que a tabela de fatos de natureza altamente normalizada, os

esforos para normalizar qualquer uma das tabelas de dimenso em um banco de
dados dimensional, simplesmente para se obter espao em disco, so uma perda
de tempo;
Desenvolver um DW no diferente de se desenvolver um projeto de tecnologia

de informao. necessrio planejamento, definio de requerimentos, projetos
e implantao;
Podem-se identificar questes no comumente existentes no mbito gerencial,

tais como: (a) vale a pena estocar tantos tamanhos diferentes de determinados
produtos? , (b) Quais produtos so canibalizados quando se promove um
determinado produto, em outras palavras, quais produtos sofrem uma queda de
venda quando se promove um outro? (c) Quais produtos so os mais vendidos,
65
por lojas, (d) Qual o perfil dos clientes, por regies e (f) Quais os produtos
indispensveis em uma loja?
No se pode identificar na tabela de fatos, quais produtos que no so vendidos,

uma vez que ela representa a transao sobre as vendas, por cliente, dia e loja;
Um DW quase sempre precisa de dados expressos no nvel de menor gro de

cada dimenso, no porque as consultas queiram ver registros analticos
individuais, mas porque as consultas precisam aprofundar-se no banco de dados
de maneira precisa;
A definio do nvel de granularidade permite determinar as dimenses

primrias da tabela de fatos;
Levando em conta a definio por uma arquitetura centralizada, o DW projetado

no estudo de caso pode parecer propenso a se tornar um DM, uma vez que
possui caractersticas quanto ao foco de usurios finais serem de uma rea da
empresa (setor comercial);
Por existir um monte de dados histricos para suporte a deciso que raramente
so usados, a empresa pode reduzir o armazenamento de dados, baseada em
algum critrio, o se justifica o fato de que projetos que comeam como um DW,
algumas vezes evoluem para Data Marts;
O processo de iterao permitiu se ter vrias repeties de execuo das etapas

de um projeto de DW (anteprojeto, definio e execuo) para cada uma as
etapas do ciclo de desenvolvimento, iniciando na fase de incepo e terminando
na fase de transio.
66
7 CONCLUSO
Este trabalho foi feito com o objetivo de propor uma metodologia prtica de projeto
de DW, e desta forma desenvolveu-se um trabalho de pesquisa que estabeleceu como
metas principais: (a) estudo das principais metodologias de DW existentes, (b) a
proposta de uma metodologia de desenvolvimento para projeto de DW e (c) a avaliao
da adequao e consistncia da metodologia proposta, atravs de um estudo de caso real
na Cia Zaffari.
A metodologia proposta, depois de aplicada mostrou-se adequada e consistente na
soluo dos problemas com relao completude, detalhamento e iterao, critrios que
motivaram este trabalho e que foram citados no captulo 5.
Levando em conta que estes critrios definidos no foram totalmente satisfeitos por
outras metodologias de projeto de DW apresentadas no captulo 4, a metodologia
proposta sustenta-se sobremaneira sobre o critrio de iterao, baseada no conceito
apresentado pela metodologia RUP. Nele, o projeto de DW elimina as incertezas e
riscos de insucesso, atravs da realizao de uma srie de execues sobre o ciclo de
vida da metodologia proposta, at a obteno de um Plano de Projeto consistente para
ser aprovado e implantado.
A tabela 3 apresenta o resumo das metodologias de projeto de DW estudadas, assim
como as principais caractersticas da metodologia proposta.
Tabela 3 Resumo das metodologias de projeto de DW e proposta.
Caractersticas
[MAR 99]
[KIM 98a]
[POE 98]
[PER 2000]
Proposta
Completa
Sim
Sim
Sim
Sim
Sim
Experincia
Sim
Sim
Sim
No
Sim
Fases da metodologia
- viso estratgica;
- planejamento;
- planejamento;
- levantamento;
- avaliao da
engenharia;
- definio de
requisitos do
negcio;
- levantamento
de requisitos e
modelagem;
levantamento
- projeto de
arquitetura tcnica;
- projeto fsico
da base de
dados;
- avaliao do fluxo
de valores;
- avaliao da
questo comercial;
- projeto/reviso;
- modelagem
dimensional;
- caso comercial do
DW;
especificao de
aplicaes de
usurio final;
- plano de
implementao da
- seleo e
- determinao
e mapeamento
das fontes de
dados;
- populao do
DW;
preliminar;
planejamento
preliminar;
- planejamento;
- planejamento
detalhado;
- arquitetura de
dados;
levantamento
detalhado;
- arquitetura
funcional;
- prottipo;
- infraestrutura;
- definio do
projeto e
- modelagem
dimensional;
67
iterao;
- projeto detalhado
- implementao;
- transio p/
produo;
- manuteno.
instalao de
produtos;
- automao dos
processos;
atualizao do
planejamento;
- projeto de
BD;
- projeto fsico;
- criao do
conjunto inicial
de relatrios;
- projeto
piloto do DW
- avaliao de
produtos;
- projeto e
desenvolvimento da
organizao de
dados;
- disponibilizar do
DW;
- execuo da
arquitetura
funcional;
- validao e
testes de dados;
- treinamento;
- aplicaes
finais.
- produo.
- manuteno e
crescimento.
Detalhamento das
fases
Pouco detalha
Detalha
Detalha
Detalha
Detalha
Arquitetura de dados
No
Acesso a dados
(Rolap e Molap)
Centralizada,
DM
dependentes e
independentes
Centralizada,
DM
dependentes e
independentes
Banco de
dados
integrado a um
DW e
[POE 98]
Arquitetura funcional
No
ra interna,
servidor de
apresentao, rea
externa e
metadados.
Integrao de
dados,
transformao
de dado,
arquitetura de
dados e
metadados
ra interna,
servidor de
apresentao,
rea externa,
servios e
metadados
[KIM 98a]
Anteprojeto
No possui
Possui
Possui
Possui
Possui
Auditoria de dados
No detalha
Detalha
Detalha
Pouco detalha
[KIM 98 a] e
[POE 98]
Iterao completa
No
No
No
No
Sim
A metodologia proposta foi concebida de forma a ser genrica o suficiente para ser
aplicada em vrios ambientes organizacionais e vrios domnios de problema. No
entanto, a validao desta generabilidade no foi realizada pois s foi aplicada em um
nico estudo de caso. Alm disto, no se pode atingir a etapa de execuo na sua
totalidade devido a fatores j citados na seo 6.2.1.1, o que dificultou numa avaliao
dos resultados esperados no estudo de caso.
Ao encerrar a execuo do projeto junto a Cia Zaffari, utilizando a metodologia
proposta neste trabalho, pde-se concluir que os resultados obtidos neste projeto, alm
de atender as necessidades gerenciais, tambm despertou o interesse do pblico
envolvido no projeto sobre a tecnologia de DW.
Como perspectivas de trabalho futuro para a metodologia proposta, sugere-se:
A realizao de um estudo mais detalhado sobre a tecnologia de Data Mining;
O acompanhamento da evoluo da equipe do projeto em sua experincia nas

necessidades metodolgicas correspondentes;
Anlise de tendncias mais especficas atravs da tecnologia de DW;
68
Integrao de banco de dados heterogneos para a formao do DW, levando em

conta a utilizao de padres de comunicao e acesso como CORBA e
ActiveX;
A realizao de testes de campo mais aprofundados, procurando-se apresentar

aos tomadores de deciso, informaes com as quais normalmente no se
trabalha.
E mais amplamente em relao a rea de DW, sugere-se:
Estudo sobre Data Warehouse orientado a objetos, pois ainda no existe

nenhuma implementao nesta rea, levando em conta a modelagem,
armazenamento, mtodos de acesso e carga de dados em um banco de dados
orientado a objetos;
Descoberta de conhecimento em banco de dados, uma nova rea que integra o

DW com informaes externas de modo que essas informaes possam gerar
informaes mais complexas e detalhadas ao usurio;
Um estudo sobre as tcnicas de compresso de dados, considerando que a base

de dados de um DW muito grande, como se poderia efetuar a compactao e
descompactao de forma a no se ter perda na performance sobre as consultas.
69
REFERNCIAS
[BOO 2000] BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML

Guia do usurio. Rio de Janeiro: Campus, 2000.
[COR 97]
CORBELLINI, Humberto. Um estudo sobre a tecnologia data

warehouse. 1997. Trabalho Individual (Mestrado em Cincia da
Computao) Instituto de Informtica, Universidade Federal do Rio
Grande do Sul, Porto Alegre.
[DAM 2000]
Data Mines for Data Warehouse. Disponvel em:

<http://www.datamining.com/dm4dw.htm> Acessado em : 28 de
junho de 2000.
[DBM 2001]
DBMiner E1.1. User Manual For Windows NT/95. DBMiner

Technology Inc. Disponvel em:
<http://db.cs.sfu.ca/DBMiner/dowload2> Acessado em:10 de
setembro de 2001.
[DWH 2000]
Data Warehouse HomePage Disponvel em:

<http://www.datawarehousing.com/ > Acessado em: 05 de julho de
2000.
[DWM 2001]
Data Warehouse Data Mining Disponvel em:

<http://www.datawarehousing.inf.br > Acessado em:01 de setembro
de 2001.
[DWP 2000]
Data Warehouse papers & Articles Disponvel em:

http://www.datawarehousing.com/papers.asp Acessado em:01 de
julho de 2000.
[EDE 94]
EDELWEISS, Nina; OLIVEIRA, Jos P.M. Modelagem de

Aspectos Temporais de Sistemas de Informao. IX Escola de
Computao. 1994 , Recife.PE.
[FAY 96]
FAYYAD,
Usama,
PIATETSKY-SHAPIRO,
Gregory,
PANDHRAIC, Smyth. From data mining to knowledge discovery:
an overview. Advances in knowledge and data mining. Califrnia:
AAAI Press, 1996.
70
[FUR 98]
FURLAN, Jos Davi. Modelagem de objetos atravs da UML The

Unified Modeling Language. So Paulo: Makron Books do Brasil,
1998.
[GEN 98]
GENERINI, Adelize O. Conceitos e solues. Florianpolis: 1998.

v.1.
[GRA 98]
GRAY, Paul; WATSON, Hugh J. Decision Support in the Data

Warehouse. New Jersey: Prentice Hall, 1998.
[HAR 96]
HARJINDER, G; RAO, P.C. The official design the data

warehousing, : Que Corporation, 1996.
[INM 97]
INMON, Willian H. Como construir o data warehouse. Rio de

Janeiro: Campus, 1997. v.1.
[KIM 98]
KIMBALL, Ralph. Data warehouse toolkit. So Paulo: Makron

Books, 1998.
[KIM 98a]
KIMBALL, Ralph, REEVES et al. The data warehouse lifecycle

toolkit: expert methods for designing, developing and developing
data wharehouse. New York: Jonh Wiley & Sons, 1998.
[MAR 99]
MARTIN, James. Microsoft SQL Server 7.0 Manual Prtico.

Rio de Janeiro: Campus, 1999.
[MIC 2000]
Microsoft Servers SQL 7.0 - Data Warehousing Framework.

Disponvel
em:
<http://www.microsoft.com/SQL/techinfo/datawareframe.htm>
Acessado em: 15 de junho de 2000.
[MOR 97]
MORAES, Rodrigo L. Um survey sobre a tecnologia data

warehouse. 1997. Trabalho Individual (Mestrado em Cincia da
Computao) Instituto de Informtica, Universidade Federal do Rio
Grande do Sul, Porto Alegre.
[PEK 96]
PERKINS, Alan. Developing a data warehouse. Visible Sustems

Corporation. 1996.
[PER 2000]
PEREIRA, Walter A. L. Uma metodologia de insero de

tecnologia de data warehouse em organizaes. 2000. Trabalho
Individual II (Mestrado em Cincia da Computao) Instituto de
Informtica, Pontifcia Universidade Catlica do Rio Grande do Sul,
Porto Alegre.
[POE 98]
POE, Vidette, KLAUER, Patricia, BROBST, Stephen. Building a

data warehouse for decision support. New Jersey, Prentice Hall
PTR. 1998.
71
[SYB 2000]
Sybase Products. Disponvel em:

<http://www.sybase.com/products.html> Acessado em: 07 de julho
de 2000.
[VAL 96]
VALENTE, Daphnis L. Estudo sobre armazm de dados. 1996.

Trabalho Individual (Mestrado em Cincia da Computao)
Instituto de Informtica, Universidade Federal do Rio Grande do Sul,
Porto Alegre.

Data Warehiuse Na Prática

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

Data Warehiuse Na Prática

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

RAFAEL GASTO COIMBRA FERREIRA

Data Warehouse na Prtica: Fundamentos e Implantao

Dissertao apresentada como requisito parcial

Prof. Dr. Marcelo Soares Pimenta

Porto Alegre, abril de 2002.

CIP CATALOGAO NA PUBLICAO

Ferreira, Rafael Gasto Coimbra

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Gostaria de agradecer a Deus,

LISTA DE ABREVIATURAS E SIGLAS.........................................................7

3FERRAMENTAS PARA O PROJETO DE DATA WAREHOUSE.............25

3.2Oracle Data Warehouse ...............................................................................................................27

4METODOLOGIAS DE PROJETO DE DW: UMA ANLISE......................33

5PROPOSTA DE UMA METODOLOGIA PARA CRIAO DE DW..........46

6ESTUDO DE CASO: DESENVOLVIMENTO DE UM PROJETO DE DW. 53

LISTA DE ABREVIATURAS E SIGLAS

Sistemas de Suporte a Deciso

Object Linking and Embedding

OLAP On-Line Analytical Processing

Sistema Gerenciador em Banco de Dados Multidimensional

Sistema Gerenciador em Banco de Dados Relacional

Sistema de Informao Gerencial

Structure Query Language

SAD Sistema de Apoio a Deciso

Servio de Transformao dos Dados

FIGURA 2.1: EXEMPLO DE DADOS BASEADOS EM ASSUNTOS..........16

FIGURA 4.3: CICLO DE VIDA DE [POE 98]................................................41

TABELA 1 ANLISE DAS METODOLOGIAS DE PROJETO DE DW....45

Embora o conceito de Data Warehouse (doravante abreviado DW), em suas vrias

Palavras-Chave: data warehouse, banco de dados, OLAP.

Date Warehouse in Practice: Foundations and Implementation

Keywords: data warehouse, database, OLAP.

Desde que as organizaes passaram a dar a devida importncia a bancos de dados

1.1 Proposta do Trabalho

Neste captulo, sero abordados conceitos bsicos necessrios para a compreenso

2.1 Sistema de apoio deciso

2.2 Data Warehouse

Para [INM 97], um conjunto de bancos de dados integrados e baseados

DW um processo que aglutina dados de fontes heterogneas, incluindo

Para [GAR 98] um processo, no um produto, para a montagem e

Caractersticas bsicas de um Data Warehouse

Um resumo das principais caractersticas bsicas de um DW ser apresentado a

Figura 2.1: Exemplo de dados baseados em assuntos.

Figura 2.2:Exemplo de dados integrados.

baixo nvel de granularidade

baixo nvel de detalhe

alto nvel de granularidade

Figura 2.3: Exemplo de granularidade.

2.3 Processamento OLAP e modelagem de dados

O processamento analtico On-Line (On-line Analytic Porcessing OLAP)

(a) Esquema estrela

(b) Esquema floco de neve

Aditivas: so as mais freqentes, podem ser somadas cruzando-se qualquer uma

Semi-aditivas: podem ser somadas atravs de apenas uma parte de suas

No aditivas: no podem ser somadas por nenhuma de suas dimenses. O

As tabelas dimensionais armazenam as descries textuais que ajudam na

Figura 2.6: Exemplo simples do modelo estrela.

2.4 Data Marts

2.5 Arquitetura de Dados

Centralizada, caracterizada por um nico DW que atende a toda a

Data Marts independentes, caracteriza-se pela ligao dos usurios aos

Data Warehouse Distribudo, consiste de vrios DW interligados atravs

Figura 2.7: Topologias de um Data Warehouse.