FernUniversität
Gesamthochschule in Hagen

LG Prakt. Informatik IV

Seminar SS 1996: Temporale Datenbanken

Das Temporale Datenmodell nach Gadia

Wolfgang Schmidt

Dokumentenbasis: [Tans94]/Kapitel 2

Inhaltsverzeichnis

1. EINFÜHRUNG / MOTIVATION 3

2. DAS TEMPORALE DATENMODELL 3

2.1 Der Datentyp `temporal element′ 3
2.2 Attributwerte als `temporal assignment′ 4
2.3 Tupel / Relationen 4
2.4 Snapshot Equivalence 5
2.5 Restruktuierung bei Schlüsselwechsel 6
2.6 Integrierung verschiedener Arten zeitlicher Daten 6

3. DIE ABFRAGESPRACHE TEMPSQL 7

3.1 Tupel-Navigation über `temporal expression′ 7
3.2 Das SELECT-Statement und die WHILE-Kausel 8
3.3 Restrukturierung im SELECT-Statement 9
3.4 Aggregation 10
3.5 User und deren Zeitbereiche 10
3.6 Überblick: Select-statement 10
3.7 Multihomogenität 10

4. ANWENDUNGSBEISPIELE FÜR DAS TDMG 10

4.1 Ein Modell für die Abfrage von DB-Transaktionen 10
4.1.1 Transaktions-Logfile als Informationsbasis 10
4.1.2 Zero-Information-Loss Modell 10
4.1.3 Beispiel-Abfragen 10
4.1.4 Ausdrücke / Operatoren 10
4.2 Ein Modell für die Abfrage von Fehlerinformationen 10
4.2.1 Das bitemporale Element 10
4.2.2 Identitätsproblematik 10
4.2.3 temporale Ausdrücke für verschiedene Fehlerarten 10

5. ZUSAMMENFASSUNG 10

6. LITERATURVERZEICHNIS 10

1. Einführung / Motivation

Das Temporale Datenmodell nach Gadia (TDMG) ist ein auf dem Relationenmodell basierender Ansatz zur Modellierung temporaler Daten. Dazu wird von S.K.Gadia und S.S.Nair eine Erweiterung zu SQL, TempSQL, beschrieben, die die Möglichkeiten des erweiterten Ansatzes in einer DML zur Verfügung stellt [Tans94].
Dem Datenmodell zu Grunde liegender Datentyp für `Zeit′, die Zeitabbildung in Attributen, Tupeln und Relationen sowie die Abfragesprache TempSQL, mit ihren Gemeinsamkeiten und Erweiterungen zu SQL, wird beschrieben.

Weiterhin werden Anwendungsbeispiele für das TDMG exemplarisch beschrieben, wie ein Modell für die Abfrage von DB-Transaktionen und ein Modell für die Abfrage von Fehlerinformationen. Diese Darstellungen zeigen Nutzen des Modells auf Grundlage einer Weiterentwicklung des Basismodells.

2. Das Temporale Datenmodell

Die Basis des TDMG ist das Relationenmodell. Es wird erweitert um den Aspekt: der Zeit, genauer der diskreten Zeit. Hierbei ist die Besonderheit gegenüber anderen Modellen, daß die Zeit nicht den Tupeln (einer Relation), sondern den (einzelnen) Attributen (jedes Tupels) zugewiesen ist.
Die Vorteile sind insbesondere die Flexible Modellierung und die leichte Anpassbarkeit auf verschiedene Anforderungen. (siehe Anwendungsbeispiele/Kapitel 4)
Als `Nachteile′ ist die Komplexitätssteigerung bzgl. Modellierung & Realisierung zu nennen, sowie die Tatsache hervorzuheben, daß die temporalen Relationen nicht mehr in der 1. Normalform sind.

2.1 Der Datentyp `temporal element′

