0Pricing
SQL Academy · Aula

Esquemas Estrela e Floco de Neve

Modele dados para análises rápidas.

Esquemas Estrela e Floco de Neve é uma aula grátis de SQL Academy 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 SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.

O que é um esquema de armazém de dados?

Em um banco de dados transacional (OLTP), você normaliza os dados para evitar redundância. Em um armazém de dados, muitas vezes você os desnormaliza intencionalmente — trocando espaço de armazenamento por velocidade de consulta. Dois padrões clássicos para organizar as tabelas de um armazém são o Esquema estrela e o Esquema floco de neve.

Ambos giram em torno de uma tabela de fatos central cercada por tabelas de dimensões. A diferença está no quanto você normaliza essas dimensões.

Tabelas de fatos e tabelas de dimensões

Uma tabela de fatos armazena eventos mensuráveis — vendas, cliques, remessas. Ela é extensa (muitas linhas) e contém medidas numéricas, além de chaves estrangeiras para as dimensões.

Uma tabela de dimensões descreve o contexto de cada evento: quem, o quê, quando, onde. As dimensões são mais estreitas (menos linhas), mas têm mais colunas descritivas.

CREATE TABLE fact_sales (
  sale_id      SERIAL PRIMARY KEY,
  date_key     INT NOT NULL,
  product_key  INT NOT NULL,
  customer_key INT NOT NULL,
  store_key    INT NOT NULL,
  quantity     INT NOT NULL,
  revenue      NUMERIC(12, 2) NOT NULL
);

CREATE TABLE dim_product (
  product_key  SERIAL PRIMARY KEY,
  product_name VARCHAR(200),
  category     VARCHAR(100),
  brand        VARCHAR(100),
  unit_price   NUMERIC(10, 2)
);

O esquema estrela

Em um esquema estrela, cada tabela de dimensões se conecta diretamente à tabela de fatos. Desenhe os relacionamentos no papel e você verá uma estrela — a tabela de fatos é o centro, e as dimensões são as pontas.

As tabelas de dimensões são totalmente desnormalizadas: todos os atributos descritivos residem em uma única tabela, mesmo que alguns atributos se repitam entre as linhas.

-- Star schema: all product info in one flat dimension table
CREATE TABLE dim_product (
  product_key    SERIAL PRIMARY KEY,
  product_name   VARCHAR(200),
  category_name  VARCHAR(100),   -- denormalized
  subcategory    VARCHAR(100),   -- denormalized
  brand_name     VARCHAR(100),   -- denormalized
  brand_country  VARCHAR(100),   -- denormalized
  unit_price     NUMERIC(10, 2)
);

CREATE TABLE dim_date (
  date_key   INT PRIMARY KEY,   -- e.g. 20240315
  full_date  DATE,
  year       INT,
  quarter    INT,
  month      INT,
  month_name VARCHAR(20),
  week       INT,
  day_of_week VARCHAR(10)
);

Consulta de esquema estrela

As tabelas de dimensões planas tornam as consultas simples. Você faz a junção da tabela de fatos com uma ou mais dimensões e agrega os dados. Não há junções secundárias por meio de cadeias de tabelas normalizadas.

É por isso que os esquemas estrela oferecem consultas analíticas rápidas — o grafo de junções é raso.

SELECT
  d.year,
  d.quarter,
  p.category_name,
  SUM(f.revenue)   AS total_revenue,
  SUM(f.quantity)  AS units_sold
FROM fact_sales f
JOIN dim_date    d ON d.date_key    = f.date_key
JOIN dim_product p ON p.product_key = f.product_key
WHERE d.year = 2024
GROUP BY d.year, d.quarter, p.category_name
ORDER BY d.quarter, total_revenue DESC;

O esquema em floco de neve

Um esquema em floco de neve normaliza ainda mais as tabelas de dimensão, dividindo-as em subdimensões. Por exemplo, em vez de armazenar category_name e brand_name dentro de dim_product, criam-se tabelas separadas dim_category e dim_brand.

O diagrama resultante se parece com um floco de neve — ramificações de tabelas relacionadas.

-- Snowflake schema: product dimension is normalized
CREATE TABLE dim_brand (
  brand_key     SERIAL PRIMARY KEY,
  brand_name    VARCHAR(100),
  brand_country VARCHAR(100)
);

CREATE TABLE dim_category (
  category_key   SERIAL PRIMARY KEY,
  category_name  VARCHAR(100),
  subcategory    VARCHAR(100)
);

