Um Estudo Sobre Data Warehouse

Universidade de Caxias do Sul
Cento de Cincias Exatas e Tecnologia

Departamento de Informtica
Bacharelado em Cincias da Computao
Um Estudo sobre Data Warehouse
ADRIANO DALALBA
CAXIAS DO SUL - RS
Nominata
Reitor:
Prof. Ruy Pauletti
Vice-reitor:
Prof. Luiz Antnio Rizzon
Pr-Reitor de Graduao:
Prof. Luiz Antnio Rizzon
Chefe do Departamento de Informtica:
Profa. MSc. Maria de Ftima Webber do Prado Lima
Sub-chefe do Departamento de Informtica:
Prof. MSc. Heitor Strogulski
Coordenadora do Colegiado do Curso de Bacharelado em Cincias da Computao:
Profa. MSc. Carine Geltrudes Webber
Sumrio
NOMINATA ......................................................................................................................................... 2
SUMRIO ............................................................................................................................................ 3
LISTA DE ABREVIATURAS.............................................................................................................. 5
LISTA DE FIGURAS ........................................................................................................................... 6
LISTA DE TABELAS .......................................................................................................................... 7
RESUMO .............................................................................................................................................. 8
ABSTRACT.......................................................................................................................................... 8
1
INTRODUO ......................................................................................................................... 10
CONCEITOS............................................................................................................................. 12
CARACTERSTICAS DO DATA WAREHOUSE .................................................................... 15

3.1
ORIENTAO POR ASSUNTO.................................................................................................... 15
3.2
INTEGRAO ......................................................................................................................... 15
3.3
VARIAO NO TEMPO ............................................................................................................ 16
3.4
NO VOLATILIDADE ............................................................................................................... 17
3.5
LOCALIZAO ....................................................................................................................... 17
3.6
CREDIBILIDADE DO DADOS ..................................................................................................... 18
3.7
GRANULARIDADE .................................................................................................................. 20
3.8
OS METADADOS ..................................................................................................................... 22
3.8.1
Fontes de metadados ...................................................................................................... 23
ARQUITETURA DO DATA WAREHOUSE ............................................................................ 25

4.1
ARQUITETURA GENRICA DE DATA WAREHOUSE ..................................................................... 25
4.2
ARQUITETURA SEGUNDO CHAUDHURI .................................................................................... 27
4.2.1
Fontes de dados internas ................................................................................................ 29
4.2.2
Fontes de dados externas................................................................................................ 29
4.3
ARQUITETURA SEGUNDO VALENTE......................................................................................... 30
4.3.1
Extrao dos dados ........................................................................................................ 30
4.3.2
Integrador ...................................................................................................................... 30
4.3.3
Processamento de informaes ....................................................................................... 31
4.4
OUTRAS ARQUITETURAS......................................................................................................... 32
4.4.1
Arquitetura de duas camadas .......................................................................................... 32
4.4.2
Arquitetura de trs camadas ........................................................................................... 33
MODELOS DE DADOS............................................................................................................ 35
5.1
MODELO DE DADOS SEGUNDO R.KIMBALL .............................................................................. 35
5.1.1
Modelo empresarial ....................................................................................................... 35
5.1.2
Modelo dimensional ...................................................................................................... 37
5.1.3
Modelo fsico ................................................................................................................ 43
5.2
MODELO DE DADOS SEGUNDO W.H.INMON ............................................................................. 45
5.2.1
Modelo de dados de alto nvel ........................................................................................ 45
5.2.2
Modelo de dados de nvel intermedirio ......................................................................... 46
5.2.3
Modelo de dados de baixo nvel ..................................................................................... 47
5.3
ESTRATGIA DE CONVERSO DO MODELO E-R PARA O MODELO DE DADOS DO DW ................... 48
5.3.1
Remoo dos dados puramente operacionais .................................................................. 48
5.3.2
Adio de um elemento de tempo na estrutura da chave .................................................. 48
5.3.3
Introduo de dados derivados ....................................................................................... 49
5.3.4
Transformao de Relacionamentos entre dados em artefatos dos dados ......................... 49
5.3.5
Acomodao dos diferentes nveis de granularidade ....................................................... 51
5.3.6
Unio dos dados comuns de diferentes tabelas ................................................................ 52
5.3.7
Criao de arrays de dados ............................................................................................ 52
5.3.8
Separao dos atributos de dados de acordo com sua estabilidade ................................... 54
5.4
MODELO DE ESTRUTURA DOS DADOS ...................................................................................... 55
6
DESENVOLVIMENTO DO DATA WAREHOUSE ................................................................. 56

6.1
AS FUNES EM UM DATA WAREHOUSE ................................................................................... 56
6.2
CONSIDERAES INICIAIS PARA O DESENVOLVIMENTO DE UM DATA WAREHOUSE ..................... 57
6.3
DESENVOLVIMENTO UTILIZANDO O MODELO ESTRELA ............................................................ 59
6.4
OS DADOS OPERACIONAIS....................................................................................................... 61
6.4.1
Tcnicas de gerenciamento da quantidade de dados operacionais pesquisados ................. 63
6.5
TCNICAS PARA INCREMENTAR A PERFORMANCE DO DATA WAREHOUSE ................................... 64
6.6
OS DATA MARTS ..................................................................................................................... 66
6.7
OS ERROS NO DESENVOLVIMENTO DE UM DATA WAREHOUSE .................................................. 68
POVOANDO UM DATA WAREHOUSE ................................................................................ 70

7.1
7.2
7.3
EXTRAO DOS DADOS DO AMBIENTE OPERACIONAL............................................................... 70

FILTRAR, TRANSFORMAR E INTEGRAR OS DADOS EXTRADOS ................................................... 71
FERRAMENTAS PARA EXTRAO DOS DADOS OPERACIONAIS ................................................... 72
EXTRAO DE INFORMAES DO DATA WAREHOUSE ............................................... 75

8.1
ACESSO AOS DADOS DO DATA WAREHOUSE .............................................................................. 75
8.2
GERADORES DE CONSULTA E RELATRIOS............................................................................... 77
8.3
EIS - EXECUTIVE INFORMATION SYSTEMS ................................................................................. 77
8.4
FERRAMENTAS DE OLAP (ON-LINE ANALYTICAL PROCESSING) ................................................. 78
8.4.1
Tipos de Ferramentas de OLAP ..................................................................................... 79
8.5
FERRAMENTAS DE MINERAO DE DADOS ............................................................................. 81
8.6
FORNECEDORES ..................................................................................................................... 82
8.7
FERRAMENTAS COMERCIAIS ................................................................................................... 83
8.7.1
PowerPlay ..................................................................................................................... 83
8.7.2
Maestro ......................................................................................................................... 85
8.7.3
Oracle............................................................................................................................ 87
ANLISE DO USO DA TECNOLOGIA DATA WAREHOUSE.............................................. 90

9.1
9.2
9.3
9.4
10
VANTAGENS .......................................................................................................................... 90
DESVANTAGENS .................................................................................................................... 91
DIFICULDADES DE DESENVOLVIMENTO ................................................................................... 92
EXEMPLOS ............................................................................................................................. 93
CONCLUSO ........................................................................................................................... 95
BIBLIOGRAFIA ................................................................................................................................ 97
Lista de Abreviaturas
BDM
DSS
DW
E-R
EIS
ERP
HTML
MOLAP
MPP
ODBC
OLAP
OLTP
ROLAP
SAD
SGBD
SMP
Banco de Dados Multidimensional

Decision Support System
Data Warehouse
Entidade/Relacionamento
Executive Information System
Enterprise Resource Planning
Hyper Text Markup Language
Multidimensional On-line Analytical Processing
Massively Parallel Processing
Open Data Base Connectivity
On-line Analytical Processing
On-line Transaction Processing
Relational On-line Analytical Processing
Sistemas de Apoio Deciso
Sistema Gerenciador de Banco de Dados
Symetric Parallel Processing
Lista de Figuras
FIGURA 2.1 COMPONENTE DE UM DATA WAREHOUSE. ........................................................................... 14

FIGURA 3.1 INTEGRAO DOS DADOS. ................................................................................................. 15
FIGURA 3.3 NVEIS DE GRANULARIDADE.............................................................................................. 20
FIGURA 3.4 NVEIS DUPLOS DE GRANULARIDADE PARA DADOS RESUMIDOS. .......................................... 21
FIGURA 4.1 ARQUITETURA DO AMBIENTE DE DW [ORR96]. ................................................................ 26
FIGURA 4.2 COMPONENTES DE ARQUITETURA DE UM DW SEGUNDO CHAUDHURI [MOR98]. ................. 27
FIGURA 4.3 O FLUXO DE DADOS NO SISTEMA [MOR98]. ....................................................................... 28
FIGURA 4.4 ARQUITETURA BSICA DE UM DW [VAL 96]. .................................................................... 31
FIGURA 4.5 ARQUITETURA DE DUAS CAMADAS. ................................................................................... 33
FIGURA 4.6 ARQUITETURA DE TRS CAMADAS. .................................................................................... 34
FIGURA 5.1 MODELO DIMENSIONAL DO TIPO ESTRELA. ........................................................................ 39
FIGURA 5.2 MODELO DIMENSIONAL DO TIPO FLOCO DE NEVE. ............................................................. 40
FIGURA 5.3 COMPARAO ENTRE O BD RELACIONAL E O BD MULTIDIMENSIONAL. ............................. 43
FIGURA 5.4 DEPENDNCIAS TRANSITIVAS ENTRE TABELAS. .................................................................. 45
FIGURA 5.5 REPRESENTAO DA MODELAGEM DE ALTO NVEL. ............................................................ 46
FIGURA 5.6 OS ELEMENTOS DO MODELO DE DADOS DE NVEL INTERMEDIRIO [INM97]. ....................... 47
FIGURA 5.7 REMOO DE DADOS PURAMENTE OPERACIONAIS. ............................................................. 48
FIGURA 5.8 ADIO DE UMA ELEMENTO DE TEMPO NA ESTRUTURA DA CHAVE. ..................................... 49
FIGURA 5.9 INTRODUO DE DADOS DERIVADOS NA CHAVE. ................................................................ 49
FIGURA 5.10 RELACIONAMENTO ENTRE TABELAS NO SISTEMA CORPORATIVO. ...................................... 50
FIGURA 5.11 INCLUSO DOS ARTEFATOS NO DW. ................................................................................ 50
FIGURA 5.12 CAPTURA DOS DADOS A CADA RECEBIMENTO DO PRODUTO. ............................................. 51
FIGURA 5.13 ALTERAO DO NVEL DE GRANULARIDADE. ................................................................... 52
FIGURA 5.14 UNIO DOS DADOS DE DIFERENTES TABELAS. .................................................................. 53
FIGURA 5.15 CRIAO DE ARRAYS DE DADOS. ....................................................................................... 53
FIGURA 5.16 ANLISE DE ESTABILIDADE DOS DADOS [INM97]............................................................. 54
FIGURA 5.17 COMPONENTES DE UM INSTANTNEO [INM97]. ............................................................... 55
FIGURA 6.1 A TABELA DE FATOS E SUAS DIMENSES NO MODELO ESTRELA [CAM97]. .......................... 60
FIGURA 6.2 A FALTA DE INTEGRAO DOS DADOS DE DIFERENTES APLICAES. ................................... 61
FIGURA 6.3 INTEGRAO DE DADOS COM AS MESMAS INFORMAES. ................................................. 62
FIGURA 6.4 TCNICAS DE GERENCIAMENTO DA QUANTIDADE DE DADOS PESQUISADOS [INM97]. .......... 64
FIGURA 6.5 INTRODUO INTENCIONAL DE DADOS REDUNDANTES [INM97]. ........................................ 65
FIGURA 6.6 TCNICA DE SEPARAO DOS DADOS CONFORME A PROBABILIDADE DE ACESSOS. ............... 66
FIGURA 6.7 DATA MARTS DEPARTAMENTAIS. ........................................................................................ 67
FIGURA 8.1 ACESSO DIRETO AOS DADOS DO DW.................................................................................. 75
FIGURA 8.2 ACESSO INDIRETO AOS DADOS DO DW. ............................................................................. 76
FIGURA 8.3 MODELO DE BDM DE TRS DIMENSES. ............................................................................ 80
FIGURA 8.4 TELA DA FERRAMENTA POWERPLAY MOSTRANDO GRFICOS E DADOS [UNI98]. ................. 84
FIGURA 8.5 TELA DA FERRAMENTA MAESTRO. .................................................................................... 86
FIGURA 8.6 TELA DA FERRAMENTA ORACLE DISCOVERER [ORA98]. ................................................... 88
Lista de Tabelas
TABELA 2.1 COMPARAO ENTRE BANCO DE DADOS OPERACIONAIS E DATA WAREHOUSE. ................... 13
TABELA 3.1 CONJUNTO DE CARACTERSTICA DA QUALIDADE DE DADOS. .............................................. 19
TABELA 6.1 FUNES EM UM DATA WAREHOUSE [BAR96]. .................................................................. 57
TABELA 7.1 FERRAMENTAS PARA EXTRAO, TRANSFORMAO E MIGRAO DE DADOS [ORL96]. ...... 74
TABELA 8.1 AS DOZES REGRAS PARA OLAP SEGUNDO CODD [COD95]. ............................................... 78
TABELA 8.2 PRODUTOS DA FAMLIA ORACLE EXPRESS PARA DW [ORA98].......................................... 87
Resumo
O ambiente de dados para suporte aos processos de gerncia e tomada de deciso

fundamentalmente diferente do ambiente convencional de processamento de
transaes. No corao deste ambiente est a idia do Data Warehouse, integrando e
consolidando dados disponveis em diferentes acervos para fins de explorao e anlise,
ampliando o contedo informacional destes acervos para atender s expectativas e
necessidades de nvel estratgico na empresa. Este trabalho tem por objetivo apresentar
os principais conceitos da tecnologia de Data Warehouse (DW), entre estes pode-se
destacar as caractersticas dos dados em um DW, as principais arquiteturas, os modelos
envolvidos no processo de desenvolvimento de um DW, as atividades que devem ser
realizadas durante o desenvolvimento de um DW, o povoamento do DW e a extrao de
informaes teis.
Abstract
The database environment supporting management and decision support systems

is essentially different from the conventional database environment of transaction
processing. Central to that environment is the Data Warehouse concept, integrating data
from different sources to fulfill the strategic information requirements of companies.
This work presents the main issues of Data Warehouse (DW) technology, among that
we present the data features of a DW, the main architectures, the models involved in
development process of a DW, the task that must be done in the DW development, the
population of a DW and the extraction of useful knowledge.
10
1 Introduo
Com a evoluo da tecnologia de informao e o crescimento do uso de
computadores interconectados, praticamente todas as empresas de mdio e grande porte
esto utilizando sistemas informatizados para realizar seus processos mais importantes,
o que com o passar do tempo acaba gerando uma enorme quantidade de dados
relacionados aos negcios, mas no relacionados entre si. Estes dados armazenados em
um ou mais sistemas operacionais1 de uma empresa so um recurso, mas de modo geral,
raramente servem como recurso estratgico no seu estado original. Os sistemas
convencionais de informtica no so projetados para gerar e armazenar as informaes
estratgicas, o que torna os dados vagos e sem valor para o apoio ao processo de
tomada de decises das organizaes. Estas decises normalmente so tomadas com
base na experincia dos administradores, quando poderiam tambm ser baseadas em
fatos histricos que foram armazenados pelos diversos sistemas de informao
utilizados pelas organizaes.
Em termos simples, um Data Warehouse, ou em portugus, Armazm de Dados,
pode ser definido como um banco de dados especializado, o qual integra e gerencia o
fluxo de informaes a partir dos bancos de dados corporativos e fontes de dados
externas2 empresa. Um Data Warehouse construdo para que tais dados possam ser
armazenados e acessados de forma que no sejam limitados por tabelas e linhas
estritamente relacionais. A funo do Data Warehouse (DW) tornar as informaes
corporativas acessveis para o seu entendimento, gerenciamento e uso. Como o DW est
separado dos bancos de dados operacionais, as consultas dos usurios no impactam
nestes sistemas, que ficam resguardados de alteraes indevidas ou perdas de dados. O
DW no como um software, que pode ser comprado e instalado em todos os
computadores da empresa em algumas horas, na realidade sua implantao exige a
integrao de vrios produtos e processos.
Um DW oferece os fundamentos e os recursos necessrios para um Sistema de
Apoio a Deciso (SAD) eficiente, fornecendo dados integrados e histricos que servem
desde a alta direo, que necessita de informaes mais resumidas, at as gerncias de
baixo nvel, onde os dados detalhados ajudam a observar aspectos mais tticos da
empresa. Nele, os executivos podem obter de modo imediato respostas para perguntas
que normalmente no possuem respostas em seus sistemas operacionais e, com isso,
tomar decises com base em fatos, no com intuies ou especulaes.
Com o surgimento do DW so necessrios novos mtodos de estruturao de
dados e novas tecnologias, tanto para armazenamento, como para recuperao de
informaes. A necessidade destes novos mtodos e tecnologias, surgiu da constatao,
primeiro de que existe uma necessidade de informao no atendida pelos aplicativos
comerciais convencionais, que atuam a nvel operacional do negcio, e segundo, pelo
fato de que a tecnologia de armazenamento de dados utilizada nestes aplicativos no
atende s necessidades detectadas. Graas aos avanos nos bancos de dados relacionais,
A expresso sistemas operacionais, neste trabalho, sempre se referir aos sistemas transacionais de
uma empresa, utilizados para controlar suas operaes dirias, como compras, vendas, estoques, etc.
2
A expresso fontes de dados externas, neste trabalho, ser utilizada para definir informaes que no
esto associadas aos sistemas da empresa. Por exemplo: arquivos textos, imagens, sons, planilhas de
clculos, etc.
11
no processamento paralelo e na tecnologia distribuda, finalmente a tecnologia da

