Antes de desenhar relacionamentos, classifique cada tabela do modelo por tipo.
A decisão de esquema estrela depende disso, e o
Padrão Corporativo de Nomenclatura usa essa mesma
classificação para escolher o prefixo físico (TabFat, TabDim, TabPon,
TabFlt ou TabInt).
1. Tipos de tabela
| Tipo | O que é | Quando usar | Prefixo |
|---|---|---|---|
| Fato | Observações ou eventos do negócio: vendas, pedidos, saldos de estoque, taxas de câmbio. Guarda as chaves das dimensões e os valores que serão resumidos | Sempre que houver algo a medir | TabFat |
| Dimensão | Descreve as entidades do negócio: cliente, produto, fornecedor, calendário. Guarda a chave única e os atributos usados para filtrar e agrupar | Sempre que houver uma entidade usada para filtrar ou agrupar as fatos | TabDim |
| Ponte | Liga duas dimensões numa relação muitos-para-muitos (ex.: vendedor × região). É uma fato sem valores, só com as duas chaves | Quando uma dimensão se relaciona com várias linhas de outra | TabPon |
| Monolítica (flat table) | Fato e dimensões numa única estrutura | Protótipo rápido, extração única de sistema legado ou cenário deliberadamente simples. Nunca o padrão-ouro | TabFlt |
| Interface | Tabela técnica, fora do esquema estrela: tabela de medidas, parâmetros, data da última atualização | Para organizar medidas ou guardar valores de apoio ao relatório | TabInt |
Como o Power BI enxerga o tipo: não existe uma propriedade "fato" ou "dimensão". Quem define é o relacionamento: no relacionamento um-para-muitos, a tabela do lado "um" funciona como dimensão e a do lado "muitos", como fato.
Por que o esquema estrela é o padrão-ouro: as dimensões servem para filtrar e agrupar, as fatos para resumir, e é exatamente isso que cada visual pede ao modelo. Separar os dois papéis permite relacionamentos eficientes, reuso de uma mesma dimensão por várias fatos e melhor compressão no VertiPaq. A tabela monolítica começa rápido, mas cresce mal: cada nova pergunta de negócio tende a exigir duplicar dados em vez de relacionar.
Grão: toda tabela fato precisa ter um grão consistente, ou seja, cada linha representa o mesmo nível de detalhe (uma venda, um item de pedido, um saldo por produto e mês). Misturar grãos na mesma fato gera totais errados.
2. Tipos de campo
| Tipo | O que é | Exemplo (físico → semântico) | Tratamento no Power BI |
|---|---|---|---|
| Chave primária | Identifica unicamente cada linha da tabela | CodigoCliente em TabDimCliente | Marcar como chave; ocultar |
| Chave estrangeira | Aponta para a chave primária de outra tabela e cria o relacionamento | CodigoCliente em TabFatVenda | Ocultar; usar tipo inteiro |
| Descritor | Descreve o registro; não entra em cálculo | NomeCliente → Nome do Cliente, Segmento | "Não resumir" |
| Georreferenciado | Algo que pode ir para um mapa: país, estado, cidade, CEP, latitude, longitude | SiglaUF → UF, CEP, Latitude | Definir a Categoria de dados (Estado, CEP, Latitude…) |
| Agregável | Valor com resumo matemático que faz sentido: soma, média, contagem | ValorVenda → Valor da Venda, Quantidade | Criar medida explícita (ex.: Total de Vendas) |
Um campo pode ter mais de um papel (o CEP é descritor e georreferenciado ao
mesmo tempo). A classificação não é exclusiva: é uma lente para decidir como
tratar o campo no modelo.
⚠️ Resumo automático: não deixe o Power BI somar colunas numéricas sozinho. Chaves, códigos e anos ficam com "Não resumir"; valores agregáveis ganham uma medida explícita. É o que pedem as regras de Formatação (desabilitar a sumarização automática em colunas numéricas) e de Relatórios e Visuais (evitar medidas implícitas).
3. Regras relacionadas
- Prefixos e nomes físico × semântico: Padrão Corporativo de Nomenclatura, no guia da página de Boas Práticas.
- Ocultar chave estrangeira e usar tipo inteiro nas colunas de relacionamento: Boas Práticas, Formatação.
- Esquema estrela em vez de snowflake: Boas Práticas, Desempenho.
4. Onde usar na prática
Ao levantar os requisitos de um projeto novo (bloco Origem dos Dados do Dashboard Canvas), classifique cada fonte por tipo de tabela e marque os campos-chave logo no início. É uma decisão muito mais barata de mudar antes de existir a primeira medida DAX escrita em cima dela.