SQL für Dummies E-Book

Allen G. Taylor

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Wissenschaft und neue Technologien
• Serie: ...für Dummies
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 648

Beschreibung

Daten und Datenbanken sind quasi überall. Mit der Standardabfragesprache SQL können Daten in relationalen Datenbanken einfach, strukturiert und zielsicher abgefragt werden. Erfahren Sie in diesem Buch, das kein Vorwissen voraussetzt, wie Sie Datenbanken erstellen, Daten ordnen und abfragen und wie Sie SQL-Anweisungen in Programme und Websites einbinden. Nutzen Sie dieses Buch auch als Nachschlagewerk. Ganz wichtig: Sie lernen auch, wie Sie Ihre Datenbanken und Daten schützen und wie Sie typische Fehler vermeiden.

Leseprobe

SQL für Dummies

Schummelseite

SQL-KRITERIEN FÜR NORMALFORMEN

Damit Datenbanktabellen Ihre Daten zuverlässig speichern, müssen sie so entworfen werden, dass keine Änderungsanomalien auftreten können. Zu diesem Zweck müssen sie normalisiert werden. Vergleichen Sie die SQL-Kriterien in der folgenden Liste mit den Tabellen in Ihrer Datenbank, um die Stellen zu entdecken, an denen Anomalien auftreten könnten und die gegebenenfalls weiter normalisiert werden müssen.

Erste Normalform (1NF)

Die Tabelle muss zweidimensional sein und Zeilen und Spalten enthalten.Jede Zeile enthält Daten, die zu einem Objekt oder einem Teil des Objekts gehören.Jede Spalte enthält Daten für ein einzelnes Attribut des beschriebenen Objekts.Jede Zelle (Schnittpunkt einer Zeile und Spalte) einer Tabelle enthält einen einzigen Wert.Alle Einträge in einer Spalte müssen vom selben Typ sein.Jede Spalte hat einen eindeutigen Namen.Keine zwei Zeilen sind identisch.Die Reihenfolge der Spalten und Zeilen spielt keine Rolle.

Zweite Normalform (2NF)

Die Tabelle muss in der ersten Normalform (1NF) vorliegen.Alle Nicht-Schlüssel-Attribute (Spalten) sind vom gesamten Schlüssel abhängig.

Dritte Normalform (3NF)

Die Tabelle muss in der zweiten Normalform (2NF) vorliegen.Die Tabelle enthält keine transitiven Abhängigkeiten.

Wertebereich-/Schlüssel-Normalform (DKNF, Domain Key Normal Form)

Jede Einschränkung der Tabelle ist eine logische Folge der Definition von Schlüsseln und Wertebereichen (Domänen).

SQL-DATENTYPEN

Genaue Zahlen

Die folgende Liste enthält alle formalen Datentypen in ISO/IEC-Standard-SQL. Zusätzlich zu diesen Typen können Sie weitere Datentypen definieren, die von diesen Typen abgeleitet sind.

INTEGERSMALLINTBIGINTNUMERICDECIMAL

Näherungsweise genaue Zahlen

REALDOUBLE PRECISIONFLOAT

Binärstrings

BINARYBINARY VARYINGBINARY LARGE OBJECT

Boolesche Werte

BOOLEAN

Zeichenfolgen

CHARACTERCHARACTER VARYING (VARCHAR)CHARACTER LARGE OBJECTNATIONAL CHARACTERNATIONAL CHARACTER VARYINGNATIONAL CHARACTER LARGE OBJECT

Datums- und Zeit-Werte

DATETIME WITHOUT TIMEZONETIMESTAMP WITHOUT TIMEZONETIME WITH TIMEZONETIMESTAMP WITH TIMEZONE

Intervalle

INTERVAL DAYINTERVAL YEAR

Collection-Typen

ARRAYMULTISET

Andere Typen

JSONROWXML

SQL-WERTEFUNKTIONEN

Die folgenden SQL-Wertefunktionen verändern Daten. Daten können auf vielerlei Arten verändert werden; die hier genannten Funktionen führen einige der am häufigsten benötigen Operationen aus.

Zeichenfolgenfunktionen

Beschreibung

SUBSTRING

Extrahiert eine Teilzeichenfolge aus einer Quellzeichenfolge

SUBSTRING SIMILAR

Extrahiert eine Teilzeichenfolge mithilfe eines POSIX-basierten regulären Ausdrucks aus einer Quellzeichenfolge

SUBSTRING_REGEX

Extrahiert das erste oder jedes Auftreten eines regulären XQuery-Ausdrucks aus einer Quellzeichenfolge und gibt den Teilstring zurück

TRANSLATE_REGEX

Extrahiert das erste oder jedes Auftreten eines regulären XQuery-Ausdrucks aus einer Quellzeichenfolge und ersetzt den Teilstring durch einen XQuery-Ersetzungsstring

UPPER

Konvertiert eine Zeichenfolge in Großbuchstaben

LOWER

Konvertiert eine Zeichenfolge in Kleinbuchstaben

TRIM

Schneidet Leerzeichen am Anfang und am Ende einer Zeichenfolge ab

TRANSLATE

Wandelt den Zeichensatz einer Zeichenfolge in einen anderen Zeichensatz um

CONVERT

Konvertiert den Zeichensatz einer Zeichenfolge in einen anderen Zeichensatz

Numerische Funktionen

Beschreibung

POSITION

Gibt die Startposition einer Zielzeichenfolge innerhalb einer Quellzeichenfolge zurück

CHARACTER_LENGTH

Gibt die Anzahl der Zeichen in einer Zeichenfolge zurück

OCTET_LENGTH

Gibt die Anzahl der Achtbitzeichen (= Bytes) innerhalb einer Zeichenfolge zurück

EXTRACT

Extrahiert ein einzelnes Feld aus einem Datumswert oder Intervall

Datums- und Zeitfunktionen

Beschreibung

CURRENT_DATE

Gibt das aktuelle Datum zurück

CURRENT_TIME(p)

Gibt die aktuelle Zeit zurück; (p) gibt die Genauigkeit der Sekundenbruchteile an

CURRENT_TIMESTAMP(p)

Gibt das aktuelle Datum und die aktuelle Zeit zurück; (p) ist die Genauigkeit der Sekundenbruchteile

MENGENFUNKTIONEN

Die SQL-Mengenfunktionen liefern schnelle Antworten auf Fragen, die die Eigenschaften der Daten insgesamt betreffen. Wie viele Zeilen sind in einer Tabelle enthalten? Was ist der größte oder kleinste Wert in einer Spalte? Solche Fragen werden mit den SQL-Mengenfunktionen beantwortet.

COUNT

Gibt die Anzahl der Zeilen in der durch die WHERE-Klausel spezifizierten Datenmenge zurück

MAX

Gibt den größten Wert in der durch die WHERE-Klausel spezifizierten Datenmenge zurück

MIN

Gibt den kleinsten Wert in der durch die WHERE-Klausel spezifizierten Datenmenge zurück

SUM

Addiert die Werte in der durch die WHERE-Klausel spezifizierten Datenmenge

AVG

Gibt den Durchschnittswert aller Werte in der durch die WHERE-Klausel spezifizierten Datenmenge zurück

PRÄDIKATE DER WHERE-KLAUSEL

Prädikate haben einen der beiden booleschen Werte TRUE oder FALSE. Mit WHERE-Klauseln können Sie unerwünschte Zeilen aus dem Ergebnis einer SQL-Abfrage herausfiltern.

Vergleichsprädikate

=        Gleich

<>      Ungleich

<        Kleiner als

<=      Kleiner als oder gleich

>        Größer als

>=      Größer als oder gleich

Andere Prädikate

ALLBETWEENDISTINCTEXISTSINLIKEMATCHNOT INNOT LIKENULLOVERLAPSSIMILARSOME, ANYUNIQUE

SQL für Dummies

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

8. Auflage 2023

© 2023 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, Germany

Original English language edition SQL For Dummies © 2019 by Wiley Publishing, Inc. All rights reserved including the right of reproduction in whole or in part in any form. This translation published by arrangement with John Wiley and Sons, Inc.

Copyright der englischsprachigen Originalausgabe SQL For Dummies © 2019 by Wiley Publishing, Inc. Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Diese Übersetzung wird mit Genehmigung von John Wiley and Sons, Inc. publiziert.

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.

Coverfoto: canjoena – stock.adobe.comKorrektur: Petra Heubach-Erdmann

Print ISBN: 978-3-527-72022-4ePub ISBN: 978-3-527-84034-2

Über den Autor

Allen G. Taylor ist ein Veteran der Computerindustrie. In mehr als 30 Jahren hat er über 30 Bücher veröffentlicht. Er arbeitete als Dozent für Datenbanken, Netzwerke, Innovationen und Existenzgründung. Darüber hinaus schulte er über einen Online-Provider Datenbankentwickler.

Danksagung

Zunächst einmal möchte ich mich ganz herzlich bei Jim Melton, dem Herausgeber der ISO/ANSI-Spezifikationen, für seine Hilfe bedanken. Ohne seine unermüdlichen Anstrengungen wäre sowohl dieses Buch als auch SQL als internationaler Standard viel weniger wert. Auch Andrew Eisenberg hat durch seine Bücher viel zu meinen SQL-Kenntnissen beigetragen. Weiterhin möchte ich Michael Durthaler für seine hilfreichen Vorschläge zum Thema Cursor danken. Ich möchte auch meinem Projektleiter Pat O’Brien und meiner Agentin Carole McClendon von Waterside Productions für ihre Unterstützung meiner Karriere danken.

