of 83/83
Semantik und Realisierung einer erweiterten Relationenalgebra f ¨ ur temporale Datenbanken Diplomarbeit im Studiengang Mathematik mit Studienrichtung Informatik vorgelegt von Christian Stahlhut Matrikelnummer: 1937473 Universit¨ at Hannover Institut f¨ ur Informationssysteme Fachgebiet Datenbanksysteme Pr¨ ufer: Prof. U. Lipeck Zweitpr¨ ufer: Prof. R. Parchmann Hannover, den 27. Juli 2004

Semantik und Realisierung einer erweiterten ... · wisse Pragmatik bez¨uglich der erweiterten Relationenalgebra aufzubauen. Ein weiterer Schritt zur Realisierung der erweiterten

  • View
    216

  • Download
    0

Embed Size (px)

Text of Semantik und Realisierung einer erweiterten ... · wisse Pragmatik bez¨uglich der erweiterten...

  • Semantik und Realisierung einererweiterten Relationenalgebra für

    temporale Datenbanken

    Diplomarbeitim Studiengang Mathematik mit Studienrichtung Informatik

    vorgelegt von

    Christian StahlhutMatrikelnummer: 1937473

    Universität Hannover

    Institut für Informationssysteme

    Fachgebiet Datenbanksysteme

    Prüfer: Prof. U. Lipeck

    Zweitprüfer: Prof. R. Parchmann

    Hannover, den 27. Juli 2004

  • Zusammenfassung

    In dieser Arbeit wird ein Konzept zur relationalen Modellierung von zeitabhängigen(”temporalen“) Daten beschrieben. Zunächst wird der zugrundeliegende Zeitbegriff nä-

    her erläutert. Dann kann die klassische Relationenalgebra um einen Zeitbezug erweitertwerden. Anhand dieser Erweiterung wird diskutiert wie temporale Datenbanken zu mo-dellieren sind und welche zusätzlichen Integritätsbedingungen es zu beachten gilt.

    Durch Anfragebeispiele für konkrete temporale Datenbanken wird versucht eine ge-wisse Pragmatik bezüglich 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 Granularität . . . . . . . . . . . . . . . . . . 72.2. Modellierung des Zeitstempels . . . . . . . . . . . . . . . . . . . . . . . . 72.3. Gültigkeitszeit, 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. Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 für pack . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4. Verbesserungen für unpack . . . . . . . . . . . . . . . . . . . . . . . . . . 576.5. Verbesserungen für split . . . . . . . . . . . . . . . . . . . . . . . . . . 57

    7. Realisierung 617.1. Erweiterung des DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.2. Übersetzung 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

    Veränderungen unter dem Einfluß der Zeit sind ein alltägliches Phänomen. ZeitlicheVeränderung zu beschreiben erfordert gewisse Begriffe. Sollen solche Beschreibungen ineinem Datenbankmanagementsystem (DBMS) realisiert werden, sind also zunächst ent-sprechende Begriffe zu schaffen. Moderne kommerzielle DBMS unterstützen jedoch denUmgang mit zeitabhängigen (temporalen) Daten bisher kaum. Allerdings ist heute dieSpeicherung großer (historischer) Datenmengen ökonomisch 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 Funktionalität zu erweitern ist also naheliegend.

    Ziel dieser Arbeit soll es demnach sein, durch eine erweiterte Relationenalgebra zu-nächst die Begriffe zu schaffen, die in einem relationalen DBMS (RDBMS) für den Um-gang mit temporalen Daten benötigt werden. Ausgehend von dieser Algebra ist exem-plarisch eine temporale Erweiterung für 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 führten je-doch dazu, dass bis heute (2004) keine solche SQL-Erweiterung verabschiedet1 ist.

    Einige der Kritiker von TSQL2 veröffentlichten 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.

    Zusätzlich werden bereits am Institut entstandenen Arbeiten (sowie deren Quellen) be-achtet: In [Rei99a] und [Bei2001a] wird versucht, eine temporale Erweiterung für SQL92im Sinne von TSQL2 zu schaffen. Eine graphische Anfragesprache für 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

    http://iso.org

  • 1. Einleitung

    Gliederung dieser Arbeit

    Der Literatur folgend werden Daten mit einem zeitlichen Bezug versehen, indem ihnenein Gültigkeitszeitraum 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 zunächst die Grundlagen für den Umgang mit solchen Intervallen imrelationalen Datenmodell zu schaffen. Davon ausgehend wird die klassische Relationen-algebra um Intervallfunktionalität erweitert (Kapitel 3).

    In Kapitel 4 wird dargelegt, wie Integritätsanforderungen einer temporalen Datenbankdurch die erweiterte Relationenalgebra zu formulieren sind. Außerdem ist zu klären wiedie Relationen einer temporalen Datenbank modelliert werden können.

    Um die Ausdrucksfähigkeit 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 ermöglichen.

    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 Möglichkeiten gege-ben, die durch das hier beschriebene Konzept erschlossen werden.

    6

  • Eins-zwei-drei! Im Sauseschritt läuft die Zeit, wir laufen mit.

    (Wilhelm Busch)

    2. Semantik temporaler Daten

    Die Bedeutung von Daten in einem zeitlichen Kontext hängt vom verwendeten Zeitbe-griff ab. Deshalb werden im folgenden zunächst die Begriffe

    ”Zeitpunkt“ und

    ”Zeitraum“

    erläutert, damit eine Semantik für zeitveränderliche Daten angegeben werden kann. Ab-schließend wird Bezug auf in der Literatur häufig verwendete Zeitbegriffe genommen.

    2.1. Zeitstempel, Chronons und Granularität

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

    ”Zeitstempel aufgeprägt“ – 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 Länge eines Zeitpunkts2 wird als Granularität bezeichnet.

    Bemerkungen:

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

    • Es können verschiedene (gleichberechtigte) Arten von Zeitpunkten mit unterschied-lichen Granularitäten existieren (etwa verschieden lange Vorlesungszeiten im Winter-und Sommersemester).

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

    ”gegenwärtig“ festgelegt sein.

    2.2. Modellierung des Zeitstempels

    2.2.1. Natürliche Zahlen als Zeitpunkte

    Da die Granularität frei bestimmbar (interpretierbar) ist, sollte es ausreichen ein diskre-tes3 Zeitmodell zu verfolgen. Damit genügt als Grundmenge von Zeitpunkten die Menge

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

    Zeiteinheiten eines Chronons im diskreten Fall

    7

  • 2. Semantik temporaler Daten

    der natürlichen Zahlen.

    Beispiel: Ist (genau) eine Stunde als Granularität gewählt, 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 häufig Tupel betrachtet werden, deren Attributwerte in einer gewissenZeitspanne konstant bleiben, erscheint es sinnvoll ein (geschlossenes) Intervall als Daten-struktur für Zeitstempel zu nutzen: Ist die Aussage eines Tupels zu einem bestimmtenZeitpunkt gleich der Aussage eines anderen Tupels zum Zeitpunkt danach (oder davor),so können 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] wäre 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 Gründen 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 größere Ausdrucksfähigkeit 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. Gültigkeitszeit, Transaktionszeit undbenutzerdefinierte Zeit

    In der Literatur zu temporalen Datenbanken sind häufig die Begriffe Gültigkeitszeit(valid time), Transaktionszeit (transaction time) und benutzerdefinierte Zeit (user-defined time) zu lesen.

    ”Gültigkeitszeit“ bezieht sich auf Aussagen mit Gültigkeitszeitraum.

    3Eine Menge ist diskret, wenn sie umkehrbar-eindeutig auf die natürlichen 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 für

    Transaktionszeit sind vom Datenbanknutzer unabhängig und werden allein vom DBMSverwaltet. Im Sinne eines Logs, also der Protokollierung von Transaktionen, sind Aussa-gen über die Vergangenheit hier nicht veränderbar4.

    Transaktionszeit läßt sich natürlich über (eine zusätzliche) Gültigkeitszeit nachbilden.Ein DBMS, das Gültigkeitszeit und Transaktionszeit enthält wird bitemporal genannt.Als

    ”benutzerdefinierte Zeit“ werden Zeitangaben ohne Zeitstempelbezug bezeichnet.

    Der oben erläuterte Zeitstempel entspricht also eher der Gültigkeitszeit. Im hier vor-gestellten Konzept müssen die genannten Zeitbegriffe jedoch nicht weiter unterschiedenwerden.

    4Ansätze für 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 können, wird in 3.1 zunächst erläu-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 eingeführt. Zusätzlich werden Operatoren für den Umgang mitIntervallen definiert. Bezüglich temporaler Daten werden also die für den Umgang mitZeiträumen benutzbaren Begriffe bereitgestellt.

    Die dann in 3.3 neu eingeführten Operatoren dienen dazu, eine”atomare“,

    ”zeitpunkt-

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

    ”zusammengefasst“ und

    ”redundanzfrei“ betrachten zu können

    (pack). Damit läßt sich die zugrundeliegende Relationenalgebra um Funktionalität fürZeitstempel (bzw. Intervalle) erweitern (3.4).

    3.1. Relationen

    Die hier aufgeführten 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 beschränkt, sondern kann eine Menge von Werten zurückliefern.Dies wird das grundlegende Konzept für 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) für alle a ∈ def(S)}

    eine Menge von Abbildungen, die allen Attributnamen eines Schemas einen Wertaus dem zugehörigen 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 möglichen Tupel zu einem Schema S.

    • Häufig 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 enthält 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 häufig in Form einer Tabelle dargestellt, z.B:

    Name AlterMüller 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 (Müller, 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 eingeschränkt:

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

    S ′ = SX |A = S ′ : A −→ im(SX) mit S ′(a) = SX(a) für alle a ∈ AI ′ = {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) = MI ′ = {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))

    Für 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 ausgewählt, die der Selektionsfunktion genügen:

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

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

    Verbund (Join)

    Durch den Verbund von X und Y werden alle Tupel verknüpft, die gleiche Werte fürgleichnamige 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 ′) mitS ′ = 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 ′) mitS ′ = 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).Für 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 für ganz X bestimmt.

    • Diese Definition der Gruppierung unterscheidet sich in (nur) einem Punkt vonder Herkömmlichen: Eine Aggregationsfunktion liefert anstelle von Werten (auseiner Menge M) eine Menge von Werten (aus P(M)) zurück. 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 abkürzende Schreibweisen möglich:

    • count für α(G) := {|G|}

    • min(a) für α(G) := {mint∈G t(a)}

    • sum(a) für α(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 über ’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 für 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

    Für 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) mitt′(Produkt) ∈ {Rennrad} ∧ t′(Summe) ∈ {300 + 250} für Rennräder undt′(Produkt) ∈ {Mountainbike} ∧ t′(Summe) ∈ {270} für 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. Zusätzlich werden Operatoren zum Umgang mit diesenIntervallen eingeführt.

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

    3.2.1. Definition

    Für 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 OperatorenFür 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 über 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 e1b2 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 eb2 e2

    • I1 ends I2 :⇔ e1 = e2 ∧ b1 ≥ b2 b1 1 eb2 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 I2Zusätzlich läßt sich der Spezialfall n ∈ I1 für 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 benötigt. 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 übergebenen 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 für die dies möglich 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 Hülle T ∗(X) bezüg-lich merges gegeben:

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

    Vereinigt (union) man nun alle Intervalle in jeder Hülle 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)

    Erläuterung:

    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 größtmöglich gewählt; es soll gelten [b1, e1] ⊆ X und [b2, e2] ⊆ X.

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

    4: Für alle Elemente in X muss es ein Intervall in X geben, welches dieses Elemententhält.

    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 läßt sich die in 3.1 definierte Relatio-nenalgebra um Funktionalität für Zeitstempel (bzw. Intervalle) erweitern. Hierzu werdenexpand und collapse als Aggregationsfunktionen aufgefasst, damit sie auf intervallwer-tige Attribute einer Relation wirken können. 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 möglichst”zusammengefasst“ und

    ”redun-

    danzfrei“ betrachten zu können (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 für ein (einziges) Attribut

    Mit diesen neuen Aggregationsfunktionen lassen sich nun pack und unpack für 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 VTMüller [2, 2]Müller [4, 6]

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

    Dann ergibt sich für 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 ∈ {Müller, Schmidt} = πName(X) mitt′(Name) ∈ {Müller} ∧ t′(VT) ∈ {[2, 2], [4, 6]} für Müller undt′(Name) ∈ {Schmidt} ∧ t′(VT) ∈ {[5, 9]} für Schmidt }

    und damit die Ergebnisrelation

    packVT(X) =

    Name VTMüller [2, 2]Müller [4, 6]

    Schmidt [5, 9]

    Für unpackVT(X) ergibt sich analog das Ergebnis

    unpackVT(X) =

    Name VTMüller [2, 2]Müller [4, 4]Müller [5, 5]Müller [6, 6]

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

    3.3.3. pack und unpack für 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: Für X =S# P#[1, 2] [3, 4][5, 6] [7, 8]

    ist

    3keine Menge, denn für 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:

    • Für unpack spielt die Reihenfolge der Attribute in L keine Rolle, für pack dagegenschon.

    • Im allgemeinen gilt nicht

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

    Mit X wie oben im Beispiel für 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 anfängliche unpackL(X) ist für 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 möglich die Operatoren der Relationenalgebra neuzu definieren. Sei L eine Liste von Attributnamen. L kann auch leer sein (Schreibweise:einfach weglassen); in diesem Fall erfüllen (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 ))

    Natürlich müssen auch die gleichen Voraussetzungen gelten wie für die”original“ Diffe-

    renz, d.h. auch hier müssen 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 für Operatoren, die auf eine einzigen Relation wirken, z.B.:

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

    L(X)))

    analog für σLϕ , εLb=β und Γ

    LA#b1=α1,...,bq=αq

    (Für Umbennennungen ρb=a erscheint eine Erweiterung nicht sinnvoll, weil nur das Sche-ma einer Relation verändert wird und nicht ihr Inhalt.)

    Bemerkung: Möglicherweise wird nur das anfängliche unpack oder das abschließendepack ausgeführt, nicht aber beides: Durch Projektion, Umbenennung oder Gruppierungkann das in L aufgeführte Attribut entfallen (kein pack) oder erst entstehen (kein un-pack).

    23

  • 4. Modellierung temporalerDatenbanken

    Für die Formulierung von Integritätsbedingungen einer temporalen Datenbank sind Be-griffe notwendig, die sich auf Zeitstempel beziehen. In Abschnitt 4.1 wird erläutert, wiesolche Bedingungen mit der erweiterten Relationenalgebra beschrieben werden können.

    Abhängig davon, welcher Aussage einer temporalen Datenbank ein Gültigkeitszeit-raum zugeordnet sein soll, sind die Relationen entsprechend zu modellieren. Wie dabeivorzugehen ist wird in 4.2 diskutiert.

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

    4.1. Integritätsbedingungen

    Die Modellierung zeitabhängiger Daten in einem DBMS stellt zusätzliche 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 Schlüsselkandidaten1 der Relation möglicherweise nicht mehr zur eindeuti-gen Identifizierung ausreichend: Mehrere verschiedene Tupel in der temporal erweitertenRelation würden nach dem nicht-temporalen Primärschlüssel2 als ein einziges Tupelidentifiziert werden, wenn sich die Werte von nicht zum Primärschlüssel gehörendenAttributen im Laufe der Zeit verändern.

    In [Kuh97a] und [Bei2001a] wird dies durch die Einführung eines zeitlich invariantenSchlüsselsurrogats gelöst. So wird etwa eine Abteilung nicht wie in der nicht-temporalenVersion der Datenbank durch ihren Namen, sondern durch eine Nummer identifiziert,die sich niemals ändert. Der Name einer Abteilung kann sich somit im Laufe der Zeitändern.

    Eine weitere Möglichkeit ist, die Schlüsselkandidaten jeweils um den Zeitstempel zuerweitern. Das hat (im Sinne des obigen Beispiels) den Vorteil, dass kein weiteres künst-liches

    ”Nummer“-Attribut eingefügt werden muss und den Nachteil, dass eine Abteilung

    keine Namensänderung durchführen darf. Allerdings sollte auch die Semantik beachtet

    1die minimalen Mengen von Attributen, die ein Tupel stets eindeutig identifizieren2der (aus inhaltlichen Gründen) tatsächlich zur Identifikation gewählte Schlüsselkandidat

    24

  • 4.1. Integritätsbedingungen

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

    ’Forschung und Entwicklung’ umbenannt wird?“3

    Formalisierung

    Für eine Relation R ohne Zeitstempel sei A die Menge der Attributnamen von R undK ⊆ A der Primärschlüssel. Dann kann bei einer Erweiterung von R zu R̃ um einenZeitstempel VT die eindeutige Identifikation erhalten werden, indem VT zum Primär-schlüssel hinzugenommen wird: K̃ := K ∪ {V T}. Die vorherige Integritätsbedingung

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

    wird für die neue Relation R̃ und ihren Primärschlüssel K̃ übernommen:

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

    Wenn also bisher für die Einhaltung der eindeutigen Identifikation gesorgt werden konn-te, sollte dies nach Erweiterung um einen Zeitstempel weiterhin möglich sein.

    Bemerkung: Manchmal werden nicht alle Attribute von K̃ benötigt: Eine Teilmengevon K̃ (etwa nur der Zeitstempel) könnte zur Identifikation von Tupeln aus R̃ genügen.Welcher Schlüsselkandidat

    ”der richtige“ ist, hängt stets von der gewünschten Semantik

    einer temporalen Datenbank ab.

    4.1.2. Widerspruchsfreiheit

    Für gewöhnlich wird davon ausgegangen, dass sich widersprechende Aussagen nicht zurgleichen Zeit gültig sind. Die Zeitstempel inhaltlich verschiedener4 Tupel einer Relationdürfen sich also (im Sinne von overlaps) nicht überlappen.

    Da verschiedene Intervalle auch als verschiedene Werte für Zeitstempel gelten – selbstwenn sie sich überlappen – wird diese Integritätsbedingung nicht durch die oben be-schriebene Eindeutigkeitsbedingung erfüllt. Es reicht jedoch aus, die Einhaltung derEindeutigkeitsbedingung aus 4.1.1 für eine Relation R auch für 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) können sich aber nicht überlappen.

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

    25

  • 4.1. Integritätsbedingungen

    Ausnahmen

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

    Prozent während91 [10, 15]83 [16, 20]72 [17, 17]87 [10, 20]56 [1, 24]

    . . .

    Diese Relation könnte beispielsweise die prozentuale Auslastung eines Servers beschrei-ben: Während 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 Fremdschlüssel

    Eine Fremdschlüsselbeziehung von R bzgl. S ist gegeben, falls R den Primärschlüsselvon S (= Fremdschlüssel von R) enthält und zu jedem Tupel von R ein Tupel aus S mitden gleichen Werten in all diesen Schlüsselattributen existiert (

    ”R referenziert S“).

    Analog zu 4.1.2 gilt: Wenn der Fremdschlüssel den Zeitstempel enthält, wird diese In-tegritätsbedingung nicht durch die Eindeutigkeitsbedingung erfüllt. Es reicht jedoch ausdie Fremdschlüsselbeziehung für unpackZeitstempel(R) bzgl. unpackZeistempel(S) zu fordern(siehe Bemerkung zu 4.2.2 für ein Beispiel).

    4.1.4. Redundanzfreiheit

    Redundanz tritt in temporalen Datenbanken auf, wenn sich die Zeitstempel inhaltlichgleicher5 Tupel überlappen: Die zu den Zeitpunkten in der Schnittmenge gehörendenAussagen werden durch mehrere Tupel ausgedrückt. Ausserdem sind verschiedene Aus-sagen redundant, wenn sie sich durch eine einzige ausdrücken 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 enthält 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. Integritätsbedingungen

    Beispiel

    R enthält 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. Integritätsbedingungen

    Präsident JahreFord [1974, 1976]

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

    . . .

    Für diese Relation, als Liste von amerikanischen Präsidenten und den dazugehörigenAmtszeiten, mag es sinnvoll sein sie nicht

    ”gepackt zu halten“, um anzudeuten wieviele

    Legislaturperioden jeder Präsident im Amt war.

    4.1.5. Stetigkeit

    Weitere weniger elementare Integritätsbedingungen sind selbstverständlich denkbar undmit der erweiterten Relationenalgebra formulierbar.

    Eine nicht explizit in [DDL2003a] behandelte Integritätsbedingung ist etwa die For-derung nach der Stetigkeit temporaler Daten, d.h. der modellierte zeitlichen Ablauf darfkeine Lücken aufweisen.

    Formalisierung

    Sei K der Primärschlüssel von R. Dann sei K̃ := K − {Zeitstempel} die Menge derPrimärschlüsselattribute ohne Zeitstempel.

    R ist stetig falls K̃ ein Schlüsselkandidat für πZeitstempelK (R) ist. Ist der Zeitstempel daseinzige Primärschlüsselattribut, muss πZeitstempelK (R) aus genau einem Tupel bestehen.

    Beispiel

    Sei {Name, VT)} der Primärschlüssel von R.

    Mit R :=

    Name Gehalt VTAlbers 6000 [1, 60]Müller 3000 [10, 20]

    Schmidt 3000 [21, 30]Schmidt 4000 [31, 50]Müller 4000 [51, 60]Müller 5000 [61, 70]

    ist πVTName, VT(R) =

    Name VTAlbers [1, 60]Müller [10, 20]

    Schmidt [21, 50]Müller [51, 70]

    .

    Da ’Müller’ in πVTName, VT(R) zweimal auftaucht, ist der Name hier kein Schlüsselkandidatund damit R nicht stetig. Allerdings wäre R stetig, wenn ’Schmidt’ in ’Müller’ (oderumgekehrt) umbenannt würde.

    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 führt zu der Frage, wie solche Relationen zu modellieren sind.Denn wird der Wert eines Attributs häufig verändert, die Werte der anderen Attributeaber kaum, so entstehen viele Tupel, die sich inhaltlich nur in einem einzigen Attributunterscheiden.

    Eine Lösung wäre, für einzelne Gruppen von Attributen deren Werte gemeinsam ver-ändert werden, eigene Zeitstempel einzuführen – Zeitstempel auf Attributen (AttributeTimestamping) im Gegensatz zu Zeitstempeln auf Tupeln (Tupel Timestamping).Die Einführung weiterer Zeitstempel in dieselbe Relation würde aber selbstverständlichdas Problem nur verschlimmern. Es ist also notwendig die Ausgangsrelation in mehrereRelationen aufzuteilen: In [DDL2003a] wird vorgeschlagen für jedes Attribut eine eigeneRelation zu modellieren. Ändern sich Attribute stets synchron, wäre es jedoch unnö-tig wenn diese Attribute jeweils eigene Relationen erhielten. Jede Gruppe von synchronveränderlichen Attributen kann also in je einer einzigen Relation modelliert werden.

    Damit diese Relationen wieder ohne Informationsverlust zur Ausgangsrelation zusam-mengefügt werden können, müssen sie jeweils den Primärschlüssel (also nach 4.1.1 aucheinen Zeitstempel) enthalten. Die Rekonstruktion kann dann über den erweiterten Ver-bund (onZeitstempel) geschehen.

    Für die beschriebene Zerlegung gelten die Vor- und Nachteile einer Normalisierung:Anfragen bezüglich des Zeitstempels eines bestimmten Attributs können anhand derweniger umfangreichen Teilrelation beantwortet werden. Aufgrund der zusätzlich benö-tigten Verbunde verringert sich jedoch die Ausführungsgeschwindigkeit von Anfragen,die sich nun auf mehrere Relationen beziehen müssen.

    Es mag allgemein für die zugrundeliegende Semantik vorteilhaft sein, die durch dieursprüngliche Relation modellierten Aussagen in mehrere kürzere, prägnantere aufzu-teilen. Die Modellierung bestimmter Aussagen kann durch die Zerlegung erst möglichwerden (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– für eine temporale Datenbank also das Zeitstempelattribut: L = Zeitstempel.

    • R erfüllt die Join-Abhängigkeit ∗(A1, . . . , An) sofern stets gilt:

    R = πLA1(R) onL · · · onL πLAn(R)

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

    • Eine Join-Abhängigkeit heißt trivial, falls ein Ai die gesamte Attributemenge vonR ist, also Ai = A für ein 1 ≤ i ≤ n gilt.

    29

  • 4.2. Tupel- oder Attributzeitstempel

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

    R = πLA1(R) on · · · on πLAn(R)

    Enthält jedes Ai (1 ≤ i ≤ n) alle Attribute aus L, so kann R im allgemei-nen nur genau dann über den klassischen Join-Operator wieder verlustlos ausden Projektionen zusammengesetzt werden, wenn jedes πLAi(R) die Werte allerL-Attribute unverändert läßt, also stets πLAi(R) = πAi(R) gilt. Im temporalen

    Kontext (L = Zeitstempel) bedeutet dies eine synchrone Änderung 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-Abhängigkeit erfüllt. (Der Begriff

    ”6NF“ bezieht sich auf die

    gebräuchliche Projection/Join-Normalform, welche mit 5NF abgekürzt wird (sieheBemerkung). Für einen tieferen Einblick in die Normalisierungstheorie siehe z.B.[Fag79] oder [Dat2000a].)

    Um nun Zeitstempel für Attribute zu modellieren, ist es hinreichend die 6NF für jedeRelation der temporalen Datenbank zu fordern. Für jede Relation, die nicht in 6NF ist,kann die durch eine nicht-triviale Join-Abhängigkeit vorgegebene vertikale Dekomposi-tion durchgeführt werden, bis alle Relationen diese Forderung erfüllen.

    Allerdings erscheint es unnötig eine Relation R entsprechend zu zerlegen, falls sichAttribute stets synchron verändern. Dies ist der Fall, wenn R eine kollektive Join-Abhängigkeit erfüllt.

    Bemerkung: Jede Relation in 6NF ist auch in Projection/Join-Normalform (5NF).Diese ist über die klassische Join-Abhängigkeit (also mit π und on statt πL und onL)definiert. Für 5NF wird gefordert, dass jede nicht-triviale Join-Abhängigkeit erfüllt, aufeinen Schlüsselkandidaten von R zurückgeht.

    4.2.2. Beispiel

    R :=

    Nr Name Gehalt ChefNr VT2 Albers 6000 2 [1, 60]10 Müller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Müller 4000 2 [51, 60]10 Müller 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 Primärschlüssel hier aus den Attributen ’Nr’ und ’VT’.R erfüllt die nicht-triviale Join-Abhängigkeit

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

    Damit ist R nicht in 6NF (jedoch in 5NF). Für die Projektion

    πVTNr, Name, VT(R) =

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

    existieren keine nicht-trivialen Join-Abhängigkeiten – sie ist in 6NF. Hingegen erfüllt 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-Abhängigkeit

    ∗({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) verändert werden, ist diese Join-Abhängigkeit jedoch kollektiv.Die Zerlegung von R in die obigen beiden Projektionen ermöglicht dann eine Modellie-rung von Zeitstempeln für die Attribute VT sowie Gehalt synchron mit ChefNr.

    Ansonsten kann R anhand dieser (nicht kollektiven) Join-Abhängigkeit aufgeteilt wer-den:

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

    Join-Abhängigkeiten für jede semantisch mögliche Ausprägung von R gelten und nichtnur für diese konkreten Werten.

    Bemerkungen:

    • Durch die Zerlegung können getrennte Aussagen über Name und Gehalt/ChefNrgetroffen werden – etwa könnte der Namen eines Angestellten für einem bestimm-ten Zeitpunkt bekannt sein, das Gehalt (und der Chef) jedoch nicht.

    Ist das nicht erwünscht, wäre eine zeitliche Fremdschlüsselbeziehung notwendig:Zu jedem Tupel aus unpack(πVTNr, Name, VT(R)) muss ein Tupel ausunpack(πVTNr, Gehalt, ChefNr, VT(R)) mit gleichen Werten für 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 natürlich ändern.

    • Eine weitere nicht-triviale Join-Abhängigkeit die R offensichtlich erfüllt ist:

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

    Ob es zweckmäßig ist durch die zusätzliche 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 für beliebige Zeiträume in Zukunft, Gegenwart oderVergangenheit gelten.

    Ist das Ende der Gültigkeit einer Aussage nicht abzusehen, wird ein künstlicher”bis-

    auf-weiteres“-Wert benötigt. Ebenso müsste ein”∞“-Wert für

    ”ewig“ geltende Aussagen

    existieren, oder zumindest durch den spätesten darstellbaren Zeitpunkt angenähert wer-den können. Diese Konstrukte können jedoch zu logischen und semantischen Komplika-tionen führen (vgl. [DDL2003a] Kapitel 10.5).

    Eine weitere Möglichkeit mit unbekannten Gültigkeitszeiträumen umzugehen, ist die-se gar nicht erst zu modellieren: Aussagen können in

    ”historische“ (für die der Gül-

    tigkeitszeitraum bekannt ist) und”aktuelle“ (für die noch nicht feststeht wann ihre

    Gültigkeit endet) aufgeteilt werden. Für historische Aussagen wird wie bisher die (”voll-

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

    temporalen“) Relationen für aktuelle Aussagen enthalten dagegen kein ganzes Intervallals Zeitstempel, sondern nur den Zeitpunkt des Beginns der Gültigkeit. Steht das Endeder Gültigkeit einer aktuellen Aussage fest, wird das entsprechende Tupel mit dem nunbekannten Gültigkeitszeitraum in die historischen Relationen übernommen und aus denRelationen für aktuelle Daten entfernt.

    Diese Modellierung hat den Vorteil auf die Einführung der oben genannten speziellenWerte verzichten zu könnnen. Der Nachteil liegt in der zusätzlichen Anzahl von Rela-tionen die durch die Partitionierung nach der Zeit (also durch die zeitliche horizontaleDekomposition) entstehen. Anfragen, für die keine Unterscheidung nach

    ”aktuell“ und

    ”historisch“ erwünscht ist, sind dann meist umständlicher zu formulieren.

    Anmerkungen:

    • Es ist natürlich möglich zukünftige Aussagen bei denen der Gültigkeitszeitraum

    ”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 Gültigkeit einer Aussage häufigunbekannt ist. Die umgekehrte Richtung (etwa wenn in einer archäologischen Da-tenbank der Beginn unbekannt ist) läß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 Müller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Müller 4000 2 [51, bis-auf-weiteres]

    und mit horizontaler Dekomposition:

    Raktuell :=Nr Name Gehalt ChefNr VT2 Albers 6000 2 110 Müller 4000 2 51

    RHistorie :=

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

    Die nächste Veränderung findet zum Zeitpunkt 61 statt: ’Albers’ scheidet aus und ’Mül-ler’ bekommt ein höheres Gehalt und einen neuen Chef. Die entprechenden Tupel werdenin die Historie übernommen.

    R :=

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

    mit horizontaler Dekomposition:

    6

    ”Wenn es im Jahre 1879 schon Computer gegeben hätte, würden diese vorausgesagt haben, dass manInfolge der Zunahme von Pferdewagen im Jahre 1979 im Pferdemist ersticken würde.“ (John C.Edwards)

    33

  • 4.3. Zukunft, Gegenwart und Vergangenheit

    Raktuell :=Nr Name Gehalt ChefNr VT10 Müller 5000 1 61

    RHistorie :=

    Nr Name Gehalt ChefNr VT2 Albers 6000 2 [1, 60]10 Müller 3000 7 [10, 20]10 Schmidt 3000 7 [21, 30]10 Schmidt 4000 2 [31, 50]10 Müller 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 nötig, es genügtschlicht:

    πName(Raktuell)

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

    wobei zusätzlich 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,”Gefühl“) im Um-

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

    Dadurch wird eine Erprobung der Ausdrucksfähigkeit der Algebra ermöglicht. Außer-dem wird ein Vorrat an Beispielen zur Veranschaulichung der Modellierung und zumbesseren Verständnis 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 können, wird im folgenden zuerst die entsprechendeTSQL2-Anfrage angegeben. Hierbei sind einige syntaktische Besonderheiten zu beachten:

    temporale Aufwärtskompatibilität: Dieses Konzept führt dazu, dass Anfragen ohne spe-zielle Kennzeichnung durch das validtime-Schlüsselwort nur auf dem aktuellenDatenbestand (von

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

    Attribut mit dem Zeitstempel zurück, sofern sie nicht als nonsequenced gekenn-zeichnet ist1.

    sequenced: Die Operatoren einer mit sequenced gekennzeichneten Anfrage wirken nurauf Tupel, die im gleichen Zeitraum gültig sind. Mit nonsequenced gibt es keineEinschränkungen. 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 Müller 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 für 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) Schlüsselsurrogat ’RWO’ eingeführt.

    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 ausgewählt, deren Zeitstempel die aktuelle Zeit enthalten.

    Wie lautet der Beschäftigungszeitraum 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

    größtmöglichem Intervall erweiterten Gültigkeitszeitraum des Attributs“ zurück.

    πVTName, VT(ang)

    Um den Beschäftigungszeitraum zu erhalten, werden nur der Name (und der zugehörigeZeitstempel) eines Angestellten projiziert. Das in πVT... eingebettete pack sorgt danndafür, dass der größtmögliche (zusammenhängende) Zeitraum ausgegeben wird.

    In welchen Zeiträumen 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 für 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 größer 5250 werden ausgewählt und dannder größtmögliche Zeitraum für jeden Namen ausgegeben.

    2sonst ist überall wo nach einem Angestellten gefragt ist, zusätzlich 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 zunächst ein unpack auf das Zeitstem-pelattribut von X und Y durchgeführt. Die so entstandenen Einheitsintervallen der be-trachtete Zeitraum von Angestellten (X) und Chefs (Y) werden dann durch onVT aufGleichheit geprüft: X.VT = Y.VT.

    Welche Angestellten haben jemals eine Gehaltserhöhung 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 Gehaltserhöhung bekommen, so müssen zwei Tupel in ’ang’existieren, die seine Gehaltsdaten vor (X) und nach (Y) der Erhöhung repräsentieren.Solche Tupelpaare werden ausgewählt und der zugehörige 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 zunächst 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 läßt sich für 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 Zeiträumen konnte ein Zulieferer keine Teile liefern?

    S−during πS#, during(SP )

    Welche Zulieferer konnten wann welche Teile liefern?

    Für die geforderte Übersicht erscheint es sinnvoll nicht nur die Zeiträume, sondern auchdie Teile als Intervall auszugeben. Hierzu wird zunächst ein Einheitsintervall für jedesTeil gebildet. Die größtmöglichen Intervalle werden dann ausgegeben.

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

    In welchen Zeiträumen war mindestens ein Zulieferer unter Vertrag?

    πduringduring(S)

    Durch die Verwendung der erweiterten Projektion erhält man die größtmöglichen Zeiträu-me.

    In welchen Zeiträumen war kein Zulieferer unter Vertrag?

    Sei C eine Relation mit dem intervallwertigen Attribut ’during’, welche das Tupel [0, max]enthält, 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, wäre eine kompliziertere Formulierung nötig: Es müsste festgestellt werden, obfür ein Tupel aus X (bzw. Y ) eine Veränderung des Status bezüglich des vorherigenZeitpunkts vorliegt.

    5.3. Beispiele zu Gruppierung und Aggregation

    Die bisher betrachteten Quellen bieten wenig Beispiele für gruppierende oder aggre-gierende Anfragen. Um die Auswirkung von den in die erweiterte Relationenalgebraeingebetteten Operatoren pack und unpack auf solche Anfragen beurteilen zu können,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 höchste Preis pro Produkt?

    ΓProdukt # Produkt, Höchstpreis = max(Preis)(R)

    Eine Formulierung mit dem erweiterten Operator ΓZeit... führt zum gleichen Ergebnis, denndas Maximum ist von der Anzahl der Tupel einer Gruppierung unabhängig: unpackZeit(R)enthält zwar mehr Tupel als R, jedoch bleibt der Wertebereich von ’Preis’ gleich.

    Was ist der Höchstpreis pro Produkt und wann wird er angenommen?

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

    R on (ρ Höchstpreis = Preis(X))

    Eine Formulierung mit onZeit würde bewirken, dass überlappende Zeitbereiche mehrererMaxima zusammengefasst werden.

    Wieviele verschiedene Produktpreise pro Hersteller gibt es?

    Diese Anfrage soll etwa für den Hersteller ’Shnel’ das Ergebnis ’2’ liefern: Er hat Renn-räder 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))

    Zunächst wird die Beziehung von Hersteller und Preis über den Fremdschlüssel (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 Preiseingeschränkt.

    Wie hoch ist der Durchschnittspreis pro Produkt?

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

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

    liefert etwa 270+2402

    = 255 als Durchschnittspreis für 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 für Mountainbikes, wobei der Preis ’270’ mit20 Zeiteinheiten ins Gewicht fällt 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 für den Zeitraum [1, 7] denDurchschnittspreis 300+270

    2= 285 liefern.

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

    Damit für jeden einzelnen Zeitpunkt der Durchschnittspreis bestimmt wird, muss hierΓZeit... benutzt werden. Eine Formulierung mit dem klassischen Gruppierungsoperator Γ...ergäbe π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 läßt sich Sum ein Attribut ’Jahr’ erweitern, welches das zum Zeitstempel gehörige Jahr angibt:

    X := εZeitJahr=d begin(Zeit)

    12e+1999

    (S)

    Bemerkung: Die Benutzung des erweiterten Operators εZeit... ist notwendig, damit einZeitstempel eindeutig einem Jahr zugeordnet werden kann. Im

    ”gepackten“ Zustand ist

    dies hier nicht immer möglich (etwa bei [1, 20]).

    Wieder sind zwei Formulierungen denkbar:

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

    Für Mountainbikes ergibt die mit ΓZeit... formulierte Anfrage270∗12

    12= 270 für das Jahr 2000

    und 270∗8+240∗48+4

    = 260 für 2001; entsprechend liefert die Anfrage mit dem klassischem

    Γ-Operator 2701

    = 270 für 2000 und 270+2402

    = 255 für 2001.

    Wann ist der frühste Zeitpunkt des Beginns der Produktion pro Hersteller proProdukt?

    Der gesuchte Zeitpunkt wäre z.B. ’8’ für 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 frühste Zeitpunkt einesZeitraums ermittelt.

    42

  • 5.3. Beispiele zu Gruppierung und Aggregation

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

    Rennräder 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 Länge eines Zeitraums.

    43

  • 6. Optimierung

    Die erweiterte Relationenalgebra basiert auf pack und unpack (siehe 3.4). Für eine Reali-sierung der erweiterten Relationenalgebra erscheint es deshalb sinnvoll, diese Operatorenmöglichst optimal zu implementieren.

    Insbesondere unpack erscheint hier kritisch, denn unter Umständen enthält eine Rela-tion im

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

    möglich sollte also die Materialisierung von”ungepackten“ Relationen vermieden werden.

    Für 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) isthäufig unnötig: meist genügt es zu fordern, dass die betreffenden Intervalle nicht überlap-pen. Eine Zerlegung von X in maximale, nicht überlappende Intervalle hat den Vorteil,dass für gewöhnlich weniger Tupel produziert werden als durch unpack(X). In den mei-sten Fällen kann unpack durch einen Operator split ersetzt werden, der solch eineZerlegung in Teilintervalle leistet:splitlPX (X) zerlegt die Tupel einer Ausgangsrelation X für 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 für 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 für splitlPX (X):

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

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

    Füge 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 Hintereinanderausführung für alleAttribute in L = l1, . . . , ln definiert:

    splitLPX (X) := splitlnPX

    (splitln−1PX

    (. . . splitl1PX (X) . . . ))

    Maximale nicht-überlappende Intervalle

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

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

    erfüllt sein, kann die Menge PX folgendermaßen gewählt 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 für die splitlPX

    (X) obigeBedingung erfüllt1. Folglich ist die Zerlegung der Tupel von X anhand von PX so grobwie möglich, die Intervalle haben also größtmögliche Länge und sind damit in diesemSinn maximal.

    Eine Zerlegung in maximale nicht-überlappende Intervalle ist auch mit einer einfacherzu konstruierenden Punktmenge möglich – siehe 6.5.1.

    Beispiel:

    Mit X :=

    Name VTMüller [2, 15]Müller [60, 68]

    Schmidt [3, 12]

    ist PX = {3, 13}

    und damit splitVTPX (X) =

    Name VTMüller [2, 2]Müller [3, 12]Müller [13, 15]Müller [60, 68]

    Schmidt [3, 12]

    .

    1Annahme: Es genügt eine Menge QX mit |QX | < |PX |. Für 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

    Für fast alle Operatoren der erweiterten Relationenalgebra ist eine Implementierungmöglich, die keine Materialisierung der Ausgangsrelationen im

    ”unpacked“-Zustand be-

    nötigt. In manchen Fällen kann sogar eine äquivalente Formulierung ohne anfänglichesunpack angegeben werden. Das abschließende pack ist ebenfalls nicht immer nötig: 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 für die Projektion die konkreten Werte eines Tupels unwichtig sind, spielt es keineRolle ob die Ausgangsrelation

    ”ungepackt“ vorliegt oder nicht:

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

    L(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=β(unpack

    L(X)) )

    einer Relation X um ein Attribut b wie sie in 3.1.2 beschrieben ist, sind in Abhängigkeitvon β zwei Fälle zu unterscheiden: Gilt β = β|L, wird also für die Berechnung von bkein Gebrauch von den intervallwertigen Attributen aus L gemacht, dann ist unpackL

    unnötig:εLb=β(X) = pack

    L( εb=β(X) )

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

    packt“ ist.Andernfalls läßt sich εLb=β(X) in einem einzigen Durchlauf über X erzeugen. In diesem

    Fall müssen entsprechend auch nur intervallwertige Attribute betrachtet werden, die βwirklich benötigt: Ist l ∈ L = {l1, . . . , ln} so kann dieses l entfallen, falls β = β|def(S)−{l}gilt.

    46

  • 6.2. Vermeidung von unpack und pack

    Algorithmus:

    Für alle x ∈ X:Für alle pi ∈ x(li) (1 ≤ i ≤ n):

    Berechne für 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 füge t dem Ergebnis hinzu.

    Wende packL für die eben erzeugten Tupel an.

    Durch das”auf Tupelebene“ (Pipelining – siehe 6.3.1) für jedes x ∈ X durchgeführte

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

    ”gepackt“ vor, so kann dadurch kein

    ”gepacktes“ Ergebnis garan-

    tiert werden und es wird zusätzlich ein abschließendes packL(X) benötigt.Ist mehr über β (und X) bekannt, ist es manchmal möglich εL durch ε zu ersetzen:

    Die im Beispiel 5.3.2 verwendete Erweiterung um das Attribut ’Jahr’ könnte mit denregulären Operator ausgedrückt werden, wenn kein Zeitstempel mehr als ein Jahr enthält.

    6.2.3. Selektion

    Anhand der Selektionsformel ϕ einer Selektion

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

    L(X)) )

    können analog zur Erweiterung zwei Fälle unterschieden werden: Gilt ϕ = ϕ|L, ist dieSelektion also von den intervallwertigen Attributen aus L unabhängig, dann ist unpackL

    unnötig:σLϕ(X) := pack

    L( σϕ(X) )

    Wieder entfällt packL falls X bereits entsprechend”gepackt“ ist.

    Andernfalls läßt sich auch σLϕ(X) in einem einzigen Durchlauf über X ohne die Mate-rialisierung von unpackL(X) erzeugen:

    Für alle x ∈ X:Für alle pi ∈ x(li) (1 ≤ i ≤ n):

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

    Wende packL für die eben erzeugten Tupel an.

    Wie bei εLb=β(X) sind nur die intervallwertigen Attribute wichtig, die wirklich von ϕbenötigt werden: Ist l ∈ L so kann dieses l entfallen, falls ϕ = ϕ|def(S)−{l} gilt. Ebensowird zusätzlich ein abschließendes packL(X) benötigt, sollte X nicht bereits

    ”gepackt“

    vorliegen.Angenommen ϕ läßt sich in einen von Attributen in L unabhängigen Teil ϕ1 und einen

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

    ”Für alle pi ∈ x(li)“) geprüft werden, ob ein Tupel x

    selektiert wird, also ϕ1(x) = wahr gilt. Ist dies der Fall, so ist es möglich den Test fürϕ2(x) zu übergehen, das Tupel in das Ergebnis zu übernehmen und mit dem nächstenTupel fortzufahren. (Analog wäre auch eine konjuktive Zerlegung ϕ = ϕ1 ∧ϕ2 möglich.)

    47

  • 6.2. Vermeidung von unpack und pack

    6.2.4. Verbund

    Für den erweiterte Verbund

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

    genügt die Zerlegung in maximale nicht-überlappende Intervalle:

    X onL Y = packL( splitLPX∪Y (X) on splitLPX∪Y

    (Y ) )

    Die für split benötigte Punktmenge PX∪Y ergibt sich hier aus den Intervallgrenzen derbeiden Relationen X und Y.

    Beispiel:

    Sei X :=

    Name VTMeier [6, 13]Müller [10, 15]Müller [18, 20]

    Schmidt [21, 55]Müller [56, 70]

    und Y :=

    Name VTMüller [10, 20]Müller [33, 44]

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

    .

    Dann können 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]Müller [10, 13]Müller [14, 15]Müller [18, 20]

    Schmidt [21, 21]Schmidt [22, 32]Schmidt [33, 44]Schmidt [45, 50]Schmidt [51, 55]Müller [56, 70]

    , splitVTPX∪Y (Y ) =

    Name VTMüller [10, 13]Müller [14, 15]Müller [16, 17]Müller [18, 20]Müller [33, 44]

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

    splitLPX∪Y (X) on splitLPX∪Y

    (Y ) ergibt

    Name VTMüller [10, 13]Müller [14, 15]Müller [18, 20]

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

    48

  • 6.2. Vermeidung von unpack und pack

    Für den Spezialfall, dass keine gleichnamigen, intervallwertigen Attribute von X und Yin L enthalten sind, ist onL... schlicht unnötig:

    X onL Y = packL(X on Y )

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

    Alternativ läß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 zunächst der klassische Verbund für alle anderen gleichnamigen Attribute gebildetwerden. Hierzu ist l etwa in xl (für X) bzw. yl (für Y ) umzubenennen2:

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

    Mittels overlaps wird nun festgestellt ob Verbundpartner für das Attribut l vorliegen,wobei intersect den zu l gehörigen Wert liefert:

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

    Zuletzt werden die jetzt überflüssigen Attribute xl und yl von S entfernt und die Ergeb-nisrelation

    ”gepackt“:

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

    Für mehrere gleichnamige, intervallwertige Attribut aus L kann analog vorgegangenwerden: Jedes Attribut ist wie oben zunächst exklusiv für X und Y umzubenennen.Ebenso muss für jedes Intervallattribut die overlaps-Bedingung gelten und das zuge-hörige Intervall mit intersect berechnet werden. Abschließend ist für 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 ∩ YVTMüller [10, 15] [10, 20] [10, 15]Müller [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 enthält und X und Y bereits

    ”gepackt“ sind.

    • Für den natürlichen 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

    Für die Vereinigung zweier Relationen gilt folgendes Distributivgesetz:

    unpackL(X) ∪ unpackL(Y ) = unpackL(X ∪ Y )Damit kann das anfängliche 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 ausgedrückt 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]Müller [56, 70]

    Differenz für genau ein Attribut

    Enthält L genau ein Attribut l, dann läßt sich X −l Y berechnen ohne auf split zu-rückgreifen zu müssen. Ähnlich dem in 6.2.4 beschriebenen Verfahren läßt sich zunächstein 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 hierfür ein

    Wert für”undefiniert“ eingeführt werden müsste (siehe folgendes Beispiel). (In Oracle ist

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

    Zur Differenzbildung genügt es Tupel aus R zu betrachten für die XVT overlapsYVT gilt oder für 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] undefiniertMüller [10, 15] [10, 20]Müller [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 zugehörigen Attributen (aus L) ausgegeben.

    Algorithmus für minus: Der folgende Algorithmus für die Aggregationsfunktion