Starting Area (Funcionalidades: Segunda Parte)

En el anterior Post introduje como nació la Starting Area (STA de ahora en adelante).

Esta idea ha ido evolucionado y la STA cumple actualmente 4 funcionalidades y posee 2 características (que ya avancé en el anterior post)

1) Relanzar los procesos de ETL cuando los necesites.

La primera de ellas la pudimos ver en el anterior post. Se trata de tener siempre "llenos" los primeros pasos de los procesos ETL, y no borrar esa información. Para ello cogemos el último nivel de agregación desde el que construimos el DWH. Obviamente como vamos a dejar la información de forma permanente la STA debe estar obligatoriamente en una base de datos relacional diferente a la Staging Area (STG) para poder optimizarla y realizar tunning de forma separada en el caso de que el volumen de datos así lo hiciera recomendable.

2) Ser el embrión del MasterData

Obviamente todos estos procesos necesitan de una unificación del modelo cuando las fuentes de datos son heterogeneas. Por ejemplo si estamos unificando el concepto "Cliente" podemos tener un modelo E-R de Cliente en el ERP que nada tenga que ver con el "Cliente" del CRM y que en la aplicación de gestión comercial tenga otro significado muy distinto. Obviamente desde el punto de vista decisional nosotros tenemos un único "Cliente" así pues en la STA, cuando las fuentes de datos son heterogeneas ,nos quedamos con el último nivel de detalle pera una vez unificado el modelo. Así esta tabla puede ser unificada no solo en la parte decisional sino que cualquier otra aplicación que quiera hacer uso de "Clientes" puede intorducirla como su fuente de datos operacional, de esta manera tenemos el embrión de un MasterData de la organización que mas adelante pueda servirnos tanto para la parte de sistemas de información transaccionales, como para los sistemas de información decisionales. Es una buena manera de empezar a difundir el concepto de MasterData en aquella empresas que no están maduras.

3) Proveer de Reporting para la trazabilidad decisional a nivel de detalle.

Muchas veces desde el DWH necesitamos vincular con información de detalle cuyo detalle tenemos que ir a buscarlo al operacional, por eso nos puede llegar a interesar tener algún repositorio con esa información ya almacenada (siempre que no estemos tratando de información a tiempo real). Por ejemplo, si queremos saber el número de incidencias de producción la semana pasada lo tenemos fácil, pero si queremos buscar una descripción de los incidentes de gravedad 1 de esa misma semana para ponerlo en el Informe, entonces deberíamos ir al operacional. Para facilitar esto lo que podemos hacer es traernos un nivel de detalle mas bajo que el que estamos utilizando en el DWH y vincularlo con la base de la estrella al mas puro estilo Inmon, como Reporting. Alguien podría decir que esto no es mas que un ODS (Operational Data Storage) y le daría la razón pero con un matiz, y es que los ODS carga información operacional agregada y yo cargo información de detalle muy bajo, ya que la información típicamente agregada del ODS para mí es parte del modelo del DWH al combinar Inmon y Kimball en la base de la estrella.

Este nivel de detalle bajo nos puede ayudar también a crear el MasterData y nos da esa capacidad de reporting complementaria al DWH sin que tengamos que molestar a los operacionales.

4) Realizar mejora de la calidad de forma "continua"

La STA como he dicho tiene un repositorio diferente de la STG y obviamente del DWH, así que podemos lanzar los procesos de carga de la STA con una periodicidad mucho mas pequeña que no la del DWH limpiando y puliendo los datos antes de hacer la carga definitiva del DWH. Esto nos da la posibilidad de detectar los errores antes de lanzar los procesos definitivos y mas costosos, mejorando la calidad del dato y los tiempos de los procesos de carga.
De esta manera podemos construir escenarios en los que la STA se cargue diariamente y el DWH mensualmente. La mayoría de los posibles problemas de calidad del dato tienen 30 oportunidades de ser detectados antes de cargar el DWH.

Estas son las funcionalidades de la Starting Area, en el próximo (el último de esta trilogía) comentaré como construirla y sus dos características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

2) Diluirse a medida que la estructura decisional madura.

¿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 ontologías, vamos a bajar de nuevo a la parte de decisiones operacionales y tácticas.
En este ambito la creación de los Datawarehouse tienen dos grandes gurús, por un lado el archiconocido Kimball con su modelo multidimensional, y por el otro el quizás menos conocido pero no menos importante Inmon.

Me he estado leyendo este artículo que la verdad aporta poco y no es mas que una revisión de todos los conceptos de un datawarehouse, pero que me ha servido para reflexionar cual es mi propio de creación de datawarehouse y cual sería el más apropiado para una metodología ágil

MODELING STRATEGIES AND ALTERNATIVES FOR DATA WAREHOUSING

Articulo de Nenad Jukic publicado en communications of ACM en abril de este año.

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 típicas 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 compañia.



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-Relación.
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 extracción 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, además su arquitectura mejora la trazabilidad decisional. Con ella podemos desgranar un valor en un KPI hasta una serie de análisis 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 metodología á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 sería la mejor opción para una metodología ágil, nos permitirá tener la rapidez del modelo Kimball y la visión de futuro del modelo Inmon.