Modelagem de bancos de dados multidimensionais

Bancos de dados multidimensionais

A finalidade de bases de dados multidimensionais (alguns autores chamam de dimensionais) é fornecer subsídio para realização de análises. Para tanto, sua arquitetura e até mesmo a terminologia empregada são distintas das utilizadas para bancos de dados transacionais.

O fato de existirem diversas informações a serem cruzadas (dimensões) permite a realização de pesquisas tais como a ilustrada na Figura 1:

Figura 1: exemplo de pesquisa multidimensional

Terminologia

As análises sobre dados históricos envolvem uma série de possibilidades de cruzamentos e agrupamentos de informações, com o uso dos seguintes termos:
     - Dimensões: estabelecem a organização dos dados, determinando possíveis consultas/cruzamentos. Por exemplo: região, tempo, canal de venda,... Cada dimensão pode ainda ter seus elementos, chamados membros, organizados em diferentes níveis hierárquicos. A dimensão tempo, por exemplo, pode possuir duas hierarquias: calendário gregoriano (com os níveis ano, mês e dia) e calendário fiscal (com os níveis ano, semana e dia);
     - Medidas: são os valores a serem analisados, como médias, totais e quantidades;
     - Fatos: são os dados a serem agrupados, contendo os valores de cada medida para cada combinação das dimensões existentes. O tamanho da tabela que contém os fatos merece atenção especial do analista;
     - Agregações: totalizações calculadas nos diversos níveis hierárquicos.

A criação de DMs implica na geração de agregações. Este processamento se reflete em ganho de desempenho quando da realização de consultas.

Alicerce relacional

Diversas ferramentas analíticas, também chamadas ferramentas de OLAP, operam sobre bases de dados multidimensionais armazenadas em SGBDRs. Além disso, as agregações são também 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, basta processar as agregações. Com isso obtém-se ganho de espaço de armazenamento, uma vez que os dados permanecem apenas na base de origem (multidimensional), embora a criação de grandes quantidades de agregações possa incorrer em explosão de dados.

Alicerce em cubos

Outra forma de armazenamento, cujo modelo matemático denomina-se hipercubos, apresenta a característica de possuir armazenamento e indexação em estruturas de dados que otimizam consultas ao invés de atualizações, como é o caso das árvores PATRICIA.

Esta forma é erroneamente chamada MOLAP, ou Multidimensional OLAP. O erro está no fato de que bases ROLAP também são multidimensionais.

Quando o modelo multidimensional é processado, nova base é gerada, desta vez contendo tanto os dados quanto as agregações em formato próprio, utilizando-se de estruturas apropriadas para pesquisas.

A Figura 2 ilustra uma representação de um cubo com três dimensões:

Figura 2: representação de um cubo com as dimensões Produto, Região e Tempo

Embora o risco de explosão de dados seja comum em estruturas relacionais por conta de cruzamentos sem dados, mas que ocupam algum espaço, as estruturas utilizadas pelos cubos são esparsas, e se aplicam a dados e agregações, de modo que os cubos são substancialmente menores do que a base multidimensional que o originou.

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 técnicas de normalização seguidas por graus de desnormalização a fim de obter o desempenho desejado ao reduzir o número de tabelas em junções (joins).

Vale lembrar que o número de planos de execução para uma junção de n tabelas é n!, isto é, para uma junção de 10 tabelas há 3.628.800 possibilidades. Embora o escalonador do SGBD possua estratégias para reduzir este número, é um ponto de atenção a considerar. Já para o caso dos MDDBs, o grau de desnormalização é bem maior, dado o volume de dados e a agilidade na consolidação de valores quando calculando as agregações.

Nesta seção, percorremos alguns conceitos importantes para a modelagem quanto à representação de fatos, dimensões e quanto a chaves. Então descrevemos vários modelos de dados, sempre do ponto de vista lógico. Portanto, os modelos que veremos serão sempre relacionais, independentemente do alicerce, relacional ou em cubos, que pode ser utilizado para o modelo físico.

Alguns conceitos

Quando o modelo de dados começa a ser definido, elementos básicos de representação precisam ter sido estabelecidos, de modo a criar-se um padrão de modelagem. Em nosso modelo teremos as dimensões e fatos representados em tabelas, podendo haver múltiplas dimensões e múltiplas 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 primária é composta, sendo um elemento da chave para cada dimensão;
     - Cada elemento chave para a dimensão deve ser representado e descrito na “tabela dimensão” correspondente (para efetuar a junção);
     - A dimensão tempo é sempre representada como parte da chave primária.

