Die letzter Artikel Im Rahmen unserer Serie haben wir uns kürzlich mit der Data Vault-Hub-Entität befasst, die zur Erfassung einer eindeutigen Liste von Geschäftsschlüsseln in einem data warehouse-Unternehmen verwendet wird, da die meisten Integrationen tatsächlich auf diesen Hub-Entitäten selbst stattfinden werden. Es gibt jedoch Szenarien, in denen die Integration von Daten allein auf diesen Hub-Entitäten nicht ausreicht, um das angestrebte Ziel zu erreichen.
Betrachten wir die folgende Situation, in der ein Beispieldatensatz, der eine Versicherungsgesellschaft betrifft, Kunden betrifft, die eine Kfz- und eine Hausratversicherung abschließen bzw. einen Schaden anmelden. Bevor wir mit dem Beispiel fortfahren, ist es wichtig zu wissen, dass es Beziehungen zwischen den beteiligten Geschäftsschlüsseln gibt, nämlich zwischen der Kundennummer, den Kennungen der Policen und den Schadensfällen.
Diese Beziehungen werden durch Data Vault-Link-Entitäten erfasst, und genau wie die Hubs enthalten sie eine eindeutige Liste von Datensätzen, d. h. sie enthalten keine Duplikate in Bezug auf die gespeicherten Daten. Beide bilden somit das Grundgerüst von Data Vault und werden später durch beschreibende, in Satelliten gespeicherte Nutzerdaten beschrieben.
Daher implementiert der Link die Beziehung, indem er auf alle Hubs verweist, die die an der Beziehung selbst beteiligten Geschäftsschlüssel speichern. Zur Veranschaulichung zeigt das folgende Diagramm eine Visual Data Vault Diagramm, das die gegebene Beziehung in Form einer Verknüpfung zeigt:
In MongoDB ist eine Link-Entität in einer Dokumentensammlung implementiert, genau wie die Hub-Entität, die im Abschnitt letzter Artikel als solche:
Daher enthält die Verknüpfungsstruktur die folgenden Objekte, die die Beziehung beschreiben:
- Die _id Element identifiziert das Link-Dokument, doch anstatt sich auf den MongoDB-Bezeichner zu verlassen, wird ein Hash-Wert berechnet, z. B. ein MD5-Wert, um den Link-Eintrag über die MongoDB-Datenbank hinaus eindeutig zu identifizieren.
- Die ldts (Zeitstempel des Ladedatums) gibt an, wann der Link-Eintrag vom Unternehmen data warehouse zum ersten Mal erkannt wurde.
- Die rsrc Element gibt die Quelle an, aus der der Link-Eintrag stammt.
- Die identifizierenden Hash-Schlüssel der referenzierten Hub-Dokumente sind enthalten in Referenz
Im Rahmen des Ladevorgangs der Sammlung von Verknüpfungsdokumenten werden zunächst die Beziehungen in der Sammlung der Quelldokumente ermittelt. Sobald die Beziehungen identifiziert sind, werden sie nach folgendem Verfahren in die Sammlung der Verknüpfungsdokumente geladen:
In MongoDB wird dieser Prozess mit Aggregationspipelines, wie in einem früheren Artikel beschrieben innerhalb dieser Reihe. Der Code filtert zunächst nach Kunden, die eine Hausratversicherung über $match. Dann wird die $onnenwind Stufe extrahiert das Array der Hausratversicherungen, d.h. ein Array mit mehreren Werten wird in einzelne Dokumente umgewandelt. Duplikate werden dann über $group.
Im Folgenden wird der Code gezeigt, der für das Laden einer Link-Dokumentensammlung aus einer Quellensammlung benötigt wird, um den zuvor beschriebenen Datenfluss zu implementieren. Er kann in der MongoDB-Shell ausgeführt werden, wobei zu beachten ist, dass er auch die Hashing-Funktion verwendet, die im Abschnitt vorheriger Artikel.
Bitte beachten Sie, dass es Variationen dieser Verknüpfungsstruktur gibt, z.B. zur Erfassung von Transaktionen, was dann als nicht-historisierte Verknüpfung bezeichnet wird, oder von Einzelposten, z.B. aus Rechnungen und Bestellungen, in einer degenerierten Verknüpfung. Um diesen Punkt zu vertiefen, sollten Sie weitere Aspekte der Forderungen berücksichtigen, da sie keine eindeutigen Geschäftsschlüssel haben. Zur Veranschaulichung: Die Verknüpfung würde zwar die erste Transaktion, z. B. einen Schadensfall, erfassen, nicht aber nachfolgende Schadensfälle der gleichen Police. Das liegt daran, dass die Verknüpfung eine eindeutige Liste von Geschäftsschlüsselbeziehungen ist, und sobald sie die Beziehung zwischen dem Kunden und der zugehörigen Hausratversicherung gefunden hat, werden nachfolgende Transaktionen nicht geladen.
Dies wird zu einem Problem, wenn transaktionsbasierte Fakteneinheiten bereitgestellt werden.
Normalerweise möchten die meisten Benutzer einen Datensatz pro Transaktion haben. Um dies zu erreichen, müssen wir das obige Verknüpfungsmuster so abändern, dass es möglich ist, mehrere Transaktionen mit denselben Verweisen auf ein Hub-Dokument zu laden.
Dies wird erreicht, indem dem Verknüpfungsdokument ein zusätzlicher Satz von Elementen hinzugefügt wird und die Dokument-ID dann nicht nur aus den referenzierten Geschäftsschlüsseln, sondern auch aus dem oder den zusätzlichen Elementen berechnet wird. Auf diese Weise wird eine eindeutige Dokument-ID pro Transaktion oder Ereignis ermittelt.
Bevor wir uns jedoch zu sehr mit diesem Konzept befassen, sollten wir diese speziellen Link-Entitäten in einem späteren Beitrag betrachten.
Bitte beachten Sie, dass diese Arbeit aus einem laufenden Projekt zwischen Scalefree und MongoDB stammt, dessen Ziel die Feinabstimmung dieser Anweisungen in großem Umfang ist.
Daher werden wir diese Artikel in naher Zukunft weiter aktualisieren.
Um die aktualisierten Informationen zu sehen, setzen Sie bitte ein Lesezeichen auf diesen Artikel.
Fragen? Kommentare?
Wir würden uns freuen, von Ihnen im Kommentarbereich unten zu hören!
Updates und Support erhalten
Bitte senden Sie Anfragen und Funktionswünsche an [email protected].
Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.
Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.
