SQL Full

3 SQL – Structured Query Language
3.1 Überblick
I SQL (früherer Name: SEQUEL): Zunächst Abfragesprache des relationalen DBMS-Prototyps

System R“, Impl. ab Anf. 70er Jahre im IBM Forschungslabor in San Jose, CA.
”
I Sprachimplementierung unterstützte (mit derselben Sprache!) von Anfang an zwei Schnittstellen:
Interaktive Bildschirmschnittstelle: User Friendly Interface (UFI)“
”
Anwendungsprogramm-Schnittstelle: Embedded SQL“
”
I SQL wurde ab Anfang der 80er Jahre in verschiedenen DB-Implementierungen verfügbar:
IBM (DB2,. . .), DEC (RDB), Oracle, Ingres, Informix, MS Access, MS SQL-Server, . . .
I Anfang/Mitte der 80er Jahre Standardisierungsaktivitäten am ANSI für eine relationale DB-
Sprache auf Basis von SQL
I 1987 wird SQL ISO-Standard (ISO 9075) und anschließend auch als deutsche Norm DIN-ISO
9075 übernommen.
I 1989 Erweiterung von ISO 9075 (DIN-ISO 9075 folgte 1990), u.a. um Regeln für die Un-
terstützung referentieller Integrität (referential integrity)
I 1992 Verabschiedung von SQL2“ als ISO 9075-1992, und 1993 als DIN 66315
”
I Ende 1999 Verabschiedung von SQL-3“
”

c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-1
I Unterschiede zwischen SQL und den Konzepten aus Kapitel 2:
SQL-Relationen sind i.a. nicht duplikatfrei (Multimengen)
Duplikatfreiheit kann in Basisrelationen durch Integritätsbedingungen erzwungen werden.
Bei Anfrage-Resultaten müssen i.d.R. – wo gewünscht – explizit (per Operator) Duplikate
entfernt werden.
SQL-Anfragen:
. bilden die Relationenalgebra weitgehend ab.
. Grenzen bei der Orthogonalität
. enthalten zusätzlich Aggregationsfunktionen, Gruppierung, Sortierung, spezielle Operationen
für einige Datentypen
SQL bietet zusätzlich:
. DML: Manipulation (Updates) von Relationen (INSERT, UPDATE, DELETE)
. DDL: Definition von Tabellen, Indizes, etc.
. Verwaltung von Benutzern, Autorisierung
I In den meisten kommerziellen DBMSen gibt es (z.T. große) Abweichungen vom SQL-Standard
(der SQL-92-Standard enthält deswegen 3 Levels“)
”
I Nächster/Aktueller Standard: SQL-3“, u.a. zusätzliche Funktionalität für
”
Objekte
Multimedia-Daten (→ Erweiterung)
Zeitdaten
rekursive Anfragen
. . . verabschiedet Ende 1999. Hier noch weitgehend SQL-2

3.2 Anfragen
I Basisbaustein: Select-From-Where-Block (SFW-Block)