Der zentrale Datentyp im TDMG ist das `temporal element′, welcher als endliche Vereinigung von Zeitintervallen definiert ist, z.B.: [11,20] ? [31,40].
Es werden also keine Intervalle als Datentyp verwendet, was das TDMG von anderen Ansätzen unterscheidet.
Die Verwendung von temporal elements hat u.a. den Vorteil, daß Operationen, wie die Vereinigung, Durchschnittbildung und Komplementbildung abgeschlossen sind. Damit sind die Abgeschlossenheitseigenschaften (bzgl. der Menge der temporalen Elemente) gegeben, womit eine Boolesche Algebra gegeben ist.

In den Zeitabschnitten, die durch die Teilintervalle eines temporal elementsbeschrieben werden, kann das Attribut verschiedene Werte seines Wertebereichs annehmen (siehe Abschnitt 2.2).

Bemerkenswert ist die Erweiterungsfähigkeit des Basis-Datentyp `temporal element′ wie z.B. bitemporales Element. Die leichte Anpassbarkeit des TDMG auf verschiedene Anwendungsfälle resultiert u.a. aus dieser Erweiterungsfähigkeit.

2.2 Attributwerte als `temporal assignment′

Die Attributwerte in klassischen Datenbanken sind atomar (1NF). Der Attributwert im TDMG ist eine Funktion der Zeit, ein temporal assignment, d.h. einen Zuweisung von einem temporalen Element in den Wertebereich des Attributs.

Beispiel für das Attribut Familienstand :

?: ([1968,1990] ledig, [1991, NOW] verheiratet)
Hier ist der Wert des Attributs Familienstand in der Zeit 1968 - 1990 : ledig, und in der Zeit 1991 - heute : verheiratet .

In diesem Rahmen ist der `temporal domain′ eines ′temporal assignment′definiert, welcher der Zeitbereich (OHNE Lücken) ist, in dem das Attribut definiert ist.

Beispiel: [[?]] = [1968, NOW]

Nochmals zu erwähnen ist die Tatsache, daß die Attributwerte sind nicht atomar sind. Diese Nichtatomarität entsteht, wegen der Einführung des temporal assignment.

2.3 Tupel / Relationen

Ein Tupel ist die Konkatenation von Assignments; eine temporale Relation ist die Menge von Tupeln (wie auch im nicht-temporalen Fall).

Im temporalen Fall ist jedoch ein Tupel mit einem Realweltobjekt inkl. der gesamten Historie gleichzusetzen, denn in den Attributen spiegelt sich die Entwicklung des Objekts wieder. Der Schlüssel eines Tupels/Objekts ist zeitinvariant zum Zweck der eindeutigen Identifikation.

Eine Forderung, für den einfachen Fall, ist die Homogenität, d.h. das alle Attribute eine Tupels denselben Zeitbereich (time domain) haben.

Beispiel-Relationen:

NAME	SALARY	DEPT
[11,60] John	[11,49] 15 K [50,54] 20 K [55,60] 25 K	[11,44] Toys [45,60] Shoes
[0,20]_[41,51] Tom	[0,20] 20 K [41,51] 30 K	[0,20] Hardware [41,51] Clothing
[71,NOW] Inga	[71,NOW] 25 K	[71,NOW] Clothing
[31,NOW] Leu	[31,NOW] 15 K	[31,NOW] Toys
[0,44]_[51,NOW] Mary	[0,44]_ [51,NOW] 25 K	[0,44]_[51,NOW] Credit

Tabelle: emp

Tabelle: management

2.4 Snapshot Equivalence

Eine Snapshot-Relation (snapshot) ist wie folgt definiert:
Sei r eine (temporale) Relation, dann ist ein snapshot von r auf den Zeitpunkt t die Relation, die man erhält, wenn alle Tupel auf den Zeitpunkt t eingeschränkt werden.

DEPT	MANAGER
[11,49] Toys	[11,44] John [45,49] Leu
[41,47]_[71,NOW] Clothing	[41,47] Tom [71,NOW] Inga
[45,60] Shoes	[45,60] John