informao pode permitir que qualquer organizao elabore um Data Warehouse.
Como as empresas demoram vrios anos para gerar e armazenar um volume
considervel de informaes, normal que estes dados estejam espalhados por diversos
locais e que tenham sido gerados por sistemas desenvolvidos em diferentes ambientes e
linguagens. Um dos desafios da implantao de um DW justamente a integrao
destes dados, eliminando as redundncias e identificando informaes iguais que
possam estar representadas sob formatos diferentes em sistemas distintos.
Estudar e conhecer a tecnologia de DW pode ajudar os empresrios a descobrir
novas formas de competir em uma economia globalizada, trazendo melhores produtos
ou servios para o mercado, mais rpido do que os concorrentes, sem aumentar o custo
do produto ou do servio. No existem ainda metodologias formais para implementao
de um DW, ela deve ser adaptada s caractersticas e s expectativas de cada empresa,
mas o principal objetivo em todas elas o de descobrir maneiras diferentes de atuar no
mercado e quais as mudanas internas que devem ocorrer para atender as novas
realidades.
Este trabalho tem como objetivo fazer um estudo dos principais conceitos
necessrios para o desenvolvimento de um ambiente de DW. No captulo 2 so
apresentados alguns conceitos encontrados na literatura sobre o termo Data Warehouse.
No captulo 3 so apresentadas as principais caractersticas dos dados que sero
mantidos em um DW. O captulo 4 apresenta uma arquitetura genrica para um
ambiente de suporte a tomada de decises com o uso de Data Warehouse; alm dessa
so apresentadas algumas propostas simplificadas de arquiteturas e os principais
componentes de software que um Data Warehouse deve possuir.
Uma questo muito importante no planejamento e desenvolvimento de um Data
Warehouse a definio dos diversos modelos de dados que daro suporte e orientao
ao trabalho do ambiente do DW. No captulo 5, so descritas duas metodologias de
modelagem de dados para Data Warehouse conforme R.Kimball [KIM96] e
W.H.Inmon [INM93], ambas apresentam trs nveis de modelagem para os dados: alto
nvel (empresarial); intermedirio (dimensional); e baixo nvel (fsico).
Depois de definir-se os modelos de dados do DW, deve-se definir algumas
estratgias que orientaro o desenvolvimento do DW, estas orientaes so apresentadas
no captulo 6. Aps, pode-se efetivamente utilizar as ferramentas de DW, as quais
podem ser divididas em dois grupos ferramentas de povoao (aquelas que extraem
dados dos sistemas operacionais da empresa) e ferramentas de consulta (aquelas que
realizam consultas sobre o DW. Os captulos 7 e 8 tratam respectivamente da povoao
e da extrao dos dados que faro parte do DW.
No captulo 9 so apresentadas algumas vantagens e desvantagens da utilizao
de um DW em uma organizao. Por fim, no captulo 10 so apresentadas algumas
concluses e sugestes de trabalhos futuros.
12
2 Conceitos
Na atual bibliografia podem ser encontrados muitos conceitos sobre DW como
os apresentados a seguir:
Segundo Inmon [INM97a], que tido como o pai do conceito, Data
Warehouse uma coleo de dados orientados por assuntos, integrados,
variveis com o tempo e no volteis, para dar suporte ao processo gerencial de
tomada de deciso;
Data Warehouse um processo em andamento que aglutina dados de fontes
heterogneas, incluindo dados histricos e dados externos para atender
necessidade de consultas estruturadas e ad-hoc, relatrios analticos e de suporte
a deciso, conforme Harjinder [HAR96];
Segundo Barquini [BAR96], Data Warehouse uma coleo de tcnicas e
tecnologias que juntas disponibilizam um enfoque pragmtico e sistemtico para
tratar com o problema do usurio final de acessar informaes que esto
distribudas em vrios sistemas da organizao,
Para entender o que um DW, importante fazer uma comparao com o
conceito tradicional de banco de dados. Conforme [BAT86], "Um banco de dados
uma coleo de dados operacionais armazenados e utilizados pelo sistema de aplicaes
de uma empresa especfica". Os dados mantidos por uma empresas so chamados de
"operacionais" ou "primitivos". Batini em [BAT86] refere-se aos dados no banco de
dados como "dados operacionais", distinguindo-se de dados de entrada, dados de sada
e outros tipos de dados.
Levando em considerao esta definio sobre dados operacionais, pode-se dizer
que um DW , na verdade, uma coleo de dados derivados dos dados operacionais para
sistemas de suporte deciso. Estes dados derivados so, muitas vezes, referidos como
dados "gerenciais", "informacionais" ou "analticos" [INM96].
Os bancos de dados operacionais armazenam as informaes necessrias para as
operaes dirias da empresa, so utilizados por todos os funcionrios para registrar e
executar operaes pr-definidas, por isso seus dados podem sofrer constantes
mudanas conforme as necessidades atuais da empresa. Por no ocorrer redundncia nos
dados e as informaes histricas no ficarem armazenadas por muito tempo, este tipo
de BD no exige grande capacidade de armazenamento.
J um DW armazena dados analticos, destinados s necessidades da gerncia
no processo de tomada de decises. Isto pode envolver consultas complexas que
necessitam acessar um grande nmero de registros, por isso importante a existncia de
muitos ndices criados para acessar as informaes da maneira mais rpida possvel. Um
DW armazena informaes histricas de muitos anos e por isso deve ter uma grande
capacidade de processamento e armazenamento dos dados que se encontram de duas
maneiras, detalhados e resumidos.
Na Tabela 2.1 esto relacionadas algumas diferenas entre bancos de dados
operacionais e DW bem como as diferenas dos dados que eles manipulam segundo os
seguinte autores: [INM96] [BAR96] [KIM96] [ONE97].
13
Objetivo
Uso
Tipo de processamento
Unidade de trabalho
Nmero de usurios
Tipo de usurio
Interao do usurio
Bancos de dados
Operacionais
Operaes dirias do negcio
Operacional
OLTP
Incluso, alterao, excluso
Milhares
Operadores
Somente pr-definida
Analisar o negcio
Informativo
OLAP
Carga e consulta
Centenas
Comunidade gerencial
Pr-definida e ad-hoc
Condies dos dados

Volume
Histrico
Granularidade
Redundncia
Dados operacionais
Megabytes gigabytes
60 a 90 dias
Detalhados
No ocorre
Dados Analticos
Gigabytes terabytes
5 a 10 anos
Detalhados e resumidos
Ocorre
Estrutura
Manuteno desejada
Acesso a registros
Atualizao
Integridade
Nmero de ndices
Inteno dos ndices
Esttica
Mnima
Dezenas
Contnua (tempo real)
Transao
Poucos/simples
Localizar um registro
Varivel
Constante
Milhares
Peridica (em batch)
A cada atualizao
Muitos/complexos
Aperfeioar consultas
Caractersticas
Data Warehouse
Tabela 2.1 Comparao entre Banco de Dados Operacionais e Data Warehouse.

Com base nestes conceitos podemos concluir que o DW no um fim, mas sim
um meio que as empresas dispem para analisar informaes histricas podendo utilizlas para a melhoria dos processos atuais e futuros. DW so resumos de dados retirados
de mltiplos sistemas de computao normalmente utilizados a vrios anos e que
continuam em operao. DW so construdos para que tais dados possam ser
armazenados e acessados de forma que no sejam limitados por tabelas e linhas
estritamente relacionais. Os dados de um DW podem ser compostos por um ou mais
sistemas distintos e sempre estaro separados de qualquer outro sistema transacional, ou
seja, deve existir um local fsico onde os dados desses sistemas sero armazenados, a
Figura 2.1 ilustra os principais componentes de um DW, mostrando que entre as fontes
de dados e os acessos a estes dados est o DW. Antes deste deslocamento, sempre
haver a aplicao de tcnicas de filtragem, agrupamento e/ou refinamento dos dados.
14
Figura 2.1 Componente de um Data Warehouse.
15
3 Caractersticas do Data Warehouse

Os dados de um DW devem ser classificados por assunto, alm disso
importante que se faa a integrao (normalizao) de representao para facilitar as
consultas, tambm deve-se definir a granularidade temporal da informao e a forma de
armazenar os dados, ter conscincia de que dados em um DW no so modificados pois
representam as informaes em um determinado instante de tempo e podem estar
fisicamente armazenados de diferentes formas. Essas so as principais caractersticas do
DW, as quais so apresentadas no conceito do W.H.Inmon [INM97] e sero detalhadas
a seguir.
3.1 Orientao por assunto

Um DW sempre armazena dados importantes sobre temas especficos da
empresa e conforme o interesse das pessoas que iro utiliz-lo. Uma empresa pode
trabalhar com vendas de produtos alimentcios no varejo e o seu maior interesse ser o
perfil de seus compradores, ento o DW ser voltado para as pessoas que compram seus
produtos e no para os produtos que ela vende.
Portanto, ao se construir um DW deve-se discutir com o usurio quais os seus
objetivos, definir as informaes relevantes para o processo de anlise, alm de se
preocupar com os tipos de anlise que sero realizadas sobre os dados do DW.
3.2 Integrao
Esta a caracterstica mais importante do DW, pois ela quem ir definir a
representao nica para os dados provenientes dos diversos sistemas que formaro a
base de dados do DW. A maior parte do trabalho na construo de um DW est na
anlise dos sistemas operacionais e dos dados que eles contm. Como no existem
padres de codificao, cada analista pode definir a mesma estrutura de dados de vrias
formas, fazendo com que dados que representam a mesma informao sejam
representados de diversas maneiras dentro dos sistemas utilizados pela empresa ao
longo dos anos.
Um exemplo clssico deste problema a representao do sexo, em um sistema
pode-se definir um campo de uma posio alfanumrica, onde M signifique masculino e
F feminino, em outro a mesma informao pode ser representada por 1 e 2 ou por H
para homem e M para mulher e assim por diante. Com a integrao dos dados este
problema desaparece, conforme ilustra a Figura 3.1, pois deve ser adotada uma nica
representao para esta informao.
Ambiente operacional
Aplicao A M, F
Aplicao B H, M
Aplicao C 0, 1
Figura 3.1 Integrao dos dados.
Data warehouse
M, F
16
3.3 Variao no tempo

Segundo W.H.Inmon [INM97] todos os dados no DW so precisos em algum
instante no tempo, como eles podem estar corretos somente em um determinado
momento, dito que esses dados variam com o tempo.
A variao no tempo pode apresentar-se de trs maneiras:
Em um DW normal que as informaes sejam representadas em horizontes
de tempo maiores de cinco anos chegando at o limite da idade dos dados ou em
um perodo considerado satisfatrio conforme a sua aplicao. Nas aplicaes
operacionais o perodo de tempo muito mais curto, variando entre sessenta e
noventa dias, pois necessrio um resposta rpida s exigncias das tarefas
dirias o que s pode ser conseguido com o processamento de poucos dados;
Assim como os dados, os metadados, que incluem definies dos itens de
dados, rotinas de validao, algoritmos de derivao, etc. tambm possuem
elementos temporais para que com eventuais mudanas nas regras do negcio a
empresa no perca dados histricos;
Os dados armazenados corretamente no DW no sero mais atualizados
tendo-se assim uma imagem fiel da poca em que foram gerados.
Os dados ainda podem ser separados em duas categorias, a de dados atuais e de
dados antigos. Os dados detalhados atuais so os dados de maior interesse por refletir os
acontecimentos mais recentes, so em grande volume porque so armazenados no nvel
mais baixo de granularidade e devem ficar armazenados em disco, um meio de acesso
rpido mas de difcil gerenciamento. Os dados detalhados atuais fornecem uma viso do
comportamento recente e podem permitir a utilizao de tcnicas como minerao de
dados e descoberta de conhecimento. O horizonte de tempo, para esses dados,
normalmente de dois anos.
Os dados detalhados antigos so aqueles que no so acessados freqentemente
e por isso normalmente ficam armazenados em meios de armazenamento de baixo custo
pois possuem um grande volume por ficarem em um nvel de detalhe consistente com
os dados detalhados atuais. Mesmo no ficando armazenados em outros meios, como
fitas por exemplo, eles continuam fazendo parte do DW e podem ser carregados sempre
que surgir necessidade de extrair informaes.
Uma definio que deve ser feita sobre o perodo de atualizao dos dados que
se refere ao tempo necessrio para que uma alterao sobre dados do ambiente
operacional reflita no DW. Um vez que os dados tenham sido refletidos no ambiente
operacional, as alteraes precisam ser passadas para o DW, o problema definir de
quanto em quanto tempo isto deve ocorrer. Inmon [INM97] sugere que pelo menos 24
horas devem se passar entre o momento em que a alterao observada pelo ambiente
operacional e sua repercusso no DW.
Existem algumas razes para a existncia deste intervalo, a primeira delas
consiste no fato de que quanto mais rigidamente o ambiente operacional for
emparelhado com o DW, mais dispendiosa e complexa ser a tecnologia necessria. A
segunda que este intervalo de tempo possibilita a estabilizao dos dados, diminuindo
a chance de o DW receber informaes incorretas.
17
3.4 No volatilidade
Em um DW no existem alteraes de dados, somente a carga inicial e as
consultas posteriores. Ele definido assim pois as operaes a nvel de registro em
modo on-line como so os sistemas transacionais, exigem um controle e um
processamento muito grande, fugindo do objetivo principal do DW. Segundo
W.H.Inmon[INM97] dizer que existe redundncia de dados entre os sistemas
transacionais e o DW demonstra a falta de conhecimento de como as coisas acontecem
no DW.
Deve-se considerar que os dados passam por filtros antes de entrar no DW, com
isso muitos dados nunca passam do ambiente transacional e outros so resumidos de
certa forma que no so encontrados fora do DW. Em outras palavras, a maior parte
dos dados fsica e radicalmente alterada quando passam a fazer parte do DW. Do
ponto de vista de integrao, no so mais os mesmos dados do ambiente operacional.
luz destes fatores, a redundncia de dados entre os dois ambientes raramente ocorre,
resultando em menos de 1 por cento de duplicaes.[INM97].
3.5 Localizao
Os dados podem estar fisicamente armazenados de trs formas[CAM97]:
Armazenados em um nico local centralizando o banco de dados em um DW
integrado, procurando maximizar o poder de processamento e agilizando a busca
dos dados;
Distribudos por reas de interesse, o que pode ser chamado de arquitetura
federativa, com dados financeiros em um servidor, dados de marketing em outro
e dados de manufatura em um terceiro lugar;
Armazenados por nveis de detalhes em que as unidades de dados so
mantidas no DW. Pode-se armazenar dados altamente resumidos em um
servidor, dados resumidos em um nvel de detalhe intermedirio em um segundo
servidor e os dados mais detalhados (atmicos) em um terceiro servidor. Os
servidores da primeira camada podem ser otimizados para suportar um grande
nmero de acessos e um baixo volume de dados enquanto servidores nas outras
camadas podem ser adequados para processar grandes volumes de dados mas
baixo nmero de acessos.
Um DW pode possuir diferentes nveis de dados, que podem estar agrupados
por idade, sintetizao ou detalhe. A forma geral de localizao dos dados em um DW
mostrada na Figura 3.2. Os componentes da estrutura so divididos em:
Dados detalhados atuais
Dados detalhados antigos
Dados levemente resumidos
Dados altamente resumidos
Metadados
18
Dados altamente
resumidos
M
E
T
A
D
A
D
O
S
Dados levemente
resumidos
Dados detalhados
atuais
Dados detalhados
antigos
Figura 3.2 Forma geral da localizao dos dados em um DW.

Para mudar de nvel necessrio que ocorra um dos seguinte eventos: os dados
so sintetizados, arquivados ou eliminados.
O processo de sintetizao interage no nvel mais alto de detalhamento (dados
detalhados atuais) para os nveis seguintes (levemente e altamente resumidos). Quando
termina determinado perodo de tempo (semana, ms, trimestre, ano), os dados so
indexados por estes perodos e armazenados nos seus respectivos nveis de
detalhamento. Para facilitar o acesso aos dados estes devem estar sintetizados e
indexados de vrias maneiras, portanto ao mesmo tempo que ocorre o agrupamento por
datas tambm pode ocorrer a sintetizao por grupos e subgrupos.
Cada nvel possui um horizonte de tempo definido para a permanncia dos
dados, ento o fato dos dados serem transportados para nveis mais elevados no
implica na sua excluso do nvel anterior. Um processo denominado processo de
envelhecimento ocorre quando este limite ultrapassado e ento os dados podem ser
transferidos para meios de armazenamentos alternativos ou passar de dados detalhados
atuais para dados detalhados antigos.
3.6 Credibilidade do dados

A credibilidade dos dados o mais importante para o sucesso de qualquer
projeto. Discrepncias simples de todo tipo podem causar srios problemas quando se
quer extrair dados para suportar decises estratgicas para o negcio das empresas.
Dados no dignos de confiana podem resultar em relatrio inteis, que no tm
importncia alguma, como uma lista de pacientes do sexo masculino e grvidos, por
19
exemplo. "Se voc tem dados de m qualidade e os disponibiliza em um DW, o seu

resultado final ser um suporte a deciso de baixo nvel com altos riscos para o seu
negcio", afirma Robert Craig [IDG98], analista do Hurwitz Group.
Coisas aparentemente simples, como um CEP errado, podem no ter nenhum
impacto em uma transao de compra e venda, mas podem influir nas informaes
referentes a cobertura geogrfica, por exemplo. "No apenas a escolha da ferramenta
certa que influi na qualidade dos dados", afirma Richard Rist [IDG98], vice-presidente
Data Warehousing Institute. Segundo ele, conjuntos de colees de dados, processos de
entrada, metadados e informaes sobre a origem dos dados, so de muita importncia.
Outras questes como a manuteno e atualizao dos dados e as diferenas entre dados
para bancos transacionais e para uso em Data Warehousing tambm so crucias para o
sucesso dos projetos. Alm das camadas do DW propriamente dito, tem-se a camada
dos dados operacionais, de onde os dados mais detalhados so coletados. Antes de fazer
parte do DW estes dados passam por diversos processos de transformao para fins de
integrao, consistncia e acuracidade.
A Tabela 3.1 descreve um conjunto das caractersticas normalmente utilizadas
para verificar a qualidade dos dados e indica algumas maneiras de medir o nvel da
qualidade dos dados do DW. Nem todas as caractersticas da Tabela 3.1 precisam
necessariamente ser averiguadas, deve-se escolher as que representam maior fator de
risco para o ambiente proposto e trabalhar em cima destas caractersticas.
Caracterstica da qualidade
de dados
Descrio
Exemplo de medida
Preciso
Grau de informaes que Percentual de correo.

esto corretas.
Abrangncia
Grau de dados requisitados e Percentual atendimentos.

atendidos.
Consistncia
Consistncia dos dados /

liberdade de contradio.
Coerncia
Coerncia lgica que permite Percentual de regras de

criar relaes entre os dados. integridade referencial
suportadas.
Tempo de resposta
Tempo entre o pedido de Relao entre a

consulta e a resposta.
complexidade e o tempo
gasto para resposta.
Singularidade
Singularidade dos dados de Percentual dos dados que

mesma natureza.
tm valores dentro dos
domnios de valores
permitidos.
Percentual de condies
satisfeitas.
Tabela 3.1 Conjunto de caracterstica da qualidade de dados.
20
3.7 Granularidade
Granularidade diz respeito ao nvel de detalhe ou de resumo contido nas
unidades de dados existentes no DW. Quanto maior o nvel de detalhes, menor o nvel
de granularidade. O nvel de granularidade afeta diretamente o volume de dados
armazenado no DW e ao mesmo tempo o tipo de consulta que pode ser respondida.
Quando se tem um nvel de granularidade muito alto o espao em disco e o
nmero de ndices necessrios se tornam bem menores, porm h uma correspondente
diminuio da possibilidade de utilizao dos dados para atender a consultas detalhadas.
A Figura 3.3 exemplifica o conceito acima utilizando os dados histricos das
vendas de um produto, um nvel de granularidade muito baixo pode ser caracterizado
pelo armazenamento de cada uma das vendas ocorridas para este produto e um nvel
muito alto de granularidade seria o armazenamento do somatrios das vendas ocorridas
por ms.
Nveis de Granularidade
Baixa
Produto Data
A1 13/9/98
B1 14/9/98
A1 16/9/98
A1 16/9/98
........
Qtd.
10
15
20
90
Alta
Valor
100,00
150,00
200,00
890,00
Ms/Ano
09/98
09/98
Produto Qtd.
Valor
A1
120 1190,00
B1
15
150,00
Figura 3.3 Nveis de granularidade.

Com um nvel de granularidade muito baixo, possvel responder a
praticamente qualquer consulta, mas uma grande quantidade de recursos
computacionais necessria para responder perguntas muito especficas. No entanto, no
ambiente de DW, dificilmente um evento isolado examinado, mais comum ocorrer a
utilizao de uma viso de conjunto dos dados.
Os dados levemente resumidos compreendem um nvel intermedirio na
estrutura do DW, so derivados do detalhe de baixo nvel encontrado nos dados
detalhados atuais. Este nvel do DW quase sempre armazenado em disco. Na
passagem para este nvel os dados sofrem modificaes, por exemplo, se as informaes
nos dados detalhados atuais so armazenadas por dia, nos dados levemente resumidos
estas informaes podem estar armazenadas por semanas. Neste nvel o horizonte de
tempo de armazenamento normalmente fica em cinco anos e aps este tempo os dados
sofrem um processo de envelhecimento e podem passar para um meio de
armazenamento alternativo.
21
Os dados altamente resumidos so compactos e devem ser de fcil acesso, pois

fornecem informaes estatsticas valiosas para os Sistemas de Informaes Executivas,
enquanto que nos nveis anteriores ficam as informaes destinadas aos Sistemas de
Apoio a Deciso (SAD) que trabalham com dados mais analticos procurando analisar
as informaes de forma mais ampla.
O balanceamento do nvel de granularidade um dos aspectos mais crticos no
planejamento de uma DW, pois na maior parte do tempo, h uma grande demanda por
eficincia no armazenamento e no acesso aos dados, bem como pela possibilidade de
analisar dados em maior nvel de detalhes. Quando uma organizao possui grandes
quantidades de dados no DW, faz sentido pensar em dois ou mais nveis de
granularidade na parte detalhada dos dados. Na realidade, a necessidade de existncia de
mais de um nvel de granularidade to grande que a opo de projeto que consiste em
duplos nveis de granularidade deveria ser o padro para quase todas as empresas.
O chamado nvel duplo de granularidade, ilustrado na Figura 3.4, se enquadra
nos requisitos da maioria das empresas. Na primeira camada de dados ficam os dados
que fluem do armazenamento operacional e so resumidos na forma de campos
apropriados para a utilizao de analistas e gerentes. Na segunda camada, ou nvel de
dados histricos, ficam todos os detalhes vindos do ambiente operacional, como h uma
verdadeira montanha de dados neste nvel, faz sentido armazenar os dados em um meio
alternativo como fitas magnticas.
Com a criao de dois nveis de granularidade no nvel detalhado do DW,
possvel atender a todos os tipos de consultas, pois a maior parte do processamento
analtico dirige-se aos dados levemente resumidos que so compactos e de fcil acesso e
para ocasies em que um maior nvel de detalhe deve ser investigado existe o nvel de
dados histricos. O acesso aos dados do nvel histrico de granularidade caro,
incmodo e complexo, mas caso haja necessidade de alcanar esse nvel de detalhe, l
estar ele.
Dados
Resumidos
Primeira
Camada
Primeira Camada
Dados resumidos por produto
Produto A1 maio/1998
Valor total: R$ 1.270,00
Quantidade total: 254
Valor mdio: R$ 5,00
Segunda
camada
Segunda Camada
Dados detalhados por produto
Produto A1
02/5/1998- Valor R$ 100,00 Quantidade 20
.........
Figura 3.4 Nveis duplos de granularidade para dados resumidos.
22
3.8 Os metadados
Metadados so normalmente definidos como dados sobre os dados. Podem ser
definidos tambm como um abstrao dos dados, ou dados de mais alto nvel que
descrevem dados de um nvel inferior. Os metadados tm um papel muito importante na
administrao de dados, mas no DW podem ser considerados de suma importncia pois
a partir deles que as informaes sero processadas, atualizadas e consultadas.
Como os usurios de DW procuram por fatos no usuais e relaes no
conhecidas previamente eles precisam examinar os dados e para isso necessitam
conhecer a estrutura e o significado dos dados do DW, o que no ocorre em um
ambiente operacional onde os usurios trabalham com aplicaes que contm as
definies de dados embutidas e simplesmente interagem com as telas do sistema sem
precisar conhecer como os dados so mantidos pelo banco de dados.
Geralmente os metadados em um DW podem ser apresentados em trs camadas
diferentes:
Metadados operacionais: definem a estrutura dos dados mantidos pelos
bancos operacionais, usados pelas aplicaes de produo da empresa;
Metadados centrais do DW: so orientados por assunto e definem como os
dados transformados devem ser interpretados, incluem definies de agregao e
campos calculados, assim como vises sobre cruzamentos de assuntos;
Metadados do nvel do usurio: organizam os metadados do DW para
conceitos que sejam familiares e adequados aos usurios finais;
Os metadados podem ser classificados conforme a classe de seus componentes:
Mapeamento: descrevem como os dados de sistemas operacionais so
transformados antes de entrarem no DW. Exemplos desta classe de metadados
podem ser os que identificam campos fontes, mapeamentos entre atributos,
converses, codificaes, padres, etc.;
Histrico: com a evoluo dos sistemas operacionais as regras de negcio da
empresa podem mudar, cabe a estes metadados manter o histrico de
mudanas destas regras, pois as regras certas devem ser aplicadas aos dados
certos;
Miscelnea: esta classe define diversos tipos de metadados, informaes da
situao de desenvolvimento de partes do DW, informaes sobre volume dos
dados para estimativas de tempo e recursos, etc.;
Algoritmos de sumarizao: mostram a relao entre os diferentes nveis
de detalhes dos dados, indicando inclusive que nvel de sumarizao mais
adequado para um dado objetivo;
Padres de acesso: mantm informaes sobre freqncia e tipo de acesso
aos dados.
Conforme visto acima os dados sobre desempenho e monitoramento tambm so
qualificados com metadados, eles podem ser criados por processos que monitoram
atividades como extrao, carga e uso dos dados. Dados que identificam questes
23
relativas a qualidade dos dados tambm devem estar disponveis para os usurios, afim
de que estes identifiquem a acuracidade de suas anlises.
Segundo Inmon[INM97] os metadados englobam o DW e mantm informaes
sobre o que est aonde no DW. Tipicamente os aspectos sobre os quais os metadados
mantm informaes so:
A estrutura dos dados segundo a viso do programador;
A estrutura dos dados segundo a viso dos analista de SAD;
A fonte de dados que alimenta o DW;
A transformao sofrida pelos dados no momento de sua migrao para o DW;
O modelo de dados;
O relacionamento entre o modelo de dados e o DW;
O histrico das extraes de dados.
3.8.1 Fontes de metadados

Os metadados podem ser encontrados em vrios locais durante o
desenvolvimento de um DW. Em [ADE97] alguns tipos de metadados so classificados
conforme suas fontes, essas fontes e o tipo de metadados que pode ser obtido atravs
delas so:
Repositrios de ferramentas CASE: Normalmente os dados contidos em
ferramentas CASE so estruturados o que facilita a integrao automtica entre a
origem dos metadados e o repositrio do ambiente de DW. Pode-se extrair informaes
sobre a origem dos dados, o fluxo dos dados (os processos que utilizam e transportam
os dados), o formato dos dados e as definies de negcios.
Documentao do desenvolvimento dos sistemas operacionais: O tipo de
metadados potencialmente disponvel idntico ao item acima. A diferena que
normalmente a documentao de desenvolvimento dos sistemas no est estruturada o
que pode dificultar o entendimento das origens e fluxos dos dados.
Cdigo fonte dos sistemas operacionais: Quando no existe uma
documentao eficiente dos sistemas operacionais, possvel extrair as informaes
sobre eles atravs dos programas fontes. Como vasculhar todos os programas de um ou
vrios sistemas operacionais a procura de regras um trabalho demorado e oneroso
possvel simplesmente utiliz-los como forma de esclarecer dvidas que a
documentao no contempla, tambm cobre os mesmos tipos de informaes das
fontes anteriores.
Entrevistas: Apesar de no ser uma fonte estruturada de informaes,
entrevistar profissionais da empresa que entendam do negcio, como gerentes e
analistas, de vital importncia. Destas entrevistas pode se obter regras e informaes
que no esto explcitas na documentao dos sistemas como, requisitos para teste dos
dados e indicadores de qualidade dos dados.
O prprio ambiente do DW: Informaes tais como freqncia de acesso s
informaes, em que nvel de agregao, tempo de resposta de cada consulta, auditoria
24
de acesso de informaes por usurios, so informaes interessantes de se manter, que

podem ser geradas pelo prprio sistema ao longo de sua utilizao, podendo ser usadas,
dentre outros propsitos, para a criao de estruturas de metadados.
25
4 Arquitetura do Data Warehouse

Para ser til o DW deve ser capaz de responder a consultas avanadas de
maneira rpida, sem deixar de mostrar detalhes relevantes resposta. Para isso ele deve
possuir uma arquitetura que lhe permita coletar, manipular e apresentar os dados de
forma eficiente e rpida. Mas construir um DW eficiente, que servir de suporte a
decises para a empresa, exige mais do que simplesmente descarregar ou copiar os
dados dos sistemas atuais para um banco de dados maior. Deve-se considerar que os
dados provenientes de vrios sistemas podem conter redundncias e diferenas, ento
antes de pass-los para o DW necessrio aplicar filtros sobre eles.
O estudo de uma arquitetura permite compreender como o DW faz para
armazenar, integrar, comunicar, processar e apresentar os dados que os usurios
utilizaro em suas decises. Um DW pode variar sua arquitetura conforme o tipo de
assunto abordado, primeira caracterstica definida no captulo anterior, pois as
necessidades tambm variam de empresa para empresa. possvel definir uma
arquitetura genrica onde praticamente todas as camadas necessrias so apresentadas,
conforme a arquitetura genrica vista a seguir, ou arquiteturas que utilizam somente
algumas das camadas definidas como as arquiteturas em duas e trs camadas e a
arquitetura segundo valente, por fim, pode-se definir uma arquitetura baseada na origem
dos dados e no fluxo que eles seguem pelo DW, como a arquitetura definidas por
Chaudhuri.
4.1 Arquitetura Genrica de Data Warehouse

A seguir descrita uma arquitetura genrica proposta por Orr[ORR96] e
ilustrada na Figura 4.1. Esta descrio genrica procura apenas sistematizar papis no
ambiente de DW, permitindo que as diferentes abordagens encontradas no mercado
atualmente possam ser adaptadas a ela, deve-se considerar que esta arquitetura tem o
objetivo de representar a funcionalidade de um DW sendo que vrias camadas propostas
podem ser atendidas por um nico componente de software.
Esta arquitetura composta pela camada dos dados operacionais e outras fontes
de dados que so acessados pela camada de acesso aos dados. As camadas de
gerenciamento de processos, transporte e DW formam o centro da arquitetura e so elas
as responsveis por manter e distribuir os dados. A camada de acesso informao
formada por ferramentas que possibilitam os usurios extrair informaes do DW.
Todas as camadas desta arquitetura interagem com o dicionrio de dados (metadados) e
com o gerenciador de processos.
Camadas de bancos de dados operacionais e fontes externas: composto
pelos dados dos sistemas operacionais das empresas e informaes provenientes
de fontes externas que sero integradas para compor o DW;
Camada de acesso a informao: Envolve o hardware e o software
utilizado para obteno de relatrios, planilhas, grficos e consultas. nesta
camada que os usurios finais interagem com o DW, utilizando ferramentas de
manipulao, anlise e apresentao dos dados, incluindo-se as ferramentas de
data-mining e visualizao.;
26
Camada de acesso aos dados: Esta camada faz a ligao entre as

ferramentas de acesso informao e os bancos de dados operacionais. Esta
camada se comunica com diferentes sistemas de bancos de dados, sistemas de
arquivos e fontes sob diferentes protocolos de comunicao, o que se chama
acesso universal de dados;
Camada de metadados(Dicionrio de dados): Metadados so as
informaes que descrevem os dados utilizados pela empresa, isto envolve
informaes como descries de registros, comandos de criao de tabelas,
diagramas Entidade/Relacionamentos (E-R), dados de um dicionrio de dados,
etc. necessrio que exista uma grande variedade de metadados no ambiente de
DW para que ele mantenha sua funcionalidade e os usurios no precisem se
preocupar onde residem os dados ou a forma com que esto armazenados;
Camada de gerenciamento de processos: a camada responsvel pelo
gerenciamento dos processos que contribuem para manter o DW atualizado e
consistente. Est envolvida com o controle das vrias tarefas que devem ser
realizadas para construir e manter as informaes do dicionrio de dados e do
DW;
Camada de transporte: Esta camada gerencia o transporte de informaes
pelo ambiente de rede. Inclui a coleta de mensagens e transaes e se encarrega
de entreg-las em locais e tempos determinados. Tambm usada para isolar
aplicaes operacionais ou informacionais, do formato real dos dados nas duas
extremidades;
Camada do Data Warehouse: o DW propriamente dito, corresponde aos
dados utilizados para obter informaes. As vezes o DW pode ser simplesmente
uma viso lgica ou virtual dos dados, podendo no envolver o armazenamento
dos mesmos ou armazenar dados operacionais e externos para facilitar seu
acesso e manuseio.
Figura 4.1 Arquitetura do ambiente de DW [ORR96].
27
4.2 Arquitetura segundo Chaudhuri

Alm de conhecer os componentes envolvidos na construo do DW
necessrio compreender os fluxos de dados que ocorrem no sistema. Conforme
[HAC95], "O verdadeiro valor de um sistema de DW no est em apenas colecionar
dados, mas sim, gerenciar fluxos de dados". Chaudhuri [CHA97] prope uma
arquitetura, ilustrada na Figura 4.2, conforme o fluxo e a origem dos dados no sistema
de DW, esta arquitetura pode ser dividida em:
Fontes de dados de onde o DW ir retirar os seus dados de origem;
Um conjunto de estruturas de dados analticos armazenados: o DW do
sistema;
Um Sistema Gerenciador de Banco de Dados (SGBD) otimizado para
atender os requisitos analticos dos sistemas de DW;
Um componente back end: conjunto de aplicaes responsveis por extrair,
filtrar, transformar, integrar e carregar os dados de diferentes origens no DW;
Um componente front end: conjunto de aplicaes responsveis por
disponibilizar aos usurios finais acesso ao DW;
Um repositrio para armazenar e gerenciar os metadados do sistema.
Data Warehouse
(SGBD)
Componente
front-end
Componente
back-end
Repositrio de
metadados
Fontes externas
Fontes internas
Figura 4.2 Componentes de arquitetura de um DW segundo Chaudhuri [MOR98].
28
Cinco principais fluxos fazem parte do sistema: fluxo de entrada (inflow), fluxo
de sada (outflow), fluxo de subida (upflow), fluxo de descida (downflow) e o
metafluxo (metaflow). A Figura 4.3 ilustra como estes cinco diferentes fluxos de dados
esto inseridos dentro de sistema:
Outflow
Componente
front-end
Upflow
Metaflow
Data Warehouse
Inflow
Repositrio de
metadados
Downflow
Componente
back-end
Dados antigos
Fontes internas
Fontes externas
Figura 4.3 O fluxo de dados no sistema [MOR98].

O primeiro fluxo o de entrada dos dados no sistema (inflow), que envolve
extrair, filtrar, transformar, integrar e carregar os dados de vrias fontes no DW. Devese considerar as fontes de dados que pertencem empresa e as fontes externas. O fluxo
de entrada geralmente implementado com ajuda de ferramentas especialmente
desenvolvidas para este fim.
O segundo fluxo o de descida dos dados (downflow), ou seja, em tempos prdeterminados, de dois a cinco anos dependendo da empresa, os dados armazenados no
DW passam para o estado de dados antigos [INM96]. Este o fluxo que remove do DW
aqueles dados considerados velhos, que j no so mais utilizados com freqncia.
O terceiro fluxo o de subida dos dados (upflow), onde enfocada a
necessidade de colocar os dados em formatos mais acessveis aos usurios finais. Este
processo sumariza e agrupa os dados dentro de "vises" mais adequadas aos usurios
finais e as aplicaes front end que eles utilizam, tais como tabelas sumarizadas,
planilhas, grficos, pginas no formato Hyper Text Markup Language (HTML), banco
de dados pessoais, entre outros formatos. Tambm funo do fluxo de subida a
distribuio dos dados para os diferentes nveis do sistema como, por exemplo, Data
Marts e bancos de dados pessoais localizados nas estaes de trabalho dos usurios
finais.
29
O quarto fluxo o de sada dos dados (outflow), cuja funo disponibilizar

acesso aos usurios finais do sistema. Este processo implementado atravs de uma
variedade de ferramentas front end como, por exemplo, geradores de consulta e
relatrio, ferramentas com caractersticas On-line Analytical Processing (OLAP),
pacotes estatsticos, ferramentas de Data Mining, ferramentas de visualizao, Executive
Information System (EIS), Decision Suport Systems (DSS), entre outras. As ferramentas
front end podem acessar tanto dados previamente preparados pelo fluxo de subida,
quanto dados "brutos" e detalhados armazenados no DW.
O quinto e ltimo fluxo pode ser chamado de metafluxo (metaflow), ao
contrrio dos quatro fluxos de dados citados acima, que descrevem como os dados se
movem no DW o metafluxo move metadados, ou seja, dados sobre os outros fluxos. O
repositrio de metadados responsvel pela gerncia do sistema como um todo,
indicando de onde os dados vm, como so transformados, quando so atualizados, o
que significam, como so acessados e quem os v.
4.2.1 Fontes de dados internas

Como regra bsica, a fonte primria dos dados de um DW so os sistemas de
processamento de transaes, os quais do suporte ao dia a dia de uma empresa. Estes
sistemas, tambm chamados de sistemas On-line Transaction Processing (OLTP),
sistemas operacionais e sistemas de produo, tm como principal objetivo garantir
as operaes bsicas das empresas nas reas de produo, administrao e comrcio,
entre outras. Grandes projetos de DW chegam a tratar com mais de quarenta diferentes
sistemas de produo [GEL96]. Todos estes sistemas acabam gerando grandes volumes
de dados, os quais podem estar armazenados e organizados na forma de sistemas de
arquivos, bancos de dados de arquitetura fechada ou aberta e bancos de dados
distribudos.
Alm dos dados referentes s transaes operacionais da empresa, podem ser
necessrios outros dados de fontes internas, geralmente no computadorizados como,
por exemplo, as metas a serem atingidas em determinado ano ou uma pesquisa mensal
que revela o grau de satisfao dos clientes em relao a determinados produtos ou
servios da empresa. Este tipo de informao raramente est disponvel atravs de
atividades normais de processamento de dados, necessitando que seja coletada, inserida
no DW e mantida.
4.2.2 Fontes de dados externas

Outra fonte de dados para um sistema de DW so as fontes externas a empresa,
principalmente como apoio para decises nos nveis gerenciais mais altos. Dentre
alguns exemplos esto informaes econmicas regionais, sobre o setor de atuao da
empresa, sobre concorrentes, preferncias do consumidor, entre outras. Informaes de
fontes externas so geralmente compradas de empresas que mantm bancos de dados
comerciais.
Muitas das informaes podem estar em um formato no tradicional como, por
exemplo, imagens, udio e, principalmente, dados baseados em documentos. O
contedo desses documentos, na medida do possvel, deve ser armazenado
eletronicamente e recuperado de acordo com suas caractersticas.
30
4.3 Arquitetura segundo Valente

Sabendo que nem todas as camadas descritas no modelo de Orr[ORR96] so
necessrias para a implementao de um DW, possvel se definir uma arquitetura mais
simples, conforme um estudo realizado por Valente [VAL96]. Na Figura 4.4 ilustrado
um exemplo de arquitetura bsica, neste exemplo pode-se ver as bases de dados que
compe o DW, logo acima tem-se os extratores que so responsveis pela deteco
automtica de mudanas nas bases de dados. Sempre que existe uma mudana no
contedo da base, a informao nova ou atualizada, que relevante para o DW,
propagada para o integrador.
O integrador responsvel em integrar o contedo fornecido pelos extratores e
fornec-lo ao DW. Para integrar os dados advindos de diversos tipos de bases de dados
necessrio que estes passem por alguns processos. Primeiro, os dados devem ser
ajustados ao modelo de dados conceitual utilizado pelo DW, ento o dado deve ser
unido com os dados j existentes, resolvendo possveis inconsistncias que possam
existir entre as bases de dados e os dados do DW. Uma lista das tarefas do integrador
pode conter itens como: especificar as diferenas das bases de dados, definir
relacionamentos entre dados de mltiplas bases, resolver duplicaes e inconsistncias e
determinar como as informaes sero integradas dentro do DW.
4.3.1 Extrao dos dados

Para que as modificaes nas bases de dados sejam detectadas pelos extratores
necessrio que antes seja feita uma traduo das informaes das bases de dados para o
modelo do DW. Quando alguma modificao de interesse detectada pelos extratores, a
informao propagada em um formato genrico para o integrador. Quando a base dos
dados operacionais um banco de dados relacional possvel definir um conjunto de
gatilhos ou triggers e guardar as notificaes de mudanas. Uma outra maneira que o
extrator examine o arquivo de atualizaes (log) e retire as modificaes que so de
interesse do DW.
Para sistemas que no possuem a facilidade de gatilhos e arquivos de
atualizaes necessrio implementar funes que notifiquem os extratores a cada
mudana na base ou criar um programa para descarregar a base de dados em um arquivo
para que o extrator compare este arquivo com o que foi gerado anteriormente,
detectando assim as modificaes existentes.
Sempre que realizada a carga de novos dados no DW necessrio que estes
passem por um processo de limpeza, descartando dados errados, inserindo dados em
formato padro, eliminado duplicidades e inconsistncias e realizando agregaes e
sumarizaes.
4.3.2 Integrador
O integrador pode ser implementado como um mecanismo de regra base,
recebendo as notificaes dos extratores e integrando-as no DW [VAL96]. Cada regra
responsvel pela manipulao de um determinado tipo de notificao e implementada
como um mtodo em um sistema orientado a objetos. Quando o extrator gera um
determinado tipo de notificao o mtodo correspondente chamado e ento executa os
31
processamentos necessrios para integrar os dados no DW, durante este processo o

integrador pode obter dados extras no DW ou em outras bases de dados.
Consultas
Data warehouse
Integrador
Extrator
Extrator
Extrator
Base de
dados
Base de
dados
Base de
dados
Figura 4.4 Arquitetura bsica de um DW [VAL 96].
4.3.3 Processamento de informaes

Para receber respostas corretas de um DW necessrio elaborar perguntas
certas, para isso o usurio deve ter conhecimento do assunto, experincia e capacidade
de anlise. necessrio primeiro definir o problema a ser resolvido, depois elaborar as
perguntas que necessitam de respostas, verificar se os dados apropriados esto
disponveis e se so suficientes para responder as questes. O processo de consulta
consiste de cinco etapas:
32
Definio das consultas: O usurio deve definir a consulta de forma a

traduzir as necessidades da empresas em termos que o DW possa responder, isso
pode ser feito atravs de ferramentas comerciais ou aplicaes;
Acesso e recuperao de dados: As ferramentas de acesso submetem a
consulta e recuperam os dados apropriados, este processo pode envolver
clculos;
Clculo, manipulao e anlise: Anlises adicionais, como clculos e
manipulaes, podem ser feitas para transformar os resultados da consulta em
informaes;
Apresentao das informaes: Os resultados podem ser apresentados em
forma de relatrios, grficos, texto em tela ou como dados pr-processados para
anlise posterior;
Disseminao da informao: As informaes podem ser distribudas aos
interessados das diversas formas existentes, como relatrios, arquivos, correio
eletrnico, etc.
As ferramentas para consulta dos dados normalmente possuem componentes
grficos e suportam um certo grau de multidimensionalidade, como sondagem
inteligente, relatrios de intertabelas e anlise de sries de tempo.
4.4 Outras arquiteturas

Segundo Pieter R. Mimno [BAR96], existem vrias opes de arquiteturas
diferentes que podem ser consideradas na implementao de um DW. Algumas delas
so:
4.4.1 Arquitetura de duas camadas

Uma opo de arquitetura para o DW utilizar um computador de alta
capacidade como servidor, como mostrado na Figura 4.5. Isto uma incorporao das
aplicaes utilizadas pelos usurios (front end) com os componentes do servidor (back
end). Aplicaes front end construdas com ferramentas cliente/servidor fornecem uma
interface grfica amigvel, suportam funes especficas da empresa, possibilitam o
acesso transparente aos dados dos sistemas j existentes e escondem a complexibilidade
e a falta de consistncia dos bancos de dados atuais alm de facilitar a utilizao e a
visualizao dos resultados. Os sistemas operacionais de uma empresas podem estar em
uso por 15 ou 20 anos e podem ter altas taxas de redundncia. Organizaes como as
companhias de seguros, que podem crescer com a compra de outras seguradoras,
gradualmente acumulam mltiplos sistemas de computao, cada um deles com
redundncias e incompatibilidade de definies dos dados. A redundncia e a falta de
consistncia dos dados pode dificultar a administrao da empresa e o acesso aos dados
e impedem o desenvolvimento de novas aplicaes front end. Uma das maneiras de
tratar com esta situao partir de um s sistema e construir uma espcie de sistema
guarda-chuva que tenha facilidade de acesso aos dados do servidor principal.
33
BD
Sistema
Operacional
BD
Sistema
Operacional
BD
Sistema
Operacional
Servidor
Principal
DW
Figura 4.5 Arquitetura de duas camadas.

A arquitetura ilustrada na Figura 4.5, pode ser usada para construir um DW em
duas camadas que consiste de componentes dos clientes (front end) e componentes do
servidor (back end). Esta arquitetura atrativa porque ela utiliza os sistemas existentes
bem como os servidores de bancos de dados existentes e requer um investimento
mnimo em hardware e software. Entretanto, a arquitetura em duas camadas no
escalonvel e no suporta um grande nmero de usurios simultaneamente. Isto
estimula o desenvolvimento de estaes clientes muito pesadas, pois muito
processamento alocado para processar nestas estaes.
4.4.2 Arquitetura de trs camadas

Uma alternativa utilizar a arquitetura de informao em mltiplas camadas,
como mostrado na Figura 4.6. Esta arquitetura flexvel suporta um grande nmero de
servios integrados, na qual a interface do usurio, as funes de processamento do
negcio e as funes de gerenciamento do banco de dados so separadas em processos
que podem ser distribudos atravs da arquitetura de informao.
A arquitetura em trs camadas amplamente utilizada para DW. Na terceira
camada ficam as fontes de dados. Dados e regras de negcio podem ser compartilhados
pela organizao, assim como o banco de dados para o DW, ficam armazenados em
servidores de alta velocidade na segunda camada. Na primeira camada ficam as
aplicaes de interface com os usurios que devem ser grficas e baseadas em rede.
No ambiente do DW, os servidores de banco de dados e os servidores de
aplicaes da segunda camada fornecem um acesso eficiente e veloz aos dados
compartilhados. Os dados de um DW so tipicamente estticos, por exemplo, no
variam com o tempo e devem ser integrados, de natureza histrica e sumarizados ou
agregados para que sejam significantes para os analistas de negcios. Como mostrado
na Figura 4.6, dados operacionais e bancos de dados para o DW so freqentemente
armazenados em servidores fisicamente separados. Bancos de dados operacionais so
otimizados para ter alto desempenho no processamento de transaes on-line, em ingls
34
conhecido como On-line Transaction Processing (OLTP). Bancos de dados para DW

so otimizados para ter alto desempenho em consultas e anlises, em ingls conhecido
como On-line Analytical Processing (OLAP).
BD
BD
Aplicaes
front-end
Sistema
Operacional
Servidor
de aplicaes
BD
Sistema
Operacional
Aplicaes
front-end
Servidor
de BD p/DW
BD
Sistema
Operacional
Aplicaes
front-end
DW
Figura 4.6 Arquitetura de trs camadas.

importante reconhecer que no existe uma arquitetura correta para DW. Para
algumas organizaes pode ser atrativo utilizar a arquitetura em duas camadas, por que
ela minimiza o custo e a complexibilidade de construo do DW. Para outras que
requerem grande performance e escalabilidade, a arquitetura em trs camadas pode ser
mais apropriada. Nesta arquitetura dados extrados dos sistemas operacionais so
filtrados, transformados e armazenados em servidores de bancos de dados de alta
velocidade, os quais so utilizados para o acesso dos usurios finais. No planejamento
do DW, as organizaes devem examinar as alternativas disponveis de arquiteturas e
selecionar aquela que satisfaa os seu requisitos estratgicos e organizacionais.
35
5 Modelos de dados
O modelo de dados tem um papel fundamental para o desenvolvimento
interativo do DW. Quando os esforos de desenvolvimentos so baseados em um nico
modelo de dados sempre que for necessrio unir estes esforos os nveis de
sobreposio de trabalho e desenvolvimento desconexo sero muito baixos, pois todos
os componentes do sistema estaro utilizando a mesma estrutura de dados.
Existe um grande nmero de enfoques sobre modelagem de dados j
desenvolvidos por vrios autores, a maioria deles pode ser usada para construir um DW.
Dentre estes modelos dois sero resumidamente apresentados neste trabalho. O primeiro
modelo foi escrito por R.Kimball em [KIM96] e divide a modelagem dos dados em
trs partes: modelo empresarial, modelo dimensional e modelo fsico. O segundo
modelo apresentado foi escrito por W.H.Inmon em [INM93] e tambm divide a
modelagem dos dados em trs partes: a modelagem de alto nvel, a modelagem de nvel
intermedirio e a modelagem de baixo nvel. Na seo final do captulo descrita uma
estrutura de dados que padro em todos os ambientes de DW, os instantneos.
5.1 Modelo de dados segundo R.Kimball

A construo de um modelo de dados ajuda a compreender as regras de negcio
que o DW ir apoiar. Muitas vezes a equipe que est desenvolvendo o ambiente do DW
ignora a fase de construo do modelo de dados por no ter tempo ou achar que no
uma parte fundamental para o desenvolvimento. Segundo [KIM96], um dos maiores
problemas no desenvolvimento do DW a compreenso dos dados, em seu artigo so
descritos trs modelos de dados, um modelo entidade-relacionamento normalizado das
regras de negcio ou modelo empresarial, um modelo dimensional e um modelo fsico.
5.1.1 Modelo empresarial

A anlise do modelo de dados o primeiro passo para desenvolver um modelo
entidade-relacionamento normalizado das regras de negcio. Este o modelo
empresarial. Nesta fase no se deve pensar em como as informaes sero recuperadas
nem em como sero utilizadas. Estas tarefas sero realizadas posteriormente. Nesta fase
o importante ter o foco na estrutura da informao, como os atributos e as relaes
entre elas. Por exemplo, se o DW que estiver sendo construdo for sobre vendas em
marketing, o tipo de perguntas que deve-se procurar responder so:
1) Quem compra o produto? (os clientes e sua estrutura);
2) Quem vende o produto? (organizao das vendas, os canais de distribuio e
assim por diante);
3) O que vendido? (estrutura de produto);
4) Quando vendido? (estrutura de tempo);
5) Como e vendido? (contrato, telefone e assim por diante);
6) Quais so as caractersticas da venda (de promoo, venda normal, etc.)
36
Estas questes iro ajudar a descobrir quais so os dados relevantes para o DW e

