Esta é uma página conceitual: explica o vocabulário que você vai encontrar no modelo semântico — fatos, dimensões, granularidade, modelo estrela e tipos de coluna. Se você já conhece esses termos do Power BI, vai reconhecer tudo; a diferença é que aqui a modelagem é resolvida em SQL do datalake (não há uma engine em memória tipo VertiPaq).
Os exemplos usam o workspace sintético Comércio Aurora Ltda (workspace aurora,
datasets aurora_bronze / aurora_silver / aurora_gold), com as tabelas
vendas (fato), produtos, clientes, filiais e calendario (dimensões).
Maturidade
O motor de modelagem (relações, cardinalidade, caminho de join) é
GA-candidato — congelado pelo conjunto de testes de referência, com resultado idêntico a cada execução. A execução no
datalake de produção é NÃO MEDIDO sem o datalake configurado. Nenhum recurso é GA
de produto hoje.
Por que modelar (e não só "juntar tabelas")#
Sem um modelo, cada gráfico repete a mesma decisão de negócio de um jeito
diferente: um soma valor, outro soma valor_liquido, um terceiro esquece de
excluir devoluções. O resultado é o clássico "cada relatório com um número de
receita diferente".
Modelar é decidir uma vez como as tabelas se ligam e o que os números significam, para que todos os visuais falem a mesma língua. É a base do modelo semântico e das medidas centrais.
Fato × dimensão#
Todo modelo dimensional separa dois papéis de tabela:
| Papel | O que guarda | No exemplo Aurora |
|---|---|---|
| Fato | Os eventos mensuráveis do negócio — uma linha por ocorrência, com números que se somam. | vendas (uma linha por item vendido: valor, quantidade, custo). |
| Dimensão | O contexto que descreve os eventos — quem, o quê, onde, quando. | produtos, clientes, filiais, calendario. |
Regra prática: se você soma ou conta, é fato; se você agrupa ou filtra
por, é dimensão. "Receita por categoria por mês": receita é medida do
fato vendas; categoria vem da dimensão produtos; mês vem da dimensão
calendario.
Granularidade (grão)#
O grão é o que uma linha do fato representa. Em vendas, o grão é "um item de
um pedido". Definir o grão é a decisão mais importante do modelo, porque:
- Toda medida do fato é somada nesse grão. Somar
valordá a receita total porque cada linha é um item. - Misturar grãos infla números. Se você juntar
vendas(grão item) com uma tabela de metas (grão filial/mês), somar a meta sobre o join a contaria várias vezes. O ingestia.bi detecta esse estouro de linhas (fan-out) e recusa a agregação em vez de entregar um total inflado — ver Relacionamentos e cardinalidade.
Nota
Mantenha um grão por fato. Se precisar de números em grãos diferentes (itens e metas mensais), use dois fatos ligados às mesmas dimensões, não um join forçado.
Modelo estrela × floco de neve#
- Estrela (recomendado): um fato no centro, cercado por dimensões, cada dimensão ligada diretamente ao fato. É simples, rápido de entender e o que o gerador de SQL resolve melhor.
- Floco de neve: dimensões normalizadas em sub-tabelas (ex.:
produtos→categorias→departamentos). Funciona, mas cada salto extra é mais um join. Prefira achatar a dimensão (trazercategoriaedepartamentopara dentro deprodutos) quando puder.
No exemplo Aurora, o desenho estrela é:
calendario
|
clientes — vendas — produtos
|
filiaisO passo a passo de montagem está no tutorial Modelo estrela.
Chaves e relacionamentos#
Uma dimensão se liga ao fato por uma chave: uma coluna do fato aponta para a coluna identificadora da dimensão.
vendas.produto_id→produtos.idvendas.cliente_id→clientes.idvendas.filial_id→filiais.idvendas.data→calendario.data
Cada relação tem cardinalidade (1-1, 1-N, N-1, N-N) e direção de
filtro. Esses conceitos têm efeito real no número final — leia
Relacionamentos e cardinalidade.
Tipos de coluna#
O catálogo classifica cada coluna, e isso orienta visuais, formatação e o que a IA pode ver:
- Numérica — soma, média, contagem; base das medidas do fato.
- Texto / categórica — vira eixo, legenda e filtro (
produtos.categoria). - Data / hora — liga à dimensão
calendarioe habilita comparações temporais. - Categoria de dado geográfica — marcar
filiais.ufcomo UF alimenta os mapas do Brasil. - PII (dado pessoal) — colunas marcadas como PII são mascaradas na visão segura e nunca saem para a IA (ver Segurança por linha (RLS) e as páginas de IA).
Além das colunas de origem, você cria colunas calculadas (derivadas linha a
linha, ex.: margem = valor - custo) e medidas (agregações reutilizáveis, ex.:
Receita = SOMA(vendas.valor)). A diferença entre calcular por linha e agregar no
contexto é o tema de Contexto de linha e de filtro.
Quando NÃO se preocupar com modelagem#
- Uma tabela só, sem cruzamentos: um único fato achatado (planilha larga) já responde a maioria dos gráficos simples — modele relações só quando cruzar tabelas.
- Exploração descartável: para uma pergunta pontual, o wizard de text-to-SQL resolve sem exigir modelo.
Limites e ressalvas#
- Não há engine colunar em memória (VertiPaq); relações viram join no SQL e o join físico é sempre fato → dimensão.
- N-N exige tabela-ponte explícita; sem ponte, a relação é tratada como ambígua e recusada.
- A execução real no datalake (latência, custo, volume) é
NÃO MEDIDOnesta documentação — depende do datalake configurado.
Relacionados#
- Modelo semântico
- Relacionamentos e cardinalidade
- Contexto de linha e de filtro
- Tutorial: modelo estrela
- Medidas, fórmulas e KPIs
Última revisão: 2026-09-08.