Wegen der Homogenität entstehen bei snapshots keine Nullwerte in den Ergebnistabellen.

DEPT	MANAGER
[11,49] Toys	[11,44] John [45,49] Leu
[41,47]_[71,NOW] Clothing	[41,47] Tom [71,NOW] Inga
[45,60] Shoes	[45,60] John

Beispiel:
Relation management zum Zeitpunkt/Moment/instant NOW (management|_NOW)

Tabelle: management

DEPT	MANAGER
NOW Clothing	NOW Inga

Tabelle: management|_NOW

Dabei sind die Attribute in Snapshots mit `timestamped values′ versehen, ansonsten sind es `normale′ klassische Relationen.

Hierzu wird der Begriff `Weak Equality′, bzw. `Snapshot Equivalenz′ definiert:

Zwei Relationen r und s sind snapshot equivalent , wenn zu jedem Zeitpunkt t die snapshots von r und s gleich sind.
Snapshot equivalent: r ? r : K (snapshot equivalent zum Ursprung)
 

Damit wird ein Vergleich von temporalen Tabellen möglich.

2.5 Restruktuierung bei Schlüsselwechsel

Eine Besonderheit, die durch die Objekt-Historienhaltung in einem Tupel (Nicht-Atomarität) gegeben ist, ist die Strukturänderung beim Schlüsselwechsel. Bei klassischen Relationen führt ein Schlüsselwechsel zu keiner Strukturänderung und daher gibt es dort das Problem der Restrukturierung nicht.

Beispiel: Relation management mit dem Schlüssel DEPT.

DEPT

MANAGER

[11,49] Toys

[11,44] John [45,49] Leu

[41,47]_[71,NOW] Clothing

[41,47] Tom [71,NOW] Inga

[45,60] Shoes

[45,60] John

DEPT

MANAGER

[11,44] Toys [45,60] Shoes

[11,60] John

[45,49] Toys

[45,49] Leu

[41,47] Clothing

[41,47] Tom

[71,NOW] Clothing

[71,NOW] Inga

Tabelle: management Tabelle: management: MANAGER

Annahme: MANAGER ist auch Schlüssel bezogen auf die Snapshot-Relation
Damit erfolgt beim Schlüsslwechsel eine Restrukturierung, da der Schlüssel zeitinvariant sein muß.

Die Relationen sind nicht gleich, haben z.B. noch nicht mal gleiche Anzahl an Tupeln,
aber sie sind snapshot equivalent .

2.6 Integrierung verschiedener Arten zeitlicher Daten

Im TDMG können verschiedene Arten zeitlicher Daten abgebildet werden.
Oben beschrieben wurden die `temporal data′.

Die statischen Daten, static data, haben die Eigenschaft einen konstanten Wert über [0, NOW] zu haben. Somit stehen die static data in engem Zusammenhang zu den `normalen′ nicht zeitbehafteten Daten.

Die Snapshot-Daten, snapshot data/relation, sind eine Momentaufnahme zu einem bestimmten Augenblick (temporal domain = single instant of time), und damit sind die Werte mit dem jeweiligen Zeitstempel versehen.

3. Die Abfragesprache TempSQL

Als Erweiterung von SQL, mit Wahrung der Abwärtskompatibilität, ist TempSQLvorgeschlagen.
Die Ausdruckstärke von TempSQL ist wie die des Relationen(-Tupel)-kalküls anzusetzen. Allgemein erwähnenswert ist das objektweise arbeiten in TempSQL, wegen der 1:1 Beziehung Objekt - Tupel.

3.1 Tupel-Navigation über `temporal expression′

In TempSQL wird die wertbezogene Navigation wie bei SQL verwendet.

Dabei sind die verwendete Ausdrücke: `temporal′, `boolean′ und `relational expressions′

temporal expression:
intuitiv `klarer′ Aufbau eines temporalen Ausdruck

B7 t _ [0,NOW] ist ein temporal expression

SALARY

[11,49] 15 K [50,54] 20 K [55,60] 25 K

B7 [[Attribut]] ist ein temporal expression
mit dem Ergebnis des temporal domains des Assignments

Beispiel:
[[SALARY]] = [11,60]

B7 [[A 3F B]], Sei 3F ein beliebiger (=,>,<,_,_,_,...) Operator,
dann ist [[A 3F B]] ein temporal expression

Ergebnis:
Zeitbereich in der die Attribute A und B in der 3F-Beziehung stehen
Beispiel: [[SALARY 3F 20]] = [11,49] 3F [55,60]

Zusatz:
gilt die Beziehung A 3F B,so folgt [[A 3F B]] 3F 3F

B7 [[e]], e relationaler Ausdruck

Konstrukt ermF6glicht mE4chtige Verschachtelungen in TempSQL-AusdrFCcken

Beispiel: [[Management]] = [11,60] 3F [71,NOW]

· Weiteres:

- Sind a und b temp.exp., so gilt dies auch fFCr: Vereinigung, Schnittbildung, Differenzbildung und Negation
- Sind a und b temp.exp., so ist die Teilmengenbeziehung a 3F b ein boolscher Ausdruck
- Sind a und b boolsche AusdrFCcke, so gilt dies auch fFCr: Konjunktion, Disjunktion und Negation

3.2 Das SELECT-Statement und die WHILE-Kausel

Die allgemeine (vereinfachte) Form ist:

select X : K
while t
from r₁, r₂, ..., r_n
where f

Die semantische Auswertung ist folgende:

· Kreuzproduktbildung der beteiligten Relationen
· Prüfung auf Bedingung f, für jedes erhaltene Tupel
· Einschränkung der erhaltenen Tupel auf time domain t
· falls das erhaltene Tupel nicht leer ist wird es ausgegeben
· evt. weitere zeitliche Einschränkung notwendig um Homogenität zu gewährleisten

Bei Verwendung des `:K′ Operators zum Schlüsselwechsel ist eine evt. Restrukturierung notwendig.

Die WHILE-Klausel schränkt also den Zeitbereich ein, in dem ein Tupel liegen muß, um ausgegeben zu werden!

Beispiel-Anfragen:

· Zeige die Manager von John!

· select MANAGER
while [[emp.DEPT=management.DEPT]]
from emp, management
where NAME = John
· Erläuterungen:
Hier kommt MANAGER aus management und NAME aus emp
Kreuzprodukt von emp und management
Zeitbereiche in denen die Dept-Einträge übereinstimmen
Zeitbereiche des so erhaltenen Tupels wird auf diesen temporal domain eingeschränkt.

· Wann hatte John einen Manager?

· [[ select MANAGER
while [[emp.DEPT=management.DEPT]]
from emp, management
where NAME = John ]]
· Erläuterungen:
temporal domain Operator um select-Ausdruck einfügen
Bildung des temporal domain des obigen Ergebnisses

· Zeige alle Daten der Mitarbeiter, während sie in der Abteilung TOYS arbeiteten und JOHN Manager irgendeiner Abteilung war?

· select *
while ([[DEPT=Toys]] ?
[[select *
while [MANAGER=John]]
from emp ]])
from emp

· Erläuterungen:
Hier wird eine Subquery in der WHILE-Klausel verwendet, wie dies auch in der SQL-WHERE-Klausel verwendet wird.
Man beachte den Zusammenhang zwischen der natürlichen Sprache und der TempSQL Umsetzung (und, oder, nicht <=> ?????, ? )

3.3 Restrukturierung im SELECT-Statement

Im Punkt 2.5 in der Modellbeschreibung wurde die Restrukturierung beschrieben.
Die Syntax in TempSQL zum Schlüsselwechsel ist `: K′.

Beispiel: Zeige die Manager, die mindestens in der Zeit [11,50] Manager waren.

Hierzu ist der Zugriff über den Schlüssel MANAGER notwendig
· Restrukturierung der Relation manager zu manager: MANAGER

select MANAGER
from mangement: MANAGER
where [[MANAGER]] ? [11,50]

DEPT	MANAGER
[11,44] Toys [45,60] Shoes	[11,60] John
[45,49] Toys	[45,49] Leu
[41,47] Clothing	[41,47] Tom
[71,NOW] Clothing	[71,NOW] Inga

Tabelle:
mangement: MANAGER

3.4 Aggregation

In Analogie zur HAVING-Klausel gibt es für den temporale Fall die DURING-Klausel
Der during-Ausdruck kann Aggregat-Operatoren enthalten

- im Gegensatz zum where-Ausdruck
- analog zum having-Ausdruck (boolean) ,der im Gegensatz zum where-Ausdruck, Aggregat-Operatoren enthalten kann

Beispiel-Anfrage:

· Gib die summierten Gehälter je Abteilung, während der Zeit, in denen das Durchschnittsgehalt < 20K war, für die Abteilungen, die das maximale Gehalt >= 15K war in jedem Zeitpunkt von 31 bis 40.

DEPT	SumSal
[11,NOW] Toys	[11,30] 15K [31,44] 30K [45,NOW] 15K

· select DEPT, sum(SALARY) SumSal
from emp
groupby (DEPT)
having [[max(SALARY) >= 15K]] ? [31,40]
during [[ave(SALARY) < 20K]]

· Ergebnisrelation:

3.5 User und deren Zeitbereiche

Das User-Konzept in einer TDB unterscheidet Classical- und "Normal"-User.
Der Classical USER hat time domain NOW. Für diesen werden Transformationen von SQL in TempSQL vom TDMBS automatisch vorgenommen.

Transformierungen wie z.B.:

from r1 ? from r1|_NOW
where ? while
A ? B ? [[A ? B]]
or ? ?
and ? ?
not ???
...
? keine Änderung notwendig beim Übergang DB ? TDB

Damit wird eine vollkommene Transparens für den Classical User erreicht, d.h. er bemerkt nicht, daß er mit einer TDB arbeitet.

Der SystemUser hat time domain [0, NOW]. Für die `normalen′ (neuen) Nutzer kann ein beliebiger time domain festgelegt werden (Standard: [0, NOW].), womit sich Sichten zeitlicher Natur realisieren lassen.

3.6 Überblick: Select-statement

Allgemeiner Aufbau

select select-Liste
while while-Ausdruck
from from-Liste
where where-Bedingung
groupby group-by-Liste
having having-Bedingung
during during-Ausdruck

- Die while- und during-Ausdrücke sind temporal expressions.
- Der during-Ausdruck kann Aggregat-Operatoren enthalten
- Analog kann der having-Ausdruck (boolean) ,im Gegensatz zum where-Ausdruck, Aggregat-Operatoren enthalten

3.7 Multihomogenität

Zum Abschluß der Basismodell/TempSQL Betrachtung ist ein Problem anzusprechen welches mit der Homogenität einhergeht:
Beim Tabellen-Kreuzprodukt (homogener Tabellen) ist die Ergebnisrelation nicht zwingend homogen:

Beispiel :

· Vergleiche die Gehaltshistorie von MA, so daß das aktuelle Gehalt des ersten MA kleiner ist als das des zweiten MA

· select emp.NAME NAME1, emp.SALARY SAL1;
e.NAME NAME2, e.SALARY SAL2
from emp e
where [[emp.SALARY|_NOW < e.SALARY|_NOW]] ???

· Erläuterungen:
Hier muß mit einer Tupelvariablen e gearbeitet werden, mit deren Hilfe aus derselben Relation verschiedene Tupel miteinander verglichen werden können. Der Bezug zum aktuellen Gehalt wird durch die Einschränkung auf NOW hergestellt. Der Schlüssel der Ergebnisrelation bildet sich aus der Menge der Schlüssel der Eingangsrelationen, hier emp und e.

· Ergebnisrelation:

NAME1	SAL1	NAME2	SAL2
[31,NOW] Leu	[31,NOW] 15K	[71,NOW] Inga	[71,NOW] 25K
[31,NOW] Leu	[31,NOW] 15K	[0,44]_[50,NOW] Mary	[0,44]_[50,NOW] 25K

Eine Generalisierung der Homogenität wird erreicht durch die Verallgemeinerung der Tupelhomogenität durch homogene Spaltenbereiche (Multihomogenität).

Diese Problem stellt sich nicht für den Classical-User, da dieser stets mit dem snapshot auf NOW arbeitet.

4. Anwendungsbeispiele für das TDMG

Als Anwendungsbeispiele für das TDMG als Basismodell kann man folgende
Modelle nennen, für die Abfrage

· von DB-Transaktionen
· von Fehlerinformationen
· unvollständiger Information
· räumlich-temporaler Information

Im weiteren werden die ersten beiden Anwendungsbeispiele näher betrachtet.

4.1 Ein Modell für die Abfrage von DB-Transaktionen

Es geht hierbei um die Möglichkeit die Transaktionen auf einer DB selbst zum Abfrageobjekt zu machen. Damit ist die Möglichkeit gegeben die Entwicklung einer DB nachzuvollziehen und ehemalige Ergebnisse von Abfragen zu rekonstruieren.

4.1.1 Transaktions-Logfile als Informationsbasis

Im Transaktions-Logfile (siehe Beispiel ) eines DBMS ist die gesamte Information gegeben, um oben formuliertes Ziel zu erreichen. Hierzu muß diese Information in eine Form gebracht werden, die es ermöglicht mit TempSQL darauf zuzugreifen.

Hierzu eine vereinfachende Annahme: Eine Query oder ein Update je Transaktion!

Beispiel:

T1: TT=8; USER=Mark.
insert (NAME: John, SALARY: 15K DEPT: Toys) in emp
with (AUTHORIZER=Don, REASON=New Employee)
T2: TT=40; USER Ryne.
modify (Name: John) tt to (SALARY: 20K) in emp
with (AUTHORIZER=Don, REASON=Raise)
T3: TT=42, USER=Vance.
Q1: What is John′s salary?
T4: TT=53; USER=Damon.
delete (NAME: John) in emp
with (AUTHORIZER=Don, REASON=Fired)

4.1.2 Zero-Information-Loss Modell

Die Form, in die die Informationen des Logfiles gebracht werden müssen, wird im Zero-Information-Loss Modell beschrieben. Darin werden drei Datenbereiche definiert:

· data store:
Der Datenbereich: klassischer temporaler Tabellen (hier: Tabellen mit Transaktionszeit)

Beispiel: Tabelle EMP nach obigen Transaktionen T1- T4:

NAME

SALARY

DEPT

[8,52] John

[8,39] 15K [40,52] 20K

[8,52] Toys

NAME

TT

AUTHORIZER

USER

REASON

John

8

Don

Mark

New Employee

John

40

Don

Ryne

Raise

John

53

Don

Damon

Fired

· update store:
Tabellen zur Update-Historien Speicherung. Je Tabelle im data store, wird eine sogenannte shadow-Tabelle im update store gehalten.

Beispiel: Tabelle SEMP nach obigen Transaktionen T1- T4:

QUERY	TT	USER
Q1: John′s SALARY	42	Vance

· query store:
Eine Tabelle zu Speicherung der Abfragen: Query Store = Tabelle Qrel

Folgende Merkmale sind zum Zero-Information-Loss Modell zusammenfassend zu nennen:

· Zu jeder Transaktionsausführung werden die entsprechenden Bereiche automatisch vom DBMS aktualisiert.
· Das Transaktionslog ist sehr reich an Information die kaum auswertbar ist. Über das Zero-Information-Loss Modell wird diese Information nutzbargemacht!

4.1.3 Beispiel-Abfragen

· Wer hat die Abfrage nach `John′s Gehalt′ ausgeführt?

select USER
from Qrel
where QUERY=Q1

· Was waren die Gründe für Änderungen in der Tabelle emp, in der Zeit in der Tom Manager in irgendeiner Abteilung war?

select REASON
from Semp
where TT ? [[select * from management where MANAGER=TOM]]

4.1.4 Ausdrücke / Operatoren

· Ein Tupel in der Tabelle Qrel kann als Ergebnistabelle einer Query aufgefaßt werden. Zum Zweck die Ergebnistabelle einer (historischen) Query zu erhalten ist der Operator rel definiert. Sei q die Query, x der User und t die Transaktionszeit, so ist rel[q, x, t] die Ergebnisrelation auf die entsprechende Abfrage.

Der Operator wird vom DBMS zur Verfügung gestellt, womit historische Ergebnisse abgefragt werden können

· Für den/die Änderungszeitpunkt(e) eines Attributs/temporal assignments wird der temporale Ausdruck: ?_M(A) für Attribut A definiert.

Beispiel:

- Gib die User, die Änderungen an den Gehältern vorgenommen haben, in der Zeit von 10 bis 20.

- select USER
from Semp
where 10 <= TT and TT <= 20
and TT ? [[select * from emp while ?_M(A) ]]

Anmerkung:
- USER ist ein Attribut aus Semp
- Die Änderungszeit wird aus Semp und aus emp ermittelt.

Zu beachten ist die Tatsache, daß die Möglichkit zur Abfrage von Modifikation allein durch die Einführung vom Ausdruck ?_M(A) ermöglicht wurde!

4.2 Ein Modell für die Abfrage von Fehlerinformationen

In klassischen Datenbanken wird kein Unterschied beim Update gemacht, ob zur Modifikation oder zur Fehlerbehebung eine Änderung vorgenommen wird. Will man diese Information festhalten, so muß über das Objekt, welches durch ein Tupel beschrieben wird, in zwei Zeitdimensionen, valid time & transaction time, jeweils Werte gespeichert werden.
Diese Notwendigkeit führt zum bitemporalen Element.

4.2.1 Das bitemporale Element

Das bitemporale Elemente: ?(t,t′) ist die zweidimensionale Erweiterung zum normalen temporal element.

Als Beispiel sei für ein Attribut jeweils die tabulare und pictorale Darstellung angegeben:

[40,80]	x	[0,_)	a
[81,NOW]	x	[0,20]	a
	x	[21,30]	b

Es gilt die Annahme: Das Wissen zum gegenwärtigem Zeitpunkt (NOW) gilt als korrekt!

Somit gilt hier, daß in der Zeit 40-80 ein Fehler in der Wissensbasis der Datenbank vorlag: während 21-30 (valid time) hatte das Attribut in der Datenbank den Wert a, obwohl in der Realität der Wert b galt !

4.2.2 Identitätsproblematik

Bei einer fehlerhaften Information in einem Attribut/assignment, welches für ein Objekt eine Identitätsfunktion hat wie z.B. der Name, kann diese Identität bei einer Abfrage verloren gehen.

[10,20]	x	[0,_)	Inga
[21,NOW]	x	[0,_)	Maria

· Beispiel:
Unter der Annahme in der Relation emp(Name, Salary, Dept) existiere ein Satz für Maria der Art:

so wurde also zur Transaktionszeit 21 die falsche Angabe des Namens berichtigt.

Bei einer Anfrage der Art: select * from emp while [10,20]x[0,_)
würde das Ergebniss: " [10,20] x [0,_) Inga "
lauten.

Damit würde eine weitere Verarbeitung (evt. Subselect) nicht möglich sein, da von einer falschen Information ausgegangen würde und keine Möglichkeit mehr besteht festzustellen, daß es sich um Maria′s Satz handelt.

· Zur Lösung dieses Problems kann z.B. zu jedem bitemporalem assignment durch das DBMS zu eindeutiger Identifikator, genannt Anker, vergeben werden, der sich nicht von außen ändern läßt; z.B. der aktuelle (NOW) Wert des Attributs.

Hierdurch ist ein eindeutiger Identifikator hinzugekommen, der über den Operator ?? zum Atribut erreicht werden kann.
Die Aufgabe den Anker zu pflegen obliegt dem DMBS und ist somit für den Anwender kein zusätzliches Problem.

[-1,0]	x	[0,_)	Maria
[10,20]	x	[0,_)	Inga
[21,NOW]	x	[0,_)	Maria
[-1,0]	x	[0,_)	Maria
[10,20]	x	[0,_)	Inga

· Im obigen Beispiel kann man sich vorstellen, daß der Anker zum fiktiven Zeitpunkt `-1′ festgehalten wird:

