Há metodologias que envelhecem mal e outras que resistem ao tempo. A modelação dimensional de Ralph Kimball pertence claramente ao segundo grupo. Décadas depois de proposta, continua a ser a base de praticamente todos os data warehouses e modelos semânticos que funcionam bem — do SQL Server ao Microsoft Fabric. A razão é simples: alinha o modelo de dados com a forma como o negócio pensa.
Quem trabalha com dados conhece o sintoma do modelo mal desenhado: relatórios lentos, métricas que não batem certo entre departamentos, e cada pergunta nova a exigir horas de trabalho. Um bom modelo dimensional resolve isto na origem. Vamos ver como, na prática.
Factos e dimensões: a ideia central
Toda a modelação dimensional assenta numa distinção simples. Os factos representam eventos mensuráveis do negócio — uma venda, uma encomenda, um pagamento. As dimensões representam o contexto desses eventos — quem, o quê, quando, onde. A tabela de factos guarda os números (quantidade, valor); as dimensões guardam os atributos por onde se filtra e agrupa (cliente, produto, data, loja).
Esta separação não é burocracia técnica: é o que permite que um utilizador de negócio responda a "vendas por região e por mês" sem escrever uma única linha de código, arrastando dimensões e medidas de forma intuitiva.
A decisão mais importante: a granularidade
Se há uma decisão que define o sucesso de um modelo, é esta: definir a granularidade da tabela de factos antes de qualquer outra coisa. A granularidade é o nível de detalhe de cada linha — uma linha por venda? por item da venda? por dia e produto?
A regra de ouro é escolher sempre o nível mais atómico disponível. Guardar ao detalhe da linha de venda dá flexibilidade para agregar de todas as formas possíveis no futuro. Escolher um nível já agregado poupa espaço a curto prazo, mas cedo ou tarde alguém vai pedir um detalhe que já não existe — e a reconstrução é cara e arriscada.
Os ingredientes de um modelo sólido
Para além da granularidade, alguns padrões separam um modelo robusto de um frágil:
- Chaves surrogate: chaves numéricas próprias do warehouse, independentes das chaves de negócio, que tornam as junções rápidas e resistentes a mudanças na origem.
- Dimensões desnormalizadas: ao contrário do modelo transacional, aqui compensa "achatar" as dimensões (o produto com a sua categoria e marca na mesma tabela), privilegiando a simplicidade e o desempenho da leitura.
- Uma tabela de datas completa: talvez a dimensão mais subestimada. Ter uma dimensão de calendário com ano, trimestre, mês, dia da semana e feriados desbloqueia toda a análise temporal.
- Esquema em estrela: factos ao centro, dimensões à volta. Simples de entender, rápido de consultar.
Na prática: do transacional ao analítico
Imagine uma base de dados de e-commerce, normalizada ao detalhe para suportar a aplicação: encomendas, linhas de encomenda, produtos, categorias, clientes, moradas — tudo em tabelas separadas e ligadas por chaves. É ótima para gravar dados, péssima para analisar.
Ao transformá-la num modelo dimensional, colapsa-se essa teia em algo simples: uma tabela de factos "vendas" ao nível da linha de encomenda, e um punhado de dimensões (cliente, produto, data, canal). De repente, uma pergunta que exigia várias junções e um analista passa a ser um relatório que qualquer gestor constrói em segundos.
Kimball na era do lakehouse
Poderia pensar-se que, com o Fabric, o Databricks e os lakehouses, a modelação dimensional deixou de importar. É o contrário. As ferramentas mudaram — o Delta Lake, o Direct Lake, o processamento distribuído — mas a necessidade de um modelo que o negócio entenda mantém-se intacta. A camada Gold de uma arquitetura Medallion é, tipicamente, um modelo dimensional Kimball.
A lição que resiste é esta: a tecnologia acelera, mas não substitui um bom desenho. Investir tempo na modelação continua a ser o que separa um warehouse que as pessoas usam e em que confiam de um que ninguém abre. E no seu projeto: a granularidade da tabela de factos foi uma decisão pensada, ou aconteceu por acaso?