quais os dados que iro resultar em estruturas dimensionais. muito comum iniciar um
processo perguntando aos usurios o que eles querem ver. Existe um grande problema
nisso. O problema que eles iro pedir por coisas no respondidas no passado, e se for
trabalhado no sentido de oferecer respostas para perguntas do passado os novos
problemas que surgirem podem requerer informaes novas que no estaro
disponveis. E o novo DW estar instantaneamente obsoleto. Pelo menos durante a fase
de construo do modelo empresarial importante desenvolver um modelo que
contenha todos os dados que esto disponveis nos sistemas operacionais da empresa e
em fontes externas.
Isto demostra uma das diferena entre os sistemas de suporte a deciso e os
sistemas operacionais. Nos sistemas operacionais, o processo empresarial quem define
os requisitos dos dados. A utilidade de cada parte dos dados pode ser determinada
avaliando seu valor dentro do processo empresarial. Considerando que o processo no
muda, o valor dos dados no mudam. Embora o processo empresarial determine a
informao em uma aplicao de DSS, o processo empresarial pode e vai mudar.
muito comum confundir as perguntas que deveriam ser feitas com as
perguntas que se deseja perguntar com as perguntas que podem ser feitas. Um exemplo
disto a questo: Que produtos compram as pessoas casadas?. Esta parece ser uma
pergunta interessante e relativamente fcil responder. Para executar alguma anlise de
tendncia, poderia ser perguntado: O que compraram as pessoas casadas ano
passado?. Esta pergunta parece com a primeira, entretanto sem a informao de estado
civil do ltimo ano seria impossvel responder a questo. Este s em exemplo de como
uma informao, ou a falta dela, pode fazer uma diferena crtica para o ambiente de
DW.
O DW pode ser considerado como uma estrutura orgnica, pois ele cresce e
cresce em direes que no podem ser previstas. Se forem enfocadas exigncias
funcionais atuais, ser desenvolvida uma soluo altamente aperfeioada para os
problemas de hoje. Porm, como os problemas mudam a soluo pode ficar cada vez
menos tima. Eventualmente, estar regular e consequentemente ficar inaceitvel. Um
caminho melhor trocar otimizao por flexibilidade. A soluo resultante poder no
ser a ideal mas ser mais adaptvel e consequentemente ter um tempo de vida maior.
O segundo passo para o desenvolvimento do modelo empresarial a
normalizao do modelo, uma vez definidas todas as entidades e relaes possvel
normalizar o modelo. Pode-se utilizar a 3 Forma Normal que alcanada quando os
atributos dependem exclusivamente da sua chave, h muitas vantagens em utilizar a 3
FN.
1) A estrutura notavelmente insensvel a mudanas. Se for preciso mudar,
acrescentar ou excluir, atributos que so relacionados a uma chave em
particular, no deveria haver nenhuma razo para mudar outras entidades ou
relaes. De uma perspectiva do DW, isto significa que a estrutura do DW
pode ser modificada facilmente para refletir mudanas organizacionais ou
problemas empresariais novos.
2) Os caminhos estruturais para ter acesso a informao ficam mais claros.
Considerando que este modelo o resultado de regras de negcio possvel
que surjam caminhos cclicos. Isto significa que necessrio educar os
usurios sobre os caminhos diferentes e que interpretao cada um deles tm.
37
Os caminhos cclicos devem ser eliminados pois a maioria das ferramentas

de consultas no consegue trabalhar com eles.
3) Muito da discusso sobre as formas normais gira em torno da eliminao de
problemas de atualizao. Isto , quais os tipos de problemas de atualizao
que so resolvidos movendo-se para uma forma normal mais alta.
Considerando que um DW raramente atualizado, a possibilidade destes
problemas acontecerem muito baixa. Este o motivo pelo qual aceitvel
falar sobre desnormalizao do DW.
Tambm existem algumas desvantagens na utilizao da 3 FN:
1) O desempenho pode ser comprometido, podendo ficar muito abaixo do
desejado. Muito do trabalho que feito para desnormalizar o modelo de
dados uma tentativa para alcanar objetivos de desempenho.
2) possvel que muitas relaes pequenas sejam criadas e o usurio pode
pensar que so uma nica relao ou grupo de dados. O modelo
dimensional reduz este tipo de problema at um certo ponto.
Considerando que o modelo empresarial no ser implementado, estas
desvantagens raramente so crticas, porm se levadas para o modelo dimensional estas
desvantagens podero reaparecer e ser necessrio um tratamento especial para cada
situao.
O terceiro passo, para desenvolver um modelo entidade-relacionamento
normalizado das regras de negcio, a definio das restries ou regras de
integridade. Como norma geral, deveria ser obrigatria a definio das restries de
integridade dentro de um DW. As restries de integridade ajudam a garantir a
consistncia dos resultados das consultas. Por exemplo, quando forem executadas
operaes de refinamento das informaes, conhecidas por operaes de drill-down, por
uma estrutura dimensional, as restries de integridade garantem que a resposta obtida
seja sempre a mesma, como se tivesse sido feita uma pesquisa por toda a tabela. Nota-se
que a no obrigatoriedade das restries de integridade pode resultar em respostas
diferentes para perguntas iguais.
Por outro lado a obrigatoriedade da definio das restries de integridade pode
fazer com que alguns registros no sejam selecionados durante o processo de carga. A
deciso sobre a definio de regras de integridade deve levar em conta o que melhor
para o DW que est sendo construdo, respostas consistentes, mas possivelmente
incompletas ou respostas completas mas possivelmente inconsistentes.
possvel que as fontes de dados criem situaes onde no seja possvel utilizar
as restries de integridade, neste caso importante saber as implicaes que isto pode
ter sobre o DW e manter os usurios informados sobre o que pode acontecer em
determinadas situaes.
5.1.2 Modelo dimensional

A resposta a perguntas complexas e que envolvam questes de anlise dos
negcios de uma empresa, normalmente requerem uma viso dos dados de perspectivas
diferentes. As respostas a esse tipo de pergunta que podem levar a tomadas de
decises acertadas ou no. As ferramentas baseadas em SQL podem ajudar na pesquisa
38
de dados relacionados a este tipo de consulta, o que ocorre que normalmente as

respostas no so conseguidas em um tempo curto, principalmente pela falta de
flexibilidade destas ferramentas.
Para exemplificar, imagine-se uma rede de supermercados que esteja querendo
melhorar o desempenho de suas vendas ou saber se suas promoes esto trazendo bons
resultados. Para isso, necessrio examinar os dados sobre as vendas disponveis na
empresa. Uma avaliao deste tipo requer uma viso histrica do volume de vendas sob
mltiplas perspectivas, como por exemplo: volume de vendas por produto, volume de
vendas por marca, volume de vendas por filial, volume de vendas por perodo de tempo.
Chama-se de dimenses as diferentes perspectivas envolvidas, no caso, produto,
marca, filial e ms. Estas dimenses usualmente correspondem a campos no numricos
em um banco de dados. Considera-se tambm um conjunto de medidas, tal como vendas
ou despesas com promoo. Estas medidas correspondem geralmente a campos
numricos em um banco de dados. A seguir, avaliam-se agregaes destas medidas
segundo s diversas dimenses, essas agregaes ficam armazenadas para acesso futuro.
Por exemplo, calcula-se a mdia de todas as vendas por todos os meses por filial. A
forma como estas agregaes so armazenadas pode ser vista em termos de dimenses e
coordenadas, dando origem ao termo multidimensional.
A modelagem multidimensional o nome de uma tcnica de projeto lgico
freqentemente usada para DW, cujo principal objetivo apresentar o dado em uma
arquitetura padro e intuitiva, que permita acessos de alta performance [KIM96]. Cada
eixo no espao multidimensional corresponde a um campo ou coluna de uma tabela
relacional e cada ponto um valor correspondente interseo desses campos ou colunas.
Assim, o valor para o campo vendas, correspondente a ms igual a maio e filial 4 um
ponto com coordenada [maio, filial 4]. Neste caso, ms e filial so duas dimenses e
vendas uma medida. Teoricamente, quaisquer dados podem ser considerados
multidimensionais. Entretanto, o termo normalmente se refere a dados representando
objetos ou eventos que podem ser descritos e portanto classificados, por dois ou mais de
seus atributos.
Dados multidimensionais podem ser armazenados e representados em estruturas
relacionais, para isso necessrio utilizar formas especficas de modelagem como o
modelo Estrela e o modelo Floco de Neve descritos a seguir.
5.1.2.1 Modelo Estrela
Conforme Daphnis Valente em [VAL96], tradicionalmente, modelos de bases de
dados relacionais apresentam tabelas com relacionamentos complexos e com mltiplas
unies circulares entre dois pontos do modelo. Para a maioria dos usurios que utilizam
ferramentas para compor suas consultas necessrio que o acesso a base de dados seja
simples o suficiente para facilitar o acesso direto a base de dados. Para acomodar as
necessidades de todos os usurios e facilitar a atualizao do DW o projetista deve criar
um modelo que o usurio final possa facilmente entender em termos do negcio.
O principal tipo de modelo dimensional, o chamado modelo Star (Estrela),
onde existe uma tabela dominante no centro, chamada tabela de fatos, com mltiplas
junes conectando-a a outras tabelas, sendo estas chamadas de tabelas de dimenso.
Cada uma das tabelas secundrias possui apenas uma juno com a tabela central. O
39
modelo Estrela, ilustrado na Figura 5.1, tem a vantagem de ser simples e intuitivo, mas
tambm faz uso de novos enfoques de indexao e unio de tabelas.
A tabela de fatos contm milhares ou milhes de valores e medidas do negcio
da empresa, como transaes de vendas ou compras. Cada uma destas medidas
tomada segundo a interseo de todas as dimenses. Na Figura 5.1, as medidas
numricas so o nmero de reais vendidos e o nmero de unidades vendidas. Os fatos
melhores e mais teis so numricos, continuamente valorados (diferentes a cada
medida) e aditivos, j que estes facilitam a gerao do conjunto de respostas. Uma outra
caracterstica da tabela de fatos a esparsidade, ou seja, se no existe um cruzamento
para alguns valores das dimenses, a tabela de fatos no armazena zeros.
As tabelas de dimenso armazenam as descries textuais das dimenses do
negcio. Cada uma dessas descries textuais ajuda a definir um componente da
respectiva dimenso. Uma das principais funes dos atributos de tabelas de dimenso
servir como fonte para restries em uma consulta ou como cabealhos de linha no
conjunto de resposta do usurio. Tabelas dimenses tendem a utilizar tipos caracteres ao
invs de numricos, de forma que suas linhas so muito mais longas mas em pouca
quantidade ocupando uma pequena percentagem de espao em disco. As tabelas de
fatos podem utilizar at 95% da rea destinada ao DW [BAR96].
Na maioria das vezes as dimenses representam hierarquias, como por exemplo,
um produto, que de uma marca ou categoria, que por sua vez pertence a uma subcategoria, etc. S que, na maioria das vezes, quando esta representada na dimenso,
no temos vrias tabelas normalizadas com ligaes um-para-muitos, e sim uma nica
tabela de dimenso. Isso faz com que a performance das consultas aumente muito, j
que no so necessrios joins para se obter os dados relacionados com algum assunto.
Outro fato importante que como a tabela de fatos na verdade representa os
relacionamentos muitos-para-muitos entre as tabelas de dimenses, esta tem como
chave primria uma chave composta de todas as chaves estrangeiras das tabelas de
dimenso [KIM96].
Para um bom desempenho do modelo Estrela necessrio que os projetistas
saibam antecipar, na modelagem do DW, as consultas mais freqentes a serem
realizadas pelos usurios. Com a redundncia seletiva e relacionamentos prestabelecidos o projetista pode simplificar os dados facilitando seu acesso.
Figura 5.1 Modelo dimensional do tipo Estrela.
40
5.1.2.2 Variao do modelo Estrela

