The Triadic Continuum, el fin del Datawarehouse

La verdad es que este post es absolutamente fruto de la casualidad, no lo tenía planificado como la continuación de mi anterior post pero me viene que ni caido del cielo.

No lo digo yo, lo dicen en DM REVIEW

The Best New BI Invention You’ve Never Heard Of

Este fantambuloso invento viene a jubilar definitivamente a los Datawarehouse y a la estructuras de Inmon y Kimball. La nueva "padre" de los sistemas decisionales es Jane Mazzagatti. y su nuevo invento tiene nombre de capítulo de Star Trek NG:

THE TRIADIC CONTINUUM.

¿Que es lo que han hecho Mazzagatti y su equipo de la empresa Unisys? Pues han inventado una estructura de autoaprendizaje en tiempo real, que se "alimenta" de querys de las que "aprende" a dar respuestas, a medida que se va alimentando de datos las respuestas a las preguntas que se hacen al Triadic Continuum pueden ir variando, al igual que funciona el conocimiento en los humanos.
La idea principal del TC es que mientras que en una Base de Datos tradicional (ya sea relacional o multidimensional) nos centramos en la busqueda de datos e información , el centro de atención del TC esta en la adquisición de conocimiento útil y con un proposito decisional determinado. El TC no solamente se centra en el dato, sino en las relaciones que hay entre ellos, sobre estas relaciones, el sistema "aprende" y crea los métodos de explotación y acceso a la información.

Es una estructura que mezcla conceptos de modelado de datos con mineria de datos, en una única herramienta. ¿no os suena de algo? los que habeis seguido el debate del post anterior os resultará esta conclusión muy pero que muy familiar.

La estructura física de este Triadic Continuum la verdad es que se me ha escapado un poco, según el artículo de referencia de DM REVIEW

"El modelo conceptual de la estructura de la Triadic Continuum es bastante simple. Mazzagatti y colegas utilizan el término "simple y elegante" en la explicación de la forma en que está organizada. En pocas palabras, se trata de una estructura de tipo arborea con nodos llamados "tríadas." Estos nodos están conectados entre sí por ramas o caminos. Las tríadas que conforman la Triadic Continuum puede ser visualizadas como tres nodos organizados de forma triangular, en cierta formación. El primer nodo se conecta al segundo nodo mediante un puntero bidireccional, y el segundo se conecta al tercero tambien con otro puntero bidireccional. Los punteros identifican a que nodeo y desde que nodo se conectan , lo que permitirá a todos los nodos a saber siempre su relación dentro de la continuidad de las estructura consultando sólo dos punteros."

Vamos que no me he enterado de nada, pero eso sí, parece que no soy el único que se esta dando cuenta que el Datawarehouse y los sistemas de BI deben de dar un paso evolutivo hacia el "conocimiento", dejando atras los "datos"

Prometo buscar mas info sobre THE TRIADIC CONTINUUM.

MODIFICACION 2-Nov-2007

Ayer recibí un email que me ha dejado patidifuso, un mail muy corto pero a la vez sorprendente y que me ha recordado que estamos realmente es un mundo conectado y que esto de la blogosfera realmente es algo increible.

El contenido del mail es este:

I have read your blog and sent it to my team – I love the TNG picture – the team members were excited to see that someone really grasped the ideas - Jane

Y si señores, es la Jane que sospechais,... ¡¡¡¡Jane Mazzagatti!!!!.

Kimball 1 - Inmon 1 (Usabilidad vs Representación)

La "lucha" Kimball vs Inmon es ya de todos conocida, pero quizás no lo sea tanto las aseveraciones y mensajitos que ambos se han lanzado.

Kimball aseguró en 1997 su modelo multidimensional era "la única manera viable de diseñar bases de datos destinadas a su uso directo por parte de un usuario final".

Casi todos le siguieron la corriente, pero obviamente algunos valientes se le tiraron a la yugular entre ellos Inmon en 2000 cuando dijo que si diseñas un DWH desde el punto de vista de análisis de un solo individuo condenas al resto a su mismo punto de vista y que dificilmente en el modelo dimensional puedes incluir información no incluida en el foco original del análisis.

Pero no solo Inmon cuestiona este punto de vista, tambien Haughey en el 2004 comenta que "el mundo no es una estrella" y que el modelo multidimentional no puede representar de forma efectiva escenarios complejos de negocio.

Con lo que el primer gol de lo asigno a Inmon, así pues Kimball 0 - Inmon 1.

Pero mira por donde este grupo de investigadores decide mirar si la aseveración un poco prepotente de Kimball con la que hemos empezado era cierta o no y publican el siguiente artículo:

Comparing the Effect of Alternative Data Warehouse Schemas on End User Comprehension Level
David Schuff
209F Speakman Hall, Fox School of Business, Temple University
Karen Corral
BA297L, W.P. Carey School of Business, Arizona State University
Ozgur Turetken
209G Speakman Hall, Fox School of Business, Temple University

En el que hacen un estudio de como ambos modelos son vistos por los usuarios finales y como afectan ambos modelos a la usabilidad decisional.
La conclusión del artículo (que lo podeis descargar entero) hace que el marcador se iguale a 1, ya que concluye que para usuarios con poca experiencia el modelo dimensional es mucho mas usable y productivo.

Así pues por un lado ganamos capacidad para representar escenarios complejos pero necesitamos usuarios listos y expertos, mientras que por el otro perdemos capacidad de representación pero ganamos que cualquiera pueda usuarlo.

De momento 1-1.

¿Alguien se anima a meter algún gol mas?
¿Creeis que es lícito sacrificar esa capacidad de representación en pro de la usabilidad?.

¿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.