Datenbanken – Konzepte und Sprachen E-Book

Gunter Saake

• Herausgeber: MITP
• Kategorie: Wissenschaft und neue Technologien
• Serie: mitp Professional
• Sprache: Deutsch

Seitenzahl: 844

Veröffentlichungsjahr: 2018

Beschreibung

Das Standardwerk zum Thema Datenbanken in der aktualisierten 6. Auflage Inkl. neuer Kapitel u.a. zu NoSQL und NewSQL Zusätzliche Kapitel kostenfrei als Download verfügbar Dieses Buch behandelt die für die Anwendung von Datenbanksystemen und die Entwicklung von Datenbankanwendungen wichtigen Konzepte und Sprachen in systematischer und fundierter Weise. Neben theoretischen Konzepten und Modellierungstechniken werden viele praktische Aspekte der Arbeit mit SQL, der Entwicklung von Anwendungssystemen, des Einsatzes von XML, multimedialer und raumbezogener Daten sowie von OLAP- und Data-Warehouse-Systemen behandelt, wobei die aktuellen Entwicklungen und Standards berücksichtigt werden. Das Buch eignet sich somit als Lehrbuch für Studierende der Informatik und verwandter Fächer wie auch für Anwender und Entwickler, die sich über den Einsatz aktueller Datenbanktechnologie genauer informieren möchten. Zahlreiche Übungsaufgaben erleichtern das Selbststudium.

Leseprobe

Gunter SaakeKai-Uwe SattlerAndreas Heuer

Datenbanken

Konzepte und Sprachen

Sechste Auflage

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.dnb.de> abrufbar.

Bei der Herstellung des Werkes haben wir uns zukunftsbewusst für umweltverträgliche und wiederverwertbare Materialien entschieden.

Der Inhalt ist auf elementar chlorfreiem Papier gedruckt.

ISBN 978-3-95845-778-26. Auflage 2018

www.mitp.de

E-Mail: [email protected]: +49 7953 / 7189 - 079Telefax: +49 7953 / 7189 - 082

© 2018 mitp Verlags GmbH & Co. KG, Frechen

Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Lektorat: Sabine Janatschek, Ernst-Heinrich Pröfener Sprachkorrektorat: Jürgen Dubau, Astrid Langen Covergestaltung: Christian Kalkert, www.kalkert.de

Bildnachweis Cover: iStock.com/Shawn Hempel | fotolia.com/karpenko_ilia Satz: Gunter Saake, Magdeburg; Kai-Uwe Sattler, Ilmenau; Andreas Heuer, Rostock

Vorwort zur sechsten Auflage

Datenbanken sind nach Softwaretechnik das wichtigste Teilgebiet der Fachrichtung Informatik. In einer aktuellen Umfrage der Gesellschaft für Informatik (GI) bezeichnen sich 30,32 Prozent der Informatiker als Datenbänker1, der stärkste Wert nach dem Gebiet Softwaretechnik mit 33,39 Prozent. Selbst dem Fachgebiet Wirtschaftsinformatik ordnen sich weniger GI-Mitglieder zu (24,54 Prozent). Und weitere Gebiete wie Technische Informatik (11,44 Prozent), Künstliche Intelligenz (8,68 Prozent) und Computergraphik (4,38 Prozent) sind weit abgehängt.

Datenbanken, genauer das Gebiet der Verwaltung großer Mengen strukturierter Daten, ist auch eines der alten, klassischen Gebiete der Informatik. Datenbanksysteme gibt es auf heutzutage veralteten Datenbankmodellen wie dem hierarchischen und Netzwerk-Modell seit den sechziger Jahren, das derzeit immer noch verbreitetste relationale Datenbankmodell ist bereits in den siebziger Jahren in der Forschung und dann in den achtziger Jahren in Form von kommerziellen Datenbank-Management-Systemen eingeführt worden. Die auch aus den siebziger Jahren stammende Datenbanksprache SQL ist immer noch intergalactic dataspeak, also die Standardsprache für die Verwaltung strukturierter Daten. Analysiert man große Online-Stellenportale wie das von Monster, so ist SQL nach Java und fast gleichauf mit C++ die drittgefragteste Sprache der Informatik — weit vor Python und anderen modernen Programmiersprachen und weit vor anderen Daten- und Dokumentbeschreibungssprachen wie XML und JSON.

Datenbanken hatte man aufgrund der langen Vorgeschichte im neuen Jahrtausend sowohl als Forschungsgebiet als auch als modernes Lehrgebiet in der Informatik den schleichenden Tod vorausgesagt: Relationale Datenbanksysteme waren nun einmal einfach da, veränderten sich kaum noch, gehörten zur Folklore für Informatiker. Das Kerngebiet der Informatik schien aus der Mode zu kommen.

Aber plötzlich erlebte das Forschungs- und Lehrgebiet Datenbanken einen riesigen Boom als Kernstück moderner Informationssystem-Infrastrukturen: Sowohl die Hardware entwickelte sich in verschiedene Richtungen weiter, als auch Anwendungen wie das Internet, Big Data, Industrie 4.0, das Internet der Dinge und Digitalisierung im allgemeinen Sinne sind abhängig von einer riesigen Menge von Daten, die effizient verwaltet und wiedergefunden werden muss. Und im Sinne von Big Data Analytics und Maschinellem Lernen müssen Daten heutzutage auch nicht nur wiedergefunden werden, es müssen auch komplexe Muster in riesigen Datenmengen gefunden werden und sie müssen statistisch analysiert werden.

All das führte dazu, dass sich in den 10er Jahren dieses Jahrhunderts das Gebiet Datenbanken dynamischer entwickelt als je zuvor. Und obwohl in diesem Lehrbuch für eine erste Grundvorlesung Datenbanken im Bachelor-Studium der Informatik, Wirtschaftsinformatik oder Technischen Informatik im Wesentlichen die klassischen Grundlagen wie das relationale Datenbankmodell und SQL vorgestellt werden müssen, müssen sich die Autoren auch auf die vielfältigen Neuentwicklungen einstellen. Die führen dazu, dass das Buch in dieser sechsten Auflage von 2018 wieder umstrukturiert wurde. Wir stellen im Folgenden kurz die Veränderungen von der ersten zur fünften Auflage vor und beschreiben dann, welche Neuerungen diese sechste Auflage bestimmen.

Von der ersten zur fünften Auflage

Abbildung 1: Die zweite und dritte Auflage des Biberbuches

Die erste Auflage des Biber-Buches erschien im September 1995, die zweite im Januar 2000, die dritte dann in 2008 (Abbildung 1 zeigt die Cover der Auflagen 2 und 3). In der Zeit bis zur dritten Auflage, immerhin über zehn Jahre, waren wichtige Themen wie SQL:2003, XML, objektrelationale Datenbanken, Data Warehouses und die Verwaltung multimedialer Daten dazugekommen. Weiterhin hatten sich auch im Aufbau, in laufenden Beispielen und in der Didaktik in den Vorlesungen zum Buch diverse Änderungen ergeben, die zur völligen Neuentwicklung schon bestehender Buchkapitel in der dritten Auflage führte.

Die Überarbeitung in der dritten Auflage wurde auch dazu genutzt, um den Stoff des Buches neu zu organisieren. Diese Umstrukturierung wurde auch dadurch motiviert, dass in einer nur zweistündigen Vorlesung die ersten Kapitel in den vorherigen Auflagen zu gehaltvoll waren, um direkt chronologisch als Stoff für eine Vorlesung herzuhalten. Seit der dritten Auflage ist das Buch in drei Teile aufgeteilt:

Der erste Teil bearbeitet umfassend die Kernkonzepte der relationalen Datenbanken, ohne auf Spezialitäten und andere Datenmodelle einzugehen. Er bildet den Kern einer Vorlesung „Grundlagen von Datenbanken“ auch mit geringerem Stundenumfang.

Der zweite Teil vertieft die Themen des ersten Teils, und kann insbesondere für eine 3- oder 4-stündige Vorlesung herangezogen werden. Zusammen geben die ersten beiden Teile eine umfassende Behandlung von Theorie, Entwurfsmethoden und Sprachkonzepten für relationale Datenbanken inklusive der ausführlichen Behandlung von SQL.

Der dritte Teil behandelt Alternativen und Erweiterungen bei Datenmodellen. Hiervon können ausgewählte Teile in eine Grundvorlesung übernommen werden, oder die Basis für Spezialvorlesungen bilden. In diesen Kapiteln wird die Sprach- bzw. Anwendungssicht in den Vordergrund gestellt; Implementierungsaspekte werden im Buch „Datenbanken: Implementierungstechniken“ [SSH11] der Autoren behandelt und sind deshalb hier ausgeblendet.

Abbildung 2: Die vierte und fünfte Auflage des Biberbuches

In der fünften Auflage [SSH13] (siehe Abbildung 2) wurden erstmals Teile wieder aus dem Buch entfernt: Der Stoff zu Datenbankkonzepten für Data- Warehouse-Anwendungen wurde derart umfangreich, dass wir ihn aus dem

Buch herausnahmen und stattdessen auf ein eigenes Spezialbuch zu dieser Thematik verweisen mussten [KSS12]. Des weiteren wurden aufgrund von Anregungen von Lesern die Abschnitte zur relationalen Entwurfstheorie und zu SQL an einigen Stellen überarbeitet. Neu hinzugekommen waren Abschnitte zu Datenbankzugriffen in der Cloud, zu RDF-Daten und zu temporalen Daten.

Die hier vorliegende sechste Auflage

Die sechste Auflage bietet nun sowohl einige Umstrukturierungen, neue Kapitel zu aktuellen Themen als auch (leider) wieder Streichungen bestimmter Kapitel. Einige kleinere Fehler, die in den bisherigen Auflagen übersehen oder unglücklicherweise neu eingebaut wurden, haben wir in dieser sechsten Auflage auch korrigiert— und wahrscheinlich unvermeidlicherweise auch neue Fehler eingebaut. Im Wesentlichen haben wir aber den Stand der Technik auf das Jahr 2018 gebracht und beispielsweise den Stand der SQL-Standardisierung auf die derzeit aktuelle Version SQL:2016. Im Folgenden geben wir einen Überblick über die Änderungen. Eine Änderung auf dem Cover möchten wir noch erwähnen: Der Biber als Logo für die gesamte Buchreihe findet sich auch weiterhin (stilisiert und klein) auf dem Cover, hat aber dort seine seitenfüllende Präsenz verloren. Als Ausgleich haben wir in Abbildung 3 noch einmal den Biber in voller Schönheit präsentiert (gezeichnet von Arved Sattler).

Abbildung 3: Der Biber als Logo für die gesamte Buchreihe (Zeichnung von Arved Sattler)

Umstrukturierungen. Während die oben für die dritte Auflage beschriebene Aufteilung des Buches in Teile eins bis drei stabil bleibt, wurden bestehende Kapitel aufgetrennt und verschoben bzw. Teile des Stoffes neu zugeordnet.

Kapitel 1 haben wir stark gekürzt, da die Einführung in das klassische relationale Datenbankmodell nun in einem eigenen Kapitel direkt anschließend erfolgt.

Kapitel 2 ist neu und führt nun das relationale Datenbankmodell zunächst informal, aber bereits sehr frühzeitig im Buch ein.

In Kapitel 5 wird das relationale Datenbankmodell und die Relationenalgebra als erstes Anfragemodell formal eingeführt. Die alternativen Anfragekalküle werden aber erst im zweiten Teil des Buches in Kapitel 10 eingeführt.

Ebenso werden im Kapitel 7 über den Relationalen Datenbankentwurf nur noch die Kriterien für einen guten Datenbankentwurf und das einfachste Entwurfsverfahren, die Dekomposition, vorgestellt. Erweiterte Kriterien und Verfahren werden nun auch erst in einem eigenen Kapitel 9 im zweiten Teil des Buches aufgegriffen.

Der dritte Teil des Buches ab Kapitel 17 ist völlig neu strukturiert und sortiert worden. Hier beschreiben wir die diversen Erweiterungen des Relationenmodells und in den letzten Jahrzehnten entstandenen alternativen Datenbankmodelle, die in vielen Fällen auch als Erweiterungen in den SQL-Standard mit eingeflossen sind.

