Wie verwendet man Point-in-Time-Tabellen (PIT) in der Versicherungsbranche?

Punkt-zu-Zeit-Tabellen sind nützlich bei der Abfrage von Daten aus dem Raw Vault, die mehrere Satelliten auf einem Hub oder einer Verbindung haben:

Über Point In Time Tables Tabellen

Im obigen Beispiel gibt es mehrere Satelliten auf dem Hub Customer und Link, die im Diagramm enthalten sind. Dies ist eine sehr häufige Situation für data warehouse-Lösungen, da sie Daten aus mehreren Quellsystemen integrieren. Allerdings erhöht diese Situation die Komplexität bei der Abfrage der Daten aus dem Raw Data Vault. Das Problem entsteht, weil die Änderungen an den in den Quellsystemen gespeicherten Geschäftsobjekten nicht gleichzeitig erfolgen. Stattdessen wird ein Geschäftsobjekt, z. B. ein Kunde (eine versicherte Person), in einem der vielen Quellsysteme zu einem bestimmten Zeitpunkt aktualisiert, dann in einem anderen System zu einem anderen Zeitpunkt usw. Beachten Sie, dass die Point-in-Time-Tabelle (PIT) bereits mit dem Hub verbunden ist, wie durch das Band angezeigt wird. Die Änderungen wurden zu verschiedenen Zeitpunkten vorgenommen, die nicht miteinander zusammenhängen. Die meisten Aktualisierungen wurden bei Abschluss einer Versicherung hinzugefügt, betrafen aber nicht alle operativen Systeme zur gleichen Zeit. Folglich wirkte sich eine Änderung nicht auf alle Satelliten aus. Stattdessen betraf sie nur den Satelliten, für den die Änderung gelten sollte (was ein Vorteil ist).

Beim Aufbau eines Data Marts aus diesen Rohdaten wird die Abfrage der Kundendaten zu einem bestimmten Datum kompliziert: Die Abfrage sollte die Kundendaten so zurückgeben, wie sie gemäß dem data warehouse-Delta-Verfahren zum ausgewählten Datum aktiv waren. Um dieses Ziel zu erreichen, sind Outer-Join-Abfragen mit komplexer Zeitbereichsbehandlung erforderlich. Bei mehr als drei Satelliten an einem Knotenpunkt oder einer Verbindung wird dies kompliziert und langsam. Der bessere Ansatz ist die Verwendung von Equal-Join-Abfragen zum Abrufen der Daten aus dem Raw Data Vault. Um dies zu erreichen, wird ein spezieller Entitätstyp in Data Vault 2.0 ModellierungPunkt-zu-Zeit-Tabellen (PIT). Diese Entität wird in ein Data Vault 2.0-Modell aufgenommen, wenn die Abfrageleistung für einen bestimmten Hub oder Link und die umliegenden Satelliten zu gering ist.

Da die Daten in einer PIT-Tabelle vom System berechnet werden und nicht aus einem Quellsystem stammen, sind die Daten nicht zu prüfen und befinden sich nicht im Raw Vault, so dass die Struktur so geändert werden kann, dass sie berechnete Spalten enthält.

Punkt-zu-Punkt-Tabellen dienen zwei Zwecken:

Vereinfachen Sie die Kombination mehrerer Deltas zu verschiedenen "Zeitpunkten".

Eine PIT-Tabelle erstellt Schnappschüsse von Daten für Daten, die von den vorgelagerten Datenkonsumenten angegeben werden. So ist es beispielsweise häufig üblich, täglich den aktuellen Stand der Daten zu melden. Um diesen Anforderungen gerecht zu werden, enthält die PIT-Tabelle das Datum und die Uhrzeit des Snapshots in Kombination mit dem Geschäftsschlüssel als eindeutigen Schlüssel der Entität (a Hash-Schlüssel einschließlich dieser beiden Attribute, die als KundenSchlüssel in Abbildung 2). Für jede dieser Kombinationen enthält die PIT-Tabelle die Ladedaten und die entsprechenden Hash-Schlüssel von jedem Satelliten, der am besten mit dem Schnappschussdatum übereinstimmt.

Reduzieren Sie die Komplexität von Joins aus Leistungsgründen mit Point-in-Time-Tabellen

