¿Qué es un link en Data Vault?

Los hubs le dicen qué clientes, productos y pedidos existen. No dicen nada sobre cómo se relacionan entre sí. Esa es la función del link.

En términos de modelado clásico, una relación se convierte en un link. Dicho de forma sencilla, una clave foránea en un modelo en tercera forma normal es la base de un link. Si la tabla Order contiene un customer_id, el Data Vault tiene un link entre el hub de pedidos y el hub de clientes.

El link clásico

Un link registra una relación entre business keys: este pedido pertenece a este cliente, este contrato cubre este producto. Al igual que un hub, no almacena datos descriptivos.

Una tabla de link contiene:

• Link hash key. La clave primaria, un hash calculado sobre las business keys de todos los hubs que conecta.
• Hash keys de los hubs. Una columna por cada hub participante.
• Load Date. El momento en que se vio la relación por primera vez.
• Record Source. El sistema que la entregó.

Los links, como los hubs, solo admiten inserciones. Una relación que se ha visto una vez permanece en el link; saber si sigue siendo válida hoy corresponde a un effectivity satellite, al que se dedicará un artículo posterior de esta serie.

Tal como lo describen los manuales, Data Vault modela todos los links como n:m, para que nunca haya que reconstruirlos cuando una relación 1:n pasa a ser n:m tras una fusión o la llegada de un nuevo sistema. Pero que la estructura sea n:m no significa que los datos lo sean. Si un pedido se asigna a otro cliente, no pasa a pertenecer a dos clientes: el nuevo cliente sustituye al anterior. Para leer correctamente un link, hay que conocer su lado director.

En Datavault Builder, el link clásico es un link binario entre dos hubs y lleva su cardinalidad: 1:1, n:1, 1:n o n:m. La cardinalidad define qué lado dirige la relación, de modo que un cambio en el lado director se interpreta como una sustitución y no como una relación adicional.

Si conoce el modelado de datos clásico, ya conoce el link

El link de transacción

Para las transacciones, Datavault Builder añade un segundo tipo de link. Una transacción, como una línea de pedido, un pago o una línea de entrega, se relaciona con varios hubs a la vez, y el Data Vault convencional suele guardarla directamente en un link, a veces uno no historizado con dependent child keys. La granularidad queda entonces implícita: es la combinación de claves que, por casualidad, hace única una fila. Si la fuente asigna más tarde una línea de pedido a otro cliente, ese link contiene dos filas para la misma línea, y nada en el modelo indica cuál de ellas describe la transacción.

El link de transacción hace explícita la granularidad. La granularidad más fina de la transacción recibe su propio hub, el grain hub (Hub_Sales_Order_Line, Hub_Payment_Transaction), y el link se ancla en él. Eso da al link de transacción cuatro propiedades, cada una con su razón de ser:

• Una granularidad fija. Hay una entrada de link por cada línea de pedido, y la granularidad no puede variar.

• Un lado director definido. El grain hub dirige la relación. Si una línea de pedido recibe un producto nuevo, este sustituye al anterior; la línea no termina apuntando a dos productos a la vez.

• Relaciones identificadoras y no identificadoras. El grain hub es la identidad de la transacción. El cliente, el producto y la tienda participan como referencias, la misma distinción que hace el modelado entidad-relación clásico.

  «La clave, toda la clave y nada más que la clave, así me ayude Codd». El resumen clásico de la tercera forma normal de Codd también vale aquí: el grain hub es la clave de la transacción, y todo lo demás la describe o remite a otro concepto.

• Atributos en un hub. La cantidad, el precio y el estado van en un satélite normal del grain hub. Pueden cargarse de forma incremental como cualquier otro satélite, y más adelante pueden añadirse más atributos sin remodelar nada. Data Vault también permite link satellites para esto; según nuestra experiencia, el mejor lugar es un hub, y lo mismo vale para una tabla asociativa con atributos, como un rol o un porcentaje en la asignación de un cliente a un contrato.

Cómo se resuelve el problema del link a link

La primera regla de Data Vault es que los links conectan hubs. Un link no puede hacer referencia a otro link.

Sin embargo, las transacciones reales se relacionan constantemente con otras transacciones: una línea de factura corresponde a una línea de entrega, un pago liquida una factura, una devolución hace referencia a una línea de pedido. La solución convencional es aplanarlo todo en un único link compuesto con seis o más claves de hub, que resulta difícil de leer y convierte cada carga en una unidad de trabajo enorme.

Con los links de transacción, el problema desaparece. Cada transacción ya tiene un grain hub, de modo que una relación entre dos transacciones es un link normal entre dos hubs:

Hub_Delivery_Line ↔ Link_Delivery_To_Invoice ↔ Hub_Invoice_Line

Sin referencias de link a link, sin soluciones provisionales con dependent child keys, y con cada link lo bastante pequeño como para poder leerlo.

El patrón se remonta a 2017, cuando lo describí por primera vez en «Sobre Links», incluida su comparación con el estándar Data Vault 2.0.

Qué cambia con Datavault Builder

• Los dos tipos de link, en un mismo modelo. Links binarios para las relaciones entre datos maestros, links de transacción allí donde la relación es una transacción.
• La cardinalidad y la granularidad son decisiones del modelo. Usted indica la cardinalidad de un link binario, o qué es una transacción, y la herramienta construye a partir de ello el link y sus cargas.
• El código se genera. Las hash keys, la unidad de trabajo y la carga de solo inserción siguen el mismo patrón en todos los links, en Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL.

Qué debe decidir

Tome sus tres transacciones más importantes y anote, para cada una, qué constituye una ocurrencia. Si la respuesta es una combinación de cliente, producto y fecha en lugar de un número de línea o de documento, la granularidad es implícita, y es ahí donde un link de transacción dará estabilidad al modelo.