Die Verwendung eines Satelliten am Link? Die Diskussion setzt sich mit beschreibenden Daten fort.
In der Diskussion gab es - wie so oft - viele und unterschiedliche Argumente für und gegen die Zuordnung eines Satelliten zu einem Link im Data Vault.
Es wäre hilfreich, diese Argumente in den Kontext einer formaleren Entscheidungshilfe zu stellen, damit Modellierer klar erkennen können, wann eine bestimmte Entscheidung am sinnvollsten ist.
Im ersten Teil dieses zweiteiligen Artikels habe ich den Hintergrund der Diskussion aus der Sicht von Diego Pasión dargestellt, seine Herangehensweise an Entscheidungen in der Modellierung und wie er diese Regeln in seinem ‘Diego Guide’ präsentiert.
Der zweite Teil des Artikels befasst sich mit den beschreibenden Attributen einer Beziehung.
Die beschreibenden Attribute
“Das physische Data Vault (DV) Modell würde sich wieder ändern, wenn sich das hier gezeigte Informationsmodell / logische Datenmodell (LDM), ändern würde”, sagt Diego, der bekannte Coach des DMCE-Teams von FastChangeCo.
Bild 1 - Fachmodell, Mitarbeiter - Department
“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:
[Bild 2 - Informationsmodell, Employee - Employee Works in Department - Department]
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.”
[Bild 3 - Data Vault Datenmodell, Employee - ‘Assoziative Entität’ Link - Department]
“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:
Bild 4 - Data Vault Datenmodell, Mitarbeiter - ‘One-To-Many’-Link - Department
Schlussgedanken
“Danke Diego, das ist wirklich hilfreich. So kann man gut erklären, wann 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
[1] Diego Pasión, Coach, eine fiktive Figur in der fiktiven Welt von FastChangeCoTM.