Transcript

Semantik und Realisierung einererweiterten Relationenalgebra fur

temporale Datenbanken

Diplomarbeitim Studiengang Mathematik mit Studienrichtung Informatik

vorgelegt von

Christian StahlhutMatrikelnummer: 1937473

Universitat Hannover

Institut fur Informationssysteme

Fachgebiet Datenbanksysteme

Prufer: Prof. U. Lipeck

Zweitprufer: Prof. R. Parchmann

Hannover, den 27. Juli 2004

Zusammenfassung

In dieser Arbeit wird ein Konzept zur relationalen Modellierung von zeitabhangigen(”temporalen“) Daten beschrieben. Zunachst wird der zugrundeliegende Zeitbegriff na-

her erlautert. Dann kann die klassische Relationenalgebra um einen Zeitbezug erweitertwerden. Anhand dieser Erweiterung wird diskutiert wie temporale Datenbanken zu mo-dellieren sind und welche zusatzlichen Integritatsbedingungen es zu beachten gilt.

Durch Anfragebeispiele fur konkrete temporale Datenbanken wird versucht eine ge-wisse Pragmatik bezuglich der erweiterten Relationenalgebra aufzubauen.

Ein weiterer Schritt zur Realisierung der erweiterten Relationenalgebra ist die Opti-mierung der erweiterten Operatoren.

Abschließend wird eine beispielhafte Implementierung der Algebra als Anfragespracheauf Grundlage des relationalen Datenbankmanagementsystems Oracle vorgestellt.

Inhaltsverzeichnis

1. Einleitung 5

2. Semantik temporaler Daten 72.1. Zeitstempel, Chronons und Granularitat . . . . . . . . . . . . . . . . . . 72.2. Modellierung des Zeitstempels . . . . . . . . . . . . . . . . . . . . . . . . 72.3. Gultigkeitszeit, Transaktionszeit und benutzerdefinierte Zeit . . . . . . . 8

3. Definition der erweiterten Relationenalgebra 103.1. Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2. Intervalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3. pack und unpack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4. Erweiterung der Relationenalgebra . . . . . . . . . . . . . . . . . . . . . 22

4. Modellierung temporaler Datenbanken 244.1. Integritatsbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2. Tupel- oder Attributzeitstempel . . . . . . . . . . . . . . . . . . . . . . . 294.3. Zukunft, Gegenwart und Vergangenheit . . . . . . . . . . . . . . . . . . . 32

5. Pragmatik – Anfragebeispiele 355.1. Beispiele aus [Bei2001a]– ein Vergleich mit TSQL2 . . . . . . . . . . . . . 355.2. Beispiele aus [DDL2003a] . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3. Beispiele zu Gruppierung und Aggregation . . . . . . . . . . . . . . . . . 40

6. Optimierung 446.1. Zerlegung in Teilintervalle – split . . . . . . . . . . . . . . . . . . . . . 446.2. Vermeidung von unpack und pack . . . . . . . . . . . . . . . . . . . . . . 466.3. Verbesserungen fur pack . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4. Verbesserungen fur unpack . . . . . . . . . . . . . . . . . . . . . . . . . . 576.5. Verbesserungen fur split . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7. Realisierung 617.1. Erweiterung des DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.2. Ubersetzung von Termen . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.3. Implementierung des Evaluators . . . . . . . . . . . . . . . . . . . . . . . 72

3

Inhaltsverzeichnis

8. Ausblick 75

A. Intervalle und Intervalloperatoren 77

B. Grammatik der Anfragesprache 78B.1. Terminalsymbole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.2. Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4

1. Einleitung

Motivation und Zielsetzung

Veranderungen unter dem Einfluß der Zeit sind ein alltagliches Phanomen. ZeitlicheVeranderung zu beschreiben erfordert gewisse Begriffe. Sollen solche Beschreibungen ineinem Datenbankmanagementsystem (DBMS) realisiert werden, sind also zunachst ent-sprechende Begriffe zu schaffen. Moderne kommerzielle DBMS unterstutzen jedoch denUmgang mit zeitabhangigen (temporalen) Daten bisher kaum. Allerdings ist heute dieSpeicherung großer (historischer) Datenmengen okonomisch vertretbar, da Speicherko-sten fast kein Problem mehr darstellen. Außerdem sind Modellierung und Verarbeitungtemporaler Daten Aufgaben, die immer mehr an Bedeutung gewinnen – zum Beispiel inData Warehouses. DBMSe um zeitliche Funktionalitat zu erweitern ist also naheliegend.

Ziel dieser Arbeit soll es demnach sein, durch eine erweiterte Relationenalgebra zu-nachst die Begriffe zu schaffen, die in einem relationalen DBMS (RDBMS) fur den Um-gang mit temporalen Daten benotigt werden. Ausgehend von dieser Algebra ist exem-plarisch eine temporale Erweiterung fur das RDBMS Oracle zu realisieren.

Quellen und verwandte Arbeiten

Arbeiten zu diesem Thema entstanden schon vor einiger Zeit (etwa [TCG93a]): EineErweiterung der deskriptiven Anfragesprache SQL (Structured Query Language) umtemporale Elemente wurde unter dem Namen TSQL2 ([Sno95a]) dem ISO-Komitee zurStandardisierung vorgelegt. Verschiedene Probleme mit dem TSQL2-Ansatz fuhrten je-doch dazu, dass bis heute (2004) keine solche SQL-Erweiterung verabschiedet1 ist.

Einige der Kritiker von TSQL2 veroffentlichten vor kurzem das Buch”Temporal Da-

ta and the Relational Model“ ([DDL2003a]), in dem ein alternativer Umgang mit derProblematik vorgeschlagen wird. Die hier vorgestellte erweiterte Relationenalgebra istan den in dieser Quelle beschriebenen Konzepten orientiert.

Zusatzlich werden bereits am Institut entstandenen Arbeiten (sowie deren Quellen) be-achtet: In [Rei99a] und [Bei2001a] wird versucht, eine temporale Erweiterung fur SQL92im Sinne von TSQL2 zu schaffen. Eine graphische Anfragesprache fur temporale Daten-banken wird in [Kuh97a] beschrieben.

1Leicht am fehlenden ”Part 7“ (”SQL/Temporal“) in der SQL-Spezifikation zu erkennen – etwa durcheine Suche bei http://iso.org nach ’SQL’.

5

1. Einleitung

Gliederung dieser Arbeit

Der Literatur folgend werden Daten mit einem zeitlichen Bezug versehen, indem ihnenein Gultigkeitszeitraum zugeordnet wird. Die Modellierung dieser Zeitstempel geschiehtmit diskreten Intervallen, welche als Zeitspannen zu verstehen sind. In Kapitel 2 wird sodie grundlegende Semantik einer temporalen Datenbank festgelegt.

Danach sind zunachst die Grundlagen fur den Umgang mit solchen Intervallen imrelationalen Datenmodell zu schaffen. Davon ausgehend wird die klassische Relationen-algebra um Intervallfunktionalitat erweitert (Kapitel 3).

In Kapitel 4 wird dargelegt, wie Integritatsanforderungen einer temporalen Datenbankdurch die erweiterte Relationenalgebra zu formulieren sind. Außerdem ist zu klaren wiedie Relationen einer temporalen Datenbank modelliert werden konnen.

Um die Ausdrucksfahigkeit der Algebra zu testen und die beschriebenen Begriffe zukonkretisieren, werden in Kapitel 5 Anfragebeispiele diskutiert. In Kapitel 6 wird ver-sucht die erweiterten Operatoren in Hinblick auf Speicherbedarf und Geschwindigkeit zuverbessern und so eine Implementierung zu ermoglichen.

Eine Beispielimplementierung soll zeigen, ob und wie die erweiterten Relationenal-gebra als Anfragesprache auf Basis eines bestehenden RDBMS realisiert werden kann(Kapitel 7). Schließlich wird in Kapitel 8 ein Ausblick auf weitere Moglichkeiten gege-ben, die durch das hier beschriebene Konzept erschlossen werden.

6

Eins-zwei-drei! Im Sauseschritt lauft die Zeit, wir laufen mit.

(Wilhelm Busch)

2. Semantik temporaler Daten

Die Bedeutung von Daten in einem zeitlichen Kontext hangt vom verwendeten Zeitbe-griff ab. Deshalb werden im folgenden zunachst die Begriffe

”Zeitpunkt“ und

”Zeitraum“

erlautert, damit eine Semantik fur zeitveranderliche Daten angegeben werden kann. Ab-schließend wird Bezug auf in der Literatur haufig verwendete Zeitbegriffe genommen.

2.1. Zeitstempel, Chronons und Granularitat

In einer Datenbank wird jedem Tupel einer Relation stets eine gewisse Aussage zugeord-net. Diese Aussage soll fur eine temporalen Datenbank in einen zeitlichen Zusammenhanggestellt werden, indem ihr ein gewisser Gultigkeitszeitraum zugesprochen – sozusagen ein

”Zeitstempel aufgepragt“ – wird. Die allgemeine Struktur dieses Zeitstempels muss also

eine (potentiell unendliche) Menge1 von Zeitpunkten sein. Einem Zeitpunkt (Chronon),als kleinster in der Datenbank darstellbaren Zeiteinheit, kann wiederum ein (kontinuierli-ches) Zeitintervall oder eine (endliche) Menge von (atomaren) Zeiteinheiten entsprechen.Die Lange eines Zeitpunkts2 wird als Granularitat bezeichnet.

Bemerkungen:

• Ein Zeitstempel besteht nicht notwendigerweise aus einem Intervall von Zeitpunk-ten (z.B. bei periodisch wiederkehrenden Ereignissen).

• Es konnen verschiedene (gleichberechtigte) Arten von Zeitpunkten mit unterschied-lichen Granularitaten existieren (etwa verschieden lange Vorlesungszeiten im Winter-und Sommersemester).

• Ein Zeitstempel kann Vergangenheit oder Zukunft (auch beides) enthalten. Dafurmuss jedoch ein Zeitpunkt als

”gegenwartig“ festgelegt sein.

2.2. Modellierung des Zeitstempels

2.2.1. Naturliche Zahlen als Zeitpunkte

Da die Granularitat frei bestimmbar (interpretierbar) ist, sollte es ausreichen ein diskre-tes3 Zeitmodell zu verfolgen. Damit genugt als Grundmenge von Zeitpunkten die Menge

1diskret oder kontinuierlich – je nach Philosophie2also die Lange des Zeitintervalls eines Chronons im kontinuierlichen Fall oder die Anzahl von atomaren

Zeiteinheiten eines Chronons im diskreten Fall

7

2. Semantik temporaler Daten

der naturlichen Zahlen.

Beispiel: Ist (genau) eine Stunde als Granularitat gewahlt, dann entspricht der Zeitpunkt’4’ der vierten Stunde – also der Zeit von 4:00 Uhr bis

”kurz vor“ 5 Uhr.

2.2.2. Intervalle als Zeitstempel

Da in der Praxis haufig Tupel betrachtet werden, deren Attributwerte in einer gewissenZeitspanne konstant bleiben, erscheint es sinnvoll ein (geschlossenes) Intervall als Daten-struktur fur Zeitstempel zu nutzen: Ist die Aussage eines Tupels zu einem bestimmtenZeitpunkt gleich der Aussage eines anderen Tupels zum Zeitpunkt danach (oder davor),so konnen diese Tupel mit dem entsprechenden intervallwertigen Zeitstempel zusam-mengefasst werden. Prozesse, die Aussagen an nicht aufeinanderfolgenden Zeitpunktenidentifizieren (etwa periodische Prozesse) werden allerdings mit dieser Wahl nicht soeffizient modelliert.

Beispiel: Mit [4, 9] ware also der Zeitraum von 4:00 Uhr bis”kurz vor“ 10 Uhr gemeint,

wenn ein Zeitpunkt einer Stunde entspricht. [4, 4] kann dann mit dem Zeitpunkt ’4’identifiziert werden.

Bemerkung: Mit den zwei Zeitpunkten b und e mit b ≤ e entspricht das geschlosseneIntervall [b, e] dem rechts offenen Intervall [b, e + 1) und umgekehrt. Aus programmier-technischen Grunden wird hier die geschlossene Darstellung bevorzugt – auch wenn beideDarstellung austauschbar sind. Außerdem besteht mit rechts offenen Intervallen eher dieGefahr undefinierte Intervalle zu erzeugen – etwa durch [b, b).

2.2.3. Temporale Elemente

Mit der im TSQL-Ansatz als Zeitstempel verwendeten Menge von Zeitintervallen (”tem-

porales Element“) ist keine großere Ausdrucksfahigkeit zu erwarten. Ein solches tempora-les Element kann stets durch mehrere Tupel mit (verschiedenen) Intervall-Zeitstempelnohne Verlust nachgebildet werden (vgl. die Beispiele in 5.1). Daher wird hier auf dieseskomplizierende Konzept verzichtet.

2.3. Gultigkeitszeit, Transaktionszeit undbenutzerdefinierte Zeit

In der Literatur zu temporalen Datenbanken sind haufig die Begriffe Gultigkeitszeit(valid time), Transaktionszeit (transaction time) und benutzerdefinierte Zeit (user-defined time) zu lesen.

”Gultigkeitszeit“ bezieht sich auf Aussagen mit Gultigkeitszeitraum.

3Eine Menge ist diskret, wenn sie umkehrbar-eindeutig auf die naturlichen Zahlen abbildbar ist.

8

2. Semantik temporaler Daten

Mit”Transaktionszeit“ ist die Protokollierung von Datenbanktransaktionen auf Tu-

pelebene gemeint –”Tupel X stand im Zeitraum Z in Relation R“. Zeitstempel fur

Transaktionszeit sind vom Datenbanknutzer unabhangig und werden allein vom DBMSverwaltet. Im Sinne eines Logs, also der Protokollierung von Transaktionen, sind Aussa-gen uber die Vergangenheit hier nicht veranderbar4.

Transaktionszeit laßt sich naturlich uber (eine zusatzliche) Gultigkeitszeit nachbilden.Ein DBMS, das Gultigkeitszeit und Transaktionszeit enthalt wird bitemporal genannt.Als

”benutzerdefinierte Zeit“ werden Zeitangaben ohne Zeitstempelbezug bezeichnet.

Der oben erlauterte Zeitstempel entspricht also eher der Gultigkeitszeit. Im hier vor-gestellten Konzept mussen die genannten Zeitbegriffe jedoch nicht weiter unterschiedenwerden.

4Ansatze fur einen Umgang mit Transaktionszeit im Hinblick auf Datenrettung sind unter dem Stich-wort ”Flashback Query“ in der Version 10g des Oracle-DBMS zu finden (siehe [OraAD] Kapitel15)

9

3. Definition der erweitertenRelationenalgebra

Um eine erweiterte Relationenalgebra definieren zu konnen, wird in 3.1 zunachst erlau-tert, wie die zugrundeliegende Relationenalgebra definiert ist.

Nach 2.2.2 wird ein Zeitstempel als Intervall modelliert. In 3.2 wird daher ein entspre-chender Intervallbegriff eingefuhrt. Zusatzlich werden Operatoren fur den Umgang mitIntervallen definiert. Bezuglich temporaler Daten werden also die fur den Umgang mitZeitraumen benutzbaren Begriffe bereitgestellt.

Die dann in 3.3 neu eingefuhrten Operatoren dienen dazu, eine”atomare“,

”zeitpunkt-

artige“ Sicht auf die Information in einer Relation zu erhalten (unpack), bzw. dieseInformation moglichst

”zusammengefasst“ und

”redundanzfrei“ betrachten zu konnen

(pack). Damit laßt sich die zugrundeliegende Relationenalgebra um Funktionalitat furZeitstempel (bzw. Intervalle) erweitern (3.4).

3.1. Relationen

Die hier aufgefuhrten Definitionen sollen weitgehend der”gewohnten“ klassischen Re-

lationenalgebra entsprechen. Der einzige wichtige Unterschied besteht in der Definitionvon Gruppierung und Aggregation: Das Ergebnis einer Aggregationsfunktion ist nichtauf einen einzigen Wert beschrankt, sondern kann eine Menge von Werten zuruckliefern.Dies wird das grundlegende Konzept fur die Formulierung der erweiterten Relationenal-gebra in 3.3.

3.1.1. Definition

Eine Relation ist ein 2-Tupel R = (S, I):

• S heißt Schema von R und ist eine Funktion der Form

S : {a1, . . . , an} −→ D mit n ∈ N0

wobei der Definitionsbereich def(S) = {a1, . . . , an} eine Menge von (paarweise ver-schiedenen) Zeichenketten (den Attributnamen) und D eine Menge von Mengen(den Wertebereichen oder Datentypen) ist. S ordnet also jedem Attributna-men einen Wertebereich zu.

10

3.1. Relationen

• Sei

T (S) := {t : def(S) −→⋃

a∈def(S)

S(a) mit t(a) ∈ S(a) fur alle a ∈ def(S)}

eine Menge von Abbildungen, die allen Attributnamen eines Schemas einen Wertaus dem zugehorigen Wertebereich zuordnet. Eine endliche Teilmenge I von T (S)heißt Inhalt von R.

Bemerkungen:

• Das Bild im(S) von S ist die Menge aller den Attributnamen zugeordneten Wer-tebereichen; im(S) ⊆ D.

• Ein 2-Tupel (a, S(a)) ∈ def(S)× im(S) heißt Attribut (von R).

• Ein t ∈ T (S) heißt Tupel und ein t ∈ I ⊂ T (S) entsprechend Tupel von R.

• T (S) ist die Menge aller moglichen Tupel zu einem Schema S.

• Haufig wird R statt I geschrieben1, z.B. t ∈ R statt t ∈ I. Oder: Ist P eine Relationmit gleichem Schema wie R, dann ist mit P ⊂ R gemeint, dass der Inhalt von PTeilmenge des Inhalts von R ist.

• Der Inhalt von R enthalt das gleiche Tupel nicht mehr als einmal (keine Duplikate).Es ist keine bestimmte Reihenfolge der Attribute oder der Tupel festgelegt.

• Ist eine Reihenfolge a1, . . . , an der Attribute vorgegeben, so wird ein t ∈ T (S) auchkurz als (t(a1), . . . , t(an)) geschrieben.

• Eine Relation wird haufig in Form einer Tabelle dargestellt, z.B:

Name AlterMuller 33

Schmidt 35Schulze 32

Die Namen der Attribute ergeben sich aus dem Tabellenkopf. Die Wertebereichewerden meist nicht explizit angegeben. Dieser Tabelle entspricht ein Schema mitden Attributen (Name, string) und (Alter, integer). Der Inhalt der Relation istdie Menge der Tupel (Muller, 33), (Schmidt, 35) und (Schulze, 32).

3.1.2. Operatoren auf Relationen – Relationenalgebra

Die folgenden Operatoren bilden eine Algebra auf der Menge der Relationen.Seien X = (SX , IX) und Y = (SY , IY ) zwei Relationen.

1Ob eine Relation oder deren Inhalt gemeint ist, sollte aus dem Kontext erkennbar sein.

11

3.1. Relationen

Projektion

Sei A eine Teilmenge der Attributnamen von X: A ⊆ def(SX). Dann wird X durch dieProjektion folgendermaßen auf A eingeschrankt:

πA(X) := (S ′, I ′) mit

S ′ = SX |A = S ′ : A −→ im(SX) mit S ′(a) = SX(a) fur alle a ∈ A

I ′ = {t|A : t ∈ X}

Erweiterung

Sei M eine Menge, β eine Abbildung der Form β : IX → M und b 6∈ def(SX) eineZeichenkette. Dann ist die Erweiterung von X um b = β definiert als:

εb=β(X) := (S ′, I ′) mit

S ′ : def(SX) ∪ {b} −→ im(SX) ∪ {M} mit S ′|def(SX) = SX und S ′(b) = M

I ′ = {t′ ∈ T (S ′) : ∃t ∈ X mit t′|def(SX) = t und t′(b) = β(t)}

Umbenennung

Sei a ∈ def(SX) ein Attributname von X und b 6∈ def(SX) eine Zeichenkette. Außerdemsei β : IX → S(a) mit β(t) = t(a). Dann kann das Attribut a von X wie folgt in bumbenannt werden:

ρb=a := πdef(SX)−{a}(εb=β(X))

Fur mehrere Umbenennungen der Form ρb1=a1(ρb2=a2(. . . (X))) sei auch die Schreibweiseρb1=a1,b2=a2,...(X) erlaubt.

Selektion

Es sei ϕ eine Selektionsfunktion: ϕ : IX → {wahr, falsch}. Mit σϕ(X) werden alle Tupelaus X ausgewahlt, die der Selektionsfunktion genugen:

σϕ(X) : = (SX , I ′) mit

I ′ = {t ∈ X : ϕ(t) = wahr}

Verbund (Join)

Durch den Verbund von X und Y werden alle Tupel verknupft, die gleiche Werte furgleichnamige Attribute haben:

X on Y := (S ′, I ′) mit

S ′ : def(SX) ∪ def(SY ) −→ im(SX) ∪ im(SX) mit S ′|def(SX) = SX und S ′|def(SY ) = SY

I ′ = {t ∈ T (S ′) : ∃x ∈ X ∧ ∃y ∈ Y mit t|def(SX) = x ∧ t|def(SY ) = y}

12

3.1. Relationen

Bemerkung: Haben X und Y keine gleichnamigen Attribute, so entspricht der Ver-bund dem Kartesischen Produkt von X und Y . Umgekehrt entspricht der Verbund demDurchschnitt von X und Y falls X und Y nur gleichnamige Attribute haben.

Vereinigung

Falls X und Y das gleiche Schema (SX = SY ) haben, ist die Vereinigung wie folgtdefiniert:

X ∪ Y : = (S ′, I ′) mit

S ′ = SX = SY

I ′ = {t : t ∈ X ∨ t ∈ Y }

Differenz

Haben X und Y das gleiche Schema (SX = SY ), so ist die Differenz von X und Ydefiniert als:

X − Y : = (S ′, I ′) mit

S ′ = SX = SY

I ′ = {t : t ∈ X ∧ t 6∈ Y }

Durchschnitt

Mit (SX = SY ) gilt:X ∩ Y := X − (X − Y ) = X on Y

Gruppierung und Aggregation

Sei A eine Teilmenge der Attributnamen von X: A ⊆ def(SX).Fur alle 1 ≤ i ≤ n ∈ N seien außerdem bi 6∈ def(SX) paarweise verschiedene Zeichenket-ten, Mi Mengen und αi (Aggregations-)Funktionen der Form

αi : P(IX) −→ P(Mi)

Dann gilt:ΓA # b1=α1,...,bn=αn(X) := (S ′, I ′) mit

S ′ : {b1, . . . , bn} −→ {Mi, . . . ,Mn} mit S ′(bi) = Mi ∀i ∈ {1, . . . , n}

I ′ = {t′ ∈ T (S ′) : ∃t ∈ πA(X) ∧ ∀i ∈ {1, . . . , n} : t′(bi) ∈ αi({x ∈ X : x|A = t}) }

13

3.1. Relationen

Bemerkungen:

• Ist A = ∅ die leere Menge, dann wird nicht gruppiert und das Ergebnis einerAggregationsfunktion wird fur ganz X bestimmt.

• Diese Definition der Gruppierung unterscheidet sich in (nur) einem Punkt vonder Herkommlichen: Eine Aggregationsfunktion liefert anstelle von Werten (auseiner Menge M) eine Menge von Werten (aus P(M)) zuruck. Der Nutzen dieserErweiterung ergibt sich im Umgang mit intervallwertigen Attributen (siehe 3.3.1).

Vereinfachungen: Mit einer Menge G ⊆ IX und einem Attributnamen a ∈ def(SX)seien folgende abkurzende Schreibweisen moglich:

• count fur α(G) := {|G|}

• min(a) fur α(G) := {mint∈G t(a)}

• sum(a) fur α(G) := {∑

t∈G t(a)}

• weitere Aggregationsfunktionen (max, avg, . . . ) analog zu min und sum

Beispiel: Sei folgende Relation X gegeben:

X :=

Produkt Preis ZeitRennrad 300 [1, 7]Rennrad 250 [8, 14]

Mountainbike 270 [1, 20]

Dann liefert eine Gruppierung uber ’Produkt’ der Form

ΓProdukt # Produkt, Summe = sum(Preis)(X)

eine Relation mit dem Schema

S ′ : {Produkt, Summe} −→ {SX(Produkt), SX(Preis)}

mit S ′(Produkt) = SX(Produkt) und S ′(Summe) = SX(Preis)

Schreibt man die Vereinfachungen aus, ergibt sich fur den Inhalt:

I ′ = {t′ ∈ T (S ′) : ∃t ∈ πProdukt(X) ∧t′(Produkt) ∈ {x(Produkt) : x ∈ X ∧ x|Produkt = t} ∧

t′(Summe) ∈ {∑

{x∈X:x|Produkt=t}

x(Preis) } }

14

3.2. Intervalle

Fur jede der beiden durch πProdukt gegebenen Partitionen von X lassen sich die (hiereinelementigen) Ergebnismengen der Aggregationsfunktionen berechnen:

I ′ = {t′ ∈ T (S ′) : ∃t ∈ {(Rennrad), (Mountainbike)} = πProdukt(X) mit

t′(Produkt) ∈ {Rennrad} ∧ t′(Summe) ∈ {300 + 250} fur Rennrader und

t′(Produkt) ∈ {Mountainbike} ∧ t′(Summe) ∈ {270} fur Mountainbikes }

Dies entspricht der ErgebnisrelationProdukt SummeRennrad 550

Mountainbike 270

3.2. Intervalle

In diesem Abschnitt werden die Intervalle zur Modellierung des in Kapitel 2 beschrie-benen Zeitstempels definiert. Zusatzlich werden Operatoren zum Umgang mit diesenIntervallen eingefuhrt.

Es sei sets N = {0, 1, 2, 3, . . .} die Menge der naturlichen Zahlen.

3.2.1. Definition

Fur b, e ∈ N mit b ≤ e sei das Intervall von b bis e definiert als

[b, e] := {n ∈ N : b ≤ n ≤ e}Sei I die Menge aller so definierten Intervalle.

3.2.2. N-wertige Operatoren

Fur ein Intervall I = [b, e] ∈ I gelte:

• begin(I) := b

• end(I) := e

• count(I) := end(I)− begin(I) + 1

3.2.3. Vergleichsoperatoren

Vergleichsoperatoren liefern Information uber die Beziehung zweier Intervalle:

I × I −→ {wahr, falsch}Seien also I1 := [b1, e1] ∈ I und I2 := [b2, e2] ∈ I zwei Intervalle.

”Allens Operatoren“

Die folgenden Operatoren sind als”Allens Operatoren“ [All83a]2 bekannt:

2is_included_in wird dort during genannt, begins als starts bezeichnet und ends entsprechendals finishes

15

3.2. Intervalle

• I1 equals(=) I2 :⇔ b1 = b2 ∧ e1 = e2

• I1 is_included_in(⊆) I2 :⇔ b1 ≥ b2 ∧ e1 ≤ e2 b1 e1

b2 e2

• I1 before I2 :⇔ e1 < b2 b1 e1 b2 e2

• I1 meets I2 :⇔ b1 = e2 + 1 ∨ b2 = e1 + 1 b2b1 e21 e

• I1 overlaps I2 :⇔ b1 ≤ e2 ∧ b2 ≤ e1 b1 e1

b2 e2

• I1 begins I2 :⇔ b1 = b2 ∧ e1 ≤ e2 b1 1 e

b2 e2

• I1 ends I2 :⇔ e1 = e2 ∧ b1 ≥ b2 b1 1 e

b2 e2

Abgeleitete Vergleichsoperatoren

Weitere Vergleichsoperatoren sind:

• I1 after I2 :⇔ I2 before I1

• I1 includes(⊇) I2 :⇔ I2 is_included_in I1

• I1 ⊂ I2 :⇔ I1 ⊆ I2 ∧ I1 6= I2

• I1 ⊃ I2 :⇔ I1 ⊇ I2 ∧ I1 6= I2

• I1 merges I2 :⇔ I1 meets I2 ∨ I1 overlaps I2

Zusatzlich laßt sich der Spezialfall n ∈ I1 fur ein n ∈ N definieren:

n ∈ I1 :⇔ [n, n] is_included_in I1 ⇔ b1 ≤ n ≤ e1

3.2.4. Intervallwertige Operatoren

Um zwei Intervalle miteinander zu einem neuen Intervall zu kombinieren, werden Ope-ratoren der Form I × I → I benotigt. Mit I1 := [b1, e1] ∈ I und I2 := [b2, e2] ∈ Isei:

•I1 union I2 := [min (b1, b2), max (e1, e2)] falls I1 merges I2

e1b1

b2 2 e b1 e2

16

3.2. Intervalle

I1 minus I2 :=

{[b1, min (b2 − 1, e1)] falls b1 < b2 ∧ e1 ≤ e2

[max (e2 + 1, b1), e1] falls b1 ≥ b2 ∧ e1 > e2

e1b1

b2 2 e b1 b2

I1 intersect I2 := I1 minus (I1 minus I2) falls I1 overlaps I2

= [max (b1, b2), min (e1, e2)]

e1b1

b2 2 e b2 e1

Diese Operatoren bilden mit den obigen Bedingungen eine Algebra auf I.

3.2.5. Operatoren auf Mengen von Intervallen

Die beiden folgenden Operatoren bilden eine Teilmenge von I auf eine Teilmenge von Iab: P(I) → P(I). Sei nun X ∈ P(I).

expand

Der Operator expand zerlegt alle ubergebenen Intervalle in Einheitsintervalle (d.h. In-tervalle I mit end(I) = begin(I)):

expand(X ) := {[b, b] : ∃I ∈ X ∧ b ∈ I}

Beispiel:

expand({[2, 2], [4, 6], [5, 7], [8, 9]}) = {[2, 2], [4, 4], [5, 5], [6, 6], [7, 7], [8, 8], [9, 9]}

collapse

Im Gegensatz dazu”verschmilzt“ collapse alle Intervalle fur die dies moglich ist.

Beispiel:

collapse({[2, 2], [4, 6], [5, 7], [8, 9]}) = {[2, 2], [4, 9]}= collapse(expand({[2, 2], [4, 6], [5, 7], [8, 9]}))

17

3.3. pack und unpack

Iterative Definition: Zu jedem Intervall X ∈ X sei die transitiven Hulle T ∗(X) bezug-lich merges gegeben:

T 0(X) := {X}T n(X) := {I ∈ X : ∃J ∈ T n−1(X) ∧ I merges J} ∀n ∈ N≥1

T ∗(X) := ein (beliebiges) T n(X) mit T n(X) = T n+1(X)

Vereinigt (union) man nun alle Intervalle in jeder Hulle zu einem einzigen Intervall,ergibt sich collapse als Vereinigung dieser Intervalle:

collapse(X ) :=⋃

X∈X

{ [ minI∈T ∗(X)

(begin(I)), maxI∈T ∗(X)

(end(I)) ] }

Deskriptive Definition:

collapse(X ) := {[b1, e2] : ∃ [b1, e1] ∈ X ∧ ∃ [b2, e2] ∈ X (1)

∧ b1 ≤ b2 ∧ e1 ≤ e2 (2)

∧ (¬∃I ∈ X mit I meets [b1, e2]) (3)

∧ (∀n ∈ [b1, e2] gilt: (∃J ∈ X mit n ∈ J))} (4)

Erlauterung:

1: Zu jedem Intervall X in der Ergebnismenge von collapse(X ) existiert ein Intervall[b1, e1] ∈ X mit begin(X) = b1 und ein Intervall [b2, e2] ∈ X mit end(X) = e2. (Eskann auch [b1, e1] = [b2, e2] sein.)

2: X wird großtmoglich gewahlt; es soll gelten [b1, e1] ⊆ X und [b2, e2] ⊆ X.

3: Es soll kein an X angrenzendes Intervall in X existieren.

4: Fur alle Elemente in X muss es ein Intervall in X geben, welches dieses Elemententhalt.

Eine Entsprechung im TSQL-Konzept findet collapse im Verschmelzungsoperatorcoalesce. Dieser Operator hat dort jedoch keine tiefgreifende Bedeutung und dient dazudas Ergebnis lesbarer zu machen (vgl. etwa [Rei99a] Kapitel 3, Definition 10).

3.3. pack und unpack

Mit den nun definierten Operatoren auf Intervallen laßt sich die in 3.1 definierte Relatio-nenalgebra um Funktionalitat fur Zeitstempel (bzw. Intervalle) erweitern. Hierzu werdenexpand und collapse als Aggregationsfunktionen aufgefasst, damit sie auf intervallwer-tige Attribute einer Relation wirken konnen. Diese neu enstehenden Operatoren dienendazu eine

”atomare“,

”zeitpunktartige“ Sicht auf die Information in einer Relation zu

18

3.3. pack und unpack

erhalten (unpack), bzw. diese Information moglichst”zusammengefasst“ und

”redun-

danzfrei“ betrachten zu konnen (pack).

Im folgenden seien X = (S, I) und Y zwei Relationen. Außerdem sei a der Name einesintervallwertigen Attributs (a, I) von X; A := def(S)−{a} sei die Menge der Attribut-namen von X ohne a und G ⊆ I eine Menge (Gruppe) von Tupeln.

3.3.1. collapse und expand als Aggregationsfunktionen

Man kann collapse und expand als Aggregationsfunktionen (nach 3.1.2) auffassen:

collapse(a) : P(I) −→ I mit

collapse(a)(G) := collapse({t(a) : t ∈ G})

und analogexpand(a) : P(I) −→ I mit

expand(a)(G) := expand({t(a) : t ∈ G})

3.3.2. pack und unpack fur ein (einziges) Attribut

Mit diesen neuen Aggregationsfunktionen lassen sich nun pack und unpack fur ein At-tribut a definieren:

packa(X) := ΓA#A,a=collapse(a)

und analogunpacka(X) := ΓA#A,a=expand(a)

Beispiel: Sei folgende Relation X gegeben:

X :=

Name VTMuller [2, 2]Muller [4, 6]

Schmidt [5, 8]Schmidt [8, 9]

Dann ergibt sich fur den Inhalt I von

packVT(X) = ΓName # Name, VT = collapse(VT)

(vgl. das Beispiel zu Gruppierung und Aggregation in 3.1.2):

I = {t′ ∈ T (S) : ∃t ∈ πName(X) ∧t′(Name) ∈ {x(Name) : x ∈ X ∧ x|Name = t} ∧t′(VT) ∈ collapse(VT)({x ∈ X : x|Name = t}) }

19

3.3. pack und unpack

also

I = {t′ ∈ T (S) : ∃t ∈ {Muller, Schmidt} = πName(X) mit

t′(Name) ∈ {Muller} ∧ t′(VT) ∈ {[2, 2], [4, 6]} fur Muller und

t′(Name) ∈ {Schmidt} ∧ t′(VT) ∈ {[5, 9]} fur Schmidt }

und damit die Ergebnisrelation

packVT(X) =

Name VTMuller [2, 2]Muller [4, 6]

Schmidt [5, 9]

Fur unpackVT(X) ergibt sich analog das Ergebnis

unpackVT(X) =

Name VTMuller [2, 2]Muller [4, 4]Muller [5, 5]Muller [6, 6]

Schmidt [5, 5]Schmidt [6, 6]Schmidt [7, 7]Schmidt [8, 8]Schmidt [9, 9]

3.3.3. pack und unpack fur mehrere Attribute

Sei L := l1, . . . , ln mit n ∈ N≥1 eine (nichtleere) Liste3 von Attributnamen:

unpackL(X) := unpackln(unpackln−1(. . . unpackl1(X) . . . ))

und damit

packL(X) := packln(packln−1(. . . packl1(unpackL(X)) . . . ))

Beispiel: Fur X =S# P#[1, 2] [3, 4][5, 6] [7, 8]

ist

3keine Menge, denn fur pack spielt die Reihenfolge eine Rolle

20

3.3. pack und unpack

unpackS#,P#(X) =

S# P#[1, 1] [3, 3][1, 1] [4, 4][2, 2] [3, 3][2, 2] [4, 4][5, 5] [7, 7][5, 5] [8, 8][6, 6] [7, 7][6, 6] [8, 8]

= unpackP#,S#(X).

Mit X =

S# P#[3, 5] [1, 5][2, 4] [1, 4][2, 4] [5, 6][2, 4] [6, 9]

gilt packS#,P#(X) =S# P#[2, 5] [1, 5][2, 4] [6, 9]

6=S# P#[2, 4] [1, 9][5, 5] [1, 5]

= packP#,S#(X).

graphische Darstellung:

1 2 3 4 5

P#

1

9

8

7

6

5

4

3

2

S#1 2 3 4 5

P#

1

9

8

7

6

5

4

3

2

S#1 2 3 4 5

P#

1

9

8

7

6

5

4

3

2

S#

X packS#,P#(X) packP#,S#(X)

Bemerkungen:

• Fur unpack spielt die Reihenfolge der Attribute in L keine Rolle, fur pack dagegenschon.

• Im allgemeinen gilt nicht

packL(X) = packln(packln−1(. . . packl1(X) . . . ))

Mit X wie oben im Beispiel fur pack ergibt sich

21

3.4. Erweiterung der Relationenalgebra

packP#(packS#(X)) = packS#(packP#(X)) =S# P#[3, 5] [1, 4][2, 4] [1, 9]

graphisch:

1 2 3 4 5

P#

1

9

8

7

6

5

4

3

2

S#

Das anfangliche unpackL(X) ist fur packL(X) also notwendig.

3.3.4. pack und unpack ohne Attribute

Um die Operatoren der Relationenalgebra zu ersetzen, wird pack sowie unpack ein Er-gebnis zugewiesen, auch wenn kein Attribut angegeben ist. In diesem Fall gelte:

pack(X) := X und auch unpack(X) := X

3.4. Erweiterung der Relationenalgebra

Mit den obigen Definitionen ist es nun moglich die Operatoren der Relationenalgebra neuzu definieren. Sei L eine Liste von Attributnamen. L kann auch leer sein (Schreibweise:einfach weglassen); in diesem Fall erfullen (wegen 3.3.4) die neu definierten Operatorendie gleiche Funktion wie die alten.

3.4.1. Dyadische Operatoren

Sei etwa die Differenz zweier Relationen X und Y neu definiert als:

X −L Y := packL(unpackL(X)− unpackL(Y ))

Naturlich mussen auch die gleichen Voraussetzungen gelten wie fur die”original“ Diffe-

renz, d.h. auch hier mussen X und Y das gleiche Schema haben.

Analog werden ∪L,∩L und onL definiert.

22

3.4. Erweiterung der Relationenalgebra

3.4.2. Monadische Operatoren

Entsprechendes gilt fur Operatoren, die auf eine einzigen Relation wirken, z.B.:

πLA(X) := packL(πA(unpackL(X)))

analog fur σLϕ , εL

b=β und ΓLA#b1=α1,...,bq=αq

(Fur Umbennennungen ρb=a erscheint eine Erweiterung nicht sinnvoll, weil nur das Sche-ma einer Relation verandert wird und nicht ihr Inhalt.)

Bemerkung: Moglicherweise wird nur das anfangliche unpack oder das abschließendepack ausgefuhrt, nicht aber beides: Durch Projektion, Umbenennung oder Gruppierungkann das in L aufgefuhrte Attribut entfallen (kein pack) oder erst entstehen (kein un-

pack).

23

4. Modellierung temporalerDatenbanken

Fur die Formulierung von Integritatsbedingungen einer temporalen Datenbank sind Be-griffe notwendig, die sich auf Zeitstempel beziehen. In Abschnitt 4.1 wird erlautert, wiesolche Bedingungen mit der erweiterten Relationenalgebra beschrieben werden konnen.

Abhangig davon, welcher Aussage einer temporalen Datenbank ein Gultigkeitszeit-raum zugeordnet sein soll, sind die Relationen entsprechend zu modellieren. Wie dabeivorzugehen ist wird in 4.2 diskutiert.

Die besondere Bedeutung der Gegenwart fuhrt auf die Frage wie eine Modellierungvon Zukunft und Vergangenheit erreicht werden kann (Abschnitt 4.3).

4.1. Integritatsbedingungen

Die Modellierung zeitabhangiger Daten in einem DBMS stellt zusatzliche Anforderungenan den Zustand der Datenbank. Im folgenden werden diese Anforderungen detailliertbesprochen.

4.1.1. Eindeutige Identifikation

Wird eine bestehende Relation ohne Zeitstempel um einen solchen erweitert, sind diebisherigen Schlusselkandidaten1 der Relation moglicherweise nicht mehr zur eindeuti-gen Identifizierung ausreichend: Mehrere verschiedene Tupel in der temporal erweitertenRelation wurden nach dem nicht-temporalen Primarschlussel2 als ein einziges Tupelidentifiziert werden, wenn sich die Werte von nicht zum Primarschlussel gehorendenAttributen im Laufe der Zeit verandern.

In [Kuh97a] und [Bei2001a] wird dies durch die Einfuhrung eines zeitlich invariantenSchlusselsurrogats gelost. So wird etwa eine Abteilung nicht wie in der nicht-temporalenVersion der Datenbank durch ihren Namen, sondern durch eine Nummer identifiziert,die sich niemals andert. Der Name einer Abteilung kann sich somit im Laufe der Zeitandern.

Eine weitere Moglichkeit ist, die Schlusselkandidaten jeweils um den Zeitstempel zuerweitern. Das hat (im Sinne des obigen Beispiels) den Vorteil, dass kein weiteres kunst-liches

”Nummer“-Attribut eingefugt werden muss und den Nachteil, dass eine Abteilung

keine Namensanderung durchfuhren darf. Allerdings sollte auch die Semantik beachtet

1die minimalen Mengen von Attributen, die ein Tupel stets eindeutig identifizieren2der (aus inhaltlichen Grunden) tatsachlich zur Identifikation gewahlte Schlusselkandidat

24

4.1. Integritatsbedingungen

werden:”Ist die ’Finanz’-Abteilung wirklich noch dieselbe Abteilung, sobald sie etwa in

’Forschung und Entwicklung’ umbenannt wird?“3

Formalisierung

Fur eine Relation R ohne Zeitstempel sei A die Menge der Attributnamen von R undK ⊆ A der Primarschlussel. Dann kann bei einer Erweiterung von R zu R um einenZeitstempel VT die eindeutige Identifikation erhalten werden, indem VT zum Primar-schlussel hinzugenommen wird: K := K ∪ {V T}. Die vorherige Integritatsbedingung

∀r1 ∈ R : ∀r2 ∈ R : r1|K = r2|K ⇒ r1 = r2

wird fur die neue Relation R und ihren Primarschlussel K ubernommen:

∀r1 ∈ R : ∀r2 ∈ R : r1|K = r2|K ⇒ r1 = r2

Wenn also bisher fur die Einhaltung der eindeutigen Identifikation gesorgt werden konn-te, sollte dies nach Erweiterung um einen Zeitstempel weiterhin moglich sein.

Bemerkung: Manchmal werden nicht alle Attribute von K benotigt: Eine Teilmengevon K (etwa nur der Zeitstempel) konnte zur Identifikation von Tupeln aus R genugen.Welcher Schlusselkandidat

”der richtige“ ist, hangt stets von der gewunschten Semantik

einer temporalen Datenbank ab.

4.1.2. Widerspruchsfreiheit

Fur gewohnlich wird davon ausgegangen, dass sich widersprechende Aussagen nicht zurgleichen Zeit gultig sind. Die Zeitstempel inhaltlich verschiedener4 Tupel einer Relationdurfen sich also (im Sinne von overlaps) nicht uberlappen.

Da verschiedene Intervalle auch als verschiedene Werte fur Zeitstempel gelten – selbstwenn sie sich uberlappen – wird diese Integritatsbedingung nicht durch die oben be-schriebene Eindeutigkeitsbedingung erfullt. Es reicht jedoch aus, die Einhaltung derEindeutigkeitsbedingung aus 4.1.1 fur eine Relation R auch fur unpackZeitstempel(R) zufordern:

∀r1 ∈ unpackZeitstempel(R) : ∀r2 ∈ unpackZeitstempel(R) : r1|K = r2|K ⇒ r1 = r2

Semantisch sind R und unpackZeitstempel(R) gleich (d.h. sie stellen die gleichen Aussagendar), die Einheitsintervalle in unpackZeitstempel(R) konnen sich aber nicht uberlappen.

3Nomen est omen.4d.h. es besteht ein Unterschied in mindestens einem Attribut, das nicht Zeitstempelattribut ist

25

4.1. Integritatsbedingungen

Ausnahmen

Es sind Relationen mit intervallwertigem Attribut denkbar deren Semantik verlangt,dass Widerspruchsfreiheit nicht eingehalten wird, etwa:

Prozent wahrend91 [10, 15]83 [16, 20]72 [17, 17]87 [10, 20]56 [1, 24]

. . .

Diese Relation konnte beispielsweise die prozentuale Auslastung eines Servers beschrei-ben: Wahrend des Zeitraums von 10 bis 15 Uhr betrug die durchschnittliche Auslastung91%, von 16 bis 20 Uhr 83% um 17 Uhr 72% usf. . .

4.1.3. Zeitliche Fremdschlussel

Eine Fremdschlusselbeziehung von R bzgl. S ist gegeben, falls R den Primarschlusselvon S (= Fremdschlussel von R) enthalt und zu jedem Tupel von R ein Tupel aus S mitden gleichen Werten in all diesen Schlusselattributen existiert (

”R referenziert S“).

Analog zu 4.1.2 gilt: Wenn der Fremdschlussel den Zeitstempel enthalt, wird diese In-tegritatsbedingung nicht durch die Eindeutigkeitsbedingung erfullt. Es reicht jedoch ausdie Fremdschlusselbeziehung fur unpackZeitstempel(R) bzgl. unpackZeistempel(S) zu fordern(siehe Bemerkung zu 4.2.2 fur ein Beispiel).

4.1.4. Redundanzfreiheit

Redundanz tritt in temporalen Datenbanken auf, wenn sich die Zeitstempel inhaltlichgleicher5 Tupel uberlappen: Die zu den Zeitpunkten in der Schnittmenge gehorendenAussagen werden durch mehrere Tupel ausgedruckt. Ausserdem sind verschiedene Aus-sagen redundant, wenn sie sich durch eine einzige ausdrucken lassen. Dies ist der Fall,wenn inhaltlich gleiche Tupel aneinandergrenzende (im Sinne von meets) Zeitstempelhaben. Durch die Vereinbarung die temporale Relation R stets

”gepackt zu halten“ so

dass stetsR = packZeitstempel(R)

gilt, wird diese Redundanz vermieden.Ist eine Relation mit mehr als einem intervallwertigen Attribut (etwa in einer bitempo-

ralen Datenbank) redundanzfrei im obigen Sinn, dann enthalt sie nicht notwendigerweisedie minimale Anzahl von Tupeln. Umgekehrt folgt aus der minimalen Tupelanzahl einerRelation im allgemeinen nicht die Redundanzfreiheit.

5d.h. es besteht kein Unterschied zwischen allen Attributen, die nicht Zeitstempelattribut sind

26

4.1. Integritatsbedingungen

Beispiel

R enthalt mit den beiden Tupeln ([3, 8], [1, 4]) und ([5, 9], [3, 8]) die redundante Aussage([5, 8], [3, 4]). Die

”gepackten“ Relationen enthalten keine Redundanz mehr:

R =

S# P#[3, 8] [1, 4][5, 9] [3, 8][1, 7] [7, 9]

1 2 3 4 5 6 7 8 9S#

P#

1

9

8

7

6

5

4

3

2

packS#, P#(R) =

S# P#[3, 8] [1, 2][3, 9] [3, 4][5, 9] [5, 6][1, 9] [7, 8][1, 7] [9, 9]

1 2 3 4 5 6 7 8 9S#

P#

1

9

8

7

6

5

4

3

2

packP#, S#(R) =

S# P#[3, 4] [1, 4][1, 4] [7, 9][5, 7] [1, 9][8, 8] [1, 8][9, 9] [3, 8]

1 2 3 4 5 6 7 8 9S#

P#

1

9

8

7

6

5

4

3

2

Ausnahmen

Es sind Relationen mit Zeitstempel denkbar deren Semantik verlangt, dass Redundanz-freiheit nicht eingehalten wird, beispielsweise:

27

4.1. Integritatsbedingungen

Prasident JahreFord [1974, 1976]

Carter [1977, 1980]Reagan [1981, 1984]Reagan [1985, 1988]Clinton [1993, 1996]Clinton [1997, 2000]

. . .

Fur diese Relation, als Liste von amerikanischen Prasidenten und den dazugehorigenAmtszeiten, mag es sinnvoll sein sie nicht

”gepackt zu halten“, um anzudeuten wieviele

Legislaturperioden jeder Prasident im Amt war.

4.1.5. Stetigkeit

Weitere weniger elementare Integritatsbedingungen sind selbstverstandlich denkbar undmit der erweiterten Relationenalgebra formulierbar.

Eine nicht explizit in [DDL2003a] behandelte Integritatsbedingung ist etwa die For-derung nach der Stetigkeit temporaler Daten, d.h. der modellierte zeitlichen Ablauf darfkeine Lucken aufweisen.

Formalisierung

Sei K der Primarschlussel von R. Dann sei K := K − {Zeitstempel} die Menge derPrimarschlusselattribute ohne Zeitstempel.

R ist stetig falls K ein Schlusselkandidat fur πZeitstempelK (R) ist. Ist der Zeitstempel das

einzige Primarschlusselattribut, muss πZeitstempelK (R) aus genau einem Tupel bestehen.

Beispiel

Sei {Name, VT)} der Primarschlussel von R.

Mit R :=

Name Gehalt VTAlbers 6000 [1, 60]Muller 3000 [10, 20]

Schmidt 3000 [21, 30]Schmidt 4000 [31, 50]Muller 4000 [51, 60]Muller 5000 [61, 70]

ist πVTName, VT(R) =

Name VTAlbers [1, 60]Muller [10, 20]

Schmidt [21, 50]Muller [51, 70]

.

Da ’Muller’ in πVTName, VT(R) zweimal auftaucht, ist der Name hier kein Schlusselkandidat

und damit R nicht stetig. Allerdings ware R stetig, wenn ’Schmidt’ in ’Muller’ (oderumgekehrt) umbenannt wurde.

28

4.2. Tupel- oder Attributzeitstempel

4.2. Tupel- oder Attributzeitstempel

Die Betrachtung von Relationen mit Tupeln deren Attributwerte in einer gewissen Zeit-spanne konstant bleiben fuhrt zu der Frage, wie solche Relationen zu modellieren sind.Denn wird der Wert eines Attributs haufig verandert, die Werte der anderen Attributeaber kaum, so entstehen viele Tupel, die sich inhaltlich nur in einem einzigen Attributunterscheiden.

Eine Losung ware, fur einzelne Gruppen von Attributen deren Werte gemeinsam ver-andert werden, eigene Zeitstempel einzufuhren – Zeitstempel auf Attributen (AttributeTimestamping) im Gegensatz zu Zeitstempeln auf Tupeln (Tupel Timestamping).Die Einfuhrung weiterer Zeitstempel in dieselbe Relation wurde aber selbstverstandlichdas Problem nur verschlimmern. Es ist also notwendig die Ausgangsrelation in mehrereRelationen aufzuteilen: In [DDL2003a] wird vorgeschlagen fur jedes Attribut eine eigeneRelation zu modellieren. Andern sich Attribute stets synchron, ware es jedoch unno-tig wenn diese Attribute jeweils eigene Relationen erhielten. Jede Gruppe von synchronveranderlichen Attributen kann also in je einer einzigen Relation modelliert werden.

Damit diese Relationen wieder ohne Informationsverlust zur Ausgangsrelation zusam-mengefugt werden konnen, mussen sie jeweils den Primarschlussel (also nach 4.1.1 aucheinen Zeitstempel) enthalten. Die Rekonstruktion kann dann uber den erweiterten Ver-bund (onZeitstempel) geschehen.

Fur die beschriebene Zerlegung gelten die Vor- und Nachteile einer Normalisierung:Anfragen bezuglich des Zeitstempels eines bestimmten Attributs konnen anhand derweniger umfangreichen Teilrelation beantwortet werden. Aufgrund der zusatzlich beno-tigten Verbunde verringert sich jedoch die Ausfuhrungsgeschwindigkeit von Anfragen,die sich nun auf mehrere Relationen beziehen mussen.

Es mag allgemein fur die zugrundeliegende Semantik vorteilhaft sein, die durch dieursprungliche Relation modellierten Aussagen in mehrere kurzere, pragnantere aufzu-teilen. Die Modellierung bestimmter Aussagen kann durch die Zerlegung erst moglichwerden (vgl. Bemerkungen zum Beispiel).

4.2.1. Formalisierung

Sei R eine Relation mit Attributmenge A und sei {A1, . . . , An} ⊂ P(A) eine Menge vonTeilmengen der Attribute. Weiterhin sei L eine Liste intervallwertiger Attribute von R– fur eine temporale Datenbank also das Zeitstempelattribut: L = Zeitstempel.

• R erfullt die Join-Abhangigkeit ∗(A1, . . . , An) sofern stets gilt:

R = πLA1

(R) onL · · · onL πLAn

(R)

(Ist L die leere Liste, entspricht dies der klassischen Definition der Join-Abhangigkeit.)

• Eine Join-Abhangigkeit heißt trivial, falls ein Ai die gesamte Attributemenge vonR ist, also Ai = A fur ein 1 ≤ i ≤ n gilt.

29

4.2. Tupel- oder Attributzeitstempel

• Eine nicht-triviale Join-Abhangigkeit ∗(A1, . . . , An) sei hier als kollektiv bezeich-net, falls stets gilt:

R = πLA1

(R) on · · · on πLAn

(R)

Enthalt jedes Ai (1 ≤ i ≤ n) alle Attribute aus L, so kann R im allgemei-nen nur genau dann uber den klassischen Join-Operator wieder verlustlos ausden Projektionen zusammengesetzt werden, wenn jedes πL

Ai(R) die Werte aller

L-Attribute unverandert laßt, also stets πLAi

(R) = πAi(R) gilt. Im temporalen

Kontext (L = Zeitstempel) bedeutet dies eine synchrone Anderung der Attribute.

Dieser Begriff wird bedeutungslos, falls L die leere Liste ist.

• Die Zerlegung von R in Projektionen πLA1

(R), . . . , πLAn

(R) wird vertikale Dekom-position (von R) genannt. (L kann auch die leere Liste sein.)

• Eine Relation R ist genau dann in der sechsten Normalform (6NF), wenn sie keinenicht-trivialen Join-Abhangigkeit erfullt. (Der Begriff

”6NF“ bezieht sich auf die

gebrauchliche Projection/Join-Normalform, welche mit 5NF abgekurzt wird (sieheBemerkung). Fur einen tieferen Einblick in die Normalisierungstheorie siehe z.B.[Fag79] oder [Dat2000a].)

Um nun Zeitstempel fur Attribute zu modellieren, ist es hinreichend die 6NF fur jedeRelation der temporalen Datenbank zu fordern. Fur jede Relation, die nicht in 6NF ist,kann die durch eine nicht-triviale Join-Abhangigkeit vorgegebene vertikale Dekomposi-tion durchgefuhrt werden, bis alle Relationen diese Forderung erfullen.

Allerdings erscheint es unnotig eine Relation R entsprechend zu zerlegen, falls sichAttribute stets synchron verandern. Dies ist der Fall, wenn R eine kollektive Join-Abhangigkeit erfullt.

Bemerkung: Jede Relation in 6NF ist auch in Projection/Join-Normalform (5NF).Diese ist uber die klassische Join-Abhangigkeit (also mit π und on statt πL und onL)definiert. Fur 5NF wird gefordert, dass jede nicht-triviale Join-Abhangigkeit erfullt, aufeinen Schlusselkandidaten von R zuruckgeht.

4.2.2. Beispiel

R :=

Nr Name Gehalt ChefNr VT2 Albers 6000 2 [1, 60]10 Muller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Muller 4000 2 [51, 60]10 Muller 5000 1 [61, 70]

30

4.2. Tupel- oder Attributzeitstempel

Da zu jedem Zeitpunkt einem Angestellten genau ein Name, ein Gehalt und ein Chefzugeordnet werden, besteht der Primarschlussel hier aus den Attributen ’Nr’ und ’VT’.R erfullt die nicht-triviale Join-Abhangigkeit

∗({Nr, Name, VT}, {Nr, Gehalt, ChefNr, VT})

Damit ist R nicht in 6NF (jedoch in 5NF). Fur die Projektion

πVTNr, Name, VT(R) =

Nr Name VT2 Albers [1, 60]10 Muller [10, 20]10 Schmidt [21, 50]10 Muller [51, 70]

existieren keine nicht-trivialen Join-Abhangigkeiten – sie ist in 6NF. Hingegen erfullt dieProjektion

πVTNr, Gehalt, ChefNr, VT(R) =

Nr Gehalt ChefNr VT2 6000 2 [1, 60]10 3000 7 [10, 30]10 4000 2 [31, 60]10 5000 1 [61, 70]

die Join-Abhangigkeit

∗({Nr, Gehalt, VT}, {Nr, ChefNr, VT})

ist also nicht in 6NF.Unter der (zugegeben unrealistischen) Annahme, dass Gehalt und ChefNr stets ge-

meinsam (also synchron) verandert werden, ist diese Join-Abhangigkeit jedoch kollektiv.Die Zerlegung von R in die obigen beiden Projektionen ermoglicht dann eine Modellie-rung von Zeitstempeln fur die Attribute VT sowie Gehalt synchron mit ChefNr.

Ansonsten kann R anhand dieser (nicht kollektiven) Join-Abhangigkeit aufgeteilt wer-den:

∗({Nr, Name, VT}, {Nr, Gehalt, VT}, {Nr, ChefNr, VT})Die genannten Zerlegungen sind naturlich nur dann sinnvoll, wenn die entsprechenden

Join-Abhangigkeiten fur jede semantisch mogliche Auspragung von R gelten und nichtnur fur diese konkreten Werten.

Bemerkungen:

• Durch die Zerlegung konnen getrennte Aussagen uber Name und Gehalt/ChefNrgetroffen werden – etwa konnte der Namen eines Angestellten fur einem bestimm-ten Zeitpunkt bekannt sein, das Gehalt (und der Chef) jedoch nicht.

Ist das nicht erwunscht, ware eine zeitliche Fremdschlusselbeziehung notwendig:Zu jedem Tupel aus unpack(πVT

Nr, Name, VT(R)) muss ein Tupel ausunpack(πVT

Nr, Gehalt, ChefNr, VT(R)) mit gleichen Werten fur Nr und VT existieren.

31

4.3. Zukunft, Gegenwart und Vergangenheit

• Allein von der konkreten Anzahl der Beispieltupel ausgehend, lohnt sich die De-komposition hier nicht – 8 Tupel in zwei Relationen statt 6 Tupel in einer Relation.Im allgemeinen Fall kann sich das naturlich andern.

• Eine weitere nicht-triviale Join-Abhangigkeit die R offensichtlich erfullt ist:

∗({Nr, VT}, {Nr, Name, VT}, {Nr, Gehalt, ChefNr, VT})

Ob es zweckmaßig ist durch die zusatzliche Relation πVTNr, VT(R) explizit zu mate-

rialisieren wie lange eine Person angestellt ist, kann nicht allgemein entschiedenwerden (vgl. die Relationen S, SS und SP in 5.2.1).

4.3. Zukunft, Gegenwart und Vergangenheit

Wird an den Zeitstempel einer Relationen keine besondere zeitliche Bedingung gestellt,so kann die Aussage eines Tupels fur beliebige Zeitraume in Zukunft, Gegenwart oderVergangenheit gelten.

Ist das Ende der Gultigkeit einer Aussage nicht abzusehen, wird ein kunstlicher”bis-

auf-weiteres“-Wert benotigt. Ebenso musste ein”∞“-Wert fur

”ewig“ geltende Aussagen

existieren, oder zumindest durch den spatesten darstellbaren Zeitpunkt angenahert wer-den konnen. Diese Konstrukte konnen jedoch zu logischen und semantischen Komplika-tionen fuhren (vgl. [DDL2003a] Kapitel 10.5).

Eine weitere Moglichkeit mit unbekannten Gultigkeitszeitraumen umzugehen, ist die-se gar nicht erst zu modellieren: Aussagen konnen in

”historische“ (fur die der Gul-

tigkeitszeitraum bekannt ist) und”aktuelle“ (fur die noch nicht feststeht wann ihre

Gultigkeit endet) aufgeteilt werden. Fur historische Aussagen wird wie bisher die (”voll-

temporale“) Modellierung durch Relationen mit Zeitstempelintervall genutzt. Die (”semi-

temporalen“) Relationen fur aktuelle Aussagen enthalten dagegen kein ganzes Intervallals Zeitstempel, sondern nur den Zeitpunkt des Beginns der Gultigkeit. Steht das Endeder Gultigkeit einer aktuellen Aussage fest, wird das entsprechende Tupel mit dem nunbekannten Gultigkeitszeitraum in die historischen Relationen ubernommen und aus denRelationen fur aktuelle Daten entfernt.

Diese Modellierung hat den Vorteil auf die Einfuhrung der oben genannten speziellenWerte verzichten zu konnnen. Der Nachteil liegt in der zusatzlichen Anzahl von Rela-tionen die durch die Partitionierung nach der Zeit (also durch die zeitliche horizontaleDekomposition) entstehen. Anfragen, fur die keine Unterscheidung nach

”aktuell“ und

”historisch“ erwunscht ist, sind dann meist umstandlicher zu formulieren.

Anmerkungen:

• Es ist naturlich moglich zukunftige Aussagen bei denen der Gultigkeitszeitraum

”feststeht“ ebenso durch eigene Relationen wie die historischen Aussagen zu mo-

dellieren. Allerdings kann nicht automatisch vom DBMS festgestellt werden, wann

32

4.3. Zukunft, Gegenwart und Vergangenheit

eine die Zukunft betreffende Aussage gilt und wann nicht6.

• Hier wird eine Zeitrichtung von”Vergangenheit“ nach

”Zukunft“ unterstellt, da

angenommen wird, dass der Endzeitpunkt der Gultigkeit einer Aussage haufigunbekannt ist. Die umgekehrte Richtung (etwa wenn in einer archaologischen Da-tenbank der Beginn unbekannt ist) laßt sich offensichtlich analog modellieren.

Beispiel

Ist R die Relation aus Beispiel 4.2.2 und”jetzt“ der Zeitpunkt 52, dann ergibt sich:

R :=

Nr Name Gehalt ChefNr VT2 Albers 6000 2 [1, bis-auf-weiteres]10 Muller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Muller 4000 2 [51, bis-auf-weiteres]

und mit horizontaler Dekomposition:

Raktuell :=Nr Name Gehalt ChefNr VT2 Albers 6000 2 110 Muller 4000 2 51

RHistorie :=

Nr Name Gehalt ChefNr VT10 Muller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]

Die nachste Veranderung findet zum Zeitpunkt 61 statt: ’Albers’ scheidet aus und ’Mul-ler’ bekommt ein hoheres Gehalt und einen neuen Chef. Die entprechenden Tupel werdenin die Historie ubernommen.

R :=

Nr Name Gehalt ChefNr VT2 Albers 6000 2 [1, 60]10 Muller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Muller 4000 2 [51, 60]10 Muller 5000 1 [61, bis-auf-weiteres]

mit horizontaler Dekomposition:

6

”Wenn es im Jahre 1879 schon Computer gegeben hatte, wurden diese vorausgesagt haben, dass manInfolge der Zunahme von Pferdewagen im Jahre 1979 im Pferdemist ersticken wurde.“ (John C.Edwards)

33

4.3. Zukunft, Gegenwart und Vergangenheit

Raktuell :=Nr Name Gehalt ChefNr VT10 Muller 5000 1 61

RHistorie :=

Nr Name Gehalt ChefNr VT2 Albers 6000 2 [1, 60]10 Muller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Muller 5000 1 [61, 70]

Anfragebeispiele: Um die Frage nach den Namen der aktuell angestellten Personen zubeantworten, ist nun kein jetzt- oder bis-auf-weiteres-Wert mehr notig, es genugtschlicht:

πName(Raktuell)

im Gegensatz zuπName(σjetzt∈VT(R))

wobei zusatzlich darauf zu achten ist, dass etwa gilt jetzt ∈ [1, bis-auf-weiteres].

Wird allerdings die Frage”Wie lauten die Namen aller jemals angestellten Personen?“

gestellt, ist die Anfrage an die zwei Relationen Raktuell und RHistorie komplizierter:

πName(Raktuell) ∪ πName(RHistorie)

im Gegensatz zuπName(R)

34

Der Tag ist 24 Stunden lang, aber unterschiedlich breit.

(unbekannt)

5. Pragmatik – Anfragebeispiele

In diesem Kapitel wird versucht eine gewisse Pragmatik (Erfahrung,”Gefuhl“) im Um-

gang mit der erweiterten Relationenalgebra aufzubauen. Hierfur werden Anfragen antemporale Datenbanken aus verschiedenen Quellen in der neuen Algebra formuliert.

Dadurch wird eine Erprobung der Ausdrucksfahigkeit der Algebra ermoglicht. Außer-dem wird ein Vorrat an Beispielen zur Veranschaulichung der Modellierung und zumbesseren Verstandnis von Optimierung und Realisierung angeboten.

5.1. Beispiele aus [Bei2001a] – ein Vergleich mit TSQL2

Die in [Bei2001a] beschriebene objekt-relationale Realisierung einer temporalen Daten-banksprache basiert auf dem z.B. in [Sno95a] beschriebenen TSQL2-Ansatz. Statt derdort verwendeten temporalen Elemente wird in dieser Arbeit ein intervallwertiges Zeit-stempelattribut verwendet (siehe 2.2.3).

Um mit TSQL2 vergleichen zu konnen, wird im folgenden zuerst die entsprechendeTSQL2-Anfrage angegeben. Hierbei sind einige syntaktische Besonderheiten zu beachten:

temporale Aufwartskompatibilitat: Dieses Konzept fuhrt dazu, dass Anfragen ohne spe-zielle Kennzeichnung durch das validtime-Schlusselwort nur auf dem aktuellenDatenbestand (von

”heute“) arbeiten. Eine validtime-Anfrage liefert stets das

Attribut mit dem Zeitstempel zuruck, sofern sie nicht als nonsequenced gekenn-zeichnet ist1.

sequenced: Die Operatoren einer mit sequenced gekennzeichneten Anfrage wirken nurauf Tupel, die im gleichen Zeitraum gultig sind. Mit nonsequenced gibt es keineEinschrankungen. Die Angabe von sequenced nach validtime kann entfallen.

coalesce: entspricht etwa einem pack auf das Zeitstempelattribut. (Es dient jedochlediglich dazu das Ergebnis einer Anfrage besser lesbar zu machen.)

5.1.1. Beispieldatenbank

ang:=Nr Name Gehalt ChefNr VT12 Muller 5000 27 [3, 7]

. . .

1In TSQL2 sind temporale (mit verstecktem Zeitstempel) und nicht-temporale Tabellen (ohne Zeit-stempel) zwei verschiedene, nicht immer miteinander vereinbare Arten von Tabellen.

35

5.1. Beispiele aus [Bei2001a] – ein Vergleich mit TSQL2

Der Name der Beispielrelation ist ’ang’ – mit der offensichtlichen Semantik fur Datenvon Angestellten. In diesem Sinn sind die Tupel aus ’ang’ eindeutig durch ’Nr’ und denZeitstempel ’VT’ identifiziert. Da in [Bei2001a] der Zeitstempel jedoch versteckt ist, wirddort zu diesem Zweck das (ebenfalls versteckte) Schlusselsurrogat ’RWO’ eingefuhrt.

Das Attribut ’Nr’ dient der Unterscheidung von Angestellten gleichen Namens. Imfolgenden sei der Einfachheit halber angenommen, dass es keine Namensvettern in ’ang’gibt.2

5.1.2. Anfragebeispiele

Wie lauten die Daten der derzeit angestellten Personen?

SELECT * FROM ang

Sei heute ∈ N die aktuelle Zeit, dann ist die Anfrage formulierbar als:

σheute∈VT(ang)

Es werden alle Tupel ausgewahlt, deren Zeitstempel die aktuelle Zeit enthalten.

Wie lautet der Beschaftigungszeitraum eines Angestellten?

VALIDTIME SELECT x.name, VALIDTIME(x.RWO) FROM ang x

validtime wird hier auf ein Attribut angewandt und liefert laut [Bei2001a]”den zum

großtmoglichem Intervall erweiterten Gultigkeitszeitraum des Attributs“ zuruck.

πVTName, VT(ang)

Um den Beschaftigungszeitraum zu erhalten, werden nur der Name (und der zugehorigeZeitstempel) eines Angestellten projiziert. Das in πVT

... eingebettete pack sorgt danndafur, dass der großtmogliche (zusammenhangende) Zeitraum ausgegeben wird.

In welchen Zeitraumen war das Gehalt eines Angestellten konstant?

NONSEQUENCED VALIDTIME SELECT x.name, VALIDTIME(x.gehalt) FROM ang x

πName, VT(πVTName, Gehalt, VT(ang))

Wie oben werden wieder die fur diese Anfrage unwichtigen Attribute durch die Projekti-on ausgeblendet und dann die Zeitstempel (durch pack) entsprechend zusammengefasst.

Wer verdient(e) wann mehr als 5250?

VALIDTIME COALESCE SELECT name FROM ang WHERE gehalt > 5250

πVTName, VT(σGehalt>5250(ang))

Die Tupel aus ’ang’ mit einem Gehaltswert großer 5250 werden ausgewahlt und dannder großtmogliche Zeitraum fur jeden Namen ausgegeben.

2sonst ist uberall wo nach einem Angestellten gefragt ist, zusatzlich dessen Nummer auszugeben

36

5.1. Beispiele aus [Bei2001a] – ein Vergleich mit TSQL2

Wer verdient(e) mehr als sein Chef und wie heißt/hieß der Chef?

VALIDTIME SELECT x.name, y.name FROM ang x, ang y

WHERE x.chefnr = y.nr AND x.gehalt > y.gehalt

MitX := ρX.Nr = Nr, X.Name = Name, X.Gehalt = Gehalt, X.ChefNr = ChefNr (ang) und

Y := ρY.Nr = Nr, Y.Name = Name, Y.Gehalt = Gehalt, Y.ChefNr = ChefNr (ang)

ergibt sich

πX.Name, Y.Name(σX.ChefNr = Y.Nr ∧ X.Gehalt > Y.Gehalt(X onVT Y ))

Durch den verwendeten erweiterten Join wird zunachst ein unpack auf das Zeitstem-pelattribut von X und Y durchgefuhrt. Die so entstandenen Einheitsintervallen der be-trachtete Zeitraum von Angestellten (X) und Chefs (Y) werden dann durch onVT aufGleichheit gepruft: X.VT = Y.VT.

Welche Angestellten haben jemals eine Gehaltserhohung erhalten?

NONSEQUENCED VALIDTIME SELECT x.name FROM ang x, ang y

WHERE x.name = y.name AND x.gehalt < y.gehalt

AND END(VALIDTIME(x)) = BEGIN(VALIDTIME(y))

(VALIDTIME(x) = x.VT und VALIDTIME(y) = y.VT – denn VT ist verstecktes Attribut)

MitX := ρX.Nr = Nr, X.Gehalt = Gehalt, X.ChefNr = ChefNr, X.VT = VT (ang) und

Y := ρY.Nr = Nr, Y.Gehalt = Gehalt, Y.ChefNr = ChefNr, Y.VT = VT (ang)

ergibt sichπName(σX.VT before Y.VT ∧ X.Gehalt < Y.Gehalt(X on Y ))

Hat ein Angestellter eine Gehaltserhohung bekommen, so mussen zwei Tupel in ’ang’existieren, die seine Gehaltsdaten vor (X) und nach (Y) der Erhohung reprasentieren.Solche Tupelpaare werden ausgewahlt und der zugehorige Name des Angestellten aus-gegeben.

Wie lauteten/lauten alle Angestelltendaten, falls jemand jemals 5500 verdienthat?

VALIDTIME COALESCE SELECT * FROM ang WHERE EXISTS ANYTIME(

VALIDTIME COALESCE SELECT * FROM ang WHERE gehalt = 5500)

Hat ein Angestellter irgendwann 5500 verdient, so ist die Relation σGehalt=5500(ang) nicht-leer. Mit der konstanten Selektionsfunktion

ϕ = σGehalt=5500(ang) 6= ∅

entspricht die Anfrage dem Term σϕ(ang) der erweiterten Relationenalgebra. Es werdenalso entweder alle Angestelltendaten ausgegeben oder keine.

37

5.2. Beispiele aus [DDL2003a]

Wie lauteten/lauten alle Angestelltendaten, als jemand 5500 verdient hat?

VALIDTIME COALESCE SELECT * FROM ang WHERE EXISTS SOMETIME(

VALIDTIME COALESCE SELECT * FROM ang WHERE gehalt = 5500)

Die”Unteranfrage“ in TSQL2 kann durch einen Join entschachtelt werden:

X onVT Y mit

mit Y :=πVT(σGehalt = 5500(ang)) und X := ang

5.2. Beispiele aus [DDL2003a]

In [DDL2003a] werden zunachst temporal-relationale Operatoren in einer beispielhaftenSprache (

”Tutorial D“) definiert, an denen sich die hier vorgestellte erweiterte Relationen-

algebra anlehnt. Kapitel 13 beinhaltet Beispielanfragen an eine Temporale Datenbank.

5.2.1. Beispieldatenbank

Die Beispiele beziehen sich auf drei Relationen:

Relation S:S# during2 [2, 4]

. . .

Diese Relation stellt die Vertragslaufzeit (during) eines Zulieferers (S# – supplier) dar– also hier:

”Zulieferer 2 ist (oder war oder wird sein) von 2 bis 4 unter Vertrag.“

Relation SS:S# Status during2 5 [2, 2]

. . .

Hier wird der Status den ein Zulieferer in einem bestimmten Zeitraum hat/hatte ver-merkt:

”Zulieferer 2 hat den Status 5 zum Zeitpunkt 2.“

Relation SP:S# P# during2 1 [2, 3]

. . .

In SP wird angegeben welche Teile (P# – part) ein Zulieferer in welchem Zeitraum liefernkann:

”Zulieferer 2 kann Teil 1 von 2 bis 3 liefern.“

5.2.2. Anfragebeispiele

Wie lautet der Status des Zulieferers ’1’ zum Zeitpunkt n?

Dies laßt sich fur ein n ∈ N formulieren als

πStatus(σS#=’1’ ∧ n ∈ during(SS))

38

5.2. Beispiele aus [DDL2003a]

Welche Zulieferer konnten im gleichen Zeitraum die beiden Teile ’1’ und ’2’liefern?

Ist bekannt wann ein Zulieferer ’1’ liefern kann

X := πS#, during(σP#=’1’(SP ))

und entprechend wann ein Zulieferer ’2’ liefern kann

Y := πS#, during(σP#=’2’(SP ))

liefert ein erweiterter Verbund das gesuchte Ergebnis:

πS#(X onduring Y )

Welche Zulieferer konnten nie im gleichen Zeitraum die beiden Teile ’1’ und ’2’liefern?

Ist X die Ergebnisrelation aus dem vorigen Beispiel, dann entspricht die Anfrage demTerm

πS#(S)−X

In welchen Zeitraumen konnte ein Zulieferer keine Teile liefern?

S−during πS#, during(SP )

Welche Zulieferer konnten wann welche Teile liefern?

Fur die geforderte Ubersicht erscheint es sinnvoll nicht nur die Zeitraume, sondern auchdie Teile als Intervall auszugeben. Hierzu wird zunachst ein Einheitsintervall fur jedesTeil gebildet. Die großtmoglichen Intervalle werden dann ausgegeben.

πduring, partsS#, parts, during(εparts=[P#,P#](SP ))

In welchen Zeitraumen war mindestens ein Zulieferer unter Vertrag?

πduringduring(S)

Durch die Verwendung der erweiterten Projektion erhalt man die großtmoglichen Zeitrau-me.

In welchen Zeitraumen war kein Zulieferer unter Vertrag?

Sei C eine Relation mit dem intervallwertigen Attribut ’during’, welche das Tupel [0, max]enthalt, wobei max der letzte darstellbare Zeitpunkt ist. Damit ergibt sich das Ergebnis

C −during πduring(S)

39

5.3. Beispiele zu Gruppierung und Aggregation

Welche Zulieferer, die schon mal unter Vertrag waren, sind heute erneut unterVertrag?

Sei heute ∈ N die aktuelle Zeit. Unter der Annahme, dass jedes Tupel in S einem eigenenVertrag entspricht (vgl. 4.1.4), ist die Anfrage formulierbar als:

πS#(σheute∈during(S)) on πS#(σheute>end(during)(S))

Wie lauten die Paare von (verschiedenen) Zulieferern, die zum selben Zeitpunkteinen (neuen) Status zugewiesen bekamen?

Geht man davon aus, dass SS = packduring(SS) gilt, lautet der entsprechende Ausdruckin der Relationenalgebra:

πX.S#, Y.S#(σbegin(X.during) = begin(Y.during) ∧ X.S# < Y.S#(X on Y ) mit

X := ρX.S# = S#, X.during = during (SS) und

Y := ρY.S# = S#, Y.during = during (SS)

Bemerkung: Geht man nicht von der Annahme aus, dass SS stets”gepackt“ gehalten

wird, ware eine kompliziertere Formulierung notig: Es musste festgestellt werden, obfur ein Tupel aus X (bzw. Y ) eine Veranderung des Status bezuglich des vorherigenZeitpunkts vorliegt.

5.3. Beispiele zu Gruppierung und Aggregation

Die bisher betrachteten Quellen bieten wenig Beispiele fur gruppierende oder aggre-gierende Anfragen. Um die Auswirkung von den in die erweiterte Relationenalgebraeingebetteten Operatoren pack und unpack auf solche Anfragen beurteilen zu konnen,erscheinen weitere Beispiele sinnvoll.

5.3.1. Beispieldatenbank

Relation R:

Produkt Preis ZeitRennrad 300 [1, 7]Rennrad 250 [8, 14]Rennrad 270 [15, 25]

Mountainbike 270 [1, 20]Mountainbike 240 [21, 30]

Relation S:

Hersteller Produkt ZeitTeua Rennrad [1, 7]Shnel Rennrad [8, 20]Teua Rennrad [21, 25]Shnel Mountainbike [1, 10]Robus Mountainbike [11, 30]

40

5.3. Beispiele zu Gruppierung und Aggregation

5.3.2. Anfragebeispiele

Was ist der hochste Preis pro Produkt?

ΓProdukt # Produkt, Hochstpreis = max(Preis)(R)

Eine Formulierung mit dem erweiterten Operator ΓZeit... fuhrt zum gleichen Ergebnis, denn

das Maximum ist von der Anzahl der Tupel einer Gruppierung unabhangig: unpackZeit(R)enthalt zwar mehr Tupel als R, jedoch bleibt der Wertebereich von ’Preis’ gleich.

Was ist der Hochstpreis pro Produkt und wann wird er angenommen?

Ist X das Ergebnis aus obiger Anfrage, dann lassen sich die gesuchten Tupel mit einemnaturlichen Verbund aus R herausfiltern:

R on (ρ Hochstpreis = Preis(X))

Eine Formulierung mit onZeit wurde bewirken, dass uberlappende Zeitbereiche mehrererMaxima zusammengefasst werden.

Wieviele verschiedene Produktpreise pro Hersteller gibt es?

Diese Anfrage soll etwa fur den Hersteller ’Shnel’ das Ergebnis ’2’ liefern: Er hat Renn-rader im Zeitraum [8, 14] zum Preis ’250’ und im Zeitraum [15, 20] zum Preis ’270’ sowieMountainbikes im Zeitraum [1, 10] zum Preis ’270’ hergestellt. Das sind genau zwei ver-schiedene Produktpreise.

ΓHersteller # Hersteller, Anzahl = count(πHersteller, Preis(R onZeit S))

Zunachst wird die Beziehung von Hersteller und Preis uber den Fremdschlussel (beste-hend aus Produkt und Zeit) durch die Verwendung eines erweiterten Verbunds herge-stellt. Da nicht nach Produkt (sondern nur nach Preis) unterschieden werden soll undder Zeitraum hier ebenfalls uninteressant ist, wird das Ergebnis auf Hersteller und Preiseingeschrankt.

Wie hoch ist der Durchschnittspreis pro Produkt?

Bei dieser Frage ist zu prazisieren auf welchen Zeitraum sich die Bildung des Durch-schnitts beziehen soll:

ΓProdukt # Produkt, Durchschnitt = avg(Preis)(R)

liefert etwa 270+2402

= 255 als Durchschnittspreis fur Mountainbikes, wobei sich derDurchschnitt auf die zwei Tupel in R bezieht. Andererseits liefert

ΓZeitProdukt # Produkt, Durchschnitt = avg(Preis)(R)

270∗20+240∗1020+10

= 260 als Durchschnittspreis fur Mountainbikes, wobei der Preis ’270’ mit20 Zeiteinheiten ins Gewicht fallt und ’240’ mit 10 Zeiteinheiten.

41

5.3. Beispiele zu Gruppierung und Aggregation

Wie hoch ist der Durchschnittspreis aller Produkte insgesamt pro Zeiteinheit?

Das Produkt ’Rennrad’ hat im Zeitraum [1, 7] den Preis 300; ’Mountainbike’ kostet indiesem Zeitraum 270. Die Anfrage sollte also beispielsweise fur den Zeitraum [1, 7] denDurchschnittspreis 300+270

2= 285 liefern.

ΓZeitZeit # Zeit, Durchschnitt = avg(Preis)(R)

Damit fur jeden einzelnen Zeitpunkt der Durchschnittspreis bestimmt wird, muss hierΓZeit

... benutzt werden. Eine Formulierung mit dem klassischen Gruppierungsoperator Γ...

ergabe πZeit, Preis(R) als Ergebnis, denn alle Zeit-Intervalle in R sind verschieden.

Wie hoch ist der Durchschnittspreis pro Produkt pro Jahr?

Angenommen die Zeiteinheiten im ’Zeit’-Attribut entsprechen fortlaufenden Monatenvom Januar 2000 an, also z.B.:

”Das Produkt ’Mountainbike’ hat im Zeitraum vom

Januar 2000 (1) bis August 2001 (20=12+8) den Preis ’270’“. In diesem Fall laßt sich Sum ein Attribut ’Jahr’ erweitern, welches das zum Zeitstempel gehorige Jahr angibt:

X := εZeit

Jahr=d begin(Zeit)12

e+1999(S)

Bemerkung: Die Benutzung des erweiterten Operators εZeit... ist notwendig, damit ein

Zeitstempel eindeutig einem Jahr zugeordnet werden kann. Im”gepackten“ Zustand ist

dies hier nicht immer moglich (etwa bei [1, 20]).

Wieder sind zwei Formulierungen denkbar:

Γ(Zeit)Produkt, Jahr # Produkt, Jahr, Durchschnitt = avg(Preis)(X)

Fur Mountainbikes ergibt die mit ΓZeit... formulierte Anfrage 270∗12

12= 270 fur das Jahr 2000

und 270∗8+240∗48+4

= 260 fur 2001; entsprechend liefert die Anfrage mit dem klassischem

Γ-Operator 2701

= 270 fur 2000 und 270+2402

= 255 fur 2001.

Wann ist der fruhste Zeitpunkt des Beginns der Produktion pro Hersteller proProdukt?

Der gesuchte Zeitpunkt ware z.B. ’8’ fur den Hersteller ’Shnel’ und das Produkt ’Renn-rad’.

ΓHersteller, Produkt # Hersteller, Produkt, Beginn = min(Beginn)(εBeginn=begin(Zeit)(R))

Durch die Verwendung des Intervalloperators begin wird der fruhste Zeitpunkt einesZeitraums ermittelt.

42

5.3. Beispiele zu Gruppierung und Aggregation

Wie lange wird im Durchschnitt ein bestimmtes Produkt von einem Herstellerproduziert?

Rennrader werden etwa vom Hersteller ’Teua’ durchschnittlich 7+52

= 6 Zeiteinheitenlang produziert.

ΓHersteller, Produkt # Hersteller, Produkt, Durchschnitt = avg(Anzahl)(εAnzahl=count(Zeit)(R))

Der Intervalloperator count liefert die Lange eines Zeitraums.

43

6. Optimierung

Die erweiterte Relationenalgebra basiert auf pack und unpack (siehe 3.4). Fur eine Reali-sierung der erweiterten Relationenalgebra erscheint es deshalb sinnvoll, diese Operatorenmoglichst optimal zu implementieren.

Insbesondere unpack erscheint hier kritisch, denn unter Umstanden enthalt eine Rela-tion im

”unpacked“-Zustand sehr viel mehr Tupel als das letztendliche Ergebnis. Wenn

moglich sollte also die Materialisierung von”ungepackten“ Relationen vermieden werden.

Fur diesen Abschnitt seien X = (S, I) und Y Relationen. L = l1, . . . , ln sei eine Listevon Attributnamen intervallwertiger Attribute von X oder Y , und L := def(S)− L seidie Menge aller Attribute von X, die nicht in L vorkommen.

6.1. Zerlegung in Teilintervalle – split

Die komplette Zerlegung einer Relation X in Einheitsintervalle durch unpackL(X) isthaufig unnotig: meist genugt es zu fordern, dass die betreffenden Intervalle nicht uberlap-pen. Eine Zerlegung von X in maximale, nicht uberlappende Intervalle hat den Vorteil,dass fur gewohnlich weniger Tupel produziert werden als durch unpack(X). In den mei-sten Fallen kann unpack durch einen Operator split ersetzt werden, der solch eineZerlegung in Teilintervalle leistet:splitl

PX(X) zerlegt die Tupel einer Ausgangsrelation X fur ein intervallwertiges Attri-

but l anhand einer Punktmenge PX . Ein Tupel mit dem l-Intervallwert [b, e] wird durcheinen Punkt p ∈ PX in zwei

”Teile“ mit [b, p− 1] und [p, e] gespalten, falls b < p ≤ e gilt.

Ein Tupel x ∈ X mit x(l) = [b, e] wird anhand von

b < p1 < · · · < pm ≤ e fur p1, . . . , pm ∈ PX

demnach durch eine Menge von Tupeln mit folgenden l-Werten ersetzt:

[b, p1 − 1], [p1, p2 − 1], . . . , [pm−1, pm − 1], [pm, e]

Algorithmus fur splitlPX

(X):

Fur alle x ∈ X:Setze q := begin(x(l)).Fur alle p ∈ PX in aufsteigender Reihenfolge mit begin(x(l)) < p und p ≤ end(x(l)):

Fuge ein Tupel t mit gleichen Attributwerten wie x bis auft(l) := [q, p− 1] dem Ergebnis hinzu.Setze q := p.

Fuge ein Tupel t mit t(l) := [q, end(x(l))] dem Ergebnis hinzu.

44

6.1. Zerlegung in Teilintervalle – split

Analog zu unpackL(X) wird splitL(X) durch die Hintereinanderausfuhrung fur alleAttribute in L = l1, . . . , ln definiert:

splitLPX

(X) := splitlnPX

(splitln−1

PX(. . . splitl1

PX(X) . . . ))

Maximale nicht-uberlappende Intervalle

Will man erreichen, dass die l-Intervalle zweier Tupel aus X nur uberlappen, falls siegleich sind, soll also die Bedingung

∀x, x ∈ X : x(l) overlaps x(l) ⇒ x(l) = x(l)

erfullt sein, kann die Menge PX folgendermaßen gewahlt werden:

PX := { begin(x(l)) : x ∈ X ∧ ∃ x ∈ X ∧ x(l) 6= x(l) ∧ begin(x(l)) ∈ x(l) }∪ { end(x(l)) + 1 : x ∈ X ∧ ∃ x ∈ X ∧ x(l) 6= x(l) ∧ end(x(l)) ∈ x(l) }

PX entsteht durch alle Anfangs- und Endpunkten von l-Intervallen aus X, die im l-Intervall eines anderern Tupels liegen (vgl. Abbildung 6.1 im unteren Beispiel).

PX ist die Menge mit der minimalen Anzahl von Elementen fur die splitlPX

(X) obigeBedingung erfullt1. Folglich ist die Zerlegung der Tupel von X anhand von PX so grobwie moglich, die Intervalle haben also großtmogliche Lange und sind damit in diesemSinn maximal.

Eine Zerlegung in maximale nicht-uberlappende Intervalle ist auch mit einer einfacherzu konstruierenden Punktmenge moglich – siehe 6.5.1.

Beispiel:

Mit X :=

Name VTMuller [2, 15]Muller [60, 68]

Schmidt [3, 12]

ist PX = {3, 13}

und damit splitVTPX

(X) =

Name VTMuller [2, 2]Muller [3, 12]Muller [13, 15]Muller [60, 68]

Schmidt [3, 12]

.

1Annahme: Es genugt eine Menge QX mit |QX | < |PX |. Fur p ∈ PX − QX existieren x, x ∈ Xmit x(l) 6= x(l) und es gilt p ∈ x(l) (bzw. p − 1 ∈ x(l)) sowie p ∈ x(l) (bzw. p − 1 ∈ x(l)) alsox(l) overlaps x(l).

45

6.2. Vermeidung von unpack und pack

Schmidt

Müller

3 12

Abbildung 6.1.: Graphische Veranschaulichung von splitVTPX

(X)

6.2. Vermeidung von unpack und pack

Fur fast alle Operatoren der erweiterten Relationenalgebra ist eine Implementierungmoglich, die keine Materialisierung der Ausgangsrelationen im

”unpacked“-Zustand be-

notigt. In manchen Fallen kann sogar eine aquivalente Formulierung ohne anfanglichesunpack angegeben werden. Das abschließende pack ist ebenfalls nicht immer notig: Sinddie Ausgangsrelationen bereits

”gepackt“, so bleibt diese Eigenschaft bei einigen Opera-

toren erhalten. Im folgenden wird jeder Operator detailliert besprochen.

6.2.1. Projektion

Da fur die Projektion die konkreten Werte eines Tupels unwichtig sind, spielt es keineRolle ob die Ausgangsrelation

”ungepackt“ vorliegt oder nicht:

πLA(X) := packL( πA(unpackL(X)) ) = packL( πA(X) )

Werden alle Attribute von X projiziert (oder kein Attribut aus L) kann auch packL

entfallen.

6.2.2. Erweiterung

Bei der Erweiterung

εLb=β(X) := packL( εb=β(unpackL(X)) )

einer Relation X um ein Attribut b wie sie in 3.1.2 beschrieben ist, sind in Abhangigkeitvon β zwei Falle zu unterscheiden: Gilt β = β|L, wird also fur die Berechnung von bkein Gebrauch von den intervallwertigen Attributen aus L gemacht, dann ist unpackL

unnotig:εL

b=β(X) = packL( εb=β(X) )

Das abschließende packL kann auch hier entfallen, sofern X bereits entsprechend”ge-

packt“ ist.Andernfalls laßt sich εL

b=β(X) in einem einzigen Durchlauf uber X erzeugen. In diesemFall mussen entsprechend auch nur intervallwertige Attribute betrachtet werden, die βwirklich benotigt: Ist l ∈ L = {l1, . . . , ln} so kann dieses l entfallen, falls β = β|def(S)−{l}gilt.

46

6.2. Vermeidung von unpack und pack

Algorithmus:

Fur alle x ∈ X:Fur alle pi ∈ x(li) (1 ≤ i ≤ n):

Berechne fur ein Tupel mit gleichen L-Werten wie x, aber mit Einheitsintervallen[pi, pi] das Ergebnis von β. Bilde also ein Tupel t mit t|L := x|L, t(li) := [pi, pi],setze t(b) := β(t|def(S)) und fuge t dem Ergebnis hinzu.

Wende packL fur die eben erzeugten Tupel an.

Durch das”auf Tupelebene“ (Pipelining – siehe 6.3.1) fur jedes x ∈ X durchgefuhrte

packL, wird die Materialisierung von unpackL(X) auf einzelne Tupel beschrankt. Liegtjedoch X nicht bereits

”gepackt“ vor, so kann dadurch kein

”gepacktes“ Ergebnis garan-

tiert werden und es wird zusatzlich ein abschließendes packL(X) benotigt.Ist mehr uber β (und X) bekannt, ist es manchmal moglich εL durch ε zu ersetzen:

Die im Beispiel 5.3.2 verwendete Erweiterung um das Attribut ’Jahr’ konnte mit denregularen Operator ausgedruckt werden, wenn kein Zeitstempel mehr als ein Jahr enthalt.

6.2.3. Selektion

Anhand der Selektionsformel ϕ einer Selektion

σLϕ(X) := packL( σϕ(unpackL(X)) )

konnen analog zur Erweiterung zwei Falle unterschieden werden: Gilt ϕ = ϕ|L, ist dieSelektion also von den intervallwertigen Attributen aus L unabhangig, dann ist unpackL

unnotig:σL

ϕ(X) := packL( σϕ(X) )

Wieder entfallt packL falls X bereits entsprechend”gepackt“ ist.

Andernfalls laßt sich auch σLϕ(X) in einem einzigen Durchlauf uber X ohne die Mate-

rialisierung von unpackL(X) erzeugen:

Fur alle x ∈ X:Fur alle pi ∈ x(li) (1 ≤ i ≤ n):

Berechne fur ein Tupel mit gleichen L-Werten wie x, aber mit Einheitsintervallen[pi, pi] das Ergebnis von ϕ. Fuge also das Tupel t mit t|L := x|L und t(li) := [pi, pi]der Ergebnisrelation hinzu, falls ϕ(t) = wahr ist.

Wende packL fur die eben erzeugten Tupel an.

Wie bei εLb=β(X) sind nur die intervallwertigen Attribute wichtig, die wirklich von ϕ

benotigt werden: Ist l ∈ L so kann dieses l entfallen, falls ϕ = ϕ|def(S)−{l} gilt. Ebensowird zusatzlich ein abschließendes packL(X) benotigt, sollte X nicht bereits

”gepackt“

vorliegen.Angenommen ϕ laßt sich in einen von Attributen in L unabhangigen Teil ϕ1 und einen

abhangigen Teil ϕ2 zerlegen: ϕ = ϕ1 ∨ ϕ2 mit ϕ1 = ϕ1|L und ϕ2 6= ϕ2|L. Dann kannbereits vor der inneren Schleife (

”Fur alle pi ∈ x(li)“) gepruft werden, ob ein Tupel x

selektiert wird, also ϕ1(x) = wahr gilt. Ist dies der Fall, so ist es moglich den Test furϕ2(x) zu ubergehen, das Tupel in das Ergebnis zu ubernehmen und mit dem nachstenTupel fortzufahren. (Analog ware auch eine konjuktive Zerlegung ϕ = ϕ1 ∧ϕ2 moglich.)

47

6.2. Vermeidung von unpack und pack

6.2.4. Verbund

Fur den erweiterte Verbund

X onL Y := packL( unpackL(X) on unpackL(Y ) )

genugt die Zerlegung in maximale nicht-uberlappende Intervalle:

X onL Y = packL( splitLPX∪Y

(X) on splitLPX∪Y

(Y ) )

Die fur split benotigte Punktmenge PX∪Y ergibt sich hier aus den Intervallgrenzen derbeiden Relationen X und Y.

Beispiel:

Sei X :=

Name VTMeier [6, 13]Muller [10, 15]Muller [18, 20]

Schmidt [21, 55]Muller [56, 70]

und Y :=

Name VTMuller [10, 20]Muller [33, 44]

Schmidt [22, 32]Schmidt [45, 50]Schulze [51, 55]

.

Dann konnen die VT-Intervalle anhand der PunktmengePX∪Y := {10, 14, 16, 18, 22, 33, 45, 51, 56} zerlegt werden:

splitVTPX∪Y

(X) =

Name VTMeier [6, 9]Meier [10, 13]Muller [10, 13]Muller [14, 15]Muller [18, 20]

Schmidt [21, 21]Schmidt [22, 32]Schmidt [33, 44]Schmidt [45, 50]Schmidt [51, 55]Muller [56, 70]

, splitVTPX∪Y

(Y ) =

Name VTMuller [10, 13]Muller [14, 15]Muller [16, 17]Muller [18, 20]Muller [33, 44]

Schmidt [22, 32]Schmidt [45, 50]Schulze [51, 55]

splitLPX∪Y

(X) on splitLPX∪Y

(Y ) ergibt

Name VTMuller [10, 13]Muller [14, 15]Muller [18, 20]

Schmidt [22, 32]Schmidt [45, 50]

48

6.2. Vermeidung von unpack und pack

Fur den Spezialfall, dass keine gleichnamigen, intervallwertigen Attribute von X und Yin L enthalten sind, ist onL

... schlicht unnotig:

X onL Y = packL(X on Y )

packL kann hier entfallen, wenn X und Y bereits”gepackt“ sind.

Alternativ laßt sich der erweiterte Verbund auch direkt auf den klassischen Operatorabbilden: Mit dem Intervalloperator overlaps werden Verbundpartner bestimmt, dannmit intersect das Schnittintervall berechnet.

Sei etwa l ∈ L das einzige gleichnamige, intervallwertige Attribut von X und Y . Dannkann zunachst der klassische Verbund fur alle anderen gleichnamigen Attribute gebildetwerden. Hierzu ist l etwa in xl (fur X) bzw. yl (fur Y ) umzubenennen2:

R := ρ l=xl (X) on ρ l=yl (Y )

Mittels overlaps wird nun festgestellt ob Verbundpartner fur das Attribut l vorliegen,wobei intersect den zu l gehorigen Wert liefert:

S := ε l=xl intersect yl (σxl overlaps yl(R))

Zuletzt werden die jetzt uberflussigen Attribute xl und yl von S entfernt und die Ergeb-nisrelation

”gepackt“:

X onl Y = packl(πAlle Attribute bis auf xl und yl(S))

Fur mehrere gleichnamige, intervallwertige Attribut aus L kann analog vorgegangenwerden: Jedes Attribut ist wie oben zunachst exklusiv fur X und Y umzubenennen.Ebenso muss fur jedes Intervallattribut die overlaps-Bedingung gelten und das zuge-horige Intervall mit intersect berechnet werden. Abschließend ist fur das entsprechendprojizierte Ergebnis packL anzuwenden.

Im Beispiel:

εVT = XVT intersect YVT (σXVT overlaps YVT(ρVT = XVT(X) on ρVT = YVT(Y )) =

Name XVT YVT VT = XVT ∩ YVTMuller [10, 15] [10, 20] [10, 15]Muller [18, 20] [10, 20] [18, 20]

Schmidt [21, 55] [22, 32] [22, 32]Schmidt [21, 55] [45, 50] [45, 50]

Anmerkungen:

• Nach dem letztgenannten Verfahren kann pack entfallen, wenn L nur ein einzigesAttribut enthalt und X und Y bereits

”gepackt“ sind.

• Fur den naturlichen Verbund von zwei gleichen Relationen (”Self Join“) gilt stets

X onL X = X on X.

2O.B.d.A gibt es noch kein Attribut xl in X bzw. yl in Y .

49

6.2. Vermeidung von unpack und pack

6.2.5. Vereinigung

Fur die Vereinigung zweier Relationen gilt folgendes Distributivgesetz:

unpackL(X) ∪ unpackL(Y ) = unpackL(X ∪ Y )

Damit kann das anfangliche unpack kann entfallen.

X ∪L Y : = packL( unpackL(X) ∪ unpackL(Y ) )

= packL(unpackL(X ∪ Y ))

= packL(X ∪ Y )

6.2.6. Differenz

Die DifferenzX −L Y := packL( unpackL(X)− unpackL(Y ) )

kann wie der Verbund durch split ausgedruckt werden:

X −L Y := packL( splitLPX∪Y (X)− splitLPX∪Y (X) )

Beispiel: Mit den Beispielrelationen X und Y aus 6.2.4 ergibt sich:

splitLPX∪Y (X)− splitLPX∪Y (X) =

Name VTMeier [6, 9]Meier [10, 13]

Schmidt [21, 21]Schmidt [33, 44]Schmidt [51, 55]Muller [56, 70]

Differenz fur genau ein Attribut

Enthalt L genau ein Attribut l, dann laßt sich X −l Y berechnen ohne auf split zu-ruckgreifen zu mussen. Ahnlich dem in 6.2.4 beschriebenen Verfahren laßt sich zunachstein Verbund von X und Y bilden:

R := ρ l=xl (X) n ρ l=yl (Y )

Ein Tupel des Minuenden X, das keinen Verbundpartner im Subtrahenden Y hat, mussin der Ergebnisrelation vorkommen. Der obige Verbundoperator n (

”Outer Join“) liefert

daher alle Tupel aus X ggfs. zusammen mit Verbundpartnern aus Y .Der Operator n ist nicht Teil der in 3.1 definierten Relationenalgebra, weil hierfur ein

Wert fur”undefiniert“ eingefuhrt werden musste (siehe folgendes Beispiel). (In Oracle ist

solch ein null-Wert jedoch vorhanden und n kann etwa Left Outer Join implementiertwerden.)

Zur Differenzbildung genugt es Tupel aus R zu betrachten fur die XVT overlaps

YVT gilt oder fur die YVT nicht definiert ist:

S := σxl ist undefiniert oder xl overlaps yl(R)

50

6.2. Vermeidung von unpack und pack

Im Beispiel:

σYVT ist undefiniert oder XVT overlaps YVT(ρVT = XVT(X) n ρVT = YVT(Y )) =

Name XVT YVTMeier [6, 13] undefiniertMuller [10, 15] [10, 20]Muller [18, 20] [10, 20]

Schmidt [21, 55] [22, 32]Schmidt [21, 55] [45, 50]

Die Differenz kann nun mit Hilfe einer neuen Aggregationsfunktion minus berechnetwerden:

X −l Y = packl(ΓL# Alle Attribute aus L, minus(xl,yl) (S))

Auf die so erzeugten Partitionen wirkt die Aggregationsfunktion minus, die die Differenzzwischen xl-Wert und den entsprechenden yl-Werten bildet. Die so erzeugten Intervallewerden zusammen mit den anderen zugehorigen Attributen (aus L) ausgegeben.

Algorithmus fur minus: Der folgende Algorithmus fur die Aggregationsfunktion minus

verlangt eine aufsteigende Sortierung nach begin(xl) und (zweitranging nach) begin(yl).Fur eine Gruppe G sind beginnend mit dem ersten Tupel folgende Schritte auszufuhren:

Fur ein Tupel g ∈ G:1. Setze b, e ∈ N auf den Wert des xl-Attributs: [b, e] := g(xl).2. Solange e + 1 ≥ begin(g(xl)) gilt und g(yl) definiert ist:

Setze e := end(g(xl)) falls e < end(g(xl)) ist.Ist b < begin(g(yl)), dann fuge ein Tupel x mit x|L := g|L und

x(l) := [b, begin(g(yl))− 1] dem Ergebnis hinzu.Setze b := end(g(yl)) + 1 falls b ≤ end(g(yl)) ist.Fahre mit dem nachsten Tupel fur g fort.

3. Sofern b ≤ e gilt, fuge dem Ergebnis ein Tupel x mit x|L := g|Lund x(l) := [b, e] hinzu.

Fahre mit dem nachsten Tupel fur g fort.

Mit diesem Algorithmus wird kein abschließendes pack benotigt (vgl. den entsprechendenAlgorithmus fur pack in 6.3.1).

Im Beispiel: Es ergibt sich folgender Ablauf des Algorithmus:

51

6.2. Vermeidung von unpack und pack

Schritt Name XVT YVT Ausgabe [b, e]1 Meier [6, 13] undefiniert – [6, 13]3 Meier [6, 13] undefiniert (Meier, [6, 13]) [6, 13]1 Muller [10, 15] [10, 20] – [10, 15]2 Muller [10, 15] [10, 20] – [21, 15]3 Muller [10, 15] [10, 20] – [21, 15]1 Muller [18, 20] [10, 20] – [18, 20]2 Muller [18, 20] [10, 20] – [21, 20]3 Muller [18, 20] [10, 20] – [21, 20]1 Schmidt [21, 55] [22, 32] – [21, 55]2 Schmidt [21, 55] [22, 32] (Schmidt, [21, 21]) [33, 55]2 Schmidt [21, 55] [45, 50] (Schmidt, [33, 44]) [51, 55]3 Schmidt [21, 55] [45, 50] (Schmidt, [51, 55]) [45, 55]

6.2.7. Durchschnitt

Der Durchschnitt

X ∩L Y := packL( unpackL(X) ∩ unpackL(Y ) )

muss nicht durch X −L (X −L Y ) implementiert werden. Fur den Durchschnitt als Spe-zialfall des Verbunds gilt:

X ∩L Y = X onL Y

6.2.8. Gruppierung und Aggregation

Die Vermeidung von unpack Gruppierung und Aggregation

ΓLA # b1=α1,...,bn=αn

(X) := packL( ΓA # b1=α1,...,bn=αn(unpackL(X)) )

ist ohne genauere Kenntnis uber die benutzten Aggregationsfunktionen nicht moglich.Allgemein laßt sich die Materialisierung einer

”ungepackten“ Relation auf die durch die

Gruppierung erzeugten Gruppen beschranken: Wird etwa die Ausgangsrelation X in dieGruppen G1, G2, . . . zerlegt, dann mussen stets nur jeweils unpackL(G1), unpack

L(G2), . . .materialisiert werden – nicht unbedingt unpackL(X). Allerdings ist durch diese Vorge-hensweise nichts gewonnen wenn A = ∅ gilt, denn dann ist die ganze Relation X dieeinzige

”Gruppe“.

Ist die Gruppierung von den Attributen in L unabhangig (gilt also A ∩ L = ∅) ist esim Prinzip moglich ganz auf unpack zu verzichten, indem die Aggregationsfunktionenersetzt werden:

ΓLA # b1=α1,...,bn=αn

(X) = packL( ΓA # b1=α∗1,...,bn=α∗n(X) )

Eine Funktion αi wird hierbei durch eine Funktion α∗i ersetzt, die das gleiche Ergebnis

wie αi liefert auch wenn die ubergebene Gruppe G nicht”ungepackt“ ist. Das sollte mog-

lich sein, denn aus G laßt sich (selbstverstandlich) unpackL(G) konstruieren. Allgemein

52

6.2. Vermeidung von unpack und pack

wird so die Materialisierung von unpackL(G) lediglich vom relationalen Operator aufdie Aggregationsfunktion verschoben. Abhangig von der benutzten Funktion kann dieseVerschiebung allerdings Vorteile bringen.

Haufig benutzte Aggregationsfunktionen

Sei G eine Gruppe aus der erzeugten Gruppierung und o.B.d.A. L = l1, . . . , ln mit n ∈ N,dann konnen folgende Aggregationsfunktionen (vgl. 3.1.2) ersetzt werden:

• count kann durch count∗ ersetzt werden, indem Gebrauch vom Intervalloperatorcount gemacht wird:

count∗ := {∑t∈G

∏1≤i≤n

count(t(li))}

• Ahnlich kann sum durch sum∗ ersetzt werden:

sum∗(a) := {∑t∈G

t(a) ·∏

1≤i≤n

count(t(li))}

• avg∗ analog mit sum∗ und count∗

• Da Minimum und Maximum vom”gepackten“ oder

”ungepackten“ Zustand einer

Relation unabhangig sind, ist hier keine Ersetzung notwendig: min∗(a) := min(a)und max∗(a) := max(a).

Diese Ersetzungen erlauben nun Gruppierung und Aggregation durchzufuhren ohne dasseine Materialisierung von unpack(G) notig ware.

Da Summe, Minimum und Maximum hier nicht fur Intervalle definiert sind, kanndas oben angegebene Attribut a kein intervallwertiges Attribut sein. Wollte man etwaeine Summe sum(τ(a)) uber ein Intervallattribut a mittels einer Transformationsfunktionτ : I −→ N bilden (z.B. τ(I) := begin(I) fur ein Intervall I), so ware zunachst uberεLneues Attribut=τ (X) ein neues Attribut fur τ einzufuhren, uber das die Summe gebildet

werden kann (vgl. etwa die Beispiele in 5.3.2). In diesem Fall gilt beispielsweise fursum:

ΓLA # b=sum(a)(X) = ΓA # b=sum∗(b)(ε

Lb=τ (X))

Gilt A∩L 6= ∅, ist also die Gruppierung von den Attributen in L abhangig, ist es unnotigganz X durch unpackL(X) bis hin zu Einheitsintervallen aufzuspalten. Eine Zerlegung inmaximale nicht-uberlappende Teilintervalle mittels des split-Operators reicht aus. DieMengen PX sind hierfur entsprechend zu wahlen (siehe 6.1). Dadurch wird es moglichdie Materialisierung einer

”ungepackten“ Gruppe wieder auf die Aggregationsfunktion

zu verschieben:

ΓLA # b1=α1,...,bn=αn

(X) = packL( ΓA # b1=α∗1,...,bn=α∗n(splitLPX

(X)) )

53

6.3. Verbesserungen fur pack

Beispiel: Die Frage nach dem Durchschnittspreises pro Zeiteinheit aus 5.3.2 fuhrt zufolgendem Ergebnis, welches die durchgefuhrte Zerlegung mittels splitZeit

P fur P ={1, 8, 15, 21, 26} erkennen laßt:

Zeit Durchschnitt[1, 7] 285[8, 14] 260[15, 20] 270[21, 25] 255[26, 30] 240

6.3. Verbesserungen fur pack

Nicht nur die Operatoren der erweiterten Relationenalgebra basieren auf unpack, son-dern auch pack selbst (vgl. 3.3.3):

packL(X) := packln(packln−1(. . . packl1(unpackL(X)) . . . ) fur L = l1, . . . , ln

6.3.1. pack fur genau ein Attribut

Enthalt L nur genau ein Attribut, wird also pack fur ein intervallwertiges Attribut l ∈ Langewandt, ist nach Definition 3.3.2 kein unpack notig. Ahnlich dem Algorithmus zurBerechnung der erweiterten Differenz fur ein Attribut in 6.2.6), laßt sich packl(X) ineinem Durchlauf berechnen: Hierfur sei X nach L gruppiert und jede dieser Gruppen nachbegin(l) aufsteigend sortiert. Fur eine solche Gruppe G genugt es folgenden Algorithmusauszufuhren (beginnend mit dem ersten Tupel):

Fur ein Tupel g ∈ G:1. Setze b, e ∈ N auf den Wert des l-Attributs: [b, e] := g(l).2. Solange e + 1 ≥ begin(g(l)) gilt:

Setze e := end(g(l)) falls e < end(g(l)) ist.Fahre mit dem nachsten Tupel fur g fort.

3. Fuge ein Tupel x mit x|L := g|L und x(l) := [b, e] dem Ergebnis hinzu.Fahre mit dem nachsten Tupel fur g fort.

Beispiel: Ist eine Relation X mit den zwei Attributen Name und VT gegeben:

X:=

Name VTMuller [3,7]Muller [3,3]Muller [8,8]Muller [9,12]

Schmidt [1,1]Schmidt [3,3]

54

6.3. Verbesserungen fur pack

Dann ware der Ablauf des beschriebenen Algorithmus fur packVT folgender:

Schritt Name VT Ausgabe [b, e]1 Muller [3, 7] – [3, 7]2 Muller [3, 3] – [3, 7]2 Muller [8, 8] – [3, 8]2 Muller [9, 12] – [3, 12]3 Muller [9, 12] (Muller, [3, 12]) [3, 12]1 Schmidt [1, 1] – [1, 1]3 Schmidt [3, 3] (Schmidt, [1, 1]) [1, 1]1 Schmidt [3, 3] – [3, 3]3 Schmidt [3, 3] (Schmidt, [3, 3]) [3, 3]

Pipelining

Das angegebene Verfahren fur pack liefert das Ergebnis tupelweise zuruck. Nachgeschal-tete Operationen mussen also nicht auf die vollstandige Materialisierung der Ergebnis-relation warten; umgekehrt benotigt pack keine vollstandige Relation als Eingabe umein Ergebnistupel zu liefern (Pipelining). Beispielsweise wird so bei Erweiterung (6.2.2)und Selektion (6.2.3) die Materialisierung von

”ungepackten Tupeln“ auf das gerade be-

trachtete beschrankt.

6.3.2. pack fur mehr als ein Attribut

Enthalt L mehr als ein intervallwertiges Attribut, dann ist packL(X) abhangig von derReihenfolge der Attribute in L (vgl. 3.3.3). Da unpackL(X) jedoch nicht von dieserReihenfolge abhangig ist und pack fur ein einziges Attribut ohne unpack auskommt,laßt sich zunachst ein unpack eliminieren:

packL(X) : = packln(packln−1(. . . packl1( unpackL(X) ) . . . ))

= packln(packln−1(. . . packl1( unpackl1(unpackL−{l1}(X)) ) . . . ))

= packln(packln−1(. . . packl1( unpackL−{l1}(X) ) . . . ))

Fur das erste Attribut l1 aus L wird nun kein unpack mehr benotigt. Wie bereits beiDifferenz und Gruppierung und Aggregation kann das verbleibende unpackL−{l1} durchsplitL−{l1} ersetzt werden:

packln(packln−1(. . . packl1( unpackL−{l1}(X) ) . . . ))

= packln(packln−1(. . . packl1( splitL−{l1}PX

(X) ) . . . ))

Nun wird die Ausgangsrelation X nur noch bis auf maximale nicht-uberlappende Teil-intervalle zerlegt, wenn die Punktmengen fur splitL−{l1} wie in 6.1 gewahlt werden.

55

6.3. Verbesserungen fur pack

Beispiel:

Fur X =

S# P#[3, 5] [1, 5][2, 4] [1, 4][2, 4] [5, 6][2, 4] [6, 9]

(vgl. das Beispiel zu 3.3.3)

liefert die Anwendung von splitP#PX

anhand der Punktmenge PX = {1, 5, 6, 7}

splitP#PX

(X) =

S# P#[3, 5] [1, 4][3, 5] [5, 5][2, 4] [1, 4][2, 4] [5, 5][2, 4] [6, 6][2, 4] [7, 9]

.

Ausgehend von diesem Ergebnis ist packS#(splitP#PX

(X)) =

S# P#[2, 5] [1, 4][2, 5] [5, 5][2, 4] [6, 6][2, 4] [7, 9]

und damit packP#(packS#(splitP#PX

(X))) =S# P#[2, 5] [1, 5][2, 4] [6, 9]

= packS#, P#(X).

Umgekehrt ergibt splitS#PX

mit PX = {3, 4}

splitS#P (X) =

S# P#[3, 4] [1, 5][5, 5] [1, 5][2, 2] [1, 4][3, 4] [1, 4][2, 2] [5, 6][3, 4] [5, 6][2, 2] [6, 9][3, 4] [6, 9]

,

packP#(splitS#PX

(X)) =

S# P#[2, 2] [1, 9][3, 4] [1, 9][5, 5] [1, 5]

und damit packP#, S#(X) = packS#(packP#(splitS#PX

(X))) =S# P#[2, 4] [1, 9][5, 5] [1, 5]

.

56

6.4. Verbesserungen fur unpack

6.4. Verbesserungen fur unpack

Sollte eine Materialisierung von unpackL(X) explizit notig sein, kann dies auf der Grund-lage von packL(X) folgendermaßen geschehen:

Fur alle x ∈ packL(X):Fur alle l ∈ L:

Fur alle n ∈ x(l):Fuge ein Tupel t mit t|L := x|L und t(l) := [n, n] dem Ergebnis hinzu.

6.5. Verbesserungen fur split

Die fur den split-Operator benotigte Punktmenge kann einfacher berechnet werden alsin angegeben 6.1 ist.

Ein Pipelining auf Tupelebene wie fur pack bzw. unpack ist zwar nicht moglich, trotz-dem laßt sich durch Partitionierung der Ausgangsrelation der Umfang einer Materiali-sierung von Zwischenergebnissen vermindern.

6.5.1. Berechnung der Punktmenge

In 6.1 wurde die Menge PX eingefuhrt mit der durch splitlPX

(X) eine Relation X inmaximale nicht-uberlappende l-Intervalle zerlegt werden kann:

PX := { begin(x(l)) : x ∈ X ∧ ∃ x ∈ X ∧ x(l) 6= x(l) ∧ begin(x(l)) ∈ x(l) }∪ { end(x(l)) + 1 : x ∈ X ∧ ∃ x ∈ X ∧ x(l) 6= x(l) ∧ end(x(l)) ∈ x(l) }

Dies ist jedoch auch mit einer einfacher zu berechnenden Punktmenge moglich:

PX :=⋃x∈X

{ begin(x(l)), end(x(l)) + 1 }

PX ⊃ PX ist eine Obermenge von PX , hat also eventuell nicht mehr die minimalen Anzahlvon Elementen. Allerdings erzeugt splitl

PX(X) immer noch Intervalle großtmoglicher

Lange3.

Liegt PX aufsteigend sortiert vor:

P = {p1, . . . , pm} mit pi < pi+1 fur alle 1 ≤ i < m,

dann wird durch splitlPX

(X) ein Tupel x ∈ X durch Tupel xi ersetzt, die sich nur im

Attribut l von x unterscheiden: xi(l) = [pi, pi+1 − 1] sofern x(l) overlapsxi(l) gilt.

3Ist p ∈ PX − PX dann existiert kein x ∈ X mit begin(x(l)) < p ≤ end(x(l)). p ”spaltet also keinTupel aus X“.

57

6.5. Verbesserungen fur split

Anders formuliert laßt sich splitlPX

(X) mit einer Relation QX die ein einziges Attribut

l und die Tupel xi(l) = [pi, pi+1− 1] enthalt, durch einen Verbund darstellen (vgl. 6.2.4):

splitlPX

(X) = σxl overlaps yl (ρ l=xl (X) on ρ l=ql (QX))

Die Berechnung von PX benotigt einen Durchlauf uber alle l-Intervalle von X. Um diesenAufwand zu sparen, ware es denkbar PX in gewisser Form fur jede Relation vorzuhalten– etwa in Gestalt der Relation QX . Sinnvoll ware auch die Indexierung der Tupel einerRelation X anhand der Punkte aus PX .

6.5.2. Pipelining und Partitionierung

Haufig ist es sinnvoll splitL(X) nur fur einzelne Partitionen zu materialisieren und Xso

”Stuck fur Stuck“ zu bearbeiten. Dieses Pipelining auf Basis einer Partitionierung

kann somit bei Differenz, pack und Gruppierung & Aggregation angewandt werden: BeiX −L Y und pack fur mehrere Attribute ist eine Partitionierung nach L moglich, beiΓL

A#...(X) (siehe 6.2.8) eine Partitionierung nach L ∩ A.Außerdem werden die Tupel von X eventuell feiner zerlegt als notig ware, wenn die

Menge der zerlegenden Punkte fur ganz X gebildet wird. Werden sie fur jede Partitioneinzeln berechnet, konnen insgesamt weniger Tupel entstehen. Allerdings ist abzuwagenob die zusatzliche Erzeugung von Punktmengen den Mehraufwand lohnt.

Beispiel fur X −L Y : Sind X und Y wie im Beispiel zur Differenz in 6.2.4, dann gibtes verschiedene Werte fur das Attribut ’Name’ etwa ’Muller’ und ’Schmidt’. Daher sindfur X die Partitionen

X1 =

Name VTMuller [10, 15]Muller [18, 20]Muller [56, 70]

und X2 =Name VT

Schmidt [21, 55]zu betrachten, sowie

fur Y die Partitionen Y1 =Name VTMuller [10, 20]Muller [33, 44]

und Y2 =Name VT

Schmidt [22, 32]Schmidt [45, 50]

.

Bei ’Muller’ ist PX1∪Y1 = {10, 16, 18}, was keine Veranderung fur X1 bedeutet und furY1 die Zerlegungen folgende Zerlegung liefert:

splitVTPX1∪Y1

(Y1) =

Name VTMuller [10, 15]Muller [16, 17]Muller [18, 20]Muller [33, 44]

Fur Y2 bedeutet die Zerlegung durch PX2∪Y2 = {22, 33, 45, 51} keine Veranderung. FurX2 gilt:

58

6.5. Verbesserungen fur split

splitVTPX2∪Y2

(X2) =

Id VTSchmidt [21, 21]Schmidt [22, 32]Schmidt [33, 44]Schmidt [45, 50]Schmidt [51, 56]

Wie angedeutet ist hier zu beobachten, dass durch die partitionsbasierte Zerlegung ins-gesamt weniger Tupel entstehen: 3 + 5 + 4 + 2 = 14 Tupel von X1, X2, Y1 und Y2 imGegensatz zu 9 + 7 = 16 Tupeln von X und Y im Beispiel von 6.2.4 (’Schulze’ und’Meier’ nicht mitgezahlt).

Pipelining fur X −L Y

Ein Pipelining fur X −L Y kann etwa durch folgenden Algorithmus geschehen:

Partitioniere X in X1, X2, . . . und Y entsprechend in Y1, Y2, . . . nach L.Fur jedes Xi:

Erzeuge fur jedes l ∈ L die Punktmenge PXi∪Yiuber Xi und Yi.

Wende damit splitlPXi∪Yi

auf Xi und Yi an.

Fuge packL(Xi − Yi) dem Ergebnis hinzu.

Das abschließende pack kann entfallen, falls L genau ein Attribut enthalt und der Minu-end X in

”gepackter“ Form vorliegt. Fur mehrere Attribute kann pack fur jedes Attribut

einzeln erfolgen (siehe 6.3.1).

Zusatzliche Partitionierung nach L

Wie schon bei unpackL(X) ist bei splitL(X) die Reihenfolge in der split fur dieeinzelnen Attribute in L ausgefuhrt wird unwichtig. Ist allerdings splitl(X) bereits furein l ∈ L ausgefuhrt worden, kann in den hier beschriebenen Fallen X zusatzlich nachdiesem l partitioniert werden. Hierdurch entstehen bei der Anwendung von split furdas nachste Attribut aus L wieder weniger Tupel. Das so erzeugte Ergebnis ist allerdingsabhangig von der Reihenfolge der Liste L.

Beispiel fur X −S#, P# Y :

Sei X :=S# P#

[1, 70] [4, 16]und Y :=

S# P#[2, 15] [4, 9][60, 68] [5, 19]

.

Mit PX∪Y = {2, 16, 60, 69} ergibt splitS#PX∪Y

(Y ) = Y =: Y ′ und

59

6.5. Verbesserungen fur split

splitS#PX∪Y

(X) =

S# P#[1, 1] [4, 16][2, 15] [4, 16][16, 59] [4, 16][60, 68] [4, 16][69, 70] [4, 16]

=: X ′.

Fur S#=[2, 15] ergibt sich die Punktmenge {4, 10} und fur S#=[60, 68] die Menge{5, 17}. Fur alle anderen Werte von S# ist die Punktmenge gemaß 6.1 leer. Nach derAnwendung von splitP# auf die S#-Partitionen ergibt sich:

X =

S# P#[1, 1] [4, 16][2, 15] [4, 9][2, 15] [10, 16][16, 59] [4, 16][60, 68] [4, 4][60, 68] [5, 16][69, 70] [4, 16]

und Y =

S# P#[2, 15] [4, 9][60, 68] [5, 16][60, 68] [17, 19]

.

Ohne zusatzliche Partitionierung nach S# enthielte splitP#PX∪Y

(X ′) mit der PunktmengePX∪Y = {4, 5, 10, 17} 20 Tupel (statt 7): [4, 16] zerlegt in 4 Intervalle pro 5 Tupel.split

P#PX∪Y

(Y ′) enthielte 5 Tupel (statt 3).

60

7. Realisierung

In diesem Kapitel wird eine exemplarische Realisierung der erweiterten Relationenalge-bra beschrieben. Es soll eine Anfragesprache an eine temporale Datenbank mit einemeinzigen Zeitstempel implementiert werden. Grundlage hierfur bildet das RDBMS Oraclein Version 9.2 ([OTN], [OraDoc]).

Da eine vollstandige Realisierung der erweiterten Relationenalgebra innerhalb desDBMS aus den im folgenden genannten Grunden nicht moglich ist, besteht dieses Ka-pitel aus drei Teilen: Zunachst wird in 7.1 erlautert welche Erweiterungen im DBMSvorgenommen werden. In 7.2 wird die Uebersetzung von Termen der erweiterten Al-gebra fur das DBMS beschrieben. Abschließend wird in 7.3 eine Implementierung derRelationenalgebra als Anfragesprache vorgestellt.

7.1. Erweiterung des DBMS

In Oracle ist keine relationale Algebra an sich vorhanden. Stattdessen konnen in derStructured Query Language (SQL) Anfragen an Tabellen gestellt werden ([OraSQL]).Zusatzlich ist es moglich in einer prozeduralen Sprache (Procedural Language/SQL –PL/SQL) Prozeduren und Funktionen fur SQL-Objekte zu implementieren ([OraPLSQL]).

Die Erweiterung der SQL-Syntax im Sinne der erweiterten Relationenalgebra ist inOracle nicht moglich. Daher findet die Auswertung eines Terms der Algebra außerhalbdes DBMS statt (siehe 7.3).

Eine Zuordung von relationalen Operatoren zu SQL-Konstrukten ist jedoch wie folgtdurchfuhrbar: Sei X eine Relation mit den Attributen x1, x2, . . . und X die entprechendeSQL-Tabelle mit den Spalten x1, x2,.... Ebenso sei Y die entsprechende Tabelle zurRelation Y .

relationaler Operator: SQL-Konstrukt:[Identitat von] X select * from X

πx1,x2(X) SELECT x1, x2 from X

εb=β(X) SELECT β as b, x1, x2,... from X

ρb=x1 SELECT x1 as b, x2, x3,... from X

σϕ(X) select * from X WHERE ϕX on Y select * from X NATURAL JOIN Y

X − Y select * from X MINUS Y

X ∪ Y select * from X UNION Y

X ∩ Y select * from X INTERSECT Y

Γx1,x2 # b=α(X) select α as b from X GROUP BY x1, x2

61

7.1. Erweiterung des DBMS

SQL unterscheidet sich jedoch von den in 3.1 beschriebenen Ausgangsstrukturen:

• Eine Relation enthalt ein Tupel nur hochstens einmal; in einer SQL-Tabelle kannim Gegensatz dazu eine Zeile mehrfach vorkommen. Um dies auszugleichen kannzu jeder erzeugten SQL-Anfrage explizit eine Duplikatelimination verlangt werden(select DISTINCT).

• In SQL existiert ein expliziter Wert fur”undefiniert“: null. Dieser Wert erfahrt

durch die erweiterte Relationenalgebra keine spezielle Behandlung – insbesondereist der null-Wert als Zeitstempel unzulassig.

Im folgenden wird davon ausgegangen, dass die bei Operatoren der erweitertenRelationenalgebra verwendete Zeitstempel-Spalte keine null-Werte enthalt. Fursonstige Spalten (auch intervallwertige!) wird der null-Wert jedoch geduldet.

• Es gibt keinen Datentyp fur Wahrheitswerte (etwa boolean) in SQL.”Wahr“ wird

also entsprechend durch die Zahl 1 und”falsch“ durch 0 dargestellt – etwa

”where

I_overlaps(Zeit1, Zeit2) = 1“ statt”where I_overlaps(Zeit1, Zeit2)“.

7.1.1. Intervalle und Intervalloperatoren

Um Anfragen in der erweiterten Relationenalgebra nach SQL zu ubersetzen, muss einIntervallbegriff zur Modellierung von Zeitstempeln im DBMS vorhanden sein.

Im Oracle RDBMS existieren bereits Datentypen fur Intervalle (interval year to

month und interval day to second) und sogar ein Zeitstempel (timestamp).Der Zeitstempel entspricht einer bis auf Sekundenbruchteile genauen Datumsangabe,

also eher einem wie in Kapitel 2 beschriebenen Zeitpunkt mit festgelegter Semantik. Ent-sprechend modellieren interval year to month und interval day to second Zeit-spannen einer bestimmten Granularitat. Solch eine Zeitspanne hat keinen Anfangszeit-punkt.

Implementierung eines Datentyps fur Intervalle

Als Grundlage fur die hier beschriebene Erweiterung erscheinen diese Datentypen unge-eignet. Deshalb wird ein neuer Datentyp fur Intervalle erzeugt, wobei naturliche Zahlendie zugrundeliegenden Zeitpunkte darstellen:

create or replace type interval_type as object (

b integer, -- Anfangszeitpunkt

e integer, -- Endzeitpunkt

--

static function min return integer, -- kleinstmogliches b

static function max return integer, -- großtmogliches e+1

--

constructor function interval_type (b integer, e integer)

return self as result,

62

7.1. Erweiterung des DBMS

--

map member function convert return integer

);

Die map-Funktion dient dem DBMS zum Vergleich von Intervallen: Sie bildet ein Inter-vall auf die ganze Zahl b * (max - min) + e ab. Durch den Vergleich dieser Zahlengilt ein Intervall I nun

”kleiner“ als ein Intervall J falls I.b < J.b oder zumindest

I.e < J.e gilt.

Nun ware es naturlich moglich Schnittstellen zwischen interval-type und den bereitsvorhandenen Typen herzustellen: Zum Beispiel konnte ein Operator I_begin_as_date

zu einem interval-type-Intervall die zugehorige timestamp-Datumsangabe des An-fangszeitpunktes b liefern.

Implementierung der Intervalloperatoren

Ausgehend vom Datentyp interval-type lassen sich gemaß 3.2 Operatoren fur Interval-le in PL/SQL implementieren. Jedem Operatornamen wird hierbei ein ’I_’ vorangestelltum Konflikte mit SQL- oder PL/SQL-Schlusselwortern zu vermeiden. Wie schon ange-deutet liefern Vergleichsoperatoren 0 fur

”falsch“ und 1 fur

”wahr“ zuruck.

Beispiele:

create or replace function I_count (i interval_type)

return integer is

begin

return i.e - i.b +1;

end I_count;

create or replace function I_overlaps (i1 interval_type, i2 interval_type)

return integer is

begin

if (i1.b <= i2.e) and (i2.b <= i1.e) then

return 1;

end if;

return 0;

end I_overlaps;

create or replace function I_intersect (i1 interval_type, i2 interval_type)

return interval_type is

b integer := i1.b;

e integer := i1.e;

begin

if I_overlaps(i1, i2) = 1 then

if i2.b > b then b := i2.b; end if;

63

7.1. Erweiterung des DBMS

if i2.e < e then e := i2.e; end if;

return interval_type(b,e);

end if;

raise_application_error(-20979, ’illegal interval-intersection: ’

||I_toString(i1)||’ intersect ’||I_toString(i2));

end I_intersect;

Alle implementierten Intervalloperatoren sind in Anhang A aufgelistet.

7.1.2. Implementierung von count∗, sum∗ und avg∗

Die in 6.2.8 beschriebenen erweiterten Aggregationsfunktionen count∗, sum∗ und avg∗

konnten als gewohnliche Aggregationsfunktionen mit zusatzlichem Zeitstempelargumentimplementiert werden. Ist R die Tabelle aus 5.3.1, so konnte

select Produkt, avg(Preis, Zeit) from R group by Produkt

den nach der Zeit gewichteten Durchschnittspreis pro Produkt liefern. Da jeder Aggre-gationsfunktion in Oracle jedoch nur genau ein Argument erlaubt ist, mussen solcheAnfragen entsprechend mit dem Intervalloperator I_count umformuliert werden. ImBeispiel fur avg∗:

select Produkt, sum(Preis * I_count(Zeit)) / sum(I_count(Zeit))

from R group by Produkt

Die Gewichtung nach einer Intervallspalte i muss also vom Benutzer selbst vorgenommenwerden: count∗ wird so zu sum( I_count(i) ), sum∗(a) zu sum(a * I_count(i)) undavg∗(a) zu sum(a * I_count(i)) / sum(I_count(Zeit)).

7.1.3. Implementierung von pack

Um pack zu implementieren sind verschiedene Ansatze denkbar. Zwei Moglichkeitenwerden im folgenden naher erlautert, wobei das letztgenannte Verfahren bei der Imple-mentierung zur Anwendung kommt.

Mengenwertige Aggregationsfunktionen

Da bei der Definition der erweiterten Relationenalgebra in Kapitel 3 Aggregationsfunk-tionen die Mengen zuruckliefern eine wichtige Rolle spielen, ist es naheliegend zu Versu-chen pack auch so zu implementieren. Zum Beispiel ist packZeit(R) fur die Relation Raus 5.3.1, definiert als (vgl. 3.3):

packZeit(R) := ΓProdukt, Preis # Produkt, Preis, Zeit=collapse(Zeit)

Mit einer entsprechend implementierten Aggregationsfunktion ließe sich die AnfrageπZeit

Produkt, Zeit(R) wie folgt in SQL umsetzen:

64

7.1. Erweiterung des DBMS

select Produkt, pack(Zeit) from R group by Produkt, Preis

Hierbei wurde außer Acht gelassen, dass die von pack gelieferte Menge auch in derErgebnisrelation entsprechend

”entschachtelt“ werden muss. Dies laßt sich jedoch mit

vom DBMS bereitgestellten Mechanismen durchfuhren.Dieses Konzept scheitert an der unvollkommenen Unterstutzung von Mengen als Ruck-

gabewert von selbstdefinierten Aggregationsfunktionen. Enthalt die Ruckgabemenge mehrals etwa 50 Intervalle, so wird die Ausfuhrung der Aggregationsfunktion mit einem in-ternen Speicherfehler seitens Oracle abgebrochen. Es scheint, dass die internen Pufferfur umfangreichere Ergebnisse von Aggregationsfunktion zu klein dimensioniert sind.

Eine Variante von Aggregationsfunktionen in Oracle sind die”Windowing Aggregate

Functions“ (siehe [OraDW]). Eine solche Funktion aggregiert fur jedes Tupel der Gruppeeinen Wert bezuglich einer Umgebung (

”Fenster“) dieses Tupels. Somit ware es also

moglich – ohne eine Menge als Ruckgabewert – mehr als einen einzigen Wert pro Gruppezuruckzuliefern.pack laßt sich allerdings nicht so implementieren, da nicht festgestellt werden kann,

ob noch Tupel aus der Gruppe folgen (was aber notig ist – vgl. Algorithmus in 6.3.1).(Es war moglich dieses Problem durch zweimalige Ausfuhrung der Windowing Aggre-gate Function zu umgehen. Dieser Ansatz wurde jedoch nicht weiter verfolgt, weil eineImplementierung mittels Pipelined Table Functions als vielversprechender erschien.)

Pipelined Table Functions

Das Oracle-DBMS bietet mit einer sogenannten Table Function die Moglichkeit einePL/SQL-Funktion zu implementieren, die eine Tabelle zuruckliefert (siehe [OraDCD]).Da in PL/SQL kein Datentyp fur SQL-Tabellen existiert, muss allerdings der Ruckga-bewert einer solchen Table Function explizit umgewandelt werden (mit Hilfe des TABLE-Operators). Als Eingabe benotigt eine Table Function fur pack ebenfalls eine SQL-Tabelle. Hierzu wird eine Anfrage in einem CURSOR-Objekt gekapselt.

Beispiel: Sei R die Tabelle aus 5.3.1. Dann laßt sich πZeitProdukt, Zeit(R) wie folgt ubersetzen:

select * from TABLE( pack( CURSOR(

select Produkt, Zeit from R order by Zeit ) ) )

Zunachst sind die verwendeten Datentypen festzulegen:

create or replace package PACK_pkg as

type rowrec is record ( -- Datentyp einer Zeile

produkt varchar2(20),

zeit interval_type

);

type rowrec_table is table of rowrec; -- Datentyp der Ruckgabe

type refcur is ref cursor return rowrec; -- Datentyp der Eingabe

end PACK_pkg;

65

7.1. Erweiterung des DBMS

Nun kann pack entsprechend dem Algorithmus aus 6.3.1 implementiert werden:

function pack (relation PACK_pkg.refcur) return PACK_pkg.rowrec_table

pipelined is

tupel PACK_pkg.rowtype;

packed PACK_pkg.rowtype;

new_group boolean;

begin

fetch relation into tupel;

if relation%found then

packed := tupel;

loop

fetch relation into tupel;

exit when relation%notfound;

new_group := case

when not packed.produkt = tupel.produkt then true

when packed.zeit.e +1 < tupel.zeit.b then true

else false

end;

if new_group then

pipe row (packed);

packed := tupel;

else

if packed.zeit.e < tupel.zeit.e then

packed.zeit.e := tupel.zeit.e;

end if;

end if;

end loop;

pipe row (packed);

end if;

close relation;

return;

end pack;

Durch das Pipelining fur nachfolgende Operatoren kann die Materialisierung der ge-samten Ergebnistabelle vermieden werden (pipe row (packed)). Pipelining fur voran-gehende Operatoren (fetch relation into tupel) erlaubt den Umfang von Zwischen-ergebnissen zu minimieren (etwa bei unpack; siehe unten).

Der pack-Operator wird jedoch nicht nur fur eine konkrete Relation benotigt, sondernfur Relationen allgemein. Das Schema solcher Relationen ist auch nicht im Voraus be-kannt, weshalb die verwendeten Datentypen nicht wie im oben gezeigten Code ange-

66

7.1. Erweiterung des DBMS

geben werden konnen. Die Implementierung eines allgemeinen pack-Operators benotigtalso Datentypen, deren konkrete Struktur erst zur Laufzeit festgelegt werden muss.

Oracle bietet solche Typen an: Der Datentyp SYS_refcursor kapselt beliebige An-fragen (

”Weakly Typed Cursor“) und mit dem Datentyp SYS.AnyDataSet lassen sich

beliebige Mengen modellieren (vgl.”Transient and Generic Types“ in [OraDCD]). Eine

allgemeine Implementierung der pack-Funktion konnte also etwa diese Form haben:

function pack (relation SYS_refcursor) return table of SYS.AnyDataSet

pipelined is

tupel SYS.AnyDataSet;

packed SYS.AnyDataSet;

new_group boolean;

begin

fetch relation into tupel;

[...]

end pack;

Leider scheint es nicht moglich, die Struktur der Tupel die einem SYS_refcursor ent-stammen, zur Laufzeit zu bestimmen. Das ist jedoch notig um den pack-Algorithmusdurchzufuhren: Im obigen Code wird durch fetch relation into tupel versucht einkonkretes Tupel aus relation der Variablen tupel zuzuweisen. Dies schlagt zur Laufzeitfehl, da tupel nicht den richtigen konkreten Typ hat.

Um trotzdem beliebige Relationen”packen“ zu konnen, muss also vor einer SQL-Anfrage

die passende konkrete PL/SQL-Funktion fur pack erzeugt werden (ggfs. auch mehre-re Funktionen). Das bedeutet, dass in jedem Schritt bei der Auswertung eines Termsder erweiterten Relationenalgebra alle Attribute inklusive deren Datentypen bekanntsein mussen. Ist dies der Fall, kann anhand dieser Information eine konkrete pack-Implementierung erzeugt werden: Der Code fur pack liegt nicht konkret vor, sondernnur als Schablone (Template, Makro,. . . ). In diese wird der konkrete Text zu Attribut-namen und Datentypen einer Relation eingesetzt. Der komplette konkrete Code wirddann vor der eigentlichen Anfrage an das DBMS ubergeben.

Beispiel: Aus

new_group := case $case_clause

when packed.$pack_arg.e +1 < tupel.$pack_arg.b then true

else false

end;

wird im konkreten Fall fur πZeitProdukt, Zeit(R) (vgl. oben):

new_group := case

when not packed.produkt = tupel.produkt then true

when packed.zeit.e +1 < tupel.zeit.b then true

else false

end;

67

7.1. Erweiterung des DBMS

Da die Auswertung der erweiterten Relationenalgebra im Evaluator-Teil der Implemen-tierung (7.3) geschieht, findet dort auch die beschriebene Textersetzung statt.

7.1.4. Implementierung von unpack

Eine Realisierung von unpack wird fur Selektion und Erweiterung benotigt (siehe 6.2.3und 6.2.2). unpack kann analog zu pack als Table Function nach dem Algorithmus aus6.4 implementiert werden. Dies ermoglicht ein Pipelining wie in 7.1.3 beschrieben.

Da der Algorithmus fur pack (und unpack) eine sortierte (bzw. partitionierte) Eingabeerfordert (6.3.1), muss entweder unpack diese Sortierung liefern, oder das (gesamte!)Ergebnis von unpack erneut sortiert werden. Fur die Selektion σZeitstempel

ϕ ist ersteresmoglich, weil lediglich Tupel bezuglich ϕ herausgefiltert werden.

Bei der Erweiterung εZeitstempelb=β ist das fur allgemeines β nicht moglich, denn die Rei-

henfolge der Werte fur b ist nicht bekannt. Um zusatzlich nach b zu sortieren kann esalso notwendig sein, das gesamte

”ungepackte“ Ergebnis zu materialisieren! Denkbar wa-

re pack, die Erweiterung und unpack als eine einzige Table Function zu implementierenum den Algorithmus aus 6.2.2 zu realisieren, wobei ggfs. β genauer festgelegt werdenmusste. Dieser Ansatz wurde hier allerdings aus Zeitgrunden nicht implementiert.

7.1.5. Implementierung von split

Fur split muss zunachst die Menge der zerlegenden Punkte gebildet werden. Ist R

eine Tabelle entsprechend der Beispielrelation aus 5.3.1, dann kann dies folgendermaßengeschehen:

select rownum as n, p from

(select alias.Zeit.b as p from R alias

UNION

select alias.Zeit.e+1 as p from R alias)

order by p asc;

Die Zeilen der Ergebnistabelle entsprechen den p1, . . . , pm aus 6.5.1, wobei die Spalten den Index reprasentiert. (Ohne alias fur R erkennt Oracle die Spalte Zeit nicht alsintervallwertige Spalte.)

Die Tabelle Q gemaß 6.5.1 wird entsprechend gebildet:

select interval_type(B.p, E.p-1) as Zeit from

(select rownum as n, p from

(select alias.Zeit.b as p from R alias

UNION

select alias.Zeit.e+1 as p from R alias)

order by p asc) B,

(select rownum as n, p from

(select alias.Zeit.b as p from R alias

UNION

68

7.2. Ubersetzung von Termen

select alias.Zeit.e+1 as p from R alias)

order by p asc) E

where E.n = B.n+1;

Schließlich ergibt sich split(R) aus einem Verbund mit Q:

select Produkt, Preis, I_intersect(R.Zeit, Q.Zeit) as Zeit

from R, Q

where I_overlaps(R.Zeit, Q.Zeit) = 1;

Die Verwendung einer Pipelined Table Function fur split erscheint unsinnig, da fur dieBildung der Punktmenge bzw. von Q die gesamte Ausgangsrelation zunachst komplettdurchlaufen werden muss. Deshalb wird R explizit materialisiert, d.h. als SQL-Tabelleerzeugt (create table ... as (select ...)). Genauso wird split(R) gebildet undebenfalls explizit materialisiert.

Um eine allgemeine Form des split-Operators zu erhalten, wird analog zu pack ei-ne Textersetzung fur alle von der konkreten Relation abhangigen Teile des Verfahrensdurchgefuhrt.

Bemerkung: Eine Implementierung von split anhand beliebiger Punktmengen warenach diesem Verfahren zwar auch moglich, wird aber im weiteren nicht benotigt. Dereinzige Fall bei dem split uberhaupt benotigt wird, ist die Gruppierung nach demZeitstempel.

7.1.6. Temporale Metadaten

Fur die Auswertung von Termen der erweiterten Relationenalgebra mussen die Na-men und Datentypen aller Attribute von jeder Relation in der Datenbank bekanntsein (vgl. 7.1.3). Im Oracle-DBMS ist diese Information in Form einer Metadatentabelle(USER_TAB_COLUMNS; siehe [OraDD]) vorhanden.

Zusatzlich ist es sinnvoll zu wissen ob eine Relation”gepackt“ vorliegt. Fur manche

Operatoren der erweiterten Relationenalgebra kann dann das abschließende pack ent-fallen (siehe Kapitel 6). Diese wird in einer entsprechenden Metadatentabelle namensUSER_TEMPORAL_TABLES festgehalten:

create table USER_TEMPORAL_TABLES (

table_name varchar2(30) not null,

packed_on varchar2(30) not null

)

7.2. Ubersetzung von Termen

Die Operatoren der erweiterten Relationenalgebra konnen auf Basis von pack, splitund anderen Table Functions in eine einzige SQL-Anfrage ubersetzt werden. Wie in 7.1

69

7.2. Ubersetzung von Termen

beschrieben, mussen hierfur ggfs. vorher PL/SQL-Funktionen erzeugt und Relationenexplizit materialisiert werden. Fur jeden erweiterten Operator wird im folgenden daszugehorige Ubersetzungsmuster angegeben.

Es sei (o.B.d.A) X eine Relation mit den Attributen z, x1 und x2 und X die ent-prechende SQL-Tabelle mit den Spalten z, x1 und x2. Zu einer Relation Y sei Y dieentsprechende SQL-Tabelle. z (bzw. z) sei der gemeinsame Zeitstempel von X und Y .

7.2.1. Projektion

Wie schon im Beispiel fur pack (7.1.3) angedeutet, laßt sich etwa πzx1,x2,z(X) folgender-

maßen implementieren:

select * from TABLE( pack( CURSOR(

SELECT x1, x2, z from X order by x1, x2, z )))

Das abschließende pack kann entfallen, wenn kein Zeitstempel nach der Projektion mehrubrig ist, etwa bei πz

x1,x2(X):

SELECT x1, x2 from X

7.2.2. Erweiterung

Fur die Erweiterung εzb=β(X) wird wie in 6.2.2 beschrieben unpack benotigt. unpack

kann analog zu pack als Pipelined Table Funktion implementiert werden (siehe 7.1.4).Die entsprechende Anfrage lautet:

select * from TABLE( pack( CURSOR

SELECT β as b, x1, x2 from TABLE( unpack( CURSOR (

select * from X order by x1, x2, z )))

order by x1, x2, b, z )))

7.2.3. Selektion

Analog zur Erweiterung (siehe oben; vgl. 6.2.3) wird eine Table Function fur unpack

benutzt. Die Materialisierung einer”ungepackten“ Relation kann hier durch Pipelining

vermieden werden (vgl. 7.1.4). Die erweiterte Selektion σzϕ(X) kann so formuliert werden:

select * from TABLE( pack( CURSOR

select * from TABLE( unpack( CURSOR (

select * from X order by x1, x2, z )))

WHERE ϕ )))

70

7.2. Ubersetzung von Termen

7.2.4. Verbund

Der erweiterte Verbund wird nach dem in 6.2.4 beschriebenen Verfahren erzeugt. Hatetwa Y die drei Spalten z, x1 und y1, dann wird der erweiterte Verbund X onz Y durchfolgende Anfrage gebildet:

select x1, x2, y1, I_intersect(X.z, Y.z) as z from

X JOIN Y

ON (I_overlaps(X.z, Y.z) = 1 AND X.x1 = Y.x1)

7.2.5. Differenz

Der in 6.2.6 angegebene Algorithmus kann wie pack ebenfalls als Table Function imple-mentiert werden. Haben X und Y das gleiche Schema, dann wird die Differenz X −z Yfolgendermaßen ausgedruckt:

select * from TABLE( minus ( CURSOR (

select * from X LEFT OUTER JOIN Y

ON ( (Y.z is null OR I_overlaps(X.z, Y.z) = 1)

AND X.x1 = Y.x1 AND X.x2 = Y.x2 )

order by x1, x2, X.z, Y.z )))

7.2.6. Vereinigung

Die Vereinigung X ∪z Y benotigt lediglich ein abschließendes pack:

select * from TABLE( pack ( CURSOR (

select * from X UNION Y )))

7.2.7. Durchschnitt

Haben X und Y das gleiche Schema, dann ist der Durchschnitt X ∩z Y ein Sonderfalldes Verbunds (siehe oben). Deshalb wird hierfur keine eigene Ubersetzung benotigt.

7.2.8. Gruppierung und Aggregation

Wird nicht nach dem Zeitstempel gruppiert, ist beispielsweise fur Γzx1,x2 # z=α(X) hoch-

stens ein pack notig (vgl. 6.2.8).

select * from TABLE( pack ( CURSOR (

select α∗ as z from X

GROUP BY x1, x2 order by x1, x2, z )))

Die erweiterten Aggregationsfunktionen α∗ sind wie in 7.1.2 beschrieben vom Benutzerentsprechend zu formulieren.

Enthalt die Ergebnisrelation keinen Zeitstempel, entfallt auch das abschließende pack.Fur Γz

x1,x2 # b=α(X) sind keine Table Functions mehr notwendig:

71

7.3. Implementierung des Evaluators

select α∗ as b from X GROUP BY x1, x2

Wird jedoch nach z gruppiert, so ist fur Γzz,x1 # b=α(X) die Anwendung von split not-

wendig. Sei also Xsplitted die durch das in 7.1.5 beschriebene Verfahren materialisierteRelation. Damit ergibt sich die Anfrage:

select α∗ as b from Xsplitted GROUP BY x1, x2

Zum Abschluß ware pack notwendig, wenn die Ergebnisrelation den Zeitstempel enthielte(vgl. oben).

7.3. Implementierung des Evaluators

Um Anfragen auf Grundlage der erweiterten Relationenalgebra an ein temporales Da-tenbanksystem stellen zu konnen, wurde ein Programm namens

”Evaluator“ entwickelt.

Der Evaluator1 wertet Ausdrucke einer abgeleiteten Anfragesprache aus indem SQL- undPL/SQL-Anweisungen erzeugt werden. Auf Wunsch werden diese vom DBMS ausgefuhrtund das Ergebnis dargestellt.

Hier wird zunachst die Grammatik der zugrundeliegenden Anfragesprache vorgestelltund im Anschluß eine Ubersicht uber die Struktur des Programms gegeben.

7.3.1. Implementierung des Evaluators

Um einen Term in der erweiterten Relationenalgebra auswerten zu konnen, wurde eineAnfragesprache auf Grundlage der Algebra entwickelt. Die implementierte Grammatikdieser Sprache ist in Anhang B in der Erweiterte Backus-Naur-Form (EBNF; [Wir77])aufgefuhrt.

Jedem relationalen Operator wird ein Schlusselwort zugeordnet (etwa project fur π).Fur alle Operatoren bis auf die Umbenennung (rename – ρ) existiert eine temporale Vari-ante mit vorangestelltem

”t“. Das Zeitstempelattribut kann uber ein dem Schlusselwort

nachfolgendes”^[Attributname]“ angegeben werden (z.B. tproject^Zeit Produkt,

Zeit (R)). Fehlt die explizite Angabe eines Zeitstempels, dann wird das intervallwerti-ge Attribut benutzt, sofern dies eindeutig ist (tproject Produkt, Zeit (R) fur R aus5.3.1).

Um Aggregationen, Erweiterungen und Selektionsbedingungen angeben zu konnenwerden diese in geschweifte Klammern eingeschlossen. Der Text zwischen den Klammernwird ohne Weiterverarbeitung in die SQL-Anfrage eingebaut. Geschlossene geschweifteKlammern mussen quotiert werden:

”}“ →

”\}“. Zum Beispiel entspricht dem Term

ΓZeitProdukt # b = sum∗(Preis)(R) der Ausdruck

1Man konnte den Evaluator als ”Ubersetzer“ bezeichnen, weil ein Term der erweiterten Relationenal-gebra nach SQL (und PL/SQL) ubersetzt wird. Da jedoch im Rahmen des Evaluators diese Uberset-zung (auf Wunsch) vom DBMS interpretiert und das Ergebnis (also der Wert der Terms) dargestelltwird, scheint die Bezeichnung ”Interpreter“ auch berechtigt zu sein.

72

7.3. Implementierung des Evaluators

tgroup by Produkt

aggregate number { sum(Preis * I_count(Zeit)) } as b (R)

Da Projektion, Umbenennung und Erweiterung alle auf select abgebildet werden,wurde project in der Anfragesprache erweitert: Umbenennung und Erweiterung sindjetzt auch in der Projektion moglich, z.B.:

project Produkt, Preis, Zeit as VT (R) = rename Zeit as VT (R)

tproject number {Preis * 10} as Preis10, Zeit (R)

project entspricht also mehr einer SQL-select-Anweisung, als der in 3.1.2 definiertenProjektion. Umbenennung und Erweiterung konnen nun als Spezialfalle der Projektionimplementiert werden.

Bei Verbund, Vereinigung, Differenz und Durchschnitt ist es moglich mehr als zweiRelationen anzugeben. Die Auswertung erfolgt dabei von links nach rechts, es gilt al-so minus(X,Y,Z) = minus(minus(X,Y), Z). (Die Auswertungsreihenfolge ist naturlichnur fur die Differenz wichtig, denn Verbund, Vereinigung und Durchschnitt sind asso-ziative Operatoren.)

Gross- und Kleinschreibung spielt fur die Auswertung der Anfragesprache keine Rolle.Mehrere aufeinanderfolgende Leerzeichen2 werden zu einem einzigen Leerzeichen zusam-mengefasst.

Die angegebene Grammatik ist eine kontextfreie LL(1)-Grammatik. Die Erkennungvon Ausdrucken der Anfragesprache kann deshalb uber die Methode des rekursiven Ab-stiegs erfolgen (

”top-down“; vgl. z.B. [Wir96a]).

7.3.2. Ablauf der Anfrageauswertung

Fur die Benutzung des Programms gibt es zwei Moglichkeiten: Als Kommandozeilenpa-rameter kann ein Ausdruck der Anfragesprache oder eine Datei ubergeben werden. Derubergebene Ausdruck bzw. die Ausdrucke in der Datei werden dann ubersetzt und dieUbersetzung ausgegeben. Ohne Parameter startet der Evaluator in einem interaktivenModus. Ahnlich zu sqlplus von Oracle konnen hier Ausdrucke direkt ausgewertet wer-den. Im interaktiven Modus oder in einer Datei ist jeder Ausdruck mit einem Semikolon(”;“) abzuschliessen.Es ergibt sich der in Abbildung 7.1 skizzierte Ablauf: Zunachst werden die Meta-

daten (vgl. 7.1.6) der temporalen Datenbank ermittelt. Dann kann eine Anfrage in eineSQL-Anfrage ubersetzt werden, wobei eventuell vorher PL/SQL-Funktionen erzeugt undRelationen explizit materialisiert werden mussen. Der gesamte Code wird dann entwederausgegeben oder an das DBMS zur Auswertung ubermittelt. Im letzten Fall kann dasErgebnis dieser Auswertung im interaktiven Modus dargestellt werden.

2genauer: Whitespace Characters, also auch Tabulatoren und Zeilenwechselzeichen

73

7.3. Implementierung des Evaluators

Intervalloperatoren

Intervalle

Zeit

Erweiterung

Tabellen und Metadaten

Oracle DBMS

EvaluatorAnfrage

Übersetzung

Ergebnis oder Ergebnis

SQL (und PL/SQL)

Übersetzung:

Metadaten

(Tabellennamen, Spaltennamen, Datentypen, ...)

Abbildung 7.1.: Ablauf der Anfrageauswertung

7.3.3. Struktur des Evaluators

Der Evaluator ist als textbasiertes Programm in Perl realisiert ([WCS96a], [CPAN],[PerlDoc]). Die Struktur des Evaluators ist in 7.2 dargestellt.

Das ausfuhrbare Programm hat den Namen evaluator.pl. Je nach Aufruf wird dieBenutzerschnittstelle (ui.pm) im interaktiven Modus gestartet oder zur Erzeugung einerlesbaren Ubersetzung benutzt. Uber das Modul db.pm werden Datenbankzugriffe abge-wickelt. Die Erkennung und Ubersetzung eines Ausdrucks geschieht im parser-Modul:Fur jeden Operator der erweiterten Relationenalgebra sind Behandlungsroutinen vorhan-den, die im handler-Modul zusammengefasst sind. Diese Routinen nutzen die Schablo-nen fur pack, unpack, split und minus (vgl. 7.1.3), welche durch das Modul templatesgekapselt werden.

ui.pm

parser.pm db.pm

evaluator.pl

project restrict

join union ...

project restrict

join union ...

pack

split minus

unpack

handler.pm

templates.pm

temporal

regular

Abbildung 7.2.: Struktur des Evaluators

74

For an indefinite time I clung to the machine as itswayed and vibrated, quite unheeding how I went,and when I brought myself to look at the dials againI was amazed to find where I had arrived.

(H.G. Wells, The Time Machine)8. Ausblick

Mit dieser Arbeit wurde ein Konzept zur relationalen Modellierung zeitabhangiger Da-ten geschaffen. Die Definition der erweiterten Relationenalgebra erlaubt die Formulierungvon zeitlichen Zusammenhangen im relationalen Kontext. Durch die Implementierung ei-ner Anfragesprache fur temporale Datenbanken auf Grundlage eines bestehenden DBMSkonnte die Realisierbarkeit eines temporalen DBMS belegt werden. Von diesem Stand-punkt aus zeichnen sich weitere Moglichkeiten ab:

Anderungsoperationen

Einfugen, Loschen und Andern laßt sich folgendermaßen mit der erweiterten Relationen-algebra ausdrucken: Sei R eine Relation und t ein Tupel passend zum Schema von R.Weiterhin sei T eine Relation deren Inhalt nur aus dem Tupel t besteht.

• Einfugen von t in R (tinsert^[Zeitstempel]): R ∪Zeitstempel T

• Loschen von t aus R (tdelete^[Zeitstempel]): R−Zeitstempel T

• Verandern von t in R (tupdate^[Zeitstempel]): loschen und verandert einfugen

Eine Verbesserung kann erreicht werden, indem diese Anderungsoperationen durch be-reits bestehende insert-, update- und delete-Befehle implementiert werden statt durchVereinigung und Differenz (siehe [DDL2003a] Anhang A).

Zusatzlich kann die Uberwachung von zeitlichen Integritatsbedingungen an diese An-derungsoperationen gekoppelt werden (

”Trigger“; siehe auch [GL95c]).

Vollstandige Integration in ein bestehendes DBMS

Um ein temporales DBMS zu schaffen, ist eine Implementierung der erweiterten Al-gebra in ein bestehendes DBMS notwendig. Die Funktionalitat des Evaluators mußtedazu vollstandig in das DBMS integriert werden. Wegen der erlauterten Probleme mitallgemeinen pack und split Operatoren war dies hier nicht zu realisieren.

Kombination mit raumlichen Datenmodellen

Eine Integration von zeitlichen Konzepten in raumliche Modelle ist haufig wunschens-wert. In einem raumzeitlichen Datenmodell konnen beispielsweise bewegte Objekte dar-gestellt werden (vgl. z.B. [KPS2003b] oder [Kle2003b]).

75

8. Ausblick

Anfrageoptimierungen

Anfragen an temporale Datenbanken bieten ein großes Optimierungspotential. Zusatzlichzur Optimierung der klassischen relationalen Operatoren gibt es Verbesserungsmoglich-keiten fur Anfragen mit zeitlichem Bezug.

Algebraische Optimierungen

Die Verschiebung von Operatoren innerhalb einer Anfrage kann durch die hier imple-mentierte SQL-Ubersetzung beeintrachtigt werden: Eine Verschiebung uber einen split-Operator hinweg ist nicht moglich, weil hier ein Zwischenergebnis explizit materialisertwird.

Theoretisch bilden Pipelined Table Functions keine solche Hurde. Praktisch wird dieEingaberelation einer Table Function in einem Cursor-Objekt gekapselt. Es ist anzu-nehmen, dass keine Verschiebung von Operatoren uber diese Grenze hinweg stattfindet.Eine Verschiebung folgender Art ware dann nicht mehr moglich:

restrict {Bedingung} ( tminus(X, Y) ) =>

tminus( restrict {Bedingung} (X), restrict {Bedingung} (Y) )

Eine Implementierung der Operatoren ohne diese Probleme wurde eine schnellere Aus-fuhrung temporaler Anfragen bedeuten.

Indexe

Die Unterstutzung der zeitlichen Dimension durch eigene Indexe wurde in dieser Arbeitnicht betrachtet. Eine sortierte Speicherung temporaler Relationen verspricht bereitseinen Geschwindigkeitsgewinn, weil die durch Table Functions realisierten Algorithmenstets eine Sortierung nach dem Zeitstempel (und eine Partitionierung nach den restlichenAttributen) verlangen.

Zur Indexierung konnten raumliche Indexe (R-, R∗-, RSS-Baume, . . . ) benutzt wer-den (vgl. [Loc2001a], [Sch2003c], [Kle2003b]): Die benotigte zweite Dimension ware inbitemporalen Datenbanken durch den zweiten Zeitstempel gegeben. Sonst kann ein the-matisches Attribut oder ein Wert ohne konkrete Semantik als zweite Dimension dienen(etwa ein festes Intervall oder nochmal der Zeitstempelwert).

Anhand der Intervallgrenzen der Zeitstempel einer Relation kann auch ein B∗-Baumaufgebaut werden (siehe [TCG93a] Kapitel 18). Dies entspricht der Vorhaltung der fursplit benotigten Punktmenge in einer Baumstruktur.

76

A. Intervalle und Intervalloperatoren

Deklaration des Intervalldatentyps:

create or replace type interval_type as object (

b integer, -- Anfangszeitpunkt

e integer, -- Endzeitpunkt

--

static function min return integer, -- kleinstmogliches b

static function max return integer, -- großtmogliches e+1

--

constructor function interval_type (b integer, e integer)

return self as result,

--

map member function convert return integer

);

Name und Signatur jedes implementierten Intervalloperators:

-- Operatoren fur ein einziges Intervall:

I_begin (i interval_type) return integer

I_end (i interval_type) return integer

I_count (i interval_type) return integer

I_toString (i interval_type) return string

I_contains (n integer, i interval_type) return integer

-- Vergleichsoperatoren:

-- Signatur "(i1 interval_type, i2 interval_type) return integer"

I_included_in I_included_in_neq

I_includes I_includes_neq

I_before I_after

I_begins I_ends

I_meets I_overlaps I_merges

-- intervallwertige Operatoren:

-- Signatur "(i1 interval_type, i2 interval_type) return interval_type"

I_union I_intersect I_minus

77

B. Grammatik der Anfragesprache

Der aus der erweiterten Relationenalgebra entwickelten Anfragesprache liegt folgendeGrammatik zugrunde:

B.1. Terminalsymbole

B.1.1. Schlusselworter

rename as

[t]project [t]extend [t]restrict [t]group by aggregate

[t]join [t]minus [t]union [t]intersect

B.1.2. Bezeichner und Werte

table column datatype anything

Mit table sind alle Tabellennamen des zugrundeliegenden Datenbankschemas gemeint.column soll eine Spalte bezeichnen und datatype einen Datentyp. anything ist einebeliebige Zeichenfolge, wobei geschlossene geschweifte Klammern zu quotieren sind:

”}“ →

”\}“. Dies entspricht den α, β, ϕ in Aggregation, Erweiterung und Selektion (vgl.

7.2).

B.1.3. Sonderzeichen

, ^ ( ) { }

B.2. Grammatik

term = listop "(" term_list ")" | monop "(" term ")" | table

term_list = term { "," term }

B.2.1. monop

monop = project | rename | extend | restrict | group

rename = "rename" rename_arg

78

B. Grammatik der Anfragesprache

project = ( "tproject" pack_on | "project" ) project_arg

extend = ( "textend" pack_on | "extend" ) extend_arg

restrict = ( "trestrict" pack_on | "restrict") restrict_arg

group = ( "group" pack_on | "group" ) group_arg

B.2.2. monop-Argumente

rename_arg = renaming { "," renaming }

project_arg = projection { "," projection }

extend_arg = extension { "," extension }

group_arg = "by" column_list "aggregate" extension

restrict_arg = pass_through

projection = column | renaming | extension

renaming = column " " naming

extension = datatype " " pass_through " " naming

B.2.3. listop

listop = ( "t" listop_token pack_on | listop_token ) "(" term_list ")"

listop_token = ( "join" | "minus" | "union" | "intersect" )

B.2.4. sonstiges

pass_through = "{" anything "}"

column_list = column { "," column }

naming = ( "as" | " " ) column

pack_on = [ "^" column ]

79

Literaturverzeichnis

[All83a] J. F. Allen. Maintaining Knowledge about Temporal Intervals. Communi-cations of the ACM, 26(11):832–843, 1983.

[Bei2001a] F. Beier. Objekt-relationale Realisierung einer temporalen Datenbankspra-che. Diplomarbeit, Institut fur Informatik, Universitat Hannover, Hanno-ver, 2001.

[BJW2000a] C. Bettini, S. Jajodia, S. X. Wang. Time Granularities in Databases, DataMining, and Temporal Reasoning. Springer-Verlag, Berlin, 2000.

[CPAN] Comprehensive Perl Archive Network, 2004. URL http://www.cpan.

org/.

[Dat2000a] C. Date. An Introduction to Database Systems, Seventh Edition. Addison-Wesley, Reading, MA, 7 Auflage, 2000.

[DD2003] C. Date, H. Darwen. An Overview and Analysis of TSQL2, 2003. URLhttp://www.thethirdmanifesto.com/.

[DDL2003a] C. Date, H. Darwen, N. A. Lorentzos. Temporal Data and the RelationalModel. Morgan Kaufmann, San Francisco, 2003.

[DB2000a] A. Descartes, T. Bunce. Programming the Perl DBI. Database Program-ming with Perl. O’Reilly & Associates, Sabastopol, CA, 2000.

[EJS98a] O. Etzion, S. Jajodia, S. Sripada (Herausgeber). Temporal Databases:Research and Practice. LNCS 1399. Springer-Verlag, Berlin, 1998.

[Fag79] R. Fagin. Normal forms and relational database operators. In Proceedingsof the 1979 ACM SIGMOD International Conference on Management ofData, Seiten 153–160, 1979.

[GL95c] M. Gertz, U. W. Lipeck. “Temporal” Integrity Constraints in TemporalDatabases. In J. Clifford, A. Tuzhilin (Herausgeber), Recent Advancesin Temporal Databases – Proceedings of the International Workshop onTemporal Databases, Sept. 1995, Workshops in Computing, Seiten 77–92.Springer-Verlag, Berlin, 1995.

80

Literaturverzeichnis

[Kle2003b] C. Kleiner. Modeling Spatial, Temporal and Spatio-Temporal Data inObject-Relational Database Systems. Doktorarbeit, Hannover, 2003.

[KPS2003b] M. Koubarakis, B. Pernici, H. Schek, M. Scholl, B. Theodoulidis, N. Try-fona, T. Sellis, A. Frank. Spatio-Temporal Databases – The CHORO-CHRONOS Approach. Springer Verlag, Berlin, 2003.

[Kuh97a] B. I. Kuhn. Entwicklung einer Anfragesprache fur temporale Datenban-ken: Semantik, Ausdrucksfahigkeit und graphische Benutzerschnittstelle.Diplomarbeit, Hannover, 1997.

[Loc2001a] U. Lockmann. Erweiterung eines objektrelationalen Datenbankmanage-mentsystems um verallgemeinerte Suchbaume als Indexstrukturen. Diplom-arbeit, Institut fur Informatik, Universitat Hannover, Hannover, 2001.

[OraAD] Oracle Database Application Developer’s Guide – Fundamentals, 2004.

[OraDCD] Oracle Data Cartridge Developer’s Guide, 2004.

[OraDD] Oracle Database Catalog Views and Data Dictionary, 2004.

[OraDoc] Oracle Database 10g Release 1 (10.1) Documentation Library, 2004. URLhttp://otn.oracle.com/pls/db10g/db10g.homepage.

[OraDW] Oracle Database Data Warehousing Guide, 2004.

[OraPLSQL] Oracle PL/SQL User’s Guide and Reference, 2004.

[OraSQL] Oracle Database SQL Reference, 2004.

[OTN] Oracle Technology Network, 2004. URL http://otn.oracle.com/.

[PerlDoc] Online Perl Documentation, 2004. URL http://www.perldoc.com/

perl5.8.4/pod/perl.html.

[Rei99a] C. Reinhard. Realisierung einer temporalen Erweiterung von SQL aufeinem objekt-relationalen Datenbankmanagementsystem. Diplomarbeit,Hannover, 1999.

[Sch2003c] O. Schweer. Erweiterung eines objektrelationalen Datenbankmanagement-systems um raumliche Verbunde. Diplomarbeit, Institut fur Informations-systeme, Universitat Hannover, Hannover, 2003.

[Sno95a] R. T. Snodgrass (Herausgeber). The TSQL2 Temporal Query Langua-ge. The Kluwer Int. Series in Engineering and Computer Science. KluwerAcademic Publishers, Boston, 1995.

81

Literaturverzeichnis

[TCG93a] A. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev, R. Snodgrass (Her-ausgeber). Temporal Databases: Theory, Design, and Implementation. Da-tabase Systems and Applications Series. Benjamin/Cummings, RedwoodCity, CA, 1993.

[WCS96a] L. Wall, T. Christiansen, R. L. Schwartz. Programming Perl (2nd Edition).O’Reilly & Associates, Cambridge, 2 Auflage, 1996.

[Wel95] H. Wells. The Time Machine, 1895.

[Wir77] N. Wirth. What can we do about the unnecessary diversity of notationfor syntactic definitions? Communications of the ACM, 20(11):822–823,1977.

[Wir96a] N. Wirth. Grundlagen und Techniken des Compilerbaus. Addison-Wesley(Deutschland), Bonn, 1996.

[ZCF97a] C. Zaniolo, S. Ceri, C. Faloutsos, R. Snodgrass, V. Subrahmanian, R. Zi-cari. Advanced Database Systems. The Morgan Kaufmann Series in DataManagement. Morgan Kaufmann Publishers, San Francisco, 1997.

82

Erklarung

Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehori-ge Implementierung selbstandig verfasst und dabei nur die angegebenenQuellen und Hilfsmittel verwendet habe.

Hannover, 27. Juli 2004

Christian Stahlhut

83


Recommended