You are on page 1of 12

EXPERINCIAS E RESULTADOS DO USO DE AGREGADOS EM DATA WAREHOUSES

Celso Kopp Webber1,2 MSc


webber@sj.univali.rct-sc.br

Cristiane Koehler1,3, MSc


koehler@inf.ufsc.br

Fabiane Barreto Vavassori1,2, MSc


fabiane@inf.ufsc.br

Fernanda dos Santos Cunha1,2, MEng


fernanda@sj.univali.rct-sc.br

Universidade Federal de Santa Catarina UFSC1 Programa de Ps-Graduao em Engenharia de Produo/PPGEP Campus Universitrio Trindade Cx. Postal 476 88.040900 Florianpolis SC Universidade do Vale do Itaja UNIVALI2 Universidade do Sul de Santa Catarina UNISUL3

ABSTRACT:
This works presents a practical demonstration of the use of aggregates in data warehouses. In order to accomplish that, a library loans database was used as a reference to build the data warehouse. Some strategical searches were run in the original database and data warehouse. The results were evaluated considering two effects: the sparsity failure and the aggregates explosion. KEYWORDS: data warehouse, aggregates, sparsity failure.

RESUMO:
Este trabalho apresenta uma demonstrao prtica da utilizao dos agregados em data warehouses. Para tanto, utilizou-se uma base de dados referente a emprstimos em uma biblioteca e criou-se um data warehouse relativo. Algumas consultas estratgicas foram realizadas sobre a base de dados original e o data warehouse. Os resultados foram avaliados considerando dois efeitos: a disperso e a exploso de agregados.

1. INTRODUO
Segundo [KHA99], no contexto de data warehouse (DW) novos tipos de consultas surgiram. Enquanto se trabalha com aplicao operacional, as consultas esto limitadas a poucas linhas por vez. No entanto, quando se trabalha sobre um data warehouse, fala-se em informao intensiva (data-intensive). Desta forma, pode-se dividir as consultas de apoio tomada de deciso em dois tipos:
S consultas data-intensive que acessam um grande nmero de linhas; S consultas data-selective que atingem somente poucas linhas.

Assim, interessante notar como pessoas em posies diferentes no processo de tomada de deciso utilizam estes tipos de consultas (apresentadas na tabela que segue) :
Posio Organizacional Executivos Gerentes nvel mdio Gerentes Operacionais Foco da Deciso Estratgica Estratgica/Ttica Ttica Tipo de Consulta Data intensive Data intensive/Selective Data selective

Tabela 1 Tipos de consultas utilizadas no processo decisrio.

Para a tomada de deciso estratgica faz-se necessrio consultas data-intensive, pois os executivos, por exemplo, querem pressionar um boto e ver informaes obtidas atravs de consultas ad-hoc expressas graficamente. Esta resposta, geralmente, necessita acionar um baixo nvel de detalhe e deve ser gerada rapidamente. Um exemplo de consulta para a deciso estratgica (data intensive) solicitada por um executivo seria: Quantos drives ns remetemos para a Regio Sul, no ltimo trimestre, no qual a quantidade enviada foi maior que dez, e qual o lucro que obtivemos a partir destas vendas em relao s vendas com quantidade inferior a dez ? Uma resposta a esta consulta necessitaria pesquisar todos os pedidos do ltimo trimestre, resultando em vrias linhas de resposta. Em um outro extremo encontram-se os gerentes operacionais, que utilizam consultas de seleo pois esto interessados num escopo mais estreito. Por exemplo, uma simples consulta: Mostrar o pedido nmero 20101995, assim pode-se verificar que este o item a ser alterado, pois o gerente operacional conhece a chave primria (nmero do pedido) da linha de interesse. Esta pesquisa resulta apenas em uma linha de resposta.

Para atender as necessidades dos executivos gerar consultas data-intensive em tempo reduzido tem-se duas estratgicas bsicas:
S particionamento: o qual reduz a quantidade de informaes que o sistema precisa acessar; S agregao: que pr-calcula as dimenses necessrias para que o sistema possa acess-las em

