Fundamentos e Modelagem de Bancos de Dados Multidimensionais

Contedo Introduo Fundamentos de Sistemas Analticos Sistemas Transacionais X Sistemas Analticos Data Warehouses e Data Marts Bancos de Dados Multidimensionais Modelos de Dados Multidimensionais Alguns Conceitos Estrela e suas Variaes Snowflake e suas Variaes Concluso Referncias Resumo: Este artigo apresenta estruturas de indexao para bancos de dados multidimensionais, as rvores Bitmap, comparando com as estruturas usadas para bancos de dados relacionais. Ento percorremos diversas opes para modelagem de dados multidimensionais, incluindo os Modelos Estrela e Snowflake e suas variaes.

Introduo
A utilizao de Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDRs) prtica consolidada mundialmente. Os dados precisam poder ser armazenados e recuperados geralmente em intervalos curtos de tempo, em situaes no triviais tais como:

Situaes de alta concorrncia, por vezes de milhares de acessos simultneos, que

precisam ser gerenciados em ambientes transacionais; Grandes web sites que, alm dos requisitos de desempenho, necessitam cuidados especificamente com relao segurana dos dados; Aplicaes analticas, baseadas em histricos de anos, para apoio a decises gerenciais e estratgicas.

As estruturas de dados e mecanismos de indexao utilizados por esses SGBDRs atendem bem s duas primeiras situaes. Todavia, as aplicaes analticas possuem peculiaridades tais como manipulao de grandes volumes de dados e baixa taxa de atualizao. Essas caractersticas favorecem outro modelo estrutural, mais eficiente e por vezes mais econmico, no tocante a espao de armazenamento. Conhecendo as estruturas de dados, a compreenso das alternativas de modelagem de dados multidimensional, base dos sistemas analticos, fica facilitada. Neste texto abordaremos as principais diferenas entre sistemas transacionais e analticos, bem como algumas estruturas de indexao comumente utilizadas para cada tipo. Apresentaremos, ainda, consideraes importantes quanto modelagem de dados multidimensional, incluindo os modelos estrela e snowflake e suas variaes.

Fundamentos de Sistemas Analticos

Nos ltimos anos o termo Business Intelligence (BI) tem sido largamente utilizado no mercado como sinnimo de sistemas analticos, OLAP, cubos, entre outros. Embora essas denominaes possam estar associadas entre si, so conceitualmente distintas. A rigor, Business Intelligence pode ser obtido por qualquer artefato, seja tecnolgico ou no, que permita a extrao de conhecimento a partir de anlises do negcio. Por razes bvias, a efetividade destas anlises ser maior se os dados estiverem disponveis de modo consistente e, preferencialmente, consolidado. Este um dos objetivos dos Data Warehouses. Solues informatizadas de BI geralmente contm sistemas analticos, que podem ser de diversos tipos, dependendo do objetivo das anlises e do perfil do usurio, conforme ilustrado na Figura 1:

Decision Support Systems (DSS), ou Sistemas de Apoio a Deciso: so baseados

em relatrios analticos, normalmente utilizados por usurios de nvel operacional; Management Information Systems (MIS), ou Sistemas de Informaes Gerenciais: permitem anlises mais profundas, com a realizao de simulaes de cenrios. Por vezes, utilizam-se de ferramentas de Data Mining para identificao de cruzamentos no triviais. So utilizados por analistas de negcio no nvel ttico; Executive Information Systems (EIS), ou Sistemas de Informaes Executivas: so voltados para profissionais que atuam no nvel estratgico das empresas, como diretores e presidncia. Oferecem, para tanto, um conjunto de indicadores chave de desempenho (KPI, ou Key Performance Indicators).

Figura 1: alguns tipos de sistemas analticos. O afinamento da pirmide indica quantidades menores e mais especficas de usurios para cada sistema.

Independentemente do tipo de sistema analtico, este difere substancialmente dos sistemas transacionais de produo. A seguir, apresentaremos tais diferenas, bem como os conceitos envolvidos.

Sistemas Transacionais X Sistemas Analticos

Sistemas transacionais, tambm conhecidos como sintticos ou ainda OLTP Online Transactional Processing - so aqueles que, como o nome sugere, baseiam-se em transaes. Alguns exemplos deste tipo de sistemas so:

