UNIVERSIDADE PRESBITERIANA MACKENZIE

Faculdade de Computao e Informtica

A MODELAGEM DE DADOS
NO AMBIENTE DATA WAREHOUSE

Daniele Del Bianco Hokama

Denis Camargo
Francine Fujita
Joo Luiz Valentim Fogliene

So Paulo
2004

Daniele Del Bianco Hokama

Denis Camargo
Francine Fujita
Joo Luiz Valentim Fogliene

A MODELAGEM DE DADOS NO AMBIENTE DATA WAREHOUSE

Trabalho de Graduao Interdisciplinar

apresentado Faculdade de Computao e
Informtica, da Universidade Presbiteriana
Mackenzie, como exigncia parcial para a
obteno do grau de Bacharel em Sistemas
de Informao

Orientador: Prof. ROGRIO OLIVEIRA

So Paulo
2004

SUMRIO
INTRODUO

................................................................................................

1 - AMBIENTE DATA WAREHOUSE

1.1 Conceitos

.............................................................

12

.......................................................................................................

12

1.2 ETL Extrao, Transformao e Carga

1.2.1 Extrao

09

.......................................................

15

.......................................................................................................

16

1.2.2 Transformao de dados

............................................................................

17

1.2.3 Carga de dados

...........................................................................................

18

1.3 Modelo de dados

...........................................................................................

19

.....................................................................................

20

..................................................................................

22

1.3.1 Modelo Relacional

1.3.2 Modelo Dimensional

1.3.3 A escolha da modelagem

............................................................................

2 - A MODELAGEM DIMENSIONAL

.............................................................

28

......................................................................

28

...........................................................................................

32

........................................................................................

34

2.1 Exemplo de Modelos de dados

2.2 Esquema Estrela

24

2.2.1 Tabela de Fatos

2.2.2 Modelagem da Tabela de Fatos

...................................................................

37

...............................................................................

38

..................................................................................

38

2.2.3 Classificao dos Fatos

2.2.4 Tabela de Dimenso

2.2.5 Hierarquia de Dimenses

2.2.6 Drill-down e Roll-up

............................................................................

40

..................................................................................

42

2.2.7 Dimenses Descaracterizadas

...................................................................

44

...............................................................................

45

................................................................................................................

48

3 - TCNICAS DE MODELAGEM DIMENSIONAL ........................................

51

3.1 Granularidade

51

2.3 Esquema Floco de Neve

2.4 Cubo

.................................................................................................

3.1.1 Nveis duais de granularidade

3.1.2 Tabelas Agregadas
3.2 Vises materializadas

...................................................................

52

.....................................................................................

53

..................................................................................

56

3.3 Tcnicas de Rastreamento de Alteraes

3.3.1 Sobrescrever o valor

.......................................................

57

..................................................................................

57

3.3.2 Adicionar uma nova linha na tabela de dimenses

......................................

58

....................................................

60

.....................................................................................

60

3.3.3 Adicionar uma nova coluna de dimenso

3.3.4 Artefatos de dados

3.4 Criao de Minidimenses

3.5 Criao de Novas Chaves

............................................................................

61

...............................................................................

64

3.6 Tratamento de Dimenses e Fatos com Cardinalidade M:N

..........................

66

...............................................................................

67

3.8 Dados desnormalizados

..................................................................................

70

3.9 Dimenses de tempo

..................................................................................

72

3.7 Tabela de fatos sem fatos

4 QUESTES SOBRE ACESSO A DADOS MULTIDIMENSIONAIS

.......

76

4.1 Estratgias de Processamento de Consultas ....................................................

76

4.1.1 ndices bitmap

77

..............................................................................................

4.1.2 ndices com juno

.....................................................................................

79

4.1.3 Junes estrela (Star Join) ............................................................................

81

4.2 Operador CUBE na Agregao Relacional

....................................................

82

.....................................................................................

83

4.2.1 Agregao no SQL

4.2.2 Problemas com o group by

......................................................................

84

...........................................................................................

87

4.3 Manuteno de Vises .....................................................................................

92

4.3.1 Informaes Completas

...............................................................................

96

4.3.2 Informaes Parciais .....................................................................................

100

CONCLUSO

.......................................................................................................

103

GLOSSRIO

.......................................................................................................

105

4.2.3 Operador CUBE

REFERNCIAS BIBLIOGRFICAS

................................................................

108

BIBLIOGRAFIA COMPLEMENTAR

................................................................

109

APNDICE A OLAP (Processamento Analtico On-line)

................................

110

LISTA DE QUADROS
Quadro 1 Requisitos de processamento transacional e analtico ......24
Quadro 2 Diferenas entre OLAP e OLTP ...25

LISTA DE FIGURAS
Figura 1

Ambiente de Data Warehouse 16

Figura 2

Modelo relacional do sistema transacional de vendas de lojas de

Departamento 29

Figura 3

Modelo dimensional do sistema analtico de Vendas de Lojas de

departamento ..31

Figura 4

Representao da estrutura do Esquema Estrela. 33

Figura 5

Tabela de fatos Vendas ..36

Figura 6

Tabela de dimenso Produtos .39

Figura 7

Hierarquia explcita de Produto ... 41

Figura 8

Hierarquia implcita para Produto ..42

Figura 9

Exemplo de drill-down, detalhando uma informao de data e

roll-up, sintetizando a informao ......43

Figura 10

Drill-down e drill-across de OLAP .44

Figura 11

Dimenso descaracterizada cdigo da venda na tabela de fatos

vendas .45

Figura 12

Modelo de Dados do sistema de vendas de lojas de departamento

utilizando o esquema floco de neve ...46

Figura 13

Modelo de dados floco de neve com as dimenses normalizadas

se relacionando diretamente com a tabela de fatos .......48

Figura 14

Exemplo de um cubo aplicado ao sistema de vendas de uma

rede de lojas de departamento ..49

Figura 15

Tabela de fatos Vendas e duas tabelas agregadas originadas

da agregao da tabela Vendas ....53

Figura 16

Alterao de dimenso sobrescrevendo o valor antigo

Figura 17

Alterao de dimenso por insero de novo registro 59

Figura 18

Rastreamento de alteraes por meio de artefatos de dados ..61

Figura 19

Minidimenso DEMOGRFICA .......................62

Figura 20

Exemplo de linhas de uma minidimenso de dados demogrficos .63

Figura 21

Chave substituta cdigo da loja na tabela de dimenso Lojas no

lugar da chave original nmero da loja ....65

...58

Figura 22

Chave substituta cdigo do produto para economizar espao em

disco da chave original cdigo de barras .66

Figura 23

Tabela de fatos sem fatos Produtos a Venda ..68

Figura 24

Dados desnormalizados na tabela de dimenso Produtos . 71

Figura 25

Tabela de dimenso Data se relacionando com a tabela de fatos

vendas no modelo do sistema de vendas de lojas de departamento,
o que permite a visualizao dos fatos por diversos critrios
diferentes de data 73

Figura 26

Exemplo de linhas em uma dimenso Data, a primeira linha

corresponde a data "16/02/2004" e a segunda a "21/04/2004" .74

Figura 27

Dimenso Data com diversos atributos, todas as interpretaes

de datas teis para o negcio devem ser armazenadas ..75

Figura 28

Exemplo de ndices com juno no data warehouse de Vendas 80

Figura 29

Tabela Empregados ..83

Figura 30

Mdia dos salrios ........83

Figura 31

Quantidade de departamentos ..84

Figura 32

Tabela de Roll Up de Vendas de carro por Modelo, por Ano e por Cor 85

Figura 33

Tabela de Vendas........................ 85

Figura 34

Linhas no includas na agregao da tabela de Vendas ..86

Figura 35

Cross tabulation de vendas da GM .........87

Figura 36

Agregaes em um cubo de N Dimenses ...88

Figura 37

Data Cube de 3 dimenses construdo a partir da tabela tbl_vendas ...90

Figura 38

Valores da relao tab_base.....................97

Figura 39

Valores da viso Visao1 com o nmero de derivaes para cada linha ..97

Figura 40

Valores da viso materializada Visao1 aps a excluso do registro (a, b)

da relao base...................................................................................98

Figura 41

Instncia das relaes tab1 e tab2 ............99

Figura 42

Valores da viso com outer-join completo Visao1..............................99

RESUMO

Modelos multidimensionais so largamente utilizados em processos analticos que

requerem complexos cruzamentos de informaes, pois so capazes de processar com
performance razovel um grande volume de dados. Este trabalho busca apresentar as
principais tcnicas da modelagem multidimensional utilizadas hoje. Essas tcnicas tm o
objetivo de otimizar a estrutura dos modelos multidimensionais. Para tanto, foi empregado um
mtodo baseado na apresentao de exemplos e na discusso dos problemas do modelo
relacional para atender a demanda de informaes analticas e gerenciais.

ABSTRACT

Multidimensional models are wide used in analytical processes that require complexes
data crosses because they can compute with moderate performance large amounts of data.
This job presents the major multidimensional modeling techniques applied nowadays. These
techniques have the objective to optimize multidimensional modeling structures. In order to
do that, it was used a method based on the presentation of examples and on the discussion of
the relational models problems to supply the analytical and the business information
demand.

INTRODUO
Quando surgiram, os sistemas e aplicaes voltados para as funes operacionais
tornaram o trabalho mais simples, pois, alm de garantirem maior agilidade na execuo de
tarefas que antes requeriam um esforo muito grande, tambm minimizam possveis erros
humanos.

Alm de vantagens como as citadas acima, essas aplicaes trouxeram outras

indiretamente, como a capacidade de manter informaes histricas de forma agrupada e
possvel de serem consultadas. Essas informaes poderiam ser usadas por reas estratgicas
da empresa (marketing, alta gerncia, etc) para auxiliar em tomadas de deciso. Porm,
agrupar essas informaes, interpret-las e tirar concluses no uma tarefa fcil. preciso
extrair de cada base de dados as informaes que realmente interessam e padroniz-las para
que possam ser analisadas.

O processo de data warehousing busca automatizar o processo de extrao e

padronizao de dados, alm de prover ao usurio maneiras mais fceis e flexveis de
visualizar os dados. Um data warehouse uma coleo de dados orientada por assuntos,
integrada, variante no tempo, e no voltil, que tem por objetivo dar suporte aos processos de
tomada de deciso [INMON, 1999].

De uma forma geral, sistemas de data warehouse compreendem um conjunto de

programas que extraem e tratam dados do ambiente operacional da empresa, um banco de
dados que os mantm, e sistemas que fornecem estes dados aos seus usurios, dando suporte a
consultas ad-hoc (consultas com acesso casual nico e tratamento dos dados segundo
parmetros nunca antes utilizados), relatrios analticos e tomada de deciso.

10
Com essas caractersticas voltadas anlise de negcios, natural que o ambiente de
data warehouse requeira mudanas constantes em seus relatrios e consultas. Essa
flexibilidade imprescindvel, uma vez que ter as informaes certas pode fazer a diferena
na tomada de deciso. Porm, embora as necessidades por informaes especficas mudem
com freqncia, os dados associados no mudam. Imaginando-se que os processos de negcio
de uma empresa permaneam relativamente constantes, existe apenas um nmero finito de
objetos e eventos com as quais uma organizao est envolvida. Por esta razo, um modelo
de dados uma base slida para identificar requisitos para um data warehouse.

Um modelo de dados bem estruturado capaz de prover s empresas a capacidade

de extrarem as informaes certas das mais diferentes formas e maneiras, independente da
ferramenta ou do grau de complexidade exigido nas consultas. Ou seja, a importncia da
modelagem de dados em data warehouse reside no fato de que, sem uma estrutura bem
elaborada, a enorme quantidade de informaes pode tornar as consultas demasiado lentas, e
com a possibilidade de tornar inviveis algumas operaes de consulta.

O objetivo geral desse trabalho mostrar a importncia da modelagem de dados no

ambiente data warehouse, apresentar os conceitos da modelagem dimensional e oferecer
tcnicas interessantes de construo de um modelo dimensional, visando oferecer ao usurio
informaes interessantes para a realizao de consultas analticas, e buscando a otimizao
da performance das consultas e das atualizaes na base de dados.

O trabalho encontra-se organizado como segue: o captulo um traz informaes

acerca da modelagem de dados relacional como uma base de entendimento para os prximos
temas. Trata de informaes acerca do ambiente data warehouse, seus termos e conceitos, e
introduo sobre o modelo dimensional de dados, que ser discutido mais profundamente

11
no captulo dois, que dedica-se a modelagem dimensional. Os conceitos de tabela de fatos, o
esquema estrela e floco de neve sero discutidos neste captulo em detalhe. O captulo trs
trata das tcnicas de modelagem a serem exploradas na construo de um modelo
dimensional, e discutem-se aspectos como a performance do modelo, a criao de chaves, o
uso de agregaes e a redundncia controlada de dados. O captulo quatro apresenta
estratgias que podem ser adotadas para reduzir o tempo de processamento para recuperar e
atualizar as informaes contidas em um modelo dimensional. Um apndice foi includo para
discutir o uso do OLAP (Processamento Analtico On-line), comparando os padres ROLAP
e MOLAP, contribuindo para um maior aprofundamento dos temas discutidos.

12

Captulo 1 Ambiente Data Warehouse

1.1 Conceitos
Um data warehouse nada mais do que um banco de dados contendo dados
extrados do ambiente de produo da empresa, que foram selecionados e depurados, tendo
sido otimizados para processamento de consulta e no para processamento de transaes. Em
geral, um data warehouse requer a consolidao de outros recursos de dados, alm dos
armazenados em banco de dados relacionais, como informaes provenientes de planilhas
eletrnicas, documentos textuais, etc. [INMON, 1999].

importante considerar que um data warehouse no contm apenas dados

resumidos, podendo conter tambm dados primitivos. Deve-se prover ao usurio a capacidade
de aprofundar-se num determinado tpico, investigando nveis de agregao menores ou
mesmo o dado primitivo, permitindo tambm a gerao de novas agregaes ou correlaes
com outras variveis. Alm do mais, extremamente difcil prever todos os possveis dados
resumidos que sero necessrios: limitar o contedo de um data warehouse apenas a dados
resumidos significa limitar os usurios apenas s consultas e anlises que eles puderem
antecipar frente a seus requisitos atuais, no deixando qualquer flexibilidade para novas
necessidades.

A especificao de requisitos do ambiente de suporte deciso, associado a um data

warehouse, fundamentalmente diferente da especificao de requisitos dos sistemas que
sustentam os processos usuais do ambiente operacional de uma empresa. Os requisitos dos
sistemas do ambiente operacional so claramente identificveis a partir das funes a serem
executadas pelo sistema. Geralmente, os sistemas do ambiente operacional que apiam os

13
usurios em suas funes do dia-a-dia so chamados OLTP (On Line Transaction
Processing), e seu principal objetivo executar o maior nmero de transaes possveis no
menor tempo de processamento. Em geral, os sistemas OLTP so pouco flexveis em relao
quantidade de relatrios e consultas, devido s limitaes impostas por seu modelo de dados
e linguagem SQL. Em sistemas de suporte a deciso, onde o volume de dados costuma ser
muito maior e as consultas altamente complexas, os requisitos so difceis de determinar, o
que culmina na necessidade de ferramentas altamente flexveis e customizveis. Para atender
essa necessidade so adotados os sistemas OLAP (On Line Analytical Processing). Sistemas
OLAP permitem aos usurios de alto nvel, como gerentes e analistas de negcio, navegarem
entre os dados da empresa com maior facilidade, proporcionando uma viso multidimensional
desses dados.

Inmon (1999) nos d uma definio bastante completa sobre o OLAP:

(...) uma tecnologia de software que permite a analistas, gerentes e

executivos a obterem os dados de uma forma rpida, consistente e com acesso interativo
para uma grande variedade de possveis vises da informao na empresa. Mais
sucintamente, OLAP um conjunto de funcionalidades que tem, como principal
objetivo, facilitar a anlise multidimensional.
Sistemas OLAP fornecem uma viso multidimensional dos dados no importando
como estes dados esto fisicamente armazenados. Os dados so percebidos pelo usurio como
um cubo multidimensional onde cada clula contm um valor ou medida.

Cubo uma estrutura multidimensional de dados que expressa a forma na qual os

tipos de informaes se relacionam entre si. O cubo de uma forma genrica armazena todas as
informaes relacionadas a um determinado assunto, de maneira a permitir que sejam

14
montadas vrias combinaes entre elas, resultando na extrao de vrias vises sobre o
mesmo tema.

Alguns conceitos so importantes para que se possa compreender melhor o

funcionamento de um ambiente data warehouse e so definidos a seguir.

Sistemas operacionais de origem: So considerados sistemas operacionais de

origem qualquer sistema de registro que captura as transaes da empresa. Sistemas de
origem devem ser considerados como externos ao data warehouse porque se presume que se
tenha um pouco ou nenhum controle sobre o contedo e formato dos dados nesses sistemas.

Metadados: Toda e qualquer informao no ambiente de data warehouse que no

so os dados propriamente ditos, so chamados metadados. Estes so como uma enciclopdia
para o data warehouse. Eles esto presentes em uma variedade de formas e formatos para
suportar as necessidades desiguais dos grupos de usurios tcnicos, administrativos e de
negcio do data warehouse.

Quando os dados esto na rea de armazenamento, encontramos metadados

especficos para orientar os processos de transformao e carga, inclusive arquivos de teste e
lay-outs de tabelas de destino, regras de transformao e filtragem, definies de dimenso e
fato em conformidade, definies de agregao e resultados de log de execuo e
cronogramas de transmisso ETL (O termo ETL tratado logo a seguir). At cdigos de
programao personalizados que foram criados na rea de armazenamento, so metadados.

Os metadados que permeiam o SGBD Sistema Gerencial de Banco de Dados do

data warehouse so responsveis por itens como tabelas de sistemas, configuraes de
partio, ndices, definies de exibio e concesses e privilgios de segurana no nvel do

15
SGBD. Os metadados de ferramentas de acesso a dados identificam os nomes e as definies
comerciais das tabelas e colunas da rea de apresentao, bem como filtros de restrio,
especificaes de modelos de aplicao, estatsticas de uso e acesso e outras documentaes
de usurio.

O objetivo dos metadados cercar, catalogar, integrar e melhorar essas diversas

variedades de metadados, da mesma forma que os recursos de uma biblioteca [KIMBALL,
2002].

1.2 ETL Extrao, Transformao e Carga

No ambiente de data warehouse, os dados so inicialmente extrados de sistemas
operacionais e de fontes externas, posteriormente integrados e transformados (limpos,
eliminados, combinados, validados, consolidados, agregados e sumarizados), antes de serem
carregados no data warehouse. Finalmente, os usurios acessam o DW atravs de ferramentas
de front-end ou aplicaes submetendo suas consultas, de modo a obterem informaes que
permitam a tomada de decises. Um DW contm dados sumarizados, histricos e detalhados
para suportar a tomada de decises tticas e estratgicas. A figura 1 apresenta o ambiente data
warehouse, mostrando o fluxo realizado at a disponibilizao dos dados aos usurios.

16

Figura 1: Ambiente Data Warehouse.

1.2.1 Extrao
A extrao o primeiro passo na obteno de dados para o ambiente do DW.
Significa basicamente ler e entender as fontes de dados e copiar as partes necessrias para a
rea de transformao de dados, a fim de serem trabalhadas posteriormente. Na grande
maioria dos DW, os dados provm de vrias fontes diferentes e independentes, podendo ser
essas fontes as bases de dados dos sistemas transacionais, planilhas excel, etc.

Freqentemente, o grande desafio determinar quais dados extrair e que tipos de

filtros aplicar, essa atividade uma das que mais consomem tempo na construo do DW. A
extrao pode ser conduzida atravs da construo de programas cujo cdigo executado
sobre um sistema fonte de modo a gerar arquivos com os dados desejados. Outra opo
utilizar ferramentas de extrao especficas que geram cdigo prprio, interno ferramenta,