Neue Kapitel zu neuen Themen. In den letzten Jahren sind diverse Datenbanktechniken neu entwickelt worden, in eigenen Linien von Datenbanksystemen auch bereits umgesetzt und breit verwendet worden, teilweise aber auch bereits als Erweiterungen in den aktuellen SQL-Standard aufgenommen worden. Diese neuen Techniken werden in eigenen Abschnitten oder Kapiteln eingeführt, etwa die Erkennung von Tupelmustern in relationalen Datenbanken als neue Analyseform in SQL:2016 (Abschnitt 11.6) und erweiterte Programmierschnittstellen als Verbindung von Java mit relationalen Datenbanken (Abschnitt 14.4 zu JPA: Java Persistence API). Stark erweitert wurden im Bereich des Datenschutzes Anonymitätsmaße und die Prinzipien der datensparsamen Anfrageverarbeitung (Abschnitt 16.3) sowie im Bereich des Text Retrieval das Ranking im Vektorraummodell (Abschnitt 17.2). In zwei eigenen Kapiteln am Schluss des dritten Teiles gehen wir auf die Entwicklungen zu NoSQL- und NewSQL-Datenbanksystemen (Kapitel 21) sowie Graph-Datenbanken (Kapitel 22) näher ein.

Streichungen. Aufgrund des Umfangs des Buches und der produktionstechnisch vorgegebenen Seitengrenze mussten wir diverse Teile der fünften Auflage aus dem Buch streichen. Im digitalen Zeitalter nutzen wir aber die Möglichkeit, diese eliminierten Teile als virtuelle Kapitel über das Internet als pdf-Dateien zur Verfügung stellen zu können. Alle virtuellen Kapitel führen wir in Anhang B kurz ein, dort befindet sich auch der Link auf die elektronischen Dokumente. Die eliminierten Abschnitte oder Kapitel betreffen die historischen Modelle (hierarchisches Modell, Netzwerkmodell) aus der vorrelationalen Zeit, die Erweiterungen des Entity-Relationship-Modells als Entwurfsmodell, objektorientierte Datenbankmodelle inklusive des ODMG-Standards, einige Erweiterungen des Relationenmodells und ihrer Anfragesprachen um strukturierte Tabellen nicht in erster Normalform, eine Umsetzung der Relationenalgebra in eine Lehrsprache (Tutorial D) sowie ECA-Regeln und aktive Datenbanken.

Die Biber-Reihe

Das Gebiet Datenbanken wird in mehreren Büchern behandelt, an denen Autoren dieses Buches auch beteiligt sind. Obwohl nicht auf allen Covern der Bücher ein Bezug zum Biber hergestellt wird, nennen wir diese Bücher Biber 1 bis Biber 4, wobei Biber 1 das hier vorliegende Buch „Datenbanken: Konzepte und Sprachen“ darstellt.

Biber 2. Implementierungsaspekte von Datenbanksystemen wie Dateiorganisationsformen und Zugriffstrukturen (etwa Indexdateien), Anfrageoptimierung und Transaktionskonzepte (Concurrency Control) werden im Buch „Datenbanken: Implementierungstechniken“ [SSH11] behandelt (siehe Abbildung 4). Aufgrund der dramatischen Entwicklung im Bereich der Prozessoren (Single Instruction Multiple Data, Mehrkern) und der Speichertechnologie (Cache-Levels, Non-Volatile RAM, Storage Class Memory) müssen wir die hierfür vollständig neu entwickelten Implementierungstechniken in den nächsten Jahren in einem getrennten Band anbieten.

Abbildung 4: Der zweite Band der Biberbuch-Reihe: Biber 2 oder Datenbanken: Implementierungstechniken

Biber 3. Bereits in Auflage drei dieses Buches wurden die Datenbankkonzepte für Data-Warehouse-Anwendungen derart umfangreich, dass wir sie aus dem Buch herausnahmen und stattdessen in ein eigenes Spezialbuch zu dieser Thematik aufgenommen haben [KSS12].

Biber 4. Bei einem anderen Verlag ist zusätzlich ein Buch erschienen, das die Reihe durch Techniken für extrem große, auf diversen Rechnern im Netz verteilten Datenbeständen ergänzt sowie die parallele Verarbeitung von Datenbankoperationen auf Rechnerclustern thematisiert [RSS15].

Danksagungen

Zu danken haben wir bei den Neuauflagen dieses Biber-1-Buches insbesondere für Korrekturen und Hinweise zu nötigen Aktualisierungen und Erweiterungen unseren (jetzigen und ehemaligen) Mitarbeitern und Studenten Ingolf Geist, Eike Schallehn, Andreas Lübcke, Stephan Vornholt, Christine Krause, Rita Schindler, Constantin, Pohl, Meike Klettke, Holger Meyer, Temenushka Ignatova, Andre Peters, Martin Garbe, Alf-Christian Schering, Dagmar Waltemath, Nils Weber, Sebastian Schick, Thomas Nösinger sowie den Lesern Lorenz Froihofer und Andreas Hilmer. Weiterhin danken wir Knut Stolze für die Unterstützung bei praktischen Tests.

Speziell bei der sechsten Auflage bedanken wir uns bei Tanja Auge, Henrik Hertel, Mark Lukas Möller, Johannes Goltz, Michael Poppe, Daniel Dietrich, Ben Hellmanzik, Enrico Gruner, Frank Röger, Hannes Grunert, Ilvio Bruder und Frank Meyer.

Mit praktischen Tests haben bei der sechsten Auflage mitgeholfen: Ilvio Bruder, Daniel Dietrich, Johannes Goltz, Hannes Grunert, Martin Jurklies und Rita Schindler.

Ein Dankeschön geht auch an die zuständige Lektorin des MITP-Verlages Sabine Janatschek, die viel Geduld aufgebracht hat, sowie an Jürgen Dubau und Astrid Langen für das sorgfältige Korrekturlesen.

Gunter Saake bedankt sich bei Birgit, Torben und Annkristin für den liebevollen und familiären Rückhalt, der sich lange hinziehende Buchprojekte erst erträglich machen kann.

Kai-Uwe Sattler bedankt sich bei Britta, Arved und Bennett, ohne deren Liebe, Rückhalt und Verständnis ein solches Buchprojekt wohl nicht möglich wäre.

Andreas Heuer möchte sich schließlich bei Renate für die über 30-jährige Unterstützung und Geduld über alle sechs Auflagen hinweg bedanken.

Ergänzende Informationen zum Buch, wie Verweise zu begleitenden Vorlesungsmaterialien, gegebenenfalls erforderliche Fehlerkorrekturen und alle virtuellen Kapitel, die aus Platzgründen nicht mehr in dieses Buch passten, sind im Web unter folgender Adresse zu finden:

http://www.biberbuch.de

Informationen und Downloads zur Buchreihe gibt es auch auf der Verlagsseite:

http://www.mitp.de/776

Magdeburg, Ilmenau und Rostock, im Februar 2018

Gunter Saake, Kai-Uwe Sattler und Andreas Heuer

Inhaltsverzeichnis

Vorwort zur sechsten Auflage

Inhaltsverzeichnis

1 Grundlegende Konzepte

1.1 Motivation und Historie

1.2 Komponenten und Funktionen

1.2.1 Prinzipien und Aufgaben

1.2.2 Einsatzgebiete, Grenzen und Entwicklungstendenzen

1.2.3 Wann kommt was?

1.3 Beispielanwendung

1.4 Vertiefende Literatur

1.5 Übungsaufgaben

2 Relationale Datenbanken – Daten in Tabellen

2.1 Relationen für tabellarische Daten

2.1.1 Begriffe im Relationenmodell

2.1.2 Integritätsbedingungen: Schlüssel

2.1.3 Integritätsbedingungen: Fremdschlüssel

2.2 Datendefinition in SQL

2.2.1 Mögliche Wertebereiche in SQL

2.2.2 Beispiele für die Datendeklaration

2.2.3 Nullwerte

2.3 Grundoperationen: Die Relationenalgebra

2.3.1 Selektion σ

2.3.2 Projektion π

2.3.3 Natürlicher Verbund

2.3.4 Umbenennung ß

2.3.5 Mengenoperationen

2.4 Qualität entworfener Tabellen

2.5 SQL als Anfragesprache

2.6 Änderungsoperationen in SQL

2.6.1 Die update-Anweisung

2.6.2 Die delete-Anweisung

2.6.3 Die insert-Anweisung

2.7 Sichten in SQL

2.8 Wie geht es weiter?

2.9 Übungsaufgaben

I Kernkonzepte relationaler Datenbanken

3 Architekturen von Datenbanksystemen

3.1 Schemaarchitektur und Datenunabhängigkeit

3.2 Systemarchitekturen

3.2.1 ANSI-SPARC-Architektur

3.2.2 Der Weg einer Anfrage

3.2.3 Fünf-Schichten-Architektur

3.2.4 Konkrete Systemarchitekturen

3.3 Anwendungsarchitekturen

3.4 Zusammenfassung

3.5 Vertiefende Literatur

3.6 Übungsaufgaben

4 Das Entity-Relationship-Modell

4.1 Datenbankmodelle

4.2 Grundlagen des Entity-Relationship-Modells

4.2.1 Grundkonzepte des klassischen ER-Modells

4.2.2 Ein einfaches Beispiel für ein ER-Schema

4.2.3 Semantik eines ER-Schemas

4.3 Eigenschaften von Beziehungen

4.3.1 Stelligkeit

4.3.2 Kardinalitäten und funktionale Beziehungen

4.3.3 Kardinalitäten in der klassischen Chen-Notation

4.3.4 Kardinalitäten in funktionaler Notation

4.3.5 Kardinalitäten in Intervallnotation

4.4 Weitere Konzepte im Entity-Relationship-Modell

4.4.1 Abhängige Entity-Typen

4.4.2 Die IST-Beziehung

4.4.3 Optionalität von Attributen

4.5 Zusammenfassung

4.6 Vertiefende Literatur

4.7 Übungsaufgaben

5 Relationenmodell und Relationenalgebra

5.1 Relationenmodell: Strukturteil

5.1.1 Schemata und Instanzen

5.1.2 Integritätsbedingungen

5.2 Relationenalgebra: Operationenteil

5.2.1 Kriterien für Anfragesprachen

5.2.2 Relationenalgebra

5.3 Änderungsoperationen

5.3.1 Allgemeine Grundprinzipien

5.3.2 Relationale Änderungsoperationen

5.4 Zusammenfassung

5.5 Vertiefende Literatur

5.6 Übungsaufgaben

6 Phasen des Datenbankentwurfs

6.1 Entwurfsaufgabe

6.2 Phasenmodell

6.2.1 Anforderungsanalyse

6.2.2 Konzeptioneller Entwurf

6.2.3 Verteilungsentwurf

6.2.4 Logischer Entwurf

6.2.5 Datendefinition

6.2.6 Physischer Entwurf

6.2.7 Implementierung und Wartung

6.2.8 Objektorientierte Entwurfsmethoden

6.2.9 Phasenbegleitende Methoden

6.3 Aspekte der Datenintegration

6.3.1 Heterogenität der Datenmodelle

6.3.2 Heterogene Datenbankschemata

6.3.3 Heterogenität auf der Datenebene

6.3.4 Schemakonflikte bei der Integration

6.4 Entity-Relationship-Abbildung auf das Relationenmodell

6.4.1 Informationskapazität

6.4.2 Beispiel für eine Abbildung auf das Relationenmodell

6.4.3 Abbildungsregeln für das relationale Modell

6.5 Zusammenfassung

6.6 Vertiefende Literatur

6.7 Übungsaufgaben

7 Relationaler Datenbankentwurf

7.1 Funktionale Abhängigkeiten

7.1.1 Definition funktionaler Abhängigkeiten

7.1.2 Ableitung von funktionalen Abhängigkeiten

7.2 Schemaeigenschaften

7.2.1 Änderungsanomalien

