um estudo sobre data warehouse
DESCRIPTION
Estudo sobre DWTRANSCRIPT
-
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
-
2
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
-
3
Sumrio
NOMINATA ......................................................................................................................................... 2
SUMRIO ............................................................................................................................................ 3
LISTA DE ABREVIATURAS.............................................................................................................. 5
LISTA DE FIGURAS ........................................................................................................................... 6
LISTA DE TABELAS .......................................................................................................................... 7
RESUMO .............................................................................................................................................. 8
ABSTRACT .......................................................................................................................................... 8
1 INTRODUO ......................................................................................................................... 10
2 CONCEITOS............................................................................................................................. 12
3 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
4 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
5 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
-
4
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
7 POVOANDO UM DATA WAREHOUSE ................................................................................ 70
7.1 EXTRAO DOS DADOS DO AMBIENTE OPERACIONAL............................................................... 70
7.2 FILTRAR, TRANSFORMAR E INTEGRAR OS DADOS EXTRADOS ................................................... 71
7.3 FERRAMENTAS PARA EXTRAO DOS DADOS OPERACIONAIS ................................................... 72
8 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
9 ANLISE DO USO DA TECNOLOGIA DATA WAREHOUSE .............................................. 90
9.1 VANTAGENS .......................................................................................................................... 90
9.2 DESVANTAGENS .................................................................................................................... 91
9.3 DIFICULDADES DE DESENVOLVIMENTO ................................................................................... 92
9.4 EXEMPLOS ............................................................................................................................. 93
10 CONCLUSO ........................................................................................................................... 95
BIBLIOGRAFIA ................................................................................................................................ 97
-
5
Lista de Abreviaturas
BDM Banco de Dados Multidimensional
DSS Decision Support System
DW Data Warehouse
E-R Entidade/Relacionamento
EIS Executive Information System
ERP Enterprise Resource Planning
HTML Hyper Text Markup Language
MOLAP Multidimensional On-line Analytical Processing
MPP Massively Parallel Processing
ODBC Open Data Base Connectivity
OLAP On-line Analytical Processing
OLTP On-line Transaction Processing
ROLAP Relational On-line Analytical Processing
SAD Sistemas de Apoio Deciso
SGBD Sistema Gerenciador de Banco de Dados
SMP Symetric Parallel Processing
-
6
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
-
7
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
-
8
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.
-
9
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,
1 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
Caractersticas Bancos de dados
Operacionais Data Warehouse
Objetivo Operaes dirias do negcio Analisar o negcio
Uso Operacional Informativo
Tipo de processamento OLTP OLAP
Unidade de trabalho Incluso, alterao, excluso Carga e consulta
Nmero de usurios Milhares Centenas
Tipo de usurio Operadores Comunidade gerencial
Interao do usurio Somente pr-definida Pr-definida e ad-hoc
Condies dos dados Dados operacionais Dados Analticos
Volume Megabytes gigabytes Gigabytes terabytes
Histrico 60 a 90 dias 5 a 10 anos
Granularidade Detalhados Detalhados e resumidos
Redundncia No ocorre Ocorre
Estrutura Esttica Varivel
Manuteno desejada Mnima Constante
Acesso a registros Dezenas Milhares
Atualizao Contnua (tempo real) Peridica (em batch)
Integridade Transao A cada atualizao
Nmero de ndices Poucos/simples Muitos/complexos
Inteno dos ndices Localizar um registro Aperfeioar consultas
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 utiliz-
las 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.
Figura 3.1 Integrao dos dados.
Ambiente operacional Data warehouse
Aplicao A M, F Aplicao B H, M Aplicao C 0, 1
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
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
M E T A D A D O
S
Dados altamente resumidos
Dados levemente
resumidos
Dados detalhados atuais
Dados detalhados
antigos
-
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
esto corretas.
Percentual de correo.
Abrangncia Grau de dados requisitados e
atendidos.
Percentual atendimentos.
Consistncia Consistncia dos dados /
liberdade de contradio.
Percentual de condies
satisfeitas.
Coerncia Coerncia lgica que permite
criar relaes entre os dados.
Percentual de regras de
integridade referencial
suportadas.
Tempo de resposta Tempo entre o pedido de
consulta e a resposta.
Relao entre a
complexidade e o tempo
gasto para resposta.
Singularidade Singularidade dos dados de
mesma natureza.
Percentual dos dados que
tm valores dentro dos
domnios de valores
permitidos.
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.
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.
Produto Data Qtd. Valor A1 13/9/98 10 100,00 B1 14/9/98 15 150,00 A1 16/9/98 20 200,00 A1 16/9/98 90 890,00 ........
Ms/Ano Produto Qtd. Valor 09/98 A1 120 1190,00 09/98 B1 15 150,00
Baixa
Nveis de Granularidade
Alta
-
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.
Primeira Camada Segunda Camada
Dados resumidos por produto Dados detalhados por produto
Produto A1 maio/1998 Produto A1
Valor total: R$ 1.270,00 02/5/1998- Valor R$ 100,00 Quantidade 20
Quantidade total: 254 09/5/1998- Valor R$ 50,00 Quantidade 10
Valor mdio: R$ 5,00 12/5/1998- Valor R$ 125,00 Quantidade 25 20/5/1998- Valor R$ 350,00 Quantidade 70
22/5/1998- Valor R$ 110,00 Quantidade 22
29/5/1998- Valor R$ 320,00 Quantidade 64
.........
Figura 3.4 Nveis duplos de granularidade para dados resumidos.
Dados Resumidos
Primeira Camada
Segunda camada
-
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.
Figura 4.2 Componentes de arquitetura de um DW segundo Chaudhuri [MOR98].
Data Warehouse
(SGBD)
Componente back-end
Componente front-end
Repositrio de metadados
Fontes internas
Fontes externas
-
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:
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. Deve-
se 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 pr-
determinados, 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.
Repositrio de metadados
Downflow
Data Warehouse
Componente back-end
Componente front-end
Fontes internas
Fontes externas
Dados antigos
Outflow
Upflow
Inflow
Metaflow
-
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.
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:
Base de
dados Base de
dados
Base de
dados
Integrador
Extrator Extrator Extrator
Data warehouse
Consultas
-
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
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
Servidor Principal
DW
Sistema Operacional BD
Sistema Operacional BD
Sistema Operacional BD
-
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).
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.
Servidor
de aplicaes
Sistema Operacional BD
Sistema Operacional BD
Sistema Operacional BD
Servidor
de BD p/DW
DW
BD
Aplicaes front-end
Aplicaes front-end
Aplicaes front-end
-
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 armazena