This blog has moved to
http://blog.matthias-reining.com

Die bestehenden Artikel bleiben vorerst alle bei blogspot. Neue Artikel veröffentliche ich allerdings nur noch auf http://blog.matthias-reining.com

Mittwoch, 23. Februar 2011

Historisierungskonzepte


Der folgende Artikel ist der Rohentwurf für einen Magazin-Artikel (Rohentwurf := die Marketing-Abteilung hat noch keine Schleife darüber gedreht ;-) )


Historisierungskonzepte
- Datenhistorisierung in Versicherungsbestandsystemen -

Eines der wesentlichen Aspekte eines Bestandsystems ist die Datenspeicherung.
Ein Versicherungsvertrag und alle darauf ausgeführten Änderungen müssen revisionssicher gespeichert werden. Jede Änderung bewirkt dabei, dass es eine neue Version des Vertrages gibt. Es handelt sich hierbei um einen neuen Vertragsstand. Ein wesentliches Merkmal eines Vertragstandes ist der Zeitpunkt ab wann dieser Stand seine Gültigkeit erreicht.

Bei diesen Vertragsstand-Versionen spricht man von den Historien eines Vertrags. Hierbei gibt es unterschiedliche Möglichkeiten wie die Persistierung von Vertragsständen in einem relationalen Datenbank Management System (RDBMS) realisiert werden kann.
Die Hersteller von Standard-Bestandsystem haben meist eine eigene Art der Historisierung. Im Normalfall ist diese aber immer an einen bestimmten Typ von Historisierung angelehnt. Auch bei individual entwickelten Systemen lässt sich die Historienführung meist auf eine übergreifende Kategorie zurückführen.
Zwei gängige Varianten zur Speicherung von zeitbezogenen Daten sind die Uni-Temporale und Bi-Temporale Datenspeicherung. Neben diesen beiden gibt es weitere Möglichkeiten, allerdings sind diese eher untypisch für Versicherungsbestandssysteme.
Im Folgenden werden die beiden Varianten anhand von Beispieldatensätzen vorgestellt.
Wir gehen hierzu von einem einfachen Datensatz in einem RDBMS aus:

--PK--

Ohne Zeitbezug
id
data


|-------     PK    -------|

Uni-Temporal
id
bd1
be1
data


|--------------         PK        --------------|

Bi-Temporal
id
bd1
be1
bd2
be2
data

PK :=        Primary Key. Hiermit wird der Datensatz eindeutig identifiziert
id :=         Identifiziert einen Datensatz ohne zeitlichen Bezug
bd1 :=      Beginn Datum der  ersten Zeitperiode
be1 :=      Ende Datum der ersten Zeitperiode
bd2 :=      Beginn Datum der  zweiten Zeitperiode
be2 :=      Ende Datum der zweiten Zeitperiode
data :=    Daten

Diese theoretischen Grundlagen werden nun im Folgenden mit Versicherungsdaten in Bezug gebracht:

Ohne Zeitbezug (Non-Temporal)
Dieser Punkt ist nur der Vollständigkeit wegen aufgeführt. Es handelt sich hierbei um eine normale Art der Persistierung ohne Zeitbezug.
Id
kennzeichen
vk
vk sb
4711
M-XY 678
0
null
3216
K - AB 320
1
500

Die Tabelle beinhaltet zwei Versicherungsobjekte.
Bei einem Kfz Produkt gibt es natürlich weit mehr Daten, um das Ganz aber übersichtlich zu gestalten wurden hier nur die Daten für das Beispiel aufgeführt.
In der Tabelle gibt es einmal ein Kfz mit dem Kennzeichen M-XY 678 (id=4711) ohne Vollkasko Deckung (vk = 0).
Weiterhin ist ein zweites Fahrzeug enthalten (K-AB 320) (id=3216), dass ein Vollkasko Deckung (vk=1) enthält mit einem Selbstbehalt (sb) von 500 EUR.
Eine zeitliche Historisierung der Daten ist so nicht möglich!

Uni-Temporal

Nun wird ein Gültigkeitszeitraum zu den Kfz Policen hinzugefügt.
Mit der Einführung der Spalten „gueltigAb“ und „gueltigBis“ wird ein zeitlicher Bezug hergestellt, von wann bis wann die Police in dieser Form gültig ist/war.
Id
gueltigAb
gueltigBis
kennzeichen
vk
vk sb
4711
01.01.2011
31.12.2011
M-XY 678
0
null
3216
08.02.2011
31.12.2011
K-AB 320
1
500

Das Kfz M-XY 678 (id=4711) ist versichert vom 01.01.2011 bis zum 31.12.2011.
Das Fahrzeug K-AB 320 (id=3216) wurde zum 08.02.2011 neu versichert. Die Kalenderjahrpolice geht bis zum Jahresende (31.12.2011).
Änderungen
Der Versicherungsnehmer des Kfz M-XY 678 will seine Police um eine Vollkasko-Deckung erweitern. Sein Sohn wird zum 19.02.2011 Volljährig und nutzt als Fahranfänger ab diesem Zeitpunkt ebenfalls das Auto. Um sich gegen die Reparaturkosten bei einem selbstverschuldeten Unfall abzusichern, erweitert er seinen bestehenden Versicherungsvertrag ab den 19.02.2011 um eine Vollkasko-Deckung mit 300EUR Selbstbeteiligung.
Id
gueltigAb
gueltigBis
kennzeichen
vk
vk sb
4711
01.01.2011
19.02.2011
M-XY 678
0
null
4711
19.02.2011
31.12.2011
M-XY 678
1
300
3216
08.02.2011
31.12.2011
K-AB 320
1
500

