Validierung der Beziehungen in Data Vault 2.0
Je nachdem, wie die Daten geliefert werden, gibt es verschiedene Möglichkeiten, die Validierung von Beziehungen aus Quellsystemen zu handhaben (Vollextrakt oder CDC), und die Art und Weise, wie ein Löschvorgang vom Quellsystem durchgeführt wird, z. B. als Soft Delete oder Hard Delete. Unter Data Vault 2.0Wir unterscheiden die Daten nach Schlüsseln, Beziehungen und Beschreibung.
Ein oft unterschätzter Punkt ist jedoch die Handhabung und Validierung von Beziehungen in Data Vault 2.0.
Im folgenden Blog erklären wir, was zu beachten ist und wie man damit umgeht.
Gelöscht 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).
Löschen Erkennung und Validierung von Beziehungen in Data Vault 2.0
Erkennung löschen für betriebswirtschaftliche Schlüssel oder Hubs ist einfach zu handhaben. Soft Deletes werden als beschreibende Attribute direkt im Satellite behandelt und berücksichtigen nicht, ob die Daten aus einem Vollextrakt oder CDC stammen. Bei harten Löschungen im Quellsystem müssen wir zwischen Vollextrakt und CDC unterscheiden. CDC.
Hier stellen wir die Wirkungsgrad Satellit. Im Falle von:
- 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.
Wenn dies der Fall ist, legen Sie 2 neue Einträge in der Datei Wirkungsgrad SatellitDie eine markiert die alte Beziehung (von) als gelöscht und die andere markiert die neue Beziehung (nach) als nicht gelöscht. Es ist notwendig, neue Beziehungen als "nicht gelöscht" einzufügen, damit Sie Hash Keys hin und zurück aktivieren und deaktivieren können.
Überlegen Sie, was passiert, wenn der Kunde 4711 wieder für das Unternehmen 1234 arbeitet. - Falls Sie die Angaben "von" und "bis" nicht haben, müssen Sie entweder die CDC Daten in einen persistenten Staging-Bereich, in dem Sie die gesamte Historie der von CDC gelieferten Daten aufbewahren, oder eine Quellreplik, in der Sie eine Spiegelung des Quellsystems erstellen, indem Sie es mit den CDC-Daten füttern, wobei Sie harte Aktualisierungen durchführen, wenn ein "Updated" von der CDC kommt, und harte Löschungen, wenn ein "Delete" von der CDC kommt.
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
Wir haben in diesem Artikel zwei wichtige Punkte behandelt. Der erste ist, dass in Data Vault 2.0Da wir die Beziehungsinformationen aus den Quelltabellen extrahieren, müssen wir der Validierung dieser Informationen mehr Aufmerksamkeit schenken.
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)
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