7.2.2 Normalformen

7.2.3 Minimalität

7.3 Transformationseigenschaften

7.3.1 Abhängigkeitstreue

7.3.2 Verbundtreue

7.4 Entwurfsverfahren

7.4.1 Ziele

7.4.2 Dekompositionsverfahren

7.4.3 Ausblick Syntheseverfahren

7.5 Zusammenfassung

7.6 Vertiefende Literatur

7.7 Übungsaufgaben

8 Die relationale Datenbanksprache SQL

8.1 SQL als Datendefinitionssprache

8.1.1 Erzeugen von Tabellen

8.1.2 Tabellen mit Integritätsbedingungen

8.1.3 Löschen und Ändern von Tabellendefinitionen

8.1.4 Erzeugen und Löschen von Indexen

8.2 SQL als relationale Anfragesprache

8.2.1 Überblick

8.2.2 Die from-Klausel

8.2.3 Die select-Klausel

8.2.4 Die where-Klausel

8.2.5 Mengenoperationen

8.2.6 Schachtelung von Anfragen

8.2.7 Mächtigkeit des SQL-Kerns

8.3 Änderungsoperationen in SQL

8.3.1 Übersicht über Änderungen in SQL

8.3.2 Die update-Anweisung

8.3.3 Die delete-Anweisung

8.3.4 Die insert-Anweisung

8.3.5 Die merge-Anweisung

8.3.6 Probleme bei SQL-Änderungen

8.4 Zusammenfassung

8.5 Vertiefende Literatur

8.6 Übungsaufgaben

II Erweiterte Konzepte für relationale Datenbanken

9 Erweiterter relationaler Datenbankentwurf

9.1 Überdeckungen von funktionalen Abhängigkeiten

9.1.1 Nicht-redundante Überdeckung

9.1.2 Reduzierte Überdeckung

9.1.3 Bildung von Äquivalenzklassen

9.1.4 Minimale Überdeckung

9.1.5 Ringförmige Überdeckung

9.2 Syntheseverfahren

9.2.1 Ablauf der Synthese

9.2.2 Erreichung der Verbundtreue

9.3 Verfeinerung des Entity-Relationship-Datenbankentwurfs

9.4 Mehrwertige Abhängigkeiten

9.4.1 Grundlagen

9.4.2 Schemaeigenschaften

9.4.3 Transformationseigenschaften

9.5 Weitere Abhängigkeiten und Normalformen

9.5.1 Verbundabhängigkeiten

9.5.2 Inklusionsabhängigkeiten

9.5.3 Weitere relationale Entwurfsverfahren

9.5.4 Weitere Anwendungen der relationalen Theorie

9.6 Zusammenfassung

9.7 Vertiefende Literatur

9.8 Übungsaufgaben

10 Grundlagen von relationalen Anfragen

10.1 Erweiterungen der Relationenalgebra

10.2 Anfragekalküle

10.2.1 Ein allgemeiner Kalkül

10.2.2 Ergebnisbestimmung einer Anfrage

10.3 Tupelkalkül

10.3.1 Definition des Tupelkalküls

10.3.2 Beispielanfragen im Tupelkalkül

10.3.3 Bezug zu SQL

10.4 Bereichskalkül

10.4.1 Sichere Anfragen

10.4.2 Beispielanfragen im Bereichskalkül

10.4.3 Eigenschaften des Bereichskalküls

10.4.4 Relationenalgebraoperationen im Bereichskalkül

10.5 Zusammenfassung

10.6 Vertiefende Literatur

10.7 Übungsaufgaben

11 Erweiterte Konzepte von SQL

11.1 Weitere Operationen und Prädikate

11.1.1 Skalare Ausdrücke

11.1.2 Prädikate

11.1.3 Quantoren und Mengenvergleiche

11.1.4 Behandlung von Nullwerten

11.2 Aggregation, Gruppierung und Sortierung

11.2.1 Aggregatfunktionen

11.2.2 Gruppierung

11.2.3 Sortierung

11.2.4 Erweiterte Aggregatfunktionen in SQL:2003

11.2.5 Top-k-Anfragen

11.2.6 Skyline-Anfragen

11.3 Äußere Verbunde

11.4 Künstliche Schlüssel und Sequenzgeneratoren

11.5 Benannte Anfragen und Rekursion

11.5.1 Benannte Anfragen

11.5.2 Rekursive Anfragen

11.6 Erkennung von Tupelmustern

11.7 SQL-Versionen

11.7.1 SEQUEL2

11.7.2 SQL-89

11.7.3 SQL-92

11.7.4 SQL:1999 und SQL:2003

11.7.5 SQL:2006 und SQL:2008

11.7.6 SQL:2011 und SQL:2016

11.8 Zusammenfassung

11.9 Vertiefende Literatur

11.10 Übungsaufgaben

12 Weitere relationale Datenbanksprachen

12.1 QUEL

12.1.1 Anfragen in QUEL

12.1.2 Änderungsoperationen in QUEL

12.2 Query by Example

12.2.1 Anfragen in QBE

12.2.2 Funktionen, Sortierung und Aggregierung in QBE

12.2.3 Formale Semantik von QBE

12.2.4 Ausdrucksfähigkeit von QBE

12.2.5 Änderungen in QBE

12.2.6 Anfragen in MS Access

12.3 Datalog

12.3.1 Grundbegriffe

12.3.2 Semantik rekursiver Regeln

12.3.3 Semantik und Auswertung von Datalog

12.4 Zusammenfassung

12.5 Vertiefende Literatur

12.6 Übungsaufgaben

13 Transaktionen, Integrität & Trigger

13.1 Grundlagen von Transaktionen

13.1.1 ACID-Prinzip

13.1.2 Probleme im Mehrbenutzerbetrieb

13.1.3 Transaktionssteuerung in SQL

13.1.4 Transaktionen und Integritätssicherung

13.2 Architekturen zur Integritätssicherung

13.2.1 Integritätssicherung durch Anwendung

13.2.2 Integritätsmonitor als Komponente des DBMS

13.2.3 Integritätssicherung durch Einkapselung

13.3 Integritätsbedingungen in SQL

13.3.1 Inhärente Integritätsbedingungen im Relationenmodell

13.3.2 Weitere Bedingungen in der SQL-DDL

13.3.3 Die assertion-Klausel

13.3.4 Verwaltung und Überprüfung von Bedingungen

13.4 Klassifikation von Integritätsbedingungen

13.5 Trigger

13.6 Methoden der Integritätssicherung

13.6.1 Integritätssicherung durch Trigger

13.6.2 Integritätssicherung durch Anfragemodifikation

13.7 Zusammenfassung

13.8 Vertiefende Literatur

13.9 Übungsaufgaben

14 Datenbankanwendungsentwicklung

14.1 Grundprinzipien

14.2 Programmiersprachenanbindung: Call-Level-Schnittstellen

14.2.1 SQL/CLI: Der Standard

14.2.2 ODBC

14.2.3 JDBC

14.2.4 Weitere Call-Level-Schnittstellen

14.3 Eingebettetes SQL

14.3.1 Statische Einbettung: Embedded SQL

14.3.2 Dynamische Einbettung: Dynamic SQL

14.3.3 SQLJ: Embedded SQL für Java

14.4 High-Level-Schnittstellen

14.4.1 Persistenz von Objekten

14.4.2 Grundlagen der Abbildung

14.4.3 JPA und Hibernate

14.4.4 Weitere Technologien

14.5 Prozedurale SQL-Erweiterungen und Datenbanksprachen

14.5.1 Vorteile von gespeicherten Prozeduren

14.5.2 SQL/PSM: Der Standard

14.5.3 PL/SQL von Oracle

14.5.4 Gespeicherte Prozeduren in Java

14.6 Anwendungsentwicklung in der Cloud

14.6.1 Database-as-a-Service und Cloud-Datenbanken

14.6.2 Klassische DBMS in der Cloud

14.6.3 NoSQL-Systeme in der Cloud

14.7 Zusammenfassung

14.8 Vertiefende Literatur

14.9 Übungsaufgaben

15 Sichten

15.1 Motivation und Begriffsbildung

15.1.1 Sichten und externe Schemata

15.1.2 Definition von Sichten

15.1.3 Definition von Sichten in SQL

15.1.4 Vorteile von Sichten

15.2 Probleme mit Sichten

15.2.1 Kriterien für Änderungen auf Sichten

15.2.2 Projektionssichten

15.2.3 Selektionssichten

15.2.4 Verbundsichten

15.2.5 Aggregierungssichten

15.2.6 Klassifikation der Problembereiche

15.3 Behandlung von Sichten in SQL

15.3.1 Auswertung von Anfragen an Sichten in SQL

15.3.2 Sichtänderungen in SQL-92

15.3.3 Sichtänderungen ab SQL:2003

15.4 Theorie änderbarer Sichten

15.5 Instead-of-Trigger für Sichtänderungen

15.6 Zusammenfassung

15.7 Vertiefende Literatur

15.8 Übungsaufgaben

16 Zugriffskontrolle & Privacy

16.1 Sicherheitsmodelle

16.1.1 Diskrete Sicherheitsmodelle

16.1.2 Verbindliche Sicherheitsmodelle

16.2 Rechtevergabe in SQL

16.2.1 Benutzer und Schemata

16.2.2 Rechtevergabe in SQL

16.2.3 Zurücknahme von Rechten

16.2.4 Rollenmodell in SQL:2003

16.2.5 Auditing

16.2.6 Authentifikation und Autorisierung

16.3 Privacy-Aspekte in Datenbanken

16.3.1 Statistische Datenbanken

16.3.2 Quasi-Identifikator

16.3.3 k-Anonymität

16.3.4 l-Diversität, t-Closeness, Differential Privacy

16.3.5 Datensparsame Anfrageverarbeitung

16.4 Zusammenfassung

16.5 Vertiefende Literatur

16.6 Übungsaufgaben

III Erweiterte Datenbankmodelle und -techniken

17 Multimediale Daten

17.1 Multimedia-Datenbanken

17.1.1 Grundbegriffe

17.1.2 Grundlagen des Multimedia Retrieval

17.2 Text Retrieval

17.2.1 Information Retrieval auf Texten

17.2.2 Grundtechniken des Text Retrieval

17.2.3 Deskribierung

17.2.4 Recherche

17.2.5 Ranking

17.2.6 Information-Retrieval-Systeme

17.3 SQL/MM

17.3.1 SQL/MM Full Text

17.3.2 SQL/MM Still Image

17.3.3 Der Datentyp Video

17.3.4 SQL/MM Spatial

17.4 Zusammenfassung

17.5 Vertiefende Literatur

17.6 Übungsaufgaben

18 Räumliche und temporale Daten

18.1 Verwaltung raumbezogener Daten

18.1.1 Grundbegriffe

18.1.2 Modellierung raumbezogener Daten

18.1.3 Prädikate und Anfragen auf raumbezogenen Daten

18.1.4 Oracle Spatial

18.1.5 Weitere Systeme

18.2 Temporale Daten

18.2.1 Grundbegriffe

18.2.2 Umsetzung in SQL

18.2.3 Temporale Schlüssel, Fremdschlüssel und Anfragen

18.2.4 Weitere Entwicklung und Einordnung

18.3 Zusammenfassung

18.4 Vertiefende Literatur

18.5 Übungsaufgaben

19 Objektorientierte und objektrelationale Modelle

19.1 Exkurs: Objektorientierte Datenbankmodelle

19.2 Abbildung von Objekten auf Relationen

19.2.1 Typkonstruktoren

19.2.2 Abbildung der Spezialisierungshierarchie

19.3 Objektrelationale Erweiterungen

19.3.1 Large Objects: BLOB und CLOB

19.3.2 Typkonstruktoren

19.3.3 Identitäten, Referenzen und Pfadausdrücke

19.3.4 Hierarchien und Vererbung

19.3.5 Methoden

19.4 Objektrelationale Konzepte in SQL:2003

19.4.1 Typsystem und DDL

19.4.2 Anfragen

19.4.3 Methoden in SQL:2003