poucas linhas. Normalmente, estas estratgias so mutuamente exclusivas. Portanto, a seguir ser detalhada a estratgia de agregao, por ser o enfoque estudado no presente artigo.

2. AGREGADOS
Um agregado um registro da tabela de fatos que representa o resumo dos registros de nvel bsico desta tabela, pois reduz o detalhamento das dimenses no importantes numa anlise (resumindo estes dados), detalhando apenas as dimenses necessrias a uma determinada restrio. A utilizao de agregados faz com que as consultas sejam mais rpidas. Porm, o grande aumento do espao necessrio para seu armazenamento e o efeito "disperso" causador de um excesso de registros de agregados so dois pontos negativos desta utilizao. Segundo [KIM96], "num ambiente de data warehouse que seja projetado apropriadamente, mltiplos conjuntos de agregados so construdos, representando nveis de agrupamento comuns entre as dimenses chave de um DW". Nessa afirmao, o autor assume que exista uma estrutura dimensional padro (normalmente chamada esquema estrela figura 1), na qual uma grande tabela de fatos central rodeada por tabelas de dimenso independentes. Estas dimenses, segundo [INM97], representam uma forma de se acessar e tratar os dados da tabela de fatos, alm de prover informaes complementares a ttulos, cabealhos e relatrios.

Figura 1 Esquema estrela.

Como a maior parte das consultas de usurios est interessada apenas em um subconjunto das dimenses disponveis, tornam-se evidentes as vantagens de usar agregados. Os dados das dimenses que no exigem detalhamento podem ser agregados, reduzindo consideravelmente o nmero de registros resultantes da consulta e o tempo do processamento, melhorando a preciso da consulta e o desempenho. Os agregados podem substituir os ndices nas tabelas de fatos, que sobrecarregam o espao de armazenamento. O Administrador de Banco de Dados pode reduzir muito a necessidade de construir estes ndices, usando bons agregados no lugar de ndices compostos.

2.1. MODOS DE UTILIZAO DE AGREGADOS


McGuff [MCG98] comenta que h dois modos de utilizar agregados: a pr-agregao, onde o resultado dos agregados previamente armazenado em disco, e a agregao dinmica, onde os clculos que geram os agregados so feitos no momento da consulta. A escolha da opo deve analisar o custo de criar e armazenar os agregados em relao ao custo de calcular dinamicamente os agregados. 2.1.1 PR-AGREGAO A pr-agregao a mais utilizada em projetos de data warehouse. Segundo [MCG98], se a tabela de fatos relativamente pequena e a computao e estrutura complexas, ento a pr-agregao uma alternativa vivel. O processo de pr-agregao inicia com a determinao de quais dimenses devem ser agregadas (se parte de uma dimenso deve ser agregada, ento toda a dimenso deve ser agregada). Uma maneira prtica de medir os benefcios de uma pr-agregao para uma determinada dimenso determinar o fator de compresso para cada nvel da dimenso. Este o nmero de linhas produzidas por uma agregao divididas pelo nmero de linhas recuperadas. Este clculo deve ser feito para todas as dimenses, usando-se dados reais, durante um longo perodo. Uma vez que se tenha estes resultados, pode-se avaliar quais dimenses devem ser pr-agregadas [MCG98], usando o seguinte critrio: dimenses com menores fatores de compresso so melhores para serem agregadas. 2.1.2 AGREGAO DINMICA Para tabelas de fatos muito grandes, porm simples em termos de estrutura e clculo, encontra-se casos em que a agregao dinmica prefervel [MCG98]. A grande vantagem da agregao

dinmica economia de espao de armazenamento. Porm, fato que os meios de armazenamento vm sendo barateados continuamente nos ltimos anos.

2.2. TCNICAS DE ARMAZENAMENTO DE AGREGADOS


