Alternative zum Driving-Key
Es gibt einen Spezialfall, in dem sich ein Teil der in einem Link gespeicherten Hub-Referenzen ändern kann, ohne eine andere Beziehung zu beschreiben. Dies hat erhebliche Auswirkungen auf die Link-Satelliten. Darüber hinaus haben wir bereits im Jahr 2017 die Link-Struktur anhand eines Beispiels für ein Data-Vault-Modell in der Bankenbranche vorgestellt. Wir haben gezeigt, wie das Modell aussieht, wenn ein Link entweder eine Beziehung oder eine Transaktion zwischen zwei Business-Objekten darstellt. Ein Link kann auch mehr als zwei Hubs miteinander verbinden. Was ist die Alternative zur Driving-Key-Implementierung in Data Vault 2.0?
In this article:
Der Driving-Key
Eine Beziehung oder Transaktion wird in einem Quellsystem häufig durch eine Kombination von Business-Keys identifiziert. In Data Vault 2.0 wird dies als normaler Link modelliert, der mehrere Hubs verbindet, die jeweils einen Business-Key enthalten. Ein Link enthält auch seinen eigenen Hash-Key, der über die Kombination aller Business-Keys der Parent-Hubs berechnet wird. Wenn der Link also vier Hubs verbindet und sich ein Business-Key ändert, weist der neue Datensatz einen neuen Link-Hash-Key auf. Ein Problem entsteht, wenn zwar vier Business-Keys die Beziehung beschreiben, aber nur drei davon diese eindeutig identifizieren. Wir können das Business-Objekt nicht allein anhand des Hash-Keys des Links identifizieren. Dies ist zwar kein Modellierungsfehler, allerdings müssen wir bei der Datenabfrage den korrekten Datensatz im zugehörigen Satelliten identifizieren. In Data Vault 2.0 wird dies als Driving-Key bezeichnet. Es handelt sich dabei um einen konsistenten Schlüssel innerhalb der Beziehung, der im Quellsystem oft dem Primärschlüssel entspricht.
Die folgenden Tabellen veranschaulichen die Beziehung zwischen einem Mitarbeiter und einer Abteilung aus einem Quellsystem.
Das folgende Data-Vault-Modell lässt sich aus dieser Quellstruktur ableiten.
Die Link-Tabelle „Empl_Dep“ wird aus der Tabelle „Employee“ im Quellsystem abgeleitet. Der Driving-Key in diesem Beispiel ist die Employee_Number, da sie der Primärschlüssel in der Quelltabelle ist und ein Mitarbeiter zur gleichen Zeit nur in einer Abteilung arbeiten kann. Das bedeutet, dass der tatsächliche Driving-Key im Satelliten des Mitarbeiters „lebt“. Wechselt die Abteilung eines Mitarbeiters, entsteht kein zusätzlicher Datensatz in der Satellitentabelle des Mitarbeiters, sondern ein neuer in der Link-Tabelle, was völlig legitim ist.
Um das aktuellste Delta zu ermitteln, müssen Sie dieses aus der Link-Tabelle abfragen und nach dem Driving-Key gruppieren.
Zusammenfassend lässt sich sagen, dass Sie immer einen neuen Link-Hash-Key erhalten, wenn sich ein Business-Key in einer Beziehung ändert. Die Herausforderung besteht darin, den Driving-Key zu identifizieren. Hierbei handelt es sich um einen eindeutigen Business-Key (oder eine Kombination von Business-Keys) für die Beziehung zwischen den verbundenen Hubs. Manchmal müssen Sie ein zusätzliches Attribut hinzufügen, um einen eindeutigen Identifikator zu erhalten.
Beides stellt ein Problem für Power-User mit Zugriff auf das Data-Vault-Modell dar. Ohne klare Namenskonventionen besteht das Risiko, dass eine GROUP-BY-Anweisung auf mehr Attribute als nur den Driving-Key angewendet wird. Dies würde zu unerwarteten und fehlerhaften Aggregatwerten führen, obwohl die Daten selbst korrekt modelliert sind
Beim Umgang mit Beziehungsdaten gibt es eine bessere Lösung als den Driving-Key: Wir bevorzugen es in der Regel, solche Daten als Non-Historized-Link zu modellieren und technische Gegenbuchungen (Counter-Transactions) in die Daten einzufügen, sobald sich eine Hub-Referenz ändert.
Im Falle eines geänderten Datensatzes in der Quelle fügen wir zwei Datensätze in den Non-Historized-Link ein: einen für die neue Version des geänderten Quell-Datensatzes und einen für die alte Version, die noch im Target existiert, aber nun ausgeglichen werden muss – den technischen Counter-Datensatz. Um die Datensätze aus der Quelle von den Counter-Transactions zu unterscheiden, wird eine neue Spalte eingeführt, die oft als „Counter“ bezeichnet wird.
Der Standardwert für dieses Counter-Attribut ist 1 für Datensätze aus der Quelle und -1 für die technischen Counter-Transactions. Wichtig: Wir führen keine UPDATE-Anweisungen aus, sondern fügen stattdessen nur neue Datensätze hinzu. Wenn Sie die Measures aus dem Link abfragen, multiplizieren Sie diese einfach mit dem Counter-Wert.
Tabelle 3 zeigt einen Link mit einem Counter-Attribut. Wenn sich ein Datensatz im Quellsystem ändert, wird er mit dem ursprünglichen Wert und einem Counter-Wert von -1 in die Link-Tabelle des Data-Warehouses eingefügt. Für den geänderten Wert gibt es einen neuen Link-Hash-Key, der ebenfalls über das beschreibende Attribut „Salary“ berechnet wird. Der Counter-Wert des neuen Datensatzes ist 1.
Fazit
Da die Identifizierung des Driving-Keys einer Beziehung in manchen Situationen ein Problem darstellen kann, können Sie eine alternative Lösung nutzen, um den Driving-Key zu vermeiden. Alle Änderungen und Löschungen werden mithilfe eines Counter-Attributs in der Non-Historized-Link-Tabelle nachverfolgt. Diese speichert auch die beschreibenden Attribute, und der Link-Hash-Key wird über alle Attribute berechnet.
