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 várias 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 contínuo 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.
QUESTÃO ERRADA: Em um data warehouse, cada linha em uma tabela fato corresponde a uma medida, representada por um valor aditivo, em que necessariamente essas medidas não compartilham a mesma granularidade.
O erro da questão é que as tabelas FATO devem possuir medidas com a MESMA granularidade. Essa é, segundo Kimball, a quarta regra, dentre as 10 regras de ouro para a Modelagem Dimensional:
QUESTÃO ERRADA: O modelo de Kimball é baseado em modelos de Entidade-Relacionamento, onde a normalização dos dados evita dados duplicados no data warehouse.
O erro da afirmação é mencionar NORMALIZAÇÃO, já que Kimball preconiza modelo estrela, ou seja, desnormalizada.
CEBRASPE (2022):
QUESTÃO CERTA: A característica principal da modelagem dimensional é a simplicidade e o seu foco é o cruzamento de variáveis.
A construção de um modelo dimensional bem desenhado deve ter como princípio a simplicidade, afinal modelos muito complexos tentem a ser problemáticos a longo prazo, tornando-se “pesados” e de difícil manutenção, então aqui podemos aplicar uma regra básica, “se está muito complexo, está errado”, ou seja, modelagens muito complexas precisam ser reavaliadas e simplificadas.