CREATE TABLE dim_product (
  product_key  SERIAL PRIMARY KEY,
  product_name VARCHAR(200),
  category_key INT REFERENCES dim_category(category_key),
  brand_key    INT REFERENCES dim_brand(brand_key),
  unit_price   NUMERIC(10, 2)
);

Consulta ao esquema em floco de neve

Consultar um esquema em floco de neve exige mais junções para remontar os dados de dimensão que foram divididos entre as tabelas. O otimizador de consultas precisa percorrer os níveis adicionais, o que pode aumentar a latência em comparação com um esquema estrela.

No entanto, as dimensões normalizadas são menores e consistentes — atualizar o nome de uma marca em uma linha de dim_brand aplica a alteração automaticamente em todos os lugares.

SELECT
  d.year,
  c.category_name,
  b.brand_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales    f
JOIN dim_date      d ON d.date_key    = f.date_key
JOIN dim_product   p ON p.product_key = f.product_key
JOIN dim_category  c ON c.category_key = p.category_key
JOIN dim_brand     b ON b.brand_key    = p.brand_key
WHERE d.year = 2024
GROUP BY d.year, c.category_name, b.brand_name
ORDER BY total_revenue DESC;

Chaves substitutas vs. chaves naturais

As tabelas de dimensão normalmente usam uma chave substituta — um inteiro gerado pelo armazém de dados (por exemplo, SERIAL) — em vez de uma chave natural do sistema de origem.

As chaves substitutas permanecem estáveis mesmo quando a origem muda, são compactas para tabelas de fatos grandes e permitem trabalhar com dimensões de alteração lenta, nas quais o histórico precisa ser acompanhado.

-- Surrogate key (product_key) vs natural key (sku)
INSERT INTO dim_product (product_name, category_key, brand_key, unit_price)
VALUES ('Wireless Headphones', 3, 7, 89.99);
-- product_key is assigned by SERIAL -- the natural key (SKU) lives elsewhere

-- Natural key would be:
-- INSERT INTO dim_product (sku, product_name, ...)
-- VALUES ('WH-1000XM5', 'Wireless Headphones', ...);
-- Risky: SKU can be reused or reassigned by the source system

A dimensão de data

A dimensão de data é especial — quase sempre está presente e geralmente é pré-populada com datas de muitos anos. Armazenar atributos derivados (ano, trimestre, nome do mês, período fiscal, indicador de feriado) na tabela de dimensão evita recalculá-los no momento da consulta.

-- Populate dim_date for one year using generate_series
INSERT INTO dim_date (date_key, full_date, year, quarter, month, month_name, week, day_of_week)
SELECT
  TO_CHAR(d, 'YYYYMMDD')::INT  AS date_key,
  d                             AS full_date,
  EXTRACT(YEAR    FROM d)::INT  AS year,
  EXTRACT(QUARTER FROM d)::INT  AS quarter,
  EXTRACT(MONTH   FROM d)::INT  AS month,
  TO_CHAR(d, 'Month')           AS month_name,
  EXTRACT(WEEK    FROM d)::INT  AS week,
  TO_CHAR(d, 'Day')             AS day_of_week
FROM generate_series('2024-01-01'::DATE, '2024-12-31'::DATE, '1 day') AS d;

Dimensões de alteração lenta (SCD Tipo 2)

O que acontece quando um cliente muda de cidade ou um produto muda de categoria? É preciso acompanhar o histórico. A SCD Tipo 2 insere uma nova linha de dimensão para cada alteração e encerra a anterior com uma data de término. A linha da tabela de fatos continua apontando para a chave de dimensão antiga, preservando a precisão histórica.

-- SCD Type 2 customer dimension
CREATE TABLE dim_customer (
  customer_key  SERIAL PRIMARY KEY,
  customer_id   INT NOT NULL,
  customer_name VARCHAR(200),
  city          VARCHAR(100),
  country       VARCHAR(100),
  valid_from    DATE NOT NULL,
  valid_to      DATE,
  is_current    BOOLEAN DEFAULT TRUE
);

-- When a customer moves, close old row and insert new one:
UPDATE dim_customer
   SET valid_to = CURRENT_DATE - 1, is_current = FALSE
 WHERE customer_id = 42 AND is_current = TRUE;

INSERT INTO dim_customer (customer_id, customer_name, city, country, valid_from, is_current)
VALUES (42, 'Alice Muller', 'Berlin', 'Germany', CURRENT_DATE, TRUE);

