El datawarehouse tiene, y debe tener, todo el detalle de información en su nivel atómico. Así, las ventas estarán detalladas por fecha, cliente, producto y punto de venta. Rápidamente nos daremos cuenta que estaremos trabajando con un volumen muy importante de información. Por poner algún ejemplo, en los sectores de distribución retail, telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles de millones de registros.
Sin embargo, la mayoría de consultas no necesitan acceder a tanto detalle. Un "product manager" puede estar interesado en los totales de venta de sus productos mes a mes, mientras que el "area manager" consulta habitualmente la evolución de ventas de sus zonas.
Incluso con el uso de índices, la compresión de las tablas, o con una inversión millonaria en hardware, estas consultas habituales deberían leer, agrupar y sumar decenas de millones de registros, lo que repercutiría directamente en el tiempo de respuesta y en el descontento de los usuarios.
La solución ante estas situaciones pasa siempre para la preparación de tablas agregadas. Las tablas agregadas sumarizan los indicadores de las tablas de detalle a un nivel superior. Por ejemplo, las ventas podrían precalcularse a nivel mensual, o por cliente, o por producto. De esta manera, las consultas típicas del "product manager" o del "area manager" podrían ejecutarse en pocos segundos, sin necesidad de acceder a la tabla de ventas detalladas.
La existencia de estas tablas agregadas debe ser completamente transparente para el usuario de negocio. Es decir, tanto el "area manager" como el "producto manager" trabajarán con el indicador "Ventas", y la herramienta Business Intelligence hará el resto.
En mi opinión, lo más complicado es definir las tablas agregadas necesarias. De nada sirve crear muchos agregados si estos no se utilizan. Es necesario conocer las consultas habituales de los usuarios. Y, desde luego, lo que no debe hacerse es lo que indica el error 5 de esta serie sobre cómo no construir un datawarehouse :
Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
Calcular los agregados en la misma tabla de ventas es un error muy grave e injustificable. Aunque puede parece adecuado en algunas situaciones, será sin duda una fuente de problemas e incoherencias futuras. Este tipo de construcciones erróneas suelen aparecer ante la falta de funcionalidad de las herramientas BI, lo que obliga al técnico a crear modelos extraños.
Personalmente, he visto este tipo de tablas (que mezclan información a diferente nivel de detalle) en sistemas operacionales, donde resulta prohibitivo calcular los totales en el momento de generación del informe. De esta manera, el operacional apunta el detalle y los totales en el mismo momento, y de esta manera los listados predefinidos del host se ejecutan de manera rápida y sencilla. En un entorno datawarehouse, evidentemente, todo esto es innecesario y contraproducente.
Recuerda: Cada "granularidad" requiere su propia tabla de hechos.
