\section{Die etablierten Datenbankmodelle im "Uberblick}
\label{Die etablierten Datenbankmodelle im Ueberblick}

Der Gruppe der wichtigsten etablierten Datenmodelle ist neben den klassischen
Vertretern, hierarchisches Datenmodell, Netzwerkdatenmodell und relationales
Datenmodell, inzwischen sicherlich auch die Familie der objektorientierten
Datenmodelle zuzurechnen. Die praktische Bedeutung des relationalen Modells und
der objektorientierten Modelle nimmt dabei stetig zu, w"ahrend die beiden
fr"uhen Modelle zwar aufgrund zahlreicher umfangreicher existierender Systeme
noch eine hohe Praxisrelevanz besitzen, f"ur die Realisierung neuer Systeme
aber kaum mehr eingesetzt werden.

Ziel dieses Abschnitts ist es, durch eine fokussierte Einf"uhrung der
charakteristischen Konzepte und deren Erl"auterung anhand eines
Beispiels ein intuitives Verst"andnis f"ur die unterschiedlichen
Datenbankmodelle zu vermitteln. Vergleichbare Konzepte und Ans"atze
spielen dabei eine wichtigere Rolle als syntaktische Besonderheiten
der einzelnen Modelle.  Dieser Betonung der Gemeinsamkeiten und der
Erleichterung eines Vergleichs dient die Verwendung einer uniformen
grafischen Notation und eines einheitlichen Beispiels bei der
Erl"auterung der Modelle.

Die grafische Notation und das Beispiel werden in Abschnitt \ref{Eine
  datenmodellunabhaengige Metanotation} vorgestellt.  Die folgenden
Abschnitte sind den einzelnen Datenbankmodellen gewidmet.  Aufgrund
ihrer abnehmenden Bedeutung und der "Ahnlichkeit der zugrundeliegenden
Konzepte werden das Netzwerkdatenmodell und das hierarchische
Datenmodell dabei in einem Abschnitt (\ref{Ueberblick ueber die
  praerelationale Aera}) zusammengefa"st, w"ahrend f"ur das
relationale Modell und f"ur die Gruppe der objektorientierten Modelle
jeweils ein eigener Abschnitt vorgesehen ist.  Dieser Teil des
Kapitels schlie"st mit einem zusammenfassenden tabellarischen
Vergleich der betrachteten Datenmodelle in Abschnitt \ref{Vergleich
  der Modelle}.

 
%Problematik: Metanotation zur Beschreibung der ``Semantik''  
%der Modelle und n syntaktische Formen f"ur n Modelle. 

%Ziel: Pragmatische, verfuehrerische, nicht uebertrieben wissenschaftliche 
%Herausarbeiten:  

\subsection{Eine datenmodellunabh"angige Metanotation}
\label{Eine datenmodellunabhaengige Metanotation}

Die Parallelen und Unterschiede zwischen den betrachteten Datenmodellen k"onnen
am besten durch die Verwendung einer einheitlichen Notation zur Darstellung der
verschiedenen Modelle aufgezeigt werden.  Alle Datenbankmodelle basieren auf
einem gemeinsamen, relativ kleinen Satz von Datenmodellkonzepten zur
Beschreibung von Datenbankzust"anden, f"ur die im folgenden eine grafische
Notation (s. Abbildung \ref{Legende Datenbankstrukturen}) gew"ahlt wird:
\renewcommand{\epsfsize}[2]{0.7#1}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/LegendeBilder.ps}
\caption{Legende f"ur Datenbankzust"ande}
\label{Legende Datenbankstrukturen}  
\end{center}
\end{figure}

\begin{description}
\item [] \e{Literale} beschreiben die atomare Werte, die als Bausteine
  in komplexeren Informationsstrukturen verwendet werden k"onnen.
  Beispiele f"ur Literale sind ganze Zahlen oder Zeichenketten.
  Literale werden ohne Verwendung weiterer Symbole in der Grafik
  notiert. Ausgezeichnete Werte mit einer speziellen Semantik, wie
  z.B.\ der \glqq Nullwert\grqq\ \key{null}, werden durch Fettschrift
  hervorgehoben.

\item [] \e{Aggregate} beschreiben zusammengesetzte Werte, die aus einer
  (ungeordneten) Folge von Paaren aus Attributnamen und zugeordneten
  Attributwerten bestehen. Die Komponenten eines Aggregats k"onnen "uber ihren
  Namen angesprochen werden. Die meisten Datenbankmodelle unterst"utzen
  selektive Zuweisungen an Wertkomponenten, jedoch nicht das Hinzuf"ugen oder
  L"oschen von Attributen. Aggregate sind mit den \e{Records} in Pascal und den
  \e{Structures} in C vergleichbar.  In der grafischen Notation werden
  Aggregate durch \e{Rechtecke} dargestellt, die in der ersten Zeile die
  Attributnamen \p{X}$_{i}$ und in der zweiten Zeile die zugeh"origen
  Attributwerte \p{A}$_{i}$ enthalten.

\item [] \e{Referenzen} beschreiben (physikalische) Verweise auf andere
  Objekte.  Sie sind mit den aus dem Bereich der Programmiersprachen bekannten
  Zeigern vergleichbar. Referenzen zwischen Objekten werden durch \e{Pfeile}
  dargestellt, die vom referenzierenden zum referenzierten Objekt f"uhren.

\item [] \e{Kollektionen} beschreiben zusammengesetzte Werte, die aus einer
  variablen Anzahl unbenannter Komponenten bestehen.  Es wird dabei von einer
  dynamischen Klassifikation der Objekte (Werte) in die Kollektionen
  ausgegangen. Die Kollektionen werden in der grafischen Notation durch
  \e{Rechtecke mit abgerundeten Ecken} dargestellt, die ihre Elemente
  \p{A}$_{i}$ nebeneinander oder untereinander enthalten.
\end{description}

Bei den meisten Datenbankmodellen wird von einer Typisierung ausgegangen.
Typisierung hat f"ur Datenbankmodelle die folgenden Konsequenzen:

\begin{itemize}
\item Die Attribute sind typisiert, wodurch Operationen auf den Attributen auf
  ihre Zul"assigkeit "uberpr"uft werden k"onnen.

\item Die Kollektionen sind homogen, d.h. alle Elemente einer Kollektion
  besitzen den gleichen Typ.
\end{itemize}

Aufgrund der Typisierung sind auf der \e{Schemaebene} analoge
Modellierungskonzepte zu finden, mit denen die Struktur von zul"assigen
Datenbankzust"anden beschrieben wird:

\begin{description}
\item [] \e{Basisdatentypen (Dom"anen)} beschreiben Wertebereiche.  Sie setzen
  sich aus Mengen von Literalen zusammen.

\item [] \e{Aggregattypen} beschreiben die Struktur von Aggregaten.  Sie setzen
  sich aus Paaren von Bezeichnern und Typen f"ur die Attribute des Aggregats
  zusammen.

\item \e{Kollektionstypen (Massendatentypen)} beschreiben die Struktur von
  Kollektionen. Dabei wird die Art der Kollektion (Liste, Menge, etc.) und der
  Typ der Elemente der Kollektion festgelegt.

\item [] \e{Mengenwertige Referenzen}
\end{description}

Aus diesen Betrachtungen l"a"st sich bereits schlie"sen, da"s es eine gewisse
Verwandtschaft zwischen Sprachen zur Schemadefinition und den Konstrukten zur
Typdefinition in Programmiersprachen gibt.  Eine Konvergenz dieser beiden
verwandten Konzepte ist eine der wesentlichen Grundlagen der
Datenbankprogrammiersprachen, die in Abschnitt
\ref{Datenbankprogrammiersprachen} behandelt werden.

Um diese Betonung der Gemeinsamkeiten zu erreichen und um einen Vergleich der
Modelle zu erleichtern, wird zur Erl"auterung der verschiedenen Modelle ein
einheitliches Beispiel gew"ahlt. Alle betrachteten Datenmodelle werden anhand
einer Projektdatenbank vorgestellt, die einen Ausschnitt des
Firmeninformationssystems aus Abschnitt \ref{Beispiel: Ein
  Firmeninformationssystem} bildet. Der Ausschnitt beschr"ankt sich auf die
Darstellung der Projekte und Abteilungen zusammen mit den Beziehungen zwischen
diesen Objekttypen (s. Abbildung \ref{Projektdatenbank OMT}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/28.eps}
\caption{Durchg"angiges Beispiel f"ur Kapitel \ref{Die etablierten Datenbankmodelle im Ueberblick}}
\label{durchgaengiges Beispiel}  
\end{center}
\end{figure}

\subsection{Das relationale Datenmodell}
\label{Das relationale Datenmodell}

Wegen seiner Beliebtheit und weiten Verbreitung in der Forschungsgemeinde und
auch im kommerziellen Bereich spielt das relationale Modell eine wichtige Rolle
im Bereich der Datenbanken. Im kommerziellen Bereich ersetzen relationale
Systeme mit wachsender Tendenz Systeme, die auf fr"uheren Modellen, wie dem
Netzwerkmodell und dem Hierarchischen Modell, beruhen.

Der Erfolg des relationalen Datenmodells ist auf seine Einfachheit
zur"uckzuf"uhren. Es gibt nur eine Art von Datenstrukturen: Tabellen mit Zeilen
und Spalten, die Daten von skalaren Datentypen enthalten. Die Anfragesprache
basiert auf einigen wenigen, wohldefinierten Operationen auf Tabellen. Das
Verst"andnis der komplexeren Operationen, z.B.\ zur Definition von
Integrit"atsbedingungen und Sichten, sowie zur Restrukturierung der Daten ist
f"ur den Endbenutzer nicht relevant.

Die Einfachheit des Modells resultiert nicht nur in einer hohen
Benutzerfreundlichkeit, sondern auch in einer guten mathematischen
Handhabbarkeit des Modells.

Nach einem "Uberblick "uber die Konzept in Abschnitt \ref{Ueberblick
  ueber die Konzepte} werden Tabellen als grundlegender
Modellierungsmechanismus im relationalen Datenmodell vorgestellt.  Die
Darstellung von Beziehung ist Thema von Abschnitt \ref{Assoziationen
  im relationalen Modell}.  Dom"anen werden in dem darauf folgenden
Abschnitt \ref{Domaenen und referentielle Integritaet} behandelt.  Der
Vermeidung von Redundanzen und damit verbundener Anomalien ist
Abschnitt \ref{Normalisierung} gewidmet.  Die restlichen Abschnitte
wenden sich der Sprache SQL zu, die sowohl zur Datendefinition als
auch zur Datenmanipulation eingesetzt wird.

\subsubsection{"Uberblick "uber die Konzepte}
\label{Ueberblick ueber die Konzepte}

Die wichtigsten Konzepte des relationalen Datenmodells lassen sich 
wie folgt zusammenfassen:

\begin{itemize}
\item Im relationalen Datenmodell besteht eine Datenbank aus einer Menge von
  \e{Relationen}.

\item \e{Relationen} sind Mengen von Elementen

\begin{itemize}
\item deren Struktur durch Attribute definiert,

\item deren Identit"at durch Sch"ussel realisiert und

\item deren Werte durch Dom"anen kontrolliert werden.
\end{itemize}

Da Relationen Mengen sind, sind die enthaltenen Elemente unsortiert und es gibt
keine Duplikate. Weiterhin ist auch die Reihenfolge der Attribute nicht
festgelegt.

\item Relationen werden meist durch \e{Tabellen} dargestellt, wobei jede
  Tabelle aus Zeilen und Spalten besteht.

\item Jede Zeile einer Tabelle repr"asentiert ein Element der Relation, das
  auch als \e{Tupel} bezeichnet wird.

\item Die Zahl der Zeilen (= Anzahl der Tupel in der Relation) ist variabel und
  wird die \e{Kardinalit"at} der Relation genannt.

\item Die Spalten der Tabellen enthalten die \e{Attribute} der Relation.

\item Die Zahl der Spalten einer Tabelle (= Anzahl der Attribute der Relation)
  wird im Schema festgelegt und als \e{Grad} der Relation bezeichnet.

\item Jeder Spalte ist eine \e{Dom"ane} zugeordnet, die die zul"assigen Werte
  f"ur das Attribut in allen Reihen festlegt. Im relationalen Modell m"ussen
  die Dom"anen atomare Werte besitzen.

\item Jede Tabelle besitzt einen \e{Prim"arschl"ussel}. Das ist ein
  ausgezeichnetes Attribut oder eine minimale Attributkombination, die eine
  eindeutige Identifizierung jedes Tupels der Relation "uber den Wert der
  Prim"arschl"usselattribute gestattet.

\item Beziehungen zwischen Datenobjekten werden im relationalem Modell nicht
  durch Referenzen, sondern durch die Identifikation des referenzierten Objekts
  "uber seinen Prim"arschl"ussel repr"asentiert (assoziative Identifikation,
  vgl. Abschnitt \ref{Identifikation und Schluessel}).

\item Ein Prim"arschl"ussel, der in einer Relation \p{A} benutzt wird, um ein
  Tupel (Objekt) in einer Relation \p{B} zu referenzieren, wird als
  \e{Fremdschl"ussel} von \p{A} bezeichnet.
\end{itemize}

%\comment{Minimal und voll relational (CODD)}

\subsubsection{Tabellen und Schl"ussel}
\label{Tabellen und Schluessel}

Zur Modellierung der Projektdatenbank im relationalen Modell werden drei
Tabellen ben"otigt, eine f"ur jede Art von Objekten der Anwendung (\p{Projekt}
und \p{Abteilung}) und eine Tabelle \p{Projekt\-durch\-f"uhrung} f"ur die
Darstellung der Beziehung zwischen Abteilungen und Projekten. Abbildung
\ref{Zustand Datenbank (RDM)} zeigt einen Zustand der Projektdatenbank bei der
gew"ahlten Modellierung. Dabei entspricht jede Zeile einem Element der
Relation. Die Spalten der Tabellen entsprechen den Eigenschaften der Objekte
der Anwendung.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/29.eps}
\caption{Zustand der Firmendatenbank (Relationales Datenmodell)}
\label{Zustand Datenbank (RDM)}
\end{center}
\end{figure}

Eine relationale Datenbank ist ein benanntes Aggregat, wobei der Bezeichner
f"ur das Aggregat der Schemaname ist. Im Beispiel besitzt das Aggragat 
drei Komponenten, n"amlich die Relationen \p{Projekte}, \p{Abteilungen}
und \p{Projektdurchf"uhrung}. Jede der Komponenten 
ist eine Kollektion. Die Elemente der Kollektionen sind  
die Tupel der Relation also wiederum Aggregate, deren Komponenten nur 
Literale sein d"urfen (flache Tupel). 

Schl"ussel sind von zentraler Bedeutung  f"ur das relationale Datenmodell.
Dabei ist zwischen zwei Arten von Schl"usseln zu unterscheiden:

\begin{description}
\item[Prim"arschl"ussel:] Ein \e{Prim"arschl"ussel} ist ein Attribut oder eine
  minimale Attributkombination, das bzw. die in jeder Reihe der Tabelle
  eindeutige Werte bzw.  Wertkombinationen enth"alt. In einigen F"allen gibt es
  mehrere Attribute (Attributkombinationen) mit dieser Eigenschaft. Man spricht
  dann von mehreren \e{Schl"usselkandidaten}, von denen einer als
  Prim"arschl"ussel ausgezeichnet wird.  Man kann sich die Prim"arschl"ussel
  als eindeutige Bezeichner f"ur die durch die Reihen einer Tabelle
  repr"asentierten Objekte der realen Welt vorstellen. Im Beispiel besitzt die
  Tabelle \p{Abteilungen} das Attribut \p{Kurz} als Prim"arschl"ussel und die
  Tabelle \p{Projekte} das Attribut \p{Nr}.

\item[Fremdschl"ussel:] Ein \e{Fremdschl"ussel} ist ein Attribut oder eine
  Attributkombination in einer Tabelle, das bzw. die als Werte
  Prim"arschl"ussel anderer Tabellen annimmt. Ein Fremdschl"ussel ist also eine
  Referenz auf ein anderes Objekt (=eine Reihe einer nicht notwendigerweise
  verschiedenen Tabelle). In der betrachteten Anwendung ist z.B. das Attribut
  \p{AbtKurz} der Tabelle \p{Projekt\-durch\-f"uhrung} ein Fremdschl"ussel.
\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/30.eps}
\caption{Fremdschl"ussel}
\label{Fremdschluessel}
\end{center}
\end{figure}

Das relationale Modell erlaubt keine Duplikate in einer Tabelle, d.h. keine
zwei Tupel d"urfen in allen Attributen "ubereinstimmen. In diesem Sinne haben
alle Tabellen automatisch einen Prim"arschl"ussel, n"amlich alle Attribute der
Relation. Die Kombination aller Attribute ist jedoch als Prim"arschl"ussel zur
Identifikation der Objekte nicht sinnvoll. F"ur den Fall, da"s eine ein- oder
zweielementige Teilmenge der Attribute zur Identifikation nicht ausreicht,
empfiehlt sich die Einf"uhrung eines k"unstlichen Schl"ussel z.B. einer
eindeutigen Nummer (ID) f"ur jeden Tupel.

Die Prim"arschl"ussel und Fremdschl"ussel der Tabellen spielen eine wichtige
Rolle f"ur die Repr"asentation von Beziehungen zwischen Objekten im
relationalen Modell.

\subsubsection{Assoziationen im relationalen Modell}
\label{Assoziationen im relationalen Modell}

In den meisten modernen Anwendungen des relationalen Modells unterscheiden die
Benutzer zwischen zwei Arten von Tabellen. Tabellen, die Objekttypen
(Entit"aten) der Anwendung darstellen, werden als \e{Entit"atentabellen}
bezeichnet. Jede Zeile einer solchen Tabelle repr"asentiert ein Objekt der
Anwendung.

Die zweite Art von Tabellen wird als \e{Beziehungstabellen} bezeichnet. 
Beziehungstabellen werden unter Verwendung von Fremdschl"usseln zur 
Darstellung von Assoziationen zwischen Objekten der Anwendung eingesetzt. 

Dabei wird nicht zur Darstellung jeder Beziehung eine eigene Tabelle ben"otigt.
Bin"are 1:1- und 1:n-Beziehungen lassen sich durch Aufnahme eines
Fremdschl"usselattributs in eine der Entit"atentabellen beteiligten Objekttypen
repr"asentieren.

Ein Beispiel ist die Abteilungshierarchie, eine optionale 1:n-Beziehung
zwischen Abteilungen. Um diese Beziehung darzustellen, wird der Fremdschl"ussel
\p{Oberabteilung} als zus"atliches Attribut in die Tabelle \p{Abteilung}
eingef"uhrt. Dieser Fremdschl"ussel referenziert die Oberabteilung einer
Abteilung. Sogar Beziehungen h"oheren Grades (vgl. Abschnitt \ref{Assoziation
  und Identifikation}) k"onnen ohne Beziehungstabellen modelliert werden,
solange h"ochstens einer der beteiligten Objekttypen eine Multiplizit"at
gr"o"ser eins in der Beziehung besitzt.

Beziehungstabellen sind notwendig, wenn mehr als eine der beteiligten
Objekttypen eine h"ohere Multiplizit"at hat, wie dies z.B. bei n:m-Beziehungen
der Fall ist. Die n:m-Beziehung zwischen \p{Projekte} und \p{Abteilungen} mu"s
somit durch eine eigene Beziehungstabelle \p{Projekt\-durch\-fuehrung}
dargestellt werden (s. Abbildung \ref{Zustand Datenbank (RDM)}).  Diese Tabelle
besitzt zwei Attribute \p{AbtKurz} und \p{ProjektNr}, die beide Fremdschl"ussel
sind: Das erste Attribut referenziert eine Abteilung, das zweite Attribut
referenziert ein Projekt. Als Werte f"ur die Fremdschl"ussel sind dabei
Abteilungsk"urzel (= Prim"arschl"ussel von \p{Abteilungen}) und Projektnummern
(=Prim"ar\-schl"us\-sel von \p{Projekte}) m"oglich.

F"ur jedes einzelne Paar Abteilung-Projekt enth"alt die Beziehungstabelle 
\p{Projekt\-durch\-f"uhrung} eine eigene Zeile. So erscheint z.B. das
Abteilungsk"urzel \glqq UXSW\grqq\ zweimal in der Tabelle, da die zugeh"orige 
Abteilung an zwei Projekten mitarbeitet und die Prokjektnummer 100 
erscheint dreimal in der Tabelle, da drei Abteiungen an dem Projekt mit
dieser Nummer arbeiten. 

Man beachte, da"s Abbildung \ref{Zustand Datenbank (RDM)} keine
Referenzen zwischen Objekten enth"alt, f"ur die in Abschnitt 
\ref{Eine datenmodellunabhaengige Metanotation} 
die Pfeilnotation eingef"uhrt wurde. Die Beziehungen zwischen den 
Objekten werden im relationalen Modell allein durch gleiche Werte
in zusammengeh"origen Prim"ar\-schl"ussel/Fremd\-schl"ussel-Paaren 
dargestellt. Es existieren \e{keine} Zeiger oder vergleichbare 
Strukturen zur Verkn"upfung von Objekten. Das relationale Modell 
basiert auf assoziativer Identifikation. 

\subsubsection{Dom"anen und referentielle Integrit"at}
\label{Domaenen und referentielle Integritaet}

Allgemein stellt \e{referentielle Integrit"at} sicher, da"s Objekte, die
referenziert werden, auch tats"achlich in der Datenbank existieren.  Beim
relationalen Modell ist die referentielle Integrit"at eng mit der Verwendung
der Fremdschl"ussel zur Darstellung von Beziehungen zwischen Objekttypen
verbunden. Zur Wahrung der referentiellen Integrit"at mu"s eine Menge von
Integrit"atsbedingungen definiert werden, die sicherstellen, da"s zu jedem in
der Datenbank benutzten Fremdschl"ussel in der referenzierten Tabelle ein Tupel
mit einem entsprechenden Prim"arschl"usselwert existiert. So mu"s bei der
Projektdatenbank zu jedem Wert \p{k} des Attributs \p{AbtKurz} in der Tabelle
\p{Projekt\-durch\-fuehrung} ein Tupel in der Tabelle \p{Abteilung} mit dem
gleichen Wert \p{k} f"ur das Attribut \p{Kurz} existieren.

Ein gutes relationales DBMS sollte die Wahrung der referentiellen Integrit"at
sicherstellen. Eine "Uberpr"ufung ist in den folgenden Situationen notwendig:

\begin{itemize}
\item Beim Einf"ugen eines neuen Fremdschl"usselwertes in ein Attribut mu"s
  "uberpr"uft werden, ob in der referenzierten Tabelle ein Objekt mit diesem
  Wert als Prim"arschl"ussel existiert. So mu"s z.B. ein Projekt mit einer
  entsprechenden Nummer existieren, bevor diese Nummer als Wert f"ur den
  Fremdschl"ussel \p{ProjektNr} in der Tabelle \p{Projekt\-durch\-fuehrung}
  verwendet werden kann.

\item Beim L"oschen eines Tupels aus einer Tabelle mu"s "uberpr"uft werden, ob
  dieses Tupel noch referenziert wird, d.h. ob sein Prim"arschl"ussel noch
  irgendwo als Fremdschl"usselwert in Gebrauch ist. Falls noch Referenzen auf
  den Prim"arschl"ussel existieren, gibt es verschiedene Optionen f"ur das
  weitere Verfahren:

\begin{enumerate}
\item Es wird eine Fehlermeldung erzeugt.

\item Die L"oschoperation wird propagiert, d.h. das referenzierende Tupel wird
  ebenfalls gel"oscht, was zur Notwendigkeit weiterer L"oschungen f"uhren kann
  (\e{Kaskadiertes L"oschen}).

\item Die Referenz wird ung"ultig gemacht, indem der Fremdschl"ussel auf einen
  Nullwert gesetzt wird.
\end{enumerate}
\end{itemize}

Ein Beipiel f"ur kaskadiertes L"oschen sind die Konsequenzen der Entfernung
einer Abteilung \p{a} aus der Projektdatenbank. Mit der Abteilung m"ussen alle
Tupel in \p{Projekt\-durch\-f"uhrung} gel"oscht werden, die sich auf diese
Abteilung beziehen. Zugleich m"ussen aber auch alle Abteilungen gel"oscht
werden, die \p{a} "uber das Attribut \p{Oberabteilung} referenzieren, d.h. alle
Unterabteilungen von \p{a}. Dies erfordert dann evtl. wiederum ein L"oschen in
der Tabelle \p{Projekt\-durch\-fuehrung}, soda"s eine einzelne L"oschoperation
weitreichende (und auch unerwartete) Folgen haben kann.

Ein weiteres wichtiges Konzept des relationalen Modells sind die \e{Dom"anen}.
Dom"anen legen zul"assige Wertebereiche f"ur Attribute fest und sind mit Typen
f"ur Attribute vergleichbar. Dom"anen k"onnen mit vordefinierten Typen
"ubereinstimmen oder spezielle Mengen von Werten f"ur ein Attribut festlegen.

Das Dom"anenkonzept erlaubt es, die Zul"assigkeit von Operationen 
auf Attributen zu "uberpr"ufen. So kann z.B. der Vergleich von Attributen
wie die Nummer und das Budget eines Projekts, die verschiedene unterliegende 
Dom"anen besitzen, verhindert werden. 
Von den meisten relationalen Systemen wird das Dom"anenkonzept jedoch nicht 
realisiert, da eine vollst"andige und flexible Implementierung von Dom"anen 
eine erhebliche Komplexit"at besitzt. Eine ausf"uhrlichere Beschreibung des 
Dom"anenkonzepts findet sich in \cite{xxUllman 1987, Date 1990}.


\subsubsection{Normalisierung}
\label{Normalisierung} 

Viel Forschung im Bereich der Datenbanken besonders in den 80er Jahren hatte
die \e{Normalisierung} relationaler Schemata zum Thema. Normalisierung
besch"aftigt sich mit der besten konzeptuellen Darstellung von Anwendungsdaten
durch relationale Tabellen; dieses Problem kann f"ur umfangreiche Schemata recht
komplex werden. Im wesentlichen werden bei der Normalisierung gro"se Tabellen
(hoher Grad) in kleinere Tabellen zerlegt mit dem Ziel, nicht zu viel
Information in eine Tabelle zu packen.

Mit \glqq zuviel\grqq\ Information in einer Tabelle k"onnen die
folgenden Probleme verbunden sein:

\begin{description}
\item [Redundanz:] Dieselbe Information wird an mehr als einer Stelle
  gespeichert. Wenn man z.B. die Attribute der Projekte mit in die Relation
  \p{Projekt\-durch\-f"uhrung} aufnimmt, anstatt sie in einer eigenen Relation
  \p{Projekt} zu speichern, f"uhrt dies zu Redundanz, da dasselbe Projekt mit
  mehreren Abteilungen in Beziehung stehen kann. Redundanz kann bei
  Aktualisierungsoperationen zu Inkonsistenzen f"uhren, wenn die Information
  nicht an allen Stellen ge"andert wird.

\item [Abh"angigkeiten:] Bestimmte Informationen k"onnen nicht eingef"ugt
  werden, ohne da"s bestimmte andere Informationen bereits existieren. Bei der
  unter dem Punkt Redundanz angesprochenen Modellierung kann z.B.\ ein Projekt
  nur zusammen mit einem Objekt vom Typ \p{Projekt\-durch\-f"uhrung} eingef"ugt
  werden.
\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/31.eps}
\caption{Redundanz in der Entit"atentabelle \p{Projektdurchf"uhrung}}
%\label{}  
\end{center}
\end{figure}

In der Datenbankliteratur wurden nacheinander eine Reihe von
Normalformen entwickelt, die sich mit verschiedenen Anomalien bei der
relationalen Schemarepr"asentation auseinandersetzen.  Die \e{erste
  Normalform} fordert \glqq flache\grqq\ Tabellen, d.h. Attribute
d"urfen nicht mengenwertig sein.  Die zweite, dritte und die weiteren
Normalformen besch"aftigen sich mit den semantischen Abh"angigkeiten
zwischen den aktuellen Daten in den Tabellen.  Diese Normalformen sind
besonders f"ur Datenbankadministratoren beim Entwurf relationaler
Schemata von Interesse. F"ur ein mehr konzeptuelles Verst"andnis des
relationalen Modells sind sie jedoch nicht notwendig und werden
deshalb hier nicht weiter behandelt. Ein guter "Uberblick "uber das
Thema findet sich in \cite{Ullman 1989xx}.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/32.eps}
\caption{Normalformen und ihr Zusammenhang}
%\label{}  
\end{center}
\end{figure}

\subsubsection{Datendefinition im relationalen Modell}
\label{Datendefinition im relationalen Modell}

F"ur relationale Datenbanksysteme hat sich die Datenbanksprache SQL zum
Quasi-Standard entwickelt. Sie wird von fast allen relationalen Systemen
unterst"utzt.  SQL umfa"st Konstrukte zur Datendefinition, zur deskriptiven
Formulierung von Anfragen, zur Modifikation der Datenbank und zur
Schema"anderung.  Es wird hier nur soweit auf die SQL-Konstrukte eingegangen,
wie dies f"ur ein intuitives Verst"andnis des relationalen Modells notwendig
ist. Eine ausf"uhrlichere Beschreibung findet sich in Abschnitt \ref{Die
  relationale Datenbanksprache SQL}, der ganz diesem Thema gewidmet ist.

Abbildung \ref{RDM Schemadefinition} zeigt eine SQL-Schemadefinition f"ur die
Projektdatenbank. Die Definition eines SQL-Schemas umfa"st eine Reihe von
Tabellendefinitionen.  F"ur jede der Tabellen werden der Name der Tabelle, die
Attribute (Attributnamen und -typen) und der Prim"arschl"ussel festgelegt.
F"ur Attribute die keine Nullwerte annehmen d"urfen, wird die Angabe \key{not
  null} gemacht.  sehr regul"are Struktur


\begin{figure}
\hrule \medskip
\footnotesize{
\begin{xple}
\key{create table} Projekte
( Nr \key{integer}  \key{not null},
  Titel  \key{char}  (30)  \key{not null},
  Budget  \key{decimal}(10,2)  \key{not null},
  \key{primary key}(Nr) );

\key{create table} Abteilungen
( Kurz  \key{char}(4)  \key{not null},
  Name  \key{char}(30)  \key{not null},
  Oberabteilung  \key{char}(4),
  \key{primary key}(Kurz) );

\key{create table} Projektdurchfuehrung
( ProjektNr  \key{integer}  \key{not null},
  AbtKurz  \key{char}(4)  \key{not null},
  \key{primary key}(Nr, Kurz) );
\end{xple}}
\hrule
\caption{SQL-Schemadefinition f"ur die Projektdatenbank}
\label{RDM Schemadefinition}
\end{figure}

Aufgrund dieser Schemadefinition ergibt sich das in Abbildung \ref{relationales
  Modell: Schemadiagramm Datenbank} dargestellte Schemadiagramm.

\subsubsection{Die Anfragesprache SQL}
\label{Die Anfragesprache SQL}

Urspr"unglich wurden f"ur das relationale Modell neben anderen Anfragesprachen
die formalen Anfragesprachen relationales Kalk"ul und relationale Algebra
vorgeschlagen (s. Abschnitt \ref{Relationale Datenbanksysteme}).  Inzwischen
hat sich jedoch die deskriptive, mengenorientierte Sprache SQL allgemein als
einheitliche Anfragesprache f"ur relationale Systeme durchgesetzt.

\begin{figure}[hbt]
\hrule \medskip
\footnotesize{
\begin{xple}
\key{select} p.Titel 
\key{from} Projekte p,
    Projektdurchfuehrung pd,
    Abteilungen a
\key{where} p.Nr = pd.Nr
\key{and} a.Kurz = pd.Nr 
\key{and} a.Name = 'Mainframe SW'
\end{xple}}
\hrule
\caption{Beispielanfrage in SQL}
\label{Anfrage in SQL}
\end{figure}   

Abbildung \ref{Anfrage in SQL} zeigt eine Beispielanfrage in SQL.
Diese Anfrage bestimmt die Titel der Projekte, an denen die Abteilung
f"ur die \p{Main\-frame SW} arbeitet. Typischerweise verwenden
SQL-Anfrage das \ky{select from where}-Konstrukt, das zur
Iterationsabstraktion dient. Es besteht aus drei Teilen: einer
\ky{select}-Klausel, einer \ky{from}-Klausel und einer
\ky{where}-Klausel. Dabei legt die \ky{from}-Klausel die beteiligten
Tabellen fest und die \ky{where}-Klausel ein Selektionspr"adikat, mit
dessen Hilfe die Ergebnistupel aus dem kartesischen Produkt der
beteiligten Tabellen selektiert werden. Die \ky{from}-Klausel
spezifiziert die Projektionsliste f"ur die Ergebnistabelle. Nur durch
diese Projektionsliste ausgew"ahlte Spalten treten auch in der Tabelle
auf, die die Anfrage als Ergebnis berechnet.

Typisch f"ur eine Anfrage im relationalen Modell ist die Notwendigkeit,
einen sog. \e{Join} "uber mehrere Tabellen durchzuf"uhren. Die Tabellen
werden dabei wertbasiert, z.B. "uber gleiche Werte in zusammengeh"origen 
Prim"arschl"ussel/Fremdschl"ussel-Paaren, miteinander verkn"upft. 
Im Beispiel ist dies ein Join "uber die drei Tabellen \p{Projekte}, 
\p{Abteilungen} und \p{Projekt\-durch\-f"uhrung}.

\comment{Etwas zum deskriptiven Charakter}


\subsubsection{Aktualisierungsoperationen in SQL}
\label{Aktualisierungsoperationen in SQL}

Unabh"angig vom jeweiligen Datenmodell lassen sich Modifikationsoperationen auf
Datenbanken in drei grundlegende Klassen einteilen: Neben Operationen zum
\e{Einf"ugen} neuer Daten gibt es Operationen zum \e{"Andern} und \e{L"oschen}
von Daten, die in der Datenbank existieren. Die Modifikationsoperationen
k"onnen dabei sowohl Daten betreffen, die Objekte der realen Welt
repr"asentieren, als auch Daten und Strukturen, die Beziehungen zwischen
solchen Objekten repr"asentieren.

Da das relationale Modell diese Arten von Information beide durch
Tabellen repr"asentiert, werden daf"ur im Gegensatz zu anderen
Datenmodellen keine unterschiedlichen Operationen ben"otigt.  Zur
Modifikation einer Datenbank unterst"utzt SQL die generischen
Operationen \key{insert}, \key{update} und \key{delete}.  Neben einem
Parameter zur Selektion einer Tabelle (Tabellenname), den alle drei
Operationen ben"otigen, mu"s bei den Operationen \key{update} und
\key{delete} eine Selektion der (des) betroffenen Tupel(s)
durchfgef"uhrt werden.  Zur Datenselektion k"onnen dabei Konstrukte
der Anfragesprache eingesetzt werden.  Bei der \ky{update}-Operation
werden zus"atzlich f"ur ein oder mehrere Attribute neue Werte oder
Formeln zu deren Berechnung angegeben, die auf die bisherigen Werte
des Attributs zur"uckgreifen k"onnen.

\begin{figure}
\hrule \medskip
\begin{xple}
\footnotesize{
\key{insert into} Projektdurchfuehrung (Nr, Kurz)
\key{select} p.Nr, a.Kurz
\key{from} Projekte p, Abteilungen a
\key{where} p.Titel = 'Telekom Statistik' 
\key{and} a.Name = 'Unix SW' ;}
\end{xple}
\hrule
\caption{SQL-Einf"ugeoperation}
\label{SQL Beispiel Insert}
\end{figure}

Eine \ky{insert}-Operation f"ugt in der Regel nur ein einzelnes Tupel ein,
dessen Attributwerte der Operation als Parameter "ubergeben werden.  Abbildung
\ref{SQL Beispiel Insert} zeigt eine spezielle Form der insert-Operation, die
eine SQL-Anfrage zur Definition des einzuf"ugenden Tupels benutzt\footnote{Mit
  dieser Form der \ky{insert}-Operation k"onnen auch Mengen von Tupeln
  eingef"ugt werden.}.  Die dargestellte Operation definiert eine Beziehung
zwischen dem Projekt \p{Telekom Statistik} und der Abteilung \p{Unix Software},
indem sie ein entsprechendes Tupel in die Tabelle \p{Projektdurchf"uhrung}
einf"ugt. Die Attributwerte f"ur das einzuf"ugende Tupel (Fremdschl"ussel)
werden "uber ein sfw-Konstrukt aus existierenden Tupel der Datenbank
selektiert.  Im Beispiel werden die Schl"ussel des Projekts und der Abteilung,
die zur Dartsellung der Beziehung als Fremdschl"ussel ben"otigt werden, "uber
deren Namen ermittelt.

\subsubsection{Zusammenfassung}
\label{Zusammenfassung}

Die Einfachheit des relationalen Modells beruht im wesentlichen 
auf den folgenden drei Eigenschaften der Tabellen:

\begin{itemize}
\item Tabellen sind Mengen im mathematischen Sinne: Duplikate sind bei den
  Reihen nicht erlaubt, es ist keine Ordnung auf den Reihen definiert;

\item Die Attribute sind nicht geordnet, sie werden immer "uber ihren Namen
  referenziert, die innerhalb einer Tabelle eindeutig sein m"ussen;

\item Die Werte, die in den Spalten und Reihen der Tabelle gespeichert werden
  sind atomar, was insbesondere mengenwertige Attribute ausschlie"st
\end{itemize}

Diese Einschr"ankungen stellen zugleich auch Beschr"ankungen des relationalen
Modells dar. Es ist zum Beispiel schwierig Objekte, die in der Realit"at
geordnet sind, wie z.B. die Kapitel eines Buches, effizient durch eine Tabelle
zu repr"asentieren. evtl bei OO-Modell

\comment{
Bewertung RDM, auch in Folien, in OO-Manifesti, Paper "uber\\
Bewertung von SQL, Bewertung evtl. nicht hier sondern bei OO-System\\
Kritik auch in Heuer Buch + Won-Buch}

\subsection{Objektorientierte Datenmodelle}
\label{Objektorientierte Datenmodelle}

\comment{Alternative Objektorientierte Datenmodelle}

Zahlreiche Aktivit"aten in der Entwicklung experimenteller 
und kommerzieller Systeme

Das Feld der objektorientierten Datenbanktechnologie 
ist momentan gepr"agt durch:

\begin{itemize}
\item Das Fehlen eines \e{einheitlichen Datenmodells}: Es sind zwar eine Reihe
  von objektorientierten Datenmodellen entwickelt worden (Literatur xx). Es
  gibt kein einheitliches Modell, Warum m"ochte man ein einheitliches
  Datenmodell Ein einheitliches, standardisiertes Datenmodell erh"oht die
  Portabilit"at

\item Das Fehlen von \e{formalen Grundlagen}, wie sie z.B. f"ur das relationale
  Datenmodell oder die deduktiven Datenbanken existieren. Solche Grundlagen
  sind insbesondere f"ur die Definition der Semantik der Konzepte und
  Operatoren eines Datenmodells von Bedeutung.
\end{itemize}


Zwei wichtige Beispiele f"ur Aktivit"aten, die sich um die Untersuchung der
zentralen Aspekte und Konzepte objektorientierter Datenmodelle und um die
Festlegung eines einheitliche Datenmodells bem"uhen sind die folgenden:

\begin{description}
\item [Anforderungskataloge:] Die sogenannten \e{objektorientierten Manifesti}
  \cite{} und \cite{} bem"uhen sich darum die Konzepte herauszukristallisieren,
  die ein objektorientiertes Datenbanksystem ausmachen.  Die pr"asentierte
  Sammlungen von Konzepten sind als Diskussionsgrundlage f"ur die Erstellung
  einer Definition f"ur objektorientierte Systeme gedacht.


\item [Standardisierungvorschl"age:] Einen wichtigen Beitrag zur
  Standardisierung liefert die Arbeit der \e{Object Database Management Group}
  (\e{ODMG}), einem Konsortium aus Vertretern vieler namhafter kommerzieller
  Anbieter von Datenbanksystemen.  Die ODMG erarbeitet einen
  Standardierungsvorschlag ODMG-93 f"ur ein objektorientiertes
  Datenbankverwaltungssytem (\e{object database management system}, \e{ODBMS}),
  der in Version 1.1 in \cite{} vorliegt, aber zum Zeitpunkt der Entstehung
  dieses Buches noch weiterentwickelt wird.  Der Standardisierungsvorschlag
  umfa"st ein Objektmodell, eine Datendefinitionsprache, eine Anfragesprache
  und Sprachanbindungen f"ur C++ und Smalltalk.  Dem Standardisierungsvorschlag
  kommt insofern besondere Bedeutung zu, da alle beteiligten kommerziellen
  Anbieter zugesagt haben, ein ODMG-93-konformes Produkt auf den Markt zu
  bringen.  In diesem Abschnitt wird ein kurzer "Uberblick "uber die
  Datenmodellierungsaspekte des ODMG-Vorschlags gegeben. Eine ausf"uhrlichere
  Beschreibung des Vorschlags findet sich in Abschnitt \ref{Objektorientierte   
    Datenbanksprachen}.
\end{description}

\comment{Alternative Standardisierungsvorschl"age}

Im Anschlu"s werden zun"achst Anforderungen erl"autert, die an objektorientierte
Datenmodelle gestellt werden k"onnen.  Die nachfolgenden Abschnitte befassen
sich dann mit dem Standardisierungsvorschlag der ODMG.  In Abschnitt
\ref{"Uberblick "uber die Konzepte des ODMG-Objektmodells} wird ein "Uberblick
"uber das Modell anhand markanter Begriffe gegeben, Abschnitt
\ref{ODMG-Objekttypen} behandelt Objekttypen und stellt das
Firmeninformationssystem in einer objektorientierten Modellierung dar.
Grundlegende Mechanismen zur Assoziation und Datendefinition werden in Abschnitt
\ref{Assoziationen im ODMG-Objektmodell} und \ref{Datendefinition im
  ODMG-Objektmodell} behandelt.  Der "Uberblick "uber den ODMG-Standard
schlie"st mit der Vorstellung der Anfragesprache OQL (Asbchnitt \ref{Die
  Anfragesprache OQL}) und den Aktualisierungsoperationen (Abschnitt
\ref{Aktualisierungsoperationen im ODMG-Objektmodell}).

\subsubsection{Anforderungen und Konzepte objektorientierter Datenmodelle}
\label{Anforderungen und Konzepte objektorientierter Datenmodelle}

Im folgenden werden die wichtigsten Konzepte objektorientierter Datenmodelle
kurz beschrieben. Die Darstellung orientiert sich an den Anforderungen, die
in den OO-Manifesti zusammengestellt sind.

Die Anforderungen betreffen z.T. die Modellierungsm"achtigkeit und z.T. die
Systemfunktionalit"at. Da die Datenmodellierung Thema dieses Abschnitts ist,
werden hier im wesentlichen nur die Anforderungen and as Datenmodell
ber"ucksichtigt.

\begin{description}
\item [Typkonstruktoren und komplexe Objekte:]

\comment{Etwas zum Bgriff komplexe Oblekte (eigentlich \\
komplexe Werte ?? }
Komplexe Objekte werden aus einfacheren Objekten durch die Verwendung 
von Konstruktoren aufgebaut. Die Grundbausteine sind dabei die 
Basistypen wie \e{Integer} und \e{Boolean} (einfachste Objekte). 
Es gibt eine Reihe verschiedener Konstruktoren, die gr"o"stenteils 
aus dem Bereich der Programmiersprachen bekannt sind. 

Als Mindestanforderung an ein objektorientiertes Datenmodell kann die
Unterst"utzung eines Konstruktors f"ur Aggregattypen, wie z.B. \e{Tuple}, eines
Mengenkonstruktors, wie z.B. \e{Set} und eines Konstruktors f"ur geordnete
Kollektionen wie \e{List} oder \e{Array} betrachtet werden.  Weiterhin sind
die Konstruktoren eines OO-Datenmodells orthogonal kombinierbar, d.h. jeder
Konstruktor kann auf jedes Objekt angewandt werden.

Im Vergleich dazu ist das relationale Modell auf einen Konstruktor f"ur
Aggregattypen (Tupel) und einen Konstruktor f"ur Mengen (Relationen)
beschr"ankt. Die Orthogonalit"at der Konstruktoren ist im relationalen Modell
nicht gegeben. Der Konstruktor f"ur Aggregate kann nur auf Basistypen angewandt
werden. Auf diese Weise konstruierte Strukturen sind die einzig zul"assigen
Elementtypen f"ur die Konstruktion von Mengentypen (Relationen), d.h. das
relationale Modell ist beschr"ankt auf Strukturen der folgenden Art:

\begin{xple}
xx
\end{xple}

\item [Objektidentit"at:] Objekte besitzen eine Existenz, die unabh"angig von
  ihren Werten ist.  Zu diesem Zweck wird jedem Objekt bei seiner Erzeugung ein
  Objektidentifikator mit den folgenden Eigenschaften zugeteilt:

\begin{itemize}
\item Der Identifikator ist systemweit eindeutig und garantiert die
  Indentifizierbarkeit.

\item Der Identifikator bleibt unabh"angig vom Zustand und den
  Zustands"anderungen des Objekts gleich.

\item Die Identifikatoren werden vom System verwaltet und k"onnen nicht vom
  Benutzer ge"andert werden.
\end{itemize}
 
Die Objektidentit"at erlaubt die Referenzierung eines Objekts durch mehrere
andere Objekte (\e{Object Sharing}). Dadurch lassen sich beliebige
Objektgraphen aufbauen, die auch zyklische Strukturen enthalten k"onnen.

\comment{Object Update}

Die Unterst"utzung von Objektidentit"at erm"oglicht verschiedene
"Aquivalenzbegriffe f"ur Objekte (s.\ Abbbildung \ref{Gleichheit}):

\begin{itemize}
\item Man spricht von der \e{Identit"at} zweier Objekte, wenn es sich um das
  gleiche Objekt handelt d.h. die Identifikatoren der Objekte sind gleich.

\item Man spricht von \e{flacher Gleichheit} (\e{shallow equality}), wenn auf
  der obersten Strukturierungsebene beide Objekte die gleichen Werte und gleiche
  Referenzen auf andere Objekte (Identit"at der Referenzen) besitzen.

\item Man spricht von \e{tiefer Gleichheit} (\e{deep equality}), wenn die
  beiden Objekte auf allen Strukturierungsebenen wertgleich sind.  Um tiefe
  Gleichheit zu testen, ist ein rekursiver Test der flachen Gleichheit f"ur die
  referenzierten Objekte entlang des Objektgraphen der verglichenen Objekte
  notwendig.
\end{itemize}

\comment{persistente Objektidentit"at, abstraktes Konzept f"ur das es
  verschiedene Realisierungen gibt.}

\begin{figure}[hbt]
\begin{center}
\leavevmode
%\epsffile{Bilder/PostScript/Kopieroperationen.ps}
\caption{Gleichheit, Identit"at und Kopieroperationen im ODMG-Objektmodell}
\label{Gleichheit}  
\end{center}
\end{figure}
    
Zu den verschiedenen Varianten des "Aquivalenzbegriffs auf Objekten gibt es
entsprechende Kopieroperationen (s.a.\ Abbildung \ref{Gleichheit}). Beim
\e{Gleichsetzen} verweisen die beiden Bezeichner danach auf das gleiche Objekt.
Bei einer \e{flachen Kopie} (\e{shallow copy}) Wird ein neues Objekt erzeugt,
das dieselben Werte und Objektidentifikatoren enth"alt, wie das kopierte Objekt.
Bei einer tiefen Kopie wird ebenfalls ein neues Objekt erzeugt, aber im
Gegensatz zur flachen Kopie wird vom ganzen Objektgraph, der vom kopierten
Objekt aus erreichbar ist, eine Kopie erzeugt.

\comment{"Anderungen}

\item [Kapselung:] Das Prinzip der Kapselung ist aus dem Bereich der
  Programmiersprachen bekannt, wo sie meist durch ein geeignetes Modulkonzept
  realisiert ist. Die N"utzlichkeit eines Modulkonzepts zur Strukturierung und
  zur Erh"ohung der Wartbarkeit hat sich in diesem Bereich erwiesen.

  Im Bereich der objektorientierten Datenmodelle ist der Zustand eines Objekts
  gekapselt.  Es kann nur "uber die Methoden des Objekts auf den Zustand
  zugegriffen werden.

  Kapselung unterst"utzt eine Art von logischer Datenunabh"angigkeit (vgl.
  Abschnitt \ref{Datenunabhaengigkeit durch Schemaarchitekturen}), die
  Realisierung des Objekttyps und die Implementierung der Methoden kann
  ver"andert werden, ohne da"s eine Anpassung der Anwendungsprogramme, die
  Objekte dieses Typs benutzen, notwendig wird.

  Durch die Kapselung ist sichergestellt, da"s nur "uber die daf"ur
  vorgesehenen Methoden auf den Zustand eines Objekts zugegriffen werden kann.
  Integrit"ats"uberwachung und Zugriffskontrolle k"onnen daher im Rahmen der
  Methoden durchgef"uhrt werden.

  Man spricht von \e{strikter Kapselung}, wenn ausschlie"slich "uber die
  Methoden auf den Zustand (die Attribute) eines Objekts zugegriffen werden
  kann. Unter gewissen Umst"anden ist es sinnvoll, eine Verletzung der
  Kapselung zuzulassen.  Dies ist z.B. im Bereich des rein lesenden Zugriffs
  (Anfragesprache) der Fall.

\item [Typen und Klassen:]

Unterscheidung der beiden Begriffe nach Anwendungszeitpunkt

\begin{itemize}
\item Ein \e{Typ} legt die Struktur seiner Elemente und die zul"assigen
  Wertebereiche fest. Die Typinformation wird zur "Ubersetzungszeit eingesetzt,
  Zweck: Vermeidung von Laufzeitfehlern, Wahl von Speicherungsstrukturen und
  Optimierungen

\item Extensionsverwaltung

  Die Klassseninformation wird zur Laufzeit verwendet, z.B. zum "Uberpr"ufen der
  aktuell existierenden Objekte
\end{itemize}


\item [Vererbung:] Klasssen k"onnen in Subklassenhierarchien angeordnet werden,
  Die Subklassen erben dabei die Attribute und Methoden ihrer Superklassen. Die
  Attribute und Methoden k"onnen in der Subklasse redefiniert werden.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/17.eps}
\caption{Vererbung im E/R-Diagramm}
%\label{}  
\end{center}
\end{figure}

  Vererbung ist ein m"achtiges Modellierungskonzept zur Beschreibung von
  Gegebenheiten der realen Welt. In der realen Welt existierende
  \e{Is-a}-Beziehungen lassen sich durch Subklassenbeziehungen ad"aquat
  darstellen. Im relationalen Modell k"onnen solche Beziehungen nur indirekt
  repr"asentiert werden, wodurch ihre eigentliche Semantik weitgehend verloren
  geht.  Weiterhin unterst"utzt die Vererbung die Wiederverwendung von
  Definitionen und Implementationen unter Ber"ucksichtigung der
  Klassenunterschiede.

\comment{Subtypisierung}

Speziellere Elemente (mehr oder verfeinerte Attribut) oder Objekte die eine
bestimmte Einschr"ankung (Pr"adikat) erf"ullen. Im zweiten Fall ist durch
"Uberpr"ufung des entsprechenden Pr"adikats eine automatische Verwaltung der
Subklassenextension m"oglich.

Eine Subklassenbeziehung zwischen zwei Klassen impliziert eine 
Inklusionsbeziehung zwischen ihren Extensionen. Jedes Objekt 
einer Subklassse ist auch eine Instanz aller Superklassen. 

Es ist auch m"oglich, zu einer Klasse mehrere direkte Superklassen 
zuzulassen. Man spricht dann von \e{Mehrfachvererbung}, da Vererbung 
von allen Superklassen an die betrachtete Klasse stattfindet. 

\item [Methodenredefinition und sp"ate Bindung:] F"ur die Methode einer Klasse
  kann es unterschiedliche Implementierungen geben (\e{overloading}).  In
  Subklassen k"onnen zus"atzlich Methoden redefiniert werden (\e{overriding})
  und erhalten so Vorrang vor der ererbten gleichnamigen Methodenimplementierung
  der entsprechenden (transitiven) Superklasse.  

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/45.eps}
\caption{Methodenredefinition}
%\label{}  
\end{center}
\end{figure}

  In Abh"angigkeit von der Klassenzugeh"origkeit eines Objektes wird zur
  Laufzeit eine Implementierung f"ur eine "uberladene Methode ausgew"ahlt.  Dazu
  mu"s das Klassenobjekt (Metaobjekt) konsultiert und die Klassenhierarchie
  travesiert werden.  Von der Auswahl einer konkreten Implementierung der Klient
  einer Methode abstrahieren.

\item [Erweiterbarkeit:] Der Benutzer kann neue Typen definieren.

\item [Beziehungen zwischen Klassen:] \comment{Subklassenbeziehungen}

  Assoziationen zwischen Klassen, Obwohl es auch Ans"atze gibt, die ein eigenes
  Konstrukt f"ur die Dartstellung von Assoziationen vorschlagen \cite{}, werden
  bei den meisten Vorschl"agen Assoziationen durch Attribute eines Objekts, die
  als Attributtyp eine Klasse besitzen, repr"asentiert.

  Wenn das explizite L"oschen von Objekten erlaubt ist, k"onnen Probleme mit
  der referentiellen Integrit"at auftreten, da noch Referenzen auf das
  gel"oschte Objekt existieren k"onnen. Es gibt f"ur diese Situation
  verschiedenen Techniken, die in Abschnitt \ref{Beziehungen zwischen Typen}
  beschrieben werden.  Referentielle Integrit"at.
\end{description}

Hinzu kommen eine Reihe von Anforderungen an die Systemfunktionalit"at eines
objektorientierten Datenbanksystems, die die algorithmische Vollst"andigkeit,
das Persistenzkonzept, die Sekund"arspeicherverwaltung den Mehrbenutzerbetrieb
(\e{Concurrency}), die Fehlererholung und die Unterst"utzung f"ur ad hoc
Anfragen betreffen. Diese Aspekte sind jedoch f"ur die Diskussion der
objektorientierten Datenmodellierung im Rahmen dieses Abschnitts nicht relevant
und werden deshalb hier nicht weiter diskutiert. Einige dieser Aspekte, wie
z.B. die Persistenz, werden jedoch im Rahmen der Vorstellung des ODMG-Vorschlags
in Abschnitt \ref{Ueberblick ueber den ODMG-93 Standard} aufgegriffen.

\comment{Wahl des ODMG-Objektmodells Vergleich mit relationalem Modell
  wichtigste Ideen. }

%Vgl. Catell 4.2

\subsubsection{"Uberblick "uber die Konzepte des ODMG-Objektmodells}
\label{"Uberblick "uber die Konzepte des ODMG-Objektmodells}

Das ODMG-Datenmodell basiert auf dem \e{Core Component} Objektmodell der
\e{Object Management Group} (OMG). Dieser Zusammenhang wird in Abschnitt
\ref{Vergleich des ODMG-93 und des OMG Objektmodells} genauer erl"autert.  Die
wichtigsten Konzepte des ODMG-Objektmodells lassen sich wie folgt
zusammenfassen:

\begin{itemize}
\item Das Datenmodell unterst"utzt Werte und Objekte.

\item \e{Objekte} sind Instanzen von \e{Typen} und besitzen eine
  \e{Objektidentit"at}.  Ein Objekt ist unmittelbare Instanz genau eines Typs.

\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.  Der
  Objektzustand ist gekapselt und nur durch die Operationen zug"anglich.

\item Zus"atzlich k"onnen bei der Typdefinition \e{Attribute} f"ur das Objekt
  und \e{Beziehungen} zu anderen Objekten festgelegt werden.

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

\item Es gibt eine vordefinierte ODMG-Typhierarchie, die vom Benutzer durch
  Einf"uhrung neuer Subtypen beliebig erweitert werden kann.

\item Zu einem Typ kann optional eine \e{Extension} verwaltet werden, in die
  Objekte dieses Typs bei ihrer Erzeugung automatisch eingef"ugt werden.

\item Zu einem Typ kann es mehrere Implementierungen geben. Eine Typdefinition
  zusammen mit einer seiner Implementierungen wird als \e{Klasse} bezeichnet.

\item Es wird ein \e{orthogonales Persistenzkonzept} unterst"utzt.  Beliebige
  Objekte k"onnen persistent gespeichert werden.

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

\subsubsection{ODMG-Objekttypen}
\label{ODMG-Objekttypen}

Im ODMG-Standard wird eine Reihe von Typen vordefiniert, die in einer
Subtyphierarchie angeordnet sind (\e{vordefinierte Typhierarchie}).  Diese
Typhierarchie besteht aus zwei Subtyp\-b"aumen. Neben einem Baum f"ur die
benennbaren Objekten (\p{Denotable\_Object}) enth"alt sie einen weiteren f"ur
die ODMG-Datenmodellkonstrukte.  Da das ODMG-Objektmodell eine klare
Unterscheidung zwischen \e{Objekten} und \e{Werten} unterst"utzt, besteht der
Baum der benennbaren Objekte aus einem Teilbaum mit Typen f"ur Objekte und
einem mit Typen f"ur Werte\footnote{Zur Unterscheidung zwischen Objekten und
  Werten siehe Abschnitt \ref{Abstraktionsmechanismen zur Datenstrukturierung}}.

Die Subtypen von \p{Denotable\_Object} umfassen unter anderem die "ublichen
Basisdatentypen sowie Typen f"ur strukturierte Daten, f"ur verschiedene Arten
von Kollektionen, f"ur Iteratoren und f"ur Ausnahmen.  Eine ausf"uhrlichere
Beschreibung der vordefinierten Typhierarchie findet sich in Abschnitt
\ref{Ueberblick ueber die vordefinierte ODMG-Typhierarchie}.

Die vordefinierte Typhierarchie kann vom Benutzer durch die Einf"uhrung neuer
Subtypen erweitert werden. Bei der Typdefinition werden die \e{Eigenschaften}
f"ur die Objekte dieses Typs festgelegt. Das sind die Attribute, die
Assoziationen zu anderen Objekttypen und die Signaturen der Methoden f"ur
Objekte dieses Typs. Die Einordnung eines Typs in die existierende
Typhierarchie geschieht durch die Auswahl eines oder mehrerer Typen der
Hierarchie als direkte Supertypen. Von diesen ererbt der neu definierte Typ
s"amtliche Eigenschaften. Zu einem Typ kann optional eine benannte Menge all
seiner Instanzen verwaltet werden. Diese Menge wird als \e{Extension} des Typs
bezeichnet.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/47.eps}
\caption{Zustand der Firmendatenbank(ODMG-Objektmodell)}
\label{Objektmodell: Zustand der Datenbank}
\end{center}
\end{figure}



Abbildung \ref{Objektmodell: Zustand der Datenbank} zeigt einen Zustand der
Projektdatenbank im Objektmodell. F"ur die Projektdatenbank werden die
ODMG-Typen \p{Abteilung} und \p{Projekt} definiert.  Die Datenbank besteht aus
einem Aggregat mit zwei benannten Kollektionen \p{projekte} und \p{abteilungen}
als Komponenten. Diese Kollektionen sind die Extensionen der beiden Objekttypen
\p{Projekt} und \p{Abteilung}.  Die Kollektionen enthalten Referenzen auf die
Objekte (Objektidentifikatoren), die als Instanzen des entsprechenden
Objekttyps aktuell existieren.  Die einzelnen Objekte sind Aggregate, die sich
aus den Eigenschaften des Objekts zusammensetzen:

\begin{itemize}
\item Die \e{Attribute} der Objekte k"onnen selbst wieder Kollektionen oder
  Aggregate sein, die sich mit beliebiger Schachtelungstiefe aus den Basistypen
  zusammensetzen. Im Beispiel treten allerdings nur atomare (flache)
  Attributwerte auf.

\item Die \e{Assoziationen} sind Komponenten des Aggregats, die eine Referenz
  oder einer Kollektion von Referenzen auf andere Objekte als Werte besitzen.
  Dies dient der Darstellung von Beziehungen eines Objekts zu anderen Objekten
  (s. Abschnitt \ref{Assoziationen im ODMG-Objektmodell}),
  einem einzelnen Objekt, wie z.B. einer \p{Abteilung} zu ihrer
  \p{Oberabteilung} bzw. zu einer Kollektion von Objekten wie bei einem Projekt
  zu den dies Projekt betreuenden Abteilung (\p{Betreuung}).

\item Die \e{Methoden} der Objekte sind ebenfalls Teil der Datenbank, aber in
  Abbildung \ref{Objektmodell: Zustand der Datenbank} der "Ubersichtlichkeit
  halber nicht dargestellt.
\end{itemize}


Ein Objekttyp ist mit der Schnittstelle eines Abstrakten Datentyps oder einer
Modulschnittstelle vergleichbar. Er legt den extern sichtbaren Teil seiner
Objekte fest. Die Repr"asentation der Objekte und die Realisierung der Methoden
werden in der Implementierung des Objekttyps definiert, zu deren Realisierung
eine objektorientierte Programmiersprache wie C++ oder Smalltalk verwendet wird
(vgl. C++- und Smalltalk-Sprachanbindung, Abschnitt \ref{Ueberblick ueber die
  ODMG-93 C++ Sprachanbindung}).  Zu einem Objekttyp kann es dabei eine oder
mehrere Implementierungen geben.  Eine Typdefinition zusammen mit einer
Implementierung wird im ODMG-Modell als \e{Klasse} bezeichnet.

\subsubsection{Assoziationen im ODMG-Objektmodell}
\label{Assoziationen im ODMG-Objektmodell}

Objektorientierte Modelle verwenden referentielle Indentifikatoren. Im
Gegensatz zum relationalen Modell geschieht daher die Darstellung von
Beziehungen zu anderen Objekten nicht wertbasiert durch die Verwendung von
Fremdschl"usseln (s. Abschnitt \ref{Assoziationen im relationalen Modell}),
sondern durch Referenzen auf die Objekte. Insbesondere werden bei
objektorientierten Ans"atzen zu diesem Zweck die eindeutige
Objektidentifikatoren verwendet, die vom Zustand des Objekts unabh"angig sind.

Die Existenz von Objektidentit"aten und die Verwendung von Objektreferenzen zur
Repr"asentation von Beziehungen zwischen Objekten pr"agen die Struktur
objektorientierter Datenbanken und sind f"ur deren erhebliche Abweichung von
der Struktur relationaler Datenbanken, die ein Vergleich der Abbildungen
\ref{Zustand Datenbank (RDM)} und \ref{Objektmodell: Zustand der Datenbank}
zeigt, verantwortlich.

Assoziationen werden "ahnlich wie Attribute definiert. Es wird ein Bezeichner
zum Traversieren der Beziehung und der Typ der assoziierten Objekte festgelegt.
Im Gegensatz zu den Wertattributen besitzen diese speziellen Attribute
Referenzen auf andere Objekte als Werte. Dabei ist sowohl eine einzelne
Referenz als auch eine Kollektion solcher Referenzen m"oglich.

Zur Darstellung einer bin"aren 1:1-Beziehungen zwischen zwei
Objekttypen \p{A} und \p{B} wird zu einem Objekt des Typs \p{A} der
Identifikator des assoziierten Objekts vom Typ \p{B} angegeben und
umgekehrt. Als Beispiel sei hier die Beziehung einer Abteilung zu ihrem
Leiter betrachtet: Bei Darstellung beider Richtungen der Beziehung
besitzt jede Abteilung eine Referenz auf ihren Leiter und jeder Leiter
eine Referenz auf die von ihm geleitete Abteilung.

Bei 1:n-Beziehungen h"angt die Modellierung von der betrachteten
Richtung ab.  Wenn nur eine Richtung einer Beziehung dargestellt wird,
verwendet man je nach gew"ahlter Richtung eine einzelne Referenz oder
eine Kollektion von Referenzen. So kann man zur Darstellung der
Abteilungshierarchie entweder zu jeder Abteilung ihre Oberabteilung
oder die Kollektion (Liste) ihrer Unterabteilungen angeben. Zur
Modellierung einer bidirektionalen 1:n-Beziehung zwischen dem
Objekttyp \p{A} und \p{B} gibt man entsprechend zu einem Objekt vom
Typ \p{A} die \e{n} Identifikatoren der assoziierten Objekte des Typs
\p{B} an und zu einem Objekt vom Typ \p{B} den Identifikator des
assoziierten Objekts vom Typ \p{A}.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/48.eps}
\caption{Assoziationen im ODMG-Objektmodell}
%\label{}  
\end{center}
\end{figure}

Wie am Beispiel der Beziehung zwischen Projekten und Abteilungen zu sehen ist,
wird zur bidirektionalen Modellierung einer n:m-Beziehung in beiden Richtungen
eine Kollektion von Objektidentifikatoren ben"otigt (s. Abbilldung
\ref{ODL-Definition Projektdatenbank}).  F"ur jedes Projekt kann man "uber den
Bezeichner \p{Abteilungen} auf die Kollektion der betreuenden Abteilungen
zugreifen. In umgekehrter Richtung kann bei einer Abteilung "uber den Bezeichner
\p{Projekte} die Kollektion der betreuten Projekte referenziert werden. Wenn nur
eine Richtung der Assoziation unterst"utzt werden soll, z.B. f"ur den Zugriff
von den Projekten auf die Abteilungen, gen"ugt es zu jedem Projekt die
Identifikatoren der assoziierten Abteilungen in einer Kollektion anzugeben. Der
Identifikator einer Abteilung \p{a} kann dabei in mehreren Kollektionen
auftauchen, wie dies f"ur die Darstellung einer n:m-Beziehung notwendig ist.

Zur Definition von Assoziationen werden im ODMG-Objektmodell spezielle
Attribute verwendet, die im Gegensatz zu den Wertattributen Referenzen auf
Objekte enthalten.  Ein solches Attribut kann eine Objektreferenz oder eine
Kollektion solcher Referenzen als Wert besitzen.  Um ein Traversieren einer
Beziehung in beide Richtungen zu erm"oglichen, mu"s sie in beiden Richtungen
definiert werden. Die Beschr"ankung auf eine der Richtungen der Beziehungen hat
Konsequenzen f"ur den Zugriff (Traversieren).
 
Bei n:m-Beziehungen werden zur Darstellung jeder der beiden Richtungen der
Assoziation Kollektionen von Identifikatoren ben"otigt. Ein Beispiel f"ur eine
n:m-Beziehung ist die Assoziation zwischen den Projekten und den Abteilungen,
die an ihnen beteiligt sind. Wenn nur eine Richtung dargestellt werden soll,
z.B. f"ur den Zugriff von den Projekten auf die Abteilungen, gen"ugt es, zu
einer Abteilung die Kollektion der Identifikatoren der beteiligten Objekte
anzugeben. Der Identifikator einer Abteilung a kann dabei in mehreren
Abteilungen auftauchen, wie dies f"ur die Darstellung einer n:m-Beziehung
notwendig ist.

Eine genauere Beschreibung der Definition von Beziehungen findet 
sich in Abschnitt \ref{Beziehungen zwischen Typen}. 

\comment{evtl hier noch etwas zu Subtypbeziehungen}

\subsubsection{Datendefinition im ODMG-Objektmodell}
\label{Datendefinition im ODMG-Objektmodell}

Der ODMG-Standard spezifiziert eine Sprache ODL zur Definition 
von Schemata, die mit dem ODMG-Objektmodell konform sind. 
Unter Verwendung dieser Sprache kann die Schemadefinition f"ur die
Projektdatenbank wie in Abbildung \ref{ODL-Definition Projektdatenbank} 
dargestellt aussehen.  

\begin{figure}
\hrule \medskip
\footnotesize{
\begin{xple}
\key{interface} Projekt
( \key{extent} projekte
  \key{keys} Nr)
$\{$ \key{attribute Unsigned Short} Nr;
  \key{attribute String} Titel;
  \key{attribute Signed Long} Budget;
  \key{relationship Set}$<$Abteilung$>$ Betreuung
    \key{inverse} Abteilung::Projekte;
$\}$;

\key{interface} Abteilung
( \key{extent} abteilungen
  \key{keys} Kurz)
$\{$ \key{attribute String }Kurz;
  \key{attribute String }Name;
  \key{relationship Set}$<$Projekt$>$ Projekte 
    \key{inverse} Projekt::Betreuung;
  \key{relationship} Abteilung Oberabteilung;
  \key{Boolean} neuesProjekt(\key{in} Projekt p) \key{raises} (...)
$\}$;
\end{xple}}
\hrule
\caption{ODL-Schemadefinition der Projektdatenbank}
\label{ODL-Definition Projektdatenbank}
\end{figure}

\subsubsection{Die Anfragesprache OQL}
\label{Die Anfragesprache OQL}

Mit OQL steht im ODMG-Objektmodell wie im relationalen Modell 
mit SQL eine men\-gen\-orientierte, deskriptive Anfragesprache zur 
Verf"ugung. Die Anfragesprache OQL bildet eine Obermenge des
Anfragesprachenanteils von SQL. Die wichtigsten Erweiterungen von OQL 
gegen"uber SQL lassen sich wie folgt zusammenfassen:

\begin{itemize}
\item OQL ber"ucksichtigt \e{Werte und Objekte}. Es k"onnen Anfragen gegen
  Kollektionen von Objekten und Werten gestellt werden, und es sind auch
  Objekte und Werte als Anfrageergebnisse m"oglich.

\item Die Anfragesprache ist nicht so sehr auf eine Kollektionsart fokussiert,
  wie dies bei SQL mit den Relationen der Fall ist. So sind in OQL z.B.\ 
  Anfragen auf \e{verschiedene Arten von Kollektionen} (Mengen, Multimengen,
  Listen, Felder) m"oglich.

\item OQL weist eine \e{h"ohere Sprachorthogonalit"at} auf. Die Konstrukte der
  Anfragesprache, deren Kombination in SQL einer Reihe von Einschr"ankungen
  unterliegt, sind in OQL frei kombinierbar.

\item Das ODMG-Objektmodell ist im Gegensatz zum relationalen Modell nicht auf
  flache Tupel beschr"ankt, sondern unterst"utzt \e{beliebig tief geschachtelte
    Strukturen}. Der Zugriff auf Komponenten tiefer geschachtelter Strukturen
  erfordert \e{l"angere Pfadnamen} in OQL-Anfragen.  So wird "uber den Ausdruck
  \p{a.Oberabteilung.Name} auf den Namen der Oberabteilung einer Abteilung
  \p{a} zugegriffen.

\item In OQL-Anfragen k"onnen neben einem Satz vordefinierter Funktionen
  beliebige Methoden aufgerufen werden. Dies f"uhrt zu einer erheblichen
  Ausdrucksm"achtigkeit der Sprache.
\end{itemize}

Die folgende OQL-Anfrage ermittelt, wie die entsprechende SQL-Anfrage 
in Abschnitt \ref{Die Anfragesprache SQL}, die Titel aller Projekte, 
an denen die Abteilung \p{Mainframe SW} arbeitet. 

\begin{xple}
\key{select} p.Titel 
\key{from} projekte p
\key{where exists} a \key{in} p.Betreuung : a.Name = 'Mainframe SW'
\end{xple}

Wegen der direkten Darstellung der Beziehung zwischen den Projekten und
den Abteilungen, von denen es betreut wird, ist hier im Gegensatz
zur SQL-Anfrage  keine Join-Operation notwendig.
Auf die Abteilungen, die das Projekt \p{p} betreuen, kann einfach 
"uber den Ausdruck \p{p.Betreuung} zugegriffen werden.  
Dies f"uhrt zu einer erheblichen Vereinfachnug der Anfrage. 

\subsubsection{Aktualisierungsoperationen im ODMG-Objektmodell}
\label{Aktualisierungsoperationen im ODMG-Objektmodell}

In Abschnitt \ref{Aktualisierungsoperationen in SQL} werden grundlegende
Klassen von Modifikationsoperationen auf Datenbanken diskutiert, die in
datenmodellspezifischer Form in jedem Datenmodell zu finden sind. Dies sind
Operationen zum Einf"ugen, L"oschen und Modifizieren von Daten der Datenbank.
Im ODMG-Ansatz treten diese Operationen sowohl f"ur Objekte als auch f"ur
Assoziationen zwischen Objekten auf. Die Operationen auf Beziehungsstrukturen
sind dabei stets einem konkreten Objekt zugeordnet und manipulieren die
Assoziationen, an denen dies Objekt beteiligt ist. Bei bidirektionalen
Beziehungen\footnote{Bidirektionale Beziehungen m"ussen nicht nur in beide
  Richtungen definiert, sondern auch durch die \ky{inverse}-Klausel miteinander
  verbunden sein.} bewirken die Operationen unabh"angig von ihrer Zuordnung zu
einem konkreten Objekt eine Aktualisierung beider Richtungen der Assoziation.
Im ODMG-Objektmodell sind die folgenden Operationen definiert:

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/52.eps}
\caption{Zustand der Firmendatenbank nach einer Aktualisierungsoperation}
%\label{}  
\end{center}
\end{figure}

\begin{description}
\item [Einf"ugen:] Die Extensionen der Typen repr"asentieren die
  Massendatenstrukturen im ODMG-Objektmodell, in denen die Objekte des Typs
  verwaltet werden.  Das Einf"ugen von Objekten in Extensionen geschieht
  automatisch bei der Objekterzeugung. Die Einf"ugeoperation tritt in diesem
  Fall also als Teilfunktionalit"at der Operation zur Objektgenerierung auf.

  Beim relationalen Modell ist die Datenbank mit den Relationen auf die
  persistente Speicherung solcher Massendatenstrukturen beschr"ankt.  Aufgrund
  des orthogonalen Persistenzkonzepts k"onnen beim ODMG-Objektmodell beliebige
  Objekte persistent gemacht und damit in die Datenbank eingef"ugt werden.

  Zum Einf"ugen neuer Beziehungen existieren Operationen die ein Objekt mit
  einem einzelnen Objekt oder einer Menge von Objekten des assoziierten Typs in
  Beziehung setzen.

\item[L"oschen:] Jedes Objekt besitzt eine Methode \p{delete}, die vom Supertyp
  \p{Object} aller Objekttypen ererbt wird. Diese Methode l"oscht das Objekt,
  f"ur das sie aufgerufen wird, und macht noch existierende Referenzen auf das
  Objekt ung"ultig.

  Assoziationen zwischen Objekten k"onnen ebenfalls gel"oscht werden.  F"ur ein
  Objekt ist sowohl das L"osen der Beziehung zu einzelnen Objekten
  (\e{selektives} L"oschen) als auch der Beziehungen zu allen assoziierten
  Objekten m"oglich (\e{vollst"andiges} L"oschen).
 
\item [Modifizieren:] Anders als im relationalen Datenmodell gibt es hier keine
  allgemeine Funktion \p{update} f"ur die "Anderung beliebiger Attribute. Zum
  "Andern des Objektzustands existiert zum einen f"ur jedes Attribut eines
  Objekttyps eine vordefinierte Methode \p{setValue}, die redefiniert werden
  kann. Zum anderen kann der Objektzustand durch benutzerdefinierte Methoden
  ver"andert werden.

  Ausgehend von einem konkreten Objekt kann eine Beziehung modifiziert werden,
  wenn dem Objekt nicht nur ein einzelnes Objekt, sondern eine Menge von
  Objekten zugeordnet werden kann (s. Abschnitt \ref{Assoziationen im
    ODMG-Objektmodell}).  Die Operationen zum Erweitern von Beziehungen, die im
  Objektmodell unterst"utzt werden, und auch das im vorigen Punkt beschriebene
  selektive L"oschen bilden Modifikationsoperation auf einer solchen Beziehung.
\end{description}

\begin{xple}
Ref$<$Abteilung$>$ aOID = Abteilungen.select\_element(
  ``\key{select} a \key{in} Abteilungen \key{where} a.Name = $\backslash$``Unix SW$\backslash$'' '');
Ref$<$Project$>$ pOID = Projekte.select\_element(
  ``\key{select} p \key{in} Projekte \key{where} p.Titel = $\backslash$``Telekom Statistik$\backslash$'' '');
aOID.Projekte.insert\_element(pOID);
(* impliziert / "aquivalent zu:
pOID.Abteilungen.insert\_element(aOID);*)
\end{xple}

\subsection{"Uberblick "uber die pr"arelationale "Ara}
\label{Ueberblick ueber die praerelationale Aera}

Die erste Definition des Netzwerkdatenmodells (NDM) wurden etwa zeitgleich mit
den Arbeiten "uber das relationale Modell vorgelegt \cite{}(DBH). Da sich das
Netzwerkdatenmodell jedoch fr"uher in der Praxis durchgesetzt hat, wird es hier
zusammen mit dem hierarchischen Modell unter dem Begriff der \e{pr"arelationalen
  "Ara} zusammengefa"st.  Das hierarchische Modell unterscheidet sich in seiner
Entwicklungsgeschichte deutlich von den anderen Modellen, da es gleichzeitig mit
der Implementierung eines konkreten Systems entwickelt worden ist. Es fand also
nicht wie bei den anderen Modellen die Entwicklung eines konzeptuellen
Datenmodells statt, da"s als Grundlage f"ur sp"atere Systemimplementierungen
benutzt wird.  Das auf dem hierarchischen Modell basierende System IDS fand eine
schnelle Verbreitung.  Neben dem Multi-Access Retrieval System (MARS VI) der
Control Data Corporation und dem System-2000 von MRI gibt es eine Reihe weiterer
System, die nach dem hierarchischen Modell implementiert sind.

Zur Realisierung neuer Systeme werden die beiden pr"arelationalen
Datenbankmodelle kaum mehr eingesetzt, soda"s ihnen in zunehmendem
Ma"se nur noch historische Bedeutung zukommt. Es gibt jedoch in der
Praxis eine gro"se Anzahl sehr umfangreicher Implementierungen, die
auf diesen Modellen basieren und erhebliche Investitionen darstellen,
was noch f"ur einige Zeit f"ur eine hohe Praxisrelevanz dieser Modelle
sorgt.
  
Die restlichen Abschnitte dieses Teils des Kapitels konzentrieren sich auf das
Netzwerkdatenmodell beginnend mit einem zusammenfassenden "Uberblick "uber die
wichtigsten Konzepte in Abschnitt \ref{Ueberblick ueber die Konzepte des
  Netzwerkdatenmodells}. Das zentrale Konzept des Netzwerkdatenmodells zur
Datenstrukturierung, die \e{DBTG-Mengen}, werden im darauffolgenden Abschnitt
beschrieben. Analog zu den "ubrigen Datenmodellen werden in den weiteren
Abschnitten die Darstellung von Assoziationen und die Datendefinition im
DBTG-Modell sowie die Unterst"utzung f"ur Anfrage- und
Aktualisierungsoperationen behandelt.  Der letzte Abschnitt \ref{Das
  Hierarchische Datenmodell} befa"st sich mit dem hierarchischen Datenmodell.
Dieses ist dem Netzwerkmodell sehr "ahnlich, wenn auch mit zus"atzlichen
Einschr"ankungen versehen. Seine Beschreibung ist deshalb sehr kurz gehalten
und beschr"ankt sich auf die wichtigsten Unterschiede und Einschr"ankungen
gegen"uber dem Netzwerkdatenmodell.

\subsubsection{"Uberblick "uber die Konzepte des Netzwerkdatenmodells}
\label{Ueberblick ueber die Konzepte des Netzwerkdatenmodells}

Die Umst"ande seiner Entstehung pr"agen entscheidend die Natur des
Netzwerkdatenmodells (NDM). Die Definition des auch als DBTG-Modell (s.u.)
bezeichneten NDM ist im Rahmen einer Gruppenaktivit"at entstanden, und beruht
nicht, wie das relationale Modell, im wesentlichen auf der Arbeit eines
Einzelnen. In die NDM-Definition fanden zahlreiche Einzelvorschl"age Eingang,
deren Integration nicht immer als gelungen bezeichnet werden kann.  Als Folge
davon sind an der NDM-Definition im Laufe der Zeit zahlreiche wesentliche
"Anderungen vorgenommen worden.  Das urspr"ungliche Modell wurde 1971 von der
\e{Database Task Group} (\e{DBTG}) des \e{CODASYL Systems Committee}
vorgeschlagen.  Zahlreiche "Anderungen und Verbesserungen fanden in die
Berichte aus den Jahren 1978 und 1981 eingang.

Syntaktisch ist die NDM-Definition aufgrund ihrer Erstellung durch die
\e{Database Task Group} (\e{DBTG}) des \e{CODASYL Systems Committee}
stark von COBOL beeinflu"st. Der \glqq wortreiche\grqq\ Stil dieser
Sprache mit seinen vielen Schl"usselworten, Klauseln, und Phrasen hat
die bei der NDM-Definition vorherrschende Tendenz, m"oglichst viele
Einzelanforderungen zu befriedigen, sicher noch unterst"utzt.

Wie das ODMG-Objektmodell beruht auch das NDM auf referentieller
Identifikation. Es gibt auf konzeptueller Ebene eine gewisse
"Ahnlichkeit zwischen den beiden Modellen, aber auch wichtige
Unterschiede und Einschr"ankungen. So fehlt im DBTG-Modell eine
deskriptive, mengenorientierte Anfragesprache, wodurch eine aufwendige
prozedurale, satzorientierte Verarbeitung von Anfragen notwendig ist.
Ein weiterer Punkt sind die zahlreichen implementierungssbedingten
Einschr"ankungen, die die DBTG bei ihrer Modelldefinition eingef"uhrt
hat.  Diese bedingen sowohl im Bereich der Strukturen als auch der
Operationen eine unn"otige Verkomplizierung. Ein Beispiel daf"ur ist
die indirekte Darstellung von bin"aren n:m-Beziehungen.  Weiterhin
fehlt im DBTG-Modell das Konzept der Objektidentit"at und der
orthogonalen Persistenz.  Die Sprachanbindung geschieht durch die
Verwendung eines Kommunikationsbereichs und weist durch die implizite
Manipulation von Aktualit"atszeigern (s. Abschnnitt
\ref{DBTG-Anfrageoperationen}) eine oft schwer durchschaubare Semantik
auf.

Im folgenden werden die wichtigsten Konzepte des Netzwerkmodells
zusammengefa"st:

\begin{itemize}
\item Eine Netzwerkdatenbank besteht aus einer Menge von Rekords, die durch
  Verweise (Zeiger) miteinander verbunden sind.

\item Die Rekords sind mit den Tupeln des relationalen Datenmodells
  vergleichbar. Als Attributwerte sind jedoch auch strukturierte Werte und
  \e{Wiederholgruppen} zur Darstellung mengenwertiger Attribute m"oglich.

\item Die Rekords sind in sogenannten \e{DBTG-Mengen} organisiert.  Eine
  DBTG-Menge enth"alt ein ausgezeichnetes Element, das als \e{Eigner}
  (\e{owner}) der Menge bezeichnet wird, und beliebig viele \e{Mitglieder}
  (\e{member}).

\item Die Definition eines \e{DBTG-Mengentyps} legt einen Rekordtyp \p{A} f"ur
  den Eigner der Menge und einen Rekordtyp \p{B} f"ur die Mitglieder der
  DBTG-Menge fest.

\item In allen DBTG-Mengen, die den gleichen DBTG-Mengentyp besitzen, kann ein
  Rekord nur maximal einmal vorkommen. Ein Rekord kann jedoch in DBTG-Mengen
  verschiedenen Typs vertreten sein.

\item DBTG-Mengen werden sowohl zur Darstellung von Objektmengen als auch zur
  Assoziation von Datenobjekten benutzt.
\end{itemize}

\subsubsection{DBTG-Mengen}
\label{DBTG-Mengen}

Eine DBTG-Menge ist ein Aggregat mit zwei Komponenten.  Die erste Komponente
enth"alt einen Verweis auf den Eigner (\e{owner}) der DBTG-Menge und die zweite
Komponente ist eine Kollektion, die eine beliebige Anzahl von Verweisen auf
Mitglieder (\e{member}) enth"alt.  DBTG-Mengen unterscheiden sich in folgenden
Punkten von mathematischen Mengen:

\begin{itemize}
\item Eine DBTG-Menge ist nicht homogen. Sie enth"alt Elemente von zwei
  verschiedenen Typen.

\item Es gibt ein ausgezeichnetes Element, den Eigner der DBTG-Menge. 

\item Die Mitglieder einer DBTG-Menge sind geordnet.
\end{itemize}

Ein DBTG-Mengentyp ist ein benannter Aggregattyp mit zwei Komponenten.  Bei der
Definition eines DBTG-Mengentyps werden ein Rekordtyp f"ur den Eigner und ein
Rekordtyp f"ur die Mitglieder festgelegt. Zu einem Mengentyp kann es beliebig
viele DBTG-Mengen als konkrete Auspr"agungen geben. Neben dieser allgemeinen
Form der DBTG-Mengen gibt es noch spezielle DBTG-Mengen, bei denen das
\e{System}\footnote{Mit \e{System} ist hier die DBMS Software gemeint.} als
Eigner gew"ahlt wird (\e{system owned sets}). Von dieser Art der DBTG-Mengen
gibt es jeweils nur eine Auspr"agung. Sie werden dazu verwendet, alle Rekords
eines bestimmten Typs in einer Menge zu verwalten. Insbesondere erm"oglicht die
Definition solcher Mengen f"ur einen Rekordtyp die Angabe einer Sortierordnung
auf den Rekords dieses Typs und liefert au"serdem Einstiegspunkte f"ur Anfragen
an die Datenbank.

Die DBTG-Mengen assoziieren ein Datenobjekt (den Eigner) eines Rekordtyp \p{A}
mit einer Menge von Datenobjekten (den Mitgliedern) eines Rekordtyps \p{B}.
Dabei gelten die folgenden Einschr"ankungen:

\begin{enumerate}
\item Ein Rekord kann innerhalb \e{eines} DBTG-Mengentyps nur einmal als
  Mitglied oder Eigner auftreten. Derselbe Rekord kann jedoch in Auspr"agungen
  verschiedener Mengentypen vertreten sein, und zwar sowohl als Eigner als auch
  als Mitglied.

\item Ein Rekordtyp kann nicht zugleich Eigner- und Mitgliedstyp derselben
  DBTG-Menge sein. Dies erschwert insbesondere die Definition rekursiver
  Beziehungen.
\end{enumerate}

Diese Einschr"ankungen haben weitreichende Konsequenzen f"ur die
Datenmodellierung und Datenmanipulation im NDM. Zum einen kann eine DBTG-Menge
durch ihren Eigner und auch durch eines ihrer Mitglieder identifiziert werden,
was beim Navigieren durch eine Netzwerkdatenbank ausgenutzt wird (s.Abschnitt
\ref{DBTG-Anfrageoperationen}). Zum anderen bedingen die Einschr"ankungen die
Einf"uhrung spezieller Rekords, der sog.\ \e{Verbindungsrekords} bei der
Darstellung von rekursiven und von n:m-Beziehungen (s. Abschnitt
\ref{Assoziationen im Netzwerkdatenmodell}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/53.eps}
\caption{Zustand der Firmendatenbank (DBTG-Netzwerkmodell)}
\label{Netzwerkmodell: Zustand der Datenbank}
\end{center}
\end{figure}


Eine Netzwerkdatenbank besteht aus Auspr"agungen der verschiedenen im Schema
definierten Rekordtypen, die in DBTG-Mengen organisiert sind.  Sie ist ein
benanntes Aggregat (Name der Datenbank) mit einzelnen DBTG-Mengen, den
\e{system owned sets} \footnote{Von den \e{system owned sets} gibt es jeweils
  nur eine Auspr"agung}, und Kollektionen von DBTG-Mengen als Komponenten.
Abbildung \ref{Netzwerkmodell: Zustand der Datenbank} zeigt einen Zustand der
Projektdatenbank bei einer Realisierung als Netzwerkdatenbank. Die
Beispieldatenbank enth"alt die \e{system owned sets} \p{Projekte} und
\e{Abteilungen} und die DBTG-Mengen \e{ProjAbt}, \p{AbtProj}, \p{Oberabteilung}
und \p{Unterabteilungen}.

Wie oben bereits erw"ahnt sind die einzelnen DBTG-Mengen selbst wiederum
Aggregate mit zwei Komponenten, einer Referenz auf den Eigner der Menge und
einer Kollektion von Referenzen auf die Mitglieder.  Die Datenbank ist also ein
Aggregat mit Aggregaten und Kollektionen von Aggregaten als Komponenten. Die
DBTG-Mengen \p{PrpjAbt} und \p{AbtProj} besitzen z.B. Elemente vom Typ
\p{Projekt} bzw.\ Abteilung als Eigner und Elemente vom Typ
\p{Projektdurchf"uhrung} als Mitglieder.  Sie dienen der Darstellung der
n:m-Beziehung zwischen Projekten und Abteilungen und werden im N"achsten
Abschnitt genauere behandelt.

Die Mitglieder einer DBTG-Menge sind geordnet und in der Regel durch eine
listen"ahnliche Zeigerstruktur miteinander verkn"upft. Die zweite Komponente
der DBTG-Menge enth"alt daher eine Referenz auf das erste Mitglied, das
wiederum "uber einen Verweis mit dem zweiten Mitglied der DBTG-Menge verkn"upft
ist.  Das letzte Element besitzt eine Referenz auf den Eigner der Menge.  Man
kann eine DBTG-Menge also auch als ein Aggregat aus zwei Referenzen betrachten,
eine auf den Eigner und eine auf das erste Mitglied.

\subsubsection{Assoziationen im Netzwerkdatenmodell}
\label{Assoziationen im Netzwerkdatenmodell}

Assoziationen zwischen Datenobjekten werden im Netzwerkdatenmodell durch die
Definition von geeigneten DBTG-Mengen modelliert.  Das Netzwerkdatenmodell ist
auf die Darstellung von bin"aren 1:n-Beziehungen ausgerichtet, ohne jedoch wie
das hierarchische Datenmodell die Darstellung anderer Beziehungen unn"otig zu
erschweren.  Die 1:n-Beziehungen werden durch die Zuordnung einer Menge von
Rekords zu einem einzelnen Rekord (dem Eigner), wie dies in den DBTG-Mengen
geschieht, optimal unterst"utzt. Bin"are 1:1-Beziehungen lassen sich ebenfalls
direkt durch DBTG-Mengen modellieren, die neben dem Eigner jeweils genau ein
Mitglied besitzen. Die Darstellung der 1:1- und 1:n-Beziehungen entspricht also
im wesentlichen der im ODMG-Objektmodell, nur da"s die Definition einer
Beziehung beim objektorientierten Ansatz als Teil des Typs eines Objekts
geschieht (s. Abschnitt \ref{ODMG-Objekttypen}), w"ahrend im NDM ein eigenes
Konstrukt, die DBTG-Mengen, verwendet wird.

Zur direkten Darstellung von n:m-Beziehungen zwischen zwei Objekttypen \p{A}
und \p{B} durch einen DBTG-Mengetyp \p{AB} mit Eignertyp \p{A} und Mitgliedstyp
\p{B} w"are es notwendig, da"s Rekords vom Typ \p{B} in mehr als einer der
Mengen vom Typ \p{AB} als Mitglied auftreten k"onnten (s. Abbildung
\ref{Netzwerkmodell: Zustand der Datenbank}). Im ODMG-Objektmodell ist diese
Art der Darstellung von n:m-Beziehungen m"oglich (vgl. Abschnitt
\ref{Assoziationen im ODMG-Objektmodell}), im Netzwerkmodell wird sie durch die
erste der im vorigen Abschnitt genannten Einschr"ankungen verhindert.

Zur Darstellung einer bin"aren n:m-Beziehungen werden deshalb sogenannte
\e{Verbindungsrekords}, f"ur die ein zus"atzlicher Rekordtyp definiert werden
mu"s und eine zweite DBTG-Menge ben"otigt. Im Fall der Beziehung zwischen
Projekten und Abteilungen wird f"ur die Verbindungsrekords der Rekordtyp
\p{Projekt\-durch\-fuehrung} eingef"uhrt und die beiden DBTG-Mengen \p{AbtProj}
und \p{ProjAbt} definiert (s. Abbildung \ref{Netzwerkmodell: Zustand der
  Datenbank}).  Um die Beziehung zwischen einem Projekt \p{p} und einer
Abteilung \p{a} darzustellen, wird eine Auspr"agung \p{pd} des Typs
\p{Projekt\-durch\-fuehrung} als Mitglied sowohl in eine Menge vom Typ
\p{ProjAbt} mit dem Projekt \p{p} als Eigner als auch in eine Menge vom Typ
\p{AbtProj} mit der Abteilung \p{a} als Eigner eingef"ugt.

Es exitiert f"ur jedes Paar Abteilung/Projekt ein eigenes Verbindungsrekord,
so da"s sich die Betreuung eines Projekts durch mehrere Abteilungen und die
Beteiligung einer Abteilung an mehreren Projekten ohne Verletzung der
Einschr"ankungen des Modells darstellen lassen. Abbildung xx zeigt diesen
Ansatz schematisch f"ur die Objekttypen \p{A} und \p{B}. Mithilfe der
Verbindungsrekords lassen sich auch n-"are Beziehungen (n$>$2) modellieren, da
ein Verbindungsrekord in verschiedenen DBTG-Mengen (verschiedener Mengentyp)
eingef"ugt werden kann.  Dies erm"oglicht die Verkn"upfung von mehr als zwei
Rekordtypen in einer Beziehung. Eine einfache Erweiterung auf Assoziationen mit
Attributen ist ebenfalls m"oglich, indem das Verbindungsrekord entsprechende
Attribute erh"alt.

Die zweite Einschr"ankung f"ur die DBTG-Mengen f"uhrt dazu, da"s rekursive
Beziehungen nicht direkt dargestellt werden k"onnen, da dies denselben
Rekordtyp f"ur den Eigner und die Mitglieder einer DBTG-Menge erfordert.  Ein
Beispiel daf"ur ist die Abteilungshierarchie. Analog zur Modellierung im
ODMG-Objektmodell bietet es sich an, DBTG-Mengen mit einer Abteilung als Eigner
und ihren Unterabteilungen als Mitgliedern zu definieren.  Aufgrund der
Einschr"ankung ist aber auch hier die Einf"uhrung eines zus"atzlichen
Rekordtyps notwendig.  F"ur die Projektdatenbank wird daf"ur der Rekordtyp
\p{Abteilungshierarchie} definiert. Man ben"otigt dann zwei DBTG-Mengen: eine
Menge \p{Oberabteilung}, mit einer Abteilung als Eigner und einem einzelnen
Rekord vom Typ \p{Abteilungshierarchie} als Mitglied, da"s die Verbindung zur
Oberabteilung herstellt und einer DBTG-Menge \p{Unterabteilungen} ebenfalls mit
einer Abteilung als Eigner und einer Kollektion von Rekords des Typs
\p{Abteilungshierarchie} als Mitglieder, die die Verbindung zu den
Unterabteilungen der Abteilung herstellt. Wenn eine Abteilung \p{a1}
Oberabteilung einer Abteilung \p{a2} ist, wird dies durch ein Verbindungsrekord
\p{ah} vom Typ \p{Abteilungshierarchie} dargestellt, das sowohl in eine Menge
vom Typ \p{Unterabteilungen} als auch in eine DBTG-Menge vom Typ
\p{Oberabteilung} als Mitglied eingef"ugt wird.

\subsubsection{Datendefinition im Netzwerkdatenmodell}
\label{Datendefinition im Netzwerkdatenmodell}

\begin{figure}
\hrule \medskip
\footnotesize{
\begin{xple}
\key{schema name is} ProjektDB.

\key{record name is} Projekt.
\key{location mode is calc using }Nr
    \key{duplicates not allowed}.
  02 Nr  \key{pic} X(5).
  02 Titel  \key{pic} X(30).
  02 Budget  \key{pic} 9999999.99.

\key{record name is} Abteilung.
\key{location mode is calc using }Kurz
    \key{duplicates not allowed}.
  02 Kurz  \key{pic} X(4).
  02 Name  \key{pic} X(30).

\key{record name is} Projektdurchfuehrung.
\key{location mode is via} ProjAbt \key{set}.

\key{record name is} Abteilungshierarchie.
\key{location mode is via} Oberabteilung \key{set}.

\key{set name is} ProjAbt.
\key{order is next}.
\key{owner is} Projekt.
\key{member is} Projektdurchfuehrung \key{optional manual}.

\key{set name is} AbtProj.
\key{order is next.}
\key{owner is} Abteilung.
\key{member is} Projektdurchfuehrung \key{optional manual}.

\key{set name is} Unterabteilungen.
\key{order is next}.
\key{owner is} Abteilung.
\key{member is} Abteilungshierarchie \key{optional manual.} 

\key{set name is} Oberabteilung.
\key{order is next}.
\key{owner is} Abteilung.
\key{member is} Abteilungshierarchie \key{optional manual.} 

\key{set name is} Projekte.
\key{order is sorted}.
\key{owner is system}.
\key{member is} Projekt \key{mandatory automatic
    ascending key is} Nr.

\key{set name is }Abteilungen.
\key{order is sorted}.
\key{owner is system}.
\key{member is} Abteilung \key{mandatory automatic}
    \key{ascending key is} Kurz.
\end{xple}}
\hrule
\caption{Schemadefinition der Projektdatenbank im DBTG-Netzwerkmodell}
\label{Schemadefinition im NDM}
\end{figure}


Abbildung \ref{Schemadefinition im NDM} zeigt eine m"ogliche Definition des
Schemas f"ur die Projektdatenbank. Die Notation orientiert sich an der
Datendefinitionsprache des netzwerkmodellbasierten Datenbanksystems IDMS
(\e{Integrated Database Management System}, s. z.B. \cite{}), das auf dem
DBTG-Vorschlag beruht.  Da das Gewicht dieses Kapitels mehr auf einem
prinzipiellen Verst"andnis der Konzepte liegt, werden die syntaktischen
Einzelheiten der Datendefinition hier nicht n"aher erl"autert.

Bei der Schemadefinition werden zun"achst die Rekordtypen \p{Projekt} und
\p{Abteilung} mit den entsprechenden Attributen zur Darstellung der Objekte der
Anwendung definiert. Die Rekordtypen \p{Projekt\-durch\-fuehrung} und
\p{Abteilungs\-hierarchie} sind die Typen f"ur die Verbindungsrekords, die f"ur
die Modellierung der Beziehungen ben"otigt werden. Sie besitzen keine
Attribute.  Der Definition der Rekordtypen folgt die Definition der
DBTG-Mengentypen f"ur dieses Beispiel. Dies sind die Typen \p{ProjAbt} und
\p{AbtProj} \/ zur Darstellung der n:m-Beziehung zwischen Projekten und
Abteilungen sowie die Typen \p{Unterabteilungen} und \p{Oberabteilung}, die,
wie bereits in Abschnitt \ref{Assoziationen im Netzwerkdatenmodell} erl"autert,
zur Modellierung der Abteilungshierarchie ben"otigt werden. Die letzen beiden
DBTG-Mengentypen der Schemadefintion, \p{Projekte} und \p{Abteilungen} legen
\e{system owned sets} fest. Sie dienen der Verwaltung aller in der Datenbank
vorhandenen Projekte bzw.\ Abteilungen.

Ein wichtige Rolle spielen im Netzwerkmodell die unterschiedlichen
Optionen, die bei der Datendefinition f"ur Rekordtypen und
DBTG-Mengentypen festgelegt werden k"onnen. Diese Angaben umfassen
Sortierordnungen, wie z.B. \key{order is sorted} und \key{ascending
  key is}, Eindeutigkeitsbedingungen (\key{duplicates not allowed})
und Optionen f"ur das Vorgehen beim Einf"ugen und L"oschen von
Datenobjekten, wie z.B.\ \key{optional} und \key{automatic} und haben
unter anderem Auswirkungen auf den Effekt bestimmter
Aktualisierungsoperationen auf der Datenbank. Au"serdem ist es auch
m"oglich bei der Datendefinition die Anordnung von Datenobjekten im
Speicher zu beeinflussen (\key{location mode})\footnote{Dies
  widerspricht der in Abschnitt \ref{Unterstuetzung der Persistenz}
  beschriebenen Forderung nach Datenunabh"angigkeit.}.  Einige der
m"oglichen Optionen sind bei der Schemadefinition in Abbildung
\ref{Schemadefinition im NDM} zu sehen. Auf die Optionen f"ur das
Einf"ugen und L"oschen wird in Abschnitt
\ref{Aktualisierungsoperationen im Netzwerkmodell} kurz eingegangen,
die "ubrigen werden hier nicht n"aher behandelt. Der interessierte
Leser sei auf entsprechende Darstellungen z.B. in \cite{Date}
verwiesen.

%\begin{figure}[hbt]
%\begin{center}
%\leavevmode
%\epsffile{Bilder/PostScript/ProjekteDBTGSchema.ps}
%\caption{Schemadiagramm der Projektdatenbank (DBTG-Netzwerkmodell)}
%\label{Netzwerkmodell: Schemadiagramm der Datenbank}
%\end{center}
%\end{figure}

Aus der Schemadefinition ergibt sich das in Abbildung \ref{Netzwerkmodell:
  Schemadiagramm der Datenbank} dargestellte Schemadiagramm.  Das
Datenbankschema besteht aus den Aggregattypen \p{Projekt}, \p{Abteilung},
\p{Projekt\-durch\-fuehrung} und \p{Abteilungshierarchie}.  Die beiden
letztgenannten Typen besitzen dabei keine Komponenten.  Sie definieren reine
Verbindungsrekords.  Die Aggregattypen \p{Projekt} und
\p{Projekt\-durch\-fuehrung}, sowie \p{Abteilung} und
\p{Projekt\-durch\-fuehrung} sind durch mengenwertige Referenzen miteinander
verbunden. Diese Struktur wird durch die DBTG-Mengentypen \p{ProjAbt} und
\p{AbtProj} festgelegt.  Weiterhin ist der Typ \p{Abteilung} "uber zwei
mengenwertige Referenzen mit dem Typ \p{Abteilugshierarchie} verbunden. Diese
Beziehungen werden durch die DBTG-Mengentypen \p{Unterabteilungen} und
\p{Oberabteilung} spezifiziert. Von der Anwendung her sollte die Beziehung
\p{Oberabteilung} eigentlich einwertig sein. Diese Unterscheidungsm"oglichkeit
wird jedoch durch die Konstrukte des Netzwerkmodells nicht unterst"utzt.

Als Eigner der \e{system owned sets} spielt \p{System} eine besondere Rolle im
Schema einer Netzwerkdatenbank. Es wird bei der Schemadefinition wie ein
vordefinierter Rekordtyp verwendet, der allerdings nur als Eigner von
DBTG-Mengen auftreten kann.  In Abbildung \ref{Netzwerkmodell: Schemadiagramm
  der Datenbank} wird dieser Sonderrolle durch die spezielle Darstellung
Rechnung getragen. \e{System} ist durch mengenwertige Referenzen mit den Typen
\p{Projekt} und \p{Abteilung} verbunden.

\subsubsection{DBTG-Anfrageoperationen}
\label{DBTG-Anfrageoperationen}
 
Im Gegensatz zum relationalen Modell und zum ODMG-Objektmodell mit ihren
deskriptiven, mengenorientierten Anfragesprachen SQL und OQL besitzt das
Netzwerdatenbankmodell eine satzorientierte, prozedurale Anfragesprache.

Zur Formulierung von Anfragen (und f"ur die Datenmanipulation) steht ein Satz
von Kommandos zur Verf"ugung, die in eine Gastsprache (\e{host language})
eingebettet werden. Als Gastsprache sind dabei verschiedene Programmiersprachen
m"oglich. Im folgenden wird die Programmiersprache Pascal als Gastsprache
angenommen. Die Anfrageoperationen unterst"utzen das Auffinden einzelner
Rekords (satzorientierte Sprache), die Iteration "uber Ergebnismengen geschieht
explizit durch die Programmierung von Schleifen in der Gastsprache.


Zur Kommunikation zwischen der Anwendung und dem Datenbanksystem besitzt jedes
Anwedungsprogramm (\e{run unit}) eine \e{user work area} (\e{UWA}). Dies ist
ein Bereich mit Puffer- und Zeigervariablen, auf die sowohl das Datenbanksystem
als auch das Anwendungsprogramm zugreifen k"onnen. Im einzelnen enth"alt die
UWA eines Anwendungsprogramms die folgenden Strukturen:

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/55.eps}
\caption{Kommunikation zwischen Anwendung und DBMS "uber UWA}
\label{Kommunikation zwischen Anwendung und DBMS "uber UWA}
\end{center}
\end{figure}

\begin{description}
\item [Kommunikationsrekords:] Die UWA enth"alt zu jeden im Schema definierten
  Rekordtyp einen \e{Kommunikationsrekord}.  "Uber diese Rekords werden Daten
  zwischen dem Anwendungsprogramm und dem Datenbanksystem ausgetauscht. Der
  Datenflu"s ist dabei in beiden Richtungen m"oglich. So kann das
  Anwendungsprogramm "uber die Kommunikationsrekords Datenwerte f"ur Anfragen
  spezifizieren; zugleich stellt das Datenbanksystem aber auch die Elemente des
  Anfrageergebnisses nacheinander in diesen Rekords f"ur das Anwendungsprogramm
  bereit.

  Bei den meisten DBTG-Systemen wird f"ur die Kommunikationsrekords derselbe
  Bezeichner wie f"ur den zugeh"origen Typ verwendet. Dies f"uhrt zu einer
  unsch"onen Vermischung unterschiedlicher Konzepte.  In den Beispielen in
  diesem Buch werden deshalb f"ur Kommunikationsrekords und Typen zwar der
  gleiche Bezeichner verwendet, zur Unterscheidung jedoch f"ur Typen mit
  gro"sem Anfangsbuchstaben und f"ur die Kommunikationsrekods mit kleinem.

\item [Aktualit"atszeiger:] Neben den Kommunikationsrekords enth"alt die
  \e{UWA} eine Reihe von \e{Aktualit"atszeigern}, die auf ausgezeichnete
  Rekords verweisen. Die Aufgabe der Aktualit"atszeiger ist vergleichbar mit
  der von Hilfszeigern beim Durchlaufen einer Liste in Programmiersprachen. Die
  Aktualit"atszeiger dienen der Kennzeichnung der beim \e{Navigieren} in der
  Netzwerkdatenbank erreichten Position, die als Ausgangspunkt f"ur
  Folgeoperationen benutzt wird.

  In der \e{UWA} wird zu jedem Rekordtyp des Schemas ein Aktualit"atszeiger
  verwaltet, der auf das zuletzt zugegriffene Rekord dieses Typs verweist.
  Weiterhin gibt es zu jedem DBTG-Mengentyp, der im Schema definiert ist, einen
  Aktualit"atszeiger. Dieser verweist auf den Eigner oder eines der Mitglieder
  einer DBTG-Menge, wodurch diese Menge als die aktuelle dieses Typs
  ausgezeichnet wird\footnote{Aufgrund der in Abschnitt \ref{DBTG-Mengen}
    beschriebenen Einschr"ankungen kann eine DBTG-Menge durch ihren Eigner und
    auch durch eines ihrer Mitglieder identifiziert werden.}.  Zus"atzlich gibt
  es einen Aktualit"atszeiger des Programms, der zu jedem Zeitpunkt genau ein
  Rekord der gesamten Datenbank als das aktuelle des Programms auszeichnet.
  Dieses Rekord spielt eine wichtige Rolle bei den Aktualisierungsoperationen
  und wird im folgenden als \e{aktuelles} Rekord bezeichnet.

  Die Aktualit"atszeiger werden nicht explizit manipuliert, sondern implizit
  durch die weiter unten beschriebenen Suchoperationen (\key{find}) umgesetzt.
  Sie sind von zentraler Bedeutung f"ur die Navigation durch die DBTG-Mengen
  der Datenbank.  Die meisten Operationen der DBTG-DML h"angen von der
  aktuellen Position der Aktualit"atszeiger ab und/oder ver"andern diese.

\item [Statusvariablen:] "Uber die Statusvariablen, die ebenfalls Teil der UWA
  sind, kann das Datenbanksystem dem Anwendungsprogramm Statusinformation
  "ubermitteln. Dazu geh"ort unter anderem die Information, ob die letzte
  Datenbankoperation erfogreich abgeschlossen wurde.  In den folgenden
  Beispielen wird f"ur diesen Zweck die Variable \p{DB-Status} benutzt, die
  f"ur den Fall eines erfolgreichen Abschlu"ses der letzten Operation den Wert
  0 enth"alt. Wie in Abbildung \ref{DBTG-Beispielanfrage} zu sehen ist, kann
  diese Variable zur Formulierung der Abbruchbedingung bei der Iteration "uber
  die Elemente eines Anfrageergenisses verwendet werden.
\end{description}

Anfragen gegen Netzwerkdatenbanken sind gepr"agt durch den prozeduralen,
satzorientierten Charakter der Anfragesprache und die explizite Benutzung des
\e{UWA} zum Austausch von Daten und Statusinformation. Eine solche Anfrage
setzt sich konzeptuell aus zwei Schritten zusammen:

\begin{enumerate}
\item Der erste Schritt dient dem \e{Auffinden der Information}. Dazu werden
  mit einer oder mehreren \ky{find}-Operationen die Aktualit"atszeiger geeignet
  positioniert. Ziel dieser Positionierungen ist es, ein Element des
  Anfrageergebnisses (oder einen Kandidaten daf"ur) zum aktuellen Rekord zu
  machen.

  F"ur diese Aufgaben stehen verschiedene Varianten der \ky{find}-Operation zur
  Verf"ugung, die in zwei Gruppen eingeteilt werden k"onnen:

\begin{itemize}
\item Die Operationen der ersten Gruppe dienen zum Suchen innerhalb aller
  Auspr"agungen eines Rekordtyps (\key{find any}, \key{find duplicate}).

\item Die Operationen der zweiten Gruppe unterst"utzen das Navigieren innerhalb
  von DBTG-Mengen. Zu dieser Gruppe geh"oren u.a.\ Operationen f"ur einen
  Zugriff auf den Eigner (\key{find owner within}) und f"ur den sequentiellen
  Zugriff auf die Mitglieder einer DBTG-Menge (\key{find first within}).
\end{itemize}

Eine \ky{find}-Operation macht ein neues Rekord zum aktuellen Rekord, d.h.  der
Aktualit"atszeiger des Programms wird umgesetzt. Zugleich wird der
Aktualit"atszeiger des zugeh"origen Rekordtyps auf dieses Rekord gesetzt und
alle DBTG-Mengen, die dieses Rekord enthalten, werden zur aktuellen Menge ihres
Mengentyps. Die Aktualit"atszeiger dieser DBTG-Mengentypen werden n"amlich auch
auf das neue aktuelle Rekord gesetzt.

\item Der zweite Schritt besteht im \e{Kopieren des Inhalts des aktuellen
    Rekords in das entsprechende Kommunikationsrekord}, wo er dem
  Anwendungsprogramm zur Verf"ugung steht.  Zu diesem Zweck wird die
  \ky{get}-Operation benutzt.
\end{enumerate} 

\begin{figure}
\hrule \medskip
\begin{xple}
\footnotesize{
abteilung.Name := 'Mainframe SW'
\key{find any} Abteilung \key{using} Name

\key{find first} Projektdurchfuehrung \key{within} AbtProj
  \key{while} DB-status = 0 \key{do}
  \key{begin}
    \key{find owner within} ProjAbt
    \key{get} projekt
    \key{print}(projekt.Titel)
    \key{find next} Projektdurchfuehrung \key{within} AbtProj
  \key{end};}
\end{xple}
\hrule
\caption{DBTG-Beispielanfrage}
\label{DBTG-Beispielanfrage}
\end{figure}

Abbildung \ref{DBTG-Beispielanfrage} zeigt den typischen Aufbau einer Anfrage
an eine Netzwerkdatenbank. Als Beispiel wird die gleiche Anfrage wie bei der
Betrachtung von SQL in Abschnitt \ref{Die Anfragesprache SQL} und von OQL in
Abschnitt \ref{Die Anfragesprache OQL} verwendet: Es werden die Titel der
Projekte, an denen die Abteilung f"ur die Mainframe Software arbeitet,
bestimmt.

Zum Auffinden eines einzelnen Ergebniselements werden eine oder mehrere
\ky{find}-Operationen benutzt, die den Aktualit"atszeiger des Programms auf das
Ergebniselement positionieren, gefolgt von einer \ky{get}-Operation, die dieses
Element in das Kommunikationsrekord kopiert. Zur Iteration "uber die Menge der
Ergebniselemente mu"s in der Gastsprache eine Schleife programmiert werden.
Die erste \ky{find}-Operation der Beispielanfrage lokalisiert die Abteilung mit
dem Namen, der dem Datenbanksystem im Kommunikationsrekord \p{abteilung} zur
Verf"ugung gestellt wird. Zugleich macht diese \ky{find}-Operation die
DBTG-Menge vom Typ \p{AbtProj}, in der die lokalisierte Abteilung Eigner ist,
zur aktuellen ihres Typs. Die zweite \ky{find}-Operation lokalisiert das erste
Mitglied dieser DBTG-Menge.  In der \ky{while}-Schleife werden nacheinander die
weiteren Mitglieder dieser Menge abgearbeitet.

Charakteristisch f"ur DBTG-Anfragen ist auch die Navigation in DBTG-Mengen.  In
diesem Beispiel wird vom Eigner einer DBTG-Menge vom Typ \p{AbtProj} zu einem
der Mitglieder dieser DBTG-Menge gegangen\footnote{Dieses ist vom Typ
  \p{Projektdurchfuehrung}.}. Mit der Operation \key{find owner within}
\p{ProjAbt} wird in die DBTG-Menge vom Typ \p{ProjAbt} gewechselt, in der die
betrachtete \p{Projektdurchfuehrung} Mitglied ist, und auf deren Eigner
zugegriffen. Dieser Eigner ist ein Projekt, an dem die betrachtete Abteilung
arbeitet, d.h. eines der gesuchten Ergebniselemente.  Die Navigationsschritte
erf"ullen den gleichen Zweck wie die Join-Operation bei SQL und das Verfolgen
von definierten Assoziationen bei OQL.

\subsubsection{Aktualisierungsoperationen im Netzwerkmodell}
\label{Aktualisierungsoperationen im Netzwerkmodell}

Die im vorigen Abschnitt beschriebenen Operationen \key{find} und
\key{get} dienen dem Auffinden von Information in einer
Netzwerkdatenbank. Dieser Vorgang spielt auch bei den
Aktualisierungsoperationen eine Rolle, da z.B. ein Datenobjekt
lokalisiert werden mu"s, bevor es gel"oscht oder ge"andert werden
kann. Analog zu den Operationen auf den Objekten und Assoziationen
beim ODMG-Objektmodell (vgl. Abschnitt \ref{Aktualisierungsoperationen
  im ODMG-Objektmodell}), wird beim Netzwerkmodell zwischen
Aktualisierungsoperationen auf Rekordebene und auf den DBTG-Mengen
unterschieden. Zur Aktualisierung von Datenobjekten (Rekords) gibt es
wiederum Operationen zum Einf"ugen, L"oschen und Modifizieren:

\begin{description}

\item [Einf"ugen:] Das einzuf"ugende Rekord wird im entsprechenden
  Kommunikationsrekord zusammengestellt und durch eine \ky{store}-Operation in
  die Datenbank eingef"ugt.

\item [L"oschen:] Zum L"oschen eines Rekords wird dieses zun"achst in der
  Datenbank aufgesucht und zum aktuellen Rekord gemacht. Mit der daf"ur
  vorgesehenen Operation \key{erase} wird das aktuelle Rekord aus der Datenbank
  entfernt.

\item [Modifizieren:] Wie beim L"oschen mu"s auch beim Modifizieren das
  betroffene Rekord zu\-n"achst zum aktuellen Rekord gemacht werden. In beiden
  F"allen wird daf"ur eine spezielle Aufsuchoperation (\key{find for update})
  verwendet. Mit der \ky{get}-Operation wird das zu modifizierende Rekord in das
  entsprechende Kommunikationsrekord kopiert, wo es durch Zuweisungsoperationen
  der Gastsprache modifiziert werden kann. Das aktualisierte Rekord wird
  schlie"slich durch einen Aufruf der Operation \key{modify} in die Datenbank
  zur"uckgeschrieben.
\end{description}

Hinzu kommen die Operationen auf den DBTG-Mengen. Dazu geh"oren Operationen zum
Ein\-h"angen eines Rekords in eine DBTG-Menge (\key{connect}), zum Aush"angen
eines Rekords aus einer DBTG-Menge (\key{disconnect}) und zum Umh"angen eines
Rekords von einer DBTG-Menge in eine andere des gleichen Typs (\key{reconnect}).
Vor Ausf"uhrung dieser Operationen werden die Aktualit"atszeiger durch
geeignete \ky{find}-Operationen auf die entsprechenden Rekords und DBTG-Mengen
positioniert.


Bei Aktualisierungsoperationen auf Netzwerkdatenbanken spielen die in
Abschnitt \ref{Datendefinition im Netzwerkdatenmodell} erw"ahnten
Optionen eine wichtige Rolle. Bei der Definition einer DBTG-Menge kann
z.B.\ festgelegt werden, da"s Rekords ihres Mitgliedstyps bei deren
Erzeugung (\key{store}) automatisch in eine DBTG-Menge des definierten
Typs eingeh"angt werden (\key{automatic}). Weiterhin kann das Aus- und
Umh"angen von Rekords zwischen DBTG-Mengen eingeschr"ankt werden.
Dabei ist es m"oglich das Aus- und Umh"angen ganz zu verbieten
(\key{fixed}) oder nur ein Umh"angen innerhalb des gleichen
DBTG-Mengentyps, aber kein Aush"angen zu erlauben (\key{mandatory}),
soda"s ein Mitgliedsrekord stets in einer der DBTG-Mengen des
definierten Typs enthalten ist.

\begin{figure}
\hrule \medskip
\footnotesize{
\begin{xple}
\key{store} projektdurchfuehrung
abteilung.Name := 'Unix SW'
\key{find any} Abteilung \key{using} Name
\key{connect} projektdurchfuehrung \key{to} AbtProj
projekt.Titel := 'Telekom Statistik'
\key{find any} projekt \key{using} Titel
\key{connect} projektdurchfuehrung \key{to} ProjAbt
\end{xple}}
\hrule
\caption{DBTG-Aktualisierungsoperation}
\label{DBTG-Aktualisierungsoperation}
\end{figure}
 
Abbildung \ref{DBTG-Aktualisierungsoperation} zeigt die Realisierung der
bereits in den Abschnitten \ref{Aktualisierungsoperationen in SQL} und
\ref{Aktualisierungsoperationen im ODMG-Objektmodell} betrachteten
Aktualisierungsoperationen im Rahmen des Netzwerkmodells. Ziel der Operation
ist es, eine Beziehung zwischen der Abteilung \p{Unix SW} und dem Projekt
\p{Telekom Statistik} zu etablieren. Dazu wird zun"achst ein Rekord \p{pd} vom
Typ \p{Projektdurchfuehrung} in die Datenbank eingef"ugt (\key{store}). Die
Vorbereitung des Rekords im Kommunikationsrekord \p{projektdurchfuehrung} durch
die Zuweisung von Attributwerten entf"allt hier, da es sich um ein reines
Verbindungsrekord ohne eigene Komponenten handelt. Danach mu"s das Rekord noch
in die entsprechenden DBTG-Mengen eingef"ugt werden. Dies geschieht jeweils in
zwei Schritten.

Im ersten Schritt wir der Eigner der betroffenen Menge, die Abteilung
\p{a} mit dem Namen \glqq Unix SW\grqq\ aufgesucht. Zu diesem Zweck
wird dem Attribut \p{Name} des Kommunikationsrekords \p{abteilung} der
Name der Abteilung zugewiesen und nachfolgend eine entsprechende
\ky{find}-Operation durchgef"uhrt. Diese Operation macht die DBTG-Menge
des Typs \p{AbtProj}, in der die Abteilung \p{a} Eigner ist, zur
aktuellen ihres Typs. Im zweiten Schritt kann dann das Rekord \p{pd}
mit einer \ky{connect}-Anweisung in diese DBTG-Menge eingef"ugt werden.
Das Einh"angen des Rekords \p{pd} in die DBTG-Menge vom Typ
\p{ProjAbt} geschieht analog.
 
\subsubsection{Das Hierarchische Datenmodell}
\label{Das Hierarchische Datenmodell}

Hierarchische Strukturierungen und Benennungsschemata erfreuen sich in vielen
Bereichen des Lebens gro"ser Beliebtheit. Unter anderem sind z.B.
Organisationen aber auch Klassifikationsschemen wie z.B. f"ur Planzen und Tiere
h"aufig hierarchisch organisiert. Auf der Grundlage dieser Tatsache wurde das
hierarchische Modell speziell auf hierarchisch organisierte
Informationsstrukturen ausgerichtet.  Solche Strukturen lassen sich in diesem
Datenmodell besonders einfach modellieren und effizient bearbeiten.  Probleme
ergeben sich jedoch bei der Modellierung von Zusammenh"angen, die von einer
streng hierarchischen Organisation abweichen.

Da das hierarchische Datenmodell dem Netzwerkdatenmodell in vielen Aspekten
sehr "ahnlich ist, beschr"ankt sich dieser Abschnitt auf die wichtigsten
Unterschiede zu diesem Modell.  Ausf"uhrlichere Beschreibungen der Konzepte und
Konstrukte des hierarchischen Datenmodells finden sich z.B. in \cite{}.

Die Strukturierungsprimitiven des hierarchischen Modells sind vergleichbar mit
denen des Netzwerkdatenmodells.  In beiden F"allen besteht die Datenbank aus
Rekords die durch Referenzen miteinander verkn"upft sind. Die starke
Ausrichtung des HDM auf Hierarchien f"uhrt jedoch zu einigen wichtigen
Einschr"ankungen. W"ahrend im NDM (mit gewissen Einschr"ankungen) beliebige
azyklische Graphen aufgebaut werden k"onnen, sind beim HDM nur hierarchische
Strukturen, d.h. Baumstrukturen, zul"assig.

Eine hierarchische Datenbank besteht aus einer Menge von speziellen B"aumen
(Wald), den \e{HDM-B"aumen}. B"aume treten als Datenstrukturen in den
verschiedensten Bereichen der Informatik auf. Meist handelt es sich dabei um
Strukturen, bei denen alle Knoten einem oder h"ochstens zwei unterschiedlichen
Typen (f"ur innere Knoten und Bl"atter) angeh"oren, was eine rekursive
Definition der zugeh"origen Typen erlaubt.  Bei den \e{HDM-B"aumen} handelt es
sich dagegen nicht um homogene Strukturen. Vielmehr treten auf jeder Ebene neue
Rekordtypen f"ur die Knoten auf. Es ist nicht zul"assig, den gleichen Rekordtyp
auf mehreren Ebenen zu verwenden.

Die B"aume, aus denen sich eine hierarchische Datenbank zusammensetzt sind alle
Auspr"agungen desselben \e{HDM-Baumtyps}, der im Rahmen der Schemadefinition
spezifiziert wird. Beginnend mit der Wurzel legt der HDM-Baumtyp die
Rekordtypen f"ur die Knoten jeder Ebene fest. Dabei sind auch auf einer Ebene
verschiedene Knotentypen zul"assig, d.h. ein Knoten kann eine heterogene
Nachfolgermenge besitzen.  Ein HDM-Baumtyp kann beliebig viele Ebenen f"ur
seine Auspr"agungen festlegen. Anders als bei rekursiven Defintionen ist hier
jedoch die Zahl der Ebenen der Auspr"agungen durch die Zahl der in der
Typdefinition spezifizierten Ebenen beschr"ankt.

Zu dem im Schema definierten HDM-Baumtyp kann es beliebig viele Auspr"agungen
geben. Dabei mu"s gelten, da"s jedes Rekord nur einmal in den Baumstrukturen
vorkommt. Dies verbietet jedoch keine zwei wertgleichen Rekords. Solche
Duplikationen von Information lassen sich sogar in vielen F"allen, wie z.B. bei
der Darstellung von n:m-Beziehungen, gar nicht vermeiden. Auf der anderen Seite
mu"s aber auch jedes der Rekords in einem der B"aume enthalten sein, da es
sonst nicht Teil der Datenbank ist. Beim HDM ist die Persistenz also an die
Mitgliedschaft in einem der HDM-B"aume gekoppelt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/60.eps}
\caption{Zustand der Firmendatenbank (HDM-Modellierungsvariante A)}
\label{Hierarchisches Modell: Datenbankzustand A}
\end{center}
\end{figure}


Mit der in Abschnittt \ref{Eine datenmodellunabhaengige Metanotation}
eingef"uhrten, einheitlichen Notation kann eine hierarchische
Datenbank wie folgt beschrieben werden: Sie besteht aus einer
benannten Kollektion (Name der Datenbank) von Aggregaten, den
Wurzelelementen der B"aume. In Abbildung \ref{Hierarchisches Modell:
  Datenbankzustand A}, die einen Zustand der Beispielsdatenbank (ohne
Abteilungshierarchie) bei einer hierarchischen Modellierung zeigt,
bilden die Projekte die Wurzeln der B"aume.  Jedes dieser Aggregate
besitzt Verweise auf eine oder mehrere Kollektionen (f"ur jeden
Nachfolgerknotentyp eine Kollektion) von Aggregaten, die die
Nachfolgerknoten bilden. Im Beispiel existiert jeweils nur eine
Kollektion von Nachfolgerknoten, n"amlich die Kollektion aller
Abteilungen, die an diesem Projekt arbeiten. Von den Aggregaten in
diesen Kollektionen kann wiederum jedes auf eine oder mehrere weitere
Kollektion von Aggregaten verweisen usw., wodurch die n"achste
Baum\-ebene erreicht wird. Im gew"ahlten Beispiel besitzen die B"aume
allerdings neben der Wurzel nur eine einzige Ebene. In der konkreten
Implementierung sind die erw"ahnten Kollektionen in der Regel Listen,
soda"s eine Reihenfolge auf den Elementen der Kollektion definiert
ist.

Augrund der oben beschriebenen Einschr"ankungen ist das HDM bei der
Modellierung von Assoziationen nur f"ur bin"are 1:1- und 1:n-Beziehungen gut
geeignet.  Bin"are 1:n-Beziehungen werden vom HDM direkt unterst"utzt, da in
den Baumstrukturen \p{n} Nachfolgerknoten einem Elternknoten zugeordnet werden.
Indem man sich auf einen Nachfolgerknoten beschr"ankt, lassen sich auch bin"are
1:1-Beziehungen darstellen.  Bei der Modellierung von n:m-Beziehungen, von
n-"aren Beziehungen und auch bereits dann, wenn ein Knotentyp als
Nachfolgerknoten verschiedener Knoten auftritt, ergeben sich jedoch gr"o"sere
Probleme als beim NDM.

\begin{figure}[htb]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/59.eps}
\caption{Schemadiagramme f"ur 
drei Modellierungsvarianten der Projektdatenbank (Hierarchisches Datenmodell)}
\label{Hierarchisches Modell: Schemadiagramme der Datenbank}
\end{center}
\end{figure}

Insbesondere mu"s f"ur die Darstellung einer n:m-Beziehunge zwischen
verschiedenen Modellierungsvarianten gew"ahlt werden, die sich aus der
relativen Anordnung der beteiligten Rekordtypen in der Baumstruktur ergeben.
Abbildung \ref{Hierarchisches Modell: Schemadiagramme der Datenbank} zeigt die
verschiedenen Varianten f"ur die Modellierung der n:m-Beziehung zwischen
Projekten und Abteilungen.  Bei Variante A ist \p{Abteilung} Nachfolgerknoten
von \p{Projekt} (vgl.\ Abbildung \ref{Hierarchisches Modell: Datenbankzustand
  A}), w"ahrend bei der Variante B \p{Projekt} im Baum unterhalb von
\p{Abteilung} angeordnet ist. Der hierarchische Ansatz f"uhrt zu einer
Asymmetrie bei der Darstellung von n:m-Beziehungen, die bei den "ubrigen
betrachteten Datenmodellen nicht auftritt.

Unabh"angig von der gew"ahlten Modellierungsvariante erfordert die Darstellung
von n:m-Beziehungen die Duplizierung von Information, da jedes Rekord nur
h"ochstens einen Eltern\-knoten besitzen darf (Hierarchie!). Die Wahl der
Variante entscheidet jedoch dar"uber, Rekords welchen Typs dupliziert werden
m"ussen und welche Zugriffe auf Daten besonders gut unterst"utzt werden.  So
ist z.B. bei der Modellierungsvariante A der Zugriff auf alle Abteilungen, die
an einem Projekt arbeiten, besonders einfach m"oglich. Ein Zugriff auf alle
Projekte, an denen eine Abteilung arbeitet, erfordert dagegen ein Durchsuchen
der gesamten Baumebene (aller Projekte mit den zugeh"origen Abteilungen).  Die
Wahl der Modellierungsvariante mu"s daher anwendungsabh"angig erfolgen und
setzt eine Kenntnis der bevorzugten Zugriffsarten voraus.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/61.eps}
\caption{Zustand der Projektdatenbank (HDM-Modellierungsvariante B)}
\label{Hierarchisches Modell: Datenbankzustand B}
\end{center}
\end{figure}


Die Notwendigkeit zur Duplizierung von Information bei der Darstellung von
n:m-Beziehun\-gen ist in Abbildung \ref{Hierarchisches Modell: Datenbankzustand
  A} zu sehen, die einen Zustand der Projektdatenbank bei Modellierungsvariante
A darstellt. Die Informationen zu den Abteilungen \p{Leitung SW} und
\p{Mainframe SW} kommen jeweils doppelt in der Datenbank vor, da jede dieser
Abteilungen an zwei Projekten arbeitet. Allgemein m"ussen die Auspr"agungen des
als Nachfolgerknoten gew"ahlten Rekordtyps dupliziert werden, und zwar genau
dann, wenn sie mit mehr als einem Rekord des Elternknotentyps in Beziehung
stehen. Abbildung \ref{Hierarchisches Modell: Datenbankzustand B} zeigt einen
Zustand der Beispieldatenbank bei Modellierungsvariante B. Bei dieser Variante
kommen entsprechend Informationen "uber gewisse Projekte mehrfach in der
Datenbank vor.

In Abbildung \ref{Hierarchisches Modell: Datenbankzustand A} ist noch ein
weiteres Problem hierarchischer Datenbanken zu erkennen. Wenn eine Abteilung,
wie hier die Abteilung \p{PC Software}, aktuell nicht an einem Projekt
arbeitet, kann sie auch nicht in der Datenbank dargestellt werden. Es ergeben
sich also Abh"angigkeiten, die in der Realit"at so nicht existieren: Eine
Abteilung kann auch dann weiter bestehen, wenn sie aktuell nicht an einem
Projekt arbeitet.

Neben dem Speicherplatzbedarf erh"oht die Duplizierung von Information auch die
Gefahr von Inkonsistenzen. Bei Aktualisierungsoperationen auf der Datenbank ist
sicherzustellen, da"s mit einem Datenobjekt zugleich auch alle evtl.\ 
existierenden Kopien ge"andert werden, da die Datenbank sonst inkonsistente
Information enth"alt.

Um die Probleme der Informationsduplizierung und der Asymmetrie bei der
Darstellung von Beziehungen zu umgehen, wurde das Konzept der sog.
\e{virtuellen Rekords} eingef"uhrt \cite{}. Idee ist es dabei, da"s mehr als
ein hierarchisches Schema f"ur eine Datenbank unterst"utzt wird, das hei"st,
da"s der gleiche Datenbestand scheinbar gleichzeitig gem"a"s verschiedener
HDM-Baumtypen organisiert ist.

Die Umgehung einiger der Einschr"ankungen des hierarchischen Datenmodells wird
dabei durch eine zus"atzliche Indirektion erreicht. Anstatt ein Rekord \p{r} zu
duplizieren wird ein \e{virtueller Rekord} eingef"uhrt, der einen Verweis auf
den Rekord \p{r} enth"alt. Der tats"achliche Rekord tritt nur in einem Baum
auf, an allen anderen Stellen werden nur virtuelle Rekords verwendet. von denen
auch mehrere auf dasselbe Datenobjekt verweisen k"onnen. Jedes virtuelle Rekord
kommt wiederum nur einmal in der Datenbank vor. Es kann neben den Verweisen
zus"atzliche Komponenten enthalten, wodurch sich weitere Optionen f"ur die
Modellierung ergeben.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/62.eps}
\caption{Datenbankzustand der Projektdatenbank (HDM-Modellierungsvariante C)}
\label{Hierarchisches Modell: Datenbankzustand C}
\end{center}
\end{figure}

Abbildung \ref{Hierarchisches Modell: Datenbankzustand C} zeigt die
Modellierung der Projektdatenbank unter Verwendung von virtuellen Rekords
(Modellierungsvariante C).  Es werden zwei Hierarchien (HDM-Baumtypen)
unterst"utzt: \p{ProjektDB} und \p{AbteilungsDB}, die den vorher untersuchten
Modellierungsvarianten A und B entsprechen. Die Nachfolgerknoten sind in beiden
Hierarchien durch virtuelle Rekords ersetzt, die auf die eigentliche
Datenobjekte verweisen. Wie man leicht erkennt, vermeidet diese Art der
Modellierung sowohl die Duplizierung von Information als auch die starke
Ausrichtung auf bestimmte Zugriffsarten, die bei den Modellierungsvarianten A
und B vorhanden sind.

Wie ein Vergleich der Abbildung \ref{Hierarchisches Modell: Datenbankzustand C}
mit dem entsprechenden Ausschnitt der Abbildung \ref{Netzwerkmodell: Zustand
  der Datenbank} zeigt, f"uhrt die Verwendung virtueller Rekords zu einer
Ann"aherung des hierarchischen Datenmodells an das Netzwerkdatenmodell. In
einer gewissen Weise sind die virtuellen Rekords mit den Verbindungsrekords des
Netzwerkmodells vergleichbar. Sie dienen ebenfalls alleine der Darstellung von
Beziehungen und brauchen keine Datenkomponenten zu besitzen.

Die Formulierung von Anfragen geschieht im HDM satzorientiert und prozedural
wie im NDM. Es stehen entsprechende Operationen zur Verf"ugung, die in eine
Gastsprache eingebettet werden. Die Kommunikation zwischen der Datenbank und der
Applikation findet ebenfalls wie im Netzwerkmodell "uber eine UWA (\e{user work
  area}. vgl. Abschnitt \ref{DBTG-Anfrageoperationen}) statt.

Wegen der einfacheren Struktur einer hierarchischen Datenbank
(Einschr"ankung auf B"aume) gen"ugen weniger m"achtige Operationen zur
Navigation durch die Datenbank.  Die Funktionalit"at der \ky{find}-
und der \ky{get}-Operation des NDM (vgl. Abschnitt
\ref{DBTG-Anfrageoperationen}) ist in einer Funktion \key{get}
zusammengefa"st, von der es mehrere Varianten gibt. Insbesondere
werden Operationen zum Durchsuchen von Teilb"aumen unterst"utzt.
Anders als beim Netzwerkdatenmodell k"onnen die Suchoperationen
Pr"adikate als Parameter erhalten, die den Suchraum einschr"anken.
Dabei ist es m"oglich, Bedingungen f"ur die Knoten auf dem Pfad zu dem
gesuchten Rekord festzulegen.

Bei den Aktualisierungoperationen kann wie bei den anderen betrachteteten
Datenmodellen zwischen Operationen zum Einf"ugen, L"oschen und Modifizieren
unterschieden werden.  Neue B"aume werden durch Einf"ugen eines neuen Elements
(Rekords) des Wurzelknotentyps erzeugt.  Beim Einf"ugen eines neuen Rekords in
eine Hierarchie wird dessen Position durch Umsetzen der entsprechenden
Aktualit"atszeiger festgelegt. Ein Rekord kann dabei nur nach seinem
Vorg"angerknoten eingef"ugt werden, da die Existenz eines Rekords in der
Datenbank direkt an seine Einordnung in einen der HDM-B"aume gebunden ist
(s.o.). Diese Einschr"ankung erzwingt bestimmte Integrit"atsbedingungen.

Das L"oschen und "Andern von Elementen der Datenbank geschieht wie beim NDM in
zwei Schritten. Im ersten Schritt wird das betroffenen Rekord lokalisiert. Dazu
wird eine spezielle Variante der oben erw"ahnten \ky{get}-Operation benutzt. Im
zweiten Schritt wird eine L"osch- bzw.\ Modifikationsoperation auf dem
aufgesuchten Rekord ausgef"uhrt.  Eine L"oschoperation l"oscht dabei nicht nur
den lokalisierten Rekord, sondern den gesamten Teilbaum, dessen Wurzel dieser
Rekord ist. Die Modifikation von Attributwerten geschieht wie beim NDM im
Kommunikationsrekord durch eine geeignete Zuweisungsoperation der Gastprache
und nachfolgendes Einbringen der "Anderung in die Datenbank.

\subsection{Vergleich der Modelle}
\label{Vergleich der Modelle}

Im direkten Vergleich der betrachteten Modelle schneiden das relationale und
die objektorientierten Modelle deutlich besser ab, als die beiden "alteren
Modelle. Dieser Vorteil spiegelt sich auch in der rasch wachsenden
Praxisverbreitung dieser beiden moderneren Modelle wieder.

Dabei zeichnet sich das relationale Modell besonders durch seine Einfachheit
und die guten formalen Grundlagen aus, w"ahrend beim objektorientierten
Datenmodell besonders die hohe Modellierungsm"achtigkeit und die explizite
Unterst"utzung des Objektbegriffs, der bei objektorientierten Ans"atzen
allgemein zum anwendungsfreundlichen Charakter beitr"agt, hervorzuheben sind.
Sowohl beim relationalen Modell als auch beim Objektmodell f"uhrt die
mengenorientierte, deskriptive Anfragesprache zu einer hohen
Benutzerfreundlichkeit. Beide Modelle verf"ugen au"serdem "uber ein hohes Ma"s
an Datenunabh"angigkeit.

Netzwerkmodell und hierarchisches Modell entsprechen nicht 
mehr den modernen Anforderungen an ein Datenmodell (Datenbanksystem).
Dabei sind besonders die mangelnde Datenunabh"angigkeit, 
die komplexe, schwer durchschaubare Semantik der Navigationsoperationen 
und deren Abh"angigkeit von den Aktualit"atszeigern zu nennen sowie 
die prozeduralen, satzorientierten Anfragesprachen, 
die dem Benutzer die Kontrolle der Iteration aufb"urden.
Beim hierarchischen Modell kommt erschwerend die 
eingeschr"ankte Modellierungsm"achtigkeit hinzu.

Um einen direkten Vergleich der unterschiedlichen Modelle zu erleichtern,
werden in Tabelle \ref{Vergleich Modelle} noch einmal die wichtigsten Aspekte
der einzelnen Modelle in tabellarischer Form gegen"ubergestellt.

\newpage

\begin{table}
\begin{center}
\begin{tabular}[htb]{|l|c c c c|}
\multicolumn{1}{c}{}
&\multicolumn{1}{c}{\bf{Relationales}} & \multicolumn{1}{c}{\bf{ODMG-}}   
& \multicolumn{1}{c}{\bf{Netzwerk-}} & \multicolumn{1}{c}{\bf{Hierarchisches}} \\
\multicolumn{1}{c}{}
& \multicolumn{1}{c}{\bf{Modell}}      & \multicolumn{1}{c}{\bf{Objektmodell}}
&  \multicolumn{1}{c}{\bf{datenmodell}}   & \multicolumn{1}{c}{\bf{Datenmodell}}           \\
\multicolumn{5}{c}{}\\
\cline{2-5}
\hline
\multicolumn{1}{|c}{}&\multicolumn{4}{c|}{\bf{Identifikation}}\\
\cline{2-5}
& assoziativ & referentiell & referentiell & referentiell \\
\hline
\multicolumn{5}{c}{}\\
\hline 
\multicolumn{1}{|c}{}&\multicolumn{4}{c|}{\bf{Attribute}}\\
\cline{2-5}

{\bf Aggregation}     & Tupel            & Attribute des    &  Rekords    & Rekords  \\
{\bf von Attributen}  &                  & Objekttyps      &             &          \\
\hline
{\bf zusammen-}       &  keine               & Strukturierter   & Wiederhol-  &   - \\
{\bf gesetzte}        &  Modellierungs-               & Attributtyp      & gruppen     &     \\
{\bf Attribute}       & unterst"utzung  & & & \\
\hline
{\bf mengenwertige}   & eigene           &  Kollektionstyp  & Wiederhol-  &  \\
{\bf Attribute}       & Relation         &  als Attributtyp & gruppen     & \\
\hline
\multicolumn{5}{c}{}\\
\hline
\multicolumn{1}{|c}{}&\multicolumn{4}{c|}{\bf{Darstellung von Assoziationen}}\\
\cline{2-5}
{\bf generell} & Fremdschl"ussel  &  Referenzen      & DBTG-       & HDM- \\
          &                  &  auf Objekte     & Mengen      & Baumstrukturen\\
\hline
{\bf 1:1}       & als Attribut     & einzelne         & DBTG-Menge  & HDM-Baum\\  
          & einer beteiligten& Referenzen       & (ein Mitglied\footnote{kann nicht erzwungen werden}) 
                                                              & (ein Nachfolger) \\
          & Relation & & & \\
\hline
{\bf 1:n}       &                  & Kollektion       & DBTG-Menge  & HDM-Baum \\
          &                  & von Referenzen   &             & \\
\hline
{\bf n:m}       & eigene Relation  & Kollektionen     & Verbindungsrekord  &  Duplizierung \\
          & 2 Fremdschl"ussel& von Refrenzen    & + 2 DBTG-Mengen    & von Daten bzw. \\
          &                  &                  &                    & virt. Rekords \\
\hline
{\bf n-"are}    & Relation mit n   & eigener          &  Verbindungsrekord & Duplizierung \\
{\bf (n $>$ 2)} & Fremdschl"usseln & Objekttyp        &  + n DBTG-Mengen   & von Daten bzw. \\
          &                  &                  &                    & virt. Rekords \\
\hline 
\multicolumn{5}{c}{} \\
\hline
\multicolumn{1}{|c}{}&\multicolumn{4}{c|}{\bf{Anfragesprachen}}\\
\cline{2-5}

&
                  deskriptiv       & deskriptiv       & prozedural     & prozedural \\
                & mengenorientiert & mengenorientiert & satzorientiert & satzorientiert \\
\hline
\multicolumn{5}{c}{}\\
\hline
\multicolumn{1}{|c}{} &\multicolumn{4}{c|}{\bf{Strukturen f"ur Massendaten}}\\
\cline{2-5}
 &  Relationen      & Extensionen      & DBTG-            & HDM-           \\
 &                  & von Objekttypen  & Mengen          & Baumstrukturen \\ 
\hline
\end{tabular}
\end{center}
\caption{Vergleich der Modelle}
\label{Vergleich Modelle}
\end{table}