Como j foi visto, um agregado um registro da tabela de fatos representando um resumo dos registros de nvel bsico. Um registro da tabela de fatos agregados est sempre associado a um ou mais registros da tabela de dimenses agregadas. Portanto, alm dos novos registros da tabela de fatos deve-se ter tambm entradas da tabela de dimenso agregadas [KIM96b]. Uma vez que se toma a deciso de pr-agregar os dados, ento deve-se optar por uma das duas tcnicas para armazenamento de registros adicionais das tabelas de fatos e de dimenso necessrios aos agregados, apresentadas nas sees que seguem. 2.2.1. CRIAO DE NOVAS TABELAS DE FATOS Esta tcnica requer a criao de uma tabela de fatos prpria para cada conjunto de dados agregados (tabelas derivadas). Cada tabela de fatos deve estar vinculada a uma ou mais tabelas de dimenso derivadas. Por exemplo, considerando duas dimenses: obra, curso e tempo, pode-se criar os seguintes registros agregados: (a) totais por ttulo na dimenso obra, (b) totais por turno na dimenso curso e (c) totais mensais na dimenso tempo. Usando esta tcnica, pode-se obter vrios tipos de registros agregados diferentes com tabelas de fatos prprias para cada tipo de registro (tabelas derivadas), como os apresentados abaixo:
Tabela 1 Unidirecional 2 Bidirecional 3 Tridirecional Tipo emprstimo por dia emprstimo por centro emprstimo por rea por centro por ms
Tabela 2 Registros Agregados.

Cada tabela de fatos derivada deve estar associada a uma ou mais tabelas de dimenso derivadas. Estas tabelas derivadas necessitam de chaves artificiais totalmente novas, que no constam da tabela de nvel bsico. A figura 2 mostra um exemplo deste esquema.

Centro Agregado Fatos Emprstimo chave_tempo chave_centro chave_obra quantidade_usuarios unidades_emprestadas

Dimenso Centro chave_centro centro

Figura 2 Tabela de Fatos Agregados Emprstimos por Centro.

A tcnica de criao de novas tabelas de fatos vem sendo recomendada para projetos de data warehouse, apesar do elevado nmero de novas tabelas que ela implica, devido a algumas razes citadas por [KIM96b]:
S A administrao dos agregados mais modular e segmentada quando os agregados ocupam

tabelas separadas.
S Existe uma soluo bem estruturada para que o elevado nmero de tabelas a mais geradas pelas

novas tabelas seja transparente para o usurio: o navegador de agregados.


S Elimina o risco de um usurio final contar duplamente, de forma acidental, totais de fatos, pois

h tabelas de fatos separadas de acordo com a granularidade desejada.


S Se ocupassem uma s tabela, os resultados de determinados agregados exigiriam campos da

tabela com tamanho maior para receberem valores muito elevados. Com a tcnica de vrias tabelas, os campos das tabelas de dimenso no precisam ser aumentados devido possibilidade de ocorrncia destes valores elevados (resultados de agregados).
S Com tabelas separadas, os agregados podem ser desenvolvidos de forma independente e

separadamente, sem afetar os j existentes. 2.2.2. INSERO DE CAMPOS NVEL NA TABELA DE FATOS BSICA Nesta tcnica, cria-se um novo campo denominado Nvel em cada uma das tabelas de dimenso em questo. Dessa forma, os registros de fatos agregados podem residir na tabela de fatos original. Alm do mesmo nmero de registros da primeira tcnica, tambm devem ser geradas as mesmas chaves agregadas na tabela de fatos e nas tabelas de dimenso. O fato de compartilhar tabelas gera vrias complicaes, tais como a possibilidade de valores duplicados devido a existncia numa mesma tabela de medidas diferentes para uma mesma dimenso; a administrao destas tabelas que exige um acompanhamento de perto do administrador

