Datenmodelle, Datenbanksprachen und Datenbank - Oldenbourg ...

Gottfried Vossen 

Datenmodelle, 

Datenbanksprachen 

und Datenbankmanagementsysteme 

5. Auflage 

Oldenbourg

Datenmodelle, 

Datenbanksprachen 

und Datenbankmanagementsysteme 

von 

Prof. Dr. Gottfried Vossen 

5. überarbeitete und erweiterte Auflage 

Oldenbourg Verlag München Wien 

Gottfried Vossen, Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. 

ISBN 978-3-486-27574-2. Oldenbourg Wissenschaftsverlag München 2008.

Inhaltsverzeichnis 

Auszug ... xiv 

... aus dem Vorwort zur ersten Auflage xiv 

... aus dem Vorwort zur zweiten Auflage xv 

... aus dem Vorwort zur dritten Auflage xvi 

Vorwort zur fünften Auflage xix 

I Einführung 1 

1 Motivationen, Historisches, Abgrenzungen 3 

1.1 Daten-intensive Anwendungen und deren Anforderungen . . . . . . . . 3 

1.2 Datenbanken und Informationssysteme . . . . . . . . . . . . . . . . . . 6 

1.3 Entwicklung von Datenbanksystemen und Datenmodellen . . . . . . . 7 

1.3.1 Filesysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

1.3.2 Generische Sicht eines Datenbanksystems . . . . . . . . . . . . 10 

1.3.3 Netzwerk- und hierarchische Datenbanken . . . . . . . . . . . . 12 

1.3.4 Relationale Datenbanken . . . . . . . . . . . . . . . . . . . . . 15 

1.3.5 Objektrelationale Datenbanken . . . . . . . . . . . . . . . . . . 18 

1.3.6 XML-Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . 21 

1.4 Bibliographische Hinweise und Ergänzungen . . . . . . . . . . . . . . . 22 

1.5 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2 Aufbau von Datenbanken und Datenbanksystemen 25 

2.1 Datenunabhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.2 Die ANSI/SPARC-Schemaebenen . . . . . . . . . . . . . . . . . . . . . 26 

2.3 Sprachebenen und -klassen . . . . . . . . . . . . . . . . . . . . . . . . 29 

2.4 Ein Schichtenmodell für Datenbanksysteme . . . . . . . . . . . . . . . 32 

2.5 Bibliographische Hinweise, Ergänzungen, Querbezüge . . . . . . . . . . 39 

2.6 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 



vi Inhalt 

II Klassische Konzepte: 

ER- und relationales Datenmodell. SQL 43 

3 Datenbank-Entwurf mit dem Entity-Relationship-Modell 45 

3.1 Der Datenbank-Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . 46 

3.2 Aspekte der Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . 49 

3.2.1 Qualitätskriterien für den Datenbankentwurf . . . . . . . . . . 49 

3.2.2 Die Grundzüge ordnungsmäßiger Modellierung . . . . . . . . . 51 

3.3 Phasen des Entwurfsprozesses . . . . . . . . . . . . . . . . . . . . . . . 52 

3.3.1 Anforderungsanalyse und -spezifikation . . . . . . . . . . . . . 54 

3.3.2 Konzeptioneller Entwurf . . . . . . . . . . . . . . . . . . . . . . 55 

3.3.3 Logischer Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . 57 

3.3.4 Physischer Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . 57 

3.3.5 Weitere Entwurfsschritte . . . . . . . . . . . . . . . . . . . . . . 58 

3.4 Allgemeine Abstraktionskonzepte . . . . . . . . . . . . . . . . . . . . . 59 

3.5 Das Entity-Relationship-Modell . . . . . . . . . . . . . . . . . . . . . . 60 

3.5.1 Entities und Attribute . . . . . . . . . . . . . . . . . . . . . . . 61 

3.5.2 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

3.5.3 IS-A-Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . 75 

3.5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 80 

3.6 Konzeptioneller Entwurf mit dem ER-Modell . . . . . . . . . . . . . . 81 


3.8 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 

4 Das relationale Datenmodell 95 

4.1 Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

4.2 Datenabhängigkeiten. Relationenschemata . . . . . . . . . . . . . . . . 98 

4.3 Transformation eines ER-Diagramms in das Relationenmodell . . . . . 104 

4.4 Datenbank-Definition mit SQL . . . . . . . . . . . . . . . . . . . . . . 109 

4.4.1 Datenbankschema-Definition . . . . . . . . . . . . . . . . . . . 110 

4.4.2 Tabellen-Definition . . . . . . . . . . . . . . . . . . . . . . . . . 111 

4.4.3 Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . . . . 112 

4.4.4 Weitere Definitionsaspekte . . . . . . . . . . . . . . . . . . . . 114 

4.5 Fallstudie Medienhandel . . . . . . . . . . . . . . . . . . . . . . . . . . 116 


4.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 

5 Grundlagen von SQL 127 

5.1 SQL von 1980 bis 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

5.2 Datenbank-Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

5.3 Datenbank-Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 

5.3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 

5.3.2 Zur Syntax von SELECT . . . . . . . . . . . . . . . . . . . . . . 131 

5.3.3 Exkurs in die Relationenalgebra . . . . . . . . . . . . . . . . . 134 

5.3.4 Semantik von SELECT am Beispiel von RA-Ausdrücken . . . . . 135 

5.3.5 Verbund-Operatoren in SQL . . . . . . . . . . . . . . . . . . . 137 

5.4 Beispiele für SQL-Anfragen . . . . . . . . . . . . . . . . . . . . . . . . 140 

5.4.1 Selektionen und Projektionen . . . . . . . . . . . . . . . . . . . 141 



Inhalt vii 

5.4.2 Verbundanfragen . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

5.4.3 Aggregatfunktionen und Unteranfragen . . . . . . . . . . . . . 144 

5.4.4 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . 146 

5.5 Rekursive Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 


5.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

5.8 Anhang: Beispieltabellen der Fallstudie Medienhandel . . . . . . . . . 153 

6 Integrität in relationalen Datenbanken 161 

6.1 Arten von Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . . 161 

6.2 Funktionale Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . 165 

6.2.1 Definition. Implikation . . . . . . . . . . . . . . . . . . . . . . . 166 

6.2.2 Ableitung. Das Membership-Problem . . . . . . . . . . . . . . . 169 

6.2.3 Anwendungen des Membership-Algorithmus. Schlüssel . . . . . 175 

6.2.4 (Abhängigkeits-) Basen . . . . . . . . . . . . . . . . . . . . . . 178 

6.2.5 Allgemeine Implikation . . . . . . . . . . . . . . . . . . . . . . 181 

6.3 Inklusionsabhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

6.4 Allgemeine Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 

6.5 Aktive Integritätskontrolle über Trigger . . . . . . . . . . . . . . . . . 188 

6.6 Bibliographische Hinweise, Ergänzungen, Querbezüge . . . . . . . . . . 193 

6.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

7 Relationale Sprachen: Relationenalgebra, Kalküle, Datalog 201 

7.1 Die Relationenalgebra . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 

7.1.1 Relationale Operationen und ihre Rechenregeln . . . . . . . . . 202 

7.1.2 Ausdrücke der Relationenalgebra . . . . . . . . . . . . . . . . . 208 

7.1.3 Eigenschaften der Relationenalgebra . . . . . . . . . . . . . . . 210 

7.1.4 Algebraische Optimierung . . . . . . . . . . . . . . . . . . . . . 212 

7.2 Relationenkalküle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 

7.2.1 Der Relationen-Tupelkalkül . . . . . . . . . . . . . . . . . . . . 215 

7.2.2 Der Relationen-Domainkalkül . . . . . . . . . . . . . . . . . . . 220 

