SQL Alles-in-einem-Band für Dummies E-Book

Allen G. Taylor

• Herausgeber: Wiley-VCH
• Kategorie: Wissenschaft und neue Technologien
• Serie: Für Dummies
• Sprache: Deutsch

Seitenzahl: 1027

Veröffentlichungsjahr: 2024

Beschreibung

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

• Wie Datenbanksysteme aufgebaut sind
• Was Sie beim Mehrbenutzerzugriff beachten sollten
• Welche Schnittstellen zu prozeduralen Programmiersprachen es gibt
• Wie Sie richtig auf Systemausfälle reagieren

Leseprobe

SQL Alles-in-einem-Band für Dummies

Schummelseite

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.

ENTWICKLUNGSPHASEN EINES SQL-SYSTEMS

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.

SQL-KRITERIEN FÜR NORMALFORMEN

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:

Erste Normalform (1NF):

Die Tabelle muss zweidimensional sein, mit Zeilen und Spalten.Jede Zeile enthält Daten, die sich auf eine Sache oder einen Teil einer Sache beziehen.Jede Spalte enthält Daten für ein einzelnes Attribut der beschriebenen Sache.Jede Zelle (Schnittpunkt von Zeile und Spalte) der Tabelle muss einwertig sein.Alle Einträge in einer Spalte müssen von der gleichen Art sein.Jede Spalte muss einen eindeutigen Namen haben.Keine zwei Zeilen dürfen identisch sein.Die Reihenfolge der Spalten und Zeilen spielt keine Rolle.

Zweite Normalform (2NF):

Die Tabelle muss in erster Normalform (1NF) vorliegen.Alle Nicht-Schlüsselattribute (Spalten) müssen vom gesamten Schlüssel abhängig sein.

Dritte Normalform (3NF):

Die Tabelle muss in zweiter Normalform (2NF) vorliegen.Tabelle hat keine transitiven Abhängigkeiten.

Domänen-Schlüssel-Normalform (DK/NF):

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

SQL-Datentypen

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

Genaue Zahlenangaben:

INTEGERSMALLINTBIGINTNUMERICDECIMALDECFLOAT

Ungefähre Zahlenangaben:

REALDOUBLE PRECISIONFLOAT

Boolesche Werte:

BOOLEAN

Zeichenfolgen:

CHARACTER (CHAR)CHARACTER VARYING (VARCHAR)NATIONAL CHARACTER (NCHAR)NATIONAL CHARACTER VARYING (NVARCHAR)

Datum/Zeit:

DATETIMETIMESTAMPTIME WITH TIMEZONETIMESTAMP WITH TIMEZONE

Intervalle:

INTERVAL DAYINTERVAL YEAR

Große Objekte:

BLOBCLOB

Sammlungen:

ARRAYMULTISET

Andere Typen:

ROWXMLJSON

SQL-WERTFUNKTIONEN

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.

Funktionen für Zeichenfolgenwerte

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

Funktionen für numerische Werte

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

Datetime-Wertfunktionen

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

SQL-MENGENFUNKTIONEN

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-Konstruktor-Funktionen

JSON_OBJECT

JSON_ARRAY

JSON_OBJECTAGG

JSON_ARRAYAGG

JSON-Abfragefunktionen

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

Die Autoren

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.

Widmung

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

Danksagung der Autoren

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.

Inhaltsverzeichnis

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

Tabellenverzeichnis

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

Illustrationsverzeichnis

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...

Orientierungspunkte

Cover

Titelblatt

Impressum

Die Autoren

Inhaltsverzeichnis

Einleitung

Fangen Sie an zu lesen

Glossar

Abbildungsverzeichnis

Stichwortverzeichnis

End User License Agreement

Seitenliste

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

Einleitung

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.

Über dieses Buch

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.

Törichte Annahmen über die Leser

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.

Wie dieses Buch aufgebaut ist

Teil I: SQL – Erste Schritte

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: Entwicklung relationaler Datenbanken

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.

Teil III: SQL-Abfragen

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: Sichern Sie Ihre Daten

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.

Teil V: Programmieren mit SQL

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.

Teil VI: Erweiterte Datentypen in SQL: XML, JSON und PGQ

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.

Teil VII: Datenbanken optimieren

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.

Symbole, die in diesem Buch verwendet werden

… 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.

Wie es weitergeht

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

SQL – Erste Schritte

IN DIESEM TEIL …

Vorteile von DatenbankenModellierung von DatenbankmodellenWas bedeutet SQL und was hat es mit relationalen Datenbanken zu tun?Die wichtigsten Komponenten von SQL kennenlernen

Kapitel 1

Relationale Datenbanken

IN DIESEM KAPITEL

Mit Dateien und Datenbanken arbeitenErkennen, wie Datenbanken, Abfragen und Datenbankanwendungen zusammenhängenVerschiedene Datenbankmodelle kennenlernenEinen Überblick über die Entwicklung der relationalen Datenbanken erhalten

SQL (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.

Verstehen, warum heutige Datenbanken besser sind als frühere

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.

Komplexität

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.

Datenverwaltung mit komplizierten Programmen

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.

Datenverwaltung mit einfachen Programmen

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.

Welche Art von Organisation ist besser?

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.

Datenbanken, Abfragen und Datenbankanwendungen

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.

Daten nützlich machen

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

Abrufen der gewünschten Daten – und nur der gewünschten Daten

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 Datenbanksystem

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.

Konkurrierende Datenbankmodelle

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.

Ein Blick auf den historischen Hintergrund der konkurrierenden Modelle

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