Modelagem dimensional: fato e dimensão na prática

Seu modelo está lento e ninguém sabe explicar o número#

A cena é quase sempre a mesma quando pegamos um projeto de Power BI para revisar: dezenas de tabelas importadas direto do sistema de origem, tudo ligado com relacionamentos em teia, e o modelo trava a cada slicer que o usuário clica. Pior: quando a diretoria pergunta por que o faturamento do dashboard não bate com o do ERP, ninguém consegue apontar onde a regra mora. A causa raiz quase nunca é o DAX. É a ausência de modelagem dimensional, que é a disciplina de organizar o modelo em tabelas de fato e de dimensão dentro de um esquema estrela.

Modelagem dimensional é a abordagem consolidada por Ralph Kimball para estruturar dados analíticos de um jeito que humanos entendem e ferramentas de BI processam rápido. A ideia central é separar o modelo em dois tipos de tabela: a tabela fato, que guarda os eventos de negócio no grão definido com suas medidas, e as tabelas dimensão, que guardam o contexto descritivo pelo qual você filtra e agrupa. Neste artigo eu mostro como isso funciona na prática, o que é grão, medida aditiva, chave substituta e dimensão que muda ao longo do tempo, e por que o esquema estrela é o formato ideal para o Power BI e o motor VertiPaq. Com honestidade, inclusive sobre onde o modelo dá trabalho.

O esquema estrela é o formato que o Power BI foi feito para consumir#

O esquema estrela recebe esse nome pelo desenho: uma tabela fato no centro, cercada por tabelas dimensão que se ligam a ela como pontas de uma estrela. Cada dimensão se conecta à fato por um único relacionamento, sempre um-para-muitos, da dimensão para a fato. É simples de olhar e é justamente essa simplicidade que sustenta a performance.

O contraponto clássico é o floco de neve (snowflake), onde as dimensões são normalizadas em várias tabelas encadeadas: produto liga em subcategoria, que liga em categoria. Funciona, mas cria saltos de relacionamento que o motor percorre a cada consulta e complica o DAX. Para BI, a normalização que faz sentido no banco transacional é o que atrapalha no modelo analítico. A recomendação de quem faz isso todo dia é direta: desnormalize as dimensões e fique na estrela sempre que possível.

Aspecto	Esquema estrela	Floco de neve
Dimensões	Desnormalizadas, uma tabela por dimensão	Normalizadas em várias tabelas encadeadas
Relacionamentos	Poucos, um salto da dimensão para a fato	Muitos, com saltos entre dimensões
DAX	Mais simples de escrever e ler	Mais complexo, exige cuidado com contexto
Performance no VertiPaq	Ideal	Aceitável, mas com mais junções
Manutenção	Fácil de entender e evoluir	Mais peças para manter

Existe um motivo técnico para a estrela casar tão bem com o Power BI. O motor de armazenamento do Power BI, o VertiPaq, é colunar e comprime cada coluna de forma independente. Ele adora colunas com poucos valores distintos, ou seja, de baixa cardinalidade. Dimensões desnormalizadas concentram atributos repetitivos e de baixa cardinalidade em tabelas pequenas, enquanto a fato fica estreita, com chaves numéricas e medidas. Esse arranjo é o cenário perfeito de compressão do VertiPaq e o que faz o modelo responder rápido mesmo com dezenas de milhões de linhas. O esquema estrela não é uma preferência estética, é a base sobre a qual o Power BI foi projetado.

A tabela fato guarda os eventos de negócio no grão definido#

A tabela fato é o coração do modelo. Ela registra os eventos de negócio que você quer medir: uma venda, um pedido, um atendimento, uma movimentação de estoque. Cada linha da fato representa uma ocorrência desse evento e carrega dois tipos de coluna: as chaves que apontam para as dimensões e as medidas, que são os valores numéricos que você soma, conta e analisa.

Antes de escrever uma única linha de código, você precisa definir o grão da fato. O grão é a resposta para a pergunta "o que uma linha desta tabela representa?". Uma linha por item de nota fiscal? Uma linha por pedido? Uma linha por dia por produto por loja? Essa decisão governa tudo o que vem depois. Definir o grão errado, ou misturar grãos diferentes na mesma fato, é o erro mais caro da modelagem dimensional, porque contamina medidas, duplica valores e força gambiarras de DAX para tentar consertar depois. Defina o grão no nível mais atômico que o negócio precisar, e mantenha uma fato coerente com um único grão.

As medidas da fato têm um atributo que decide como você pode usá-las: a aditividade. Vale separar três casos:

• Aditivas: podem ser somadas por qualquer dimensão. Quantidade vendida e valor de venda são aditivos, você soma por produto, por cliente, por mês, por qualquer eixo. São as medidas mais fáceis e o alvo ideal.
• Semiaditivas: podem ser somadas por algumas dimensões, mas não por tempo. Saldo de estoque e saldo bancário são o exemplo clássico: somar o saldo de dezembro com o de novembro não faz sentido, mas somar o saldo de várias contas no mesmo dia faz.
• Não aditivas: não podem ser somadas por nenhuma dimensão. Percentuais, razões e médias entram aqui. A regra prática é guardar os componentes aditivos na fato, o numerador e o denominador, e calcular a razão como medida no DAX, nunca armazenar o percentual pronto.

