Modellierung des Datentresors

Einfaches Datentresor-Modell mit zwei Hubs (blau), einem Link (grün) und vier Satelliten (gelb)

Der Datentresor versucht, das Problem des Umgangs mit Veränderungen in der Umgebung zu lösen, indem er die Geschäftsschlüssel (die sich nicht so oft ändern, (die sich nicht so oft ändern, weil sie eine Geschäftseinheit eindeutig identifizieren) und die Verknüpfungen zwischen diesen Geschäftsschlüsseln von den beschreibenden Attributen dieser Schlüssel trennen.

Die Geschäftsschlüssel und ihre Assoziationen sind strukturelle Attribute, die das Gerüst des Datenmodells bilden. Die Data-Vault-Methode hat als eines ihrer Hauptaxiome, dass sich echte Geschäftsschlüssel nur ändern, wenn sich das Geschäft ändert, und daher die stabilsten Elemente sind, aus denen man die Struktur einer historischen Datenbank ableiten kann. Wenn Sie diese Schlüssel als Rückgrat eines Data Warehouse verwenden, können Sie den Rest der Daten um sie herum organisieren. Das bedeutet, dass die Wahl der richtigen Schlüssel für die Knotenpunkte von größter Bedeutung für die Stabilität Ihres Modells ist. Die Schlüssel werden in Tabellen gespeichert, deren Struktur einigen Beschränkungen unterliegt. Diese Schlüsseltabellen werden Hubs genannt.

HubsEdit

Hubs enthalten eine Liste von eindeutigen Geschäftsschlüsseln mit geringer Neigung zur Änderung. Hubs enthalten auch einen Ersatzschlüssel für jedes Hub-Element und Metadaten, die den Ursprung des Geschäftsschlüssels beschreiben. Die beschreibenden Attribute für die Informationen über den Hub (z. B. die Beschreibung des Schlüssels, möglicherweise in mehreren Sprachen) werden in Strukturen gespeichert, die Satellitentabellen genannt werden und auf die weiter unten eingegangen wird.

Der Hub enthält mindestens die folgenden Felder:

• einen Surrogatschlüssel, der verwendet wird, um die anderen Strukturen mit dieser Tabelle zu verbinden.
• einen Unternehmensschlüssel, den Treiber für diesen Hub. Der Geschäftsschlüssel kann aus mehreren Feldern bestehen.
• die Datensatzquelle, die verwendet werden kann, um zu sehen, welches System jeden Geschäftsschlüssel zuerst geladen hat.
• optional können Sie auch Metadatenfelder mit Informationen über manuelle Aktualisierungen (Benutzer/Zeit) und das Extraktionsdatum haben.

Ein Hub darf nicht mehrere Business Keys enthalten, außer wenn zwei Systeme denselben Business Key liefern, aber mit Kollisionen, die unterschiedliche Bedeutungen haben.

Hubs sollten normalerweise mindestens einen Satelliten haben.

Hub-BeispielBearbeiten

Dies ist ein Beispiel für eine Hub-Tabelle, die Autos enthält, genannt „Car“ (H_CAR). Der führende Schlüssel ist die Fahrzeugidentifikationsnummer.

LinksEdit

Verknüpfungen oder Transaktionen zwischen Business Keys (z.B. die Hubs für Kunde und Produkt durch den Kaufvorgang miteinander in Beziehung setzen) werden mit Hilfe von Verknüpfungstabellen modelliert.

Verknüpfungen können auf andere Verknüpfungen verweisen, um Änderungen in der Granularität zu berücksichtigen (z. B. würde das Hinzufügen eines neuen Schlüssels zu einer Datenbanktabelle die Granularität der Datenbanktabelle ändern). Wenn Sie zum Beispiel eine Assoziation zwischen Kunde und Adresse haben, könnten Sie einen Verweis auf eine Verknüpfung zwischen den Knotenpunkten für Produkt und Transportunternehmen hinzufügen. Dies könnte eine Verknüpfung namens „Lieferung“ sein. Eine Verknüpfung in einer anderen Verknüpfung zu referenzieren, gilt als schlechte Praxis, weil dadurch Abhängigkeiten zwischen Verknüpfungen entstehen, die das parallele Laden erschweren. Da eine Verknüpfung zu einer anderen Verknüpfung dasselbe ist wie eine neue Verknüpfung mit den Knotenpunkten der anderen Verknüpfung, ist in diesen Fällen die Erstellung der Verknüpfungen ohne Verweis auf andere Verknüpfungen die bevorzugte Lösung (siehe den Abschnitt über Ladepraktiken für weitere Informationen).

Verknüpfungen verknüpfen manchmal Knotenpunkte mit Informationen, die allein nicht ausreichen, um einen Knotenpunkt zu bilden. Dies geschieht, wenn einer der durch den Link verknüpften Geschäftsschlüssel kein echter Geschäftsschlüssel ist. Nehmen wir als Beispiel ein Bestellformular mit „Bestellnummer“ als Schlüssel und Bestellzeilen, die mit einer halbzufälligen Nummer verschlüsselt sind, um sie eindeutig zu machen. Sagen wir, „eindeutige Nummer“. Der letztgenannte Schlüssel ist kein echter Geschäftsschlüssel, er ist also kein Knotenpunkt. Wir müssen ihn jedoch verwenden, um die richtige Granularität für die Verbindung zu gewährleisten. In diesem Fall verwenden wir keinen Hub mit Surrogatschlüssel, sondern fügen den Geschäftsschlüssel „unique number“ selbst zur Verknüpfung hinzu. Dies geschieht nur dann, wenn keine Möglichkeit besteht, den Geschäftsschlüssel jemals für eine andere Verbindung oder als Schlüssel für Attribute in einem Satelliten zu verwenden. Dieses Konstrukt wurde von Dan Linstedt in seinem (jetzt nicht mehr existierenden) Forum als „peg-legged link“ bezeichnet.

Links enthalten die Surrogatschlüssel für die Hubs, die verlinkt sind, ihren eigenen Surrogatschlüssel für den Link und Metadaten, die den Ursprung der Verbindung beschreiben. Die beschreibenden Attribute für die Informationen über die Assoziation (wie Zeit, Preis oder Betrag) werden in Strukturen gespeichert, die Satellitentabellen genannt werden und auf die weiter unten eingegangen wird.

Link-BeispielBearbeiten

Dies ist ein Beispiel für eine Link-Tabelle zwischen zwei Knotenpunkten für Autos (H_CAR) und Personen (H_PERSON). Der Link heißt „Fahrer“ (L_DRIVER).

SatellitesEdit

Die Hubs und Links bilden die Struktur des Modells, haben aber keine zeitlichen Attribute und enthalten keine beschreibenden Attribute. Sie werden in separaten Tabellen gespeichert, die Satelliten genannt werden. Diese bestehen aus Metadaten, die sie mit ihrem übergeordneten Hub oder Link verknüpfen, Metadaten, die den Ursprung der Assoziation und der Attribute beschreiben, sowie einer Zeitleiste mit Start- und Enddatum für das Attribut. Während die Hubs und Links die Struktur des Modells bilden, liefern die Satelliten das „Fleisch“ des Modells, den Kontext für die Geschäftsprozesse, die in den Hubs und Links erfasst sind. Diese Attribute werden sowohl in Bezug auf die Details der Angelegenheit als auch auf die Zeitachse gespeichert und können von recht komplex (alle Felder, die das vollständige Profil eines Kunden beschreiben) bis hin zu recht einfach (ein Satellit auf einem Link mit nur einem Gültigkeitsindikator und einer Zeitachse) reichen.

Gemäß der Regel werden die Attribute in Satelliten nach Quellsystem gruppiert. Allerdings können sich beschreibende Attribute wie Größe, Kosten, Geschwindigkeit, Menge oder Farbe unterschiedlich schnell ändern, so dass man diese Attribute auch nach ihrer Änderungsgeschwindigkeit in verschiedene Satelliten aufteilen kann.

Alle Tabellen enthalten Metadaten, die mindestens das Quellsystem und das Datum, an dem dieser Eintrag gültig wurde, beschreiben, so dass eine vollständige historische Sicht auf die Daten gegeben ist, wenn sie in das Data Warehouse gelangen.

SatellitenbeispielBearbeiten

Dies ist ein Beispiel für einen Satelliten auf der Fahrer-Verbindung zwischen den Knotenpunkten für Autos und Personen, genannt „Fahrerversicherung“ (S_DRIVER_INSURANCE). Dieser Satellit enthält Attribute, die für die Versicherung der Beziehung zwischen dem Auto und der Person, die es fährt, spezifisch sind, z. B. einen Indikator, ob es sich um den Hauptfahrer handelt, den Namen der Versicherungsgesellschaft für dieses Auto und diese Person (könnte auch ein separater Hub sein) und eine Zusammenfassung der Anzahl der Unfälle, an denen diese Kombination aus Fahrzeug und Fahrer beteiligt war. Ebenfalls enthalten ist ein Verweis auf eine Nachschlage- oder Referenztabelle mit der Bezeichnung R_RISK_CATEGORY, die die Codes für die Risikokategorie enthält, in die diese Beziehung einzuordnen ist.

(*) mindestens ein Attribut ist obligatorisch.(**) Die Sequenznummer wird obligatorisch, wenn sie benötigt wird, um die Eindeutigkeit für mehrere gültige Satelliten auf demselben Hub oder Link zu erzwingen.

ReferenztabellenBearbeiten

Referenztabellen sind ein normaler Bestandteil eines gesunden Datentresor-Modells. Sie sind dazu da, die redundante Speicherung von einfachen Referenzdaten zu verhindern, auf die häufig verwiesen wird. Formal definiert Dan Linstedt Referenzdaten wie folgt:

Jede Information, die als notwendig erachtet wird, um Beschreibungen aus Codes aufzulösen oder um Schlüssel auf (sic) eine konsistente Weise zu übersetzen. Viele dieser Felder sind „beschreibender“ Natur und beschreiben einen bestimmten Zustand der anderen, wichtigeren Informationen. Daher befinden sich die Referenzdaten in separaten Tabellen, die von den rohen Data Vault-Tabellen getrennt sind.

Referenztabellen werden von den Satelliten referenziert, aber nie mit physischen Fremdschlüsseln verbunden. Es gibt keine vorgeschriebene Struktur für Referenztabellen: Verwenden Sie, was in Ihrem speziellen Fall am besten funktioniert, von einfachen Nachschlagetabellen bis hin zu kleinen Datentresoren oder sogar Sternen. Sie können historisch sein oder keine Historie haben, aber es wird empfohlen, sich an die natürlichen Schlüssel zu halten und in diesem Fall keine Ersatzschlüssel zu erstellen. Normalerweise haben Datentresore eine Menge Referenztabellen, genau wie jedes andere Data Warehouse.

ReferenzbeispielBearbeiten

Dies ist ein Beispiel für eine Referenztabelle mit Risikokategorien für Fahrer von Fahrzeugen. Sie kann von jedem Satelliten im Data Vault referenziert werden. Im Moment verweisen wir auf die Tabelle über den Satelliten S_DRIVER_INSURANCE. Die Referenztabelle lautet R_RISK_CATEGORY.

(*) mindestens ein Attribut ist obligatorisch.