Outro tipo de estrutura bastante comum, conforme [CAM97], o modelo de
dados Snow Flake (Floco de Neve), que consiste em uma extenso do modelo Estrela
onde cada uma das pontas da estrela passa a ser o centro de outras estrelas. Isto
porque cada tabela de dimenso seria normalizada, quebrando-se a tabela original ao
longo de hierarquias existentes em seus atributos. Este modelo pode ser ilustrado
imaginando-se a classificao de um automvel, onde a dimenso do produto possui
uma hierarquia definida: categoria se divide em marca e marca se divide em produtos,
como ilustrado na Figura 5.2. Da mesma forma, a dimenso tempo inclui ano que
contm ms e ms que contem dia-do-ms. Cada um destes relacionamentos muitospara-um geraria uma nova tabela em um modelo Floco de Neve.
Kimball [KIM96] aconselha os projetistas a resistirem tentao de transformar
modelos Estrela em modelos Floco de Neve, devido ao impacto da complexidade deste
tipo de estrutura sobre o usurio final, enquanto que o ganho em termos de espao de
armazenamento seria pouco relevante.
Figura 5.2 Modelo dimensional do tipo Floco de Neve.
5.1.2.3 Vantagens do Modelo Estrela

Segundo Kimball, o modelo dimensional apresenta vrias vantagens no que diz
respeito a sua utilizao para DW, dentre estas esto [KIM96]:
O modelo Estrela tem uma arquitetura padro e previsvel. As ferramentas de

consulta e interfaces do usurio podem se valer disso para fazer suas
interfaces mais amigveis e fazer um processamento mais eficiente;
Todas as dimenses do modelo so equivalentes, ou seja, podem ser vistas

como pontos de entrada simtricos para a tabela de fatos. As interfaces do
usurio so simtricas, as estratgias de consulta so simtricas, e o SQL
gerado, baseado no modelo, simtrico;
O modelo dimensional totalmente flexvel para suportar a incluso de

novos elementos de dados, bem como mudanas que ocorram no projeto.
Essa flexibilidade se expressa de vrias formas, dentre as quais temos:
Todas as tabelas de fato e dimenso podem ser alteradas

simplesmente acrescentando novas colunas a tabelas;
Nenhuma ferramenta de consulta ou relatrio precisa ser alterada de

forma a acomodar as mudanas;
41
Todas as aplicaes que existiam antes das mudanas continuam

rodando sem problemas;
Existe um conjunto de abordagens padres para tratamento de situaes

comuns no mundo dos negcios. Cada uma destas tem um conjunto bem
definido de alternativas que podem ento ser especificamente programadas
em geradores de relatrios, ferramentas de consulta e outras interfaces do
usurio. Dentre estas situaes temos:
Mudanas lentas das dimenses: ocorre quando uma determinada

dimenso evolui de forma lenta e assncrona;
Produtos heterogneos: quando um negcio, tal como um banco,

precisa controlar diferentes linhas de negcio juntas, dentro de um
conjunto comum de atributos e fatos, mas ao mesmo tempo esta
precisa descrever e medir as linhas individuais de negcio usando
medidas incompatveis;
Outra vantagem o fato de um nmero cada vez maior de utilitrios

administrativos e processo de software serem capazes de gerenciar e usar
agregados, que so de suma importncia para a boa performance de respostas
em um DW.
5.1.2.4 Comparao entre o modelo E-R e o modelo Estrela

Uma das principais diferenas entre o modelo E-R e o modelo Estrela a
complexibilidade. Por ser normalizado, o modelo E-R gera dezenas ou at centenas de
tabelas conectadas entre si, o que faz com que ele se torne confuso e de difcil
compreenso por parte dos usurios. J o modelo multidimensional do tipo estrela
apresenta uma estrutura muito mais simples, onde uma tabela central, a tabela de fatos,
ligada a vrias tabelas de dimenses uma nica vez, tornando o modelo de fcil
compreenso [KIM95].
A construo do modelo E-R se baseia no micro-relacionamento entre os dados,
ou seja, a escolha das entidades e seus relacionamentos feita baseando-se em como as
coisas acontecem. No modelo dimensional, a escolha das dimenses e atributos de fatos
so baseados na opinio do usurio, o que faz com que o modelo reflita as suas
necessidades [KIM95].
O modelo dimensional enxerga as informaes de uma perspectiva histrica ao
invs de transaes atmicas, tal como nos diagramas E-R [RAD96].
O modelo multidimensional globalmente consistente para toda a empresa, ao
passo que o modelo relacional consistente somente dentro de seu escopo. A principal
razo disso que o modelo dimensional tem como objetivo fornecer uma viso
integrada dos dados da empresa [RAD96].
Os relacionamentos no modelo E-R so modelados explicitamente, ao passo que
no modelo multidimensional estes relacionamentos so representados pela existncia de
fatos no cruzamento entre as dimenses [RAD96].
42
5.1.2.5 Mapeamento do modelo E-R para o modelo Estrela

de fundamental importncia para o DW, que os dados da empresa sejam
integrados, de forma que este possa ser construdo facilmente e de forma consistente. O
modelo de dados corporativo normalmente expressa esta integrao, por isso alguns
autores sugerem que se utilize o modelo de dados corporativo para se chegar ao modelo
dimensional. Entretanto o modelo multidimensional mais utilizado para a construo de
DW o modelo Estrela que possui uma estrutura totalmente diferente do modelo E-R.
Como os dois modelos podem representar dados de uma mesma empresa de
perspectivas diferentes normal que exista uma ligao entre eles. Baseando-se nisso,
propostas de mapeamento entre os dois modelos comearam a surgir, de forma que os
modelos E-R corporativos pudessem ser aproveitados para gerar os modelos Estrela.
Como os modelos E-R representam todos os possveis processos de negcio da
empresa, enquanto cada modelo dimensional focaliza em nico assunto de interesse,
possvel que de um modelo E-R surjam vrios modelos dimensionais que normalmente
estaro interligados.
Uma das abordagens, feita por Kimball detalha os seguintes passos para o
mapeamento [KIM97]:
1. Separar o diagrama E-R nos diferentes processos de negcio e modelar cada
um separadamente;
2. Selecionar os relacionamentos muitos-para-muitos que contenham fatos
aditivos e numricos, no modelo E-R, para transform-los em tabelas de
fato;
3. Por fim, deve-se desnormalizar todas as tabelas remanescentes em tabelas
com chaves simples, que se conectam diretamente as tabelas de fato. Estas
tabelas se tornam as tabelas de dimenso.
Nos casos em que a tabela de dimenso se conecta a mais de uma tabela de fatos,
esta deve ser representada em ambos os esquemas, e estas so ditas ento serem
conformed entre os dois modelos.
O modelo dimensional global resultante, para uma grande empresa, deve
consistir de cerca de dez a vinte e cinco modelos Estrela conectados. Cada um tendo de
quatro a doze dimenses. Se o projeto foi feito de forma correta, muitas destas
dimenses sero compartilhadas entre as tabelas de fatos.
Na seo 5.3 so apresentadas algumas regras para traduo do modelo E-R para
o modelo dimensional Estrela propostas por Inmon [INM93].
5.1.2.6 Dimenses em bancos de dados multidimensionais
Uma matriz bidimensional representa mais claramente os dados armazenados na
forma relacional tradicional. Na Figura 5.3, os valores de vendas esto localizados nas
intersees dos eixos X e Y da matriz 3x3. Cada eixo corresponde a uma dimenso
(uma das perspectivas dos dados) e cada elemento dentro de uma dimenso corresponde
a uma posio. As perspectivas esto embutidas diretamente na estrutura como
dimenses e todos os possveis valores da cada dimenso esto explicitados nas
posies, facilitando ao usurio sua manipulao e visualizao. Alm disso, na
43
representao multidimensional, totais consolidados so facilmente obtidos e

armazenados, bastando simplesmente adicionar totais de colunas e fileiras.
Banco de Dados Relacional

Marca
Produto Vendas
Marca A X
5
Marca A Z
3
Marca A Y
8
Marca B Y
4
Marca B Z
2
Marca B X
1
Marca B Y
8
Marca C Y
4
Matriz Bidimensional
Marca
X Y Z Total
Marca A 5 8
3 16
Marca B 1 4
2 7
Marca C 0 4
0 4
Total
6 16 5 27
Figura 5.3 Comparao entre o BD Relacional e o BD Multidimensional.

Um banco de dados multidimensional ao invs de armazenar os dados como
registros em tabelas, armazena os dados em arrays multidimensionais. Um array
multidimensional tem um nmero fixo de dimenses. As posies segundo uma
dimenso so tambm chamadas de elementos ou membros. As dimenses podem ser
compostas por mltiplos nveis, segundo os quais os dados podem ser agrupados. Os
membros do nvel mais baixo da hierarquia de uma dimenso so chamados de
membros de entrada.
5.1.3 Modelo fsico

Cada um dos modelos apresentado tem um propsito particular. O propsito do
modelo fsico alcanar objetivos de desempenho. Se os computadores no tivessem
restries de velocidade e de recursos de armazenamento, no seria necessria a
preocupao com o modelo fsico, mas como este no o caso a elaborao de um bom
modelo fsico e outro no to bom pode ser a diferena entre sucesso e fracasso do DW.
O modelo fsico tambm dependente do SGBD e da configurao de hardware. As
diretrizes encontradas na definio de Kimball [KIM96] procuram no enfocar nenhum
SGBD ou hardware especfico
Com raras excees o desempenho de um DW ser limitado nos processo de
entrada e sada dos dados, portanto so problemas que esto relacionados com o SGBD
ou com o prprio DW. Caso o DW tenha significantes problemas de desempenho
importante que o modelo fsico sofra uma reviso[MCG98].
5.1.3.1 Processamento paralelo
Os resultados do processamento paralelo so alcanados quando possvel
decompor uma nica operao ou consulta em fluxos paralelos e executa-los
simultaneamente. Em geral, se o tipo de processamento que ser executado se
44
beneficiar do processamento paralelo, importante que o SGBD utilizado permita

estruturar fisicamente os discos de forma que processo paralelo no fique limitado
sucesso fsica das linhas das tabelas.
H essencialmente trs tipos diferentes de processamento paralelo[MCG98]:
Symmetric Parallel Processing (SMP) ou processo paralelo simtrico, Massively
Parallel Processing (MPP) ou processo maciamente paralelo e o clustering. A
diferena entre SMP e MPP o que compartilhado. Em SMP, os processadores
compartilham uma memria comum, enquanto em MPP os processadores no
compartilham nada. Mquinas de SMP so mais fceis de administrar enquanto as
mquinas de MPP tm um melhor desempenho. Clustering so grupos de mquinas
unidas por uma rede de alta velocidade de conexo
A vantagem do processamento paralelo que muitos processadores baratos e
lentos juntos so mais rpidos que uns poucos processadores caros e rpidos. As
vantagens relativas de SMP contra MPP no pertencem ao escopo deste trabalho e
portanto no sero discutidas. Porm, as vantagens do clustering so relevantes para o
modelo fsico de DW.
A complexidade das consulta executadas nos ambientes de DW esto ficando
cada vez mais complexas. Algumas questes podem levar segundos enquanto outras
podem levar horas para serem processadas, isto por que algumas consultas complexas
podem executar centenas de pequenas consultas para chegarem ao seus objetivos. O
processamento paralelo em clustering permite criar um agrupamento de mquinas para
processar pedidos que exijam alta demanda de processamento, onde cada mquina faria
uma parte dos processos melhorando o tempo de resposta total. Clustering uma
caracterstica muito importante para o SGBD em que o DW ser desenvolvido.
5.1.3.2 Consideraes bsicas
Esta seo resume algumas consideraes que devem estar presentes na mente
do arquiteto de dados enquanto este estiver desenvolvendo o modelo fsico [MCG98].
Chaves alfanumricas: Chaves alfanumricas devem ser substitudas por
chaves numricas. Este fato pode ter um impacto significante no espao requerido para
o armazenamento tanto dos dados quanto dos ndices. Mas o espao em disco no to
crtico quanto o tempo necessrio para processar estas chaves. Tempos de procura para
ndices compostos por nmeros inteiro so muito menores que os tempos de pesquisa
por chaves textuais.
Dependncias transitivas: Os atributos em uma relao so transitivamente
dependentes de todas as entidades mais fracas. Por exemplo, o atributo
descrio_do_grupo da tabela grupo_de_produtos transitivamente dependente na
relao com a tabela subgrupo_de_produtos. O processo de normalizao removeu o
campo descrio_do_grupo da entidade mais fraca (subgrupo_de_produtos) e o
colocou somente na entidade mais forte (grupo_de_produtos). Neste caso pode ser
benfica a desnormalizao deste relacionamento colocando o campo
descrio_do_grupo tambm da tabela subgrupo_de_produtos, isto melhorar o
desempenho das consultas que envolvam as duas tabelas e a descrio do grupo,
conforme ilustra a Figura 5.4.
45
Tabelas normalizadas, mas com dependncia transitiva

GRUPO_DE_PRODUTOS
GRUPO
1
2
3
DESCRICAO_DO_GRUPO
PRODUTOS CLASSE A
PRODUTOS CLASSE B
PRODUTOS CLASSE C
SUBGRUPO_DE_PRODUTOS
VALOR
SUBGRUPO
INDICE
1001
1002
15
1003
87
3001
3002
45
GRUPO
TIPO
Tabela desnormalizada mas com facilidade de acesso ao atributo descricao_do_campo

SUBGRUPO_DE_PRODUTOS
GRUPO
DESCRICAO_DO_GRUPO
SUBGRUPO
INDICE
TIPO
PRODUTOS CLASSE A
1001
PRODUTOS CLASSE A
1002
PRODUTOS CLASSE A
1003
PRODUTOS CLASSE C
3001
PRODUTOS CLASSE C
3002
Figura 5.4 Dependncias transitivas entre tabelas.
5.2 Modelo de dados segundo W.H.Inmon

Este modelo que ser resumidamente apresentado neste trabalho, pode ser
pesquisado mais detalhadamente em [INM93]. Este modelo composto por trs nveis
de modelagem: a modelagem de alto nvel, a modelagem de nvel intermedirio e a
modelagem de baixo nvel.
5.2.1 Modelo de dados de alto nvel

O alto nvel de modelagem apresenta as entidades e seus relacionamentos,
conforme ilustrado na Figura 5.5, as entidades exibidas neste nvel encontram-se no
nvel mais alto de abstrao. Para determinar quais entidades participam deste nvel
necessrio estabelecer o escopo de integrao que quem define as fronteiras do
modelo de dados e deve ser definido antes do incio do processo de modelagem. O
escopo de integrao pode ser definido pelos analistas, pela gerncia e pelo usurio final
e deve ser redigido em no mais do que cinco pginas e em uma linguagem de fcil
entendimento para as pessoas de negcios.
46
Cliente
Pedido
Estoque
Cobrana
Produo
Expedio
Figura 5.5 Representao da modelagem de alto nvel.
5.2.2 Modelo de dados de nvel intermedirio

O modelo de dados de nvel intermedirio criado a partir das rea de interesse
ou entidades identificadas no nvel alto de modelagem, para cada uma destas reas ou
entidades desenvolvido um nvel intermedirio prprio. Este nvel composto por
quatro elementos apresentados na Figura 5.6.
Um agrupamento primrio de dados, o qual composto pelos atributos que
aparecem uma nica vez em cada rea de interesse. Como todos os
agrupamentos de dados o agrupamento primrio contem atributos e chaves;
Um agrupamento secundrio de dados que engloba os atributos que podem
aparecer mais de uma vez na mesma rea de interesse;
Um conector que representa os relacionamentos dos dados entre as reas de
interesse;
O tipo dos dados.
Esses quatro elementos de modelagem so usados para identificar os atributos de
dados de um modelo e os relacionamentos entre tais atributos. Normalmente cada
agrupamento de dados existente no modelo de dados resulta na definio de uma tabela
durante o processo de projeto do banco de dados.
47
Agrupamento
primrio de
dados
Agrupamento
secundrio de
dados
Chave
Campo1
Campo2
Campo3
.....
Chave
Campo1
Campo2
Campo3
.....
Chave
Campo1
Campo2
Campo3
.....
Chave
Conector
dados
Chave
Campo1
Campo2
Campo3
.....
Agrupamento
primrio de
dados
Chave
Campo1
Campo2
Campo3
.....
Figura 5.6 Os elementos do modelo de dados de nvel intermedirio [INM97].
5.2.3 Modelo de dados de baixo nvel

O modelo de baixo nvel, tambm chamado de modelo fsico, de dados criado
a partir do modelo de nvel intermedirio simplesmente expandindo este de forma que
ele passe a apresentar chaves e caractersticas fsicas. Neste ponto o modelo fsico de
dados necessita ser alterado para receber as caractersticas de performance.
No caso do DW, o primeiro passo para a incluso dos fatores de performance
consiste em decidir sobre a granularidade e o particionamento dos dados, alm da
alterao da estrutura da chave para a incluso do elemento de tempo. Depois que a
granularidade e o particionamento tiverem sido includos, vrias outras atividades de
projeto fsico so embutidas no projeto.
Uma das principais atividades no projeto fsico se refere a otimizao das
operaes de E/S (entrada/sada) fsica. E/S fsica a atividade que introduz os dados
no computador a partir do meio de armazenamento ou envia os dados do computador
para o meio de armazenamento. A tarefa do projetista do DW consiste em organizar os
dados fisicamente de forma que durante a execuo de uma E/S seja transferida uma
massa de dados que apresente alta probabilidade de ser acessada. Por exemplo, se um
programador precisar acessar e recuperar cinco registros e estes registros estiverem
dispostos em blocos de dados diferentes, sero necessrias cinco E/S. Mas se o
projetista tiver condies de prever a necessidade de agrupar os registros e coloca-los no
mesmo bloco fsico, somente uma E/S ser necessria, fazendo com que o programa
seja executado com mais eficincia.
48
5.3 Estratgia de converso do modelo E-R para o modelo

de dados do DW
Para construir o modelo de dados do DW Inmon [INM93] recomenda a
utilizao do modelo de dados corporativo, pois este modelo j possui todos os atributos
necessrios para registrar as informaes dos sistemas operacionais da empresa.
Contudo, um considervel nmero de alteraes feito no modelo corporativo de dados
quando ele aplicado ao DW. Para tal, Inmon fornece ento alguns passos que podem
ser seguidos, no se esquecendo de que o fundamental que as decises de
transformao devem ser tomadas levando-se em considerao os requisitos especficos
da empresa. Os passos bsicos so:
5.3.1 Remoo dos dados puramente operacionais

A primeira ao consiste em remover os dados que so usados apenas no
ambiente operacional, como vemos no exemplo da Figura 5.7. Neste, atributos tais
como mensagem, descrio e status so retirados pois muito pouco provvel que estes
sejam utilizados no processo de tomada de deciso.
Neste momento, pode ser que se pense em manter todos os atributos, pois talvez
algum destes seja necessrio para alguma deciso especfica. Entretanto, deve-se levar
em conta o custo para gerenciar grandes volumes de dados.
Modelo de Dados
Corporativo
Modelo de Dados do
Data Warehouse
#ID da Nota Fiscal

Data de Emisso
ID do Comsumidor
End do Consumidor
Mensagem
Descrio
Termos
Status
#ID da Nota Fiscal

Data de Emisso
ID do Comsumidor
End do Consumidor
Atributos que
provavelmente no sero
usados no processo de
tomada de deciso
Figura 5.7 Remoo de dados puramente operacionais.
5.3.2 Adio de um elemento de tempo na estrutura da chave

A segunda modificao a ser feita no modelo corporativo adicionar um
elemento de tempo a chave das tabelas, se estas j no o tiverem.
No exemplo da Figura 5.8, o campo Data_Snapshot foi adicionado como parte
da chave. Enquanto no modelo corporativo a chave apenas a identificao do
consumidor, no modelo do DW a data do instantneo deve fazer parte da chave, j que
com o passar do tempo os dados do consumidor podem se alterar. Esta tcnica apenas
uma forma de tirar instantneos dos dados.
49
Outra forma de faz-lo adicionar dois campos do tipo data, um marcando o

incio e outro o fim de um determinado intervalo de tempo. Esta tcnica melhor por
representar faixas contnuas de tempo ao invs de pontos ou datas especficas.
Modelo de Dados
Corporativo
Modelo de Dados do
Data Warehouse
#ID do Consumidor
Nome
Data de Nascimento
Estado Civil
Limite de Crdito
#ID do Consumidor
#Data do Snapshot
Nome
Idade
Estado Civil
Limite de Crdito
Figura 5.8 Adio de uma elemento de tempo na estrutura da chave.
5.3.3 Introduo de dados derivados

O prximo passo adicionar dados derivados ao modelo, como mostrado na
Figura 5.9, j que por regra geral estes no existem no modelo corporativo. Devem ser
adicionados os dados derivados que sero usados habitualmente de forma que estes
sejam calculados apenas uma vez. Dessa forma, haver uma reduo no processamento
que deve ser feito para acessar os dados derivados ou sumarizados.
Outra razo para o armazenamento de dados derivados que uma vez calculados
e armazenados, a integridade destes aumenta, uma vez que se torna impossvel a
utilizao de diferentes algoritmos para o clculo destes derivados.
Modelo de Dados
Corporativo
Modelo de Dados do
Data Warehouse
#ID da Nota Fiscal

#Item
Cdigo do Produto
Quantidade
Preo_Unitrio
#ID da Nota Fiscal

#Item
Cdigo do Produto
Quantidade
Preo_Unitrio
Total Comprado
Custo do Produto
Dados
Derivados
Figura 5.9 Introduo de dados derivados na chave.
5.3.4 Transformao de Relacionamentos entre dados em artefatos

dos dados
Os relacionamentos encontrados nas modelagens de dados clssicas, assumem
que h um e somente um valor de negcio no relacionamento. Levando-se em
considerao que nos sistemas operacionais o dado estar integro no momento da
transao, esta abordagem correta. Entretanto, o DW por sua caracterstica de
50
armazenar dados histricos, tem muitos valores para um dado relacionamento entre duas
tabelas. Dessa forma a melhor maneira de representar o relacionamento entre duas
tabelas no DW atravs da criao de artefatos.
Um artefato de um relacionamento somente a parte do relacionamento que
bvia e tangvel no momento do instantneo. Em outras palavras, quando o instantneo
feito os dados associados com o relacionamento que so teis e bvios sero
colocados no DW.
O artefato pode incluir chaves estrangeiras e outros dados relevantes, tais como
colunas de tabelas associadas, ou este pode incluir somente os dados relevantes, sem
incluir as chaves estrangeiras.
Como exemplo, consideremos as tabelas e o relacionamento entre estas na
Figura 5.10. Nesta existe um relacionamento entre produto e fornecedor, onde cada
produto tem um fornecedor principal. Se fossemos fazer ento um instantneo deste
relacionamento, teramos que considerar a informao do fornecedor principal que est
relacionado ao produto. Alm disso, outras informaes de artefato relacionadas com o
fornecedor deveriam ento ser capturadas. A tabela de produtos no modelo do DW
ficaria ento como a mostrada na Figura 5.11.
Modelo Corporativo
Produto
#Cdigo do Produto
Descrio
Unidade de Medida
Fornecedor do Produto
#Cdigo do Produto
#Cdigo Cosumidor
Forncedore Preferido
Figura 5.10 Relacionamento entre tabelas no sistema corporativo.
Modelo de Dados do Data

Warehouse
Tabela Snapshot
de Produtos
#Cdigo do Produto
Descrio
Unidade de Medida
FornecedorPreferido
CidadeForncedor
EstadoFornecedor
PasFornecedor
Artefatos
Figura 5.11 Incluso dos artefatos no DW.
51
Mas o exemplo anterior, tem o problema de ser incompleto. Isto ocorre porque
ele mostra o relacionamento que existe em um instante de tempo especfico, de forma
que eventos podem ocorrer e nunca serem capturados. Por exemplo, se este instantneo
for tirado semanalmente, pode ser que um produto mude trs vezes de fornecedor
durante uma semana, fazendo com que somente o ltimo seja armazenado no DW.
Uma forma de tentar solucionar este problema, seria guardar registros histricos
e no instantneos. Por exemplo, para o produto pode-se armazenar os dados no exato
momento em que este foi recebido, de forma que o fornecedor deste nunca seria
perdido, sendo sempre armazenado no DW. Na Figura 5.12 pode-se ver como seria feito
este registro.

Warehouse
Tabela Snapshot
de Produtos
#Cdigo do Produto
#Cdigo da Entrega
Data de Recebimento
Cdigo do Fornecedor
Nome do Fornecedor
Unidade de Medida
Condio
Recebido por
Figura 5.12 Captura dos dados a cada recebimento do produto.
5.3.5 Acomodao dos diferentes nveis de granularidade

Dependendo do caso, o nvel de granularidade do sistema transacional pode ser o
mesmo do DW ou no. Quando o nvel de granularidade se altera, o modelo do DW
deve representar esta mudana, como no exemplo da Figura 5.13.
No exemplo, o modelo de dados corporativo mostra dados da atividade de envio
de um determinado produto que so armazenadas toda vez que uma entrega feita.
Quando este passado para o DW, duas agregaes so feitas, alterando ento a
granularidade. Na primeira, o total de entregas agregado mensalmente, fazendo com
que a granularidade seja o ms, j na segunda, existe uma agregao das entregas feitas
por ms e local de origem, fazendo ento com que a granularidade seja o ms associado
ao fornecedor.
52
Modelo Corporativo
Atividade de Entrega
Data da Entrega
Cdigo da Entrega
Enviado por
Enviado para
Quantidade

Warehouse
Entregas Mensais
#Ano/ms
Nmero de Entregas
Valor da Entrega
Entregas Atrasadas
Entregas na Data
Sumarizao por
Produto
Cdigo do Pedido
Inventrio por Item
#Ano/ms
#Enviado por
Nmero de Entregas
Valor da Entrega
Entregas Atrasadas
Entregas na Data
Figura 5.13 Alterao do nvel de granularidade.
5.3.6 Unio dos dados comuns de diferentes tabelas

Neste fase, deve-se considerar a possibilidade de combinar duas ou mais tabelas
do modelo corporativo em uma nica tabela do modelo do DW. Para que esta juno
possa ser feita, as seguintes condies devem ser verdadeiras:
As tabelas compartilham um chave comum (ou chave parcial);
Os dados das diferentes tabelas geralmente so usados juntos;
padro de insero nas tabelas o mesmo.
Como exemplo, consideremos a Figura 5.14, onde temos as tabelas NOTAS e

ITENS DAS NOTAS. Quando estas so colocados no modelo do DW, estas vo para uma
mesma tabela. Dessa forma, a juno entre estas tabelas passa a no ser mais necessria
quando uma consulta for feita. Neste caso, podemos ver que as trs condies so
atendidas: as tabelas compartilham parte da chave, ID da Nota; estas duas tabelas
geralmente so usadas juntas; e o padro de insero o mesmo, ou seja, sempre que
uma nota inserida seus itens tambm o so.
5.3.7 Criao de arrays de dados

Os dados no modelo corporativo geralmente esto normalizados, onde a
existncia de grupos repetitivos no permitida. Entretanto, em algumas situaes no
ambiente de DW podem haver grupos repetitivos de dados. As condies para
existncia destes so:
Quando o nmero de ocorrncias do dado previsvel;
53
Quando a ocorrncia do dado relativamente pequena (em termos de

tamanho fsico);
Quando as ocorrncias do dado geralmente so usadas juntas;
Quando o padro de insero e remoo dos dados estvel;
Merge das duas tabelas

#Cdigo da Nota
Data de Nota
Cdigo do Consumidor
Cod. Repr. Vendas
#Cdigo da Nota
#Cdigo do Item
Cdigo do Produto
Quantidade
Preo Unitrio
#Cdigo da Nota
#Cdigo do Item
Data de Nota
Cdigo do Consumidor
Cod. Repr. Vendas
Cdigo do Produto
Quantidade
Preo Unitrio
Figura 5.14 Unio dos dados de diferentes tabelas.

A Figura 5.15 mostra uma tabela no modelo corporativo com as previses de
gasto mensais. Quando esta colocado no modelo do DW, os dados so armazenados
de forma que cada ms do ano uma ocorrncia no array.
Modelo Corporativo
#Cod Previso Gasto
Gasto Mensal/Anual
Valor do Gasto

Warehouse
#Cod Previso Gasto
#Ano
Valor em janeiro
Valor em fevereiro
Valor em maro
......
......
Valor em dezembro
Figura 5.15 Criao de arrays de dados.

H vrias vantagens em se utilizar esta abordagem. Uma delas, que no tendo
registros individuais para cada ms, uma certa quantidade de espao economizada.
Alm disso, o ndice no modelo corporativo requer 12 entradas para cada entrada no
modelo do DW. Outra vantagem, a possibilidade de organizar todas as ocorrncias
anuais dos dados em uma nica localizao fsica, criando a possibilidade de um
aumento de performance. Obviamente, esta melhoria de performance est condicionada
ao SGBD em questo, a organizao fsica dos registros dentro deste, e outros.
54
5.3.8 Separao dos atributos de dados de acordo com sua estabilidade

A prxima atividade de projeto, referente passagem do modelo de dados da
empresa para o modelo de dados do DW, consiste em realizar a anlise de
estabilidade. A anlise de estabilidade uma tarefa que consiste em agrupar atributos
de dados segundo sua propenso a alteraes. A Figura 5.16 ilustra a anlise de
estabilidade de uma tabela de produtos. Neste exemplo possvel perceber que os dados
que raramente sofrem alteraes so agrupados com outros dados que apresentam essa
mesma caracterstica, dados que s vezes so alterados so agrupados com outros dados
que s vezes so alterados e dados que freqentemente so alterados so agrupados com
outros dados freqentemente alterados. O resultado final da anlise de estabilidade a
criao de grupos de dados que apresentem caractersticas semelhantes.
Tabela de peas
raramente
alterada
alterada
algumas vezes
alterada
freqentemente
Codigo
Descrio
Principal_substituta
Quantidade_atual
Unidade_compra
Ponto_reposicao
Fornecedor
Prazo_entrega
Taxa_rejeicao
Transportadora
Data_ultima_venda
Quantidade_ultima_venda
Local_ultima_entrega
Manifesto_carga
Quantidade_encomendada
.....
Codigo
Descrio
Unidade_compra
Prazo_entrega
Taxa_rejeicao
Manifesto_carga
.....
Codigo
Principal_substituta
Ponto_reposicao
Fornecedor
Transportadora
.....
Codigo
Quantidade_atual
Data_ultima_venda
Quantidade_ultima_venda
Local_ultima_entrega
Quantidade_encomendada
.....
Figura 5.16 Anlise de estabilidade dos dados [INM97].
55
5.4 Modelo de estrutura dos dados

Apesar das diversas aplicaes e dos diversos tipos de DW, h uma linha
comum entre todos eles. Internamente, cada um dos DW concentra-se em uma estrutura
de dados denominada instantneo ou snapshot. Os instantneos so criados como
resultado da ocorrncia de algum evento, normalmente aleatrio, como a emisso de
uma nota fiscal, o recebimento de mercadorias ou a compra de um produto. Tambm
podem ser criados com a passagem normal do tempo, passagens regulares de tempo
tpicas incluem o final do dia, o final da semana e o final do ms.
O instantneo disparado por um evento apresenta quatro componentes bsicos
descritos a seguir e representados na Figura 5.17.
Uma chave, que pode ou no ser nica, e normalmente possui vrios
elementos que servem para identificar os dados primrios;
Uma unidade de tempo, que pode referir-se ao momento em que ocorreu o
evento descrito ou o momento da captura dos dados;
Dados primrios que se relacionam diretamente com a chave, so os
principais dados do registro e no so opcionais;
Dados secundrios, que so opcionais, so capturados como parte do
processo de criao do instantneo e no possuem relacionamento direto com os
dados primrios ou com a chave. So informaes complementares que podem
auxiliar em processamentos SAD futuros.
INSTANTNEO
Unidade de
tempo
Dados primrios
Dados Secundrios
Chave
Figura 5.17 Componentes de um instantneo [INM97].

Um arquivo de produtos pode ser usado como exemplo da ocorrncia de um
instantneo. Toda vez que o produto comprado ou vendido o DW alertado e um
registro contnuo da histria do produto feito. Um registro pode acompanhar o produto
por dois ou trs anos, dependendo do volume dos dados, aps um determinado tempo
outro registro criado e continua recebendo o histrico do produto. Quando for
necessrio resgatar informaes sobre este produto o DW acessar somente as
informaes contidas dentro do perodo de tempo solicitado.
56
6 Desenvolvimento do Data Warehouse

No h receita pronta para desenvolver um DW. Mas possvel encontrar vrias
ferramentas que abrangem desde as etapas de extrao e anlise de dados at a
construo propriamente dita e o gerenciamento do DW.
Um dos pontos a se observar o valor do investimento, geralmente situado na
casa dos milhes de dlares. Por estar diretamente vinculado aos negcios da empresa,
o projeto exige no apenas o trabalho da equipe tcnica como a participao constante
da rea executiva pois qualquer desvio na execuo pode causar graves prejuzos ao
levar a empresa a consultar informaes no confiveis e, consequentemente, a tomar
decises erradas.
Este captulo aborda as funes que as pessoas desempenham dentro do
ambiente do DW, algumas fases e processos necessrios para a transformao do
modelo empresarial para o modelo de dados do DW. Deve estar claro para a equipe de
desenvolvimento que para inserir os dados operacionais no DW necessrio ter um
mtodo eficiente e que satisfaa as condies do DW da empresa. Para aumentar a
performance do DW existem algumas tcnicas que podem ser aplicadas durante o seu
desenvolvimento como a redundncia dos dados e o agrupamento de registros, tambm
discutido o intervalo que deve existir entre as atualizaes dos dados no DW.
Dependendo do tamanho do projeto possvel desenvolver um data mart que
poder ser definitivo, se o escopo do projeto for pequeno ou poder ser agrupado com
outros data marts para formar um nico DW. No final est um a lista de erros mais
comuns no desenvolvimento do DW.
6.1 As funes em um Data Warehouse

Para criar e manter um DW necessrio desenvolver uma srie de funes.
Dependendo do tamanho do projeto e o tipo de tecnologia utilizada pedem ser
necessrias vrias pessoas para realizar as diferentes funes necessrias. Nem todas as
funes descritas na Tabela 6.1 so necessrias durante todo o tempo de vida de um
DW. Estas funes podem variar conforme o estgio em que se encontra o DW, bem
como, podem ser agrupadas para que uma s pessoa realize vrias delas ao mesmo
tempo.
Funo
Gerente do DW
Arquiteto de Dados
Responsabilidades
Define as estratgias pertinentes ao DW
Planeja e gerencia o DW
Comunica os objetivos do DW para a
equipe de desenvolvimento
Desenvolve o modelo de dados
Analisa as exigncias de dados
Desenha as estruturas dos dados
Define as vises gerenciais para os
dados
57
Funo
Administrador de Metadados
Administrados do BD
Responsabilidades
Define os padres de metadados
Gerencia o repositrio dos metadados
Cria as estruturas fsicas no BD
Monitora o carregamento dos dados e a

performance das consultas
Usurio de nvel gerencial
Descreve os dados necessrios
Especifica as regras de negcio
Testa os resultados das transformaes

dos dados
Analista de processos e aplicaes
Desenvolve as aplicaes de suporte a

deciso
Especialista em Aplicaes Operacionais
Indica onde esto os dados nos sistemas

operacionais
Analista e programador de converses
Indica as fontes de dados para o DW
Desenvolve os programas
selecionar e carregar os dados
para
Especialista em suporte tcnico
Desenvolve as atividades tcnicas

como instalar e configurar mquinas
Instrutor
Treina os usurios para acessar o DW
Tabela 6.1 Funes em um Data Warehouse [BAR96].
6.2 Consideraes iniciais para o desenvolvimento de um

Data Warehouse
O incio basicamente consiste na extrao dos dados das fontes internas,
incluindo a transformao e a limpeza dos dados. Deve-se observar a exigncia de
padronizao dos dados, geralmente distribudos de formas distintas pelos
departamentos das empresas. Um dos itens mais importantes o repositrio dos
metadados, responsvel pela documentao de cada registro realizado na base de dados.
Os metadados vo proporcionar a segurana sobre a qualidade das informaes obtidas.
Para que o projeto do DW obtenha sucesso necessrio escolher corretamente a
estratgia a ser adotada, esta estratgia deve ser adequada s caractersticas e
necessidades especficas do ambiente onde o DW ser implementado. Existem vrias
58
abordagens que podem ser utilizadas para o desenvolvimento de um DW, mas

importante fazer uma escolha fundamentada em pelo menos trs dimenses: escopo do
DW (departamental, empresarial, etc), grau de redundncia de dados e tipo de usurio
alvo [WEL97].
O escopo de um DW pode ser to amplo quanto aquele que inclui todo o
conjunto de informaes de uma empresa ou to restrito quanto um DW pessoal de um
nico gerente. Quanto maior o escopo, mais valor o DW tem para a empresa e mais cara
e trabalhosa ser sua criao e manuteno. Por isso, muitas empresas tendem a
comear com a construo de Data Marts e s aps obter um retorno de seus usurios
expandir seu escopo integrando os Data Marts em um nico DW.
Quanto redundncia de dados, h essencialmente trs nveis de redundncia:
DW virtual: Consiste em simplesmente prover os usurios finais com
facilidades adequadas para extrao das informaes diretamente dos bancos de
produo, no havendo assim redundncia, mas podendo sobrecarregar o
ambiente operacional;
DW centralizado: Constitui-se em um nico banco de dados fsico contendo
todos os dados para uma rea funcional especfica, um departamento ou uma
empresa, sendo usado onde existe uma necessidade comum de informaes. Um
DW central normalmente contm dados oriundos de diversos bancos
operacionais, devendo ser carregado e mantido em intervalos regulares;
DW distribudo: Como o nome indica, possui seus componentes
distribudos por diferentes bancos de dados fsicos, normalmente possuindo uma
grau de redundncia alto e por conseqncia, procedimentos mais complexos de
carga e manuteno.
Outro fator importante na escolha da abordagem de desenvolvimento o padro
de uso do DW. Relatrios e consultas pr-estruturadas podem satisfazer o usurio final,
e geram pouca demanda sobre o SGBD e sobre o servidor. Anlises complexas, por sua
vez, tpicas de ambientes de suporte deciso, exigem mais de todo o ambiente.
Ambientes dinmicos, com necessidades em constante mudana, so melhor atendidos
por uma arquitetura simples e de fcil alterao, como as estruturas altamente
normalizadas, ao invs de uma estrutura mais complexa que necessite de reconstruo a
cada mudana, por exemplo, estrutura multidimensional.
O DW deve ser construdo de forma interativa, isto , no possvel definir
antecipadamente todos os requisitos necessrios sua construo at que ele esteja
parcialmente povoado e sendo utilizado pelos analistas de SAD. Portanto ele no pode
ser projetado da mesma forma como so construdos os sistemas baseados em
requisitos. Por outro lado um erro grave pensar que no necessrio prever alguns
requisitos iniciais. necessrio encontrar um meio termo entre estes dois conceitos. Por
ser projetado e carregado passo a passo, dito que ele segue uma abordagem
evolucionria.
Inmon [INM97] indica algumas das muitas razes que indicam a importncia do
desenvolvimento seguir a abordagem evolucionria:
Histrico de sucesso das aplicaes sugere enfaticamente tal mtodo;
Usurio final no ter condies de expressar suas necessidades com clareza
at que a primeira interao seja feita;
59
A gerncia no se comprometer por completo at que verdadeiros

resultados tangveis e claros sejam apresentados;
H necessidade de, rapidamente, obter resultados visveis.
Muitas empresas iniciam o processo a partir de uma rea especfica, que
normalmente uma rea carente de informao e cujo trabalho seja relevante para os
negcios da empresa, criando Data Marts, para depois ir crescendo aos poucos,
seguindo uma estratgia botton-up ou assunto-por-assunto.
Outra alternativa selecionar um grupo de usurios, prover ferramentas
adequadas, construir um prottipo do DW e deixar que os usurios analisem
minuciosamente as amostras dos dados. Somente aps a concordncia do grupo quanto
aos requisitos e funcionamento, que o DW ser de fato carregado com dados dos
sistemas operacionais na empresa e dados externos.
O modelo de processos deve ser bem analisado antes do incio do projeto pois
ele formado tipicamente por diagramas de contexto de nvel zero, diagramas de fluxo
de dados, diagramas de estrutura e outras estruturas baseadas em requisitos. Em muitos
ambientes o modelo de processos pode ser fundamental para o desenvolvimento de
sistemas, no entanto, na construo de um DW o modelo de processos pode ser um
empecilho, pois ele pressupe a existncia de um conjunto de necessidades conhecidas
antes que os detalhes do projeto sejam definidos. Diversas ferramentas de
desenvolvimento, como as ferramentas CASE, so baseadas nesse mesmo aspecto e,
portanto, no so aplicveis ao ambiente de DW.
necessrio ter conscincia que ainda no existe uma metodologia consolidada
para o desenvolvimento de um DW. Campos [CAM97] afirma que o que se v na
literatura e nas histrias de sucesso de implementaes em empresas, so propostas no
sentido de construir um modelo dimensional a partir do modelo de dados corporativo ou
departamental (base dos bancos de dados operacionais da empresa), de forma
incremental. Inmon [INM93] salienta que, de fato, um DW construdo de uma
maneira "heurstica", confirmando a estratgia evolucionria discutida anteriormente.
6.3 Desenvolvimento utilizando o modelo Estrela

Dados multidimensionais podem ser armazenados e representados em estruturas
relacionais, para isso necessrio utilizar formas especficas de modelagem como o
modelo Estrela descrito no captulo 5, a qual armazena e representa dados
multidimensionais em estruturas relacionais, a seguir esto relacionados os principais
tpicos sugeridos para um desenvolvimento utilizando o modelo Estrela.
Segundo Kimball [KIM96], desenvolver um DW uma questo de unir as
necessidades dos seus usurios com a realidade dos dados disponveis. Kimball aponta
um conjunto de nove pontos fundamentais no projeto da estrutura de um DW, que
constituem definies a serem feitas, as quais correspondem as etapas do projeto.
Portanto em um projeto que utiliza o modelo do tipo estrela deve-se fazer as seguintes
definies.
1. Os processos e, por conseqncia, a identidade das tabelas de fatos;
2. A granularidade de cada tabela de fatos;
3. As dimenses de cada tabela de fatos;
60
4. Aos fatos, incluindo fatos pr-calculados;

5. Os atributos das dimenses;
6. Como acompanhar mudanas graduais em dimenses;
7. As agregaes, dimenses heterogneas, minidimenses e outras decises de
projeto fsico;
8. Durao histrica do banco de dados;
9. A urgncia com que se d a extrao e carga para o DW.
Para exemplificar algumas das etapas propostas por Kimball podemos imaginar
os processos de uma loja qualquer, onde se encontram diversos tipos de rotinas: controle
de estoque, pedidos de compra, inventrio, pedidos de clientes, expedio de pedidos,
vendas, etc.
Aps a identificao dos processos cria-se uma ou mais tabelas de fatos a
partir de cada um deles, identificando tambm o que corresponde a um fato individual
naquela tabela, estas informaes iro caracterizar a granularidade da tabela. Exemplos
de granularidade so: um grupo de produtos, um perfil de venda dirio de um produto,
ou um perfil de venda mensal de um produto. Aps definir a granularidade da tabela de
fatos, as dimenses e suas respectivas granularidades podem ser identificadas. Neste
exemplo, considera-se a tabela de fatos vendas acumuladas do produto. Assim, as
dimenses tempo, produto e vendedor so criadas, alm de outras dimenses descritivas
como local-de-expedio, local-de-recebimento, modo-de-envio. A adio destas
dimenses descritivas no altera o nmero de instncias na tabela de fatos. A Figura 6.1
mostra a tabela de fatos com as dimenses identificadas. A escolha das dimenses o
ponto chave no projeto pois cada dimenso pode ser vista como um ponto de entrada
para a tabela de fatos. O passo seguinte consiste em detalhar todas as medidas que
constaro da tabela de fatos e finalmente completar as tabelas de dimenses. Neste
instante, tem-se a estrutura do projeto lgico completa.
Figura 6.1 A tabela de fatos e suas dimenses no modelo Estrela [CAM97].
61
6.4 Os dados operacionais

tentador pensar que a criao do DW consiste em apenas extrair dados
operacionais e inseri-los no Data Warehouse. Nada poderia estar mais longe da
verdade. [INM97]. Esta afirmao faz sentido pois um DW construdo com
informaes provenientes de vrias aplicaes operacionais com dados no integrados
entre si. Quando estas aplicaes j existentes foram criadas no foi considerada a
possibilidade de uma integrao futura. Cada aplicao possui seu conjunto nico e
particular de requisitos e, durante o processo de desenvolvimento, as demais aplicaes
no eram levadas em conta.
No difcil encontrar em sistemas de uma mesma empresa dados rotulados da
mesma maneira em locais diferentes mas que contenham as mesmas informaes ou
alguns dados que apresentem os mesmos rtulos e as mesmas informaes mas com
unidades de medidas diferentes. A questo da configurao dos extratores ou mesmo da
programao de extratores personalizados para os sistemas da empresas que no so
integrados pode se tornar uma tarefa muito complexa. A Figura 6.2 demonstra a falta de
integrao comum ao ambiente dos sistemas existentes.
Vendas
Mesmos dados,
Nomes diferentes.
Compras
Dados diferentes,
Mesmos nomes.
Pedidos
Dados s
encontrados aqui.
Estoque
Chaves diferentes,
mesmos dados
Figura 6.2 A falta de integrao dos dados de diferentes aplicaes.
Um exemplo simples de falta de integrao o fato de os dados no poderem ser

codificados de forma coerente. Um campo que tenha o objetivo de armazenar a
informao distncia pode ser definido de vrias maneiras. Alm de poder ter qualquer
nome como rtulo ele tambm pode utilizar unidades de medidas distintas como metros,
quilmetros ou centmetros. No existe uma preocupao especfica com o modo como
o caminho ser medido do DW, contanto que ele seja medido de forma coerente. A
Figura 6.3 ilustra o processo de integrao de dados que tem o mesmo significado mas
que possuem representaes diferentes.
62
Transformao da unidade de medida

Aplicao A - centmetros
Aplicao B quilmetros
Aplicao C - polegadas
Data Warehouse
centmetros
Aplicao D - metros
Figura 6.3 Integrao de dados com as mesmas informaes.

Este exemplo apenas d uma idia da questo da integrao e por si s no
complexo. Mas quando ele se multiplica pelos milhares de arquivos e sistemas
existentes, a questo da integrao se torna extremamente complexa e onerosa. Outro
importante problema da passagem de dados do ambiente operacional para o ambiente do
DW diz respeito ao acesso eficiente aos dados dos sistemas existentes, no simples
definir um mtodo que indique para os programas que esto varrendo as bases de dados
operacionais se um arquivo j foi ou no varrido anteriormente. H uma enorme
quantidade de dados no ambiente de sistemas existentes e a tentativa de efetuar
varreduras completas toda vez que feita uma varredura para o DW antieconmica e
pouco realista.
Para carregar e transformar os dados provindos de sistemas operacionais,
necessrio um esforo de processamento muito grande, por isso estes processos so
realizados normalmente a noite, deixando os dados disponveis para o dia seguinte.
Quando os dados so transferidos para o DW a sua caracterstica de no volatilidade faz
com que os dados que so manipulados no ambiente operacional assumam a situao de
definitivos no podendo mais sofrer alteraes. Muitos dados do ambiente operacional
no passam para o DW, pois o processo de carga efetua uma filtragem nos mesmos,
impedindo que dados redundantes ou sem valor para analise faam parte do sistema.
H trs tipos de cargas que podem ser feitas do ambiente operacional para o
DW, a carga dos dados histricos, a carga dos valores correntes e o carregamento das
alteraes [INM97].
Dados histricos: O carregamento dos dados histricos do sistema
operacional para posterior descarregamento no DW no uma boa maneira de
acessar os dados dos sistemas existentes pois alm de sobrecarregar os sistemas
on-line tambm pode acessar dados que j foram carregados para o DW;
Dados de valor corrente: O carregamento de dados de valor corrente no
ambiente operacional feito atravs da criao de um ou mais arquivos
seqenciais com os valores atuais do sistema operacional. Este arquivo
posteriormente ser processado e descarregado no DW o que no ocasionar
danos ao ambiente on-line;
63
Alteraes: O carregamento de alteraes do DW a partir de atualizaes

que tenham ocorrido no ambiente operacional desde a ltima atualizao do DW
consiste no maior desafio ao arquiteto de dados. No fcil realizar o
rastreamento eficiente e o tratamento das alteraes que esto sendo efetuadas
sobre o ambiente operacional sem sobrecarrega-lo.
6.4.1 Tcnicas de gerenciamento da quantidade de dados operacionais

pesquisados
Existem algumas tcnicas que podem ser usadas para limitar a quantidade de
dados pesquisados, conforme demostrado na Figura 6.4, as tcnicas expostas a seguir
devem ser analisadas e deve-se escolher a que melhor represente as necessidades da
empresa.[INM97].
A primeira tcnica consiste em pesquisar dados que apresentem marcas de
tempo. Para isso necessrio que as aplicaes registrem o momento da ltima
alterao ou atualizao em um registro para que ao ser executada a varredura para o
DW s sejam examinados os registros que tenham a data de atualizao igual ou maior
do que a data da ltima pesquisa.
A segunda tcnica utiliza um arquivo de registros de alteraes efetuadas.
Este arquivo, tambm chamado arquivo delta, criado por uma aplicao e contm
apenas as alteraes efetuadas por esta nos dados operacionais. Quando possvel
contar com um arquivo delta o processo de varredura se torna muito eficiente uma vez
que os dados que no sofreram alteraes no sero acessados. O problema que
poucas aplicaes geram arquivos delta.
A terceira tcnica consiste em varrer um arquivo de auditoria ou de log.
Basicamente o arquivo de log possui os mesmos dados de uma arquivo delta, todavia,
h algumas diferenas significativas. Uma delas que por ser o arquivo utilizado para a
recuperao dos dados do banco de dados operacional em uma eventual falha no
interessante que se utilize este arquivo com outros propsitos. Outra diferena que os
arquivos de log normalmente possuem uma estrutura interna voltada aos objetivos de
um sistema e no esto completamente preparados para a recuperao de dados por um
DW.
A quarta tcnica empregada no gerenciamento da quantidade de dados
pesquisados durante a extrao para o DW consiste em modificar o cdigo da
aplicao operacional. Essa pode ser a pior escolha, sobretudo quando o cdigo da
aplicao antigo ou complexo.
A ltima opo consiste em moldar um arquivo de imagem anterior e
posterior. Segundo esta opo, uma cpia do banco de dados tirada no momento da
extrao e quando for realizada outra extrao, outra cpia ser tirada. As duas cpias
sero comparadas serialmente entre si para que seja detectada a atividade transcorrida
neste perodo e ento resgatadas as diferenas entre as duas copias. Esse mtodo
pesado, complexo e demanda uma quantidade excessiva de recursos.
64
Marca de
tempo
Aplicaes
existentes
Arquivo
delta
Aplicaes
existentes
Arquivo de
log
Aplicaes
existentes
Imagem
anterior
Cdigo da
aplicao
Aplicaes
existentes
Imagem
anterior
Alteraes
sobre o BD
desde a
ltima
atualizao
Figura 6.4 Tcnicas de gerenciamento da quantidade de dados pesquisados [INM97].

Outra importante observao a ser feita durante a passagem dos dados do
ambiente de sistemas operacionais existentes para o ambiente do DW referente
necessidade de gerenciar o volume de dados. preciso efetuar a condensao dos
dados, pois o volume de dados contidos no DW poder ficar grande demais para ser
controlado, dificultando o gerenciamento de DW e degradando seu desempenho.
6.5 Tcnicas para incrementar a performance do Data

Warehouse
Existem algumas tcnicas que podem ser aplicadas no desenvolvimento de um
DW para incrementar sua performance. Algumas destas tcnicas so amplamente
utilizadas no ambiente operacional e outras so especficas do ambiente de DW, em
[INM97] so descritas algumas tcnicas citadas a seguir.
A primeira tcnica que pode ser utilizada a intercalao de tabelas onde o
projetista deve procurar intercalar as tabelas afins em um mesmo local fsico,
diminuindo assim a quantidade de E/S (entradas/sadas), tanto em termos de acesso aos
dados, como em termos de acessos aos ndices para a localizao dos dados. A melhor
65
estratgia de intercalao de tabelas deve ser defina com base nos tipos de dados e
possveis consultas que podem ser realizadas.
Outra tcnica importante aplicada especialmente no ambiente de DW consiste na
introduo intencional de dados redundantes. A Figura 6.5 mostra um exemplo no
qual a introduo deliberada de dados redundantes proporciona um excelente retorno.
Na parte superior da Figura 6.5 o campo descrio est normalizado e no apresenta
redundncia. Dessa maneira todos os processos que precisam ver a descrio precisam
acessar a tabela bsica. Na parte inferior da Figura 6.5 o campo descrio foi
intencionalmente colocado nas diversas tabelas em que ele precisa ser usado. O
problema da replicao de dados somente o aumento do volume do DW, j que
praticamente no existe a preocupao com atualizaes neste ambiente.
Itens
Cdigo
Descrio
Unidade
Quantidade
.....
atualizao
MRP
Cdigo
.....
acesso
Produo
Cdigo
.....
acesso
Estoque
Cdigo
.....
acesso
Gerncia
Cdigo
.....
acesso
A descrio no est redundante e usada freqentemente, gerando muitos acessos.
Itens
Cdigo
Descrio
Unidade
Quantidade
.....
MRP
Cdigo
Descrio
.....
Produo
Cdigo
Descrio
.....
Estoque
Cdigo
Descrio
.....
Gerncia
Cdigo
Descrio
.....
atualizao
acesso
acesso
acesso
acesso
A descrio est redundante e deve ser atualizada em vrios locais, mas raramente atualizada.
Figura 6.5 Introduo intencional de dados redundantes [INM97].