17
executado sobre o sistema fonte, de forma a obter os dados necessrios, de preferncia dentro
de arquivos de formato no proprietrio, como, por exemplo, arquivos texto.

1.2.2 Transformao de dados

Aps a extrao dos dados dos sistemas fontes, so realizadas uma srie de
atividades sobre esses dados de modo a convert-los em formato adequado para carga no data
warehouse e valioso para o negcio. A transformao dos dados poder envolver um ou
vrios processos, dependendo da necessidade e situao. Seguem alguns dos processos mais
comumente utilizados:

limpeza: constitui no conjunto de atividades realizadas, sobre os dados extrados,

de modo a corrigir o uso incorreto ou inconsistente de cdigos e caracteres
especiais, resolver problemas de conflito de domnios, tratar dados perdidos,
corrigir os valores duplicados ou errados. Independente do problema a ser
solucionado pelo processo de limpeza, a finalidade deixar os elementos de
dados dentro de formatos padres (uniformizados), no duplicados, corretos,
consistentes e espelhando a realidade;

eliminao: constitui em desconsiderar os campos e dados provenientes de

sistemas legados que no so teis ao DW;

combinao: realizada quando fontes de dados possuem exatamente os mesmos

valores de chaves representando registros iguais ou complementares;

desnormalizao e normalizao: o padro no processo de transformao reunir

as hierarquias de dados, separadas em vrias tabelas devido normalizao,
dentro de uma nica dimenso, de forma desnormalizada. Pode ocorrer,
entretanto, que dados provenientes do processo de extrao estejam

18
completamente desnormalizados dentro de arquivos texto, nesse caso possvel
que seja necessrio normalizar partes dos registros.

clculos, derivao e alocao: so transformaes a serem aplicadas s regras

do negcio identificadas durante o processo de levantamento de requisitos.
conveniente que as ferramentas a serem empregadas possuam um conjunto de
funes, tais como manipulao de textos, aritmtica de data e hora, entre outras.

1.2.3 Carga de dados

Aps os dados serem transformados, eles so carregados no data warehouse. A parte

de carga dos dados tambm possui uma enorme complexidade, e os seguintes fatores devem
ser levados em conta:

Integridade dos dados: no momento da carga, necessrio checar os campos que

so chaves estrangeiras com suas respectivas tabelas para certificar-se de que os
dados existentes na tabela da chave estrangeira esto de acordo com a tabela da
chave primria;

Tipo de carga a ser realizada - incremental ou a total: a carga incremental

normalmente feita para tabelas de fatos e a carga total feita em tabelas de
dimenso onde o analista ter que excluir os dados existentes e inclu-los
novamente. Mas isso depende da necessidade do negcio em questo;

Otimizao do processo de carga: todo banco de dados possui um conjunto de

tcnicas para otimizar o processo de carga, tais como evitar a gerao de log
durante o processo, criar ndices e agregar dados. Muitas dessas caractersticas
podem ser invocadas dos bancos de dados ou registradas em scripts atravs da
utilizao de ferramentas sobre a rea de organizao de dados;

19

Suporte completo ao processo de carga: o servio de carga tambm precisa

suportar as exigncias antes e depois da carga atual, como eliminar e recriar
ndices e particionamento fsico de tabelas e ndices.

1.3 Modelo de Dados

A elaborao do modelo de dados concentra-se na observao dos fatos relevantes
que ocorrem na realidade, com a finalidade de construir um sistema que possa automatizar as
necessidades de informao da mesma. Neste momento, os documentos que registram estes
fatos s devem ser utilizados como apoio de entendimento, e no como base para o
desenvolvimento do sistema de informaes, ou seja, no se deve ter a preocupao em
simular o ambiente atual, seja ele manual ou automatizado [MACHADO, 1996].

O analista deve ter a preocupao de retratar as necessidades de informao que as

pessoas (que agem sobre esta realidade) precisam para alcanar os objetivos desta mesma
realidade. Ao coletar e selecionar os fatos relevantes, o analista deve identificar os elementos
geradores de informao, as leis que regem esta realidade, bem como, as operaes que
incidem sobre os elementos bsicos (dados).

Para registrar as necessidades de informao de uma realidade, necessrio fazer

uso de um modelo, ou seja, algo que nos mostre como as informaes esto relacionadas
(fatos). E, com base no modelo criado, os analistas podem interagir com os usurios validando
seus objetivos e metas, permitindo a construo de um sistema de informaes, cada vez mais,
prximo da realidade do usurio.

20
Como ser visto a seguir, os modelos de dados podem ser classificados segundo a
arquitetura que utilizam. O modelo relacional surgiu para atender os sistemas transacionais
(OLTP), j o modelo dimensional surgiu para atender os sistemas analticos (OLAP).

1.3.1 Modelo Relacional

Criado por Edgar F. Codd, nos anos 70, o Modelo Relacional, comeou a ser
utilizado nas empresas a partir de 1977. A abordagem relacional est baseada no princpio de
que as informaes em uma base de dados podem ser consideradas como relaes
matemticas e que esto representadas de maneira uniforme, atravs do uso de tabelas
bidimensionais. Este princpio coloca os dados dirigidos para estruturas mais simples de
armazenar dados, que so as tabelas, e nas quais a viso do usurio privilegiada.

O modelo relacional um conjunto de dados visto segundo um conjunto de tabelas,

e suas operaes sobre elas so feitas por linguagens que manipulam a lgebra relacional, no
sendo procedurais, ou seja, manipulam conjuntos de uma s vez [MACHADO, 1996].

Esse modelo surgiu para atender sistemas transacionais que possuem operaes
atmicas (que devem ocorrer por completo ou ento serem desfeitas) pr-definidas,
geralmente, com um grande nmero de usurios simultneos realizando operaes
repetidamente.

Para se compreender melhor o modelo de dados relacional, preciso o

conhecimento de alguns conceitos que so definidos a seguir.

21
Chave: designa o conceito de item de busca, ou seja, um dado que ser empregado
nas consultas base de dados. um conceito lgico de aplicao.

ndice: um recurso fsico visando otimizar a recuperao de uma informao, via

um mtodo de acesso. Seu objetivo principal est relacionado com a performance de um
sistema.

O modelo relacional deve estar preparado para ter um tempo de resposta pequeno,
uma vez que, as transaes so curtas e operam sobre poucos dados. Uma tabela acessvel
por qualquer campo independentemente se este declarado como chave ou no. O
relacionamento entre conjunto de dados (tabelas) no existe fisicamente, pois este
relacionamento apenas lgico e representado atravs das chaves estrangeiras (elos de
ligao entre as tabelas). Esse modelo visa a eliminao de redundncia, deixando os dados
em um nico lugar.

A base de dados de um modelo relacional reflete imediatamente as operaes

realizadas, com atualizaes que so visualizadas em tempo real, no existindo um processo
de carga de dados. A insero de um registro ou a atualizao de um registro j existente
imediatamente vista pelos usurios do sistema e geralmente no existe a necessidade de
consultas a dados histricos.

Por possuir atualizaes em tempo real com usurios simultneos, esse modelo exige
controle de concorrncia, por meio de mecanismos de bloqueio, commit e rollback para evitar
qualquer tipo de problema com os dados, como a perda de informaes.

22
Na criao de um modelo de dados relacional, so realizados aprimoramentos
chamados de normalizao, tornando o modelo menos redundante e menos inconsistente.

Normalizao: o processo de reunir todos os dados que sero armazenados em um

certo banco de dados e separ-los em tabelas. Atravs do processo de normalizao, pode-se
substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta
purificado em relao s anomalias de atualizao (incluso, alterao e excluso), as quais,
podem causar certos problemas, tais como: grupos repetitivos (atributos multivalorados) de
dados, redundncia de dados desnecessrios, perdas acidentais de informao, dificuldade na
representao de fatos da realidade [MACHADO, 1996].

Pode-se citar alguns benefcios do processo da Normalizao: estabilidade do

modelo, mantendo-o inalterado face a mudanas que venham a ser percebidas ou introduzidas
no ambiente que tenha sido modelado; flexibilidade, com o processo de normalizao das
tabelas aumenta a capacidade de adaptao a demandas diferenciadas, a expanso e reduo,
omisso ou presena (das tabelas); integridade, refere-se qualidade do dado, se um dado
sobre certo objeto aparecer mapeado em mais de um local de modo diferente, pode-se ter
indcios de que no h integridade entre eles; economia, com a existncia de redundncias nos
dados, o custo de armazenamento, torna-se muito maior, alm de tambm aumentar o custo de
manipulao dos dados.

1.3.2 Modelo Dimensional

Modelagem dimensional um nome para uma tcnica antiga que permitia tornar os
bancos de dados fceis e compreensveis. Caso aps caso, a partir da dcada de 1970 as
empresas de Tecnologia da Informao, as consultorias, os usurios finais e os fornecedores

23
migraram para uma estrutura dimensional simples para atender a necessidade humana
fundamental de simplicidade [KIMBALL, 1998].

O modelo dimensional surgiu para atender sistemas de processamento analtico, com

consultas para planejamento ttico e estratgico da empresa. Atualmente a utilizao desses
sistemas pelo nvel operacional das empresas vem crescendo, auxiliando o processo de
tomada de decises dirias. Normalmente, ele atende um pequeno nmero de usurios que
realizam consultas planejadas (relatrios pr-definidos) e ad-hoc.

O tempo de resposta maior, devido a consultas longas que operam sobre grande
volume de dados. Para melhor desempenho nas consultas, h redundncia planejada dos
dados, compensando os gastos com armazenamento e atualizao das informaes. O
resultado uma estrutura simples, com modelos que refletem o processo de anlise de
negcios.

A base de dados no atualizada pelo usurio, portanto, no disponibiliza as

alteraes realizadas entre uma atualizao e outra. As atualizaes so feitas periodicamente
em batch, no havendo a necessidade de controle de concorrncia. Os usurios somente
realizam consultas na base de dados, podendo extrair e formatar seus prprios relatrios, no
dependendo da equipe de tecnologia para isso.

Para realizao de anlises, a base de dados planejada para armazenar muitos

dados histricos, tipicamente de 12 a 60 meses.

Os sistemas analticos suportam a gesto da empresa, como planejamento de

marketing (expanso de lojas, lanamento de ofertas), anlise de vendas (melhores e piores
clientes / produtos / vendedores), etc.

24

Processamento Transacional:

Processamento Analtico:

Dados normalizados

Dados consistentes

Atualizao em tempo real

Desempenho compatvel com o volume de

dados (ou frmulas, etc)

Controle de concorrncia
Dados correntes

Clara representao do modelo de negcio

(camada semntica)

Respostas imediatas

Ferramentas especiais para os usurios finais

Quadro 1: Requisitos de processamento transacional e analtico.

1.3.3 - A escolha da modelagem

O quadro 2 a seguir mostra as principais diferenas entre sistemas de processamento

transacional (OLTP - On Line Transaction Processing) e sistemas de processamento analtico
(OLAP - On Line Analytical Processing).

Se OLAP e OLTP so to distintos, a modelagem de dados para cada funo deve

ser tambm distinta, pois OLAP e OLTP se propem a resolver problemas completamente
diferentes.

um erro pensar que tcnicas de projeto que servem para sistemas convencionais
sero adequadas para a construo de um data warehouse [INMON, 1999]. Os requisitos para
um data warehouse podem no ser conhecidos at que ele esteja parcialmente carregado e j
em uso.

O principal objetivo da modelagem relacional em um sistema OLTP eliminar ao

mximo, a redundncia, de tal forma que uma transao que promova mudanas no estado do
banco de dados, atue o mais pontualmente possvel. Com isso, nas metodologias de projeto

25
usuais, os dados so "fragmentados" por diversas tabelas, o que traz uma considervel
complexidade formulao de uma consulta por um usurio final. Por isso, esta abordagem
no parece ser a mais adequada para o projeto de um data warehouse, onde estruturas mais
simples, com menor grau de normalizao devem ser buscadas [KIMBALL, 2002].

Transacional - OLTP

Analtico - OLAP

Usurios tpicos

Usurios em geral

Gerentes, analistas de negcio

Aplicao do sistema

Operaes do dia-a-dia

Anlises do negcio

Interao do usurio

Pr-determinado

Ad-hoc

Caractersticas de trabalho

Leitura/gravao

Leitura

Unidade de trabalho

Transao

Consulta

Processamento

Orientado a processos

Orientado a assuntos

Atualizao

Um registro por vez

Vrios registros por vez

Quadro 2: Diferenas entre OLAP e OLTP

Fonte: Vaisman (1998, p. 5)

Obter respostas a questes tpicas de anlise dos negcios de uma empresa

geralmente requer a visualizao dos dados segundo diferentes perspectivas. Por exemplo:
uma agncia de automveis que esteja querendo melhorar o desempenho de seu negcio
necessita examinar os dados sobre as vendas disponveis na empresa. Uma avaliao deste
tipo requer uma viso histrica do volume de vendas sob mltiplas perspectivas: volume de
vendas por modelo, volume de vendas por cor, volume de vendas por montadora, volume de
vendas por perodo de tempo. Uma anlise do volume de vendas utilizando uma ou mais
destas perspectivas permitiria responder questes do tipo:

Qual a tendncia, em termos de volume de vendas, para o ms de dezembro, de

modelos Corsa Sedan pretos?

26
A capacidade de responder a este tipo de questo em tempo hbil o que permite
aos gerentes e altos executivos das empresas formularem estratgias efetivas, identificar
tendncias e melhorar sua habilidade de tomar decises de negcio. O ambiente tradicional de
bancos de dados relacional certamente pode atender a este tipo de consulta. No entanto,
usurios finais que necessitam de consultas deste tipo via acesso interativo aos bancos de
dados se frustram devido a tempos de resposta ruins e pela falta de flexibilidade oferecida por
ferramentas de consulta baseadas em SQL. Da a necessidade de utilizar abordagens
especficas para atender a estas consultas.

So chamadas de dimenses as diferentes perspectivas envolvidas. Em nosso

exemplo: loja, montadora, ms, essas dimenses usualmente correspondem a campos no
numricos em um banco de dados. Considerando um conjunto de medidas, tal como vendas
ou despesas com promoo, essas medidas correspondem geralmente a campos numricos em
um banco de dados. A seguir, as agregaes dessas medidas so avaliadas segundo as diversas
dimenses e armazenadas para acesso futuro. Por exemplo, calcula-se a mdia de todas as
vendas por todos os meses por loja. A forma como essas agregaes so armazenadas pode
ser vista em termos de dimenses e coordenadas, dando origem ao termo multidimensional.

Ao contrrio de aplicaes convencionais, como uma folha de pagamento ou

inventrio, a classificao de instncias em problemas multidimensionais dependente do
objetivo da anlise do usurio, no sendo consideradas propriedades prprias das entidades
envolvidas. Os tipos de classificao usados fazem surgir as dimenses descritivas, segundo
as quais observaes dos objetos ou eventos so observadas e medidas.

Cada eixo no espao multidimensional um campo/coluna de uma tabela relacional

e cada ponto um valor correspondente interseo das colunas. Por exemplo, o valor para o

27
campo vendas, correspondente a ms igual a novembro e loja igual a Iguatemi um ponto
com coordenada (novembro, Iguatemi). Nesse caso, ms e loja 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 por dois ou mais de seus atributos. Estruturas relacionais podem ser
usadas para a representao e o armazenamento de dados multidimensionais. Nesse caso, as
abordagens encontradas incluem desde a adoo de formas especficas de modelagem (os
chamados esquemas estrela e floco de neve) at mecanismos sofisticados de indexao.

Neste captulo foram tratados conceitos bsicos de data warehouse e modelo de

dados, mostrando as diferenas bsicas entre o modelo relacional e o modelo dimensional,
que ser tratado com maior profundidade no captulo que segue.

28

Captulo 2 - A Modelagem Dimensional

A modelagem dimensional uma metodologia que permite modelar logicamente
dados para melhorar o desempenho de consultas e prover facilidade de utilizao a partir de
um conjunto de eventos bsicos de medio. Os modelos dimensionais so compreensveis,
previsveis, ampliveis e resistentes ao ataque especfico de grupos de usurios de negcio,
por se manter fiel simplicidade, ter uma perspectiva voltada para as necessidades analticas
da empresa, e especialmente ao seu formato simtrico, em que todas as dimenses
normalmente so iguais pontos de entrada na tabela de fatos [KIMBALL, 2002]. Os modelos
dimensionais so a base de muitos aprimoramentos de desempenho SGBD, inclusive
agregaes e mtodos de indexao avanados.

2.1 Exemplo de Modelos de dados

O sistema empregado para apresentao dos exemplos de modelos de dados um
sistema de vendas de uma rede de lojas de departamento. Essa rede possui diversas lojas
distribudas em diferentes estados do Brasil. O sistema transacional gerencia todas as vendas
efetuadas em cada uma das lojas.

O modelo relacional utilizado nesse sistema utilizado nesse sistema, ilustrado na

figura 2, possui uma tabela Faturas que contm todos os dados relacionados a uma fatura, com
seus itens vendidos sendo armazenados na tabela Itens_Fatura. Para gerenciar as vendas,
possui tambm um cadastro de Lojas, de Clientes, de Funcionrios, de Produtos, de
Categorias e de Fornecedores.

29
Cada venda ocorrida representa uma linha na tabela Faturas e n linhas na tabela
Itens_Fatura, sendo que n o nmero de itens (produtos) diferentes vendidos nessa transao.

Figura 2: Modelo relacional do sistema transacional de vendas de lojas de departamento.

Para se realizar consultas analticas, o modelo relacional no oferece o desempenho

adequado, pois cada informao se encontra em uma tabela diferente. A normalizao um
dos princpios de tal modelo, sendo assim, o grande nmero de junes inevitvel, tornando
o processamento muito lento.

Por exemplo, um analista de marketing quer saber qual o faturamento com a venda
de cosmticos do fornecedor "Johnson & Johnson", em lojas da zona sul da cidade de So
Paulo no perodo do dia das mes. No modelo relacional a consulta precisaria fazer a juno
das tabelas Categorias, Produtos, Fornecedores, Itens_Fatura, Faturas e Lojas. Seria feita uma

30
busca por "cosmticos" na tabela Categorias, uma busca por "Johnson & Johnson" na tabela
Fornecedores, e uma juno dessas tabelas com a tabela Produtos para identificar quais so os
produtos dessa categoria e desse fornecedor. Na tabela Lojas seria feita uma busca por "zona
sul" e cidade "So Paulo", e as datas referentes ao perodo do dia das mes teriam que ser
limitadas manualmente na tabela Faturas. Com isso, possvel retornar o faturamento total da
tabela Itens_Fatura.

Para realizar essa consulta no modelo relacional, foram utilizadas 6 tabelas,

realizando um total de 5 junes, o que em um modelo dimensional poderia ser otimizado,
como apresentado a seguir.

A figura 3 apresenta o modelo dimensional desse sistema, preparado para atender

necessidades de anlises das vendas, a partir do cruzamento das informaes das lojas da
rede, com os produtos vendidos, os clientes e a data da venda.

Esse modelo possui uma tabela central chamada Vendas que armazena os dados
principais a serem analisados da venda, como o faturamento e o lucro. Essa tabela tem
relacionamento com as demais tabelas necessrias para identificar um item de venda com base
no cliente, data, loja e produto.

A tabela Clientes possui os dados necessrios para identificao do comprador, e

dados importantes para filtr-los, como idade, faixa etria, renda, sexo, etc. A tabela Data
armazena um registro para cada dia durante o perodo de existncia da rede de lojas de
departamento, com campos para facilitar a busca por uma determinada data ou perodo, como
a data no ano calendrio ou fiscal, se o dia um feriado ou no, qual a temporada de vendas
dessa data (dia dos namorados, dia das mes, Natal), etc.

31

Figura 3: Modelo dimensional do sistema analtico de Vendas de Lojas de departamento.

A tabela Lojas possui os dados de identificao para cada uma das lojas, e dados
para filtro, como um campo para indicar se uma loja pertence ou no a um shopping center.
Por fim a tabela Produtos armazena os dados de cada um dos produtos comercializados pelas
lojas da rede, sua categoria e fornecedor, e campos de caracterizao do produto, como o tipo
de embalagem (garrafa, caixa, pacote) e peso.

