Das temporale Datenmodell nach Gadia

Inhaltsverzeichnis

1. EINFÜHRUNG / MOTIVATION

2. DAS TEMPORALE DAT ENMODELL
2.1 DER DATENTYP ‘TEMPORAL ELEMENT’
2.2 ATTRIBUTWERTE ALS ‘TEMPORAL ASSIGNMENT’
2.3 TUPEL / RELATIONEN
2.4 SNAPSHOT EQUIVALENCE
2.5 RESTRUKTUIERUNG BEI SCHLÜSSELWECHSEL
2.6 INTEGRIERUNG VERSCHIEDENER ARTEN ZEITLICHER DATEN

3. DIE ABFRAGESPRACHE TEMPSQL
3.1 TUPEL-NAVIGATION ÜBER ‘TEMPORAL EXPRESSION’
3.2 DAS SELECT-STATEMENT UND DIE WHILE-KAUSEL
3.3 RESTRUKTURIERUNG IM SELECT-STATEMENT
3.4 AGGREGATION
3.5 USER UND DEREN ZEITBEREICHE
3.6 ÜBERBLICK: SELECT-STATEMENT
3.7 MULTIHOMOGENITÄT

4. ANWENDUNGSBEISPIELE FÜR DAS TDMG
4.1 EIN MODELL FÜR DIE ABFRAGE VON DB-TRANSAKTIONEN
4.1.1 TRANSAKTIONS-LOGFILE ALS INFORMATIONSBASIS
4.1.2 ZERO-INFORMATION-LOSS MODELL
4.1.3 BEISPIEL-ABFRAGEN
4.1.4 AUSDRÜCKE / OPERATOREN
4.2 EIN MODELL FÜR DIE ABFRAGE VON FEHLERINFORMATIONEN
4.2.1 DAS BITEMPORALE ELEMENT
4.2.2 IDENTITÄTSPROBLEMATIK
4.2.3 TEMPORALE AUSDRÜCKE FÜR VERSCHIEDENE FEHLERARTEN

5. ZUSAMMENFASSUNG

6. LITERATURVERZEICHNIS

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 be- schrieben, 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 Basismo- dells.

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 Anwendungsbei- spiele/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ß Operatio- nen, wie die Vereinigung, Durchschnittbildung und Komplementbildung ab- geschlossen sind. Damit sind die Abgeschlossenheitseigenschaften (bzgl. der Menge der temporalen Elemente) gegeben, womit eine Boolesche Al- gebra gegeben ist.

In den Zeitabschnitten, die durch die Teilintervalle eines temporal elements beschrieben 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 Attri- butwert 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:

Abbildung in dieser Leseprobe nicht enthalten

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 Zeit- punkt t die Relation, die man erhält, wenn alle Tupel auf den Zeitpunkt t eingeschränkt werden.

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

Beispiel:

Relation management zum Zeitpunkt/Moment/instant NOW (management|NOW)

Abbildung in dieser Leseprobe nicht enthalten

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 ’ defi- niert:

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üssel- wechsel. 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.

Abbildung in dieser Leseprobe nicht enthalten

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 TempSQL vorgeschlagen.

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ü>

temporal expression:

intuitiv ‘klarer’ Aufbau eines temporalen Ausdruck

- t Π[0,NOW] ist ein temporal expression
- [[Attribut]] ist ein temporal expression

mit dem Ergebnis des temporal domains des Assignments

Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

- [[A ? B]], Sei ? ein beliebiger (=,>,<,¹,³,£,...) Operator,

dann ist [[A ? B]] ein temporal expression

Ergebnis:

Zeitbereich in der die Attribute A und B in der ? -Beziehung stehen

Beispiel: [[SALARY ? 20]] = [11,49] ? [55,60]

Zusatz:

gilt die Beziehung A ? B,so folgt [[A ? B]] ? ?

- [[ e ]], e relationaler Ausdruck

Konstrukt ermöglicht mächtige Verschachtelungen in

TempSQL-Ausdrücken

Beispiel: [[Management]] = [11,60] ? [71,NOW]

Seminar: Temporale Datenbanken Ausarbeitung Vortrag 3 3-10

Wolfgang Schmidt

- Weiteres:

- Sind a und b temp.exp., so gilt dies auch für: Vereinigung, Schnittbildung, Differenzbildung und Negation

- Sind a und b temp.exp., so ist die Teilmengenbeziehung a ? b ein boolscher Ausdruck

- Sind a und b boolsche Ausdrücke, so gilt dies auch für: Kon- junktion, Disjunktion und Negation

3.2 Das SELECT-Statement und die WHILE-Kausel

Die allgemeine (vereinfachte) Form ist:

Abbildung in dieser Leseprobe nicht enthalten

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 ge- wä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?

Erläuterungen:

Abbildung in dieser Leseprobe nicht enthalten

- Zeige alle Daten der Mitarbeiter, während sie in der Abteilung TOYS ar- beiteten und JOHN Manager irgendeiner Abteilung war?

Abbildung in dieser Leseprobe nicht enthalten

- 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

Abbildung in dieser Leseprobe nicht enthalten

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 whe- re-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.

- select DEPT, sum(SALARY) SumSal from emp

group by (DEPT)

having [[max(SALARY) >= 15K]] ? [31,40] during [[ave(SALARY) < 20K]]

- Ergebnisrelation:

DEPT SumSal

Abbildung in dieser Leseprobe nicht enthalten

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 Transfor- mationen 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) Nut-

Seminar: Temporale Datenbanken zer kann ein beliebiger time domain festgelegt werden (Standard: [0, NOW].), womit sich Sichten zeitlicher Natur realisieren lassen.

3.6 Überblick: Select-statement

Allgemeiner Aufbau

Abbildung in dieser Leseprobe nicht enthalten

- 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 wer- den können. Der Bezug zum aktuellen Gehalt wird durch die Einschrän- kung auf NOW hergestellt. Der Schlüssel der Ergebnisrelation bildet sich aus der Menge der Schlüssel der Eingangsrelationen, hier emp und e.

- Ergebnisrelation:

Abbildung in dieser Leseprobe nicht enthalten

Eine Generalisierung der Homogenität wird erreicht durch die Verallgemei- nerung der Tupelhomogenität durch homogene Spaltenbereiche (Multiho- mogenitä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 folgen- de

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 betrach- tet.

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:

Abbildung in dieser Leseprobe nicht enthalten

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:

Abbildung in dieser Leseprobe nicht enthalten

- 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:

Abbildung in dieser Leseprobe nicht enthalten

- query store:

Eine Tabelle zu Speicherung der Abfragen: Query Store = Tabelle Qrel

Abbildung in dieser Leseprobe nicht enthalten

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 nutz- bargemacht!

4.1.3 Beispiel-Abfragen

Abbildung in dieser Leseprobe nicht enthalten

4.1.4 Ausdrücke / Operatoren

- Ein Tupel in der Tabelle Qrel kann als Ergebnistabelle einer Query aufge- faß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 re l[q, x, t] die Ergebnisrelation auf die ent- sprechende 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 Modifika- tion 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:

Abbildung in dieser Leseprobe nicht enthalten

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.

- Beispiel:

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

Abbildung in dieser Leseprobe nicht enthalten

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 han- delt.

- Zur Lösung dieses Problems kann z.B. zu jedem bitemporalem as- signment 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.

- Im obigen Beispiel kann man sich vorstellen, daß der Anker zum fiktiven

Abbildung in dieser Leseprobe nicht enthalten

Damit ergibt obigen DB-Anfrage als Ergebnisrelation:

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

Man beachte hier durch einen schrittweisen Vergleich zwischen der natür- lichsprachigen 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 be- schrieben, 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 Basismo- dells.

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. Benja- min/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] entnom- men. Dabei wurden zur Vereinfachung verschiedene Beispiele etwas ge- kürzt.