Data Vault: Hubs, Links & Satellites

BI Geek / Arquitecturas  / Data Vault: Hubs, Links & Satellites
data-vault-estructuras

Data Vault: Hubs, Links & Satellites

Después de haber presentado los principios generales de la técnica Data Vault en el anterior artículo, en esta nueva entrada al blog nos vamos a adentrar en mayor detalle en las principales estructuras que conforman el esqueleto de un modelo de datos Data Vault: hubs, links y satellites.

Cabe resaltar que en Data Vault existen también otras estructuras o tipos de tablas de gran utilidad para casos concretos. Sin embargo, las que toman protagonismo en este artículo constituyen los pilares sobre los que recae el peso de esta técnica de modelado.

 

Hub Tables

Las tablas hub contiene las claves de negocio, entendiendo como tal aquellos códigos que identifican los componentes del negocio de una compañía, como puede ser el código producto, el código cliente o el código de factura. Se consideran el principal pilar de un modelo Data Vault.

El contenido de estas tablas está formado por los códigos de negocio, la clave primaria (hash key) y los campos de metadata. La finalidad de estos últimos es proporcionar información que garantice la trazabilidad de la información de cara a posibles auditorias y a la identificación de anomalías en los datos. Los campos que intervienen en los hubs son los siguientes:

  • Clave primaria: Estará compuesta por un código hash generado a partir del código de negocio que identifica. Se emplearán algoritmos de criptografía que serán explicados en el siguiente artículo.
  • Clave de negocio: Como puede ser el código cliente, el código de producto, etc.
  • Load Date: Este campo es generado por el sistema y contiene la fecha y hora a la que el registro llegó al Data Warehouse.
  • Record Source: Campo hard-codeado que contiene el sistema origen del que proviene el código de negocio:

– En caso de tener dos orígenes se incluirá el de mayor peso de cara al negocio

– Si el registro es fruto de una regla de negocio (cálculo o agregación) dentro del Data Warehouse, se puede incluir el nombre de la regla de negocio o el estándar “System”

– Last Seen Date: Es un campo opcional que almacena la última fecha en que una determinada clave de negocio se detectó en las fuentes origen. Durante el aprovisionamiento de las tablas hub se compara si una clave de negocio existe o no en el Data Warehouse, de forma que solo se insertan las nuevas. Es este el punto en el que, para claves de negocio ya presentes en el modelo, se actualizará esta fecha Last Seen Date con la fecha de carga (Load Date). En función del negocio, contener esta fecha puede ser de gran utilidad.

Mencionar que los campos propios de la metodología data vault (atributos de metadata y los propios de cada estructura, tanto obligatorios como opcionales) se colocan al principio de cada estructura. La intención de la metodología es establecer un orden común en todos los proyectos, por lo que esta premisa también tiene aplicación en el caso de links y satellites.

Es importante saber diferenciar las claves de negocio de aquellos atributos que no forman parte del negocio pero aportan contexto al mismo. Ejemplos de estos son los ISO de divisa, códigos postales, códigos de país, fechas y sus jerarquías, etc. Esta información se almacena en “Tablas de Referencia”, similares a dimensiones no historificadas, de las que hablaremos en próximos artículos.

A continuación, se muestran cuatro ejemplos de tablas hub: hub de contratos, hub de contrapartidas, hub de entidades y hub de producto.

ejemplo-hub-data-vault-2ejemplo-hub-data-vault-3ejemplo-hub-data-vault-1ejemplo-hub-data-vault-4

 

Link Tables

Las tablas link contiene las relaciones existentes entre claves de negocio, es decir, entre hubs. En este sentido, estas estructuras van a contener cualquier conexión existente entre los componentes del negocio, como pueden ser transacciones, asociaciones, jerarquías, etc. Un ejemplo sería la relación entre un cliente, un producto y un pedido en un momento dado.

Son tablas que representan relaciones de “muchos a muchos”, conectando dos o más códigos de negocio. Es por ello que, al igual que en una tabla de hechos en un modelo dimensional, donde la granularidad viene definida por el número de dimensiones que conecta, la granularidad de las tablas link dependerá del número de hubs que relaciona. Estas tablas contendrán las claves primarias de aquellas clave de negocio presentes en la relación, es decir, los códigos hash que identifican dichas claves de negocio.

