Cuando diseñamos un modelo de datos analítico, uno de los aspectos clave a tener en cuenta corresponde al nivel de normalización/desnormalización con que queremos dotar a la estructura del mismo. Es probable que la mayoría de los orígenes de datos que utilicemos a nivel profesional correspondan a sistemas de procesamiento de transacciones (OLTP). Estos sistemas son bases de datos relacionales optimizadas para llevar a cabo las tareas diarias de una oficina, principalmente la gestión de pedidos, facturas, reclamaciones, realización de asientos contables, etc…

En estos sistemas nos encontraremos frecuentemente con estructuras altamente normalizadas, donde prácticamente cada atributo se almacena en una tabla y, por lo tanto, un solo objeto, como por ejemplo «Cliente», estará almacenado en 10 o 20 tablas distintas relacionadas entre sí. Esto se debe a que dichas bases de datos OLTP están diseñadas para gestionar continuas operaciones de introducción y modificación de datos, por lo que una estructura de este tipo proporciona la ventaja de ahorrar tamaño en disco (lo que normalmente se traducirá en mayor velocidad) y que los cambios que introduzcamos en un atributo solo tengan que actualizarse una vez.

Si por el contrario trabajáramos con una base de datos desnormalizada, el actualizar por ejemplo la dirección de un cliente supondría que el servidor tuviera que ejecutar cientos de órdenes, causando un rendimiento deficiente.

A la hora de diseñar un modelo de datos analítico es importante tener en cuenta que no estamos interesados en la introducción y actualización de datos, si no solo en la lectura de los mismos. Las estructuras que nos encontraremos inicialmente en los sistemas OLTP, que constituyen los orígenes de datos tradicionales, difícilmente serán las más apropiadas a la hora de analizar los datos. Nuevos orígenes como la actividad de los navegadores, las redes sociales o los dispositivos móviles, que pueden proporcionarnos valiosa información respecto al comportamiento y las preferencias de nuestros clientes y ayudarnos a encontrar mejores maneras de satisfacer sus necesidades están creando conjuntos de datos extremadamente grandes en comparación con los orígenes tradicionales, y sus estructuras, aunque son variadas y dependen del uso específico de cada aplicación, suelen requerir también transformaciones en el proceso de ETL para estructurar los datos con el propósito de acomodarlos de cara a optimizar la consulta y el análisis de los mismos.

Modelamiento dimensional y esquema en estrella (Star Schema)

Existe cierto consenso en la industria del Data Warehouse / Business Intelligence de que para un entorno analítico el diseño más conveniente se refiere al denominado modelamiento dimensional. La arquitectura de la gran mayoría de modelos dimensionales corresponde a lo que se conoce como esquema de estrella. Este término técnico procede de la metodología Kimball, que describe la forma lógica en la que los datos deben estructurarse para obtener un rendimiento óptimo desde un punto de vista analítico. En los esquemas de estrella, las tablas que forman el modelo de datos se dividen en 2 categorías:

  • Tablas de consulta o dimensiones: los activos informativos que corresponden al contexto de los hechos se almacenan en tablas independientes, conteniendo cada una de ellas todos los atributos relativos a su objeto. Por ejemplo «Producto» sería un objeto y sus atributos serían «Color», «Peso», «Categoría»…
  • Tablas de hechos o datos: los valores numéricos de un proceso de negocio observable en el mundo real («hechos») se almacenan en la tabla central, y cada registro de la misma está formado por dichos valores numéricos y las claves secundarias (foreing keys) que se relacionan con las diversas dimensiones que describen los hechos o eventos.

En la siguiente imagen podemos ver un clásico esquema de estrella relativo a los pedidos recibidos en una empresa:

Este tipo de esquema dimensional mantiene la tabla de hechos en su forma normalizada (normalizando fuera de ella las dimensiones), para obtener un tamaño menor y un mejor rendimiento, pero mantiene cada dimensión en forma desnormalizada (plana), de forma que cada objeto contenga todos sus atributos correspondientes. Estas dimensiones contienen la misma información que podemos encontrar en su forma totalmente normalizada en el origen de datos, pero sin las tablas y claves (keys) necesarias para completar el proceso de normalización mediante relaciones.

