Historisierung von Daten in der Versicherungswirtschaft

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:

GUELTIG_AB <= t < GUELTIG_BIS

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.

PRIMARY KEY (ID, GUELTIG_AB)

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

ORDER BY GUELTIG_BIS DESC

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:

KENNTNIS_AB <= t < KENNTNIS_BIS

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.

Alternative: Event-Sourcing

Eine Alternative bietet das Event-Sourcing (ES). Bei diesem Verfahren wird nicht der komplette Zustand eines fachlichen Geschäftsobjektes (Entität) festgehalten. Sondern es werden alle Änderungen (Events) einer Entität aufbewahrt. Die Änderungen werden chronologisch ihres Auftretens gespeichert und bilden den Event-Stream dieser Entität. Dadurch entsteht die gewünschte Historie der Entität (Event-Log und zusätzlich ein Audit-Log).

Event

Ein Event ist immutable. Aus diesem Grund sind in einer Persistenz nur lesende und schreibende Zugriffe von Nöten. Auf die destruktiven Zugriffe löschen und ändern wird verzichtet. Bei den destruktiven Zugriffen gehen die vorherigen Zustände verloren.

Ein Event wird in der Regel mit einigen Attributen angereichert:

  • Wann aufgetreten (Gültig ab)
  • Wann bemerkt (Kenntnis ab)
  • Wer hat es bearbeitet
  • Betroffene Geschäftslogik
  • Type des Events

Diese Art der Speicherung ist extrem schnell, da nur neue Datensätze angelegt bzw. Datensätze selektiert werden. Für den lesenden Zugriff können die Verfahren Caching oder Snapshots verwendet werden. Das Caching hält den Event-Stream vor und der Snapshot speichert den Zustand einer Entität. Die Snapshots können regelmäßig gebildet werden. Z. B. nach einer Anzahl von neuen Events oder zu definierten Zeitpunkten (z. B. Monatsende).

Event-Stream

Die folgenden Aktionen sind auf dem Event-Stream möglich:

Complete Rebuild

Der aktuelle Zustand einer Entität wird aus dem chronologischen Abarbeiten des kompletten Event-Streams neu erstellt. Der so gewonnene Zustand sollte als Snapshot gespeichert werden.

Event Reply

Ausgehen von einem Snapshot werden alle neueren Events chronologisch angewendet und der aktuelle Zustand der Entität gebildet.

Temporal Query

Es wird ein Snapshots zu einem Zeitpunkt gebildet, in dem der Event-Stream entweder vom Anfang oder ab einem Snapshots bis zum Zeitpunkt abgearbeitet wird.

Reversing Event

Durch ein Reversing-Event kann ein vorheriger fehlerhafter Event wieder rückgängig gemachte werden. Dazu müssen Event aber einen Unterschied beschreiben und nicht ein Ergebnis. In Form des Differenzansatzes: „Erhöhe um 10“ statt „Setze auf 110“.

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

Die Literaturempfehlung

Frank Rahn
Letzte Artikel von Frank Rahn (Alle anzeigen)
0 Kommentare

Hinterlasse einen Kommentar

An der 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. Ihr Kommentar wird verschlüsselt an meinen Server gesendet. Erforderliche Felder sind mit * markiert.

Weitere Informationen und Widerrufshinweise finden Sie in meiner Datenschutzerklärung.