Mit der Einführung der Daten gueltigAb und gueltigBis kann nun festgestellt werden von wann bis wann welche Version einer Police gültig war.

Deckungsprüfung
Wenn der Versicherungsnehmer für sein Kfz (id=4711; M-XY 678) nun einen Vollkasko-Schaden zum 22.02.2011 meldet, kann die Schadenabteilung die Deckung mit folgenden Select prüfen:
SELECT * FROM kfz_police
 WHERE id=4711
   AND ‚22.02.2011‘ BETWEEN gueltigAb AND gueltigBis
Als Ergebnis bekommt man den ersten Datensatz, der eine Vollkasko Deckung enthält. Der Schaden des Versicherten ist gedeckt.

Bi-Temporal

Neben dem Gültigkeitszeitraum ist bei einer Versicherungspolice weiterhin der Wirksamkeitszeitraum  von Interesse.
Der Wirksamkeitszeitraum  beschreibt den Zeitraum von wann bis wann der Datensatz mit dem entsprechenden Gültigkeitszeitraum wirksam bzw. bekannt war.
Mit der Einführung der Spalten „wirkVon“ und „wirkBis“ wird ein zeitlicher Bezug hergestellt, von wann bis wann der Policenstand dem Versicherer bekannt ist/war.
Id
gueltigAb
gueltigBis
wirkVon
wirkBis
kennzeichen
vk
vk sb
4711
01.01.2011
31.12.2011
22.10.2010
31.12.9999
M-XY 678
0
null
3216
08.02.2011
31.12.2011
04.02.2011
31.12.9999
K-AB 320
1
500

Das Kfz M-XY 678 (id=4711) wurde am 22.10.2010 in der Abwerbephase für den Zeitraum 01.01.2011 bis zum 31.12.2011 versichert.
Für das Fahrzeug K-AB 320 (id=3216) wurde am 04.02.2011 eine neue Versicherung mit Beginn 08.02.2011 abgeschlossen.
Das Datum 31.12.9999 bedeutet fachlich „bis auf weiteres“.

Änderungen

Anbei die gleiche Änderung von oben:
Der Versicherungsnehmer des Kfz M-XY 678 schreibt, mit etwas Verspätung, der Versicherung am 27.02.2011 ein Fax und gibt an, dass eine Vollkasko-Deckung mit 300EUR Selbstbeteilung ab dem  19.02.2011 in dem Vertrag mit aufgenommen werden soll.

Id
gueltigAb
gueltigBis
wirkVon
wirkBis
kennzeichen
vk
vk sb
4711
01.01.2011
19.02.2011
22.10.2010
27.02.2011
M-XY 678
0
null
4711
19.02.2011
31.12.2011
27.02.2011
31.12.9999
M-XY 678
1
300
3216
08.02.2011
31.12.2011
04.02.2011
31.12.9999
K-AB 320
1
500

Mit den Daten wirkVon und wirkBis ist es nun möglich festzugstellen, welcher Stand dem Versicherer wann bekannt war.

Deckungsprüfung
Wenn der Versicherungsnehmer für sein Kfz (id=4711; M-XY 678) nun einen Vollkasko-Schaden zum 22.02.2011 meldet, kann die Schadenabteilung die Deckung wieder mit folgenden Select prüfen:
SELECT * FROM kfz_police
 WHERE id=4711
   AND ‚22.02.2011‘ BETWEEN gueltigAb AND gueltigBis
Als Ergebnis bekommt man den ersten Datensatz, der eine Vollkasko Deckung enthält. Der Schaden des Versicherten ist auf den ersten Blick gedeckt.
Mit folgenden Select kann nun auch geprüft werden ob eventuell ein Versicherungsbetrug versucht wurde:
SELECT * FROM kfz_police
 WHERE id=4711
   AND ‚22.02.2011‘ BETWEEN wirkAb AND wirkBis
Dieser Select liefert zeigt, dass zum Schadentermin dem Versicherer noch kein Vollkasko Deckung bekannt war.
Jetzt sollte die Schadenabteilung noch mal genauer recherchieren.

Ausblick:

Dieser Artikel hat nun im Kleinen gezeigt, wie eine Historienführung funktioniert.
Folgende Sachverhalte sollten im Rahmen der Einführung eines Historienkonzeptes auch immer noch beachtet werden:
·         Objekt-Beziehungen: 1:1 und 1:n Tabellen, mit Datum versehen.
·         Große Vertragskonstrukte: Rahmenvertrag, Einzelverträge
·         Flottenkonzepte: Rahmenvertrag, Objektklassen, Einzelverträge
·         Korrekturen von Vertragsständen zum gleichen GülitigAb Datum.
·         Wie wird mit Uhrzeiten umgegangen (24:00Uhr oder 0:00 Uhr)
·         Bearbeitung von rückwirkenden Änderungen
·        

Fazit:

Viele Versicherungssysteme arbeiten mit einer Historisierung, die an einer Uni-Temporale-Historisierung angelehnt ist. Die Wirksamkeitskomponente wird dann oft versucht über die Bearbeitungsdokumentation (BDok) abzudecken. Spätestens im Schaden bzw. Leistungsfall ist dann oft eine automatisierte Prüfung nicht mehr so einfach möglich.
Eine Bi-Temporale Historisierung ist im Versicherungsumfeld immer zu empfehlen!