Temporale Erweiterungen des relationalen Datenmodells

Friedrich Schiller-Universität Jena
Institut für Informatik
Temporale Erweiterungen des relationalen
Datenmodells
Ausarbeitung zum Proseminar:
“Grundlagen von DBMS“
Wintersemester 2000/2001
Leitung : Dipl. Inf. Lufter
Prof. Dr. Küspert
vorgelegt von:
Stefan Scheidewig MN 38784
Daniel Lempe
MN 39481
3. Semester, Diplom
Informatik
Jena den 21.03.2001
2
Inhalt
Seite
1. Einleitung
3
2. Zeit
4
2.1
Zeitmodelle
4
2.2
Zeitfolgetypen
4
2.3
Zeitdatentypen
4
3. Temporale Daten
5
3.1
Snapshotdaten
6
3.2
Gültigkeitszeitdaten
6
3.3
Transaktionszeitdaten
7
3.4
Bitemporale Daten
7
4. Temporale Datenmodelle
7
4.1
Gültigkeitszeitmodell
7
4.2
Transaktionszeitmodell
8
4.3
Bitemporales Modell
9
5. BCD – Modell
10
5.1
Eigenschaften
10
5.2
Fallbeispiel
11
5.3
Änderungsoperatoren
11
6. TSQL2
13
6.1 Zeit in TSQL2
13
6.2 Sprachkonstrukte in TSQL2
14
6.2.1 Der CREATE TABLE - Befehl
14
6.2.2 Der INSERT - Befehl
15
6.2.3. Der UPDATE - Befehl
18
6.2.4. Der DELETE - Befehl
18
6.2.5 Die SELECT – Anweisung
19
6.3 Ein Vergleich
22
6.4 Weitere temporale Datenbanken
23
7. Zusammenfassung
Literaturverzeichnis
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
23
24
3
1. Einleitung
Das Gebiet der temporalen Datenbanken
wird erst seit etwa 15 Jahren erforscht, daher
1500
ist dieses Gebiet noch relativ jung. Die
1000
Anzahl der Veröffentlichungen zu diesem
500
Thema hat aber während der letzten Jahre
sehr zugenommen, sind es 1988 noch 214
gewesen, so konnten
0
1988 1991 1994 1996
1996 schon 1096
Erscheinungen und Publikationen verzeichnet werden.
In vielen Anwendungen ist es einfach erforderlich, nicht nur Informationen über Objekte,
sondern auch die zeitlichen Änderungen dieser Informationen, über ihren Gültigkeitszeitraum
hinaus, festzuhalten. Beim Löschen oder Ändern von Daten, die für diese Anwendungen in
bestimmten Datenbanken abgelegt wurden, müssen Überspeicherungen verhindert werden.
Konventionelle Datenbanksysteme sind nur beschränkt geeignet, diese Datenhaltung zu
organisieren. Existierende Sprachkonstrukte sind bei Recherchen über Zeitverläufe nicht
ausreichend. Damit sind Untersuchungen etwa über neue Datenmodelle, Datenbanksprachen
oder anzulegende Speicherstrukturen notwendig.
Einige dieser Sprachvorschläge werden im späteren Verlauf vorgestellt werden, wobei aber
das Hauptaugenmerk auf dem Sprachvorschlag TSQL2 liegen wird.
Wo aber sollen diese neuen temporalen Datenbanken eingesetzt werden? Zum Beispiel in der
Medizin, denn hier ist die Wahl der Behandlungsmethode des Patienten von früheren und
aktuellen Diagnosen abhängig. Auch in der Buchhaltung von Firmen, sind Informationen über
die Gehaltsentwicklung eines Angestellten hilfreich, oder Angaben über die Ausgaben der
Firma im Vergleich zum Vorjahr, wobei temporale Datenbanken genutzt werden können.
Es lassen sich viele solcher Beispiele aufzählen, aber realisieren lassen sie sich erst seit kurzer
Zeit, da temporale Datenhaltung immens speicheraufwendig ist. Daher war sie früher ein
teueres Unterfangen, aber zur heutigen Zeit, in der Speichermedien immer größer und
schneller werden, ist sie in den Bereich des Finanzierbaren gekommen.
Die folgende Ausarbeitung wird sich zuerst mit den theoretischen temporalen Grundlagen und
Modellen beschäftigen und dann insbesondere auf TSQL2, aber auch andere temporale
Sprachvorschläge, eingehen. Aus Gründen der Verständlichkeit, wie auch des Umfangs,
haben wir auf temporale Algebra verzichtet.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
4
2. Die Zeit
2.1 Zeitmodelle
Def. : Zeit ist eine Existenzform der Materie in der alle ihre Änderungen und Bewegungen
ablaufen [Meyers Lexikon]
Def. : allg.: Abfolge eines Geschehens, die im menschlichen Bewußtsein als Vergangenheit,
Gegenwart und Zukunft am Entstehen und Vergehen der Dinge erfahren wird. Die
Gegenwart läßt sich als Grenze zwischen Noch-nicht (Zukunft) und Nicht-mehr
(Vergangenheit) bestimmen. [Meyers Lexikon]
Es gibt drei grundlegende Modelle der Zeit
Stetiges Modell:
Hierbei ist die Zeit isomorph zum Bereich der reellen Zahlen, sie wird also mit den reellen
Zahlen gleichgesetzt. Zeit verläuft in diesem Modell linear.
Dichtes Modell:
Dabei ist die Zeit isomorph zum Bereich der rationalen Zahlen, sie wird also mit den
rationalen Zahlen gleichgesetzt. Zeit verläuft in diesem Modell linear.
Diskretes Modell:
Hier ist die Zeit isomorph zum Bereich der natürlichen Zahlen, sie wird also mit den
natürlichen Zahlen gleichgesetzt. Zeit verläuft in diesem Modell linear.
Im Diskreten Zeitmodell gilt das chronon als kleinste Einheit, wobei ein chronon kein Punkt,
sondern ein Segment auf der Zeitlinie ist. So wird beispielsweise mit einem schönen
Augenblick nicht nur die Millisekunde eines Zwinkerns assoziiert, sondern das gesamte
Ereignis, welches damit verbunden wird.
Dieses Modell dient als Grundlage für die temporalen Datenbanken, da sich diskrete Zeit in
der diskreten Rechnerumgebung leichter implementieren läßt.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
5
2.2 Zeitfolgetypen
Abb. 1: Zeitfolgen
Eine Folge, deren Elemente nach der Gültigkeitszeit(vt) geordnete Daten(t) eines Objektes
sind, wird als Zeitfolge bezeichnet. Die aktuelle Zeitfolge enthält Daten, die nach
gegenwärtigem Wissensstand gültig sind, andernfalls wird sie als nichtaktuell charakterisiert.
Gilt ein Fakt in zeitlicher Richtung fort, bis er später durch einen anderen ersetzt wird, handelt
es sich um eine zustandsstabile Zeitfolge (Abb 1a). Ein Beispiel für eine zustandsstabile
Zeitfolge ist die Positionen von Mitarbeitern in einer Firma oder auch der Kontostand.
Ist ein Fakt nur zu einem bestimmten Zeitpunkt gültig, sprechen wir von einer
ereignisorientierten Zeitfolge (Abb 1b). Als Beispiel hierzu kann man eine Unfallbilanz der
Polizei betrachten.
Wenn ein Fakt fortlaufend über die Zeit gültig ist, sprechen wir von einer kontinuierlichen
Zeitfolge (Abb 1c). Die Pegelstände an Gewässern sind ein Beispiel für kontinuierliche
Zeitfolgen. Notwendige Bedingung einer kontinuierlichen Zeitfolge ist, daß die vorhandenen
Stützstellen den Kurvenverlauf eindeutig darstellen. Ansonsten ist sie den anderen beiden
Zeitfolgetypen zuzuordnen. Wird beispielsweise bei einem Patienten mehrere Male pro Tag
die Temperatur gemessen, ist sie über einen Zeitraum als Kurve darstellbar. Erfolgt die
Messung gelegentlich, zum Beispiel einmal pro Woche, kann man nur von einer
ereignisorientierten Zeitfolge sprechen.
2.3 Zeitdatentypen
Es gibt bereits verschiedene Zeitdatentypen, mit deren Hilfe sich einfache temporale
Gegebenheiten in SQL92 darstellen lassen können. Ein instant ist ein spezieller chronon auf
der Zeitlinie, ein event ist ein Ereignis, welches zu einem instant geschieht und die event
occurence time ist die Zeit, in der der event in der realen Welt passiert ist.
So unterstützt SQL92 drei Arten von instant Datentypen, und zwar: DATE (Datum), TIME
(Tageszeit) und TIMESTAMP (Datum und Zeit zusammen).
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
6
Der Typ TIME PERIOD, also eine Zeitspanne zwischen zwei instants, wird von SQL92
nicht unterstützt, dies soll aber in SQL3 geschehen.
In SQL92 werden zwei Arten unterstützt, zum einen, das month - year interval und zum
anderen, das second - day interval. Dies kommt daher, da month (engl. Monat) und year
(engl. Jahr) in einem festen Verhältnis zueinander stehen, also 12:1. Dasselbe gilt auch für
second (engl. Sekunde) und day (engl. Tag). Aber durch den Fakt des Schaltjahres ist ein
second - year interval nicht möglich, da das Verhältnis nicht fest bestimmt ist.
3.Temporale Daten
Es gibt verschiedene Arten temporaler Daten, die im folgenden Teil charakteriesiert werden.
Abb. 2: Schematische Darstellung
3.1 Snapshotdaten
Dies sind nicht temporale Daten oder die wie die meisten Datenbanken keine explizite
Zeitinformationen enthalten. Weiterhin sind es nur zweidimensionale Informationen, die von
den Dimensionen Objekt und Eigenschaft definiert werden (Abb. 2a). Als Modell hierfür
kann die klassische Datenbank angesehen werden.
3.2 Gültigkeitszeitdaten
Jene temporalen Daten werden durch die Gültigkeitszeit (valid time) sowie den Eigenschaften
der betrachteten Objekte wärend dieser Zeit charakterisiert (Abb. 2b). Durch die explizite
Gültigkeitszeit wird bestimmt, wann ein Tupel in der modellierten Welt wahr ist. Außerdem
kann die gewisse Zeit sowohl begrenzt als auch unbegrenzt sein, da angenommen werden
kann, daß ein Fakt erst in der Zukunft gültig ist. Das Modell hierzu wäre das
Gültigkeitszeitmodell (siehe Abschnitt 4.1).
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
7
3.3 Transaktionszeitdaten
Transaktionszeitdaten sind ebenfalls temporale Daten, welchen zu den zwei Dimensionen
Objekt und Eigenschaft noch die Transaktionszeit hinzugefügt wurde (transaction time) (Abb.
2b). Durch diese Zeit wird gezeigt, wann das Tupel in der Datenbank gespeichert worden ist.
Die Transaktionszeit ist eine implizite Zeitmarke, die von der Systemuhr vorgegeben wird
und damit durch die Gegenwart begrenzt ist. Das dazugehörige Modell ist das
Transaktionszeitmodell (siehe Abschnitt 4,2).
3.4 Bitemporale Daten
Falls Daten sowohl Gültigkeitszeit als auch Transaktionszeit besitzen, sprechen wir von
bitemporalen Daten, durch welche es möglich ist, die gesamte Geschichte des Objektes zu
rekonstruieren. Die vierte Dimensionen kann durch eine Menge von Würfeln aus Abbildung
2.b veranschaulicht werden, wobei jeder Würfel für eine bestimmte Transaktionszeit steht.
Das Modell hierzu wäre das bitemporale Modell ( Abschnitt 4.3) oder BCD-Modell
(Abschnitt 5).
4. Temporale Datenmodelle
Def. : Ein Datenmodell ist ein formaler Rahmen zur Beschreibung von Datenstrukturen und
Operationen auf Daten. Es wird angenommen, daß die abzuspeichernde Information
mit Hilfe von Objekten und Beziehungen zwischen Objekten modelliert werden kann.
[“Theoretische Grundlagen relationaler Datenbanksystemen“ von Kanzia, 1993]
4.1 Gültigkeitszeitmodell
Das
Modell von Jones ist im Rahmen der LEGOL2 im Jahre 1979 entstanden. Die
Modellierung erfolgt durch die zwei Zeitattribute start und stop, welche ein Intervall
definieren in dem der Fakt seine Gültigkeit besitzt. Die Angabe der Zeitwerte ist explizit, das
heißt sie wird durch den Benutzer eingegeben.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
8
Modell von Jones
Name
Vorlesung
Start
Stop
Detlef
Inf 1
1
2
Franz
Inf 1
1
1
Franz
Inf 2
3
4
Abb. 3 Modell von Jones
Ein anderes Beispiel wäre hierfür das Modell von Clifford, bei welchen sowohl den Tupeln
als auch den Attributen die Gültigkeitszeit zugewiesen
4.2 Transaktionszeitmodell
Bei einem Transaktionszeitmodell wird immer dann, wenn ein Fakt in der Datenbank
gespeichert, geändert oder gelöscht wurde, die exakte Zeit der Operation vermerkt. Dieser
Zeitstempel oder auch TIMESTAMP ist implizit, also vom User nicht beeinflußbar, sondern
direkt von der Systemuhr bestimmt.
Name
Gehalt
Intervall
[a]
Name
Gehalt
Intervall
Karl
30000
[1,now]
Hugo
40000
[1,now]
Name
Gehalt
Intervall
Karl
30000
[1,now]
Hugo
40000
[1,3]
[b]
Name
Gehalt
Intervall
Karl
30000
[1,now]
Hugo
40000
[1,now]
Detlef
55000
[2,now]
Detlef
55000
[2,now]
Heinz
27000
[3,now]
[c]
Abb. 4: Transaktionszeitmodell
Besonderer Beachtung gilt hier der now Variable, denn durch sie wird ausgedrückt, daß der
Fakt bis zum jetzigen Zeitpunkt aktuell ist. Zur näheren Erklärung ist zu erwähnen, daß die
Transaktionszeit auf die Gegenwart beschränkt ist.
Beim obigen Beispiel war die Datenbank zu Beginn leer, dann wurden zum Zeitpunkt 1 [a]
Hugo und Karl hinzugefügt. Zum Zeitpunkt 2 [b] ist Detlef hinzugefügt worden, welches
eindeutig an seinem Zeitstempel [2,now] ablesen werden kann. Zu guter Letzt wird zum
Zeitpunkt 3 [c] Heinz hinzugefügt und Hugo gelöscht. Alle veränderten oder gelöschten
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
9
Informationen bleiben auch weiterhin in der Datenbank verzeichnet, daher ist dieses Modell
sehr für Write-Once-Datenträger geeignet.
Ein weiteres Beispiel für ein Transaktionszeitmodell wäre das Modell von Jensen, welches
neben der Transaktionszeit noch ein zusätzliches Backlog-Feld benutzt. In diesem Feld
werden die Operatoren verzeichnet, mit denen das Objekt verändert wurden (insert, delete,
update). Damit ist die Geschichte des Objektes durch Backlog nachvollziehbar.
4.3 Bitemporales Modell
Ein bitemporales Modell zeichnet sich daher aus, daß es sowohl Gültigkeitszeit als auch
Transaktionzeit besitzt. Die obige Tabelle soll verdeutlichen, welche verschiedenen
Relationen zwischen diesen Zeitwerten möglich sind.
[d]
[c]
[b]
[a]
Abb. 5: Zeitverhältnisse im Bitemporalen Modell
[a]
Information ist sofort gültig (X = Y)
[b]
Änderung in der Zukunft, Information wird erst noch gültig (X < Y)
[c]
rückwirkende Änderung, Information war schon gültig (X > Y)
[d]
Änderung der Gültigkeitszeit, zur Terminierung in der Zukunft
Durch die dargestellten, verschieden Möglichkeiten zum Verhältnis von Gültigkeitszeit und
Transaktionszeit zueinander, ist es möglich die Geschichte des Objektes bzw der Information
über einen bestimmten Zeitraum nachzuvollziehen. Das wohl bekannteste bitemporale Modell
ist das BCDM, welches im Anschluß näher vorgestellt wird.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
10
5. BCD Modell
Das BCDM (bitemporal conceptual data model) wurde 1993 vom
TSQL2 Language Design Commitee als Teil und Grundlage des
Sprachvorschlages TSQL2 entworfen. Diesem Komitee gehörten unter
R. T. Snodgrass
anderen R. Snodgrass, J. Clifford, und C. Jensen an.
Als konzeptionelles Datenmodell soll es die Semantik temporaler Daten
möglichst einfach und deutlich darstellen können, ohne dabei
besonderen Wert auf eine möglichst effiziente Realisierung zu legen.
Das BCDM ist ein erweitertes relationales Datenmodell, d.h. die
Konzepte des relationalen Modells wurden übernommen und erweitert .
Christian Jensen
Abb.6. - Personen
5.1 Eigenschaften
Die Tupel des BCDM besitzen Transaktions- und Gültigkeitszeit, sie sind also bitemporal.
Weiterhin basiert dieses Modell auf der diskreten Zeit, und hat als kleinste Einheit das
Chronon (c). Die Chronons haben eine implementierungsabhängige Länge, denn je genauer
die physische Repräsentationsform gewählt wird, desto kleiner wird die Länge des Chronons.
Gültigkeitszeitdomain
DGZ = {t1, t2, t3, ...,tk }
Transaktionszeitdomain
DTZ = {t´1, t´2, t´3, ... , t´k }  {UC}
Einen gesondert zu behandelnden Wert bezeichnet das Schlüsselwort UC (until changed).
Dieser Wert wird im Fallbeispiel 5.2 noch näher erklärt.
Tupel einer bitemporalen Relation
Tb ⊆ DTZ x DGZ
Hierbei muß aber beachtet werden, daß zwei Tupel in einer bitemporalen Relation nie
wertegleich sein dürfen. Daher muß die Geschichte in den Tupeln selbst vermerkt sein.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
11
5.2 Fallbeispiel
Beispiel :
„Zum Zeitpunkt 5 wird vom Personalchef eines Kaufhauses festgelegt, daß Herr Meier für das
Zeitintervall 11-44 in der Arbeit Spielzeug arbeiten soll. Zum Zeitpunkt 15 meldet ein
Mitarbeiter, daß Herr Meier nicht in der Abteilung arbeitet. Der Personalchef verändert
daraufhin seine Konzeption und teilt Herr Meier nun im Zeitintervall 20-32 für die
Spielzeugabteilung ein. Bei der Feststellung des Mitarbeiters, daß Herr Meier zum Zeitpunkt
15 noch keine Spielzeuge verkaufte, handelte es sich um jedoch um einen Irrtum. Deshalb
übernimmt der Personalchef zum Zeitpunkt 25 wieder die ursprüngliche Arbeitseinteilung für
Herrn Meier.“
[“Anbindung von TSQL2 an ein objektorientiertes Datenbanksystem“ Arne Lange 1996]
Dieses Beispiel kann als Graph (Abb.7) oder als Tabelle (Abb.8) dargestellt werden.
Abb. 7: Bitemporale Aussage
Abb. 8: Bitemporale Relation mit Tupelstempelverfahren und nicht in erster Normalform
In der Tabelle sind bitemporale Elemente dargestellt, d.h. das für jedes gültige Tupel TZ x GZ
ein weiteres bitemp. Element hinzugefügt wird.
Wenn ein bitemp. Element aber die Form (UC, cv) hat, dann wird mit jedem verstreichenden
Transaktionszeitchronon (ct´) ein Tupel mit neuer Transaktionzeit eingefügt.
=> tbi= (UC,cv)
Vergangener Chronon ct´
tbi+1 = (ct , cv)
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
12
5.3 temporale Änderungsoperatoren
Im Rahmen des BCD-Modells, wie auch in TSQL2, sind verschiedene temporale
Änderungsoperationen möglich,wie Abbildung 9. verdeutlichen soll.
Abb. 9 – Verhältnisse von Gültigkeits – und Transaktioszeit
.
Temporales Einfügen (Insert)
Diese Operation fügt entweder neue Informationen ein oder verlängert Gültigkeitszeit von
bereits existierenden Daten.
Temporales Ändern (Update)
Ein Update verändert die existierenden Informationen und damit auch die Gültigkeitszeit. Wie
hier in unserem Beispiel: ABC war gültig bis zum Zeitpunkt X und danach war DEF gültig ab
dem Zeitpunkt X.
Temporales Löschen (Delete)
Die
Delete-Operation
verringert
Gültigkeitsdauer
von
vorhandenen
Informationen.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
existierender
13
6. TSQL2
6.1 Zeit in TSQL2
Temporale Anfragesprachen sind ein relatives junges Wissenschaftsgebiet und befinden sich
noch in den Kinderschuhen. Das kann man besonders daran erkennen, daß der temporale Teil
der bislang existierenden temporalen Anfragesprachen lediglich ein Aufsatz auf eine schon
existierende Anfragesprache darstellt und immer tunlichst auf Abwärtskompatibilität geachtet
werden mußte.
Die Zeit wird in TSQL2 linear und an beiden Enden begrenzt dargestellt (zum Beispiel von
JETZT bis NÄCHSTE ÄNDERUNG oder vom 23.6.98 bis 25.6.98). Dabei können die
Zeitlinien in temporalen Anfragesprachen diskret (isomorph zu den natürlichen Zahlen), dicht
(isomorph zu den rationalen Zahlen) und kontinuierlich (isomorph zu den reellen Zahlen)
sein, wobei in TSQL2 mit diskreter Zeit gearbeitet wird. Das TSQL2 zugrundeliegende
Modell ist das BCD-Modell (bitemporal conceptual data), das im Abschnitt 5 vorgestellt
wurde.
Die Darstellung der Zeit erfolgt mit „chronons“ (zum Beispiel 1999 oder 10-4 (für 10.4. oder
4.10.) oder 10:23 für Uhrzeiten). Die Granularität der Zeitdarstellung ergibt sich aus der Zahl
der chronons pro Zeitraum. Je mehr chronons man also verwendet, desto höher wird die
Granularität (zum Beispiel 1999 –jahresgenau- im Gegensatz zu 10-4-1999 10:23 –
minutengenau).
TSQL2 ist eine Obermenge von SQL92, das bedeutet die Sprache ist ein Aufsatz auf SQL92
und unterstützt deren Befehle und Datentypen mit einer geringfügigen Modifikation – der
Zeit.
In SQL92 existierten ohnehin schon die Datentypen DATE, TIME, TIMESTAMP und
INTERVAL zur Darstellung von Zeit. Diese wurden von TSQL2 adoptiert und um PERIOD
ergänzt. Der wesentliche Unterschied zwischen INTERVAL und PERIOD besteht darin, daß
INTERVAL eine Zeitdauer ohne Verankerung darstellt, wobei PERIOD eine Zeitspanne mit
Anfangs- und Endpunkt darstellt.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
14
6.2 Sprachkonstrukte in TSQL2
Wie bereits erwähnt, wurde TSQL2 nur um Zeit modifiziert und das Anliegen dieses
Abschnitts besteht darin, die wichtigsten Befehle und deren Veränderung anhand eines
Beispieles zu erläutern.
6.2.1 Der CREATE TABLE - Befehl
Zunächst werde eine Relation angestellter mit Hilfe des CREATE TABLE – Konstruktes
erstellt (siehe Abbildung 10). Diese Relation soll zustandsstabil sein und mit Transaktionszeit
versehen
werden
(bitemporal)
und
die
Granularität Tag haben (z.B. 10-4-99). Die
nichttemporalen Attribute der Relation sollen der
Name, der Vorname und das Gehalt der Person
sein.
Neu bei CREATE TABLE ist die AS - Klausel,
die den Zeitfolgetyp und die Granularität
Abb. 10: Erstellung von angestellter
festlegt. Dabei kann der TSQL2 - Benutzer zwischen sechs verschiedenen Zeitfolgetypen
auswählen (Abbildung 11).
Zeitfolgetypen
Dabei hat man auch die Möglichkeit die „normalen“ (sprich die aktuellen) Daten, wie sie in
SQL92 vorkommen, zu gebrauchen indem man bei der Deklaration das Schlüsselwort
SNAPSHOT angibt. Zusätzlich besteht die Möglichkeit, die Relationen als zustandsstabil
(ohne beziehungsweise mit Transaktionszeit), ereignisorientiert (ohne beziehungsweise mit
Transaktionszeit) oder gar nur mit Transaktionszeit zu deklarieren (siehe Abbildung 12). Eine
kontinuierliche Zeitfolge wird gewährleistet durch ein stetiges Aktualisieren der
ereignisorientierten Zeitfolge.
1.) Snapshot
2.) AS VALID STATE
 zustandsstabil
