Historisierung von Daten in der Versicherungswirtschaft

Dieser Beitrag beschreibt die Historisierung von Daten in der Versicherungswirtschaft. Dort müssen vergangenheitsbezogenen Vertragsänderungen z. B. für die Prüfung von Deckungsansprüchen bei Schadenmeldungen herangezogen werden. Zu diesem Zweck muss der rechtliche Stand der Bestandsdaten zu einem beliebigen Zeitpunkt wiederhergestellt werden können.

Dieses Festhalten der zeitlichen Entwicklung der Daten wird auch temporale Datenhaltung genannt.

Der Änderungsbaum der Daten entsteht durch das Aufzeichnen der Änderungen in Gültigkeitsabschnitten (Beginn- und Endzeitpunkte, Gültigkeitszeit). Diese Abschnitte können auf einer Zeitlinie aneinandergereiht dargestellt werden und bilden damit einen Pfad zum Zeitpunkt t1.

Historisierung mit einem Pfad

Historisierung mit einem Pfad (© Frank Rahn)

Die rückwirkende Änderung eines alten Zustands der Daten erzeugt eine neue Zeitlinie als Zweig zum Zeitpunkt t2.

Historisierung mit einem Zweig

Historisierung mit einem Zweig (© Frank Rahn)

Keine Historisierung von Daten (Ohne Zeitbezug)

In diesem Abschnitt wird der einfachste Fall der Historisierung beschrieben:
Bestandsdaten ohne Historie oder Non-temporal.

Es wird nur der letzte Zustand t2 der Daten zu einem beliebigen Zeitpunkt gespeichert. Der vorletzte Zustand zum Zeitpunkt t1 der Daten wird überschrieben und geht somit endgültig verloren.

Historisierung ohne Pfad

Historisierung ohne Pfad (© Frank Rahn)

Eindimensionale Historisierung von Daten (Abschnittshistorie)

In diesem Abschnitt wird der nächste Fall der Historisierung beschrieben:
Die eindimensionale Historisierung oder Actual Temporal.

Es werden nur die Änderungen der Zustände der Daten in einem einzelnen Pfad gespeichert. Bei einer rückwirkenden Änderung zum Zeitpunkt t2 geht der alte Pfad verloren.

Historisierung mit einem überschriebenen Pfad

Historisierung mit einem überschriebenen Pfad (© Frank Rahn)

Zwischen den Gültigkeitsabschnitten sind Lücken erlaubt, während Überschneidungen nicht erlaubt sind. Somit gilt für einen Zeitpunkt t:

Dieses beschreibt die fachliche Gültigkeit eines Zustandes der Daten. Hierbei reicht in der Regel Tagesgenauigkeit ( DATE) aus.

Bei einer lückenlosen Abschnittshistorie könnte auf das Attribut GUELTIG_BIS verzichtet werden. Aber bei einem relationalen Datenbanksystem sollten die einzelnen Datensätze voneinander unabhängig sein.

Der Schlüssel der Daten setzt sich aus der Id der Daten (z. B. Vertragsnummer) und des Attributs GUELTIG_BIS zusammen.

Das Attribute GUELTIG_BIS wird auch zur Sortierung der Zustandsabfolge der Daten verwendet.

Beispiel der eindimensionalen Historisierung von Daten

Am 03.03. wird ein Versicherungsvertrag angelegt. Dieser Vertrag ist ab dem 01.03. (Vertragsbeginn) unbegrenzt wirksam.

Beispiel: eindimensionale Historisierung

Beispiel: eindimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 100…

In der Spalte STATUS steht N für normal gültiger Datensatz und in der Spalte GUELTIG_BIS wird NULL für unbegrenzt gültig eingetragen.

Am 26.03. wird der Vertrag mit Wirkung zum 01.04. geändert.

Beispiel: eindimensionale Historisierung

Beispiel: eindimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS VERTRAGSATTRIBUTE
1 N 01.03. 01.04. 100…
1 N 01.04. NULL 200…

