El esquema copo de nieve es una variante del esquema estrella donde las dimensiones se normalizan en múltiples tablas relacionadas. Aprende por qué raramente se usa en Power BI y cuándo podría tener sentido considerarlo.
Intermedio
❄️
¿Qué es el Esquema Copo de Nieve?
Normalización de dimensiones a varios niveles
El esquema copo de nieve (snowflake schema) es una extensión del esquema estrella donde las dimensiones se normalizan, dividiéndose en múltiples tablas relacionadas. En lugar de tener una tabla de dimensión "plana" con todos los atributos, estos se separan en sub-dimensiones conectadas entre sí.
El nombre es descriptivo: si dibujamos el modelo en un papel, el resultado no es una estrella limpia sino una figura más compleja con ramificaciones, como un copo de nieve.
Un ejemplo concreto:
Imagina una dimensión Producto que en star schema tendría todas las columnas en una sola tabla:
En snowflake, esa dimensión se fragmenta en jerarquías: Dim_Product → Dim_Subcategory → Dim_Category, donde cada nivel es una tabla separada con su propia clave primaria y foránea.
💡 Tip kawaii: Piénsalo como una muñeca rusa. En star schema abres la muñeca y ves todo de golpe. En snowflake, dentro de la muñeca hay otra muñeca, y dentro otra… más "puro" desde el punto de vista de bases de datos relacionales, pero más incómodo para el análisis.
🔄
Diferencias con Star Schema
La diferencia fundamental: normalización
La distinción clave entre ambos esquemas es el grado de normalización de las dimensiones. Star schema las aplana; snowflake las estructura en jerarquías de tablas.
⭐ Star Schema (Desnormalizado)
Una tabla por dimensión
Todos los atributos en la misma tabla
Redundancia de datos ("Electronics" se repite en miles de filas)
Simple de entender y consultar
Óptimo para rendimiento de consultas
Recomendado por Microsoft para Power BI
❄️ Snowflake Schema (Normalizado)
Dimensiones divididas en múltiples tablas
Atributos distribuidos en jerarquías
Sin redundancia (cada categoría aparece solo 1 vez)
Snowflake schema tiene ventajas reales… en el mundo de las bases de datos relacionales clásicas. El problema es que la mayoría de esas ventajas no se trasladan a Power BI.
✅ Ventajas (teóricas)
Menor espacio en disco: sin redundancia de datos
Integridad referencial más clara: jerarquías explícitas en la estructura
Actualizaciones eficientes: cambiar "Electronics" se hace en 1 fila, no en miles
Dimensiones reutilizables: la tabla Dim_Category puede compartirse entre múltiples esquemas
❌ Desventajas (en la práctica de BI)
Consultas más lentas: múltiples JOINs degradan el rendimiento en VertiPaq
Modelos más complejos: más tablas = más difícil de entender y mantener
DAX más complicado: navegar jerarquías requiere más código y más cuidado
Experiencia de usuario confusa: los usuarios ven 5 tablas donde deberían ver 1
Ahorro de espacio irrelevante: VertiPaq comprime tan bien que la redundancia casi no pesa
💡 Tip kawaii: Las ventajas del snowflake schema se diseñaron para sistemas OLTP (transaccionales), donde se insertan, actualizan y borran filas constantemente. En OLAP (analítico) como Power BI, el patrón de acceso es completamente diferente y esas ventajas dejan de ser relevantes.
⚠️
Por qué NO se recomienda en Power BI
Tres razones técnicas de peso
En Power BI específicamente, snowflake schema es una mala idea en el 95% de los casos. No es una opinión: hay razones técnicas concretas detrás de esta recomendación.
⚠️ Razón #1: VertiPaq hace la redundancia irrelevante
El motor VertiPaq de Power BI comprime los datos mediante codificación por diccionario. Los valores repetidos (como "Electronics" en miles de filas) no se almacenan miles de veces: se guardan una vez en un diccionario y el resto son punteros enteros. Resultado: la redundancia de datos en una dimensión desnormalizada ocupa prácticamente lo mismo que en una normalizada.
⚠️ Razón #2: Rendimiento degradado en DAX
Cada relación adicional que DAX tiene que cruzar añade coste computacional. En star schema, obtener la categoría de un producto es directo: FactVentas → DimProducto[Categoría]. En snowflake, DAX tiene que atravesar FactVentas → DimProducto → DimSubcategory → DimCategory, multiplicando la complejidad de la consulta. Esto se nota especialmente en modelos grandes y en informes con muchos filtros activos.
⚠️ Razón #3: Experiencia de usuario horrible
Los usuarios que crean sus propios informes (self-service BI) ven el panel de campos con 5 tablas donde deberían ver 1. Esto genera confusión, errores de uso y preguntas del tipo: "¿uso CategoryName de la tabla Category directamente, o tengo que ir por Product → Subcategory → Category?" El resultado es adopción más baja y más errores en los informes.
📌 Buena práctica: Si recibes datos de origen ya normalizados (snowflake), desnormalízalos en Power Query antes de cargar al modelo. Usa Merge Queries para aplanar las jerarquías en una sola tabla de dimensión. Tu modelo de datos en Power BI siempre debe aspirar al star schema.
🤔
Cuándo considerar Snowflake Schema
Los 3 escenarios donde podría tener sentido
Hay exactamente tres situaciones donde snowflake schema podría justificarse en Power BI. Son excepciones, no la norma.
1
Conectado en DirectQuery a un DW normalizado
Si tu fuente de datos ya está en snowflake schema y usas DirectQuery (no Import Mode), mantener la estructura normalizada puede tener sentido para no duplicar lógica en dos sitios. Pero incluso aquí, muchos expertos recomiendan crear una vista SQL desnormalizada en la fuente y apuntar a ella desde Power BI. DirectQuery con muchos JOINs puede ser muy lento.
2
Dimensiones conformadas compartidas entre múltiples tablas de hechos
Si tienes una tabla Dim_Producto usada por 5 tablas de hechos diferentes, y necesitas garantizar que todas compartan exactamente la misma jerarquía de categorías sin ninguna duplicación de lógica de transformación, snowflake podría justificarse. Pero esto es extremadamente raro en proyectos Power BI y normalmente se resuelve con una buena estrategia de Power Query compartida.
3
Dimensiones con decenas de millones de filas
Si tienes una dimensión con 50+ millones de filas y columnas de texto muy largas que se repiten (caso extremadamente inusual en dimensiones), la normalización podría ahorrar algo de memoria en escenarios muy específicos. Pero si has llegado aquí, tu diseño de dimensiones probablemente tiene problemas más profundos que revisar primero.
📌 Regla general kawaii: Si tienes dudas, usa star schema. El 99% de los proyectos Power BI funcionan mejor así. Solo considera snowflake si tienes una razón MUY específica, documentada, y has medido que los trade-offs merecen la pena.
📊
Ejemplo Visual Comparativo
Mismo caso: ventas de productos por categoría
Para ver la diferencia de forma concreta, modelemos el mismo escenario de dos maneras. El objetivo: poder analizar las ventas filtrando por categoría de producto.
Ventas Electrónica =
CALCULATE(
SUM(Fact_Sales[Amount]),
TREATAS(
SELECTCOLUMNS(
FILTER(Dim_Category,
Dim_Category[CategoryName]
= "Electronics"),
"SubcategoryID", Dim_Category[CategoryID]
),
Dim_Subcategory[CategoryID]
)
)
-- O navegar manualmente la cadena...
-- Más código, más margen de error
🚀 ¡Siguiente nivel! Ahora que entiendes por qué star schema es superior y en qué casos snowflake podría considerarse, profundiza en Esquema Estrella para aprender a implementarlo correctamente desde cero. O explora Relaciones en Power BI para dominar cómo se conectan las tablas en tu modelo de datos.