Syntaktische Grundstruktur (vereinfacht):
» ff–
[ALL]
SELECT Attributliste FROM R1, . . . , Rn [ WHERE Prädikat ]
DISTINCT
» » ff– » » ff– ––
ASC ASC
ORDER BY Attr1∗) , Attr2∗) , ...
DESC DESC
∗) Anstelle des Attributnamens kann auch die Attributnummer (= Attributposition) angegeben werden.
Bedeutung SFW: πAttributliste (σPrädikat |(R1 × ·{z

· · × Rn )
}
Produkt!
Dabei ist
. ALL/DISTINCT. . . Kennzeichnung für mit/ohne Duplikate
[Im folgenden der Einfachheit halber meist ohne DISTINCT“!]
”
. Attributliste . . . von der Form Ri .Aij , . . .“
”
oder Ri .∗“ oder ∗“ (= alle Attribute)
” ”
. Prädikat . . . Attribute (Ri .Ai j ), Konstanten,
=, 6=, <, . . ., AND, OR, NOT, u.v.m.

Anmerkungen/Hinweise:
. SELECT – Klausel ist Projektion (nicht Selektion)
. (gedankliche) Reihenfolge der Anwendung FROM→WHERE→SELECT
I Im folgenden schrittweise Erläuterung anhand von Beispielen
3.2.1 Ein-Tabellen-Operationen (Selektion/Projektion)

S1. Gib die Teilnehmer-Relation komplett aus.“
”
SELECT [ DISTINCT ] *
FROM Teilnehmer
Hinweis:
Die WHERE-Klausel entfällt in diesem Fall, da keine einschränkende Selektionsbedingung zu spe-
zifizieren ist.
S2. Gib die Teilnehmer-Relation komplett aus, aber in der Attribut-Reihenfolge Name, TnNr, Ort.“
”
SELECT Name, TnNr, Ort
FROM Teilnehmer

S3. Gib alle Kursteilnehmer aus, die aus ‘Ulm’ kommen.“
”
mit expliziter Attributangabe mittels Kurzform
SELECT TNNr, Name, Ort SELECT ∗
FROM Teilnehmer FROM Teilnehmer
WHERE Ort = ‘Ulm’ WHERE Ort = ‘Ulm’
I SQL enthält auch zusätzliche Operatoren für bestimmte Datentypen:

Verwendung von arithmetischen Funktionen in der SELECT-Klausel
IN-Prädikat für Vergleiche mit einer Menge von Konstanten
LIKE-Vergleichsoperator für CHAR-Attribute
ORDER BY zur Sortierung (auf- oder absteigend, auch mehrere Attribute)
DATE-Datentyp für Datum und Zeit

3.2.2 Mehr-Tabellen-Operationen, Verbunde (Joins)
I Syntaktische Grundstruktur (vereinfacht):
SELECT Attributliste
FROM Rel 1, Rel 2,. . . Rel n

WHERE Rel i .Attributname = Rel j .Attributname AND
Rel k .Attributname = Rel l .Attributname AND. . . AND
Rel y .Attributname = Rel z .Attributname
mit i , j, k, l, . . . , z ∈ {1, 2, . . . n}
Anmerkungen:
. In dieser Formulierung werden Joins als Produkte gefolgt von Selektionen ausgedrückt!
. Es sind auch andere Vergleichsoperatoren zugelassen.
. SQL 2 sieht explizite Join-Operationen vor (s. später)

S4. Gib aus, welche Kursangebote (Ausgabe: KursNr, AngNr) von welchen Kursleitern (Ausgabe:
”
Name) durchgeführt werden.“
SELECT f.KursNr, f.AngNr, lt.Name

FROM Fuehrt durch f, Kursleiter lt
WHERE f.PersNr = lt.PersNr
KursNr AngNr Name

G08 1 Huber,L.
G08 2 Huber,L.
G10 1 Müller,K.
G10 2 Schulze,H.
P13 1 Meier,I.
P13 2 Meier,I.
I09 1 Schulze,H.
I09 2 Schulze,H.
I09 3 Schulze,H.

S5. Wie S4, aber zusätzlich sollen noch der Kurstitel, das Kursdatum und der Kursort ausgeben
”
werden.“
SELECT f.KursNr, f.AngNr, lt.Name, k.Titel, a.Datum, a.Ort

FROM Fuehrt durch f, Kursleiter lt, Kurs k, Angebot a
WHERE f.PersNr = lt.PersNr AND
f.KursNr = a.KursNr AND
f.AngNr = a.AngNr AND
f.KursNr = k.KursNr
KursNr AngNr Name Titel Datum Ort

G08 1 Huber,L. Grundlagen I 13 − 01−1996 München
G08 2 Huber,L. Grundlagen I 24 − 02−1996 Bremen
G10 1 Müller,K. Grundlagen II 01 − 02−1996 München
G10 2 Schulze,H. Grundlagen II 15 − 02−1996 Hamburg
P13 1 Meier,I. C-Programmierung 28 − 05−1996 Ulm
P13 2 Meier,I. C-Programmierung 01 − 07−1996 Essen
I09 1 Schulze,H. Datenbanken 27 − 03−1996 Stuttgart
I09 2 Schulze,H. Datenbanken 23 − 04−1996 Hamburg
I09 3 Schulze,H. Datenbanken 29 − 05−1996 München

S6. Gib aus, welche Teilnehmer (Ausgabe: TnNr, Name) an Kurs ‘G08’ oder ‘G10’ (Ausgabe:
”
KursNr, AngNr) teilnehmen.“
SQL-Formulierung:
I In SQL-92 sind die Möglichkeiten zur Formulierung von Joins wesentlich verbessert worden, da
diese direkt in der FROM-Klausel ausgedrückt werden können (und somit die WHERE-Klausel
vereinfachen). Möglichkeiten:
NATURAL JOIN
UNION JOIN
CROSS JOIN
Condition Join
Column Name Join
OUTER JOIN
I Dies ist zur Zeit noch nicht in allen RDBMSen realisiert worden.

3.2.3 Subqueries / Existenzbedingungen
I Form 1: SELECT Attributliste

FROM Rel 1, Rel 2,. . . , Rel n
WHERE [ NOT ] EXISTS
(SELECT-FROM-WHERE-Ausdruck)

8 < 9
> <= >
 ff >
>
< >
> » ff–
R i .Attr name =
= ANY
WHERE
(R i .Attr name, R j .Attr name, . . . ) >
> <> >
> ALL
: >= >
> ;
>

R i .Attr name
 ff
WHERE (R .Attr name, R .Attr name, . . . ) [ NOT ] IN
i j

I Anmerkungen:
Anfrageform 1: Der Subquery-Ausdruck (EXISTS) liefert nur TRUE (Treffer gefunden) oder
FALSE (keine Treffer).
Anfrageform 2: Ohne ANY-/ALL-Zusatz muss der Subquery-Ausdruck so formuliert sein, dass
genau ein Attributwert oder Tupel (keine Menge!) zurückgeliefert wird. Dieser wird als Ver-
gleichswert ( Quasi-Konstante“) im äußeren (Sub-)Query-Ausdruck verwendet.1
”
= ANY ist äquivalent zu IN, NOT IN ist äquivalent zu <> ALL.
Subquery-Ausdrücke können geschachtelt sein, d.h. sie können wiederum Subquery-Ausdrücke
enthalten.
In Subquery-Ausdrücken kann auf Relationen von äußeren (Sub-)Query-Ausdrücken Bezug ge-
nommen werden: =⇒ korrelierte Subqueries (correlated subqueries)
Subqueries liefern (Ausnahme: Form 1) per Default ebenfalls Multimengen als Resultat zurück.
Ggf. muss dies mittels SELECT DISTINCT verhindert werden.
Je nach Anfragebearbeitungs-Strategie bzw. Güte der Anfrage-Optimierung des verwendeten
DBMS können sich bei semantisch äquivalenten Anfrageformulierungen im konkreten Fall stark
unterschiedliche Antwortzeiten ergeben.2
1 Die Klammer in (R .Attr name, R .Attr name, . . .) fungiert als Tupel-Konstruktor. Dieser wurde erst mit SQL-2 eingeführt.
i j
Er wurde aber von einigen DBMSen (z.B. ORACLE) bereits schon vorher unterstützt.
2 Eine ausführliche Behandlung dieses Aspektes findet sich – neben anderen Dingen – z.B. in: (Rautenstrauch und Moazzami
1990)

S7. Gib alle Kursangebote aus (Ausgabe: KursNr, AngNr), für die Teilnehmer aus ‘Ulm’ gebucht
”
haben.“
Möglichkeit 1: Join (wie gehabt)
I In Algebra-Notation:
π Nimmt-teil.KursNr, Nimmt-teil.AngNr (Nimmt-teil 1 σ Ort=‘Ulm’Teilnehmer)
I In SQL-Notation:
SELECT DISTINCT nt.KursNr, nt.AngNr
FROM Nimmt teil nt, Teilnehmer t
WHERE nt.TnNr = t.TnNr AND t.Ort = ‘Ulm’
KursNr AngNr
I09 1
P13 1
Möglichkeit 2: (korrelierte) Subquery mit EXISTS

FROM Nimmt teil nt
WHERE EXISTS
(SELECT *
FROM Teilnehmer t
WHERE t.Ort = ‘Ulm’ AND t.TnNr = nt.TnNr)

Möglichkeit 3: Subquery mit ANY
SELECT DISTINCT nt.Kursnr, nt.AngNr
FROM Nimmt teil nt
WHERE nt.TnNr = ANY
(SELECT TnNr
FROM Teilnehmer
WHERE Ort = ‘Ulm’)
Möglichkeit 4: Subquery mit IN

FROM Nimmt teil nt
WHERE nt.TnNr IN
(SELECT TnNr
FROM Teilnehmer
Anmerkungen:
I Bei der EXISTS-Variante handelt es sich um eine korrelierte Subquery, bei der ANY- und
IN-Variante um nicht-korrelierte Subqueries.
I Wir werden später eine alternative Formulierung zu der EXISTS-Formulierung mittels COUNT
kennenlernen.

Resultat Resultat
Startbedingung
Haupt-Query
Haupt- Haupt-
Query Query
Output Input für Output n mal

1 mal n mal
Subquery Subquery Subquery
Sub- Startbedingung Sub-

Subquery Query
Query
nicht-korreliert korreliert
Abbildung 3-1: Nicht-korrelierte und korrelierte Subqueries (schematische Darstellung)

S8. Gib alle Kursangebote (Ausgabe: Angebot.*) aus, für die keine Anmeldungen vorliegen.“
”
S9. Gib die Personalnummer des Kursleiters mit dem höchsten Gehalt aus.“
”
SELECT k1.PersNr
FROM Kursleiter k1
WHERE NOT EXISTS
(SELECT *
FROM Kursleiter k2
WHERE k2.Gehalt > k1.Gehalt)
Alternative Formulierung ALL-Quantor:

S10. Gib alle Kurse aus (Ausgabe: Angebot-Info), die Teilnehmer(in) ‘Schmidt, M.’ gebucht hat.“
”
Annahme hier: Die Teilnehmer-Namen seien eindeutig
SELECT *
FROM Angebot
WHERE (AngNr, KursNr) IN
(SELECT AngNr, KursNr
FROM Nimmt teil
WHERE TnNr =
(SELECT TnNr
FROM Teilnehmer
WHERE Name = ‘Schmidt, M.’))
S11. Wie S10, aber es interessieren alle Kurse, die ‘Schmidt, M.’ oder ‘Abele, I.’ gebucht haben.“
SELECT *
FROM Angebot
WHERE (AngNr,KursNr) IN
( SELECT AngNr, KursNr
FROM Nimmt_teil
WHERE TnNr = .... ???
( SELECT TnNr
FROM Teilnehmer
WHERE Name = 'Schmidt, M.' OR Menge!
Name = 'Abele, I.' ) )

3.2.4 Aggregat- und Gruppierungs-Funktionen
I SQL bietet standardmäßig die folgenden eingebauten“ Mengen-Funktionen (set functions;
”
built-in functions) an:
Funktion Bedeutung
COUNT(∗) Anzahl der Tupel
COUNT([DISTINCT] Attributname ) Anzahl der Attributwerte
MAX(Attributname) Maximum der Attributwerte
MIN(Attributname) Minimum der Attributwerte
AVG([DISTINCT] Attributname) Durchschnitt der Attributwerte
SUM([DISTINCT] Attributname ) Summe der Attributwerte
POSITION (string IN source string) Suche Pos. von String in String (∗)
SUBSTRING (src str FROM pos [FOR len]) Extraktion eines Substrings (∗)
UPPER(src str ) Umwandl. in Großbuchstaben (∗)
LOWER(src str ) Umwandl. in Kleinbuchstaben (∗)
8 9
<BOTH = Entf. von führenden und/oder anhängen-
TRIM LEADING char FROM src str ) den Zeichen (∗)
: ;
TRAILING Beispiel: TRIM BOTH ’ ’ FROM ’ qaa ’ → ’qaa’
TRANSLATE, CONVERT Zur Unterstützung verschied. Zeichensätze (∗)
CURRENT DATE Liefert das aktuelle Datum3 (∗)
Liefert die aktuelle Zeit mit precision
CURRENT TIME[(precision)] (∗)
Nachkommastellen3
Liefert aktuelle TIMESTAMP mit precisi-
CURRENT TIMESTAMP[(precision)] (∗)
on Nachkommastellen3
(∗) Erst in SQL 2 eingeführt, allerdings z.T. bereits in einigen DBMS unterstützt
3 Als Datentyp DATE bzw. TIMESTAMP

S12. Gib die Anzahl aller Kursteilnehmer aus.“
”
SELECT COUNT(*)
FROM Teilnehmer
S13. Gib die Anzahl aller Kursteilnehmer aus ‘Ulm’ aus.“

”
SELECT COUNT(*)
FROM Teilnehmer
WHERE Ort = ‘Ulm’
S14. Gib das durchschnittliche Gehalt aller Kursleiter aus.“

”
SELECT AVG(Gehalt)
FROM Kursleiter
Wichtiger Hinweis:
Wenn eine SELECT-Anweisung eine Aggregatfunktion enthält, so wird nur max. ein
Resultat-Tupel erzeugt.
Ausnahme: Bei Verwendung der GROUP BY-Klausel (kommt später).

S15. Gib das höchste, das niedrigste und das durchschnittliche Kursleiter-Gehalt sowie die Summe aller
”
Gehälter aus.“
SELECT MAX(Gehalt), MIN(Gehalt),

AVG(Gehalt), SUM(Gehalt)4
FROM Kursleiter
S16. Anfrage S9: Gib die Personalnummer des Kursleiters mit dem höchsten Gehalt aus.“
”
Mittels Aggregat-Funktion formuliert:
SELECT PersNr
FROM Kursleiter
WHERE Gehalt >=
(SELECT MAX(Gehalt)
FROM Kursleiter)
4 Die Angabe mehrerer Aggregat-Funktionen in einem SELECT-Ausdruck wird möglicherweise nicht von allen DBMS unterstützt. Bei
ORACLE ist dies zulässig.

S17. Gib die Anzahl der verschiedenen Orte aus, aus denen die Kursteilnehmer kommen.“
”
S18. Gib alle Kursangebote aus (Ausgabe: KursNr, AngNr), für die Teilnehmer aus ‘Ulm’ gebucht
”
haben.“ (vgl. Anfrage S7):
Mittels COUNT formuliert:
SELECT nt.KursNr, nt.AngNr

FROM Nimmt teil nt
WHERE 0 < (SELECT COUNT(*)
FROM Teilnehmer t
WHERE t.Ort = ‘Ulm’ AND t.TnNr = nt.TnNr)

S19. Gib auf Basis der Teilnehmer-Relation eine ortsbezogene Teilnehmerstatistik aus (Ausgabe: Orts-
”
name, Teilnehmerzahl).“
SELECT Ort, COUNT . . . ?

FROM Teilnehmer
Lösung: Gruppierung
SELECT Ort, COUNT(Ort)

FROM Teilnehmer
GROUP BY Ort
Ort COUNT(Ort)
Augsburg 1
Bochum 1
Bremen 1
Essen 1
Hamburg 1
Heidelberg 1
Senden 1
Stuttgart 2
Ulm 2

I Syntaktische Struktur:
SELECT [ALL|DISTINCT] Attributliste
FROM Relationenliste
[ WHERE Nebenbedingung]
[ GROUP BY Gruppierungsattribut(e)
[HAVING Gruppierungsbedingung]]
[ ORDER BY Attributliste]
Erläuterung und ergänzende Kommentare:

GROUP BY bewirkt (interne) Teilmengenbildung (Gruppierung) der Ergebnis-Relation entspre-
chend dem/den Gruppierungsattribut(en) (→ Menge von Mengen).
Aggregationsfunktionen werden jeweils auf Teilmengen (falls vorhanden) angewandt.
Eventuelle Joins werden vor Anwendung der Gruppierungsfunktion ausgeführt
(gedankliche (!) Ausführungs-“reihenfolge jetzt also:
”
FROM→WHERE→GROUP BY→HAVING→ORDER BY→SELECT)
In der SELECT-Klausel können – bei Angabe von GROUP BY – neben Aggregat-Funktionen
auch Gruppierungsattribute stehen.
Gruppierungsnebenbedingungen werden mittels HAVING-Klausel ausgedrückt (HAVING kann
nur in Verbindung mit GROUP BY auftreten).
Beziehung WHERE↔HAVING:
. WHERE eliminiert einzelne Zeilen
. HAVING eliminiert einzelne Gruppen

Wirkungsweise von GROUP BY
. . . unter Verwendung von nicht normalisierten“ oder geschachtelten“ Relationen kann man die
” ”
Wirkung von GROUP BY einfach wie folgt erläutern:
Nach der Auswertung der FROM- und WHERE-Klauseln wird das bisherige Zwischenergebnis nach
den in der GROUP BY-Klausel angegebenen Attributen in geschachtelte Tupel“ gruppiert.
”
Zwischenergebnis2
Zwischenergebnis1
A B {CD-Gruppe}
A B C D
C D
a b c1 c2
a b c1 c2
a b c3 c4
→ GROUP BY A,B → c3 c4
x y c3 c4
x y c3 c4
x y c5 c6
c5 c6
x y c7 c8
c7 c8
q w c9 c10
q w c9 c10
. . . aus den 6 Tupeln des ersten Zwischenergebnisses sind 3 Tupel des zweiten geworden, die jeweils
eine Menge von CD-Tupeln als Attribut“ haben. Eine evtl. HAVING-Klausel ist eine Selektion in
”
diesem relationenwertigen Attribut“.
”
Offensichtlich sind Beschränkungen bzgl. nachfolgender Projektionen (SELECT-Klausel) erforderlich,
damit das Ergebnis wieder eine flache“, d.h. normalisierte, Relation ist.
”

S20. Gib für alle Kursangebote die Anzahl der Anmeldungen aus (Ausgabe: Angebote-Attribute, Anzahl
”
Teilnehmer).“
SELECT a.*, COUNT(*)
FROM Angebot a, Nimmt teil nt
WHERE a.AngNr = nt.AngNr AND a.KursNr = nt.KursNr
GROUP BY a.AngNr, a.KursNr, a.Datum, a.Ort
AngNr KursNr Datum Ort COUNT(*)
1 G08 13 − 01−1996 München 1
1 I09 27 − 03−1996 Stuttgart 5
1 P13 28 − 05−1996 Ulm 2
2 G08 24 − 02−1996 Bremen 1
2 I09 23 − 04−1996 Hamburg 1
2 P13 01 − 07−1996 Essen 3
S21. Wie S20, aber nur solche Kurse ausgeben, für die mehr als 2 Anmeldungen vorliegen.“
”
SELECT a.*, COUNT(*)
HAVING COUNT(*) > 2
AngNr KursNr Datum Ort COUNT(*)
1 I09 27 − 03−1996 Stuttgart 5
2 P13 01 − 07−1996 Essen 3

S22. Gib alle Kursleiter aus, die mindestens zwei Kurse leiten. Ausgabe: Personaldaten, Angebotsdaten,
”
sortiert nach PersNr.“
SELECT kl.*, a.*

FROM Angebot a, Kursleiter kl, Fuehrt durch fd
WHERE a.AngNr = fd.AngNr AND
a.KursNr = fd.KursNr AND
fd.PersNr = kl.PersNr AND
kl.PersNr IN
(SELECT PersNr
FROM Fuehrt durch
GROUP BY PersNr HAVING COUNT(*) >= 2)
ORDER BY kl.PersNr
PersNr Name AngNr KursNr Datum Ort

27183 Meier,I. 1 P13 28 − 05−1996 Ulm
27183 Meier,I. 2 P13 01 − 07−1996 Essen
29594 Schulze,H. 2 G10 15 − 02−1996 Hamburg
29594 Schulze,H. 1 I09 27 − 03−1996 Stuttgart
29594 Schulze,H. 3 I09 29 − 05−1996 München
29594 Schulze,H. 2 I09 23 − 04−1996 Hamburg
38197 Huber,L. 1 G08 13 − 01−1996 München
38197 Huber,L. 2 G08 24 − 02−1996 Bremen

Alternative Query-Formulierung für S22 ohne GROUP BY:
SELECT kl.*, a.*
FROM Angebot a, Kursleiter kl, Fuehrt durch fd
WHERE a.AngNr = fd.AngNr AND
a.KursNr = fd.KursNr AND
fd.PersNr = kl.PersNr AND
2 <= (SELECT COUNT(*)
FROM Fuehrt durch fd1
WHERE fd1.PersNr = fd.PersNr)
ORDER BY kl.PersNr
S23. Gib alle Kurstypen (KursNr) – mit Ausnahme der Grundlagen-kurse (‘G..’) – aus, für die mehr
”
als 4 Anmeldungen vorliegen.“
SELECT nt.KursNr, k.Titel, COUNT(*)
FROM Nimmt teil nt, Kurs k
WHERE nt.KursNr = k.KursNr
GROUP BY nt.KursNr, k.Titel
HAVING COUNT(*) > 4 AND nt.KursNr NOT LIKE ‘G%’
KursNr Titel COUNT(*)

I09 Datenbanken 6
P13 C-Programmierung 5

3.2.5 Vereinigung, Differenz und Durchschnitt
I Syntaktische Grundstruktur:
 ff
SFW-Ausdruck
TABLE Relationsname
8 9
< UNION = ˆ ˜
EXCEPT [ ALL ] CORRESPONDING (Attr 1, Attr 2,. . . )
INTERSECT
: ;
 ff
SFW-Ausdruck
TABLE Relationsname
Attributliste
h n oi
ORDER BY
Positionsnummer
I Anmerkungen / Erläuterungen:
In SQL 89 war nur UNION definiert
Die Ergebnis-Relationen der beiden Query-Ausdrücke (die Operanden) müssen hinsichtlich
Anzahl und Typ der Spalten identisch sein. – Bei Angabe von CORRESPONDING wird zu-
vor eine Projektion auf die angegebenen Attribute durchgeführt.

Anmerkungen (Forts.):
UNION, EXCEPT und INTERSECT führen automatisch eine Duplikateliminierung durch.
– Durch Angabe von ALL kann dies unterdrückt werden.
Die Attributnamen der Operanden-Relationen“ können von einander abweichen.5
”
Die ORDER BY-Klausel – falls angegeben –, muss am Ende des Query-Ausdrucks stehen.
Anstelle von Attributnamen können in der ORDER BY-Klausel auch wieder die Positionsnum-
mern der entsprechenden Attribute angegeben werden.
Die Mengenoperationen sind nur auf dem äußersten Query-Level zulässig, nicht in Subqueries
(SQL-92).
Kurzschreibweisen (für UNION, INTERSECT, EXCEPT):
Normalform Kurzform
SELECT * SELECT *
FROM Rel1 FROM (TABLE Rel1 UNION TABLE Rel2 )
UNION
SELECT *
FROM Rel2
5 Bei ORACLE werden die Attributnamen vom oberen“ Query-Ausdruck übernommen.

”

S24. Erstelle eine Namensliste mit Teilnehmernummer bzw. Personalnummer von allen Kursteilnehmern
”
und Kursleitern (Ausgabe: Name, Nummer), alphabetisch nach Name sortiert.“
SELECT Name, TnNr AS Nummer

FROM Teilnehmer
UNION
SELECT Name, PersNr
FROM Kursleiter
ORDER BY Name
S25. Wie S24, aber nach Nummer sortiert.“

”
SELECT Name, TnNr AS Nummer FROM Teilnehmer
UNION
SELECT Name, PersNr FROM Kursleiter
ORDER BY 2
S26. Gib alle Kurse (Ausgabe: KursNr, Titel) aus, die nicht Kurs ‘G08’ als Voraussetzung haben.“
”
SELECT * FROM Kurs
EXCEPT
SELECT Kurs.* FROM Kurs, Vorauss
WHERE Vorauss.KursNr = Kurs.KursNr AND
Vorauss.VorNr = ’G08’

S27. Gib alle Kurse aus, die am Wohnort der jeweiligen Kurs-Teilnehmer angeboten werden
”
(Ausgabe: Ort, AngNr, KursNr).“
SELECT t.Ort, nt.AngNr, nt.KursNr

FROM Teilnehmer t, Nimmt teil nt
WHERE t.TnNr = nt.TnNr
INTERSECT
SELECT a.Ort, nt.AngNr, nt.KursNr
WHERE a.AngNr = nt.AngNr AND
a.KursNr = nt.KursNr
Ort AngNr KursNr

Bremen 2 G08
Essen 2 P13
Hamburg 2 I09
Stuttgart 1 I09
Ulm 1 P13

3.3 Datendefinition: Erzeugen, Löschen und Ändern von Relationen
3.3.1 Erzeugen von Relationen

I Beispiel 3-1:
CREATE TABLE Angebot
( AngNr DECIMAL(5) NOT NULL,
KursNr CHAR(6) NOT NULL,
Datum DATE,
Ort VARCHAR2(20))
CREATE TABLE Gehalt

( PersNr DECIMAL(5) NOT NULL,
Gehalt DECIMAL(7,2))

I Syntaktische Grundstruktur:6
CREATE TABLE Relationsname

„ » ff–
NULL
Attributname1 Datentyp1
NOT NULL
» » ff– –«
NULL
, Attributname2 Datentyp2 ,. . .
NOT NULL
I Datentypen:7
Datentyp Spezifikation Erläuterungen
Integer INTEGER Oracle: NUMBER(38)
Real FLOAT[(g)] Oracle: NUMBER[(g)], g = Genauigkeit (max. 38 Ziffern)
Dezimal DECIMAL(g[,k]) Oracle: NUMBER(g[,k]) . . . , davon k Nachkommastellen
Zeichenkette CHAR(Länge) feste Länge, max. 255 Zeichen
Zeichenkette VARCHAR2(Länge) var. Länge, max. 2.000 Zeichen
Zeichenkette LONG max. 2 GB
Bytestring LONG RAW var. Länge, max. 2 GB (s. Fußnote zu LONG)
Datum DATE Format einstellbar, bei uns: tt-mm-jjjj
TupleID8 ROWID Tupel-Adresse
6 Dies ist die erforderliche Minimal-Syntax“. Wir werden im folgenden noch eine erweiterte Syntax kennenlernen
7 (Auswahl). Teilweise gibt”es synonyme Benennungen für denselben Datentyp. Die Beschränkungen sind jeweils
(ORACLE-)implementierungsspezifisch.
8 ORACLE-spezifisch, kein SQL 89 oder SQL 2 Datentyp! Jede Relation in ORACLE hat ein Pseudo-Attribut ROWID (Aufbau:
block.row.file, z.B.: 0000000F.0000.0002)

I Datentypen in SQL 92:
Grundsätzlich: Verschiedene Schreibweisen für dasselbe bzw. ähnliche Konstrukt aus Kompati-
bilitätsgründen:
z.B. CHARACTER VARYING = VARCHAR = CHAR VARYING
Integer, Real: Wie bei ORACLE V7
Dezimal: Wird mit DECIMAL(n[,k]) oder NUMERIC(n) deklariert.
CHAR VARYING (wird in ORACLE V7 mit VARCHAR2 deklariert; VARCHAR hatte in
V5/V6 andere Bedeutung)
Binärfelder (LONG RAW in ORACLE): Werden als BIT (feste Länge) bzw. BIT VARYING
(variable Länge) deklariert.
Zusätzlich weitere Datentypen wie
. TIME
. TIMESTAMP
. TIME WITH TIME ZONE
. Nationale Zeichensätze
. ...

I Anmerkungen:
Jede Tabelle/Relation gehört zu einem SCHEMA9 . Relationsnamen innerhalb eines Schemas
müssen eindeutig sein.
CREATE TABLE [schema.]tabname bewirkt Eintrag der Relation in den DB-Katalog.
Bei Angabe von NOT NULL werden alle Insert- und Update-Operationen zurückgewiesen, die
für dieses Attribut einen NULL-Wert liefern.
Der DB-Katalog ist i.a. als Sammlung von Relationen realisiert.10
Folge: Katalog-Relationen können wie normale Relationen abgefragt werden.
Für einige Katalogeinträge sind spezielle Zugriffs-Privilegien erforderlich (z.B. DBA-Status).
Für (ORACLE-) Benutzer i.a. nützliche Katalog-Relationen:
. TAB Liste der vom Benutzer erzeugten Relationen und Sichten
. COL Liste der Attribute der vom Benutzer erzeugten Relationen
. VIEWS Sichtendefinitionen
. INDEXES Vom Benutzer auf Benutzer-Relationen erzeugte Indexe.
9 Wird nichts angegeben, so gehört es zum Default-Schema des Benutzers. In ORACLE V7 gibt es zwar ein CREATE SCHEMA
Statement, es ist aber nur ein Schema je UserID zugelassen.
10 SQL92 legt die Katalogstruktur des Information Schema fest. Die derzeitig verfügbaren DBMSe haben jeweils eigene
Strukturen. Ein komplettes Verzeichnis der ORACLE-Katalog-Relationen ist in der Katalog-Relation DTAB gespeichert.

I Probleme mit Minimal-Syntax“:
”
Keine Angaben zur Werteindeutigkeit ⇒ wird auf ( Unique“-) Index verlagert (siehe später)
”
Primärschlüssel aus Definition nicht erkennbar.
Keine DB-unterstützte Integritätsprüfung beim Einfügen; es sei denn über Unique Index (siehe
später).
I Erweiterte CREATE-TABLE-Syntax gemäß SQL 92:11,12
1. Attributbezogene  Klauseln: ff
Datentyp i
Attributname i [< default-klausel >] [< check-klausel >]
Domain i 8 9
>
> Konstante> >
USER
< =
<default-klausel> ::= DEFAULT
>
> ... >
>
: ;
NULL
 ff
NOT NULL
<check-klausel> ::=
CHECK(<check-bedingung>)
<check-bedingung> ::= Von einfachen Vergleichen bis hin zu komplexen EXISTS-
oder IN-Subqueries alles erlaubt.13
11 Zusätzliche Klauseln entsprechend SQL 2. Die meisten davon gab es bereits in SQL 89.
12 Von ORACLE V7 (und vielen anderen relationalen DBMS) heute noch nicht (voll) unterstützt.
13 In ORACLE V7 (und vielen anderen relationalen DBMSen) kann sich die Check-Bedingung nur auf das aktuelle Tupel beziehen.
Subqueries auf andere Relationen sind nicht erlaubt.

2. Vereinbarung von Domains:
Vergleichbar mit einfachen, nicht-geschachtelten Typ-Vereinbarungen in einer Programmier-
sprache
Kann anschließend in CREATE-TABLE-Anweisung verwendet werden.
CREATE DOMAIN domain-name [AS] datatype
[ <Default-Klausel> ]
[ <Constraint-Klausel> ]
Beispiel 3-2:
CREATE DOMAIN AngNr Type AS NUMERIC(5)
CHECK (VALUE IS NOT NULL)
CREATE DOMAIN GehaltType AS DECIMAL(8,2)

CHECK (VALUE IS NULL) OR (VALUE > 0)
3. Relationsbezogene Klausel:
UNIQUE
hn o i
(Attribut1 [, Attribut2 ,. . . ])
PRIMARY KEY

3.3.1.1 Schlüssel- und Fremdschlüssel-Deklarationen
I Erweiterte SQL-DDL mit Primärschlüssel- (−→ PRIMARY KEY) und Fremdschlüssel-Angabe

(−→ REFERENCES).
I Ermöglicht, Beziehungen zwischen Relationen im Schema zu beschreiben.
I Beispiel 3-3: (bezogen auf Abb. 3-2)
CREATE TABLE Lieferant
(LiefNr DECIMAL(5) PRIMARY KEY, /* in-line“ Deklaration */
”
LiefName CHAR(30) NOT NULL)
CREATE TABLE Liefert
(TeileNr DECIMAL(6) REFERENCES Teil(TeileNr), /* dto. in-line“ */
”
LiefNr DECIMAL(5) REFERENCES Lieferant(LiefNr),
Preis DECIMAL(8,2),
UNIQUE (TeileNr, LiefNr)) /* unbenannter Constraint */
CREATE TABLE Teil
(TeileNr DECIMAL(6) CONSTRAINT teilpk PRIMARY KEY,
TeileBez CHAR(20) NOT NULL, /* ↑ benannte Constraint, in-line“ */
”
Bestand DECIMAL(6))
CREATE TABLE TeileBest
(BestNr DECIMAL(9) PRIMARY KEY,
LiefNr DECIMAL(5) REFERENCES Lieferant,
Termin DATE)

CREATE TABLE TeileBestPos
(BestNr DECIMAL(9),
BestPos DECIMAL(3),
TeileNr DECIMAL(5),
Menge DECIMAL(6) NOT NULL,
CONSTRAINT tbp constrainsts /* abgesetzte Constraint-Deklaration */
UNIQUE (BestNr, BestPos),
REFERENCES TeileBest(BestNr),
REFERENCES Teile(TeileNr))
...

I Anmerkungen:
PRIMARY KEY und UNIQUE erzwingen beide Eindeutigkeit.
UNIQUE kann mehrmals, PRIMARY KEY nur einmal je Relation angegeben werden.
Falls sich PRIMARY KEY bzw. UNIQUE auf ein einzelnes Attribut beziehen, kann die in-line“
”
Darstellung gewählt werden:
Attributname Attributtyp PRIMARY KEY bzw.
Attributname Attributtyp UNIQUE
PRIMARY KEY, UNIQUE und REFERENCES können sich auf mehrere Attribute (zusammen-
gesetzter Schlüssel) beziehen (siehe z.B. Relation TeileBestPos)
Auch explizite Fremdschlüssel-Deklaration ist möglich:
CREATE TABLE Auftrag
(AuftrNr DECIMAL(9) PRIMARY KEY,
KdNr DECIMAL(9)
Termin DATE
FOREIGN KEY (KdNr) REFERENCES Kunde(KdNr))
alternativ:
FOREIGN KEY KundeRef (KdNr) REFERENCES Kunde14
14 Wird bei REFERENCES nur der Relationsname angegeben, so bezieht sich REFERENCES auf den PRIMARY KEY der
angegebenen Tabelle

I REFERENCES kann sich auch auf andere Attribute als den PRIMARY KEY einer Relation bezie-
hen.
Attribut(wert) muss in übergeordneter Relation eindeutig sein.15
Explizite Attributangabe in REFERENCES-Klausel erforderlich (ansonsten optional):
CREATE TABLE Kunde
(KdNr DECIMAL(9) PRIMARY KEY,
KdName CHAR(30) NOT NULL,
KdAnschrift CHAR(60) NOT NULL
UNIQUE(KdName, KdAnschrift))
CREATE TABLE Adressen
(Name CHAR(30),
Adresse CHAR(60),
FOREIGN KEY KundeRef (Name, Adresse)
REFERENCES Kunde(KdName, KdAnschrift))
Wirkungsweise von PRIMARY KEY . . . REFERENCES

(in der bisher betrachteten Form):16
. Überprüfung von Einfüge-, Lösch- und Änderungsoperationen auf Einhaltung der Referenz-
Bedingungen (z.B. keine Erzeugung von Waisenkindern“).
”
. Zurückweisung referenzverletzender Anweisungen.
. Keine automatische Anpassung abhängiger“ Werte.
”
15 Hier wird gefordert, dass für dieses Attribut bzw. die Attribut-Kombination eine UNIQUE-Spezifikation vorliegt.
16 mehr dazu später

3.3.2 Ändern einer Tabelle (Schemaänderung!)
I Syntax (vereinfacht):
ALTER TABLE Relationsname
 ff „ » ff– «
ADD NULL
Attributname1 Datentyp1 ,...
MODIFY NOT NULL
I Beispiele:
A1: Erweitere die Teilnehmer-Relation um die Attribute PLZ vom Typ Number(4) und Strasse
”
vom Typ CHAR(30).“
ALTER TABLE Teilnehmer ADD (PLZ DECIMAL(4), Strasse CHAR(30))
A2: Es existiere eine noch leere Tabelle TEILE. Eine zusätzliche Spalte PREIS soll hinzugefügt
”
werden, die zwingend Werte enthalten soll.“
ALTER TABLE Teile ADD (Preis DECIMAL(8,2) NOT NULL)

I Anmerkungen:
Neue Spalten werden stets hinten angehängt.
Sofern die Relation bereits Tupel enthält, werden die neuen Attribute mit Nullwerten gefüllt.
NOT NULL-Klausel daher nur bei leeren Relationen möglich.
Nachträgliche Änderungen von Attribut-Definitionen (Typ, Größe“, NULL-Klausel) bei leerer
”
Relation oder NULL-wertiger Spalte durch ALTER TABLE . . . MODIFY-Anweisung möglich.
Löschen oder Umbenennen von Attributen ist nicht möglich.
ORACLE erlaubt das Ändern des Relationsnamens mittels der Anweisung:
RENAME alter Name TO neuer Name
INGRES benutzt die Modify-Anweisung auch um die interne Speicherung von Relationen zu
ändern:
. MODIFY Relation1 TO HASH
. MODIFY Relation2 TO BTREE
. MODIFY Relation3 TO ISAM
. MODIFY Relation4 TO HEAP17
. ...
17 HEAP ist die interne Standard-Repräsentation bei INGRES

3.3.3 Löschen einer Tabelle
I Syntax:
DROP TABLE Relationsname
I Wirkung: Löscht die angegebene Relation samt Inhalt und entfernt sie aus dem Katalog.
I Beispiel 3-4:
DROP TABLE Gehalt
I Hinweis:
Beendet bei automatisch auch die laufende Transaktion (implizites Commit) !18
Grund: Vermeidung von (aufwendigem) UNDO dieser Operation19
18 siehe später bei Transaktionsverwaltung

19 Der SQL-Standard überlässt es der jeweiligen Implementierung, ob DDL-Operationen mit DML-Operationen in einer
Transaktion gemischt werden können oder nicht bzw. ob diese stets zu implizitem COMMIT führen.

3.3.4 Anlegen und Löschen von Indexen
I Syntax (vereinfacht):
CREATE [UNIQUE] INDEX Indexname ON Relationsname
(Attributname1 [, Attributname2 , . . . ])
DROP INDEX Indexname [ON Relationsname]
I Beispiel 3-5:
CREATE INDEX Ort Sort ON Angebot (Ort)
CREATE UNIQUE INDEX nt index ON Nimmt teil (AngNr, KursNr)
DROP INDEX Datum Index
I Anmerkungen:
Indexnamen für vom Benutzer erzeugte Relationen müssen innerhalb eines Schemas eindeutig
sein.
Mehrere Indexe pro Relation erlaubt.
Indexe können von Anfang an (bei noch leerer Relation) oder nachträglich definiert werden.
Bei nachträglicher Definition und UNIQUE-Klausel müssen die betroffenen Attributwerte (bzw.
Attributwert-Kombinationen) dieses Prädikat erfüllen.

3.4 Datenmanipulation: Einfügen, Löschen und Ändern von Tupeln
3.4.1 Einfügen
I Syntaktische Struktur:
INSERT INTO Relationsname [(Attribut1 , Attribut2 , . . . )]
 ff
VALUES(Wert1 , Wert2 ,. . . )
Query
I Anmerkungen:
Sollen nicht alle Attribute, sondern nur einige mit Werten gefüllt werden, so können diese explizit
aufgezählt werden. Die nicht spezifizierten Attribute werden mit Nullwerten gefüllt.
Es können daher nur solche Attribute ausgeblendet werden, für die Nullwerte erlaubt sind.
Die Einfügewerte können als Konstante mittels VALUES-Klausel oder über eine Query bereit-
gestellt werden.
Anzahl und Typ der mittels VALUE-Klausel oder Query bereitgestellten Werte müssen mit den
implizit (keine Attributliste angegeben) oder explizit spezifizierten Attributen harmonieren.
SQL-92 sieht vor, dass mehrere Tupelkonstante, durch Kommata getrennt, angegeben werden
können.

Beispiele:
I1: Füge einen neuen Teilnehmer (TnNr 200) für Kurs ‘G08’ und AngNr 1 in die Gebühren-Relation
”
ein. Die Teilnamegebühr sei noch nicht bekannt.“
INSERT INTO Gebuehren VALUES (1, ‘G08’, 200, NULL)
alternativ:
INSERT INTO Gebuehren (AngNr, KursNr, TnNr) VALUES (1, ‘G08’, 200)
I2: Füge ein neues Kursangebot (AngNr 3) für ‘G08’ für den 15. März 1991 in ‘Ulm’ ein.“
”
INSERT INTO Angebot VALUES (3, ‘G08’, ‘15-03-1991’, ‘ULM’)
I3: Die Relation GEBUEHREN sei noch leer: Fülle die Attribute AngNr, KursNr und TnNr der
”
Relation mittels den Einträgen in der Relation Nimmt teil. Das Attribut Gebuehr soll noch ohne
Wert bleiben.“
INSERT INTO Gebuehren (AngNr, KursNr, TnNr)
SELECT *
FROM Nimmt teil
I4: Eine Relation KURS STATISTIK(AngNr,KursNr,Ort,Anz Tnr) sei geeignet definiert. Sie sei
”
noch leer. Sie soll mit den aktuellen Werten gefüllt werden.“
INSERT INTO Kurs Statistik
SELECT a.AngNr, a.KursNr, a.Ort, COUNT(nt.TnNr)

3.4.2 Löschen von Tupeln
I Syntaktische Form:
DELETE
FROM Relationsname
[ WHERE Bedingung ]
I Anmerkung: Löscht alle Tupel [, für die die WHERE-Bedingung erfüllt ist,] aus der angegeben
Relation.
D1: Entferne alle Tupel aus der TEILNEHMER-Relation.“

”
DELETE FROM Teilnehmer
Anmerkung: Es werden nur die Tupel gelöscht, die (leere) Relation selbst (als Eintrag im Katalog)
bleibt erhalten.
D2: Lösche in Nimmt Teil-Relation alle Einträge für Kurse, die vor dem 1. März 1990 stattgefunden
”
haben.“
DELETE
FROM Nimmt teil
WHERE (AngNr,KursNr) IN
( SELECT AngNr, KursNr
FROM Angebot
WHERE Datum <‘01-03-1990’)

D3: Lösche alle Einträge aus der Nimm teil-Relation, für die es keinen korrespondierenden Eintrag
”
(TnNr) in der Teilnehmer-Relation gibt“.
DELETE
FROM Nimmt teil
WHERE TnNr NOT IN
( SELECT TnNr
FROM Teilnehmer)

3.4.3 Ändern von Tupeln
I Syntaktische Form:
Form 1:
UPDATE Relationsname [ Korrelationsvariable ]
SET Attribut1 = Ausdruck1 [, Attribut2 = Ausdruck2 , . . . ]
[ WHERE Bedingung ]
Form 2:
UPDATE Relationsname [Korrelationsvariable]
SET (Attribut1 [, Attribut2 , . . . ] ) = ( subquery )
[ WHERE Bedingung ]
I Anmerkung: Die Wertänderung wird für alle Tupel durchgeführt, für die die WHERE-
Bedingung erfüllt ist ( Snapshot-Logik“)
”

U1: Erhöhe alle Kursgebühren (in der Relation GEBUEHREN) um 10%.“
”
UPDATE Gebuehren
SET Gebuehr = Gebuehr ∗ 1.1
U2: Wie U-1, aber nur für die Teilnehmer mit TnNr > 150.“
”
UPDATE Gebuehren
SET Gebuehr = Gebuehr ∗ 1.1
WHERE TnNr > 150
U3: Es existiere eine Relation STD GEBUEHR(KursNr, Gebuehr).

Setze alle Gebühren, für die noch kein Wert spezifiziert wurde, auf die Standardgebühr.“
”
UPDATE Gebuehren g
SET g.Gebuehr =
( SELECT s.Gebuehr
FROM Std Gebuehr s
WHERE g.KursNr = s.KursNr )
WHERE g.Gebuehr IS NULL

U4: Alle für ‘Ulm’ geplanten Kursangebote fallen aus. Setze AngNr für alle betroffenen Teilnehmer
”
in Nimmt teil auf NULL.“
UPDATE Nimmt teil

SET AngNr = NULL
WHERE (AngNr, KursNr) IN
(SELECT AngNr, KursNr
FROM Angebot
U5: TN STAMM(TnNr, Name, Ort, Strasse, Anmerkungen) enthalte für alle Kursteilnehmer stets
”
die aktuellen Personendaten. Aktualisiere die Tupel der Teilnehmer-Relation (Name, Ort) auf Basis
der TN STAMM Relation.“
UPDATE Teilnehmer t
SET (t.Name, t.Ort) =
( SELECT ts.Name, ts.Ort
FROM Tn Stamm ts
WHERE ts.TnNr = t.TnNr)

I Anmerkung: Die Semantik von mengen-orientierten Updates ist nicht immer ganz unproblema-
tisch (z.B. bei self-referencing updates“).
”
Beispiel 3-6:
Angest (AngestNr, Name, Gehalt, AbtNr)

Abteilung (Abtnr, Bez, MgrNr)
Setze das Gehalt des Managers der Abteilung ‘Spielwaren’ auf das Doppelte des Durchschnitts-
”
gehalts dieser Abteilung“
UPDATE Angest a
SET a.Gehalt = (SELECT 2∗AVG (Gehalt)
FROM Angest a1
WHERE a1.AbtNr = a.Abtnr)
WHERE a.AngNr = (SELECT MgrNr
FROM Abteilung
WHERE Bez = ‘Spielwaren’)
. . . durch den Update steigt das Durchschnittsgehalt!
☞ Die Auswertung der Assignment-Ausdrücke“ (sowie die Menge der zu ändernden Tupel)
”
muss (systemintern) vor dem ersten Update vorgenommen werden!

3.5 Autorisierung
I Syntaktische Grundstruktur:20
8 9 8 9
 ff < ALL PRIVILEGES <[ TABLE ] relview =
GRANT =
<privilege> ON DOMAIN domain
REVOKE :
[, <privilege>, . . . ]
; : ;
 ff . . .
PUBLIC
TO [ WITH GRANT OPTION ]∗)
userid1 [, userid2, . . . ]
8 9
>
>SELECT >
>
DELETE
>
> >
>
>
> >
>
INSERT [(Attrib1 [, Attrib2 , . . . ])]
< =
<privilege> ::=
>
>UPDATE [(Attrib1 [, Attrib2 , . . . ])] >
>
> >
:REFERENCES [(Attrib1 [, Attrib2 , . . . ])]
>
> >
>
> >
;
...
∗) nur in Verbindung mit GRANT wählbar
20 Entsprechend dem SQL 92 Standard