A terceira tcnica que pode ser utilizada para aumentar a velocidade de acesso
aos dados chamada de separao de dados que consiste em transformar uma tabela
normalizada e que apresente probabilidades de acesso muito diferentes em duas tabelas
66
separadas. A Figura 6.6 demonstra a separao de uma tabela de produtos, onde a data
de cadastramento e a descrio so pouco acessados e a quantidade disponvel do
produto freqentemente consultada.
Para a construo de um DW pode ser usado tambm uma tcnica chamada de
ndice criativo. Um ndice criativo gerado quando os dados passam do ambiente
operacional para o ambiente de DW. O ndice criativo gera um perfil de dados de
interesse do usurio final, como informaes sobre os produtos mais vendidos, clientes
inativos e outras informaes que possam antecipar os interesses da gerencia, como esta
antecipao nem sempre possvel necessrio avaliar com cautela sobre quais os
dados em que ser aplicado esta tcnica.
Cdigo
Descrio
Data_incluso
Qtd_atual
...
Cdigo
Descrio
Data_incluso
...
Dados com baixa
probabilidade de
acesso
Tabela original
Cdigo
Qtd_atual
...
Dados com alta

probabilidade de
acesso
Figura 6.6 Tcnica de separao dos dados conforme a probabilidade de acessos.

Por ltimo deve-se esclarecer que a tentativa de reproduzir a integridade
referencial no DW constitui uma abordagem incorreta pois os dados em um DW no
so atualizados e representam informaes ao longo do tempo, com isso os
relacionamentos no permanecem iguais impossibilitando a criao de relacionamentos.
6.6 Os Data Marts

Empresas que tm exigncias mais modestas, como as que necessitam construir
DW para departamentos individuais podem escolher em construir pequenos Data Marts
que utilizam uma arquitetura baseada em rede.
Pela complexidade de fatores que envolvem um DW corporativo integral, a
construo do projeto lenta e cara. Para equilibrar os gastos e oferecer resultados em
prazos mais curtos, possvel construir Data Marts, que so pequenos DW
departamentais. Entre as principais vantagens da utilizao de Data Marts est a
67
reduo do tempo de implementao, em mdia de 120 dias cada, e o fator preo.

Segundo estimativas, enquanto um Data Marts departamental custa em torno de US$
100 mil a US$ 1 milho, um DW integral comea em torno dos US$ 2 milhes e leva
cerca de um ano para estar consolidado.
Conforme [INM97], os Data Marts so subconjuntos de dados da empresa
armazenados fisicamente em mais de um local, geralmente divididos por departamento
(Data Marts "departamentais"). Existem diferentes alternativas de se implementar os
Data Marts [ONE97], porm a proposta original a aquela onde os Data Marts so
desenvolvidos a partir de um DW central. A Figura 6.7 exemplifica esta situao.
Data Mart
Data Mart
Compras
Vendas
Data Mart
Estoque
Data Warehouse
Figura 6.7 Data Marts departamentais.

Nesta arquitetura, grupos de usurios acessam diretamente os Data Marts de
seus respectivos departamentos. Somente aquelas anlises que necessitam de uma viso
global da empresa so realizadas sobre o DW. Os Data Marts se diferenciam do DW
pelos seguintes fatores [INM97]:
So personalizados: Atendem s necessidades de um departamento
especfico ou grupos de usurios;
Menor volume de dados: Por atenderem a um nico departamento,
armazenam um menor volume de dados;
Histrico limitado: Os Data Marts raramente mantm o mesmo perodo
histrico que o DW, geralmente, o DW mantm um histrico que abrange de 5
a 10 anos, enquanto que os Data Marts devem optar em manter o mesmo
perodo porm com os dados em um nvel maior de granularidade, ou um menor
perodo, com os dados armazenados no mesmo nvel de granularidade do DW;
Dados sumarizados: Os Data Marts geralmente no mantm os dados no
mesmo nvel de granularidade do DW, ou seja, os dados so, quase sempre,
sumarizados quando passam do DW para os Data Marts.
Um dos problemas dos Data Marts o grande risco de desvio do modelo
original, pois pode acontecer um crescimento desestruturado. Por ser muito utilizado e
estar em constante aperfeioamento pode ocorrer a replicao das mesmas informaes
68
em vrios locais o que dificulta uma futura integrao de todos os Data Marts em um
nico DW.
6.7 Os erros no desenvolvimento de um Data Warehouse

Existem vrios problemas que podem ocorrer no desenvolvimento de um DW,
para ajudar o gerente do DW a detectar os principais problemas Barquin [BAR96] cita
os mais comuns:
1) Comear sem o envolvimento da diretoria da empresa: Para que o projeto
de DW tenha sucesso e continuidade necessrio que a alta diretoria esteja
comprometida com o projeto, garantindo as verbas necessrias e ajudando a direcionar o
foco do DW para o negcio da empresa.
2) Criar expectativas que no podero ser cumpridas: O DW mostrar aos
gerentes as melhores decises. Informaes erradas como esta podem criar
expectativas alm do que o DW realmente poder fazer, isto um grave erro e pode
comprometer a continuidade do projeto assim que os gerentes descobrirem que o DW
no mostrar as melhores decises, mas sim respostas as consultas efetuadas. Cabe aos
usurios elaborar consultas inteligentes e analisar as respostas obtidas.
3) Carregar o DW com informaes somente porque elas existem: Nem
todos os dados disponveis nos sistemas operacionais da empresa so necessariamente
teis para o DW. O arquiteto dos dados deve analisar junto aos usurios quais os dados
que realmente contm informaes necessrias e desprezar aqueles que no fazem parte
dos objetivos do DW.
4) Acreditar que o projeto do banco de dados do DW o mesmo que o
projeto de um sistema operacional: Em um processo transacional, o projeto deve
fornecer velocidade de acesso e facilidades na atualizao de registros. O DW
fundamentalmente diferente. A meta no DW so acessos agregados, ou seja, somas,
mdias, tendncias, etc. Outra diferena entre os dois tipos de sistemas o tipo de
usurios. Nos sistemas operacionais um programador desenvolve uma consulta que
poder ser utilizada milhares de vezes. No DW o usurio final desenvolve suas
consultas que podem ser utilizadas somente uma vez.
5) Escolher um gerente para o DW com orientao tcnica: O DW
essencialmente uma prestao de servios e no um servio de armazenamento de
dados por isso fundamental que o gerente do DW seja uma pessoa voltada aos
interesses dos usurios e principalmente que fale a mesma lngua deles.
6) Focalizar-se em dados do tipo registros: Muitas vezes os projetos de DW
partem do princpio que as informaes necessrias ao bom desempenho do DW esto
somente em forma de registros nos arquivos dos sistemas operacionais da empresa. Isto
pode ser um equvoco, j que muitas informaes podem estar armazenadas fora dos
sistemas operacionais em forma de textos, imagens, sons e vdeos.
7) Acreditar nas promessas de performance, capacidade e escalabilidade
dos fornecedores: A informtica cresce de uma maneira muito rpida, isto tambm
acontece com o tamanho do DW, portanto interessante fazer um estudo de
crescimento do DW antes de definir a configurao, que deve atender com folga o
banco de dados do DW pelo menos at a concluso do projeto inicial. interessante que
69
o servidor do banco de dados do DW seja fornecido por uma empresa idnea e que
garanta futuras expanses.
8) Acreditar que quando o DW estiver rodando seu problemas estaro
terminados: Assim que o DW comear a rodar, os usurios comearo a criar mais
consultas e estas consultas necessitaro de novos dados que resultaro em novas
consultas. Assim, o projeto do DW precisa ser atualizado continuamente, no s com
novos dados mas tambm com novas tecnologias.
70
7 Povoando um Data Warehouse

Esta etapa envolve os processos de extrao, filtragem, transformao e
migrao dos dados. Por no existir um produto capaz de oferecer suporte adequado a
todas as fases desta etapa, ela se torna uma das partes mais crticas na construo de um
DW. As ferramentas, tambm conhecidas como componentes back end, normalmente
so especializadas em um dos processos necessrios, o que indica que sempre ser
necessria a utilizao de dois ou mais componentes back end para concluir esta etapa.
As ferramentas podem ser divididas de acordo com suas funes[IDG98]:
Extrao, filtragem, transformao e migrao: tm capacidade de acessar a
base de dados dos sistemas operacionais. A ferramenta de extrao, por exemplo, obtm
os dados que vo ser armazenados no DW. A de transformao acerta os dados para o
formato do DW e a de filtragem faz os ajustes necessrios. So ferramentas limitadas e
s vezes no acessam alguns tipos de bases de dados. Existe um nmero limitado de
fornecedores e a maioria das solues ainda pode ser considerada imatura.
Transferncia de dados e replicao: pode ser considerada um subconjunto
das ferramentas de extrao. No faz nenhum tipo de processamento e transformao.
Apenas transfere um dado de um lugar A para B. Pode ser usada em algumas
situaes especficas como: replicar dado de uma fonte transacional para uma
relacional; ou na consolidao de Data Marts a um DW central, onde vo ficar
guardadas todas as informaes.
Gerenciamento e administrao: uma ferramenta que s faz sentido ser
adquirida depois que o DW est construdo. Monitora as tarefas do DW como a
performance e a segurana. A maioria dos fornecedores conta com solues com
funcionalidades diferentes. Por isso necessrio saber para qual funo se pretende
adquirir. No considerada fundamental.
7.1 Extrao dos dados do ambiente operacional

A primeira tarefa a ser executada pelo componente back end a extrao dos
dados operacionais da empresa, geralmente envolvendo fontes de dados autnomas,
distribudas e/ou heterogneas. Para esta etapa, deve ser considerada uma rea de
trabalho temporria onde os dados extrados sero colocados para receberem os
tratamentos necessrios antes de serem atualizados no DW. Quando se trabalha com
uma rea temporria, a lgica utilizada para "limpar", transformar e integrar os dados
comum a todas as origens, independente do mtodo de acesso utilizada por cada uma
delas [BOH97]. Esta rea de trabalho temporria poder estar no mesmo servidor do
DW ou no.
No existe uma regra que defina qual o intervalo de tempo deve ser adotado para
realizar as extraes, na maioria das vezes, os dados so extrados periodicamente
como, por exemplo, no final do dia, final do ms ou final de um perodo fiscal.
As rotinas de extrao devem ser capazes de isolar somente aqueles dados que
foram inseridos e atualizados desde a ltima extrao, este processo conhecido como
refresh. A melhor poltica de refresh deve ser avaliada pelo administrador do DW, que
deve levar em conta caractersticas como as necessidades dos usurios finais, trfego na
71
rede e perodos de menor sobrecarga, tanto das origens dos dados quanto do DW, devese considerar que os perodos de sobrecarga podem variar para cada origem de dados.
H vrias opes de extrao dos dados do ambiente operacional para o DW
dependendo das caractersticas de cada origem dos dados [CHA97]:
Origens cooperativas: origens que suportam gatilhos (triggers), fazendo
com que notificaes de mudanas na base de dados possam ser programadas
para ocorrer automaticamente;
Origens com log: origens que mantm um log o qual pode ser consultado,
de forma que mudanas possam ser extradas deste log (ex. Sybase Replication
Server e Oracle Replication Server);
Origens consultveis (time stamps): origens que so modeladas para indicar
dados novos e modificados atravs de time stamps. Desta forma, apuraes
peridicas podem ser realizadas diretamente sobre estas origens a fim de isolar
as alteraes que se tem interesse;
Origens de instantneos (snapshots): origens que no suportam triggers,
logs ou consultas. Neste caso, a soluo realizar peridicos snapshots off-line
onde as mudanas so detectadas comparando os sucessivos snapshots.
7.2 Filtrar, transformar e integrar os dados extrados

Uma vez que os dados so extrados e colocados na rea de trabalho temporria,
estes devem passar por uma srie de tratamentos. O primeiro destes tratamentos referese a limpeza ou filtragem dos dados onde o objetivo garantir a integridade dos dados
atravs de programas ou rotinas especiais que tentam identificar anomalias e resolv-las,
deixando os dados em um estado consistente antes de serem instalados no DW
[CEL95]. A correo de erros de digitao, a descoberta de violaes de integridade, a
substituio de caracteres desconhecidos, a padronizao de abreviaes, podem ser
exemplos de limpeza de dados. Algumas ferramentas conseguem identificar
inconsistncias e resolv-las de forma automtica, exemplos destas ferramentas sero
dados na prxima seo.
O segundo passo colocar os dados em uma forma homognea aplicando uma
metodologia de comparao de representaes, que inclua os critrios a serem utilizados
na identificao de semelhanas e conflitos de modelagem[BAT86]. Conflitos de
modelagem podem ser divididos em [RIB95]: semnticos e estruturais. Conflitos
semnticos so todos aqueles envolvendo o nome ou palavra associado s estruturas de
modelagem, por exemplo, mesmo nome para diferentes entidades ou diferentes nomes
para a mesma entidade. Conflitos estruturais englobam os conflitos relativos s
estruturas de modelagem escolhidas, tanto no nvel de estrutura propriamente dito como
no nvel de domnios. O principal tipo de conflito estrutural so os conflitos de domnio
de atributo que se caracterizam pelo uso de diferentes tipos de dados para os mesmos
campos. Conflitos tpicos de domnio de atributo so [RIB95]:
Diferenas de unidades: quando as unidades utilizadas diferem, embora
forneam a mesma informao ( como distncia em metros ou quilmetros);
72
Diferenas de preciso: quando a preciso escolhida varia de um ambiente

para outro (como quando o custo do produto armazenado com duas posies
ou com seis posies decimais);
Diferenas em cdigos ou expresses: quando o cdigo utilizado difere um
do outro (como no caso de sexo representado por M ou F e por 1 e 2) ;
Diferenas de granularidade: quando os critrios associados a uma
informao, embora utilizando uma mesma unidade, so distintos (como quando
horas trabalhadas correspondem s horas trabalhadas na semana ou s horas
trabalhadas no ms);
Diferenas de abstrao: quando a forma de estruturar uma mesma
informao segue critrios diferentes (como com endereo armazenado em um
atributo nico, ou subdividido em rua e complemento).
Aps identificados os conflitos de modelagem, deve-se criar as regras de
mapeamento de representaes equivalentes e de converso para os padres
estabelecidos pelo DW. Para criar estas rotinas existem atualmente no mercado uma
variedade de ferramentas especializadas, conhecidas como data migration. Estas
ferramentas permitem que sejam especificadas regras de transformaes simples como,
por exemplo, converter o cdigo F e M para "masculino" e "feminino" antes que o
registro seja atualizado no DW.
7.3 Ferramentas para extrao dos dados operacionais

As ferramentas utilizadas para a identificao e limpeza de dados inconsistentes
so as chamadas ferramentas de data scrubbing. A caracterstica deste tipo de
ferramenta trabalhar em domnios especficos de conhecimento como, por exemplo,
corrigir listas de nomes e endereos de clientes. Trs exemplos so [ONE97] [CHA97]:
NADIS da Group1 Software, Integrity da Vality Technology Inc. e Trillum da HarteHanks Data Tecnologies.
Outras ferramentas, conhecidas como data auditing, possibilitam a descoberta de
regras e relacionamentos ao analisar os dados [CEL95]. Tais ferramentas podem ser
consideradas uma variante das solues de data mining. Sua funo indicar possveis
inconsistncias utilizando complexos algoritmos matemticos, redes neurais e lgica
fuzzy. Uma ferramenta simples que enquadra-se nesta categoria a WizRule da WizSoft
Incorporated [ONE97]. Trata-se de uma ferramenta comercial, capaz de descobrir
automaticamente regras a partir de bases de dados relacionais. Outros dois exemplos de
ferramentas de data auditing so [ONE97]: Migration Architect da DBStar e
QDB/Analyze da QDB solutions.
As ferramentas de data auditing citadas anteriormente tambm podem auxiliar
na identificao de alguns dos conflitos de modelagem citados. Migration Architect da
DBStar [ONE97], por exemplo, capaz de determinar de forma automtica conflitos
semnticos, bem como identificar dependncias funcionais entre sistemas operacionais
diferentes. Porm, grande parte deste trabalho ainda depende da interveno manual por
parte dos especialistas.
Exemplos de ferramentas que criam regras de mapeamento de representaes
so [WIL97]: Extract da Evolutionary Technologies International (ETI), Passport da
73
Carleton Corp., InfoSuite da Platinum Technology Inc., Prism Warehouse Manager da

Prism Solutions Inc. e SAS/Warehouse Administrator da SAS.
A Tabela 7.1 agrupa em categorias, as principais ferramentas para extrao,
filtragem, transformao e migrao de dados em ambientes de DW.
CATEGORIA
Engenharia Reversa de Dados;
baseada em metadados
Engenharia Reversa de Dados;

baseada no contedo dos dados
Extrao/Transporte em batch;
geradores de cdigo para extrao
baseados em parmetros
Extrao/Transporte em
batch;voc escreve o cdigo de
extrao
Replicao
Middleware - extrao/ transporte

on-line interativo
Qualidade do contedo dos dados

baseadas em filtros
EXEMPLO DE
FERRAMENTA
LogicWorks
ERWIN/ERX
Embarcadero ER/1
Kismet KisMeta
Vality Integrity
QDB Analyze
Data Star
WizRule
Prism Warehouse Director
Carleton Passport
ETI Extract
Prism Warehouse Executive
3GL/4GL
(COBOL et al.)
Platinum InfoRefiner
Platinum InfoPump
Praxis OmniReplicator
IBM DataPropagator
Sybase Replic. Server
CA Enterprise Access
Platinum InfoHub
Praxis Omni Replic.
Sybase Enterp. Connect
IBM DataJoiner
Intersolv Sequelink
Apertus
Trillium
FUNCIONALIDADE
Processa metadados para
documentar sistemas e abstrair
regras de negcio e
relacionamentos
Processa o contedo do dado
junto com o metadado para
abstrair regras do negcio e
relacionamentos,
automaticamente
Extrao controlada de forma
centralizada; programas de
extrao so gerados
automaticamente. Oferecem
converso, alm do transporte.
Oferecem gerenciamento de
replicao
Depsito para o cdigo de
extrao/converso, interfaces
com BDs; modesta funo de
replicao
Especfico para replicao. Pode
incluir funes de extrao/
transporte, embora limitadas
Similar a ferramentas batch
conceitualmente, mas
suportando consultas on-line e
automatizando a interface entre
diversas fontes e as ferramentas
de consulta do usurio
Situadas entre a exportao e
importao de dados, estas
ferramentas suportam filtragem
de dados baseada em
parmetros. So ferramentas
especializadas e mais capazes de
gerenciar relacionamentos e
transformaes do que outras de
uso mais geral. Podem ser
usadas para manter dados com
diferentes chaves em
consonncia, para evitar
problemas de interpretao
durante as consultas.
74
CATEGORIA
EXEMPLO DE
FERRAMENTA
Qualidade do contedo dos dados

baseada em relacionamentos
Vality
DB Star
WizRule
IDI
Qualidade de dados para

objetivos especficos
PostalSoft ACE
Group 1 Nadis
SSA
Qualidade de dados - suporte

entrada de dados em reas
especficas
PostalSoft Library
Mailers +4
Traduo de Dados
Data Junction
Cambio
FUNCIONALIDADE
A qualidade dos dados
avaliada baseada no contedo
dos dados. Padres de dados,
regras e relacionamentos
descobertos assistem os analistas
a determinar areas problema em
termos de qualidade.
Qualidade de dados aplicada a
reas especficas, como por
exemplo, correo de
nome/endereo, nomes
farmacuticos, etc.
Edio automtica de endereos
durante a entrada de dados online. As ferramentas so
incorporadas em telas e entrada
de dados como bibliotecas de
classe.
Auxlio a traduo de formatos
de dados (para uso conjunto com
outros processos)
Tabela 7.1 Ferramentas para extrao, transformao e migrao de dados [ORL96].
75
8 Extrao de informaes do Data Warehouse

O erro mais comum, quando uma corporao decide construir um DW
comear o trabalho pela escolha das ferramentas de acesso, conhecidas tambm por
componente front end, [IDG98]. A ferramenta de extrao dos dados uma parte muito
importante do projeto do DW, mas apenas uma pequena parcela de um conjunto
bastante complexo de solues de hardware e software. Depois de definido e projetado
o escopo do projeto e depois de construdo o repositrio de dados, que deve-se chegar
s ferramentas de front-end responsveis pelo meio de campo entre as bases de dados e
os usurios finais da rea executiva. Elas no podem ser muito complexas porque no
sero utilizadas por profissionais da rea tcnica, mas precisam ser robustas o suficiente
para dar agilidade no acesso s informaes estratgicas.
Existem vrias maneiras de recuperar informaes de um DW, as formas de
extrao mais comuns no mercado hoje so os relatrios, as consultas, os EIS,
ferramentas que utilizam caractersticas OLAP e as ferramentas de Data Mining. A
nova tendncia dessas solues a integrao com o ambiente Web, permitindo maior
agilidade em consultas estticas e dinmicas [MOR98].
8.1 Acesso aos dados do Data Warehouse

O acesso aos dados do DW pode ser realizado de duas maneiras, diretamente ou
indiretamente. Para acessar dados diretamente do DW as aplicaes do ambiente
operacional enviam uma solicitao referente a dados localizados no DW. A solicitao
passada ao ambiente de DW e os dados so localizados e transferidos para o ambiente
operacional. A Figura 8.1 mostra uma consulta feita pelo ambiente operacional
diretamente ao DW.
Consulta
Aplicao
Operacional
Data
Warehouse
Resultado da consulta
Figura 8.1 Acesso direto aos dados do DW.

O acesso direto ao dados do DW pelo ambiente operacional uma ocorrncia
rara, pois apesar de parecer simples e eficiente, uma simples solicitao pode sofrer
uma srie de limitaes, essas limitaes impendem que a maioria dos dados sejam
76
transferidos diretamente do DW para o ambiente operacional. Algumas desta condies

so citadas a seguir.
Uma solicitao pode levar at 24 horas para ser atendida. Isso significa que
o processamento operacional no deve apresentar qualquer exigncia em termos
de resposta;
A solicitao deve ser referente a uma quantidade mnima de dados;
Deve existir compatibilidade entre as tecnologias de gerenciamento do DW e
a do ambiente operacional;
No deve existir formatao de dados na passagem destes para o ambiente
operacional.
Essas condies impedem que a maioria dos dados sejam transferidos
diretamente do DW para o ambiente operacional. Uma das formas mais eficientes de
utilizao do DW o acesso indireto aos seus dados. O acesso indireto aos dados do
DW recomendado por ser eficiente e muito rpido. A Figura 8.2 mostra um acesso
indireto feito pelo ambiente operacional ao DW.
Aplicao
Operacional
Arquivo de
Informaes
Data
Warehouse
Programa de
anlise
Figura 8.2 Acesso indireto aos dados do DW.

Para isso o DW analisado periodicamente por um programa que analisa
caractersticas e critrios relevantes pr-definidos. A anlise cria, ento, no ambiente
operacional, um pequeno arquivo que contm informaes sucintas sobre os negcios
da empresa. Este arquivo fica disponvel para consultas on-line, possibilitando o rpido
acesso aos dados do DW.
O programa de anlise normalmente apresenta muitas caractersticas de
inteligncia artificial, pode acessar todos os dados do DW e executado em segundo
plano o que faz que o DW fique disponvel para outras tarefas ou consultas enquanto ele
atualiza o arquivo que ser utilizado no ambiente operacional. A grande vantagem da
utilizao deste arquivo de dados no ambiente operacional que ele direcionado para
o acesso a unidades individuais de dados, no a varreduras massivas de dados [INM97].
77
8.2 Geradores de consulta e relatrios

Os geradores de consultas e relatrios so considerados a primeira gerao de
ferramentas para a acesso a dados, as quais permitem a realizao de consultas ad-hoc.
Ao contrrio de ter que aprender uma linguagem de consulta, tal como SQL, os usurios
utilizam menus e botes para especificar os elementos de dados, condies, critrios de
agrupamentos e outros atributos, atravs de operaes simples e facilitadas pelo
ambiente grfico. Consulta e relatrios normalmente disponibilizam informaes do
tipo mdias, totalizaes, desvios padro e outras funes bsicas de anlise. Exemplos
de ferramentas que enquadram-se nesta categoria so [DAR96]: Data Prism da Brio,
Crystal Reports da Crystal, Impromptu da Cognos e Discoverer/2000 da Oracle.
8.3 EIS - Executive Information Systems

O termo EIS (Executive Information Systems ou Sistemas de Informaes
Executivas),
refere-se a sistemas destinados especificamente a satisfazer as
necessidades de executivos de alto nvel eliminando a necessidade de intermedirios
entre executivos e computadores.
As principais caractersticas destes sistemas so [SPR91]:
Tem como propsito atender s necessidades de informaes dos executivos de alto

nvel, como acompanhamento e controle de informaes a nvel estratgico da
empresa;
Podem ser adaptados ao estilo de tomada de decises de cada executivo;
Contm recursos grficos de alta qualidade para que as informaes possam ser
apresentadas graficamente de vrias formas;
So fceis de usar, para que o executivo possa oper-los com muito pouco
treinamento;
Proporcionam acesso rpido e fcil a informaes detalhadas, ou seja, as

informaes so visualizadas em nveis que podem ser expandidos;
Fazem uso intenso de dados de fontes externas ao ambiente da empresa como:

concorrentes, clientes, indstrias, mercados, governo, etc.
Os sistemas EIS geralmente acessam o DW de modo indireto, isto , utilizando

uma base de dados exclusiva para o seu processamento, gerada a partir do DW e de
fontes externas. Isto permitir que a interao do executivo com o EIS torne-se mais
rpida, um requisito essencial neste tipo de sistema. Os EIS geralmente apresentam aos
executivos os seguintes tipos de informaes [SPR91] [INM96]:
Narrativas de problemas-chaves: estes relatrios enfatizam o desempenho geral

da empresa, os problemas-chave e suas origens. Um texto explicativo normalmente
aparece junto com informaes em forma de tabelas e grficos;
Quadros de destaque: trata-se de apresentaes resumidas elaboradas a partir da

perspectiva do usurio. Essas representaes enfatizam rapidamente as reas de
preocupao e sinalizam visualmente o estado do desempenho da empresa em
relao ao fatores crticos para o sucesso;
78
Finanas de alto nvel: essas apresentaes fornecem informaes sobre a sade

financeira da empresa em forma de nmeros absolutos e taxas de desempenho
comparativas;
Fatores chaves: tais fatores, conhecidos como indicadores de desempenho,

