En un reciente artículo he recibido muchas críticas por menospreciar las capacidades de los cubos OLAP. Creo que la mayor polémica ha surgido al afirmar que los cubos OLAP tienen limitaciones estructurales, y que no se adaptan suficientemente bien al negocio.
Intentaré en este artículo aclarar cuáles son estas “limitaciones estructurales” de las que hablo, y por qué los cubos no son siempre la mejor solución posible.
El ejemplo típico de cubo OLAP consiste invariablemente en un cubo comercial con las ventas en unidades e importes. Así, tenemos las ventas por producto, por familia, por categoría, o por fechas, semanas, meses, años, o por cliente, provincia, región o país... Todo muy bonito y muy fácil.
En la vida real, sin embargo, existen muchas bases de datos corporativas donde la “agregaciones dimensionales” no es lo más relevante, y donde el “dato” no es un número fácilmente agregable. Os pongo tres ejemplos:
- Un proyecto de SCM (cadena de suministro). En este caso se dispone de calcetines o bolígrafos que se encajan en China o Tailandia, y que se ponen en contenedores, y que viajan hasta Europa utilizando barcos, aviones y camiones... En todo este proceso, existen multitud de eventos y fechas significativas (fecha de encajado, de embarque, aduanas, incoterm, de entrada en almacén, y un larguísimo etcétera que si vives el sector conocerás). ¿Acaso no es necesario hacer un análisis de estos datos? ¿Acaso los usuarios no necesitan acceder fácil y rápidamente a todos estos datos? Claro que es necesario, y el usuario lo quiere, y todo es importante y sin perder la trazabilidad. Y lo quiere desde cualquier perspectiva y con cualquier agregación. Además, existen infinidad de indicadores (retrasos, unidades pendientes de...). La solución a esto pasa, necesariamente, por un modelo ROLAP. Olvídate de los cubitos.
- Una aplicación de recursos humanos. En este caso, suelen ser bases de datos minúsculas (¿1.000 empleados? ¿10.000? Da igual). Tenemos nóminas que se pagan mensualmente, y tenemos la historia de cada empleado: sus distintos contratos, su bajas por enfermedad, sus maternidades, su historial de fichajes, su periodos de vacaciones, sus evaluaciones. Etc.). ¿Acaso alguien recomendaría poner esta información en un cubo? Aquí, no existe un “dato” agregable que consultar. Por supuesto que existen indicadores y se pueden definir KPI. Pero no es eso lo que principalmente pedirá el manager de RRHH.
- Un sistema de control de la producción. En este caso, tenemos máquinas y operarios que fabrican piezas, y disponemos de la historia de las piezas (fechas, materiales, incidencias,...) y de las máquinas (calibración, periodos de operación, operarios, revisiones...). Por supuesto, querremos calcular la producción diaria, o medir la calidad del producto resultante... Pero el manager querrá (¡necesitará!) mucha más información. A este manager no le des un cubito. En serio, sus datos no caben en un cubo.
Es decir, las limitaciones de los cubos no se refieren sólo al volumen de información que pueden gestionar, o a la complejidad de sus procesos de carga. Los cubos presentan “limitaciones estructurales” en las cosas que pueden meterse eficientemente. Si no, ¿Por qué pensáis que los anteriores ejemplos raramente se entregan a los usuarios en forma de cubo?
Creo que lo que diferencia estos ejemplos con el cubo de ventas es que para analizar las ventas basta y sobra con unos disponer de unos pocos indiciadores (unidades, importes, costes y márgenes,...) desde unas pocas perspectivas (tiempo, producto, punto de venta), mientras en los otros ejemplos los indicadores no son suficiente. Es necesario conocer toda la historia, a nivel detallado, con sus fechas, atributos, descripciones textuales, códigos, y manteniendo la “trazabilidad”. Tal vez sea eso lo que diferencia unos casos de otros: Todas las ventas son iguales, pero cada viaje, cada trabajador, y cada pieza fabricada es única, y tiene su propia historia.
Estas diferencias conceptuales provocan diferencias en el tipo de informe y análisis que se realiza:
- Una tabla dinámica puede ser suficiente para analizar las ventas. Los gerentes comerciales tienen esta suerte.
- Pero un informe de SCM, de RRHH, o de producción siempre consistirá en varios bloques de información –tablas o gráficos – que se repetirán en distintas “secciones”... ¿Cómo haces eso con un cubo? ¿Y por qué vamos a privar a estos gerentes de disponer de un acceso fácil, rápido y analítico a sus datos? Y digo más: ¿Quién coño es IT para decidir cómo deben estos managers hacer sus informes? ¡¡o para decidir si necesitan informes predefinidos o si necesitan autonomía para el acceso y análisis de la información!!
Y provocan diferencias en los modelos de datos:
- Las bases de datos comerciales se modelizan en estrella o en copo de nieve...
- Y el resto se modelizan como haga falta. Sí: La bases de datos relacionales son las más flexibles, y las que se adaptan a cualquier situación de negocio imaginable. El señor Edgar F. Codd se revolvería en su tumba si pretendiésemos prescindir de las bases de datos relacionales para modelizar todas estas cuestiones.
Los lectores habituales saben que no es la primera vez que cuestiono los modelos MOLAP. Lo hice en mi quinto artículo. Y lo he hecho en otras ocasiones. Por supuesto, es una opinión compartida por otros profesionales:
No sé si las críticas vienen por la sencilla razón de que ahora tengo más lectores, o por el tono comercial del artículo en cuestión. Tal vez sea que esta vez he particularizado en una base de datos (MSAS) con una importante comunidad de usuarios (¿fanboys?) :-)
En cualquier caso, gracias por vuestros comentarios. Toda crítica es bienvenida.
PD: El título está puesto sólo para provocar. Por supuesto, no creo que sean una basura.
