Der Nutzen von Non-Historized Links

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 statt auf historische Änderungen konzentrieren. Das steigert die Effizienz, reduziert die Komplexität und verbessert die Abfrage-Performance für agilere Analysen.

Einführung in Non-Historized Links

Non-historized Links, auch bekannt als Transaction Links, sind ein zentrales Element des Data Vault 2.0-Frameworks – aber wie funktionieren sie eigentlich im Modell? Als Dan Linstedt, Mitbegründer von Scalefree, Data Vault erfand, verfolgte er mehrere Ziele. Eines davon: Daten so schnell wie möglich aus der Quelle ins Data-Warehouse-Modell laden, zu Informationen verarbeiten und dem Business-Analysten in jeder gewünschten Zielstruktur bereitstellen.

Zur Vereinfachung und Automatisierung im Data Warehouse besteht das Data Vault 2.0 Modell aus nur drei grundlegenden Entitätstypen:

1. Hubs: eine eindeutige Liste von Business Keys
2. Links: eine eindeutige Liste von Beziehungen zwischen Business Keys
3. Satellites: beschreibende Daten, die den übergeordneten Schlüssel (Business Key oder Beziehung) in einem bestimmten Kontext über die Zeit versioniert beschreiben

In diesem Beispiel lassen sich Sales mit Non-Historized Links modellieren, die einzelne Transaktionen eines Customer im Zusammenhang mit einem Store erfassen. Ziel dieser Links ist es, sowohl beim Laden ins Data Warehouse als auch beim Abfragen eine hohe Performance sicherzustellen. Nicht vergessen: Ziel von Data Warehousing ist es, ein funktionierendes Data Warehouse aufzubauen – nicht nur ein Modell zu entwerfen. Und dafür braucht es mehr als nur das Modell: Menschen, Prozesse und Technologie.

Hauptmerkmale von Non-Historized Links

Wie also helfen Non-Historized Links dabei, diese Ziele zu erreichen? Denk an deine Business-Analysten. Was sind ihre Ziele? Um ehrlich zu sein: Sie interessieren sich in der Regel nicht für ein Data-Vault-Modell. Stattdessen möchten sie dimensionale Modelle sehen – etwa Star Schemas, Snowflake Schemas oder Flat-and-Wide-Modelle fürs Data Mining. Oder sie wollen gelegentlich die alten, unansehnlichen Tabellen vom Mainframe sehen – manchmal verknüpft, manchmal nicht –, bei denen kaum noch jemand die Beziehungen versteht... Aber für die Abwärtskompatibilität ist das völlig in Ordnung.

Ist das Ziel definiert, stellt sich die nächste Frage: Was ist die Zielgranularität? In einem dimensionalen Modell spiegelt die Zielgranularität von Fact Tables häufig die zu analysierenden Transaktionen wider – (zum Beispiel Anrufdatensätze in der Telekommunikationsbranche oder Buchungen im Bankwesen).

Interessanterweise lässt sich diese gewünschte Zielgranularität oft direkt in den Quellsystemen finden. Denn ein Telekommunikationsanbieter hat ein operatives System, das jeden einzelnen Anruf erfasst. Oder eine Bankanwendung zeichnet jede Kontobewegung auf. Diese Datensätze werden in der Regel ohne Aggregation in das Data Warehouse geladen – zumindest im Data Vault, wo wir an der feinsten Granularität für Prüf- und Lieferzwecke interessiert sind.

Und hier zeigt sich ein Problem der Standard-Entitätstypen im Data Vault. Sie sind zwar einfach und standardisiert, bringen aber eine Einschränkung mit sich. Denn wie bereits erwähnt, speichert der Standard-Link „eine eindeutige Liste von Beziehungen“. Das bedeutet, dass nur solche Relationen aus der Quelle berücksichtigt werden, die dem Ziel-Link noch nicht bekannt sind. Wenn ein Customer also mehrmals in denselben Store geht und dasselbe Product kauft, ist diese Beziehung bereits bekannt – und es wird kein zusätzlicher Link-Eintrag erzeugt.

Infolgedessen ändert sich die Granularität der eingehenden Daten beim Laden des Links. Wenn die Beziehung einer Transaktion bereits bekannt ist, wird diese Transaktion ausgelassen – und stattdessen durch einen Satellite erfasst.

Das nächste Problem: Die Link-Granularität unterscheidet sich nun von der Zielgranularität, da der Business-Analyst einen Datensatz pro Transaktion erwartet, nicht nur pro eindeutiger Beziehung. Es ist ein weiterer Grain Shift erforderlich – typischerweise durch das Joinen des Satellites mit dem Link, um die ursprüngliche Granularität wiederherzustellen.

Wie wir in unserem Buch "Building a Scalable Data Warehouse with Data Vault 2.0" beschrieben haben, ist ein solcher Grain Shift (in Bezug auf die Leistung relativ kostspielig). Denn der Vorgang erfordert aufwendige GROUP BY-Operationen oder LEFT- und RIGHT-JOINs.

Und wofür das Ganze? Das Endergebnis beider Schritte ist häufig wieder die ursprüngliche Granularität aus dem Quellsystem. Zwei teure Grain Shifts – für nichts.

Genau das ist der Punkt.

Hier kommen Non-Historized Links ins Spiel: Sie sind eine einfache Variation des Standard-Links – mit dem Ziel, Quelltransaktionen und Events in ihrer ursprünglichen Granularität zu erfassen.

Abbildung: Non-Historized Link mit Sales ID als zusätzlichem Schlüssel

Ein komplexeres Szenario wäre der Fall, dass dasselbe Product – also die feinste Granularität – innerhalb eines Sales zweimal vorkommt, zum Beispiel aufgrund unterschiedlicher Rabatte. In diesem Fall dient die Position des einzelnen Line Items als zusätzlicher Schlüssel (Dependent Child Key), um jeden Datensatz eindeutig zu machen.

Aus Performance-Gründen sollten Grain Shifts beim Auslesen ebenfalls vermieden werden. Wenn eine abweichende Zielgranularität benötigt wird, die sich weder aus dem Quellsystem noch aus dem Data-Vault-Modell direkt laden lässt, empfiehlt sich der Einsatz einer Bridge Table. Diese modelliert den Grain Shift explizit und bietet gleichzeitig die Möglichkeit, das Zielmodell flexibel an die Anforderungen des jeweiligen dimensionalen Zielmodells anzupassen.

Abbildung: Virtuelle Bridge Table als Fact Table mit GROUP BY Store Hash Key

Fazit

Non-Historized Links bieten einen einen vereinfachten und performanten Ansatz für die Data-Vault-Modellierung. Sie optimieren die Performance und vereinfachen die Datenstrukturen. Durch den Fokus auf aktuelle Beziehungen statt historischer Änderungen steigern sie die Effizienz, senken den Speicherbedarf und verbessern die Abfragegeschwindigkeit. Ihre Integration in die Datenarchitektur kann zu einer agileren und besser skalierbaren Analyseumgebung führen.