Entwicklung von DATA VAULT und Übergang zu BUSINESS DATA VAULT

Im vorherigen Artikel habe ich die Grundlagen des DATA VAULT erklärt und die wesentlichen Elemente sowie deren Zweck beschrieben. Die Thematik des DATA VAULT ist damit jedoch nicht vollständig behandelt, und es ist notwendig, über die nächsten Entwicklungsstufen des DATA VAULT zu sprechen.

In diesem Artikel werde ich mich auf die Weiterentwicklung des DATA VAULT und den Übergang zu BUSINESS DATA VAULT oder einfach BUSINESS VAULT konzentrieren.

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

Es ist erwähnenswert, dass DATA VAULT trotz bestimmter Stärken auch Schwächen aufweist. Eine dieser Schwächen ist die Komplexität beim Schreiben analytischer Abfragen. Die Abfragen enthalten zahlreiche JOINs, wodurch der Code lang und unübersichtlich wird. Zudem unterliegen die in DATA VAULT aufgenommenen Daten keinen Transformationen, sodass DATA VAULT in seiner reinen Form aus geschäftlicher Sicht keinen uneingeschränkten Wert hat.

Um diese Schwächen zu beheben, wurde die DATA VAULT-Methodologie um Elemente wie folgende erweitert:

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

Lassen Sie uns die Funktionen dieser Elemente im Detail betrachten.

PIT Tabellen

In der Regel kann ein Geschäftsobjekt (HUB) Daten mit unterschiedlichen Aktualisierungsfrequenzen enthalten. Wenn wir beispielsweise über Daten sprechen, die eine Person charakterisieren, können wir sagen, dass Informationen über Telefonnummer, Adresse oder E-Mail eine höhere Aktualisierungsfrequenz haben als zum Beispiel Name, Passdaten, Familienstand oder Geschlecht.

Daher sollte bei der Festlegung von Satelliten die Aktualisierungsfrequenz berücksichtigt werden. Warum ist das wichtig?

Wenn in einer Tabelle Attribute mit unterschiedlicher Aktualisierungsfrequenz gespeichert werden, muss bei jeder Aktualisierung des am häufigsten geänderten Attributs eine Zeile in die Tabelle eingefügt werden. Dies führt zu steigendem Speicherplatzbedarf und längeren Ausführungszeiten der Abfragen.

Jetzt, da wir die Satelliten nach Aktualisierungsfrequenz sortiert haben und die Daten unabhängig laden können, sollten wir sicherstellen, dass aktuelle Daten abgerufen werden können. Am besten ohne überflüssige JOINs.

Ich erkläre, dass man aktuelle Informationen (zum Zeitpunkt der letzten Aktualisierung) von Satelliten mit unterschiedlichen Aktualisierungsfrequenzen abrufen möchte. Dazu ist es notwendig, nicht nur einen JOIN durchzuführen, sondern auch mehrere verschachtelte Abfragen (für jeden Satelliten mit Informationen) zu erstellen, bei denen das maximale Aktualisierungsdatum MAX(Aktualisierungsdatum) ausgewählt wird. Mit jedem neuen JOIN wuchert dieser Code und wird schnell schwer verständlich.

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

So haben wir Informationen über die Aktualität der Daten für alle 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 jeden Tag ohne Unterbrechungen gefüllt wird. Selbst wenn es Unterbrechungen in der PIT gibt, können aktuelle Daten nur durch eine einzige verschachtelte Abfrage zur PIT selbst erhalten werden. Eine einzige verschachtelte Abfrage wird schneller ausgeführt als die verschachtelten Abfragen zu jedem Satelliten.

BRIDGE

Bridge-Tabellen werden auch verwendet, um analytische Abfragen zu vereinfachen. Der Unterschied zu PIT besteht jedoch darin, dass sie dazu dienen, Abfragen zwischen verschiedenen Hubs, Links und ihren Satelliten zu vereinfachen und zu beschleunigen.

Die Tabelle enthält alle notwendigen Schlüssel für alle Satelliten, die häufig in Abfragen verwendet werden. Darüber hinaus können, falls erforderlich, gehashte Geschäftsschlüssel durch textuelle Schlüssel ergänzt werden, wenn die Bezeichnungen der Schlüssel für die Analyse benötigt werden.

Ohne die Verwendung von Bridge müssen bei der Datenbeschaffung von Satelliten, die verschiedenen Hubs gehören, JOIN-Befehle nicht nur für die Satelliten selbst, sondern auch für die Links, die die Hubs verbinden, durchgeführt werden.

Das Vorhandensein oder Fehlen von Bridge hängt von der Konfiguration des Speichers und der Notwendigkeit zur Optimierung der Geschwindigkeit bei der Ausführung von Abfragen ab. Ein universelles Beispiel für Bridge zu finden, ist schwierig.

VORDEFINIERTE ABLEITUNGEN

Ein weiterer Objekttyp, der uns dem BUSINESS DATA VAULT näher bringt, sind Tabellen, die vorher berechnete Kennzahlen enthalten. Solche Tabellen sind für Unternehmen von großer Bedeutung, da sie Informationen enthalten, die nach bestimmten Regeln aggregiert werden, und relativ einfach darauf zugegriffen werden kann.

Architektonisch stellen PREDEFINED DERIVATIONS nichts anderes dar als einen weiteren Satelliten eines bestimmten Hubs. Er enthält, wie ein gewöhnlicher Satellit, den Geschäftsschlüssel und das Datum der Erstellung des Eintrags im Satelliten. Damit enden jedoch die Gemeinsamkeiten. Die weiteren Attribute eines solchen 'spezialisierten' Satelliten werden von den Geschäftsanwendern auf Grundlage der gefragtesten, vorher berechneten Kennzahlen festgelegt.

Ein Hub, der Informationen über einen Mitarbeiter enthält, könnte Satelliten mit Kennzahlen wie diesen umfassen:

• Mindestgehalt;
• Höchstgehalt;
• Durchschnittsgehalt;
• Akkumulierter Betrag des ausgezahlten Gehalts usw.

Es ist sinnvoll, PREDEFINED DERIVATIONS in die PIT-Tabellen desselben Hubs aufzunehmen, um problemlos Datenschnitte zu einem bestimmten Datum für einen Mitarbeiter zu erhalten.

FAZIT

Wie sich in der Praxis zeigt, ist die Nutzung von DATA VAULT durch Unternehmen aus mehreren Gründen etwas kompliziert:

• Die Abfragen sind komplex und umständlich;
• Die Vielzahl an JOINs wirkt sich auf die Abfragegeschwindigkeit aus;
• Um analytische Abfragen zu schreiben, ist ein herausragendes Verständnis der Speicherstruktur 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, das meiner Meinung nach Interessanteste für diejenigen zu präsentieren, die mit BI arbeiten. Ich werde Methoden zur Erstellung von Fakten- und Dimensionstabellen auf Basis von DATA VAULT vorstellen.

Die Materialien des Artikels basieren auf:

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

Quelle: habr.com