Was ist ein Link in Data Vault?

Hubs sagen Ihnen, welche Kunden, Produkte und Aufträge existieren. Sie sagen nichts darüber, wie diese zusammengehören. Das ist die Aufgabe des Links.

In der Sprache der klassischen Modellierung: Aus einer Beziehung wird ein Link. Einfach gesagt ist ein Fremdschlüssel in einem Modell in dritter Normalform die Grundlage für einen Link. Wo die Tabelle Order eine customer_id führt, hat der Data Vault einen Link zwischen dem Auftrags-Hub und dem Kunden-Hub.

Der klassische Link

Ein Link hält eine Beziehung zwischen Business-Keys fest: Dieser Auftrag gehört zu diesem Kunden, dieser Vertrag umfasst dieses Produkt. Wie ein Hub speichert er keine beschreibenden Daten.

Eine Link-Tabelle enthält:

• Link-Hash-Schlüssel. Der Primärschlüssel, ein Hash über die Business-Keys aller Hubs, die er verbindet.
• Hub-Hash-Schlüssel. Eine Spalte pro beteiligtem Hub.
• Load Date. Wann die Beziehung zum ersten Mal gesehen wurde.
• Record Source. Welches System sie geliefert hat.

Links werden wie Hubs nur ergänzt (insert-only). Eine Beziehung, die einmal gesehen wurde, bleibt im Link. Ob sie heute noch gilt, beantwortet ein Effectivity-Satellit, dem ein späterer Artikel dieser Reihe gewidmet ist.

Data Vault nach Lehrbuch modelliert jeden Link als n:m-Beziehung, damit er nie umgebaut werden muss, wenn nach einer Fusion oder einem neuen System aus einer 1:n-Beziehung eine n:m-Beziehung wird. Dass die Struktur n:m ist, heißt allerdings nicht, dass es auch die Daten sind. Wird ein Auftrag einem anderen Kunden zugeordnet, gehört er danach nicht zu zwei Kunden: Der neue Kunde ersetzt den alten. Um einen Link richtig zu lesen, müssen Sie seine führende Seite kennen.

In Datavault Builder ist der klassische Link ein binärer Link zwischen zwei Hubs, und er führt seine Kardinalität mit: 1:1, n:1, 1:n oder n:m. Die Kardinalität legt fest, welche Seite in der Beziehung führend ist. Eine Änderung auf der führenden Seite wird deshalb als Ersetzung gelesen, nicht als zusätzliche Beziehung.

Wer die klassische Datenmodellierung kennt, kennt den Link bereits

Der Transaktions-Link

Für Transaktionen ergänzt Datavault Builder eine zweite Art von Link. Eine Transaktion, etwa eine Auftragsposition, eine Zahlung oder eine Lieferposition, steht mit mehreren Hubs gleichzeitig in Beziehung, und im konventionellen Data Vault wird sie oft direkt in einem Link abgebildet, manchmal in einem nicht historisierten mit abhängigen Kindschlüsseln (Dependent Child Keys). Die Granularität ist dann implizit: Sie ergibt sich aus der Kombination von Schlüsseln, die eine Zeile zufällig eindeutig macht. Ordnet die Quelle später eine Auftragsposition einem anderen Kunden zu, enthält dieser Link zwei Zeilen für dieselbe Position, und nichts im Modell sagt, welche davon die Transaktion beschreibt.

Der Transaktions-Link macht die Granularität explizit. Die feinste Granularität der Transaktion erhält einen eigenen Hub, den Grain-Hub (Hub_Sales_Order_Line, Hub_Payment_Transaction), und der Link wird an ihm verankert. Das verleiht dem Transaktions-Link vier Eigenschaften, jede aus einem bestimmten Grund:

• Eine feste Granularität. Es gibt genau einen Link-Eintrag pro Auftragsposition, und die Granularität kann sich nicht verschieben.

• Eine definierte führende Seite. Der Grain-Hub ist in der Beziehung führend. Erhält eine Auftragsposition ein neues Produkt, ersetzt das neue Produkt das alte. Die Position verweist danach nicht auf zwei Produkte gleichzeitig.

• Identifizierende und nicht identifizierende Beziehungen. Der Grain-Hub ist die Identität der Transaktion. Kunde, Produkt und Filiale sind als Referenzen beteiligt. Das ist dieselbe Unterscheidung, die auch die klassische ER-Modellierung trifft.

  „Der Schlüssel, der ganze Schlüssel und nichts als der Schlüssel, so wahr mir Codd helfe.“ Die klassische Zusammenfassung von Codds dritter Normalform gilt auch hier: Der Grain-Hub ist der Schlüssel der Transaktion, alles andere beschreibt ihn oder verweist auf ein anderes Geschäftsobjekt.

• Attribute an einem Hub. Menge, Preis und Status kommen in einen gewöhnlichen Satelliten am Grain-Hub. Sie können wie jeder andere Satellit per Delta-Load geladen werden, und weitere Attribute lassen sich später ohne Umbau des Modells ergänzen. Data Vault erlaubt dafür auch Link-Satelliten. Unserer Erfahrung nach ist ein Hub der bessere Ort, und dasselbe gilt für eine Zuordnungstabelle mit Attributen, etwa eine Rolle oder ein Prozentsatz bei der Zuordnung eines Kunden zu einem Vertrag.

Das Link-to-Link-Problem lösen

Die erste Regel von Data Vault lautet: Links verbinden Hubs. Ein Link darf nicht auf einen anderen Link verweisen.

Echte Transaktionen stehen ständig mit anderen Transaktionen in Beziehung: Eine Rechnungsposition entspricht einer Lieferposition, eine Zahlung begleicht eine Rechnung, eine Retoure verweist auf eine Auftragsposition. Der übliche Ausweg besteht darin, alles in einen zusammengesetzten Link mit sechs oder mehr Hub-Schlüsseln zu packen. Ein solcher Link ist schwer zu lesen und macht jeden Ladevorgang zu einer großen Unit of Work.

Mit Transaktions-Links verschwindet das Problem. Jede Transaktion hat bereits einen Grain-Hub, also ist eine Beziehung zwischen zwei Transaktionen ein gewöhnlicher Link zwischen zwei Hubs:

Hub_Delivery_Line ↔ Link_Delivery_To_Invoice ↔ Hub_Invoice_Line

Kein Verweis von Link auf Link, kein Umweg über abhängige Kindschlüssel, und jeder Link bleibt klein genug, um lesbar zu sein.

Das Muster geht auf das Jahr 2017 zurück, als ich es zum ersten Mal in „Über Links im Data Vault“ beschrieben habe, einschließlich des Vergleichs mit dem Standard von Data Vault 2.0.

Was sich mit Datavault Builder ändert

• Beide Arten von Links in einem Modell. Binäre Links für Beziehungen zwischen Stammdaten, Transaktions-Links dort, wo die Beziehung eine Transaktion ist.
• Kardinalität und Granularität sind Modellentscheidungen. Sie geben die Kardinalität eines binären Links an oder legen fest, was eine Transaktion ist, und das Tool baut daraus den Link und seine Ladeprozesse.
• Der Code wird generiert. Hash-Schlüssel, Unit of Work und Insert-only-Laden folgen für jeden Link demselben Muster, auf Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL.

Was Sie entscheiden sollten

Nehmen Sie Ihre drei wichtigsten Transaktionen und notieren Sie für jede, was ein einzelnes Vorkommen ist. Lautet die Antwort eine Kombination aus Kunde, Produkt und Datum statt einer Positions- oder Belegnummer, ist die Granularität implizit, und genau dort macht ein Transaktions-Link das Modell stabil.