Der Business Vault ist die Schicht in der Data Vault 2.0-Architektur, in der die Business-Logik implementiert wird, um Daten zu transformieren, zu bereinigen und zu modifizieren.
Das Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ der Scalefree-Gründer Dan Linstedt und Michael Olschimke sowie das Data Vault 2.0 Boot Camp zeigen, wie eine solche Business-Logik unter Verwendung verschiedener Business Vault Entities, wie beispielsweise Computed Satellites, implementiert werden kann.
Es ist jedoch wichtig zu beachten, dass dies nur ein Teil des Gesamtbildes ist. Das Buch zeigt Computed Satellites (und andere Entities) mit einem Load Date im Primary Key des Computed Satellite. Solche Satellites eignen sich hervorragend, um die Ergebnisse einer Business-Logik zu erfassen, die auf eingehende Deltas angewendet wird. Es gibt jedoch zwei verschiedene Arten von Granularitäten für die Business-Logik im Business Vault:
- In einigen Fällen wird die Business-Logik auf eingehende Deltas angewendet. Wenn beispielsweise Telefonnummern bereinigt werden sollen, wird die Datenbereinigungsregel typischerweise auf alle eingehenden Deltas angewendet, unabhängig davon, ob das Delta letztlich in der Information Delivery verwendet wird. Das mag ungewöhnlich klingen, ist jedoch aufgrund der Leistungsfähigkeit moderner SQL-Optimierer in der Praxis der effizientere Ansatz.
- In anderen Fällen basiert die Granularität der Business-Logik nicht auf den eingehenden Deltas, sondern auf den ausgehenden Informationen.
Die zweite Granularität lässt sich am besten anhand eines praktischen Beispiels beschreiben: Betrachten Sie die tägliche Berechnung des Customer Lifetime Value eines Kunden. Die Formel ist zeitabhängig, je mehr Zeit seit der letzten Bestellung vergangen ist, desto weiter sinkt der Lifetime Value, bis der Kunde eine erneute Bestellung aufgibt.
In einem solchen Fall sinkt der Lifetime Value, obwohl keine neuen Daten im Raw Data Vault eintreffen, es liegt also kein eingehendes Delta vor. Stattdessen sollte der Wert für jeden Kunden regelmäßig (z. B. täglich) berechnet werden. Diese regelmäßige Basis entspricht genau der Granularität der in der Information Delivery definierten Snapshots, die durch das Snapshot Date identifiziert werden.
Vor diesem Hintergrund wird der Computed Satellite angepasst: Das Load Date im Primary Key wird durch das Snapshot Date ersetzt, was der Granularität der ausgehenden Informationen entspricht.
Aus Performancegründen wird der Computed Satellite häufig in Verbindung mit einer PIT Table verwendet. Dabei ist zu beachten, dass der Primary Key solcher Computed Satellites dem Alternate Key der PIT entspricht, welcher aus dem Hash Key des Parents der PIT und dem Snapshot Date besteht. Der beschriebene informationsbasierte Computed Satellite kann somit in der Information Delivery über den Alternate Key der PIT Table gejoint werden.
Fazit
Bei der Entwicklung des Business Vault stehen weitere fortgeschrittene Techniken zur Verfügung. Diese sind äußerst hilfreich bei der Konzeption der Datenflüsse vom Quellsystem bis hin zu den für das Business bereitzustellenden Information Assets.