para aumentar o tamanho dos campos das tabelas de acordo com a necessidade ou para acrescentar ou excluir agregados, de acordo com a demanda de consultas dos usurios. Comparando-se estas duas tcnicas, nota-se que a nica diferena existente est relacionada com o local de armazenamento dos registros de dimenso agregados e os registros de fatos agregados. Enquanto que na tcnica de criao de novas tabelas de fatos gera-se um grande nmero de novas tabelas, na tcnica de insero de campos Nvel todos os novos registros agregados so armazenados na tabela de fatos e na tabela de dimenso originais e no em novas tabelas.

2.3. DISPERSO E EXPLOSO DE AGREGADOS


O planejamento do tamanho das tabelas pode ser difcil em virtude da disperso. Sabemos que a tabela de fatos de nvel bsico normalmente bastante dispersa na localizao das chaves. Entretanto, na construo de agregados, a taxa de ocupao do banco de dados aumenta drasticamente, podendo aumentar mais de 400%. No entanto, projetando-se tabelas de agregados de forma que uma consulta possa ser satisfeita atravs de uma tabela de agregados hierarquicamente inferior, pode-se alcanar uma soluo para este problema. Por exemplo, totais anuais podem ser obtidos a partir de totais mensais, ao invs de partir de uma tabela anual, eliminando assim algumas tabelas agregadas em favor de outras. Para visualizar como a exploso de agregados ocorre, pode-se tomar o exemplo da rede de mercados (Grocery), apresentado por [KIM96b]. A tabela 3 apresenta dados sobre o problema.
Tabela Base: produto por loja por dia Unidirecional: categoria por loja por dia Unidirecional: produto por distrito por dia Unidirecional: produto por loja por ms Bidirecional: categoria por distrito por dia Bidirecional: categoria por loja por ms Bidirecional: produto por distrito por ms Tridirecional: categoria por distrito por ms TOTAL GERAL
Tabela 3 Dados sobre o problema Rede de Mercados.

Produto 10.000 2.000 10.000 10.000 2.000 2.000 10.000 2.000

Loja Tempo Disperso 1.000 1.000 100 1.000 100 1.000 100 100 100 100 100 30 100 30 30 30 10% 50% 50% 50% 80% 80% 80% 100%

N Registros 100 milhes 100 milhes 50 milhes 150 milhes 16 milhes 48 milhes 24 milhes 6 milhes 494 milhes

Comparando os dados acima, tem-se para o primeiro agregado, unidirecional, Categoria por loja por dia, embora apenas 10% dos produtos de nvel bsico sejam vendidos em uma determinada loja

em um determinado dia, a representao do nvel Categoria em uma loja em um dia ser muito maior. Pode-se facilmente encontrar 50% das categorias nos dados dirios de uma loja em oposio aos 10% de produtos individuais. A disperso ainda mais drstica para agregados bidirecionais. A expectativa encontrar 80% das Categorias vendidas no nvel Distrito a cada dia. E para o agregado tridimensional obtm-se 100% das Categorias vendidas no nvel Distrito Mensalmente. O banco de dados original cresceu de 100 milhes de registros bsicos para 494 milhes de registros com agregados, aumentando 394%, apesar de nenhuma das dimenses ter aumentado mais de 30%. Talvez seja difcil prever a disperso de forma exata, mas ela certamente ocorrer em alguma proporo na construo de agregados.

3. EXPERIMENTO
O problema escolhido para avaliar as influncias (positiva e negativa) do uso de agregados foi a parte de emprstimos de livros em uma biblioteca. A partir de uma base de dados existente, cuja modelagem suporta todos os processos realizados naquele setor, criou-se um esquema estrela composto por uma tabela de fatos Emprstimo e trs tabelas de dimenso: Obra, Curso e Tempo. A figura 3 apresenta o esquema estrela, bem como a estrutura de cada tabela. A granularidade utilizada no experimento diria.
Dimenso Obra chave_obratitul o subttulo autor cdu cutter volume tipo_obra Tabela de Fatos Emprstimo chave_tempo chave_obra chave_curso quantidade_usuarios unidades_emprestadas Dimenso Curso chave_curso nome centro campus turno habilitao Dimenso Tempo chave_tempo dia mes ano dia_ano dia_semana semestre periodo_prova

