Modelo Dimensional para Data Warehouse

PorEduardo Moreira em

O modelo dimensional para construção de banco de dados para Data Warehouse é uma forma de modelagem onde as informações se relacionam de forma que pode ser representada como um cubo. Sendo assim podemos fatiar este cubo e aprofundar em cada dimensão ou eixo para extrair mais detalhes sobre os processos internos que ocorrem na empresa que em um modelo relacional torna-se muito complicados de serem extraídos e muitas vezes até impossíveis de serem analisadas.

O modelo dimensional permite visualizar dados abstratos de forma simples e relacionar informações de diferentes setores da empresa de forma muito eficaz.

O que torna o Data Warehouse mais poderoso é que informações que se situam em vários sistemas, planilhas e arquivos espalhados por todos os setores da empresa, são reunidos em um banco de dados de forma dimensional, sendo assim tendo informações unificadas e padronizadas em um mesmo local.

Vejamos o caso de uma empresa que possui várias lojas filiais e que deseja acompanhar o desempenho de suas vendas ao longo do tempo. Um desenhista de Data Warehouse visualiza estas informações de uma forma como um cubo que pode ser descrito com três dimensões principais que são:

Tempo
Loja
Produto

Na intersecção destas três dimensões está a quantidade de produtos que foi vendido.

Neste modelo cada cubo menor, ou seja, a intersecção entre as dimensões ou eixos representa uma quantidade de um produto que foi vendido em uma determinada loja em uma data especifica.

Mas se quisermos saber e controlar também se os produtos que foram vendidos participavam de uma promoção teríamos que ter mais uma dimensão chamada PROMOÇÃO, e se quisermos controlar em cada momento as equipes de marketing que atuaram em cima das promoções e das lojas devemos ter mais outra dimensão, e se quisermos controlar os clientes que compraram os produtos teríamos que ter uma dimensão Clientes, sendo assim teríamos um modelo com seis dimensões. Tantas dimensões não é possíveis desenhar graficamente, mas seguem o mesmo conceito de cubo, pois é possível navegar, aprofundar-se, detalhar e acompanhar os desempenhos destas dimensões ao longo do tempo. Um modelo dimensional pode ter quantas dimensões forem necessária.

Um modelo de dados dimensional é extremamente simples, isto facilita para os usuários deste banco de dados identificarem onde estão localizadas as informações e permite que os softwares que naveguem por estes bancos de dados com eficiência. Um outro fator importante para a modelagem dimensional é a velocidade de acesso a uma informação, com modelos simples sem muitas tabelas para relacionar, é muito rápido para extrair as informações necessárias.

Um modelo dimensional conta basicamente com uma tabela de fatos central e tabelas dimensionais ligadas diretamente a elas.

Os Fatos e Dimensões são tabelas do banco de dados, só que no modelo dimensional adquirem nomes de Fatos e Dimensões de acordo com a função da tabela.

Uma tabela de Fatos, em nosso exemplo “Fatos Vendas” contém medições sobre o negócio como a quantidade de produtos que foi vendido, contém o valor da venda e o valor unitário do produto vendido. Além destas informações de fatos, esta tabela contém chaves para as tabelas de dimensões. Uma tabela de fatos é extremamente grande referente à quantidade de registros que contém, neste exemplo ela armazena todas as vendas de cada produto feitas em cada loja todos os dias. É comum uma tabela de fatos alcançar alguns Gibabytes logo nos primeiros meses de uso do Data Warehouse.

As tabelas de Dimensões contém descrições textuais sobre cada um elementos que fazem parte do processo, no exemplo que citamos temos três dimensões (Tempo, Loja e Produto) as tabelas dimensionais contém vários atributos que descrevem em detalhes todas as características que possam definir e serem úteis para futuras pesquisas no Data Warehouse.

A dimensão Produto deve ter descrições curtas e detalhadas sobre o produto, deve também ter o tamanho, peso, categoria, cor, departamento, marca, tipo da embalagem, etc. Ou seja todos os atributos que podem definir o produto e que possam ser utilizados para futuras pesquisas e analises que ajudarão o empresário a tomar decisões sobre seu negócio.

A dimensão Loja deve conter informações sobre as lojas que fazem parte do complexo do negócio, dentre estas informações deve ter descrições como endereço, CEP, região, cidade, bairro, telefone, gerente, etc.

A dimensão Tempo deve ter detalhes sobre o calendário para que facilite pesquisas estratégicas, então a dimensão tempo não deve ter somente a data em que o produto foi vendido, mas deve conter informações como dia no mês, dia na semana, número do dia na semana, mês, número do mês no ano, ano, número da semana no ano, número de semanas corridas, número de meses corridos trimestre, período fiscal, indicador de feriado, indicador de fim de semana, indicador de último dia do mês, etc.

Tipos de Modelos Dimensionais

– O Modelo Estrela (Star Schema)

No modelo estrela todas as tabelas relacionam-se diretamente com a tabela de fatos, sendo assim as tabelas dimensionais devem conter todas as descrições que são necessária para defini uma classe como Produto, Tempo ou Loja nela mesma, ou seja, as tabelas de dimensões não são normalizadas no modelo estrela, então campos como Categoria, Departamento, Marca contém suas descrições repetidas em cada registro, assim aumentando o tamanho das tabelas de dimensão por repetirem estas descrições de forma textual em todos os registros.

Este modelo é chamado de estrela porque a tabela de fatos fica ao centro cercada das tabelas dimensionais assemelhado a uma estrela. Mas o ponto forte a fixar é que as dimensões não são normalizadas.

– O Modelo Floco de Neve (Snow Flake)

No modelo Floco as tabelas dimensionais relacionam-se com a tabela de fatos, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para fins de normalização das tabelas dimensionais, visando diminuir o espaço ocupado por estas tabelas, então informações como Categoria, Departamento e Marca tornaram-se tabelas de dimensões auxiliares.

No modelo Floco existem tabelas de dimensões auxiliares que normalizam as tabelas de dimensões principais. Na figura anterior estas tabelas são (Ano, Mês e Dia) que normalizam a Dimensão Tempo, (Categoria, Departamento e Marca) que normalizam a Dimensão Produto e a tabela Meio que normaliza a Dimensão Promoção.

Construindo a base de dados desta forma, passamos a utilizar mais tabelas para representar as mesmas dimensões, mas ocupando um espaço em disco menor do que o modelo estrela. Este modelo chama-se floco de neve, pois cada dimensão se divide em vaias outras tabelas, onde organizadas de certa forma lembra um floco de neve.

– Considerações sobre ambos modelos

O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos dados dimensionais mas acrescenta várias tabelas ao modelo, deixando-o mais complexo, tornando mais difícil a navegação pelos softwares que utilizarão o banco de dados. Um outro fator é que mais tabelas serão utilizadas para executar uma consulta, então mais JOINS de instrução SQL serão feitos, tornando o acesso aos dados mais lento do que no modelo estrela.

O Modelo Estrela (Star Schema) é mais simples e mais fácil de navegação pelos softwares, porém desperdiça espaço repetindo as mesmas descrições ao longo de toda a tabela, porém análises feitas mostram que o ganho de espaço normalizando este esquema resulta em um ganho menor que 1% do espaço total no banco de dados, sendo assim existem outros fatores mais importantes para serem avaliados para redução do espaço em disco como a adição de agregados e alteração na granularidade dos dados, estes temas serão abordados em colunas posteriormente.

Portanto o que recomendo é utilizar um modelo estrela pois fornece um acesso mas rápido aos dados e mais fácil de se navegar, criando tabelas auxiliares para dimensões somente para dimensões especificas quando for estritamente necessário ou quando demonstrar um beneficio que justifique a perda de desempenho nas consultas, que também não é tão grande dependendo da forma que estas tabelas são construídas e a quantidade de registros que elas contiverem.

Deixe um comentário! 42

42 comentários

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Parabéns pela forma objetiva e clara de escrever sobre o assunto. Tinha lido textos muito maiores que esses para entender, mas nenhum com a clareza utilizada aqui.

  2. Tenho uma dúvida em relação ao modelo flocos de neves. Se no meu schema eu possuo uma tabela com relacionamento de muito para muito, como ele deverá ser implementado?

  3. Muito bom texto, linguagem simples e precisa…. isso prova que um bom texto nesse assunto não precisa ser atual, pois esse já tem 6 anos.. parabens!

  4. Eduardo, você tem uma excelente didática! Você não complica, apenas explica. O que não acontece com a maioria dos posts que vejo na internet. Parabéns!!!

  5. Num modelo starschema, na tentativa de tentar colocar numa fato o grão de diversos assuntos diferentes, o que você sugere para atributos DATA onde existem diversas datas diferentes. Exemplo: colocando no fato, para cada cliente uma quantidade = 1 (cada registro corresponderá a 1 cliente), mas tenho a data de inicio desse cliente e a data da ultima compra. Coloca-se as duas datas na fato?

  6. Boa didática é uma característica que merece ser elogiada. Esclarecer aquilo que normalmente causa dúvida para a maioria das pessoas, de forma clara e fácil, é um dom pra poucos. Fica aqui um elogio sincero!

leia mais
Este projeto é mantido e patrocinado pelas empresas: