Data Warehousing, Data Warehouse y Datamart

¿Qué pasa cuando hemos identificado la necesidad de mejorar los sistemas que dan soporte a la toma de decisiones en nuestra organización? Rápidamente, nos hallamos en un contexto que si bien tiene puntos en común con nuestro modelo de negocio y nuestras aplicaciones transaccionales, nos deja descolocados. Más de la mitad de términos que se usan en las presentaciones de productos nos son desconocidos.

Así que de nuevo nos situamos desde el marco de establecer significados etimológicos. Recordemos que dimos ya las definiciones de Inmon y Kimball. Para empezar es necesario tener claro que significan los términos Data Warehousing, Data Warehouse y Data Mart que participan en las fases iniciales de implantación de una herramienta Business Intelligence.

Definición de Data Warehousing

Entendemos por Data Warehousing el proceso de extraer y filtrar datos de las operaciones comunes de la organización, procedentes de los distintos sistemas de información operacionales y/o sistemas externos, para transformarlos, integrarlos y almacenarlos en un depósito o almacén de datos (Data Warehouse, en inglés) con el fin de acceder a ellos para dar soporte en el proceso de toma de decisiones de una organización. Es decir, la finalidad es convertir los datos operacionales en información relacionada y estructurada, homogénea y de mayor calidad, identificada convenientemente y que se mantenga en el tiempo, es decir, los datos más recientes no sustituyen a los precedentes, pero tampoco se acumulan de cualquier manera, sino que se suelen mantener con un mayor nivel de detalle los datos actuales, y de manera más agregada los datos anteriores. Se pretende crear un círculo virtuoso para la información.

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, con las propiedades siguientes: estable, coherente, fiable y con información histórica. Al abarcar un ámbito global de la organización y con un amplio alcance histórico, el volumen de datos puede ser muy grande (centenas de terabytes). Las bases de datos relacionales son el soporte técnico más comúnmente usado para almacenar las estructuras de estos datos y sus grandes volúmenes. 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.

Continuaremos, en una futura entrada, definiendo los conceptos necesarios y con la mira puesta a hablar sobre el diseño de un Data Warehouse.

Contexto para un proyecto de data warehouse

Empezamos a hablar ayer (nunca mejor dicho), sobre un tema sumamente interesante: data warehouse. Lo que por esto lares se conoce más comunmente como almacen de datos. Vamos a continuar considerando el momento de abordar la construcción del sistema de Data Warehouse.

Debemos tener presente que, a parte del propio proceso, debe existir un contexto adecuado en el que:

  1. La alta dirección apoya el proyecto.
  2. Los usuarios apoyan el proyecto.
  3. Los usuarios accederán a un amplio espectro de datos.
  4. Los usuarios necesitan herramientas restrictivas.
  5. Los usuarios entienden la relación entre la información del Data Warehouse y la ejecución de sus tareas de negocio.
  6. Los usuarios entienden que el departamento de IT les da soporte para resolver sus dudas.
  7. Tienen que existir uno o varios usuarios finales expertos: Power users.
  8. Y por otra parte, de la constitución de un equipo adecuado para la realización del proyecto (formado por expertos de diversas áreas).

Cabe decir que no se tiene un enfoque único para construir un Data Warehouse que se adapte a las necesidades de una organización, dado que las necesidades de cada una de ellas son diferentes, al igual que su contexto. Que nadie os engañe, no existen fórmulas mágicas. Sólo best practices.

Centrándonos ya en el proceso en si (pero aún desde un punto de vista genérico), se deberían establecer fases:

  1. Definir el mejor diseño para el modelo de datos. El diseño físico debe estar orientado a generar buen rendimiento en el procesamiento de consultas.
  2. Definir los procesos de extracción, filtrado, transformación y carga de datos que se deben implementar para poblar ese modelo de datos.
  3. Definir los procesos de administración de la información que permanece en el Data Warehouse.
  4. Definir las formas de consultas a la información del Data Warehouse que se le proporcionará al usuario. Para esto, debe considerarse la necesidad de resolver un problema y la potencia de consulta.
  5. Completar el modelo de consulta base, relativo a las áreas seleccionadas.
  6. Implementar los procesos estratégicos de las áreas de trabajo, es decir, implementar herramientas especializadas de Scoring, herramientas especializadas de Data Mining,…

Y uno se puede preguntar entonces, cuál podría ser una estrategia óptima:

  • Seleccionar un número de usuarios basados en el valor de la empresa y hacer un análisis de sus puntos, preguntas y necesidades de acceso de datos.
  • Posteriormente se analizan las diversas fuentes de datos para conocer los datos de origen y sus interrelaciones, determinar los temas principales de la organización, establecer metadatos y determinar la integridad de datos.
  • De acuerdo a esas necesidades y al análisis, se constituyen prototipos Data Warehousing y se prueban para que los usuarios finales puedan experimentar y modificar sus requerimientos.
  • Una vez se tenga un consenso general sobre las necesidades, entonces se consiguen los datos provenientes de los sistemas operacionales existentes a través de la empresa y/o desde fuentes externas de datos y se cargan al Data Warehouse.
  • Creación de Datamarts dependientes del Data Warehouse para los departamentos que así lo requieran por sus necesidades informacionales.
  • Establecer períodos de análisis de futuras necesidades de la organización para la futura implementación.

Y de nuevo, me pregunto ¿qué más añadirías a estas listas? ¿Qué factores deberían tenerse también en cuenta?