Kimball vs Inmon. Ampliacin de conceptos del Modelado Dimensional.

Como hemos visto en la entrada anterior del Blog, estamos utilizando la metodologa desarrollada por Kimball (y su enfoque dimensional), para la construccin de nuestro DW. Aunque existen otras metodologias o enfoques para la construccin de un Data Warehouse, las mas importantes son la propia de Ralph Kimball y la definida por Will Inmon (y su enfoque Enterprise Warehouse o CIF). Es ah donde llegamos al que parece eterno dilema entre Kimball e Inmon. Para entender las diferencias entre ambos enfoques, es necesario en primer lugar tener claro algun concepto, como es la diferencia entre Data Warehouse y Data Mart ( Josep Curto nos lo explica muy bien en su blog).

Definicin de Data Warehouse: Un Data Warehouse proporciona una visin global, comn e integrada de los datos de la organizacin, independiente de cmo se vayan a utilizar posteriormente por los consumidores o usuarios. Normalmente en el almacn de datos habr que guardar informacin histrica que cubra un amplio perodo de tiempo. Pero hay ocasiones en las que no se necesita la historia de los datos, sino slo sus ltimos valores, siendo adems admisible generalmente un pequeo desfase o retraso sobre los datos operacionales. En estos casos el almacn se llama almacn operacional (ODS, Operational Data Store).

Definicin de Data Mart: Podemos entender un Data Mart como un subconjunto de los datos del Data Warehouse con el objetivo de responder a un determinado anlisis, funcin o necesidad y con una poblacin de usuarios especfica. Al igual que en un data warehouse, los datos estn estructurados en modelos de estrella o copo de nieve y un data mart puede ser dependiente o independiente de un data warehouse. Por ejemplo, un posible usos sera para el data mining.Qu diferencia existe entonces entre un data mart y un data warehouse? Su alcance. El data mart est pensado para cubrir las necesidades de un grupo de trabajo o de un determinado departamento dentro de la organizacin. Es el almacn natural para los datos departamentales. En cambio, el mbito del data warehouse es la organizacin en su conjunto. Es el almacn natural para los datos corporativos comunes.

Teniendo en cuenta esto, vamos a intentar realizar un resumen de los aspectos mas importantes de cada una de las metodologas: 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). Ampliacin de Conceptos del Modelado Dimensional Veamos algunos conceptos ms sobre el modelado dimensional: Dimensiones Las dimensiones, como ya vimos son los diferentes puntos de vista por los que queremos analizar la informacin. Las dimensiones incluyen los diferentes atributos que queremos analizar, que ademas se estructuran de forma jerrquica, conforme a diferentes niveles de detalle. Las tablas de dimensiones se construyen incluyendo todos los atributos que la incluyen de una forma desnormalizada, con una clave que identifica el mnimo nivel de detalle. Podemos distinguir varios tipos de dimensiones:

Dimensiones Normales: aquellas que agrupan diferentes atributos que estan relacionados por el ambito al que se refieren (todas las caractersticas de un cliente, los diferentes componentes de la dimensin tiempo, etc).

Dimensiones Causuales: aquella que incluye atributos que pueden causar cambios en los procesos de negocio (por ejemplo la dimensin promocin en el proceso de negocio de ventas).

Dimensiones Heterogeneas: dimensiones que agrupar conjuntos heterogeneos de atributos, que no estan relacionados entre si.

Dimensiones Roll-Up: es una dimensin que es un subconjunto de otra, necesarias para el caso en que tenemos tablas de hechos con diferente granuralidad (ver la entrada anterior del blog).

Dimensiones Junk: dimension que agrupa indicadores de baja cardinalidad como pueden ser flags o indicadores.

Dimensiones Role-playing: cuando una misma dimensin interviene en una tabla de hechos varias veces (por ejemplo, la fecha en una tabla de hechos donde se registran varias fechas referidas a conceptos diferentes), es necesario reutilizar la misma dimension, pues no tiene sentido crear tantas dimensiones como usos se hagan de ella. Para ello se definen las dimensiones Role-playing. Podemos crear vistas sobre la tabla de la dimensin completa que nos permiten utilizarla varias veces o jugar con los alias de tabla. La misma dimensin juega un rol diferente segn el sitio donde se utiliza.

Dimensiones Degeneradas: son dimensiones que no tienen ningn atributo y por tanto, no tienen una tabla especifica de dimensin. Solo se incluye para ellas un identificador en la tabla de hechos, que identifica completamente a la dimensin (por ejemplo, un pedido de ventas). Nos interesa tener identificada la transaccin (para realizar data mining, por ejemplo), pero los datos interesantes de este elemento los tenemos repartidos en las diferentes dimensiones (cliente, producto, etc).

Mini dimensiones o Dimensiones Outrigger: conjunto de atributos de una dimensin que se extraen la tabla de dimensin principal pues se suelen analizar de forma diferente. El tipico ejemplo son los datos sociodemogrficos asociados a un cliente (que se utilizan, por ejemplo, para el datamining).

Es necesario gestionar de una forma correcta los cambios que se producen en los atributos de las dimensiones (por ejemplo, el cambio de comercial o de canal de un cliente, el cambio de familia de un material, etc), que nos permitan realizar de una forma correcta el anlisis histrico de los datos. Para ello se introduce el concepto de Dimensin Lentamente Cambiante (SCD), estableciendo varios metodos para su procesamiento (que tendran que ser tenidos en cuenta en los procesos ETL). Resumiendo, tenemos varios tipos de metodos para el tratamiento (ampliar informacin en el blog de Bernabeu Dario o en BI Facil):

