¿Estrella o copo de nieve?

A todos nos ha pasado: empezamos un nuevo proyecto y nos enfrentamos al diseño de un nuevo datamart… es importante hacerlo bien, porque será la base para nuestros cubos OLAP. ¿Debemos diseñar el almacenamiento relacional subyacente en estrella, o en copo de nieve? Lo cierto es que sobre este tema han corrido ríos de tinta, y sin embargo parece que aún hay discusiones. ¿Cual es la elección correcta?

Una variable multidimensional, dos bases de datos

Lo primero para decantarse por uno u otro diseño es tener bien claro cómo se almacena una variable multidimensional. La mejor forma de comprender la naturaleza de una variable multidimensional es compararlo con un sistema cartesiano.

  • Las dimensiones, son los ejes del sistema.
  • Los hechos, son los "puntos" que vamos a ubicar en esos ejes.
  • Estos "puntos" deben colocarse en coordenadas enteras dentro de los ejes cartesianos: jamás en coordenadas que se representen por medio de fracciones. Como muchos de los "puntos" que queremos representar contienen "fracciones" en sus coordenadas, tenemos que agregarlos para llegar a representarlos en el sistema. Tanto estos "puntos", como los distintos valores que puede tomar una coordenada, se cargan de una base de datos relacional (el datamart).
  • Las dimensiones de una variable multidimensional tienen "niveles". Para cada nivel sucesivo, las coordenadas cartesianas de esa dimensión se "espacian", de forma que los puntos a representar deben establecerse en un sistema "menos preciso". Por lo tanto, es necesario volver a agregarlos.

Por lo tanto, el espacio ocupado por un volumen multidimensional viene condicionado por:

  • Los hechos (puntos) que queremos representar.
  • El número de dimensiones de ese "volumen cartesiano" (los más puristas me diréis que no es un "volumen", sino un sistema… pero bueno, si nos ponemos puristas tampoco hablaríamos de cubos, sino de hipercubos, ¿no?)
  • El número de distintos valores que puede tomar cada dimensión (cómo de "espaciada" esté la componente cartesiana que sitúa un punto en esa dimensión).
  • El número de niveles de una dimensión, considerando a su vez la colección de posibles valores de ese nuevo nivel.

Los metadatos que dan la forma al cubo, y los agregados que constituyen el conjunto de puntos representado sobre el sistema cartesiano se almacenan en un volumen de datos multidimensional (por ejemplo, lo que sería la base de datos de Analysis Services). Los hechos que queremos agregar en el espacio multidimensional y los valores que pueden adoptar cada una de las coordenadas del sistema cartesiano, se cargan de una base de datos relacional (el datamart, que iría soportado, por ejemplo, sobre SQL Server).