proporcionam medidas especficas dos fatores crticos para o sucesso no nvel da
empresa. Estes fatores so sinalizados como problemas nos quadros de destaque
quando no conseguem atingir algum padro pr-definido;
Relatrios detalhados: indicam o desempenho particular de indivduos ou unidades

em reas crticas para o sucesso da empresa.
OS EIS podem ser desenvolvidos atravs de pacotes especficos como [DAR96]:

EISToolKit 2.11 da MicroStrategy, SAS/EIS 6.09 da SAS Institute e LightShip 2.3 da
Pilot Software.
8.4 Ferramentas de OLAP (On-Line Analytical Processing)

O termo OLAP foi citado pela primeira vez em um artigo escrito em 1992 por
E.F.Cood [COD95]. Neste artigo Codd definiu doze regras que caracterizam uma
ferramenta OLAP. A Tabela 8.1 cita estas doze regras.
Caractersticas das ferramentas OLAP

1. Viso Conceitual Multi-dimensional
2. Transparncia
3. Acessibilidade
4. Informaes de performance consistente
5. Arquitetura Cliente-Servidor
6. Dimensionalidade genrica
7. Manipulao de matrizes dinamicamente
8. Suporte a multi-usurios
9. Operaes ilimitadas em referncias cruzadas
10. Manipulao de dados intuitivamente
11. Consultas flexveis
12. Nveis de dimenses e agregaes ilimitados
Tabela 8.1 As dozes regras para OLAP segundo Codd [COD95].
Segundo [BAR96], "OLAP considerado uma categoria de software que
permite analistas, gerentes e executivos obter respostas dentro dos dados, atravs de
79
uma rpida, consistente e interativa forma de acesso a uma ampla variedade de possveis
vises". As ferramentas de OLAP permitem que o negcio de uma empresa possa ser
visualizado e manipulado de forma multidimensional, isto , agrupando as informaes
em vrias dimenses como: produtos, fornecedores, departamentos, localizaes,
clientes, recursos, etc.
A criao de tabelas cruzadas, exploso de informaes e a criaes de
dimenses esto entre as funes mais tradicionais das ferramentas OLAP. As
ferramentas OLAP trabalham de modo interativo, permitindo que a partir de uma
resposta o usurio faa outros questionamentos, ou seja, o usurio consegue analisar o
porque dos resultados obtidos. A interao do usurio final com o DW, utilizando as
ferramentas de OLAP, se d atravs de questionamentos, como por exemplo:
1. Qual o total das vendas de casacos de l, nos trimestres do ano de 1997, nas lojas
da regio sul do pas?
2. Qual foi o lucro lquido que os dez maiores clientes no estado do RS geraram
durante o primeiro semestre de 1998?
3. Quais so as dez cidades do Brasil proporcionaram maior lucratividade por
habitante em 1997?
4. Quais so os dez produto que proporcionaram menor lucro durante os meses de
dezembro de 1997, janeiro de 1998 e fevereiro de 1998?
As respostas a estas questes so baseadas em fatos histricos que vo mostrar
uma tendncia de comportamento das variveis selecionadas. A partir destas respostas
possvel formular outras questes at que o nvel de informao desejada seja atendido.
Respondendo rapidamente a estas perguntas que a empresa vai conquistar um
diferencial positivo em relao concorrncia, tendo condies de criar aes rpidas
para sua rea de atuao.
8.4.1 Tipos de Ferramentas de OLAP

As ferramentas de OLAP podem ser divididas em dois grupos, as ferramentas
que acessam SGBD relacionais, as chamadas Relational On-line Analytical Processing
(ROLAP) e as que acessam Bancos de Dados Multidimensionais(BDM), as
Multidimensional On-line Analytical Processing (MOLAP). Os BDM armazenam os
dados em estruturas especiais e implementam as operaes OLAP diretamente sobre
estas estruturas. As primeiras solues OLAP foram baseadas em BDM [BAU97].
Um SGBD relacional permite aos usurios ver os dados em duas dimenses, por
exemplo, produtos por regio. Um BDM permite que os usurios consultem os dados
em vrias dimenses, a Figura 8.3 demonstra um exemplo de como uma informao
armazenada em uma relao de trs dimenses, uma unidade de valor pode conter as
informaes de venda de um produto em um determinado perodo por exemplo. Para
manter estas informaes empregado o uso otimizado de ndices cruzados, estruturas
hierrquicas e dados organizados em dimenses de tempo. possvel ento aos usurios
navegar atravs de muitas dimenses e nveis de dados, por meio de tabelas ou grficos
e descobrir importantes tendncias dos negcios da empresa para o futuro.
Alguns exemplos de ferramentas MOLAP so [BAU97]: Express Analyzer da
Oracle (utilizado sobre o Express Server) e Dimension Control da Dimension Data
Systems, Inc. (utilizado sobre o Essbase).
80
Muitos fabricantes esto agora disponibilizando as chamadas ferramentas

ROLAP, que acessam os dados armazenados em estruturas relacionais organizadas de
forma multidimensional. As abordagens utilizadas para armazenar dados
multidimensionais em estruturas relacionais podem variar desde a adoo de formas
especficas de modelagem, como o modelo Estrela descrito no captulo 5, at mtodos
avanados de indexao.
Figura 8.3 Modelo de BDM de trs dimenses.

Os servidores ROLAP localizam-se entre um SGBD relacional tradicional,
utilizado como gerenciador do DW, e as aplicaes front end. A sua principal funo
receber as consultas multidimensionais enviadas pelas aplicaes cliente e transformlas em rotinas no formato Structured Query Language (SQL) otimizadas para tirar
vantagem dos recursos oferecidos pelo SGBD. O usurio recebe o resultado das
consultas em forma de tabelas, grficos, relatrios, etc.
A grande tendncia das ferramentas de OLAP possibilitar o acesso atravs da
Web. A tecnologia disponibilizada pelo projeto World Wide Web (WWW) tem
revolucionado a forma com que companhias tem fornecido informaes a seus clientes e
funcionrios [WHE96]. A grande vantagem que navegadores de WWW (browsers)
permitem que usurios tenham a sua disposio sistemas de informao de uma forma
distribuda e independente de plataforma. Algumas ferramentas de OLAP j oferecem
acesso via browser, tais como [FLO97]: DSS Web da MicroStrategy, SpaceOLAP da
Infospace, WebOLAP da Information Advantage, Commander DecisionWeb da
Comshare e dbProbe 2.0 da InterNetivity.
Com o crescente volume de dados histricos armazenados no DW e com os
usurios tendo cada vez menos tempo para tomar decises comeam a surgir novas
maneiras de interagir com o DW. Algumas ferramentas de OLAP comeam a
disponibilizar recursos importantes que permitem o usurio receber informaes sem a
necessidade de interagir diretamente com o DW. So os alertas, utilizados
principalmente na identificao de problemas e oportunidades. Os alertas so eventos
inesperados ou peridicos que realizam alguma verificao de condio sobre o
conjunto de bancos de dados do sistema, avisando os usurios finais caso alguma
situao extraordinria tenha acontecido. Por exemplo, um alerta programado para
81
enviar um e-mail ao gerente de compras quando as vendas de determinado produto

esto sendo maiores do que a mdia prevista para o ms [MOR98].
Exemplos de utilizao de ferramentas OLAP:
Uma empresa farmacutica pode analisar as atividades de suas vendas e os

seus resultados e determinar quais mercados devem ser mais focalizados e
quais tero um impacto maior nos prximos meses. Os resultados podem ser
distribudos para as gerencias de vendas, que podero repassar aos
vendedores as recomendaes e as atribuies que iro surgindo durante o
processo de deciso.
Uma administradora de cartes de crdito pode selecionar em um DW de

transaes comerciais de seus clientes, os clientes mais interessados no
lanamento de novos produtos ou cartas de crdito. Podendo direcionar suas
correspondncias para o tipo de pessoa com maiores probabilidades de
resposta.
8.5 Ferramentas de Minerao de Dados

Ainda pouco utilizadas no Brasil, as ferramentas de Minerao de Dados (Data
Mining) so consideradas a terceira gerao de Sistemas de Suporte Deciso (SSD).
Elas possibilitam o cruzamento de informaes na base de dados, com respostas
impensveis sem o uso desta tecnologia.
As aplicaes OLAP vistas anteriormente, permitem que o usurio final possa
extrair informaes e conhecimento que so teis no seu negcio visualizando e
manipulando de forma multidimensional os dados do DW. A abordagem de anlise
utilizada neste caso a de verificao ou descoberta dedutiva [ONE97], isto , uma
consulta solicitada e um resultado apresentado para verificao, em forma de tabelas
cruzadas ou grficos. Nesta abordagem, o usurio final formula uma hiptese sobre o
seu negcio e ento utiliza a ferramenta OLAP para aprovar ou desaprovar esta
hiptese.
Entretanto, ao utilizar a abordagem de verificao, existem algumas informaes
importantes que podem passar desapercebidas para o usurio, at pelo nmero de
variveis e relacionamentos de parmetros, os quais so impossveis de serem
processados pelo crebro humano. Para evitar esta perda de informaes que se torna
necessrio o processo de minerao dos dados. Este processo trabalha no modo de
descoberta indutiva, ou seja, os dados so analisados atravs de um conjunto de
algoritmos e critrios especificados.
As ferramentas de Minerao de Dados, so especializadas em procurar padres
nos dados. Essa busca pode ser efetuada automaticamente pelo sistema ou
interativamente com um analista, responsvel pela gerao de hipteses. Diversas
ferramentas distintas, como redes neurais, induo de rvores de deciso, sistemas
baseados em regras e programas estatsticos, tanto isoladamente quanto em combinao,
podem ser ento aplicadas ao problema. Em geral, o processo de busca interativo, de
forma que os analistas revem o resultado, formulam um novo conjunto de questes
para refinar a busca em um dado aspecto das descobertas, e realimentam o sistema com
novos parmetros. Ao final do processo, o sistema de Minerao de Dados gera um
relatrio das descobertas, que passa ento a ser interpretado pelos analistas de
82
minerao. Somente aps a interpretao das informaes obtidas encontramos

concluses ou regras, este processo conhecido por Knowledge Discovery in Database
(KDD) ou descoberta de conhecimento em banco de dados.
O mercado atual oferece diversas ferramentas para Minerao de Dados, onde
cada uma orientada para realizar determinadas tarefas de "minerao", utilizando
diferentes algoritmos para isto (redes neurais, algoritmos genticos, rvores de deciso,
entre outros). As empresas devem primeiramente identificar o tipo de descoberta que
possa suprir as necessidades de seus negcios para, s ento, selecionar a ferramenta de
minerao mais apropriada, o que ainda um grande problema devido a falta de padres
e as diferenas entre as ferramentas . Exemplos de ferramentas de Minerao de Dados
so [MOR98]: AIRA da Hycones Information Technology, IBM Intelligent Miner da
IBM, WizWhy da WizSoft e IDIS da Information Discovery.
8.6 Fornecedores
medida que o DW se torna parte integrante da computao corporativa, os
fornecedores de
software para gesto empresarial, tambm conhecidos como
Enterprise Resource Planning (ERP) comeam a integrar em seus produtos ferramentas
de anlise e extrao de dados. Grandes empresas como SAP, Oracle e PeopleSoft,
prometem aos usurios verses rpidas, baratas, e relativamente fceis de usar. As
estratgias dos principais fornecedores de sistemas de gesto empresarial a nvel
mundial sobre o DW so[COM97]:
Oracle: No pretende fazer a integrao de seu pacote de aplicativos com o
DW de forma direta. Ao contrrio, disponibiliza uma srie de ferramentas prprias para
fazer a construo do DW corporativo que podem se integrar ao seu sistema ERP.
Mas, de acordo com a empresa, so duas coisas distintas. A unio acontece via o
Express Server um BD multidimensional e os aplicativos Finantial Analyser, Finantial
Controller e o Sales Analyser.
Datasul: Est desenvolvendo ferramentas de extrao de informaes para se
integrar com seus sistemas de EIS para o Magnus e o Datasul EMS. Isso ser a base de
cunho gerencial para abastecer o DW. A ferramenta que deve ser lanada em breve
deve permitir a visualizao dos dados.
PeopleSoft: conta com um conjunto de ferramentas de extrao de dados na
verso atual de seu aplicativo. Uma delas o NVision que extrai informaes
resumidas e gerenciais do seu sistema. Outra a Query, para criao de relatrios online. A prxima verso de seu sistema, ter integrado uma ferramenta OLAP, da
Cognos.
SAP: Est jogando pesado na estratgia de unir seus sistemas e DW.
Recentemente lanou o Business Information Warehouse, um componente do pacote
R/3 que vai ligar as duas tecnologias. A promessa que este mdulo crie uma
independncia entre o sistema relacional e o DW, mas fazendo a consolidao dos
dados de forma ativa. Segundo a empresa, ser um conjunto de ferramentas para
construir, manter e dar funcionalidades ao DW corporativo. Apesar disso, ela j conta
com uma soluo pronta chamada de Open Information Warehouse no produto atual.
83
JD Edwards: Aposta que a unificao da base de dados conseguida com a

implantao de um pacote de gesto empresarial pode levar facilmente construo de
um DW. O motivo que os usurios tero um banco de dados integrado e nico.
Logocenter: No acredita que essa integrao possa acontecer de maneira
simples. Mas conta com um sistema de EIS acoplado ao seu aplicativo. Na viso da
empresa, os pacotes de gesto empresarial sero apenas um alimentador de informaes
do banco de dados do DW.
Baan: O produto integra-se com as solues disponveis no mercado mas no
conta com nenhum mdulo prprio para fazer essa tarefa. Acredita que a funo de um
sistema de gesto empresarial gerenciar o processo de ida e volta das informaes
dentro de uma companhia. No funo do pacote ter ou no um DW incorporado,
mas conta com uma ferramenta de EIS integrada ao aplicativo.
SSA: A estratgia da companhia manter-se na rea em que domina: gesto
empresarial. Acredita que existem empresas tem ferramentas especializadas na rea de
DW. Aposta no conceito de backbone provider, ou seja, permitir que produtos de
terceiros integrem-se ao seu aplicativo para dar a funcionalidade do DW. Apesar disso,
tem um sistema de EIS chamado UserVision, que extrai informaes e gera relatrios
de forma grfica.
NCR: Possui um software chamado Teradata, que focado em DW e vem
conquistando grandes usurios pelo suporte a grandes volumes de dados, desde bases
de 1 GB at 1 TB de informaes. Alm da integrao com servidores de grande porte,
a verso 2 do produto permite manuteno automtica e interfaces Java e CGI.
8.7 Ferramentas comerciais

Com o advento do Data Warehousing as ferramentas OLAP passaram a ter um
grande destaque. Segundo alguns autores o sucesso de um DW pode depender da
ferramenta certa para atender as necessidades dos usurios. Se os usurios no puderem
obter respostas para questes importantes do negcio, os dados armazenados se tornaro
informaes inteis. Portanto a escolha da ferramenta ter um impacto significativo no
sucesso do DW.
Nesta seo est uma breve descrio de trs ferramentas para consultas dados
de um DW. O PowerPlay para anlises multidimensionais de dados, o Maestro que
uma ferramenta para desenvolvimento de aplicaes para apoio a deciso e o
Discoverer/2000 ferramenta da Oracle que permite a construo de consultas, relatrios
e grficos sobre bases de dados relacionais.
8.7.1 PowerPlay
Cognos Incorporated uma empresa canadense sediada em Ottawa, Canad.
Atua no mercado de tecnologia em business intelligence ou apoio a deciso, sua
soluo contempla o acesso, formatao e anlise de dados corporativos estratgicos no
modelo para gesto empresarial. Com mais de 600.000 licenas distribudas em
empresas de 58 pases, os seus produtos esto direcionados a atender toda a estrutura
organizacional de uma empresa, desde a extrao dos dados, formatao de relatrios
gerenciais, anlise multidimensional de informaes e simulaes.
84
Para as anlise multidimensional de dados, tambm conhecida como OLAP, sua

ferramenta o PowerPlay, que dispe os dados no contexto do negcio, possibilitando o
redirecionamento imediato nas regras de atuao, quando for necessrio [UNI98].
Algumas caractersticas:
Possui recursos grficos padro Windows, os dados tambm podem ser

consultados via Internet atravs de um web browser;
Permite a visualizao de grficos e planilhas em uma mesma tela, conforme

a Figura 8.4;
Possibilita o armazenamento das estruturas multidimensionais em ambiente

PC, redes ou bases relacionais como Oracle, Informix, Sybase SQL Server,
Microsoft SQL-Server;
Possui uma ferramenta para carga de grandes volumes de dados chamada

PowerPlay Server Edition, que trabalha em ambiente UNIX (HP-UX, IBMAIX, Sun);
Programao de carga de dados em horrios ociosos.
Figura 8.4 Tela da ferramenta PowerPlay mostrando grficos e dados [UNI98].
Especificaes tcnicas:
Compatvel com ambienteWindows95, NT, Unix;
85
Carga de dados atravs de arquivos textos, planilhas de clculo (Excel e

Lotus 1-2-3), Paradox, FoxPro ou de bases relacionais atravs do software
Impromptu;
Suporte para armazenamento dos dados em Oracle, Sybase SQL-Server,

Informix ou Microsoft SQL Server;
Suporte a BDM: Essbase, Oracle Express e Informix Metacube;
Requisitos de Hardware: 16Mb RAM, 40Mb de disco rgido.
8.7.2 Maestro
A Hyper Consultoria em Informtica uma empresa de software que realiza
projetos e consultoria em sistemas de informao, oferecendo produtos e servios
especializados neste segmento de atuao. Uma importante rea de especializao da
Hyper o desenvolvimento de aplicaes de Apoio Deciso conhecidas como Data
Warehousing, Data Marts, e SIE (Sistema de Informao para Executivos). Alm disso
estabelece parcerias estratgicas com empresas de grande porte, que utilizam o Maestro,
ferramenta para desenvolvimento rpido de EIS e DSS para sistemas de apoio deciso,
que est sendo utilizado por vrias empresas multinacionais no Brasil e no exterior.
O Maestro uma ferramenta para desenvolvimento rpido de aplicaes para
apoio a deciso como programas de front-end de DW e Data Marts em ambiente
Windows e utilizando bases de dados SQL, desde servidores corporativos de centenas
de Gigabytes at notebooks, conforme ilustra a Figura 8.5. O Maestro uma ferramenta
que implementa bases de dados multidimensionais (MOLAP) em bases de dados
relacionais (ROLAP). Administra tanto dados como metadados. Suporta bases de dados
que tm algumas dezenas de milhares de linhas at bases de dados com mais de 200
milhes de linhas, aproximadamente 100Gb, em ambiente cliente/servidor. Por
exemplo: para acessar 200 linhas em um cubo com mais de 250 milhes de linhas levase menos que 5 segundos.
No preciso escrever nenhuma linha de cdigo para construir as aplicaes
front-end. Possui a maioria das funcionalidades das outras ferramentas e alguma
funcionalidades exclusivas como drill down simultneo em todas as dimenses e janelas
multidimensionais sincronizadas (permite a visualizao sincronizada de vrias
informaes da mesma dimenso).
O software Maestro divido em mdulos[HYP98]:
Manuteno de Metadados: para definio dos elementos bsicos dos
modelos, como dimenses, hierarquias, variveis, frmulas, critrios para agregao
dimensional e para comparaes, etc. Existe um dicionrio central onde ficam todas as
regras comuns para todos os Data Marts que compem o DW, e um dicionrio local
para cada Data Mart. A manuteno pode ser feita interativamente ou em arquivos de
lote (batch).
Editor de Menus e Sinalizadores: para definio de telas de navegao
(Menus) compostos de links parametrizveis para outras telas, vises ou outras
aplicaes, e para composio de sinalizadores. Sinalizadores so telas com facilidades
adicionais para mostrar dados e sinalizar comparaes atravs de bandeiras e outros
objetos coloridos, e dotadas de mecanismos para seleo dimensional de dados - combo-
86
boxes e radio-buttons. Estas telas podem usar imagens grficas como mapas, desenho
de produtos e cones.
Figura 8.5 Tela da ferramenta Maestro.

Visualizador Multidimensional: ferramenta OLAP grfica, onde os dados so
mostrados em janelas sincronizadas, em planilhas e/ou grficos 2D e 3D. As planilhas
podem usar frmulas e formatao da planilha eletrnica Microsoft Excel. Pode ser
usado em modo ad-hoc ou para mostrar vises pr-definidas.
Agregador Multidimensional: para alimentao das bases de dados e
agregao multidimensional prvia dos dados . Integrado aos dicionrios de dados,
utiliza algoritmos muito eficientes. Para bases de dados cliente-servidor faz uso dos
utilitrios rpidos de carga em batch oferecidos por estes softwares.
Sisus: mdulo de controle de acesso pelos usurios aos dados e s funes.
Utiliza sofisticados mecanismos para mapear os direitos dos usurios de acessar os
dados atravs da estrutura multidimensional e hierrquica dos dados.
DocViewer: mdulo para estruturao e acesso a bancos multidimensionais de
documentos. Documentos do tipo textos (.doc), planilhas (.xls), apresentaes (.ppt),
ajudas (.hlp), etc. so armazenados de acordo com estruturas dimensionais. Por
exemplo, em uma rede de lojas, se todo ms cada gerente de departamento em cada loja
faz um relatrio sobre o desempenho da sua rea, estes relatrios podem ser
armazenados e consultados pelo DocViewer, nas dimenses tempo e loja/departamento.
87
8.7.3 Oracle
Detentora de mais de 50% de todas as instalaes j realizadas de DW, de
acordo com relatrio recente do META Group [ORA98], a Oracle possui uma soluo
para a construo e desenvolvimento de DW. O pacote Oracle, composto pela
ferramenta Oracle Discoverer 3.0 e pela famlia de produtos Oracle Express,
compatvel com Windows NT e Unix e configura uma opo de baixo custo, totalmente
integrada, fcil de usar e instalar. A Tabela 8.2 mostra a lista de produtos
multidimensionais que a Oracle possui. Este conjunto de produtos conhecido pelo
nome de Oracle Express Tools, disponvel para os sistemas operacionais Windows 3.11
e Windows 95.
PRODUTO
Oracle Express Analyzer
Discoverer/2000
Oracle Express Data Dictionary Editor
Oracle Express Objects
Oracle Sales Analyzer
Oracle Financial Analyzer
DESCRIO
Ferramenta de anlise para usurios finais. Permite
anlises OLAP multidimensionais em geral.
Ferramenta de anlise para usurios finais. Permite
anlises em bases de dados relacionais.
Ferramenta de alto nvel para definies de objetos na
bases da dados da famlia Oracle Express.
Ferramenta para desenvolvimento de aplicaes
multidimensionais sob medida. Oracle Express
Objects uma ferramenta orientada a objetos para o
desenvolvimento de aplicaes com o Oracle Express
Server ou o Oracle Personal Express. Sua ferramenta
correspondente para bases de dados relacionais o
Developer/2000.
Ferramenta para usurios finais, especializada em
anlise de vendas. Inclui funes pr-definidas para
anlises de vendas e mercado.
Similar ao Sales Analyzer, o Oracle Financial
Analyzer, um a ferramenta para anlises OLAP
orientada para o setor financeiro.
Tabela 8.2 Produtos da famlia Oracle Express para DW [ORA98].
8.7.3.1 Oracle Discoverer 3.0

O Discoverer 3.0 uma ferramenta direcionada para o usurio final que
permite consultas, anlises, construo de relatrios e grficos. Combina a flexibilidade
da tecnologia de acesso a dados com uma interface intuitiva e de fcil uso, permitindo a
realizao de consultas e relatrios, que podem ser executados na Internet e intranets
corporativas. O Discoverer 3.0 tem como principal atributo sua facilidade de uso e
administrao, aliada a uma alta performance, que otimiza a produtividade e os recursos
de computao do usurio, especialmente no acesso a grandes bancos de dados.
Possui dois componentes principais, o Oracle Discoverer Administration e o
Oracle Discoverer Users:
88
Discoverer Administration: o componente responsvel pela preparao do

ambiente do DW. Nele o usurio estabelece as hierarquias, tabelas sumarizadas, ordem
de consulta e outros. Esse componente tambm responsvel por anlises orientadas a
performance como por exemplo o uso das tabelas sumarizadas e consultas mais
acessadas.
Discoverer Users: o componente que interage com o usurio final. Neste
componente o usurio poder criar suas prprias consultas alm de analisar consultas
prontas ou mesmo alter-las de acordo com condies de acesso estabelecidas no
Discoverer Administration.
A ferramenta Oracle Discoverer permite a consulta de informaes em vrias
dimenses. Na Figura 8.6 pode-se ver a anlise das vendas de vdeos em cada ms do
ano de 1996 por regio onde possvel visualizar os totais por cidades da regio.
Figura 8.6 Tela da ferramenta Oracle Discoverer [ORA98].

uma ferramenta ROLAP que se apresenta em 3 nveis: Nvel do Usurio Final,
Nvel do Administrador dos Sistemas de Negcios e Nvel dos Metadados. Para cada
nvel existe um conjunto de recursos que visa a facilidade de desenvolvimento e
pesquisa, bem como a preocupao com performance e bom desempenho.
Algumas caractersticas:
Fornece ao usurio final uma previso do tempo necessrio para completar

todo o processo de consulta, abrindo a possibilidade de interrupo;
Os relatrios podem ser exportados para o sistema de arquivos como HTML;
89
Possui help sensvel ao contexto e cartes de sugesto que so amostras de

como realizar determinadas tarefas;
Possui recursos grficos padro Windows. Pode acessar dados no

formatados como imagens e sons.
Criao de Consultas Pr-formuladas, onde os relatrios criados podem ser

gravados para uso posterior.
Acessa vrios bancos de dados relacionais via Open Data Base Connectivity
(ODBC) ou o prprio Oracle diretamente atravs de SQL Net.
90
9 Anlise do uso da tecnologia Data Warehouse

