Cómo modelar un esquema en copo de nieve en un Data Warehouse

Un esquema en copo de nieve (snowflake schema) organiza un Data Warehouse normalizando las dimensiones en tablas más pequeñas y enlazadas entre sí. El resultado es menos redundancia y dimensiones más fáciles de mantener, útil cuando una dimensión tiene muchos atributos repetidos, como categorías de producto o ubicaciones geográficas.

Requisitos previos

• Un Data Warehouse o base de datos relacional (SQL Server, Azure SQL, PostgreSQL, etc.).
• Conocer el concepto de esquema en estrella (star schema), con tabla de hechos y dimensiones.
• Nociones básicas de SQL (CREATE TABLE, JOIN, claves primarias y foráneas).

Paso 1: Entender la diferencia entre estrella y copo de nieve

En el esquema en estrella, cada dimensión es una única tabla "aplanada" (desnormalizada) que repite valores. En el esquema en copo de nieve, esa dimensión se divide en varias tablas relacionadas, siguiendo las reglas de la normalización. La tabla de hechos permanece en el centro; la diferencia está en cómo se ramifican las dimensiones.

Imagina una dimensión de producto que incluye categoría y subcategoría. En el modelo en estrella, el nombre de la categoría se repite en cada fila de producto. En el copo de nieve, la categoría pasa a su propia tabla y el producto guarda solo una clave.

Regla práctica: usa el copo de nieve para dimensiones grandes y muy repetitivas; mantén el esquema en estrella para dimensiones pequeñas donde la rapidez de las consultas es prioritaria.

Paso 2: Identificar la dimensión a normalizar

Elige una dimensión con atributos claramente jerárquicos o muy repetidos. Un buen candidato es Dim_Produto, que suele contener producto, subcategoría y categoría, una jerarquía natural de tres niveles. Separar estos niveles evita actualizar decenas o cientos de filas cuando cambia el nombre de una categoría, porque ese nombre pasa a existir en un solo lugar.

Paso 3: Crear las tablas normalizadas

Vamos a dividir la dimensión de producto en tres tablas enlazadas por claves foráneas: categoría, subcategoría y producto. Cada tabla usa una surrogate key (una clave numérica propia del Data Warehouse) como clave primaria, lo que mantiene los enlaces estables aunque cambien los identificadores de origen.

CREATE TABLE Dim_Categoria (
    categoria_key INT PRIMARY KEY,
    nome_categoria VARCHAR(100)
);

CREATE TABLE Dim_Subcategoria (
    subcategoria_key INT PRIMARY KEY,
    nome_subcategoria VARCHAR(100),
    categoria_key INT REFERENCES Dim_Categoria(categoria_key)
);

CREATE TABLE Dim_Produto (
    produto_key INT PRIMARY KEY,
    nome_produto VARCHAR(150),
    subcategoria_key INT REFERENCES Dim_Subcategoria(subcategoria_key)
);

Fíjate en la cadena: Dim_Produto apunta a Dim_Subcategoria, que a su vez apunta a Dim_Categoria. Esa ramificación es la que da la forma de copo de nieve.

Paso 4: Conectar la tabla de hechos

La tabla de hechos se conecta solo al nivel más detallado de la dimensión, en este caso Dim_Produto. Los niveles superiores se alcanzan a través de las tablas intermedias, siguiendo la cadena de claves.

CREATE TABLE Fact_Vendas (
    venda_key BIGINT PRIMARY KEY,
    produto_key INT REFERENCES Dim_Produto(produto_key),
    data_key INT,
    quantidade INT,
    valor_total DECIMAL(12,2)
);

Paso 5: Consultar los datos con JOINs

Para obtener las ventas por categoría, recorre la cadena de tablas con JOIN hasta llegar a la categoría:

SELECT c.nome_categoria,
       SUM(f.valor_total) AS total_vendas
FROM Fact_Vendas AS f
JOIN Dim_Produto AS p       ON f.produto_key = p.produto_key
JOIN Dim_Subcategoria AS s  ON p.subcategoria_key = s.subcategoria_key
JOIN Dim_Categoria AS c     ON s.categoria_key = c.categoria_key
GROUP BY c.nome_categoria
ORDER BY total_vendas DESC;

Fíjate en que el copo de nieve exige más JOIN que el esquema en estrella. A cambio, cada nombre de categoría existe una sola vez, lo que ahorra espacio y simplifica las actualizaciones. En las bases de datos analíticas modernas el coste de estos JOIN suele ser bajo, pero conviene probarlo con tu volumen real de datos.

Verificar el resultado

Para confirmar que el modelo es correcto, valida tres cosas:

• Cada subcategoria_key en Dim_Produto existe en Dim_Subcategoria (integridad referencial).
• La consulta del Paso 5 devuelve una fila por categoría, sin duplicados.
• No hay nombres de categoría repetidos en Dim_Categoria.

Puedes ejecutar esta comprobación rápida para detectar categorías duplicadas:

SELECT nome_categoria, COUNT(*) AS repeticoes
FROM Dim_Categoria
GROUP BY nome_categoria
HAVING COUNT(*) > 1;

Si la consulta no devuelve ninguna fila, no existen categorías repetidas y la normalización está bien hecha.

Conclusión

Ya sabes montar un esquema en copo de nieve: normalizas una dimensión en tablas enlazadas por claves foráneas y ajustas las consultas con JOIN adicionales. Usa este enfoque cuando el ahorro de espacio y la facilidad de mantenimiento compensen los joins extra; de lo contrario, el esquema en estrella puede ser más rápido y sencillo. ¿Cuál de tus dimensiones tiene más valores repetidos y sería la primera candidata a normalizar?