Die Point-in-Time-Tabelle ist wie ein Index, der von der Abfrage verwendet wird und Informationen über die aktiven Satelliteneinträge pro Snapshot-Datum liefert. Ziel ist es, so viel von der Verknüpfungslogik wie möglich zu materialisieren und am Ende eine innere Verknüpfung mit nur gleichwertigen Verknüpfungsbedingungen zu erhalten. Dieser Join-Typ ist auf den meisten (wenn nicht sogar allen) relationalen Datenbankservern die leistungsfähigste Version des Join. Um die Leistung der PIT-Tabelle zu maximieren und gleichzeitig den Speicherbedarf gering zu halten, ist nur ein Ghost-Datensatz in jedem von der Point-in-Time-Tabelle verwendeten Satelliten erforderlich. Dieser Ghost-Datensatz wird verwendet, wenn in dem referenzierten Satelliten kein Datensatz aktiv ist, und dient als der unbekannte oder NULL-Fall. Durch die Verwendung des Ghost-Datensatzes können NULL-Prüfungen im Allgemeinen vermieden werden, da die Verknüpfungsbedingung immer auf einen aktiven Datensatz in der Satellitentabelle verweist: entweder auf einen tatsächlichen Datensatz, der zum gegebenen Snapshot-Datum aktiv ist, oder auf den Ghost-Datensatz.

Die obige Tabelle (Tabelle 1) zeigt eine versicherte Person mit eingefrorenen Datenständen, einen vom 8. und einen vom 9. Oktober 2018. Am 8. Oktober gab es keinen Datensatz für diesen Kunden im Rechtsschutzversicherungssatelliten. Aus diesem Grund sind sowohl der Hash-Schlüssel als auch der Zeitstempel des Ladedatums NULL. Um die Abfrageleistung zu verbessern, werden diese NULL-Werte auf den Geisterdatensatz in der zugehörigen Satellitentabelle verwiesen, um zu vermeiden, dass ein Datensatz gesucht wird, der nicht existiert.

Wenn Kundendaten nur für ein Unternehmen gelöscht werden müssen und PII-Informationen als Geschäftsschlüssel verwendet werden, müssen nur der Link-Eintrag und die beschreibenden Attribute in dem spezifischen Satelliten gelöscht werden. Die Aktivitätshistorie ist weiterhin verfügbar, kann für analytische Zwecke verwendet werden und ist nicht auf den Kunden selbst zurückzuführen. Der zusätzliche Vorteil dieser "Geschäftsaufteilung" besteht darin, dass bei der Löschung von Kundendaten nur ein Geschäft betroffen ist, d.h. jedes Geschäft kommt aus verschiedenen Niederlassungen, und nur die Kfz-Versicherungsdaten gelöscht werden müssen. Außerdem ist zu beachten, dass die Löschung nur des Geschäftsschlüssels (und die Beibehaltung der Hash Key) nicht dazu führt, dass GDPR Einhaltung (und erfüllt nicht die Data Vault 2.0 Standard, da der Business Key in Verbindungstabellen verwendet wird). Die Hash Key in Data Vault 2.0 wird nicht zur Verschlüsselung von Daten verwendet, sondern aus Leistungsgründen. Der Schlüssel in den Links und den Business Driven Hubs, um die es hier geht, kann nicht zurückgerechnet werden, da es sich um einen vollständigen Surrogatschlüssel handelt. Sobald der Kunde vollständig gelöscht werden soll, da er kein Kunde mehr in einem Ihrer Geschäfte ist, löschen Sie den Datensatz auch aus dem Haupt-Hub.

Andernfalls, wenn es keinen zusätzlichen künstlichen Schlüssel für den Kunden gibt, können Sie nach dem Löschen von PII-Daten Ihre Daten nicht an ein Objekt (einen Ankerpunkt) zurückbinden, was sie (in vielen Fällen) nutzlos macht.

Schlussfolgerung

Der Zweck von Point-in-Time-Tabellen besteht darin, die Abfrageleistung zu verbessern, indem äußere Joins eliminiert und innere Joins mit gleichwertigen Join-Bedingungen ermöglicht werden (beste Leistung). Außerdem verbessern Point-in-Time-Tabellen die Partitionierung und ermöglichen die volle Skalierbarkeit von Sternschemata (die vollständig virtualisiert werden sollten) auf dem Data Vault. Darüber hinaus müssen Endbenutzer nicht alle Satellitentabellen verknüpfen, sondern nur eine Tabelle für ein Geschäftsobjekt, was die Abfragekomplexität bei Ad-hoc-Abfragen reduziert.

Updates und Support erhalten

Bitte senden Sie Anfragen und Funktionswünsche an [email protected]. 

Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.

Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.