Nesse esquema, a busca pelo faturamento dos cosmticos do fornecedor "Johnson &
Johnson" vendidos na zona sul de So Paulo no perodo do dia das mes envolveria a juno

32
apenas das tabelas Vendas, Lojas, Produtos e Data. A busca por categoria e fornecedor
envolveria uma nica tabela, j que todos estes dados esto armazenados na tabela Produtos.
Na tabela Data seriam consultados todos os registros que tivessem o campo temporada de
venda com o valor "dia das mes", deste ano calendrio. Essa uma maneira mais simples do
que identificar quais foram os dias que fizeram parte desse perodo no momento da consulta,
evitando possveis distores por parte dos usurios. Na tabela Lojas feita a seleo por
regio "zona sul" e cidade "So Paulo", e, atravs da juno dessas trs tabelas na tabela
Vendas, retornado o faturamento total.

Como o modelo relacional trabalha com normalizao, suas tabelas possuem menos
registros e no tm redundncias, apresentando assim uma melhor performance nas tarefas do
dia a dia, como incluses, alteraes e excluses de registros, mas ele s adequado para
consultas simples de poucos registros. Para anlises mais complexas com um universo de
registros maior, o modelo dimensional oferece uma melhor alternativa, economizando em
junes com vrias tabelas, e armazenando dados que facilitam a anlise das informaes.

O modelo dimensional, alm de atender a consulta sobre as vendas no perodo do dia

das mes com uma performance melhor, facilita outros tipos de anlise como comparaes
entre os resultados das vendas do dia das mes desse ano com os resultados de anos
anteriores, avaliao mdia do perfil dos compradores (faixa etria, renda mdia, etc.), etc.

2.2 Esquema Estrela

O esquema estrela uma estrutura simples, com poucas tabelas e ligaes
(relacionamentos) bem definidas [POE, KLAUER, BROBST, 1998], assemelha-se ao modelo

33
de negcio, o que facilita a leitura e entendimento, no s pelos analistas, como por usurios
finais no familiarizados com estruturas de banco de dados. Permite a criao de um banco de
dados que facilita a execuo de consultas complexas, podendo ser realizadas de modo
eficiente e intuitivo pelo usurio.

O modelo dimensional requer a utilizao de ferramentas de consultas analticas,

desenvolvidas especialmente para consultar esse tipo de modelo, o que permite aos usurios a
explorao de todos os dados disponveis durante a elaborao das consultas.

Figura 4: Representao da estrutura do Esquema Estrela.

34
O nome "estrela" est associado disposio das tabelas no modelo, que consiste de
uma tabela central, a tabela de fatos, que se relaciona com diversas outras tabelas, as tabelas
de dimenso (os conceitos de tabelas de fatos e tabelas de dimenso so apresentados em
seguida). A figura 4 apresenta a estrutura geral de um esquema estrela.

O esquema estrela pode representar tanto o modelo lgico, como o modelo fsico do
banco de dados. A representao mais simples de um modelo dimensional contm um
esquema estrela com uma tabela de fatos relacionada com tabelas de dimenso, mas um
modelo dimensional pode ter uma ou mais tabelas de fatos, relacionadas com tabelas de
dimenso. Entretanto, a viso de um esquema por vez torna o modelo mais claro.

2.2.1 Tabela de Fatos

A tabela de fatos a principal tabela de um modelo dimensional, onde as medies

numricas de interesse da empresa esto armazenadas [KIMBALL, 2002]. A palavra "fato"
representa uma medida dos processos que estamos modelando, como quantidades, valores e
indicadores. A tabela de fatos registra os fatos que sero analisados. composta por uma
chave primria (formada por uma combinao nica de valores de chaves de dimenso) e
pelas mtricas de interesse para o negcio.

As dimenses indicam a forma como as medidas sero vistas, os seja, so os

aspectos pelos quais se pretende observar as mtricas. A interseco das chaves de dimenso
define a granularidade da tabela de fatos, e importante que todas as medidas na tabela de
fatos tenham a mesma granularidade.

35
A granularidade diz respeito ao nvel de detalhe ou de resumo contido nas unidades
de dados existentes no data warehouse [INMON, 1997]. Quanto mais detalhe, mais baixo o
nvel de granularidade. Quanto menos detalhe, mais alto o nvel de granularidade.

Os modelos dimensionais devem armazenar a informao mais detalhada no

processo do negcio, preferencialmente dados que no podem ser subdivididos, como uma
linha de item de uma venda, por exemplo. Por isso, normalmente uma tabela de fatos
grande, com milhes de registros.

A tabela de fatos deve ser sempre preenchida com as medidas referentes ao fato.
No se deve preencher uma linha da tabela fato com zeros para representar que nada
aconteceu (por exemplo, que no houve vendas de um produto em determinada data), pois
isso faria com que a tabela de fatos crescesse demais.

A tabela de fatos sempre esparsa, ou seja, possui um nmero relativamente

pequeno de todas as combinaes possveis de valores de chaves. Por exemplo, no caso de um
banco de dados de uma companhia area, a presena de todas as combinaes possveis
representaria que todos os clientes voam todos os dias, e em todos os vos feitos pela
companhia, o que na prtica impossvel. Por isso podemos dizer que esse banco
extremamente esparso, pois uma porcentagem muito pequena de todas as combinaes
possveis de clientes, nmero do vo e dia aparecero nele.

Outro ponto importante que a tabela de fatos deve representar uma unidade do
processo do negcio, no devendo-se misturar assuntos diferentes numa mesma tabela de
fatos.

36
Os atributos mais comuns em uma tabela de fatos so valores numricos. Estes
valores so, em sua maioria, aditivos. As mtricas aditivas so as que permitem operaes
como adio, subtrao e mdia de valores por todas as dimenses, em quaisquer
combinaes de registros, como "total de itens vendidos" por combinao de data, produto e
loja. Mtricas aditivas so importantes porque normalmente as aplicaes de data warehouse
no retornam uma linha da tabela de fatos, mas sim centenas, milhares e at milhes.

Existem tambm mtricas no-aditivas e mtricas semi-aditivas. As mtricas noaditivas so valores que no podem ser manipulados livremente, como valores percentuais ou
relativos. Para esses valores, os clculos devem ser realizados nos dados absolutos nos quais
se baseiam. Exemplos de mtricas no-aditivas so preo de custo e preo de venda de um
produto em uma venda. Por fim, as mtricas semi-aditivas so valores que no podem ser
somados em todas as dimenses. Por exemplo: numa tabela com o registro dirio do saldo
bancrio dos clientes de uma agncia, no faz sentido somar os saldos bancrios dirios de um
cliente durante um ms, mas pode-se somar os saldos de todos os clientes de uma agncia em
determinada data.

Um exemplo de uma tabela de fatos a tabela Vendas da rede de lojas de

departamentos vista anteriormente, apresentada na figura 5.

Figura 5: Tabela de fatos Vendas.

37
2.2.2 Modelagem da Tabela de Fatos

Uma tcnica para modelar a tabela de fatos responder as seguintes perguntas:

Que processo estamos modelando?

O que usamos para medir este processo?

Quais os indicadores crticos de desempenho desse processo?

Um processo uma atividade de negcio natural executada na empresa. Ouvir os

usurios o meio mais eficiente de selecionar o processo de negcio. importante lembrar
que no estamos nos referindo a um departamento ou funo de negcio de uma empresa
quando falamos de processos de negcio. Se forem estabelecidos modelos dimensionais para
cada departamento, inevitavelmente os dados sero duplicados com diferentes rtulos e
terminologias [KIMBALL, 2002].

Os valores necessrios para se medir o processo podem ser encontrados prontos no

sistema origem, ou ento podem ser calculados baseados em medidas do sistema origem. Os
fatos tpicos so valores numricos aditivos.

Os indicadores crticos de desempenho so os indicadores em que a empresa se

baseia para fazer suas anlises. A tabela de fatos deve conter fatos que permitam que esses
indicadores sejam construdos.

Por exemplo: o usurio quer saber quais foram as vendas no perodo de janeiro a
maro deste ano na regio sudeste e nordeste, quais os produtos mais rentveis, quem foram
os maiores clientes, quais foram os melhores vendedores, onde vendi mais que o concorrente,
e que produtos vendem menos que os do concorrente. Como resposta s perguntas, temos:

Que processo estamos modelando? - Processo de vendas

38

O que usamos para medir este processo? - Usamos o valor das vendas e
quantidade vendida

Quais os indicadores crticos de desempenho desse processo? - Atingimento

da cota de venda, margem de lucro, benchmark com o mercado

2.2.3 Classificao dos Fatos

Os fatos podem ser classificados em transaes individuais, em snapshots e em

linhas de itens [KIMBALL et al, 1998].

As chamadas transaes individuais representam uma transao completa,

normalmente, apresentam uma estrutura muito simples, possuem um campo acumulado que
contm o valor total de uma transao.

Os fatos snapshots representam medidas de atividades extradas em tempo

determinado, como, por exemplo, final do dia ou final do ms, com medies acumuladas
durante esse perodo.

Os fatos do tipo linhas de itens so aqueles que representam exatamente uma linha
de item, so armazenados no nvel mais detalhado dos fatos, como, por exemplo, itens de
pedido, itens de entrega e itens de aplice de seguro.

2.2.4 Tabela de Dimenso

A tabela de dimenso contm as descries textuais do negcio, e possui as

informaes necessrias para anlises ao longo de dimenses. Seus atributos so fonte das
restries das consultas, agrupamento dos resultados, e cabealhos para relatrios. As

39
dimenses so os aspectos pelos quais se pretende observar as mtricas relativas ao processo
que est sendo modelado.

A qualidade do banco de dados proporcional qualidade dos atributos de

dimenses, portanto deve ser dedicados tempo e ateno a sua descrio, ao seu
preenchimento e a garantia da qualidade dos valores em uma coluna de atributos [KIMBALL,
2002].

Cada dimenso definida com uma nica chave primria. Essa chave a base da
integridade referencial no relacionamento com a tabela de fatos. Uma tabela de dimenso
composta tambm de atributos, os melhores atributos so textuais e distintos, e devem
consistir de palavras reais, evitando-se o uso de cdigos e abreviaes. Esses atributos
descrevem as linhas na tabela de dimenso. A figura 6 mostra um exemplo de tabela de
dimenso Produtos.

Figura 6: Tabela de dimenso Produtos.

A tabela de dimenso costuma ser bem menor que a tabela fato, geralmente com
muito menos do que um milho de registros, no entanto comum existirem tabelas de
dimenso com muitos atributos (de 50 a 100).

40
muito importante que os atributos das tabelas de dimenso sejam preenchidos com
valores descritivos ao invs de cdigos sem sentido, criptografados ou abreviados
[KIMBALL, 2002]. Por exemplo, em uma tabela de dimenso Alimentos, o campo
perecvel deve ser preenchido com valores como perecvel ou No perecvel ao
invs de usar simplesmente S e N. Em um relatrio com a listagem de milhares de
produtos, um valor descritivo tem muito mais utilidade do que cdigos. Ao invs de usar uma
aplicao para decodificar esses cdigos e mostrar uma descrio, melhor armazenar essas
descries no banco de

dados,

tornando a

informao

disponvel ao

usurio

independentemente de seu aplicativo de acesso aos dados.

2.2.5 Hierarquia de Dimenses

As hierarquias descrevem a lgica dos relacionamentos entre os dados so a base

para a navegao entre os diferentes nveis de detalhe em uma estrutura multidimensional
[MEYER, CANNON, 1998]. A figura 7 apresenta os nveis de agregaes, ou seja,
agrupamentos que podem ser aplicados dimenso Produto. Muitas dimenses apresentam
uma estrutura hierrquica ou multinvel.

Algumas estruturas hierrquicas so facilmente identificadas, como por exemplo,

uma estrutura de tempo representada por horas, dias, semanas, meses, trimestres e anos ou
uma estrutura geogrfica representada por cidades, municpios, estados, regies e pases
[KIMBALL, 1996]. Dois tipos de hierarquia podem ser considerados para uma dimenso:
explcita e implcita.

Hierarquias explcitas: As hierarquias so caracterizadas por uma seqncia de

entidades interligadas, cujos relacionamentos, entre cada par de entidades na

41
seqncia, N:1. A figura 7 representa a hierarquia explcita para a dimenso
Produto. Essa hierarquia constituda pelas dimenses Tipo e Categoria.

Figura 7: Hierarquia explcita de Produto.

Hierarquias implcitas: tambm conhecidas como mltiplas hierarquias,

representam as hierarquias embutidas nos atributos das dimenses. Um exemplo
para mltiplas dimenses representado na figura 8, com a classificao de
produtos de acordo com Tipo de Armazenamento e Tipo de Embalagem. Os
alimentos podem ser subcategorizados, quanto ao armazenamento refrigerado ou
no refrigerado, ou quanto ao tipo de embalagem, em caixa e pacote. Do
mesmo modo, os materiais de limpeza podem ser classificados, quanto sua
frmula, em txica ou no txica, ou, quanto sua consistncia, em lquida,
pastosa ou em p.

42

Figura 8: Hierarquia implcita para Produto.

Uma questo importante a ser abordada diz respeito influncia da hierarquia das
dimenses sobre a tabela de fato. A tabela de fatos deve refletir a menor granularidade das
dimenses, de modo a garantir que no sejam armazenados registros que representem totais
referentes a um nvel mais alto na hierarquia de uma dimenso.

Dessa forma, se a dimenso Produto, na figura 7, apresenta a hierarquia:

Categoria / Tipo / Produto, os registros na tabela de fatos devem indicar totais no

nvel de produto. Os registros que totalizem por Categoria ou Tipo no devem ser
armazenados.

2.2.6 Drill-down e Roll-up

Uma caracterstica bastante interessante nas anlises dimensionais a possibilidade

de detalhamento e de sintetizao das informaes, que chamamos respectivamente de drilldown e roll-up. A figura 9 apresenta um exemplo de drill-down e roll-up atravs de uma
informao de data.

43

Figura 9: Exemplo de drill-down, detalhando uma informao de data e roll-up, sintetizando

a informao.
Drill-down no significa descer em uma hierarquia predeterminada. Significa a
possibilidade de obter rapidamente cabealhos de linha de qualquer uma das dimenses
associadas a uma tabela de fatos. Significa tambm a possibilidade de remover cabealhos e
pesquisar em direes diferentes [KIMBALL, 1996].

Determina tambm o detalhamento de um consulta, as consultas so mais restritas se

existirem mais detalhes nos critrios de seleo. O usurio pode querer comear sua anlise
no nvel mais alto de agregao, e ento aprofundar a pesquisa passando pelos diferentes
nveis at o nvel inferior de detalhe a fim de obter uma perspectiva diferente do que comps
os valores do nvel mais alto. A acumulao e o aprofundamento de pesquisa so recursos
teis do ambiente OLAP para a realizao da anlise multidimensional, porm, diferentes
nveis de uma hierarquia no representam dimenses diferentes por si mesmas, desse modo,
eles no so considerados requerimentos para se fornecer capacidades multidimensionais.

A figura 10 mostra o suporte OLAP ao processamento de drill-down. H dois tipos

de processamento de drill-down relevantes: processamento de drill-down entre-OLAP e

44
processamento de drill-down OLAP-para-dados estruturados organizacional. O drill-down
entre-OLAP usado para mostrar o relacionamento de resumo entre as diferentes instncias
de dados dentro do ambiente OLAP, tambm conhecido como drill-across. Dados mais
detalhados existem no nvel estruturado organizacional do data warehouse, o que d suporte a
um nvel de drill-down que vai alm do projeto de cada instncia de OLAP departamental
[INMON, 1999].

Figura 10: Drill-down e drill-across de OLAP.

O roll-up o processo inverso do drill-down, permite que o usurio reduza o escopo

da anlise. Ele sobe o nvel de detalhe, ou seja, incrementa o nvel de agregao.

2.2.7 Dimenses Descaracterizadas

As dimenses descaracterizadas, tambm conhecidas como dimenses degeneradas,

so tipos de atributo normalmente empregados em tabelas de fatos onde a granularidade da
tabela representa uma transao propriamente dita ou uma linha de item da transao, e pode
ser usada para agrupar itens de linha em uma nica ordem.

45
A dimenso descaracterizada representa um identificador do registro. So
representadas na tabela de fatos como chaves de dimenso sem que exista a tabela de
dimenso. Muitas vezes dimenses descaracterizadas compem a chave primria da tabela de
fatos junto com as chaves estrangeiras das outras dimenses. A figura 11 ilustra um exemplo
de dimenso descaracterizada na tabela de fatos Vendas, com o atributo nmero da venda.
Como as outras informaes, como Cliente e Data, j esto em outra dimenso, o nmero da
venda se torna uma dimenso descaracterizada.

Figura 11: Dimenso descaracterizada cdigo da venda na tabela de fatos Vendas.

2.3 Esquema Floco de Neve

O esquema floco de neve uma variao do esquema estrela, no qual todas as
tabelas de dimenso so normalizadas na terceira forma normal (3FN), ou seja, so retirados
das tabelas os campos que so funcionalmente dependentes de outros campos que no so
chaves. Recomenda-se utilizar o esquema floco de neve apenas quando a linha de dimenso
ficar muito longa e comear a ser relevante do ponto de vista de armazenamento. A figura 12

46
representa a implementao do modelo floco de neve no modelo do sistema de vendas da loja
de departamentos apresentado no tpico 2.1.

Figura 12: Modelo de Dados do sistema de vendas de lojas de departamento utilizando o

esquema floco de neve.
Se as tabelas de dimenso forem normalizadas podem surgir alguns problemas. A
complexidade do modelo de dados aumenta e, conseqentemente, diminui a compreenso
desse modelo por parte dos usurios.

A implementao do floco de neve frustra o uso de esquemas de indexao mais

eficientes como o ndice de mapa de bits [KIMBALL, 2002]. Esses ndices so muito teis
para indexar campos de baixa cardinalidade, agilizam muito o desempenho de uma consulta
ou restrio nica coluna em questo, sendo assim ideais para tabelas desnormalizadas. Esse

47
esquema inevitavelmente interfere na possibilidade de explorao dessa tcnica de ajuste de
desempenho.

O desempenho durante a fase de atualizao dos dados do data warehouse ser

melhor com as tabelas normalizadas, mas isso no to importante em sistemas de apoio
deciso, uma vez que esta operao feita normalmente durante a noite ou em momentos em
que no estejam sendo executadas consultas por parte dos usurios. Mesmo assim, alguns
projetistas utilizam o argumento de melhorar este desempenho para justificarem a necessidade
de normalizar as dimenses.

J a performance das consultas realizadas pelos usurios tende a diminuir devido o

aumento do nmero de junes, e essa sim pode ser crucial para o sucesso do ambiente visto
que os usurios que esperam retornos cada vez mais rpidos.

Ralph Kimball [1996] aconselha os projetistas "bem-intencionados" a resistirem

tentao de transformar esquemas estrela em esquemas 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.

A deciso de optar pelo esquema estrela ou pelo floco de neve deve ser tomada
levando-se em considerao o volume de dados, o SGBD, as ferramentas utilizadas, etc.

Outra possibilidade mesclar o esquema estrela com o esquema floco de neve,

normalizando apenas algumas dimenses. Essas dimenses normalizadas podem ou no ter
um relacionamento direto com a tabela de fatos. A figura 13 mostra como ficariam
relacionadas as tabelas no caso do modelo ter um relacionamento direto das dimenses
normalizadas com a tabela de fato.

48

Figura 13: Modelo de dados floco de neve com as dimenses normalizadas se relacionando
diretamente com a tabela de fatos.
Dessa forma, pode-se economizar com espao de armazenamento e melhorar a
performance em alguns tipos de consultas, do que se fosse utilizado o esquema floco de neve
puro. Por exemplo, no caso de se efetuar uma anlise de vendas por categoria.

