Historisierung  – eines der meist diskutiertesten Themen im Umfeld von Data Warehouse und Datenmodellierung. Richtig kompliziert wird das Thema, wenn nicht nur eine Zeitdimension chronologiebestimmend für die Bildung von Historienketten ist, sondern weitere dazu kommen. Zum Beispiel ein fachliches Wirksamkeitsdatum und / oder ein DWH Ladezeitpunkt. Man spricht dann von bi-temporaler Historisierung bzw. tri-temporaler Abgrenzung. Ich möchte in diesem blog Artikel jedoch nicht in die Esotherik temporaler Datenbankforschung abtauchen, sondern anhand nachvollziehbarer Beispiele zeigen, wie es geht.

Begriffe & Festlegungen

Zunächst ist es ganz wichtig Begrifflichkeiten zu klären, um nicht die berühmten Äpfel mit den bekannten Birnen zu vergleichen.

Tupel-Timestamping

Versieht man jeden Datensatz einer Tabelle mit einer Zeitinformation, dann wird dadurch angegeben, wann der Datensatz und damit die dadurch repräsentierte Aussage in der Realität (d.h. in der operativen Datenbank) gültig ist, war bzw. bekannt wurde oder sein wird. Die Änderung eines einzigen Attributwerts dieses Datensatzes führt zur Erzeugung eines neuen Datensatzes mit veränderten Attributwerten. Das Tupel-Timestamping wird auch Datensatz-Zeitstempelung genannt. Im folgenden wird davon ausgegangen, dass das Verfahren der Datensatz-Zeitstempelung angewendet wird (und nicht etwa die Attribut-Zeitstempelung).

Zeitdimensionen

Beschreibende Eigenschaften von Geschäftsobjekten werden in der Datenmodellierung Attribute (die Spalten einer relationalen Datenbank) genannt, wobei die Geschäftsobjekte selbst durch Entitäten (die Tabellen einer relationalen Datenbank) beschrieben werden. Attribute können unterschiedliche Datentypen haben. Attribute, die Zeitangaben speichern, nennt man Zeitattribute. Sie sind meist vom Datentyp DATE oder TIMESTAMP.

Unter den Zeitattributen unterscheidet man zwischen zwei Typen:

1. Zeitattribute, die eine kontextbezogene Bedeutung haben wie zum Beispiel
   ANLAGE_DATUM, UNFALL_DATUM.
2. Zeitattribute, die eine chronologiebestimmende Bedeutung haben. Sie dienen der Beschreibung der Gültigkeit von Objektzuständen oder ihrer Änderungszeitpunkte. Sie sind kontextunabhängig. Diese Attribute zählen zu den Historisierungszeitdimensionen. Beispiele:
   • GUELTIG_AB (Bsp. für den Startzeitpunkt der fachlichen Gültigkeit)
   • BEARB_DAT (Bsp. für den Startzeitpunkt dertechn. Änderungszeitpunkt)

DEFINITION

Chronologiebestimmende Zeitattribute sind unabhängig vom fachlichen Kontext der Tabelle. Fachliche und technische Gültigkeiten sind chronologiebestimmende Zeitattribute

Die folgenden Kapitel erklären die für die Historisierung wichtigsten Zeitdimensionen.

Technische Gültigkeit

Die technische Gültigkeit oder „Transaction-Time“ beschreibt den Zeitpunkt, zu dem der Objektzustand in der Datenbank persistiert oder logisch gelöscht wurde. Die logische Löschung der Daten bedeutet, dass der Zustand logisch nicht mehr existent ist, jedoch zum Zweck der Nachweisbarkeit und Nachvollziehbarkeit physisch noch vorhanden ist.

DEFINITION

Es gilt folgende Semantik für die technische Gültigkeit:

1. Die technische Gültigkeit wird von Endanwendern weder bestimmt noch erfasst. Sie wird durch das Datenbanksystem bei der Speicherung des Objektzustandes ermittelt (meist durch einen Aufruf der Systemzeit des Servers, z.B. via current_timestamp). Es gibt keine Möglichkeit, die Werte des Zeitstempels für die Transaction-Time durch den Benutzer zu beeinflussen.
2. Um die Löschung eines Objektzustandes zu dokumentieren wird nicht nur der Erstellungszeitpunkt, sondern auch der Ersetzungszeitpunkt erfasst. Hierdurch ergibt sich zusammen mit dem Erstellungszeitpunkt das technische Gültigkeitsintervall.
3. Die Transaction-Time Zeitintervalle der Zustände eines Objekts sind überlappungsfrei und im Zeitraum ab Erstellung des ersten Objektzustandes bis zur seiner logischen Löschung lückenlos.

Synonyme für „technische Gültigkeit“: „Transaction-Time“, „Bearbeitungszeit“, „Updatetime“

Beispiel einer „Transaction-Time“ Tabelle:

Eine Tabelle, die neben den fachlichen Attributen auch die technische Änderungshistorie enthält, ist eine Transaction-Time Tabelle. Die chronologiebestimmenden Zeitattribute der Transaction-Time Tabelle werden im Folgenden ERSTELLT_AM und ERSETZT_AM genannt. Die Werte der Transaction-Time Zeitattribute sind vom Datentyp TIMESTAMP. Um die Darstellung zu vereinfachen, werden in den Beispieltabellen jedoch nur Datumswerte angezeigt.

BKey	FATT *	Erstellt_am	Ersetzt_am
4711	01	31.12.1997	22.12.1998
4711	02	22.12.1998	31.12.9999

