Was ist ein Hub in Data Vault?

Jedes Data Warehouse muss vor allen anderen eine Frage beantworten: Über welche Dinge spricht dieses Unternehmen, und woran unterscheidet es sie? In Data Vault lautet die Antwort: der Hub.

Was ein Hub ist

Ein Hub bildet ein zentrales Geschäftsobjekt (Core Business Concept) ab: Kunde, Produkt, Konto, Vertrag. Er ist keine Kopie einer Tabelle aus dem Quellsystem. Der Kunden-Hub enthält jeden Kundenschlüssel, den das Warehouse je erhalten hat, aus jeder Quelle, jeden genau einmal.

Ein Hub speichert Identität, keinen Zustand. Er sagt nichts über den Kunden aus: Name, Adresse und Status stehen in Satelliten, und die Aufträge und Verträge des Kunden sind über Links angebunden. Der Hub hält nur fest, dass dieser Schlüssel existiert, wann das Warehouse ihn zum ersten Mal gesehen hat und woher er kam.

Wer die klassische Datenmodellierung kennt, kennt den Hub bereits

Data Vault ersetzt nicht, was Sie über Datenmodellierung gelernt haben. Es nutzt dieses Wissen weiter. Beginnen Sie mit dem konzeptionellen Modell, das Sie ohnehin erstellen würden: den Geschäftsobjekten und ihren Beziehungen zueinander. Jedes Geschäftsobjekt, jede Entität in Ihrem ER-Diagramm, wird zu einem Hub.

Nehmen Sie eine klassische Customer-Tabelle in dritter Normalform:

Nichts geht verloren, und nichts wird neu erfunden. Die Entität wird entlang von Linien aufgeteilt, die Sie bereits kennen: was sie identifiziert, was sie beschreibt und womit sie in Beziehung steht. Der Hub ist das Erste dieser drei. Deshalb ist die Suche nach Hubs dieselbe Arbeit wie bei jedem guten konzeptionellen Modell: sich auf die Geschäftsobjekte einigen und darauf, wie jedes von ihnen identifiziert wird.

Der Aufbau eines Hubs

Ein Hub hat vier Spalten, nicht mehr:

• Hash-Schlüssel. Der Primärschlüssel: ein deterministischer Surrogatschlüssel, berechnet als Hash (MD5 oder SHA-256) des Business-Keys, ergänzt um einen optionalen Kollisionscode, wo zwei Quellen denselben Schlüssel für Unterschiedliches verwenden könnten. In Datavault Builder heißt dieser Kollisionscode Business Key Prefix. Jede Tabelle, die auf den Hub verweist, berechnet denselben Wert ohne Lookup.
• Business-Key. Der Schlüssel, der die Entität in der Geschäftswelt identifiziert: eine Kundennummer, eine Fahrgestellnummer (VIN), eine IBAN. Eine Spalte oder mehrere bei einem zusammengesetzten Schlüssel, etwa Buchungskreis plus Kundennummer.
• Load Date. Wann der Business-Key zum ersten Mal im Data Vault registriert wurde.
• Record Source. Welches operative System den Schlüssel zuerst geliefert hat.

Der Business Key Prefix: gleicher Schlüssel, anderer Auftrag

Die Schweizer und die deutsche Tochtergesellschaft betreiben jeweils ihr eigenes ERP-System, und beide haben einen Auftrag 1018. Es sind zwei verschiedene Aufträge von verschiedenen Kunden. Würde nur die Auftragsnummer gehasht, fielen beide in dieselbe Hub-Zeile, und alles, was die beiden Systeme über sie wissen, würde vermischt.

Der Business Key Prefix hält sie auseinander. Jede Quelle stellt ihr Präfix vor den Schlüssel, bevor er gehasht wird, CH|1018 und DE|1018, sodass der Auftrags-Hub zwei Zeilen enthält, wie es sein soll. Setzen Sie ihn nur dort ein, wo derselbe Schlüssel wirklich Unterschiedliches bedeuten kann. Wo zwei Systeme einen Schlüssel mit gleicher Bedeutung teilen, etwa eine konzernweite Kundennummer, sollten sie ohne Präfix derselben Hub-Zeile zugeordnet werden.

Warum wir den Business-Key weder trimmen noch in Großbuchstaben umwandeln

Häufig wird empfohlen, den Business-Key vor dem Hashen zu trimmen und in Großbuchstaben umzuwandeln. Davon raten wir ab. Dadurch werden c-10442 und C-10442 zum selben Kunden, und auch ein Leerzeichen am Ende verschwindet, selbst wenn der Unterschied ein Tippfehler in der Quelle ist. Der Vault führt dann zwei Einträge und ihre Beziehungen zu einem zusammen, ohne dass es jemand bemerkt. Der Hub sollte behalten, was die Quelle geliefert hat. Die Entscheidung, dass zwei Schlüssel dasselbe bedeuten, ist eine Geschäftsregel, und sie gehört an eine sichtbare Stelle, etwa in einen Same-As-Link.