Figura 3 Esquema estrela do problema.

As informaes referentes aos emprstimos de livros podem auxiliar na tomada de decises quanto aquisio de livros, por exemplo. Respostas questes como Qual a quantidade de ttulos emprestados aos alunos de determinado curso no 1 semestre ? do subsdios para verificao de quais livros so mais usados pelos alunos. Como conseqencia, este livro um candidato a ser adquirido pelo setor (principalmente se houver pequeno nmero de exemplares). Para a realizao do experimento, foram construdos alguns agregados uni, bi e tridimensionais relativos questes estratgicas. Estes agregados alteram o esquema estrela do DW (figura 4), pois para cada agregado foram geradas duas ou mais novas tabelas conforme o n de dimenses envolvidas no processo. As tcnicas utilizadas nesta construo foram a pr-agregao e a criao de novas tabelas de fatos.
Ms_Centro Agregado Fatos Emprstimo chave_ms chave_obra chave_centro quantidade_usuarios unidades_emprestadas Centro Agregado Fatos Emprstimo chave_tempo chave_obra chave_centro quantidade_usuarios unidades_emprestadas

Dimenso Ms chave_ms ms

rea_Ms_Centro Agregado Fatos Emprstimo chave_ms chave_rea chave_centro quantidade_usuarios unidades_emprestadas

Dimenso Centro chave_centro centro campus

Ms Agregado Fatos Emprstimo chave_ms chave_obra chave_curso quantidade_usuarios unidades_emprestadas

Dimenso rea chave_rea rea

Semestre_Centro Agregado Fatos Emprstimo chave_obra chave_centro chave_semestre quantidade_usuarios unidades_emprestadas

Dimenso Semestre chave_semestre semestre Figura 4 Esquema estrela com as tabelas derivadas.

As questes referentes aos agregados citados acima so apresentadas pela Tabela 4. Questes deste tipo foram utilizadas para realizar o experimento alvo deste trabalho.
Questo 1. Quantos emprstimos so feitos por centro ? 2. Quantos usurios de cada curso efetuam emprstimos por ms ? 3. Quantas unidades so emprestadas por ms por centro ? 4. Quantos usurios de cada curso efetuam emprstimos por semestre por centro ? 5. Quantas unidades so emprestadas por ms por centro por rea ?
Tabela 4 Agregaes realizadas.

Dimenses Agregadas Curso Tempo Tempo e Curso Tempo e Curso Tempo, Curso e Obra

O banco de dados original tinha cerca de 80 MB de tamanho. A insero das tabelas referentes ao esquema estrela apresentado na figura 3 fez com que este banco aumentasse seu tamanho em 7,82 MB (um crescimento de 9,72%). J os agregados impuseram um crescimento de 11,61% ao banco (aumentando-o em 9,34 MB). Para comprovao da melhoria no tempo de processamento de uma consulta, foram realizadas vrias queries SQL sobre o banco de dados e, em seguida, sobre a verso modificada do banco agregados. Ao final de cada uma, o tempo de execuo era observado. Para esta comparao, foi utilizado um microcomputador Pentium 200, 48 MB de RAM, 2.1 GB de disco, isolado da rede, e sem aplicativos adicionais executando, para no influenciar os resultados. O sistema operacional utilizado foi o Windows NT 4.0 Service Pack 3. O status do equipamento mostrado na figura 5.

Figura 5 Status do equipamento.

A tabela 5 apresenta os resultados referentes a trs das consultas realizadas, para que se possa compar-los. Cada consulta se refere a um tipo de agregado formado (uni, bi e tridimensional).
Query SQL: Quantos emprstimos so feitos pelo Centro de Cincias da Sade ? Itens Registros na Tabela de Fatos Registros Resultantes da Query Tempo de Execuo do SQL % Ganho de Tempo de Execuo BD sem agregao 43.353 5.767 7.231 ms

