Conceitos de modelagem dimensional — ingestia.io Documentation

This page has not been translated yet — you are reading the Portuguese version. View in Portuguese

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 valor dá 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.

Note

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 (trazer categoria e departamento para dentro de produtos) quando puder.

No exemplo Aurora, o desenho estrela é:

code

        calendario
            |
clientes — vendas — produtos
            |
         filiais

O 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.id
vendas.cliente_id → clientes.id
vendas.filial_id → filiais.id
vendas.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 calendario e habilita comparações temporais.
Categoria de dado geográfica — marcar filiais.uf como 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 MEDIDO nesta documentação — depende do datalake configurado.

Relacionados#

Última revisão: 2026-09-08.