En cada entrevista donde me invitan a participar siempre incluyo la pregunta ¿Qué prefieres Inmon o Kimball? Y de esa simple pregunta puedo obtener mucha información valiosa de si una persona sabe de lo que estamos hablando, ha trabajado con sus propias manos en ello o simplemente se está montando un farol. Por supuesto la respuesta no es sencilla y en la mayoría de los casos no existe una respuesta incorrecta, salvo que sigas montándote el farol. Solemos escuchar la preferencia personal con ejemplos prácticos y veces escuchar disertaciones apasionadas y teóricos sobre los beneficios de uno sobre el otro. ¿Pero existe tal diferencia hoy en día? Averigüémoslo juntos, vamos a ello.
Un poco de historia
Una vez comencé a trabajar en una empresa de servicios de entrega de paquetes. Dentro de mis investigaciones iniciales para saber cuál era el dolor de la empresa, desde el punto de vista de los datos, me encontré que la directiva se quejaba que los informes tardaban mucho en desplegarse. Por otro lado, la gente operativa se quejaba que a veces las transacciones sobre el sistema de ser muy fluidas se quedaban pilladas y todo el sistema se ralentizaba.
Al llevar estos “dolores” al equipo de desarrollo y datos me encontré con la sorpresa que tenía una sola gran base de datos transaccional que servía para todo, tanto para las transacciones operativas y para los informes ejecutivos. Es decir, sobre el OLTP (Online transaction processing) recaía todo el peso del trabajo tanto transaccional como analítico. Era como estar en los años 70 y 80 del siglo pasado. Un sistema con una base de datos diseñada para facilitar la escritura de los datos de manera ágil, congruente y oportuna, era también usado de manera indiscriminada para la lectura masiva de datos e ingesta de grandes informes tan grandes como el mar, para ser analizados por la directiva y gerencia media. Esta dualidad de usos, en el caso de nuestro ejemplo, era el origen del problema tanto para los operativos como para los analistas.
Pues del ejemplo anterior fue como en las décadas de 1970 y 1980 se iniciaron los estudios académicos y prácticos sobre la optimización de la arquitectura de la información para lograr adaptar los recursos tanto para la parte transaccional (OLTP) como para la parte analítica (OLAP, Online analytical processing).
Si bien podemos decir que el término datawarehouse se le atribuye a Inmon por sus trabajos en los años 1970 y luego con la publicación de su primer libro Effective Data Base Design en 1981. El estudio había comenzado ya unos años antes que el acuñara el término. Ya para la década de 1960 los términos de dimensiones (dimension) y hecho (fact) estaban siendo estudiados y definidos por una colaboración entre la empresa General Mills y la Dartmouth College.
A principio de los años 1980 Teradata introduce una base de datos específicamente diseñada para el soporte a la toma de decisiones. Ellos hoy día siguen con la misma línea de negocio. Y a finales de esa misma década se acuña por primea vez el término "business data warehouse" dentro de un artículo, escrito por Barry Devlin y Paul Murphy (por favor no confundir con el gran ajedrecista y campeón del mundo), llamado "An architecture for a business and information system".
Ya en la década de 1990 es cuando Bill Inmon formaliza la literatura clásica de la data warehouse con su libro (1992) “Building the Data Warehouse” y unos años luego Ralph Kimball publica “The Data Warehouse Toolkit”. Y entre ellos dos se consolida y fundamenta toda la teoría de arquitectura de base de datos que hasta el sol de hoy nos basamos todos.
Enfoque Inmon
Inmon tiene una basta bibliografía, sin embargo, sus conceptos iniciales siguen en vigencia y en uso. El describe el proceso de construcción en base a cuatro pilares fundamentales. Integración, temática, tiempo variante y no volátil. Para Inmon existe un solo punto de referencia de la verdad, por lo que su proceso se concentra en proceso top-down.
Inmon defiende la alta normalización de su modelo, conllevando a este a ser estilo copo de nieve, muy similar a un modelo entidad relación de los OLTP. Lo que lleva a que los datos tengan un modelo jerárquico con una relación N:1 y con la finalidad de evitar las relaciones N:M. Este modelo garantiza la no redundancia de datos.
Integración
Por lo general los orígenes de los datos son diversos, un mismo concepto puede ser llamado en diferentes países de forma distinta, pero en el fin básico es lo mismo. Para ello usa una estrategia top-down donde se centraliza en un único punto de verdad para las diversas fuentes de información, si tenemos varios sistemas con clientes, estos deberán ser consolidados en un solo maestro de clientes y este será el único punto de verdad para la analítica del proceso productivo del negocio.
Por ejemplo, si tenemos definido un atributo como de cumplimiento del GDPR en un sistema lo definen como 0 y 1 (no cumple, cumple), pero en otro lo definen como Sí y No, en otro como S y N. para Inmon estos diversos criterios deberán ser unificados en uno solo dentro del data warehouse.