Si no eres de Vulcano necesitas Fuzzy OLAP

Como bien dice Angel Agueda en un blog "Inactivad es sinonimo de mucho trabajo"
Así que voy a hacer una pequeña anotación para recordaros que sigo en la brecha, a pesar de que el ritmo no es que yo desearía.

¿Recordamos todos Star Trek? Supongo que si, sabreis entonces que Spock( y todos los de Vulcano), regían sus acciones sobre la más estricta de las lógicas, sin inmutarse ni pestañear, refrexionaba todo cuantitativamente y daba la respuesta más lógica. Mítica es la frase "el bienestar de la mayoria supera al de la minoria y de a uno solo" con el que Spock decide que es más lógico sacrificarse él por salvar a toda la tripulación del Enterprise.

El caso es que su contrapunto en la serie era el Capitán Kirk que tomaba las decisiones sin meditarlas demasiado, con el estómago como quien dice, al mas puro estilo "humano".

Así pues, si fueramos de Vulcano nos serviría perfectamente la estructura OLAP tradicional (como ya comenté en el post Mi cerebro ... ¿un producto cartesiano?), pero obviamente no tenemos esa capacidad y el cosquilleo en el estómago y la intuición a veces tienen un peso más que específico dentro de nuestra toma de decisiones. Eso me recordó que quizás la lógica difusa (fuzzy logic) podría ayudarnos mas que la lógica pura, y que quizás un análisis cualitativo fuera mas adecuado para la toma de decisiones. Sin muchas esperanzas me puse a buscar y ¡oh! ¡Sorpresa! alguien ya estaba investigando en esa linea.

El articulo con el que he topado es

	Fuzzy OLAP cube for qualitative analysis Pavan Kumar, K.V.N.N.; Radha Krishna, P.; Kumar De, S.; Intelligent Sensing and Information Processing, 2005. Proceedings of 2005 International Conference on 4-7 Jan. 2005 Page(s):290 - 295 Digital Object Identifier 10.1109/ICISIP.2005.1529464 Summary: Data warehouse systems enable decision-makers to acquire and integrate information from heterogeneous sources and query very large databases efficiently. Data warehouse provides the users with an online analytical processing (OLAP) facility by which .....

Como siempre de investigadores de la India que cada vez están mas fuertes (o tienen más tiempo libre). El artículo tiene la bondad de no solo teorizar sino de implementar un ejemplo práctico con un cubo de ventas, que si bien es muy limitado si que nos da una idea de como utilizar la lógica difusa en la consulta de cubos OLAP.

El ejemplo con el que juegan es ¿cuando un cliente/vendedor se puede calificar de Bueno, o Medio o Malo? ¿Lo tenemos claro? ¿Es totalmente estricto o dejamos cierto margen de variabilidad?. Pare ello utiliza algoritmos de lógica difusa mezclados con algoritmos de mineria de datos sobre un cubo OLAP. Es una buena aproximación sobre la que seguiré reflexionando.

¿Inmon o Kimball? o cuanto apreciamos la trazabilidad decisional

Despues de un tiempo de silencio (la entrada en septiembre ha sido un poco dura) y tras hablar de ontologías, vamos a bajar de nuevo a la parte de decisiones operacionales y tácticas.
En este ambito la creación de los Datawarehouse tienen dos grandes gurús, por un lado el archiconocido Kimball con su modelo multidimensional, y por el otro el quizás menos conocido pero no menos importante Inmon.

Me he estado leyendo este artículo que la verdad aporta poco y no es mas que una revisión de todos los conceptos de un datawarehouse, pero que me ha servido para reflexionar cual es mi propio de creación de datawarehouse y cual sería el más apropiado para una metodología ágil

MODELING STRATEGIES AND ALTERNATIVES FOR DATA WAREHOUSING

Articulo de Nenad Jukic publicado en communications of ACM en abril de este año.

Y me ha sorprendido comprobar que estoy mas de acuerdo con las tesis de Inmon que con las de Kimball, yo que he sido un fiel seguidor del primero

Aquí podemos ver dos típicas arquitecturas al "estilo Kimball"


El primer modelo es el utilizado en algunas implementaciones MOLAP puras en las que tenemos varios procesos ETL, que se conecta a diferentes fuentes de datos y generamos los diferentes datamarts dimensionales. Son generalmente datamarts independientes entre ellos para el uso de un solo departamento o incluso de una sola persona.


El segundo modelo es el Kimball mas corporativo en el que un proceso ETL nutre un espacio datawarehouse en el que se comparten las dimensiones entre diferentes puntos de vista y en el que los datamarts de cada departamento forman utilizando los hechos y las dimensiones ya establecidas para toda la compañia.



Todo normal hasta aquí y perfectamente de acuerdo con ello, yo mismo he hecho decenas de dwh utilizando el dogma Kimball


