Modelagem Multidimensional
Finalizando a sessão nostalgia, esse artigo publicado originalmente em 2012, veio na sequência do artigo Visão geral de um Data Warehouse e seus componentes.
E mesmo tendo se passado mais de 10 anos, muito conteúdo continua relevante por abordar, principalmente, conceitos e fundamentos.
Se quiser saber o que estou estudando, experimentando ou escrevendo, visite o meu Diário de Bordo e veja as novidades.
Cubo de Dados
Um DW tem como principal objetivo servir de repositório para a análise de grandes massas de dados através de consultas OLAP , neste cenário observa-se dados centrais (os fatos ou métricas) que serão consultados sob diversas perspectivas (as dimensões ou parâmetros) criando a abstração do cubo de dados, conforme figura abaixo:
Modelo Estrela || Floco de Neve
Conceitualmente, uma base de dados multidimensional é representada pelo cubo de dados; mas partindo para o modelo lógico e físico, a forma mais simples de representar uma base de dados multidimensional é a figura abaixo:
Essencialmente teremos no centro do modelo a “tabela fato” contendo de 0 (zero) a n (várias) métricas, e nas bordas teremos pelo menos 1 (uma) “tabela dimensão”, podendo ter quantas mais forem necessárias.
Durante o processo de modelagem da base de dados multidimensional, os itens abaixo devem ser analisados cuidadosamente:
- Escopo;
- Granularidade;
- Dimensões e;
- Métricas.
Escopo
A experiência e o conhecimento do analista de SAD ou analista de BI (como são conhecidos atualmente) sobre o negócio é fundamental para a correta definição do escopo de um projeto de DW.
É imprescindível ter uma visão do que é importante para o negócio, ou melhor, saber qual informação será necessária extrair dos dados armazenados no DW, para que a organização obtenha algum conhecimento novo e a partir deste ponto os gestores possam tomar as decisões mais acertadas.
Vale lembrar que cada projeto é único e portanto deve ser analisado individualmente, e que muitas variáveis influenciam as decisões, por exemplo: tempo para implantação, custo, capital humano e recursos tecnológicos disponíveis, etc.
Esses dentre outros fatores influenciarão na escolha de um dos dois paradigmas que envolvem os projetos de DW, que são as propostas de Inmon e Kimball .
Inmon propõe que o projeto do DW deve partir do DW corporativo para depois desmembrar nos DM departamentais com isto ganha-se na consistência dos dados armazenados mas o tempo para a obtenção de resultados práticos aumenta.
Em contrapartida, Kimball propõe o caminho inverso: partir de DM departamentais para o DW corporativo, buscando observar a consistência das informações. Neste processo, os resultados aparecem mais rapidamente, porém o risco de inconsistência aumenta.
O bom senso entre as pessoas envolvidas sempre deve ser levado em conta no momento da decisão do projeto, para se buscar um equilíbrio entre o melhor dos dois mundos.
Granularidade
Durante o desenho da solução, o analista de SAD define quais métricas serão armazenadas nas tabelas fatos e quais parâmetros serão armazenados nas tabelas dimensões. Observe a figura abaixo.
A definição correta da granularidade de uma tabela fato implica no desempenho das consultas OLAP , tomando como base o modelo proposto. Imagine os seguintes cenários:
- Poucas lojas e pouca abrangência (poucos CEP´s);
- Muitas lojas e pouca abrangência (poucos CEP´s);
- Poucas lojas e abrangência nacional;
- Muitas lojas e abrangência nacional.
É de se concordar que o volume de dados armazenados na tabela fato na última situação poderá chegar a bilhões de registros, podendo impactar no desempenho das consultas que não necessitem de um detalhamento maior.
Nestes casos uma alternativa é quebrar a tabela fato em domínios menores, onde além de uma tabela com o nível máximo de detalhes, existiriam outras tabelas sumarizadas por cidade ou estado, por exemplo.
No geral, para granularidades distintas teremos tabelas fatos distintas.
Dimensões
Vamos falar um pouco sobre a tabela “dimensão”, um item importante na modelagem multidimensional e que tem algumas características próprias que devemos observar:
- Projete a tabela dimensão na perspectivas do usuário. Utilize textos descritivos e códigos que sejam de fácil entendimento do usuário final, não tente economizar alguns bytes neste quesito;
- Evite utilizar técnicas de normalização dos dados. Esta técnica aumenta a complexidade das consultas, impactando no desempenho, além de não compensar a economia de espaço obtida;
- Utilize uma chave primária genérica e simples. Este procedimento evita problemas de atualização que surgem aos utilizar, por exemplo, o próprio código do cliente ou produto como chave primária, além de proporcionar um melhor desempenho na utilização dos índices;
- Utilize múltiplas colunas de atributos. Com isto ficará mais fácil identificar a chave em questão.
Abaixo alguns exemplos de atributos que podem ser utilizados para ajudar a detalhar uma chave, facilitando na definição dos parâmetros da consulta OLAP.
- Atributos estruturais para relacionamentos pai-filho.
- Atributos para definição de nível
- Atributos tipo “flag” de resolução e/ou de seqüência
Métricas
Agora vamos aos “fatos”, às “métricas”, ao centro das atenções, pois são as tabelas fatos que irão guardar no data warehouse a respota para todas as questões.
É na tabela fato que o analista de SAD armazenará as métricas do negócio, possibilitando recuperar dados quantitativos e responder, por exemplo, quanto foi vendido de um determinado produto? em determinada época? em determinado local? dentre outras questões.
Os fatos ou métricas armazenadas podem ser de três tipos:
- Aditivas: São as métricas que podem ser sumarizadas, adicionando seus valores ao longo do tempo. Por exemplo: o valor, o custo e/ou a quantidade de um pedido podem ser somados independente das combinações dos parâmetros das dimensões;
- Não-aditivas: É o inverso das aditivas. Por exemplo: valores percentuais no geral não são somados, e como normalmente são derivadas de outras métricas aditivas, fica mais prático calcular em tempo de execução do que armazenar estas métricas.
- Semi-aditiva: Estas métricas podem ser sumarizadas apenas em algumas dimensões, como exemplo temos o saldo de uma conta corrente, que pode ser sumarizada na dimensão cliente, já na dimensão agência não faz sentido somar o saldo da conta ao longo do tempo.
Ampliando esta questão dos tipos de métricas, temos o exemplo da temperatura (métrica não-aditiva) e do saldo da conta (métrica semi-aditiva) que não faz sentido somar, mas podemos utilizar outras operações como média, máximo e mínimo.
Normalmente, na tabela fato a chave primária (PK) é composta, sendo que cada elemento é uma chave estrangeira (FK) vinculada à uma tabela dimensão, sendo que a dimensão tempo sempre faz parte deste conjunto.
Em alguns casos podemos ter uma tabela sem fato, onde apenas a relação entre as dimensões já é o suficiente para a área de negócios, conforme o exemplo:
Conclusão!
Espero que este artigo tenha lhe ajudado a entender um pouco mais sobre modelagem multidimensional.
Gostou do conteúdo? bata palmas e compartilhe nas suas redes sociais.
Sentiu falta de algo? quer conversar a respeito? tem alguma dúvida, crítica ou sugestão? deixe seu comentário.
Obrigado pela atenção, até o próximo! Fui!
Se quiser saber o que estou estudando, experimentando ou escrevendo, visite o meu Diário de Bordo e veja as novidades.
