Data Vault 2.0 — Introducción

En los últimos meses he estado aprendiendo este modelado para la integración de datos, con cualidades sumamente deseables como auditoria de sistemas de información, flexible y escalable. Bueno, decir que es modelado es restarle importancia, en realidad es toda una metodología para un desarrollo ágil incremental de un enterprise data warehouse. Se trata de observar todos los avances realizados en mejores prácticas en el desarrollo de software y traerlos al mundo del data warehouse.

Entrando en materia vamos con la definición que nos brinda el creador de este genial modelo Dan Linstedt:

The Data Vault is a detail oriented, historical tracking and uniquely linked set of normalized tables that support one or more functional areas of business. It is a hybrid approach encompassing the best of breed between 3rd normal form (3NF) and star schema. The design is flexible, scalable, consistent and adaptable to the needs of the enterprise. It is a data model that is architected specifically to meet the needs of today’s enterprise data warehouses.

Además de esta definición lo que más me ha gustado es su enfoque en la conceptualización y procesos del negocio. Esta aproximación nos asegura unos pilares muy sólidos para nuestro data warehouse que podrá soportar nuevas reglas de negocio e incluso migración de sistemas de información (una experiencia que pronto podré ampliar pues estoy a punto de enfrentarme a esto). Me adelanto a decir que lo más importante a la hora de utilizar data vault es entender a profundidad el negocio, creo que es el secreto.

• Orientado al detalle: Almacena la información más granular posible
• Rastreo histórico: Registro de todos los cambios sucedidos, de todos los atributos de sistema de información operacional
• Tablas normales enlazadas: Modelo de datos compuesto por pocos tipos de objetos de almacenamiento (hub, link, satellite, reference, pit, bridge). Nos permite generar una solución flexible, extensible y escalable.

Este modelo está construido con el matra de “lo bueno, lo malo y lo feo” pertenece al negocio y por tanto el 100% de la información el 100% de las veces debe ser cargada al data warehouse.

Se constituye en una arquitectura de tres capas:

Entre las características más importantes es la separación entre hard rules (técnicas) y soft rules (interpretación). Esto debido a que los problemas surgen de los constantes cambios en las reglas de negocio para transformación de datos en información y el impacto que un cambio tiene en las capas superiores. Por tanto, al postergar soft rules el impacto de cambios se minimiza, dejando solamente las hard rules al inicio pues no es posible postergar decisiones de transformaciones técnicas.

En la imagen podemos observar las capas de staging, data warehouse y entrega de información, que además vienen acompañas por las hard rules y las soft rules.

1. Staging: Tiene como propósito ejecutar la extracción de los datos desde los sistemas fuentes, lo más rápido posible a fin de respetar ventanas de tiempo pactadas y generar poco impacto en desempeño.
2. Data Warehouse: Promueve propiamente la integración de todos los datos que posee el negocio mediante sus tipos de objetos normales (hub, link y sat).
3. Entrega: Provee modelos de datos para la entrega de la información de vuelta a los usuarios de negocio.
4. Hard Rules: Reglas de negocio aplicables en la ingesta de información que no cambian el sentido de los datos, más bien adecuan para el correcto tratamiento técnico.
5. Soft Rules: Reglas de negocio para interpretar, agregar, etc los datos para convertirlos en información.

En el data warehouse los elementos que se utilizan son:

• Hub: Representa un concepto del negocio y provee un listado único de las llaves que representan ese concepto. Estos deben ser independientes del sistema de información. Deben estar construidos que tengan un sentido de negocio y no ser llaves surrogadas que generalmente existen con fines técnicos.
• Link: Listado único de asociaciones atemporales entre conceptos de negocio que ocurren en los proceso de negocio. Cuando los procesos cambian, nuevos links aparecen en escena. Estos nos proveen de flexibilidad y escalabilidad. Son modelados con la posibilidad de realizar cambios en el futuro al modelo, sin impactar a los objetos ya existentes.
• Satellite: Contiene la información contextual descriptiva y que puede cambiar a través del tiempo. El mismo principio de una slow changing dimension type 2 (SCD2).

En la imagen de arquitectura observamos una distinción entre raw (data) vault y business vault. Raw vault pretende generar una integración de toda la información, tal cual está. Business Vault aplica reglas de negocio para ir generando interpretaciones de los datos y convertirlos así en información.

Data Vault Modeling es entonces un modelo que brinda elementos básicos que nos permiten crear las relaciones complejas que suceden en los procesos de negocio, ayudándonos a mantener una versión única de hechos que posteriormente presentaremos como versiones de verdad en information marts posteriores.

El framework de data vault 2.0 está compuesto de cuatro componentos:

1. Modelado: Expone las decisiones de diseño que debes tomar para mantener coherencia en tu diseño, que te permite entre muchas cosas tener la posibilidad de automatizar la mayor parte de tu data warehouse.
2. Arquitectura: Describe las características de “sistema de integración” que tu solución debería considerar. Buenas prácticas en distintas herramientas de vendors para data management o ETLs.
3. Implementación: Particularidades a tener en cuenta en la creación de ETLs, consultas de base de datos o funciones.
4. Metodología: Siendo el mundo del desarrollo de software uno que ha expuesto las mejores prácticas para el trabajo ágil y en equipo, data vault 2.0 mapea esas buenas prácticas al mundo del data warehouse incluyendo CMMI para mejora continúa, TQM para calidad de la información, PMP para control de proyectos, Scrum para desarrollo ágil y SDLC como ciclos de desarrollo.

Siempre debes tener en mente que el objetivo debe ser la automatización de la construcción de tablas, procesos de carga, evaluación de consistencia e integridad, y generación de consultas de base de datos. Aprende detalladamente las implicaciones de tus decisiones al modelar de una u otra forma. De hacerlo incorrecto, con el tiempo es posible que requieras romper algún estándar para construir un query, algo nada deseable por una herramienta de automatización.

También será excelente que leas las ideas expuestas en los siguientes blogs. Mucho de lo que expongo en esta serie de entradas las he aprendido a base de leer todos sus posts.

1. danlinstedt.com (Creador)
2. roelantvos.com
3. dm-unseen.blogspot.com
4. kentgraziano.com
5. datawarehouseautomation.guide

Los siguientes libros son indispensables:

1. Building a Scalable Data Warehouse with Data Vault 2.0 (al menos 7 veces)
2. Modeling the Agile Data Warehouse with Data Vault (al menos 3 veces y lee el post de Dan con observaciones sobre el libro o no corregirás algunas ideas expuestas aquí)

Estoy seguro que dejo por fuera varias referencias pero estas han sido las más importantes.

Haz clic en el enlace para seguir profundizando en el tema: Data Vault 2.0

Este es un repost de mi sitio original escrito en el 2017.