Pero miremos ahora el "estilo Inmon"
Coincide con Kimbal en un único proceso ETL que nutra un DWH corporativo, pero el que él nutre no es dimensional es un DWH basado en el modelo Entidad-Relación.
La idea de Inmon es que el modelo E-E mucho mas rico y adaptable que el multidimensional.

Una vez tenemos el DWH E-R corporativo generamos los datamarts dimensionales que queramos, y no solo eso, nos puede servir para crear cualquier otra extracción para cualquier otro sistema decisional, como puede ser para mineria de datos o para sistemas expertos, por ejemplo.

Lo que me gusta de Inmon es que no se cierra a un solo modelo y no solo eso, además su arquitectura mejora la trazabilidad decisional. Con ella podemos desgranar un valor en un KPI hasta una serie de análisis y reports que lo expliquen en detalle, tan en detalle como nos permiten los modelos E-R que tenemos en nuestros sistemas operacionales.

Parece maravilloso, pero el problema es que es mas costoso de mantener y de implementar. El de Inmon es un modelo que mira a largo plazo y para una metodología ágil el largo plazo es secundario. Para adaptarlo y no perder la agilidad de por ejemplo el primer modelo de Kimball, yo he utilizado a veces lo que he llamado la "Starting Area".

Si el proyecto necesita de una trazabilidad que llegue hasta el ultimo nivel de detalle, lo mejor es crear un capa que sea una copia exacta de los diferentes modelos relacionales de los que se nutre el modelo dimensional. Una simple BULK COPY nos servirá inicialmente, no hace falta unificar el modelo E-R de las diferentes fuentes origen en uno solo, eso es demasiado trabajo. La idea es dejar la semilla de una capa relacional por debajo del dimensional y que ambas crezcan de forma conjunta alo largo del proyecto.

Creo que esta sería la mejor opción para una metodología ágil, nos permitirá tener la rapidez del modelo Kimball y la visión de futuro del modelo Inmon.

7 Intervenciones para el éxito de un DWH (2ª Parte)

El cuarto punto de intervención está en elegir la herramienta de explotación del DWH.
La cuarta pregunta que os debeis hacer es :

¿Los usuarios necesitan herramientas restrictivas o no restrictivas ?

Usar herramientas restrictivas (es decir herramientas que limitan las opciones del usuario final) sin duda nos ayudará a reducir la complejidad y la ambigüedad semántica, pero nos limitan las posibilidades.

Usar herramientas no restrictivas (es decir herramientas que dan una amplia gama de opciones al usuario) nos permitirán acceder a información menos estructurada, pero son mas complejas de usar por los usuarios y es facil que generen conflictos semánticos.

Obviamente los investigadores detectaron que aquellos que tenian un repositorio simple como DWH (sin datamarts) y que habían tenido éxito habían optado por herramientas no restrictivas, preferian invertir en aprender la complejidad de este tipo de herramientas antes que utilizar una mas simplificada.

Ahora me gustaria hacer una pequeña reflexión: ¿somos conscientes de que cuando utilizamos un Datamart estamos "semiestructurando" nuestros tipos de análisis?. ¿Somos conscientes que al simplificar, al crear dimensiones, jerarquías y hechos de análisis, dejamos algunas manzanas fuera del cesto?.

Unas herramientas que nos simplifiquen la interacción tambien nos harán mas sencillos los tipos de análisis que podamos hacer, perdiendo parte de ese capacidad por el camino. Si nos limitamos a decir "no, mejor todas las posibilidades" entonces introducimos complejidad innecesaria, dificultamos el aprendizaje del DWH, e incentivamos a los usuarios a que busquen la información por otro lado, en algún listado del ERP combiando con un Excel que les pasa su vecino de mesa.

No es lo mismo acceder a la informacion mediante informes realizados en herramientas específicas de BI, diseñadas para el análisis y el reporting (Business Objects, Cognos, MicroStrategy, MIS, etc...), que hacerlo directamente con sentencias SQL. Seguro que con sentencias SQL podemos acceder a cualquier posibilidad que exista en el DWH, pero la complejidad de su uso quizá no merezca la pena.

Por lo tanto este equilibrio entre lo que pierdo de capacidad de análisis y lo que gano en sencillez es vital para el éxito del DWH. Pensad que los usuarios finales son generalmente bastante vagos (lo digo por experiencia) y siempre encontrarán la manera mas sencilla y mas cómoda para acceder a la información.

Desde el punto de vista de las metodologías ágiles, la utilización de una herramienta restrictiva creo que es la más adecuada, ya que la famosa regla del 80-20 se cumple inexorablemente. Quizás podamos dejar un 20% de análisis no típicos que al semiestructurar perderemos, pero el 80% restante lo tendremos con solo el 20% de esfuerzo. ¿Merece la pena aplicar otro 80% de esfuerzo por esos análisis?. Pues generalmente no. Pensad que uno de los principios básicos de las metodologías ágiles es potenciar la puesta en marcha rápida de todo aquello que sea útil desde la perspectiva de negocio, eliminando lo superfluo.