BD com agregao 43.345 5.767 3.625 ms 50 %

Query SQL: Quantas unidades foram emprestados ao Centro de Cincias da Sade em 06/99 ? Itens Registros na Tabela de Fatos Registros Resultantes da Query Tempo de Execuo do SQL % Ganho de Tempo de Execuo BD sem agregao 43.353 450 5.268 ms

BD com agregao 42.898 450 741 ms 85 %

Query SQL: Quantos emprstimos da Sade so feitos pelo Centro de Cincias da Sade em 06/99 ? Itens Registros na Tabela de Fatos Registros Resultantes da Query Tempo de Execuo do SQL % Ganho de Tempo de Execuo BD sem agregao 43.353 1 662.452 ms
Tabela 5 Resultados obtidos.

BD com agregao 629 1 60 ms 99 %

4. CONCLUSO
fato que o uso generalizado de agregados impacta o banco de dados quanto ao seu tamanho (efeito de disperso e exploso de agregados). Porm, viu-se que neste exemplo no houve um crescimento exagerado do banco de dados. Isto deve ter ocorrido em virtude do pequeno nmero de registros, da simplicidade do banco de dados utilizado e, tambm, da qualidade das informaes. Uma comprovao alcanada neste experimentos foi quanto ao fato de que alguns agregados elevam o tamanho do banco sem necessidade, pois suas respostas podem ser obtidas a partir de outros agregados menores existentes. A resposta para a quarta questo da tabela 4, que manipula valores semestrais, pode ser facilmente obtida pela soma dos registros agregados pela questo 3 daquela mesma tabela, cujos valores esto identificados mensalmente.

Em contrapartida, alguns agregados podem gerar apenas novas tabelas de fatos agregados. Isto ocorre quando as dimenses relacionadas a presente consulta j foram agregadas da mesma forma para outras queries. Um exemplo desta situao dado pela terceira questo da tabela 4, onde as agregaes por ms e centro j tinham sido utilizadas para as questes 1 e 2 da mesma tabela. Portanto, os agregados devem ser projetados considerando esta possibilidade, e vantagem, de reaproveitamento. Quanto a disperso dos dados, para o primeiro agregado, unidirecional, emprstimos por Centro por dia, foram encontrados pelo menos 50% das centros nos dados dirios. A disperso foi bem mais forte para agregados bidirecionais e tridimensionais, pois obteve-se cerca de 100% dos valores relacionados. Quanto ao desempenho das consultas, v-se uma melhora muito grande. Quanto mais dimenses agregadas envolvidas na query mais rpida ser a obteno da resposta. Claro que a montagem do esquema estrela agregado leva um tempo considervel pois h o resumo das informaes. Logo, deve-se agregar dinamicamente aquelas consultas mais elaboradas e que so utilizadas com uma certa freqencia, agilizando o processo decisrio da empresa ou setor.

5. REFERNCIAS BIBLIOGRFICAS
INMON, W.H. Como construir um data warehouse. Rio de Janeiro, 1997. ISBN 85-352-0141-6. 388p. KHADER, A.; MEREDITH, M.E. Divide and Aggregate: Designing Large Warehouses. Database Programming & Design On-Line. Documento on-line disponvel na Internet. <http://www.db.pd.com/vault/khader.htm>, Maio, 1999. [KIM96] KIMBALL, R. The Aggregate Navigator. Coluna Data Warehouse Architect. Revista DBMS. Novembro, 1995. [KIM96b] KIMBALL, R. The Data Warehouse Toolkit. New York: John Wiley & Sons, Inc., 1996. [MCG99] MCGUFF, F. Data Modeling for Data Warehouse. Documento on-line disponvel na Internet. <http://members.aol.com/fmcguff/dwmodel/part10.htm>, Maro, 1999. [INM97] [KHA99]

You might also like