Fußnote:
* FATT = Fachliche(s) Attribut(e)

Dabei ist ‚9999-12-31‘ das maximal mögliche Datum, dieser Wert ist allerdings abhängig vom verwendeten Datenbanksystem abhängig. Er wird auch High-Value-Defaultwert genannt. Er drück aus, dass noch keinWert für Ersetzt_Am definiert wurde. Einen solchen Default-Wert statt NULL zu verwenden macht Sinn, weil sich dadurch bestimmte SQL-Abfragen leichter formulieren lassen.

Bei der Anlage einer neuen Version eines Objekts entspricht der Wert des Feldes ERSTELLT_AM dem Wert des Feldes ERSETZT_AM der alten Version. Hierdurch wird sichergestellt, dass es keine Lücken in der Änderungshistorie eines Objekts gibt.

Quelle des technischen Änderungszeitpunktes aus Sicht des DWH: Grundsätzlich kann der technische Änderungszeitpunkt vom Quellsystem als Transaction-Time verwendet werden – oder das technisches Verarbeitungsdatum des Data Warehouse. Die Entscheidung für eine der beiden Varianten muss für alle Quellen gleich getroffen werden! Die Unterschiede beider Varianten sowie deren Vor- und Nachteile werden an dieser Stelle nicht weiter betrachtet.

Fachliche Gültigkeit

Die fachliche Gültigkeit oder „Valid-Time“ beschreibt die Gültigkeit eines Objektzustandes in der realen Geschäftswelt des Unternehmens. Beispieleweise kann mit dieser Zeitdimension ausgedrückt werden, wann ein Vertrag rechtlich wirksam ist bzw. war. Ein anderes Beispiel ist die neue Bankverbindung, die uns ein Kunde übermittelt und die aber erst in 2 Wochen gültig ist (Vordatierung). Durch die Speicherung der einzelnen Objektzustände im Laufe der Zeit wird die Grundlage geschaffen, historische Zustände nachzuvollziehen – auch wenn dies in den Quellsystemen teilweise nicht mehr möglich ist, weil dort u.U.nicht historisiert wird. Dementsprechend bietet das DWH an dieser Stelle einen beachtlichen Mehrwert.

Ein Objektzustand ist in der Regel über einen Zeitraum gültig. Daher wird auch die fachliche Gültigkeit der Objektzustände mit Hilfe von Zeitintervallen beschrieben. Bei Verwendung von Zeitintervallen können auch Lücken in der Historie eines Geschäftsobjekts erkannt und dokumentiert werden.

DEFINITION

Semantik der fachlichen Gültigkeit kann unter Verwendung von Zeitintervallen wie folgt beschrieben werden:

1. Das Gültigkeitsintervall eines Objektzustandes wird vom Endbenutzer bestimmt und im operativen System erfasst.
2. Die Gültigkeitszeitintervalle der Zustände eines Objekts dürfen sich nicht überlappen. Die Überlappungsfreiheit dieser Intervalle stellt sicher, dass das Objekt zu jedem gegebenen Zeitpunkt höchstens einen fachlich gültigen Zustand hat.
3. Es kann jedoch Zeitpunkte oder Zeiträume geben, in denen das Objekt keinen gültigen Zustand hat. In diesem Fall spricht man von Lücken in der Objekthistorie.

Synonyme für „fachliche Gültigkeit“: „Valid-Time“

In der Praxis kann das fachliche Gültigkeitsdatum in Anhängigkeit des Quellsystems unterschiedlich repräsentiert werden.

Beispiel 1: Bei einer Bankverbindung die zum Lastschrifteinzug verwendet wird, existiert i.d.R. ein Datum, ab dem die Bankverbindung verwendet werden darf – sowie ein Datum, das ausdrückt, ab wann die Bankverbindung nicht mehr verwendet werden darf.

In einigen Systemen werden die Objekte sofort mit Speicherung in der Datenbank auch fachlich wirksam. In diesen Fällen muss sehr sorgfältig darauf geachtet werden, dass hierdurch tatsächlich auch immer eine fachliche Wirksamkeit abgebildet wird. Diese darf nicht mit dem technischen Änderungszeitpunkt verwechselt werden.

Beispiel 2: Ein Sachbearbeiter legt am 10.02.2013 im Billingsystem fest, dass die Einkaufskonditionen für einen Kunden vom 01.03.2013 bis 31.12.2013 gültig (wirksam) sind. Der 10.02.2013 ist der technische Änderungszeitpunkt. Fachlich gültig sind die neuen Konditionen vom 01.03.2013 bis 31.12.2013.

Beispiel einer Valid-Time-Tabelle

Eine Tabelle, die neben den fachlichen Attributen auch (kontextunabhängige) fachliche Gültigkeitsattribute enthält, ist eine Valid-Time-Tabelle. Hinweis: Die Tabelle enthält keinen Zeitstempel, der uns mitteilt, wann die Daten im System abgespeichert wurden (technische Gültigleit). In diesem Fall könnte man den Übertragungszeitpunkt oder den Extraktionszeitpunkt (aus dem Quellsystem) verwenden.

VNR	FATT	GUELTIG_VON	GUELTIG_BIS
4711	01	01.01.1998	01.01.2000
4711	02	01.01.2000	01.1.2006
4711	03	01.1.2007	31.12.9999

