Modelagem dimensional na prática

 Em outro post, tentei desmistificar o conceito de Data warehouse. Voltando a ler o Post, senti falta de um exemplo prático que mostrasse as vantagens e desvantagens de modelar de forma dimensional uma base de dados para atender a um DW.  A ideia deste post é tentar apresentar uma resposta a estas questões.

Conforme mencionado no outro post, o DW visa resolver questões de performance na execução das consultas.  E como se resolve isso? A forma encontrada foi modelar a base de um jeitão meio diferente, o que ficou conhecido como Modelagem dimensional.

A Modelagem dimensional é uma técnica de design de banco de dados projetada para suportar consultas de usuários finais em um Data Warehouse.  

A ideia é que os usuários consigam fazer consultas sem necessitar da ajuda de profissionais especializados em SQL. 

Em modelos relacionais, é prezada a questão da normalização. Na modelagem dimensional, para melhorar o desempenho das consultas, há redundância planejada dos dados, compensando os gastos com armazenamento e atualização das informações, fazendo com o que a base de dados fique de certo modo desnormalizada.

O modelo dimensional é composto por tabelas fato e por tabelas conhecida como dimensões.

Na prática, a tabela fato armazena as chaves das dimensões e armazena também as métricas a serem analisadas por quem vier a consultar o DW.

Já as tabelas de dimensão são compostas basicamente de atributos que descrevem as entidades envolvidas no modelo. 

Modelando desta forma, o modelo fica parecido com uma "estrela"

Nesse modelo os dados são desnormalisados para evitar joins entre tabelas, diminuindo o tempo de consultas, no entanto devido a repetição de dados, utiliza mais espaço em disco. A vantagem desse modelo é a eficiência na extração de dados, o que é um grande diferencial em se tratando de um datawarehouse.

A chave da tabela fato é uma chave composta, uma vez que trata-se da junção das chaves das tabelas de dimensão.

Importante também é não misturar os fatos. Exemplo: A finalidade é analisar o volume de vendas? Devemos criar uma tabela fato específica para isso. Ao analisar o volume de compras, deve-se criar outra tabela fato com essa finalidade.

Quando a quantidade de atributos das dimensões é muito grande,  costuma-se normalizar as tabelas de dimensão. Neste caso, o modelo fica parecendo um floco de neve (Snow Flake ). Isto porque cada tabela de dimensão seria normalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes em seus atributos. 

A adoção de um modelo ou de outro de implementação trás vantagens e desvantagens em relação a performance das consultas e volume de armazenamento dos dados. Cabe aos analistas decidirem qual será a melhor abordagem.

Cheguei a conclusão de que a melhor maneira de entender a modelagem dimensão é através de exemplos. Abaixo coloquei alguns exemplos de modo a clarear o entendimento deste tipo de modelagem.

Exemplo de um modelo conceitual

Exemplo de modelo para análise de despesas

Exemplo de modelo para análise de produção

A dica aqui é procurar nos pais dos burros (Google) mais modelos de modo a fixar a ideia desse tipo de modelagem.

Como entrevistar os usuários de um DW? Segue um texto legal do Piton nesse link https://rafaelpiton.com.br/blog/data-warehouse-como-modelar/

E aí? O post deu uma clareada? Em caso afirmativo, fico satisfeito. Tem outras questões a serem respondidas. Como importar os dados da origem de dados que comporão as tabelas do DW? Como atualizar esses dados ao longo do tempo? Se os dados que vierem compor o DW provierem de fontes de dados distintos, com formatos diferentes, como unificar o padrão desses dados? A resposta a essas perguntas estará em outro post sobre ETL.

Valeu!!!