19.5 Zusammenfassung

19.6 Vertiefende Literatur

19.7 Übungsaufgaben

20 XML, XQuery und SQL/XML

20.1 Semistrukturierte Datenmodelle

20.1.1 Merkmale semistrukturierter Datenmodelle

20.1.2 Datenmodelle für semistrukturierte Dokumente

20.2 XML

20.2.1 Bausteine von XML

20.2.2 Verarbeitung von XML

20.3 Datendefinition in XML

20.3.1 Dokumenttypdefinition

20.3.2 XML Schema

20.3.3 XML-Abbildung auf relationale Schemata

20.4 Navigation in XML-Dokumenten: XPath

20.4.1 Pfadausdrücke und Lokalisierungsschritte

20.4.2 Selektionsprädikate und Funktionen

20.5 Die Anfragesprache XQuery

20.5.1 FLWOR-Ausdrücke

20.5.2 Elementkonstruktoren

20.5.3 Verbunde und Gruppierungen

20.5.4 Ausdrücke und Vergleiche

20.5.5 Funktionen

20.6 SQL/XML: XML-Erweiterungen für SQL

20.6.1 XML-Datentypen

20.6.2 XML-Konstruktion mit SQL

20.7 Zusammenfassung

20.8 Vertiefende Literatur

20.9 Übungsaufgaben

21 NoSQL-Datenbanken

21.1 Exkurs: Big Data

21.2 Motivation für NoSQL

21.3 KV-Stores und das Wide-Column-Datenmodell

21.3.1 Datenmodell: Key-Value-Stores

21.3.2 Datenmodell: Wide Column

21.4 Document Stores

21.4.1 Das JSON-Format

21.4.2 Anfragen bei dokumentenorientierter Speicherung

21.4.3 Datenrepräsentation und Anfragen in MongoDB

21.5 NewSQL – relationale Datenbanken schlagen zurück

21.6 Zusammenfassung

21.7 Vertiefende Literatur

21.8 Übungsaufgaben

22 Graph-Datenbanken

22.1 Graph-Datenmodelle: Grundlagen

22.1.1 Repräsentation von Graphstrukturen

22.1.2 Operationen und Anfragen auf Graphen

22.2 Das Resource Description Framework

22.2.1 Das RDF-Modell

22.2.2 RDF-Repräsentationen

22.2.3 RDF Schema und Vokabulare

22.3 Die RDF-Anfragesprache SPARQL

22.3.1 Grundlagen

22.3.2 SPARQL-Elemente

22.3.3 Aggregation und Gruppierung

22.3.4 Weitere Anfragetypen

22.3.5 Updates

22.4 Property-Graph-Modelle

22.4.1 Anfragen in Cypher

22.4.2 Anfragen in Gremlin

22.5 Zusammenfassung

22.6 Vertiefende Literatur

22.7 Übungsaufgaben

A Laufendes Beispiel

A.1 ER-Schema der Weindatenbank

A.2 Relationale Repräsentation

A.3 Vereinfachtes Schema und Beispieldaten

B Zusätzliche Kapitel

B.1 Historische Modelle

B.2 Erweiterte Entwurfsmodelle

B.3 Erweiterte Modelle und Anfragealgebren

B.4 Objektorientierte und objektrelationale Modelle inklusive SQL:2003

B.5 Tutorial D

B.6 ECA-Regeln und aktive Datenbanken

B.7 Grundlegende Datenbanktechniken

B.8 SQL/JSON

Literaturverzeichnis

1

Grundlegende Konzepte

Dieses erste Kapitel ist den grundlegenden Konzepten der Datenbankterminologie und -technik gewidmet. Wir werden uns die historische Entwicklung von Datenbanksystemen ansehen, Gründe für den Einsatz von derartigen Systemen diskutieren sowie Funktionen und Architektur von Datenbanksystemen betrachten. Ferner stellen wir als eine Beispielanwendung eine Weinkellerverwaltung vor, die wir über das ganze Buch hinweg verwenden werden.

1.1 Motivation und Historie

Wie ordnen sich Datenbanksysteme in die Vielfalt von Softwarepaketen ein, die heutzutage eingesetzt werden? Zur Beantwortung dieser Frage diskutieren wir zuerst eine verbreitete Klassifikation von Softwaresystemen.

Softwareschichten

Üblicherweise teilt man die Software eines Computersystems in mehrere Schichten ein, etwa der Aufteilung in Abbildung 1.1 folgend. In der Praxis können natürlich einige Softwarepakete mehrere Schichten umfassen.

Jede Schicht baut auf den weiter innen liegenden Schichten auf. Beispielsweise bietet das Betriebssystem Dateien und Operationen auf Dateien, Möglichkeiten zum Drucken etc. an. Anwendungssoftware wie Textverarbeitungssoftware nutzt diese Möglichkeiten als Dienste der niedrigeren Schicht. Als Beispiele für typische Softwareprodukte auf den einzelnen Schichten mag die folgende Auswahl dienen:

• Typische Betriebssysteme sind etwa Windows, Linux, MacOS X oder z/OS.

Abbildung 1.1: Aufteilung in Softwareschichten

• Zur Systemsoftware, die direkt auf diesen Betriebssystemen aufbaut, zählen Datenbanksysteme und Benutzerschnittstellen (wie das Windows-GUI oder X11-Produkte unter Unix).

• Zur Basissoftware, die wiederum auf der Systemsoftware aufbaut, gehören etwa Graphiksysteme wie OpenGL.

• Anwendungs- und Individualsoftware ist auf bestimmte Anwendungsklassen hin zugeschnitten: CAD-Systeme für Konstruktionsanwendungen, Desktop-Publishing-Systeme für Publikationsanwendungen sowie Buchhaltungssysteme, Lagerverwaltungssysteme oder allgemeiner ERP-Systeme (Enterprise Resource Planning) zur Unterstützung aller Geschäftsprozesse in Unternehmen.

Die Rolle der Datenbanksysteme ist also eine sehr elementare. Idealerweise sollten selbst Textverarbeitungssysteme ihre Texte und Informationen über Texte in einem Datenbanksystem verwalten und nicht einfach in einem Dateisystem. Genauso sollten CAD-Systeme sich allgemeinerer Graphiksysteme bedienen und diese wiederum zur Speicherung von Graphiken auf Datenbanksysteme zurückgreifen. Die Welt der kommerziellen Software ist von dieser Idealvorstellung jedoch leider noch etwas entfernt.

Das Problem der Datenredundanz

Ohne den Einsatz von Datenbanksystemen tritt das Problem der Datenredundanz auf. Die Basis- oder Anwendungssoftware verwaltet in diesem Szenario jeweils ihre eigenen Daten in ihren eigenen Dateien, und zwar jeweils in eigenen speziellen Formaten. Ein typisches Szenario gibt die folgende Auflistung wieder:

• Ein Textverarbeitungssystem verwaltet Texte, Artikel und Adressen.

• Die Buchhaltung speichert ebenso Artikel- und Adressinformationen.

• In der Lagerverwaltung werden Artikel und Aufträge benötigt und verwendet.

• Die Auftragsverwaltung manipuliert Aufträge, Artikel und Kundenadressen.

• Das CAD-System verwaltet Artikeldaten, technische Daten und technische Bausteine.

• Die Bereiche Produktion, Bestelleingang und Kalkulation benötigen teilweise ebenfalls diese Daten.

In diesem Szenario sind die Daten redundant, also mehrfach gespeichert. So werden Artikel und Adressen von mehreren Anwendungen verwaltet. Die entstehenden Probleme sind Verschwendung von Speicherplatz und „Vergessen“ von lokalen Änderungen, die typisch für das Fehlen einer zentralen, genormten Datenhaltung sind. Ein Ziel der Entwicklung von Datenbanksystemen ist die Beseitigung der Datenredundanz.

Weitere Problemfelder

Die meisten anderen Softwaresysteme (auch Programmiersprachen, Tabellenkalkulationen, Dateiverwaltungssysteme …) können große Mengen von Daten nicht effizient verarbeiten, so dass fehlender Einsatz von Datenbankmanagementsystemen (DBMS) zu erheblichen Effizienzeinbußen führen kann. Auch ermöglichen es viele Systeme nicht, dass mehrere Benutzer oder Anwendungen parallel mit den gleichen Daten arbeiten können, ohne einander zu stören. Weiterhin können gar Datenverluste durch unkontrolliertes Überschreiben entstehen. Diese Kontrolle ist eine Basisfunktion moderner DBMS.

Auch in der Anwendungserstellung führt der fehlende Einsatz einer zentralen Datenhaltungskomponente zu erheblichen Defiziten. Die Anwendungsprogrammierer oder auch Endanwender können Anwendungen nicht programmieren bzw. benutzen, ohne

• die interne Darstellung der Daten sowie

• Speichermedien oder Rechner (bei verteilten Systemen)

zu kennen. Dieses Problem wird als fehlende Datenunabhängigkeit bezeichnet und in Abschnitt 3.1 intensiver diskutiert. Auch ist die Sicherstellung der Zugriffskontrolle und der Datensicherheit ohne zentrale Datenhaltung nicht gewährleistet.

Datenintegration

Die obigen Probleme können mithilfe des Einsatzes von Datenbanktechnologien gelöst werden. Wir sprechen dann im Gegensatz zur Datenredundanz von einer Datenintegration. Das Prinzip der Datenintegration basiert auf folgenden Überlegungen:

Die gesamte Basis- und Anwendungssoftware arbeitet mit denselben Daten, die in einer zentralen Datenhaltungskomponente verwaltet werden. Der Gesamtbestand der Daten wird nun als Datenbank bezeichnet. Diese Architekturvorstellung wird in Abbildung 1.4 auf Seite 6 im Rahmen der historischen Entwicklung von Datenhaltungskomponenten graphisch verdeutlicht. Eine derartige Datenbank muss natürlich äußerst sorgfältig entworfen und in einer geeigneten Datendefinitionssprache beschrieben werden.

In unserem Beispielszenario bedeutet Datenintegration, dass zum Beispiel Adressen und Artikel nur einmal gespeichert werden, also nicht mehr redundant vorliegen.

Auch andere Probleme im Umgang mit großen Datenbeständen, etwa Fragestellungen der Effizienz, Parallelität, Zugriffskontrolle und Datensicherheit können mit heutigen kommerziellen Datenbankmanagementsystemen zufriedenstellend gelöst werden. Diese Systeme zeichnen sich durch folgende Eigenschaften aus:

• Datenbanksysteme können große Datenmengen effizient verwalten. Sie bieten benutzergerechte Anfragesprachen an, die eine komfortable Anfrageformulierung ohne Rücksichtnahme auf die interne Realisierung der Datenspeicherung ermöglichen. Eine interne Optimierung ermöglicht trotzdem einen effizienten Zugriff auf die Datenbestände.

• Viele Benutzer können parallel auf Datenbanken arbeiten. Das Transaktionskonzept verhindert hier unerwünschte Nebeneffekte beim Zugriff auf gemeinsam genutzte Daten.

• Die Datenunabhängigkeit wird durch ein Drei-Ebenen-Konzept gewährleistet, das eine externe Ebene der Anwendungssicht, eine konzeptuelle Ebene der logischen Gesamtsicht auf den Datenbestand und eine interne Ebene der implementierten Datenstrukturen unterscheidet.

• Zugriffskontrolle (kein unbefugter Zugriff) und Datensicherheit (kein ungewollter Datenverlust) werden vom System gewährleistet.

Historische Entwicklung

Die historische Entwicklung hin zu Datenbankmanagementsystemen kann in drei Stufen skizziert werden:

Die erste Stufe ist zu Beginn der 60er Jahre anzusiedeln, also zu einem Zeitpunkt, als die ersten Anwendungen der Massendatenverarbeitung auf Rechnern realisiert wurden. Die Daten wurden in elementaren Dateien abgelegt, und es erfolgte eine anwendungsspezifische Datenorganisation. Die Datenorganisation war geräteabhängig, zwangsweise redundant und führte leicht zu inkonsistenten Datenbeständen. Die Situation ist in Abbildung 1.2 verdeutlicht.

