Datenhistorisierung / -versionierung

Es gibt verschiedene Verfahren, die angewandt werden können, um ältere Versionen einer Datenbank als Historie zu dokumentieren. Beispielsweise können in regelmäßigen Abständen Kopien der gesamten Datenbank gespeichert werden, sodass die genaue Version an Tag X eingesehen werden kann. Dies nimmt allerdings viel Speicherplatz in Anspruch, da auch unveränderte Datensätze ständig kopiert und gespeichert werden.

Im Folgenden soll ein alternatives, effizienteres Verfahren erklärt werden, bei dem nur die Änderungen an der Datenbank dokumentiert werden, die nach regelmäßigen Abgleichen erkannt werden. Dazu werden den veränderten Datensätzen Zeiträume zugeordnet, in denen sie in der Original-Datenbank existiert haben. Somit entsteht ein historischer Änderungsverlauf, der jede Veränderung verzeichnet, die an der Datenbank getätigt wird. Benötigt werden die Quellabfrage, die historisiert werden soll, und eine Zieldatei, in der der Änderungsverlauf festgehalten wird.

Periodisches Verfahren zur Historisierung

Bei dem grundlegenden Verfahren des Moduls werden die Datensätze aus der Quelltabelle (z. B. Kundendaten) in eine Zieltabelle übertragen und dort mit den zusätzlichen Angaben valid_from_dt und invalid_from_dt ergänzt. Diese geben an, wann der jeweilige Datensatz in der Quelltabelle hinzugefügt wurde und bis wann er dort existiert.

Beispiel: Historie der ersten Version

Quelltabelle nach historischem Abgleich am 01. Januar 2000

person_no name first_name date_of_birth
1 Monroe Marilin 01.06.1926
2 Dean James 08.02.1931

Zieltabelle nach historischem Abgleich

person_no valid_from invalid_from name first_name date_of_birth
1 01.01.2000 31.12.9999 Monroe Marilin 01.06.1926
2 01.01.2000 31.12.9999 Dean James 08.02.1931

Zu festgelegten Zeitpunkten wird die aktuelle Quelltabelle mit der Version verglichen, die zum letzten festgelegten Zeitpunkt erfasst wurde. Die Granularität des Abgleichs wird vom Anwender definiert und kann beliebig häufig sein (tages-, sekunden-, millisekundengenau). Werden beim Abgleich keine Änderungen festgestellt, enthält die Zieldatei die selben Datensätze wie die Quelltabelle (plus die zusätzlichen Informationen valid_from etc.). Wenn das System beim regelmäßigen Abgleich Veränderungen erfasst, werden diese in die Zieltabelle geschrieben. Diese Inkongruenzen zwischen den verglichenen Versionen werden folgendermaßen in der Zieltabelle dokumentiert:

  • Wird ein hinzugefügter Datensatz in der Quelltabelle festgestellt, fügt das Modul auch in der Zieltabelle einen entsprechenden Datensatz hinzu.
  • Wird ein bereits bestehender Datensatz verändert, wird dieser in der Zieltabelle als veraltete Version markiert, indem die Angabe invalid_from auf den Zeitpunkt gesetzt wird, an dem die Änderung erkannt wurde. Die Gültigkeit des Datensatzes ist also exklusive der angegeben Zeitangabe zu verstehen, weil der exakte Zeitpunkt der Änderung nicht ermittelbar ist, sondern nur der Zeitpunkt, an dem die Veränderung erkannt wird. Außerdem wird ein neuer Datensatz in der Zieltabelle hinzugefügt, der die aktuelle Version beschreibt, die die neue Information enthält und ab diesem Zeitpunkt aktiv ist (z.B. neue Kontaktdaten, Korrektur bestehender Daten). Diese übernimmt also den Zeitpunkt, an dem die Veränderung erfasst wurde als valid_from-Wert. Somit werden Datensatz-Versionen in der Zieltabelle an zugehörige Gültigkeitsperioden geknüpft, zu denen sie in der Quelltabelle existiert haben.

Beispiel: Korrektur Vorname

Quelltabelle nach historischem Abgleich am 08. Januar 2000