Podemos entender mejor la diferencia entre las 2 estructuras (normalizada y desnormalizada), si vemos de forma gráfica una vista de las relaciones que se establecen entre las tablas del modelo en ambos casos. En la siguiente imagen podemos ver un ejemplo de algunos de los atributos relativos a la dimensión «Producto» en un modelo normalizado:

Image 1

Como podemos observar, la tabla base denominada «Productos» conecta con la tabla de hechos al nivel de la clave primaria de producto (primary key), y a su vez, se relaciona mediante claves secundarias (foreing keys) con una serie de tablas que guardan otros atributos relativos al mismo objeto. Cuando desnormalizamos el modelo anterior durante el proceso de ETL, lo que hacemos es combinar las distintas consultas de forma que obtengamos una única tabla que contenga todos los atributos correspondientes a la dimensión «Producto». El resultado sería el siguiente:

Image 2

Con este modelo desnormalizado, podemos también agregar los datos de la tabla de hechos al nivel de cualquier atributo de la dimensión, por lo que podemos decir que desde una perspectiva analítica los dos modelos son equivalentes. Cuando realizamos este proceso de desnormalización con las 10 o 20 dimensiones que nos encontraremos normalmente asociadas al proceso de ventas en una base de datos relacional, las ventajas que obtenemos son enormes y podemos resumirlas en los siguientes puntos:

  • Facilidad de uso: para el usuario, el modelo dimensional, con su arquitectura básica de una sola tabla por cada dimensión, ofrece un nivel de simpleza muy superior a cualquier modelo con mayor nivel de normalización. Desde el punto de vista del programador, el desarrollo de los cálculos tiende también a simplificarse.
  •  Rendimiento/eficiencia: el modelo dimensional simplifica el diseño físico de la estructura de datos mediante la reducción dramática en el número de tablas y relaciones necesarias para la realización de las consultas analíticas. Tanto DAX como otros lenguajes usados en el análisis de datos presentan optimizaciones para el modelo dimensional, especialmente si se trata de un «esquema en estrella».
  • Flexibilidad: uno de los objetivos principales del modelamiento dimensional corresponde a capturar los datos al nivel más pequeño posible de detalle, conocido como el nivel atómico, cualquier agregación previa a la inclusión de los datos en el modelo analítico significará la perdida de detalles y por tanto la reducción de la flexibilidad a la hora de elaborar nuestros informes. En un modelo dimensional correctamente diseñado, la granularidad o nivel de detalle en la tabla de hechos corresponderá siempre al  nivel atómico, de forma que los datos puedan agregarse y segmentarse en función de cualquier atributo de cualquier dimensión, proporcionándonos de esta manera la máxima flexibilidad.
  • Mantenimiento: cuanto más sencilla sea la arquitectura del modelo de datos, más fácil resultará desde el punto de vista del desarrollador el mantenimiento y adecuación del mismo ante cambios en el número o el tipo de atributos.

Esquema en copo de nieve (Snowflake Schema)

Otro tipo de estructura de datos muy común en la industria del Business Intelligence es el conocido como esquema en copo de nieve. Esta estructura surge cuando una relación jerárquica entre atributos de la misma dimensión es normalizada, de forma que ciertos atributos con una cardinalidad baja aparecen como tablas secundarias conectadas mediante relaciones con la tabla base de su dimensión correspondiente. En la siguiente imagen podemos ver la estructura multinivel característica de este tipo de esquema:

Aunque el esquema en copo de nieve representa de forma precisa los datos jerárquicos correspondientes a las distintas dimensiones, presenta cierta complejidad que lo hace difícil de entender y navegar por parte de los usuarios. Por otro lado, el rendimiento analítico será peor, por lo que siempre que sea posible, es preferible la desnormalización de los atributos de forma que obtengamos dimensiones planas, de esta forma obtendremos también la ventaja de que el código DAX tenderá a ser más fácil de desarrollar y menos proclive a los errores.