Inhaltsverzeichnis

Cover

Titelblatt

Impressum

Über den Autor

Danksagung

Einleitung

Über dieses Buch

Wer sollte dieses Buch lesen?

Symbole, die in diesem Buch verwendet werden

Wie es weitergeht

Teil I: Grundbegriffe

Kapitel 1: Grundlagen relationaler Datenbanken

Die Übersicht über die Dinge bewahren

Was ist eine Datenbank?

Datenbankgröße und -komplexität

Was ist ein Datenbankverwaltungssystem?

Flache Dateien

Datenbankmodelle

Überlegungen zum Datenbankentwurf

Kapitel 2: SQL-Grundlagen

Was SQL ist und was es nicht ist

Ein (sehr) kurzer historischer Überblick

SQL-Anweisungen

Reservierte Wörter

Datentypen

Nullwerte

Einschränkungen

SQL in Client/Server-Systemen

SQL mit dem Internet oder einem Intranet benutzen

Kapitel 3: Die Komponenten von SQL

Data Definition Language

Data Manipulation Language

DCL (Data Control Language)

Teil II: Datenbanken mit SQL erstellen

Kapitel 4: Eine einfache Datenbankstruktur erstellen und verwalten

Eine einfache Datenbank mit einem RAD-Werkzeug erstellen

Das gleiche Beispiel mit der DDL von SQL erstellen

Überlegungen zur Portierbarkeit

Kapitel 5: Eine relationale Datenbank mit mehreren Tabellen erstellen

Die Datenbank entwerfen

Mit Indizes arbeiten

Die Datenintegrität bewahren

Die Datenbank normalisieren

Teil III: Daten speichern und abrufen

Kapitel 6: Daten einer Datenbank bearbeiten

Daten abfragen

Eine Sicht erstellen

Sichten aktualisieren

Neue Daten hinzufügen

Vorhandene Daten aktualisieren

Daten übertragen

Überholte Daten löschen

Kapitel 7: Temporale Daten verarbeiten

Zeiten und Perioden in SQL verstehen

Mit Anwendungszeitperioden-Tabellen arbeiten

Mit systemversionierten Tabellen arbeiten

Noch mehr Daten mit bitemporalen Tabellen verwalten

Kapitel 8: Das Angeben von Datenwerten

Werte

Wertausdrücke

Funktionen

Kapitel 9: SQL-Wertausdrücke – fortgeschrittener Teil

CASE-Bedingungsausdrücke

Umwandlungen von Datentypen mit CAST

Datensatzwertausdrücke

Kapitel 10: Daten zielsicher finden

Modifizierende Klauseln

Die Klausel FROM

Die Klausel WHERE

Logische Verknüpfungen

Die Klausel GROUP BY

HAVING

ORDER BY

Begrenzende FETCH-Funktion

Ergebnismengen mit Fensterfunktionen erstellen

Kapitel 11: Relationale Operatoren

UNION

INTERSECT

EXCEPT

Verknüpfungsoperatoren

ON im Vergleich zu WHERE

Kapitel 12: Mit verschachtelten Abfragen tief schürfen

Was Unterabfragen erledigen

Kapitel 13: Rekursive Abfragen

Was ist Rekursion?

Was ist eine rekursive Abfrage?

Wo kann ich eine rekursive Abfrage anwenden?

Wo könnte ich rekursive Abfragen sonst noch nutzen?

Teil IV: Kontrollmechanismen

Kapitel 14: Datenbanken schützen

Die Datenkontrollsprache von SQL

Zugriffsebenen für Benutzer

Rechte an Benutzer vergeben

Rechte über Ebenen hinweg einräumen

Das Recht zur Vergabe von Rechten übertragen

Rechte entziehen

Mit GRANT und REVOKE zusammen Zeit und Aufwand sparen

Kapitel 15: Daten schützen

Gefahren für die Datenintegrität

Die Gefahr der Verfälschung von Daten reduzieren

Einschränkungen innerhalb von Transaktionen

Kapitel 16: SQL in Anwendungen nutzen

SQL in einer Anwendung

SQL in prozedurale Sprachen einbinden

Teil V: SQL in der Praxis

Kapitel 17: Datenzugriffe mit ODBC und JDBC

ODBC

ODBC in einer Client/Server-Umgebung

ODBC und das Internet

ODBC und Intranets

JDBC

Kapitel 18: SQL und XML

Was XML mit SQL zu tun hat

Der XML-Datentyp

SQL in XML und XML in SQL konvertieren

SQL-Funktionen, die mit XML-Daten arbeiten

Prädikate

XML-Daten in SQL-Tabellen umwandeln

Nicht vordefinierte Datentypen in XML abbilden

Die Hochzeit von SQL und XML

Teil VI: SQL für Fortgeschrittene

Kapitel 19: Cursor

Einen Cursor deklarieren

Einen Cursor öffnen

Daten aus einer einzelnen Zeile abrufen

Einen Cursor schließen

Kapitel 20: Prozedurale Möglichkeiten mit dauerhaft gespeicherten Modulen schaffen

Zusammengesetzte Anweisungen

Anweisungen zur Ablaufsteuerung

Gespeicherte Prozeduren

Gespeicherte Funktionen

Rechte

Gespeicherte Module

Kapitel 21: Fehlerbehandlung

SQLSTATE

Die Klausel WHENEVER

Diagnosebereiche

Ausnahmen handhaben

Kapitel 22: Trigger

Einige Anwendungen von Triggern

Einen Trigger erstellen

Eine Folge von Triggern auslösen

Alte Werte und neue Werte referenzieren

Ein Beispiel

Mehrere Trigger für eine einzelne Tabelle auslösen

Teil VII: Der Top-Ten-Teil

Kapitel 23: Zehn häufige Fehler

Annehmen, dass die Kunden wissen, was sie brauchen

Den Umfang des Projekts ignorieren

Nur technische Faktoren berücksichtigen

Nicht um Feedback bitten

Immer Ihre liebste Entwicklungsumgebung benutzen

Immer Ihre liebste Systemarchitektur benutzen

Datenbanktabellen unabhängig voneinander entwerfen

Design-Reviews ignorieren

Betatests überspringen

Keine Dokumentation erstellen

Kapitel 24: Zehn Tipps für Abfragen

Prüfen Sie die Datenbankstruktur

Testen Sie Abfragen mit einer Testdatenbank

Prüfen Sie Verknüpfungsabfragen doppelt

Prüfen Sie Abfragen mit einer Unterabfrage dreifach

Daten mit GROUP BY summieren

Beachten Sie die Einschränkungen der Klausel GROUP BY

Benutzen Sie bei AND, OR und NOT Klammern

Überwachen Sie Abfragerechte

Sichern Sie Ihre Datenbanken regelmäßig

Bauen Sie eine Fehlerbehandlung ein

Anhang A: Wie kommt man zu einer Datenbankumgebung?

Die verschiedenen SQL-Datenbanksysteme

Die MySQL-Konsole

Anhang B: SQL: Reservierte Wörter

Abbildungsverzeichnis

Stichwortverzeichnis

End User License Agreement

Tabellenverzeichnis

Kapitel 2

Tabelle 2.1: SQL-Anweisungen

Tabelle 2.2: Datentypen

Kapitel 3

Tabelle 3.1: Die Datenbanktabellen des Sportartikelgeschäfts

Tabelle 3.2: Beispiele für Stringverkettungen

Tabelle 3.3: Vergleichsoperatoren und Vergleichsprädikate

Tabelle 3.4: Schutzmechanismen

Kapitel 5

Tabelle 5.1: VetLab-Tabellen

Tabelle 5.2: Kundentabelle

Tabelle 5.3: KundenNamen-Index für die Kundentabelle

Kapitel 6

Tabelle 6.1: Die Tabelle

Kunde

Tabelle 6.2: Die Tabelle

Kunde

nach der Aktualisierung einer Zeile mit

UPDATE

Tabelle 6.3: Die Tabelle

Kunde

nach dem

UPDATE

mehrerer Zeilen

Tabelle 6.4: Die Tabelle

Kunde

nach einem

UPDATE

aller Zeilen

Kapitel 7

Tabelle 7.1: Die Anwendungszeitperiode-Tabelle enthält eine Zeile.

Tabelle 7.2: Die Anwendungszeitperiode-Tabelle nach der Aktualisierung

Tabelle 7.3: Die Anwendungszeitperiode-Tabelle vor einer Aktualisierung oder Lösc...

Tabelle 7.4: Die Anwendungszeitperiode-Tabelle nach der Löschung

Tabelle 7.5: Eine unerwünschte Situation

Kapitel 8

Tabelle 8.1: Beispiele für Literale der verschiedenen Datentypen

Tabelle 8.2: String-Wertausdrücke

Tabelle 8.3: Nährwerte von 100 Gramm ausgewählter Nahrungsmittel

Tabelle 8.4: Die Wirkungsweise der Funktion

UPPER

Tabelle 8.5: Die Wirkungsweise der Funktion

LOWER

Tabelle 8.6: Die Wirkungsweise der Funktion

TRIM

Tabelle 8.7: Die Wirkungsweise der Funktion

POSITION

Tabelle 8.8: Datums- und Zeitfunktionen

Tabelle 8.9: Tabelle mit JSON-Dokumenten

Kapitel 9

Tabelle 9.1: Dienstgrade

Kapitel 10

Tabelle 10.1: Modifizierende Klauseln und ihre Funktionen

Tabelle 10.2: Vergleichsprädikate in SQL

Tabelle 10.3:

LIKE

in SQL

