In Data Vault 2.0 unterscheiden wir die Daten nach Schlüsseln, Beziehungen und Beschreibung.
Ein oft unterschätzter Punkt ist jedoch die Handhabung von Beziehungen in Data Vault 2.0.
Im Folgenden erklären wir, was zu beachten ist und wie man damit umgeht:
Es gibt verschiedene Möglichkeiten, die Validierung von Beziehungen aus Quellsystemen zu handhaben, je nachdem, wie die Daten geliefert werden (Vollextrakt oder CDC) und wie ein Löschvorgang vom Quellsystem geliefert wird, z. B. als Soft Delete oder Hard Delete.
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).
Die Erkennung von Löschungen für Business-Keys oder Hubs ist unkompliziert. Weiche Löschungen werden direkt als beschreibende Attribute im Satellite behandelt und berücksichtigen nicht, ob die Daten aus einem Vollextrakt oder einer CDC stammen. Bei harten Löschungen im Quellsystem müssen wir zwischen Vollextrakt und CDC unterscheiden.
Hier stellen wir den Effektivitätssatelliten vor. 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 das der Fall ist, erstellen Sie 2 neue Einträge im Gültigkeits-Satelliten, einer markiert die alte Beziehung (von) als gelöscht und der 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. - Wenn Sie keine "von" und "nach" haben, müssen Sie entweder die CDC-Daten in einen persistenten Staging-Bereich laden, in dem Sie die gesamte Historie der von CDC gelieferten Daten aufbewahren, oder eine Quellreplik erstellen, 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 CDC kommt, und harte Löschungen, wenn ein "Delete" von 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
Wir haben in diesem Artikel zwei wichtige Punkte behandelt. Der erste ist, dass wir in Data Vault Beziehungsinformationen aus den Quelltabellen extrahieren und daher der Validierung dieser Informationen mehr Aufmerksamkeit schenken müssen.
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.
Sie können Ihre Fragen und Kommentare gerne im folgenden Abschnitt hinterlassen!
- 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.
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.
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