Professional Documents
Culture Documents
A MODELAGEM DE DADOS
NO AMBIENTE DATA WAREHOUSE
So Paulo
2004
So Paulo
2004
SUMRIO
INTRODUO
................................................................................................
.............................................................
12
.......................................................................................................
12
09
.......................................................
15
.......................................................................................................
16
............................................................................
17
...........................................................................................
18
...........................................................................................
19
.....................................................................................
20
..................................................................................
22
............................................................................
2 - A MODELAGEM DIMENSIONAL
.............................................................
28
......................................................................
28
...........................................................................................
32
........................................................................................
34
24
...................................................................
37
...............................................................................
38
..................................................................................
38
............................................................................
40
..................................................................................
42
...................................................................
44
...............................................................................
45
................................................................................................................
48
51
3.1 Granularidade
51
.................................................................................................
...................................................................
52
.....................................................................................
53
..................................................................................
56
.......................................................
57
..................................................................................
57
......................................
58
....................................................
60
.....................................................................................
60
............................................................................
61
...............................................................................
64
..........................
66
...............................................................................
67
..................................................................................
70
..................................................................................
72
.......
76
76
77
..............................................................................................
.....................................................................................
79
81
....................................................
82
.....................................................................................
83
......................................................................
84
...........................................................................................
87
92
...............................................................................
96
100
CONCLUSO
.......................................................................................................
103
GLOSSRIO
.......................................................................................................
105
REFERNCIAS BIBLIOGRFICAS
................................................................
108
BIBLIOGRAFIA COMPLEMENTAR
................................................................
109
................................
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
Figura 2
Figura 3
Figura 4
Figura 5
Figura 6
Figura 7
Figura 8
Figura 9
Figura 10
Figura 11
Figura 12
Figura 13
Figura 14
Figura 15
Figura 16
Figura 17
Figura 18
Figura 19
Figura 20
Figura 21
...58
Figura 22
Figura 23
Figura 24
Figura 25
Figura 26
Figura 27
Figura 28
Figura 29
Figura 30
Figura 31
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
Figura 35
Figura 36
Figura 37
Figura 38
Figura 39
Valores da viso Visao1 com o nmero de derivaes para cada linha ..97
Figura 40
Figura 41
Figura 42
RESUMO
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.
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.
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
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.
14
montadas vrias combinaes entre elas, resultando na extrao de vrias vises sobre o
mesmo tema.
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.
16
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.
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.
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:
18
completamente desnormalizados dentro de arquivos texto, nesse caso possvel
que seja necessrio normalizar partes dos registros.
19
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).
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.
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.
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.
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.
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.
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 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.
24
Processamento Transacional:
Processamento Analtico:
Dados normalizados
Dados consistentes
Controle de concorrncia
Dados correntes
Respostas imediatas
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.
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
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
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.
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.
28
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.
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.
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.
31
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.
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.
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.
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.
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.
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.
37
2.2.2 Modelagem da Tabela de Fatos
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:
38
O que usamos para medir este processo? - Usamos o valor das vendas e
quantidade vendida
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.
39
dimenses so os aspectos pelos quais se pretende observar as mtricas relativas ao processo
que est sendo modelado.
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.
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
41
seqncia, N:1. A figura 7 representa a hierarquia explcita para a dimenso
Produto. Essa hierarquia constituda pelas dimenses Tipo e Categoria.
42
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.
43
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].
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.
46
representa a implementao do modelo floco de neve no modelo do sistema de vendas da loja
de departamentos apresentado no tpico 2.1.
47
esquema inevitavelmente interfere na possibilidade de explorao dessa tcnica de ajuste de
desempenho.
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.
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.
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.
51
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.
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.
53
3.1.2 Tabelas Agregadas
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.
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.
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.
Agregao completa: consiste em recriar a tabela agregada toda vez que houver
uma carga na tabela de fatos;
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.
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.
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].
57
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.
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
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.
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.
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.
bairro
241
Jos
Aguiar
854
Jos
Aguiar
Rua XV de novembro, 14
Centro
60
3.3.3 Adicionar uma nova coluna de dimenso
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.
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.
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.
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.
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
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.
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.
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.
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.
67
cardinalidade M:N necessria uma anlise mais minuciosa, cruzando o modelo gerado com
as regras do negcio [SOARES, 1998].
68
No se pode inserir um registro com essas trs dimenses e preencher as medidas com zeros.
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.
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.
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.
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:
72
quando existe uma hierarquia que pode ser usada para diferentes modos de
agregao e classificao dos dados para diferentes propsitos [INMON, 1999].
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.
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.
76
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.
77
dados. O uso correto de ndices uma estratgia de otimizao no processamento das
consultas.
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.
78
alternativa melhor que essa: em vez de uma lista com as posies, pode-se utilizar um vetor
de bits [VAISMAN, 1998].
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.
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].
80
sum(Vendas)
( Vendas
( estado=SP ( Cliente ) ) )
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
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.
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.
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.
depto
121
121
010
005
salario
3.000,00
5.000,00
1.500,00
8.000,00
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.
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.
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
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
86
UNION
SELECT
FROM
WHERE
GROUP BY
UNION
SELECT
FROM
WHERE
GROUP BY
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.
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
87
UNION
SELECT
FROM
WHERE
GROUP BY
GM
Preto
Branco
Total (ALL)
1994 1995
50
40
90
85
115
200
Total
(ALL)
135
155
290
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
2002
2003
2004
Por fabricante
Ford
GM
Vermelho
Por ano
Branco
Azul
Sum
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.
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
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:
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
93
usados para computar uma alterao em uma viso, como quais relaes base
tm que ser acessadas, as restries de integridade, chaves, etc.
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:
E a seguinte viso que contm todos os mdulos que custaram mais do que R$ 1000:
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 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.
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.
Sistemas_modulo)
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.
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.
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
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
-(tab_base) = (a,b)
tab_base U tab_base
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
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.
99
A
10
20
B
15
25
A
10
30
C
bb
dd
O outer-join completo :
A
10
20
null
B
15
25
null
A
10
null
30
C
bb
Null
dd
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).
Vises Recursivas
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.
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.
Sistemas_modulo)
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.
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.
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.
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
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
Banco de dados
multidimensional
Byte
Chave composta
Chave estrangeira
(FK)
Chave primria
(PK)
Coluna em uma tabela de banco de dados que exclusivamente diferente de cada linha
na tabela.
Classificar
Clusula FROM
(SQL)
Clusula GROUP
BY (SQL)
Clusula ORDER
BY (SQL)
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)
Cubo
Dados atmicos
106
Data Staging Area
Data warehouse
Desnormalizao
Dimenso
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.
DSS
Escalabilidade
Esparsa
Extrao,
Transformao e
Carga (ETL)
Ferramenta de
acesso a dados
Ferramenta de ETL
Granularidade
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
Modelagem
dimensional
MOLAP (OLAP
Multidimensional)
Normalizao
107
OLAP
(Processamento
analtico on-line)
OLTP
(Processamento de
transaes on-line)
Processamento
analtico
SGBD(Sistema
Gerenciador de
Banco de Dados)
Sistema de origem
Sistema de suporte
tomada de
decises (DSS,
Decision Support
System)
Sistema operacional
de registro
Snowflake (Floco de
neve)
SQL (Structured
Query Language)
Tabela
Tabela de dimenso
Tabela em um modelo dimensional com uma chave primria composta por uma nica
parte e colunas de atributos descritivos.
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
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
Transparncia
Acessibilidade
Performance de relatrio
consistente
Arquitetura ClienteServidor
Dimensionalidade genrica
Operao dimensional
cruzada irrestrita
Manipulao de dados
intuitiva
Flexibilidade quanto a
relatrios
Dimenso e nveis de
agregao ilimitados
O data warehouse arquitetado ir suportar capacidades de pesquisas (drilldown) tanto no nvel departamental quanto individual.
Atualizao incremental de
banco de dados
Arrays mltiplos
Seleo de subconjuntos
112
Informao
Estruturado
individual
Menos
Histrico
Normalizado
Detalhado
Estruturado
departamental
Dados
Mais
Estruturado
organizacional
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.
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
consulta
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.
Economia de processamento;
Alta flexibilidade;
115
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.
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.
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.
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;
fazer todo
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.
120