Skip to main content
search
0
CartClose Cart
All Posts By

Marc Winkelmann

Marc Winkelmann is a Senior Managing Consultant and Certified Data Vault 2.1 Trainer at Scalefree with over 8 years of BI experience. A Snowflake SnowPro Advanced Data Engineer and dbt Certified Developer, he specializes in cloud migrations (AWS, Azure, Snowflake) and enterprise data strategy. Marc holds a Master’s in BI & Analytics and is an expert in coaching teams through complex data transformations.

In Datenarchitektur

Write-Backs in der Enterprise-Data-Warehouse-Architektur

Managed Self Service BI and write backs

Die Data-Vault-2.0-Schichten

Diese Ausgabe behandelt Write-Backs in das Enterprise-Data-Warehouse und zeigt, wie die Data-Vault-2.0-Architektur diese ermöglicht. Viele kennen bereits die klassische Drei-Schichten-Architektur von Data Warehouses, die auch in Data Vault 2.0 verwendet wird. Die erste Schicht bildet die Staging Area, welche die Rohdaten (Raw Data) aus den Quellsystemen aufnimmt. Die zweite Schicht ist die Enterprise-Data-Warehouse-Schicht mit dem Data-Vault-2.0-Modell. Die dritte Schicht umfasst die Information Marts, welche die Daten in verschiedenen Strukturen wie Star- oder Snowflake-Schemata bereitstellen.

DV2.0 Architecture and write backs

Abbildung 1: Data-Vault-2.0-Architektur

Diese Architektur bietet optimale Voraussetzungen für Write-Backs von Daten. Grundsätzlich gibt es zwei Wege: das Zurückschreiben von Daten in das Enterprise-Data-Warehouse sowie direkt in die Quellsysteme. Dieser Artikel befasst sich mit dem Write-Back in das Enterprise-Data-Warehouse, während ein nachfolgender Beitrag das Write-Back in die Quellsysteme beleuchtet.

Continue Reading

In Datenmodellierung

Modellierung bei strukturellen Änderungen im Quellsystem

Modellierung eines Satelliten bei strukturellen Änderungen im Quellsystem

Im Laufe der Zeit kann sich ein Quellsystem verändern. Es stellt sich die Frage, wie diese Änderungen in ein Data Vault 2.0 Data Warehouse integriert werden können – insbesondere im Hinblick auf die Satelliten.

Bei Änderungen der Quelltabellenstruktur gilt es, eine Balance zwischen Reengineering-Aufwand und Performance zu finden. Um allen zu helfen, die mit strukturellen Änderungen im Quellsystem konfrontiert sind, stellt dieser Artikel auf Basis unserer Knowledge Base Empfehlungen für verschiedene Arten von Quelländerungen vor.

Dieser Artikel beschreibt Eigenschaften des Data Vault 2.0-Modells: Das Fundament aus Hub-, Link- und Satelliten-Entitäten kann sich problemlos an Änderungen der Quelldaten anpassen, wodurch die Kosten für das Reengineering des Enterprise Data Warehouse reduziert werden.

In this article:

Neue Spalten im Quellsystem: Vorgehen beim Hinzufügen von Attributen

Es gibt zwei Optionen, um neue Attribute aus der Quelle in das Data Warehouse zu übernehmen. Erstens kann der bestehende Satellit angepasst werden.
Dies ist ein pragmatischer Ansatz, erfordert jedoch die Änderung bestehenden Codes.
Zweitens ist es möglich, einen neuen Satelliten für das neue Attribut bzw. die neuen Attribute zu erstellen, ohne die bestehenden Satelliten zu verändern. Dies hat den Vorteil, dass kein bestehender Code angepasst werden muss (Zero Code Impact), erfordert jedoch mehr Joins im Bereich der Informationsbereitstellung (Information Delivery) des Data Vaults.

Die erste Option erfordert diesen Join nicht, da das neue Attribut dem bestehenden Satelliten hinzugefügt wird. Der beste Ansatz besteht darin, die Vor- und Nachteile beider Optionen im Kontext Ihrer spezifischen Situation abzuwägen. Automatisierungstools können beispielsweise die ALTER-TABLE-Anweisung in der Regel automatisch ohne manuellen Programmieraufwand verarbeiten, erfordern jedoch Änderungen an der Datenbank.

Löschen von Spalten im Quellsystem

Eine Option besteht darin, den „alten“ Satelliten zu schließen, d. h. nicht weiter zu beladen (indem der ETL-Code deaktiviert wird), und einen neuen Satelliten zu erstellen, der fortan beladen wird. Der gleiche Ansatz wird gewählt, wenn die zugrunde liegenden Datenstrukturen der Quelle in größerem Umfang geändert werden.
Alte Satelliten werden abgeschaltet, neue Satelliten mit der neuen Struktur werden anschließend beladen.
Eine andere Option ist sinnvoller, wenn nur geringfügige Änderungen erforderlich sind, wie etwa das Entfernen einer einzelnen Spalte. In diesem Fall kann diese Spalte mit einem NULL-Wert oder einem fachlich korrekten Ersatzwert „simuliert“ werden, was für Revisionszwecke hilfreicher ist.

Wenn ein neuer Satellit erstellt wird, führt dies zu zwei neuen Spalten in der zugehörigen PIT-Tabelle (Hash-Key + LDTS).

Das Schließen eines Satelliten und das Erstellen eines neuen ist auch bei größeren Änderungen im Quellsystem anwendbar, beispielsweise bei einer neuen Release-Version des Quellsystems, bei der Spalten gelöscht, umbenannt und neu erstellt werden. Bei kleineren Änderungen, insbesondere wenn Spalten entfallen, empfehlen wir die Anpassung des bestehenden Satelliten.

Erstellung einer virtuellen Dimensionstabelle aus einer PIT-Tabelle mit mehreren Satelliten

Wenn ein neuer Satellit für das neue Attribut (oder die neuen Attribute) erstellt wird, anstatt den bestehenden Satelliten zu verändern, ist eine neue virtuelle Dimension erforderlich, um Informationen aus PIT-Tabellen unter Verwendung beider Satelliten basierend auf dem erforderlichen Zeitstempel abzufragen.
Es gibt zwei Ansätze, wie Informationen aus beiden Satelliten abgerufen werden können:

  • Der erste Ansatz nutzt einen Computed Satellite, in dem Sie alle Satelliten mit dem aktuellsten Datensatz pro Hash-Key und derselben Struktur kombinieren. Dies kann jedoch eine komplexe Abfrage sein, da sie von der Datenmenge und der Anzahl der zu joinenden Satelliten abhängt.
  • Der zweite Ansatz besteht darin, eine PIT-Tabelle für alle Satelliten zu verwenden. Beim Abfragen der Daten beispielsweise für eine Dimensionstabelle, wählen Sie den Datensatz aus dem führenden Satelliten aus, zum Beispiel mithilfe einer IIF-Anweisung oder der COALESCE-Funktion.

Fazit

Obwohl jede Situation einen Ansatz erfordert, der den individuellen Charakter der Aufgabenstellung berücksichtigt, haben sich die oben genannten Lösungen bei der Umsetzung in unseren eigenen Projekten als essenziell erwiesen.

Wir teilen diese Empfehlungen, damit auch andere von unseren Erkenntnissen aus Testen, Anwendung und Implementierung profitieren können.

In Data Vault

Aufteilung einer Satellite-Entität basierend auf den Quelldaten

Satellite split by source system

Aufteilung einer Satellite-Entität

Kriterien für das Satellite-Splitting spielen eine entscheidende Rolle für die Struktur eines Satelliten. Daher wird davon abgeraten, sämtliche beschreibenden Daten zu einem Business Key in einer einzigen Satellite-Struktur zu speichern. Stattdessen sollten Rohdaten vorzugsweise nach bestimmten Kriterien aufgeteilt werden.

In this article:

 

Kriterien für das Aufteilen eines Satelliten

Im Allgemeinen haben wir die folgenden Arten von Satellite-Splits definiert:

  1. Aufteilung nach Quellsystem
  2. Aufteilung nach Änderungsrate

Darüber hinaus haben wir zwei weitere Arten von Splits definiert:

  1. Aufteilung nach Sicherheits- und Datenschutzstufe
  2. Fachlich getriebene Aufteilung (Business-driven Split)

Eine Aufteilung des Satelliten nach Quellsystem wird dringend empfohlen, um zwei wesentliche Probleme beim Laden der Daten in das Enterprise Data Warehouse zu vermeiden: Wenn erstens zwei verschiedene Quellsysteme mit unterschiedlichen relationalen Strukturen in dieselbe Satellite-Entität geladen werden sollen, ist möglicherweise eine Transformation der Struktur erforderlich. Eine solche strukturelle Transformation erfordert jedoch früher oder später Geschäftslogik (Business Logic). Diese sollte auf die Information-Delivery-Schicht verschoben werden, um vollständig revisionssichere Umgebungen sowie die Anwendung mehrerer Geschäftsperspektiven zu unterstützen. Continue Reading

In Lösungen

Data-Lake-Effizienz: Strukturelle Lösungen

Data Lake architecture

Data-Lake-Struktur – Lösung

Die Organisation von Daten innerhalb eines Data Lakes beeinflusst deren nachgelagerte Verfügbarkeit maßgeblich. Während das Auslagern (Offloading) von Daten in den Data Lake meist unkompliziert ist, liegt die eigentliche Herausforderung in der effizienten Abfrage dieser Daten. Eine hohe Effizienz beim Datenabruf ist entscheidend für Aufgaben wie das inkrementelle oder initiale Laden des Enterprise Data Warehouse (EDW) sowie für Data Scientists, die eigenständige Analysen durchführen. In der Praxis steht und fällt der einfache Zugriff auf nachgelagerte Daten mit ihrer Strukturierung im Data Lake. Eine durchdachte Organisation sorgt für reibungslose Abrufprozesse und unterstützt sowohl EDW-Ladevorgänge als auch die Abfrageanforderungen der Data Scientists optimal.

ACCESS THE SOLUTION
In einer hybriden Data-Warehouse-Architektur, wie sie in der Data-Vault-2.0-Bootcamp-Schulung vermittelt wird, dient ein Data Lake als Ersatz für eine relationale Staging Area. Um das Potenzial dieser Architektur voll auszuschöpfen, sollte der Data Lake so strukturiert sein, dass er einen effizienten Zugriff im Rahmen eines Persistent-Staging-Area-Musters sowie eine verbesserte Datenvirtualisierung ermöglicht.

Continue Reading

In Data Vault, Fortgeschrittene

Data Vault Use Cases jenseits des klassischen Reportings – Teil 1

Data Cleansing with Data Vault 2.0

Enterprise Data Warehouses mit Data Vault 2.0

Während Enterprise Data Warehouses (EDWs) traditionell für Reporting und Dashboarding eingesetzt werden, liegt ihr wahres Potenzial in Verbindung mit Data Vault weit jenseits dieser Basisanwendungen. Data Vault 2.0 bietet eine beispiellose Flexibilität und Skalierbarkeit, die es Organisationen ermöglicht, neue Use Cases wie Data Cleansing, die Automatisierung operativer Prozesse und Predictive Analytics erfolgreich umzusetzen. Dieser Artikel untersucht, wie Data Vault 2.0 Unternehmen in die Lage versetzt, zentralisierte Data-Cleansing-Regeln anzuwenden, die Datenqualität direkt an der Quelle zu verbessern und ein Total Quality Management (TQM) zu etablieren. Durch die Nutzung des vollen Potenzials ihrer EDW-Systeme können Organisationen weit über einfache Analysen hinausgehen und nachhaltige, agile sowie wirkungsvolle Datenstrategien entwickeln.

Mit Data Vault 2.0 über das Standard-Reporting hinausgehen

Reporting und Dashboarding sind in der heutigen Geschäftswelt der Standard, um KPIs und andere wichtige Kennzahlen zu ermitteln. Entsprechend wurden Enterprise Data Warehouses primär zur Unterstützung dieser Reporting-Prozesse konzipiert. Angesichts der wachsenden Datenmenge und -vielfalt steigt jedoch der Bedarf an Methoden, die diese Daten so nutzen, dass sie einen echten geschäftlichen Mehrwert generieren. Data Vault 2.0 bietet hierfür ein breites Spektrum an Ansätzen, um fundierte Entscheidungen jenseits des Standard-Reportings zu unterstützen und zukunftsgerichtete, geschäftskritische Erkenntnisse zu liefern. Begleiten Sie uns auf diesem Weg und erfahren Sie, wie Sie das volle Potenzial Ihrer Daten ausschöpfen können.

Watch webinar recording

In this article:

Flexibilität und Skalierbarkeit

Einfach ausgedrückt führt ein Enterprise Data Warehouse (EDW) Daten aus internen sowie externen Datenquellen zusammen, um sie für Reporting- und Dashboarding-Zwecke bereitzustellen. Häufig werden diese Daten analytischen Transformationen unterzogen, um Berichte und Dashboards aussagekräftiger und wertvoller zu gestalten. Dennoch übersehen viele Organisationen beim Aufbau eines Data Warehouses weitere wertvolle Use Cases. Tatsache ist, dass EDWs ein enormes ungenutztes Potenzial bieten, das weit über das bloße Reporting historischer Daten hinausgeht. Um diese Möglichkeiten agil zu erschließen, bringt Data Vault ein Höchstmaß an Flexibilität und Skalierbarkeit mit.

Data Vault Use Cases

Zu Beginn wird ein Data Warehouse oft nur dazu genutzt, Daten zu sammeln und für Reporting- und Dashboarding-Zwecke aufzubereiten. Wird das EDW jedoch auf diese grundlegenden Use Cases beschränkt, bleibt ein Großteil des eigentlichen Datenwerts ungenutzt.

Dabei lässt sich über ein Data Warehouse eine Vielzahl innovativer Use Cases realisieren. Dazu gehören die Optimierung und Automatisierung operativer Prozesse, vorausschauende Analysen, das Zurückspielen von Daten in operative Systeme oder das Auslösen von Ereignissen außerhalb des Data Warehouses – um nur einige der neuen Möglichkeiten zu nennen.

Continue Reading

In Data Warehouse

Was Sie bei Namenskonventionen im Data Warehousing beachten sollten – Teil 1

Naming conventions - Letter cases

Namenskonventionen im Data Warehousing

Eine der ersten und wichtigsten Entscheidungen bei der Data-Vault-Entwicklung betrifft die Definition von Namenskonventionen für Datenbankobjekte. Als wesentlicher Bestandteil der Standardisierung sind diese Konventionen zwingend erforderlich, um ein gut strukturiertes und konsistentes Data-Vault-Modell aufrechtzuerhalten. Angemessene Namenskonventionen erhöhen die Benutzerfreundlichkeit des Data Warehouses erheblich, nicht nur für Entwickler, sondern auch für Power-User bei der Datenexploration.

In diesem Artikel stellen wir Ihnen die wichtigsten Überlegungen aus unserem Standardprozess zur Definition von Namenskonventionen vor.

In this article:

Dokumentation von Namenskonventionen

Es ist eine Sache, die Namenskonventionen für die Entwicklung Ihres Data Warehouses einfach nur zu definieren. Eine ganz andere Herausforderung ist es jedoch, die nötige Konsistenz zu etablieren, damit diese Konventionen auch tatsächlich zu gelebten Standards werden. Daher gehört es zu den Best Practices, eine klare Richtlinie für die Benennung von Data-Warehouse-Objekten zu dokumentieren. In den folgenden Abschnitten erörtern wir verschiedene Aspekte, die Sie bei der Definition von Namenskonventionen für eine Data-Warehouse-Lösung berücksichtigen sollten.

Namenskonventionen: Groß- und Kleinschreibung

Wenn es um die Groß- und Kleinschreibung von Namen geht, gibt es verschiedene Optionen: durchgehende Großschreibung, durchgehende Kleinschreibung, Camel Case und Pascal Case. Auch wenn die Unterschiede gering erscheinen mögen, hat jede Option ihre eigenen Vor- und Nachteile hinsichtlich der Lesbarkeit und der Schnelligkeit beim Tippen.

Letztendlich hängt die Entscheidung für eine bestimmte Schreibweise vom verwendeten Datenbankmanagementsystem ab. Einige Systeme wie PostgreSQL unterstützen case-sensitive Objektnamen, was bei Abweichungen die Verwendung von Anführungszeichen erforderlich macht. Daher bevorzugen PostgreSQL-Nutzer standardmäßig oft die Kleinschreibung, da kleingeschriebene Objektnamen den zu schreibenden Code reduzieren und gleichzeitig die Benutzerfreundlichkeit bei Ad-hoc-Abfragen durch Power-User verbessern. Dennoch ist es zwingend erforderlich, eine einheitliche Groß- und Kleinschreibung sowohl für Entitäts- als auch für Spaltennamen beizubehalten.

Naming conventions - Letter cases
Figure 1: Naming Convention - Letter Case

Namenskonventionen: Verwendung von Unterstrichen „_“ und Bindestrichen „-“

Zur Verbesserung der Lesbarkeit sind Worttrenner wie Unterstriche „_“ oder, je nach Anwendungsfall, Bindestriche „-“ wünschenswert. Es ist jedoch wichtig zu bedenken, dass Bindestriche in vielen Systemen als Minuszeichen interpretiert werden. Dennoch werden Bindestriche häufig in XML- oder JSON-Datenformaten verwendet. Sie lassen sich jedoch leicht durch Unterstriche ersetzen, falls diese als Standard-Trennzeichen definiert sind.

Namenskonventionen: Abkürzungen und Akronyme

Einige Systeme erzwingen Zeichenbegrenzungen für Objektnamen. So erlauben beispielsweise Oracle 12.1 und ältere Versionen nur eine maximale Länge von 30 Bytes für Objektnamen. Daher bieten sich Abkürzungen und Akronyme bei der Objektbenennung an, auch wenn diese leicht zu Missverständnissen führen können. Um dem entgegenzuwirken, empfiehlt es sich, ein Dokument mit einer Liste aller verwendeten Abkürzungen und deren genauer Bedeutung zu erstellen. Um jedoch potenzielle Verwirrung zu vermeiden, sollten Sie den Einsatz von Abkürzungen und Akronymen auf ein Minimum beschränken.

In logischen Modellen sollten Objektnamen so selbsterklärend wie möglich sein. Das bedeutet, dass die meisten Wörter vollständig ausgeschrieben werden sollten – mit Ausnahme etablierter Abkürzungen wie „dept“ für „department“ oder „org“ für „organization“. In physischen Modellen hingegen werden typischerweise Abkürzungen und Akronyme genutzt, um die Objektnamen kurz zu halten.

Namenskonventionen: Singular- vs. Plural-Objektnamen

Es ist gängige Praxis, Substantive oder Nominalphrasen in ihrer Singularform als Objektnamen zu verwenden. So lässt sich vermeiden, dass man sich mit unregelmäßigen englischen Pluralformen (z. B. man/men, person/people) auseinandersetzen muss, was das Datenmodell unnötig verkomplizieren würde.

Namenskonventionen: Präfix vs. Suffix

Ob Objekte mit Präfixen oder Suffixen benannt werden, ist für die Entwicklung von untergeordneter Bedeutung. Dennoch bevorzugen wir intern bei Scalefree Tabellennamen mit Suffixen wie „customer_h“ und „transaction_l“ anstelle von Präfixen. Der Vorteil dieser Methode: Da die meisten Datenbank-Tools Tabellen alphabetisch sortieren, werden alle Tabellen, die sich auf dasselbe Geschäftsobjekt beziehen, automatisch gruppiert. Beispielsweise werden alle Hubs, Satelliten und Links für Kontakte, deren Namen mit „contact_…“ beginnen, im Datenbank-Browser direkt untereinander angezeigt. Dies erleichtert die Datenexploration für Power-User und Entwickler erheblich.

Naming conventions - prefix
Figure 2: Naming Convention - Prefix

Dennoch können Präfixe in bestimmten Fällen sinnvoll sein. Beispielsweise hilft die Verwendung von Präfixen bei den Schema-Namen der verschiedenen Layer dabei, diese im Datenbank-Browser übersichtlich zu gruppieren.

Naming conventions - Schema
Figure 3: Naming Convention - Schemas

Fazit

Namenskonventionen sind zu einem gewissen Grad eine Frage der persönlichen Vorliebe und der internen Richtlinien. Unabhängig davon gilt: Je systematischer und konsistenter die Namenskonventionen definiert sind, desto größer ist der Nutzen bei der Entwicklung und Implementierung Ihrer Data-Vault-Lösung. Um dies sicherzustellen, empfehlen wir Data-Vault-Entwicklungsteams, eine einfache SQL-Funktion zu implementieren, die die gesamte Datenbank automatisch auf Abweichungen von den Namenskonventionen überprüft. So wird die Einhaltung der Standards kontinuierlich gewährleistet.

Sind Sie daran interessiert, wie wir bei Scalefree Namenskonventionen standardisieren? In einem der nächsten Artikel werden wir konkrete Vorschläge für Namenskonventionen vorstellen, die sich sowohl bei unseren Kunden als auch in unserem eigenen Team in der Praxis bewährt haben.

Lassen Sie uns in den Kommentaren diskutieren: Wie setzen Sie Namenskonventionen in Ihrer Data-Vault-Entwicklung um? Welchen Standards folgen Sie?

In Data Vault

Alternative zur Driving-Key-Implementierung in Data Vault

Driving Key Source Table

Alternative zum Driving-Key

Es gibt einen Spezialfall, in dem sich ein Teil der in einem Link gespeicherten Hub-Referenzen ändern kann, ohne eine andere Beziehung zu beschreiben. Dies hat erhebliche Auswirkungen auf die Link-Satelliten. Darüber hinaus haben wir bereits im Jahr 2017 die Link-Struktur anhand eines Beispiels für ein Data-Vault-Modell in der Bankenbranche vorgestellt. Wir haben gezeigt, wie das Modell aussieht, wenn ein Link entweder eine Beziehung oder eine Transaktion zwischen zwei Business-Objekten darstellt. Ein Link kann auch mehr als zwei Hubs miteinander verbinden. Was ist die Alternative zur Driving-Key-Implementierung in Data Vault 2.0?

In this article:

Der Driving-Key

Eine Beziehung oder Transaktion wird in einem Quellsystem häufig durch eine Kombination von Business-Keys identifiziert. In Data Vault 2.0 wird dies als normaler Link modelliert, der mehrere Hubs verbindet, die jeweils einen Business-Key enthalten. Ein Link enthält auch seinen eigenen Hash-Key, der über die Kombination aller Business-Keys der Parent-Hubs berechnet wird. Wenn der Link also vier Hubs verbindet und sich ein Business-Key ändert, weist der neue Datensatz einen neuen Link-Hash-Key auf. Ein Problem entsteht, wenn zwar vier Business-Keys die Beziehung beschreiben, aber nur drei davon diese eindeutig identifizieren. Wir können das Business-Objekt nicht allein anhand des Hash-Keys des Links identifizieren. Dies ist zwar kein Modellierungsfehler, allerdings müssen wir bei der Datenabfrage den korrekten Datensatz im zugehörigen Satelliten identifizieren. In Data Vault 2.0 wird dies als Driving-Key bezeichnet. Es handelt sich dabei um einen konsistenten Schlüssel innerhalb der Beziehung, der im Quellsystem oft dem Primärschlüssel entspricht.

Die folgenden Tabellen veranschaulichen die Beziehung zwischen einem Mitarbeiter und einer Abteilung aus einem Quellsystem.

Driving Key Source Table
Table 1: employee-department relationship

Das folgende Data-Vault-Modell lässt sich aus dieser Quellstruktur ableiten.

Driving Key in a Data Vault Model
Figure 1: Data Vault model

Die Link-Tabelle „Empl_Dep“ wird aus der Tabelle „Employee“ im Quellsystem abgeleitet. Der Driving-Key in diesem Beispiel ist die Employee_Number, da sie der Primärschlüssel in der Quelltabelle ist und ein Mitarbeiter zur gleichen Zeit nur in einer Abteilung arbeiten kann. Das bedeutet, dass der tatsächliche Driving-Key im Satelliten des Mitarbeiters „lebt“. Wechselt die Abteilung eines Mitarbeiters, entsteht kein zusätzlicher Datensatz in der Satellitentabelle des Mitarbeiters, sondern ein neuer in der Link-Tabelle, was völlig legitim ist.

Driving Key in a Data Vault Model
Table 2: link data

Um das aktuellste Delta zu ermitteln, müssen Sie dieses aus der Link-Tabelle abfragen und nach dem Driving-Key gruppieren.

Zusammenfassend lässt sich sagen, dass Sie immer einen neuen Link-Hash-Key erhalten, wenn sich ein Business-Key in einer Beziehung ändert. Die Herausforderung besteht darin, den Driving-Key zu identifizieren. Hierbei handelt es sich um einen eindeutigen Business-Key (oder eine Kombination von Business-Keys) für die Beziehung zwischen den verbundenen Hubs. Manchmal müssen Sie ein zusätzliches Attribut hinzufügen, um einen eindeutigen Identifikator zu erhalten.

Beides stellt ein Problem für Power-User mit Zugriff auf das Data-Vault-Modell dar. Ohne klare Namenskonventionen besteht das Risiko, dass eine GROUP-BY-Anweisung auf mehr Attribute als nur den Driving-Key angewendet wird. Dies würde zu unerwarteten und fehlerhaften Aggregatwerten führen, obwohl die Daten selbst korrekt modelliert sind

Beim Umgang mit Beziehungsdaten gibt es eine bessere Lösung als den Driving-Key: Wir bevorzugen es in der Regel, solche Daten als Non-Historized-Link zu modellieren und technische Gegenbuchungen (Counter-Transactions) in die Daten einzufügen, sobald sich eine Hub-Referenz ändert.

Im Falle eines geänderten Datensatzes in der Quelle fügen wir zwei Datensätze in den Non-Historized-Link ein: einen für die neue Version des geänderten Quell-Datensatzes und einen für die alte Version, die noch im Target existiert, aber nun ausgeglichen werden muss – den technischen Counter-Datensatz. Um die Datensätze aus der Quelle von den Counter-Transactions zu unterscheiden, wird eine neue Spalte eingeführt, die oft als „Counter“ bezeichnet wird.

Der Standardwert für dieses Counter-Attribut ist 1 für Datensätze aus der Quelle und -1 für die technischen Counter-Transactions. Wichtig: Wir führen keine UPDATE-Anweisungen aus, sondern fügen stattdessen nur neue Datensätze hinzu. Wenn Sie die Measures aus dem Link abfragen, multiplizieren Sie diese einfach mit dem Counter-Wert.

Driving Key in a Data Vault Model
Table 3: LinkConnection with counter attribute

Tabelle 3 zeigt einen Link mit einem Counter-Attribut. Wenn sich ein Datensatz im Quellsystem ändert, wird er mit dem ursprünglichen Wert und einem Counter-Wert von -1 in die Link-Tabelle des Data-Warehouses eingefügt. Für den geänderten Wert gibt es einen neuen Link-Hash-Key, der ebenfalls über das beschreibende Attribut „Salary“ berechnet wird. Der Counter-Wert des neuen Datensatzes ist 1.

Fazit

Da die Identifizierung des Driving-Keys einer Beziehung in manchen Situationen ein Problem darstellen kann, können Sie eine alternative Lösung nutzen, um den Driving-Key zu vermeiden. Alle Änderungen und Löschungen werden mithilfe eines Counter-Attributs in der Non-Historized-Link-Tabelle nachverfolgt. Diese speichert auch die beschreibenden Attribute, und der Link-Hash-Key wird über alle Attribute berechnet.

In Data Vault

Wie Sie Insert-Only in Data Vault 2.0 implementieren

End dating satellites in Data Vault 2.0 for insert only architecture

Insert-Only in Data Vault 2.0

Eine kompetente Modellierung ist wichtig, um das volle Potenzial von Data Vault 2.0 auszuschöpfen. Um im Hinblick auf Skalierbarkeit und Performance das Beste aus dem System herauszuholen, muss es zudem auf einer Architektur aufbauen, die vollständig auf Insert-Only ausgelegt ist. Beim Laden in das Data Vault können sämtliche Update-Operationen eliminiert und die Ladeprozesse erheblich vereinfacht werden.

In this article:

Die gängige Implementierung in Data Vault 2.0

In den gängigen Lademustern gibt es in Data Vault 2.0 zwei wichtige technische Zeitstempel. Der erste ist der Load Date Timestamp (LDTS). Dieser Zeitstempel stellt kein Business-Datum (Business Date) dar, das aus dem Quellsystem stammt. Stattdessen gibt er Auskunft darüber, wann die Daten zum ersten Mal in das Data Warehouse geladen wurden, in der Regel in die Staging Area.

Daher unterscheidet er sich grundlegend von den verschiedenen Business-Daten, die aus den Quellsystemen stammen und eine geschäftliche Bedeutung haben. Aus diesem Grund muss er für einen gesamten Batch-Ladeprozess generiert werden. Business-Daten, wie beispielsweise Gültigkeitsdaten, werden in Effectivity-Satelliten gespeichert, die meist mit Link-Entities verbunden sind. Sie liefern Informationen über die Beziehungen zwischen Geschäftsobjekten sowie das jeweilige Anfangs- und Enddatum.

Der zweite technische Zeitstempel ist der Load End Date Timestamp (LEDTS). Wie der LDTS ist auch der LEDTS systemgeneriert und tritt nur in Satellite-Entities auf. Da diese Satelliten delta-basiert sind, gibt es immer einen Datensatz, der das aktuellste Delta darstellt. Der Wert des LEDTS bei diesen Datensätzen ist üblicherweise „9999-12-31“ (End of Time) oder NULL. Die folgende Abbildung zeigt den gesamten End-Dating-Prozess, der mit der Verwendung des LEDTS-Attributs einhergeht. Dieser wird nach dem Laden des Satelliten ausgeführt (nicht währenddessen):

End dating satellites in Data Vault 2.0 for insert only architecture
Figure 1: End dating process for satellites

Die Abbildung verdeutlicht, dass wir den Satelliten mit dem neuen LEDTS-Wert aktualisieren müssen, was zulasten der Performance geht. Wie anfangs erwähnt, möchten wir die LEDTS-Updates eliminieren, um mit einer 100-prozentigen Insert-Only-Architektur in Data Vault 2.0 eine höhere Performance zu erzielen.

An dieser Stelle stellt sich die typische Frage, wie das aktuellste Delta in einem Satelliten abgefragt werden kann, wenn wir keinen LEDTS mehr haben. Mittels max(LDTS)? Sicherlich nicht.

Der Vorteil von PIT-Tabellen in Data Vault 2.0

Die Antwort liegt in der Verwendung von Fensterfunktionen (Window Functions) zum Laden Ihrer Point-in-Time-Tabellen (PIT-Tabellen). Wir haben das Thema PIT-Tabellen bereits mit einem Beispiel aus der Versicherungsbranche in unserem Newsletter vom Oktober 2018 behandelt. 2018. Der Zweck von PIT-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins eliminiert und aus Performancegründen Inner Joins mit Equi-Join-Bedingungen ermöglicht werden. Wir empfehlen dringend, eine PIT-Tabelle als performantere Alternative zum LEDTS aufzubauen. Die PIT-Tabelle wird mithilfe von Fensterfunktionen erstellt, um das aktuellste Delta im Satelliten zu finden. Sobald sie mit Snapshots der aktuellen Daten erstellt wurde, müssen wir den LDTS nicht mehr mit BETWEEN-Bedingungen abfragen. Die zeitliche Historie wird in Form von Snapshots gespeichert und kann mit Equi-Join-Bedingungen auf dem Hash-Key und dem LDTS zu den zugehörigen Satelliten abgefragt werden. Da PIT-Tabellen kontinuierlich wachsen, wird empfohlen, Partitionen auf dem Snapshot-Datum zu erstellen. Schließlich können die (visualisierten) Information-Mart-Dimensionen ganz einfach direkt aus der PIT-Tabelle und den zugehörigen Satelliten abgefragt werden.

Durch die Verwendung von Fensterfunktionen auf dem Hash-Key (Partition) und dem LDTS (Order) können Sie das aktuellste Delta identifizieren, das dynamisch berechnet wird. Es gibt verschiedene Fensterfunktionen, die zur Ermittlung des aktuellsten Deltas verwendet werden können. Die folgende Tabelle zeigt einige Beispiele für diese Fensterfunktionen.

Window function in Data Vault 2.0 for insert only architecture
Table 1: Examples of window functions

Ein Grund für die Existenz des LEDTS in Data Vault ist, dass viele Datenbanken im frühen 21. Jahrhundert noch keine Fensterfunktionen unterstützten oder dafür nicht schnell genug waren.

Wie bereits im Newsletter vom Oktober 2018 erwähnt, besteht der Zweck von PIT-Tabellen darin, Inner Joins mit Equi-Join-Bedingungen zu ermöglichen. Sie sind jedoch auch der Schlüssel zu einer reinen Insert-Only-Implementierung von Data Vault 2.0, wodurch weitaus effizientere Ladeprozesse ermöglicht werden.

Fazit

Die Implementierung einer Insert-Only-Architektur in Data Vault 2.0 verbessert die Skalierbarkeit und Performance, indem Update-Operationen während des Datenladens eliminiert werden. Dieser Ansatz vereinfacht den Ladeprozess und stellt sicher, dass alle Datenänderungen als neue Datensätze erfasst werden, wodurch die historische Genauigkeit gewahrt bleibt. Durch die Nutzung von Point-in-Time-Tabellen (PIT-Tabellen) können Unternehmen die aktuellsten Daten effizient abfragen, ohne auf End-Dating-Techniken angewiesen zu sein, wodurch der Datenabruf und die Datenanalyse weiter optimiert werden.

In Data Vault

Wie Sie Point-in-Time-Tabellen in der Versicherungsbranche nutzen

Introduction to point in time tables

Point-in-Time-Tabellen

Point-in-Time-Tabellen (PIT-Tabellen) sind nützlich, wenn Sie Daten aus dem Raw Vault abfragen, bei denen mehrere Satellites an einen Hub oder Link angebunden sind:

Introduction to point in time tables
Figure 1: Data Vault model including PIT (logical)

In this article:

Über Point-in-Time-Tabellen

Im obigen Beispiel sind mehrere Satellites für den Hub „Customer“ und den Link im Diagramm dargestellt. Dies ist eine sehr häufige Situation bei Data-Warehouse-Lösungen, da sie Daten aus mehreren Quellsystemen integrieren. Diese Situation erhöht jedoch die Komplexität bei der Abfrage von Daten aus dem Raw Data Vault. Das Problem entsteht, weil Änderungen an den in den Quellsystemen gespeicherten Business-Objekten nicht gleichzeitig erfolgen. Stattdessen wird ein Business-Objekt, wie z. B. ein Kunde (eine versicherte Person), zu einem bestimmten Zeitpunkt in einem der vielen Quellsysteme aktualisiert, zu einem anderen Zeitpunkt in einem anderen System usw. Beachten Sie, dass die Point-in-Time-Tabelle (PIT) bereits an den Hub angehängt ist, wie durch das Band dargestellt.

Änderungen gingen zu unterschiedlichen Zeiten ein, die nicht miteinander in Beziehung standen. Die meisten Aktualisierungen wurden beim Abschluss einer Versicherung vorgenommen, betrafen jedoch nicht alle operativen Systeme gleichzeitig. Folglich wirkte sich eine Änderung nicht auf alle Satellites aus. Stattdessen betraf sie nur denjenigen Satellite, der die Änderung abbilden sollte (was ein Vorteil ist).

Beim Erstellen eines Data Marts aus diesen Rohdaten wird die Abfrage von Kundendaten zu einem bestimmten Stichtag kompliziert: Die Abfrage muss die Kundendaten so zurückgeben, wie sie gemäß dem Delta-Prozess des Data Warehouses am ausgewählten Datum aktiv waren. Um dieses Ziel zu erreichen, sind Outer-Join-Abfragen mit komplexer Zeitbereichslogik erforderlich. Bei mehr als drei Satellites an einem Hub oder Link wird dies kompliziert und langsam. Der bessere Ansatz ist die Verwendung von Equi-Join-Abfragen, um die Daten aus dem Raw Data Vault abzurufen. Um dies zu erreichen, wird in der Data-Vault-2.0-Modellierung ein spezieller Entitätstyp verwendet: Point-in-Time-Tabellen (PIT). Diese Entität wird immer dann in ein Data-Vault-2.0-Modell integriert, wenn die Abfrageperformance für einen bestimmten Hub oder Link und die zugehörigen Satellites zu gering ist.

Point in time tables
Figure 2: PIT table structure

] Da die Daten in einer PIT-Tabelle systemgeneriert sind und nicht aus einem Quellsystem stammen, müssen sie nicht auditiert werden und befinden sich nicht im Raw Vault. Daher kann ihre Struktur so angepasst werden, dass sie berechnete Spalten (Computed Columns) enthält.

Point-in-Time-Tabellen dienen zwei Zwecken:

Vereinfachung der Kombination mehrerer Deltas zu verschiedenen „Points in Time“

Eine PIT-Tabelle erstellt Snapshots von Daten für Stichtage, die von den nachgelagerten Datenkonsumenten definiert wurden. Beispielsweise ist es üblich, täglich den aktuellen Zustand der Daten bereitzustellen. Um diesen Anforderungen gerecht zu werden, enthält die PIT-Tabelle das Datum und die Uhrzeit des Snapshots in Kombination mit dem Business-Key als eindeutigen Schlüssel der Entität (ein Hash-Key, der diese beiden Attribute enthält und in Abbildung 2 als „CustomerKey“ bezeichnet wird). Für jede dieser Kombinationen enthält die PIT-Tabelle die Load-Dates und die entsprechenden Hash-Keys aus jedem Satellite, die am besten mit dem Snapshot-Datum übereinstimmen.

Reduzierung der Join-Komplexität aus Performancegründen mit Point-in-Time-Tabellen

Die Point-in-Time-Tabelle fungiert wie ein von der Abfrage verwendeter Index und liefert Informationen über die aktiven Satellite-Einträge pro Snapshot-Datum. Das Ziel besteht darin, so viel Join-Logik wie möglich zu materialisieren, um am Ende einen Inner Join mit ausschließlichen Equi-Join-Bedingungen zu erhalten. Dieser Join-Typ ist auf den meisten (wenn nicht allen) relationalen Datenbankservern die performanteste Join-Variante. Um die Performance der PIT-Tabelle zu maximieren und gleichzeitig den Speicherbedarf gering zu halten, ist in jedem von der Point-in-Time-Tabelle referenzierten Satellite nur ein einziger Ghost-Record erforderlich. Dieser Ghost-Record wird verwendet, wenn im referenzierten Satellite kein Datensatz aktiv ist, und dient als Fallback für unbekannte oder NULL-Werte. Durch die Verwendung des Ghost-Records können NULL-Prüfungen im Allgemeinen vermieden werden, da die Join-Bedingung immer auf einen aktiven Datensatz in der Satellite-Tabelle verweist: entweder auf einen tatsächlichen Datensatz, der zum angegebenen Snapshot-Datum aktiv ist, oder auf den Ghost-Record.

Example of Point in time tables
Table 1: Example of PIT table

Die obige Tabelle (Tabelle 1) zeigt eine versicherte Person mit historischen Datenständen vom 8. und 9. Oktober 2018. Am 8. Oktober gab es für diesen Kunden keinen Datensatz im Rechtsschutzversicherungs-Satellite. Aus diesem Grund sind sowohl der Hash-Key als auch der Load-Date-Zeitstempel NULL. Für eine bessere Abfrageperformance verweisen diese NULL-Werte auf den Ghost-Record in der zugehörigen Satellite-Tabelle, um die Suche nach einem nicht existierenden Datensatz zu vermeiden.

Wenn Kundendaten nur für einen bestimmten Geschäftsbereich gelöscht werden müssen und personenbezogene Daten (PII) als Business-Key dienen, müssen lediglich der Link-Eintrag und die beschreibenden Attribute im spezifischen Satellite gelöscht werden. Der Aktivitätsverlauf bleibt weiterhin verfügbar, kann für analytische Zwecke genutzt werden und lässt sich nicht mehr auf den konkreten Kunden zurückführen. Der zusätzliche Vorteil dieses „Business Splits“ zeigt sich, wenn beim Löschen von Kundendaten nur ein einzelner Geschäftsbereich betroffen ist – beispielsweise wenn die Geschäftsbereiche zu verschiedenen Tochtergesellschaften gehören und nur die Kfz-Versicherungsdaten gelöscht werden müssen. Denken Sie außerdem daran, dass das Löschen des reinen Business-Keys (unter Beibehaltung des Hash-Keys) nicht zur DSGVO-Konformität führt (und ohnehin nicht dem Data-Vault-2.0-Standard entspricht, da der Business-Key in Link-Tabellen verwendet wird). Der Hash-Key in Data Vault 2.0 wird nicht zur Verschlüsselung von Daten verwendet, sondern dient reinen Performancegründen. Der Schlüssel in den Links und den geschäftsorientierten Hubs, von denen hier die Rede ist, kann nicht zurückgerechnet werden, da es sich um einen reinen Surrogatschlüssel handelt. Sobald ein Kunde die vollständige Löschung seiner Daten wünscht, da er oder sie kein Kunde mehr in einem Ihrer Geschäftsbereiche ist, löschen Sie den Datensatz auch aus dem Haupt-Hub.

Andernfalls können Sie Ihre Daten nach dem Löschen der personenbezogenen Daten (PII) sofern kein zusätzlicher künstlicher Schlüssel für den Kunden existiert nicht mehr mit einem Objekt (einem Ankerpunkt) verknüpfen, was sie in vielen Fällen unbrauchbar macht.

Fazit

Der Zweck von Point-in-Time-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins eliminiert und Inner Joins mit Equi-Join-Bedingungen (für die beste Performance) ermöglicht werden. Darüber hinaus verbessern Point-in-Time-Tabellen die Partitionierung und ermöglichen eine vollständige Skalierbarkeit von Star-Schemas (die vollständig virtualisiert sein sollten) auf dem Data Vault. Zudem müssen Endanwender nicht alle Satellite-Tabellen miteinander verknüpfen, sondern verbinden nur eine einzige Tabelle mit einem Business-Objekt, was die Komplexität von Ad-hoc-Abfragen erheblich reduziert.

In Datenarchitektur

Hybride Architektur in Data Vault 2.0

Data Vault 2.0 Hybrid Architecture

Hybride Architektur in Data Vault 2.0

Business-Anwender erwarten von ihren Data-Warehouse-Systemen, dass sie immer mehr Daten hinsichtlich Vielfalt, Volumen und Geschwindigkeit laden und aufbereiten. Auch die Arbeitslast typischer Data-Warehouse-Umgebungen steigt immer weiter an, insbesondere wenn die erste Version des Warehouses bei den ersten Anwendern ein Erfolg war. Skalierbarkeit hat daher mehrere Dimensionen. Letzten Monat haben wir über Satellites gesprochen, die eine wichtige Rolle bei der Skalierbarkeit spielen. Nun erklären wir, wie Sie strukturierte und unstrukturierte Daten mit einer hybriden Architektur kombinieren.

In this article:

Logische Data-Vault-2.0-Architektur

Die Data-Vault-2.0-Architektur basiert auf drei Schichten: der Staging Area, die die Rohdaten aus den Quellsystemen sammelt, der Enterprise-Data-Warehouse-Schicht, die als Data-Vault-2.0-Modell aufgebaut ist, und der Information-Delivery-Schicht mit Information Marts als Star-Schemata und anderen Strukturen. Die Architektur unterstützt sowohl das Batch-Laden aus Quellsystemen als auch das Laden in Echtzeit über den Enterprise Service Bus (ESB) oder jede andere serviceorientierte Architektur (SOA).

Das folgende Diagramm zeigt die grundlegende logische Data-Vault-2.0-Architektur:

Data Vault 2.0 Architecture
Figure 1: Logical Data Vault 2.0 Architecture

In diesem Fall werden strukturierte Daten aus Quellsystemen zuerst in die Staging Area geladen, um die Systembelastung der operativen Quellsysteme zu minimieren. Anschließend werden sie unverändert in den Raw Data Vault geladen, der die Enterprise-Data-Warehouse-Schicht darstellt. Nachdem die Daten in dieses Data-Vault-Modell (bestehend aus Hubs, Links und Satellites) geladen wurden, werden im Business Vault Business-Regeln auf die Daten des Raw Data Vaults angewendet. Sobald die Business-Logik angewendet wurde, werden die Daten aus dem Raw Data Vault und dem Business Vault zusammengeführt und für die Information Delivery in den Information Marts in das Business-Modell umstrukturiert. Der Business-Anwender nutzt Dashboard- oder Reporting-Anwendungen, um auf die Informationen in den Information Marts zuzugreifen

Die Architektur ermöglicht die Implementierung der Business-Regeln im Business Vault durch eine Kombination verschiedener Technologien, wie beispielsweise SQL-basierte Virtualisierung (typischerweise über SQL-Views) und externe Tools wie Business-Rule-Management-Systeme (BRMS).

Es ist jedoch auch möglich, unstrukturierte NoSQL-Datenbanksysteme über eine hybride Architektur zu integrieren. Aufgrund der Plattformunabhängigkeit von Data Vault 2.0 kann NoSQL für jede Data-Warehouse-Schicht verwendet werden – einschließlich der Staging Area, der Enterprise-Data-Warehouse-Schicht und der Information-Delivery-Schicht. Daher kann die NoSQL-Datenbank als Staging Area genutzt werden, um Daten in die relationale Data-Vault-Schicht zu laden. Sie kann jedoch auch in beide Richtungen über einen gehashten Business Key in die Data-Vault-Schicht integriert werden. In diesem Fall handelt es sich um eine hybride Architekturlösung, bei der die Information Marts Daten aus beiden Umgebungen beziehen.

Hybride Architektur

Die Standard-Data-Vault-2.0-Architektur in Abbildung 1 konzentriert sich auf strukturierte Daten. Da immer mehr Unternehmensdaten semistrukturiert oder unstrukturiert vorliegen, ist es Best Practice für ein neues Enterprise Data Warehouse, eine hybride Architektur auf Basis eines Hadoop-Clusters zu verwenden, wie in der folgenden Abbildung dargestellt:

Data Vault 2.0 Hybrid Architecture
Figure 2: Hybrid Data Vault 2.0 Architecture

In dieser modifizierten hybriden Architektur wird die relationale Staging Area durch eine HDFS-basierte Staging Area ersetzt, die sowohl unstrukturierte als auch strukturierte Daten erfasst. Auch wenn die Erfassung strukturierter Daten im HDFS auf den ersten Blick wie ein zusätzlicher Overhead erscheint, verringert diese Strategie die Belastung der Quellsysteme, da sie sicherstellt, dass die Quelldaten unabhängig von strukturellen Änderungen stets extrahiert werden können. Die Daten werden dann mit Apache Drill, Hive External oder ähnlichen Technologien extrahiert.

Zudem ist es möglich, den Raw Data Vault und den Business Vault (die strukturierten Daten im Data-Vault-Modell) in Hive Internal zu speichern.

Fazit

Die Integration einer hybriden Architektur in Data Vault 2.0 ermöglicht es Unternehmen, sowohl strukturierte als auch unstrukturierte Daten durch die Nutzung von Plattformen wie Hadoop effektiv zu verwalten. Dieser Ansatz verbessert die Skalierbarkeit sowie Flexibilität und ermöglicht eine effiziente Datenverarbeitung und -speicherung. Indem traditionelle relationale Staging Areas durch HDFS-basierte Systeme ersetzt werden, können Unternehmen die Belastung der Quellsysteme reduzieren und eine nahtlose Datenextraktion gewährleisten.

In Datenmodellierung

Visual Data Vault: Link-Modellierung in der Bankenbranche

Visual Data Vault example for links

Visual Data Vault

Der folgende Artikel beschreibt die Darstellung von Links anhand eines praxisnahen Beispiels aus Visual Data Vault. Mit dem Aufkommen von Data Vault 2.0, das den Data Vault 1.0-Standard um Architektur– und Prozessdefinitionen erweitert, hat Dan Linstedt die in der Modellierung genutzten Symbole standardisiert. Auf Basis dieser standardisierten Symbole wurde die Modellierungssprache Visual Data Vault (VDV) entwickelt, die EDW-Architekten beim Aufbau von Data-Vault-Modellen unterstützt.

Als unsere Gründer ihr Buch schrieben, benötigten sie einen visuellen Ansatz, um die Konzepte von Data Vault verständlich zu modellieren. Zu diesem Zweck entwickelten sie eine grafische Modellierungssprache, die sich auf die logischen Aspekte von Data Vault konzentriert. Die passenden Microsoft-Visio-Schablonen und ein detailliertes Whitepaper stehen auf www.visualdatavault.com zum kostenlosen Download bereit.

In this article:

Links in Visual Data Vault

In einem früheren Beitrag haben wir bereits gezeigt, wie Hubs im Finanzbereich modelliert werden. In diesem Artikel erklären wir die Funktion von Standard-Links und wie die Modellierung speziell in der Bankenbranche funktioniert.

Links verbinden einzelne Hubs in einem Data-Vault-Modell und repräsentieren entweder Transaktionen oder Beziehungen zwischen Business-Objects. Im laufenden Geschäftsbetrieb sind Business-Objects stets miteinander verknüpft – kein Business-Object existiert völlig isoliert von anderen. Stattdessen werden sie durch die operativen Geschäftsprozesse miteinander verbunden, welche diese Objekte bei der Ausführung ihrer Aufgaben nutzen. Das folgende Diagramm veranschaulicht einen Link, der zwei Hubs miteinander verbindet (ein Standard-Link erfordert mindestens zwei Verbindungen):

Figure 1: A standard link connects two hubs

Der Link im obigen Beispiel referenziert zwei Hubs: Account und Customer. Die Verbindungslinie (der Pfeil) ist zu lesen als: „(Der Hub) Customer wird verwendet von (dem Link) Account to Customer“. Die zweite Referenz unterscheidet sich leicht, da der Name der Verbindung zwischen dem Account-Hub und dem Link durch die fachliche Rolle eines Kredit- oder Debitoren-Accounts überschrieben wird. Dies ist immer dann erforderlich, wenn das Modell eine präzisere fachliche Semantik benötigt oder wenn mehrere Verbindungen zum selben Hub bestehen. Die Hash-Keys jedes Hubs, die jedes Business-Object über ein berechnetes Attribut eindeutig identifizieren, werden unter Verwendung desselben Attributnamens in die Link-Entität repliziert.

Ein Link bildet n:m-Beziehungen (Many-to-Many) ab und bietet dadurch eine hohe Flexibilität: Änderungen an den Business-Rules erfordern kein aufwendiges Re-Engineering, und die Granularität wird durch die Anzahl der referenzierten Hubs klar ausgedrückt und transparent dokumentiert.

Link table example
Figure 2: Link table with its attributes

Der Link enthält alle Hash-Keys der zugehörigen Hubs (als logische Fremdschlüssel), ein Load Date (das den ersten Eingang der Beziehung im Data Warehouse dokumentiert), die Record Source der Daten sowie den Link-Hash-Key (als logischen Primärschlüssel). Letzterer wird aus den Business-Keys der Hubs berechnet – nicht aus den Hash-Keys, denn: Hashen Sie niemals einen Hash! Zudem folgt die Beladung einem reinen Insert-only-Muster.

Links erhöhen die Flexibilität des Data-Vault-Modells erheblich, da sich neue Links leicht hinzufügen und bestehende Beziehungstypen mühelos anpassen lassen. Dadurch verkürzt sich die Reaktionszeit auf geschäftliche Veränderungen spürbar. Um neue Funktionalitäten zu ergänzen, fügen Sie lediglich neue Hubs hinzu und verbinden diese über Links mit den bestehenden Strukturen. In der Regel wird dem Link ein Standard-Satellite angehängt, der die beschreibenden Daten der Beziehung enthält.

Eine weitere verbreitete Form ist der Non-Historized Link (auch als Transactional Link bekannt). Dieser speichert ausschließlich Transaktionsdaten, benötigt keinen Satellite und folgt strikt einem Insert-only-Lademuster. Weitere Details zum Mehrwert von NH-Links finden Sie in einem unserer früheren Beiträge aus diesem Jahr.

Fazit

Die Modellierungssprache Visual Data Vault bietet einen standardisierten und hocheffizienten Ansatz zur Abbildung komplexer Beziehungen und Transaktionen in der Bankenbranche. Durch die gezielte Verknüpfung von Business-Objects über Links entsteht eine klare, logische Struktur, die reale Geschäftsprozesse präzise abbildet. Diese Methodik steigert nicht nur die Transparenz von Datenmodellen, sondern vereinfacht auch das Datenmanagement sowie spätere Datenabfragen nachhaltig was sie zu einem unverzichtbaren Werkzeug für Enterprise Data Warehouse-Architekten macht.

In Datenmodellierung

Data-Vault-Modellierung: Visuelles Beispiel – Scalefree

Data Vault Modeling of a Hub

Visuelles Beispiel einer Data-Vault-Modellierung

Durch die Ergänzung von Architektur- und Prozessdefinitionen in Data Vault 2.0 hat Dan Linstedt die Data-Vault-Modellierung standardisiert.

Basierend auf diesen standardisierten Symbolen wurde die Visual-Data-Vault-Modellierungssprache entwickelt, die Enterprise-Data-Warehouse-Architekten zur Erstellung von Data-Vault-Modellen nutzen können.

Die Autoren des Buches „Building a Scalable Data Warehouse“, die auch die Gründer von Scalefree sind, benötigten einen visuellen Ansatz, um die Data-Vault-Konzepte im Buch darzustellen.

Zu diesem Zweck entwickelten sie die grafische Data-Vault-Modellierungssprache, die sich auf die logischen Aspekte von Data Vault konzentriert.

Die Microsoft-Visio-Stencils und ein detailliertes Whitepaper stehen auf www.visualdatavault.com zum kostenlosen Download zur Verfügung.

Hubs in Visual Data Vault

Business-Keys spielen in jedem Unternehmen eine wichtige Rolle, da Geschäftstransaktionen und Beziehungen zwischen Geschäftsobjekten auf sie verweisen.

Immer wenn ein Unternehmen Geschäftsobjekte identifiziert und nachverfolgt, kommen Business-Keys in allen Geschäftsprozessen zum Einsatz.

Dies ist einer der Gründe, warum Data Vault auf den Business-Keys basiert. In der Data-Vault-Modellierung werden Business-Keys in Hub-Entitäten gespeichert.

Die Herausforderung besteht darin, die Business-Keys zu identifizieren, die ein Geschäftsobjekt eindeutig repräsentieren. Das kann ein einzelner Business-Key sein, aber auch ein Composite-Key oder ein Smart-Key.

Die erste Abbildung zeigt einen Hub mit nur einem Business-Key-Attribut:

Data Vault Modeling of a Hub

Hier reicht das Attribut „Invoice Number“ aus, um die Rechnung zu identifizieren. Es ist kein weiteres Attribut erforderlich (wie beispielsweise das Rechnungsjahr).

In anderen Fällen ist es nicht so einfach, wie das folgende Diagramm zeigt:

Data Vault Modeling for a Hub

In diesem Data-Vault-Modellierungsfall wird der Buchhalter durch ein „Country Code“-Attribut (wie den ISO2-Code) und ein „Employee Number“-Attribut identifiziert.

Ein Attribut allein würde nicht ausreichen, um den Buchhalter zu identifizieren: Die „Employee Number“ an sich könnte sich länderübergreifend überschneiden und nur eine lokale Bedeutung haben (die „Employee Number“ 10006 könnte in mehreren Ländern verwendet werden und in jedem Land einen anderen Buchhalter identifizieren).

Daher wird der lokale Schlüssel um den „Country Code“ erweitert, um den Buchhalter eindeutig zu identifizieren. Bitte beachten Sie, dass der „Country Code“ in den Quelldaten enthalten sein muss, damit dies ein gültiges Modell in Data Vault ist (letztendlich modellieren wir Quelldaten im Raw Data Vault, nicht das Zielmodell des Fachbereichs).

Ein weiteres Beispiel erweitert dieses Konzept zu einem sogenannten Smart-Key:

Data Vault Modeling of a Hub

Hier besteht die IBAN, die zur internationalen Identifizierung von Bankkonten dient, aus vier physischen Elementen:

  1. Country Code
  2. Checking number
  3. Account number
  4. Bank Identifier code

Um einen Smart-Key zu modellieren (einen Schlüssel, der aus mehreren Teilen oder Schlüsseln besteht), fügen Sie dem Hub einen Smart-Key und anschließend Business-Keys hinzu, um die einzelnen Segmente des Smart-Keys zu identifizieren.

Wie Sie in der obigen Abbildung sehen können, ähnelt das logische Symbol eines Smart-Keys dem eines Business-Keys. Die Symbole unterscheiden sich jedoch geringfügig, und die Form deutet auf einen Stapel hin.

In diesem Data-Vault-Modellierungsbeispiel wird jeder Business-Key als einzelnes Attribut in der Hub-Entität modelliert. Die Kombination identifiziert ein Geschäftsobjekt im Unternehmen. Die „Checking Number“ wird eigentlich nicht modelliert, da sie keinen geschäftlichen Nutzen hat (außer der Funktion als technische Prüfsumme).

Es ist jedoch nicht falsch, wenn Sie diese ebenfalls dem Modell hinzufügen.

Close Menu