AS VALID STATE
3.) AS VALID EVENT
[AND TRANSACTION]
4.) AS TRANSACTION
 ereignisorientiert
AS VALID EVENT
5.) AS VALID STATE AND
[AND TRANSACTION]
TRANSACTION
 kontinuierlich
AS VALID EVENT
6.)
AS VALID EVENT AND
[AND TRANSACTION]
TRANSACTION
(mit hoher Aktualisierung)
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
15
Abb. 12: Die gebräuchlichsten Zeitfolgetypen
Abb. 11: Alle Möglichkeiten
6.2.2 Der INSERT - Befehl
In der soeben erschaffenen Relation angestellter soll nun ein
Objekt eingefügt werden. Um in eine TSQL2 – Relation ein
Objekt einzufügen zu können, benötigt man, genauso wie in
Abb. 13.
SQL92 den INSERT – Befehl. Ähnlich wie bei CREATE kann man auch bei INSERT eine
Veränderung im Gegensatz zu SQL92 erkennen – die VALID PERIOD – Klausel. Diese
drückt die Start- und Endzeit aus, in dem das Objekt in der modellierten Welt gültig ist, sprich
die Gültigkeitszeit. Läßt man beim Einfügen eines Objektes die VALID PERIOD – Klausel
weg, so werden vom DBMS (data base management system) Standardwerte angenommen
(sofern die Relation mit Gültigkeitszeit deklariert wurde). Diese wären das aktuelle Datum
(Systemzeit, die vom DBMS vergeben wird) als Startzeit und eine ungebundene Variable
NOW als Endzeit.
Im Vorfeld wurde erläutert, daß TSQL2 auf dem BCD – Modell basiert und die Variable
NOW das Pendant zu UNTIL CHANGED (UC) darstellt. Die Transaktionszeit wird vom
DBMS implizit vergeben; der Anwender muß sich nicht darum kümmern (sofern die Relation
Transaktionszeit enthält). Nach Anwendung des Befehls in Abbildung 14 erhält man die
entsprechende Tabelle.
NAME
VORNAME
GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – NOW]
[10-5-98 – NOW]
Abb. 14: Das erste Objekt wird eingefügt
Am 1. August wird in der Firma entschieden, daß Rick Meier ab 1. September ein
unbefristetes Gehalt von 5000 Geldeinheiten beziehen soll. Um diese Änderung
vorzunehmen, schreibt man in die VALUES – Klausel die entsprechenden nichttemporalen
Daten und ist gezwungen
die VALID PERIOD – Klausel anzuwenden, die das Intervall für die Gültigkeitszeit des
neuen Objekts enthält (siehe Abbildung 15 ).
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
16
Da Rick Meier ein unbefristetes Gehalt beziehen soll, steht der wirkliche Endpunkt der
Gültigkeitszeit noch nicht fest. TSQL2 stellt dafür den Systemwert CURRENT_TIME zur
Verfügung . Sobald also das Objekt verändert wird, wird die Startzeit des neuen Objekts
eingesetzt.
NAME
VORNAME
GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – 1-8-98]
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – NOW]
[10-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Abb. 15: Das alte Objekt (Entity) wird nicht gelöscht (Änderung am 1. August)
Auffällig ist, daß das Objekt (Meier, Rick, 3500) zweimal vorkommt. Dies ist ein weiterer
Vorteil von TSQL2 und von temporalen Datenbanksystemen generell. Sie gestatten es die
Geschichte aufzunehmen. So geschah es, daß das ältere Objekt (Meier, Rick, 3500) nur in der
Transaktionszeit verändert wurde (der Tag der Änderung ist der Endpunkt des alten Tupels)
und die Gültigkeitszeit unverändert blieb. Dafür erstellte das Datenbanksystem ein neues
Objekt, welches die gleichen nichttemporalen Attribute besitzt, dafür aber unterschiedliche
Intervalle in der Transaktions- und Gültigkeitszeit. Dabei setzt TSQL2 die NOW - Variable
der Transaktionszeit des alten Objekts auf das Datum der Systemzeit (also die Zeit der
Änderung) und im neuen Tupel die Systemzeit als Startzeit und UNTIL CHANGED (NOW)
als Endzeit. Dies geschieht sowohl im neuen Tupel (Meier, Rick, 3500) als auch im Tupel
(Meier, Rick, 5000). In der Gültigkeitszeit erhält das Tupel (Meier, Rick, 5000) als Startzeit
den 1. September und eine undefinierte Endzeit.
Am 6. August fällt dem Personalbüro auf, das Rick Meier eigentlich schon seit dem 1. Mai
des Jahres 98 in der Firma angestellt ist, statt des eingetragenen 10. Mai. Wenn nun der
entsprechende INSERT Befehl ausgeführt wird, ergibt sich die Tabelle (Relation) in
Abbildung
16.
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
17
NAME
VORNAME
GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – 1-8-98]
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Abb. 16: Die Relation angestellter nach der Änderung am 6. August
Das Merkwürdige ist, daß in der VALID PERIOD – Klausel das Intervall vom 1. bis 11. Mai
läuft, Rick Meier doch aber ein Gehalt von 3500 Geldeinheiten pro Monat bis zum 1.9. erhält
in der Tabelle aber kein Tupel die Gültigkeitszeit von 1.5. bis 11.5. besitzt.
Das liegt an der Tatsache, daß TSQL 2 die Fähigkeit hat, Objekte, deren nichttemporale
Attribute gleich sind und deren Gültigkeitszeit sich überlappen, zusammenzufassen. So
erkennt das System, daß diese Situation vorliegt. Es schließt das alte Tupel mit der
Änderungszeit ab (Zeile 2 in der Tabelle von Abbildung 16) und erschafft ein neues, das die
vereinigte Gültigkeitszeit enthält.
Am 10. August beschließt die Firma einen neuen Mitarbeiter einzustellen, der Kai Schulze
heißt und einen befristen Arbeitsvertrag vom 3. September bis zum 5. Oktober für 1500
Geldeinheiten erhalten soll. Dazu wendet man auf die Relation angestellter den in Abbildung
17 dargestellten INSERT - Befehl an, die dann das neue Objekt enthält.
NAME
VORNAME
GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – 1-8-98]
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
1500
[10-8-98 – NOW]
[3-9-98 – 5-10-98]
Abb. 17: Die Relation angestellter nach der Änderung am 10. August
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
18
6.2.3 Der UPDATE – Befehl
Am 11. August beschwert sich der Angestellte Kai Schulze
beim Chef, daß er nur lächerliche 1500 Geldeinheiten
verdiene und doch die meiste Programmierarbeit mache. Der
Chef sieht das ein und weist eine Gehaltserhöhung von 1500 auf 4500 Geldeinheiten an. Da
sich die Gültigkeitszeit (sprich die Vertragsdauer) nicht ändert, wendet man den UPDATE –
Befehl an, um diese Änderung vorzunehmen. Der UPDATE – Befehl enthält jetzt auch wie
der INSERT – Befehl die VALID PERIOD – Klausel. Um also die Datenbank auf den
neuesten Stand zu bringen, wendet man den UPDATE - Befehl an und der resultiert in der
neuen aktualisierten Relation angestellter, dargestellt in Abbildung 18.
NAME
Meier
VORNAME
Rick
GEHALT
3500
TRANSACTION
[10-5-98 – 1-8-98]
VALID
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
1500
[10-8-98 – 11-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[11-8-98 – NOW]
[3-9-98 – 5-10-98]
Abb. 18: Änderung am 11. August (keine VALID PERIOD – Klausel im Befehl)
Der Befehl bewirkte nun die Erstellung eines neuen Objektes, das sich gegenüber von
(Schulze, Kai, 1500) nur im Gehalt und natürlich in der Transaktionszeit unterscheidet.
6.2.4 Der DELETE – Befehl
Am 13. August beschließt der Chef, daß Kai Schulze doch
nur vom 13. September bis zum 5. Oktober in der Firma
benötigt wird und verkürzt unter Einwilligung von Herrn
Schulze die Vertragsdauer. Um diese Änderung auch in einer TSQL2 – Datenbank
vorzunehmen, benötigt man den DELETE – Befehl, der ebenfalls um die VALID PERIOD –
Klausel erweitert wurde. Die WHERE – Bedingungen können durch logische Operatoren, wie
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
19
man sie aus Hochsprachen kennt, verbunden werden. Um jetzt die Vertragszeit zu verkürzen,
muß der Anwender die Zeit eingeben, die abgezogen werden soll.
So wird dann die Tabelle (respektive Relation), wie in Abbildung 19 zu sehen, modifiziert.
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – 1-8-98]
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
1500
[10-8-98 – 11-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[11-8-98 – 13-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[13-8-98 – NOW]
[13-9-98 – 5-10-98]
Abb. 19: Änderung am 13. August
Dabei kann man erkennen, daß im eigentlichen Sinne überhaupt nicht gelöscht wurde,
sondern sogar noch ein neues Tupel hinzugefügt, einfach um die Geschichte nachvollziehen
zu können. Die Transaktionszeit des neuen Tupels erhält als Startzeit die Endzeit, des in der
VALID PERIOD – Anweisung befindlichen Intervalls. Die Endzeit der Gültigkeitszeit bleibt
unverändert, da das Intervall nur bis zum 13. September läuft.
6.2.5 Die SELECT – Anweisung
Nachdem wir die Datenbank erschaffen haben, möchten wir
jetzt auch auf sie zugreifen können. Um das zu realisieren,
bedarf es der SELECT – Anweisung. Der Vorteil von TSQL2
gegenüber SQL92 zeigt sich dann erst richtig. Der Anwender
kann nämlich jetzt aussuchen, ob er die aktuellen Daten haben möchte (Snapshot) oder die
Daten, wie sie an einem bestimmten Tag waren (historische Betrachtung). Um von unserer
Relation angestellter eine Snapshot - Selektion zu machen, führen wir folgende Anweisung
aus (siehe Abbildung 20): Dieser einfache Befehl bewirkt, daß das DBMS die
Transaktionszeiten aller in der Relation befindlichen Tupel durchforstet und die zur Anfrage
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
20
gültige Systemzeit mit den Intervallen vergleicht. Befindet sich die
Systemzeit in dem Intervall eines speziellen Tupels, so taucht
dieses Tupel in der Zielrelation auf (im folgendem Beispiel alle
Abb. 20
Tupel mit NOW). Nehmen wir an, wir hätten die Anfrage (Abb.
20) am 4. September gemacht, so würden wir die in Abbildung 21 abgebildete Zielrelation
erhalten. (Zur besseren Übersicht wurde die Ausgangsrelation angestellter noch einmal
abgebildet)
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – 1-8-98]
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
1500
[10-8-98 – 11-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[11-8-98 – 13-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[13-8-98 – NOW]
[13-9-98 – 5-10-98]
Ursprungsrelation angestellter
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
4500
[13-8-98 – NOW]
[13-9-98 – 5-10-98]
Abb. 21: Die am 4.9. gestellte Anfrage ergibt die Zielrelation angestellter‘
Diese Anfrage gibt sozusagen die Sicht auf die Datenbank, die zur Anfragezeit aktuell ist.
Möchte man jetzt die Gehaltszeitfolge von Rick Meier erfragen, so wendet man den in
Abbildung 22 befindlichen SELECT – Befehl an, der ebenfalls am 4.9. benutzt wird.
Damit ergibt sich die Relation angestellter‘‘.
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
21
Abb. 22: Gehaltszeitfolge von Rick Meier
Es gibt natürlich nicht nur die Möglichkeit, die zur Anfragezeit (Systemzeit) gültigen Tupel
abzufragen, es ist auch möglich, Anfragen über die modellierte Zeit zu machen. So kann man
zum Beispiel anfragen, zu welchen Daten welche Mitarbeiter angestellt sind. In unserem
Beispiel aus Abbildung 23 fragen wir, welche Angestellten die Firma zwischen dem 3.
September und dem 6. November beschäftigt.
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
4500
[13-8-98 – NOW]
[13-9-98 – 5-10-98]
Abb. 23: zwischen 3. und 6. September beschäftigte Angestellte
Wir sehen, daß man in TSQL2 mit Hilfe der Funktion VALID() auf die Gültigkeitszeit
zugreifen kann. Natürlich gilt dies auch für die Transaktionszeit, die durch TRANSACTION
erreicht werden kann. Zusätzlich haben wir einen Operator angewendet, von welchem wir
vorher noch nichts gehört haben. Es handelt sich hierbei um einen Vergleichsoperator, von
denen es in TSQL2 insgesamt vier gibt.
Die Vergleichsoperatoren sind Operatoren über Intervallen der diskreten Zeit. Das bedeutet,
daß die Zeit durch natürliche Zahlen darstellbar sein muß (11-3-98 und 12-3-98, dazwischen
ist nichts). In Abbildung 24 sind die Operatoren und eine bildliche Darstellung zu sehen.
Abb. 24: Binäre Funktionen in TSQL2 über Zeit
Es gibt viele Anwendungsgebiete, bei denen eine geschichtliche Zurückversetzung gefordert
wird. Mit Hilfe von TSQL2 ist solch eine Betrachtung möglich. Dabei ist klar, daß man die
Transaktionszeit über den SELECT – Befehl explizit ansprechen muß. Als Beispiel soll
wieder unsere Relation angestellter dienen. Es soll nun herausgefunden werden, wie die
Situation in der Firma an einen gegebenen Tag war, in diesem Fall am 2. August 98
(Abbildung 25).
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
22
Dabei
geschieht
ein
Zugriff
auf
die
Transaktionszeit
mit
Hilfe
der
Funktion
TRANSACTION() und es wird kontrolliert, ob die Transaktionszeit die Zeitmarke 2-8-98
überlappt.
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[10-5-98 – 1-8-98]
[10-5-98 – NOW]
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
3500
[6-8-98 – NOW]
[1-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Schulze
Kai
1500
[10-8-98 – 11-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[11-8-98 – 13-8-98] [3-9-98 – 5-10-98]
Schulze
Kai
4500
[13-8-98 – NOW]
[13-9-98 – 5-10-98]
Ursprungsrelation angestellter
NAME
VORNAME GEHALT
TRANSACTION
VALID
Meier
Rick
3500
[1-8-98 – 6-8-98]
[10-5-98 – 1-9-98]
Meier
Rick
5000
[1-8-98 – NOW]
[1-9-98 – NOW]
Ergebnisrelation nach Anwendung des SELECT - Befehls
Abb. 25 Die Sicht vom 2. August
6.3 Ein Vergleich
Im folgenden soll gezeigt werden, was passiert, wenn man versucht, Zeit in SQL92 zu
gebrauchen. Um Zeit in SQL92 darzustellen benötigt man zusätzliche Attribute, da es kein
PERIOD Datentyp gibt. So benötigt man, um ein Intervall darstellen zu können, zwei
Attribute Start und Stop (oder ähnlich) für die Start- und die Endzeit des Intervalls. Außerdem
sind Vergleichsoperatoren wie in TSQL2 nicht gegeben und so müssen umfangreiche
Selektionen benutzt werden, um die gleichen Ergebnisse zu erzielen für Anfragen, die nur
wenige Zeilen Code in TSQL2 erfordern. Möchte man zum Beispiel das aktuelle Gehalt von
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
23
Rick Meier erfragen, ergeben sich folgende Anfragen in SQL92 (Abbildung 26) und in
TSQL2 (Abbildung 27):
Abb. 27: TSQL2
Abb. 26: SQL92 - Anfrage
Wie man sehen kann, sind temporale Datenbanksysteme ein Fortschritt hinsichtlich der
Implementierung von Zeit, doch TSQL2 ist nicht der einzige Ansatz Zeit in ein DBMS
einzubinden.
6.4 Weitere temporale Datenbanken
In der relativ kurzen Zeit dieser jungen Wissenschaft, gab es schon viele Ansätze. Da
temporale Datenbanken besonders geeignet sind zum erfassen von Viehbeständen und
anderen agrarischen Dingen, entwickelte die Landwirtschaftsuniversität Athen einen
temporalen SQL92 – Aufsatz IXSQL, der auf Intervallen basiert. Ein weiteres auf SQL92
aufbauendes System existiert mit ATSQL, welches auf dem relationalen Datenmodell
aufbaut. SQL/Temporal gebraucht Konstrukte von TSQL2 und ATSQL und erlaubt doppelte
Tupel. In SQL/TP existiert eine weitere Erweiterung von SQL92 und mit TOQL besteht auch
die Möglichkeit für das objektorientierte Datenmodell, die Vorzüge von temporalen
Datenbanksystemen auszunutzen.
7. Zusammenfassung
Zusammenfassend kann gesagt werden, daß die bitemporale Datenhaltung durchaus eine
komplexe Angelegenheit ist,daß sie aber durch den Eisatz geeigneter Mittel effizient und
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe
24
sicher implementiert werden kann. Im Laufe der nächsten Jahre werden auf diesem Gebiet
sicherlich noch größere Forschritte zu verzeichen seien, da die temporale Datenhaltung grosse
Vorteile beinhaltet,wie wir hoffentlich gezeigt haben.
Literaturverzeichnis

“Anbindung der temp. Anfragesprache TSQL2 an ein objektorientiertes
Datenbanksystem“, Universität Rostock, Diplomarbeit, Arne Lange, 1996

”TSQL2 Language Specification”, u.a. R.T. Snodgrass Sept., 1994

“Temporale Datenbanken“, Seminar Uni. Rostock, W. Schmidt, SS 1996

“Temporal Databases: theory, design and implementation” Benjamin Cummings 1993

“Das temporale Datenmodell”, Seminar Universität Jena, Alexander Hermann, 2001

“The TSQL2 Temporal Query Language”, Kluwer Academic Publication, R.T. Snodgrass, 1995

“Temporal Database System Implementations,” ACM SIGMOD Record, M.H. Böhlen,
1995

“Temporale Datenbanken und TSQL2“, Universität Rostock, Bernd Griefahn, 1997
Temporale Datenbanken © Stefan Scheidewig & Daniel Lempe