\section{Die relationale Datenbanksprache SQL}
\label{Die relationale Datenbanksprache SQL}

Dieser Abschnitt stellt die Sprachkonstrukte der Datenbanksprache SQL vor, die
aufgrund ihrer weiten Verbreitung und hohen Akzeptanz in der Praxis auch als
\e{intergalactical dataspeak} (Michael Stonebraker \cite{}) bezeichnet wird.
Obwohl SQL urspr"unglich f"ur relationale Datenbanksysteme entwickelt wurde (s.
Abschnitt \ref{Relationale Datenbanksysteme}), haben viele Konstrukte der
Sprache (insbesondere die \ky{select from where}-Iterationsabstraktion und das
grundlegende Format der DDL-Anweisungen) Eingang in andere, funktionale und
objektorientierte Datenbanksprachen gefunden, und es existieren auch Werkzeuge
zur "Ubersetzung von SQL Anweisungen in Anweisungssequenzen f"ur hierarchische
und Netzwerkdatenbanken.

Die nachfolgenden Ausf"uhrungen decken einen Gro"steil des im SQL-92 Standard
definierten Sprachumfangs ab, streben jedoch keine enzyklop"adische
Vollst"andigkeit an. Im Gegensatz zu SQL-Lehrb"uchern \cite{} wird versucht,
bei der Vorstellung eines konkreten SQL-Konstrukts auch die zugrundeliegende
Datenbankmodellierungsaufgabe und evtl. alternative L"osungsans"atze
herauszuarbeiten.

\subsection{Lexikalische und syntaktische Regeln}
\label{Lexikalische und syntaktische Regeln}

Wie in modernen Programmiersprachen "ublich, wird ein SQL Quelltext vor der
Syntaxanalyse zun"achst in eine Folge von \e{Symbolen} (Lexeme, Token) zerlegt.
Bei dieser Zerlegung werden nicht-druckbaren Steuerzeichen (Zeilenvorschub,
Seitenwechsel, Tabulator, ...) und \e{Kommentare} wie Leerzeichen behandelt, so
da"s die Formatierung des Quelltextes keinen Einflu"s auf die Semantik von SQL
Anweisungen besitzt. Ein Kommentar ist eine beliebige Zeichenfolge, die mit
\glqq --\grqq\ beginnt und dem Zeilenende endet:

\begin{xple}
\key{select} *                        -- dies ist ein Kommentar
\key{from} Tabelle                 -- mit Umlauten "a"o"u bzw. "s
\end{xple}

Au"serdem werden Kleinbuchstaben im Quelltext sofort in Gro"sbuchstaben
umgewandelt, falls sie nicht in einem speziellen Kontext auftreten (s.u.). SQL
unterscheidet folgende Symbole:

\begin{itemize}
\item Ein \e{Name} (Bezeichner) beginnt mit einem Buchstaben, dem eine
  (evtl.  leere) Kette aus Buchstaben, Ziffern und dem Zeichen \glqq
  \_\grqq\ folgt. Jede SQL Implementierung definiert eine Zahl \e{n},
  so da"s Bezeichner, die in den ersten \e{n} Buchstaben
  "ubereinstimmen, als identisch betrachtet werden.

\item Der SQL-92 Standard definiert "uber 210 Namen als \e{Schl"usselworte},
  die nicht zur direkten Benennung benutzerdefinierter Objekte eingesetzt
  werden k"onnnen (\key{absolute}, \key{action}, \key{all}, \key{and}, ...,
  \key{from}, ... \key{select}, \key{year}, \key{zone}). In diesem Text werden
  Schl"usselworte durch Fettdruck hervorgehoben. Schl"usselworte sind in SQL
  \e{nicht kontextsensitiv}. Zum Beispiel ist das Schl"usselwort \key{create},
  das nie im Kontext von Anfragen auftreten kann, trotzdem kein zul"assiger
  Name f"ur eine Variable innerhalb einer Anfrage.

\item Zus"atzlich zu den oben beschriebenen sogenannten \e{regul"aren Namen}
  k"onnen auch sogenannte \e{begrenzte Namen} als Symbole auftreten. Ein
  begrenzter Name ist eine Zeichenkette innerhalb doppelter Anf"uhrungszeichen.
  Diese Zeichenkette kann beliebige Sonderzeichen (auch Umlaute) und
  Kleinbuchstaben enthalten, die nicht in Gro"sbuchstaben umgewandelt werden.
  Da begrenzte Namen von Schl"usselworten lexikalisch unterschieden sind, kann
  durch den Einsatz begrenzter Namen vermieden werden, da"s ein einmal
  erstelltes SQL Programm beim Umstieg auf ein neueres SQL System mit einem
  reicheren Satz an Schl"usselworten ung"ultig wird
  (\e{Syntaxerweiterungsproblematik}).

\item SQL besitzt weiterhin umfangreiche lexikalische Regeln f"ur \e{Literale},
  dies sind Symbole zur Benennung von Werten der SQL Basisdatentypen (s.
  Tabelle unten). Diese Regeln erl"autern insbesondere die Behandlung
  nationaler Zeichens"atze, die Definition von Stringliteralen
  (Zeichenkettenkonstanten), die l"anger als eine Eingabezeile sind, oder die
  Steuerzeichen enthalten. Die Typisierungsregeln f"ur Literale werden in
  Abschnitt \ref{Basisdatentypen und Typkompatibilitaet} erl"autert.

\item Weitere SQL Symbole (z.B.  \e{Operatoren}) werden durch Sonderzeichen des
  ASCII Zeichensatzes ($>$, $<$, =, \%, \&, (, ), *, +, ...) gebildet.
\end{itemize}

\begin{table}
\begin{center}
\begin{tabular}{|l|l|}
\hline
&   \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Literal}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{SQL Datentyp}} \\
\hline
\hline
'abc'  & \key{character}(3) \\
\hline
\p{N' "a"o"u"s'}  & \key{national character}(4)\\
\hline
\p{123} & \key{smallint}\\
\hline
\p{123.456} & \key{decimal}\\
\hline
\p{B' 101010'}  & \key{bit}(6)\\
\hline
\p{X' 12EF'}  & \key{bit}(16)\\
\hline
\p{date '12-31-94'}  & \key{date}\\
\hline
\p{time '12:34:56.78'} & \key{time}(2)\\
\hline
\p{time '12:34:56.789-01:00'} & \key{time}(3) \key{with time zone}\\
\hline
\p{timestamp '12-31-94 12:34:56'}  & \key{timestamp}(0)\\
\hline 
\p{interval '12'  day} & \key{interval day}\\
\hline
\end{tabular}
\end{center}
\caption{SQL Datentypen}
\label{SQL Datentypen}
\end{table}

Aufgrund der zahlreichen \e{Modalit"aten}, in denen SQL eingesetzt
wird, sind im Einzelfall zus"atzliche lexikalische Regeln zu
ber"ucksichtigen.  Bei der interaktiven Eingabe von SQL-Ausdr"ucken
ist es zum Beispiel erforderlich, die Eingabe einer Anweisungssequenz
explizit abzuschlie"sen (z.B. Eingabe von CTRL-D oder \glqq
$\backslash$g\grqq ), um die Auswertung der Sequenz durch das
Datenbanksystem auszul"osen. Bei der Definition von SQL Anfragen
innerhalb von Stringliteralen einer Gastsprache (z.B. C) werden
zun"achst die lexikalischen Regeln der Gastsprache und dann die
lexikalischen Regeln von SQL ber"ucksichtigt. Dies f"uhrt insbesondere
bei geschachtelten Stringliteralen zu un"ubersichtlichen
Konstruktionen:

\begin{xple}
char* sqlQuery = '' \key{select} * \key{from} Tabelle \key{where} x 2697 = $\backslash$' $\backslash$ $\backslash$ n $\backslash$' ''
\end{xple}

SQL besitzt eine sehr umfangreiche \e{Syntax}, die sich durch eine hohe Anzahl
optionaler Klauseln und schl"usselwortbasierter Operatoren auszeichnet. In
dieser Einf"uhrung stellen wir nur eine Auswahl der SQL Konstrukte vor und
verzichten auf eine formale Definition der SQL-Syntax durch Grammatiken oder
Syntaxdiagramme, da diese in jeder Systemdokumentation von SQL
Datenbanksystemen zu finden sind.

\subsection{Datendefinition in SQL}
\label{Datendefinition in SQL}

In diesem Abschnitt werden die wichtigsten SQL-Konstrukte zur Datendefinition
vorgestellt. Dabei wird der SQL-Terminologie gefolgt, die von der in Abschnitt
\ref{Das relationale Datenmodell} eingef"uhrten Terminologie des relationalen
Datenmodells abweicht (s. Tabelle \ref{SQL-Terminologie}):

