15.2.Kimball vs Inmon. Ampliación de conceptos del Modelado Dimensional.

Como hemos visto en la entrada anterior del Blog, estamos utilizando la metodología desarrollada por Kimball (y su enfoque dimensional), para la construcción de nuestro DW. Aunque existen otras metodologias o enfoques para la construcción 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).

• Definición de Data Warehouse: Un Data Warehouse proporciona una visión global, común e integrada de los datos de la organización, independiente de cómo se vayan a utilizar posteriormente por los consumidores o usuarios. Normalmente en el almacén de datos habrá que guardar información histórica que cubra un amplio período de tiempo. Pero hay ocasiones en las que no se necesita la historia de los datos, sino sólo sus últimos valores, siendo además admisible generalmente un pequeño desfase o retraso sobre los datos operacionales. En estos casos el almacén se llama almacén operacional (ODS, Operational Data Store).
• Definición 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 análisis, función o necesidad y con una población de usuarios específica. Al igual que en un data warehouse, los datos están 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 sería 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 organización. Es el almacén natural para los datos departamentales. En cambio, el ámbito del data warehouse es la organización en su conjunto. Es el almacén 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 metodologías:

Paradigma Bill Inmon.

Bill Inmon ve la necesidad de transferir la información de los diferentes OLTP (Sistemas Transaccionales) de las organizaciones a un lugar centralizado donde los datos puedan ser utilizados para el analisis (sería el CIF o Corporate Information Factory). Insiste ademas en que ha de tener las siguientes características:

• Orientado a temas.- Los datos en la base de datos están 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 organización, y dichos datos deben ser consistentes.
• No volátil.- La información no se modifica ni se elimina, una vez almacenado un dato, éste se convierte en información de sólo 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 información ha de estar a los máximos 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 también 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 información 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 construcción de un sistema de este tipo es la habitual para construir un sistema de información, 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 análisis y sus atributos, su organización 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 común que los comunican). Una dimensión conformada puede ser, por ejemplo, la dimensión 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, gestión de cobros, etc).

Enfoque Kimball - Arquitectura Bus del DW

Este enfoque también se referencia como Bottom-up, pues al final el Datawarehouse Corporativo no es mas que la unión de los diferentes datamarts, que estan estructurados de una forma común a través 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 análisis, y luego ir añadiendo otros que comparten las dimensiones ya definidas o incluyen otras nuevas. En este sistema, los procesos ETL extraen la información 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 metodología para la construcción del Dw incluye las 4 fases que vimos en la entrada anterior del blog, que son: Selección del proceso de negocio, definición de la granuralidad de la información, elección de las dimensiones de análisis e identificación de los hechos o métricas. Igualmente define el tratamiento de los cambios en los datos a través de las Dimensiones Lentamente Cambiantes (SCD).

Si quereis profundizar en cada una de las filosofias, incluyendo las similitudes y diferencias, os recomiendo leer la presentación realizada por Ian Abramson:

Ver este documento en Scribd

Ahora llega el momento de elegir cual de los enfoques es el mas apropiado para nuestro proyecto (suponiendo que aun no lo hubieramos hecho). En la entrada de blog de Jorge Fernández se planteo un interesante debate sobre la conveniencia de utilizar uno u otro enfoque. Podemos resumir que el enfoque Inmon es mas apropiado para sistemas complejos, donde ademas queremos asegurar su perdurabilidad y consistencia aunque cambien los procesos de negocio en la organización. Pero para pequeños proyectos, donde ademas queremos asegurar la usabilidad de los usuarios con un sistema facil de entender y el rapido desarrollo de la solución, el enfoque Kimball es mas apropiado.

En nuestro caso, vamos a realizar un DW departamental, que ademas es un proyecto piloto. Dado el ambito, y los recursos que se van a destinar a el, es mas conveniente utilizar el enfoque Kimball para el diseño del DW. El DW seria lo mas cercano a un datamart, y lo vamos a desarrollar intentando que las dimensiones esten conformadas (dentro del concepto de datawarehouse bus), con lo que dejaremos la puerta abierta a una ampliación posterior dentro el ámbito de la compañia, añadiendo nuevos cubos que utilizaran las dimensiones conformadas ya definidas.

Ademas de estos dos enfoques, existen otros de los que no hablaremos, como el Hybrid DW o el Federated DW, que utilizan una aproximación intermedia para la construcción del sistema.

Ampliación de Conceptos del Modelado Dimensional

Veamos algunos conceptos más sobre el modelado dimensional:

Dimensiones

Las dimensiones, como ya vimos son los diferentes puntos de vista por los que queremos analizar la información. Las dimensiones incluyen los diferentes atributos que queremos analizar, que ademas se estructuran de forma jerárquica, 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 mínimo 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 características de un cliente, los diferentes componentes de la dimensión tiempo, etc).
• Dimensiones Causuales: aquella que incluye atributos que pueden causar cambios en los procesos de negocio (por ejemplo la dimensión promoción 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 dimensión 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 dimensión 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 dimensión completa que nos permiten utilizarla varias veces o jugar con los alias de tabla. La misma dimensión juega un rol diferente según el sitio donde se utiliza.
• Dimensiones Degeneradas: son dimensiones que no tienen ningún atributo y por tanto, no tienen una tabla especifica de dimensión. Solo se incluye para ellas un identificador en la tabla de hechos, que identifica completamente a la dimensión (por ejemplo, un pedido de ventas). Nos interesa tener identificada la transacción (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 dimensión que se extraen la tabla de dimensión principal pues se suelen analizar de forma diferente. El tipico ejemplo son los datos sociodemográficos 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 análisis histórico de los datos. Para ello se introduce el concepto de Dimensión 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 información 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 análisis veremos la información histórica desde el punto de vista actual.
• SCD Tipo 2: Añadir 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 dimensión según 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: Añadir 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 análisis 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 mínimo 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 máximo 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 información de forma periódica a intervalos de tiempo regulares sobre un hecho. Nos permiten tomar una foto de la situación 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 día.
• 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 acumulación, 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 información que recopilan así como su funcionalidad asociada (ver blog de Josep Curto):

• Métricas: valores que recogen el proceso de una actividad o los resultados de la misma. Esto medidas proceden del resultado de la actividad de negocio.
  • Métricas de realización de actividad (leading): miden la realización de un actividad. Por ejemplo, la participación de una persona en un evento.
  • Métricas 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 asunción de los objetivos. Estas medidas proporcionar información sobre el rendimiento de una actividad o sobre la consecución de una meta.
  • Key Performance Indicator (KPI): Indicadores clave de rendimiento. Más allá de la eficacia, se definen unos valores que nos explican en qué rango óptimo de rendimiento nos deberíamos situar al alcanzar los objetivos. Son métricas 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 según 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.

Según si desnormalizamos  las tablas de dimensiones o no, tendremos un esquema de estrella (star) o copo de nieve (snowflaked). Kimball recomienda utilizar siempre la desnormalización 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 dimensión).

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 electrónico.