Sie sind auf Seite 1von 93

3 SQL – Structured Query Language

3.1 Überblick

I SQL (früherer Name: SEQUEL): Zunächst Abfragesprache des relationalen DBMS-Prototyps


System R“, Impl. ab Anf. 70er Jahre im IBM Forschungslabor in San Jose, CA.

I Sprachimplementierung unterstü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 verfügbar:
IBM (DB2,. . .), DEC (RDB), Oracle, Ingres, Informix, MS Access, MS SQL-Server, . . .
I Anfang/Mitte der 80er Jahre Standardisierungsaktivitäten am ANSI fü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 übernommen.
I 1989 Erweiterung von ISO 9075 (DIN-ISO 9075 folgte 1990), u.a. um Regeln für die Un-
terstützung referentieller Integritä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 Integritätsbedingungen erzwungen werden.
 Bei Anfrage-Resultaten müssen i.d.R. – wo gewünscht – explizit (per Operator) Duplikate
entfernt werden.
 SQL-Anfragen:
. bilden die Relationenalgebra weitgehend ab.
. Grenzen bei der Orthogonalität
. enthalten zusätzlich Aggregationsfunktionen, Gruppierung, Sortierung, spezielle Operationen
für einige Datentypen
 SQL bietet zusä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 enthält deswegen 3 Levels“)

I Nächster/Aktueller Standard: SQL-3“, u.a. zusätzliche Funktionalität für

 Objekte
 Multimedia-Daten (→ Erweiterung)
 Zeitdaten
 rekursive Anfragen
. . . verabschiedet Ende 1999. Hier noch weitgehend SQL-2


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-2
3.2 Anfragen

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


Syntaktische Grundstruktur (vereinfacht):

» ff–
[ALL]
SELECT Attributliste FROM R1, . . . , Rn [ WHERE Prä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 (σPrädikat |(R1 × ·{z


· · × Rn )
}
Produkt!
 Dabei ist
. ALL/DISTINCT. . . Kennzeichnung für mit/ohne Duplikate
[Im folgenden der Einfachheit halber meist ohne DISTINCT“!]

. Attributliste . . . von der Form Ri .Aij , . . .“

oder Ri .∗“ oder ∗“ (= alle Attribute)
” ”
. Prädikat . . . Attribute (Ri .Ai j ), Konstanten,
=, 6=, <, . . ., AND, OR, NOT, u.v.m.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-3
 Anmerkungen/Hinweise:
. SELECT – Klausel ist Projektion (nicht Selektion)
. (gedankliche) Reihenfolge der Anwendung FROM→WHERE→SELECT
I Im folgenden schrittweise Erlä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 entfällt in diesem Fall, da keine einschrä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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-4
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 enthält auch zusätzliche Operatoren für bestimmte Datentypen:


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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-5
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 ausgedrückt!
. Es sind auch andere Vergleichsoperatoren zugelassen.
. SQL 2 sieht explizite Join-Operationen vor (s. später)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-6
S4. Gib aus, welche Kursangebote (Ausgabe: KursNr, AngNr) von welchen Kursleitern (Ausgabe:

Name) durchgefü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 Mü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.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-7
S5. Wie S4, aber zusä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 München
G08 2 Huber,L. Grundlagen I 24 − 02−1996 Bremen
G10 1 Müller,K. Grundlagen II 01 − 02−1996 Mü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 München


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-8
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 Möglichkeiten zur Formulierung von Joins wesentlich verbessert worden, da
diese direkt in der FROM-Klausel ausgedrückt werden können (und somit die WHERE-Klausel
vereinfachen). Mö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.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-9
3.2.3 Subqueries / Existenzbedingungen

I Form 1: SELECT Attributliste


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

I Form 2: SELECT Attributliste


FROM Rel 1, Rel 2,. . . , Rel n
8 < 9
> <= >
 ff >
>
< >
> » ff–
R i .Attr name =
= ANY
WHERE
(R i .Attr name, R j .Attr name, . . . ) >
> <> >
> ALL
: >= >
> ;
>
(SELECT-FROM-WHERE-Ausdruck)

I Form 3: SELECT Attributliste


FROM Rel 1, Rel 2,. . . , Rel n
R i .Attr name
 ff
WHERE (R .Attr name, R .Attr name, . . . ) [ NOT ] IN
i j
(SELECT-FROM-WHERE-Ausdruck)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-10
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!) zurückgeliefert wird. Dieser wird als Ver-
gleichswert ( Quasi-Konstante“) im äußeren (Sub-)Query-Ausdruck verwendet.1

 = ANY ist äquivalent zu IN, NOT IN ist äquivalent zu <> ALL.
 Subquery-Ausdrücke können geschachtelt sein, d.h. sie können wiederum Subquery-Ausdrücke
enthalten.
 In Subquery-Ausdrücken kann auf Relationen von äußeren (Sub-)Query-Ausdrücken Bezug ge-
nommen werden: =⇒ korrelierte Subqueries (correlated subqueries)
 Subqueries liefern (Ausnahme: Form 1) per Default ebenfalls Multimengen als Resultat zurück.
Ggf. muss dies mittels SELECT DISTINCT verhindert werden.
 Je nach Anfragebearbeitungs-Strategie bzw. Güte der Anfrage-Optimierung des verwendeten
DBMS können sich bei semantisch ä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 eingeführt.
i j
Er wurde aber von einigen DBMSen (z.B. ORACLE) bereits schon vorher unterstützt.
2 Eine ausführliche Behandlung dieses Aspektes findet sich – neben anderen Dingen – z.B. in: (Rautenstrauch und Moazzami
1990)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-11
S7. Gib alle Kursangebote aus (Ausgabe: KursNr, AngNr), für die Teilnehmer aus ‘Ulm’ gebucht

haben.“
Mö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

Möglichkeit 2: (korrelierte) Subquery mit EXISTS

SELECT DISTINCT nt.KursNr, nt.AngNr


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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-12
Mö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’)

Möglichkeit 4: Subquery mit IN


SELECT DISTINCT nt.KursNr, nt.AngNr
FROM Nimmt teil nt
WHERE nt.TnNr IN
(SELECT TnNr
FROM Teilnehmer
WHERE Ort = ‘Ulm’)

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 später eine alternative Formulierung zu der EXISTS-Formulierung mittels COUNT
kennenlernen.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-13
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)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-14
S8. Gib alle Kursangebote (Ausgabe: Angebot.*) aus, für die keine Anmeldungen vorliegen.“

S9. Gib die Personalnummer des Kursleiters mit dem hö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:


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-15
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.' ) )


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-16
3.2.4 Aggregat- und Gruppierungs-Funktionen
I SQL bietet standardmäß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 führenden und/oder anhängen-
TRIM LEADING char FROM src str ) den Zeichen (∗)
: ;
TRAILING Beispiel: TRIM BOTH ’ ’ FROM ’ qaa ’ → ’qaa’
TRANSLATE, CONVERT Zur Unterstützung verschied. Zeichensä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 eingeführt, allerdings z.T. bereits in einigen DBMS unterstützt
3 Als Datentyp DATE bzw. TIMESTAMP


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-17
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 enthält, so wird nur max. ein
Resultat-Tupel erzeugt.
Ausnahme: Bei Verwendung der GROUP BY-Klausel (kommt später).


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-18
S15. Gib das höchste, das niedrigste und das durchschnittliche Kursleiter-Gehalt sowie die Summe aller

Gehälter aus.“

SELECT MAX(Gehalt), MIN(Gehalt),


AVG(Gehalt), SUM(Gehalt)4
FROM Kursleiter

S16. Anfrage S9: Gib die Personalnummer des Kursleiters mit dem hö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 möglicherweise nicht von allen DBMS unterstützt. Bei
ORACLE ist dies zulässig.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-19
S17. Gib die Anzahl der verschiedenen Orte aus, aus denen die Kursteilnehmer kommen.“

S18. Gib alle Kursangebote aus (Ausgabe: KursNr, AngNr), fü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)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-20
S19. Gib auf Basis der Teilnehmer-Relation eine ortsbezogene Teilnehmerstatistik aus (Ausgabe: Orts-

name, Teilnehmerzahl).“

SELECT Ort, COUNT . . . ?


FROM Teilnehmer

Lö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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-21
I Syntaktische Struktur:
SELECT [ALL|DISTINCT] Attributliste
FROM Relationenliste
[ WHERE Nebenbedingung]
[ GROUP BY Gruppierungsattribut(e)
[HAVING Gruppierungsbedingung]]
[ ORDER BY Attributliste]

Erläuterung und ergä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 ausgeführt
(gedankliche (!) Ausführungs-“reihenfolge jetzt also:

FROM→WHERE→GROUP BY→HAVING→ORDER BY→SELECT)
 In der SELECT-Klausel können – bei Angabe von GROUP BY – neben Aggregat-Funktionen
auch Gruppierungsattribute stehen.
 Gruppierungsnebenbedingungen werden mittels HAVING-Klausel ausgedrückt (HAVING kann
nur in Verbindung mit GROUP BY auftreten).
 Beziehung WHERE↔HAVING:
. WHERE eliminiert einzelne Zeilen
. HAVING eliminiert einzelne Gruppen

c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-22
Wirkungsweise von GROUP BY

. . . unter Verwendung von nicht normalisierten“ oder geschachtelten“ Relationen kann man die
” ”
Wirkung von GROUP BY einfach wie folgt erlä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 Beschränkungen bzgl. nachfolgender Projektionen (SELECT-Klausel) erforderlich,
damit das Ergebnis wieder eine flache“, d.h. normalisierte, Relation ist.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-23
S20. Gib fü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 Mü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, für die mehr als 2 Anmeldungen vorliegen.“

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
HAVING COUNT(*) > 2
AngNr KursNr Datum Ort COUNT(*)
1 I09 27 − 03−1996 Stuttgart 5
2 P13 01 − 07−1996 Essen 3


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-24
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 München
29594 Schulze,H. 2 I09 23 − 04−1996 Hamburg
38197 Huber,L. 1 G08 13 − 01−1996 München
38197 Huber,L. 2 G08 24 − 02−1996 Bremen


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-25
Alternative Query-Formulierung fü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, fü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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-26
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 / Erläuterungen:
 In SQL 89 war nur UNION definiert
 Die Ergebnis-Relationen der beiden Query-Ausdrücke (die Operanden) müssen hinsichtlich
Anzahl und Typ der Spalten identisch sein. – Bei Angabe von CORRESPONDING wird zu-
vor eine Projektion auf die angegebenen Attribute durchgeführt.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-27
Anmerkungen (Forts.):
 UNION, EXCEPT und INTERSECT führen automatisch eine Duplikateliminierung durch.
– Durch Angabe von ALL kann dies unterdrückt werden.
 Die Attributnamen der Operanden-Relationen“ können von einander abweichen.5

 Die ORDER BY-Klausel – falls angegeben –, muss am Ende des Query-Ausdrucks stehen.
 Anstelle von Attributnamen können in der ORDER BY-Klausel auch wieder die Positionsnum-
mern der entsprechenden Attribute angegeben werden.
 Die Mengenoperationen sind nur auf dem äußersten Query-Level zulässig, nicht in Subqueries
(SQL-92).
 Kurzschreibweisen (fü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 übernommen.



c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-28
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’


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-29
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
FROM Angebot a, Nimmt teil nt
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-30
3.3 Datendefinition: Erzeugen, Löschen und Ä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))


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-31
I Syntaktische Grundstruktur:6

CREATE TABLE Relationsname


„ » ff–
NULL
Attributname1 Datentyp1
NOT NULL
» » ff– –«
NULL
, Attributname2 Datentyp2 ,. . .
NOT NULL

I Datentypen:7
Datentyp Spezifikation Erlä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(Länge) feste Länge, max. 255 Zeichen
Zeichenkette VARCHAR2(Länge) var. Länge, max. 2.000 Zeichen
Zeichenkette LONG max. 2 GB
Bytestring LONG RAW var. Lä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 für denselben Datentyp. Die Beschrä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)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-32
I Datentypen in SQL 92:
 Grundsätzlich: Verschiedene Schreibweisen für dasselbe bzw. ähnliche Konstrukt aus Kompati-
bilitätsgrü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)
 Binärfelder (LONG RAW in ORACLE): Werden als BIT (feste Länge) bzw. BIT VARYING
(variable Länge) deklariert.
 Zusätzlich weitere Datentypen wie
. TIME
. TIMESTAMP
. TIME WITH TIME ZONE
. Nationale Zeichensätze
. ...


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-33
I Anmerkungen:
 Jede Tabelle/Relation gehört zu einem SCHEMA9 . Relationsnamen innerhalb eines Schemas
mü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 zurückgewiesen, die
für dieses Attribut einen NULL-Wert liefern.
 Der DB-Katalog ist i.a. als Sammlung von Relationen realisiert.10
 Folge: Katalog-Relationen können wie normale Relationen abgefragt werden.
 Für einige Katalogeinträge sind spezielle Zugriffs-Privilegien erforderlich (z.B. DBA-Status).
 Für (ORACLE-) Benutzer i.a. nü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 gehö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 verfügbaren DBMSe haben jeweils eigene
Strukturen. Ein komplettes Verzeichnis der ORACLE-Katalog-Relationen ist in der Katalog-Relation DTAB gespeichert.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-34
I Probleme mit Minimal-Syntax“:

 Keine Angaben zur Werteindeutigkeit ⇒ wird auf ( Unique“-) Index verlagert (siehe später)

 Primärschlüssel aus Definition nicht erkennbar.
 Keine DB-unterstützte Integritätsprüfung beim Einfügen; es sei denn über Unique Index (siehe
später).
I Erweiterte CREATE-TABLE-Syntax gemäß 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 Zusä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) unterstü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.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-35
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-36
3.3.1.1 Schlüssel- und Fremdschlüssel-Deklarationen

I Erweiterte SQL-DDL mit Primärschlüssel- (−→ PRIMARY KEY) und Fremdschlüssel-Angabe


(−→ REFERENCES).
I Ermö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)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-37
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))
...


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-38
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 gewählt werden:
Attributname Attributtyp PRIMARY KEY bzw.
Attributname Attributtyp UNIQUE
 PRIMARY KEY, UNIQUE und REFERENCES können sich auf mehrere Attribute (zusammen-
gesetzter Schlüssel) beziehen (siehe z.B. Relation TeileBestPos)
 Auch explizite Fremdschlüssel-Deklaration ist mö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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-39
I REFERENCES kann sich auch auf andere Attribute als den PRIMARY KEY einer Relation bezie-
hen.
 Attribut(wert) muss in ü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
. Überprüfung von Einfüge-, Lösch- und Änderungsoperationen auf Einhaltung der Referenz-
Bedingungen (z.B. keine Erzeugung von Waisenkindern“).

. Zurückweisung referenzverletzender Anweisungen.
. Keine automatische Anpassung abhängiger“ Werte.

15 Hier wird gefordert, dass für dieses Attribut bzw. die Attribut-Kombination eine UNIQUE-Spezifikation vorliegt.
16 mehr dazu später


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-40
3.3.2 Ändern einer Tabelle (Schemaä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 zusätzliche Spalte PREIS soll hinzugefügt

werden, die zwingend Werte enthalten soll.“
ALTER TABLE Teile ADD (Preis DECIMAL(8,2) NOT NULL)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-41
I Anmerkungen:
 Neue Spalten werden stets hinten angehängt.
 Sofern die Relation bereits Tupel enthält, werden die neuen Attribute mit Nullwerten gefüllt.
 NOT NULL-Klausel daher nur bei leeren Relationen möglich.
 Nachträgliche Änderungen von Attribut-Definitionen (Typ, Größe“, NULL-Klausel) bei leerer

Relation oder NULL-wertiger Spalte durch ALTER TABLE . . . MODIFY-Anweisung möglich.
 Löschen oder Umbenennen von Attributen ist nicht möglich.
 ORACLE erlaubt das Ä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
ändern:
. MODIFY Relation1 TO HASH
. MODIFY Relation2 TO BTREE
. MODIFY Relation3 TO ISAM
. MODIFY Relation4 TO HEAP17
. ...

17 HEAP ist die interne Standard-Repräsentation bei INGRES


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-42
3.3.3 Löschen einer Tabelle
I Syntax:
DROP TABLE Relationsname

I Wirkung: Lö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 später bei Transaktionsverwaltung


19 Der SQL-Standard überlässt es der jeweiligen Implementierung, ob DDL-Operationen mit DML-Operationen in einer
Transaktion gemischt werden können oder nicht bzw. ob diese stets zu implizitem COMMIT führen.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-43
3.3.4 Anlegen und Lö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 für vom Benutzer erzeugte Relationen müssen innerhalb eines Schemas eindeutig
sein.
 Mehrere Indexe pro Relation erlaubt.
 Indexe können von Anfang an (bei noch leerer Relation) oder nachträglich definiert werden.
 Bei nachträglicher Definition und UNIQUE-Klausel müssen die betroffenen Attributwerte (bzw.
Attributwert-Kombinationen) dieses Prädikat erfüllen.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-44
3.4 Datenmanipulation: Einfügen, Löschen und Ändern von Tupeln

3.4.1 Einfü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 gefüllt werden, so können diese explizit
aufgezählt werden. Die nicht spezifizierten Attribute werden mit Nullwerten gefüllt.
 Es können daher nur solche Attribute ausgeblendet werden, für die Nullwerte erlaubt sind.
 Die Einfügewerte können als Konstante mittels VALUES-Klausel oder über eine Query bereit-
gestellt werden.
 Anzahl und Typ der mittels VALUE-Klausel oder Query bereitgestellten Werte müssen mit den
implizit (keine Attributliste angegeben) oder explizit spezifizierten Attributen harmonieren.
 SQL-92 sieht vor, dass mehrere Tupelkonstante, durch Kommata getrennt, angegeben werden
können.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-45
Beispiele:
I1: Füge einen neuen Teilnehmer (TnNr 200) für Kurs ‘G08’ und AngNr 1 in die Gebühren-Relation

ein. Die Teilnamegebü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: Füge ein neues Kursangebot (AngNr 3) für ‘G08’ für den 15. März 1991 in ‘Ulm’ ein.“

INSERT INTO Angebot VALUES (3, ‘G08’, ‘15-03-1991’, ‘ULM’)
I3: Die Relation GEBUEHREN sei noch leer: Fülle die Attribute AngNr, KursNr und TnNr der

Relation mittels den Einträ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 gefüllt werden.“
INSERT INTO Kurs Statistik
SELECT a.AngNr, a.KursNr, a.Ort, COUNT(nt.TnNr)
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-46
3.4.2 Löschen von Tupeln
I Syntaktische Form:
DELETE
FROM Relationsname
[ WHERE Bedingung ]

I Anmerkung: Löscht alle Tupel [, für die die WHERE-Bedingung erfüllt ist,] aus der angegeben
Relation.

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



DELETE FROM Teilnehmer
Anmerkung: Es werden nur die Tupel gelöscht, die (leere) Relation selbst (als Eintrag im Katalog)
bleibt erhalten.
D2: Lösche in Nimmt Teil-Relation alle Einträge für Kurse, die vor dem 1. März 1990 stattgefunden

haben.“
DELETE
FROM Nimmt teil
WHERE (AngNr,KursNr) IN
( SELECT AngNr, KursNr
FROM Angebot
WHERE Datum <‘01-03-1990’)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-47
D3: Lösche alle Einträge aus der Nimm teil-Relation, für die es keinen korrespondierenden Eintrag

(TnNr) in der Teilnehmer-Relation gibt“.
DELETE
FROM Nimmt teil
WHERE TnNr NOT IN
( SELECT TnNr
FROM Teilnehmer)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-48
3.4.3 Ä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 Wertänderung wird für alle Tupel durchgeführt, für die die WHERE-
Bedingung erfüllt ist ( Snapshot-Logik“)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-49
U1: Erhöhe alle Kursgebühren (in der Relation GEBUEHREN) um 10%.“

UPDATE Gebuehren
SET Gebuehr = Gebuehr ∗ 1.1

U2: Wie U-1, aber nur fü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 Gebühren, für die noch kein Wert spezifiziert wurde, auf die Standardgebühr.“

UPDATE Gebuehren g
SET g.Gebuehr =
( SELECT s.Gebuehr
FROM Std Gebuehr s
WHERE g.KursNr = s.KursNr )
WHERE g.Gebuehr IS NULL


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-50
U4: Alle für ‘Ulm’ geplanten Kursangebote fallen aus. Setze AngNr für alle betroffenen Teilnehmer

in Nimmt teil auf NULL.“

UPDATE Nimmt teil


SET AngNr = NULL
WHERE (AngNr, KursNr) IN
(SELECT AngNr, KursNr
FROM Angebot
WHERE Ort = ‘Ulm’)

U5: TN STAMM(TnNr, Name, Ort, Strasse, Anmerkungen) enthalte fü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)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-51
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-Ausdrücke“ (sowie die Menge der zu ändernden Tupel)

muss (systemintern) vor dem ersten Update vorgenommen werden!


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-52
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 wählbar

20 Entsprechend dem SQL 92 Standard


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-53
I Wirkungsweise/Erläuterungen:
 Jeder Benutzer hat die volle Verfügungsgewalt (Lesen, Ändern, Löschen) ü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 beschränkt werden (z.B. auf lesenden Zugriff)
 Beschränkung des Lesezugriffs auf ausgewählte Attribute mittels VIEW-Mechanismus.
 Beschränkung des Änderungsrechts (UPDATE) auf ausgew ä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 Verfü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. später bei Datenschutz und Datensicherheit)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-54
3.6 Gewährleistung referentieller Integrität

I Die Abbildung von Informationen aus der Realwelt in die relationale Modellwelt erfordert i.a. mehrere
Relationen zur adäquaten Darstellung21
I Die logische Verknüpfung zwischen den Relationen erfolgt über Primar-/ Fremdschlüsselbeziehun-
gen
I Als Folge davon entstehen Schemata mit z.T. komplexen Abhä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: Primärschlüssel – Fremdschlüssel (FS) – Beziehungen


21 auf die Frage der Abbildung der Realwelt in die Datenbank-Modellwelt werden wir in einem späteren Kapitel zurückkommen.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-55
I Problem:
 Gewährleistung, dass alle Referenzbeziehungen stets konsistent sind.
. bei Insert / Delete: kein Entstehen von Waisenkindern“

. bei Update: konsistente Änderung aller Referenzen

I Möglichkeiten:
 passive Maßnahmen
☞ Zurückweisen konsistenzverletzender Operationen
. per geeigneter Sichten-Definition
. per DDL-Erweiterung
=⇒ Prüfklauseln
=⇒ Referenz-Beziehungen
 aktive Maßnahmen
☞ konsistente Propagation von Änderungen
. per DDL-Erweiterung
=⇒ Kaskadierung von Änderungen
. Trigger-Mechanismen


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-56
3.6.1 Passive Integritätssicherung
I Einfügen eines Tupels in äbhängigerTabelle:
=⇒ Prüfung, ob das Fremdschlüssel-Attribut“ in übergeordneter“ Tabelle existiert.
” ”
I Löschen eines Tupels in übergeordneter“ Tabelle:

=⇒ Prüfung, ob irgendwo noch abhängige“ Tupel existieren.

3.6.1.1 DEFINE VIEW . . . WITH CHECK OPTION

I Korrektheits-Prüfung von Änderungsoperationen mittels geeigneter VIEW-Definition.


I Beispiel 3-7: Es sollen nur solche Kursangebote in die ANGEBOT-Relation eingetragen werden

können, deren Kursnummer tatsächlich auch existiert (Referenz: Kurs-Relation).“

1. Versuch:
CREATE VIEW AngebotNeu
AS
SELECT *
FROM Angebot
WHERE KursNr IN
(SELECT KursNr
FROM Kurs)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-57
Test:
1. Einfügen zulässiges Tupel:
INSERT INTO AngebotNeu
VALUES (4,‘I09’, TO DATE(‘1-mar-91’), ‘Augsburg’) −→ OK
2. Einfügen nicht zulässiges Tupel:
INSERT INTO AngebotNeu
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-58
Test:
1. Einfügen zulässiges Tupel:
INSERT INTO AngebotNeu
VALUES (4,‘I09’, TO DATE(‘1-mar-91’), ‘Augsburg’) −→ OK
2. Einfügen nicht zulässiges Tupel:
INSERT INTO AngebotNeu
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 Absicherungsmöglichkeiten bzgl. Insert-Fehlern.
–m Stark eingeschränkte Tauglichkeit bzgl. Delete- und Update-Fehlern.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-59
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 eingefügt werden können, für die TeileNr und

LiefNr in den Relationen Teil“ bzw. Lieferant“ bereits definiert sind:
” ”

CREATE TABLE Liefert


(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)))


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-60
I Anmerkungen:
 Die CHECK-Bedingung kann eine beliebige Query mit Resultattyp boolean
(−→ TRUE/FALSE) sein.22
 Es werden später nur solche DML-Operationen ausgeführt, fü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 beschränkt. Diese Beschränkung ist
in SQL2 entfallen.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-61
Mögliche Probleme bei Änderungsoperationen:
. . . die Transaktion, nicht das einzelne Statement ist die Einheit der Integritätserhaltung (s. unten)

I Beispiel 3-9: Ä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: Fremdschlüssel-Beziehungen

I Durchführung dieser Ä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!


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-62
I Lö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:
 Integritäts-Prüfungen werden temporär ausgesetzt und erst nach
SET CONSTRAINTS . . . IMMEDIATE durchgeführt.
 Folgt auf DEFERRED“ keine IMMEDIATE“-Klausel, so werden die Integritäts-Prüfungen
” ”
automatisch bei COMMIT WORK durchgeführt.
 Das Transaktionskonzept fordert Konsistenzerhaltung bei Ä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: Führt bei Oracle V7 jeweils zu einem impliziten Commit!


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-63
3.6.2 Aktive Integritätssicherung

⇒ führt in einer allgemeinen Form auf sog. Aktive/Reaktive Datenbanken“, Trigger“.


” ”

3.6.2.1 ON DELETE / UPDATE CASCADE


I Automatische Propagation von Änderungen in die abhä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 längerem verfügbar (z.B. DB2/6000 V2).
Zusätzlich noch optionale Klausel für initiale Belegung hinsichtlich IMMEDIATE/DEFERRED bzw. NOT DEFERRABLE.
26 In Oracle V7 ist ON DELETE CASCADE verfügbar, . . . UPDATE jedoch noch nicht.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-64
I Beispiel 3-10: (für UPDATE)
CREATE TABLE Liefert
(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 fü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))


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-65
I Wirkung von ON DELETE CASCADE:
Löschen äbhängigerTupel, ggf. kaskadierend
Lieferant LiefNr LiefName
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-66
I Wirkung von ON UPDATE CASCADE:
=⇒ Propagation des geä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

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

Update LiefNr
Lieferant LiefNr LiefName
444 4447:
222 Maier & Co.
333 Müller GmbH
Update 4447 Schmidt KG

U p date U p date
444 4447 44 4 4447

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

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 Integrität
⊕ Konzept kann durch geeignete Datenstrukturen auch implementierungsseitig effizient un-
terstützt werden (=⇒ Performance!)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-67
3.7 Sichten

3.7.1 Einführung
Eine Sicht ist ein Ausschnitt“ aus der Datenbank (genauer: ein – möglicherweise umstrukturierter

– Teil des logischen DB-Schemas), der als externes Schema einem Benutzer/Anwendungsprogramm
zur Verfügung gestellt wird.
Eine Sicht ist eine zusä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“.

Ä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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-68
I Vorteile von Sichten:
 Vereinfachung von Anfragen (→ Vorformulierung komplexer Teilanfragen)
 Strukturierung der Datenbankbeschreibung nach individuellen“ Bedürfnissen

 stabile Schnittstelle für Anwendungen (→ bei Schemaänderungen)
 Datenschutz ( need-to-know“: Verbergen von nicht benötigten Daten)

I Beispiel:
 Relation: Gegeben sei die folgende Relation des logischen DB-Schemas mit Prüfungsdaten:

Prüf(Studienfach, Fach, Student, Prüfer, Datum, Note)

 Durch entsprechende Sichten können individuelle Informationsbedürfnisse befriedigt werden:


. Der Fachbereich Informatik und Informationswissenschaft sieht nur die Daten der eigenen“

Studenten.
. Das Prüfungsamt sieht alle Daten.
. Jeder Student darf seine eigenen Daten sehen (aber nicht ändern)
. Die Kommission zur Vergabe von Stipendien darf von Studenten die Durchschnittsnote
sehen.
. Der Dekan darf statistische Daten über Absolventen des letzten Jahrgangs lesen.
. Sekretariate dürfen Prüfungsdaten der zugehörigen Professoren einsehen.
I SQL-Syntax:
CREATE VIEW view-name AS query [ WITH CHECK OPTION ]


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-69
I Probleme mit Sichten:
 Bearbeitung von Anfragen auf Sichten: Substituiere definierende SQL-Anfrage für den Namen
der Sicht ( Query Substitution“)

 ⇒ Orthogonalität der Sprache besonders wichtig: SQL ⇔ Relationenalgebra
 Änderungsoperationen auf Sichten:
. Überhaupt zulässig? Eindeutigkeit? Welche Einschränkungen erforderlich?
. Wie sollen aus View-Updates die Updates der gespeicherten Datenbank hergeleitet werden?
. Welches sind vernünftige“ Update-Operationen?

I Kriterien für Änderungsoperationen:
 Effektkonformität: Änderungen, die auf einer Sicht formuliert werden, sollen nach der Änderung
der Basisdatenbank zu einer Ausprägung der Sicht führen, die dem entspricht, als ob diese
Änderung direkt auf der Sicht ausgeführt wurde (⇒ Korrektheit der Transformation).
 Minimalität: Die Basisdatenbank sollte nur minimal geändert werden, um den gewünschten
Effekt zu erzielen.
 Konsistenzerhaltung: Die Änderung einer Sicht darf zu keinen Integritätsverletzungen der Ba-
sisdatenbank führen.
 Respektierung des Datenschutz: Wird die Sicht aus Datenschutzgründen eingeführt, darf von
der Änderung nicht der bewusst ausgeblendete Teil der Basisdatenbank betroffen sein.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-70
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-71
I Probleme:
 Einfü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 Schlü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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-72
I Problem: Ein Tupel der Sicht kann durch eine Ä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!
Ü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 Änderung betroffen wäre, obwohl dieses nicht in der
Sicht MG liegt!

 Ist die Sicht MG aus Datenschutzgründen angelegt worden, sollte die Änderung zurü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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-73
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 Änderungstransformationen:
 oft nicht eindeutig!
 Minimalitä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 Änderungen denkbar:
(a) INSERT INTO AL VALUES (‘Info’, ‘Zuse’)
(b) UPDATE AL SET Abteilung=‘Info’ WHERE Leiter = ‘Zuse’
b) entspricht der Minimalitätsforderung, ist aber nicht effektkonform (die Mitarbeiter der
Abteilung Mathematik haben nun keinen Leiter mehr!).


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-74
I Analoge Probleme ergeben sich bei Löschungen. Etwa kann für die Löschung des Tupels
MGAL(‘Turing’, 30, ‘Info’, ‘Zuse’) entweder ein Tupel in MGA oder in AL oder in beiden Re-
lationen gelöscht werden.
 Konsequenz: Änderungsoperationen fü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 Änderung auf aggregierten Werten nicht sinnvoll:
I Beispiel 3-19:
UPDATE AS SET SummeGehalt = Summe + 1000
WHERE Abteilung = ‘Info’


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-75
I Klassifikation der Problembereiche:
 Vermeidung von Integritätsverletzungen
 Vermeidung von Seiteneffekten auf nichtsichtbaren Teile der Datenbank aus Datenschutz-
gründen
 Minimalität ggf. nicht eindeutig ⇒ Auswahlproblem
 Keine sinnvolle Transformation möglich
 1:1-Beziehung zwischen Sicht und Basisdatenbank kann verletzt sein (etwa beim Wegprojizieren
von Schlüsseln).


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-76
3.7.3 Integritätswahrung bei Sichten in SQL
I Integritätsverletzende Änderungen in Sichten werden zurückgewiesen.
I Die Behandlung potentiell datenschutzverletzender Sichtänderungen unterliegt der Benutzerkon-
trolle (⇒ ‘WITH CHECK OPTION’-Klausel).
I Sichten, die zu nicht eindeutigen Transformationen bei Änderungen führen können, werden als nicht
änderbar klassifiziert (unabhängig von einer speziellen Änderungsoperation). Auf diesen Sichten sind
keine Änderungen erlaubt.
I Elementare Änderungen auf Sichtebene müssen zu elementaren Änderungsoperationen der Basis-
relation abgebildet werden (⇒ DISTINCT-Klausel).
I Eine Sicht ist in SQL genau dann änderbar, wenn alle folgenden Bedingungen erfü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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-77
3.7.4 Auswertungsaspekte
I Grundidee bei der Ausfü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. Einschränkungen der Or-
thogonalität nicht möglich!
I Restriktionen von SQL:
 Einsetzungen von Unterabfragen im FROM-Teil seit SQL-92 möglich, aber (noch) nicht in
allen SQL-Dialekten (-Implementierungen); außerdem: View-Ersetzung auch schon vorher!
 Geschachtelte Aggregierungen nicht in einer SQL-Anfrage möglich.

I Konsequenz:
 In SQL kö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 aufgeführt.
. In der WHERE-Klausel erfolgt eine konjunktive Verknüpfung von Sicht- und
Anfragebedingungen.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-78
 Dies kann zu unerwarteten Problemen fü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
. Mögliche Übersetzungen:
 SELECT Abteilung
FROM MGA
WHERE SUM(Gehalt) > 500
GROUP BY Abteilung
 SELECT Abteilung
FROM MGA
GROUP BY Abteilung
HAVING SUM(Gehalt) > 500


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-79
Beispiel 3-21:
. Anfrage:
SELECT AVG(GehaltsSumme)
FROM DS
. Ü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 ausgeführt
werden.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-80
3.8 Nullwerte in SQL
I SQL unterstützt einen speziellen Wert NULL für alle Domänen.
I Dieser hat die Bedeutung Wert nicht bekannt“ und ist verschieden von dem numerischen Wert

0 und einer Zeichenkette der Lä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 Ausdrücken: Wenn einer oder beide Operanden nullwertig sind, ist das
Ergebnis NULL.
 In booleschen Ausdrü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.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-81
 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 155 ← Nullwert
1 I09 171 ← Nullwert
1 I09 173 400.00
2 P13 177 ← Nullwert
1 I09 185 450.00
2 I09 187 ← Nullwert
1 P13 194 ← Nullwert

⇒ In der Literatur werden Nullwerte oftmals durch verschiedene Sonderzeichen, z.B. ω, ⊥


dargestellt. Hier verwenden wir einfach eine Leerstelle.
. Darü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“.
” ”


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-82
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-83
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.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-84
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-85
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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-86
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 ??


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-87
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 für ein Tupel ri ∈ val(R) kein S-Tupel,
das F erfüllt, so werden die S-Attribute im Ergebnis-Tupel mit Nullwerten aufgefüllt.
Achtung: @ F und @ F sind nicht kommutativ!
I Formen des Outer Join (gemäß SQL 2):
 Left Outer Join: Stellt sicher, dass alle Zeilen der linken Tabelle im Ergebnis enthalten
sind (siehe unten)
 Right Outer Join: Analog, jedoch ü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 aufgefüllt)


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-88
I Beispiel 3-22:
R A B S C D
1 Hans 2 Mü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 Mü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
P13 C-Programmierung G08
P13 C-Programmierung G10

27 Wie in SQL 2 spezifiziert


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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-89
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 aufgefüllt wird!
 In einer Outer-Join-Anweisung darf (bei ORACLE) höchstens eine Tabelle ohne ”(+)” auftre-
ten.
 Wird der Outer Join über mehr als ein Attribut (z.B. bei zusammengesetztem Schlüssel)
spezifiziert, so muss ”(+)” fü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))


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-90
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
FROM Angebot a, Nimmt teil nt
WHERE a.KursNr = nt.KursNr (+) AND
a.AngNr = nt.AngNr (+)
AngNr KursNr Datum Ort TnNr
1 G08 13–01–1996 München 145
2 G08 24–02–1996 Bremen 143
1 G10 01–02–1996 Mü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 Mü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


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-91
N7. Wie S4, aber zusä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
WHERE a.KursNr = nt.KursNr (+) AND
a.AngNr = nt.AngNr (+) AND
nt.TnNr = t.TnNr (+)

N8. Gib alle Kursangebote aus, für die sich kein Teilnehmer angemeldet hat“.

SELECT a.*, nt.TnNr ORACLE
FROM Angebot a, Nimmt teil nt
WHERE a.KursNr = nt.KursNr (+) AND
a.AngNr = nt.AngNr (+) AND
nt.TnNr IS NULL
I Anmerkungen:
 Die obige SQL-Anfrageformulierung mittels Outer Join ist eine von mehreren Möglichkeiten,
Anfrage S9 in SQL umzusetzen.
 Der Test auf Nullwert muss mittels IS NULL bzw. IS NOT NULL durchgeführt werden.
= NULL“ bzw. <> NULL“ führen nicht zum gewünschten Ergebnis.
” ”
 Tests mittels IS [NOT] NULL sind auch ohne Outer Joins in Selektionen möglich.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-92
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.


c M. Scholl, 2003/04 – Informationssysteme: 3. SQL – Structured Query Language 3-93