Multi-Aktiv Satelliten richtig einsetzen - Teil 2

Multi-Active Satellites in Data Vault 2.0

In unserem ersten Beitrag über multiaktive Satelliten haben wir kurz verschiedene Implementierungsansätze zur Behandlung von Multiaktivität vorgestellt. In diesem Artikel betrachten wir nun die Vor- und Nachteile dieser Ansätze – jeweils mit aktivierten oder deaktivierten Delta-Prüfungen.

Kurze Zusammenfassung von Multi-Active Satelliten

Multiaktive Satelliten ermöglichen Ihnen die Implementierung mehrerer aktiver Datensätze pro Business Key in Data Vault 2.0. Um die Notwendigkeit für eine solche Lösung zu verdeutlichen, betrachten wir ein häufiges Szenario: Ein Quellsystem liefert nicht die erforderlichen Metadaten – etwa bei der Verarbeitung von XML-Dateien.

Eine Lösung besteht darin, einen multiaktiven Satelliten zu modellieren, indem pro Business Key eine Teilsequenznummer ergänzt wird. Damit lassen sich Fälle abbilden, in denen kein eindeutiges multiaktives Attribut aus der Quelle stammt. Bei Telefonnummern könnte dies beispielsweise ein Tag sein, der zwischen geschäftlich, privat oder mobil unterscheidet. Alternativ ließe sich ein zusätzlicher Hub für das multiaktive Attribut erstellen, da es sich dabei jedoch nicht um ein eigenständiges Geschäftsobjekt handelt, ist die erste Lösung in der Regel vorzuziehen.

Delta Check OFF

Es gibt zwei Möglichkeiten, neue Datensätze in einen multiaktiven Satelliten zu laden – mit aktivierter oder deaktivierter Delta-Prüfung. Ist die Delta-Prüfung deaktiviert, werden alle Datensätze eines Business Keys aus der Quelle vollständig in den Satelliten eingefügt.

Der Vorteil dieser Methode ist ein schnellerer Ladevorgang sowie ein einheitlicher Ladezeitstempel zum übergeordneten Hash Key – unabhängig vom multiaktiven Attribut.

Zudem vereinfacht sich später die Abfrage der multiaktiven Daten (siehe Abbildung 1). Ein wesentlicher Nachteil besteht jedoch darin, dass sich das Datenvolumen stark erhöhen kann, insbesondere bei vollständigen Ladevorgängen.

In solchen Fällen empfiehlt es sich, die Daten nach dem Ladezeitstempel zu partitionieren. 

Abbildung 1: Verknüpfung von Datensätzen mit einer PIT-Tabelle, wenn ein gemeinsamer LDTS für alle aktiven Datensätze je Schlüssel verwendet wird.

Delta Check ON

Um die Datenmenge zu reduzieren, können Deltaprüfungen eingesetzt werden. Dabei werden die eingehenden Daten mit dem jeweils aktuellsten LDTS pro Hash Key abgeglichen.
Eine hilfreiche Funktion zur Umsetzung der Deltaprüfung ist LISTAGG(). Diese Funktion fasst Werte aus einer Gruppe von Zeilen zu einer Liste zusammen. Damit lässt sich eine Hash Differenz über mehrfach aktive Attribute je Geschäftsschlüssel erzeugen (siehe Abbildung 2).

Abbildung 2. Mehrzeilige Hash-Differenz unter Verwendung der LISTAGG()-Funktion

Wenn neue Daten eintreffen, können sie mit der mehrzeiligen Hash-Differenz verglichen werden. Auf diese Weise kann ein großer Teil der Daten ignoriert werden. Wird ein Delta erkannt, werden dennoch alle Datensätze für den betreffenden Hash Key erneut eingefügt – selbst wenn sich nur der Inhalt einer einzelnen Teilsequenz geändert hat. Dadurch entsteht ein konsistenter Zeitstempel des Ladedatums pro Hash Key. Ein Delta wird auch erkannt, wenn sich lediglich die Reihenfolge der Datensätze ändert. Dieser Ansatz stellt einen Kompromiss dar: Er reduziert die Zahl der zu ladenden Datensätze, sorgt aber gleichzeitig für konsistente Zeitstempel pro Hash Key – sodass nur eine einzige PIT-Tabelle benötigt wird.

Typ-Codes verwenden

Eine weitere Methode zur Handhabung von Mehrfachaktivität besteht in der Nutzung von Attributtypen – sofern diese vorhanden sind – wie bereits im vorherigen Beitrag erläutert.
Wenn Typ-Codes vorhanden sind, können die Daten zeilenweise verglichen und nur die jeweils relevanten Datensätze geladen werden. Dies führt jedoch dazu, dass pro multiaktivem Attribut unterschiedliche LDTS entstehen. Wird im Business Vault mit PIT-Tabellen gearbeitet, ist in diesem Fall eine separate multiaktive PIT-Tabelle erforderlich. Dieses Szenario zeigt Abbildung 3.

Abbildung 3. Notwendigkeit eines MA-PIT bei unterschiedlichen LDTS pro aktivem Datensatz

Lässt sich die multiaktive Spalte in mehrere Spalten aufteilen, also je eine Spalte pro Ausprägung, entfallen die zuvor genannten Vor- und Nachteile. Der Satellit wird damit zu einem Standardsatelliten. In Bezug auf unser Beispiel mit den Telefonnummern würde man somit bspw. eine eigene Spalte für Geschäfts-, Privat- und Mobilnummer einführen.
Diese Lösung ist am besten geeignet, wenn sichergestellt werden kann, dass sich die Typ-Codes (z. B. Telefontypen) zukünftig nicht ändern. Andernfalls müsste der Prozess neu gestaltet werden, um sämtliche gelieferten Daten weiterhin zuverlässig zu erfassen!

Fazit

In unserem zweiten Beitrag über multiaktive Satelliten haben wir die Hintergründe verschiedener Methoden beleuchtet. Die vorgestellten Ansätze können Sie nutzen, um je nach Ausgangslage eine passende Lösung für multiaktive Daten umzusetzen.
Beachten Sie jedoch, dass es häufig sinnvoll ist, die zu ladenden Datenmengen zu begrenzen – hier kann die LISTAGG()-Funktion hilfreich sein. Wenn Sie eine Lösung mit potenziell unterschiedlichen LDTS einsetzen, sollten Sie diese beim Abfragen der Daten unbedingt berücksichtigen.

- von Marvin Geerken (Scalefree)