7.3 View-Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 

7.4 Grundlagen von Datalog . . . . . . . . . . . . . . . . . . . . . . . . . . 226 

7.4.1 Motivationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 

7.4.2 Logik als Anfragesprache . . . . . . . . . . . . . . . . . . . . . 228 

7.4.3 Intensionale und extensionale Datenbanken . . . . . . . . . . . 229 

7.4.4 Rekursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

7.4.5 Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . . . . 232 

7.4.6 Datalog-Programme und deren Interpretation . . . . . . . . . . 232 

7.4.7 Ausdruckskraft von Datalog . . . . . . . . . . . . . . . . . . . . 235 

7.5 Konzepte der Theorie von Anfragesprachen . . . . . . . . . . . . . . . 236 

7.5.1 Konjunktive Anfragen . . . . . . . . . . . . . . . . . . . . . . . 236 

7.5.2 Vollständigkeit von Anfragesprachen . . . . . . . . . . . . . . . 237 

7.5.3 Ausdruckskraft und Komplexität von Anfragesprachen . . . . . 239 


7.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 



viii Inhalt 

8 Qualitätsorientierter Datenbankentwurf 251 

8.1 Universalrelationen und Update-Anomalien . . . . . . . . . . . . . . . 251 

8.2 Zweite, dritte und Boyce-Codd-Normalform . . . . . . . . . . . . . . . 253 

8.3 Dekomposition und Synthese . . . . . . . . . . . . . . . . . . . . . . . 259 

8.4 Mehrwertige und Verbund-Abhängigkeiten . . . . . . . . . . . . . . . . 269 

8.5 Vierte und fünfte Normalform . . . . . . . . . . . . . . . . . . . . . . . 273 


8.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 

III Moderne Konzepte: 

Objekt-Basierung und XML-Dokumente 279 

9 Objekt-relationale Datenbanken 281 

9.1 Evolution von Datenmodellen . . . . . . . . . . . . . . . . . . . . . . . 282 

9.1.1 Grenzen relationaler Datenmodelle . . . . . . . . . . . . . . . . 282 

9.1.2 Höhere Datenmodelle . . . . . . . . . . . . . . . . . . . . . . . 283 

9.1.3 Daten-, Funktions- und Prozessentwurf . . . . . . . . . . . . . 285 

9.2 Objekt-Orientierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 

9.2.1 Das Paradigma . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 

9.2.2 Objekt-Orientierung und Datenbanken . . . . . . . . . . . . . . 292 

9.2.3 Unterscheidung von Typen und Klassen . . . . . . . . . . . . . 295 

9.2.4 Objekt-Orientierung im relationalen Datenmodell . . . . . . . . 299 

9.3 Datenbankmodellierung mit der UML . . . . . . . . . . . . . . . . . . 301 

9.3.1 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

9.3.2 Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

9.3.3 Aggregationen und Kompositionen . . . . . . . . . . . . . . . . 305 

9.3.4 Generalisierung und Spezialisierung . . . . . . . . . . . . . . . 305 

9.3.5 Weitere Modellierungsmöglichkeiten . . . . . . . . . . . . . . . 306 

9.3.6 Fallstudie Medienhandel . . . . . . . . . . . . . . . . . . . . . . 307 

9.4 Objekt-relationale Definitionskonzepte in SQL . . . . . . . . . . . . . . 310 

9.4.1 Basisdatentypen und Typkonstruktoren . . . . . . . . . . . . . 310 

9.4.2 Benutzerdefinierte Typen und Typhierarchien . . . . . . . . . . 312 

9.4.3 Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 

9.5 Fallstudie Medienhandel . . . . . . . . . . . . . . . . . . . . . . . . . . 317 

9.6 SQL-Anfragen an objekt-relationale Datenbanken . . . . . . . . . . . . 321 


9.8 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 

9.9 Anhang: Beispieltabellen der Fallstudie Medienhandel . . . . . . . . . 330 

10 Einführung in XML 337 

10.1 Elemente, Tags und Attribute . . . . . . . . . . . . . . . . . . . . . . . 338 

10.2 Validierung von XML-Dokumenten: DTDs und XML Schema . . . . . 345 

10.3 Normalisierungsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 349 

10.4 Verarbeitung von XML-Dokumenten . . . . . . . . . . . . . . . . . . . 351 

10.4.1 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 

10.4.2 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 




Inhalt ix 

10.6 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 

10.7 Anhang: XML-Spezifikationen für die Fallstudie Medienhandel . . . . 365 

10.7.1 Document Type Definition . . . . . . . . . . . . . . . . . . . . 365 

10.7.2 XML Schema Definition . . . . . . . . . . . . . . . . . . . . . . 367 

11 SQL und Programmiersprachen 375 

11.1 Web-Anbindung von Datenbanken . . . . . . . . . . . . . . . . . . . . 376 

11.1.1 Grundlegendes . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 

11.1.2 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 

11.1.3 MySQL-Anbindung per PHP . . . . . . . . . . . . . . . . . . . 380 

11.2 Eingebettetes SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 

11.2.1 Arten der Einbettung . . . . . . . . . . . . . . . . . . . . . . . 386 

11.2.2 JDBC und SQLJ . . . . . . . . . . . . . . . . . . . . . . . . . . 388 


11.4 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 

12 XQuery und SQL/XML 397 

12.1 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 

12.1.1 Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 

12.1.2 FLWOR-Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . 400 

12.1.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 

12.1.4 Update-Operationen . . . . . . . . . . . . . . . . . . . . . . . . 408 

12.2 SQL/XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 

12.2.1 XML-Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . 411 

12.2.2 Publikations-Funktionen . . . . . . . . . . . . . . . . . . . . . . 413 

12.2.3 XQuery-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 416 

12.3 SQL/XML-Unterstüzung in IBM DB2 V9 . . . . . . . . . . . . . . . . 418 

12.3.1 Speicherung von XML-Dateien . . . . . . . . . . . . . . . . . . 420 

12.3.2 Anfragen mit SQL/XML . . . . . . . . . . . . . . . . . . . . . 422 

12.3.3 Anfragen mit XQuery . . . . . . . . . . . . . . . . . . . . . . . 424 

12.3.4 Generierung von XML- oder HTML-Strukturen . . . . . . . . . 424 


12.5 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 

IV Datenintegration und ihre Anwendungen 435 

13 Architekturkonzepte für Datenbanksysteme 437 

13.1 Das Client/Server-Konzept . . . . . . . . . . . . . . . . . . . . . . . . 438 

13.1.1 Anfrageserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

13.1.2 Objekt- und Seitenserver . . . . . . . . . . . . . . . . . . . . . 442 

13.2 Verteilte Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . 444 

13.2.1 Vor- und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . 444 

13.2.2 Klassifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 

13.2.3 Homogene Verteilung . . . . . . . . . . . . . . . . . . . . . . . 448 

13.2.4 Heterogene Verteilung und Föderation . . . . . . . . . . . . . . 451 

13.3 Parallele Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . 454 




x Inhalt 

13.5 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 

14 Datenintegration 461 

14.1 Einführung. Architekturkonzepte . . . . . . . . . . . . . . . . . . . . . 461 

14.2 Übersetzer, Integratoren und Koordinatoren . . . . . . . . . . . . . . . 463 

14.3 Integration mittels logischer Sichten . . . . . . . . . . . . . . . . . . . 467 

14.4 Verteilte Objekte und Web Services . . . . . . . . . . . . . . . . . . . 473 


14.6 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 

15 Data Warehouses (Datenlager) und OLAP 479 

15.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 

15.1.1 Anwendungen und Architektur von Datenlagern . . . . . . . . 481 

15.1.2 Der ETL-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . 484 

15.1.3 Daten-Bereinigung zur Erzielung von Datenqualität . . . . . . 485 

15.2 Mehrdimensionale Datenmodelle . . . . . . . . . . . . . . . . . . . . . 486 

15.2.1 Fakten, Maße und Dimensionen . . . . . . . . . . . . . . . . . . 486 

15.2.2 Sternschemata und Varianten . . . . . . . . . . . . . . . . . . . 488 

15.2.3 Effiziente Speicherung von Faktentabellen mittels Bitmaps . . . 490 

15.3 Qualitätsorientierter Schemaentwurf für Datenlager . . . . . . . . . . . 493 

15.3.1 Der Entwurfsprozess . . . . . . . . . . . . . . . . . . . . . . . . 494 

15.3.2 Qualitätskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . 497 

15.3.3 Summierbarkeit und Normalformen . . . . . . . . . . . . . . . 497 

15.3.4 Selbstwartbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 499 

15.4 Grundlagen des OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 

15.4.1 Datenwürfel und OLAP-Operatoren . . . . . . . . . . . . . . . 503 

15.4.2 Von Vereinigungs- zu Würfel-Anfragen . . . . . . . . . . . . . . 506 

15.4.3 SQL Roll-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 

15.4.4 SQL Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 

15.4.5 SQL Grouping Sets . . . . . . . . . . . . . . . . . . . . . . . . . 516 


15.6 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 

16 Grundlagen des Data Mining 523 

16.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 

16.2 Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 

16.3 Cluster-Bildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 

16.4 Assoziationsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 

16.4.1 Häufige Mengen und Assoziationsregeln . . . . . . . . . . . . . 532 

16.4.2 Der Apriori-Algorithmus . . . . . . . . . . . . . . . . . . . . . . 535 

16.4.3 Verbesserungspotenziale beim Apriori-Algorithmus . . . . . . . 537 

16.4.4 Alternativen zum Apriori-Algorithmus . . . . . . . . . . . . . . 539 

16.4.5 Interessantheitsmaße . . . . . . . . . . . . . . . . . . . . . . . . 543 

16.5 Sequenzanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 

16.6 Web-Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 

16.6.1 Web-Struktur-Mining . . . . . . . . . . . . . . . . . . . . . . . 548 

16.6.2 Web-Inhalts-Mining . . . . . . . . . . . . . . . . . . . . . . . . 551 

16.6.3 Web-Log-Mining . . . . . . . . . . . . . . . . . . . . . . . . . . 551 



Inhalt xi 


16.8 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 

V Datenbanksystemtechnik 555 

17 Interne Datenbank- und Speicherorganisation 557 

17.1 Plattenspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 

17.1.1 Blöcke und Blockzugriffe . . . . . . . . . . . . . . . . . . . . . . 559 

17.1.2 RAID-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . 560 

17.2 Pufferverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 

17.3 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 

17.3.1 Sequentielle Files . . . . . . . . . . . . . . . . . . . . . . . . . . 565 

17.3.2 Effizienter Filezugriff durch Indexierung . . . . . . . . . . . . . 567 

17.4 Spezielle Indexstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . 568 

17.4.1 ISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 

17.4.2 Baumstrukturen für eindimensionale Punktdaten . . . . . . . . 569 

17.4.3 Baumstrukturen für mehrdimensionale Punktdaten . . . . . . . 575 

17.4.4 Hash-Organisationsformen . . . . . . . . . . . . . . . . . . . . . 581 

17.5 Beispiel: Speicherorganisation bei DB2 . . . . . . . . . . . . . . . . . . 584 

17.6 Speicherung und Indexierung von XML-Dokumenten . . . . . . . . . . 587 

17.6.1 Speicherungsoptionen . . . . . . . . . . . . . . . . . . . . . . . 587 

17.6.2 Indexierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588 


17.8 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 

18 Verarbeitung und Optimierung von Anfragen 597 

18.1 Anfrageverarbeitung im Überblick . . . . . . . . . . . . . . . . . . . . 598 

18.2 Anfrage-Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 

18.2.1 Ziele und Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . 600 

18.2.2 High-Level-Optimierung . . . . . . . . . . . . . . . . . . . . . . 601 

18.2.3 Low-Level-Optimierung . . . . . . . . . . . . . . . . . . . . . . 606 

18.3 Implementierungstechniken für den Verbund . . . . . . . . . . . . . . . 607 

18.3.1 Nested-Loop-Join . . . . . . . . . . . . . . . . . . . . . . . . . . 608 

18.3.2 Sort-Merge-Join . . . . . . . . . . . . . . . . . . . . . . . . . . 608 

18.3.3 Hash-Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609 

18.4 Spezielle QEP-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 612 

18.5 Anfrage-Prozessoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615 


18.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618 

19 Physischer Datenbankentwurf und Tuning 621 

19.1 Grundlagen des physischen Datenbankentwurfs . . . . . . . . . . . . . 621 

19.2 Fragmentierung und Replikation bei Datenverteilung . . . . . . . . . . 624 

19.3 Datenbank-Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 

19.3.1 Grundlegende Prinzipien . . . . . . . . . . . . . . . . . . . . . . 627 

19.3.2 Tuning von Indexen . . . . . . . . . . . . . . . . . . . . . . . . 629 

19.3.3 Tuning in relationalen Systemen . . . . . . . . . . . . . . . . . 629 



xii Inhalt 

19.4 Datenbank-Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . 630 


19.6 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634 

20 Transaktionen und Serialisierbarkeit 637 

20.1 Das Transaktionskonzept . . . . . . . . . . . . . . . . . . . . . . . . . 638 

20.2 Beispiele für Synchronisationsprobleme . . . . . . . . . . . . . . . . . . 641 

20.3 Das ACID-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 

20.4 Das Read-Write-Modell für Transaktionen . . . . . . . . . . . . . . . . 644 

20.5 Serialisierbarkeit von Schedules . . . . . . . . . . . . . . . . . . . . . . 647 

20.5.1 Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647 

20.5.2 View-Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . 651 

20.5.3 Konflikt-Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . 652 

20.5.4 Commit-Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . 657 

20.6 Fehlersicherheit von Schedules . . . . . . . . . . . . . . . . . . . . . . . 659 

20.6.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659 

20.6.2 Rücksetzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 660 

20.6.3 Vermeidung kaskadierender Aborts . . . . . . . . . . . . . . . . 661 

20.6.4 Striktheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 

20.7 Korrektheit von Schedules . . . . . . . . . . . . . . . . . . . . . . . . . 663 


20.9 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664 

21 Concurrency Control 667 

21.1 Überlegungen zum Scheduler-Entwurf . . . . . . . . . . . . . . . . . . 667 

21.2 Sperrende Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670 

21.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670 

21.2.2 Das 2-Phasen-Sperrprotokoll . . . . . . . . . . . . . . . . . . . 672 

21.2.3 Varianten des 2-Phasen-Sperrprotokolls . . . . . . . . . . . . . 677 

21.2.4 Das MGL-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . 679 

21.2.5 Das TL-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . 682 

21.2.6 Tuning in Gegenwart sperrender Scheduler . . . . . . . . . . . 684 

21.3 Nicht sperrendes Timestamp-Ordering . . . . . . . . . . . . . . . . . . 689 

21.4 Concurrency Control auf höherer Abstraktionsebene . . . . . . . . . . 690 


21.6 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695 

22 Grundlagen der Crash Recovery 697 

22.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 

22.2 Organisation eines Data-Managers . . . . . . . . . . . . . . . . . . . . 699 

22.3 Der Recovery-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 

22.4 Ein Undo/Redo-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . 705 