Einmal schreiben, nie aktualisieren

Hubs werden nur ergänzt (append-only). Jeder Ladevorgang vergleicht die eingehenden Schlüssel mit denen, die bereits im Hub stehen, und fügt die neuen ein. Steht ein Business-Key einmal im Hub, bleibt er für immer: keine Updates, keine Deletes.

Diese Regel hat zwei Folgen. Ein Hub-Ladevorgang hängt von nichts anderem im Modell ab, deshalb können alle Hubs parallel geladen werden. Und ein gescheiterter Ladevorgang kann einfach wiederholt werden, weil sich dieselben neuen Schlüssel nicht zweimal einfügen lassen.

Wo die Silos der Quellsysteme aufgelöst werden

Der Hub ist der Integrationspunkt des Modells. Wenn CRM und ERP einen Kunden über denselben realen Business-Key identifizieren, werden beide derselben Hub-Zeile zugeordnet, und alles, was die beiden Systeme über diesen Kunden wissen, kommt dort zusammen.

Deshalb ist der Business-Key die eigentliche Designentscheidung. Ein Schlüssel, den das Unternehmen systemübergreifend verwendet, ist die beste Wahl. Er steht nicht immer in brauchbarer Form zur Verfügung: Eine Quelle führt vielleicht nur ihre eigene technische ID oder einen Schlüssel, der mehrfach vergeben, unterschiedlich formatiert ist oder bei älteren Datensätzen fehlt. Wie man damit umgeht, behandelt ein eigener Artikel dieser Reihe: technische versus fachliche Schlüssel. Wo zwei Systeme für denselben Kunden unterschiedliche Schlüssel verwenden, hält ein Same-as-Link fest, dass sie zusammengehören.

Was nie in einen Hub gehört

• Beschreibender Kontext. Namen, Adressen, Status und Beträge gehören in Satelliten. Ein Hub, der Attribute sammelt, ist ein verkappter Satellit und ist nicht mehr stabil.
• Fremdschlüssel. Eine Store_ID im Kunden-Hub ist eine Beziehung, und Beziehungen gehören in Links.
• Attribute, die als Geschäftsobjekte auftreten. Ein Status, eine Kategorie oder ein Währungscode beschreibt etwas, ist aber kein eigenes Geschäftsobjekt. Bei Transaktionen ist das anders: In Datavault Builder erhält eine Auftragsposition oder eine Zahlung einen eigenen Grain-Hub, was der Artikel über Links erklärt.
• Ein Hub pro Quelle. Drei Kunden-Hubs, je einer für CRM, ERP und Webshop, bauen genau die Silos wieder auf, die das Warehouse beseitigen sollte.
• Surrogatschlüssel aus Quellsystemen, wo Sie sie vermeiden können. Ein IDENTITY- oder AUTO_INCREMENT-Wert aus einer Datenbank bedeutet im nächsten System nichts. Lassen Sie ihn deshalb weg, wenn es einen Business-Key gibt. Manchmal ist er jedoch der beste Schlüssel, den es gibt, etwa für die Versionen einer Tabelle, die das Quellsystem bereits historisiert, oder für die feinste Granularität einer Transaktion, auf die nichts anderes verweist. Dort kann er die richtige Wahl sein. Wann das zutrifft, behandelt der Artikel über technische versus fachliche Schlüssel.

Was sich mit Datavault Builder ändert

In Datavault Builder definieren Sie das Geschäftsobjekt einmal und ordnen ihm jede Quelle zu, indem Sie deren Business-Key festlegen. Die Tabelle, die Schlüsselbehandlung und der Ladecode werden daraus generiert und laufen nativ auf Ihrer Datenbank, ob Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL.

• Der Schlüssel ist eine Modellentscheidung, kein Code-Muster. Sie entscheiden, was einen Kunden identifiziert. Die Hash-Berechnung und die Insert-Logik zu schreiben, gehört nicht zu dieser Entscheidung.
• Neue Quellen werden demselben Hub zugeordnet. Den Webshop hinzuzufügen heißt, seine Kundennummer dem bestehenden Kunden-Hub zuzuordnen, nicht einen neuen zu bauen.
• Das Muster ist jedes Mal dasselbe. Ein von Hand geschriebener Hub-Ladevorgang wird mit jeder neuen Quelle kopiert, angepasst und leicht verändert. Ein generierter weicht nicht ab.

Was Sie entscheiden sollten

Listen Sie die fünf bis zehn Geschäftsobjekte auf, um die es in Ihren Berichten tatsächlich geht, und notieren Sie für jedes den Schlüssel, mit dem das Unternehmen es identifiziert. Wo zwei Abteilungen Ihnen unterschiedliche Antworten geben oder eine Quelle gar keinen brauchbaren Schlüssel hat, haben Sie die wertvollste Integrationsarbeit des Projekts gefunden.