Esquema estrela e projeto de armazém de dados
Tabelas de fatos e dimensões, compromissos da desnormalização e modelagem OLAP.
Esquema estrela e projeto de armazém de dados é uma aula grátis de Coding Interview Prep no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Coding Interview Prep, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Coding Interview Prep inclui 4 aulas no total.
OLTP versus OLAP
As perguntas sobre armazéns de dados começam com uma distinção que os entrevistadores esperam que você domine: OLTP versus OLAP.
- OLTP (transacional): muitas leituras/gravações pequenas, altamente normalizado para garantir a integridade. Dá suporte ao aplicativo.
- OLAP (analítico): poucas leituras grandes, que fazem agregações sobre o histórico, deliberadamente desnormalizado para obter velocidade. Dá suporte a relatórios e painéis.
Os esquemas estrela são um projeto de OLAP. O objetivo é realizar consultas analíticas rápidas, aceitando redundância em troca disso.
Fatos e dimensões
Um esquema estrela divide os dados em dois tipos de tabelas:
- Tabela de fatos: os eventos ou transações mensuráveis (uma venda, um clique). Contém medidas numéricas e chaves estrangeiras para as dimensões.
- Tabelas de dimensões: o contexto descritivo pelo qual você segmenta os dados (data, produto, cliente, loja).
A tabela de fatos fica no centro; as dimensões a rodeiam como as pontas de uma estrela, daí o nome.
Anatomia de uma tabela de fatos
Uma tabela de fatos é composta principalmente por chaves estrangeiras e medidas numéricas. Ela é longa e estreita e cresce continuamente.
Medidas são números aditivos que você agrega: quantidade, receita, custo. A granularidade (uma linha = um ?) deve ser declarada com clareza; aqui, uma linha representa uma linha de produto em uma venda.
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
date_key INT NOT NULL, -- FK to dim_date
product_key INT NOT NULL, -- FK to dim_product
customer_key INT NOT NULL, -- FK to dim_customer
store_key INT NOT NULL, -- FK to dim_store
quantity INT, -- measure
revenue DECIMAL(12,2), -- measure
cost DECIMAL(12,2) -- measure
);Anatomia de uma tabela de dimensões
As dimensões são curtas e largas: têm muitas colunas descritivas pelas quais você filtra e agrupa os dados. Elas são intencionalmente desnormalizadas para que uma consulta precise de apenas uma junção por dimensão.
Observe que dim_product mantém a categoria e a marca na mesma linha, em vez de mantê-las em tabelas separadas. Essa redundância é justamente o objetivo: ela evita junções extras no momento da consulta.
CREATE TABLE dim_product (
product_key INT PRIMARY KEY, -- surrogate key
product_id INT, -- natural/business key
product_name VARCHAR(100),
category VARCHAR(50), -- denormalized
brand VARCHAR(50), -- denormalized
unit_price DECIMAL(10,2)
);Uma consulta em um esquema estrela
É isso que o projeto proporciona. Uma consulta analítica típica faz junções entre a tabela de fatos e algumas dimensões, filtra e agrega os dados. Uma junção por dimensão, sem cadeias profundas.
Os entrevistadores pedem que você escreva exatamente esse tipo de consulta em um esquema estrela.
SELECT d.category,
t.year,
SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date t ON t.date_key = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;Chaves substitutas
As dimensões usam uma chave substituta: uma chave primária inteira sem significado de negócio (como product_key) gerada pelo armazém de dados, separada da chave natural do sistema de origem.
Por que isso é importante para os entrevistadores:
- Isso desacopla o armazém de dados de chaves de negócio que podem mudar.
- Isso mantém as tabelas de fatos estreitas (junções entre inteiros são rápidas).
- Isso é necessário para acompanhar o histórico com dimensões que mudam lentamente (na próxima cena).
Dimensões que mudam lentamente
Um tema muito comum em entrevistas sobre armazéns de dados: quando um atributo de dimensão muda (um cliente muda de cidade), como você trata essa mudança? Essas são as dimensões que mudam lentamente (SCD):
- Tipo 1: substitua o valor antigo. Sem histórico.
- Tipo 2: adicione uma nova linha com datas de vigência e um indicador de registro atual. Histórico completo; isso exige chaves substitutas.
- Tipo 3: mantenha uma coluna de “valor anterior”. Histórico limitado.
O Tipo 2 é a resposta mais esperada para acompanhar mudanças ao longo do tempo.
-- SCD Type 2 dimension
CREATE TABLE dim_customer (
customer_key INT PRIMARY KEY, -- surrogate
customer_id INT, -- natural key
city VARCHAR(50),
valid_from DATE,
valid_to DATE,
is_current BOOLEAN
);Estrela versus floco de neve
Espere uma pergunta de comparação. Um esquema floco de neve normaliza as dimensões em subtabelas (produto -> categoria -> departamento), enquanto um esquema estrela as mantém planas.
- Estrela: menos junções, leituras mais rápidas e alguma redundância. É preferível para o desempenho das consultas.
- Floco de neve: menos armazenamento e manutenção mais fácil das dimensões, mas mais junções por consulta.
Diga: “Por padrão, use o esquema estrela para obter velocidade nas consultas; use o esquema floco de neve apenas quando as dimensões forem grandes e reutilizadas.”
A dimensão de datas
Quase todo esquema estrela tem uma dimensão de datas dedicada, em vez de uma coluna de data bruta. Ela pré-calcula ano, trimestre, mês, dia da semana, indicadores de feriados e períodos fiscais.
Isso permite que os analistas agrupem por “trimestre fiscal” ou “é_fim_de_semana” usando uma simples junção, em vez de espalhar funções de data pelo código. Mencionar uma dimensão de datas sem ser solicitado é um forte sinal de que você já criou armazéns de dados.
CREATE TABLE dim_date (
date_key INT PRIMARY KEY, -- e.g. 20250131
full_date DATE,
year INT,
quarter INT,
month INT,
day_of_week VARCHAR(10),
is_weekend BOOLEAN,
fiscal_qtr VARCHAR(6)
);Escolhendo a granularidade
A decisão mais importante sobre uma tabela de fatos é a granularidade: o que cada linha representa. Declare isso antes de qualquer outra coisa.
- Granularidade muito grossa (uma linha por dia e por loja) faz você perder detalhes.
- Granularidade muito fina (uma linha por item escaneado) faz a tabela explodir.
Uma declaração clara de granularidade, como “uma linha por produto em cada linha do pedido”, determina quais dimensões e medidas pertencem ao modelo. Os entrevistadores prestam atenção a essa disciplina.
Quando desnormalizar
Relacione isso à normalização. Os sistemas OLTP são normalizados até a 3FN para garantir a integridade; os armazéns de dados desnormalizam deliberadamente as dimensões para obter velocidade nas leituras.
A compensação que você deve saber explicar:
- Dados redundantes nas dimensões são aceitáveis porque o armazém de dados é carregado por ETL controlado, e não por gravações improvisadas do aplicativo.
- Menos junções significam agregações mais rápidas sobre bilhões de linhas de fatos.
É o julgamento, e não a regra, que diferencia as respostas de nível sênior neste caso.
Verificação rápida
Você está projetando um armazém de dados de vendas e precisa manter o histórico completo da cidade de um cliente quando ele se muda.
Recapitulação: esquema estrela e projeto de armazém de dados
Agora você consegue responder a perguntas sobre modelagem de armazéns de dados:
- OLTP normaliza para garantir a integridade; OLAP desnormaliza para obter velocidade nas leituras.
- Um esquema estrela tem uma tabela de fatos central (chaves estrangeiras + medidas numéricas) cercada por dimensões planas.
- Use chaves substitutas e uma dimensão de datas dedicada.
- Acompanhe mudanças com o SCD Tipo 2; declare primeiro a granularidade dos fatos.
- Prefira o esquema estrela ao esquema floco de neve para obter melhor desempenho nas consultas.
Perguntas Frequentes
A aula “Esquema estrela e projeto de armazém de dados” é grátis?
Sim — o texto completo de “Esquema estrela e projeto de armazém de dados” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Coding Interview Prep, atualize para CoddyKit PRO. O curso de Coding Interview Prep inclui 4 aulas no total.
O que vou aprender em “Esquema estrela e projeto de armazém de dados”?
Tabelas de fatos e dimensões, compromissos da desnormalização e modelagem OLAP. Você pratica Coding Interview Prep com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Coding Interview Prep?
Nenhuma experiência prévia é necessária. Coding Interview Prep no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.
Quanto tempo leva a aula “Esquema estrela e projeto de armazém de dados”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Coding Interview Prep?
Sim. Cada aula de Coding Interview Prep inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Normalização até a 3FN
- Modelagem ER e cardinalidade de relacionamentos
- Esquema estrela e projeto de armazém de dados
- Conjunto completo de problemas de entrevista simulada