Entwicklung des DATA VAULT und Übergang zum BUSINESS DATA VAULT

Im vorherigen Artikel habe ich die Grundlagen von DATA VAULT erläutert, die wichtigsten Elemente von DATA VAULT beschrieben und deren Zweck erklärt. Das Thema DATA VAULT ist damit jedoch nicht erschöpft, es ist notwendig, über die nächsten Stufen der Evolution von DATA VAULT zu sprechen.

In diesem Artikel konzentriere ich mich auf die Entwicklung von DATA VAULT und den Übergang zu BUSINESS DATA VAULT oder einfach BUSINESS VAULT.

Gründe für das Auftreten von BUSINESS DATA VAULT

Es ist zu beachten, dass DATA VAULT zwar über bestimmte Stärken verfügt, aber auch Schwächen hat. Eine dieser Schwächen ist die Komplexität beim Schreiben analytischer Abfragen. Abfragen enthalten eine erhebliche Anzahl von JOINs, der Code wird lang und unübersichtlich. Außerdem werden die Daten, die in DATA VAULT gelangen, keinen Transformationen unterzogen, sodass DATA VAULT aus geschäftlicher Sicht in seiner reinen Form keinen uneingeschränkten Wert hat.

Gerade um diese Schwächen zu beseitigen, wurde die Methodik von DATA VAULT um Elemente wie die folgenden erweitert:

• PIT (Point in Time) Tabellen;
• BRIDGE Tabellen;
• VORDEFINIERTE ABLEITUNGEN.

Lassen Sie uns die Funktion dieser Elemente näher betrachten.

PIT Tabellen

In der Regel kann ein Geschäftsobjekt (HUB) Daten mit unterschiedlichen Aktualisierungsfrequenzen enthalten; zum Beispiel können wir sagen, dass Informationen über Telefonnummern, Adressen oder E-Mail-Adressen eine höhere Aktualisierungsfrequenz aufweisen als z.B. Name, Personalausweisdaten, Familienstand oder Geschlecht.

Daher sollte bei der Definition von Satelliten die Frequenz ihrer Aktualisierung berücksichtigt werden. Warum ist das wichtig?

Wenn in einer Tabelle Attribute mit unterschiedlichen Aktualisierungsfrequenzen gespeichert werden, muss bei jeder Aktualisierung des am häufigsten geänderten Attributs eine Zeile in die Tabelle eingefügt werden. Folglich – Zuwachs des benötigten Speicherplatzes, Erhöhung der Ausführungszeit der Abfragen.

Jetzt, wo wir die Satelliten nach Aktualisierungsfrequenz unterteilt haben und Daten unabhängig laden können, muss die Möglichkeit sichergestellt werden, aktuelle Daten zu erhalten. Am besten, ohne unnötige JOINs.

Ich erkläre, dass beispielsweise aktuelle (nach dem Datum der letzten Aktualisierung) Informationen von Satelliten mit unterschiedlichen Aktualisierungsfrequenzen abgerufen werden müssen. Dazu ist es notwendig, nicht nur einen JOIN vorzunehmen, sondern auch mehrere verschachtelte Abfragen (zu jedem Satelliten, der Informationen enthält) zu erstellen, um das maximale Aktualisierungsdatum MAX(Aktualisierungsdatum) auszuwählen. Mit jedem neuen JOIN wächst dieser Code und wird sehr schnell schwer verständlich.

Die PIT-Tabelle soll solche Anfragen vereinfachen. Die PIT-Tabellen werden gleichzeitig mit der Aufnahme neuer Daten in den DATA VAULT gefüllt. PIT-Tabelle:

So haben wir Informationen über die Aktualität der Daten in allen Satelliten zu jedem Zeitpunkt. Durch die Verwendung von JOINs zur PIT-Tabelle können wir vollständig auf verschachtelte Abfragen verzichten, vorausgesetzt, dass die PIT täglich und ohne Unterbrechungen gefüllt wird. Selbst wenn es Unterbrechungen in der PIT gibt, können aktuelle Daten nur mit einer einzigen verschachtelten Abfrage zur PIT abgerufen werden. Eine verschachtelte Abfrage wird schneller ausgeführt als verschachtelte Abfragen zu jedem Satelliten.

BRIDGE

Tabellen vom Typ BRIDGE werden ebenfalls zur Vereinfachung analytischer Abfragen verwendet. Der Unterschied zur PIT besteht jedoch darin, dass sie zur Vereinfachung und Beschleunigung von Abfragen zwischen verschiedenen Hubs, Links und deren Satelliten dienen.

Die Tabelle enthält alle erforderlichen Schlüssel für alle Satelliten, die häufig in Abfragen verwendet werden. Darüber hinaus können bei Bedarf die gehashten Geschäftsschlüssel um Schlüssel in Textform ergänzt werden, wenn die Bezeichnungen der Schlüssel für die Analyse erforderlich sind.

Der Punkt ist, dass ohne die Verwendung von BRIDGE bei der Beschaffung von Daten aus Satelliten, die verschiedenen Hubs angehören, nicht nur die Satelliten selbst verknüpft werden müssen, sondern auch die Links, die die Hubs verbinden.

Das Vorhandensein oder Fehlen von BRIDGE wird durch die Konfiguration des Speichers und die Notwendigkeit, die Ausführungsgeschwindigkeit der Abfragen zu optimieren, bestimmt. Es ist schwierig, ein universelles Beispiel für BRIDGE zu finden.

VORDEFINIERTE ABLEITUNGEN

Ein weiterer Objekttyp, der uns dem BUSINESS DATA VAULT näher bringt, sind die Tabellen mit vorab berechneten Kennzahlen. Solche Tabellen sind für das Geschäft tatsächlich wichtig, da sie Informationen enthalten, die gemäß festgelegten Regeln aggregiert wurden, und relativ einfach darauf zugegriffen werden kann.

Architektonische PREDEFINED DERIVATIONS sind nichts anderes als ein weiterer Satellit eines bestimmten Hubs. Dieser enthält, wie ein gewöhnlicher Satellit, den Geschäftsschlüssel und das Datum der Eintragung im Satelliten. Damit enden jedoch die Ähnlichkeiten. Die weiteren Attribute eines solchen „spezialisierten“ Satelliten werden von den Geschäftsnutzern auf Basis der am meisten nachgefragten, zuvor berechneten Kennzahlen festgelegt.

Ein Hub, der Informationen über einen Mitarbeiter enthält, kann einen Satelliten mit Kennzahlen wie folgenden beinhalten:

• Mindestgehalt;
• Höchstgehalt;
• Durchschnittsgehalt;
• Kumulierte Summe des verrechneten Gehalts usw.

Es ist sinnvoll, die PREDEFINED DERIVATIONS in die PIT-Tabelle dieses Hubs aufzunehmen, da man so problemlos Datenausschnitte über Mitarbeiter zu einem spezifisch gewählten Datum erhalten kann.

FAZIT

Wie die Praxis zeigt, gestaltet sich die Nutzung von DATA VAULT durch Geschäftsnutzer aus mehreren Gründen als etwas schwierig:

• Die Abfragecodes sind komplex und umständlich;
• Die Vielzahl an JOINs beeinträchtigt die Performance der Abfragen;
• Um analytische Abfragen zu schreiben, ist ein hervorragendes Wissen über die Struktur des Datenspeichers erforderlich.

Um den Zugang zu den Daten zu erleichtern, wird DATA VAULT durch zusätzliche Objekte erweitert:

• PIT (Point in Time) Tabellen;
• BRIDGE Tabellen;
• VORDEFINIERTE ABLEITUNGEN.

Im nächsten Artikel Ich plane, meiner Meinung nach das Interessanteste für diejenigen zu erzählen, die mit BI arbeiten. Ich werde Methoden zur Erstellung von Faktentabellen und Dimensionstabellen auf Basis von DATA VAULT vorstellen.

Die Inhalte des Artikels basieren auf:

• Auf einer Veröffentlichung Kenta Graziano, die neben einer detaillierten Beschreibung auch Diagramme des Modells enthält;
• Buch: „Building a Scalable Data Warehouse with DATA VAULT 2.0“;
• Artikel Grundlagen von Data Vault.

Quelle: habr.com