Sistemas Contbeis; Aplicaes de Cadastro; Sistemas de Compra, Estoque, Inventrio; ERPs, CRMs.
Os sistemas transacionais se caracterizam pela alta taxa de atualizao, grande volumes de dados e acessos pontuais, ou seja, pesquisas cujo resultado seja de pequeno volume (at milhares de linhas, mas preferencialmente menos). J os sistemas analticos, ou OLAP Online Analytical Processing se caracterizam por fornecer subsdio para tomadas de deciso, a partir de anlises realizadas sobre bases de dados histricas, por vezes com milhes de registros a serem totalizados. Alguns exemplos de sistemas analticos so os ilustrados na Figura 1. A Tabela 1 sintetiza as principais diferenas entre sistemas transacionais e analticos: Tabela 1: Comparao entre sistemas transacionais e analticos.

Caracterstica
Atualizaes Tipo de Informao Quantidade de Dados Preciso Complexidade Consistncia Exemplos Terminologia

Sistemas Transacionais(OLTP)
Mais freqentes Detalhes Poucos Dados atuais Baixa Microscpica CRM, ERP, Supply Chain Linhas e Colunas

Sistemas Analticos(OLAP)
Menos freqentes Agrupamento Muitos Dados histricos Alta Global MIS, DSS, EIS Dimenses, Medidas e Fatos

Conforme ilustrado na tabela acima, o fato dos sistemas transacionais refletirem a situao atual de um determinado tipo de dado conduz todas as demais caractersticas, como:

A realizao de atualizaes freqentemente, mantendo os dados atuais; Informao detalhada com a maior granularidade possvel (consistncia

microscpica); Pesquisas pontuais, portanto de baixa complexidade, no tocante ao negcio (do ponto de vista tcnico, a pesquisa pode ser bem elaborada).

Do mesmo modo, o fato das anlises serem realizadas sobre dados histricos leva s seguintes caractersticas:

Uma vez que os dados so histricos, as atualizaes no precisam ser to

freqentes. Por exemplo, numa comparao entre a produtividade de trs filiais de uma empresa para um determinado produto nos ltimos quatro meses, por ms, o dia de hoje ou mesmo ontem no , em geral, de grande representatividade; As anlises geralmente agrupam informaes, sendo tais agrupamentos mais importantes neste contexto do que os dados detalhados. No exemplo do item anterior, o importante a produo conjunta mensal, e no a produo de uma unidade particular do produto analisado. Os diferentes tipos de sistemas tambm sugerem diferentes abordagens tcnicas, seja na forma de armazenamento ou de busca. No caso dos sistemas transacionais, que exigem acesso rpido aos dados, principalmente no tocante a modificaes, a utilizao de ndices estruturados como rvores balanceadas, ou B-Trees, adequada. No entanto, essa estrutura no a mais recomendada para sistemas analticos, onde as atualizaes so espordicas, mas as consultas envolvem grandes conjuntos de dados e devem ser muito rpidas. Outra estrutura de dados, denominada rvore PATRICIA, mais adequada neste contexto. As prximas duas sees descrevem o funcionamento dessas duas estruturas. rvores Balanceadas (B-Trees) Este tipo de rvore, empregada por vrios SGBDRs comerciais ou no, possui a denominao balanceada pelo fato das folhas estarem praticamente mesma distncia da raiz, podendo diferir em apenas um nvel. A Figura 2 ilustra uma rvore balanceada:

Figura 2: exemplo de rvore balanceada.

A figura acima mostra uma busca na rvore, que pode ser realizada de modo eficiente. O fato da rvore acima ser binria mera coincidncia. Vale notar que uma insero neste tipo de rvore pode ser realizada com pequena quantidade de operaes, conforme ilustrado na Figura 3. Essas operaes denominam-se rotaes, e visam a manuteno da rvore como balanceada. Nos dois casos, a insero foi realizada em g, de modo a desbalancear a rvore. As rotaes sugeridas reparam a situao.

Figura 3: inseres em rvores balanceadas. rvores PATRICIA Concebido por Donald. R. Morrison (1) e descrito em (2), PATRICIA um algoritmo para realizao de buscas em rvores com as chaves dos ns representadas em binrio, sem armazenar as chaves nos ns. O nome um acrnimo de Practical Algorithm To Retrieve Information Coded In Alphanumeric, e o mtodo particularmente til para tratamento de chaves de tamanho varivel extremamente longas, tais como ttulos e frases. No caso de pesquisas analticas, os dados podem tirar proveito deste mtodo desde que as informaes sejam armazenadas como cadeias de texto. Uma restrio dessas rvores a necessidade de no haver um elemento que seja prefixo de outro, o que pode facilmente ser obtido se necessrio. Em nosso exemplo, utilizaremos a codificao apresentada na Tabela 2 para as letras de A a Z: Tabela 2: representao binria das letras do alfabeto.

Caractere <espao> A B C D E F G H I J K L M N O P Q R S T U V W X Y

Representao Decimal 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Representao Binria 00000 00001 00010 00011 00100 00101 00110 00111 01000 01001 01010 01011 01100 01101 01110 01111 10000 10001 10010 10011 10100 10101 10110 10111 11000 11001

26

11010

O caractere <espao> utilizado como separador entre as palavras. A Tabela 3 ilustra a representao binria da frase ESTE FOI UM ESTUDO DE ARVORE PATRICIA: Tabela 3: representao em binrio das palavras do exemplo.

A partir da frase acima possvel construir a rvore PATRICIA ilustrada na Figura 4:

Figura 4: rvore PATRICIA. As setas tracejadas indicam um ancestral do n corrente, e as setas Cheias indicam seus descendentes. Cada n da rvore possui as seguintes informaes:

KEY: um ponteiro para o incio da palavra no texto original. Por exemplo, ao invs

do texto (ESTUDO), o n deveria conter 13, que a posio na frase do incio da palavra; LLINK e RLINK: ponteiros representando zero e um, respectivamente. Mais detalhes no exemplo de busca na rvore a seguir; LTAG e RTAG: campos binrios indicando se LLINK e RLINK, nesta ordem, so ponteiros para ns ancestrais (valor um, representado pelas setas tracejadas na Figura 4) ou descendentes (valor zero, correspondente s setas cheias na Figura 4). Por conveno, um n pode ser ancestral de si mesmo; SKIP: o nmero de bits que podem ser pulados durante uma busca. O exemplo de busca a seguir ilustra esse conceito.

A raiz da rvore contm apenas KEY, LLINK e LTAG. Busca em rvores PATRICIA O algoritmo de busca relativamente simples. Ilustraremos aqui dois casos: 1. Busca por um elemento presente na rvore: procura pela palavra FOI (em binrio, 00110 01111 01001) A busca inicia no n esquerda da raiz, (UM). O campo SKIP pede para analisarmos o bit 1. Se valer 0, procura esquerda. Se valer 1, procura direita. No exemplo, seguimos para a esquerda; Estando no n (ARVORE), o campo SKIP = 2 somado aos SKIPs anteriores, ou 1 + 2, pede para analisar o bit 3 do texto sendo procurado. Como vale 1, procura direita; Estando no n (FOI), o campo SKIP pede para analisar o bit 4. Como vale 1, segue direita; Como o n corrente no mudou, testa o valor da chave para saber se encontrou. Esse teste importante, uma vez que o padro 0x11x xxxxx xxxxx foi encontrado. Uma busca pelo texto FUI tambm terminaria no mesmo padro. 2. Busca por todos os elementos que comeam com uma cadeia. Por exemplo, busca por todos os elementos que comecem por EST (em binrio, 00101 10011 10100): A busca procede da mesma forma que a anterior, at o momento em que tenta-se comparar bit inexistente (16 bit) no texto procurado (15 bits); Nesse ponto, compara-se o texto procurado com o elemento corrente (ESTUDO). Se encontrou, ento o mesmo padro tambm est presente nos descendentes e ancestrais deste n, devendo ser ento comparados. Construo de rvores PATRICIA Este algoritmo funciona da seguinte forma: 1. A raiz da rvore contm a primeira palavra lida, conforme a Figura 5; 2. A partir da, para cada novo elemento, fazemos duas buscas: A primeira para procurar a provvel localizao do elemento. Considerando todos os elementos distintos, essa busca sempre ser mal-sucedida; Na posio encontrada na primeira busca, determina-se quantos bits coincidem com o elemento novo; Da, faz-se nova busca para encontrar precisamente a posio a inserir o novo elemento. A seqncia de figuras a seguir ilustra a construo da rvore da Figura 4:

