Einführung in SQL - upload.wikimedia.org¼hrung_in_SQL.pdf · Titel „Einführung in SQL“, Einschränkung auf Jahr „2011–“. Namen von Programmen und Produkten sowie weitere

Einfhrung in SQLDatenbanken bearbeiten

Jrgen Thomas

Ein Wiki-Buch

Bibliografische Information

Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillier-te Angaben sind im Internet zu erhalten:https://portal.d-nb.de/opac.htm?method=showOptions#topTitel Einfhrung in SQL, Einschrnkung auf Jahr 2011.

Namen von Programmen und Produkten sowie weitere technische Angaben sindhufig geschtzt. Da es auch freie Bezeichnungen gibt, wird das Symbol nichtverwendet.

Die Online-Version, die PDF-Version und die gedruckte Fassung unterscheidensich vor allem wegen unterschiedlicher Seitenformate und technischer Mglich-keiten.

ISBN 978-3-9815260-0-4 (Juli 2012)

Verlag: Jrgen Thomas, DE-13189 Berlin, http://www.vs-polis.de/verlag

Diese Publikation ist entstanden bei Wikibooks, einem Projekt der WikimediaFoundation fr Lehr-, Sach- und Fachbcher unter den Lizenzen Creative Com-mons Attribution/Share-Alike (CC-BY-SA) und GFDL.

PDF- und Druckversion sind entstanden mit dem Programm wb2pdf unter GPL.Dabei wurde das Textsatzprogramm LATEX verwendet, das unter der LPPL steht.

Die Grafik auf dem Buchumschlag wurde unter der Lizenz CC-BY-SA-3.0 selbsterstellt und ist zu finden unter:http://de.wikibooks.org/wiki/Datei:SQL-Titelbild.png

Einzelheiten zu den Lizenzen und Quellen stehen im Anhang auf Seite 451.

Druck und Verarbeitung: Conrad Citydruck & Copy GmbH, Uhlandstrae 147,DE-10719 Berlin

https://portal.d-nb.de/opac.htm?method=showOptions##tophttp://www.vs-polis.de/verlaghttp://de.wikibooks.org/wiki/Datei:SQL-Titelbild.png

bersicht

1. Vorwort 1

I. Einfhrung 32. Ein Einstieg 53. Einleitung 114. Relationale Datenbanken 175. Normalisierung 256. Beispieldatenbank 39

II. Grundlagen 457. SQL-Befehle 478. DML (1) Daten abfragen 579. DML (2) Daten speichern 6910. DDL Struktur der Datenbank 7911. TCL Ablaufsteuerung 8912. DCL Zugriffsrechte 9513. Datentypen 9714. Funktionen 109

III. Mehr zu Abfragen 12715. Ausfhrliche SELECT-Struktur 12916. Funktionen (2) 14117. WHERE-Klausel im Detail 15518. Mehrere Tabellen 16719. Einfache Tabellenverknpfung 17320. Arbeiten mit JOIN 18121. OUTER JOIN 19122. Mehr zu JOIN 20323. Ntzliche Erweiterungen 21324. Berechnete Spalten 23525. Gruppierungen 24126. Unterabfragen 25127. Erstellen von Views 271

III

bersicht

IV. Erweiterungen 28328. DDL Einzelheiten 28529. Fremdschlssel-Beziehungen 30530. SQL-Programmierung 32331. Eigene Funktionen 34732. Prozeduren 35733. Trigger 37734. Tipps und Tricks 38935. nderung der Datenbankstruktur 39736. Testdaten erzeugen 407

V. Anhang 417A. Tabellenstruktur der Beispieldatenbank 419B. Downloads 423C. Befehlsreferenz 431D. Weitere Informationen 445E. Zu diesem Buch 451

IV

Inhaltsverzeichnis

1. Vorwort 1

I. Einfhrung 3

2. Ein Einstieg 52.1. Datenbanken enthalten Informationen . . . . . . . . . . . . . . . 52.2. Abfrage nach den Mitarbeitern . . . . . . . . . . . . . . . . . . . . . 62.3. Neuaufnahme bei den Mitarbeitern . . . . . . . . . . . . . . . . . . 72.4. SQL und natrliche Sprache . . . . . . . . . . . . . . . . . . . . . . 82.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Einleitung 113.1. Geschichte von SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2. bersicht ber Datenbankmanagementsysteme . . . . . . . . . 123.3. Schreibweisen im Buch . . . . . . . . . . . . . . . . . . . . . . . . . 143.4. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. Relationale Datenbanken 174.1. Grundstruktur relationaler Datenbanken . . . . . . . . . . . . . . 174.2. Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3. Spalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4. Verknpfungen und Schlssel . . . . . . . . . . . . . . . . . . . . . 224.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5. Normalisierung 255.1. Grundgedanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2. Die 1. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3. Die 2. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4. Die 3. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5. Zustzliche Manahmen . . . . . . . . . . . . . . . . . . . . . . . . 345.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6. Beispieldatenbank 396.1. Sachverhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

V

Inhaltsverzeichnis

6.2. Schematische Darstellung . . . . . . . . . . . . . . . . . . . . . . . . 416.3. Tabellenstruktur und Datenbank . . . . . . . . . . . . . . . . . . . 426.4. Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II. Grundlagen 45

7. SQL-Befehle 477.1. Allgemeine Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.2. DML Data Manipulation Language . . . . . . . . . . . . . . . . . 497.3. DDL Data Definition Language . . . . . . . . . . . . . . . . . . . 517.4. TCL Transaction Control Language . . . . . . . . . . . . . . . . . 527.5. DCL Data Control Language . . . . . . . . . . . . . . . . . . . . . 527.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.7. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.8. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8. DML (1) Daten abfragen 578.1. SELECT Allgemeine Hinweise . . . . . . . . . . . . . . . . . . . . 578.2. Die einfachsten Abfragen . . . . . . . . . . . . . . . . . . . . . . . . 588.3. DISTINCT Keine doppelten Zeilen . . . . . . . . . . . . . . . . . 598.4. WHERE Eingrenzen der Ergebnismenge . . . . . . . . . . . . . . 608.5. ORDER BY Sortieren . . . . . . . . . . . . . . . . . . . . . . . . . . 618.6. FROM Mehrere Tabellen verknpfen . . . . . . . . . . . . . . . . 628.7. Ausblick auf komplexe Abfragen . . . . . . . . . . . . . . . . . . . . 648.8. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658.9. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9. DML (2) Daten speichern 699.1. INSERT Daten einfgen . . . . . . . . . . . . . . . . . . . . . . . . 699.2. UPDATE Daten ndern . . . . . . . . . . . . . . . . . . . . . . . . 729.3. DELETE Daten lschen . . . . . . . . . . . . . . . . . . . . . . . . 749.4. TRUNCATE Tabelle leeren . . . . . . . . . . . . . . . . . . . . . . . 759.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10. DDL Struktur der Datenbank 7910.1. Allgemeine Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7910.2. Hauptteile der Datenbank . . . . . . . . . . . . . . . . . . . . . . . . 8010.3. Ergnzungen zu Tabellen . . . . . . . . . . . . . . . . . . . . . . . . 8310.4. Programmieren mit SQL . . . . . . . . . . . . . . . . . . . . . . . . . 8510.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8510.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8610.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

VI

Inhaltsverzeichnis

11. TCL Ablaufsteuerung 8911.1. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8911.2. Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9011.3. Misserfolg regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9111.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9211.5. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

12. DCL Zugriffsrechte 95

13. Datentypen 9713.1. Vordefinierte Datentypen . . . . . . . . . . . . . . . . . . . . . . . . 9713.2. Konstruierte und benutzerdefinierte Datentypen . . . . . . . . . 10113.3. Spezialisierte Datentypen . . . . . . . . . . . . . . . . . . . . . . . . 10213.4. Nationale und internationale Zeichenstze . . . . . . . . . . . . . 10313.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10513.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10513.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

14. Funktionen 10914.1. Allgemeine Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 11014.2. Funktionen fr Zahlen . . . . . . . . . . . . . . . . . . . . . . . . . . 11014.3. Funktionen fr Zeichenketten . . . . . . . . . . . . . . . . . . . . . 11314.4. Funktionen fr Datums- und Zeitwerte . . . . . . . . . . . . . . . 11514.5. Funktionen fr logische und NULL-Werte . . . . . . . . . . . . . . 11614.6. Konvertierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11714.7. Spaltenfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12014.8. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12314.9. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12314.10. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

III. Mehr zu Abfragen 127

15. Ausfhrliche SELECT-Struktur 12915.1. Allgemeine Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12915.2. Set Quantifier Mengenquantifizierer . . . . . . . . . . . . . . . . 13015.3. Select List Auswahlliste . . . . . . . . . . . . . . . . . . . . . . . . 13015.4. Table Reference List Tabellen-Verweise . . . . . . . . . . . . . . 13215.5. WHERE-Klausel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13315.6. GROUP BY- und HAVING-Klausel . . . . . . . . . . . . . . . . . . . 13415.7. UNION-Klausel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13515.8. ORDER BY-Klausel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13615.9. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13615.10. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

VII

Inhaltsverzeichnis

16. Funktionen (2) 14116.1. Funktionen fr Zahlen . . . . . . . . . . . . . . . . . . . . . . . . . . 14116.2. Funktionen fr Zeichenketten . . . . . . . . . . . . . . . . . . . . . 14416.3. Funktionen fr Datums- und Zeitwerte . . . . . . . . . . . . . . . 14616.4. Funktionen fr logische und NULL-Werte . . . . . . . . . . . . . . 14816.5. Verschiedene Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 15016.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15016.7. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15016.8. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

17. WHERE-Klausel im Detail 15517.1. Eine einzelne Bedingung . . . . . . . . . . . . . . . . . . . . . . . . 15517.2. Mehrere Bedingungen verknpfen . . . . . . . . . . . . . . . . . . 16017.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16217.4. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16317.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

18. Mehrere Tabellen 16718.1. Schreibweisen bei mehreren Tabellen . . . . . . . . . . . . . . . . 16718.2. Mit Hilfe von WHERE der traditionelle Weg . . . . . . . . . . . . 16818.3. JOINs der moderne Weg . . . . . . . . . . . . . . . . . . . . . . . . 16818.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16918.5. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

19. Einfache Tabellenverknpfung 17319.1. Alle Kombinationen aller Datenstze . . . . . . . . . . . . . . . . . 17319.2. Tabellen einfach verbinden . . . . . . . . . . . . . . . . . . . . . . . 17419.3. Verknpfungs- und Auswahlbedingungen . . . . . . . . . . . . . . 17619.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17619.5. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17619.6. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

20. Arbeiten mit JOIN 18120.1. Die Syntax von JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 18120.2. INNER JOIN von zwei Tabellen . . . . . . . . . . . . . . . . . . . . . 18220.3. WHERE-Klausel bei JOINs . . . . . . . . . . . . . . . . . . . . . . . . 18320.4. INNER JOIN mehrerer Tabellen . . . . . . . . . . . . . . . . . . . . 18520.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18520.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18620.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

21. OUTER JOIN 19121.1. Allgemeine Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 19121.2. LEFT OUTER JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19221.3. RIGHT OUTER JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

VIII

Inhaltsverzeichnis

21.4. FULL OUTER JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19421.5. Verknpfung mehrerer Tabellen . . . . . . . . . . . . . . . . . . . . 19521.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19821.7. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

22. Mehr zu JOIN 20322.1. Welcher JOIN-Typ passt wann? . . . . . . . . . . . . . . . . . . . . . 20322.2. SELF JOIN Verknpfung mit sich selbst . . . . . . . . . . . . . . 20422.3. CROSS JOIN das kartesische Produkt . . . . . . . . . . . . . . . . 20922.4. WITH Inline-View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21022.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21122.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21122.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

23. Ntzliche Erweiterungen 21323.1. Beschrnkung auf eine Anzahl Zeilen . . . . . . . . . . . . . . . . . 21323.2. Mehrere Abfragen zusammenfassen . . . . . . . . . . . . . . . . . 22023.3. CASE WHEN Fallunterscheidungen . . . . . . . . . . . . . . . . . 22323.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22823.5. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

24. Berechnete Spalten 23524.1. Ergebnis von Berechnungen . . . . . . . . . . . . . . . . . . . . . . 23624.2. Zeichenketten verbinden und bearbeiten . . . . . . . . . . . . . . 23624.3. Ergebnis von Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 23724.4. Unterabfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23824.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23824.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

25. Gruppierungen 24125.1. Syntax von GROUP BY . . . . . . . . . . . . . . . . . . . . . . . . . . 24125.2. Gruppierung bei einer Tabelle . . . . . . . . . . . . . . . . . . . . . 24225.3. Gruppierung ber mehrere Tabellen . . . . . . . . . . . . . . . . . 24325.4. Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24425.5. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24525.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24725.7. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24725.8. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

26. Unterabfragen 25126.1. Ergebnis als einzelner Wert . . . . . . . . . . . . . . . . . . . . . . . 25126.2. Ergebnis als Liste mehrerer Werte . . . . . . . . . . . . . . . . . . . 25426.3. Ergebnis in Form einer Tabelle . . . . . . . . . . . . . . . . . . . . . 25626.4. Verwendung bei Befehlen zum Speichern . . . . . . . . . . . . . . 25826.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

IX

Inhaltsverzeichnis

26.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

27. Erstellen von Views 27127.1. Eine View anlegen und benutzen . . . . . . . . . . . . . . . . . . . 27227.2. Eine View ndern oder lschen . . . . . . . . . . . . . . . . . . . . 27627.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27727.4. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27727.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

IV. Erweiterungen 283

28. DDL Einzelheiten 28528.1. Definition einer Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 28528.2. Definition einer einzelnen Spalte . . . . . . . . . . . . . . . . . . . 28728.3. Tabelle ndern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29128.4. CONSTRAINTs Einschrnkungen . . . . . . . . . . . . . . . . . . 29328.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30128.6. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30128.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

29. Fremdschlssel-Beziehungen 30529.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30529.2. Grundstze der Lsung . . . . . . . . . . . . . . . . . . . . . . . . . 30629.3. Syntax und Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 30729.4. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31129.5. Kombination von Fremdschlsseln . . . . . . . . . . . . . . . . . . 31229.6. Rekursive Fremdschlssel . . . . . . . . . . . . . . . . . . . . . . . . 31429.7. Reihenfolge der Manahmen beachten . . . . . . . . . . . . . . . 31629.8. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31729.9. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31829.10. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

30. SQL-Programmierung 32330.1. Routinen ohne feste Speicherung . . . . . . . . . . . . . . . . . . . 32430.2. Programmieren innerhalb von Routinen . . . . . . . . . . . . . . . 32530.3. SQL-Programmierung mit Firebird . . . . . . . . . . . . . . . . . . 32630.4. SQL-Programmierung mit MS-SQL . . . . . . . . . . . . . . . . . . 33130.5. SQL-Programmierung mit MySQL . . . . . . . . . . . . . . . . . . . 33430.6. SQL-Programmierung mit Oracle . . . . . . . . . . . . . . . . . . . 33830.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34230.8. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34330.9. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

X

Inhaltsverzeichnis

31. Eigene Funktionen 34731.1. Funktion definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34731.2. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34931.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35131.4. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35131.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

32. Prozeduren 35732.1. Die Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35832.2. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36032.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37032.4. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37032.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

33. Trigger 37733.1. Die Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37833.2. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37933.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38133.4. bungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38233.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

34. Tipps und Tricks 38934.1. Die letzte ID abfragen . . . . . . . . . . . . . . . . . . . . . . . . . . 38934.2. Tabellenstruktur auslesen . . . . . . . . . . . . . . . . . . . . . . . . 39134.3. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

35. nderung der Datenbankstruktur 39735.1. Spalten hinzufgen und ndern . . . . . . . . . . . . . . . . . . . . 39735.2. Einschrnkungen auf Spalten . . . . . . . . . . . . . . . . . . . . . 39935.3. Indizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40135.4. Fremdschlssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40235.5. Weitere Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . . . 40235.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40535.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

36. Testdaten erzeugen 40736.1. Neue Fahrzeuge registrieren . . . . . . . . . . . . . . . . . . . . . . 40836.2. Neue Versicherungsvertrge registrieren . . . . . . . . . . . . . . . 40836.3. Probleme mit Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . 41436.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41536.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

XI

Inhaltsverzeichnis

V. Anhang 417

A. Tabellenstruktur der Beispieldatenbank 419

B. Downloads 423B.1. Die Download-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . 423B.2. Verbindung zu den Datenbanksystemen . . . . . . . . . . . . . . . 424B.3. Die vollstndige Beispieldatenbank . . . . . . . . . . . . . . . . . . 427B.4. Erstellen der Beispieldatenbank . . . . . . . . . . . . . . . . . . . . 427B.5. Skripte fr nachtrgliche nderungen . . . . . . . . . . . . . . . . 428

C. Befehlsreferenz 431C.1. DDL (Data Definition Language) . . . . . . . . . . . . . . . . . . . 431C.2. DML Data Manipulation Language . . . . . . . . . . . . . . . . . 435C.3. TCL Transaction Control Language . . . . . . . . . . . . . . . . . 438C.4. DCL Data Control Language . . . . . . . . . . . . . . . . . . . . . 439C.5. Schlsselwrter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

D. Weitere Informationen 445D.1. Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . 445D.2. Weblinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

E. Zu diesem Buch 451E.1. Hinweise zu den Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . 451E.2. Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452E.3. Bildnachweis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

XII

1. Vorwort

Dieses Buch ist im Laufe mehrerer Jahre entstanden mit einer Diskussion dar-ber, inwieweit die Sprache einer bestimmten SQL-Datenbank behandelt wer-den sollte oder eher ein allgemeiner berblick erforderlich ist. Dies sieht mandem Buch auch heute noch an; aber die Regel ist klar: Es handelt sich um eineEinfhrung in den SQL-Standard; die Unterschiede zwischen den SQL-Dialekten(wie man die Unterschiede zwischen den Datenbanksystemen nennt) werdennur soweit behandelt, wie es unbedingt ntig ist.

Dieses Buch richtet sich an:

Schler, Studenten und Andere, die sich mit relationalen Datenbanken be-schftigen wollen bzw. mssen.

Was dieses Buch erreichen will:

Einfhrung in SQL anhand einer Beispieldatenbank.

Der Leser soll die Beispiele anhand von bungen auf seinem eigenen Daten-bankmanagementsystem nachvollziehen knnen.

Die Schwerpunkte liegen hierbei auf folgenden Themen:

Abfragen von Daten

Manipulieren von Daten

Einfaches ndern der Datenbankstruktur

Was dieses Buch nicht sein soll:

Keine Einfhrung in die Grundkonzepte relationaler Datenbankmodelle.

Keine Einfhrung in die Gestaltung relationaler Datenbanken.

Keine Einfhrung in die Verwaltung von Datenbankmanagementsystemen.

Keine Einfhrung in die Verbesserung der Geschwindigkeit relationaler Daten-banken.

Keine Einfhrung in prozedurale (z. B. PL/SQL) oder objektorientierte Spra-chen, die innerhalb der Datenbank gespeichert und genutzt werden knnen.

1

Vorwort

Hoffentlich gewinnen die Leser mit dieser Darstellung mit vielen Erluterun-gen, Beispielen und bungen einen guten Einblick in die Mglichkeiten vonSQL.

Auch wenn ich mich als Hauptautor bezeichne, wre dieses Buch nicht so um-fangreich und mglichst hilfreich geworden ohne die Vorarbeit vieler andererAutoren bei Wikibooks1 und die Kontrolle durch Leser und Lernende. Bei all die-sen freundlichen Mitmenschen mchte ich mich herzlich fr ihre Beteiligungbedanken.

Jrgen Thomas Berlin, im Juli 2012

1 Siehe die Lizenzhinweise auf Seite 451

2

Teil I.

Einfhrung

3

2. Ein Einstieg

2.1. Datenbanken enthalten Informationen . . . . . . . . . . . . . . 5

2.2. Abfrage nach den Mitarbeitern . . . . . . . . . . . . . . . . . . . 6

2.3. Neuaufnahme bei den Mitarbeitern . . . . . . . . . . . . . . . . 7

2.4. SQL und natrliche Sprache . . . . . . . . . . . . . . . . . . . . . 8

2.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Nehmen wir einmal an, dass ein Versicherungsunternehmen einen neuen Ge-schftsfhrer bekommt. Dieser sammelt zunchst Informationen, um sich mitdem Unternehmen vertraut zu machen.

2.1. Datenbanken enthalten Informationen

Der Geschftsfhrer findet in seinem Bro keine Akten, sondern nur einen PC.Nach dem Einschalten und Anmelden bekommt er folgende Begrung:

Wikibooks-Beispieldatenbank(C) Wiki-SQLBitte geben Sie einen SQL-Befehl ein:sql >

Damit wird der Geschftsfhrer auf mehrere Punkte der Organisation in seinemUnternehmen hingewiesen.

Die Daten sind in einer Datenbank zusammengefasst mit dem Namen Bei-spieldatenbank.

Diese Datenbank (DB) stammt von der Firma Wikibooks.

Um etwas mit dieser DB zu machen, soll er hinter "sql >" einen SQL-Befehleingeben.

Die Inhalte dieser Datenbank sind im Kapitel Beispieldatenbank beschrieben,Einzelheiten unter Tabellenstruktur der Beispieldatenbank.

5

Ein Einstieg

Das Datenbanksystem (DBMS) der Firma Wikibooks wird als Wiki-SQL bezeich-net. Dies bedeutet, dass die Beispieldatenbank zu Wiki-SQL passen muss inBezug auf das Dateiformat, die interne Struktur und den Aufbau der Befehle.

SQL ist die Abkrzung fr Structured Query Language, also strukturierte Abfra-gesprache. Der Geschftsfhrer hat schon einmal davon gehrt, dass dies einestandardisierte Form ist, um mit Datenbanken zu arbeiten, und probiert es aus.

2.2. Abfrage nach den Mitarbeitern

Als erstes mchte er eine Liste seiner Mitarbeiter haben. Er berlegt, wie die Ab-frage lauten knnte:

Hole Name und Vorname von den Mitarbeitern

Auf Englisch probiert er (mit ein paar Synonymen) also so etwas aus:

Get Name, Vorname FROM MitarbeiterFetch Name, Vorname FROM MitarbeiterFind Name, Vorname FROM MitarbeiterSearch Name, Vorname FROM Mitarbeiter

Und schlielich bekommt er keine Fehlermeldung, sondern ein Ergebnis:

SELECT Name, Vorname FROM Mitarbeiter

Die Liste ist ihm zu lang und unbersichtlich. Er will sie zunchst einmal sortie-ren und probiert Sortierung, Reihenfolge aus, bis es passt:

SELECT Name, Vorname FROM Mitarbeiter ORDER BY Name

Dann mchte er die Auswahl einschrnken, nmlich auf die Mitarbeiter mit An-fangsbuchstaben 'A'. Wieder nach ein paar Versuchen wei er, dass nicht WITH,sondern WHERE die Lsung liefert.

SELECT Name, Vorname FROM Mitarbeiter WHERE Name < B

Jetzt mchte er beide Abfragen verbinden:

Quelltext Falsch

SELECT Name, Vorname FROM Mitarbeiter ORDER BY Name WHERE Name < B

6

Neuaufnahme bei den Mitarbeitern

SQL error code = -104. Token unknown - line 1, column 53. WHERE.

Das kann doch nicht sein?! WHERE ist doch das richtige Verfahren fr eine solcheEinschrnkung?! Kommt es etwa auf die Reihenfolge der Zustze an?

Quelltext Richtig

SELECT Name, Vorname FROM Mitarbeiter WHERE Name < B ORDER BY Name

NAME VORNAMEAagenau KarolinAliman Zafer

Welche Informationen sind denn sonst gespeichert? Er wei auch (z. B. vom DIR-Befehl des Betriebssystems), dass ein Sternchen anstelle von alles gesetzt werdenkann. Und siehe da, es klappt:

SELECT * FROM Mitarbeiter WHERE Name < B ORDER BY Name

ID PERSONALNUMMER NAME VORNAME GEBURTSDATUM TELEFON (und noch mehr)13 60001 Aagenau Karolin 02.01.1950 0234/66006001 usw.18 80002 Aliman Zafer 12.11.1965 0201/4012161 usw.

Prima, damit ist klar, wie Informationen aus der Datenbank geholt werden:

SELECT FROM WHERE ORDER BY

2.3. Neuaufnahme bei den Mitarbeitern

Als nchstes mchte der Geschftsfhrer sich selbst als Mitarbeiter speichern.Schnell kommt er auf das Grundgerst des Befehls:

INSERT INTO Mitarbeiter VALUES

Wenn er danach seinen Namen schreibt, bekommt er wieder eine Fehlermel-dung mit "token unknown". Er hat aber schon von der Benutzung von Klammernin der EDV gehrt.

7

Ein Einstieg

Quelltext Falsch

INSERT INTO Mitarbeiter VALUES (Webern, Anton)

SQL error code = -804.Count of read-write columns does not equal count of values.

Na gut, dann wird eben ausdrcklich angegeben, dass erstmal nur Name undVorname einzutragen sind.

Quelltext Falsch

INSERT INTO Mitarbeiter (Name, Vorname) VALUES (Webern, Anton)

validation error for column PERSONALNUMMER, value "*** null ***".

Ach so, die Personalnummer muss angegeben werden, und vermutlich alles an-dere auch. Aber die ID ist doch gar nicht bekannt? Nun, immerhin sind wir aufdiese Grundstruktur des Befehls gekommen:

INSERT INTO [ ( ) ]

VALUES ( )

2.4. SQL und natrliche Sprache

Offensichtlich sind die Befehle von SQL der natrlichen englischen Sprachenachempfunden. (Englisch hat wegen der klaren Satzstruktur und Grammatikinsoweit natrlich Vorteile gegenber der komplizierten deutschen Syntax.)

SELECT fr Abfragen

Um Daten abzufragen, gibt es den SELECT-Befehl mit folgenden Details:

SELECT whle aus[ DISTINCT | ALL ] verschiedene | alle

FROM aus

[ WHERE ] wobei[ GROUP BY ] gruppiert durch[ HAVING ] wobei[ ORDER BY ] sortiert durch

8

Zusammenfassung

INSERT fr Neuaufnahmen

Um Daten neu zu speichern, gibt es den INSERT-Befehl mit folgenden Details:

INSERT INTO einfgen in[ ]

VALUES ( ) Werte/* oder */INSERT INTO einfgen in[ ]

SELECT durch eine Auswahl

UPDATE fr nderungen

Um Daten zu ndern, gibt es den UPDATE-Befehl mit folgenden Details:

UPDATE aktualisiereSET = [ , setze fest

= , usw. = ]

[ WHERE ]; wobei

DELETE fr Lschungen

Um Daten zu lschen, gibt es den DELETE-Befehl mit folgenden Details:

DELETE FROM lsche aus[ WHERE ]; wobei

CREATE TABLE bei der Struktur einer Tabelle

Um eine neue Tabelle zu erstellen, gibt es den CREATE TABLE-Befehl mit fol-genden Einzelheiten:

CREATE TABLE erzeuge Tabelle( , )

So einfach kann es gehen? Dann kann man doch auch eigene Daten erzeugen,speichern, abfragen und auswerten.

2.5. Zusammenfassung

Die einzelnen Teile der SQL-Befehle sind leicht verstndlich; und es scheint nurwenige Befehle zu geben, die man als Anfnger wirklich lernen muss. Natrlich

9

Ein Einstieg

kann man nicht sofort alle Mglichkeiten erfassen. Aber angesichts des begrenz-ten Umfangs und der klaren Struktur lohnt es sich, sich nher damit zu befassen.Dies will dieses Buch erleichtern.

2.6. Siehe auch

Wikipedia hat einen Artikel zum Thema SQL1.

Weitere Informationen gibt es in folgenden Kapiteln:

Beispieldatenbank2

Tabellenstruktur der Beispieldatenbank3

1 http://de.wikipedia.org/wiki/SQL2 Kapitel 6 auf Seite 393 Anhang A auf Seite 419

10

http://de.wikipedia.org/wiki/SQL

3. Einleitung

3.1. Geschichte von SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2. bersicht ber Datenbankmanagementsysteme . . . . . . . . 12

3.3. Schreibweisen im Buch . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Dieses Kapitel gibt Informationen ber Inhalt und Aufbau des Buches.

Die Abfragesprache SQL ist die etablierte Sprache fr die Arbeit mit relationa-len Datenbankmanagementsystemen (DBMS). Es existieren verschiedene Stan-dards, und jeder Hersteller von DBMS hat seine eigenen Erweiterungen und Be-sonderheiten zu den Standards.

Das Buch soll eine Einfhrung in die Sprache SQL bieten. Ziel ist es, dass derLeser nach dem Durcharbeiten folgende Aufgaben selbstndig lsen kann:

Eigene Abfragen fr relationale Datenbanken erstellen

Manipulieren von Daten (Einfgen, ndern und Lschen)

Eigene einfache relationale Datenbanken aufbauen

Bestehende Datenbankstrukturen erweitern

Um die Ziele zu erreichen, wird SQL anhand praxisnaher Beispiele erlutert.

Die Beispiele im Buch wurden unter mindestens einem der folgenden DBMS ge-testet:

Firebird

MS-SQL Server 2005 oder 2008

MySQL 4.1 oder 5

Oracle 9, 10 oder 11

Vorzugsweise werden allgemeingltige Schreibweisen nach dem SQL-Standard(siehe unten) benutzt. Deshalb sollten die Befehle in aller Regel auf allengngigen DBMS funktionieren und hchstens kleinere nderungen bentigen.Dort, wo eine Schreibweise wesentlich abweicht, wird das ausdrcklich er-whnt.

11

Einleitung

i AchtungWegen der unterschiedlichen Schreibweisen der SQL-Befehle ist eine voll-stndige Prfung leider nicht mglich. Sie mssen in allen Zweifelsfllen inder Dokumentation Ihres DBMS die passende Schreibweise nachlesen.

3.1. Geschichte von SQL

SQL ist aus IBMs SEQUEL in den siebziger Jahren entstanden. Der Erfolg derSprache SQL liegt sicherlich auch darin, dass sie einfach aufgebaut ist und sichan der englischen Umgangssprache orientiert. Es gibt verschiedene Standards:

Erster SQL-Standard (1986 ANSI)

SQL2 bzw. SQL-92 (1992)

SQL3 bzw. SQL:1999 (1999 ISO)

SQL:2003 (2003)

SQL:2008 (2008)

Hierbei ist zu beachten, dass die meisten Datenbankmanagementsysteme SQL2untersttzen. Die neueren Versionen sind in der Regel nur teilweise oder garnicht in den einzelnen Datenbankmanagementsystemen umgesetzt.

Alles, was in diesem Buch als SQL-Standard, also als offizielle SQL-Feststellung angegeben wird, bezieht sich auf die SQL-Dokumente von 2003.

Diese Version ist zum Lernen nicht veraltet. Viele Elemente sind nach wie vornicht berall verwirklicht. Aber die Grundlagen, die in diesem Buch behandeltwerden, sind unverndert die Grundlagen beim Verstndnis von SQL.

3.2. bersicht ber Datenbankmanagementsysteme

3.2.1. Allgemein

Datenbanken sind Systeme (Daten und Programme) zur Verwaltung von Daten.Es gibt verschiedene Konzepte:

Relationale DBMS

Objektrelationale DBMS

Objektorientierte DBMS

12

bersicht ber Datenbankmanagementsysteme

Bei Wikipedia gibt es eine Liste der Datenbankmanagementsysteme.

Da SQL die Abfragesprache fr relationale Datenbanken ist, bezieht sich dasBuch nur auf diese Art von Datenbanken. Das Konzept hinter den relationalenDatenbanken wird im nchsten Kapitel erlutert.

3.2.2. Kommerzielle Datenbankmanagementsysteme

DB2

Informix

Interbase

Microsoft SQL Server

Oracle

Sybase

Microsoft und Oracle bieten auch kostenlose Express-Versionen mit einge-schrnkten Mglichkeiten oder Nutzungsrechten an.

3.2.3. Freie Datenbankmanagementsysteme

Firebird

MySQL

PostgreSQL

SQLite

Bei MySQL ist das duale Lizenzsystem zu beachten: je nach Nutzungsbedingun-gen frei oder kostenpflichtig.

Die Unterscheidung zwischen frei und kommerziell ist nicht kor-rekt. Bei den freien DBMS steht die freie Verfgbarkeit im Vorder-grund, auch wenn Kosten anfallen oder es nicht als Open Source-Projekt entwickelt wird. Bei den kommerziellen DBMS steht dasgewerbliche Interesse des Anbieters im Vordergrund, auch wenn eskostenlose Lizenzen gibt.

3.2.4. Weitere Systeme zur Datenverwaltung

Die folgenden Dateisysteme enthalten keine Datenbanken im eigentlichen Sin-ne, sondern Dateien fr strukturierte Daten. Auch diese knnen (je nach verwen-detem Programm) in eingeschrnktem Umfang mit SQL-Befehlen umgehen.

dBASE und seine Varianten

13

Einleitung

MS-Access

das Datenbankmodul Base von LibreOffice (OpenOffice.org)

Paradox

Auf diese Systeme gehen wir nicht ein. Sie mssen in der jeweiligen Programm-Dokumentation nachlesen, welche Befehle und Optionen mglich sind.

3.3. Schreibweisen im Buch

Das Buch ist grundstzlich schrittweise aufgebaut. Aber nicht immer knnen ineinem Beispiel nur bereits bekannte Begriffe verwendet werden. Wenn Bestand-teile erst in einem spteren Kapitel erlutert werden, dann gibt es ausdrcklicheHinweise, beispielsweise hier:

Der INSERT-Befehl in DML (2) Daten speichern1 muss korrekt mit Datenty-pen2 umgehen und benutzt dazu auch Funktionen3.

Auch fr das Erstellen einer Tabelle in DDL Struktur der Datenbank4 mussgenau auf die Datentypen geachtet werden.

Wenn Sie die SQL-Begriffe aus dem Englischen ins Deutsche bersetzen, solltenSie den Zusammenhang auch ohne Hin- und Herblttern verstehen.

Das Wort Statement bezeichnet einen SQL-Befehl, manchmal auch den Teil ei-nes Befehls.

Die Beispiele fr SQL-Befehle werden nach den folgenden Regeln geschrieben.

1. Alle SQL-Befehle und Schlsselwrter, wie z. B. SELECT, INSERT, DELETE,WHERE, ORDER BY, werden vorzugsweise gro geschrieben. SQL selbstverlangt das nicht, sondern arbeitet ohne Bercksichtigung von Gro- undKleinschreibung (case insensitive); dort werden select, Select und sogarsElEcT gleich behandelt.5

2. Eigentlich sollten Tabellen- und Spaltennamen vorzugsweise ebenfallsgro geschrieben werden, und zwar ohne Anfhrungszeichen. Aber in derPraxis werden solche Namen meistens gemischt geschrieben.

3. String-Literale werden mit einfachen Anfhrungszeichen gekennzeichnet.Bitte nicht wundern: Manche DBMS geben fr Namen oder Literale andereRegeln zu den Anfhrungszeichen vor.

1 Kapitel 9 auf Seite 692 Kapitel 13 auf Seite 973 Kapitel 14 auf Seite 1094 Kapitel 10 auf Seite 795 Im Buch verhindern zurzeit technische Einschrnkungen, dass alle Begriffe automatisch gro-

geschrieben werden. Wir haben uns aber durchgehend um Groschreibung bemht.

14

Siehe auch

4. SQL-Befehle werden mit einem Semikolon abgeschlossen.

5. Optionale Argumente (d. h. solche, die nicht unbedingt erforderlich sind)werden in [ ] eingeschlossen.

6. Variable Argumente (d. h. solche, die mit unterschiedlichem Inhalt vor-kommen) werden in < > eingeschlossen.

7. Wahlmglichkeiten werden durch das Pipe-Zeichen | (den senkrechtenStrich) getrennt.

8. Listen werden gekennzeichnet durch , wobei dies eine Kurz-form ist fr .

9. Sofern das Ergebnis einer Abfrage im Ausgabefenster aufgefhrt wird, han-delt es sich berwiegend nur um einen Teil des Ergebnisses, gleichgltig obdarauf hingewiesen wird oder nicht.

Die Struktur eines Befehls steht in einem Rahmen mit Courier-Schrift:

SELECT FROM

[ WHERE ];

Aufgabe: So wird eine Aufgabenstellung angezeigt, die mit dem danach fol-genden Beispiel erledigt werden soll.

Ein konkretes Beispiel wird mit einem komplexen Rahmen und unterschiedli-chen Inhalten (zustzlicher Hinweis bei Fehlern, mit oder ohne Kopf- und Fu-zeile, mit oder ohne Ausgabefenster) dargestellt:

Quelltext Falsch

SELECT * FROM BeispieltabelleWHERE Spalte1 = Abc;

Hier steht ggf. eine Meldung.

3.4. Siehe auch

Unter Weblinks6 stehen viele zustzliche Hinweise.

MoWeS7 bietet eine kostenlose PHP-MySQL-Umgebung fr den USB-Stick, diesich gut eignet, MySQL zu lernen und zu testen.

6 Anhang D auf Seite 4457 http://de.wikipedia.org/wiki/MoWeS

15

http://de.wikipedia.org/wiki/MoWeS

4. Relationale Datenbanken

4.1. Grundstruktur relationaler Datenbanken . . . . . . . . . . . . 17

4.2. Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3. Spalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4. Verknpfungen und Schlssel . . . . . . . . . . . . . . . . . . . . 22

4.5. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Um mit SQL auf relationalen Datenbanken zu arbeiten, muss der Anwender einGrundverstndnis dafr haben. Dieses soll hier vermittelt werden.

4.1. Grundstruktur relationaler Datenbanken

Bevor man mit der Sprache SQL beginnt, muss das Grundprinzip relationalerDatenbanken geklrt werden. Diese versuchen, einen Bestandteil der Realitt ineinem Datenmodell abzubilden. Fr diese Datenmodelle gibt es verschiedeneAbstraktionsebenen. In der Regel unterscheidet man zwischen Entittenmodellund Tabellenmodell. Da es sich hier um eine Einfhrung handelt, beschrnkenwir uns auf das Tabellenmodell, das weniger Theorie voraussetzt.

Grundstzlich sollen Objekte der Realitt betrachtet werden, welche zueinanderin Beziehung stehen. Zum einen werden die Objekte mit ihren Eigenschaften un-tersucht: Objekte mit gleichen Eigenschaften werden zusammengefasst; Objek-te mit verschiedenen Eigenschaften werden getrennt. Zum anderen werden dieBeziehungen zwischen unterschiedlichen Objekten behandelt. Auerdem gehtes darum, mglichst keine Informationen unntigerweise doppelt zu speichern.

4.1.1. Beispielhafte Struktur

In unserer Beispieldatenbank1 simulieren wir dazu eine Versicherungsgesell-schaft. Unter anderem werden die Vertrge mit den dazugehrigen Kunden be-trachtet:

1 Kapitel 6 auf Seite 39

17

Relationale Datenbanken

Ein Versicherungsvertrag ist durch die Vertragsnummer, das Datum des Ab-schlusses, den Versicherungsnehmer, die Art und die Hhe der Police gekenn-zeichnet.

Ein Versicherungsnehmer kann bei der Versicherung einen oder mehrere Ver-trge haben. Es kann Kunden geben, die aktuell keinen Vertrag haben; aber eskann keinen Vertrag ohne zugehrigen Kunden geben.

Ein Versicherungsnehmer ist gekennzeichnet durch seinen Namen und An-schrift und bei Personen einen Vornamen und ein Geburtsdatum. Auerdemverfgt er blicherweise ber eine Kundennummer, die ihn eindeutig kenn-zeichnet.

Nun knnte man alle Vertrge wie folgt in einer einzigen Datei, z. B. einemArbeitsblatt einer Tabellenkalkulation, speichern:

NUMMER ABSCHLUSSDATUM ART NAME ANSCHRIFTBETREUER TELEFON

DG-01 03.05.1974 TK Heckel Obsthandel GmbH 46282 DorstenPohl, Helmut 0201/4014186 Mobil (0171) 4123456



XC-01 07.08.1974 HP Antonius, Bernhard 45892 GelsenkirchenBraun, Christian 0201/4014726 Mobil (0170) 8351647

RH-01 11.12.1976 VK Cornelsen, Dorothea 44577 Castrop-RauxelBraun, Christian 0201/4014726 Mobil (0170) 8351647

Dies ist offensichtlich unbersichtlich. Auch werden die persnlichen Dateneines Versicherungsnehmers und seines Betreuers zu oft gespeichert. Es istalso sinnvoll, dies zu trennen zum einen die Vertrge:

NUMMER ABSCHLUSSDATUM ART KUNDE BETREUERDG-01 03.05.1974 TK 1 9DG-02 11.06.1975 TK 1 9DG-03 25.02.1977 TK 1 9XC-01 07.08.1974 HP 2 10RH-01 11.12.1976 VK 3 10

Zum anderen die Kunden:

NUMMER NAME ANSCHRIFT1 Heckel Obsthandel GmbH 46282 Dorsten2 Antonius, Bernhard 45892 Gelsenkirchen3 Cornelsen, Dorothea 44577 Castrop-Rauxel

18

Grundstruktur relationaler Datenbanken

Und schlielich die zustndigen Sachbearbeiter (Betreuer):

NUMMER NAME TELEFON MOBIL9 Pohl, Helmut 0201/4014186 (0171) 4123456

10 Braun, Christian 0201/4014726 (0170) 8351647

Durch die Angabe der Nummer (Kunde bzw. Betreuer) in den Aufstellungen isteine klare Verbindung hergestellt. Auerdem zeigt die Wiederholung des WortesMobil an, dass dieser Wert in einer eigenen Spalte eingetragen werden sollte.

Diese Trennung der Daten erfolgt bei der Normalisierung2 einer Datenbank.

4.1.2. Eigenschaften der Objekte

Vor allem mssen wir ber die Eigenschaften der verschiedene Objekte nach-denken. Es gibt solche, die ein Objekt eindeutig kennzeichnen, andere, die im-mer anzugeben sind, und weitere, die nur manchmal wichtig sind.

Fr einen Versicherungsnehmer gibt es u. a. folgende Eigenschaften:

NUMMER ist eindeutig und eine Pflichtangabe.

NAME, PLZ, ORT sind Pflichtangaben, ihre Inhalte knnen aber bei mehrerenVersicherungsnehmern vorkommen.

VORNAME und GEBURTSDATUM sind bei natrlichen Personen Pflicht, aberbei juristischen Personen (Firmen) irrelevant.

Fr einen Versicherungsvertrag gibt es u. a. folgende Eigenschaften:

NUMMER ist eindeutig und eine Pflichtangabe.

Auch die anderen bisher genannten Eigenschaften sind Pflicht, aber sie sindnicht eindeutig.

Die verschiedenen Objekte stehen ber die Kundennummer miteinander inBeziehung. Im Beispiel geht es um die Verknpfung: Ein Kunde kann einenoder mehrere Vertrge oder auch keinen haben. Der letzte Fall keinen Vertragkommt erst am Schluss des Buches vor, wenn wir weitere Testdaten erzeugen3.

In einem relationalen Datenbanksystem (DBMS) werden die Objekte als Tabel-len dargestellt. Die Eigenschaften werden ber die Spalten der Tabelle abgebil-det. Eine Zeile (wahlweise als Datensatz bezeichnet) in der Tabelle entsprichtgenau einem Objekt in der Realitt. Die Beziehungen zwischen Tabellen werdenber Fremdschlssel abgebildet.

2 Kapitel 5 auf Seite 253 Kapitel 36 auf Seite 407

19


4.2. Tabellen

Tabellen sind zweidimensional gegliederte Informationen. Die Tabelle selbst hateinen Namen. Anzahl, Bezeichnung und Typ der Spalten (auch Felder oder Attri-bute genannt) werden durch die Tabelle definiert. Die Zeilen (Anzahl und Inhal-te) sind variabel und entsprechen jeweils einem wirklichen Objekt des Typs, derin der Tabelle gesammelt wird.

So sieht ein Ausschnitt aus der Tabelle Abteilung der Beispieldatenbank aus:

Spaltenname ID KURZBEZEICHNUNG BEZEICHNUNG ORTDatentyp integer varchar(10) varchar(30) varchar(30)Zeilen 1 Fibu Finanzbuchhaltung Dortmund

2 Albu Anlagenbuchhaltung Dortmund5 Vert Vertrieb Essen6 Lagh Lagerhaltung Bochum

Sie enthlt also 4 Spalten und 12 Zeilen, von denen hier 4 angezeigt werden.

Dabei handelt es sich um eine Basistabelle (TABLE), die tatschlich Informatio-nen speichert. Daneben gibt es virtuelle Arten von Tabellen, nmlich die VIEWals Sichttabelle und die Ergebnismenge (Resultset) als Ergebnis einer SELECT-Abfrage.

Eine View enthlt eine fest vordefinierte Abfrage, die sich auf eine oder mehre-re Tabellen bezieht. Aus Sicht des Anwenders sieht sie wie eine Basistabelle aus,ist aber nur eine Abbildung realer Tabellen. Ein Beispiel wre ein Ausschnitt auseiner View Mitarbeiter_Bochum, nmlich der Mitarbeiter, die zu einer der Abtei-lungen in Bochum gehren:

PERSNR NAME VORNAME BEZEICHNUNG60001 Aagenau Karolin Lagerhaltung60002 Pinkart Petra Lagerhaltung70001 Olschewski Pjotr Produktion70002 Nordmann Jrg Produktion120001 Carlsen Zacharias Forschung und Entwicklung120002 Baber Yvonne Forschung und Entwicklung

Nheres zu Sichttabellen steht im Kapitel Erstellen von Views4.

Jede Ergebnismenge hat zwangslufig die Struktur einer Tabelle.

Ergnzend sei darauf hingewiesen, dass auch das DBMS selbst smtliche Sche-mata in Systemtabellen speichert. Beispielsweise stehen bei Interbase und Fire-bird die Definition von TABLEs und VIEWs in der Tabelle RDB$RELATIONS unddie dazugehrigen Felder (Spalten) in RDB$RELATION_FIELDS.


20

Spalten

4.3. Spalten

Spalten bezeichnen die Elemente einer Tabellenstruktur. Sie werden eindeutiggekennzeichnet durch ihren Namen; diese Eindeutigkeit gilt innerhalb einer Ta-belle, verschiedene Tabellen drfen Spalten mit gleichem Namen (z. B. ID) ha-ben. Auerdem gehrt zur Definition einer Spalte der Datentyp; dies wird imKapitel Datentypen5 behandelt.

Die Spalten (innerhalb einer Tabelle) werden intern nach Position geordnet.Spalten an verschiedenen Positionen knnen denselben Datentyp haben, aberniemals denselben Namen. Auf eine bestimmte Spalte wird fast immer ber denNamen zugegriffen, nur uerst selten ber die Position.

Eine Spalte hat also einen Namen und einen Datentyp. Jede Zeile in einer Tabellehat genau einen Wert fr jede Spalte; wenn mehrere gleichartige Werte eingetra-gen werden sollen, werden mehrere Spalten bentigt. Jeder Wert in einer Zeileentspricht dem Datentyp der Spalte.

Hinweis: In dieser Hinsicht unterscheiden sich Datenbank-Tabellenganz wesentlich von denjenigen einer Tabellenkalkulation, bei derder Datentyp einzelner Zellen abweichen kann von der Spaltendefi-nition und einzelne Zellen zusammengezogen werden knnen.

Die Eigenschaft NULL fr einen Wert ist eine Besonderheit, die vor allem Einstei-ger gerne verwirrt. Dies bedeutet, dass einer Zelle (noch) kein Wert zugeordnetworden ist. Eine bessere Bezeichnung wre etwas wie UNKNOWN; aber es heitnun leider NULL. Bitte beachten Sie deshalb:

Fr ein Textfeld werden folgende Werte unterschieden:

1. Der Wert ist ein leerer Text.

2. Der Wert ist ein Text, der genau ein Leerzeichen enthlt.

3. Der Wert NULL enthlt nichts.

Fr ein logisches Feld (Datentyp boolean) wird dies unterschieden:

1. Der Wert TRUE bedeutet wahr.

2. Der Wert FALSE bedeutet falsch.

3. Der Wert NULL bedeutet unbekannt.

Fr ein Zahlenfeld wird es so unterschieden:

1. Der Wert 0 ist eine bestimmte Zahl, genauso gut wie jede andere.

2. Der Wert NULL bedeutet unbekannt.


21


i HinweisDer Wert NULL steht nicht fr einen bestimmten Wert, sondern kannimmer als unbekannt interpretiert werden.

Dies kann bei jeder Spalte allgemein festgelegt werden: Die Eigenschaft NOTNULL bestimmt, dass in dieser Spalte der NULL-Wert nicht zulssig ist; wennDaten gespeichert werden, muss immer ein Wert eingetragen werden (und sei esein leerer Text). Wenn dies nicht festgelegt wurde, muss kein Wert eingetragenwerden; der Feldinhalt ist dann NULL.

Bei SELECT-Abfragen (vor allem auch bei Verknpfungen mehrerer Tabellen)gibt es unterschiedliche Ergebnisse je nachdem, ob NULL-Werte vorhanden sindund ob sie bercksichtigt oder ausgeschlossen werden sollen.

4.4. Verknpfungen und Schlssel

Mit diesen Verfahren werden die Tabellen in Beziehung zueinander gebracht.Auch dies folgt der Vorstellung, dass die Wirklichkeit abgebildet werden soll.

4.4.1. Verknpfungen

Diese, nmlich die Beziehungen zwischen den Tabellen, sind ein Kern eines rela-tionalen Datenbanksystems. In der Beispieldatenbank6 bestehen unter anderemfolgende Beziehungen:

Die Tabelle Mitarbeiter verweist auf folgende Tabelle:

1. Jeder Mitarbeiter gehrt zu einem Eintrag der Tabelle Abteilung.

Die Tabelle Zuordnung_SF_FZ verbindet Schadensflle und Fahrzeuge undverweist auf folgende Tabellen:

1. Jedes beteiligte Fahrzeug gehrt zu einem Eintrag der Tabelle Fahrzeug.

2. Jeder Schadensfall muss in der Tabelle Schadensfall registriert sein.

Die Tabelle Versicherungsvertrag verweist auf folgende Tabellen:

1. Jeder Vertrag wird von einer Person aus der Tabelle Mitarbeiter bearbeitet.

2. Zu jedem Vertrag gehrt ein Eintrag der Tabelle Fahrzeug.

3. Zu jedem Vertrag gehrt ein Eintrag der Tabelle Versicherungsnehmer.

6 Anhang A auf Seite 419

22

Verknpfungen und Schlssel

Durch diese Verknpfungen werden mehrere Vorteile erreicht:

Informationen werden nur einmal gespeichert.Beispiel: Der Name und Sitz einer Abteilung muss nicht bei jedem Mitarbeiternotiert werden.

nderungen werden nur einmal vorgenommen.Beispiel: Wenn die Abteilung umzieht, muss nur der Eintrag in der Tabelle Ab-teilung gendert werden und nicht die Angaben bei jedem Mitarbeiter.

Der Zusammenhang der Daten wird gewhrleistet.Beispiel: Ein Versicherungsnehmer kann nicht gelscht werden, solange ernoch mit einem Vertrag registriert ist.

Damit dies verwirklicht werden kann, werden geeignete Manahmen bentigt:

1. Jeder Datensatz muss durch einen Schlssel eindeutig identifiziert werden.

2. Die Schlssel der verschiedenen miteinander verknpften Datenstzemssen sich zuordnen lassen.

4.4.2. Schlssel

PrimaryKey (PK): Der Primrschlssel ist eine Spalte in der Tabelle, durch dieeindeutig jede Zeile identifiziert wird (gerne mit dem Namen ID). Es kann aucheine Kombination von Spalten als eindeutig festgelegt werden; das ist aber seltensinnvoll. In der Regel sollte diese Spalte auch keine andere inhaltliche Bedeu-tung haben als die ID.

Beispiele: Die Kombination Name/Vorname kann bei kleinen Daten-mengen zwar praktisch eindeutig sein, aber niemals theoretisch; ir-gendwann kommt ein zweiter Lucas Mller, und dann? Bei einemMehrbenutzersystem werden hufig mehrere Eintrge gleichzeitiggespeichert; es ist besser, wenn das DBMS die Vergabe der ID selbststeuert, als dass die Benutzer sich absprechen mssen. In der Bei-spieldatenbank wird deshalb in der Tabelle Mitarbeiter zwischen derautomatisch vergebenen ID und der ebenfalls eindeutigen Personal-nummer unterschieden.

ForeignKey (FK): ber Fremdschlssel werden die Tabellen miteinander ver-knpft. Einem Feld in der einen Tabelle wird ein Datensatz in einer anderen Ta-belle zugeordnet; dieser wird ber den Primrschlssel bereitgestellt. Es kannauch eine Kombination von Spalten verwendet werden; da sich der Fremd-schlssel aber auf einen Primrschlssel der anderen Tabelle beziehen muss, istdies ebenso selten sinnvoll. Die Datenbank-Theorie geht sogar soweit, dass dieSchlsselfelder dem Anwender gar nicht bekannt sein mssen.

23


Beispiele stehen in der obigen Aufstellung. Nhere Erluterungensind im Kapitel Fremdschlssel-Beziehungen7 zu finden.

Index: Er dient dazu, einen Suchbegriff schnell innerhalb einer Tabelle zu fin-den. Die Mehrzahl lautet nach Duden Indizes, auch Indexe ist mglich; in derEDV wird oft auch der englische Plural Indexes verwendet. Dies gehrt zwar nichtzum Kernbereich eines relationalen DBMS, passt aber (auch wegen der um-gangssprachlichen Bedeutung des Wortes Schlssel) durchaus hierher.

Der Primrschlssel ist ein Suchbegriff, mit dem eindeutig ein Datensatz ge-funden werden kann.

Mit einem Index kann die Suche nach einem bestimmten Datensatz oder einerDatenmenge beschleunigt werden.Beispiel: die Suche nach Postleitzahl

Die Werte einer Spalte oder einer Kombination von Spalten sollen eindeutigsein.Beispiel: die Personalnummer

Nhere Erluterungen sind in den Kapiteln im Teil Erweiterungen ab DDL Ein-zelheiten8 zu finden.

4.5. Siehe auch

ber Wikipedia sind weitere Informationen zu finden:

Relationale Datenbank9

Entittenmodell10 und Entity-Relationship-Modell11

Normalisierung 12

Tabellenkalkulation13 im Gegensatz zu Datenbank-Tabellen

Nullwert14

7 Kapitel 29 auf Seite 3058 Kapitel 28 auf Seite 2859 http://de.wikipedia.org/wiki/Relationale%20Datenbank10 http://de.wikipedia.org/wiki/Entit%c3%a4t%20(Informatik)11 http://de.wikipedia.org/wiki/Entity-Relationship-Modell12 http://de.wikipedia.org/wiki/Normalisierung%20(Datenbank)13 http://de.wikipedia.org/wiki/Tabellenkalkulation14 http://de.wikipedia.org/wiki/Nullwert

24

http://de.wikipedia.org/wiki/Relationale%20Datenbankhttp://de.wikipedia.org/wiki/Entit%c3%a4t%20(Informatik)http://de.wikipedia.org/wiki/Entity-Relationship-Modellhttp://de.wikipedia.org/wiki/Normalisierung%20(Datenbank)http://de.wikipedia.org/wiki/Tabellenkalkulationhttp://de.wikipedia.org/wiki/Nullwert

5. Normalisierung

5.1. Grundgedanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2. Die 1. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3. Die 2. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4. Die 3. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.5. Zustzliche Manahmen . . . . . . . . . . . . . . . . . . . . . . . 34

5.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.7. Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

In diesem Kapitel werden einige berlegungen angestellt, wie eine Datenbankkonzipiert werden soll.

Dieses Kapitel geht zwar ber die Anforderungen einer Einfhrung hinaus. Dennes richtet sich weniger an einfache Anwender, die eine vorhandene Datenbankbenutzen wollen, sondern an (knftige) Programmentwickler, die eine Daten-bank entwerfen und erstellen. Aber wann soll man darber sprechen, wenn nichtam Anfang?

5.1. Grundgedanken

Schon das einfache Muster einer unzureichenden Tabelle wie im vorigen Kapitelweist auf ein paar Forderungen hin, die offensichtlich an eine sinnvolle Strukturgestellt werden sollten:

Redundanz vermeiden: Eine Information, die an mehreren Stellen bentigtwird, soll nur einmal gespeichert werden. Dadurch mssen auch smtli-che nderungen, die solche Informationen betreffen, nur an einer Stelleerledigt werden.

Im Beispiel waren das u. a. die Angaben zum Fahrzeughalter und zumSachbearbeiter (mit seinen Telefonnummern), die bei jedem Vertrag an-gegeben werden.

Wiederholungen trennen: Die Zusammenfassung gleichartiger Informationenist nicht sehr bersichtlich. Im vorigen Kapitel standen zunchst Festnetz-und Mobil-Rufnummer in einer Spalte. Das ist praktisch, wenn man sich

25

Normalisierung

keine Gedanken machen will, welche und wie viele Kontaktnummern esgibt. Es ist ziemlich unpraktisch, wenn man gezielt einzelne Nummern su-chen will oder von einer Nummer auf den Sachbearbeiter schlieen will.Besser sind Festnetz- und Mobilnummer getrennt zu speichern.

Primrschlssel verwenden: Jeder Datensatz muss eindeutig identifiziert wer-den, damit die Informationen verwendet werden knnen.

In der ungengenden Tabelle wurde wegen der Zeilennummern daraufverzichtet. Aber selbst wenn man die Suche in zigtausend Zeilen fr mach-bar hielte, sptestens bei der Aufteilung in mehrere Tabellen braucht manWerte, um die Zusammenhnge eindeutig zu regeln.

Bei den bisherigen berlegungen handelt es sich nur um ein paar Gedanken, diesich einem aufdrngen. Das wollen wir nun besser strukturieren. berlegen wiruns zunchst, welche Informationen bentigt werden.

Grundlegende Daten

Fr die Vertrge mssen die folgenden Angaben gespeichert werden.

die Vertragsdaten selbst, also Nummer, Abschlussdatum und Art des Vertrags(HP = Haftpflicht, TK = Teilkasko, VK = Vollkasko) und der Prmienberechnung

der Vertragspartner mit Name, Anschrift, Telefonnummern, dazu bei natrli-chen Personen Geschlecht und Geburtsdatum sowie bei juristischen Personender Eintrag im Handelsregister o. .

das versicherte Fahrzeug mit Kennzeichen, Hersteller und Typ (die Farbe isteine Zusatzinformation, die bei manchen Suchvorgngen hilfreich sein kann)

der zustndige Sachbearbeiter mit Name, Abteilung und Telefonnummern

Ein Teil der Angaben muss immer vorhanden sein, ein anderer Teil je nach Situa-tion (Geschlecht bei Personen) und weitere nur bei Bedarf (Mobiltelefon).

Schnell stellen wir fest, dass ein Versicherungsnehmer auch mehrere Fahrzeugeversichern kann. Andererseits kann ein Fahrzeug zu mehreren Vertrgen geh-ren, wenn Haftpflicht und Vollkasko getrennt abgeschlossen werden oder wennzur Haftpflicht vorbergehend Vollkasko frs Ausland hinzukommt. Jeder Ver-trag ist ein eigener Datensatz; also stehen bei jedem Datensatz die Angaben desVertragspartners und des Fahrzeugs. Um alle Vertrge eines Kunden gemeinsamanzuzeigen, brauchen wir folglich ein paar Angaben zur Organisation:

Kundennummer und laufende Nummer seiner Vertrge als eindeutiger Such-begriff (als Index, vielleicht auch als Primrschlssel)

Vertragsnummer als eindeutiger Wert

Fahrzeug-Kennzeichen als Wert, der in der Regel nur einmal vorkommt

26

Grundgedanken

Schadensflle

Nun sollen zu einem Vertrag auch die Schadensflle gespeichert werden. Wir be-ntigen also eine oder mehrere Spalten mit den erforderlichen Angaben (Datumund Art des Schadens, Sachbearbeiter der Schadensabwicklung, andere beteilig-te Fahrzeuge); aber wie wird das am besten gespeichert?

eine gemeinsame Spalte fr alle diese Angaben fr alle Schadensflle (denn dieMehrzahl der Fahrzeuge fhrt schadensfrei)

oder je eine Spalte fr alle Angaben eines Schadensfalls (werden dann zweioder drei Spalten bentigt, oder muss man fr Mehrfach-Snder gleich zehnSpalten vorsehen?)

oder einzelne Datenstze fr jeden Schaden eines Fahrzeugs (sodass sich alleFahrzeug- und Vertragsdaten in diesen Datenstzen wiederholen und nur dieSchadensangaben unterscheiden)

Ungeklrt bleibt dabei noch dieses Problem: Wie viele versicherte Schadensgeg-ner gibt es denn keine (wenn ein Reh angefahren wird), einen (z. B. beim Par-ken) oder viele (bei einem Auffahrunfall auf der Autobahn)?

Entscheiden wir uns deshalb provisorisch fr ein eigenes Arbeitsblatt Schadens-flle mit folgender Struktur:

je eine Spalte fr die Angaben, die direkt zum Schadensfall gehren

vorlufig 5 Gruppen fr maximal 5 beteiligte Fahrzeuge

jede dieser Gruppen enthlt in einzelnen Spalten Fahrzeug-Kennzeichen unddie Halter-Angaben (Name, Anschrift)

Damit stehen die Fahrzeugdaten in beiden Arbeitsblttern. Als praktisches Pro-blem kommt hinzu: Fr die Schadenshufigkeit eines Fahrzeugs muss man es infnf Spalten heraussuchen. Die Beschrnkung auf fnf beteiligte Fahrzeuge wirdim nchsten Schritt aufgelst, machen wir uns dazu keine weiteren Gedanken.

Auf diesem Weg kann jedenfalls noch keine sinnvolle Struktur erreicht werden.

Update-Anomalien

Mit diesem Begriff werden die folgenden Unklarheiten bezeichnet. Dabei han-delt es sich um weitere Probleme bei einer ungengenden Struktur.

Einfgen-Anomalie: In der ersten Tabelle sind u. a. die Sachbearbeiter enthal-ten. Es wre sinnvoll, auch alle anderen Mitarbeiter der Gesellschaft hiereinzutragen. Aber bei einem Vertrag werden zwingend Vertragsnummerund Abschlussdatum bentigt; dieser Zwang verhindert das Speichern derTeilinformation Sachbearbeiter ohne Bezug auf einen Vertrag.

27

Normalisierung

Lschen-Anomalie: Wenn ein Vertrag gekndigt und abgelaufen ist und des-halb gelscht wird, sind in der ersten Tabelle auch alle Angaben zum Ver-tragspartner verloren. Wenn er drei Tage spter einen neuen Vertrag ab-schliet, mssen alle Angaben neu aufgenommen werden. Und was sollmit Schadensfllen geschehen, die zu diesem Vertrag gespeichert sind?

ndern-Anomalie: Wenn der Sachbearbeiter wechselt, muss sein Name bei al-len von ihm betreuten Vertrgen gendert werden, obwohl eine einzige n-derung ausreichend wre. (Dies ist auf die Datenredundanz zurckzufh-ren, dass nmlich dieser Hinweis vielfach gespeichert ist statt einmalig.)

All diesen Problemen wollen wir nun durch eine deutlich verbesserte Daten-struktur begegnen. Nehmen wir dazu zunchst an, dass alle bentigten Infor-mationen in den beiden Arbeitsblttern Vertrge und Schadensflle der Tabel-lenkalkulation stehen, und beginnen wir, dies sinnvoll zu strukturieren.

5.2. Die 1. Normalform

Am grausamsten fr den Aufbau der Tabelle und die praktische Arbeit ist dievielfache Wiederholung gleicher Informationen.

Sowohl beim Namen des Fahrzeughalters als auch bei den Mitarbeitern steht derName bisher in einer Spalte in der Form Nachname, Vorname, was als Suchbe-griff geeignet ist. Nun bentigen wir aber auch eine persnliche Anrede (Namemit Titel) und eine Briefanschrift (Vorname, Name). Soll dies in weiteren Spaltengespeichert werden? Nein, denn all dies kann aus den Einzelangaben Nameund Vorname zusammengesetzt werden.

Ein Schadensfall ist bisher auf fnf beteiligte Fahrzeuge beschrnkt, auch wennselten mehr als zwei Beteiligungen bentigt werden. Wenn nun ein sechstes,zehntes oder zwanzigstes Fahrzeug beteiligt ist, muss dann jedesmal die Tabel-lenstruktur (und jedes Makro, das auf diese Spalten zugreift) gendert werden?!

Damit haben wir bereits zwei Regeln, die als Definition der ersten Normalformgelten. Hinzu kommt eine dritte Regel, die zwar formal nicht erforderlich ist; aberaus praktischen Grnden gibt es keine sinnvolle Lsung ohne diese Regel.

i Die 1. Normalform1. Jede Spalte enthlt nur unteilbare (atomare, atomische) Werte.2. Spalten, die gleiche oder gleichartige Informationen enthalten, sind ineigene Tabellen (Relationen) auszulagern.3. Jede Tabelle enthlt einen Primrschlssel.

28

Die 1. Normalform

Verletzung der 1. Normalform

Unsere Ausgangstabelle verstt an vielen Stellen gegen diese Regeln:

Zusammengesetzte Werte befinden sich z. B. an folgenden Stellen:

Fahrzeughalter: Name und Vorname, PLZ und Ort, Strae und Nummer

Sachbearbeiter: Name und Vorname, Festnetz- und Mobilnummer

Wiederholungen finden sich vor allem hier:

mehrere Fahrzeuge bei einem Schadensfall

Vorgehen zur Herstellung der 1. Normalform

Es werden also zwei Schritte bentigt:

1. Zusammengesetzte Werte werden in Einzelinformationen aufgeteilt: jeeine Spalte fr jeden unteilbaren Wert.

2. Wiederholungen werden in getrennte Tabellen ausgelagert; welche Datenzusammengehren, wird durch eine laufende Nummer angegeben.

Eine erste Verbesserung

An jeder Stelle, die Namen oder Anschrift enthlt, werden getrennte Spalten ver-wendet, beispielsweise im Arbeitsblatt Vertrge:

Kundennummer Vertrag Abschluss Halter_Name Halter_PLZ Halter_OrtSachbearbeiter_N Sachbearbeiter_V Telefon

1 DG-01 03 05 1974 Heckel Obsthandel GmbH 46282 DorstenPohl Helmut 0201/4014186

1 DG-02 04 07 1974 Heckel Obsthandel GmbH 46282 DorstenPohl Helmut 0201/4014186

Die Tabelle Schadensflle wird auf die eigentlichen Daten beschrnkt; die betei-ligten Fahrzeuge stehen in einer eigenen Tabelle Zuordnungen.

Nummer Datum Schadensort BeschreibungSachbearbeiter_N Sachbearbeiter_V Telefon

1 02 03 2007 Recklinghausen, Bergknappenstr 144 Gartenzaun gestreiftSchindler Christina 0201/4012151

2 11 07 2007 Haltern, Hauptstr 46 beim Ausparken hat ...Aliman Zafer 0201/4012161

Die Anzahl der beteiligten Fahrzeuge an einem Schadensfall wird durch eine ei-gene Tabelle Zuordnungen bercksichtigt:

29

Normalisierung

Nummer Fahrzeug Hersteller Typ Halter_Name Halter_VornameHalter_PLZ Halter_Ort Halter_Strae

1 RE-LM 902 Opel Corsa Heckel Obsthandel GmbH46282 Dorsten Gahlener Str 40

2 BO-GH 102 Volvo C30 Geissler Helga44809 Bochum Steinbankstr 15

2 RE-CD 456 Renault Twingo Cornelsen Dorothea44577 Castrop-Rauxel Kiefernweg 9

Die Zusatzbedingung eines Primrschlssels wurde gleichzeitig erfllt; die be-treffenden Spalten wurden unterstrichen.


Eine weitere Wiederholung in den Monster-Tabellen sind die Angaben zumHalter bei den Vertrgen und den Zuordnungen oder die Fahrzeugdaten sowohlbei den Vertrgen als auch bei den Zuordnungen. Auch diese werden in eigeneTabellen ausgelagert; das ergibt sich als Definition aus der folgenden Regel:

i Die 2. Normalform1. Die Tabelle erfllt die 1. Normalform.2. Alle Informationen in den Spalten, die nicht Teil des Primrschlsselssind, mssen sich auf den gesamten Primrschlssel beziehen.

Man sagt auch, dass die Informationen funktional abhngig sind von der Ge-samtheit der Schlsselwerte. Umgekehrt formuliert bedeutet es: Wenn eine Spal-te nur zu einem einzelnen Schlsselfeld gehrt, ist die 2. Normalform nicht er-fllt.

Whrend sich die 1. Normalform auf die einzelnen Spalten und Wiederholungeninnerhalb eines Datensatzes bezieht, befasst sich die 2. Normalform mit Wieder-holungen bei verschiedenen Datenstzen.


Unsere derzeitigen Tabellen verstoen mehrfach gegen diese Regel:

Bei den Vertrgen beziehen sich Name und Anschrift des Vertragspartners nurauf die Kundennummer, aber nicht auf die Vertragsnummer.

30

Die 2. Normalform

Bei den Vertrgen stehen auch die Fahrzeugdaten. (Dies wurde bei der Be-schreibung der grundlegenden Daten erwhnt, fehlt aber in den bisherigenBeispielen.) Diese beziehen sich auf die Vertragsnummer, haben aber nur in-direkt etwas mit Name und Anschrift des Vertragspartners zu tun.

Bei den Zuordnungen der Schadensflle gehren Fahrzeug- und Halterdatennur zu einem Fahrzeug (dem Kennzeichen), aber nicht zu einem Schadensfall.


Alle unpassenden Informationen gehren in eigene Tabellen. Der Primr-schlssel bezieht sich nur auf die eigentlichen Informationen einer Tabelle.

Aus den Vertrgen werden alle Angaben des Vertragspartners entfernt undin eine Tabelle Versicherungsnehmer bertragen. Der Primrschlssel bestehtnur noch aus der Spalte Vertrag. Die Spalte Kundennummer ist nur noch einFremdschlssel zur Verknpfung mit der neuen Tabelle Versicherungsnehmer.

Aus den Vertrgen werden alle Angaben des Fahrzeugs entfernt und in eineneue Tabelle Fahrzeuge bertragen. Das Fahrzeug-Kennzeichen ist hier nurnoch ein Fremdschlssel als Verweis auf die Tabelle Fahrzeuge.

Aus den Zuordnungen werden alle Angaben der Fahrzeuge entfernt und in eineTabelle Fahrzeuge bertragen. Die Tabelle Zuordnungen besteht nur noch ausden Spalten des Primrschlssels.

Damit stehen die Fahrzeugdaten nur noch in einer Tabelle sowohl fr die Ver-trge als auch fr die Schadensflle (genauer: die Zuordnungen).

Eine zweite Verbesserung

Die ursprngliche Tabelle Vertrge beschrnkt sich jetzt auf diese Angaben:

Vertrag Abschluss Typ Kd-Nr Fahrzeug Sachb_N Sachb_V TelefonDG-01 03.05.1974 HP 1 RE-LM 901 Pohl Helmut 0201/4014186DG-02 04.07.1974 HP 1 RE-LM 902 Pohl Helmut 0201/4014186

Die neue Tabelle Versicherungsnehmer umfasst dessen Daten:

Kd-Nr Name Vorname Geburtsdatum PLZ Ort Strae Nr1 Heckel Obsthandel GmbH 46282 Dorsten Gahlener Str. 405 Geissler Helga 13.01.1953 44809 Bochum Steinbankstr. 15

Die neue Tabelle Fahrzeuge umfasst nur noch die Daten, die sich auf das Fahr-zeug selbst beziehen. Name und Anschrift des Fahrzeughalters werden durch dieKundennummer, also den Verweis auf die Tabelle Versicherungsnehmer ersetzt.

31

Normalisierung

Fahrzeug Hersteller Typ Farbe HalterRE-LM 902 Opel Corsa ocker 1BO-GH 102 Volvo C30 rot 5RE-CD 456 Renault Twingo ocker 3

Die Tabelle Schadensflle muss nicht angepasst werden. Die Tabelle Zuordnun-gen vereinfacht sich radikal:

Nummer Fahrzeug1 RE-LM 9022 BO-GH 1022 RE-CD 456

Die 2. Normalform kann ganz einfach dadurch gewhrleistet werden, dass sichder Primrschlssel nur auf eine Spalte bezieht.


Beseitigen wir noch die brigen Wiederholungen, nmlich die Sachbearbeiterbei Vertrgen und Schadensfllen sowie die Hersteller bei Fahrzeugen. Diesekommen ebenfalls in eigene Tabellen gem Definition nach folgender Regel:

i Die 3. Normalform1. Die Tabelle erfllt die 2. Normalform.2. Informationen in den Spalten, die nicht Teil des Primrschlssels sind,drfen funktional nicht voneinander abhngen.

Die 3. Normalform befasst sich also mit Wiederholungen bei verschiedenen Da-tenstzen, die nur zustzliche Informationen bereitstellen.


Unsere derzeitigen Tabellen verstoen in folgender Hinsicht gegen diese Regel:

Name, Vorname und Telefonnummer eines Sachbearbeiters hngen vonein-ander ab. Sie haben aber nur insgesamt etwas mit dem Vertrag bzw. dem Scha-densfall zu tun, nicht als einzelne Information.

Hersteller und Typ eines Fahrzeugs hngen voneinander ab. Sie haben abernur insgesamt etwas mit dem Fahrzeug zu tun, nicht als einzelne Information.

32

Die 3. Normalform

Eine andere Erklrung dafr ist, dass die Zusatzinformation auch ohne Bezugzum eigentlichen Datensatz gltig bleibt. Der Sachbearbeiter gehrt zum Un-ternehmen unabhngig von einem bestimmten Vertrag. Der Fahrzeugherstellerexistiert unabhngig davon, ob ein bestimmtes Fahrzeug noch fhrt oder inzwi-schen verschrottet worden ist.


Alle unpassenden Informationen kommen wieder in eigene Tabellen. IhreSpalten werden ersetzt durch einen Fremdschlssel zur Verknpfung mit derneuen Tabelle.

Aus den Vertrgen und den Schadensfllen werden alle Angaben zum Sachbe-arbeiter entfernt und in eine Tabelle Mitarbeiter bertragen. Die Spalte Sach-bearbeiter verweist als Fremdschlssel auf die neue Tabelle Mitarbeiter.

Dies lst automatisch auch das oben erwhnte Problem: Wir knnennun alle Mitarbeiter in einer gemeinsamen Tabelle speichern.

Aus den Fahrzeugen werden alle Angaben zu Hersteller und Typ entfernt undin eine neue Tabelle Fahrzeugtypen bertragen. Die Spalten Hersteller und Typwerden ersetzt durch einen Fremdschlssel zur Verknpfung mit der TabelleFahrzeugtypen.

Um es korrekt zu machen, gehrt der Hersteller in eine weitere Ta-belle Fahrzeughersteller; in der Tabelle Fahrzeugtypen verweist er alsFremdschlssel auf diese weitere Tabelle.

Eine weitere Verbesserung

Die Tabellen Vertrge und Schadensflle werden also nochmals vereinfacht:

Vertrag Abschluss Typ Kundennummer Fahrzeug SachbearbeiterDG-01 03.05.1974 HP 1 RE-LM 901 9DG-02 04.07.1974 HP 1 RE-LM 902 9

Nummer Datum Schadensort Beschreibung Sachbearb1 02.03.2007 Recklinghausen, Bergknappe... Gartenzaun gestreift 142 11.07.2007 Haltern, Hauptstr. 46 beim Ausparken hat ... 15

Hinzu kommt die neue Tabelle Mitarbeiter:

Nummer Nachname Vorname Telefon9 Pohl Helmut 0201/4014186

33

Normalisierung

14 Schindler Christina 0201/401215115 Aliman Zafer 0201/4012161

In gleicher Weise wird die Tabelle Fahrzeuge gekrzt; die Angaben werden in dieneuen Tabellen Fahrzeugtypen und Fahrzeughersteller ausgelagert.

5.5. Zustzliche Manahmen

In der Theorie gibt es noch eine 4. und eine 5. Normalform (und eine Alterna-tive zur 3. Normalform). Dazu sei auf den Wikipedia-Artikel und die dortigenHinweise (Quellen, Literatur, Weblinks) verwiesen. In der Praxis ist aber eine Da-tenbank, die den Bedingungen der 3. Normalform entspricht, bereits sehr gutkonzipiert. Weitere Normalisierungen bringen kaum noch Vorteile; stattdessenknnen sie die bersichtlichkeit und die Geschwindigkeit beim Datenzugriff be-eintrchtigen.

5.5.1. Verzicht auf Zusatztabellen

Beispielsweise wiederholen sich in der Tabelle Versicherungsnehmer die Orts-angaben. Dabei gehren die Kombinationen PLZ/Ort immer zusammen; auchwenn der Kunde umzieht, ist eine solche Kombination unverndert gltig. Alsoknnte man in der Tabelle die Adresse wie folgt speichern:

Kd-Nr Name Vorname Geburtsdatum PLZ Alort Strae Hausnummer1 Heckel Obsthandel GmbH 46282 10884500 Gahlener Str. 405 Geissler Helga 13.01.1953 44809 05902500 Steinbankstr. 15

Der Ortsname ist dann zu finden ber die PL-Datei der Deutschen Post AG (mitPLZ/Alort als Primrschlssel):

Dateiversion Geltung PLZ Alort PLZ-Arten OrtsnamePL 0509 244 20010101 44809 05902500 06 2 2 BochumPL 0509 244 20050329 46282 10884500 06 2 2 Dorsten

Das gleiche Verfahren ist mglich fr die Straennamen. Es sorgt dafr, dass nurgltige Anschriften gespeichert sind und auch bei Eingemeindungen die neu-en Angaben eindeutig bernommen werden. Aber selbst wenn man wegen derDatensicherheit mit Alort arbeiten will, wird man fr die praktische Arbeit denOrtsnamen in der Adressendatei behalten wollen.

34

Zustzliche Manahmen

5.5.2. Primrschlssel nur zur Identifizierung

Im vorigen Kapitel hatten wir kurz darauf hingewiesen, dass der Primrschlsselnur die Bedeutung als ID haben sollte.

Eine Begrndung liefert die obige Tabelle Fahrzeuge, bei der das Kennzeichenzur Identifizierung benutzt wurde. Wenn der Fahrzeughalter in einen anderenKreis umzieht, bekommt er ein neues Kennzeichen. Dann msste es an allenStellen gendert werden, an denen es gespeichert ist. Nun darf die Vertragsab-teilung nur die Vertrge ndern, die Schadensabwicklung die Schadensflle (undwer wei, wo noch darauf Bezug genommen wird). Jede Ummeldung verursachtalso erheblichen Mehraufwand.

Sorgen wir also fr mehr Datensicherheit und Arbeitsvereinfachung:

Der Primrschlssel ist eine automatisch zugewiesene ID. Diese ID wird nie-mals gendert.

Die Identifizierung, die der Benutzer kennt, ist eine einzelne Spalte in einereinzigen Tabelle.Beispiele: Vertragsnummer, Fahrzeug-Kennzeichen, Personalnummer

Die Verknpfungen mit anderen Tabellen regelt die Datenbank mit Hilfe derID selbstndig.

5.5.3. nderungsdaten

In vielen Fllen ist es sinnvoll, wenn in einer Tabelle nicht nur der aktuelle Zu-stand gespeichert ist, sondern der Verlauf.

Beispiel mit nderung des Kennzeichens: Wenn die Polizei nach einem Un-fallverursacher sucht, der inzwischen umgezogen ist, wird fr das alte (nichtmehr gltige) Kennzeichen kein Fahrzeug gefunden.

Adressennderungen auf Termin legen: Es wre viel zu aufwndig, wenn al-le nderungen gleichzeitig an dem Stichtag, an dem sie gelten sollen, einge-geben werden mssten. Besser ist es, sie sofort zu speichern mit Angabe desGeltungsdatums; die Datenbank holt abhngig vom aktuellen und dem Gel-tungsdatum immer die richtige Version.

Aktueller Steuersatz: Die Abrechnung einer Versandfirma muss immer mitdem richtigen Steuersatz rechnen, auch wenn er mitten im Jahr gendert wird.Als Steuersatz 1 fr die Mehrwertsteuer wird dann bei einer lteren Rech-nung mit 16 % und bei einer Rechnung neueren Datums mit 19 % gerechnet.

Fr alle solche Flle erhalten Tabellen gerne zustzliche Spalten gltig von undgltig bis. Anstelle einer nderung werden Datenstze verdoppelt; die neuen In-formationen ersetzen dabei die bisher gltigen.

35

Normalisierung

Selbstverstndlich erfordert eine solche Datenbankstruktur hheren Aufwandsowohl beim Entwickler der Datenbank als auch beim Programmierer der An-wendung. Der zustzliche Nutzen rechtfertigt diesen Aufwand.

5.5.4. Reihenfolge ohne Bedeutung

Beim Aufbau einer Datenbank darf es nicht relevant sein, in welcher Reihenfol-ge die Zeilen und Spalten vorkommen: Die Funktionalitt der Datenbank darfnicht davon abhngen, dass zwei Spalten in einer bestimmten Folge nacheinan-der kommen oder dass nach einem Datensatz ein bestimmter zweiter folgt.

Ein Datensatz (also eine Zeile) steht nur ber den Primrschlssel bereit.

Eine Spalte steht nur ber den Spaltennamen zur Verfgung.

Nur ausnahmsweise wird mit der Nummer einer Zeile oder Spalte gearbeitet,z. B. wenn ein Programmierer-Werkzeug nur indizierte Spalten kennt.

5.6. Zusammenfassung

Fassen wir diese Erkenntnisse zusammen zu einigen Regeln, die bei der Entwick-lung einer Datenbankstruktur zu beachten sind.

5.6.1. Allgemeine Regeln

Von der Realitt ausgehen: Erstellen Sie Tabellen danach, mit welchen Dingen(Objekten) Sie arbeiten. Benutzen Sie aussagekrftige Namen fr Tabellenund Spalten.

Einzelne Informationen klar trennen: Alle Informationen werden in einzelneSpalten mit unteilbaren Werten aufgeteilt.

Vollstndigkeit: Alle mglichen Informationen sollten von vornherein berck-sichtigt werden. Nachtrgliche nderungen sind zu vermeiden.

Keine berechneten Werte speichern: Eine Information, die aus vorhandenenAngaben zusammengestellt werden kann, wird nicht als eigene Spalte ge-speichert.

Kleine Tabellen bevorzugen: Wenn eine Tabelle sehr viele Informationen um-fasst, ist es besser, sie zu unterteilen und ber einen einheitlichen Primr-schlssel zu verbinden.

Keine doppelten Speicherungen: Es darf weder ganze doppelte Datenstze ge-ben noch wiederholte Speicherungen gleicher Werte (Redundanz von Da-ten). Doppelte Datenstze werden durch Primrschlssel und Regeln zur

36

Siehe auch

Eindeutigkeit in Feldern vermieden; Datenredundanz wird durch getrenn-te Tabellen ersetzt, sodass es nur die Fremdschlssel mehrfach gibt.

Wichtig ist auch, dass der Aufbau der Datenbank beschrieben und ggf. begrn-det wird. Hilfreich sind dabei graphische Darstellungen, wie sie von vielen Da-tenbankprogrammen angeboten werden.

5.6.2. Abweichungen

Die vorstehenden berlegungen werden nicht immer beachtet. Fr fast jede Re-gel gibt es begrndete Ausnahmen

Beispielsweise enthlt eine Datenbank mit Adressen in der Regel die Adressenim Klartext und nicht nur als Verweise auf die Nummern von Orten, Ortsteilen,Straen und Straenabschnitten der Deutschen Post.

Entscheiden Sie erst nach bewusster Abwgung von Vor- und Nachteilen, wennSie von einer der Regeln abweichen wollen.

5.7. Siehe auch

ber Wikipedia sind weitere Informationen zu finden:

Normalisierung 1

Relationale Datenbank2

Edgar F. Codd3 und seine 12 Regeln4 fr relationale Datenbanken

Update-Anomalien5

Redundanz von Daten6

Fr eine sorgfltige Planung einer Adressen-Datenbank hilft die Datenstrukturder Deutschen Post:

Broschre Datafactory7 (360 kB) als berblickUnter Post Direkt8 kann die Datei 20101230_HB_Leitdaten.pdf mit der Daten-satzbeschreibung kostenfrei bestellt werden.

1 http://de.wikipedia.org/wiki/Normalisierung%20(Datenbank)2 http://de.wikipedia.org/wiki/Relationale%20Datenbank3 http://de.wikipedia.org/wiki/Edgar%20F.%20Codd4 http://de.wikipedia.org/wiki/Online_Analytical_Processing%2312_Regeln_nach_Codd5 http://de.wikipedia.org/wiki/Anomalie%20(Informatik)6 http://de.wikipedia.org/wiki/Redundanz%20(Informationstheorie)7 http://www.deutschepost.de/downloadServlet?target=/mlm.nf/dpag/images/d/datafactory

/20100205_datafactory_internet.pdf8 mailto:[email protected]

37

http://de.wikipedia.org/wiki/Normalisierung%20(Datenbank)http://de.wikipedia.org/wiki/Relationale%20Datenbankhttp://de.wikipedia.org/wiki/Edgar%20F.%20Coddhttp://de.wikipedia.org/wiki/Online_Analytical_Processing%2312_Regeln_nach_Coddhttp://de.wikipedia.org/wiki/Anomalie%20(Informatik)http://de.wikipedia.org/wiki/Redundanz%20(Informationstheorie)http://www.deutschepost.de/downloadServlet?target=/mlm.nf/dpag/images/d/datafactory/20100205_datafactory_internet.pdfhttp://www.deutschepost.de/downloadServlet?target=/mlm.nf/dpag/images/d/datafactory/20100205_datafactory_internet.pdfmailto:[email protected]

6. Beispieldatenbank

6.1. Sachverhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2. Schematische Darstellung . . . . . . . . . . . . . . . . . . . . . . 41

6.3. Tabellenstruktur und Datenbank . . . . . . . . . . . . . . . . . . 42

6.4. Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Dieses Kapitel bespricht die Grundlagen der Beispieldatenbank. Alle Einzelhei-ten der Tabellen stehen im Anhang unter Tabellenstruktur der Beispieldaten-bank1.

i HinweisAlle Beispiele, Erluterungen und Aufgaben beziehen sich auf dieseDatenstruktur. Bitte schlagen Sie (soweit erforderlich) immer dort nach.

6.1. Sachverhalt

Die Beispieldatenbank in diesem Buch versucht, eine Versicherungsgesellschaftfr Kfz-Versicherungen abzubilden. Das Beispiel ist eine starke Vereinfachungder Realitt; zum Beispiel fehlen alle Teile der laufenden Abrechnung der Prmi-en und Schadensflle.

Die relevanten Begriffe sind fr eine bessere bersichtlichkeit fett gekennzeich-net. Folgender Sachverhalt wird in der Datenbank abgebildet:

Die Versicherungsgesellschaft UnsereFirma verwaltet mit dieser Datenbank ih-re Kundendaten und die Schadensflle. Wegen der Schadensflle mssen auchDaten fremder Kunden und Versicherungen gespeichert werden.

Jeder Versicherungsvertrag wird mit einem Versicherungsnehmer ber genauein Fahrzeug abgeschlossen. Der Versicherungsvertrag wird durch folgende Ei-genschaften gekennzeichnet; zu jeder Eigenschaft gehrt eine Spalte:

1 Anhang A auf Seite 419

39

Beispieldatenbank

Vertragsnummer (Pflicht, eindeutig)

Datum des Abschlusses, Art des Vertrages (Pflicht); dabei gibt es die Arten Haft-pflicht (HP), Haftpflicht mit Teilkasko (TK), Vollkasko (VK).

Verweis auf den Versicherungsnehmer (Pflicht)

Verweis auf das Fahrzeug (Pflicht, eindeutig)

Verweis auf den Mitarbeiter, der den Vertrag bearbeitet (Pflicht)

Der Versicherungsnehmer ist gekennzeichnet durch diese Eigenschaften:

Kundennummer (Pflicht, eindeutig)

Name und Anschrift: PLZ, Ort, Strae, Hausnummer (Pflicht)

bei natrlichen Personen zustzlich durch Vorname, Geburtsdatum, Datumdes Fhrerscheins (optional)

Verweis auf eine Fremdversicherung, wenn ein (fremdes) Fahrzeug an einemUnfall beteiligt ist (optional)

Das Fahrzeug ist gekennzeichnet durch diese Eigenschaften:

polizeiliches Kennzeichen (Pflicht, eindeutig)

Farbe (optional)

Fahrzeugtyp und damit indirekt auch den Fahrzeughersteller (Pflicht)

Ein Mitarbeiter ist gekennzeichnet durch diese Eigenschaften:

Name, Vorname, Geburtsdatum (Pflicht)

Personalnummer (Pflicht, eindeutig)

Verweis auf Abteilung, Vermerk, ob es sich um den Leiter der Abteilung handelt(Pflicht)

Kontaktdaten wie Telefon, Mobiltelefon, Email, Raum (optional)

Die Abteilung ist gekennzeichnet durch diese Eigenschaften:

Nummer (Pflicht, eindeutig)

Kurzbezeichnung, Bezeichnung (Pflicht, eindeutig)

Ort (optional)

Zustzlich gibt es Dienstwagen. Dabei handelt es sich um eine Tabelle mit dengleichen Eigenschaften wie bei Fahrzeug und zustzlich:

Verweis auf den Mitarbeiter, zu dem ein Dienstwagen gehrt (optional)

denn es gibt auch Firmenwagen, die keinem Mitarbeiter persnlich zugeord-net sind

Ein Schadensfall ist gekennzeichnet durch diese Eigenschaften:

40

Schematische Darstellung

Datum, Ort und Umstnde des Unfalls (Pflicht)

Vermerk, ob es Verletzte gab, sowie Hhe des Gesamtschadens (optional, denndie Angaben knnten erst spter bekannt werden)

Verweis auf den Mitarbeiter, der den Schadensfall bearbeitet (Pflicht)

An einem Schadensfall knnen mehrere Fahrzeuge unterschiedlicher Versiche-rungen beteiligt sein. (Unflle mit Radfahrern und Fugngern werden nicht be-trachtet.) Deshalb gibt es eine weitere Tabelle Zuordnung_SF_FZ mit diesen Ei-genschaften:

Liste aller Schadensflle und aller beteiligten Fahrzeuge (Pflicht)

anteilige Schadenshhe eines Fahrzeugs an dem betreffenden Unfall (optio-nal)

ber die Verbindung Schadensfall Fahrzeug Versicherungsvertrag Ver-sicherungsnehmer Versicherungsgesellschaft knnen alle beteiligten Gesell-schaften festgestellt und in die Schadensabwicklung eingebunden werden.

Bitte beachten Sie auch die unten stehenden Hinweise ber Fehlende Spaltenund Einschrnkungen.

6.2. Schematische Darstellung

Die vorstehende Struktur kann im folgenden Diagramm dargestellt werden. DieVerweise, nmlich die Verknpfungen zwischen den Tabellen sind daraus so ab-zulesen:

Von jeder Tabelle gibt es einen Verweis auf einen Eintrag in der direkt darunterstehenden Tabelle.

Zu jedem Vertrag gehrt ein Sachbearbeiter; das wird durch den Pfeil nachlinks auen angedeutet, der in der Tabelle Mitarbeiter von rechts herein-kommt.

Zu jedem Vertrag gehrt genau ein Fahrzeug; zu jedem Fahrzeug gehrt einVertrag.

Jeder Eintrag in der Liste der Zuordnungen Schadensfall, Fahrzeug bezieht sichauf einen Schadensfall und ein Fahrzeug; dabei gilt:

Zu jedem Schadensfall gehren ein oder mehrere Fahrzeuge.

Nicht jedes Fahrzeug hat einen Schadensfall.

Documents

Einführung in SQL - upload.wikimedia.org¼hrung_in_SQL.pdf · Titel „Einführung in SQL“, Einschränkung auf Jahr „2011–“. Namen von Programmen und Produkten sowie weitere