person_no name first_name date_of_birth
1 Monroe Marilyn 01.06.1926
2 Dean James 08.02.1931

Zieltabelle nach historischem Abgleich

person_no valid_from invalid_from name first_name Date of Birth
1 01.01.2000 08.01.2000 Monroe Marilin 01.06.1926
1 08.01.2000 31.12.9999 Monroe Marilyn 01.06.1926
2 01.01.2000 31.12.9999 Dean James 08.02.1931

Das Verfahren bei Löschungen von Datensätzen in der Quelltabelle hängt davon ab, ob diese Löschungen erkannt und dokumentiert werden sollen oder nicht. Soll das System Löschungen erfassen, gibt es zwei verschiedene Methoden, um diese in der Zieltabelle zu dokumentieren. So ergeben sich drei Verfahrensweisen, die je nach Einstellung angewandt werden können.

  1. Keine Dokumentation von Löschungen

    Bei diesem Modus kann das System keine Löschungen erkennen oder dokumentieren. Ein typisches Anwendungsbeispiel sind Buchungsbelege, die nicht gelöscht werden können.

    Falls ein Datensatz gelöscht wird, bleibt die Zieltabelle unverändert.

    Beispiel: In inkrementeller Quelle fehlt Person No. 2

    Quelltabelle am 09. Januar 2000

    person_no name first_name date_of_birth
    1 Monroe Marilyn 01.06.1926

    Unveränderte Zieltabelle

    person_no valid_from invalid_from name first_name Date of Birth
    1 01.01.2000 08.01.2000 Monroe Marilin 01.06.1926
    1 08.01.2000 31.12.9999 Monroe Marilyn 01.06.1926
    2 01.01.2000 31.12.9999 Dean James 08.02.1931
  2. Dokumentation von Löschungen durch Terminierung

    Wird bei diesem Modus ein Datensatz in der Quelltabelle gelöscht, erhält der entsprechende Datensatz in der Zieltabelle als invalid_from-Wert den Zeitpunkt, an dem die Löschung erfasst wurde. Somit wird die Löschung lediglich durch die Terminierung der letzten aktiven Version eines Datensatzes gekennzeichnet.

    Beispiel: Löschung von Person No. 2 ohne Löschkennzeichen

    Quelltabelle am 10. Januar 2000

    person_no name first_name date_of_birth
    1 Monroe Marilyn 01.06.1926

    Zieltabelle nach historischem Abgleich

    person_no valid_from invalid_from name first_name date_of_birth
    1 01.01.2000 08.01.2000 Monroe Marilin 01.06.1926
    1 08.01.2000 31.12.9999 Monroe Marilyn 01.06.1926
    2 01.01.2000 10.01.2000 Dean James 08.02.1931
  3. Dokumentation von Löschungen durch Löschkennzeichen

    Die Löschung wird hier zusätzlich durch das Hinzufügen eines als gelöscht markierten Datensatzes in der Zieltabelle dokumentiert. Die Zieltabelle führt eine Spalte, die die Information gelöscht: ja/nein beinhaltet. Bei einer Löschung wird die letzte aktive Version auf den Erfassungszeitpunkt terminiert (invalid_from) und als nicht gelöscht markiert (is_deleted: no), da sie bis zu diesem Zeitpunkt aktiv ist. Zusätzlich wird eine Kopie der letzten aktiven Version als neuer Datensatz in der Zieltabelle erstellt, der ab dem Erfassungszeitpunkt der Löschung gültig ist und als gelöscht markiert ist (is_deleted: yes).

    Beispiel: Löschung von Person No. 2 mit Löschkennzeichen

    Quelltabelle am 10. Januar 2000

    person_no name first_name date_of_birth
    1 Monroe Marilyn 01.06.1926

    Zieltabelle nach historischem Abgleich

    person_no valid_from invalid_from name first_name date_of_birth is_deleted
    1 01.01.2000 08.01.2000 Monroe Marilin 01.06.1926 N
    1 08.01.2000 31.12.9999 Monroe Marilyn 01.06.1926 N
    2 01.01.2000 10.01.2000 Dean James 08.02.1931 N
    2 10.01.2000 31.12.9999 Dean James 08.02.1931 Y