Umgang mit der Validierung von Beziehungen in Data Vault 2.0

Validierung von Beziehungen in Data Vault 2.0

Es gibt verschiedene Möglichkeiten, die Validierung von Beziehungen aus Quellsystemen zu handhaben. Dies hängt davon ab, wie die Daten geliefert werden (Full-Extract oder CDC) und wie ein Löschvorgang vom Quellsystem übermittelt wird – beispielsweise als Soft Delete oder Hard Delete. In Data Vault 2.0 unterscheiden wir Daten nach Schlüsseln (Keys), Beziehungen und Beschreibungen.

Dennoch ist die Handhabung und Validierung von Beziehungen in Data Vault 2.0 ein oft unterschätzter Aspekt.
Im folgenden Blogartikel erklären wir, was Sie beachten müssen und wie Sie am besten damit umgehen.

 

Löschungen in Data Vault 2.0

Zuerst betrachten wir die verschiedenen Arten von Löschungen (Deletes) in Quellsystemen:

1. Hard Delete – Ein Datensatz wird im Quellsystem physisch gelöscht und existiert dort nicht mehr.
2. Soft Delete – Der gelöschte Datensatz bleibt in der Datenbank des Quellsystems bestehen, wird jedoch als gelöscht gekennzeichnet.

Als Nächstes untersuchen wir, wie wir diese Daten in der Staging Area identifizieren:

1. Full-Extract – Dies kann der aktuelle Zustand des Quellsystems oder ein Delta- bzw. inkrementeller Extrakt sein.
2. CDC (Change Data Capture) – Es werden nur neue, aktualisierte oder gelöschte Datensätze geliefert, um Daten inkrementell oder als Delta 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 – selbst wenn kein Audit-Trail aus dem Quellsystem vorliegt (Data Aging ist hierbei ein anderes Thema).

Erkennung von Löschungen und Validierung von Beziehungen in Data Vault 2.0

Die Erkennung von Löschungen für Business Keys oder Hubs ist unkompliziert. Soft Deletes werden direkt als beschreibende Attribute im Satelliten behandelt – unabhängig davon, ob die Daten aus einem Full-Extract oder über CDC eingehen. Bei Hard Deletes im Quellsystem müssen wir hingegen zwischen Full-Extract und CDC unterscheiden.
Hier führen wir den Effectivity-Satelliten ein. Dabei gilt:

1. Full-Extract – Führen Sie einen Abgleich (Lookup) mit der Staging Area durch, um zu prüfen, ob der Business Key noch existiert. Wenn nicht, fügen Sie einen Datensatz mit den Löschinformationen (d. h. ein Flag und ein Datum) in den Effectivity-Satelliten ein.
2. CDC – Sie erhalten eine „Delete“-Information, was direkt zu einem neuen Eintrag im Effectivity-Satelliten führt.

Die Erkennung gelöschter Beziehungen erfordert etwas mehr Aufmerksamkeit und wird oft übersehen. Bei einem Full-Extract können Sie denselben Ansatz wie bei Business Keys verfolgen: Prüfen Sie einfach, ob der Link-Hash-Key im aktuellen Staging-Ladevorgang vorhanden ist, und fügen Sie bei Bedarf einen neuen Eintrag in den Effectivity-Satelliten ein.

Heutzutage setzt sich CDC immer mehr durch. Da diese Methode jedoch nur Deltas liefert, besteht die Herausforderung darin, nicht mehr existierende Beziehungen zu identifizieren. Das folgende Beispiel zeigt eine Beziehung zwischen den Business-Objekten Customer und Company. Dies ist eine 1:n-Beziehung:

Abbildung 1: Tabellen Customer und Company

Die Link-Tabelle in Data Vault sieht wie folgt aus:

Tabelle 1: Customer-Link

Zur besseren Lesbarkeit und Vereinfachung stellen wir die Business Keys anstelle von Hash-Keys dar und verzichten auf die Darstellung von Systemfeldern wie dem Load-Date-Timestamp und der Record-Source.

So weit, so gut. Was passiert jedoch, wenn ein Kunde für ein anderes Unternehmen tätig wird? Dies führt zu einem neuen Datensatz in der Link-Tabelle. Der CDC-Mechanismus liefert die Daten als Update der Customer-Tabelle.

Abbildung 2: Quelltabellen und Link nach Unternehmenswechsel

Woher stammt die Information, dass Customer 4711 nicht mehr für Company 1234 arbeitet, und wo wird diese gespeichert? Es muss ein Soft Delete für den alten Link-Eintrag im Data Warehouse durchgeführt werden, um die Datenkonsistenz zu wahren. Aktuell sieht es so aus, als ob der Kunde für beide Unternehmen tätig wäre, da beide Links aktiv sind.

Hierfür gibt es zwei mögliche Lösungswege:

1. Sie erhalten die „Gültig von“- und „Gültig bis“-Angaben in Ihrem Audit-Trail und identifizieren eine Differenz bei der company_id. In diesem Fall erstellen Sie zwei neue Einträge im Effectivity-Satelliten: Der erste markiert die alte Beziehung (von) als gelöscht, der zweite die neue Beziehung (bis) als aktiv (nicht gelöscht). Es ist notwendig, neue Beziehungen als „nicht gelöscht“ einzufügen, damit Sie Hash-Keys flexibel aktivieren und deaktivieren können.
   Bedenken Sie dabei auch das Szenario, dass Customer 4711 später wieder für Company 1234 tätig wird.
2. Falls diese Angaben fehlen, müssen Sie die CDC-Daten entweder in eine Persistent Staging Area (PSA) laden, um die gesamte Historie der gelieferten Daten aufzubewahren, oder in ein Source Replica überführen. Im Source Replica erstellen Sie ein Spiegelbild des Quellsystems, indem Sie es mit den CDC-Daten speisen. Dabei führen Sie bei einem „Update“-Signal ein Hard Update und bei einem „Delete“-Signal ein Hard Delete durch. Bei der Verwendung eines Source Replica können Sie denselben Ansatz wie bei Vollabzügen (Full-Loads) verfolgen: Sie führen einen Join auf das Replica aus, um zu prüfen, ob der Hash-Key noch existiert.
   Der größte Nachteil dieser Methode ist der höhere Scan-Aufwand, was zu einer höheren I/O-Last führt. Bei der Verwendung einer Persistent Staging Area können Sie Änderungen in einer Beziehung mithilfe der Window-Funktion lead() ermitteln. Dabei partitionieren Sie nach der technischen ID (in diesem Fall Customer_ID) und sortieren nach dem Load Date Timestamp.
   Sobald sich der Link-Hash-Key unterscheidet, hat sich die Beziehung geändert und die vorherige existiert nicht mehr..

Das Ergebnis ist der folgende (logische) Effectivity-Satellit:

Tabelle 2: Effectivity-Satellit auf dem Link

Fazit

In diesem Artikel haben wir zwei wesentliche Aspekte behandelt. Erstens extrahieren wir in Data Vault 2.0 Beziehungsinformationen direkt aus den Quelltabellen, weshalb die Validierung dieser Informationen besondere Aufmerksamkeit erfordert.
Zweitens bietet Ihnen die Art der Datenbereitstellung (Delta via CDC oder Full-Extract) unterschiedliche Optionen für den Ladevorgang. Bei großen Datenmengen ist CDC definitiv die bevorzugte Methode. Zudem erfasst der CDC-Mechanismus alle Änderungen direkt aus der Quelle, was das Laden von Daten in (nahezu) Echtzeit erheblich erleichtert.