22.5 Alternativen zum Undo/Redo-Protokoll . . . . . . . . . . . . . . . . . 707 

22.6 Recovery-Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708 

22.7 Bibliographische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . 709 

22.8 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709 



Inhalt xiii 

23 Verteilte Transaktionsverarbeitung 711 

23.1 Homogene Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711 

23.1.1 Verteilte Transaktionen und Schedules . . . . . . . . . . . . . . 711 

23.1.2 Verteiltes Concurrency Control . . . . . . . . . . . . . . . . . . 715 

23.1.3 Verteilte Recovery-Protokolle . . . . . . . . . . . . . . . . . . . 720 

23.1.4 Transaktionen auf replikativen Datenbanken . . . . . . . . . . . 728 

23.2 Heterogene Verteilung. System-Föderationen . . . . . . . . . . . . . . 733 

23.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734 

23.2.2 Ein MDBS-Modell . . . . . . . . . . . . . . . . . . . . . . . . . 734 

23.2.3 Transaktionen und Schedules in einem MDBS . . . . . . . . . . 736 

23.2.4 Globale Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . 739 

23.2.5 Gewährleistung globaler Serialisierbarkeit . . . . . . . . . . . . 742 

23.3 Bibliographische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . 745 

23.4 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746 

VI Neuere Entwicklungen 749 

24 Ausblicke 751 

24.1 Temporale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . 751 

24.2 Probabilistische Datenbanken . . . . . . . . . . . . . . . . . . . . . . . 755 

24.3 Räumliche Daten und GIS . . . . . . . . . . . . . . . . . . . . . . . . . 757 

24.4 Datenströme (Data Streams) . . . . . . . . . . . . . . . . . . . . . . . 760 

24.5 Data Provenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762 

24.6 Column Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764 


Literaturverzeichnis 767 

Index 808 



Kapitel 5 

Grundlagen von SQL 

In diesem Kapitel behandeln wir einführend Datenbank-Updates und -Anfragen mit 

der relationalen Datenbanksprache SQL, auf deren Datendefinitionsmöglichkeiten wir 

einführend bereits im vorigen Kapitel eingegangen sind. Im Unterschied zu den später 

behandelten formaleren Sprachen für das Relationenmodell (insbesondere Relationenalgebra 

und Relationenkalküle) handelt es sich bei SQL um eine Sprache, welche von 

vielen DBMS-Entwicklern implementiert und bereits vor längerer Zeit standardisiert 

wurde, so dass sie in kommerziell verfügbaren sowie in Open-Source-DBMS heute 

durchgehend verwendet wird. Es sei bereits vorab darauf hingewiesen, dass unsere 

Darstellung keinen Anspruch auf Vollständigkeit erhebt, allerdings um eine Auswahl 

des Sprachstandards bemüht ist, welche dem Leser einen tieferen Einstieg in dieses 

Thema leicht machen sollte. 

5.1 SQL von 1980 bis 2003 

Die Entwicklung der Sprache SQL wurde zunächst ausschließlich von IBM betrieben 

und bereits zu Beginn der 70er Jahre (im Rahmen des System/R-Projekts) begonnen, 

nachdem die strategische Bedeutung des relationalen Modells für Datenbanksysteme 

erkannt worden war. SQL war zu dieser Zeit ein Akronym für Structured English 

Query Language oder kurz SEQUEL. Das ab 1981 kommerziell verfügbare System 

SQL/Data System von IBM war das erste System, welches diese Sprache ” öffentlich“ 

bereitstellte; von IBM wurde SQL in der Folgezeit für alle anderen Datenbanksysteme 

(z.B. DB2 und QMF) übernommen. 

Zu Beginn der 80er Jahre erkannte zunächst das American National Standards 

Institute (ANSI) die Bedeutung von SQL und begann mit einer Standardisierung dieser 

Sprache. 1986 wurde der erste Standard unter dem Namen SQL1 bzw. SQL86 von 

der International Standards Organization (ISO) verabschiedet. Erste Ergänzungen 

erschienen 1989 im so genannten Addendum-1; der ab dieser Zeit gültige Standard ist 

auch unter der Bezeichnung SQL89 bekannt. Weitere Ergänzungen und Modifikationen 

wurden 1992 im Rahmen von SQL2 bzw. SQL92 festgeschrieben. 1995 wurde das 

Call-Level Interface (SQL/CLI) hinzugefügt; technische Korrekturen am Standard 

wurden 1994 und 1996 vorgenommen. Weitere Ergänzungen (insbesondere Persistent 

Stored Modules, kurz SQL/PSM) erfolgen etwas später. 



128 Teil II: Klassische Konzepte: ER- und relationales Datenmodell. SQL 

Das Akronym SQL steht heute für Standard Query Language. Ähnlich wie 

bei vergleichbaren Entwicklungen im Bereich von Programmiersprachen (etwa Fortran) 

ist dieser Sprachstandard weiter gehender Entwicklung unterworfen; derzeit am 

häufigsten verwendet werden SQL:1999, welches erstmals objekt-relationale Datenbank-Konzepte 

enthielt, und SQL:2003, mit welchem XML Einzug in die relationale 

Welt gehalten hat. Kritisch ist bereits an dieser Stelle anzumerken, dass die Standardisierung 

von SQL de facto zu spät begonnen wurde, so dass praktisch kein relationales 

System den Standard in ” Reinform“ realisiert. Neben der zeitlichen Differenz zwischen 

der Verabschiedung des Standards und dem Verfügbarwerden relationaler Produkte 

liegt dies z.B. daran, dass SQL2 gegenüber SQL1 nicht nur eine Erweiterung darstellt, 

sondern es wurden auch Konzepte (wie z.B. die Möglichkeit des Einrichtens 

bzw. Löschens von Indexen) wieder entfernt; in einigen Implementierungen wurden 

diese jedoch beibehalten. Die Spezifikation von SQL:1999 wurde ebenfalls mehrfach 

geändert. Andererseits sind die im Einzelfall vorliegenden Abweichungen vom Standard 

teilweise implementierungsabhängig und daher für unsere Betrachtungen unerheblich. 

Nachdem wir im letzten Kapitel bereits SQL-Funktionalität im Hinblick auf die 

Deklaration relationaler Datenbanken betrachtet haben, wollen wir in den folgenden 

Abschnitten die zentrale Funktionalität von SQL im Hinblick auf die Manipulation 

relationaler Datenbanken beschreiben; hierbei stützen wir uns auf den Standard, ohne 

dies jeweils gesondert zu erwähnen. Abweichungen gehen im Einzelfall aus den jeweiligen 

Herstellerunterlagen hervor. Der SQL-Standard bezieht sich generell auf drei 

Ebenen: 

• Die Ebene der DDL 

(mit Kommandos wie create table oder drop table), 

• die Ebene der DML 

(mit Kommandos wie select, insert, delete oder update), 

• die Ebene der Programmiersprachen-Einbettung und -Anbindung 

(mit Kommandos wie declare cursor, open, fetch oder close). 

Von diesen Ebenen betrachten wir hier die mittlere der DML, wobei wir bei auf 

Weiteres eine interaktive Benutzung der Sprache unterstellen. Hinsichtlich der Syntax- 

Darstellung gelten die bereits in Kapitel 4 genannten Konventionen. 

5.2 Datenbank-Updates 

Nach Einrichtung von Basistabellen wird man zunächst Daten in diese Tabellen eintragen 

wollen; dazu steht das INSERT-Kommando zur Verfügung, welches in der einfachsten 

Form folgende Gestalt hat: 

INSERT INTO table-name 

[ ( list-of-column-names ) ] 

VALUES ( data-items ) 

