Dez Regras de Ouro para Modelagem Dimensional

Conheça as dez regras de ouro para modelagem dimensional, segundo Kimball!

Regra 1: Carregar detalhes atômicos nas estruturas dimensionais.

Modelos Dimensionais devem ser populados alicerçados em detalhes atômicos de forma a suportar filtros, consultas agrupadas, solicitadas pelas regras de negócio e consulta dos usuários. Tipicamente, os usuários não precisam ver uma única linha por vez, mas podemos prever, de certa forma, as maneiras arbitrárias como eles irão querer ver na tela e navegar por esses detalhes. Se somente dados sumarizados estiverem disponíveis, então fizemos suposições sobre os padrões de consulta dos usuários, que irão criar uma parede de tijolos quando esses usuários quiserem ir mais a fundo nas informações, nos detalhes. É claro que detalhes atômicos podem ser complementados por modelos dimensionais sumarizados, que irão melhorar a performance das consultas mais comuns, mas os usuários do negócio não podem viver apenas com dados sumarizados, precisam de detalhes para responder as questões do seu dia a dia.

Regra  2: Estruturar os DMs em volta dos Processos do Negócio.

Processos de Negócio são as atividades realizadas pela organização; representam as medidas dos eventos, como fazer um pedido ou faturamento para um cliente. Tipicamente, processos de negócio capturam ou geram medidas únicas, referentes à realização dos seus eventos. Essas métricas, transformadas em fatos, com cada processo de negócio, representa uma única tabela fato atômica. Em adição a uma única tabela fato do processo, tabelas fato consolidadas são, às vezes, criadas combinando métricas  de múltiplos processos  em uma tabela fato com um nível comum de detalhes. Mais uma vez, tabelas fatos consolidadas são complementos do detalhamento dos processos e não um substituto.

Regra  3: Todo Fato deve ter uma Dimensão de Tempo associada.

A medição dos eventos, descritos na regra anterior, sempre tem uma data ‘carimbada’ ou alguma variedade a eles associados, podendo ser o balance mensal, ou os valores capturados por minute, etc. Todo Fato deve ter, pelo menos, uma foreign Key de associação a uma Dimensão de Tempo (datas), cuja granularidade seja um único dia com os atributos do calendário  e características não padronizadas sobre a data da medida do evento, como, por exemplo, ano fiscal, feriados, etc. É comum termos várias datas associadas a um fato.

Regra  4: Um Fato deve  ter, sempre, a mesma granularidade.

Existem três categorias fundamentais de granularidade: Transacional, Período no Tempo ou Período Acumulado (transacional, periodic snapshot, or accumulating snapshot).  Indiferentemente do tipo da granularidade, cada medida em um Fato deve ter, exatamente, o mesmo nível de detalhe. Quando misturamos fatos (medidas), representando múltiplos níveis de granularidade em uma mesma tabela Fato, estaremos gerando uma confusão de informações sobre o negócio, gerando, com certeza, informações erradas e desacreditando o BI na empresa.

Regra 5: Relacionamento muitos-para-muitos é um Fato.

Como uma tabela Fato armazena os resultados dos eventos dos processos de negócio, existe um relacionamento muitos-para-muitos inerente a esse resultado, entre as foreign Keys, tais como múltiplos produtos sendo vendidos em múltiplas lojas em múltiplos dias. Essas foreign keys nunca devem ser nulas. Às vezes, dimensões podem ter múltiplos valores para uma única medida do evento, como múltiplos diagnósticos associados a um plano de saúde ou múltiplos clientes com contas no Banco. Nesses casos não é interessante resolver essa dimensão com muitos valores diretamente com a tabela fato, isso violaria a granularidade natural da medida do evento. Nesse caso, usamos uma tabela com chave dupla em conjunção com o Fato.

Regra 6: Resolver muitos-para-um na Dimensão.

Relacionamentos muitos-para-um entre atributos são tipicamente desnormalizados ou desmanchados em uma Dimensão. Caso tenhamos passado tempo demais desenhando modelos ER, deveremos resistir à tentação em normalizar gerando varias subdimensões menores, criando uma estrutura snowflake. Não esqueça, desnormalizar é o nome do jogo em Modelagem Dimensional.

Regra 7: Armazenar  ‘ report labels’ e  ‘filter domain’ na Dimensão.

Os códigos e, mais importante, decodes associados e descritores usados para nome de colunas em relatórios e filtrar consultas (queries) devem ser obtidos a partir da Dimensão. Evite armazenar campos codificados ou campos descritivos volumosos nas tabelas Fato; bem como não armazene o código em Dimensões, assumindo que os usuários não precisam de decodes descritivos ou que eles poderão ser manuseados na aplicação BI.  

Como observamos na regra 5 que as foreign keys nunca devem ser nulas, isso também deve ser considerado para os atributos das dimensões, evitando-se nulos, substituindo valores nulos por, por exemplo, NA (Não se Aplica) ou outro valor default qualquer, reduzindo possíveis confusões.

Regra 8: Usar Surrogate Key nas Dimensões.

O uso de Surrogate Key (SK) nas dimensões (com exceção da Dimensão Tempo, onde a data é muito mais representativa), nos trás muitos benefícios, incluindo chaves menores que significa Fatos menores, índices menores e melhora a performance. Surrogate keys são absolutamente necessárias se precisarmos acompanhar as mudanças de determinados atributos na Dimensão, ou seja, se precisarmos acompanhar históricos. Surrogate Keys também permitem mapear múltiplas chaves operacionais em um perfil comum.

Regra 9: Criar Conformed Dimensions.

Conformed dimensions são essenciais para um Data Warehouse corporativo. Gerenciadas apenas uma vez, nos processos de ETL, e reusadas em múltiplas tabelas Fato, as Dimensões Conformadas apresentam atributos descritivos consistentes entre modelos dimensionais, e suportam técnicas como Drill Across e integração de informações entre vários processos de negócio. O Conceito de Enterprise Data Warehouse Bus Matrix é a arquitetura chave, que representa o núcleo dos processos de negócio da empresa, dimensionalmente associados. O reuso de dimensões agiliza o processo de desenvolvimento e elimina redundâncias. Contudo, necessita comprometimento e governança na tutela dos dados para potencializar a conformidade.

Regra 10: Manter equilíbrio continuo entre  DW/BI e  Negócio .

Os arquitetos devem, constantemente, acompanhar os requerimentos dos usuários do negócio, com a realidade dos dados, para desenhar a implementação e entrega das informações de forma a ser o BI adotado pelo negócio. As requisições versus a realidade balanceada das informações, é a vida de um DW/BI. Manter sempre uma estratégia de técnicas para implementações e melhorias nas informações, com arquiteturas de ETL e disponibilização de dados, definindo planos de ação.

… Até a próxima!

Publicado em Diversos. 9 Comments »