\begin{table}
\begin{center}
\begin{tabular}{|c|c|c|}
\hline
&  & \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Datenbankmodell-}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{SQL-}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Englische}}\\
\raisebox{1.5ex}[0cm][0cm] {\bf{Terminologie}} &
\raisebox{1.5ex}[0cm][0cm] {\bf{Terminologie}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{"Ubersetzung}}\\
\hline
\hline
Relation & Tabelle & \e{table}\\
\hline
Tupel & Reihe & \e{row} \\
\hline
Attribut & Spalte & \e{column} \\
\hline
Attributname & Spaltenname & \e{column name} \\
\hline
Sicht & Tabellensicht & \e{view table} \\
\hline  
Dom"ane & Basisdatentyp & \e{base data type} \\
\hline
\end{tabular}
\end{center}
\caption{SQL-Terminologie}
\label{SQL-Terminologie}
\end{table}

\subsubsection{Dynamische DDL Anweisungen}

Im Gegensatz zu anderen Datenbankmodellen findet in SQL keine strikte Trennung
in eine \e{data definition language} (DDL) zur Schemadefinition und eine
separate \e{data manipulation language} (DML) zur Datenbankmanipulation statt.

Die \e{Deklaration} einer Tabelle (\key{create table}) wird in SQL ebenso wie
z.B. die Tabellenoperation \key{update} als eine \e{Anweisung} betrachtet, die
erst dynamisch zur Laufzeit ausgewertet wird. Dieser Ansatz besitzt folgende
Vorteile:

\begin{itemize}
\item Operationen und Deklarationen k"onnen innerhalb von Transaktionen zu
  einer atomaren Operation \e{zusammengefa"st} werden.

\item Deklarationen k"onnen zur Laufzeit durch Werte einer Gastsprache
  \e{parametrisiert} werden (Tabellen- und Spaltennamen, Typen,
  Integrit"atsbedingungen,...).

\item Deklarationen k"onnen innerhalb \e{zusammengesetzter Anweisungen} und
  Schleifen (\key{if}, \key{switch}, \key{loop}) einer Gastsprache auftreten.
\end{itemize}

Diese Flexibilit"at bei der Behandlung von Deklarationen f"uhrt aber auch zu
erheblichen Nachteilen bei der Arbeit mit statischen Datenbankschemata, wie sie
in typischen Informationssystemen anzutreffen sind:

\begin{itemize}
\item \e{Dynamische Bindung}: Alle globalen Namen, die in SQL-Operationen
  verwendet werden (Tabellen, Sichten, ...) m"ussen zur Laufzeit dynamisch (in
  Schemata und Katalogen) identifiziert werden. Auch ein einfacher Tippfehler
  in einer Anfrage (\key{select} \p{*} \key{from} \p{Mitrabeiter}) wird erst zur
  Laufzeit erkannt.

\item \e{Dynamische Typisierung}: Die Kompatibilit"at zwischen Anfragen und der
  Struktur der von ihnen benutzten globalen SQL-Objekte kann ebenfalls erst zur
  Laufzeit getestet werden. Zur "Ubersetzungszeit der Anfrage \key{select} \p{*}
  \key{from} \p{Mitarbeiter} \key{where} \p{Salary$>$Size} ist also unbekannt,
  ob die Tabelle Mitarbeiter tats"achlich die Spalten Salary und Size besitzt,
  ob diese einen kompatiblen Basisdatentyp besitzen, welche Vergleichsoperation
  (exakte Ganzzahlarithmetik, Stringvergleich) zu verwenden ist, und welche
  Spalten das Ergebnis besitzt. Gerade bei Gastspracheneinbettungen ist es
  daher erforderlich, zus"atzliche statische Typinformationen in der
  Programmiersprache zu verwalten, um zum Beispiel auf das Anfrageergebnis der
  obigen Anfrage typsicher zuzugreifen.
\end{itemize}

Moderne Datenbankmodelle (zum Beispiel das objektorientierte Datenbanksystem
O$_{2}$) l"osen dieses Dilemma zwischen Flexibilit"at und statischer
Konsistenzkontrolle beim Datenbankzugriff, indem sie eine \e{Trennung} zwischen
der statischen \e{Definition} von Schemainformationen (analog zu
Modulschnittstellen und Typinformationen) und der dynamischen
\e{Instantiierung} von Datenbankobjekten (analog zu dynamisch gebundenen
Modulen, lokalen Prozedurvariablen oder anonymen Pointervariablen) einf"uhren
(s. Abschnitt 1.5.3). Im obigen Beispiel ist also die Struktur der Tabelle
\p{Mitarbeiter} zur "Ubersetzungszeit der eingebetteten Anfrage bekannt, auch
wenn die Tabelle evtl. erst nach der "Ubersetzung dynamisch angelegt wird.


\comment{Vorw"artsverweis:

\e{polymorphe Typisierung}und
\e{Typinferenz} (select* from X as x where x.age$>$30) und 
\e{reflektive Programmierung} (Konstruktion von Anfragen basierend 
auf Schemainformationen).

}

\subsubsection{Schemata und Kataloge}
\label{Schemata und Kataloge}

Ein SQL-Schema ist ein \e{dynamischer Sichtbarkeitsbereich} f"ur die Namen
geschachtelter (lokaler) \e{SQL-Objekte} (Tabellen, Sichten, Regeln, ...). Im
Gegensatz zu statischen Sichtbarkeitsbereichen in blockstrukturierten
Programmiersprachen k"onnen die \e{Bindungen} von Namen an Objekte in
dynamischen Sichtbarkeitsbereichen durch Anweisungen explizit erzeugt und
gel"oscht werden:

\begin{xple}
\key{create schema} FirmenDB;
  \key{create table} Mitarbeiter ... ;
  \key{create table} Produkte ... ;

\key{create schema} ProjektDB;
  \key{create table} Mitarbeiter ... ;
  \key{create view} Leiter ... ;
  \key{create table} Projekte ... ;
  \key{create table} T ... ;
  \key{drop table} T;

\key{drop schema} FirmenDB
\end{xple}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/65.eps}
\caption{SQL-Kataloge und SQL-Schemata als Sichtbarkeitsbereiche (s. Text)}
\label{SQL-Kataloge und SQL-Schemata}  
\end{center}
\end{figure}
    
Klassische Datenbankanwendungen arbeiten mit SQL-Objekten genau eines Schemas.
Die Integration separat entwickelter Datenbankschemata und die Arbeit in
verteilten und f"oderativen Datenbanken erfordert jedoch auch den simultanen
Zugriff auf SQL-Objekte mehrerer Schemata (\e{multibases}).

Der Name eines mit \key{create schema} erzeugten SQL-Schemas kann daher
verwendet werden, um einen Namen, der in mehr als einem SQL-Schema auftritt,
eindeutig mit Hilfe der Punktnotation zu \e{qualifizieren}
(\p{FirmenDB.Mitarbeiter}, \p{ProjektDB.Mitarbeiter}). Da andererseits jede
SQL-Anweisung immer im Kontext eines \e{aktuellen Schemas} interpretiert wird,
kann bei der Arbeit mit nur einem Schema auf den Einsatz qualifizierter Namen
verzichtet werden. Das aktuelle Schema, also die Menge der in einer Anweisung
global sichtbaren Namen, wird entweder statisch (z.B. bei der "Ubersetzung von
SQL-Modulen) oder dynamisch als Seiteneffekt von Anweisungen (\key{create
  schema} \p{FirmenDB}, \key{connect} \p{FirmenDB}) definiert.  Damit kommt SQL
der in Abschnitt \ref{Unterstuetzung der Persistenz} beschriebenen Forderung
nach \e{dynamischer Bindung} zwischen informationsverarbeitenden Algorithmen
und persistenten Informationsbest"anden nach.

Ein SQL-Schema ist \e{persistent}. In SQL impliziert das Anlegen und L"oschen
eines Schemas gleichzeitig das Anlegen und L"oschen einer \e{Datenbank}, die
das Schema implementiert, und die einen persistenten Container f"ur die lokal
deklarierten SQL-Objekte (z.B. Tabellen) darstellt. Die Lebensdauer
geschachtelter SQL-Objekte ist durch die Lebensdauer ihres Schemas begrenzt. Im
obigen Beispiel l"oscht die Operation \key{drop schema} \p{FirmenDB} also
ebenfalls die lokale Tabelle \p{FirmenDB.Mitarbeiter}.

"Uber qualifizierte Namen ist es auch m"oglich, in einem Schema Referenzen auf
SQL-Objekte eines anderen Schemas zu erzeugen (\key{create view} \p{Leiter}
\key{as select} \p{*} \key{from} \p{FirmenDB.Mitarbeiter} \key{where} ..., s.
Abschnitt \ref{Sichten auf eine Tabelle}). Dies f"uhrt zu
\e{Schemaabh"angigkeiten}, die beim L"oschen eines Schemas ber"ucksichtigt
werden m"ussen:

\begin{xple}
\key{drop schema} FirmenDB \key{cascade}:
\end{xple}

Das Schl"usselwort \key{cascade} erzwingt in diesem Beispiel das (transitive)
L"oschen der abh"angigen SQL-Objekte in anderen Schemata, insbesondere der
Sicht \p{Leiter} in dem Schema \p{ProjektDB}.

Schlie"slich sei darauf hingewiesen, da"s Schemanamen ihrerseits in
Sichtbarkeitsbereichen enthalten sind, die in der Terminologie von SQL-92 als
\e{Kataloge} bezeichnet werden. Wie in Abbildung \ref{SQL-Kataloge und
  SQL-Schemata} dargestellt, werden in Katalogen weitere Informationen zu einem
Schema (Zugriffsrechte, Speichermedium, Datum des letzten Backup, ...)
persistent gespeichert.  Die Namen von Katalogen sind wiederum in Katalogen
abgelegt, von denen einer als \e{Wurzelkatalog} ausgezeichnet ist. Im
allgemeinsten Fall wird daher ein SQL-Objekt "uber eine mehrstufige
Qualifizierung von Katalognamen, einen Schemanamen und einen Objektnamen
ausgehend von dem Wurzelkatalog eindeutig identifiziert. Die aufwendige
Katalogverwaltung wird dabei von Datenbanksystemen teilweise an standardisierte
Netzwerknamensdienste (\e{name services}) delegiert \comment{zitat?}.


\subsubsection{Basisdatentypen und Typkompatibilit"at}
\label{Basisdatentypen und Typkompatibilitaet}

Die \e{formale} Definition des relationales Datenmodell basiert auf einer Menge
von \e{Dom"anen} (D1, D2, ...,Dn), der die \e{atomaren} Werte der Attribute von
Tupeln in Relationen entstammen. Dabei werden nur schwache Anforderungen an die
\e{algebraische Struktur} einer Dom"ane \e{D} gestellt:

\begin{itemize}
\item Existenz einer "Aquivalenzrelation (=) auf \e{D} zur Definition der
  Relationensemantik (Duplikatelimination) und des Begriffs der funktionalen
  Abh"angigkeit (s. Abschnitt \ref{Normalisierung}).

\item Existenz weiterer Boole' scher Pr"adikate ($>$, $<$, $>$=,
  \key{substring}, \key{odd}, ...) auf \e{D} zur Formulierung von Selektions-
  und Joinausdr"ucken "uber Attribute (optional).
\end{itemize}

Eine naheliegende Idee, die von modernen erweiterbaren Datenbankmodellen auch
unterst"utzt wird, besteht darin, beliebige \e{benutzerdefinierte Dom"anen}
(Datentypen) in Datenbankschemadefinitionen zuzulassen, wobei der Programmierer
dem Datenbanksystem unter anderem auch Funktionen zur Implementierung der
(Gleichheits-)pr"adikate bekanntmacht.

Datenbankmodelle der Praxis, wie zum Beispiel SQL-92, besitzen jedoch auch die
Aufgabe, den Datenbankzustand und die Semantik von Anfragen unabh"angig von
speziellen Programmen und Hardwareumgebungen interpretierbar zu halten. Sie
definieren daher ein festes Repertoire an anwendungsorientierten
\e{vordefinierten Basisdatentypen}. Die Definition jedes Basisdatentyps umfa"st
dabei:

\begin{itemize}
\item Lexikalische Regeln f"ur \e{Literale}, also Notationen zur Benennung von
  Werten der Basisdatentypen (4, 4.0, \glqq 4\grqq ),

\item \e{Evaluationsregeln} f"ur un"are, bin"are und allgemein n-"are
  Operatoren (Wertebereich, Ausnahmebehandlung, Behandlung von Nullwerten),

\item \e{Typkompatibilit"atsregeln} f"ur gemischte Ausdr"ucke,

\item \e{Wertkonvertierungsregeln} f"ur den bidirektionalen Datenaustausch mit
  typisierten Programmiersprachenvariablen bei der Einbettung in Gastsprachen.

\item Spezifikationen des \e{Speicherbedarfs} (minimal, maximal) f"ur Werte des
  Typs.
\end{itemize}

Dabei bietet SQL-92 verglichen mit Programmiersprachen eine erheblich feinere
Kontrolle "uber die Datenrepr"asentation der Basisdatentypen (Stringl"ange,
Dezimalstellenanzahl, ...), und erlaubt damit bei der Datendefinition eine
anwendungsgerechte Abw"agung zwischen \e{Modellierungspr"azision} und
\e{Speicherbedarf}.  Au"serdem bietet SQL-92 zahlreiche standardisierte
Operatoren auf diesen Basisdatentypen (z.B. Suchoperationen in Strings,
Datumsfunktionen) und leistet damit ebenfalls einen wichtigen Beitrag zur
\e{Portabilit"at} der mit SQL entwickelten Programme.

Konkret lassen sich die Basisdatentypen von SQL-92 wie folgt klassifizieren (s.
Tabelle in Abschnitt \ref{Lexikalische und syntaktische Regeln}):

\begin{description}
\item[] \e{Exact numerics} bieten exakte Arithmetik und gestatten teilweise die
  Angabe einer Gesamtstellenanzahl (\key{scale},\p{s}) und einer
  Nachkommastellenanzahl (\key{precision}, \p{p}) und umfassen die Typen
  \key{integer}, \key{smallint}, \key{numeric}\p{(p,s)}, \key{decimal}\p{(p,s)}.

\item[] \e{Approximate numerics} bieten aufgrund ihrer Flie"skommadarstellung
  einen flexibleren Wertebereich, sind jedoch wegen der Rundungsproblematik
  nicht f"ur kaufm"annische Anwendungen geeignet (\key{real}, \key{double
    precision}, \key{float}\p{(p)}),

\item[] \e{Character strings} beschreiben mit Leerzeichen aufgef"ullte
  Zeichenketten fester L"ange \e{n} (\key{character}\p{(n)}) oder variabel lange
  Zeichenketten mit fester Maximall"ange \e{n} (\key{character varying}\p{(n)}).

\item[] Analog beschreiben \e{bit strings} mit Null aufgef"ullte Bitmuster
  fester L"ange \e{n} (\key{bit}\p{(n)}) oder variabel lange Bitmuster mit
  fester Maximall"ange \e{n} (\key{bit varying}\p{(n)}).

\item[] Die Klasse der \e{datetime Basistypen} beschreibt Zeit(punkt)werte
  vorgegebener Granularit"at (\key{date}, \key{time}\p{(p)},
  \key{timestamp}\p{(p)}, \key{time}\p{(p)} \key{with time zone},
  \key{timestamp}\p{(p)} \key{with time zone}).

\item[] Schlie"slich beschreiben \e{time intervals} Zeitintervalle vorgegebener
  Dimension und Granularit"at. Zum Beispiel umfa"st der Basisdatentyp
  \key{interval year}\p{(2)} \key{to month} als Werte folgende
  Intervallangaben: 0 Jahre und 0 Monate, 0 Jahre und 1 Monat, ..., 1 Jahr und
  0 Monate, 1 Jahr und 1 Monat, ..., 99 Jahre und 12 Monate.
\end{description}

Bedenkt man, da"s ein Datenbankstandard f"ur jeden Operator (z.B.
Zeitintervallberechnung) detaillierte Evaluations- und
Typkompatibilit"atsregeln definiert, aus denen insbesondere auch die Dimension
und Granularit"at des Berechnungsergebnisses hervorgeht, so wird die in einem
Datenbanksystem \e{versteckte algorithmische Komlexit"at} deutlich.

Schlie"slich ist zu erw"ahnen, da"s SQL wie viele Programmiersprachen sowohl
die implizite Typanpassung (\e{coercion}), zum Beispiel zur Umwandlung von
Datenwerten geringer Genauigkeit in Datenwerte h"oherer Genauigkeit, als auch
die explizite Typanpassung (\e{casting}), zum Beispiel zur Umwandlung von
Zeichenketten, die nur Ziffern enthalten, in ganzzahlige Werte
(\key{cast}\p{('1234'} \key{as integer})), unterst"utzt.

\subsubsection{Nullwerte und Wahrheitswerte}
\label{Nullwerte und Wahrheitswerte}

Bei der Datenbankmodellierung und -programmierung k"onnen Situationen
auftreten, in denen anstelle eines Wertes eines Basisdatentyps ein
ausgezeichneter \e{Nullwert} ben"otigt wird.  Folgende Beispiele illustrieren,
da"s die Semantik (Interpretation) des Nullwerts oft \e{situationsabh"angig}
ist:

\begin{itemize}
\item Ein Tabellenschema definiert, da"s in jeder Reihe der Tabelle
  \p{Mitarbeiter} die Spalte \p{Alter} einen Wert des Typs \key{integer}
  besitzt.  Ist das Alter eines Mitarbeiters \e{unbekannt}, so kann dies mit
  dem Wert \key{null} gekennzeichnet werden.

\item Ein Tabellenschema definiert, da"s in jeder Reihe der Tabelle
  \p{Abteilung} die Spalte \p{Oberabteilung} einen Wert des Typs \key{string}
  besitzt. Ist \e{bekannt}, da"s eine Abteilung \e{keine} Oberabteilung
  besitzt, so kann diese Information mit dem Wert \key{null} repr"asentiert
  werden.

\item Die Typregeln von SQL definieren, da"s die Berechnung des
  Tabellenmaximums oder des Tabellenmittelwerts eines Attributs des Typs
  \key{float} ein Ergebnis des selben Typs liefert. Da das Maximum und der
  Mittelwert einer leeren Menge jedoch mathematisch \e{undefiniert} ist, kann
  das Auftreten dieser Ausnahmesituation zur Laufzeit mit dem Ergebniswert
  \key{null} signalisiert werden.
\end{itemize}

Zur Unterst"utzung solcher Modellierungssituationen ist jeder SQL-Basisdatentyp
um den ausgezeichneten Wert \key{null} erweitert, der von jedem anderen Wert
des Basisdatentyps verschieden ist. F"ugt man zu SQL-Typspezifikationen die
Integrit"atsbedingung \key{not null} hinzu (s. z.B. \p{Name} \key{char}(40)
\key{not null}), so wird das Auftreten von Nullwerten in Attributen oder
Variablen dieses Typs durch statische und dynamische Tests ausgeschlossen.

Ein Nullwert in dem Attribut \p{x} kann in Datenbankanfragen "uber die 
\e{Pr"adikate} \p{x} \key{is null} und \p{x} \key{is not null} behandelt werden.

Als \e{Vorteil}e der expliziten Unterst"utzung von Nullwerten durch
Datenbankmodelle sind zu nennen:

\begin{itemize}
\item Explizite und konsistente Behandlung von Nullwerten durch alle
  Applikationen (im Gegensatz zu \e{ad hoc} L"osungen, bei denen z.B. der Wert
  \p{-1}, \p{-MaxInt} oder die leere Zeichenkette als Nullwert eingesetzt
  wird).

\item Exakte Definition der Semantik von Datenbankoperatoren (Zuweisung,
  Vergleich, Arithmetik) auf Nullwerten.
\end{itemize}

Diesen Vorteilen stehen jedoch auch einige \e{Nachteile} gegen"uber:

\begin{itemize}
\item Eine Erweiterung eines Datentyps um Nullwerte steht oft im Konflikt mit
  den \e{algebraischen Eigenschaften} (Existenz von Nullelementen,
  Assoziativit"at, Kommutativit"at, Ordnung, ...) des nicht-erweiterten
  Datentyps. Es ist zum Beispiel unklar, an welcher Stelle der Sortierordnung
  der Wert \key{null} bei den ganzen Zahlen einzuordnen ist (Gilt \p{\dots $<$
    -2 $<$ -1 $<$ 0 $<$ null $<$ 1 $<$ 2 $<$ \dots} ?).  "Ahnliches gilt f"ur
  die Generalisierung der Arithmetik (Gilt \p{1 + \key{null} = \key{null}} und
  \p{\key{null} - \key{null} = \key{null}} ?).  Da die im SQL-Standard
(willk"urlich) getroffenen Annahmen teilweise nicht mit der speziellen
Nullwertsemantik einer Anwendung "ubereinstimmen, ist es in der Praxis h"aufig
erforderlich, Nullwerte in SQL-Anweisungen aufwendig explizit zu behandeln.

\item Wie in Kapitel xx (Anfrageoptimierung) dargestellt, werden algebraische
  Eigenschaften h"aufig auch zur \e{Anfrageoptimierung} ausgenutzt.  Eine
  Anfrage, die Werte eines Datentyps \p{T} verwendet, bietet daher im Regelfall
  weniger Optimierungsspielraum als eine Anfrage mit Werten des Datentyps \p{T}
  \key{not null}.

\item Die Einf"uhrung von Nullwerten f"ur Variablen f"uhrt zu einem
  \e{Schneeballeffekt}, indem Nullwerte auch als (Zwischen-)ergebnisse von
  beliebigen Ausdr"ucken auftreten k"onnen und separat behandelt werden
  m"ussen.

\item Beim Datenaustausch zwischen SQL-Datenbanken und Programmiersprachen
  werden SQL-Attribute eines Typs \p{T}, der auch Nullwerte annehmen kann,
  durch ein Paar bestehend aus einer Programmiersprachenvariablen des Typs
  \p{T} und einer (Boole' schen) \e{Indikatorvariable} dargestellt, die angibt,
  ob der SQL-Wert \key{null} ist.  Diese Darstellung f"uhrt zu einer hohen
  \e{Komplexit"at der Anwendungsprogramme}.
\end{itemize}

Speziell f"ur den (in SQL-92 nur implizit vorhandenen) Datentyp der
\e{Wahrheitswerte} (\key{boolean}) f"uhren Nullwerte zu einer \e{dreiwertigen
  Logik}(\key{true}, \key{false}, \key{null}), in der die Restriktion aller
Operatoren (\key{and}, \key{or}, \key{not}) auf die Argumente \key{true} und
\key{false} die "ubliche Boole' sche Semantik besitzt. Die nachfolgenden
Wahrheitstabellen zeigen die spezielle dreiwertige Logik, die dem SQL-92
Standard zugrunde liegt.  Wie aus den Tabellen hervorgeht, unterst"utzt SQL-92
also die Interpretation des Wertes \key{null} als \e{unbekannt} (\glqq
vielleicht \key{true} oder vielleicht \key{false}\grqq ). So ist zum Beispiel
das Ergebnis von \key{true or null} als \key{true} definiert, da sowohl
\key{true or false} als auch \key{true or true} zu \key{true} evaluiert.

Die oben genannte Schwierigkeit einer konsistenten Erweiterung einer Dom"ane um
Nullwerte wird bereits am einfachen Beispiel der Boole' schen Werte und der
grundlegenden logischen "Aquivalenz \p{x} \key{and not} \p{x =} \key{false}
deutlich, die bei der Erweiterung der Dom"ane um einen Nullwerte verletzt wird
( \key{null and not null} \p{=} \key{null}).

\begin{table}
\begin{center}
\key{
\begin{tabular}{|c|l|c|c|c|}
\hline
\multicolumn{1}{|p{1.8cm}|}{} & 
 &   
\multicolumn{1}{|p{1.8cm}|}{}& 
\multicolumn{1}{|p{1.8cm}|}{} & 
\multicolumn{1}{|p{1.8cm}|}{}\\
 \raisebox{1.5ex}[0cm][0cm] {or} & &
 \raisebox{1.5ex}[0cm][0cm] {true} & 
 \raisebox{1.5ex}[0cm][0cm] {false} & 
 \raisebox{1.5ex}[0cm][0cm] {null} \\
\hline
\hline
true & & true & true & true \\
\hline
false & & true & false & null \\
\hline
null & &  true & null & null \\
\hline
\end{tabular}}
\end{center}


\begin{center}
\key{
\begin{tabular}{|c|l|c|c|c|}
\hline
\multicolumn{1}{|p{1.8cm}|}{} & 
 &   
\multicolumn{1}{|p{1.8cm}|}{}& 
\multicolumn{1}{|p{1.8cm}|}{} & 
\multicolumn{1}{|p{1.8cm}|}{} \\
 \raisebox{1.5ex}[0cm][0cm] {and} & &
 \raisebox{1.5ex}[0cm][0cm] {true} & 
 \raisebox{1.5ex}[0cm][0cm] {false} & 
 \raisebox{1.5ex}[0cm][0cm] {null} \\
\hline
\hline
true & &  true & false & null \\
\hline
false & &  false & false & false \\
\hline
null & & null & false & null \\
\hline
\end{tabular}}
\end{center}

\begin{center}
\key{
\begin{tabular}{|c|l|c|c|c|}
\hline
\multicolumn{1}{|p{1.8cm}|}{} & 
 &   
\multicolumn{1}{|p{1.8cm}|}{}& 
\multicolumn{1}{|p{1.8cm}|}{} & 
\multicolumn{1}{|p{1.8cm}|}{} \\
 \raisebox{1.5ex}[0cm][0cm] {x} & &
 \raisebox{1.5ex}[0cm][0cm] {not x} & 
 \raisebox{1.5ex}[0cm][0cm] {x is null} & 
 \raisebox{1.5ex}[0cm][0cm] {x is not null} \\
\hline
\hline
true & & false & false & true \\
\hline
false & & true & false & true \\
\hline
null & &  null & true & false \\
\hline
\end{tabular}}
\end{center}
\caption{Wahrheitstabellen der dreiwertigen SQL92-Logik}
\label{dreiwertige Logik}
\end{table}

Die hohe Bedeutung, die Nullwerte in der Theorie und Praxis relationaler
Modelle erlangt haben, ist zum Teil auch auf die \e{eingeschr"ankte
  Datenstrukturflexibilit"at} des relationalen Modells (homogene Mengen flacher
Tupel) zur"uckzuf"uhren. Einige Modellierungsaufgaben, die im relationalenn
Datenmodell durch Nullwerte gel"ost werden, k"onnen in anderen Modellen durch
speziellere Konzepte wie Vereinigungstypen (\e{union types, variant records}),
Subtypisierung oder Vererbungsbeziehungen gel"ost werden.

Abschlie"send sei angemerkt, da"s in der Forschung zahlreiche alternative
Modelle f"ur Nullwerte und \e{mehrwertige Logiken} vorgeschlagen wurden. Ein
extremes Beispiel stellt eine Studie der \e{DataBase Systems Study Group} dar,
die 29 alternative Bedeutungen f"ur Nullwerte unterscheidet\cite{}.

Bei der Entwicklung des Nachfogers des SQL-92 Standards sind daher zus"atzliche
Nullwerte und sogar benutzerdefinierte Nullwerte in der Diskussion.

\subsubsection{Tabellendefinitionen}
\label{Tabellendefinitionen}

Tabellen sind die wichtigsten SQL-Objekte, die in einem Schema definiert
werden. Eine SQL-Tabellendefinition fa"st die folgenden Teilschritte in
\e{einem} syntaktischen Konstrukt zusammen:

\begin{itemize}
\item \e{Typdefinition}: Definition einer Tabellenstruktur (Spaltennamen,
  Spaltentypen).

\item \e{Variablendefinition}: Definition eines Namens f"ur eine Tabelle dieser
  Struktur im aktuellen Schema.

\item \e{Variableninstantiierung}: Dynamisches Anlegen einer Variablen dieser
  Struktur in der aktuellen Datenbank. Eine Variable wird in SQL mit der leeren
  Tabelle initialisiert.
\end{itemize}

Moderne Datenbanksprachen bieten separate syntaktische Konstrukte f"ur jeden
dieser Schritte, die es zum Beispiel erm"oglichen, benannte Tabellentypen zu
definieren (Vorteile: Wiederverwendung, statische Schematyisierung).

Das folgende Beispiel illustriert die Syntax einer SQL-Tabellendefinition:

\begin{xple}
\key{create table} Mitarbeiter(
  Name \key{char}(29),
  Gehalt \key{integer},
  Urlaub \key{smallint});
\end{xple}

Die Anzahl der Spalten einer Tabelle ist statisch fixiert wird auch als der
\e{Grad} der Tabelle bezeichnet.  In SQL ist die Reihenfolge der Spalten einer
Tabelle signifiant und es ist nicht erlaubt, Tabellen mit Grad 0 zu definieren.

Die Anzahl der Reihen einer Tabelle variiert dynamisch und wird auch als die
\e{Kardinalit"at} der Tabelle bezeichnet. Eine Tabelle mit Kardinalit"at 0
hei"st \e{leer}. Im Gegensatz zur Definition des relationalen Modells kann eine
Tabelle \e{Duplikate} enthalten. Eine Reihe ist ein Duplikat einer anderen
Reihe, wenn beide in allen Spalten gem"a"s der "Aquivalenzrelation der
jeweiligen Spaltentypen "ubereinstimmen. In den meisten Kontexten ist die
\e{Reihenfolge} der Reihen einer Tabelle unspezifiziert (siehe aber Abschnitt
Abschnitt \ref{Duplikatelimination und Sortierordnung} und Abschnitt
\ref{Gruppierung}).

Tabellendefinitionen k"onnen wie die meisten Objekte eines SQL 
Schemas dynamisch modifiziert werden. SQL verwendet unterschiedliche 
Schl"uselworte f"ur die Manipulation von Daten und die Manipulation 
von Metadaten:

\begin{table}
\begin{center}
\begin{tabular}[htb]{|l|c|c|}
\hline 
\multicolumn{1}{|p{100pt}|}{}& 
\multicolumn{1}{|p{150pt}|}{}& 
\multicolumn{1}{|p{150pt}|}{}\\
\raisebox{1.5ex}[0cm][0cm] {\bf{Operation}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Schl"usselwort f"ur}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Schl"usselwort f"ur}} \\
 & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Schemamanipulation}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Datenmanipulation}} \\
\hline
\hline
Einf"ugen    & \key{create} & \key{insert} \\
\hline
Modifizieren & \key{alter}  & \key{update} \\
\hline
L"oschen     & \key{drop}   & \key{delete} \\
\hline
\end{tabular}
\end{center}
\caption{Schl"usselworte f"ur die Schema- und Datenmanipulation}
\label{Schluesselworte Schema und Daten}
\end{table}

Das folgende Beispiel zeigt \e{Schema"anderungen} f"ur die oben 
definierte Tabelle \p{Mitarbeiter}.

\begin{xple}
\key{alter table} Mitarbeiter
  \key{add column} Adresse \key{varchar}(40)
  \key{alter column} Name \key{unique}
  \key{drop column} Urlaub;
\key{drop table} Mitarbeiter;
\end{xple}
  
Dabei ist zu beachten, da"s die SQL-DDL-Anweisung \key{drop table} \p{T} sich
von der SQL-DML-Anweisung \key{delete from} \p{T} (s. Abschnitt
\ref{delete-Anweisung}) darin unterscheidet, da"s nicht nur der gesamte Inhalt
der Tabelleninstanz sondern auch die Tabellentypinformation und die
Tabellenvariableninformation gel"oscht werden.

\subsubsection{Lebensdauer, Sichtbarkeit und gemeinsame Nutzung von Tabellen}

Wie in Abbildung \ref{Sichtbarkeit, Lebensdauer, gemeinsame Nutzung}
dargestellt, k"onnen mehrere informationsverarbeitende \e{Prozesse} (Sitzungen,
\e{sessions}) die gleiche Datenbank simultan oder sequentiell nacheinander
benutzen. Ein Proze"s f"uhrt eine Folge von \e{Transaktionen} (s. Abschnitt
\ref{Transaktionale Datenbankprogrammierung}) durch, innerhalb derer
Datenbankzugriffe stattfinden. Prozesse und Transaktionen benutzen \e{Namen}
zur Identifikation von Datenbankobjekten.

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

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/66.eps}
\caption{Sichtbarkeit, Lebensdauer, gemeinsame Nutzung}
\label{Sichtbarkeit, Lebensdauer, gemeinsame Nutzung}  
\end{center}
\end{figure}

Bei der Deklaration von Datenbankobjekten wie SQL-Tabellen 
sind daher drei Objekteigenschaften zu definieren:

\begin{description}
\item[] \e{Lebensdauer (extent)}: Der Zustand eines Objektes kann
  \e{persistent} oder nur \e{fl"uchtig} gespeichert werden.  Persistente
  SQL-Objekte (\p{Mitarbeiter}) existieren solange bis sie oder die Datenbank,
  in der sie deklariert wurden, explizit durch eine SQL Anweisung (\key{drop},
  \key{delete} \ldots) gel"oscht werden.  Eine fl"uchtige Lebensdauer kann sich
  "uber einen gesamten Proze"s (Bewerbungen), eine einzelne Transaktion oder
  nur eine einzelne SQL-Prozedur erstrecken.

\item[] \e{Sichtbarkeit (scope)}: Der Name eines Objekts kann \e{global} f"ur
  alle Prozesse, die eine Datenbank benutzen (\p{Mitarbeiter}), oder nur
  \e{lokal} f"ur einen Proze"s (Bewerbungen, Ergebnistabelle) sichtbar sein.
  Der Sichtbarkeitsbereich eines Prozesses kann durch SQL-Module noch weiter
  partitioniert werden.

\item[] \e{Gemeinsame Nutzung (sharing)}: Ein Name kann entweder eine
  \e{Referenz} auf ein f"ur mehrere Prozesse zugreifbares Objekt
  (\p{Mitarbeiter) oder eine proze"slokale } \e{Kopie} (Instanz) eines Objekts
  (Ergebnistabelle) bezeichnen.  Referenzen und Kopien unterscheiden sich in
  der Wirkung von Seiteneffekten (\key{insert}, \key{delete}, \key{update}).
\end{description}

Es ist zu beachten, da"s diese Objekteigenschaften \e{nicht} vollst"andig
\e{orthogonal} zueinander sind, da zum Beispiel eine Referenz auf ein gemeinsam
genutztes Objekt nur erzeugt werden kann, wenn ein Namen in einem globalen
Sichtbarkeitsbereich zu seiner Identifikation zur Verf"ugung steht.

Problematisch ist weiterhin die Situation, in der ein Name mit globaler
Sichtbarkeit ein Objekt mit fl"uchtiger Lebensdauer bezeichnet, da am Ende der
Lebensdauer das an den Namen gebundene Objekt undefiniert ist. Dieses Problem
der sogenannten \e{dangling references} ist auch aus Programmiersprachen
bekannt.

Da SQL-Datenbanksysteme eine Persistenzabstraktion durchf"uhren, ist es nicht
erforderlich, als vierte Objekteigenschaft den \e{Adre"sraum} (im Prim"ar- oder
Sekund"arspeicher) zu definieren, in dem ein (lokales oder globales) SQL-Objekt
anzulegen ist.

Historisch gesehen haben sich Datenbanksysteme auf persistente und globale
Datenobjekte konzentriert. Wie in Abschnitt \ref{Unterstuetzung der Persistenz}
aufgez"ahlt, existieren jedoch in Informationssystemen h"aufig auch lokale und
fl"uchtige Informationsstrukturen, bei deren Realisierung Datenbankdienste wie
Massedatenstrukturierung und Iterationabstraktion erforderlich sind. Eine
explizte Unterst"utzung fl"uchtiger und lokaler Objekte durch die
Datenbanksoftware bietet dabei folgende \e{Vorteile}:

\begin{itemize}
\item Vermeidung von \e{Namenskonflikten} im globalen Sichtbarkeitsbereich der
  Datenbank.

\item Automatische \e{Speicherfreigabe} durch das Datenbanksystem am Prozedur-,
  Transaktions- bzw. Proze"sende (kein explizites \key{drop table}
  erforderlich).

\item Effizienzgewinn durch die M"oglichkeit zur \e{proze"slokalen Speicherung}
  (z.B. im Hauptspeicher).

\item Effizienzgewinn durch die \e{Vermeidung von Synchronisationsoperationen}
  (Sperren, Nachrichten, ...) zwischen Prozessen.
\end{itemize}

Tabelle \ref{Lebensdauer, Sichtbarkeit und gemeinsame Nutzung von Tabellen}
fa"st die in SQL-92 unterst"utzten Kombinationen von Tabellenlebensdauer,
Tabellensichtbarkeit und gemeinsamer Nutzung sowie die jeweils zugeh"orige
SQL-DDL-Anweisung zusammen.

\begin{table}
\begin{center}
\begin{tabular}{|l|c|c|c|}
\hline
\multicolumn{1}{|p{120pt}|}{} & 
\multicolumn{1}{|p{120pt}|}{}& 
\multicolumn{1}{|p{80pt}|}{} & 
\multicolumn{1}{|p{80pt}|}{} \\
\raisebox{1.5ex}[0cm][0cm] {\bf{DDL}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Tabellen-}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Namens-}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Gemeinsame}} \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Anweisung}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Lebensdauer}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Sichtbarkeit}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Nutzung}}\\
\hline
\hline
\bf{create table} \p{T}   & persistent              &  global & ja \\
                          & (Datenbank)             & (Datenbank)& \\
\hline
\key{create global}         & fl"uchtig               &  lokal & nein \\
\key{temporary table} \p{T} & (Proze"s, Transaktion)  & (Proze"s) & \\
\hline
\key{create local}          & fl"uchtig               & lokal  & nein \\
\key{temporary table} \p{T} & (Proze"s, Transaktion)  & (Modul) & \\
\hline
\key{declare local}         & fl"uchtig               & lokal & nein \\
\key{temporary table} \p{T} & (Proze"s, Transaktion)  & (Prozedur) & \\
\hline
\end{tabular}
\end{center}
\caption{Lebensdauer, Sichtbarkeit und gemeinsame Nutzung von Tabellen}
\label{Lebensdauer, Sichtbarkeit und gemeinsame Nutzung von Tabellen}
\end{table}

In SQL l"a"st sich f"ur tempor"are Tabellen mit den Klauseln \key{on commit
  preserver rows} und \key{on commit delete rows}.  die Lebensdauer fl"uchtiger
Tabellen auf einen gesamten Proze"s oder nur eine einzelne Transaktion
einschr"anken. F"ur eine Tabelle \p{T}, die mit \key{create ... temporary table}
\p{T(...)} \key{on commit delete rows} definiert wird, mu"s das Datenbanksystem
keine aufwendigen \e{Fehlererholungsinformationen} zum R"ucksetzen des
Tabellenzustands im Falle von Transaktionsabbr"uchen speichern.


\subsubsection{Standardwerte f"ur Spalten}
\label{Standardwerte fuer Spalten}

In SQL ist es m"oglich, beim Einf"ugen von Reihen in eine Tabelle Werte f"ur
einzelne Spalten unspezifiziert zu lassen. So l"a"st zum Beispiel die folgende
Einf"ugeoperation den Wert der Spalte \p{Urlaub} unspezifiziert.

\begin{xple}  
\key{insert into} Mitarbeiter (Name, Gehalt, Urlaub) 
\key{values} ('Peter', 3000)
\end{xple}

Die fehlenden Spaltenwerte werden in solchen F"allen durch den Nullwert
\key{null} ersetzt. Es ist jedoch auch m"oglich, bei der Tabellenerzeugung
(\key{create table}) einen anderen Standardwert f"ur eine Spalte mit der Klausel
\key{default} \p{Standardwert} festzulegen. Dieser Wert ist entweder ein Literal
eines Basistyps oder eine \e{parameterlose} SQL-Funktion, die zum Zeitpunkt der
Einf"ugeoperation ausgewertet wird und einen Datumswert (\key{current\_date},
\key{current\_time}, \key{current\_timestamp}) oder eine Benutzeridentifikation
(\key{current\_user}, \key{session\_user}, \key{system\_user}) liefert.

Spaltenstandardwerte leisten einen nicht zu untersch"atzenden Beitrag zur
\e{Datenunabh"angigkeit} und \e{Schemaevolution}, da existierende
Anwendungsprogramme auch nach dem Erweitern einer Relation um eine neue Spalte
(\key{alter table} \p{Mitarbeiter} \key{add column} Parkplatz \key{not null})
konsistent mit neu erstellten Anwendungsprogrammen interagieren k"onnen.

\comment{Vorw"artsverweis auf Sichten. Wirklich neue Funktionalit"at?}

\subsection{Anfragen in SQL}
\label{Anfragen in SQL}

Dieser Abschnitt zeigt am Beispiel SQL wie Datenbanksprachen
\e{Iterationsabstraktion} durch deklarative Anfrage- und "Anderungsoperationen
erreichen. SQL erzielt Iterationsabstaktion durch

\begin{itemize}
\item \e{Mengen-orientierte}, \e{kalk"ulbasierte} \ky{select from
    where}-Anfragen

\item Algebraische Mengenoperationen

\item Aggregatfunktionen f"ur Mengen

\item Quantifizierte Pr"adikate
\end{itemize}

Das grundlegende Sprachkonstrukt von SQL ist die \e{mengenorientierte}
\ky{select from where}-Anfrage, die aus einer Projektionsliste, einer Liste von
Bereichstabellen und einem Selektionspr"adikat besteht, und die eine Tabelle
als Anfrageergebnis liefert:

\begin{xple}
\key{select} Projektionsliste 
\key{from}   Bereichstabellen 
\key{where}  Selektionspr"adikat;
\end{xple}

Die vollst"andige Syntax und Semantik des \ky{select from where}-Ausdrucks ist
recht kompliziert und wird in den nachfolenden Abschnitten schrittweise
eingef"uhrt.

%\comment{Bezug auf relationales Datenbankschema der Firmendatenbank 
%beschrieben in Abbildung xxx. }

\subsubsection{Monorelationale Select From Where-Anfragen}
\label{Monorelationale Select From Where-Anfragen}

\e{Monorelationale} Anfragen sind Anfragen, die sich nur auf eine
Bereichstabelle beziehen:

\begin{xple}
\key{select} Projektionsliste 
\key{from}   Bereichstabelle
\key{where}  Selektionspr"adikat;
\end{xple}

Das Ergebnis einer monorelationalen Anfrage ist eine fl"uchtige, anonyme
Tabelle, deren Spaltenstruktur durch die Projektionsliste bestimmt wird. Die
Projektionsliste besteht aus einer durch Kommata getrennten Liste von
Ausdr"ucken, die Werte der SQL-Basisdatentypen liefern m"ussen. Das
\e{Selektionspr"adikat} ist ein beliebig komplexer Boole' scher Ausdruck, der
zu den Werten \key{true}, \key{false} oder \key{null} evaluieren kann. F"ur
jede Reihe der Bereichstabelle, die das Selektionspr"adikat erf"ullt
(\p{Selektionspr"adikat =} \key{true}), wird die Projektionsliste ausgewertet
und eine neue Reihe mit den berechneten Spaltenwerten in die Ergebnistabelle
eingef"ugt. Die \e{Reihenfolge} der Reihen in der Ergebnistabelle ist nicht
definiert und ist insbesondere nicht durch die Reihenfolge der Reihen in der
Bereichstabelle bestimmt.

Um zum Beispiel die Namen und das K"urzel aller Abteilungen zu 
bestimmen, die der Abteilung \glqq Leitung Software\grqq\ mit dem K"urzel 
\glqq LTSW\grqq\ untergeordnet sind, kann die folgende SQL Anfrage 
verwendet werden:

\begin{xple}
\key{select} Name, Kurz 
\key{from} Abteilungen
\key{where} Oberabteilung = 'LTSW';
\end{xple}

Die Anfrage berechnet eine Tabelle mit den Spalten \p{Name, Kurz} als Ergebnis.
F"ur jede Reihe der Bereichstabelle \p{Abteilungen}, f"ur die das Pr"adikat
\p{Oberabteilung='LTSW'} wahr ist, wird eine Reihe in der Ergebnistabelle mit
den Werten der Spalten \p{Name} und \p{Kurz} angelegt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/68.eps}
\caption{Ergenisrelation einer monorelationalen Anfrage}
\label{Ergenisrelation einer monorelationalen SQL-Anfrage}
\end{center}
\end{figure}

Ein Stern (\key{*}) in der Projektionsliste einer \ky{select from
  where}-Anfrage entspricht der Aufz"ahlung aller Spalten der Bereichstabelle.
Die Reihenfolge der Spalten bleibt dabei erhalten, und es wird ausschlie"slich
eine \e{Tabellenselektion} durchgef"uhrt:

\begin{xple}
\key{select *} 
\key{from} Abteilungen
\key{where} Oberabteilung = 'LTSW';
\end{xple}

\begin{figure}
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/69.eps}
\end{center}
\caption{Ergenisrelation einer monorelationalen Anfrage}
%\label{Ergenisrelation einer monorelationalen SQL-Anfrage}
\end{figure}

Das Weglassen der \ky{where}-Klausel entspricht der Angabe des
Selektionspr"adikats \key{true}, soda"s f"ur jede Reihe der Bereichstabelle
eine Reihe im Anfrageergebnis auftaucht und ausschlie"slich eine
\e{Tabellenprojektion} durchgef"uhrt wird (s. Abbildung \ref{Monorelationale
  SQL-Anfrage}):

\begin{xple}
\key{select} Oberabteilung 
\key{from} Abteilungen
\end{xple}

\begin{figure}
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/70.eps}
\end{center}
\caption{Ergebnis einer monorelationalen SQL-Anfrage bei Weglassen der \ky{where}-Klausel}
%\label{Monorelationale SQL-Anfrage}
\end{figure}

Eine anonyme fl"uchtige Kopie einer Datenbanktabelle \p{T} erh"alt man also
durch Anfragen der folgenden Form:

\begin{xple}
\key{select * from} T;
\end{xple}

Die Spaltennamen der Ergebnistabelle k"onnen bei 
Bedarf in der Projektionsliste explizit definiert werden:

\begin{xple} 
\key{select} Kurz \key{as} Unter, Oberabteilung \key{as} Ober 
\key{from} Abteilungen;
\end{xple}
 
\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/71.eps}
\caption{Ergebnisrelation einer Anfrage mit expliziter Projektionsliste}
\label{}  
\end{center}
\end{figure}

\subsubsection{Duplikatelimination und Sortierordnung}
\label{Duplikatelimination und Sortierordnung}

Das Anfrageergebnis, das in Abbildung \ref{Monorelationale SQL-Anfrage}
dargestellt ist, enth"alt dreimal den Wert \glqq LTSW\grqq , da die
Bereichstabelle drei Reihen mit diesem Wert in der Spalte \p{Oberabteilung}
besitzt. Verwendet man in der zugeh"origen Anfrage das Schl"usselwort
\key{distinct}, so werden im Anfrageergebnis \e{Duplikate} eliminiert (Zur
Erinnerung: Eine Reihe ist ein Duplikat einer anderen Reihe, wenn beide in
allen Spalten gem"a"s der "Aquivalenzrelation der jeweiligen Spaltentypen
"ubereinstimmen):

\begin{xple} 
\key{select distinct} Oberabteilung \key{from} Abteilungen
\end{xple}

Nach der Duplikateliminierung enth"alt im obigen Beispiel die Ergebnistabelle
genau zwei Zeilen (\p{LTSW} und \key{null}). Allgemeiner gesagt wird durch das
Schl"usselwort \key{distinct} eine Ergebnistabelle in eine \e{Ergebnismenge}
umgewandelt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/74.eps}
\caption{Ergebnisrelation bei Duplikatelimination}
%\label{}  
\end{center}
\end{figure}

Wie in Abschnitt \ref{Nullwerte und Wahrheitswerte} erkl"art wurde,
lassen sich Nullwerte in Spalten durch das Pr"adikat \key{is null}
erkennen und damit auch in der Ergebnistabelle oder -menge vermeiden:

\begin{xple}
\key{select distinct} Oberabteilung 
\key{from} Abteilungen
\key{where} Oberabteilung \key{is not null};
\end{xple}
  
\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/75.eps}
\caption{Ergebnisrelation bei Duplikatelimination und Elimination von nullwertigen Ergebnissen}
%\label{}  
\end{center}
\end{figure}

In manchen F"allen ist es erforderlich, Anfrageergebnisse \e{sortiert}
darzustellen. Dies ist "uber die \key{order by} Klausel mit den
Optionen \key{asc} (\e{ascending}, aufsteigend) und \key{desc}
(\e{descending}, absteigend) in SQL m"oglich:

\begin{xple}
\key{select * from} Abteilungen \key{order by} Kurz \key{asc};
\end{xple}
  
\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/76.eps}
\caption{Ergebnisrelation bei Sortierung}
%\label{}  
\end{center}
\end{figure}

Die Sortierordnung f"ur eine Spalte wird dabei durch die Sortierordnung der
zugrundeliegenden Dom"ane (s. Abschnitt \ref{Basisdatentypen und
  Typkompatibilitaet}) definiert.  Zum Beispiel werden Zeichenketten
lexikographisch sortiert, w"ahrend Zahlen numerisch sortiert werden. Dabei wird
der Nullwert \key{null} als der minimale Wert jeder Dom"ane betrachtet.

%\comment{stimmt das? keine Auskunft darueber in Navathe}

Die Sortierung kann mehrere Spalten umfassen. Im folgenden Beispiel werden alle
Abteilungen gem"a"s des K"urzels ihrer Oberabteilung aufsteigend sortiert.
Innerhalb einer Oberabteilung werden die Abteilungen dann absteigend nach ihrem
K"urzel sortiert:

\begin{xple}
\key{select * from} Abteilungen \key{order by} Oberabteilung \key{asc}, Kurz \key{desc};
\end{xple}  

\subsubsection{Multirelationale Select From Where-Anfragen}
\label{Multirelationale Select From Where-Anfragen}

Die Leistungsf"ahigkeit von \ky{select from where}-Anfragen wird in
\e{multirelationalen} Anfragen deutlich. Dies sind Anfragen, in denen Spalten
und Reihen mehrerer Bereichstabellen verkn"upft werden.  Solche Verkn"upfungen
sind zum Beispiel notwendig, um Anfragen "uber \e{Objektbeziehungen} im
Relationalen Modell zu formulieren.

\begin{xple}
\key{select} Projektionsliste 
\key{from} T$_{1}$,  T$_{2}$,\dots T$_{n}$
\key{where} Selektionspr"adikat;
\end{xple}  

Die Typisierungs- und Auswertungsregeln (Selektionspr"adikat, Projektionsliste,
Reihenfolge) f"ur multirelationale Anfragen entsprechen den Regeln f"ur
monorelationale Anfragen (s. \ref{Monorelationale Select From Where-Anfragen})
mit dem Unterschied, da"s das Selektionspr"adikat und die Projektionsliste f"ur
alle m"oglichen Kombinationen der Reihen der \e{n} Bereichstabellen ausgewertet
werden. Konzeptionell findet also eine Selektion und Projektion "uber das
\e{Kartesische Produkt} der Bereichstabellen statt.

Zur Verdeutlichung ist nachfolgend das Ergebnis der Berechnung des Kartesischen
Produkts T = R x S der Tabellen R und S mit der SQL-Anfrage \key{select * from}
\p{R, S} dargestellt:

\begin{center}
\begin{tabular}{| c |}
\hline
\bf{R} \\
\hline
\hline
1 \\
\hline
2 \\
\hline
3 \\
\hline
\end{tabular}
\end{center}

\begin{center}
\begin{tabular}{| c |}
\hline
\bf{S} \\
\hline
\hline
A \\
\hline
B \\
\hline
C \\
\hline
\key{null} \\
\hline
\end{tabular}
\end{center}

\begin{center}
\begin{tabular}{| c | c |}
\hline
\bf{T} & \\
\hline
\hline
1 & A \\
\hline
2 & A \\
\hline
3 & A \\
\hline
1 & B \\
\hline
2 & B \\
\hline
3 & B \\
\hline
1 & C \\
\hline
2 & C \\
\hline
3 & C \\
\hline
1 & \key{null} \\
\hline
2 & \key{null} \\
\hline
3 & \key{null} \\
\hline
\end{tabular}
\end{center}

Beispiel f"ur Firmendatenbank: 

\begin{xple}
\key{select} Name, Kurz 
\key{from} Mitarbeiter, Abteilung 
\key{where} Gehalt $>$ 3000
\end{xple}

Duplikatelimination und Sortierordnung k"onnen auch bei multirelaltionalen
Anfragen wie in Abschnitt \ref{Duplikatelimination und Sortierordnung}
beschrieben spezifiziert werden.

Verwendet man einen Stern (*) in der Projektionsliste einer multirelationalen
Anfrage, so besitzt die Ergebnistabelle alle Spalten der Bereichstabellen in
der Reihenfolge, in der die Bereichstabellen in der \ky{from}-Klausel
aufgelistet wurden. Insbesondere k"onnen dabei \e{Spaltennamensduplikate} in der
Ergebnistabelle auftreten, die eine Weiterbearbeitung der Ergebnistabelle
erschweren.

Anfragen "uber n$\ge$2 Bereichstabellen werden auch als 
\e{n}-Weg-Joins (\e{n way joins}) bezeichnet.

Die bisher vorgestellten Beispiele multirelationaler Anfragen benutzen als
Selektionspr"adikat einen Gleichheitstest (=) zwischen Spaltenwerten und werden
daher auch als \e{Equi-Joins} bezeichnet. Dabei handelt es sich bei den
Spalten in den Beispielen um je einen Fremdschl"ussel und einen
Prim"arschl"ussel, so da"s das Anfrageergebnis Informationen "uber die
\e{Beziehungen} zwischen Objekten in der Datenbank tabellenf"ormig darstellt.

Wesentlich seltener werden Equi-Joins zwischen Nicht-Schl"usselspalten
durchgef"uhrt. Ein Beispiel daf"ur ist die folgende Anfrage, die die Namen der
Personen, die in der Stadt ihrer Firma wohnen, bestimmt:

\begin{xple}
\key{select} p.Nr p.Titel p.Budget q.Kurz
\key{from} Projekte \key{as} p, Projektdurchf"uhrung \key{as} q
\key{where} p.Nr = q.Nr
\end{xple}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/72.eps}
\caption{Ergebnisrelation einer Equi-Joinoperation}
%\label{}  
\end{center}
\end{figure}

Joinoperationen, die anstelle eines Gleichheitstests 
(=) ein anderes zweistelliges Boole' sches Pr"adikat $\theta$
($<$, $>$, $>$=, $<$=, $<$$>$, like, ...) zum Vergleich 
der Spaltenwerte zweier Tabellen verwenden, werden zusammenfassend 
auch als \e{Theta-Joins} (\e{$\theta$-joins} bezeichnet.

Die folgende Anfrage bestimmt zum Beispiel die Namen der Personen, 
deren Monatsgehalt das Budget ihrer Abteilung "ubersteigt: 

\begin{xple}
\key{select} Name
\key{from} Mitarbeiter \key{as} m, Abteilung \key{as} a
\key{where} m.gehalt $>$ a.budget
\end{xple}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/38.eps}
\caption{Ergebnisrelation einer Joinoperation}
%\label{}  
\end{center}
\end{figure}

\subsubsection{Sichtbarkeitsregeln und Spaltennamenkonflikte}
\label{Sichtbarkeitsregeln und Spaltennamenkonflikte}

Abschnitt \ref{Schemata und Kataloge} behandelt ausf"uhrlich die Sichtbarkeit
der \e{globalen} Namen von SQL-Objekten, die in einem SQL-Schema definiert
werden. In diesem Abschnitt werden die Sichtbarkeitsregeln f"ur \e{lokale}
Namen (Spaltennamen, Bereichsvariablennamen) innerhalb von kalk"ulorientierten
SQL-Anfragen erkl"art.

Man betrachte hierzu die allgemeine Form einer \ky{select from where}-Anfrage:

\begin{xple}
\key{select} P 
\key{from} T$_{1}$, T$_{2}$,\dots, T$_{n}$
\key{where} S;
\end{xple} 

In den Teilausdr"ucken \p{P, S,} \p{T$_{1}$}, \p{T$_{2}$},\dots, \p{T$_{n}$}
sind alle globalen Namen von SQL-Objekten (Tabellen, Sichten, Schemata,
Kataloge) sichtbar. Im Selektionspr"adikat \p{S} und in der Projektionsliste
\p{P} sind zus"atzlich die \e{lokalen} Namen aller Spalten aller
Bereichstabellen \p{T$_{i}$} sichtbar. Dabei \e{"uberdeckt} ein lokaler Name
einen globalen Namen.

Bei der Evolution gro"ser Datenbankschemata treten unweigerlich Namenskonflikte
zwischen den Spaltennamen verschiedener Tabellen sowie zwischen Spaltennamen
und globalen Namen auf. Daher existiert in SQL-Anfragen die M"oglichkeit zur
Definition lokaler \e{Bereichsvariablen} (\e{correlation names, alias names}),
die zur Qualifizierung von Spaltennamen mittels Punktnotation im
Selektionspr"adikat und der Projektionsliste eingesetzt werden k"onnen:

\begin{xple}
\key{select} P 
\key{from} T$_{1}$ \key{as} X$_{1}$, T$_{2}$ \key{as} X$_{2}$,\dots, T$_{n}$ \key{as} X$_{n}$
\key{where} S;
\end{xple} 

  
Bei dieser Form von SQL-Anfragen sind im Selektionspr"adikat \p{S} und in der
Projektionsliste \p{P} zus"atzlich zu den globalen Namen nur die lokalen
Bereichsvariablen \p{X$_{i}$} sichtbar. Wiederum "uberdeckt ein lokaler
Bereichsvariablenname einen globalen Namen.

\begin{xple}
\key{select} Mitarbeiter.*
\key{from} Angestellte \key{as} Mitarbeiter
\key{where} Mitarbeiter.gehalt $>$ 3000;
\end{xple}

Der Bezeichner \p{Mitarbeiter} der obigen Anfrage "uberdeckt in diesem Fall den
Namen der gleichlautenden Tabelle \p{Mitarbeiter}, die im Schema des
Firmeninformationssystems definiert ist.

Mithilfe der Notation \p{Bereichsvariable.*} ist es m"oglich, in der
Projektionsliste alle Attribute einer Bereichstabelle zu bezeichnen.  In
folgendem Beispiel werden durch \p{m.*} die Attribute \p{m.Name}, \p{m.Alter}
und \p{m.Gehalt} spezifiziert.

\begin{xple}
\key{select} m.* 
\key{from} Mitarbeiter \key{as} m
\key{where} m.gehalt $>$ 3000;
\end{xple}

Abschlie"send sei erw"ahnt, da"s es sich in der Praxis aus mehreren Gr"unden als
sinnvoll erwiesen hat, in SQL-Anfragen \e{immer} Bereichsvariablen zu
verwenden:

\begin{itemize}
\item \e{Lesbarkeit}: Es ist unmittelbar (ohne Nachschlagen im DB-Schema) zu
  erkennen, zu welcher Bereichstabelle ein Spaltenname geh"ort.

\item \e{Wartbarkeit}: Probleme durch Spaltennamenkonflite und das unerwartete
  Verdecken von Tabellennamen bei Schema"anderungen (Anf"ugen neuer Spalten
  oder beim Umbenennen von Spalten) werden f"ur die gesamte Lebensdauer der
  Datenbank ausgeschlossen.

\item \e{Ausdrucksm"achtigkeit}: Es wird m"oglich, \e{reflexive} Anfragen zu
  formulieren. Dies sind Anfragen, in denen \e{mehrere} Reihen \e{einer}
  Tabelle verkn"upft werden, zum Beispiel, um mit rekursiven Beziehungen
  zwischen Datenbankobjekten zu arbeiten.

  Zum Beispiel liefert die folgende Anfrage die Namen von Ober- und
  Unterabteilungen in tabellarischer Form.

\begin{xple}
\key{select} o.Name \key{as} Oberabteilung, u.Name \key{as} Unterabteilung 
\key{from} Abteilung \key{as} o, Abteilung \key{as} u
\key{where} u.Oberabteilung = o.Kurz
\end{xple}

\end{itemize}

Die genannten Vorteile von Bereichsvariablen haben dazu gef"uhrt, da"s
praktisch alle modernen kalk"ulorientierten Datenbanksprachen (SQL, QUEL, QBE)
die Benutzung von Bereichsvariablen erzwingen.

\subsubsection{Einfache und quantifizierte Pr"adikate}
\label{Einfache und quantifizierte Pr"adikate}

\comment{Formulierung Todo !!!!}
SQL-Pr"adikate entsprechen Boole' schen Ausdr"ucken in Programmiersprachen. 
Leistungsm"achtiger weil wertorientiert und Iterationsabstraktion.

Stark schl"usselwortorientiert, Bindungsst"arke nicht hier erl"autert.

Zu den meisten der im folgenden betrachteten Operatoren gibt es ein negiertes
Gegenst"uck, deren Semantik in Tabelle \ref{Nullwerttests} betrachtet wird.

\begin{description}
\item [Vergleichsoperatoren] In SQL gibt es die "ublichen Operatoren f"ur den
  Vergleich \p{a $\theta$ b} zweier Werte \p{a} und \p{b}.  Dabei k"onnen f"ur
  $\theta$ die allgemein bekannten Operatoren $<$, $>$, $>$=, $<$=, und $<>$
  eingesetzt werden.

  Eine wichtige Rolle spielen in SQL die Nullwerte. Es gibt daher spezielle
  Vergleichsoperatoren f"ur den Test auf Nullwerte.

\begin{xple}
 x \key{is null}
 x \key{is not null}
\end{xple}

Die Operatoren \key{null} und \key{not null} k"onnen auch auf Werte mit mehreren
Spalten angewandt werden. Die resultierende Semantik ist dabei allerdings nicht
ganz selbstverst"andlich und wird deshalb in Tabelle \ref{Nullwerttests}
erl"autert.

\begin{table}
\begin{center}
\begin{tabular}[htb]{|l|c|c|c|c|}
\hline
&  & & & \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Pr"adikat}} &
\raisebox{1.5ex}[0cm][0cm] {\p{x \key{is}}} & 
\raisebox{1.5ex}[0cm][0cm] {\p{x \key{is}}} & 
\raisebox{1.5ex}[0cm][0cm] {\key{not} \p{x}} & 
\raisebox{1.5ex}[0cm][0cm] {\key{not} \p{x \key{is}}} \\
& \raisebox{1.5ex}[0cm][0cm] {\key{null}} &
\raisebox{1.5ex}[0cm][0cm] {\key{not null}} &
\raisebox{1.5ex}[0cm][0cm] {\key{is null}} &
\raisebox{1.5ex}[0cm][0cm] {\key{not null}} \\
\hline
\hline
x ist gleich & \multicolumn{1}{|p{1.8cm}|}{} & \multicolumn{1}{|p{1.8cm}|}{} &
\multicolumn{1}{|p{1.8cm}|}{}  & \multicolumn{1}{|p{1.8cm}|}{}\\
dem Nullwert 
& \raisebox{1.5ex}[0cm][0cm] {\key{true}} 
& \raisebox{1.5ex}[0cm][0cm] {\key{false}} 
& \raisebox{1.5ex}[0cm][0cm] {\key{false}}
& \raisebox{1.5ex}[0cm][0cm] {\key{true}} \\
\hline
x ist nicht      & & & & \\
der Nullwert 
& \raisebox{1.5ex}[0cm][0cm] {\key{false}} 
& \raisebox{1.5ex}[0cm][0cm] {\key{true}} 
& \raisebox{1.5ex}[0cm][0cm] {\key{true}}
& \raisebox{1.5ex}[0cm][0cm] {\key{false}} \\
\hline
x = (x$_1$, x$_2$, x$_3$), & & & & \\
kein Wert x$_i$  & \key{false} & \key{true} & \key{true} & \key{false}\\
ist  gleich dem Nullwert & & & & \\
\hline
x = (x$_1$, x$_2$, x$_3$), & & & & \\
mindestens ein Wert x$_i$ & \key{false} & \key{false} & \key{true} & \key{true} \\
ist gleich dem Nullwert & & & & \\
\hline
x = (x$_1$, x$_2$, x$_3$), & & & & \\
alle Werte x$_i$ & \key{true} &  \key{false} &  \key{false} & \key{true} \\
sind gleich dem Nullwert & & & & \\
\hline
\end{tabular}
\end{center}
\caption{Semantik des Nullwerttests}
\label{Nullwerttests}
\end{table}

Neben diesen allgemeinen Vergleichsoperatoren werden auch solche unterst"utzt,
die auf spezielle Datentypen ausgerichtet sind.  Der wichtigste Operator dieser
Art ist \key{like}, das einen partiellen Vergleich von Zeichenketten erlaubt.
Es wird wie die anderen Operatoren in Infixnotation benutzt. Die mit \p{a}
\key{like} \p{b} verglichenen Zeichenketten k"onnen die \e{wildcards} \% und \_
enthalten, wobei \_ f"ur einen beliebigen Buchstaben und \% f"ur keinen, einen
oder beliebig viele beliebige Buchstaben steht. In einem Zeichenstring k"onnen
mehrere dieser Zeichen vorkommen, wodurch sich eine hohe Flexibilit"at in der
Formulierung partieller Suchanfragen ergibt.

\begin{xple}
   x \key{like} '\%Software Version \_.\_'
\end{xple} 

Mit dem Operator \key{between} kann "uberpr"uft werden, ob ein 
Wert \p{x} in einem durch zwei Werte \p{a} und \p{b} spezifizierten 
geschlossenen Intervall liegt: 

\begin{xple}
   x \key{between} a \key{and} b
\end{xple} 

Dieses Pr"adikat ist "aquivalent zu 

\begin{xple}
   a $<=$ x \key{and} x $<=$ b
\end{xple} 

Der \ky{between}-Operator existiert auch in negierter Form. Syntax und 
Semantik sind in Tabelle \ref{Semantik der Praedikate} aufgef"uhrt.  
 
Ebenfalls mit Intervallen befa"st sich der Operator \key{overlaps}. 

\begin{xple}
  a \key{overlaps} b
\end{xple}

Er "uberpr"uft, ob sich zwei Zeitintervalle \p{a} und \p{b} "uberlappen und ist
damit besonders f"ur den Bereich der Terminplanung geeignet.  Die verglichenen
Zeitintervalle k"onnen dabei entweder durch einen Start- und einen Endzeitpunkt
oder durch einen Startzeitpunkt und die Dauer des Intervalls festgelegt werden,
wobei \p{a} und \p{b} nicht auf die gleiche Weise spezifiziert sein m"ussen.
Zwei Intervalle "uberlappen nicht, wenn sie sich nur ber"uhren, d.h. wenn der
Endzeitpunkt des fr"uheren Intervalls der Startzeitpunkt des sp"ateren
Intervalls ist.

\item [Enthaltenseinstest:] Der \ky{in}-Operator "uberpr"uft, ob ein Wert
  \p{x} in einer Menge \p{m} von anderen Werten enthalten ist. Die Menge \p{m}
  kann dabei wie im folgenden Beispiel durch die Aufz"ahlung ihrer Elemente
  angegeben werden.

\begin{xple}
x \key{in} (1, 2, 4, 8, 16, 32)
\end{xple}

Es ist aber auch m"oglich, eine Unteranfrage (\e{subquery}) anzugeben, deren
Ergebnis die untersuchte Menge \p{m} bildet.

\begin{xple}
x \key{in} (\key{select} name \key{from} Mitarbeiter \key{where} gehalt $>$ 3000)
\end{xple}


\item [Quantifizierte Pr"adikate:] SQL unterst"utzt auch Operatoren, die (mit
  einigen Einschr"ankungen) die Formulierung von quantifizierten Pr"adikaten
  erlaubt. Ein Pr"adikat \p{x} $\theta$ \key{all} \p{s} das den Operator \p{all}
  enth"alt\footnote{F"ur $\theta$ sind dabei wieder die bereits weiter oben
    aufgelisteten Vergleichsoperatoren zul"assig.}, entspricht in etwa dem
  folgenden universell quantifizierten Pr"adikat mit einer impliziten
  Bereichsvariablen \p{y}, die mit dem universellen Quantor an das
  Anfrageergebnis gebunden ist.

\begin{xple}
 $\forall$ y $\in$ s : x $\theta$ y
\end{xple}
Das Pr"adikat ist also nur erf"ullt, wenn f"ur alle Elemente \p{y} des
Anfrageergebnisses x $\theta$ y gilt.
 
Analog dazu ist auch die Formulierung existentiell quantifizierter Pr"adikate
in SQL m"oglich. Wie der Tabelle \ref{Semantik der Praedikate} zu entnehmen
ist, kann daf"ur wahlweise der Operator \key{some} oder der Operator \key{any}
benutzt werden. Das Pr"adikat \p{x} $\theta$ \key{some} \p{s} ergibt also den
Wahrheitswert \p{true}, wenn f"ur mindestens ein Ergebniselement \p{y} zur
Anfrage \p{s} die Bedingung \p{x $\theta$ y} erf"ullt ist.

%\comment{Etwas zu den Einschr"ankungen, Beispiele ??} 

\item [Test auf Leerheit und Eindeutigkeit:] Der Operator \key{exists}
  suggeriert durch seinen Namen zwar eine Verbindung zur existentiellen
  Quantizierung, dient jedoch in SQL dazu, die Leerheit eines
  Anfrageergebnisses zu testen. Er kann auf Unteranfragen (\e{subqueries})
  angewandt werden und liefert den Wahrheitswert \p{true}, falls das Ergebnis
  dieser Anfrage mindestens ein Element enth"alt. So "uberpr"uft die folgende
  Anfrage, ob es einen Mitarbeiter gibt, der mehr als 10000 DM verdient.

\begin{xple}
\key{exists} (\key{select} * \key{from} Mitarbeiter \key{where} gehalt $>$ 10000
\end{xple}

Der Pr"afixoperator \key{unique} wird ebenfalls auf Unteranfragen angewandt und
"uberpr"uft, ob das Anfrageergebnis Duplikate enth"alt. Er ist nicht zu
verwechseln mit dem Operator \key{distinct}, der eine Duplikatelimination
durchf"uhrt (s. Abschnitt \ref{Duplikatelimination und Sortierordnung}).
\end{description}

%Erkl"are Problem mit \e{Universeller Quantifizierung}: 
%SQL p. 142

\begin{table}
\begin{center}
\begin{tabular}[htb]{|l|l|l|}
\hline
&  & \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Pr"adikat}} &
\raisebox{1.5ex}[0cm][0cm] {\bf{"Aquivalentes Pr"adikat}} & 
\raisebox{1.5ex}[0cm][0cm] {\bf{Bemerkung}} \\
\hline
\hline
x \key{is between} a \key{and} b & a $<$= x \key{and} x $<$= b & \\
x \key{is not between} a \key{and} b & \key{not}(x \key{between} a \key{and} b) & \\
\hline
a in m & a = m$_1$ \key{or} a =  m$_2$ \key{or} \dots a= m$_n$ & \\
       &   mit m = \{m$_1$, m$_2$, \dots, m$_n$\} & \\
a \key{not in} m & not(a \key{in} m) & \\
\hline
(s$_1$, e$_1$) \key{overlaps} (s$_2$, e$_2$) & (s$_1$ $<$ s$_2$  \key{and} e$_1$ $>$ s$_2$) \key{or} & \\
   &                               (s$_2$ $<$ s$_1$ \key{and} e$_2$ $>$ s$_1$) & \\
\hline
is not null & & \\
\hline
x $\theta$ \key{all} s & $\forall$ y $\in$ s : x $\theta$ y & mit Einschr"ankung\\
\hline
x $\theta$ \key{some} s & $\exists$ y $\in$ s : x $\theta$ y & \\
x $\theta$ \key{any} s & \raisebox{1.5ex}[0cm][0cm] {$\exists$ t $\in$ s : x $\theta$ t} &\\ 
\hline
\end{tabular}
\end{center}
\caption{"Aquivalente Pr"adikate}
\label{Semantik der Praedikate}
\end{table}

Aus den beschriebenen Pr"adikaten k"onnen durch konjunktive (\key{and}) 
und disjunktive (\key{or}) Verkn"upfung komplexere Pr"adikate 
aufgebaut werden. Au"serdem kann jedes Pr"adikat durch Voranstellen des 
\ky{not}-Operators negiert werden. Wie in Abschnitt \ref{Nullwerte 
und Wahrheitswerte} erl"autert, ist dabei zu beachten, da"s es sich hier
wegen der Existenz der Nullwerte um eine dreiwertige Logik handelt. 
Die entsprechenden Wahrheitstabellen f"ur die Operatoren \key{and}, 
\key{or} und \key{not} sind in Abschnitt \ref{Nullwerte und Wahrheitswerte}
zu finden. 

aussagenlogisch, pr"adikatenlogik 1. Stufe.

Generelles Problem: Sichtbarkeitsbereich gebundener Variablen. 
Analogie: Blockstrukturierung in Programmiersprachen. Wie in\#\# 
erkl"art. Menge der globalen Variablen enth"alt auch lokale Variablen 
des umfassenden Blocks.

\subsubsection{Algebraische Tabellenoperationen}
\label{Algebraische Tabellenoperationen}

Die aus der Mengenalgebra bekannten Operationen Mengenvereinigung,
Schnittmengenbildung und Mengendifferenz werden in SQL-92 auf Tabellen
"ubertragen. Mit den Operatoren \key{union}, \key{intersect} und \key{except}
k"onnen Tabellen in Anfragen miteinander verkn"upft werden. In der folgenden
Anfrage werden die Mengen der Mitarbeiter zweier Abteilungen miteinander
verkn"upft.

\begin{xple}
\key{select} *
\key{from} MitarbeiterAbt1
\key{union}
\key{select} *
\key{from} MitarbeiterAbt2
\end{xple}

In Anlehnung an die Mengenvereinigung f"uhrt die Operation \key{union}
automatisch eine Duplikatelimination durch.  Es existiert jedoch die
zus"atzliche Option \key{all}, um diese Duplikatelimination zu unterdr"ucken.
Die Option \key{all} kann auch im Zusammenhang mit dem Operator \key{intersect}
verwendet werden.

Voraussetzung f"ur die Verkn"upfung mit einer der algebraischen
Tabellenoperationen ist die Kompatibilit"at der Spaltenstruktur
der beteiligten Tabellen. Dies erfordert unter anderem, da"s die Spalten der
Tabellen die gleichen Namen und Datentypen besitzen m"ussen.  Die Forderung
nach der Kompatibilt"at kann auf einen Teil der Spalten eingeschr"ankt werden,
indem man den jeweiligen Operator um eine \ky{corresponding}-Klausel erweitert.
Es werden dann nur die kompatiblen Spalten der beiden Tabellen ber"ucksichtigt
und die Ergebnistabelle enth"alt ebenfalls nur die kompatiblen Spalten.

\begin{xple}
 x
\end{xple}

Eine weitere Einschr"ankung ist durch die explizite Nennung von Spaltennamen in
der \ky{corresponding}-Klausel m"oglich.  Sowohl die Kompatibilit"atspr"ufung
als auch das Ergebnis beziehen sich in diesem Fall ausschlie"slich auf die
genannten Spalten.

Eine weitere wichtige Klasse algebraischer Tabellenoperationen sind
die bereits in Abschnitt \ref{Die Anfragesprache SQL} erw"ahnten
Join-Operationen.  Wegen der zentralen Bedeutung dieser Operationen
f"ur das relationale Modell und der zahlreichen Varianten, die in
SQL-92 daf"ur vorgesehen sind, ist diesen Operationen ein eigener
Abschnitt (\ref{Multirelationale Select From Where-Anfragen}) gewidmet.

\subsubsection{Join-Operationen}
\label{Join-Operationen}

\comment{Au"serdem SQL-92: (152-162)
Komplexe Sichtbarkeitsregeln fuer Zielausdruck}

Die Grundlage von \e{Join-Operationen} ist die Bildung des kartesischen
Produkts "uber zwei oder mehr Tabellen.  In den meisten F"allen wird dieses
Produkt durch explizit spezifizierte oder implizit im speziellen Operator
enthaltenen \e{Join-Bedingungen} auf einen Ausschnitt eingeschr"ankt.
Join-Operationen werden in der \ky{from}-Klausel verwendet (??).  \comment{
  Vielleicht noch etwas mehr grunds"atzliches ??}

SQL-92 f"uhrt eine explizite Behandlung von Join-Operationen mit einer
Vielzahl verschiedener Varianten ein. Die M"oglichkeit
Join-Operationen auszudr"ucken ist jedoch zentral f"ur das relationale
Modell und existiert bereits in fr"uheren SQL-Versionen. Wie in
Abschnitt \ref{Multirelationale Select From Where-Anfragen} erw"ahnt,
gen"ugt es, in der \ky{from}-Klausel mehrere Tabellen aufzuf"uhren, was
der Bildung des kartesischen Produkts "uber diese Tabellen entspricht.
Die Join-Bedingung kann in der \ky{where}-Klausel der Anfrage
festgelegt werden.

Die unterschiedlichen Varianten der Join-Operationen in SQL-92 
lassen sich grunds"atzlich in zwei Klassen einteilen. 

\begin{itemize}
\item Das Ergebnis eines \e{inner Join} enth"alt nur den Teil des
  kartesischen Produkts, der die Join-Bedingungen erf"ullt.
 
\item Beim \e{outer Join} wird noch weitere Information aus den beteiligten
  Tabellen in das Ergebnis aufgenommen.
\end{itemize}

Die Varianten des \e{inner} Join, von denen die wichtigsten im folgenden kurz
beschrieben werden, unterscheiden sich haupts"achlich in der Handhabung der
Join-Bedingung (z.B. explizite oder implizite Angabe von Join-Bedingungen).

\begin{description}
\item [Kartesisches Produkt:] Der einfachste Join-Operator ist der \e{cross
    join}.  Er dient zur Bildung des kartesisches Produkt aus den beteiligten
  Tabellen.  Die Verwendung dieses Operators ist "aquivalent zur einfachen
  Auflistung mehrerer Tabellen in der \ky{from}-Klausel, macht jedoch die
  Durchf"uhrung des Joins explizit.  Einschr"ankende Join-Bedingungen werden in
  beiden F"allen durch die \ky{where}-Klausel festgelegt.

\item [Join mit Bedingung:] Dieser Operator enth"alt eine \ky{on}-Klausel, in
  der eine beliebige Join-Bedingung festgelegt werden kann.  Wie im folgenden
  Beispiel zu sehen ist, werden die beteiligten Tabellen durch den Operator
  \e{join} miteinander verbunden.

\comment{
 Beispiel mit Gleichsetzen bestimmter Spalten
Beachte Scopes}

Die Join-Bedingung kann "aquivalent auch "uber die \ky{where}-Klausel festgelegt
werden.  Die Verwendung der \ky{on}-Klausel gestattet jedoch eine explizite
Zuordnung der Bedingung zur Join-Operation, w"ahrend weitere Einschr"ankungen
der durch die Join-Operation entstandenen Tabelle in der \ky{where}-Klausel
zusammengefa"st werden k"onnen.

Join mit Bedingung ist der allgemeinste Join-Operator in der Klasse der
\e{inner joins}; alle "ubrigen Operatoren lassen sich mit Hilfe dieses
Operators ausdr"ucken, wenn auch nicht in generischer Form.

\item [Natural Join:] Der \e{natural Join}, auch \e{natural equi-join}
  genannt, und der \e{Join mit Spaltennamen} (s.u.) besitzen implizite
  Join-Bedingungen als Teil der Operatorensemantik. Sie basieren auf der
  Annahme, da"s Spalten die den gleichen Namen besitzen, auch vergleichbare
  Inhalte enthalten. Bei der Ausf"uhrung eines \e{natural} Join werden n"amlich
  alle Spalten mit den gleichen Spaltennamen verglichen. Alle Paare von Reihen
  der ersten und zweiten Tabelle, die in all diesen Spalten die gleiche Werte
  besitzen, werden in die Ergebnistabelle aufgenommen.  Zus"atzlich wird auf
  der Ergebnistabelle eine Projektion durchgef"uhrt, die verhindert, da"s die
  gleichnamigen Spalten im Ergebnis doppelt auftreten.

\comment{Hauptanwendung?? Beipiel??}

"Aquivalentes Attribut, evtl. in Tabelle ???

t1  natural join t2
select 
from t1 as x t2 as y
where 
  x.a = y.a and x.b =y.b
 
wobei a und b Attribute sowohl von t1 als auch von t2 sind. 

Beispiel

\item [Join mit Spaltennamen] Diese Variante der Join-Operation l"a"st eine
  Einschr"ankung des Natural Joins auf einen Teil der gleichnamigen Spalten zu.
  Die implizite Join-Bedingung vergleicht nicht wie beim Natural Join alle
  gleichnamigen Spalten, sondern nur die, deren Namen explizit in der
  \ky{using}-Klausel des Operators aufgef"uhrt wird.

t1 join t2 using (a,b) 

\comment{Beachte Nutzung der Spatenbezeichner im where-Pr"adikat !!
s.S. 160}
\end{description}

Beim \e{inner} Join ist die Information aus Zeilen der verbundenen Tabellen,
die nicht die Join-Bedingung erf"ullen, nicht in der Ergebnistabelle enthalten.
Idee des \e{outer} Joins ist es, diese Information (oder zumindest ein Teil
davon) mit in die Ergebnistabelle aufzunehmen. Die Join-Bedingung wird beim
\e{outer} Join ebenfalls in einer \ky{on}-Klausel festgelegt.  (vgl. Join mit
Bedingung).

Zur Erl"auterung des \e{outer} Join wird von zwei Tabellen t$_1$ und t$_2$ mit
n bzw. m Spalten ausgegangen. Wenn keine Projektion durchgef"uhrt wird, hat die
Ergebnistabelle n+m Spalten.  Es wird dabei zwischen dem \e{left outer Join},
dem \e{right outer Join} und dem \e{full outer Join} unterschieden.

Die Ergebnistabelle eines \e{left outer} Joins kann man sich als aus zwei
Teilen a und b zusammengesetzt vorstellen. Der erste Teil (a) entspricht dem
Ergebnis eines \e{inner} Joins mit der gleichen Join-Bedingung. Teil b enth"alt
all die Reihen der Tabelle t$_1$, die in Teil a nicht auftreten.  Diese
Information f"ullt aber nur die ersten n Spalten dieses Teils der
Ergebnistabelle, die "ubrigen m Spalten werden mit Nullwerten aufgef"ullt.

Das Ergenis eines \e{right outer} Joins setzt sich analog zusammen, nur da"s
der Teil b der Ergebnistabelle die nicht ber"ucksichtigten Zeilen der Tabelle
t$_2$ enth"alt, d.h. in diesem Fall werden die ersten n Spalten mit Nullwerten
aufgef"ullt.

Beim \e{full outer} Join setzt sich das Ergebnis aus drei Teilen zusammen: den
beiden Teilen, die beim \e{left outer} Join auftreten plus dem zweiten Teil des
Ergebnisses des \e{right outer} Joins.

Im Gegensatz zum \e{inner} Join sind die \e{outer} Join-Operatoren nicht
assoziativ.

Die folgende Tabelle fa"st noch einmal die einzelnen Varianten der
Join-Operationen zusammen. Es wird dabei von einer Tabelle t$_1$ mit den Spalte
a, b, c und einer Tabelle t$_2$ mit den Spalten b, c, d, e ausgegangen.

\begin{table}
\begin{center}
\begin{tabular}{|l|l|l|l|}
\hline
& & &   \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Join-Operation}} &
\raisebox{1.5ex}[0cm][0cm] {\bf{Bezeichnung}} &
\raisebox{1.5ex}[0cm][0cm] {\bf{"Aquivalente Operation}} &
\raisebox{1.5ex}[0cm][0cm] {\bf{Bemerkung}} 
 \\
\hline
\hline
\key{select} P(t$_1$, t$_2$) & \e{natural} Join & \key{select} & \\
\key{from} t$_1$ \key{natural join} t$_2$         & \key{from} t$_1$, t$_2$ & \\
& &                                         & \key{where} XXX \\
\hline
\end{tabular}
\end{center}
\caption{Join-Operationen in SQL-92}
\label{Join-Operationen in SQL-92}
\end{table}

t1  natural join t2
select 
from t1 as x t2 as y
where 
  x.a = y.a and x.b =y.b

  bestimmte Join-Operationen sind besonders wichtig z.B. die Verbindung von
  Tabellen die Beziehungen darstellen, oder die Verbindung von Information, die
  aufgrund von Normalisierung in mehrere Tabellen verteilt worden sind.
 

\subsubsection{Aggregatfunktionen}
\label{Aggregatfunktionen}

In der Projektionsliste (\ky{select}-Klausel) einer SQL-Anfrage k"onnen
sogenannte \e{Aggregatfunktionen} benutzt werden. Diese Funktionen dienen der
Berechnung aggregierter Werte wie z.B. der Summe "uber alle Werte einer Spalte
in einer Tabelle. Die folgende Anfrage berechnet z.B.\ die Summe und das
Maximum der Budgets aller Projekte.

\begin{xple}
  \key{select} \key{sum}(p.Budget), \key{max}(p.Budget)
  \key{from} Projekte \key{as} p
\end{xple}

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

SQL unterst"utzt neben Funktionen zum Berechnen der Summe (\key{sum}), des
Maximums (\key{max}), des Minimums (\key{min}) und des Durchschnitts
(\key{avg}) auch eine Funktion \key{count} zum Z"ahlen der Werte in einer
Tabelle. Die Funktion \key{count} kann anders als die anderen Funktionen nicht
nur auf eine einzelne Spalte sondern durch den Aufruf \key{count}(*) auch auf
gesamte Tupel angewandt werden. So ermittelt die folgende Anfrage die Anzahl
der Tupel in der Relation \p{Abteilungen}.

\begin{xple}
  \key{select} \key{count}(*)
  \key{from} Abteilungen 
\end{xple}

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

In manchen Situationen ist es notwendig beim Z"ahlen von Werten
Duplikate auszu\-schlie"sen. So ist z.B. die folgende Anfrage zur 
Berechnung der Anzahl aller Oberabteilungen ungeeignet, da sie 
Abteilungen mit mehreren Unterabteilungen mehrfach z"ahlt. 

\begin{xple}
  \key{select} \key{count}(a.Oberabteilung)
  \key{from} Abteilungen \key{as} a
  \key{where} a.Oberabteilung \key{is not null}
\end{xple}

Um dies zu verhindern, bietet SQL das Schl"usselwort \key{distict} an. 

\begin{xple}
  \key{select} \key{count}(\key{distinct} a.Oberabteilung)
  \key{from} Abteilungen \key{as} a
  \key{where} a.Oberabteilung \key{is not null}
\end{xple}

In diesem Fall werden mehrfach auftretende Spaltenwerte nur einfach
gez"ahlt (vgl. Duplikatelimination in Abschnitt
\ref{Duplikatelimination und Sortierordnung}).  \key{distinct} kann mit
der entsprechenden Semantik auch mit den anderen Aggregatfunktionen
kombiniert werden.

\subsubsection{Gruppierung}
\label{Gruppierung}

Zeilen einer Tabelle werden abh"angig von den Werten in bestimmten Spalten, den
sogenannten \e{Gruppierungsspalten}, zu Gruppen zusammengefa"st. Alle Zeilen
einer Gruppe enthalten in dieser Spalte bzw. in diesen Spalten den gleichen
Wert.  Man erh"alt auf diese Weise eine Tabelle von Gruppen als
Zwischenergebnis.
 
Wenn eine Anfrage eine \ky{group by}-Klausel enth"alt, gibt es einige 
Einschr"ankungen. F"ur die \ky{select}-Klausel sind in diesem Fall nur 
Ausdr"ucke der folgenden Art zul"assig:

\begin{itemize}
\item Spalten aus der \ky{group by}-Klausel, 

\item Aufrufe von Aggregatfunktionen und

\item Konstanten; 
\end{itemize}

Aggregatfunktionen werden bei gruppierten Tabellen auf die einzelnen 
Gruppen angewandt. Die Ergebnistabelle enth"alt also einen aggregierten 
Wert pro Gruppe.  

\begin{xple}
\key{select} Oberabt, \key{count}(Kurz)
\key{from} Abteilungen
\key{group by} Oberabt;
\end{xple}

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

Zus"atzlich ist es auch m"oglich, Bedingungen f"ur die Gruppen einer
gruppierten Tabellen festzulegen. Zu diesem Zweck wird die \ky{having}-Klausel
verwendet. Sie definiert einen Filter f"ur die Gruppen. Nur Gruppen, die die
Filterbedingung erf"ullen, werden im Ergebnis der Anfrage ber"ucksichtigt.  Die
mit der \ky{having}-Klausel eingef"uhrte Bedingung wird nicht auf einzelne
Zeilen, sondern auf Gruppen angewandt.  Es k"onnen deshalb in der Bedingung nur
Gruppierungsspalten direkt referenziert werden\footnote{Diese haben f"ur alle
  Reihen einer Gruppe denselben Wert.}. Auf andere Spalten kann nur als
Parameter einer Aggregatfunktion zugegriffen werden.
 
Wenn eine SQL-Anfrage zwar eine \ky{having}-Klausel, aber keine \ky{group
  by}-Klausel enth"alt, wird die ganze Tabelle als eine Gruppe betrachtet.

%\comment{GROUP BY HAVING ...

%Betone Nicht-Orthogonalit"at der Konzepte (Schachtelung, Viewdefinition 
%(p.196) ...}

\subsection{"Anderungsoperationen in SQL}
\label{Aenderungsoperationen in SQL}

Die folgenden Abschnitte behandeln Operationen, die den Inhalt von Tabellen
"andern.  Sie beziehen sich jeweils auf eine einzelne Relation.

\subsubsection{update-Anweisung}
\label{update-Anweisung}

Die \ky{update}-Anweisung dient zur Modifikation von Attributwerten. Der Effekt
einer \ky{update}-Anweisung ist dabei nicht notwendigerweise auf ein einzelnes
Tupel beschr"ankt.  Vielmehr kann die Menge der betroffenen Tupel "ahnlich wie
bei einer SQL-Anfrage durch ein beliebiges, in einer \ky{where}-Klausel
spezifiziertes Pr"adikat festgelegt werden.

Eine \ky{update}-Anweisung besteht aus drei Teilen. Im ersten Teil wird die
betroffene Tabelle festgelegt. Der zweite Teil wird durch das Schl"usselwort
\key{set} eingeleitet. In ihm findet die Zuweisung der neuen Attributwerte
statt.

Alle Tupel, die das Pr"adikat, welches mit einer \ky{where}-Klausel formuliert
wird, erf"ullen, werden modifiziert. 

Im einfachsten Fall wird einem Attribut unabh"angig von seinem
bisherigen Wert ein neuer Wert zugeordnet.  So erh"alt durch die
folgende Anweisung das Projekt \glqq DB Fahrplaene\grqq\ ein neues
Budget von DM 500.000.

\begin{xple}
\key{update} Projekte
\key{set} Budget = 500000
\key{where} Titel = 'DB Fahrplaene';
\end{xple}

Es ist aber auch m"oglich den neuen Attributwert in Abh"angigkeit vom alten
Attributwert festzulegen, wie dies im folgenden Beispiel geschieht.

\begin{xple}
\key{update} Mitarbeiter
\key{set} Gehalt = Gehalt + 100
\key{where} Gehalt $\le$ 3000
\end{xple}

Der dritte, optionale Teil einer \ky{update}-Operation ist die bereits erw"ahnte
\ky{where}-Klausel zur Selektion der betroffenen Tupel. Wenn die
\ky{where}-Klausel fehlt werden alle Tupel der Tabelle modifiziert.

Eine Verwendung von Unterabfragen in der \ky{where}-Klausel ist m"oglich.
Diese Unterliegen in diesem Fall aber einigen Einschr"ankungen. 

\subsubsection{insert-Anweisung}
\label{insert-Anweisung}

Die Position des eingef"ugten Tupels in der Tabelle ist unspezifiziert. Es
kann z.B. nicht davon ausgegangen werden, da"s neue Tupel hinten an die Tabelle
angeh"angt werden, oder da"s eine Sortierung nach den Prim"arschl"usseln
aufrechterhalten wird.  Die Positionierung neuer Tupel ist allein Sache der
Implementierung des DBMS.

Wenn Attributnamen angegeben werden, ist es nicht notwendig, R"ucksicht auf
Reihenfolge der Spalten in der Tabelle zu nehmen.  Wird f"ur alle Attribute ein
Wert festgelegt und geschieht die Nennung der Werte exakt in der Reihenfolge,
in der die zugeh"origen Spalten in der Tabelle auftreten, kann auf eine Angabe
der Attributnamen verzichtet werden. Die explizite Nennung der Attributnamen in
der \ky{insert}-Anweisung besitzt jedoch die folgenden Vorteile.

\begin{itemize}
\item Vermeidung von Fehlern in der Datenbank durch die irrt"umliche
  Vertauschung von Spalten, die zuf"allig den gleichen Datentyp besitzen.

\item Verbesserung der Robustheit gegen Schemamodifikationen wie z.B. die
  Umordnung von Reihen.

\item Erh"ohung der \e{Lesbarkeit} der Operationen, der Benutzer braucht sich
  nicht die Reihenfolge der Spalten zu merken oder nachzusehen.
\end{itemize}

Im folgenden Beispiel wird ein neues Element in die Tabelle der
Projekte eingef"ugt:

\begin{xple}
\key{insert into} Projekte
    (Nr, Titel, Budget)
\key{values} (471, 'Mensaabrechnung', 90000);
\end{xple}

\subsubsection{delete-Anweisung}
\label{delete-Anweisung}

Die \ky{delete}-Anweisung zum L"oschen von Datenelementen ist in ihrem
strukturellen Aufbau der \ky{select from where}-Anweisung sehr "ahnlich.  Sie
besitzt ebenfalls eine \ky{from}-Klausel zur Festlegung der betroffenen Tabelle
und eine \ky{where}-Klausel zur Angabe eines Selektionspr"adikates.  Da alle
Modifikationsoperationen auf eine einzelne Tabelle beschr"ankt sind, ist die
Angabe mehrerer Tabellen in der \ky{from}-Klausel anders als bei den Anfragen
bei dieser Operation nicht zul"assig.

Das folgende Beispiel zeigt, wie alle Tupel der Tabelle, die das
Selektionspr"adikat erf"ullen, durch die \ky{delete}-Anweisung gel"oscht
werden.  Das zuvor eingef"ugte Projekt \glqq Mensaabrechnung\grqq\ wird aus der
Tabelle \p{Projekte} gel"oscht.

\begin{xple}
\key{delete}
\key{from} Projekte
\key{where} Titel = 'Mensaabrechnung';
\end{xple}

Die Operation \key{delete} dient zum L"oschen einzelner Tupel aus einer Tabelle.
In SQL k"onnen jedoch Objekte sehr unterschiedlicher Granularit"at gel"oscht
werden. Die meisten der entsprechenden Operationen sind bereits in den
vorherigen Abschnitten beschrieben worden, werden aber hier noch einmal
zusammengefa"st.

\begin {itemize}
\item Zum L"oschen einzelner \e{Attributwerte} k"onnen diese Attribute mit der
  \ky{update}-Operation auf den Wert \p{null} gesetzt werden (s. Abschnitt
  \ref{update-Anweisung}).

\item Das L"oschen eines oder mehrerer ganzer \e{Tupel} geschieht mit der in
  diesem Abschnitt beschriebenen \ky{delete}-Anweisung. Welche Tupel gel"oscht
  werden, wird durch die \ky{where}-Klausel der Anweisung festgelegt.

\item L"oschen aller \e{Werte einer Spalte}.

\item Ganze \e{Spalten} k"onnen ebenfalls aus einer Tabelle entfernt werden.
  Dies entspricht einer Schema"anderung und wird deshalb alter table drop
  column (s.Abschnitt \ref{Schemata und Kataloge}) genannt.

\item L"oschen des gesamten \e{Inhalts einer Tabelle} entspricht einer
  \ky{delete}-Anweisung ohne \ky{where}-Klausel.

\item L"oschen einer ganzen \e{Tabelle} mitsamt der Datenstruktur wird durch
  drop table (s. Abschnitt \ref{Schemata und Kataloge}) erreicht.
\end{itemize}

\subsection{Integrit"atssicherung in SQL}
\label{Integritaetssicherung in SQL}

Bereits bei der "Ubersetzung jeder SQL-Anweisungen erzwingt SQL die folgenden
\e{modellinh"arenten Integrit"atsbedingungen} durch eine textuelle
Analyse der Anweisung unter Benutzung von Schemainformationen analog zur
\e{statischen Typisierung} in Programmiersprachen:

\begin{description}
\item[] \e{Typisierung der Spalten}: In einer Spalte k"onnen nur typkompatible
  Werte gespeichert werden.

\item[] \e{Homogenit"at der Reihen}: Alle Reihen einer Tabelle besitzen eine
  identische Spaltenstruktur.
\end{description}

Zur Definition \e{applikationsspezifischer Integrit"atsbedingungen} bietet SQL
zwei syntaktische Konstrukte, die beide Boole' sche Pr"adikate zur
\e{deklarativen} Integrit"atssicherung benutzen, und die durch Laufzeittests
erzwungen werden:

\begin{description}
\item[] \e{Tabellenzusicherungen} werden syntaktisch in Tabellendefinitionen
  geschachtelt spezifiziert:

\begin{xple}
\key{create table} Tabellenname 
    (\dots
     \key{constraint} Zusicherungsname \key{check}(Pr"adikat) )
\end{xple}

Eine Tabellenzusicherung garantiert, da"s in jedem Datenbankzustand die
Auswertung des Pr"adikats f"ur \e{alle} Reihen der Tabelle den Wert \key{true}
liefert. Man sagt daher auch, da"s das Pr"adikat \e{universell quantifiziert}
ist. Das Pr"adikat kann sich auf die Spaltennamen der Tabelle und auf die
globalen Namen des aktuellen SQL-Schemas beziehen (z.B. Tabellennamen).

\item[] \e{Schemazusicherungen} sind SQL-Objekte, die dynamisch dem aktuellen
  SQL-Schema hinzugef"ugt werden k"onnen:

\begin{xple}
\key{create assertion} Zusicherungsname
    \key{check}(Pr"adikat);
\end{xple}  

Eine Schemazusicherung garantiert, da"s in jedem Datenbankzustand die
Auswertung des Pr"adikats den Wert \key{true} liefert. Das Pr"adikat kann sich
nur auf die globalen Namen des aktuellen SQL-Schemas beziehen.
\end{description}

Ein Datenbankzustand hei"st \e{konsistent}, wenn er alle im Schema deklarierten
Zusicherungen erf"ult. Logisch gesehen sind daher alle Tabellen- und
Schemazusicherungen konjunktiv (mit \key{and}) verkn"upft. Das Aufspalten einer
komplexen Zusicherung der Form \key{check}\p{(Pr"adikat$_{1}$} \key{and}
\p{Pr"adikat $_{2}$}) in zwei Zusicherungen erm"oglicht jedoch die separate
\e{Benennung} von Zusicherungen:

\begin{xple}
 \key{constraint} Name$_{1}$ \key{check} (Pr"adikat$_{1}$) 
 \key{constraint} Name$_{2}$ \key{check} (Pr"adikat$_{2}$)
\end{xple}  

Zusicherungsnamen werden einerseits benutzt, um Zusicherungen explizit zu
l"oschen ( \key{drop constraint} \p{\dots}) und zu modifizieren (\key{set
  constraint} \p{\dots} \key{deferred}); andererseits k"onnen
Anwendungsprogramme beim Auftreten einer Integrit"atsverletzung den Namen der
aktuell verletzten Zusicherung bestimmen und anwendungsspezifische
Ausnahemebehandlungsoperationen ausl"osen.

Auf den ersten Blick erscheint die Unterscheidung zwischen Tabellen- und
Schemazusicherungen "uberfl"ussig, da syntaktisch gesehen jede
Schemazusicherung direkt in eine Tabellenzusicherung f"ur eine Tabelle \p{T}
umgewandelt werden kann. Jedoch besitzt die universelle Quantifizierung f"ur
Tabellen die subtile Eigenschaft, f"ur leere Tabellen immer den Wert \key{true}
zu liefern, so da"s im Fall, da"s \p{T} leer ist, die Tabellenzusicherungen von
\p{T} nicht "uberpr"uft werden.

Als Beispiel betrachte man die folgende Schemazusicherung, die 
in keinem Datenbankzustand erf"ullt ist:

\begin{xple}
\key{create assertion} unerfuellbar \key{check}(\key{false})
\end{xple}  

Die entsprechende Tabellenzusicherung

\begin{xple}
\key{create table} Mitarbeiter 
    (\dots
     \key{constraint} unerfuellbar \key{check}(\key{false}) )
\end{xple}
  
ist jedoch immer dann erf"ullt, wenn die Tabelle \p{Mitarbeiter} leer ist.  In
den folgenden Abschnitten wird die Definition von Zusicherungen mit zunehmendem
Wirkungsbereich beschrieben (Spaltenwert, Reihe, Tabelle, mehrere Tabellen).

\subsubsection{Spaltenwertintegrit"at und Dom"anendeklarationen}
\label{Spaltenwertintegritaet und Domaenendeklarationen}

Eine Tabellenzusicherung, deren Pr"adikat sich auf nur einen Spaltennamen
bezieht, garantiert die Spaltenintegrit"at und wird in folgenden
Modellierungssituationen eingesetzt:

\begin{itemize}
\item Vermeidung von \e{Nullwerten}, zum Beispiel \key{check} \p{(Alter} \key{is
    not null}\p{)},

\item Definition von \e{Unterbereichstypen}, zum Beispiel \key{check}\p{(Alter
    $>$= 0} \key{and} \p{Alter $<$= 150)},

\item Definition von \e{Formatinformationen} durch Stringvergleiche, zum
  Beispiel \key{check}\p{(Postleitzahl} \key{like} \p{'D-\_\_\_\_\_' )}

\item Definition von \e{Aufz"ahlungstypen}, zum Beispiel \key{check}\p{(Note}
  \key{in} \p{(1, 2, 3, 4, 5, 6))} oder \key{check}\p{(hatVordiplom} \key{in}
  \p{('Ja' , 'Nein' ))}
\end{itemize}

H"aufig ist es sinnvoll, eine immer wiederkehrende Kombination 
eines Basistypen mit zugeh"origen Zusicherungen in Form einer 
benannten \e{SQL-Dom"ane} im aktuellen Schema zu definieren: 

\begin{xple}
\key{create domain} Schulnote \key{integer}
    \key{constraint} NoteDefiniert \key{check}(\key{value is not null})
    \key{constraint} NoteZwischen1und6 \key{check}(\key{value in} (1, 2, 3, 4, 5, 6));
\end{xple}
  
Der Dom"anenname kann nachfolgend "uberall dort verwendet werden, wo ein
SQL-Basistypname erwartet wird.

\subsubsection{Reihenintegrit"at}
\label{Reihenintegritaet}

Eine Tabellenzusicherung, deren Pr"adikat sich auf mehrere Spaltennamen
bezieht, definiert eine Reihenintegrit"atsbedingung, die von jeder Reihe einer
Tabelle erf"ullt sein mu"s, zum Beispiel:

\begin{xple}
\key{check}(Ausgaben $<$= Einnahmen)
\key{check}((HatVordiplom, HatDiplom) \key{in values}(
          ('nein',       'nein' )
          ('ja',         'nein' )
          ('ja',         'ja')))
\end{xple}

Die zweite Zusicherung garantiert, da"s das Paar bestehend aus den
Spaltenwerten \p{HatVordiplom} und \p{HatDiplom} nur Werte aus der Menge der
aufgez"ahlten legalen Kombinationen annimmt.

\subsubsection{Tabellenintegrit"at}
\label{Tabellenintegritaet}

W"ahrend die in den vorangegangenen Abschnitten beschriebenen Zusicherungen in
Datenbanksystemen mit geringem Aufwand (ohne zus"atzliche
Sekund"arspeicherzugriffe) "uberpr"uft werden k"onnen, erfordert die
"Uberpr"ufung von \e{quantifizierten Pr"adikaten} (s. Abschnitt \ref{Einfache
  und quantifizierte Pr"adikate}) im schlimmsten Fall als Folge einer einfachen
elementorientierten "Anderungsoperation die Auswertung einer kompletten
mengenorientierter Anfrage zur Integrit"atspr"ufung.

\begin{xple}
\key{check}( (\key{select sum}(Budget) \key{from} Projekte ) $>$= 0 )
\end{xple}

oder

\begin{xple}
\key{check}( \key{exists} (\key{select} * \key{from} Abteilung \key{where} Oberabt = 'LTSW')
\end{xple}

Einige in der Praxis h"aufig auftretende quantifizierte Zusicherungen k"onnen
in Datenbanksystemen effizient mittels \e{Indexstrukturen} "uberpr"uft werden.
W"ahrend "ublicherweise die Integrit"ats"uberpr"ufung das Laufzeitverhalten von
Datenbanksystemen verschlechtert, k"onnen in diesen Situationen Zusicherungen
sogar zu einem \e{Effizienzgewinn} bei Anfragen und "Anderungsoperationen
f"uhren.

SQL-92 bietet spezielle syntaktische Konstrukte f"ur h"aufig auftretende Muster
solcher quantifizierter Zusicherungen. Dies erh"oht einerseits die
\e{Lesbarkeit} von Schemadeklarationen und erm"oglicht andererseits der
Datenbanksystemsoftware eine \e{optimierende Implementierung} von
Zusicherungen.

\begin{itemize}
\item \e{Spaltenwerteindeutigkeit}: Die Eindeutigkeit von
  Spaltenwertkombinationen in einer Tabelle gestattet eine wertbasierte
  Identifikation von Tabellenelementen.  Eine solche Spaltenkombination wird
  als \e{Schl"usselkandidat} bezeichnet.

Die SQL-Zusicherung 

\begin{xple}
\key{create table} T (\dots \key{unique}(Spaltenname$_{1}$, Spaltenname$_{2}$, \dots, Spaltenname$_{n}$))
\end{xple}

ist semantisch "aquivalent zu der folgenden quantifizierten Zusicherun:

\begin{xple}
\key{create table} T (\dots \key{check}(\key{all} x, \key{all} y :...
     ((x.Spaltenname$_{1}$ $<${}$>$ y.Spaltenname$_{1}$) \key{or}  %vorher and
      (x.Spaltenname$_{2}$ $<${}$>$ y.Spaltenname$_{2}$) \key{or}  %vorher and
       \dots
      (x.Spaltenname$_{n}$ $<${}$>$ y.Spaltenname$_{n}$))
       \key{or} x = y))
\end{xple}


Diese Langform definiert auch die Behandlung von Nullwerten in den Spalten des
Schl"usselkandidaten.

Eine Tabelle kann mehrere Schl"usselkandidaten besitzen, die durch separate
\ky{unique}-Klauseln beschrieben werden.

\item \e{Prim"arschl"usselintegrit"at:} Ein Schl"usselkandidat, in dessen
  Spalten keine Nullwerte auftreten d"urfen, kann als \e{Prim"arschl"ussel}
  ausgezeichnet werden. Eine Tabelle kann nur einen Prim"arschl"ussel besitzen.
  Die SQL-Zusicherung

\begin{xple}
\key{create table} T 
     (... 
      \key{primary key}(Spaltenname$_{1}$, Spaltenname$_{2}$, \dots, Spaltenname$_{n}$))
\end{xple}

ist "aquivalent zu der SQL-Zusicherung:

\begin{xple}
\key{create table} T 
     (...
      \key{unique} Spaltenname$_{1}$, Spaltenname$_{2}$, \dots, Spaltenname$_{n}$),
      \key{check}(Spaltenname$_{1}$ \key{is not null}),
      \key{check}(Spaltenname$_{2}$ \key{is not null}), 
      \dots,
      \key{check}(Spaltenname$_{n}$ \key{is not null}))
\end{xple}

\item \e{Referentielle Integrit"at}(Fremdschl"usselintegrit"at): Diese
  Zusicherung bezieht sich auf den Zustand \e{zweier} Tabellen und wird deshalb
  im n"achsten Abschnitt separat behandelt.
\end{itemize}

\subsubsection{Referentielle Integrit"at}
\label{Referentielle Integritaet}

Die Werte eines Schl"usselkandidaten einer Tabelle \p{T$_{Ziel}$} k"onnen als
Spaltenwerte in einer Zeile einer Tabelle \p{T$_{Quelle}$} verwendet werden, um
eine \e{Beziehung} (wertbasierte Assoziation) zwischen dieser Zeile und einer
zugeh"origen Zeile in Tabelle \p{T$_{Ziel}$} zu beschreiben (s. Abschnitt
\ref{Assoziationen im relationalen Modell}). Die entsprechenden Spalten in
\p{T$_{Quelle}$} werden als \e{Fremdschl"ussel} bezeichnet.

\e{Referentielle Integrit"at} (Fremdschl"usselintegrit"at) ist eine Zusicherung
"uber den Zustand zweier Tabellen, die dann erf"ullt ist, wenn zu jeder Reihe
in Tabelle \p{T$_{Quelle}$} eine zugeh"orige Reihe in Tabelle \p{T$_{Ziel}$}
existiert, die den Fremdschl"usselwert von \p{T$_{Quelle}$} als Wert ihres
Schl"usselkandidaten besitzt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/83.eps}
\caption{Referentielle Integrit"at}
%\label{}  
\end{center}
\end{figure}

Zum Beispiel sichert referentielle Integrit"at zu, da"s es zu den Werten des
Attributs \p{Abteilung} der Tabelle \p{Mitarbeiter} (Fremdschl"usselattribut)
entsprechende Werte in der Spalte \p{Nr} der Tabelle \p{Abteilungen}
(Prim"arschl"ussel) gibt.  Abbildung \ref{2Wertbasierte Assoziation}
verdeutlicht die wertbasierte Assoziation zwischen Zeilen der Quelltabelle
\p{Mitarbeiter} und Reihen der Zieltabelle \p{Abteilungen} "uber Pfeile, die
jeweils vom Fremdschl"usselwert der Spalte \p{Abteilung} zum zugeh"origen
Prim"arschl"usselwert der Spalte \p{Nr} f"uhren.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/84.eps}
\caption{Referentielle Integrit"at}
%\label{}  
\end{center}
\end{figure}

In SQL-92 wird die Fremdschl"usselintegrit"at syntaktisch als eine
\e{Tabellenzusicherung} f"ur \p{T$_{Quelle}$} formuliert. F"ur unser obiges
Beispiel lautet die Tabellendefinition wie folgt:

\begin{xple}
\key{create table} Mitarbeiter 
     (...  
      \key{constraint} MitarbeiterHatAbteilung
      \key{foreign key}(Abteilung) \key{references} Abteilung(Nr))
\end{xple}

Diese Zusicherung ist "aquivalent zu der folgenden SQL-Schemazusicherung:

\begin{xple}
\key{create constraint} MitarbeiterHatAbteilung \key{check}(
   \key{not exists} (\key{select * from} Mitarbeiter m \key{where}
    \key{not exists} (\key{select * from} Abteilung a \key{where} m.Abteilung = a.Nr)))
\end{xple}


Im allgemeinen besteht ein Fremdschl"ussel aus einer Liste von Spalten, der
eine typkompatible Liste von Spalten in \p{T$_{Ziel}$} entspricht:

\begin{xple}
\key{create table} T$_{Quelle}$
  (... 
   \key{constraint} Name 
     \key{foreign key}(A$_{1}$, A$_{2}$, \dots, A$_{n}$) \key{references}   T$_{Ziel}$(B$_{1}$, B$_{2}$, \dots, B$_{n}$))
\end{xple}

In dem h"aufig auftretenden Fall, da"s es sich bei 
B$_{1}$, B$_{2}$, \dots, B$_{n}$ um die Prim"arschl"usselspalten 
von \p{T$_{Ziel}$} handelt, kann die Angabe der B$_{i}$ entfallen.

Schlie"slich sei erw"ahnt, da"s rekursive Beziehungen (z.B. 
\p{Abteilung : Oberabteilung}) zu reflexiven Fremdschl"usseldeklarationen 
(\p{T$_{Quelle}$ = T$_{Ziel}$}) f"uhren.

\subsubsection{Behandlung von Integrit"atsverletzungen}
\label{Behandlung von Integritaetsverletzungen}

Ergreift ein SQL-Benutzer keine speziellen Ma"snahmen, so werden
SQL-Anweisungen, die eine (modellinh"arente oder anwendungsspezifische)
Zusicherung verletzen, vom Datenbanksystem \e{ignoriert}, und es wird "uber
eine Statusvariable signalisiert, welche Zusicherung verletzt wurde.

Eine Sonderrolle nimmt dabei die \ky{commit}-Anweisung ein, da im Falle des
Scheiterns verz"ogerter Integrit"atsbedingungen in jedem Fall ein
\e{Transaktionsabbruch}(\key{rollback}) ausgel"ost wird.  In der Praxis ist es
daher sinnvoll, vor dem Transaktionsende mit der SQL-Anweisung \key{set
  constraints all immediate} eine unmittelbare "Uberpr"ufung aller
verz"ogerbaren Zusicherungen zu erzwingen und Integrit"atsverletzungen
programmgesteuert explizit zu behandeln.

Gerade im Zusammenhang mit referentiellen Integrit"atsbedingungen ist es
w"unschenswert, \e{automatisch} auf Integrit"atsverletzungen zu reagieren, und
die Integrit"at nicht durch das Ignorieren von Anweisungen, sondern durch das
Ausl"osen geeigenter \e{Folgeaktionen} wiederherzustellen.

Die Fremdschl"usselintegrit"at zwischen zwei Tabellen \p{T$_{Quelle}$} und
\p{T$_{Ziel}$} kann durch folgende vier Operationen verletzt werden:

\begin{enumerate}
\item \key{insert into } \p{T$_{Quelle}$}

\item \key{update}\p{T$_{Quelle}$} \key{set} \p{\dots}

\item \key{delete from} \p{T$_{Ziel}$} \p{\dots}

\item \key{update} \p{T$_{Ziel}$} \key{set} \p{\dots}
\end{enumerate}

Tritt bei der Anweisung (1) oder (2) ein Fremdschl"usselwert in
\p{T$_{Quelle}$} auf, der nicht als Schl"usselwert in \p{T$_{Ziel}$} definiert
ist, k"onnen in SQL-92 keine Folgeaktionen ausgel"ost werden, und die Anweisung
wird (mit Fehlerkode) ignoriert.

Wird bei Anweisung (3) oder (4) der Versuch unternommen, eine Reihe zu
l"oschen, deren Schl"usselwert noch als Fremdschl"usselwert in einer oder
mehreren Reihen von \p{T$_{Quelle}$} auftritt, so wird eine Folgeaktion
ausgef"uhrt, die am Ende der \ky{references}-Klausel der zugeh"origen
Tabellenzusicherung spezifiziert wurde (s. Abschnitt \ref{Referentielle
  Integritaet}). SQL-92 unterst"utzt zu diesem Zweck folgende Aktionen:

\begin{itemize}
\item \key{set null}: Der Fremdschl"usselwert aller betroffenen Reihen von
  \p{T$_{Quelle}$} wird durch \key{null} ersetzt.

\item \key{set default:} Der Fremdschl"usselwert aller betroffenen Reihen von
  \p{T$_{Quelle}$} wird durch den Standardwert der Fremdschl"usselspalte
  (\key{default}, s. Abschnitt \ref{Standardwerte fuer Spalten}) ersetzt.

\item \key{cascade}: In Fall (3, \key{delete}) werden alle betroffenen Reihen
  von \p{T$_{Quelle}$} gel"oscht. In Fall (4, \key{update}) werden die
  Fremdschl"usselwerte aller betroffenen Reihen von \p{T$_{Quelle}$} durch die
  neuen Schl"usselwerte der korrespondierenden Reihen in \p{T$_{Ziel}$}
  ersetzt.

\item \key{no action}: Es wird keine Folgeaktion ausgel"ost, sondern es greift
  die Standard-SQL Fehlerbehandlung -- die Anweisung (3) bzw. (4) wird
  ignoriert.
\end{itemize}

Folgeaktionen k"onnen f"ur Fall (3) und (4) separat spezifiziert 
werden:

\begin{xple}
\key{create table} T
   (...
    \key{constraint} xx \key{foreign key}(\dots) \key{references} \dots 
      \key{on delete set null}
      \key{on update cascade})
\end{xple}

\comment{Reihenfolgesensitivit"at vermieden durch Phasenansatz 
\& (s.S.227)

Markierung zum L"oschen.

Verallgemeinerung wird in \e{aktiven} Datenbanksystemen verfolgt. DBMS l"ost
benutzerdef.  Aktionen aus}

\subsubsection{Zeitpunkt der Integrit"ats"uberpr"ufung}
\label{Zeitpunkt der Integritaetsueberpruefung}

Erlaubt ein Datenbankmodell die Formulierung von Zusicherungen, die sich auf
\e{mehrere} Zustandsvariablen erstrecken, bietet jedoch keine Operationen an,
um diese Variablen \e{simultan} zu aktualisieren, so wird es notwendig, den
Zeitpunkt der Integrit"ats"uberpr"ufung genauer zu spezifizieren. Zum Beispiel
ist es in SQL-92 m"oglich, Zusicherungen "uber mehrere Tabellen zu formulieren,
andererseits kann eine SQL-Anweisung nur Reihen einer Tabelle simultan
modifizieren.

SQL-92 l"ost den Zielkonflikt zwischen fr"uher Fehlerverletzungserkennung und
komplexen multi-relationalen Integrit"atsbedingungen, indem der SQL-Benutzer
f"ur jede Tabellen- und Schemazusicherung "uber Schl"usselworte explizit einen
von zwei Modi der Integrit"ats"uberpr"ufung w"ahlen kann:

\begin{itemize}
\item \key{not deferrable} kennzeichnet eine nicht verz"ogerbare Zusicherung,
  die \e{unmittelbar} nach jeder SQL-Anweisung "uberpr"uft wird.

\item \key{deferrable} kennzeichnet eine verz"ogerbare Zusicherung.
  Zu einer solchen Zusicherung wird eine zweiwertige Indikatorvariable
  (\e{flag}) gespeichert, die angibt, ob nach der n"achsten
  SQL-Anweisung diese Zusicherung gepr"uft werden soll (flag =
  \key{immediate}), oder ob die Pr"ufung aufgeschoben werden soll
  (flag = \key{deferred}). Die Zusicherung wird au"serdem immer beim
  Umschalten der Indikatorvariable auf den Wert \key{immediate} sowie
  am Transaktionsende "uberpr"uft.
\end{itemize}

Der Anfangswert der Indikatorvariablen, der am Beginn jeder Transaktion 
gilt, wird bei der Definition der Zusicherung mit der Klausel 
\key{initially immediate} oder \key{initially deferred} festgelegt. 
Fehlt die Angabe der Klausel, so wird die Definition \key{initially 
immediate} angenommen.

W"ahrend der Ausf"uhrung einer Transaktion kann der Wert der 
Indikatorvariablen mit der Anweisung 
\key{set constraint} \p{Zusicherungsname} \key{immediate} 
(bzw. \key{deferred}) ver"andert werden.

Nat"urlich wird ein Datenbanksystem Optimierungen durchf"uhren, 
um redundante "Uberpr"ufungen von Zusicherungen zu vermeiden, 
so da"s zum Beispiel eine nicht-verz"ogerbare Zusicherung nicht 
tats"achlich nach jeder SQL-Anweisung erneut "uberpr"uft wird.

\subsection{Sichten in SQL}
\label{Sichten in SQL}

\subsubsection{Sichten auf eine Tabelle}
\label{Sichten auf eine Tabelle}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/80.eps}
\caption{Sichten in SQL}
%\label{}  
\end{center}
\end{figure}

\comment{Motivation: DB vereinigt zahlreiche Unternehmenssichten 
auf das gleiche Objekt. Anwendungen sollen jedoch vor der Komplexit"at 
gesch"utzt werden.

2. Motivation: Bewu"ste Kapselung

3 M"oglichkeiten der Sichtendefinition

Strukturelle Einschr"ankung (Projektion)

Pr"adikative Einschr"ankung (Selektion)

WITH CHECK LOCAL / CASCADED (S. 82)

Operationale Einschr"ankung (Zugriffsrechte, INSERT, DELETE, 
...)

Hier weg?

s. Updatable Query Specifications auf S. 184 in SQL Buch}


\subsubsection{Sichten auf mehrere Tabellen}
\label{Sichten auf mehrere Tabellen}

\subsection{Transaktionale Datenbankprogrammierung}
\label{Transaktionale Datenbankprogrammierung}

\comment{Commit, Rollback , Abort. Sperrkonflikte, Notification

Abbildung: Persistente DB-Historie}