Abbildung 1.2: Historische Entwicklung 1: Zugriff auf Dateien ohne spezielle Verwaltung

Die zweite Stufe kennzeichnet die Situation Ende der 60er Jahre. Sie ist durch die Verwendung sogenannter Dateiverwaltungssysteme gekennzeichnet (bekannte Methoden sind etwa die Systeme SAM und ISAM für den sequentiellen und indexsequentiellen Dateizugriff, die auch in der Datenbankimplementierung eine große Rolle spielen [HR01, SSH11]). Dateiverwaltungssysteme konnten um zusätzliche Dienstprogramme ergänzt werden, etwa zum Sortieren von Datenbeständen. Die Situation der zweiten Stufe ist in Abbildung 1.3 dargestellt. Als wesentlicher Fortschritt wurde die Geräteunabhängigkeit der Datenhaltung erreicht, die Probleme der redundanten und eventuell inkonsistenten Datenhaltung blieben aber bestehen.

Diese Probleme konnten ab den 70er Jahren mit dem Einsatz von Datenbanksystemen gelöst werden. Sie garantieren Geräte- und Datenunabhängigkeit und ermöglichen eine redundanzfreie und konsistente Datenhaltung. Das Prinzip der Datenbanksysteme ist in Abbildung 1.4 skizziert: Der Datenbestand ist in einer Datenbank integriert, und jeder Zugriff erfolgt ausschließlich durch den „Filter“ des DBMS.

Abbildung 1.3: Historische Entwicklung 2: Dateiverwaltungssoftware

Abbildung 1.4: Historische Entwicklung 3: Datenbankmanagementsysteme

Ein wesentlicher Erfolgsfaktor war das von Codd vorgeschlagene Relationenmodell und dessen Umsetzung in relationalen Datenbanksystemen. Das erste System wurde – noch als Forschungsprototyp – von IBM unter dem Namen System R entwickelt und 1977 erstmals in einer größeren Installation eingesetzt. Später wurde es in das kommerzielle Produkt unter dem Namen DB2 überführt. Fast zeitgleich wurde an der University of California in Berkeley (UCB) unter Leitung von Mike Stonebraker das System Ingres entwickelt, das Vorläufer für Systeme wie Postgres, Sybase und der aktuellen Version von Ingres war. 1979 wurde auch Oracle erstmals veröffentlicht – interessanterweise gleich als Version 2, weil die Firma (wohl berechtigterweise) davon ausging, dass Kunden der zweiten Version eines Produktes mehr Vertrauen schenken würden. Darüber hinaus hat Oracle von Beginn an die Bedeutung einer Standardisierung erkannt und dies in Form einer Kompatibilität zum IBM-Konkurrenzprodukt umgesetzt. Dagegen war das DBMS von Microsoft – der SQL Server – zunächst keine Eigenentwicklung: Als Microsoft Ende der 80er Jahre den Bedarf eines DBMS für die eigene Serverplattform Windows NT erkannte, wurde kurzerhand der Quellcode von Sybase gekauft und als eigenes Produkt vermarktet. Erst nach und nach haben sich die beiden Produkte unabhängig voneinander weiterentwickelt.

Nachdem der Markt für SQL-basierte RDBMS mit drei bis vier großen Playern jahrzehntelang sehr überschaubar war, ist er nach 2000 geradezu explodiert, indem beispielsweise Open Source DBMS (etwa MySQL) und komplette Neuentwicklungen wie SAP HANA eine bisher ungewohnte Vielfalt erzeugten.

Neben dem stabilen Einsatz von SQL-DBMS lassen sich ferner Zehn- Jahres-Hypes von innovativen Datenbanktechnologien erkennen, die zu sehr vielen Neuentwicklungen geführt haben, deren Technologien aber üblicherweise dann vom SQL-Standard und von den RDBMS-Herstellern nach der Hype-Zeit aufgegriffen wurden. In den 90ern wurden die objektorientierten DBMS populär, deren Konzepte zum großen Teil in die SQL-Standards SQL:1999 und SQL:2003 aufgenommen und in objektrelationalen DBMS dann weit verbreitet wurden. In den 00er Jahren wurden XML-Datenbanksysteme modern, die in der Dokumentbeschreibungssprache XML strukturierte Daten und Dokumente verarbeiten konnten. Sie wurden dann von SQL:2003 bis SQL:2008 schrittweise in den SQL-Standard aufgenommen (SQL/XML). In den 10er Jahren sind NoSQL-Datenbanksysteme, die schwachstrukturierte Daten sehr flexibel und hochgradig skalierbar verarbeiten können, der aktuelle Hype. Die RDBMS-Hersteller reagieren auf diesen Trend durch diverse Verbesserungen auf der internen Ebene der DBMS sowie durch Spracherweiterungen, die insgesamt mit NewSQL zusammengefasst werden. Erste Ansätze sind auch bereits im SQL-Standard erschienen (SQL:2016: SQL/JSON).

Die Entwicklung der Datenbanksysteme bis zum heutigen Stand sowie aktuelle Entwicklungstendenzen werden wir in den verschiedenen Abschnitten dieses Buchs noch genauer betrachten.

1.2 Komponenten und Funktionen

Im vorigen Abschnitt haben wir die Vorteile von Datenbanksystemen gegenüber einfacher Dateispeicherung erläutert. In diesem Abschnitt werden wir uns die Aufgaben eines derartigen Systems sowie die daraus folgenden grundlegenden Komponenten eines Datenbanksystems im Überblick anschauen. Eine genauere Beschreibung der Komponenten eines DBMS und insbesondere der verwendeten Implementierungstechniken kann im Datenbankimplementierungsbuch [SSH11] gefunden werden.

1.2.1 Prinzipien und Aufgaben

Wir wollen die Diskussion der Funktionen eines Datenbanksystems damit beginnen, dass wir die allgemeinen Aufgaben kurz skizzieren sowie einige grundlegende Begriffe einführen.

Aufgaben eines Datenbankmanagementsystems (DBMS)

Im Laufe der Jahre hat sich eine Basisfunktionalität herauskristallisiert, die von einem Datenbankmanagementsystem erwartet wird. Codd hat 1982 diese Anforderungen in neun Punkten zusammengefasst [Cod82]:

1. IntegrationDie Datenintegration erfordert die einheitliche Verwaltung aller von Anwendungen benötigten Daten. Hier verbirgt sich die Möglichkeit der kontrollierten nicht-redundanten Datenhaltung des gesamten relevanten Datenbestands.

2. OperationenAuf der Datenbank müssen Operationen möglich sein, die Datenspeicherung, Suchen und Änderungen des Datenbestands ermöglichen.

3. KatalogDer Katalog, auch Data Dictionary genannt, ermöglicht Zugriffe auf die Datenbeschreibungen der Datenbank.

4. BenutzersichtenFür unterschiedliche Anwendungen sind unterschiedliche Sichten auf den Datenbestand notwendig, sei es in der Auswahl relevanter Daten oder in einer angepassten Strukturierung des Datenbestands. Die Abbildung dieser speziellen Sichten auf den Gesamtdatenbestand muss vom System kontrolliert werden.

5. KonsistenzüberwachungDie Konsistenzüberwachung, auch als Integritätssicherung bekannt, übernimmt die Gewährleistung korrekter Datenbankinhalte und der korrekten Ausführung von Änderungen, so dass diese die Konsistenz nicht verletzen können.

6. ZugriffskontrolleAufgabe des Zugriffskontrolle ist der Ausschluss unautorisierter Zugriffe auf die gespeicherten Daten. Dies umfasst datenschutzrechtlich relevante Aspekte personenbezogener Informationen ebenso wie den Schutz firmenspezifischer Datenbestände vor Werksspionage.

7. TransaktionenUnter einer Transaktion versteht man eine Zusammenfassung von Datenbankänderungen zu Funktionseinheiten, die als Ganzes ausgeführt werden sollen und die bei Erfolg permanent in der Datenbank gespeichert werden.

8. SynchronisationKonkurrierende Transaktionen mehrerer Benutzer müssen synchronisiert werden, um gegenseitige Beeinflussungen, etwa Schreibkonflikte auf gemeinsam benötigten Datenbeständen, zu vermeiden.

9. DatensicherungAufgabe der Datensicherung ist es, die Wiederherstellung von Daten, etwa nach Systemfehlern, zu ermöglichen.

Prinzipien von Datenbanksystemen

Unter dem Begriff Datenbankmanagementsystem verstehen wir die Gesamtheit der Softwaremodule, die die Verwaltung einer Datenbank übernehmen. Ein Datenbanksystem, kurz DBS, ist die Kombination eines DBMS mit einer Datenbank1. Diese Begriffsbildung ist für das Verständnis der Datenbankkonzepte essentiell und wird in Tabelle 1.1 zusammengefasst.

Tabelle 1.1: Begriffsbildungen für Datenbanksysteme

Grundmerkmale von modernen Datenbanksystemen sind die folgenden (angelehnt an die aufgeführten neun Punkte von Codd):

• DBMSe verwalten persistente (langfristig zu haltende) Daten, die einzelne Läufe von Anwendungsprogrammen überstehen sollen.

• Sie haben die Aufgabe, große Datenmengen effizient zu verwalten.

• DBMSe definieren ein Datenbankmodell, mit dessen Konzepten alle Daten einheitlich beschrieben werden.

• Sie stellen Operationen und Sprachen (Datendefinitionssprache, interaktive Anfragesprachen, Datenmanipulationssprachen usw.) zur Verfügung. Derartige Sprachen sind deskriptiv, verzichten also auf die explizite Angabe von Berechnungsschritten. Die Sprachen sind getrennt von einer Programmiersprache zu benutzen.

• DBMSe unterstützen das Transaktionskonzept inklusive Mehrbenutzerkontrolle: Logisch zusammenhängende Operationen werden zu Transaktionen zusammengefasst, die als atomare (unteilbare) Einheit bearbeitet werden. Auswirkungen von Transaktionen sind langlebig. Transaktionen können parallel durchgeführt werden, wobei sie voneinander isoliert werden.

• Sie unterstützen die Einhaltung des Datenschutzes, gewährleisten Datenintegrität (Konsistenz) und fördern die Datensicherheit durch geeignete Maßnahmen.

1.2.2 Einsatzgebiete, Grenzen und Entwicklungstendenzen

Bisher haben wir die Grundkonzepte von DBMS beschrieben. Nun müssen wir sie in die Softwarelandschaft einordnen sowie Entwicklungslinien der Vergangenheit und Entwicklungstendenzen der Zukunft diskutieren.

Einsatzgebiete und Grenzen

Die klassischen Einsatzgebiete der Datenbanken sind Anwendungen im kommerziellen Bereich, die sich aus Buchhaltungs- und Katalogisierungsproblemen entwickelt haben. Ein typisches Beispiel neben unserer kleinen Weindatenbank sind beispielsweise Artikelverwaltungs- und Bestellsysteme im Handel bzw. E-Commerce. Derartige Anwendungen zeichnen sich durch einige Charakteristika aus: Es gibt viele Objekte (20.000 Artikel, 10.000 Kunden, 1.000 Bestellvorgänge pro Tag usw.), aber vergleichsweise wenige Objekttypen (ARTIKEL, KUNDE, BESTELLUNG). Objekte sind einfach strukturiert und verhältnismäßig klein. Durchzuführende Transaktionen sind kurz und betreffen wenige Objekte (etwa die Bestellung eines Artikels), und die ausgeführten Operationen sind relativ unkompliziert, wie etwa einfache arithmetische Berechnungen.

Andere wichtige Beispiele für Datenbankanwendungen sind Enterprise Resource Planning (ERP)-Systeme, die die gesamte Ressourcenplanung in Unternehmen unterstützen. Derartige Systeme beinhalten neben der Stammdatenverwaltung Komponenten für die Materialwirtschaft (Lagerhaltung, Beschaffung), Finanz- und Rechnungswesen, Controlling, Personalwirtschaft und Produktion2. Die bekanntesten Vertreter sind sicherlich SAP R/3 bzw. der Nachfolger mySAP ERP und PeopleSoft.

Ein weiteres Beispiel sind Customer Relationship Management (CRM)- Systeme, die zur Verwaltung der Kundenbeziehungen eines Unternehmens dienen. In einer Datenbank werden dazu alle Kundenkontakte erfasst – beginnend bei den Adressen über die Historie von Anfragen, Angeboten und Kaufvorgängen bis hin zur finanziellen Situation. Derartige Systeme werden insbesondere zur Unterstützung des Vertriebs und für Marketingaktionen eingesetzt.

Datenbanksysteme bilden auch die Basis für sogenannte Data Warehouses. Hierbei handelt es sich um eine integrierte Datenbasis für Unternehmensdaten aus verschiedenen Quellsystemen, die zum Zweck der Analyse längerfristig und unabhängig von den Quellsystemen gespeichert werden. Aspekte von Data Warehouses werden u.a. in [KSS12] ausführlich behandelt.

Natürlich haben herkömmliche Datenbanksysteme auch Grenzen:

• Relationale Datenbanksysteme mit ihren flachen, einheitlich strukturierten Daten (siehe Kapitel 2) sind überfordert, wenn sehr tiefe, auch wechselnde Strukturen der Daten mit vielen Objekttypen benötigt werden und wenn Transaktionen viele Objekte über längere Zeiträume hinweg manipulieren. Beispiele hierfür sind CAD- und andere technische oder wissenschaftliche Anwendungen wie in der Physik, Astronomie oder Genomforschung.

• Auch Anwendungen, in denen kontinuierlich und unter Umständen große Datenmengen erzeugt werden, die möglichst zeitnah oder gar in Echtzeit verarbeitet werden müssen, stellen relationale Datenbanksysteme vor Probleme. Beispiele hierfür sind die Verarbeitung von Protokolldaten in Telekommunikationsnetzwerken, von Sensordaten in der Umweltmessung, in Logistik- und Fertigungsprozessen, der Verkehrssteuerung oder der Satellitenüberwachung. Hier verbietet sich oft schon aufgrund des Datenvolumens und der theoretischen Unendlichkeit der Daten eine Ablage in einem Datenbanksystem und eine darauf aufbauende Verarbeitung durch Anfragen.

Entwicklungslinien bei Datenbankmanagementsystemen

In den 60er Jahren entstanden die ersten Datenbanksysteme im Sinne unserer Begriffsbildung. Diese unterstützten das sogenannte hierarchische Modell bzw. das Netzwerkmodell. Diese Modelle sind an die Datenstrukturen von kommerziellen Programmiersprachen angelehnt und basieren somit auf Zeigerstrukturen zwischen Datensätzen. Dem hierarchischen Datenmodell können hierbei Baumstrukturen zugeordnet werden, während das Netzwerkmodell allgemeinere Verknüpfungen zulässt.

Die Systeme dieser ersten Generation zeichneten sich durch eine schwache Trennung zwischen interner und konzeptueller Ebene aus, so dass die Art der internen Speicherung die Anwendungsprogrammierung beeinflusste. Die Datenmanipulationssprache war navigierend anhand der Zeigerstrukturen.

Die 70er und 80er Jahre waren geprägt durch die Entwicklung der relationalen Datenbanksysteme, die zurzeit den kommerziellen Markt beherrschen. Wie wir im folgenden Kapitel 2 noch sehen werden, werden Daten in Tabellenstrukturen verwaltet, wobei das Drei-Ebenen-Konzept eine Trennung der internen von der konzeptuellen Ebene erzwingt. Relationale DBMS unterstützen eine deklarative Datenmanipulationssprache, in der Regel SQL. Die Datenmanipulationssprache ist von der Programmiersprache der Anwendungsentwicklung separiert, so dass die Kopplung der beiden Sprachwelten zwangsweise zu Problemen führt.

Seit den (späten 80er und) 90er Jahren kann die relationale Datenbanktechnik als etabliert gelten. Aktuelle Entwicklungstendenzen sind daher auf die Berücksichtigung neuer Anforderungen gerichtet.

Hierzu zählt zum einen die Verwaltung komplex strukturierter Datenbestände. So waren Ende der 90er Jahre objektorientierte Datenbanksysteme eines der populärsten Schlagworte im Datenbankbereich. Derartige Systeme ermöglichen die Zusammenfassung von Daten in komplexeren Objektstrukturen und bieten so adäquate Strukturierungskonzepte. Sie unterstützen zum Teil deklarative oder navigierende DML, wobei die deklarativen Ansätze in kommerziellen Systemen nicht ausgereift waren. Daher boten sie eine integrierte Datenbankprogrammiersprache an – zunächst als Erweiterung von C++, später dann auf Basis von Java.

Inzwischen haben objektorientierte Konzepte als objektrelationale Erweiterungen auch Eingang in die SQL-Datenbanksysteme gefunden. Im Gegensatz zu den objektorientierten Datenbanksystemen werden Entwicklungen im Bereich dieser objektrelationalen Datenbanksysteme (ORDBMS) von den großen Datenbankherstellern vorangetrieben und haben den SQL:2003-Standard beeinflusst. Ein wichtige Rolle spielt dabei insbesondere die Verwaltung raumbezogener Daten oder Geodaten (engl. Spatial Data) zur Unterstützung von Geoinformationssystemen.

Auch die Verbreitung von XML hat großen Einfluss auf die Datenbankentwicklung. Neben Datenbanksystemen, die direkt XML-Dokumente verwalten können (sogenannte native XML-Datenbanksysteme), unterstützen einige der aktuellen kommerziellen DBMS auch die Speicherung und Verarbeitung von XML-Daten in Form spezieller Datentypen. Weiterhin sind XML-Konzepte auch in neuere Versionen des SQL-Standards eingeflossen (SQL:2003 bis SQL:2008: SQL/XML).

Zur Verarbeitung von kontinuierlich erzeugten Daten wurden in den letzten Jahren Datenstrommanagementsysteme vorgeschlagen. Hierbei handelt es sich um Systeme, die kontinuierliche Anfragen auf sogenannten Datenströmen verarbeiten können.

Schließlich besteht in vielen Szenarien die Aufgabe, verteilt vorliegende und auf unterschiedliche Weise strukturierte Daten zu verknüpfen. Eine der Herausforderungen in derartigen Daten- oder Informationsintegrationssystemen ist die Überwindung der Heterogenität – der unterschiedlichen Ausprägung auf System-, Datenmodell-, Schema- und Datenrepräsentationsebene.

Obwohl – oder gerade weil – SQL die dominierende Sprache der Datenbankwelt ist, werden unter dem Sammelbegriff NoSQL verstärkt Datenbanksysteme diskutiert und realisiert, die sich bewusst nicht als SQL-Systeme sehen. NoSQL steht dabei meist für Not only SQL, auch wenn das Kürzel zuerst für no SQL stand. Verbunden ist mit dem Begriff NoSQL einerseits die Kritik an dem strikten, stark formalisierten Datenmodell von SQL, das nur schwer flexible Ad-hoc-Nutzung zulässt und beispielsweise bei der Speicherung von Dokumenten oder Netzwerkgraphen eine umständliche Modellierung erfordert. Andererseits wird SQL auch für die umständliche Erweiterbarkeit der Datenbankfunktionalität kritisiert, etwa wenn man Graphenalgorithmen auf Netzwerkgraphen realisieren möchte.

Unter NoSQL werden unterschiedlichste Systeme subsumiert. Einige Systeme zeichnen sich durch ein einfaches, aber flexibles Datenmodell aus und verzichten auf eine volle Datenbanksprache im Sinne von SQL. Andere Systeme, etwa Dokumentenspeicher oder Graph-Datenbanken, haben ein ähnlich komplexes Datenmodell nutzen aber andere Sprachansätze. Auch die bereits erwähnten objektorientierten und XML-Datenbanken werden inzwischen als NoSQL-Systeme bezeichnet, obwohl es beide deutlich länger als den Begriff No- SQL gibt. Auch hier reagieren aber die Hersteller von relationalen Datenbanksystemen und die Standardisierer der relationalen Datenbanksprache SQL: Mit SQL:2016 gibt es erstmals die Möglichkeit, auch schwachstrukturierte Daten wie in NoSQL-Systemen zu verwalten.

1.2.3 Wann kommt was?

Wie finden sich die bisher nur kurz angerissenen Konzepte in diesem Buch wieder? Viele der diskutierten Aspekte werden im vorliegenden Buch ausführlich behandelt. Aspekte, die sich eher den internen Realisierungen zuordnen lassen, sind dem Buch „Datenbanken: Implementierungskonzepte“ von Saake, Sattler und Heuer [SSH11] (das sich einer Vorlesung „Datenbanken II“ zuordnen lässt) vorbehalten.

Die bereits angerissenen Themen können wie folgt den Kapiteln und Abschnitten des vorliegenden Buchs zugeordnet werden:

• Eine Einführung in das derzeit in der Praxis am häufigsten eingesetzte Datenbankmodell, das Relationenmodell, geben wir in Kapitel 2.

• Allgemeine Architekturfragen sind Inhalt von Kapitel 3.

• Die Frage der Datendefinition ist eng mit dem Konzept des Datenbankmodells verbunden. Diese Aufgabe gehört zu den wichtigsten Tätigkeiten beim Einsatz von DBMS und wird darum in diesem Buch sehr intensiv behandelt. Kapitel 4 führt die Grundlagen von Datenbankmodellen ein und stellt mit dem Entity-Relationship-Modell ein konkretes Modell für den Entwurf von Datenbanken vor. Die Kapitel 6, 7 und 9 diskutieren die Probleme des Datenbankentwurfs, wobei Kapitel 7 die theoretischen Grundlagen für den Entwurf relationaler Datenbanken liefert und Kapitel 9 diese dann später vertieft. Die Datendefinition für relationale Datenbanken wird in Kapitel 8 behandelt, weitere Datenbankmodelle sind Gegenstand des dritten Teils mit den Kapiteln 17 bis 22.

• Das Problem der Sichtdefinition wird in Kapitel 15 intensiver diskutiert. In den Kapiteln 13 und 16 werden des Weiteren Transaktionen, Integritätssicherung und Aspekte der Zugriffskontrolle behandelt.

• Sprachen für Anfragen und Änderungen sind naturgemäß ein wichtiger Aspekt. Die Datenbanksprache SQL wird in den Kapiteln 8 (relationaler Teil) und 11 (erweiterte Konzepte) vorgestellt. Formale Grundlagen sind Gegenstand von Kapitel 5 (speziell Relationenalgebra) bzw. 10 (Relationenkalküle und erweiterte Anfragemodelle), weitere Datenbanksprachen werden in Kapitel 12 behandelt.

• Der Bereich der Datenbankanwendungsprogrammierung wird in Kapitel 14 behandelt.

• Eine Reihe von Themen, die sich eher der Implementierung von DBMS zuordnen lassen, werden im vorliegenden Buch nicht behandelt, sondern sind einem anderen Buch der Autoren vorbehalten. Insbesondere die interne Dateiorganisation ist den „Datenbanken-Implementierungstechniken“ zugeordnet und wird in [SSH11] in den Kapiteln 5 und 6 ausführlich behandelt. Dies gilt ebenfalls für die Themenfelder Zugriff auf Speichermedien, Auswertung und Optimierung von Anfragen. Eine ausführliche Diskussion dieser Konzepte erfolgt in den Kapiteln 7 und 8 von [SSH11].

1.3 Beispielanwendung

In diesem Buch greifen wir größtenteils auf dasselbe Beispiel zurück, das einen kleinen Teil der Möglichkeiten einer Datenbankanwendung anhand einer kleinen Weinkellerverwaltung beschreiben soll. Unsere Anwendung umfasst folgende Objekttypen, zu denen Informationen in einem Datenbanksystem gespeichert werden3:

• Zu jedem Wein wollen wir folgende Eigenschaften verwalten: den Namen, die Farbe (rot, weiß, rosé), den Jahrgang sowie den Restzuckergehalt (die Restsüße).