Estrela vs. floco de neve — vantagens e desvantagens

Nenhum dos dois esquemas é universalmente melhor. Escolha com base nas suas prioridades:

  • Estrela — menos junções, consultas mais rápidas, ETL mais simples e maior custo de armazenamento. Melhor para ferramentas de análise com muitas leituras (Tableau, Power BI).
  • Floco de neve — dimensões normalizadas, menos redundância e atualizações de dimensão mais fáceis, mas com mais junções. Melhor quando as dimensões são grandes ou compartilhadas por várias tabelas de fatos.
-- Checking how much storage the denormalized category column costs
-- in a large dim_product (star schema) vs a separate dim_category (snowflake)
SELECT
  COUNT(*)                               AS total_products,
  COUNT(DISTINCT category_name)          AS unique_categories,
  pg_size_pretty(
    SUM(pg_column_size(category_name))
  )                                      AS category_storage
FROM dim_product;

Esquema de galáxia (constelação de fatos)

Quando um armazém de dados tem várias tabelas de fatos que compartilham tabelas de dimensão, o resultado é chamado de esquema de galáxia (ou constelação de fatos). Por exemplo, um armazém de dados do varejo pode ter tabelas de fatos separadas para vendas e devoluções, ambas referenciando dim_product e dim_date.

As dimensões compartilhadas garantem uma filtragem consistente e tornam simples as comparações entre fatos.

CREATE TABLE fact_returns (
  return_id     SERIAL PRIMARY KEY,
  date_key      INT NOT NULL REFERENCES dim_date(date_key),
  product_key   INT NOT NULL REFERENCES dim_product(product_key),
  customer_key  INT NOT NULL,
  quantity      INT NOT NULL,
  refund_amount NUMERIC(12, 2) NOT NULL
);

-- Cross-fact query: net revenue = sales - refunds
SELECT
  d.year,
  d.month,
  SUM(s.revenue)       AS gross_revenue,
  SUM(r.refund_amount) AS total_refunds,
  SUM(s.revenue) - COALESCE(SUM(r.refund_amount), 0) AS net_revenue
FROM dim_date d
LEFT JOIN fact_sales   s ON s.date_key = d.date_key
LEFT JOIN fact_returns r ON r.date_key = d.date_key
WHERE d.year = 2024
GROUP BY d.year, d.month
ORDER BY d.month;

Esquema estrela vs. esquema em floco de neve

Teste seus conhecimentos sobre esquemas estrela e em floco de neve.

Recapitulação da lição

Nesta lição, você explorou dois padrões fundamentais de projeto de armazéns de dados:

  • Esquema estrela — uma tabela de fatos central cercada por tabelas de dimensão planas e desnormalizadas. Menos junções, consultas mais rápidas e um pouco mais de armazenamento.
  • Esquema em floco de neve — as tabelas de dimensão são ainda mais normalizadas em subdimensões. Menos redundância e atualizações mais fáceis, mas são necessárias mais junções.
  • Tabelas de fatos armazenam eventos mensuráveis; tabelas de dimensão fornecem contexto (quem, o quê, quando e onde).
  • Chaves substitutas protegem a precisão histórica e desacoplam o armazém de dados das alterações no sistema de origem.
  • SCD Tipo 2 acompanha o histórico das dimensões adicionando novas linhas com datas de validade, em vez de substituir as antigas.
  • Quando várias tabelas de fatos compartilham dimensões, o projeto se torna um esquema de galáxia (constelação de fatos).

Escolha o esquema estrela pela simplicidade e velocidade; escolha o esquema em floco de neve quando as dimensões forem grandes, atualizadas com frequência ou compartilhadas por muitas tabelas de fatos.

Perguntas Frequentes

A aula “Esquemas Estrela e Floco de Neve” é grátis?

Sim — o texto completo de “Esquemas Estrela e Floco de Neve” é 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 SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.

O que vou aprender em “Esquemas Estrela e Floco de Neve”?

Modele dados para análises rápidas. Você pratica SQL Academy 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 SQL Academy?

Nenhuma experiência prévia é necessária. SQL Academy 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 “Esquemas Estrela e Floco de Neve”?

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 SQL Academy?

Sim. Cada aula de SQL Academy 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

  1. OLTP vs OLAP
  2. Tabelas de Fatos e Dimensões
  3. Esquemas Estrela e Floco de Neve
  4. Escrevendo Consultas Analíticas
← Voltar para SQL Academy