Tipos de modelagem
Dimensional, wide table e consolidação multi-fonte. Três formas de organizar a camada Gold, cada uma com um exemplo concreto e um caso em que brilha.
- Conhecer os três padrões com exemplo prático de cada
- Escolher o padrão certo por caso de uso
- Evitar over-engineering na hora de modelar
Modelar é decidir o formato da sua camada Gold. Não existe um formato "certo" universal: existe o que serve ao seu consumo. Os três padrões abaixo cobrem quase tudo o que você vai precisar. Comece pelo diagrama, depois veja o exemplo concreto de cada um nas abas.
Os três padrões, com exemplo
Separa fatos (os eventos, com as métricas) das dimensões (as entidades que descrevem o evento). O fato guarda chaves e números, as dimensões guardam os atributos. Você junta na hora da análise.
fato_vendas (uma linha por venda):
| data_id | produto_id | cliente_id | valor | qtd |
|---|---|---|---|---|
| 20260308 | P-42 | C-5521 | 1234,50 | 3 |
dim_produto e dim_cliente (atributos, sem repetir a cada venda):
| produto_id | nome | categoria |
|---|---|---|
| P-42 | Tênis Runner | Calçados |
Bom quando: BI pesado, muitas métricas agregadas por várias dimensões, e você quer economizar storage não repetindo atributos. O custo é precisar de joins toda vez.
Uma única tabela larga, com tudo já junto, uma linha por evento no grão que você consome. Nada de joins na hora de usar.
vendas_wide (uma linha por venda, já com os atributos dentro):
| data | produto | categoria | cliente | cidade | valor | qtd |
|---|---|---|---|---|---|---|
| 08/03/2026 | Tênis Runner | Calçados | Loja Silva | Recife | 1234,50 | 3 |
Bom quando: exploração ad-hoc, consumo simples, e principalmente consumo por IA via MCP. Um agente entende uma tabela larga muito melhor do que precisar descobrir e executar joins. Na Nekt, a Gold voltada a IA tende a ser wide.
Junta várias fontes numa tabela única, padronizando os campos por uma chave comum. Clássico de agência: unir investimento de mídia de plataformas diferentes.
Fontes cruas (cada uma fala uma língua):
| fonte | campo de gasto | campo de resultado |
|---|---|---|
| Meta Ads | spend | leads |
| Google Ads | cost | conversions |
consolidado_midia (uma linha por cliente, canal e dia, campos padronizados):
| data | cliente | canal | investimento | leads |
|---|---|---|---|---|
| 08/03/2026 | Loja Silva | Meta | 320,00 | 18 |
| 08/03/2026 | Loja Silva | 410,00 | 22 |
Bom quando: você precisa comparar ou somar dados que vêm de sistemas diferentes. O trabalho está em achar a chave comum e padronizar os nomes e as unidades.
Comparando os três
| Padrão | Formato | Melhor para | Consumo ideal | Complexidade |
|---|---|---|---|---|
| Dimensional | Fato + dimensões | BI com muitas métricas | Dashboards, ferramentas de BI | Alta (joins) |
| Wide table | Uma tabela larga | Exploração e IA | MCP, exploração, Data API | Baixa |
| Consolidação | Multi-fonte unificada | Juntar sistemas diferentes | Relatórios cross-fonte | Média (padronizar) |
Modelo dimensional em estrela é lindo no diagrama e caro na prática. Se o seu consumo é exploração e IA, uma wide table resolve com menos joins, menos manutenção e melhor resultado no MCP. Só monte estrela quando o volume de storage ou o BI realmente pedirem.
Escolhido o padrão, você não precisa escrever a transformação inteira na mão. O MCP da Nekt cria a query ou o notebook a partir de linguagem natural: peça "monte uma wide table de vendas por pedido, com produto, cliente e canal" e ele gera o código pra você revisar e ajustar. Estruturar o modelo fica muito mais rápido.
Decida agora
Uma agência começou querendo montar um star schema completo de mídia. Na prática, o consumo era um agente respondendo perguntas e um dashboard simples. Trocaram por uma wide table consolidada (uma linha por cliente, canal e dia). Menos manutenção, e o agente passou a acertar mais porque não precisava mais adivinhar joins entre fatos e dimensões.
Materiais de referência
Para aprofundar cada padrão e ver como aplicar no seu workspace:
↗ Guia: Organização do catálogo ↗ Vá fundo nos docs: transformações na Nekt