Validation of Relationships in Data Vault 2.0
There are different ways of handling validation of relationships from source systems depending on how the data is delivered, (full-extract or CDC), and the way a delete is delivered by the source system, such as a soft delete or hard delete. In Data Vault 2.0, we differentiate data by keys, relationships and description.
That said, an often underestimated point is the handling and the validation of relationships in Data Vault 2.0.
In the following blog we explain what to consider and how to deal with it.
Deletes in Data Vault 2.0
Lassen Sie uns zunächst die verschiedenen Arten von Löschungen in Quellsystemen erklären:
- Hartes Löschen - Ein Datensatz wird im Quellsystem hart gelöscht und erscheint nicht mehr im System.
- Weiches Löschen - Der gelöschte Datensatz existiert noch in der Datenbank des Quellsystems und wird als gelöscht gekennzeichnet.
Zweitens wollen wir uns ansehen, wie wir die Daten im Staging-Bereich finden:
- Vollextrakt - Dies kann der aktuelle Stand des Quellsystems oder ein Delta-/Inkrementalextrakt sein.
- CDC (Datenerfassung ändern) - Nur neue, aktualisierte oder gelöschte Datensätze, um Daten inkrementell/deltamäßig zu laden.
Um die folgende Erklärung so einfach wie möglich zu halten, gehen wir davon aus, dass wir Beziehungen als gelöscht markieren wollen, sobald wir die Löschinformationen erhalten, auch wenn es keinen Prüfpfad vom Quellsystem gibt (Datenalterung ist ein anderes Thema).
Delete Detection and Validation of Relationships in Data Vault 2.0
Delete detection for business keys, or Hubs, is straight-forward. Soft deletes are handled as descriptive attributes in the Satellite directly and do not take into account as to whether the data arrives from a full extract or CDC. For hard deletes in the source system, we have to distinguish between full-extract and CDC.
Here we introduce the Wirkungsgrad Satellit. In case of:
- Vollextrakt - Führen Sie einen Lookup zurück in den Staging-Bereich durch, um zu prüfen, ob der Business Key noch existiert. Falls nicht, fügen Sie einen Datensatz mit den Löschinformationen (d.h. ein Kennzeichen und ein Datum) in den Gültigkeits-Satelliten ein.
- CDC - Wir erhalten eine "Lösch"-Information, die einen neuen Eintrag im Gültigkeits-Satelliten darstellt.
Die Erkennung des Löschens von Beziehungen erfordert etwas mehr Aufmerksamkeit und wird oft vergessen. Bei einem Vollextrakt können wir den gleichen Ansatz wie bei den Geschäftsschlüsseln verfolgen: Prüfen Sie einfach, ob der Link Hash Key in der aktuellen Staging-Last vorhanden ist, und fügen Sie einen entsprechenden neuen Eintrag in den Gültigkeits-Satelliten ein.
Heutzutage wird CDC jedoch immer häufiger eingesetzt. Da CDC jedoch nur Deltas liefert, besteht die Herausforderung nun darin, Beziehungen zu identifizieren, die nicht mehr existieren. Das folgende Beispiel zeigt eine Beziehung zwischen den Geschäftsobjekten Kunde und Unternehmen. Dies ist eine 1:n-Beziehung:
Bild 1: Tabellen Kunde und Unternehmen
Die Link-Tabelle in Data Vault sieht folgendermaßen aus:
Tabelle 1: Kundenverbindung
Zur besseren Lesbarkeit und Vereinfachung stellen wir die Geschäftsschlüssel anstelle von Hash-Schlüsseln dar und zeigen keine Systemfelder wie den Zeitstempel des Ladedatums und die Datensatzquelle an.
So weit so gut, aber was passiert, wenn der Kunde für ein anderes Unternehmen zu arbeiten beginnt? Dies führt zu einem neuen Datensatz in der Verknüpfung. Der CDC-Mechanismus wird uns die Daten als Aktualisierung der Kundentabelle zur Verfügung stellen.
Abbildung 2: Quelltabellen und Link nach Firmenwechsel
Woher bekommen wir die Information, dass der Kunde 4711 nicht mehr für die Firma 1234 arbeitet und wo ist diese Information gespeichert? Wir müssen den alten Link-Eintrag in der data warehouse löschen, um die Daten wieder konsistent zu machen. Im Moment sieht es so aus, als ob der Kunde für beide Unternehmen arbeitet, da beide Verknüpfungen derzeit aktiv sind.
Es gibt zwei mögliche Wege:
- Sie erhalten das "von" und das "bis" in Ihrem Prüfpfad und stellen einen Unterschied bei der company_id fest.
If that is the case, create 2 new entries in the Wirkungsgrad Satellit, one marks the old one (from) as deleted and the other one marks the new one (to) as not deleted. It is necessary to insert new relationships as “not deleted” that you can activate and deactivate Hash Keys forth and back.
Überlegen Sie, was passiert, wenn der Kunde 4711 wieder für das Unternehmen 1234 arbeitet. - In case you don’t have the “from” and “to”, you either have to load the CDC data into a persistent staging area, where you keep the full history of data delivered by CDC, or a source replica, where you create a mirror of the of the source system by feeding it with the CDC data whereby you perform hard updates when an “Updated” comes from the CDC and hard deletes when a “Delete” comes from the CDC.
Wenn Sie die Quellreplik verwenden, können Sie den gleichen Ansatz wie zuvor beschrieben verfolgen, um Volllast zu erhalten: Verbinden Sie sich mit der Replik und finden Sie heraus, ob die Hash Key noch existiert oder nicht.
Der größte Nachteil dabei ist, dass Sie mehr Daten scannen müssen, was mehr IO bedeutet. Bei Verwendung eines persistenten Staging-Bereichs können Sie eine Änderung in einer Beziehung mit Hilfe der Fensterfunktion lead() herausfinden, wobei Sie nach der technischen ID, in diesem Fall Customer_ID, partitionieren und nach dem Zeitstempel des Ladedatums ordnen.
Sobald der Link Hash Key anders ist, wird die Beziehung geändert und die alte besteht nicht mehr.
Das Ergebnis ist der folgende Effektivitätssatellit (logisch):
Tabelle 2: Wirksamkeits-Satelliten auf dem Link
Schlussfolgerung
We covered two major points in this article. The first one is that in Data Vault 2.0, we extract relationship information from the source tables and thus we have to pay more attention to the validation of those.
Der zweite Punkt ist, dass die Art und Weise, wie Sie die Daten erhalten (Delta durch CDC oder vollständiger Extrakt), Ihnen unterschiedliche Möglichkeiten hinsichtlich der Art und Weise bietet, die Daten zu laden. Wenn Sie mit großen Datenmengen arbeiten, ist CDC definitiv der richtige Weg. Darüber hinaus erhalten Sie mit dem CDC-Mechanismus alle Aktualisierungen aus der Quelle und können Daten leichter in (fast) Echtzeit laden.
- von Marc Finger (Scalefree)
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.
Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.
Newsletter
Jeden Monat neue Erkenntnisse über Data Vault
Die Struktur der Effektivitätssatellitentabelle lässt mich an einen Statusverfolgungssatelliten denken, und beide tun das Gleiche: gelöschte Links identifizieren. Warum nicht die gleichen Konzepte von STS für Links zusammenführen, anstatt Effektivitätssatelliten zu haben.
Der Zweck des Statusverfolgungssatelliten ist etwas anders. Die Tabelle ist vollständig rohdatengesteuert und sollte verwendet werden, wenn kein Prüfpfad verfügbar ist. Der Gültigkeits-Satellit kann stattdessen Teil des Business Vault sein, z. B. wenn Sie die Daten altern lassen oder Daten aus mehreren Quellsystemen stammen. Dann wollen Sie den Business Key (oder die Kombination in der Verknüpfung) als gelöscht markieren, gesteuert durch Geschäftsregeln.
Lassen Sie es uns wissen, wenn Sie hier weitere Unterstützung benötigen. Dies wird auch in den Data Vault 2.0 Boot Camps erklärt: https://www.scalefree.com/boot-camp-class/
Wenn Sie Fragen haben, können Sie uns gerne kontaktieren oder einen weiteren Kommentar hinterlassen.
Prost
Sandra
Hallo, wie kann der Satellit die nicht gelöschten Datensätze identifizieren, que consulta puedo hacer para poder identificar
Hallo Yomar,
Solange kein neuer Link Hash Key für einen Driving Key erscheint und der Link Hash Key noch existiert (Volllast) oder Sie keine Löschinformation von CDC erhalten.
Herzliche Grüße,
Marc
Die Beziehungen, die wir zwischen Hub(s) und Link erstellen, sollten immer identifizierend sein? Dieses Verständnis bezieht sich auf die Tatsache, dass ein Link keinen Eintrag haben sollte, wenn die entsprechenden Schlüssel in den verbundenen HUB(s) nicht vorhanden sind.
Hallo Rupa,
danke für die Frage!
Der Link selbst stellt die Beziehung zwischen den Hubs dar. Ein Link kann so viele Hubs haben, wie Business Keys in Ihren Quellsystemen in Beziehung zueinander stehen. Stellen Sie sich eine Bestellung vor: Er hat eine "Filiale", einen "Kunden" und auf Einzelpostenebene sogar ein "Produkt". Falls es keinen Schlüssel zu einem der zugehörigen Hubs gibt, laden wir den Eintrag trotzdem, da wir sonst Daten verlieren würden. Aber anstelle eines NULL-Schlüssels fügen wir den "Zero Key" hinzu.
Mehr über das Zero-Key-Konzept können Sie hier lesen:
– https://www.scalefree.com/blog/data-vault/implementing-data-vault-2-0-zero-keys/
– https://www.scalefree.com/knowledge/webinars/data-vault-friday/zero-key-concepts-in-data-vault/
Wir bieten auch Schulungen an, in denen wir diese und viele andere Teile der Data Vault-Methodik durchgehen:
https://www.scalefree.com/trainings/boot-camp-class/
Mit freundlichen Grüßen,
Marc