Tipos de Tabela e Tipos de Campo
Antes de desenhar relacionamentos, vale classificar cada tabela do
modelo por tipo — a decisão de esquema estrela depende disso, e o
Padrão Corporativo de Nomenclatura usa exatamente essa classificação
para decidir o prefixo (TabFat, TabDim ou TabFlt).
1. Tipos de tabela
| Tipo | O que é | Quando usar | Prefixo |
|---|---|---|---|
| Fato | Eventos mensuráveis que definem o propósito do negócio — registros imutáveis (vendas, pedidos, ordens de serviço) | Sempre que houver um evento de negócio repetível para medir | TabFat |
| Dimensão | Dados complementares/explicativos que dão contexto à Fato — cadastros (clientes, produtos, fornecedores, calendário) | Sempre que houver uma entidade descritiva reutilizada por múltiplas Fatos | TabDim |
| Monolítica (flat table) | Todos os dados num único arquivo/estrutura, sem separação fato×dimensão | Protótipo rápido, extração única de sistema legado, ou cenário deliberadamente simples — nunca o padrão-ouro | TabFlt |
O esquema estrela (Fato + Dimensões) é o padrão-ouro porque separa "o que aconteceu" (Fato) de "quem/o quê/quando aconteceu" (Dimensão) — isso é o que permite relacionamentos eficientes, reuso de dimensão entre múltiplas fatos, e as otimizações de compressão do VertiPaq. Uma tabela Monolítica funciona para começar rápido, mas cresce mal: cada nova pergunta de negócio tende a exigir duplicar dados em vez de relacionar.
2. Tipos de campo
| Tipo | O que é | Exemplo |
|---|---|---|
| Chave Primária | Identifica unicamente cada registro da tabela | ClienteID em TabDimCliente |
| Chave Estrangeira | Referencia a chave primária de outra tabela, estabelecendo o relacionamento | ClienteID em TabFatVenda |
| Descritor | Informação complementar/explicativa sobre o registro, não usada em cálculo | NomeCliente, Segmento |
| Georreferenciado | Identifica algo exibível em mapa — latitude, longitude, país, estado, cidade, CEP | UF, CEP, Latitude |
| Agregável | Valor passível de resumo matemático — soma, média, contagem, mín/máx | Quantidade, ValorVenda |
Um campo pode acumular mais de um papel semântico (ex.: CEP é
Descritor e Georreferenciado ao mesmo tempo) — a classificação não é
mutuamente exclusiva, é uma lente pra decidir como tratar o campo no
modelo (esconder chave estrangeira do usuário final, marcar campo
georreferenciado com a categoria de dados certa no Power BI, aplicar
sumarização automática só em campos agregáveis).
3. Cross-referência
- Prefixos de tabela (
TabFat/TabDim/TabFlt) — verpowerbi-padrao-nomenclatura, seção "Modelagem dimensional". - Ocultar chave estrangeira do usuário final e usar tipo de dado inteiro em colunas de relacionamento — regras oficiais de Boas Práticas, categoria Formatação.
- Esquema estrela vs. snowflake — regra oficial de Boas Práticas, categoria Performance.
4. Onde usar isso na prática
Ao levantar requisito de um projeto novo (ver Dashboard Canvas, bloco "Origem dos Dados"), classificar cada fonte por tipo de tabela e marcar os campos-chave logo na anamnese evita retrabalho de modelagem depois — é decisão que fica mais barata de mudar antes de existir uma única medida DAX escrita em cima dela.