9 Respostas to “Dez Regras de Ouro para Modelagem Dimensional”

  1. Mauro Canoas Says:

    Carlos, achei excelente este artigo.
    Gostaria de uma ajuda em relação ao item que trata o uso de surrogate key. Sou AD e defendo esta pratica sempre que possivel, acontece que certos DBAs são contra e afirmam que o processo de carga fica muito prejudicado, não compensando o uso.
    Você teria algo mais detalhado sobre o assunto para que eu pudesse argumentar junto aos DBAs?
    Desde já obrigado

    Mauro Canoas

  2. Efrain Says:

    Sr. Carlos Alberto, bom dia.

    Estou há apenas 2 meses na área de BI, o senhor teria alguma dica para que eu possa ter um bom começo nesta carreira promissora? Pergunta de iniciante mesmo.

  3. Efrain Says:

    complementando a mensagem acima: participei da análise de um projeto, criei o DW e o STG, fiz a parte de ETL, e agora desenvolvendo relatório em web intelligence e tentando aprender Crystal Reports. Mas tudo com ajuda dos amigos do setor e muito suor.

    • Carlos Alberto Lorenzi Lima Says:

      Efrain, bom dia!!!

      Por favor, nada de senhor!!! É Lito mesmo ou ‘você’….

      Meu velho, antes de falar sobre qualquer dica, peço a sua permissão para falar sobre um e-Book de Conceitos sobre DW e BI, que eu fiz, e está a venda no site http://www.litomart.com. Se você puder, compra esse e-Book, não é caro (sou obrigado a cobrar pra poder manter uma estrutura de Serviços Digitais que estou implementando – Veja no vídeo de apresentação no mesmo site) e dará uma noção completa sobre BI e DW. Você tendo essa visão completa, poderá entender melhor a minha primeira dica: Gostou do assunto? Pretende seguir nessa área? É muito importante que essa área seja do seu agrado!!! Envolve não apenas tecnologia, mas conhecimento de negócios. Segunda dica: Estude o assunto! Procure um curso sobre DW / BI, Modelagem Dimensional, ETL, etc. Eu pretendo, no segundo semestre, disponibilizar cursos, palestras e e-Books técnicos sobre o assunto, exatamente para ajudar aqueles que tem as mesmas duvidas que você, mas, mesmo com esse tipo de ensino (os chamados recursos digitais – cursos pela internet ao vivo ou gravados (Webinars)), que serão bem acessíveis em termos financeiros, recomendo também, cursos presenciais, na CETAX, por exemplo. Cursos presenciais requerem investimentos um pouco maiores, porém irá ajudar, e muito, a consolidar os ensinamentos ‘virtuais’. Terceira dica: Defina qual será a sua expertise nessa área! Pretende ser um Arquiteto? Um desenvolvedor (mexer com ferramentas de BI)? Qual desses segmentos o agrada mais… Quarta dica: Se preocupe com ferramentas de DW e BI só depois que definir o seu caminho. Essas ferramentas, usualmente, tem duas ‘divisões’: a administrativa, que envolve um pouco mais de arquitetura, e a de desenvolvimento, que envolve um pouco mais de conhecimentos técnicos. Depois que você pensar em tudo isso e definir o seu caminho, se dedique e tenha garra, não desista!!! No começo é difícil… o Blog está aqui como um canal de comunicação. Use-o, para tirar duvidas, falar sobre sua evolução na área, etc…

      Abração!!!!

  4. Efrain Says:

    Boa tarde Lito,

    Fico meio assustado, pois tenho 46 anos, há 2 anos e meio trabalhava como garçom, a entre vários atendimentos atendi a um Sr. e seu filho que falavam sobre banco de dados, eu sempre gostei de banco, mas sempre lí por conta(comprava os livros) baixava os bancos de dados na versão express e estudava, quando ouvi eles falando sobre banco de dados perguntei se eles trabalhavam com TI e o sr. me disse que tinha uma empresa, pedi uma oportunidade ele pediu que entrasse no site e cadastrasse meu CV, cadastrei, fiz as provas, entrevistas e hoje estou aqui há 2 anos e meio, comecei a trabalhar na central de atendimento e pleteei uma vaga na área de BI sem nenhum conhecimento, por isto, o pedido desesperado de uma orientação. Mas vou crescer de Deus quiser e no que depender de mim.

    • Carlos Alberto Lorenzi Lima Says:

      Efrain, eu sei o que é ficar assustado… Eu tenho 57 anos, e sou um consultor… estou sempre pensando: ‘Será que já me acham velho no mercado? Será que as consultorias irão me oferecer novas oportunidades de projeto?’…….. Mas evito ficar pensando nisso, senão me apavoro e não vivo mais… Você, graças a Deus, já esta empregado, agora é pensar em evoluir no seu emprego, independente da idade. Se quer mesmo entrar nessa área de BI, vá em frente, mas não esqueça o que eu disse, conheça bem a área primeiro, pra saber se essa área realmente te encanta!!! Entenda o que quer dizer DW e BI, quais os conhecimentos que você deverá aprimorar para ser bem sucedido nesse segmento (Banco de Dados, Modelagem Relacional, Modelagem Dimensional, etc.).
      Boa sorte, meu velho!!!
      Abração!!!

  5. Efrain Says:

    Obrigado Lito,

    Mas lembre-se, qualquer coisa estarei aqui para lhe incomodar.

    Grande abraço.


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: