27,99 €
Werden Sie zum SQL-Profi!
In diesem Buch erfahren Sie alles, was es über SQL zu wissen gibt. Angefangen mit den Grundlagen und der Frage, wie Sie Datenbanken erstellen, Daten ordnen und abfragen, lernen Sie zudem Entwicklungsumgebungen für die Datenbankenprogrammierung kennen. Auch das Thema Datensicherheit kommt nicht zu kurz: So lernen Sie, wie Sie Ihre Daten und Datenbanken schützen und wie Sie typische Fehler vermeiden. Sie erfahren außerdem, wie Sie andere Sprachen, wie XML und JSON, mit SQL integrieren und wie Sie die Leistung Ihrer Datenbank analysieren und optimieren.
Sie erfahren
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 1027
Veröffentlichungsjahr: 2024
SQL Alles-in-einem-Band für Dummies
SQL ist eine beliebte und nützliche Programmiersprache. Sie können noch mehr davon profitieren, wenn Sie die verschiedenen Phasen der SQL-Entwicklung, die Kriterien für Normalformen, die von SQL verwendeten Datentypen, ein wenig über Mengen- und Wertfunktionen sowie einige Tipps zum Filtern von Tabellen mit WHERE-Klauseln kennen.
Bei der Entwicklung eines jeden Systems fängt man am Anfang an und zieht es bis zum Ende durch, das ist bei SQL nicht anders. Die folgende Liste zeigt Ihnen, was Sie in den verschiedenen Phasen des Lebenszyklus der SQL-Entwicklung beachten müssen:
Definitionsphase: Definition der präzisen Aufgabenstellung, ihres Umfangs und der beteiligten Personen.Anforderungsphase: Erarbeiten einer detaillierten Beschreibung dessen, was genau durch die Entwicklungsarbeit erreicht werden soll. Sammeln Sie alle relevanten Informationen, und fassen Sie sie in einem Anforderungsdokument (Statement of Requirements) zusammen. Holen Sie die Genehmigung des Kunden ein.Bewertungsphase: Festlegen, wie die Anforderungen erfüllt werden sollen. Welche Tools werden Sie verwenden? Wie werden Sie Ihr Entwicklungsteam einsetzen? Überprüfen Sie, ob die Aufgabe innerhalb des Zeit- und Budgetrahmens machbar ist.Entwurfsphase: Erstellen eines Datenbankmodells und anschließender Entwurf einer Datenbank und einer Datenbankanwendung, die die Bedingungen des Anforderungsdokuments erfüllen.Implementierungsphase: Erstellen der Datenbank und der Datenbankanwendung. Fügen Sie eine ausführliche Dokumentation in den Code und in externe Dokumente ein.Abschließende Dokumentations- und Testphase: Stellen Sie die Datenbank und die Anwendung auf eine harte Probe. Beaufschlagen Sie das System mit allen vorstellbaren und einigen unvorstellbaren Eingabebedingungen. Versuchen Sie, das System zu überlasten. Beobachten Sie, wo es versagt. Wenn es versagt, geben Sie es zurück an die Entwickler oder sogar zurück an die Designer. Dokumentieren Sie alles.Wartungsphase: Behebung von latenten Fehlern, sobald sie auftreten. Bereitstellung von Aktualisierungen und Erweiterungen, die vom Kunden gewünscht werden.In SQL sind Normalformen die bestimmenden Merkmale von relationalen Datenbanken. SQL-Formen werden nach den Arten von Änderungsanomalien klassifiziert, denen sie unterliegen. Die erste, zweite und dritte Normalform (1NF, 2NF, 3NF) dienen als Abhilfe für die drei Hauptquellen von Änderungsanomalien.
Normalformen sind verschachtelt. Eine Tabelle, die in 2NF ist, ist automatisch auch in 1NF. Ebenso ist eine Tabelle in 3NF automatisch in 2NF und so weiter. Für die meisten praktischen Anwendungen reicht es aus, eine Datenbank in 3NF anzulegen, um ein hohes Maß an Integrität zu gewährleisten. Um sich ihrer Integrität absolut sicher zu sein, müssen Sie die Datenbank in DK/NF anlegen.
In den folgenden Listen sind die Kriterien für die einzelnen Formen aufgeführt:
Je nach ihrem Ursprung unterstützen die verschiedenen SQL-Implementierungen eine Vielzahl von Datentypen. Die SQL-Spezifikation kennt neun vordefinierte allgemeine Typen, die in den folgenden Listen aufgeführt sind
SQL-Wertfunktionen führen Operationen an Daten durch. Es gibt alle möglichen Operationen, die für Datenelemente durchgeführt werden können. Nachfolgend sind einige der am häufigsten verwendeten Funktionen aufgelistet.
Funktion
Wirkung
SUBSTRING
Extrahiert eine Teilzeichenfolge aus einer Quellzeichenfolge
SUBSTRING SIMILAR
Extrahiert eine Teilzeichenfolge aus einer Quellzeichenfolge unter Verwendung POSIX-basierter reguläre Ausdrücke
SUBSTRING_REGEX
Extrahiert aus einer Zeichenfolge das erste Vorkommen eines regulären XQuery-Ausdrucks und gibt ein Vorkommen derübereinstimmenden Teilzeichenfolge zurück.
TRANSLATE_REGEX
Extrahiert aus einer Zeichenfolge das erste oder jedes Vorkommen eines regulären XQuery-Ausdrucksmusters und ersetzt es oder sie durch eine XQuery-Ersatzzeichenfolge
UPPER
Konvertiert eine Zeichenfolge in Großbuchstaben
LOWER
Konvertiert eine Zeichenfolge in Kleinbuchstaben
BTRIM
Schneidet mehrere Zeichen vor und nach dem Text ab
LTRIM
Schneidet mehrere Zeichen links vom Text ab
RTRIM
Schneidet mehrere Zeichen rechts vom Text ab
TRIM
Schneidet führende oder nachlaufende Leerzeichen ab
LPAD
Fügt Füllzeichen auf der linken Seite des Textes ein
RPAD
Fügt Füllzeichen auf der rechten Seite des Texts ein
TRANSLATE
Wandelt eine Quellzeichenfolge von einem Zeichensatz in einen anderen um
CONVERT
Wandelt eine Quellzeichenfolge von einem Zeichensatz in einen anderen um
Funktion
Wirkung
POSITION
Gibt die Anfangsposition 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 Oktette (Bytes) in einer Zeichenfolge zurück
EXTRACT
Extrahiert ein einzelnes Feld aus einer Zeitangabe oder einem Intervall
Funktion
Wirkung
CURRENT_DATE
Gibt das aktuelle Datum zurück
CURRENT_TIME(p)
Gibt die aktuelle Zeit zurück; (p) ist die Genauigkeit in Sekunden
CURRENT_TIMESTAMP(p)
Gibt das aktuelle Datum und die aktuelle Uhrzeit zurück; (p) ist die Genauigkeit in Sekunden
Die SQL-Mengenfunktionen geben Ihnen eine schnelle Antwort auf Fragen, die Sie zu den Eigenschaften Ihrer Daten als Ganzes haben. Wie viele Zeilen hat eine Tabelle? Welches ist der höchste Wert in der Tabelle? Welches ist der niedrigste? Diese Fragen können Sie mit den SQL-Mengenfunktionen beantworten.
Funktion
Wirkung
COUNT
Gibt die Anzahl der Zeilen in der angegebenen Tabelle zurück
MAX
Gibt den höchsten Wert zurück, der in der angegebenen Tabelle vorkommt
MIN
Gibt den niedrigsten Wert zurück, der in der angegebenen Tabelle vorkommt
SUM
Addiert die Werte in einer angegebenen Spalte
AVG
Gibt den Durchschnitt aller Werte in der angegebenen Spalte zurück
ANY_VALUE
Gibt einen Zufallswert aus einer angegebenen Datenmenge zurück
GREATEST
Gibt den größten Wert aus einer angegebenen Datenmenge zurück
LEAST
Gibt den kleinsten Wert aus einer angegebenen Datenmenge zurück
LISTAGG
Wandelt Werte aus einer Gruppe von Zeilen in eine abgegrenzte Zeichenfolge um
Trigonometrische und logarithmische Funktionen
sin, cos, tan, asin, acos, atan, sinh, cosh, tanh, log(<Basis>, <Wert>), log10(<Wert>), ln( <Wert>)
JSON_OBJECT
JSON_ARRAY
JSON_OBJECTAGG
JSON_ARRAYAGG
JSON_EXISTS
JSON_VALUE
JSON_QUERY
JSON_TABLE
SQL Alles-in-einem-Band 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.
1. Auflage 2025
© 2025 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, Germany
Original English language edition SQL All-In-One For Dummies © 2024 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 All-In-One For Dummies © 2024 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.
Coverillustration: Tee11 – stock.adobe.comKorrektur: Birgit Volk
Print ISBN: 978-3-527-72189-4ePub ISBN: 978-3-527-84753-2
Allen G. Taylor: Allen ist seit 40 Jahren in der Computerbranche tätig und Autor von mehr als 40 Büchern, darunter SQL für Dummies, Crystal Reports 2008 For Dummies, Database Development For Dummies, Access 2003 Power Programming with VBA und SQL Weekend Crash Course. Er hält Vorträge auf der ganzen Welt über Datenbanken, Netzwerke, Innovation, Astronomie und Unternehmertum sowie über Gesundheit und Wellness. Außerdem leitet er Kurse zum Thema Datenbankentwicklung bei einem führenden Online-Bildungsanbieter. Die neuesten Informationen über Allens Aktivitäten finden Sie in seinem Online-Kurskatalog (https://pioneer-academy1.teachable.com) und in seinem Blog (www.allengtaylor.com). Sie können Allen unter [email protected] erreichen.
Richard Blum: Rich ist seit mehr als 35 Jahren in der IT-Branche als Netzwerk- und Systemadministrator tätig. Dabei hatte er die Gelegenheit, mit vielen verschiedenen Betriebssystemen zu arbeiten, darunter IBM-Mainframes und Windows-, Netware-, UNIX- und Linux-Server, sowie mit vielen verschiedenen Datenbanksystemen wie Oracle, Informix, Microsoft SQL, PostgreSQL und MySQL. Im Laufe der Jahre hat er auch ehrenamtlich für mehrere gemeinnützige Organisationen gearbeitet, um kleine Netzwerke zu unterstützen, die nur wenig finanziellen Spielraum haben. Rich ist Autor mehrerer Bücher mit Themen rund um Linux für absolute Linux-Freaks und leitet Online-Kurse in Programmierung. Wenn er nicht gerade damit beschäftigt ist, sich als Computerfreak auszuleben, spielt Rich gerne Orgel, Klavier und Bassgitarre und verbringt Zeit mit seiner Frau Barbara und seinen beiden Töchtern Katie Jane und Jessica.
Dieses Buch ist den vielen Lehrern, Autoren, Mitarbeitern, Freunden, Studierenden und den Autoren der Online-Beiträge gewidmet, die mir in all den Jahren geholfen haben, mein Computerwissen zu erweitern.
»The way of a fool is right in his own eyes, but a wise man listens to advice.« – Sprüche 12:15 (English Standard Version)
Richard Blum
Allen G. Taylor: Zuallererst möchte ich Jim Melton, dem Herausgeber der ISO/ANSI-Spezifikation für SQL, meine Anerkennung für seine Hilfe aussprechen. Ohne seinen unermüdlichen Einsatz wäre dieses Buch – und auch SQL selbst als internationaler Standard – von weitaus geringerem Nutzen. Ich möchte meiner Projektmanagerin Maureen Tullis, meinem Entwicklungs- und Textredakteur Scott Tullis und der leitenden Redakteurin Katie Mohr für ihre wichtigen Beiträge zur Erstellung dieses Buches danken. Dank auch an meine Agentin Carole McClendon von Waterside Productions für ihre Unterstützung meiner Karriere.
Richard Blum: Alles Lob und alle Ehre gebührt zunächst Gott, der durch seinen Sohn alles möglich macht und uns das Geschenk des ewigen Lebens macht.
Ein besonderer Dank geht an Allen für seine erstaunliche und hervorragende Arbeit an den vergangenen Ausgaben von SQL Alles-in-einem-Band für Dummies. Ich bin in der vierten Auflage in dieses Projekt eingestiegen, und es war mir eine Freude, den Text auf die neuesten SQL-Standards zu aktualisieren.
Vielen Dank an die großartigen Mitarbeiter von John Wiley & Sons für ihre Hilfe und Anleitung beim Schreiben dieses Buches. Danke an Steve Hayes, der mir die Möglichkeit bot, dieses Projekt zu übernehmen. Vielen Dank auch an Elizabeth Kuball, die mir geholfen hat, das Projekt stets auf Kurs zu halten! Ken Hess hat hervorragende Arbeit geleistet, indem er meine Fehler aufgespürt und Vorschläge gemacht hat, um dieses Buch zu verbessern – danke! Ein weiterer Dank geht an Carole Jelen von Waterside Productions, die diesen Beitrag arrangiert hat und meine Karriere als Buchautor am Laufen hält.
Schließlich möchte ich mich bei meinen Eltern, Mike und Joyce Blum, dafür bedanken, dass sie meine Ausbildung immer wieder an die vorderste Stelle gerückt haben, sowie bei meiner Frau Barbara und meinen beiden Töchtern Katie Jane und Jessica für ihre Liebe und Unterstützung, insbesondere während der Arbeit an diesem Projekt.
Cover
Titelblatt
Impressum
Die Autoren
Widmung
Danksagung der Autoren
Inhaltsverzeichnis
Einleitung
Über dieses Buch
Törichte Annahmen über die Leser
Wie dieses Buch aufgebaut ist
Symbole, die in diesem Buch verwendet werden
Wie es weitergeht
Teil I: SQL – Erste Schritte
Kapitel 1: Relationale Datenbanken
Verstehen, warum heutige Datenbanken besser sind als frühere
Welche Art von Organisation ist besser?
Datenbanken, Abfragen und Datenbankanwendungen
Konkurrierende Datenbankmodelle
Warum das relationale Modell gewonnen hat
Kapitel 2: Modellierung eines Systems
Das Datenmodell der Benutzer erfassen
Das Benutzerdatenmodell in ein formales Entity-Relationship-Modell übersetzen
Kapitel 3: SQL kennenlernen
Woher SQL kommt
Was SQL kann
Die ISO/IEC-Norm für SQL
Was SQL nicht kann
Auswahl und Verwendung einer verfügbaren DBMS-Implementierung
Kapitel 4: SQL und das relationale Modell
Mengen, Relationen, Multimengen und Tabellen
Funktionale Abhängigkeiten
Schlüssel
Ansichten
Benutzer
Zugriffsrechte
Schemas
Kataloge
Verbindungen, Sitzungen und Transaktionen
Routinen
Pfade
Kapitel 5: Die wichtigsten Komponenten von SQL
Erstellen einer Datenbank mit der Datendefinitionssprache
Daten mit der Datenmanipulationssprache (DML) bearbeiten
Mit der Datenkontrollsprache (DCL) die Sicherheit wahren
Kapitel 6: SQL – das Wesentliche
SQL-Anweisungen ausführen
Korrekte Verwendung reservierter Wörter
Die Datentypen von SQL
Zeichenfolgen (Strings)
Umgang mit Nullwerten
Beschränkungen
Teil II: Entwicklung relationaler Datenbanken
Kapitel 7: Überblick über die Systementwicklung
Die Komponenten eines Datenbanksystems
Der Lebenszyklus der Systementwicklung
Kapitel 8: Aufbau eines Datenbankmodells
Stakeholder finden und anhören
Konsensbildung
Aufbau eines relationalen Modells
Die Gefahr von Anomalien
Der Kompromiss zwischen Datenbankintegrität und Leistung
Kapitel 9: Gleichgewicht zwischen Leistung und Korrektheit
Entwurf einer Beispieldatenbank
Wahrung der Integrität
Vermeidung von Datenkorruption
Beschleunigte Datenabrufe
Arbeiten mit Indizes
SQL-Server-Ausführungspläne lesen
Kapitel 10: Eine Datenbank mit SQL erstellen
Die Planung Ihrer Datenbank
Tabellen erstellen
Beschränkungen festlegen
Schlüssel und Indizes
Datenvalidität mit Domänen sicherstellen
Beziehungen zwischen Tabellen herstellen
Die Tabellenstruktur ändern
Tabellen löschen
Teil III: SQL-Abfragen
Kapitel 11: Werte, Variablen, Funktionen und Ausdrücke
Datenwerte eingeben
Mit Funktionen arbeiten
Ausdrücke
Kapitel 12: SELECT-Anweisungen und modifizierende Klauseln
Mit der SELECT-Anweisung die Nadel im Heuhaufen finden
Modifizierende Klauseln
Abfragen tunen
Kapitel 13: Abfrage mehrerer Tabellen mit Unterabfragen
Was ist eine Unterabfrage?
Was Unterabfragen tun
Verwendung von Unterabfragen in INSERT-, DELETE- und UPDATE-Anweisungen
Tuning für Anweisungen, die verschachtelte Abfragen enthalten
Tuning von korrelierten Unterabfragen
Kapitel 14: Abfragen mehrerer Tabellen mit relationalen Operatoren
UNION
INTERSECT
EXCEPT
JOINS
ON versus WHERE
Join-Bedingungen und Clustering-Indizes
Kapitel 15: Cursor
Einen Cursor deklarieren
Einen Cursor öffnen
In einer einzigen Zeile arbeiten
Einen Cursor schließen
Teil IV: Sichern Sie Ihre Daten
Kapitel 16: Schutz vor Hardwarefehlern und externen Bedrohungen
Was kann schon schiefgehen?
Die Vorteile von RAID nutzen
Sichern Ihres Systems
Bedrohungen aus dem Internet
Installation von Schutzschichten
Kapitel 17: Schutz vor Benutzerfehlern und Konflikten
Reduzierung von Dateneingabefehlern
Umgang mit Fehlern im Datenbankentwurf
Umgang mit Programmierfehlern
Konflikte bei gleichzeitigen Operationen lösen
Den ACID-Test bestehen: Atomarität, Konsistenz, Isolierung und Dauerhaftigkeit
Mit Transaktionen arbeiten
Sperren
Sperren optimieren
Serialisierbarkeit mit Zeitstempeln erzwingen
Tuning des Wiederherstellungssystems
Kapitel 18: Rechte zuweisen
Mit der SQL Data Control Language arbeiten
Autorisierte Benutzer identifizieren
Kapitel 19: Fehlerbehandlung
Fehlerbedingungen identifizieren
SQLSTATE
Verarbeitungsbedingungen
Umgang mit Ausführungsausnahmen: Die WHENEVER-Klausel
Mehr Informationen: Der Diagnosebereich
Ein Beispiel für die Verletzung einer Beschränkung
Beschränkungen zu einer vorhandenen Tabelle hinzufügen
SQLSTATE-Informationen interpretieren
Ausnahmebehandlung
Teil V: Programmieren mit SQL
Kapitel 20: Datenbankentwicklungsumgebungen
Microsoft Access
Microsoft SQL Server
IBM DB2
Oracle 23c
SQL Anywhere
PostgreSQL
MySQL
Kapitel 21: Die Schnittstelle zwischen SQL und einer prozeduralen Sprache
Eine Anwendung mit SQL und einer prozeduralen Sprache erstellen
Access und VBA
SQL Server und die .NET-Sprachen
Kapitel 22: Verwendung von SQL in einem Anwendungsprogramm
Vergleich von SQL mit prozeduralen Sprachen
Schwierigkeiten bei der Kombination von SQL mit einer prozeduralen Sprache
SQL in eine Anwendung einbetten
Verwendung von SQL-Modulen mit einer Anwendung
Kapitel 23: Entwurf einer Beispielanwendung
Das Problem des Kunden verstehen
Annäherung an das Problem
Festlegung der zu erbringenden Leistungen
Aufbau eines Entity-Relationship-Modells
Umwandlung des Modells
Tabellen erstellen
Die Tabellenstruktur ändern
Tabellen löschen
Die Benutzeroberfläche gestalten
Kapitel 24: Eine Anwendung erstellen
Top-down-Design
Bottom-up-Coding
Testen, testen, testen
Kapitel 25: Die prozeduralen Funktionen von SQL
SQL-Anweisungen in Ihren Code einbetten
Dem Fluss der Kontrollanweisungen folgen
Gespeicherte Prozeduren verwenden
Mit Triggern arbeiten
Gespeicherte Funktionen verwenden
Rechte gewähren
Gespeicherte Module verwenden
Kapitel 26: Verbindung von SQL mit einer entfernten Datenbank
Native Treiber
ODBC und seine wichtigsten Komponenten
Was geschieht, wenn die Anwendung eine Abfrage stellt?
Teil VI: Erweiterte Datentypen in SQL: XML, JSON und PGQ
Kapitel 27: Verwendung von XML mit SQL
Einführung in XML
Die Teile eines XML-Dokuments
XML-Schema
Verknüpfung von SQL und XML
Verwendung des XML-Datentyps
SQL auf XML abbilden
XML-Daten mit SQL-Funktionen bearbeiten
XML-Prädikate
Kapitel 28: XML-Daten in SQL-Tabellen speichern
XML-Daten in eine SQL-Pseudotabelle einfügen
Eine Tabelle zur Aufnahme von XML-Daten erstellen
XML-Dokumente aktualisieren
Oracle-Tools zum Aktualisieren von XML-Daten in einer Tabelle
Microsoft-Tools zum Aktualisieren von XML-Daten in einer Tabelle
Kapitel 29: Daten aus XML-Dokumenten abrufen
XQuery
FLWOR-Ausdrücke
XQuery versus SQL
Kapitel 30: Verwendung von JSON mit SQL
Verwendung von JSON mit SQL
Das SQL/JSON-Datenmodell
SQL/JSON-Funktionen
SQL/JSON-Pfadsprache
SQL:2023 JSON-Verbesserungen
Kapitel 31: Eigenschaftsgraphen-Abfragen
Was sind Eigenschaftsgraphen-Abfragen?
SQL/PGQ
Mit SQL/PGQ arbeiten
Teil VII: Datenbanken optimieren
Kapitel 32: Datenbank-Tuning
Die Arbeitslast analysieren
Berücksichtigung des physischen Designs
Die Auswahl der richtigen Indizes
Indizes tunen
Abfragen tunen
Transaktionen tunen
Benutzerinteraktionen und Transaktionen trennen
Den Datenverkehr zwischen Anwendung und Server möglichst gering halten
Vorkompilierung häufig verwendeter Abfragen
Kapitel 33: Tuning der Umgebung
Ausfälle überleben – mit minimalem Datenverlust
Tuning des Wiederherstellungssystems
Das Betriebssystem tunen
Vorhandene Hardware optimal nutzen
Hardware hinzufügen
Multiprozessor-Umgebungen
Kapitel 34: Leistungsengpässe auffinden und beseitigen
Lokalisierung des Problems
Mögliche Ursachen von Störungen ermitteln
Umsetzung der allgemeinen Grundsätze: Ein erster Schritt zur Leistungsverbesserung
Engpässe aufspüren
Analyse der Abfrageeffizienz
Ressourcen klug verwalten
Anhang
SQL:2023 – reservierte Wörter
Glossar
Abbildungsverzeichnis
Stichwortverzeichnis
End User License Agreement
Kapitel 4
Tabelle 4.1: Relation
PROJEKT
Tabelle 4.2: Tabelle
PROJEKT
Kapitel 5
Tabelle 5.1: Tabelle
PRODUKT
Tabelle 5.2: Tabelle
PRODUKT
Tabelle 5.3: Tabelle
PRODUKT
Tabelle 5.4: Tabelle
PRODUKT
Tabelle 5.5: Tabelle
PRODUKT
Kapitel 6
Tabelle 6.1: Datentypen
Kapitel 8
Tabelle 8.1: Beschreibung der Elemente einer Datenbank
Kapitel 9
Tabelle 9.1: Primärschlüssel für Beispielrelationen
Kapitel 10
Tabelle 10.1: Tabellen für Joes Autoklinik
Kapitel 11
Tabelle 11.1: Beispiel-Literale für verschiedene Datentypen
Tabelle 11.2: Preisliste für Fotopapiere pro 20 Blatt
Tabelle 11.3: Beispiele für die Verwendung der
POSITION
-Anweisung
Tabelle 11.4: Beispiele für Zeichenfolgen-Wertausdrücke
Kapitel 12
Tabelle 12.1: Vergleichsprädikate in SQL
Tabelle 12.2: Das
LIKE
-Prädikat von SQL
Kapitel 13
Tabelle 13.1: Ford Small-Block V-8s, 1960–1980
Tabelle 13.2: Chevy Small-Block V-8s, 1960-1980
Kapitel 14
Tabelle 14.1: STANDORT
Tabelle 14.2: ABTEILUNG
Tabelle 14.3: MITARBEITER
Kapitel 16
Tabelle 16.1: Vergleich von RAID-Leveln
Kapitel 17
Tabelle 17.1: Isolationsniveaus und gelöste Probleme
Kapitel 19
Tabelle 19.1: Klassenwerte von
SQLSTATE
Tabelle 19.2: Bedingungen, die in einem Bedingungs-Handler spezifiziert werden k...
Tabelle 19.3: Diagnose-Kopfbereich
Tabelle 19.4: Diagnose-Detailbereich
Kapitel 29
Tabelle 29.1: USERS
Tabelle 29.2: ITEMS
Tabelle 29.3: BIDS
Tabelle 29.4: XQuery-1.0-Datentypen und entsprechende SQL-Datentypen
Kapitel 30
Tabelle 30.1: Neue JSON-Funktionen
Kapitel 1
Abbildung 1.1: Ein hierarchisches Modell der Mondrakete Saturn V.
Abbildung 1.2: Ein hierarchisches Modell einer Verkaufsdatenbank für ein Einzelh...
Abbildung 1.3: Ein Netzwerkmodell für Transaktionen in einem Online-Geschäft.
Abbildung 1.4: Ein relationales Modell von Transaktionen in einem Online-Geschäf...
Kapitel 2
Abbildung 2.1:
MITARBEITER
, ein Beispiel für eine Entitätsklasse.
Abbildung 2.2: Duke Kahanamoku, ein Beispiel für eine Instanz der Entitätsklasse...
Abbildung 2.3: Die Beziehung
MITARBEITER:TRANSAKTION
.
Abbildung 2.4: Eine Eins-zu-eins-Beziehung zwischen
PERSON
und
FÜHRERSCHEIN
Abbildung 2.5: Eine Eins-zu-viele-Beziehung zwischen
PERSON
und
STRAFZETTEL
.
Abbildung 2.6: Eine Viele-zu-Viele-Beziehung zwischen
STUDENT
und
VORLESUNG
.
Abbildung 2.7: Die Beziehung
KOMPONIST:LIED:TEXTER
.
Abbildung 2.8: ER-Diagramm mit Anzeige der minimalen Kardinalität, bei der eine ...
Abbildung 2.9: ER-Diagramm mit minimaler Kardinalität, bei der ein Führerschein ...
Abbildung 2.10: Das ER-Modell für eine Einzelhandelstransaktionsdatenbank.
Abbildung 2.11: Eine
PERSON:FÜHRERSCHEIN
-Beziehung, die
FÜHRERSCHEIN
a...
Abbildung 2.12: Der
SITZPLATZ
ist über die Beziehung
FLUG:SITZPLATZ
von
FLUG-ID
-...
Abbildung 2.13: Die Supertyp-Entität
GEMEINSCHAFT
mit den Subtyp-Entitäten
STUDE
...
Abbildung 2.14: Ein ER-Diagramm eines kleinen webbasierten Einzelhandelsunterneh...
Abbildung 2.15: Das ER-Diagramm der Clear Creek Medical Clinic.
Kapitel 3
Abbildung 3.1: Ein Microsoft-Access-365-Datenbankfenster, in dem die Northwind-T...
Abbildung 3.2: Ergebnisse der Abfrage für Artikelbestellungen.
Abbildung 3.3: Die Entwurfsansicht der Abfrage für die Artikelbestellungen.
Abbildung 3.4: Die SQL-Ansicht der Abfrage für die Artikelbestellungen.
Abbildung 3.5: Änderung des SQL für die Abfrage zu den Artikelbestellungen, um a...
Abbildung 3.6: Die Ergebnisse der Abfrage zur Anzeige aller Daten in der Tabelle...
Kapitel 5
Abbildung 5.1: Die Hierarchie der umschließenden relationalen Datenbank.
Abbildung 5.2: Das ER-Diagramm der Datenbank für ein Auftragserfassungssystem.
Abbildung 5.3: Erstellen einer Multi-Tabellenansicht mit Hilfe von Joins.
Kapitel 6
Abbildung 6.1: Definition von Sub- und Supertypen von Büchern.
Abbildung 6.2: Ein Beispiel für Fremdschlüssel-Beschränkungen in Tabellen.
Kapitel 7
Abbildung 7.1: Informationsfluss in einem Datenbanksystem.
Kapitel 9
Abbildung 9.1: Das ER-Modell für Joes Autoklinik.
Abbildung 9.2: Die Entität
KUNDE
und die Relation
KUNDE
.
Abbildung 9.3: Das ER-Modell der Beziehung
TEIL:RECHNUNGSZEILE
.
Abbildung 9.4: Ein relationales Modell zur Darstellung der Eins-zu-eins-Beziehun...
Abbildung 9.5: Ein ER-Diagramm einer Eins-zu-viele-Beziehung.
Abbildung 9.6: Eine Darstellung eines relationalen Modells der Eins-zu-viele-Bez...
Abbildung 9.7: Das ER-Diagramm einer Viele-zu-viele-Beziehung.
Abbildung 9.8: Die Darstellung des relationalen Modells der Zerlegung der Viele-...
Abbildung 9.9: Das ER-Diagramm für Joes Autoklinik.
Abbildung 9.10: Die Darstellung des relationalen Modells für das Modell von Joes...
Abbildung 9.11: Überarbeitetes ER-Modell für Joes Autoklinik.
Abbildung 9.12: Tabellen und Beziehungen in der AdventureWorks2022-Datenbank.
Abbildung 9.13: SQL Server 2022 Management Studio bei der Ausführung einer SQL-A...
Abbildung 9.14: Der Ausführungsplan für die Abfrage der Lieferzeiten.
Kapitel 12
Abbildung 12.1: Die Ergebnismenge für den Abruf der Verkäufe für Juli 2011.
Abbildung 12.2: Durchschnittlicher Umsatz für jeden Verkäufer.
Abbildung 12.3: Gesamtumsatz für jeden Verkäufer.
Abbildung 12.4: Gesamtumsatz für alle Verkäufer außer Saraiva.
Abbildung 12.5: Kunden, die mindestens eine Bestellung aufgegeben haben.
Abbildung 12.6: Der
SELECT DISTINCT
-Abfrageausführungsplan.
Abbildung 12.7: Client-Statistik zur
SELECT DISTINCT
-Abfrage.
Abbildung 12.8: Abrufen aller Mitarbeiterinnen namens Janice aus der Tabelle Per...
Abbildung 12.9:
SELECT
-Abfrageausführungsplan unter Verwendung einer temporären ...
Abbildung 12.10: Client-Statistiken zur
SELECT
-Abfrageausführung unter Verwendun...
Abbildung 12.11:
SELECT
-Abfrageergebnis mit einer zusammengesetzten Bedingung.
Abbildung 12.12:
SELECT
-Abfrageausführungsplan mit einer zusammengesetzten Bedin...
Abbildung 12.13:
SELECT
-Abfrage-Client-Statistiken mit einer zusammengesetzten B...
Abbildung 12.14: Ausführungsplan, Minimierung des Auftretens von
ORDER BY
-Klause...
Abbildung 12.15: Client-Statistiken, Minimierung des Auftretens von
ORDER BY
-Kla...
Abbildung 12.16: Ausführungsplan, Abfragen mit separaten
ORDER BY
-Klauseln.
Abbildung 12.17: Client-Statistiken, Abfragen mit separaten
ORDER BY
-Klauseln.
Abbildung 12.18: Abfrage mit einer
HAVING
-Klausel.
Abbildung 12.19: Abfrage mit einem
HAVING
-Klausel – Ausführungsplan.
Abbildung 12.20: Abfrage mit einer
HAVING
-Klausel – Client-Statistik.
Abbildung 12.21: Abfrage ohne
HAVING
-Klausel.
Abbildung 12.22: Abfrage ohne
HAVING
-Klausel – Ausführungsplan.
Abbildung 12.23: Abfrage ohne
HAVING
-Klausel – Client-Statistiken.
Abbildung 12.24: Abfrage mit einer logischen
OR
-Verknüpfung.
Kapitel 13
Abbildung 13.1: Chevy-Muscle-Cars mit einem höheren PS-Hubraum-Verhältnis als di...
Abbildung 13.2: Bestellungen, die nicht vorrätige Produkte enthalten.
Abbildung 13.3: Ein Ausführungsplan für eine Abfrage, die Bestellungen für nicht...
Abbildung 13.4: Client-Statistiken für eine Abfrage mit Bestellungen für nicht v...
Abbildung 13.5: Eine verschachtelte Abfrage, die Bestellungen anzeigt, die Produ...
Abbildung 13.6: Ein Ausführungsplan für eine geschachtelte Abfrage, die Bestellu...
Abbildung 13.7: Client-Statistiken für eine verschachtelte Abfrage, die Bestellu...
Abbildung 13.8: Eine relationale Abfrage zeigt Bestellungen, die Produkte mit ge...
Abbildung 13.9: Der Ausführungsplan für eine relationale Abfrage, die Bestellung...
Abbildung 13.10: Client-Statistiken für eine relationale Abfrage, die Bestellung...
Abbildung 13.11: Eine korrelierte Unterabfrage, die Bestellungen anzeigt, die Pr...
Abbildung 13.12: Ein Ausführungsplan für eine korrelierte Unterabfrage, die Auft...
Abbildung 13.13: Client-Statistiken für eine korrelierte Unterabfrage mit Bestel...
Abbildung 13.14: Relationale Abfrage mit Aufträgen, die Produkte enthalten, die ...
Abbildung 13.15: Ein Ausführungsplan für eine relationale Abfrage, die Bestellun...
Abbildung 13.16: Client-Statistiken für eine relationale Abfrage, die Bestellung...
Kapitel 16
Abbildung 16.1: RAID-Striping.
Abbildung 16.2: Scanergebnis von HP WebInspect.
Abbildung 16.3: Scanergebnis von IBM Security AppScan.
Kapitel 21
Abbildung 21.1: Im Dialogfeld
VERWEISE
von Visual Basic for Applications können ...
Kapitel 23
Abbildung 23.1: Ein ER-Diagramm der OLS-Forschungseinrichtung.
Abbildung 23.2: Eine Darstellung des ER-Modells für das OLS-Syst...
Abbildung 23.3: Die Entität
MITGLIEDER
(oben) und die Relation
M
...
Kapitel 24
Abbildung 24.1: Der Hauptbildschirm der OLS-Anwendung mit Befehlsschaltflächen.
Abbildung 24.2: Die Menühierarchie der OLS-Anwendung.
Abbildung 24.3: Das Menü »OLS-Formulare«.
Abbildung 24.4: Das Formular »OLS-Mitglieder«.
Kapitel 26
Abbildung 26.1: Ein Datenbanksystem, das einen nativen Oracle 23c-Treiber verwen...
Abbildung 26.2: Ein Datenbanksystem mit ODBC-API.
Abbildung 26.3: Die Architektur eines zweistufigen Treibersystems.
Abbildung 26.4: Handles stellen die Verbindung zwischen einer Anwendung und eine...
Kapitel 31
Abbildung 31.1: Ein Beispiel für eine Eigenschaftsgraphen-Datenbank.
Abbildung 31.2: Erstellen der Knotentabelle
Employee
.
Abbildung 31.3: Die Tabellen der Knoten
"City"
und
"Company"
für die Stadt und d...
Abbildung 31.4: Anzeigen der Datenfelder der Kantentabelle
worksat
(ArbeitetBei)...
Abbildung 31.5: Das Ergebnis der
worksat
-Abfrage.
Abbildung 31.6: Das Ergebnis der
bossof
-Abfrage.
Abbildung 31.7: Die Ergebnisse der Suche nach Mitarbeitern, die in derselben Sta...
Kapitel 32
Abbildung 32.1: Die Kosten für Abfragen mit und ohne Index.
Kapitel 34
Abbildung 34.1: Microsoft SQL Server 2022 Management Studio.
Abbildung 34.2: Das SQL-Editor-Fenster von Microsoft SQL Server Management Studi...
Abbildung 34.3: Eine Beispielabfrage.
Abbildung 34.4: Das Abfrageergebnis.
Abbildung 34.5: Das Fenster
DATABASE ENGINE TUNING ADVISOR
.
Abbildung 34.6: Das Dialogfeld
TRACE PROPERTIES
(Trace-Eigenschaften).
Abbildung 34.7: Die Registerkarte
EVENTS SELECTION
(Ereignisauswahl) des Dialogf...
Abbildung 34.8: Trace für eine einfache Abfrage.
Abbildung 34.9: Anzeige von
LAUFWERKE DEFRAGMENTIEREN UND OPTIMIEREN
für die Lau...
Cover
Titelblatt
Impressum
Die Autoren
Inhaltsverzeichnis
Einleitung
Fangen Sie an zu lesen
Glossar
Abbildungsverzeichnis
Stichwortverzeichnis
End User License Agreement
1
2
3
4
5
6
9
10
11
12
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
91
92
93
94
95
96
97
98
99
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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
189
190
191
192
193
194
195
196
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
224
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
316
317
318
319
320
321
322
323
324
325
326
327
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
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
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
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
689
690
691
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
SQL ist die international anerkannte Standardsprache für den Umgang mit Daten in relationalen Datenbanken. SQL wurde von IBM entwickelt und 1986 zu einem international anerkannten Standard. Dieser Standard wurde in den Jahren 1989, 1992, 1999, 2003, 2008, 2011, 2016 und 2023 aktualisiert. Er wird stetig weiterentwickelt und erweitert. Die Anbieter von Datenbanken aktualisieren ihre Produkte häufig, um die neuen Funktionen der ISO/IEC-Norm zu integrieren. (Für die Neugierigen unter Ihnen: ISO ist die Internationale Organisation für Normung und IEC die Internationale Elektrotechnische Kommission.)
SQL ist keine Allzwecksprache, wie zum Beispiel C++ oder Java. Stattdessen ist sie ausschließlich für den Umgang mit Daten in relationalen Datenbanken konzipiert. Mit SQL können Sie alle folgenden Aufgaben ausführen:
Eine Datenbank erstellen, einschließlich aller Tabellen und Beziehungen.
Daten in Datenbanktabellen eingeben.
Daten in Datenbanktabellen ändern.
Daten aus Datenbanktabellen löschen.
Spezifische Informationen aus Datenbanktabellen abrufen.
Zugriff auf Datenbanktabellen gewähren und entziehen.
Datenbanktabellen vor Beschädigung durch Zugriffskonflikte oder Benutzerfehler schützen.
In diesem Buch geht es nicht nur um SQL, sondern auch darum, wie sich SQL in den Prozess der Erstellung und Pflege von Datenbanken und Datenbankanwendungen einfügt. Es geht darum, wie sich SQL in die größere Welt der Anwendungsentwicklung integriert und wie es mit Daten umgeht, die von anderen Computern kommen, die sich auf der anderen Seite der Welt oder sogar im interplanetaren Raum befinden können.
Hier einige der Dinge, bei denen Ihnen dieses Buch helfen kann:
Ein Modell eines geplanten Systems erstellen, das anschließend in eine Datenbank übersetzt werden kann.
Informationen über die Möglichkeiten und Grenzen von SQL erhalten.
Entdecken, wie zuverlässige und wartbare Datenbanksysteme entwickelt werden.
Datenbanken erstellen.
Datenbankabfragen beschleunigen.
Datenbanken vor Hardwarefehlern, Softwarefehlern und Internetangriffen schützen.
Den Zugang zu sensiblen Informationen kontrollieren.
Effektive Datenbankanwendungen schreiben.
Daten aus einer Vielzahl von nicht herkömmlichen Datenquellen unter Verwendung von XML verarbeiten.
Dieses Buch ist modular aufgebaut, damit Sie nicht alles lesen müssen, was nicht zu Ihrer aktuellen Aufgabe gehört. Das heißt, es ist so konzipiert, dass Sie immer genau die Informationen finden können, die Sie brauchen. An einigen Stellen im Buch gibt es Einschübe mit interessanten Informationen, die nicht unbedingt zum eigentlichen Thema gehören. Sie können diese gerne überspringen. Sie müssen auch nicht den Text lesen, der mit den Symbolen für technische Informationen gekennzeichnet ist und der interessante, aber eher komplizierte Sachverhalte beschreibt (die Ihnen vielleicht gefallen oder auch nicht).
Beim Lesen werden Sie feststellen, dass einige Webadressen über zwei Textzeilen hinweg umbrochen sind. Wenn Sie dieses Buch in gedruckter Form lesen und eine dieser Webseiten besuchen möchten, geben Sie die Webadresse einfach genau so ein, wie sie im Text angegeben ist, und tun Sie so, als ob der Zeilenumbruch nicht vorhanden wäre. Wenn Sie dieses Buch als E-Book lesen, haben Sie es leicht: Klicken Sie einfach auf die Webadresse, um direkt zur Webseite zu gelangen.
Ich weiß, dass dies ein Buch für Dummies ist, aber ich erwarte nicht, dass Sie ein Dummie sind. Ich gehe sogar davon aus, dass Sie ein sehr intelligenter Mensch sind. Schließlich haben Sie sich entschlossen, dieses Buch zu lesen, was in der Tat ein Zeichen von hoher Intelligenz ist. Daher nehme ich an, dass Sie einige Dinge tun wollen, wie zum Beispiel einige der Beispiele im Buch nachvollziehen. Vielleicht möchten Sie sogar SQL-Code eingeben und ausführen. Dazu benötigen Sie zumindest einen SQL-Editor und wahrscheinlich auch eine Art von Datenbankmanagementsystem (DBMS). Es gibt viele Möglichkeiten, sowohl proprietäre als auch quelloffene. Ich erwähne mehrere dieser Produkte an verschiedenen Stellen des Buches, empfehle aber kein bestimmtes. Jedes Produkt, das der internationalen ISO/IEC-Norm für SQL entspricht, sollte geeignet sein.
Die Behauptung der ISO/IEC-Konformität ist jedoch mit Vorsicht zu genießen. Kein heute verfügbares DBMS ist zu 100 Prozent konform mit der ISO/IEC-Norm für SQL. Aus diesem Grund funktionieren einige der im Buch gezeigten Codebeispiele möglicherweise nicht in der speziellen SQL-Implementierung, die Sie verwenden. Die Codebeispiele in diesem Buch entsprechen dem internationalen Standard und nicht der Syntax einer bestimmten Implementierung, es sei denn, ich gebe ausdrücklich an, dass der Code für eine bestimmte Implementierung vorgesehen ist.
Dieser Teil ist die richtige Lektüre, wenn Sie gerade erst anfangen, sich mit Datenbanken zu beschäftigen. Er erklärt, warum Datenbanken nützlich sind, und beschreibt die verschiedenen Typen. Er konzentriert sich auf das relationale Modell und beschreibt die Struktur und die Funktionen von SQL.
Teil II geht im Detail darauf ein, wie man eine Datenbank erstellt, die sowohl zuverlässig als auch reaktionsschnell ist. Unzuverlässige Datenbanken sind viel zu leicht zu erstellen. Hier erfahren Sie, wie Sie Fallstricke vermeiden können, die lauern, wenn man nicht aufpasst.
Gehen Sie direkt zu Teil III über, wenn Ihre Datenbank bereits existiert und Sie nur wissen wollen, wie Sie SQL verwenden, um die gewünschten Informationen daraus abzurufen.
Teil IV richtet sich in erster Linie an den Datenbankadministrator (DBA) und weniger an den Entwickler oder Benutzer von Datenbankanwendungen. Es wird erörtert, wie ein robustes Datenbanksystem aufbaut wird, das gegen Datenbeschädigung und Datenverlust möglichst resistent ist.
Dieser Teil richtet sich an den Anwendungsentwickler. Neben der Erläuterung, wie eine Datenbankanwendung geschrieben wird, wird anhand eines Beispiels Schritt für Schritt erklärt, wie eine zuverlässige Anwendung erstellt wird.
Wenn Sie bereits ein alter Hase in Sachen SQL sind und einfach nur wissen wollen, wie Sie Daten im XML- oder JSON-Format in Ihrer SQL-Datenbank verarbeiten können, oder wenn Sie in die Welt der Property-Graph-Datenbanken eintauchen möchten, ist Teil VI genau das Richtige für Sie.
Hier finden Sie eine Vielzahl von Techniken zur Verbesserung der Leistung Ihrer Datenbank. Dieser Teil ist die richtige Anlaufstelle, wenn Ihre Datenbank zwar funktioniert, aber nicht so gut, wie Sie es sich wünschen. Die meisten dieser Techniken beschreiben Maßnahmen, die der DBA ergreifen kann, aber nicht der Anwendungsentwickler oder der Datenbankbenutzer. Wenn Ihre Datenbank nicht so funktioniert, wie Sie es erwarten, wenden Sie sich an Ihren Datenbankadministrator. Er kann ein paar Dinge unternehmen, die sehr hilfreich sein können.
… für-Dummies-Bücher sind bekannt für ihre hilfreichen Symbole, die Sie zu den wirklich wichtigen Informationen führen. In diesem Abschnitt werden die in diesem Buch verwendeten Symbole kurz beschrieben.
Das Tipp-Symbol weist auf hilfreiche Informationen hin, die Ihnen die Arbeit erleichtern können.
Dieses Symbol kennzeichnet eine allgemein interessante und nützliche Tatsache – etwas, das Sie sich vielleicht für später merken möchten.
Das Warnsymbol weist auf eine lauernde Gefahr hin. Wenn Sie dieses Symbol sehen, sollten Sie aufmerksam sein und mit Vorsicht vorgehen.
Dieses Symbol kennzeichnet sehr technische Informationen. Wenn Sie nicht besonders technikbegeistert sind, können Sie sie überspringen.
Sie können dieses Buch von vorne nach hinten durchlesen, um garantiert jedes Detail über Datenbanken mitzunehmen. So werden Sie zum absoluten Datenbank-Profi. Ihre Kollegen kommen dann vielleicht zu Ihnen, wenn Sie Informationen benötigen, Vorgesetzte werden möglicherweise Rat bei Ihnen suchen, aber vor allem werden Sie verstehen, wie Ihr Unternehmen wirklich funktioniert.
Natürlich können Sie auch einfach das Kapitel oder den Teil aufschlagen, das oder der Sie gerade brennend interessiert. Vielleicht haben Sie auch schon ein, zwei Fragestellungen im Hinterkopf, die Sie angehen möchten. Nur zu! Auch der Anhang ist ein praktisches Nachschlagewerk, das Ihnen hilft, schnell die Bedeutung eines Wortes zu finden, auf das Sie gestoßen sind, oder herauszufinden, warum eine von Ihnen eingegebene SQL-Anweisung nicht wie erwartet funktioniert hat. (Vielleicht haben Sie ein reserviertes Wort verwendet, ohne es zu merken.)
Teil I
IN DIESEM TEIL …
Vorteile von DatenbankenModellierung von DatenbankmodellenWas bedeutet SQL und was hat es mit relationalen Datenbanken zu tun?Die wichtigsten Komponenten von SQL kennenlernenKapitel 1
IN DIESEM KAPITEL
Mit Dateien und Datenbanken arbeitenErkennen, wie Datenbanken, Abfragen und Datenbankanwendungen zusammenhängenVerschiedene Datenbankmodelle kennenlernenEinen Überblick über die Entwicklung der relationalen Datenbanken erhaltenSQL (ausgesprochen ess kiu ell, manchmal auch se quel) ist die internationale Standardsprache in Verbindung mit relationalen Datenbanken. Relationale Datenbanken sind die auf der ganzen Welt vorherrschende Form der Datenspeicherung. Um zu verstehen, warum relationale Datenbanken die wichtigsten Datenspeicher für kleine und große Unternehmen sind, müssen Sie zunächst die verschiedenen Arten der Speicherung von Computerdaten verstehen und wie diese Speichermethoden mit dem relationalen Datenbankmodell zusammenhängen. Um Ihnen dabei zu helfen, verbringe ich einen großen Teil dieses Kapitels damit, bis in die frühesten Tage der Computer zurückzublicken und die Geschichte der Datenspeicherung zu rekapitulieren.
Mir ist klar, dass große historische Übersichten nicht jedermanns Sache sind. Dennoch möchte ich aufzeigen, dass die verschiedenen Datenspeicherstrategien, die im Laufe der Jahre verwendet wurden, jeweils ihre eigenen Stärken und Schwächen haben. Letztlich überwogen die Stärken des relationalen Modells seine Schwächen, und es wurde zu der am häufigsten verwendeten Methode der Datenspeicherung. Kurz darauf wurde SQL die am häufigsten verwendete Methode für den Umgang mit Daten, die in einer relationalen Datenbank gespeichert sind.
In den Anfängen des Computings war das Konzept der Datenbank eher theoretisch als praktisch. Vannevar Bush, der Visionär des 20. Jahrhunderts, hatte die Idee einer Datenbank bereits 1945, noch bevor der erste Computer gebaut worden war. Praktische Implementierungen von Datenbanken kamen jedoch erst einige Jahre später auf, wie beispielsweise das IMS (Information Management System) von IBM, in dem alle Komponenten der Apollo-Mondmission und ihrer kommerziellen Nachfolger erfasst wurden. Viel zu lange wurden Computerdaten in Dateien gespeichert, statt sie in Datenbanken zu überführen.
Jedes Softwaresystem, das eine nützliche Funktion ausführt, ist komplex. Je umfangreicher die Funktion ist, desto komplexer ist ihre Implementierung. Unabhängig davon, wie die Daten gespeichert werden, bleibt die Komplexität bestehen. Die einzige Frage ist, wo sich diese Komplexität befindet.
Jede nicht triviale Computeranwendung besteht aus zwei Hauptkomponenten: dem Programm und den Daten. Obwohl der Grad der Komplexität einer Anwendung von der auszuführenden Aufgabe abhängt, haben die Entwickler eine gewisse Kontrolle über den Ort dieser Komplexität. Die Komplexität kann hauptsächlich im Programmteil des Gesamtsystems oder auch im Datenteil angesiedelt sein. In den folgenden Abschnitten erläutere ich, wie sich der Ort der Komplexität in Datenbanken im Laufe der Jahre verschoben hat, als technologische Verbesserungen dies möglich machten.
Bei den frühesten Anwendungen von Computern zur Lösung von Problemen lag die gesamte Komplexität im Programm selbst. Die Daten bestanden aus Datensätzen fester Länge, die sequenziell in einer »flachen« Datei gespeichert wurden. Dies wird als Flat-File-Datenstruktur bezeichnet. Die Datendatei enthält nichts anderes als Daten. Die Programmdatei muss Informationen darüber enthalten, wo sich bestimmte Datensätze innerhalb der Datendatei befinden (eine Form von Metadaten, deren einziger Zweck es ist, die Primärdaten zu organisieren, die Sie wirklich interessieren). Bei dieser Art der Organisation liegt die Komplexität der Datenverwaltung also vollständig im Programm.
Hier ein Beispiel für Daten, die in einer flachen Dateistruktur organisiert sind:
Thomas Meier Siebenbürgerstr. 8 Neustadt BY 92683Anne Schulz Küstenweg 373 Ehlingen BW 72705Adrian Berger Bergstraße 37 Aberberg BW 92640Arthur Maus Geheimrat-Ecker-Str. 2 Gartenstadt BW 72643Johannes Sieber Fichtenweg 1 Berg BW 72715Leonie Zuckerguss Hauptstraße 1243 Stanton BW 72610Sebastian Gsangl Weidenstraße 44 Schafberg BW 72635Matthias Holzer Kurze Lohe 292 Anaheim BW 72640Felix Flatter Auenstraße 342 Burgstadt BW 72610Juliane Jung Sonnenstraße 1257 Bad Bergen BW 72705
Dieses Beispiel enthält Felder für Name, Adresse, Stadt, Bundesland und Postleitzahl. Jedes Feld hat eine bestimmte Länge, und die Dateneinträge müssen so gekürzt werden, dass sie in diese Länge passen. Wenn die Einträge nicht den gesamten ihnen zugewiesenen Platz ausnutzen, wird Speicherplatz verschwendet.
Die Flat-File-Methode der Datenspeicherung hat mehrere Konsequenzen, einige davon vorteilhaft, andere nicht. Zunächst zu den positiven Merkmalen:
Der Speicherbedarf
ist minimal.
Da die Datendateien nur Daten enthalten, benötigen sie nur ein Minimum an Platz auf Festplatten oder anderen Speichermedien. Der Code, der zu einem Programm hinzugefügt werden muss, das die Metadaten enthält, ist minimal im Vergleich zu dem Aufwand, der mit dem Hinzufügen eines Datenbankmanagementsystems (DBMS) auf der Datenseite des Systems verbunden ist. (Ein
Datenbankmanagementsystem
ist das Programm, das den Zugriff auf eine Datenbank – und die Operationen für diese – steuert.)
Operationen mit den Daten können schnell sein.
Da das Programm direkt mit den Daten interagiert, ohne dass ein DBMS dazwischengeschaltet ist, können gut konzipierte Anwendungen so schnell laufen, wie die Hardware es erlaubt.
Wow! Was könnte besser sein? Eine Datenorganisation, die den Speicherbedarf minimiert und gleichzeitig die Arbeitsgeschwindigkeit maximiert, scheint das Beste aus allen möglichen Welten zu sein. Aber Moment …
Flache Dateisysteme kamen in den 1940er-Jahren zum Einsatz. Wir kennen sie schon seit Langem, und dennoch werden sie heute fast vollständig durch Datenbanksysteme ersetzt. Woran liegt das? Vielleicht sind es die nicht ganz so vorteilhaften Merkmale:
Die Aktualisierung
der Datenstruktur kann eine enorme Aufgabe sein.
Es ist üblich, dass die Daten eines Unternehmens von mehreren Anwendungsprogrammen mit unterschiedlichen Zwecken verarbeitet werden. Wenn sich die Metadaten über die Struktur der Daten im Programm befinden und nicht an die Daten selbst angehängt sind, müssen
alle
Programme, die auf diese Daten zugreifen, bei jeder Änderung der Datenstruktur angepasst werden. Dies verursacht nicht nur eine Menge redundanter Arbeit (weil in allen Programmen dieselben Änderungen vorgenommen werden müssen), sondern ist auch häufige Ursache von Problemen. Alle Programme müssen auf genau die gleiche Weise geändert werden. Wenn ein Programm versehentlich vergessen wird, wird es beim nächsten Start nicht mehr funktionieren. Selbst wenn alle Programme geändert werden, werden alle, die nicht genau so geändert wurden, wie es sein sollte, fehlschlagen oder, noch schlimmer, die Daten beschädigen, ohne dass es einen Hinweis darauf gibt, dass etwas nicht stimmt.
Flache Dateisysteme bieten keinen Schutz für einzelne Datenelemente.
Bei flachen Dateien haben Sie entweder Lese-/Schreibzugriff auf die gesamte Datei oder auf keinen Teil der Datei. Ein Flat-File-System verfügt nicht über ein Datenbankmanagementsystem, mit dem Sie den Zugriff auf die Daten auf autorisierte Benutzer beschränken können.
Die Geschwindigkeit kann beeinträchtigt werden.
Der Zugriff auf Datensätze in einer sehr großen flachen Datei kann tatsächlich viel langsamer sein als ein ähnlicher Zugriff in einer Datenbank, da flache Dateisysteme keine Indizierung unterstützen. Die Indizierung ist ein wichtiges Thema, das ich in
Kapitel 9
behandle.
Die Portabilität
wird zum Problem.
Wenn in jedem Programm fest kodiert ist, wie ein bestimmter Abschnitt der Daten von einem bestimmten Laufwerk abgerufen wird, was passiert dann, wenn Ihre Hardware veraltet ist und Sie auf ein neues System umsteigen müssen? Alle Ihre Anwendungen müssen geändert werden, um die neue Art des Datenzugriffs zu berücksichtigen. Diese Aufgabe ist so mühsam, dass sich viele Unternehmen dazu entschlossen haben, mit alten, schlecht funktionierenden Systemen weiterzuarbeiten, anstatt den Aufwand einer Umstellung auf ein System auf sich zu nehmen, das ihre Anforderungen viel effektiver erfüllen würde. Unternehmen mit Altsystemen, die aus Millionen von Codezeilen bestehen, sitzen sozusagen in der Falle.
In den Anfängen der elektronischen Datenverarbeitung war Speicherplatz relativ teuer, sodass die Systementwickler hoch motiviert waren, ihre Aufgaben mit so wenig Speicherplatz wie möglich zu bewältigen. Außerdem waren die Computer damals viel langsamer als heute, sodass die schnellstmögliche Erledigung von Aufgaben ebenfalls hohe Priorität hatte. Diese beiden Überlegungen machten flache Dateisysteme zur Architektur der Wahl, trotz der Probleme, die mit der Aktualisierung der Datenstruktur eines Systems verbunden sind.
Heute ist die Situation eine völlig andere. Die Kosten für die Datenspeicherung sind drastisch gesunken und sinken weiterhin exponentiell. Die Geschwindigkeit, mit der Berechnungen durchgeführt werden, hat exponentiell zugenommen. Infolgedessen sind die Minimierung des Speicherbedarfs und die Maximierung der Geschwindigkeit, mit der ein Vorgang ausgeführt werden kann, nicht mehr die primären Triebkräfte, die sie einst waren. Da die Systeme immer größer und komplexer geworden sind, hat sich auch das Problem ihrer Wartung vergrößert. Aus all diesen Gründen haben flache Dateisysteme an Attraktivität verloren, und Datenbanken haben sie in praktisch allen Anwendungsbereichen ersetzt.
Der Hauptvorteil von Datenbanksystemen besteht darin, dass die Metadaten auf der Datenseite des Systems und nicht im Programm gespeichert werden. Das Programm muss nichts über die Details wissen, wie die Daten gespeichert sind. Das Programm stellt logische Abfragen, um Dateien zu erhalten, und das DBMS übersetzt diese logischen Abfragen in Befehle, die an die physische Speicherhardware weitergeleitet werden, um die angeforderte Operation durchzuführen. (Das bedeutet, die logische Abfrage fragt nach einer bestimmten Information, gibt aber nicht an, wo diese auf der Festplatte zu finden ist, beispielsweise in Stapeln, Spuren, Sektoren oder Bytes.) Hier die Vorteile dieser Organisation:
Da Anwendungsprogramme nur wissen müssen, mit welchen Daten sie arbeiten wollen, und nicht, wo diese Daten genau abgelegt sind, sind sie nicht betroffen, wenn sich die physischen Details des Speicherorts der Daten ändern.
Die Übertragbarkeit zwischen verschiedenen Plattformen ist einfach, selbst wenn diese sehr unterschiedlich sind, solange das DBMS, das auf der ersten Plattform verwendet wird, auch auf der zweiten verfügbar ist. Im Allgemeinen müssen Sie die Programme überhaupt nicht ändern, um sie an verschiedene Plattformen anzupassen.
Was sind die Nachteile? Unter anderem:
Wenn ein Datenbankmanagementsystem zwischen das Anwendungsprogramm und die Daten geschaltet wird, verlangsamen sich die Operationen mit diesen Daten. Dies ist jedoch nicht mehr das Problem, das es früher war. Fortschritte, wie beispielsweise die Verwendung von Hochgeschwindigkeits-Cache-Speichern, haben dieses Problem erheblich entschärft.
Datenbanken benötigen mehr Speicherplatz auf der Festplatte als die gleiche Datenmenge in einem flachen Dateisystem. Dies ist darauf zurückzuführen, dass zusammen mit den Daten auch Metadaten gespeichert werden. Die Metadaten enthalten Informationen darüber, wie die Daten gespeichert sind, sodass die Anwendungsprogramme sie nicht einbeziehen müssen.
Ich wette, Sie kennen meine Antwort bereits. Sie haben wahrscheinlich recht, aber ganz so einfach ist es nicht. Es gibt nicht die eine richtige Antwort, die für alle Situationen gilt. In den Anfängen der elektronischen Datenverarbeitung waren flache Dateisysteme die einzige praktikable Lösung. Um eine vernünftige Berechnung zeitnah und wirtschaftlich durchführen zu können, musste man das Verfahren verwenden, das am schnellsten war und den geringsten Speicherplatz benötigte. Da immer mehr Anwendungssoftware für diese Systeme entwickelt wurde, waren die Unternehmen, die diese Systeme besaßen, immer stärker an das gebunden, was sie hatten. Um auf ein moderneres Datenbanksystem umzusteigen, mussten alle Anwendungen von Grund auf neu geschrieben und alle Daten neu organisiert werden – eine gewaltige Aufgabe. Infolgedessen gibt es immer noch alte Flat-File-Systeme, die weiterbestehen, weil ein Umstieg auf eine modernere Technologie nicht machbar ist, sowohl wirtschaftlich als auch zeitlich.
Wie stehen die Chancen, dass eine Person tatsächlich eine Nadel im Heuhaufen findet? Nicht sehr gut. Die sprichwörtliche Nadel zu finden, ist deshalb so schwer, weil der Heuhaufen ein zufälliger Haufen Heu ist, mit einzelnen Halmen, die in alle Richtungen zeigen, und einer Nadel, die sich an einem zufälligen Ort zwischen all dem Heu befindet.
Ein flaches Dateisystem ist nicht wirklich mit einem Heuhaufen vergleichbar, aber es fehlt ihm an Struktur, und um einen bestimmten Datensatz in einer solchen Datei zu finden, müssen Sie Werkzeuge verwenden, die außerhalb der Datei selbst liegen. Das ist so, als würde man einen starken Magneten auf den Heuhaufen anwenden, um die Nadel zu finden.
Damit eine Datensammlung nützlich ist, müssen Sie die gewünschten Daten einfach und schnell abrufen können, ohne sich durch den Rest der Daten bewegen zu müssen. Eine Möglichkeit, dies zu erreichen, besteht darin, die Daten in einer logischen Struktur zu speichern. Flache Dateien haben keine großartige Struktur, Datenbanken dagegen schon. Historisch gesehen wurden das hierarchische Datenbankmodell und das Netzwerk-Datenbankmodell vor dem relationalen Modell entwickelt. Jedes dieser Modelle organisiert die Daten auf eine andere Weise, aber alle drei führen zu einem strukturierten Ergebnis. Aus diesem Grund wurden ab den 1970er-Jahren alle neuen Entwicklungsprojekte hauptsächlich unter Verwendung eines der drei oben genannten Datenbankmodelle durchgeführt: hierarchisch, netzwerkartig oder relational. (Ich gehe auf jedes dieser Datenbankmodelle später in diesem Kapitel im Abschnitt »Die konkurrierender Datenbankmodelle« näher ein.)
Von allen Operationen, die Menschen mit einer Datensammlung durchführen, ist der Abruf bestimmter Elemente aus der Sammlung die wichtigste. Dies liegt daran, dass Abrufe häufiger durchgeführt werden als jede andere Operation. Die Dateneingabe wird nur einmal durchgeführt. Änderungen an bestehenden Daten werden relativ selten vorgenommen, und Daten werden nur einmal gelöscht. Abrufe hingegen werden häufig durchgeführt, und dieselben Datenelemente können viele Male abgerufen werden. Wenn man also etwas optimieren sollte, dann den Datenabruf. Moderne Datenbankmanagementsysteme unternehmen daher große Anstrengungen, um Abfragen schnell zu gestalten.
Abrufe werden durch Abfragen durchgeführt. Ein modernes Datenbankmanagementsystem analysiert eine Abfrage, die ihm vorgelegt wird, und entscheidet, wie sie am besten ausgeführt werden kann. In der Regel gibt es mehrere Möglichkeiten, eine Abfrage auszuführen, einige davon viel schneller als andere. Ein gutes DBMS wählt stets einen möglichst optimalen Ausführungsplan aus. Natürlich ist es hilfreich, wenn die Abfrage von vornherein optimal formuliert ist. (Ich bespreche Optimierungsstrategien ausführlich in Teil VII, der sich mit Datenbank-Tuning befasst.)
Das erste echte Datenbanksystem wurde von IBM in den 1960er-Jahren zur Unterstützung des Apollo-Mondlandungsprogramms der NASA entwickelt. Die Anzahl der Komponenten der Saturn V-Trägerrakete, für die Apollo-Befehls- und Servicemodule und die Mondlandefähre überstieg bei Weitem alles, was bis dahin gebaut worden war. Es musste gründlicher getestet werden als alles andere zuvor, denn jedes Bauteil musste den Unbilden einer Umgebung standhalten, die feindlicher und unnachgiebiger war als jede Umgebung, in der Menschen je zu arbeiten versucht hatten. Flache Dateisysteme kamen nicht in Frage. Die Lösung von IBM, die später in ein kommerzielles Datenbankprodukt mit dem Namen IMS (Information Management System) umgewandelt wurde, zeichnete jede einzelne Komponente sowie ihre gesamte Historie auf.
Als der Hauptsauerstofftank der gescheiterten Apollo 13 auf dem Weg zum Mond riss, arbeiteten die Ingenieure fieberhaft an einem Plan, um das Leben der drei Astronauten auf dem Weg zum Mond zu retten. Sie waren erfolgreich und konnten den Astronauten einen funktionierenden Plan übermitteln.
Nachdem die Besatzung sicher zur Erde zurückgekehrt war, ergab eine Abfrage der IMS-Aufzeichnungen über den ausgefallenen Sauerstofftank, dass er irgendwo zwischen seiner Herstellung und dem Einbau in Apollo 13 zu Boden gefallen war. Die Ingenieure testeten erneut, ob er dem Druck standhalten würde, den er während der Mission aushalten musste, und legten ihn nach bestandenem Test wieder auf Lager. Es stellte sich jedoch heraus, dass der Test einen versteckten Schaden am Tank nicht aufgedeckt hatte, und die NASA hätte diesen Sauerstofftank bei der Apollo-13-Mission nicht verwenden dürfen. Die im IMS gespeicherte Historie zeigt, dass das Bestehen eines Drucktests nicht ausreicht, um zu gewährleisten, dass ein zu Boden gefallener Tank unbeschädigt ist. Bei den nachfolgenden Apollo-Missionen wurde dies berücksichtigt.
Ein Datenbankmodell beschreibt einfach die Art und Weise, Datenelemente innerhalb einer Datenbank zu organisieren. In diesem Abschnitt stelle ich Ihnen die drei Datenbankmodelle vor, die als erste auf der Bildfläche erschienen sind:
Hierarchisch:
Organisiert Daten in Ebenen, wobei jede Ebene eine einzelne Datenkategorie enthält, und zwischen den Ebenen Eltern-Kind-Beziehungen hergestellt werden.
Netzwerk:
Organisiert Daten auf eine Weise, die einen Großteil der Redundanz des hierarchischen Modells vermeidet.
Relational:
Organisiert Daten in einer strukturierten Sammlung von zweidimensionalen Tabellen.
Nach der Einführung des hierarchischen, des Netzwerk- und des relationalen Modells haben Informatiker weitere Datenbankmodelle entwickelt, die sich in einigen Anwendungskategorien als nützlich erwiesen haben. Auf einige dieser Modelle und ihre Anwendungsbereiche werde ich später in diesem Kapitel kurz eingehen. Für allgemeine Geschäftsanwendungen wurden jedoch hauptsächlich die hierarchischen, netzwerkbasierten und relationalen Modelle verwendet.
Das erste funktionierende Datenbanksystem wurde von IBM entwickelt und ging am 14. August 1968 bei einem Apollo-Vertragspartner in Betrieb. (Lesen Sie die ganze Geschichte im Einschub »Das erste Datenbanksystem« in diesem Kapitel.) Es wurde als IMS (Information Management System) bezeichnet und ist (erstaunlicherweise) auch heute noch, über 50 Jahre später, im Einsatz, da IBM es zur Unterstützung seiner Kunden kontinuierlich weiterentwickelt hat.
Wenn Sie sich für ein Datenbankmanagementsystem entscheiden, sollten Sie in Erwägung ziehen, es von einem Anbieter zu kaufen, der es so lange unterstützen wird, wie Sie es nutzen wollen. IBM hat sich als ein solcher Anbieter erwiesen, aber natürlich gibt es auch andere.
IMS ist ein Beispiel für ein hierarchisches Datenbankprodukt. Etwa ein Jahr nach der Einführung von IMS wurde das Netzwerk-Datenbankmodell von einem Industrieausschuss beschrieben. Etwa ein Jahr später schlug Dr. Edgar F. »Ted« Codd, ebenfalls von IBM, das relationale Modell vor. Innerhalb weniger Jahre entstanden so die drei Modelle, die den Datenbankmarkt jahrzehntelang beherrschen sollten.
Es hat einige Jahre gedauert, bis das objektorientierte Datenbankmodell auf den Markt kam und sich als eine Alternative präsentierte, die einige der Mängel des relationalen Modells beheben sollte. Das objektorientierte Datenbankmodell