Tabelle 10.4: Das Ergebnis des Abrufs der Verkäufe vom 31.1.2020 bis zum 16.2.202...

Tabelle 10.5: Die durchschnittlichen Umsätze der Verkäufer

Tabelle 10.6: Der Gesamtumsatz aller Verkäufer

Tabelle 10.7: Der Gesamtumsatz aller Verkäufer außer Meier

Kapitel 11

Tabelle 11.1: Tabelle

Standort

Tabelle 11.2: Tabelle

Abteilung

Tabelle 11.3: Tabelle

Mitarbeiter

Tabelle 11.4: Tabelle

Mitarbeiter

Tabelle 11.5: Tabelle

Projekte

Tabelle 11.6: Tabelle

Fähigkeit

Tabelle 11.7: Ergebnis der inneren Verknüpfung

Tabelle 11.8: Ergebnis des Union-Joins

Tabelle 11.9: Ergebnis der Vereinigungsverknüpfung mit dem Ausdruck

COALESCE

Tabelle 11.10: Verfeinertes Ergebnis der Vereinigungsverknüpfung mit

COALESCE

-Aus...

Kapitel 12

Tabelle 12.1: Tabelle

Artikel

Tabelle 12.2: Tabelle

Komponente

Tabelle 12.3: Tabelle

Verwendung

Tabelle 12.4: Tabelle

Kunde

Tabelle 12.5: Tabelle

Kontakt

Kapitel 13

Tabelle 13.1: Flüge, die von Vannevar Airlines angeboten werden

Tabelle 13.2:

ErreichbarVon

nach einem Durchlauf durch die Rekursion

Tabelle 13.3:

ErreichbarVon

nach zwei Durchläufen durch die Rekursion

Kapitel 15

Tabelle 15.1: Isolierungsebenen und gelöste Probleme

Kapitel 20

Tabelle 20.1: Klassenwerte von

SQLSTATE

Tabelle 20.2: Ausnahmen, die in einem Ausnahme-Handler festgelegt werden können

Kapitel 21

Tabelle 21.1: Der Kopf des Diagnosebereichs

Tabelle 21.2: Der Diagnose-Detailbereich

Illustrationsverzeichnis

Kapitel 1

Abbildung 1.1: Blockdiagramm eines DBMS-Informationssystems

Abbildung 1.2: Tabelle mit der Offensivstatistik eines Baseball-Spielers

Abbildung 1.3: Jede Tabellenzeile enthält einen Datensatz; jede Spalte enthält ei...

Abbildung 1.4: Die für den Verkaufsmanager definierte View wird von der Tabelle

K

...

Abbildung 1.5: Die Sicht des Zweigstellenleiters enthält nur bestimmte Zeilen der...

Abbildung 1.6: In der View für den Buchhaltungsleiter werden Daten aus zwei Tabel...

Kapitel 2

Abbildung 2.1: Beziehungen der XML-Untertypen

Kapitel 3

Abbildung 3.1: Die Tabelle

Kunde

mit einigen Beispieldaten

Abbildung 3.2: Eingabe von Daten über eine Maske mit phpMyAdmin

Abbildung 3.3: Die Sicht

DeKunde

wird aus der Tabelle

Kunde

abgeleitet.

Abbildung 3.4: Die Datenbankstruktur des Sportartikelgeschäfts

Abbildung 3.5: Eine Mehrtabellensicht mit

JOIN

erstellen

Abbildung 3.6: Die View nach der Eingabe einer Zeile in die Tabelle

Rechnung

Abbildung 3.7: Die hierarchische Struktur einer typischen SQL-Datenbank

Kapitel 4

Abbildung 4.1: Der Startbildschirm von Access

Abbildung 4.2: Die Datenblattansicht in der Access-Entwicklungsumgebung

Abbildung 4.3: Anfangszustand der Entwurfsansicht

Abbildung 4.4: Einen aussagekräftigen Feldnamen für den Primärschlüssel verwenden

Abbildung 4.5: Das Fenster zur Erstellung der Tabelle nach der Definition des

Vor

...

Abbildung 4.6: Das Fenster zur Erstellung der Tabelle nach der Definition des

Nac

...

Abbildung 4.7: Das Fenster zur Erstellung der Tabelle nach der Definition aller F...

Abbildung 4.8: Eine leere Zeile wird in die Tabelle

Angebote

eingefügt.

Abbildung 4.9: Die überarbeitete Tabellendefinition

Abbildung 4.10: Sie können eine Tabelle über das Kontextmenü der Tabelle löschen.

Abbildung 4.11: Die

ABFRAGETOOLS

mit der Tabelle

Angebote

Abbildung 4.12: Verfügbare Datenbank-Ansichten im Abfragemodus

Abbildung 4.13: SQL-Ansicht im Abfragemodus

Abbildung 4.14: SQL-Vorschau in phpMyAdmin beim Erstellen einer Tabelle

Abbildung 4.15: Datendefinitionsabfrage zur Erstellung einer Tabelle

Abbildung 4.16: Links die neue

AngeboteSQL

-Tabelle

Kapitel 5

Abbildung 5.1: Die Tabellen und Verknüpfungen der VetLab-Datenbank

Abbildung 5.2: Diese Verkaufstabelle führt zu Änderungsanomalien.

Abbildung 5.3: Die Zerlegung der Tabelle

Verkauf

in zwei Tabellen

Abbildung 5.4: In der Tabelle

Verkauf2

bilden die Spalten

Kundennummer

und

Produk

...

Kapitel 6

Abbildung 6.1: Die Sicht

AuftragNachLand

für den Marketingleiter

Abbildung 6.2: Die Sicht

Verzögerung

für den Chef der Qualitätskontrolle

Abbildung 6.3: Die Sicht zur Ermittlung des Geburtstagsrabatts

Kapitel 13

Abbildung 13.1: Das Ergebnis des Aufrufs von

spiral(1)

Abbildung 13.2: Die Rekursionskette hinab- und wieder hinaufsteigen

Kapitel 14

Abbildung 14.1: Beispiel für die Rechtehierarchie

Abbildung 14.2: Hierarchie der

Kunstwerk

-Tabelle

Kapitel 16

Abbildung 16.1: Die Abfrage

MBFT-Abhandlungen

in der Entwurfsansicht

Abbildung 16.2: Eine der Optionen ist die

SQL-ANSICHT

.

Abbildung 16.3: Eine SQL-Anweisung, die die Namen aller Abhandlungen abruft, die ...

Kapitel 17

Abbildung 17.1: Vergleich eines Client/Server-Systems mit einem webbasierten Syst...

Abbildung 17.2: Webbasiertes Datenbanksystem mit Server-Erweiterung

Abbildung 17.3: Eine Web-Datenbankanwendung, die ein Java-Applet verwendet

Kapitel 21

Abbildung 21.1: Layout des Statusparameters

SQLSTATE

Orientierungspunkte

Cover

Titelblatt

Impressum

Über den Autor

Inhaltsverzeichnis

Einleitung

Fangen Sie an zu lesen

Abbildungsverzeichnis

Stichwortverzeichnis

End User License Agreement

Seitenliste

1

2

3

4

7

8

9

25

26

27

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

355

356

357

358

359

360

361

362

363

364

365

366

367

369

370

371

372

373

374

375

376

377

378

379

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

465

466

467

468

471

472

473

474

475

476

477

478

479

Einleitung

Willkommen bei der Datenbankentwicklung mit der Standard-Abfragesprache SQL (Structured Query Language). Es gibt viele verschiedene Werkzeuge für Datenbankverwaltungssysteme (DBMS – Database Management System), die auf unterschiedlichsten Hardware-Plattformen laufen. Diese Werkzeuge unterscheiden sich zwar zum Teil beträchtlich, aber alle Produkte, die ernst genommen werden wollen, haben eines gemeinsam: Sie unterstützen den Zugriff und die Bearbeitung von Daten mit SQL. Wenn Sie SQL kennen, können Sie relationale Datenbanken erstellen und nützliche Informationen daraus abrufen.

Über dieses Buch

Relationale Datenbankverwaltungssysteme spielen heute in den allermeisten Unternehmen eine lebenswichtige Rolle. Dabei sind Laien immer noch oft der Ansicht, dass Erstellung und Verwaltung derartiger Systeme mit sehr komplexen Aufgaben verbunden wären und somit Datenbankgurus vorbehalten bleiben müssen, die einen Grad der Erleuchtung erlangt haben, der über den Normalsterblicher hinausgeht. Dieses Buch lüftet den Schleier dieser Datenbankgeheimnisse, und Sie werden

die Grundlagen von Datenbanken kennenlernen

herausfinden, wie ein DBMS aufgebaut ist

die funktionalen Hauptkomponenten von SQL kennenlernen

eine Datenbank erstellen

eine Datenbank vor Schäden schützen

mit den Daten einer Datenbank arbeiten

gewünschte Daten aus einer Datenbank abrufen

Dieses Buch soll Ihnen helfen, mit SQL relationale Datenbanken zu erstellen und nützliche Informationen daraus zu extrahieren. SQL ist eine international standardisierte Sprache, die weltweit eingesetzt wird, um relationale Datenbanken zu erstellen und zu verwalten. Diese Auflage beschreibt die neueste Version des Standards: SQL:2016.

