Ejemplo de modelo de datos en copo de nieve

En las bases de datos utilizadas en (data warehousing), un esquema en copo de nieve es una estructura algo más compleja que el esquema en estrella. Se da cuando alguna de las dimensiones se implementa con más de una tabla de datos. La finalidad es normalizar las tablas y así reducir el espacio de almacenamiento al eliminar la redundancia de datos; pero tiene la contrapartida de generar peores rendimientos al tener que crear más tablas de dimensiones y más relaciones entre las tablas (JOINS) lo que tiene un impacto directo sobre el rendimiento.

Introducción

En las aplicaciones OLAP implementadas sobre bases de datos relacionales (ROLAP), un elemento clave es el Cubo OLAP. Estos cubos (también llamados hipercubos) almacenan grandes volúmenes de datos que posteriormente deben ser analizados en función de unos determinados parámetros. Al diseñar las tablas en las que se han de almacenar estos datos y parámetros, si se aplican las técnicas de Normalización de bases de datos para optimizar el espacio requerido para guardar estos datos eliminando las redundancias, es habitual que se termine obteniendo un esquema en copo de nieve; en este tipo de esquemas se tiene una tabla central de hechos en la que se guardan las medidas del negocio que se quiere analizar, y en las tablas adyacentes se tendrán las dimensiones (parámetros) de que dependen los datos del negocio. Si por alguna dimensión se requiere más de una tabla se dice que el esquema resultante es un esquema en copo de nieve.

En el ejemplo de la figura adjunto, pese a no estar totalmente normalizada (por ejemplo, la tabla 'Dimension_Almacen' tiene redundancias) se observa como para algunas dimensiones de la tabla de hechos como Producto y Cliente se ha empleado más de una tabla, dando lugar a una jerarquía de dimensiones. Por ejemplo, los productos se pueden clasificar por marcas, además, estos mismos productos se pueden agrupar por categorías y subcategorías.

Argumentos a favor y en contra del esquema en copo de nieve

El único argumento a favor de los esquemas en copo de nieve es que al estar normalizadas las tablas de dimensiones, se evita la redundancia de datos y con ello se ahorra espacio. Pero si tenemos en cuenta que hoy en día, el espacio en disco no suele ser un problema, y sí el rendimiento, se presenta con una mala opción en Data warehouse, ya que el hecho de disponer de más de una tabla por cada dimensión de la tabla de hechos implica tener que realizar código más complejo para realizar una consulta que a su vez se ejecutará en un tiempo mayor, debido en parte al mayor número de uniones (JOINS) que habrá que realizar.

Se puede usar un esquema de copo de nieve en un Data warehouse, aunque estos sean realmente grandes y complejos, pero nunca en sistemas donde el tiempo de respuesta sea un factor crítico para los usuarios.

Véase también

• Almacén de datos
• Cubo OLAP
• Esquema en estrella
• OLAP
• ROLAP
• Tabla de hechos
• Tabla de dimensión

Enlaces externos

• ¿Estrella o copo de nieve?
• Designing the Star Schema Database (ver el apartado Snowflake Schemas)