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. Dazu muss der rechtliche Stand der Bestandsdaten zu einem beliebigen Zeitpunkt rekonstruiert 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 Änderungen eines alten Zustand 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

In diesem Abschnitt wird der einfachste Fall der Historisierung beschrieben:
Bestandsdaten ohne Historie.

Es wird nur der letzte Zustand t2 einer Entität zu einem beliebigen Zeitpunkt gespeichert. Der vorletzte Zustand zum Zeitpunkt t1 einer Entität 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.

Es werden nur die Änderungen der Zustände einer Entität in einem einzelnen Pfad gespeichert. Bei einer rückwirkenden Änderungen 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 Entität. Hierbei reicht in der Regel Tagesgenauigkeit ( DATE) aus.

Bei einer lückenlosen Abschnittshistorie könnte auf das Attribut GUELTIG_BIS verzichtet werden, aber bei relationalen Datenbanksystemen sollten einzelne Entitäten voneinander unabhängig sein.

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

Das Attribute GUELTIG_BIS wird auch zur Sortierung der Zustandsfolge der Entität bestimmt.

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 wieder 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 ein weiteres Mal 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: 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)

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

Es werden alle Änderungen der Zustände einer Entität 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 Entität in der Datenbank (Kenntnisstand) 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 einem Zeitpunkt) 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 neuem 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 neuem 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

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

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