Zum Inhalt springen

Temporale Datenhaltung

Links hinzufügen
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 27. Februar 2007 um 17:11 Uhr durch Cactus26 (Diskussion | Beiträge) (→Integritätsprüfungen). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Unter temporaler Datenhaltung (auch Historisierung genannt) versteht man in der Informationstechnologie die zeitabhängige Speicherung von Daten.

Normalerweise wird in einer Datenbank nur der jeweils aktuell (heute) gültige Wert gespeichert, bei einer Änderung eines Werts wird der alte Datenwert einfach überschrieben. Dagegen ermöglicht eine temporale Datenhaltung zu rekonstruieren, welcher Wert zu welchem Zeitpunkt gültig war oder - in weniger häufigen Fällen - auch gültig werden wird.

Bezüglich temporaler Datenhaltung sind zwei Arten der zeitlichen Betrachtung relevant:

  • Gültigkeitzeit: Der Zeitraum, in der ein Datenelement in der realen Welt gültig ist.
    Beispiel: Ein Artikel zum Preis von 1,95€ verteuert sich am 01. 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 z.B. bei Beantwortung folgender auf obige Beispiele bezogenen 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?
Datei:TemporaleDatenhaltungAbb1.jpg
Beispiel


Abbildung temporaler Daten in Datenbanksystemen

Bezüglich der Abbildung temporaler Daten existieren folgende Varianten:

  • Verwendung temporaler Datenbanken
    Dabei handelt es sich um Datenbanksysteme, bei denen systemseitig bereits eine gewisse Unterstützung temporaler Datenhaltung vorhanden ist, die über die Unterstützung von zeitbezogenen Datentypen hinausgeht. Vollwertige temporale Datenbanken haben derzeit noch keinen besonders hohen Verbreitungsgrad bzw. befinden sich noch in der Entwicklungsphase.
  • Verwendung spatiotemporaler Datenbanken
    Dabei 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 meist auf der räumlichen Information.
  • Abbildung in herkömmlichen relationalen Datenbanken
    Da die Unterstützung temporaler Datentypen auch in herkömmlichen relationalen Datenbanksystemen gegeben ist, können temporale Daten prinzipiell in relationalen 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. objektorientierten Datenbanken)
    Bezüglich der anderen Datenbanksysteme besteht keine mit den relationalen Systemen vergleichbare Einheitlichkeit und Verbreitung, so dass eine generelle Aussage über die Abbildung temporaler Daten nicht möglich ist.

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 Datenbanksysteme 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 (Valid Time) den Zeitpunkt oder Zeitraum, wann ein Sachverhalt in der modellierten realen Welt (der Bezugswelt) gilt. Dabei können sowohl zukünftige als auch vergangene Zeiträume relevant sein.

Im Gegensatz dazu bezeichnet Transaktionszeit (Transaction Time) 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[1], 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 (User-defined Time[2]). 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 (Snapshot) 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 (Instant) 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 in der Zeitskala. Bei einer Zeitdauer handelt es sich somit um ein unverankertes Zeitintervall.

Zeitlich verankerte Intervalle werden auch als Perioden (Time Period) 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 bezüglich einer bestimmten Granularität kleinste mögliche Zeitintervall wird als Chronon[2]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 Datenbank 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 umfänglichste Form ist hierbei ein sogenanntes temporales Element[2] , das eine Menge von ein oder mehreren Zeitintervallen darstellt.

Dieser Zeitbezug wird im Konsens-Glossar auch als Zeitstempel (Timestamp) bezeichnet[2]. 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.

Tupel- versus Attribut-Zeitstempelung

Bezüglich der Zeitstempelung stellt sich die Frage, auf welcher Ebene man diese einführt. Im Grunde genommen müsste jedes Attribut, das sich nicht synchron mit einem anderen verhält, für sich allein versioniert, dass heißt mit einer eigenen Zeitstempelung versehen werden. Dieses Vorgehen bezeichnet man als Attribut-Zeitstempelung.

Der technische Verwaltungsaufwand für eine Attribut-Zeitstemeplung 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[3].

Temporale Normalisierung (Coalescing)

Mit der Tupel-Zeitstempelung handelt man sich aber zwangsläufig das Problem ein, dass man bei Auswertung nur eines der gemeinsam versionierten Attribute aufeinander folgende Zeiträume erhält, bei denen sich die Attributwerte nicht unterschieden. Man hätte dann gern diese Zeiträume zusammengefasst. Eine derartige Zusammenfassung wird als temporale Normalisierung bezeichnet (auch Coalescing[2]).

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).

Abbildung in herkömmlichen relationalen Datenbanksystemen

Die Abbildung temporaler Daten in herkömmlichen relationalen Datenbanken ist möglich, dennoch gibt es kein Patentrezept bezüglich der Umsetzung. Die Komplexitätssteigerung und die Nachteile bei Abbildung temporaler Daten im Vergleich zu einer "herkömmlichen" Schnappschuss-Abbildung sind dabei nicht unerheblich, so dass es auch diverse vereinfachende Abbildungen gibt, die jeweils situationsabhängig möglich sind. Mit der Unterstützung temporaler Daten sind folgende Nachteile verbunden:

  • Das Datenvolumen steigt beträchtlich, ggf. ist eine Bereinigungsfunktion notwenig, die ältere Daten archiviert bzw. löscht.
  • Der Zugriff auf den aktuellen Wert wird wesentlich komplexer (Implementierungsaufwand, Performance), dies ist v.a. deshalb bedeutsam, da dies in vielen Fällen die mit Abstand häufigste Form des Zugriffs ist.
  • Aus dem ER-Modell (ohne temporale Betrachtung) abgeleitete Integritätsbedingungen können nicht mehr so ohne weiteres mittels der Definition von Primärschlüsseln und Nutzung der referentiellen Integrität abgebildet werden.

Es ist somit nicht zweckmäßig, eine temporale Abbildung für Daten zu unterstützen, für die das aufgrund der Anforderungen nicht unbedingt nötig ist. Das bedeutet auch, dass bei der grundsätzlichen Einführung der Zeitabhängigkeit in ein Datenmodell nicht grundsätzlich alle Relationen umgestellt werden sollten.

Im folgenden werden zunächst verschiedene konzeptionelle Aspekte bezüglich einer vollwertigen Abbildung temporalen Daten dargelegt. Abschließend erfolgt zudem noch die Diskussion diverser vereinfachender Abbildungen.

Zeitstempelung

Zur Zeitstempelung werden im Regelfall Zeitintervalle verwendet. Da es ein (fixiertes) Zeitintervall nicht als explizites Attribut in relationalen Datenbanken gibt, sind hierfür zwei Zeitattribute (z.B. vom Typ DATE oder TIMESTAMP) in die Tabellendefinition aufzunehmen, die den Beginn und das Ende des Zeitintervalls definieren, im bitemporalen Fall jeweils separat für Gültigkeits- und Transaktionszeit. Dabei gibt es zwei grundsätzliche Ansätze[4]:

  1. Interval Representation: Ergänzung zweier Zeitangaben pro Datenzeile (Beginn, Ende)
  2. Point Representation: Ergänzung nur einer Zeitangabe, die den Beginn der Zeile definiert, das Ende wird hierbei implizit durch den Beginn der zeitlich folgenden Zeile festgelegt

Beide Ansätze haben ihre Vor- und Nachteile:

  1. Nachteile der Interval Representation:
    • Überschneidende Zeilen können eingefügt werden, ohne die Datenbankintegrität zu verletzten. Es ist eine gesonderte Validierung erforderlich (z.B. mittels Datenbanktriggern).
    • Es ist ein spezieller Wert zur Kennzeichnung einer unbefristeten Gültigkeit erforderlich. Hierfür kann entweder NULL oder das minimal bzw. maximal mögliche Datum verwendet werden (siehe unten).
    • Bei einer Wertänderung ist zusätzlich zum Einfügen einer neuen Zeile ggf. die Anpassung (Terminierung) der bisher gültigen Zeile erforderlich.
  2. Nachteile der Point Representation:
    • Die Ermittlung der Daten zu einem speziellen Zeitpunkt (i.d.R. aktueller Zeitpunkt) ist schwierig und benötigt eine Unterabfrage (Subselect).
    • Das Ende der Gültigkeit oder Gültigkeitsunterbrechungen können nur dadurch abgebildet werden, dass alle Datenattribute der Zeile leer (NULL) gesetzt werden.

Bei der Interval Representation steht man zudem vor der Wahl, ein geschlossenes oder ein rechtsseitig halboffenes Intervall zu verwenden, d.h. das Ende selbst ist nicht mehr Bestandteil des Intervalls. Dabei spricht vieles für letztere Variante, da sonst bei der Ermittlung auf Lückenlosigkeit der Intervalle immer ein Chronon zum Ende addiert werden müsste, was z.B. beim Datentyp TIMESTAMP datenbankunabhängig gar nicht möglich ist.

Das folgende Beispiel stellt die SQL-Abfragen für beide Varianten dar. Dabei werden die aktuell gültigen Preise zu Artikeln (identifiziert durch ArtNr) ermittelt. Der Gültigkeitsbeginn wird jeweils durch die Spalte GueltigAb ausgedrückt, für die Intervall-Represantation wird das Gültigkeitsende durch UngueltigAb definiert (es handelt sich also um ein rechtszeitig halboffenes Intervall). Zudem wird im Falle eines unbefristeten Gültigkeitsendes unterstellt, dass das maximal mögliche Datum eingetragen wird. 

SELECT ArtNr, Preis 
  FROM Artikel AS a
 WHERE CURRENT_DATE >= a.GueltigAb
   AND CURRENT_DATE < a.UngueltigAb


SELECT ArtNr, Preis 
  FROM Artikel AS a
 WHERE a.GueltigAb = (SELECT MAX(GueltigAb) 
                        FROM Artikel
                       WHERE ArtNr = a.ArtNr
                         AND GueltigAb <= CURRENT_DATE
                     )

Bestimmen des Primärschlüssels

Der Primärschlüssel einer temporalen Relation beinhaltet zunächst einmal auch die eindeutige Identifikation der Zeile ohne Berücksichtigung der für die temporale Speicherung erforderlichen Zeitstempelung (also die Primärschlüsselspalten, die die Relation ohne temporale Abbildung hätte). Aber bei temporaler Speicherung besteht eine noch größere Erfordernis der zeitlichen Invarianz der Schlüsselattribute, als dies in einer Schnappschuss-Datenbank der Fall ist, da sonst die Objekt-Evolution nicht mehr nachvollziehbar ist. Somit ist bei temporaler Speicherung noch häufiger die Verwendung eines Surrogatschlüssels (künstlichen Schlüssels) erforderlich[5].

Bei Verwendung der Point Representation für die Zeitstemeplung ist der "normale" Primärschlüssel lediglich noch um das den Gültigkeitsbeginn definierende Attribut zu erweitern.

Bei Verwendung der Interval Representation bieten sich mehrere Alternativen an. Hierbei kann entweder der Beginn oder das Ende des Intervalls in den Schlüssel aufgenommen werden. Bei dieser Entscheidung spielt noch eine Rolle, welchen Wert man als Stellvertreter für eine unbefristete Gültigkeit definiert[6]:

  • Der Primärschlüssel einer Relation wird einerseits zur Sicherstellung der Eindeutigkeit definiert, andererseits ist die Definition des Primärschlüssels auch eine Optimierungsfrage, da beim Zugriff auf die Daten dieser Schlüssel als Index zur Suche der passenden Zeilen verwendet wird.
  • Insbesondere bei der Transaktionszeitstempelung wird häufig die derzeit aktuell gültige Zeile benötigt. Dies ist die Zeile, bei der das Gültigkeitsende unbefristet ist. Dies würde für die Aufnahme des Gültigkeitsendes in den Primärschlüssel sprechen.
  • Bei herkömmlichen relationalen Datenbanksystemen ist NULL nicht als Primärschlüsselspalte möglich, deshalb kann das Gültigkeitsende nicht in den Schlüssel aufgenommen werden, wenn man diese Abbildungsvariante für ein unbefristetes Gültigkeitsende wählt. Alternativ würde sich dann die Verwendung des maximal möglichen Zeitwerts zur Festlegung eines unbefristeten Gültigkeitsendes anbieten.

Zu beachten ist weiterhin, dass bei Verwendung der Interval Representation keine der Varianten eine Überschneidungsfreiheit der Zeilen sicherstellt, diese ist gesondert zu prüfen.

Integritätsprüfungen

Wie bereits erwähnt müssen Integritätsbedingungen, die normalerweise über die Eindeutigkeit des Primärschlüssels oder die referentielle Integrität abgedeckt werden, bei temporalen Daten anderweitig abgesichert werden. Hierzu bieten sich folgende Varianten an:

Insbesondere bei Nutzung von Constraints und Datenbanktriggern kann sich die Problematik ergeben, dass die Integrität während einer aus mehreren Datenbankoperationen bestehenden Aktualisierung temporär verletzt sein kann und erst nach Durchführung aller Datenbankoperationen für einen Aktualisierungsfall wieder eingehalten wird. Hierfür muss das Datenbanksystem die Möglichkeit bieten, die Integritätsprüfungen erst am Ende einer Transaktion durchzuführen[7].

Bei Verwendung der Interval Representation ist, wie schon erwähnt, die Prüfung auf Überscheidungsfreiheit der Zeilen zu einem Objekt erforderlich. Im folgenden eine beispielhafte SQL-Abfrage, die überscheidende Einträge für Zeilen zu Artikeln (identifiziert durch ArtNr) aus einer Tabelle mit Namen Artikel liefert, wobei das Gültigkeitszeitintervall durch GueltigAb und UngueltigAb ausgedrückt wird. 

