sábado, septiembre 16, 2006

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

domingo, septiembre 03, 2006

De la Web Semántica a la Ontología Decisional (2ª parte)

Todo Ontología se compone de tres partes:
1) Clases e instancias de los objetos que la componen
2) Propiedades que establecen relaciones
3) Reglas para modelar el conocimiento y los comportamientos complejos ( Creación, Restricción y Reacción).

Si no aplicamos el último componente (las reglas) obtendremos o bien una ontología ligera o bien una Taxonomia que no es el objetivo que buscamos en principio.

Así pues ,si queremos tener una ontología decisional, ¿debemos utilizar reglas?.

La utilización de reglas nos origina el problema de la capacidad del motor de inferencia, cuando la base de conocimiento sobre la que se intenta inferir es muy grande, los motores tienen graves problemas de escalabilidad, siendo inviables hoy en dia.

  • RuleML (http://www.ruleml.org/)es un ejemplo de lenguaje de reglas basado en XML, si la base de conocimiento no es demasiado extensa, funciona perfectamente. Pero...
  • ........¿que tipo de toma de decisiones tiene una base de conocimiento relativamente pequeña?. Desde luego las decisiones estratégicas no, con lo que una de mis primeras intuiciones, aplicar reglas basadas en conocimiento en los sistemas estratégicos, parece que se va limitar a ambitos de actuación muy especializados. Mi gozo en un pozo.

La no utilización de reglas nos origina el problema de la poca capacidad expresiva del conocimiento. Hay varias alternativas una de ellas es utilizar lenguajes lógicos que alternen capacidad expresiva y posibilidades computacionales reales, ya que la lógica de predicados de primer orden es intrinsecamente indecidible.

  • OWL-DL, reduce las posiblidades expresivas de la lógica de predicados de primer order obteniendo un lenguaje de razonamiento de capacidad exponencial pero que puede ser procesado (ya no es indecidible, aunque es exponencial). OWL-DL tiene la potencia suficiente como para representar un modelo de Entidad-Relacion (E-R) (OWL-DL can represent E-R Models). Actualmente se esta investigando como mapear modelos OWL-DL sobre diagramas UML. Con lo que se nos abriría una via importante para su utilizacion en entornos decisionales operacionales.

La otra alternativa es la utilizacion de ontologías lígeras (sin reglas) pero fortalecidas con "razonadores" que expanden las consultas utilizando una base de datos relacional y por lo tanto todas las capacidades de ejecución y optimización que poseen en la actualidad. Esta alternativa no plantea problemas de escalabilidad, y aunque no es tan purista, posiblemente sea mas fácil de implantar para entornos tácticos y estratégicos.

Así pues ya tenemos una idea de como crear nuestras ontologias decisionales, pero lo que no sabemos es lo fundamental... ¿como le hago una pregunta? ¿me sirve el SQL de toda la vida?. Obviamente no. Existen lenguajes de consulta específicos para atacar a las ontologías, uno de ellos es SPARQL( Un lenguaje de consulta para RDF ). No es el único, exiten otros como RDQL y RQL, pero es el que parece que se convertirá en estándar de la W3C.

Así que ya podemos pensar en que al SQL le ha salido un nuevo compañero de viaje. Sin duda en el futuro los sistemas decisionales hablaran SPARQL.