SCD Tipo 1: Sobreescribir: cuando hay un cambio en los valores de un atributo, sobrescribimos el valor antiguo con el nuevo sin registrar una historia. Esto significa perder toda la historia del dato, y cuando hagamos un anlisis veremos la informacin histrica desde el punto de vista actual.

SCD Tipo 2: Aadir fila: cuando hay un cambio, creamos un nuevo registro en la tabla. El nuevo registro tiene una nueva clave subrogada, de forma que una entidad de sistema operacional (por ejemplo, un cliente), puede tener varios registros en la tabla de la dimensin segn se van produciendo los cambios. Estamos gestionando un versionado, que ademas puede incluir unas fechas para indicar los periodos de validez, numerador de registros o un indicador de registro activo o no.

SCD Tipo 3: Aadir columna: cuando hay un cambio, nos guardamos el valor anterior en una columna distinta, actualizando el campo con el nuevo valor (para cada campo, tendremos una tupla valor anterior, valor actual). Solo nos vamos a guardar, por tanto, los dos ultimos valores.

Cada una de las dimensiones tiene una clave que identifica cada uno de los registros que la conforman. Para definir esta clave, podemos utilizar los mismos valores que se utilizan en los sistemas operacionales (con lo que nos estamos limitando a la forma en que estan definidos alli y seguramente estableciendo limitaciones para el futuro) o bien utilizar las llamadas Surrogated Keys (Claves Subrogadas), que son identificadores que nos inventamos en el Dw, que nos va a permitir optimizar las consultas sql y evitar las posibles limitaciones de la definicion de las claves existentes, desvinculandola totalmente de los sistemas origen, ademas del tratamiento de las SCD. Os recomiendo la lectura de la entrada del blog de BI Facil referente a este tema. Hechos Los hechos son los indicadores de negocio que dan sentido al anlisis de las dimensiones. Las tablas de hechos incluyen los indicadores asociados a un proceso de negocio en concreto, ademas de las claves de las dimensiones que intervienen en dicho proceso, en el mnimo nivel de granuralidad o detalle. Podemos tener varios tipos de tablas de hechos, como describe muy bien otra vez Josep Curto:

Transaction Fact Tables: representan eventos que suceden en un determinado espacio-tiempo. Se caracterizan por permitir analizar los datos con el mximo detalle. Reflejan las transacciones relacionadas con nuestros procesos de negocio (ventas, compras, inventario, contabilidad, etc).

Factless Fact Tables: Son tablas que no tienen medidas y representan la ocurrencia de un evento determinado. Por ejemplo, la asistencia a un curso puede ser una tabla de hechos sin metricas asociadas.

Periodic Snapshot Fact Tables: Son tablas de hecho usadas para recoger informacin de forma peridica a intervalos de tiempo regulares sobre un hecho. Nos permiten tomar una foto de la situacin en un momento determinado (por ejemplo al final del dia, de una semana o de un mes). Un ejemplo puede ser la foto del stock de materiales al final de cada da.

Accumulating Snapshot Fact Table: representan el ciclo de vida completo de una actividad o proceso, que tiene un principio y final. Suelen representar valores acumulados.

Consolidated Fact Tables: tablas de hechos construidas como la acumulacin, en un nivel de granuralidad o detalle diferente, de las tablas de hechos de transacciones.

Podemos distinguir diferentes tipos de medidas o indicadores, basadas en el tipo de informacin que recopilan as como su funcionalidad asociada (ver blog de Josep Curto):

Mtricas: valores que recogen el proceso de una actividad o los resultados de la misma. Esto medidas proceden del resultado de la actividad de negocio.
o

Mtricas de realizacin de actividad (leading): miden la realizacin de un actividad. Por ejemplo, la participacin de una persona en un evento.

Mtricas de resultado de una actividad (lagging): recogen los resultados de una actividad. Por ejemplo, la cantidad de unidades vendidas.

Indicadores clave: entendemos por este concepto, valores correspondientes que hay que alcanzar, y que suponen el grado de asuncin de los objetivos. Estas medidas proporcionar informacin sobre el rendimiento de una actividad o sobre la consecucin de una meta.
o

Key Performance Indicator (KPI): Indicadores clave de rendimiento. Ms all de la eficacia, se definen unos valores que nos explican en qu rango ptimo de rendimiento nos deberamos situar al alcanzar los objetivos. Son mtricas del proceso.

Key Goal Indicator (KGI): Indicadores de metas. Aqu podriamos incluir por ejemplo, el objetivo de rentabilidad del proceso de negocio de ventas.

Las medidas se pueden clasificar igualmente como aditivas, semiaditivas y no aditivas segn si se pueden sumarizar a lo largo de todas las dimensiones, solo para algunas o para ninguna. Igualmente, las medidas son derivadas cuando se calculan a partir de los valores de otras medidas o indicadores. Segn si desnormalizamos las tablas de dimensiones o no, tendremos un esquema de estrella (star) o copo de nieve (snowflaked). Kimball recomienda utilizar siempre la desnormalizacin total, pero esta claro que hay situaciones en las que no queda mas remedio que pasarnos al esquema copo de nieve (aunque solo sea para alguna dimensin).

Para terminar, si quereis realmente profundizar en el modelado dimensional y en las multiples variantes de situaciones que os podeis encontrar, os recomiendo la lectura del libro Advanced Data Warehouse Design, en formato electrnico.