Guardar componentes aditivos e calcular razões em tempo de consulta não é preciosismo. É o que garante que uma margem agregada por região não vire a média errada de médias. Para escrever essas medidas do jeito certo, vale a leitura sobre modelagem e DAX de boas práticas no Power BI.

As tabelas dimensão dão o contexto pelo qual você filtra e agrupa#

Se a fato responde "quanto", as dimensões respondem "quem, o quê, quando e onde". A dimensão Produto tem nome, categoria, marca, cor. A dimensão Cliente tem nome, cidade, segmento. A dimensão Calendário tem dia, mês, trimestre, ano, dia da semana. São essas colunas descritivas que viram os eixos dos seus gráficos, os campos dos seus slicers e as linhas das suas tabelas.

Uma boa dimensão é rica em atributos e desnormalizada. Não tenha medo de repetir "Eletrônicos" em milhares de linhas de produto: o VertiPaq comprime isso quase de graça, e em troca você ganha um modelo simples e consultas rápidas. Cada dimensão deve ter uma chave que a identifica de forma única, e é por essa chave que ela se liga à fato.

Uma dimensão merece atenção especial: a de Calendário, ou dimensão de tempo. Ela é obrigatória em praticamente todo modelo, precisa ser contínua, sem buracos de datas, e deve ser marcada como tabela de datas no Power BI. É ela que habilita toda a inteligência temporal do DAX, como comparações ano contra ano e acumulados. Modelo sério não usa a data que veio na fato como eixo de tempo, usa uma dimensão de calendário dedicada.

Característica	Tabela fato	Tabela dimensão
O que guarda	Eventos de negócio, medidas	Contexto descritivo, atributos
Volume de linhas	Grande, cresce com o tempo	Pequeno a moderado
Colunas típicas	Chaves e valores numéricos	Textos e categorias descritivas
Cardinalidade	Alta na fato como um todo	Baixa nos atributos
Papel na análise	Responde "quanto"	Responde "quem, o quê, quando, onde"
Relacionamento	Lado "muitos"	Lado "um"

Chaves substitutas isolam o modelo da origem#

Aqui entra uma decisão que separa o modelo amador do modelo profissional: usar chaves substitutas, ou surrogate keys. A chave substituta é uma chave artificial, tipicamente um número inteiro sequencial, gerada por você na engenharia de dados para identificar cada linha da dimensão. Ela substitui a chave natural do sistema de origem, como o CPF do cliente ou o SKU do produto, no papel de conectar dimensão e fato.

Por que não usar direto a chave que já veio do sistema? Por vários motivos práticos:

• Independência da origem: se o ERP troca o formato do código do produto, ou se você integra dois sistemas que usam códigos diferentes para o mesmo cliente, a chave substituta protege o modelo. A origem muda, o seu modelo não.
• Performance no VertiPaq: um inteiro sequencial comprime e faz junção muito melhor do que uma chave alfanumérica longa. A fato fica mais leve e as consultas mais rápidas.
• Histórico: e este é o ponto decisivo, a chave substituta é o que permite guardar mais de uma versão do mesmo cliente ou produto ao longo do tempo, algo que a chave natural sozinha não consegue fazer.

Esse último ponto nos leva diretamente ao tema mais mal resolvido da maioria dos modelos: o que fazer quando uma dimensão muda.

Dimensões mudam, e SCD tipo 1 e tipo 2 tratam isso de formas opostas#

Um cliente muda de cidade. Um produto muda de categoria. Um vendedor muda de região. A pergunta não é se a dimensão vai mudar, é o que você quer que aconteça com o histórico quando ela mudar. Kimball classifica essas mudanças em tipos, e os dois que você precisa dominar são o tipo 1 e o tipo 2. Essas são as chamadas dimensões que mudam lentamente, ou Slowly Changing Dimensions (SCD).

O SCD tipo 1 sobrescreve o valor antigo com o novo. Simples e direto: o cliente mudou de cidade, a coluna cidade passa a mostrar a nova cidade, e a antiga desaparece. Não há histórico. Toda a análise passada é recontada como se o cliente sempre tivesse morado na cidade atual. Use tipo 1 quando o histórico do atributo não importa, ou quando a mudança é uma correção de erro de digitação que você quer apagar mesmo.

O SCD tipo 2 preserva o histórico criando uma nova linha na dimensão a cada mudança. O cliente que mudou de cidade passa a ter duas linhas: a antiga, marcada como inativa com data de fim de vigência, e a nova, ativa. Cada linha tem sua própria chave substituta, e é por isso que a chave substituta é pré-requisito do tipo 2. As fatos antigas continuam apontando para a linha antiga, as novas apontam para a nova, e a análise histórica fica correta: as vendas de antes da mudança contam para a cidade antiga, as de depois para a nova.