Dimensões

Deve haver uma “tabela dimensão” para cada dimensão do modelo, contendo:
     - Uma chave artificial (ou gerada) genérica;
     - Uma coluna de descrição genérica para a dimensão;
     - Colunas que permitam efetuar os filtros;
     - Um indicador NÍVEL que indica o nível da hierarquia a que se refere a linha da tabela.

A Figura 3 ilustra uma tabela para a dimensão “Geografia”, com os pontos acima representados. Note que a coluna “nível” determina a hierarquia (Região/Estado/Cidade).

Figura 3: exemplo de uma tabela de dimensão

Valores nulos irão existir em algumas colunas, dependendo do nível hierárquico para o qual a linha contenha valores. Esse é o caso da coluna “loja”: como somente existem lojas nas cidades, e não nos estados ou regiões, a tabela fica com nulos, conforme identificados pela região circundada na figura. Todavia, é tarefa do modelo físico reduzir o espaço ocupado pelos nulos.

A dimensão Tempo

Esta é uma dimensão que praticamente todos os sistemas analíticos possuem, dada a característica de realização de análises em dados históricos. Deveria conter:
     - Uma coluna chave para a junção com a(s) tabela(s) de fato(s);
     - Uma descrição genérica para cada período;
     - Colunas que permitam efetuar os filtros;
     - Coluna sinalizadora da presença de fatos para o período de tempo indicado na linha;
     - Coluna RESOLUÇÃO usada para restringir o período ao nível apropriado - opera de forma idêntica à coluna NÍVEL das outras dimensões;
     - Coluna SEQUÊNCIA que contém um número sequencial de 1 a n em cada nível do período de tempo e identifica a ordem relativa de cada data. Permite:

          - Construções com cálculos de tempo, como “últimos quatro dias”, por exemplo.

A Figura 4 mostra um exemplo de tabela de dimensão tempo. Note que a descrição é o que aparecerá para os valores de uma determinada data ou período.

Figura 4: exemplo de uma tabela para a dimensão tempo

Considerações sobre chaves

No tocante às chaves, sistemas analíticos devem contar com chaves artificiais, por uma série de motivos:
     - Qualquer atualização de dados fica simplificada. Por exemplo, um recadastramento de CPFs, embora improvável, poderia resultar em atualização de grande volume para uma tabela de fatos de transações bancárias, 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 execução de junções. 

Estrela e suas variações

Uma das formas de apresentação de um banco de dados multidimensional é através do Modelo Estrela. No centro da estrela encontra-se a tabela de fatos e, ao seu redor, as dimensões. Este modelo é apresentado na Figura 5:

Figura 5: Modelo Estrela

É um modelo simples e eficiente, caracterizado por possuir uma única tabela de fatos e chaves simples nas tabelas de dimensões. Cada dimensão é representada por uma única tabela.

Os pontos positivos deste modelo são a eficiência, dada pelo reduzido número de junções nas pesquisas e pelas chaves simples, e a facilidade de definir hierarquias.

Os pontos negativos são o tamanho e a desnormalização das tabelas de dimensões.

Modelo Estrela Parcial

É uma variação do Modelo Estrela, na qual existem várias tabelas fato e de dimensão separadas lógica e fisicamente por níveis de sumarização.

Desse modo, os dados são particionados em granularidades distintas. Por haver várias tabelas fato, na prática existem várias estrelas, cada uma representando uma combinação de níveis de agregação em cada dimensão. A Figura 6 apresenta uma parte do modelo que ilustra esta variação.

Figura 6: exemplo de duas estrelas no Modelo Estrela Parcial

Quando houver necessidade de novas agregações, basta criar outras tabelas com as granularidades desejadas, como ilustrado na Figura 7.

Figura 7: Modelo Estrela Parcial para composições de agregações

Os pontos positivos deste modelo são a maior economia de espaço, eliminando redundâncias e colunas que não têm sentido para determinado nível de agregação e o melhor desempenho para consultas de nível específico de agregação.

Por outro lado, a complexidade do modelo é maior e as consultas que combinam níveis de agregação distintos são mais elaboradas, podendo resultar em queda de desempenho.

Modelo Estrela com Particionamento de Fatos (ou Modelo Constelação de Fatos)

É uma variação do Modelo Estrela Parcial, na qual os fatos são particionados e as dimensões compartilhadas, conforme ilustrado na Figura 8.