Über dieses Kommando wird ein (neues) Tupel in eine Basistabelle eingefügt. Die 

Werte dieses Tupels werden als ” data-items“ durch Kommata getrennt. Falls nur für 




bestimmte, aber nicht für alle Attribute neue Werte eingetragen werden sollen, so 

sind die betreffenden Spalten explizit anzugeben; in den nicht angegebenen Spalten 

wird das Tupel vom System mit Null- oder gegebenenfalls Default-Werten aufgefüllt. 

Zur Illustration Möglichkeiten von SQL, Anfragen und Updates zu formulieren, 

verwenden wir auch in diesem Kapitel die aus den Kapiteln 3 und 4 bekannte 

Datenbank des Medienhändlers, wobei wir unterstellen, dass diese über die im letzten 

Kapitel angegebenen CREATE TABLE-Kommandos bereits angelegt wurde. 

Durch ein CREATE TABLE-Kommando wird eine (noch leere) Tabelle des betreffenden 

Namens angelegt, mit welcher man sofort arbeiten kann; SQL-Implementierungen 

kennen also keine spezielle ” Definitionsphase“ einer Datenbank. DDL- und DML- 

Kommandos dürfen in beliebiger (sinnvoller) Reihenfolge verwendet werden. 

Beispiel 5.1 

Die nachfolgend gezeigte Folge von Kommandos trägt in eine leere Tabelle Medienartikel 

die ersten fünf Tupel der im letzten Abschnitt dieses Kapitels in Abbildung 

5.10 gezeigte Tabelle ein (vgl. Abschnitt 5.8): 

insert into Medienartikel 

values(’0001-E’, ’LaTeX in 21 Tagen’, 2004); 


values(’0003-E’, ’Harry Potter III’, 1997); 


values(’0005-B’, ’Der Schwarm’, 2004); 


values(’0006-B’, ’LaTeX kurz und gut’, 2004); 


values(’0007-B’, ’Simplify your life’, 2004); 

In den Beispielen dieses Kapitels beziehen wir uns durchgehend auf die Tabellen, 

die im Stil des letzten Beispiels erzeugt wurden und im Anhang zu diesem Kapitel 

(Abschnitt 5.8) zusammengefasst sind. 

Eine andere Form des INSERT-Kommandos ist die der gleichzeitigen Einfügung 

mehrerer Tupel durch 

INSERT INTO table-name select-expression 

Schließlich sind bei Definition entsprechender Domains möglicherweise Default-Werte 

(Voreinstellungen) festgelegt, so dass dann auch das Kommando 

INSERT INTO table-name DEFAULT VALUES 

Werte in eine Tabelle einfügt. 

Weitere Formen des Einfügens ergeben sich im Zusammenhang mit dem Einfügen 

in Sichten bzw. in typisierte Tabellen. Bei Sichten ist wesentlich, dass diese 

änderbar sind; auf typisierte Tabellen und deren Behandlung gehen wir in einem 

späteren Kapitel ein. 


ISBN 978-3-486-27574-2. Oldenbourg Wissenschaftsverlag München 2008. 

✷


Die folgenden Kommandos zum Löschen bzw. Ändern eines Tupels oder all 

solcher Tupel, die einer bestimmten Bedingung genügen, sind im Wesentlichen selbsterklärend; 

auf die Form einer möglichen condition gehen wir weiter unten im Zusammenhang 

mit Anfragen ein: 

DELETE FROM table-name 

[ WHERE condition ] 

UPDATE table-name 

SET column-name-1 = expression-1 

[, column-name-2 = expression-2 ] ... 


5.3 Datenbank-Anfragen 

In diesem Abschnitt widmen wir uns den Anfragen, die allein unter Verwendung der 

klassischen relationalen Ausdrucksmittel von SQL formuliert werden können. 

5.3.1 Einführung 

SQL kennt nur ein einziges Kommando zur Formulierung von Anfragen an eine Datenbank: 

das SELECT-Kommando bzw. den select-expression. Wir weisen bereits 

an dieser Stelle darauf hin, dass die Bezeichnung SELECT nichts mit der relationalen 

Operation der Selektion (vgl. Kapitel 7) zu tun hat, wenngleich über ein SELECT- 

Kommando bei geeignetem Aufbau auch selektiert werden kann; das Schlüsselwort 

SELECT müsste eigentlich ” PROJECT“ lauten. 

Das SELECT-Kommando kennt viele Optionen zum Aufbau einfacher oder komplexer 

Anfragen, von denen wir in diesem Abschnitt nur auf einige grundlegende eingehen 

wollen. Es kommt uns vor allem darauf an, hier und im weiteren Verlauf unserer 

Betrachtungen die Ausdrucksmöglichkeiten des SELECT-Kommandos mit denen der 

Relationenalgebra vergleichen zu können. Dazu sei jedoch bemerkt, dass es sich bei 

SQL bzw. bei der Teilsprache von SQL, mit welcher Anfragen formuliert werden, nicht 

um eine rein algebraische Sprache handelt, wenngleich eine Reihe von algebraischen 

Operatoren in dieser Sprache vorkommen. Ursprünglich war der Anfrageteil von SQL 

sogar orientiert an einer Einschränkung des so genannten relationalen Tupelkalküls, 

worauf wir später eingehen werden. Außerdem verfügt das SELECT-Kommando z.B. 

über arithmetische Funktionen, Funktionen auf Datums- und Zeitwerten sowie Funktionen 

auf Zeichenketten; mittlerweile ist sogar die Verwendung Benutzer definierter 

Funktionen, Prozeduren und Methoden möglich. 

Das SELECT-Kommando hat zunächst die sehr einfache Grundstruktur 

SELECT Attribute ( ” Ausgabe“) 

FROM Relation(en) ( ” Eingabe“) 

WHERE Bedingung 

In der Sprache der noch zu behandelnden Relationenalgebra wird damit ein SPJ- 

Ausdruck (kurz für Selektion-Projektion-Join) spezifiziert. Die Zuordnung wird wie 




folgt vorgenommen: Die SELECT-Klausel gibt an, auf welche Attribute projiziert werden 

soll. Die FROM-Klausel gibt an, aus welchen Relationen diese Attribute zu entnehmen 

sind. Ist ein Join zu bilden, so sind an dieser Stelle mindestens zwei Ausdrücke 

anzugeben, die zu Relationen ausgewertet werden können; dies können Relationennamen 

sein, die sich jedoch nicht notwendig auf verschiedene Tabellen beziehen müssen. 

Die (optionale) WHERE-Klausel gibt Selektionsbedingungen an bzw. im Falle eines Joins 

außerdem Bedingungen, nach welchen der Verbund zu bilden ist. 

Die Auswertung eines SELECT-Kommandos der oben angegebenen Form hat 

zu berücksichtigen, dass SQL-Tabellen im Unterschied zu Relationen im Relationenmodell 

Multimengen ( ” Bags“) sein dürfen, d.h. doppelte Tupel enthalten können; will 

man ein mehrfaches Vorkommen von Tupeln in einem Anfrageergebnis ausschließen, so 

sind dazu besondere Vorkehrungen erforderlich (wie z.B. die Definition von Schlüsseln 

oder die Verwendung von DISTINCT in der SELECT-Klausel einer Anfrage). 

Unter diesen ” Nebenbedingungen“ verläuft die Auswertung eines SELECT-Kommandos 

grundsätzlich in folgenden drei Schritten: 

(1) Es wird ein Kartesisches Produkt der Tabellen gebildet, die sich durch eine 

Auswertung der Ausdrücke in der FROM-Klausel ergeben (de facto eine ” Konkatenation“ 

dieser Operanden, vgl. unten); 

