Wenn Datensätze verschwinden …

In einem Data Warehouse nach Data Vault 2.0 kann man sehr gut erkennen, wenn sich die Daten zu einem Geschäftsobjekt verändern. Bei jeder Änderung wird ein neuer Datensatz mit dem aktuellen Ladedatum in den zugehörigen Satelliten eingetragen. Man kann an diesem Satelliten aber nicht erkennen, wenn der Datensatz zu diesem Geschäftsobjekt irgendwann wieder aus dem operativen System verschwindet. Der zuletzt eingetragene Datensatz bleibt im Satelliten erhalten und die Information, dass das Geschäftsobjekt „verschwunden“ ist, muss im Data Warehouse auf andere Art dokumentiert werden.

In diesem Beitrag geht es darum, wie das Verschwinden von Datensätzen im Data Warehouse dokumentiert werden kann.

Mein erster Ansatz, das Verschwinden von Datensätzen zu dokumentieren, habe ich bereits im Artikel Willibald-Data: Übernahme der Kunden ins Data Warehouse im Absatz „Was ist die Bedeutung der „Last Seen“-Tabellen?“ beschrieben. Es handelt sich dabei um Satelliten, deren einzige Payload das Ladedatum ist. Da sich das Ladedatum bei jeder Übernahme der Daten verändert, enthält dieser Satellit einen Datensatz für jeden Zeitpunkt, an dem der Datensatz im operativen System vorhanden war. Da nur der zuletzt geschriebene Satz relevant ist, werden – um Platz zu sparen – alle älteren Sätze über ein SQL-Skript gelöscht. Dieses Verfahren hat den Vorteil, dass es wenig Speicherplatz benötigt. Es kann aber nicht abbilden, wenn ein Datensatz verschwindet und später wieder auftaucht. Diese Datenlücke wird über dieses Verfahren nicht dokumentiert.

Besser wäre es natürlich, wenn nicht mehr gültige Datensätze im operativen System nicht einfach gelöscht werden würden, sondern nur das Ende der Gültigkeit vermerkt werden würde. Das Ende der Gültigkeit wäre dann ein ganz normales Datenfeld im Payload des Satelliten. Aber unser Data Warehouse muss ja auch mit anderen operativen Systemen arbeiten können.

Eine weitere Möglichkeit bieten Systeme, die Change Data Capture (CDC) implementiert haben. Dabei werden alle Datenänderungen kommuniziert und dazu gehört auch das Löschen der Daten. Auch hier ist das Ende der Gültigkeit eine Information im CDC-Satelliten.

Da ich, wie oben bereits angedeutet, mit meiner ersten Implementierung (den „Last Seen“-Tabellen) nicht ganz zufrieden war, habe ich eine bessere Lösung gesucht und bin im Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ von Dan Linstedt und Michael Olschimke auf die Record Tracking Satellites (RTS) gestoßen.

Bei meiner Suche nach einem RTS-Makro in dem Toolset AutomateDV, das ich für die Umsetzung unseres DWH benutze, bin ich dann auf die Extended Tracking Satellites (XTS) gestoßen, die 2019 von Certus Solutions als Ergänzung von DV2.0 auf der wwdvc-Konferenz vorgeschlagen worden sind. Eine Beschreibung davon gibt es in diesem Artikel von Patrick Cuba, den er 2021 auf Medium veröffentlicht hat: „Data Vault 2.0 has a new hero…„.

Die Beschreibung der XTS-Satelliten in AutomateDV steht hier: https://automate-dv.readthedocs.io/en/latest/tutorial/tut_xts/ Für jeden Hub und jeden Link wird ein XTS-Satellit angelegt, der die Tracking-Informationen für jeden Satelliten enthält, der an dem Hub bzw. Link definiert ist.

In meinen Daten der Willibald-Challenge habe ich diese Situation:

  • Stage wb_kd: die Kundendaten aus dem Webshop
    • Hub kd: der Hub Kunde
      • Satellit sat_wb_kd_hub_kd_1:
        der 1. Satellit am Hub Kunde aus der Stage Webshop-Kunden
      • Satellit sat_wb_kd_hub_kd_2:
        der 2. Satellit am Hub Kunde aus der Stage Webshop-Kunden
  • Stage wb_wo: die Wohnorte der Kunden aus dem Webshop
    • Hub kd: der Hub Kunde
      • Satellit mas_wb_wo_hub_kd:
        der Multi-Active-Satellite am Hub Kunde aus der Stage Webshop-Wohnorte
  • Stage rs_best: die Bestellungen aus der Roadshow
    • Hub kd: der Hub Kunde
      • Satellit sat_rs_best_hub_kd
        der Satellit am Hub Kunde aus der Stage Roadshow-Bestellungen

Es gibt vier Satelliten am Hub Kunde, die aus drei verschiedenen Stages bedient werden. Die XTS-Tabelle enthält einen Eintrag für jeden Record in jedem der vier Satelliten.

Bei der Umsetzung der XTS-Tabellen musste ich feststellen, dass die Implementierung des XTS-Makros im Toolset AutomateDV nicht mit der Situation umgehen kann, dass die XTS-Tabelle aus mehreren Stages aufgebaut wird. Mehrere Satelliten aus der gleichen Stage sind kein Problem. Wendet man das XTS-Makro nur auf eine Stage an, dann funktioniert es gut. Deshalb baue ich zunächst drei XTS-Tabellen auf (für jede Stage eine) und kombiniere sie dann in einem View über ein Union-Select.

Alle Informationen, die benötigt werden, um diese XTS-Tabellen und Views zu erzeugen, sind bereits in der Steuerdatei RawVault.xml in meinem Generierungs-Tool GenRawVault enthalten. Ich musste also nur noch den Generator für die xts- und vxts-Skripte bereitstellen und den Generator für die stg-Skripte etwas erweitern, um XTS-Tabellen für alle Hubs und Links zu erzeugen.

Und wofür man so eine XTS-Tabelle nutzen kann, zeige ich in diesem Beispiel für einen View auf den Satelliten sat_wb_kd_hub_kd_1, der im Datenfeld LAST_SEEN anzeigt, wann der Datensatz zuletzt im operativen System gesehen wurde.


Beitrag veröffentlicht

in

, ,

von

Schlagwörter:

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert