Unter temporaler Datenhaltung (auch Historisierung genannt) versteht man in der Informationstechnik das Festhalten der zeitlichen Entwicklung der Daten bei Speicherung in einer Datenbank.
Häufig ist es ausreichend, in einem Datenbestand nur den jeweils aktuell (heute) gültigen Wert zu speichern, bei einer Änderung wird der alte Datenwert einfach überschrieben. Wenn jedoch die Anforderung besteht, alle Änderungen zu dokumentieren, ist eine temporale Datenhaltung erforderlich. Diese ermöglicht zu rekonstruieren, welcher Wert zu welchem Zeitpunkt gültig war oder – in weniger häufigen Fällen – erst in Zukunft gültig werden wird.
Bei einer temporalen Datenhaltung sind zwei Arten der zeitlichen Betrachtung relevant: hochkant=2|mini|Beispiel Gültigkeitszeit: Der Zeitraum, in dem ein Datenelement in der realen Welt gültig ist.Beispiel: Ein Artikel zum Preis von 1,95 € verteuert sich am 1. Juni 2006 auf 2,25 €. Transaktionszeit (auch Bearbeitungszeit): Der Zeitpunkt, an dem ein Datenelement im Datenbestand gespeichert wurde.Beispiel: Obige Preisanpassung des Artikels wurde am 25. Mai 2006 bearbeitet und in den Datenbestand aufgenommen. In manchen Fällen sind dabei tatsächlich beide Arten relevant, hierfür verwendet man auch den Ausdruck „bitemporal“. Dies gilt beispielsweise für folgende, auf obige Beispiele bezogene Frage: Welcher Preis wurde einem Kunden am 20. Mai 2006 für den Kauf des Artikels genannt, wobei der Kauf erst am 15. Juni 2006 stattfinden sollte?
Details zur temporalen Datenhaltung werden (oft auch in Verbindung mit der Archivierung von Daten) als Anforderungen zur Revisionssicherheit von Informationssystemen definiert – z. B. wie lange Änderungen nachweisbar sein müssen.
Abbildung temporaler Daten in Datenbanksystemen
Bei der Abbildung temporaler Daten existieren folgende Varianten: Verwendung temporaler DatenbankenDabei handelt es sich um Datenbanksysteme, bei denen systemseitig bereits eine weitergehende Unterstützung temporaler Datenhaltung vorhanden ist, die über die Unterstützung zeitbezogener Datentypen hinausgeht. Derzeit existieren hierfür jedoch lediglich Prototypen und es ist noch kein kommerzielles Datenbanksystem verfügbar, das die Anforderungen der temporalen Datenhaltung umfänglich abbilden würde.Myrach 2005, Seite 23 Verwendung spatio-temporaler DatenbankenDabei handelt es sich um Datenbanksysteme, die neben der Unterstützung zeitabhängiger Daten auch für die Speicherung räumlicher Informationen ausgelegt sind. Dabei liegt der Fokus aber auf der räumlichen Information. Eingesetzt werden derartige Datenbanken beispielsweise im Bereich der Verkehrstelematik. Abbildung in herkömmlichen relationalen DatenbankenDa die Unterstützung temporaler Datentypen auch in herkömmlichen relationalen Datenbanksystemen gegeben ist, können temporale Daten prinzipiell in derartigen Datenbanken gespeichert werden, wobei die temporalen Attribute als „normale“ Attribute abgebildet werden. Die Abhandlung der temporalen Aspekte muss dabei durch die Anwendungsprogramme oder durch ein zur Anwendungsentwicklung verwendetes Framework erfolgen. Abbildung in anderen Datenbanken (z. B. Objektdatenbanken)Für andere Datenbanksysteme, insbesondere auch die objektorientierten Datenbanken, besteht keine mit den relationalen Systemen vergleichbare Einheitlichkeit und Verbreitung, so dass eine generelle Aussage über die Abbildung temporaler Daten nicht möglich ist. Dennoch lassen sich sicherlich die meisten der im Folgenden dargelegten Aspekte auch auf solche Datenbanken übertragen.
Im folgenden Abschnitt werden allgemeine Eigenschaften temporaler Datenhaltung betrachtet, die weitestgehend für alle oben genannten Abbildungen gelten. Anschließend erfolgt eine detaillierte Erläuterungen der Abbildung temporaler Daten in herkömmlichen relationalen Datenbanken. Weitere Informationen zu den anderen Abbildungsvarianten finden sich unter Umständen bei der Erläuterung der Datenbankmanagementsysteme selbst.
Begriffserläuterungen und Terminologie
Im Folgenden werden die wichtigsten Begriffe in Bezug auf temporale Datenhaltung erläutert. Diese Erläuterungen decken sich im Wesentlichen mit dem sogenannten „Konsens-Glossar“ (siehe Weblinks).
Gültigkeitszeit und Transaktionszeit
Wie anfangs bereits erwähnt, bezeichnet Gültigkeitszeit () den Zeitpunkt oder Zeitraum, wann ein Sachverhalt im modellierten Abbild der realen Welt (der Bezugswelt) gilt. Dabei können sowohl zukünftige als auch vergangene Zeiträume relevant sein.
Im Gegensatz dazu bezeichnet Transaktionszeit () den Zeitpunkt, wann ein Sachverhalt in der Datenbank gespeichert wurde und damit den Zeitraum, wann dieser Sachverhalt als korrektes Abbild der Bezugswelt angesehen wurde. Im Gegensatz zur Gültigkeitszeit kann sich die Transaktionszeit also niemals auf die Zukunft beziehen. Ein interessantes Beispiel für temporale Daten findet sich in der Datenbank von Wikipedia selbst, in der eine Transaktionszeitstempelung der Artikel stattfindet,Revision Table.MediaWiki Database Layout um die Versionen eines Artikels zu verschiedenen Zeitpunkten rekonstruieren zu können.
Sind sowohl Gültigkeits- als auch Transaktionszeit relevant, spricht man von bitemporaler Datenhaltung. In diesem Zusammenhang ist auch zu beachten, dass die Transaktionszeit vom System (z. B. dem Datenbanksystem) festgelegt werden kann, die Gültigkeitszeit muss dagegen vom Benutzer angegeben werden.
Im Konsens-Glossar existiert auch der Begriff der benutzerdefinierten Zeit (Konsens-Glossar, Definition benutzerdefinierte Zeit, Chronon, temporales Element, Timestamp, Coalesce). Damit sollen anderweitige Zeitangaben, die „normale“ Attribute in der Datenbank darstellen (wie z. B. ein Geburtsdatum), von der temporalen Datenhaltung abgegrenzt werden. Diese Bezeichnung ist unglücklich, da ja auch die Gültigkeitszeit vom Benutzer festgelegt wird.
Als Schnappschuss () bezeichnet man die Betrachtung temporaler Daten zu einem fixierten Zeitpunkt für die Gültigkeits- und ggf. auch die Transaktionszeit. Meist bezieht sich ein solcher Schnappschuss auf die aktuelle Zeit. Eine Datenbank ohne temporale Unterstützung bietet ausschließlich einen solchen Schnappschuss, deshalb werden solche Datenbanken auch als Schnappschuss-Datenbanken bezeichnet.
Zeitpunkte, Zeitintervalle und Zeitdauern
Ein Zeitpunkt () stellt einen Punkt auf einer verwendeten Zeitachse dar. Dabei können unterschiedliche Granularitäten Verwendung finden (z. B. tagesgenau, sekundengenau).
Zeitangaben können verankert (fixiert) oder unverankert sein. Eine verankerte Zeitangabe bezieht sich auf einen konkreten Zeitpunkt oder ein konkretes Intervall in der Zeitskala. Bei einer Zeitdauer handelt es sich um ein unverankertes Zeitintervall.
Zeitlich verankerte Intervalle werden auch als Perioden () bezeichnet. Der Begriff Intervall ohne zusätzliche Angabe ist in dieser Hinsicht missverständlich, vor allem auch deshalb, weil in SQL der Begriff für eine Zeitdauer verwendet wird.
Das kleinste mögliche Zeitintervall bei einer bestimmten Granularität wird als Chronon bezeichnet, bei einem Datum wäre das beispielsweise ein Tag.
Zeitstempelung
Als Zeitstempelung bezeichnet man die Ergänzung eines Zeitbezugs zu einem Datenattribut oder einer Datenzeile, in Verbindung mit relationalen Datenbanken auch als Tupel bezeichnet. Dabei werden Gültigkeits-, Transaktions- und bitemporale Zeitstempelung unterschieden.
Allgemein wird erst einmal nicht definiert, wie dieser Zeitbezug technisch abgebildet ist. Dabei kann es sich um eine einfache Zeitangabe handeln, die die Gültigkeit zu einem einzigen konkreten Zeitpunkt ausdrückt. Häufiger jedoch ist der Zeitbezug in Form eines Zeitintervalls abgebildet. Die allgemeinste Form ist hierbei ein sogenanntes temporales Element, das eine Menge von ein oder mehreren Zeitintervallen darstellt.
Dieser Zeitbezug wird im Konsens-Glossar auch als Zeitstempel () bezeichnet. Hierbei ist wichtig, dass man dies hier nicht mit der herkömmlichen Bedeutung dieses Begriffs verwechseln darf, da es sich hier um eine wesentlich abstraktere Form eines Zeitstempels handelt.
Bei der Befüllung von Zeitstempeln unterscheidet man explizite und implizite Zeitstempelung. Bei der expliziten Zeitstempelung wird der Zeitstempel nicht durch das Datenbanksystem versorgt, sondern muss explizit durch das Anwendungsprogramm (oder durch die verwendete Architektur, z. B. einem Datenbanktrigger) versorgt werden. Eine implizite Zeitstempelung gibt es nur bei „echten“ temporalen Datenbanken, dort übernimmt das Datenbanksystem in der Regel diese Aufgabe. Zu beachten ist dabei, dass dies nur im Falle der Transaktionszeit vollständig gekapselt ablaufen kann, bei der Gültigkeitszeit muss die Angabe des Gültigkeitszeitraums auch explizit vorgegeben werden können, temporale Datenbanken bieten hierbei aber oft spezielle Schnittstellen an und handhaben den Zeitstempel nicht als normales Attribut.
Tupel- versus Attribut-Zeitstempelung
Bei der Einführung einer Zeitstempelung stellt sich die Frage, auf welcher Ebene man diese ergänzt. Im Grunde genommen müsste jedes Attribut, das sich nicht synchron mit einem anderen verhält, für sich allein versioniert, das heißt mit einer eigenen Zeitstempelung versehen werden. Dieses Vorgehen bezeichnet man als Attribut-Zeitstempelung.
Der technische Verwaltungsaufwand für eine Attribut-Zeitstempelung ist jedoch beachtlich, so dass man häufig alle Attribute einer Datenzeile (eines Tupels) gemeinsam versioniert, obwohl die Attribute sich zeitlich nicht synchron verhalten. Dies bezeichnet man als Tupel-Zeitstempelung.
Die Entscheidung, welches Verfahren man wählt, hängt vor allem von der Änderungshäufigkeit der einzelnen Attribute ab. Typischerweise wird man Attribute mit hoher Änderungshäufigkeit eher für sich alleine, hingegen Attribute mit geringer Änderungshäufigkeit gemeinsam versionieren.Myrach 2005, Seite 389–392
Temporale Normalisierung ()
Mit der Tupel-Zeitstempelung handelt man sich aber zwangsläufig das Problem ein, dass man bei Auswertungen, die nur eines der gemeinsam versionierten Attribute auswerten, aufeinander folgende Zeiträume erhält, bei denen sich die Attributwerte nicht unterscheiden. Man hätte dann gern diese Zeiträume zusammengefasst. Eine derartige Zusammenfassung wird als temporale Normalisierung bezeichnet (auch ).
Die Verwendung der Tupel-Zeitstempelung ist aber nicht der einzige Grund, warum man eine temporale Normalisierung benötigt. Beispielsweise ist diese Normalisierung ebenfalls erforderlich, wenn man bitemporale Daten nur separat nach der Gültigkeits- oder der Transaktionszeit auswertet. Außerdem ist eine solche Zusammenfassung auch dann wünschenswert, wenn man bei Auswertungen mehrere mit Zeitstempelung versehene Tupel verknüpft (Join).
Formal versteht man unter temporaler Normalisierung eine Zusammenfassung gleichartiger Attributwerte, wann immer das gemäß der zur Zeitstempelung verwendeten Datentypen möglich ist.Myrach 2005, Seite 63 Bei Verwendung von Zeitintervallen zur Zeitstempelung sind also aufeinanderfolgende Intervalle mit gleichen Attributwerten zusammenzufassen, bei Verwendung von temporalen Elementen werden sogar alle Zeiträume zusammengefasst, zu denen ein spezieller Attributwert auftritt.
Im folgenden Beispiel werden für die Artikeldaten der Preis und der Ziellagerbestand gemeinsam versioniert. Werden sowohl der Preis als auch der Ziellagerbestand für sich alleine ohne Normalisierung ausgewertet, würde man vier einzelne Intervalle erhalten. Durch die temporale Normalisierung lassen sich dabei je zwei Einzelintervalle zu einem zusammenfassen.
+ Artikeldaten Art.nr. Gültig ab Gültig bis Preis Ziellgrbst. 4711 01.03.06 31.05.06 1,95€ 1000 4711 01.06.06 31.07.06 2,25€ 800 4711 01.08.06 30.09.06 2,25€ 750 4711 01.10.06 b.a.w. 2,45€ 750
+Preis pro Artikel(normalisiert) Art.nr. Gültig ab Gültig bis Preis 4711 01.03.06 31.05.06 1,95€ 4711 01.06.06 30.09.06 2,25€ 4711 01.10.06 b.a.w. 2,45€