(2) auf dem in Schritt (1) erzeugten Zwischenergebnis werden die in der WHERE- 

Klausel angegebenen Selektionsbedingungen ausgewertet (sofern unter diesen 

Verbund-Bedingungen vorkommen, entsteht aus der zunächst erzeugten Konkatenation 

jetzt das Ergebnis eines Theta-Verbundes); 

(3) das Zwischenergebnis aus Schritt (2) wird auf die in der SELECT-Klausel angegebenen 

Attribute projiziert. 

5.3.2 Zur Syntax von SELECT 

Wir beschreiben als Nächstes die Grundzüge der SELECT-Syntax genauer, wobei wir 

nach wie vor keinen Anspruch auf Vollständigkeit erheben. Wir beschreiben die Syntax 

nur geringfügig umfangreicher, als wir sie für nachfolgende Beschreibungen benötigen. 

Wir gehen hier anders vor als bei der Beschreibung der Update-Kommandos: Bis auf 

wenige Ausnahmen werden in der Syntax verwendete (kleingeschriebene) Abkürzungen 

bzw. Bezeichnungen in der Reihenfolge ihres Auftretens (einer ” Depth-First- 

Strategie“ folgend) soweit wie nötig detailliert. Wir verwenden unten nicht notwendig 

die gleichen Termini wie im offiziellen Standard-Dokument. 

select-expression ::= 

SELECT [ ALL | DISTINCT ] list-of-select-items 

FROM list-of-table-references 


[ GROUP BY list-of-column-names ] 

[ HAVING condition ] 

select-item ::= 

{ * | expression [ AS ]column-name } 




expression ::= 

term | expression { + | − } term 

term ::= 

factor | term { ∗ | / } factor 

factor ::= 

[ + | − ] primary 

primary ::= 

column-name | scalar-function | aggregate-function 

| ( expression ) 

aggregate-function ::= 

COUNT(∗) | { AVG | MAX | MIN | SUM | COUNT } 

( [ ALL | DISTINCT ] expression ) 

table-reference ::= 

table-name [ [ AS ] range-variable 

[ ( list-of-column-names ) ] ] 

| ( table-expression ) [ AS ] range-variable 

[ ( list-of-column-names ) ] 

| join-table-expression 

table-expression ::= 

join-table-expression | nonjoin-table-expression 

join-table-expression ::= 

table-reference [ NATURAL ] [ join-type ] JOIN table-reference 

[ ON condition 

| USING ( list-of-column-names ) ] 

| table-reference CROSS JOIN table-reference 

| ( join-table-expression ) 

join-type ::= 

INNER | { LEFT | RIGHT | FULL } [ OUTER ] | UNION 

nonjoin-table-expression ::= 

select-expression 

| select-expression { UNION | EXCEPT | INTERSECT } 

select-expression 

condition ::= 

condition-term | condition OR condition-term 

condition-term ::= 

condition-factor | condition-term AND condition-factor 




condition-factor ::= 

[ NOT ] condition-test 

condition-test ::= 

condition-primary [ IS [ NOT ] { TRUE | FALSE | UNKNOWN } ] 

condition-primary ::= 

simple-condition | ( condition ) 

simple-condition ::= 

compare-cond | between-cond | like-cond | in-cond 

| exists-cond | unique-cond 

compare-cond ::= 

expression IS [ NOT ] NULL 

| expression { = | < | | >= | } 

{ expression | ( select-expression ) } 

between-cond ::= 

expression [ NOT ] BETWEEN expression AND expression 

like-cond ::= 

column-name [ NOT ] LIKE ’ string ’ 

in-cond ::= 

expression [ NOT ] IN 

{ ( select-expression | table-expression ) } 

exists-cond ::= 

EXISTS ( table-expression ) 

unique-cond ::= 

UNIQUE ( table-expression ) 

Zu dieser Beschreibung ist Verschiedenes anzumerken: 

(1) SQL unterscheidet zahlreiche Formen von expressions (Ausdrücke), was aus 

der oben angegebenen Syntax nur unvollständig erkennbar ist; insbesondere 

werden numerische, character-basierte, Bitstring- sowie Date/Time-Ausdrücke 

unterschieden. 

(2) Auf die Beschreibung von scalar functions (Skalarfunktionen) haben wir 

oben verzichtet; hierunter versteht man z.B. Funktionen auf Zeichenketten (wie 

Teilstring-Suche oder Konkatenation) oder auf Datums- bzw. Zeit-Werten (wie 

Extraktion der Jahreszahl aus einem Datum). 

(3) Auch die Syntax von table-references sowie table-expressions ist de facto 

erheblich komplexer; das Gleiche gilt für den Aufbau von conditions. 




(4) Wie der oben angegebene Ausschnitt der SELECT-Syntax bereits zeigt, kennt 

SQL verschiedene Verbund-Operatoren. 

5.3.3 Exkurs in die Relationenalgebra 

Wenngleich wir die Relationenalgebra erst in Kapitel 7 ausführlich behandeln werden, 

sei bereits an dieser Stelle ein kurzer Exkurs gestattet. Die Grundlagen der Semantik 

von rein relationalem SQL lassen sich nämlich anhand weniger Operationen der 

Relationenalgebra präzisieren. Wir gehen daher an dieser Stelle bereits kurz auf Projektion, 

Selektion, Umbenennung, Vereinigung, Differenz und natürlichen Verbund 

ein. Man beachte, dass wir hier die in Kapitel 4 eingeführten Formalia für Relationen 

und Relationenschemata verwenden. 

Definition 5.1 

Sei R = (X, .) ein Relationenschema, r ∈ Rel(X) und Y ⊆ X: 

(i) πY (r) := {µ[Y ] | µ ∈ r} 

heißt Projektion von r auf Y . Dabei bezeichnet µ[Y ] die Einschränkung des 

Tupels µ auf Y (µ[Y ] ∈ Tup(Y )). 

(ii) Es sei A ∈ X, a ∈ dom(A) und Θ ∈ {, ≥, =, �=}: 

σAΘa(r) := {µ ∈ r | µ(A)Θa} 

heißt Selektion von r bzgl. AΘa. 

(Für den Fall Θ ∈ {, ≥} sei dabei unterstellt, dass dom(A) geordnet ist.) 

(iii) Es seien A, B ∈ X mit dom(A) = dom(B) und Θ ∈ {, ≥, =, �=}: 

σAΘB(r) := {µ ∈ r | µ(A)Θµ(B)} 

heißt Selektion von r bzgl. AΘB. 

(Für den Fall Θ ∈ {, ≥} sei dabei dom(A) bzw. dom(B) ebenfalls geordnet.) 

Beispiele für diese Operationen sowie die nachfolgend eingeführten oder beschriebenen 

betrachten wir weiter unten direkt in SQL-Notation. Intuitiv entfernt eine Projektion 

die angegebenen Attribute aus der Operandenrelation und sodann eventuell existierende 

doppelte Tupel; eine Projektion liefert also eine Ergebnisrelation mit einem 

gegenüber der Ausgangsrelation veränderten Schema. Eine Selektion dagegen lässt 

das Schema des Operanden unverändert und selektiert lediglich jene Tupel, welche 

die Selektionsbedingung(en) erfüllen. 

Die Operation der Umbenennung erlaubt ein einfaches Verändern eines Attributnames 

im Ergebnis einer Anfrageoperation, was wir hier noch nicht formal definieren; 

wir schreiben A/C, wenn A in C umbenannt werden soll. Ebenso verzichten 

wir an dieser Stelle noch auf die formale Definition von Vereinigung und Differenz als 

klassische Mengenoperationen. Beide Operationen verlangen von ihren beiden Operationen 