2.4 Cubo
Uma idia fundamental da modelagem dimensional que quase todos os tipos de
dados de negcio podem ser representados por um tipo de cubo de dados, onde as clulas
deste cubo contm valores medidos e os lados do cubo definem as dimenses dos dados.
Pode-se ter mais que trs dimenses, tecnicamente chamado de hipercubo, apesar de
normalmente os termos cubo e cubo de dados serem usados como sinnimos de hipercubo
[KIMBALL et al, 1998].

49
Cubo a estrutura multidimensional de dados que expressa a forma na qual os tipos
de informaes se relacionam entre si. formado pela tabela de fatos e pelas tabelas de
dimenso que a circundam e representam possveis formas de visualizar e consultar os dados.
O cubo armazena todas as informaes relacionadas a um determinado assunto, de maneira a
permitir que sejam montadas vrias combinaes entre elas, resultando na extrao de vrias
vises sobre o mesmo tema.

Por exemplo, voltando ao exemplo da rede de lojas de departamento, podemos

considerar o total de vendas de um determinado produto em um perodo do ano (como um
ms) em uma loja especfica. Ns podemos imaginar estes dados atravs de um cubo
tridimensional, onde uma dimenso representa os produtos disponveis, a outra o perodo e a
ltima as lojas da rede, como mostrado na figura 14:

produtos

meia

30

80

27

56

blusa

73

90

82

15

cala

55

13

80

95

lenol

50

85

75

70

sapato

20

74

79

74

Jan/04

Fev/04

Mar/04

Abr/04

03
02
01

lojas

perodo

Figura 14: Exemplo de um cubo aplicado ao sistema de vendas de uma rede de lojas de
departamento
No exemplo acima, demonstramos um cubo de trs dimenses. Se acrescentarmos
mais uma dimenso (cliente, por exemplo), teremos ento um hipercubo de quatro dimenses.

50
Para se visualizar a anlise multidimensional em cubo utiliza-se a tcnica de slice e dice, ou
seja, fatiar e cortar o cubo separando partes de um cubo [INMOM, 1999]. O uso integrado dos
conceitos slice e dice permite rotacionar os lados de um cubo de dados (dimenses) em
qualquer sentido, possibilitando a combinao de quaisquer dimenses e a obteno de
informaes correspondentes sobre vrios enfoques.

Entende-se que com a modelagem dimensional possvel melhorar desempenho de

consultas e facilitar anlises atravs das medidas armazenadas nas tabelas fatos e das
descries das dimenses. Esse captulo apresentou os conceitos e terminologias da
modelagem dimensional, apresentou as tabelas de fatos e tabelas de dimenso e os esquemas
estrela e floco de neve. Porm existem tcnicas para se desenvolver o modelo dimensional e
melhorar seu desempenho. Essas tcnicas sero apresentadas no prximo captulo.

51

Captulo 3 - Tcnicas de Modelagem Dimensional

As tcnicas de modelagem dimensional, ou multidimensional, representam uma
maneira de se desenvolver um modelo dimensional. Estas tcnicas tm o propsito de gerar
um modelo dimensional que seja correto do ponto de vista do negcio e apresente um bom
desempenho para a execuo de consultas. A seguir so apresentadas algumas tcnicas
interessantes de implementao da modelagem dimensional.

3.1 Granularidade
A mais importante questo de projeto que o desenvolvedor do data warehouse
precisa enfrentar, refere-se definio da granularidade do data warehouse, ou seja, o nvel
de detalhe ou de resumo dos dados existentes no data warehouse.

Quando a granularidade de um data warehouse apropriadamente estabelecida, os

demais aspectos de projeto e implementao fluem tranqilamente; quando ela no
estabelecida, todos os outros aspectos se complicam [INMON, 1997].

A razo pelo qual a granularidade a principal questo de projeto consiste no fato de

que ela afeta profundamente o volume de dados que residem no data warehouse e, ao mesmo
tempo, afeta o tipo de consulta que pode ser atendida.

Com um nvel de granularidade mais alto o volume de dados bem menor e menos
ndices sero necessrios, como a quantidade de registro geralmente bem grande, a fora de
processamento necessria para acessar os dados um fator importante.

52
O problema que medida que o nvel de granularidade aumenta, o nmero de
consultas que podem ser atendidas diminui, sendo que numa granularidade mnima as
consultas mais detalhadas podem ser respondidas.

3.1.1 Nveis duais de granularidade

As organizaes geralmente buscam uma eficincia de armazenamento e acesso a

dados, assim como querem ter a possibilidade de consultar os dados em maior detalhe. Por
isso, deve-se pensar em dois, ou mais, nveis de granularidade no data warehouse, ou seja,
nveis duais de granularidade.

Um ambiente com nveis duais de granularidade consiste em ter dados a respeito de

um mesmo assunto em granularidades diferentes. Por exemplo, em um sistema bancrio,
pode-se armazenar os lanamentos individuais em contas correntes nos ltimos 60 dias, e
armazenar o histrico resumido desses lanamentos nos ltimos 5 anos, com o valor total de
lanamentos sumarizados por ms. Tanto os dados resumidos, quanto os detalhados estaro
disponveis para o usurio.

O ponto de partida para a definio do nvel de granularidade apropriado consiste

em se fazer uma estimativa do nmero de linhas de dados que o data warehouse conter. Se
para o primeiro ano ultrapassar o total de 1.000.000 de linhas, nveis duais de granularidade se
faro necessrios [INMON, 1997].

Nveis duais de granularidade permitem que voc processe eficientemente a enorme

quantidade de solicitaes e atenda a qualquer questo que possa ser respondida. Essa a
melhor de todas as situaes e deveria ser a opo de projeto padro [INMON, 1997].

53
3.1.2 Tabelas Agregadas

Em aplicaes de anlise de dados, um dos fatores mais crticos o tempo de

resposta ao usurio devido ao grande volume de dados envolvido nas consultas desse tipo de
aplicao. Uma tcnica utilizada para obter ganhos significativos de performance a criao
de tabelas agregadas, esse um dos principais recursos para ajuste de desempenho de data
warehouses. Consiste em criar novas tabelas com os dados da tabela de fatos, mas alterando a
granularidade da mesma, gerando assim tabelas bem menores, com dados sumarizados.

evidente que se o usurio quiser fazer um drill-down na informao que estiver

analisando, isto , detalhar mais a informao, ele acabar tendo que usar tabelas noagregadas, arcando, portanto, com um tempo maior de resposta.

Todo data warehouse deve conter tabelas de agregao pr-calculadas e prarmazenada. Como deve ser evitada a granularidade mista na tabela de fatos, cada agregao
de tabela de fatos deve ocupar sua prpria tabela de fatos fsica. A figura 15 mostra algumas
agregaes que poderiam ser feitas da tabela de fatos Venda.

Figura 15: Tabela de fatos Vendas e duas tabelas agregadas originadas da agregao da
tabela Vendas.

54
importante avaliar bem o ambiente para definir quais agregaes devem ser
criadas. preciso considerar o modelo de dados (relacionamentos, hierarquias e
cardinalidades), realizar estatsticas de consultas para descobrir quais os requisitos mais
freqentes e quais consultas so mais crticas, e assim definir quais agregadas sero mais
teis, mais utilizadas.

impraticvel pensar na criao de todas as combinaes de agregao em

potencial. A utilizao de tabelas agregadas requer um esforo adicional de manuteno, alm
de aumentar o gasto com armazenamento, por isso deve-se sempre tentar criar agregadas que
correspondam a mltiplas consultas.

Outro ponto a ser considerado a distribuio estatstica dos dados, ou seja, deve ser
avaliado quantas instncias exclusivas existem em cada nvel da hierarquia e qual a
compactao ser obtida ao se passar para o nvel seguinte. Por exemplo, se uma tabela tiver
50 produtos, e esses fossem agrupados em 10 marcas, estaremos resumindo 5 linhas da tabela
base (na mdia) para calcular a agregao de marca. Nesse caso no vale o esforo de prarmazenar a agregao fisicamente. Por outro lado, se podemos evitar a consulta de 100
linhas base acessando a agregao, isso j pode ser vantajoso.

O uso de tabelas agregadas pode ser temporrio, por exemplo, se determinadas

anlises so feitas freqentemente apenas em um determinado perodo, essas tabelas podem
ser criadas apenas nesse perodo, economizando com armazenamento e manuteno. Ou ainda
tabelas que sero utilizadas apenas uma vez, em anlises especiais.

A utilizao dessas tabelas deve ser sempre monitorada para verificar se realmente
est se obtendo vantagem com a sua existncia. O benefcio gerado pela criao de uma
agregada calculado baseado na reduo do volume de dados e na freqncia de sua

55
utilizao. Deve-se sempre levar em conta a possibilidade de uma agregada ser extinta e a
manuteno que isso causaria a todo o processo.

Cada nova carga de dados no data warehouse acarretar no reclculo de toda ou

pelo menos parte das tabelas agregadas, para que ela contemple os novos dados includos.
Existem duas formas de atualizar uma tabela agregada:

Agregao completa: consiste em recriar a tabela agregada toda vez que houver
uma carga na tabela de fatos;

Agregao incremental: os dados existentes na tabela so alterados e apenas os

dados novos so inseridos.

Quando a agregao no for completa, mecanismos de limpeza precisam ser

desenvolvidos para que os dados mais antigos sejam excludos. O perodo de reteno de uma
tabela agregada nem sempre o mesmo que o da tabela de fatos. Muitas empresas adotam um
perodo maior na tabela agregada, pois os dados esto sumarizados e gastam menos com o
armazenamento. Por exemplo, uma tabela de fatos tem dados com viso diria de trs meses,
mas o usurio pode acessar os dados dos ltimos doze meses em uma viso mensal.

A deciso por qual tabela agregada utilizar para responder cada consulta no uma
tarefa to simples, pois muitas vezes a consulta pode ser executada em mais de uma tabela
agregada retornando o mesmo resultado. Em algumas ferramentas analticas, durante o
desenvolvimento do projeto so definidas as possibilidades de tabelas a serem utilizadas e a
prioridade de cada uma, sendo a escolha feita baseada nos campos que o usurio utilizar na a
consulta. Existem tambm ferramentas que determinam automaticamente qual tabela ser
utilizada na consulta, baseados no nvel de granularidade de cada uma.

56
Outra forma de implementar agregaes utilizando as vises materializadas,
apresentadas a seguir.

3.2 Vises materializadas

As vises materializadas so um tipo especial de viso, que existe fisicamente dentro
do banco de dados. Elas existem para melhorar o tempo de execuo de consultas.

Nos ambientes de data warehouse as vises materializadas so usadas para o prclculo e armazenamento de dados gerados, como totais e mdias. Tambm podem ser usadas
para pr-calcular relacionamentos com ou sem agregaes.

O otimizador de consultas do SGBD pode utilizar a viso materializada para

aumentar a performance de acesso aos dados, reconhecendo automaticamente quando uma
viso materializada pode ser utilizada para determinada requisio. O otimizador
transparentemente direciona a consulta para a viso materializada em vez da tabela original.

Essa caracterstica do otimizador pode trazer muitos benefcios para ambientes com
grandes volumes de dados, pois sem alterar a consulta do usurio, que utiliza tabelas com
grandes volumes, o otimizador interpreta consultas e obtm o mesmo resultado mais
rapidamente em uma das vises materializadas presentes no ambiente [FERNANDES, 2002].

Alguns SGBDs atualizam os dados das vises materializadas imediatamente aps as

alteraes serem efetivadas na tabela original, no havendo necessidade de processamentos
especiais durante o processo de carga do data warehouse.

57

3.3 Tcnicas de Rastreamento de Alteraes

No projeto de modelagem do data warehouse, as dimenses so normalmente
projetadas para serem independentes de tempo. Infelizmente isso no reflete o que acontece
no mundo real. Apesar de no haver mudanas constantemente nas dimenses, elas no
possuem um valor sempre fixo (o estado civil de um cliente pode alterar de solteiro para
casado, por exemplo).

Durante a fase de projeto do data warehouse, os projetistas devem determinar quais

estratgias tomar para gerenciar as alteraes nas dimenses. Esse item geralmente
esquecido pelos usurios durante a preparao dos requisitos do projeto, porm melhor estar
preparado para estas situaes o quanto antes para desenvolver o modelo de dados adequado a
essas mudanas.

preciso analisar cada atributo das dimenses, prevendo quais atitudes tomar se (e
quando) o valor deste atributo mudar no mundo real [KIMBALL, 2002], e analisar qual a
melhor alternativa para o modelo.

3.3.1 Sobrescrever o valor

Com essa abordagem, o valor antigo simplesmente substitudo pelo novo valor na
tabela de dimenso responsvel por guardar este dado, sem afetar a tabela de fatos. Essa a
soluo de implementao mais simples e til em situaes de acertos no cadastro (correo
de informaes erradas, por exemplo), ou quando no importante armazenar o valor antigo
do atributo alterado. Um exemplo a alterao da categoria do endereo do cliente Jos

58
Aguiar da Rua Pedro lvares Cabral, 299 na Vila Barros para Rua XV de Novembro, 14 no
Centro, ilustrado na figura 16 com alguns dos campos da tabela Clientes.
cod_cliente primeiro_nome sobrenome endereco
241

Jos

Aguiar

bairro

Rua XV de novembro, 14 Centro

Figura 16: Alterao de dimenso sobrescrevendo o valor antigo.

Porm essa soluo no mantm o histrico das informaes, e os fatos perdem esse
acompanhamento. Caso haja alguma agregao ou consulta criada baseada no antigo valor
deste atributo precisar ser refeita para que esta referencie o novo valor, do contrrio ela
passar a no encontrar mais registros com o valor utilizado.

3.3.2 - Adicionar uma nova linha na tabela de dimenso

Com esta abordagem, adicionado um novo registro para a dimenso que foi
alterada, contendo uma nova chave e o novo valor. Por exemplo, na alterao da residncia de
um cliente, seria inserido um novo registro desse cliente, com uma nova chave e o endereo
alterado.

Essa alternativa permite haver quantas alteraes quantas forem necessrias na

tabela de dimenso, porm pode ocorrer um crescimento muito grande dessa tabela, no sendo
uma alternativa muito adequada quando se atinge o patamar de milhes de linhas de dimenso
[KIMBALL, 2002].

Uma complicao dessa abordagem a necessidade de utilizao de chaves

substitutas (no poderia ser usado o RG do cliente, por exemplo), j que haver dois registros
referenciando o mesmo item.

59
Nas necessidades de busca de todas as Vendas para esse cliente (independente de
sua alterao), bastaria restringir a consulta pelo RG do cliente, ou pelo seu nome, retornando
ento todos os fatos que referenciam o item.

No processo de carga do data warehouse, todos os novos fatos que referenciem essa
dimenso alterada precisam conter a chave da nova dimenso, ocasionando numa partio
natural da tabela de fatos cronologicamente. Essas chaves substitutas devem estar descritas
nos metadados e serem tratadas pelas aplicaes do usurio final, que devem considerar que
se trata do mesmo item, que sofreu uma alterao em algum atributo.

A figura 17 ilustra a alterao do endereo de um cliente atravs da insero de um

novo registro na dimenso (somente so mostrados alguns atributos da tabela).

cod_cliente primeiro_nome sobrenome endereco

bairro

241

Jos

Aguiar

Rua Pedro lvares Cabral, 299 Vila Barros

854

Jos

Aguiar

Rua XV de novembro, 14

Centro

Figura 17: alterao de dimenso por insero de novo registro.

Para a deteco e manipulao das alteraes durante a carga das dimenses,

interessante adicionar um campo na tabela de dimenso contendo o resultado de um algoritmo
de checksum em cada registro. Quando os novos registros forem carregados, executa-se o
mesmo algoritmo nestes registros, caso o resultado de ambos seja igual, significa que o
registro no foi alterado e no precisa de atualizao na tabela de dimenso. Caso tenha
diferena, significa que houve alterao e que preciso adicionar uma nova dimenso para
este item, com nova chave.

60
3.3.3 Adicionar uma nova coluna de dimenso

Apesar de haver o particionamento do histrico com a abordagem anterior, ela no

permita a associao do novo valor com o valor antigo da dimenso. Muitas vezes, porm, os
usurios podem querer buscar os fatos como se a alterao no tivesse ocorrido.

Por exemplo, a pesquisa por vendas para clientes do bairro Centro s retornaria
dados a partir da data em que o novo valor entrou em vigor, e o usurio pode querer saber
como as vendas do dia se comportariam sob a estrutura do dia anterior, com os dados antigos.

Para resolver esse tipo de necessidade, uma soluo adicionar uma nova coluna na
tabela de dimenso, contendo o valor inicial de determinado atributo, e um novo atributo com
a data em que o novo valor entrou em vigor. Essa data necessria porque com essa
abordagem a chave da dimenso permanece inalterada, sendo atravs da data a nica maneira
de identificar a alterao.

Essa soluo mais complexa do que as duas anteriores, e torna necessria a

manuteno de dois campos para um atributo: um com o valor corrente, e outro com o valor
original. Essa soluo tambm no atende o objetivo de acompanhar o histrico dos dados,
pois no h o armazenamento dos valores intermedirios, apenas do atual e do original.

3.3.4 Artefatos de dados

Esta tcnica usada para preservar o relacionamento dos dados quando um ou mais
atributos so dinmicos por natureza [INMON, 1999]. Consiste na criao de uma tabela de
dimenso adicional com os dados que so alterados com o tempo, para manter o histrico dos

61
registros. Essa nova tabela contm a chave original do produto, a data de alterao, e os
demais atributos que so dinmicos.

A cada alterao na dimenso em questo, um novo registro adicionado nessa

tabela de histrico, conforme mostra a figura 18.
Cliente
cod_cliente
241
data_status
14/05/2004
primeiro_nome Jos
sobre_nome Aguiar
Histrico Cliente
cod_cliente
241
241
241
data_alteracao
15/02/2002
18/03/2003
14/05/2004
endereco
Rua Salvador, 344 Rua Pedro lvares Cabral, 299 Rua XV de Novembro, 14
bairro
Jardim Aurora
Vila Barros
Centro
Figura 18: Rastreamento de alteraes por meio de artefatos de dados.

Essa abordagem difere da abordagem que prega a insero de um novo registro na

tabela de dimenso porque alguns dados so dinmicos por natureza, enquanto outros so
estticos. Capturar todos os dados de uma dimenso a cada alterao em um atributo iria gerar
redundncia demais. Outra vantagem dessa abordagem a persistncia da chave original do
item da dimenso.

3.4 Criao de Minidimenses

No gerenciamento de alteraes nas dimenses, encontramos alguns problemas
quando uma tabela muito grande e sofre alteraes freqentemente. A utilizao da tcnica
de adicionar uma nova linha na tabela de dimenso a cada alterao se torna invivel numa

62
tabela que j contm milhes de registros, e sobrescrever tais valores faria com que o
histrico dessas alteraes fosse perdido. A criao de minidimenses uma tcnica que
permite vencer os desafios de anlise de desempenho e controle de alteraes em tabelas de
dimenso muito grandes e que mudam rapidamente.

A tcnica de criao de minidimenses consiste em dividir uma dimenso muito

grande em uma dimenso separada ou em minidimenses compostas por pequenos conjuntos
de atributos que esto sempre sendo mudados ou analisados [KIMBALL, 2002]. Esses
atributos devem estar estruturados para conter um nmero limitado de valores.

Por exemplo, no caso da tabela de Clientes, pode-se criar uma minidimenso

separada por atributos demogrficos como idade, sexo, nmero de filhos e renda familiar,
partindo do princpio que essas colunas seriam muito utilizadas em anlises.

Figura 19: Minidimenso DEMOGRFICA.

Cada registro da tabela de fatos deve conter duas chaves externas relacionadas a essa
dimenso, a chave da dimenso normal e a chave da minidimenso, como mostra a figura 19.

63
A presena da chave da minidimenso garante um bom desempenho em consultas por
atributos demogrficos.

Quando se cria uma minidimenso, os atributos devem assumir um nmero

relativamente pequeno de valores discretos, por isso, os atributos que mudam com freqncia,
como idade e receita, devem ser associados em faixas de valores. A utilizao de faixas com
associaes provavelmente o compromisso mais importante associado tcnica da
minidimenso porque, depois que decidido sobre as associaes de valor, ser difcil o
registro da tabela dimenso mudar para um conjunto diferente de associaes mais adiante. A
figura 20 ilustra como ficariam as linhas de uma minidimenso de dados demogrficos.

CHAVE DE DADOS
DEMOGRFICOS

ESTADO CIVIL

IDADE

SEXO

RENDA FAMILIAR

Solteiro

18-22

Masculino

< R$2.000,00

Casado

18-22

Masculino

< R$2.000,00

Divorciado

18-22

Masculino

< R$2.000,00

Solteiro

18-22

Masculino

R$2.000,00- R$4.000,00

Casado

18-22

Masculino

R$2.000,00- R$4.000,00

20

Solteiro

30-35

Feminino

R$5.000,00- R$8.000,00

Figura 20: Exemplo de linhas de uma minidimenso de dados demogrficos.

No caso do usurio precisar acessar o valor dos dados brutos especficos, ele dever
ser includo tambm na tabela de fatos alm de ser representado como uma associao de
valor na minidimenso de dados demogrficos, isso atenderia o usurio em consultas
especficas como essa e seria performtico em anlises mais globais.

64
Uma outra vantagem da presena da chave da minidimenso na tabela de fatos que
os perfis demogrficos histricos de um cliente, por exemplo, podem ser levantados a
qualquer momento consultando a tabela de fatos. A tabela de dimenso armazena apenas o
valor de chave da minidimenso referente aos valores atuais, no h necessidade de
armazenar os valores antigos, se isso fosse na prpria tabela de dimenso o problema de
aumentar muito a tabela que j muito grande continuaria a existir.

3.5 Criao de Novas Chaves

Tambm conhecidas como chaves sem significado, chaves inteiras, chaves no
naturais, as chaves substitutas so, basicamente, um valor inteiro, atribudo seqencialmente a
cada registro inserido, conforme a necessidade. Por exemplo: o primeiro produto inserido na
dimenso Produto teria a chave 1, o prximo teria a chave 2, e assim sucessivamente. Sua
funcionalidade exclusivamente para o relacionamento das tabelas de dimenso com a tabela
de fatos [KIMBALL, 2002].

Manter uma chave substituta para as dimenses em vez de utilizar as chaves naturais
operacionais vantajoso porque isso livra o ambiente data warehouse de alteraes
operacionais. Manter uma chave sem significado possibilita ao data warehouse ser
independente de alteraes nos sistemas transacionais para manter a compatibilidade dos
dados.

Um exemplo de chave substituta o atributo cod_loja na tabela de dimenso

Lojas. Enquanto a chave original do sistema transacional o nmero da loja (numero_loja),

65
no ambiente data warehouse foi criada a chave substituta cod_loja para evitar o
gerenciamento de alteraes na tabela de dimenso lojas, conforme ilustra a figura 21.

Figura 21: Chave substituta cdigo da loja na tabela de dimenso Lojas no lugar da chave
original nmero da loja.
Outra vantagem de chaves substitutas a performance. Muitas vezes as chaves
operacionais so volumosos textos alfanumricos. Para manter o relacionamento com a tabela
de fatos, muito espao em disco desperdiado por causa do tamanho destas chaves. No
entanto, uma chave numrica de 4 bytes consegue armazenar aproximadamente 2 bilhes de
valores, o suficiente para guardar todos os registros de uma tabela de dimenso.

A figura 22 representa a utilizao da chave substituta cod_produto utilizada no

lugar da chave original codigo_barras na tabela de dimenso Produtos. Ao se utilizar a chave
substituta (de 4 bytes) neste caso, possvel economizar cerca de 10 bytes por registro da
tabela de fatos (economia de aproximadamente 1Gb a cada 1 bilho de registros).

66

Figura 22: Chave substituta cdigo do produto para economizar espao em disco da chave
original cdigo de barras.
Como alternativa chave inteira seqencial, pode-se usar a chave operacional do
item, adicionando-se dois ou mais dgitos ao final para indicar a verso do item [INMON,
1997]. Essa alternativa no resolve o problema da performance, j que o tamanho da chave
ficar ainda maior do que a chave original, porm ajuda a rastrear as modificaes geradas
nos itens atravs da chave primria, gerando um controle de verso de fcil manipulao.

3.6 Tratamento de Dimenses e Fatos com Cardinalidade M:N

Segundo Kimball [KIMBALL et al, 1998], apesar de, normalmente, a cardinalidade
entre as dimenses e a tabela de fatos ser 1:N (um-para-muitos), podem acontecer casos em
que essa cardinalidade seja M:N (muitos-para-muitos). A identificao deste tipo de
cardinalidade empregando um desenvolvimento baseado apenas em tcnicas dimensionais no
uma tarefa trivial. Neste tipo de desenvolvimento as dimenses e a prpria tabela de fatos
so definidas de acordo com a especificao do usurio final. Para identificar a existncia da

67
cardinalidade M:N necessria uma anlise mais minuciosa, cruzando o modelo gerado com
as regras do negcio [SOARES, 1998].

Na abordagem de Kimball [KIMBALL et al, 1998], aps a definio do modelo

dimensional necessria uma anlise de cada dimenso existente, verificando-se a
cardinalidade de seu relacionamento com a tabela de fatos. O propsito desta anlise
identificar as dimenses que apresentem um relacionamento M:N com a tabela de fatos.

Quando esse tipo de cardinalidade identificado, Kimball [KIMBALL et al, 1998]

recomenda a adio de uma nova dimenso que representar uma ponte entre a dimenso
original e a tabela de fatos. Essa dimenso ponte representa efetivamente a cardinalidade
M:N, tendo alm de sua chave normal, uma chave que permite identificar o conjunto de
informaes. Essa chave, nica para um conjunto, ser inserida na tabela de fatos. Dessa
forma, ser possvel realizar as consultas pela dimenso origem, garantindo que no havero
repeties na tabela de fatos. Essa nova dimenso, mais simples, deve permitir o
desenvolvimento de consultas a partir dela para a tabela de fatos.

3.7 Tabela de fatos sem fatos

Uma das premissas na criao e populao da tabela de fatos a obrigatoriedade das
medidas serem preenchidas. No se pode ter um registro na tabela de fatos com as medidas
contendo o valor zero, pois isso iria aumentar bastante a quantidade de registros.

No data warehouse de exemplo que registra Vendas, pode haver a necessidade de

saber quais produtos no tiveram nenhuma venda em determinada data, em determinada loja.

68
No se pode inserir um registro com essas trs dimenses e preencher as medidas com zeros.

Para suprir necessidades de registrar um fato onde no temos medidas (nada

aconteceu), so utilizadas tabelas de fatos sem fatos. Uma tabela de fatos sem fatos consiste
basicamente de uma tabela que servir de relacionamento entre todas as dimenses
necessrias para atender a uma necessidade bsica, porm no contendo nenhuma medida.
Seus registros apenas relacionam as dimenses relacionadas a ela. A tabela de fatos sem fatos
tem como linhas todo o universo possvel de relacionamento entre as dimenses envolvidas,
sem nenhum atributo de medida.

Figura 23: Tabela de fatos sem fatos Produtos a Venda.

69
No caso dos produtos que no foram vendidos, seria criada uma tabela fato sem
fatos chamada Produtos a Venda. Essa tabela possui apenas os atributos para relacionamento
com as tabelas de dimenso Produtos, Lojas e Data. importante notar que ela no possui
relacionamento com a tabela de dimenso Clientes, e tambm no possui a dimenso
descaracterizada Venda, j que a granularidade desta tabela o produto por loja por data,
conforme mostra a figura 23.

Essa tabela ento preenchida com todo o universo de produtos disponveis para
venda em cada loja, a cada dia, contendo os registros com esses relacionamentos. Para saber
quais produtos no foram vendidos, basta consultar na tabela Produtos a Venda o universo de
produtos nas datas/lojas desejadas e, aps consultar a tabela de fatos Vendas com as mesmas
condies, a diferena entre os dois resultados a resposta ao problema.

Como a tabela de fatos sem fatos armazena um registro para cada associao
possvel entra as dimenses, ela geralmente contm uma quantidade de registros muito
grande. No necessrio existir uma relao entre a tabela de fatos sem fatos e a tabela de
fatos, podendo, no nosso exemplo, a granularidade da tabela de fatos sem fatos ser produtos
disponveis por semana, ao invs de usar granularidade diria. Isso reduziria a quantidade de
registros da tabela, porm continuaria a atender necessidade.

Uma tabela de fatos sem fatos tambm pode ser usada como uma tabela associativa
entre as dimenses, onde no necessrio armazenar nenhuma medida. O registro de eventos
normalmente feito desta forma, onde no existem medidas para ser analisadas, apenas a
relao entre as dimenses.

Um exemplo dessa abordagem um data warehouse de uma instituio de ensino,

com a necessidade de analisar os alunos, as matrias que eles cursam, e em quais campi. Para

70
isso, pode-se criar uma tabela de fatos sem fatos Matrcula possuindo relacionamentos com as
dimenses Alunos, Matrias e Campi. Essa tabela armazenaria os registros de quais alunos
cursam quais matrias, e em qual campus. Apenas estas so as informaes importantes para
este data warehouse, no existe nenhuma medida para ser armazenada e analisada, portanto a
tabela de fatos somente teria as chaves das tabelas de dimenso.

3.8 Dados desnormalizados

Redundncia gerenciada uma caracterstica do data warehouse que ajuda no
suporte ao processamento de informaes, para dar ao usurio um conjunto de dados
adequados necessidade do negcio, permitindo visualizar os dados como informaes mais
facilmente [INMON, 1999].

Os dados redundantes normalmente so desnormalizados armazenando-se as

definies dos registros juntamente com os prprios cdigos, na mesma tabela. Dessa
maneira, no so necessrias repetidas junes entre tabelas de dados (tabelas de fatos) e
tabelas de referncia (tabelas de dimenso) para obter as definies descritivas dos dados,
apenas a consulta a uma tabela j traz essas informaes, ao invs de cdigos confusos.

Isso permite ao usurio fazer uma consulta SQL no banco de dados qualificando sua
consulta pelo cdigo (mtodo mais eficiente), e exibindo o resultado pelas suas descries
(mtodo mais informativo) sem precisar juntar tabelas distintas, melhorando a performance
das consultas.

71
No tabela de dimenso Produtos, esto armazenados os campos de cdigo da
categoria (cod_categoria) e tambm o campo descrio da categoria (desc_categoria). Com
isso, o usurio pode limitar a consulta pelo cdigo, enquanto que o resultado exibido pela
descrio, sem relacionar outras tabelas, conforme exemplifica a figura 24.

Figura 24: Dados desnormalizados na tabela de dimenso Produtos.

Deve ser aplicado um controle sobre quais dimenses so boas candidatas a serem
desnormalizadas na tabela de fatos. Quando o valor sempre preenchido na tabela de
dimenso, e quando a tabela relacionada existe somente para descrever este dado, uma boa
idia fazer a desnormalizao. Porm melhor deixar uma tabela de dimenso normalizada
quando ocorrer uma das seguintes situaes:

a dimenso no preenchida constantemente, ou seja, o dado preenchido na

tabela de dimenso somente em uma pequena porcentagem de registros
[INMON, 1999];

a dimenso armazena dados importantes alm da descrio do campo, isto ,

outros dados da tabela relacionada so importantes para o esquema, alm da
definio descritiva do dado [INMON, 1999];

72

quando existe uma hierarquia que pode ser usada para diferentes modos de
agregao e classificao dos dados para diferentes propsitos [INMON, 1999].

3.9 Dimenses de tempo

Todo data mart geralmente uma relao de fatos baseados em um tempo, por isso
recomendado a criao de uma dimenso de tempo, como a dimenso Data criada no
modelo exemplo, ao invs de armazenar a data diretamente na tabela de fatos.

Uma dimenso Data explcita importante porque muitas vezes uma consulta SQL
no permite um filtro de datas por dias de semana e finais de semana, ou por feriados,
perodos fiscais, temporadas e eventos importantes. Com isso, uma tabela de dimenso Data
permite armazenar todas as opes de filtragem desejadas e facilitar consultas e anlises de
dados.

Um exemplo de tabela de dimenso Data a utilizada no exemplo do captulo 2,

conforme ilustrado na figura 25.

Na tabela de dimenso Data armazenado um registro por dia, no sendo utilizada

para armazenar dados de hora. Isso permite armazenar registros de um perodo de dez anos
em uma tabela de dimenso Data, totalizando em apenas 3.650 registros, sendo uma tabela de
dimenso relativamente pequena.

73

Figura 25: Tabela de dimenso Data se relacionando com a tabela de fatos Vendas no modelo
do sistema de vendas de lojas de departamento, o que permite a visualizao dos fatos por
diversos critrios diferentes de data.
Nas necessidades de armazenar a hora da transao da anlise em questo, mais
conveniente a criao de uma dimenso Hora do dia, separada da dimenso Data, contendo
registros para cada minuto do dia, resultando em uma tabela com apenas 1.440 registros. Caso
fosse armazenada a hora na dimenso Data, com granularidade de minutos, a quantidade de
registros necessrios para o armazenamento de um perodo de dez anos aumentaria para
5.256.000, um valor extremamente alto e difcil de manipular [KIMBALL, 2002].

A chave primria dessa tabela pode ser um campo numrico inteiro, ao invs de um
campo de data. Os campos de data baseados no SQL normalmente so armazenados em 8
bytes, enquanto um campo inteiro armazenado em apenas 4 bytes. Isso representa uma
economia de 4 bytes em cada registro da tabela de fatos, onde existe uma chave estrangeira
referenciando essa tabela.

74
Observe na figura 26 como ficariam preenchidos alguns atributos de uma dimenso
Data, para as datas "16/02/2004" e a "21/04/2004".

CHAVE
DA DATA

DIA
DIA DA SEMANA

NUMRICO
DA SEMANA

DIA DO

DIA DO

MS

NOME DO

INDICADOR

MS

ANO

CALENDRIO

MS

DE FERIADO

segunda-feira

16

47

fevereiro

no feriado

50

quarta-feira

21

112

abril

feriado

Figura 26: Exemplo de linhas em uma dimenso Data, a primeira linha corresponde data
"16/02/2004" e a segunda a "21/04/2004".
A dimenso Data deve conter todos os atributos que podem ser utilizados para
anlise e seleo dos dados. melhor armazenar todos esses atributos de tempo na tabela ao
invs de usar as aplicaes de acesso para converter e classificar as datas da maneira desejada.

Na dimenso Data do exemplo, foram colocados atributos como dia da semana, dia
no ms, dia no ano, ms calendrio, nome do ms, semana fiscal, indicador de feriado, etc.
Mas uma dimenso Data pode conter uma infinidade de campos, todas as interpretaes de
datas teis para o negcio devem ser armazenadas. Por exemplo, para determinado negcio
pode ser interessante saber o nmero do dia na poca, ou seja, um nmero de dia consecutivo
comeando pelo incio de alguma poca. A figura 27 mostra uma dimenso Data com mais
alguns atributos que podem auxiliar nas anlises.

75

Figura 27: Dimenso Data com diversos atributos, todas as interpretaes de datas teis para
o negcio devem ser armazenadas.

Entende- se que as tcnicas de modelagem dimensional so importantes para gerar

um modelo correto do ponto de vista do negcio e com um bom desempenho. Neste captulo
foi apresentada a importncia de adotar a granularidade adequada, alm de abordar tabelas
agregadas, tcnicas de rastreamento de alteraes, minidimenses, desnormalizao, entre
outras tcnicas.

76

Captulo 4 - Questes sobre acesso a dados multidimensionais

J foi apresentado como uma modelagem dimensional pode prover as informaes
necessrias a processos analticos. Tambm foi visto como construir esse modelo e suas
vantagens sobre o modelo relacional para este tipo de aplicaes. Porm, com este modelo,
uma quantidade muito maior de informaes precisa ser armazenada e, conseqentemente,
recuperadas. No tarefa simples recuperar e atualizar as informaes contidas em modelo
dimensional, agregando, derivando ou simplesmente selecionando-as sem que seja necessrio
um tempo de processamento elevado.

As estratgias de que este captulo trata podem ser adotadas para reduzir este tempo
de processamento. Embora muitas vezes no seja possvel obter um tempo de resposta
consideravelmente rpido, se comparada a operaes transacionais, a aplicao destas
tcnicas pode trazer um ganho significativo neste tempo, reduzindo o custo de processamento
de muitas atividades em um ambiente de processamento analtico.

4.1 Estratgias de Processamento de Consultas

Conforme foi visto, as consultas em um sistema OLAP so muito diferentes das
consultas realizadas em um sistema OLTP. Enquanto um sistema OLTP desenvolvido para
retornar resultados de um nmero limitado de consultas, este no o caso nos sistemas
OLAP. Os modelos dimensionais tentam abranger essas novas caractersticas. Como
conseqncia, fornecedores e pesquisadores comearam a pensar em maneiras de resolver
consultas envolvendo agregaes, rankings, etc, em bancos de dados com muitos gigabytes de

77
dados. O uso correto de ndices uma estratgia de otimizao no processamento das
consultas.

Usualmente, os bancos de dados dos sistemas OLTP e os data warehouses residem

em diferentes sistemas, sendo que no existem limitaes de ndices nos data warehouses.
Pode-se criar ndices em quantas colunas das tabelas forem necessrias. Em geral, os data
warehouses podem ser indexados com ndices de alta seletividade.

Por exemplo, uma consulta para saber quantas vendas houve para homens de So
Paulo com escolaridade universitria, num sistema OLTP, geraria problemas com ndice, j
que a coluna "sexo" no poderia ser indexada, devido sua alta seletividade. Alm disso, ter
ndices em muitas colunas levaria a problemas de performance durante atualizaes da tabela.
Ento, uma consulta desse tipo seria otimizada, normalmente, por apenas um ndice. Em um
banco de dados com bilhes de vendas para milhares de clientes, o tempo de resposta no
seria aceitvel.

Na consulta do exemplo, o processador de consultas precisa selecionar dados na

tabela de Clientes, que vai retornar as linhas de acordo com os atributos "estado", "sexo" e
"educao", e ento fazer a juno com a tabela de Vendas.

Para esse tipo de problema, foram criadas novas tcnicas de indexao e

processamento da consulta.

4.1.1 ndices bitmap

Em um ndice B-tree tradicional, os ns-folhas possuem um valor e a lista de

posies das linhas que satisfazem esse valor. Em alguns casos, possvel utilizar uma

78
alternativa melhor que essa: em vez de uma lista com as posies, pode-se utilizar um vetor
de bits [VAISMAN, 1998].

Um nmero associado a cada linha de uma tabela (por exemplo, Clientes).

Considerando a necessidade de criar um ndice no atributo "educao", presumindo que haja 5
possveis valores para esse atributo. O ndice seria um vetor de bits de tamanha N (sento N a
quantidade de registro em Clientes). Em cada posio desse vetor, o bit preenchido com 1
ou 0 caso o cliente na linha em questo possua educao universitria ou no,
respectivamente. Para ter um ndice bitmap, basta criar um vetor de bits para cada valor
possvel do atributo, e armazenar o vetor nos ns folhas do B-tree.
Como exemplo, pode-se considerar o seguinte bitmap:
0011011001001.....1
Esse vetor afirma que os clientes nas linhas 3, 4, 6, 7, 10, 13 e N possuem educao
universitria.

fcil estimar o tamanho desse tipo de ndice: considerando como exemplo a tabela
Clientes com 250.000 linhas, e 5 possveis valores para o atributo "educao". Um ndice
bitmap neste atributo (considerando somente os ns folhas) iria ocupar 250.000 * 5 / 8 = 0.14
mb. Um ndice B-tree tradicional, como este usado no exemplo, iria ocupar 250.000 * 4kb =
0.95 mb. Essa no uma diferena significativa na tabela de Clientes, mas em uma tabela
com bilhes de linhas (como a tabela Vendas), passa a ser um ganho considervel.
O espao necessrio para ndices bitmap proporcional quantidade de valores do
ndice (enquanto ndices tradicionais so independentes dessa quantidade). Para sistemas de
suporte a deciso, que necessitam de ndices em atributos de grande seletividade, esses ndices
so os mais adequados [VAISMAN, 1998].

79
A maior vantagem dos ndices bitmap, no entanto, a alta performance alcanada no
processo de consulta [VAISMAN, 1998]. Quando for necessrio realizar uma operao com
AND, OR ou NOT, o sistema apenas far uma comparao de bits.

No exemplo, a seleo busca sexo = "M" e educao = "Universitrio", supondo

dois vetores de bits para cada valor como:

0110010110010110 para sexo = M e

1001010110110101 para educao = Universitrio
simples para um programa em qualquer linguagem, com um custo de
processamento muito baixo, gerar um vetor que armazene o resultado da operao AND,
comparando bit a bit:
0000010110010100 = sexo = M e educao = Universitrio

4.1.2 ndices com juno

Uma juno conhecida por ser a operao com maior custo de performance em um
SGBD. Existem algumas estratgias de processamento de junes em modelos relacionais,
como hash-join, sort-merge join, entre outras. Para estratgias focadas para o suporte a
deciso, as principais estratgias so o uso de ndices com juno e star join [VAISMAN,
1998].

Essas estratgias tiram vantagem do esquema estrela do data warehouse, no qual a

tabela de fatos est relacionada com as dimenses por chaves estrangeiras. As junes que
sero requeridas pelas consultas iro usar essas chaves estrangeiras.

Considerando a seguinte consulta:

80

sum(Vendas)

( Vendas

( estado=SP ( Cliente ) ) )

possvel criar um ndice com uma juno na chave estrangeira, na tabela de

Vendas, junto com o atributo "estado".

Isso parece estranho, porque o estado no pertence a "Vendas". Na verdade, criado

um ndice apontando para os registros de Vendas que armazenam vendas para clientes de
SP. Isso feito primeiramente com a juno das tabelas pela chave estrangeira, e ento
criando um bitmap em Vendas para cada estado. A figura 28 ilustra como ficaria um ndice
bitmap para o exemplo de Vendas.

Cada bitmap ter N bits, sendo N o nmero de linhas na tabela Vendas, e no caso de
ter mais condies, pode-se criar um ndice com juno para cada condio.
Vendas
cod_venda
1
2
3
4
5
6

cod_produto
5
45
8
13
2
9
Cliente
cod_cliente
1
2
3
4

cod_cliente
3
3
2
4
1
4

qtde_vendida
50
100
200
150
300
50

estado
SP
RJ
SP
PR

O ndice ficaria como no exemplo:

SP 110010
RJ 001000
PR 000101
Figura 28: Exemplo de ndices com juno no data warehouse de Vendas.

81
Esse conceito pode ser generalizado, no sendo restrito a apenas um relacionamento,
e tambm til quando as condies so colocadas em diferentes tabelas de dimenses. A
vantagem desse tipo de ndice sua flexibilidade, facilitando a alterao ou adio de
condies.

Alguns sistemas permitem o uso de ndices para junes com mais de duas tabelas.
A idia a mesma do ndice explicado anteriormente, ou seja, filtrar valores da tabela de
fatos. Mas, neste caso, um ndice multi-colunas criado.

Como exemplo, pode-se utilizar a tabela de fatos Vendas e as tabelas de dimenses

Tempo e Cliente, e a necessidade de buscar a quantidade de vendas dos clientes de So Paulo,
no ms de dezembro de 2003, com essa consulta representada abaixo:

sum(Vendas) ( Vendas ( estado=SP ( Cliente ) )

( mes_calendario=12 ano_calendrio=2003( Data ) ) )
Para criar um ndice, preciso fazer a juno das trs tabelas e criar o ndice na
forma (estado, mes_calendario), com um registro no ndice para cada par de valores da tabela
Vendas.

Os sistemas que implementam esse tipo de estratgia de indexao precisam saber

da existncia desses ndices ao processas as consultas, para tirar melhor proveito.

4.1.3 Junes estrela (Star Join)

Star Join uma tcnica que aumenta a performance de uma juno sem criar ndices
com juno, considerando-se que h um ndice em cada um dos atributos envolvidos nas
restries.

82
Para a consulta de vendas de dezembro de 2003, para clientes de SP, apresentada
anteriormente, o sistema iria primeiro selecionar todos os cdigos dos clientes em "SP",
armazenando-os em uma tabela temporria (T1). Ento seriam selecionados todos os dias do
ms de dezembro de 2003 e armazenados em outra tabela temporria (T2), e finalmente, seria
feito o produto cartesiano T1 X T2 para fazer a juno com o ndice (cod_cliente, cod_data) j
existente na tabela Vendas.

Um problema dessa tcnica acontece quando a tabela de fatos esparsa (o que

bastante comum em grandes organizaes). Neste caso, os recursos so divididos para
calcular o produto cartesiano, para formar linhas que no participaro da juno. Cabe utilizar
a tcnica mais adequada em cada situao.

4.2 Operador CUBE na Agregao Relacional

Aplicaes de anlise de dados, geralmente, fazem agregao dos dados atravs de
muitas dimenses. Essas aplicaes sumarizam valores dos dados, extraem informaes
estatsticas e ento contrastam uma categoria com outra.

A agregao dos dados realizada atravs de funes de agregao SQL e o

operador GROUP BY. Atravs destes operadores so produzidas respostas de zero-dimenso
ou uma-dimenso. Para serem produzidas respostas com n-dimenses utilizado o chamado
operador CUBE.

83
4.2.1 Agregao no SQL
O SQL padro conta com cinco funes de agregao de valores: COUNT ( ) usado
para contar a quantidade de registros em uma tabela de acordo com o critrio, o SUM ( ) que
soma os valores em uma tabela de acordo com critrios, o MIN ( ) que seleciona o valor
mnimo em uma tabela, o MAX ( ) que seleciona o valor mximo em uma tabela e o AVG ( )
que obtm o valor mdio em uma seleo. Alm dessas, o SQL tambm capaz de agregar
valores que se repetem em uma seleo, usando o comando DISTINCT.

Por exemplo, poderamos considerar o cdigo abaixo aplicado sobre a tabela

EMPREGADOS (figura 29):
SELECT AVG(salario) AS media_sal
FROM Empregados;
Nome
Paulo Mendes
Antonio Gusmo
Patrcia da Silva
Marisa Santana

depto
121
121
010
005

salario
3.000,00
5.000,00
1.500,00
8.000,00

Figura 29: Tabela Empregados.

E como resultado obteramos o seguinte (figura 30):

Media_sal
4.375,00
Figura 30: Mdia dos salrios.
Da mesma forma, os outros operadores podem ser aplicados obtendo-se os
resultados de acordo com cada operador utilizado. A exceo o comando DISTINCT usado
na sintaxe da seguinte maneira:

84
SELECT COUNT(DISTINCT Depto) AS qtd_dep
FROM Empresa;
Obtendo-se o seguinte resultado (figura 31):

Qtd_dep
3
Figura 31: Quantidade de departamentos.
Essas funes so extremamente teis, mas quando tratamos de consultas analticas
de dados, elas no so suficientes. Existem alguns tipos de consulta muito complexas de
serem implementadas com o SQL tradicional e so desses problemas que o prximo tpico
trata com mais detalhes.

4.2.2 Problemas com o group by

Como vimos, o SQL possui algumas funes de agregao que, embora atendam
muitas demandas, no so suficientes para atender a complexidade de um processo de
consulta analtica.

Certas agregaes analticas so extremamente complexas, embora no sejam

impossveis de serem construdas com o SQL tradicional. Dentre os problemas mais comuns
encontrados nestes casos esto pertinentes ao uso de roll-up/drill-down [GRAY, 1995].

Roll-up e drill-down usam totais e sub-totais para relatrios. Relatrios comumente

agregam dados em um nvel menos granular e ento, sucessivamente, diminuem essa
granularidade at obterem um resultado mais detalhado sobre o dado. O relatrio de vendas de
carro na figura 32 pode dar a idia deste problema.

85
A tabela representada na figura 32 no pode ser relacional, uma vez que possui
valores nulos na chave primria. A figura 33 uma tabela relacional e mostra uma
representao mais conveniente que a do exemplo anterior.

Modelo

Ano

Cor

GM

1994

Preto
Branco

1995

Preto
Branco

Vendas por
Modelo,
Ano e Cor
50
40

Vendas por
Vendas por
Modelo e
Modelo
Ano

85
115

90

200

290

Figura 32: Tabela de Roll Up de Vendas de carro por Modelo, por Ano e por Cor.

Modelo
GM
GM
GM
GM
GM
GM
GM

Ano
1994
1994
1994
1995
1995
1995
ALL

Cor
Preto
Branco
ALL
Preto
Branco
ALL
ALL

Unidades
50
40
90
85
115
200
290

Figura 33: Tabela de Vendas.

Para se construir essa tabela a soluo proposta foi incluir um valor chamado ALL
para denotar a agregao dos campos. Desta forma, um Roll-up pode ser calculado com este
cdigo:

SELECT
FROM
WHERE
GROUP BY

Modelo, 'ALL', 'ALL', SUM(Unidades)

Vendas
Modelo = 'GM'
Modelo

86
UNION
SELECT
FROM
WHERE
GROUP BY

Modelo, Ano, 'ALL', SUM(Unidades)

Vendas
Modelo = 'GM'
Modelo, Ano

UNION
SELECT
FROM
WHERE
GROUP BY

Modelo, Ano, Cor, SUM,(Unidades)

Vendas
Modelo = 'GM'
Modelo, Ano, Cor;

A representao da tabela de vendas (figura 33), com a unio dos GROUP BYs,
resolve o problema da representao dos dados agregados em um modelo de dados
relacional.

Este exemplo um roll-up de 3 dimenses. Agregaes de n-dimenses requerem

tambm n-unies (Union), ou seja, quanto mais dimenses a serem agregadas, mais complexo
ser o cdigo SQL para acessar os dados.

Note que a tabela de vendas (figura 33) no contempla a agregao das linhas que
representam o total de vendas por ano. As linhas que no foram includas so as seguintes
(figura 34):
Modelo
Ano
GM
ALL
GM
ALL

Cor
Preto
Branco

Unidades
135
155

Figura 34: Linhas no includas na agregao da tabela de Vendas.

Para que as mesmas sejam includas na consulta, necessrio inserir ao final do
cdigo utilizado na obteno da tabela de vendas da figura 34 as seguintes linhas:

87
UNION
SELECT
FROM
WHERE
GROUP BY

Modelo, 'ALL', Cor, SUM (Vendas)

Vendas
Modelo = 'GM'
Modelo, Cor;

Cross tabulation a agregao de duas ou mais dimenses. Por exemplo, na figura

35 podemos observar uma cross-tab de duas dimenses.

GM
Preto
Branco
Total (ALL)

1994 1995
50
40
90

85
115
200

Total
(ALL)
135
155
290

Figura 35: Cross tabulation de vendas da GM.

A representao de uma cross tab equivalente a uma representao relacional,

usando o valor ALL, generaliza-se uma cross tab de n-dimenses.

4.2.3 Operador CUBE

Podemos dizer que a dimenso 0 de um cubo de dados um ponto, a dimenso 1

uma linha com um ponto, a dimenso 2 uma cross tabulation, um plano, duas linhas e um
ponto enquanto a dimenso 3 um cubo com trs interseces de cross tabulations de duas
dimenses. A Figura 36 apresenta, dentro do exemplo que estamos utilizando, um cubo de
dados [GRAY, 1995].

88
Group By
(com total)

Cross Tab

By Color

Agregao

Ford GM

Vermelho

Vermelho

Branco

Branco

Azul

Azul

Sum

By Color

Por Fabricante
Sum

Sum

As Agregaes no Cubo de Dados

Por fabricante e ano
2001

2002

2003

2004

Por fabricante

Ford
GM
Vermelho

Por ano

Branco
Azul

Por Cor e Ano

Por fabricante e Cor
Por cor

Sum

Figura 36: Agregaes em um cubo de N Dimenses.

O operador Data Cube ou cubo de dados a generalizao em N-Dimenses de

funes simples de agregao. Esse operador constri uma tabela contendo todos os valores
agregados e o total agregado representado como uma tupla:

ALL, ALL, ALL, ..., ALL, f(*)

89
O GROUP BY tradicional pode gerar um cubo de dados de n-dimenses.
Agregaes com poucas dimenses aparecem como pontos, linhas, planos, cubos ou
hipercubos. Pontos em planos com mais dimenses, possuem menos valores ALL.

A sintaxe SQL usando o operador CUBE a seguinte:

GROUP BY (
{ ( < nome-da-coluna><expresso>)
[ AS <nome correlato> ]
[<clusula>]
, ...)
[WITH (CUBE ROLLUP)]
}
A figura 37 representa o uso da sintaxe SQL abaixo:
SELECT
Modelo, Ano, Cor, SUM(Vendas) AS Vendas
FROM TBL_VENDAS
WHERE Modelo IN (Ford , GM)
AND
Ano BETWEEN 2002 AND 2004
GROUP BY Modelo, Ano, Cor
WITH CUBE;
Podemos considerar que a cardinalidade de N atributos so C1, C2..., CN, ento, a
cardinalidade do cubo resultante, pode ser expressa pela projeo de (C1+1). O Valor extra
em cada domnio ALL. Por exemplo, a tabela TBL_VENDAS possui 2x3x3=18,
considerando 2 possveis valores para o atributo Modelo ('
FORD'e '
GM'
), 3 para Ano ('
2002'
,
'
2003'e '
2004'
) enquanto a tabela resultante aps a aplicao do operador CUBE, possui
3x4x4=48, incluindo o valor ALL.

90

Modelo
GM
GM
GM
GM
GM
GM
GM
GM
GM
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD

TBL_VENDAS
Ano
Cor
Vendas
2002 Vermelho
5
2003 Branco
13
2004 Azul
12
2002 Vermelho
25
2003 Branco
27
2004 Azul
32
2002 Vermelho
14
2003 Branco
17
2004 Azul
31
2002 Vermelho
52
2003 Branco
16
2004 Azul
20
2002 Vermelho
6
2003 Branco
8
2004 Azul
16
2002 Vermelho
20
2003 Branco
54
2004 Azul
9

CUBE

Modelo
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
FORD
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
GM
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL

TBL_Vendas CUBO
Ano
Cor
2002
ALL
2002
Azul
2002
Branco
2002
Vermelho
2003
ALL
2003
Azul
2003
Branco
2003
Vermelho
2004
ALL
2004
Azul
2004
Branco
2004
Vermelho
ALL
ALL
ALL
Azul
ALL
Branco
ALL
Vermelho
2002
ALL
2002
Azul
2002
Branco
2002
Vermelho
2003
ALL
2003
Azul
2003
Branco
2003
Vermelho
2004
ALL
2004
Azul
2004
Branco
2004
Vermelho
ALL
ALL
ALL
Azul
ALL
Branco
ALL
Vermelho
2002
Azul
2002
Vermelho
2002
Branco
2003
Azul
2003
Vermelho
2003
Branco
2004
Azul
2004
Vermelho
2004
Branco
ALL
Azul
ALL
Vermelho
ALL
Branco
2002
ALL
2003
ALL
2004
ALL
ALL
ALL

Venda
78
20
6
52
78
54
8
16
45
9
16
20
201
83
30
88
44
14
25
5
57
17
27
13
75
31
32
12
176
62
84
30
34
57
31
71
29
35
40
32
48
145
114
118
122
135
120
377

Figura 37: Data Cube de 3 dimenses construdo a partir da tabela tbl_vendas.

Cada valor ALL representa um conjunto de todos os valores que foram agregados.
Na tabela resultante os conjuntos respectivos so:
Modelo.ALL = ALL (Modelo) = ('Ford','GM')
Ano.ALL
= ALL (Ano)
= ('2002','2003','2004')
Cor.ALL = ALL (Cor)
= ('Vermelho','Branco','Azul')

91
O valor ALL aparece como um valor essencial na agregao usando o comando
CUBE. Sem ele, seria impossvel obter super agregaes como visto na figura 37 (totais por
Modelo, Ano e Cor exibidos simultaneamente, assim como totais gerais), porm, ele cria uma
complexidade substancial. Ele um "no-valor" como o NULL e durante sua implementao
alguns aspectos devem ser observados. Abaixo citamos alguns:

O ALL torna-se uma palavra-chave denotando um conjunto de valores.

A sintaxe ALL [NOT] ALLOWED deve ser adicionada sintaxe de definio da

coluna e aos atributos da coluna no catlogo do sistema, para permitir ou no a
incluso de valores ALL.

ALL, como NULL, no participa de nenhuma agregao, exceto COUNT().

Embora existam outros aspectos, estes do uma idia das particularidades ao se

utilizar o valor ALL [GRAY, 1995].

Embora o SQL padro conte com diversas funes de agregao muito teis no diaa-dia de um usurio, estas no so suficientes para atender completamente a demanda de
agregaes exigidas por processos analticos. Nesta demanda pode-se considerar a
necessidade de se realizar Roll-Up e Drill-Down das informaes. Para que o SQL consiga
agrupar as informaes para exibi-las de maneira eficiente para um processo que envolva
Roll-Up/Drill-Down, complexas consultas precisam ser realizadas. O operador CUBE reduz a
complexidade destas consultas, uma vez que, por si s, consegue extrair as informaes no
formato adequado com as devidas agregaes.

92

4.3 Manuteno de Vises

Uma viso uma relao derivada, definida a partir das relaes bases, ou seja,
relaes que esto fisicamente armazenadas. Portanto, uma viso define uma funo de um
conjunto de tabelas base em uma tabela derivada, essa funo recomputada toda vez que
uma viso referenciada.

As vises materializadas so um tipo especial de viso, onde os registros so

armazenados fisicamente dentro do banco de dados. Nos ambientes de data warehouse elas
so utilizadas para pr-clculos e armazenamento dos dados gerados, so usadas tambm para
pr-calcular relacionamentos com ou sem agregaes. A utilizao dessas vises pode gerar
uma melhoria significativa no tempo de execuo de consultas.

Em contrapartida, quando um dado base for atualizado, as vises materializadas

derivadas desse dado tambm devem ser atualizadas. O processo de atualizar uma viso
materializada em resposta a modificaes em um dado base chamado de manuteno de
vises. Esse processo nem sempre envolve recalcular a viso completamente, na maioria das
vezes isso seria um desperdcio de processamento, pois possvel computar nas vises apenas
as modificaes ocorridas nas relaes base. Isto chamado de manuteno incremental de
vises.

Existem quatro dimenses atravs das quais o problema da manuteno de vises

pode ser analisado [GUPTA, 1995]:

Dimenso Informao: Refere-se quantidade de informaes que esto

disponveis para manuteno de vises. Essa dimenso trata de quais dados so

93
usados para computar uma alterao em uma viso, como quais relaes base
tm que ser acessadas, as restries de integridade, chaves, etc.

Dimenso Modificao: Refere-se a quais modificaes um algoritmo de

manuteno de vises pode tratar. Incluso e excluso de registros nas relaes
bases, alterao de registros, se so tratados diretamente ou so modelados como
uma excluso seguida de uma incluso, as mudanas na definio da viso,
conjuntos de alteraes, etc.

Dimenso Linguagem: Refere-se a fatores como se a viso pode ser expressa

como uma consulta seleo-projeo-juno, ou em algum outro subconjunto de
lgebra relacional, se utiliza SQL ou subconjunto de SQL, se pode ter
duplicidades, usar agregao, recursividade, etc.

Dimenso Instncia: Refere-se possibilidade dos algoritmos de manuteno de

vises trabalharem ou no sobre todas as instncias de um banco de dados e se
eles trabalham ou no para todas as instncias de modificao. Sendo assim uma
instncia pode ser de dois tipos: instncia de banco de dados e instncia de
modificao.

A seguir so apresentados exemplos que ilustram as dimenses utilizadas para a

classificao do problema da manuteno de vises.

Exemplo 1: Dimenses Informao e Modificao

Em uma empresa de desenvolvimento de sistemas, os mdulos desenvolvidos

podem ser genricos, sendo, nesses casos, reaproveitados em diversos sistemas, tendo apenas

94
um custo de adaptao. Considerando a seguinte relao que trata o mdulo, custo da
adaptao e o sistema em que o mdulo foi incorporado:

Sistema_modulo(modulo, custo, sistema)

E a seguinte viso que contm todos os mdulos que custaram mais do que R$ 1000:

Modulos_caros(modulo) = modulo custo>1000(Sistema_modulo)

Se for inserido um registro como (mod1, 500, CW), isso no gera nenhum impacto
na viso, pois o custo menor que R$1000. Porm, se for includo o registro (mod2, 1250,
WH) ser necessrio contemplar esse registro na viso, pois o custo maior que R$1000.
Diferentes algoritmos de manuteno de vises podem ser designados, dependendo das
informaes disponveis para determinar se o mod2 deve ser inserido na viso:

Se a viso materializada antiga estiver disponvel, basta consult-la para verificar

se o mdulo mod2 j est na viso, se estiver a viso no precisa ser modificada,
seno o mod2 dever ser inserido.

Se a relao base Sistema_modulo estiver disponvel, ela pode ser utilizada para
verificar se existe algum registro com o mesmo mdulo, mas com o custo igual
ou maior. Se for encontrado algum registro, o novo registro inserido no precisa
ser contemplado na viso.

Se o mdulo for chave na relao Sistema_modulo e esse mdulo est sendo

includo agora, significa que ele no pode j estar na viso, portanto deve ser
inserido.

95
Outro problema da manuteno de vises responder s excluses realizadas.
Supondo que o registro (mod1, 6000, IF) seja excludo. Como o custo dele maior que 1000,
esse mdulo est na viso, mas no se pode simplesmente excluir o mod1 da viso, preciso
saber se no existe outro registro na relao base que determine com que o mod1 continue na
viso, como, por exemplo, o registro (mod1, 2000, DN). Portando, o algoritmo de
manuteno no capaz de resolver o problema da excluso utilizando apenas a viso
materializada, sempre sero necessrias outras informaes como os prprios dados da
relao base, restries ou chaves.

Exemplo 2: Dimenses Linguagem e Instncia

O exemplo 1 considerou uma linguagem de definio de viso consistida de

operaes de seleo e projeo, no exemplo 2, ser ampliada a linguagem de definio da
viso com a operao juno (join). A viso definida a seguir mostra os mdulos distintos que
fazem parte de sistemas em fase de homologao, definindo uma juno entre as relaes
Sistema_modulo(modulo, custo, sistema) e Sistema(sistema, status):

Mod_hom (modulo) = modulo ( status=Hom(Sistemas)

Sistemas_modulo)

No caso de incluso de um registro (mod2, 250, IF), se j existir o mdulo mod2

na viso Mod_hom, essa incluso no afeta a viso, mas no caso de no existir, no possvel
determinar o efeito dessa incluso utilizando apenas a viso. Na viso Modulos_Caros do
exemplo 1, era possvel determinar a manuteno em resposta s incluses utilizando apenas a
viso, mas quando se utilizam junes isso se torna impossvel.

96
A viso Mod_hom mantida se ela j tiver o mdulo mod2, mas no caso contrrio.
Assim, a manutenibilidade de uma viso depende tambm de instncias particulares dos
bancos de dados e das modificaes.

4.3.1 Informaes completas

Os casos em que os algoritmos utilizam informaes completas, so aqueles que as

relaes bases e as vises materializadas esto disponveis durante o processo de manuteno.
Esses casos se aplicam a maioria dos trabalhos de manuteno de vises, e o foco tem sido
buscar tcnicas eficientes para manter vises expressadas em diferentes linguagens (iniciando
de seleo-projeo-juno lgebra relacional, e SQL), considerando funcionalidades como
agregaes, duplicidades, recursividade, e outer-join.

No que diz respeito aos casos de utilizao de informaes completas, so aplicadas

a trs tipos de vises: vises no-recursivas, vises outer-join e vises recursivas.

Vises no-recursivas

Utiliza o algoritmo de contagem, o qual pode ser definido usando unio, negao e
agregao. A idia bsica contar o nmero de alternativas de derivaes pra cada registro de
uma viso e armazenar isso como uma informao extra na prpria viso. Dessa forma, se for
excludo um registro em uma relao base, possvel verificar se ele deve ou no ser excludo
da viso.

Por exemplo, considerando a seguinte viso:

CREATE VIEW Visao1 as
SELECT DISTINCT t1.Campo1, t2.Campo2
FROM tab_base t1, tab_base t2

97
WHERE t1.Campo2 = t1.Campo1
E os valores abaixo para a relao tab_base:
Campo1
a
b
b
a
d

Campo2
b
c
e
d
c

Figura 38: Valores da relao tab_base.

A viso Visao1 ficar dessa forma ao ser includo o nmero de derivaes para cada
linha, nomeado de Conta:
Campo1
a
a

Campo2
c
e

Conta
2
1

Figura 39: Valores da viso Visao1 com o nmero de derivaes para cada linha

Supondo a excluso do registro (a, b) da relao base, embora o registro (a, c) da

viso seja derivada de (a, b), ele tem duas alternativas de derivaes, como mostra o atributo
Conta, ou seja, o registro (a ,b) no o nico que gera o (a, c) na viso, portanto, no deve
haver a excluso do registro na viso. A expresso abaixo aplica a diferenciao para definir a
viso:

-(tab_base) = (a,b)

tab_base U tab_base

(a,b) U (a,b) (a,b) = {(a,c), (a,e)}

O algoritmo Contagem computa -(tab_base) ( + para inseres). Cada registro em

associado com um valor de contagem (negativo para excluses). Nesse exemplo, ficaria

98
(a, c, -1), (a, e, -1). Combinando isso com a viso materializada Visao1 atual, o resultado seria
a seguinte viso:
Campo1
a

Campo2
c

Conta
1

Figura 40: Valores da viso materializada Visao1 aps a excluso do registro (a, b) da
relao base.
O algoritmo de contagem executa esse processo para cada viso materializada
presente no sistema.

Vises outer-join

Para definir uma viso outer-join utilizada a seguinte sintaxe:

CREATE VIEW Visao1 AS
SELECT x1, x2, ..., xn
FROM tab1 FULL OUTER JOIN tab2 ON g(y1, y2, ...)
Onde g(y1, y2, ...) uma conjuno de predicados.

Registros podem ser inseridos ou excludos de tab1 ou tab2. Isso representado por:

+ (tab1) e

( tab1)

O outer-join pode ser reescrito como um par de outer joins pela esquerda e pela
direita:
s1 - SELECT x1, x2, ..., xn
FROM (tab1) LEFT OUTER JOIN tab2 ON g(y1, y2, ...)
s2 - SELECT x1, x2, ..., xn
FROM tab1_novo RIGHT OUTER JOIN (tab2) ON g(y1, y2, ...)
Obs.: tab1_novo a relao tab1 depois das alteraes.

Considerando tab1(A, B) e tab2(A, C), e as seguintes instncias:

99
A
10
20

B
15
25

A
10
30

C
bb
dd

Figura 41: Instncia das relaes tab1 e tab2.

O outer-join completo :

A
10
20
null

B
15
25
null

A
10
null
30

C
bb
Null
dd

Figura 42: Valores da viso com outer-join completo Visao1.

Inserindo (40, 45) em tab1, inserido um registro (40, 45, null, null) na viso. Se for
inserido um registro que j tenha um correspondente em tab2 como (30, 35), obtida a
combinao (30, 35, 30, dd). Porm, o algoritmo deve excluir o registro (null, null, 30, dd) da
viso. Assim como se o registro (30, 35) for excludo de tab1, deve ser adicionado na viso
(null, null, 30, dd).

Em resumo, s1 computa na viso Visao1 as mudanas de tab1, e s2 faz o mesmo

com as mudanas ocorridas em tab2.

Vises Recursivas

O algoritmo utilizado na manuteno dessas vises chamado de DRed Excluso

(Deletion) e Rederivao (Rederivation). Como seu nome j revela, esse algoritmo formado
por duas fases. A primeira exclui todos os registros afetados pela expresso da viso. No
exemplo do algoritmo de contagem, seriam excludos ambos os registros, (a, c) e (a, e), no

100
importando quantas alternativas de derivao cada registro tem. Nesse caso, uma
superestimao de registros derivados excludos obtida. Ento, essa superestimao
aprimorada procurando as alternativas de derivao de cada registro excludo. Dessa forma,
(a, c) ser reinserido na viso. A incluso executada usando a viso (uma vez atualizada
parcialmente) e as relaes bases.

4.3.2 Informaes parciais

Ao contrrio da manuteno de vises que utiliza informaes completas, uma viso

nem sempre exige uma manuteno quando a modificao utiliza somente informaes
parciais. Assim, o algoritmo primeiro verifica se a viso deve ser atualizada, depois, caso isso
seja possvel, efetivamente faz a manuteno.

Consultas independentes de alterao

Um algoritmo verifica se uma alterao na relao base afeta a viso. Se a viso no

afetada pela alterao, nada feito. Se ela afetada, ento os algoritmos de manuteno so
aplicados.

Vises auto-atualizveis

Uma viso chamada de auto-atualizvel, quando sua manuteno pode ser feita
utilizando apenas a viso materializada e as restries de chave. Essa uma idia importante
quando as vises materializadas so aplicadas em data warehouses, porque assim, no
necessrio varrer os dados base para atualizar as tabelas sumarizadas.

101
Pode-se dizer que uma viso auto-atualizvel com respeito modificao tipo T
em uma relao base R se a viso pode ser auto-atualizada para todas as instncias de um
banco de dados em resposta a todas as modificaes de tipo T sobre a relao R.

No segundo exemplo apresentado no incio dessa seo de manuteno de viso:

Mod_hom (modulo) = modulo ( status=Hom(Sistemas)

Sistemas_modulo)

Se for excludo um registro em Sistemas_modulo, como (mod2, 250, IF), no se

pode excluir o mdulo mod2 da viso sem verificar se esse mdulo foi implementado tambm
em outro sistema da empresa. Sendo assim, a viso Mod_hom no auto-atualizvel com
respeito a excluses em Sistemas_modulo. Assim como essa viso no auto-atualizvel com
respeito a incluses em qualquer uma das duas relaes bases.

A maioria das vises seleo-projeo-juno no auto-atualizvel com respeito a

incluses, mas muitas vezes so auto-atualizveis com respeito a excluses e alteraes. Por
exemplo:

Uma viso seleo-projeo-juno que faz a juno de duas ou mais relaes

distintas no auto-atualizvel com respeito a incluses.

Uma viso seleo-projeo-juno auto-atualizvel com respeito a excluses

em tab1 se os atributos chaves de cada ocorrncia de tab1 na juno tambm
esto includos na viso, ou so igualadas a uma constante na definio da viso.

Uma viso Visao1 com outer-join pela esquerda ou completo definida usando
duas relaes tab1 e tab2 auto-atualizvel com respeito a todos os tipos de

102
modificaes na relao tab2, desde que as chaves de tab1 e tab2 sejam distintas
e todos os atributos expostos de tab2 sejam distintos. Um atributo distinto em
uma viso Visao1, se ele aparece na clusula SELECT de definio da viso.
Um atributo A pertencente a uma relao tab1 exposto numa viso Visao1, se
A for utilizado no predicado da definio.

Com as tcnicas apresentadas neste captulo, possvel melhorar o desempenho em

tarefas que recuperam dados em um data warehouse. Seja atravs de ndices como os usados
em consultas, como na manuteno correta e otimizada de vises ou ainda com a agregao
relacional, um tempo e um custo razovel de processamento podem ser economizados,
propiciando maior eficincia na entrega de resultados ao usurio.

103

CONCLUSO
Uma modelagem de dados eficientemente construda fundamental na construo
de um data warehouse e, para permitir o acesso a informaes em grandes bases de dados.
Observou-se que, o modelo relacional apresenta um timo desempenho para qualquer tipo de
operao transacional (inseres, alteraes e excluses), que seu objetivo, mas no atende
plenamente a demanda por informaes, j que sua performance baixa para executar
consultas complexas, envolvendo perodos de tempo ou grandes quantidades de tabelas e
registros.

Com o modelo multidimensional possvel obter-se um desempenho superior, no

que se refere s consultas e anlise de grandes volumes de dados. Esse modelo permite, ainda,
que as consultas sejam realizadas de maneira mais intuitiva e flexvel pelo usurio.

Esses resultados so obtidos, em geral, pela utilizao de esquemas do tipo estrela e

floco de neve. A composio formada por uma nica tabela de fatos, onde se encontram as
medidas dos valores analisados, e circundada por quantas tabelas dimenso que trazem as
descries textuais do negcio (esquema estrela), fornece uma estrutura desnormalizada e
mais adequada a consultas a ser definida de acordo com a rea de negcio que ir atender.

A modelagem deve permitir a obteno do mais baixo nvel de detalhe possvel

sobre os dados, armazenando-se no s dados sumarizados tais quais valores mensais ou
quinzenais, mas tambm informaes de cada operao de negcio. Essa capacidade de
navegao para baixo (drill-down) ou para cima (roll-up), no detalhe das informaes, se d
pela adoo de hierarquias nos esquemas multidimensionais, que definem os nveis
navegveis que o usurio poder acessar.

104
Com essa estrutura, as consultas tendem a requerer maior tempo de processamento,
uma vez que, totais precisam ser calculados sempre que um nvel de detalhe mais alto
solicitado. Quando esse tipo de consulta se torna suficientemente freqente, a criao de
tabelas agregadas, que contm os dados pr-calculados para alguns nveis, pode ser uma
alternativa de soluo, apesar de seu custo de armazenamento.

Um problema a ser contornado no modelo dimensional o gerenciamento de

alteraes de dados nas tabelas dimenso. Muitas informaes, como o estado civil ou o
endereo de uma loja alternam-se com o tempo e o data warehouse deve estar preparado para
controlar essas alteraes da maneira mais adequada possvel. Em alguns casos, dados podem
ser simplesmente sobrescritos pelos novos, mas em geral, uma alterao como essa poderia
trazer problemas com as agregaes ou consultas baseadas no valor antigo. Nesse caso, outras
tcnicas podem ser utilizadas como a adio de uma nova linha na tabela dimenso, alterando
as novas informaes, ou ento a criao de uma nova coluna contendo o valor inicial de
determinado atributo, ou ainda o uso de artefatos de dados.

So muitas as alternativas para construo de modelos multidimensionais e, um

bom modelo parece estar condicionado ao problema especfico que tratamos. Desse modo,
a ausncia de receitas facilmente aplicveis e gerais torna a modelagem multidimensional
uma atividade complexa, mas, da qual, em muito dependem os resultados dos data
warehouses e dos sistemas de suporte a deciso.

105

GLOSSRIO
Ad-hoc

So consultas com acesso casual nico e tratamento dos dados segundo parmetros
nunca antes utilizados, geralmente executado de forma iterativa e heurstica. Isso tudo
nada mais do que o prprio usurio gerar consultas de acordo com suas necessidades
de cruzar as informaes de uma forma no vista e com mtodos que o levem a
descoberta daquilo que procura.

Agregaes

Linhas fsicas em um banco de dados, na maioria das vezes criadas pela soma de outros
registros nos bancos de dados visando melhorar o desempenho de consulta.

Anlise

Decomposio de campos operacionais, com o nome ou o endereo em partes

elementares padro.

rea de
Apresentao de
Dados

Local em que o data warehouse est organizado, armazenado e disponvel para consulta
direta dos usurios, ferramenta de acesso de dados e outras aplicaes analticas.

Atributo

Coluna (campo) em uma tabela de dimenso

Banco de dados
multidimensional

Banco de dados em que os dados so apresentados em cubos de dados, em oposio a

tabelas em uma plataforma de banco de dados relacional.

Byte

Unidade de medida formada por 8 bits de dados.

Chave composta

Em um banco de dados, uma chave formada por vrias colunas.

Chave estrangeira
(FK)

Coluna em uma tabela de banco de dados relacional cujos valores so extrados de

valores de uma chave primria localizada em uma outra tabela.

Chave primria
(PK)

Coluna em uma tabela de banco de dados que exclusivamente diferente de cada linha
na tabela.

Classificar

Ordenar os dados de acordo com critrios projetados

Clusula FROM
(SQL)

Clusula SQL que lista as tabelas necessrias para a consulta

Clusula GROUP
BY (SQL)

Clusula SQL que lista exclusivamente os itens no agregados na lista SELECT, ou

seja, tudo o que no seja SUM, COUNT, MIN, MAX, AVG.

Clusula ORDER
BY (SQL)

Clusula SQL que determina a ordem das linhas do conjunto de respostas.

Coluna

Estrutura de dados que contm um item de dados especficos dentro de uma linha
(registro). Equivalente a um campo do banco de dados.

Consulta (Query)

Solicitao feita pelo usurio de informaes armazenadas em um data warehouse

Cubo

Nome de uma estrutura dimensional em uma plataforma de banco de dados de

processamento analtico on-line (OLAP) ou multidimensional, originalmente referindose ao caso simples de trs dimenses: produto, mercado e hora.

Dados atmicos

Os dados mais granulares detalhados capturados por um processo corporativo. Devem

ser disponibilizados na rea de apresentao dos dados para responder a consultas
especficas e imprevisveis.

106
Data Staging Area

rea de armazenamento e conjunto de processos que limpam, transforma, combinam,

retiram duplicidades, armazenam e preparam dados de origem para serem usados no
data warehouse

Data warehouse

Aglomerao das reas de staging e de apresentao do data warehouse de uma

empresa, em que dados operacionais esto estruturados especificamente para consulta e
desempenho de anlise e facilidade de utilizao.

Desnormalizao

Aceitao de redundncia em uma tabela para que ela permanea simples e no

normalizada. Esse procedimento tem por objetivo melhorar o desempenho e facilitar
ainda mais a utilizao.

Dimenso

Entidade independente em um modelo dimensional que serve como ponto de entrada ou

como mecanismo para aplicar o recurso de separao e combinao (slicing and
dicing) das medidas aditivas localizadas na tabela de fatos do modelo dimensional.

Drill across
(interligao)

Ato de solicitar dados com a mesma identificao de duas ou mais tabelas de fatos em
um nico relatrio, quase sempre envolvendo consultas separadas que so intercaladas
com uma segunda passagem atravs da correspondncia de cabealhos de linhas.

Drill down (descer

na hierarquia)

Ato de adicionar um cabealho de coluna ou substituir um cabealho de linha em um

relatrio para dividir as linhas pelo conjunto de respostas mais minuciosamente.

DSS

Veja Sistemas de suporte tomada de decises

Escalabilidade

Capacidade de acomodar exigncias de crescimento futuras

Esparsa

Tabela de fatos que possui um nmero relativamente pequeno de todas as combinaes

possveis de valores chaves.

Extrao,
Transformao e
Carga (ETL)

Conjunto de processos atravs dos quais os dados operacionais de origem so

preparados para o data warehouse

Ferramenta de
acesso a dados

Uma ferramenta cliente que consulta, obtm ou manipula dados armazenados em um

banco de dados relacional, de preferncia um modelo dimensional localizado na rea de
apresentao de dados

Ferramenta de ETL

Aplicao de software normalmente residente no cliente e no servidor que ajuda nos

processos de extrao/transformao da carga de dados da produo.

Granularidade

Nvel de detalhe capturado no data warehouse

ndice

Estrutura de dados associada a uma tabela que esta ordenada logicamente pelos valores
de uma chave e usada para melhorar o desempenho do banco de dados e a velocidade
de acesso consulta.

Metadados

Qualquer dado mantido para sustentar as operaes ou a utilizao de um data

warehouse; funciona como uma enciclopdia para o data warehouse

Modelagem
dimensional

Metodologia que permite modelar logicamente dados para melhorar o desempenho de

consultas e prover facilidade de utilizao a partir do conjunto de eventos bsicos de
medio.

MOLAP (OLAP
Multidimensional)

Implementaes de processamento analtico on-line dedicadas que no dependem de

bancos de dados relacionais.

Normalizao

Tcnica de modelagem lgica que remove redundncia de dados separando os dados em

muitas entidades distintas, cada uma das quais se torna uma tabela e um SGBD
relacional.

107
OLAP
(Processamento
analtico on-line)

um conjunto de princpios vagamente definidos que fornecem uma estrutura

dimensional de suporte tomada de decises.

OLTP
(Processamento de
transaes on-line)

Descrio original de todas as atividades e sistemas associados entrada segura de

dados em um banco de dados.

Processamento
analtico

Utilizao de dados para fins de anlise visando suportar a tomada de decises na

empresa.

SGBD(Sistema
Gerenciador de
Banco de Dados)

uma aplicao de computador para armazenar, recuperar e modificar dados de uma

forma altamente estruturada

Sistema de origem

Sistema operacional de registro cuja funo capturar as transaes ou outras medidas

de desempenho de processos de uma empresa.

Sistema de suporte
tomada de
decises (DSS,
Decision Support
System)

Nome original do processo de data warehouse.

Sistema operacional
de registro

Sistema operacional para captura de dados sobre as operaes e processos de negcio

de uma empresa.

Slice and Dice

Capacidade de acessar igualmente um data warehouse atravs de qualquer uma de suas

dimenses. o processo de separao e combinao de dados do warehouse em
combinaes aparentemente infinitas.

Snowflake (Floco de
neve)

Dimenso normalizada em que uma dimenso de tabela simples decomposta em uma

estrutura de rvore com, potencialmente, muitos nveis de alinhamento

SQL (Structured
Query Language)

Linguagem padro para acesso a bancos de dados relacionais

Tabela

Coleo de linhas (registros) que possuem colunas associadas (campos).

Tabela de dimenso

Tabela em um modelo dimensional com uma chave primria composta por uma nica
parte e colunas de atributos descritivos.

Tabela de fatos sem

fatos

Tabela de fatos que no possui fatos, mas captura determinados relacionamentos de

muitos para muitos entre as chaves de dimenso. mais normalmente usada para
representar eventos ou fornecer informaes que no aparecem nas outras tabelas de
fatos.

Viso (SQL)

Instruo SQL que cria cpias lgicas de uma maneira que uma consulta completa
possa ser usada separadamente em uma instruo SELECT.

108

REFERNCIAS BIBLIOGRFICAS

COLOSSI, N.; MALLOY, W.; REINWALD B. Relational Extensions for OLAP. IBM
Systems Journal, vol 41, n 4, 2002.
FERNANDES, Lcia. Oracle 9i Para Desenvolvedores Curso Completo. Rio de Janeiro.
Axcel Books do Brasil, 2002. 1614 p.
GRAY, Jim; BOSWORTH, Adam; LAYMAN, Andrew; PIRAHESH, Hamid. Data Cube: A
Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and
Sub-Totals. Technical Report MSR-TR-95-22. Redmond, WA.
GUPTA, Ashish, MUMICK, Inderpal Singh. Maintenance of Materialized Views:
Problems, Techniques, and Applications. San Jose, 1995.
INMON, W.H. Como construir o Data Warehouse. Rio de Janeiro: Editora Campus, 1997.
388p.
INMON, W.H, WELCH, J. D., GLASSEY, K. L. Gerenciando Data Warehouse. So Paulo:
Makron Books, 1999. 375p.
KIMBALL, Ralph. Data Warehouse Toolkit. So Paulo: Makron Books, 1996-b. 388 p.
KIMBALL, Ralph, REEVES, Laura, ROSS, Margy, THORNTHWAITE, Warren. TheIData
Warehouse Lifecycle Toolkit Expert Methods for Designing, Developing
andIDeploying Data Warehouses. New York: John Wiley & Sons, Inc., 1998. 771 p.
KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit (Segunda Edio). Rio de
Janeiro: Editora Campus, 2002. 494 p.
MACHADO, F. N. R.; ABREU, M. P. Projeto de Banco de Dados: uma viso prtica. So
Paulo: rica, 1996.
MEYER, Don, CANNON, Casey. Building a Better Data Warehouse. New Jersey:
Prentice-Hall PTR, 1998. 227 p.
POE, Vidette, KLAUER, Patricia, BROBST, Stephen. Building a Data Warehouse for
Decision Support. New Jersey. Prentice-Hall, Inc, 1998. 285 p.
SOARES, Vnia Jesus de Araujo. Modelagem Incremental no Ambiente de Data
Warehouse (tese de mestrado). Rio de Janeiro, 1998.
VAISMAN, Alejandro A. Olap, Data Warehousing, and Materialized Views: a Survey.
Buenos Aires, 1998.

109

BIBLIOGRAFIA COMPLEMENTAR
COUGO, Paulo. Modelagem Conceitual e Projeto de Banco de Dados. Rio de Janeiro:
Campos, 1997.
FIGUEIREDO, Adriana Maria C.M. MOLAP x ROLAP: Embate de Tecnologias para
Data warehouse. Developers Magazine. Rio de Janeiro: Axcel Books do Brasil Editora
Ltda. Fevereiro de 1998, n 18 p.24.
PEDERSEN, T. B., JENSEN, C. S. Multimensional Database Technology. Revista
Computer, 2001.
PENDSE, N. What Is OLAP? The OLAP Report, see http://www.olapreport.com/fasmi.htm.
THOMSEN, E. OLAP Solutions. John Wiley&Sons, Inc., Hoboken, NJ (1997).

110

APNDICE A - OLAP (Processamento Analtico On-line)

A anlise multidimensional para OLAP surgiu aps a publicao de A Programming
Language (Ken Iverson,1962). Com base nessas idias a IBM desenvolveu e implementou a
primeira linguagem com anlise multidimensional, no final da dcada de 60, chamada de
APL. A evoluo desta linguagem culminou na criao das ferramentas OLAP na dcada 90.

A aplicao OLAP soluciona o problema de sntese, anlise e consolidao de

dados, pois o processamento analtico online dos dados. Tem capacidade de visualizao das
informaes a partir de muitas perspectivas diferentes, enquanto mantm uma estrutura de
dados adequada e eficiente. A visualizao realizada em dados agregados, e no em dados
operacionais porque a aplicao OLAP tem por finalidade apoiar os usurios finais a tomar
decises estratgicas.

medida que os usurios do data warehouse ampliam seu conhecimento das

capacidades do processamento DSS (Decision Support System) e que cresce o volume de
dados exponencialmente, a necessidade de tcnicas mais sofisticadas para facilitar o uso do
ambiente do data warehouse tambm aumenta.

Para suprir esta demanda por um ambiente OLAP completo e eficiente, um conjunto
de regras baseadas na arquitetura foram definidas por E.F.Codd, servindo de guia para
fornecedores de ferramentas de anlise e outros produtos.

111

Viso conceitual
multidimensional

Todos os atributos necessrios para dar suporte ao processamento DSS devem

ser moldados e os dados capturados para que seja possvel haver qualquer viso
conceitual de dimenses.

Transparncia

O acesso a qualquer nvel de data warehouse dever ser transparente ao usurio.

Acessibilidade

O data warehouse deve permitir acessibilidade aos dados possibilitando

transform-los em informao

Performance de relatrio
consistente

O tempo de resposta na gerao dos relatrios deve ser constante , independente

de ambiente ou outras circunstncias.

Arquitetura ClienteServidor

O data warehouse uma arquitetura e no uma tecnologia, portanto

independente de plataforma.

Dimensionalidade genrica

Qualquer atributo que seja necessrio a um usurio-alvo deve estar disponvel

aquele usurio como uma dimenso. Assim, todas as dimenses e os atributos
ou grupos de atributos que elas representam so genricos.

Operao dimensional
cruzada irrestrita

Os nveis departamentais podem ser construdos para dar suporte a qualquer

operao dimensional cruzada. (drill-across)

Manipulao de dados
intuitiva

O uso de metadados muito importante pois eles fornecem definies em um

contexto de negcio para os usurios, fazendo com que todos eles tenham a
mesma compreenso dos dados.

Flexibilidade quanto a
relatrios

O data warehouse deve permitir ao usurio a maior flexibilidade possvel na

construo de relatrios.

Dimenso e nveis de
agregao ilimitados

Depende de como o nvel atmico do data warehouse projetado.

Pesquisa de detalhes (Nvel

de Linha)

O data warehouse arquitetado ir suportar capacidades de pesquisas (drilldown) tanto no nvel departamental quanto individual.

Atualizao incremental de
banco de dados

Atualmente os sistemas de gerenciamento de bancos de dados

multidimensionais no suportam atualizao incremental de dados, por isso o
banco de dados inteiro deve ser recarregado com os dados novos.

Arrays mltiplos

Um data warehouse pode e deve suportar um nmero adequado e os tipos de

matrizes a fim de satisfazer as necessidades de informao dos diferentes
usurios alvo.

Seleo de subconjuntos

a seleo de subconjuntos a partir do nvel atmico do data warehouse, usado

para popular os nveis departamentais e individuais.

Suporte a dados locais

A arquitetura do data warehouse suporta a localizao fsica dos dados to

perto do usurio final quanto apropriado. A implementao descentralizada da
arquitetura do data warehouse, especialmente nos nveis departamental e
individual, um de seus recursos mais poderosos.

Quadro 1: Regras OLAP

Fonte: Inmon W. H. (1999)

112

1 Origem dos dados do OLAP

A origem dos dados do OLAP o nvel de dados estruturado organizacional de um
DW que j foi previamente carregado por outros processos aleatrios advindos de outros
sistemas da empresa.

Informao

Estruturado
individual

Menos

Histrico

Normalizado

Detalhado

Estruturado
departamental

Dados

Mais

Estruturado
organizacional

Figura 1: A arquitetura de Data Warehouse.

O OLAP possui um tamanho reduzido em comparao ao nvel de dados estruturado

organizacional (cerca de trs vezes menor). Isso se d devido ao fato do OLAP atender
determinadas reas de negcio, adequando seu contedo apenas s necessidades dos usurios
que iro utiliz-lo, e/ou armazenando um perodo histrico menor dos dados. Ou seja, os
dados so interpretados e agregados para atender determinadas reas de negcios
(departamentos) da empresa, segmentando e preparando os dados de maneira particular para
cada necessidade, como mostra a figura 1. Tal medida de extrema importncia para garantir
um tempo de resposta mais rpido nas consultas.

113
Podemos dizer ento que, como o OLAP envolve um volume de dados reduzido em
relao ao nvel de dados estruturado organizacional, ele mais flexvel.

2 OLAP e a carga de trabalho

Uma das vantagens mais interessantes do OLAP a redistribuio da carga de
trabalho (processamento) gerados pelo acesso a dados realizado no ambiente estruturado
organizacional para uma combinao de aquisio de dados do ambiente estruturado
organizacional para o ambiente OLAP, e o acesso a dados realizado em ambos. A figura 2
mostra as diferenas antes e depois do ambiente OLAP ter sido criado [INMON, 1999].
consulta

consulta

consulta

consulta

consulta

consulta

consulta

consulta

consulta

consulta

consulta

consulta
consulta

consulta

consulta

consulta

consulta

consulta

consulta

VS

Consultas
mais
simples e
diretas
usadas com
OLAP

consulta

Consultas muito complexas

requeridas mesmo pelas mais
simples solicitaes de
informao.
consulta

consulta

Figura 2: OLAP desvia profundamente a carga de trabalho

consulta

114
Quando no h ambiente OLAP, todas as consultas so executadas no ambiente
estruturado organizacional. Executar todas as consultas no ambiente estruturado
organizacional pode no ser o problema contanto que no haja muitos dados e que no haja
muito processamento ocorrendo nele.

No instante em que houver muitos dados no ambiente estruturado organizacional ou

processamento demais no ambiente, uma opo para facilitar o acesso a esses dados a
criao de um ambiente OLAP.

O uso deste ambiente provoca um desvio de processamento de consultas do nvel

estruturado organizacional do data warehouse para o prprio OLAP, proporcionando:

Economia de processamento;

Alta flexibilidade;

Personalizao de dados necessrios por determinada rea de negcio;

Tirar vantagem de diferentes softwares para satisfazer diferentes necessidades,

residindo em uma plataforma OLAP;

Permitir que partes significativas de dados sejam isoladas;

Permitir que subconjuntos de dados sejam isolados.

115

3 Necessidades do ambiente OLAP

Alguns dos fatores que aceleram a necessidade de uma ambiente OLAP para
fornecer um acesso a dados mais eficiente na transformao de dados em informaes
incluem:

Pr-agregao de dados para obter uma performance melhor.

Pr-categorizao de dados para uma melhor compreenso e usabilidade por

parte dos usurios finais.

Padronizao de clculos, mtricas e outros dados derivados para assegurar a

preciso por toda a organizao.

Um nico ponto de acesso (dados estrutural organizacional) versus muitos

(dados OLAP).

Apesar das vantagens oferecidas pelo ambiente OLAP, nem sempre possvel
atender s necessidades dos usurios somente com este nvel de detalhe. Algumas vezes,
consultas requerem um nvel de detalhe ou tipos de dados necessrios tais, que somente no
ambiente estruturado organizacional possvel obter os resultados esperados.

4 Metadados no OLAP
Devido s freqentes alteraes nas regras de negcio que servem de base para a
aquisio dos dados no ambiente OLAP, torna-se imprescindvel a utilizao de metadados,

116
uma vez que, sem eles, seria impossvel reconhecer e compreender as alteraes feitas aos
dados ao longo de diferentes perodos de tempo.

Os componentes dos metadados OLAP so muito similares aos encontrados no nvel

estruturado organizacional, dentre eles esto:

Informao descritiva sobre o que est no ambiente OLAP (contedo, estrutura,

definio etc.);

A origem dos dados (dados estruturados organizacionais ou dados externos);

O nome comercial e tcnico dos dados;

Uma descrio do resumo, subconjunto, superconjunto e/ou os processos de

desnormalizao que descrevem a jornada dos dados do nvel estruturado
organizacional ao ambiente OLAP;

Mtricas que descrevem quantos dados e de que tipos encontram-se em um

ambiente OLAP;

Informao da programao de atualizao, descrevendo quando os dados OLAP

foram inseridos;

Informao sobre modelagem, descrevendo como os dados no ambiente OLAP

se relacionam ao modelo de dados corporativo e ao modelo de dados de OLAP.

H a necessidade de metadados tanto globais quanto locais no ambiente OLAP. Os

metadados locais so utilizados para uma determinada rea de negcio que cada ambiente

117
OLAP atende, j os metadados globais servem para reter informaes que so aplicadas a
diversos ambientes OLAP, mantendo assim uma integrao entre eles.

5 Arquiteturas OLAP
A arquitetura em que a aplicao OLAP trabalha deve ser elaborada de acordo com
o mtodo de armazenamento de dados. Os principais mtodos de armazenamentos so
MOLAP e ROLAP. Cada um deles deve ser utilizado quando suas particularidades melhor
atenderem s necessidades da rea de negcio que far uso do OLAP.

5.1 MOLAP (Multidimensional OLAP)

MOLAP (Multidimensional On Line Analytical Processing) uma classe de

sistemas que permite a execuo de anlises bastante sofisticadas usando como gerenciador
de banco de dados, um banco multidimensional [FIGUEIREDO, 1998].

A tecnologia MOLAP no somente uma ferramenta de visualizao, e sim, uma

tecnologia complexa de armazenamento e visualizao de dados onde devemos nos preocupar
com todo o processo de engenharia de banco de dados, tamanho, estruturao, processo de
carga, indexao, otimizao, etc.

No MOLAP os dados so armazenados em matrizes proprietrias concebidas

especificamente para anlises dimensionais e indexados de maneira a prover um timo
desempenho no acesso a qualquer elemento. Os ndices so necessrios apenas para o
gerenciamento de dados esparsos e cabem na memria principal.

118
Usando indexao, antecipao da maneira como os dados so acessados e alto grau
de agregao dos dados no processamento das agregaes, o MOLAP capaz de apresentar
uma melhor performance em relao ao ROLAP no tempo de resposta ao usurio, uma vez
que no processo de carga dos dados ele pode pr-calcular diversas informaes.

Servidores MOLAP aplicam estratgias de compresso para manipular cubos

esparsos (cubos em que a maioria das clulas no tem valor), fazendo um uso eficiente do
caching. Por outro lado, ele consome muito espao. Como conseqncia, o MOLAP
geralmente usado em Data Marts (pequenos DW envolvendo somente um nico setor de uma
organizao).

5.2 ROLAP (Relacional OLAP)

Sistemas ROLAP fornecem anlise multidimensional de dados armazenados em

uma base de dados relacional. Atualmente existem duas maneiras de se fazer este trabalho:

fazer todo o processamento dos dados no servidor da base de dados, neste caso
o servidor OLAP gera os comandos SQL em mltiplos passos e as tabelas
temporrias necessrias para o devido processamento das consultas;

executar comandos SQL para recuperar os dados, mas

fazer todo

processamento (incluindo junes e agregaes) no servidor OLAP.

No ROLAP a sumarizao executada por uma ferramenta externa, os dados so

mapeados nos registros nas tabelas do modelo estrela, agregaes so pr-calculadas nas
tabelas sumrio e metadados so armazenados em tabelas relacionais (ndices).

119
No final dos anos 80 e aproximadamente incio dos anos 90, um grande nmero de
produtos foi desenvolvido para explorar este mtodo de organizao de dados
multidimensionais. Em 1986, Ralph Kimball, foi um dos fundadores da Red Brick Systems
para desenvolver um sistema de bancos de relacional desenhado especificamente para tratar
consultas em um modelo estrela. Entretanto, a linguagem SQL como implementada no incio
dos anos 90 implicou em srios problemas de performance na implementao de cubos
OLAP. Alguns destes problemas foram:

GROUP BY: No podem ser usados para retornar os resultados de clulas com
diferentes nveis de agregao. Isto significa que muitas consultas diferentes
foram necessrias para obter todos os valores solicitados.

Consultas altamente agregadas podem referenciar virtualmente todas as linhas da

tabela fato de maneira que poucos valores das clulas so retornados.

Geralmente no existia memria para armazenar os resultados de grandes

clculos, ou seja, para cada consulta era necessrio reiniciar o processamento.
Como agregaes para vrios nveis eram calculados, as linhas da tabela de fatos
eram lidas repetidamente.

SQL suportava apenas algumas funes de agregao (SUM, COUNT, AVG,

MIN e MAX), entretanto alguns sistemas de bancos de dados relacionais tinham
extenses com capacidades analticas adicionais.

Os catlogos de bancos de dados no continham informaes sobre os meta

dados dos modelos estrela. Como resultado, modelos estrela tinham que ser
descritos diversas vezes uma vez para cada aplicao ou ferramenta usada.

120

Como os metadados no faziam parte dos catlogos de bancos de dados,

informaes estruturais de chaves ficavam indisponveis para os compiladores de
consulta.

Em geral, a soluo encontrada para resolver os problemas de performance nos

sistemas ROLAP foi manter um nmero como sumrio da tabela fato e tabelas dimenso
associadas. Em tal sistema, sempre que dados na tabela fato so modificados, a tabela sumrio
precisa ser ajustada. Apesar desses problemas, sistemas ROLAP foram largamente
implementados. Em tempo de consultas, se a tabela sumrio no estiver disponvel com a
agregao desejada, o sistema OLAP deve escolher uma tabela sumrio apropriada contendo
parcialmente resultados agregados ou ento consultar a base da tabela fato [COLOSSI, 2002].

Uma vantagem na adoo de uma soluo ROLAP reside na utilizao de uma

tecnologia estabelecida, de arquitetura aberta e padronizada como a relacional,
beneficiando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware
[FIGUEIREDO, 1998].