SELECT * FROM Artikel AS x, Artikel AS y
 WHERE x.ArtNr = y.ArtNr
   AND x.UngueltigAb >= y.GueltigAb
   AND y.UngueltigAb >= x.GueltigAb
   AND x.GueltigAb <> y.GueltigAb

Etwas irritierend ist dabei der letzte Vergleich (x.GueltigAb <> y.GueltigAb). Dieser ist erforderlich, damit ein Zeile nicht als überschneidend mit sich selbst diagnostiziert wird (dabei wird zudem unterstellt, dass der Gültigkeitsbeginn Bestandteil des Primärschlüssels ist).

Noch etwas aufwändiger gestaltet sich die Prüfung der referentiellen Integrität im temporalen Sinn, wenn sowohl die referenzierende Tabelle (die Dependent-Tabelle) als auch die referenzierte Tabelle (die Parent-Tabelle) eine Zeitstempelung aufweist. Hierbei muss für jede Zeile der Dependent-Tabelle geprüft werden, ob

  1. eine davor oder gleichzeitig beginnende zugehörige Parent-Zeile existiert, die sich mit dem Zeitraum der Dependent-Zeile überlappt,
  2. eine danach oder gleichzeitig beendete zugehörige Parent-Zeile existiert, die sich mit dem Zeitraum der Dependent-Zeile überlappt und
  3. für alle Zeilen der Parent-Tabelle, deren Gültigkeitsende im Zeitraum der jeweiligen Dependent-Zeile liegt (nicht mit ihm zusammenfällt!), immer ein direkter Nachfolger existiert (keine Lücken, wo es stört).

Nur wenn alle drei Bedingungen gegeben sind, liegt keine Verletzung der Integrität vor.

Vereinfachende Abbildungen

Als Alternative zu einer Transaktionszeitstempelung kann für den Fall, dass nur in sehr seltenen Fällen auf ältere Daten zurückgegriffen werden muss, über eine Protokollierung (Logging) der Datenbank-Aktualisierungen die Rekonstruierbarkeit älterer Datenkonstellationen sichergestellt werden. Für die Implementierung eines derartigen Prokollierungsverfahrens ist jedoch die Nutzung zentraler Funktionen für Datenbank-Aktualisierungen nötig. Zudem sind Funktionen bereitzustellen, die durch Auswertung des Protokolls alte Datenbankstände rekonstruieren.

Bei der Gültigkeitszeitstempelung ist es für den Fall zyklischer Datenänderungen sinnvoll, statt der üblicherweise verwendeten Intervalle zur Zeitstempelung direkt die Identifikation der Gültigkeitsperiode zu verwenden (z.B. bei einem jährlichen Änderungszyklus kann allein das Jahr als zusätzlicher Primärschlüsselbestandteil verwendet werden).

Falls die Temporalität ausschließlich dafür erforderlich ist zu dokumentieren, mit welchen Datenständen eine bestimmte Auswertungsfunktion ausgeführt wurde, kann auch das Ausführungsereignis selbst als Zeitstempel verwendet werden. Zu beachten ist aber, dass dieser Ansatz fragwürdig wird, sobald zwei verschiedene derartige Auswertungsfunktionen existieren, die gleichartige Datentypen einbeziehen.

Ein weiterer Ansatz zur Vereinfachung des Zugriffs auf die aktuellen Daten ist, die Historie in separate Tabellen auszulagern. Dies ist v.a. auch im Hinblick auf die Performance bei Zugriff auf die aktuellen Daten interessant. Dieses Verfahren ist sowohl für die Transaktions- als auch die Gültigkeitszeit möglich, für letztere allerdings nur dann, wenn keine zukünftig gültigen Daten zu erfassen sind. Zudem ist der Preis relativ hoch, da alle Relationen dupliziert werden müssen.

Einzelnachweise

  1. ↑ MediaWiki Database Layout, Revision Table
  2. ↑ a b c d e Konsens-Glossar, Definition benutzerdefinierte Zeit, Chronon, temporales Element, Timestamp, Coalesce
  3. ↑ Myrach 2005, Seite 390ff
  4. ↑ On An Algebra For Historical Relatlonal Databases. Two Views; Clifford/Tansel; 1995
  5. ↑ Myrach 2005, Seite 259f
  6. ↑ A Novel Approach to Model NOW in Temporal Databases; Bela Stantic, John Thornton, Abdul Sattar; 2003
  7. ↑ Myrach 2005, Seite 158, 164, 173ff

Literatur

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Temporale_Datenhaltung&oldid=28419355“