Watch the Video
Snapshot-basierte Bridge Table für Link und Effectivity Satellite
Willkommen zu einer weiteren Ausgabe von Data Vault Friday! Heute widmen wir uns dem Konzept einer snapshot-basierten Bridge Table und konzentrieren uns dabei insbesondere auf deren Einsatz in Szenarien mit Links und Effectivity Satellites. Dieser Ansatz hilft uns, komplexe Beziehungen zwischen Business Objects im Zeitverlauf zu verwalten, Beziehungsänderungen nachzuvollziehen und eine lückenlose historische Sicht zu bewahren. In diesem Artikel untersuchen wir Lösungen für drei zentrale Fragen:
- Wie mit einer Beziehung umzugehen ist, die an Tag 2 im Vergleich zu Tag 1 entfällt
- Wie geänderte Beziehungen zwischen Tag 1 und Tag 2 für denselben Key verwaltet werden
- Wie sich ein Business Object (A3) an Tag 2 einbinden lässt, wenn keine Beziehung zu einem Objekt in B besteht
In this article:
- Das Data-Vault-Modellierungsbeispiel verstehen
- Erstellung des Links und des Effectivity Satellites
- Aufbau der snapshot-basierten Bridge Table
- Umgang mit fehlenden Daten und Wiederherstellung von Beziehungen
- Einbindung von A3 in die Bridge Table an Tag 2
- Vermeidung kartesischer Produkte und weitere Best Practices
- Fazit
Das Data-Vault-Modellierungsbeispiel verstehen
In unserem Beispiel nutzen wir zwei Quellen, die jeweils ein anderes Business Object (A und B) repräsentieren. Business Object A liegt als statischer Datensatz vor, während Business Object B über drei Tage hinweg dynamische Beziehungen zu A aufweist. Jeder Tag bringt Änderungen in diesen Beziehungen mit sich, wobei einzelne Einträge wegfallen oder sich verschieben. Unsere Aufgabe besteht darin, diese Änderungen effizient in einer snapshot-basierten Bridge Table abzubilden.
Untersuchung der Beziehungsänderungen
Gehen wir die über drei Tage hinweg beobachteten Änderungen im Detail durch:
- Tag 1: B1 steht in Beziehung zu A1, B2 zu A2 und B3 zu A3.
- Tag 2: Die Beziehungen ändern sich. B1 steht nun in Beziehung zu A2, B2 zu A1 und B3 entfällt.
- Tag 3: Im Vergleich zu Tag 2 treten keine weiteren Änderungen auf.
Unser Ziel ist es, diese Beziehungen mithilfe eines Effectivity Satellites und einer Bridge Table so zu dokumentieren, dass wir ihren exakten Zustand für jeden einzelnen Stichtag historisch korrekt abfragen können.
Erstellung des Links und des Effectivity Satellites
Der erste Schritt zur Erfassung dieser Beziehungen besteht darin, eine Link-Tabelle zu erstellen, die eine eindeutige (distinct) Liste aller Beziehungen zwischen den Business Objects enthält. Links sollten keine zusätzlichen Metadaten wie etwa Gültigkeitszeiträume enthalten, da dies spätere Abfragen unnötig verkompliziert und die Abfrage-Performance beeinträchtigen kann. In unserem Beispiel erfasst die Link-Tabelle jede eindeutige Kombination von A- und B-Keys, speichert jedoch weder Start- noch Enddaten.
Als Nächstes erstellen wir einen Effectivity Satellite. Diese Tabelle erweitert den Link, indem sie Beginn und Ende jeder Beziehung über Zeitstempel sowie ein „is_active“-Flag speichert, um den jeweiligen Status jeder Beziehung anzuzeigen. Mithilfe dieser Tabelle lässt sich lückenlos nachvollziehen, wann eine Beziehung beginnt, sich ändert oder endet. In der Praxis stellt sich das wie folgt dar:
- Einträge an Tag 1: Alle Beziehungen (B1-A1, B2-A2, B3-A3) sind als aktiv gekennzeichnet.
- Einträge an Tag 2: Neue Beziehungen (B1-A2 und B2-A1) kommen hinzu und werden als aktiv markiert, während vorherige Beziehungen (B1-A1 und B2-A2) auf inaktiv gesetzt werden. B3-A3 entfällt vollständig.
Aufbau der snapshot-basierten Bridge Table
Sobald der Effectivity Satellite eingerichtet ist, können wir eine Bridge Table aufbauen, die die aktiven Beziehungen für jeden Tag in Form eines Snapshots festhält. Diese Tabelle liefert eine Point-in-Time-Sicht auf die Beziehungen genau so, wie sie an einem bestimmten Tag bestanden haben. Sehen wir uns den Aufbau der Bridge Table an:
Snapshot für Tag 1
Der Snapshot für Tag 1 spiegelt die Ausgangsbeziehungen wider und übernimmt alle zu diesem Zeitpunkt aktiven Datensätze aus dem Effectivity Satellite. An Tag 1 sind B1-A1, B2-A2 und B3-A3 durchgängig aktiv.
Snapshot für Tag 2
Im Snapshot für Tag 2 verbleiben lediglich die Beziehungen B1-A2 und B2-A1 als aktiv, während B3-A3 nicht mehr berücksichtigt wird. Durch die Filterung auf ausschließlich aktive Einträge bildet der Snapshot den Zustand an Tag 2 exakt ab.
Snapshot für Tag 3
Der Snapshot für Tag 3 ist identisch mit dem von Tag 2, da keine weiteren Änderungen erfolgt sind. Die aktiven Beziehungen B1-A2 und B2-A1 bleiben unverändert bestehen.
Dieses Vorgehen gewährleistet einen transparenten Audit-Trail über sämtliche Beziehungsänderungen und -löschungen. Der tägliche Snapshot gibt den jeweiligen Status quo präzise wieder, ohne redundante Daten zu erzeugen.
Umgang mit fehlenden Daten und Wiederherstellung von Beziehungen
Eine zentrale Stärke des Effectivity Satellites liegt in der Fähigkeit, reaktivierte Beziehungen sauber abzubilden. Wird beispielsweise die Beziehung B1-A1 an Tag 4 wiederhergestellt, fügen wir im Effectivity Satellite neue Zeilen hinzu, markieren die zuvor aktive Kombination (B1-A2) als inaktiv und aktivieren B1-A1 erneut. Diese dynamische Struktur federt das Entstehen, Wegfallen und Wiederauftreten von Beziehungen im Zeitverlauf flexibel ab.
Einbindung von A3 in die Bridge Table an Tag 2
Eine typische Herausforderung besteht darin, Business Objects wie A3 an Tag 2 einzubinden, obwohl an diesem Tag keine Beziehung zu einem Objekt in B vorliegt. Im Data-Vault-Umfeld wird dies üblicherweise in nachgelagerten Abfragen oder Joins auf Reporting-Ebene gelöst – und nicht direkt in der Bridge Table.
Wenn Sie von Objekt A ausgehen und einen Left Join auf die Bridge Table durchführen, beziehen Sie sämtliche Datensätze aus A ein – selbst diejenigen ohne Entsprechung in B. Dadurch ist sichergestellt, dass nicht verknüpfte Objekte in den Ergebnissen erscheinen, wobei die zugehörigen B-Attribute als NULL oder optional über einen definierten Platzhalter abgebildet werden.
Vermeidung kartesischer Produkte und weitere Best Practices
Beim Einsatz einer Bridge Table gilt es unbedingt zu verhindern, dass unerwünschte kartesische Produkte entstehen, da diese das Datenvolumen bei Aggregationen massiv aufblähen können. Prüfen Sie daher stets die Kardinalität der Beziehungen (z. B. 1:1 oder n:m), um sicherzustellen, dass Joins ausschließlich über die erforderlichen Keys ausgeführt werden. Der Driving Key, der die Beziehungen in der Link-Tabelle verankert, muss dabei im Mittelpunkt stehen – insbesondere bei n:m-Beziehungen.
Diese Best Practice garantiert höchste Präzision sowie optimale Performance bei der Datenaggregation und schützt vor verfälschten Reporting-Ergebnissen.
Fazit
Snapshot-basierte Bridge Tables sind in der Data-Vault-Modellierung ein leistungsfähiges Instrument, um veränderliche Beziehungen zu steuern und historische Snapshots nachvollziehbar festzuhalten. Durch das strukturierte Zusammenspiel von Links, Effectivity Satellites und Bridge Tables schaffen wir einen verlässlichen, auditierbaren Pfad für alle Datenänderungen im Zeitverlauf. Wie gezeigt, ermöglicht uns dieser Ansatz, Datenlücken zu überbrücken, Beziehungen zu reaktivieren und eine künstliche Datenaufblähung zu verhindern. Das Ergebnis sind performante und stabile Datenmodelle.
Wenn Sie Unterstützung bei Vorlagen für Bridge Tables oder Effectivity Satellites wünschen, können Sie sich jederzeit gerne an mich wenden. Ich hoffe, dass diese Erläuterung wertvolle Klarheit über den Einsatz von Bridge Tables in Data Vault geschaffen hat. Seien Sie auch beim nächsten Mal wieder dabei, wenn wir neue Einblicke teilen, und reichen Sie Ihre Fragen gerne vorab ein!