I Wirkungsweise/Erläuterungen:
Jeder Benutzer hat die volle Verfügungsgewalt (Lesen, Ändern, Löschen) über die von ihm/ihr
erzeugten ( privaten“) Relationen.
”
Andere Benutzer haben per Default keinerlei Zugriffsrechte auf private“ Relationen anderer
”
Benutzer.
Ein Benutzer kann Zugriffsrechte auf seine privaten“ Relationen an andere Benutzer (gezielt
”
oder an alle) vergeben.
Die Art des Zugriffsrechts kann beschränkt werden (z.B. auf lesenden Zugriff)
Beschränkung des Lesezugriffs auf ausgewählte Attribute mittels VIEW-Mechanismus.
Beschränkung des Änderungsrechts (UPDATE) auf ausgew ählte Attribute durch explizite An-
gabe der Attribute in der UPDATE-Klausel.
Erteilung der Erlaubnis zur Weitergabe ( Vererbung“) von Zugriffsrechten (=⇒ WITH GRANT
”
OPTION).
I Diese Art der Vergabe von Zugriffsrechten nennt man auch discretionary access control“, weil
”
es in der Verfügungsgewalt der Benutzer liegt, Zugriffsrechte zu vergeben. Im Gegensatz dazu be-
zeichnet mandatory access control“ eine Strategie, bei der zwingend jedem Paar Benutzer/Objekt
”
ein Zugriffsrecht zugeordnet werden muss. (s.a. später bei Datenschutz und Datensicherheit)

