Im Jahr 2017 haben wir die Linkstruktur mit einem Beispiel für ein Data Vault-Modell im Bankensektor. Wir haben gezeigt, wie das Modell aussieht, wenn eine Verbindung entweder eine Beziehung oder eine Transaktion zwischen zwei Geschäftsobjekten darstellt. Ein Link kann auch mehr als zwei Hubs miteinander verbinden. Darüber hinaus gibt es einen Sonderfall, bei dem sich ein Teil der in einem Link gespeicherten Hub-Referenzen ändern kann, ohne eine andere Beziehung zu beschreiben. Dies hat einen großen Einfluss auf die Link-Satelliten. Was ist die Alternative zur Implementierung des Driving Key in Data Vault 2.0?
Der Fahrschlüssel
Eine Beziehung oder Transaktion wird oft durch eine Kombination von Geschäftsschlüsseln in einem Quellsystem identifiziert. In Data Vault 2.0 wird dies als normaler Link modelliert, der mehrere Hubs verbindet, die jeweils einen Geschäftsschlüssel enthalten. Ein Link enthält auch seine eigene Hash-Schlüsselder über die Kombination aller geschäftlichen Schlüssel der Eltern berechnet wird. Wenn also die Verknüpfung vier Hubs verbindet und sich ein Geschäftsschlüssel ändert, weist der neue Datensatz einen neuen Verknüpfungs-Hash-Schlüssel auf. Es gibt ein Problem, wenn vier Geschäftsschlüssel die Beziehung beschreiben, aber nur drei von ihnen sie eindeutig identifizieren. Wir können das Geschäftsobjekt nicht identifizieren, indem wir nur den Hash-Schlüssel der Verknüpfung verwenden. Das Problem ist kein Modellierungsfehler, sondern wir müssen bei der Abfrage der Daten den richtigen Datensatz im zugehörigen Satelliten identifizieren. In Data Vault 2.0 wird dies als Antriebsschlüssel bezeichnet. Es handelt sich um einen konsistenten Schlüssel in der Beziehung und oft um den Primärschlüssel im Quellsystem.
Die folgenden Tabellen zeigen die Beziehung zwischen einem Mitarbeiter und einer Abteilung aus einem Quellsystem.
Aus dieser Ausgangsstruktur lässt sich das folgende Data Vault-Modell ableiten.
Die Verknüpfungstabelle "Empl_Dep" wird von der Tabelle "Employee" im Quellsystem abgeleitet. Der treibende Schlüssel in diesem Beispiel ist die Mitarbeiternummer, da sie der Primärschlüssel in der Quelltabelle ist und ein Mitarbeiter nur in einer Abteilung zur gleichen Zeit arbeiten kann. Das bedeutet, dass der wahre treibende Schlüssel im Satelliten des Mitarbeiters "lebt". Wenn die Abteilung eines Mitarbeiters wechselt, gibt es keinen zusätzlichen Datensatz in der Satellitentabelle des Mitarbeiters, sondern einen neuen in der Verknüpfungstabelle, was legitim ist.
Um das jüngste Delta abzufragen, müssen Sie es in der Verknüpfungstabelle abfragen, gruppiert nach dem Fahrschlüssel.
Zusammenfassend lässt sich sagen, dass Sie immer einen neuen Link-Hash-Schlüssel haben werden, wenn sich ein Geschäftsschlüssel in einer Beziehung ändert. Die Herausforderung besteht darin, den treibenden Schlüssel zu identifizieren, der ein eindeutiger Geschäftsschlüssel (oder eine Kombination von Geschäftsschlüsseln) für die Beziehung zwischen den verbundenen Knotenpunkten ist. Manchmal muss man ein zusätzliches Attribut hinzufügen, um einen eindeutigen Bezeichner zu erhalten.
Beides stellt ein Problem für Power-User dar, die Zugriff auf das Modell Data Vault haben. Ohne Benennungskonventionen besteht die Gefahr, dass eine Gruppierung nach mehr Attributen als nur dem treibenden Schlüssel durchgeführt wird, was zu unerwarteten und falschen Gesamtwerten führen würde - auch wenn die Daten selbst korrekt modelliert sind.
Beim Umgang mit Beziehungsdaten gibt es eine bessere Lösung als den Antriebsschlüssel: Wir bevorzugen in der Regel die Modellierung solcher Daten als nicht-historisierte Verbindung und fügen Sie technische Gegentransaktionen zu den Daten ein, wenn sich eine Hub-Referenz ändert.
Im Falle eines geänderten Datensatzes in der Quelle fügen wir zwei Datensätze in die nicht-historisierten Verknüpfungen ein: einen für die neue Version des geänderten Datensatzes in der Quelle und einen für die alte Version, die noch im Ziel existiert (nicht-historisierte Verknüpfung), aber jetzt gekontert werden muss - den technischen Gegensatzsatz. Zur Unterscheidung der Datensätze aus der Quelle und den Gegengeschäften wird eine neue Spalte eingefügt, die oft "Zähler" genannt wird.
Der Standardwert für dieses Zählerattribut ist 1 für Datensätze aus der Quelle und -1 für die technischen Gegengeschäfte. Wichtig: Wir führen keine Aktualisierungsanweisungen durch, sondern fügen nur die neuen Zählersätze ein. Wenn Sie die Kennzahlen aus der Verknüpfung abfragen, multiplizieren Sie die Kennzahlen einfach mit dem Zählerwert.
Die Tabelle 3 zeigt eine Verknüpfung mit einem Zählerattribut. Wenn sich ein Datensatz im Quellsystem ändert, wird er mit dem ursprünglichen Wert und einem Zählerwert von -1 in die Link-Tabelle des data warehouse eingefügt. Für den geänderten Wert gibt es einen neuen Link-Hash-Schlüssel, der ebenfalls über das beschreibende Attribut "Salary" berechnet wird. Der Zählerwert des neuen Satzes ist 1.
Schlussfolgerung
Da die Identifizierung des treibenden Schlüssels einer Beziehung in manchen Situationen ein Problem darstellen kann, können Sie eine alternative Lösung verwenden, um den treibenden Schlüssel zu vermeiden. Alle Änderungen und Löschungen werden mit Hilfe eines Zählerattributs in der nicht-historisierten Verknüpfungstabelle nachverfolgt. Sie speichert auch die beschreibenden Attribute, und der Link-Hash-Schlüssel wird über alle Attribute berechnet.
Updates und Support erhalten
Bitte senden Sie Anfragen und Funktionswünsche an [email protected].
Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.
Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.
Hallo zusammen, wenn ich das Konzept der Datenaktualisierung in der Verknüpfung richtig verstehe, sollten im zweiten und dritten Datensatz dieses Beispiels in Tabelle 3 genau die Ladedaten stehen. Denn wenn sich ein Datensatz im Quellsystem ändert, wird diese neue Information geladen und die vorherige gleichzeitig "ungültig" gemacht. Liege ich da richtig?
Hallo Tomas,
Zunächst führen wir keine "physischen" Aktualisierungen in der Verbindung durch, sondern erstellen neue Datensätze, die "Zählersätze" sind. Die Genauigkeit des Ladedatums hängt von der Häufigkeit der Datenladungen ab. Bei täglichen Batch-Ladungen könnte der Tag als detailliertester Wert ausreichen. Bei Mini-Batches sollten Sie mindestens die Sekunden angeben. Und ja, das Einfügen neuer Datensätze und das Einfügen der Zähler können parallel laufen.
Mit freundlichen Grüßen,
Scalefree Mannschaft
Hallo scalefree Team,
Könnten Sie bitte ein Beispiel aus dem wirklichen Leben nennen, bei dem der erläuterte Ansatz von Vorteil war?
Mit freundlichen Grüßen,
Mike
Hallo Mike,
Wir verwenden diesen Ansatz in Situationen, in denen wir volle Prüfbarkeit bei gleichzeitiger Einfachheit benötigen. Wir haben diesen Ansatz bei Berenberg erfolgreich bei den Buchungsvorgängen der Bank eingesetzt. In diesem Fall war die Bank in der Lage, in der Historie aller Transaktionen vor und zurück zu blättern, um jederzeit den aktuellen Stand aller Bankkonten abzurufen. Mehr Details: Erfolgsgeschichte Berenberg & Scalefree
Mit freundlichen Grüßen,
Ihr Scalefree-Team
Hinweis: Der Artikel wurde am 14. Januar 2019 zur Verbesserung der Qualität überarbeitet.
Es gibt immer noch einen Fehler in der Tabelle 3. Der zweite (Korrektur-)Datensatz sollte den Wert 2013-07-14 2:11:10 Load_Date haben.
Außerdem muss ich empfehlen, den Gehaltswert direkt mit -1 zu multiplizieren, um die Summe zu vereinfachen.
Hallo Richard,
wir wollen den ursprünglichen Datensatz rückgängig machen, deshalb verwenden wir genau die gleichen Werte wie beim ersten Datensatz (der Zählerwert ist Teil des LinkHashKey). In Abfragen müssen Sie mit dem Zählerattribut multiplizieren, ja.
Mit freundlichen Grüßen,
Ihr Scalefree-Team
Hallo,
Ich habe das Gefühl, dass die einzige Stelle, von der man das erfahren kann, eine CDC ist... Ich verstehe nicht, wie man die -1 erstellen kann, ohne zu wissen, dass sich die Beziehung von Abteilung A zu Abteilung B geändert hat....
Wenn ja, was passiert bei einem Wechsel in die Abteilung C...
Ich kann mir vorstellen, dies von einem Änderungsauslöser aus zu tun, wo ich jetzt zwei Insert Statements in den Link erstellen kann... aber nicht in einem Batch Load oder von einer CDC-Änderung aus, da ich nicht wüsste, wo ich in der CDC aufgehört habe...
Danke,
Hallo John,
Ja, wenn möglich, sind CDC-Audit-Trails definitiv der richtige Weg. Wenn CDC/Audit Trails in der Quelle implementiert sind, sollten Sie sich für Standard Link und seine Satelliten entscheiden. Unsere Lösung hängt von der vollständigen Datenübermittlung ab. Ziel ist es, für jede Änderung einen vollständigen Zählersatz des ursprünglichen Datensatzes zu erstellen.
Wir verwenden zwei verschiedene Muster für den gesamten Prozess. Das erste ist eine Einfügeanweisung, die neue oder geänderte Datensätze einfügt (gekennzeichnet durch den Link_Unique_HK).
Das zweite Muster fügt die Zählerbuchung ein, wenn Datensätze in der Verknüpfung nicht im transienten Staging-Bereich (oder beim letzten Batch-Load in einem persistenten Staging-Bereich) vorhanden sind. Beide Prozesse können parallel ablaufen.
Mit freundlichen Grüßen,
Ihr Scalefree-Team
Hallo,
Wie würde man anhand von Tabelle 3 den Stand vom 2013-07-04 02:00:00 abfragen?
Benötigen Sie dazu nicht auch das Load_Date der Änderung?
Herzliche Grüße,
Tjomme
Hallo Tjomme,
das Load_Date und die Record Source sind nicht Teil des eindeutigen Hash-Schlüssels. Die Erkennung erfolgt über einen vollständigen Tabellenscan im Staging-Bereich (in dem Sie die vollständige Datenladung aus dem Quellsystem haben), indem der eindeutige Hash-Schlüssel verglichen wird. Das Load_Date ist in diesem Fall nicht das Ladedatum für den Zählerdatensatz, da es nie wirklich existiert. Der Zählerdatensatz ist der ursprüngliche erste Datensatz und wird zur gleichen Zeit/im gleichen Stapel wieder eingefügt, wenn die neuen Datensätze geladen werden, nur mit dem Zähler -1. Am 2013-07-04 02:00:00 existiert der Zählerdatensatz noch nicht. Er wird eingefügt, wenn der dritte Datensatz eingefügt wird.
Denken Sie daran, dass diese Methode verwendet werden sollte, wenn Sie keine CDC-Daten, sondern nur vollständige Datenlieferungen erhalten.
Mit freundlichen Grüßen,
Ihr Scalefree-Team
Hallo Karina,
Ein Zweck des Data Vault ist die Auditierbarkeit. Das bedeutet, dass wir heute in der Lage sein sollten, den Status des Quellsystems zu reproduzieren, wie er am 2013-07-14 02:00:00 war.
Wenn ich nur mit der obigen Tabelle 3 arbeite, wird dies eine Herausforderung sein. Oder übersehe ich etwas?
Dies wird sehr viel einfacher, wenn das Load_Date des Datensatzes, der die Erstellung des Zählerdatensatzes veranlasst hat, auch im Zählerdatensatz erfasst wird. In diesem Fall wäre das 2013-07-14 02:11:10. Durch Filtern nach diesem Feld könnten wir die Tabelle problemlos auf einen beliebigen Zeitpunkt setzen.
Oder wird diese Information in einem (nicht erwähnten) Statussatelliten verwaltet?
Die gleiche Technik könnte auch bei der Verarbeitung von CDC-Protokollen verwendet werden.
Herzliche Grüße,
Tjomme
Hallo Tjomme,
Ja, Sie haben Recht.
Sie können die ursprüngliche Datenlieferung nur reproduzieren, wenn Sie das Ladedatum für den Zählersatz auf das Datum der aktuellen Datenladung setzen, an dem Sie das Fehlen tatsächlich erkennen. Das haben wir entsprechend geändert.
Vielen Dank für Ihr wachsames Auge und herzliche Grüße,
Ihr Scalefree-Team
Ich habe 2 Fragen:
1) Ich gehe davon aus, dass Link_Unique_HK im angegebenen Beispiel auf der Grundlage von Employee BK, Department BK, Counter und Load_date berechnet werden muss. Sie muss eindeutig sein, und der Mitarbeiter kann dieselbe Abteilung mehrmals eingeben, richtig?
2) Wenn wir Beziehungs- und Kontextdaten in der transaktionalen Verknüpfung mischen können, könnten wir dann auch Beziehungs- und Kontextdaten in der Sattelite mischen? Für das gegebene Beispiel wäre die Tabellenstruktur die gleiche, nur würde die Tabelle die Sattelite der Mitarbeiter-Drehscheibe darstellen. Der Primärschlüssel wäre also employee_hk und load_date. Wir könnten auch Link_unique_hk nur auf Basis von Employee_hk und department_hk berechnen, wie im Standard empl_dep link. Ich glaube, wir könnten sogar eine Ansicht für die Virtualisierung dieses Links auf einem solchen Satelliten erstellen, so dass es eine physische Darstellung des empl_dep-Links in der Datenbank gibt. Wir würden nur eine neue Zeile pro Änderung benötigen. Hinsichtlich des Ladens können sowohl vollständige Dumps als auch CDC genutzt werden. Power-User und ETL für Datamarts würden die aktuellen Datensätze wie bei einem Standard-Satelliten abrufen, und es könnten nur wenige Joins übrig bleiben. Können Sie uns auf irgendwelche Fallstricke hinweisen, die Sie bei diesem Ansatz sehen?
Hallo Karel,
1) Richtig.
2) Ihr Ansatz ist ähnlich wie der, der Driving Keys beinhaltet. In diesem Fall benötigen Sie jedoch einen Link, um Business Keys in Beziehung zu setzen, was aus verschiedenen Gründen auch Teil der Standards von Data Vault 2.0 ist - aber das ist ein anderes Thema. Bedenken Sie, dass der von Ihnen vorgeschlagene Ansatz für eine One-to-many-Beziehung funktionieren würde, nicht aber für eine Many-to-many-Beziehung, da Sie dann mehrere LDTS pro Hash Key aktivieren müssten.
Das Problem besteht darin, dass sich der Geschäftsschlüssel in einer Beziehung geändert hat und Sie nicht über einen Audit Trail verfügen, der Sie darüber informiert. Das Ergebnis wäre ein neuer Verknüpfungseintrag mit einer neuen Verknüpfung Hash Key (was in Ordnung ist) und ein weiterer Satelliteneintrag (was ebenfalls in Ordnung ist), allerdings müssen Sie die "alten" Einträge sanft löschen (oder wie auch immer Sie verschwindende Daten in Ihrem Data Warehouse kennzeichnen).
Dies zwingt Sie dazu, eine vollständige Durchsuchung der Stufentabelle durchzuführen, um herauszufinden, welche Geschäftsschlüsselbeziehungen verschwunden sind. Dies kann auf verschiedene Weise gehandhabt werden: Erstellen Sie einen Record Tracking- oder Effectivity-Satelliten, der an der Verknüpfung hängt; verwenden Sie den Driving Key-Ansatz; oder - der "einfachere" Weg - behalten Sie nur eine nicht historisierte Verknüpfungstabelle und zählen Sie einfach den gesamten Datensatz, sobald er aus der Quelle verschwunden ist.
Mit freundlichen Grüßen,
Ihr Scalefree-Team
Bei diesem Ansatz gibt es einige Probleme
1) Die Modellierung von Attributen in einem Link ist unflexibel gegenüber der Schemaentwicklung - wenn ein weiteres Attribut hinzugefügt werden soll, muss die gesamte Geschichte des Links berücksichtigt werden.
2) Wenn sich der treibende Schlüssel für die Beziehung ändert, müssen Sie eine neue Verbindung modellieren.
3) Nicht-historisierte Links sind Ausnahmelademuster, die für unveränderliche Daten reserviert sind, die sich voraussichtlich nicht ändern werden - wie Transaktionen, die in Echtzeit eingehen. Nicht-historisierte Links sind für die Geschwindigkeitsschicht (Lambda) gedacht, wo die Daten nicht gestaffelt sind.
4) Die Modellierung der Details als Link ist weitaus effektiver, aber das Hinzufügen eines Zählers würde bedeuten, dass Sie abgeleitete Daten haben - d. h. es handelt sich um eine Geschäftsregel und somit um etwas, das Sie zu business vault hinzufügen. Nicht historisierte Links sind keine business vault-Artefakte.
5) Wie gehen Sie mit einer Beziehung um, die zurückgekehrt ist, d.h. der Mitarbeiter ist in seine ursprüngliche Abteilung zurückgekehrt.
Diese Flexibilität wird effektiv (Wortspiel beabsichtigt) bei der Erstellung von Wirksamkeitssatelliten auf der Grundlage der Antriebsschlüssel einer Verbindung genutzt. Ändert sich der treibende Schlüssel, bleibt die Verbindung bestehen, aber es wird ein neuer Gültigkeits-Satellit erstellt. Gültigkeits-Satelliten werden abgeleitet; jede neue Beziehung pro treibendem Schlüssel erhält ein hohes Datum als Enddatum. Jede Änderung dieser Beziehung in Bezug auf die nicht treibenden Schlüssel dieser Beziehung erzeugt einen Abschlussdatensatz und einen neuen aktiven Datensatz (hohes Datum). Das Ganze ist nur einfügbar. Die Abfrage der Daten ist ebenfalls flexibel: Wählen Sie Ihre(n) treibenden Schlüssel (es kann mehr als einen geben) und wählen Sie die Daten aus dem Gültigkeits-Satelliten auf der Grundlage des gewünschten Datums aus, und Sie können verfolgen, wie oft die Beziehung geändert wurde.
Sie können sogar nachverfolgen, wann die Beziehung verloren gegangen ist, d. h. für den nicht treibenden Geschäftsschlüssel wurde von der Quelle eine Null eingegeben, wodurch er zu einem Nullschlüssel wurde. Gültigkeits-Satelliten benötigen einen treibenden Schlüssel und beziehen sich auf die Beziehung und nicht auf die Kontextinformationen für diese Beziehung. Wenn Anfangs- und Enddatum vom Quellsystem bereitgestellt werden, handelt es sich um einen regulären Satelliten und nicht um einen Gültigkeitssatelliten.
Hallo Patrick,
vielen Dank für Ihr Feedback. Hier sind meine 2 Cents auf Ihre Herausforderungen:
1) Sie könnten einfach einen nicht-historisierten Satelliten zu der bestehenden Verbindung hinzufügen, um zusätzliche Einheiten zu erfassen, ohne die Verbindungsdaten neu zu laden und zu aktualisieren.
2) Nicht-historisierte Verknüpfungen sollten nicht zur Erfassung von Beziehungen (z. B. Mitarbeiter zu Manager) verwendet werden, sondern sich auf Transaktionen und Ereignisse konzentrieren. Ich muss zugeben, dass ich kein großer Fan des Konzepts des treibenden Schlüssels bin und es - um ehrlich zu sein - meide wie die Pest. Das bedeutet, dass ich versuche, eine bessere Lösung für einen treibenden Schlüssel zu finden (in einer nicht-historisierten Verknüpfung, d.h. einer Gegen-Transaktion).
3) nicht unbedingt. Wir haben es z. B. bei Banken eingesetzt, um Buchungsvorgänge zu erfassen, die in Stapeln über die Bühne gingen. Mit anderen Worten: Jede Einheit (Hubs, Standardverbindungen, nicht-historisierte Verbindungen und jeder Satellit) kann in Batch, Fast-Echtzeit oder "echter" Echtzeit geladen werden.
4) Jede Entitätsart kann Teil des Business Vault sein. Der Unterschied zwischen Raw Data Vault und Business Vault besteht darin, dass Raw Data Vault rohe, unveränderte Daten enthält, während Business Vault berechnete, vorverarbeitete Daten enthält. Bei Raw Data Vault lautet die Frage: Können Sie die Lieferung so rekonstruieren, wie sie von der Quelle geliefert wurde? Das können wir, sogar mit den technischen Gegengeschäften. Daher erfüllt sie die Definition von Raw Data Vault (aber ich muss zugeben, dass dies ein Grenzfall ist).
5) Auch hier würde ich keine nicht-historisierten Verknüpfungen zur Erfassung von Beziehungen verwenden. Verwenden Sie eine Standardverknüpfung in Kombination mit einem Gültigkeits-Satelliten, um das geschäftsbedingte "Anfangs- und Enddatum der Beschäftigung" zu erfassen.
Ich hoffe, das klärt die Sache ein wenig.
Mike
Sehr interessanter Ansatz, der mir gefällt. Eine Sache, die ich noch nicht ganz verstanden habe, ist: Woher bekommen wir die BK für die wechselnden HK(s) (nicht Teil des Fahrschlüssels, in diesem Artikel die Abteilungs-BK), um den Unique Hash-Schlüssel für die Gegentransaktion zu berechnen? Von dem/den Hub(s)?
Hallo Johan,
herzlichen Dank!
In diesem Fall brauchen Sie den Business Key nicht. Denken Sie daran, dass dies ein möglicher Ansatz ist, wenn das Quellsystem keinen Prüfpfad zur Verfügung stellt, was bedeutet, dass Sie einen vollständigen Lookup zurück in das Staging durchführen müssen, um herauszufinden, ob ein Link Hash Key (der jüngste Datensatz) noch existiert oder nicht. Wenn nicht, erstellen Sie die "Zählerbuchung" auf der Grundlage des Links selbst mit dem Zählerwert -1.
Ich hoffe, das hilft.
Mit freundlichen Grüßen,
Ihr Scalefree-Team