Arquitectura BI (Parte V): Introducción al Data Vault

BI Geek / Arquitecturas  / Arquitectura BI (Parte V): Introducción al Data Vault

Arquitectura BI (Parte V): Introducción al Data Vault

Después de haber repasado los enfoques más relevantes a la hora de construir un Data Warehouse, explorando sus grandes diferencias en cuanto al modelado de sus estructuras internas, arquitecturas involucradas y casos de uso, podemos afirmar que las técnicas de diseño de repositorios de datos, en lo que a bases de datos relacionales se refiere, no terminan con Bill Inmon y Ralph Kimball.

A principio de los 90, momento de intenso debate entre las distintas visiones del DW normalizado y el dimensional, Dan Linstedt comienza a dar forma a una nueva técnica de modelado basándose en las teorías de Inmon y Kimball. En el año 2000 publica los principios del Data Vault, técnica que, estando basada en los fundamentos del modelo normalizado y el dimensional, los aglutina tomando lo mejor de ambos enfoques y solventando sus carencias. Como el mismo Dan Linstedt afirma, la técnica Data Vault es un planteamiento híbrido que combina lo aspectos positivos de la tercera forma normal y del modelo de estrella.

Los cuatros principios primordiales que definen a este modelo son los siguientes:

  • Trazabilidad: todo registro contendrá información sobre el origen del dato y la fecha de carga, permitiendo a los auditores trazar los datos desde el DW hasta los sistemas origen.
  • No hay distinción entre datos malos y buenos: la filosofía del Data Vault es que todos los datos son relevantes, por lo que se han de almacenar todos los datos de los sistemas fuente con independencia de su posible uso de cara al negocio que los requiera explotar (que no sean de interés hoy, no implica que no lo sean mañana).
  • Tolerancia al cambio: el modelo ha de ser tolerante ante posibles cambios en el negocio. Esto es posible separando la información estructural (claves de negocio) de las variables descriptivas.
  • Velocidad de carga: el modelo ha de estar diseñado para garantizar el aprovisionamiento paralelizado de sus estructuras. Este aspecto permite obtener unas velocidades de carga notablemente superiores a las de modelos de datos convencionales.

Estos cuatro puntos le aportan al modelo Data Vault un notable salto cualitativo respecto a las técnicas de modelado tan ampliamente utilizadas a la hora de diseñar un Data Warehouse. En este sentido, el propio Bill Inmon recibió este modelo como la evolución del DW tradicional, siendo sus palabras sobre esta técnica las siguientes:

The Data Vault is the optimal choice for modeling the EDW in the DW 2.0 framework

En cuanto a la estructura interna de este modelo,  encontramos tres tipos de tablas diferenciadas por el contenido que albergan y su finalidad: hubs, links y satellites.

  • Tablas “hubs”: contienen listados de claves de negocio, entendiendo por éstas aquellas claves y/o códigos que dan sentido a la información y al negocio que definen. Ejemplos de claves de negocio son los códigos de producto, códigos de cliente, códigos de contrato, etc.
  • Tablas “link”: almacenan las relaciones existentes entre las claves de negocio albergadas en las tablas hubs, por lo que conectarán tantas tablas hubs como relaciones haya entre ellas. Este tipo de tablas guardarán las relaciones que puedan darse, por ejemplo, entre un cliente, un producto y un contrato.
  • Tablas “satellites”: contienen los atributos descriptivos y/o temporales de las claves de negocio y de
    las relaciones entre éstas. Por tanto, habrá tablas satellites conectadas a las tablas hubs, describiendo las claves en ellas contenidas; y tablas satellites conectadas a las tablas link, conteniendo campos descriptivos, cuantitativos y otros atributos de vigencia sobre las relaciones almacenadas.

diagrama-data-vaultAtendiendo al diagrama de ejemplo se observa que hubs y links conforman el esqueleto del modelo, mientras que las tablas satellites se distribuyen alrededor de éste.

Otro aspecto que nos muestra el diagrama es que no existen restricciones en lo referente a que cada tabla hub o link solo pueda tener una tabla satellite descriptiva de su contenido. Al contrario, existen una serie de premisas en función de las cuales se recomienda separar los atributos descriptivos de una misma tabla hub o link en distintas estructuras satellites. Estas recomendaciones las iremos exponiendo en próximas entradas del blog.

En lo referente a la arquitectura del modelo de Dan Linstedt, a nivel general podemos ver que no existen grandes divergencias respecto al Corporate Information Factory (CIF) de Inmon: fuentes origen – data warehouse – repositorios dimensionales/data marts departamentales.

Arquitectura Dan Linstedt

Sí es cierto que, siendo una arquitectura de alto nivel, plasma de manera explícita la capa inicial de staging, a la que le da un gran peso dentro del sistema. Ésta estará formada por tablas no historificadas que mantendrán la estructura y formatos de los sistemas fuentes, permitiendo campos nulables e incorporando atributos de trazabilidad del dato (record source, timestamp), definiéndose así una entrada de datos al dw Data Vault que garantice la traza de información hacia los sistemas fuente.

La novedad de esta arquitectura en contraste con el Corporate Information Factory (CIF) radica en la presencia de orígenes de datos NoSQL. Dan Linstedt contempla los cruces de información con estas fuentes tanto en la capa de Staging como en el propio Data Warehouse, pudiendo fluir la información en ambas direcciones Data Vault / Fuentes NoSQL.

En cuanto al Data Warehouse, éste puede contener una capa opcional a la que denomina Business Vault, modelizada siguiendo las premisas del data vault. Ésta estará presente en aquellos entornos en los que el negocio requiera un elevado número de reglas de cálculo y se situará entre el DW y los Data Marts departamentales, de forma que se evite tener que calcular reglas de negocio comunes para cada posible data mart.

 

En próximas entradas entraremos más en detalle sobre las estructuras protagonistas en esta técnica de modelización de bases de datos (hubs, links y satellites), cubriendo los atributos obligatorios y opcionales que presentan, buenas prácticas a la hora de diseñarlas, ejemplos de uso y los principios de aprovisionamiento de las mismas, repasando todos aquellos aspectos necesarios para poder modelizar con independencia un Data Warehouse en Data Vault.