Star, Snowflake e Factless: Treine para Decidir como Modelar seu Data Warehouse

Poucas decisões de modelagem têm tanto impacto no dia a dia de um time de dados quanto a escolha do modelo do Data Warehouse. Ela influencia a estrutura das consultas, quanto tempo um analista leva para entender o modelo e se o dashboard responde em segundos ou em minutos. Mesmo assim, muita gente escolhe por hábito: quem vem de bancos transacionais tende a normalizar tudo, porque foi assim que aprendeu.

Neste artigo você vai treinar. São cinco missões, com XP, feedback imediato e um comparador de consultas que mostra o custo real de cada escolha. No final, um rank e um quiz de revisão. Reserve de 15 a 20 minutos.

Aquecimento: fatos, dimensões e a pergunta de negócio

A modelagem dimensional parte de uma ideia simples: todo evento de negócio (uma venda, uma presença, um clique) tem medidas (valores numéricos, como o valor da venda) e contexto (quem, o quê, onde, quando). As medidas ficam na tabela fato; o contexto fica nas dimensões. Star, Snowflake e Factless são variações dessa mesma estrutura, mas não são três opções mutuamente exclusivas: elas respondem a duas perguntas diferentes.

Um lembrete antes de começar: o nível de detalhe de cada linha da fato é o grão da tabela fato, e ele deve ser definido antes de escolher qualquer modelo. Se o grão está confuso, nenhum desenho de estrela vai salvar o resultado.

Decisão 1: o que a tabela fato registra? Medidas numéricas (valor, quantidade) ou apenas a ocorrência de um evento ou relação (um aluno esteve em uma aula)? Esse segundo caso é a Factless Fact Table, uma fato sem medidas numéricas.

Decisão 2: como as dimensões são organizadas? Desnormalizadas, em uma tabela larga por dimensão (Star Schema), ou normalizadas, divididas em várias tabelas (Snowflake Schema)?

Como as perguntas são independentes, uma fato factless pode participar de um esquema estrela ou de um esquema com dimensões normalizadas. Vamos ensinar nessa ordem.

Parte 1: conheça as três abordagens

Missão 1

Explore as três abordagens

Clique em cada abordagem para ver o diagrama, a ideia central e quando considerá-la. Objetivo: explorar as três.

Star SchemaDimensões desnormalizadas Snowflake SchemaDimensões normalizadas Factless Fact TableFato sem medida numérica

Selecione uma abordagem acima para ver os detalhes.

0 de 3 abordagens exploradas.

Repare que o Star Schema e o Snowflake descrevem a organização das dimensões e podem compartilhar exatamente a mesma tabela fato. Já a Factless Fact Table descreve a natureza da fato: ela registra que algo aconteceu, sem nenhum valor para somar, e pode combinar com qualquer um dos dois esquemas.

Parte 2: fato, dimensão ou medida?

Antes de escolher entre modelos, é preciso saber ler cada peça. Imagine a pergunta de negócio: "Quanto vendemos por produto, loja e mês?". Classifique cada elemento do modelo que responde a ela.

Missão 2

Fato, dimensão ou medida?

Classifique cada elemento. A explicação aparece logo após cada resposta.

fato_vendas, com uma linha para cada item vendido.

Tabela fato Dimensão Medida (coluna da fato)

dim_produto, com nome, categoria e marca.

Tabela fato Dimensão Medida (coluna da fato)

O valor da venda (coluna valor).

Tabela fato Dimensão Medida (coluna da fato)

dim_tempo, com data, mês e ano.

Tabela fato Dimensão Medida (coluna da fato)

A quantidade de itens vendidos.

Tabela fato Dimensão Medida (coluna da fato)

dim_loja, com nome e estado.

Tabela fato Dimensão Medida (coluna da fato)

0 de 6 respondidos.

Parte 3: duas decisões, duas perguntas

Agora o treino fica mais parecido com o trabalho real. O infográfico traz regras de bolso: Star Schema como padrão, Snowflake quando a dimensão for muito grande e Factless para evento sem medida numérica. São bons pontos de partida, mas lembre-se de que respondem a perguntas diferentes: primeiro, o que a fato registra?; depois, como organizar as dimensões?. Em cada cenário abaixo, repare qual das duas decisões está em jogo.

Missão 3

Qual decisão você está tomando?

Cada cenário trata da fato (o que ela registra) ou das dimensões (como se organizam). Escolha a melhor resposta.

A fato: faturamento por produto, loja e mês. A tabela precisa guardar valor e quantidade vendida.

Fato com medidas numéricas Factless (sem medidas)

A fato: registrar a presença de alunos em aulas. Não há valor numérico para somar.

Fato com medidas numéricas Factless (sem medidas)

A fato: registrar em quais campanhas cada usuário clicou, sem nenhum valor associado ao clique.

Fato com medidas numéricas Factless (sem medidas)

A fato: registrar quais produtos estavam disponíveis em cada loja em cada dia, mesmo sem vendas.

Fato com medidas numéricas Factless (sem medidas)

As dimensões: uma equipe de BI nova quer simplicidade, manutenção fácil e dimensões de tamanho normal.

Desnormalizadas (Star) Normalizadas (Snowflake)

As dimensões: o catálogo de produtos é enorme, com milhares de atributos e hierarquias complexas, e a redundância está pesando.

Desnormalizadas (Star), sem avaliar nada Vale avaliar normalizar (Snowflake)

Uma factless de presença em aula, com a dimensão de disciplina pequena, pode usar qual organização de dimensões?

Só Star Só Snowflake Qualquer uma das duas

0 de 7 respondidos.

Parte 4: compare a estrutura das consultas

Teoria é uma coisa; escrever a consulta é outra. No comparador abaixo, execute os três exemplos e observe o SQL que cada um exige. Para vendas por categoria, marca, cidade e mês, o exemplo estrela usa 3 joins e o exemplo snowflake usa 5. Esses números são exemplos, não características universais: o número de joins depende do desenho do modelo e da pergunta feita.

Importante: esta atividade compara a estrutura das consultas (quantas tabelas entram e como elas se ligam). Ela não executa benchmarks, e contar joins, sozinho, não mede desempenho. O impacto real depende do volume de dados, dos índices, do otimizador e do motor que você usa; para decidir, meça no seu ambiente.

Missão 4

Comparador de estrutura das consultas

Execute os três exemplos para comparar o SQL, o número de tabelas envolvidas e o trade-off de cada desenho. Nenhum deles mede tempo de execução.

Executar: Star Schema Executar: Snowflake Schema Executar: Factless (dimensões em estrela)

0 de 3 exemplos executados. Rode todos para comparar.

O comparativo do infográfico, em tabela. Leia como tendências e pontos de partida, não como garantias:

Parte 5: diagnostique erros comuns

O erro mais frequente em Data Warehouse não é técnico, é de hábito: normalizar dimensão por reflexo de quem vem de OLTP. Em sistemas transacionais, eliminar redundância protege a integridade dos dados. Em um Data Warehouse, o objetivo é outro: responder perguntas de negócio com simplicidade e boa performance. Nos casos abaixo, aponte o problema que você enxerga.

Missão 5

Diagnostique o modelo

Cada caso descreve um sintoma. Escolha a causa mais provável.

Todas as dimensões foram normalizadas 'por reflexo' de quem vem de OLTP, inclusive as pequenas, e agora cada consulta junta muitas tabelas sem nenhum ganho visível.

Normalizou dimensão por reflexo Grão indefinido Faltou uma factless Faltou dim_tempo

A fato_presenca tem grão 'um aluno, em uma aula, em uma data', mas a mesma presença foi inserida duas vezes, e as contagens saem infladas.

Faltou normalizar as dimensões Linhas duplicadas: o grão não está sendo respeitado Faltou dim_tempo Deveria ser Star em vez de factless

A tabela fato mistura linhas por pedido e linhas por item de pedido, e os totais saem duplicados.

Grão misturado Faltou uma factless Faltou Snowflake Dimensão desnormalizada

O time quer saber quais produtos estavam disponíveis em cada dia e não venderam, mas só guarda vendas: dias sem venda 'somem'.

Normalizou demais Faltou uma factless de cobertura para comparar com as vendas Grão fino demais Usou Star onde precisava Snowflake

0 de 4 respondidos.

O que não aconteceu: cobertura x atividade

Há dois usos clássicos de factless: registrar eventos (presença, clique, agendamento) e registrar cobertura (o que estava disponível ou elegível, por exemplo produtos em promoção em cada loja e dia). A tabela de cobertura sozinha mostra as possibilidades. Para achar o que estava disponível e não aconteceu, compare-a com a tabela de atividade, por exemplo com um LEFT JOIN e um filtro para as linhas sem correspondência:

SELECT c.id_produto, c.id_loja, c.id_tempo
FROM fato_cobertura c
LEFT JOIN fato_vendas v
  ON  v.id_produto = c.id_produto
  AND v.id_loja    = c.id_loja
  AND v.id_tempo   = c.id_tempo
WHERE v.id_produto IS NULL;

O resultado lista os produtos que estavam disponíveis, em cada loja e dia, mas não tiveram venda registrada.

Resumindo o treino

As três abordagens servem à mesma pergunta de fundo: como organizar os dados para que o negócio consiga fazer perguntas e obter respostas? Mas elas não são alternativas entre si: duas descrevem as dimensões e uma descreve a fato.

• Star Schema: organização de dimensões desnormalizadas, ponto de partida na maioria dos casos. Simples e fácil de manter.
• Snowflake Schema: organização de dimensões normalizadas. Vale avaliar quando a dimensão é muito grande ou tem hierarquias complexas, pesando redundância, volume e complexidade; meça antes de decidir.
• Factless Fact Table: um tipo de tabela fato, sem medidas numéricas, para eventos e coberturas (presença, disponibilidade, clique, agendamento). Pode participar de um esquema estrela ou snowflake.

Em resumo: responda duas perguntas, nesta ordem. A fato registra medidas ou só ocorrências? As dimensões ficam desnormalizadas ou serão normalizadas? Comece pelo mais simples, normalize quando houver motivo claro e medido, e lembre-se do lema que fecha o infográfico: menos teoria, mais dados no mundo real.