Los campos que componen este tipo de estructuras son los siguientes:

  • Clave primaria: Código hash generado con las claves de negocio de la relación (no con los códigos hash generados con dichas claves de negocio).
  • Claves de negocio: Los códigos hash que referencian a los códigos de negocio partícipes en la relación. Habrá tantos campos como códigos de negocio formen la relación.
  • Load Date: Al igual que en los hubs, contiene la fecha y hora en que el registro se cargó en el Data Warehouse.
  • Record Source: Mismo campo que el de las tablas hub, contiene el sistema origen del registro.
  • Last Seen Date: Campo opcional con la misma funcionalidad que en el caso de los hubs.
  • Dependent Child key: Es un campo muy poco habitual pero que puede tener cabida en estas tablas, conocido como “defenerate field”. Por ejemplo, en el caso de un link que represente la transacción de una factura, pueden aparecer números de control generados por los procesos operacionales que solo son válidos en el contexto de la factura, careciendo de significado de negocio pero que, según el caso, puede ser de interés mantenerlos. Estos “degenerate fields” pueden aparecer también en las tablas de hechos de un modelo dimensional, como indica Kimball, careciendo de asociación con las dimensiones.

Entre las ventajas de estas tablas destaca la flexibilidad y la tolerancia al cambio que le aportan al Data Warehouse ante posibles cambios en el negocio. Estos cambios pueden afectar seriamente el modelo de un Data Warehouse normalizado (3FN) y a los procesos ETL que lo aprovisionan, como ocurriría en el caso del Corporate Information Factory de Inmon. Sin embargo, en un DW modelado con las técnicas y buenas prácticas del Data Vault, estos cambios de negocio no requieren modificaciones en las estructuras físicas presentes en el mismo. En próximos artículos sobre Data Vault explicaré detenidamente este punto con ejemplos que aporten una mayor claridad.

Un caso llamativo de uso de tablas link es el de poder vincular códigos de negocio contenidas en una misma tabla hub. Un ejemplo sería el de una tabla link que represente transacciones entre dos entidades, tanto la entidad ordenante como la entidad contrapartida estarían contenidas en la misma tabla hub “Entidades”.

Otro caso similar al anterior es el de links jerárquicos, que almacenan las relaciones entre padres e hijos de una jerarquía. En Data Vault, se considera válido almacenar en una misma tabla hub los distintos niveles de una jerarquía, siendo este tipo de tablas link las que contengan las relaciones jerárquicas. No obstante, desde mi punto de vista, evitaría generalizar el uso de este tipo de tratamiento para las jerarquías, empleándolo en casos puntuales en los que, por la naturaleza de la información, las volumetrías y el origen de los datos, tenga sentido en nuestro modelo.

Una duda muy común que surge a la hora de diseñar las tablas link es la relacionada con la posibilidad de conectar tablas links entre sí mismas. La respuesta es sí, es posible, pero se trata de una práctica totalmente desaconsejada por varias razones:

  • el modelo perdería la flexibilidad y la tolerancia la cambio, quedando expuesto a modificaciones ante posibles cambios de negocio
  • el modelo dejaría de ser intuitivo y fácilmente escalable, aspectos perseguidos por la metodología Data Vault
  • se generarían dependencias entre estructuras de una misma tipología (links), sacrificándose uno de los grandes objetivos del Data Vault, la velocidad de aprovisionamiento

Las prácticas recomendadas son modelar el Data Warehouse mediante el uso de links independientes. Esto generará un mayor número de estructuras pero le prevendrá al modelo ante los puntos anteriormente descritos.

Un caso particular de tablas links son aquellas que recogen transacciones. Estas transacciones son eventos únicos que no cambian con el tiempo, no son historificables. Por esta razón, como explicaremos en el artículo de aprovisionamiento, dado que todas las transacciones se han de recoger en la tabla link, el código hash PK de la tabla no solo estará generado con las claves de negocio de la relación, sino que tendrá como entrada adicional la fecha Load Date. De esta forma se evita que dos transacciones entre las mismas claves de negocio generen un error de clave duplicada.

En el siguiente ejemplo podemos ver las tablas hubs anteriores conectadas al link Producto:

ejemplo-links-data-vault

 

Satellite Tables

Las tablas satellites almacenan datos que describen los componentes del negocio – contenidos en las tablas hub – y las relaciones y transacciones – contenidas en las tablas link – añadiendo contexto en un momento concreto o durante un período temporal. Es por ello que el contenido de los satellies puede cambiar a lo largo del tiempo, siendo necesario trazar dichos cambios e historificarlos.

Cada tabla satellite estará conectada a una tabla hub o link mediante el código hash que constituye la PK de éstas. Dado que los satellites registrarán los cambios que sufran los datos descriptivos que almacenan, su propia clave primaría estará formada por el código hash del hub o link al que están conectadas y la fecha de carga (Load Date). De esta manera, un código de negocio o relación de códigos de negocio podrá estar conectado a varios registros de una tabla satellite, siendo el vigente el que contenga la fecha Load Date más reciente.

Es importante tener en cuenta que, en aquellos casos en los que se detecten cambios en origen sobre registros ya cargados en el Data Warehouse, no se realizarán updates sobre éstos, sino que se insertará un nuevo registro en la tabla destino, conteniendo el mismo código hash que el registro previamente cargado con la nueva fecha Load Date. Este método de historificación está basado en el tipo II de Kimball para el mantenimiento de dimensiones (Slow Changing Dimensions).

Las prácticas recomendadas son separar los atributos descriptivos de un mismo hub o link en distintas tablas según fuentes origen. De esta manera, logramos independizar los procesos de aprovisionamiento, evitando modificaciones generalizadas en caso de que una determinada fuente sufra cambios en origen, que un sistema origen desaparezca o en el supuesto de que se introduzca un nuevo aplicativo fuente, caso en el que tan solo habría que crear una nueva satellite con su propio aprovisionamiento. Así mismo, con esta medida se evitan dependencias entre fuentes origen durante el aprovisionamiento del Data Warehouse, mejorándose los tiempos de carga.

De manera adicional, atributos de un mismo origen pueden ser separados en función de su volatilidad o frecuencia de cambio. Con esta separación se evita que una tabla compuesta por diez campos descriptivos crezca constantemente por cambios en uno o dos de ellos, medida que reducirá notablemente las necesidades de almacenamiento. En este sentido, se pueden crear varias tablas en función de la frecuencia de cambio, separando atributos estáticos de atributos con cambios mensuales, diarios, etc.

Estas tablas estarán compuestas, por un lado, por aquellos campos descriptivos del hub o link y, por otro, por los campos genéricos de metadata – los obligados de los satellites y los opcionales -. Entre este segundo grupo nos encontramos los siguientes:

  • Load Date: Similar a la fecha de carga de hubs y links. En el caso de los satellites esta fecha formará parte de la clave primaria.
  • Record Source: Mismo campo que en el caso de hubs y links.
  • Parent Hash key: El código hash que forma la clave primaria del hub o link que describen. Este campo, junto a la fecha Load Date, constituirá la clave primaria del satellite.
  • Load End Date: La fecha en la que el registro se vuelve inválido. Cuando es detectado un cambio sobre un registro ya almacenado en la tabla, la fecha Load End Date de este último será actualizada con el Load Date. El nuevo registro tendrá como Load End Date un nulo o valor por defecto (9999/12/31).
  • Hash Difference: Es un código hash opcional calculado por los atributos descriptivos del registro en la capa de Staging. Es útil para comparar los registros que llegan desde las fuentes origen con los ya cargados en el Data Warehouse, identificándose rápidamente y sin necesidad de comparar cada columna descriptiva si los registros contenidos en los satellites han sufrido cambios en origen o no.

En el caso de satellites de tablas link que recogen transacciones, no será necesario incluir la fecha Load End Date, dado que las transacciones son eventos únicos que no cambian con el tiempo, son registrados como eventos aislados.

Por otro lado, no todos los link han de tener un satellite asociado, ya que no todas las relaciones tienen campos descriptivos asociados.

En la siguiente imagen se muestran ejemplos de satellites para los hub entidad, producto y contrapartida. En el caso de este último hub, para el ejemplo se ha supuesto que podríamos encontrarnos con contrapartidas con cambio frecuente de residencia y contacto, supuesto que requeriría la presencia de dos tablas satellites, una con los atributos estáticos y otra con los volátiles.

 

ejemplo-satellite-data-vault

 

En próximos artículos continuaremos profundizando sobre la técnica Data Vault, tocando temas como los códigos hash y sus usos, prácticas recomendadas a la hora de aprovisionar un Data Warehouse, la capa Business Vault y sus posibles estructuras y las buenas prácticas a tener en cuenta en nuestros proyectos con Data Vault.

El objetivo de nuestra empresa es retomar los valores originales de la consultoría y poder ofrecer un valor añadido real a nuestros clientes.