jeweils gleiche Schemata (was gegebenenfalls durch Umbenennung erreichbar 

ist) und wirken dann, wie aus der Mengenlehre bekannt: Eine Vereinigung der Form 

R ∪ S liefert die Menge aller Tupel, die in einem der beiden Operanden (R oder S) 

vorkommen; eine Differenz der Form R − S sondert die Tupel aus R aus, die nicht in 

S vorkommen. 




Von besonderer Bedeutung ist im Zusammenhang mit Anfragen die Operation 

des Verbundes, die wir als Nächstes einführen: 


Es seien X1, . . . , Xn Attributmengen und ri ∈ Rel(Xi) für 1 ≤ i ≤ n: 

⊲⊳ n i=1 ri := {µ ∈ Tup(∪ n i=1Xi) | (∀ i, 1 ≤ i ≤ n) µ[Xi] ∈ ri} 

heißt der (natürliche) Verbund ( ” natural join“) von r1, . . . , rn. 

Für den häufigen Fall n = 2 ergibt sich aus der letzten Definition unmittelbar: 

r1 ⊲⊳ r2 = {µ ∈ Tup(X1X2) | µ[X1] ∈ r1 ∧ µ[X2] ∈ r2} 

Der natürliche Verbund verbindet also zwei oder mehr Relationen zu einer neuen 

Relation, welche als Attributmenge die Vereinigung der Attributmengen aller Operanden 

besitzt; die Bildung der Verbindung erfolgt jeweils über gemeinsame Attribute 

und über gleiche Werte für diese. Auf diese beiden letztgenannten Bedingungen kann 

man auch verzichten; dann spricht man allgemeiner von einem Theta-Verbund. Ein 

Theta-Verbund sondert nicht notwendig doppelt vorkommende Attribute aus; er kann 

ferner unterschiedliche (aber typgleiche) Attribute aus den Operandentabellen über 

beliebige Bedingungen verbinden. 

Es sei bemerkt, dass für alle diese Operationen eine Reihe von Rechenregeln gelten, 

welche Grundlage für eine Optimierung von relationenalgebraischen Ausdrücken 

sind. Hierauf werden wir in Kapitel 7 eingehen; für unsere Zwecke in diesem Kapitel 

soll es ausreichen, die Existenz dieser Operationen zu kennen. 

5.3.4 Semantik von SELECT am Beispiel von RA-Ausdrücken 

Bevor wir den Gebrauch des SELECT-Kommandos bei der Formulierung von Anfragen 

am Beispiel der Datenbank des Medienhändlers erläutern, wollen wir kurz den 

Zusammenhang zwischen dem oben eingeführten Ausschnitt der Relationenalgebra 

und SELECT-Ausdrücken herstellen. Insbesondere geben wir als Nächstes SELECT- 

Formulierungen für die gerade vorgestellten algebraischen Operationen an: 

(1) Projektion: 

Sei R = (X, .) ein Relationenschema mit {A1, . . . , Ak} ⊆ X. Die Projektion 

π {A1...Ak}(R) wird ausgedrückt durch 

SELECT DISTINCT A1, ... , Ak FROM R 

(2) Selektion: 

Sei R = (X, .) ein Relationenschema mit A, B ∈ X. Die A = a-Selektion 

σA=a(R) wird ausgedrückt durch 

SELECT DISTINCT * FROM R WHERE A = a 

Analog wird die A = B-Selektion σA=B(R) ausgedrückt durch 

SELECT DISTINCT * FROM R WHERE A = B 




Anstelle von ” =“ können auch andere (anwendbare) Vergleichsoperatoren verwendet 

werden. 

(3) Umbenennung: 

Sei R = (X, .) ein Relationenschema mit X = {A, B} (eine Verallgemeinerung 

auf mehr als zwei Attribute ist leicht möglich). Die Umbenennung von R bzgl. 

A/C wird ausgedrückt durch 

SELECT A AS C, B FROM R 

(4) Vereinigung: 

Seien R und S Relationenschemata mit gleicher Attributmenge. Dann wird die 

Vereinigung R ∪ S ausgedrückt durch 

SELECT DISTINCT * FROM R 

UNION SELECT DISTINCT * FROM S 

(5) Differenz: 

Seien R und S Relationenschemata mit gleicher Attributmenge. Dann wird die 

Differenz R − S ausgedrückt durch 

SELECT DISTINCT * FROM R 

EXCEPT SELECT DISTINCT * FROM S 

(6) Natürlicher Verbund: 

Sei R ein Relationenschema mit den Attributen A1, . . . , An, B1, . . . , Bm und S 

ein solches mit den Attributen B1, . . . , Bm, C1, . . . , Cl. Dann wird der natürliche 

Verbund R ⊲⊳ S explizit ausgedrückt durch 

SELECT DISTINCT A1, ..., Am, R.B1, ..., R.Bm, C1, ..., Cl 

FROM R, S 

WHERE R.B1 = S.B1 AND ... AND R.Bm = S.Bm 

In der SELECT-Klausel wird die Vereinigung der beiden Attributmengen explizit 

beschrieben, wobei es in diesem Fall unerheblich ist, ob man die gemeinsamen 

Attribute aus R oder aus S wählt. Da jedoch Namensgleichheiten zwischen 

Attributen aus verschiedenen Relationenschemata vorkommen, muss durch den 

Zusatz des Relationennamens (z.B. R.B1) eindeutig spezifiziert werden, welches 

Vorkommen des betreffenden Attributs gemeint ist. In der WHERE-Klausel wird 

die Überprüfung auf gleiche Werte für die gemeinsamen Attribute explizit und 

vollständig gefordert. Eine einfachere Formulierung dieser Operation lautet: 

SELECT * FROM R NATURAL JOIN S 

Die oben gegebene Beschreibung der Simulation relationenalgebraischer Operationen 

in SQL reicht offensichtlich bereits aus, alle in der RA formulierbaren Anfragen in 

SQL auszudrücken. 




5.3.5 Verbund-Operatoren in SQL 

Bevor wir SQL-Anfragen weiter erläutern, führen wir zunächst einige weitere Operationen 

auf den Relationen einer Datenbank ein, wobei es uns wesentlich darauf 

ankommt, die unterschiedlichen Verbund-Operatoren präzise zu beschreiben: 


Es sei r ∈ Rel(X), s ∈ Rel(Y ). Dann heißt 

r ∗ s := {µν | µ ∈ r ∧ ν ∈ s} 

die Konkatenation von r und s. (Dabei steht ” µν“ nicht für eine Verknüpfung von µ 

und ν als Funktionen, sondern für eine Hintereinanderschreibung der beiden Tupel.) 

Die Konkatenation bildet – in Analogie zur Konkatenation von Zeichenketten in der 

Theorie der formalen Sprachen – zu zwei gegebenen Tupeln ein neues durch Hintereinanderhängen 

der einzelnen Werte. 

Als erstes Beispiel betrachten wir folgende beiden Relationen r ∈ Rel(AB) und 

s ∈ Rel(CD): 

Dann gilt: 

A B C D 

r : 0 0 s : 1 0 

1 1 0 1 

A B C D 

0 0 1 0 

r ∗ s : 0 0 0 1 

1 1 1 0 

1 1 0 1 

Das Konkatenationsergebnis enthält also Tupel über der disjunkten Vereinigung der 

Attributmengen der beiden Operanden. (Man beachte, dass eine Konkatenation formal 

nicht dasselbe Ergebnis liefert wie ein Kartesisches Produkt, da Letzteres auf 

eine Menge von geordneten Paaren führt, wobei die erste Komponente jeweils aus 

dem einen, die zweite aus dem anderen Operanden stammt.) Es folgt unmittelbar, 

dass eine Konkatenation nicht notwendig eine Relation (in dem aus Kapitel 4 bekannten 

Sinne) zum Ergebnis hat, da die Attributmenge des Resultats unter Umständen 

doppelte Elemente enthält und dann eine Multimenge ist. 

Als zweites Beispiel betrachten wir daher zwei Relationen r ∈ Rel(AB) und t ∈ 

Rel(BC): 

Dann gilt: 

A B B C 

r : 0 0 t : 1 0 

1 1 0 1 




A B B C 

0 0 1 0 

r ∗ t : 0 0 0 1 

1 1 1 0 

1 1 0 1 

Nur in dem Fall, dass X ∩ Y = ∅ gilt für r ∈ Rel(X) und t ∈ Rel(Y ), ist r ∗ t 

eine Relation in dem hier verwendeten Sinne (r ∗ t ∈ Rel(XY )). Im Hinblick auf die 

bereits informal angegebene Semantik eines SELECT-Kommandos sei ferner bemerkt, 

dass man in den gerade genannten Beispielen anstelle von Relationen auch Tabellen 

mit doppelten Zeilen verwenden kann, so dass sowohl das Format einer Tabelle als 

auch ihr Inhalt eine Multimenge sein kann. 

In SQL wird die oben beschriebene Unterscheidung zwischen einer Konkatenation 

und einem Kartesischen Produkt nicht gemacht, sondern diese beiden Operationen 

werden identifiziert. In beiden oben genannten Beispielen erhält man daher das 

Konkatenationsergebnis durch Bildung eines Produkts wie folgt: 

SELECT R.*, S.* FROM R, S 

Eine äquivalente Formulierung, welche die verwendete Operation explizit angibt (und 

daher etwa zu Dokumentationszwecken sinnvoller ist), lautet: 

SELECT * FROM R CROSS JOIN S 

Ein CROSS JOIN liefert also nichts anderes als ein Kartesisches Produkt bzw., in formal 

korrekterer Sprechweise, eine Konkatenation. 

Mit Hilfe der Konkatenation können wir eine weitere oben bereits erwähnte 

Operation definieren, welche für die Formulierung von SELECT-Anfragen wesentlich 

ist: 


Es sei r ∈ Rel(X), s ∈ Rel(Y ), A ∈ X, B ∈ Y , Θ ∈ {, ≥, =, �=}. Dann heißt 

r[AΘB]s := {µν ∈ r ∗ s | µ(A)Θν(B)} 

Θ-Join (sprich: Theta-Join) von r und s. (In dieser Definition sei µ ∈ r bzw. ν ∈ s 

wie in Definition 10.1.) 

Ist Θ speziell das Zeichen ” =“, so spricht man vom Equijoin von r und s. 

Als Beispiel betrachten wir zunächst die weiter oben angegebenen Relationen r ∈ 

Rel(AB) und s ∈ Rel(CD). Dann gilt: 

A B C D 

r[B = C]s : 0 0 0 1 

1 1 1 0 

In SQL lautet die entsprechende Formulierung wie folgt: 




SELECT * FROM R, S WHERE R.B = S.C 

Eine alternative (und explizitere) Formulierung derselben Anfrage lautet: 

SELECT * FROM R JOIN S ON R.B = S.C 

Für r ∈ Rel(AB), s ∈ Rel(BC) wie oben angegeben gilt z.B. 

A B B C 

r[B < B]s : 0 0 1 0 

Die entsprechende SQL-Formulierung lautet: 

SELECT * FROM R, S WHERE R.B < S.B 

Offensichtlich gilt für r ∈ Rel(X) und s ∈ Rel(Y ) formal dann Folgendes: Ist X ∩Y = 

∅, so ist r ∗ s eine Relation (über XY ). Dann ist auch r[AΘB]s eine Relation (über 

XY mit A ∈ X, B ∈ Y ), und der Theta-Join von r und s kann wie folgt geschrieben 

werden: 

r[AΘB]s = σAΘB(r ∗ s) 

Der Theta-Join stellt offensichtlich eine Verallgemeinerung des natürlichen Verbundes 

dar; konkret ist ein natürlicher Verbund ein Equijoin, welcher über gleichbenannte 

Attribute gebildet wird (und bei welchem auf diese projiziert wird). 

SQL lässt als weitere Verallgemeinerung des natürlichen Verbunds zu, dass 

einige, aber nicht alle gemeinsamen Attribute auf gleiche Werte überprüft werden. 

Hat z.B. R die Attribute A, B und C, S die Attribute B, C und D, so ist es möglich, 

einen (verallgemeinerten) natürlichen Verbund nur über B (oder über C) zu bilden. 

Die entsprechende Formulierung lautet: 

SELECT * FROM R JOIN S USING (B) 

Der natürliche Verbund und seine gerade beschriebenen Verallgemeinerungen werden 

in der SQL-Terminologie auch als innere Joins bezeichnet. Im Unterschied dazu 

werden Verbund-Operationen als äußere Verbünde (outer joins) bezeichnet, falls 

Operanden-Tupel, welche die Verbund-Bedingung nicht erfüllen, im Ergebnis erhalten 

bleiben. 

Wir verzichten auf eine formale Definition des äußeren Verbunds und beschreiben 

hier nur exemplarisch seine in SQL vorgesehenen Erscheinungsformen. Man spricht 

von einem LEFT OUTER JOIN, falls alle Tupel des ” linken“ (ersten) Verbund-Operanden 

im Ergebnis erhalten bleiben. Als Beispiel betrachten wir die folgenden beiden Tabellen: 

Der SELECT-Ausdruck 

A B C D 

r : 1 0 s : 1 0 

2 1 0 1 




SELECT * FROM R LEFT OUTER JOIN S ON R.A = S.C 

liefert dann das folgende Ergebnis: 

A B C D 

1 0 1 0 

2 1 ? ? 

(Hierbei bezeichnet ” ?“ den Nullwert mit der Bedeutung ” unbekannt“.) Entsprechend 

erhält ein RIGHT OUTER JOIN alle Tupel des ” rechten“ (zweiten) Operanden im Ergebnis. 

Im Beispiel der oben angegebenen Relationen liefert also z.B. 

SELECT * FROM R RIGHT OUTER JOIN S ON R.A = S.C 

das folgende Ergebnis: 

A B C D 

1 0 1 0 

? ? 0 1 

Schließlich stellt ein FULL OUTER JOIN (im Allgemeinen kurz auch als OUTER JOIN bezeichnet) 

eine Kombination von LEFT und RIGHT OUTER JOIN dar. Im obigen Beispiel 

liefert also z.B. 

SELECT * FROM R FULL OUTER JOIN S ON R.A = S.C 

das folgende Ergebnis: 

A B C D 

1 0 1 0 

2 1 ? ? 

? ? 0 1 

Abschließend sei bemerkt, dass die Anwendung dieser Operatoren nicht auf zwei Operanden 

beschränkt ist. 

5.4 Beispiele für SQL-Anfragen 

Wir beschreiben als Nächstes eine Reihe von Beispielen für die Verwendung des 

SELECT-Kommandos, wobei wir mit Selektionen und Projektionen beginnen und dann 

zu Verbund- sowie anderen Anfragen (Aggregationen, Gruppierungen, Unteranfragen) 

übergehen. Der aktuelle Inhalt der hier verwendeten Beispiel-Datenbank ist im letzten 

Abschnitt dieses Kapitel zusammengestellt; ein Blick hierauf vor Durcharbeitung 

der nachfolgenden Beispiele wird empfohlen.

Datenmodelle, Datenbanksprachen und Datenbank - Oldenbourg ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?