• Ein Erzeuger ist ein Weinproduzent, von dem wir den Namen (das Weingut) und die Adresse bzw. die Region (wie das Napa Valley in Kalifornien, das Barossa Valley in Australien oder Saint Émilion in Frankreich) speichern.

• Das Anbaugebiet ist die geographische Region, in der ein Wein mit dem Namen der Region angebaut wird, so z.B. Bordeaux in Frankreich, Kalifornien oder der Rheingau in Deutschland. Demzufolge werden die Eigenschaften Name und Land benötigt.

• Eine Rebsorte ist durch den Namen und die Farbe gekennzeichnet, beispielsweise Zinfandel (rot), Riesling (weiß) oder Cabernet Sauvignon (rot).

• Ein Gericht ist eine Speise mit einem Namen (z.B. Rinderbraten, Kalbsleber) und einer Beilage wie Pommes Frites, Thüringer Klößen oder Risotto.

• Ein Kritiker ist ein Weinexperte, zu dem wir den Namen und die Organisation (Firma, Verlag usw.) verwalten.

Die genannten Objekttypen stehen miteinander in vielfältigen Beziehungen, die ebenfalls in der Datenbank verwaltet werden sollen:

• Ein Erzeuger produziert Weine, beispielsweise produziert das (fiktive) Weingut „Helena“ einen Zinfandel.

• Weiterhin ist ein Erzeuger in einem Anbaugebiet angesiedelt. So sitzt das Weingut „Helena“ im kalifornischen Napa Valley.

• Ein Wein wird aus einer oder mehreren Rebsorten hergestellt, etwa der kalifornische Opus One aus „Cabernet Sauvignon“, „Cabernet Franc“ und „Merlot“.

• Ein Weinkritiker empfiehlt einen Wein zu einem Gericht, z.B. einen bestimmten Bordeaux-Wein zu Rinderbraten.

Im Anhang A werden Darstellungen der modellierten Anwendungsdaten sowohl in einem abstrakteren Modell, dem Entity-Relationship-Modell, kurz ER-Modell (siehe Kapitel 7), als auch im Relationenmodell angegeben. Dort sind auch einige Beispieldaten aufgeführt. Für die verschiedenen Namen von Objekten, Beziehungen und Eigenschaften werden wir gegebenenfalls auch Abkürzungen verwenden, falls wir dies zur Darstellung aus Platzgründen benötigen.

Natürlich ist eine einzelne Beispielanwendung nicht für alle Problembereiche gleichermaßen zur Veranschaulichung geeignet, so dass wir in einigen Abschnitten kleinere Ergänzungen, Vereinfachungen oder Änderungen vornehmen, wenn damit die jeweiligen Konzepte besser verdeutlicht werden können.

1.4 Vertiefende Literatur

Die Grundkonzepte von Datenbanksystemen sind in vielen Lehrbüchern aufbereitet, die wir an dieser Stelle nicht alle explizit aufzählen wollen. Stellvertretend seien hier nur einige der Klassiker erwähnt: es sind die Bücher Garcia- Molina, Ullman und Widom [GUW09], Elmasri und Navathe [EN17], Silberschatz, Korth und Sudarshan [SKS10], Ramakrishnan und Gehrke [RG03], Kemper [Kem15] und Maier [Mai83]. Vertiefende Literatur zu den einzelnen Themenkomplexen werden in den einzelnen Abschnitten angegeben. Auch die historische Entwicklung wird zum Teil in diesen Lehrbüchern abgehandelt und spiegelt sich in den wechselnden Themenschwerpunkten der großen Datenbanktagungen und -zeitschriften wider.

Die Standardisierung der Drei-Ebenen-Architektur und der verschiedenen Datenbanksprachen durch ANSI-SPARC kann in [TK78, Dat86a] oder [LD87] nachgelesen werden. Die neun Aufgaben eines Datenbanksystems – die Codd’schen Regeln – wurden von Codd in [Cod82] definiert.

1.5 Übungsaufgaben

Übung 1-1 Vergleichen Sie die Dateiverwaltung eines Betriebssystems, etwa ein Dateisystem von UNIX/Linux oder einer neueren Windows-Version, mit einem Datenbankmanagementsystem! Welche Funktionalität stimmt überein, wo liegen die Unterschiede?

Übung 1-2 Überlegen Sie sich umgangssprachlich formulierte Anfragen und Änderungsoperationen, die Ihrer Meinung nach in einer Bibliotheksanwendung häufig anfallen.

2

Relationale Datenbanken – Daten in Tabellen

Relationale Datenbanken sind die dominierende Form der strukturierten Datenhaltung in aktuellen Anwendungssystemen. Viele Themen dieses Buches beziehen sich auf Modelle, Theorie und Sprachen für relationale Datenbanken. Dieses Kapitel gibt einen kurzen Überblick über Kernkonzepte derartiger Datenbanken, um den Einstieg in die einzelnen vertiefenden Themenblöcke zu vereinfachen, indem der Leser bereits das große Gesamtbild vor Augen haben kann.

2.1 Relationen für tabellarische Daten

Im täglichen Leben liegen viele Daten in Tabellen vor – seien es Spielergebnisse einer Bundesliga, Kontoauszüge oder Prüfungseinschreibungslisten. Daher liegt es nahe, sich zu überlegen, ob Tabellen als universelle Datenbankstruktur gut geeignet sind. Tatsächlich gilt dies für die meisten Daten, insbesondere für Daten, die kommerziellen Anwendungen zugrunde liegen und dort automatisch verarbeitet werden müssen.

Das relationale Datenbankmodell setzt nun genau diese Idee um: eine Datenbank ist hier eine Menge von Tabellen. Mathematisch kann man Tabellen als Darstellung von Relationen auffassen – daher die Namensgebung.

Abbildung 2.1 zeigt zwei Tabellen, die Daten aus unserer Beispielanwendung beinhalten. Eine Tabelle enthält Zeilen, die jeweils Informationen über einen Wein zusammenfassen. In der zweiten Tabelle werden Informationen über Weingüter, die diese Weine herstellen, gespeichert.

Abbildung 2.1: Relationen über Weine und deren Erzeuger

Im Gegensatz zu Datensätzen, die in üblichen Programmiersprachen verarbeitet werden, sind in dieser tabellarischen Speicherung keine Referenzen möglich. Will man also wissen, in welcher Region ein Wein hergestellt wurde, muss man in der Tabelle WEINE den Namen des Weinguts nehmen, um in der zweiten Tabelle ERZEUGER die Region nachschlagen zu können.

2.1.1 Begriffe im Relationenmodell

Basierend auf den Beispieltabellen aus Abbildung 2.1 können wir nun die grundlegenden Begriffe der tabellarischen Datenhaltung einführen. Abbildung 2.2 verdeutlicht die Nutzung dieser Begriffe anhand der visuellen Darstellung.

• Eine gespeicherte Tabelle wird als Relation bezeichnet. Der Relationenname steht der tabellarischen Darstellung voran. Die Begriffe Relationenname und Relation werden oft synonym genutzt. Ein Beispiel für einen Relationennamen ist ERZEUGER aus Abbildung 2.1.

• Der „Tabellenkopf“ legt die Anzahl, Bezeichnung und Typisierung der Spalten fest. Er wird als Relationenschema bezeichnet.

• Eine Spaltenüberschrift im Tabellenkopf legt ein Attribut fest. Gezeigt wird hierbei der Attributname, weitere Festlegungen wie der Datentyp etc. werden in der graphischen Darstellung oft ausgeblendet. Ein Beispiel für ein Attribut ist Weingut in der Tabelle ERZEUGER.

Abbildung 2.2: Begriffe bei tabellarische Daten

• Eine Zeile der Tabelle bezeichnen wir als Tupel.

•  Die Menge aller Einträge, also aller gespeicherten Tupel, bildet die Relation an sich.

• Ein Eintrag in ein Feld eines Tupels ist ein konkreter Attributwert. Ein Beispiel für einen Attributwert des Attributs Weingut in der Tabelle ERZEUGER ist ‘Creek’.

Wir hatten ja bereits erwähnt, dass es in relationalen Datenbanken keine Referenzen auf Datenobjekte gibt. Wir müssen daher einen anderen Weg finden, um Verbindungen zwischen Datenobjekten eindeutig zu halten. Diesem Zwecke dienen spezielle Integritätsbedingungen, die wir im Folgenden einführen werden.

2.1.2 Integritätsbedingungen: Schlüssel

Die erste von uns eingefügte Integritätsbedingung ist die Schlüsselbedingung. Die Schlüsselbedingung besagt, dass die Attributwerte einer Spalte die gespeicherten Tupel eindeutig identifizieren. Diese Eigenschaft bezeichnen wir als Schlüsseleigenschaft.

In unserem Beispiel gilt, dass die Weingut-Werte in der Tabelle ERZEUGER diese Eigenschaft haben. Schlüsselattribute können in der graphischen Darstellung durch Unterstreichen gekennzeichnet werden, wie in Abbildung 2.3 gezeigt.

Abbildung 2.3: Relation mit Schlüsselattribut

Auch Attributkombinationen können Schlüssel sein, etwa in einer Datenbank über Personen die Kombination aus Name, Vorname und Geburtsdatum. Für eine Tabelle kann es mehrere mögliche Schlüssel geben, etwa die Personalausweisnummer und die Matrikelnummer in einer Studierendenverwaltung für eine Tabelle STUDIERENDE. Hier wird dann ein Schlüssel als Primärschlüssel ausgewählt; nur dieser Schlüssel wird durch Unterstreichen visualisiert, um die Darstellung eindeutig zu halten.

Beide eben genannten Beispiele zeigen übrigens, dass die Festlegung der Schlüssel oft eine Entwurfsentscheidung ist, und nicht aus der Realität abgeleitet werden kann.

2.1.3 Integritätsbedingungen: Fremdschlüssel

Mit der Einführung der Schlüsselbedingung haben wir nun die Möglichkeit, Einträge in einer gespeicherten Tabelle eindeutig zu identifizieren. Mit anderen Worten, die Schlüsselwerte einer Tabelle können in einer anderen (oder derselben!) Tabelle als eindeutige Verweise genutzt werden.

Derartige Verweise bezeichnen wir als Fremdschlüssel. Wir fordern weiterhin, dass diese Verweise nicht „ins Leere führen“, also tatsächlich zu einem gespeicherten Datenobjekt gehören. Diese Eigenschaft bezeichnen wir als referentielle Integrität.

In unseren Beispiel dienen die Weingut-Werte in Tabelle WEINE als Verweise auf Tupel der ERZEUGER-Tabelle. Die Abbildung 2.4 verdeutlicht dies.

In unserem Beispiel wird die referentielle Integrität durch die Angabe Weingut → ERZEUGER im Tabellenkopf ausgedrückt. Eine andere, verbreitete Visualisierung ist die Verbindung zweier Attribute in zwei Tabellen mit einem Pfeil. Die Bedingung ist nun, dass jeder in der Tabelle WEINE auftauchende Weingut-Wert tatsächlich in der Tabelle ERZEUGER als Schlüsselwert eines Tupels auftritt. Die Schlüsselbedingung in der Tabelle ERZEUGER gewährleistet nun, dass es sich wirklich um eine eindeutige Referenz handelt.

Wie kommt nun die merkwürdige Bezeichnung Fremdschlüssel zustande? Es handelt sich ja bei Weingut in der Tabelle WEINE gerade nicht um einen Schlüssel, da es ja mehrere Weine zu einem Weingut gibt. Die Bezeichnung kommt nun daher, dass ein Fremdschlüssel ein Schlüssel in einer „fremden“ Tabelle sein muss.

Abbildung 2.4: Beispiel für referentielle Integrität

2.2 Datendefinition in SQL

SQL ist das „intergalactic data speak“ der relationalen Datenbanken. SQL ist bewusst so entworfen worden, dass es Befehlssätzen der englischen Sprache nachempfunden wurde — ursprünglich stand das erste Sprachkürzel SEQUEL für „structured english query language“.