Para aquellos a los que os queden dudas acerca de cómo se representa una variable multidimensional, os recuerdo que leáis el artículo de mi amigo y excelente divulgador Manuel de la Herran "Cómo diseñar grandes variables en bases de datos multidimensionales" (http://www.redcientifica.com/doc/doc200104190004.html).

Bien, ahora ya podemos empezar a entender las razones para adaptar un diseño en estrella o en copo de nieve.

La belleza de lo simple

Todo diseñador novel que se precie, y que venga del mundo relacional, tendrá una tendencia "natural" a normalizar… y aunque nos parezca mentira, lo más normal es al estudiar lo que será una dimensión, nos salga normalizada. Generalmente, por cada nivel de una dimensión, nos saldrá una tabla en el modelo relacional. Sin embargo, aunque el diseño más fácil de entender para un desarrollador sea el de un conjunto de dimensiones normalizadas (copo de nieve), fijaros en cómo trabaja un analista de negocio sobre Excel… EXACTO: no normaliza en exceso. Si está separando hombres de mujeres en una lista, escribe "Hombre" y "Mujer" al lado de cada nombre: no escribe un 1 o un 2, y pone una nota a pie de página que dice "Leyenda: ver tabla de codificación del género". Los modelos normalizados son fáciles de entender para las máquinas, pero difíciles de leer para el hombre. He aquí la primera razón para no normalizar las dimensiones: una estrella es mucho más fácil de comprender y manejar que un copo de nieve.

Unos cuantos tópicos sobre las estrellas y los copos de nieve

En general, si uno busca por Internet, las razones que esgrimen los defensores de cada uno de los diseños, son las siguientes:

  • El modelo en copo de nieve requiere menos espacio de almacenamiento. Esto es falso casi en todos los casos. Si nos fijamos en el conjunto de agregados de una variable multidimensional (el volumen del que os he hablado al comienzo del post) veremos que el número de valores disitintos que adopta una dimensión, así como el número de niveles de la misma, ES INDEPENDIENTE del DISEÑO relacional subyacente. Tenemos el mismo número de niveles y tenemos el mismo número de valores posibles para las coordenadas en esa dimensión, con lo que el espacio del volumen multidimensional ES EL MISMO. Bien, ¿entonces por qué he insinuado que esta frase es correcta para algunos casos? Aunque el volumen multidimensional de espacio que consumirá esa dimensión es el mismo, no es el mismo el espacio RELACIONAL que consumirá la dimensión en el datamart desde la que se carga. Si tenemos dimensiones EXTREMADAMENTE GRANDES, y en la que muchos atributos de la dimensión se encuentran repetidos o son nulos para determinados tipos de valores, al normalizar esta dimensión, ganaremos espacio en el datamart (recordemos que el datamart es una proyección bidimensional del espacio multidimensional, no el espacio multidimensional en sí). Por lo tanto, se puede ganar espacio al normalizar una dimensión, pero ganaremos espacio en el volumen relacional desde el que se carga el cubo, no en el cubo en sí. Para profundizar en este aspecto, os recomiendo que leáis el artículo "A trio of interesting snowflakes", de Ralph Kimball (http://www.intelligententerprise.com/010629/warehouse1_1.jhtml)
  • El diseño en estrella es más rápido: Esta frase hay que saber comprenderla. La velocidad de consulta del cubo no depende del diseño relacional de la dimensión, porque el motor multidimensional estructura los datos con respecto a dimensiones, no con respecto a las tablas que representan una dimensión. Cuando se "puebla" una dimensión, se leen los posibles valores que podrá tener una coordenada con respecto a esa dimensión, y se generan los correspondientes niveles. Evidentemente, durante este proceso, si la proyección relacional de la dimensión está normalizada, habrá que realizar tantas joins como tablas contenga la dimensión para ir poblando los distintos niveles de la dimensión. Hacer Joins es lento, y por eso se dice que el modelo en estrella es más rápido… pero OJO, SÓLO ES MÁS RÁPIDO DURANTE EL PROCESO DE CARGA DE LA DIMENSIÓN. Si nuestra dimensión es estática y jamás necesita ser regenerada, no se ahorra nada de tiempo. Cuidado con esto, porque podemos obsesionarnos con llegar a un modelo en estrella, y no darnos cuenta de que estamos complicando en exceso el ETL que "desnormaliza" los datos para llegar a este diseño en estrella… y recordad que el ETL se ejecuta sobre la base de datos OLTP, así que debería mantenerse tan eficiente como fuese posible. Para seguir profundizando sobre este tema, os recomiendo que leáis el epígrafe “Eliminate Joins between Fact and Dimension Tables” en la guía de optimización de Analysis Services (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ansvcspg.mspx)

Tanto hablar para no decir nada…

Efectivamente, todavía no me he decantado por ninguno de los dos diseños, y como inteligentemente habráis podido deducir, no me voy a decantar por ninguno. Hay que saber elegir inteligentemente dependiendo de la circunstancia. Habrá que valorar en cada caso:

  • Acceso al almacenamiento relacional subyacente. ¿Habrá aplicaciones o usuarios que accedan directamente al Datamart, sin hacer uso de la capa OLAP? En este caso, sin duda debemos decantarnos por una estrella. No sólo por la simplicidad, sino porque sacar cualquier informe relacional a partir de una estrella, requiere una única JOIN. Si el acceso siempre se realizará a través de una capa OLAP, nos da igual que el diseño sea en estrella o copo de nieve.
  • ¿Cómo son las dimensiones? Si son muy grandes, tienden a cambiar poco, y tienen atributos de gran tamaño y muy repetidos, tal vez interese considerar el espacio que ahorraríamos en el almacenamiento relacional usando un diseño en estrella.
  • ¿Complicamos mucho el ETL para transformar los datos en una estrella? Tal vez interese el diseño en estrella, porque de esta forma la carga de las dimensiones supondrá un esfuerzo para el sistema que soporta el datamart, pero descargaremos de trabajo a la base de datos de la que cargamos al propio datamart (recordemos que aunque el procesamiento sobre el datamart pueda ser incluso más lento, no afectará a los sistemas OLTP de la empresa).

Por último, los que usamos Analysis Services 2005 estamos de enhorabuena, porque al parecer, con esta maravilla de base de datos, el diseño en estrella apenas impacta en el rendimiento… bueno, eso al menos es lo que dicen en los blogs de MSDN (http://blogs.msdn.com/bi_systems/articles/164525.aspx).

A ver si con esto os animáis a mandarme comentarios… ¡que sería la primera vez que este tema no levanta polémica!

Un comentario sobre “¿Estrella o copo de nieve?”

Responder a gelexgaray Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *