Arquitectura de un datawarehouse

Vamos a hablar hoy de los elementos dentro de la arquitectura Data Warehouse (que es una forma de representar la estructura global de los datos, la comunicación, los procesos y la presentación del usuario final). Como ya sabemos la construcción del data warehouse se establece como elemento crítico en el proceso de implantación de una herramienta Business Intelligence y por lo tanto resulta interesante recordar todos estos conceptos:

  • Base de datos operacional/nivel de base de datos externos: hace referencia a los sistemas operacionales/transaccionales de la organización y a fuentes que forman parte del proceso de Data Warehousing.
  • Nivel de acceso a la información: es la capa de interacción del usuario cuya finalidad es la conversión de los datos almacenados en información fácil y transparente para las herramientas de los usuarios finales.
  • Nivel de acceso a los datos: comunica el nivel de acceso a la información con el nivel operacional de forma universal.
  • Nivel de directorio de datos (metadatos): repositorio de metadatos de los datos almacenados que proporcionan información sobre el origen y sobre la transformación de los mismos en el proceso de Data Warehousing.
  • Nivel de gestión de procesos: planificación de las tareas y procesos para la construcción y mantenimiento actualizado del Data Warehouse.
  • Nivel de mensaje de la aplicación: determina el transporte de información a lo largo del entorno de computación de la organización a modo de middleware pero más allá de meramente protocolos de red.
  • Nivel Data Warehouse (físico): es el repositorio central altamente flexible de información donde residen copias de los datos operacionales y/o externos optimizados para su acceso para la consulta.
  • Nivel de organización de datos: incluye todos los procesos necesarios para seleccionar, editar, resumir (normalmente sumarizar), combinar y cargar en el Data Warehouse y en la capa de acceso a la información los datos operacionales y/o externos.

Respecto la arquitectura del Data Warehouse, podríamos considerar tres aspectos como los de mayor importancia y los presentamos en orden decreciente:

  1. Nivel de organización de datos: las organizaciones suelen tener fuentes de datos sumamente interesantes y con un gran potencial de información para la estrategia de negocio. Por lo tanto, es absolutamente necesario que exista un proceso ágil que homogeinice los datos, los depure, los transforme adecuadamente y los cargue siguiendo las necesidades de negocio de la organización. De lo que deviene que este nivel de arquitectura sea el de mayor importancia en la arquitectura dado que si no se realiza con la mayor excelencia el proyecto puede no aportar nada a la organización.
  2. Nivel de directorio de datos: el uso de metadatos es crucial para el éxito del Data Warehouse porque permiten integrar datos de diferentes fuentes, permite evitar inconsistencias en el modelo de datos, son un soporte a la calidad de los datos, es una guía para el mapping de datos en la transformación del ambiente operacional al Data Warehouse, describiendo la localización, la estructura y el significado. Debe incluir dominio, reglas de validación, derivación y transformación de los datos extraídos y es una guía de los algoritmos usados para la esquematización entre el detalle de datos actual con los datos ligeramente resumidos, y éstos con los datos completamente resumidos, etc.
  3. Nivel de gestión de procesos: los procesos de actualización y mantenimiento del Data Warehouse es el tercer aspecto que debemos comentar. Dado que las necesidades de una organización evolucionan, exactamente ocurre para la información que necesita. De modo que, a través de los metadatos, pueda realizarse un mantenimiento de los datos almacenados con una periodicidad fijada y sea fácil extender los datos almacenados.

Eso no significa que los demás puntos no sean importantes. Por ejemplo, no conviene infravalorar ni los requerimientos de Hardware ni tampoco cómo se presenta la información ni la combinación de la misma a los usuarios finales. Pero, en todo caso es posible presentar los seleccionados como los principales.

¿Qué opinan mis lectores?

Fuente: Master Business Intelligence UOC

Business Intelligence chain value (1 de 2)

La excelencia operacional en una organización transcurre necesariamente por el camino de delimitar claramente el modelo de negocio de la misma. Siguiendo la estela de los post anteriores en los que hablabamos sobre Hoshin Kanri (1 y 2) y con la vista puesta en el futuro para hablar sobre el modelo de producción de toyota (TPS), volvemos a hablar (aunque sea por un breve y fugaz momento) de los planes de mejora. Estos presentan, entre sus metas, llegar a la excelencia operacional como el que realiza la búsqueda de la perfección (aunque siempre teniendo en cuenta que es imposible llegar a la misma. No en vano es utópico pretender alcanzarla; pero, sin embargo, es factible mejorar en cada paso del proceso. Por lo que, tengamos en mente: Not the best, just better).

Entonces, una manera clara de explicar las etapas del proceso en cuyo estado final debe alcanzar la excelencia operativa es hablar del concepto de cadena de valor. Éste fue introducido por Michael Porter en 1986 y categoriza las actividades que producen valor añadido en las etapas de un proceso.

Pongámonos en contexto. Recordemos que habíamos comentado que una organización, como entidad de entropía creciente, necesita de procesos que regulen el sistema. En ese punto, considerábamos los sistemas de información como fuentes de energia para regular la entropía (en concreto, para disminuirla o en el peor e los casos mantenerla estable). Si bien el concepto de entropía en una organización puede considerarse a muchos niveles (como organización, estructura, planificación, gestión,…), queremos centrarnos en los datos que genera/accede la organización durante su proceso de negocio a lo largo de la vida de esta lo que se conoce como raw data, es decir, datos sin procesar).

Pero lo que la organización necesita, no sólo es que los datos estén gestionados por una herramienta (por ejemplo, un fabricante necesita de una herramienta PLM que permitirá agilizar el ciclo de vida de un producto) sino que esos datos puedan proporcionar información para la toma de decisiones. Es decir, ahora estamos hablando de herramientas Business Intelligence.

Si la organización necesita que la excelencia operativa esté presente en los sistemas que proporcionan información relevante, las herramientas BI no son menos. Es decir, este tipo de sistemas cuya finalidad es la de transformar datos en información con valor añadido requieren que:

  • no exista sobreinformación: una cantidad demasiado grande de KPI’s (key performance indicators) no es controlable y no tiene sentido (¿será que no hemos aplicado el principio de pareto? o… ¿deberíamos aplicar la navaja de Occam, incluso?)
  • evitar cuellos de botella: ¿está el proceso lo suficientemente bien diseñado para evitar que se generen tiempos de espera excesivos que impidan el flujo regular del proceso y haciendo que se diluya todo el beneficio del sistema?
  • considerar J.I.T (Just In Time) como una necesidad de la organización: ¿la información de valor añadido es accesible en el momento que se necesita y en la medida que ésta sea comprendida por aquellos a los que está dirigida?

Un primer paso en el camino hacia esa excelencia es construir la cadena de valor de la información en el marco de una herramienta Business Intelligence. Lo comentaremos en la segunda parte de este post.