In den vorangegangenen Artikeln dieser Serie wurden Hub- und Link-Entitäten zur Erfassung von Business Keys sowie der Beziehungen zwischen Business Keys vorgestellt. Zur Veranschaulichung: Die Hub-Document-Collection in MongoDB ist eine eindeutige (distinct) Liste von Business Keys, die zur Identifizierung von Kunden verwendet werden.
Um deskriptive Daten zu erfassen, in diesem Fall die beschreibenden Merkmale der Business Keys, werden in Data Vault Satellite-Entitäten verwendet. Da sowohl Business Keys als auch Beziehungen zwischen Business Keys durch Benutzerdaten beschrieben werden können, können Satellites wie folgt sowohl an Hub- als auch an Link-Entitäten angehängt werden:
Die Art und Weise, wie diese Data-Vault-Satellites in MongoDB implementiert werden, unterscheidet sich jedoch im Vergleich zu einem Data-Vault-Modell auf einer relationalen Datenbank. In erster Linie gibt es Satellite-Dokumente, die einen Business Key oder eine Beziehung beschreiben. Da sich diese Werte im Laufe der Zeit verändern können, wird das Dokument im _id–Attribut durch zwei Unterattribute identifiziert: die _id des Business Keys (in diesem Fall ein Hash Key) und den ldts-Wert (Load Date Timestamp) des deskriptiven Dokuments:
Das obige Dokument beschreibt einen Kunden und verweist daher auf den Hash Key hk_customer_h des Business-Key-Dokuments des Kunden, in diesem Fall ein Hub-Dokument.
Wie jedes andere Data-Vault-Dokument enthält es ein rsrc-Attribut, das die Datenquelle identifiziert. Ebenso ist hd_customer_info_s der Hash Diff des Dokuments, also der Hash-Wert, der verwendet wird, um nachträgliche Änderungen am Dokument zu identifizieren. Bitte beachten Sie, dass wir auf diesen speziellen Aspekt in dieser Artikelserie nicht näher eingehen, da er innerhalb des Prozesses optional ist.
Die Unterstruktur rdv_customer_info_s im obigen Beispiel enthält die Benutzerattribute, die den Business Key für einen bestimmten Zeitpunkt (wie den Load Date Timestamp) beschreiben. Beachten Sie, dass diese Struktur mehrere Unterobjekte enthalten kann und nicht nur flache Attribute (flattened attributes), wie in diesem Beispiel gezeigt.
Bitte beachten Sie außerdem, dass sich diese deskriptiven Datenattribute in Unternehmensdaten im Laufe der Zeit häufig ändern: Kunden im obigen Beispiel können ihre E-Mail-Adresse oder Telefonnummer, ihr Geschlecht oder ihren Beruf ändern und heiraten, wodurch sich sowohl ihr Nachname als auch ihr Familienstand ändern. Die Anzahl der Kinder wird häufig aktualisiert, und selbst das Geburtsdatum eines Kunden könnte korrigiert werden. Sollten die Quelldaten aus irgendeinem Grund fehlerhaft eingegeben worden sein und sich diese Datenqualitätsprobleme im Laufe der Zeit ändern, sollte das Data-Vault-Satellite-Dokument diese Änderungen widerspiegeln.
Während ein operatives System das Dokument überschreiben würde, sollte jede Änderung an den Daten innerhalb eines Data Warehouses versioniert werden. Dies geschieht in der Data-Vault-Satellite-Document-Collection. In diesem Fall ist es jedoch nicht zwingend erforderlich, Delta-Checks durchzuführen, um tatsächliche Änderungen an den Quelldaten auf Basis der Attribute des Ziel-Satellites zu identifizieren. Stattdessen ist es möglich, einfach jedes Quelldokument in den Satellite zu laden und somit Non-Deltas zu akzeptieren. Der einzige Nachteil dieses Verfahrens besteht darin, dass der Satellite mehr Speicherplatz als nötig beansprucht.
Da die Satellite-Dokumente einen Business Key oder eine Beziehung zwischen Business Keys beschreiben, werden sie in derselben MongoDB-Collection wie das Hub- oder Link-Dokument gespeichert, sodass keine zusätzliche Document-Collection für Satellite-Dokumente erforderlich ist; dargestellt wie folgt:
Das obige Diagramm veranschaulicht, warum der Name der Satellite-Struktur entscheidend ist: Wenn später eine Merge- und Flatten-Funktion verwendet wird, führt diese das Hub-Dokument (den Business Key) mit den Satellite-Dokumenten (in diesem Fall den Beschreibungen) zusammen.
Es ist möglich, die Attribute zu einem späteren Zeitpunkt abzuflachen (flatten) und ein kombiniertes Dokument mit einem Business Key sowie all seinen Beschreibungen samt den zugehörigen Versionen aus allen Satellites abzurufen. Der Name des Satellites in der Unterstruktur stellt sicher, dass identische Attributnamen , wie etwa ein Vorname aus mehreren Quellsystemen und somit aus mehreren Satellites – kein Problem darstellen.
Um die Satellite-Dokumente in die Hub- oder Link-Collection zu laden, werden typischerweise die folgenden Operationen durchgeführt:
Der Ladeprozess ist unkompliziert: Zunächst werden die deskriptiven Daten aus den Quell-Collections bezogen, die Struktur des Ziel-Satellites wird auf die eingehenden Dokumente projiziert, um eventuelle Satellite-Splits durchzuführen, und anschließend werden die Daten in die Ziel-Collection (in manchen Fällen ein Hub oder ein Link) eingefügt. Bitte beachten Sie, dass in diesem Fall kein Delta-Check verwendet wird, da dieser optional ist und auf dem Hash Diff basieren würde.
Der MongoDB-Quellcode für das Laden eines solchen Satellites ist unten dargestellt:
Auch hier gilt: Obwohl dieses Skript den Hash-Diff-Wert berechnet, wird er derzeit nicht für Delta-Checks verwendet.
Damit ist unsere erste Serie über Data Vault auf MongoDB abgeschlossen. Wie bereits erwähnt, entstammt diese Arbeit einem laufenden Projekt zwischen Scalefree und MongoDB, um diese Ansätze für massive Datenvolumina zu optimieren.
Aus diesem Grund werden wir diese Artikel in naher Zukunft weiter aktualisieren. Kontaktieren Sie uns daher gerne bezüglich zwischenzeitlicher Updates. Wenn Sie Anmerkungen zu den obigen Ausführungen haben, hinterlassen Sie unten gerne einen Kommentar.