What Is a Link in Data Vault?

Hubs tell you which customers, products and orders exist. They say nothing about how those things belong together. That is the job of the link.

In classical modeling terms: a relationship becomes a link. Put simply, a foreign key in a third normal form model is the basis for a link. Where the Order table carries a customer_id, the Data Vault has a link between the order hub and the customer hub.

The classic link

A link records a relationship between business keys: this order belongs to this customer, this contract covers this product. Like a hub, it stores no descriptive data.

A link table carries:

• Link hash key. The primary key, a hash over the business keys of every hub it connects.
• Hub hash keys. One column per participating hub.
• Load date. When the relationship was first seen.
• Record source. Which system delivered it.

Links are insert-only, like hubs. A relationship that is seen once stays in the link; whether it is still valid today is a question for an effectivity satellite, which is a later article in this series.

Textbook Data Vault models every link as many-to-many, so it never has to be rebuilt when a one-to-many turns into a many-to-many after a merger or a new system. The structure being many-to-many does not mean the data is, though. If an order is moved to a different customer, it does not now belong to two customers: the new customer replaces the old one. To read a link correctly, you have to know its driving side.

In Datavault Builder the classic link is a binary link between two hubs, and it carries its cardinality: one-to-one, many-to-one, one-to-many or many-to-many. The cardinality says which side drives the relationship, so a change on the driving side is read as a replacement, not as an additional relationship.

If you know classical data modeling, you already know the link

The transaction link

For transactions, Datavault Builder adds a second kind of link. A transaction, such as an order line, a payment or a delivery line, relates to several hubs at once, and conventional Data Vault often puts it straight into a link, sometimes a non-historized one with dependent child keys. The grain is then implicit: whatever combination of keys happens to make a row unique. If the source later moves an order line to a different customer, that link holds two rows for the same line, and nothing in the model says which one describes the transaction.

The transaction link makes the grain explicit. The finest grain of the transaction gets its own hub, the grain hub (Hub_Sales_Order_Line, Hub_Payment_Transaction), and the link is anchored on it. That gives the transaction link four properties, each for a reason:

• A fixed grain. There is one link entry per order line, and the grain cannot drift.

• A defined driving side. The grain hub drives the relationship. If an order line gets a new product, the new product replaces the old one; the line does not now point to two.

• Identifying and non-identifying relationships. The grain hub is the identity of the transaction. Customer, product and store participate as references, the same distinction classical ER modeling makes.

  “The key, the whole key, and nothing but the key, so help me Codd.” The classic summary of Codd’s third normal form holds here too: the grain hub is the key of the transaction, and everything else either describes it or refers to another concept.

• Attributes on a hub. Quantity, price and status go into an ordinary satellite on the grain hub. They can be delta loaded like any other satellite, and more attributes can be added later without remodeling. Data Vault also allows link satellites for this; our experience is that a hub is the better home, and the same applies to an associative table that carries attributes, such as a role or a percentage on a customer-to-contract assignment.

Solving the link-to-link problem

The first rule of Data Vault is that links connect hubs. A link may not reference another link.

Real transactions relate to other transactions all the time: an invoice line matches a delivery line, a payment settles an invoice, a return references an order line. The conventional workaround is to flatten everything into one composite link with six or more hub keys, which is hard to read and turns every load into a large unit of work.

With transaction links the problem disappears. Every transaction already has a grain hub, so a relationship between two transactions is an ordinary link between two hubs:

Hub_Delivery_Line ↔ Link_Delivery_To_Invoice ↔ Hub_Invoice_Line

No link-to-link reference, no dependent child workaround, and every link stays small enough to read.

The pattern goes back to 2017, when I first described it in On Links, including how it compares with the Data Vault 2.0 standard.

What changes with Datavault Builder

• Both kinds of link, in one model. Binary links for relationships between master data, transaction links where the relationship is a transaction.
• Cardinality and grain are model decisions. You state the cardinality of a binary link, or what one transaction is, and the tool builds the link and its loads from that.
• The code is generated. Hash keys, unit of work and insert-only loading follow the same pattern for every link, on Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle or PostgreSQL.

What to decide

Take your three most important transactions and write down, for each, what one occurrence is. If the answer is a combination of customer, product and date rather than a line or document number, the grain is implicit, and that is where a transaction link will make the model stable.