Similar al anterior artículo: Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas , el presente artículo esta enfocado a arquitectos e ingenieros de datos, específicamente aquellos trabajando en el diseño y construccion de un data warehouse o data mart haciendo uso de modelado multidimensional.
En el artículo citado se mencionó que existen diferencias en los objetivos y enfoque de un modelo de datos para un sistema transaccional(OLTP) y un modelo de datos análitico( OLAP) y por lo tanto también existen diferencias en los patrones de diseño y las buenas practicas para ambos casos encontrándose ocasiones en los que una buena practica en un enfoque es un "pecado" en el otro.
El problema esta en que en las universidades y cursos de bases de datos es muy poco tocado el tema de analíticos por lo cual las personas encargadas de realizar un diseño de este tipo, muchas veces desconocen los objetivos, patrones y buenas practicas y realizan el diseño como si se tratase de un modelo transaccional(enfoque que si es tratado a profundidad academicamente) , muchos otros han aprendido el diseño de analíticos de manera básica a través de otras personas o bien por su cuenta , pero solo conociendo los patrones de diseño básicos por lo cual mezclan ambos mundos.
En el presente articulo atacaremos un error común y la manera recomendada de resolución del mismo.
En un modelo transaccional utilizando el modelo entidad-relación es muy común encontrarse con 2 tablas en relación de uno a muchos en una estructura llamada "maestro/detalle" en la cual cada registro del maestro o encabezado contiene información general que es compartida por cada uno de los registros "detalle" asociados.Ejemplos de esto son facturas en los que cada factura(maestro o encabezado) tiene asociados varios productos(detalles) o bien ordenes de mantenimiento de equipos en los que cada orden(maestro o encabezado) tiene asociados muchos equipos(detalle),en ambos casos los datos del maestro o encabezado son datos generales y que son compartidos por cada elemento del detalle(por ejemplo numero de factura u orden, o fecha de la operación) .En el mundo transaccional es correcto modelarlo de manera normalizada pensando en los objetivos de reducción de redundancia , facilidad de actualización de datos, integridad referencial y reducción de consumo de espacio en disco y no olvidando que en este tipo de sistemas operativos, comúnmente un usuario accede y/o actualiza una transacción a la vez, por lo cual en estos sistemas el modelado se hace a través de la estructura mencionada de 2 tablas,1 tabla maestro o encabezado, asociada con una tabla de detalle. Por ejemplo el siguiente modelo de facturación con una tabla para almacenar cada factura y otra tabla de detalle donde se registra para cada factura, que productos fueron vendidos.
Este patrón es muy usado y recomendado para el mundo transaccional , mas no así en el mundo multidimensional donde comúnmente no se accede una sola transacción a la vez si no posiblemente miles y ademas buscamos agilidad, simplicidad , menor cantidad de enlaces(joins) y tiempos de respuesta mas eficientes. Lamentablemente este patrón es muy utilizado ya que representa de manera correcta las relaciones entre los datos y es la manera en la que los diseñadores de modelos de datos se sienten mas cómodos. Esto nos al primero de los 2 patrones a evitar.
Replicar la tabla maestro(o encabezado) como una dimensión y el detalle como una fact table en el modelo multidimensional
El primer patrón a evitar consiste en prácticamente crear una copia de la tabla de encabezado, como una dimensión en el modelo multidimensional, y el detalle como una fact table. Aun que si es muy común y recomendado tener una tabla de detalle como base para una fact table, es mala practica que esta fact table sea una copia fiel de la tabla detalle y la tabla de encabezado sea una dimensión . Ejemplo:
Hacerlo de esta forma hace que se pierdan muchos beneficios de un modelo multidimensional bien diseñado, como el uso de dimensiones centralizadas,integradas, únicas y compartidas entre diversos modelos(lo cual permite hacer un analisis drill across entre múltiples procesos de negocio) ya que la información contextual o descriptiva estaría "incrustada" dentro de la dimensión de encabezado, o bien a través de un doble enlace entre fact table->dimension encabezado -> Dimension descriptiva , lo cual como se menciono en el anterior post también es un patrón a evitar. Ejemplo(Como podemos ver esto ya nisiquiera tiene la famosa forma de estrella):
De esta forma se tendría una tabla dimensional que crece a un ritmo bastante elevado(similar al de la fact table) y un análisis de este proceso de negocio implicaría el acceso a 2 tablas voluminosas(en lugar de una tabla voluminosa y pequeñas tablas dimensionales) .Si se desea analizar solo la información contextual o descriptiva(por ejemplo: listado de clientes o sucursales) sería necesario recorrer toda la tabla(con posiblemente millones de registros) en vez de recorrer una única tabla pequeña, esto puede degradar el rendimiento y tiempo de respuesta.
Además de esto el campo de enlace(o llave) entre ambas tablas, sería un campo incremental y único que no se repetiría en la fact table , lo cual haría que sea imposible utilizar técnicas de compresión (como por ejemplo compresion bytedict en amazon redshift) o indices bitmap(Sybase IQ) que si podrían ser utilizadas si se manejara como pequeñas dimensiones con pocos valores repetidos muchas veces.
En este post hemos hablado del primer patron a evitar para relaciones maestro detalle, en el siguiente post se explicara el segundo patrón ademas de presentarse un esquema de datos recomendado para modelar estas relaciones de manera eficiente. Nuevamente estas no son recomendaciones o ideas generadas únicamente por mi persona, si no por los expertos en la materia y creadores del modelado multidimensional.
Autor: Luis Leal
