Fundamentos do esquema estrela: fatos, dimensões e a declaração da granularidade

O que é

A modelagem dimensional divide os dados em medições de eventos de negócio e no contexto descritivo desses eventos: quem, o quê, onde, quando, por quê e como. Em um banco de dados relacional, isso resulta em um esquema estrela: tabelas de fatos no centro, cada uma ligada por chaves estrangeiras às tabelas de dimensão ao seu redor. A orientação do Power BI (citada) descreve isso de forma operacional: uma tabela de fatos contém colunas de chave de dimensão, que a relacionam com as tabelas de dimensão, e colunas numéricas de medidas; as colunas de chave determinam a dimensionalidade da tabela de fatos e os valores dessas chaves determinam sua granularidade; as tabelas de dimensão são comparativamente pequenas, enquanto as tabelas de fatos são grandes e crescem continuamente. A página do Kimball Group sobre granularidade (citada) torna explícito o primeiro passo do projeto: declarar a granularidade define exatamente o que uma única linha da tabela de fatos representa, passa a ser um contrato vinculante e deve vir antes da escolha das dimensões e dos fatos. Recomenda-se a granularidade atômica, o nível mais baixo capturado pelo processo, porque ela resiste a consultas imprevisíveis. A página sobre fatos (citada) classifica as medidas: as aditivas podem ser somadas em qualquer dimensão; as semiaditivas, como saldos, em todas as dimensões exceto o tempo; as não aditivas, como razões, em nenhuma. Por isso, devem-se armazenar seus componentes aditivos e calcular a razão depois da agregação.

Por que importa

Analistas e ferramentas de BI conseguem agregar dados de um esquema estrela sem conhecer os sistemas de origem: filtram por atributos de dimensão, somam medidas e agrupam por qualquer dimensão. Um esquema operacional normalizado exige junções entre várias tabelas, cuja semântica muda a cada consulta, e uma tabela que mistura granularidades (linhas de pedido e cabeçalhos de pedido) gera contagem em duplicidade assim que alguém a soma.

Como aplicar

• Escreva a granularidade como uma frase ("uma linha por item de pedido por dia") e rejeite qualquer medida ou dimensão que não se encaixe nela; uma granularidade diferente vai para uma tabela de fatos separada.
• Dê a cada dimensão uma chave substituta (surrogate key) inteira, mantenha a chave natural da origem como atributo e inclua uma dimensão de data com atributos de calendário, em vez de derivá-los em cada consulta.
• Armazene dimensões degeneradas (número do pedido) diretamente no fato; reserve tabelas de dimensão para entidades com atributos descritivos.
• Defina dimensões conformadas uma única vez e reutilize-as entre tabelas de fatos, para que resultados de processos diferentes se alinhem nas mesmas linhas.

Armadilhas

Decompor dimensões em subtabelas normalizadas (snowflaking) economiza pouco armazenamento e custa junções. Chaves estrangeiras NULL quebram filtros; use um membro de dimensão "desconhecido" explícito. Médias e percentuais armazenados como fatos não podem ser reagregados corretamente.

Chaves substitutas em pipelines reexecutáveis

Uma chave gerada por uma sequência é atribuída na ordem de carga; por isso, reexecutar ou fazer backfill de uma dimensão fora de ordem altera as chaves e deixa órfãos os fatos carregados nesse intervalo. Em pipelines construídos para reexecuções idempotentes, derive a chave substituta de forma determinística a partir da chave natural (e de valid_from nas linhas do tipo 2), normalmente por meio de um hash; dbt_utils.generate_surrogate_key é a implementação mais comum. Assim, as cargas de dimensões e de fatos continuam podendo ser reexecutadas de forma independente, e os fatos podem receber suas chaves no momento da carga, sem consulta de lookup. Mantenha chaves inteiras de sequência quando as cargas forem serializadas e o desempenho de junção com um inteiro estreito for importante, e nunca misture as duas abordagens em uma mesma dimensão.