\section{Objektorientierte Datenbanksprachen}
\label{Objektorientierte Datenbanksprachen}

Ziel dieses Abschnittes ist es, dem Leser ein tieferes Verst"andnis
f"ur objektorientierte Datenbanken zu geben, wobei sich die
Betrachtungen auf den ODMG-93 Standard beschr"anken.  Nach der
Darlegung allgemeiner charakteristischer Eigenschaften
objektorientierter Datenbanken in Abschnitt \ref{Charakteristische
  Eigenschaften objektorientierter Datenbanken} wird in Abschnitt
\ref{Zur Nutzung objektorientierter Datenbanksprachen} zun"achst die
Notwendigkeit eines weiteren Datenmodells motiviert.  Abschnitt
\ref{Ueberblick ueber den ODMG-93 Standard} verschafft dann einen
"Uberblick "uber den ODMG-93 Standard, dessen Objektmodell in
Abschnitt \ref{Vergleich des ODMG-93 und des OMG Objektmodells} in
Beziehung zum Objektmodell der Object Management Group gesetzt wird.
Analog zu SQL werden anschlie"send die Datendefinitionssprache ODL
(\ref{Datendefinition in ODL}) und die Anfragesprache OQL
(\ref{Anfragen in OQL}) erl"autert.

\subsection{Charakteristische Eigenschaften objektorientierter Datenbanken}
\label{Charakteristische Eigenschaften objektorientierter Datenbanken}

\comment{OO Manifesti wiedergeben oder in 1.2.6 integrieren 
und hier nur Verweis.}

\subsection{Zur Nutzung objektorientierter Datenbanksprachen}
\label{Zur Nutzung objektorientierter Datenbanksprachen}

Im Vergleich zu SQL streben objektorientierte Datenbanksprachen eine
wesentlich weitergehende \e{Modellierungsm"achtigkeit} an, die neben
der Beschreibung von persistenten Datenstrukturen auch die
Beschreibung von Verhalten (prozeduralem Code) mit einschlie"st.
Informationssysteme, die mit objektorientierten Datenbanken entwickelt
werden, besitzen daher auch eine substantiell andere \e{Architektur}
als Datenbanksysteme, die mit relationalen Datenbanksystemen
realisiert werden.

\begin{itemize}
\item Abbildung \ref{Architektur mit SQL-Datenbanken} zeigt, da"s bei
  der Nutzung von SQL eine \e{explizite Kommunikation} zwischen
  Anwendungsprogrammen (geschrieben in konventionellen Sprachen der
  dritten Generation wie C, Pascal, COBOL, FORTRAN, ...) und dem
  Datenbanksystem "uber SQL-Kommandos und -Anfragen stattfindet. Die
  Argumente der Kommandos und die Ergebnisse der Anfragen werden "uber
  spezielle Mechanismen zwischen dem Hauptspeicher und dem externen
  persistenten Speicher \e{kopiert}. Dabei mu"s eine explizite
  Umwandlung zwischen den typisierten Datenstrukturen der
  Programmiersprache (Arrays, verkettete Listen, Records) und den
  SQL-Datenstrukturen (Tabellen, Zeilen) stattfinden.

\item Abbildung \ref{Architektur mit objektorientierten Datenbanken}
  zeigt, da"s bei der Nutzung eines objektorientierten Systems eine
  \e{implizite Kommunikation} zwischen den Anwendungsprogrammen
  (geschrieben in einer speziellen objektorientierten
  Datenbanksprache, z.B. O$_{2}$C oder Persistent C++) und dem
  Objektspeicherungssystem stattfindet. Der Anwendungsprogrammierer
  kann \e{direkt} auf persistenten Datenstrukturen arbeiten
  (Objektinstanziierung, Attributzugriff, Zuweisung, Methodenaufruf,
  ...), die dem gleichen Typsystem wie die fl"uchtigen Datenstrukturen
  gehorchen, so da"s keine f"ur den Programmierer sichtbare
  Konvertierung zwischen Hauptspeicherstrukturen und persistenten
  Datenstrukturen stattfinden mu"s (Persistenzabstraktion, vgl.
  Abschnitt \ref{Persistenzabstraktion}).  Insbesondere k"onnen
  Programmvariablen direkt persistente Objekte \e{referenzieren}.
\end{itemize}

\begin{figure}
\begin{center}Fig:xx  "ahnlich zu ODMG S. 3
\end{center}
\caption{Architektur eines Informationssystems bei der Realisierung 
mit SQL-Datenbanken}
\label{Architektur mit SQL-Datenbanken}
\end{figure}

\begin{figure}
\begin{center}Fig:xx  "ahnlich zu ODMG S. 3
\end{center}
\caption{Architektur eines Informationssystems bei der Realisierung 
mit objektorientierten Datenbanken}
\label{Architektur mit objektorientierten Datenbanken}
\end{figure}

Neben der Vermeidung des \e{impedance mismatch} bieten
objektorientierte Datenbanksprachen folgende \e{Vorteile} gegen"uber
SQL-L"osungen bei der Entwicklung von Informationssystemen:

\begin{description}
\item [Datenmodellierungsm"achtigkeit:] Wie in den folgenden
  Abschnitten \ref{Ueberblick ueber den ODMG-93 Standard} --
  \ref{Klassen als Implementierungen von Typen} n"aher beschrieben
  wird, k"onnen Programmierer die Strukturen und das Verhalten des
  Informationssystems durch anwendungsnahe Konzepte wie Objekte,
  Klassen und Nachrichten direkt modellieren, es ist keine Abbildung
  in flache Reihen innerhalb von Tabellen erforderlich.

\item [Uniformit"at:] Programmierer m"ussen nur \e{eine} Sprache zur
  Datendefinition und Datenmanipulation (DDL und DML) erlernen, die
  uniform f"ur fl"uchtige und persistente, lokale und globale Daten
  kleinen und gro"sen Umfangs gilt.

\item [Kompaktheit:] Datenbankprogramme beschr"anken sich auf die
  eigentlichen, anwendungsrelevanten Algorithmen und enthalten keine
  aufwendigen Transfer- und Konvertierungsroutinen zum Datenaustausch
  mit der SQL Datenbank.

\item [Wartbarkeit:] Typinformationen f"ur persistente globale und
  fl"uchtige lokale Daten sind in einem einheitlichen Format
  gespeichert, so da"s Werzeuge die Konsistenz zwischen
  Datenbankschema und Variablendeklarationen in Anwendungsprogrammen
  "uberpr"ufen k"onnen.

\item [Laufzeiteffizienz:] F"ur komplexe Zugriffe l"a"st sich die
  Schnittstelle zwischen Programmen und Datenbank wesentlich
  effizienter gestalten, als dies bei rein mengenorientierten
  SQL-Schnittstellen m"oglich ist. (z.B. durch Cache-Techniken,
  Compiler-Optimierungen und durch Ausnutzen der Referenzsemantik
  objektorientierter Modelle).
\end{description}

Diesen Vorteilen stehen folgende eher pragmatische \e{Nachteile}
gegen"uber.

\begin{description}
\item [Fehlende Standardisierung:] Gegenw"artig bietet praktisch jeder
  Hersteller objektorientierter Datenbanken eine eigene integrierte
  Datenbanksprache an. Entwickler von Informationssystemen sind jedoch
  daran interessiert, da"s ihre Kunden das System auf Hardware- und
  Softwareplattformen verschiedener Hersteller einsetzen k"onnen.  Die
  fehlende Standardisierung verhindert auch, da"s Drittanbieter in
  gro"sem Umfang Werkzeuge zur Unterst"utzung der
  Anwendungsentwicklung anbieten (vgl. generische SQL
  Datenbankbrowser). Schlie"slich ist der Datenaustausch zwischen
  unabh"angig entwickelten objektorientierten Datenbanksystemen sehr
  schwierig zu realisieren.

\item [Aufwendige Sprachrealisierungstechniken:] Die enge Integration
  von Sprachprozessoren (Parser, Typchecker, Codegenerator,
  Speicherverwaltung) und Datenbanksystemen (Datenw"orterbuch,
  Cache-Manager, Anfrageoptimierer) f"uhrt dazu, da"s Fortschritte bei
  der Sprachprozessortechnologie (z.B. Optimierer, Debugger,
  Bibliotheksfunktionalit"at) nur mit Verz"ogerung Eingang in
  Datenbanksprachprozessoren finden.
\end{description}

Beim Zugriff auf relationale Datenbanksysteme aus Sprachen der dritten
Generation ergibt sich das folgende Problem, f"ur das sich in Anlehnung an den
Begriff des Wellenwiderstands aus der Nachrichtentechnik in der Literatur der
Begriff des \e{impedance mismatch} eingeb"urgert hat (s. Abbildung
\ref{Impedance mismatch}): W"ahrend Sprachen der dritten Generation in der Lage
sind, mit sehr hoher Frequenz Operationen auf individuellen Datens"atzen
durchzuf"uhren, sind relationale Datenbanken darauf optimiert, mit relativ
geringer Frequenz hochkomplexe Operationen auf gro"sen Datenmengen (z.B.
Mehrweg-Verbundoperationen) durchzuf"uhren. Die Inkompatibilit"at dieser beiden
Wellenwiderst"ande an der Datenbank-Programmierschnittstelle f"uhrt insgesamt zu
einer geringen Kommunikationseffizienz (siehe dazu auch Abschnitt
\ref{Statischer Datenbankzugriff aus monomorphen Programmiersprachen})

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/82.eps}
\caption{\e{Impedance mismatch} an der Datenbank-Programmierschnittstelle 
relationaler Datenbanksysteme}
\label{Impedance mismatch}
\end{center}
\end{figure}

\subsection{"Uberblick "uber den ODMG-93 Standard}
\label{Ueberblick ueber den ODMG-93 Standard}

Die im vorangegangenen Abschnitt genannten Nachteile unabh"angig
entwickelter Objektdatenbanksprachen und -modelle wurden von den
Herstellern dieser Datenbanksysteme erkannt und haben zur Entwicklung
eines \e{Object Database Standard} durch die sogenannte Object
Database Management Group (ODMG) gef"uhrt. Der sogenannte ODMG-93
Standard soll langfristig eine "ahnliche Rolle wie SQL f"ur
relationale Datenbanksysteme bei der Entwicklung \e{portabler
  Informationssysteme} einnehmen.

Es lassen sich drei Arten der Portabilit"at unterschieden:

\begin{description}
\item [] \e{Quellkode-Portabilit"at} erlaubt den Austausch des
  Datenbankssystems ohne Modifikation oder erneute Implementierung der
  Applikation.  Der Quellkode der Applikationen mu"s allerdings f"ur
  die Verwendung mit dem neuen Datenbanksystem in der Regel neu
  "ubersetzt werden.

\item [] \e{Bin"arkode-Portabilit"at} stellt die Lauff"ahigkeit eines
  compilierten Anwendungsprogramms auf verschiedenen Systemen sicher,
  ohne da"s ein separater "Ubersetzungsvorgang f"ur die
  unterschiedlichen Systeme notwendig ist. Diese Art der Portabilit"at
  wird z.B.\ durch den ODBC-Standard von Microsoft f"ur relationale
  Systeme sichergestellt.

\item [] \e{Datenportabilit"at} bezieht sich auf die
  Wiederverwendbarkeit von Daten.  Durch eine Applikation erzeugte
  Daten sind auch f"ur Applikationen zugreifbar, die in anderen
  Sprachen realisiert worden sind.
\end{description} 


Ziel des ODMG-Standards ist Quellkode-Portabilit"at.

Zum Zeitpunkt der Erstellung dieses Textes liegt der ODMG-93 Standard
in seiner zweiten Version (Release 1.1) als Buch vor \cite{}. Alle am
Standardisierungsproze"s beteiligten Firmen haben sich verpflichtet,
ODMG-gerechte Schnittstellen f"ur ihre Produkte anzubieten, Der
Standard definiert folgende f"ur den Anwendungsprogrammierer sichtbare
Komponenten eines Objektdatenbanksystems:

\begin{description}
\item [Datenmodell:] Das ODMG-Modell basiert auf dem abstrakten
  \e{Core Component} Objektmodell der \e{Object Management Group}
  (OMG), die ebenfalls ein Zusammenschlu"s von Softwareherstellern,
  wie HP, Sun und anderen, ist [xx] und die vor allem durch die
  Spezifikation der \e{Common Object Request Broker Architecture
    }(CORBA) bekannt ist. Das ODMG-Datenmodell definiert Konzepte wie
  z.B. Objekt, Typ, Attribut, Beziehung, Operation, Schnittstelle,
  Implementierung und Supertyp.

\item [Datendefinitionssprache:] Die \e{Object Definition Language}
  (ODL) definiert eine (C++ "ahnliche) Syntax zur Beschreibung von
  ODMG-Typen, die es erlaubt Namen, Attributen, Operationssignaturen,
  usw.\ f"ur solche Typen festzulegen. ODL ist eine
  aufw"artskompatible Erweiterung der \e{Interface Definition
    Language} (IDL) der OMG. ODL ist programmiersprachenunabh"angig
  und gestattet die Definition aller Strukturen des ODMG-Modells mit
  Ausnahme von Operationsimplementierungen. Damit ODL auch zur
  Schemaintegration und zum Datenaustausch zwischen verschiedenen
  objektorientierten und relationalen Datenmodellen eingesetzt werden
  kann, ist die Syntax von ODL erweiterbar ausgelegt.

\item [Anfragesprache:] Die \e{Object Query Language} (OQL) definiert
  eine (SQL-"ahnliche) konkrete Syntax f"ur eine deklarative
  (nicht-prozedurale) Sprache zur Formulierung von Anfragen auf
  Kollektionen und auf Datenbanken, die zu dem ODMG-Objektmodell
  kompatibel sind. OQL ist nicht algorithmisch vollst"andig, jedoch
  k"onnen OQL Ausdr"ucke Operationen aufrufen, die in prozeduralen
  Sprachen implementiert sind, und die ihrerseits wieder OQL
  Ausdr"ucke enthalten k"onnen.  OQL kann sowohl aus Anwendungskode
  heraus als auch interaktiv von (erfahrenen) Datenbankanwendern
  benutzt werden.

\item [C++ und Smalltalk Sprachanbindung:] Da die ODMG von der in
  Abbildung \ref{Architektur mit objektorientierten Datenbanken}
  skizzierten Integration von Programmiersprache und Datenbanksystem
  ausgeht, werden keine speziellen Notationen oder \glqq eingebettete DML
  Anweisungen\grqq\ f"ur die Manipulationen von persistenten Objekten
  ben"otigt. Die sogenannten C++ und Smalltalk \e{language bindings}
  definieren daher nur die Details der Abbildung des
  ODMG-Objektmodells und der ODMG-Anfragesprache in die bestehende
  Syntax und Semantik der jeweiligen Programmiersprache (C++ bzw.
  Smalltalk).  Die Sprachanbindung wird entweder durch einen
  Pr"aprozessor oder durch einen erweiterten Compiler realisiert. Die
  Sprachanbindung definiert auch die konkreten Namens- und
  Typkonventionen f"ur die ODMG-\e{Standardtyphierarchie}.
\end{description}

Bei der Vortstellung des ODMG-93-Standards in den folgenden
Abschnitten ist zu beachten, da"s sich die Arbeiten zum Zeitpunkt der
Erstellung dieses Buches noch im Flu"s befinden. Viele Konzepte und
Konstrukte, die in der Bschreibung des Standards \cite{} vorgestellt
und beschrieben werden sind noch unterspezifiziert und teilweise auch
widerspr"uchlich.

\comment{ODMG-93 ist noch unterspezifiziert und teilweise 

widerspr"uchlich (Bsp: in, out, inout in Operationssignaturen
 
Persistenzmodell) (s. ODMG 6.9), Sperrprotokolle, parallele

Vererbungshierarchien, 
Persistenzkonzept (Erreichbarkeit, ...). Sprachanbindung. }

\subsection{Vergleich des ODMG-93 und des OMG Objektmodells}
\label{Vergleich des ODMG-93 und des OMG Objektmodells}

Wie bereits im vorangegangenen Abschnitt beschrieben, basiert das
ODMG-Datenmodell auf dem \e{Core Component} Objektmodell der \e{Object
  Management Group} (OMG), das sich wie folgt zusammenfassen l"a"st:

\begin{itemize}
\item Objekte sind Instanzen von Typen und besitzen eine systemweit eindeutige
  Objektidentit"at.

\item Ein Typ definiert das Verhalten und die m"oglichen Zust"ande
  seiner Instanzen.

\item Das Verhalten von Objekten wird durch eine Menge von Operationen
  beschrieben, die auf Objekten eines Typs ausgef"uhrt werden k"onnen.

\item Ein Objekt ist unmittelbare Instanz genau eines Typs.

\item Der Typ eines Objekts wird einmalig bei der Objekterzeugung
  festgelegt.  Objekte k"onnen ihren Typ nicht dynamisch "andern.

\item Typen sind in einer Subtyp/Supertyphierarchie organisiert, wobei
  ein Typ mehrere Supertypen besitzen darf.

\item Subtypbeziehungen werden explizit definiert und werden nicht
  implizit von der Kompatibilit"at zwischen den Signaturen des Super-
  und Subtyps abgeleitet (vgl. strukturelle Subtypisierung \cite{}
  \comment{FM}).

\item Operationen besitzen Signaturen, die den Namen der Operation,
  Typen und Namen der Argumente der Operation und den Ergebnistyp der
  Operation definieren.

\item Operationen werden f"ur einen einzelnen Typ definiert, dies ist
  der Typ des ausgezeichneten ersten Arguments einer Operation.

\item Operationen nehmen Werte oder Objekte als Argumente und liefern
  einen Wert oder ein Objekt als Ergebnis. Die Parameter- und
  Ergebnis"ubergabe besitzt Referenzsemantik.

\item Operationen werden explizit auf ein Objekt angewandt und d"urfen
  Seiteneffekte besitzen.

\item Operationen werden im Implementationsteil einer Typdefinition
  definiert.
\end{itemize}

Das ODMG-Modell erweitert das OMG \e{Core Component} Objektmodell um
folgende datenbankspezifische Konzepte:

\begin{itemize}
\item Objekte k"onnen persistent gespeichert werden.

\item Operationen k"onnen Ausnahmen ausl"osen, die im Typ definiert
  werden.

\item Objekte besitzen Attribute und Beziehungen zus"atzlich zu dem
  gekapselten Objektzustand, der nur durch Operationen zug"anglich
  ist.

\item Das Datenmodell definiert generische, systemweit vorhandene
  Dienste f"ur Anfragen und Transaktionen.
\end{itemize}

Die ODMG folgt damit den Vorstellungen der OMG, die vorsieht, da"s das
Kernmodell f"ur spezielle Anwendungsdom"anen, wie sie z.B. die
Vermittlung in verteilten Netzen und die persistente Datenhaltung
darstellen, aufw"artskompatibel erweitert werden kann.

\subsection{Datendefinition in ODL}
\label{Datendefinition in ODL}

\comment{text}

\subsubsection{"Uberblick "uber die vordefinierte ODMG-Typhierarchie}
\label{Ueberblick ueber die vordefinierte ODMG-Typhierarchie}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/86.eps}
\caption{Die vordefinierte ODMG-93 Typhierarchie (I)}
\label{ODMG-93 Typhierarchie (I)}
\end{center}
\end{figure}


%\comment{Evtl alles in ein Bild, oder getrennt nach Denotable +Characteristic, %Text anpassen}

Der ODMG-Standard legt eine Reihe von vordefinierten Typen fest, die
in einer Typhierarchie angeordnet sind.  In Abbildung \ref{ODMG-93
  Typhierarchie (I)} ist ein Teil dieser Typhierarchie in OMT-Notation
(s. Abschnitt \ref{Ueberblick ueber die vordefinierte
  ODMG-Typhierarchie}) dargestellt. Die Typen sind dabei durch das
Symbol f"ur die Klassen dargestellt, da sie mit diesen eng verwandt
sind\footnote{Der genaue Zusammenhang zwischen Typen und Klassen wird
  im Abschnitt \ref{Klassen als Implementierungen von Typen}
  beschrieben}.  Die Supertypen sind dabei oberhalb ihrer Subtypen
angeordnet, an die sie ihre Eigenschaften und Operationen vererben.
Die vordefinierte Typhierarchie kann um benutzerdefinierte Subtypen
erweitert werden, die ihre Supertypen erweitern und verfeinern
k"onnen.

Die Hierarchie enth"alt zwei spezielle Arten von Typen:
 
\begin{description}
\item[] \e{Abstrakte Typen} definieren nur Eigenschaften, die von
  ihren Subtypen geerbt werden. Da sie keine \comment{vollst"andige?}
  Implementierung besitzen, k"onnen abstrakte Typen selbst nicht
  instantiiert werden.  Sie definieren jedoch Signaturen (Protokolle),
  die f"ur ihre Subtypen gelten.  Abstrakte Typen k"onnen auch
  Operationen definieren (\comment{und implementieren}), die auf
  Instanzen aller ihrer Subtypen anwendbar sind.  \comment{Dies
    unterst"utzt die Erstellung von generischem Kode und die
    Wiederverwenbarkeit von Kode??. Bsp has\_name (Object)(Gibt es
    Implementierungsvererbung ???)} In Abbildung \ref{ODMG-93
    Typhierarchie (I)} und den folgenden Abbildungen werden abstrakte
  Typen durch Schr"agschrift hervorgehoben.

\item[] \e{Parametrisierte Typen} besitzen einen (oder mehrere)
  Typparameter.  Sie sind keine Typen sondern Typgeneratoren. Erst mit
  einem konkreten Typ als Parameter versehen, stellen sie selbst
  konkrete Typen dar. Parametrisierte Typen sind an dem nachgestellten
  in spitzen Klammern eingeschlossenen Typparameter $<$\p{T}$>$ zu
  erkennen. Sie werden unter anderem f"ur generische Kollektionen wie
  z.B.\ \key{Set}$<$\p{T}$>$ verwendet. Diese k"onnen beliebige Subtypen
  von \p{Denotable\_Object} als Parameter erhalten, wodurch
  instantiierbare Kollektionstypen wie \key{Set}$<$\p{Mitarbeiter}$>$
  oder \key{Set}$<$\p{Abteilung}$>$ entstehen.
\end{description}

Die vordefinierte Typhierarchie besitzt zwei separate Wurzelelemente,
die abstrakten Typen \p{Denotable\_Object} und \p{Characteristic}, und
bildet ansonsten eine strikte Baumstruktur.  Allgemein sind jedoch
f"ur die Subtyphierarchien beliebige azyklische Graphen zul"assig, da
ein Typ direkter Subtyp mehrerer anderer Typen sein kann

Anwendungsprogramme k"onnen nur Subtypen von \p{Denotable\_Object}
direkt benennen, w"ahrend die Subtypen von \p{Characteristic} nur die
vordefinierten ODMG-Datenmodellkonstrukte beschreiben. Dies bedeutet,
da"s das ODMG-Modell \e{keine Konzepte h"oherer Ordnung} anbietet, da
weder Operationen noch Typen Sprachobjekte erster Klasse sind. So ist
es zum Beispiel nicht m"oglich, Operationen als Argumente oder
Ergebnisse von Operationen zu verwenden oder Typen dynamisch zur
Laufzeit zu manipulieren. Solche Mechanismen sind bei der Realisierung
\e{generischer} Datenbankwerkzeuge, also von Werkzeugen, die f"ur
verschiedene Datenbankschemata einzusetzen sind, von Bedeutung.

\renewcommand{\epsfsize}[2]{0.4#1}  
\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/ODMGChar.ps}
\caption{Die vordefinierte ODMG-93 Typhierarchie (II)}
\label{ODMG-93 Typhierarchie (II)}
\end{center}
\end{figure}

Der Typ \p{Characteristic} besitzt die Subtypen \p{Property} f"ur
Eigenschaften und \p{Operation} f"ur Operationen (s. Abbildung
\ref{ODMG-93 Typhierarchie (II)}). Die Eigenschaften (\e{properties})
eines Typs umfassen sowohl dessen Attribute als auch dessen
Beziehungen zu anderen Typen, die durch die Subtypen \p{Attribute} und
\p{Relationship} von \p{Property} definiert werden.  Diese Typen
werden beim Zugriff auf Metadaten einer ODMG-Datenbank ben"otigt (s.
Abschnitt \ref{Zugriff auf Metadaten ueber Objekte des Typs Type}).

Neben der Integration der Metadatendefinition in das Objektmodell und
des Metadatenzugriffs in die Anfragesprache OQL hat die Definition des
Typs \p{Charakteristic} und dessen Subtypen als Teil der
vordefinierten Typhierarchie einen weiteren nicht zu untersch"atzenden
Vorteil.  Es wird explizit ein Begriffsapparat eingef"uhrt, der eine
pr"azise und konsistente Beschreibung der Sprachkonstrukte von ODMG
unterst"utzt.  Im folgenden wird unter Verwendung dieses
Begriffsapparats \e{Charakteristik} als gemeinsame Bezeichnung f"ur
die Eigenschaften und Operationen eines Typs benutzt, wenn es nicht
notwendig ist, zwischen den beiden zu unterscheiden.  Mit dem Begriff
\e{Eigenschaften} werden die Attribute und Beziehungen eines Typs
gemeinsam angesprochen.

\subsubsection{Literale und Objekte} 
\label{Literale und Objekte} 

Der Typ \p{Denotable\_Object} besitzt zwei Subtypen, n"amlich
\p{Literal} und \p{Object}. Diese Spezialisierung entspricht der in
Abschnitt \ref{Abstraktionsmechanismen zur Datenstrukturierung}
erl"auterten Unterscheidung zwischen Werten (unver"anderlich) und
Objekten (ver"anderbarer Zustand). Sowohl die Literale als auch die
Objekte werden weiter in strukturierte und atomare Auspr"agungen
unterteilt, woraus sich die Subtypen \p{Atomic\_Literal} und
\p{Structured\_Literal}, \p{Atomic\_Object} und \p{Structured\_Object}
ergeben.

\p{Atomic\_Object} besitzt die Subtypen \p{Type}, \p{Exception} und
\p{Iterator}. Der Typ \p{Exception} wird bei der Definition von
Ausnahmen verwendet, w"ahrend \p{Type} alle Typen der
vordefinierten Typhierachie als Instanzen besitzt und damit den
Zugriff auf Metadaten erm"oglicht (s. Abschitt \ref{Zugriff auf
  Metadaten ueber Objekte des Typs Type}). \p{Iterator} spielt eine
wichtige Rolle bei der Definition von Kollektionen (s.u.).

\p{Atomic\_Literal} ist Supertyp der "ublichen Basistypen \p{Integer},
\p{Float}, \p{Character} und \p{Boolean}.  F"ur die atomaren Literale
gibt es keine \ky{create}-Operation, alle Instanzen dieser Typen
existieren jederzeit implizit. Der Benutzer kann neue Typen f"ur
Literale (Subtypen von \p{Literal}) definieren. Die Operationen auf
den vordefinierten Literalen d"urfen jedoch nicht "uberschrieben
werden.

Sowohl die strukturierten Objekte als auch die strukturierten Literale
sind weiter unterteilt in Kollektionen (\p{Collection} und
\p{Immutable\_Collection}) und Strukturen (\p{Structure} und
\p{Immutable\_Structure}).
 
\subsubsection{Kollektionen und Iteratoren}
\label{Kollektionen und Iteratoren}

Kollektionen k"onnen "uber einem beliebigen instantiierbaren Subtyp des 
Typs \p{Denotable\_Object} definiert werden, also sowohl "uber Literale 
als auch "uber Objekte. Die Typen \p{Collection} und 
\p{Immutable\_Collection} selbst sind abstrakte, parametrisierte Typen,
wobei der Typparameter den Typ der Elemente festlegt.  
Der Typ \p{Collection} unterst"utzt Operationen zum Erzeugen, Kopieren und      
L"oschen einer Kollektion, zum Einf"ugen, "Andern und L"oschen von 
Elementen, zur Elementselektion und zum Test auf Enthaltensein.

Zur Iteration "uber die Elemente einer Kollektion mu"s ein Iterator
erzeugt werden. Iteratoren sind Instanzen des vordefinierten
parametrisierten Typs \p{Iterator}, der den Elementtyp der jeweiligen
Kollektion als Parameter besitzt. Ein Iterator verwaltet eine aktuelle
Position in einer Kollektion, und mit Hilfe von sukzessiven Aufrufen
der auf diesem Typ definierten Funktion \p{next} k"onnen nacheinander
alle Elemente der Kollektion besucht werden. Zu einer Kollektion kann
mehr als ein Iterator definiert werden, soda"s simultan mehrere
Positionen innerhalb einer Kollektion verwaltet werden k"onnen.

Die Funktion \p{next} positioniert den Iterator auf das n"achste Element und
liefert das neue aktuelle Element zur"uck.  Bei geordneten Kollektionen
geschieht die Iteration in der durch die Ordnung der Elemente festgelegte
Reihenfolge, wobei bei der Erzeugung des Iterators zwischen den Richtungen
\p{forward} und \p{backward} gew"ahlt werden kann. F"ur ungeordnete Kollektionen
ist eine beliebige Iterationsreihenfolge m"oglich.

Weiterhin sind auf Iteratoren Operationen zum Zur"ucksetzen des Iterators, zum
Positionieren auf das erste bzw.\ letzte Element, f"ur Statusabfragen sowie zum
L"oschen des Iterators definiert.  F"ur eine C++ Sprachanbindung k"onnte die
Schnittstelle zur Definition des Typs \p{Iterator} etwa wie folgt aussehen:

\begin{xple}
\key{interface} Iterator $<$T$>$ ()
\{\key{attribute} \key{Boolean} stable
  \key{attribute} Enumeration(forward, backward)
  T next()
  T first()
  T last()
  \key{Boolean} more()
  \key{void} reset()
  \key{void} delete() \};
\end{xple}

Das Konzept der Iteratoren ist dem Konzept der Cursor in SQL "ahnlich, besitzt
jedoch den Vorteil das Iteratoren im Gegensatz zu Cursorn Objekte erster Klasse
sind. Dies erlaubt es dem Anwender typisierten, generischen Code zur
Iterationsabstraktion zu schreiben, der unabh"angig von der Art der Kollektion
und dem Elementtyp verwendet werden kann. Man kann z.B. eine Operation
\p{choose} realisieren, die eine Liste der Elemente einer beliebigen Kollektion
am Bildschirm anzeigt und ein vom Benutzer selektiertes Element zur"uckliefert.
Einer solchen Funktion wird ein Iterator f"ur die anzuzeigende Kollektion als
Parameter "ubergeben.

Alle Kollektionstypen sind parametrisierte Typen, soda"s sie Kollektionen mit
beliebigem, aber innerhalb einer Kollektion festen Elementtyp repr"asentieren.
Die vordefinierte Typhierarchie enth"alt vier Typen f"ur Kollektionen mit
ver"anderbarem Zusatand:

\begin{description} 
\item[] \p{Set} ist der Typ ungeordneter Kollektionen, die keine Duplikate
  enthalten (Mengen): Neben den "ublichen Mengenoperationen Durchschnitt,
  Vereinigung und Mengendifferenz definiert der Typ \p{Set} auch Operationen zum
  Kopieren von Mengen und Teilmengentests.

\item[] \p{Bag} ist der Typ ungeordneter Kollektionen, bei denen Duplikate
  erlaubt sind (Multimengen): Auf den Multimengen sind bis auf die
  Teilmengentests dieselben Operationen wie auf den Mengen definiert.

\item[] \p{List} ist der Typ geordneter Kollektionen, bei denen
  Duplikate erlaubt sind (Listen): Dieser Typ stellt Operationen f"ur
  das positionsabh"angige Einf"ugen, L"oschen und Auffinden von
  Elementen zur Verf"ugung. Weiterhin besitzen Objekte dieses Typs
  eine Eigenschaft \p{current\_position}, die den Index der aktuellen
  Position f"ur Lese- und "Anderungsoperationen enth"alt.  Diese
  Position ist unabh"angig von der durch einen Iterator verwalteten
  Position.

\item[] \p{Array} ist der Typ eindimensionaler Felder ver"anderlicher L"ange:
  F"ur diesen Kollektionstyp sind Operationen zum L"oschen, Ersetzen, Einf"ugen
  und Auffinden von Elementen an einer durch einen Index festgelegten Position
  vorgesehen. Die L"ange des Feldes wird bei der Erzeugung initialisiert und
  kann entweder explizit durch eine \ky{resize}-Operation oder implizit durch
  Zuweisung eines Elements an einer Position au"serhalb der bisherigen
  Indexgrenzen ver"andert werden.
\end{description}

Zu jedem dieser Kollektionstypen existiert ein unver"anderliches Gegenst"uck,
das als Subtyp des Typs \p{Literal} deklariert ist (\p{Immutable\_Set}
\p{Immutable\_Bag} \p{Immutable\_List} \p{Immutable\_Array}). Objekte dieser
Typen zeigen dasselbe Verhalten, au"ser da"s sie einen unver"anderlichen Zustand
besitzen.  \p{Immutable\_Collection} besitzt weiterhin den Subtyp
\p{Enumeration}.  Dieser entspricht dem Enumerationstyp, wie er aus vielen
Programmiersprachen bekannt ist. Ein Enumerationstyp f"uhrt eine Reihe von
Bezeichnern ein, die die einzigen Werte dieses Typs repr"asentieren.
 
Sowohl Zeichenketten als auch \e{bit strings} werden im ODMG-Objektmodell als
spezielle Listen betrachtet. Sie sind daher als Subtypen des jeweiligen
Listentyps in der vordefinierten Typhierarchie enthalten (\p{String},
\p{Bit\_String}, \p{Immutable\_String} und \p{Immutable\_Bit\_String}).

\subsubsection{Strukturen}
\label{Strukturen}

Strukturen besitzen im Gegensatz zu Kollektionen, die sich durch eine variable
Anzahl unbenannter Komponenten, den Elementen der Kollektion, auszeichnen, eine
feste Anzahl benannter Komponenten.  F"ur Strukturen sind folgende
parametrisierte Typen vordefiniert:

\begin{xple}
  Structure$<$e$_{1}$: T$_{1}$ e$_{2}$: T$_{2}$ \dots e$_{n}$: T$_{n}$ $>$ 
\end{xple}

und 

\begin{xple}
  Immutable\_Structure$<$e$_{1}$: T$_{1}$ e$_{2}$: T$_{2}$ \dots e$_{n}$: T$_{n}$ $>$
\end{xple}

Sie erhalten eine Reihe von Paaren \p{e}$_{i}$\p{: T}$_{i}$ als Parameter
jeweils bestehend aus einem Komponentennamen \p{e}$_{i}$ und dem zugeh"origen
Typ \p{T}$_{i}$ der Komponente. Zur Beschreibung von Namen kann z.B. der
folgende Typ definiert werden:

\begin{xple}
  Structure$<$Vorname :\key{String} Nachname: \key{String}$>$
\end{xple}

Der Zugriff auf die Komponenten geschieht "uber die Komponentennamen durch die
zu diesem Zweck allgemein "ubliche Punktnotation.

F"ur den Typ \p{Immutable\_Structure} der unver"anderlichen Strukturen
sind die Subtypen \p{Date}, \p{Time}, \p{Timestamp}, und \p{Interval}
vordefiniert, die dieselbe Semantik wie die entsprechenden Typen in
ANSI SQL besitzen (s.  Abschnitt \ref{Basisdatentypen und
  Typkompatibilitaet}).  \comment{Beispiel, verwende Datumstyp aus
  SQL}

\subsubsection{Signaturen f"ur Eigenschaften und Operationen}
\label{Signaturen fuer Eigenschaften und Operationen}

Ein ODMG-Datenbankschema besteht aus einer Menge von benannten Schnittstellen,
wobei jede Schnittstelle \key{interface} einen Objekttyp definiert. Dabei werden
sowohl Charakteristiken f"ur die Instanzen dieses Typ als auch Eigenschaften
f"ur den Typ selbst festgelegt. Die ODMG-Typdefinitionen f"ur das Beispiel
des Firmeninformationssystems sieht wie folgt aus:

\begin{figure}
\hrule \medskip
\begin{xple}
\key{interface} Projekt (\key{extent} projekte   \key{key} (Nr, Titel))
\{ \key{attribute} \key{Unsigned Short} Nr;
   \key{attribute} \key{String} Titel;
   \key{attribute} \key{Long} Budget;
   \key{relationship} \key{Set}$<$Mitarbeiter$>$ Beteiligte
     \key{inverse} Mitarbeiter :: Projekte;
   \key{relationship} \key{List}$<$Abteilung$>$  Betreuungen
     \key{inverse} Abteilung :: Projekte \}; 

\key{interface} Mitarbeiter (\key{extent} mitarbeiter   \key{key} PID)
\{ \key{attribute} Strucure$<$Vorname :\key{String} Nachname :\key{String}$>$ Name
   \key{attribute} \key{Unsigned Short} PID  
   \key{relationship} Abteilung  Arbeitgeber
     \key{inverse} Abteilung :: Angestellte
   \key{relationship} \key{List}$<$Projekt$>$ Projekte
     \key{inverse} Projekt :: Beteiligte \}

\key{interface} Festangestellte: Mitarbeiter (\key{extent} festangestellte)
\{ \key{attribute} Gehalt;
   \key{attribute} Einstellungsdatum \}

\key{interface} Werkstudent: Mitarbeiter (\key{extent} werkstudenten)
\{ \key{attribute} (xxx Datum) Beginn 
   \key{attribute} \key{Unsigned Short} Dauer 
   \key{attribute} (Preis) Verguetung \}

\key{interface} Abteilung (\key{extent} abteilungen \key{keys} Name, Kurz)
\{ \key{attribute} \key{String} Kurz;
   \key{attribute} \key{String} Name;
   \key{relationship} \key{List}$<$Projekt$>$  Projekte
     \key{inverse} Projekt :: Betreuung;
   \key{relationship} Leiter Chef
      \key{inverse} Leiter :: Bereich;
   \key{relationship} \key{Set}$<$ Mitarbeiter $>$ Angestellte
      \key{inverse} Mitarbeiter :: Arbeitgeber;
   \key{relationship} \key{List}$<$Abteilung$>$ Unterabteilungen
      \key{inverse} Abteilung :: Oberabteilung
     \{\key{order\_by} Name\}
   \key{relationship} Abteilung Oberabteilung
      \key{inverse} Abteilung :: Unterabteilungen;
   \key{Boolean} neuesProjekt \key{in} (Projekt) \key{raises} () xxx \};

\key{interface} Leiter: Festangestellte (\key{extent} leiter)
\{ \key{relationship} Abteilung Bereich
      \key{inverse} Abteilung :: Chef \}

\end{xple}
\hrule
\end{figure}

Im einzelnen werden in der Schnittstelle Signaturen f"ur die folgenden
Charakteristiken spezifiziert: 

\begin{description}
\item [Attribute:] Es werden Namen und Typen f"ur die Attribute der Instanzen
  des Typs spezifiziert. Die Spezifikation jedes Attributs wird durch das
  Schl"usselwort \key{attribute} gekennzeichnet. Im Beispiel sind dies die
  Attribute \p{Name} und \p{PID}.

  Als Werte f"ur ein Attribut sind Literale und beliebige Strukturen zul"assig,
  die als Komponenten nur Literale enthalten.

  F"ur jedes Attribut sind die Operationen \p{get\_value} (zum Zugriff auf den
  Attributwert) und \p{set\_value} (zum Modifizieren des Attributwerts) mit den
  folgenden Signaturen vordefiniert:

\begin{xple}
get\_value() $\rightarrow$ exsting\_value :Literal
set\_value(new\_value :Literal)
\end{xple}
Diese Operationen k"onnen vom Benutzer "uberschrieben werden.  

Die Attribute sind als abstrakte Komponenten des Zustands zu verstehen. Sie
brauchen nicht notwendigerweise auch als Komponente der Repr"asentation
(Implementierung) zu existieren. Es kann sich vielmehr auch um abgeleitete
Attribute handeln, deren Wert bei Bedarf durch eine geeignete
\ky{get\_value}-Routine aus anderen Werten berechnet wird. So kann z.B. f"ur
einen Typ \p{Person} ein Attribut \p{Alter} existieren, dessen Wert jedoch
jeweils aus dem Attribut \p{Geburtsdatum} und dem aktuellen Datum bestimmt wird.

Dieser Zusammenhang spielt auch eine wichtige Rolle f"ur die vom
relationalen Datenmodell bekannten Update-Problematik f"ur Sichten
(\e{view updates}).  View-Updates sind bei relationalen Systemen Sache
des Datenbanksystems.  Wegen inh"arenter Mehrdeutigkeiten sind solche
Updates nicht in allen F"allen m"oglich.

Im ODMG-Objektmodell ist die korrekte Propagierung von Updates auf
abgeleiteten Attributen (Sichten) Sache des Programmierers der
Typimplementierungen. Er mu"s bei der Realisierung der zugeh"origen
\ky{set\_value}-Methoden entscheiden, welche Konsequenzen die
Ver"anderung eines abgeleiteten Attributs durch den Benutzer hat.
Allgemein sollten zusammengeh"orige Paare von
\ky{set\_value/get\_value}-Methoden die Invariante
(\p{(get\_value(set\_value(x)) = x} erf"ullen.

\item [Beziehungen:] Eingeleitet durch das Schl"usselwort \key{relationship}
  wird der Typ der referenzierten Objekte, ein Bezeichner zum Traversieren der
  Beziehung und gegebenenfalls auch die inverse Beziehung angegeben. Beziehungen
  im ODMG-Datenmodell werden in Abschnitt \ref{Beziehungen zwischen Typen}
  genauer beschrieben.

\item [Operationen:] Die Signatur f"ur eine Operation umfa"st den Name der
  Operation, Namen und Typen der Parameter, den Typ des R"uckgabewertes sowie
  eine Liste der Ausnahmen, die zur Laufzeit von der Operation ausgel"ost werden
  k"onnen. Jede Operation ist genau einem Typ zugeordnet und besitzt ein Objekt
  dieses Typs als impliziten, ausgezeichneten ersten Parameter.  \comment{ToDo:}
  Beispiel zur Erl"auterung des ersten Parameters, Es kann bei der
  Implementierung durch Mechanismen der Zielsprache darauf zugegriffen werden
  (z.b. durch \p{self})s.Abschnitt Implementierung

  Als weitere Argumente f"ur eine Operation sind beliebige Objekte und Literale
  m"oglich, die Instanzen eines Subtyps von \p{Denotable\_Object} sind. Eine
  Operation besitzt stets einen R"uckgabewert (ist also eine Funktion).
  Operationen, die nur Seiteneffekte haben, liefern den Wert \key{nil} zur"uck.

  Im Beispiel werden die Operationen ... auf den Objekten des Typs ...
  spezifiziert.
\end{description}

Typen k"onnen selbst auch als Objekte betrachtet werden (s. Abschnitt
\ref{Zugriff auf Metadaten ueber Objekte des Typs Type}). Ein solches
Objekt vom Typ \p{Type} besitzt einige Eigenschaften, denen bei der
Schnittstellendefinition Werte zugeordnet werden k"onnen:

\begin{description}
\item [Supertypen:] Ein Objekttyp kann als Subtyp einer oder mehrerer anderer
  Objekttypen definiert werden. Dazu werden bei seiner Definition in der
  Schnittstelle diese Typen als Supertypen angegeben (s. Abschnitt
  \ref{Subtypdefinitionen}).

\item [Extension:] Zu einem Typ kann optional die Menge all seiner Instanzen,
  die sog. \e{Extension}, verwaltet werden.  Sie wird nur angelegt, wenn in der
  Schnittstelle eine \ky{extent}-Klausel angegeben wird, mit der gleichzeitig
  auch ein Name f"ur die Extension festgelegt wird.  Beim Erzeugen neuer
  Instanzen des Typs und beim L"oschen von Instanzen wird die Extension
  automatisch aktualisiert.

  F"ur einen Objekttyp \p{A} ist die Extension des Typs vom Typ \key{Set}$<$
  \p{A} $>$.

\comment{Parallelen zu SQL }

\item [Schl"ussel:] Zur Identifikation von Instanzen eines Typs in ihrer
  Klassenextension kann f"ur diesen Typ in der Schnittstelle durch die
  \ky{key}-Klausel ein Schl"ussel festgelegt werden. Dabei sind sowohl einfache
  als auch zusammengesetzte Schl"ussel m"oglich. Ein einfacher Schl"ussel
  besteht aus einer Eigenschaft des Typs, deren Wert jede Instanz des Typs
  eindeutig identifiziert. F"ur Mitarbeiter ist dies die Personalnummer
  \p{PID}.Dabei ist zu beachten, da"s nicht nur Attribute, sondern auch
  Beziehungen als Schl"ussel und Schl"usselbestandteile zul"assig sind.

  Ein zusammengesetzter Schl"ussel besteht aus einer Kombination
  mehrerer Eigenschaften, die zusammen eindeutig f"ur jede Instanz
  sind.  Zusammengesetzte Schl"ussel werden in Klammern
  eingeschlossen. Im Firmeninfomationssytem besitzt der Typ
  \p{Projekt} einen zusammengesetzten Schl"ussel:

\begin{xple}
\key{interface} Projekt(\key{extent} projekte  \key{key} (Nr, Titel))
\{ \dots \}; 
\end{xple}

Zu einem Objekttyp kann es auch mehrere alternative Schl"ussel geben.  In diesem
Fall wird eine Liste von mehreren Schl"usseln bei der Schnittstellendefinition
angegeben. Abteilungen k"onnen z.B. sowohl "uber ihren Namen als auch "uber das
K"urzel \p{Kurz} identifiziert werden:

\begin{xple}
\key{interface} Abteilung (\key{extent} abteilungen  \key{keys} Name, Kurz)
\{ \dots \}
\end{xple} 

Wichtig ist es hierbei, die unterschiedliche Rolle der Schl"ussel im
ODMG-Objektmodell und in SQL zu sehen. Im ODMG-Modell dienen die
Schl"ussel allein der Objektselektion und der Modellierung in der
Realit"at existierender Integrit"atsbedingungen (z.B.\glqq Jeder
Mitarbeiter hat eine eindeutige Personalnummer\grqq ). In SQL werden
Schl"ussel zus"atzlich f"ur die Modellierung von Beziehungen ben"otigt
(s. Abschnitt \ref{Assoziationen im relationalen Modell}).
\end{description}

\subsubsection{Subtypdefinitionen}
\label{Subtypdefinitionen}

Das ODMG-Objektmodell unterst"utzt strikte Ererbung von Attributen, Beziehungen
und Operationen. Ein Subtyp erbt alle Eigenschaften (Attribute und Relationen)
und Operationen von seinen Supertypen. Er kann au"serdem die ererbten
Charakteristiken verfeinern und durch die Definition weiterer Attribute,
Beziehungen und Operationen erweitern.

Da die Subtyphierarchien nicht auf Baumstrukturen beschr"ankt sind, kann ein Typ
mehr als einen direkten Supertyp besitzen. In Erweiterung des
Firmeninformationssystems kann man sich einen weiteren Supertyp \p{Student} f"ur
\p{Werkstudent} vorstellen, wodurch sich die in Abbildung
\ref{Mehrfachvererbung} gezeigte Struktur ergibt.

\begin{figure}
\begin{center}
Werkstudent als Subtyp von Mitarbeiter und Student
\end{center}
\caption{Ein Beispiel f"ur Mehrfachvererbung}
\label{Mehrfachvererbung}
\end{figure}

In diesem Fall findet Mehrfachererbung (\e{multiple inheritance}) statt: Ein Typ
erbt die Charakteristiken aller seiner direkten Supertypen.  Dabei kann es zu
Namenskonflikten kommen, wenn mehrere Supertypen eine Charakteristik des
gleichen Namens besitzen. Solche Namenskonflikte m"ussen im Subtyp durch
explizites Umbenennen einer der ererbten Charakteristiken aufgel"ost werden.

Die Supertypen eines Typs werden bei der Typdefinition in der Schnittstelle
festgelegt. Im erweiterten Beispiel besitzt der Typ \p{Werkstudent} die
Supertypen \p{Mitarbeiter} und \p{Student}.

\begin{xple}
\key{interface} Werkstudent: Mitarbeiter, Student
 (\key{extent} werkstudenten)
\{ \key{attribute} (xxDatum) Beginn    
\key{attribute} \key{Unsigned Short} Dauer 
   \key{attribute} (xxPreis) Verguetung \}
\end{xple}

Eine Instanz eines Subtyps kann als Instanz jeder seiner Supertypen betrachtet
werden. Sie verf"ugt "uber das Verhalten und die Zust"ande, die von einer
Instanz der Supertypen erwartet wird. Zus"atzlich besitzt sie spezialisierte
Zustandsinformation und/oder Verhaltensmuster, die sie als Instanz der
Spezialisierung auszeichnen.

Jedes Element eines Subtyps ist auch in den Extensionen all seiner Supertypen
enthalten. Wenn f"ur einen Typ \p{A} und seinen Subtyp \p{B} Extensionen
verwaltet werden, ist also die Extension des Typs \p{B} eine Teilmenge der
Extension des Typs \p{A}.

In manchen F"allen erfordert es die Modellierung, da"s die Extensionen der
direkten Subtypen eines Typs paarweise disjunkt sein sollen, d.h.\ kein Element
des Supertyps geh"ort zu mehr als einem seiner direkten Subtypen\footnote{In OMT
  wird dies durch ein leeres Dreieck ausgedr"uckt gegen"uber einem gef"ullten
  Dreieck f"ur "uberlappende Subklassen}.  Eine solche Disjunktheit kann mit den
Sprachmitteln des ODMG-Objektmodells nicht erzwungen werden.

Implementierungsvererbung wird durch den ODMG-93-Standard nicht spezifiziert.
\comment{nachlesen}

\subsubsection{Beziehungen zwischen Typen}
\label{Beziehungen zwischen Typen}

Beziehungen zwischen Objekten spielen in der Datenmodellierung eine zentrale
Rolle. Im ODMG-Standard werden Beziehungen zwischen Objekten nicht durch ein
eigenes "ubergeordnetes Konstrukt auf der Typebene ausgedr"uckt, sondern
"ahnlich wie Attribute als Teil der Strukturdefinition eines Typs definiert. Zur
Unterscheidung von den rein wertbasierten Attributen werden
Beziehungsdefinitionen durch das Schl"usselwort \key{relationship} eingeleitet.
Im ODMG-Objektmodell k"onnen nur bin"are, keine n-"aren Beziehungen definiert
werden. Beziehungen sind nur zwischen Objekten des Typs \p{Denotable\_Object}
und damit auch all seiner Subtypen m"oglich.

Analog zu ein- und mehrwertigen Attributen kann auch bei der Definition einer
Beziehung ein einzelnes Objekt oder eine Kollektion von Objekten angegeben
werden. Damit lassen sich 1:1-, 1:n- und n:m-Beziehungen darstellen. Es handelt
sich dabei in allen F"allen um optionale Beziehungen. Um darzustellen, da"s bei
einer 1:1-Beziehung einem Objekt kein Objekt zugeordnet wird, verwendet man den
ausgezeichneten Wert \key{nil} anstelle des assoziierten Objekts. Bei 1:n- und
n:m-Beziehungen verwendet man bei nicht an der Beziehung beteiligten Objekten
die leere Kollektion.  anstelle der Spezifikation der assoziierten Objekte.
Nicht-optionale Beziehungen wie z.B. jedes Objekt aus \p{A} ist mit \e{genau}
einem Objekt aus \p{B} assoziiert k"onnen mit den Mitteln des ODMG-Objektmodells
nicht erzwungen werden (vgl. dazu die Angabe \key{not null} bei SQL, Abschnitt
\ref{Nullwerte und Wahrheitswerte}).
 
Zur Definition einer 1:1-Beziehungen zwischen zwei Objekttypen \p{A} und \p{B}
wird in der Signatur des Typs \p{A} eingeleitet durch das Schl"usselwort
\key{relationship} der Objekttyp \p{B} als zweiter an der Beziehung beteiligter
Typ angegeben.  Als Beispiel wird die Beziehung zwischen den Abteilungen und
ihren Leitern betrachtet.

\begin{xple}
\key{interface} Abteilung (\dots)
\{ \dots
   \key{relationship} Leiter Chef
      \key{inverse} Leiter :: Bereich;
   \dots  \};

\key{interface} Leiter: Festangestellte (\dots)
\{ \dots
   \key{relationship} Abteilung Bereich
      \key{inverse} Abteilung :: Chef 
   \dots \}
\end{xple}

Beziehungen haben keinen Objektidenifikation und keinen Namen.  Es
wird jedoch bei der Definition der Beziehung ein Bezeichner
eingef"uhrt (\e{traversal path}), mit dessen Hilfe ein Traversieren
der Beziehung m"oglich ist. Im Beispiel ist dies der Bezeichner
\p{Chef} f"ur das Traversieren der Beziehung von \p{Abteilungen} zum
zugeh"origen \p{Leiter} und der Bezeichner \p{Bereich} f"ur die
umgekehrte Richtung der Beziehung.
 
Durch Angabe der \ky{inverse}-Klauseln werden die beiden Richtungen
der Beziehung miteinander in Verbindung gebracht.  Wenn zu einer
Beziehung die inverse Richtung nicht angeben wird, kann die Beziehung
nur in der definierten Richtung traversiert werden.  Dies kann vom
System als Hinweis angesehen werden, da"s die Unterst"utzung zum
Traversieren in entgegengesetzter Richtung eingespart werden kann.

Die referentielle Integrit"at wird durch Beziehungen gewahrt: Das
System l"ost eine Ausnahme aus, falls ein zuvor gel"oschtes Objekt
"uber eine Beziehung dereferenziert wird.  Aus Anwendersicht ist diese
L"osung nicht optimal. F"ur ihn ist es konsequenter und komfortabler,
wenn noch bestehende Referenzen bereits beim L"oschen des Objekts vom
System erkannt und geeignet behandelt werden. Ein Beispiel f"ur einen
solchen Ansatz ist das Kaskadieren von L"oschoperationen in SQL (s.
Abschnitt \ref{Domaenen und referentielle Integritaet}).  Solche
Ans"atze sind jedoch aufwendiger in der Realisierung, besonders f"ur
objektorientierte Sprachen mit ihrer extensiven Verwendung von
Objektreferenzen. Kaskadierendes L"oschen kann au"serdem auch zu
schwer "uberschaubaren (und auch unerwarteten) Konsequenzen einer
einzelnen L"oschoperation f"uhren.

Zur Definition einer 1:n-Beziehung zwischen zwei Typen \p{A} und \p{B} kann zu
jedem Objekt aus \p{A} eine Kollektion von Objekten aus \p{B} angegeben werden
(vgl. mehrwertige Attribute). Als Beispiel wird hier die Beziehung zwischen
Mitarbeitern und Abteilungen betrachtet: Jeder Mitarbeiter geh"ort zu einer
Abteilung und jede Abteilung hat beliebig viele Mitarbeiter(\key{Set}$<$
\p{Mitarbeiter} $>$).

\begin{xple}
\key{interface} Abteilung (\dots)
\{ \dots
   \key{relationship} \key{Set}$<$Mitarbeiter$>$ Angestellte
     \key{inverse} Mitarbeiter :: Arbeitgeber;
   \dots \};

\key{interface} Mitarbeiter(\dots)
\{ \dots  
   \key{relationship} Abteilung  Arbeitgeber
     \key{inverse} Abteilung :: Angestellte
   \dots\};
\end{xple}

Neben \key{Set} sind auch andere Kollektionstypen m"oglich.  Dies wird im
folgenden Beispiel der Definition einer n:m-Beziehung zwischen Projekten und
Mitarbeitern illustriert. Bei der n:m-Beziehung wird f"ur beide Richtungen der
Beziehung eine Kollektion angegeben.

\begin{xple}
\key{interface} Projekt (\dots)
\{ \dots
   \key{relationship} \key{Set}$<$Mitarbeiter$>$ Beteiligte
     \key{inverse} Mitarbeiter :: Projekte;
   \dots\}; 

\key{interface} Mitarbeiter (\dots)
\{ \dots
   \key{relationship} \key{List}$<$Projekt$>$ Projekte
     \key{inverse} Projekt :: Beteiligte
\}
\end{xple}

Die an einer Beziehung beteiligten Typen m"ussen nicht unterschiedlich sein, wie
an den rekursiven Beziehungen \p{Oberabteilug} und \p{Unterabteilungen} zur
Modellierung der Abteilungshierarchie zu sehen ist:

\begin{xple}
\key{interface} Abteilung (\dots)
   \key{relationship} \key{List}$<$Abteilung$>$ Unterabteilungen
      \key{inverse} Abteilung :: Oberabteilung;
      \{ \key{order\_by} Name \}
   \key{relationship} Abteilung Oberabteilung
      \key{inverse} Abteilung :: Unterabteilungen;
   \dots
  \};
\end{xple}

F"ur geordnete Kollektionen kann eine Ordnung auf den Objekten angegeben werden.
Die Definition einer Ordnung geschieht durch eine \ky{order\_by}-Klausel. In
obigem Beispiel werden die Unterabteilungen nach ihrem Namen sortiert.

Auf den Beziehungen sind eine Reihe von Operationen definiert, die sich in 
vier Gruppen einteilen lassen:

\begin{description}
\item [Erzeugung:] Mit diesen Operationen k"onnen Beziehungen zwischen konkreten
  Objekten erzeugt werden. F"ur eine 1:1-Beziehungen k"onnen zwei konkreten
  Objekten assoziiert werden und f"ur eine 1:n-Beziehung ein Objekt mit einer
  Menge von Objekten.

\item [Erweiterung:] Durch diese Operationen k"onnen 1:n- und n:m-Beziehungen
  erweitert werden. Mit einem konkreten Objekt kann ein weiteres Objekt und oder
  eine Menge weiterer Objekte assoziiert werden.  1:1-Beziehungen k"onnen f"ur
  ein konkretes Objekt nicht erweitert werden.
 
\item [L"oschen:] Die Operationen dieser Gruppe erlauben es, die f"ur ein
  konkretes Objekt bestehenden Beziehungen selektiv oder insgesamt zu l"oschen.
  F"ur n:m-Beziehungen k"onnen alle Assoziationen an denen ein bestimmtes Objekt
  beteiligt ist, gel"oscht werden. Die L"oschoperationen beziehen sich stets auf
  eine ausgezeichnete Beziehung, nicht auf alle Beziehungen an denen der
  Objekttyp beteiligt ist.

\item [Traversieren:] Diese Gruppe enth"alt Funktionen, mit denen von einem
  Objekt aus auf die mit ihm assoziierten Objekte zugegriffen werden kann
  (Traversieren der Beziehung). Gem"a"s der Definition der Beziehungsarten
  liefern die Operationen zum Traversieren bei einer 1:1-Beziehung ein einzelnes
  Objekt, w"ahrend sich bei einer 1:n-Beziehung eine Kollektion von Objekten
  ergibt.  Da sich durch die Art der Definition im ODMG-Standard eine
  n:m-Beziehung aus zwei 1:n-Beziehungen zusammensetzt, kann die f"ur
  1:n-Beziehungen vorgesehene Funktion zum Traversieren der einzelnen Richtungen
  einer n:m-Beziehung verwendet werden.
\end{description}

Die konkrete Syntax der einzelnen Operationen h"angt von der gew"ahlten
Sprachanbindung ab. 

\subsubsection{Klassen als Implementierungen von Typen}
\label{Klassen als Implementierungen von Typen}

Wie in Abschnitt \ref{Signaturen fuer Eigenschaften und Operationen}
beschrieben, werden Objekttypen durch Schnittstellen definiert. Die
Implementierung der Typen, die textuell von der Schnittstelle getrennt ist,
erfolgt in ODMG-konformen Sprachen (\comment{Beispiel}).  Zu einer Schnittstelle
kann es dabei mehrere Implementierungen geben.  \comment{Vorteile??} Eine
Schnittstelle zusammen mit einer Implementierung dieser Schnittstelle
entspricht dem Konzept der \e{Klasse}, wie es in Smalltalk oder C++ vorhanden
ist.

Das Problem der Auswahl einer der vorhandenen Implementierungen spielt
nur bei der Erzeugung von Objekten eine Rolle, sie kann nicht
dynamisch ge"andert werden.  Wenn man die Objektidentit"at einmal
besitzt, findet eine automatische Auswahl der \glqq passenden\grqq\
Implementierung durch das System statt. Dies erm"oglicht
multi-linguale Systeme, da in einer Applikation vorkommende Objekte in
verschiedenen Sprachen geschriebene Implementierungen besitzen
k"onnen.

Die Implementierung darf mehr Operationen enthalten als die Schnittstelle
(private Attribute und Operationen).
 
\comment{
Operationsimplementierung kann immer 
auf aktuelles Objekt zugreifen (self, this, ...). Methodenaufruf. 
Ausnahmebehandlung nicht weiter diskutiert. }

\subsubsection{Sp"ate Bindung}
\label{Spaete Bindung}

Namen von Operationen m"ussen nur innerhalb einer Schnittstellendefinition
eindeutig sein. Es k"onnen also in unterschiedlichen Typdefinitionen
Operationen mit dem gleichen Namen definiert werden. Man spricht dann von
\e{"uberladenen} Operationen (\e{operation overloading}).

Beim Aufruf einer Operation mit einem "uberladenen Namen tritt das Problem der
Auswahl der zugeh"origen Operation auf.  Dieser Auswahlvorgang wird als
Namensaufl"osung oder \e{operation dispatching} bezeichnet.  Bei der Auswahl der
Operation richtet sich das System nach dem Typ des ausgezeichneten ersten
Parameters der Operation.  Jede Operation eines Typs kann auch auf die Objekte
all seiner Subtypen angewandt werden. Es kann deshalb mehrere Operationen des
gleichen Namens geben, die aufgrund der Subtyphierarchie auf ein Objekt
anwendbar sind.  Grunds"atzlich wird beim \e{operation dispatching} die
Operation ausgew"ahlt, die f"ur den spezifischsten Typ des Objekts definiert
ist.  \renewcommand{\epsfsize}[2]{0.7#1}

\begin{figure}[hbt]
\begin{center}
\leavevmode
%\epsffile{Bilder/PostScript/xx.ps} Bild in Vorlage
\caption{\e{Operation dispatching}}
\label{Operation dispatching}
\end{center}
\end{figure}

Abbildung \ref{Operation dispatching} zeigt zur Illustration einen
Teil der Typhierarchie des Firmeninformationssystems. Es wird
angenommen, da"s sowohl der Typ \p{Mitarbeiter} als auch der Typ
\p{Festangestellter} eine Operation \p{Jahresgehalt} definiert. Auf
ein Objekt vom Typ \p{Festangestellter} k"onnen beide Operationen
ausgew"ahlt werden, beim \e{operation dispatching} wird die Operation
des Typs \p{Festangestellter} ausgew"ahlt (spezifischster Typ).  Es
werden zwei Arten des \e{operation dispatching} unterschieden:

\begin{itemize}
\item Beim \e{static dispatching} stellt der Compiler zum "Ubersetzungszeitpunkt
  den Typ des Objekts \p{m} fest und w"ahlt in Abh"angigkeit davon die Operation
  aus. Diese Art des \e{dispatchings} ist z.B. in Ada realisiert.

\item Beim \e{dynamic dispatching} verz"ogert der Compiler die Auswahl bis zur
  Laufzeit. Die Auswahl h"angt vom dynamischen Typ des an die Variable \p{m}
  gebundenen Objekts ab. Diese Art des \e{operation dispatching} ist in den
  meisten objektorientierten Sprachen wie z.B.\ in Eiffel und in C++ realisiert.
\end{itemize}

Der Unterschied zwischen den beiden Arten des \e{operation dispatchings} l"a"st
sich am besten an einem Beispiel illustrieren.  Man betrachtet dazu das folgende
Beispiel einer OQL-Anfrage\footnote{Die Syntax von OQL ist der von SQL sehr
  "ahnlich. Sie wird in Abschnitt \ref{Anfragen in OQL} beschrieben}, die das
durchschnittliche Jahresgehalt berechnet:

\begin{xple}
\key{avg}(\key{select} m.Jahresgehalt()
      \key{from} mitarbeiter m)
\end{xple}

Die Anfrage f"uhrt eine Variable \p{m} vom Typ \p{Mitarbeiter} ein, die an die
Extension dieses Typs gebunden ist. F"ur diese Variable.  wird die Operation
\p{Jahresgehalt} aufgerufen. Wenn die Anfrage f"ur ein Objekt vom Typ
\p{Festangestellter} ausgewertet wird w"ahlt der Compiler bei \e{static
  dispatching} zur "Ubersetzungszeit die Operation \p{Jahresgehalt} des Typs
\p{Mitarbeiter} aus. Bei \e{dynamic dispatching} hingegen wird zur Laufzeit
festgestellt, da"s das betrachtete Objekt vom Typ \p{Festangestellter} ist, und
es wird die Operation \p{Jahresgehalt} dieses Typs gew"ahlt.

Der ODMG-Standard geht von der Realisierung der zweiten Art des \e{operation
  dispatchings} aus.
 
Sp"ate Bindung erh"oht die Wartbarkeit und Erweiterbarkeit von Softwaresystemen.
Es k"onnen auch noch nach der Realisierung von Applikationen neue Subklassen
eingef"uhrt werden. Die bisherigen Prozeduren k"onnen unver"andert
weiterverwendet werden, tragen aber der erweiterten Subklassenhierarchie
Rechnung, indem sie gegebenenfalls den Code der neuen Subklasse verwenden. Es
kann also in einer Prozedur auf Implementierungen von Subklassen zugegrifffen
werden, die zum Zeitpunkt der Erstellung der Prozedur noch gar nicht geplant
waren. Meyer \cite{Eiffel88} spricht in diesem Zusammenhang von geschlossenen
und offenen Systemen: Eine Klassenhierarchie ist geschlossen, da man schon mit
ihr arbeiten kann; sie ist aber zugleich auch offen f"ur sp"atere Erweiterungen.
  
Im Bereich der Datenbanksysteme f"uhrt die sp"ate Bindung wegen der dynamischen
Zuordnung der Implementierungen zu einer Erschwerung der Anfrageoptimierung
(vgl. dazu \cite{} \comment{Paper zur Optimierung von OO-Anfragen}).

\subsubsection{Sichtbarkeits- und Lebensdauerregeln}
\label{Sichtbarkeits- und Lebensdauerregeln}

Jedes Objekt einer ODMG-Datenbank besitzt eine innerhalb dieser Datenbank
g"ultige und eindeutige, unver"anderliche Objektidentit"at, die ihm bei seiner
Erzeugung zugeordnet wird. Der Gleichheitstest auf Objekten basiert demgem"a"s
nicht auf der Gleichheit der Objektzust"ande sondern auf der Indentit"at der
Objekte. Die Operation \p{x.same\_as?(y)}, die f"ur ein Objekt \p{x} aufgerufen
werden kann, vergleicht die Objektidentit"aten der Objekte \p{x} und \p{y}.

Bei der Erzeugung eines Objekts wird eine Objektidentit"at zur"uckgeliefert.
Wenn keine Bindung an einen Bezeichner stattfindet, erlaubt diese jedoch keinen
Zugriff auf das Objekt. Objekte sind deshalb zun"achst anonym und erfordern zu
ihrer weiteren Verwendung eine Bindung an einen Bezeichner (Benennung).  Zum
Zugriff auf Objekte innerhalb einer Sitzung k"onnen Objekte an Programmvariablen
gebunden werden, die jedoch nur bis zum Ende der Sitzung g"ultig sind. Eine
Identifizierung von Objekten unabh"angig von Sitzungen ist "uber eine Benennung
der Objekte auf der Ebene der Schemadefinition m"oglich. Zusammen mit den Namen
der Extensionen bilden diese Objektnamen Eintrittspunkte in die Datenbank
(\e{roots of persistence}).

Im ODMG-Objektmodell k"onnen Objekte auf der Schemaebene benannt werden, wobei
mehrere Namen f"ur daselbe Objekt zul"assig sind. Jeder Name darf jedoch
innerhalb seines Sichtbarkeitsbereichs nur einmal vergeben werden.  Es kann zur
Laufzeit festgestellt werden, ob ein Objekt benannt ist und gegebenenfalls auch,
welches der bzw.\ die Namen sind. Zu diesem Zweck gibt es die vordefinierten
Eigenschaften \p{has\_name?} und \p{names} des Typs \p{Object}, die an alle
Subtypen von \p{Object} vererbt werden. F"ur ein benanntes Objekt gilt
\p{has\_name? =} \key{true} und das Attribut \p{names} besitzt die Menge der
Namen des Objekts als Wert.

Es gibt also im ODMG-Objektmodell verschiedene sitzungsunabh"angige
Zugriffsm"oglichkeiten auf ein Objekt:

\begin{itemize}
\item "Uber die benannte Extension des zugeh"origen Typs kann das Objekt durch
  eine (wertbasierte) Selektion z.B. "uber die Konstrukte der Anfragesprache OQL
  (s. Abschnitt \ref{Anfragen in OQL}) angesprochen werden; vgl. OQL,...??

\item "Uber die ihm zugeordneten Namen, kann das Objekt direkt angesprochen
  werden.

\item "Uber einen Pfad ausgehend von einem benannten Objekt kann ein Objekt
  evtl.\ indirekt angesprochen werden.
\end{itemize}

\renewcommand{\epsfsize}[2]{0.7#1}

\begin{figure}[hbt]
\begin{center}
\leavevmode
%\epsffile{Bilder/PostScript/??.ps}
\caption{Optionen f"ur den Zugriff auf Objekte}
\label{Objektzugriff}
\end{center}
\end{figure}

\comment{Bild siehe Block, anpassen an Text} 

Abbildung \ref{Objektzugriff} illustriert die verschiedenen Optionen f"ur den
Zugriff auf Objekte. Objekt \p{A} kann innerhalb der Sitzung 1 "uber die
Variable \p{x} und innerhalb der Sitzung 2 "uber die Variable \p{y} sowie
sitzungsunabh"angig "uber seinen Namen \p{nameA} und als Mitglied der Extension
seines Typs \p{Typ1} angesprochen werden. Objekt \p{B} kann indirekt "uber das
benannte Objekt \p{A} und damit auch indirekt "uber die Variablen \p{x} und
\p{y} und auch als Mitglied der Extension seines Typs \p{Typ2} angesprochen
werden.

Der Sichtbarkeitsbereich von Schnittstellennamen und \e{benannten
  Wurzelobjekten} ist die gesamte Datenbank.
Schnittstellendefinitionen und Typimplementierungen bilden lokale
Sichtbarkeitsbereiche. Die Namen von Attributen und Operationen
brauchen nur innerhalb dieser Bereiche eindeutig zu sein.  Im
Abschnitt \ref{Subtypdefinitionen} werden die Sichtbarkeitsregeln f"ur
ererbte Attribute beschrieben.

Implementierungen werden relativ zu ihren Schnittstellen benannt. Die Namen von
Implementierungen brauchen daher nur in diesem Sichtbarkeitsbereich eindeutig zu
sein.

Die Lebensdauer eines Objekts ist orthogonal zu seinem Typ (\e{orthotogonal
  persistence}). Sie beginnt mit seiner (dynamischen) Erzeugung. Im Gegensatz zu
den "ubrigen Operationen ben"otigt man zur Objekterzeugung eine Operation, die
nicht f"ur eine Instanz des Typs (ein Objekt), sondern f"ur den Typ selbst
aufgerufen wird, da die zu erzeugende Instanz noch nicht existiert. Die
Operation \p{create\_instance} ist deshalb f"ur den Typ \p{Type} vordefiniert,
der alle "ubrigen Objekttypen als \e{Instanzen} enth"alt (s.Abschnitt
\ref{Zugriff auf Metadaten ueber Objekte des Typs Type}). Damit kann diese
Operation f"ur all diese Typen aufgerufen werden. Sie besitzt die folgende
Signatur:

\begin{xple}
create\_instance(e$_{1}$ = v$_{1}$, e$_{2}$ = v$_{2}$, \dots e$_{n}$ = v$_{n}$): Denotable\_Object
\end{xple}

Bei der Objekterzeugung k"onnen f"ur alle oder einige der Objektattribute Werte
festgelegt werden. Dazu werden Paare aus Attributnamen e$_{i}$ und Attributwert
v$_{i}$ als Parameter an die \ky{create\_instance}-Operation "ubergeben. Nicht
explizit initialisierte Attributwerte erhalten den Wert \key{nil}. Als Ergebnis
liefert die Operation die Objektidentit"at des neu erzeugten Objekts. Nach
seiner Erzeugung kann der Typ eines Objekts jederzeit ermittelt werden. Diesem
Zweck dient die f"ur den Typ \p{Object} vordefinierte Eigenschaft \p{type}, die
einen Verweis auf den zugeh"origen Objekttyp (ein Objekt vom Typ \p{Type})
enth"alt.

Die Lebensdauer eines Objekts wird bei der Erzeugung des Objekts festgelegt und
kann danach nicht mehr ge"andert werden. Das ODMG-Objektmodell bietet daf"ur
folgende drei Optionen:

\begin{description}
\item [] \p{conterminus\_with\_procedure}: Die Lebensdauer des Objekts ist
  beschr"ankt auf die Prozedur, in der es erzeugt wurde. Es wird bei der
  R"uckkehr aus der Prozedur automatisch gel"oscht.

\item [] \p{conterminus\_with\_process}: Die Lebensdauer des Objekts ist
  beschr"ankt auf den Proze"s, innerhalb dessen es erzeugt wurde.  Es wird am
  Ende der jeweiligen Sitzung automatisch gel"oscht.

\item [] \p{conterminus\_with\_database}: Die Lebensdauer des Objekts ist
  beschr"ankt auf die Lebensdauer der Datenbank, zu der es geh"ort. Um die
  Lebensdauer des Objekts zu beenden, mu"s es explizit gel"oscht werden. Zum
  expliziten L"oschen eines Objekts definiert der Typ \p{Object} die generische
  Operation \key{delete}, die an alle Subtypen von \p{Object} vererbt werden.
  Diese Operation entfernt das zu l"oschende Objekt aus der Datenbank und
  markiert es in allen Beziehungen, an denen es beteiligt ist, als ung"ultig
  (siehe auch Abschnitt \ref{Beziehungen zwischen Typen}). Der Versuch, auf ein
  explizit gel"oschtes Objekt "uber einen Namen oder einen Pfad zuzugreifen,
  f"uhrt zu einer Ausnahme.
\end{description}

Es ist zul"assig, da"s sich ein Objekt auf ein anderes mit einer k"urzeren
Lebensdauer bezieht, allerdings nur bis zum Ende von dessen Lebensdauer.

\subsubsection{Zugriff auf Metadaten "uber Objekte des Typs \glqq Type\grqq }
\label{Zugriff auf Metadaten ueber Objekte des Typs Type}

Typen sind selbst durch Objekte repr"asentiert und k"onnen deshalb
auch Instanzen eines Typs sein. Alle Typen der vordefinierten
Typhierarchie (s.  Abschnitt \ref{Ueberblick ueber die vordefinierte
  ODMG-Typhierarchie}) sind Instanzen des Typs \p{Type}, der Subtyp
des Typs \p{Atomic\_Object} ist.  Insbesondere ist der Typ \p{Type}
selbst auch durch ein Objekt des Typs \p{Type} und damit auch des Typs
\p{Atomic\_Object} repr"asentiert.  Daraus ergeben sich die folgenden
Konsequenzen:

\begin{itemize}
\item Jeder Typ der Typhierarchie und jeder benutzerdefinierte Typ, der in diese
  Hierarchie eingef"ugt wird, besitzt die Eigenschaften, die durch \p{Type}
  definiert werden (siehe Tabelle).

\item Als Instanz des Typs \p{Atomic\_Object} besitzt \p{Type} die
  Eigenschaften, die durch den Typ \p{Atomic\_Object} definiert sind.

\item Da \p{Type} auch Subtyp von \p{Atomic\_Object} ist, erben alle Instanzen
  von \p{Type}, d.h.\ alle Typen der Typhierarchie und die benutzerdefinierten
  Typen (s.o.) die Eigenschaften von \p{Atomic\_Object}.
\end{itemize}  

Die Eigenschaften des Typs \p{Type} sind in der folgenden Tabelle 
zusammengefa"st.   

\begin{center}
\begin{tabular}{|p{120pt}| p{120pt} | p{120pt}|}
\hline
\bf{Name der Eigenschaft} & \bf{Typ der Eigenschaft} & \bf{Erkl"arung} \\
 \hline
\hline
has\_operations & \key{Set}$<$ Operation $>$ & Menge der Operationen \\
\hline
has\_properties & \key{Set}$<$ Property $>$ & Menge der Eigenschaften\\
\hline
has\_subtypes   & \key{Set}$<$ Type $>$ & Menge der Subtypen \\
\hline
has\_supertypes & \key{Set}$<$ Type $>$ & Menge der Supertypen\\
\hline
name & \key{String} & Name des Typs \\
\hline
extent & \key{Set}$<$ Atomic\_Object $>$ & Extension des Typs\\
\hline
name\_of\_extent & \key{String} & Name der Extension \\
\hline
\end{tabular}
\end{center}

Weiterhin definiert \p{Type} die Operationen \p{create\_instance} (s. Abschnitt
\ref{Sichtbarkeits- und Lebensdauerregeln}) und \p{create\_extent}, die die
implizit verwaltete Extension initialisiert.

"Ahnlich wie in relationalen Systemen, bei denen die Metadaten in Tabellen
abgelegt sind, k"onnen auch im hier beschriebenen Ansatz Metadaten "uber die ODL
beschrieben und mit der Sprache OQL abgefragt werden.

%\comment{erl"autern , evtl. Hinweis auf reflektive Programmierung}

\subsection{Anfragen in OQL}
\label{Anfragen in OQL}

OQL ist eine deklarative Anfragesprache mit einer abstrakten und einer
konkreten, SQL-"ahnlichen Syntax, die im folgenden betrachtet wird. Im Gegensatz
zur Sprache SQL, bei der Anfragen im wesentlichen aus \ky{select from
  where}-Konstrukten bestehen m"ussen, bietet OQL ein weites Spektrum von
Ausdr"ucken an, die als Anfragen zugelassen sind.

OQL wurde als eine Obermenge von SQL entworfen.  Jede korrekte
\ky{select from where}-Anweisung in SQL ist ebenso g"ultig in OQL.
Die Erweiterungen von OQL betreffen komplexe Objekte,
Objektidentit"at, Pfadausdr"ucke, Polymorphismus, Funktionsaufrufe und
sp"ate Bindung.

OQL unterst"utzt sowohl Werte (unver"anderlich) als auch Objekte
(ver"anderlich).  Weiterhin ist es weniger auf eine bestimmte Art von
Kollektionen wie etwa die Relationen in SQL (=Multimengen) fokussiert. Neben
Anfragen auf Mengen und Mulimengen sind auch Anfragen auf geordnete Kollektionen
wie Listen und Felder m"oglich.

Eine OQL-Anfrage besteht aus einem Ausdruck, der zur Berechnung des
Anfrageergebnisses ausgewertet wird. Neben einfachen Ausdr"ucken wie Bezeichnern
von Werten oder Objekten und Komponentenselektionen spielen dabei Funktionen
eine wichtige Rolle. Dabei bestimmt der f"ur die Funktionsparameter berechnete
R"uckgabewert das Ergebnis der Anfrage.  Zu diesem Zweck ist eine Reihe von
Funktionen in OQL vordefiniert, von denen sich viele in Infix-Notation anwenden
lassen.

Das Spektrum der zul"assigen OQL-Anfrageausdr"ucke l"a"st sich in f"unf 
Gruppen aufteilen: 

\begin{itemize}
\item Elementare Anfragen (Abschnitt \ref{Elementare Anfragen})

\item Konstruktoren f"ur Objekte und Werte (Abschnitt \ref{Konstruktoren fuer
    Objekte und Werte})

\item Funktionale Anfragen (Abschnitt \ref{Funktionale Anfragen})

\item Quantifizierte Mengenanfragen (Abschnitt\ref{Quantifizierte
    Mengenanfragen})

\item Anfragen auf geordnete Kollektionen (Abschnitt\ref{Anfragen auf geordnete
    Kollektionen})
\end{itemize}

Nach einer Behandlung der Aspekte Sprachorthogonalit"at und Benennung von
Anfragen in den Abschnitten \ref{Sprachorthogonalitaet} und \ref{Benannte
  Anfragen} werden diese f"unf Gruppen von Ausdr"ucken beschrieben.


\subsubsection{Sprachorthogonalit"at}
\label{Sprachorthogonalitaet}

Ein deutlicher Vorteil von OQL gegen"uber von SQL ist die erh"ohte
Sprachorthogonalit"at. Im Gegensatz zu den Einschr"ankungen in SQL
(vgl.  Abschnitt \ref{Vergleich der Modelle}) k"onnen die Konstrukte
der Anfragesprache bei OQL beliebig miteinander kombiniert werden.
Vgl. mit SQL. Regul"are Semantik. Einzelner Name ist bereits eine
Anfrage. (Zwischen-)ergebnisse beliebiger Typen.

Der Vorteil der hohen Sprachorthogonalit"at l"a"st sich gut am \ky{select from
  where}-Konstrukt illustrieren, das im wesentlichen mit dem entsprechenden
SQL-Konstrukt "ubereinstimmt.  Die mehrmalige Verwendung dieses Konstrukts
innerhalb einer Anfrage f"uhrt zu geschachtelten Anfragen. In OQL ist ein
geschachteltes \ky{select from where}-Konstrukt in folgenden Teilen der Anfrage
m"oglich:

\begin{description}
\item [select-Klausel:] Ein Beipiel daf"ur ist die Anfrage

  \glqq Angestellte der Abteilung PC-Software, die am Projekt
  DB-Fahrpl"ane mitarbeiten.\grqq

\begin{xple}
\key{select select} ang
       \key{from} abt.Angetellte  ang
       \key{where} dbFahrplaeneProjekt \key{in} ang.Projekte
\key{from} abteilungen  abt  
\key{where} abt.Kurz = 'PC SW';
\end{xple}

Das "au"sere \ky{select from where}-Konstrukt liefert hier die Abteilung
PC-Software und damit deren Angestellte (\p{abt.Angestellte}).  Das innere
Konstrukt selektiert aus dieser Menge von Angestellten die f"ur das
Anfrageergebnis relevanten.

\item [from-Klausel:] Ein Beipiel daf"ur ist die Anfrage

  \glqq Die Leiter aller Oberabteilungen, die weniger als DM 10.000
  verdienen.\grqq

\begin{xple}
select oAbt.Chef
\key{from} \key{select} abt
         \key{from} abteilungen abt
         \key{where} \key{not} a.Unterabteilungen.empty?  oAbt  
\key{where} oAbt.Chef.Gehalt $<$ 10000
\end{xple}

Das innere \ky{select from where}-Konstrukt selektiert hier die Menge der
Oberabteilungen (=Abteilungen mit mindestens einer Unterabteilung).

\item[\ky{where}-Klausel:] Ein Beipiel daf"ur ist die Anfrage

  \glqq Abteilungen mit mehr als zehn Mitarbeitern, die am Projekt
  DB-Fahrpl"ane arbeiten.\grqq

\begin{xple}
\key{select} abt
\key{from} abteilungen abt
\key{where} 10 $<$ count(\key{select} ang
                     \key{from} abt.Angetellte  ang
                     \key{where} dbFahrplaeneProjekt \key{in} ang.Projekte)
\end{xple}

Das innere \ky{select from where}-Konstrukt selektiert nacheinander f"ur jede
Abteilung die Menge der Angestellten, die an dem gew"uschten Projekt arbeiten.
\end{description}

Hohe Flexibilit"at zeigt die Anfragesprache OQL auch bei der Behandlung von
Objekten und Werten. Anfragen k"onnen existierende Objekte, atomare Literale,
strukturierte Werte und Kollektionen der selbigen zur"uckliefern, aber auch
selbst neue Objekte erzeugen und Objekte und Werte zu beliebig strukturierten
Konstrukten kombinieren.

OQL selbst ist nicht algorithmisch vollst"andig (\e{computationally
  incomplete}), aber es ist m"oglich, in einer Anfrage Methoden
aufzurufen und umgekehrt auch Anfragen in Methoden zu verwenden.
Dadurch ergibt sich eine hohe Ausdrucksm"achtigkeit.  \comment{Siehe
  dazu neuer Text !!}

Wie SQL ist auch OQL eine deklarative Anfragesprache. Dies erleichtert die
Formulierung von Anfragen und er"offnet gute Optionen f"ur die Optimierung.

\subsubsection{Benannte Anfragen}
\label{Benannte Anfragen}

OQL unterst"utzt ein Konstrukt f"ur die Benennung von Anfragen.  F"ur eine
Anfrage kann durch das \ky{define as}-Konstrukt ein Bezeichner eingef"uhrt
werden.  Die folgende Definition bindet den Bezeichner \p{Oberabteilungen} an
die Anfrage, die die Menge der Abteilungen mit mindestens einer Unterabteilung
bestimmt.

\begin{xple} 
\key{define} Oberabteilungen \key{as} 
  \key{select} abt
  \key{from} abteilungen abt
  \key{where} \key{not} abt.Unterabteilungen.empty? 
\end{xple}

Das \ky{select from where}-Konstrukt wird in Abschnitt \ref{Quantifizierte
  Mengenanfragen} erl"autert.

Ein auf diese Weise gebundener Bezeichner kann unter anderem in anderen
Anfrageausdr"ucken innerhalb des Sichtbarkeitsbereichs des Namens anstelle des
Anfrageausdrucks benutzt werden.  So kann z.B.\ obige Anfrage unter Verwendung
des Bezeichners wie folgt vereinfacht werden:

\begin{xple}
\key{select} oAbt.Chef
\key{from} Oberabteilungen oAbt
\key{where} oAbt.Chef.Gehalt $<$ 10000
\end{xple}

OQL unterst"utzt keine rekursiven Anfragen. Da Anfragen jedoch Methodenaufrufe
und umgekehrt Metoden auch Anfragen enthalten k"onnen, kann eine Anfrage eine
Operation enthalten, die die Anfrage rekursiv aufruft (indirekte Rekursion).

\subsubsection{Elementare Anfragen}
\label{Elementare Anfragen}

Literale und Bezeichner von Objekten und Typen sind bereits zul"assige Anfragen
in OQL.  Als Eintrittspunkte f"ur die Anfragesprachen dienen die Bezeichner der
Wurzelobjekte. Dazu geh"oren die Namen der Extensionen der im Datenbankschema
definierten Objekttypen und benannte Objekte (vgl. Abschnitt \ref{Sichtbarkeits-
  und Lebensdauerregeln}).  Die Extensionen spielen dabei dieselbe Rolle wie
die Relationen in SQL.

F"ur die Anwendung einer Operation (Methode) \p{f} auf eine Objekt \p{o}
gibt es zwei verschiedene Notationen in OQL: 

\begin{xple}
o $\rightarrow$ f
o.f
\end{xple}

Weiterhin gibt es die M"oglichkeit ein Objekt \p{x} explizit zu typisieren.
Dazu wird dem Objekt der Bezeichner \p{T} seines Typs eingeklammert
vorangestellt.

\begin{xple}
(T) x
\end{xple}

Die Korrektheit der Typangabe wird vom System getestet. Falls die
Typangabe nicht korrekt ist, wird zur Laufzeit eine Ausnahme erzeugt.
Dabei ist zu beachten, da"s auch jeder Supertyp des Typs, f"ur den das
Objekt erzeugt worden ist eine korrekte Typangabe ist (s Abschnitt
\ref{Subtypdefinitionen}).  Die explizite Typangabe er"offnet
au"serdem die M"oglichkeit, da"s ein Objekt auf eine Eigenschaft einer
seiner Supertypen zugreift (die in dem eigenen Objektyp "uberschrieben
wurde??), indem nicht der Objekttyp sondern der Bezeichner des
entsprechenden Supertyps angegeben wird.

\begin{xple}
xx
\end{xple}

Wenn die explizite Typisierung zu diesem Zweck verwendet wird, stellt sie eine
Art Typkonvertierung (\e{Typ-Cast}) dar.

\subsubsection{Konstruktoren f"ur Objekte und Werte}
\label{Konstruktoren fuer Objekte und Werte}

Entsprechend der klaren Unterscheidung zwischen Werten und Objekten im
ODMG-Standard (s.\ Abschnitt \ref{Literale und Objekte}) gibt es auch
verschiedene Konstrukte f"ur deren Erzeugung.  Zur Erzeugung eines
neuen Objekts wird der Name seines Typs als Konstruktor verwendet. Als
Parameter erh"alt der Konstruktor Initialierungswerte f"ur Attribute
des Objekts. Dabei wird f"ur jedes Attribut auch der Name angegeben,
d.h.\ es werden Paare Attributname/Attributwert als Parameter
"ubergeben. Attribute, die nicht explizit initialisiert werden,
erhalten den Standardwert \key{nil}. Mit dem folgenden Ausdruck wird
ein neues Objekt vom Typ \p{Abteilung} erzeugt.

\begin{xple}
Abteilung(Kurz: 'LTSW', Name: 'Leitung Software')
\end{xple}

(siehe Seiteneffekte S. 70 ODMG-Standard)  
\comment{Mengenwertige Objekte??}

Die Erzeugung von strukturierten Werten hingegen wird durch das Schl"u"sselwort
\key{struct} eingeleitet. Die Werte der Eigenschaften werden wiederum wie bei
den Objekten durch Paare aus Namen und Werten angegeben.

\begin{xple}
\key{struct}(p1: e1, p2: e2, ... pn: en)
\end{xple}

Es ist insbesondere zu beachten, da"s die beiden Ausdr"ucke

\begin{xple}
Person(Name: 'Peter', Alter: 20)
\key{struct}(Name: 'Peter', Alter: 20)   
\end{xple}

eine ganz unterschiedliche Bedeutung besitzen. Der erste Ausdruck erzeugt ein
Objekt vom Typ \p{Person} mit den ver"anderlichen Eigenschaften \p{Name} und
\p{Alter}. Der zweite Asdruck erzeugt einen strukturierten Wert mit den
unver"anderlichen Komponenten \p{Name} und \p{Alter}.  Insbesondere liegt den
beiden Konstrukten ein unterschiedlicher Gleichheitsbegriff zugrunde. Die
Ergebnisse einer zweimaligen Auswertung des ersten Ausdrucks besitzen
unterschiedliche Objektidentit"aten und werden deshalb als ungleich betrachtet.
Es handelt sich um zwei Objekte, die zuf"allig die gleichen Werte besitzen. Beim
zweiten Ausdruck ergeben sich jedoch bei zweimaliger Auswertung identische,
nicht-unterscheidbare strukturierte Werte.

Die Konstruktion einer Kollektion erfolgt durch einen entsprechenden Konstruktor
(\key{set}, \key{bag}, \key{list}, \key{array}) gefolgt von der Enumeration der
Ausdr"ucke, die die Elemente der Kollektion bilden.

Die folgende Tabelle fa"st die Konstruktoren in abstrakter Form zusammen.  Dabei
sind die \p{e$_{i}$} Ausdr"ucke, die \p{p$_{i}$} Namen von Eigenschaften und
\p{t} der Name eines Typs.

\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\bf{Konstruktor} & \bf{Parameter} & \bf{zur Erzeugung \dots} \\
\hline
\hline
\p{t}     & \p{p$_{1}$: e$_{1}$, p$_{2}$:  e$_{2}$, \dots p$_{n}$: 
e$_{n}$} 
                                                       &  eines  Objektes vom Typ \p{t}\\    
\hline
\key{struct}& \p{p$_{1}$: e$_{1}$, p$_{2}$: e$_{2}$, \dots p$_{n}$: e$_{n}$} 
                                                          &  eines strukurierten Wertes \\
\hline
\key{set}   &  \p{e$_{1}$, e$_{2}$, \dots e$_{n}$} & einer Menge \\
\hline
\key{bag}   &  \p{e$_{1}$, e$_{2}$, \dots e$_{n}$} & einer Multimenge \\
\hline
\key{list}  &  \p{e$_{1}$, e$_{2}$, \dots e$_{n}$} &  einer Liste \\
\hline
\key{array} &  \p{e$_{1}$, e$_{2}$, \dots e$_{n}$}  & eines Feldes 
\\
\hline
\end{tabular}
\end{center}

\subsubsection{Funktionale Anfragen}
\label{Funktionale Anfragen}

Zur Formulierung von funktionalen Anfragen stehen in OQL eine Reihe von
Operatoren (Funktionen) zur Verf"ugung. Neben den "ublichen un"aren (z.B.
\key{not}, \p{-}) und bin"aren Boolschen (\key{and}\footnote{\p{A} \key{and}
  \p{B} wird von links nach rechts ausgewertet.Dies spielt wegen der m"oglichen
  Dereferenzierung von \key{nil} eine Rolle.}, \key{or}) und arithmetischen
Operatoren (\p{-}, \p{+}, etc.)  und Vergleichsoperatoren (\p{+}, $<$ , etc. )
enth"alt OQL die un"aren Operatoren \key{min}, \key{max}, \key{count},
\key{sum}and \key{avg}, die auf Kollektionen angewandt werden k"onnen. Sie sind
vergleichbar mit den Aggregatfunktionen bei SQL (vgl. Abschnitt
\ref{Aggregatfunktionen}). So kann man z.B. mit der Anfrage

\begin{xple}
  \key{count}(abteilungen)
\end{xple}

die Anzahl aller Abteilungen ermitteln. 

Ein weiterer bin"arer Infixoperator von OQL ist \key{in}. Dieser Operator
"uberpr"uft, ob der als erster Parameter "ubergebene Ausdruck in der Kollektion,
die als zweiter Parameter angegeben wird, enthalten ist. Ein solcher Elementtest
kann auf beliebige Kollektionsarten angewandt werden.  F"ur zwei konkrete
Abteilungen \p{a1} und \p{a2} kann man so z.B. testen, ob \p{a2} eine
Unterabteilung von \p{a1} ist:

\begin{xple}
  a2 \key{in} a1.Unterabteilungen 
\end{xple}

Dar"uberhinaus bietet OQL Operatoren an, mit denen sich Ausdr"ucke 
umformen (konvertieren) lassen: 

\begin{itemize}
\item H"aufig liefern Anfragen einelementige Kollektionen als Ergebnis.  Mit dem
  Operator \key{element} l"a"st sich das (einzige) Element zur
  Weiterverarbeitung aus einer solchen Kollektion extrahieren.  Wenn die
  Kollektion mehr als einElement enth"alt wird eine Ausnahme erzeugt.  Dieser
  Operator ist insbesondere deshalb von Bedeutung, da das f"ur die
  Anfragesprache wichtige \ky{select from where}-Konstrukt stets Kollektionen
  (Mulimengen oder Mengen) als Ergebnis liefert.  Das Beipiel zeigt einen
  wichtigen Spezialfall, bei dem ein Element "uber den Schl"ussel (eindeutig!)
  aus einer Extension, in diesem Fall der Menge der Mitarbeiter selektiert wird:

\begin{xple}
\key{element}(\key{select} m  
            \key{from} mitarbeiter m
            \key{where} m.PID = 22)
\end{xple}

Das Ergebnis der \ky{select from where}-Anfrage ist vom Typ
\key{Bag}$<$Mitarbeiter$>$, das Ergebnis der Gesamtanfrage ist vom Typ
\p{Mitarbeiter}.

\item Der Operator \key{listtoset} formt eine Liste in eine Menge um, d.h.  es
  wird eine Duplikatelimination durchgef"uhrt und das Ergebnis ist eine
  ungeordnete Kollektion (Beispiel s.u.).

\item Der Operator \key{flatten} vermindert die Schachtelungstiefe von
  ineinander geschachtelten Kollektionen. Er macht aus einer Kollektion von
  Kollektionen von Ausdr"ucken von Typ \p{T} eine Kollektion von Ausdr"ucken vom
  Typ \p{T}, indem er alle Ausdr"ucke in einer Kollektion vereinigt. Es kann
  sich dabei in den verschiedenen Schachtelungstiefen um verschiedene
  Kollektionsarten handeln. Die Art der Ergebniskollektion h"angt von den
  beteiligten Kollektionsarten ab.

\begin{xple}
\key{flatten}(\key{select} a.Angestellte
            \key{from} a \key{in} Abteilungen
            \key{where} ProjektDBFahrplaene \key{in} a.Projekte)
\end{xple}

Die \ky{select from where}-Anfrage liefert die Menge der Mengen von
Angestellten, deren Abteilungen am Projekt \p{ProjektDBFahrplaene} beteiligt
ist. Der Operator \key{flatten} macht daraus die Menge aller Angestellten, deren
Abteilungen am Projekt \p{ProjektDBFahrplaene} beteiligt ist.
\end{itemize}

Die bin"aren Mengenoperatoren \key{union} (Vereinigung), \key{intersect}
(Durchschnitt) und \key{except} (Differenz) sind anwendbar auf ungeordnete
Kollektionen mit und ohne Duplikate, also auf Objekte vom Typ \p{Set} und vom
Typ \p{Bag}. Alle drei Operatoren werden in Infixnotation verwendet und erwarten
zwei Kollektionen als Operatoren. Unter Verwendung der oben definierten
\p{Oberabteilungen} und einer entsprechend definierten Menge von
\p{Unterabteilungen} kann man mit dem Infixoperator \key{intersect} z.B. die
Menge aller Abteilungen, die sowohl Ober- als auch Unterabteilung sind,
berechnen:

\begin{xple}
Oberabteilungen  \key{intersect} Unterabteilungen, 
\end{xple}

F"ur geordnete Kollektionen wie Listen und Felder gibt es den Infixoperator
\p{+}, der zwei Kollektionen der gleichen Art konkateniert.  Damit l"a"st sich
die Menge der Projekte an denen Abteilung \p{a1} oder \p{a2} arbeitet,
bestimmen:

\begin{xple}
  \key{listtoset}(a1.Projekte + a2.Projekte)
\end{xple}

Hierbei wird der oben erw"ahnte Operator \key{listtoset} eingestzt, um Duplikate
zu eliminieren, die evtl. aufgrund der Beteiligung beider Abteilungen an
gleichen Projekten auftreten.

Alternativ kann diese Menge auch unter Verwendung des Operators \key{union}
zur Mengenvereinigung berechnet werden:

\begin{xple}
  listtoset(a1.Projekte) \key{union} listtoset(a2.Projekte)
\end{xple}

\subsubsection{Quantifizierte Mengenanfragen}
\label{Quantifizierte Mengenanfragen}

Die quantifizierten Mengenanfragen sind den funktionalen Anfragen, die im
vorigen Abschnitt vorgestellt werden, sehr "ahnlich. Sie f"uhren jedoch
zus"atzlich eine Bereichsvariable mit lokalem Sichtbartkeitsbereich ein.

Eine Bereichsvariable \p{x} kann in OQL universell und existentiell 
quantifiziert werden. Dazu stehen die folgenden Konstrukte zur Verf"ugung:

\begin{xple}
\key{for all} x \key{in}  e$_{1}$: e$_{2}$
\key{exists} x \key{in}  e$_{1}$: e$_{2}$
\end{xple}

Das \ky{for all}-Konstrukt (universelle Quantifizierung) liefert den
Wahrheitswert \key{true}, wenn das Pr"adikat \p{e}$_{2}$ f"ur alle Elemente, die
in der durch den Ausdruck e$_{1}$ beschriebenen Ausdruck enthalten sind,
erf"ullt ist. Bei der existentiellen Quantifizierung (\key{exists}) gen"ugt es,
wenn das Pr"adikat \p{e}$_{2}$ f"ur eines der durch \p{e}$_{1}$ beschriebenen
Elemente erf"ullt ist. Man beachte, da"s die Syntax und Semantik des
\ky{exists}-Konstrukts von der des gleichnamigen SQL-Konstrukts abweicht: Das
SQL-Konstrukt realisiert einen Test auf leere Menge und keine existentielle
Quantifizierung und wird syntaktisch wie eine Aggregatfunktion auf eine Menge
angewandt.

Neben der universellen und der existentiellen Quantifizierung ist das
\key{select from where} - Konstrukt von zentraler Bedeutung. Dieses entspricht
im wesentlichen dem gleichnamigen SQL-Konstrukt, zeichnet sich jedoch durch
h"ohere Orthogonalit"at (s. Abschnitt \ref{Sprachorthogonalitaet}) und die
Inkorporation objektorientierter Aspekte aus. Das \ky{select from
  where}-Konstrukt ist in OQL von der Form

\begin{xple}
\key{select} e
\key{from}   e$_{1}$ x$_{1}$, e$_{2}$ x$_{2}$, \dots, e$_{n}$ x$_{n}$ 
\key{where} e'
\end{xple}

Dabei wird f"ur jeden der an der Anfrage beteiligten Kollektionen, die
durch die Ausdr"ucke \p{e}$_{i}$ beschrieben werden eine
Bereichsvariable \p{x}$_{i}$ eingef"uhrt. Jede der Bereichsvariablen
x$_{i}$ ist an die Kollektion gebunden, die durch den zugeh"origen
Ausdruck e$_{i}$ beschrieben wird.  Wie bei SQL umfa"st der
Sichtbarkeitbereich dieser Variablen die gesamte Anfrage (vgl.
Abschnitt \ref{Sichtbarkeitsregeln und Spaltennamenkonflikte}). Sie
k"onnen also in den Ausdr"ucken \p{e} und \p{e}' auftreten. Eine
Besonderheit des objektorientierten Ansatzes ist die Verwendung einer
Bereichsvariablen \p{x}$_{i}$ in einem nachfolgenden Ausdruck
\p{e}$_{j}$ (\p{j}$>$\p{i}). Dies erm"oglicht Anfragen auf
mengenwertige Attribute und Beziehungen eines Objekts. Als Beispiel
wird noch einmal die Anfrage \glqq Angestellte der Abteilung PC-Software,
die am Projekt DB-Fahrpl"ane mitarbeiten\grqq\ aus Abschnitt
\ref{Sprachorthogonalitaet} betrachtet. Sie kann auch wie folgt
formuliert werden:

\begin{xple}
\key{select} ang
\key{where} abt.Kurz = 'PC SW' \key{and} dbFahrplaeneProjekt \key{in} ang.Projekte
\end{xple}

Weiterhin sind in OQL wie an allen anderen Stellen auch f"ur \p{e} beliebige
OQL-Ausdr"ucke m"oglich. Dies er"offnet M"oglichkeiten , die weit "uber die bei
SQL unterst"utzte Selektion und Umbenennung von Spalten hinausgeht. Es k"onnen
unter anderem beliebig strukturierte Werte konstruiert werden und sogar neue
Objekte erzeugt werden. Diese hohe Sprachm"achtigkeit ist eine klare Konsequnez
der Orthogonalit"at der Sprache.

\comment{Beispiel}

Das Ergebnis einer solchen Anfrage ist eine Multimenge, d.h.\ es kann Duplikate
enthalten. Zur Vermeidung von Duplikaten kann das Konstrukt \key{select distinct
  from where} benutzt werden. Es wird dann eine Duplikatelimination
durchgef"uhrt, und das Anfrageergebnis ist eine Menge.

Wenn die Ausdr"ucke e$_{1}$, e$_{2}$, \dots, e$_{n}$ unterschiedliche
Kollektionstypen und insbesondere auch geordnete Kollektionen liefern, werden
zur Bestimmung des Anfrageergebnisses gewisse Konvertierungen zwischen den
Kollektionsarten durchgef"uhrt, auf die hier aber nicht weiter eingegangen wird.

In SQL und in OQL kann man f"ur den Ausdruck \p{e} in der
\ky{select}-Klausel einen Stern angegeben. In SQL erh"alt man dann
die Spalten aller in der \ky{from}-Klausel in der Ergebnistabelle.
(vgl.\ Abschnitt \ref{Monorelationale Select From Where-Anfragen}). In
OQL werden f"ur das Ergebnis Strukturen konstruiert mit den Namen ...
der Bereichsvariablen als Komponentennamen und den Elementtypen der
durch die Ausdr"ucke \p{e}$_{i}$ als Komponententypen.  Die Elemente
des Ergebnisses sind dann also vom Typ:

\begin{xple}
\key{Structure}$<$ x$_{1}$: Elementtyp(e$_{1}$),  x$_{2}$: Elementtyp(e$_{2}$), \dots,  x$_{n}$: Elementtyp(e$_{n}$)$>$
\end{xple}

Wie in SQL gibt es auch in OQL optionale Erweiterungen des \ky{select from
  where}-Konstrukts.  Zur Sortierung des Anfrageergebnisses k"onnen mit Hilfe
der \ky{order by}-Klausel Sortierkriterien angegeben werden.  In der Klausel
k"onnen die in der Anfrage eingef"uhrten Bereichsvariablen referenziert werden.
Die Sortierklausel ist von der Form

\begin{xple}
\key{order by}  e$_{1}$, e$_{2}$, \dots, e$_{n}$
\end{xple}

Dabei geben die \p{e}$_{i}$ die Sortierkriterien an, wobei f"ur jedes
Sortierkriterium optional festgelegt werden kann, ob in aufsteigender oder
absteigender Reihenfolge sortiert werden soll.  Der Operator kann auch zur
Sortierung von ungeordneten Kollektionen wie Mengen und Multimengen benutzt
werden, das Ergebnis ist auf jeden Fall eine Liste. Der folgende Ausdruck
sortiert die Menge der Oberabteilungen absteigend nach der Anzahl ihrer
Mitarbeiter und bei gleicher Mitarbeiterzahl alphabetisch nach ihrem Namen und
liefert eine sortierte Liste:

\begin{xple}
  \key{select} abt
  \key{from} abteilungen abt
  \key{where}\key{not} abt.Unterabteilungen.empty? 
  \key{order by} (count(abt.Angestellte) \key{desc},
                abt.Name \key{asc}
\end{xple}

Zus"astzlich kann eine sfw- um eine \ky{group by}-KLausel erweitert werden die
es erlaubt, die Elemente eine Kollektion nach bestimmten Kriterien in mehrere
Partitionen zu gruppieren.

\begin{xple}
\key{group by} (p$_{1}$: e$_{1}$, p$_{2}$: e$_{2}$, \dots  p$_{n}$: e$_{n}$)
\end{xple}

Dabei ist \p{x} die Bereichsvariable, die an die durch \p{e} beschriebene
Kollektion gebunden ist. Die \ky{group by}-Klausel legt das Kriterium f"ur die
Partitionierung fest. Das Kriterium setzt sich aus den Ausdr"ucken \p{e}$_{i}$
zusammen, f"ur die die Bezeichner \p{p}$_{i}$ eingef"uhrt werden.  Alle
Elemente, bei denen die Auswertung der Ausdr"ucke \p{e}$_{i}$ dieselbe
Wertekombination liefert, werden in eine Partition gruppiert.  Wenn f"ur die
\p{e}$_{i}$ sich ausschlie"sende Pr"adikate gew"ahlt werden, stellen diese
Pr"adikate Charakterisierungen der einzelnen Partitionen dar.  Dies l"a"st sich
am besten an einem Beispiel veranschaulichen. Durch den folgenden Ausdruck
werden die \p{Mitarbeiter} in Gehaltsklassen aufgeteilt (partitioniert):

\begin{xple}
\key{select} *
\key{from} festangestellte f
\key{group by} hoch:  f.Gehalt $>$ 8000, 
             mittel:  f.Gehalt $<$ = 8000  and f.Gehalt $>$ = 3000, 
             niedrig: f.Gehalt $<$ 3000)
\end{xple}

Das Ergebnis der \ky{group by}-Operation ist eine Menge von
Strukturen, wobei jede der Strukturen eine der Partitionen
repr"asentiert.  Die Strukturen besitzen Komponenten \p{p}$_{i}$ mit
dem jeweiligen Wert von \p{e}$_{i}$ und eine mengenwertige Komponente
mit dem vordefinierten Namen \p{partition}, die die Elemente der
jeweiligen Partition enth"alt.  Es ist vom Typ:

\begin{xple}
\key{Set}$<$ \key{Structure}
   $<$ hoch: \key{Boolean}, mittel: \key{Boolean} niedrig: \key{Boolean}
       partition: \key{Bag} $<$ Festangestellte $>$  $>$
\end{xple}

Jedes der drei Elemente des Ergebnisses repr"asentiert eine der Partitionen und
ist durch die Werte der Boole'schen Variablen \p{hoch}, \p{mittel} und
\p{niedrig} gekennzeichnet.
 
Durch Angabe eines entsprechenden Ausdrucks in der \ky{select}-Klausel ist es
auch m"oglich eine Aggregatfunktionen auf die erzeugten Partitionen anzuwenden.
Damit l"a"st sich z.B.\ das durchschnittliche Gehalt der Mitarbeiter zu jeder
Abteilung berechnen und zusammen mit dem jeweiligen Namen der Abteilung
ausgeben.
 
\begin{xple}
\key{select} structure(Abteilung avg\_Gehalt: avg(\key{select} x.Gehalt \key{from} partition x))
\key{from} festangestellte f
\key{group by} Abteilung: f.Arbeitgeber.name
\end{xple}

F"ur das Bespiel ist das Ergebnis vom Typ: 

\begin{xple}
\key{Bag}$<$ \key{Structure} $<$ Abteilung: \key{String}, avg\_Gehalt: \key{Integer}$>$  $>$
\end{xple}

Wie in SQL kann auch in OQL die \ky{group by}-Klausel durch eine
\ky{having}-Klausel erweitert werden, die es erlaubt, einschr"ankende
Pr"adikate auf den Partitionen zu definieren

\subsubsection{Anfragen auf geordnete Kollektionen}
\label{Anfragen auf geordnete Kollektionen}

Speziell f"ur geordnete Kollektionen bietet OQL Anfragekonstrukte zur 
Selektion von einzelnen Elementen und Teilkollektionen an:

\begin{itemize}
\item Da dem ersten bzw.\ letzten Elements einer geordneten Kollektion in vielen
  Situationen, wie z.B. bei der Verwendung einer Liste als Warteschlange eine
  besondere Bedeutung zukommt, existieren spezielle Operatoren \key{first} und
  \key{last} zur Selektion des ersten bzw.\ letzten Elements einer geordneten
  Kollektion. Wenn man davon ausgeht, da"s die Projekte zu jeder Abteilung nach
  Priorit"at geordnet sind, l"a"st sich mit der folgenden Anfrage das wichtigste
  Projekt der Abteilung \p{a1} ermitteln:

\begin{xple}
  \key{first}(abt1.Projekte)
\end{xple}

\item Das i-te Element einer geordneten Kollektion kann durch die Angabe des
  Index \p{i} in eckigen Klammern selektiert werden\footnote{Es ist zu beachten,
    da"s das erste Element den Index 0 besitzt.}. Obiger Ausdruck l"a"st sich
  damit auch wie folgt definieren:

\begin{xple}
  abt1.Projekte[0]
\end{xple}

Es ist eine gute "Ubung sich die Formulierung der entsprechenden 
Anfrage unter Verwendung der Aggregatfunktion \key{min} zu "uberlegen.

\item Die positionsabh"angige Selektion einer Teilkollektion einer geordneten
  Kollektion geschieht durch die Angabe des Index (der Position) des ersten und
  des letzten der auszuw"ahlenden Elemente, eingefa"st in eckige Klammern und
  getrennt durch einen Doppelpunkt. Analog zum vorigen Beipiel ergibt die
  folgende Anfrage die \e{Top Ten}-Liste der bestverdienenden Festangestellten

\begin{xple}
\key{list}(\key{select}
       \key{from} festangestellte f
       \key{order by} f.Gehalt \key{desc}) [0:9]
\end{xple}
\end{itemize}