Figura 5: seqncia de figuras ilustrando a construo de uma rvore PATRICIA. A rvore completa est na Figura 4. Embora seja uma estrutura de dados muito eficiente no que diz respeito a buscas, executando em tempos O(lgN), onde N o nmero de elementos da rvore, o custo de atualizaes grande, inviabilizando seu uso para aplicaes transacionais. Inicio da pagina

Data Warehouses e Data Marts

Esses dois conceitos comumente se associam ao uso de aplicaes analticas. Um Data Warehouse uma base de dados, geralmente relacional, que consolida as informaes empresariais. Sua construo (3) um processo normalmente moroso e complexo, por diversos fatores, dentre os quais a grande quantidade de dados, diversas fontes de informaes com bases heterogneas e muitas vezes inconsistentes, envolvimento de vrias reas ou departamentos da empresa. Um dos maiores desafios na construo do DW a extrao e consolidao dos dados operacionais, pois:

 Pode haver vrias fontes; Os dados precisam ser limpos; A granularidade precisa ser ajustada; Pode ser necessrio resumir dados; Deve haver valores default e tratamento de NULL; necessrio componente temporal; Os relacionamentos nos dados de entrada precisam ser claros.
Algumas situaes comuns entre as fontes de dados:

Mesmos dados, nomes diferentes; Dados diferentes, mesmo nome; Dados exclusivos de uma aplicao; Chaves diferentes, mesmos dados.
Como mtodos de construo, existem formalmente dois:

Top-down, no qual realizada a modelagem integral do DW, seguida pelas

extraes de dados. A principal vantagem a criao de um modelo nico. O revs fica por conta do maior tempo de projeto; Bottom-up, onde o foco em uma rea por vez, com o crescimento gradual do DW. A vantagem a obteno de resultados a intervalos mais curtos, garantindo muitas vezes sustentao ao projeto. A desvantagem a maior dificuldade de se consolidar informaes entre as diversas reas. Uma alternativa s estratgias acima, denominada Middle-out, aproveitar as vantagens de cada uma por meio do desenvolvimento iterativo do DW: 1. O modelo de dados corporativo o primeiro a ser desenvolvido e o responsvel pela integrao dos demais; 2. As primeiras tabelas da rea de interesse escolhida so povoadas: primeiras anlises; 3. Povoamento de mais tabelas com dados histricos; 4. Alguns dados passam a compor o DW, saindo da base operacional; 5. Surgimento dos data marts (a seguir nesta seo); 6. O ciclo se repete at que o DW esteja completo. Bases de produo contm apenas dados operacionais. Outro fator crtico para o sucesso de um DW o gerenciamento do volume. Embora o conceito de DW se aplique a grandes quantidades de dados, chegando atualmente a ordem de TB, sua capacidade no infinita, devendo ser utilizada sabiamente. Apenas dados relevantes deveriam constar do DW. Pode ser que o horrio de uma determinada transao seja importante quando o foco for o curto prazo, mas que apenas um contexto de agrupamento seja suficiente para dados de cinco anos atrs. Questes como essa devem ser consideradas durante o planejamento do DW, pois ajudam a dimension-lo. A remoo de dados do DW um assunto tratado com receio pelos DBAs e pelos analistas de negcio. A rigor, to importante quanto saber que dados armazenar, saber quando e quais dados remover do DW. Algumas estratgias so:

esumir dados mais antigos; Armazenar os dados antigos em meio mais barato (fita); Remover os dados do DW.