Am 27.03. wird der Vertrag geändert, diesmal mit Wirkung zum 01.05.

Beispiel: eindimensionale Historisierung

Beispiel: eindimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS VERTRAGSATTRIBUTE
1 N 01.03. 01.04. 100…
1 N 01.04. 01.05. 200…
1 N 01.05. NULL 250…

Am 02.04. wird der Vertrag rückwirkend geändert, diesmal mit Wirkung zum 15.03.

Beispiel: eindimensionale Historisierung

Beispiel: eindimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS VERTRAGSATTRIBUTE
1 N 01.03. 15.03. 100…
1 N 15.03. NULL 300…

Am 02.04. wird der Vertrag mit Wirkung zum 01.06. aufgehoben. Der gelöschte Datensatz existiert über das Löschdatum 01.06. hinaus, damit er ggf. storniert werden kann.

Beispiel: eindimensionale Historisierung

Beispiel: eindimensionale Historisierung (© Frank Rahn)

Für die Löschung wird kein neuer Datensatz geschrieben.

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS VERTRAGSATTRIBUTE
1 N 01.03. 15.03. 100…
1 L 15.03. 01.06. 300…

Im letzten Datensatz wird die Spalte STATUS auf L für gelöscht gesetzt und zusätzlich das Datum in die Spalte GUELTIG_BIS geschrieben.

Die endgültige Löschung des Vertrages geschieht am 02.05. durch einen automatischen Prozess (Batch).

Beispiel: eindimensionale Historisierung

Beispiel: eindimensionale Historisierung (© Frank Rahn)

Auch bei der endgültigen Löschung wird kein neuer Datensatz geschrieben. Der Vertrag wird aus Dokumentationszwecken weiterhin aufbewahrt – somit findet auch keine physische Löschung ( DELETE) in der Datenbank statt.

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS VERTRAGSATTRIBUTE
1 N 01.03. 15.03. 100…
1 E 15.03. 01.06. 300…

Im letzten Datensatz wird nun die Spalte STATUS auf E für endgültig gelöscht gesetzt.

Zweidimensionale Historisierung von Daten (Vollständige Historisierung, Vollprotokollierung)

In diesem Abschnitt wird der letzte Fall der Historisierung beschrieben:
Die zweidimensionale Historisierung oder Bitemporal.

Es werden alle Änderungen der Zustände der Daten in allen Pfaden gespeichert. Die eindimensionale Historisierung ist ein Spezialfall der zweidimensionalen Historisierung.

Historisierung mit einem Zweig

Historisierung mit einem Zweig (© Frank Rahn)

Gegenüber diesem Spezialfall muss zusätzlich eine Aussage über die Gültigkeit eines Zustandes der Daten in der Datenbank (Kenntnisstand, Record Temporal) vorgenommen werden. Auch hier gilt für einen Zeitpunkt t:

Allerdings ist hier eine höhere Genauigkeit ( TIMESTAMP) gefordert, da an einem Tag mehrere Änderungen (zu verschiedenen Zeitpunkten) vorgenommen werden können.

Beispiel der zweidimensionalen Historisierung von Daten

Am 03.03. wird ein Versicherungsvertrag angelegt. Dieser Vertrag ist ab dem 01.03. (Vertragsbeginn) unbegrenzt wirksam.

Beispiel: zweidimensionale Historisierung

Beispiel: zweidimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS KENNTNIS_AB KENNTNIS_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 03.03. 10:00 NULL 100…

In der Spalte STATUS steht N für normal gültiger Datensatz und in der Spalte GUELTIG_BIS sowie KENNTNIS_BIS ist NULL für unbegrenzt gültig eingetragen.

Am 26.03. wird der Vertrag mit Wirkung zum 01.04. geändert. Der neue Zustand des Vertrages überlagern die vorhandenen Zustände. Die nicht überlagerten Teile des Gültigkeitsabschnitts sind gültig.

Beispiel: zweidimensionale Historisierung