Figura 8: Modelo Particionamento de Fatos

Quando comparado ao Modelo Estrela Parcial, este modelo é menos exigente quanto à sua manutenção, dado o compartilhamento das tabelas de dimensão.

Modelo Estrela com Particionamento de Dimensões

Assim como o anterior, é uma variação do Modelo Estrela Parcial, porém com as dimensões particionadas, compartilhando a tabela de fatos. A Figura 9 apresenta este modelo. Note que a tabela de fatos deve conter os seus dados na maior granularidade que o modelo previr e também consolidados de acordo com os níveis mais altos.

Figura 9: Modelo Particionamento de Dimensões, para local e tempo. Note a granularidade da tabela de fatos.

Este modelo é particularmente útil quando houver dimensões com grande quantidade de elementos, como é o caso de SKUs de produtos, por exemplo.

Snowflake e suas variações

Os modelos Snowflake acrescentam graus de normalização às tabelas de dimensões do Modelo Estrela, eliminando redundâncias e a necessidade do indicador NÍVEL. A Figura 10 mostra o resultado da normalização das tabelas “Produtos” e “Lojas” apresentadas na Figura 5. Observe a redução nas redundâncias, o que resulta em agilidade na manutenção. Apesar disso, é um modelo que resulta em maior número de tabelas em junções, podendo haver queda de desempenho.

Figura 10: Modelo Snowflake, após normalização do Modelo Estrela da Figura 5

A seguir veremos três variações do Modelo Snowflake.

Modelo Snowflake Lookup

Neste modelo, ilustrado na Figura 11, as tabelas de dimensões são normalizadas, resultando na eliminação de redundâncias, o que torna a manutenção mais ágil e o modelo mais consistente.

Aqui, criamos uma tabela principal para uma determinada dimensão, que referencia tabelas de busca (lookup), estas contendo os nomes e descrições de campos.

Um cuidado extra com este modelo é o número de tabelas em junções, o que pode degradar o desempenho.

Figura 11: Parte do Modelo Snowflake Lookup, mostrando a normalização da tabela Clientes do modelo da Figura 10

Observe no diagrama acima, que a tabela de fatos foi deslocada para a esquerda e nem todas as dimensões estão representadas, a fim de melhorar a visualização do modelo. Note que a tabela de dimensão “PrincipalClientes” possui apenas os dados de cada cliente e chaves estrangeiras para outros elementos, sendo que a manutenção destes é feita de modo mais consistente ao promover alterações apenas nas tabelas de busca (lookup).

Modelo Snowflake Chain

Este modelo encadeia as tabelas de dimensões começando com a tabela principal, que é o ponto de entrada para a tabela fato. A tabela principal da dimensão contém a chave para o próximo nível da hierarquia da dimensão e assim por diante. Na Figura 10, a normalização da dimensão “Produtos” em diversos níveis é um exemplo deste modelo. Note que a tabela de fatos possui indicação do nível mais baixo na hierarquia, referenciando a dimensão “Produtos”, e então as tabelas de dimensões “Modelos” e “Fabricantes” percorrem os níveis mais altos.

A recomendação de uso deste modelo ocorre quando o nível de detalhe mais baixo está armazenado na tabela de fatos. A contra-indicação, por sua vez, é para os casos em que a pesquisa requer vários níveis de sumarização da informação, já que são necessários vários passos para recuperar as informações. A fim de melhorar o desempenho, uma sugestão é desnormalizar a cadeia, inserindo as chaves de níveis mais altos nos níveis mais baixos.

Modelo Snowflake Attribute

Com o objetivo de reduzir o número de informações referentes a atributos nas tabelas de fatos, geralmente utilizados para obtenção de detalhes (drillthrough), inserimos todos eles em uma tabela de atributos, conforme ilustrado pelas figuras a seguir.

Figura 11: Modelo Snowflake, antes de separar os atributos

Figura 12: Modelo Snowflake Attribute

Outra utilidade deste modelo é a consolidação de informações sobre diversas pequenas dimensões que possuam poucos campos (muitas vezes apenas a descrição) em uma única tabela. Desse modo, o número de tabelas em junções pode ser reduzido, melhorando o desempenho.

Conclusão

As opções de modelagem são várias 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.

Ligue a vontade para qualquer celular ou fixo em todo o Brasil, EUA e Canadá, através do 99TelexFREE. Teste nosso serviço por 1 hora gratuitamente: http://www.telexfree.com/ad/marcelmesmo