Aspecto	SCD tipo 1	SCD tipo 2
O que faz com a mudança	Sobrescreve o valor antigo	Cria uma nova linha e preserva a antiga
Histórico	Não guarda	Guarda de forma completa
Chave substituta	Útil	Obrigatória
Colunas de controle	Não precisa	Vigência início, vigência fim, flag de ativo
Complexidade	Baixa	Média a alta
Quando usar	Correções e atributos sem valor histórico	Atributos cujo histórico importa para a análise

A escolha entre tipo 1 e tipo 2 não é técnica, é de negócio. Ela depende de uma pergunta: quando eu olhar as vendas do ano passado, quero ver a região que o vendedor tinha na época ou a região que ele tem hoje? Se a resposta é "na época", é tipo 2. Se é "a de hoje", é tipo 1. Ninguém no time de engenharia deveria decidir isso sozinho, isso se define com a área de negócio. E um alerta honesto: tipo 2 tem custo. Ele infla a dimensão, exige colunas de controle de vigência e cuidado no pipeline de carga para fechar a linha antiga e abrir a nova corretamente. Não aplique tipo 2 em toda coluna por precaução, aplique onde o histórico realmente vale.

Montar e manter esse tipo de lógica de carga é trabalho de engenharia de dados de verdade, não de arrastar tabelas no Power BI. O modelo dimensional costuma viver na camada final de preparação, já limpo e conformado, pronto para consumo.

Perguntas frequentes#

Modelagem dimensional é a mesma coisa que esquema estrela? Não exatamente. Modelagem dimensional é a disciplina de organizar dados analíticos em fatos e dimensões, seguindo a abordagem de Kimball. O esquema estrela é o formato físico mais comum que essa modelagem assume, com uma fato central cercada de dimensões desnormalizadas. Na prática, quando alguém fala em modelagem dimensional para Power BI, quase sempre está falando de montar um esquema estrela.

Preciso de chave substituta mesmo em um modelo pequeno? Depende do que você vai fazer. Se o modelo é simples, sem histórico de dimensão e com uma única origem estável, a chave natural pode bastar. Mas no momento em que você precisa integrar fontes diferentes, se proteger de mudanças na origem ou aplicar SCD tipo 2, a chave substituta deixa de ser opcional. Como ela é barata de implementar, muitos times já a adotam por padrão para não ter retrabalho depois.

Por que o esquema estrela é melhor para o Power BI do que trazer as tabelas como estão? Porque o VertiPaq, o motor do Power BI, é colunar e comprime melhor colunas de baixa cardinalidade, exatamente o que as dimensões desnormalizadas oferecem. O esquema estrela também reduz o número de relacionamentos e deixa o DAX mais simples e previsível. Trazer as tabelas cruas do sistema transacional gera modelos com muitos saltos, relacionamentos complexos e consultas lentas.

O que acontece se eu errar o grão da tabela fato? Vira dor de cabeça crônica. Misturar grãos diferentes na mesma fato, por exemplo linhas por pedido junto com linhas por item, duplica medidas e força você a filtrar e corrigir no DAX o tempo todo. O certo é definir um grão único e atômico por fato. Se precisa de outro grão, isso normalmente é outra tabela fato, não uma coluna extra na mesma.

Quando devo usar SCD tipo 2 em vez de tipo 1? Use tipo 2 quando o histórico do atributo importa para a análise, ou seja, quando você quer ver o passado com o valor que era verdadeiro na época. Território de vendedor, faixa de crédito de cliente e categoria de produto costumam pedir tipo 2. Use tipo 1 quando só interessa o valor atual, ou quando a mudança é uma correção que você quer apagar do histórico. A decisão é do negócio, não da TI.

Modelagem dimensional ainda faz sentido com Microsoft Fabric e lakehouse? Faz, e continua sendo a camada de consumo recomendada. O lakehouse muda onde e como o dado é preparado, mas o modelo que alimenta o Power BI ainda deve ser dimensional, em esquema estrela, para performar. Fabric, Direct Lake e Delta não substituem a modelagem, eles são a infraestrutura sobre a qual você entrega o modelo dimensional na camada final. Vale ver o panorama do Microsoft Fabric para entender onde a modelagem se encaixa.

A modelagem dimensional separa dashboard rápido de gambiarra lenta#

A modelagem dimensional não é teoria de livro, é a diferença prática entre um Power BI que responde rápido, que qualquer analista entende e cujos números batem, e um amontoado de tabelas cruas que trava e gera desconfiança. Fato no grão certo, dimensões desnormalizadas e ricas, chaves substitutas para isolar a origem e SCD escolhido com o negócio: são essas decisões, tomadas na engenharia antes de qualquer visual, que sustentam um projeto confiável. O esquema estrela não é enfeite, é o formato que o VertiPaq foi feito para comprimir e consultar.

Se você tem um modelo de Power BI lento, cheio de relacionamentos em teia, ou está montando um do zero e quer acertar a fundação, fale com a gente. Já reestruturamos modelos dimensionais em cenários assim e sabemos onde a disciplina economiza tempo e onde ela é exagero.