Desde a definio do conceito de Data Warehouse em 1990 por William
Inmon at os dias de hoje muitos estudos j foram realizados sobre DW e muitas
empresas decidiram apostar nesta nova maneira de armazenar e extrair informaes
teis para o suporte a decises. Para avaliar as vantagens e desvantagens da utilizao
de um DW foram feitos estudos sobre vrios casos de empresas que j esto utilizando
ou esto no processo inicial de construo de um DW. Uma das fontes de pesquisa
para este trabalho foi um artigo publicado pela professora Toru Sakaguchi [TOR98] da
Universidade de Memphis, EUA. Este artigo foi realizado tendo como base 456 artigos
escritos entre abril de 1992 e julho de 1996, que foram analisados e comparados para
extrair as principais vantagens e desvantagens da utilizao de um DW.
9.1
Vantagens
1) Simplicidade: A vantagem mencionada com mais freqncia sobre DW
pode se resumida como simplicidade. O DW facilita a administrao da
empresa por que fornece uma imagem simples da realidade com integrao
de vrios dados de sistemas diferentes. O DW permite que os sistemas
operacionais continuem em uso, transformando os dados inconsistentes dos
sistemas operacionais em um conjunto de dados coerentes que so
informaes vitais para as empresas. As operaes atuais podem ser
monitoradas e comparadas com as operaes passadas, previses de futuras
operaes podem ser feitas racionalmente, novos processos podem ser
inventados, e os sistemas operacionais podem ser alterados para suportar
estes processos. O DW tambm pode armazenar um grande nmero de dados
histricos que auxiliam as empresas na tomada de decises. Oferece o
benefcio de ser nico, com dados centralizados mas mantendo uma estrutura
de cliente/servidor. Alm disso, DW so sistemas para empresas grandes, o
que melhora a distribuio das informaes internamente.
2) Qualidade dos dados: A segunda vantagem mais mencionada foi a melhor
qualidade dos dados. O DW proporciona consultas em dados de maior
qualidade o que traz maior consistncia, acuracidade e documentao, alm
de aumentar a produtividade dos usurios atravs de utilizao de
ferramentas OLAP e de Data Mining.
3) Acesso rpido: O DW permite aos usurios recuperar rapidamente os dados
necessrios para suas consultas, eliminando o trabalho de busca em vrios
sistemas operacionais pois todos os dados esto em um nico local, sendo
assim o tempo de resposta deve ser reduzido.
4) Facilidade de uso: A maioria das ferramentas de consultas facilitam o
acesso aos dados pois trabalham com interfaces grficas e comandos prdefinidos o que torna a anlise das informaes armazenadas no DW uma
tarefa intuitiva para os usurios finais.
5) Separa as operaes de deciso das operaes de produo: Como os
dados do DW ficam separados dos dados dos sistemas operacionais mas so
continuamente atualizados com informaes sobre as operaes realizadas,
91
os gerentes e analistas de negcios podem fazer anlises nestes dados sem

sobrecarregar os sistemas operacionais.
6) Vantagem competitiva: O DW auxilia o administrador a gerenciar melhorar
a empresa utilizando o conhecimento incorporado, o qual possibilita a
empresa ser mais competitiva, entendendo melhor as necessidades dos
clientes, e conhecendo mais rapidamente as demandas de mercado. Esta
vantagem pode compensar o grande custo de se implantar um DW.
7) Custo de operao: O DW oferece uma boa base para o desenvolvimento
de novos sistemas operacionais, alm de eliminar o uso de arquivos baseados
em papis e uma vez coberto o investimento inicial o grupo de tecnologia da
informao da empresa normalmente consome menos recursos do que antes
da implantao do DW pois as informaes ficam centralizadas e podem ser
acessadas facilmente pelos usurios finais.
8) Administrao do fluxo da informao: O DW recebe uma grande
quantidade de dados de vrias fontes operacionais e envia dados para vrias
aplicaes front-end. Para se adaptarem as mudanas nas regras de negcio
das empresas, os sistemas operacionais e as estruturas dos dados so
constantemente modificados. No DW isto dificilmente ocorre pois os
metadados auxiliam na configurao dos dados para que eles atendam os
novos requisitos da empresa.
9) Habilita o processamento paralelo: O processamento paralelo ajuda os
usurios a realizar consultas no DW mais rapidamente, pois suporta grandes
demandas em ambientes cliente/servidor, onde os usurios podem fazer
perguntas ou consultas simultneas que exijam um processamento intensivo,
com o processamento paralelo o DW oferece uma melhor relao de
preo/performance .
10) Infra-estrutura computacional: O DW ajuda as organizaes a montar
uma infra-estrutura que pode suportar mudanas nos sistemas operacionais e
na estrutura dos seus negcios.
11) Valores quantitativos: Outra vantagem que o DW pode mostrar um
retrospecto realista da evoluo da empresa pois possui medidas
quantitativas que podem ser comparadas e analisadas com perodos de vrios
anos.
12) Segurana: O fato dos usurios do DW no acessar diretamente as bases de
dados dos sistemas operacionais, aumenta a segurana destes dados alm de
diminuir o nmero de acessos aos mesmos.
9.2
Desvantagens
1) Complexidade de desenvolvimento: Uma empresa no pode simplesmente
comprar um DW. necessrio construir um ambiente composto de
hardware e software como banco de dados, ferramentas de extrao de
dados, ferramentas de recuperao dos dados, etc. Um DW deve atender as
necessidades especficas de uma empresa, na construo deste ambiente
especfico necessrio ter muito conhecimento das necessidades prdefinidas para a construo da estrutura, definies e fluxo dos dados, assim
92
como na escolha do hardware e software necessrios. O desenvolvimento de

um DW requer um senso de antecipao sobre as necessidades futuras dos
usurios assim como a previso de futuras alteraes nas regras de negcio
da empresa. Definir como aumentar o DW por causa da demanda de dados,
tanto em volume com em complexidade torna o seu desenvolvimento muito
complexo e requer uma equipe de especialistas.
2) Tempo de desenvolvimento: Como uma tarefa complexa natural que
tambm seja demorada. Estudos indicam que em mdia um ambiente
completo de DW demora de dois a trs anos para ficar pronto, o que pode ser
muito tempo para uma empresa que necessita de um ambiente de suporte a
deciso em um curto espao de tempo.
3) Alto custo de desenvolvimento e administrao: um DW pode consumir
milhares de dlares at que esteja pronto para ser utilizado e continuar a
consumir recursos durante toda sua vida til, pois necessitar de constantes
manutenes;
4) Treinamento: Um das desvantagens que os usurios do DW devem ser
constantemente treinados e comunicados das mudanas no DW. Isto se deve
ao fato de que importante que todos estejam aptos a retirar o mximo de
informaes possveis que o DW oferece.
As vantagens mostradas acima mostram que necessrio comear um DW com
uma estrutura de dados simples, procurando facilitar o acesso aos dados e otimizando o
tempo de resposta. importante dar nfase na seleo dos dados pois dados com
qualidade melhoram a produtividade e a busca de decises mais certas. Por outro lado
as desvantagens mostram que nem todas as empresas podem construir um DW, umas
por serem pequenas e consequentemente no terem o suporte financeiro necessrio e
outras por no terem o tempo necessrio para a concluso de todo o projeto. Para estas
empresas interessante avaliar a possibilidade de comear o desenvolvimento do DW
atravs de pequenos Data Marts departamentais que alm de terem um custo muito
inferior ao DW tambm podem ser construdos em poucos meses.
9.3 Dificuldades de desenvolvimento

Durante o desenvolvimento de um DW muitas dificuldades so encontradas,
algumas destas dificuldades e problemas foram identificadas durante o desenvolvimento
deste trabalho.
Dificuldades na hora de coletar e integrar os dados: as empresas tm

sistemas espalhados por vrios departamentos, alguns deles com funes
especficas, e elas tm que extrair dados de cada um deles e consolidar dentro de
DW, isto pode ser um grande problema quando estes sistemas esto escritos em
linguagens diferentes e rodam em plataformas diferentes.
Falta de padronizao dos dados: Se as fontes dos dados esto espalhadas em
diversos sistemas e estes sistemas foram desenvolvidos por pessoas diferentes
muito provvel que no exista nenhum padro entre seus dados.
Inconsistncia das informaes: Mesmo quando existem poucas fontes de
dados para o DW provvel que alguns destes dados estejam inconsistentes,
esta inconsistncias podem ser geradas por perda de parte dos dados ou por falta
de regras de integridade referencial que algumas linguagens no suportam.
93
Dimensionamento de CPUs e discos: A definio dos recursos

computacionais para o suporte a um DW uma tarefa difcil, pois mesmo
mantendo muitos dados armazenados necessrio que ele tenha agilidade para
responder as consultas dos usurios.
Resistncia dos usurios: Alguns usurios podem tronar-se resistentes a
utilizao de uma nova ferramenta, um exemplo pode ser a no utilizao de
papel, pois as ferramentas de front-end normalmente mostram as informaes na
tela do computador dando vrias possibilidades de perspectivas de vises dos
dados que no so conseguidas em relatrios.
9.4 Exemplos
Atravs dos novos conceitos da Tecnologia da Informao, o DW comea a
conquistar espao nas grandes empresas nacionais onde est sendo considerado como
uma segunda reengenharia pela qual as companhias devem passar para se tornarem mais
competitivas e globalizadas.
O DW j mostra seus primeiros resultados, mesmo estando em processo de
implementao na maioria das empresas. O primeiro deles a capacidade de oferecer
informaes precisas e atualizadas para diferentes unidades de negcios dentro das
companhias. A contrapartida a essa autonomia tem sido uma independncia maior em
relao rea de informtica, que deixa de se responsabilizar por algumas funes tais
como a implementao de consultas especficas e a emisso de relatrios.
Nos itens abaixo est a descrio sucinta dos projetos de DW desenvolvidos por
algumas empresas nacionais.
Banco Amrica do Sul: Implantou um projeto-piloto que funciona nas reas de
crdito e marketing, cobrindo dados histricos dos ltimos trs anos. O sistema utiliza
banco de dados Informix, roda em equipamento NumaQ da Sequent, para extrair as
informaes usa o software Prism Warehouse Executive e os relatrios gerenciais so
acessados pelo Business Object para manipulao de dados e rene quatro terabytes de
dados. A previso concluir a soluo, envolvendo todo o banco, em 1999, a um custo
de US$ 10,8 milhes [COM97].
Companhia Siderrgica Nacional: Est em fase inicial e se prope a cobrir
produo e a carteira de encomendas, totalizando 30 GB de informaes. Previsto para
comear a funcionar em julho 1998, o sistema ainda est parado por causa de
problemas no tempo de processamento. O projeto, cujo valor no foi divulgado,
emprega banco de dados Oracle 7 e uma mquina HP 460 com 2GB de memria e
100GB de disco. A arquitetura foi planejada em forma de pirmide, com os sistemas
operacionais na base, suportando o DW, o Decision Suport Systems (DSS) e o Executive
InformatonSystem (EIS) na parte superior [COM97].
Latasa: Criou um Data Mart, cujo investimento estimado em US$ 50 mil de
1995 at o incio de 1998, contm 10 variveis sobre os negcios da empresa. Usado
pela rea de marketing, opera numa rede Windows NT com SQL Server, rodando num
servidor Compaq srie 5000, com 256 Mb de memria e 20 GB de disco. A idia levar
a tecnologia para as reas industrial e financeira [COM97].
Lobrs: Desenvolveu um DW basicamente usado pelo departamento comercial.
Envolve dados de maro de 1996 em diante. Conta com 12 GB de informaes, sendo 8
GB das Lojas Brasileiras e 4 GB das lojas Marisa. Trabalha com uma rede Windows NT
94
com SQL Server 6.5. O hardware um servidor IBM com dois processadores Pentium
Pro. O investimento no projeto de US$ 300 mil e est ajudando a empresa a saber
com exatido o movimento das vendas de seus mais de 21.500 produtos [COM97].
Serpro: O DW necessrio para abranger despesas de pessoal, arrecadao,
comrcio exterior e dvida ativa, j consumiu um investimento de US$ 4 milhes e
armazena 105 GB de informaes. O sistema opera com Oracle 7 e tem como hardware
um AlphaServer de 64 bits da Digital com sistema operacional Unix, 2 GB de
memria e 150 GB de disco. Aps concluso do DW considerado estratgico pelo
governo federal, o rgo planeja implantar um sistema de data minig, para auxiliar na
identificao de fraudes [COM97].
Avon: Uma das maiores empresas de cosmticos do mundo, a Avon est em
fase de desenvolvimento de um projeto denominado Global Communications Network
que vai integrar as unidades presentes em 131 pases, com investimentos avaliados em
US$ 25 milhes. Uma das partes deste projeto a criao de um data mart na rea de
Marketing que est sendo desenvolvido no centro de desenvolvimento tecnolgico
localizado na Inglaterra. Baseado no banco de dados Oracle 7 e na ferramenta de data
mining da Cognos, o projeto vai permitir explorar melhor o perfil de consumo dos
clientes. As informaes estaro disponveis para o circuito gerencial, sendo o passo
inicial para a empresa evoluir at um amplo projeto de DW [COM97]
Ita: O banco Ita foi um dos pioneiros no uso de DW no Brasil. Seu objetivo
na poca da implantao do DW era filtrar suas correspondncias que eram enviadas pra
mais de 1 milho de correntistas mas somente 2% se interessavam pelas promoes e
novidades. Com a utilizao do DW o ndice de retorno foi para 30% . Hoje cerca de
1000 pessoas de vrios departamentos utilizam as informaes contidas no DW, que
rene 1 terabyte de dados [INF97].
95
10 Concluso
A tecnologia de DW mostra-se muito interessante para empresas que possuem
grandes volumes de dados gerados e acumulados durante sua existncia e necessitam
recuperar estes dados de uma forma que eles possam auxiliar os administradores destas
empresas a tomarem decises estratgicas rapidamente e com segurana.
Apesar de possuir uma arquitetura relativamente simples, os processos de
extrao, filtragem, carga e recuperao dos dados so bastante complexos, exigindo
que pessoas altamente capacitadas faam parte do projeto para que os objetivos sejam
atingidos no menor espao de tempo possvel e sem o gasto de recursos
desnecessariamente.
Como o DW no um sistema ou programa, mas sim um ambiente que
necessita ser adaptado as necessidades, muitas vezes especficas, das empresas normal
que cada ambiente de DW possua caractersticas prprias, inviabilizando seu uso para
outros objetivos que no os descritos no incio do projeto.
Os custos envolvidos no projeto do DW podem a princpio no serem
justificveis o que pode levar a concluso de que melhor comear o projeto com um
escopo menor, definindo-se Data Marts departamentais e depois integr-los em um
nico DW quando os objetivos iniciais j tiverem sido alcanados.
Para a informtica o ambiente de DW mostrou ser um desafio aos processos que
normalmente so utilizados para desenvolver um software. Um dos desafios conseguir
modelar os dados de maneira que todas as informaes estejam disponveis de forma
clara e rpida para os usurios que a esto requisitando, outro desafio disponibilizar as
informaes sobre os dados (metadados), para que os usurios possam saber quais
informaes esto disponveis, de onde vieram, para onde vo, etc.
Tambm pode ser considerado um desafio aos profissionais de informtica a
definio dos requisitos necessrios para disponibilizar os dados do DW, j que eles so
histricos e crescem indefinidamente consumindo rapidamente a capacidade de
armazenamento e de processamento dos computadores atuais.
Como esta monografia teve o objetivo de fazer um estudo sobre o ambiente de
DW possvel aprofundar muitos tpicos aqui desenvolvidos ou desenvolver assuntos
no abordados neste trabalho. Como sugesto para futuros trabalhos, pode-se citar as
seguintes:
Um estudo mais aprofundado sobre os modelos de dados existentes e a
definio de um modelo timo para a construo do ambiente de DW,
Um estudo completo sobre metadados, sua estrutura, como defini-los, como
apresenta-los de forma amigvel aos usurios para que estes possam utilizlos da melhor forma possvel, etc.;
Um estudo sobre os algoritmos e as ferramentas de extrao, limpeza,
transformao e integrao dos dados operacionais e fontes externas;
A comparao das diversas ferramentas existentes para o acesso aos dados
do DW, comparando suas funcionalidades e necessidades de armazenamento,
alm de diferenciar seus atributos e suas caractersticas.
96
O desenvolvimento em forma de um prottipo um DW para uma empresa,

onde poderia se avaliar na prtica quais so as dificuldades encontradas durante
o projeto e os benefcios que o DW proporcionas aos Sistemas de Apoio a
Deciso.
Por fim, importante destacar que este trabalho contribuiu muito para a
ampliao dos conhecimentos do autor em relao aos ambientes de suporte a deciso.
O que com certeza poder ser aplicado na sua futura vida profissional, pois a empresa
onde trabalha produz sistemas de gesto empresarial com o uso de banco de dados, e
ser muito interessante para seus clientes contarem com um ambiente que integre, filtre
e disponibilize de forma analtica as informaes geradas diariamente pelos sistemas
operacionais da empresa.
97
Bibliografia
[ADE97]
ADELMAN, S. e LEBARON, M. - Meta Data Standards, Review

Magazine, Dezembro 1997.
[BAR96]
BARQUINI, RAMON - Planning and designing the Warehouse,

New Jersey, Prentice-Hall, 1996, 311 pg.
[BAT86]
BATINI, C. e LENZERINI, M. Comparative Analysis Of

Methodologies For Database Schema Integration,
ACM
Computing Surveys, New York, v.18, n 4, pg.323-364, Dezembro
1986.
[BAU97]
BAUER, A. e LEHNER, W. - The Cube-Query-Language (CQL) for

Multidimensional Statistical and Scientific Database Systems,
International Conference On Database Systems For Advanced
Applications, Melbourne, Australia, pg.263-272, Maio 1997.
[BOH97] BOHN, K. Convering Data for Warehouses DBMS, Califrnia,

Junho 1997.
[CAM97] CAMPOS, MARIA LUIZA e ROCHA, ARNALDO V. Data
Warehouse, XVII Congresso da Sociedade Brasileira de
Computao, XVI Jornada de Atualizao em Informtica, Rio de
Janeiro, 1997, 261 pg.
[CEL95]
CELKO, J. e MCDONAL, J. Don't Warehouse dirty data.

Datamation, New York, Outubro 1997.
[CHA97] CHAUDHURI, S. e DAYAL, U.

An Overview of Data
Warehousing and Olap Tecnology, SIGMOD Record, New York,
v.26, n 1, pg.65-74, Maro 1997.
[COD95] CODD, E. F. Twelve Rules for On Line Analytical Processing,
Computerworld, Abril 1995.
[COM97] Revista Computerworld, Revista de computao, disponvel na
Internet via protocolo http, no endereo http://www.computerworld.
com.br - Edio 221 - Agosto 1997, data do ltimo acesso
28/10/1998.
[DAR96] DARLING, C. How to integrate your Data Warehouse.
Datamation, New York, v.42, n 10, pg.40-51, Maio 1996.
[FLO97]
FLOHR, U. OLAP by Web. Byte, Peterborough, v.22, n 9, pg.8184, Setembro 1997.
98
[GEL96]
GELMAN, S. e PECK, D. Bringing Business Information to

AT&T Network Systems Through a Data Warehouse. AT&T
Technical Journal, New York, v.75, n 2, pg.60-78, Abril 1996.
[HAC95] HACKATHORN, R. Data Warehousing Energizes Your

Enterprise. Datamation, New York, v.41, n 02, pg.38-43,
Fevereiro 1997.
[HAR96] HARJINDER, G. e RAO, P. C. The Officil Guide to Data
Warehousing, Que Corporation, 1996.
[HYP98]
Hyper Consultoria, site sobre a empresa Hyper Consultoria que

presta servios de consultoria em Sistemas de Apoio Deciso,
disponvel na Internet via protocolo http, no endereo
http://www.hyperinf.com.br/maestro.htm, data do ltimo acesso
15/11/1998.
[IDG98]
Revista IDG, Revista de computao, disponvel na Internet via

protocolo http, no endereo http://www.Iidgnow.com.br - Edio
237 - Outubro 1998, data do ltimo acesso 20/11/1998.
[INF97]
Revista Informtica Exame Big Brother no reclamaria, Ano 12,

Nro.139, pg.128, Outubro 1997.
[INM93]
INMON, W.H. Information System Arquiteture: Development in

90s., John Wiley & Sons Inc., New York, 1993.
[INM96]
INMON, W.H. Building the Data Warehouse, John Wiley & Sons
Inc., New York, 1996.
[INM97]
INMON, W.H. Como Construir o Data Warehouse, Campus, Rio

de Janeiro, 1997, 387 pg.
[INM97a] INMON, W.H. & RICHARD D. HACKATHORN Como Usar o Data

Warehouse, Infobook, Rio de Janeiro, 1997.
[KIM95]
KIMBALL, RALPH Is E-R Modeling Hazardous to DSS?, DBMS,

Outubro 1995.
[KIM96]
KIMBALL, RALPH The Data Warehouse Toolkit, John Wiley &

Sons Inc., New York, 1996.
[KIM97]
KIMBALL, RALPH
Agosto 1997.
Dimensional Modeling Manifesto, DBMS,
[MCG98] McGUFF, FRANK, Designing the Perfect Data Warehouse

Hitchhiker's Guide to Decision Support, disponvel na Internet via
protocolo http, no endereo
http://members.aol.com/fmcguff/
dwmodel, data do ltimo acesso 22/11/1998.
[MOR98] Moraes, Rodrigo Leal Esta pgina contm informaes sobre os
Sistemas de Data Warehouse e assuntos relacionados, disponvel
99
na Internet via protocolo http, no endereo http://www.inf.ufrgs.br/

~rlmoraes/dw.html, data do ltimo acesso 10/09/1998.
[ONE97] ONEIL, B. Oracle Data Warehousing. Indianapolis, Sams
Publishing, 1997.
[ORA98] Oracle Site sobre a empresa e seus produtos, disponvel na
Internet via protocolo http, no endereo http://www.oracle.com.br
data do ltimo acesso 22/11/1998.
[ORL96] ORLI, R. J. Data Extraction, Transformation and Migration
Tools, disponvel na Internet via protocolo http, no endereo
http://www.kismeta.com/ ex2.html,
data do ltimo acesso
21/11/1998.
[ORR96] ORR, KEN. Data Warehouse Technology, The Ken Orr
Institute 1996, disponvel na Internet via protocolo http, no
endereo http://www. kenorrinst.com/datawh.html, data do ltimo
acesso 2/10/1998.
[RAD96] RADEN, N. Technology Tutorial Modeling a DataWarehouse
Value to organization means turning data into actionable
information, Information Week, Issue 564, Janeiro 1996.
[RIB95]
RIBEIRO, C. Bancos de Dados Heterogneos - Mapeamento

dos Esquemas Conceituais em um modelo Orientado a Objetos,
Tese de Doutorado, Porto Alegre, CPGCC da UFRGS, 1995.
[SPR91]
SPRAGUE, H. e WATSON, J. Sistema de apoio a deciso:

colocando a teoria em prtica. Ed. Campus, Rio de Janeiro,
1991, 497 pg.
[TOR98] TORU, SAKAGUCHI A Review of the Data Warehousing

Literature, University of Memphis, 1998, disponvel na Internet
via protocolo http, no endereo http://www.people.memphis.edu/
~tsakagch/dw-web.htm, data do ltimo acesso 5/11/1998.
[UFR98] Universidade Federal do Rio de Janeiro, site do Mestrado em
Informtica UFRJ, disponvel na Internet via protocolo http, no
endereo http://tartaruga.nce.ufrj.br/dw, data do ltimo acesso
22/11/1998.
[UNI98]
Uniplace Sistemas de Informaes, site sobre a empresa Uniplace

que especializada em projetos para Sistemas de Apoio
Deciso, disponvel na Internet via protocolo http, no endereo
http://www.uniplace.com.br/pagPowerplay.html, data do ltimo
acesso 17/10/98.
[VAL96]
VALENTE, DAPHNIS LOPES Estudo sobre Armazm de Dados,

CPGCC da UFRGS, Porto Alegre, 1996, 56 pg.
100
[WEL97] WELDON, J.L. Warehouse Cornerstones, Revista Byte, v.22, n

1, Janeiro 1997.
[WHE96] WHETZEL, J. Integrating World Wide Web and Database
Technology. AT&T Technical Journal, New York, v.75, n 2,
Maro 1996.
[WIL97]
WILLIAMS, J. Tools for Traveling Data. DBMS, Califrnia, Junho

1997.

Um Estudo Sobre Data Warehouse

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

Um Estudo Sobre Data Warehouse

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade de Caxias do Sul

Cento de Cincias Exatas e Tecnologia

Um Estudo sobre Data Warehouse

Profa. MSc. Carine Geltrudes Webber

CARACTERSTICAS DO DATA WAREHOUSE .................................................................... 15

ARQUITETURA DO DATA WAREHOUSE ............................................................................ 25

DESENVOLVIMENTO DO DATA WAREHOUSE ................................................................. 56

POVOANDO UM DATA WAREHOUSE ................................................................................ 70

EXTRAO DOS DADOS DO AMBIENTE OPERACIONAL............................................................... 70

EXTRAO DE INFORMAES DO DATA WAREHOUSE ............................................... 75

ANLISE DO USO DA TECNOLOGIA DATA WAREHOUSE.............................................. 90

Banco de Dados Multidimensional

FIGURA 2.1 COMPONENTE DE UM DATA WAREHOUSE. ........................................................................... 14

O ambiente de dados para suporte aos processos de gerncia e tomada de deciso

The database environment supporting management and decision support systems

no processamento paralelo e na tecnologia distribuda, finalmente a tecnologia da

Condies dos dados

Tabela 2.1 Comparao entre Banco de Dados Operacionais e Data Warehouse.

Figura 2.1 Componente de um Data Warehouse.

3 Caractersticas do Data Warehouse

3.1 Orientao por assunto

Figura 3.1 Integrao dos dados.

3.3 Variao no tempo

Figura 3.2 Forma geral da localizao dos dados em um DW.

3.6 Credibilidade do dados

exemplo. "Se voc tem dados de m qualidade e os disponibiliza em um DW, o seu

Grau de informaes que Percentual de correo.

Grau de dados requisitados e Percentual atendimentos.

Consistncia dos dados /

Coerncia lgica que permite Percentual de regras de

Tempo entre o pedido de Relao entre a

Singularidade dos dados de Percentual dos dados que

Tabela 3.1 Conjunto de caracterstica da qualidade de dados.

Figura 3.3 Nveis de granularidade.

Os dados altamente resumidos so compactos e devem ser de fcil acesso, pois

Figura 3.4 Nveis duplos de granularidade para dados resumidos.

3.8.1 Fontes de metadados

de acesso de informaes por usurios, so informaes interessantes de se manter, que

4 Arquitetura do Data Warehouse

4.1 Arquitetura Genrica de Data Warehouse

Camada de acesso aos dados: Esta camada faz a ligao entre as

Figura 4.1 Arquitetura do ambiente de DW [ORR96].

4.2 Arquitetura segundo Chaudhuri

Figura 4.2 Componentes de arquitetura de um DW segundo Chaudhuri [MOR98].

Figura 4.3 O fluxo de dados no sistema [MOR98].

O quarto fluxo o de sada dos dados (outflow), cuja funo disponibilizar

4.2.1 Fontes de dados internas

4.2.2 Fontes de dados externas

4.3 Arquitetura segundo Valente

4.3.1 Extrao dos dados

processamentos necessrios para integrar os dados no DW, durante este processo o

Figura 4.4 Arquitetura bsica de um DW [VAL 96].

4.3.3 Processamento de informaes

Definio das consultas: O usurio deve definir a consulta de forma a

4.4 Outras arquiteturas

4.4.1 Arquitetura de duas camadas

Figura 4.5 Arquitetura de duas camadas.

4.4.2 Arquitetura de trs camadas

conhecido como On-line Transaction Processing (OLTP). Bancos de dados para DW

Figura 4.6 Arquitetura de trs camadas.

5.1 Modelo de dados segundo R.Kimball

5.1.1 Modelo empresarial

Estas questes iro ajudar a descobrir quais so os dados relevantes para o DW e

Os caminhos cclicos devem ser eliminados pois a maioria das ferramentas