Paradigma Bill Inmon.
Bill Inmon ve la necesidad de transferir la informacin de los diferentes OLTP (Sistemas Transaccionales) de
las organizaciones a un lugar centralizado donde los datos puedan ser utilizados para el analisis (sera el CIF
o Corporate Information Factory). Insiste ademas en que ha de tener las siguientes caractersticas:
Orientado a temas.- Los datos en la base de datos estn organizados de manera que todos los
elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre s.
Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la
organizacin, y dichos datos deben ser consistentes.
No voltil.- La informacin no se modifica ni se elimina, una vez almacenado un dato, ste se
convierte en informacin de slo lectura, y se mantiene para futuras consultas.
Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo quedan
registrados para que los informes que se puedan generar reflejen esas variaciones.
La informacin ha de estar a los mximos niveles de detalle. Los Dw departamentales o datamarts son
tratados como subconjuntos de este Dw corporativo, que son construidos para cubrir las necesidades
individuales de analisis de cada departamento, y siempre a partir de este Dw Central (del que tambin se
pueden construir los ODS ( Operational Data Stores ) o similares).
Enfoque Inmon - DW Corporativo
El enfoque Inmon tambien se referencia normalmente como Top-down. Los datos son extraidos de los
sistemas operacionales por los procesos ETL y cargados en las areas de stage, donde son validados y
consolidados en el DW corporativo, donde ademas existen los llamados metadatos que documentan de una
forma clara y precisa el contenido del DW. Una vez realizado este proceso, los procesos de refresco de los
Data Mart departamentales obtienen la informacin de el, y con las consiguientes transformaciones,
organizan los datos en las estructuras particulares requeridas por cada uno de ellos, refrescando su
contenido.
La metodologia para la construccin de un sistema de este tipo es la habitual para construir un
sistema de informacin, utilizando las herramientas habituales (esquema Entidad Relacion, DIS
(Data Item Sets, etc). Para el tratamiento de los cambios en los datos, usa la Continue and Discrete
Dimension Management (inserta fechas en los datos para determinar su validez para las Continue
Dimension o bien mediante el concepto de snapshot o foto para las Discrete Dimension).
Al tener este enfoque global, es mas dificil de desarrollar en un proyecto sencillo (pues estamos intentando
abordar el todo, a partir del cual luego iremos al detalle).
Paradigma Ralph Kimball.
El Data Warehouse es un conglomerado de todos los Data Marts dentro de una empresa, siendo una copia de
los datos transaccionales estructurados de una forma especial para el analisis, de acuerdo al Modelo
Dimensional (no normalizado), que incluye, como ya vimos, las dimensiones de anlisis y sus
atributos, su organizacin jerarquica, asi como los diferentes hechos de negocio que se quieren
analizar. Por un lado tenemos tablas para las representar las dimensiones y por otro lado tablas para los
hechos (las facts tables). Los diferentes Data Marts estan conectados entre si por la llamada bus structure,
que contiene los elementos anteriormente citados a traves de las dimensiones conformadas (que permiten
que los usuarios puedan realizar querys conjuntos sobre los diferentes data marts, pues este bus contiene
los elementos en comn que los comunican). Una dimensin conformada puede ser, por ejemplo, la
dimensin cliente, que incluye todos los atributos o elementos de analisis referentes a los clientes y que
puede ser compartida por diferentes data marts (ventas, pedidos, gestin de cobros, etc).
Enfoque Kimball - Arquitectura Bus del DW
Este enfoque tambin se referencia como Bottom-up, pues al final el Datawarehouse Corporativo no es mas
que la unin de los diferentes datamarts, que estan estructurados de una forma comn a travs de la bus
structure. Esta caracteristica le hace mas flexible y sencillo de implementar, pues podemos construir un Data
Mart como primer elemento del sistema de anlisis, y luego ir aadiendo otros que comparten las
dimensiones ya definidas o incluyen otras nuevas. En este sistema, los procesos ETL extraen la informacin
de los sistemas operacionales y los procesan igualmente en el area stage, realizando posteriormente el
llenado de cada uno de los Data Mart de una forma individual, aunque siempre respetando la estandarizacion
de las dimensiones (dimensiones conformadas).
La metodologa para la construccin del Dw incluye las 4 fases que vimos en la entrada anterior del blog, que
son: Seleccin del proceso de negocio, definicin de la granuralidad de la informacin, eleccin de
las dimensiones de anlisis e identificacin de los hechos o mtricas. Igualmente define el
tratamiento de los cambios en los datos a travs de las Dimensiones Lentamente Cambiantes (SCD).
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
ontologas, vamos a bajar de nuevo a la parte de decisiones operacionales y tcticas.
En este ambito la creacin de los Datawarehouse tienen dos grandes gurs, por un lado el
archiconocido Kimball con su modelo multidimensional, y por el otro el quizs menos conocido pero
no menos importante Inmon.
Me he estado leyendo este artculo que la verdad aporta poco y no es mas que una revisin de todos
los conceptos de un datawarehouse, pero que me ha servido para reflexionar cual es mi propio de
creacin de datawarehouse y cual sera el ms apropiado para una metodologa gil
MODELING STRATEGIES AND ALTERNATIVES FOR DATA WAREHOUSING
Articulo de Nenad Jukic publicado en communications of ACM en abril de este ao.
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
tpicas
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
compaia.
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-Relacin.
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 extraccin 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, adems su
arquitectura mejora la trazabilidad [Link] ella podemos desgranar un valor en un KPI hasta
una serie de anlisis 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 metodologa 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 sera la mejor opcin para una metodologa gil, nos permitir tener la rapidez del
modelo Kimball y la visin de futuro del modelo Inmon.