3.6 Gewährleistung referentieller Integrität
I Die Abbildung von Informationen aus der Realwelt in die relationale Modellwelt erfordert i.a. mehrere
Relationen zur adäquaten Darstellung21
I Die logische Verknüpfung zwischen den Relationen erfolgt über Primar-/ Fremdschlüsselbeziehun-
gen
I Als Folge davon entstehen Schemata mit z.T. komplexen Abhängigkeitsbeziehungen zwischen den
Relationen
Lieferant LiefNr LiefName TeileBest BestNr LiefNr Termin

FS
Liefert TeileNr LiefNr Preis TeileBestPos BestNr BestPos TeileNr Menge

FS FS FS FS
Teil TeileNr TeileBez Bestand
AuftragPos AuftrNr AuftrPos TeileNr Menge Preis Struktur OberTNr UnterTNr Anzahl
FS FS FS FS
Auftrag AuftrNr KdNr Termin Kunde KdNr KdName KdAnschrift

FS
Abbildung 3-2: Primärschlüssel – Fremdschlüssel (FS) – Beziehungen

21 auf die Frage der Abbildung der Realwelt in die Datenbank-Modellwelt werden wir in einem späteren Kapitel zurückkommen.

I Problem:
Gewährleistung, dass alle Referenzbeziehungen stets konsistent sind.
. bei Insert / Delete: kein Entstehen von Waisenkindern“
”
. bei Update: konsistente Änderung aller Referenzen
I Möglichkeiten:
passive Maßnahmen
☞ Zurückweisen konsistenzverletzender Operationen
. per geeigneter Sichten-Definition
. per DDL-Erweiterung
=⇒ Prüfklauseln
=⇒ Referenz-Beziehungen
aktive Maßnahmen
☞ konsistente Propagation von Änderungen
. per DDL-Erweiterung
=⇒ Kaskadierung von Änderungen
. Trigger-Mechanismen

