Da war sie wieder, die lebhafte Diskussion über die Verwendung eines Link-Satelliten. 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 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.
Im ersten Teil dieses zweiteiligen Artikels 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. Der zweite Teil befasst sich mit den bitemporalen Aspekten im Zusammenhang mit diesen Entscheidungen.
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.Satelliten an Links sind technisch möglich und werden in der Data-Vault-Literatur traditionell immer wieder beschrieben, z.B. um den Kontext einer Unit of Work (UOW) aufzunehmen.
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 Link-Satelliten hitziger werden oder er begründet, warum es ‘per se keine’ Link-Satelliten geben kann.
Diego zeigt in diesen 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.
Bild 1 - Fachmodell, Mitarbeiter - Department
“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 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 DV 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”
Bild 2 - Data Vault Datenmodell, Mitarbeiter - Link - Department
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.
Bild 3 - Data Vault Datenmodell, Mitarbeiter - ‘One-To-Many’-Link - Department
Und die bitemporale Historisierung?
“Das physische Data Vault Datenmodell würde sich wieder ändern, wenn sich das Informationsmodell, das LDM, ändert”, merkt Diego an.
“Das kann eine fachliche Historisierung (eine bitemporale Historisierung) sein oder wie bereits erwähnt weitere beschreibende Attribute auf der Relation. Meiner Meinung nach muss das anders gelöst werden. Ein Beispiel wäre, wenn die Relation im obigen Datenmodell zwischen ‘Mitarbeiter’ und ‘Abteilung’ folgendes beschreibende Attribut 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.”
Wie Diego damit umgeht und wie sein Leitfaden dafür erweitert wird, ist Gegenstand des 2. Teils dieses Blogartikels.
So long,
Dirk
[1] Diego Pasión, Coach, eine fiktive Figur in der fiktiven Welt von FastChangeCoTM.