Es gibt einen Spezialfall, in dem sich ein Teil der in einem Link gespeicherten Hub-Referenzen \u00e4ndern kann, ohne eine andere Beziehung zu beschreiben. Dies hat erhebliche Auswirkungen auf die Link-Satelliten. Dar\u00fcber hinaus haben wir bereits im Jahr 2017 die<\/span> Link-Struktur<\/a><\/span> anhand eines Beispiels f\u00fcr ein Data-Vault-Modell in der Bankenbranche<\/a> vorgestellt. Wir haben gezeigt, wie das Modell aussieht, wenn ein Link entweder eine Beziehung oder eine Transaktion zwischen zwei Business-Objekten darstellt. Ein Link kann auch mehr als zwei Hubs miteinander verbinden. Was ist die Alternative zur Driving-Key-Implementierung in Data Vault 2.0<\/a>?<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“25″][vc_column_text css=““ text_direction=“default“] In this article:<\/p> Die folgenden Tabellen veranschaulichen die Beziehung zwischen einem Mitarbeiter und einer Abteilung aus einem Quellsystem.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29672″ image_size=“full“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“100%“ max_width_mobile=“default“][vc_custom_heading text=“Table 1: employee-department relationship“ font_container=“tag:div|text_align:center“ google_fonts=“font_family:Droid%20Serif%3Aregular%2Citalic%2C700%2C700italic|font_style:400%20regular%3A400%3Anormal“][divider line_type=“No Line“ custom_height=“15″][vc_column_text css=““ text_direction=“default“]Das folgende Data-Vault-Modell<\/a> l\u00e4sst sich aus dieser Quellstruktur ableiten. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40″][image_with_animation image_url=“29675″ image_size=“full“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“100%“ max_width_mobile=“default“][vc_custom_heading text=“Figure 1: Data Vault model“ font_container=“tag:div|text_align:center“ google_fonts=“font_family:Droid%20Serif%3Aregular%2Citalic%2C700%2C700italic|font_style:400%20regular%3A400%3Anormal“][divider line_type=“No Line“ custom_height=“20″][vc_column_text css=““ text_direction=“default“]Die Link-Tabelle \u201eEmpl_Dep\u201c wird aus der Tabelle \u201eEmployee\u201c im Quellsystem abgeleitet. Der Driving-Key in diesem Beispiel ist die Employee_Number, da sie der Prim\u00e4rschl\u00fcssel in der Quelltabelle ist und ein Mitarbeiter zur gleichen Zeit nur in einer Abteilung arbeiten kann. Das bedeutet, dass der tats\u00e4chliche Driving-Key im Satelliten des Mitarbeiters \u201elebt\u201c. Wechselt die Abteilung eines Mitarbeiters, entsteht kein zus\u00e4tzlicher Datensatz in der Satellitentabelle des Mitarbeiters, sondern ein neuer in der Link-Tabelle, was v\u00f6llig legitim ist. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40″][image_with_animation image_url=“29674″ image_size=“full“ animation_type=“entrance“ animation=“None“ animation_movement_type=“transform_y“ hover_animation=“none“ alignment=“center“ border_radius=“none“ box_shadow=“none“ image_loading=“lazy-load“ max_width=“100%“ max_width_mobile=“default“][vc_custom_heading text=“Table 2: link data“ font_container=“tag:div|text_align:center“ google_fonts=“font_family:Droid%20Serif%3Aregular%2Citalic%2C700%2C700italic|font_style:400%20regular%3A400%3Anormal“][divider line_type=“No Line“ custom_height=“15″][vc_column_text css=““ text_direction=“default“]Um das aktuellste Delta zu ermitteln, m\u00fcssen Sie dieses aus der Link-Tabelle abfragen und nach dem Driving-Key gruppieren.<\/span><\/p>\n Zusammenfassend l\u00e4sst sich sagen, dass Sie immer einen neuen Link-Hash-Key erhalten, wenn sich ein Business-Key in einer Beziehung \u00e4ndert. Die Herausforderung besteht darin, den Driving-Key zu identifizieren. Hierbei handelt es sich um einen eindeutigen Business-Key (oder eine Kombination von Business-Keys) f\u00fcr die Beziehung zwischen den verbundenen Hubs. Manchmal m\u00fcssen Sie ein zus\u00e4tzliches Attribut hinzuf\u00fcgen, um einen eindeutigen Identifikator zu erhalten. <\/span><\/p>\n Beides stellt ein Problem f\u00fcr Power-User mit Zugriff auf das Data-Vault-Modell dar. Ohne klare Namenskonventionen besteht das Risiko, dass eine GROUP-BY-Anweisung auf mehr Attribute als nur den Driving-Key angewendet wird. Dies w\u00fcrde zu unerwarteten und fehlerhaften Aggregatwerten f\u00fchren, obwohl die Daten selbst korrekt modelliert sind <\/span><\/p>\nDer Driving-Key <\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Eine Beziehung oder Transaktion wird in einem Quellsystem h\u00e4ufig durch eine Kombination von Business-Keys identifiziert. In Data Vault 2.0 wird dies als normaler Link modelliert, der mehrere Hubs verbindet, die jeweils einen Business-Key enthalten. Ein Link enth\u00e4lt auch seinen eigenen Hash-Key<\/a>, der \u00fcber die Kombination aller Business-Keys der Parent-Hubs berechnet wird. Wenn der Link also vier Hubs verbindet und sich ein Business-Key \u00e4ndert, weist der neue Datensatz einen neuen Link-Hash-Key auf. Ein Problem entsteht, wenn zwar vier Business-Keys die Beziehung beschreiben, aber nur drei davon diese eindeutig identifizieren. Wir k\u00f6nnen das Business-Objekt nicht allein anhand des Hash-Keys des Links identifizieren. Dies ist zwar kein Modellierungsfehler, allerdings m\u00fcssen wir bei der Datenabfrage den korrekten Datensatz im zugeh\u00f6rigen Satelliten identifizieren. In Data Vault 2.0 wird dies als Driving-Key bezeichnet. Es handelt sich dabei um einen konsistenten Schl\u00fcssel innerhalb der Beziehung, der im Quellsystem oft dem Prim\u00e4rschl\u00fcssel entspricht. <\/span><\/p>\n