3.6.1 Passive Integritätssicherung
I Einfügen eines Tupels in äbhängigerTabelle:
=⇒ Prüfung, ob das Fremdschlüssel-Attribut“ in übergeordneter“ Tabelle existiert.
” ”
I Löschen eines Tupels in übergeordneter“ Tabelle:
”
=⇒ Prüfung, ob irgendwo noch abhängige“ Tupel existieren.
”
3.6.1.1 DEFINE VIEW . . . WITH CHECK OPTION
I Korrektheits-Prüfung von Änderungsoperationen mittels geeigneter VIEW-Definition.

I Beispiel 3-7: Es sollen nur solche Kursangebote in die ANGEBOT-Relation eingetragen werden
”
können, deren Kursnummer tatsächlich auch existiert (Referenz: Kurs-Relation).“
1. Versuch:
CREATE VIEW AngebotNeu
AS
SELECT *
FROM Angebot
WHERE KursNr IN
(SELECT KursNr
FROM Kurs)

Test:
1. Einfügen zulässiges Tupel:
INSERT INTO AngebotNeu
VALUES (4,‘I09’, TO DATE(‘1-mar-91’), ‘Augsburg’) −→ OK
2. Einfügen nicht zulässiges Tupel:
VALUES (4,‘I10’, TO DATE(‘1-mar-91’), ‘Augsburg’) −→ OK !?
2. Versuch:
CREATE VIEW AngebotNeu AS
SELECT *
FROM Angebot
WHERE KursNr IN
(SELECT KursNr
FROM Kurs)
WITH CHECK OPTION

Test:
1. Einfügen zulässiges Tupel:
VALUES (4,‘I09’, TO DATE(‘1-mar-91’), ‘Augsburg’) −→ OK
2. Einfügen nicht zulässiges Tupel:
VALUES (4,‘I10’, TO DATE(‘1-mar-91’), ‘Augsburg’)
−→ ERROR. . . : view WITH CHECK OPTION where-clause violation
Bewertung als Schutz gegen Referenzverletzungen:

+m Relativ gute Absicherungsmöglichkeiten bzgl. Insert-Fehlern.
–m Stark eingeschränkte Tauglichkeit bzgl. Delete- und Update-Fehlern.

3.6.1.2 CREATE TABLE . . .: CHECK-Klausel
I Beispiel 3-8: (bezogen auf Abb. 3-2)

In die Relation Liefert“ sollen nur solche Tupel eingefügt werden können, für die TeileNr und
”
LiefNr in den Relationen Teil“ bzw. Lieferant“ bereits definiert sind:
” ”

(TeileNr DECIMAL(6) NOT NULL,
LiefNr DECIMAL(5) NOT NULL,
PREIS DECIMAL(8,2),
UNIQUE (TeileNr, LiefNr),
CHECK
(EXISTS
(SELECT *
FROM Teil
WHERE Teil.TeileNr = Liefert.TeileNr) AND
(EXISTS
(SELECT *
FROM Lieferant
WHERE Lieferant.LiefNr = Liefert.LiefNr)))

I Anmerkungen:
Die CHECK-Bedingung kann eine beliebige Query mit Resultattyp boolean
(−→ TRUE/FALSE) sein.22
Es werden später nur solche DML-Operationen ausgeführt, für welche die CHECK-Klausel zu
TRUE evaluiert wird.
Die Deklaration einer CHECK-Klausel ist jeweils an eine Tabellen-Deklaration
(−→ CREATE TABLE) gebunden.
Ab dem SQL2-Standard gibt es freistehende“ CHECK-Klauseln, die nicht Teil einer Tabellen-
”
Definition sind (−→ ASSERTIONS).
22 Im 1989’er SQL-Standard war der Scope der CHECK-Klausel noch auf die eigene Relation beschränkt. Diese Beschränkung ist
in SQL2 entfallen.

Mögliche Probleme bei Änderungsoperationen:
. . . die Transaktion, nicht das einzelne Statement ist die Einheit der Integritätserhaltung (s. unten)
I Beispiel 3-9: Änderung von LiefNr 444 in 4447.
Lieferant LiefNr LiefName

222 Maier Co.
333 Müller GmbH
444 Schmidt KG
REFERENCES REFERENCES
Liefert TeileNr LiefNr Preis TeileBest BestNr LiefNr Termin

3847 222 23.15 47123 444 960427
4921 333 17.22 47124 333 960501
5316 222 33.86 47125 222 960720
5319 444 11.47 47128 222 960418
5578 444 17.99
Abbildung 3-3: Fremdschlüssel-Beziehungen
I Durchführung dieser Änderung erfordert an sich drei Updates

Update Lieferant (444 −→ 4447)
=⇒ Waisenkinder“ in Liefert und TeileBest ⇒ reject!
”
Update TeileBest (444 −→ 4447)
=⇒ Referenzbedingung verletzt ⇒ reject!
dto. Update von Liefert ⇒ reject!

I Lösung: Deferred Constraint Checking23
 ff
ALL
SET CONSTRAINTS DEFERRED
constraint-name(n)
SQL-Anweisung1
SQL-Anweisung2
...  ff
ALL
SET CONSTRAINTS IMMEDIATE
constraint-name(n)
I Wirkungsweise:
Integritäts-Prüfungen werden temporär ausgesetzt und erst nach
SET CONSTRAINTS . . . IMMEDIATE durchgeführt.
Folgt auf DEFERRED“ keine IMMEDIATE“-Klausel, so werden die Integritäts-Prüfungen
” ”
automatisch bei COMMIT WORK durchgeführt.
Das Transaktionskonzept fordert Konsistenzerhaltung bei Änderungen erst zum Ende von
Transaktionen!
I Oracle V7: Aus-/Einschalten von benannten Constraints mittels ALTER TABLE-Anweisung24
23 In der vollen Version von SQL2 vorgesehen.

24 Achtung: Führt bei Oracle V7 jeweils zu einem impliziten Commit!

3.6.2 Aktive Integritätssicherung
⇒ führt in einer allgemeinen Form auf sog. Aktive/Reaktive Datenbanken“, Trigger“.

” ”
3.6.2.1 ON DELETE / UPDATE CASCADE

I Automatische Propagation von Änderungen in die abhängigen“ Relationen.
”
I Erweiterung der REFERENCES-Klausel
I Syntax:
. . . REFERENCES Relation [(Attrib1, Attrib2, . . . )]
2 8 93
 ff >
>CASCADE
 ff >
>
6ON DELETE NULL
6 < =7
SET 7 25,26
4 UPDATE > > DEFAULT >
>
5
NO ACTION
: ;
25 Im vollen Umfang (z.B. ON UPDATE . . .) erst in SQL2 definiert, teilweise aber bereits seit längerem verfügbar (z.B. DB2/6000 V2).
Zusätzlich noch optionale Klausel für initiale Belegung hinsichtlich IMMEDIATE/DEFERRED bzw. NOT DEFERRABLE.
26 In Oracle V7 ist ON DELETE CASCADE verfügbar, . . . UPDATE jedoch noch nicht.

I Beispiel 3-10: (für UPDATE)
(TeileNr DECIMAL(6) REFERENCES Teil
ON UPDATE CASCADE,
LiefNr DECIMAL(5) REFERENCES Lieferant
ON UPDATE CASCADE,
Preis DECIMAL(8,2),
UNIQUE TeileNr, LiefNr))
CREATE TABLE TeileBest

(BestNr DECIMAL(9) PRIMARY KEY,
LiefNr DECIMAL(5) REFERENCES Lieferant
ON UPDATE CASCADE,
Termin DATE)
I Beispiel für DELETE . . . CASCADE
CREATE TABLE Struktur
(OberTNr DECIMAL(5) REFERENCES Teile(TeileNr)
ON DELETE CASCADE,
UnterTNr DECIMAL(5) REFERENCES Teile(TeileNr)
ON DELETE CASCADE,
Anzahl DECIMAL(3))

I Wirkung von ON DELETE CASCADE:
Löschen äbhängigerTupel, ggf. kaskadierend
222 Maier & Co. DELETE
333 Müller GmbH
444 Schmidt KG
REFERENCES ...
ON DELETE CASCADE
TeileBest BestNr LiefNr Termin

47123 444 910427
47124 333 910501
47125 222 910720
47128 222 910418
REFERENCES ...
ON DELETE CASCADE
TeileBestPos BestNr BestPos TeileNr Menge

47123 1 5319 50
47123 2 5578 30
47124 1 4921 80
47125 1 3847 40
47125 2 5316 10
47128 1 5316 20
47128 2 3847 60

I Wirkung von ON UPDATE CASCADE:
=⇒ Propagation des geänderten Attributwertes in die referenzierenden Relationen.
Ausgangssituation: Lieferant LiefNr LiefName
222 Maier & Co.
333 Müller GmbH
444 Schmidt KG
REFERENCES ... REFERENCES ...

ON UPDATE CASCADE ON UPDATE CASCADE

3847 222 23.15 47123 444 960427
4921 333 17.22 47124 333 960501
5316 222 33.86 47125 222 960720
5319 444 11.47 47128 222 960418
5578 444 17.99
Update LiefNr
444 4447:
222 Maier & Co.
333 Müller GmbH
Update 4447 Schmidt KG
U p date U p date
444 4447 44 4 4447

3847 222 23.15 47123 444 960427
4921 333 17.22 47124 333 960501
5316 222 33.86 47125 222 960720
5319 444 11.47 47128 222 960418
5578 444 17.99
Resultat:
Lieferant LiefNr LiefName Liefert TeileNr LiefNr Preis TeileBest BestNr LiefNr Termin
222 Maier & Co. 3847 222 23.15 47123 4447 960427
333 Müller GmbH 4921 333 17.22 47124 333 960501
4447 Schmidt KG 5316 222 33.86 47125 222 960720
5319 4447 11.47 47128 222 960418
5578 4447 17.99
I Bewertung:
⊕ Wichtiges Konzept zur Erzwingung referentieller Integrität
⊕ Konzept kann durch geeignete Datenstrukturen auch implementierungsseitig effizient un-
terstützt werden (=⇒ Performance!)

3.7 Sichten
3.7.1 Einführung
Eine Sicht ist ein Ausschnitt“ aus der Datenbank (genauer: ein – möglicherweise umstrukturierter
”
– Teil des logischen DB-Schemas), der als externes Schema einem Benutzer/Anwendungsprogramm
zur Verfügung gestellt wird.
Eine Sicht ist eine zusätzliche, virtuelle“ (berechnete) Relation und wird wie diese angesprochen.
”
Es handelt sich um abgeleitete Daten; die Ableitung erfolgt bei jedem Zugriff, d.h. es wird kein
Schnappschuss“ bei der Definition der Sicht erzeugt, sondern die Sicht wird jedesmal beim Zugriff
”
neu berechnet“.
”
Änderungen der (Basis-) Relationen sind in den Sichten sichtbar und umgekehrt!
I Realisierung der Externen Ebene (⇒ ANSI 3-Ebenen-Architektur)
Abbildung 3-4: 3-Ebenen-Architektur

I Vorteile von Sichten:
Vereinfachung von Anfragen (→ Vorformulierung komplexer Teilanfragen)
Strukturierung der Datenbankbeschreibung nach individuellen“ Bedürfnissen
”
stabile Schnittstelle für Anwendungen (→ bei Schemaänderungen)
Datenschutz ( need-to-know“: Verbergen von nicht benötigten Daten)
”
I Beispiel:
Relation: Gegeben sei die folgende Relation des logischen DB-Schemas mit Prüfungsdaten:
Prüf(Studienfach, Fach, Student, Prüfer, Datum, Note)
Durch entsprechende Sichten können individuelle Informationsbedürfnisse befriedigt werden:

. Der Fachbereich Informatik und Informationswissenschaft sieht nur die Daten der eigenen“
”
Studenten.
. Das Prüfungsamt sieht alle Daten.
. Jeder Student darf seine eigenen Daten sehen (aber nicht ändern)
. Die Kommission zur Vergabe von Stipendien darf von Studenten die Durchschnittsnote
sehen.
. Der Dekan darf statistische Daten über Absolventen des letzten Jahrgangs lesen.
. Sekretariate dürfen Prüfungsdaten der zugehörigen Professoren einsehen.
I SQL-Syntax:
CREATE VIEW view-name AS query [ WITH CHECK OPTION ]

I Probleme mit Sichten:
Bearbeitung von Anfragen auf Sichten: Substituiere definierende SQL-Anfrage für den Namen
der Sicht ( Query Substitution“)
”
⇒ Orthogonalität der Sprache besonders wichtig: SQL ⇔ Relationenalgebra
Änderungsoperationen auf Sichten:
. Überhaupt zulässig? Eindeutigkeit? Welche Einschränkungen erforderlich?
. Wie sollen aus View-Updates die Updates der gespeicherten Datenbank hergeleitet werden?
. Welches sind vernünftige“ Update-Operationen?
”
I Kriterien für Änderungsoperationen:
Effektkonformität: Änderungen, die auf einer Sicht formuliert werden, sollen nach der Änderung
der Basisdatenbank zu einer Ausprägung der Sicht führen, die dem entspricht, als ob diese
Änderung direkt auf der Sicht ausgeführt wurde (⇒ Korrektheit der Transformation).
Minimalität: Die Basisdatenbank sollte nur minimal geändert werden, um den gewünschten
Effekt zu erzielen.
Konsistenzerhaltung: Die Änderung einer Sicht darf zu keinen Integritätsverletzungen der Ba-
sisdatenbank führen.
Respektierung des Datenschutz: Wird die Sicht aus Datenschutzgründen eingeführt, darf von
der Änderung nicht der bewusst ausgeblendete Teil der Basisdatenbank betroffen sein.

3.7.2 Verschiedene Arten von Sichten
. . . hier am Beispiel des Relationenmodells:

I Projektionssichten
I Selektionssichten
I Verbundsichten
I Aggregierungssichten
3.7.2.1 Projektionssichten (Project Views)

I Beispiel 3-11:
Gegeben seien zwei Relationen:
MGA(Mitarbeiter, Gehalt, Abteilung), AL(Abteilung, Leiter)
Projektionssicht MA
. In Relationenalgebra:
MA:= πMitarbeiter, Abteilung(MGA)
. In SQL:
CREATE VIEW MA AS SELECT Mitarbeiter, Abteilung FROM MGA

I Probleme:
Einfügungen: Setzen der Attribute, die in der Sicht fehlen . . . ?
Beispiel 3-12:
INSERT INTO MA VALUES (‘Zuse’, ‘Info’)
wird transformiert zu
INSERT INTO MGA VALUES (‘Zuse’, NULL, ‘Info’).
⇒ Konsistenzerhaltung: Gehalt darf nicht als NOT NULL deklariert worden sein. (Alternative:
Verwendung von Defaultwerten).
Nur wenn Schlüssel der Basisdatenbank in der Sicht erhalten bleiben, entspricht ein Tupel der
Sicht genau und eindeutig einem Tupel der Basisrelation.
3.7.2.2 Selektionssichten (Select Views)

I Beispiel 3-13:
Relationenalgebra:
MG := σGehalt>20πMitarbeiter, Gehalt(MGA)
SQL:
CREATE VIEW MG AS SELECT Mitarbeiter, Gehalt FROM MGA WHERE Gehalt > 20

I Problem: Ein Tupel der Sicht kann durch eine Änderung in den nichtselektierten Teil der Sicht
bewegt werden (Tupelmigration).
Beispiel 3-14:
Das Tupel MGA(‘Zuse’, 25, ‘Info’) wird durch
UPDATE MG SET Gehalt = 15 WHERE Mitarbeiter = ‘Zuse’
aus der Sicht MG entfernt!
Übersetzung:
UPDATE MGA SET Gehalt = 15 WHERE Mitarbeiter= ‘Zuse’ AND Gehalt > 20
Beachte:
Die Selektionsbedingung muss um die Sichtbedingung erweitert werden, da ansonsten auch ein
Tupel MGA(‘Zuse’, 10, ‘Info’) von der Änderung betroffen wäre, obwohl dieses nicht in der
Sicht MG liegt!
Ist die Sicht MG aus Datenschutzgründen angelegt worden, sollte die Änderung zurückgewiesen
werden.
Tupelmigration kann explizit durch die WITH CHECK OPTION-Klausel verhindert werden.
Beispiel 3-15:
CREATE VIEW MG AS
SELECT Mitarbeiter, Gehalt FROM MGA WHERE Gehalt > 20 WITH CHECK OPTION

3.7.2.3 Verbundsichten (Join Views)
I Beispiel 3-16:
Relationenalgebra: MGAL := MGA 1 AL
SQL:
CREATE VIEW MGAL AS

SELECT m.Mitarbeiter, m.Gehalt, m.Abteilung, a.Leiter
FROM MGA m, AL a
WHERE m.Abteilung=a.Abteilung
I Änderungstransformationen:
oft nicht eindeutig!
Minimalität
I Beispiel 3-17:
INSERT INTO MGAL VALUES (‘Turing’, 30, ‘Info’, ‘Zuse’)
Transformation:
1. MGA: INSERT INTO MGA VALUES (’Turing’,30,’Info’)
2. AL: hier sind ggf. verschiedene Änderungen denkbar:
(a) INSERT INTO AL VALUES (‘Info’, ‘Zuse’)
(b) UPDATE AL SET Abteilung=‘Info’ WHERE Leiter = ‘Zuse’
b) entspricht der Minimalitätsforderung, ist aber nicht effektkonform (die Mitarbeiter der
Abteilung Mathematik haben nun keinen Leiter mehr!).

I Analoge Probleme ergeben sich bei Löschungen. Etwa kann für die Löschung des Tupels
MGAL(‘Turing’, 30, ‘Info’, ‘Zuse’) entweder ein Tupel in MGA oder in AL oder in beiden Re-
lationen gelöscht werden.
Konsequenz: Änderungsoperationen für derartige Sichten in SQL verboten.
Analoge Probleme bei Mengenoperationen
3.7.2.4 Aggregierungssichten
I Verwendung von Gruppierung und Aggregierung
I Spezialfall von berechneten Werten in der DB.
I Beispiel 3-18:
CREATE VIEW AS(Abteilung,SummeGehalt) AS
SELECT Abteilung, SUM(Gehalt)
FROM MGA
GROUP BY Abteilung
I Änderung auf aggregierten Werten nicht sinnvoll:
I Beispiel 3-19:
UPDATE AS SET SummeGehalt = Summe + 1000
WHERE Abteilung = ‘Info’

I Klassifikation der Problembereiche:
Vermeidung von Integritätsverletzungen
Vermeidung von Seiteneffekten auf nichtsichtbaren Teile der Datenbank aus Datenschutz-
gründen
Minimalität ggf. nicht eindeutig ⇒ Auswahlproblem
Keine sinnvolle Transformation möglich
1:1-Beziehung zwischen Sicht und Basisdatenbank kann verletzt sein (etwa beim Wegprojizieren
von Schlüsseln).

3.7.3 Integritätswahrung bei Sichten in SQL
I Integritätsverletzende Änderungen in Sichten werden zurückgewiesen.
I Die Behandlung potentiell datenschutzverletzender Sichtänderungen unterliegt der Benutzerkon-
trolle (⇒ ‘WITH CHECK OPTION’-Klausel).
I Sichten, die zu nicht eindeutigen Transformationen bei Änderungen führen können, werden als nicht
änderbar klassifiziert (unabhängig von einer speziellen Änderungsoperation). Auf diesen Sichten sind
keine Änderungen erlaubt.
I Elementare Änderungen auf Sichtebene müssen zu elementaren Änderungsoperationen der Basis-
relation abgebildet werden (⇒ DISTINCT-Klausel).
I Eine Sicht ist in SQL genau dann änderbar, wenn alle folgenden Bedingungen erfüllt sind:
Die Sicht ist eine reine Selektionsabfrage (d.h.: kein Verbund, keine Mengenoperationen).
Es ist kein DISTINCT enthalten.
Keine Arithmetik und Aggregatsfunktionen in der SELECT-Klausel.
Genau eine Referenz auf eine Relation im FROM-Teil
Keine Unterabfragen mit Selbstbezug, d.h. die in der FROM-Klausel angesprochene Relation
darf nicht in FROM-Klauseln der Unterabfragen verwendet werden.
Keine Gruppierung

3.7.4 Auswertungsaspekte
I Grundidee bei der Ausführung von Anfragen auf Sichten:
Setze die View-Definition (=SQL-Anfrage1) in die Benutzer-Anfrage (=SQL-Anfrage2) an
der Stelle ein, wo der Name der Sicht angesprochen wird.
. . . rein syntaktische String-Ersetzung. Aber: in SQL aufgrund div. Einschränkungen der Or-
thogonalität nicht möglich!
I Restriktionen von SQL:
Einsetzungen von Unterabfragen im FROM-Teil seit SQL-92 möglich, aber (noch) nicht in
allen SQL-Dialekten (-Implementierungen); außerdem: View-Ersetzung auch schon vorher!
Geschachtelte Aggregierungen nicht in einer SQL-Anfrage möglich.
I Konsequenz:
In SQL können Sichten nicht direkt durch Einsetzen der Definitionen ausgewertet werden.
Deswegen wird ein syntaktisches Mischen“ vorgesehen:
”
. In der SELECT-Klausel werden Sichtattribute ersetzt bzw. durch ihren Berechnungsterm
ersetzt.
. Im FROM-Teil werden die Namen der Originalrelationen aufgeführt.
. In der WHERE-Klausel erfolgt eine konjunktive Verknüpfung von Sicht- und
Anfragebedingungen.

Dies kann zu unerwarteten Problemen führen:
Beispiel 3-20:
. Sicht:
CREATE VIEW DS (Abteilung, GehaltsSumme) AS
SELECT Abteilung, SUM(Gehalt)
FROM MGA
GROUP BY Abteilung
. Anfrage:
SELECT Abteilung
FROM DS
WHERE GehaltsSumme > 500
. Mögliche Übersetzungen:
SELECT Abteilung
FROM MGA
WHERE SUM(Gehalt) > 500
GROUP BY Abteilung
SELECT Abteilung
FROM MGA
GROUP BY Abteilung
HAVING SUM(Gehalt) > 500

Beispiel 3-21:
. Anfrage:
SELECT AVG(GehaltsSumme)
FROM DS
. Übersetzung durch Mischen:
SELECT AVG(SUM(Gehalt))
FROM MGA
GROUP BY Abteilung
Aber: Geschachtelte Aggregationsfunktionen nicht erlaubt in SQL!
⇒ Diese Anfrage kann nur mit geschachtelten Unteranfragen im FROM-Teil ausgeführt
werden.

3.8 Nullwerte in SQL
I SQL unterstützt einen speziellen Wert NULL für alle Domänen.
I Dieser hat die Bedeutung Wert nicht bekannt“ und ist verschieden von dem numerischen Wert
”
0 und einer Zeichenkette der Länge 0.
I Behandlung von Nullwerten
spezielle Selektionsbedingung bzgl. Nullwerten:
. . . WHERE Attrib IS [NOT] NULL
Sortieren nach nullwertigem Attribut: Tupel mit Nullwerten in dem betreffenden Attribut stehen
stets am Anfang der Ergebnis-Tabelle, egal ob ASC oder DESC angegeben wurde.
In arithmetischen Ausdrücken: Wenn einer oder beide Operanden nullwertig sind, ist das
Ergebnis NULL.
In booleschen Ausdrücken:
TRUE ∧ NULL ⇒ NULL

TRUE ∨ NULL ⇒ TRUE
const = NULL ⇒ unknown
const ! = NULL ⇒ unknown
Bei Gruppierung (GROUP BY) nach nullwertigem Attribut: Nullwert wird wie ein normaler
Wert behandelt, bildet ggf. eine eigene Gruppe.
Bei Anwendung von Aggregat-Funktionen (AVG, SUM, COUNT, . . . ): Nullwerte werden bei
der Auswertung ignoriert.

Beispiele: Gegeben sei die folgende Relation:
Gebuehren AngNr KursNr TnNr Gebuehr
2 G08 143 500.00
2 P13 143 400.00
1 G08 145 ← Nullwert
1 P13 146 300.00
1 I09 146 ← Nullwert
2 P13 149 350.00
1 I09 173 400.00
2 P13 177 ← Nullwert
1 I09 185 450.00
1 P13 194 ← Nullwert
⇒ In der Literatur werden Nullwerte oftmals durch verschiedene Sonderzeichen, z.B. ω, ⊥

dargestellt. Hier verwenden wir einfach eine Leerstelle.
. Darüber hinaus kann man verschiedene Sorten von Nullwerten unterscheiden (z.B. Wert
”
unbekannt, aber vorhanden – unknown“, Wert existiert nicht – not existent“, es ist nicht
” ”
bekannt, ob ein Wert existiert – no information“, . . .)
. SQL kennt jedoch nur einen Nullwert NULL“ mit der Bedeutung Wert unbekannt“.
” ”

N1:
SELECT Gebuehren.*, Gebuehr - 100
FROM Gebuehren
AngNr KursNr TnNr Gebuehr Gebuehr-100
2 G08 143 500.00 400.00
2 P13 143 400.00 300.00
1 G08 145
1 P13 146 300.00 200.00
1 I09 146
2 P13 149 350.00 250.00
1 I09 155
1 I09 171
1 I09 173 400.00 300.00
2 P13 177
1 I09 185 450.00 350.00
2 I09 187
1 P13 194

N2:
SELECT COUNT(*), SUM(Gebuehr),
SUM(Gebuehr)/COUNT(*), AVG(Gebuehr)
FROM Gebuehren
COUNT(*) SUM(Gebuehr) SUM(Gebuehr)/COUNT(*) AVG(Gebuehr)
13 2400.00 184.615 400.00
Die hierbei auftretende Unstimmigkeit ist in der Literatur als SQL-Count Bug“ be-
”
kannt geworden.

N3:
SELECT *
FROM Gebuehren
ORDER BY KursNr, AngNr
AngNr KursNr TnNr Gebuehr
1 G08 145
2 G08 143 500.00
1 I09 146
1 I09 155
1 I09 173 400.00
1 I09 185 450.00
1 I09 171
2 I09 187
1 P13 146 300.00
1 P13 194
2 P13 143 400.00
2 P13 177
2 P13 149 350.00

N4:
SELECT AngNr, KursNr, SUM(Gebuehr), AVG(Gebuehr)
FROM Gebuehren
GROUP BY KursNr, AngNr
ORDER BY KursNr, AngNr
AngNr KursNr SUM(Gebuehr) AVG(Gebuehr)
1 G08
2 G08 500.00 500.00
1 I09 850.00 425.00
2 I09
1 P13 300.00 300.00
2 P13 750.00 375.00

3.9 Erweiterte Relationenalgebra
N5. Gib alle Kurse (Ausgabe: KursNr, Titel) zusammen mit ihren eventuellen direkten Voraussetzun-
”
gen (Ausgabe: VorNr) aus.“
Ausgangs-Relationen:
Kurs KursNr Titel Vorauss VorNr KursNr

G08 Grundlagen I G08 P13
G10 Grundlagen II G10 P13
P13 C-Programmierung G08 I09
I09 Datenbanken G10 I09
P13 I09
SQL-Formulierung (Versuch):
SELECT Kurs.*, Vorauss.VorNr
FROM Kurs, Vorauss
WHERE Kurs.KursNr = Vorauss.KursNr
Resultat Problem:
KursNr Titel VorNr
Kurse, die keine Voraussetzungen haben
P13 C-Programmierung G08
P13 C-Programmierung G10 (hier: G08 und G10), erscheinen nicht in
I09 Datenbanken G08 der Ergebnis-Relation bzw. der Ausgabe,
I09 Datenbanken G10 da der Join sie wegfiltert“.
I09 Datenbanken P13 ”
G08 ??
G10 ??

3.9.1 Outer Joins
R @F S: Linker Außen-Verbund“ (left outer join): Alle Tupel der linken Relation (d.h. alle
”
R-Tupel) sind im Ergebnis enthalten. Gibt es für ein Tupel ri ∈ val(R) kein S-Tupel,
das F erfüllt, so werden die S-Attribute im Ergebnis-Tupel mit Nullwerten aufgefüllt.
Achtung: @ F und @ F sind nicht kommutativ!
I Formen des Outer Join (gemäß SQL 2):
Left Outer Join: Stellt sicher, dass alle Zeilen der linken Tabelle im Ergebnis enthalten
sind (siehe unten)
Right Outer Join: Analog, jedoch überleben hier die Zeilen der rechten Tabelle
Full Outer Join: Kombination von Left + Right Outer Join: Alle Zeilen beider Tabel-
len sind mind. 1× im Ergebnis enthalten (ggf. links oder rechts mit
Nullwerten aufgefüllt)

I Beispiel 3-22:
R A B S C D
1 Hans 2 München
2 Ilse 2 Ulm
3 Hans 3 Stuttgart
4 Klara 6 Passau
R @ A=C S: A B C D S @ C=A R: C D A B
1 Hans ←
Nullwerte
2 Ilse 2 München
2 Ilse 2 Ulm
3 Hans 3 Stuttgart
4 Klara ←
Formulierung von Anfrage N5 mittels (Left) Outer Join:27

KursNr Titel VorNr
N5’: G08 Grundlagen I ← Nullwert
SELECT k.*, v.VorNr
G10 Grundlagen II ← Nullwert
FROM Kurs AS k LEFT OUTER JOIN I09 Datenbanken G08
Vorauss AS v 28 I09 Datenbanken G10
ON k.KursNr = v.KursNr I09 Datenbanken P13
27 Wie in SQL 2 spezifiziert

28 SQL-2 verbindet die Korrelationsvariable mit dem Tabellennamen mittels AS-Klausel

I Hinweise zu ORACLE
ORACLE verwendet (noch?) eine andere syntaktische Form, um den Outer Join darzustellen.
Die Anfrage N5’ wird deshalb in ORACLE wie folgt formuliert:
SELECT ks.*, v.VorNr

FROM Kurs k, Vorauss v
WHERE k.KursNr = v.KursNr (+)
Das ”(+)” im obigen Beispiel bezieht sich auf die Vorauss-Relation. – Es wird (bei ORACLE)
also derjenige Operand markiert, der ggfs. mit Nullwerten aufgefüllt wird!
In einer Outer-Join-Anweisung darf (bei ORACLE) höchstens eine Tabelle ohne ”(+)” auftre-
ten.
Wird der Outer Join über mehr als ein Attribut (z.B. bei zusammengesetztem Schlüssel)
spezifiziert, so muss ”(+)” für alle diese Attribute in der WHERE-Klausel angegeben werden
(siehe Anfrage-Beispiel S4)
☞ Achtung:
Nullwerte sind spezielle logische Werte und entsprechen nicht einem Leerzeichen oder dem
numerischen Wert Null! (→ Dreiwertige Logik (true, false, unknown))

N6. Gib alle Kursangebote (Ausgabe: *) zus. mit den vorliegenden Anmeldungen (TnNr) aus.“
”
SELECT a.*, nt.TnNr SQL 2
FROM Angebot AS a LEFT OUTER JOIN Nimmt teil AS nt
ON (a.KursNr = nt.KursNr) AND (a.AngNr = nt.AngNr)
SELECT a.*, nt.TnNr ORACLE
WHERE a.KursNr = nt.KursNr (+) AND
a.AngNr = nt.AngNr (+)
AngNr KursNr Datum Ort TnNr
1 G08 13–01–1996 München 145
2 G08 24–02–1996 Bremen 143
1 G10 01–02–1996 München
2 G10 15–02–1996 Hamburg
1 I09 27–03–1996 Stuttgart 146
1 I09 27–03–1996 Stuttgart 155
1 I09 27–03–1996 Stuttgart 173
1 I09 27–03–1996 Stuttgart 185
1 I09 27–03–1996 Stuttgart 171
2 I09 23–04–1996 Hamburg 187
3 I09 29–05–1996 München
1 P13 28–05–1996 Ulm 146
1 P13 28–05–1996 Ulm 194
2 P13 01–07–1996 Essen 143
2 P13 01–07–1996 Essen 177
2 P13 01–07–1996 Essen 149

N7. Wie S4, aber zusätzlich zur Teilnehmernummer soll jeweils auch noch der Teilnehmername
”
ausgegeben werden.“
SELECT a.*, nt.TnNr, t.Name ORACLE

FROM Angebot a, Nimmt teil nt, Teilnehmer t
a.AngNr = nt.AngNr (+) AND
nt.TnNr = t.TnNr (+)
N8. Gib alle Kursangebote aus, für die sich kein Teilnehmer angemeldet hat“.
”
SELECT a.*, nt.TnNr ORACLE
a.AngNr = nt.AngNr (+) AND
nt.TnNr IS NULL
I Anmerkungen:
Die obige SQL-Anfrageformulierung mittels Outer Join ist eine von mehreren Möglichkeiten,
Anfrage S9 in SQL umzusetzen.
Der Test auf Nullwert muss mittels IS NULL bzw. IS NOT NULL durchgeführt werden.
= NULL“ bzw. <> NULL“ führen nicht zum gewünschten Ergebnis.
” ”
Tests mittels IS [NOT] NULL sind auch ohne Outer Joins in Selektionen möglich.

3.10 Literaturhinweise
Abiteboul, S., R. Hull und V. Vianu (1995). Foundations of Databases. Addison-Wesley.
Date, C.J. und H. Darwen (1993). A Guide to the SQL Standard. Addison-Wesley Publ. Comp., 3 Aufl.
Heuer, A. und G. Saake (2000). Datenbanken: Konzepte und Sprachen. MITP Verlag, Bonn, 2. Aufl.
ISO (1992). Database Language SQL, International Standard. ISO. ISO/IEC 9075:1992, DIN 66315.
Kandzia, P. und H.-J. Klein (1993). Theoretische Grundlagen relationaler Datenbanksysteme. BI Wissenschafts-
verlag, Reihe Informatik.
Melton, J. und A. Simon (1993). Understanding the New SQL: A Complete Guide. Morgan Kaufmann Publishers.
Rautenstrauch, C. und M. Moazzami (1990). Effiziente Systementwicklung mit ORACLE . Addison-Wesley.


SQL Full

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SQL Full

Hochgeladen von

Copyright:

Verfügbare Formate

3 SQL – Structured Query Language

I SQL (früherer Name: SEQUEL): Zunächst Abfragesprache des relationalen DBMS-Prototyps

I Basisbaustein: Select-From-Where-Block (SFW-Block)

Bedeutung SFW: πAttributliste (σPrädikat |(R1 × ·{z

3.2.1 Ein-Tabellen-Operationen (Selektion/Projektion)

I SQL enthält auch zusätzliche Operatoren für bestimmte Datentypen:

FROM Rel 1, Rel 2,. . . Rel n

SELECT f.KursNr, f.AngNr, lt.Name

KursNr AngNr Name

SELECT f.KursNr, f.AngNr, lt.Name, k.Titel, a.Datum, a.Ort

KursNr AngNr Name Titel Datum Ort

I Form 1: SELECT Attributliste

I Form 2: SELECT Attributliste

I Form 3: SELECT Attributliste

Möglichkeit 2: (korrelierte) Subquery mit EXISTS

SELECT DISTINCT nt.KursNr, nt.AngNr

Möglichkeit 4: Subquery mit IN

Output Input für Output n mal

Sub- Startbedingung Sub-

Abbildung 3-1: Nicht-korrelierte und korrelierte Subqueries (schematische Darstellung)

Alternative Formulierung ALL-Quantor:

S13. Gib die Anzahl aller Kursteilnehmer aus ‘Ulm’ aus.“

S14. Gib das durchschnittliche Gehalt aller Kursleiter aus.“

SELECT MAX(Gehalt), MIN(Gehalt),

SELECT nt.KursNr, nt.AngNr

SELECT Ort, COUNT . . . ?

SELECT Ort, COUNT(Ort)

Erläuterung und ergänzende Kommentare:

SELECT kl.*, a.*

PersNr Name AngNr KursNr Datum Ort

KursNr Titel COUNT(*)

5 Bei ORACLE werden die Attributnamen vom oberen“ Query-Ausdruck übernommen.

SELECT Name, TnNr AS Nummer

S25. Wie S24, aber nach Nummer sortiert.“

SELECT t.Ort, nt.AngNr, nt.KursNr

Ort AngNr KursNr

3.3.1 Erzeugen von Relationen

CREATE TABLE Gehalt

CREATE TABLE Relationsname

CREATE DOMAIN GehaltType AS DECIMAL(8,2)

I Erweiterte SQL-DDL mit Primärschlüssel- (−→ PRIMARY KEY) und Fremdschlüssel-Angabe

Wirkungsweise von PRIMARY KEY . . . REFERENCES

17 HEAP ist die interne Standard-Repräsentation bei INGRES

18 siehe später bei Transaktionsverwaltung

DROP INDEX Indexname [ON Relationsname]

D1: Entferne alle Tupel aus der TEILNEHMER-Relation.“

U3: Es existiere eine Relation STD GEBUEHR(KursNr, Gebuehr).

UPDATE Nimmt teil

Angest (AngestNr, Name, Gehalt, AbtNr)

. . . durch den Update steigt das Durchschnittsgehalt!

20 Entsprechend dem SQL 92 Standard

Lieferant LiefNr LiefName TeileBest BestNr LiefNr Termin

Liefert TeileNr LiefNr Preis TeileBestPos BestNr BestPos TeileNr Menge

Teil TeileNr TeileBez Bestand

Auftrag AuftrNr KdNr Termin Kunde KdNr KdName KdAnschrift

Abbildung 3-2: Primärschlüssel – Fremdschlüssel (FS) – Beziehungen

3.6.1.1 DEFINE VIEW . . . WITH CHECK OPTION

I Korrektheits-Prüfung von Änderungsoperationen mittels geeigneter VIEW-Definition.

Bewertung als Schutz gegen Referenzverletzungen:

I Beispiel 3-8: (bezogen auf Abb. 3-2)

CREATE TABLE Liefert

I Beispiel 3-9: Änderung von LiefNr 444 in 4447.

Lieferant LiefNr LiefName

SELECT kl., a.