Technische Schlüssel vs. Business-Keys in Data Vault
Quellsysteme speichern den Business-Key im Stammdatensatz, doch jede Beziehung läuft über technische Schlüssel. Vier Wege, damit umzugehen, was jeder davon kostet, und das Muster, das wir verwenden: ein PSA-Hub für die technischen Schlüssel, der dem Business-Key-Hub zugeordnet wird.
Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen
Kommt Ihnen das bekannt vor?
- Die Auftragstabelle enthält nur eine system-interne Kunden-ID, und die Kundennummer steht in einer anderen Tabelle.
- Jede Quelle hat ihren eigenen Kunden-Hub erhalten, und die Daten sind nie zusammengekommen.
- Joins im Staging schlagen Business-Keys in der Quelle nach, und niemand kann mehr belegen, was die Quelle tatsächlich geliefert hat.
Data Vault baut auf Business-Keys auf: Sie sind stabil, werden systemübergreifend verwendet und überstehen Migrationen. Die Probleme beginnen, sobald Sie sich ansehen, wie Quellsysteme Beziehungen tatsächlich speichern.
Das Problem: Beziehungen laufen über technische Schlüssel
Die meisten Quellsysteme speichern den Business-Key in der Entität, die er identifiziert. Die Kundentabelle enthält die Kundennummer. Die Beziehungen dagegen verwenden die eigenen technischen Schlüssel des Systems:
| Tabelle | Spalten |
|---|---|
Customer |
customer_id = 10492, customer_number = CUST-9921, Name, Adresse |
Order |
order_id = 884102, order_number = SO-1018, customer_id = 10492 |
Der Auftrag kennt seinen Kunden nur als 10492. Um ihn mit dem Kunden-Hub zu verbinden, dessen
Schlüssel CUST-9921 ist, muss das eine in das andere übersetzt werden.
In der Sprache der klassischen Modellierung: Die Quelle verwendet für ihre Fremdschlüssel Surrogatschlüssel, Data Vault dagegen braucht den natürlichen Schlüssel. Die Frage ist, wo die Übersetzung stattfindet.
Vier Lösungswege
| Ansatz | So funktioniert er | Der Haken |
|---|---|---|
| 1. Ein Source Vault pro System | Getrennte Hubs für CRM-Kunden und Fakturierungskunden, mit technischen IDs als Schlüssel | Technisch machbar, doch die Daten werden nie integriert |
| 2. Quell-APIs mit Business-Keys | Jede Quelle soll jede Beziehung mit Business-Keys liefern | Sehr angenehm, wenn es klappt, was selten vorkommt |
| 3a. Eigene Lookups beim Staging | Technische Schlüssel beim Staging durch Business-Keys ersetzen, indem Sie die Quelle abfragen | Das funktioniert und liegt in Ihrer Hand, doch die Daten werden vor dem Schreiben verändert und sind damit nicht mehr prüfbar, und die Lookups erzeugen Last auf Produktivsystemen, wo sie nicht hingehört |
| 3b. Lookups nach dem Staging | Die technischen Schlüssel nach dem Staging per Join ersetzen, entweder gegen die Staging-Tabellen oder gegen den Vault | Ein Join gegen die Staging-Tabellen verhindert Delta-Loads, weil der Join die vollständigen Tabellen braucht. Ein Join gegen den Vault funktioniert, doch die Daten werden trotzdem vor dem Laden verändert |
| 4. PSA-Hubs | Technische Schlüssel in einen eigenen Hub laden und diesen dem Business-Key-Hub zuordnen | Ein zusätzlicher generierter Join bei der Abfrage. Diesen kann man aber mit einem Business-Vault-Ladevorgang überflüssig machen. |
Das Muster, das wir verwenden: PSA-Hubs
Ein PSA-Hub ist ein Hub für die technischen Schlüssel der Quellsysteme. PSA steht für Persistent Staging Area, allerdings nicht für die, von der man im Data-Lake-Umfeld spricht, also eine flache Kopie der Quelltabellen: Diese hier liegt bereits im Vault-Format vor, mit Hubs und Links und mit Satelliten, wo sie gebraucht werden. Im folgenden Beispiel enthält die PSA gar keine Attribute, sondern nur die technischen Beziehungen: Die beschreibenden Daten liegen am Business-Key-Hub.
Jedes Geschäftsobjekt erhält zwei Hubs, niemals einen pro Quellsystem:
- Der PSA-Hub enthält die technischen Schlüssel aller Systeme, jeden mit seinem
Business Key Prefix:
CRM|10492,ERP|80012. - Der Raw-Vault-Hub enthält die Business-Keys ohne Prefix:
CUST-9921.
Das Laden kommt dann ganz ohne Übersetzung aus:
- Transaktionen werden so geladen, wie sie geliefert werden. Der Auftrag
884102ist mit dem KundenCRM|10492über einen Link zwischen dem Auftrags-PSA-Hub und dem Kunden-PSA-Hub verbunden, mit den technischen Schlüsseln genau so, wie die Quelle sie führt. - Die Stammdatensätze übernehmen die Zuordnung. Der Kundendatensatz enthält sowohl
10492als auchCUST-9921und ordnet damit den PSA-Schlüssel dem Business-Key zu, n:1. Die technischen Schlüssel mehrerer Systeme können auf denselben Kunden verweisen. - Satelliten hängen am Business-Key-Hub. Name und Adresse des Kunden beschreiben
CUST-9921, ganz gleich, welches System sie geliefert hat.
Dasselbe Muster wiederholt sich für jedes Geschäftsobjekt: Aufträge, Produkte, Verträge.
Abfragen: ein Weg und eine Abkürzung
Um Aufträge mit ihrem integrierten Kunden auszugeben, führt die Abfrage vom Auftrag zum Auftrags-PSA-Hub, entlang der technischen Beziehung zum Kunden-PSA-Hub und von dort zum Kunden:
Order → Order PSA → Customer PSA → Customer
Das ist der rohe, vollständig nachvollziehbare Weg. Wo Abfragen schneller sein müssen, konfigurieren Sie einen Business-Vault-Ladevorgang, der einen Exploration-Link erzeugt: Er löst den Weg einmal auf und speichert die direkte Beziehung zwischen Auftrag und Kunde. Berichte nutzen den kurzen Weg; der lange bleibt als Audit-Trail erhalten.
Was Sie gewinnen
- Nichts wird vor dem Schreiben verändert. Technische Schlüssel werden so geladen, wie die Quelle sie geliefert hat, deshalb bleibt jede Zeile prüfbar.
- Keine Lookups gegen Produktivsysteme. Die Übersetzung findet im Warehouse statt.
- Schnelles Schreiben. Das Laden braucht überhaupt keine Lookups, daher lädt jede Quelle so schnell, wie sie liefert, und der Exploration-Link wird anschließend asynchron erzeugt.
- Integrierte Ausgabe. Jeder Kunde erscheint genau einmal, mit dem Business-Key als Schlüssel und mit den Transaktionen aller Systeme.
- Migrationen bleiben beherrschbar. Wird ein Quellsystem abgelöst, werden seine neuen technischen Schlüssel denselben Business-Keys zugeordnet, und die Historie passt weiterhin zusammen.
Was sich mit Datavault Builder ändert
Datavault Builder unterstützt die PSA, den Raw Vault und den Business Vault, und alle drei bilden ein integriertes Modell. Jede Schicht lässt sich agil in Schritten entwickeln, sobald sie gebraucht wird: Beginnen Sie mit den PSA-Hubs, ergänzen Sie die Zuordnung zum Business-Key, und konfigurieren Sie einen Exploration-Link dort, wo eine Abfrage ihn verlangt.
Der Business Key Prefix, der CRM|10492 und ERP|10492 auseinanderhält, ist Teil des Modells,
und die Hubs, Links und Ladevorgänge des Musters werden wie alle anderen generiert. Die
Modellierungsentscheidung bleibt bei Ihnen: welches Geschäftsobjekt, welcher Business-Key und wo
sich ein Exploration-Link lohnt.
Erleben Sie es live mit Ihren eigenen Datenquellen
Buchen Sie eine kostenlose Demo und bringen Sie den Connector mit, der Sie am meisten kostet, an Geld oder an Zeit.
Drei Schritte von technischen Schlüsseln zu Business-Keys
-
Den Raw Vault wie gewohnt laden
Business-Key-Hubs und ihre Satelliten, geladen aus den Stammdatensätzen, genau wie es die Literatur beschreibt.
-
PSA-Hubs für technische Schlüssel ergänzen
PSA-Hubs enthalten die technischen Schlüssel mit ihrem Business Key Prefix, und die Beziehungen zwischen ihnen verlaufen über diese Schlüssel.
-
Den Weg verkürzen, wo es sich lohnt
Wo eine Abfrage wirklich Geschwindigkeit braucht, speichert ein Exploration-Link die direkte Beziehung einmalig ab.
Wie Datavault Builder die Reibungsverluste in der Ingestion beseitigt
-
Ingestion ist eingebaut
Batch-, Delta- und CDC-Ladevorgänge aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka, die als Micro-Batches ankommen. Dieselbe Plattform, die das Warehouse generiert, keine zweite Rechnung.
-
Ihr Schema, nicht das des Anbieters
Quelltabellen werden auf ein Data-Vault-2.0-Modell gemappt, das Sie entworfen haben. Eine neue Spalte oder eine umbenannte Tabelle ändert ein Mapping, keine Kette von Skripten nach dem Load.
-
Nur Deltas bewegen sich
Hubs, Links und Satelliten laden, was sich geändert hat. Vollständige Ladevorgänge bleiben im Staging, statt jede Nacht weiter unten neu verarbeitet zu werden.
-
Historie wird von Haus aus behalten
Jede Änderung wird so festgehalten, wie sie eintrifft. Historien- und Stichtagsabfragen funktionieren also auch dort, wo die Quelle ihre eigenen Zeilen überschreibt.
-
Code, den Sie nie von Hand schreiben
Laden, Historisierung und Lineage werden in Echtzeit aus dem Modell generiert und laufen nativ auf Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL.
-
Eine Plattform, bis zu neun Tools weniger
Modellierung, ETL, CI/CD, Dokumentation und Lineage an einem Ort. Das ist es, was 14,7 Minuten von der Anforderung bis zur Produktion möglich macht.
Ausgezeichnet von BARC im Data Fabric Survey 26
Sprechen Sie mit unserem Experten
Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrem Stack passt.
Matt Collett
Sales Director
Perfekt, wählen Sie einen passenden Termin:
Weitere Probleme in dieser Serie
-
Was ist ein Business-Key in Data Vault?
Ein Business-Key ist die Kennung, mit der Ihre Mitarbeitenden und Kunden tatsächlich arbeiten: die Kundennummer, die Rechnungsnummer, die Vertragsnummer. Er ist stabil, wird systemübergreifend verwendet, und auf ihm baut jeder Hub in einem Data Vault auf.
-
Was ist ein Satellit in Data Vault?
Ein Satellit enthält alles, was einen Hub beschreibt: Namen, Status, Beträge und jede Änderung daran, angefügt und nie aktualisiert. Er ist eine Slowly Changing Dimension Typ 2 ohne UPDATE, und bringt von Haus aus einen vollständigen Audit-Trail mit.
-
Was ist ein Link in Data Vault?
Ein Link hält fest, dass Business-Keys zusammengehören: Dieser Auftrag gehört zu diesem Kunden. Datavault Builder deckt den klassischen Data-Vault-Link ab und ergänzt ihn um einen Transaktions-Link, der an einem Grain-Hub verankert ist. Dieser legt die Granularität einer Transaktion fest und ermöglicht Beziehungen zwischen Transaktionen.
-
Was ist ein Hub in Data Vault?
Ein Hub bildet ein zentrales Geschäftsobjekt wie Kunde, Produkt oder Konto als Liste seiner Schlüssel ab: jeden Schlüssel, den das Warehouse je gesehen hat, jeden genau einmal. Er speichert Identität, keinen Zustand, und genau diese Beschränkung macht ihn zu dem Punkt, an dem die Silos der Quellsysteme aufgelöst werden.
Fragen und Antworten
- Dan Linstedt. Er hat die Methode in den 1990er-Jahren entwickelt und sie um das Jahr 2000 veröffentlicht. Data Vault 2.0, das das Modell um Hash-Schlüssel, eine Methodik und eine Architektur ergänzt, folgte 2013.
- Das Standardwerk ist Building a Scalable Data Warehouse with Data Vault 2.0 von Dan Linstedt und Michael Olschimke (Morgan Kaufmann, 2015).
- Nein. Bill Inmon sieht Data Vault als Weiterentwicklung seiner Sicht auf das Enterprise Data Warehouse in dritter Normalform, nicht als konkurrierenden Ansatz.
- Nein. Ein dimensionaler Output ist oft Teil einer Data-Vault-Implementierung: Der Vault hält die integrierte Historie, und für das Reporting werden darauf Star-Schemas aufgebaut. Derselbe Vault kann auch flache Tabellen oder ein Unified Star Schema liefern.
- Mit Automatisierung lässt sich eine Sicht in dritter Normalform auf einem Data Vault vollständig deterministisch generieren. Der Vault hält die Daten nur einmal, und die 3NF-Schicht wird aus dem Modell abgeleitet. So funktioniert das.
- Es ohne Automatisierung zu versuchen. Data Vault beruht auf wenigen strengen, sich wiederholenden Mustern. Genau deshalb ist es mühsam und fehleranfällig, es von Hand zu schreiben, und einfach, es zu generieren. Deshalb sollten Sie Datavault Builder einsetzen.
- Ja. Wer Schlüssel, Beziehungen und Historie auf Hubs, Links und Satelliten aufteilt, erhält mehr Tabellen als in einem normalisierten oder dimensionalen Modell. Deshalb sollte die physische Schicht durch einen modellgetriebenen Ansatz wie Datavault Builder abstrahiert werden: Sie arbeiten am Geschäftsmodell, und die Tabellen werden generiert.
- Buchen Sie eine Demo und sehen Sie, wie ein Data Vault auf Ihren eigenen Quellen entsteht, oder bestellen Sie eine Trainingsumgebung und probieren Sie es selbst aus.
- Hier. Datavault Builder ist eine Lösung zur Data-Vault-Automatisierung: Sehen Sie sich die Preise an oder buchen Sie eine Demo.
- Datavault Builder wird jährlich für die Nutzung lizenziert. Kauflizenzen gibt es auf Anfrage. Die Editionen und ihren Umfang finden Sie auf der Preisseite.