Damit ergibt obigen DB-Anfrage als Ergebnisrelation:

Somit wurde durch die Anfrage nicht die Identiät zerstört, da diese immer im Anker vorliegt.

4.2.3 temporale Ausdrücke für verschiedene Fehlerarten

Um verschiedene Fehlerarten zu Identifizieren, werden temporale Ausdrücke für diese definiert: (für das bitemporale Element ?(t,t′) ):

Zum Beispiel für die Fälle: kein Fehler, fehlende Werte, falsche Werte, ...

· Kein Fehler: ? _N(?) = {(t,t′) : ?(t,t′) = ?(NOW,t′)}
· fehlende Werte: ?_M(?) = {(t,t′) : ?(t,t′) ? [[?]] and (NOW,t′) ?[[?]]

Beispiel-Abfrage:

· Selektiere die Manager in Toys, während John kein Gehalt bezog (bzgl. der damaligen DB-Information), aber in der Zeit er dennoch in der Abteilung Toys arbeitete.

· select MANAGER
while [[select * while ?_M(SALARY)
during [[DEPT = Toys]]
from emp where ??NAME = John ]]
from management
where ??DEPT = Toys

Man beachte hier durch einen schrittweisen Vergleich zwischen der natürlichsprachigen Anfrage und der Select-Umsetzung die vernünftige und intuitive Formulierung.

5. Zusammenfassung

Wir haben das Temporale Datenmodell mit dem zentralen Datentyp für `Zeit′, der Zeitabbildung in Attributen, Tupeln und Relationen im Basismodell kennengelernt.

Die Abfragesprache TempSQL mit ihren Gemeinsamkeiten und Erweiterungen zu SQL, sowie den Besonderheiten, bedingt aus der temporalen Erweiterung, wurden besprochen.

Weiterhin wurden Anwendungsbeispiele für das TDMG exemplarisch beschrieben, wie ein Modell für die Abfrage von DB-Transaktionen und ein Modell für die Abfrage von Fehlerinformationen. Diese Darstellungen zeigten Nutzen des Modells auf Grundlage einer Weiterentwicklung des Basismodells.

6. Literaturverzeichnis

[Tans94] Tansel, A., Clifford, J., Gadia, S., Jajodia, S., Segev, A., and Snodgrass, R.T. (eds). Temporal Databases: Theory, Design, and Implementation. Database Systems and Applications Series. Benjamin/Cummings, Redwood City, CA, 1994.

[Gadia88] Gadia, S.K., "A homogeneous relational model and query languages for temporal databases" ACM Transactions on Databases Systems 13, 4, pp. 418-448, December 1988.

Hinweis:

Die hier verwendeten Beispiele sind dem Kapitel 2 von [Tans94] entnommen. Dabei wurden zur Vereinfachung verschiedene Beispiele etwas gekürzt.

Seminar: Temporale Datenbanken Ausarbeitung Vortrag 3 3-7