Fijaos que si ya tenemos la información "semiestructurada" en un Datamart, esa pérdida ya la hemos cometido con lo que el uso de la herramienta restrictiva apenas nos quitará juego y nos aportará simplificación del uso y reduccion de la ambigüedad semántica (esto último se consigue al crear el Datamart y luego ponerle una capa de abstracción o semántica o de metadatos con la herramienta de explotación del usuario que escojamos).

Por el contrario, si no tengo la informacion "semiestructurada", es decir, si tengo un repositorio simple, al introducir una herramienta restrictiva estoy poniendo mucho en juego, estoy perdiendo esa amplitud de análisis que precisamente me habian llevado a elegir un repositorio simple. No es de extrañar entonces que los investigadores detectasen que para estos casos se eligieran herramientas no restrictivas.

Podriamos pues deducir, que si tenemos un repositorio con información semiestructurada y elegimos una herramienta no restrictiva, seguramente llegará un momento en que deberemos completar esos "huecos" con información no estructurada, para permitir recuperar esa pérdida de capacidad de análisis. ¿ Esta situación no se parece mucho a la arquitectura HOLAP (Hybrid On-Line Analitical Process) ?.

Obviamente en el artículo no se nombra nada de esto, pero creo que cae por su propio peso, sacar como conclusion el siguiente esquema decisional para el cuarto punto de intervención.

Si alguno de los lectores estais en alguna de estas situaciones me gustaria que lo comentarámos para confirmar este esquema.

Hemos visto el 4º punto de intervención, me he extendido demasiado así que dejaré los tres últimos puntos para la tercera parte de este artículo.

Mi cerebro.. ¿un producto cartesiano?

Despues de algunos dias sin poder escribir he conseguido sacar algunos minutos para continuar con el blog. Estoy "cerrando" proyectos ya que en breve nacerá mi primer hijo (en 4 semanas) y no quiero dejar ningun cabo suelto.

Hoy me gustaria reflexionar sobre como estructuramos la toma de decisiones. Nuestro cerebro esta acostumbrado a realizar con precisión procesos semiestructurados, en los que hay una parte de incertidumbre que tenemos que despejar. Esto hace de los procesos decisionales algo muy complejo. Trasladarlos a un automatismo es muy complicado ya que no se puede prever con exactitud el tipo de información que vas a necesitar y anticiparte con un informe. Es esta necesidad la que hace nacer los sistemas OLAP (On-Line Analytical Process) que nos ayudarán en la ejecución de los análisis dinámicos. El más conocido de ellos es sin duda el modelo dimensional también conocido por cubos multidimensionales, pero debemos recordar que no es el único..

El modelo dimensional nos representa una actividad que es objeto de análisis a la que se denomina “hecho” y las dimensiones que caracterizan la actividad, estructuradas jerárquicamente. La información relevante sobre el “hecho” (actividad) se representa mediante el uso de medidas o indicadores. Por ejemplo para el hecho venta tendríamos los indicadores unidades y euros, y las dimensiones tiempo, producto, vendedor, zona, almacen, etc… Moviéndonos y cruzando dichas jerarquias obtenemos los valores de los indicadores que necesitamos.

Reflexionad un momento en porque siempre es necesaria la dimensión tiempo, pero tomaos un tiempo antes de seguir leyendo........
........
........
........
otra vez
........
........
........
es necesaria porque los humanos no sabemos tomar ninguna decisión sin hacer referencia a hechos sucedidos en el pasado, es decir sin utilizar nuestra experiencia. Recuerdo cierto episodio de Star Trek Deep Space Nine en que se encontraban con una forma de vida que no tenia la referencia temporal..... l¡¡¡¡ la comunicación era practicamente imposible !!!!!.... y tomar decisiones conjuntas mas todavía. Así que si eres humano necesitas la dimensión tiempo en tu sistema decisional.

Sigamos con las preguntas: ¿Que es un cubo multidimensional?........., pues es un almacén de información en el que calculo previamente todas las combinaciones de todos los niveles de la jeraquía de la dimensión con todas las dimensiones. En otras palabras; un “bonito” producto cartesiano que me almacena todas las combinaciones. El almacén de un hecho en concreto es lo que se denomina Datamart.

Un momento, ¿pero eso no es una salvajada?. Pues en cierto modo si, es una semiestructuración basada en la “fuerza” que nos garantiza poder acceder de forma rápida y sencilla a la necesidad decisional que nos salga en ese momento. Obviamente esto requiere de grandes cantidades de procesos de cálculo y de un almacén de datos que ya no tiene por que ser una base de datos relacional (diseñado para la transacción) sino que puede ser una de las modernas bases de datos multidimensionales, diseñadas específicamente para hacer eficiente este modelo de semiestructuración de la información.

¿Es esta la mejor forma de acometer un sistema decisional?
¿Es mi cerebro un conjunto de productos cartesianos que utilizan la dimension tiempo?
¿Como puedo agilizar entonces la toma de decisiones con un metodo tan poco "agil"?