Entwicklung einer Anfragesprache für temporale Datenbanken

Entwicklung einer
Anfragesprache für
temporale Datenbanken:
Semantik, Ausdrucksfähigkeit und
graphische Benutzerschnittstelle
Diplomarbeit von
Barbara Ingrid Kuhn
im Rahmen des Studiengangs
Mathematik mit Nebenfach Informatik
an der Universität Hannover
Prüfer:
Prof. Dr. Udo Lipeck
Hannover, den 19. November 1997
Zusammenfassung
Die Notwendigkeit, in temporalen Datenbanksystemen temporale Daten berücksichtigen
zu müssen, ﬁndet zunehmend Beachtung. Insbesondere die Speicherung von Gültigkeitszeiträumen von Datenbankeinträgen ermöglicht eine eﬀektivere Nutzung z.B. von Daten aus Geschäftsprozessen. Anfragen vergangene, aktuelle und zukünftige Datenbankzustände betreﬀend könnten gestellt werden. Solche Anfragen bedürfen eines geeigneten
Werkzeugs: einer mächtigen temporalen Anfragesprache, die aber leicht zu erlernen ist.
Basierend auf dem TEER–Modell, einer temporalen Erweiterung des EER–Modells, wird
in dieser Arbeit eine graphische temporale Datenbank–Anfragesprache vorgestellt. Anfragen werden mit Hilfe eines graphischen TEER–Anfrage–Editors auf der Basis des der
Datenbank zugrundeliegenden TEER–Schemas gestellt. Dadurch muß der Anwender nur
das in der Regel leicht verständliche konzeptionelle Schema der Datenbank kennen, um
Anfragen stellen zu können.
Formal deﬁniert wird die TEER–Anfragesprache durch Festlegung einer Syntax und einer
Semantik unter Verwendung des hier vorgestellten TEER–Kalküls. Desweiteren werden
eine exemplarische Implementierung der Anfragesprache vorgeschlagen und ein TEER–
Anfrage–Editor zur Demonstration der Sprache implementiert. Auf Einschränkungen der
Sprache bzw. der sie deﬁnierenden Syntax/Semantik sowie auf Verbesserungsmöglichkeiten wird hingewiesen.
4
Inhaltsverzeichnis
1 Einleitung
9
1.1 Gegenstand der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Grundlagen
13
2.1 Das EER–Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1
EER–Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2
EER–Diagramm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Ein Beispiel–Datenbank–Schema . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Die Datentyp–Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1
Formale Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2
EER–Standarddatentyp–Signatur . . . . . . . . . . . . . . . . . . . 21
2.4 Die EER–Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.2
Semantik
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Der EER–Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.2
Semantik
2.5.3
Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6 Relationenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.1
Formale Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.2
Transformation des EER–Modells in das Relationenmodell . . . . . 39
3 Ein graphisches temporales Datenmodell
43
3.1 Das TEER–Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Ein temporales Beispiel–Datenbank–Schema . . . . . . . . . . . . . . . . . 47
3.3 TEER–Standarddatentyp–Signatur . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Lineare Syntax der TEER–Standarddatentyp–Signatur . . . . . . . . . . . 56
3.5 Transformation des TEER–Modells in das Relationenmodell . . . . . . . . 57
5
INHALTSVERZEICHNIS
4 Die TEER–Anfragesprache
69
4.1 Eine graphische temporale Anfragesprache . . . . . . . . . . . . . . . . . . 69
4.1.1
Konstrukte der TEER–Anfragesprache . . . . . . . . . . . . . . . . 69
4.1.2
Anfrageeditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.3
TEER–Datenbank–Anfragesprache . . . . . . . . . . . . . . . . . . 73
4.2 Der TEER–Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.1
Die umgangssprachlichen temporalen Prädikate . . . . . . . . . . . 87
4.2.2
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2.3
Semantik
4.2.4
Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3 Transformation in den TEER–Kalkül . . . . . . . . . . . . . . . . . . . . . 97
4.3.1
Voraussetzungen und Einschränkungen . . . . . . . . . . . . . . . . 98
4.3.2
Die Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.3.3
Die Transformation von restrict expr und restrict attr . . . . 102
4.3.4
Die Transformation von temp sel expr . . . . . . . . . . . . . . . . 103
4.3.5
Die Transformation von temp proj expr . . . . . . . . . . . . . . . 104
4.3.6
Die Transformationsregeln . . . . . . . . . . . . . . . . . . . . . . . 105
4.3.7
Beispieltransformationen . . . . . . . . . . . . . . . . . . . . . . . . 111
5 Exemplarische Implementierung in SQL
125
5.1 Voraussetzungen in ORACLE . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.2 Übersetzung der Beispielanfragen . . . . . . . . . . . . . . . . . . . . . . . 128
5.2.1
Übersetzung des Get–Operators . . . . . . . . . . . . . . . . . . . . 128
5.2.2
Übersetzung des Restrict–Operators . . . . . . . . . . . . . . . . . . 131
5.2.3
Übersetzung des Query–result–link–Operators . . . . . . . . . . . . 133
5.2.4
Übersetzung des temporalen Projektionsoperators . . . . . . . . . . 136
5.2.5
Übersetzung des True–time–Operators . . . . . . . . . . . . . . . . 139
5.2.6
Übersetzung des temporalen Selektionsoperators . . . . . . . . . . . 144
5.2.7
Übersetzung des Time–link–Operators . . . . . . . . . . . . . . . . 148
6 Kritik und Ausblick
151
A Implementierung der Testdatenbank
155
A.1 Die Tabelle Firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A.2 Die Tabelle Angestellter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
A.3 Die Tabelle Abteilung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6
INHALTSVERZEICHNIS
A.4 Die Tabelle Produkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
A.5 Die Tabelle Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.6 Die Tabelle Zulieferﬁrma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.7 Die Tabelle Vorprodukt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.8 Die Tabelle gehoert zu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A.9 Die Tabelle produziert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.10 Die Tabelle liefert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
B Syntax der TEER–Datenbank–Anfragesprache
165
C Transformation in den TEER–Kalkül
167
D Benutzerhandbuch
175
D.1 Modularisierung und Installation . . . . . . . . . . . . . . . . . . . . . . . 175
D.2 Erstellung des TEER–Modells . . . . . . . . . . . . . . . . . . . . . . . . . 178
D.3 Handbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
D.3.1 Das Hauptfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
D.3.2 Laden eines Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . 182
D.3.3 Die Editoroperatoren Remove und Duplicate . . . . . . . . . . . . . 183
D.3.4 Der Get–Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
D.3.5 Der Restrict–Operator . . . . . . . . . . . . . . . . . . . . . . . . . 189
D.3.6 Der Query–result–link–Operator . . . . . . . . . . . . . . . . . . . . 190
D.3.7 Der temporale Selektionsoperator . . . . . . . . . . . . . . . . . . . 192
D.3.8 Der temporale Projektionsoperator . . . . . . . . . . . . . . . . . . 193
D.3.9 Der Time–link–Operator . . . . . . . . . . . . . . . . . . . . . . . . 196
D.3.10 Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Literaturverzeichnis
197
Abbildungsverzeichnis
201
Index
202
7
INHALTSVERZEICHNIS
8
Kapitel 1
Einleitung
1.1
Gegenstand der Arbeit
Zeit ist ein wesentlicher Faktor, was das Festhalten von Informationen über sich stetig
entwickelnde Sachverhalte betriﬀt. Fakten oder Daten müssen im Kontext Zeit“ inter”
pretiert werden. Beziehungen zwischen Objekten oder Ereignissen sind ebenfalls zeitlichen
Rahmenbedingungen unterworfen. Zeit ist ein allumfassender Wert, der aber in konventionellen Datenbankmanagementsystemen (DBMS) kaum Beachtung ﬁndet. Diese Systeme
erlauben zwar vom Anwender eingegebene Zeitdaten bestehend aus Datum und Uhrzeit
abzuspeichern, aber eine automatische Speicherung des temporalen Kontexts von Daten
existiert nicht. Damit Daten aber ein korrektes Bild der realen Welt wiedergeben, ist die
Abspeicherung zeitlicher Informationen unablässig.
In konventionellen Datenbanken wird nur der momentane Zustand von Daten festgehalten. Werden Einträge verändert, ersetzt der neue Wert den alten. In einer temporalen
Datenbank dagegen führt eine Datenveränderung im allgemeinen zu einer Einfügung neuer Daten, so daß alte Werte nicht gelöscht werden. Dieses ermöglicht die Formulierung von
Anfragen an den aktuellen Datenbankzustand, aber auch an vergangene und zukünftige
Zustände. In temporalen Datenbanken werden somit verschiedene Zustände festgehalten.
Weitere Anforderungen an eine temporale Datenbank sind die Möglichkeit, den Zustand
zu einem bestimmten Zeitpunkt zu bestimmen, und die Möglichkeit, zwischen verschiedenen Zeitpunkten in Anfragen zu unterscheiden.
Es gibt zwei Arten von zeitlichen Veränderungen, die in einem DBMS von Interesse sind.
Zum einem ist dieses der Zeitpunkt einer Transaktion, oder auf eine Menge von Intervallen
bezogen, der Existenzzeitraum von Daten. Dieser Existenzzeitraum heißt Transaction–
Time. Mit Hilfe dieser Zeitform kann im nachhinein festgestellt werden, wann welche
Daten wie verändert worden sind und seit wann sie in der Datenbank existieren. Beispiele
für DBMS, die die Transaction–Time zur Verfügung stellen, sind Postgres und sein kommerzieller Nachfolger Illustra. Bei diesen DBMS wird diese Vorhaltung der Transaction–
Time mit Time Travel“ bezeichnet. Die zweite Zeitart beschreibt den Zeitraum, in dem
”
Daten gültig sind. Diese Gültigkeitszeit von Daten heißt Valid–Time. Diese zusätzlichen
temporalen Informationen ermöglichen die Formulierung von Anfragen, die historische,
gegenwärtige oder zukünftige Zustände betreﬀen. Eine weiterführende Behandlung der
Valid– und der Transaction–Time ﬁndet sich in [Ku94].
9
Kapitel 1. Einleitung
Graphische Benutzeroberﬂächen für Computerprogramme ermöglichen die Nutzung dieser Programme einer großen Gruppe von Anwendern. Die Anforderungen an den Benutzer
sind i.a. minimal. Sie beschränken sich auf den Umgang mit der Maus, mit der bestimmte
Aktionen auslösbar sind, sowie der Reaktion auf diese Aktionen, was häuﬁg der Eingabe
von Daten über eine Tastatur entspricht. Mit Hilfe einer graphischen Oberﬂäche kann ein
Anwender durch ein Programm geführt werden, wobei durch eine abstrahierende Darstellung von komplexen Befehlsstrukturen Fehler des Anwenders weitestgehend unterbunden
werden. Durch einen einzigen Mausklick sind in graphisch gesteuerten Programmen Befehle aktivierbar, für deren Ausführung der Anwender sonst eine lange Liste von Kommandos
eingeben muß. Auf Grund graphischer Oberﬂächen ist der Anwender nicht mehr gezwungen, ständig neue Befehle zu erlernen und sich bewußt an strenge syntaktische Regeln zu
halten.
Einen Ansatz zur Verbindung graphischer Benutzeroberﬂächen mit Datenbanken bietet das Entity–Relationship–Modell (ER–Modell). Dieses Modell wurde 1976 von Peter
Chen [Che76] zur visuellen Darstellung eines Datenbankaufbaus eingeführt. Es zeigt leicht
verständlich, welche Arten von Daten in der Datenbank gespeichert werden sollen und
wie die Daten zueinander in Beziehung stehen. Es hat sich seit seiner Einführung zu
einem unverzichtbaren Werkzeug insbesondere beim konzeptionellen Datenbankentwurf
entwickelt, da das ER–Modell die Darstellung von Datenbankschemata mit einfachen
Mitteln ermöglicht. Dabei bleibt das Datenmodell unabhängig vom logischen Modell des
DBMS sowie frei von physischen Betrachtungen und Zwängen, die erst in einem späteren
Entwurfsschritt, dem physischen Datenbank–Entwurf, Einﬂuß in den Datenbankentwurf
ﬁnden. Das ER–Modell wurde im Laufe der Jahre von verschiedenen Autoren zu einem
erweiterten ER–Modell (EER–Modell) entwickelt. Das EER–Modell ermöglicht durch die
Kombination verschiedener EER–Modellelemente die graphische Darstellung auch von
komplexen Datenstrukturen. Außerdem sind zusätzlich Informationen über die Beziehungen der Elemente untereinander darstellbar. Auf diesem EER–Modell setzt das temporale EER–Modell (TEER–Modell) von Ramez Elmasri et. al. [EWK93] auf, das auch die
Abbildung der Zeit berücksichtigt. Dabei besteht kein graphischer Unterschied zwischen
dem EER– und dem TEER–Schema sondern ein interpretatorischer. Alle Objekte und
Beziehungen, die in einem TEER–Schema dargestellt sind, stehen in einem temporalen
Kontext. Zu Daten eines jeden Objekts und einer jeden Beziehung wird zusätzlich der
Zeitraum festgehalten, in dem diese Daten Gültigkeit haben. Das TEER–Schema von
[EWK93] bezieht nur die Valid–Time ein.
Nicht temporal abhängige Daten sind zeitinvariant. Dieses bedeutet, daß die Daten über
die gesamte Lebensdauer einer Datenbank gültig sind und nicht verändert werden können.
Zu dem Konzept temporal und nicht temporal abhängiger Objekte in einer gemeinsamen
temporalen Datenbank gibt es in der Literatur eine Reihe von Vorschlägen ([EEK90],
[EK92]). Es ist aber in dem hier vorgestellten TEER–Modell, auf dem eine Anfragesprache deﬁniert wird, nicht vorgesehen. Auf eine Erweiterung wird verzichtet, da sonst eine
graphische Unterscheidung temporal abhängiger und unabhängiger Objekte eingeführt
werden müßte, was das Datenmodell unnötigt kompliziert. Zur Darstellung zeitinvarianter
Objekte ist es einfacher, die Lebensdauer des Objekts auf die Lebensdauer der Datenbank
zu setzen.
Im Rahmen dieser Arbeit wird eine graphische temporale Datenbank–Anfragesprache entwickelt, die auf einem Vorschlag von Vram Kouramajian und Michael Gertz [KG95] ba10
1.2. Aufbau der Arbeit
siert. Die graphische Grundlage dieser Sprache bildet das TEER–Modell. Die Sprache,
genannt TEER–Anfragesprache, stellt Operatoren zur Auswahl von Daten sowohl auf
Grund temporaler als auch nichttemporaler Bedingungen zur Verfügung. Diese Operatoren ermöglichen Anfragen wie
Wann war Herr Müller Leiter der Abteilung Montage ?“
”
Welche Angestellten haben in der Abteilung von Herrn Müller gearbeitet als dieser Ab”
teilungsleiter war ? “
Auf diesen Operatoren basierend wurde ein Editor in Tcl/Tk implementiert, der die Darstellung eines TEER–Schemas sowie die Formulierung von Anfragen graphisch realisiert.
Von einem TEER–Schema ausgehend kann der Anwender die gewünschte Anfrage graphisch zusammensetzen. Dabei wird er insofern geführt, als daß der Editor in jedem
Schritt nur syntaktisch folgerichtige Operatoren zur Verfügung stellt. Für die graphische
TEER–Anfragesprache wird eine lineare Syntax angegeben. Auf dieser basierend wird
anschließend die Semantik der Sprache deﬁniert wird. Dazu ist es nötig, daß die linearen
Syntaxkonstrukte in den TEER–Kalkül transformiert werden. Dieser Kalkül wird zuvor
aus dem EER–Kalkül hergeleitet.
Um die Funktionalität der Sprache zu zeigen, wird ein spezielles TEER–Schema nach
ORACLE, einem konventionellen, relationalen DBMS, transformiert und dazu eine Testdatenbank angelegt. An Hand von Beispielanfragen wird eine Übersetzungsmethode für
die graphischen Anfragen in SQL–Anfragen vorgeführt. Diese SQL–Anfragen wurden an
die Testdatenbank gestellt.
Eine allgemeine SQL–Implementierung sowie die Betrachtung der Ausdrucksfähigkeit der
TEER–Anfragesprache haben sich als zu aufwendig im Rahmen dieser Diplomarbeit erwiesen.
1.2
Aufbau der Arbeit
Der vorliegende Text gliedert sich wie folgt:
In Kapitel 2 sind sämtliche theoretischen Grundlagen aufgeführt, die zur Deﬁnition
des TEER–Modells, der neu entwickelten Anfragesprache sowie des temporalen Kalküls
benötigt werden. Hauptbestandteile sind dabei die formale und graphische Deﬁnition des
EER–Modells durch Angabe einer Syntax und einer Semantik, die graphische Darstellung
und die formale Deﬁnition des zugehörigen EER–Kalküls.
In Kapitel 3 wird das temporale graphische Datenmodell eingeführt. Dazu wird zunächst
das TEER–Modell vorgestellt und anschließend mit Hilfe einer Syntax und einer Semantik
formal deﬁniert. Im letzten Abschnitt wird die Transformation des TEER–Modells in das
Relationenmodell diskutiert und eine in späteren Kapiteln herangezogene Testdatenbank
angelegt.
Die auf dem TEER–Modell basierende TEER–Anfragesprache wird in Kapitel 4 vorgestellt. Es wird eine lineare Syntax eingeführt und eine sich daran orientierende Semantik
mit Hilfe des in diesem Zusammenhang deﬁnierten TEER–Kalküls angegeben. In Abschnitt 4.1.3 werden zum besseren Verständnis für bestimmte Anfragetypen Beispiele
gegeben. Auf diese Beispiele wird in späteren Teilen der Arbeit wieder zurückgegriﬀen.
11
Kapitel 1. Einleitung
In Kapitel 5 ist eine exemplarische Implementierung der TEER–Anfragesprache beschrieben. Dazu werden die Beispielanfragen aus Kapitel 4.1.3 in SQL–Anfragen übersetzt und
an die Testdatenbank gestellt.
Im letzten Kapitel des Hauptteils werden die Ergebnisse dieser Arbeit zusammengefaßt
sowie ein Ausblick auf mögliche Spracherweiterungen gegeben.
Im Anhang dieser Arbeit ﬁnden sich die SQL–Anweisungen zur Erzeugung der Testdatenbank (Anhang A), die alphabetisch sortierte lineare Syntax der TEER–Anfragesprache
(Anhang B) sowie die alphabetisch angeordneten Regeln für die Transformation dieser
Syntax in den TEER–Kalkül (Anhang C). Den Abschluß bildet Anhang D, ein Benutzerhandbuch für den Anfrageeditor.
12
Kapitel 2
Grundlagen
2.1
Das EER–Schema
Ein EER–Schema ist eine in einer Datenbeschreibungssprache abgefaßte Deﬁnition der
in einer Datenbank zugelassenen Datenstrukturen. Die zu einem EER–Schema gehörige
Sprache ist das EER–Modell. Es stellt Konzepte zur Darstellung dieser Datenstrukturen
zur Verfügung. Die graphische Darstellung eines EER–Modells ist das EER–Diagramm.
Das EER–Modell und das EER–Diagramm werden in den beiden folgenden Abschnitten
eingeführt.
2.1.1
EER–Modell
Das Entity–Relationship–Modell (ER–Modell) ist ein Werkzeug, das 1976 von Peter Chen
zur graphischen Darstellung von Datenbankschemata eingeführt wurde [Che76]. Ein Datenbankschema ist die formale Beschreibung aller in einer Datenbank enthaltenen Daten
und ihrer Beziehungen zueinander. Es stellt somit einen Ausschnitt der realen Welt, eine
sogenannte Mini–Welt, dar.
Die Modellierungskonzepte des ER–Modells sind Objekte, Beziehungen zwischen Objekten und Attribute. Attribute geben Eigenschaften von Objekten oder auch von Beziehungen an. In Anlehnung an den englischen Sprachgebrauch werden im folgenden Objekte als
Entities und Beziehungen als Relationships bezeichnet. Einzelne Entities, welche ähn”
lich“, vergleichbar“ oder zusammengehörig“ sind, werden zu einem Entitytyp zusam”
”
mengefaßt. Die Beziehungen zwischen verschiedenen Entitytypen werden durch Relationshiptypen beschrieben.
Das erweiterte Entity–Relationship–Modell (EER–Modell) stellt neben neuen Konzepten
auch neue Datentypen und Informationen über die Art der dargestellten Beziehungen zur
Verfügung. Das hier Verwendung ﬁndende EER–Modell bietet folgende neuen Konzepte
an: Die Konzepte Aggregation und Assoziation ermöglichen die Bildung komplex strukturierter Entitytypen, wogegen das Konzept der Generalisierung bzw. Spezialisierung das
Ausdrücken von Teilmengenbeziehungen zwischen Entitytypen ermöglicht.
13
Kapitel 2. Grundlagen
Entities und Entitytypen
Nach Chen ist ein Entity eindeutig identiﬁzierbar. Es entspricht einem Gegenstand, einer Person oder einem Begriﬀ der Mini–Welt, über die veränderliche Informationen zu
speichern sind. Um Entities in der Datenbank speichern zu können, werden sie in einem
ER–Modell zu Klassen gleicher Entities zusammengefaßt, den Entitytypen.
Ein Entitytyp ist eine Menge von Entities desselben Typs, d.h. die Entities besitzen
dieselben Attributtypen. Jeder Entitytyp Ei besitzt eine Menge von Attributtypen
Ai1 ,. . . ,Ain , und zu jedem Attributtyp Aij gehört ein Wertebereich domain(Aij ). Jedem
Entity ei eines Entitytyps Ei werden somit Attribute aij aus dem Bereich domain(Aij )
zugeordnet.
Dieser Wertebereich domain(Aij ) eines Attributtyps kann durch einen der fest vorgegebenen Standarddatentypen wie integer (ganze Zahlen Z) oder number (reelle Zahlen
R) festgelegt sein. Es besteht aber auch die Möglichkeit, anwendungsbezogene Nicht–
Standarddatentypen wie circle (Kreiskoordinaten) oder point (Punktkoordinaten) zu deﬁnieren. Der Wertebereich eines Attributtyps kann auch ein zusammengesetzter Datentyp
sein. Er ist dann mengen–, multimengen– oder listenwertig, d.h. er liefert eine Menge (set),
Multimenge (bag) oder Liste (list) von Werten.
Im EER–Modell kann der Wertebereich eines Attributtyps um einen Nullwert erweitert
werden. Dieses bedeutet, daß ein Attribut unbekannt sein darf. Solche Attributtypen heißen optional, die anderen obligatorisch. Der optionale Attributtyp Aij , der jedem Entity ei eines Entitytyps Ei einen Wert aus dem Bereich domain(Aij ) zuordnet, beschreibt
eine partielle Funktion.
Zur Identiﬁkation eines speziellen Entities ist es in der Regel nicht erforderlich, alle Attribute anzugeben. Ein Entity kann bereits durch ein Attribut oder durch eine Kombination mehrerer eindeutig festgelegt werden. Eine Menge von Attributtypen, die ausreicht, ein Entity eindeutig zu identiﬁzieren, heißt Schlüsselkandidat des Entitytyps.
Ein Schlüssel ist ein minimaler Schlüsselkandidat, in dem Sinne, daß es keine weitere
Untermenge von Attributtypen dieses Schlüsselkandidaten gibt, die ausreicht, die Entities des Entitytyps eindeutig zu identiﬁzieren. Die an einem Schlüssel partizipierenden
Attributtypen heißen Schlüsselattribute(typen).
Aggregationen
Eine Aggregation ist ein Konstruktor zur Bildung neuer Entitytypen durch Zusammenfassen von mehreren Objekten verschiedener Typen. Beispielsweise können n Entitytypen
E1 , . . . , En zu einem Entitytyp Eagg durch kartesische Produktbildung zusammengefaßt
werden, d.h. das Entity einer Aggregation ist ein Tupel von Entities der verwendeten
Entitytypen:
eagg = (e1 , . . . , en ),
eagg ∈ Eagg ,
ei ∈ Ei , i = 1, . . . , n
Im EER–Modell wird diese Typ–Neubildung durch objektwertige Attributtypen erzielt. Diese Attributtypen besitzen als Wertebereich einen Entitytyp anstelle eines Datentyps. Ein objektwertiger Attributtyp heißt Komponente. Da nur Entitytypen Komponenten besitzen dürfen, können mit Hilfe der Komponenten komplexe Entitytypen erzeugt
14
2.1. Das EER–Schema
werden. Dies ist möglich, weil Entities einer Komponente wiederum Entities als Bestandteile besitzen können.
Assoziationen
Die Assoziation, auch Gruppierung genannt, entspricht einer Potenzmengenbildung, d.h.
ein Objekt entsteht durch das Zusammenfassen mehrerer Objekte gleichen Typs. Ein
Entity einer Assoziation Eass über einem Entitytyp E besteht also aus einer Menge von
Entities des Typs E:
eass = {e1 , . . . , en },
eass ∈ Eass ,
ei ∈ E, i = 1, . . . , n
Eine Assoziation wird im EER–Modell durch einen komplex–objektwertigen Attributtyp
erzeugt. Ein komplex–objektwertiger Attributtyp ist eine mehrwertige, d.h. listen–,
mengen– oder multimengenwertige, Komponente.
Generalisierungen und Spezialisierungen
Eine Generalisierung bzw. Spezialisierung ist eine Klassiﬁkation von Entitytypen in neue
Typen. Eine Spezialisierung erlaubt, einen neuen Entitytyp Espez als Teilmenge eines anderen Entitytyps E zu deﬁnieren, dagegen faßt eine Generalisierung mehrere Entitytypen
E1 , . . . , En zu einem neuen Entitytyp Egen zusammen.
Spezialisierungen und Generalisierungen werden im EER–Modell durch das Konzept der
Typkonstruktion ausgedrückt. Eine Typkonstruktion T = T (E1 , . . . , En ; A1 , . . . , Am )
besitzt eine Menge von eingehenden Entitytypen E1 , . . . , En , n ≥ 1, und eine Menge daraus konstruierter Entitytypen A1 , . . . , Am , m ≥ 1, entsprechend Eingangs– und
Ausgangstypen genannt. Mit diesem Konzept können beliebige Teilmengenbeziehungen
zwischen Entitytypen explizit ausgedrückt werden. So sind neben Generalisierung und
Spezialisierung auch Partition und Kategorisierung formulierbar.
Relationships und Relationshiptypen
Die Beziehungen zwischen den Objekten in einer Mini–Welt werden durch Relationshiptypen ausgedrückt. Ein Relationshiptyp R mit der Stelligkeit m verbindet m Entitytypen
E1 , . . . , Em .
Relationshiptypen können eigene Attributtypen besitzen. Diese bringen spezielle Eigenschaften zum Ausdruck, die erst durch das Herstellen der Beziehung relevant werden. Für
die beteiligten Entitytypen sind diese Eigenschaften bedeutungslos. Damit ist jedes Relationship r eines m–stelligen Relationshiptyps R mit s Attributen ein m + s–Tupel
r =< e1 , . . . , em , a1 , . . . , as > mit ei ∈ Ei und aj ∈ Aj , i = 1, . . . , m, j = 1, . . . , s.
Jeder an einem Relationshiptyp teilnehmende Entitytyp E1 , . . . , Em erhält einen innerhalb des Relationshiptyps eindeutigen Rollennamen n1 , . . . , nm zugeordnet. Dieser Rollenname gibt an, welche Rolle der Entitytyp in der Beziehung einnimmt. Partizipiert ein
Entitytyp mehrfach an demselben Relationshiptyp, so dienen die Rollennamen der Unterscheidung der unterschiedlichen Rollen. Bei einer einfachen Teilnahme eines Entitytyps
15
Kapitel 2. Grundlagen
an einem Relationshiptyp ist die Vergabe eines Rollennamens optional. Der Name des
Entitytyps kann als Rollenname automatisch angenommen werden.
Zu jeder Beziehung zwischen einem Entitytyp Ei und einem Relationshiptyp R (mit
Rollennnamen ni ) kann eine Kardinalität der Form (min,max) mit min ∈ N0 und
max ∈ N ∪ {∗} angegeben werden. Diese Angabe verlangt, daß ein Entity ei vom Typ Ei
mindestens min–mal und höchstens max–mal an den Beziehungen des Typs R teilnehmen
darf; ∗“ bedeutet dabei unendlich. Die Standardangabe ist (0, ∗), d.h. jedes Entity ei
”
kann beliebig oft, insbesondere auch gar nicht, an R partizipieren. Der Spezialfall (1, ∗)
erzwingt, daß jedes Entity ei an der Beziehung R teilnehmen muß.
2.1.2
EER–Diagramm
Das EER–Diagramm dient der graphischen Veranschaulichung der in einem EER–Modell
enthaltenen Informationen.
Ein Entitytyp E wird durch ein Rechteck dargestellt.
E
Ein Relationshiptyp R wird durch eine Raute repräsentiert. Diese Raute wird durch
ungerichtete Kanten mit den beteiligten Entitytypen E1 , . . . , Em verbunden. Die Kanten
sind mit den zu jeder Beziehung gehörigen Rollennamen n1 , . . . , nm und den Kardinalitäten beschriftet, wobei diese Angaben optional sind.
E1
n1 (min1 , max1 )
R
(minm , maxm ) nm
Em
.....
Ein Attribut Aij zu einem Entitytyp E bzw. einem Relationshiptyp R mit einem Wertebereich vom Datentyp d wird durch eine Ellipse repräsentiert. Diese Ellipsen werden
durch ungerichtete Kanten mit dem zugehörigen Rechteck des Entitytyps bzw. der zugehörigen Raute des Relationshiptyps verbunden. Die Angabe des Datentyps ist optional,
da er sich oft aus dem Kontext erschließen läßt.
16
2.1. Das EER–Schema
Aij : [set/bag/list] d
E
Aij : [set/bag/list] d
R
Jeder Bestandteil eines Schlüssels zu einem Entitytyp E wird durch einen dicken Punkt
am Rechteck von E gekennzeichnet.
Aij : [set/bag/list] d
E
Die Kante eines optionalen Attributtyps enthält einen Kreis.
Aij : [set/bag/list] d
E
Eine Komponente C zum Entitytyp E1 mit dem Wertebereich E2 oder set/bag/list(E2 )
über einem Entitytyp E2 wird durch eine Ellipse dargestellt, das mit dem Rechteck des
Entitytyps E1 mit einer ungerichteten Kante verbunden ist. Anstelle von E2 steht ein
Quadrat, von dem aus ein Pfeil auf den Entitytyp E2 zeigt.
E2
C : [set/bag/list]
E1
Jede Typkonstruktion T mit den Eingangstypen E1 , . . . , En und den Ausgangstypen
A1 , . . . , Am wird als Dreieck dargestellt. Die Eingangstypen Ei sind durch Kanten mit der
Grundseite des Dreiecks verbunden, die Ausgangstypen Aj mit dem gegenüberliegenden
Eckpunkt.
17
Kapitel 2. Grundlagen
A1
E1
....
....
T
En
2.2
Am
Ein Beispiel–Datenbank–Schema
Zur Veranschaulichung der einzelnen Konzepte des EER–Modells wird das EER–Schema
eines Konzerns verwendet.
Die Abbildung 2.1 zeigt die Modellierung Konzern” als EER–Diagramm, in dem der
”
Konzern (KONZERN), verschiedene Arten von Firmen (FIRMA, ZULIEFERFIRMA,
KUNDE), Produkte (PRODUKT, VORPRODUKT), Aufträge (AUFTRAG), Abteilungen (ABTEILUNG) und Angestellte (ANGESTELLTER) sowie zugehörige Adressen
(ADRESSE) jeweils als Entitytyp modelliert sind. Zwischen den Entities dieser Typen
bestehen die folgenden Relationships:
• Ein Kunde vergibt Aufträge.
• Jede Abteilung gehört zu genau einer Firma.
• Eine Abteilung produziert mehrere Produkte.
• Ein Auftrag besteht aus mehreren Produkten.
• Zulieferﬁrmen liefern Vorprodukte.
In dem EER–Diagramm sind neben den üblichen Attributtypen, die Eigenschaften wie den
Namen (AngName) einer Person oder die Chargennummer (ChargenNr) eines Produkts
beschreiben, eine Reihe von objektwertigen und komplex–objektwertigen Attributtypen
vertreten. Diese sind in Form einer Komponente realisiert. So besitzt zum Beispiel jede
Abteilung einen Abteilungsleiter (AbtLeiter) und mehrere Mitarbeiter, die jeweils Angestellte sind.
Das Konzept der Typkonstruktion erlaubt Spezialisierungen und Generalisierungen von
Entitytypen. So sind Zulieferﬁrmen und Kunden zu Firmen generalisiert, und jedes Vorprodukt ist ein Produkt.
Jeder Entitytyp, der nicht Ausgangstyp einer Typkonstruktion ist, besitzt einen eindeutigen Schlüssel. Einige Rollennamen sind explizit vergeben worden. Sie sind bei der späteren
theoretischen Beschreibung dieses EER–Schemas hilfreich.
18
2.2. Ein Beispiel–Datenbank–Schema
Name
Tochterfirmen: set
KONZERN
Adresse:
Strasse
FIRMA
Firmenname
.
HausNr
ADRESSE
Anschrift:
.
Plz
Ort
⊇
⊇
TelNr
Fax
ZULIEFERFIRMA
KUNDE
(1,*)
(1,*)
vergibt
(1,*) k auftr
liefert
Auftrag:
AUFTRAG
.
Datum
AuftrNr
(1,*)
AngAnschrift:
AngName
PersNr
a inhalt
VORPRODUKT
Gehalt
⊇
(1,1)
.
PRODUKT
ChargenNr
Preis
Menge
p auftr
p abt
(1,1)
ProdName
besteht
aus
produziert
(1,*)
AbtLeiter:
abt p
ABTEILUNG
(1,*)
.
Mitarbeiter: set
AbtName
StPreis
gehört
zu
ANGESTELLTER
Position
Auslastung
(1,*)
.
(1,1)
abt f
Abbildung 2.1: Konzern–Schema
19
Kapitel 2. Grundlagen
2.3
Die Datentyp–Signatur
In diesem Abschnitt werden die Begriﬀe der Syntax und der Semantik einer Datentyp–
Signatur eingeführt. Darauf aufbauend werden die Standarddatentypen des EER–Modells
deﬁniert.
Als erstes werden die verwendeten Notationen eingeführt:
|SET| : Klasse aller Mengen
|REL| : Klasse aller Relationen
|FUN| : Klasse aller Funktionen
|FISET| : Klasse aller endlichen Mengen
Es sei S eine beliebige Menge aus |SET|. Dann ist
P(S) : Menge aller Teilmengen von S (Potenzmenge von S)
F (S) : Menge aller endlichen Teilmengen von S
B(S) : Menge aller endlichen Multimengen über S
S ∗ : Menge aller endlichen Listen über S
S + : Menge aller endlichen, nichtleeren Listen über S
2.3.1
Formale Definition
Definition 2.1
Die Syntax einer Datentyp–Signatur DT = (SORTDT , OPNSDT , PREDDT ) besteht
aus
1. den endlichen Mengen SORTDT , OPNSDT , PREDDT ∈ |FISET|,
2. den Hilfsfunktionen source, destination, arguments ∈ |FUN|, so daß
source : OPNSDT → SORT∗DT ,
destination : OPNSDT → SORTDT ,
arguments : PREDDT → SORT+
DT .
Ist ω ∈ OPNS mit source(ω) =< d1 , . . . , dn > und destination(ω) = d, so wird
ω : d1 , . . . , dn → d als Operationssignatur (oder kurz Operation) von ω bezeichnet.
Ist π ∈ PRED mit arguments(π) =< d1 , . . . , dn >, so wird π : d1 , . . . , dn als Prädikatsignatur (oder kurz Prädikat) von π bezeichnet.
Definition 2.2
Eine Interpretation I einer Datentyp–Signatur DT ist ein Tripel I
(ISORT , IOPNS , IPRED ) mit
=
1. einer Funktion ISORT : SORT → |SET|, so daß ⊥d ∈ ISORT (d) für jedes d ∈ SORT.
⊥d bezeichne einen Nullwert für jedes d ∈ SORT.
20
2.3. Die Datentyp–Signatur
2. einer Funktion IOPNS : OPNS → |FUN|, so daß jedes ω : d1 , . . . , dn → d ∈ OPNS
eine Funktion
IOPNS(w) : ISORT (d1 ) × . . . × ISORT (dn ) → ISORT (d)
impliziert.
|DT| bezeichne die Klasse aller Interpretationen der Datentyp–Signatur DT.
Die Semantik µ[DT] einer Datentyp–Signatur DT ist eine feste Interpretation aus der
Klasse DT.
2.3.2
EER–Standarddatentyp–Signatur
Die Standarddatentypen des EER–Modells sind die aus Programmiersprachen bekannten Datentypen boolean, integer, number und string. Mit Hilfe einer Datentyp–Signatur
können sie, zusammen mit üblichen Operationen und Prädikaten, eindeutig deﬁniert werden. Die Listenbildung (list), Mengenbildung (set), sowie Multimengenbildung (bag) werden zur Deﬁnition verschiedener Operationen benötigt.
Jede Interpretation eines Datentyps s enthält einen sogenannten Nullwert ⊥s im Sinne
von undeﬁniert“. Der Grund für die Einführung dieser speziellen Werte ⊥ sind die optio”
nalen Attributtypen. Ist A ein derartiger Attributtyp zu einem Entitytyp E oder einem
Relationshiptyp R mit einem Wertebereich domain(A) := s ∈ SORT, so kann das Attribut a den Wert ⊥s liefern, wenn der Attributwert zu einem konkreten Entity e oder
einem Relationship r nicht bekannt ist.
SORTDT = {boolean, integer, number, string}
Es seien u ∈ SORTDT und v ∈ {integer, number} ⊆ SORTDT beliebig.
Gegeben seien die wie folgt deﬁnierten Hilfsoperationen max und min.
Es seien x, y ∈ v, dann gilt:
x, falls x ≥v y
max(x, y) :=
y, sonst
min(x, y) :=
x, falls x ≤v y
y, sonst
21
Kapitel 2. Grundlagen
OPNSDT = { and, or : boolean, boolean → boolean,
not : boolean → boolean,
+i , −i , ∗i : integer, integer → integer,
/i : integer, integer → number,
numberi : integer → number,
+n , −n , ∗n , /n : number, number → number,
avgset(v) : set(v) → number,
countset(u) : set(u) → integer,
maxset(v) : set(v) → v,
minset(v) : set(v) → v,
sumset(v) : set(v) → v,
avgbag(v) : bag(v) → number,
btsbag(u) : bag(u) → set(u),
countbag(u) : bag(u) → integer,
maxbag(v) : bag(v) → v,
minbag(v) : bag(v) → v,
occbag(u) : bag(u), u → integer,
sumbag(v) : bag(v) → v,
avglist(v) : list(v) → number,
countlist(u) : list(u) → integer,
indlist(u) : list(u) → set(integer),
ltblist(u) : list(u) → bag(u),
ltslist(u) : list(u) → set(u),
maxlist(v) : list(v) → v,
minlist(v) : list(v) → v,
occlist(u) : list(u), u → integer,
poslist(u) : list(u), u → set(integer),
sellist(u) : list(u), integer → u,
sumlist(v) : list(v) → v }
PREDDT = {
<i , >i , ≤i , ≥i , =i , =i : integer, integer,
<n , >n , ≤n , ≥n , =n , =n : number, number
∈set(u) : u, set(u)
∈bag(u) : u, bag(u)
∈list(u) : u, list(u) }
Weitere Operationen und Prädikate können in gleicher Weise hinzugefügt werden, wie
zum Beispiel Vergleichsprädikate für Zeichenketten.
ISORT (boolean) := {true, f alse, ⊥b }
ISORT (integer) := Z ∪ {⊥i }
ISORT (number) := R ∪ {⊥n }
22
2.3. Die Datentyp–Signatur
ISORT (string) := Menge aller endlichen Zeichenketten und einem Element ⊥s
IOPNS (and) : logische UND–Verknüpfung boolescher Ausdrücke
Diese logische Verknüpfung wird gemäß der folgenden dreiwertigen Logik ausgewertet:
and true false ⊥b
true true false ⊥b
false false false false
⊥b false ⊥b
⊥b
IOPNS (or) : logische OR–Verknüpfung boolescher Ausdrücke
Diese logische Verknüpfung wird gemäß der folgenden dreiwertigen Logik ausgewertet:
or
true
false
⊥b
false ⊥b
true true
false ⊥b
⊥b
⊥b
true
true
true
true
IOPNS (not) : Negation eines booleschen Ausdrucks
Diese logische Verknüpfung wird gemäß der folgenden dreiwertigen Logik ausgewertet:
not
true false
false true
⊥b
⊥b
IOPNS (+i) : Summe ganzer Zahlen
IOPNS (−i ) : Diﬀerenz ganzer Zahlen
IOPNS (∗i) : Produkt ganzer Zahlen
IOPNS (/i) : Quotient ganzer Zahlen
IOPNS (numberi ) : Konvertierung eines integer–Werts in einen number–Wert
Die Anwendung auf einen number–Wert verändert diesen nicht.
IOPNS (+n ) : Summe reeller Zahlen
IOPNS (−n ) : Diﬀerenz reeller Zahlen
IOPNS (∗n ) : Produkt reeller Zahlen
IOPNS (/n ) : Quotient reeller Zahlen
Mengenoperationen
IOPNS (avgset(v) ) : Berechnung des Durchschnitts von Mengenelementen
Es sei {k1 , . . . , kn } ∈ set(v), dann ist

falls n = 0
 ⊥v ,
numberi (sumset(v) ({k1 , . . . , kn })) /n
avgset(v) ({k1 , . . . , kn }) :=
, sonst

numberi (countset(v) ({k1 , . . . , kn }))
23
Kapitel 2. Grundlagen
IOPNS (countset(u) ) : Bestimmung der Anzahl von Mengenelementen
Es sei {k1 , . . . , kn } ∈ set(u), dann ist
countset(u) ({k1 , . . . , kn }) := n.
IOPNS (maxset(v) ) : Bestimmung des Maximums von Mengenelementen
Es sei {k1 , . . . , kn } ∈ set(v), dann ist
falls n = 0
⊥v ,
maxset(v) ({k1 , . . . , kn }) :=
max(k1 , maxset(v) ({k2 , . . . , kn })), sonst
IOPNS (minset(v) ) : Bestimmung des Minimums von Mengenelementen
Es sei {k1 , . . . , kn } ∈ set(v), dann ist
falls n = 0
⊥v ,
minset(v) ({k1 , . . . , kn }) :=
min(k1 , minset(v) ({k2 , . . . , kn })), sonst
IOPNS (sumset(v) ) : Summenbildung von Mengenelementen
Es sei {k1 , . . . , kn } ∈ set(v), dann ist
⊥v ,
falls n = 0
sumset(v) ({k1 , . . . , kn }) :=
k1 +v . . . +v kn , sonst
Multimengenoperationen
IOPNS (avgbag(v) ) : Berechnung des Durchschnitts von Multimengenelementen
Es sei {{k1 , . . . , kn }} ∈ bag(v), dann ist

falls n = 0
 ⊥v ,
(sum
({
{k
,
.
.
.
,
k
}
}))
/
number
i
1
n
n
avgbag(v) ({{k1 , . . . , kn }}) :=
bag(v)
, sonst

numberi (countbag(v) ({{k1 , . . . , kn }}))
IOPNS (btsbag(u) ) : Konvertierung einer Multimenge in eine Menge (bag–to–set)
Es sei {{k1 , . . . , kn }} ∈ bag(u), dann ist
{ },
falls n = 0
btsbag(u) ({{k1 , . . . , kn }}) :=
{k1 } ∪ btsbag(u) ({{k2 , . . . , kn }}), sonst
IOPNS (countbag(u) ) : Bestimmung der Anzahl von Multimengenelementen
Es sei {{k1 , . . . , kn }} ∈ bag(u), dann ist
countbag(u) ({{k1 , . . . , kn }}) := n.
IOPNS (maxbag(v) ) : Bestimmung des Maximums von Multimengenelementen
Es sei {{k1 , . . . , kn }} ∈ bag(v), dann ist
falls n = 0
⊥v ,
maxbag(v) ({{k1 , . . . , kn }}) :=
max(k1 , maxbag(v) ({{k2 , . . . , kn }})), sonst
24
2.3. Die Datentyp–Signatur
IOPNS (minbag(v) ) : Bestimmung des Minimums von Multimengenelementen
Es sei {{k1 , . . . , kn }} ∈ bag(v), dann ist
falls n = 0
⊥v ,
minbag(v) ({{k1 , . . . , kn }}) :=
min(k1 , minbag(v) ({{k2 , . . . , kn }})), sonst
IOPNS (occbag(u) ) :
Berechnung der Häuﬁgkeit eines Elements in
(occurrence)
Es sei {{k1 , . . . , kn }} ∈ bag(u), k ∈ u, dann ist

 0,
occbag(u) ({{k2 , . . . , kn }}, k),
occbag(u) ({{k1 , . . . , kn }}, k) :=

occbag(u) ({{k2 , . . . , kn }}, k) + 1,
einer Multimenge
falls n = 0
falls n ≥ 1 und k = k1
sonst
IOPNS (sumbag(v) ) : Summenbildung von Multimengenelementen
Es sei {{k1 , . . . , kn }} ∈ bag(v), dann ist
⊥v ,
falls n = 0
sumbag(v) ({{k1 , . . . , kn }}) :=
k1 +v . . . +v kn , sonst
Listenoperationen
IOPNS (avglist(v) ) : Berechnung des Durchschnitts von Listenelementen
Es sei < k1 , . . . , kn >∈ list(v), dann ist

falls n = 0
 ⊥v ,
numberi (sumlist(v) (< k1 , . . . , kn >)) /n
avglist(v) (< k1 , . . . , kn >) :=
, sonst

numberi (countlist(v) (< k1 , . . . , kn >))
IOPNS (countlist(u) ) : Bestimmung der Anzahl von Listenelementen
Es sei < k1 , . . . , kn >∈ list(u), dann ist
countlist(u) (< k1 , . . . , kn >) := n.
IOPNS (indlist(u) ) : Berechnung der Indizes einer Liste
Es sei < k1 , . . . , kn >∈ list(u), dann ist
indlist(u) (< k1 , . . . , kn >) := {1, . . . , n}
IOPNS (ltblist(u) ) : Konvertierung einer Liste in eine Multimenge (list–to–bag)
Es sei < k1 , . . . , kn >∈ list(u), dann ist
ltblist(u) (< k1 , . . . , kn >) := {{k1 , . . . , kn }}.
IOPNS (ltslist(u) ) : Konvertierung einer Liste in eine Menge (list–to–set)
Es sei < k1 , . . . , kn >∈ list(u), dann ist
{ },
falls n = 0
ltslist(u) (< k1 , . . . , kn >) :=
{k1 } ∪ ltslist(u) (< k2 , . . . , kn >), sonst
25
Kapitel 2. Grundlagen
IOPNS (maxlist(v) ) : Bestimmung des Maximums von Listenelementen
Es sei < k1 , . . . , kn >∈ list(v), dann ist
maxlist(v) (< k1 , . . . , kn >) :=
⊥v ,
falls n = 0
max(k1 , maxlist(v) (< k2 , . . . , kn >)), sonst
IOPNS (minlist(v) ) : Bestimmung des Minimums von Listenelementen
Es sei < k1 , . . . , kn >∈ list(v), dann ist
minlist(v) (< k1 , . . . , kn >) :=
⊥v ,
falls n = 0
min(k1 , minlist(v) (< k2 , . . . , kn >)), sonst
IOPNS (occlist(u) ) : Berechnung der Häuﬁgkeit eines Elements in einer Liste
Es sei < k1 , . . . , kn >∈ list(u), k ∈ u, dann ist

falls n = 0
 0,
falls n ≥ 1 und k = k1
occlist(u) (< k2 , . . . , kn >, k),
occlist(u) (< k1 , . . . , kn >, k) :=

occlist(u) (< k2 , . . . , kn >, k) + 1, sonst
IOPNS (poslist(u) ) : Berechnung des Indizes eines Listenelements (position)
Es sei < k1 , . . . , kn >∈ list(u), k ∈ u, dann ist

falls n = 0
 { },
poslist(u) (< k2 , . . . , kn >, k),
falls n ≥ 1 und k = k1
poslist(u) (< k1 , . . . , kn >, k) :=

poslist(u) (< k2 , . . . , kn >, k) ∪ {1}, sonst
IOPNS (sellist(u) ) : Selektion eines Listenelements (selection)
Es sei < k1 , . . . , kn >∈ list(u), j ∈ integer, dann ist
kj , falls 1 ≤ j ≤ n
sellist(u) (< k1 , . . . , kn >, j) :=
⊥u , sonst
IOPNS (sumlist(v) ) : Summenbildung von Listenelementen
Es sei < k1 , . . . , kn >∈ list(v), dann ist
falls n = 0
⊥v ,
sumlist(v) (< k1 , . . . , kn >) :=
k1 +v . . . +v kn , sonst
IPRED (<i ) :
IPRED (>i ) :
IPRED (≤i ) :
IPRED (≥i ) :
IPRED (=i ) :
IPRED (=i ) :
Kleiner–Relation für ganze Zahlen
Größer–Relation für ganze Zahlen
Kleiner–gleich–Relation für ganze Zahlen
Größer–gleich–Relation für ganze Zahlen
Gleich–Relation für ganze Zahlen
Ungleich–Relation für ganze Zahlen
26
2.4. Die EER–Signatur
IPRED (<n ) :
IPRED (>n ) :
IPRED (≤n ) :
IPRED (≥n ) :
IPRED (=n ) :
IPRED (=n ) :
Kleiner–Relation für reelle Zahlen
Größer–Relation für reelle Zahlen
Kleiner–gleich–Relation für reelle Zahlen
Größer–gleich–Relation für reelle Zahlen
Gleich–Relation für reelle Zahlen
Ungleich–Relation für reelle Zahlen
IPRED (∈set(u) ) : ist–Element–von–Prädikat für Mengen
Es sei {k1 , . . . , kn } ∈ set(u), k ∈ u dann ist
k ∈set(u) {k1 , . . . , kn } ⇔ ∃ kj mit k = kj , 1 ≤ j ≤ n
IPRED (∈bag(u) ) : ist–Element–von–Prädikat für Multimengen
Es sei {{k1 , . . . , kn }} ∈ bag(u), k ∈ u dann ist
k ∈bag(u) {{k1 , . . . , kn }} ⇔ ∃ kj mit k = kj , 1 ≤ j ≤ n
IPRED (∈list(u) ) : ist–Element–von–Prädikat für Listen
Es sei < k1 , . . . , kn >∈ list(u), k ∈ u dann ist
k ∈list(u) < k1 , . . . , kn >⇔ ∃ kj mit k = kj , 1 ≤ j ≤ n
2.4
Die EER–Signatur
In der EER–Signatur werden die Grundkonzepte des EER–Modells formalisiert. Damit
wird eine Möglichkeit zur Beschreibung der Syntax und der Semantik des EER–Modells
eingeführt.
2.4.1
Syntax
Zu der Beschreibung der Syntax des EER–Modells werden die Mengen, die den Grundkonzepten entsprechen, und die darauf deﬁnierten Hilfsfunktionen eingeführt.
Die nachstehenden Mengen entsprechen den Grundkonzepten des EER–Modells direkt:
E-TYPE = { Namen aller speziﬁzierten Entitytypen }
R-TYPE = { Namen aller speziﬁzierten Relationshiptypen }
ROLE = { Namen aller speziﬁzierten Rollen }
ATTR = { Namen aller speziﬁzierten Attributtypen }
COMP = { Namen aller speziﬁzierten Komponenten }
CONSTRUCTION = { Namen aller speziﬁzierten Typkonstruktionen }
Hilfsfunktionen spiegeln den Zusammenhang der Konzepte wider:
participants : liefert zu jedem Relationshiptyp die teilnehmenden Entitytypen
relship : ordnet jedem Rollennamen den zugehörigen Relationshiptyp zu
entity : ordnet jedem Rollennamen den teilnehmenden Entitytyp zu
type : legt den Typ (Entity oder Relationship) eines Attributtyps oder einer Komponente
fest
27
Kapitel 2. Grundlagen
domain : legt den Wertebereich eines Attributtyps oder einer Komponente fest
input : bestimmt den Eingangstyp einer Typkonstruktion
output : bestimmt den Ausgangstyp einer Typkonstruktion
Definition 2.3
Es sei eine Datentyp–Signatur DT = (SORTDT , OPNSDT , PREDDT ) gegeben. Die Syntax
einer EER–Signatur EER(DT) über DT besteht aus:
1. den endlichen Mengen E-TYPE, R-TYPE, ROLE, ATTR, COMP,
CONSTRUCTION ∈ |FISET|
2. den Hilfsfunktionen participants, relship, entity, type, domain, input, output ∈
|FUN|, so daß
R-TYPE → E-TYPE+
ROLE → R-TYPE
ROLE → E-TYPE
ATTR → E-TYPE ∪ R-TYPE
COMP → E-TYPE
domain :
ATTR → {d | d ≡ d oder d ≡ set/bag/list(d), d ∈ SORTDT }
COMP → {e | e ≡ e oder e ≡ set/bag/list(e), e ∈ E-TYPE}
input, output : CONSTRUCTION → (F (E-TYPE) − ∅)
participants :
relship :
entity :
type :
Für jeden Relationshiptyp R ∈ R-TYPE mit participants(R) =< E1 , . . . , Em > können
genau m Rollennamen ni ∈ ROLE (i = 1, . . . , m) mit relship(ni ) = R und entity(ni ) = Ei
existieren. Dann wird R(n1 : E1 , . . . , nm : Em ) ∈ R-TYPE und ni : R → Ei ∈ ROLE(i =
1, . . . , m) notiert.
Für A ∈ ATTR mit type(A) = S, S ∈ E-TYPE ∪ R-TYPE und domain(A) = d wird
A : S → d notiert und entsprechend C : E → E für C ∈ COMP mit type(C) = E und
domain(C) = E .
Für Typkonstruktionen T, T1 , T2 ∈ CONSTRUCTION müssen die folgenden Bedingungen erfüllt sein:
1. output(T1 ) ∩ output(T2 ) = ∅ für T1 = T2
2. Sei connection:= {(I, O) | T ∈ CONSTRUCTION, I ∈ input(T ), O ∈ output(T )}
eine Relation und bezeichne connection+ die transitive Hülle dieser Relation, so darf
(E, E) ∈ connection+ für keinen Entitytyp E ∈ E-TYPE erfüllt sein.
Beispiel 2.4
Das EER–Schema des Konzerns in Abbildung 2.1 ist analog dem EER–Schema, das durch
die folgenden Mengen gegeben ist:
28
2.4. Die EER–Signatur
E-TYPE =
{
R-TYPE = {
KONZERN, FIRMA, ADRESSE, ZULIEFERFIRMA, KUNDE, AUFTRAG,
VORPRODUKT, PRODUKT, ABTEILUNG, ANGESTELLTER}
vergibt(kunde: KUNDE, k auftr: AUFTRAG),
liefert(zulieferﬁrma: ZULIEFERFIRMA, vorprodukt: VORPRODUKT),
besteht aus(a inhalt: AUFTRAG, p auftr: PRODUKT),
produziert(abt p: ABTEILUNG, p abt: PRODUKT),
gehört zu(abt f: ABTEILUNG, ﬁrma: FIRMA) }
ROLE =
{
ﬁrma (von FIRMA), zulieferﬁrma(von ZULIEFERFIRMA),
kunde (von KUNDE), a inhalt, k auftr (von AUFTRAG),
vorprodukt (von VORPRODUKT), p abt, p auftr (von PRODUKT),
abt f, abt p (von ABTEILUNG) }
ATTR =
{
Name (von KONZERN), Firmenname (von FIRMA),
Strasse, HausNr, Plz, Ort, TelNr, Fax (von ADRESSE),
Datum, AuftrNr (von AUTRAG), Preis, Menge (von besteht aus),
ChargenNr, ProdName, StPreis (von PRODUKT),
Auslastung (von produziert), AbtName (von ABTEILUNG),
Position, Gehalt, PersNr, AngName (von ANGESTELLTER) }
COMP =
{
Tochterﬁrmen, Adresse (von Konzern), Anschrift (von FIRMA),
AbtLeiter, Mitarbeiter (von ABTEILUNG),
AngAnschrift (von ANGESTELLTER),
Auftrag (von liefert) }
CONSTRUCTION = { ⊇(FIRMA;ZULIEFERFIRMA),
⊇(FIRMA;KUNDE),
⊇(PRODUKT;VORPRODUKT) }
2.4.2
Semantik
Zu jedem EER–Modell gehört ein Universum µ, das aus einer Sammlung von Wertebereichen bzw. Mengen möglicher Entities zu den im Modell angegebenen Daten– bzw.
Entitytypen besteht.
Zu jedem Datenbank–Schema gehört eine Menge
von passenden Datenbank–Zuständen
(Ausprägungen). Ein Zustand σ einer Datenbank ist eine Menge von Entities, Relationships und Attributen, die zu den in der Datenbank modellierten
Entity– und Relationship–
sowie Attributtypen gehören. In jedem Zustand σ ∈
werden die im Schema angegebenen Entity– und anderen Strukturtypen durch passende mathematische Strukturen wie
Mengen, Funktionen, Relationen usw. interpretiert.
Es folgt die Semantik der einzelnen Modellierungskonzepte des EER–Modells:
Entitytypen
Es sei E ∈ E-TYPE, dann gilt:
• E → µ(E)
29
Kapitel 2. Grundlagen
mit µ(E) = Menge der möglichen Entities vom Typ E. Dieses ist i. a. eine (nur
gedachte) unendliche Menge.
• im Zustand σ:
σ(E) = Menge der aktuellen Entities vom Typ E, so daß σ(E) ⊆ µ(E).
Das bedeutet, daß ein Entity vom Typ E im Zustand σ ein Element e ∈ σ(E) ist.
• Für verschiedene Entitytypen Ei = Ej , Ei , Ej ∈ E-TYPE, wird die Disjunktheit
der Universen und damit auch von Zuständen gefordert, d.h.
µ(Ei ) ∩ µ(Ej ) = ∅ ⇒ σ(Ei ) ∩ σ(Ej ) = ∅
Relationshiptypen
Es seien R ∈ R-TYPE und E1 , . . . , Em ∈ E-TYPE mit participants(R) = {E1 , . . . , Em }.
Im Zustand σ gilt:
σ(R) ⊆ σ(E1 ) × . . . × σ(Em )
Das bedeutet, daß ein Relationship vom Typ R zwischen Entities e1 , . . . , em ein m–Tupel
(e1 , . . . , em ) ∈ σ(R) ist.
Attributtypen
• Entity–Attributtypen:
Es seien E ∈ E-TYPE und A ∈ ATTR mit type(A) = E.
Im Zustand σ gilt:
σ(A) : σ(E) → domain(A)
Das heißt, daß ein Attribut vom Typ A im Zustand σ ein Zuordnungspaar (e, a) mit
e ∈ E und a ∈ domain(A) ist.
• optionale Entity–Attributtypen:
Es seien E ∈ E-TYPE und A ∈ ATTR mit type(A) = E.
Im Zustand σ gilt:
σ(A) : σ(E)→domain(A)
σ(A) ist eine partielle Funktion, da ⊥u ∈ domain(A) gilt, wobei ⊥u den Nullwert
eines Datentyps u ∈ SORTDT bezeichnet.
• Relationship–Attributtypen:
Es seien R ∈ R-TYPE und A ∈ ATTR mit type(A) = R.
Im Zustand σ gilt:
σ(A) : σ(R) → domain(A)
• optionale Relationship–Attributtypen:
Es seien R ∈ R-TYPE und A ∈ ATTR mit type(A) = R.
Im Zustand σ gilt:
σ(A) : σ(R)→domain(A)
30
2.4. Die EER–Signatur
Rollen
Es seien n ∈ ROLE, R ∈ R-TYPE und E ∈ E-TYPE mit relship(n) = R und
entity(n) = E.
Im Zustand σ gilt:
σ(n) = π : σ(R) → σ(E)
Ein Rollenname benennt eine Projektion π zwischen zusammengehörigen Entity– und
Relationshiptypen.
Kardinalitäten
Es seien R ∈ R-TYPE und E1 , E2 ∈ E-TYPE mit participants(R) ⊆ {E1 , E2 }.
Für die allgemeine Kardinalität (min1 , max1 ), (min2 , max2 ) gilt im Zustand σ:
∀ e1 ∈ σ(E1 ) : min1 ≤ |{e2 ∈ σ(E2 ) | (e1 , e2 ) ∈ σ(R)}| ≤ max1
∀ e2 ∈ σ(E2 ) : min2 ≤ |{e1 ∈ σ(E1 ) | (e1 , e2 ) ∈ σ(R)}| ≤ max2
Kardinalitäten beschreiben die Beteiligung von Objekten an Beziehungen.
Komponenten
Es seien C ∈ COMP und E1 , E2 ∈ E-TYPE mit type(C) = {E1 , E2 }.
• Aggregation
Im Zustand σ als objektwertiges Attribut gilt:
σ(C) : σ(E1 ) → σ(E2 )
Das bedeutet, daß die Komponente eine Zuordnung zwischen Objektmengen bezeichnet.
• Assoziation
Im Zustand σ als komplex–objektwertiges Attribut gilt:
σ(C) : σ(E1 ) → ass(σ(E2 ))
Hierbei steht ass für die Listen–, Mengen– oder Multimengenbildung:
σ(C) : σ(E1 ) → (σ(E2 ))∗
σ(C) : σ(E1 ) → P(σ(E2 ))
σ(C) : σ(E1 ) → B(σ(E2 ))
Typkonstruktionen
Gegeben seien n Eingangstypen E1 , . . . , En ∈ E-TYPE und m Ausgangstypen
A1 , . . . , Am ∈ E-TYPE sowie ein Teilmengenoperator Θ. In Abhängigkeit von m, n und Θ
werden durch eine Typkonstruktion T verschiedene Teilmengenbeziehungen beschrieben.
Es muß input(T ) = {E1 , . . . , En } und output(T ) = {A1 , . . . , Am } gelten.
• Generalisierung: m = 1, Θ ≡ =
31
Kapitel 2. Grundlagen
• einfache Spezialisierung: n = m = 1, Θ ≡ ⊇
• allgemeine (disjunkte) Spezialisierung: n = 1, Θ ≡ ⊇
• Kategorisierung: m = 1, Θ ≡ ⊇
• Partition: n = 1, Θ ≡ =
Damit alle Entities der Eingangstypen zusammengefaßt und ein Teil von ihnen auf die
Ausgangstypen verteilt wird, müssen die folgenden Bedingungen vom Universum µ und
in jedem Zustand σ erfüllt sein:
•
n
k=1
n
k=1
σ(Ek ) Θ
µ(Ek ) =
m
j=1 σ(Aj )
m
j=1
µ(Aj )
Diese beiden Bedingungen besagen, daß die Ausgangstypen nur Entities der Eingangstypen enthalten dürfen.
• σ(Ap ) ∩ σ(Aq ) = ∅ für p = q und p, q = 1, . . . , m
Dieses bedeutet, daß die Ausgangstypen disjunkt sind, d.h. ein Eingangstyp kann
nur in einem Ausgangstyp präsent sein.
Schlüssel
Gegeben sei ein Entitytyp E mit den Attributtypen A1 , . . . , An , d.h. type(Ai ) = E für i =
1, . . . , n. Eine Teilmenge {Ai1 , . . . , Aik } ⊆ {A1 , . . . , An } von obligatorischen Attributen
ist genau dann ein Schlüssel von E, wenn gilt:
• ∀ σ ∀ e, e ∈ σ(E) : (∀ j = 1, . . . , k : σ(Aij )(e) = σ(Aij )(e )) ⇒ e = e
• {Ai1 , . . . , Aik } ist eine minimale Teilmenge mit dieser Eigenschaft.
In einem EER–Modell muß zu jedem Entitytyp ein Schlüssel angegeben werden, sofern
dieser Typ kein Ausgangstyp einer Typkonstruktion ist. In einem solchen Fall erbt ein
Ausgangstyp die Schlüssel der Eingangstypen.
2.5
Der EER–Kalkül
Ein Kalkül zu einem Datenmodell ist eine Sprache, die die Darstellung logischer Zusammenhänge in einer übersichtlichen und exakten Form ermöglicht. Er eignet sich daher zur
Deﬁnition der Semantik einer Sprache, die auf diesem Datenmodell basiert.
Die Syntax des EER–Kalküls wird mit Hilfe der Prädikatenlogik 1. Ordnung deﬁniert.
Im Gegensatz zur Prädikatenlogik ist der EER–Kalkül aber nicht hierarchisch aufgebaut (Abbildung 2.2), sondern besitzt eine rekursive Struktur (Abbildung 2.3). Daher ist
bei einzelnen Deﬁnitionen die Verwendung später deﬁnierter Begriﬀe nicht vermeidbar.
Die Semantik des Kalküls wird anschließend formal deﬁniert. Auch wird der Begriﬀ der
32
2.5. Der EER–Kalkül
Datenbank–Anfrage deﬁniert, denn nur mit einer Anfrage ist es möglich, Informationen
aus einer Datenbank zu erhalten.
Terme
Formeln
Atomare Formeln
Abbildung 2.2: Hierarchischer Aufbau der Prädikatenlogik 1. Ordnung
Terme
Atomare Formeln
Bereiche
Formeln
Deklarationen
Abbildung 2.3: Rekursiver Aufbau des EER–Kalküls
Es sei ein EER–Modell einschließlich zugehöriger Datentypen SORTDT sowie ein
Datenbank–Zustand σ gegeben. Die Datentypen haben eine feste Interpretation.
Die Beispiele in diesem Kapitel beziehen sich alle auf das Konzern–Modell (siehe Abbildung 2.1) aus Kapitel 2.2.
2.5.1
Syntax
Definition 2.5
Das Alphabet des EER–Kalküls setzt sich wie folgt zusammen:
• Trennzeichen
• Klammern
• Doppelpunkt
, (Komma)
(, )
:
• Verbindungszeichen
• Quantoren
¬, ∧, ∨, ⇒, ⇔
∀, ∃
• Individuenvariablen
x, y, z . . .
• Sorten
33
Kapitel 2. Grundlagen
– Datensorten SORTDT
– Entitytypen E-TYPE
– Relationshiptypen R-TYPE
• Sortenausdrücke
– Jede Sorte ist ein Sortenausdruck.
– Ist s ein Sortenausdruck, so sind list(s), set(s) und bag(s) Sortenausdrücke.
• Die Menge der Prädikatsymbole π(τ1 , . . . , τn ) besteht aus den Datentyp–Prädikaten
der Menge PREDDT sowie den Relationshiptypen. Mit den Prädikaten der Menge
PREDDT stehen Vergleichsoperatoren für Zahlen, Listen, Mengen und Multimengen
zur Verfügung. Die Datentyp–anzeigenden Indizes der Prädikate der Menge PREDDT
werden i. allg. weggelassen, da sich dieser aus dem Kontext erschließen läßt.
Ein Relationshiptyp (ohne Berücksichtigung von Relationship–Attributtypen)
R(n1 : E1 , . . . , nm : Em ) mit partizipierenden Entitytypen Ei und zugehörigen Rollennamen ni ist als Prädikat R(τ1 , . . . , τm ) zugelassen. Die Deﬁnition dieses Prädikats ist
R(τ1 , . . . , τm ) := ∃ (xR : R) (n1 (xR ) = τ1 ∧ . . . ∧ nm (xR ) = τm ),
wobei xR eine Variable für den Relationshiptyp R ist. Das bedeutet, daß die zu
Entities ei ausgewerteten Terme τi (i = 1, . . . , m) in einer Beziehung des Typs R
stehen müssen, um die Formel zu erfüllen. Die τi sind Terme im Sinne der unten
gegebenen Deﬁnition.
Die Menge der Prädikatsymbole wird durch is–Prädikate, die auf Typkonstruktionen
angewendet werden, erweitert. Das Prädikat is Ak : Ej prüft, ob ein Entity des
Eingangstyps Ej auch Entity des Ausgangstyps Ak ist. Es sei e ∈ Ej , dann gilt
true, falls e ∈ Ak
is Ak (e) =
f alse, sonst
Analog ist das Prädikat is Ej : Ak deﬁniert.
• Die Menge der Operatorsymbole ω(τ1 , . . . , τn ) besteht aus den Datentyp–Operationen der Menge OPNSDT . Damit existieren Operationen auf Listen, Mengen und
Multimengen. Aggregierende Funktionen auf Assoziationen von Zahlen und Konvertierungsfunktionen sind deﬁniert. Der Datentyp–anzeigende Index wird auch für
Operatoren der Menge OPNSDT i. allg. nicht angegeben.
Erweitert wird diese Menge durch Datenbankschema–Operatoren. Ist x eine Variable der Sorte E ∈ E-TYPE oder R ∈ R-TYPE und A ∈ ATTR ein Attribut, so
bezeichnet x.A eine Variable für das Attribut A, das zum Typ E oder R gehört.
In gleicher Weise werden Variablen für Komponenten C ∈ COMP oder Rollennamen n ∈ ROLE erzeugt: x.C.A entspricht einer Variablen für das Attribut A der
Komponente C, die objektwertiges Attribut des Typs E oder R ist.
Partielle Konversionen ermitteln die gemeinsamen Entities von Ein– und Ausgangstypen von Typkonstruktionen. So berechnet der Operator as Ak : Ej → Ak diejenigen Entities des Ausgangstyps Ak , die auch Entities des Eingangstyps Ej sind. Der
Operator as Ej : Ak → Ej ist analog deﬁniert.
34
2.5. Der EER–Kalkül
Eine besondere Art von Operator ist eine Konstante. Konstanten k der speziﬁzierten
Datentypen s werden als nullstellige Funktionen k :→ s aufgefaßt (nach [Hoh93]).
Definition 2.6
Eine Deklaration δ = (x : ρ) bindet eine Variable x an einen (sortenmäßig passenden)
Bereich ρ. Ein Bereich ist eine (Multi–) Menge mit endlich vielen Elementen oder ein
Sortenausdruck.
Definition 2.7
Die Terme des EER–Kalküls sind wie folgt induktiv deﬁniert:
1. Jede Variable x ist ein Term.
2. Jede sortenmäßig passende Anwendung ω(τ1 , . . . , τn ) eines Operators ω auf Terme
τ1 , . . . , τn ist ein Term.
3. Seien δ1 , . . . , δk Deklarationen und ϕ eine Formel. Wenn τ1 , . . . , τn Terme sind, so
sind es auch
• Mengenterme:
{τ1 , . . . , τn | δ1 ∧ . . . ∧ δk ∧ ϕ}
• Multimengenterme:
{{τ1 , . . . , τn | δ1 ∧ . . . ∧ δk ∧ ϕ}}
Die Gültigkeitsbereiche der Deklarationen bestehen aus den Termen τ1 , . . . , τn sowie
der Formel ϕ. Damit darf jede in δi deklarierte Variable sowohl in τ1 , . . . , τn als auch
in ϕ verwendet werden.
Beispiel 2.8
Die Variable ab sei vom Typ ABTEILUNG.
1. ab.AbtLeiter ist ein Term der Sorte ANGESTELLTER. AbtLeiter: ABTEILUNG
→ ANGESTELLTER ist eine Operation und die Variable ab ein Term (nach 2.7.1).
Nach 2.7.2 ist der Ausdruck also ein Term.
2. {{ab | (ab : ABTEILUNG)}} ist ein Term der Sorte bag(ABTEILUNG). Die Variable
ab ist durch die Deklaration (ab: ABTEILUNG) gebunden. Der Term ist nach 2.7.3
aufgebaut.
Definition 2.9
Atomare Formeln sind deﬁniert durch:
1. Eine Gleichung τ1 = τ2 zwischen zwei Termen τ1 und τ2 .
2. Eine sortenmäßig passende Anwendung π(τ1 , . . . , τn ) eines Prädikats π auf Terme
τ1 , . . . , τn .
35
Kapitel 2. Grundlagen
Beispiel 2.10
Die Variable ang sei vom Typ ANGESTELLTER, die Variable ab vom Typ ABTEILUNG,
die Variable prod sei vom Typ PRODUKT und die Variable p vom Typ produziert.
1. ang = ab.AbtLeiter ist eine atomare Formel nach 2.9.1.
2. p.Auslastung > 80 ist eine atomare Formel nach 2.9.2.
3. produziert(prod, ab) ist eine atomare Formel nach 2.9.2.
Definition 2.11
Eine Variable ist frei, wenn sie weder im Gültigkeitsbereich einer Deklaration noch in
dem eines Quantors liegt. Ist eine Variable nicht frei, so ist die gebunden.
Definition 2.12
Die Formeln des EER–Kalküls sind gegeben durch:
1. Jede atomare Formel ist eine Formel.
2. Wenn ϕ, ϕ1 , ϕ2 Formeln sind, so sind auch ¬ϕ, ϕ1 ∧ ϕ2 , ϕ1 ∨ ϕ2 Formeln.
3. Wenn ϕ eine Formel und δ = (x : ρ) eine Deklaration ist, so sind auch ∃ (x : ρ)(ϕ)
und ∀ (x : ρ)(ϕ) Formeln.
Der Gültigkeitsbereich der Deklaration δ ist auf ϕ beschränkt.
Beispiel 2.13
Die Variable ang sei vom Typ ANGESTELLTER.
1. Die Beispiele 2.10.1 und 2.10.2 sind Formeln nach 2.12.1.
2. (ang.PersNr = 100) ∨ (ang.PersNr = 101) ist eine Formel nach 2.12.2.
3. ∃ (ab : ABTEILUNG)(ang = ab.AbtLeiter) ist eine Formel nach 2.12.3.
Bemerkung
Die im Alphabet eingeführten Verbindungszeichen ⇒ und ⇔ sind als syntaktische
Abkürzungen wie folgt deﬁniert. ϕ1 und ϕ2 seinen Formeln.
(ϕ1 ⇒ ϕ2 ) := (¬(ϕ1 ) ∨ ϕ2 )
(ϕ1 ⇔ ϕ2 ) := ((ϕ1 ⇒ ϕ2 ) ∧ (ϕ2 ⇒ ϕ1 ))
2.5.2
Semantik
Definition 2.14
Ein Bereich ist, wie in 2.6 bereits deﬁniert, eine (Multi–) Menge mit endlich vielen Elementen oder ein Sortenausdruck. Aus diesen Bereichen kann eine Variable x Werte durch
Belegung annehmen. Eine Belegung β ordnet dabei allen (vorkommenden) Variablen
passende Werte, Objekte oder Beziehungen zu.
36
2.5. Der EER–Kalkül
Die folgenden Notationen werden verwendet:
[σ, β](τ ) bezeichne den Wert des Terms τ im Zustand σ unter der Belegung β.
[σ, β] |= ϕ bedeutet: Eine Formel ϕ ist im Zustand σ unter der Belegung β gültig.
Es folgt die Semantik, d.h. eine Interpretation der einzelnen Kalkülkonstrukte:
Definition 2.15
Die Semantik der Terme ist die folgende:
• [σ, β](x) := β(x)
• [σ, β](ω(τ1 , . . . , τn )) := σ(ω)([σ, β](τ1 ), . . . , [σ, β](τn ))
• [σ, β]({τ1 , . . . , τn | δ1 ∧ . . . ∧ δk ∧ ϕ}) :=
{[σ, β ](τ1 ), . . . , [σ, β ](τn ) | es gibt eine Ergänzung β der Belegung β für die in
δ1 , . . . , δk deklarierten Variablen, so daß [σ, β ] |= ϕ}.
• [σ, β]({{τ1 , . . . , τn | δ1 ∧ . . . ∧ δk ∧ ϕ}}) :=
{{[σ, β ](τ1 ), . . . , [σ, β ](τn ) | es gibt eine Ergänzung β der Belegung β für die in
δ1 , . . . , δk deklarierten Variablen, so daß [σ, β ] |= ϕ}}.
Definition 2.16
Die Semantik der atomaren Formeln:
• [σ, β] |= τ1 = τ2
gdw.
• [σ, β] |= π(τ1 , . . . , τn )
[σ, β](τ1 ) = [σ, β](τ2 )
gdw. ([σ, β](τ1 ), . . . , [σ, β](τn )) ∈ σ(π)
Definition 2.17
Die Semantik der Formeln:
• [σ, β] |= ¬ϕ
gdw.
nicht [σ, β] |= ϕ
• [σ, β] |= ϕ1 ∧ ϕ2
gdw.
[σ, β] |= ϕ1 und [σ, β] |= ϕ2
• [σ, β] |= ϕ1 ∨ ϕ2
gdw.
[σ, β] |= ϕ1 oder [σ, β] |= ϕ2
• [σ, β] |= ∃ (x : ρ)(ϕ) gdw.
es gibt r ∈ σ(ρ), so daß [σ, β ] |= ϕ, wobei β eine Ergänzung der Belegung β mit
β (x) = r und β (y) = β(y) für y ≡ x ist.
• [σ, β] |= ∀ (x : ρ)(ϕ) gdw.
für alle r ∈ σ(ρ) gilt [σ, β ] |= ϕ, wobei β eine Ergänzung der Belegung β mit
β (x) = r und β (y) = β(y) für y ≡ x ist.
37
Kapitel 2. Grundlagen
2.5.3
Anfragen
Anfragen dienen dazu, Informationen aus einer Datenbank zu erhalten. Wird eine Information benötigt, muß eine Anfrage gefunden werden, die diese Information aus dem
vorhandenen Datenbankinhalt speziﬁziert.
Definition 2.18
Eine Anfrage im EER–Kalkül ist ein Term ohne freie Variablen.
Das Verbot freier Variablen stellt sicher, daß ein Term nur in Abhängigkeit eines Datenbankzustands σ, aber unabhängig von einem durch eine Belegung gegebenen Kontext
ausgewertet wird.
Definition 2.19
Die Semantik einer Anfrage τ ist gegeben durch:
[σ, β] |= τ
gdw. [σ, α] |= τ,
wobei α und β beliebige Belegungen sind.
Beispiel 2.20
1. Welche Angestellten verdienen mehr als 4000 DM ?“
”
{ang.PersNr, ang.AngName | (ang : ANGESTELLTER) ∧ ang.Gehalt > 4000}
2. Welche Aufträge hat die Firma ’Meier’ vergeben ?“
”
{a.AuftrNr | (a : AUFTRAG) ∧ ∃ (f : FIRMA)(f.Firmenname = ’Meier’
∧ vergibt(as KUNDE(f), a)) }
3. Welche Mitarbeiter arbeiten in der Abteilung ’Montage’ ?“
”
{ang.PersNr, ang.AngName | (ang : ANGESTELLTER)
∧ ∃ (ab : ABTEILUNG)(ab.AbtName = ’Montage’ ∧ ang ∈ ab.Mitarbeiter)}
4. In welcher Abteilung arbeitet der Angestellte mit dem höchsten Gehalt ?“
”
{ab.AbtName | (ab : ABTEILUNG) ∧ ∃ (ang : ANGESTELLTER)
(ang.Gehalt = max{a.Gehalt | (a : ANGESTELLTER)}
∧ ang ∈ ab.Mitarbeiter)}
2.6
Relationenmodell
2.6.1
Formale Definition
Das Relationenmodell ist die Grundlage für viele Datenbank–Managementsysteme. Die
einzelnen Relationen werden durch Tabellen repräsentiert. Jede Zeile einer Tabelle heißt
38
2.6. Relationenmodell
Tupel. Alle Informationen einer Datenbank, also sowohl die Objekte wie auch ihre Beziehungen, werden auf die gleiche Art durch Tabellen dargestellt. Beziehungen zwischen
Objekten sind vorhanden, wenn ein Wert in mehreren Relationen vorkommt. Zur Deﬁnition des Relationenmodells wird der Begriﬀ des Relationenschemas benötigt.
Definition 2.21
Es sei eine Datentyp–Signatur DT = (SORTDT , OPNSDT , PREDDT ) gegeben. Die Syntax
eines Relationenschemas r ist gegeben durch:
1. die Mengen REL-TYPE, ATTRR ∈ |FISET| und
2. die Hilfsfunktionen sourceR und destinationR , so daß
sourceR : ATTRR → REL-TYPE
destinationR : ATTRR → SORTDT
Ein Relationenschema (auch Tupel genannt) r ∈ REL-TYPE ist von der Form
r = prod(A1 : u1 , . . . , An : un ) mit Ai ∈ ATTRR und ui ∈ SORTDT (f ür i = 1, . . . , n,
n ≥ 1).
Definition 2.22
Die Semantik eines Relationenschemas ist gegeben durch:
1. eine Funktion µREL : REL-TYPE → |FISET| und
2. eine Funktion µATTR : ATTRR → |FUN|, so daß
µATTR (A) : µREL (sourceR (A)) → µSORTDT (destinationR (A)).
Definition 2.23
Das Relationenmodell besteht aus einer Menge ATTRR von Attributen und einer Menge REL-TYPE von Relationenschemata ([Hoh93]).
2.6.2
Transformation des EER–Modells in das Relationenmodell
Die Transformation M eines EER–Modells in ein Relationenmodell ist eine Abbildung,
die zu gegebener EER–Modellierung eine äquivalente“ relationale Modellierung erzeugt:
”
EER-Modell → Relationenmodell
M :=
EER(DT)
→ REL(DT)
Diese Abbildung beinhaltet insbesondere die Transformation derjenigen Nicht–
Standarddatentypen der Menge DT, die nicht von relationalen Datenbanksystemen angeboten werden. M liefert zu gegebener EER–Signatur EER(DT) eine relationale Signatur
REL(DT), die, um Integritätsbedingungen erweitert, zur EER–Signatur äquivalent ist.
39
Kapitel 2. Grundlagen
Definition 2.24
Es sei eine Datentyp–Signatur DT = (SORTDT , OPNSDT , PREDDT ) gegeben.
Eine relationale Datentyp–Signatur REL(DT) zu einem EER–Schema ist ein Tripel
REL(DT) = (SORTREL , OPNSREL , PREDREL ), wobei gilt:
1. SORTREL := SORT
n DT ∪ {surrogateS | S ∈ E-TYPE ∪ R-TYPE} ∪
{ k=1 surrogateEk | C ∈ CONSTRUCTION
mit input(C) = {E1 , . . . , En }}
2. OPNSREL := OPNSDT
3. PREDREL := PREDDT
surrogateS , S ∈ E-TYPE ∪ R-TYPE, ist eine Menge spezieller Datentypen im Relationenmodell. Attribute, deren Wertebereich surrogate ist, heißen Surrogate. Diese sind
systemdeﬁniert und –kontrolliert, d.h. ein Benutzer hat auf diesen Wert keinen Einﬂuß.
Das Surrogat identiﬁziert eindeutig die zu einem Entity oder Relationship gehörigen Tupel
einer Relation. Surrogate können mit Hilfe der Mengenvereinigung miteinander kombiniert
werden.
Das Ziel dieser Arbeit ist die eindeutige Deﬁnition einer Datenbank–Anfragesprache.
Das Anlegen sowie Verwalten der dazu benötigten Datenbank, insbesondere die Integritätsüberwachung, stehen nicht im Vordergrund. Daher wird in diesem Abschnitt nur
die Rolle der Surrogate bei der Erzeugung einer Datenbank auf der Grundlage eines
EER–Schemas herausgestellt. Dadurch sollen die Unterschiede und Probleme, die bei der
Erzeugung einer benötigten temporalen Testdatenbank auftreten, verständlich gemacht
werden. Eine ausführliche Beschreibung der Transformation eines EER–Modells in das
Relationenmodell ist in [Zec97] zu ﬁnden. Dort wurden zu diesem Zweck Algorithmen
und ihre Übersetzung in eine Daten–Deﬁnitionssprache entwickelt. Im Rahmen der Diplomarbeit [Zec97] wurde das Werkzeug EDE (EER–Diagramm–Editor) erstellt, das ein
EER–Schema nach ORACLE transformiert. ORACLE ist ein Datenbankmanagementsystem, das auf dem Relationenmodell basiert. Die zugehörige Datenbanksprache ist SQL
(Structured Query Language).
Surrogat– und Schlüsselattribute
Bei der Transformation eines EER–Modells wird für jeden Entitytypen E, E ∈ E-TYPE,
eine eigene Relation deﬁniert. Diese Relation heißt Stammrelation. Sie erhält ein zusätzliches Attribut, ein künstliches Surrogat E$. Bei der Erzeugung einer solchen Stammrelation in ORACLE wird das Surrogat als primary key, die eigentlichen Schlüsselattribute als
unique–Werte angelegt. Das bedeutet, daß sowohl der Surrogat– als auch der Schlüsselwert
eines Objekts innerhalb seiner Tabelle eindeutig sind. Die primary key–Klausel ist eine
Möglichkeit in SQL einen Wert so auszuzeichnen, daß andere Tabellen darauf zugreifen
können. Es ist hervorzuheben, daß dieses Surrogat mit der oben gegebenen Deﬁnition eines
Surrogats nicht übereinstimmt. So soll ein Surrogat systemdeﬁniert und –kontrolliert sein.
Das hier sichtbare, manipulierbare Surrogat dient der Darstellung von Datenabhängigkeiten.
40
2.6. Relationenmodell
Zu jedem Relationshiptyp R(n1 : E1 , . . . , nm : Em ) (ohne Berücksichtigung von Relationship–Attributtypen), R ∈ R-TYPE, wird ebenfalls eine entsprechende Stammrelation
festgelegt. Der Schlüssel einer solchen Relation setzt sich aus den Schlüsseln der beteiligten Entitytypen Ei zusammen, die Surrogate Ei $ bilden somit den Schlüssel. Die Surrogate
der Entitytypen werden benutzt, um Zusammenhänge zwischen verschiedenen Entities,
im EER–Diagramm durch die Verwendung von Relationships, Typkonstruktionen oder
Komponenten dargestellt, mit möglichst geringem Aufwand darzustellen. Relationships
und mehrwertige Komponenten werden durch eigene Tabellen ausgedrückt. Diese Tabellen werden im folgenden als Datenabhängigkeiten darstellende Tabellen bezeichnet.
Bei Typkonstruktionen und einwertigen Komponenten ist lediglich die Erweiterung der
Entitytyp darstellenden Tabellen um Surrogateinträge nötig. Ohne die Verwendung von
Surrogaten müßte jeweils der eigentliche Entityschlüssel an Stelle des Surrogats in die
Tabellen aufgenommen werden. Dieses kann aber, falls sich ein Schlüssel aus mehreren
Attributen zusammensetzt, mehr Speicher kosten, als ein einzelnes Surrogatattribut.
Ein Nachteil der Surrogate ist, wie bereits erwähnt, deren Generierung und Verwaltung.
Es gibt aber Datenbanksysteme, die eine fortlaufende Erzeugung und Verwaltung von
künstlichen Werten unterstützen, die zu diesem Zweck sinnvoll ausgenutzt werden kann.
In ORACLE wird zum Beispiel für jedes in die Datenbank eingetragene Objekt eine innerhalb der Datenbank eindeutige Identiﬁkation (ID) erzeugt, vgl. [KL95]. Diese wird
in der Systemtabelle USER OBJECTS unter Object ID abgespeichert. Ob und wie diese
ID als sichtbarer Surrogatschlüssel zu nutzen ist, geht über den Rahmen dieser Arbeit
hinaus. Vorstellbar wäre, direkt nach dem Eintrag eines Objekts eine update–Operation
auf den eben erzeugten Eintrag auszuführen und dabei die Objekt–ID aus der Tabelle USER OBJECTS in die eigentliche Tabelle an Stelle eines benutzerdeﬁnierten Surrogats
einzufügen.
41
Kapitel 2. Grundlagen
42
Kapitel 3
Ein graphisches temporales
Datenmodell
In konventionellen Datenbanken wird nur der momentane Zustand von Daten festgehalten. Werden Einträge verändert, ersetzt der neue Wert den alten. In einer temporalen
Datenbank dagegen führt eine Datenveränderung im allgemeinen zu einer Einfügung neuer Daten, so daß alte Werte nicht gelöscht werden. Dieses ermöglicht die Formulierung
von Anfragen an den aktuellen Datenbankzustand, aber auch an vergangene und, wenn
Gültigkeitszeiträume angegeben werden, zukünftige Zustände.
In dieser Arbeit wird die graphische Formulierung von Anfragen an eine temporale Datenbank realisiert. Dazu wird ein Datenmodell als Grundlage benötigt: das temporale erweiterte Entity–Relationship–Modell (TEER–Modell). Das TEER–Modell nach [EWK93]
basiert auf dem EER–Modell. Das EER–Modell ist dabei um die zeitliche Dimension erweitert, womit auch zeitliche Informationen über die Daten und deren Beziehungen zueinander beschreibbar werden. Das TEER–Modell wird im zweiten Abschnitt vorgestellt.
Das TEER–Diagramm ist die graphische Umsetzung der in einem TEER–Schema enthaltenen Informationen. Es ist identisch mit dem EER–Diagramm, da sämtliche Elemente
eines TEER–Schemas zusätzlich zeitabhängig sind, die Zeit aber nicht dargestellt wird.
Ein nicht temporal abhängiges Element ist zeitinvariant. Dieses bedeutet, daß das Element
über die gesamte Lebensdauer einer Datenbank gültig ist und nicht verändert werden
kann. Auf eine Erweiterung des TEER–Modells um zeitinvariante Objekte wird verzichtet,
da sonst eine graphische Unterscheidung temporal abhängiger und unabhängiger Objekte
eingeführt werden müßte, was das Datenmodell unnötigt kompliziert. Zur Darstellung
zeitinvarianter Objekte ist es einfacher die Lebensdauer des Objekts auf die Lebensdauer
der Datenbank zu setzen.
Nach der Einführung der temporalen Standarddatentypen werden die Syntax und Semantik des TEER–Modells formuliert. Auf dem TEER–Modell basierend wird in Kapitel
4.1 eine graphische Anfragesprache deﬁniert, anschließend wiederum deren Syntax und
Semantik.
43
Kapitel 3. Ein graphisches temporales Datenmodell
3.1
Das TEER–Modell
Da im TEER–Modell nach [EWK93] und im EER–Modell dieselben Konzepte verwendet
werden, wird hier nur auf temporale Erweiterungen, die die jeweiligen Konzepte betreﬀen,
eingegangen.
Temporale Hierarchie
Im Zusammenhang mit der temporalen Korrektheit eines TEER–Modells kann man von
einer temporalen Hierarchie sprechen. Diese ergibt sich, da Entity–Attribute, Typkonstruktionen, Komponenten und Relationships nicht älter als die an ihnen beteiligten
Entities sein dürfen. Relationship–Attribute wiederum dürfen die Lebensdauer des zugehörigen Relationships nicht übersteigen.
Entity
= Eingangstyp (im Fall einer Typkonstruktion)
Typkonstruktion
Entityattribute Relationships Komponenten
Relationshipattribute
Ausgangstyp
Entityattribute
des Ausgangstyps
Relationships
Relationshipattribute
Abbildung 3.1: Die temporale Hierarchie
Darstellung der Zeit
Es sei T die abzählbar unendliche Menge von geordneten diskreten Punkten in der Zeit,
d.h. T = {t0 , t1 , . . . , tnow , tnow+1 , . . . , t∞ }. t0 bezeichnet den Entstehungszeitpunkt der Datenbank, tnow den aktuellen Zeitpunkt, der sich stetig verändert. t∞ bezeichnet den in der
unendlichen Zukunft liegenden Zeitpunkt. Der Abstand der Zeitpunkte ist von der Anwendung der Datenbank abhängig, d.h. Jahr, Monat, Tag, Stunde oder jede andere sinnvolle
Zeiteinteilung ist möglich. Ein Zeitintervall [ts , te ] ist dann eine Menge von aufeinanderfolgenden Zeitpunkten:
[ts , te ] = {ts , ts+1 , . . . , te } ⊆ T
ts ist die Start– bzw. Anfangszeit, te die Endzeit. Ein einzelner Zeitpunkt wird als Zeitintervall [t, t], oder kurz [t], dargestellt.
Ein temporales Element TE ist eine endliche Vereinigung von Zeitintervallen, d.h. eine
Menge von Zeitpunkten. Seien Ii , i = 1, . . . , n, Intervalle in T , dann gilt:
TE = I1 ∪ I2 ∪ . . . ∪ In
= {t | t ∈ I1 ∨ t ∈ I2 ∨ . . . ∨ t ∈ In }
44
3.1. Das TEER–Modell
Ein Intervall Ij ⊆ TE ist maximal in TE, wenn für alle Intervalle Ik ⊆ TE, j = k, mit
Ij ∩ Ik = ∅ gilt: Ik ⊆ Ij .
In dieser Version des TEER–Modells wird nur die Valid–Time betrachtet. Diese Zeitart
gibt den Gültigkeitszeitraum der in der Datenbank enthaltenen Daten an. Die Valid–Time
ermöglicht somit den Zugriﬀ auf aktuell gültige Daten, historische Daten und Daten, die in
der sogenannten Zukunftszeit gültig sind. Historische Daten repräsentieren einen vergangenen Zustand der Mini–Welt. Daten der Zukunftszeit beschreiben dagegen Ereignisse,
die geplant sind.
Temporaler Datenbankzustand
Der Zustand σ einer temporalen Datenbank besteht aus einer Folge von Zuständen σt ,
t ∈ T:
σ =< σt0 , σt1 , . . . , σtnow , σtnow+1 , . . . , σt∞ > .
σt ist der Zustand des Datenbankinhalts zu einem Zeitpunkt t, ein sogenannter Schnappschuß. Eine temporale Datenbank enthält für jeden Zeitpunkt t einen Schnappschuß. Der
Zustand σ besteht somit aus einer Folge von Schnappschüssen.
Entities und Entitytypen
Entities und Entitytypen stehen in der temporalen Hierarchie auf der obersten Stufe, was
bedeutet, daß an sie keine temporalen Korrektheitsbedingungen gestellt werden. Entity–
Attributtypen dagegen sind vom zugehörigen Entitytyp zeitabhängig.
Jedem Entity e vom Entitytyp E ist ein temporales Element TE(e) ⊆ [t0 , t∞ ] zugeordnet. TE(e) gibt die Lebensdauer des Entities e an. Diese kann ein Zeitintervall oder die
Vereinigung disjunkter Zeitintervalle sein.
Der zeitliche Wert eines Attributtyps Ai , das zu dem Entity e gehört, kurz Ai (e), ist die
partielle Funktion
Ai (e) : TE(e)→domain(Ai ).
Diese Funktion wird als temporale Zuordnung bezeichnet. Die Teilmenge von TE(e),
in der Ai (e) deﬁniert ist, wird als TE(Ai (e)) notiert und wird temporales Element der
temporalen Zuordnung genannt. Es wird angenommen, daß Ai innerhalb der Intervalle
TE(e) − TE(Ai (e)) unbekannt ist. Der temporale Wert eines Attributs vom Typ Ai wird
mit Ai (e)(t) bezeichnet, es ist der Wert von Ai im Zustand σt .
In einer temporalen Datenbank muß ein Schlüsselattribut(typ) A eines Entitytyps E zu
jedem Zeitpunkt t ∈ T eindeutig sein, d.h. keine zwei Entities vom Typ E dürfen denselben Wert für A zum Zeitpunkt t annehmen. Da jedes Entity das systemdeﬁnierte
Surrogat–Attribut besitzt, ist eine update–Operation auf Schlüsselattribute zulässig. Eine
update–Operation auf einer temporalen Datenbank entspricht einer insert–Operation auf
einer konventionellen Datenbank, so daß mehrere Datenbankeinträge desselben Schlüsselattributs existieren können. Der Wert des Surrogats ist eindeutig für jedes Entity in der
45
Kapitel 3. Ein graphisches temporales Datenmodell
Datenbank bestimmt. Dieser Wert ist für den Benutzer der Datenbank nicht sichtbar
und wird während der ganzen Lebensdauer des Entities nicht verändert. Das temporale
Element des Surrogats stimmt mit der Entity–Lebensdauer TE(e) überein.
Relationships und Relationshiptypen
Relationships sind von den an ihnen beteiligten Entities temporal abhängig.
Jedes Relationship r ist mit einem temporalen Element TE(r) assoziiert. TE(r) gibt die
Lebensdauer des Relationships r an. Zur Sicherung zeitlicher Korrektheit muß gelten, daß
das Relationship r nur zu einem Zeitpunkt t existieren kann, zu dem alle Entities, die zu
dieser Beziehung gehören, existieren:
TE(r) ⊆ (TE(e1 ) ∩ . . . ∩ TE(em )),
wobei die temporale Zuordnung für Relationship–Attributtypen gegeben ist durch
Ai (r) : TE(r)→domain(Ai ).
Für das temporale Element der temporalen Zuordnung gilt:
TE(Ai (r)) ⊆ TE(r).
Ai (r)(t) bezeichne den temporalen Wert des Relationship–Attributtyps Ai .
Komponenten
Eine Komponente C zu einem Entitytyp E1 mit dem Wertebereich E2 oder
set/bag/list(E2 ) besitzt als (komplex–) objektwertiges Attribut den zeitlichen Wert
C(e1 ) : TE(e1 )→domain(C).
Das temporale Element der temporalen Zuordnung ist TE(C(e1 )). Es muß gelten:
TE(C(e1 )) ⊆ TE(e1 ) und TE(C(e1 )) ⊆ TE(e2 ).
Typkonstruktionen
Es sei eine Typkonstruktion T mit den Eingangstypen E1 , . . . , En und Ausgangstypen
A1 , . . . , Am gegeben. Jedem Entity ei , aj vom Typ Ei , Aj ist ein temporales Element
TE(ei ) bzw. TE(aj ) zugeordnet, i = 1, . . . , n, j = 1, . . . , m. Zur Sicherung temporaler
Korrektheit im Rahmen einer Typkonstruktion muß gelten:
n
TE(ei ) ⊇
i=1
m
j=1
46
TE(aj )
3.2. Ein temporales Beispiel–Datenbank–Schema
3.2
Ein temporales Beispiel–Datenbank–Schema
Das EER–Schema eines Konzerns (Abbildung 2.1) aus Kapitel 2.2 kann auch temporal
interpretiert werden. Es ist dann das TEER–Modell eines Konzerns dargestellt. Graphisch
sind, wie bereits erwähnt, ein EER– und ein TEER–Diagramm nicht zu unterscheiden.
Das TEER–Schema des Konzerns stellt Informationen die Vergangenheit, Gegenwart und
Zukunft betreﬀend zu unternehmensplanerischen Zwecken zur Verfügung. Aus den Daten
lassen sich Geschäftsberichte über beliebige Zeiträume erstellen. Die Entwicklung einzelner
Abteilungen und deren Anteil am Produktionsprozeß lassen sich analysieren. Die Historie
kundenbezogener Auftragsdaten kann dazu dienen, festzustellen, welche Kunden innerhalb
der letzten Zeit weniger Aufträge als früher oder überhaupt keine vergeben haben. An
Hand der bestehenden Auslastung der vorhandenen Kapazitäten und der Auftragslage
lassen sich Unternehmenszukäufe planen. Abteilungsstärken und deren Beteiligung am
Produktionsprozeß sind modellierbar.
Für die in dieser Arbeit folgenden Beispiele habe ein bestimmtes ANGESTELLTER–
Entity e mit Gültigkeitszeitraum TE(e) = [1/7/90, t∞] die unten stehenden Attributwerte.
Der temporale Wert eines Attributs Ai (e)(t) wird hierbei mittels der Notation t → Ai (e)
angegeben. Zusammenhängende Zeitpunkte mit denselben Attributwerten werden dabei
zu Intervallen zusammengefaßt. Der Abstand zwischen zwei aufeinanderfolgenden Zeitpunkten sei ein Tag, tnow sei der 31.7.97.
Surrogat(e) = {[1/7/90, t∞ ] → surrogate id}
AngName(e) = {[1/7/90, t∞ ] → Hans Müller}
PersNr.(e) = {[1/7/90, t∞ ] → 123987}
Gehalt(e) = {[1/7/90, 30/9/90] ∪ [1/4/91, 31/12/91] → 1000,
[1/1/92, 31/12/94] → 1500,
[1/1/95, 30/6/95] → 2500,
[1/7/95, 31/12/95] ∪ [1/4/96, 31/3/97] → 3000,
[1/1/96, 31/3/96] → 2800,
[1/4/97, tnow ] → 3500,
[1/10/97, 31/5/98] → 3800,
[1/10/90, 31/3/91] ∪ [1/6/98, t∞ ] → ⊥n }
Position(e) = {[1/7/90, 30/9/90] ∪ [1/4/91, 31/12/91] → Aushilfe,
[1/10/90, 31/3/91] → ⊥s ,
[1/1/92, 31/12/94] → Lehrling,
[1/1/95, 31/3/97] → Monteur,
[1/4/97, tnow ] → stellv. Abteilungsleiter,
[1/6/98, t∞ ] → Abteilungsleiter}
3.3
TEER–Standarddatentyp–Signatur
In diesem Abschnitt werden basierend auf dem Begriﬀ der Datentyp–Signatur die Zeit–
Standarddatentypen einer temporalen Datenbank deﬁniert, in der Daten auf der Basis
eines TEER–Schemas abgespeichert werden können. Die in Kapitel 2.3.2 eingeführten
Standarddatentypen bilden zusammen mit den Zeit–Standarddatentypen die Standarddatentypen einer temporalen Datenbank.
47
Kapitel 3. Ein graphisches temporales Datenmodell
Die Zeit–Standarddatentypen des TEER–Modells sind die temporalen Datentypen date,
interval und TE type. Die temporalen Elemente sind vom Datentyp TE type. Mit Hilfe
der Listenbildung (list) und der Mengenbildung (set) werden aus dem Datentyp date
die Typen interval und TE type sowie die darauf erlaubten Operationen erzeugt. Dazu
werden die Prädikate des Typs date herangezogen, obwohl sie erst später im Text deﬁniert
werden. Die Mengenbildung wird ebenso bei der Deﬁnition verschiedener Operationen
verwendet. Die neu konstruierten Sortenausdrücke besitzen zu gegebener Interpretation
der zugrundeliegenden (vordeﬁnierten) Datentypen eine feste Interpretation.
Die TEER–Standarddatentyp–Signatur ist gegeben durch
TDT = (SORTTDT , OPNSTDT , PREDTDT ),
wobei die beteiligten Mengen wie folgt deﬁniert sind:
Jede Interpretation eines Zeit–Standarddatentyps s enthält einen sogenannten Nullwert
⊥s im Sinne von undeﬁniert”: ⊥s ∈ ISORT (s) für jedes s ∈ SORTTDT .
”
SORTTDT = SORTDT ∪ {date, interval, TE type}
mit
interval := list(date)
TE type := set(date)
OPNSTDT = OPNSDT ∪
{ −d : date, date → integer,
+d : date, date → integer,
m
: interval, . . . , interval → TE type,
int
m
int : interval, . . . , interval → interval,
m
: TE type, . . . , TE type → TE type,
TE
m
: TE type, . . . , TE type → TE type,
TE
−TE : TE type, . . . , TE type → TE type,
+TE : TE type, . . . , TE type → TE type,
firstTE : TE type → interval,
lastTE : TE type → interval,
min durationTE : TE type → interval,
max durationTE : TE type → interval }
PREDTDT =
PREDDT ∪
{ <d , >d , ≤d , ≥d , =d , =d : date, date,
beforeint , afterint , duringint , superiorint ,
equivalentint , adjacentint , overlapint : interval, interval,
beforeTE , afterTE , duringTE , superiorTE ,
equivalentTE , adjacentTE , overlapTE : TE type, TE type,
∈TE : intervalTE type }
Zu den Sorten, Operationen und Prädikaten im einzelnen:
48
3.3. TEER–Standarddatentyp–Signatur
ISORT (date) := Menge aller Kalenderdaten.
Diese Menge enthält ein Element t0 , das den Entstehungszeitpunkt der Datenbank beschreibt, ein Element tnow , das den aktuellen Zeitpunkt angibt, ein Element t∞ , das die
Zukunftszeit repräsentiert und ein Element ⊥d .
Für diesen Abschnitt habe ein Datum das Format Tag–Monat–Jahr: tag , monat , jahr
mit tag ∈ {1, . . . , 31}, monat ∈ {1, . . . , 12}, jahr ∈ {0, . . . , 9999}.
ISORT (interval) := Menge aller Zeitintervalle.
Ein Intervall I ist eine Liste von Daten. Es wird durch ein Startdatum ts und ein Enddatum te repräsentiert, wobei gilt: ts , te ∈ date, ts ≤d te . Alle Zeitpunkte, die zwischen
diesen beiden Daten liegen, gehören zum Intervall. Ein Intervall ist somit eine Menge von
aufeinanderfolgenden Zeitpunkten: I = [ts , te ] = {ts , ts+1 , . . . , te } ⊆ date.
ISORT (TE type) := Menge aller temporalen Elemente.
Ein temporales Element TE wird erzeugt durch eine endliche Vereinigung nicht notwendigerweise disjunkter Zeitintervalle. Ein temporales Element ist eine Menge von Zeitpunkten, die dann durch disjunkte Intervalle dargestellt wird. Die Informationen über die
Ausprägungen der zur Erzeugung des TE type verwendeten Intervalle gehen verloren. Sei
Ii ∈ interval ein Intervall, dann gilt:
TE = I1 ∪ I2 ∪ . . . ∪ In
= {t | t ∈ date ∧ (t ∈ I1 ∨ . . . ∨ t ∈ In )}
Kalenderdatenoperationen
IOPNS (−d ) : Diﬀerenz von Kalenderdaten (in Tagen), wobei Schaltjahre hier nicht berücksichtigt werden.
Es seien t1 , t2 ∈ date mit t1 ≥d t2 , dann ist
t1 −d t2 := s1 +i s2
mit s1 = 365 ∗ h, wobei
falls monat1 ≥i monat2 und tag1 ≥i tag2
jahr1 −i jahr2 ,
h :=
jahr1 −i jahr2 −i 1, sonst
s2 :=
hi :=
falls monat1 ≥i monat2
h1 − h2 ,
, wobei
365 + h1 − h2 , falls monat1 <i monat2
31 +
30 +
28 + ti , i = 1, 2
j∈{1,3,5,7,8,10,12}
j≤monati −1
j∈{4,6,9,11}
j≤monati −1
j=2
monati =2
IOPNS (+d ) : Addition von Kalenderdaten (in Tagen), wobei Schaltjahre hier nicht berücksichtigt werden.
Es seien t1 , t2 ∈ date, dann ist
t1 +d t2 := s1 +i s2
mit
s1 = 365 ∗ h, wobei h := jahr1 +i jahr2 ,
s2 := h1 + h2 , wobei hi , i = 1, 2, wie oben deﬁniert ist.
49
Kapitel 3. Ein graphisches temporales Datenmodell
Intervalloperationen
IOPNS ( m
int ) : m–stellige Vereinigung von Intervallen.
Es sei Ij ∈ interval, j = 1, . . . , m, dann ist
m
int
Ij :=
m
Ij := {t | t ∈ date und ∃ j mit t ∈ Ij , j = 1, . . . , m}.
j=1
IOPNS ( m
int ) : m–stelliger Durchschnitt von Intervallen.
Es sei Ij ∈ interval, j = 1, . . . , m, dann ist
m
int
Ij :=
m
Ij := {t | t ∈ date und t ∈ Ij ∀ j = 1, . . . , m}.
j=1
Operationen auf temporalen Elementen
) : m–stellige Vereinigung von temporalen Elementen.
IOPNS ( m
TE
Es sei TEj ∈ TE type, j = 1, . . . , m, dann ist
m
TE
TEj :=
m
TEj := {t | t ∈ date und ∃ j mit t ∈ TEj , j = 1, . . . , m}.
j=1
) : m–stelliger Durchschnitt von temporalen Elementen.
IOPNS ( m
TE
Es sei TEj ∈ TE type, j = 1, . . . , m, dann ist
m
TE
TEj :=
m
TEj := {t | t ∈ date und t ∈ TEj ∀ j = 1, . . . , m}.
j=1
IOPNS (−TE ) : Diﬀerenz für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann ist
TE1 −TE TE2 := {t | t ∈ date, t ∈ TE1 und t ∈ TE2 }.
IOPNS (+TE ) : Addition für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann ist
TE1 +TE TE2 := {t | t ∈ date, t ∈ TE1 oder t ∈ TE2 }.
IOPNS (firstTE ) : Ausgabe des maximalen Intervalls beginnend mit dem ersten Zeitpunkt
eines temporalen Elements.
Es sei TE ∈ TE type, dann ist
firstTE (TE) := [tp , tq ]
mit tp , . . . , tq ∈ TE und ∀ t =d tp ∈ TE : tp <d t
und ∀ t̃ >d tq ∃ t̂ ∈ TE mit tq <d t̂ <d t̃.
50
3.3. TEER–Standarddatentyp–Signatur
IOPNS (lastTE ) : Ausgabe des maximalen Intervalls endend mit dem letzten Zeitpunkt eines
temporalen Elements.
Es sei TE ∈ TE type, dann ist
lastTE (TE) := [tp , tq ]
mit tp , . . . , tq ∈ TE und ∀ t =d tq ∈ TE : tq >d t
und ∀ t̃ <d tp ∃ t̂ ∈ TE mit tp >d t̂ >d t̃.
IOPNS (min durationTE ) : Ausgabe der kürzesten maximalen Intervalle eines temporalen
Elements. Das Ergebnis dieser Funktion ist mengenwertig, da es mehrere Intervalle gleicher
kürzester maximaler Länge geben kann.
Es sei TE ∈ TE type, dann gilt
min durationTE (TE) := { [tp , tq ] | tp , . . . , tq ∈ TE
∧ ∃ [tp , tq+1 ] ⊆ TE ∧ ∃ [tp−1 , tq ] ⊆ TE
und ∀ [tk , tl ] mit tk , . . . , tl ∈ TE ist l −i k +i 1 ≥i q −i p }.
IOPNS (max durationTE ) : Ausgabe der längsten maximalen Intervalle eines temporalen
Elements. Das Ergebnis dieser Funktion ist mengenwertig, da es mehrere Intervalle gleicher
längster maximaler Länge geben kann.
Es sei TE ∈ TE type, dann gilt
max durationTE (TE) := { [tp , tq ] | tp , . . . , tq ∈ TE und ∀ [tk , tl ]
mit tk , . . . , tl ∈ TE ist l −i k +i p ≤i q −i p }.
Kalenderdatenprädikate
IPRED (<d ) : Kleiner–Relation für Kalenderdaten.
Es seien t1 , t2 ∈ date, dann gilt
t1 <d t2 ⇔ jahr1 <i jahr2
oder monat1 <i monat2 und jahr1 =i jahr2
oder tag1 <i tag2 und monat1 =i monat2 , jahr1 =i jahr2 .
IPRED (>d ) : Größer–Relation für Kalenderdaten.
Es seien t1 , t2 ∈ date, dann gilt
t1 >d t2 ⇔ jahr1 >i jahr2
oder monat1 >i monat2 und jahr1 =i jahr2
oder tag1 >i tag2 und monat1 =i monat2 , jahr1 =i jahr2 .
IPRED (=d ) : Gleich–Relation für Kalenderdaten.
Es seien t1 , t2 ∈ date, dann ist
t1 =d t2 ⇔ jahr1 =i jahr2 und monat1 =i monat2 und tag1 =i tag2 .
Entsprechend:
IPRED (≤d ) : Kleiner–gleich–Relation für Kalenderdaten.
51
Kapitel 3. Ein graphisches temporales Datenmodell
IPRED (≥d ) : Größer–gleich–Relation für Kalenderdaten.
IPRED (=d ) : Ungleich–Relation für Kalenderdaten.
Es seien t1 , t2 ∈ date, dann ist
t1 =d t2 ⇔ jahr1 =i jahr2 ∨ monat1 =i monat2 ∨ tag1 =i tag2 .
Intervallprädikate
Zur Interpretation der Prädikate auf Intervall–abhängigen Datentypen seien die Intervalle
I1 = [ts1 , te1 ], I2 = [ts2 , te2 ] ∈ interval gegeben.
IPRED (beforeint ) : liegt–vor–Relation für Intervalle.
[ts1 , te1 ] beforeint [ts2 , te2 ] ⇔ te1 <d ts2 .
IPRED (afterint ) : liegt–hinter–Relation für Intervalle.
[ts1 , te1 ] afterint [ts2 , te2 ] ⇔ ts1 >d te2 .
IPRED (duringint) : liegt–innerhalb–Relation für Intervalle.
[ts1 , te1 ] duringint [ts2 , te2 ] ⇔ ts1 ≥d ts2 ∧ te1 ≤d te2 .
IPRED (superiorint ) : liegt–über–Relation für Intervalle.
[ts1 , te1 ] superiorint [ts2 , te2 ] ⇔ ts1 ≤d ts2 ∧ te1 ≥d te2 .
IPRED (equivalentint ) : fällt–aufeinander–Relation für Intervalle.
[ts1 , te1 ] equivalentint [ts2 , te2 ] ⇔ ts1 =d ts2 ∧ te1 =d te2 .
Dieses Prädikat ist kommutativ.
IPRED (adjacentint ) : ist–benachbart–Relation für Intervalle.
[ts1 , te1 ] adjacentint [ts2 , te2 ] ⇔ ts2 −d te1 =d 1 ∨ ts1 −d te2 =d 1.
Dieses Prädikat ist kommutativ.
IPRED (overlapint ) : sich–überschneiden–Relation für Intervalle.
[ts1 , te1 ] overlapint [ts2 , te2 ] ⇔ ts1 ≤d te2 ∧ ts2 ≤d te1 .
Dieses Prädikat ist kommutativ.
52
3.3. TEER–Standarddatentyp–Signatur
Prädikate auf temporalen Elementen
IPRED (beforeTE ) : liegt–vor–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 beforeTE TE2 ⇔ ∀ t1 ∈ TE1 ∀ t2 ∈ TE2 : t1 <d t2 .
IPRED (afterTE ) : liegt–hinter–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 afterTE TE2 ⇔ ∀ t1 ∈ TE1 ∀ t2 ∈ TE2 : t1 >d t2 .
IPRED (adjacentTE ) : ist–benachbart–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 adjacentTE TE2 ⇔
∃ t1 ∈ TE1 ∀ t̃ ∈ TE1 : t1 >d t̃ ∧ ∃ t2 ∈ TE2 ∀ t̂ ∈ TE2 : t2 <d t̂ ∧ t2 −d t1 =i 1
∨ ∃ t2 ∈ TE2 ∀ t̂ ∈ TE2 : t2 >d t̂ ∧ ∃ t1 ∈ TE1 ∀ t̃ ∈ TE1 : t1 <d t̃ ∧ t1 −d t2 =i 1.
Dieses Prädikat ist kommutativ.
Durch Mengenvergleiche induzierte Prädikate:
IPRED (duringTE ) : liegt–innerhalb–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 duringTE TE2 ⇔ TE1 ⊆ TE2 .
IPRED (superiorTE ) : liegt–über–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 superiorTE TE2 ⇔ TE1 ⊇ TE2 .
IPRED (equivalentTE ) : fällt–aufeinander–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 equivalentTE TE2 ⇔ TE1 = TE2 .
Dieses Prädikat ist kommutativ.
IPRED (overlapTE ) : sich–überschneiden–Relation für temporale Elemente.
Es seien TE1 , TE2 ∈ TE type, dann
TE1 overlapTE TE2 ⇔ TE1 ∩ TE2 = ∅.
Dieses Prädikat ist kommutativ.
IPRED (∈TE ) : ist–Intervall–von–Prädikat für temporale Elemente.
Es sei I = [ts , te ] ∈ interval und TE ∈ TE type, dann ist
I ∈TE TE ⇔ ts , te ∈ TE ∧ ∀ t ts ≤ t ≤ te : t ∈ TE.
53
Kapitel 3. Ein graphisches temporales Datenmodell
Beispiel 3.1
In dem folgenden Beispiel werden einige der oben deﬁnierten Operationen und Prädikate
auf temporalen Elementen graphisch dargestellt. Dabei wird ein temporales Element durch
Angabe mehrerer Intervalle dargestellt.
1. firstTE (TE), lastTE (TE) :
Das temporale Element TE ⊆ [tk , tl ] sei durch die Intervalle Ij , j = 1, . . . , 5, gegeben, die wie folgt angeordnet sind:
I4
I1
I5
I2
I3
T
tk
tl
firstTE (TE) = I4 , da I4 das maximale Intervall ist, daß zum Zeitpunkt tk beginnt.
lastTE (TE) = I5 , da I5 das maximale Intervall ist, daß zum Zeitpunkt tl endet.
2. TE1 beforeTE TE2 :
TE1
TE2
T
3. TE1 afterTE TE2 :
TE1
TE2
T
54
3.3. TEER–Standarddatentyp–Signatur
4. TE1 adjacentTE TE2 :
TE1
TE2
T
5. TE1 duringTE TE2 :
TE1
TE2
T
6. TE1 superiorTE TE2 :
TE1
TE2
T
7. TE1 equivalentTE TE2 :
TE1
TE2
T
55
Kapitel 3. Ein graphisches temporales Datenmodell
8. TE1 overlapTE TE2 :
TE1
TE2
T
3.4
Lineare Syntax der TEER–Standarddatentyp–
Signatur
In diesem Abschnitt ist eine lineare Syntax der im vorherigen Kapitel deﬁnierten Datentypen und Prädikate angegeben. Die Angaben beschränken sich auf die später benötigten
Ausdrücke.
Formale, syntaktische Deﬁnitionen werden in der erweiterten Backus–Naur–Form (EBNF)
angegeben. Die Grundzüge dieser Notation werden zunächst beschrieben.
α, β seien Ausdrücke in EBNF.
• Terminalsymbole werden in Anführungszeichen "
" eingeschlossen.
• [α] bedeutet, daß α einmal oder keinmal auftreten darf.
• [α]∗ bedeutet, daß α beliebig oft auftreten darf.
• [α]+ bedeutet, daß α beliebig oft auftreten darf, aber mindestens einmal auftreten
muß.
• α | β bedeutet, daß entweder α oder β auftreten muß.
Die lineare Syntax der Datentypen und Prädikate ist wie folgt gegeben:
• Zahlausdruck:
integer ::= [ digit ]+
number ::= [ digit ]+ "."[ digit ]+
digit ::= "0" | "1" | ...| "9"
• Zeichenkette:
string ::= alphanum
alphanum ::= [ char digit expr ]+
char ::= "a" | ...| "z" | "A" | ...| "Z" | " "
char digit expr ::= char | digit
56
3.5. Transformation des TEER–Modells in das Relationenmodell
• Zeitintervall:
interval ::= "[" time expr "," time expr "]"
time expr ::= "null" | "now" | "infinity" | date
date ::= [ digit ] digit "/" [ digit ] digit "/"
[ digit digit ] digit digit
• temporales Element:
temp elem ::= interval | interval union
interval union ::= "{" interval [ "," interval ]+ "}"
• Prädikat:
temp pred ::=
"before" | "after" | "during" | "superior" |
"equivalent" | "adjacent" | "overlap"
pred ::= "=" | ">" | "≥" | "<" | "≤" | "="
• TEER–Modell:
teer ::= ent name [ abbrev ] [ "," ent name [ abbrev ] ]∗
[ "," rel name [ abbrev ] ]∗
[ "," typ name ]∗
[ "," comp name ]∗
ent name ::= string
rel name ::= string
typ name ::= string
comp name ::= string
abbrev ::= string
• Attributwert:
value ::= "’" string "’" | number
3.5
Die Testdatenbank – Transformation des TEER–
Modells in das Relationenmodell
Wie bereits in Kapitel 2.6.2 erklärt, ist es nicht Ziel dieser Arbeit eine Daten–Deﬁnitions–
und Manipulationssprache für eine temporale Datenbank zu entwerfen, sondern die eindeutige Deﬁnition einer graphischen Anfragesprache an eine solche Datenbank zu geben.
Um aber eine Anfragesprache benutzen zu können, muß eine entsprechende Datenbank
existieren. In diesem Abschnitt werden daher die auftretenden Probleme bei der Deﬁnition einer temporalen Datenbank in ORACLE, ein auf dem Relationenmodell basierendes
Datenbankmanagementsystem, nur aufgezeigt. Die Grundlage für spätere graphische Anfragen bildet das eingeschränkte Konzern-Schema in Abbildung 3.2. Für dieses Schema
werden die benötigten Tabellen zusammen mit Testdaten angegeben. Die entsprechenden SQL create table–Anweisungen sowie die zur Datenerzeugung benutzten insert–
Befehle sind in Anhang A aufgeführt.
57
Kapitel 3. Ein graphisches temporales Datenmodell
Darstellung der Zeit
Für die Implementierung der temporalen Testdatenbank wird ein temporales Element auf
ein Intervall eingeschränkt. Ein temporales Element ist nach Deﬁnition durch eine endliche Anzahl von Intervallen darstellbar. Für jedes dieser Intervalle sind in einer Datenbank
die Anfangs– und Endzeit abzuspeichern. Zur Abspeicherung dieser Daten werden zwei
Tabellenspalten gebraucht. Ist die Anzahl darzustellender Intervalle für alle Entities eines
Entitytyps bekannt und nicht sehr groß, können die pro Intervall benötigten Spalten direkt
an die Entitytyp–darstellende Tabelle angefügt werden. Ab einer bestimmten Anzahl von
benötigten Spalten zur Darstellung des temporalen Elements ist dieser Weg nicht mehr
sinnvoll, da die erzeugten Tabellen sehr groß und damit bei der Ergebnisausgabe auf dem
Bildschirm auch unübersichtlich werden. Eine andere Möglichkeit zur Implementierung
der temporalen Elemente ist das Anlegen einer speziellen Zeittabelle, die aus drei Spalten
besteht. Bei der Transformation des TEER–Modells in das Relationenmodell wird jeder
Entitytyp darstellenden Tabelle eine Extraspalte für Surrogatwerte hinzugefügt. Diese
Spalte ist so angelegt, daß jeder Tabelleneintrag eindeutig identiﬁzierbar ist. Über dieses
Surrogat kann dann eine Verbindung zu der zusätzlich angelegten Tabelle hergestellt werden, in der das Surrogat zusammen mit den beiden Intervalldaten abgespeichert ist. Das
Surrogat ist dann ein zeitinvarianter Wert, der in der extra angelegten Tabelle mehrfach
vorkommen darf. Die Kombination aus Surrogat und Intervalldaten muß nicht eindeutig sein, da der Wert eines Attributs innerhalb eines Zeitintervalls nicht eindeutig sein
muß. Als Beispiel sei die Telefonnummer eines Angestellten genannt. Die Zeittabellen der
Datentypabhängigkeiten–darstellenden Tabellen sind nicht auf dreispaltige Tabellen beschränkbar. An Stelle eines einzigen Surrogats ist der Surrogatschlüssel der partizipierenden Entitytypen, also der Schlüssel der Datentypabhängigkeiten darstellenden Tabellen,
abzuspeichern. Vergleicht man diese beiden Implementierungsmöglichkeiten ist oﬀensichtlich, daß der erste Weg, d.h. die Beschränkung des temporalen Elements von vornherein
auf eine feste Anzahl darstellender Intervalle, der einfachere ist. Es sind deutlich weniger
Tabellen zu erzeugen und Daten zu generieren. Um die Funktionalität der Sprache zu
testen, ist die maximale Beschränkung des temporalen Elements auf ein Intervall ausreichend. Das bedeutet, daß sämtliche Tabellen um zwei Spalten vom ORACLE-Datentyp
date zu erweitern sind. Diese Spalten bekommen die festen Namen vt from und vt to
zugewiesen. vt steht für Valid–Time, die die in dieser Version des TEER–Modells unterstützte Zeitart ist (vgl. 3.1). Die Spalte vt from enthält die Anfangszeit, vt to die
Endzeit des Gültigkeitsintervalls eines Tabelleneintrags.
58
3.5. Transformation des TEER–Modells in das Relationenmodell
Firmenname
FIRMA
⊇
(1,*)
ZULIEFERFIRMA
(1,1)
gehört
zu
abt f
(1,*)
liefert
AngName
(1,*)
PersNr
Gehalt
VORPRODUKT
.
ANGESTELLTER
Position
⊇
AbtLeiter:
p abt
.
produziert
PRODUKT
ChargenNr
(1,1)
abt p
ABTEILUNG
(1,*)
.
Mitarbeiter: set
AbtName
Auslastung
ProdName
StPreis
Abbildung 3.2: Ausschnitt des Konzern–Schemas
59
Kapitel 3. Ein graphisches temporales Datenmodell
Die Einschränkung des temporalen Elements eines beliebigen Entities auf ein Intervall
bedeutet insbesondere, daß das temporale Element des Surrogat–Attributs, welches nach
Deﬁnition jedes Entity einer temporalen Datenbank besitzt (vgl. 3.1), ebenfalls auf ein
Intervall eingeschränkt wird. Dieses Surrogat ist zeitinvariant. Es zeigt in einer Tabelle
an, welche Einträge zu einem Entity gehören. Dieses Surrogat der temporalen Datenbank
ist nicht identisch mit den zur Transformation vom EER–Modell in das Relationenmodell
einzuführenden Surrogaten (vgl. 2.6.2). Die dort besprochenen Surrogate sind temporal
abhängig und dienen dazu, Verbindungen zwischen verschiedenen Tabelleneinträgen anzuzeigen. Zur besseren Unterscheidung dieser Surrogate wird das erstere im folgenden als
zeitinvariantes Surrogat, das bei der Transformation einzuführende als temporal abhängiges Surrogat bezeichnet. Die Beschränkung auf ein Intervall zieht nach sich, daß sich die
Attribute eines Entities innerhalb seiner Lebenszeit verändern können, es somit zu mehreren Tabelleneinträgen ein Entity betreﬀend kommt, wobei sich die zugehörigen Intervalle
aber nicht überschneiden dürfen. Diese Eigenschaft wird im folgenden als temporale Korrektheit des temporalen Elements eines Entities bezeichnet.
Beispiel 3.2
Für ein ABTEILUNG–Entity e seien die folgenden Attributwerte gegeben:
Surrogat(e) = {[1/1/85, t∞ ] → surrogate id}
AbtName(e) = {[1/1/85, t∞ ] → Montage}
AbtLeiter(e) = {[1/1/85,31/12/90] → Müller,
[1/1/91,30/4/91] → Maier
[1/5/91,31/5/91] → Schulz
[1/6/91,31/12/95] → Hinz}
Das angegebene Surrogat ist das zeitinvariante Surrogat. In einer relationalen Datenbank
werden die obigen Daten in zwei Tabellen abgespeichert, da das Attribut AbtLeiter eine
Komponente ist. Die Namen sowie zugehörige Daten der Abteilungsleiter sind in einer
Tabelle Angestellter zu ﬁnden. An Stelle des Namens AbtLeiter wird in der Tabelle Abteilung ein referenzierender temporalabhängiger Surrogatwert eingetragen.
temporales zeitinvariantes
Surrogat
Surrogat
5000
995000
5012
995000
5034
995000
5222
995000
AbtLeiter
AbtName (Surrogatwert)
Montage
7018
Montage
7099
Montage
7002
Montage
7111
vt from
01-01-1985
01-01-1991
01-06-1991
01-05-1991
vt to
31-12-1990
30-04-1991
31-12-1995
31-05-1991
Tabelle 3.1: Das ABTEILUNG–Entity e
Auf die unterschiedlichen Surrogate und ihre Bedeutung sowie sich daraus ergebende
Schlüsselbedingungen für die Tabellen wird im nächsten Abschnitt eingegangen.
60
3.5. Transformation des TEER–Modells in das Relationenmodell
Surrogat– und Schlüsselattribute
Bei der Transformation eines TEER–Modells in das Relationenmodell sind, analog zur
Transformation eines EER–Modells, Surrogate einzuführen, so daß Datenabhängigkeiten
ausdrückbar werden. Diese Surrogate sind innerhalb von Entitytyp darstellenden Tabellen
als primary keys anzulegen. Zusätzlich benötigen diese Tabellen eine Spalte, die den temporalen Surrogatwert enthält (vgl. Beispiel 3.2). Diese Tabellenspalte ist als not null–Wert
anzulegen. Die Überwachung der Korrektheit des temporalen Elements ist innerhalb der
Tabellendeﬁnition nicht ausdrückbar. Dafür sind spezielle Kontrollstrukturen anzulegen,
sogenannte Trigger. Diese überprüfen nach jeder Transaktion, ob der erreichte Zustand die
gegebenen Integritätsbedingungen erfüllt. Transaktionen sind das Einfügen, Löschen und
Verändern von Tabelleneinträgen. Die Schlüsselattribute eines Entitytyps dürfen nicht,
wie bei der Transformation eines EER–Modells, als unique–Werte angelegt werden, da innerhalb einer temporalen Datenbank update–Operationen auf Schlüsselattribute erlaubt
sind. Eine update–Operation auf einen Eintrag einer temporalen Datenbank bedeutet
nicht, wie in nichttemporalen Datenbanken üblich, daß der Eintrag entsprechend den angegebenen Werten verändert wird. Es wird vielmehr ein Eintrag den angegebenen Änderungen entsprechend erzeugt und der vt from– bzw. vt to–Wert des zu verändernden
Eintrags wird neu gesetzt.
Tabellen, die Datenabhängigkeiten darstellen, enthalten kein temporales Surrogat. Sie sind
durch die nichttemporalen Surrogate mit den zugehörigen Entitytyp–Tabellen verknüpft.
Der Schlüssel einer solchen Tabelle wird aber nicht nur von den beteiligten Surrogaten
gebildet. In diesen Fällen ist der Gültigkeitszeitraum, d.h. die Werte vt from und vt to,
zum Schlüssel hinzuzunehmen. Da Relationships, Komponenten und Ausgangstypen von
Typkonstruktionen in der temporalen Hierarchie unterhalb zugehöriger Entities liegen,
können die Gültigkeitszeitintervalle in den Datenabhängigkeiten ausdrückenden Tabellen
kleiner sein oder sich auch auf mehrere disjunkte Intervalle aufteilen. Zu Überwachung
dieser Disjunktheit und der temporalen Hierarchie werden ebenfalls Trigger benötigt. Die
Tabellen 3.2 und 3.3 fassen die Unterschiede bei den Transformationen von EER– bzw.
TEER–Modellen in das Relationenmodell zusammen.
EER–Modell → Relationenmodell
eindeutige
Werte
Schlüssel
keine
Nullwerte
Schlüsselattribute
Surrogat
obligatorische Attribute
TEER–Modell → Relationenmodell
Schlüsselattribute in Verbindung
mit vt from und vt to
Surrogat
obligatorische Attribute
Schlüsselattribute
Tabelle 3.2: Entitytyp–Tabellen
EER–Modell → Relationenmodell
Schlüssel
Surrogate der beteiligten Entities
TEER–Modell → Relationenmodell
Surrogate der beteiligten Entities
zusammen mit vt from und vt to
Tabelle 3.3: Datenabhängigkeiten–darstellende Tabellen
61
Kapitel 3. Ein graphisches temporales Datenmodell
Die folgenden Tabellen bilden die Testdatenbank. Für jede Tabelle wird der zugehörige
SQL create–Befehl angegeben. Die zugehörigen insert–Anweisungen sind in Anhang A
zu ﬁnden. Sämtliche Surrogate sind als number–Werte angelegt. Das Datumsformat ist auf
4–stellige Jahresangaben erweitert worden. Der Entstehungszeitpunkt t0 dieser Datenbank
ist der 01.01.1985, t∞ wird durch das Datum 31.12.9999 dargestellt. Zeitinvariante Surrogate werden in Spalten mit dem festen Namen t inv$ abgespeichert, temporal abhängige
Surrogate in Spalten mit dem Namen E$.
Die Tabelle Firma
create table Firma (
Firma$ number not null,
t_inv$ number not null,
Firmenname varchar2(15) not null,
vt_from date not null,
vt_to date not null,
primary key (Firma$));
Firma$
1000
1001
1004
1005
1006
t inv$
991000
991001
991004
991005
991006
Firmenname
Prima
Trumpf
Zonk
Flop
Top
Anschrift
11000
11001
11004
11005
11006
Tabelle 3.4: Firma
Die Tabelle Angestellter
create table Angestellter (
Angestellter$ number unique,
t_inv$ number not null,
AngName char(15) not null,
PersNr integer not null,
Gehalt number not null,
Position char(20) not null,
vt_from date not null,
vt_to date not null,
primary key (Angestellter$));
62
vt from
01-01-1985
01-07-1985
01-09-1987
01-01-1997
01-01-1998
vt to
31-12-9999
31-12-1990
31-08-1997
31-07-1997
31-12-9999
t inv$
997000
997000
997010
997010
997015
997020
997025
997030
997035
997040
997045
997050
997050
AngName PersNr Gehalt
Hinz
312
5300
Hinz
312
6300
Mueller
234
5800
Mueller
234
6400
Schmidt
813
4000
Schiller
921
4000
Vogel
789
3800
Klein
909
4500
Gross
877
5000
Maier
987
7500
Schulz
654
6400
Kunz
717
8000
Kunz
717
8500
Position
AbtLeiter
AbtLeiter
AbtLeiter
AbtLeiter
Monteur
Monteur
Maler
Techniker
stellv. AbtLeiter
AbtLeiter
AbtLeiter
AbtLeiter
AbtLeiter
vt from
01-03-1987
01-01-1990
01-01-1985
01-01-1991
01-01-1985
01-01-1985
01-01-1990
01-01-1987
01-01-1985
01-04-1990
01-04-1989
01-07-1990
01-01-1996
Tabelle 3.5: Angestellter
vt to
31-12-1989
31-12-9999
31-12-1990
31-12-1995
31-12-1987
31-12-1995
31-12-9999
31-12-1990
31-12-9999
30-09-1995
31-12-9999
31-12-1995
31-12-9999
3.5. Transformation des TEER–Modells in das Relationenmodell
63
Ang$
7001
7002
7018
7019
7020
7025
7030
7035
7040
7099
7111
7987
7988
Kapitel 3. Ein graphisches temporales Datenmodell
Die Tabelle Abteilung
create table Abteilung (
Abteilung$ number unique,
t_inv$ number not null,
AbtName varchar2(15) not null,
AbtLeiter number not null references Angestellter(Angestellter$),
vt_from date not null,
vt_to date not null,
primary key (Abteilung$));
Abteilung$
5000
5011
5012
5034
5222
5333
t inv$
995000
995010
995000
995000
995000
995010
AbtName
Montage
Lackiererei
Montage
Montage
Montage
Lackiererei
AbtLeiter
7018
7987
7099
7002
7111
7018
vt from
01-01-1985
01-01-1996
01-01-1991
01-06-1991
01-05-1991
01-01-1991
vt to
31-12-1990
31-12-9999
30-04-1991
31-12-1995
31-05-1991
31-12-1995
Tabelle 3.6: Abteilung
Die Tabelle Produkt
create table Produkt (
Produkt$ number unique,
t_inv$ number not null,
ChargenNr number not null,
ProdName varchar2(25) not null,
StPreis number not null,
vt_from date not null,
vt_to date not null,
primary key (Produkt$));
Produkt$
4000
4001
4005
4010
4015
4020
4025
4030
4035
4040
t inv$ ChargenNr
994000
55778
994000
55778
994005
56889
994010
57911
994015
98102
994020
75432
994020
75432
994030
77641
994035
12341
994035
12341
ProdName StPreis
Rennrad
1200
Rennrad
1100
Rennrad
1150
Rennrad
1000
Rennrad
1050
Rennrad
1400
Rennrad
1700
Rennrad
1800
Rennrad
1600
Rennrad
1400
Tabelle 3.7: Produkt
64
vt from
01-01-1985
01-01-1987
01-01-1990
01-01-1991
01-09-1989
01-01-1985
01-01-1987
01-01-1990
01-01-1992
01-01-1996
vt to
31-12-1986
31-08-1987
30-06-1990
31-12-1992
31-12-9999
31-12-1986
31-12-1987
31-12-1992
31-12-1995
31-12-9999
3.5. Transformation des TEER–Modells in das Relationenmodell
Die Tabelle Mitarbeiter
create table Mitarbeiter (
Abteilung$ number not null references Abteilung(Abteilung$),
Mitarbeiter number not null references Angestellter(Angestellter$),
vt_from date not null,
vt_to date not null);
Abteilung$ Mitarbeiter
5000
7020
5000
7025
5000
7030
5000
7035
5000
7040
5011
7025
5012
7025
5034
7025
5222
7025
vt from
01-01-1985
01-01-1985
01-01-1990
01-01-1987
01-01-1985
01-01-1995
01-01-1991
01-06-1991
01-05-1991
vt to
31-12-1987
31-12-1990
31-12-9999
31-12-1990
31-12-1987
31-12-1995
30-04-1991
31-12-1994
31-05-1991
Tabelle 3.8: Mitarbeiter
Die Tabelle Zulieferfirma
create table Zulieferfirma (
Zulieferfirma$ number unique,
t_inv$ number not null,
Firma$ number not null references Firma(Firma$),
vt_from date not null,
vt_to date not null,
primary key (Zulieferfirma$));
Zulieferﬁrma$
2000
2001
2010
2011
t inv$ Firma$
992000
1000
992010
1000
992020
1004
992030
1001
vt from
01-01-1985
01-01-1991
01-09-1987
01-01-1990
Tabelle 3.9: Zulieferﬁrma
Die Tabelle Vorprodukt
create table Vorprodukt (
Vorprodukt$ number unique,
t_inv$ number not null,
65
vt to
31-08-1987
31-12-1992
31-08-1997
30-06-1990
Kapitel 3. Ein graphisches temporales Datenmodell
Produkt$ number not null references Produkt(Produkt$),
vt_from date not null,
vt_to date not null,
primary key (Vorprodukt$));
Vorprodukt$
3000
3001
3002
3003
3004
t inv$ Produkt$
993000
4010
993010
4015
993020
4005
993030
4000
993030
4001
vt from
01-01-1991
01-09-1989
01-01-1990
01-01-1985
01-01-1987
vt to
31-12-1992
31-12-9999
30-06-1990
31-12-1986
31-08-1987
Tabelle 3.10: Vorprodukt
Die Tabelle gehoert zu
create table gehoert_zu (
Firma$ number not null references Firma(Firma$),
Abteilung$ number not null references Abteilung(Abteilung$),
vt_from date not null,
vt_to date not null,
primary key (Firma$, Abteilung$, vt_from, vt_to));
Firma$ Abteilung$
1000
5000
1000
5011
1000
5012
1000
5034
1000
5222
1000
5333
1005
5011
vt from
01-01-1985
01-01-1985
01-01-1991
01-06-1991
01-05-1991
01-01-1991
01-01-1997
vt to
31-12-1990
31-12-1990
30-04-1991
31-12-1995
31-05-1991
31-12-1996
31-07-1997
Tabelle 3.11: gehoert zu
Die Tabelle produziert
create table produziert (
Produkt$ number not null references Produkt(Produkt$),
Abteilung$ number not null references Abteilung(Abteilung$),
Auslastung number not null,
vt_from date not null,
vt_to date not null,
primary key (Produkt$, Abteilung$, vt_from, vt_to));
66
3.5. Transformation des TEER–Modells in das Relationenmodell
Produkt$ Abteilung$ Auslastung
4000
5000
75
4005
5000
82
4010
5000
89
4010
5012
73
4010
5034
70
4010
5222
69
4015
5000
72
4015
5011
91
4015
5012
73
4015
5034
75
4015
5222
40
vt from
01-01-1985
01-01-1990
01-01-1990
01-01-1991
01-06-1991
01-05-1991
01-09-1989
01-01-1996
01-01-1991
01-06-1991
01-05-1991
vt to
31-12-1986
30-06-1990
31-12-1990
30-04-1991
31-12-1992
31-05-1991
31-12-1990
31-12-9999
30-04-1991
31-12-1995
31-05-1991
Tabelle 3.12: produziert
Die Tabelle liefert
create table liefert (
Zulieferfirma$ number not null references Zulieferfirma(Zulieferfirma$),
Vorprodukt$ number not null references Vorprodukt(Vorprodukt$),
vt_from date not null,
vt_to date not null,
primary key (Zulieferfirma$, Vorprodukt$, vt_from, vt_to));
Zulieferﬁrma$ Vorprodukt$
2000
3003
2000
3004
2001
3000
2010
3001
2011
3002
vt from
01-01-1985
01-01-1987
01-01-1991
01-09-1989
01-01-1990
Tabelle 3.13: liefert
67
vt to
31-12-1986
31-08-1987
31-12-1992
31-08-1997
30-06-1990
Kapitel 3. Ein graphisches temporales Datenmodell
68
Kapitel 4
Die TEER–Anfragesprache
4.1
Eine graphische temporale Anfragesprache
Der Sinn einer graphischen Datenbank–Anfragesprache ist, die Nutzung der Datenbank
auch Anwendern zu ermöglichen, die keine speziellen fachlichen Vorkenntnisse besitzen. Die Basis der graphischen TEER–Datenbank–Anfragesprache bildet ein TEER–
Diagramm. Dieses Diagramm kann mit Hilfe eines Editors in eine Anfrage transformiert
werden, die einen zeitlichen Bezug hat. Die zugrundeliegende Datenbank muß das dargestellte Datenmodell mit zugehörigen Daten enthalten. Im folgenden werden zunächst
Konstrukte der TEER–Anfragesprache vorgestellt. Anschließend werden der Anfrageeditor und die Formulierung von Anfragen beschrieben. Desweiteren wird eine lineare Syntax
der graphischen Elemente deﬁniert. In Anhang B ist diese in übersichtlicher Form zu ﬁnden. Die TEER–Anfragesprache basiert auf einem Vorschlag in [KG95].
Für Datentypen und darauf deﬁnierte Prädikate gelte die lineare Syntax aus Kapitel 3.4.
Alle Beispiele dieses Kapitels beziehen sich auf das temporale Konzern–Schema aus Kapitel 3.2, das in Abbildung 2.1 dargestellt ist. In den Beispielanfragen wird durchgehend das
temporale Prädikat during benutzt. Bei der umgangssprachlichen Formulierung dieser graphischen Anfragen ist versucht worden auszudrücken, daß das Prädikat during nur dann
den Wert true zurückgibt, wenn eine totale liegt–in Beziehung gegeben ist. Das bedeutet,
daß during überlappende Intervalle nicht als ineinanderliegende Intervalle erkennt“.
”
Im Anhang D wird das Programm TEER–Anfrage–Editor vorgestellt, daß die graphische
Formulierung von Anfragen ermöglicht. Diese Implementierung eines Anfrageeditors realisiert die in diesem Kapitel vorgeschlagenen Gestaltungsmöglichkeiten teilweise in anderer
Form. An Stelle der graphischen Unterscheidung von Elementen durch verschiedene Formen bzw. Liniendarstellungen nutzt der TEER–Anfrage–Editor die Möglichkeit der farblichen Unterscheidung und stellt insbesondere keine gestrichelten Linien dar.
4.1.1
Konstrukte der TEER–Anfragesprache
Mit Hilfe einer Anfrage an eine nichttemporale Datenbank werden Entities auf Grund boolescher Prädikate selektiert. Diese Prädikate werden auf die Attributwerte eines Entities
oder auf die Attributwerte von zueinander in Beziehung stehenden Entities angewendet.
69
Kapitel 4. Die TEER–Anfragesprache
Als Ergebnis einer solchen Anfrage werden dann ausgewählte Attribute und Relationships
jedes selektierten Entities ausgegeben. In einer temporalen Datenbank dagegen muß sich
eine Selektionsbedingung nicht nur auf Attributwerte beziehen, sondern kann auch temporale Bedingungen beinhalten. Zusätzlich besteht die Möglichkeit, die gesamte Historie
der Attribute oder Relationships eines selektierten Entities auszugeben oder die Ausgabe auf einen bestimmten Zeitraum einzuschränken. Zur Konstruktion solcher temporaler
Anfragen werden neue Anfrage–Konstrukte benötigt. Dazu werden zunächst die Konzepte des temporalen booleschen Ausdrucks, des Gültigkeitszeitraums einer Bedingung, der
temporalen Selektion sowie der temporalen Projektion deﬁniert.
Temporaler boolescher Ausdruck
Ein temporaler boolescher Ausdruck stellt eine Bedingung an die Attribute und Relationships eines Entities dar. Die Anwendung einer booleschen Bedingung b auf ein Entity e
bedeutet eine temporale Zuordnung
b(e) : TE(e) → {true, false, ⊥b }.
Für die Formulierung eines temporalen booleschen Ausdrucks bool expr bzgl. der Attributtypen attr name gilt die nachfolgende Syntax. Die Attributtypen können verschieden
sein. Sie müssen aber entweder dem Entitytypen angehören oder einem der Relationshiptypen, die mit dem Entitytyp verbunden sind. Die Bezeichnung attr name repräsentiert
die Namen von Attributtypen. Existieren Attributtypen gleichen Namens verschiedener
Entity– oder Relationshiptypen, kann dem Typnamen eine Abkürzung abbrev zugeordnet
werden. Der Attributtyp wird dann mit abbrev"."attr name angegeben.
bool expr ::= "(" attr expr [ bool op attr expr ]∗ ")"
attr expr ::= [ "not" ] attr cond
attr cond ::= attr name pred value
bool op ::= "and" | "or"
Beispiel 4.1
Der boolesche Ausdruck Position = ’Monteur’ and Gehalt = 3000 liefert, bezogen auf
das ANGESTELLTER–Entity, die folgende Menge temporaler Zuordnungen:
{ [1/7/90, 30/9/90] → false,
[1/10/90, 31/3/91] → false,
[1/4/91, 31/12/91] → false,
[1/1/92, 31/12/94] → false,
[1/1/95, 30/6/95] → false,
[1/7/95, 31/12/95] → true,
[1/1/96, 31/3/96] → false,
[1/4/96, 31/3/97] → true,
[1/4/97, tnow ] → false,
[1/10/97, 31/5/98] → false,
[1/6/98, t∞ ] → false }
70
4.1. Eine graphische temporale Anfragesprache
Gültigkeitszeitraum eines booleschen Ausdrucks
Der Gültigkeitszeitraum [[b]] eines booleschen Ausdrucks b(e) besteht aus temporalen Elementen. Diese temporalen Elemente gehören zu denjenigen Entities e, die auf Grund der
Bedingung b(e) selektiert werden. Somit ist der Gültigkeitszeitraum die Zeit, in der der
boolesche Ausdruck b(e) den Wert true annimmt.
Die Syntax eines Gültigkeitszeitraums eines booleschen Ausdrucks true time ist gegeben
durch:
true time ::= "[[" bool expr "]]"
Beispiel 4.2
Der Gültigkeitszeitraum der obigen booleschen Bedingung Position = ’Monteur’ and Gehalt = 3000 (siehe Beispiel 4.1) ist somit {[1/7/95, 31/12/95], [1/4/96, 31/3/97]}.
Temporale Selektion
Eine temporale Selektion vergleicht zwei temporale Elemente mit Hilfe eines beliebigen
Prädikats der Menge PREDTDT . Eines der beiden temporalen Elemente ist ein Gültigkeitszeitraum eines booleschen Ausdrucks. Das zweite temporale Element ist entweder
konstant oder das Ergebnis einer Unteranfrage.
Eine Kurznotation für eine temporale Selektion ist:
temp seltrue
time temp pred cal temp elem (typ),
wobei true time der Gültigkeitszeitraum eines booleschen Ausdrucks ist. cal temp elem
ist ein konstantes, direkt angegebenes temporales Element oder das Ergebnis einer Unteranfrage. temp pred ist eines der zugelassenen Prädikate. typ ist ein Bezeichner für einen
Entity– oder Relationshiptypnamen.
Beispiel 4.3
Die Selektion
tempsel[[(P osition= M onteur )
and (Gehalt=3000)]] ⊆[1/1/95,31/12/95]
(ANGEST ELLT ER)
liefert alle Entities, die im Jahr 95 Monteur waren und 3000 DM verdient haben. Diese
Bedingung wird für jedes einzelne ANGESTELLTER–Entity berechnet und liefert entweder eine true– oder eine false–Antwort. Alle Entities, deren Antwort true ist, werden
ausgegeben.
Die Syntax einer temporalen Selektion hat folgendes Aussehen:
temp sel ::= true time temp pred cal temp elem
cal temp elem ::= temp elem | get time
Die Syntax der Unteranfrage get time wird auf Seite 82 angegeben. Diese Möglichkeit
wird schon hier der Vollständigkeit wegen angegeben.
71
Kapitel 4. Die TEER–Anfragesprache
Temporale Projektion
Eine temporale Projektion wird auf ein TEER–Schema, d.h. auf eine Menge von Entity–,
Relationship– und Attributtypen, angewendet. Sie schränkt alle temporalen Zuordnungen
(Attribute und Relationships) für die im TEER–Schema vorkommenden Entities auf ein
temporales Element ein.
Die Notation einer Projektion ist gegeben durch:
temp projtemp
pred temp elem proj (teer),
wobei temp pred eines der Prädikate der Menge PREDTDT ist. temp elem proj ist ein temporales Element, das direkt angegeben wird und ein Gültigkeitszeitraum eines booleschen
Ausdrucks oder das Ergebnis einer Unteranfrage ist. teer ist das TEER–Schema.
Beispiel 4.4
Wird das ANGESTELLTER–Entity auf den Zeitraum [21/3/94,12/1/95] projiziert,
temp projduring
[21/3/94,12/1/95] (ANGESTELLTER),
werden die Attribute für dieses Entity auf die folgenden Werte eingeschränkt:
Surrogat(e) = {[21/3/94,12/1/95] → surrogate id}
AngName(e) = {[21/3/94,12/1/95] → Hans Müller}
PersNr(e) = {[21/3/94,12/1/95] → 123987}
Gehalt(e) = {[21/3/94,31/12/94] → 1500,
[1/1/95,12/1/95] → 2500}
Position(e) = {[21/3/94,31/12/94] → Lehrling,
[1/1/95,12/1/95] → Monteur}
Die Syntax einer temporalen Projektion ist folgende:
temp proj ::= teer temp pred temp elem proj
temp elem proj ::= temp elem | true time | "(" get time ")"
Der Bezeichner teer repräsentiert ein syntaktisch korrektes TEER-Diagramm.
Die Syntax der Unteranfrage get time ist auf Seite 82 zu ﬁnden.
4.1.2
Anfrageeditor
Das TEER–Diagramm, auf dem die TEER–Anfragesprache basiert, repräsentiert eine
Mini–Welt. Bei Anfragen diese Mini–Welt betreﬀend sind nicht unbedingt alle Entity–,
Relationship– und Attributtypen von Interesse, so daß eine Auswahlmöglichkeit bestehen
muß. Die zur Verfügung stehenden Operatoren werden in diesem Abschnitt vorgestellt.
Der Remove–Operator
Durch Löschen von Attribut–, Relationship– und Entitytypen, an denen der Benutzer
nicht interessiert ist, wird aus dem TEER–Diagramm ein Arbeitsdiagramm erzeugt.
72
4.1. Eine graphische temporale Anfragesprache
Der Duplicate–Operator
Ausschnitte des Arbeitsdiagramms können mit Hilfe des Duplicate–Operators kopiert
werden.
4.1.3
TEER–Datenbank–Anfragesprache
Die TEER–Anfragesprache ermöglicht nach Modellierung eines TEER–Diagramms im
Editor die graphische Formulierung von zeitlichen und nichtzeitlichen Bedingungen sowie
von Unteranfragen.
Ein TEER–Diagramm wird, falls nötig, zunächst durch wiederholtes Anwenden des
Remove–Operators in ein Arbeitsdiagramm umgewandelt. Wenn die Anfrage Unteranfragen enthalten soll, so muß der Duplicate–Operator auf den minimalen Teil des Diagramms
angewendet werden, der die betroﬀenen Entity–, Relationship– und Attributtypen enthält.
Als nächstes wird die Unteranfrage formuliert. Dieses entspricht der Formulierung einer
Anfrage, wie unten beschrieben, an den kopierten Diagrammteil. Da das Ergebnis dieser Unteranfrage für die Formulierung der übergeordneten Anfrage benötigt wird, muß
der sogenannte Query–result–link benutzt werden. Zunächst werden aber der Get– und
der Restrict–Operator eingeführt, mit deren Hilfe Elemente für eine Ergebnismenge ausgewählt und durch Bedingungen eingeschränkt werden können.
Der Restrict–Operator
Der Restrict–Operator ermöglicht es, boolesche Bedingungen für Attribute von Entity–
und Relationshiptypen anzugeben. Die Bedingungen werden in einer sogenannten condition box formuliert. Die logische UND–Verknüpfung der condition boxes ergibt den
Restrict–Operator. Dabei dürfen in einer condition box nur Bedingungen an die Attribute eines gemeinsamen Entity– oder Relationshiptyps formuliert werden. Durch eine
ungerichtete Kante ist die condition box mit dem zugehörigen Typ verbunden.
E
bool_expr
....
Abbildung 4.1: Beispiel einer condition box
Lineare Syntax des Restrict–Operators:
restrict attr ::= "(" bool expr ")" [ "and"
"(" bool expr")" ]∗
Der Get–Operator
Alle Attributtypen, deren Attributwerte als Anfrageergebnis ausgegeben werden sollen,
werden mit einem Stern (*) markiert. Die Zugehörigkeit der Attributtypen zu ein und
73
Kapitel 4. Die TEER–Anfragesprache
demselben Entity– oder Relationshiptyp wird hier nicht gefordert. Diese Operation entspricht somit einem linearen Befehl
get op ::= "get" attr list "from" teer
attr list ::= attr name [ "," attr name ]∗
Beispiel 4.5
Welche Produkte werden von der Abteilung ’Montage’ der Firma ’Prima’ produziert ?“
”
FIRMA
Firmenname = ’Prima’
gehört
zu
AbtName = ’Montage’
ABTEILUNG
produziert
*
ChargenNr
PRODUKT
*
ProdName
Der Query–result–link–Operator
Der Query–result–link kombiniert eine Anfrage mit einer Unteranfrage. Das Ergebnis der
Unteranfrage wird an eine explizit anzugebende Variable gebunden. Der Typ dieser Variablen ist entsprechend dem Typ des Unteranfrageergebnisses. Damit kann das Unteranfrageergebnis an die übergeordnete Anfrage weitergeleitet werden. Das Unteranfrageergebnis
kann aus einer Menge von Werten desselben Attributtyps bestehen. Die Variable wird in
der übergeordneten Anfrage direkt demjenigen Attributtyp der übergeordneten Anfrage
zugeordnet, der mit dem Ergebnis der Unteranfrage verglichen werden soll. Die Attributtypen der beiden Anfragen müssen dabei sortenmäßig zusammenpassen. Der anzugebende
Vergleichsoperator Θ setzt sich aus einem Operator θ ∈ {<, >, =, ≤, ≥, =} und einem der
Wörter all oder any zusammen. Bei der Verwendung von Θ = θall muß ein Ergebniswert
74
4.1. Eine graphische temporale Anfragesprache
den Vergleich θ mit allen Mengenelementen erfüllen. Bei der Benutzung von Θ = θany
reicht aus, wenn der Ergebniswert den Vergleich θ bezüglich eines Mengenelements erfüllt.
Graphisch wird die Weiterleitung des Unteranfrageergebnisses durch eine gerichtete Kante
zwischen den sortenmäßig passenden Attributtypen der Unteranfrage und der übergeordneten Anfrage dargestellt. Die Kante ist mit der Variablen beschriftet. Die Variable wird
dann in der Anfrage zur Formulierung von Bedingungen unter der Verwendung des Vergleichsoperators Θ weiterbenutzt.
Ej
Aj Θx
x
x := Ai
Ei
....
....
Unteranfrage
übergeordnete Anfrage
Abbildung 4.2: Der Query–result–link bzgl. Entity–Attributen
Die lineare Syntax des Query–result–link–Operators ist gegeben durch:
result link ::= attr name pred all any choice "(" get result ")"
all any choice ::= "all " | "any "
get result ::= get result op [ "restrict" restrict attr ]
get result op ::= "get" attr name "from" teer
Beispiel 4.6
Welche Personen verdienen mehr, als das Produkt ’Rennrad’ kostet ?“
”
AngName
PersNr
PRODUKT
StPreis =: x
x
*
*
*
ANGESTELLTER
Gehalt >all x
ProdName = ’Rennrad’
Der temporale Projektionsoperator
Der temporale Projektionsoperator ermöglicht die Einschränkung aller temporaler Zuordnungen (Attribute und Relationships) eines Entities auf einen bestimmten Zeitraum.
75
Kapitel 4. Die TEER–Anfragesprache
Dieser Operator wird auf ein TEER–Diagramm, also eine Gruppe von Entities, angewendet.
Entity–, Relationship– und Attributtypen, auf die eine temporale Projektion ausgeführt
werden soll, werden mit Hilfe eines gestrichelten Kastens umrandet. Ein Pfeil ordnet diesem Kasten das temporale Element temp elem proj zu. Dieser Pfeil wird mit dem Namen
des Prädikats temp pred beschriftet.
teer
temp_pred
temp_elem_proj
Abbildung 4.3: Die temporale Projektion temp projtemp
pred temp elem proj (teer)
Temporale Projektionen auf Unteranfragen oder Teile des Arbeitsdiagramms sind nicht
erlaubt. Das Verbot der temporalen Projektion auf Unteranfragen stellt sicher, daß die
durch die Projektion beschriebene temporale Einschränkung nur auf bereits durch den
Get–Operator ausgewählte Entities ausgeführt wird. Diese ausgewählten Entities erfüllen
bereits die mit Hilfe des Restrict–Operators formulierten Bedingungen. Die Aufgabe der
temporalen Projektion ist somit die Ausgabemenge auf einen Zeitraum einzuschränken.
Desweiteren muß sichergestellt sein, daß eine in teer formulierte Anfrage komplett innerhalb eines Zeitraums ausgewertet wird. Ansonsten ist es möglich, daß zwei durch ein
Relationship verbundene Entities in einem Ergebnistupel ausgegeben werden, aber nicht
im selben Zeitraum gültig sind. Projektionen auf Teile des Arbeitsdiagramms sind daher
nicht zulässig. Eine Projektion wird also immer auf das TEER–Schema teer angewendet,
auf das der Get–Operator angewendet wird. Die Angabe teer ist daher in der linearen
Syntax optional.
Die lineare Syntax einer temporalen Projektion ist gegeben durch:
temp proj ::= [ "(" teer ")" ] temp pred temp elem proj
76
4.1. Eine graphische temporale Anfragesprache
Beispiel 4.7
Wie teuer waren die Vorprodukte der Firma ’Prima’, die genau innerhalb des Zeitraums
”
vom 1/1/91 bis 31/12/91 produziert wurden ?“
Firmenname = ’Prima’
FIRMA
⊇
ZULIEFERFIRMA
during
[1/1/91, 31/12/91]
liefert
VORPRODUKT
⊇
PRODUKT
*
ChargenNr
*
*
ProdName
StPreis
Das Anfrageergebnis besteht aus denjenigen Datensätzen, die die Bedingungen des
Restrict–Operators zu bestimmten Zeitpunkten erfüllen. Ein solcher Zeitpunkt muß innerhalb des Zeitraums liegen, der durch das Prädikat temp pred und das temporale Element
temp elem proj speziﬁziert wird.
Soll an Stelle eines festen, vom Benutzer angegebenem Zeitraums das Anfrageergebnis auf
einen von einer Bedingung abhängigen Zeitraum eingeschränkt werden, dem Gültigkeitszeitraum eines booleschen Ausdrucks, so ist dieses mit Hilfe des True–time–Operators
77
Kapitel 4. Die TEER–Anfragesprache
möglich. Die zu berechnenden Zeiträume werden mittels des temporalen Projektionsoperators in die Anfrage eingebunden. Dafür wird die dortige Zeitangabe durch den die
True–time bestimmenden Kasten ersetzt.
Der True–time–Operator
Der True–time–Operator ermöglicht die Bestimmung von Gültigkeitszeiträumen von booleschen Ausdrücken. Die Bedingungen dürfen dabei nur an einen einzelnen Entity– oder
Relationshiptyp gestellt werden. Daher sind die berechneten Zeiträume für jedes Entity
oder Relationship verschieden. Die Formulierung der Bedingungen geschieht in einem Kasten mit doppelten Seitenstrichen. Die lineare Syntax des True–time–Operators ist, wie
bereits deﬁniert:
true time ::= "[[" bool expr "]]"
Zur Bestimmung von Zeiträumen, in denen Bedingungen von verschiedenen Entity– oder
Relationshiptypen erfüllt sein sollen, steht der Time–link–Operator (siehe S. 81) zur
Verfügung. Der True–time–Operator ist eine Abkürzung des Time–link–Operators für den
Fall, daß sich die zu erfüllenden Bedingungen nur auf einen Entity– oder Relationshiptyp
beziehen.
temp_pred
teer
bool_expr
Abbildung 4.4: Der True–time–Operator in Verbindung mit einer temporalen Projektion
Beispiel 4.8
Welche Produkte werden von welcher Abteilung genau in den Zeiträumen produziert, in
”
denen die Auslastung mindestens einer Abteilung über 80% liegt ?“
PRODUKT
ABTEILUNG
produziert
*
ProdName
during
Auslastung > 80
78
*
AbtName
4.1. Eine graphische temporale Anfragesprache
Bei der Bearbeitung dieser Anfrage wird auf jeden selektierten Datensatz eine Menge
von Zeitintervall projiziert. Diese Menge besteht aus denjenigen Zeiträumen, in denen
die Auslastung einer beliebigen Abteilung bei der Produktion eines beliebigen Produkts
größer als 80% ist.
Eine zeitliche Auswahl kann aber auch aufgrund temporaler Bedingungen an Attribute
getroﬀen werden. Dieses ermöglicht der temporale Selektionsoperator.
Der temporale Selektionsoperator
Mit Hilfe des temporalen Selektionsoperators werden Entities aufgrund temporaler Bedingungen an Attribute ausgewählt. Eine temporale Selektion wird nicht auf das gesamte
Arbeitsdiagramm angewendet, sondern nur auf einen Teil: denjenigen Entity– oder Relationshiptyp, zu dem die Attribute, auf die der True–time–Operator angewendet wird,
gehören. Graphisch hat eine temporale Selektion die Form:
temp_pred
E
bool_expr
cal_temp_pred
....
Abbildung 4.5: Die temporale Selektion temp seltrue
time temp pred cal temp elem (E)
Die lineare Syntax einer temporalen Selektion ist, wie bereits deﬁniert:
temp sel ::= true time temp pred cal temp elem
79
Kapitel 4. Die TEER–Anfragesprache
Beispiel 4.9
Welche Angestellten arbeiten für wieviel Gehalt in derjenigen Abteilung, die innerhalb
”
des Zeitraums vom 1/1/91 bis 30/6/91 ’Montage’ hieß ?“
AngName
PersNr
*
*
*
ANGESTELLTER
Gehalt
AbtLeiter:
ABTEILUNG
Mitarbeiter: set
during
AbtName = ’Montage’
[1/1/91, 30/6/91]
Diese Anfrage liefert die Personalnummer, den Namen sowie das Gehalt aller Angestellten,
die jemals in der entsprechenden Abteilung gearbeitet haben, bzw. arbeiten werden. Soll
die Ergebnismenge auf einen bestimmten Zeitraum eingeschränkt werden, muß auf die
obige Anfrage 4.9 eine temporale Projektion angewendet werden.
80
4.1. Eine graphische temporale Anfragesprache
Beispiel 4.10
Welche Angestellten arbeiteten innerhalb des Zeitraums vom 1/1/95 bis 31/1/95 für wie”
viel Gehalt in derjenigen Abteilung, die innerhalb des Zeitraums vom 1/1/91 bis 30/6/91
’Montage’ hieß ?“
AngName
PersNr
*
*
*
ANGESTELLTER
Gehalt
AbtLeiter:
ABTEILUNG
Mitarbeiter: set
during
AbtName = ’Montage’
[1/1/91, 30/6/91]
during
[1/1/95, 31/1/95]
In der TEER–Anfragesprache existiert die Möglichkeit, Zeiträume als Anfrageergebnis auszugeben. Dieses ermöglicht der Time–link–Operator. Seine zweite Anwendungsmöglichkeit ﬁndet dieser Operator im Rahmen einer temporalen Projektion oder
Selektion. Hierbei wird das berechnete temporale Element nicht ausgegeben, sondern an
einer weitere Datenbankanfrage weitergeleitet.
Der Time–link–Operator
Mit Hilfe des Time–link–Operators wird ein temporales Element berechnet. Es wird entweder als Eingabe an eine übergeordnete Anfrage weitergeleitet oder direkt als Anfrageergebnis ausgegeben. Graphisch besteht dieser Operator aus einem gestrichelten Kasten,
der das gesamte Arbeitsdiagramm umfaßt, sowie einer gerichteten Kante. Diese Kante,
die vom Kasten ausgeht, ist an ihrem Startpunkt mit der Vorschrift "get time" beschriftet. Die gerichtete Kante endet entweder graphisch im Nichts oder an einem temporalen
Vergleichsoperator. Das graphische Nichts bewirkt die Ausgabe des berechneten temporalen Elements. Der temporaler Vergleichsoperator bewirkt, daß das berechnete temporale
81
Kapitel 4. Die TEER–Anfragesprache
Element an eine weitere Anfrage geleitet wird. Dazu wird das Kantenende mit einem
Prädikatnamen beschriftet, der die gewünschte temporale Projektion oder Selektion angibt.
get_time
teer
Abbildung 4.6: Time–link
teer
get_time
temp_pred
teer’
Abbildung 4.7: Time–link im Rahmen einer temporalen Projektion
Da der Time–link–Operator eine Unteranfrage darstellt, ist eine temporale Projektion auf
das TEER–Schema teer nicht zugelassen.
Die lineare Syntax des Time–Links get time ist gegeben durch:
get time ::=
"get time" "from" teer
[ "restrict" restrict attr ] [ temp sel expr ]
temp sel expr ::= "time condition of" ent rel name "is" temp sel
Der Bezeichner ent rel name repräsentiert einen Entity– oder Relationshiptypnamen.
82
4.1. Eine graphische temporale Anfragesprache
Beispiel 4.11
Wann ist Müller Leiter der Abteilung ’Montage’ ?“
”
ANGESTELLTER
AngName = ’Müller’
get time
AbtLeiter:
ABTEILUNG
AbtName = ’Montage’
83
Kapitel 4. Die TEER–Anfragesprache
Die nächste Anfrage enthält zusätzlich zum Time–link noch einen Vergleichsoperator. Der
Time–link–Operator liefert in diesem Beispiel das temporale Element für eine Projektion.
Beispiel 4.12
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem Müller
”
Leiter der Abteilung ’Montage’ ist ?“
AngName = ’Müller’
ANGESTELLTER
AbtLeiter:
ABTEILUNG
AbtName = ’Montage’
get time
during
ANGESTELLTER
*
AngName
*
PersNr
*
Position
Syntax einer Anfrage
Die Syntax einer Anfrage query an ein TEER–Modell teer ist gegeben durch:
query ::= get attr | get time
get attr ::=
get op [ restrict expr ]
[ temp sel expr ] [temp proj expr ]
restrict expr ::= "restrict" "(" restrict attr ")" |
"restrict" result link |
"restrict" "(" restrict attr "and" result link ")"
temp proj expr ::= "project" temp proj
Die Syntax der TEER–Datenbank–Anfragesprache ist zusammengefaßt im Anhang B zu
ﬁnden.
84
4.1. Eine graphische temporale Anfragesprache
Es folgen als Beispiele die obigen in graphischer Form gegebenen Anfragen in linearer
Schreibweise:
Beispiel 4.13
1. Beispiel 4.5:
Welche Produkte werden von der Abteilung ’Montage’ der Firma ’Prima’ produ”
ziert ?“
get ChargenNr, ProdName
from FIRMA, ABTEILUNG, PRODUKT, gehört zu, produziert
restrict ((Firmenname = ’Prima’) and (AbtName = ’Montage’))
2. Beispiel 4.6:
Welche Personen verdienen mehr, als das Produkt ‘Rennrad’ kostet ?“
”
get AngName, PersNr, Gehalt
from ANGESTELLTER
restrict Gehalt > all (get StPreis
from PRODUKT
restrict (ProdName = ’Rennrad’))
3. Beispiel 4.7:
Wie teuer waren die Vorprodukte der Firma ’Prima’, die genau innerhalb des Zeit”
raums vom 1/1/91 bis 31/12/91 produziert wurden ?“
get ChargenNr, ProdName, StPreis
from FIRMA, ZULIEFERFIRMA, VORPRODUKT, PRODUKT, liefert, ⊇, ⊇
restrict ((Firmenname = ’Prima’))
project during [1/1/91, 31/12/91]
4. Beispiel 4.8:
Welche Produkte werden von welcher Abteilung genau in den Zeiträumen produ”
ziert, in denen die Auslastung mindestens einer Abteilung über 80% liegt ?“
get ProdName, AbtName
from PRODUKT, ABTEILUNG, produziert
project during [[ Auslastung > 80 ]]
5. Beispiel 4.9:
Welche Angestellten arbeiten für wieviel Gehalt in derjenigen Abteilung, die inner”
halb des Zeitraums vom 1/1/91 bis 30/6/91 ’Montage’ hieß ?“
get PersNr, AngName, Gehalt
from ANGESTELLTER, ABTEILUNG, AbtLeiter, Mitarbeiter
time condition of ABTEILUNG is [[ AbtName = ’Montage’ ]]
during [1/1/91, 30/6/91]
85
Kapitel 4. Die TEER–Anfragesprache
6. Beispiel 4.10:
Welche Angestellten arbeiteten innerhalb des Zeitraums vom 1/1/95 bis 31/1/95
”
für wieviel Gehalt in derjenigen Abteilung, die innerhalb des Zeitraums vom 1/1/91
bis 30/6/91 ’Montage’ hieß ?“
get PersNr, AngName, Gehalt
from ANGESTELLTER, ABTEILUNG, AbtLeiter, Mitarbeiter
time condition of ABTEILUNG is [[ AbtName = ’Montage ]]
during [1/1/91, 30/6/91]
project during [1/1/95, 31/1/95]
7. Beispiel 4.11:
Wann ist Müller Leiter der Abteilung ’Montage’ ?“
”
get time from ABTEILUNG, ANGESTELLTER, AbtLeiter
restrict ((AbtName = ’Montage’) and (AngName = ’Müller’))
8. Beispiel 4.12:
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem
”
Müller Leiter der Abteilung ’Montage’ ist ?“
get AngName, PersNr, Position
from ANGESTELLTER ang
project during (get time from ABTEILUNG, ANGESTELLTER a
restrict ((a.AbtName = ’Montage’) and
(a.AngName = ’Müller’)))
4.2
Der TEER–Kalkül
Der TEER–Kalkül ist ein temporal erweiterter EER–Kalkül (Kapitel 2.5). Die temporale
Erweiterung besteht darin, daß sich die Kalkülausdrücke auf einen Zeitpunkt beziehen
können. Eine Umwandlung dieser Zeitpunkte in temporale Elemente wird nicht betrachtet. Daher ist die Menge der zugelassenen umgangssprachlichen temporalen Prädikate
einzuschränken. Dieser Punkt wird unten ausführlich diskutiert.
Die Begriﬀe Term, Atomare Formel und Formel (Deﬁnitionen 2.7, 2.9, 2.12) werden vollständig übernommen. Das Grundgerüst des Kalküls, das Alphabet, ist zu
verändern. Die Grundlage dazu bildet die TEER–Standarddatentyp–Signatur TDT =
(SORTTDT , OPNSTDT , PREDTDT ). Analog zum EER–Kalkül werden auch im TEER–
Kalkül Datentyp–anzeigende Indizes bei Operatoren und Prädikaten der Mengen
OPNSTDT und PREDTDT nicht angegeben. Die entscheidenden Erweiterungen bilden Funktionen, die den Datenbankinhalt in Abhängigkeit von der Zeit auswerten. Da der TEER–
Kalkül das Ergebnis einer temporalen Anfrage liefert, wird die Ausgabe um die Angabe
des Zeitpunkts erweitert, zu dem das Ergebnistupel gültig ist.
Es sei ein TEER-Schema mit den zugehörigen temporalen Datentypen der Menge SORTTDT gegeben.
Datentypen haben eine feste Interpretation. Die Operato Die
m m m
,
,
, TE , firstTE , lastTE , min durationTE , max durationTE } ⊆
ren der Menge { m
int
int
TE
OPNSTDT sind nicht zugelassen, da sie in der TEER–Anfragesprache nicht verfügbar sind.
86
4.2. Der TEER–Kalkül
4.2.1
Die umgangssprachlichen temporalen Prädikate
Die Prädikate superior, equivalent, adjacent und overlap der Menge PREDTDT sind im
temporal erweiterten EER–Kalkül nicht ausdrückbar. Die die Begründung dafür ist, daß
sich der TEER–Kalkül ausschließlich auf Zeitpunkte bezieht. Eine graphische TEER–
Anfrage, die auf der Basis temporaler Elemente formuliert wird, entspricht einer Menge
von Kalkülanfragen. Die mit jeder Anfrage ermittelten Zeitpunkte bilden ein temporales
Element. An diese temporalen Elemente stellen die obigen Prädikate spezielle Bedingungen: Es müssen sich ein temporales Element in einer bestimmten temporalen Ausbildung
bilden. Diese Ausbildung ist an Hand von Beispielen im Beispiel 3.1 graphisch dargestellt.
In den folgenden Erklärungen zu den Prädikaten, die von der Form π(τ1 , τ2 ), τi ∈ TE type,
sind, wird angenommen, daß das temporale Element τ2 gegeben ist und τ1 sich aus berechneten Zeitpunkten zusammensetzen soll.
1. superior:
Das sich aus den einzelnen Zeitpunkten bildende temporale Element muß ganz über
dem gegebenen temporalen Element liegen, d.h. alle Teilintervalle des gegebenen
temporalen Elementes müssen vollständig überdeckt werden.
2. equivalent:
Das sich aus den einzelnen Zeitpunkten bildende temporale Element muß in allen
Zeitpunkten mit dem gegebenen temporalen Element übereinstimmen.
3. adjacent:
Das sich aus den einzelnen Zeitpunkten bildende temporale Element muß neben
dem gegebenen temporalen Element liegen, d.h. es müssen sich Intervalle bilden, so
daß jedes Intervall des gegebenen Elements einen Nachbarn besitzt.
4. overlap:
Das sich aus den einzelnen Zeitpunkten bildende temporale Element muß das gegebene Element überschneiden.
Es ist aber nicht möglich, an einen gerade berechneten Zeitpunkt Bedingungen zu stellen,
die andere noch unbekannte, zu berechnende Zeitpunkte einschließen. Es ist unbekannt, ob
dieser Zeitpunkt einzeln oder in einem sich bildenden Intervall liegt, oder ob im Fall von
overlap außerhalb des gegebenen Elements liegende Zeitpunkte in das zu berechnende
Element aufgenommen werden dürfen, da vielleicht noch nicht sicher ist, daß es auch
Überschneidungen gibt.
Die Prädikate during, before und after sind in Kapitel 3.3 so für temporale Elemente
deﬁniert, daß diese Deﬁnitionen auch für einzelne Zeitpunkte richtig sind. Ob ein vor, nach
oder innerhalb eines temporalen Elements liegender Zeitpunkt innerhalb eines Intervalls
oder einzeln liegt, ist nicht wichtig. Die Menge endlich vieler berechneter Zeitpunkte bildet
ein temporales Element, das das Prädikat in Bezug auf das gegebene temporale Element
erfüllt.
Die umgangssprachlichen Prädikate sind allesamt nicht direkt im TEER–Kalkül anzugeben. Die Prädikate during, before und after sind aber mit Hilfe der mathematischen
Prädikate {<d , >d , ≤d , ≥d , =d , =d , ∈TE } ⊆ PREDTDT ausdrückbar.
87
Kapitel 4. Die TEER–Anfragesprache
4.2.2
Syntax
In der folgenden Deﬁnition des Alphabets des TEER–Kalküls werden an passenden Stellen, innerhalb der Deﬁnition der Prädikate und Operatoren, gleich Beispiele angegeben.
Zu diesem unüblichen Mittel wird gegriﬀen, um die gemachten Unterscheidungen zu veranschaulichen.
Definition 4.14
Das Alphabet des TEER–Kalküls ist gegeben durch:
• Trennzeichen
• Klammern
, (Komma)
(, )
• Doppelpunkt
:
• Verbindungszeichen
• Quantoren
¬, ∧, ∨, ⇒, ⇔
∀, ∃
• Individuenvariablen
• Zeitvariablen
• Zeitkonstanten
x, y, z . . .
t, t , t , . . .
t0 , tnow , t∞
• Sorten
– Datensorten SORTTDT
– Entitytypen E-TYPE
– Relationshiptypen R-TYPE
• Sortenausdrücke
– Jede Sorte ist ein Sortenausdruck.
– Ist s ein Sortenausdruck, so sind list(s), set(s) und bag(s) Sortenausdrücke.
• Die Menge der Prädikatsymbole π(τ1 , . . . , τn ) läßt sich in drei Gruppen einteilen.
Die erste Gruppe besteht aus Prädikaten, die nicht temporal erweitert werden. Die
zweite Gruppe enthält alle Prädikate, die temporal erweitert werden und die dritte Gruppe umfaßt die auf temporale Datentypen anwendbaren Prädikate. Für die
Prädikate der ersten beiden Gruppen gilt, daß sie auf temporal abhängige oder
unabhängige Terme anwendbar sind. Wenn eine temporale Abhängigkeit der Argumentterme besteht, sind alle diese temporal abhängigen Terme von demselben festen
Zeitpunkt t abhängig. Diese Abhängigkeit wird mit Hilfe der speziellen Schreibweise .t (unten als Operator deﬁniert) ausgedrückt. In der unten folgenden Auﬂistung
der Prädikate wird in allgemeinen Formeln diese temporale Abhängigkeit der Argumentterme angenommen, sie muß aber nicht für alle Terme bestehen.
88
4.2. Der TEER–Kalkül
Die erste Menge besteht aus den Datentyp–Prädikaten der Menge PREDDT ⊆
PREDTDT . Diese Prädikate werden nicht temporal erweitert:
π(τ1 , . . . , τn ) ≡ π̂(τ̂1 .t, . . . , τ̂n .t),
wobei τi ein Term des TEER–Kalküls und τ̂i ein Term des EER–Kalküls ist.
π̂ ≡ π ∈ PREDDT ist ein Prädikat des EER–Kalküls.
Beispiel 4.15
Die Variable pr sei vom Typ produziert.
pr.Auslastung.t > 80
ist eine atomare Formel des TEER–Kalküls. Sie ist von der Form
π(τ1 , τ2 )
mit
π ≡ π̂ = >, π, π̂ ∈ PREDDT ,
τ1 ≡ τ̂1 .t = pr.Auslastung.t,
τ2 ≡ τ̂2 = 80.
Da 80 eine Konstante ist, ist τ2 nicht temporal abhängig.
Beispiel 4.16
Die Variable ang sei vom Typ ANGESTELLTER, die Variable ab vom Typ ABTEILUNG.
ang = ab.AbtLeiter.t
ist eine atomare Formeln der Form
τ1 = τ2
mit
τ1 ≡ τ̂1 = ang,
τ2 ≡ τ̂2 .t = ab.AbtLeiter.t .
Da ang eine Individuenvariable ist, ist τ1 nicht temporal abhängig.
Die nächste Gruppe der Prädikatsymbole besteht aus den Relationshiptypen sowie den is–Prädikaten. Diese Prädikate werden temporal abhängig gemacht. Für
Prädikate π ∈ PREDTDT gilt:
π(τ1 , . . . , τn ) ≡ π̂.t(τ̂1 .t, . . . , τ̂n .t),
wobei π̂, π̂ ∈ PREDTDT , ein Prädikat des EER–Kalküls ist, für das gilt: π ≡ π̂.t. τi
ist ein Term des TEER–Kalküls, τ̂i ist ein Term des EER–Kalküls. Zu den Relationshiptypen und Prädikatfunktionen im einzelnen:
Ein Relationshiptyp wird in Abhängigkeit eines Zeitpunkts t ausgewertet. Der Relationshiptyp R = R(n1 : E1 , . . . , nm : Em ) (ohne Berücksichtigung von Relationship–
Attributtypen) mit partizipierenden Entitytypen Ei und zugehörigen Rollennamen
ni ist als Prädikat dann wie folgt deﬁniert:
R.t(τ1 .t, . . . , τm .t) := ∃ (xR : R) (n1 .t(xR ) = τ1 .t ∧ . . . ∧ nm .t(xR ) = τm .t).
Der Rollenname ni .t ist dabei ein Operator im Sinne der unten gegebenen Deﬁnition.
89
Kapitel 4. Die TEER–Anfragesprache
Beispiel 4.17
Die Variable p sei vom Typ PRODUKT, die Variable ab vom Typ ABTEILUNG
und der Relationshiptyp R sei produziert. Der Ausdruck
produziert.t(p, ab)
ist eine atomare Formel der Form
π(τ1 , τ2 )
π ≡ π̂.t = produziert.t,
τ1 ≡ τ̂1 = p,
τ2 ≡ τ̂2 = ab.
mit
π, π̂ ∈ PREDTDT ,
Das is–Prädikat wird temporal erweitert. Die Funktion is Ak .t : Ej prüft, ob ein
Entity des Eingangstyps Ej auch Entity des Ausgangstyps Ak zum Zeitpunkt t ist.
Das Prädikat is Ej .t : Ak ist analog deﬁniert.
Beispiel 4.18
Die Variable v sei vom Typ VORPRODUKT. Der Ausdruck
is PRODUKT.t(v)
ist eine atomare Formel der Form
π(τ )
mit
π ≡ π̂.t = is PRODUKT.t,
τ ≡ τ̂ = v.
π, π̂ ∈ PREDTDT ,
Die dritte Gruppe bilden die auf temporale Datentypen anwendbaren Prädikate
der Menge PREDTEMP ⊆ PREDTDT , wobei die umgangssprachlichen Prädikate im
TEER–Kalkül nicht zugelassen sind.
PREDTEMP := {<d , >d , ≤d , ≥d , =d , =d , ∈TE } ⊆ PREDTDT .
Diese Prädikate dürfen auf Zeitvariablen sowie temporale Elemente bzw. die Datumsangaben, aus denen sich die Angabe eines solchen Elements zusammensetzt,
angewendet werden. Ausdrücke, die ein Prädikat der Menge PREDTEMP beinhalten,
sind von der Form:
π(τ1 , . . . , τn ) ≡ π̂(τ̂1 , . . . , τ̂n ),
π ≡ π̂, τi ≡ τ̂i .
Beispiel 4.19
1. t ∈ [1/1/91, 30/6/91]
2. t < 1/1/91
3. t = t
• Die Menge der Operatorsymbole ω(τ1 , . . . , τn ) läßt sich ebenfalls in drei Gruppen
aufteilen. Auch hier wird die Unterscheidung nach der temporalen Abhängigkeit getroﬀen. Die Operatoren der ersten Gruppe werden temporal erweitert. Die zweite
90
4.2. Der TEER–Kalkül
Gruppe enthält alle Operatoren, die nicht temporal erweitert werden, und die dritte
Gruppe umfaßt die auf temporale Datentypen anwendbaren Operatoren. Für die
Operatoren der ersten beiden Gruppen gilt, daß sie auf temporal abhängige oder
unabhängige Terme anwendbar sind. Wenn eine temporale Abhängigkeit der Argumentterme besteht, sind alle diese temporal abhängigen Terme von demselben festen
Zeitpunkt t abhängig. In der unten folgenden Auﬂistung der Operatoren wird in allgemeinen Formeln diese temporale Abhängigkeit der Argumentterme angenommen,
sie muß aber nicht für alle Terme bestehen.
Die erste Gruppe besteht aus den Datentyp–Operationen der Menge OPNSDT ⊆
OPNSTDT . Diese Operationen werden nicht temporal erweitert:
ω(τ1 , . . . , τn ) ≡ ω̂(τ̂1 .t, . . . , τ̂n .t),
wobei ω ≡ ω̂ ∈ OPNSDT ein Operator des EER–Kalküls ist. Die Terme τi sind
Terme des TEER–Kalküls, die Terme τ̂i sind Terme des EER–Kalküls.
Beispiel 4.20
Der Ausdruck
StPreis.t + 50
ist ein Term der Form
ω(τ1 , τ2 )
mit
ω ≡ ω̂ = +, ω, ω̂ ∈ OPNSDT ,
τ1 ≡ τ̂1 .t = StPreis.t,
τ2 ≡ τ2 = 50.
Die zweite Gruppe der Operatorsymbole besteht aus Datenbankschema–Operatoren
sowie dem as–Operator. Diese Operatoren werden temporal abhängig gemacht:
ω(τ1 , . . . , τn ) ≡ ω̂.t(τ̂1 , . . . , τ̂n ),
wobei ω, ω ∈ OPNSTDT , ein Operator des TEER–Kalküls und ω̂, ω̂ ∈ OPNSTDT ,
ein Operator des EER–Kalküls ist, für den ω ≡ ω̂.t gilt. τi ist ein Term des TEER–
Kalküls, τ̂i ein Term des EER–Kalküls. Die Operatoren im einzelnen:
Ist x eine Variable der Sorte E ∈ E-TYPE oder R ∈ R-TYPE und A ∈ ATTR
ein Attribut, so bezeichnet x.A.t eine Variable für das Attribut A zum Zeitpunkt
t, das zum Typ E oder R gehört. Diese Verknüpfung gilt auch für Komponenten
C ∈ COMP oder Rollennamen n ∈ ROLE : x.C.A.t entspricht einer Variablen für
das Attribut A der Komponente C, die objektwertiges Attribut des Typs x ist, zum
Zeitpunkt t. n.t(x) drückt die Rolle des Typs E zum Zeitpunkt t aus (x kann in
diesem Fall nur Variable eines Entitytyps sein).
Beispiel 4.21
Die Variable ab sei vom Typ ABTEILUNG. Der Ausdruck
ab.AbtName.t
ist ein Term der Form
ω(τ )
mit
ω ≡ ω̂.t = AbtName.t,
τ ≡ τ̂ = ab.
91
ω, ω̂ ∈ OPNSTDT ,
Kapitel 4. Die TEER–Anfragesprache
Die partielle Konversion as Ak : Ej → Ak wird ebenfalls temporal erweitert:
as Ak .t : Ej → Ak . Sie liefert diejenigen Entities des Ausgangstyps Ak , die zum
Zeitpunkt t Entities des Eingangstypen Ej sind. Das Prädikat as Ej .t : Ak ist analog deﬁniert.
Beispiel 4.22
Die Variable f sei vom Typ FIRMA. Der Ausdruck
as ZULIEFERFIRMA.t(f )
ist von der Form
ω(τ )
mit
ω ≡ ω̂.t = as ZULIEFERFIRMA.t,
τ ≡ τ̂ = f.
ω, ω̂ ∈ OPNSTDT ,
Die dritte Gruppe der Operatoren bilden die auf temporale Datentypen anwendbaren Operatoren der Menge OPNSTEMP ⊆ OPNSTDT , wobei die umgangssprachlichen
Operatoren nicht zugelassen sind.
OPNSTEMP := {−d , +d , −TE , +TE } ⊆ OPNSTDT .
Ausdrücke, die einen Operator der Menge OPNSTDT enthalten, sind von der Form:
ω(τ1 , . . . , τn ) ≡ ω̂(τ̂1 , . . . , τ̂n ),
ω ≡ ω̂, τi ≡ τ̂i .
Beispiel 4.23
1. t + 5
2. [12/1/97, 12/2/97] − [31/1/97, 31/12/97]
Bemerkung: Konstanten
Die nullstelligen Funktionen k :→ s, als welche Konstanten k der speziﬁzierten
Datentypen s aufgefaßt werden, bleiben unverändert, werden also temporal nicht
erweitert. Für Konstanten ist die Angabe eines Zeitpunkts t irrelevant.
Bemerkung: Quantoren
Der All-Quantor ∀ und der Existenz–Quantor ∃ sind auf Zeitvariablen anwendbar.
Definition 4.24
Eine Anfrage im TEER–Kalkül ist ein Term ohne freie Variablen und Zeitvariablen der
Form
{τ1 , . . . , τn , t | δ1 ∧ . . . ∧ δk ∧ ϕ ∧ ϕt } ≡ {τ̂1 .t, . . . , τ̂n .t, t | δ1 ∧ . . . ∧ δk ∧ ϕ ∧ ϕt },
wobei τ1 , . . . , τn , n ≥ 0, Terme des TEER–Kalküls und τ̂1 , . . . , τ̂n Terme des EER–Kalküls
sind. t ist eine Zeitvariable, ϕ eine Formel und ϕt eine Formel, in der t gebunden wird.
92
4.2. Der TEER–Kalkül
ϕt drückt die temporale Projektion aus, mit der der Zeitraum, in dem die ausgegebenen
Daten gültig sind, festgelegt wird. Beinhaltet eine Anfrage keine temporale Projektion,
wird der Gültigkeitszeitraum auf die gesamte Lebensdauer der Datenbank gesetzt. Ein
Gültigkeitszeitraum wird mit Hilfe eines temporalen Elements TE angegeben.
Es folgen als Beispiele die obigen in graphischer und linearer Form gegebenen Anfragen
im TEER–Kalkül:
Beispiel 4.25
Zu beachten ist, daß Anfragen, die keine temporale Projektion beinhalten, über die gesamte Lebensdauer der Datenbank ausgewertet werden. Mit jeder Kalkülanfrage wird,
zusätzlich zu den gewünschten Werten, auch der Gültigkeitszeitpunkt dieser Werte ausgegeben.
1. Beispiel 4.5:
Welche Produkte werden von der Abteilung ’Montage’ der Firma ’Prima’ produ”
ziert ?“
{p.ChargenNr.t, p.ProdName.t, t | (p : PRODUKT)
∧ ∃ (ab : ABTEILUNG)(ab.AbtName.t = ’Montage’ ∧ produziert.t(p, ab)
∧ ∃ (f : FIRMA)(f.Firmenname.t = ’Prima’ ∧ gehört zu.t(f, ab)))
∧ t ∈ [t0 , t∞ ]}
2. Beispiel 4.6:
Welche Personen verdienen mehr, als das Produkt ’Rennrad’ kostet ?“
”
{ang. AngName.t, ang.PersNr.t, ang.Position.t, t | (ang : ANGESTELLTER)
∧ ang.Gehalt.t >max
{p.StPreis.t | (p : PRODUKT) (p.ProdName.t = ’Rennrad’)
∧ t ∈ [t0 , t∞ ]}
∧ t ∈ [t0 , t∞ ]}
3. Beispiel 4.7:
Wie teuer waren die Vorprodukte der Firma ’Prima’, die genau innerhalb des Zeit”
raums vom 1/1/91 bis 31/12/91 produziert wurden ?“
{p.ChargenNr.t, p.ProdName.t, p.StPreis.t, t | (p : PRODUKT)
∧ ∃ (f : FIRMA)(f.Firmenname.t = ’Prima’
∧ ∃ (v : VORPRODUKT)(liefert.t(v,as ZULIEFERFIRMA.t(f ))
∧ as PRODUKT.t(v) = p)) ∧ t ∈ [1/1/91, 31/12/91]}
4. Beispiel 4.8:
Welche Produkte werden von welcher Abteilung genau in den Zeiträumen produ”
ziert, in denen die Auslastung mindestens einer Abteilung über 80% liegt ?“
{p.ProdName.t, ab.AbtName.t, t | (p : PRODUKT ∧ ab : ABTEILUNG)
∧ ∃ (pr : produziert)(pr.Auslastung.t > 80) ∧ produziert.t(p, ab)
∧ t ∈ [t0 , t∞ ]}
93
Kapitel 4. Die TEER–Anfragesprache
5. Beispiel 4.9:
Welche Angestellten arbeiten für wieviel Gehalt in derjenigen Abteilung, die inner”
halb des Zeitraums vom 1/1/91 bis 30/6/91 ’Montage’ hieß ?“
{ang.PersNr.t, ang.AngName.t, ang.Gehalt.t, t |
(ang : ANGESTELLTER) ∧ ∃ (ab : ABTEILUNG) ((∀ t ∈ [1/1/91,30/6/91])
⇒ (ab.AbtName.t = ’Montage’)
∧ (ang = ab.AbtLeiter.t ∨ ang ∈ ab.Mitarbeiter.t)) ∧ t ∈ [t0 , t∞ ]}
6. Beispiel 4.10:
Welche Angestellten arbeiteten innerhalb des Zeitraums vom 1/1/95 bis 31/1/95
”
für wieviel Gehalt in derjenigen Abteilung, die innerhalb des Zeitraums vom 1/1/91
bis 30/6/91 ’Montage’ hieß ?“
{ang.PersNr.t, ang.AngName.t, ang.Gehalt.t, t | (ang : ANGESTELLTER)
∧ ∃ (ab : ABTEILUNG) ((∀ t ∈ [1/1/91,30/6/91]) ⇒ (ab.AbtName.t = ’Montage’)
∧ (ang = ab.AbtLeiter.t ∨ ang ∈ ab.Mitarbeiter.t) ∧ t ∈ [1/1/95,31/1/95])}
7. Beispiel 4.11:
Wann ist Müller Leiter der Abteilung ’Montage’ ?“
”
{t | ∃(ang : ANGESTELLTER)(ang.AngName.t = ’Müller’
∧ ∃(ab : ABTEILUNG)(ab.AbtName.t = ’Montage’
∧ ang = ab.AbtLeiter.t)) ∧ t ∈ [t0 , t∞ ]}
8. Beispiel 4.12:
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem
”
Müller Leiter der Abteilung ’Montage’ ist ?“
{ang.AngName.t, ang.PersNr.t, ang.Position.t, t | (ang : ANGESTELLTER)
∧ ∃(a : ANGESTELLTER)(a.AngName.t = ’Müller’
∧ ∃(ab : ABTEILUNG)(ab.AbtName.t = ’Montage’
∧ a = ab.AbtLeiter.t)) ∧ t ∈ [t0 , t∞ ]}
4.2.3
Semantik
Die für den EER–Kalkül deﬁnierte Semantik der Terme, atomaren Formeln und Formeln
(Deﬁnitionen 2.15, 2.16, 2.17) ist im TEER–Kalkül gültig. Die Semantik des TEER–
Kalküls wird mit Hilfe dieser zugrunde liegenden Semantik deﬁniert. Terme, Operatoren
und Prädikate des EER–Kalküls werden mit der im vorherigen Abschnitt eingeführten
ˆ–Notation kenntlich gemacht.
Die folgenden neuen Notationen werden verwendet:
[σt , β](τ ) bezeichne den Wert des Terms τ im Zustand σt unter der Belegung β.
[σt , β] |= ϕ bedeutet: Eine Formel ϕ ist im Zustand σt unter der Belegung β gültig.
Ein Zustand σt einer temporalen Datenbank ist eine Menge von Entities, Relationships
und Attributen, die zu den in der Datenbank modellierten Entity– und Relationshiptypen sowie Attributtypen passen (vgl. Kapitel 3.1). Diese Menge ist zeitabhängig, da eine
94
4.2. Der TEER–Kalkül
Menge gleicher Entities, Relationships und Attribute zu verschiedenen Zeitpunkten t unterschiedliche Werte enthalten kann. σt bezeichnet somit den Zustand einer (temporalen)
Datenbank zu einem Zeitpunkt t.
Die Belegung einer Zeitvariablen t ist ein fester Zeitpunkt. Eine Anfrage des TEER–
Kalküls entwickelt sich daher zu einer Menge von Anfragen des EER–Kalküls, da β(t) alle
innerhalb dieses Zeitraums liegenden Zeitpunkte durchlaufen muß. In Kalkülkonstrukten,
in denen t eine freie Variable ist, sei der Wert von t außerhalb dieses Konstrukts festgelegt.
Von dieser Festlegung des Zeitpunkts t ist der Datenbank–Zustand, in dem die Anfrage
ausgewertet wird, abhängig. Die Semantik einzelner Kalkülkonstrukte, in denen t frei ist,
ist daher nicht festgelegt. Für die im folgenden behandelten Konstrukte sei eine feste
Belegung β(t) gegeben, sofern t sonst eine freie Zeitvariable wäre.
Definition 4.26
Die Semantik des TEER–Kalküls ist gegeben durch:
• [σ, β](t) := β(t)
• ω ∈ OPNSDT ⊆ OPNSTDT :
[σ, β](ω(τ1 , . . . , τn )) ≡ [σ, β](ω̂(τ̂1 .t, . . . , τ̂n .t)), ω̂ ∈ OPNSDT
:= [σβ(t) , β](ω̂(τ̂1 , . . . , τ̂n ))
• ω ∈ OPNSTDT :
[σ, β](ω(τ1 , . . . , τn )) ≡ [σ, β](ω̂.t(τ̂1 .t, . . . , τ̂n .t)), ω̂ ∈ OPNSTDT
:= [σβ(t) , β](ω̂(τ̂1 , . . . , τ̂n ))
• ω ∈ OPNSTEMP ⊆ OPNSTDT :
[σ, β](ω(τ1 , . . . , τn )) ≡ [σ, β](ω̂(τ̂1 , . . . , τ̂n )), ω̂ ∈ OPNSTEMP
:= [σβ(t) , β](ω̂(τ̂1 , . . . , τ̂n ))
• [σ, β]({τ1 , . . . , τn , t | δ1 ∧ . . . ∧ δk ∧ ϕ ∧ ϕt })
≡ [σ, β]({τ̂1 .t, . . . , τ̂n .t, t | δ1 ∧ . . . ∧ δk ∧ ϕ ∧ ϕt })
:= {[σβ(t) , β]({τ̂1 , . . . , τ̂n , β(t) | δ1 ∧ . . . ∧ δk ∧ ϕ}) | β(t) ist ein Zeitpunkt, der in
dem in der Formel ϕt speziﬁzierten Gültigkeitszeitraum liegt. }
• [σ, β]({{τ1 , . . . , τn , t | δ1 ∧ . . . ∧ δk ∧ ϕ ∧ ϕt }})
≡ [σ, β]({{τ̂1 .t, . . . , τ̂n .t, t | δ1 ∧ . . . ∧ δk ∧ ϕ ∧ ϕt }})
:= {[σβ(t) , β]({{τ̂1 , . . . , τ̂n , β(t) | δ1 ∧ . . . ∧ δk ∧ ϕ}}) | β(t) ist ein Zeitpunkt, der in
dem in der Formel ϕt speziﬁzierten Gültigkeitszeitraum liegt. }
• [σ, β] |= τ1 = τ2 ≡ τ̂1 .t = τ̂2 .t gdw. [σβ(t) , β] |= τ̂1 = τ̂2
• π ∈ PREDDT ⊆ PREDTDT :
[σ, β] |= π(τ1 , . . . , τn ) ≡ π̂(τ̂1 .t, . . . , τ̂n .t), π̂ ∈ PREDDT
gdw. [σβ(t) , β] |= π̂(τ̂1 , . . . , τ̂n )
• π ∈ PREDTDT :
[σ, β] |= π(τ1 , . . . , τn ) ≡ π̂.t(τ̂1 .t, . . . , τ̂n .t), π̂ ∈ PREDTDT
gdw. [σβ(t) , β] |= π̂(τ̂1 , . . . , τ̂n )
95
Kapitel 4. Die TEER–Anfragesprache
• π ∈ PREDTEMP ⊆ PREDTDT :
[σ, β] |= π(τ1 , . . . , τn ) ≡ π̂(τ̂1 , . . . , τ̂n ), π̂ ∈ PREDTEMP
gdw. [σβ(t) , β] |= π̂(τ̂1 , . . . , τ̂n )
4.2.4
Auswertung
In diesem Abschnitt wird die Vorgehensweise bei der Auswertung einer Anfrage des
TEER–Kalküls an Hand eines einfachen Beispiels vorgestellt.
Gegeben sei die TEER–Kalkül–Anfrage
{p.ChargenNr.t, t | (p : PRODUKT) ∧ p.StPreis.t > 1000 ∧ t ∈ [t0 , t∞ ]}.
Diese Anfrage gibt die Chargennummer aller Produkte, die teurer als 1000 DM sind, aus.
Die Kalkülanfrage ist ein korrekter Anfrageterm der Form
τ1 = {τ2 , t | δ1 ∧ ϕ ∧ ϕt }
mit
τ2 = τ̂2 .t = p.ChargenNr.t
δ1 = (p : PRODUKT)
ϕ = p.StPreis.t > 1000
ϕt = t ∈ [t0 , t∞ ]
Die Sorten sort der Terme lassen sich wie folgt bestimmen:
sort(p) = type(p) = PRODUKT
sort(τ̂2 ) = integer, da ChargenNr: PRODUKT → integer
sort(τ1 ) = set(tuple(integer, date))
Der Anfrageterm τ1 muß nun zu allen Zeitpunkten t, die zwischen t0 und t∞ liegen,
ausgewertet werden. O.B.d.A. sei t0 = t∞ , so daß die Auswertung nur zu dem festen
Zeitpunkt β(t) = t0 erfolgen muß. Der Datenbank–Zustand σβ(t) sei durch die Tabelle 4.1
festgelegt.
Surrogat ChargenNr
p1
1
p2
2
p3
3
p4
4
ProdName StPreis
Rennrad
1200
Herrenrad
1100
Damenrad
900
Kinderrad
400
Tabelle 4.1: σβ(t) (PRODUKT) = {p1 , p2 , p3 , p4 }
96
4.3. Transformation in den TEER–Kalkül
Die Auswertung:
[σβ(t) , β](τ1 ) = {[σβ(t) , β ](τ̂2 ), β(t) |
β ist eine Belegung mit β (x) = β(x) f ür alle x = p,
so daß [σβ(t) , β ](p : PRODUKT) und [σβ(t) , β ](p.StPreis > 1000)}
= {[σβ(t) , β ](τ̂2 ), β(t) |
β ist eine Belegung mit β (x) = β(x) f ür alle x = p,
so daß β (p) ∈ σβ(t) (PRODUKT) und
([σβ(t) , β ](p.StPreis), [σβ(t) , β ](1000)) ∈ σβ(t) (>)}
= {σβ(t) (ChargenNr)([σβ(t) , β ](p)), β(t) |
β ist eine Belegung mit β (p) = pi (i ∈ 1, . . . , 4) und
σβ(t) (StPreis)([σβ(t) , β ](p)) > 1000}
= {σβ(t) (ChargenNr)(β (p)), β(t) |
β ist eine Belegung mit β (p) = pi (i ∈ 1, . . . , 4) und
σβ(t) (StPreis)(β (p)) > 1000}
= {σβ(t) (ChargenNr)(pi ), β(t) | i ∈ 1, . . . , 4 und σβ(t) (StPreis)(pi ) > 1000}
= {(1, t0 ), (2, t0 )}
4.3
Transformation in den TEER–Kalkül
Nachdem neben der Syntax der TEER–Anfragesprache auch deren Interpretation umgangssprachlich in Kapitel 4.1.3 gegeben wurde, soll die Semantik jetzt eindeutig festgelegt werden. Dazu wird der im Abschnitt 4.2.2 deﬁnierte TEER–Kalkül verwendet. Eine
Konsequenz davon ist, daß die umgangssprachlichen temporalen Prädikate superior, equivalent, adjacent und overlap in zu transformierenden Anfragen nicht verwendet werden
dürfen.
Die Familie von Funktionen T F = {T , Tt , Tt,t } transformiert eine graphische TEER–
Anfrage, die in linearer Schreibweise vorliegt, in den TEER–Kalkül. Das geschieht, indem
die einzelnen Syntaxkonstrukte transformiert werden. Die Transformation ist Syntax–
orientiert. Die jeweilige Transformationsfunktion ist danach festgelegt, ob der transformierte Ausdruck temporal abhängig ist.
Die Funktion T ist temporal unabhängig. Das bedeutet, daß keine Zeitvariablen in dem
erzeugten Kalkülkonstrukt verwendet werden. Die Funktionen Tt , Tt,t sind dagegen temporal abhängig. Die Funktion Tt wird benutzt, um eine gebundene Zeitvariable t dem zu
transformierenden Ausdruck zu übergeben. t wird damit in dem erzeugten Ausdruck verwendet. Die Funktion Tt,t übergibt die Zeitvariable t analog zur Funktion Tt . Die Variable
t dagegen wird erst durch den Funktionsaufruf erzeugt. t wird in dem transformierten
Ausdruck gebunden und kann in der folgenden zu erzeugenden Kalkülanfrage weiterverwendet werden.
97
Kapitel 4. Die TEER–Anfragesprache
Bei der Formulierung der Transformation wird, wie in der linearen Syntax (vgl. Anhang
B), die erweiterte Backus–Naur–Form verwendet. Damit soll verdeutlicht werden, welche
Zeichen geschrieben werden müssen. Optionale Klammern sind dann sooft zu bearbeiten,
wie der zu transformierende Ausdruck in der linearen Anfrage vorkommt. In Ausnahmefällen sind spezielle Regeln angegeben.
Um eine fehlerfreie Transformation zu gewährleisten, müssen die linearen Anfragen eine bestimmte Form besitzen, die über die syntaktische Korrektheit hinausgeht, wie im
folgenden zu sehen ist.
4.3.1
Voraussetzungen und Einschränkungen
• Alle Anfragen und Unteranfragen müssen explizit deklarierte Variablen beinhalten.
Eine Anfrage, inklusive ihrer Unteranfragen, darf sich nur auf ein einziges (syntaktisch korrektes) TEER–Schema beziehen. Dieses sei in einer TEER–Signatur formalisiert (damit sind die beschreibenden Mengen und Hilfsfunktionen aus Kapitel
2.4.1 deﬁniert und vorhanden).
Die Form des Anfragekopfs sei
"get" attr list "from" teer
mit
teer ::=
ent name abbrev [ "," ent name abbrev ]∗
[ "," rel name abbrev ]∗
[ "," typ name ]∗
[ "," comp name ]∗
Für die in attr list und teer enthaltenen Namen muß gelten:
1. Alle Attributnamen attr name müssen in der Menge ATTR enthalten sein,
2. alle Entitytypnamen ent name müssen in der Menge E-TYPE enthalten sein,
3. alle Relationshiptypnamen rel name müssen in der Menge R-TYPE enthalten
sein,
4. alle Typkonstruktionsnamen typ name müssen in der Menge
CONSTRUCTION enthalten sein,
5. alle Komponentennamen comp name müssen in der Menge COMP enthalten
sein.
• Die Namen der Variablen abbrev müssen in der Anfrage eindeutig sein und genau
einmal deklariert werden.
• Es sind nur Anfragen zugelassen, die sich auf Diagramme beziehen, deren Relationships alle zweistellig sind.
• Alle in eine Anfrage einbezogenen Typkonstruktionen dürfen nur einen Eingangs–
und einen Ausgangstyp besitzen.
98
4.3. Transformation in den TEER–Kalkül
Das Vorgehen bei der Transformation einer Anfrage ist nicht linear, d.h. die in einem Konstrukt enthaltenen Informationen reichen nicht immer zu seiner Transformation aus. Bei
der Transformation solcher Konstrukte wird immer wieder auf die in dem Konstrukt teer
enthaltenen Informationen zurückgegriﬀen. Es ﬁndet eine sogenannte seitliche Weitergabe
von Informationen statt. Der Baum in Abbildung 4.8 soll das Vorgehen bei einer Transformation verdeutlichen. Dabei ist die jeweilig benutzte Transformationsfunktion nicht
angegeben. Der Ableitungsast eines Konstrukts, also eines Nichtterminals, ist soweit nach
unten verfolgt, bis sich eine Zeichenfolge, nur aus Terminalen bestehend, gebildet hat.
Wegen der enormen Größe des Baums sind die Ableitungen von Datentypen und Prädikaten jedoch nicht dargestellt. Besitzen mehrere Nichtterminale eines Ausdrucks dieselbe
Ableitung, werden die Äste an einem gemeinsamen Knoten zusammengeführt. Kommt ein
Nichtterminal dabei mehrfach in diesem Ausdruck vor, so wird nur für eines die Ableitung
weiter dargestellt. Durch diese unkonventionelle Darstellungsform soll die Breite des Baumes beschränkt werden. Die seitliche Weitergabe von Informationen ist aus eben diesem
Grund nicht dargestellt. Dieser Ableitungsbaum“ ist nicht vollständig, oftmals wird auf
”
die Wiederholung von Ableitungsästen von Nichtterminalen verzichtet. Der entsprechende Ast ist in diesen Fällen an anderer Stelle im Baum zu ﬁnden. Aus diesem Grund sind
sämtliche temporalen Ausdrücke in Abhängigkeit von t aufgeführt. Ob t eventuell durch
eine andere Zeitvariable zu ersetzen ist, ist den unten aufgeführten Transformationsregeln zu entnehmen. Der Sinn der Abbildung ist, einen Weg durch die unten angegebenen
Transformationsregeln zu zeigen. Die Regeln zur Transformation der Datentypen sind
in diesem Abschnitt nicht angegeben, da sie oﬀensichtlich sind. In Anhang C sind die
Transformationsregeln vollständig zusammengefaßt.
99
Kapitel 4. Die TEER–Anfragesprache
Abbildung 4.8: Ableitungsbaum“
”
100
4.3. Transformation in den TEER–Kalkül
4.3.2
Die Transformation
Die im TEER–Kalkül ausdrückbaren Anfragen sind in zwei Gruppen eingeteilt:
1. Die Ausgabe von Tupeln zusammen mit dem Gültigkeitszeitpunkt:
{τ1 , . . . , τn , t | δ1 . . .∧ δk ∧ ϕ ∧ ϕt } = {τ̂1 .t, . . . , τ̂n .t, t | δ1 ∧. . .∧ δk ∧ ϕ ∧ ϕt }, n > 0.
2. Die Ausgabe eines Zeitpunkts:
{t | ϕ ∧ ϕt }, n = 0.
Dieses ist analog zu der linearen Syntax der TEER–Anfragesprache. Eine Anfrage query
ist dort entweder als ein get attr oder ein get time–Konstrukt deﬁniert. Deshalb liefert
die Transformation einer query ::= get attr einen Kalkülausdruck der ersten Gruppe,
eine Transformation von query ::= get time einen Ausdruck der zweiten Gruppe. Nach
diesem Schema, sich an der Syntax orientierend, sind alle Transformationsregeln aufgebaut. Die kontextfreien Syntaxregeln reichen zu einer fehlerfreien Transformation jedoch
nicht immer aus. Es gibt zusätzlich kontextsensitive Regeln, die von den Mengen und
Hilfsfunktionen aus Kapitel 2.4.1 Gebrauch machen.
Ein TEER–Diagramm wird durch das Konstrukt teer beschrieben. In teer werden sämtliche Entitytyp–, Relationshiptyp–, Typkonstruktions– und Komponentennamen angegeben, auf die sich eine Anfrage bezieht.
Im folgenden wird die Beispielanfrage 4.5
Welche Produkte werden von der Abteilung ’Montage’ der Firma ’Prima’ produziert ?“
”
betrachtet. Die zugehörige lineare Anfrage ist (vgl. Beispiel 4.13.1):
get ChargenNr, ProdName
from FIRMA, ABTEILUNG, PRODUKT, gehört zu, produziert
restrict ((Firmenname = ’Prima’) and (AbtName = ’Montage’))
Das TEER–Diagramm ist somit angegeben durch
teer ::=
FIRMA f, ABTEILUNG ab, PRODUKT p, gehört zu gz,
produziert pr
wobei, um den oben gestellten Voraussetzungen zu entsprechen, alias–Bezeichner für die
Entity– und Relationshiptypen eingeführt worden sind. In dem Deklarationsteil einer
Kalkülanfrage sollen aber nur diejenigen Entity– und Relationshiptypen deklariert werden,
deren Attributwerte ausgegeben werden sollen. Welche Namen in teer zu welchem EER–
Konzept gehören, liefert ein Vergleich eines jeden Namens mit den Elementen der Mengen
E-TYPE, R-TYPE, CONSTRUCTION und COMP. Im obigen Beispiel liefert dieser
Vergleich
FIRMA, ABTEILUNG, PRODUKT ∈ E-TYPE,
gehört zu, produziert ∈ R-TYPE.
Die Attribute, deren Werte ausgegeben werden sollen, sind in attr list angegeben. In
Beispiel 4.5 hat diese das folgende Aussehen:
ChargenNr, ProdName
101
Kapitel 4. Die TEER–Anfragesprache
Die Transformation von attr list sieht vor, daß jeder Attributname der Liste um einen
alias–Bezeichner sowie die Endung .t erweitert wird. Der alias–Bezeichner ist die in teer
angegebene Abkürzung des zu diesem Attribut gehörenden Entity– oder Relationshiptyps.
Diesen Typ liefert die Funktion type als Ergebnis. So ist für das obige Beispiel
type(ChargenNr) = PRODUKT
und type(ProdName) = PRODUKT.
Der zugehörige alias–Bezeichner für PRODUKT ist p. attr list wird daher zu
p.ChargenNr.t, p.ProdName.t
(4.1)
abgeleitet. Damit ist auch die Transformation von teer festgelegt:
T (teer) = (p : PRODUKT),
(4.2)
da nur Attribute des Entitytyps PRODUKT ausgegeben werden.
4.3.3
Die Transformation von restrict expr und restrict attr
Das in der linearen Syntax folgende Konstrukt restrict expr ist dort optional. Diese Optionalität wird bei der Transformation einer Anfrage verworfen. Im Rahmen der
Transformation dieses Konstrukts wird eine Funktion aufgerufen“, die die Beziehungen,
”
die zwischen verschiedenen Entitytypen existieren, im Kalkül zum Ausdruck bringt. Diese
Funktion namens relationt erzeugt für das obige Beispiel unter Verwendung der beiden
in teer angegebenen Relationshiptypnamen und der dort angegebenen Abkürzungen die
Ausdrücke
gehört zu.t(f, ab)
und produziert.t(p, ab)
(4.3)
(4.4)
Zur Bildung dieser Ausdrücke wird die Funktion participants benutzt. Sie liefert zu einem
Relationshiptyp die daran beteiligten Entitytypen:
participants(gehört zu) =
participants(produziert) =
{FIRMA, ABTEILUNG}
{PRODUKT, ABTEILUNG}
Die Ausdrücke (4.3) und (4.4) setzen sich aus den Relationshiptypnamen, der .t–Notation
und den in teer angegebenen alias–Bezeichnern für die beteiligten Entitytypen zusammen. Bei der Transformation von restrict expr wird für das obige Beispiel die Transformation von restrict attr durchgeführt, da dieses Konstrukt in der linearen Schreibweise dieser Beispielanfrage gegeben ist. An Stelle von restrict attr kann aber auch
ein result link oder eine Kombination von beiden Konstrukten stehen. Während der
Transformation von restrict attr werden zuerst die noch nicht deklarierten, in teer
aufgeführten, Entitytypen deklariert:
∃ (f : FIRMA) ∧ ∃ (ab : ABTEILUNG)
(4.5)
Im Anschluß daran werden eventuelle boolesche Bedingungen bool expr transformiert.
Dabei werden die Attributnamen wie bei der Transformation von attr list behandelt,
102
4.3. Transformation in den TEER–Kalkül
Konstanten und Vergleichsprädikate bleiben unverändert. Die Bedingungen bool expr
sind in Beispiel 4.5 gegeben durch:
bool expr ::= Firmenname = ’Prima’
bool expr ::= AbtName = ’Montage’
Die Transformation dieser Bedingungen ergibt die Ausdrücke
f.Firmenname.t = ”Prima”
ab.AbtName.t = ”Montage”
(4.6)
(4.7)
Die Ausdrücke (4.3) – (4.7) werden durch Und– und Klammersymbole zu dem
folgenden Ausdruck zusammengesetzt, der Transformation von restrict expr ::=
"restrict" restrict attr:
∃ (f : FIRMA) ∧ ∃ (ab : ABTEILUNG)(f.Firmenname.t = ”Prima” ∧
ab.AbtName.t = ”Montage” ∧ gehört zu.t(f, ab) ∧ produziert.t(p, ab)
(4.8)
Die übrig gebliebene oﬀene Klammer wird erst am Ende des gesamten Kalkülausdrucks
geschlossen. Eine schließende Klammer an dieser Stelle würde den Geltungsbereich der
Variablen f und ab womöglich vorzeitig beenden.
4.3.4
Die Transformation von temp sel expr
Das nächste zu transformierende Konstrukt einer Anfrage ist das optionale
temp sel expr–Konstrukt. Bei der Transformation von temp sel expr werden neue Zeitvariablen eingeführt. Diese sollen eine Unterscheidung zwischen einer Selektion und
einer temporalen Projektion in einer Anfrage sicher stellen. Die Transformation von
temp sel expr hält sich nicht streng an die Syntax. Um die Abhängigkeit der in true time
beschriebenen Bedingungen von dem durch temp pred und cal temp elem angegebenen
Zeitraum in Kalkülschreibweise auszudrücken, ist eine Vertauschung der linearen Syntaxkonstrukte während der Transformation notwendig.
Im folgenden wird die Beispielanfrage 4.9
Welche Angestellten arbeiten für wieviel Gehalt in derjenigen Abteilung, die innerhalb
”
des Zeitraums vom 1/1/91 bis 30/6/91 ’Montage’ hieß ?“
betrachtet. Die zugehörige lineare Anfrage ist (vgl. Beispiel 4.13.5):
get PersNr, AngName, Gehalt
from ANGESTELLTER, ABTEILUNG, AbtLeiter, Mitarbeiter
time condition of ABTEILUNG is [[ AbtName = ’Montage’ ]]
during [1/1/91, 30/6/91]
Die temporale Selektion ist diesem Beispiel angegeben durch
temp sel expr ::= time condition of ABTEILUNG is [[ AbtName = ”Montage”]]
during [1/1/91, 30/6/91]
(4.9)
In diesem konkreten Beispiel wird die true time ::= [[ AbtName = ’Montage’ ]] auf den
Entitytyp ABTEILUNG angewendet. Der Zeitraum, in dem die Bedingung AbtName =
”
’Montage’“ gelten soll, ist angegeben durch
103
Kapitel 4. Die TEER–Anfragesprache
temp pred ::= "during"
und cal temp elem ::= [1/1/91, 30/6/91]
Die Transformation von temp sel expr wird folgendermaßen durchgeführt:
Das Konstrukt temp sel expr wird in Abhängigkeit von der Zeitvariablen t nach der
Regel transformiert:
Tt (temp sel expr) := ∧ (( ∀ t ∈ [t0 , t∞ ] ∃ t ∈ Tt (cal temp elem) t = t )
⇒ (Tt (true time))),
da das verwendete Prädikat temp pred during ist.
Bei der Transformation des Intervalls cal temp elem bleibt dieses unverändert:
Tt (cal temp elem) = [1/1/91, 30/6/91]
(4.10)
Innerhalb der Transformation des Konstrukts true time wird der Entitytyp ABTEILUNG deklariert, falls dieser bisher noch undeklariert ist. Es wird angenommen, daß
ABTEILUNG bisher nicht deklariert wurde. An dieser Stelle muß, um ABTEILUNG
deklarieren zu können, wieder auf Informationen, die in teer enthalten sind, zurückgegriﬀen werden. Im Anschluß an die Deklaration wird die Bedingung AbtName = ’Mon”
tage’“ transformiert:
Tt (true time) = ∃ (ab : ABTEILUNG)(ab.AbtName.t = ”Montage”)
(4.11)
Das Einsetzen der Ausdrücke (4.10) – (4.11) in (4.3.4) ergibt die Transformation des
temp sel expr–Ausdrucks (4.9):
Tt (temp sel expr) := ∧ ((∀ t ∈ [t0 , t∞ ] ∃ t ∈ [1/1/91, 30/6/91] t = t )
⇒ (∃ (ab : ABTEILUNG)(ab.AbtName.t = ”Montage”)))
4.3.5
Die Transformation von temp proj expr
Das letzte zu transformierende Konstrukt ist temp proj expr. Dieses Konstrukt ist in der
linearen Syntax optional, bei der Transformation dagegen nicht. Der Grund dafür ist die
Festlegung, daß der Gültigkeitszeitraum auf die Lebensdauer der Datenbank zu setzen ist,
falls kein Gültigkeitszeitraum, d.h. eine temporale Projektion, in der Anfrage angegeben
ist. Im Fall der Anfrage 4.5, die keine Projektion enthält, ergibt die Transformation daher
den Ausdruck
∧ t ∈ [t0 , t∞ ]
(4.12)
Die Zusammensetzung der Ausdrücke (4.1), (4.2), (4.8) und (4.12) zusammen mit im
Rahmen der Transformation von rstrict attr zu setzenden Klammern ergibt für die
Anfrage 4.9 die transformierte Anfrage
{p.ChargenNr.t, p.ProdName.t, t | (p : PRODUKT)
∧ ∃ (f : FIRMA) ∧ ∃ (ab : ABTEILUNG)
(f.Firmenname.t = ’Prima’ ∧ ab.AbtName.t = ’Montage’
∧ gehört zu.t(f, ab) ∧ produziert.t(p, ab) ∧ t ∈ [t0 , t∞ ])}
Eine angegebene temporale Projektion wird in Abhängigkeit von dem verwendeten Prädikat temp pred transformiert.
104
4.3. Transformation in den TEER–Kalkül

 ∀ t ∈ Tt (temp elem proj) t < t , falls temp pred ::= before
∀ t ∈ Tt (temp elem proj) t > t , falls temp pred ::= after
Tt (temp proj) :=

∃ t ∈ Tt (temp elem proj) t = t , falls temp pred ::= during
Die Transformation des Konstrukts temp elem proj richtet sich nach dem in der Anfrage
verwendeten Konstrukt. So kann temp elem proj entweder ein konstantes temporales
Element, ein Gültigkeitszeitraum true time oder eine Unteranfrage get time sein.
Die Transformation einer Anfrage vom Typ get time unterscheidet sich in der Vorgehensweise unwesentlich von der oben beschriebenen Transformation einer Anfrage get attr.
Als Ergebnis erhält man einen Kalkülausdruck der zweiten Gruppe:
{t | ϕ ∧ ϕt }
Es wird ebenfalls Syntax–orientiert vorgegangen, die Ausnahmen, die bei den Konstrukten
restrict attr und temp proj expr gemacht werden, sind im Rahmen der Transformationsregeln erklärt.
4.3.6
Die Transformationsregeln
Die Transformation einer Anfrage query ist gegeben durch die Abbildung Tt (query).
Tt (get attr), falls query ::= get attr
Tt (query) :=
Tt (get time), falls query ::= get time
Die Abbildungen der übrigen Konstrukte sind in alphabetischer Reihenfolge angegeben.
Die Transformation der Datentypen ist in Anhang C zu ﬁnden.
T (abbrev) := T (string)
T ("all") := "max"
T (all any choice) :=
T ("all"), falls all any choice ::= "all"
Tt ("any"), falls all any choice ::= "any"
T ("and") := " ∧ "
T ("any") := "min"
Tt (attr expr) := [ T ("not") ] Tt (attr cond)
Tt (attr cond) := Tt (attr name) T (pred) T (value)
Tt (attr list) := Tt (attr name) [ "," Tt (attr name) ]∗
105
Kapitel 4. Die TEER–Anfragesprache
Tt (attr name) := T (abbrev)"."T (string)".t"
Es muß gelten:
abbrev gehört zu demjenigen Entity ent name für das gilt: type(attr name) = ent name
und ent name ist in teer enthalten.
Tt (bool expr) := Tt (attr expr) [ T (bool op) Tt (attr expr) ]∗
T (bool op) :=
T ("and "), falls bool op ::= "and"
T ("or "), falls bool op ::= "or"
Tt (cal temp elem) :=
Tt (temp elem), falls cal temp elem ::= temp elem
Tt (get time), falls cal temp elem ::= get time
T (comp name) := T (string)
T (ent name) := T (string)
T (ent rel name) :=
Tt (get attr) :=
T (ent name), falls ent rel name ::= ent name
T (rel name), falls ent rel name ::= rel name
"{" Tt (get op) Tt (restrict expr)
[ Tt (temp sel expr) ] Tt (temp proj expr) [ ) ]! "}"
Im Gegensatz zur Syntax einer Anfrage sind die Transformationen der Konstrukte
restrict expr und temp proj expr nicht optional. Mit der Transformation des Konstrukts restrict expr werden eventuelle Verbindungen zwischen Entity– und Relationshiptypen, an die eine Anfrage gestellt wird, in Kalkülschreibweise ausgedrückt. Die Transformation des Konstrukts temp proj expr erzeugt die Einschränkung der Daten auf einen
Gültigkeitszeitraum. Ist keine Projektion in der Anfrage angegeben, wird die Lebensdauer
der Datenbank als Gültigkeitszeitraum genommen.
Die optionale runde schließende Klammer wird dann benötigt, wenn in einer Kalkülanfrage an dieser Stelle noch oﬀene Klammern kein schließendes Gegenstück besitzen. Die
nicht zur erweiterten Backus–Naur–Form gehörige Hilfsnotation [ ) ]! soll bedeuten, daß
nicht beliebig viele schließende Klammern gesetzt werden dürfen, sondern ihre Anzahl
muß genau der Anzahl noch oﬀener Klammern entsprechen. Im Rahmen der Formulierung
von booleschen Bedingungen oder Gültigkeitszeiträumen werden Klammern geöﬀnet,
können aber dort nicht wieder geschlossen werden, da sonst der Gültigkeitsbereich von
Deklarationen vorzeitig beendet werden könnte.
Tt (get op) := Tt (attr list) ", t |" T (teer)
106
4.3. Transformation in den TEER–Kalkül
Tt (get result) := "{" Tt (get result op) Tt (restrict attr) Tt (temp proj expr) [ ) ]! "}"
Es gelten dieselben Erklärungen wie für das Konstrukt get attr. Die Transformation
des in einer Unteranfrage nicht zugelassenen Konstrukts temp proj expr erzeugt die in
dem Kalkül nötige Einschränkung der Variablen t auf die Lebensdauer der Datenbank.
Da das get result–Konstrukt eine Unteranfrage darstellt, dürfen nur diejenigen runden
Klammern geschlossen werden, die während der Transformation dieser Unteranfrage
geöﬀnet wurden und bisher kein schließendes Gegenstück besitzen. Das bedeutet insbesondere, daß oﬀene runde Klammern, die bei der Transformation der übergeordneten
Anfrage geöﬀnet wurden, nicht geschlossen werden dürfen.
Tt (get result op) := Tt (attr name) "|" T (teer)
Tt (get time) := "{ t |" Tt (restrict att) [ Tt (temp sel expr) ] Tt (temp proj expr) [ ) ]! "}"
Es gelten dieselben Erklärungen wie für das Konstrukt get attr. Die Transformation
des in einer Unteranfrage nicht zugelassenen Konstrukts temp proj expr erzeugt die in
dem Kalkül nötige Einschränkung der Variablen t auf die Lebensdauer der Datenbank.
Auch in diesem Fall drückt die Hilfsnotation [ ) ]! aus, daß nur soviele runde schließende
Klammern gesetzt werden dürfen, wie noch oﬀene vorhanden sind. Wird das get time–
Konstrukt als Unteranfrage im Rahmen einer temporalen Selektion oder Projektion
verwendet, ist die Betrachtung der Klammern nur auf die innerhalb der Transformation
dieser Unteranfrage gesetzten Klammern beschränkt.
T ("not") := "¬"
T ("or") := " ∨ "
T (rel name) := T (string)
Tt (restrict attr) := [ " ∧ " ] [ "∃ (" T (abbrev) " : " T (ent rel name) ")" ]
[ " ∧ ∃ (" T (abbrev) " : " T (ent rel name) ")" ]∗
"(" Tt (bool expr) [ " ∧ " Tt (bool expr) ]∗
[ " ∧ " relationt ]∗
Die ersten drei optionalen Klammern ermöglichen die Deklaration aller bisher nicht deklarierten Entitytypen, die in teer aufgeführt sind. Als Variablen werden dabei die zugehörigen alias–Bezeichner abbrev aus teer benutzt. Relationshiptypen werden nur dann
deklariert, wenn eine boolesche Bedingung bool expr an ein zugehöriges Attribut gestellt
107
Kapitel 4. Die TEER–Anfragesprache
ist. Das erste optionale ∧ wird nicht benötigt, falls Tt (restrict attr) im Rahmen einer
Transformation des Konstrukts get result oder get time aufgerufen wird.
Als nächstes werden alle booleschen Bedingungen nacheinander transformiert. Die letzte
optionale Klammer beinhaltet einen Aufruf der Funktion relationt . Diese Funktion
stellt Verbindungen zwischen Entitytypen her. relationt ist sooft aufzurufen, bis alle
Relationshiptyp–, Typkonstruktions– und Komponentennamen, die in teer vorkommen,
benutzt sind. Beinhaltet eine Anfrage nur einen Entitytyp, ist der Funktionsaufruf zu
übergehen.
Für das Funktion relationt gilt:

T (rel name)".t" (abbrev,abbrev),
falls Fall 1



falls Fall 2
T (abbrev) " = as "T (ent name)".t ("T (abbrev)")",
relationt :=
"(" T (abbrev) " ∈ " T (abbrev)"."T (comp name)".t"


, falls Fall 3

[ " ∨ " T (abbrev) " ∈ " T (abbrev)"."T (comp name)".t" ] ")"
Fall 1:
1. rel name ist in teer enthalten.
2. participants(rel name) = {ent name,ent name}. Die alias–Bezeichner abbrev
dieser beiden Entitytypen werden verwendet.
Fall 2:
1. Es gibt eine Typkonstruktion typ name in teer, wobei
output(typ name), input(typ name) in teer enthalten sind.
2. Die erste Abkürzung abbrev eines Entitynamens gehört zu
ent name = output(typ name).
3. Die zweite Abkürzung abbrev eines Entitynamens gehört zu
ent name = input(typ name).
4. In relationt ist der verwendete ent name = output(typ name).
Fall 3:
1. comp name ist in teer enthalten.
2. Der Ausdruck in der optionalen Klammer, wird für den Fall gebraucht, daß
es mehrere Komponenten zwischen den beiden Entitytypen type(comp name) und
domain(comp name) gibt.
3. Die erste Abkürzung abbrev gehört zu ent name = domain(typ name).
4. Die zweite Abkürzung abbrev gehört zu ent name = type(typ name).
108
4.3. Transformation in den TEER–Kalkül
5. Eine Unterscheidung zwischen ein– und mehrwertigen Komponenten ﬁndet nicht
statt.

Tt (restrict attr),




T

t (result link),


Tt (restrict attr) " ∧ " Tt (result link),
Tt (restrict expr) :=
 [ " ∧ ∃ (" T (abbrev) " : " T (ent name) ")" ]∗



"(" relationt [ " ∧ " relationt ]∗ ,



" ",
falls Fall 1
falls Fall 2
falls Fall 3
falls Fall 4
sonst
Fall 1:
restrict expr ::= "restrict" "(" restrict attr ")"
Fall 2:
restrict expr ::= "restrict" result link
Fall 3:
restrict expr ::= "restrict" "(" result attr "and" result link ")"
Fall 4:
Fall 1 und Fall 2 sind nicht erfüllt und es gibt mehr als einen Namen ent name in teer.
Erklärung der Formel:
Mit Hilfe der ersten Klammer werden alle bisher nicht deklarierten Entitytypen, die in
teer aufgelistet sind, deklariert. Die folgenden Aufrufe der Funktion relationt bewirken,
daß die Verbindungen zwischen den einzelnen Typen ausgedrückt werden.
Tt (result link) :=
[ " ∧ ∃ (" T (abbrev) " : " T (ent name) ")" ]∗
"(" relationt [ " ∧ " relationt ]∗
"(" Tt (attr name) T (pred) T (all any choice)
Tt (get result)
Mit Hilfe der ersten Klammer werden alle bisher nicht deklarierten Entitytypen, die in
teer aufgelistet sind, deklariert. Die folgenden Aufrufe der Funktion relationt bewirken,
daß die Verbindungen zwischen den einzelnen Typen ausgedrückt werden. Der Rest der
Transformationsregel ist streng Syntax–orientiert.
T (teer) :=
"(" T (abbrev) " : " T (ent name)
[ " ∧ " T (abbrev) " : " T (ent rel name) ]∗ ")"
wobei abbrev die zu dem Entitytypnamen ent name oder Entity– bzw. Relationshiptypnamen ent rel name gehörige alias–Bezeichner ist. Es werden nur diejenigen Namen
ent name bzw. ent rel name aufgezählt, deren Abkürzung abbrev in Tt (attr list)
vorkommt. Jeder Entity– oder Relationshiptyp wird dabei jedoch nur einmal deklariert,
auch wenn seine Abkürzung in Tt (attr list) mehrfach vorkommt.
109
Kapitel 4. Die TEER–Anfragesprache
Tt (temp elem) :=
Tt (interval),
falls temp elem ::= interval
Tt (interval union), falls temp elem ::= interval union

falls temp elem proj ::= temp elem
 Tt (temp elem),
"[t0 , t∞ ]" Tt (true time) " ∧ ”, falls temp elem proj ::= true time
Tt (temp elem proj) :=

falls temp elem proj ::= get time
Tt (get time),

 ∀ t ∈ Tt (temp elem proj) t < t , falls temp pred ::= before
∀ t ∈ Tt (temp elem proj) t > t , falls temp pred ::= after
Tt (temp proj) :=

∃ t ∈ Tt (temp elem proj) t = t , falls temp pred ::= during
Eine temporale Projektion wird in Abhängigkeit des verwendeten temporalen Prädikats
temp pred transformiert.
Tt (temp proj expr) :=
" ∧ " Tt (temp proj), falls temp proj expr gegeben ist
sonst
" ∧ t ∈ [t0 , t∞ ]",

"(( ∀ t ∈ [t0 , t∞ ] ∀ t ∈ " Tt (cal temp elem) "t < t )"




falls temp pred ::= before
" ⇒ (" Tt (true time) "))"



"(( ∀ t ∈ [t0 , t∞ ] ∀ t ∈ "Tt (cal temp elem) "t > t )"
Tt (temp sel) :=
falls temp pred ::= after
" ⇒ (" Tt (true time) "))"




"(( ∀ t ∈ [t0 , t∞ ] ∃ t ∈ "Tt (cal temp elem) "t = t )"



" ⇒ (" Tt (true time) "))"
falls temp pred ::= during
Eine temporale Selektion wird in Abhängigkeit des verwendeten temporalen Prädikats
temp pred transformiert.
Tt (temp sel expr) := " ∧ " Tt (temp sel)
wobei der in temp sel expr vorkommende Name ent rel name in Tt (true time)
innerhalb von Tt (temp sel) verwendet wird.

"t0 ",



"tnow ",
Tt (time expr) :=
"t∞ ",



T (date),
falls
falls
falls
falls
time
time
time
time
expr
expr
expr
expr
::=
::=
::=
::=
null
now
infinity
date
Tt (true time) := [ "∃ (" T (abbrev) " : " T (ent rel name) ")" ] "(" Tt (bool expr) ")"
wobei der optionale Ausdruck benutzt wird, falls sich die Bedingung auf das Attribut
eines Entity– Relationshiptyps bezieht und ent rel name im bisherigen Ausdruck noch
nicht deklariert worden ist.
110
4.3. Transformation in den TEER–Kalkül
4.3.7
Beispieltransformationen
Als Beispiele werden die linearen Anfragen 4.13 in den TEER–Kalkül transformiert. Dazu
müssen die Anfragen teilweise verändert werden, um den Voraussetzungen zu entsprechen.
Die transformierten Anfragen stimmen mit den Anfragen 4.25 im TEER–Kalkül nicht in
allen Einzelheiten überein. Die Anfragen 4.25 sind optimierte Versionen der hier hergeleiteten.
Um die einzelnen Schritte zu verdeutlichen, werden für jede Anfrage die einzelnen Anfragekonstrukte herausgestellt und transformiert. Wiederholende Transformationen werden
nur beim erstenmal ausführlich erläutert. Auf die Verwendung der EBNF wird dabei
verzichtet.
Beispiel 4.27
Es wird die Beispielanfrage 4.5 betrachtet:
Welche Produkte werden von der Abteilung ’Montage’ der Firma ’Prima’ produziert ?“
”
get ChargenNr, ProdName
from FIRMA f, ABTEILUNG ab, PRODUKT p, gehört zu gz, produziert pr
restrict ((Firmenname = ’Prima’) and (AbtName = ’Montage’))
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op restrict expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= ChargenNr, ProdName
teer ::= FIRMA f, ABTEILUNG ab, PRODUKT p, gehört zu gz,
produziert pr
Die Ableitung des Konstrukts restrict expr:
restrict expr ::= "restrict" "(" restrict attr ")"
restrict attr ::= "(" bool expr1 ")" "and" "(" bool expr2 ")"
bool expr1 ::= Firmenname = ’Prima’
bool expr2 ::= AbtName = ’Montage’
Die Transformation:
Tt (query) = Tt (get attr)
= { Tt (get op) Tt (restrict expr) Tt (temp proj expr) [ ) ]! }
111
Kapitel 4. Die TEER–Anfragesprache
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts get op:
Tt (get op) = Tt (attr list), t | T (teer)
Die Transformation der Attributliste attr list:
Tt (attr list) = p.ChargenNr.t, p.ProdName.t,
da beide Attribute zu dem Entitytyp PRODUKT gehören und p die zugehörige Abkürzung
ist (siehe teer).
Die Transformation des TEER–Schemas teer:
T (teer) = (p : PRODUKT),
da p die einzige in Tt (attr list) verwendete Abkürzung ist.
Die Transformation des Konstrukts restrict expr:
Tt (restrict expr) = Tt (restrict attr)
= ∧ ∃ (f : FIRMA) ∧ ∃ (ab : ABTEILUNG)
(f.Firmenname.t = ’Prima’ ∧ ab.AbtName.t = ’Montage’
∧ gehört zu.t(f, ab) ∧ produziert.t(p, ab)
Die Entitytypen FIRMA und ABTEILUNG sind diejenigen Entitytypen in teer, die bisher in keiner Deklaration benutzt wurden. Da sich die booleschen Bedingungen nicht auf
Attribute von Relationshiptypen beziehen, besteht der Deklarationsteil nur aus der Deklaration der beiden Entitytypen FIRMA und ABTEILUNG. Es folgt die Transformation
der beiden booleschen Bedingungen. Mit Hilfe der Funktion relationt werden die beiden in
teer aufgeführten Relationshiptypen gehört zu und produziert, in Abhängigkeit ihrer
zugehörigen Entitytypen, hinzugefügt.
Die Transformation des Konstrukts temp proj expr:
Tt (temp proj expr) = ∧ t ∈ [t0 , t∞ ],
da keine temporale Projektion in der Anfrage angegeben ist.
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{p.ChargenNr.t, p.ProdName.t, t | (p : PRODUKT)
∧ ∃ (f : FIRMA) ∧ ∃ (ab : ABTEILUNG)
(f.Firmenname.t = ’Prima’ ∧ ab.AbtName.t = ’Montage’
∧ gehört zu.t(f, ab) ∧ produziert.t(p, ab) ∧ t ∈ [t0 , t∞ ])}
Bei dieser Anfrage ist eine geöﬀnete runde Klammer am Ende zu schließen und zwar die,
die vor f.Firmenname.t geöﬀnet wurde.
112
4.3. Transformation in den TEER–Kalkül
Beispiel 4.28
Es wird die Beispielanfrage 4.6 betrachtet:
Welche Personen verdienen mehr, als das Produkt ’Rennrad’ kostet ?“
”
get AngName, PersNr, Gehalt
from ANGESTELLTER ang
restrict Gehalt >all (get StPreis
from PRODUKT p
restrict (ProdName = ’Rennrad’))
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op restrict expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= AngName, PersNr, Gehalt
teer ::= ANGESTELLTER ang
Die Ableitung des Konstrukts restrict expr:
restrict expr ::= "restrict" result link
result link ::= attr name pred all any choice "(" get result ")"
attr name ::= Gehalt
pred ::= ">"
all any choice ::= "all"
Die Ableitung des Konstrukts get result:
get result ::= get result op "restrict" "(" restrict attr ")"
get result op ::= "get" StPreis "from" PRODUKT p
restrict attr ::= "(" bool expr ")"
bool expr ::= ProdName = ’Rennrad’
Die Transformation:
Tt (query) = Tt (get attr)
= { Tt (get op) Tt (restrict expr) Tt (temp proj expr) [ ) ]! }
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts get op:
Tt (get op) = Tt (attr list), t | T (teer)
= ang.AngName.t, ang.PersNr.t, ang.Position.t, t | (ang : ANGESTELLTER)
113
Kapitel 4. Die TEER–Anfragesprache
Die Transformation des Konstrukts restrict expr:
Tt (restrict expr) = Tt (result link)
= ( Tt (attr name) T (pred) T (all any choice) Tt (get result)
Tt (attr name) = ang.Gehalt.t
T (pred) = >
T (all any choice) = max
Die Transformation des Konstrukts get result:
Tt (get result) =
{Tt (get result op) Tt (restrict attr) Tt (temp proj expr) [ ) ]! }
Die Transformation des Konstrukts get result op:
Tt (get result op) = Tt (attr name), | T (teer)
Tt (attr name) = p.StPreis.t
T (teer) = (p : PRODUKT)
Die Transformation des Konstrukts restrict attr innerhalb der Unteranfrage
get result:
Tt (restrict attr) = (p.ProdName.t = ’Rennrad’
Die Transformation des Konstrukts temp proj expr innerhalb der Unteranfrage
get result:
Tt (temp proj expr) = ∧ t ∈ [t0 , t∞ ],
da keine Projektion explizit angegeben ist.
Die Transformation des Konstrukts temp proj expr der übergeordneten Anfrage:
Tt (temp proj expr) = ∧ t ∈ [t0 , t∞ ]
da ebenfalls keine temporale Projektion angegeben ist.
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{ang.AngName.t, ang.PersNr.t, ang.Position.t, t | (ang : ANGESTELLTER)
(ang.Gehalt.t >
{p.StPreis.t | (p : PRODUKT) (p.ProdName.t = ’Rennrad’
∧ t ∈ [t0 , t∞ ])}
∧ t ∈ [t0 , t∞ ])}
Innerhalb der Anfrage und der Unteranfrage ist am Ende jeweils eine Klammer zu schließen. Diese Klammern wurden während der Transformation des Konstrukts restrict expr
114
4.3. Transformation in den TEER–Kalkül
der übergeordneten Anfrage bzw. des Konstrukts restrict attr der Unteranfrage geöﬀnet.
Beispiel 4.29
Es wird die Beispielanfrage 4.7 betrachtet:
Wie teuer waren die Vorprodukte der Firma ’Prima’, die genau innerhalb des Zeitraums
”
vom 1/1/91 bis 31/12/91 produziert wurden ?“
get ChargenNr, ProdName, StPreis
from FIRMA f, ZULIEFERFIRMA z, VORPRODUKT v, PRODUKT p, liefert l,
⊇, ⊇
restrict ((Firmenname = ’Prima’))
project during [1/1/91, 31/12/91]
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op restrict expr temp proj expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= ChargenNr, ProdName, StPreis
teer ::= FIRMA f, ZULIEFERFIRMA z, VORPRODUKT v, PRODUKT p,
liefert l, ⊇, ⊇
Die Ableitung des Konstrukts restrict expr:
restrict expr ::= "restrict" "(" restrict attr")"
restrict attr ::= "(" bool expr ")"
bool expr ::= Firmenname = ’Prima’
Die Ableitung des Konstrukts temp proj expr:
temp
temp
temp
temp
temp
proj
proj
pred
elem
elem
expr ::= "project" temp proj
::= temp pred temp elem proj
::= "during"
proj ::= temp elem
::= [1/1/91, 31/12/91]
115
Kapitel 4. Die TEER–Anfragesprache
Die Transformation:
Tt (query) = Tt (get attr)
= { Tt (get op) Tt (restrict expr) Tt (temp proj expr) [ ) ]! }
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts get op:
Tt (get op) = Tt (attr list), t | T (teer)
= p.ChargenNr.t, p.ProdName.t, p.StPreis.t, t | (p : PRODUKT)
Die Transformation des Konstrukts restrict expr:
Tt (restrict expr) = Tt (restrict attr)
= ∧ ∃ (f : FIRMA) ∧ ∃ (z : ZULIEFERFIRMA) ∧ ∃ (v : VORPRODUKT)
(f.Firmenname.t = ’Prima’ ∧ liefert.t(z, v) ∧ z = as ZULIEFERFIRMA.t(f )
∧ v = as VORPRODUKT.t(p)
Die Transformation des Konstrukts temp proj expr:
Tt (temp proj expr) = ∧ Tt (temp proj)
= ∧ ∃ t ∈ Tt (temp elem proj) t = t
= ∧ ∃ t ∈ [1/1/91, 31/12/91] t = t
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{p.ChargenNr.t, p.ProdName.t, p.StPreis.t, t | (p : PRODUKT)
∧ ∃ (f : FIRMA) ∧ ∃ (z : ZULIEFERFIRMA) ∧ ∃ (v : VORPRODUKT)
(f.Firmenname.t = ’Prima’ ∧ liefert.t(z, v) ∧ z = as ZULIEFERFIRMA.t(f )
∧ v = as VORPRODUKT.t(p) ∧ ∃ t ∈ [1/1/91, 31/12/91] t = t )}
Bei dieser Anfrage ist eine geöﬀnete Klammer am Ende zu schließen. Diese wurde während
der Transformation des Konstrukts restrict expr geöﬀnet, vor dem transformierten Attributnamen f.Firmenname.t.
Beispiel 4.30
Es wird die Beispielanfrage 4.8 betrachtet:
Welche Produkte werden von welcher Abteilung genau in den Zeiträumen produziert, in
”
denen die Auslastung mindestens einer Abteilung über 80% liegt ?“
get ProdName, AbtName
from PRODUKT p, ABTEILUNG ab, produziert pr
project during [[ Auslastung > 80 ]]
116
4.3. Transformation in den TEER–Kalkül
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op temp proj expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= ProdName, AbtName
teer ::= PRODUKT p, ABTEILUNG ab, produziert pr
Die Ableitung des Konstrukts temp proj expr:
temp
temp
temp
temp
true
bool
proj
proj
pred
elem
time
expr
expr ::= "project" temp proj
::= temp pred temp elem proj
::= "during"
proj ::= true time
::= [[ bool expr ]]
::= Auslastung > 80
Die Transformation:
Tt (query) = Tt (get attr)
= { Tt (get op) Tt (restrict expr) Tt (temp proj expr) [ ) ]! }
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts get op:
Tt (get op) = Tt (attr list), t | T (teer)
= p.ProdName.t, ab.AbtName.t, t | (p : PRODUKT ∧ ab : ABTEILUNG)
Die Transformation des Konstrukts restrict expr:
Tt (restrict expr) = (relationt = (rel name.t (abbrev,abbrev)
= (produziert.t(p, ab),
da in der Anfrage kein restrict expr–Konstrukt enthalten ist und in teer genau zwei
Entitytypen enthalten sind.
Die Transformation des Konstrukts temp proj expr:
Tt (temp proj expr) = ∧ Tt (temp proj)
= ∧ ∃ t ∈ Tt (temp elem proj) t = t
= ∧ ∃ t ∈ [t0 , t∞ ] Tt (true time) ∧ t = t
= ∧ ∃ t ∈ [t0 , t∞ ] ∃ (pr : produziert)(pr.Auslastung.t > 80) ∧ t = t
Der Relationshiptyp produziert ist innerhalb der Transformation von true time zu deklarieren, da dieser noch undeklariert ist.
117
Kapitel 4. Die TEER–Anfragesprache
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{p.ProdName.t, ab.AbtName.t, t | (p : PRODUKT ∧ ab : ABTEILUNG)
(produziert.t(p, ab)
∧ ∃ t ∈ [t0 , t∞ ] ∃ (pr : produziert)(pr.Auslastung.t > 80) ∧ t = t )}
Bei dieser Anfrage ist eine geöﬀnete Klammer am Ende zu schließen. Diese oﬀene Klammer
wurde während der Transformation des Konstrukts restrict expr gesetzt.
Beispiel 4.31
Es wird die Beispielanfrage 4.9 betrachtet:
Welche Angestellten arbeiten für wieviel Gehalt in derjenigen Abteilung, die innerhalb
”
des Zeitraums vom 1/1/91 bis 30/6/91 ’Montage’ hieß ?“
get PersNr, AngName, Gehalt
from ANGESTELLTER ang, ABTEILUNG ab, AbtLeiter, Mitarbeiter
time condition of ABTEILUNG is [[ AbtName = ’Montage’ ]]
during [1/1/91, 30/6/91]
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op temp sel expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= PersNr, AngName, Gehalt
teer ::=ANGESTELLTER ang, ABTEILUNG ab, AbtLeiter, Mitarbeiter
Die Ableitung des Konstrukts temp sel expr:
temp sel expr ::= "time condition of" ent rel name "is" temp sel
ent rel name ::= ABTEILUNG
temp sel ::= true time temp pred cal temp pred
true time ::= [[ bool expr ]]
bool expr ::= AbtName = ’Montage’
temp pred ::= "during"
cal temp elem ::= temp elem
temp elem ::= [1/1/91, 30/6/91]
Die Transformation:
Tt (query) = Tt (get attr)
= { Tt (get op) Tt (restrict expr) Tt (temp sel expr)
Tt (temp proj expr) [ ) ]! }
118
4.3. Transformation in den TEER–Kalkül
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts get op:
Tt (get op) = Tt (attr list), t | T (teer)
= ang.PersNr.t, ang.AngName.t, ang.Gehalt.t, t | (ang : ANGESTELLTER)
Die Transformation des Konstrukts restrict attr:
Tt (restrict expr) = ∧ ∃ (T (abbrev) : T (ent name)) (relationt
∧ ∃ (T (abbrev) : T (ent name)) ((T (abbrev) ∈ T (abbrev). T (comp name).t)
∨ T (abbrev) ∈ T (abbrev).T (comp name).t)
= ∧ ∃ (ab : ABTEILUNG) ((ang ∈ ab.AbtLeiter.t ∨ ang ∈ ab.Mitarbeiter.t)
Die Transformation von restrict expr ergibt den angegebenen Ausdruck, da die Entitytypen ANGESTELLTER und ABTEILUNG durch die zwei Komponenten AbtLeiter und
Mitarbeiter miteinander verbunden sind.
Die Transformation des Konstrukts temp sel expr:
Tt (temp sel expr) = ∧ Tt (temp sel)
= ∧ ((∀ t ∈ [t0 , t∞ ] ∃ t ∈ Tt (cal temp elem) t = t ) ⇒ (Tt (true time)))
= ∧ ((∀ t ∈ [t0 , t∞ ] ∃ t ∈ [1/1/91, 30/6/91] t = t
⇒ ((ab.AbtName.t = ’Montage’)))
Die Transformation des Konstrukts temp proj expr:
Tt (temp proj expr) = ∧ t ∈ [t0 , t∞ ],
da keine Projektion explizit angegeben ist.
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{ang.PersNr.t, ang.AngName.t, ang.Gehalt.t, t |
(ang : ANGESTELLTER)
∧ ∃ (ab : ABTEILUNG) ((ang ∈ ab.AbtLeiter.t ∨ ang ∈ ab.Mitarbeiter.t)
∧ ((∀ t ∈ [t0 , t∞ ] ∃ t ∈ [1/1/91, 30/6/91] t = t ) ⇒ ((ab.AbtName.t = ’Montage’)))
∧ t ∈ [t0 , t∞ ])}
Bei dieser Anfrage ist eine geöﬀnete Klammer am Ende zu schließen. Sie wurde innerhalb
der Transformation von restrict expr geöﬀnet.
Beispiel 4.32
Es wird die Beispielanfrage 4.10 betrachtet:
Welche Angestellten arbeiten im Zeitraum vom 1/1/95 bis 31/1/95 für wieviel Gehalt in
”
derjenigen Abteilung, die zwischen 1/1/91 und 30/6/91 ’Montage’
hieß ?“
119
Kapitel 4. Die TEER–Anfragesprache
get PersNr, AngName, Gehalt
from ANGESTELLTER ang, ABTEILUNG ab, AbtLeiter, Mitarbeiter
time condition of ABTEILUNG is [[ AbtName = ’Montage’ ]]
during [1/1/91, 30/6/91]
project during [1/1/95, 31/1/95]
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op temp sel expr temp proj expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= PersNr, AngName, Gehalt
teer ::=ANGESTELLTER ang, ABTEILUNG ab, AbtLeiter, Mitarbeiter
Die Ableitung des Konstrukts temp sel expr:
temp sel expr ::= "time condition of" ent rel name "is" temp sel
ent rel name ::= ABTEILUNG
temp sel ::= true time temp pred cal temp pred
true time ::= [[ bool expr ]]
bool expr ::= AbtName = ’Montage’
temp pred ::= "during"
cal temp elem ::= temp elem
temp elem ::= [1/1/91, 30/6/91]
Die Ableitung des Konstrukts temp proj expr:
temp
temp
temp
temp
proj
proj
pred
elem
expr ::= "project" temp proj
::= temp pred temp elem proj
::= "during"
proj ::= [1/1/95, 31/1/95]
Die Transformation dieser Anfrage unterscheidet sich in der Vorgehensweise nicht von
der vorherigen Transformation der Anfrage 4.9. Der Unterschied zwischen den beiden
Anfragen besteht darin, daß für diese Anfrage ein Gültigkeitszeitraum angegeben ist.
Tt (query) =
{ang.PersNr.t, ang.AngName.t, ang.Gehalt.t, t |
(ang : ANGESTELLTER)
∧ ∃ (ab : ABTEILUNG) ((ang ∈ ab.AbtLeiter.t ∨ ang ∈ ab.Mitarbeiter.t)
∧ ((∀ t ∈ [t0 , t∞ ] ∃ t ∈ [1/1/91, 30/6/91] t = t ) ⇒ ((ab.AbtName.t = ’Montage’)))
∧ ∃ t ∈ [1/1/95, 31/1/95] t = t )}
120
4.3. Transformation in den TEER–Kalkül
Beispiel 4.33
Es wird die Beispielanfrage 4.11 betrachtet:
Wann ist Müller Leiter der Abteilung ’Montage’ ?“
”
get time from ABTEILUNG ab, ANGESTELLTER ang, AbtLeiter
restrict ((AbtName = ’Montage’) and (AngName = ’Müller’))
Für diese Anfrage gilt:
query ::= get time
get time ::= "get time" "from" teer "restrict" "(" restrict attr ")"
teer ::= ABTEILUNG ab, ANGESTELLTER ang, AbtLeiter
Die Ableitung des Konstrukts restrict attr:
restrict attr ::= "(" bool expr1 ")" "and" "(" bool expr2 ")"
bool expr1 ::= AbtName = ’Montage’
bool expr2 ::= AngName = ’Müller’
Die Transformation:
Tt (query) = Tt (get time)
= { t | Tt (restrict attr) Tt (temp proj expr) [ ) ]! }
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts restrict attr:
Tt (restrict attr)
= ∃(ab : ABTEILUNG) ∧ ∃(ang : ANGESTELLTER)
(ab.AbtName.t = ’Montage’ ∧ ang.AngName.t = ’Müller’
∧ (ang ∈ ab.AbtLeiter.t)
Die Transformation des Konstrukts temp proj expr:
Tt (temp proj expr) = ∧ t ∈ [t0 , t∞ ]
da keine Projektion explizit angegeben ist.
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{t | ∃(ab : ABTEILUNG) ∧ ∃(ang : ANGESTELLTER)
(ab.AbtName.t = ’Montage’ ∧ ang.AngName.t = ’Müller’
∧ (ang = ab.AbtLeiter.t) ∧ t ∈ [t0 , t∞ ])}
Bei dieser Anfrage ist eine geöﬀnete Klammer am Ende zu schließen.
121
Kapitel 4. Die TEER–Anfragesprache
Beispiel 4.34
Es wird die Beispielanfrage 4.12 betrachtet:
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem Müller
”
Leiter der Abteilung ’Montage’ ist ?“
get AngName, PersNr, Position
from ANGESTELLTER ang
project during (get time from ABTEILUNG ab, ANGESTELLTER a
restrict ((a.AbtName = ’Montage’) and (a.AngName = ’Müller’)))
Für diese Anfrage gilt:
query ::= get attr
get attr ::= get op temp proj expr
Die Ableitung des Konstrukts get op:
get op ::= "get" attr list "from" teer
attr list ::= AngName, PersNr, Position
teer ::= ANGESTELLTER ang
Die Ableitung des Konstrukts temp proj expr:
temp
temp
temp
temp
proj
proj
pred
elem
expr ::= "project" temp proj
::= temp pred temp elem proj
::= "during"
proj ::= "(" get time ")"
Die Ableitung des Konstrukts get time:
get time ::= "get time" "from" teer "restrict" "(" restrict attr ")"
teer ::= ABTEILUNG ab, ANGESTELLTER a
Die Ableitung des Konstrukts restrict attr:
restrict attr ::= "(" bool expr1 ")" "and" "(" bool expr2 ")"
bool expr1 ::= a.AbtName = ’Montage’
bool expr2 ::= a.AngName = ’Müller’
Die Transformation:
Tt (query) = Tt (get attr)
= { Tt (get op) Tt (restrict expr) Tt (temp proj expr) [ ) ]! }
122
4.3. Transformation in den TEER–Kalkül
Im einzelnen ergeben diese Transformationen:
Die Transformation des Konstrukts get op:
Tt (get op) = Tt (attr list), t | T (teer)
= ang.AngName.t, ang.PersNr.t, ang.Position.t, t | (ang : ANGESTELLTER)
Die Transformation des Konstrukts restrict expr:
Tt (restrict expr) = " ",
da die Anfrage kein restrict expr–Konstrukt enthält und teer nur einen Entitytypnamen enthält.
Die Transformation des Konstrukts temp proj expr:
Tt (temp proj expr) = ∧ Tt (temp proj)
= ∧ ∃ t ∈ Tt (temp elem proj) t = t
= ∧ ∃ t ∈ Tt (get time) t = t
Die zu transformierende get time–Anfrage stimmt mit der obigen get time–Anfrage überein (vgl. 4.11), es muß nur t an Stelle von t gesetzt werden sowie der in der linearen
Anfrage verwendete alias–Bezeichner a für ANGESTELLTER an Stelle von ang verwendet werden.
Insgesamt ergibt sich die folgende Kalkülanfrage:
Tt (query) =
{ang.AngName.t, ang.PersNr.t, ang.Position.t, t | (ang : ANGESTELLTER)
∧ ∃ t ∈
{t | ∃(ab : ABTEILUNG) ∧ ∃(a : ANGESTELLTER)
(ab.AbtName.t = ’Montage’ ∧ a.AngName.t = ’Müller’
∧ (a = ab.AbtLeiter.t ) ∧ t ∈ [t0 , t∞ ])} t = t }
123
Kapitel 4. Die TEER–Anfragesprache
124
Kapitel 5
Exemplarische Implementierung in
SQL
Dieser Abschnitt handelt von der Realisierung der graphischen
TEER–Anfragesprache für das ORACLE–Datenbankmanagementsystem (DBMS).
Dazu werden exemplarisch die graphischen Beispielanfragen
4.5 – 4.12 aus Kapitel
4.1.3 in SQL–Anfragen übersetzt. Ein allgemein
gültiger Algorithmus wird nicht gegeben.
5.1
Voraussetzungen in ORACLE
SQL
SQL, die Structured Query Language, ist die von ORACLE–DBMS
verwendete Datenbankanfragesprache. Zunächst wird die Struktur des
select–Kommandos vorgestellt, mit dem Anfragen in SQL formuliert
werden. Die Syntax dieses Befehls ist in [KL95] angegeben.
select distinct
from
where
Attribute
( Ausgabe“)
”
Relation(en) ( Eingabe“)
”
Bedingung ;
Die select–Klausel gibt an, für welche Attribute Werte
ausgegeben werden sollen. Die Anweisung distinct sorgt dafür,
daß kein Ergebnistupel doppelt ausgegeben wird. In der
from–Klausel werden diejenigen Relationen speziﬁziert, aus denen
Attribute zu entnehmen sind. Ist ein Verbund zu bilden, d.h. bezieht
sich eine Anfrage auf mehr als eine Tabelle, so sind an dieser Stelle
mindestens zwei Tabellennamen anzugeben. Die where–Klausel gibt
125
Kapitel 5. Exemplarische Implementierung in SQL
Funktionsaufruf
add months(date,count)
greatest(date1,date2,date3,. . . )
least(date1,date2,date3,. . . )
last day(date)
months between(date1,date2)
next day(date,’day’)
new time(date,’this’,’other’)
round(date,’format’)
trunc(date,’format’)
to char(date,’format’)
to date(string,’format’)
Aufgabe
addiert count–viele Monate auf date
gibt das späteste Datum aus der Liste von Daten
zurück
gibt das früheste Datum aus der Liste von Daten
zurück
gibt das Datum des letzten Tages des Monats aus,
in dem date liegt
berechnet die Diﬀerenz date1 – date2 in Monaten
gibt das Datum des nächsten Tages namens ’day’
aus, der auf date folgt
rechnet die Angabe date von this Zeitzone1 in other
Zeitzone um
rundet einen date–Wert auf 00:00:00 des Tages date
ab, wenn date vor 12:00:00 liegt, sonst
auf den nächsten Tag 00:00:00 auf 2
setzt date auf 00:00:00 des Tages date 2
wandelt date in das Format format um
konvertiert eine Zeichenkette string in ein
ORACLE–Datum mit Format format
Tabelle 5.1: date–Funktionen in ORACLE
eine Selektionsbedingung an bzw. im Fall eines Verbunds außerdem eine
Bedingung, nach welcher dieser Verbund zu bilden ist. Die weiteren, hier
nicht angegebenen Klauseln group by, having und order by werden
nicht benötigt und daher nicht betrachtet. Eine SQL–Anweisung wird
mit einem Semikolon abgeschlossen.
Der Datentyp date
Datumsangaben werden von ORACLE in Spalten vom Datentyp
date in einem speziellen Format abgespeichert. Ein Datum besteht
für ORACLE nicht nur aus der Angabe von Tag, Monat und Jahr
sondern auch aus den zusätzlichen Angaben von Stunde, Minute und
Sekunde. Welche dieser Angaben in einer Tabelle sichtbar sind, ist
mit Hilfe eines speziellen SQL–Befehls einstellbar. Dieser
wird weiter unten vorgestellt, nachdem die Möglichkeiten zur
Formatangabe vorgestellt wurden.
1
Eine Zeitzone wird durch eine dreistellige
Buchstabenabkürzung angegeben, siehe [KL95].
2
Mit Hilfe von format können auch andere
126
5.1. Voraussetzungen in ORACLE
Auf date–Werte sind sowohl arithmetische als auch speziell
deﬁnierte Funktionen anwendbar. Die Addition von 1 auf einen
date–Wert z.B. liefert den auf dieses Datum folgenden Tag. Die
in ORACLE verfügbaren speziellen Funktionen sind in der
Tabelle 5.1 aufgeführt. Die Funktion to date wird
zur Erzeugung von Datumsangaben benötigt. Eine Zeichenkette der
Form ’1-1-1991’ wird von ORACLE nicht als Datum
erkannt. Um dies zu erreichen, ist die Zeichenkette
mit Hilfe der Funktion to date
in ein Datum umzuwandeln, wobei neben der Zeichenkette auch das
Eingabeformat
anzugeben ist. Die Zeichenkette hat dann diesem Format zu
entsprechen und wird in diesem Format gespeichert. Im Rahmen der
Erzeugung der Testdatenbank und der Beispiel–SQL–Anfragen
ist das Format ’DD-MM-YYYY’ gewählt worden. Ein Datum besteht
aus einer zweistelligen numerischen Angabe für Tag und Monat und einer
vierstelligen numerischen Angabe für das Jahr. Es gibt eine
Reihe von Möglichkeiten, das Datumsformat zu deﬁnieren, so sind auch
buchstabliche Abkürzungen oder die Verwendung vollständiger Monatsnamen
erlaubt. Eine vollständige Auﬂistung der date–Formate ist
in [KL95] zu ﬁnden.
Das Standard–Ausgabeformat von date–Spalten ist in
ORACLE von der Form ’DD--MMM-YY’. Das bedeutet, daß
unabhängig vom Eingabeformat Datumsangaben durch eine zweistellige
numerische Abkürzung für Tag und Jahr sowie eine dreistellige
buchstabliche Abkürzung für den Monat repräsentiert werden.
Mit Hilfe der folgenden SQL–Anweisung wird das Ausgabeformat
auf das oben gewählte Eingabeformat gesetzt:
alter session set NLS_DATE_FORMAT = ’DD-MM-YYYY’;
Der aktuelle Zeitpunkt tnow kann in ORACLE durch eine einfache
SQL–Anweisung erzeugt werden. Die Funktion sysdate gibt
das aktuelle Datum mit der aktuellen Zeit zurück. sysdate wird
in Anfragen wie ein numerisch angegebenes Datums verwendet.
Zeitpunkte, auf die auf– oder abgerundet werden soll, spezifiziert
werden, siehe [KL95].
127
Kapitel 5. Exemplarische Implementierung in SQL
5.2
Übersetzung der Beispielanfragen
Bei der Übersetzung der TEER–Beispielanfragen wird von der in
Kapitel 3.5 beschriebenen temporalen Testdatenbank
ausgegangen. Der Inhalt dieser Datenbank ist in den Tabellen
3.4 – 3.13 angegeben. Das bedeutet
insbesondere, daß sich die temporale Hierarchie der Schemaobjekte in den
Tabelleneinträgen widerspiegelt. Diese Voraussetzung macht eine
temporale Kontrolle in der Anfrage unnötig, wodurch sich
die Anfragen verkürzen. Dieses optimiert somit die Erstellung und
Bearbeitung der Anfragen. Konstrukte und Bezeichner werden in den allgemeinen
Erklärungen mit
dem Index SQL versehen, um bei Namensgleichheiten eine Verwechslung
mit den Konstrukten und Bezeichnern der linearen Schreibweise aus
Kapitel 4.1.3 zu vermeiden.
Ausgegangen wird im folgenden von einer im TEER–Anfrage–Editor
modellierten Anfrage.
5.2.1
Übersetzung des Get–Operators
Sämtliche im Editor markierten Attribute werden mit Hilfe der
select–Klausel ausgegeben:
select
attr listSQL ,
greatest(ent rel comp abbrevSQL .vt from
[ , ent rel comp abbrevSQL .vt from ]∗ )
least(ent rel comp abbrevSQL .vt to
[ , ent rel comp abbrevSQL .vt to ]∗ )
from ent nameSQL [ , ent rel nameSQL ]∗ [ ,
comp nameSQL ]∗
[ where join condSQL ]
wobei die Attributnamen in attr listSQL aus den
Attributnamen attr nameSQL und dem zugehörigen
Entitytyp– oder Relationshiptypnamen ent rel nameSQL
gebildet werden:
attr listSQL = ent rel nameSQL .attr nameSQL
[ , ent rel nameSQL .attr nameSQL ]∗
128
5.2. Übersetzung der Beispielanfragen
Dieses sichert die Eindeutigkeit der Attributnamen
bei Anfragen ab, die einen Join über mehrere Tabellen beinhalten.
Sind alle Attributnamen von vornherein eindeutig, oder bezieht sich
eine Anfrage nur auf eine Tabelle, so kann auf die Angabe des Typnamens
innerhalb des Attributnamens verzichtet werden. Ist die Angabe des
Typnamens erforderlich, kann
die Attributliste durch die Verwendung von alias–Bezeichnern
abbrevSQL für die Namen ent rel nameSQL
verkürzt werden:
attr listSQL = abbrevSQL .attr nameSQL
[ , abbrevSQL .attr nameSQL ]∗
Die Bezeichner abbrevSQL sind in der from–Klausel zu
deklarieren. Sie werden dort direkt hinter dem jeweilig zugehörigen
Namen angegeben.
Zusätzlich zu den Attributen werden Anfang und Ende des
Gültigkeitszeitraums für jedes Ergebnistupel mit ausgegeben. Dieser
läßt sich aus dem spätesten vt from–Eintrag und dem
frühesten vt to–Eintrag der Tabellen
ent rel comp nameSQL berechnen. Mit den in den
Funktionsaufrufen von greatest und least verwendeten
alias–Bezeichnern ent rel comp abbrevSQL sind solche
Tabellen gemeint, die für Ausgangstypen von Typkonstruktionen,
Relationships und mehrwertige Komponenten angelegt wurden. In den
Aufrufen dieser beiden Funktionen werden dieselben Tabellen angesprochenen.
Da nach der temporalen Hierarchie die temporalen Elemente
von Ausgangstypen von Typkonstruktionen, Relationships und Komponenten
kleiner als die der zugehörigen Entities sind, reicht es aus nur diese zu
betrachten. Bezieht sich eine Anfrage jedoch nur auf ein einziges,
allein stehendes Entity oder beinhaltet eine Anfrage nur ein
Relationship, eine Komponente oder Typkonstruktion, so reicht es aus, die
vt from– und vt to–Werte der entsprechenden Tabelle
auszugeben. Die Funktionen greatest und least brauchen nicht
benutzt zu werden.
Eine besondere Ausnahme bei der Angabe der Komponentennamen ist
gegeben, falls zwischen zwei Entitytypen mehr als eine Komponente
129
Kapitel 5. Exemplarische Implementierung in SQL
existiert. In einem solchen Fall werden die Funktionen greatest
und least auf vt from– und
vt to–Tabelleneinträge angewendet, die für das selektierte Tupel
nicht existieren müssen. Jedes Tupel wird auf Grund einer der
Komponenten ausgewählt, und es ist nicht zwingend notwendig, daß auch
eine Verbindung über die anderen Komponenten vorhanden ist. Die
Beispiele 4.9 und 4.10 beinhalten diesen
Fall. Einträge zu AbtLeiter müssen nicht unbedingt in der Tabelle
Mitarbeiter enthalten sein. Daher sind in solchen Fällen mehrere
Anfragen zu formulieren. Diese Problematik wird später bei der
Übersetzung der Anfragen 4.9 und 4.10
neu aufgegriﬀen.
Das im Editor beﬁndliche TEER–Schema sei minimal, d.h. es beﬁnden
sich keine unnötigen Elemente im Editor. In die from–Klausel
werden daher alle im Editor dargestellten Entities und Relationships
namentlich aufgenommen. Sie sind in der Datenbank durch eigene Tabellen
dargestellt. Mehrwertige Komponenten sind ebenfalls durch eigene
Tabellen dargestellt, und nur Namen solcher Komponenten werden der
from–Klausel hinzugefügt. Die Verwendung von
alias–Bezeichnern ist für sämtliche in der from–Klausel
angegebenen Tabellennamen erlaubt und, falls sie bei der Bildung von
Attributnamen verwendet werden, nötig.
from
ent rel nameSQL abbrevSQL
[ , ent rel nameSQL abbrevSQL ]∗
[ , comp nameSQL abbrevSQL ]∗
Das in der where–Klausel enthaltene Konstrukt
join condSQL beinhaltet die Bedingungen, nach denen ein
eventueller Verbund mehrerer Tabellen zu bilden ist. Dazu werden die
Surrogate einer jeden Tabellen benutzt, die nach dem Tabellennamen benannt
sind:
where
ent rel comp nameSQL $ = ent rel comp nameSQL $
[ and ent rel comp nameSQL $ = ent rel comp nameSQL $ ]∗
Eine Übersetzung der Standard–Projektion ist nicht nötig, da alle
in den Spalten vt from und vt to abgespeicherten Daten
in der geordneten Menge aller Zeitpunkte T und somit zwischen
t0 und t∞ liegen.
130
5.2. Übersetzung der Beispielanfragen
5.2.2
Übersetzung des Restrict–Operators
Jede in einer condition box formulierte Bedingung wird mit
and an die where–Klausel angefügt. Gibt es eine solche in
der bisherigen Anfrage noch nicht, wird sie jetzt eingeführt:
[ where | and ]
bool exprSQL
[ and bool exprSQL ]∗
wobei die boolesche Bedingung bool exprSQL direkt aus der
condition box übernommen wird. Der in der Formulierung von
bool expr verwendete Attributname ist um
den zugehörigen alias–Bezeichner zu erweitern.
Beispiel 5.1
Die zu der graphischen Anfrage 4.5 auf Seite
74 äquivalente SQL–Anfrage ist somit:
select distinct ChargenNr, ProdName,
greatest(g.vt_from, pr.vt_from),
least(g.vt_to, pr.vt_to)
from Produkt p, Abteilung ab, Firma f, produziert pr, gehoert_zu g
where f.Firma$ = g.Firma$ and
ab.Abteilung$ = g.Abteilung$ and
pr.Abteilung$ = ab.Abteilung$ and
p.Produkt$ = pr.Produkt$ and
ab.AbtName = ’Montage’ and
f.Firmenname = ’Prima’;
Das Ergebnis dieser Anfrage ist die folgende Tabelle:
CHARGENNR PRODNAME
FROM
TO
---------- ------------------------- ---------- ---------131
Kapitel 5. Exemplarische Implementierung in SQL
55778 Rennrad
01-01-1985 31-12-1986
56889 Rennrad
01-01-1990 30-06-1990
57911 Rennrad
01-01-1990 31-12-1990
57911 Rennrad
01-01-1991 30-04-1991
57911 Rennrad
01-05-1991 31-05-1991
57911 Rennrad
01-06-1991 31-12-1992
98102 Rennrad
01-09-1989 31-12-1990
98102 Rennrad
01-01-1991 30-04-1991
98102 Rennrad
01-05-1991 31-05-1991
98102 Rennrad
01-06-1991 31-12-1995
Die ausgegebenen Tupel besitzen die gewünschten Eigenschaften:
Das Surrogat der Firma Prima“ ist 1000, die der Abteilung
”
Montage“ haben die Werte 5000, 5012, 5034 und 5222. Der Tabelle
”
gehört zu sind die folgenden Beziehungen zwischen der Firma
”
Prima“ und der Abteilung Montage“ zu entnehmen:
”
FIRMA$ ABTEILUNG$ VT_FROM
VT_TO
-------- ---------- ---------- ---------1000
5000 01-01-1985 31-12-1990
1000
5012 01-01-1991 30-04-1991
1000
5034 01-06-1991 31-12-1995
1000
5222 01-05-1991 31-05-1991
Die von der Abteilung Montage“ produzierten Produkte sind
”
der Tabelle produziert zu ﬁnden:
132
5.2. Übersetzung der Beispielanfragen
PRODUKT$ ABTEILUNG$ VT_FROM
VT_TO
---------- ---------- ---------- ----------4000
5000
01-01-1985 31-12-1986
4005
5000
01-01-1990 30-06-1990
4010
5000
01-01-1990 31-12-1990
4010
5012
01-01-1991 30-04-1991
4010
5222
01-05-1991 31-05-1991
4010
5034
01-06-1991 31-12-1992
4015
5000
01-09-1989 31-12-1990
4015
5012
01-01-1991 30-04-1991
4015
5222
01-05-1991 31-05-1991
4015
5034
01-06-1991 31-12-1995
Da die Intervallangaben der Tabelle produziert kleiner als die der
Tabelle gehoert zu sind, werden die Zeitangaben der Tabelle
produziert zusammen mit den zu den Surrogaten Produkt$ gehörigen
Angaben der Chargennummer und dem Produktnamen aus der Tabelle
Produkt als Ergebnis ausgegeben.
5.2.3
Übersetzung des Query–result–link–Operators
Mit Hilfe eines Query–result–link–Operators wird eine boolesche Bedingung
für ein Attribut formuliert. Das betreﬀende Attribut soll mit dem Ergebnis
einer Unteranfrage verglichen werden. Nach der Deﬁnition des
Query–result–link–Operators besteht das Ergebnis der Unteranfrage aus
einem oder einer Menge von Werten desselben Attributs. Die von der
Unteranfrage selektierten Werte müssen keine temporalen Bedingungen
erfüllen. Nach der durch den TEER–Kalkül festgelegten Semantik,
muß auf die Ausgabewerte einer Query–result–link–Unteranfrage die
133
Kapitel 5. Exemplarische Implementierung in SQL
Standard–Projektion ausgeführt werden.
Diese erfüllen, wie bereits oben erklärt, alle in der temporalen
Datenbank enthaltenen Werte automatisch. Die durch den
Query–result–link formulierte Bedingung wird in einer SQL–Anfrage
in die where–Klausel mit aufgenommen.
Beispiel 5.2
Die Beispielanfrage 4.6 auf Seite
75 vergleicht mit Hilfe des
Query–result–link–Operators das Gehalt aller Angestellten mit dem
Preis des Produkts Rennrad“. Das in der übergeordneten
”
Anfrage verwendete Vergleichsprädikat >all ist auch in SQL
deﬁniert. An Stelle der in der graphischen Anfrage darauf folgenden
Variable x wird in SQL direkt die Unteranfrage gesetzt. Die
Unteranfrage wird in folgende SQL–Anweisung übersetzt:
select distinct StPreis
from Produkt
where ProdName = ’Rennrad’;
Die Ausgabe von Gültigkeitszeiträumen ist nicht notwendig und
würde den direkten Vergleich mit den Gehältern der Angestellten
unmöglich machen. Da die Unteranfrage dann eine Menge von
Ergebnistupeln liefern würde. Der Gültigkeitszeitraum des
Unteranfrageergebnisses ist auch nicht von Interesse. Für den Fall,
daß das Ergebnis einer Anfrage von Gültigkeitszeiträumen abhängig sein soll,
steht der Time–link–Operator zur Verfügung.
Die zur Anfrage 4.6 äquivalente SQL–Anfrage ist
somit:
select distinct PersNr, AngName, Gehalt, vt_from, vt_to
from Angestellter
where Gehalt > all (select distinct StPreis
134
5.2. Übersetzung der Beispielanfragen
from Produkt
where ProdName =’Rennrad’);
Das Ergebnis dieser Anfrage besteht aus der ganzen Relation
Angestellter, da alle Angestellten mehr als das teuerste Rennrad
verdienen. Auf die Verwendung von alias–Bezeichnern kann verzichtet
werden, da sich sowohl die übergeordnete Anfrage als auch die
Unteranfrage jeweils nur auf ein Entity beziehen. Die Attributnamen
sind daher eindeutig.
Die Ergebnisrelation:
PERSNR ANGNAME
GEHALT VT_FROM
VT_TO
---------- --------------- ---------- ---------- ---------234 Mueller
5800 01-01-1985 31-12-1990
234 Mueller
6400 01-01-1991 31-12-1995
312 Hinz
5300 01-03-1987 31-12-1989
312 Hinz
6300 01-01-1990 31-12-9999
654 Schulz
6400 01-04-1989 31-12-9999
717 Kunz
8000 01-07-1990 31-12-1995
717 Kunz
8500 01-01-1996 31-12-9999
789 Vogel
3800 01-01-1990 31-12-9999
813 Schmidt
4000 01-01-1985 31-12-1987
877 Gross
5000 01-01-1985 31-12-9999
909 Klein
4500 01-01-1987 31-12-1990
921 Schiller
4000 01-01-1985 31-12-1995
987 Maier
7500 01-04-1990 30-09-1995
135
Kapitel 5. Exemplarische Implementierung in SQL
5.2.4
Übersetzung des temporalen Projektionsoperators
Eine temporale Projektion schränkt die Menge der
selektierten Daten auf einen Gültigkeitszeitintervall ein (sofern nicht die
Standard–Projektion angewendet wird). Die Attribute vt from
und vt to der Tabellen, die Datenabhängigkeiten
repräsentieren, müssen jetzt zusätzlich Bedingungen erfüllen. Das
projizierte temporale Element sei ein konstantes Intervall.
Entsprechend dem in der graphischen Anfrage verwendetem Prädikat
werden mehrere Bedingungen an die where–Klausel mit and
angefügt. Es müssen alle vt from– und vt to–Werte
derjenigen Tabellen, die in der Liste der Namen
ent rel comp nameSQL beim Aufruf der Funktionen
greatest und least angegeben sind, mit dem projizierten
Intervall verglichen werden.
Übersetzung der Prädikate
Das konstante Intervall sei [d from,d to], das
Vergleichsprädikat der Tabelle [vt from,vt to]. Die
umgangssprachlichen temporalen Prädikate der Menge PREDTDT werden zu
folgenden SQL–Anweisungen übersetzt:
1. Anfrage:
[vt from, vt to] before
[d from,d to]
SQL:
2. Anfrage:
vt to < to date(’d from’,’DD-MM-YYYY’)
[vt from, vt to] after
[d from,d to]
SQL:
3. Anfrage:
vt from > to date(’d to’,’DD-MM-YYYY’)
[vt from, vt to] during
[d from,d to]
SQL:
vt from >= to date(’d from’,’DD-MM-YYYY’)
and
vt to <= to date(’d to’,’DD-MM-YYYY’)
136
5.2. Übersetzung der Beispielanfragen
4. Anfrage:
[vt from, vt to] superior
[d from,d to]
SQL:
vt from <= to date(’d from’,’DD-MM-YYYY’)
and
vt to >= to date(’d to’,’DD-MM-YYYY’)
5. Anfrage:
[vt from, vt to] equivalent
[d from,d to]
SQL:
vt from = to date(’d from’,’DD-MM-YYYY’)
and
vt to = to date(’d to’,’DD-MM-YYYY’)
6. Anfrage:
[vt from, vt to] adjacent
[d from,d to]
SQL:
to date(’d from’,’DD-MM-YYYY’) −
vt to = 1 or
vt from −
to date(’d to’,’DD-MM-YYYY’) = 1
7. Anfrage:
[vt from, vt to] overlap
[d from,d to]
SQL:
vt from <= to date(’d to’,’DD-MM-YYYY’)
and
vt to >= to date(’d from’,’DD-MM-YYYY’)
Obwohl im Kalkül nicht alle diese Prädikate zugelassen waren, wurden
hier SQL–Anweisungen für alle gegeben, da sie alle in der
TEER–Anfragesprache zugelassen sind.
Beispiel 5.3
Die Beispielanfrage 4.7 von Seite
77 ist äquivalent zu der folgenden SQL–Anfrage.
137
Kapitel 5. Exemplarische Implementierung in SQL
select distinct ChargenNr, ProdName, StPreis,
greatest(l.vt_from, z.vt_from, p.vt_from),
least(l.vt_to, z.vt_to, p.vt_to)
from Produkt p, Vorprodukt v, Zulieferfirma z, Firma f, liefert l
where f.Firma$ = z.Firma$ and
z.Zulieferfirma$ = l.Zulieferfirma$ and
l.Vorprodukt$ = v.Vorprodukt$ and
v.Produkt$ = p.Produkt$ and
f.Firmenname = ’Prima’ and
l.vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
z.vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
p.vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
l.vt_to <= to_date(’31-12-1991’,’DD-MM-YYYY’) and
z.vt_to <= to_date(’31-12-1991’,’DD-MM-YYYY’) and
p.vt_to <= to_date(’31-12-1991’,’DD-MM-YYYY’);
Die Ergebnisrelation dieser Anfrage ist leer, da es keine Tupel gibt,
die die temporale Projektion erfüllen.
Es gibt zwar Produkte, die während des projizierten
Intervalls [01-01-1991,31-12-1991] von der Firma
Prima“ produziert wurden, aber nicht innerhalb. Das ist
”
augenscheinlich dasselbe, aber das during–Prädikat gibt den
Wert true nur dann zurück, wenn ein Intervall ganz innerhalb
eines anderen liegt.
Wird das Intervall [1/1/91,31/12/92] projiziert,
select distinct ChargenNr, ProdName, StPreis,
138
5.2. Übersetzung der Beispielanfragen
greatest(l.vt_from, z.vt_from, p.vt_from),
least(l.vt_to, z.vt_to, p.vt_to)
from Produkt p, Vorprodukt v, Zulieferfirma z, Firma f, liefert l
where f.Firma$ = z.Firma$ and
z.Zulieferfirma$ = l.Zulieferfirma$ and
l.Vorprodukt$ = v.Vorprodukt$ and
v.Produkt$ = p.Produkt$ and
f.Firmenname = ’Prima’ and
l.vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
z.vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
p.vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
l.vt_to <= to_date(’31-12-1992’,’DD-MM-YYYY’) and
z.vt_to <= to_date(’31-12-1992’,’DD-MM-YYYY’) and
p.vt_to <= to_date(’31-12-1992’,’DD-MM-YYYY’);
enthält das Ergebnis ein Tupel:
CHARGENNR PRODNAME
STPREIS FROM
TO
---------- ------------------------- ---------- ---------- ---------57911 Rennrad
5.2.5
1000 01-01-1991 31-12-1992
Übersetzung des True–time–Operators
Graphische Anfragen, die den True–time–Operator beinhalten, werden zu
geschachtelten SQL–Anfragen übersetzt. Eine True–Time ist der
Gültigkeitszeitraum einer booleschen Bedingung. Dieser Zeitraum wird
139
Kapitel 5. Exemplarische Implementierung in SQL
mit Hilfe einer einfachen select . . . from . . . where–Anfrage
ermittelt. Als Ergebnis liefert diese Anfrage eine Menge von Intervallen.
Beispiel 5.4
Der Gültigkeitszeitraum der Bedingung Auslastung > 80“ aus
”
Beispiel 4.8 von Seite 78 wird mit
Hilfe der Anfrage
select distinct vt_from, vt_to
from produziert
where Auslastung > 80;
bestimmt. Die Ergebnisrelation:
VT_FROM
VT_TO
---------- ---------01-01-1990 30-06-1990
01-01-1990 31-12-1990
01-01-1996 31-12-9999
Diese Intervallergebnisse führen zu drei Anfragen. In Beispiel
4.8 liefert der True–time–Operator das zu
projizierende Element einer temporalen Projektion.
So entstehen nach der oben beschriebenen
Übersetzung des Projektionsoperators drei Anfragen. Bei der ersten
Anfrage wird das Intervall [01-01-1990,30-06-1990], der zweiten das
Intervall [01-01-1990,31-12-1990] und der dritten das Intervall
[01-01-1996,31-12-9999] projiziert. Ein direkter Vergleich der
vt from– und
vt to–Werte derjenigen Tabellen, die von den Funktionen
greatest und least zur Bestimmung des Gültigkeitszeitraums
betrachtet werden, mit der Unteranfrage ist nicht möglich. Ein
solcher Vergleich hätte die Form:
140
5.2. Übersetzung der Beispielanfragen
vt_from >= any (select distinct vt_from
from produziert
where Auslastung > 80) and
vt_to <= any (select distinct vt_to
from produziert
where Auslastung > 80);
Dieser Vergleich führt aber dazu, daß nicht die obigen
Intervalle projiziert werden, sondern das sich aus den Unteranfragen
größte bildende Intervall; d.h. das Intervall [01-01-1990,31-12-9999] wird
projiziert. Damit werden aber auch Produkte selektiert, die in dem
Intervall [01-01-1991,31-12-1995] liegen. Dieses Intervall ist nicht
in dem zu projizierenden Zeitraum enthalten, aber in dem sich größten
bildenden Intervall. Um die richtigen Zeiträume zu projizieren, sind
somit drei Anfragen zu formulieren, in denen jeweils eines der
berechneten Intervalle projiziert wird.
1.
select distinct ChargenNr, ProdName, AbtName, pr.vt_from, pr.vt_to
from Produkt p, produziert pr, Abteilung a
where p.Produkt$ = pr.Produkt$ and
pr.Abteilung$ = a.Abteilung$ and
pr.vt_from >= to_date(’01-01-1990’,’DD-MM-YYYY’) and
pr.vt_to <= to_date(’30-06-1990’,’DD-MM-YYYY’);
2.
select distinct ChargenNr, ProdName, AbtName, pr.vt_from, pr.vt_to
from Produkt p, produziert pr, Abteilung a
where p.Produkt$ = pr.Produkt$ and
141
Kapitel 5. Exemplarische Implementierung in SQL
pr.Abteilung$ = a.Abteilung$ and
pr.vt_from >= to_date(’01-01-1990’,’DD-MM-YYYY’) and
pr.vt_to <= to_date(’31-12-1990’,’DD-MM-YYYY’);
3.
select distinct ChargenNr, ProdName, AbtName, pr.vt_from, pr.vt_to
from Produkt p, produziert pr, Abteilung a
where p.Produkt$ = pr.Produkt$ and
pr.Abteilung$ = a.Abteilung$ and
pr.vt_from >= to_date(’01-01-1996’,’DD-MM-YYYY’) and
pr.vt_to <= to_date(’31-12-9999’,’DD-MM-YYYY’);
Auf die Verwendung der Funktionen greatest und least in
der select–Klausel kann
in diesem Beispiel verzichtet werden, da das Relationship
produziert das einzige in diese Anfrage einbezogene TEER–Konzept ist,
das in eine Datenabhängigkeit darstellende Tabelle transformiert
worden ist. Die vt from– und vt to–Werte der Tabelle
produziert können somit direkt ausgegeben werden.
Diese drei Anfragen können zu einer einzigen Anfrage mit Hilfe der
SQL–Anweisung union kombiniert werden. Die
union–Anweisung ist auf zwei Anfragen anwendbar, deren
Ausgabeformate identisch sind. Das Ausgabeformat ist durch
die Anzahl der ausgegebenen Werte zusammen mit der Reihenfolge der Datentypen
festgelegt.
Die union–Anweisung kombiniert die Ausgabetabellen solch
passender Anfragen zu einer gemeinsamen, wobei Duplikate eliminiert
werden.
select distinct ChargenNr, ProdName, AbtName, pr.vt_from, pr.vt_to
142
5.2. Übersetzung der Beispielanfragen
from Produkt p, produziert pr, Abteilung a
where p.Produkt$ = pr.Produkt$ and
pr.Abteilung$ = a.Abteilung$ and
pr.vt_from >= to_date(’01-01-1990’,’DD-MM-YYYY’) and
pr.vt_to <= to_date(’30-06-1990’,’DD-MM-YYYY’)
union
(select distinct ChargenNr, ProdName, AbtName, pr.vt_from, pr.vt_to
from Produkt p, produziert pr, Abteilung a
where p.Produkt$ = pr.Produkt$ and
pr.Abteilung$ = a.Abteilung$ and
pr.vt_from >= to_date(’01-01-1990’,’DD-MM-YYYY’) and
pr.vt_to <= to_date(’31-12-1990’,’DD-MM-YYYY’)
union
select distinct ChargenNr, ProdName, AbtName, pr.vt_from, pr.vt_to
from Produkt p, produziert pr, Abteilung a
where p.Produkt$ = pr.Produkt$ and
pr.Abteilung$ = a.Abteilung$ and
pr.vt_from >= to_date(’01-01-1996’,’DD-MM-YYYY’) and
pr.vt_to <= to_date(’31-12-9999’,’DD-MM-YYYY’));
Das Ergebnis dieser Anfrage ist die folgende Tabelle. Alle
vt from– und vt to–Werte liegen in dem durch die boolesche
Bedingung Auslastung >80“ bestimmten Zeitraum.
”
CHARGENNR
PRODNAME
ABTNAME
143
FROM
TO
Kapitel 5. Exemplarische Implementierung in SQL
---------- ------------------------- --------------- ---------- ---------98102 Rennrad
Lackiererei
01-01-1996 31-12-9999
56889 Rennrad
Montage
01-01-1990 30-06-1990
57911 Rennrad
Montage
01-01-1990 31-12-1990
5.2.6
Übersetzung des temporalen Selektionsoperators
Der temporale Selektionsoperator besteht aus einem
True–time–Operator, einem temporalen Prädikat und einem
Gültigkeitszeitraum, die auf einen Entity– oder Relationshiptyp
angewendet werden. Dieser Selektionsoperator wird zu einer
SQL–Unteranfrage übersetzt. Die Unteranfrage liefert als Ergebnis
das zeitinvariante Surrogat t inv$.
Beispiel 5.5
Die Selektion aus Beispiel 4.9 auf Seite 80
wird in die SQL–Anweisung
select distinct t_inv$
from Abteilung
where AbtName = ’Montage’ and
vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
vt_to <= to_date(’30-06-1991’,’DD-MM-YYYY’);
übersetzt. Diese Unteranfrage wird in einer where–Klausel einer
übergeordneten Anfrage aufgerufen. Über das Surrogat t inv$
werden alle Mitarbeiter und Abteilungsleiter, die jemals in der
entsprechenden Abteilung gearbeitet haben, arbeiten oder arbeiten werden,
selektiert. Die obige Anfrage liefert das zeitinvariante Surrogat
t inv$ = 995000. Die zu diesem Surrogat t inv$ gehörigen
Surrogate Abteilung$ sind 5000, 5012, 5034 und 5222. Alle
Mitarbeiter und Abteilungsleiter, die zu diesen Abteilungen gehören,
144
5.2. Übersetzung der Beispielanfragen
werden als Ergebnis ausgegeben.
Wie bereits oben erwähnt ist eine graphische Anfrage, die zwei
Komponenten zwischen zwei Entitytypen beinhaltet, nicht in eine SQL–
Anfrage übersetzbar. Es müssen zwei Anfragen formuliert werden,
wobei sich die eine auf die Komponente AbtLeiter, die andere auf die
Komponente Mitarbeiter bezieht. Da beide Anfragen dasselbe
Ausgabeformat besitzen, können sie über die union–Anweisung
zu einer einzigen Anfrage zusammengesetzt werden. Die SQL–Anfrage
für Beispiel 4.9 lautet:
select distinct PersNr, AngName, Gehalt, mit.vt_from, mit.vt_to
from Angestellter ang, Abteilung ab, Mitarbeiter mit
where ab.Abteilung$ = mit.Abteilung$ and
mit.Mitarbeiter = ang.Angestellter$ and
ab.t_inv$ = (select distinct t_inv$
from Abteilung
where AbtName = ’Montage’ and
vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
vt_to <= to_date(’30-06-1991’,’DD-MM-YYYY’))
union
select distinct PersNr, AngName, Gehalt, ab.vt_from, ab.vt_to
from Angestellter ang, Abteilung ab
where ab.AbtLeiter = ang.Angestellter$ and
ab.t_inv$ = (select distinct t_inv$
from Abteilung
where AbtName = ’Montage’ and
vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
145
Kapitel 5. Exemplarische Implementierung in SQL
vt_to <= to_date(’30-06-1991’,’DD-MM-YYYY’));
Die Ergebnisrelation:
PERSNR ANGNAME
GEHALT VT_FROM
---------- --------------- ---------- ---------
VT_TO
----------
234 Mueller
5800 01-01-1985 31-12-1990
312 Hinz
6300 01-06-1991 31-12-1995
654 Schulz
6400 01-05-1991 31-05-1991
789 Vogel
3800 01-01-1990 31-12-1999
813 Schmidt
4000 01-01-1985 31-12-1987
877 Gross
5000 01-01-1985 31-12-1987
909 Klein
4500 01-01-1987 31-12-1990
921 Schiller
4000 01-01-1985 31-12-1990
921 Schiller
4000 01-01-1991 30-04-1991
921 Schiller
4000 01-05-1991 31-05-1991
921 Schiller
4000 01-06-1991 31-12-1994
987 Maier
7500 01-01-1991 30-04-1991
Beispiel 5.6
Die graphische Anfrage 4.10 auf Seite
81 entspricht der Anfrage 4.9,
erweitert um eine temporale Projektion. Es wird das Zeitintervall
[1/1/95,31/1/95] projiziert. Die Anfrage hat, nach dem bisherigen
Übersetzungsschema vorgehend, unter Verwendung der SQL–Anfrage
5.5 die Form:
146
5.2. Übersetzung der Beispielanfragen
select distinct PersNr, AngName, Gehalt,
mit.vt_from, mit.vt_to
from Angestellter ang, Abteilung ab, Mitarbeiter mit
where ab.Abteilung$ = mit.Abteilung$ and
mit.Mitarbeiter = ang.Angestellter$ and
ab.t_inv$ = (select distinct t_inv$
from Abteilung
where AbtName = ’Montage’ and
vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
vt_to <= to_date(’30-06-1991’,’DD-MM-YYYY’)) and
mit.vt_from >= to_date(’01-01-1995’,’DD-MM-YYYY’) and
mit.vt_to <= to_date(’31-01-1995’,’DD-MM-YYYY’)
union
select distinct PersNr, AngName, Gehalt, ab.vt_from, ab.vt_to
from Angestellter ang, Abteilung ab, Mitarbeiter mit
where ab.AbtLeiter = ang.Angestellter$ and
ab.t_inv$ = (select distinct t_inv$
from Abteilung
where AbtName = ’Montage’ and
vt_from >= to_date(’01-01-1991’,’DD-MM-YYYY’) and
vt_to <= to_date(’30-06-1991’,’DD-MM-YYYY’)) and
ab.vt_from >= to_date(’01-01-1995’,’DD-MM-YYYY’) and
ab.vt_to <= to_date(’31-01-1995’,’DD-MM-YYYY’);
147
Kapitel 5. Exemplarische Implementierung in SQL
Wie der Ergebnisrelation der Anfrage 4.9 zu entnehmen
ist, gibt es keine Angestellten, die die temporale Projektion
erfüllen. Es gibt zwar Personen, die während des projizierten
Intervalls [01-01-1995,31-01-1995] in der Abteilung
”
Montage“ gearbeitet haben, aber nicht innerhalb. Daher ist die
Ergebnisrelation der SQL–Anfrage zu Beispiel 4.10 leer.
5.2.7
Übersetzung des Time–link–Operators
Das Vorgehen bei der Übersetzung des Time–link–Operators unterscheidet
sich kaum vom bisher beschriebenen. Das Ergebnis einer
Time–link–Anfrage ist ein temporales Element. Dieses Element gibt
denjenigen Zeitraum an, in dem die selektierten Tupel gültig sind. Die
select–Klausel der SQL–Anweisung beinhaltet somit keine
Attributliste attr listSQL sondern besteht aus der
Angabe der Zeitfunktionen greatest und least, sofern der
Time–link–Operator nicht im Rahmen einer temporalen Projektion oder
Selektion benutzt wird.
select distinct greatest(ent rel comp abbrevSQL .vt from
[ , ent rel comp abbrevSQL .vt from ]∗ )
least(ent rel comp abbrevSQL .vt to
[ , ent rel comp abbrevSQL .vt to ]∗ )
Beispiel 5.7
Die Anfrage 4.11 von Seite 83
repräsentiert den Fall, daß ein temporales Element als Endergebnis
ausgegeben werden soll. Die zu dieser graphischen Anfrage
äquivalente SQL–Anweisung ist demnach:
select distinct ab.vt_from, ab.vt_to
from Abteilung ab, Angestellter ang
where ab.AbtLeiter = ang.Angestellter$ and
AbtName = ’Montage’ and
AngName = ’Mueller’;
148
5.2. Übersetzung der Beispielanfragen
Da die Anfrage 4.11 keine Relationshiptypen oder
Typkonstruktionen beinhaltet, sondern sich nur auf eine einzige
Komponente bezieht, kann auf die Verwendung der Funktionen
greatest und least verzichtet werden.
Das Ergebnis dieser Anfrage besteht aus einem Tupel, da der
Angestellter Müller“ nur einmal Leiter der
”
Abteilung Montage“ war.
”
VT_FROM
VT_TO
---------- ---------01-01-1985 31-12-1990
Beispiel 5.8
Die Beispielanfrage 4.12 von Seite
84 ist aus einem Time–link und einer temporalen
Projektion zusammengesetzt. Bei der Übersetzung einer solchen Projektion
bestehen dieselben Schwierigkeiten wie bei der Übersetzung einer
projizierten True–time. Um den Gültigkeitszeitraum korrekt zu
projizieren, muß der projizierte Zeitraum bekannt sein. Besteht der
Gültigkeitszeitraum aus mehreren Intervallen, ist eine
Anfrage, die das Ergebnis eines Time–links projiziert, nicht in eine
einzige SQL–Anfrage übersetzbar. Die Anfragen können jedoch durch
die union–Anweisung zu einer Anfrage zusammengefügt werden.
Dieses ist bei der Beispielanfrage 4.12 nicht
notwendig, da die get time–Unteranfrage nur ein einziges
Intervall als Ergebnis zurückgibt. Die verwendete Unteranfrage ist
identisch der Anfrage 4.11.
Die Fortsetzung der der Anfrage 4.12 entsprechenden SQL–Anfrage ist
folglich:
select distinct PersNr, AngName, Position, ang.vt_from, ang.vt_to
from Angestellter ang
149
Kapitel 5. Exemplarische Implementierung in SQL
where ang.vt_from >= to_date(’01-01-1985’,’DD-MM-YYYY’) and
ang.vt_to <= to_date(’31-12-1990’,’DD-MM-YYYY’);
Das Ergebnis der obigen SQL–Anfrage ist die folgende Tabelle:
PERSNR ANGNAME
POSITION
VT_FROM
VT_TO
---------- --------------- -------------------- ---------- ---------234 Mueller
AbtLeiter
01-01-1985 31-12-1990
312 Hinz
AbtLeiter
01-05-1987 31-12-1989
813 Schmidt
Monteur
01-01-1985 31-12-1987
909 Klein
Techniker
01-01-1987 31-12-1990
150
Kapitel 6
Kritik und Ausblick
In diesem Kapitel werden kritische Anmerkungen zum Entwurf der vorgestellten TEER–
Anfragesprache sowie des TEER–Kalküls gemacht. Desweiteren werden mögliche Spracherweiterungen vorgestellt.
Kritik
Im Rahmen dieser Diplomarbeit ist es gelungen, eine eindeutige Syntax und Semantik für
eine graphische temporale Anfragesprache, die TEER–Anfragesprache, zu deﬁnieren. Zur
Festlegung der Semantik wurde zwar die Syntax der der TEER–Anfragesprache sowie des
zugehörigen TEER–Schemas eingeschränkt, aber auch diese eingeschränkte Sprache ist
sehr mächtig. Beleg dafür sind die Beispielanfragen aus Kapitel 4.1. Das Konzern–Schema,
an das alle Beispielanfragen gestellt werden, erfüllt die in dem Abschnitt Transformation
”
in den TEER–Kalkül“ getroﬀenen Voraussetzungen. Die im Rahmen der Transformation
nicht zugelassenen Syntaxkonstrukte sind ebenfalls in keiner der Beispielanfragen verwendet worden. Dennoch lassen sich so komplexe Anfragen stellen, daß es Schwierigkeiten
bereitet diese Anfragen umgangssprachlich auszudrücken.
Beim Entwurf des TEER–Kalküls wurde die naheliegende Erweiterung des EER–Kalküls
um einen Zeitpunkt gewählt. Diese Abhängigkeit der TEER–Kalkülausdrücke von einem
festen Zeitpunkt ermöglicht die Deﬁnition der Semantik des Kalküls. Die Semantik eines
Kalküls kann nur in Abhängigkeit von einem festen Datenbank–Zustand deﬁniert werden.
Der Datenbank–Zustand einer temporalen Datenbank wiederum ist von festen Zeitpunkten abhängig. Der allgemeine Begriﬀ des temporalen Elements erschien für diesen Zweck
zu variabel, da es sich bei einem temporalen Element um eine große Menge von Zeitpunkten handeln kann. Für eine diesbezügliche Verallgemeinerung des TEER–Kalküls war der
zeitliche Rahmen dieser Diplomarbeit zu klein. Die Deﬁnition der Semantik der TEER–
Anfragesprache und die damit verbundene Deﬁnition des TEER–Kalküls sowie der gegebenen Transformationsregeln haben sich als sehr aufwendig erwiesen. Das Hauptanliegen
dieser Arbeit war die eindeutige Deﬁnition der Semantik für eine graphische temporale
Anfragesprache, was auf Kosten von Aussagen über die Ausdrucksfähigkeit der Sprache
und einer allgemeinen SQL–Implementierung realisiert wurde. Diese Themen haben sich
als zu aufwendig im Rahmen dieser Diplomarbeit erwiesen.
Die vorgestellte TEER–Anfragesprache basiert auf dem Sprachvorschlag [KG95]. Einige
151
Kapitel 6. Kritik und Ausblick
der dort getroﬀenen, nicht übernommenen Konventionen sind jedoch inpraktikabel und
verkomplizieren die Formulierung von Anfragen. Solche Konventionen sind nicht übernommen sondern durch neue Bestimmungen ersetzt worden. In [KG95] ist festgelegt, daß
eine nicht temporale Anfrage nur zum aktuellen Zeitpunkt ausgewertet wird. Im Gegensatz dazu erfolgt in der TEER–Anfragesprache die Auswertung einer solchen Anfrage zu
jedem Schnappschuß des Datenbankinhalts. Die Interpretation in [KG95] bewirkt, daß auf
Grund einer temporalen Projektion historische, gegenwärtige oder zukünftige Datensätze
ausgegeben werden, die im aktuellen Datenbankzustand gültig sind und eventuell formulierte Bedingungen erfüllen. Die Selektion historischer, gegenwärtige oder zukünftige
Daten ist somit vom aktuellen Datenbank–Zustand abhängig. Die ausgegebenen Daten
müssen diese Bedingungen nicht erfüllen. Datensätze, die im Gegensatz dazu in dem projizierten Zeitraum gültig sind und die Selektionsbedingungen erfüllen, aber nicht zum
aktuellen Zeitpunkt Gültigkeit haben, werden nicht mit ausgegeben. Damit die Sprache
[KG95] dasselbe Ergebnis wie die TEER–Anfragesprache ausgibt, ist eine Anfrage, die
eine temporale Selektion mit einer anschließenden Projektion beinhaltet, zu formulieren.
Die temporalen Elemente der Selektion und der Projektion müssen dabei identisch sein.
Das bedeutet, daß eine Projektion in der TEER–Anfragesprache einer Selektion mit anschließender Projektion in der Sprache [KG95] entspricht.
Eine weitere entscheidende Änderung ist für den Query–result–link–Operator getroﬀen
worden. Der Sprachvorschlag [KG95] sieht vor, daß ein erweiterter Vergleichsoperator
Θall oder Θany nur dann zu verwenden ist, wenn der Benutzer weiß“, daß die Unteran”
frage eine Menge von Werten zurückgibt; ansonsten ist die Angabe von Θ ausreichend.
Diese syntaktische Regel der graphischen Anfragesprache [KG95] setzt voraus, daß der
Benutzer den Inhalt der Datenbank, an die er eine Anfrage stellen will, genau kennt.
In den seltensten Fällen wird dieses der Realität entsprechen, so daß schnell semantisch
falsche Anfragen formuliert werden.
Bei der exemplarischen Implementierung der Beispielanfragen in ORACLE hat sich gezeigt, daß es problematisch ist, eine Anfragesprache für ein nicht formal deﬁniertes DBMS
zu realisieren, wenn keine Möglichkeit vorhanden ist, die geforderten Erweiterungen zum
DBMS zu simulieren. Es fehlen ein Datendeﬁnitions– und ein Datenmanipulationstool
zur Erzeugung temporaler Datenbanken, die das TEER–Modell abbilden können. Daher
wurde eine Testdatenbank angelegt, die nicht als temporale Datenbank bezeichnet werden
darf. Die Einhaltung der temporalen Hierarchie wird von der Datenbank nicht überprüft.
Eine Erweiterung des TEER–Anfrage–Editors zu einer graphischen Benutzerschnittstelle,
die eine Verbindung zum ORACLE–DBMS herstellt, hätte diese Problematik verschärft.
Der Benutzer mußte absichern, daß das dargestellte Schema in der Datenbank realisiert
ist. Das Programm EDE, das im Rahmen der Diplomarbeit [Zec97] erstellt wurde, kann zu
der Transformation eines TEER–Modells in das Relationenmodell nicht benutzt werden,
da die für eine temporale Datenbank benötigten Schlüsselbedingungen nicht erzeugt werden können. Die in einer temporalen Datenbank zusätzlichen Spalten für den Anfangs–
und den Endzeitpunkt des Gültigkeitszeitraums sowie das zeitinvariante Surrogat könnten indes noch als zusätzliche Attribute der Entity– und Relationshiptypen angelegt werden. Wird ein solches EER–Schema in EDE als Simulation eines äquivalenten TEER–
Schemas modelliert, dürfen die entsprechenden SQL create table–Anweisungen nicht
nach ORACLE sondern nur in eine Datei ausgegeben werden. Der Benutzer kann so einen
Eindruck von den zu erzeugenden temporalen Tabellen und ihren Beziehungen unterein152
ander erhalten. Dieser Weg ist die im Moment die einzig verfügbare Unterstützung, die
der Benutzer bei der Erzeugung einer temporalen Datenbank bekommen kann.
Ausblick
In der Menge der Operatoren der TEER–Standarddatentyp–Signatur sind Filter– und
Mengenoperatoren enthalten, die in der TEER–Anfragesprache nicht enthalten sind.
Die Filteroperatoren first, last, min duration und max duration sind auf temporale Elemente anwendbar und geben ein oder mehrere Zeitintervalle zurück. Ein solcher Filteroperator kann dann z.B. in einer Anfrage, in der das Ergebnis einer Time–link–Unteranfrage
auf eine übergeordnete Anfrage projiziert wird, Verwendung ﬁnden. Eine Anfrage des
genannten Typs, ist die Beispielanfrage 4.12.
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem Müller
”
Leiter der Abteilung ’Montage’ ist ?“
Wird in diese Anfrage ein Filteroperator eingebunden, müssen nicht mehr alle Zeiträume,
in den Müller Leiter der Abteilung Montage war, projiziert werden, sondern es kann aus
dieser Menge von Zeitintervallen ein bestimmtes, z.B. das früheste längste, ausgewählt
werden. Die gestellte Anfrage lautet dann umgangssprachlich:
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem Müller
”
zum ersten Mal Leiter der Abteilung ’Montage’ war ?“
Die auf temporalen Elementen zugelassenen Mengenoperatoren sind die m–stellige Vereinigung, der m–stellige Durchschnitt und die Diﬀerenz zweier temporaler Elemente. Mit
Hilfe dieser Operatoren sind sehr komplexe Anfragen formulierbar, da es möglich wäre,
aus mehreren temporalen Elementen ein einziges zu erzeugen. Damit könnten innerhalb
temporaler Selektionen oder Projektionen mehrere temporale Elemente gleichzeitig verwendet werden. So könnte z.B. das Ergebnis eines True–time–Operators mit dem Ergebnis
eines Time–link–Operators vereinigt werden und dieses Ergebnis auf eine übergeordnete
Anfrage projiziert werden. Eine solche Anfrage könnte lauten:
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem Müller
”
Leiter der Abteilung ’Montage’ ist oder die Auslastung mindestens einer Abteilung über
80% liegt ?“
Wird in eine solche Anfrage zusätzlich noch ein Filteroperator eingebunden, kann gefragt
werden:
Welche Angestellten arbeiten in welcher Position innerhalb des Zeitraums, in dem Müller
”
am längsten Leiter der Abteilung ’Montage’ ist oder die Auslastung mindestens einer
Abteilung am längsten über 80% liegt ?“
Als weitere Erweiterungsmöglichkeit bieten sich die in jedem konventionellen DBMS
verfügbaren Aggregationsfunktionen an. Mit Hilfe dieser hier vorgestellten Erweiterungsmöglichkeiten vergrößert sich die Menge der formulierbaren Anfragen enorm. Für
alle diese Erweiterungen müßten neue graphische Objekte deﬁniert werden sowie die Syntax und Semantik festgelegt werden.
Eine andere Möglichkeit die TEER–Anfragesprache zu erweitern, besteht darin, auch
Anfragen an den Existenzzeitraum von Daten zuzulassen. Dafür wird eine Datenbank
153
Kapitel 6. Kritik und Ausblick
benötigt, die zusätzlich zur Valid–Time auch die Transaction–Time unterstützt. Die Anfragekonstrukte sind dann auf beide Zeitarten anwendbar, der Benutzer muß entscheiden,
ob sich seine Anfrage auf die Valid– oder die Transaction–Time bezieht.
Als eine zusätzliche Spracherweiterung bieten sich in diesem Zusammenhang die temporalen Operatoren timeslice“ und moving window“ an. Der Timeslice–Operator liefert,
”
”
auf die Valid–Time angewendet, alle zu einem festen Zeitpunkt gültigen Datensätze, d.h.
ein Schnappschuß des Datenbankinhalts zu diesem Zeitpunkt wird ausgegeben. Dieser zu
speziﬁzierende Zeitpunkt kann beliebig gewählt sein. Wird der Timeslice–Operator dagegen auf die Transaction–Time angewendet, muß dieser Zeitpunkt in der Vergangenheit
liegen oder das aktuelle Datum sein. Als Ergebnis gibt der Timeslice–Operator dann alle
zu dem angegebenen Zeitpunkt in der Datenbank existierenden Datensätze zurück. Der
Timeslice–Operator ist natürlich auch für eine Anfragesprache an eine Datenbank, die nur
die Valid–Time unterstützt, eine sinnvolle Erweiterung.
Der Moving–window–Operator beschreibt ein Zeitintervall konstanter Länge. Eine Anfrage, die ein Moving–window beinhaltet, wird dann in allen existierenden Intervallen in der
Zeit T ausgewertet, die die Länge des speziﬁzierten Intervalls haben. Das bedeutet, das
mit dem Moving–window–Operator ein frei bewegliches Intervall fester Länge angegeben
wird, für das die Anfrageauswertung erfolgt.
154
Anhang A
Implementierung der Testdatenbank
Anmerkungen zu dem verwendeten date–Format sowie der Erzeugung von Datumsangaben in ORACLE sind in Abschnitt 5.1 zu ﬁnden.
A.1
Die Tabelle Firma
drop table Firma cascade constraints;
create table Firma (
Firma$ number not null,
t_inv$ number not null,
Firmenname varchar2(15) not null,
vt_from date not null,
vt_to date not null,
primary key (Firma$));
insert into Firma
values (1000, 991000, ’Prima’, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Firma
values (1001, 991001, ’Trumpf’, to_date(’01/07/1985’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into Firma
values (1004, 991004, ’Zonk’, to_date(’01/09/1987’,’DD/MM/YYYY’),
to_date(’31/08/1997’,’DD/MM/YYYY’));
insert into Firma
values (1005, 991005, ’Flop’, to_date(’01/01/1997’,’DD/MM/YYYY’),
to_date(’31/07/1997’,’DD/MM/YYYY’));
insert into Firma
values (1006, 991006, ’Top’, to_date(’01/01/1998’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
155
Kapitel A. Implementierung der Testdatenbank
A.2
Die Tabelle Angestellter
drop table Angestellter cascade constraints;
create table Angestellter (
Angestellter$ number unique,
t_inv$ number not null,
AngName char(15) not null,
PersNr integer not null,
Gehalt number not null,
Position char(20) not null,
vt_from date not null,
vt_to date not null,
primary key (Angestellter$));
insert into Angestellter
values (7018, 997010, ’Mueller’, 234, 5800, ’AbtLeiter’,
to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into Angestellter
values (7019, 997010, ’Mueller’, 234, 6400, ’AbtLeiter’,
to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
insert into Angestellter
values (7099, 997040, ’Maier’, 987, 7500, ’AbtLeiter’,
to_date(’01/04/1990’,’DD/MM/YYYY’),
to_date(’30/09/1995’,’DD/MM/YYYY’));
insert into Angestellter
values (7111, 997045, ’Schulz’, 654, 6400, ’AbtLeiter’,
to_date(’01/04/1989’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Angestellter
values (7001, 997000, ’Hinz’, 312, 5300, ’AbtLeiter’,
to_date(’01/03/1987’,’DD/MM/YYYY’),
to_date(’31/12/1989’,’DD/MM/YYYY’));
insert into Angestellter
values (7002, 997000, ’Hinz’, 312, 6300, ’AbtLeiter’,
to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Angestellter
values (7987, 997050, ’Kunz’, 717, 8000, ’AbtLeiter’,
to_date(’01/07/1990’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
insert into Angestellter
values (7988, 997050, ’Kunz’, 717, 8500, ’AbtLeiter’,
to_date(’01/01/1996’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
156
A.3. Die Tabelle Abteilung
insert into Angestellter
values (7020, 997015, ’Schmidt’, 813, 4000, ’Monteur’,
to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1987’,’DD/MM/YYYY’));
insert into Angestellter
values (7025, 997020, ’Schiller’, 921, 4000, ’Monteur’,
to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
insert into Angestellter
values (7030, 997025, ’Vogel’, 789, 3800, ’Maler’,
to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Angestellter
values (7035, 997030, ’Klein’, 909, 4500, ’Techniker’,
to_date(’01/01/1987’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into Angestellter
values (7040, 997035, ’Gross’, 877, 5000, ’stellv. AbtLeiter’,
to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
A.3
Die Tabelle Abteilung
drop table Abteilung cascade constraints;
create table Abteilung (
Abteilung$ number unique,
t_inv$ number not null,
AbtName varchar2(15) not null,
AbtLeiter number not null references Angestellter(Angestellter$),
vt_from date not null,
vt_to date not null,
primary key (Abteilung$));
insert into Abteilung
values (5000, 995000, ’Montage’, 7018, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into Abteilung
values (5012, 995000, ’Montage’, 7099, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’30/04/1991’,’DD/MM/YYYY’));
insert into Abteilung
values (5222, 995000, ’Montage’, 7111, to_date(’01/05/1991’,’DD/MM/YYYY’),
to_date(’31/05/1991’,’DD/MM/YYYY’));
insert into Abteilung
values (5034, 995000, ’Montage’, 7002, to_date(’01/06/1991’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
157
Kapitel A. Implementierung der Testdatenbank
insert into Abteilung
values (5011, 995010, ’Lackiererei’, 7987, to_date(’01/01/1996’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Abteilung
values (5333, 995010, ’Lackiererei’, 7018, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
A.4
Die Tabelle Produkt
drop table Produkt cascade constraints;
create table Produkt (
Produkt$ number unique,
t_inv$ number not null,
ChargenNr number not null,
ProdName varchar2(25) not null,
StPreis number not null,
vt_from date not null,
vt_to date not null,
primary key (Produkt$));
insert into Produkt
values (4000, 994000, 55778, ’Rennrad’, 1200,
to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1986’,’DD/MM/YYYY’));
insert into Produkt
values (4005, 994005, 56889, ’Rennrad’, 1150,
to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’30/06/1990’,’DD/MM/YYYY’));
insert into Produkt
values (4010, 994010, 57911, ’Rennrad’, 1000,
to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1992’,’DD/MM/YYYY’));
insert into Produkt
values (4015, 994015, 98102, ’Rennrad’, 1050,
to_date(’01/09/1989’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Produkt
values (4020, 994020, 75432, ’Rennrad’, 1400,
to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1986’,’DD/MM/YYYY’));
insert into Produkt
values (4025, 994020, 75432, ’Rennrad’, 1700,
to_date(’01/01/1987’,’DD/MM/YYYY’),
to_date(’31/12/1987’,’DD/MM/YYYY’));
insert into Produkt
158
A.5. Die Tabelle Mitarbeiter
values (4030, 994030, 77641, ’Rennrad’, 1800,
to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’31/12/1992’,’DD/MM/YYYY’));
insert into Produkt
values (4035, 994035, 12341, ’Rennrad’, 1600,
to_date(’01/01/1992’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
insert into Produkt
values (4040, 994035, 12341, ’Rennrad’, 1400,
to_date(’01/01/1996’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Produkt
values (4001, 994000, 55778, ’Rennrad’, 1100,
to_date(’01/01/1987’,’DD/MM/YYYY’),
to_date(’31/08/1987’,’DD/MM/YYYY’));
A.5
Die Tabelle Mitarbeiter
drop table Mitarbeiter cascade constraints;
create table Mitarbeiter (
Abteilung$ number not null references Abteilung(Abteilung$),
Mitarbeiter number not null references Angestellter(Angestellter$),
vt_from date not null,
vt_to date not null);
insert into Mitarbeiter
values (5000, 7020, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1987’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5000, 7025, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5000, 7030, to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5000, 7035, to_date(’01/01/1987’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5000, 7040, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1987’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5012, 7025, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’30/04/1991’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5222, 7025, to_date(’01/05/1991’,’DD/MM/YYYY’),
159
Kapitel A. Implementierung der Testdatenbank
to_date(’31/05/1991’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5034, 7025, to_date(’01/06/1991’,’DD/MM/YYYY’),
to_date(’31/12/1994’,’DD/MM/YYYY’));
insert into Mitarbeiter
values (5011, 7025, to_date(’01/01/1995’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
A.6
Die Tabelle Zulieferfirma
drop table Zulieferfirma cascade constraints;
create table Zulieferfirma (
Zulieferfirma$ number unique,
t_inv$ number not null,
Firma$ number not null references Firma(Firma$),
vt_from date not null,
vt_to date not null,
primary key (Zulieferfirma$));
insert into Zulieferfirma
values (2000, 992000, 1000, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/08/1987’,’DD/MM/YYYY’));
insert into Zulieferfirma
values (2001, 992010, 1000, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1992’,’DD/MM/YYYY’));
insert into Zulieferfirma
values (2010, 992020, 1004, to_date(’01/09/1987’,’DD/MM/YYYY’),
to_date(’31/08/1997’,’DD/MM/YYYY’));
insert into Zulieferfirma
values (2011, 992030, 1001, to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’30/06/1990’,’DD/MM/YYYY’));
A.7
Die Tabelle Vorprodukt
drop table Vorprodukt cascade constraints;
create table Vorprodukt (
Vorprodukt$ number unique,
t_inv$ number not null,
Produkt$ number not null references Produkt(Produkt$),
vt_from date not null,
vt_to date not null,
primary key (Vorprodukt$));
160
A.8. Die Tabelle gehoert zu
insert into Vorprodukt
values (3000, 993000, 4010, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1992’,’DD/MM/YYYY’));
insert into Vorprodukt
values (3001, 993010, 4015, to_date(’01/09/1989’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
insert into Vorprodukt
values (3002, 993020, 4005, to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’30/06/1990’,’DD/MM/YYYY’));
insert into Vorprodukt
values (3003, 993030, 4000, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1986’,’DD/MM/YYYY’));
insert into Vorprodukt
values (3004, 993030, 4001, to_date(’01/01/1987’,’DD/MM/YYYY’),
to_date(’31/08/1987’,’DD/MM/YYYY’));
A.8
Die Tabelle gehoert zu
drop table gehoert_zu cascade constraints;
create table gehoert_zu (
Firma$ number not null references Firma(Firma$),
Abteilung$ number not null references Abteilung(Abteilung$),
vt_from date not null,
vt_to date not null,
primary key (Firma$, Abteilung$, vt_from, vt_to));
insert into gehoert_zu
values (1000, 5000, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into gehoert_zu
values (1000, 5012, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’30/04/1991’,’DD/MM/YYYY’));
insert into gehoert_zu
values (1000, 5222, to_date(’01/05/1991’,’DD/MM/YYYY’),
to_date(’31/05/1991’,’DD/MM/YYYY’));
insert into gehoert_zu
values (1000, 5034, to_date(’01/06/1991’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
insert into gehoert_zu
values (1005, 5011, to_date(’01/01/1997’,’DD/MM/YYYY’),
to_date(’31/07/1997’,’DD/MM/YYYY’));
insert into gehoert_zu
values (1000, 5333, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1996’,’DD/MM/YYYY’));
161
Kapitel A. Implementierung der Testdatenbank
insert into gehoert_zu
values (1000, 5011, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
A.9
Die Tabelle produziert
drop table produziert cascade constraints;
create table produziert (
Produkt$ number not null references Produkt(Produkt$),
Abteilung$ number not null references Abteilung(Abteilung$),
Auslastung number not null,
vt_from date not null,
vt_to date not null,
primary key (Produkt$, Abteilung$, vt_from, vt_to));
insert into produziert
values (4000, 5000, 75, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1986’,’DD/MM/YYYY’));
insert into produziert
values (4005, 5000, 82, to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’30/06/1990’,’DD/MM/YYYY’));
insert into produziert
values (4010, 5000, 89, to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into produziert
values (4010, 5012, 73, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’30/04/1991’,’DD/MM/YYYY’));
insert into produziert
values (4010, 5222, 69, to_date(’01/05/1991’,’DD/MM/YYYY’),
to_date(’31/05/1991’,’DD/MM/YYYY’));
insert into produziert
values (4010, 5034, 70, to_date(’01/06/1991’,’DD/MM/YYYY’),
to_date(’31/12/1992’,’DD/MM/YYYY’));
insert into produziert
values (4015, 5000, 72, to_date(’01/09/1989’,’DD/MM/YYYY’),
to_date(’31/12/1990’,’DD/MM/YYYY’));
insert into produziert
values (4015, 5012, 73, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’30/04/1991’,’DD/MM/YYYY’));
insert into produziert
values (4015, 5222, 40, to_date(’01/05/1991’,’DD/MM/YYYY’),
to_date(’31/05/1991’,’DD/MM/YYYY’));
insert into produziert
values (4015, 5034, 75, to_date(’01/06/1991’,’DD/MM/YYYY’),
to_date(’31/12/1995’,’DD/MM/YYYY’));
162
A.10. Die Tabelle liefert
insert into produziert
values (4015, 5011, 91, to_date(’01/01/1996’,’DD/MM/YYYY’),
to_date(’31/12/9999’,’DD/MM/YYYY’));
A.10
Die Tabelle liefert
drop table liefert cascade constraints;
create table liefert (
Zulieferfirma$ number not null references Zulieferfirma(Zulieferfirma$),
Vorprodukt$ number not null references Vorprodukt(Vorprodukt$),
vt_from date not null,
vt_to date not null,
primary key (Zulieferfirma$, Vorprodukt$, vt_from, vt_to));
insert into liefert
values (2000,3003, to_date(’01/01/1985’,’DD/MM/YYYY’),
to_date(’31/12/1986’,’DD/MM/YYYY’));
insert into liefert
values (2001,3000, to_date(’01/01/1991’,’DD/MM/YYYY’),
to_date(’31/12/1992’,’DD/MM/YYYY’));
insert into liefert
values (2010,3001, to_date(’01/09/1989’,’DD/MM/YYYY’),
to_date(’31/08/1997’,’DD/MM/YYYY’));
insert into liefert
values (2011,3002, to_date(’01/01/1990’,’DD/MM/YYYY’),
to_date(’30/06/1990’,’DD/MM/YYYY’));
insert into liefert
values (2000,3004, to_date(’01/01/1987’,’DD/MM/YYYY’),
to_date(’31/08/1987’,’DD/MM/YYYY’));
163
Kapitel A. Implementierung der Testdatenbank
164
Anhang B
Syntax der
TEER–Datenbank–Anfragesprache
Die Syntax der TEER–Datenbank–Anfragesprache ist in der erweiterten Backus–Naur–
Form deﬁniert. Eine Anfrage ist eine query, die übrigen Konstrukte sind in alphabetischer
Reihenfolge angegeben.
query ::= get attr | get time
abbrev ::= string
all any choice ::= "all " | "any "
alphanum ::= [ char digit expr ]+
attr expr ::= [ "not" ] attr cond
attr cond ::= attr name pred value
attr list ::= attr name [ "," attr name ]∗
attr name ::= string | abbrev"."string
bool expr ::= "(" attr expr [ bool op attr expr ]∗ ")"
bool op ::= "and" | "or"
cal temp elem ::= temp elem | get time
char ::= "a" | ...| "z" | "A" | ...| "Z" | " "
char digit expr ::= char | digit
comp name ::= string
date ::=
[ digit ] digit "/" [ digit ] digit "/"
[ digit digit ] digit digit
digit ::= "0" | "1" | ...| "9"
ent name ::= string
ent rel name ::= ent name | rel name
165
Kapitel B. Syntax der TEER–Datenbank–Anfragesprache
get attr ::=
get
get
get
get
get op [ restrict expr ]
[ temp sel expr ] [temp proj expr ]
op ::= "get" attr list "from" teer
result ::= get result op [ "restrict" restrict attr ]
result op ::= "get" attr name "from" teer
time ::= "get time" "from" teer
[ "restrict" restrict attr ] [ temp sel expr ]
interval ::= "[" time expr "," time expr "]"
interval union ::= "{" interval [ "," interval ]+ "}"
number ::= [ digit ]+
pred ::= "=" | ">" | "≥" | "<" | "≤" | "="
rel name ::= string
restrict attr ::= "(" bool expr ")" [ "and" "(" bool expr ")" ]∗
restrict expr ::= "restrict" "(" restrict attr ")" |
"restrict" result link
result link ::= attr name pred all any choice
"(" get result ")"
string ::= alphanum
ent name [ abbrev ] [ "," ent name [ abbrev ] ]∗
[ "," rel name [ abbrev ] ]∗
[ "," typ name ]∗
[ "," comp name ]∗
temp elem ::= interval | interval union
temp elem proj ::= temp elem | true time | "(" get time ")"
temp pred ::= "before" | "after" | "during" | "superior"
"equivalent" | "adjacent" | "overlap"
temp proj ::= [ "(" teer ")" ] temp pred temp elem proj
temp proj expr ::= "project" temp proj
temp sel ::= true time temp pred cal temp elem
temp sel expr ::= "time condition of" ent rel name "is" temp sel
time expr ::= "null" | "now" | "infinity" | date
true time ::= "[[" bool expr "]]"
typ name ::= string
teer ::=
value ::= "’" string "’" | number
166
Anhang C
Transformation in den TEER–Kalkül
Die Transformation einer graphischen TEER–Anfrage query, die in linearer Schreibweise vorliegt, ist gegeben durch die Abbildung Tt (query). Die Abbildungen der restlichen
Konstrukte sind in alphabetischer Reihenfolge angegeben.
Tt (get attr), falls query ::= get attr
Tt (query) :=
Tt (get time), falls query ::= get time
T (abbrev) := T (string)
T ("all") := "max"
T (all any choice) :=
T ("all"), falls all any choice ::= "all"
Tt ("any"), falls all any choice ::= "any"
T (alphanum) := [ T (char digit expr) ]+
T ("and") := " ∧ "
T ("any") := "min"
Tt (attr expr) := [ T ("not") ] Tt (attr cond)
Tt (attr cond) := Tt (attr name) T (pred) T (value)
Tt (attr list) := Tt (attr name) [ "," Tt (attr name) ]∗
Tt (attr name) := T (abbrev)"."T (string)".t"
167
Kapitel C. Transformation in den TEER–Kalkül
Es muß gelten:
abbrev gehört zu demjenigen Entity ent name für das gilt: type(attr name) = ent name
und ent name ist in teer enthalten.
Tt (bool expr) := Tt (attr expr) [ T (bool op) Tt (attr expr) ]∗
T (bool op) :=
T ("and "), falls bool op ::= "and"
T ("or "), falls bool op ::= "or"
Tt (cal temp elem) :=

"a",



..


.



"z",
T (char) :=
"A",




..


.


"Z",
Tt (temp elem), falls cal temp elem ::= temp elem
Tt (get time), falls cal temp elem ::= get time
falls char ::= "a"
falls char ::= "z"
falls char ::= "A"
falls char ::= "Z"
T (char), falls char digit expr ::= char
T (char digit expr) :=
T (digit), falls char digit expr ::= digit
T (comp name) := T (string)
T (date) :=
[ T (digit) ] T (digit) "/" [ T (digit) ] T (digit)"/"
[ T (digit) T (digit) ] T (digit) T (digit)


"0", falls digit ::= "0"


 "1", falls digit ::= "1"
T (digit) :=
.
 ..


 "9", falls digit ::= "0"
T (ent name) := T (string)
T (ent rel name) :=
Tt (get attr) :=
T (ent name), falls ent rel name ::= ent name
T (rel name), falls ent rel name ::= rel name
"{" Tt (get op) Tt (restrict expr)
[ Tt (temp sel expr) ] Tt (temp proj expr) [ ) ]! "}"
Im Gegensatz zur Syntax einer Anfrage sind die Transformationen der Konstrukte
restrict expr und temp proj expr nicht optional. Mit der Transformation des Kon168
strukts restrict expr werden eventuelle Verbindungen zwischen Entity– und Relationshiptypen, an die eine Anfrage gestellt wird, in Kalkülschreibweise ausgedrückt. Die Transformation des Konstrukts temp proj expr erzeugt die Einschränkung der Daten auf einen
Gültigkeitszeitraum. Ist keine Projektion in der Anfrage angegeben, wird die Lebensdauer
der Datenbank als Gültigkeitszeitraum genommen.
Die optionale runde schließende Klammer wird dann benötigt, wenn in einer Kalkülanfrage an dieser Stelle noch oﬀene Klammern kein schließendes Gegenstück besitzen. Die
nicht zur erweiterten Backus–Naur–Form gehörige Hilfsnotation [ ) ]! soll bedeuten, daß
nicht beliebig viele schließende Klammern gesetzt werden dürfen, sondern ihre Anzahl
muß genau der Anzahl noch oﬀener Klammern entsprechen. Im Rahmen der Formulierung
von booleschen Bedingungen oder Gültigkeitszeiträumen werden Klammern geöﬀnet,
können aber dort nicht wieder geschlossen werden, da sonst der Gültigkeitsbereich von
Deklarationen vorzeitig beendet werden könnte.
Tt (get op) := Tt (attr list) ", t |" T (teer)
Tt (get result) := "{" Tt (get result op) Tt (restrict attr) Tt (temp proj expr) [ ) ]! "}"
Es gelten dieselben Erklärungen wie für das Konstrukt get attr. Die Transformation
des in einer Unteranfrage nicht zugelassenen Konstrukts temp proj expr erzeugt die in
dem Kalkül nötige Einschränkung der Variablen t auf die Lebensdauer der Datenbank.
Da das get result–Konstrukt eine Unteranfrage darstellt, dürfen nur diejenigen runden
Klammern geschlossen werden, die während der Transformation dieser Unteranfrage
geöﬀnet wurden und bisher kein schließendes Gegenstück besitzen. Das bedeutet insbesondere, daß oﬀene runde Klammern, die bei der Transformation der übergeordneten
Anfrage geöﬀnet wurden, nicht geschlossen werden dürfen.
Tt (get result op) := Tt (attr name) "|" T (teer)
Tt (get time) := "{ t |" Tt (restrict att) [ Tt (temp sel expr) ] Tt (temp proj expr) [ ) ]! "}"
Es gelten dieselben Erklärungen wie für das Konstrukt get attr. Die Transformation
des in einer Unteranfrage nicht zugelassenen Konstrukts temp proj expr erzeugt die in
dem Kalkül nötige Einschränkung der Variablen t auf die Lebensdauer der Datenbank.
Auch in diesem Fall drückt die Hilfsnotation [ ) ]! aus, daß nur soviele runde schließende
Klammern gesetzt werden dürfen, wie noch oﬀene vorhanden sind. Wird das get time–
Konstrukt als Unteranfrage im Rahmen einer temporalen Selektion oder Projektion
verwendet, ist die Betrachtung der Klammern nur auf die innerhalb der Transformation
dieser Unteranfrage gesetzten Klammern beschränkt.
Tt (interval) := "[" Tt (time expr) ", " Tt (time expr) "]"
169
Kapitel C. Transformation in den TEER–Kalkül
Tt (interval union) := Tt (interval) [ " ∪ " Tt (interval) ]+
T ("not") := "¬"
T (number) := [ T (digit) ]+
T ("or") := " ∨ "

" = ",




" > ",



" ≥ ",
T (pred) :=
" < ",




" ≤ ",



" = ",
falls
falls
falls
falls
falls
falls
pred
pred
pred
pred
pred
pred
::=
::=
::=
::=
::=
::=
"="
">"
"≥"
"<"
"≤"
" = "
T (rel name) := T (string)
Tt (restrict attr) := [ " ∧ " ] [ "∃ (" T (abbrev) " : " T (ent rel name) ")" ]
[ " ∧ ∃ (" T (abbrev) " : " T (ent rel name) ")" ]∗
"(" Tt (bool expr) [ " ∧ " Tt (bool expr) ]∗
[ " ∧ " relationt ]∗
Die ersten drei optionalen Klammern ermöglichen die Deklaration aller bisher nicht deklarierten Entitytypen, die in teer aufgeführt sind. Als Variablen werden dabei die zugehörigen alias–Bezeichner abbrev aus teer benutzt. Relationshiptypen werden nur dann
deklariert, wenn eine boolesche Bedingung bool expr an ein zugehöriges Attribut gestellt
ist. Das erste optionale ∧ wird nicht benötigt, falls Tt (restrict attr) im Rahmen einer
Transformation des Konstrukts get result oder get time aufgerufen wird.
Als nächstes werden alle booleschen Bedingungen nacheinander transformiert. Die letzte
optionale Klammer beinhaltet einen Aufruf der Funktion relationt . Diese Funktion
stellt Verbindungen zwischen Entitytypen her. relationt ist sooft aufzurufen, bis alle
Relationshiptyp–, Typkonstruktions– und Komponentennamen, die in teer vorkommen,
benutzt sind. Beinhaltet eine Anfrage nur einen Entitytyp, ist der Funktionsaufruf zu
übergehen.
Für das Funktion relationt gilt:

T (rel name)".t" (abbrev,abbrev),
falls Fall 1



falls Fall 2
T (abbrev) " = as "T (ent name)".t ("T (abbrev)")",
relationt :=
"(" T (abbrev) " ∈ " T (abbrev)"."T (comp name)".t"


, falls Fall 3

[ " ∨ " T (abbrev) " ∈ " T (abbrev)"."T (comp name)".t" ] ")"
170
Fall 1:
1. rel name ist in teer enthalten.
2. participants(rel name) = {ent name,ent name}. Die alias–Bezeichner abbrev
dieser beiden Entitytypen werden verwendet.
Fall 2:
1. Es gibt eine Typkonstruktion typ name in teer, wobei
output(typ name), input(typ name) in teer enthalten sind.
2. Die erste Abkürzung abbrev eines Entitynamens gehört zu
ent name = output(typ name).
3. Die zweite Abkürzung abbrev eines Entitynamens gehört zu
ent name = input(typ name).
4. In relationt ist der verwendete ent name = output(typ name).
Fall 3:
1. comp name ist in teer enthalten.
2. Der Ausdruck in der optionalen Klammer, wird für den Fall gebraucht, daß
es mehrere Komponenten zwischen den beiden Entitytypen type(comp name) und
domain(comp name) gibt.
3. Die erste Abkürzung abbrev gehört zu ent name = domain(typ name).
4. Die zweite Abkürzung abbrev gehört zu ent name = type(typ name).
5. Eine Unterscheidung zwischen ein– und mehrwertigen Komponenten ﬁndet nicht
statt.

Tt (restrict attr),
falls Fall 1




falls Fall 2
Tt (result link),



falls Fall 3
Tt (restrict attr) " ∧ " Tt (result link),
Tt (restrict expr) :=
[ " ∧ ∃ (" T (abbrev) " : " T (ent name) ")" ]∗


falls Fall 4


"(" relationt [ " ∧ " relationt ]∗ ,



" ",
sonst
Fall 1:
restrict expr ::= "restrict" "(" restrict attr ")"
171
Kapitel C. Transformation in den TEER–Kalkül
Fall 2:
restrict expr ::= "restrict" result link
Fall 3:
restrict expr ::= "restrict" "(" result attr "and" result link ")"
Fall 4:
Fall 1 und Fall 2 sind nicht erfüllt und es gibt mehr als einen Namen ent name in teer.
Erklärung der Formel:
Mit Hilfe der ersten Klammer werden alle bisher nicht deklarierten Entitytypen, die in
teer aufgelistet sind, deklariert. Die folgenden Aufrufe der Funktion relationt bewirken,
daß die Verbindungen zwischen den einzelnen Typen ausgedrückt werden.
Tt (result link) :=
[ " ∧ ∃ (" T (abbrev) " : " T (ent name) ")" ]∗
"(" relationt [ " ∧ " relationt ]∗
"(" Tt (attr name) T (pred) T (all any choice)
Tt (get result)
Mit Hilfe der ersten Klammer werden alle bisher nicht deklarierten Entitytypen, die in
teer aufgelistet sind, deklariert. Die folgenden Aufrufe der Funktion relationt bewirken,
daß die Verbindungen zwischen den einzelnen Typen ausgedrückt werden. Der Rest der
Transformationsregel ist streng Syntax–orientiert.
T (string) := T (alphanum)
T (teer) :=
"(" T (abbrev) " : " T (ent name)
[ " ∧ " T (abbrev) " : " T (ent rel name) ]∗ ")"
wobei abbrev die zu dem Entitytypnamen ent name oder Entity– bzw. Relationshiptypnamen ent rel name gehörige alias–Bezeichner ist. Es werden nur diejenigen Namen
ent name bzw. ent rel name aufgezählt, deren Abkürzung abbrev in Tt (attr list)
vorkommt. Jeder Entity– oder Relationshiptyp wird dabei jedoch nur einmal deklariert,
auch wenn seine Abkürzung in Tt (attr list) mehrfach vorkommt.
Tt (temp elem) :=
Tt (interval),
falls temp elem ::= interval
Tt (interval union), falls temp elem ::= interval union

falls temp elem proj ::= temp elem
 Tt (temp elem),
"[t0 , t∞ ]" Tt (true time) " ∧ ”, falls temp elem proj ::= true time
Tt (temp elem proj) :=

falls temp elem proj ::= get time
Tt (get time),
172

 ∀ t ∈ Tt (temp elem proj) t < t , falls temp pred ::= before
∀ t ∈ Tt (temp elem proj) t > t , falls temp pred ::= after
Tt (temp proj) :=

∃ t ∈ Tt (temp elem proj) t = t , falls temp pred ::= during
Eine temporale Projektion wird in Abhängigkeit des verwendeten temporalen Prädikats
temp pred transformiert.
Tt (temp proj expr) :=
" ∧ " Tt (temp proj), falls temp proj expr gegeben ist
sonst
" ∧ t ∈ [t0 , t∞ ]",

"(( ∀ t ∈ [t0 , t∞ ] ∀ t ∈ " Tt (cal temp elem) "t < t )"




" ⇒ (" Tt (true time) "))"
falls temp pred ::= before



"(( ∀ t ∈ [t0 , t∞ ] ∀ t ∈ "Tt (cal temp elem) "t > t )"
Tt (temp sel) :=
falls temp pred ::= after
" ⇒ (" Tt (true time) "))"




"((
∀
t
∈
[t
,
t
]
∃
t
∈
"T
(cal
temp
elem) "t = t )"

0 ∞
t


falls temp pred ::= during
" ⇒ (" Tt (true time) "))"
Eine temporale Selektion wird in Abhängigkeit des verwendeten temporalen Prädikats
temp pred transformiert.
Tt (temp sel expr) := " ∧ " Tt (temp sel)
wobei der in temp sel expr vorkommende Name ent rel name in Tt (true time)
innerhalb von Tt (temp sel) verwendet wird.

"t0 ",



"tnow ",
Tt (time expr) :=
"t∞ ",



T (date),
falls
falls
falls
falls
time
time
time
time
expr
expr
expr
expr
::=
::=
::=
::=
null
now
infinity
date
Tt (true time) := [ "∃ (" T (abbrev) " : " T (ent rel name) ")" ] "(" Tt (bool expr) ")"
wobei der optionale Ausdruck benutzt wird, falls sich die Bedingung auf das Attribut
eines Entity– Relationshiptyps bezieht und ent rel name im bisherigen Ausdruck noch
nicht deklariert worden ist.
T (value) :=
" " T (string)" ", falls value ::= "’" string "’"
T (number),
falls value ::= number
173
Kapitel C. Transformation in den TEER–Kalkül
174
Anhang D
Benutzerhandbuch
In diesem Kapitel wird das Programm TEER–Anfrage–Editor vorgestellt, das die Formulierung von TEER–Anfragen graphisch realisiert. Dazu wird im ersten Abschnitt die Modularisierung des zu Grunde liegenden Programms aufgezeigt sowie auf die Dateistruktur,
Systemvoraussetzungen und die Installation eingegangen.
Im zweiten Abschnitt wird die Erstellung der Grundlage des TEER–Anfrage–Editors, die
Erzeugung eines TEER–Schemas, vorgestellt. Dieses schließt insbesondere das Programm
EDE ( EER–Diagramm–Editor“) ein, das im Rahmen der Diplomarbeit [Zec97] erstellt
”
wurde.
Der TEER–Anfrage–Editor wird schließlich im letzten Abschnitt vorgestellt und die Erstellung graphischer Anfragen an Hand der Beispiele aus Kapitel 4.1.3 vorgeführt.
D.1
Modularisierung und Installation
Modularisierung
Der Kern des Programms TEER–Anfrage–Editor besteht aus C++–Dateien, die dem Programm EDE entstammen. Da der Anfrage–Editor nur zur Darstellung von Anfragen
dient, sind keine neuen Quelldateien hinzugekommen. Aus dem Programm EDE wurde die Methode des Abspeicherns von Elementen übernommen. Die in das Programm
TEER–Anfrage–Editor aufgenommenen C++–Dateien enthalten die dazu angelegten Speicherstrukturen sowie Implementierungen neuer Tcl–Befehle. Diese Tcl–Befehle werden zur
Erzeugung und Darstellung der graphischen Objekte gebraucht. Die Modulstruktur der
übernommenen C++–Dateien ist in Abbildung D.1 dargestellt.
Das Programm EDE unterstützt das Konzept der Entity–Cluster und benutzerdeﬁnierter
Integritätsbedingungen. Dieses beides wird nicht vom Anfrage–Editor angeboten. Daher
ist sämtlicher diesbezüglicher Code aus den vom Programm EDE stammenden C++–
Dateien gekürzt worden.
Die graphische Benutzeroberﬂäche wurde in Tcl/Tk programmiert und setzt auf dem
C++–Kern auf. Da die Programme EDE und TEER–Anfrage–Editor zum Teil die gleichen
Befehle anbieten, basiert ein Teil der Tcl–Prozeduren des Programms TEER–Anfrage–
Editor auf Tcl–Prozeduren des Programms EDE. Da das Programm TEER–Anfrage–Editor
175
Kapitel D. Benutzerhandbuch
tkAppInt
tkDiv
tkObjects
tkConnections
objects
lists
types
Abbildung D.1: Modulstruktur des Programmkerns
176
str
D.1. Modularisierung und Installation
aber in der Lage ist, zwei verschiedene Zeichenbereiche anzusteuern, sind sämtliche übernommenen Funktionen modiﬁziert worden.
Der Programmcode, der die graphische Oberﬂäche erzeugt und steuert, ist auf vier
Tcl/Tk–Dateien verteilt. Das Aussehen und die Erzeugung der Oberﬂäche sind in der
Datei teer.tcl implementiert. Diese Datei bildet das Hauptprogramm des Tcl/Tk–Teils.
In dieser Datei beﬁnden sich die include–Kommandos für die übrigen Quelldateien. In
der Datei fileselect.tcl ist das Einlesen eines Dateinamens implementiert, die Datei
schemaio.tcl enthält alle Prozeduren, die zum Abspeichern und Auslesen eines Schemas
aus einer Datei nötig sind. Die letzte Datei, die Datei control.tcl, beinhaltet sämtliche
Befehle, die zur Ansteuerung und Darstellung von auf der graphischen Oberﬂäche dargestellten Objekten und Programmknöpfen benötigt werden. Die Abbildung D.2 zeigt an,
welche Tcl/Tk–Dateien auf welche C++–Module zugreifen.
teer.tcl
tkConnections
control.tcl
tkDiv
tkObjects
fileselect.tcl
schemaio.tcl
Abbildung D.2: Zusammenhang zwischen Tcl/Tk– und C++–Teil
Installation des Programms
Der Quelltext des Programms TEER–Anfrage–Editor ist auf zwei Verzeichnisse verteilt:
c++/ Dieses Verzeichnis enthält die von dem Programm EDE benötigten Programmquellen des C++–Teils. Diese Dateien wurden den neuen Anforderungen angepaßt.
tcl/ Dieses Verzeichnis enthält die Programmquellen des Tcl/Tk–Teils. Ein Teil der
darin enthaltenen Prozeduren wurde von EDE übernommen und den neuen
Anforderungen angepaßt.
Diese beiden Verzeichnisse beﬁnden sich in einem Verzeichnis namens teer, der zusätzlich
eine Datei Makefile enthält.
Damit der TEER–Anfrage–Editor installierbar ist, muß als Systemvoraussetzung ein UNIX–
System mit der graphischen X–Windows–Oberﬂäche vorhanden sein. Zusätzlich wird die
177
Kapitel D. Benutzerhandbuch
Programmiersprache Tcl mit dem Toolkit Tk gebraucht. Tcl sollte in der Version 7.5 oder
höher, Tk in der Version 4.1 oder höher verfügbar sein. Ferner werden die Erweiterungspakete TclX und TkX benötigt.
Das make–Kommando erzeugt mit Hilfe der Datei Makefile aus dem in dem Verzeichnis
c++ beﬁndlichen Quellcode das ausführbares Programm TEER. Der TEER–Anfrage–Editor
kann anschließend mit dem Kommando TEER aufgerufen werden.
D.2
Erstellung des TEER–Modells
Der TEER–Anfrage–Editor stellt nur Befehle zur Formulierung von Anfragen an ein TEER–
Schema zur Verfügung. Das bedeutet insbesondere, daß das TEER–Schema nicht im
TEER–Anfrage–Editor erstellt werden kann. Eine Möglichkeit zur Erstellung eines solchen
Schemas bietet das Programm EDE an. Da sich EER– und TEER–Schemata graphisch
nicht voneinander unterscheiden, stellt dieser Weg die unproblematischste Methode dar.
Der TEER–Anfrage–Editor erwartet als Eingabe eine EER–Schema–Speziﬁkationsdatei.
Dieses Dateiformat ist im Anhang der Arbeit [Zec97] beschrieben, der schematische Aufbau einer solchen Datei ist wie folgt:
SCHEMA Schemaname Schemagröße
ETYPES
{Entity-Spec}∗
END
ENTITY--CLUSTER
{Cluster-Spec}∗
END
RTYPES
{Relationship-Spec}∗
END
CONSTR
{Construction-Spec}∗
END
CONSTRAINTS
{Constraint-Spec}∗
END
In einer EER–Schema–Speziﬁkationsdatei werden im Kopf Name und Größe des Schemas
abgespeichert. In den folgenden Bereichen werden Entitytypen, Entity–Cluster, Relationshiptypen, Typkonstruktionen und Komponenten mit Namen, der graphischen Position
im Editor und den Beziehungen untereinander abgespeichert. Im letzten Bereich sind
benutzerdeﬁnierte Integritätsbedingungen abgelegt. Wird eine solche Datei in den TEER–
Anfrage–Editor eingelesen, wird das entsprechende Schema dargestellt, Entity–Cluster–
und Integritätsangaben jedoch überlesen. Diese Konzepte werden von dem Anfrage–Editor
nicht unterstützt, da sie in der TEER–Anfragesprache keine Rolle spielen.
Die zum Ausschnitt des Konzern–Schemas, in Abbildung 3.2 dargestellt, gehörige Schema–
Speziﬁkationsdatei hat folgenden Inhalt:
178
D.2. Erstellung des TEER–Modells
SCHEMA unbenannt 0.0c 0.0c 24.8546c 14.0777c
ETYPES
ENTITY FIRMA 755 177
ATTRIBUTE Firmenname single 0 -1 VARCHAR2 15 755 258 KEY
ENTITY ZULIEFERFIRMA 755 44
ENTITY VORPRODUKT 292 44
ENTITY PRODUKT 292 154
ATTRIBUTE ChargenNr single 0 -1 NUMBER 0 104 111 KEY
ATTRIBUTE ProdName single 0 -1 VARCHAR2 15 118 154 SIMPLE
ATTRIBUTE StPreis single 0 -1 NUMBER 0 119 196 SIMPLE
ENTITY ABTEILUNG 290 404
ATTRIBUTE AbtName single 0 -1 VARCHAR2 15 290 476 KEY
COMPONENT AbtLeiter single 0 -1 ANGESTELLTER 447 370 SIMPLE
COMPONENT Mitarbeiter set 0 -1 ANGESTELLTER 466 437 SIMPLE
ENTITY ANGESTELLTER 625 402
ATTRIBUTE AngName single 0 -1 CHAR 0 625 331 SIMPLE
ATTRIBUTE PersNr single 0 -1 INTEGER 0 775 328 KEY
ATTRIBUTE Gehalt single 0 -1 NUMBER 0 769 380 SIMPLE
ATTRIBUTE Position single 0 -1 CHAR 0 764 432 SIMPLE
END
ENTITY-CLUSTER
END
RTYPES
RELATIONSHIP liefert 508 44
PARTICIPANT ZULIEFERFIRMA 1 -1
PARTICIPANT VORPRODUKT 1 -1
RELATIONSHIP produziert 289 293
PARTICIPANT PRODUKT 1 1
PARTICIPANT ABTEILUNG 1 -1
ATTRIBUTE Auslastung single 0 -1 NUMBER 0 125 292 SIMPLE
RELATIONSHIP gehoert_zu 505 271
PARTICIPANT FIRMA 1 -1
PARTICIPANT ABTEILUNG 1 -1
END
CONSTR
CONSTRUCTION supset2 292 93 Nord PARTIAL
INPUT PRODUKT
OUTPUT VORPRODUKT
CONSTRUCTION supset1 755 115 Nord PARTIAL
INPUT FIRMA
OUTPUT ZULIEFERFIRMA
END
CONSTRAINTS
END
Diese Speziﬁkation wurde mit Hilfe des Programms EDE erstellt.
179
Kapitel D. Benutzerhandbuch
D.3
D.3.1
Handbuch
Das Hauptfenster
Die Abbildung D.3 zeigt das Hauptfenster des TEER–Anfrage–Editors. Das Fenster setzt
sich aus zwei Bereichen zusammen. Der größere beinhaltet einen Zeichenbereich, in dem
das TEER–Schema dargestellt wird. An der linken Seite ist eine Bedienleiste angebracht,
mit der die Erstellung einer Anfrage gesteuert wird. Der gesamte Bereich der graphischen
Oberﬂäche ist nur mit der linken Maustaste bedienbar. Nur durch sie sind Aktionen
auslösbar. Die mittlere und rechte Taste besitzen keine Funktion. Das Hauptfenster ist
dehnbar, wobei jedoch nur der Zeichenbereich vergrößert wird.
Abbildung D.3: Das Hauptfenster vom TEER–Anfrage–Editor
Die Knöpfe der Bedienleiste sind in sieben Gruppen aufgeteilt, die optisch voneinander
abgesetzt sind. Damit eine graphische Anfrage syntaktisch korrekt ist, sollte die Erstellung
in der Reihenfolge der Bedienknöpfe erfolgen. Dieses ist nicht zwingend notwendig, aber
sinnvoll. Ein entsprechender Programmablaufsplan ist in Abbildung D.4 dargestellt. Ein
gestrichelter Pfeil bedeutet dabei, daß eine Aktion aktivierbar ist oder auch übergangen
werden kann. Ein durchgezogener Pfeil bedeutet, daß die Aktion aktiviert werden muß
(bei zwei sich bietenden Möglichkeiten nur eine der beiden). Ein doppelter Pfeil bedeutet,
180
D.3. Handbuch
daß eine Aktion vom Programm automatisch aktiviert wird, der Benutzer von dort aber
wieder in den ursprünglichen Ablauf zurückkehren muß. Zur Formulierung einer Anfrage
müssen mindestens die Aktionen load und get verwendet werden.
load
remove
result link
remove
get
restrict
query
specification
duplicate
time link
projection
get
time link sopecification
predicate
specification
selection
restrict
select true time
restrict
restrict
predicate
specification
select time interval
selection
select true time
projection
time link
projection
project true time
select time interval
time link
predicate
specification
specify time interval
project time interval
predicate specification predicate specification
restrict
specify time interval
Abbildung D.4: Ablauf des Programms TEER–Anfrage–Editor
181
Kapitel D. Benutzerhandbuch
Der Reihenfolge der Bedienknöpfe zu folgen bedeutet, daß sie der Reihe nach von oben
nach unten bedient werden. Somit ist zuerst ein Schema zu laden (Bedienknopf load),
dann, falls erwünscht, die Editoroperationen remove und duplicate auszuführen. Anschließend können Attribute selektiert sowie Bedingungen formuliert werden. Diese beiden
Aktionen sind durch das Drücken der Knöpfe get bzw. restrict möglich. Der Knopf specify time interval wird automatisch eingeschaltet, wenn die Eingabe eines Intervalls
nötig ist. Dasselbe Verhalten hat der Knopf restrict, wenn eine booleschen Bedingung
im Rahmen eines Gültigkeitszeitraums angegeben werden muß.
Die nächsten Bedienelemente realisieren die Formulierung einer temporalen Selektion.
Eine Selektion besteht nach Deﬁnition aus einem Gültigkeitszeitraum und einem konstanten temporalen Element. Die Formulierung dieser beiden Angaben ermöglichen die
Knöpfe select true time und select time interval.
Da auf eine temporale Selektion eine Projektion angewendet werden darf, stehen die
nächsten drei Knöpfe zur Formulierung dieser zur Verfügung. Mit projection werden
die Elemente, auf die eine temporale Projektion ausgeführt werden soll, ausgewählt. Mit
einem der nächsten Knöpfe ist entweder ein Gültigkeitszeitraum (project true time)
oder ein konstantes temporales Element (project time interval) projizierbar.
Der vorletzte Knopf time–link dient dazu eine Anfrage zu formulieren, deren Ergebnis ein
temporales Element sein soll. Eine Weiterleitung dieses Ergebnisses an eine übergeordnete
Anfrage ist an dieser Stelle nicht möglich. Die Formulierung einer Time–link–Anfrage als
Unteranfrage wird weiter unten erklärt.
Mit dem exit–Knopf kann schließlich das Programm verlassen oder durch load ein neues
Schema geladen und somit eine neue Anfrage formuliert werden.
Damit eine graphische Anfrage syntaktisch korrekt ist, sind nicht alle aktivierbaren Funktionen auf alle Elemente anwendbar. Wann immer versucht wird, eine syntaktisch nicht
korrekte Aktion auszulösen, ertönt ein Piepton. Bei der Beschreibung des Programms wird
nur erklärt, wann welche Aktionen im Zusammenhang mit welchen Elementen möglich
sind. Die der Syntax nicht entsprechenden sich aber trotzdem anbietenden Möglichkeiten
werden unterbunden.
D.3.2
Laden eines Schemas
Das Laden eines Schema wird über den Bedienknopf load gesteuert. Ein Mausklick auf
diesen Knopf läßt das Fenster Dateiauswahl“ erscheinen. Es ist in Abbildung D.5 zu
”
sehen. Aus der Dateiliste ist dann eine Datei auszuwählen, die das Format einer EER–
Schema–Speziﬁkationsdatei haben muß. Wird versucht eine Datei mit einem anderen Format zu laden, erfolgt eine Fehlermeldung, und es kann erneut eine Datei ausgewählt werden. Der aus der Liste ausgewählte Name wird in den oberen Teil übernommen. Das Laden
des Schemas kann entweder durch einen Mausklick auf den Button OK oder einen doppelten Mausklick auf den Dateinamen in der Liste selbst ausgelöst werden. Die Auswahl
einer Datei kann aber auch durch einen Mausklick auf den Button Abbruch abgebrochen
werden.
182
D.3. Handbuch
Abbildung D.5: Die Dateiauswahl
D.3.3
Die Editoroperatoren Remove und Duplicate
In Abbildung D.6 ist der Ausschnitt des Konzern–Schemas geladen, dessen EER–Schema–
Speziﬁkation im Abschnitt D.2 angegeben wurde.
Abbildung D.6: Ausschnitt des Konzern–Schemas im Anfrageeditor
183
Kapitel D. Benutzerhandbuch
Remove
Wenn sich eine Anfrage nicht auf alle Schema–Elemente bezieht, sind diejenigen Elemente,
die nicht benötigt werden, zu löschen. Dazu steht eine Löschfunktion zur Verfügung. Sie
ist durch einen Mausklick auf den Knopf remove aktivierbar. Da nach dem Löschen
von Schema–Elementen das TEER–Schema syntaktisch immer noch korrekt sein muß,
dürfen die Elemente nicht beliebig gelöscht werden. Ist die Löschfunktion aktiviert, hat
der Cursor die Form eines Totenkopfs. Alle angeklickten Elemente werden gelöscht, sofern
sie an dieser Stelle des Löschvorgangs gelöscht werden dürfen. Kann ein Element nicht
gelöscht werden, ertönt ein Piepton.
Die Löschfunktion arbeitet nach den folgenden Regeln:
• Jedes beliebige Attribut kann gelöscht werden.
• Jede beliebige Komponente kann gelöscht werden.
• Relationshiptypen können nicht gelöscht werden.
• Typkonstruktionen können nicht gelöscht werden.
• Ein Entitytyp wird nur dann gelöscht, wenn er nur eine Verbindung mit einem
Relationshiptyp oder einer Typkonstruktion hat. Steht der Entitytyp gleichzeitig
mit zwei Relationshiptypen, Typkonstruktionen oder einem Relationship und einer
Typkonstruktion in Verbindung kann der Entitytyp nicht gelöscht werden.
Kann ein Entitytyp gelöscht werden, so werden alle zugehörigen Attribute und
Komponenten mit ihm gelöscht. Ist dieser Entitytyp mit einem zweistelligen Relationshiptyp verbunden, wird dieser Relationshiptyp mit seinen Attributen ebenfalls
gelöscht.
Ist der Entitytyp einziger Eingangs– oder Ausgangstyp einer Typkonstruktion, wird
mit dem Entitytyp auch die Typkonstruktion gelöscht.
Für das obige Konzern–Schema in Abbildung D.6 bedeutet das, daß alle Attribute und
Komponenten gelöscht werden können, jedoch kein einziges Entity, da das Schema eine
Ringstruktur hat (siehe Abbildung D.7). Für einen solchen Fall, ist die Löschfunktion
durch einen doppelten Mausklick auslösbar. Von diesem Moment an ist der Benutzer für
die syntaktische Korrektheit des entstehenden TEER–Schemas verantwortlich.
184
D.3. Handbuch
Abbildung D.7: Die durch das Löschen entstandene Ringstruktur des Konzern–Schemas
Duplicate
Mit Hilfe des Knopfs duplicate wird eine Kopierfunktion aktiviert. Das Kopieren eines
Diagrammteils bedeutet, das eine geschachtelte Anfrage gestellt werden soll. Die beiden
einzigen von der TEER–Anfragesprache angebotenen Möglichkeiten sind, daß entweder
eine Anfrage mit einem Query–result–link oder mit einer Time–link–Unteranfrage formuliert werden soll. Ist die Kopierfunktion aktiviert, ist im Zeichenbereich ein Rahmen
aufziehbar. Alle innerhalb des Rahmen liegenden Elemente werden rot markiert und der
syntaktisch korrekte Teil dieses Teilschemas in einen zweiten Zeichenbereich kopiert. Dieser zweite Zeichenbereich liegt in einem neuen Fenster, das automatisch erzeugt wird.
Ehe das neue Fenster erscheint, ist festzulegen, ob eine Unteranfrage auf Grund eines
Query–result– oder eines Time–links gestellt wird. Dazu erscheint, nachdem die selektierten Elemente markiert wurden, die Listbox query specification, zu sehen in Abbildung
D.8. Der Kopiervorgang wird nur fortgesetzt, wenn eine der beiden Möglichkeiten durch
einen doppelten Mausklick ausgewählt wird.
185
Kapitel D. Benutzerhandbuch
Abbildung D.8: Die Query Speciﬁcation
Query–result–link
Wählt der Benutzer die Möglichkeit result link, wird eine Anfrage, die einen Query–
result–link beinhaltet, formuliert. Der kopierte Diagrammteil wird in dem Zeichenbereich
eines neuen Fensters mit Namen subquery: result link kopiert. Dieses Fenster hat, der
Syntax der TEER–Anfragesprache folgend, nur die drei Knöpfe remove, get und restrict
in seiner Bedienleiste. Die Abbildung D.15 zeigt das subquery: result link–Fenster, das
im Rahmen der Erstellung der Beispielanfrage 4.6 erzeugt wird.
Time–link
Wird vom Benutzer die Möglichkeit time link im Fenster query specification ausgewählt, bedeutet das, daß das Ergebnis der Time–link–Anfrage, die in dem neuen Zeichenbereich formuliert wird, im Rahmen einer temporalen Projektion oder Selektion benutzt wird. Daher hat der Benutzer als nächstes diese Auswahl zu treﬀen. Es erscheint
das Fenster time link specification, wo durch einen doppelten Mausklick das weitere
Vorgehen bestimmt wird. Wählt der Benutzer die temporale Projektion aus, doppelter
Mausklick auf projection, muß als nächstes das temporale Prädikat, das bei dieser Projektion benutzt wird, bestimmt werden. Das geschieht abermals durch eine Listbox. Das
Fenster predicate specification beinhaltet alle in der TEER–Anfragesprache verfügbaren Prädikate.
Abbildung D.9: Die Time–Link–Speciﬁcation
186
D.3. Handbuch
Abbildung D.10: Die Predicate–Speciﬁcation
Nachdem ein Prädikat durch einen doppelten Mausklick ausgewählt worden ist, wird das
neue Fenster mit dem kopierten Schema erzeugt. Dieses Fenster hat den Namen subquery: time link. Im Hauptfenster wird ein Kasten erzeugt, der alle Schema–Elemente
enthält. Auf diesen Kasten zeigt ein Pfeil, der mit dem temporalen Prädikat sowie der Vorschrift get time beschriftet ist und an dessen Anfang ein blauer Kasten mit der Beschriftung subquery erzeugt wird. Abbildung D.11 zeigt diesen Zustand des Hauptfensters.
Das neu erzeugte Fenster subquery: time link enthält eine etwas größere Bedienleiste
als das Fenster subquery: result link. Es stehen zusätzlich noch die Bedienknöpfe zur
Formulierung einer temporalen Selektion zur Verfügung.
Wird vom Benutzer im Fenster time link specification die temporale Selektion ausgewählt, wird das Fenster subquery: time link erzeugt. Die Selektion im Hauptfenster
kann nicht automatisch erzeugt werden, da sich diese nur auf einen Entity– oder Relationshiptyp beziehen darf. Das Programm merkt“ sich aber, daß eine solche Unteranfrage
”
gestellt wird, und setzt im Rahmen der Formulierung der temporalen Selektion im Hauptfenster dann den subquery–Kasten an die Stelle des anzugebenden temporalen Elements.
Nachdem alle ausgewählten Elemente kopiert worden sind, nehmen die markierten Elemente wieder ihre ursprüngliche Farbe an.
Die Abbildungen D.11 und D.12 zeigen die graphische Formulierung der Beispielanfrage
4.12. In dieser Anfrage wird das Ergebnis einer Unteranfrage, das ein temporales Element
ist, auf die übergeordnete Anfrage projiziert. Die Abbildung D.12 enthält das Fenster subquery: time link, die Abbildung D.11 das Hauptfenster mit der übergeordneten Anfrage.
Die im Hauptfenster farbig markierten Elemente sind die Attribute, deren Werte ausgegeben werden sollen. Der dabei angewendete Get–Operator sowie der zur Formulierung
benutzte Restrict–Operator werden in den nächsten beiden Abschnitten vorgestellt.
187
Kapitel D. Benutzerhandbuch
Abbildung D.11: Die übergeordnete Anfrage der Beispielanfrage 4.12
Abbildung D.12: Die Time–link–Unteranfrage der Beispielanfrage 4.12
188
D.3. Handbuch
Bemerkung
Die Editoroperatoren remove und duplicate können in einer beliebigen Reihenfolge
benutzt werden. Einmal gelöschte Elemente können nicht mehr zurückgeholt werden und
somit ist ein Kopieren vor einem Löschen in vielen Fällen notwendig.
D.3.4
Der Get–Operator
Mit Hilfe des Get–Operators können Attribute, deren Werte ausgegeben werden sollen,
ausgewählt werden. Im TEER–Anfrage–Editor ist dieses durch eine farbige Markierung
der Elemente realisiert. Wird in der Bedienleiste die Aktion Get durch einen Klick auf
den Knopf get ausgelöst, nimmt der Cursor eine sternförmige Gestalt an. Alle Attribute,
die jetzt angeklickt werden, werden rot markiert. Durch ein erneutes Anklicken bereits
selektierter Attribute werden diese deselektiert.
D.3.5
Der Restrict–Operator
Mit Hilfe des Restrict–Operators können Bedingungen an Attribute formuliert werden.
Dazu ist der restrict–Knopf anzuklicken. Der Cursor nimmt die Form eines Stiftes an.
Alle Attribute sind damit auswählbar. Durch das Anklicken wird in die Ellipse ein Cursor
vor den Attributnamen gesetzt. Mit Hilfe der Pfeiltasten kann der Cursor in der Ellipse
nach rechts und links bewegt werden. Sowohl ein Backspace als auch alle anderen Tastatureingaben werden eingelesen. Die Abbildung D.13 zeigt die Beispielanfrage 4.5 im
TEER–Anfrage–Editor. Zur Erstellung dieser Anfrage wurden die dem Remove–, Get– und
Restrict–Operatoren entsprechenden Knöpfe benutzt.
189
Kapitel D. Benutzerhandbuch
Abbildung D.13: Die Beispielanfrage 4.5
D.3.6
Der Query–result–link–Operator
Eine Anfrage mit einem Query–result–link wird, wie bereits oben erklärt, über die Aktion
duplicate formuliert. Die Variable, die den Wert der Unteranfrage übergibt, wird, wie
in der TEER–Anfragesprache, direkt den entsprechenden Attributen der übergeordneten
Anfrage und der Unteranfrage zugeordnet. In der Formulierung des Vergleichs im Hauptfenster ist der erweiterte Vergleichsoperator Θ = θall oder Θ = θany zu benutzen. Die
Formulierung der Beispielanfrage 4.6 im TEER–Anfrage–Editor, ist in den beiden Fenster
D.15 und D.14 zu sehen. Das Fenster subquery: result link, Abbildung D.15, enthält
die Unteranfrage, das Fenster in Abbildung D.14 die übergeordnete Anfrage.
190
D.3. Handbuch
Abbildung D.14: Die übergeordnete Anfrage der Beispielanfrage 4.6
Abbildung D.15: Die Unteranfrage der Beispielanfrage 4.6
191
Kapitel D. Benutzerhandbuch
D.3.7
Der temporale Selektionsoperator
Eine temporale Selektion ist mit Hilfe der Knöpfe select true time und select time
interval formulierbar. Eine Selektion besteht nach Deﬁnition immer aus einem Gültigkeitszeitraum und einem konstanten temporalen Element. Der Gültigkeitszeitraum ist
nach einem Mausklick auf den Knopf select true time im Zeichenbereich erzeugbar.
Durch einen Mausklick in diesem Bereich wird ein grüner Kasten mit der Beschriftung
bool expr an der Mausposition plaziert. An dem Mauszeiger hängt jetzt eine Verbindungslinie, die zu einem Entity– oder Relationshiptypen gezogen werden kann. Ist eine
Verbindung hergestellt worden, wird automatisch die Aktion restrict aktiviert. Es kann
sofort damit der grüne Kasten angeklickt und eine boolesche Bedingung formuliert werden.
Der zweite Bestandteil einer Selektion, das konstante temporale Element, wird mit Hilfe
des Knopfes select time interval erzeugt. Ist dieser Knopf aktiviert, kann im Zeichenbereich ein blauer Kasten mit der Beschriftung time interval plaziert werden. An der
Maus hängt wieder eine Verbindungslinie, die jetzt zu dem grünen Kasten gezogen wird.
Am Ende dieser Linie beﬁndet sich ein Pfeil. Sobald die Verbindung hergestellt ist, erscheint das Fenster predicate specification, und das temporale Prädikat der Selektion
ist auszuwählen. Es wird automatisch am Pfeilende plaziert. Jetzt ist vom Programm die
Aktion specify time interval aktiviert, und der blaue Kasten kann angeklickt werden.
Es erscheint ein Cursor in dem Kasten, und das temporale Element kann eingegeben
werden.
Wurde im Laufe der Anfrageformulierung ein Teil des Schemas kopiert, um ein temporales
Element für die Selektion berechnen zu lassen, hat der blaue Kasten die Beschriftung
subquery. Es ist in einem solchen Fall nicht möglich, ein anderes temporales Element
einzugeben.
In Abbildung D.16 ist das Aussehen der Beispielanfrage 4.9 im TEER–Anfrage–Editor zu
sehen.
192
D.3. Handbuch
Abbildung D.16: Die Beispielanfrage 4.9
D.3.8
Der temporale Projektionsoperator
Eine temporale Projektion ist mit Hilfe der Knöpfe projection, project true time und
project time interval formulierbar. Als erstes ist die Aktion projection zu aktivieren. Im Zeichenbereich ist nun ein Kasten von oben links nach rechts unten aufzuziehen.
Mit der Maus ist in den Zeichenbereich zu klicken, der Kasten aufzuziehen, während die
Maustaste gedrückt bleibt. An der Stelle, an der sich der Mauszeiger beim Loslassen der
Maustaste beﬁndet, ist die untere rechte Ecke des Kastens. Umfaßt dieser Kasten nicht
alle Schema–Elemente, ertönt ein Piepton, und der Kasten wird nicht erzeugt. Nach Deﬁnition muß eine temporale Projektion alle in einem TEER–Schema enthaltenen Elemente
umfassen. Der Kasten ist erneut zu erzeugen, die Aktion projection ist noch aktiv.
Nachdem ein Kasten erzeugt wurde, muß der Benutzer wählen, ob ein Gültigkeitszeitraum
oder ein temporale Element projiziert werden soll. Der erste Knopf unter projection existiert zur Projektion eines Gültigkeitszeitraums. Sobald project true time aktiviert ist,
kann ein grüner Kasten im Zeichenbereich mit der Beschriftung bool expr plaziert werden. Am Cursor hängt dann eine Verbindungslinie, die zum Kasten zu ziehen ist. Am Ende
dieser Linie beﬁndet sich Pfeil. Sobald dieser plaziert ist, ist das temporale Prädikat der
Projektion anzugeben. Dazu erscheint automatisch das Fenster predicate specification.
und eines der aufgelisteten Prädikate ist durch einen doppelten Mausklick auszuwählen.
Dieses Prädikat wird dann am Pfeilende plaziert. Das Programm aktiviert daraufhin die
Aktion restrict, und die boolesche Bedingung, auf Grund derer der Gültigkeitszeitraum
193
Kapitel D. Benutzerhandbuch
bestimmt werden soll, ist einzugeben. Die Abbildung D.17 stellt eine solche temporale
Projektion dar, die Beispielanfrage 4.8.
Abbildung D.17: Die Beispielanfrage 4.8
Die andere Möglichkeit einer Projektion ist, daß ein temporales Element projiziert werden
soll. Dazu ist die Aktion project time interval zu aktivieren. Die Vorgehensweise ist
hier genauso, wie wenn ein Gültigkeitszeitraum projiziert werden würde. Der graphische
Unterschied besteht darin, daß der im Zeichenbereich erzeugt Kasten blau ist und die Beschriftung time interval trägt. Das Programm aktiviert auch nicht die Aktion restrict,
sondern die sortenmäßig passende Aktion restrict time interval. In Abbildung D.18 ist
die Formulierung der Beispielanfrage 4.7 im TEER–Anfrage–Editor zu sehen.
194
D.3. Handbuch
Abbildung D.18: Die Beispielanfrage 4.7
Wurde jedoch bereits über die Aktionen duplicate eine temporale Projektion formuliert,
sind die Aktion projection, project true time und project time interval nicht mehr
aktivierbar. Genauso sind project true time und project time interval nur aktivierbar, wenn ein Kasten mit Hilfe von projection bereits erzeugt wurde.
Die Abbildung D.19 enthält die Beispielanfrage 4.10 im TEER–Anfrage–Editor. In dieser
Anfrage wird eine temporale Projektion auf eine Schema angewendet, das bereits eine
temporale Selektion enthält.
195
Kapitel D. Benutzerhandbuch
Abbildung D.19: Die Beispielanfrage 4.10
D.3.9
Der Time–link–Operator
Mit Hilfe des Time–link–Operators kann ein temporales Element berechnet werden. Der
im Editor verfügbare Knopf time–link dient nur zur Formulierung von Anfragen, deren
Ergebnis dieses berechnete temporale Element ist. Soll ein Time–link in Verbindung mit
einer temporalen Projektion oder Selektion verwendet werden, ist dieses nur über die
Aktion duplicate möglich. Das Vorgehen in diesem Fall wurde bereits oben erklärt.
Ist die Aktion time–link aktiviert worden, ist im Zeichenbereich ein Kasten nach denselben Regeln wie bei der Aktion projection zu erzeugen. Ist der Kasten plaziert worden,
wird von der rechten Seitenmitte ausgehend ein Pfeil mit der Vorschrift get time erzeugt.
Die Abbildung D.20 enthält die graphische Formulierung der Beispielanfrage 4.11.
196
D.3. Handbuch
Abbildung D.20: Die Beispielanfrage 4.11
D.3.10
Anmerkungen
Bei der Formulierung einer graphischen Anfrage im TEER–Anfrage–Editor wird die syntaktische Korrektheit dieser Anfrage nicht hundertprozentig kontrolliert. Es wird kontrolliert,
ob der syntaktische Aufbau der Anfrage stimmt., da immer nur syntaktisch folgerichtige Aktionen auslösbar sind. Es wird nicht überprüft, ob Eingaben, die von der Tastatur
eingelesen werden, syntaktisch richtig sind. Diese Tastatureingaben beschränken sich auf
boolesche Bedingungen und die Angabe von temporalen Elementen.
Der TEER–Anfrage–Editor war ursprünglich als Benutzerschnittstelle zu einer ORACLE–
Datenbank geplant. Daher sollte die syntaktische Korrektheit dieser vom Benutzer
angegebenen Konstrukte von ORACLE überprüft werden und eventuelle ORACLE–
Fehlermeldungen zurückgegeben werden. Dieser Teil der Implementierung war im zeitlichen Rahmen dieser Arbeit nicht realisierbar, so daß die syntaktische Korrektheit einer
Anfrage nicht immer gewährleistet ist.
197
Kapitel D. Benutzerhandbuch
198
Literaturverzeichnis
[CER90] Czejdo, B., Elmasri, R., Rusinkiewicz, M.: A Graphical Data Manipulation Language for an Extended Entity–Relationship Model. Computer, Vol. 23
No. 3. IEEE Computer Press, 1990.
[Che76] Chen, P.P.: The entity–relationship model: toward a uniﬁed view of data. ACM
Transactions on Database Systems, 1, 1, 9–36.
[CS89]
Catarci, T., Santucci, G.: Query by Diagram: A Graphical Query System.
Proc. of the eight Int. Conference on Entity–Relationship Approach, 1989.
[Dat90] Date, C.J.: An Introduction to Database Systems, Volume I, Fifth Edition.
Addison–Wesley, Reading, MA, 1990.
[EEK90] Elmasri, R., El–Assal, I., Kouramajian, V.: Semantics of temporal data in an extended ER model. Proc. of the ninth Int. Conference on Entity–
Relationship Approach, 1990.
[EK92]
Elmasri, R., Kouramajian, V.: A Temporal Query Language Based on Conceptual Entities and Roles. Proc. of the eleventh Int. Conference on Entity–
Relationship Approach, 1992.
[EN94]
Elmasri, R., Navathe, S.B.: Fundamentals of Database Systems (Second
Edition). Addison–Wesley, Amsterdam, The Netherlands, 1994.
[EW90] Elmasri, R., Wuu, G.T.J.: A Temporal Model and Query Language for ER
Databases. IEEE Data Engineering Conference, 1990.
[EWK93] Elmasri, R., Wuu, G.T.J., Kouramajian, V.: A Temporal Model and
Query Language for EER Databases. in: Tansel, A., Clifford, J., Gadia,
S., Jajodia, S., Segev, A., Snodgrass R.: Temporal Databases: Theory,
Design, and Implemetation., Database Systems and Application Series, Benjamin/Cummings, Redwood City, CA, 1993.
[Gog94] Gogolla, M.: An Extended Entity–Relationship Model. Lecture Notes in
Computer Science. Springer–Verlag, Heidelberg, 1994.
[GY95] Gadia, S.K., Yeung, C.: A Generalized Model for a Relational Temporal
Database. ACM SIGMOD Conference, 1988.
199
LITERATURVERZEICHNIS
[HE91]
Hohenstein, U., Engels, G.: SQL/EER – Syntax and Semantics of an
Entity–Relationship–Based Query Language. Informatik–Berichte 91-02. Technische Universität Braunschweig, 1991.
[Hoh88] Hohenstein, U.: Automatic Transformation of Entity–Relationship Schemas
into Relational Schemas. Informatik–Berichte 88-10. Technische Universität
Braunschweig, 1988.
[Hoh90] Hohenstein, U.: Ein Kalkül für ein erweitertes Entity–Relationship–Modell
und seine Übersetzung in einen relationalen Kalkül. Dissertation. Technische
Universität Braunschweig, 1990.
[Hoh93] Hohenstein, U.: Formale Semantik eines erweiterten Entity–Relationship–
Modells. Teubner–Texte zur Informatik. Teubner–Verlagsgesellschaft, Leibzig,
1993.
[KG95] Kouramajian, V., Gertz, M.: A Graphical Query Language for Temporal
Databases. in: Papazoglou, Michael P.: OOER’95: Object-Oriented and
Entity-Relationship Modeling. Springer-Verlag, Berlin, 1995.
[KL95]
Koch, G., Loney, K.: ORACLE: The Complete Reference, Third Edition.
Oracle Press, McGraw–Hill, Berkeley, 1995.
[Ku94]
Kuhn, B.: Implementierung einer SQL–Erweiterung für temporale Datenbanken. Studienarbeit, Institut für Informatik, Universität Hannover, 1994.
[OS94]
Oberweis, A., Sänger, V.: GTL – A Graphical Language For Temporal
Data. Proc. of the Seventh Int. Working Conference on Scientific and Statistical
Database Management, Charlottesville/Virginia, IEEE Computer Press, 1994.
[Ous95] Ousterhout, J.K.: Tcl und Tk: Entwicklung graﬁscher Benutzerschnittstellen
für das X Window System. Addison–Wesley (Deutschland), Bonn, 1995.
[Ull88]
Ullman, J.D.: Principles of Database and Knowledge Base Systems Vol. I
(Third edition). Computer Science Press, Rockville, D, 1988.
[Vos94] Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement–
Systeme (2. Auﬂage). Addison–Wesley (Deutschland), Bonn, 1994.
[Wel95] Welch, B.B.: Practical Programming in Tcl and Tk. Prentice Hall, Upper
Saddle River, New Jersey, 1995.
[Zec97]
Zech, I.: Entwicklung eines Werkzeugs zur Übersetzung von EER–Datenbankschemata nach ORACLE/SQL. Diplomarbeit, Institut für Informatik, Universität Hannover, 1997.
200
Abbildungsverzeichnis
2.1 Konzern–Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Hierarchischer Aufbau der Prädikatenlogik 1. Ordnung . . . . . . . . . . . 33
2.3 Rekursiver Aufbau des EER–Kalküls . . . . . . . . . . . . . . . . . . . . . 33
3.1 Die temporale Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Ausschnitt des Konzern–Schemas . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Beispiel einer condition box . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Der Query–result–link bzgl. Entity–Attributen . . . . . . . . . . . . . . . . 75
4.3 Die temporale Projektion temp projtemp
pred temp elem proj (teer)
. . . . . . . 76
4.4 Der True–time–Operator in Verbindung mit einer temporalen Projektion . 78
4.5 Die temporale Selektion temp seltrue
time temp pred cal temp elem (E)
. . . . . . 79
4.6 Time–link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.7 Time–link im Rahmen einer temporalen Projektion . . . . . . . . . . . . . 82
4.8
Ableitungsbaum“
”
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
D.1 Modulstruktur des Programmkerns . . . . . . . . . . . . . . . . . . . . . . 176
D.2 Zusammenhang zwischen Tcl/Tk– und C++–Teil . . . . . . . . . . . . . . 177
D.3 Das Hauptfenster vom TEER–Anfrage–Editor . . . . . . . . . . . . . . . . . 180
D.4 Ablauf des Programms TEER–Anfrage–Editor . . . . . . . . . . . . . . . . . 181
D.5 Die Dateiauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
D.6 Ausschnitt des Konzern–Schemas im Anfrageeditor . . . . . . . . . . . . . 183
D.7 Die durch das Löschen entstandene Ringstruktur des Konzern–Schemas . . 185
D.8 Die Query Speciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
D.9 Die Time–Link–Speciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . 186
D.10 Die Predicate–Speciﬁcation
. . . . . . . . . . . . . . . . . . . . . . . . . . 187
D.11 Die übergeordnete Anfrage der Beispielanfrage 4.12 . . . . . . . . . . . . . 188
D.12 Die Time–link–Unteranfrage der Beispielanfrage 4.12 . . . . . . . . . . . . 188
D.13 Die Beispielanfrage 4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
201
ABBILDUNGSVERZEICHNIS
D.14 Die übergeordnete Anfrage der Beispielanfrage 4.6 . . . . . . . . . . . . . . 191
D.15 Die Unteranfrage der Beispielanfrage 4.6 . . . . . . . . . . . . . . . . . . . 191
D.16 Die Beispielanfrage 4.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
D.17 Die Beispielanfrage 4.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
D.18 Die Beispielanfrage 4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
D.19 Die Beispielanfrage 4.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
D.20 Die Beispielanfrage 4.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
202
Index
bts, 22
Aggregation
EER–Modell, 14
Alphabet
EER–Kalkül, 33
TEER–Kalkül, 88
Anfrage
EER–Kalkül, 38
TEER–Anfragesprache,
siehe
TEER–DB–Anfragesprache
TEER–Kalkül, 92
arguments, 20
Assoziation
EER–Modell, 15
Atomare Formel
Semantik, 37
Syntax, 35
ATTR, 27
Attribut, 13
Wertebereich, 14
Attributtyp
EER–Diagramm
obligatorisch, 16
optional, 17
EER–Modell
komplex–objektwertig, 15
objektwertig, 14
obligatorisch, 14
optional, 14
Ausgangstyp, siehe Typkonstruktion
avg, 22
COMP, 27
CONSTRUCTION, 27
count, 22
date, 48
Datenbankzustand, 29
temporaler, 45
Datenmodell, 13
Datentyp–Signatur
Interpretation, 20
relationale, 40
Semantik, 21
Syntax, 20
Deklaration, 35
destination, 20
domain, 14, 28
DT, 20
Duplicate–Operator, 73
EBNF–Notation, 56
Editor, 72
EER–Diagramm, 16
EER–Kalkül, 32
Semantik, 37
Syntax, 33
EER–Modell, 13
Semantik, 29
Syntax, 27
EER–Schema, 13
EER–Signatur, 28
EER–Standarddatentyp–Signatur, 21
Eingangstyp, siehe Typkonstruktion
Entity, 13, 14
seeEntitytyp, 13
entity, 28
Entity–Attributtyp
EER–Diagramm, 16
EER–Modell, 14
Entitytyp
B(S), 20
bag, 14
Belegung, 36
Bereich, 35
β, 36
Beziehung, siehe Relationship
boolescher Ausdruck
Gültigkeitszeitraum, 71
temporal, 70
203
INDEX
occ, 22
ω, 20
Operation, siehe Operationssignatur
Operationssignatur, 20
OPNSDT , 20
OPNSREL , 40
OPNSTDT , 48
output, 28
EER–Diagramm, 16
EER–Modell, 14
TEER–Modell, 45
ER–Modell, 13
E-TYPE, 27
F (S), 20
Formel
Semantik, 37
Syntax, 36
P(S), 20
participants, 28
π, 20
pos, 22
Prädikat, siehe Prädikatsignatur
Prädikatsignatur, 20
PREDDT , 20
PREDREL , 40
PREDTDT , 48
Projektion, siehe temporale Projektion
Generalisierung
EER–Modell, 15
Get–Operator, 73
Gruppierung, siehe Assoziation
I, 44
∈, 22
ind, 22
input, 28
interval, 48
Intervall, 44
maximal, 45
IOPNS , 20
IPRED , 20
ISORT , 20
Query–result–link–Operator, 74
Relationenmodell, 39
Relationenschema
Semantik, 39
Syntax, 39
Relationship, 13, siehe Relationshiptyp
EER–Modell, 15
Relationship–Attributtyp
EER–Diagramm, 16
EER–Modell, 15
Relationshiptyp
EER–Diagramm, 16
EER–Modell, 15
TEER–Modell, 46
REL(DT), 40
relship, 28
REL-TYPE, 39
Remove–Operator, 72
Restrict–Operator, 73
ROLE, 27
Rollenname
EER–Diagramm, 16
EER–Modell, 15
R-TYPE, 27
Kardinalität
EER–Diagramm, 16
EER–Modell, 16
Komponente
EER–Diagramm, 17
EER–Modell, 14
TEER–Modell, 46
list, 14
ltb, 22
lts, 22
M, 39
max, 22
min, 22
Modellierungskonzepte
EER–Modell, 13
ER–Modell, 13
Modelltransformation, 39
µ, 29
µ[DT], 21
S + , 20
S ∗ , 20
Objekt, siehe Entity
204
INDEX
temporaler Selektionsoperator, 79
temporales Element, 44
Term
Semantik, 37
Syntax, 35
TE type, 48
T F = {T , Tt , Tt,t }, 97
Time–link–Operator, 81
True–time–Operator, 78
[ts , te ], 44
type, 28
Typkonstruktion
EER–Diagramm, 17
EER–Modell, 15
TEER–Modell, 46
Schlüssel, 14
Schlüsselattribut, siehe Schlüsselattributtyp
Schlüsselattributtyp
EER–Diagramm, 17
EER–Modell, 14
TEER–Modell, 45
Schlüsselkandidat, 14
sel, 22
Selektion, siehe temporale Selektion
set,
14
, 29
σ, 29
σt , 45
[σ, β] |= ϕ, 37
[σt , β] |= ϕ, 94
[σ, β](τ ), 37, 94
SORTDT , 20
SORTREL , 40
SORTTDT , 48
source, 20
Spezialisierung
EER–Modell, 15
Stammrelation, 40
sum, 22
surrogate, 40
Surrogat, 40, 45
Universum, 29
Valid–Time, 45
Variable
frei, 36
gebunden, 36
ϕt , 92
Zeit, 44
Zeitintervall, siehe Intervall
Zeitpunkt, 44
T , 44
TE, 44
TEER–Anfrage–Konstrukte, 69
TEER–Datenbank–Anfragesprache
Syntax, 84, 165
Transformation in Kalkül, 97
TEER–Datenbank–Anfragesprache, 73
TEER–Diagramm, 43
TEER–Kalkül, 86
Semantik, 94
Syntax, 88
TEER–Modell, 43
TEER–Standarddatentyp–Signatur, 47
temporale Hierarchie, 44
temporale Projektion, 72
temporale Selektion, 71
temporale Zuordnung, 45
temporales Element, 45
temporaler Projektionsoperator, 75
205
Erklärung
Hiermit erkläre ich, Barbara Ingrid Kuhn, daß ich meine Diplomarbeit, ,,Entwicklung
einer Anfragesprache für temporale Datenbanken: Semantik, Ausdrucksfähigkeit und graphische Benutzerschnittstelle”, selbständig verfaßt und keine anderen als die angegebenen
Quellen und Hilfsmittel benutzt habe.
Hannover, den 19. November 1997.