Tabelle 4 enthält neben den fachlichen Attributen VNR (Vertragsnummer) und fachlichen Nutzattributen (FATT) auch die chronologiebestimmenden Valid-Time Attribute GUELTIG_VON und GUELTIG_BIS. In der hier beschriebenen Historie des Objekts ist eine Lücke enthalten (in dem Zeitraum vom 01.01.2006 bis 01.01.2007). Dies kann fachlich absolut valide sein, wenn zum Beispiel eine Versicherungsvertrag „ruhend“ gestellt wurde, d.h. für einen bestimmten Zeitraum hat sich der Versicherungsnehmer dazu entschieden, sein Fahrrad aus der Hausratversicherung auszuschließen und später wieder einzuschließen.

Quelle des fachlichen Gültigkeitszeitpunktes aus Sicht des Data Warehouse (DWH)

Fachliche Gültigkeitszeiträume werden ausschließlich aus dem liefernden Quellsystem zur Verfügung gestellt. Es dürfen keine fachlichen Gültigkeitsdaten durch die DWH-Befüllung generiert werden. Andernfalls würden die gelieferten Daten interpretiert werden – dies muss jedoch nicht der Realität entsprechen oder es könnten technische und fachliche Daten vermischt werden. Das Datum, zu dem ein Datensatz im Data Warehouse auftaucht, ist jedoch nicht identisch mit dem Datum zu dem das fachliche Objekt gültig wird. Eine fachliche Historie muss daher entweder direkt im Quellsystem abgelegt und von dort extrahierbar sein oder in der Verantwortung des Quellsystems dort bei der Extraktion bereitgestellt werden.

Beispiel einer „Snapshot-Tabelle“

Eine Tabelle, die nur fachliche (d.h. benutzerdefinierte) Attribute enthält. Es wird in einer solchen Relation keine Historie geführt. Jede Korrektur führt zur Überschreibung des alten Zustandes. Diese Tabellen zeigen eine Momentaufnahme ihres jeweiligen Zustandes; sie werden daher auch Snapshot-Tabellen genannt. Ich verwende an dieser Stelle die Bezeichnung Snapshot nur ungerne – wg. der Assoziation mit Snapshot-Faktentabellen im multidimensionalen Kontext.

VNR	FATT	Eingabedatum
0815	01	01.01.1998
4711	01	01.01.1999

Die Spalte Eingabedatum in dieser Tabelle ist zwar ein Zeitattribut, sie hat jedoch keine chronologiebestimmende Bedeutung, da im Quellsystem bei einer Änderung eines Attributes kein neuer Datensatz erzeugt, sondern der bestehende aktualisiert (d.h. überschrieben) wird, so dass die Historie nicht nachvollziehbar ist. Dieser Tabellentyp residiert oftmals in den Quellsystemen. Auf ihm aufbauend kann keine zuverlässige fachliche Historisierung im DWH aufgebaut werden.

Gegenüberstellung der Zeitdimensionen

Zur Vertiefung der besprochenen Punkte zeigt Tabelle 6 nochmal eine Gegenüberstellung der wesentlichen Unterschiede der beiden chronologiebestimmenden Zeitattribute.

Merkmal	Technische Gültigkeit	Fachliche Gültigkeit
Ursprung der Information?	Quellsystem-Schnittstelle	Quellsystem-Schnittstelle
Wer setzt den Zeitstempel?	Die Quellsystem-Anwendung durch Zugriff auf die Systemuhr (CURRENT TIMESTAMP)	Der Anwender durch manuelle Eingabe
Hat der Anwender einer Applikation Einfluss auf das Datum?	NEIN	JA
Sind Lücken in den Intervallen erlaubt?	NEIN	JA
Darf ein GÜLTIG_BIS Wert vom DWH ermittelt werden?	JA	NEIN (es kann aber ein Defaultwert gesetzt werden)

DWH Ladezeitpunkt

Der Zeitpunkt zu dem Daten aus operativen Quellsystemen in das DWH übernommen werden, wird der „Ladezeitpunkt“ des Data Warehouse genannt. Der Ladezeitpunkt – auch Erkenntnisstand“ genannt, kann eine weitere chronologiebestimmende Zeitdimension darstellen. Der Ladezeitpunkt wird vom DWH berechnet – es darf kein Zeitattribut des Quellsystems für diesen Zeitstempel verwendet werden! Der Ladezeitpunkt spielt gerade in der Data Vault Datenmodellierung eine elementare Rolle. Zur Vereinfachung wird diese Zeitdimension in diesem Artikel nicht weiter betrachtet. Wir bleiben also im Folgenden bei einer bi-temporalen Historisierung.

Fachliche Zeitattribute

Alle anderen Zeitattribute, die den oben genannten Zeitdimensionen nicht zugeordnet werden können, sind benutzerdefinierte (fachliche) Zeitattribute. Die Bedeutung dieser Zeitattribute ist kontextabhängig und ihre Werte können sich über die Zeit ändern. Sie sind keine chronologiebestimmenden Zeitattribute.

Beispiel: Ein Attribut „KUNDE_SEIT“ in einer Tabelle Person beschreibt eine Eigenschaft der Person in Bezug auf einen Kundenvertrag. Es sagt jedoch nichts über die übrigen Attribute der Person aus. Insbesondere bestimmt es weder den fachlichen noch den technischen Gültigkeitsbeginn des jeweiligen Zustands des Objekts „Person“. Fachliche Zeitattribute sind also alle Attribute einer Entität, die nicht chronologiebestimmend sind, d.h. nicht zur Bestimmung der technischen oder fachlichen Gültigkeit herangezogen werden.

Bi-Temporale Historisierung

Bi-temporale Tabellen enthalten neben den fachlichen Attributen immer technische („Transaction-Time“) und fachliche Gültigkeit („Valid-Time“). Da durch die zwei Zeitdimensionen alle Aspekte der Historisierung eines Objekts abgebildet werden, spricht man bei einer bi-temporalen Tabelle auch von vollständiger Historisierung.

Aus Tabelle 10 ist ersichtlich, dass eine Korrektur der Gültigkeit des ersten Zustandes bei Bekanntwerden des zweiten Zustands stattgefunden hat. Es ist somit nachvollziehbar, dass das Gültigkeitsende des ersten Vertragszustands (Fachlicher Schlüssel = VNR) zum Zeitpunkt der Erfassung nicht bekannt war und dass dieser Zustand bis zum Korrekturzeitpunkt mit unbekanntem Gültigkeitsende (31.12.9999) den Anwendungen zur Verfügung gestanden hatte. Aus dieser Kenntnis heraus lässt sich der Datenstand zu einem gegebenen Zeitpunkt reproduzieren.

row Nr	BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
#1	4711	XC	31.12.1997	22.12.1998	01.01.1998	31.12.9999
#2	4711	XC	22.12.1998	31.12.9999	01.01.1998	01.01.1999
#3	4711	AA	22.12.1998	31.12.9999	01.01.1999	31.12.9999

Datensatz #1, Spalte Gültig_bis: Es erfolgt kein Update des Wertes 31.12.9999; stattdessen: Einfügen von Datensatz #2 und log. Löschung via Spalte Ersetzt_am. Zur Unterscheidung von „Fortschreibung“ und „Korrektur“ des jüngsten Datensatzes siehe nachfolgende Kapitel.

Default-Werte

Im Data Warehouse werden oftmals Default-Werte verwendet, um anzugeben, dass der Beginn bzw. das Ende der Gültigkeit nicht bekannt ist. Diese werden anstatt eines leeren Felds (NULL) verwendet, um die Durchführung von arithmetischen Zeitoperationen sowie Vergleiche von Datumsangaben (z.B. CURRENT_DATE >= GUELTIG_VON AND CURRENT_DATE < GUELTIG_BIS) zu erleichtern.

Als Beispiel könnten folgende Defaultwerte definiert sein:

• Default Wert für das Low-Value-Datum: 01.01.0001
• Default Wert für das High-Value-Datum: 31.12.9999

Halboffene Intervalle

Bei den hier verwendeten Intervallen (auch „Historienketten“ genannt) handelt es sich um „halboffene“ Intervalle, d.h. das Beginn-Datum ist Teil des Intervalls wogegen das Ende-Datum nicht mehr Teil des Intervalls ist. Für die Formulierung von SQL SELECT Anfragen gilt daher:

• Das Beginn-Datum ist Teil des Intervalls
• Das Ende-Datum nicht mehr Teil des Intervalls.
• Das Beginn-Datum des aktuellen Satzes ist damit gleich dem Ende-Datum des Vorgängersatzes

Für alle gültigen Daten gilt also: BEGINN_DATUM <= FilterDatum <ENDE_DATUM.

Vorteile der halboffenen Intervalle: Sie lassen sich besser lesen und leichter beladen (ETL-/ELT-Prozess); Nachteil: Die BETWEEN Clause kann in einer SELECT-Abfrage nicht verwendet werden.

Temporale Nichtreduzierbarkeit

Folgende Annahme:

• Alle fachlichen Attribute von zwei Datensätzen einer historisierten Tabelle sind gleich
• Die Datensätze unterscheiden sich nur bzgl. ihrer fachlichen Gültigkeit.
• Die fachlichen Gültigkeitsintervalle Intervalle sind „adjazent“, d.h. sie berühren sich ohne sich zu überlappen. Beispiel: Siehe Tabelle 11

Eine solche Tabelle ist reduzibel, d.h. diese beiden Datensätze können auf einen Datensatz reduzieren werden.

BKey	FATT	Gueltig_ab	Gueltig_bis
4711	01	01.01.2004	01.01.2005
4711	02	01.01.2005	01.01.2008
4711	02	01.01.2008	31.12.9999

VNR = vertragsnummer = Business Key; STATUS = fachliches Attribut. Datensatz 3 liefert keine neue Information

Der Primärschlüssel einer historisierten Tabelle besteht aus dem zeitunabhängigen Schlüssel (Business Key) und mindestens einem chronologiebestimmenden Attribut (hier z.B. GUELTIG_VON). Unter Berücksichtigung dieses Primärschlüssels verursachen die Datensätze der obigen Tabelle keine Schwierigkeiten bei deren Speicherung. Jedoch kann sich unter Umständen die Anzahl Zeilen einer historisierten Dimension dadurch unnötig vergrößern und so die Abfrage-Performance negativ beeinflussen. Die obige Tabelle kann also reduziert werden, siehe nachfolgende Tabelle.

BKey	FATT	Gueltig_ab	Gueltig_bis
4711	01	01.01.2004	01.01.2005
4711	02	01.01.2005	31.12.9999

Tabellen Design

Technischer PRIMARY KEY

Alle historisierten Tabellen des DWH enthalten auf Datenbankebene eine „PRIMARY-KEY“ Definition.

• Der technische Schlüssel einer bi-temporal historisierten Tabelle ist ein Surrogate-Key, der stellvertretend steht für die Kombination aus:
  BK + technischer Zeitstempel + fachlicher Zeitstempel
• Der technische Schlüssel wird datenbankseitig über ein PRIMARY KEY Constraint implementiert.

Fachlicher PRIMARY KEY

Der fachliche Primärschlüssel einer historisierten Tabelle besteht aus einem zeitunabhängigen Teil (Business-Key) und mindestens einem chronologiebestimmenden Zeitattribut. Auf Datenbankebene wird hierzu ein „UNIQUE INDEX“ definiert.

Die Wahl der chronologiebestimmenden Zeitattribute, die Bestandteil des fachlichen Primärschlüssels sind, ist je nach Architekturschicht, vom Tabellentyp und der abzubildenden Fachlichkeit abhängig. Der zeitunabhängige Teil des Schlüssels (Business-Key) identifiziert das jeweilige Objekt unabhängig von der jeweiligen zeitlichen Version und wäre somit der Primärschlüssel der Relation, wenn diese nicht chronologisch geführt werden müsste. Diesen Teil des Primärschlüssels einer chronologischen Relation bezeichnet man als „Business-Key“ (Abkürzungen: „BK“, „BKey“). Synonym gibt es auch den Begriff „Time Invariant Key“ (Abk.: TIK).

Wichtig: Mit dem Business Key wird ein fachliches Objekt eindeutig identifiziert. Mit der Kombination Business Key + chronologiebestimmende Attribute wird ein Zustand dieses Objekts (eine Version) eindeutig identifiziert. Ein Business Key kann auch ein zusammengesetzter Schlüssel sein. Die Historisierung einer Tabelle ist nur möglich, wenn der Business Key jedes in dieser Tabelle gespeicherte Objekt unabhängig von der Zeit eindeutig identifiziert.

VNR_SID	VNR	Status	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
10005	4711	01	31.12.1997	22.12.1998	01.01.1998	31.12.9999
10301	4711	01	22.12.1998	31.12.9999	01.01.1998	31.12.1998
10302	4711	02	22.12.1998	31.12.9999	31.12.1998	31.12.9999

VNR = Vertragsnummer (Business Key)
Fachlicher Primärschlüssel = VNR, GUELTIG_VON, ERSTELLT_AM
VNR_SID = Surrogate ID = Time-Variant Key = Zeitabhänginger Schlüssel = Ersatzschlüssel für den fachlichen Primärschlüssel.

In den obigen Tabellen ist das Feld VNR als Business Key anzusehen. Jeder Vertrag kann mit Hilfe der Vertragsnummer eindeutig identifiziert werden. Zur Identifikation eines Zustands eines gegebenen Vertrages werden VNR und zusätzlich die chronologiebestimmende Attribute benötigt (z.B. GUELTIG_VON und ERSTELLT_AM).

Die VNR­_SID ist ein technischer Schlüssel, der vom DWH generiert wird, auch Surrogate-Key genannt. Die VNR­_SID identifiziert bereits eindeutig eine Kombination aus VNR, GUELTIG_VON, ERSTELLT_AM kann somit als technischer Primary Key der Tabelle definiert werden.

Anwendungsfälle für ETL

Den allgemeinen Fall einer historisierten Tabelle stellt eine bi-temporale Relation dar. Der Umgang mit dieser wird im Folgenden anhand von Use-Cases beschrieben. Hierbei wird insbesondere darauf eingegangen, wie Objektzustände chronologisch verwaltet werden und welche Systemunterstützung hierzu erforderlich ist. Die Use-Cases orientieren sich hierzu am Lebenszyklus eines historisierten Geschäftsobjekts.

In allen der unten aufgelisteten Use-Cases wird eine bi-temporale Relation mit Tupel-Timestamping verwendet. Das Attribut BKEY steht stellvertretend für den zeitunabhängigen Primärschlüssel und FATT für alle fachlichen Attribute der Relation. Alle anderen Attribute sind chronologiebestimmende Attribute. Da das Data Warehouse bei der Belieferung keine zusätzlichen Daten zu den Quelldaten künstlich erzeugt, werden zeitliche Lücken in der Historie der Quelldaten NICHT durch die Erzeugung künstlicher Daten im DWH geschlossen. Davon abgesehen könnte dies auch aus fachlicher Sicht falsch sein.

SID	BKey *	FATT	Erstellt_am *	Ersetzt_am	Gueltig_ab *	Gueltig_bis
—	—	—	—	—	—	—

Fußnoten: * Attribut gehört zum fachlichen Primärschlüssel

Die in Tabelle 14 kursiv dargestellten Attribute bilden den fachlichen Primärschlüssel der Tabelle. In der Datenbank kann dieser über einen UNIQUE INDEX implementiert werden, um Mindestanforderungen an die Datenqualität sicherzustellen. Zusätzlich wird noch ein technisch generierter Schlüssel aufgenommen, der ein Surrogat zum fachlichen Primary-Key darstellt.

In allen folgenden Datenbeispielen wurden Datumswerte anstatt vom Timestamp-Werten verwendet. Dies dient lediglich der einfacheren Veranschaulichung. Es gelten die in den vorherigen Kapiteln festgelegten Datentypen für die chronologiebestimmenden Zeitattribute.

Use-Case 01: Ersten Zustand anlegen

Das Objekt mit dem BKey 4711 wird erstmalig an das DWH geliefert und hier initial angelegt. Der so erzeugte Datensatz repräsentiert den so genannten „Urzustand“ des Objekts. Zu diesem Zeitpunkt ist in der Regel der Beginn der fachlichen Gültigkeit des Objekts bekannt, das Ende jedoch nicht. Daher wird das Attribut „GUELTIG_BIS“ mit dem Wert 31.12.9999 belegt, der anzeigt, dass kein Datum für das Ende der fachlichen Gültigkeit bekannt ist. In dem Beispiel wird angenommen, dass der Datensatz am 01.01.2006 angelegt wurde. Da es sich um den technisch derzeit gültigen Satz handelt, der nicht durch einen neueren Satz ersetzt wurde, enthält das Attribut „ERSETZT_AM“ ebenfalls das Datum 31.12.9999.

BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	31.12.9999	10.02.2006	31.12.9999

In manchen Fällen ist auch das Ende der fachlichen Gültigkeit des Objekts bekannt. In diesen Fällen enthält das Attribut „GUELTIG_BIS“ den entsprechenden Wert.

BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	31.12.9999	10.02.2006	31.12.2006

„Letzten Zustand aktualisieren“ – auch „Fortschreibung“ genannt.

Use-Case 02: Letzten Zustand aktualisieren

Der letztgültige (oder auch „jüngste“) Zustand eines Objekts ist der Zustand mit GUELTIG_BIS = 31.12.9999. Eine Aktualisierung oder Fortschreibung dieses Zustandes bedeutet, dass der jüngste Zustand in der Historie eines Geschäftsobjekts geändert wird. D.h. es wird ein neuer Zustand angelegt, dessen Gültigkeitsbeginn jünger ist als der Gültigkeitsbeginn des betrachteten jüngsten Zustandes.

Zustand t₁
Zum Zeitpunkt t₁ = 01.01.2006 wurde der Urzustand des Objekts angelegt:

BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	31.12.9999	10.02.2006	31.12.9999

Zustand t₂
Zum Zeitpunkt t₂ = 26.01.2006 wurde eine Änderung vorgenommen
(FATT = „EFG“, fachlich gültig ab dem 01.04.2006)

BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	26.01.2006	10.02.2006	31.12.9999
4711	ABC	26.01.2006	31.12.9999	10.02.2006	01.04.2006
4711	EFG *	26.01.2006	31.12.9999	01.04.2006	31.12.9999

Fußnote: * Ein neuer fachlicher Zustand wurde abgebildet.

Es findet kein direktes Update der Spalte GUELTIG_BIS des ersten Datensatzes statt. Es ist auch nach der Änderung nachvollziehbar, dass der erste Zustand des Objekts bis zur Änderung am 26.01.2006 in der Datenbank mit einem unbekannten Ende (31.12.9999) vorhanden war. Das Systemverhalten kann somit nachvollzogen werden und die Generierung von Datenbeständen kann zu jedem Zeitpunkt wiederholt werden.

WICHTIG: Zu der aktuell gültigen Historie des Objekts 4711 zählen nur die Zustände, die noch nicht ersetzt wurden, d.h. Ersetzt_am = „31.12.9999“

Use-Case 03: Letzten Zustand eines Objekts korrigieren

Bei der Fortschreibung (Update des jüngsten Zustandes) wird mindestens ein neuer Datensatz mit anderen fachlichen Attributswerten erzeugt. Bei der Korrektur werden fachliche Attributswerte oder das fachliche Gültigkeitsintervall zwar geändert, ein fachlich neuer Zustand entsteht dadurch nicht.

Zum Zeitpunkt t₁ = 26.01.2006 hat die Beispieltabelle den folgenden Inhalt.

BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
4711	ABC	26.01.2006	31.12.9999	01.01.2002	01.01.2005
4711	EFG	26.01.2006	31.12.9999	01.01.2005	31.12.9999

Zustand t₂
Anwendungsfallbeschreibung: Am 28.01.2006 (t₂) wird die fachliche Gültigkeit des jüngsten Zustandes korrigiert. Der Gültigkeitsbeginn soll auf 01.03.2005 statt 01.01.2005 festgelegt werden.

• (1): Um die Nachvollziehbarkeit der Änderungen sicher zu stellen, ist der bisherige jüngste Datensatz aus der aktuell gültigen Historie herauszunehmen (ERSETZT_AM = 28.01.2006) und ein neuer mit der modifizierten fachlichen Gültigkeit anzulegen.
• (2): Der neu anzulegende Datensatz darf jedoch erst ab Zeitpunkt der Änderung sichtbar sein (ERSTELLT_AM = 28.01.2006). Bei dieser Korrektur entsteht eine Lücke in der Historie, die jedoch nicht automatisch geschlossen werden darf.  Das Schließen dieser Lücke durch eine Verlängerung der Gültigkeit des vorherigen Datensatzes kann fachlich falsch sein. Das fachliche GUELTIG_BIS wird niemals vom DWH gesetzt!

BKey	FATT		Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
4711	ABC	26.01.2006	31.12.9999	01.01.2002	01.01.2005
4711	EFG	26.01.2006	28.01.2006 *	01.01.2005	31.12.9999
4711	EFG	28.01.2006 **	31.12.9999	01.03.2005 ***	31.12.9999

Fußnoten:
* jüngster Satz wird technisch per UPDATE ungültig gesetzt
** INSERT eines Korrektursatzes, „sichtbar“ ab 28.1.2006
*** es entsteht eine Lücke der fachlichen Gültigkeit von 01.01.2005 bis 01.03.2005 !

Unterschied zwischen Fortschreibung und Korrektur des jüngsten Datensatzes

Es ist schwierig basierend auf Datenkonstellationen, eine Korrektur des jüngsten Datensatzes von einer Fortschreibung zu unterscheiden. Allein auf Basis der Datenkonstellation hätte die letzte Änderung als Fortschreibung interpretiert werden können, weil der Beginn des neuen Zustands jünger als der Beginn des bisherigen jüngsten Datensatzes ist.

BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
4711	ABC	26.01.2006	31.12.9999	01.01.2002	01.01.2005
4711	EFG	26.01.2006	28.01.2006	01.01.2005	31.12.9999
4711 *	EFG	28.01.2006 **	31.12.9999	01.01.2005 ***	01.03.2005 ***
4711 *	EFG	28.01.2006 **	31.12.9999	01.03.2005 ***	31.12.9999

Fußnoten:
* zwei neue Sätze werden eingefügt
** Gleicher Erstellt_am Zeitstempel bei beiden neuen Sätzen
*** die fachliche Wirksamkeit wird lückenlos abgebildet

Die Interpretation des neuen Datensatzes als Fortschreibung des Objekts 4711 führt dazu, dass keine Lücke in der Historie entsteht. Stattdessen entsteht eine temporal reduzible Relation (siehe Kapitel 3.13). Während in Tabelle 20 eine Lücke festzustellen ist, ist in Tabelle 21 keine Lücke zu sehen.

Eine dieser beiden Interpretationen ist fachlich nicht richtig. Aus diesem Grund ist bei einer Korrektur zusätzlich zu dem Datensatz auch ein Kennzeichen mitzuliefern, welches darauf hinweist, dass der neue Datensatz nicht als Fortschreibung, sondern als Korrektur des jüngsten Datensatzes in der Historie zu betrachten ist. Andernfalls ist der neue Datensatz als Fortschreibung zu betrachten. Ist dies nicht möglich, so ist seitens der Bewirtschaftung Wissen über das Verhalten des Quellsystems nötig, mithilfe dessen aus den gelieferten Datenkonstellationen auf die fachliche Interpretation geschlossen werden kann.

Zeitpunkt t₁
Zum Zeitpunkt t₁ = 26.01.2006 hat Tabelle 22 den folgenden Inhalt

Use-Case 04: Zustand löschen

In einer voll historisierten Tabelle wird kein physisches Löschen der Objekte vorgenommen. Ein Objekt aus einer solchen Tabelle zum Zeitpunkt t₁ zu löschen bedeutet, dass das Objekt ab t₁ keine sichtbaren Zustände mehr haben darf. Das Lesen der Tabelle aus aktueller Sicht (t₁) wird die Zustände des Objekts nicht finden. Das Lesen der Tabelle zu einem Zeitpunkt älter als t₁ kann jedoch Zustände des gelöschten Objekts finden.

row Nr	BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
#1	4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
#2	4711	ABC	26.01.2006	31.12.9999	01.01.2002	01.01.2005
#3	4711	EFG	26.01.2006	31.12.9999	01.01.2005	31.12.9999

Zeitpunkt t₂
Am 28.01.2006 soll das Objekt 4711 komplett gelöscht werden. Dies geschieht, indem alle in der aktuell gültigen Historie des Objekts vorhandenen Zustände ein „ERSETZT_AM“ = CURRENT TIMESTAMP bekommen. Nach der Löschung (t₂) sind keine Zustände aus aktueller Sicht sichtbar.

row Nr	BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
#1	4711	ABC	01.01.2006	26.01.2006 *	01.01.2002	31.12.9999
#2	4711	ABC	26.01.2006	28.01.2006 **	01.01.2002	01.01.2005
#3	4711	EFG	26.01.2006	28.01.2006 **	01.01.2005	31.12.9999

Fußnoten:
* bereits zu t₁ log. gelöscht gewesen
** zu t₂ logisch gelöscht

Use-Case 05: Rückwirkende Änderung

Die rückwirkende Änderung ist der komplexeste Use-Case bei der Vollhistorisierung. Wir betrachten die folgende bi-temporale Tabelle im zugrunde liegenden operativen System (Tabelle 24):

row Nr	BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
#1	4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
#2	4711	ABC	26.01.2006	31.12.9999	01.01.2002	01.01.2005
#3	4711	EFG	26.01.2006	31.12.9999	01.01.2005	31.12.9999

Fall 1:   Rückwirkende Änderung enthält eine FATT-Änderung und eine Änderung der fachlichen Gültigkeit

Am 31.01.2006 soll die Historie des zweiten Datensatzes (#2) vom 01.01.2002 bis 01.01.2006 fachlich gültig sein und der Wert des Attributs FATT soll auf HIJ gesetzt werden. Diese fachlichen Gegebenheiten führen zu einer neuen Historie, die vom Sachbearbeiter erstellt wird. Das Festlegen der neuen Gültigkeitsintervalle ist kein Ergebnis einer mathematischen Berechnung, sondern eine fachliche Entscheidung. Diese Information kann daher nur aus dem Quellsystem geliefert werden und wird nicht durch die DWH-Befüllung berechnet.

Vorgehensweise im DWH

• Alle Zustände der aktuellen Historie, deren fachliches Gültigkeitsintervall sich mit dem neuen Gültigkeitsintervall des zu ändernden Zustands überschneidet sowie der Vorgängersatz müssen über Ersetzt_am logisch gelöscht werden (*).
• Zwei Datensätze der aktuellen Historie sind betroffen. Über zwei neue Datensätze (INSERT) wird das neue fachliche Gültigkeitsinterval (**) abgebildet.
• Es sind natürlich auch komplizierte Anwendungsfälle denkbar wie z.B. die Aufsplittung in mehrere fachliche Gültigkeitsintervalle (ggfls. auch mit Lücken).

row Nr	BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
#1	4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
#2	4711	ABC	26.01.2006	31.01.2006 *	01.01.2002	01.01.2005
#3	4711	EFG	26.01.2006	31.01.2006 *	01.01.2005	31.12.9999
#4 (neu)	4711	HIJ	31.01.2006 **	31.12.9999 ***	01.01.2002	01.01.2006 ****
#5 (neu)	4711	EFG	31.01.2006 **	31.12.9999 ***	01.01.2006	31.12.9999 ****

Fußnoten:
* Korrekturdatum des UPDATEs
** neu eingefügter Satz
*** akt. gültiger Satz
**** Die Datensatz #4 ersetzt #2; Datensatz #5 ersetzt #3

Fall 2: Rückwirkende Änderung enthält keine Änderung der fachlichen Gültigkeit

• Wir betrachten weiterhin Tabelle 24 als Ausgangslage.
• Der Wert des Attributs FATT des zweiten Datensatzes soll am 31.01.2006 auf 123 rückwirkend geändert werden.
• Die Zeiträume bleiben unverändert. In diesem Fall findet eine Korrektur statt. Eine neue Historie entsteht nicht.
• Der zu ändernde Zustand wird dupliziert und logisch gelöscht
• Der duplizierte Zustand wird aktualisiert (ERSTELLT_AM, ERSETZT_AM)

row Nr	BKey	FATT	Erstellt_am	Ersetzt_am	Gueltig_ab	Gueltig_bis
1	4711	ABC	01.01.2006	26.01.2006	01.01.2002	31.12.9999
2	4711	ABC	26.01.2006	31.01.2006 *	01.01.2002	01.01.2005
3	4711	EFG	26.01.2006	31.12.9999 ***	01.01.2005	31.12.9999
4 (neu)	4711	123	31.01.2006	31.12.9999 **	01.01.2002	01.01.2005

Fußnoten:
* Korrekturdatum des UPDATEs
** #4 basiert auf einer einer Duplizierung von #2 mit neuem FATT-Wert und Ersetzt_am = 31.12.999 (High-Value Default)
*** #3 wurde nicht verändert (keine logische Löschung!)

Fazit für die rückwirkende Änderung im DWH

Zur Berücksichtigung rückwirkender Änderungen von Quellsystemdaten im DWH ist eine komplette neue Historie des Objekts ab dem Zeitpunkt der rückwirkenden Änderung an das DWH zu liefern. Es findet im DWH keine Berechnung von neuen Gültigkeitsintervallen statt. Die neue Historie ist gesondert anzuliefern, so dass die Verarbeitung im DWH nicht durch Vergleich der neuen und alten Datensätze bestimmt wird.

Alle Datensätze im DWH bis zum jüngsten Datensatz in der neu gelieferten Historie sind logisch zu löschen (ERSETZT_AM = CURRENT TIMESTAMP). Die neuen Datensätze können eingefügt werden (nur INSERT), ohne dass ein Vergleich vorher durchgeführt werden musste. Die Erkennung von rückwirkenden Änderungen und deren korrekte Lieferung an das DWH ist eine wichtige Anforderung an die liefernden Schnittstellen aus den Quellsystemen.

Anwendungsfälle für Queries

Use-Case 06: Aktuellen Zustand lesen

In einer voll historisierten Tabelle wird der aktuelle Zustand durch die beiden Zeitdimensionen bestimmt. Daher muss beim Lesen eines Objektzustands immer bestimmt werden, zu welchem fachlichen Zeitpunkt der Zustand gewünscht ist und welcher technische Wissensstand hierfür zugrunde gelegt wird. Letztes wird in den meisten Fällen der jeweils letzte Stand sein. Daher sind folgende Kriterien anzulegen:

ERSETZT_AM = 9999-12-31 AND 
GUELTIG_VON <= CURRENT_DATE AND CURRENT_DATE < GUELTIG_BIS

Use-Case 07: Fachlich gültigen Zustand zum Zeitpunkt t₁ lesen aus aktueller Datenbank-Sicht

In einer voll historisierten Tabelle ist der gültige Zustand eines Objekts zu einem beliebigen Zeitpunkt t₁ aus aktueller Sicht der Zustand mit folgenden Eigenschaften:

ERSETZT_AM = 9999-12-31 AND 
GUELTIG_VON <= t1 AND t1 < GUELTIG_BIS

Use-Case 08: Fachlich gültigen Zustand zum Zeitpunkt t₁ lesen aus beliebiger Datenbank-Sicht

In einer voll historisierten Tabelle ist der gültige Zustand eines Objekts zu einem beliebigen Zeitpunkt t₁ aus beliebiger Datenbanksicht t₂ der Zustand mit folgenden Eigenschaften:

ERSTELLT_AM <= t2 AND t2 < ERSETZT_AM AND
GUELTIG_VON <= t1 AND t1 < GUELTIG_BIS

Siehe auch: https://de.wikipedia.org/wiki/Temporale_Datenhaltung