Point-in-Time-Tabellen (PIT-Tabellen) sind n\u00fctzlich, wenn Sie Daten aus dem Raw Vault abfragen, bei denen mehrere Satellites an einen Hub oder Link angebunden sind:[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29684″ 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 including PIT (logical)“ 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=“30″][vc_column_text css=““ text_direction=“default“] In this article:<\/p> Im obigen Beispiel sind mehrere Satellites f\u00fcr den Hub \u201eCustomer\u201c und den Link im Diagramm dargestellt. Dies ist eine sehr h\u00e4ufige Situation bei Data-Warehouse-L\u00f6sungen, da sie Daten aus mehreren Quellsystemen integrieren. Diese Situation erh\u00f6ht jedoch die Komplexit\u00e4t bei der Abfrage von Daten aus dem Raw Data Vault. Das Problem entsteht, weil \u00c4nderungen an den in den Quellsystemen gespeicherten Business-Objekten nicht gleichzeitig erfolgen. Stattdessen wird ein Business-Objekt, wie z. B. ein Kunde (eine versicherte Person), zu einem bestimmten Zeitpunkt in einem der vielen Quellsysteme aktualisiert, zu einem anderen Zeitpunkt in einem anderen System usw. Beachten Sie, dass die Point-in-Time-Tabelle (PIT) bereits an den Hub angeh\u00e4ngt ist, wie durch das Band dargestellt. <\/span><\/p>\n \u00c4nderungen gingen zu unterschiedlichen Zeiten ein, die nicht miteinander in Beziehung standen. Die meisten Aktualisierungen wurden beim Abschluss einer Versicherung vorgenommen, betrafen jedoch nicht alle operativen Systeme gleichzeitig. Folglich wirkte sich eine \u00c4nderung nicht auf alle Satellites aus. Stattdessen betraf sie nur denjenigen Satellite, der die \u00c4nderung abbilden sollte (was ein Vorteil ist). <\/span><\/p>\n Beim Erstellen eines Data Marts aus diesen Rohdaten wird die Abfrage von Kundendaten zu einem bestimmten Stichtag kompliziert: Die Abfrage muss die Kundendaten so zur\u00fcckgeben, wie sie gem\u00e4\u00df dem Delta-Prozess des Data Warehouses am ausgew\u00e4hlten Datum aktiv waren. Um dieses Ziel zu erreichen, sind Outer-Join-Abfragen mit komplexer Zeitbereichslogik erforderlich. Bei mehr als drei Satellites an einem Hub oder Link wird dies kompliziert und langsam. Der bessere Ansatz ist die Verwendung von Equi-Join-Abfragen, um die Daten aus dem Raw Data Vault abzurufen. Um dies zu erreichen, wird in der Data-Vault-2.0-Modellierung<\/a> ein spezieller Entit\u00e4tstyp verwendet: Point-in-Time-Tabellen (PIT). Diese Entit\u00e4t wird immer dann in ein Data-Vault-2.0-Modell integriert, wenn die Abfrageperformance f\u00fcr einen bestimmten Hub oder Link und die zugeh\u00f6rigen Satellites zu gering ist. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29683″ 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 2: PIT table structure“ 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=“30″][vc_column_text css=““ text_direction=“default“]] Da die Daten in einer PIT-Tabelle systemgeneriert sind und nicht aus einem Quellsystem stammen, m\u00fcssen sie nicht auditiert werden und befinden sich nicht im Raw Vault. Daher kann ihre Struktur so angepasst werden, dass sie berechnete Spalten (Computed Columns) enth\u00e4lt. <\/span><\/p>\n Point-in-Time-Tabellen<\/span> dienen zwei Zwecken:<\/span><\/p>\n Eine PIT-Tabelle erstellt Snapshots von Daten f\u00fcr Stichtage, die von den nachgelagerten Datenkonsumenten definiert wurden. Beispielsweise ist es \u00fcblich, t\u00e4glich den aktuellen Zustand der Daten bereitzustellen. Um diesen Anforderungen gerecht zu werden, enth\u00e4lt die PIT-Tabelle das Datum und die Uhrzeit des Snapshots in Kombination mit dem Business-Key als eindeutigen Schl\u00fcssel der Entit\u00e4t (ein Hash-Key<\/a>, der diese beiden Attribute enth\u00e4lt und in Abbildung 2 als \u201eCustomerKey\u201c bezeichnet wird). F\u00fcr jede dieser Kombinationen enth\u00e4lt die PIT-Tabelle die Load-Dates und die entsprechenden Hash-Keys aus jedem Satellite, die am besten mit dem Snapshot-Datum \u00fcbereinstimmen.<\/p>\n Die Point-in-Time-Tabelle fungiert wie ein von der Abfrage verwendeter Index und liefert Informationen \u00fcber die aktiven Satellite-Eintr\u00e4ge pro Snapshot-Datum. Das Ziel besteht darin, so viel Join-Logik wie m\u00f6glich zu materialisieren, um am Ende einen Inner Join mit ausschlie\u00dflichen Equi-Join-Bedingungen zu erhalten. Dieser Join-Typ ist auf den meisten (wenn nicht allen) relationalen Datenbankservern die performanteste Join-Variante. Um die Performance der PIT-Tabelle zu maximieren und gleichzeitig den Speicherbedarf gering zu halten, ist in jedem von der Point-in-Time-Tabelle referenzierten Satellite nur ein einziger Ghost-Record erforderlich. Dieser Ghost-Record wird verwendet, wenn im referenzierten Satellite kein Datensatz aktiv ist, und dient als Fallback f\u00fcr unbekannte oder NULL-Werte. Durch die Verwendung des Ghost-Records k\u00f6nnen NULL-Pr\u00fcfungen im Allgemeinen vermieden werden, da die Join-Bedingung immer auf einen aktiven Datensatz in der Satellite-Tabelle verweist: entweder auf einen tats\u00e4chlichen Datensatz, der zum angegebenen Snapshot-Datum aktiv ist, oder auf den Ghost-Record. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][image_with_animation image_url=“29682″ 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: Example of PIT table“ 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=“30″][vc_column_text css=““ text_direction=“default“]Die obige Tabelle (Tabelle 1) zeigt eine versicherte Person mit historischen Datenst\u00e4nden vom 8. und 9. Oktober 2018. Am 8. Oktober gab es f\u00fcr diesen Kunden keinen Datensatz im Rechtsschutzversicherungs-Satellite. Aus diesem Grund sind sowohl der Hash-Key als auch der Load-Date-Zeitstempel NULL. F\u00fcr eine bessere Abfrageperformance verweisen diese NULL-Werte auf den Ghost-Record in der zugeh\u00f6rigen Satellite-Tabelle, um die Suche nach einem nicht existierenden Datensatz zu vermeiden. <\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][vc_column_text css=““ text_direction=“default“]Wenn Kundendaten nur f\u00fcr einen bestimmten Gesch\u00e4ftsbereich gel\u00f6scht werden m\u00fcssen und personenbezogene Daten (PII) als Business-Key dienen, m\u00fcssen lediglich der Link-Eintrag und die beschreibenden Attribute im spezifischen Satellite gel\u00f6scht werden. Der Aktivit\u00e4tsverlauf bleibt weiterhin verf\u00fcgbar, kann f\u00fcr analytische Zwecke genutzt werden und l\u00e4sst sich nicht mehr auf den konkreten Kunden zur\u00fcckf\u00fchren. Der zus\u00e4tzliche Vorteil dieses \u201eBusiness Splits\u201c zeigt sich, wenn beim L\u00f6schen von Kundendaten nur ein einzelner Gesch\u00e4ftsbereich betroffen ist \u2013 beispielsweise wenn die Gesch\u00e4ftsbereiche zu verschiedenen Tochtergesellschaften geh\u00f6ren und nur die Kfz-Versicherungsdaten gel\u00f6scht werden m\u00fcssen. Denken Sie au\u00dferdem daran, dass das L\u00f6schen des reinen Business-Keys (unter Beibehaltung des Hash-Keys) nicht zur DSGVO<\/a>-Konformit\u00e4t f\u00fchrt (und ohnehin nicht dem Data-Vault-2.0<\/a>-Standard entspricht, da der Business-Key in Link-Tabellen verwendet wird). Der Hash-Key in Data Vault 2.0 wird nicht zur Verschl\u00fcsselung von Daten verwendet, sondern dient reinen Performancegr\u00fcnden. Der Schl\u00fcssel in den Links und den gesch\u00e4ftsorientierten Hubs, von denen hier die Rede ist, kann nicht zur\u00fcckgerechnet werden, da es sich um einen reinen Surrogatschl\u00fcssel handelt. Sobald ein Kunde die vollst\u00e4ndige L\u00f6schung seiner Daten w\u00fcnscht, da er oder sie kein Kunde mehr in einem Ihrer Gesch\u00e4ftsbereiche ist, l\u00f6schen Sie den Datensatz auch aus dem Haupt-Hub. <\/span><\/p>\n Andernfalls k\u00f6nnen Sie Ihre Daten nach dem L\u00f6schen der personenbezogenen Daten (PII) sofern kein zus\u00e4tzlicher k\u00fcnstlicher Schl\u00fcssel f\u00fcr den Kunden existiert nicht mehr mit einem Objekt (einem Ankerpunkt) verkn\u00fcpfen, was sie in vielen F\u00e4llen unbrauchbar macht.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“30″][vc_column_text css=““ text_direction=“default“]\n Der Zweck von Point-in-Time-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins eliminiert und Inner Joins mit Equi-Join-Bedingungen (f\u00fcr die beste Performance) erm\u00f6glicht werden. Dar\u00fcber hinaus verbessern Point-in-Time-Tabellen die Partitionierung und erm\u00f6glichen eine vollst\u00e4ndige Skalierbarkeit von Star-Schemas (die vollst\u00e4ndig virtualisiert sein sollten) auf dem Data Vault. Zudem m\u00fcssen Endanwender nicht alle Satellite-Tabellen miteinander verkn\u00fcpfen, sondern verbinden nur eine einzige Tabelle mit einem Business-Objekt, was die Komplexit\u00e4t von Ad-hoc-Abfragen erheblich reduziert. <\/span>[\/vc_column_text][\/vc_column][\/vc_row]\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":91,"featured_media":59545,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3948],"tags":[],"class_list":["post-59542","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\u00dcber Point-in-Time-Tabellen<\/h2>\n
Vereinfachung der Kombination mehrerer Deltas zu verschiedenen \u201ePoints in Time\u201c<\/h2>\n
Reduzierung der Join-Komplexit\u00e4t aus Performancegr\u00fcnden mit Point-in-Time-Tabellen<\/h2>\n
Fazit<\/span><\/h2>\n