Star schema: o que é e como modelar dados de receita

Marketing puxa o número de leads de um lugar, Vendas de outro, Financeiro tem a receita numa terceira planilha — e no fim do mês nenhum bate. Cada pergunta nova (“quanto de receita veio de inbound no trimestre, por segmento?”) vira um projeto de meio dia de PROCV. O problema não é falta de ferramenta; é arquitetura de dados. Este guia cobre o que é star schema, a diferença entre fato e dimensão, como montar na ordem certa, quando ele vence o snowflake e as armadilhas de quem já implementou.

O que é star schema

Os dados já existem — todo mundo tem CRM, tem BI, tem planilha. O que falta é modelá-los numa forma que responde pergunta. Star schema (esquema estrela, ou modelagem dimensional) é a resposta madura para isso, e madura de verdade: Ralph Kimball formalizou o método nos anos 90 e ele segue sendo o padrão da indústria para análise, inclusive nas plataformas de nuvem modernas.^[1]

A ideia é dividir todo dado em duas categorias, e só duas. A fato (fact table) é o que aconteceu e você mede — uma linha por evento no menor nível possível: uma venda, um pagamento, um clique. Guarda números (valor, quantidade) e chaves que apontam para o contexto; cresce sem parar, milhões de linhas, e é magra em colunas. A dimensão (dimension table) é o contexto que descreve o fato — o “quem, o quê, onde, quando”: cliente, produto, data, canal, vendedor. Poucas linhas, muitas colunas descritivas. É por aqui que você filtra e agrupa.

A Microsoft resume a divisão de trabalho de forma limpa: dimensões servem para filtrar e agrupar; fatos servem para somar.^[2] Toda pergunta de BI é uma combinação disso — “some a receita (fato), agrupada por canal (dimensão), filtrada pelo trimestre (dimensão)”. Quando os dados já estão nesse formato, a pergunta vira uma linha; quando não estão, vira um projeto.

Não confunda com dois vizinhos. O data warehouse é o lugar onde o star schema mora (o banco analítico); o star schema é a forma como você organiza os dados lá dentro — dá para ter um warehouse mal modelado, sem estrela, e sofrer para tirar relatório dele. E o snowflake schema é a versão normalizada da mesma ideia, com mais joins — assunto da seção “Quando usar”. Onde o star schema realmente importa é como meio, não como fim: é ele que faz NRR, CAC e forecast serem calculáveis de um jeito confiável. Sem ele, cada métrica é uma planilha isolada com sua própria definição de “cliente” e “receita” — e é exatamente aí que os números param de bater.

Como montar um star schema

Kimball define um processo canônico de quatro passos, nessa ordem: (1) escolha o processo de negócio, (2) declare o grão, (3) liste as dimensões, (4) liste os fatos.^[4] A ordem não é decorativa — pular o grão para começar pelas dimensões (a parte “visível”) é a origem de quase todo modelo quebrado.

A decisão mais importante e a que mais gente erra é o grão (grain): em que nível fica uma linha da fato? Uma linha por pedido? Por item do pedido? Por dia? Kimball é categórico — declare o grão primeiro, por escrito, com todos os donos concordando, e faça no nível atômico (o mais detalhado que a fonte permite).^[4] Grão errado é irreversível na prática: se você agregou por dia, nunca mais responde “por hora”; se misturou grãos (uma linha por item e uma linha de total do pedido), soma tudo em dobro e o número infla sem ninguém perceber. Esse é o passo que trava reunião — deixe travar, é barato aqui e caríssimo depois.

Depois vêm dimensões e fatos. As dimensões saem dos recortes que o negócio realmente fatia — cliente, produto, data, canal, vendedor: cada coisa que alguém vai querer filtrar ou agrupar. Os fatos são só o que se soma naquele grão — valor, quantidade, desconto, custo. Números aditivos entram; taxa e percentual se calculam depois, não se guardam na fato. Duas escolhas de engenharia fecham o modelo. Use uma chave substituta (surrogate key) gerada por você, nunca o ID do sistema de origem^[2] — o dia em que você troca de CRM, ou o cliente muda de segmento, o ID de origem te trai, e é a surrogate key que sustenta o versionamento (as slowly changing dimensions, o histórico de “esse cliente era tier 1 na venda de janeiro, virou tier 2 em março”). E faça as dimensões conformes: uma dim_cliente só, que serve o fato de venda e o fato de receita — é o que faz os números baterem entre áreas. Ao fim, valide com uma pergunta real que hoje é difícil; se o modelo responde em uma consulta, funcionou; se ainda exige três joins e uma reza, o grão ou as dimensões estão errados — volte ao passo dois.

