Das temporale Datenmodell nach Gadia

  Wolfgang Schmidt  

  Inhaltsverzeichnis  

1.  EINFÜHRUNG MOTIVATION  3

2.  DAS TEMPORALE DAT ENMODELL  3

2.1  DER DATENTYP TEMPORAL ELEMENT  3

2.2  ATTRIBUTWERTE ALS TEMPORAL ASSIGNMENT  5

2.3  TUPEL RELATIONEN  5

2.4  SNAPSHOT EQUIVALENCE  7

2.5  RESTRUKTUIERUNG BEI SCHLÜSSELWECHSEL  9

2.6  INTEGRIERUNG VERSCHIEDENER ARTEN ZEITLICHER DATEN  9

3.  DIE ABFRAGESPRACHE TEMPSQL  10

3.1  - ÜBER TEMPORAL EXPRESSION  10

3.2  DAS - UND DIE -  11

3.3  RESTRUKTURIERUNG IM -  12

3.4  AGGREGATION  13

3.5  USER UND DEREN ZEITBEREICHE  13

3.6  ÜBERBLICK: -  15

3.7  MULTIHOMOGENITÄT  15

4.  ANWENDUNGSBEISPIELE FÜR DAS TDMG  16

4.1  EIN MODELL FÜR DIE ABFRAGE VON -  16

4.1.1  - ALS INFORMATIONSBASIS  16

4.1.2  - LOSS MODELL  18

4.1.3  -  19

4.1.4  AUSDRÜCKE OPERATOREN  19

4.2  EIN MODELL FÜR DIE ABFRAGE VON FEHLERINFORMATIONEN  20

4.2.1  DAS BITEMPORALE ELEMENT  20

4.2.2  IDENTITÄTSPROBLEMATIK  20

4.2.3  TEMPORALE AUSDRÜCKE FÜR VERSCHIEDENE FEHLERARTEN  22

5.  ZUSAMMENFASSUNG  23

6.  LITERATURVERZEICHNIS  24

  Seminar: Temporale Datenbanken Ausarbeitung Vortrag 3 -  

Wolfgang Schmidt

1. Einführung / Motivation

Das Temporale Datenmodell nach Gadia (TDMG) ist ein auf dem Relatio- nenmodell basierender Ansatz zur Modellierung temporaler Daten. Dazu wird von S.K.Gadia und S.S.Nair eine Erweiterung zu SQL, TempSQL, be- schrieben, 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 & Realisie- rung zu nennen, sowie die Tatsache hervorzuheben, daß die temporalen Re- lationen nicht mehr in der 1. Normalform sind.

2.1 Der Datentyp ‘temporal element’

Der zentrale Datentyp im TDMG ist das ‘temporal element’, welcher als end- liche 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 Werte- bereichs annehmen (siehe Abschnitt 2.2).

Bemerkenswert ist die Erweiterungsfähigkeit des Basis-Datentyp ‘temporal element’ wie z.B. bitemporales Element. Die leichte Anpassbarkeit des

Wolfgang Schmidt

TDMG auf verschiedene Anwendungsfälle resultiert u.a. aus dieser Erweite-

rungsfähigkeit.

Wolfgang Schmidt

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 tem- poral 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 zeit- invariant 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:

Wolfgang Schmidt

Wolfgang Schmidt

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

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

Beispiel:

Relation management zum Zeitpunkt/Moment/instant NOW (manage- ment| NOW)

Tabelle: management

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

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

Wolfgang Schmidt

Damit wird ein Vergleich von temporalen Tabellen möglich.

Wolfgang Schmidt

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.

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

Wolfgang Schmidt

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ücke: ‘temporal’, ‘boolean’ und ‘relational expressions’

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:

[[SALARY]] = [11,60]

•

[[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]

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: select X : K

while t from r 1 , r 2 , ..., 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 ge- währleisten Bei Verwendung des ‘:K’ Operators zum Schlüsselwechsel ist eine evt. Re- strukturierung notwendig.

Die WHILE-Klausel schränkt also den Zeitbereich ein, in dem ein Tupel lie- gen 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 do- main eingeschränkt.

• Wann hatte John einen Manager?

• [[

select MANAGER while [[emp.DEPT=management.DEPT]]

Wolfgang Schmidt

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 ar- beiteten 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 be- schrieben.

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]

Tabelle:

mangement: MANAGER

Wolfgang Schmidt

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:

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-

Wolfgang Schmidt

zer kann ein beliebiger time domain festgelegt werden (Standard: [0,

NOW].), womit sich Sichten zeitlicher Natur realisieren lassen.

Wolfgang Schmidt

3.6 Überblick: Select-statement

Allgemeiner Aufbau

select select-Liste while while-Ausdruck from from-Liste where where-Bedingung group by 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 an- zusprechen 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:

Wolfgang Schmidt

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 Ent- wicklung einer DB nachzuvollziehen und ehemalige Ergebnisse von Abfra- gen zu rekonstruieren.

4.1.1 Transaktions-Logfile als Informationsbasis

Im Transaktions-Logfile (siehe Beispiel ) eines DBMS ist die gesamte In- formation gegeben, um oben formuliertes Ziel zu erreichen. Hierzu muß die- se 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)

Wolfgang Schmidt

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)

Wolfgang Schmidt

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 Da- tenbereiche definiert:

• data store:

Der Datenbereich: klassischer temporaler Tabellen (hier: Tabellen mit Transaktionszeit)

Beispiel: Tabelle EMP nach obigen Transaktionen T1- T4:

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

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

Folgende Merkmale sind zum Zero-Information-Loss Modell zusammenfas- send 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!

Wolfgang Schmidt

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 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 rel[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!

Wolfgang Schmidt

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

Somit gilt hier, daß in der Zeit 40-80 ein Fehler in der Wissensbasis der Da- tenbank vorlag: während 21-30 (valid time) hatte das Attribut in der Daten- bank 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:

so wurde also zur Transaktionszeit 21 die falsche Angabe des Namens

Wolfgang Schmidt

berichtigt.

Wolfgang Schmidt

Bei einer Anfrage der Art:

[10,20]x[0,∞) würde das Ergebniss:

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 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’) ?[[?]]

Wolfgang Schmidt

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 Abtei- lung 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ür- lichsprachigen Anfrage und der Select-Umsetzung die vernünftige und intuiti- ve 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 Erweite- rungen zu SQL, sowie den Besonderheiten, bedingt aus der temporalen Er- weiterung, 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.

Wolfgang Schmidt

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