Wir haben bereits das relationale Datenbankmodell kennengelernt, und können uns nun ansehen, wie Tabellen in SQL definiert werden. Diesen Teil von SQL nennt man Datendefinitionssprache (kurz DDL für „data definition language“).

Die Anweisung create table beginnt der Sprachphilosophie von SQL konsequenterweise mit den Befehlsworten „create table“ als englischsprachiger Anweisung. Danach folgt eine klassische Strukturdeklaration analog zu einer Programmiersprache:

Die Wirkung dieses Kommandos ist sowohl die Ablage des Relationenschemas im Data Dictionary als auch die Vorbereitung einer „leeren Basisrelation“ in der Datenbank.

Tabellen können nicht nur angelegt werden, sondern auch wieder entfernt werden. Das Löschen einer Tabelle erfolgt mittels der Anweisung drop table.

Der Effekt ist das komplette Löschen einer Tabelle — sowohl der Inhalt der Tabelle als auch der Eintrag im Data Dictionary wird gelöscht:

Bevor wir uns die Deklaration einer Tabelle am Beispiel ansehen, werden wir kurz die möglichen Wertebereiche für Attributwerte in SQL diskutieren.

2.2.1 Mögliche Wertebereiche in SQL

Relationale Datenbanken und somit auch SQL wurden ursprünglich für finanzielle und betriebswirtschaftliche Anwendungen entwickelt – numerische Werte, Geldwerte, Datumsangaben und Zeichenketten sind daher zentrale Wertebereiche für Tabellen. Wir werden später eine umfangreiche Liste der Wertebereiche in SQL vorstellen – für unser kleines Weinhandelsbeispiel benötigen wir nur die folgenden:

• integer (oder auch integer4, int) für ganze Zahlen, sowie

• character varying(n) (oder kurz varchar(n)) für Zeichenketten variabler Länge bis zur Maximallänge n.

2.2.2 Beispiele für die Datendeklaration

Als einfaches Beispiel für create table betrachten wir die Deklaration der Tabelle WEINE:

Neben dem Einsatz der Definition von Wertebereichen für Attribute zeigt unser Beispiel die Definition einer Schlüsselbedingung. Die Angabe primary key kennzeichnet die Spalte WeinID als Schlüsselattribut der Tabelle WEINE.

Nicht nur Schlüsselbedingungen können deklariert werden, sondern auch Fremdschlüsselbedingungen. Das folgende Beispiel der Deklaration der Tabelle WEINE zeigt ein create table mit Angabe eines Fremdschlüssels.

Die Angabe foreign key kennzeichnet die Spalte Weingut als Fremdschlüssel. Dabei muss die „Zieltabelle“ der Referenzierung explizit angegeben werden.

2.2.3 Nullwerte

Eine Angabe bei der Tabellendeklaration haben wir bisher nicht erläutert. Die Angabe not null schließt in bestimmten Spalten sogenannte Nullwerte als Attributwerte aus. Ein Nullwert heißt soviel wie „nicht bekannt“ oder „nicht zutreffend“, und zeigt einen fehlenden Wert an. Nullwert kommt dabei nicht von der (deutschen) Null, sondern von dem englischen Wort null und bezeichnet also nicht die Zahl 0 (englisch „zero“). In unserem Beispiel muss jeder Wein einen Namen haben, während Farbe und Jahrgang nicht unbedingt angegeben sein müssen.

Die Kennzeichnung von Nullwerten erfolgt in SQL durch das Schlüsselwort null; in theoretischen Beispielen wird eher die mathematische Notation ⊥ genutzt. Die Angabe null repräsentiert die Bedeutung „Wert unbekannt“, „Wert nicht anwendbar“ oder „Wert existiert nicht“, gehört aber zu keinem Wertebereich. Die Angabe null kann in allen Spalten auftauchen, außer in Schlüsselattributen und den mit not null gekennzeichneten Spalten.

2.3 Grundoperationen: Die Relationenalgebra

Nachdem wir nun Tabellen als Datenstruktur für Datenbankinhalte kennengelernt haben, wenden wir uns nun den Möglichkeiten zu, aus Datenbanken Informationen zu extrahieren. Hierzu betrachten wir zuerst Basisoperationen auf Tabellen, die die Berechnung von neuen Ergebnistabellen aus gespeicherten Datenbanktabellen erlauben. Diese Operationen werden zur sogenannten Relationenalgebra zusammengefasst.

In der Mathematik ist eine Algebra definiert durch einen Wertebereich sowie darauf definierten Operationen. Bei Datenbankanfragen entsprechen die Tabellen der Datenbank den Werten, die Operationen sind dann Funktionen zum Berechnen der Anfrageergebnisse. Da alle Operationen als Eingabe jeweils Tabellen haben und als Ergebnis eine neue Tabelle berechnen, sind diese Operationen beliebig kombinierbar (und erlauben durch Schachtelung komplexe Anfragen).

Die theoretischen Grundlagen von Tabellen sind Relationen, also Mengen von Tupeln mit benannten Attributen. Einige Operationen sind daher naheliegend: Wir können die üblichen Mengenoperationen auf Mengen von Tupeln anwenden, etwa die Vereinigungsmenge oder Schnittmenge bilden, und können Attribute umbenennen. Dies reicht natürlich nicht aus, um beliebige Anfragen umzusetzen.

Erstaunlicherweise reichen drei weitere Operationen aus, um die meisten Anfragen zu realisieren: die Projektion, die Selektion und der Verbund. Zusammen mit den genannten einfachen Mengenoperationen und der Umbenennung von Spalten konstituieren diese Operationen die Relationenalgebra.

Abbildung 2.5: Projektion, Selektion und Verbund

Abbildung 2.5 verdeutlicht die Bedeutung der drei neuen Operationen: Die Projektion wählt Spalten aus, die Selektion als Gegenstück dazu Tupel, und der Verbund verschmilzt die Tupel zweier Relationen basierend auf übereinstimmenden Werten gleichbenannter Spalten. Wir werden nun alle genannten Operationen an Beispielen erläutern.

2.3.1 Selektion σ

Als erste Operation betrachten wir die Selektion. Als Operationssymbol dient der kleine griechische Buchstabe Sigma, also σ. Die Selektion dient der Auswahl von Zeilen einer Tabelle anhand eines Selektionsprädikats. Das Selektionsprädikat wird dabei rechts unten am Operatorsymbol notiert. Ein Beispiel ist die folgende Anwendung der Selektion, die Weine mit Jahrgängen größer 2015 selektiert.

Abbildung 2.6 zeigt das Ergebnis dieser Selektion.

Als Selektionsprädikate treten üblicherweise einfache Bedingungen auf, also Vergleiche von Attributwerten mit Konstanten, beziehungsweise auch der Vergleich zweier Attribute (etwa der Vergleich eines Herstellungsdatums mit dem Verkaufsdatum).

Abbildung 2.6: Ergebnis einer Selektion

2.3.2 Projektion π

Die Projektion dient der Auswahl von Spalten durch Angabe einer Attributliste. Als Operationssymbol wird der kleine griechische Buchstabe Pi genutzt, also π. Die Attributliste wird wieder rechts unten am Operatorsymbol notiert, wobei die Attributnamen durch Kommata separiert werden.

Als Bespiel betrachten wir die Auswahl einer einzelnen Spalte Region aus der ERZEUGER-Tabelle:

In Abbildung 2.6 ist das Ergebnis dieser Projektion abgebildet.

Abbildung 2.7: Ergebnis einer Projektion

Da es sich bei Relationen um Mengen von Tupeln handelt, entfernt die Projektion ansonsten doppelte Tupel automatisch.

2.3.3 Natürlicher Verbund

Der Verbund (engl. join) verknüpft Tabellen über gleichbenannte Spalten, indem er jeweils zwei Tupel verschmilzt, falls sie dort gleiche Werte aufweisen. Als Operatorsymbol wird das Symbol genutzt. Wir bezeichnen diesen Verbund als natürlichen Verbund, da es natürlich erscheint, gleichbenannte Spalten zur Verknüpfung heranzuziehen, da gleichbenannte Spalten in der Regel dieselbe Bedeutung haben. Natürlich gilt Letzteres nicht immer – man denke an Namen von Personen und an Namen von Produkten.

Als Beispiel für den natürlichen Verbund betrachten wir den folgenden Ausdruck der Relationenalgebra:

In Abbildung 2.8 ist das Ergebnis der Verbundberechnung abgebildet. Wir haben einige Attribute von WEIN durch Pünktchen nur angedeutet, da die Tabelle sonst zu breit geworden wäre.

Abbildung 2.8: Ergebnis eines Verbunds

Zur Verbundberechnung werden die Werte in der Spalte Weingut herangezogen, die in beiden Eingabetabellen gleichbenannt ist. Zwei Tupel werden verschmolzen, wenn die Werte in dieser Spalte übereinstimmen.

Im Ergebnis des Beispiel-Verbunds taucht jeder Wein nur einmal auf – dies liegt daran, dass das gemeinsame Attribut Weingut in ERZEUGER ein Schlüssel ist. Das Weingut „Château La Pointe“ ist im Ergebnis verschwunden da Tupel, die keinen Partner finden (sogenannte dangling tuples), nicht im Ergebnis aufgenommen werden. Umgekehrt kann kein WEIN verschwinden, da die Fremdschlüsselbedingung in diesem Fall dafür sorgt, dass ein passender ERZEUGER existiert.

Das folgende Beispiel zeigt dass die Operatoren kombiniert werden können, um komplexe Anfragen formulieren zu können.

Das Ergebnis dieser Anfrage ist in Abbildung 2.9 abgebildet.

Abbildung 2.9: Ergebnis eines komplexen Algebraausdrucks

2.3.4 Umbenennung ß

Die Anpassung von Attributnamen erfolgt mittels des Umbenennung-Operators. Wieder wird ein griechischer Buchstabe als Operatorsymbol genutzt, hier nun der kleine griechische Buchstabe Beta, also ß.

Abbildung 2.10 zeigt zwei Tabellen, die derart angeglichen werden sollen, dass beide denselben Attributnamen für ihre eine Spalte haben.

Abbildung 2.10: Zwei durch Umbenennung anzugleichende Tabellen

Das Angleichen kann nun wie folgt geschehen:

Dieses Beispiel zeigt auch die Syntax der Angabe des alten und des neuen Attributnamens.

2.3.5 Mengenoperationen

Die Mengenoperationen Vereinigung, Differenz und Durchschnitt sind die aus der Schulmathematik bekannten Operationen. Wir werden die drei Operationen der Reihe nach kurz vorstellen.

Die Vereinigungr1 ∪ r2 von zwei Relationen r1 und r2 ergibt die Gesamtheit der beiden Tupelmengen. Eine Vereinigung kann nur erfolgen, wenn die Attributmengen beider Relationen identisch sind.

Als Beispiel vereinigen wir die beiden durch Umbenennung angeglichenen Tabellen aus Abbildung 2.10.

Abbildung 2.11 zeigt links das Ergebnis dieser Beispielanfrage.

Die Differenzr1 – r2 eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen. Wir nutzen das selbe Beispiel für eine illustrierende Anfrage:

Abbildung 2.11: Ergebnisse von Vereinigung, Differenz und Schnittmenge

In der Abbildung 2.11 ist das Ergebnis dieser Beispielanfrage in der Mitte zu sehen.

Der Durchschnittr1 ∩ r2 als dritte Mengenoperation ergibt die Tupel, die in beiden Relationen gemeinsam vorkommen:

In der Abbildung 2.11 ist das Ergebnis dieser Beispielanfrage rechts zu sehen.

2.4 Qualität entworfener Tabellen

Relationale Tabellen lassen sich leicht definieren – man muss ja nur einfach die Attribute einer Tabelle auflisten. Nicht alle definierten Tabellen sind dabei von gleicher Qualität. In diesem Abschnitt werden wir anhand einfacher Beispiele motivieren, welche Qualitätsdefizite bei relationalen Tabellen auftreten, und mit welchem formalen Methoden wir diese Defizite erkennen und beseitigen können.

Die Qualitätsmaße für Tabellen sind dabei als Normalformen