Ich gehe nicht näher darauf ein, wie eine Datenbank entworfen wird, da ich in meinen Erläuterungen davon ausgehe, dass Sie bereits über einen arbeitsfähigen Datenbankentwurf verfügen, den Sie erstellt oder von jemand anderem übernommen haben. Ich zeige Ihnen, wie Sie diesen Entwurf mit SQL umsetzen können. Falls Sie der Meinung sind, dass Ihr Datenbankentwurf verbesserungsfähig sein könnte, sollten Sie ihn auf jeden Fall überarbeiten, bevor Sie versuchen, die Datenbank zu erstellen. Je früher Sie bei einem Entwicklungsprojekt Probleme erkennen und beheben, desto kostengünstiger werden die erforderlichen Korrekturen sein.

Wer sollte dieses Buch lesen?

Wenn Sie Daten in einem DBMS speichern und daraus abrufen müssen, können Sie Ihre Aufgaben viel besser erledigen, wenn Sie SQL beherrschen. Sie müssen kein Programmierer sein, um SQL zu benutzen, und Sie müssen keine anderen Programmiersprachen, wie zum Beispiel Java, C, C++ oder BASIC, kennen. Die SQL-Syntax ist an das normale Englisch angelehnt.

Als Programmierer können Sie SQL natürlich auch in Ihre Programme einbinden. SQL erweitert aber keineswegs nur konventionelle Sprachen um sehr mächtige Funktionen zum Abfragen und Bearbeiten von Daten.

Für ein Projekt habe ich vor einigen Jahren einmal SQL-Abfragen in einem kleinen Beispiel zusammen mit HTML, PHP und einer MySQL-Datenbank für das Internet kombiniert. SQL-Abfragen sorgen dafür, dass jeweils aktuelle Daten angezeigt werden.

Auch wenn Sie Google, Yahoo und Wikipedia nutzen oder Bestellungen über das Internet aufgeben, werden die Eingaben meist als SQL-Abfragen an Datenbanken weitergereicht. Viele der Möglichkeiten lassen sich auch im kleineren Rahmen nutzen, wie beispielsweise Ticketsysteme oder ein Media-Wiki im Supportbereich.

Wollte man die vielfältigen Möglichkeiten auch nur ansatzweise umfassend darstellen, würde das den Rahmen des Buches bei Weitem sprengen. In diesem Buch beschränken wir uns daher weitgehend auf das, was Sie wissen müssen, um die vielseitigen Werkzeuge und Funktionen von SQL in eigenen Programmen oder Abfragen nutzen zu können.

Wenn Sie auf eine bereits eingerichtete Arbeitsumgebung zurückgreifen, können Sie gleich loslegen. Ansonsten finden Sie im Anhang ein paar Hinweise, die Ihnen bei der Einrichtung derselben hilfreich sein können.

Symbole, die in diesem Buch verwendet werden

Tipps sparen Zeit und lotsen Sie um Gefahren herum.

Achten Sie auf die Informationen, die mit diesem Symbol gekennzeichnet sind – Sie könnten sie später noch brauchen.

Die Ratschläge unter diesem Symbol können Sie vor größerem Schaden bewahren. Missachten Sie diese Hinweise auf eigene Gefahr.

Dieses Symbol kennzeichnet technische Details, die zwar interessant, aber nicht unbedingt notwendig sind, um das gerade behandelte Thema zu verstehen.

Wie es weitergeht

Und jetzt beginnt der Spaß! Datenbanken sind eines der vielleicht besten Werkzeuge, die jemals erfunden wurden. Mit ihnen können Sie wichtige Geschehnisse und Abläufe sehr gut im Auge behalten. Wenn Sie Datenbanken verstehen und mit SQL dazu bringen können, Ihre Wünsche zu erfüllen, haben Sie die Möglichkeit, ungeahnten Einfluss auf Ihre Daten auszuüben. Ihre Kollegen kommen zu Ihnen, wenn sie wichtige Informationen benötigen. Ihre Vorgesetzten suchen Ihren Rat. Praktikanten bitten Sie um ein Autogramm. Aber – und das ist am wichtigsten – Sie verstehen, wie Ihr Unternehmen wirklich funktioniert.

Teil I

Grundbegriffe

IN DIESEM TEIL …

Wesentliche Begriffe relationaler DatenbankenGrundlegende SQL-BegriffeGrundlegende Datenbank-Tools

Kapitel 1

Grundlagen relationaler Datenbanken

IN DIESEM KAPITEL

DatenorganisationDen Begriff Datenbank definierenDen Begriff DBMS definierenDatenbankmodelle im VergleichDen Begriff relationale Datenbanken definierenDie Probleme beim Entwurf einer Datenbank

SQL (Structured Query Language) ist eine Abfragesprache, die ess-ku-el und nicht si-quel ausgesprochen wird und die speziell für das Arbeiten mit Datenbanken entwickelt wurde. Mit ihr kann man Datenbanken erstellen, neue Daten in Datenbanken einfügen und ausgewählte Teilmengen der Daten abrufen. SQL wurde 1970 eingeführt und im Laufe der Jahre weiterentwickelt. Heute ist sie längst zu einem wichtigen Branchenstandard geworden. SQL wird durch einen formellen Standard definiert, der von der International Standards Organization (ISO) betreut wird.

Es gibt verschiedene Datenbankarten, die unterschiedliche konzeptionelle Modelle für die Organisation von Daten widerspiegeln.

SQL wurde ursprünglich zu dem Zweck entwickelt, Daten zu verwalten, die in Datenbanken enthalten sind, deren Aufbau dem relationalen Modell entspricht. Der internationale SQL-Standard wurde vor einigen Jahren um einen Teil des Objektmodells erweitert, was zu hybriden Strukturen führt, die als objektrelationale Datenbanken bezeichnet werden. In diesem Kapitel beschreibe ich verschiedene Formen der Datenspeicherung, vergleiche das relationale mit anderen wichtigen Datenbankmodellen und gehe dann auf die wichtigen Merkmale relationaler Datenbanken ein.

Doch bevor ich näher auf SQL eingehe, will ich den Begriff der Datenbank klar definieren. Seine Bedeutung änderte sich mit der Art und Weise, in der Computer Informationen speicherten und verwalteten.

Die Übersicht über die Dinge bewahren

Heute werden Computer für viele Aufgaben benutzt, für die früher andere Werkzeuge benutzt wurden. Mechanische und elektrische Schreibmaschinen wurden von Computern beispielsweise längst weitestgehend verdrängt, wenn es darum geht, Dokumente zu erstellen und zu bearbeiten. Sie haben elektronische und mechanische Rechenmaschinen verdrängt. Millionen auf Papier ausgedruckte Seiten, Ordner und Archivschränke wurden als Hauptmedium zur Aufbewahrung wichtiger Daten abgelöst. Computer sind normalerweise sehr viel schneller und effizienter als diese alten Werkzeuge. Diese Vorteile haben aber auch einen Nachteil, denn Computerbenutzer haben keinen direkten physischen Zugang zu ihren Daten mehr.

Bei Computerausfällen fragen sich Benutzer zuweilen, ob die Computerisierung wirklich Fortschritte gebracht hat. Früher konnten Ordner nicht »abstürzen«, sondern höchstens mit lautem Krach auf dem Boden landen. Dann wurden die Blätter einfach wieder aufgesammelt und wieder in den Aktenordner geheftet. Außer bei Erdbeben können Aktenschränke kaum »abstürzen«. Fehlermeldungen zeigen sie Ihnen auch nie an. Festplattenabstürze sind hingegen etwas ganz anderes: Verloren gegangene Bits und Bytes lassen sich nicht einfach vom Boden »aufheben«. Mechanische, elektronische und menschliche Fehlfunktionen können dazu führen, dass Ihre Daten ins »Nirwana« verschwinden und für immer verloren sind.

Wenn Sie sich aber mit den gebotenen Vorsichtsmaßnahmen gegen zufällige Datenverluste schützen, können Sie die Vorteile nutzen, die Ihnen Computer mit ihrer höheren Geschwindigkeit und Präzision bieten.

Im modernen Arbeitsumfeld müssen Sie gerade bei wichtigen Datenbanken darauf aufpassen, dass sie möglichst gut geschützt werden. Externe Zugriffe von außen sollten nur möglich sein, wenn es wirklich erforderlich ist.

Wenn Sie wichtige Daten speichern, müssen Sie Ihr Augenmerk folgenden vier Bereichen widmen:

Die Daten müssen schnell und einfach gespeichert werden, weil dieser Vorgang sehr häufig notwendig ist.

Die Speichermedien müssen zuverlässig arbeiten. Sie wollen schließlich später keine böse Überraschung erleben und feststellen, dass Ihre Daten ganz oder teilweise verschwunden sind.

Die Daten müssen schnell und einfach abgerufen werden können, und zwar unabhängig von der Menge der gespeicherten Daten.

Sie benötigen einfache Möglichkeiten, um genau die gewünschten Daten aus der Masse der gespeicherten Daten herauszufiltern.

Moderne Computer-Datenbanken, die sich auf dem Stand moderner Technik befinden, erfüllen diese vier Kriterien. Wenn Sie mehr als einige Dutzend Datenelemente speichern müssen, sollten Sie dafür Datenbanken verwenden.

Was ist eine Datenbank?

Mit der Entwicklung der Computer hat der Begriff Datenbank seine ursprüngliche Bedeutung recht weitgehend verloren. Einige betrachten jede Sammlung von Datenelementen (Telefonbücher, Einkaufszettel, Schriftrollen und so weiter) als Datenbank. Andere definieren den Begriff präziser.

In diesem Buch wird eine Datenbank als selbstbeschreibende Sammlung integrierter Datensätze beschrieben. Und diese Definition setzt neben Computertechnologien Programmiersprachen wie SQL voraus.

Bei einem Datensatz handelt es sich um die Repräsentation eines physischen oder konzeptionellen Objekts. Wenn Sie beispielsweise Kunden einer Firma verwalten wollen, legen Sie für jeden Kunden einen Datensatz an. Jeder Datensatz enthält ein oder mehrere Attribute, wie beispielsweise den Namen, die Adresse oder die Telefonnummer. Einzelne Namen, Adressen und so weiter bilden die eigentlichen Daten oder Datenelemente.

Eine Datenbank besteht aus Daten und Metadaten. Metadaten beschreiben dabei die Struktur der Daten innerhalb der Datenbank. Wenn Sie wissen, wie Ihre Daten strukturiert sind, können Sie sie abrufen. Eine Datenbank ist selbstbeschreibend, weil sie eine Beschreibung ihrer eigenen Struktur enthält. Die Datenbank ist integriert, weil sie neben den Datenelementen auch Beziehungen zwischen den Datenelementen enthält.

Die Datenbanken speichern Metadaten in einem Bereich, der Datenverzeichnis (englisch Data Dictionary) genannt wird und der die Tabellen, Spalten, Indizes, Einschränkungen (Bedingungen) und andere Elemente beschreibt, aus denen die Datenbank besteht.

Weil flache Dateisysteme (die später in diesem Kapitel beschrieben werden) keine Metadaten enthalten, müssen mit flachen Dateien arbeitende Anwendungen die den Metadaten entsprechenden Angaben im Programm enthalten. Anders ausgedrückt, muss dann das Programm selbst die Struktur der Daten kennen.

Datenbankgröße und -komplexität

Datenbanken gibt es mit allen möglichen Datenmengen, angefangen bei einfachen Sammlungen mit wenigen Datensätzen bis hin zu Millionen Datensätzen und mehr. Die meisten Datenbanken lassen sich in eine von drei Kategorien einordnen, die von der Größe der Datenbank selbst, der relativen Kapazität der Computer, auf denen sie laufen, und der Größe der Organisationen abhängen, von denen sie betrieben werden:

Eine

persönliche Datenbank

ist für die Benutzung durch eine einzige Person auf einem einzigen Computer bestimmt. Derartige Datenbanken sind meist recht einfach strukturiert und relativ klein.

Eine

Abteilungs

- oder

Arbeitsgruppendatenbank

ist für die Benutzung durch die Mitglieder einer einzelnen Abteilung oder Arbeitsgruppe innerhalb eines Unternehmens vorgesehen. Diese Art Datenbank ist meist umfangreicher als eine persönliche Datenbank und demgemäß auch komplexer, weil sie mehrere Benutzer verwalten muss, die gemeinsam auf dieselben Daten zugreifen.

Eine

Unternehmensdatenbank

kann riesig sein. Unternehmensdatenbanken können den gesamten geschäftskritischen Informationsfluss großer Unternehmen abbilden.

Was ist ein Datenbankverwaltungssystem?

Gut, dass Sie das fragen. Ein Datenbankverwaltungssystem (DBMS – Database Management System) ist ein Satz von Programmen, mit denen Sie Datenbanken und die dazugehörigen Anwendungen definieren, verwalten und ausführen können. Eine verwaltete Datenbank ist im Wesentlichen eine Struktur zum Speichern von Daten, die für Sie oder Ihr Unternehmen wichtig sind. Ein DBMS ist ein Werkzeug, mit dem Sie eine derartige Struktur erstellen können, um die darin enthaltenen Daten bearbeiten zu können.

Heute werden viele Datenbankverwaltungssysteme angeboten. Einige laufen nur auf Servern, andere nur lokal auf Arbeitsrechnern, wie PCs, Laptops oder Tablets. Die Entwicklung geht jedoch deutlich in Richtung von Produkten, die von mehreren Plattformen unterstützt werden und in unterschiedlichen Netzwerken mit Rechnern verschiedener Leistungsklassen arbeiten können. Sehr viele Anwendungen besitzen Bedienoberflächen für Internet-Browser. Noch ausgeprägter ist der Trend, Daten in der Cloud zu speichern. Dieser Speicher kann heute von privaten Unternehmen oder auch einzelnen Personen, aber auch von großen Unternehmen wie etwa Amazon, Google oder Microsoft bereitgestellt werden. Dabei kann man zwischen privater und öffentlicher Cloud unterscheiden. Bereitgestellt werden die Daten irgendwo »in den Wolken« über das Internet. Lediglich der Zugang zu den Daten wird in einer privaten Cloud eingeschränkt. Im Grunde handelt es sich dann um eine Erweiterung des firmeninternen Intranets bis hinein ins Internet.

Der Begriff Cloud ist heute zwar einigermaßen unscharf definiert, aber in aller Munde. Eigentlich besteht eine Cloud lediglich aus einer Ansammlung von Computer-Ressourcen, auf die irgendwie mit einem Browser oder einer Anwendung über das Internet oder im privaten Intranet zugegriffen werden kann. Der Nebel der »Wolken« verhüllt lediglich, wo sich die benutzten Computer-Ressourcen in der Cloud befinden, also ob sich diese in physischen Rechenzentren mit bekanntem Standort oder vielleicht bei Google oder Amazon irgendwo auf dem Planeten auf angemieteten Geräten befinden. Der Datenzugriff muss dabei nicht zwangsläufig mit einem Browser erfolgen, da sich die gleichen Funktionen selbstverständlich auch mit geeignet programmierten und vorkonfigurierten Apps realisieren lassen.

Ein DBMS, das auf mehreren verschiedenen großen und kleinen Plattformen läuft, nennt man skalierbar.

Unabhängig von der Leistung des Computers, auf dem die Datenbank läuft, und davon, ob der Rechner in ein Netzwerk eingebunden ist, bleibt der Informationsfluss zwischen der Datenbank und dem Benutzer gleich. Abbildung 1.1 zeigt, wie Benutzer über das DBMS mit der Datenbank kommunizieren. Das Datenbankverwaltungssystem verbirgt die physischen Details der Datenbankspeicherung, weshalb die Anwendung nur die logischen Eigenschaften der Daten, nicht aber deren physische Speicherform kennen muss.

Abbildung 1.1: Blockdiagramm eines DBMS-Informationssystems

Nicht die Daten, sondern die Struktur stellen den Wert dar

Vor vielen Jahren hat eine kluge Person berechnet, dass der Materialwert eines Menschen nur knapp einen Euro beträgt, wenn man ihn auf Kohlenstoff, Wasserstoff, Sauerstoff und Stickstoff sowie die Spurenelemente reduziert, aus denen er besteht. Diese Rechnung ist jedoch nicht nur skurril, sondern auch irreführend. Menschen bestehen nicht nur aus einem Haufen Atome. Unsere Atome bilden Enzyme, Eiweiße, Hormone und viele andere Substanzen, für die in der Pharmaindustrie auf dem Markt teilweise Millionen Euro pro Kilo bezahlt werden würden. Für den Wert sorgen die spezifischen Strukturen, die von den Atomen gebildet werden. Ähnlich ermöglicht die Datenbankstruktur eine Interpretation scheinbar bedeutungsloser Daten. Die Struktur enthüllt Muster, Trends und Tendenzen in den Daten. Unstrukturierte und isolierte Daten besitzen dagegen – wie die unverbundenen Atome – nur einen geringen Wert.

Flache Dateien

Die einfachste Sammlung strukturierter Daten stellt eine sogenannte flache Datei dar. Flache Dateien besitzen nur eine minimale Struktur. Sie bestehen einfach aus einer Sammlung von Datensätzen, die nacheinander in einem bestimmten Format in einer Liste angeordnet sind – sie enthält die Daten, die ganzen Daten und nichts als die Daten. Für Computer sind flache Dateien sehr einfach aufgebaut. Weil die Dateien keinerlei Informationen über ihre eigene Struktur enthalten (keine Metadaten), ist der enthaltene Overhead (Informationen in der Datei, die selbst keine Daten sind, aber Speicherplatz belegen) minimal.

Angenommen, Sie wollten die Namen und Adressen der Kunden Ihrer Firma in einer flachen Datei verwalten. Diese soll ähnlich wie das folgende Beispiel strukturiert sein:

Klaus Klawuttke Heimweg 15 12345 BerlinJerry Cotton Gasse 77 48787 HermannsburgAdrian Hansen Perlenallee 3 58789 OberstadtJohann Bäcker Terrenshof 128 98755 GermsdorfMichael Pens Kalauerweg 1 57730 KölnBarbara Michimoto Sandufer 9 25252 KielLinda Schmidt Vennweg 56 44134 DüsseldorfRobert Funnell Kölner Ring 9 24240 LübeckBoris Reckal Am Hof 9 59554 SiegenKevin Kirenberg Pferdeweg 7 35305 Kassel

Diese Datei enthält nur Daten. Jedes Feld hat eine feste Länge (das Namensfeld ist beispielsweise immer genau 18 Zeichen lang) und ein Feld wird vom anderen nicht durch Strukturen getrennt. Die Person, die die Datenbank entworfen hat, hat die Feldpositionen und Längen vorgegeben. Alle Programme, die diese Datei benutzen, müssen diese Felddefinitionen »kennen«, da diese Angaben nicht in der Datenbank selbst gespeichert sind.

Wegen des geringen Overheads kann man mit flachen Dateien sehr schnell arbeiten. Nachteilig ist jedoch, dass Anwendungsprogramme zusätzliche Logik enthalten müssen, um die Daten einer flachen Datei auf Detailebene bearbeiten zu können. Die Anwendung muss genau wissen, wo und wie die Daten in der Datei gespeichert sind. Flache Dateien eignen sich für kleinere Systeme. Je umfangreicher das System jedoch wird, desto umständlicher wird die Verarbeitung flacher Dateisysteme.

Wenn Sie stattdessen eine Datenbank benutzen, können Sie den Doppelaufwand verringern. Obwohl Datenbankdateien möglicherweise einen größeren Overhead haben, können die Anwendungen leichter auf andere Hardware- und Betriebssystemplattformen übertragen werden. Außerdem erleichtern Datenbanken das Schreiben von Anwendungsprogrammen, weil Programmierer keine Details über den Speicherort und die Speicherform der Daten wissen müssen.

Datenbanken vermeiden Doppelarbeit, weil das DBMS die Details der Datenbearbeitung übernimmt. Bei Anwendungen, die mit flachen Dateien arbeiten, müssen alle Einzelheiten im Anwendungscode programmiert werden. Wenn mehrere Anwendungen auf dieselben flachen Dateien zugreifen, muss jede Anwendung (redundant) den gesamten Code für die Datenbearbeitung enthalten. Bei einem DBMS ist dieser Code in der Anwendung überflüssig.

Verständlicherweise ist es nicht einfach, eine Anwendung von einer Plattform auf eine andere zu portieren, wenn sie mit flachen Dateien arbeitet und plattformspezifischen Code zur Datenmanipulation enthält, weil Sie zunächst den gesamten spezifischen Hardware-Code ändern müssen. DBMS-basierte Anwendungen lassen sich sehr viel leichter auf andere Plattformen portieren.

Datenbankmodelle

Die ersten Datenbanken, die in den 1950er-Jahren eingeführt wurden, waren nach dem hierarchischen Modell strukturiert. Sie litten unter Redundanzproblemen, und ihre inflexible Struktur erschwerte Datenbankänderungen. Bald darauf folgten Datenbanken, die nach dem Netzwerkmodell strukturiert waren und die Hauptnachteile der hierarchischen Datenbanken beseitigen sollten. Netzwerkdatenbanken verfügen über eine minimale Redundanz auf Kosten einer hohen strukturellen Komplexität.

Einige Jahre später entwickelt Dr. E. F. Codd bei IBM das relationale Modell, das minimale Redundanz und leicht verständliche Struktur miteinander kombiniert. Die Sprache SQL wurde für das Arbeiten mit relationalen Datenbanken entwickelt. Relationale Datenbanken haben hierarchische Datenbanken und Netzwerkdatenbanken fast vollständig verdrängt.

Seit etlichen Jahren werden auch sogenannte NoSQL-Datenbanken auf den Markt gebracht. Diese sind nicht wie relationale Datenbanken strukturiert und arbeiten nicht mit SQL als Abfragesprache. NoSQL-Datenbanken werden in diesem Buch nicht behandelt.

Das relationale Modell

E. F. Codd, der bei IBM arbeitete, formulierte das relationale Datenbankmodell erstmals im Jahre 1970. Es dauerte etwa ein Jahrzehnt, bis dieses Modell für Datenbankprodukte verwendet wurde. Es entbehrt nicht einer gewissen Ironie, dass nicht die Firma IBM das erste relationale DBMS lieferte. Diese Ehre wurde einer kleinen, neu gegründeten Firma zuteil, die ihr Produkt Oracle nannte.

Relationale Datenbanken haben Datenbanken der früher verwendeten Modelle weitgehend verdrängt, weil man die Struktur relationaler Datenbanken ändern kann, ohne die Anwendungen ändern zu müssen, die noch mit der alten Struktur gearbeitet haben. Angenommen, Sie wollten eine oder mehrere neue Spalten in eine Datenbanktabelle einfügen. Dann müssen Sie vorher erstellte Anwendungen, die mit dieser Tabelle arbeiten, nur dann ändern, wenn Sie eine oder mehrere der in den Anwendungen verwendeten Spalten ändern.

Wenn Sie eine Spalte löschen, auf die eine vorhandene Anwendung Bezug nimmt, die also von einer vorhandenen Anwendung referenziert wird, bekommen Sie natürlich Probleme, und zwar unabhängig vom verwendeten Datenbankmodell. Eine der wirksamsten Methoden, einen Fehler in einer Datenbankanwendung zu verursachen, besteht darin, Daten aus Spalten abzurufen, die in der Datenbank nicht vorhanden sind.

Komponenten relationaler Datenbanken

Die Flexibilität relationaler Datenbanken beruht darauf, dass ihre Daten in Tabellen gespeichert werden, die im Wesentlichen unabhängig voneinander sind. Sie können in einer Tabelle Daten einfügen, ändern oder löschen, ohne dadurch die Daten in den anderen Tabellen zu beeinflussen, sofern die betroffene Tabelle den anderen Tabellen nicht übergeordnet ist. (Die Beziehungen der Über- und Unterordnung zwischen Tabellen werden in Kapitel 5 erklärt.) In diesem Abschnitt zeige ich, woraus diese Tabellen bestehen und in welcher Beziehung sie zu den Komponenten einer relationalen Datenbank stehen.

Was sind Relationen?

Datenbanken bestehen aus miteinander verknüpften Tabellen. In der Datenbankterminologie werden diese Tabellen auch Relationen genannt. Eine relationale Datenbank besteht also aus einer oder mehreren Relationen.

Eine Relation ist eine zweidimensionale, aus Zeilen und Spalten bestehende Anordnung von Feldern, auch Array genannt, die nur Einträge eines Typs von Datenwerten und keine identischen Zeilen enthalten kann. Jede Zelle des Arrays darf nur einen Wert enthalten. Keine zwei Zeilen dürfen identisch sein.

Ein Beispiel: Die meisten Benutzer kennen zweidimensionale Arrays, die aus Zeilen und Spalten bestehen, in Form von Arbeitsblättern elektronischer Tabellenkalkulationen (wie zum Beispiel Microsoft Excel). Die auf der Rückseite der Baseball-Karten von Baseball-Spielern der Major-League aufgedruckte Offensivstatistik stellt ein weiteres Beispiel für ein Datenfeld dar. Die Baseball-Karte enthält Spalten für das Jahr, die Mannschaft (Team), die geleisteten Spiele sowie für die verschiedenen Leistungskriterien (At Bat, Hits, Runs und so weiter), die in der Baseball-Welt eine Rolle spielen. Eine Zeile fasst die Daten eines Jahres zusammen, in dem der Spieler in der Major-League gespielt hat. Sie können diese Daten auch in einer Relation (einer Tabelle) speichern, die dieselbe Grundstruktur hat. Abbildung 1.2 zeigt eine relationale Datenbanktabelle, die die Offensivstatistik eines Spielers der Major-League enthält. Im praktischen Einsatz würde eine solche Tabelle die statistischen Daten einer ganzen Mannschaft oder möglicherweise der gesamten Liga enthalten.

Abbildung 1.2: Tabelle mit der Offensivstatistik eines Baseball-Spielers

Spalten in der Tabelle sind in dem Sinne konsistent, als eine Spalte in jeder Zeile dieselbe Bedeutung hat. Wenn eine Spalte in einer Zeile den Nachnamen eines Spielers enthält, muss die Spalte in allen Zeilen den Nachnamen eines Spielers enthalten. Die Reihenfolge, in der Zeilen und Spalten in einer Tabelle erscheinen, spielt dabei keine Rolle. Aus der Sicht des DBMS ist es deshalb gleichgültig, welche Spalte an erster, welche an zweiter und welche an letzter Stelle steht. Das DBMS verarbeitet die Tabelle unabhängig von deren Aufbau.

Jede Spalte einer Datenbanktabelle stellt ein einzelnes Attribut der Tabelle dar. Die Bedeutung einer Spalte ist für alle Zeilen der Tabelle gleich. Eine Tabelle kann beispielsweise die Namen, Adressen und Telefonnummern aller Kunden einer Firma enthalten. Zeilen in der Tabelle, die auch Datensatz oder Tupel genannt werden, enthalten jeweils die Daten eines einzelnen Kunden. Jede Spalte enthält ein einzelnes Attribut des Kunden, wie zum Beispiel die Kundennummer (KundenNr), die Firma (Unternehmen), die Straße (Anschrift1) und so weiter. Abbildung 1.3 zeigt einige Zeilen und Spalten einer solchen Tabelle.

Abbildung 1.3: Jede Tabellenzeile enthält einen Datensatz; jede Spalte enthält ein einzelnes Attribut.

Die Relationen in diesem Datenbankmodell entsprechen den Tabellen einer auf dem Modell basierenden Datenbank.

Views oder Sichten

Tabellen können viele Spalten und Zeilen enthalten. Manchmal interessieren Sie sich für alle Daten, bei umfangreichen Tabellen aber oft auch nicht. Möglicherweise möchten Sie nur einige der Spalten einer Tabelle sehen oder nur Zeilen, die einer bestimmten Bedingung genügen. Vielleicht möchten Sie einige Spalten einer Tabelle und einige andere Spalten einer mit ihr verknüpften Tabelle sehen. Um die Daten auszuschließen, die Sie augenblicklich nicht interessieren, erstellen Sie eine sogenannte Sicht (englisch View). Eine Sicht ist eine Untermenge einer Datenbank. Diese Untermenge kann von einer Anwendung verarbeitet werden. Eine Sicht kann Ausschnitte einer oder mehrerer Tabellen enthalten.

Sichten werden manchmal auch virtuelle Tabellen genannt. Aus der Perspektive von Anwendungen oder Benutzern verhalten sich Sichten wie Tabellen. Sichten existieren jedoch nicht unabhängig von Tabellen. Mit Views können Sie Daten betrachten, wobei die Views selbst kein Bestandteil der Daten sind.

Angenommen, Sie arbeiten mit einer Datenbank, in der die beiden Tabellen Kunde und Rechnung enthalten sind. Die Tabelle Kunde enthält die Spalten KundenNr, Vorname, Nachname, Strasse, Ort, Land, Plz und Tel. Die Tabelle Rechnung verfügt über die Spalten RechnungNr, KundenNr, Datum, Umsatz, Bezahlt und Zahlungsart.

Ein Verkaufsleiter will nur den Vornamen (Vorname), den Nachnamen (Nachname) und die Telefonnummer (Tel) eines jeweiligen Kunden auf dem Bildschirm sehen. Der Verkaufsleiter kann nun für die Tabelle Kunde eine Sicht erstellen, die nur die drei benötigten Spalten und nicht auch noch die momentan überflüssigen Informationen aus anderen Spalten enthält. Abbildung 1.4 zeigt die vom Verkaufsleiter erstellte Sicht.

Abbildung 1.4: Die für den Verkaufsmanager definierte View wird von der Tabelle KUNDE abgeleitet.

Ein Zweigstellenleiter benötigt die Namen und Telefonnummern aller Kunden, deren Postleitzahl zwischen 90000 und 93999 liegt. Eine Sicht, die von ihr abgerufene Zeilen und angezeigte Spalten mit einer sogenannten Einschränkung versieht und sie damit filtert, führt diese Aufgabe aus. Abbildung 1.5 zeigt die Datenquellen für die Spalten der Sicht des Zweigstellenleiters.

Abbildung 1.5: Die Sicht des Zweigstellenleiters enthält nur bestimmte Zeilen der Tabelle KUNDE.

Der Buchhaltungsleiter möchte die Kundennamen der Tabelle Kunde und die Spalten Datum, Umsatz, Bezahlt und Zahlungsart der Tabelle Rechnung sehen, bei denen Bezahlt kleiner als Umsatz ist. Die zuletzt genannte Bedingung ist erfüllt, wenn eine Rechnung noch nicht vollständig beglichen wurde. Für diese Sicht müssen Sie Daten aus beiden Tabellen kombinieren. Abbildung 1.6 zeigt, wie Daten der Tabellen Kunde und Rechnung in die Sicht des Buchhaltungsleiters einfließen.

Abbildung 1.6: In der View für den Buchhaltungsleiter werden Daten aus zwei Tabellen kombiniert.

Sichten sind nützlich, weil sie es ermöglichen, Daten aus Datenbanken zu extrahieren und geeignet zu formatieren, ohne dabei an den gespeicherten Daten wirklich etwas zu ändern. Zugleich bieten sie auch für jene Daten einen gewissen Schutz, die nicht angezeigt werden sollen, weil sie in den Sichten nicht enthalten sind. In Kapitel 6 erfahren Sie, wie mit SQL Sichten erstellt werden.

Schemata, Domänen und Einschränkungen

Eine Datenbank ist mehr als eine Sammlung von Tabellen. Zusätzliche Strukturen werden über mehrere Schichten verteilt und helfen, die Integrität der Daten zu wahren. Das Schema einer Datenbank sorgt für die übergreifende Organisation der Tabellen. Die Domäne einer Tabellenspalte sagt Ihnen, welche Werte Sie in der Spalte speichern dürfen. Sie können Einschränkungen (Constraints) für eine Datenbanktabelle definieren, um zu verhindern, dass unzulässige Daten in der Tabelle gespeichert werden können.

Schemata

Die Struktur einer ganzen Datenbank wird als ihr Schema oder als konzeptionelle Sicht und manchmal auch vollständige logische Sicht der Datenbank genannt. Das Schema gehört zu den Metadaten und ist damit ein Teil der Datenbank. Die Metadaten selbst, die die Struktur der Datenbank beschreiben, werden wie normale Daten in Tabellen gespeichert. Damit sind sogar Metadaten nichts anderes als Daten, und das ist das Gute an ihnen.

Domänen

Ein Attribut einer Relation (das heißt die Spalte einer Tabelle) kann eine endliche Anzahl von Werten annehmen. Die Gesamtmenge dieser Werte, also die Wertemenge, wird im Relationenmodell Domäne des Attributs genannt.

Angenommen, Sie verkaufen als Autohändler das neue Curarri GT 4000 Sportcoupé. Sie verwalten die Autos, die Sie am Lager haben, in einer Datenbanktabelle mit dem Namen LAGER. Eine Spalte dieser Tabelle hat den Namen Farbe, in der die Farbe jedes Autos gespeichert wird. Der GT 4000 wird nur in vier Farben geliefert: Lippenrot, Mitternachtsschwarz, Schneeweiß und Metallicgrau. Diese vier Farben bilden die Domäne des Attributs Farbe.

Einschränkungen

Einschränkungen (Constraints) sind eine wichtige, gleichwohl oft übersehene Komponente einer Datenbank. Einschränkungen sind Regeln, die festlegen, welche Werte die Attribute einer Tabelle annehmen dürfen.

Wenn Sie Einschränkungen für eine Spalte definieren, können Sie verhindern, dass Benutzer ungültige Daten in diese Spalte eingeben. Natürlich muss jeder Wert, der in der Domäne der Spalte gültig wäre, auch alle ihre Einschränkungen berücksichtigen. Wie ich im vorangegangenen Abschnitt erläutert habe, bildet die zulässige Wertemenge der Spalte ihre Domäne. Eine Einschränkung schränkt diese Werte ein. Die Eigenschaften einer Tabellenspalte definieren zusammen mit den Einschränkungen, die auf diese Spalte angewendet werden, die Spaltendomäne.

Bei dem Beispiel des Autohändlers könnten Sie eine Einschränkung so definieren, dass die Datenbank in der Spalte Farbe nur die vier zulässigen Werte akzeptiert. Falls ein Benutzer dann versuchen sollte, eine andere Farbe, wie zum Beispiel Waldgrün, in die entsprechende Spalte einzugeben, weist das System die Eingabe zurück. Die Dateneingabe kann nur dann fortgesetzt werden, wenn der Benutzer eine gültige Farbe in das Feld Farbe eingibt.

Vielleicht fragen Sie sich, was passiert, wenn der Hersteller Curarri eine waldgrüne Version des GT 4000 als Sommeroption anbietet. Die Antwort impliziert eine Arbeitsplatzgarantie für Datenbankprogrammierer, denn derartige Dinge passieren immer wieder und erfordern Anpassungen der Datenbankstruktur. Dann können nur Fachleute (zu denen auch Sie gehören), die die Strukturen zu ändern wissen, größere Katastrophen verhindern.

Das Objektmodell fordert das relationale Modell heraus

Das relationale Modell hat in vielen Anwendungsbereichen fantastische Erfolge gefeiert. Es ist jedoch nicht frei von Problemen. Diese Probleme wurden mit zunehmender Beliebtheit objektorientierter Programmiersprachen, zum Beispiel C++, Java und C#, immer deutlicher. Solche Sprachen können komplexere Probleme leichter handhaben als traditionelle Sprachen, weil sie über Funktionen verfügen, wie beispielsweise durch Benutzer erweiterbare Datentypen, Kapselung, Vererbung, dynamische Bindung von Methoden, komplexe und zusammengesetzte Objekte und Objektidentitäten.

Ich werde nicht alle diese Begriffe in diesem Buch erklären (obwohl Sie einigen später begegnen werden). Es reicht aus zu wissen, dass das klassische relationale Modell nicht mit allen diesen Funktionalitäten klarkommt. Deshalb werden Datenbankverwaltungssysteme entwickelt und angeboten, die auf dem Objektmodell basieren. Allerdings haben sie zurzeit nur einen relativ kleinen Marktanteil.

Das objektrelationale Modell

Datenbankentwickler streben wie fast jedermann danach, für ihre Aufgaben möglichst die besten aller Lösungen zu finden. Deshalb versuchten einige, die Vorteile eines objektorientierten Datenbanksystems mit denen des erfolgreichen relationalen Systems zu verbinden und dabei die Kompatibilität zu Letzterem zu bewahren. Das Ergebnis dieser Bemühungen ist das objektrelationale Hybridmodell. Objektrelationale Datenbankverwaltungssysteme erweitern das relationale Modell um die Fähigkeit, Daten objektorientiert zu modellieren. Der internationale SQL-Standard wurde um objektorientierte Funktionalitäten erweitert. Damit erhalten die Anbieter relationaler Datenbankverwaltungssysteme die Möglichkeit, ihre Produkte zu objektrelationalen Datenbankverwaltungssystemen auszubauen und dabei die Kompatibilität zum Standard zu wahren. Im Gegensatz zu dem SQL-92-Standard, der ein rein relationales Datenbankmodell definiert, beschreibt SQL:1999 deshalb ein objektrelationales Datenbankmodell. SQL:2003 enthält mehr objektorientierte Funktionen; und die nachfolgenden SQL-Versionen wurden in dieser Richtung weiterentwickelt.

Ich beschreibe in diesem Buch den internationalen ISO-/IEC-SQL-Standard. (IEC steht für International Electrotechnical Commission, aber das spielt eigentlich keine Rolle. Wie viele Menschen wissen, wofür die Buchstaben der Abkürzung LASER stehen?) Dabei handelt es sich hauptsächlich um ein relationales Datenbankmodell. Außerdem beschreibe ich die objektorientierten Erweiterungen, die mit SQL:1999 eingeführt wurden, sowie die zusätzlichen Erweiterungen aus späteren SQL-Versionen. Die objektorientierten Funktionalitäten des neuen Standards geben Entwicklern die Möglichkeit, SQL-Datenbanken für die Lösung von Problemen einzusetzen, die für den früheren, rein relationalen Ansatz zu komplex waren. Anbieter von DBMS-Systemen wie zum Beispiel Oracle bauten die objektorientierten Funktionen aus dem ISO-Standard in ihre Produkte ein. Einige dieser Funktionen werden schon seit Jahren angeboten, während andere noch nicht in die Sprache integriert wurden.

Überlegungen zum Datenbankentwurf

Eine Datenbank ist eine Repräsentation einer physischen oder konzeptionellen Struktur, wie eines Unternehmens, der Montage eines Autos oder der Erfolgsstatistik aller Mannschaften der Bundesliga. Die Genauigkeit dieser Repräsentation hängt davon ab, wie detailliert Ihr Datenbankentwurf ist. Der Aufwand, den Sie in den Datenbankentwurf investieren, sollte von der Art der Informationen abhängen, die Ihnen die Datenbank liefern soll. Mit zu vielen Details wird nur Arbeit, Zeit und Speicherplatz verschwendet. Doch zu wenig Details können Datenbanken wiederum wertlos werden lassen. Näheres zum Datenbankentwurf finden Sie beispielsweise in »Datenbanksysteme für Dummies«.

Kapitel 2

SQL-Grundlagen

IN DIESEM KAPITEL

SQL verstehenMit falschen Vorstellungen über SQL aufräumenDie verschiedenen SQL-StandardsStandard-SQL-Anweisungen und reservierte WörterDarstellung von Zahlen, Zeichen, Datumsangaben, Zeiten und anderen DatentypenNullwerte und EinschränkungenSQL in einem Client/Server-System einsetzenSQL im Netzwerk

SQL ist eine flexible Sprache, die für verschiedene Aufgaben eingesetzt werden kann. Wenn es um die Kommunikation mit relationalen Datenbanken geht, handelt es sich bei SQL um das meistbenutzte Werkzeug. In diesem Kapitel beschreibe ich zunächst, was SQL ist und was es nicht ist, und damit insbesondere auch, worin sich SQL von anderen Computersprachen unterscheidet. Dann stelle ich die von Standard-SQL unterstützten Anweisungen und Datentypen vor und erläutere die Schlüsselbegriffe Nullwerte und Einschränkungen. Schließlich erhalten Sie einen Überblick darüber, wie SQL in Client/Server-Umgebungen, im Internet und im Intranet eines Unternehmens eingesetzt werden kann.

Da es in diesem Kapitel um eine ganze Menge formeller Aspekte von SQL geht, kann es Ihnen möglicherweise ein wenig zu »trocken« werden. Sie können Großteile dieser theoretischen Grundlagen aber durchaus zurückstellen und das Kapitel erst einmal nur überfliegen oder vielleicht sogar ganz zurückstellen, um zu den benötigten Teilen erst bei Bedarf zurückzukehren.

Was SQL ist und was es nicht ist

Das Erste, was Sie von SQL verstehen müssen, ist, dass es sich dabei nicht um eine prozedurale Sprache wie BASIC, C, C++ oder Java handelt. Um in einer dieser Sprachen eine Problemstellung zu lösen, schreiben Sie eine Prozedur, die eine Reihe von Operationen nacheinander ausführt, bis die Aufgabe erledigt ist. Die Prozedur kann aus einer linearen Abfolge von Schritten bestehen oder Schleifen enthalten, die wiederholt verarbeitet werden. Auf jeden Fall wird die Verarbeitungsreihenfolge aber vom Programmierer fest vorgegeben.

SQL ist dagegen nicht prozedural. Um ein Problem mit SQL zu lösen, teilen Sie SQL einfach mit, was Sie wollen (so, als wenn Sie zu Aladins Flaschengeist sprächen), anstatt dem System zu sagen, wie es die Aufgabe lösen soll. Das Datenbankmanagementsystem (DBMS) wählt den besten Weg aus, um die Aufgabe zu erfüllen.

Wie gerade erwähnt, ist SQL keine prozedurale Sprache. Das ist im Wesentlichen wahr. Nun sind Millionen von Programmierern (zu denen Sie möglicherweise auch gehören) gewohnt, Probleme prozedural zu lösen. Deshalb gab es in den letzten Jahren auch Bestrebungen, SQL um prozedurale Funktionalitäten zu erweitern. Deshalb wurden in SQL mittlerweile Bestandteile prozeduraler Sprachen, wie BEGIN-Blöcke, IF-Anweisungen, Funktionen und Prozeduren, eingebaut. Deshalb können Sie auf einem Server auch Anwendungen ablegen, die von diversen Clients wiederholt verwendet werden können.

Um zu verdeutlichen, was mit »dem System sagen, was Sie wollen« gemeint ist, nehmen Sie bitte an, dass Sie mit einer Mitarbeitertabelle arbeiten und jene Zeilen abrufen wollen, in denen Mitarbeiter mit erheblicher Berufserfahrung gespeichert sind. Dabei sollen Mitarbeiter als »erfahren« gelten, wenn sie älter als 40 Jahre sind oder mehr als 60.000 Euro jährlich verdienen. Die gewünschten Daten können Sie erhalten, wenn Sie die folgende Abfrage verwenden:

SELECT * FROM Mitarbeiter WHERE Lebensalter> 40 OR Gehalt> 60000 ;

Diese Anweisung ruft alle Zeilen einer Tabelle namens Mitarbeiter ab, bei denen entweder der Wert in der Spalte Lebensalter größer als 40 oder der Wert in der Spalte Gehalt größer als 60.000 ist. Wenn Sie SQL verwenden, müssen Sie nicht selbst festlegen, wie die Informationen abgerufen werden sollen. Stattdessen untersucht die Datenbank-Engine (die Software-Komponente, die die Interaktion und die Arbeit mit der Datenbank ermöglicht) die Datenbank und entscheidet dann, wie Ihr Auftrag am besten ausgeführt wird. Sie müssen nur angeben, welche Daten abgerufen werden sollen.

Eine Abfrage ist eine Frage, die Sie an die Datenbank richten. Gibt es in der Datenbank Daten, die die Bedingungen (Kriterien) Ihrer Abfrage erfüllen, werden sie von SQL abgerufen.

Den aktuellen Implementierungen von SQL fehlen viele der grundlegenden Sprachkonstrukte der meisten anderen Programmiersprachen. Fast alle praktischen Anwendungen benötigen mindestens einige dieser Sprachkonstrukte; deshalb ist SQL eigentlich keine vollständige Programmiersprache, sondern (nur) eine Spezialsprache zur Datenbearbeitung. Selbst mit den SQL-Erweiterungen von 1999, 2003, 2005, 2008 und 2011 müssen Sie SQL zusammen mit einer prozeduralen Sprache wie etwa C verwenden, um vollständige Anwendungen erstellen zu können.

Es gibt zwei Methoden, mit denen Sie Daten aus einer Datenbank extrahieren können:

Mit einer

Ad-hoc-Abfrage

von einer Computerkonsole aus, bei der Sie einfach eine SQL-Anweisung eintippen und das Ergebnis vom Bildschirm ablesen.

Konsole

ist dabei die traditionelle Bezeichnung für jene Hardware, die die Aufgaben von Tastatur und Bildschirm bei heutigen PCs übernimmt. Abfragen über die »Konsole« liefern schnelle Antworten auf spezifische Fragen. So können Sie auch direkt Daten aus Datenbanken abfragen, die ansonsten gar nicht oder nur selten benötigt werden. Geben Sie die entsprechende SQL-Abfrage über die Tastatur ein und entnehmen Sie das Ergebnis binnen kürzester Zeit der Bildschirmausgabe.

Mit der Ausführung eines Programms, das die Daten aus der Datenbank abruft und in einen Bericht schreibt, der entweder auf dem Bildschirm oder über einen Drucker ausgegeben wird.

SQL-Abfragen direkt in Programme oder Skripte einzubauen, eignet sich für komplexe Abfragen, die wiederholt verwendet werden sollen. Auf diese Weise müssen Sie die Abfrage nur einmal formulieren. In

Kapitel 15

erfahren Sie, wie Sie SQL-Code in Programme einbetten können, die mit höheren Programmiersprachen erstellt wurden.

Ein (sehr) kurzer historischer Überblick

SQL wurde, wie die Theorie der relationalen Datenbanken, in den IBM-Forschungslaboratorien entwickelt. In den frühen 1970er-Jahren, als sich die IBM-Forscher mit relationalen Datenbankmanagementsystemen (oder RDBMS) zu befassen begannen, entwickelten sie eine Datenuntersprache, um mit diesen Systemen arbeiten zu können. Ursprünglich nannten sie diese Untersprache SEQUEL (Structured English QUEry Language). Doch als die Abfragesprache offiziell auf dem Markt vorgestellt werden sollte, mussten sie feststellen, dass »Sequel« als Markenname bereits an ein anderes Unternehmen vergeben war. Deshalb suchten IBMs Marketing-Gurus nach einem Namen, der sich zwar von SEQUEL unterschied, aber dennoch eine gewisse Verwandtschaft kaum verleugnen konnte. So kamen sie auf das Kürzel SQL.

Die Syntax von SQL entspricht einer Art von strukturiertem Englisch, was auch der Grund für den ursprünglichen Namen war. Doch SQL ist keine strukturierte Sprache