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.
Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen
Kommt Ihnen das bekannt vor?
- Das Modell wurde aus dem Datenbankschema abgeleitet, und die Fachabteilung erkennt darin keinen einzigen Schlüssel wieder.
- Nach der ERP-Migration hat jeder Kunde eine neue ID, und die Historie lässt sich nicht mehr verknüpfen.
- Zwei Systeme führen dieselben Kunden, und das Warehouse kann nicht erkennen, welche Datensätze zusammengehören.
Ein Hub ist nur so gut wie der Schlüssel, auf dem er aufbaut. Bei Data Vault ist der Schlüssel zum Erfolg der Business-Key.
Was ein Business-Key ist
Ein Business-Key ist die Kennung, die das Unternehmen selbst verwendet: die Kundennummer auf einem Brief, die Rechnungsnummer, die ein Kunde am Telefon nennt, die Vertragsnummer in einer E-Mail. Mitarbeitende und Kunden kennen diese Schlüssel, und genau deshalb sind sie stabil. Ein System kann seine internen Datensätze neu nummerieren. Eine Nummer, die auf zehntausend Rechnungen gedruckt ist, lässt sich dagegen nicht so einfach ändern.
In der Sprache der klassischen Datenmodellierung ist der Business-Key der natürliche Schlüssel, einer der Schlüsselkandidaten der Entität, im Gegensatz zum Surrogatschlüssel, den eine Datenbank für ihre eigenen Zwecke erzeugt. Wer schon einmal einen Primärschlüssel für ein konzeptionelles Modell gewählt hat, hat diese Arbeit bereits gemacht.
Wie Sie sie finden: der Trick mit der Papierrechnung
Viele Data Engineers und Datenmodellierer zögern, die Fachanwender nach Schlüsseln zu fragen. Die Frage klingt technisch, und die Antworten verlieren sich in Tabellennamen. Eine einfache Übung vermeidet das:
- Bitten Sie die Fachanwender, einige echte Belege auszudrucken: einen Auftrag, eine Rechnung, einen Lieferschein.
- Fragen Sie sie: “Wenn ein Kunde Sie wegen dieses Belegs anruft, was nennt er Ihnen, damit Sie den Beleg finden?”
- Markieren Sie, worauf sie zeigen.
Die markierten Kennungen sind Ihre Business-Keys. Auf demselben Blatt Papier sehen Sie auch die Geschäftsobjekte rund um diese Kennungen (Kunde, Auftrag und Produkt) und wie sie miteinander in Beziehung stehen. Damit beginnt das Modell.
Warum Data Vault auf Business-Keys aufbaut
- Passive Integration. Business-Keys werden von mehreren Quellsystemen gemeinsam verwendet.
Wenn CRM und ERP beide den Kunden
C-10442in denselben Hub laden, sind ihre Daten verbunden, ohne dass eine manuelle Integrationslogik nötig ist: Das erledigen der gemeinsame Schlüssel und unsere Automatisierung. - Migrationen von Quellsystemen. Wird ein Quellsystem abgelöst, ändern sich seine technischen Schlüssel. Seine Business-Keys ändern sich nicht, deshalb passt die Historie vor und nach der Migration weiterhin zusammen.
- Data-Warehouse-Generationen. Dasselbe gilt für das Warehouse selbst. Wenn eine neue Datenintegrations- oder DWH-Lösung Daten aus der alten übernehmen muss, verbinden die Business-Keys beide, weil sie auch zwischen DWH-Versionen stabil bleiben.
Wo derselbe Schlüssel in verschiedenen Systemen Unterschiedliches bedeutet, etwa der Auftrag 1018
im Schweizer und im deutschen ERP-System, hält der Business Key Prefix die
beiden auseinander. Wo ein Schlüssel aus mehreren Teilen besteht, etwa Buchungskreis plus
Kundennummer, ist der Business-Key einfach zusammengesetzt.
Der Haken
Die meisten Quellsysteme speichern den Business-Key in der Entität, die er identifiziert: Die Kundennummer steht in der Kundentabelle. Die Beziehungen dagegen verwenden technische Schlüssel. Ein Auftragsdatensatz enthält die system-interne ID des Kunden, nicht die Kundennummer. Wie Sie von dort zu einem Modell gelangen, das auf Business-Keys aufbaut, behandelt der nächste Artikel dieser Reihe: technische versus fachliche Schlüssel.
Was sich mit Datavault Builder ändert
In Datavault Builder definieren Sie das Geschäftsobjekt einmal. Dann ordnen Sie ihm jede Quelle zu, indem Sie festlegen, welche ihrer Spalten den Business-Key bilden, und Datavault Builder erledigt alles, was für die Integration nötig ist: Der Hub, die Schlüsselbehandlung und der Ladecode werden generiert. Der Aufwand fließt in das Gespräch mit der Fachabteilung, nicht in das Schreiben von Ladelogik.
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 zu Ihren Business-Keys
-
Die Belege ausdrucken
Bitten Sie die Fachanwender, echte Aufträge, Rechnungen und Lieferscheine zum ersten Termin mitzubringen.
-
Eine einzige Frage stellen
Wenn ein Kunde wegen dieses Belegs anruft, was nennt er Ihnen, damit Sie den Beleg identifizieren können?
-
Die Antwort markieren
Jede Kennung, auf die sie zeigen, ist ein Business-Key. Die Belege zeigen außerdem die Geschäftsobjekte und ihre Beziehungen zueinander.
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
-
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.
-
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.