Quando usar star schema (e quando snowflake)

A dúvida clássica é star contra snowflake. No star schema, cada dimensão é uma tabela só, achatada (desnormalizada): a dimensão produto já traz categoria e subcategoria dentro dela. No snowflake schema, você normaliza — quebra produto em produto → subcategoria → categoria, três tabelas encadeadas. O snowflake economiza um pouco de armazenamento e é mais “limpo” academicamente, mas cobra o preço em joins a mais em toda consulta e num modelo mais difícil de o usuário de negócio entender.^[3]

Há ainda a comparação com o modelo transacional normalizado (3NF), o formato de banco de sistema operacional. Consultas contra um modelo dimensional são significativamente mais rápidas que contra um 3NF, porque os joins e as agregações já foram aplicados na modelagem.^[5] Na dúvida, star — a própria Microsoft recomenda colapsar um snowflake numa dimensão única no BI.^[2] O ganho real não é de milissegundo, é de clareza: todo mundo consulta a mesma fonte com a mesma definição. Quem promete “star schema melhora performance em X%” está chutando — o ganho depende do volume, do motor (Postgres, BigQuery, Snowflake) e da qualidade dos índices.

Como implementar na prática

Armadilhas comuns

Estes são os erros que mais aparecem quando ajudamos um time a montar um star schema do zero — a maioria nasce de modelagem apressada, não de falta de ferramenta.

Pular a definição do grão e sair criando tabela

O erro nº 1 é começar pelas dimensões porque é a parte visível, e deixar o grão implícito. Aí metade das linhas da fato é por item e a outra metade é total de pedido — ninguém declarou, então ninguém percebe. Toda soma de receita infla, o forecast fica otimista, e você descobre quando o número do BI não bate com o do Financeiro no fechamento. Grão primeiro, sempre. É a regra nº 1 do Kimball e a mais ignorada.^[4]

Guardar taxa e percentual dentro da fato

O time quer “NRR” ou “win rate” prontos na fato para não recalcular. O problema: percentual não é aditivo — você não soma dois NRR e obtém um NRR válido. Quando alguém agrega por trimestre, o número vira lixo silencioso. A fato guarda os ingredientes aditivos (receita retida, receita base); a taxa se calcula na consulta ou na camada de métrica. Todo mundo tenta essa e todo mundo se queima.

Usar o ID de origem como chave, sem surrogate key

Parece economia — “por que criar uma chave nova se o Pipedrive já tem ID?”. Aí você troca de CRM, ou o cliente muda de segmento, e o histórico se perde ou os IDs colidem. Sem chave substituta você não consegue versionar dimensão (slowly changing dimension) e perde a resposta para “esse cliente estava em que tier na venda de janeiro?”.^[2] Barato de fazer no início, caro de retrofit.

Modelar a empresa inteira antes de entregar qualquer coisa

O impulso perfeccionista é desenhar todas as fatos e dimensões de uma vez. Seis meses depois não há nada em produção e o negócio perdeu a fé no projeto. Kimball é claro: um processo de negócio por vez, entrega incremental, dimensões conformes reusadas entre eles.^[4] Quem tenta o big bang morre no meio.

Normalizar por reflexo de “boa prática de banco”

Quem vem de sistema transacional normaliza por instinto — quebra produto em três tabelas encadeadas porque “é o certo”. No mundo analítico isso cobra join extra em toda consulta e deixa o modelo ilegível para o pessoal de negócio.^[3] A regra inverte: no OLAP você desnormaliza a dimensão de propósito. Redundância de um nome de categoria repetido mil vezes é irrelevante; join a mais em toda pergunta, não.

Alimentar a fato com dado sujo e culpar o modelo

Star schema não limpa dado — ele propaga. Se o CRM tem canal nulo em metade dos deals e valor zerado, sua dim_canal nasce com um monte de “não identificado” e a fato de receita fica furada. Quando o número sai errado, o instinto é mexer no schema — mas o conserto mora lá atrás, no processo de captura, em quem preenche o CRM. Diagnostique a fonte antes de reengenheirar a estrela. (A única descrição que pode viver na fato de propósito é a degenerate dimension — um atributo como o número do pedido.^[2])

Checklist de implementação

Sua estrela precisa de quem monte a arquitetura, não de mais um painel

Quando cada pergunta vira um projeto e os números não batem entre áreas, o problema não se resolve com mais uma ferramenta de BI — resolve-se com quem senta, escolhe o processo, declara o grão e casa CRM com billing numa fonte única. É o que o time de RevOps da Incuca faz: estrutura a arquitetura de dados que faz NRR, CAC e forecast pararem de divergir, e deixa o modelo vivo mês a mês.