Der Wert von nicht-historisierten Links

Als Dan Linstedt, Mitbegründer von Scalefree, das Data Vault erfand, hatte er mehrere Ziele vor Augen. Eines der Ziele war es, Daten so schnell wie möglich aus der Quelle in ein data warehouse-Modell zu laden, sie zu Informationen zu verarbeiten und sie dem Unternehmensanalysten in jeder gewünschten Zielstruktur zu präsentieren.

Der Einfachheit und Automatisierung halber besteht das Modell Data Vault nur aus drei Grundtypen von Einheiten:

1. Hubs: eine eindeutige Liste von Unternehmensschlüsseln
2. Verknüpfungen: eine eindeutige Liste von Beziehungen zwischen Geschäftsschlüsseln
3. Satelliten: beschreibende Datendie den übergeordneten Schlüssel (Geschäftsschlüssel oder Beziehung) in einem bestimmten Kontext beschreiben, der im Laufe der Zeit versioniert wurde.

In diesem Beispiel ist "Sales" eine nicht-historisierte Verbindung, die Verkaufstransaktionen eines Kunden im Zusammenhang mit einer Filiale erfasst. Das Ziel der nicht-historisierten Verbindung ist es, eine hohe Leistung auf dem Weg in den data warehouse und auf dem Weg nach draußen zu gewährleisten. Vergessen Sie nicht, dass das ultimative Ziel von data warehousing der Aufbau eines data warehouse ist, nicht nur dessen Modellierung. Und zum Aufbau eines data warehouse gehört viel mehr als nur das Modell: Es braucht Menschen, Prozesse und Technologie.

Wie also erreicht die nicht-historisierte Verbindung ihre Ziele? Denken Sie an Ihre Business-Analysten. Was sind ihre Ziele? Um ehrlich zu sein, ist ihnen ein Data Vault-Modell letztlich egal. Stattdessen wünschen sie sich dimensionale Modelle wie Sternschemata und Schneeflockenmodelle oder flache und breite Modelle für Data Mining. Oder sie wollen hin und wieder die hässlichen Tabellen aus dem Mainframe sehen, manchmal verknüpft, manchmal nicht, und viele Leute verstehen die Beziehungen nicht mehr ganz... aber für die Rückwärtskompatibilität ist das einfach toll.

Nach der Definition des Ziels 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 (man denke an Anrufdatensätze in der Telekommunikationsbranche oder an Banktransaktionen).

Interessanterweise lässt sich diese gewünschte Zielgranularität oft direkt in den Quellsystemen finden. Denn ein Telekommunikationsanbieter verfügt über ein operatives System, das jeden Telefonanruf aufzeichnet. Oder eine Bankanwendung, die jede Kontotransaktion aufzeichnet. Und diese Datensätze werden in der Regel ohne Aggregation in die data warehouse geladen (zumindest in der Data Vault, wo wir an der feinsten Granularität zu Prüfungs- und Lieferzwecken interessiert sind).

Und hier kommt das Problem mit den Standard Data Vault Entitätstypen. Sie sind zwar sehr einfach und nach einem Muster aufgebaut, haben aber ein Problem. Es ist die Tatsache, dass der Standard-Link "eine eindeutige Liste von Beziehungen speichert", wie oben erwähnt. 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 das gleiche Produkt kauft, ist die Beziehung zwischen Kunde (Nummer), Geschäft (Nummer) und Produkt (Nummer) bereits bekannt, und es wird kein zusätzlicher Link-Eintrag hinzugefügt.

Infolgedessen wird die Granularität der eingehenden Daten beim Laden der Zielverbindung geändert. Wenn die der Transaktion zugrunde liegende Beziehung bereits bekannt ist, würde die Transaktion ausgelassen (und stattdessen von einem Satelliten erfasst) werden.

Das nächste Problem besteht darin, dass die Verknüpfungsgranularität nun von der Zielgranularität abweicht, weil der Geschäftsanalyst einen Datensatz pro Transaktion und nicht pro eindeutiger Geschäftsschlüsselbeziehung wollte. Es ist eine weitere Granularitätsverschiebung erforderlich, bei der in der Regel der Satellit der Verknüpfung mit der Verknüpfung selbst verbunden wird, um die ursprüngliche Granularität wiederherzustellen.

Wie wir in unserem Buch "Aufbau eines skalierbaren Data Warehouse mit Data Vault 2.0"Eine Kornverschiebung ist in Bezug auf die Leistung relativ kostspielig. Dies liegt daran, dass der Vorgang kostspielige GROUP BY-Anweisungen oder LEFT und RIGHT JOINS erfordert.

Und wofür? Das Endergebnis beider Operationen ist oft die ursprüngliche Granularität des Ausgangssystems. Zwei teure Kornverschiebungen für nichts klingt nach einem schlechten Geschäft.

Und das ist sie.

Hier kommt die nicht-historisierte Verknüpfung ins Spiel: Die Verknüpfung ist eine einfache Abwandlung der Standardverknüpfung mit dem Ziel, die Ursprungstransaktionen und -ereignisse in der ursprünglichen Granularität zu erfassen.

Abbildung: Nicht-historisierte Verknüpfung mit Verkaufs-ID als zusätzlicher Schlüssel

Ein tiefergehendes Szenario wäre, wenn dasselbe Produkt (in diesem Fall die höchste Granularität) zweimal in einem Verkauf auftaucht, z. B. aufgrund unterschiedlicher Rabatte. In diesem Fall wäre die Einzelpostennummer ein zusätzlicher Schlüssel (abhängiger untergeordneter Schlüssel), um jeden Datensatz eindeutig zu machen.

Aus Leistungsgründen sollten Kornverschiebungen auf dem Weg nach draußen 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, sollte eine Brückentabelle in Betracht gezogen werden. Der Zweck dieses Entitätstyps besteht darin, die Granularitätsverschiebung zu materialisieren und gleichzeitig den Vorteil zu behalten, dass das Ziel entsprechend den individuellen Anforderungen an das Dimensionsziel angepasst werden kann.

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