Da war sie wieder, die lebhafte Diskussion über die Verwendung eines Data Vault Link-Satellite. Die Argumentation, ob ja oder nein, drehte sich im Kreis.
DVEE Consortium Summit - Rotterdam, das jährliche Treffen der Data Vault & Ensemble Enthusiasten (DVEE), ein weltweites Treffen zum Austausch unter Experten. Dies war der Ort der Diskussion, das Ereignis, das wieder einmal die Diskussion in der Gruppe auslöste, ob Data Vault Link-Satelliten verwendet werden sollten: ja oder nein?
Die Diskussion beinhaltete immer wieder die unterschiedlichsten, z.B. fachlichen und technischen, Argumente für und gegen einen Satelliten am Link in Data Vault, die jedoch für einen Argumentationsleitfaden getrennt werden sollten.
In diesem Artikel gehe ich auf den Hintergrund der Diskussion aus der Sicht von Diego Pasión ein und stelle seinen Ansatz vor, wie er diese Modellierungsentscheidung angehen und die verschiedenen Perspektiven in einer Entscheidungshilfe festhalten will.
Data Vault Link-Satellite - Was ist der Hintergrund?
Data Vault ist eine physische Datenmodellierungsmethode mit dem Ziel, Daten möglichst effizient und technisch vollständig historisiert zu speichern. Daher ist es sehr schwierig, während der Modellierung eines Data Vault Datenmodells die fachlichen Ursachen für auftretende Probleme zu diskutieren oder gar eine Lösung zu finden.
Ein Data Vault Link-Satellite ist ein strukturelles Element im Data Vault Datenmodell, das zusätzliche beschreibende Attribute für eine Beziehung zwischen zwei oder mehr Hubs speichert. Während ein Link die Verbindungen zwischen Geschäftsobjekten (repräsentiert durch Hubs) darstellt, erfasst der zugehörige Link-Satellite die sich im Laufe der Zeit verändernden Eigenschaften oder Details dieser Beziehung. Beispiele könnten Attribute wie Vertragsbedingungen, Rollen in einer Partnerschaft, Transaktionsdaten oder Unit of Work (UOW) sein. Link-Satellites ermöglichen es, die Flexibilität und Historisierung des Data Vault Datenmodells auch auf Verbindungen zwischen Geschäftsobjekten auszudehnen.
Eine Lösung und Argumentationshilfe
Wie in vielen Bereichen in der Welt der Daten entwickeln sich mit der Zeit nicht nur Ideen und Methoden weiter, sondern auch die Herangehensweisen. So auch bei Diego Pasión: Inzwischen ist er - der bekannte Coach des DMCE-Teams von FastChangeCo - davon überzeugt, dass mit einem fachlichen Datenmodell ein viel besseres Data Vault Datenmodell entworfen werden kann, als ohne. Hauptsächlich deswegen, da die Modellierung der Information (Fachlichkeit) von der physischen Implementierung getrennt ist.
Aus diesem Ansatz leitet sich sein Leitfaden für die Argumentation ab, wenn Diskussionen über das Für und Wider von Data Vault Link-Satelliten hitziger werden oder er begründet, warum es ‘per se keine’ Link-Satelliten geben kann.
Diego zeigt in dieser Situation gerne anhand eines einfachen Beispiels auf, wie ein Data-Vault-Datenmodell aus einer fachlichen Datenmodellierung abgeleitet wird und wie sich daraus sein Leitfaden für die Argumentation, ob Satelliten an Links modelliert werden sollen, ergibt.
“Wenn man immer vom fachlichen Datenmodell ausgeht, was grundsätzlich zu empfehlen ist,” so Diego, “dann passiert bei der Instanziierung eines logischen Datenmodells (LDM) in ein physisches Data-Vault-Datenmodell (DV), dass eine Entität im ersten Schritt ‘automatisch’ zu einem Hub und einem Satelliten wird und eine Relation zu einem Link ohne Satelliten.”
Im Diego-Leitfaden gelten daher die folgenden einfachen Regeln:
- Entitätsattribut(e) (Identifizierend - Wie bekomme ich einen und nur einen Datensatz): Wird/werden zum Geschäftsschlüssel im Hub
- Entitätsattribut(e) (beschreiben, messen - Was ist wichtig über eine Entität?): Wird/werden zu Kontextattributen im Satelliten
- Relation (Was ist der Grund für eine Beziehung zwischen zwei Entitäten?): Wird zu einem Link
“Aus fachlicher Sicht, im Sinne eines LDM,” fährt Diego fort, “kann es also deshalb nie einen Data Vault Link-Satelliten geben, da Relationen niemals beschreibende Attribute haben. Die Beziehung zwischen ‘Employee’ und ‘Department’ würde in der Entität 'Employee' aktualisiert (update), falls der Mitarbeiter die Abteilung wechselt. Wo sie zu einem bestimmten Zeitpunkt in der Vergangenheit gearbeitet hat, spielt, grob gesagt, keine Rolle.”
Diego blickt in die Runde, als er seinen Leitfaden den Zuhörern vorstellt.
“Hätte eine Relation im LDM einen beschreibenden Kontext, dann würde der Datenmodellierer im LDM eine assoziative Entität modellieren. Diese würde die beschreibenden Attribute der Relation aufnehmen, dann aber, so der Leitfaden, wieder zu einem Hub und Satelliten im DV werden.”
“Diego, kannst du uns das anhand eines Beispiels mal zeigen?”
Aus dem zuvor gezeigten LDM leitet Diego das folgende Data Vault Datenmodell anhand seines Leitfadens ab: “Aus den Entitäten ‘Employee’ und ‘Department’ wird jeweils ein Hub und ein Satellite physisch modelliert. Die Relation ‘works in’ wird zu dem Link zwischen den beiden Hubs”
Separation of concerns
“Aber was ist, wenn der Mitarbeiter die Abteilung wechselt?” wird Diego gefragt.
Diego greift die gestellte Frage auf und erklärt: "Da ein LDM sich nicht um die technische Historisierung ‘kümmert’, diese aber dennoch von Interesse ist, bringt Data Vault als grundlegende Eigenschaft eine technische Historisierung für den beschreibenden Kontext in Satelliten mit. In einem physischen Datenmodell, das ‘eins-zu-eins’ vom LDM abgeleitet ist, gäbe es keine Historisierung, nur Updates. Ob dies in Ordnung ist, hängt von der Anwendung ab, die auf dem physischen Datenmodell aufbaut.”
Diego sagt, dass er generell für eine getrennte Betrachtung von fachlichen und temporalen Aspekten ist: “In dem Moment, in dem eine technische Historisierung in die Diskussion kommt, sieht die Sache anders aus. Denn bei einer One-to-many-Beziehung muss eine Veränderung auch technisch dokumentiert werden. Z.B. wenn die Mitarbeiterin Sophie von der Abteilung A in die Abteilung B wechselt.”
“Generell wird in den Data Vault Satelliten eine Spalte ‘Load Date Timestamp’ (LDTS, oder wie in den gezeigten Datenmodellen der Inscription Timestamp) für die rein technische Historisierung/Versionierung der Daten verwendet”, erklärt Diego die Grundzüge.
“Diese Spalte ist Teil des physischen Datenmodells, der Instanziierung des LDM, da erst hier eine Versionierung (statt einer Aktualisierung) der Daten erforderlich ist, um frühere Zustände der Daten zu ‘konservieren’.“
“Um bei dem Beispiel zu bleiben”, fährt Diego fort, “wenn nun die Mitarbeiterin Sophie von Abteilung A in Abteilung B wechselt, wird durch dieses Ereignis ein weiterer Datensatz dem Link hinzugefügt. Im zuvor gezeigten Datenmodell wäre die Beziehung nun nicht mehr eindeutig! Da aus den Daten nicht eindeutig hervorgeht, in welcher Abteilung Sophie gerade arbeitet”.
Die von Diego favorisierte Lösung für dieses Szenario (One-To-Many-Relation) ist ein (End-Dating) Satellit am Link, der sich ausschließlich um die technische Historisierung des Links kümmert. Mit Hilfe eines sogenannten Driving Keys im Link können und werden die One-To-Many Änderungen im Link durch den Satelliten historisch korrekt dokumentiert.
Die beschreibenden Attribute
“Das physische Data Vault Datenmodell würde sich wieder ändern, wenn sich das Informationsmodell, das LDM, ändert”, merkt Diego an.
“Das können, wie bereits erwähnt, weitere beschreibende Attribute an der Relation sein. Ein Beispiel wäre, wenn die Relation im obigen Datenmodell zwischen ‘Mitarbeiter’ und ‘Abteilung’ folgende beschreibende Attribute erhält: Der Arbeitsbeginn von Sophie in einer neuen Abteilung B liegt drei Monate in der Zukunft. Dort wird Sophie für drei Monate die Rolle des Datenmodellierers übernehmen.”
“Dies können, wie bereits erwähnt, beschreibende Attribute an der Beziehung sein”, erklärt Diego.
“Ein Beispiel ist die Beziehung zwischen ‘Employee’ und ‘Department’, für die Folgendes gilt:
Der Arbeitsbeginn (‘Work Begin Date’) von Sophie in einer neuen Abteilung B liegt drei Monate in der Zukunft.
Sophie übernimmt dann für drei Monate (Zeitraum: ‘Work Begin Date’, ‘Work End Date’) die Rolle einer Datenmodelliererin (‘Assignment’).”
Diego präsentiert seinen Zuhörern das überarbeitete Fachdatenmodell / Fachdatenmodell mit den neuen Informationen:
Diego schaut in die Runde, während er den Zuhörern das LDM zeigt.
“Die Beziehung zwischen ‘Employee’ und ‘Department’ hat jetzt einen beschreibenden Kontext, und um dies zu berücksichtigen hat die Datenmodelliererin eine assoziative Entität im LDM hinzugefügt.
Dieses neue Objekt enthält die beschreibenden Attribute der Beziehung: 'Work Begin Date', indirekt die Dauer (Zeitraum: 'Work Begin Date', 'Work End Date') und 'Assignment'.
Der fachliche Zeitraum beschreibt, wie andere Attribute auch, die Beziehung bzw. die ’normale’ Entität”.
Erweiterung des ‘Diego-Leitfadens’
Diego erinnert die Zuhörer an das, was er zuvor gesagt hat:
“Wenn man immer vom fachlichen Datenmodell ausgeht, was grundsätzlich zu empfehlen ist”, sagt Diego, “dann passiert Folgendes: Wenn man ein LDM in ein physisches DV Modell instanziiert, dann wird die Entität ‘automatisch’ zu einem Hub mit einem Satelliten und eine Beziehung zu einem Link ohne Satelliten.”
Die Zuhörer nicken zustimmend.
“Wenn wir unseren Leitfaden auf dieses Informationsmodell anwenden”, fährt Diego fort, “dann wird die assoziative Entität im physischen Datenmodell zu einem Hub und einem Satelliten und nicht zu einem Satelliten am Link, richtig?”
Auch hier nicken die Zuhörer wieder zustimmend. Diego denkt kurz über seine Aussage nach.
“Eine kleine Ergänzung, die 4. Regel, müssen wir im Leitfaden vornehmen.” fährt Diego fort. “Die assoziative Entität mit ihren zwei Beziehungen würde, nach dem aktuellen Leitfaden, zu zwei Links im physischen Datenmodell führen. Aber das würde nicht mit der LDM übereinstimmen.”
“Wie meinst du das, Diego?”
“Eine assoziative Entität und die ‘beiden zugehörigen Beziehungen’ sind eine Beziehung im eigentlichen Sinne. Es handelt sich um eine Beziehung mit beschreibenden Attributen. Das ist der Grund, warum wir Datenmodellierer im LDM den Trick mit der assoziativen Entität brauchen.
Im DV setzen wir diese spezielle Beziehung so um, dass aus der assoziativen Entität ein Link, ein Hub und ein Satellit entstehen.”
“Diego, kannst du uns das bitte noch einmal an einem Beispiel zeigen?”
Mit Hilfe des geänderten Leitfadens entwirft Diego aus dem LDM, das er zuvor gezeigt hat, ein DV-Modell und erläutert dabei seine Vorgehensweise.
“Wie zuvor schon gezeigt, werden aus den Entitäten ‘Employee’ und ‘Department’ jeweils ein Hub (Regel 1) und ein Satellite (Regel 2) physisch modelliert. Die zuvor im LDM vorhandene Beziehung ‘works in’ wurde aufgrund der beschreibenden Attribute zu einer assoziativen Entität ‘Employee Works In Department’ weiterentwickelt.”
Im ‘Diego-Leitfaden’ gelten die folgenden einfachen Regeln:
- Entitätsattribut(e) (Identifizierend - Wie bekomme ich einen und nur einen Datensatz): Wird/werden zum Geschäftsschlüssel im Hub
- Entitätsattribut(e) (beschreiben, messen - Was ist wichtig über eine Entität?): Wird/werden zu Kontextattributen im Satelliten
- Beziehung (Was ist der Grund für eine Beziehung zwischen zwei Entitäten?): Wird zu einem Link
- Assoziative Entität (Beziehung mit beschreibenden Attributen oder eine Many-to-many-Beziehung): Die Entität wird zu einem Hub und einem Satelliten (Regel 1 und 2), die ‘beiden’ Beziehungen werden zu einem Link.
“Dadurch kommt die 4. Regel zur Anwendung. Das physische DV Modell ändert sich dahingehend, dass der bestehende Link zwischen den beiden Hubs um einen weiteren Hub mit einem Satelliten erweitert wird.”
“Die Aufgabe des ‘Hub Employee Works In Department’ und seines Satelliten ist es, die ursprüngliche ‘Many-To-Many’ Beziehung mit ihren beschreibenden Attributen korrekt abzubilden.”
Zum Vergleich zeigt Diego nochmals das bisherige DV-Modell mit der One-To-Many-Beziehung:
Schlussgedanken
“Danke Diego, das ist wirklich hilfreich. So kann man gut erklären, wann Data Vault Link-Satelliten sinnvoll sind.”
“Die 4. Regel gilt übrigens auch für Many-To-Many Beziehungen, unabhängig davon, ob diese Beziehungen beschreibende Attribute haben oder nicht. Denn eine Many-To-Many Beziehung muss letztendlich immer durch eine assoziative Entität aufgelöst werden”, ergänzt Diego.
“Wir als Team sollten diesen Leitfaden in unsere Data Vault Modellierungsregeln aufnehmen”, sind sich alle einig.
Diego ist froh, dass sein Ansatz geschätzt wird. Auf diese Weise kann er den Zuhörern als Mentor und Coach helfen.
Dann fällt Diego ein, dass er noch etwas über Namenskonventionen im LDM erzählen könnte. Aber das ist eine andere Geschichte. Mehr dazu im nächsten Artikel der Serie. Schaut unbedingt wieder vorbei.
So long,
Dirk