Tais estratgias no so excludentes, podendo ser utilizadas em conjunto. A importncia da remoo de dados est em manter o DW o mais enxuto possvel, embora isso possa parecer contraditrio ao conceito de DW. Com relao granularidade, as bases de dados operacionais trabalham com o maior nvel de detalhe possvel, ou seja, a maior granularidade. J no DW pode haver diversos graus de agregao e resumo dos dados. Por exemplo, os dados do ano corrente podem ser detalhados por item de pedidos, de um a cinco anos, por total de cada pedido e, aps isso, por total de pedidos por dia. A correta determinao da granularidade exerce papel fundamental no planejamento de capacidade e desempenho do DW. Ao contrrio do que ocorre com as bases operacionais, o DW, por conter dados histricos, no demanda alta taxa de atualizao. Desse modo, pode ser atualizado a cada 24 horas ou at mesmo uma vez por semana. Alm disso, por sofrer poucas modificaes, e de forma controlada (por aplicaes especficas para esse fim), seus relacionamentos podem ser implementados atravs de entidades, embora isso no seja freqente. Embora consolide as informaes da empresa, mesmo que de modo iterativo, os DWs so geralmente armazenados em bancos de dados relacionais, e no se utilizam de estruturas tais como as rvores PATRICIA. Neste ponto surgem os Data Marts (DM), bancos de dados multidimensionais especficos por rea de negcio para realizao de anlises. Alguns conceitos sobre Data Marts no esto muito bem claros para o mercado. O processo de construo de um DW e de DMs, ilustrado na Figura 6, ajuda a esclarecer alguns deles:

Figura 6: etapas da construo de um DW e de DMs.

Como pode ser notado na figura acima, um DW construdo iterativamente possui pores agrupadas por segmento de negcio, regio ou qualquer outra forma que seja adequada empresa. Essas pores alimentam os Data Marts, que podem ser ento consultados por ferramentas de anlise. Inicio da pagina

Bancos de Dados Multidimensionais

A finalidade de bases de dados multidimensionais (alguns autores chamam de dimensionais) fornecer subsdio para realizao de anlises. Para tanto, sua arquitetura e at mesmo a terminologia empregada so distintas das utilizadas para bancos de dados transacionais. O fato de existirem diversas informaes a serem cruzadas (dimenses) permite a realizao de pesquisas tais como a ilustrada na Figura 7:

Figura 7: exemplo de pesquisa multidimensional. Terminologia As anlises sobre dados histricos envolvem uma srie de possibilidades de cruzamentos e agrupamentos de informaes, com o uso dos seguintes termos:

Dimenses: estabelecem a organizao dos dados, determinando possveis

consultas/cruzamentos. Por exemplo: regio, tempo, canal de venda,... Cada dimenso pode ainda ter seus elementos, chamados membros, organizados em diferentes nveis hierrquicos. A dimenso tempo, por exemplo, pode possuir duas hierarquias: calendrio gregoriano (com os nveis ano, ms e dia) e calendrio fiscal (com os nveis ano, semana e dia);

 Medidas: so os valores a serem analisados, como mdias, totais e quantidades; Fatos: so os dados a serem agrupados, contendo os valores de cada medida para
cada combinao das dimenses existentes. O tamanho da tabela que contm os fatos merece ateno especial do analista; Agregaes: totalizaes calculadas nos diversos nveis hierrquicos. A criao de DMs implica na gerao de agregaes. Este processamento se reflete em ganho de desempenho quando da realizao de consultas. Alicerce Relacional Diversas ferramentas analticas, tambm chamadas ferramentas de OLAP, operam sobre bases de dados multidimensionais armazenadas em SGBDRs. Alm disso, as agregaes so tambm mantidas em banco de dados relacional. Esta forma de armazenamento conhecida como ROLAP, ou Relational OLAP. Uma vez que os dados j se encontram em um modelo apropriado, chamado multidimensional (veja opes de modelagem nas prximas sees), basta processar as agregaes. Com isso obtm-se ganho de espao de armazenamento, uma vez que os dados permanecem apenas na base de origem (multidimensional), embora a criao de grandes quantidades de agregaes possa incorrer em exploso de dados. Alicerce em Cubos Outra forma de armazenamento, cujo modelo matemtico denomina-se hipercubos, apresenta a caracterstica de possuir armazenamento e indexao em estruturas de dados que otimizam consultas ao invs de atualizaes, como o caso das rvores PATRICIA. Esta forma erroneamente chamada MOLAP, ou Multidimensional OLAP. O erro est no fato de que bases ROLAP tambm so multidimensionais. Quando o modelo multidimensional processado, nova base gerada, desta vez contendo tanto os dados quanto as agregaes em formato prprio, utilizando-se de estruturas apropriadas para pesquisas. A Figura 8 ilustra uma representao de um cubo com trs dimenses:

Figura 8: representao de um cubo com as dimenses Produto, Regio e Tempo. Embora o risco de exploso de dados seja comum em estruturas relacionais por conta de cruzamentos sem dados, mas que ocupam algum espao, as estruturas utilizadas pelos cubos so esparsas, e se aplicam a dados e agregaes, de modo que os cubos so substancialmente menores do que a base multidimensional que o originou. Inicio da pagina

Modelos de Dados Multidimensionais

A natureza do uso de bancos de dados multidimensionais torna sua modelagem distinta daquela utilizada para sistemas transacionais. Neste ltimo aplicamos tcnicas de normalizao seguidas por graus de desnormalizao a fim de obter o desempenho desejado ao reduzir o nmero de tabelas em junes (joins). Vale lembrar que o nmero de planos de execuo para uma juno de n tabelas n!, isto , para uma juno de 10 tabelas h 3.628.800 possibilidades. Embora o escalonador do SGBD possua estratgias para reduzir este nmero, um ponto de ateno a considerar. J para o caso dos MDDBs, o grau de desnormalizao bem maior, dado o volume de dados e a agilidade na consolidao de valores quando calculando as agregaes. Nesta seo, com trechos extrados de (4) e (5), percorremos alguns conceitos importantes para a modelagem quanto representao de fatos, dimenses e quanto a chaves. Ento descrevemos vrios modelos de dados, sempre do ponto de vista lgico. Portanto, os modelos que veremos sero sempre relacionais, independentemente do alicerce, relacional ou em cubos, que pode ser utilizado para o modelo fsico. Inicio da pagina

Alguns Conceitos

Quando o modelo de dados comea a ser definido, elementos bsicos de representao precisam ter sido estabelecidos, de modo a criar-se um padro de modelagem. Em nosso modelo teremos as dimenses e fatos representados em tabelas, podendo haver mltiplas dimenses e mltiplas tabelas de fatos. Fatos Ao modelar a(s) tabela(s) de fatos (ou apenas tabela fato), deve-se ter em mente os seguintes pontos:

A chave primria composta, sendo um elemento da chave para cada dimenso; Cada elemento chave para a dimenso deve ser representado e descrito na tabela
dimenso correspondente (para efetuar a juno); A dimenso tempo sempre representada como parte da chave primria. Dimenses Deve haver uma tabela dimenso para cada dimenso do modelo, contendo:

Uma chave artificial (ou gerada) genrica; Uma coluna de descrio genrica para a dimenso; Colunas que permitam efetuar os filtros; Um indicador NVEL que indica o nvel da hierarquia a que se refere a linha da
tabela. A Figura 9 ilustra uma tabela para a dimenso Geografia, com os pontos acima representados. Note que a coluna nvel determina a hierarquia (Regio/Estado/Cidade

Figura 9: exemplo de uma tabela de dimenso

Valores nulos iro existir em algumas colunas, dependendo do nvel hierrquico para o qual a linha contenha valores. Esse o caso da coluna loja: como somente existem lojas nas cidades, e no nos estados ou regies, a tabela fica com nulos, conforme identificados pela regio circundada na figura. Todavia, tarefa do modelo fsico reduzir o espao ocupado pelos nulos A Dimenso Tempo Esta uma dimenso que praticamente todos os sistemas analticos possuem, dada a caracterstica de realizao de anlises em dados histricos. Deveria conter:

Uma coluna chave para a juno com a(s) tabela(s) de fato(s); Uma descrio genrica para cada perodo; Colunas que permitam efetuar os filtros; Coluna sinalizadora da presena de fatos para o perodo de tempo indicado na linha; Coluna RESOLUO usada para restringir o perodo ao nvel apropriado - opera de
forma idntica coluna NVEL das outras dimenses Coluna SEQNCIA que contm um nmero seqencial de 1 a n em cada nvel do perodo de tempo e identifica a ordem relativa de cada data. Permite: Coluna SEQNCIA que contm um nmero seqencial de 1 a n em cada nvel do perodo de tempo e identifica a ordem relativa de cada data. Permite: Construes com clculos de tempo, como ltimos quatro dias, por exemplo. A Figura 10 mostra um exemplo de tabela de dimenso tempo. Note que a descrio o que aparecer para os valores de uma determinada data ou perodo.

Figura 10: exemplo de uma tabela para a dimenso tempo Consideraes sobre Chaves No tocante s chaves, sistemas analticos devem contar com chaves artificiais, por uma srie de motivos:

Qualquer atualizao de dados fica simplificada. Por exemplo, um recadastramento

de CPFs, embora improvvel, poderia resultar em atualizao de grande volume para uma tabela de fatos de transaes bancrias, caso o cliente fosse identificado com CPF sendo chave; Com uma nica coluna para a chave, geralmente de tipo inteiro, o desempenho de pesquisas tende a ser melhor quanto menor o tamanho da chave, melhor o desempenho; O fato de ser chave simples facilita a execuo de junes.

Inicio da pagina

Estrela e suas Variaes

Uma das formas de apresentao de um banco de dados multidimensional atravs do Modelo Estrela, apresentado por Ralph Kimball (4). No centro da estrela encontra-se a tabela de fatos e, ao seu redor, as dimenses. Este modelo apresentado na Figura 11:

Figura 11: Modelo Estrela

 um modelo simples e eficiente, caracterizado por possuir uma nica tabela de fatos e chaves simples nas tabelas de dimenses. Cada dimenso representada por uma nica tabela. Os pontos positivos deste modelo so a eficincia, dada pelo reduzido nmero de junes nas pesquisas e pelas chaves simples, e a facilidade de definir hierarquias. Os pontos negativos so o tamanho e a desnormalizao das tabelas de dimenses. Modelo Estrela Parcial uma variao do Modelo Estrela, na qual existem vrias tabelas fato e de dimenso separadas lgica e fisicamente por nveis de sumarizao. Desse modo, os dados so particionados em granularidades distintas. Por haver vrias tabelas fato, na prtica existem vrias estrelas, cada uma representando uma combinao de nveis de agregao em cada dimenso. A Figura 12 apresenta uma parte do modelo que ilustra esta variao.

Figura 12: exemplo de duas estrelas no Modelo Estrela Parcial Quando houver necessidade de novas agregaes, basta criar outras tabelas com as granularidades desejadas, como ilustrado na Figura 13.

Figura 13: Modelo Estrela Parcial para composies de agregaes Os pontos positivos deste modelo so a maior economia de espao, eliminando redundncias e colunas que no tm sentido para determinado nvel de agregao e o melhor desempenho para consultas de nvel especfico de agregao. Por outro lado, a complexidade do modelo maior e as consultas que combinam nveis de agregao distintos so mais elaboradas, podendo resultar em queda de desempenho. Modelo Estrela com Particionamento de Fatos (ou Modelo Constelao de Fatos) uma variao do Modelo Estrela Parcial, na qual os fatos so particionados e as dimenses compartilhadas, conforme ilustrado na Figura 14.

Figura 14: Modelo Particionamento de Fatos Quando comparado ao Modelo Estrela Parcial, este modelo menos exigente quanto sua manuteno, dado o compartilhamento das tabelas de dimenso. Modelo Estrela com Particionamento de Dimenses Assim como o anterior, uma variao do Modelo Estrela Parcial, porm com as dimenses particionadas, compartilhando a tabela de fatos. A Figura 15 apresenta este modelo. Note que a tabela de fatos deve conter os seus dados na maior granularidade que o modelo previr e tambm consolidados de acordo com os nveis mais altos.

Figura 15: Modelo Particionamento de DImenses, para local e tempo. Note a granularidade da tabela de fatos. Este modelo particularmente til quando houver dimenses com grande quantidade de elementos, como o caso de SKUs de produtos, por exemplo. Inicio da pagina

Snowflake e suas Variaes

Os Modelos Snowflake acrescentam graus de normalizao s tabelas de dimenses do Modelo Estrela, eliminando redundncias e a necessidade do indicador NVEL. A Figura 16 mostra o resultado da normalizao das tabelas Produtos e Lojas apresentadas na Figura 11. Observe a reduo nas redundncias, o que resulta em agilidade na manuteno. Apesar disso, um modelo que resulta em maior nmero de tabelas em junes, podendo haver queda de desempenho.

Figura 16: Modelo Snowflake, aps normalizao do Modelo Estrela da Figura 11 A seguir veremos trs variaes do Modelo Snowflake. Modelo Snowflake Lookup Neste modelo, ilustrado na Figura 17, as tabelas de dimenses so normalizadas, resultando na eliminao de redundncias, o que torna a manuteno mais gil e o modelo mais consistente. Aqui, criamos uma tabela principal para uma determinada dimenso, que referencia tabelas de busca (lookup), estas contendo os nomes e descries de campos. Um cuidado extra com este modelo o nmero de tabelas em junes, o que pode degradar o desempenho.

Figura 17: parte do Modelo Snowflake Lookup, mostrando a normalizao da tabela Clientes do modelo da Figura 16 Observe no diagrama acima, que a tabela de fatos foi deslocada para a esquerda e nem todas as dimenses esto representadas, a fim de melhorar a visualizao do modelo. Note que a tabela de dimenso PrincipalClientes possui apenas os dados de cada cliente e chaves estrangeiras para outros elementos, sendo que a manuteno destes feita de modo mais consistente ao promover alteraes apenas nas tabelas de busca (lookup). Modelo Snowflake Chain Este modelo encadeia as tabelas de dimenses comeando com a tabela principal, que o ponto de entrada para a tabela fato. A tabela principal da dimenso contm a chave para o prximo nvel da hierarquia da dimenso e assim por diante. Na Figura 16, a normalizao da dimenso Produtos em diversos nveis um exemplo deste modelo. Note que a tabela de fatos possui indicao do nvel mais baixo na hierarquia, referenciando a dimenso Produtos, e ento as tabelas de dimenses Modelos e Fabricantes percorrem os nveis mais altos.

A recomendao de uso deste modelo ocorre quando o nvel de detalhe mais baixo est armazenado na tabela de fatos. A contra-indicao, por sua vez, para os casos em que a pesquisa requer vrios nveis de sumarizao da informao, j que so necessrios vrios passos para recuperar as informaes. A fim de melhorar o desempenho, uma sugesto desnormalizar a cadeia, inserindo as chaves de nveis mais altos nos nveis mais baixos. Modelo Snowflake Attribute Com o objetivo de reduzir o nmero de informaes referentes a atributos nas tabelas de fatos, geralmente utilizados para obteno de detalhes (drillthrough), inserimos todos eles em uma tabela de atributos, conforme ilustrado pelas figuras a seguir.

Figura 18: Modelo Snowflake, antes de separar os atributos

Figura 19: Modelo Snowflake Attribute Outra utilidade deste modelo a consolidao de informaes sobre diversas pequenas dimenses que possuam poucos campos (muitas vezes apenas a descrio) em uma nica tabela. Desse modo, o nmero de tabelas em junes pode ser reduzido, melhorando o desempenho. Inicio da pagina

Concluso
O desenvolvimento de sistemas analticos cada vez mais comum. Embora haja ferramentas de diversos fornecedores, de nada elas adiantam se a modelagem de dados e o paradigma analtico no forem compreendidos. Neste artigo procuramos percorrer assuntos pouco divulgados e com pouca bibliografia. Abordamos as estruturas de dados mais comumente encontradas em gerenciadores relacionais e analticos: as B-Trees e as rvores Bitmap. Ao conhecer um pouco da estrutura que suporta as tecnologias, esperamos que o leitor possa escolher melhor e entender as caractersticas de cada modelo de dados que desenvolver e suportar.

As opes de modelagem so vrias e aqui ilustramos algumas que podem ser utilizadas de modo isolado ou ainda combinadas, a fim de produzir modelos de dados multidimensionais que atendam a sua demanda. Inicio da pagina

Referncias

1. 2. 3. 4. 5. 6.

PATRICIA Practical Algorithm To Retrieve Information Coded In Alphanumeric. Morrison, Donald R. 4, 1968, JACM, Vol. 15, pp. 514-534. Knuth, Donald E. The Art of Computer Programming. s.l. : Addison-Wesley, 1998. Vol. 3. ISBN 0-201-89685-0. Inmon, W H. Building the Data Warehouse. s.l. : John Wiley & Sons, 1998. Ferreira, Joo Eduardo, Italiano, Isabel Cristina and Takai, Osvaldo Kotaro. Introduo a Banco de Dados. [Online] 2005. [Cited: 06 21, 2007.] http://www.ime.usp.br/~jef/apostila.pdf. Tanler, Richard. The Intranet Data Warehouse. s.l. : John Wiley & Sons, 1997. Kimball, Ralph. The Data Warehouse Toolkit. s.l. : John Wiley & Sons, 2000.