Eine kompetente Modellierung<\/a> ist wichtig, um das volle Potenzial von Data Vault 2.0<\/a> auszusch\u00f6pfen. Um im Hinblick auf Skalierbarkeit und Performance das Beste aus dem System herauszuholen, muss es zudem auf einer Architektur aufbauen, die vollst\u00e4ndig auf Insert-Only ausgelegt ist. Beim Laden in das Data Vault k\u00f6nnen s\u00e4mtliche Update-Operationen eliminiert und die Ladeprozesse erheblich vereinfacht werden. In this article:<\/p> Daher unterscheidet er sich grundlegend von den verschiedenen Business-Daten, die aus den Quellsystemen stammen und eine gesch\u00e4ftliche Bedeutung haben. Aus diesem Grund muss er f\u00fcr einen gesamten Batch-Ladeprozess generiert werden. Business-Daten, wie beispielsweise G\u00fcltigkeitsdaten, werden in Effectivity-Satelliten gespeichert, die meist mit Link-Entities verbunden sind. Sie liefern Informationen \u00fcber die Beziehungen zwischen Gesch\u00e4ftsobjekten sowie das jeweilige Anfangs- und Enddatum. <\/span><\/p>\n Der zweite technische Zeitstempel ist der Load End Date Timestamp (LEDTS). Wie der LDTS ist auch der LEDTS systemgeneriert und tritt nur in Satellite-Entities auf. Da diese Satelliten delta-basiert sind, gibt es immer einen Datensatz, der das aktuellste Delta darstellt. Der Wert des LEDTS bei diesen Datens\u00e4tzen ist \u00fcblicherweise \u201e9999-12-31\u201c (End of Time) oder NULL. Die folgende Abbildung zeigt den gesamten End-Dating-Prozess, der mit der Verwendung des LEDTS-Attributs einhergeht. Dieser wird nach dem Laden des Satelliten ausgef\u00fchrt (nicht w\u00e4hrenddessen): <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29679″ 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: End dating process for satellites“ 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=“25″][vc_column_text css=““ text_direction=“default“]Die Abbildung verdeutlicht, dass wir den Satelliten mit dem neuen LEDTS-Wert aktualisieren m\u00fcssen, was zulasten der Performance geht. Wie anfangs erw\u00e4hnt, m\u00f6chten wir die LEDTS-Updates eliminieren, um mit einer 100-prozentigen Insert-Only-Architektur<\/a> in Data Vault 2.0 eine h\u00f6here Performance zu erzielen<\/span>.<\/p>\n An dieser Stelle stellt sich die typische Frage, wie das aktuellste Delta in einem Satelliten abgefragt werden kann, wenn wir keinen LEDTS mehr haben. Mittels max(LDTS)? Sicherlich nicht.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40″][vc_column_text css=““ text_direction=“default“]\n Durch die Verwendung von Fensterfunktionen auf dem Hash-Key (Partition) und dem LDTS (Order) k\u00f6nnen Sie das aktuellste Delta identifizieren, das dynamisch berechnet wird. Es gibt verschiedene Fensterfunktionen, die zur Ermittlung des aktuellsten Deltas verwendet werden k\u00f6nnen. Die folgende Tabelle zeigt einige Beispiele f\u00fcr diese Fensterfunktionen. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40″][image_with_animation image_url=“29678″ 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: Examples of window functions“ 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“]Ein Grund f\u00fcr die Existenz des LEDTS in Data Vault ist, dass viele Datenbanken im fr\u00fchen 21. Jahrhundert noch keine Fensterfunktionen unterst\u00fctzten oder daf\u00fcr nicht schnell genug waren.<\/span><\/p>\n Wie bereits im Newsletter vom Oktober 2018 erw\u00e4hnt, besteht der Zweck von PIT-Tabellen darin, Inner Joins mit Equi-Join-Bedingungen zu erm\u00f6glichen. Sie sind jedoch auch der Schl\u00fcssel zu einer reinen Insert-Only-Implementierung von Data Vault 2.0, wodurch weitaus effizientere Ladeprozesse erm\u00f6glicht werden.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40″][vc_column_text css=““ text_direction=“default“]\n Die Implementierung einer Insert-Only-Architektur in Data Vault 2.0 verbessert die Skalierbarkeit und Performance, indem Update-Operationen w\u00e4hrend des Datenladens eliminiert werden. Dieser Ansatz vereinfacht den Ladeprozess und stellt sicher, dass alle Daten\u00e4nderungen als neue Datens\u00e4tze erfasst werden, wodurch die historische Genauigkeit gewahrt bleibt. Durch die Nutzung von Point-in-Time-Tabellen (PIT-Tabellen) k\u00f6nnen Unternehmen die aktuellsten Daten effizient abfragen, ohne auf End-Dating-Techniken angewiesen zu sein, wodurch der Datenabruf und die Datenanalyse weiter optimiert werden. <\/p>\n [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":91,"featured_media":59688,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3948],"tags":[],"class_list":["post-59686","post","type-post","status-publish","format-standard","has-post-thumbnail","category-data-vault"],"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
<\/span>[\/vc_column_text][vc_column_text css=““ text_direction=“default“]Die g\u00e4ngige Implementierung in Data Vault 2.0<\/span><\/h2>\n[\/vc_column_text][vc_column_text css=““ text_direction=“default“]In den g\u00e4ngigen Lademustern gibt es in Data Vault 2.0<\/a> zwei wichtige technische Zeitstempel. Der erste ist der Load Date Timestamp (LDTS). Dieser Zeitstempel stellt kein Business-Datum (Business Date) dar, das aus dem Quellsystem stammt. Stattdessen gibt er Auskunft dar\u00fcber, wann die Daten zum ersten Mal in das Data Warehouse geladen wurden, in der Regel in die Staging Area. <\/span><\/p>\n
Der Vorteil von PIT-Tabellen in Data Vault 2.0<\/span><\/h2>\n[\/vc_column_text][vc_column_text text_direction=“default“]Die Antwort liegt in der Verwendung von Fensterfunktionen (Window Functions) zum Laden Ihrer Point-in-Time-Tabellen (PIT-Tabellen). Wir haben das Thema PIT-Tabellen bereits mit einem Beispiel aus der Versicherungsbranche<\/a> in unserem<\/span> Newsletter<\/span> vom Oktober<\/span> 2018 behandelt. <\/span> 2018. Der Zweck von PIT-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins eliminiert und aus Performancegr\u00fcnden Inner Joins mit Equi-Join-Bedingungen erm\u00f6glicht werden. Wir empfehlen dringend, eine PIT-Tabelle als performantere Alternative zum LEDTS aufzubauen. Die PIT-Tabelle wird mithilfe von Fensterfunktionen erstellt, um das aktuellste Delta im Satelliten zu finden. Sobald sie mit Snapshots der aktuellen Daten erstellt wurde, m\u00fcssen wir den LDTS nicht mehr mit BETWEEN-Bedingungen abfragen. Die zeitliche Historie wird in Form von Snapshots gespeichert und kann mit Equi-Join-Bedingungen auf dem Hash-Key<\/a> und dem LDTS zu den zugeh\u00f6rigen Satelliten abgefragt werden. Da PIT-Tabellen kontinuierlich wachsen, wird empfohlen, Partitionen auf dem Snapshot-Datum zu erstellen. Schlie\u00dflich k\u00f6nnen die (visualisierten) Information-Mart<\/a>-Dimensionen ganz einfach direkt aus der PIT-Tabelle und den zugeh\u00f6rigen Satelliten abgefragt werden.
<\/span><\/p>\nFazit<\/h2>\n