Non-Historized Links in Data Vault 2.0
Non-Historized Links in Data Vault 2.0 vereinfachen die Datenmodellierung, indem sie sich auf aktuelle Beziehungen konzentrieren statt auf historische Änderungen. Dies verbessert die Effizienz, reduziert die Komplexität und steigert die Abfrageleistung für agilere Analysen.
Einführung in Non-Historized Links
Non-Historized Links, auch als Transaction Links bekannt, sind ein wesentlicher Bestandteil des Data Vault 2.0 Frameworks – aber wie funktionieren sie innerhalb eines Modells? Als Dan Linstedt, Mitgründer von Scalefree, den Data Vault erfand, verfolgte er mehrere Ziele. Eines davon war es, Daten so schnell wie möglich aus der Quelle in ein Data Warehouse Modell zu laden, sie in Informationen umzuwandeln und dem Business Analysten in jeder gewünschten Zielstruktur bereitzustellen.
Für die Data Warehouse Automatisierung und Einfachheit besteht das Data Vault 2.0 Modell aus nur drei grundlegenden Entitätstypen:
- Hubs: eine eindeutige Liste von Business Keys
- Links: eine eindeutige Liste von Beziehungen zwischen Business Keys
- Satellites: beschreibende Daten, die das übergeordnete Element (Business Key oder Beziehung) aus einem bestimmten Kontext heraus beschreiben, versioniert über die Zeit.
Wie wir immer lehren (und manchmal predigen): Sie können alle Unternehmensdaten allein mit diesen drei Entitätstypen modellieren. Ein Modell, das jedoch nur diese Entitätstypen verwendet, hätte mehrere Nachteile: viele komplexe Joins, hoher Speicherverbrauch, eingeschränkte Ladeleistung und verpasste Möglichkeiten zur Virtualisierung.
Die Lösung? Das Hinzufügen weiterer Bausteine zu den Kernentitätstypen des Data Vault, um diese Probleme zu bewältigen. Einer dieser Bausteine ist die Verwendung von Non-Historized Links, auch als Transaction Links bekannt:
In diesem Beispiel können Verkäufe mit Non-Historized Links modelliert werden, die Verkaufstransaktionen eines Kunden in Bezug auf ein Geschäft erfassen. Das Ziel des Non-Historized Links ist es, eine hohe Performance sowohl beim Laden in als auch beim Auslesen aus dem Data Warehouse sicherzustellen. Vergessen Sie nicht: Das ultimative Ziel des Data Warehousing ist es, ein Data Warehouse zu bauen – nicht nur zu modellieren. Und der Aufbau eines Data Warehouse umfasst weit mehr als nur das Modell: Es erfordert Menschen, Prozesse und Technologie.
Wesentliche Merkmale von Non-Historized Links
Wie erfüllen Non-Historized Links diese Ziele? Denken Sie an Ihre Business Analysten. Was sind ihre Ziele? Ehrlich gesagt interessiert sie das Data Vault Modell am Ende nicht direkt. Stattdessen möchten sie dimensionale Modelle sehen – Star Schemas, Snowflake Schemas oder flache, breite Modelle für Data Mining. Oder gelegentlich möchten sie die unübersichtlichen Tabellen aus dem Mainframe sehen, manchmal verknüpft, manchmal nicht – und nicht mehr viele Menschen verstehen die Beziehungen noch vollständig… aber für die Abwärtskompatibilität ist das hervorragend.
Nachdem das Ziel definiert wurde, stellt sich die nächste Frage: Was ist die Zielgranularität? In einem dimensionalen Modell spiegelt die Zielgranularität von Faktentabellen beispielsweise häufig die zu analysierenden Transaktionen wider – denken Sie an Anrufaufzeichnungen in der Telekommunikationsbranche oder Banktransaktionen.
Interessanterweise ist diese gewünschte Zielgranularität häufig direkt in den Quellsystemen zu finden. Ein Telekommunikationsanbieter verfügt über ein operatives System, das jeden Telefonanruf aufzeichnet. Oder eine Bankanwendung, die jede Kontotransaktion erfasst. Diese Datensätze werden in der Regel ohne Aggregation in das Data Warehouse geladen – im Data Vault arbeiten wir auf der feinsten Granularität für Prüf- und Lieferzwecke.
Und hier liegt das Problem mit den Standard-Data Vault Entitätstypen. Obwohl sie sehr einfach und musterbasiert sind, haben sie ein Problem: Der Standard-Link speichert eine eindeutige Liste von Beziehungen. Das bedeutet, dass der Link nur an Beziehungen aus der Quelle interessiert ist, die dem Ziel-Link unbekannt sind. Wenn ein Kunde mehrmals in ein Geschäft geht und dasselbe Produkt kauft, ist die Beziehung zwischen Kunde, Geschäft und Produkt bereits bekannt – es wird kein weiterer Link-Eintrag hinzugefügt.
Infolgedessen wird die Granularität der eingehenden Daten beim Laden des Ziel-Links verändert. Wenn die dem Vorgang zugrunde liegende Beziehung bereits bekannt ist, wird die Transaktion ausgelassen – und stattdessen von einem Satellite erfasst.
Das nächste Problem besteht darin, dass die Link-Granularität nun von der Zielgranularität abweicht, weil der Business Analyst einen Datensatz pro Transaktion und nicht pro eindeutiger Business Key-Beziehung wollte. Eine weitere Granularitätsverschiebung ist erforderlich, die typischerweise das Verknüpfen des Satellite des Links mit dem Link selbst beinhaltet, um die ursprüngliche Granularität wiederherzustellen.
Wie wir in unserem Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ erläutert haben, ist eine Granularitätsverschiebung in Bezug auf die Performance relativ kostspielig. Dies liegt daran, dass der Vorgang aufwendige GROUP BY-Anweisungen oder LEFT und RIGHT JOINS erfordert.
Und wofür? Das Endergebnis beider Operationen entspricht oft der ursprünglichen Granularität aus dem Quellsystem. Zwei aufwendige Granularitätsverschiebungen für nichts – das klingt nach einem schlechten Tausch.
Und genau das ist der Fall.
Hier kommen Non-Historized Links ins Spiel: Der Link ist eine einfache Variation des Standard-Links mit dem Ziel, die Quelltransaktionen und -ereignisse in der ursprünglichen Granularität zu erfassen.
Abbildung: Non-Historized Link mit der Verkaufs-ID als zusätzlichem Schlüssel
Ein tiefergehendes Szenario wäre, wenn dasselbe Produkt (in diesem Fall die höchste Granularität) zweimal in einem Verkauf vorkommt – beispielsweise aufgrund unterschiedlicher Rabatte. In diesem Fall wäre die Positionsnummer ein zusätzlicher Schlüssel (Dependent Child Key), um jeden Datensatz eindeutig zu machen.
Aus Performance-Gründen sollten Granularitätsverschiebungen beim Auslesen vermieden werden. Wenn eine andere Zielgranularität erforderlich ist und es nicht möglich ist, diese Granularität aus dem Quellsystem oder aus dem Data Vault Modell zu laden, sollten Sie eine Bridge Table in Betracht ziehen. Der Zweck dieses Entitätstyps besteht darin, die Granularitätsverschiebung zu materialisieren und dabei den Vorteil zu behalten, das Ziel gemäß den individuellen Anforderungen des dimensionalen Ziels anzupassen.
Abbildung: Virtuelle Bridge Table als Faktentabelle mit GROUP BY Store Hash Key
Fazit
Non-Historized Links bieten einen effizienten Ansatz zur Data Vault Modellierung, der die Performance optimiert und Datenstrukturen vereinfacht. Indem sie sich auf aktuelle Beziehungen statt auf historische Änderungen konzentrieren, steigern sie die Effizienz, reduzieren den Speicherbedarf und verbessern die Abfragegeschwindigkeit. Die Integration in Ihre Datenarchitektur kann zu einer agileren und skalierbareren Analyseumgebung führen.