Beispiel: zweidimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS KENNTNIS_AB KENNTNIS_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 03.03. 10:00 26.03. 14:30 100…
1 N 01.04. NULL 26.03. 14:30 NULL 200…

In der Spalte GUELTIG_BIS wird in diesem Beispiel immer NULL eingetragen, da keine Änderung zeitlich begrenzt ist und immer unbegrenzt gültig ist.

Am 27.03. wird der Vertrag wieder geändert, diesmal mit Wirkung zum 01.05. Es entsteht eine Treppe.

Beispiel: zweidimensionale Historisierung

Beispiel: zweidimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS KENNTNIS_AB KENNTNIS_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 03.03. 10:00 26.03. 14:30 100…
1 N 01.04. NULL 26.03. 14:30 27.03. 09:15 200…
1 N 01.05. NULL 27.03. 09:15 NULL 250…

Am 02.04. wird der Vertrag rückwirkend geändert, diesmal mit Wirkung zum 15.03.

Beispiel: zweidimensionale Historisierung

Beispiel: zweidimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS KENNTNIS_AB KENNTNIS_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 03.03. 10:00 26.03. 14:30 100…
1 N 01.04. NULL 26.03. 14:30 27.03. 09:15 200…
1 N 01.05. NULL 27.03. 09:15 02.04. 07:30 250…
1 N 15.03. NULL 02.04. 07:30 NULL 300…

Am 02.04. wird der Vertrag abermals mit Wirkung zum 01.06 aufgehoben. Der gelöschte Datensatz existiert auch über das Löschdatum 01.06. weiter, damit er ggf. storniert werden kann.

Beispiel: zweidimensionale Historisierung

Beispiel: zweidimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS KENNTNIS_AB KENNTNIS_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 03.03. 10:00 26.03. 14:30 100…
1 N 01.04. NULL 26.03. 14:30 27.03. 09:15 200…
1 N 01.05. NULL 27.03. 09:15 02.04. 07:30 250…
1 N 15.03. NULL 02.04. 07:30 02.04. 17:45 300…
1 L 01.06 NULL 02.04. 17:45 NULL 300…

Im neuen Datensatz wird die Spalte STATUS auf L für gelöscht gesetzt.

Die endgültige Löschung des Vertrags geschieht am 02.05. durch einen automatischen Prozess (Batch).

Beispiel: zweidimensionale Historisierung

Beispiel: zweidimensionale Historisierung (© Frank Rahn)

Vertragstabelle
ID STATUS GUELTIG_AB GUELTIG_BIS KENNTNIS_AB KENNTNIS_BIS VERTRAGSATTRIBUTE
1 N 01.03. NULL 03.03. 10:00 26.03. 14:30 100…
1 N 01.04. NULL 26.03. 14:30 27.03. 09:15 200…
1 N 01.05. NULL 27.03. 09:15 02.04. 07:30 250…
1 N 15.03. NULL 02.04. 07:30 02.04. 17:45 300…
1 L 01.06 NULL 02.04. 17:45 02.05. 00:00 300…
1 E 01.06. NULL 02.05. 00:00 NULL 300…

Im neuen Datensatz wird die Spalte STATUS auf E für endgültig gelöscht gesetzt.

Nachfolgend eine Liste von weiterführenden Links auf zusätzliche Informationsquellen.

Die Literaturempfehlung

Frank Rahn

Frank Rahn ist Softwarearchitekt. Er unterstützt bei der Konzeption von Softwarearchitekturen mit Java-Technologie. Folge Sie ihm auf Facebook, Twitter oder Google+.

Benötigen Sie Unterstützung? Kontaktieren Sie ihn.

Hat Ihnen dieser Beitrag gefallen? Wir würden uns über Ihren Kommentar freuen! Bitte verwenden Sie Ihren bürgerlichen Namen und eine E-Mail-Adresse mit Gravatar.

Letzte Artikel von Frank Rahn (Alle anzeigen)

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ihr Kommentar wird verschlüsselt an meinen Server gesendet. Weitere Informationen und Widerrufshinweise finden Sie in meiner Datenschutzerklärung.