Die Unit of Work ist ein grundlegendes Konzept bei der Data-Vault-Modellierung. Sie beschreibt das Prinzip, alle zusammenh\u00e4ngenden Business Keys aus einem Quellsystem gemeinsam in einer einzigen Link-Struktur zu erfassen. Dadurch wird sichergestellt, dass die in den Rohdaten abgebildeten Beziehungen in Ihrem Raw Data Vault vollst\u00e4ndig und unverf\u00e4lscht erhalten bleiben. <\/p>\n
Stellen Sie es sich wie ein Puzzle vor, bei dem alle Teile zusammengeh\u00f6ren: Wenn Sie die Teile ohne eine klare Strategie f\u00fcr das sp\u00e4tere Zusammensetzen voneinander trennen, riskieren Sie, das urspr\u00fcngliche Gesamtbild zu verlieren \u2013 oder schlimmer noch, ein Bild zu erzeugen, das in der Realit\u00e4t nie existiert hat. <\/p>\n
In this article:<\/p>
Die zentrale Frage aus unserer Data-Vault-Friday-Session lautete:<\/p>\n
\u201eEs w\u00e4re gut, das Thema Unit of Work noch einmal aufzugreifen. Welche Informationen verliere ich, wenn ich breitere Links in kleinere Paare aufteile (DrivingKey -> Key1\/Key2 etc)? Ich kann mir ein technisches Setup vorstellen, bei dem ich mehrere Links und Effectivity Satellites nutze und in der Lage sein sollte, zu jedem beliebigen Zeitpunkt dieselben Ergebnisse zu erzielen\u2026 Welche Informationen gehen genau verloren, wenn ich Links aufteile?\u201c <\/p><\/blockquote>\n
Das Risiko beim Aufteilen von Links: Ein Praxisbeispiel<\/h2>\n
Beginnen wir mit einem einfachen Beispiel, um das Problem zu veranschaulichen:<\/p>\n
Stellen Sie sich eine Beziehung zwischen drei Gesch\u00e4ftsentit\u00e4ten vor \u2013 Customer, Store und Product. Customers betreten Stores und kaufen Products. Wenn Sie diese Beziehung als einen einzelnen Link modellieren, der alle drei Hubs (Customer, Store, Product) umfasst, erhalten Sie ein pr\u00e4zises und unverf\u00e4lschtes Bild dieser Transaktion. <\/p>\n
Nehmen wir nun an, Sie entscheiden sich daf\u00fcr, diesen Link in zwei kleinere Links aufzuteilen:<\/p>\n
\n
- Customer -> Store<\/li>\n
- Customer -> Product<\/li>\n<\/ul>\n
Auf den ersten Blick mag das unproblematisch erscheinen. Wenn Sie jedoch versuchen, den urspr\u00fcnglichen Datensatz durch das Verkn\u00fcpfen (Joinen) dieser beiden Links zu rekonstruieren, erzeugen Sie m\u00f6glicherweise neue Kombinationen, die es in Wirklichkeit nie gegeben hat. Zum Beispiel: <\/p>\n
\n
- Customer A hat Store K besucht und Product X gekauft (valide)<\/li>\n
- Customer A hat Store L besucht (ebenfalls valide), aber wenn Sie dies mit Product X verkn\u00fcpfen, entsteht eine falsche Beziehung: Customer A hat Product X in Store L gekauft (was tats\u00e4chlich nie stattgefunden hat).<\/li>\n<\/ul>\n
Dieses Ph\u00e4nomen, bei dem durch Joins neue, k\u00fcnstliche Datens\u00e4tze generiert werden, f\u00fchrt zu Dateninkonsistenzen<\/strong>. Sie f\u00fchren damit Beziehungen ein, die im Quellsystem nicht existierten. Genau darin liegt das wesentliche Risiko beim Aufteilen von Links. <\/p>\n
Der Jedi-Test: \u00dcberpr\u00fcfung Ihres Modells<\/h2>\n
Um solche Probleme zu vermeiden, empfiehlt Michael die Anwendung des sogenannten Jedi-Tests<\/strong> (Star-Wars-Fans d\u00fcrfen sich freuen!).<\/p>\n
Der Jedi-Test ist eine einfache, aber wirkungsvolle Validierungsmethode: Versuchen Sie, den urspr\u00fcnglichen Quelldatensatz aus Ihrem Data-Vault-Zielmodell exakt zu rekonstruieren. Wenn Sie die urspr\u00fcnglichen Zeilen genau reproduzieren k\u00f6nnen \u2013 nicht mehr und nicht weniger \u2013, ist Ihr Modell optimal. Entstehen dabei zus\u00e4tzliche oder fehlende Zeilen, liegt ein Modellierungsproblem vor. <\/p>\n
Dieser Test stellt sicher, dass Ihre Links korrekt modelliert sind und beim Aufteilen weder Daten verloren gehen noch inkorrekte Beziehungen entstehen.<\/p>\n
Driving Keys und Unit of Work<\/h2>\n
Ein Szenario, bei dem das Aufteilen von Links unausweichlich zu Problemen f\u00fchrt, ist der Einsatz von Driving Keys<\/strong>. Driving Keys sind eine Teilmenge von Business Keys, die eine Beziehung eindeutig identifizieren. <\/p>\n
Michael erl\u00e4utert, dass die Aufteilung von Komponenten eines Driving Keys fast immer das Prinzip der Unit of Work verletzt. Wenn Sie einen Driving Key zerlegen, gef\u00e4hrden Sie die Integrit\u00e4t Ihrer Beziehungsdaten. Daher sollten alle Hub-Referenzen aus derselben Quelle stets gemeinsam in einem Unit-of-Work-Link innerhalb des Raw Data Vault abgebildet werden. <\/p>\n
Er betont, dass er selbst zwar kein Verfechter von Driving Keys ist (und von einer gewissen \u201eHassliebe\u201c spricht), es jedoch Anwendungsf\u00e4lle gibt, in denen sie notwendig sind. Wenn dies der Fall ist, m\u00fcssen Sie zwingend darauf achten, sie nicht aufzuteilen.<\/p>\n
Die sicherste L\u00f6sung: Links im Raw Data Vault zusammenhalten<\/h2>\n
Die bew\u00e4hrte Best Practice lautet: Belassen Sie alle Hub-Referenzen aus derselben Quelltabelle zusammen in einem einzigen Link \u2013 dem Unit-of-Work-Link<\/strong>. <\/p>\n
Dieser Ansatz garantiert, dass die vollst\u00e4ndige Beziehung exakt so erfasst wird, wie sie im Quellsystem vorlag. Sie k\u00f6nnen diese Beziehungen sp\u00e4ter im Business Vault<\/strong> jederzeit aufteilen, wenn dort Transformationen und zus\u00e4tzliche Gesch\u00e4ftsregeln greifen. Der Raw Data Vault hingegen dient als Ihre vertrauensw\u00fcrdige, unver\u00e4nderliche Single Source of Truth. <\/p>\n
Indem Sie die Unit of Work im Raw Data Vault wahren, beugen Sie Dateninkonsistenzen vor und gew\u00e4hrleisten, dass Sie nachgelagert jederzeit korrekte und verl\u00e4ssliche Datenstrukturen aufbauen k\u00f6nnen.<\/p>\n
Was tun, wenn ein Link aufgeteilt werden muss?<\/h2>\n
Gelegentlich erfordern technische Restriktionen die Aufteilung eines Links. Beispielsweise wenn: <\/p>\n
\n
- Ihr Datenbanksystem die Anzahl der Hub-Referenzen limitiert, die in einen zusammengesetzten Index aufgenommen werden k\u00f6nnen.<\/li>\n
- Deskriptive Daten auf unterschiedlichen Granularit\u00e4tsebenen vorliegen, die einen breiten Link unpraktikabel machen.<\/li>\n<\/ul>\n
In solchen F\u00e4llen empfiehlt Michael folgende Vorgehensweisen:<\/p>\n
\n
- Behalten Sie den Unit-of-Work-Link als Basis-Link bei.<\/li>\n
- Erstellen Sie zus\u00e4tzliche Links, um spezifische Granularit\u00e4tsanforderungen abzubilden (z. B. Customer -> Product, Customer -> Store, etc.).<\/li>\n
- Wenn Sie Links aufteilen, stellen Sie sicher, dass alle fehlenden Beziehungen ebenfalls erfasst werden. Wenn Sie beispielsweise Customer -> Store and Customer -> Product, modellieren, ben\u00f6tigen Sie gegebenenfalls auch Store -> Product, um das vollst\u00e4ndige Beziehungsgeflecht zu erhalten.<\/li>\n<\/ol>\n
Diese erg\u00e4nzenden Links erm\u00f6glichen es Ihnen, den urspr\u00fcnglichen Datenbestand bei Bedarf exakt wiederherzustellen, erh\u00f6hen jedoch die Systemkomplexit\u00e4t. Mehr Links bedeuten mehr Entit\u00e4ten, mehr Joins und potenziell geringere Abfragegeschwindigkeiten. Daher betont Michael die Bedeutung eines schlanken Modells und r\u00e4t dazu, Links wann immer m\u00f6glich zusammenzuhalten. <\/p>\n
Effizienz\u00fcberlegungen<\/h2>\n
Unter Performance-Gesichtspunkten f\u00fchren weniger Links mit mehr Hub-Referenzen in der Regel zu schnelleren Abfragen. Sie reduzieren die Anzahl der Joins und vereinfachen das Datenmodell. Mehr Links erh\u00f6hen dagegen die Komplexit\u00e4t und die Fehleranf\u00e4lligkeit. <\/p>\n
Die Abw\u00e4gung ist daher eindeutig: Einfachheit und Effizienz durch einen Unit-of-Work-Link stehen der Flexibilit\u00e4t durch zus\u00e4tzliche Links gegen\u00fcber \u2013 letzteres jedoch auf Kosten h\u00f6herer Komplexit\u00e4t und operationeller Risiken.<\/p>\n
Fazit und Empfehlungen<\/h2>\n
Zusammenfassend gilt:<\/p>\n
\n
- Halten Sie Hub-Referenzen aus derselben Quelle im Raw Data Vault stets gemeinsam in einem Unit-of-Work-Link<\/strong>.<\/li>\n
- F\u00fchren Sie den Jedi-Test<\/strong> durch, um auszuschlie\u00dfen, dass Datenbeziehungen verloren gehen oder f\u00e4lschlicherweise generiert werden.<\/li>\n
- M\u00fcssen Links getrennt werden, dokumentieren und verwalten Sie diese sorgf\u00e4ltig und stellen Sie sicher, dass s\u00e4mtliche notwendigen Beziehungen erhalten bleiben (auch solche, die auf den ersten Blick nicht offensichtlich sind).<\/li>\n
- Verlagern Sie komplexe Aufteilungen und Transformationen in den Business Vault, da Anpassungen dort vorgenommen werden k\u00f6nnen, ohne den gesamten Datensatz neu laden zu m\u00fcssen.<\/li>\n<\/ul>\n
Eine sauber strukturierte Unit of Work stellt sicher, dass Ihr Data Vault ein robustes und verl\u00e4ssliches Fundament f\u00fcr Analytics, Reporting und Data-Science-Initiativen bleibt.<\/p>\n[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][vc_column_text]\n
Video ansehen<\/h2>\n[\/vc_column_text][vc_video link=“https:\/\/youtu.be\/tK3_i5kAhcA“ align=“center“ css=““][divider line_type=“No Line“ custom_height=“60″][vc_column_text]\n","protected":false},"excerpt":{"rendered":"
[vc_row type=“in_container“ full_screen_row_position=“middle“ column_margin=“default“ column_direction=“default“ column_direction_tablet=“default“ column_direction_phone=“default“ scene_position=“center“ text_color=“dark“ text_align=“left“ row_border_radius=“none“ row_border_radius_applies=“bg“ overflow=“visible“ overlay_strength=“0.3″ gradient_direction=“left_to_right“ shape_divider_position=“bottom“ bg_image_animation=“none“][vc_column column_padding=“no-extra-padding“ column_padding_tablet=“inherit“ column_padding_phone=“inherit“ column_padding_position=“all“ column_element_direction_desktop=“default“ column_element_spacing=“default“ desktop_text_alignment=“default“ tablet_text_alignment=“default“ phone_text_alignment=“default“ background_color_opacity=“1″ background_hover_color_opacity=“1″ column_backdrop_filter=“none“ column_shadow=“none“…<\/p>\n","protected":false},"author":3,"featured_media":60617,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3987],"tags":[],"class_list":["post-60745","post","type-post","status-publish","format-standard","has-post-thumbnail","category-data-vault-friday"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t