Kimball e Inmon y el diseño de datawarehouses.

En el anterior artículo repasamos una posible arquitectura a la hora de planificar como vamos a obtener y almacenar los datos que servirán como información en nuestro proyecto de Business Intelligence.

Terminamos comentando que existen dos figuras muy importantes en el desarrollo conceptual del datawarehousing. Ralph Kimball y Bill Inmon. A pesar de que ambas teorías persiguen los mismos objetivos, la forma de conseguirlos difiere bastante, lo que ha generado dos filosofías a la hora de diseñar nuestra estrategia de datos.

La visión de Kimball se basa en que son los procesos de negocio los que deben de marcar la forma en la que diseñamos el datawarehouse. Admite un punto de partida en la que ya existen datos más o menos organizados en datamarts, y que estos son la base del futuro datawarehouse.

Para Kimball lo más importante es que el cálculo de los datos que servirá para la toma de decisiones sea rápido, por lo que estructura los datos del datawarehouse siguiendo patrones dimensionales. Esto suele mejorar mucho su rendimiento a la hora de realizar consultas y además organiza los datos de una forma más intuitiva y natural para los usuarios.

Por todo esto se considera a la arquitectura de Kimball como una aproximación “bottom-up” del problema, ya que partimos de los datos y procesos existentes y modelamos el datawarehouse para que se adapte a ellos, tomando como premisas la eficiencia en tiempo y la representación natural de datos a costa de la normalización.

kimball representa una estrategia bottom-up Inmon representa una visión top-down
Ralph Kimball Bill Inmon

Por otra parte, su colega Inmon (quien es considerado el padre del concepto de datawarehouse) nos plantea una estrategia “top-down” del problema. Lo primero que haremos a la hora de desarrollar del datawarehouse será establecer la estructura de datos en 3FN, perfectamente normalizada y limpia. Los datos que se insertarán en esta estructura generalmente procederán de un “área de carga” en la que los datos son depurados antes de pasar a la estructura normalizada del datawarehouse.

A partir de esa estructura, se pueden establecer una serie de datamarts que agrupen de una forma más lógica (y si se quiere multidimensional) la información del datawarehouse principal. Como se puede observar, esta forma de trabajar es mucho más organizada pero menos flexible que la anterior, ya que aquí es la estructura y la normalización de los datos lo que marcará la pauta a la hora de trabajar en vez de que sean los procesos existentes de negocio.

¿Cuál es mejor? No creo que una sea mejor que otra… simplemente cada una tiene un punto diferente sobre lo que debe primar a la hora de diseñar un datawarehouse. Kimball representa la relación de los datos con el usuario final, la flexibilidad y la rápida explotación de la información. Por otra parte Inmon representa la pulcritud en el diseño y el respeto por una serie de normas que garanticen la exactitud de los datos, su integración y su coherencia.

Con el tiempo, los profesionales del datawarehousing han aprendido a fusionar ambas tendencias en modelos híbridos que recogen lo mejor de ambas soluciones. Estructuras que cierran bien el ciclo de vida de la información mediante procesos ETL y a su vez modelos dimensionales para representar la información de una forma que facilite su explotación.

1 comment to Kimball e Inmon y el diseño de datawarehouses.

Deja un comentario

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">