A RS - of the AG Database-Systems

Datenbanksysteme 

Bernhard Seeger 

Fachbereich Mathematik und Informatik 

Philipps-Universität Marburg 

Email: seeger@informatik.uni-marburg.de 

Tel.: 06421-28 21526 

Dieses “Skript” ist nur als eine Orientierungshilfe zur Vorlesung Datenbanksysteme. Die Kopien 

entsprechen zu einem großen Teil den Folien, die in den Vorlesungsstunden aufgelegt und erläutert 

werden. 

Seite 1

Organisation 

� Vorlesung 

– Mi. 12:00-14:00 HG 007, Fr. 8:00-10:00 HG 007 

� Übung 

– Übungsleiter: Daniar Achakeyev 

– Übungsblätter 

– Ausgabe des Übungsblatts: in der Vorlesung am Freitag 

– Abgabe der Übungen in der kommenden Vorlesung am Freitag 

– Korrektur der Aufgaben 

– Übungstermine: Di 14-16 und Di 16-18 jeweils im HS I 

� Benoteter Schein: 

– 50% der Übungsaufgaben + Klausur 

– Note des Moduls = Note der Klausur 

� Web-Seite: 

– http://dbs.mathematik.uni-marburg.de/teaching/vl/DBS1/09SS/ 

Seite 2

Basisliteratur 

Literaturliste 

� A. Kemper, A. Eikler: “Datenbanksysteme. Eine Einführung”, Oldenbourg, 2008 (6. Auflage). 

� G. Saake, A. Heuer: “Datenbanken Konzepte und Sprachen”, mitp. 2008. 

� G. Vossen: “Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme”, 

Oldenbourg, 2008. 

� Jeffrey D. Ullman, Jennifer D. Widom: A First Course in Database Systems, Prentice Hall, 

2001. 

� Ramez A. Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen, Pearson 

Studium 2005. 

� Gunter Saake, Kai-Uwe Sattler: "Datenbanken und Java. JDBC, SQLJ und ODMG", dpunkt 

Verlag, 2003. 

Spezialliteratur 

� Gerhard Weikum, Gottfried Vossen: Transactional Information Systems: Theory, Algorithms, 

and the Practice of Concurrency Control, Morgan Kaufmann, 2001. 

� Serge Abiteboul, Richard Hull, Victor Vianu: Foundations of Database Systems, Addison- 

Wesley, 1995. 

Seite 3

Wichtige Zeitschriften und Konferenzen 

Zeitschriften: 

� ACM Transactions on Database Systems (TODS) 

� The VLDB Journal 

� IEEE Transactions on Knowledge and Database Engineering (TKDE) 

� Information Systems 

Wichtige Konferenzen: 

� Int. Conf. on Very Large Data Bases (VLDB) 

� ACM SIGMOD Int. Conf. on Management of Data (SIGMOD) 

� ACM SIGACT-SIGMOD Principles of Database Systems (PODS) 

� IEEE Int. Conf. on Data Engineering (ICDE) 

� Int. Conf. on Extending Database Technology (EDBT) 

Seite 4

Vorläufiges Inhaltsverzeichnis 

1. Einführung 

2. Konzeptioneller Datenbankentwurf 

3. Relationales Modell 

Relationale Algebra, Tupelkalkül, Erweiterte Relationale Algebra 

4. SQL: Die relationale Datenbanksprache 

5. Anwendungsprogrammierung 

6. Entwurfstheorie 

7. Transaktionskonzepte u. Fehlerbehandlung 

8. Indexstrukturen 

9. Anfrageverarbeitung 

10.Data Warehouse 

Seite 5

1. Einführung 

Einführung 

� Datenbanksysteme (DBS) werden genutzt zur rechnergestützten Verwaltung großer 

Datenbestände, die auf nichtflüchtigen Speichermedien abgelegt werden. 

– Daten liegen i. A. auf großen Magnetplattenspeicher 

� Datenbanksystem besteht aus 

– Datenbankverwaltungssystem (engl. database management system, DBMS) 

Dahinter verbirgt sich die Software zur Verwaltung von Daten. 

– Datenbank 

Darunter versteht man die zu verwaltenden Daten und andere Hilfsdaten (z. B. Indexe und 

Metadaten). Eine Datenbank stellt eine logische Einheit dar. 

Benutzer 

Dateneingabe 

Anfragen Antworten 

Database Management System (DBMS) 

Datenbank 

Seite 6

Anwendungen von Datenbanksystemen 

� Implementierung anwendungsspezifischer Informationssysteme durch Datenbanksysteme 

– Beispiel: SAP 

� Klassische Anwendungen 

– Bankinformationssystem: 

Verwaltung der Kunden, ihre Konten, … 

– Versicherungsinformationssystem: 

Verwaltung der Kunden, ihre Verträge, … 

� Neuartige Anwendungen 

– Biologie: 

Gen-Datenbanken 

– Geo-Datenbanken 

Kataster, Leitungsnetzwerke wie z. B. bei Energieversorger 

– Content-Managementsysteme 

Text-Dokumente wie z. B. Artikel, Zeitschriften, Bücher 

– Multimedia-Informationssysteme: 

Bilder, Videos 

Einführung 

Seite 7

Einführung 

Als es noch keine Datenbanksysteme gab, … 

� Entwicklung von DBS setzte erst in den frühen 60er Jahre ein. Zuvor wurden vornehmlich 

einfache Dateisysteme benutzt. 

Beispiel für die Datenverarbeitung in einer Versicherung: 

� Drei Kundenberater Alfred, Beatrice und Carlo, die je nach Art des 

Versicherungstyps Kunden betreuen. 

� Jeder der Kundenberater benutzt für den Zugriff auf die 

Kundendaten ein eigenentwickeltes Programm 

� Jeder Berater hat seine eigene Kundendatei 

KB Alfred 

KB Beatrice 

KB Carlo 

Programm 

KundenVonA 

Programm 

KundenVonB 

Programm 

KundenVonC 

Seite 8

Anwendungsprogramme 

� Anwendungsprogramm (AWP) 

– Ein Programm, das direkt durch den Benutzer oder eine spezifische 

Anwendungskomponente aufgerufen wird. 

� Beispiel (statt wie früher üblich Cobol oder PL1 benutzen wir Java) 

import java.io.*; 

class Anfrage1 { 

public static void main(String[] args) throws IOException { 

int index = Integer.parseInt(args[0]); 

float tmp, limit = Integer.parseFloat(args[1]); 

} 

} 

Einführung 

RandomAccessFile raf = new RandomAccessFile("feld.myf", "r"); 

while (index*4 < raf.length()) { 

raf.seek(index * 4); 

index++; 

tmp = raf.readFloat(); 

if (tmp > limit) 

System.out.println(raf.readFloat()); 

raf.close(); 

Seite 9

Probleme der frühen Datenverarbeitung 

Einführung 

� Direkte Erzeugung und Verarbeitung der Daten erfolgte im AWP unter Verwendung von 

Dateien 

– kein standardisiertes Speicherungsformat 

– hoher Aufwand beim Austausch von Daten verschiedener Benutzern 

– mehrfache und unkoordinierte Verwaltung der Daten 

– häufige Inkonsistenzen im Datenbestand 

– hoher Aufwand bei der Verknüpfung von Daten aus mehreren Dateien 

� Zugriff auf Daten erfolgt explizit im AWP 

– hoher Aufwand für die Entwicklung einer großen Anzahl maßgeschneiderter, aber auch 

unflexibler Programme 

– Programmcode zur Optimierung des Datenzugriffs durch den Anwender 

� Dateninkonsistenzen bei gleichzeitigem Zugriff durch mehrere Benutzer 

� Unzureichende Möglichkeiten beim Datenschutz 

Seite 10

Anforderungen an ein Datenbanksystem 

Gemeinsame Datenbasis und Mehrbenutzerbetrieb 

� Gemeinsam genutzte, persistente Datenbasis auf dem Externspeicher 

– Zugriff der Benutzer und der AWP auf einen gemeinsam verwalteten Datenbestand 

� Kontrollierte Datenredundanz 

– Vermeidung von Kopien derselben Daten durch integrierte Verwaltung aller Daten. 

� Mehrbenutzerbetrieb 

– Gleichzeitiger Zugriff mehrerer Benutzer auf ihre Daten 

– Virtuelles Einbenutzersystem 

Korrektheit und Qualität der Daten 

Einführung 

� Datenintegrität 

– Unterstützung von Integritätsbedingungen zur Gewährleistung der Korrektheit und 

Vollständigkeit der Daten 

– Automatische Überprüfung der Bedingungen beim Einfügen, Ändern und Löschen der 

Daten 

Seite 11

Einführung 

� Datenkonsistenz 

– Automatische Sicherstellung der Datenkonsistenz auf Basis der Integritätsbedingungen 

� Datenschutz 

– Zugriffskontrolle durch Authentisierung und Verschlüsselung 

– Schutz der Datenbank vor nicht-autorisierten Zugriff 

� Fehlerbehandlung 

– Schutz vor den Auswirkungen von Systemfehlern 

– Wiederanlauf des Systems (Recovery): automatisches Wiederherstellen des zuletzt 

aktuellen, konsistenten Datenbankzustands mittels von Log-Dateien 

– Anlegen von Sicherungskopien für den Fall der Zerstörung eines Speichermediums 

Softwareentwicklung mit DBMS 

� Schnelle Entwicklung von neuen Anwendungen 

– unter Ausnutzung einer mächtigen Infrastruktur 

� Flexible und schnelle Anpassung von Programmen bei Änderungen im Datenbestand 

– Verteilung der Daten über mehrere Platten 

– Änderung der Speicherorganisation 

– Änderung des Typs der Daten 

Seite 12

� Bereitsstellung verschiedener Benutzerschnittstellen 

– Ad-hoc Anfragesprachen für interaktive Benutzer 

– Programmierschnittstellen für die Erstellung von AWP 

– Menügesteuerte, einfach zu benutzende Schnittstelle (GUI) 

– Spezieller Zugang für Administrator (z. B. zur Datendefinition) 

Performanz 

Einführung 

� Schneller Datenzugriff 

– Mächtige Sammlung von Werkzeugen zur effizienten Speicherung und 

Anfrageverarbeitung externer Datenquellen. 

– Indexstrukturen für große Datenmengen, die auf dem Plattenspeicher verwaltet werden. 

– Effiziente Algorithmen zum Sortieren großer Datenmengen 

� Effektive Anfragebearbeitung 

– Übersetzung und Optimierung von Anfragen 

– Anfrageoptimierung mit dem Ziel eines hohen Durchsatzes (Anfragen/Sekunde) 

Seite 13

Nach einer Umstrukturierung ... 

� Zugriff auf die Datenbank nur über ein DBMS 

� Es gibt nur einen zentralen Datenbestand 

– (eigentlichen) Daten 

– Metadaten (Daten über die Daten) 

– Funktionen 

Alfred Carlo Beatrice 

DBMS 

DB 

Einführung 

Seite 14

Datenabstraktion 

DBS besitzt mehrere Abstraktionsstufen: 

� Externe Ebenen: beschreiben den Teil der DB, der für 

einen Benutzer (oder eine Benutzergruppe) relevant ist. 

� Konzeptionelle Ebene gibt an, welche Daten und 

welche Beziehungen in der DB vorhanden sind 

� Physisches Ebene beschreibt, wie die Daten 

physisch abgelegt sind (physisches Datenmodell) 

Datenbankschema 

� Enwurf der Datebank bzgl. der drei Ebenen: 

– externe Schemata 

– ein konzeptionelle Schema 

– ein physisches Schema. 

� AWP greifen über ein externes Schema auf die Daten eines DBS zu. 

Datenbankzustand 

� Konkrete Instanz, die dem Datenbankschema folgt. 

AWP 

externe 

Ebenen 

konzeptionelle 

Ebene 

physische 

Ebene 

Einführung 

Seite 15

Datenunabhängigkeit 

Einführung 

� bezeichnet die Eigenschaft, das Schema in einer Ebene zu ändern, ohne dabei das Schema der 

Daten in der darüber liegenden Ebene zu beeinflussen. 

� Logische Datenunabhängigkeit: 

– Änderungen an der konzeptionellen Ebene haben keine 

Auswirkungen auf die externe Ebene und damit auch 

nicht auf die AWP. 

– Beispiel: 

Daten bei der Kontoführung sollen um das Attribut 

“Uhrzeit” erweitert werden. 

� Physische Datenunabhängigkeit: 

– Änderungen an der physischen Ebene haben keine 

Auswirkungen auf die konzeptionelle Ebene und 

damit auch nicht auf die externe Ebenen und die AWP. 

– Beispiele: 

Der Datenbestand “Kontoführung” soll statt in einer 

Datei auf mehrere Dateien verteilt gespeichert werden. 

AWP 

externe 

Ebenen 

konzeptionelle 

Ebene 

physische 

Ebene 

Der Algorithmus für das externe Sortieren wird neu implementiert. 

Ein Suchbaum soll aufgebaut werden, um schneller Anfragen zu beantworten. 

Seite 16

Datenmodelle 

� Ein Datenmodell ist ein Formalismus zur Beschreibung und Definition 

– von Daten 

– und von Operationen zur Datenmanipulation. 

Dies beinhaltet nicht nur die Syntax, sondern insbesondere auch die Semantik! 

� Typischerweise besitzt ein DBS zumindest zwei Datenmodelle: 

– physisches Datenmodell: zur speicher-orientierten Repräsentation der Daten 

– logisches Datenmodell: zur benutzer-orientierten Repräsentation der Daten 

� logische Datenmodelle sind 

– objekt-orientiert, z. B. 

Entity-Relationship Modell 

objektorientiertes Modell 

– satz-orientiert, z. B. 

relationales Datenmodell 

Netzwerk-Datenmodel 

hierarchisches Datenmodell 

Einführung 

Seite 17

Sprachen in DBS 

Datendefinitionssprache (DDL = data definition language) 

� Sprache zur Manipulation des Datenbankschemas 

� Verwaltung von Meta-Daten zur Beschreibung des Schemas (data dictionary) 

� Spezifikation von “lästigen” Implementierungsdetails 

Datenmanipulationssprache (DML = data manipulation language) 

Einführung 

� Funktionalität: 

– Einfügen, Löschen und Ändern von Datenobjekten in (aus) der Datenbank 

– Suche nach Datenobjekten in der Datenbank 

� Anfragesprachen sind i.a. deklarativ 

– Benutzer spezifiziert nur, was für Daten gesucht werden, aber nicht wie die Daten 

gefunden werden sollen. 

� Herausforderung 

– Anfrage, die ein Benutzer auf seiner externen Ebene deklarativ formuliert hat, wird in 

eine effiziente, imperative Anfrage übersetzt, die auf Objekte der physischen Ebene 

aufsetzt. 

Seite 18

naiver 

Benutzer 

Code des 

Anwenderprogramms 

Komponenten eines DBMS 

Anwendungsprogrammierer 

Precompiler 

der DML 

Dateisystem 

Dateien Dateien Daten- 

Dictionary 

Compiler 

der DML 

ad-hoc 

Anfrager 

Datenbank 

Manager 

Datenbankadministrator 

Compiler der 

Datendefinitionssprache 

Einführung 

Seite 19

Probleme heutiger Datenbanken 

� Neue Formen der Datenerfassung 

– Sensoren 

– Ticker 

– Anbindung von Web-Datenquellen 

� Dadurch ergeben sich sehr große und ständig wachsende Datenbanken 

– AT&T (2005) 

Größe 

• 330 TByte 

• 1,8 Billionen Elemente 

– UPS (2005) 

Systemlast (Maximum) 

• 315000 Anfragen/Sekunde 

– Steigerungsrate von 2003 bis 2005: Faktor 10 

� Zentrale Fragestellung 

– Wie kann man solche Datenmengen beherrschen? 

– Wie kann man DBMS bauen, die solch eine hohe Last unterstützen? 

Einführung 

Seite 20

Einführung 

Seite 21

Konzeptioneller Datenbankentwurf 

2. Konzeptioneller Datenbankentwurf 

Naive Vorgehensweise bei der Realisierung einer Datenbank 

� Informatiker definiert am Rechner das Datenbankschema 

Probleme 

� Datenbankschema ist hochgradig komplex 

– SAP-Datenbank besteht z. B. aus mehr als 20.000 Datentypen (ohne spezifische 

Benutzerdaten). 

==> Online-Entwicklung am Rechner ist nahezu unmöglich 

� Hohe Anzahl von Anwendungsprogrammen 

– Bei Unternehmen wie Allianz oder BMW greifen mehrere tausende AWP auf die gleiche 

Datenbank zu. 

==> Berücksichtigung der Bedürfnisse der Anwender ist zwingend erforderlich 

Seite 21

Datenorientierter Ansatz 

� Welche Daten müssen im System verwaltet werden? 

� Wie werden die Daten im System verändert? 

� Wie greifen die AWP auf die Daten zu? 

Datenbankentwurfsschritte 

Datenverarbeitungsanforderungen 

Anforderungsanalyse 

Informationsanforderungen 

Konzeptioneller 

Entwurf 

Logischer 

Entwurf 

DBMS- 

Eigenschaften 


Hardware/BS- 

Eigenschaften 

Physischer 

Entwurf 

Seite 22

Anforderungsanalyse 


� Diese Problemstellung wird primär im Bereich der Softwaretechnik betrachtet. 

– siehe auch die Veranstaltungen von Prof. Hesse/Prof. Täntzer 

� Die Analyse basiert auf dem Wissen über Informationsstrukturanforderungen, z. B. 

– Was sind meine Objekte und deren Attribute? 

– Wie sehen die Beziehungen zwischen den Objekten aus? 

– Wie viele Objekte werden in meiner Datenbank auftreten? 

und die Datenverarbeitungsanforderungen, z. B. 

– Was sind meine typischen Prozesse? 

– Reihenfolge und Priorität der Operationen 

� Zentrales Problem bei der Anforderungsanalyse: 

– Entwickler einer Datenbank muss diese Informationen erst von den Benutzern der 

Datenbank bekommen! 

– Es gibt kein Patentrezept für eine erfolgreiche Anforderungsanalyse. 

� Resultat der Anforderungsanalyse 

– Pflichtenheft, in dem möglichst genau festgehalten wird, was die Datenbank zu leisten 

hat. 

Seite 23

Ziel: 

Konzeptioneller Entwurf 

� Erstellung eines Modells unabhängig vom 

– konkreten DBMS 

– und eines konkreten Datenbankmodells 

Methode 


� Datenbeschreibung in einer formalen Sprache auf Basis eines Modells hoher Abstraktion 

– Ein bekanntes konzeptionelles Datenmodell ist das Entity-Relationship Modell (ER- 

Modell) 

– Ein insbesondere für OO-Sprachen wichtiges Datenmodell ist Bestandteil der UML 

(Unified Model Language). 

� Daten in der Datenbank (Instanzen) werden nicht betrachtet, sondern nur deren Schemata. 

Problem 

� Automatische Transformation einer Anforderungsanalyse in einen konzeptionellen Entwurf 

– Anforderungsanalyse ist informell, konzeptionelles Modell ist relativ formal 

– Weglassen irrelevanter Strukturen (Abstraktion der realen Objekte) 

Seite 24

Ziel 

Logischer Entwurf 


� Abbildung der Datenstrukturen des konzeptionellen Modells in Datenstrukturen des darunter 

liegenden logischen Datenmodells, d.h., in konkrete Strukturen der entsprechenden Datenbank 

(z. B. Relationen, XML-Hierarchie) 

– Möglichst kompakte Repräsentation Daten (Vermeidung von Redundanz) 

� Datenstrukturen des logischen Modells abstrahieren von der physischen Repräsentation. 

– Konkretes DBMS hat keinen Einfluss auf die Modellierung 

Physischer Entwurf 

� Physische Repräsentation der Datenstrukturen des logischen Entwurfs in Dateien 

– Aufteilung einer Datei auf verschiedene Plattenspeichersysteme (Lastbalancierung) 

� Anlegen von Hilfsstrukturen wie z. B. Indexe zur Unterstützung von Anfragen. 

– Zu viele Indexe: Updates der Datenbank werden zu teuer 

– Zu wenige Indexe: Anfragen werden nicht effizient unterstützt. 

Seite 25


2.1 Entity-Relationship Datenmodell 

� Kurz ER-Modell (Peter P. Chen: The Entity-Relationship Model - Toward a Unified View of 

Data. in Trans. on Database Systems 1(1): 9-36(1976)) 

� Das ER-Modell hat eine große Relevanz in der Praxis, insbesondere für 

– den konzeptionellen Entwurf von Datenbanken 

� Vorgehensweise beim DB-Entwurf (siehe oben) 

– Zunächst Anforderungsanalyse und Entwurf des ER-Modells 

– Dann Logischer Entwurf, d. h. Umsetzung des ER Modells in ein Datenbankmodell 

� Ziel: 

Modellierung eines Ausschnittes der “realen Welt” durch Abstraktion, so dass gewisse 

Fragen über die “reale Welt” mit Hilfe des Modells beantwortet werden können. 

– “Reale Welt”:Zunächst nur wahrnehmbar über Sinnesorgane. Menschliche Sprache ist 

bereits erster Abstraktions- und Modellierungsschritt. 

ER-Modell beschreibt “reale Welt” durch 

� Entitäten (Entities) mit 

� Eigenschaften (Attributes) und 

� Beziehungen (Relationships) zueinander. 

Seite 26

Informelle Definitionen 

Entität (Entity) 


� Eine Entität existiert in der realen, zu modellierenden Welt und unterscheidet sich von 

anderen Entitäten. 

– Beispiele: (ISBN 3-929821-31-1, Datenbanken), (Sommer, C++) 

� Ähnliche Entitäten werden zu einer Entitätsmenge (Entity Set) zusammengefaßt. 

– Menge aller Bücher, Menge aller Vorlesungen, Menge aller Professoren 

Eine Entitätsmenge umfaßt alle zusammengehörigen Entitäten unabhängig von der derzeitigen 

Ausprägung in der Datenbank. Man spricht dann auch von einem Entitätstyp. 

– Ein Entitätstyp wird durch die zugehörigen Attribute und weiteren Nebenbedingungen 

beschrieben. 

� Ein Attribut eines Entitätstyps beschreibt eine charakteristische Eigenschaft 

– Jedes Buch besitzt eine ISBN-Nummer, einen Autor, … 

– Die Werte eines Attributes stammen aus Wertebereichen wie INTEGER, STRING, … 

z. B. ist die ISBN-Nummer eines Buches ein String aus Ziffern 

� Eine minimale Menge von Attributen, anhand deren Werte sich alle Entitäten eines 

Entitätstyps unterscheiden lassen, wird als Schlüsselkandidat bezeichnet. 

– z.B. identifiziert die ISBN-Nummer das Buch 

Seite 27

Beziehung (Relationship) 


� Eine Beziehung repräsentiert Zusammenhänge zwischen Entitäten. 

Beispiele: 

– Student Maier hört Vorlesung DBS I 

– Es gibt ein Buchexemplar zum Buch mit ISBN-Nummer 3-929821-31-1 

� Eine „homogene“ Menge von Beziehungen wird zu einer Beziehungsmenge (Relationsship- 

Sets) zusammengefaßt. 

– z. B. die Beziehung Hört_Vorlesung 

Eine Beziehungsmenge wird auch als Beziehungstyp bezeichnet, der durch eine geordnete 

Liste von Entitätstypen Ei ,1 � i � n, und zusätzlichen Attributen beschrieben wird. 

– n ist der Grad der Beziehung 

– Beziehungstypen können auch Attribute besitzen. 

Beispiel: Hört_Vorlesung besitzt als Eigenschaft die Nummer des Hörsaals 

– Der Grad einer Beziehung ist i. A. 2, aber eine Beziehung mit höherem Grad ist möglich. 

� Ein Entitätstyp darf in einem Beziehungstyp mehrfach vorkommen. 

– Zur Unterscheidung ist es dann wichtig an die mehrfach in einer Beziehung 

vorkommenden Entitätstypen eine Rolle zu vergeben. 

Seite 28


Funktionalität von Beziehungstypen 

1:1-Beziehungen (one-to-one relationships) 

� Falls für einen Beziehungstyp RE � 

1 

� E � 

2 

jede Entität aus E zu höchstens einer Entität aus 

� � 

1 

E 

2 

in Beziehung steht und umgekehrt. 

1:M-Beziehungen (one-to-many relationships) 

� Falls für einen zweistelligen Beziehungstyp RE � 

1 

� E � 

� 2� 

jede Entität aus E1 mit beliebig vielen 

(also mehreren oder auch keinen) Entitäten aus E2 , aber jede Entität aus E2 mit maximal einer 

Entität aus E1 in Beziehung steht. 

M:N-Beziehungen (many-to-many relationships) 

� Falls für einen binären Beziehungstyp RE � 

1 

� E � 

jede Entität aus E1 mit beliebig vielen (also 

� 2� 

mehreren oder auch keinen) Entitäten aus E2 in Beziehung stehen kann und umgekehrt. 

Seite 29

Beispiele 


� 1:1-Beziehung: ABTEILUNG wird geleitet von ANGESTELLTER 

Annahme: Jede Abteilung hat genau einen Leiter und kein Angestellter leitet mehr als eine 

Abteilung. 

� 1:M-Beziehung ANGESTELLTER arbeitet in ABTEILUNG 

Annahme: jeder Angestellte arbeitet in genau einer Abteilung. 

� N:M-Beziehung ANGESTELLTER arbeitet im PROJEKT 

Einige Besonderheiten: 

� Vergabe von Rollen an die Entitätstypen, wenn diese in einem Beziehungstyp mehrfach 

vorkommen 

– Beispiel: VORGESETZTER(CHEF: ANGESTELLTER, MITARBEITER: 

ANGESTELLTER) wobei CHEF und MITARBEITER Rollen für den Entitätstyp 

ANGESTELLTER sind. 

� Ein weiterer Beziehungstyp ist die Spezialisierung, bekannt auch als IS-A-Beziehung 

– ANGSTELLTER besitzt Attribute ANGNR, NAME und GEHALT 

– ZUGFUEHRER und TECHNIKER sind auch ANGESTELLTER, besitzen aber noch 

weitere Attribute 

Seite 30

Alternative Notationen 


� Unsere Notation bei einer 1:N-Beziehungen hält(Professor, Vorlesung) sieht folgendermaßen 

aus: 

1 

N 

Professor hält Vorlesung 

� In der Literatur findet man auch die funktionale Schreibweise hält: Vorlesung |--> Professor. 


Stattdesssen wird auch die funktionale Beziehung dadurch charakterisiert, wie oft eine Entität 

in der Beziehung mit einer anderen Entität auftreten kann. 

� Einige kommerzielle Anbieter verwenden die sogennannte “Krähenfußnotation” 


Seite 31

min-max-Notation 


� Im Gegensatz zu den rein syntaktischen Unterschieden funktionaler Beziehungen, ist die minmax-Notation 

tatsächlich eine semantisch angereicherte Notation für Beziehungen. 

Definition 

� An einer Kante einer Relation R(E 1 ,E 2 ) wird ein Intervall (min i ,max i ) i=1,2 notiert. Dabei gilt: 

– für alle e1 � E1 : min1 � �e2�e1�e2� � R� 

�max1 

– für alle e2 � E2 : min2 � �e1�e1�e2� � R� 

�max2 

� Wenn es keine obere Schranke gibt (oder diese unbekannt ist), wird dies durch ein “*” 

gekennzeichnet. 

Beispiel: 

(0,4) (1,1) 


1 

N 

Seite 32


Beziehungen mit mehr als zwei Entitäten 

Funktionale Notation 

� Im Folgenden betrachten wir eine Relation RE � 1� …� Ek� mit k Entitäten. Wir ordnen in 

unserer Notation der Kante zur Entität eine “1” zu, falls 

eine Funktion ist. Ansonsten wird ein Symbol M,N,…zugeordnet. 

� Beispiel: 

E j 

R: �E1� …� Ej – 1� 

Ej + 1� 

…� Ek� � Ej 1 

N 


M 

Raum 

Seite 33


Beziehungen mit mehr als zwei Entitäten 

min-max-Notation 

� Die min-max-Notation lässt sich auch verallgemeinern. Dabei betrachten wir k Intervalle 

�minj� maxj�, 1 � j� k, 

wobei folgende Bedingungen gelten: 

� Beispiel: 

minj minej � Ej Re1 … ej … e ( � � � � k) 

maxej � Ej Re1 … ej … e � � ( � � � � k) 

�maxj 

(0,8) (1,2) 

1 

N 


(0,*) 

M 

Raum 

Seite 34

2.1.1 ER-Diagramm 


� Graphische Repräsentation von Entitätstypen, Beziehungstypen und ihrer Attribute 

Folgende Vereinbarungen werden getroffen: 

� Ein Rechteck repräsentiert einen Entitätstyp: 

� Ellipsen repräsentieren Attribute: 

– Sie sind über ungerichtete Kanten mit ihrem Entitätstyp verbunden. 

– Schlüssel-Attribute werden unterstrichen. 

� Ein Beziehungstyp wird durch eine Raute repräsentiert: 

– Beziehungstypen werden mit ihren Entitätstypen durch Kanten verbunden. 

– Die Kanten werden mit der Funktionalität des in der Beziehung auftretenden Entitätstyps 

gekennzeichnet. 

a) Bei 1:1-Beziehungen besitzen beide Kanten das Symbol “1”. 

b) Bei N:1-Beziehungen zwischen E1 und E2 ist die Kante zu E1 mit dem Symbol 

“N” und die Kante zu E2 mit dem Symbol “1” gekennzeichnet. 

c) Bei N:M-Beziehungen wird “N” der einen und “M” der anderen Kante zugeordnet. 

Seite 35

Id-Beziehungen 

2.1.2 Erweiterungen 


� Id-Beziehungen sind spezielle 1:N-Beziehungen, wobei die Existenz einer Entität von einer 

anderen Entität abhängt. 

– Man bezeichnet dann auch den existenzabhängigen Entitätstyp als schwach und den 

anderen Entitätstyp als stark. 

� Graphische Notation 

� Beispiel: 

schwache 

Entität 

Abteilung 

Id-Beziehung 

1 N 

Ang 

Seite 36


IS-A-Beziehungen (Typerweiterung) 

� Eine Entität vererbt alle ihre Eigenschaften an eine andere Entität. Die Beziehung zwischen 

den Entitätstypen wird als IS-A-Beziehung bezeichnet. 

� IS-A-Beziehung wird für die Partitionierung einer Menge in (disjunkte) Teilmengen 

verwendet. Beide Entitätstypen einer IS-A-Beziehung besitzen den gleichen Schlüssel. 

� Beispiel 

– ANGSTELLTER besitzt Attribute ANGNR, NAME und GEHALT 

– Professoren sind auch ANGESTELLTER, besitzen aber noch weitere Attribute wie z. B. 

FACHGEBIET 

Professor 

Angestellter 

IS-A 

Mitarbeiter 

Besonderheit von IS-A und Id-Beziehungstypen 

� Es gibt höchstens einen IS-A oder Id-Beziehungstyp zwischen zwei Entitätstypen 

Seite 37


2.2 Entwurf eines ER-Diagramms 

Anhand des Beispiels eines Auskunft- und Buchungssystem für das DB-ICE-Netz 

Mögliche Anfragen (Datenverarbeitungsanforderungen) 

� Wann fährt ein Zug von München nach Bremen? 

� Reserviere einen Platz von München nach Frankfurt im Zug ICE621 am 6.5.2009. 

� Gib Liste der reservierten Plätze in Zug ICE621 am 6.5.2006. 

� Gibt es eine Verbindung von München nach Essen mit Abfahrt zwischen 8.00 und 10.00 (ohne 

umzusteigen)? 

Informationsanforderungen: 

Entitätstypen: 

� Zug 

� Wagen 

� Platz 

� Bahnhof 

Attribute: 

� Zugnr, Name, Verkehrstage 

� Wagennr., Klasse, Platzanzahl, R/NR 

� Platznr, Fenster 

� Name, Umsteigebahnhof 

Seite 38

Beziehungstypen: 

� Zugplan: Zug x Wagen 

� Wagenplan: Wagen x Platz 

� Belegung: Platz x Bahnhof x Bahnhof 

� Halt: Zug x Bahnhof 

� Zuglauf: Zug x Bahnhof x Bahnhof x Bahnhof 

� Verbindung: Bahnhof x Bahnhof x Bahnhof 

Einschränkungen: 

� Keine Reservierungen eines Platzes auf überlappenden Teilstrecken 

� Übereinstimmung der Zeiten in den Beziehungstypen Halt und Verbindung 


Seite 39

ER-Diagramm 


Zug Zugplan Wagen Wagenp. Platz 

Halt 

Zuglauf 

Bahnhof 

Verbind. 

Belegung 

Seite 40

Zusammenfassung 


� Datenbankentwurf ist ein äußerst komplexer Vorgang! 

� ER-Modellierung ist ein auch in der Industrie anerkanntes und weit verbreitetes Verfahren zur 

Datenmodellierung 

– Voraussetzung ist eine detaillierte Anforderungsanalyse 

– ER-Modell unabhängig vom Typ der Datenbank und dem konkreten System 

� Wichtige Komponenten des ER-Modells 

– Entität und Entitätstyp 

– Attribut 

– Beziehung und Beziehungstyp 

� Charakterisierung von Beziehungstypen 

– N:M, 1:M, 1:1-Beziehungen 

– min-max-Notation 

– IS-A-Beziehung, Has-A-Beziehung 

– “starke” Beziehungen 

� Frage: 

Wie kann das ER-Modell in ein Modell eines spezifischen Datenbanktyps abgebildet werden? 

Seite 41

3. Das Relationale Datenmodell 

Das Relationale Datenmodell 

� Entwicklung des relationalen Modells durch Codd (1970): 

E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 

13(6): 377-387(1970) 

� Kommerzielle DBMS wie z. B. 

– Oracle, SQL Server, Sybase, Informix, DB2 

und nicht-kommerzielle Systeme wie z. B. 

– Firebird, mySQL, PostgreSQL, MaxDB, Derby 

basieren in ihren Grundzügen auf dem relationalen Datenmodell 

Gründe für den Erfolg des relationalen Datenmodells 

� Einfachheit 

– Relation (vergleichbar mit einer Tabelle) als wesentliche Datenstruktur 

� Wenige, aber ausdrucksstarke Grundoperationen zur Verarbeitung 

– klare Semantik 

� Mengenorientierte Verarbeitung der Daten 

� Formale Fundierung der Modellierung und der Anfrageverarbeitung 

Seite 43

3.1 Grundlegende Strukturen 

Definition: Eine Relation R besteht aus folgenden Komponenten: 


1. einem Namen 

2. ein Relationenschema RSR – Ein Relationenschema definiert die spezifische Struktur der Relation. RSR wird durch 

eine Liste von k Attributen (A1 ,…,Ak ) beschrieben, wobei es zu jedem Attribut Aj einen 

Wertebereich Dj = dom(Aj ) gibt. Der Wertebereich der Relation ist dann 

dom( R) 

= D 

1 

� D 

2 

��D k 

, k � 1 

– Der Wertebereich eines Attributs ist endlich und besteht aus atomaren Elementen, die 

keine weitere Struktur besitzen. Beispiele hierfür sind int oder String. 

Oft sind weitere semantische Eigenschaften bekannt, welche zu einer erheblichen 

Verkleinerung des Wertebereichs führen können. 

3. eine Instanz IR Darunter verstehen wir eine Teilmenge des Wertebereichs: 

I 

R 

� 

dom( R) 

Ein Tupel (Zeile, Datensatz) der Relation R entspricht einem Element der Relationeninstanz 

I R . Ein Tupel hat somit für jedes Attribut genau einen Wert. 

Seite 44

Notation 


� Tupel: (Franz, 2000, 1966) 

Dies könnte ein Tupel einer Relation Personal mit den Attributen Name, Gehalt und 

Geburtsjahr sein. 

� Relationenschema einer Relation R: RSR = (A1 ,…,Ak ) 

– Für eine Relation R mit k Attributen bezeichnet k die Grad (Stelligkeit) von R. 

– In der Literatur findet man auch häufig die Schreibweise R(A1 ,…,Ak ). 

� Relationeninstanz einer Relation R: I R = {t 1 ,…,t n }, wobei t i die Tupel sind. 

Vereinfachte Notation und weitere Begriffe 

� Der Begriff Relation wird oft auch für die Instanz einer Relation verwendet. 

� Ist klar, um welche Relation es sich handelt, wird der Index bei der Instanz und beim Schema 

einfach weggelassen. 

� Häufig wird eine Relation als Tabelle dargestellt: 

Pers1 Name Gehalt GebJahr 

Carlo 2000 1981 

Beate 3000 1977 

Pers 1 ist der Relationennamen. Name, Gehalt, GebJahr sind die Attributsnamen. 

Seite 45

Gleichheit von Relationen 

� Seien R und S zwei Relationen. Dann sind R und S schemakonform, falls 

– dom(R) = dom(S) 

– und RSR = RSS . 


� Zwei Relationen R und S sind gleich, wenn R und S schemakonform sind und I R = I S . 

Bemerkungen 

� Relationen sind vergleichbar mit Variablen aus imperativen Programmiersprachen. Relationen 

sind Speicherbereiche in der Datenbank, die über den Relationennamen angesprochen werden 

können. 

Seite 46

Reihenfolge der Attribute 


� Bei unserer bisherigen Definition einer Relation hat die Reihenfolge der Zeilen (Tupel) keine 

Bedeutung. Eine Instanz wird immer als eine Menge von Tupel betrachtet. 

� Die Reihenfolge der Attribute ist aber von Bedeutung, was insbesondere dazu führt: 


Carlo 2000 1981 

Beate 3000 1977 

� Um die Gleichheit solcher Relationen zu erzielen, betrachten wir folgende Definition für eine 

Relation R: 

– Das Schema RSR von R besteht aus einer Menge von Attributen: RSR Jedes Attribut verfügt wie bisher über einen Wertebereich. 

= �A1� …� Ak�. – Die zu R gehörende Instanz IR ist eine endliche Menge von totalen Abbildungen der 

k 

� 

Form t: RSR � dom( Ai) , wobei tA ( j) 

� 

dom( Aj) gilt. 

i = 1 

= 

Pers2 Gehalt Name GebJahr 

2000 Carlo 1981 

3000 Beate 1977 

� Diese Definition liefert uns den gewünschten Effekt! Je nach Sachverhalt werden wir auf die 

eine oder die andere Definition zurückgreifen (siehe auch Literatur). 

Seite 47

Beispiel: 


Carlo 2000 1981 

Beate 3000 1977 

� Relationenschema der Relation Städte: 

{Name, Gehalt, GebJahr} mit dom(Name) = String[40], dom(Gehalt) = 

Integer und dom(GebJahr) = Integer 

� Tupel t1 und t2 mit 

t 1 (Name) = Carlo, t 1 (Gehalt) = 2000 und t 1 (GebJahr) = 1981 

t 2 (Name) = Beate, t 2 (Gehalt) = 3000 und t 2 (GebJahr) = 1977 


Seite 48

Datenbank 


� Analog zu einer Relation wird eine Datenbank durch drei Eigenschaften beschrieben: 

– Name 

– Datenbankschema: Menge der Relationenschemata 

– Datenbankinstanz: Menge der Instanzen der Relationen 

� Viele der somit beschreibbaren Datenbankinstanzen können nicht auftreten. Es ist deshalb 

sinnvoll, die möglichen Datenbankinstanzen durch semantische Bedingungen einzuschränken. 

Seite 49

Einfache Integritätsbedingungen 


� Integritätsbedingungen sind semantische Eigenschaften einer Relation, welche die Menge der 

möglichen Instanzen einschränken. Im Folgenden werden wir eine wichtige Bedingung 

erläutern. Eine ausführliche Diskussion folgt später. 

Notation 

� Sei R eine Relation und RS das zugehörige Schema. Sei X�RS. Dann bezeichnet t[X] das 

Tupel t eingeschränkt auf X. Ist X = {A}, so schreiben wir kurz t[A] (statt t[{A}]. 

Schlüssel 

� X�RS wird als Schlüssel bezeichnet, wenn folgende Bedingungen erfüllt sind: 

– Eindeutigkeit: Für alle (real möglichen) Relationeninstanzen I der Relation R gilt: Für 

zwei beliebige Tupel t1 und t2 aus I gilt: 

t 

1 

�X� = t 

2 

�X��t 1 

= t 

2 

– Minimalität: es gibt kein Y � X ( Y � 

X), 

so dass die Eindeutigkeit erfüllt ist. 

� Wenn mehrere Teilmengen eines Relationenschemas Schlüssel sind, wird einer von diesen als 

Primärschlüssel ausgezeichnet. 

– Die Attribute des Primärschlüssels werden im Schema unterstrichen. 

Seite 50


3.2 Abbildung eines ER-Schemas in ein 

� Datenstruktur der ER-Datenmodellierung 

– Entitätstypen 

– Beziehungstypen 

� Datenstruktur des relationalen Modells 

– Relationen (bzw. Relationenschema) 

Fragestellung 

relationales Schema 

� Wie kann ein ER Datenmodell in ein relationales Model umgesetzt werden? 

� Diese Frage wird nun in zwei Schritten beantwortet: 

– Einfache Umsetzung von Entitätstypen und Beziehungstypen 

– Konsolidierung des Relationenschemas 

Seite 51

Umsetzung eines Entitätstyps 


� Der Entitätstyp wird als eigenständige Relation umgesetzt, wobei jede Eigenschaft des 

Entitätstyps durch ein Attribut in der Relation dargestellt wird. 

� Die Namen der Attribute können entsprechend den Namen der Eigenschaften des Entitätstyps 

gewählt werden. 

� Der Schlüssel des Entitätstyps wird als Primärschlüssel des Relationenschemas vereinbart. 

� Beispiel (siehe ER Diagramm aus Kapitel 2): 

– Entität Zug: 

{ZugNr: Integer, Typ: String} 

– Entität Bahnhof 

{Id: Integer, Stadt: String, Name: String} 

Seite 52

Umsetzung eines Beziehungstyps 


� Der Beziehungstyp wird als eigenständige Relation umgesetzt, wobei 

– die Primärschlüssel der beteiligten Entitäten vollständig im Relationenschema 

aufgenommen werden 

– und jedes Attribut des Beziehungstyps durch ein Attribut in der Relation dargestellt wird. 

� Die aus einem Primärschlüssel gewonnen Attribute werden als Fremdschlüssel bezeichnet. 

� Die Namen der Attribute eines Fremdschlüssels müssen z. T. umbenannt werden, damit eine 

Eindeutigkeit der Namen gewährleistet wird. 

� Beispiel (M:N-Beziehungstyp) 

– Umsetzung des M:N-Beziehungstyps hält und die am Beziehungstyp beteiligten 

Entitätstypen Zug und Bahnhof. 

– Der Schlüssel von hält entspricht dabei der Menge von Fremdschlüsseln. 

Zug Id Typ 

529 ICE 

621 ICE 

… … 

hält Zug Bhf Gleis 

529 1 7 

529 2 4a/b 

621 1 7 

621 3 22 

… … … 

Bahnhof Id Stadt Name 

1 Frankfurt Lahn 

2 Würzburg Hbf 

3 München Hbf 

… … 

Seite 53


� Beispiel (Umsetzung eines 1:N-Beziehungstyps) 

– Betrachten wir hierzu ein Beispiel aus der Universitätswelt, in der ein Professor 

Vorlesungen abhält. Wenn der Primärschlüssel von Professor die PersNr und die von 

Vorlesung die VorNr ist, würden die Beziehung liest als zweistellige Relation umgesetzt 

werden. 

– Man beachte aber, dass {PersNr, VorNr} kein Schlüssel von liest ist, da die Eigenschaft 

der Minimalität verletzt ist. {VorNr} erfüllt aber die Eigenschaft eines Schlüssels. 

� Mit der Fremdschlüsseleigenschaft bezeichnet man nun folgende Integritätsbedingung: 

– Sei F der Fremdschlüssel in R, der sich auf eine Relation S bezieht, so muss stets 

erfüllt sein. 

1 N 

Professor liest Vorlesung 

IR�F� � 

IS�F� Seite 54

Konsolidierung des Schemas 


� Mögliche Vereinfachungen des Schemas durch Verschmelzen von Relationen, die aus einem 

zweistelligen Beziehungstyp der Kardinalität 1:1 oder 1:N hervorgegangen sind. 

� Seien R und S die Relationen der beteiligten Entitätstypen eines 1:N-Beziehungstyps und T die 

Relation des Beziehungstyps. Dann können wir alternativ folgendes Schema verwenden: 

– Statt der Relation S und T wird eine neue Relation U eingeführt, wobei 

RSU = RSS � RST Die Instanzen von U sollen nun die gleiche Information wie zuvor die Instanzen von S 

und T enthalten. Hierzu verknüpfen wir die Tupel aus S und T bzgl. ihrer Fremdschlüssel. 

– Für die Tupel s � IS, die kein t � ITmit s[F] = t[F] besitzen, wird ein Tupel u erzeugt, 

so dass � � = 

s. 

uRS S 

– Die anderen Werte von u werden mit einem speziellen Wert (NULL) aufgefüllt. 

NULL-Werte signalisieren, dass der Wert bisher unbekannt ist. NULL-Werte sind bei 

einem Schlüssel explizit verboten. 

– Die Relation R bleibt unverändert bestehen. 

� Was sind die Vor- und Nachteile einer solchen Konsolidierung? 

Seite 55


Umsetzung von IS-A-Beziehungstypen 

� IS-A-Beziehungstypen werden nicht durch eine eigene Relation repräsentiert. Die Beziehung 

wird dadurch bereits ausgedrückt, wenn der Schlüssel des allgemeinen Typs auch als Schlüssel 

der spezialisierten Typen benutzt wird. 

� Beispiel: 

Professor 

Angestellter 

IS-A 

Mitarbeiter 

ANGNR 

Name 

Fachgebiet Thema 

Daraus ergeben sich drei Relationen mit dem Schema {ANGNR, Name}, {ANGNR, 

Fachgebiet} und {ANGNR, Thema}. 

� Als Alternative bietet sich an, den IS-A-Beziehungstyp und die beteiligten Entitätstypen durch 

eine Relation mit Schema {ANGNR, Name, Fachgebiet, Thema} zu präsentieren und bei den 

Instanzen die fehlende Information durch NULL-Werte aufzufüllen. 

Was ist bei diesem Ansatz problematisch? 

Seite 56

mnr 

MName 

Beispiel (ER-Diagramm) 

Fähigkeit 

M PM- N 

Machinen Zuteilung Personal 

AName 

abtnr 

pnr 

N 

arbeitet_in 

1 

Abteilung 

PName 

1 

N 


leitet 

Seite 57

Datenbankschema: 

PM-Zuteilung: 

pnr mnr Fähigkeit 

67 84 3 

67 93 2 

67 101 3 

73 84 5 

114 93 5 

114 101 3 

51 93 2 

69 101 2 

333 84 3 

701 84 2 

701 101 2 

82 101 2 

Beispiel (Relationen) 

Abteilungsleiter: 

abtnr pnr 

B10 67 

A63 333 

A64 333 

Abteilung: 

abtnr AName 

B10 Spielzeug 

A63 Computer 

A64 Suppen 

Personal: 

mnr MName 

84 Presse 

93 Füllanlage 

101 Säge 


pnr PName Vorname Abt Lohn 

67 Meier Helmut B10 L4 

73 Müller Margot B10 L5 

114 Bayer Martin A63 L6 

51 Daum Birgit A64 L7 

69 Störmer Willi A64 L6 

333 Haar Hans A63 L6 

701 Reiner Willi A64 L6 

82 Just Michael A64 L6 

Maschinen: 

Seite 58

Was ist eine Algebra: 

3.3 Die relationale Algebra 

� Gegeben eine Menge N (“Anker der Algebra”) 

� Menge von Operationen { � 

1 

, …, 

� 

n 

} der Form � 

j 

: Nk � 

N 

Relationale Algebra 

� Anker ist die Menge aller Relationen 

� Menge von 6 Grundoperationen 


Seite 59


3.3.1 Grundoperationen der relationalen 

Algebra 

� Gegeben zwei Relationen R({A 1 ,…,A r }) und S({B 1 ,…,B s }) vom Grad r und s. 

– Zur Erleichterung der Definition sei hier angenommen, dass die Attribute der Relationen 

ungeordnet und die Tupel also Abbildungen sind. Dann gilt: 

IR � �t | �tA � i� 

� dom�Ai��1� i� r�� 

und IS � �t | �tB � i� 

� dom�Bi��1�i �s�� 

� Vereinigung: R � S 

– Voraussetzung: R und S sind schemakonform. 

– RSR � S = RSR und IR � S = IR � IS � Differenz: R– S 

– Voraussetzung: R und S sind schemakonform. 

– RSR – S = RSR und IR – S = IR \ IS � Kartesisches Produkt: R�S – Voraussetzung: RSR �RSS = � 

– RSR � S = RSR � RSS und IR S 

= 

� 

� I R I S 

Seite 60

� Projektion: Sei X � RSR, X � �. 

Dann ist 

RS�X�R� X 

= und I 

�X�R� Das Relationale Datenmodell 

Statt der Angabe einer Teilmenge X = {A,B,C,…} werden üblicherweise bei der Projektion 

nur die Attribute A,B,C,… als Index der Projektion verwendet. Z. B.: 

�A� B� C�R� 

= � A� B� C 

� Selektion: 

Dabei ist F eine Boolesche Funktion (Prädikat), die sich folgendermaßen zusammensetzt: 

a) Operanden: Konstanten oder Name eines Attributs 

b) Vergleichsoperatoren: = , � , � , � , � ,� 

c) Boolesche Operatoren: � , � , � 

– 

– 

�F�R� � � 

� � R 

RS�F�R� = RSR I �F R 

= 

� � t | t I R 

= 

� � � Ft () � 

�r �t 

� IR : r = t�X�� Umbenennen von Relationen und Attributen (“+ 1- Operation”) 

�S�R�: Relation R wird in Relation S umbenannt 

Seite 61

�B � A R 

� �: 

Attribut A der Relation R wird umbenannt in B 


– Umbenennung unterscheidet sich von den anderen Operatoren dadurch, dass keine neue 

Instanz erzeugt wird, sondern nur das Schema der Relation verändert wird. 

– Operator ist notwendig für binäre Operatoren, wenn beispielsweise 

a) eine Relation mehrfach im Kreuzprodukt vorkommt, 

b) zwei Relationen bei der Vereinigung nicht schemakonform sind. 

– Werden gleichzeitig A1 in B1 , A2 in B2 , …, Ak in Bk umbenannt, benutzen wir die 

verkürzte Schreibweise: �R�. �B1� �� Bk � A1��Ak Seite 62

Beispiele (abstrakt) 

R A B C 

a b c 

d a f 

c b d 

R�T �A�C a b c 

d a f 

c b d 

b g a 

S D E F 

b g a 

d a f 

R– T 

a b c 

c b d 

�R� A C 

A B C 

� � 

a c 

d f 

c d 

�B = b R 

a b c 

c b d 

T = �A B C 

T A B C 

b g a 

d a f 

� � � D�E�F R�S �S� Das Relationale Datenmodell 

A B C D E F 

a b c b g a 

a b c d a f 

d a f b g a 

d a f d a f 

c b d b g a 

c b d d a f 

Seite 63

� Relationenschemata: siehe Seite 58 

Beispiele für Anfragen 


� Bestimme alle Personen und deren Lohngruppe, die in Lohngruppe L5 oder höher sind. 

�PName� Lohn �Lohn � ’’L5’’ 

� �Personal�� In welcher Abteilung arbeitet Müller? 

�abtnr��PName = ’’Müller’’ �Personal�� Bestimme die Personen mit gleichem Vornamen. 

�PersNr� pnr��VN 

= Vorname�Personal 

� �PersNr � pnr� 

VN � Vorname��Vorname� 

pnr�Personal�� 

� Finde die Namen aller Personen aus der Abteilung Computer. 

�PName��Abt = abtnr�Personal 

� �AName = ’’Computer’’ �Abteilung�� Finde alle Personen, die nur an der Maschine mit Nummer 84 ausgebildet sind. 

�pnr��mnr = 84�PM-Zuteilung��– 

�pnr��mnr � 84�PM-Zuteilung�� 

Seite 64

Durchschnitt: 

� R�S = R – �R– S� 

� Beispiel: 

3.3.2 Abgeleitete Operationen 

R�S R B C D 

b c a 

b c d 

b f b 

a d c 

S B C D 

b c d 

b c e 

a d b 

R�S Das Relationale Datenmodell 

B C D 

b c d 

Seite 65

Quotient (Division): 

� vereinfachende Annahme: 

� und IS � � 

RS R 

� Relationenschema des Quotienten: 

RSR S = – 

� Resultatsinstanz des Quotienten: 

� Beispiel: 

RS S 

I R S 

R�S � RS R RS S 

� = �t � s � IS�u�IR: u�RSS� = s � uRS � R – RSS� = t� 

R A B C D 

a b c d 

a b e f 

b c e f 

e d c d 

e d e f 

a b d e 

S C D 

c d 

e f 

R�S A B 

a b 

e d 


Seite 66

Natürlicher Verbund (natural join): 


� Der natürliche Verbund ist die wichtigste Operation neben der Selektion. Er stellt eine echte 

Verallgemeinerung des kartesischen Produkt dar. 

– Der Unterschied zum kartesischen Produkt tritt dann auf, wenn der Schnitt der beiden 

Schemata nicht leer ist, d. h. � � �. 

� Dann ist 

� Beispiel: 

RS R S 

= 


� 




R S 

I 

R S 

= �t | � s�Is: t�RSS� = s � � r�Ir: t�RSR� = r� 

R B C A 

b c a 

b c d 

b f b 

a d c 

S B C D 

b c d 

b c e 

b d a 

a d b 

R S 

B C A D 

b c a d 

b c a e 

b c d d 

b c d e 

a d c b 

Seite 67

Theta-Join (Verbund): 


� Auswahl bestimmter Tupel aus dem kartesischen Produkt R�S: – Voraussetzung: A�RSR, B � RSS, RSR �RSS = � und � � { = , � , � , � , � , � } 

– 

RA�BS := �A � B�R�S� R A�B S 

� Für � = “=“ wird der Join auch als Equi-Join bezeichnet. 

� Beispiel: 

R A B C 

1 2 3 

4 5 6 

7 8 9 

S D E 

3 1 

6 2 

RB � DS 

A B C D E 

1 2 3 3 1 

1 2 3 6 2 

4 5 6 6 2 

Seite 68

Anfragen 

� Finde alle Namen von Personen, die an einer Maschine ausgebildet sind. 

� 

PName 

�Personal PM-Zuteilung� 


� Finde alle Namen der Personen, die an keiner Maschine genügend gut ausgebildet sind. 

� 

PName 

�� pnr 

�Personal� – � 

pnr 

�� Fähigkeit � 5 

�PM-Zuteilung�� Personal� 

� Finde die Namen der Personen aus Abteilung “Suppen”, die an der Maschine mit mnr = 93 

ausgebildet sind. 

� 

PName 

�� AName = Suppen 

�Abteilung�� Personal� 

� 

mnr = 93 

�PM-Zuteilung�� Finde die Namen der Personen, die an der gleichen Maschine ausgebildet sind wie die Person 

mit pnr = 114. 

� 

PName 

�Personal �� mnr 

�� pnr = 114 

�PM-Zuteilung�� PM-Zuteilung�� 

Seite 69

Weitere Join-Operatoren 

� Bisherige Join-Operatoren werden auch als innere Joins bezeichnet. 

Äußere Join-Operatoren (engl.: outer joins): 


� Problem von inneren Joins: Datensätze ohne Join-Partner gehen verloren. 

– Beim äußeren Join bleiben Datensätze ohne Join-Partner (teilweise) erhalten. Die nicht 

bekannten Attribute werden mit Nullwerten aufgefüllt. 

� Schema des äußeren Joins entspricht dem des inneren Joins 

� Varianten 

– linker äußerer Join R S: Tupel von R bleiben erhalten 

– rechter äußerer Join R S: Tupel von S bleiben erhalten 

– vollständiger äußerer Join R S: Tupel von S und R bleiben erhalten 

� Beispiel 

R A B C 

a 1 b 1 c 1 

a 2 b 2 c 2 

S C D E 

c 1 d 1 e 1 

c 3 d 2 e 2 

R S A B C D E 

a 1 b 1 c 1 d 1 e 1 

a 2 b 2 c 2 NULL NULL 

Seite 70

Semi-Join 

� Der Semi-Join von R und S ist folgendermaßen definiert: 

R S = � �R S� 

RSR 


– Der Semi-Join berechnet also alle Tupel der Relation R, die am Join mit der Relation S 

beteiligt sind. 

� Beispiel 

R A B C 

a 1 b 1 c 1 

a 2 b 2 c 2 

S C D E 

c 1 d 1 e 1 

c 3 d 2 e 2 

R S A B C 

a 1 b 1 c 1 

Seite 71

Bisher: 

3.4 Das Relationenkalkül 

� Benutzung einer prozeduralen Anfragesprache 

� Explizite Beschreibung, wie das Ergebnis berechnet wird 

Zugrunde liegende Idee beim Relationenkalkül: 


� Ergebnis einer Anfrage ist eine Menge von Tupel 

� Beschreibung der Ergebnisrelation ohne dabei explizit eine Vorschrift für die 

Konstruktion des Ergebnisses anzugeben. 

� Prädikatenlogik erster Stufe 

Zwei verschiedene Techniken 

� Tupelkalkül 

� Domänenkalkül 

Seite 72

3.4.1 Das Tupelkalkül 

� Eine Anfrage im Tupelkalkül wird wie folgt formuliert: 


– f ist hierbei eine Boolesche Funktion. 

– Die Ergebnismenge der Anfrage ist durch die Tupel t aus dem Schema RS 

gegeben mit ft ��= true. 

– Wird kein Schema explizit angegeben, ergibt sich das Schema implizit aus dem 

minimal notwendigen Schema für die Formel f . 

– Häufig ergibt sich das Schema aus der verbalen Formulierung der Anfrage. Das 

Schema wird deshalb bei den Formeln nicht immer explizit angegeben. 

Beispiele: 

�tRS � � | ft �� 

� Was sind die Namen der Mitarbeiter aus Abteilung A63? 

�t�PName� | �s � Personal mit t[PName] = s[PName] und s[abtnr] = “A63“ � 

� Quotient der Relationen R mit Schema RSR und S mit Schema RSS , � : 

�tRS � R – RSS� | �ts � S �tr � R mit tr�RSR – RSS� = t und tr�RSS� = ts� RS S 


Seite 73

Formeln des Tupelkalküls 

� Eine Formel f setzt sich zusammen aus Atomen der Form 

– R(s): s ist Element der Relation R (s ist Tupelvariable) 

– s[i] � u[j] mit � � � = , � , � , � , � ,�� 

– s[i] � a 

– 

Beispiele: 

� Personal(t), t[Fähigkeit] > 4, t[abtnr] = u[abtnr] 

Eine Formel ist entweder durch 

� ein Atom 

oder rekursiv durch folgende Ausdrücke definiert (Ann.: f und g sind Formeln): 

� f�g, f�g, �f, �� f 

� �sRS � �f, 

�sRS 

� �f 


– s ist eine Tupelvariable in f 

und RS ist das zur Variablen s gehörende Schema 

Seite 74

Bemerkung: 

� Reihenfolge der Ausführung: � und �; 

�; 

� ; � 

� Klammern setzten die Reihenfolge außer Kraft 

Beispiele: 

Annahme: Tupelvariable x ist aus dem Schema {pnr,mnr,Fähigkeit} 

� �x�Fähigkeit��4 � 

� 

� 

�x�pnr� = ypnr � �� 

� �x�Fähigkeit� � 4 

PM-Zuteilung�x��xpnr � � = ypnr � �� 

� �x�Fähigkeit� � 4 

�x�PM-Zuteilung�x� 

� �xpnr � � = y�pnr�� x�Fähigkeit� � 4� 


Seite 75


Freie und gebundene Tupelvariablen 

� Freie und gebundene Variablen im Tupelkalkül entsprechen globalen und lokalen 

Variablen in einem Programm. 

� Durch Angabe eines Quantors direkt vor einer freien Variablen wird diese gebunden. 

Definition 

– Das Auftreten einer Tupelvariablen in einem Atom ist stets frei. 

– Für f = �g 

und f = �g� sind alle freien Variablen von g auch frei in f. 

– Für f = g�h und f = g�h sind die Variablen in f frei, falls sie es in g und h sind. 

– Sei x eine freie Variable in g. Dann wird durch f = �x �RS��g� und f = �x (RS) �g� x zu einer gebundenen Variable in f. Dabei ist RS das Schema der Variable x. 

Beispiel: 

�x��pnr�mnr�Fähigkeit��P-M-Zuteilung�x� � x�Fähigkeit� � 4� 

Seite 76


Berechnung der Formeln des Tupelkalkül 

� Ein Ausdruck des Tupelkalküls hat die Form 

�tRS � � | ft �� 

wobei t (aus dem Schema RS) die einzig freie Variable in f ist. 

Definition (Substitution): 

� Sei fs � � eine Formel mit der freien Variable s. Dann ist fs/t � � die Substitution von der 

Tupelvariable s in f durch das Tupel t, falls in jedem Atom, das ein freies Auftreten 

von s enthält, wie folgt verfahren wird: 

– R(s) wird ersetzt durch “wahr”, falls t � R. 

Andernfalls durch “falsch”. 

– s[A] � u[B] wird ersetzt durch c � u[B] mit c = t[A] (Ann.: u�s ) 

– s[A] � c wird ersetzt durch “wahr”, falls tA � � � c 

gilt. Andernfalls durch “falsch”. 

Bemerkung: 

� Durch Substitution gewinnt man eine Formel die nur noch Konstanten der Form 

“wahr” und “falsch” und Atome mit gebundenen Variablen enthält. 

Seite 77

Beispiele 

� Voraussetzung: 

– u und t aus dem Schema {pnr,mnr, Fähigkeit} 

� Gegeben sei die Formel: 

�u��PM-Zuteilung(u) 

� �upnr 

� � = tpnr � � � u�Fähigkeit� � t�Fähigkeit�� Für das Tupel t = (73,84,5) gilt: 

�u��PM-Zuteilung(u) 

� �upnr 

� � = 73 � u�Fähigkeit� � 5� 

� Gegeben sei die Formel: 

�PM-Zuteilung(u) � �upnr 

� � = 73 � u�Fähigkeit��5 Für das Tupel u = (51,93,2) gilt: 

�wahr � �falsch 

� 

wahr 


Seite 78

Interpretation der Formel 


� Sei f eine Formel ohne freie Variablen. Die Interpretation I(f) ist wie folgt definiert: 

– Sei f = “wahr”. Dann ist I(f) := true. Sei f = “falsch”. Dann ist I(f) := false. 

– Sei f = (g). Dann ist I(f) := I(g). 

– Sei f = �g. 

Dann ist I(f) := true genau dann, falls I(g) = false. 

– Sei f = g � h. 

Dann ist I(f) := true genau dann, falls I(g) = true und I(h) = true. 

– Sei f = g � h. 

Dann ist I(f) := true genau dann, falls I(g) = true oder I(h) = true. 

– Sei f = �xRS 

� � �gx � ��. 

Dann ist I(f) := true, falls es mindestens ein Tupel t aus dem 

Schema RS gibt, so dass I(g(x/t)) = true ist. Andernfalls, I(f) := false 

– Sei f = �xRS 

� ��gx � ��. 

Dann ist I(f) := true genau dann, falls für alle t aus dem Schema 

RS I(g(x/t)) = true gilt. Andernfalls, I(f) := false. 

� Sei E = �x�RS� | fx � �� 

ein Ausdruck des Tupelkalküls und sei RS = {A1 ,…,An } das 

Schema von x und D1 � D2 � … � Dn der Wertebereich. Der Wert von E zu einer 

gegebenen Datenbank besteht aus allen Tupel t � D1�D2�… � Dn , die 

erfüllen. 

I�f�x/t�� = 

true 

Seite 79

Beispiele 


� Gib alle Personalnummern von Personen, die an einer Maschine ausgebildet sind. 

�t��pnr�� | �u�PM-Zuteilung�u� 

� u�pnr� = tpnr � �� 

� Gib alle Personalnummern der Personen, die an keiner Maschine genügend gut 


�t��pnr�� | �u��PM-Zuteilung�u� 

� u�Fähigkeit� � 5 � �upnr 

� � = tpnr � �� 

Menge der möglichen Werte 

für u (t[pnr] = 1): 

P-M-Zuteilung 

u[pnr] = 1 

alle möglichen Werte 

für u 

Seite 80

� 

� 

� 

Beispiel 


Einführung von Kurzschreibweisen: 

�u � R�fu 

� �� 

:= �u�RSR��Ru � � � fu � �� 


� �� 

:= �u�RSR��Ru � � � fu � �� 

f� g:= 

�f � g 

� Berechne die Namen der Personen, die an keiner Maschine genügend gut 

ausgebildet sind (Schema der Tupelvariablen t ist {PName}). 

�t | �x � Personalf�x�t�� y��pnr��ypnr 

� � = xpnr � � � gy � �� 

– fxt � � � = �xPName � � = tPName � �� 

– 

gy � � = �u 

� PM-Zuteilung�u�Fähigkeit� 

� 5 � �u�pnr� 

= ypnr � �� 

Vereinfachen der Formel g: 

gy � � = 

�u 

� PM-Zuteilung��upnr 

� � = ypnr � �� 

� �u�Fähigkeit� � 5�� 

Seite 81

Sichere Ausdrücke 


� Probleme des Tupelkalküls: 

– Beschreibung unendlich großer Relationen 

– Keine effektive Berechnung möglich (d.h. nur durch Testen jedes Elements aus dem 

Wertebereich) 

� Idee: 

– Beschränkung der Wertebereiche nur auf die tatsächlich in den vorhandenen Instanzen 

(der Relationen) vorkommenden Werte. 

� Definition: DOM�� f 

Menge aller Werte, die explizit in f vorkommen, oder in Instanzen der Relationen, die in f 

erwähnt werden (zur Erinnerung: Instanzen sind hier stets endlich). 

– Beispiel: f = “t�2� = 7 � Rt ��“ mit . 

Dann gilt: 

DOM�� f = 

�ab � � � �357 � � � 

R 

a 5 

b 3 

Seite 82

Definition (sicherer Ausdruck) 

Ein Ausdruck �t(RS) ft �� 

wird als sicher bezeichnet, falls: 

1. 

2. für jede Teilformel �u�gu � �� 

gilt: I�gu � � v�� 

= true � v � DOM�g� 3. für jede Teilformel �u�gu � �� 

gilt: v � DOM�g��I�gu � � v�� 

= true 

Beispiele: 

� 

� 

�t�RSPersonal� | Personal�� t � t�Vorname� = “Willi“ � 

ist ein sicherer Ausdruck 

�t�RSPersonal� | �Personal�� t � tVorname � � = “Willi“ �� 

ist nicht sicher. 


� Für eine Relation R und eine Formel f erfüllen die folgenden Teilformeln die 

Bedingung 2 bzw. 3: 

– �u � R�fu 

� �� 

– 

I�fu � � t�� 

= true � t � DOM�� f 


� �� 

Seite 83

3.4.2 Das Bereichskalkül 


� Das Bereichskalkül basiert auf einer ähnlichen Idee wie das Tupelkalkül mit dem 

Unterschied, dass Variablen sich jetzt auf die Komponenten der Tupel beziehen. 

� Ausdrücke haben die Form: 

�x1�xkfx � 1� �� xk�� wobei die Bereichsvariable x i einem Attribut A i zugeordnet ist, 1 � i � k. Die Bereichsvariablen 

x 1 ,…,x k sind die einzigen freien Variablen. 

Beispiele: 

� 

�vwxyz| � � � � Personalvwxyz � � � � � � mit x = “Willi“ � 

oder kürzer 

vw“Willi“ � � � yz| � Personal�v�w �“Willi“ � yz � �� 

oder wenn nur der Nachname erwünscht ist: 

�w | �v �y �z Personal�v�w �“Willi“ �yz � �� 

Seite 84

� Atome haben die Form: 

– Rx � 1�x k� 

(oder auch Rx � 1� �� xk�) – x � y mit Bereichsvariablen x und y 

� Substitution wird entsprechend wie beim Tupelkalkül vorgenommen 

Beispiele: 


� Was sind die Namen von Personen, die an einer Maschine ausgebildet sind. 

�t | �uvwxyzPM-Zuteilung 

� � � � � � �uvw � � ��Personal�u� t� x� y� z�� 

� Was sind die Personalnummern der Personen, die an keiner Maschine genügend gut 


�t | �x 

�y 

��PM-Zuteilung�txy � � � � y � 5�� 

Seite 85


3.5 Erweiterung der relationalen Algebra 

Probleme der relationalen Algebra und des Tupelkalküls 

� Das bisherige Konzept der relationalen Algebra unterstützt zwar die Formulierung vieler 

wichtiger Anfragen. Folgende Anfragen können jedoch bisher nicht ausgedrückt werden: 

(i) Sortieren der Daten (insbesondere beim Ergebnis einer Anfrage) 

(ii) Abspeichern von Duplikaten (die z. B. durch Projektion entstehen) 

– Datentyp Relation (Menge von Tupeln) ist hierfür nicht ausreichend 

(iii) Verdichtung der Daten einer Relation durch Aggregation (Summe, Durchschnitt) 

– Fehlende Operatoren in der relationalen Algebra 

Beispielsanfragen 

� Berechne zu jeder Maschine die Anzahl von Personen, welche die Maschine bedienen können. 

� Wieviel Lohn muss diesen Monat an alle Angestellten gezahlt werden? 

Anmerkung 

� Wir werden später bei der tatsächlichen Anfragesprache relationaler Systeme (SQL) sehen, 

dass diese Anforderungen beim Entwurf von SQL berücksichtigt wurden. 

Seite 86

M-Relation 


� Eine Multi-Relation (M-Relation) R besteht aus einem Relationenschema RS R und einer 

Instanz I R , wobei I R eine Multimenge (auch als Bag bezeichnet) ist. 

– Das Schema einer M-Relation enstpricht dem einer gewöhnlichen Relation. 

– Die zu einer Multi-Relation gehörende Instanz wird durch eine Funktion VM (x) 

beschrieben, die zu jedem Tupel x die Häufigkeit von x in der derzeitigen Instanz liefert. 

� Notation 

– Um den Unterschied zu Mengen klar zu machen, verwenden wir statt Mengenklammern 

“”. 

� Zwei M-Relationen heißen schemaverträglich, falls die Attribute der Schemata gleich sind, 

und der Wertebereich der Attribute in beiden Relationen gleich ist. 

� Um die Semantik von Operationen zu definieren, verwenden wir die Funktionen V. Seien M 

und N schemaverträgliche M-Relationen. Dann gilt 

– M = N genau dann, falls � x: 

VM�x� = VN�x�. – M�N genau dann, falls � x: 

VM�x� � 

VN�x�. � Gewöhnliche Relationen können als Spezialfall von M-Relationen betrachtet werden, für deren 

Tupel x stets V M(x) � 1 gilt. 

Seite 87


Erweiterung der relationalen Operatoren 

� Selektion: MRel -> MRel 

– 

RS�F�R� = RSR – Es gilt: V�F�R� . 

– Die Selektion auf M-Relationen entspricht damit der Selektion auf Relationen. 

– Beispiel: Sei RSR = {A,B} und . Dann ist 

x � � 

� 

= � 

� 

VR�x� 0 

falls F�x� sonst 

= ��11 � ��12 � ��13 � ��12 � �� 

I�B = 2�R� 

= 12 � 

�� 12 � �� 

I R 

� Kartesisches Produkt: MRel x MRel -> MRel 

– RSR � S = RSR � RSS (Ann.: RSR � RSS = �). 

– VR � S�x� 

= VR�xRS � R�� 

� VS�xRS � S�� 

für x�dom�R�S�. Es wird analog zu Mengen das kartesische Produkt bei Multimengen gebildet. 

– Beispiel: IR = ��1�� 2��1�� und IS = ��1��2��. Dann ist 

= 

��11 � ��12 � ��21 � ��22 � ��11 � ��12 � �� 

. 

IR � S 

Seite 88


� Vereinigung: MRel x MRel -> MRel 

– Seien R und S schemaverträglich. 

– Die Instanz ergibt sich aus folgender Bedingung: VR � S �x� + 

Bei der Vereinigung werden also Duplikate nicht beseitigt. 

= VR�x�+ VS�x�. – Beispiel: Seien IR = ��1�� 2�� 1�� und IS = ��2��3��. Dann ist 

= ��1�� 2�� 1�� 2��3��. IR �+ 

S 

– Diese Vereinigung wird auch als Summenvereinigung bezeichnet. Zusätzlich wird auch 

noch die Maximumsvereinigung benötigt. 

� Differenz: MRel x MRel -> MRel 

– Annahme: R und S sind schemaverträglich. Somit ist RSR – S = RSS �= RSR�. – Die Instanz ergibt sich aus folgender Bedingung: 

� V 

– VR – S�x� 

R�x� – VS�x� falls VR�x� � VS�x� = 

� 

. 

� 0 sonst 

Die Differenz entfernt somit nicht alle Instanzen von einem Element aus der ersten 

Multimenge, das in der zweiten Multimenge vorkommt. 

Seite 89

– Beispiel: IR = ��2��1��2��1�� und IS = ��2��3�� . Dann ist 

= ��2�� 1�� 1�� . 

IR – S 


– Als Alternative könnte man auch die Differenz strikt definieren, indem jedes Tupel aus 

der Relation R entfernt wird, das in der Relation S liegt. 

� Projektion: MRel -> MRel 

– Das Relationenschema X der Projektion auf einer Relation R wird explizit beim 

Operationsaufruf definiert, wobei X � RSR. – Es gilt: . Bei der Projektion wird also jedes 

� � VR x' 

= 

� � 

V�X�R� x 

� 

x' � IR � x'�X� = x 

Tupel der Eingabe in ein Tupel der Ausgabe überführt. Gleiche Tupel werden 

verschmolzen und deren Vielfachheit aufsummiert. 

– Beispiel: Für IR = ��11 � �� 12 � �� 23 � �� 

ist I�1�R� = 

��1��1��2��. � Umbenennung: MRel -> MRel 

Entspricht der Operation, wie sie für Relationen definiert ist. 

Seite 90

Verallgemeinerung der Projektion 


� Die Projektion und auch die Umbenennung sind bei M-Relationen Operatoren, die zu jedem 

Tupel der Eingabe ein Tupel der Ausgabe erzeugen. Solche Abbildungen werden auch als map 

bezeichnet. 

� Seien R eine M-Relation, RS ein Relationenschema mit Wertebereich D und 

f: (RSR -> dom(R)) -> (RS -> D) eine Abbildung. Dann wird durch 

T = �f�R� die relationale Map definiert, wobei 

– 

– 

RS�f�R� = RS 

V�f�R� x 

� 

� � VR y 

= 

� � 

y � IR�x= fy () 

� 

Beachte, dass f eine Funktion ist, die ein Tupel der Relation R auf ein Tupel der 

Ergebnisrelation abbildet. Dabei nutzen wir die Definition des Tupels als eine Abbildung. 

Beispiel 

Sei R eine Relation mit RSR = {A,B} und IR = ��12 � ��21 � ��12 � ��21 � ��46 � ��. 

Sei f(t) 

= (t[A]*t[B], t[A] + t[B]) eine Abbildung. Dann ist 

· 

= 

�� 23 � �� 

�23 � �� 23 � �� 24� 10��. 

I�f�R� 23 

Seite 91

Motivation 

Aggregation 


� Um schnell einen Überblick der Daten einer Multi-Relation zu bekommen, soll in einer 

Anfragesprache auch die Berechnung wichtiger Kennzahlen unterstützt werden. Insbesondere 

im betriebswirtschaftlichen Umfeld sind dabei die Aggregationsoperationen Summe (sum), 

Durchschnitt (avg), Anzahl (count), Minimum (min) und Maximum (max) von Bedeutung. 

� In der relationalen Algebra sind solche Operationen bisher noch nicht berücksichtigt worden. 

Erweiterung der relationalen Algebra 

� Eine Aggregationsfunktion agg berechnet zu einer Multi-Relation einen Wert aus einem 

Wertebereich D. Ganz allgemein ist agg: MRel � D. 

� Die relevanten Aggregationsfunktionen sind avg, sum, count, min, max: MRel � 

D , die eine 

Multi-Relation auf den Wert eines Attributs abbilden. 

– Bei sum, avg, min und max muss noch zusätzlich ein Attribut aus dem Schema der 

Relation angegeben werden, auf welches das Aggregat angewendet wird. 

– Die Operation count liefert die Anzahl der Tupel in der Instanz der Relation. 

� Aggregate finden zunächst nur Verwendung in Kombination mit einem Gruppierungsoperator, 

den wir auf der folgenden Seite einführen. 

Seite 92

Gruppierung 


� Um gleich mehrere Kennzahlen für eine Multi-Relation zu berechnen, kann diese in Klassen 

(Partitionen) aufgeteilt und für jede dieser Partitionen eine Kennzahl berechnet werden. 

� Eine Partition ist wiederum eine Relation, die das Schema von der Quelle erbt. 

– Bei einer Relation R wird eine Partitionierung durch �A1, �, 

An��RSR definiert. Eine 

Partition enthält alle Tupel aus IR , die bzgl. der Attribute �A1, �, 

An� den gleichen Wert 

besitzen. 

� Zu einer Aggregatoperation (und einem ausgezeichneten Attribut) wird nun für jede Partition 

eine Kennzahl berechnet. Diese Kennzahl wird zusammen mit den Werten der 

Partitionierungsattribute in der Ergebnisrelation eingetragen. 

� Sei R eine Multi-Relation und A = �A1, �, 

An��RSR. Des Weiteren seien B1 ,…,Bm Attribute und agg1 ,…,aggm Aggregatsfunktionen mit aggi : MRel � dom( Bi) .Dann ist der 

Gruppierungsoperator S = �A B1 

( ) folgendermaßen definiert: 

� = agg1�…�Bm= agg R 

m 

– RSS = A��B1�…�Bm�.(Ann.: Bi � A, 

1 � i� m) 

� 1falls V 

– VS�x� R�xA � �� 

� 0 

= � 

und x[Bi ] = aggi ( �RA � � = xA � ��R�). 

� 0 sonst 

Seite 93

Beispiel: 

� Betrachten wir die Relationeninstanz IR = ��ax � ��ay � ��az � ��bu � �� 

. Dann ist 

( R) 

= ��a� 3��b� 

1��. 

Es treten also keine Tupel mehrfach auf. 

�A�C = count 

Spezialfall (Duplikateliminierung) 


� Ein wichtiger Spezialfall des Gruppierungsoperators ist die Duplikateliminierung �. 

Dabei 

setzen wir A = RSR und berechnen keine Aggregationsfunktion (m=0). 

� Durch eine Duplikateliminierung werden alle Zähler von Tupeln der Relation R auf den Wert 1 

gesetzt. Eine solche Multi-Relation entspricht einer gewöhnlichen Relation. 

� Beispiele: 

– Sei R = ��1�� 2�� 1�� eine M-Relation. Dann ist ��R� = ��1��2��. – Relationenschemata:. 

Berechne die Abteilungen, in denen Mitarbeiter in der Lohngruppe L6 oder höher sind. 

�� Abt��Lohn � L6�Personal�� 

Seite 94

Abgeleitete Operationen 


� Man hat bereits bemerkt, dass die Unterstützung von Multi-Relationen zu einem wesentlich 

komplexeren Modell führt. 

– Insbesondere gelten die Mengengesetze für die Instanzen der Multi-Relationen nicht. 

� Deshalb werden noch weitere Operationen für die Vereinigung und Differenz benötigt. 

– Schnitt zweier schemaverträglicher Relationen R und S 

– Maximumsvereinigung von R und S 

– Strikte Differenz 

R�S = R– �R – S� 

R�maxS = �R– S� 

�+ 

S 

R-strictS = 

R ��( R) 

– S� 

� Anmerkung 

Leider ist dieser Grad an Präzision notwendig, da nur dadurch die Semantik von Anfragesprachen 

wie SQL klar definiert werden kann. 

Seite 95

Beispiele 

� Wie beziehen uns auf die Datenbank mit den Relationen Personal, Maschinen, … 

Anfragen 


� Was ist die durchschnittiche Bewertung aller Angestellten an den zugeteilten Maschinen. 

� Wie sieht der Notenspiegel insgesamt aus? 

� Welche Maschine wird unter allen Maschinen am schlechtesten bedient? 

� Welcher Angestellte hat den besten Notendurchschnitt? 

� Berechne für jede Abteilung die Anzahl der Maschinen, die von den Mitarbeitern bedient 

werden können. 

� Was ist der Notendurchschnitt der Angestellten aus den verschiedenen Abteilungen? 

Seite 96

� Eine S-Relation besteht aus (R, < R ), wobei 

– R eine M-Relation 

– < R eine Ordnungsrelation auf dom(R) 

� Durch 

– : MRel -> SRel 

� < 

S-Relation 

wird eine M-Relation R auf eine S-Relation S = (R,

Seien 

– < 1 = {((a,b,c), (d,e,f)) | a < d} 

– < 2 = {((a,b,c), (d,e,f)) | c < f oder (c = f) und b > e} 

Ordnungsrelationen. Dann sind 

Achtung: 

�


� Begriff der Relation 

– Relationenschema und Relationeninstanz 

– Zwei Definitionen basierend auf Attributlisten und Attributmengen 

– Einfache Integritätsbedingungen 

� Abbildung von ER-Modell in ein relationales Modell 

Grundlagen von Anfragesprachen 

� Relationale Algebra 

– Mengenalgebra 

� Tupelkalkül 

– Prädikatenlogik erster Stufe 

� Erweiterte relationale Algebra 

– Algebra für Multimengen 

– Geordnete Mengen 

– Weitere Operationen: Aggregation, Gruppierung, Sortierung 


Seite 99

SQL: Die Sprache relationaler DBMS 

4. SQL: Die Sprache relationaler DBMS 

� Basierend auf dem Tupelkalkül und der relationalen Algebra wurden mit dem Aufkommen 

relationaler DBMS auch spezielle Sprachen entwickelt. 

– SQL ist die derzeit marktbeherrschende Anfragesprache 

– Von praktischer Bedeutung waren auch noch bis Ende der 80er Jahre: 

a) QBE (Query by Example, basierend auf dem Domainkalkül) 

b) Quel (Anfragesprache von Ingres basierend auf dem Tupelkalkül). 

Bei Anfragesprachen wird unterschieden zwischen der 

� Datendefinitionssprache (DDL) 

– Anlegen und Ändern der Datenstrukturen für die drei Ebenen einer Datenbank (externe 

Ebenen, konzeptionelle Ebene, physische Ebene) 

– Festlegen von Integritätsbedingungen 

– Festlegen der Zugriffsrechte 

� Datenmanipulationssprache (DML) 

– Einfügen, Ändern und Löschen von Datenobjekten 

– Anfragen 

Seite 100

Historie 


� SQL (structured query language) wurde bei IBM als Sprache des relationalen DBMS System R 

entwickelt (1974, D.D. Chamberlin et al.) 

– SQL ist eine Mischform aus der erweiterten relationalen Algebra und dem (erweiterten) 

Tupelkalkül. 

� Heute ist SQL quasi der Standard für Sprachen relationaler DBMS 

– SQL1, 1985 

– SQL2, 1992 (wird auch als SQL92 bezeichnet) 

– SQL3 (SQL:1999 und SQL 2003) 

� SQL wird als interaktive Sprache eingesetzt, kann aber auch durch eine geeignete Kopplung in 

einer Programmiersprache wie z. B. C und Java genutzt werden. 

Anmerkung 

� Das offizielle Dokument, in dem der Standard von SQL beschrieben wird, umfaßt mehrere 

1000 Seiten. In dieser Vorlesung beschränken wir uns deshalb auf die wichtigsten Konzepte 

von SQL. 

� Viele Hersteller wie Oracle, Microsoft, IBM, … haben in ihren Systemen Erweiterungen von 

SQL implementiert. 

Seite 101

Lexikalische Elemente 


� Wie jede andere Programmiersprache besitzt SQL lexikalische Elemente. 

– Leerzeichen, Zeilenumbruch und Tabulatoren trennen lexikalische Elemente. 

Bezeichner 

� Bezeichner werden benutzt, um Namen an Datenbanken, Relationen und Attribute zu 

vergeben. 

� Aufbau eines Bezeichners 

– Erstes Zeichen ist ein Buchstabe. 

– Weiterhin können darin Zahlen und _ enthalten sein. 

– Bezeichner müssen sich von einem Schlüsselwort unterscheiden. 

Konstanten (Literale) 

� Literale sind sehr ähnlich zu den Konstanten in bekannten Programmiersprachen. 

� Gewöhnungsbedürftig sind Konstanten von Zeichenketten: 

– ´Gerd´ ist eine Konstante. 

– Einige DBMS unterstützen auch andere Formate. 

Seite 102

Vorbemerkungen 

4.1 DDL 


� Im Folgenden werden nun einige wichtige Aspekte bei der Datendefinition erläutert ohne 

jedoch auf viele der angebotenen Optionen einzugehen. 

� Wir werden beispielhaft die Definition von Datenstrukturen der konzeptionellen Ebene 

(Relation) erläutern 

– Die Definition von Datenstrukturen der internen Ebene (Index) und der externen Ebene 

(View) erfolgt später. 

Aufbau des Kapitels: 

� Datentypen 

� Definition von Relationen 

� Einfache Integritätsbedingungen 

Seite 103

4.1.1 Datentypen 


� Datenbanksysteme bieten eine sehr reichhaltige Palette von Datentypen an, die sich bis auf 

einen Kern erheblich unterscheiden. 

– Zum Teil findet man gleiche Datentypen mit unterschiedlichen Namen. 

– Auch wenn die Namen gleich sind, werden nicht die gleichen Operationen angeboten 

oder unterschiedliche Namen für die gleiche Methode. 

� Heutige Systeme unterstützen auch die Definition benutzerdefinierter Datentypen 

� Klassifizierung 

– Zeichenketten 

– Zahlen 

– Individuelle Erweiterungen, die es in nahezu allen DBMS gibt: 

binäre Daten (BLOB), Texte (CLOB), Date 

– DBMS spezifische Datentypen 

� Die unterschiedlichen Datentypen tragen insbesondere dazu bei, dass eine Kopplung von SQL- 

Datenbanken nicht so einfach ist. 

Seite 104

Zeichenketten 

Standardtypen 


� char(size) Zeichenkette mit konstanter Länge size 

– Maximallänge ist abhängig vom System. 

– char spezifiziert eine Zeichenkette mit einem Zeichen. 

� varchar(size) variabel lange Zeichenkette mit maximaler Länge size 

– Bedarfsorientierter Speicherplatzverbrauch 

� Die maximale Größe für size hängt von dem spezifischen DBMS ab, z. B. 8000 bei SQL 

Server. Wird size nicht angegeben, so hat die Zeichenkette die Länge 1. 

� Unicode-Unterstützung durch spezielle Typen: nchar, nvarchar 

Operationen auf Zeichenketten 

� Relationale Operatoren: =, , sind in allen DBMS verfügbar, aber die Semantik 

kann in Abhängigkeit des Systems anders sein. (Stichwort: Nullwerte) 

� Weitere Operatoren im SQL92 Standard (der aber in dieser Form nicht von allen DBMS 

unterstützt wird): 

– || ist z. B. die Verknüpfung von zwei Zeichenketten 

Seite 105

Zahlen 

� numeric(g,d) bzw. decimal(g,d) 

– Gleitkommazahlen mit: g = #Gesamtstellen, d = #Nachkommastellen 

� Darüber hinaus gibt es die üblichen Datentypen: 

integer, smallint, real, double precision 

� Operationen 

– *, /, +, - 

– und noch viele andere. Z. B.: abs 

Spezielle Datentypen 


� Die oben genannten Datentypen sind in ihrer Größe erheblich eingeschränkt. Anfang der 90er 

Jahre wurde dieses Defizit durch Einführung neuer Datentypen gemildert. 

long: 

– variabel lange Zeichenkette mit maximal 2 GB. 

– erhebliche Einschränkungen bei der Anfragebearbeitung 

clob / blob: variabel lange Zeichenfolge / Bytefolge mit maximal 4 GB 

� date/time Datentypen für Datum und Uhrzeit 

– date unterstützt ein Datum bis zum Jahr 9999 

Seite 106

Definition neuer Datentypen 


� In SQL lassen sich neue Wertebereiche anlegen, indem bestehende Wertebereiche 

eingeschränkt werden. 

– Syntax: 

create domain [as] [] [] 

– Beispiel: 

create domain Adresse varchar(50) default 'Marburg' 

� Weiterhin können Datentypen zur Laufzeit verändert 

– alter domain … 

und gelöscht werden: 

– drop domain Adresse 

Bemerkung 

� Es handelt sich hierbei um eine sehr eingeschränkte Form der Definition von Datentypen. Es 

ist dadurch z. B. nicht möglich, strukturierte Datentypen zu definieren. 

� Die Syntax dieses Befehls ist nicht für alle DBMS einheitlich. 

Seite 107


4.1.2 Anlegen eines Relationenschemas 

Eine stark vereinfachte Grammatik zur Definition einer Relation 

create table ([,] *) 

::= | 

::= [] [not null | unique] 

::= default | null 

� Die genaue Behandlung von Integritätsbedingungen erfolgt später. Im Weiteren werden wir 

einige Möglichkeiten exemplarisch erläutern. 

Folgende Beispiele basieren auf dem Datenbankschema von Seite 57. 

Seite 108

Beispiel: 

create table Abteilung( 

abtnr int primary key, 

aname varchar(10) not null unique) 

Anmerkungen zu den Integritätsbedingungen 


� unique drückt aus, dass dieses Attribut ein Schlüsselkandidat ist. Wird ein Schlüsselkandidat 

durch mehrere Attribute A 1 , …, A n gebildet, so wird dies durch die Integritätsbedingung 

unique (A 1 ,…,A n ) angegeben. 

� not null sagt aus, dass das Attribut explizit belegt werden muss. Es dürfen keine Null-Werte 

auftreten. 

� Durch primary key (A1 ,…,An ) wird festgelegt, dass die Attributmenge {A1 ,…,An } der 

Primärschlüssel der Relation ist. 

– Direkt hinter dem Attribut, wenn Primärschlüssel aus einem Attribut besteht. 

� Durch Angabe eines Defaultwertes wird beim Einfügen eines Tupels dieser Wert zur 

Initialisierung benutzt, wenn explizit keine Wertzuweisung vorgenommen wurde. 

Seite 109

Beispiel: 

– create table pmzuteilung( 

pnr int references Personal(pnr), 

mnr int references Maschinen(mnr), 

note int, 

constraint pk primary key (pnr,mnr)) 

Anmerkungen zu den Integritätsbedingungen 


� Ein Fremdschlüssel kann über die Integritätsbedingung references angegeben werden. Damit 

wird sichergestellt, dass das Tupel mit dem Schlüssel tatsächlich in der Relation (in unserem 

Beispiel ist das die Relation Personal) existiert. 

– Beim Einfügen eines neuen Tupels muss deshalb eine entsprechende Überprüfung 

stattfinden (was zu einem hohen Berechnungsaufwand führen kann). 

– Entsprechend muss beim Löschen eines Tupels aus einer Relation geprüft werden, ob eine 

Referenz auf dieses Tupel existiert. 

� Für eine Integritätsbedingung kann mit dem Schlüsselwort constraint ein Name definiert 

werden, mit dem man die Bedingung temporär außer Kraft setzten kann. 

Seite 110

Beispiel (komplett) 

� Alle Relationen der Datenbank werden dann durch folgende Befehle angelegt: 

– create table Maschinen(mnr int primary key, mname varchar(10)) 

– create table Personal(pnr int primary key, 

pname varchar(10) not null, 

vorname varchar(10), 

abtnr int references Abteilung(abtnr), 

lohn char(2) default 'L4') 

– create table leitet(pnr int primary key references Personal(pnr), 

abtnr int references Abteilung(abtnr)) 

– create table Abteilung(abtnr int primary key, aname varchar(10)) 

– create table pmzuteilung(pnr int references Personal(pnr), 

mnr int references Maschinen(mnr), 

note int, 

constraint pk primary key (pnr,mnr)) 

Anmerkungen 


� Das Schlüsselwort default wird benutzt, um Attribute eines Tupel mit einem initialen Wert zu 

belegen. 

Seite 111


Ändern/Löschen eines Relationenschemas 

Ändern 

alter table add 

Besonderheiten 

� Prinzipiell sind Syntax und Semantik solcher Befehle stark von dem jeweiligen 

Systemhersteller abhängig. 

Löschen 

drop table 

Seite 112

4.2 DML - Grundkonzepte 


� Anfragen an die Datenbank werden in der DML formuliert 

� Grundschema: 

select < Liste von Attributsnamen > z.B. select PName 

from < ein oder mehrere Relationennamen > from Personal 

[ where < Bedingung > ] where Lohn = 'L5' 

Bemerkungen: 

� Die select-Klausel entspricht der Projektion in der relationalen Algebra (und nicht der 

Selektion). 

� Die Bedingung nach der where-Klausel enthält 

1. Vergleichsoperatoren (, = ... ) 

2. Boolesche Operatoren (and, or , not) 

3. Mengenoperatoren (in, not in) und Quantoren (exists, any, some, all) 

� Attribute mit gleichen Namen, die zu verschiedenen Relationen gehören, werden mittels des 

Relationennamens unterschieden. 

Seite 113


4.2.1 Algebra-Operationen in SQL 

� Relation R 

select * 

from R 

Bei Angabe von “*” in der select-Klausel werden alle Attribute der Relation aus der from- 

Klausel ausgegeben. 

� Projektion 

select distinct A, C 

from R 

Ohne das Schlüsselwort distinct würde als Ergebnis eine M-Relation erzeugt werden. 

� Selektion 

�A�C �R� �B = b�R� 

select * 

from R 

where B = b 

Seite 114

� Kartesisches Produkt R�S select * 

from R, S 

� Theta-Join auf Relationen R(A,B) und S(C,D) 

R B�D S 


select * 

from R, S 

where B � D 

� Vereinigung der Relationen R(A,B) und T(A,B) 

select * from R 

union 

select * from T 

� Differenz der Relationen R und T 

select * from R 

except 

select * from T 

� Allgemeine Bedeutung der “select … from … where”-Klausel in der relationalen Algebra: 

select distinctA,B,C,.. 

� 

from R,S,T,... 

A,B,C,� 

�� F 

�R�S�T�� where F 

Seite 115

Duplikate und M-Relationen 


� Die gewöhnliche select-Klausel beseitigt keine Duplikate in der Ergebnisrelation. Dies ist aber 

durch Hinzufügen des Schlüsselworts distinct möglich: 

select distinct A, B, C, … 

from R,S,T,… 

where Bedingung 

Durch distinct wird als Ausgabe eine Relation erzeugt. Ansonsten wird eine M-Relation ausgegeben. 

� Die Differenz auf zwei Multi-Mengen entspricht der Semantik, wie wir sie bereits bei der 

erweiterten relationalen Algebra kennen gelernt haben. 

– Das Schlüsselwort minus wird nur von Oracle benutzt. In SQL92 gibt es stattdessen das 

Schlüsselwort except. 

– except all entspricht der Summendifferenz der erweiterten relationalen Algebra 

– SQL Server bietet eine solche Operation derzeit nicht an. Diese kann aber durch 

enstsprechende Prädikate in der where-Klausel implementieren werden. 

� Bei der Vereinigung auf Relationen werden automatisch Duplikate beseitigt. Dies gilt auch für 

M-Relationen. Sollen Duplikate nicht beseitigt werden, muss hinter dem Schlüsselwort union 

das Schlüsselwort all folgen. 

Seite 116

Beispielanfragen 

Welche Angestellten sind in der Lohngruppe L4 oder L5? 

select distinct PName 

from Personal 

where Lohn = 'L4' or Lohn = 'L5' 


Welche Angestellten können irgendwie die Maschine mit Nr. 84 bedienen? 

select distinct PName 

from Personal, PMZuteilung 

where Personal.pnr = PMZuteilung.pnr and mnr = 84 

Seite 117

4.2.2 From-Klausel 


� Innerhalb einer From-Klausel können auch Tupelvariablen definiert werden. 

… 

from PMZuteilung L /* L Ist eine Tupelvariable */ 

… 

� Damit kann man nun über die Tupelvariable L die Attribute in der Relation ansprechen. 

– Dadurch kann eine Art “Umbenennung” der Relation erfolgen. 

select distinct P1.pnr, P2.pnr, P1.Fähigkeit 

from PMZuteilung P1, PMZuteilung P2 

where P1.mnr = P2.mnr and P1.pnr < P2.pnr 

– Die Unterscheidung der Attribute erfolgt durch Verwendung der Punkt-Notation. Dies ist 

nur dann erforderlich, wenn der Attributname nicht eindeutig einer Relation zugeordnet 

werden kann. 

� In einer from-Klausel können nicht nur physische Relationen angegeben werden, sondern auch 

wiederum Anfragen - man spricht dann von Unteranfragen - auftreten: 

select L1.PName 

from (select PName, pnr from Personal where Lohn = 'L4') L1 

In diesem Fall muss eine Tupelvariable benutzt werden. 

Seite 118

Joins in der From-Klausel 


� Die Joinbedingung kann sowohl direkt in der from-Klausel als auch in der where-Klausel 

angegeben werden. Letzteres wird in allen DBMS unterstützt. 

� Natural Join /* Wird nicht von Interbase, SQL Server, … unterstützt */ 

… from R natural join S … 

oder 

… from R join S 

� �-Join 

(auch als inner join bezeichnet) 

… from R join S on A � B … 

� left outer join 

… from T left join S on A � B … 

� right outer join 

… from T right join S on A � 

B … 

Bemerkung 

� Der eigentliche Grund für diese Notation ist die Formulierung von äußeren Joins. 

Seite 119

4.2.3 Where-Klausel 


� In einer where-Klausel wird eine Boolesche Funktion angegeben, die im Wesentlichen einer 

Formel des Tupelkalküls entspricht. 

� Wir wollen zunächst einfache Formeln betrachten, die keine quantifizierten Teilformeln 

enthalten. 

Aufbau von einfachen Formeln 

� Einfache Formeln setzen sich aus Atomen der Form “A op B” zusammen, 

– Dabei steht op für ein Vergleichsoperator. 

– A und B stehen hier nicht nur für Attribute und Konstanten, sondern es können auch 

komplexere Ausdrücke sein. 

a) Bei numerischen Ausdrücken sind dies unter anderem die 4 arithmetischen 

Grundoperationen. Weiterhin kann hier auf die Vielzahl von im DBS angebotenen 

Operationen wie z. B. abs verwendet werden. 

b) Bei Zeichenketten umfaßt dies insbesondere die Verkettung “||”. 

� Atome können mit den Operatoren not, or und and zu komplexeren Formeln verknüpft werden. 

Seite 120

Weitere Varianten von atomaren Formeln: 


� Das Schlüsselwort and kommt nochmals als Bestandteil eines anderen Operators vor: 

– A between B and C 

– Diese Boolesche Funktion ist äquivalent zu B

Nullwerte 


� SQL benutzt zur Unterstützung von Nullwerten in Anfragen eine dreiwertige Logik. 

� Beispiel 

– Annahme: Es gibt ein Tupel (73, 101, NULL) in Relation PMZuteilung. 

– Sowohl select * from PMZuteilung where Fähigkeit > 2 

als auch select * from PMZuteilung where not Fähigkeit > 2 

� 

liefert uns nicht das Tupel als Ergebnis. 

Wir benötigen noch eine Möglichkeit, um Tupel mit Nullwerten zu finden. Dazu bedient man 

sich in SQL92 des Schlüsselworts is: 

– select * from PMZuteilung where Fähigkeit is null 

liefert die Tupel, deren Attribut Fähigkeit keinen Wert (also null) besitzt. 

Bemerkung 

� Man könnte auch ein relationales Modell ohne die Verwendung von NULL-Werten 

entwickeln. 

� NULL-Werte werden unterschiedlich in den kommerziellen DBMS verarbeitet. 

Seite 122

4.2.4 Select-Klausel 


� Die Select-Klausel wird als letztes bei der SQL-Anfrage ausgeführt. 

� Wurde eine Relation R berechnet, so werden durch 

select * … 

die Tupel mit allen Attributen der Relation R ausgegeben. 

� Entsprechend können alle Attribute einer am Join beteiligten Relation S durch 

select S.* from S,… where … 

ausgegeben werden. 

� Zur Wiederholung: select distinct beseitigt Duplikate, wohingegen select all dies nicht macht 

(select entspricht select all) 

Definition von Attributen im Ergebnis 

� Prinzipiell kann als Ergebnis in der select-Klausel ein Ausdruck stehen, der von mehreren 

Attributen abhängt. Man kann nun durch das Schlüsselwort as einer Spalte explizit einen neuen 

Namen zuweisen. 

select A*B as X from R 

Man kann dabei das Schlüsselwort as auch einfach weglassen. 

Seite 123

4.2.5 Aggregate 


� In SQL werden folgende Aggregatfunktionen angeboten: count, sum, avg, min und max. 

– Aggregate dürfen nur in der select-Klausel einer Anfrage auftreten. Man beachte, dass die 

select-Klausel zuletzt angewendet wird und dass zuvor eine Relation R als 

Zwischenergebnis bereits berechnet wurde. 

– Bei der Berechnung eines Aggregats wird eine Relation mit einem Tupel erzeugt. 

– Als Parameter eines Aggregats ist ein Ausdruck erlaubt. Das Aggregat count kann auch 

als Parameter einen “*” besitzen. Dann wird als Ergebnis die Anzahl der Tupel der 

Relation R geliefert. 

– Bei Angabe des Schlüsselworts distinct vor dem Ausdruck werden zunächst die Duplikate 

beseitigt, die durch Auswertung des Ausdrucks auf der Relation R entstehen. Danach wird 

das eigentliche Aggregat berechnet wird. 

� Die Aggregatfunktionen min, max und count können auf beliebige Ausdrücke angewendet 

werden. Die Funktionen sum und avg erwarten als Eingabe eine Zahl. 

– min bzw. max berechnet das Minimum bzw. das Maximum 

– count die Anzahl der Terme 

– sum berechnet die Summe aller Terme 

– avg berechnet den Durchschnitt über alle Terme. 

Seite 124

Beispiele 

� Wie viele Angestellte arbeiten in der Abteilung 'B10'? 

select count (pnr) 

from Personal 

where abtnr = 'B10' 

� Wie viele Angestellte mit verschiedenen Vornamen gibt es? 

select count (distinct Vorname) 

from Personal 


� Berechne die Anzahl der Angestellten, die Maschine 84 bedienen können, sowie deren 

durchschnittliche, minimale und maximale Fähigkeiten. 

select count(pnr), min(Fähigkeit), avg(Fähigkeit), max(Fähigkeit) 

from PMZuteilung 

where mnr = 84 

Seite 125

Nullwerte und Aggregate 


� Nullwerte werden bei der Berechnung eines Aggregats nicht berücksichtigt, mit Ausnahme 

von count(*). 

� Ist die Eingabe für das Aggregat leer, wird als Ergebnis null geliefert. Ausnahme ist wiederum 

count, das den Wert 0 zurückgibt. 

Seite 126

Gruppierung 

Allgemeinere Form der “select...from...where”-Klausel: 

select ..... from..... [where.....] 

[group by [,] *] 

[having < Bedingung>] 

[order by ] 

“group by”-Klausel 


� Diese wird nach der where-Klausel ausgeführt, aber noch vor der select-Klausel. 

� Zunächst werden anhand der Attribute in der Klausel Äquivalenzklasse gebildet. 

– Zwei Tupel sind in der gleichen Klasse, wenn diese bzgl. der in der Klausel spezifizierten 

Attribute gleich sind. 

� Pro Klasse wird dann durch die select-Klausel ein Tupel erzeugt. Die select-Klausel besteht 

dabei nur aus 

– Aggregaten, die dann auf die Gruppen angewendet werden. 

– Attributen, die bereits in der group_by-Klausel aufgetreten sind. 

Seite 127

Nullwerte 


� Wird für das group-by Attribut der Wert NULL angenommen, so wird eine entsprechende 

Gruppe eröffnet. 

“having”-Klausel 

� Filtern der durch die group_by-Klausel erzeugten Gruppen anhand einer Bedingung 

– Es dürfen nur Argumente mit einem Wert pro Gruppe auftreten. 

– Innerhalb einer having-Klausel sind Aggregate erlaubt (im Gegensatz zur where-Klausel) 

Beispiel: 

select mnr, avg(Fähigkeit) 


where Fähigkeit < 4 

group by mnr 

having count (*) > 4 

Seite 128

Order-By-Klausel: 

4.2.6 Geordnete Ausgabe 

order by A 1 [asc|desc] ,…, A n [asc|desc] 


� Durch diese Klausel wird die Ausgabe des SQL-Befehls sortiert ausgegeben, wobei die 

Sortierreihenfolge bzgl. den angegebenen Attributen erfolgt (absteigend: desc oder 

aufsteigend: asc). 

– Statt eines Attributs kann auch ein Ausdruck benutzt werden. 

– Sind mehrere Kriterien angegeben, so wird nach deren lexikographischer Ordnung 

sortiert. 

� Die order-by Klausel ist die letzte Klausel in einem SQL-Befehl. 

– Das Ergebnis der Klausel kann nicht weiterverarbeitet werden. 

� Null-Werte: 

Beim Sortieren wird null entweder stets als höchster oder kleinster Wert interpretiert 

(unabhängig ob asc oder desc angegeben wurde). 

– Welche der beiden Möglichkeiten gewählt wird, hängt vom zugrunde liegenden DBMS 

ab. 

Seite 129

Beispiele 


� Erstelle eine geordnete Liste aller Maschinen, in der für jede Maschine der minimale und der 

maximale Wert für die Fähigkeit der Angestellten angegeben sind! 

select mnr, min (Fähigkeit) as MinP, max (Fähigkeit) as MaxP 


group by mnr 

order by mnr 

� Welche Maschine kann von nur einem Angestellten bedient werden? 

select mnr 


group by mnr 

having count(*) = 1 

� Sortiere die Tupel aus PMZuteillung aufsteigend nach mnr und absteigend nach Fähigkeit! 

select * 


order by mnr, Fähigkeit desc 

Seite 130

4.2.7 Zusammenfassung 


� Eine SQL-Anfrage setzt sich aus folgenden Klauseln zusammen: 

select X 

from R r,S s,T t,... 

where F 

group by Y 

having G 

order by H 

� X eine Menge von Attributen 

– Optional können diese Attribute in der select-Klausel neu definiert und einen Wert eines 

Ausdrucks repräsentieren. 

� R,S,T,… eine Menge von Relationen und r,s,t,… eine Menge von Tupelvariablen 

– Tupelvariablen sind nur dann erforderlich, wenn statt einer Relation eine Unteranfrage 

angesprochen werden soll. 

� F eine Boolesche Formel 

� Y eine Menge von Attributen, wobei Y � 

X gilt. 

� G eine Boolesche Formel, die sich nur auf die Gruppen der group-by-Klausel bezieht. 

� H eine Liste von Attributen, die zum Sortieren des Ergebnis benutzt wird. 

Seite 131

4.3 Geschachtelte Anfragen 


� In einer SQL-Anweisung können in der 

– where-Klausel, 

– from-Klausel, 

– select-Klausel 

wieder SQL-Anweisungen auftreten. Man spricht dann auch von einer geschachtelten Anfrage 

oder Unteranfrage. 

� Bei Unteranfragen werden häufig Tupelvariablen benutzt. 

– Eine Tupelvariable wird in der from-Klausel deklariert und dabei einer Relation 

zugeordnet. 

– Tupelvariablen sind dann erforderlich, wenn die gleiche Relation mehrfach in einer 

Anfrage benutzt wird. 

Welche Angestellten können die gleiche Maschine bedienen? 

select distinct a1.pnr, a2.pnr 

from PMZuteilung a1, PMZuteilung a2 

where a1.mnr = a2.mnr and a1.pnr < a2.pnr 

Seite 132


Unteranfragen in der from-Klausel 

� Innerhalb einer from-Klausel kann statt einer Relation eine Unteranfrage benutzt werden. 

– Dann ist es ebenfalls möglich, eine Tupelvariable an diese Unteranfrage zu binden. 

� Bestimmte Anfragen lassen sich erst über solche Unterfragen formulieren: 

Beispiel 

– Wie viele Angestellte können eine Maschine im Durchschnitt bedienen? 

select avg(t.summe) 

from (select mnr, count(*) as summe from PMZuteilung group by mnr) t 

� Die having-Klausel kann dann sogar durch eine äquivalente where-Klausel ersetzt werden. 

Anfrage mit having-Klausel äquivalente Anfrage ohne having-Klausel 

select A, agg(B) as C select * 

from R from ( select A, agg(B) as C 

where FW from R 

group by A where FW 

having FH(C) group by A) t 

where FH(t.C) 

Seite 133


Unteranfragen in der select-Klausel 

� Einige Datenbanksysteme unterstützen auch Unteranfragen in der select-Klausel (z. B. SQL 

Server): 

– Damit ist es möglich nach einem Attribut zu gruppieren und gleichzeitig im Aggregat 

verschiedene where-Bedingungen zu berücksichtigen. 

– Beispiel: 

select pnr, 

(select count(*) from Personal A where A.pnr = B.pnr and Lohn < 'L5'), 

(select count(*) from Personal A where A.pnr = B.pnr and Lohn


Unteranfragen in der where-Klausel 

� In der where-Klausel wird dabei noch unterschieden, ob das Resultat der Unteranfrage einen 

skalaren Wert oder eine Relation zurückliefert. Wir betrachten zunächst den ersten Fall: 

Skalare Unteranfragen 

� Welche Maschinen, die von dem Angestellten mit Nr. 67 bedient werden können, kann dieser 

besser als im Durchschnitt bedienen? 

select mnr 


where pnr = 67 and Fähigkeit < ( select avg(Fähigkeit) 

from PMZuteilung) 

Skalare Unteranfragen mit Exists 

� In der where Klausel werden auch Unteranfragen erlaubt, die einen Booleschen Wert 

zurückliefern. Diese sind durch das Schlüsselwort exists gekennzeichnet. Dabei ist die 

Bedingung 

– exists 

wahr, falls die Unteranfrage nicht leer ist. 

Seite 135


� Welche Abteilungen haben Angestellten, die die Maschine 84 bedienen können? 

select distinct abtnr 

from Personal P 

where exists (select pnr 


where P.pnr = pnr and mnr = 84) 

Gültigkeit von Tupelvariablen in Unteranfragen 

� Bei dieser Unteranfrage wird Bezug genommen auf eine Tupelvariable, die in der äußeren 

Anfrage definiert wurde. Bei der Auswertung der Anfrage wird entsprechend so wie beim 

Tupelkalkül vorgegangen (“von außen nach innen”). Man spricht dann auch von einer 

korrelierten Unteranfrage. 

– Eine unkorrelierte Unteranfrage braucht nur einmal ausgewertet zu werden. Dagegen 

muss eine korrelierte Anfrage für jedes äußere Tupel ausgewertet werden. 

� Eine Tupelvariable ist in allen zugehörigen Unteranfragen gültig. Eine Redeklaration der 

gleichen Tupelvariable überdeckt die äußere Deklaration der Variablen. 

– Sucht man die Deklaration einer Tupelvariable geht man also von innen nach außen. Es 

wird die Deklaration benutzt, die zuerst gefunden wird (und alle anderen ignoriert). 

Seite 136

Mengenwertige Unteranfragen 


� Durch Verwendung vom Schlüsselwort in kann getestet werden, ob ein Attribut einen Wert in 

einer Menge annimmt (oder auch nicht) 

select pnr, PName 

from Personal 

where pnr in 

(select pnr from PMZuteilung) 

Wie kann die Anfrage formuliert werden, ohne dabei eine Unteranfrage zu benutzen? 

� Soll nun getestet werden, ob ein Attribut mit allen Elementen einer Menge in einer bestimmten 

Beziehung steht, kann das Schlüsselwort all benutzt werden. 

Suche für alle Maschinen die Angestellten mit den besten Fähigkeiten! 

select * 

from PMZuteilung L 

where Fähigkeit

Differenz durch Unteranfragen 


� Eine Differenz zwischen Relationen kann über except ausgedrückt werden (wird nicht von 

allen DBMS unterstützt) oder durch eine Unteranfrage mit not in und not exists. 

� Beispiele: 

Berechne alle Angestellten, die derzeit keine Maschine bedienen können. 

select * 

from Personal 

where pnr not in (select pnr from PMZuteilung) 

oder 

select * 

from Personal P 

where not exists (select pnr from PMZuteilung where pnr = P.pnr) 

Seite 138

Allquantifizierte Anfragen 


� Da �x��x��x��x��, können alle Anfragen mit einem Allquantor in äquivalente 

Anfragen umgeformt werden, die nur noch Existenzquantoren besitzen. 

� Welche Angestellte können alle Maschinen bedienen, die Angestellter 114 bedienen kann? 

– Anfrage im Tupelkalkül ? 

– Anfrage in SQL 

select distinct pnr 

from PMZuteilung L 

where not exists( select mnr 


where pnr = 114 and 

not mnr in ( select mnr 


where pnr =L.pnr)) 

Seite 139

Anfrage: 


Allquantifizierte Anfragen mit count 

� Welche Angestellte können alle Maschinen bedienen? 

select pnr 


group by pnr 

having count(*) = (select count(*) from (select distinct mnr from PMZuteilung) t) 

Seite 140


4.4 Ändern einer Relationeninstanz 

� Tupelweises Einfügen: 

insert 

into [( [, ] * )] 

values ( [, Konstante] * ) 

oder mengenweises Einfügen 

insert 

into [( [, ] * )] 

select ... from ... where .... 

� Löschen: 

delete 

from 

[where ] 

� Verändern: 

update 

set = [, = ] * 

[where ] 

Seite 141

Beispiele 


� Füge den Angstellten 51 ein, dass er/sie die Maschine 84 mit Fähigkeit 2 bedienen kann. 

insert into PMZuteilung (pnr, mnr, Fähigkeit) 

values (51, 84, 2) 

� Verbessere die Fähigekeiten des Angestelllten 114 um 1! 

update Fähigkeit 

set Fähigkeit = Fähigkeit - 1 

where pnr = 114 and Fähigkeit > 1 

Seite 142

Motivation 

Rekursion 


� In unserer Datenbank können Angestellte Vorgestzte für andere Angestellte sein. Daraus ergibt 

sich eine Hierarchie von Vorgesetzten; das ist in der Praxis sehr oft der Fall! 

� Folgende Anfrage soll dann unterstützt werden: 

Berechne alle Vorgesetzten, der Angestellten mit Lohngruppe L6. 

select L.pnr 

from Personal P, Abteilungsleiter L 

where P.Abt = L.abtnr and P.Lohn = ’L6’ 

Jetzt sollen noch die potentiellen Vorgesetzten der Vorgesetzten berechnet werden: 

select L.pnr 

from Personal P, Abteilungsleiter L 

where P.Abt = L.abtnr and 

P.pnr in (select L.pnr from Personal P, Abteilungsleiter L 

where P.Abt = L.abtnr and P.Lohn = ’L6’) 

� Die Berechnung aller direkten und indirekten potentiellen Vorgesetzten kann mit den bisher 

vorgestellten Mitteln jedoch in SQL nicht formuliert werden. 

Seite 143

Rekursion in Oracle 


� Erst im SQL3-Standard wurden Möglichkeiten geschaffen, rekursive Anfragen zu formulieren. 

– Wir werden später noch auf die spezielle Syntax von SQL 3 eingehen. 

� Zuvor gab es für spezielle rekursive Anfragen verschiedene Insellösungen von den Herstellern, 

wie z. B. eine Tiefensuche in Oracle: 

– In der Klausel start with wird der Ausgangspunkt der Tiefensuche angegeben, in unserem 

Fall: P.Lohn = ’L6’ 

– Hinter der Klausel connect by wird angegeben, wie bei der Tiefensuche der Vorgänger 

mit dem Nachfolger (über das Schlüsselwort prior) verbunden wird. 

In Oracle könnte dann obige Anfrage folgendermaßen formuliert werden: 

select L.pnr 

from Abteilungsleiter L join Personal P on L.abtnr = P.Abt 

connect by P.Abt = prior L.pnr 

start with P.Lohn= ’L6’ 

Seite 144

Indexe 

4.5 Anlegen anderer Strukturen 


� Indexe sind Bestandteile der physischen Ebene. Sie dienen “nur” zur Verbesserung der 

Anfragezeit und haben keinen Einfluss auf die Anfragesemantik. 

– Maß für die Effizienz in Datenbanken: Anzahl der Plattenzugriffe 

� Ein Index ist eine Instanz einer Indexstruktur. 

– In kommerziellen Systemen gibt es folgende Indexstrukturen: 

B+-Bäume und Hashverfahren. 

– B+-Bäume garantieren ähnlich wie AVL-Bäume logaritmische Zugriffskosten, sind aber 

im Gegensatz zu AVL-Bäume für die Indexierung von Daten auf dem Externspeicher 

entwickelt worden. 

– Eine detaillierte Diskussion der Beschreibung der Indexstrukturen erfolgt in Kapitel 

“Physische Datenorganisation” auf Seite 302. 

� Ein Index bezieht sich auf ein Attribut, bzw. eine Folge von Attributen 

– Bei mehreren Attributen werden diese lexikographisch miteinander verknüpft. 

Seite 145

Anlegen eines Index 

create [unique] index on 

( [] [,[]] * ) 

::= Asc | Desc 


� unique: Für alle Attributsnamen sind keine zwei Tupel mit gleichen Werten in diesem Attribut 

erlaubt � 

Schlüsselbedingung ist erfüllt. 

� In Datenbanksystemen, wie z. B. Oracle, können noch weitere Optionen beim Erzeugen von 

Indexen angegeben werden. 

– Ein Clusterindex bestimmt die physische Ordnung der Daten. 

– Ein “gewöhnlicher” Index hat keinen Einfluss auf die Ordnung. Man spricht dann auch 

von einem Sekundärindex. 

Beispiel: 

create unique index PersonalIndex on Personal (PName,Vorname) 

Löschen eines Index 

drop index 

Seite 146

Sichten 


� Sichten entsprechen den externen DB-Schemata. 

� In relationalen Systemen werden Sichten als (abgeleitete) Relationen aufgefasst, die durch 

Anfragen definiert werden. 

Sichten anlegen: 

create view [([,] *)] as [with check 

option] 

Beispiel: 

create view Top_PMZuteilung as 

select * from PMZuteilung where Fähigkeit < 3 

with check option 

Sichten löschen: 

drop view 

Seite 147


Änderungsoperationen und Sichten 

� Prinzipiell ist es möglich Datensätze auch in eine Sicht einzufügen. 

– entsprechend auch zu löschen und zu ändern 

� Durch das Schlüsselwort with check option können nur Datensätze in eine Sicht eingefügt 

werden, die bei einer Suche auf der Sicht auch wieder gefunden werden können. 

– Dies ist die einzig sinnvolle Variante einer View. 

� Beim Einfügen eines Tupels in einer Sicht müssen die Basisrelationen angepasst werden. die 

zur Definition der Sicht benutzt wurden. 

– In einer Sicht werden keine Daten gespeichert! 

� Die Zuordnung zu den Basisrelationen ist aber nicht immer möglich! 

– z. B. wenn ein Attribut einer Sicht durch eine Aggregatfunktion berechnet wird. 

� Sichten sind in Oracle / Interbase veränderbar, wenn folgende Bedingungen gelten: 

– keine Aggregatfunktionen 

– keine Anweisungen mit distinct, group by, having, union und minus 

– from-Klausel enthält nur eine Relation 

– ein Schüssel der Basisrelationen muss in der select-Klausel enthalten sein. 

� Es gibt aber durchaus veränderbare Sichten, die aber nicht alle vier der oben genannten 

Bedingungen, erfüllen. 

Seite 148

Integritätsbedingungen 

4.6 Datenintegrität 


� Einschränkung der Datenbankzustände auf diejenigen, die tatsächlich nur in der realen Welt 

existieren können. 

� Integritätsbedingungen sind aus dem erstellten Datenmodell ableitbar (semantisch) und können 

deshalb bei der Erstellung des Schemas bereits angegeben werden. Folgende Vorteile ergeben 

sich: 

– Einmalige Angabe der Konsistenzbedingungen 

– Keine lästige Überprüfung der Konsistenzbedingungen durch die AWPs 

– Verzögerte Überprüfung der Integritätsbedingungen aus Effizienzgründen, z. B. bei einer 

Masseneingabe von Daten 

Zwei Klassen von Integritätsbedingungen 

� statische Bedingungen 

– sind definiert bzgl. Datenbankzuständen 

� dynamische Bedingungen 

– sind definiert bzgl. Zustandsänderungen 

Seite 149

4.6.1 Schlüssel 

Schlüssel in einer Relation (mittels primary key) 


� Syntax 

– Wenn der Schlüssel nur ein Attribut umfasst, kann primary key direkt an das Ende der 

Attributdeklaration geschrieben werden. 

– Wenn der Schlüssel mehrere Attribute umfasst, gibt es eine eigene Klausel 

primary key (A1 ,…,An ) 

– Es gibt höchstens einen Primärschlüssel in einer Relation. 

� Semantik 

– Die als Primärschlüssel spezifizierten Attribute sind eindeutig. 

– Die Attribute dürfen nicht den Wert null annehmen. 

Schlüssel (mittels unique) 

� Syntaktisch wird nun das Schlüsselwort unique benutzt. 

� Semantik (SQL´92) 

– Im Gegensatz zum Primärschlüssel ist der Wert null bei unique-Attributen erlaubt. 

– Es können mehrere Tupel existieren, die im unique-Attribut den Wert null besitzen. 

Seite 150

4.6.2 Fremdschlüssel 


� Damit bezeichnet man Attribute, die zur Modellierung einer Beziehung benutzt werden. 

� Semantik: 

Seien R und S Relationen mit dem Schema RSR und RSS . Sei K ( � RSR ). Schlüssel von R 

(gekennzeichnet durch primary key). Dann wird F � 

RSS Fremdschlüssel von S genannt, 

falls zu jedem Datensatz s aus der Relation S eine der folgenden Bedingungen gilt: 

– s[F] = NULL 

– es gibt einen Datensatz r aus R, so dass s[F] = r[K] gilt. 

� Mögliche Probleme, wenn referentielle Integrität nicht erfüllt ist: 

– Angstelle arbeitet in einer Abteilung, die es nicht gibt. 

– Angestellte sind an Maschinen ausgebildet, die nicht existieren. 

� Definition einer Fremdschlüsselbedingung: 

KNr muss bereits in der Relation Personal vorher als Primärschlüssel oder mit dem Schlüsselwort 

unique gekennzeichnet worden sein. 

– create table PMZuteilung (pnr int,,…, 

foreign key(pnr) references Personal(pnr)) 

oder 

Seite 151

– create table PMZuteilung(pnr int references Personal(pnr), …) 

oder 

– create table PMZuteilung(pnr int,,…, 

FK_PNR foreign key(pnr) references Personal(pnr)) 


In diesem Fall wird die Bedingung mit dem Namen FK_PNR versehen, was insbesondere 

die Performance bei Änderungsoperationen verbessern kann. 

Seite 152


Einhaltung referentieller Integrität 

� In einer Relation, die eine Beziehung modelliert, sollte gewährleistet sein, dass die 

Fremdschlüssel mit Werten belegt sind. 

� Relationale Algebra: 

– Relation R mit Primärschlüssel K 

– Relation S mit Fremdschlüssel F (bezieht sich auf K) 

� 

F 

�S�� K 

�R� � Erlaubte Änderungen 

– Einfügen eines Tupels s in S, wenn sF � � � � 

K 

�R� – Verändern eines Attributwerts eines Tupels s aus S, wenn … 

– Verändern von rK � � eines Tupels r aus R, wenn � 

F = r�K� �S� = 

� 

– Löschen eines Tupels r aus R, wenn … 

Seite 153


Überwachung der referentiellen Integrität 

Defaulteinstellung 

� Löschen eines Tupels r aus einer Relation R ist i.A. nicht möglich, falls es noch Tupel aus 

anderen Relationen gibt, die über einen Fremdschlüssel an r gebunden sind. 

Kaskadierendes Löschen/Ändern 

� Wenn ein Tupel r aus einer Relation R gelöscht/geändert wird, können auch Datensätze aus 

anderen Relationen automatisch gelöscht/geändert werden, die sich über einen Fremdschlüssel 

auf das Tupel r beziehen. 

� Bei der Definition des Fremdschlüssels kann diese Einstellung mit aufgenommen werden: 

Setzen auf Null 

� Wird ein Tupel gelöscht, wird der Wert aller davon abhängigen Attribute auf null gesetzt. 

� create table PMZuteilung( 

pnr int constraint fk_personal references Personal(pnr) 

on delete cascade) 

on update set null, 

… 

) 

Seite 154

4.6.3 Zeitpunkt der Überprüfung 


� In SQL gibt es noch die Möglichkeit den Zeitpunkt der Überprüfung einer 

Integritätsbedingung zu beeinflussen. 

� Motivation 

– Eine Integritätsbedingung gewährleistet, dass die durchschnittlichen Fähigkeiten eines 

oder aller Angestellten genügend gut ist. 

� Anforderung 

– Bündelung von mehreren Operationen zu einer Einheit (Transaktion) 

– Überprüfung der Integritätsbedingung nur am Beginn / Ende einer Transaktion 

� Eine Integritätsbedingung kann nun mit folgenden Schlüsselworten versehen werden: 

– not deferrable: Die Integritätsbedingung wird sofort hinter einer Änderung überprüft. 

– deferrable: Es besteht jetzt die Möglichkeit der verzögerten Überprüfung. 

– deferrable initially deferred: Überprüfung erfolgt am Ende der Transaktion. 

– deferrable initially immediate: Überprüfung vor der Änderung. 

� Eine mit dem Schlüsselwort deferrable versehene Bedingung mit einem Namen, sagen wir 

einfach MeineBedingung, kann noch zur Laufzeit angepasst werden: 

– set constraint MeineBedingung deferred 

– set constraint MeineBedingung immediate 

Seite 155


4.6.4 Statische Integritätsbedingungen 

Attributsbezogene Bedingungen 

� Diese Bedingungen beziehen sich auf ein Attribut einer Relation. 

– Die Überprüfung dieser Bedingungen findet immer dann statt, wenn das Attribut durch 

eine Änderung betroffen ist. Dies sorgt aber nicht dafür, dass auch tatsächlich die 

Bedingung stets erfüllt bleibt (wenn z. B. die Bedingung noch von einem anderen Attribut 

oder einer anderen Relation abhängt). 

� Ausschluss von Nullwerten 

create table Personal (pnr int primary key, PName char(20) not null, …) 

– Wert des entsprechenden Attributs muss bei jedem Tupel vorliegen. 

� Check-Bedingungen 

– sind beliebig komplexe Bedingungen, die ähnlich zu einer where-Klausel von SQL 

angegeben werden können. Dabei kann man sich direkt auf das Attribut beziehen. 

– Beispiel: 

create table Personal( pnr int primary key, PName char(20) 

check(100 > (select count(*) from Personal A where A.PName = PName)), 

… 

) 

Seite 156

Relationsbezogene Bedingungen 


� Einschränkung der Werte, die ein Tupel bzgl. seiner verschiedenen Attribute annehmen darf. 

– Diese Bedingungen werden immer dann überprüft, wenn ein Tupel in die Relation 

eingefügt wird oder ein bestehendes Tupel sich ändert. 

� In SQL kann eine relationsbezogene Bedingung durch die check-Klausel beim Anlegen des 

Schemas angegeben werden. 

– In der Bedingung kann man sich auf alle Attribut der zugehörigen Relation beziehen. 

� Die Deklaration einer solchen Bedingung erfolgt direkt bei der Deklaration der Relation oder 

zu einem späteren Zeitpunkt. 

Beispiel: 

– Stelle sicher, dass die durchschnittliche Fähigkeit nicht schlechter als 3 ist. 

alter table PMZuteilung add check(3 < (select avg(Fähigkeit) from PMZuteilung)) 

Seite 157


4.6.5 Verwalten von Integritätsbedingungen 

� Integritätsbedingungen können in SQL durch Verwendung des Schlüsselworts constraint 

implementiert und dabei mit einem Namen versehen werden. 

Hinzufügen/Löschen von Integritätsbedingungen 

� alter table PMZuteilung 

add constraint plus_const check (Fähigkeit < 1) 

– Dies ist stets eine Relationen-Bedingung. Ein Hinzufügen von Attribut-Bedingungen ist 

nicht möglich. 

� alter table Personal 

add constraint name_unique unique PName 

� alter table drop constraint 

– Löschen wird für beliebige Bedingungen unterstützt. 

Seite 158


Datenbankbezogene Bedingungen 

� Hierbei handelt sich um die mächtigste Form von Integritätsbedingungen. 

create assertion check 

– Die Deklaration erfolgt außerhalb einer Deklaration einer Relation. 

– Die Überprüfung der Bedingung bei Änderung einer der beteiligten Relationen. 

– Leider werden diese Bedingungen nur von wenigen Systemen unterstützt. 

� Im Gegensatz zu den vorherigen check-Klauseln gibt es nicht die Möglichkeit sich direkt auf 

ein Attribut einer Relation zu beziehen. 

Vergleich von verschiedenen Bedingungen 

Typ Ort der Deklaration 

Auslösen der 

Überprüfung 

Attributsbezogene Attribut Einfügen in die Relation 

Bedingung 

Ändern des Attributs 

Relationsbezogene Relationenschema Einfügen in die Relation 

Bedingung 

Ändern eines Tupels 

Datenbankbezogene Datenbankschema Änderung einer der 

Bedingung 

beteiligten Relationen 

Unteranfragen 

Nein 

Nein 

Ja 

Seite 159

Trigger-Konzept 


� Zusätzlich können komplexe Integritätsbedingungen auch über so genannte Trigger 

spezifiziert werden. 

– Trigger werden bereits seit langem von verschiedenen Herstellern angeboten, wobei diese 

erst mit SQL3 standardisiert wurden. 

– Im Gegensatz zu Assertion können mit einem Tigger auch dynamische 

Integritätsbedingungen definiert werden. 

� Da das Trigger-Konzept mit einer prozeduralen Erweiterung (PL/SQL) Hand in Hand geht, 

verschieben wir eine detaillierte Diskussion auf ein späteres Kapitel. 

Seite 160

Entwurfstheorie relationaler Datenbanken 

5. Entwurfstheorie relationaler Datenbanken 

� Wie sieht ein gutes konzeptionelles Schema der Datenbank aus? 

� Wie kann die Güte eines Datenbankschemas beurteilt werden? 

� Beispiel: 

– erstes Schema: 

Kunde(KName, KAdr, Kto) 

Auftrag(KName, Ware, Menge) 

LieferantW(LName, LAdr, Ware, Preis) 

– alternatives Schema: 

KundenAdr(KName, KAdr) 

KundenKto(KName, Kto) 

Auftrag(KName, Ware, Menge) 

Lieferant(LName, LAdr) 

Angebot(LName, Ware, Preis) 

Seite 162

Beispiel: LieferantW (LName, LAdr, Ware, Preis) 


1. Redundanz: 

Für jede Ware wird die Adresse des Lieferanten gespeichert. 

2. Änderungs-Anomalien (mögliche Inkonsistenzen): 

Man kann die Adresse eines Lieferanten in einem seiner Tupel ändern, in einem anderen 

jedoch unverändert lassen. 

3. Einfüge-Anomalien: 

Man kann keine Lieferantenadresse ohne eine Ware einfügen. 

4. Entfernungs-Anomalien: 

Beim Löschen der letzten Ware geht auch die Lieferantenadresse verloren. 

Verbesserung (?): 

Lieferant(LName, LAdr) 

Angebot(LName, Ware, Preis) 

Vorteil: 

� Keine Redundanz und keine Anomalien und somit niedrige Kosten bei Änderungen der Daten 

Nachteil: 

� Bei Anfragen sind zusätzliche Joinoperationen erforderlich und somit höhere Anfragekosten 

Finde die Adresse der Lieferanten, die eine Ware liefern können. 

Seite 163

Verbesserung ? 

Lieferant(LName, LAdr,Ware) 

Angebot(Ware, Preis) 

vorher: 

nachher: 

Zusammenfügen durch Join ergibt: 

LieferantW LName LAdr Ware Preis 

Michl München Milch 1,10 

Kohl Frankfurt Milch 1,30 

Keller Stuttgart Mehl 2,30 

Lieferant LName LAdr Ware 

Michl München Milch 

Kohl Frankfurt Milch 

Keller Stuttgart Mehl 

LieferantW LName LAdr Ware Preis 





Keller Stuttgart Mehl 2,30 


Angebot Ware Preis 

Milch 1,10 

Milch 1,30 

Mehl 2,30 

Seite 164

Entwurfsziele 

� Vermeidung von Redundanzen und Anomalien 

� Vermeidung der Probleme bei der Informationsrepräsentation 

� Vermeidung des Informationsverlusts 

� evtl. Einbeziehung von Effizienzüberlegungen 

Grundlage: 

– DB-Schema + “funktionale Abhängigkeiten” (Definition folgt) 

Vorgehen: 


– Zerlegen des gegebenen Datenbank-Schemas in ein äquivalentes Schema ohne 

Redundanz und Anomalien (“Normalisierung”). 

Seite 165


5.1 Funktionale Abhängigkeiten 

� statische Integritätsbedingungen: 

– Bedingungen an die zugelassenen Ausprägungen des Datenbankschemas 

� Funktionale Abhängigkeiten (FDs) = spezielle Integritätsbedingungen 

– FD steht für “functional dependency” 

� im Folgenden: R bezeichnet eine Relation, RSR das Schema und IR die Instanz 

Def. (funktionale Abhängigkeit): 

Sei R eine Relation und A sowie B Teilmengen des Relationenschemas RSR ( A�B�RSR). B ist von 

A funktional abhängig oder A bestimmt B funktional, geschrieben A�B, gdw. zu jedem Wert in 

A genau ein Wert in B gehört: 

A�B��IR�t1�t2�IR : t1�A� = t2�A��t1�B� = 

t2�B� � Beachte: Funktionale Abhängigkeit ist abhängig von der Semantik des Schemas, nicht von der 

Instanz einer Relation! 

Seite 166

Beispiel: 


� Lieferant(LName, LAdr, Ware, Preis) 

� Funktionale Abhängigkeiten: 

1. {LName} � {LAdr} (ein Lieferantenname bestimmt eindeutig seine Adresse) 

2. {LName, Ware} � {Preis} 

(der Schlüssel {LName, Ware} bestimmt eindeutig den Preis) 

3. {LName} � {LName} (trivial) 

4. {LName, Ware} � {Ware} (trivial) 

5. {LName, Ware} � {LAdr} (partiell) 

Eine Abhängigkeit A�B ist trivial, wenn gilt: B�A Def. (voll, partiell, transitiv): 

Eine Abhängigkeit A�B heißt voll, wenn es keine echte Teilmenge C�A gibt, so dass gilt: 

C�B. Gibt es eine solche Teilmenge, dann heißt A�B partielle Abhängigkeit. 

Seien A und B Attributsmengen aus RS ( A�B�RS) und gelte A�B und A � B. 

Sei X�RS ein 

Attribut mit X�A�B und gelte B�X. Dann ist X transitiv abhängig von A: A � 

X 

Seite 167

Berechnung von FDs 


� Wunsch: 

Zu einer gegebenen Menge F von FDs sollen alle gültigen FDs berechnet werden. 

� F + ist die Menge aller FDs, die aus den funktionalen Abhängigkeiten in F ableitbar sind. F + 

wird auch als Hülle von F bezeichnet. 

� Seien RS ein Relationenschema, F eine Menge von FDs und ABC � � � RS. 

Zur Berechnung von F + werden folgende Regeln genutzt (Armstrong Axiome): 

– Reflexivität: Sei B�A. Dann gilt stets A � B (Sonderfall: A�A) – Verstärkung: Falls A�B gilt, dann gilt auch A�C�B�C. – Transitivität: Falls A � B und B � C, 

dann gilt auch A�C � Es kann gezeigt werden, dass die Regeln korrekt und vollständig sind. 

– abgeleitete Regeln sind für alle Relationen des Schemas gültig 

– alle gültigen FDs in F + sind mit Hilfe dieser Regeln auch herleitbar 

Seite 168


� Trotz dieser Eigenschaften der Amstrong-Axiome ist es komfortabler, noch folgende Regeln 

zu benutzen: 

– Vereinigungsregel: 

Falls A�B und A � C gilt, dann gilt auch A�B�C – Dekompositionsregel: 

Falls A�B�C gilt, dann gilt auch A�B und A�C – Pseudotransivität: 

Falls A�B und B�C�Dgilt, dann gilt auch A�C�D � Beispiel: 

– Lieferanten-Relationen Lieferant(LName, LAdr, Ware, Preis) 

– FDs 1-4 seien gültig (siehe oben) 

– zu zeigen: FD 5 {LName, Ware} � {LAdr} ist ebenfalls erfüllt. 

Es gilt {LName} � {LAdr}. 

Auf Grund des 2-ten Amstrong-Axiom gilt auch: 

{LName, Ware} � 

{LAdr, Ware} 

Wegen der Dekompositionsregel ergibt sich damit FD 5. 

Seite 169

Membership-Problem 


� Fragestellung: 

Sei F eine Menge von FDs und A�B eine funktionale Abhängigkeit. Gilt A�B F ? 

+ 

� 

� Explizite Berechnung von F + ist zu aufwendig 

� Stattdessen: Berechnung der Hülle A + der Attributmenge A bzgl. der Menge F 

– A + besteht aus allen Attributen, die von A funktional bestimmt werden 

– Falls B A gilt, dann gilt auch . 

+ 

� A � B F + 

� 

Algorithmus Hülle(F, A) 

Erg = A; 

WHILE (Änderungen an Erg) 

FOREACH DO 

IF ( ) THEN ; 

RETURN A + B�C�F B�Erg Erg = 

Erg � C 

= Erg; 

Seite 170

� Definition: 

Kanonische Überdeckung 


Zwei Mengen F und G von FDs einer Relation R sind äquivalent, falls F + = G + gilt. 

� Wunsch: Berechne eine möglichst kleine Menge, die zu F äquivalent ist. 

– wenig Aufwand beim Testen, ob ein neues Tupel eine FD verletzt. 

� Fc wird als kanonische Überdeckung von F bezeichnet, falls folgende Bedingungen erfüllt 

sind: 

+ 

– Fc = F + 

– Für alle FDs A�B in Fc gibt es keine “überflüssigen” Attribute, d. h. 

für alle Attribute X�A gilt �F c 

– �A�B��A– �X�� B�� 

. 

für alle Attribute gilt . 

– Jede linke Seite der FDs in Fc kommt nur einmal vor, d. h. 

+ F + 

� 

Y � B �F c 

– �A�B��A��B – �Y�� + F + 

� 

falls A�B und A�C, dann wird in Fc nur die FD A�B�C verwendet. 

Seite 171

Berechnung der kanonischen Überdeckung 

1. Führe für jede FD A � B � F die Linksreduktion durch: 

Überprüfe für alle X�A, ob das Attribut X überflüssig ist, d.h. ob 

B � Hülle�FA � – �X�� gilt. Ist dies der Fall, ersetze A�B durch A– �X��B. Entwurfstheorie relationaler Datenbanken 

2. Führe für jede verbliebene FD A�B � F die Rechtsreduktion durch, d. h. 

Überprüfe für alle Y�B , ob das Attribut Y überflüssig ist, d. h. 

Y � Hülle�F– �A�B� � �A�B– �Y��A� gilt. Ist dies der Fall, dann wird A�B durch A�B– �Y� ersetzt. 

3. Entferne die FDs der Form A � � (die im 2-ten Schritt entstanden sind) 

4. Ersetze alle FDs der Form A�B1, A�B2, …, A�Bkdurch A�B1� B2 � … � Bk Seite 172

Beispiel: 

� Menge F = { A�B, B�C, A � B � 

C } 

� Schritt 1: 





Seite 173

Zerlegung einer Relation 


� Um Anomalien zu beseitigen, wird eine Relation R mit Schema RS R in n Relationen R 1 ,…,R n 

mit Schemata RS R1 , …, RS Rn zerlegt. 

� Folgende Eigenschaften sollen erfüllt werden: 

– Kein Informationsverlust, d.h. die Relation R muss aus den Relationen R1 ,…,Rn wieder 

rekonstruierbar sein. 

– Alle FDs, die für die Relation R gelten, sollen für R1 ,…,Rn effizient überprüfbar bleiben. 

� Informationsverlust (n=2): 

Eine Zerlegung der Relation R in R1 und R2 hat keinen Informationsverlust, wenn folgendes 

gilt: R = �RS1�R��RS2�R�. Satz 

Sei R eine Relation und FR die Menge der FDs. Eine Zerlegung von R in R1 und R2 hat keinen 

Informationsverlust, falls eine der folgenden Bedingungen gilt: 

+ 

– �RS � RS � RS ��F R1 R2 R1 R 

– 

�RS � RS � RS ��F R1 R2 R2 R 

+ 

Seite 174

Beispiel: 


� Die Zerlegung der Relation R(LName, LAdr, Ware, Preis) in die Relationen 

– Lieferant(LName, LAdr) 

– Lieferant(LName, Ware, Preis) 

+ 

ist verlustlos, da LName � LAdr eine FD aus FR ist. 

� Über die Zerlegung 

– Lieferant(LName, LAdr, Ware) 

– Angebot(Ware, Preis) 

können wir auf Grund des Satzes keine Aussage treffen, obwohl wir wissen, dass 

– Ware bestimmt nicht funktional den Preis 

– Ware bestimmt nicht funktional den LName (und damit auch nicht LAdr) 

gilt. Der Satz liefert uns nur eine hinreichende, aber keine notwendige Bedingung! 

Seite 175


Bewahrung funktionaler Abhängigkeiten 

� Wunsch: alle FDs, die für die Relation R gelten, sollen lokal auf den zerlegten Relationen 

R 1 ,…,R n überprüfbar sein (Effizienz !). 

� Formal kann dies wie folgt ausgedrückt werden: 

Dann wird die Zerlegung als hüllentreu bezeichnet. 

Beispiel: 

+ 

FR = 

�F��F� R1 Rn 

+ 

� Sei die Relation PV(Straße, Ort, BLand, PLZ) gegeben Es sollen folgende Bedingungen 

gelten: 

– Orte werden durch “Ort” und “BLand” eindeutig charakterisiert. 

– Innerhalb einer Straße ändert sich “PLZ” nicht. 

– PLZ-Gebiete gehen nicht über Ortsgrenzen, Orte nicht über Bundeslandgrenzen. 

� FDs: {PLZ} --> {Ort, BLand} und {Straße, Ort, BLand} --> {PLZ} 

� Welche Eigenschaften besitzt die Zerlegung {PLZ, Straße} und {PLZ, Ort, BLand}? 

Seite 176


5.2 Die ersten drei Normalformen 

� Durch Normalformen wird definiert, was unter einem guten Datenbankdesign zu verstehen ist. 

Def. (1. Normalform): 

Eine Relation ist in der 1. Normalform (NF), wenn alle Attribute nur atomare Werte, die nicht 

weiter zerlegbar sind, enthalten können. Dafür stehen Wertebereiche wie STRING, INTEGER etc. 

zur Verfügung. Mengen von Werten oder sonstige Strukturen (z. B.Tupel) sind nicht erlaubt. 

Beispiel (für eine Relation in NF2 ): 

� Vor- und Nachteile der Algebra für geschachtelte relationale Datenbanken 

(NonFirstNormalForm = NF 2 ) sind z.Zt. in der Diskussion 

� Beispiel:NF2 für Literatur (BÜCHER, AUTOR, STICHWORT) 

BÜCHER AUTOR STICHWORT 

B_1 Boyce Normalisierung 

Abhängigkeit 

B_1 Codd Normalisierung 

Abhängigkeit 

Seite 177


Def. (prim):Ein Attribut heißt prim, wenn es Teil eines Schlüsselkandidaten ist, sonst nicht prim. 


Eine Relation R ist in der 2. Normalform (2NF), wenn jedes Attribut A�RSRentweder prim oder 

von jedem Schlüsselkandidat voll funktional abhängig ist. 

Beispiel: 

� Leistungsnachweis (S#, K#, Titel, DName, Raum#, Note) 

� Tupel (s, k, t, d, r, n) bedeutet: Student s hat die Note n erzielt im Kurs mit Nummer k, der den 

Titel t trug und im Raum mit Nummer r vom Dozenten d abgehalten wurde. 

Folgende Abhängigkeiten bestehen: 

1. {S#, K#} � {Note} 

2. {K#} � {Titel} 

3. {K#} � {DName} 

4. {DName} � {Raum#} 

5. {K#} � {Raum#} 

Note 

S# 

K# 

Titel 

DName 

Raum# 

Seite 178


Die Relation ‘Leistungsnachweis’ ist nicht in 2NF. Folgende Anomalien können auftreten: 

• Informationen über einen neuen Kurs sind nur dann verfügbar, wenn bereits ein Student 

für diesen Kurs eingetragen ist. 

• Dozent ist nur dann in der Datenbank, wenn er/sie einen Kurs hält 

• Namensänderung eines Kurses ist sehr aufwendig (1 Update pro Student) 

• Falls alle Studenten den Kurs 27 verlassen und die dazugehörigen Tupel gelöscht 

werden, verschwinden alle Informationen über den Kurs. 

� Transformation in 2NF behebt diese Anomalien: 

– Aufspalten der Relation ‘Leistungsnachweis’ in folgende zwei Relationen: 

– Schema in 2NF: 

Leistungsnachweis (S#, K#, Note) 

Kurs (K#, Titel, DName, Raum#) 

Bemerkung: 

� 2NF kann nur dann verletzt werden, wenn Schlüsselkandidaten zusammengesetzt sind. 

� Partielle funktionale Abhängigkeiten nicht-primer Attribute vom Schlüssel werden beseitigt. 

� 2NF spielt in der Normalisierungstheorie jedoch kaum mehr eine Rolle. 

Seite 179



Eine Relation R ist in der 3. Normalform (3NF), wenn für alle Abhängigkeiten X�A mit 

X�RSR�A�RSR�A�X gilt: 

• X enthält einen Schlüssel von R, oder 

• A ist prim. 

� Die Relation ‘Kurs’ ist nicht in 3NF, da die Abhängigkeit DName � 

Raum# 

DName weder Schlüssel noch Raum# prim ist. 

Folgende Anomalien können auftreten: 

besteht und 

– Informationen über Dozenten und Raum sind ohne Zuordnung eines Kurses nicht 

verfügbar 

– Ändern der Raumnr. eines Dozenten bedingt die Änderung für jeden Kurs 

– Falls ein Dozent keinen Kurs gibt, werden alle Informationen über den Dozent 

und seinen Raum aus der Datenbank gelöscht. 

Schema in 3NF: 

Leistungsnachweis (S#, K#, Note) 

Kurs (K#, Titel, DName) 

Dozent (DName, Raum#) 

� Hinweis:Die 3. Normalform beseitigt Abhängigkeiten von Nicht-Schlüssel-Attributen. 

Seite 180

5.3 Synthesealgorithmus 


� Ziel ist die Zerlegung einer Relation R mit funktionalen Abhängigkeiten F in Relationen 

R 1 ,…,R n , so dass folgende Bedingungen erfüllt sind: 

– kein Informationsverlust, 

– Bewahrung der funktionalen Abhängigkeiten, 

– Relationen R1 ,…,Rn erfüllen die dritte Normalform. 

� Folgender Algorithmus generiert eine solche Zerlegung: 

1. Bestimme die kanonische Überdeckung Fc der Menge F. 

2. Führe für jede FD A�B�Fcfolgende Anweisungen aus: 

– Erzeuge ein Relationenschema RSA = A�B und ordne RSA die FDs FA = 

�C�D � Fc C�D � RSA� 3. Falls alle der in Schritt 2 erzeugten Schemata keinen Kandidatenschlüssel der 

ursprünglichen Relation R enthalten, so erzeuge zusätzlich eine Relation mit dem Schema 

RSK = K und FK = � 

, wobei K ein Kandidatenschlüssel von R ist. 

4. Eliminiere die Schemata R, die in einem anderen Schema enthalten sind. 

Seite 181

Beispiel: 

� Relationenschema ProfessorenAdr: 

PersNr, Raum, Rang, Name, Straße, Ort, BLand, Landesreg., PLZ, Vorwahl 

Annahmen: 

� Ort ist der Erstwohnsitz des Profs 

� Landesregierung ist die Partei der 

Ministerpräsidentin 

� Ortsnamen sind eindeutig innerhalb 

der Bundesländer 

� PLZ ändert sich nicht innerhalb einer 

Straße 

� Städte und Straßen liegen vollständig 

in Bundesländern 

� ein Prof hat genau ein Büro (und er 

teilt es nicht) 

PersNr 

Raum 


Rang 

Name 

Straße 

Ort 

BLand 

Landesregierung 

PLZ 

Vorwahl 

Seite 182

1-ter Schritt: Berechnung einer kanonischen Überdeckung 

� FD1 {PersNr} � {Raum, Name, Rang, Straße, Ort, BLand} 

� FD2 {Raum} � {PersNr} 

� FD3 {Sraße, Ort, Bland} � {PLZ} 

� FD4 {Ort, BLand} � {Vorwahl} 

� FD5 {BLand} � {Landesregierung} 

� FD6 {PLZ} � 

{Ort, BLand} 

2-ter Schritt: 

� aus FD 1 ergibt sich: 

– {PersNr, Name, Rang, Raum, Straße, Ort, Bland} 

– FD1 und FD2 werden zugeordnet 


– {Straße, Ort, Bland, PLZ} 

– FD3 und FD6 werden zugeordnet 


Seite 183

� aus FD 4 ergib sich: 

– {Ort, BLand, Vorwahl} 

– FD4 wird zugeordnet 


– {BLand, Landesregierung} 

– FD5 wird zugeordnet 


Schritt 3: 

� {PersNr} ist Kandidatenschlüssel des ursprünglichen Schemas und befindet sich in einem 

Relationenschema. 

Schritt 4: 

� ist schon im Schritt 2 passiert 

Seite 184

5.4 Boyce-Codd Normalform 


Def. (Boyce/Codd-NF):Eine Relation R ist in Boyce/Codd-Normalform (BCNF), wenn für alle 

Abhängigkeiten X�A mit X�RSR�A � RSR�A�X gilt: 

• X enthält einen Schlüssel von R 

� Die Boyce/Codd-Normalform beseitigt Abhängigkeiten unter Attributen, die prim sind. 

Beispiel: Autoverzeichnis (Hersteller, HerstellerNr, ModellNr) 

� Folgende Abhängigkeiten bestehen: 

– Hersteller � HerstellerNr(1:1-Beziehung zwischen Hersteller und HerstellerNr) 

– HerstellerNr � 

Hersteller(s.o.) 

� Beispiel ist in 3NF (alle Attribute sind prim), aber nicht in BCNF 

� Folgende Anomalien können auftreten: 

– Einfügen des selben Herstellers mit verschiedenen Herstellernr. ist möglich 

– 1:1-Beziehung von Hersteller und HerstellerNr. ist an die ModellNr gekoppelt 

� Sei R eine Relation und FDR die zugehörige Menge funktionaler Abhängigkeiten. Dann gilt: 

Es gibt eine Zerlegung von R in Relationen R1 ,…,Rn , so dass 

– die Zerlegung verlustlos ist und, 

Seite 185

– R i die Boyce-Codd Normalform erfüllen. 

Schlechte Nachrichten: 


� Es kann nicht immer eine abhängigkeitsbewahrende Zerlegung gefunden werden. 

Seite 186


5.5 Mehrwertige Abhängigkeiten 

� Verallgemeinerung funktionaler Abhängigkeiten 

� Beispiel: RelationBuch mit Schema {ISBN, Autor, Stichwort} 

ISBN 

AUTOR STICHWORT 

– ein Buch kann mehrere Autoren besitzen 

– mehrere Stichwörter verweisen auf das Buch 

– AUTOR bzw. STICHWORT sind mehrwertig abhängig von ISBN 

Def. (mehrwertig abhängig): 

Sei R eine Relation und A� B� C�RSR 

mit RSR = A� B �C. 

Dann ist C mehrwertig 

abhängig von A, A » 

C , wenn für alle Instanzen IR gilt: Für jedes Paar von Tupel t1 und t2 

mit t1[A] = t2[A] existieren zwei Tupel t3 und t4 mit t3[A] = t4[A] = t1[A] und mit folgenden 

Eigenschaften: 

t3[B] = t1[B] t3[C] = t2[C] 

t4[B] = t2[B] t4[C] = t1[C] 

Es wird die Kurzschreibweise MVD (multi-value dependency) für eine mehrwertige 

Abhängigkeit benutzt. 

Seite 187

Beispiel: 

� Buch (ISBN, AUTOR, STICHWORT) 


� Buch besitzt nicht nur zwei Autoren, sondern es existieren auch mindestens zwei Stichworte 

� Zerlegen der Relation Buch in zwei Relationen R1 und R2 – RS R1 = {ISBN, Autor} 

– RS R2 = {ISBN, Stichwort} 

ISBN AUTOR STICHWORT 

I-1 Boyce Normalisierung 

I-1 Boyce Abhängigkeit 

I-1 Codd Normalisierung 

I-1 Codd Abhängigkeit 

– Es gilt sogar: Die Zerlegung ist verlustfrei! 

Satz 

Sei R eine Relation und MR die Menge der MVDs. Eine Zerlegung von R in R1 und R2 hat keinen 

Informationsverlust, genau dann falls mindestens eine der folgenden Bedingungen gilt: 

+ 

+ 

�RS � RS » RS ��Foder R1 R2 R1 R 

�RS � RS » RS � � 

F R1 R2 R2 R 

Seite 188

Vierte Normalform 

� ist eine Verstärkung der Boyce-Codd Normalform 

� Vermeidung der durch mehrwertige Abhängigkeiten verursachten Redundanz 


Sei R eine Relation und A�C�RSR. Eine mehrwertige Abhängigkeit A 

der folgenden Bedingungen gilt: 

» C ist trivial, falls eine 

1. C�A 2. 

C = RSR– A 

Definition (4NF): 

Sei R eine Relation und MR die zugehörige Menge mehrwertiger Abhängigkeiten. R ist in vierter 

Normalform (4NF), wenn für jede nicht-triviale mehrwertige Abhängigkeit A » C�MRfolgende 

Bedingung gilt: A enthält einen Schlüssel von R. 

Seite 189


5.6 Grenzen der Normalisierung 

� Auf Grund der Einhaltung von Normalformen existieren Relationen mit “wenigen” Attributen 

– Vorteil: Anomalien sind beseitigt, geringe Redundanz 

– Nachteil: “ineffiziente” Anfragebearbeitung 

Beispiel: 

� Gesucht sind Namen und Adressen aller Lieferanten, die ‘Mehl’ liefern. 

– Schema: Liefert(LName, LAdr, Ware, Preis) 

�LName� LAdr �Ware = Mehl 

� �Liefert�� – alternatives Schema: 

Lieferant(LName, LAdr)(Schema in 2NF) 

Angebot(L Name, Ware, Preis) 

�LName� LAdr��Ware 

= Mehl�Lieferant 

Angebot�� 

Seite 190

Bisher: 


5.6.1 Nicht-Standard Anwendungen 

� Beispiele aus dem betriebswirtschaftlich/administrativen Bereich Handel, Banken, 

Versicherungen, etc., d.h. Standard-Datenbanken und -systeme 

� kleine Datenobjekte exakt festgelegter Struktur 

� meist einfache Integritätsbedingungen 

� viele, kurze Transaktionen auf den Datenbanken (z.B. Buchungen) 

Jetzt: 

� Betrachtung sog. “Nicht-Standard-Datenbanksysteme” (NDBS) 

- CAD / CAM / CIM 

- Geographie und Kartographie 

- Medizin und Biologie 

� komplexe, unterschiedlich strukturierte geometrische Objekte 

� oft komplexe Integritätsbedingungen (z.B. aus der Geographie) 

� häufig sehr lange Operationen (Transaktionen) auf wenigen Objekten (z.B. CAD) 

Seite 191

F 1 

F 2 

F 3 

F 4 

Beispiel aus der Geographie 

F 6 

F 5 

F 7 

Parzellen 

FNr KNr 

F 1 

F 1 

F 1 

F 1 

F 4 

F 4 

F 4 

F 4 

F 4 

F 4 

F 7 

F 7 

F 7 

F 7 

K 1 

K 2 

K 3 

K 4 

K 2 

K 5 

K 6 

K 7 

K 8 

K 9 

K 7 

K 10 

K 11 

K 12 

Kanten 

KNr PNr 1 PNr 2 

K 1 

K 2 

K 3 

K 4 

K 5 

K 6 

K 7 

K 8 

K 9 

K 10 

K 11 

K 12 

P 1 

P 2 

P 3 

P 4 

P 2 

P 5 

P 6 

P 7 

P 8 

P 6 

P 9 

P 10 

P 2 

P 3 

P 4 

P 1 

P 5 

P 6 

P 7 

P 8 

P 3 

P 9 

P 10 

P 7 


PNr 

P 1 

P 2 

P 3 

P 4 

P 5 

P 6 

P 7 

P 8 

P 9 

P 10 

Punkte 

X-Koord. Y-Koord 

X P1 

X P2 

X P3 

X P4 

X P5 

X P6 

X P7 

X P8 

X P9 

X P10 

Y P1 

Y P2 

Y P3 

Y P4 

Y P5 

Y P6 

Y P7 

Y P8 

Y P9 

Y P10 

Seite 192


� redundanzfreie Repräsentation der Parzellen erfordert die Verteilung der Informationen auf 

drei Relationen: ‘Parzellen’, ‘Kanten’ und ‘Punkte’. 

� Anfragen auf den Parzellen müssen die erforderlichen Informationen zunächst 

zusammengesetzten: 

– Beispiel: Gesucht sind alle Eckpunkte der Parzelle mit Flurnr. 2. 

select Punkte.PNr, X-Koord, Y-Koord 

from Parzellen, Kanten, Punkte 

where FNr = “2” and 

Parzellen.KNr = Kanten.KNr and 

(Kanten.PNr1 = Punkte.PNr 

Kanten.PNr2 = Punkte.PNr) 

or 

� einfache Anfrage erfordert mehrere Joins 

� Ursache: Datenmodellierung und Normalisierung der Relationen 

� bessere Datenmodellierung für komplex (speziell geometrische) Objekte 

Seite 193

6. Transaktionskonzepte und 

Fehlerbehandlung 

Transaktionskonzepte und Fehlerbehandlung 

� Mehrbenutzerbetrieb: 

– DBS bedient gleichzeitig mehrere Benutzer 

– Benutzer arbeiten zwar unabhängig voneinander, können aber die gleiche Relation oder 

sogar den gleichen Datensatz bearbeiten! 

� Aktivität eines Benutzers: 

– sequentieller Prozess 

� Aktivitäten mehrerer Benutzer: 

– variable Menge von ineinander verzahnt ablaufender Prozesse 

– gemeinsame Nutzung der Datenbasis 

Benutzer Z 

Benutzer X 

DBMS 

Benutzer V 

JDBC 

ESQL 

DB 

SQL 

SQL 

Benutzer Y 

Seite 194


Anwendung eines DBS: Kontoverwaltung 

� Ein Benutzer möchte eine Buchung von einem Konto A auf ein Konto B vornehmen können. 

� Folgende Anforderungen ergeben sich dabei: 

– Eine Buchung sollte nicht teilweise durchgeführt werden. 

– Alle Konsistenzbedingungen sollen nach einer Buchung gewahrt bleiben: 

z. B. Kontostände dürfen nicht unter 10000,- fallen 

– Gleichzeitig ablaufende Buchungen dürfen keinen Einfluss haben auf das Ergebnis dieser 

Buchung. 

– Eine erfolgreiche Buchung ist auch tatsächlich in der Datenbank wirksam geworden. 

� Datenbanksystem 

– Mehrere Elementaroperationen werden miteinander zu einer Einheit verschmolzen. Der 

Ablauf dieser Einheit wird eine Transaktion genannt. 

– Es werden neue Operationen zur Ablaufsteuerung von Transaktionen benötigt. 

Seite 195

Operationen 

6.1 Transaktionen 


� Elementaroperationen, die sich auf die Datenbasis beziehen 

– Lesen des Werts eines Objekts A in eine Programmvariable a: 

read(A,a) bzw. r(A) 

– Zuweisung eines Werts einer Programmvariable a an ein Objekt A der Datenbank 

write(A, a) bzw. w(A) 

� Elementaroperationen, die keine Auswirkung auf die Datenbasis haben. 

� Ablaufsteuerung 

Anfang einer Transaktion: BOT 

– Oft wird nach einem Beenden einer Transaktion die nächste Transaktion implizit bereits 

geöffnet. 

Ende der Transaktion: commit 

– Alle in der Transaktion erzeugten Änderungen der Datenbasis werden festgeschrieben. 

Abbruch einer Transaktion: abort 

– Alle in der Transaktion vorgenommen Änderungen der Datenbasis werden unwirksam. 

Seite 196


Eigenschaften von Transaktionen 

� Eine Transaktion (TA) ist eine Folge von Elementaroperationen. Eine TA erfüllt die ACID- 

Bedingungen: 

A: TA ist die kleinste, atomare Ausführungseinheit. 

– Entweder alle durch einen TA vorgenommenen Änderungen werden in der Datenbasis 

wirksam oder gar keine. 

C: Eine TA überführt einen konsistenten Datenbankzustand in einen anderen konsistenten 

Datenbankzustand. 

– Innerhalb einer TA sind Inkonsistenzen erlaubt. 

I: Eine TA ist gegenüber anderen TAs isoliert, d. h. das Ergebnis einer TA kann nicht direkt 

durch eine andere TA beeinflusst werden. 

– Jede TA wird logisch so ausgeführt, als gäbe es keine andere TA. 

D:Ist eine TA einmal erfolgreich abgeschlossen, dann bleibt ihre Wirkung auf die Datenbasis 

dauerhaft erhalten. 

– Dies gilt auch im Fall eines Systemfehlers (Verlust des Hauptspeichers). 

Seite 197

Tm Tm+1 T n 

Transaktionsmanagement 

TA-Manager 

verzahnter 

Ablauf der TAs 

� Synchronisation der TAs 

– Isolation 

� Einschränkung bei den verzahnten Abläufen 

� Zurücksetzen einer oder mehrerer TAs 

– Atomarität 

– Dauerhaftigkeit 

� 

Einschränkung bei den verzahnten Abläufen 


Seite 198

Notation 

� Transaktionen: T 1 , T 2 , …, T n 

� Transaktion T j setzt sich aus folgenden Elementaroperationen zusammen: 

1. Leseoperation: r j (A) 

2. Schreiboperation: w j (A) 

3. Abbruch: a j 


4. Commit: c j 

5. weitere Operationen, die aber auf die Datenbank keine Auswirkung haben. 

� Eine Transaktion T j wird durch einen Aufruf von a j oder c j beendet: 

es gibt keine weitere Operation von T j , die danach ausgeführt wird. 

� Einzelne Operationen (r j , w j , a j , und c j ) werden sequentiell nacheinander ausgeführt: 

– Für einen Ablauf einer TA Tj gibt es eine Ordnungsrelation < j , welche die sequentielle 

Ordnung der Elementaroperationen ausdrückt: 

op1 < j op2 : � 

op1 wird vor op2 ausgeführt. 

Seite 199

Ausführungsplan (Historie) 

Definition (Ausführungsplan, Historie): 


Seien T 1 ,…,T n Transaktionen. Dann wird eine Folge H aller Operationen der TAs T 1 ,…,T n ein 

Ausführungsplan genannt, falls folgende Bedingungen erfüllt sind: 

– Es gibt nur Elementaroperationen vom Typ r j , w j , a j , c j . 

– Ordnungsrelationen < j der einzelnen Transaktionsabläufe bleiben bewahrt. 

Bemerkungen: 

� Durch den Ausführungsplan H ist eine Ordnungsrelation < H definiert. 

� Nicht alle Ausführungspläne erzeugen einen konsistenten Datenbankzustand (siehe Beispiele) 

� Verzahnter Ablauf der TAs wird oft auch als parallele Ausführung bezeichnet. 

Seite 200

Transaktion T 1 : 

read(A, a); 

a := a + 10; 

write(A, a); 

read(B, b); 

b := b-10; 

write(B, b); 

commit; 

Transaktion T 2: 

read(B, b); 

b := b + 10; 

write(B, b); 

read(C, c); 

c := c-10; 

write(C, c); 

commit 

Zeit 

Beispiel 

ein Ablauf: 

T 1 T 2 

read(A, a); 

read(B, b); 

a:= a + 10; 

write(A, a); 

b := b + 10; 

read(B, b); 

write(B, b); 

b := b-10; 

read(C, c); 

write(B, b); 

commit; 

c := c-10; 

write(C, c); 

commit; 


Ausführungsplan: 

r 1 (A); 

r 2 (B); 

w 1 (A); 

r 1 (B); 

w 2 (B); 

r 2 (C); 

w 1(B); 

c 1; 

w 2(C); 

c 2; 

Seite 201


6.1.1 Synchronisationsprobleme 

� Ein Ausführungsplan muss gewisse Kriterien erfüllen, damit die Isolationseigenschaft 

garantiert ist. Sonst kann es Probleme geben: 

Problem des “lost update” 

� Transaktion T 1 und T 2 erhöhen das Gehalt eines Mitarbeiters jeweils um 100,- DM 

T1 T2 Ausführungsplan 

read(Gehalt, g); r1 (Gehalt); 

g := g + 100; 

read(Gehalt, h); r2 (Gehalt); 

write(Gehalt, g); w1 (Gehalt); 

commit; 

h := h + 100; 

c1 write(Gehalt, h); w2 (Gehalt); 

commit; c2 � Konsistenz der DB ist i.a. nicht verletzt 

� Resultate der Anfragen sind nicht “offenkundig falsch” 

Seite 202

Problem der inkonsistenten Sicht auf die Datenbank 


� A und B seien zwei Kontostände für die A+B=0 gelten soll. 

� T1 und T2 sind zwei Transaktionen, wobei T1 ändert und T2 nur vom Konto liest. 

T 1 

read(A, a); 

a := a-1; 

write(A, a); 

read(A, c); 

read(B, d); 

commit; 

read(B,b); 

b := b+1; 

write(B,b); 

commit; 

� Transaktion T2 ließt somit inkonsistente Daten aus der Datenbank, obwohl die Datenbank nach 

T1 wieder in einem konsistenten Zustand ist. 

T 2 

Seite 203

Problem der inkonsistenten Datenbank 

� A und B seien im Folgenden zwei Kontostände, die stets A = B erfüllen. 

T 1 

read(A, a); 

a := a + 10; 

write(A, a); 

read(A, c); 

c := c*1.1; 

write(A, c); 

read(B, b); 

b := b*1.1; 

write(B, b); 

commit; 

read(B, d); 

d := d +10; 

write(B,d); 

commit; 

Die Datenbank hat dauerhaft einen inkonsistenten Zustand: 

Aneu = (A+10)*1.1 � B*1.1+10 = Bneu T 2 


Seite 204

Phantom-Problem: 

� Transaktion T1 – liest die Daten aller Angestellten, 

– berechnet die Höhe einer möglichen Gehaltserhöhung, 

– und erhöht entsprechend das Gehalt der Angestellten. 

� Transaktion T2 fügt einen neuen Angestellten ein. 


– Wird T 2 nach Schritt 1 von T 1 ausgeführt, so ist die Kalkulation von T 1 veraltet. 

Lösung der Synchronisationsprobleme: 

� strikte, sequentielle Ausführung der Transaktionen 

– Nachteil: schlechte Systemauslastung, lange Wartezeiten 

� Beschränkung der “Parallelität” auf erlaubte Verarbeitungsreihenfolgen 

Seite 205

6.1.2 Serialisierung von TAs 


� Sei T* = {T1 ,…,Tn } eine Menge von Transaktionen und H ein dazugehörender 

Ausführungsplan. Seien Ti und Tj zwei Transaktionen aus T*, die gemeinsam auf ein 

Datenobjekt A zugreifen. Es werden nun folgende vier Fälle unterschieden: 

1. ri (A) < H rj (A) 

2. r i (A) < H w j (A) 

3. w i (A) < H r j (A) 

4. w i (A) < H w j (A) 

Bemerkungen: 

– Nur im 1. Fall sind die Operationen vertauschbar, ohne dass sich das Ergebnis des 

Ausführungsplans ändert. 

– In allen anderen Fällen ist davon auszugehen, dass ein Vertauschen der 

Ausführungsreihenfolge zu einem anderen Ergebnis führt. Man spricht dann auch von 

einem Konflikt. 

Seite 206


Äquivalenz von Ausführungsplänen 

� Definition: 

Sei T* = {T1 ,…,Tn } eine Menge von Transaktionen. Seien H und G zwei dazugehörige 

Ausführungspläne. Dann sind H und G äquivalent, falls die Konflikte identisch sind, d.h. 

wenn für alle Relationen Ti und Tj und ein beliebiges Datenobjekt A folgende Bedingungen 

gelten: 

ri (A) < H wj (A) � 

ri (A) < G wj (A) 

wi (A) < H rj (A) � 

wi (A) < G rj (A) 

wi (A) < H wj (A) � 

wi (A) < G wj (A) 

� Durch Vertauschen von zwei benachbarten Operationen, die nicht in Konflikt zueinander 

stehen, kann man sich einen äquivalenten Ausführungsplan erzeugen. 

� Beispiel: 

– zwei Relationen T1 und T2 – Ausführungsplan H = (r1 (A),r2 (C),w1 (A),w2 (C),r1 (B),w1 (B),c1 ,r2 (A),w2 (A),c2 ) 

– Konflikte: 

r 1 (A) < H w 2 (A) 

w 1 (A) < H r 2 (A) 

Seite 207


Serialisierbare Ausführungspläne 

Definition (Serialisierbarkeit): 

Ein Ausführungsplan ist serialisierbar, falls es einen äquivalenten sequentiellen Ausführungsplan 

gibt. 

Serialisierbarkeitsgraph 

� Test auf Serialisierbarkeit eines Ausführungsplans. 

– Graph G = (K,U) mit Knotenmenge K und Kantenmenge U�K�K – zu jeder TA gibt es genau einen Knoten 

– (T1 ,T2 ) � U g.d.w. es gibt ein Objekt O, so dass op1 (O) < H op2 (O) in Konflikt zueinander 

stehen. 

Satz: 

T 1 

Ein Ausführungsplan ist genau dann serialisierbar, falls G zyklenfrei ist. 

Beweis: siehe Bernstein, Hadzilacos, Goodman.: Concurrency Control and Recovery in Database 

Systems. Addison-Wesley 1987. 

T 2 

Seite 208


6.2 Synchronisationsverfahren 

� In einem DBS soll stets Serialisierbarkeit garantiert werden. 

� Zwei prinzipielle Methoden: 

– verifizierende (“optimistische”) Verfahren: 

Beobachte ständig die Ausführungspläne (über den Graph G). Falls Serialisierbarkeit 

nicht garantiert ist, setze eine TA zurück und starte sie neu. 

– präventive Verfahren: 

Verhindere nicht-serialisierbare Ausführungspläne. 

� Bislang verwendete Verfahren: 

– Sperrverfahren 

– Zeitstempel- und Mehrversionsverfahren 

Seite 209

Sperrverfahren 


� Jede TA sperrt den Teil der DB, auf dem sie arbeiten will. 

– Solange gesperrt ist, können keine anderen TAs zugreifen 

� Klassifizierung der Sperrverfahren nach 

– Sperrobjekten: Datensatz, Datenseite, Relation, Datenbank 

Beachte: 

je feiner die Sperreinheit, desto mehr Parallelität ist möglich 

je feiner die Sperreinheit, desto mehr Verwaltungsaufwand 

– Sperrmodi 

lock(A) sperrt das Datenobjekt A 

unlock(A) gibt die Sperre wieder frei 

– Sperrprotokoll 

Anforderung: Gewährleistung der Serialisierbarkeit 

Seite 210


Zwei-Phasen Sperrprotokoll (2PL) 

� 2-Phasen-Sperrprotokoll: 

Für jede TA darf nach dem ersten unlock kein lock mehr angefordert werden. 


#Sperren 

Sperren 

Verarbeitung 

Freigabe 

� Bevor auf ein Objekt A zugegriffen wird, muss es mit einem lock gesperrt werden. 

Insbesondere muss eine Sperre direkt vor dem Lesen des Objekts gesetzt werden. 

� Das gleiche Objekt darf während einer Transaktion bei einem 2PL nur einmal gesperrt und 

freigegeben (unlock) werden. 

� Wurde das Objekt verändert, muss es vor der Freigabe (unlock) auch geschrieben werden. 

Zeit 

Seite 211

Satz: 

Beweisskizze: 


Jeder durch ein 2-Phasen Sperrprotokoll erzeugte Ausführungsplan ist serialisierbar. 

– Annahme: H ist ein Ausführungsplan mit einem Zyklus T i1 -> … -> T in -> T i1 

– Wenn dieser mittels eines 2PL entstanden wäre, dann müsste es Objekte A i1 , …, A in 

geben, so dass bzgl. diesen Objekten die Transaktionen in Konflikt stehen. Somit muss 

also ein unlock ij (A ij ) vor einem lock ij+1 (A ij ) für j= 1, …,n-1 erfolgt sein und zusätzlich 

noch ein lock i1 (A in ) nach dem unlock in (A in ) erfolgen. 

Seite 212

� Preclaiming (konservatives 2PL): 

#Sperren 

Verarbeitung 

– keine Verklemmung möglich 

– Objekte müssen bei Beginn der TA 

bekannt sein 

– häufig wird zu viel und zu lange 

gesperrt 

– Probleme beim Zurücksetzen einer 

TA (kaskadierend) 

Varianten des 2PL 

Freigabe 

Zeit 


� EOT-Sperren (striktes 2PL) 

#Sperren 

Sperren 

Verarbeitung 

Zeit 

– Verklemmungen sind möglich 

– Objekte müssen beim Beginn der TA 

noch nicht bekannt sein. 

– bei Freigabe der Sperren ist 

garantiert, dass auf kein Objekt mehr 

zugegriffen wird. 

– vermeidet Zurücksetzen von bereits 

abgeschlossenen TAs 

Seite 213

Sperrmodi 


� Das bisherige Vorgehen ist zu restriktiv, da das Sperren von Objekten, die nur gelesen werden, 

nicht gesondert behandelt wird. 

– Eine Transaktion T2 , die ein Objekt A lesen möchte, muss warten bis die Transaktion T1 ein unlock auf A ausführt (obwohl T1 keine Änderungen an A vornimmt). 

RX-Protokoll 

� Unterscheidung zwischen zwei Sperrmodi 

– S-Sperre: slockT (A) 

Das Objekt A darf von der Transaktion T gelesen, aber nicht geschrieben werden. Auf 

dem Objekt A sind nun mehrere S-Sperren verschiedener Transaktionen erlaubt (S ist eine 

Abkürzung für Shared) 

– X-Sperre: xlockT (A) 

Die Transaktion T hat nach dem Sperren des Objekts A exklusiven lesenden und 

schreibenden Zugriff. Es ist somit nur eine X-Sperre auf einem Objekt A erlaubt (X ist 

eine Abkürung für eXclusice) 

Seite 214


Hierarchische Sperrgranulate 

� Motivation 

– Bisher sind wir davon ausgegangen, dass die Sperren sich auf Objekte der gleichen 

Hierarchiestufe beziehen (z. B. Seiten) 

– Sperren auf einer höheren Stufe (z. B. Relation) sind dann sinnvoll, wenn bereits viele 

Kindobjekte gesperrt wurden. Dadurch kann der Verwaltungsaufwand für die Sperren 

erheblich reduziert werden. 

� Multiple-granularity Locking 

– S: Lesesperre 

– X Schreibesperre 

– IS Auf Objekten in der darunter liegenden Hierarchie ist eine Lesesperre 

beabsichtigt. 

– IX Auf Objekten in der darunter liegenden Hierarchie ist eine Schreibesperre 

beabsichtigt. 

� Erwerb von Sperren 

– Top-Down: Bevor ein Objekt gesperrt wird, muss zuerst das Objekt auf der darüber 

liegenden Ebene intensional gesperrt sein. 

� Zurückgabe von Sperren 

Seite 215

– Bottom-up: Feingranulare Sperren werden zuerst zurückgegeben. 

� Kompatibilität der Sperrmodi 

Beispiel: 

Datenbank 

Relationen 

Seiten 

S X IS IX 

S x x 

X 

IS x x x 

IX x x 

IX 1 

X1 S11 S12 

Sätze d111 d112 IX 1 

D 

IS 2 

R 1 R2 R 3 


IS 2 

S 31 

S 2 

Seite 216


6.3 Mehrbenutzersynchronisation in SQL92 

� In SQL’92 kann das Korrektheitskriterium für die parallele Verarbeitung von Transaktionen 

durch Angabe eines Isolationslevel abgesenkt werden. 

– Erhöhung des Parallelitätsgrads 

– Gefahr einer inkonsistenten Datenbank 

� Isolationslevel 

– read uncommited 

Dies erlaubt lesenden Transaktionen den Zugriff auf noch nicht festgeschriebene Daten 

(d.h. Daten können vor dem commit bereits gelesen werden). 

– read committed 

Daten können nur dann gelesen werden, wenn diese tatsächlich über ein commit 

festgeschrieben wurden. Warum garantiert dies noch keine Serialisierbarkeit? 

– repeatable reads 

Identische Leseoperationen innerhalb der gleichen Transaktion liefern zwar das gleiche 

Ergebnis. Das Phantomproblem wird jedoch nicht verhindert. 

– serializable 

Dies entspricht dem in diesem Kapitel erläuterten Serializierbarkeitsbegriff. Dies ist die 

Defaulteinstellung bei einem DBS. 

Seite 217

6.4 Fehlerbehandlung 


� Schutz vor Beeinträchtigungen durch Fehler des Systems oder eines Benutzers 

� nach Systemzusammensturz innerhalb einer TA 

– inkonsistenter Zustand der DB 

– physische und logische Inkonsistenz 

� Recovery-Komponente eines DBS: 

– dient zum Wiederherstellen eines korrekten DB-Zustandes 

– basiert auf dem TA-Konzept des DBS 

Fehlerklassen: 

� Transaktionsfehler (z. B. Deadlock, Konsistenzverletzung, Division durch 0) 

– Rücksetzen einer oder mehrerer TAs im laufenden Betrieb 

� Systemfehler (DBS ist funktionsunfähig, Verlust des Inhalts im Hauptspeicher) 

– Rückgängigmachen aller laufenden TAs (Neustart des Systems) 

� Speicherfehler (Verlust des Plattenspeichers durch “head crash”, selten) 

– Rekonstruieren der Datenbank 

Seite 218


Lesen und Schreiben von Datensätzen 

AWP 1 

AWP 2 

A neu 

B 

Datenbank-Puffer 

externe Datenbank 

� Datensätze werden in Seiten (Blöcken) auf dem Externspeicher abgelegt. 

– Eine Seite ist die kleinste Transfereinheit zwischen Extern- und Hauptspeicher. 

� Ein DBS besitzt einen Puffer, in dem Datensätze (und Datenseiten) für die AWPs bereitgestellt 

werden. 

� Zu jeder Seite im Puffer gibt es genau eine Seite in der externen DB 

– Seite in der externen DB ist aber ggf. veraltet. 

– Schreiben einer Seite in die DB zerstört den alten Zustand. 

A alt 

B 

Hauptspeicher Externspeicher 

Seite 219

Interner Ablauf einer Lese/Schreiboperation 


1. Lies die Seite vom Externspeicher in den Puffer (wenn nicht bereits vorhanden) 

2. Fixiere die Seite im Puffer, d.h. die Seite bleibt fest im Hauptspeicher. 

3. Setze eine Sperre auf den gewünschten Datensatz. 

AWP liest/schreibt den Datensatz und führt weitere Operationen aus. 

4. Hebe die Sperre auf. 

5. Kennzeichne, dass das AWP die Seite nicht mehr benötigt (Unfix). 

Im Fall von Schreiboperationen: 

� Datenbank gerät kurzzeitig in einen inkonsistenten Zustand (innerhalb einer TA) 

� Modifizierte Seiten im Puffer werden nicht sofort auf den Externspeicher übertragen 

– externe DB ist veraltet 

– externe DB hat nach dem Ende der TA einen inkonsistenten Zustand. 

� Verlust des Hauptspeichers => inkonsistente DB 

Ziel: 

� DB soll auch bei Verlust des HSP in einem konsistenten Zustand sein. 

Seite 220

Freigabe von Seiten 


Varianten beim Lesen/Schreiben 

� Pufferverwalter kann diese Seite aus dem Puffer entfernen und (wenn die Seite geändert 

wurde) auf den Externspeicher schreiben 

� Varianten 

– steal: Freigabe vor dem commit einer TA 

– no-steal: keine Freigabe vor dem commit der TA. 

Schreiben der modifizierten Seiten auf den Externspeicher 

� Varianten 

– force: Schreiben der Seiten beim commit 

– no-force: Schreiben der Seiten zu einem späteren Zeitpunkt 

in heutigen DBS: 

� no-force und steal 

Seite 221


Protokollierung von Änderungsoperationen 

� Mögliche Fälle nach einem commit einer TA (im Fall von steal und no-force): 

– externe DB ist in einem inkonsistenten Zustand 

– Änderungen sind in der externen DB noch nicht wirksam geworden. 

� Protokoll 

– REDO-Information: 

wenn Änderungen nachvollzogen werden sollen. 

– UNDO-Information: 

wenn Änderungen rückgängig gemacht werden sollen. 

� Eintrag in der Protokolldatei (Log) besteht aus: 

– LSN: Log Sequence Number 

eindeutige Kennung (monoton wachsend) 

– TA_ID: Transaktionskennung 

– SID: Seitennummer 

– REDO-Information 

– UNDO-Information 

– P_LSN: Zeiger auf den vorherigen Log-Eintrag der Transaktion TA_ID. 

Seite 222

Physisches Logging 

Varianten beim Logging 


� Explizite Angabe des neuen Zustands des Objekts (“after image”) und des alten Zustands 

(“before image”) 

Logisches Logging 

� Angabe der Operation (für redo) und der zugehörigen Umkehrfunktion (undo) 

Physiologisches Logging 

� physisches Logging auf der Seitenebene 

� logisches Loggig innerhalb einer Seite 

Seite 223

Beispiel: 


Transaktion T1 Transaktion T2 logische Protokolldatei physiologische Protokolldatei 

begin-TA 

r(A,a1 old ) 

a1 new = a1 old - 10 

begin_TA 

r(C,c old ) 

w(A,a1 new ) 

r(B, b old ) 

b new = b old + 10 

c new = c old + 20 

w(C,c new ) 

w(B, b new ) 

commit 

r(A,a2 old ) 

a2 new = a2 old - 20 

w(A,a2 new ) 

commit 

� Unter Verwendung der UNDO- und der REDO-Information ist es also möglich den vorherigen 

Zustand der Seite zu rekonstruieren. 

Seite 224


� Bei der logischen Protokollierung ist es aber noch wichtig, den Zustand der betroffenen Seite 

zu kennzeichnen: 

– LSN der zuletzt auf der Seite wirksamen Schreiboperation wird in der Seite zusätzlich 

abgespeichert. 

� Zwei Fälle können nun unterschieden werden: 

– LSN der Seite < LSN eines Protokolleintrags 

– LSN der Seite >= LSN des Protokolleintrags 

Seite 225


Verwaltung der Protokolleinträge 

AWP 1 

AWP n 

abstrakte SQL-Mashine 

Schreiben 

in den Puffer 

DB- 

Puffer 

Log- 

Puffer 

Implementierung als Ringpuffer 

Datenbank DB-Archiv 

Log-Datei Log-Archiv 

Schreiben auf 

Log-Datei 

Seite 226


Schreiben der Einträge in die Log-Datei 

� Folgende Regeln müssen beim Schreiben der Log-Einträge befolgt werden: 

– Vor dem commit einer TA müssen alle zugehörigen Protokolleinträge in die Log-Datei 

geschrieben werden. 

– Vor dem Schreiben einer modifizierten Seite in die (externe) Datenbank müssen alle 

zugehörigen Protokolleinträge geschrieben werden. 

� Wenn ein Protokolleintrag mit LSN x in die Log-Datei geschrieben wird, so müssen vorher 

alle Einträge mit LSN y, y < x, geschrieben worden sein. 

� Diese Vorgehensweise nennt man auch Write Ahead Log (WAL) 

Seite 227


6.4.1 Wiederanlauf nach einem Systemfehler 

� Ursache: Verlust des Hauptspeichers 

� Zwei Arten von TA 

– Winner: 

Für TAs, die bereits mit commit beendet wurden, müssen die durchgeführten Änderungen 

in der DB nachvollzogen werden. Warum ? 

– Loser: 

Für TAs, die zum Zeitpunkt es Absturzes aktiv waren, aber noch nicht mit commit 

beendet wurden, müssen die Änderungen rückgängig gemacht werden. 

� Wiederanlauf geschieht in drei Phasen: 

– Analyse: Bestimme Winner und Loser 

– Wiederholung der Historie (REDO) 

– Zurücksetzen der Loser (UNDO) 

Analyse 

� sequentielles Durchlaufen der Log-Datei vom Anfang bis zum Ende 

– TA mit einem Eintrag “begin_TA” und einem Eintrag “commit” sind Winner. 

– TA mit einem Eintrag “begin_TA” ohne einem Eintrag “commit” sind Loser. 

Seite 228

REDO-Phase 


� Sequentielles Durchlaufen der Einträge in der Log-Datei vom Anfang bis zum Ende 

– Lies die zugehörige Seite vom Externspeicher 

Falls LSN der Seite < LSN des Eintrags: 

(i) Führe REDO-Operation aus. 

(ii) Übertrage die LSN des Eintrags in die Seite. 

UNDO-Phase 

� Sequentielles Durchlaufen der Einträge in der Log-Datei vom Ende bis zum Anfang 

– Führe für jede Loser-TA die UNDO-Operation aus. 

Zusätzlich: 

– Schreiben von Kompensationseinträgen in die Log-Datei 

Seite 229


Fehlerbehandlung beim Wiederanlauf 

� “Schicksalsstunden” im Leben einer Datenbank 

– Stromausfall: Verlust es Hauptspeichers 

– Wiederanlauf des Systems 

– erneuter Stromausfall (bevor der Wiederanlauf beendet wurde) 

� Anforderung: Idempotenz der UNDO- und REDO-Operationen 

– Ergebnis einer beliebig oft ausgeführten UNDO/REDO-Operation entspricht dem 

Ergebnis einer einmalig ausgeführten UNDO/REDO-Operation 

� Offensichtlich gilt: REDO-Operationen sind idempotent 

Idempotenz der UNDO-Operation 

� Diese Eigenschaft wird durch Kompensationseinträge in der Protokolldatei sichergestellt. 

� Für jede ausgeführte UNDO-Operation wird ein Eintrag erzeugt: 

– Dieser besitzt keine UNDO-Information. 

– Seine REDO-Information entspricht dabei der (ausgeführten) UNDO-Operation. 

– Zusätzlich gibt es noch einen Verweis auf einen Eintrag in der Log-Datei 

(UNDO_P_LSN). 

Seite 230

Beispiel: 

� Transaktionen T 1 und T 2 

Log-Datei (vor dem Wiederanlauf) 

#1 #2 #3 #4 #5 #6 #7 

Log-Datei nach dem Wiederanlauf 

� UNDO_P_LSN 

– Zeiger auf die nächste auszuführende UNDO-Operation der TA. 


#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 

UNDO_P_LSN 

NIL 

Seite 231

6.4.2 Rücksetzen einer TA 

Gründe für das Zurücksetzen einer TA 


� System muss eine oder mehrere TAs zurücksetzen (z. B. wegen einer Verklemmung). 

� Benutzer bricht seine TA ab. 

Anforderung: 

Ablauf 

– alle DB-Änderungen der TA müssen zurückgenommen werden 

– lokal für eine TA möglich, wenn noch keine Sperren freigegeben wurden 

� sequentielles Durchlaufen der Protokolldatei vom Ende bis zum ersten Eintrag der TA, die 

zurückgesetzt werden soll: 

– Ausführen der UNDO-Operation 

– Eintrag eines Kompensationseintrags 

– Aufsuchen des nächsten Eintrags (mit P_LSN) 

� Sperren der TA müssen zusätzlich beim Rücksetzen freigegeben werden. 

Seite 232

6.4.3 Sicherungspunkte 

� Nachteil beim Zurücksetzen: Protokolldateien können sehr groß werden! 

� Einführung von Sicherungspunkte, so dass idealerweise 

– der Wiederanlauf startet am letzten Sicherungspunkt 

– und ältere Protokolleinträge gelöscht werden können. 

Arten von Sicherungspunkten (savepoints, checkpoints) 


� Transaktionskonsistente Sicherungspunkte 

– Überführung des Systems in einen Ruhezustand (d.h. keine TA ist mehr aktiv) 

– Schreiben aller modifizierten Seiten 

– Neuinitialisierung der Protokolldatei 

– Starten der wartenden TA 

Nachteil: 

– Verzögerung der TA 

– großer Aufwand beim Schreiben des Pufferinhalts 

Seite 233


Aktionsbasierte Sicherungspunkte 

� Dabei ist keine Beruhigung des Systems erforderlich. Stattdessen müssen nur die elementaren 

Änderungsoperationen abgeschlossen werden. 

T5 

T4 

T3 

T2 

T1 

MIN_LSN 

Sicherungspunkt 

� Folgende Aktionen werden ausgeführt: 

– Schreiben des Log-Puffers und des DB-Puffers (WAL-Prinzip !) 

– Berechnen der Liste STA aller zum Zeitpunkt des Sicherungspunktes aktiven TAs 

– Berechnen von MIN_LSN = min {LSN | LSN gehört zu einer TA aus S TA } 

� Analyse- und REDO-Phase setzt beim Sicherungspunkt auf. 

� UNDO-Phase muss aber bis MIN_LSN gehen. 

Abbruch 

Zeit 

Seite 234

Ziel 

Unscharfe Sicherungspunkte 


� Reduzierung der Systembelastung durch schrittweises Weitersetzen von Sicherungspunkten 

Folgende Datenstrukturen werden nun benötigt 

� “schmutzige” Pufferseiten sind miteinander verkettet bzgl. der LSN der zuletzt in der Seite 

ablaufenden Änderung. 

– Seite am Kopf der Liste besitzt die kleinste LSN (MIN_LSN_DIRTY). 

– MIN_LSN_DIRTY ist quasi die LSN des Sicherungspunkts 

� Liste STA enthält alle zum Zeitpunkt MIN_LSN_Dirty aktiven TAs 

� MIN_LSN ist die kleinste LSN die in TAs aus S TA vorkommt. 

Seite 235

6.4.4 Rekonstruktion 


� Rekonstruktion eines korrekten DB-Zustand (mit möglichst wenig Verlust) 

� Vorgehensweise: 

– DB-Kopie, ein so genannter Dump, wird benötigt zu einem zurückliegenden Zeitpunkt 

(sehr teuer, deshalb selten) 

– Verwende Dump und wiederhole alle seitdem beendete TAs 

� Hierzu werden folgende Daten benötigt: 

– “after images” veränderter Objekte (benötigt bis zum letzten Dump) 

– entsprechende Protokolldatei wird von vorne nach hinten gelesen 

T5 

T4 

T3 

T2 

T1 

Dump 

Abbruch 

Zeit 

Seite 236

7. Anwendungsprogrammierung 

Anwendungsprogrammierung 

� Anwendungen werden typischerweise in imperativen Sprachen entwickelt (C, Cobol, Fortran, 

Java, C++, C#…) 

– reichhaltige Funktionalität bei der “gewöhnlichen” Programmierung 

– keine Unterstützung von Persistenz (Datenbankprogrammierung) 

– flexibles Datenmodell: 

basiert auf der Verarbeitung von einzelnen Datensätzen 

� Datenbankanfragesprachen (SQL) sind deskriptiv 

– wenig Funktionalität für die “alltägliche” Programmierung: 

Einfache Aufgaben wie z. B. die “Berechne den Flächeninhalt eines beliebigen Polygons” 

sind in SQL nicht möglich. 

– sehr komfortabel für die Datenbankprogrammierung 

– restriktives Datenmodell: 

im Wesentlichen nur Verarbeitung von Mengen (Relationen) 

Frage: 

� Wie kann die Programmierung von Datenbankaufgaben mit der von “gewöhnlichen” 

Aufgaben verbunden werden (ohne dabei die Vorteile von SQL aufzugeben)? 

Seite 237

Evolutionäre Ansätze: 

Kopplungsmöglichkeiten 

� CALL-Schnittstelle 

– Bereitstellung von Bibliotheken 

� Einbettung mit Vorübersetzer 

– statisch: Struktur der SQL-Befehle ist bereits vorgegeben 

– dynamisch: beliebige SQL-Befehle 

� Spracherweiterungen 

– von SQL 

– von einer imperativen Programmiersprache (z. B. PASCAL) 

� Skriptsprachen 

– BASIC-ähnliche Sprachen ohne Typkonzept 

– einfache Anbindung an Window- und Graphikumgebung 


Seite 238


7.1 Prozedurale CALL-Schnittstelle 

� basiert auf der Verwendung einer Bibliothek 

– im Fall von Oracle: Oracle Call Interface (OCI) 

– im Fall von SQL Server (ODBC) 

– … 

Quelldateien 

Host-Compiler 

Host-Linker 

DBMS-Bibliothek 

AWP DBMS-Server 

Datenbank 

Seite 239


Komponenten der CALL-Schnittstelle 

� Gemeinsam vom AWP und dem Datenbank-Server genutzte Datenstrukturen: 

– zum Aufbau der Kommunikation 

– zur Bearbeitung einer Anfrage 

� Cursor: Im AWP benutzte Datenstruktur zum Zugriff auf Relationen der DB. 

� SQL-Anfragen werden im AWP als String repräsentiert. 

– AWP muß einen erheblichen Teil der Typüberprüfung übernehmen. 

� Binden der Variablen aus dem AWP an die Datenstrukturen des DBMS-Servers 

Ablauf eines AWP: 

Aufbau der Verbindung 

zum DBMS-Server 

Initialisieren 

eines Cursors 

Parsen eines 

SQL-Statements 

Binden von Eingabevariablen 

an das SQL-Statement 

Ausführen eines 

Updates (einer Anfrage) 

Schließen des 

Cursors 

Abkoppeln 

vom Server 

Seite 240

Ausführen einer Anfrage (im Detail): 

Abfragen der 

Ausgabeparameter 

Nachteil bei der Benutzung der CALL-Schnittstelle: 


� komplizierte Programmierung 

– Abbildung zwischen den Objekten des AWP und den Objekten der Datenbank 

� fehleranfällig 

– Typsystem der Programmiersprache und des Datenbanksystems sind unterschiedlich 

Vorteile 

Binden der Ausgabe 

an Variablen des AWP 

� hohe Flexibilität 

– Generierung und Kompilieren von Anfragen zur Laufzeit des AWP 

Setzen des 

Cursors 

Abbrechen der 

Anfrage 

Seite 241

7.1.1 JDBC 


� JDBC steht für Java Database Connectivity 

� Java API für die Programmierung relationaler DBMS 

– Anfragen werden vom Java-Anwendungsprogramm als uninterpretierte Zeichenketten an 

das DBMS gegeben. 

– Resultate werden als Objekte einer Klasse ResultSet vom DBMS an das AWP geliefert. 

� JDBC bietet eine einheitliche Schnittstelle für verschiedene DBMS 

– ähnlich zu ODBC (Open DataBase Connectivity), aber plattformunabhängig 

– JDBC ist unter dem Paket java.sql integraler Bestandteil der Standard API von Java 

� Unterstützung des Client-Server Konzepts 

– DBMS läuft logisch auf einem anderen Rechner als das AWP 

� Unterstützung wichtiger Konzepte 

– Verschiedene Typen von Anfragen (statische Anfragen, parametrisierbare Anfragen, 

Aufruf von gespeicherten Prozeduren) 

– Änderungsoperationen auf Relationen und dem Schema 

– Zugriff auf Metadaten 

Seite 242

ResultSet 

getXXX 

Datentypen 

Wichtige Klassen bei JDBC 

executeQuery 

getResults 

executeQuery 

setXXX 

getXXX 

Statement 

IS-A 

PreparedStatement 

IS-A 

CallableStatement 

createStatement 

prepareStatement 

prepareCall 


Connection 

DriverManager 

getConnection 

� Die Namen in den Rechtecken entsprechen den Namen der verfügbaren Schnittstellen 

� Die gerichteten durchgezogenen Kanten zeigen, wie man ein Objekt einer Klasse (auf die eine 

Kante gerichtet ist) mit Hilfe der anderen Klasse erzeugt. 

Seite 243

Client/Server Kopplung in JDBC 

Aufbau einer Verbindung 


� Als erstes muß zunächst die entsprechende Treiberklasse angemeldet werden. 

Class.forName("oracle.jdbc.driver.OracleDriver") ; 

� Danach wird ein Connection Objekt erzeugt. 

Connection con = DriverManager.getConnection ("jdbc:oracle:thin:@venus.mathematik.unimarburg.de:1521:Init_DB", 

"scott", "tiger"); 

– Erste Zeichenkette entspricht einer URL zur Datenbank 

– Zweite Zeichenkette ist der Benutzername 

– Dritte Zeichenkette ist das Passwort 

4 verschiedene Treiberklassen bei JDBC 

1. Native API-Treiber 

2. JDBC-ODBC Bridge 

3. JDBC-Middleware 

4. Natives Protokoll 

Seite 244

Native API-Treiber 


Spezielle Netzsoftware des DBMS wird auf dem Client installiert. Methoden in JDBC werden 

nativ auf die Methoden der darunter liegenden Netzsoftware abgebildet. 

Nachteile 

� Installation der Netzsoftware auf allen Clients 

– keine Unabhängigkeit vom Datenbanksystem 

– Keine Nutzung im Internet 

Vorteil 

� relativ gute Performance 

Client Server 

JDBC 

DBMS-Net 

DBMS 

Seite 245

Vorteil 

JDBC-ODBC Bridge 


ODBC-Treiber und ggf. weitere Datenbank-Software sind auf dem Client verfügbar. Methoden 

von JDBC werden auf die Funktionalität von ODBC abgebildet. 

� Unabhängigkeit von speziellen Datenbanksystemen, da ODBC sehr weit verbreitet ist. 

Nachteil 

Client Server 

JDBC 

ODBC-Treiber + 

Datenbank-Software 

DBMS 

� Installation von ODBC + Datenbanktreiber auf allen Clients 

– keine Anbindung im Internet 

� Anfragen und Ergebnisse müssen über die ODBC-Brücke verschickt werden. 

– schlechte Performance 

Seite 246

Vorteil 

JDBC-Middleware 


Ähnlich zur ersten Lösung, aber die Netzsoftware ist durch Nutzung einer Middleware unabhängig 

vom spezifischen DBMS. 

� Keine Installation von spezieller Software am Client 

– Einfacher (und kleiner) Java-Treiber wird bei Bedarf geladen 

� Unabhängigkeit vom DBMS 

� Optimierung auf dem Server (wie z. B. Pufferung von Ergebnissen) 

Nachteil 

Client Server 

JDBC 

Java-Treiber 

DBMS 

Middle-Net 

� Alle Ergebnisse werden über die Middleware nach außen gegeben. 

Seite 247

Natives Protokoll 


Ein speziell in Java implementierte Netzwerkverbindung übermittelt die Anforderungen des 

Clients an einen Server. Beim Server wird dann die Anforderung direkt an das DBMS weitergereicht. 

Vorteile 

� Software auf dem Client ist in Java geschrieben und kann bei Bedarf geladen werden. 

� Direkte Interaktion mit dem DBMS (Vermeidung einer Zwischeninstanz) 

– gute Performance 

Nachteil 

Client Server 

JDBC + 

Datenbanktreiber 

� Für jedes DBMS benötigt man einen eigenen Treiber. 

DBMS 

Seite 248

Treibermanager 

Treibermanagement von JDBC 


� Vermittlungsschicht zwischen Anwendung und dem eigentlichen Datenbanktreiber 

� Es gibt nur einen Treibermanager pro Programm 

=> nur statische Methoden in der Klasse DriverManager 

� Unterstützung folgender Operationen 

– Registrieren und Laden von Treibern 

– Herstellen einer Verbindung zur Datenbank 

– Konfiguration der Verbindung 

� Laden eines Treibers 

– Explizites Laden im AWP über einen Aufruf der Methode Class.forName 

– Über die Systemeigenschaft jdbc.drivers der JVM 

java -Djdbc.drivers=foo.bas.Driver:wom.sql.Driver JDBCDemo1 

Es wird das Programm JDBCDemo1 gestartet und in der Kommandozeile der 

verwendete Treiber mitgeteilt. 

Seite 249


– Beim Laden eines Treibers, registriert der Treiber sich beim Treibermanager (durch 

Aufruf der Methode registerDriver der Klasse DriverManager). 

Treiber 

� Wichtig für die Praxis sind Methoden zum Abgreifen von Daten über die Version des Treibers 

und seinen Leistungsumfang. 

– Z. B. liefert die Methode jdbcCompliant der Schnittstelle Driver nur dann true, wenn der 

Treiber SQL92 Entry Level unterstützt und den JDBC-Test erfolgreich bestanden hat. 

Aufbau einer Datenbankverbindung 

� erfolgt über den Aufruf einer Methode mit Namen getConnection aus der Klasse 

DriverManager. 

– Alle diese Methoden erwarten eine URL als Parameter, genauer gesagt eine JDBC-URL. 

� Aufbau einer JDBC-URL 

jdbc:: 

Weitere Funktionalität 

� Setzen einer maximalen Wartezeit zur Anmeldung am Server 

� Protokollierung von Fehlermeldungen 

Seite 250

7.1.2 Datenverbindungen bei JDBC 


� Eine Verbindung wird in JDBC durch ein Objekt der Klasse Connection repräsentiert. 

– getConnection liefert als Ergebnis ein solches Objekt zurück. 

� Unterstützte Funktionalität 

– Senden von SQL-Anweisungen an den Datenbankserver 

– Steuerung von Transaktionen 

– Empfang von Resultaten vom Server 

– Abgreifen von Metainformation über die Datenbank 

Seite 251

Transaktionen 


� Eine Transaktion ist eine Folge von SQL-Befehlen, die atomar verarbeitet werden. 

– Durch den Befehl commit wird die Transaktion abgeschlossen und die Änderungen sind 

dann danach garantiert in der Datenbank. 

– Durch den Befehl rollback wird die Transaktion wieder zurückgefahren, d. h. alle 

bisherigen Operationen in der Transaktion sind unwirksam. 

� Eine Transaktion wird implizit mit dem ersten Befehl (nach commit und rollback) gestartet. 

� Objektmethoden 

– commit() und rollback() sind Methoden mit der bekannten Semantik 

– void setAutoCommit(boolean enable) 

Ist AutoCommit gesetzt, ist jeder Befehl eine Transaktion. Ansonsten muß die 

Transaktion explizit durch commit bzw. rollback abgeschlossen werden. 

– Methode setTransactionIsolation erlaubt das Einstellen eines sogenannten 

Isolationslevels. (Siehe auch Kapitel Transaktionen) 

Seite 252

7.1.3 Anfragen 


� In java.sql wird zwischen drei Anfragetypen unterschieden 

– Statement 

Einfache Anfragen ohne Parametrisierung 

– PreparedStatement 

Vorübersetzte Anfrage, die Eingabeparameter unterstützt. 

– CallableStatement 

Aufruf von gespeicherten Prozeduren, die auf dem DBMS hinterlegt sind. 

� Zur Ausführung von allgemeinen SQL-Anfragen stehen folgende execute-Methoden zur 

Verfügung: 

– ResultSet executeQuery(String sql) 

Ausführung einer Anfrage mit SELECT-Klausel, wobei das Ergebnis ein Objekt der 

Klasse ResultSet ist. 

– int executeUpdate(String sql) 

Dadurch können Änderungsoperationen (Einfügen neuer Tupel, Löschen, …) unterstützt 

werden. Als Ergebnis wird die Anzahl der involvierten Tupel geliefert. 

Weiterhin können auch Schemaänderungen formuliert werden (z. B. create table, …). 

Dann ist das Ergebnis stets 0. 

Seite 253


– boolean execute(String sql) 

Diese Methode wird dann aufgerufen, wenn es nicht bekannt ist, ob die SQL-Anweisung 

eine Anfrage ist (Rückgabewert true) oder eine Änderungsoperation (false). Auch kann 

diese Methode verwendet werden, wenn eine Anweisung mehr als ein Resultat besitzt. 

Inkompatibilität von SQL-Dialekten 

– Ein primäres Ziel von JDBC ist die Unabhängigkeit des AWP vom zugrunde liegenden 

DBMS. Leider gibt es eine Vielzahl von Unterschieden bei den verschiedenen SQL- 

Dialekten. 

Outer-Join in SQL92 Standard 

select Emp.name, Proj.name 

from Emp left outer join Proj on Emp.pid = Proj.id 

Outer-Join in SQL von Oracle 


from Emp, Proj 

where Emp.pid = Proj.id(+) 

– Zur Überwindung solcher Abhängigkeiten gibt es in JDBC eine Escape-Klausel. Diese 

Klausel wird vom Treiber erkannt und dann in den spezifischen Dialekt des DBMS 

transformiert. Eine Escape-Klausel besteht aus einem Schlüsselwort und einer Menge von 

Parametern. 

{ …} 

Seite 254

Beispiel: Outer-Join mit Escape-Klausel 

Outer-Join mit Escape-Klausel 


from {oj Emp left outer join Proj 

on Emp.pid = Proj.id} 


– Der Funktionsumfang von Escape-Klauseln hängt stark vom jeweiligen Treiber ab! 

– Ein bekanntes Beispiel für Inkompatibilitäten ist die Schreibweise für Datumskonstanten. 

Mit Escape-Klausel kann folgende Schreibweise für den 6.1.2003 benutzt werden: {d 

´2003-01-6´} 

Ergebnisgröße und Laufzeiten von Anfragen 

� Mit der Methode setMaxRows kann die maximal erwünschte Anzahl von Ergebnissen 

spezifiziert werden und mit setQueryTimeout die maximal akzeptierte Ausführungszeit. 

Seite 255

ResultSet 

getXXX 

Datentypen 

Wichtige Klassen bei JDBC 

executeQuery 

getResults 

executeQuery 

setXXX 

getXXX 

Statement 

IS-A 


IS-A 

CallableStatement 

createStatement 

prepareStatement 

prepareCall 


Connection 

DriverManager 

getConnection 

� Die Namen in den Rechtecken entsprechen den Namen der verfügbaren Schnittstellen 

� Die gerichteten durchgezogenen Kanten zeigen, wie man ein Objekt einer Klasse (auf die eine 

Kante gerichtet ist) mit Hilfe der anderen Klasse erzeugt. 

Seite 256



� Ein PreparedStatement ist eine Spezialisierung eines Statements, wobei die SQL-Anweisung 

beim Erzeugen des Statements (bis auf Parameter) vorliegen muß. 

– Dieses Statement wird bereits bei der Erzeugung übersetzt und kann ohne 

Neuübersetzung beliebig oft ausgeführt werden. 

– Eingabeparameter sind erlaubt, die erst bei Ausführung mit Werten belegt werden. 

� Bei der Definition eines PrepapredStatement werden die Eingabeparameter jeweils durch ein 

Fragezeichen markiert. 

– PreparedStatement stmt = con.prepareStatement(“select x, y from Points where x < ? and 

x > ?”); 

� Vor der Ausführung einer Anweisung müssen die Parameter durch set-Methoden gesetzt 

werden. Für jeden Typ gibt es eine spezielle Methode. 

– stmt.setInt(1, 20); stmt.setInt(2, 10); 

// Erste Parameter der set-Methoden ist die Stelle des Parameters in der 

// Anweisung. 

� Zur Übergabe von NULL-Werten und großen Objekten gibt es spezielle Methoden: 

– void setNull(int stelle, int jdbcType); 

// Der zweite Parameter identifiziert ein Typ, siehe java.sql.Types 

– void setAsciiStream(int stelle, java.io.InputStream s, int len); 

Seite 257

Ergebnisse von Anfragen 


� Anfragen mit Select-Klausel liefern als Ergebnis ein Objekt der Klasse ResultSet. 

– Repräsentation einer Menge von Tupeln mittels eines Cursors. 

� Methode next() liefert beim erfolgreichen Weitersetzen des Cursors true, wobei zu Beginn der 

Cursor vor dem ersten Tupel steht (Ein Aufruf von next ist deshalb vor dem ersten Zugriff 

zwingend erforderlich). 

� Zugriff auf die Spalten erfolgt über get-Methoden, wobei es für jeden Typ int, double, … 

jeweils eine solche Methode gibt. 

– Parameter der get-Methode ist die Position der Spalte in der Relation. 

– Eine Methode findColumn(String str) liefert zu einem Attributnamen die Position. 

– Eine weitere Besonderheit von JDBC ist die Methode getObject, die zu dem SQL-Typ 

einen passenden Java-Objekttyp generiert. 

� Null-Werte erfordern wiederum eine Sonderbehandlung. 

– boolean wasNull() 

überprüft, ob das zuletzt abgefragte Attribut tatsächlich ein Nullwert war. 

– Dieser Methodenaufruf ist nur in folgenden Fällen sinnvoll: 

a) Wenn die get-Methode den Wert null liefert. 

b) Wenn getBoolean den Wert false liefert. 

c) Wenn getInt und getDouble den Wert 0 liefert. 

Seite 258

7.1.4 Metadaten 


� Durch Ausnutzung der Metadaten der zugrunde liegenden Datenbank können Anwendungen 

erheblich flexibler gestaltet werden. 

� JDBC bietet folgende Schnittstellen für Metadaten an 

– ResultSetMetaData zur Beschreibung der Relation, die das Objekt der Klasse ResultSet 

verwendet. 

– DatabaseMetaData zur Beschreibung der eigentlichen Datenbank 

ResultSetMetaData 

� ist insbesondere dann von Vorteil, wenn der Benutzer nicht genau weiß, welche der get- 

Methoden bei einem Objekt rs der Klasse ResultSet tatsächlich angewendet werden sollen. 

� Abhilfe schafft dann der Aufruf rs.getMetaData(), der zu rs die Metadaten liefert. 

� Damit kann z. B. die Anzahl der Spalten, der Typ und Name einer Spalte abgefragt werden. 

� Beispiel: 

ResultSet rs = stmt.executeQuery(“SELECT * FROM Personal”); 

ResultSetMetaData rsm = rs.getMetaData(); 

Seite 259

for (int i = 1; i

7.1.5 Ausnahmebehandlung 


� Wie üblich in Java werden ungewöhnliche Situationen durch Verwendung des Exception- 

Konzepts behandelt. Hierfür gibt es eine eigene Klasse SQLException, auf die wir hier nur 

verweisen wollen. 

� Zusätzlich können “unkritische” Fehler auch als Warnungen nach außen gegeben werden. 

– Warnungen sind Objekte von der Klasse SQLWarning bzw. von SQLWarning 

abgeleiteten Klassen. 

– Beispiel: Klasse DataTruncation 

Eine solche Warnung wird beim Lesen von Daten gegeben, wenn diese nicht vollständig 

eingelesen werden konnten. 

Seite 261


7.1.6 Abbildung von SQL-Typen in Java 

� Da das Typsystem der verschiedenen DBMS recht unterschiedlich ist, bietet JDBC zur 

Überwindung der Inkompatibilitäten in der Klasse java.sql.Types einige generische 

Typbezeichner an. 

– z. B. VARCHAR, LONGVARBINARY, INTEGER, DOUBLE, DATE, TIME 

� Diese Typen (repräsentiert als ganzzahlige Konstanten) sind dann dort einzusetzen, wo SQL- 

Typen anzugeben sind. Die Umsetzung in die spezifischen Typen des zugrunde liegenden 

DBMS erfolgt automatisch über den Treiber. 

� Ähnliche Vorgehensweise steckt hinter den Aufrufen der getXXX- und setXXX-Methoden. 

– Es erfolgt hierbei eine Konvertierung von einem Java-Typ in einen JDBC-Typ und 

implizit durch den Treiber in einen Typ des zugrunde liegenden DBMS. 

� Darüber hinaus ist zu beachten, dass die Datums- und Zeittypen von Java aus dem Package 

java.sql stammen. 

– Diese sind im Wesentlichen Wrapper-Klassen für die aus dem Package java.util. 

Seite 262


7.1.7 Erweiterungen: JDBC 2 und JDBC 3+4 

Entwicklung von JDBC 

� Die bisherige Beschreibung entspricht im Wesentlichen dem ursprünglichen JDBC-Standard, 

der aber bereits 1998 wesentlich erweitert wurde (JDBC 2). 

� In Java 6 wird inzwischen JDBC 4 unterstützt. 

� JDB4-kompatible Treiber werden ebenfalls angeboten. 

Überblick der Erweiterungen 

� Scrollen auf Objekten der Klasse ResultSet, Unterstützung von Änderungsoperationen 

� Unterstützung von Typen aus SQL99 (JDBC3) und SQL 2003 (JDBC4) 

� Batch-Updates 

� Sicherungspunkte 

� Weitere optionale Änderungen im Package javax.sql 

Seite 263

Erweiterungen von ResultSet 


� Flexible Positionierung in einem ResultSet 

– vorwärts 

– rückwärts 

– direkt 

� Dies hört sich zunächst relativ unspektakulär an, hat aber erhebliche Auswirkungen. Es werden 

jetzt mehrere Typen von ResultSet angeboten 

– forward-only 

Das entspricht der zuvor beschriebenen Funktionalität von ResultSet. 

– scroll-insensitiv 

Dieser Typ unterstützt das Durchlaufen in beliebigen Richtungen, wobei sich Änderungen 

auf den Datenbestand nicht auswirken. 

– scroll-sensitiv 

Dieser Typ unterstützt ebenfalls beliebiges Navigieren, aber Änderungen von anderen 

Transaktionen werden dabei sichtbar. 

� Darüber hinaus wird noch unterschieden zwischen 

– read-only: keine Änderungen auf den Daten zulässig. 

– updatable: Änderungen, Löschen und Einfügen werden unterstützt. 

Seite 264


� Erzeugen von scrollbaren Objekten der Klasse ResultSet erfolgt über eine neue Methode, die 

zusätzlich zwei Parameter umfasst: 

– resultSetType (vom Typ int) spezifiziert den jeweiligen Typ 

– resultSetConcurrency (vom Typ int) gibt an, ob das Objekt nur lesbar oder auch 

änderbar ist. 

Beispiel: 

Statement stmt = con.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE, 

ResultSet.CONCUR_READ_ONLY); 

ResultSet srs = stmt.executeQuery("SELECT Name FROM Personal"); 

� Dabei ist zu beachten, dass einige Treiber nicht die komplette Funktionalität unterstützen. Um 

sicher zu gehen, muss man auf die Methode 

boolean supportsResultSetType(int resultSetType) 

aus der Klasse java.sql.DatabaseMetaData zurückgreifen. 

Seite 265

Scrollen 


� Initiales Positionieren eines ResultSet 

– void beforeFirst() // Cursor ist vor dem ersten Element 

– void afterLast() // Cursor ist hinter dem letzten Element 

– boolean first() // Cursor ist auf dem ersten Element 

– boolean last() // Cursor ist auf dem letzten Element 

� Navigieren auf einem ResultSet 

– Neben der Methode boolean next() gibt es noch die Methode 

boolean previous() // Setzt den Cursor auf das Vorgängerelement. 

– Darüber hinaus besteht die Möglichkeit den Cursor direkt auf eine absolute Adresse 

boolean absolute(int row) 

und auf eine Adresse relativ zum aktuellen Tupel 

boolean relative(int row) 

zu setzen. Dabei ist zu beachten, dass das erste Element die Position 1 besitzt. 

� Abfragen von der Cursorposition 

– Hierzu kann man direkt int getRow() aufrufen. 

– Zusätzlich gibt es noch Methoden boolean isBeforeFirst(), boolean isAfterLast(), 

boolean isFirst(), boolean isLast(). 

Seite 266

Änderungsoperationen 


� Bei Änderungsoperationen auf ResultSet-Objekten ergibt sich die gleiche Problematik wie bei 

Sichten (Views), dass diese nämlich nur sehr eingeschränkt möglich sind. 

– Die Anfrage beinhaltet nur eine Relation und keine Verbundoperation. 

– Der Primärschlüssel ist Bestandteil der Ergebnisrelation. 

– Alle Attribute, die nicht NULL-Werte zulassen und keine Defaultwerte besitzen, sind 

ebenfalls Bestandteil der Ergebnisrelation. 

� Änderungen (Update eines bestehenden Tupel) 

– Diese Operation bezieht sich stets auf das aktuelle Tupel des ResultSet. 

– Spaltenwerte können über die updateXXX-Methoden geändert werden. 

rs.updateDouble(“price”, 9.99); 

– Nach den Änderungen auf einem Tupel muss noch die Methode 

rs.updateRow(); 

gerufen werden, um die Änderung tatsächlich in die Datenbank zu übertragen. 

� Einfügen eines neuen Tupel 

– Jedes ResultSet-Objekt verfügt über einen internen Datensatz zum Einfügen. Das 

Einfügen kann analog zum Update vorbereitet und danach mt dem Aufruf von insertRow 

abgeschlossen werden. 

Seite 267


– Zuerst muss man an die richtige Stelle positioniert werden 

rs.moveToInsertRow(); 

– Danach können über die updateXXX-Methoden die Attributwerte des neuen Tupel 

eingegeben werden. 

– Schließlich muss noch durch den Aufruf 

rs.insertRow(); 

das neue Tupel übertragen werden. 

– Ein Aufruf der Methode moveToCurrentRow sorgt dafür, dass der Cursor auf der 

vorherigen Position steht. 

� Löschen eines Tupel 

– Zunächst muss auf das zu löschende Tupel navigiert werden. Danach kann durch Aufruf 

der Methode 

rs.deleteRow() 

das Tupel gelöscht werden. 

Sichtbarkeit von Änderungen 

� Damit kann man steuern, ab welchem Zeitpunkt eine Änderung im AWP tatsächlich sichtbar 

wird. 

– sofort nach der Änderung 

– am Ende der Transaktion 

Seite 268

Problem 

Techniken zur Leistungssteigerung 


� Tupelweiser Zugriff auf ResultSet erfordert bei jedem next-Aufruf Kommunikation mit dem 

DBMS-Server. 

� Änderungsoperationen können nur einzeln an das DBMS übergeben werden. 

Prefetching von Resultaten 

� Statt nur das nächste Tupel werden die nächsten k Tupel vom DBMS-Server angefordert. 

Durch Aufruf der Methode void setFetchSize(int rows) wird die Anzahl der Ergebnisse pro 

Anforderung spezifiziert. 

Seite 269

Batch-Updates 


� Bündelung von mehreren Änderungsoperationen, die gemeinsam an die zugrunde liegende 

Datenbank geschickt werden. 

� Hierzu gibt es folgende Methoden 

– void addBatch(String sql); // Fügt eine neue Änderungsoperationen zum Batch 

– int[] executeBatch(); // Führt einen Batch aus, wobei als Ergebnis die 

// Anzahl der betroffenen Tupel geliefert wird. 

Beispiel ( mit Relation Emp(Name,Gehalt)): 

� Sourcecode 

con.setAutoCommit(false); 

Statement stmt = con.createStatement(); 

stmt.addBatch("INSERT INTO Emp " + "VALUES('Müller', 3000)"); 

stmt.addBatch("INSERT INTO Emp " + "VALUES('Schmidt', 4000)"); 

stmt.addBatch("INSERT INTO Emp " + "VALUES('Becker', 3500)"); 

stmt.addBatch("INSERT INTO Emp " + "VALUES('Bauer', 900)"); 

int [] updateCounts = stmt.executeBatch(); 

con.commit(); 

con.setAutoCommit(true); 

Seite 270

Connection Pooling 


� Problem 

– Herstellung der physischen Verbindung zum Server ist eine teuere Operation. 

– In vielen Web-Anwendungen werden ständig Verbindungen auf- und abgebaut, viele 

Verbindungen werden nicht im vollen Umfang genutzt. 

� Lösungsidee 

– Bereitstellung von logischen Verbindungen, die auf wenige physische Verbindungen 

abgebildet werden. 

� Funktionalität unter JDBC 

– initialPoolSize initiale Anzahl der physischen Verbindungen 

– minPoolSize minimale Anzahl der physischen Verbindungen 

– maxPoolSize maximale Anzahl der physischen Verbindungen 

– maxIdleTime Zeitdauer (in Sekunden) die eine physische Verbindung ungenutzt im 

Pool bleiben soll. 

� Erweiterung für PreparedStatements 

– Pooling von Statements (nicht nur von Verbindungen) 

Seite 271

7.1.8 Zusammenfassung 


� JDBC hat sich als relativ leicht zu nutzende Call-Schnittstelle für die Erstellung von AWP 

erwiesen. 

– Anfragen werden in Objekte der Klasse Statement gepackt 

– Resultat einer Anfrage steht als Objekt der Klasse ResultSet zur Verfügung 

� Flexible Programmierung durch Unterstützung von Metadaten 

� JDBC wurde in den letzten Jahren um weitere Funktionalität erweitert. 

– Insbesondere zur flexibleren und effektiveren Nutzung von ResultSet. 

– Unterstützung des neuen SQL-Standards (bisher noch nicht behandelt) 

– Weitere Erweiterungen sind optional und sind in dem Package javax.sql zu finden. 

� Nachteile von JDBC 

– Abbildung der Typen zwischen Java und dem JDBC-Treiber (indirekt also dem DBMS) 

muss vom Benutzer vorgenommen werden. 

– Viele Fehler treten erst zur Laufzeit auf. 

– So genannte JDBC-konforme Treiber unterstützen nur einen relativ geringen 

Befehlsumfang. Damit sind oft Applikationen abhängig von dem jeweiligen Treiber 

(alternativ könnten auch die Eigenschaften eines Treibers erst erfragt werden, was aber 

die Programmierung erheblich erschwert). 

Seite 272

7.2 Embedded SQL (eSQL, SQLJ) 

� Grundlegendes Prinzip: Verwendung eines Vorübersetzers 

� Statische Festlegung der Datenbankoperationen zur Übersetzungszeit 

– Typenüberprüfung zwischen AWP und Datenbank durch den Vorübersetzer 

– einfache Übertragung von Daten aus der Datenbank ins AWP 

� Verwendung des Cursor-Prinzips zum Durchlaufen von Relationen 

Quelldateien 

Vor-Compiler 

Host-Compiler 

Host-Linker 

Zwischencode 

DBMS-Bibliothek 

AWP DBMS-Server 

Datenbank 


Seite 273

SQLJ 


� Embedded SQL wurde zunächst für die Programmiersprache C entwickelt. 

� Auf Grund der großen Akzeptanz von Java und JDBC bieten führende Datenbankhersteller 

(IBM, Oracle, Sybase) einen entsprechenden Ansatz für Java unter dem Namen SQLJ an. 

� SQLJ nutzt dabei typischerweise JDBC zur Codegenerierung. 

SQLJ-Quelle 

Zusatzinformationen 

über die SQL- 

Anweisungen 

SQLJ-Compiler 

Java-Compiler 

Java-Quelle 

Bytecode 

SQLJ-Laufzeit 

SQLJ-Profil 

JDBC 

JDBC-Bibliothek 

DBMS-Server 

Datenbank 

Seite 274


Syntaktische Kennung von Datenbankoperationen im SQLJ-AWP: 

� #sql {SQL-Befehl} 

� Ein SQL-Befehl bezieht sich auf die Objekte der Datenbank. Eine Ausnahme sind die 

sogenannten Hostvariablen, die zur Kommunikation zwischen der Datenbank und dem AWP 

genutzt werden. 

– Eine Hostvariable wird wie eine gewöhnliche Variable von Java deklariert und genutzt. 

– Eine Hostvariable kann auch in einem SQL-Kommando angesprochen werden, indem 

dem Variablennamen ein “:” vorgestellt wird. 

� Man kann auch Hostvariablen dazu nutzen, Ergebnisse einer Anfrage aufzunehmen, wobei 

dann nur ein Tupel als Ergebnis geliefert werden darf und nicht eine Menge. 

– select-Klausel wird um das Schlüsselwort into gefolgt von Hostvariablen ergänzt. 

Beispiele 

� #sql {select A, B from R where B > :x} 

Hier wird der Wert der Hostvariablen x in den SQL-Befehl eingesetzt. 

� #sql {select A, B into :a, :b from R where Id = 7} 

– Das Ergebnis wird nun in die Hostvariablen a und b übertragen (Ann.: Id ist 

Schlüsselkandidat). 

– Die Typen der Hostvariablen müssen zu den SQL-Typen kompatibel sein. 

Seite 275


Öffnen einer Datenbankverbindung 

� Ähnlich wie bei JDBC braucht man in SQLJ einen Bezug zu einer bestehenden Datenbank. 

Aus diesem Grund kann nun ein Kontext definiert werden: 

#sql context Verbinden 

Danach kann Verbinden wie eine Klasse benutzt werden, die insbesondere folgenden Konstruktor 

besitzt: 

Verbinden verbindungsObject = new Verbinden("jdbc:oracle:thin:@venus.mathematik.unimarburg.de:1521:Init_DB", 

"scott", "tiger"); 

Dieses Kontextobjekt kann nun bei einem sql-Befehl noch zusätzlich angegeben werden: 

#sql (verbindungsObject) {select A, B from R where B > :x} 

� Wird bei einem sql-Befehl kein Kontextobjekt angegeben, so wird ein Defaultkontextobjekt 

genutzt, das zuvor aber erzeugt werden muss: 

DefaultContext ctx = new DefaultContext(DriverManager.getConnection(…)); 

Seite 276


Anfrageformulierung mit Iteratoren 

� Für SQL-Anweisungen, die mehr als eine Antwort liefern, können nun Iteratoren (Cursor) 

definiert werden. Es wird unterschieden zwischen positionsbezogenen und namenbezogenen 

Iteratoren. 

� Positionsbezogene Iteratoren (Beispiel): 

– Deklaration: 

#sql public iterator Pos (String, int); 

Damit wird ein Iteratortyp Pos mit zwei Komponenten definiert. 

– Danach kann man eine Variable des Typs deklarieren: 

Pos x; 

– Ein sql-Befehl kann an diese Variable gebunden werden: 

#sql x = {select A, B from R where B > 10}; 

– Der Zugriff auf die Ergebnismenge erfolgt dann i. A. in einer Schleife: 

while (true) { 

#sql {fetch :x into :a, :b}; // impliziter Aufruf von next 

if (x.endFetch()) break; 

System.out.println(a + “ verdient “ + b + “ €”); 

} 

Seite 277


– Freigabe der Ressourcen: 

x.close(); 

� Namensbezogene Iteratoren 

– Deklaration: 

#sql public iterator Name (String A, int B); 

– Deklaration einer Variablen 

Name y; 

– Anbinden an einen SQL-Befehl: 

#sql y = {select A, B from R where B > 10}; 

Die Ergebnisrelation muss alle im Attribut deklarierten Attribute enthalten! 

– Zugriff auf die Ergebnismenge: 

while (y.next()) 

System.out.println(y.A() + “ verdient “ + y.B() + “ €”); 

Man beachte hierbei, dass 

- der Zugriff auf die Werte über Methodenaufrufe erfolgt, wobei der Name der 

Methode dem des Attributs entspricht. 

- Mit der Methode next wird auf das nächste Tupel zugegriffen. 

Seite 278

Mengenwertige Änderungs- und Löschoperationen 


� Solche Operationen verwenden auch Iteratoren, wobei die zu ändernde (löschende) 

Datenmenge an den Iterator gebunden wird. 

� Danach können folgendermaßen die Änderungen vorgenommen werden. 

#sql public iterator Name implements sqlj.runtime.ForUpdate (String A, int B) 

// Hierbei muss der Iterator die oben genannte Schnittstelle implementieren. 

… 

Name y; 

… 

#sql y = {select A, B from R where B > 10}; 

… 

while (y.next()) 

#sql {update R set B = B + 10 where current of :y} 

Damit wird nun der derzeit angesprochene Datensatz der Menge geändert. 

� Zusätzliche Eigenschaften eines Iterators können bei der Deklaration durch eine with-Klausel 

gesetzt werden. 

– #sql public iterator Name implements sqlj.runtime.ForUpdate (String A, int B) with 

(sensitivity=SENSITIVE); 

Seite 279


7.3 Prozedurale Erweiterung von SQL 

� Neben der Einbindung der SQL-Funktionalität in einer imperativen Programmiersprache, 

besteht auch die Möglichkeit, SQL um prozedurale Konzepte zu erweitern. 

– Dies ist bereits als Anhang zum SQL92-Standard unter dem Namen SQL/PSM (Persistent 

Stored Modules) berücksichtigt. 

– Oracle hat unter den Namen PL/SQL eine solche Erweiterung bereits frühzeitig definiert, 

die im industriellen Umfeld zur Entwicklung von AWPs genutzt wird. 

– Oracle und andere Anbieter (IBM) bieten inzwischen an, in Java codierte Prozeduren im 

DBS ablaufen zu lassen. 

� Primäres Ziel der prozeduralen Erweiterung von SQL 

– Bündelung von mehreren SQL.Befehlen unter einer aufrufbaren Einheit, die in der 

Datenbank persistent abgespeichert und auf dem Server ausgeführt wird. 

� Vorteile zu bisherigen Ansätzen 

– Serverseitige Ausführung der Prozeduren ==> Unabhängigkit vom Client 

– Leistungsverbesserung, da die Kommunikation zwischen Client und Server erheblich 

reduziert werden kann. 

– Zentrale Verwaltung von gemeinsam genutzter Funktionalität 

Seite 280

Vorgehensweise 


� Implementierung einer Prozedur oder Funktion 

� Installation der Prozedur auf dem Server 

� Registrierung der Prozedur auf dem Server 

– Hierzu benutzt man die SQL-Operationen create procedure bzw. create function. 

� Aufruf der Prozedur vom Client 

– Dies geschieht indirekt über das DBMS. 

Seite 281

7.3.1 PL/SQL 


� PL/SQL ist eine von Oracle entwickelte Erweiterung von SQL, die primär zur Erstellung von 

gespeicherten Prozeduren entwickelt wurde. 

– Syntax orientiert sich an der Programmiersprache Ada 

� PL/SQL bietet insbesondere die Möglichkeit, Prozeduren zu deklarieren und diese in SQL 

aufzurufen. 

Vorteile gegenüber einer Hostsprache 

� homogene Anbindung der imperativen Konzepte an SQL 

� Typkonvertierungen entfallen 

� plattformunabhängige Ausführung 

Nachteil: 

� Imperative Konzepte sind für eine vollständige Entwicklung von AWP nicht ausreichend. 

Seite 282

PL/SQL Block 


� Ein PL/SQL-Block besteht aus drei Teilen: 

– einem optionalen Deklarationsteil zur Deklaration von Variablen und Objekten, 

– einem Rumpf, in dem der Zustand der Variablen manipuliert wird, 

– einem optionalen Ausnahmebehandlungsteil, in dem Ausnahmen und Fehler zur Laufzeit 

behandelt werden. 

� Definition eines Blocks: 

[ is] 

[declare ] 

begin 

 

[exception ] 

end 

Seite 283

Deklarationsteil 


� Typdeklarationen 

– Neben den SQL-Typen, können Variablen PL/SQL Typen wie boolean haben. 

– PL/SQL unterstützt insbesondere auch die Definition von Record-Typen: 

type PersonTyp is record (Name varchar(50), Salary int); 

– Weiterhin erlaubt PL/SQL auch indirekt über Relationen und Variablen erzeugte Typen. 

� Variablendeklarationen 

– Eine Variable wird ähnlich wie bei SQL durch Nachstellen des Typs deklariert: 

ang PersonTyp; 

– Eine Besonderheit ist, dass die Datentypen der Relationen bei der Variablendeklaration 

benutzt werden können: 

ang Personal%rowtype; 

– Entsprechend wird durch 

ang2 ang%type; 

eine Variable vom Typ der Variable ang deklariert. 

– Ähnlich wie in Pascal erstreckt sich der Gültigkeitsbereich einer Variablen auf den 

lokalen Block und alle Blöcke, die in diesem enthalten sind. 

– Die grundlegende Operation für Variablen ist die Zuweisung. Das Symbol ist ’:=’ ! 

Seite 284

Cursor 


� Ein Cursor unterstützt die sequentielle Verarbeitung einer Datenmenge. 

� Cursordeklarationen 

– konstanter Cursor 

cursor AlleAng is 

select * 

from Personal; 

– parametrisierter Cursor 

cursor interessantePersonen(von int, bis int) is 

select * 

from Personal 

where Lohn > von and Lohn < bis; 

� Cursor und ihre Attribute 

Gewisse Eigenschaften von Cursorn können zur Laufzeit durch Anhängen eines Suffix 

abgefragt werden: 

– %found : Der letzte Fetch-Befehl auf dem Cursor war erfolgreich. 

– %isopen : Der Cursor ist geöffnet 

– %rowcount : Anzahl der Tupel des Cursors 

Seite 285

Imperative Ablaufsteuerung 

Kontrollstrukturen 

� bedingte Anweisung 

if then end if; 

� for-Schleife 

for in 

loop 

 

end loop; 

Verarbeitung eines Cursors 


� Öffnen eines Cursors 

open AlleAng; 

open interessantePersonen(1000, 2000); 

� Spezielles Schleifenkonstrukt für einen Cursor zur Verarbeitung einer Antwortmenge 

for ang in AlleAng 

loop 

 

end loop; 

Seite 286

Prozeduren und Funktionen 


� Eine Prozedur ist ein Block, der mit einem Namen versehen ist und optional über eine 

Parameterleiste verfügt. 

� Eine Funktion liefert durch den Befehl return stets ein Ergebnis. 

function totalSalary(von int, bis int) return int is 

declare 

p Personal%rowtype; 

total int; 

begin 

open interessantePersonen(von, bis); 

… 

return total; 

end; 

� Die Parameter können mit drei verschiedenen Optionen versehen sein: in, out, in out 

procedure run (par1 in Typ1, par2 out Typ2, par3 in out Typ3, …) is 

 

Seite 287

Gespeicherte Prozeduren 


� Mittels des Befehls create procedure können Prozeduren im Datenbanksystem in übersetzter 

Form abgespeichert werden. 

– Dies hat insbesondere den Vorteil gegenüber dem bisherigen Ansatz von PL/SQL, dass 

die Anweisungen nicht mehr übersetzt werden müssen. 

� Die Deklaration einer Prozedur (Funktion) folgt dem bereites vorher erläuterten Muster 

Cursor-Variablen 

� Es ist oft günstig, die Ergebnisse einer gespeicherten Prozedur durch Cursor-Variablen an das 

aufrufende PL/SQL-Programm zu geben. 

� Eine Cursor-Variable ist eine Referenz auf eine Liste von Datensätzen. Es wird zwischen 

folgenden Typen von Cursor-Variablen unterschieden: 

– starker Typ: 

type personenCurTyp is ref cursor Personal%rowtype; 

– schwacher Typ: 

type allCurTyp is ref cursor; 

Die Variablendeklaration wird wie üblich vorgenommen. 

� Zum Zeitpunkt der Deklaration hat die Cursor-Variable noch keinen Bezug zu einer Anfrage. 

Seite 288


� Anbindung einer Cursor-Variable an eine Anfrage 

– erfolgt erst beim Öffnen eines Cursors: 

open personenCurTyp for 

select * from Personal where Lohn > 1000; 

� Typische Verwendung 

– Öffnen einer Cursor-Variablen in der gespeicherte Prozedur/Funktion 

– Übergeben des Cursors an das AWP, wo dann die Datensätze verarbeitet werden. 

Trotz der vielen Vorteile, die Cursor-Variablen bieten, gibt es derzeit bei der Nutzung in Oracle 

noch sehr viele Einschränkungen: 

– Eine Cursor-Variable darf nicht im Update-Modus geöffnet werden. 

– Den Typ ref cursor gibt es nur in PL/SQL, aber nicht in SQL. 

Seite 289

Beispiel 1 


� Erhöhe das Gehalt der Angestellten um 10%, die bisher unter dem Durchschnitt verdient 

haben. Gib das aktuelle Durchschnittsgehalt aus, falls dieses 50000 überschreitet. 

declare 

dGehalt number; 

begin 

select avg(Lohn) into dGehalt from Personal; 

update Personal set Lohn = Lohn*1.1 where Lohn < dGehalt; 

select avg(Lohn) into dGehalt from Personal; 

if dGehalt > 50000 then 

dbms_output.put_line(“Durchschnitt: “ || dGehalt); 

end if; 

commit; 

exception 

when others then dbms_output_line(“Fehler beim Update”); 

rollback; 

end; 

Seite 290

Beispiel 2 


� Berechne die Gehaltserhöhung der Angestellten in Abhängigkeit ihres bisherigen Gehalts. 

declare 

begin 

cursor angCursor is select Lohn from Personal for update of Lohn; 

angNr integer; 

angGehalt Personal.Gehalt%type; 

open angCursor; 

fetch angCursor into angGehalt; 

while angCursor%found 

if angGehalt > 60000 

update Personal set Lohn = Lohn*1.1 where current of angCursor; 

elsif angGehalt > 50000 


else 


Seite 291

end; 

end if; 

fetch angCursor into angGehalt; 

end loop; 


Seite 292

Gespeicherte Prozeduren in JDBC 


� Gespeicherte Prozeduren lassen sich mittels JDBC aufrufen, indem ein Objekt der Schnittstelle 

CallableStatement erzeugt wird. 

� Der Aufruf einer gespeicherten Prozedur erfolgt über die Methode prepareCall, die als 

Parameter eine Zeichenkette in Escape-Schreibweise hat. 

CallableStatement cstmt = con.prepareCall(“{call TestProc(?,?)}”); 

Parameter werden dabei wie in JDBC üblich mit dem Symbol ? gekennzeichnet. 

� Danach müssen die Werte der Eingabeparameter mit setXXX-Methoden gesetzt werden. 

cstmt.setString(1,’Schneider’); 

cstmt.setDouble(2,42.0); 

� Für die Ausgabeparameter muss vor der Ausführung noch der JDBC-Typ festgelegt werden 

(Ann.: 1. Parameter ist IN und der 2. Parameter InOut): 

cstmt.registerOutParameter(2,java.sql.Types.FLOAT); 

� Die Prozedur kann dann mit einem Aufruf von execute aufgerufen werden. 

� Danach können die Ausgabeparameter mit getXXX-Methoden ausgelesen werden. 

double res = cstmt.getDouble(2); 

Seite 293

Gespeicherte Funktionen in SQL 


� Gespeicherte Funktionen können innerhalb von SQL deklariert und auch aufgerufen werden. 

Aber es gelten folgende Einschränkungen: 

– Die Funktion darf keine Gruppierungsoperationen enthalten. 

– Alle Datentypen der Eingabe und der Ausgabe müssen dem Datenbanksystem bekannt 

sein (also keine PL/SQL-Typen) 

� Beispiel einer gespeicherten Funktion: 

create function simple(x in int) return int as 

begin 

return x / 101; 

end simple; 

� Beispiel des Aufrufs einer Funktion in einer SQL-Anfrage: 

select Name, simple(Lohn) from Personal; 

Seite 294


7.3.2 Trigger: Ein Anwendungsfall für 

gespeicherte Prozeduren 

� Ein Trigger ist eine gespeicherte Prozedur, die bei Erfüllung gewisser Kriterien oder als 

Seiteneffekt einer Änderungsoperation in der Datenbank vom DBMS implizit ausgeführt wird. 

– Eine Ausführung erfolgt immer dann, wenn ein bestimmtes Ereignis eintritt. 

� Trigger werden insbesondere zur Wahrung der Datenkonsistenz (dynamische 

Integritätsbedingungen) genutzt. Trigger gehen deshalb über eine reine Überprüfung des 

Datenbankzustands hinaus. 

– Ein Trigger kann z. B. dafür sorgen, dass Statistiken aktualisiert werden oder abgeleitete 

Spalten berechnet werden. 

� Ein Trigger besteht aus 

– einem Kopf, in dem Vorbedingungen zur Ausführung formuliert sind, 

– und einem PL/SQL-Block. 

� Trigger sind nicht im SQL92 Standard, haben aber eine hohe praktische Relevanz. 

Seite 295

Einführendes Beispiel 


� Im Folgenden betrachten wir eine Relation Professoren, die als Attribut den Rang des 

Professors besitzt (siehe Kemper/Eickler). Durch den folgenden Trigger wird verhindert, dass 

der Rang von Professoren durch einen Update niedriger wird. 

create trigger keineDegradierung 

before update on Professoren 

for each row 

when (:old.Rang is not null) 

begin 

if :old.Rang = “C3” and :new.Rang = “C2” then :new.Rang := “C3”; end if; 

if :old.Rang = “C4” then :new.Rang := “C4”; end if; 

if :new.Rang is null then :new.Rang := :old.Rang end if; 

end; 

Seite 296

Kopf eines Triggers 


� Anlegen bzw. Verändern eines neuen bzw. bestehenden Trigger erfolgt über 

– create trigger bzw. replace trigger 

� Trigger-Ereignis 

– Jedem Ereignis wird der Zeitpunkt vorangestellt, wann der Trigger ausgelöst werden soll. 

before | after 

– Beim Ereignis wird unterschieden zwischen Ändern, Einfügen und Löschen. 

update [of [] on 

insert on 

delete on 

Es können auch gleichzeitig mehrere Ereignisse spezifiziert werden. In diesem Fall kann 

im Rumpf des Trigger durch 

if updating [(’’)] then 

if inserting then 

if deleting then 

zwischen den einzelnen Ereignissen unterschieden werden. 

� Trigger-Typ 

Es wird unterschieden zwischen einen befehlsorientierten Trigger, bei dem der Trigger genau 

einmal ausgeführt wird und einem zeilenorientierten Trigger. Letzteres erfordert zusätzlich 

folgende Zeile: 

Seite 297


for each row 

Bei einem zeilenorientierten Trigger wird der Trigger für jedes geänderte Tupel einmal 

aufgerufen. Im Rumpf hat man dann die Möglichkeit, das alte Tupel über die Variable :old und 

das neue Tupel über :new anzusprechen. Ein anderer Zugriff innerhalb des Rumpfs ist aber 

nicht mehr möglich. 

� Trigger-Restriktion 

when 

– Hier können Bedingungen formuliert werden, welche die Ausführung des Rumpfs 

auslösen. 

– Bei einem zeilenorientierten Trigger kann man sich über :new und :old auf die neuen bzw. 

alten Tupel der Relation beziehen. 

� Trigger-Rumpf 

– Besteht aus einem PL/SQL-Block mit den obengenannten Modifikationen 

Seite 298

Beispiele 

� Protokollierung der Änderungen am Attribut Lohn einer Relation Personal 

create trigger LogGehalt 

before update on Personal 

for each row 

when (:old > 1333) 

begin insert into LogRel values(:old.Lohn, :new.Lohn, sysdate) end; 

� Zurücksetzen einer Änderung 

create or replace trigger CheckGehalt 

before update on Personal 

for each row 

when (:new.Lohn > 1500) 

begin :new.Lohn := :old.Lohn end; 

Probleme bei Triggern 


� Gewährleistung der Widerspruchsfreiheit der Trigger durch Anwender 

– Vermeidung von Aufrufzyklen bei Triggern 

– Terminierung 

� Trigger sollten nur dann zur Formulierung von Integritätsbedingungen genutzt werden, wenn 

dies nicht mit anderen Mitteln möglich ist. 

Seite 299


7.3.3 Java und Gespeicherte Prozeduren 

� Im Zuge des Erfolges der Programmiersprache Java im Umfeld von DBMS bieten derzeit 

einige DBMS (DB2, Oracle) die Möglichkeit, gespeicherte Prozeduren in Java zu 

implementieren. 

� Die Vorgehensweise ist sehr ähnlich zu der von PL/SQL: 

– Erstellen einer Quelldatei 

public class Hello { 

public static String world() { return “Hello World”;} 

} 

– Übersetzen der Quelldatei auf dem Client 

javac Hello.java 

– Übergeben der class-Datei an das DBMS 

loadjava -user scott/tiger Hello.class 

– Erzeugen einer SQL-Schnittstelle für die Prozedur 

create function HelloWorld return varchar as 

language java name ’Hello.world() return java.lang.String’; 

– Ausführen der gespeicherten Prozedur 

variable myString varchar[20]; 

call HELLOWORLD() into :myString; 

print myString; 

Seite 300

Fazit 


� PL/SQL ist eine interessante Erweiterung von SQL, die schon vor Java eine 

plattformunabhängige Programmierung angeboten hatte. 

� SQL wird insbesondere durch gespeicherte Funktionen mächtiger. 

� PL/SQL wurde in jüngster Zeit um so genannte Table Functions erweitert. Diese unterstützen 

Cursor, die wie eine Relation in der from-Klausel von SQL genutzt werden können. 

– Dabei wird sogar eine bedarfsgesteuerte Ausführung solcher Cursor unterstützt, d.h. die 

Tupel werden auf Anforderung nach und nach erzeugt. 

� Obwohl nahezu jedes relationale DBMS gespeicherte Prozeduren anbietet und es einen 

Standard SQL/PSM gibt, sind die Lösungen in DBMS derzeit noch recht unterschiedlich. 

Seite 301


7.4 Weitere Kopplungsmöglichkeiten 

PASCAL/R: eine Erweiterung von Pascal für relationale Datenbanken 

� Erweiterung des Typsystems von PASCAL: 

– Datentyp RELATION entspricht “SET OF TUPLE” 

– Operationen der relationalen Algebra 

– Iteratoren (wie Cursor) für die Verarbeitung von Relationen 

Skriptsprachen 

� populärer Ansatz für die Erstellung von AWPs (z. B. Visual Basic) 

� Nachteil 

– keine strenge Typisierung 

– keine Standards (schlechte Wartung der Applikationssoftware) 

– Durchmischung von verschiedenen Konzepten aus dem Bereich Datenbanken, 

imperativen Programmierung, Benutzerschnittstellen und Regeln 

� Vorteil: 

– schnelle Erstellung von AWP mit graphischen Benutzeroberflächen 

– komfortable Entwicklungsumgebung 

Seite 302

8. Physische Datenorganisation 

� Datenbanken 

– externe Ebene 

– konzeptionelle Ebene 

– physische Ebene 

� Leistungsfähigkeit eines DBMS 

– maßgeblich bestimmt durch die Datenstrukturen auf der physischen Ebene 

� Abbildung der konzeptionellen Ebene auf die physische Ebene 

Zugriffsstrukturen 

Pufferorganisation 

Externspeicherverwalt. 

ext. Speichermedium 

Datenobjekte: 

� Datensätze 

� Relationen 

Datenobjekte: 

� Seiten 

� Dateien 

Physische Datenorganisation 

Abbildung 

? 

Seite 302

AWP 1 AWP 2 • • • AWP n 

Anfragebearbeitung 

logische Seitenreferenzen 

Systempufferverwaltung 

physische Seitenreferenzen 

Externspeicherverwaltung 

Plattenzugriffe 

Architektur 

Algorithmen 


– Implementierung der 

Operatoren der 

relationalen Algebra 

Zugriffstrukturen 

– Hilfsdatenstrukturen für 

den schnellen Zugriff auf 

die relevanten 

Datensätze 

Speicherstrukturen 

– Physische 

Repräsentation der 

Relationen 

Seite 303


8.1 Aufbau eines Magnetplattenspeichers 

� Magnetplatten 

– seit über 40 Jahren die Technologie zur persistenten Datenspeicherung 

� Eigenschaften 

– günstig: 10GB für 1€ 

– robust 

– große Speicherkapazität: bis 1 TB/Platte 

– langsam 

� Entwicklung der Plattenspeichertechnologie 

Plattenspeicher 1957 Plattenspeicher heute 

(2.5” Durchmesser) 

0,85 Zoll Durchmesser 

RAID-Plattensysteme 

Seite 304


Funktionsweise von Plattensystemen 

� Festplatte besteht aus einem Stapel übereinander liegender Magnetplatten. 

– Jede Oberfläche hat einen Lese/Schreibarm. 

– Lese/Schreibarme bewegen sich synchron, wobei nur einer davon 

aktiv ist. 

� Strukturierung: 

– Zylinder, Spur und Sektor (Seite) 

– Zugriff über einen Kamm mit Schreib-/Leseköpfen, der quer zur 

Rotation bewegt wird 

� Zugriff auf Seiten 

– Positionierung des Schreib-/Lesekopfes (Seek) 

� Zeit für die Armbewegung [5 ms] 

– Warten auf den Sektor / Seite (Rotationsverzögerung) 

��halbe Rotationszeit der Platte [3 - 4,3 ms] 

– Übertragung der Seite (Transferzeit) 

��Zeit für Schreiben bzw. Lesen einer 4 KByte Seite [0,05 ms] 

– Kontrolle der Übertragung: Zeit des Platten-Controllers [ < 1 ms] 

Zeit für Zugriff einer Seite >> Zeit für Hauptspeicherzugriff ! 

Seite 305

Systempuffer-Verwaltung 

� Umsetzung der logischen in physische Seitenadressen 

Schnittstelle: 


� Bereitstellen einer DB-Seite im DB-Puffer (zur exklusiven oder gemeinsamen Benutzung). 

� Bereitstellen einer neuen Seite 

� Freigeben einer Seite 

intern verwendete Funktionen: 

� Effiziente Suche im Puffer 

– Hash-Tabelle 

� Suche nach freiem Platz im Puffer (Frames) 

� Bestimmen einer Seite (Opfer), die aus dem Puffer entfernt wird. 

– Least-Recently-Used: Verkettung der Seiten nach dem letzten Zeitpunkt der Nutzung 

� Schreiben modifizierter Seiten 

– Erfolgt in Absprache mit der Transaktionsverarbeitung 

Seite 306

8.2 Speicherstrukturen 


� Datenbanken werden typischerweise auf eine Datei bzw. eine Menge von Dateien abgebildet. 

� Beim Anlegen der Datenbank werden noch wichtige Parameter mitgegeben: 

– Initiale Dateigröße 

– Maximale Dateigröße 

– Inkrementelle Größe 

� Beim Anlegen einer Relation wird der Relation eine initiale Seite zugewiesen. 

– Alle weiteren Seiten werden dann miteinander verkettet. 

Tuple-Identifier (TID auch RowID und RID genannt) 

� TID ist eine eindeutige Kennung des Datensatzes innerhalb der Datenbank. Dieser setzt sich 

zusammen aus der Seitenadresse und einer relativen Adresse innerhalb der Seite. 

Seitenadresse: 42 

Der markierte Datensatz hat die TID (42,3) 

Seite 307


– TIDs sind invariant bzgl. Verschiebungen innerhalb einer Seite 

� Die TID ändert sich auch nicht, wenn ein Datensatz in eine andere Seite verschoben wird. 

– Anlegen eines Stellvertreters in der ursprünglichen Seite, der auf die neue Position 

verweist. 

j 

(4711,j) 

Seitenadresse: 42 Seitenadresse 4711 

� Vorteil des TID-Konzepts 

– TID sind stabil 

� Nachteil 

– hohe Zugriffskosten, wenn es viele Stellvertreter gibt. 

==> Reorganisation der Datenbank 

Seite 308

Recordmanager 

� Komponente zur Verwaltung der Datensätze in Seiten 

Zentrale Aufgabe des Recordmanager 


� Für einen neuen Datensatz soll eine Seite mit genügend freiem Speicherplatz gefunden werden. 

– Ggf. muss hierfür eine neue Seite angefordert werden. 

� Wünschenswert wäre auch eine Ballung (Clusterung) der Datensätze: 

– Datensätze, die oft gemeinsam zugegriffen werden, sollen auch gemeinsam in einer Seite 

liegen. 

Unterscheidung 

� Datensätze mit konstanter Länge 

– einfache Lösungen: z. B. Verkettung der Seiten, die noch Platz haben. 

� Datensätze mit variabler Länge 

– relativ kompliziert 

Seite 309

Zugriff auf die Basisrelationen 

Bei Datenbanken unterscheidet man zwischen zwei Zugriffsarten: 


� Relationen-Scan 

– Durchlaufen der zu der Relation gehörenden Seiten. 

� Index-Scan 

– Zugriff erfolgt indirekt über eine Hilfsstruktur, in der die Verweise (TID) auf die 

Datensätze (zusammen mit z. B. einem Attribut) der Relation hinterlegt sind 

(4711,j) 

Index auf dem 

Attribut Lohn 

der Relation Personal 

(1000, (42,3)) (2100, (42,1)) (3000,(4711,2) 

Seitenadresse: 42 Seitenadresse 4711 

j 

Seite 310

Ziel: 

8.3 Indexstrukturen 


� Effizienter Zugriff auf die Datensätze einer Relation, die ein bestimmtes Prädikat erfüllen. 

� Strukturen sollen keinen erheblichen Mehraufwand verursachen. 

– Änderungsoperationen 

– Speicherplatz 

Klassifizierung 

� Eindimensionale Prädikate (bzgl. einem Attribut) 

– Exakte Prädikate: Dyn. Hash-Verfahren 

– Bereichsprädikate und exakte Prädikate: B + - Bäume 

� Mehrdimensionale Prädikate 

– Bereichsprädikate 

� Metrische Prädikate 

– Nachbarprädikate 

� Mengenbasierte Prädikate 

Seite 311

Anforderungen 

Allgemeine Ziele beim Entwurf von Indexstrukturen 

� Hohe Speicherplatzausnutzung 

� Kurze Antwortzeiten für eine Operation 

– Benötigte Zeit entspricht dabei der Anzahl der Seitenzugriffe 

Operationen 


� Suchanfragen 

– Einlesen einer Teilmenge der Daten einer Relation 

– Exakte Suche: select * from R where R.A = c 

– Bereichssuche: select * from R where c1 � R.A and R.A � c2 

� Einfügen, Löschen und Ändern 

– Reorganisationen der Daten des Index erforderlich 

– Reorganisationen sollen nur lokal auf einem kleinen Teil der Daten einwirken 

(dynamische Indexstrukturen) 

Seite 312

8.3.1 Suchbäume 


� Wichtige Datenstruktur für Hauptspeicher und Hintergrundspeicher zur Unterstützung von 

Bereichsprädikaten (siehe Prakt. Info II) 

Definitionen (Baum) 

� Ein Baum ist eine endliche Menge T von Elementen, Knoten genannt, mit: 

(1) Es gibt einen ausgezeichneten Knoten w(T), die Wurzel von T 

(2) Die restlichen Knoten sind in m � 0 disjunkte Mengen T 1 , …, T m zerlegt, die 

ihrerseits Bäume sind. T 1 , …, T m heißen Teilbäume der Wurzel w(T). 

� Der Grad eines Knotens x, deg(x), ist gleich der Anzahl der Teilbäume von x. Gilt deg(x) = 0, 

so nennt man x ein Blatt. 

� Jeder Knoten x außer w(T) hat einen eindeutigen Vorgänger vm(x), auch als Vater/Mutter 

bezeichnet. 

� Ein Pfad in einem Baum ist eine Folge von Knoten x1 , …, xn mit: xi = vm(xi+1 ), i = 1, …, n-1. 

Die Länge des Pfades ist n. 

� Die Höhe eines Baums entspricht der Länge des längsten Pfads. 

Seite 313

Definition (Suchbaum) 


� Sei auf der Menge T eine Ordnungsrelation “

Die schlechte Nachricht! 


� Einfache Abbildung von binären Knoten auf Seiten führt zu schlechten Strukturen. 

– im schlechtesten Fall: ein Knotenzugriff = ein Plattenzugriff 

– exakte Suche ist dann sehr teuer 

z. B. für 107 Datensätze beträgt die Höhe bereits 23 

� Binäre Suchbäume sind also nicht für die Verwaltung auf dem Externspeicher geeignet. 

binärer Baum ideale Baumstruktur für den Externspeicher 

Zentrale Frage (bis Ende der 60er Jahre): 

� Gibt es eine effiziente Zugriffsstruktur für einen seitenorientierten Externspeicher? 

Seite 315

Prinzipien 

8.4 B + -Bäume 

� Im Gegensatz zu binären Bäumen enthält ein Knoten viele Einträge/Sätze 

– 1:1-Beziehung zwischen Knoten und Seiten! 

– Daten werden exklusiv in den Blättern verwaltet 

� Basieren auf dem Konzept von 

– ISAM (Index Sequential Access Method) 

statisch: globale Reorganisation periodisch erforderlich 

– B-Bäumen (Bayer & McCreight, 1972) 

Funktionsumfang und Leistung 

� Leistung des B+-Baums hängt von dem Verzweigungsgrad b eines Knotens ab. 

� Suchfunktionen: 

– Exaktes Prädikat 

– Bereichsprädikat 

� Effizienz (Speicherplatz u. Antwortzeiten) ist asymptotisch unabhängig von der 

Einfügereihenfolge. 


Seite 316

Definition (B+-Baum) 

Ein B + -Baum vom Typ (b, c) ist ein Baum mit folgenden Eigenschaften: 

1. Jeder Weg von der Wurzel zum Blatt hat die gleiche Länge. 

2. Die Wurzel ist ein Blatt oder hat mindestens 2 und höchstens 2b-1 Söhne. 

3. Jeder Zwischenknoten hat mindestens b und höchstens 2b-1 Söhne. 

4. Jedes Blatt hat mindestens c und höchstens 2c-1 Einträge. 

� Zwischenknoten: 

– p i = Zeiger Sohnseite, k i = Schlüssel 

– es gilt stets: k i < k i+1 für 0 

� Blattknoten: 

p 0 k 1 p 1 k 2 p 2 • • • k m p m frei 

V k 1 TID 1 k 2 • • • k m frei 

TID 2 

– TID i = Verweis auf den Satz mit Schlüssel k i 

– N = Zeiger auf den rechten Blattknoten 

– V = Zeiger auf den linken Blattknoten 

TID m 

N 


Seite 317

Eigenschaften des B + -Baums 


� lokale Ordnungserhaltung: 

Für jeden Zwischenknoten Z mit j Schlüsseln k1 ,…,kj und (j+1) Söhnen p0 ,…,pj gilt: 

Für jedes i, 1 � i � j, sind alle Schlüssel in dem zu p i-1 gehörenden Teilbaum nicht größer als k i 

und k i ist kleiner als alle Schlüssel, die im Teilbaum von p i liegen. 

… … … 

�k i 

k i 

B + -Baum 

�k i 

Datenraum 

k i 

�k i �k i 

Seite 318

Beispiel 

� b=2, c=2 

� Beachte: b und c sind nur aus Gründen der Übersicht so klein gewählt! 

4 6 

1 TID 3 TID 4 TID 5 TID 6 TID 7 TID 9 TID 10 

TID 


Seite 319


Wie hoch kann ein B + -Baum werden? 

� Welche Höhe besitzt ein B + -Baum zur Abspeicherung von N Datensätzen im schlechtesten 

Fall? 

Oder anders gefragt: 

� Wie viele Datensätze müssen mindestens (dürfen höchstens) in einem B + -Baum der Höhe h 

sein? 

� Vereinfachende Annahme: b = c 

Wurzel hat mindestens 2 Einträge 

Zwischenknoten in der Ebene 2 hat mindestens b Einträge 

Zwischenknoten in der Ebene 3 hat mindestens b Einträge 

… b Einträge 

Blattknoten in der Ebene h hat mindestens b Datensätze 

Daraus ergibt sich, dass in einem B + -Baum der Höhe h mindestens 2*bh-1 Datensätze liegen. Es 

gilt also N � 2*b h-1 und somit 

N 

h � 

1 + log �--- � 

b = O�log �2� bN� � Besonderheit der asymptotischen Analyse: b ist keine Konstante 

Seite 320

Speicherplatz für den B + -Baum 

� Speicherplatzausnutzung (SPAN): 

minimal 

--------------------------------------------------------------------------------------erforderlicher 

Speicherplatz 

tatsächlich reservierter Speicherplatz 


� Im schlimmsten Fall 

– Jeder Knoten (mit Ausnahme der Wurzel) ist mit mindestens der Hälfte der möglichen 

Schlüssel gefüllt. 

– Ein B + -Baum braucht (im schlechtesten Fall) doppelt soviel Speicher wie ein optimal 

gefüllter Baum. Damit ergibt sich eine Speicherplatzausnutzung von mindestens 50%. 

� Im Durchschnitt 

– ln 2 (etwa 69%) 

Wie viele Einträge passen in einen Zwischenknoten der Größe 4 KB? 

– pro Zeiger: 4 Byte 

– pro Schlüssel: 16 Byte 

Dies ergibt ca. 200 Einträge in einem Zwischenknoten. 

Seite 321

Problem: 

Exakte Suche im B+-Baum 


� Gegeben ein Schlüssel k. Liefere den TID des Datensatzes r mit r.key = k in dem B+-Baum mit 

Wurzel root: EMQ(root, k). 

Algorithmus EMQ(Knoten p akt , Key k) 

readPage(pakt ); 

IF (pakt ist ein Zwischenknoten) 

index = m; // m ist die Anzahl der Schlüssel im Zwischenknoten 

Bestimme im Knoten pakt den kleinsten Schlüssel ki , so dass k � ki . 

IF (es gibt solch ein ki ) 

index := i-1; 

RETURN EMQ(pindex , k); // rekursiver Aufruf 

ELSE 

Bestimme im Knoten pakt den Datensatz (ki ,TIDi ) mit k == ki . 

RETURN (es gibt solch einen Datensatz) ? TIDi : NULL; 

END EMQ; 

Seite 322

Vereinfachende Annahme 

Beispiel 

� Es wird nur als Ergebnis geliefert, ob der Datensatz im Baum ist. 

� Suche den Datensatz mit Schlüssel 42. 

� Suche den Datensatz mit Schlüssel 41. 

9 28 

41 

46 67 

1 5 9 15 19 28 33 37 41 45 46 

53 59 67 71 83 99 


Seite 323

Bereichsanfrage im B + -Baum 


� Gegeben ein Schlüsselpaar low und up, low � up. Finde alle TID der Datensätze r mit low � r.key 

� up im B + -Baum mit Wurzel root: RQ(root, low, up) 

Algorithmus RQ(Knoten p akt ; Key low, Key up) 

Bestimme analog zur exakten Suche das Blatt first, in dem ein Datensatz mit Schlüssel 

low liegen könnte; 

res = ��pakt = first; 

LOOP 

ReadPage(pakt ); 

FOREACH (r mit r.key in [low,up] im Knoten pakt ) 

res += {r.TID} 

IF ((es gibt ein Datensatz r in pakt mit r.key � up) OR 

(pakt ist das am weitesten rechts liegende Blatt im B+-Baum)) 

RETURN res; 

pakt := pakt .N; // Gehe zum rechten Nachbarknoten 

END RQ; 

Seite 324

� Suche alle Datensätze im Bereich [40, 52]. 

9 28 

Beispiel 

41 

46 67 

1 5 9 15 19 28 33 37 41 45 46 

53 59 67 71 83 99 


Seite 325


Einfügen und Löschen in B + -Bäumen 

Meistens ist das Einfügen und Löschen sehr einfach: 

� Entspricht fast immer einer exakten Suche, dem Einfügen des neuen Satzes und dem 

Zurückschreiben des modifizierten Blatts (Datenseite). 

Manchmal treten aber folgende Problemfälle auf: 

� Was passiert, wenn die Seite keinen Datensatz mehr aufnehmen kann? 

1. Lösung: Einführung von Überlaufseiten und verketten mit der Primärseite. 

– Nachteil: Kosten für Suche, Einfügen und Löschen erhöhen sich. 

2. Lösung: Reorganisation der Datenstruktur 

– Sofort: Überlaufseiten werden nicht zugelassen. Reorganisation des B + - 

Baums soll aber lokal begrenzt bleiben. 

– Verzögert: kurzzeitige Verwendung von Überlaufseiten und spätere globale 

Reorganisation des Datenbestands. 

� Was passiert, wenn es zu wenige Datensätze in der Seite gibt? 

Seite 326

Einfügen im B + -Baum 


� Gegeben einen Datensatz r = (key,TID) und die Wurzel root des B + -Baums. Füge den Datensatz 

in den B + -Baum ein: Insert(root, r). 

Algorithmus Insert(Knoten p akt ; Record r) 

Suche nach dem Datensatz mit Wert r.key; // siehe EMQ(pakt , r.key) 

IF (Datensatz wurde gefunden) 

RETURN; // ggf. melde dies als Fehler 

Setze pakt auf das zuletzt gelesene Blatt; 

Füge r in pakt ein; 

WHILE (pakt ist übergelaufen) 

Teile die Sätze/Verweise in pakt in zwei gleich große Gruppen L und R, so dass 

alle Sätze/Verweise in L kleiner sind als die Sätze/Verweise in R; 

Speichere die Sätze/Verweise in R in einem neuen Knoten pneu und die in L in pakt ; 

Sei kmax der größte Schlüssel in L; 

pakt = (vm(pakt ) != NULL) ? vm(pakt ) : newRoot(pakt ); // Gehe zum Vater 

Füge das Paar (kmax , pneu ) in den Vaterknoten ein; 

END Insert; 

Seite 327

Spezialfall: Überlauf der Wurzel 

� Schleife wird spätestens durch eine Überlaufbehandlung der Wurzel beendet. 

� Durch den Aufruf der Methode newRoot wird eine neue Wurzel bereitgestellt: 

p akt 

p akt 

neue 

Wurzel 


– Der neue Wurzelknoten verfügt zunächst über nur einen Eintrag. Sofort danach wird dann 

der zweite Eintrag eingefügt. 

Seite 328

� Einfügen von 40 in folgenden B+-Baum 

– Suche nach dem Blatt 

Beispiel 

9 28 

41 46 

1 5 9 15 19 28 33 37 41 45 46 53 59 67 

9 28 

41 46 

1 5 9 15 19 28 

40 

33 37 41 45 46 53 59 67 

– Einfügen in das Blatt, Spalten des Blatts und Einfügen in den Vater 

9 28 

41 46 

(37, ) 

1 5 9 15 19 28 33 37 40 41 45 46 53 59 67 


Seite 329

– Einfügen in die Wurzel, Spalten der Wurzel und Erzeugen der neuen Wurzel 

9 28 

Wichtige Eigenschaften beim Einfügen: 

41 46 

1 5 9 15 19 28 33 37 40 41 45 46 53 59 67 

� Einfügeoperation bleibt auf einen Pfad des B + -Baums beschränkt. 

– Pro Ebene wird höchstens ein neuer Knoten hinzugefügt. 

– Der Aufwand für das Einfügen eines Datensatzes beträgt O(logb N) 

� Beim Einfügen bleiben alle Invarianten des B + -Baums erhalten. 

37 


Seite 330

Löschen im B + -Baum 


� Gegeben ein Schlüssel k und die Wurzel des B + -Baums. Finde den Datensatz mit Schlüssel k 

im B + -Baum und entferne diesen. 

Problemfälle: 

� Wie kann verhindert werden, dass ein Knoten zu wenig Datensätze enthält? 

– Ausgleich mit einem Geschwisterknoten 

– Ggf. muss der Knoten mit einem Geschwisterknoten verschmolzen werden. 

� Was passiert, wenn ein Datensatz gelöscht wird, dessen Schlüssel auch als Referenz in einem 

Elternknoten benutzt wird? 

– Das stellt kein Problem dar, weil die internen Schlüssel nur eine Wegweiserfunktion 

besitzen. 

Löschen von 28 

9 28 

37 

41 46 

1 5 9 15 19 28 33 37 40 41 45 46 53 59 67 

Seite 331


Kosten für Suchen, Einfügen und Löschen 

� Exakte Suche, Einfügen und Löschen sind auf einen Pfad beschränkt 

� Im schlechtesten Fall ergeben sich folgende Kosten für den B+-Baum: 

exakte Suche: O(logb N) 

Bereichanfrage: O(logb N + r/b) 

Einfügen: O(logb N) 

Löschen: O(logb N) 

Praktische Überlegungen 

� Wie viele Datensätze können in einem B + -Baum der Höhe 4 gespeichert werden? 

Beispiel (b = c = 200, 4 KB pro Seite); 

– Im schlechtesten Fall: 2*200*200*200 = 16*106 Datensätze, 8*10 4 Datenseiten = 320 

MB Speicherplatz für die Blattebene des B + -Baums. 

– Im Durchschnitt: Da Knoten zu etwa 2/3 im Durchschnitt gefüllt sind, können 

voraussichtlich 2*200*270*270 = 29*106 Datensätze verwaltet werden. Es wird nun 430 

MB an Speicherplatz für die Blattebene benötigt. 

� In vielen Anwendungen: 

Wurzel im Hauptspeicher ==> 3 Plattenzugriffe für exakte Suche 

Seite 332

Cluster-Index 

8.5 Indexe in Datenbanken 


� Höchstens ein Index pro Relation kann als Cluster-Index angelegt werden: 

create clustered index MeinIndex on … 

� Durch einen Cluster-Index wird das Speicherlayout der Datensätze der Relation bestimmt. 

– Beispiel: DB2 von IBM 

(a) Datensätze werden entsprechend der Ordnung im Index auf die Seiten abgebildet. 

(b) Häufiges Einfügen zerstört die Ordnung. 

(c) Reorganisation der Relation (TEUER) clustert die Datensätze wieder. 

– Beispiel: SQL Server 

Sicherstellung der Eindeutigkeit durch einen Index 

� Durch Anlegen eines Index kann sehr effizient überprüft werden, ob die Bedingung eines 

Schlüsselkandidats erfüllt ist. 

� Anlegen eines unique-Index: 

create unique index MeinIndex on … 

Seite 333

Überblick 

9. Anfrageverarbeitung 

Anfrageverarbeitung 

� Übersetzungsverfahren für SQL-Anfragen 

– Scannen und Parsen von Anfragen 

– Generierung eines Operatorbaums, der sich aus Operatoren der erweiterten relationalen 

Algebra zusammensetzt. 

� Anfrageoptimierung 

– algebraisch: 

Ausnutzung äquivalenter Repräsentationen von Anfragen in der relationalen Algebra 

– kostenbasiert: 

Ausnutzung spezieller Implementierungen von Operatoren der relationalen Algebra 

� Implementierung der Operatoren 

– ONC-Schnittstelle 

� Algorithmen für spezifische Operatoren 

Seite 334

Problem: 

Motivation und Problemstellung 


� Gegeben eine SQL-Anfrage. Erzeuge aus der Anfrage einen schnell ausführbaren (ideal wäre 

einen optimalen) Code. 

Schwierigkeiten bei der Transformation 

� Eigenschaften von SQL 

– nicht-prozedurale (deskriptive) Anfragesprache 

– zugriffspfad-unabhängiges (relationales) Datenmodell 

– Fakten und Beziehungen werden durch Werte dargestellt 

– Zugriff auf Satzmengen 

� Code wird repräsentiert als physischer Operatorbaum 

– prozedurale Darstellung einer Anfrage 

– Ausnutzung von Indexstrukturen (und TIDs) 

– Zugriff auf einzelne Datensätze 

Seite 335

Vorgehensweise bei der Übersetzung 

1. Parsen der Anfrage (lexikalische und syntaktische Analyse) 

– Scannen des Eingabestroms 

– Überführen der Anfrage in eine Interndarstellung 

2. Semantische Analyse 

– Ersetzen der Sichten durch ihre relationalen Ausdrücke. 

– Gibt es die in der Anfrage angesprochenen Relationen und Attribute 

tatsächlich in der Datenbank? 

– Zugriffskontrolle 

3. Normalisierung der Anfrage 

– Überführung in eine Normalform 

– Vereinfachung der Anfrage, d. h. Erkennen von Redundanzen und leeren 

Teilanfragen 

4. Erstellung von Ausführungsplänen und Auswahl des besten Ausführungsplans 


Seite 336

9.1 Anfrage als Operatorbaum 

� Die übliche interne Darstellung einer Anfrage benutzt einen Operatorbaum: 

– Knoten stellen logische Operatoren der relationalen Algebra dar. 

– Kanten beschreiben den operator-kontrollierten Datenfluss. 


� Beispiel: 

select AName,Gehalt 

from Abteilung, Personal 

where Abteilung.Nr = Personal.AbtNr and Personal.Gehalt < 4000 and AName = ’Spielzeug’ 

AName = ’Spielzeug’ 

AName,Gehalt 

� 

Abteilung 

� Operatorgraphen benutzen Operatoren der erweiterten relationalen Algebra 

– Gruppierung, verallgemeinerte Projektion (Map), Aggregation, Duplikateliminierung 

� 

� 

� 

Personal 

AName,Gehalt 

Gehalt < 4000 

Seite 337

Äquivalente Operatorbäume 


� Zwei Operatorbäume sind äquivalent, wenn ihre Ergebnisse für beliebige Instanzen der 

beteiligten Relationen gleich sind. 

� Eine SQL-Anfrage hat keine eindeutige Darstellung als Operatorbaum 

– Es gibt sogar unendlich viele Darstellungen! 

� Falls eine Anfrage eine einfache Select-From-Where-Anfrage ohne Unteranfrage ist, kann 

diese direkt in relationale Algebra umgesetzt werden: 

– Erzeuge das kartesische Produkt der Relationen in der from-Klausel 

– Schränke das Ergebnis auf die Tupel ein, welche die Bedingung der where-Klausel 

erfüllen. 

– Projektion auf die in der select-Klausel angegebenen Attribute 

� AName,Gehalt 

� AName = ’Spielzeug’ AND Lohn < 4000 AND Abteilung.Nr = Personal.AbtNr 

Abteilung 

Personal 

� Als problematisch erweisen sich dabei Unteranfragen (siehe weiterführende Vorlesungen) 

Seite 338

Algebraische Anfrageoptimierung 

Ziel bei der Anfrageübersetzung 

� frühzeitiges Erkennen leerer Anfragen und gemeinsamer Teilanfragen 

� Minimierung der Anzahl der Zwischenergebnisse im Operatorbaum 

Vorgehensweise 

� Normalisierung der Prädikate in der where-Klausel: 

Durch Anwendung der Kommutativ-, Assoziativ- und Distributivregeln sowie der De 

Morgan’schen Regeln lässt sich die where-Klausel in folgende Formen übertragen: 

– konjunktive Normalform 

(Pi1 OR Pi2 OR …Pin ) AND … AND (Pj1 OR Pj2 OR … Pjm ) 

– disjunktive Normalform 

(P h1 AND P h2 AND …P hx ) OR … OR (P kl AND P k2 AND … P ky ) 

Die Prädikate P i sind dabei atomar. 

� Anwendung von Regeln für die Operatoren der relationalen Algebra 

– Operatoren wie Selektion möglichst früh ausführen 

=> Reduktion der Zwischenergebnisse 


Seite 339

Join-Reihenfolgen 

� Die Vereinigung, das kartesische Produkt und der natürliche Verbund sind 

– kommutativ (R |X| S = S |X| R) und 

– assoziativ ((R |X| S) |X| T= R |X| (S |X| T)). 

Aufgrund dieser Eigenschaften können sehr viele äquivalente Umformungen von 

Operatorbäumen berechnet werden. 

� Assoziativität gilt aber i. A. nicht für den Theta-Join. 

Seien R, S und T Relationen mit A,C � RSR , B � RSS und D � RST . Dann ist: 

(R |X| A>B S) |X| C>D T definiert, aber R |X| A>B (S |X| C>D T) nicht. 


– Das Attribut C besitzt keinen Bezug zur Relation S und T. 

� Der zentrale Baustein bei der Anfrageoptimierung ist verantwortlich für die Bestimmung einer 

Reihenfolge für die Abarbeitung von Joins. 

– i. A. Beschränkung auf links-tiefe Bäume 

– approximative Lösung durch dynamische Programmierung 

Seite 340

Ziel: 

Kostenbasierte Anfrageoptimierung 

� Transformation des zuvor hergeleiteten logischen Operatorbaums in einen physischen 

Operatorbaum auf Basis eines einfachen und effektiven Kostenmodells. 

Realisierung 


� Auswahl einer effizienten Implementierung für die Operatoren 

� Zusammenfügen von aufeinander folgenden Operatoren zu neuen Operatoren. 

So ist es z. B. möglich, eine Selektion und eine Projektion (ohne Duplikateliminierung) in 

einem Operator durchzuführen. 

� Festlegung eines Kommunikationsprotokolls zwischen zwei aufeinander folgenden Knoten im 

Operatorbaum. 

– Alle Operatoren erfüllen die ONC-Schnittstelle. 

– Die Ergebnisse der Teilbäume werden bedarfsorientiert berechnet. 

Die Alternative dazu wäre alle Ergebnisse eines Teilbaums zu berechnen, diese alle auf 

Platte zu speichern. Danach könnte Vaterknoten die Daten wieder einlesen. 

Seite 341

9.2 ONC-Protokoll 


� In diesem Abschnitt betrachten wir Operatoren und ihre Implementierungen, die auf einer 

Relation bzw. zwei Relationen arbeiten. 

� Alle Operatoren erfüllen die so genannte ONC-Schnittstelle eines Iterators: 

– Open: Öffnet den Iterator 

– Next: Gibt das nächste Element 

– Close: Schließt den Iterator 

Auf Basis dieser Schnittstelle können beliebige Operatoren der Algebra miteinander kombiniert 

werden. 

Ziel bei der Implementierung der Operatoren 

� Bedarfsgesteuerte Produktion der Ergebnisse 

– Immer dann, wenn auf einem Operator Next aufgerufen wird, wird erst das nächste 

Ergebnis berechnet! 

– Vermeidung von teuren Preprocessing-Schritten und Abspeicherung von Ergebnissen auf 

dem Externspeicher. 

Seite 342

Anforderung an ONC 


� Damit eine möglichst effiziente Verarbeitung gewährleistet wird, sollten die physischen 

Operatoren nicht blockieren, sondern erste Ergebnisse bereits dann liefern, wenn die 

Eingabemenge(n) nicht vollständig vorliegen. 

– Erste Ergebnisse sollten schnell erzeugt werden (Optimierungsziel). 

– Die durchschnittliche Antwortzeit für einen Aufruf von Next sollte niedrig sein. 

� Beim Open eines Operators werden die erforderlichen Parameter der Operatoren gesetzt (wie 

z. B. der benötigte Hauptspeicher) und die Metadaten berechnet. 

– Open wird beginnend bei der Wurzel rekursiv für die Kinderknoten im Operatorbaum 

aufgerufen. 

– Das Open eines Operators ist erst dann abgeschlossen, wenn die darunter liegenden 

Operatoren vollständig geöffnet sind. 

– Teilweise können die Verfahren sich noch zur Laufzeit an den tatsächlich verfügbaren 

Speicher anpassen (speicheradaptive Verfahren) 

� Vorteile: 

– Einfacher Austausch von Implementierungen 

– Keine Zwischenspeicherung von Ergebnissen 

Seite 343

Einfache Beispiele für ONC 


� Erste Implementierungen für Projektion und Selektion erfüllen in einfacher Weise die ONC 

Schnittstelle. 

� Projektion: �X (R) 

next() { 

rec = R.next(); 

return new Record(rec, X); 

} 

Bei der verallgemeinerten Projektion wird im Wesentlichen noch eine Funktion auf die 

Datensätze angewendet. 

� Selektion: �F (R) 

next() { 

do 

rec = R.next(); 

while (!F(rec)); 

return rec; 

} 

Die Selektion kann insbesondere durch Indexstrukturen, wie z. B. B+-Bäume, effizient 

unterstützt werden. 

Seite 344


Bei den anderen Operatoren ist ONC nicht so einfach zu implementieren. 

� Durchlaufen mehrerer Relationen (z. B. beim Join) 

� Mehrmaliges Durchlaufen einer Relation (z. B. beim Gruppieren) 

� Anlegen von zusätzlichen Datenstrukturen notwendig, die aufgrund ihrer Größe i. A. auf dem 

Plattenspeicher abgelegt werden müssen. 

� 

Die Kosten bei diesen Operationen sind damit im Wesentlichen durch die 

benötigten I/O Operationen bestimmt. 

Einfache Lösung: Nested-Loops-Technik 

� Basieren auf dem Durchlaufen der Relation(en), wobei ein möglichst großer Anteil im 

Hauptspeicher gehalten wird, um bei einem erneuten Durchlauf I/O Operationen einzusparen. 

Prinzipielle Techniken für Entwurf effizienterer Lösungen 

� Externes Sortieren 

� Divide-and-conquer (z. B. mit Hashing) 

Seite 345

9.3 Partitionierende Verfahren 

� Verwendung einer Partitionierungsfunktion f: 

– Abbildung der Datensätze auf {0,…, p-1}. 

Phase 1 

Wertebereich des 

Schlüssels 

f 


� Für jede Partition wird eine Pufferseite im Hauptspeicher reserviert. 

� Datensätze werden gelesen und mittels der Funktion f einer Partition zugeordnet, d. h. 

Datensätze werden in die zugehörige Pufferseite im Hauptspeicher geschrieben. 

� Falls eine Pufferseite voll ist, wird deren Inhalt auf eine Seite im Externspeicher übertragen. 

0 

1 

p-2 

p-1 

Hauptspeicher 

p = #Partitionen 

0 

1 

p-2 

p-1 

Externspeicher 

Seite 346

Phase 2: 

� Nach der vollständigen Partitionierung der Daten wird iterativ für jede der Partitionen 

folgendermaßen vorgegangen: 

a) Alle Daten der Partition werden in den Hauptspeicher gelesen. 

b) Das entsprechende Problem (z. B. Duplikatbeseitigung) wird dafür gelöst. 

Phase 3 (optional) 


� Sollte eine Partition immer noch nicht vollständig in den Hauptspeicher passen, wendet man 

obiges Prinzip rekursiv an oder verwendet ggf. Nested-Loops. 

Seite 347

Leistung des Verfahrens 


� Annahmen 

– Gleichmäßige Verteilung der Daten über die Partitionen, d. h. jede Partition besitzt etwa 

N/p Datensätze. 

– Verfügbarer Hauptspeicher M und Seitengröße C 

� Für p Partitionen wird insgesamt p*C Hauptspeicher zum Schreiben benötigt. Dazu kommt 

eine Seite zum Lesen der Eingabe. 

– M � p*C + C 

� Um das Verfahren in zwei Phasen ablaufen zu lassen, muss zusätzlich folgende Bedingung 

erfüllt sein: 

– M � N/p 

p�N�C ist die optimale Wahl für p, d. h. es gilt M � 

CN. 

� Anzahl der I/O Operationen: 2*N/C 

Seite 348

Idee 

Hybrides Partitionieren 

� Möglichst viele Daten sollen im Hauptspeicher verarbeitet werden und nur wenige in 

Partitionen ausgelagert werden. 

– Partition 0 verbleibt im Hauptspeicher 


– Partitionen 1,…,p werden bei Bedarf auf den Externspeicher ausgelagert. 

Partition 0 

0 

1 

h 

verbleibt im 

Hauptspeicher 

-1 ({0,…,s-1}) 

s-1 

q-2 

q-1 Wertebereich des 

Schlüssels 

Wertebereich der 

Funktion h 

h 

h -1 ({s,…,q-1}) 

f 

0 

1 

p-1 

p 

Externspeicher 

p + 1 = #Partitionen, p < q 

Seite 349

Parameter des Verfahrens 

� Größe der Partition 0 

– Durch Verkleinerung des Grenzwertes s ist eine dynamische Anpassung der 

Größe der Partition 0 möglich. 

� p = Anzahl der “externen” Partitionen 

� Datenstruktur der Partition 0 

– Falls die Partition 0 sehr groß ist, ist eine effiziente Datenstruktur zur 

Verwaltung der Datensätze vorteilhaft. 

– In der Literatur wird i. a. vorgeschlagen, die Partition 0 durch eine Hashtabelle 

zu verwalten. 

Bemerkung 


� Hybrides Partitionieren lohnt, falls die Größe der Eingaberelation R zwischen M und M 2 / C 

Datensätze liegt, d. h. ein (ideales) Partitionierungsverfahren benötigt einen 

Partitionierungsschritt (bzw. zwei Phasen) 

Seite 350

Wie viele externe Partitionen werden benötigt? 

� Parameter 

– p Anzahl der externen Partitionen 

– m Anzahl der Seiten im Hauptspeicher (= M / C) 

– n Anzahl der Seiten der Relation (= N / C) 

Wir nehmen an, dass jede der Partitionen aus m Seiten besteht. 

� Jede der externen Partitionen benötigt einen Ausgabepuffer. Weiterhin wird noch ein 

Eingabepuffer benötigt. Somit verbleiben 

m – �p + 1� 

Seiten für die Partition 0 im Hauptspeicher. 

� Berechne nun p so, dass p dem kleinsten Wert entspricht, für den gilt: 

� Nach Auflösung nach p ergibt sich dann 

m– �p+ 1�+ 

mp � n 

p = 

�n – m + 1��m– 

1� 


Aus dieser Gleichung lassen sich dann auch sofort die Kosten für das hybride Hashverfahren 

abschätzen. 

Seite 351


9.4 Aggregate und Duplikatbeseitigung 

� Implementierung von Aggregation und Duplikatbeseitigung durch einen Operator 

� Aggregatberechnung 

– Berechnung eines einzigen Werts für die gesamte Relation (Skalares Aggregat) 

select count(*) 

fromAngestellte 

where Gehalt > 20000 

– Berechnung eines Werts für jede Klasse einer Relation (Aggregatfunktionen) 

select AbtNr, count(*) 

from Angestellte 


group by AbtNr 

� Duplikateliminierung 

– ist beispielsweise nach einer Projektion mit distinct erforderlich 

select distinct Abteilung 

from Angestellte 


� Unterschied zwischen Duplikateliminierung und Aggregatfunktionen? 

Seite 352


Duplikatbeseitigung durch Nested-Loops 

� Algorithmus DupElim(Eingabe Relation R, Ausgabe Relation S) 

S.insert(R[0]) 

out: for (int i = 1; i < R.length(); i++) { 

for (int j = 0; j < S.length(); j++) 

if (R[i] == S[j]) 

continue out; 

S.insert(R[i]); 

} 

� Algorithmus hat im schlimmsten Fall quadratische Laufzeit. 

Was tun, wenn R und S nicht in den Hauptspeicher passen? 

� Für jedes Tupel der Relation R teste, ob das Tupel bereits im Hauptspeicherteil von S liegt. 

– Wenn ja, wird dieses Tupel verworfen. 

Andernfalls wird überprüft, ob das Tupel noch in den Hauptspeicher passt. 

– Wenn ja, fügen wir das Tupel in den Hauptspeicherteil von S ein. 

Andernfalls, speichern wir es auf dem Externspeicher in einer Datei R’ ab. 

� Danach wird der Hauptspeicher geleert und der Algorithmus wird rekursiv für R’ aufgerufen. 

Seite 353

Wie kann ONC implementiert werden? 


� In der open-Phase wird im Wesentlichen der Hauptspeicher reserviert und das erste Tupel 

eingefügt (und als aktuelles Tupel markiert). 

� In der next-Phase wird 

– das aktuelle Tupel ausgegeben, 

– und ein neues Tupel in den Hauptspeicher geholt (dies kann insbesondere dazu führen, 

dass die Relation R’ erzeugt werden muss). 

Vorschläge zur Leistungsverbesserung 

� Die im Hauptspeicher liegenden Daten von S können durch einen Index organisiert werden, 

der Suchen und Einfügen effizient unterstützt. 

� Verwendung eines Bitfilters 

Seite 354

Sortieren 

Duplikatbeseitigung 

durch Sortieren und Hashing 


� direkte Anwendung externer Sortierverfahren 

� Vorschlag zur Leistungsverbesserung 

– Duplikatbeseitigung sollte so früh wie möglich durchgeführt werden, d. h. in den frühen 

Phasen des Verschmelzens sollten bereits Duplikate beseitigt werden. 

– Beobachtung von Bitton & DeWitt: 

Durch eine frühe Duplikatbeseitigung werden die sortierten Teilfolgen nicht wesentlich 

verkürzt. Erst beim letzten Verschmelzen werden viele Duplikate beseitigt. 

Hashing 

� Aufteilen der Daten in Partitionen, die komplett in den Hauptspeicher passen. 

� Eliminierung von Duplikaten aus den einzelnen Partitionen 

� Wenn möglich hybrid: frühe Produktion von Ergebnissen möglich. 

Seite 355


� Implementierung von SQL-Übersetzern 

� Anfrageoptimierer ist die zentrale Komponente 

– algebraisch 

– kosten-basiert 

� Bedarfsgesteuerte Implementierung der Operatoren 

– ohne Speicherung großer Zwischenergebnisse 

� Implementierungstechniken 

– nested-loops 

– sortierbasiert 

– hash-basiert 

� Beispiel für Duplikateliminierung 


Seite 356

Übersicht 

10. Data-Warehouse 

� Klärung wichtiger Begriffe 

� Architektur eines Data-Warehouse 

� Back-End Komponenten 

� Front-End Komponenten 

� Implementierung eines Data-Warehouse durch relationale Datenbanksysteme 

Data-Warehouse 

Seite 357


Online-Transaction Processing (OLTP) 

� OLTP bestimmte im Wesentlichen die Entwicklung bei der Datenbanktechnologie bis 

Mitte der 90er Jahre. 

� Charakterisierung von OLTP-Anwendungen 

– kurze Transaktionen 

– wenig Datenzugriffe pro Transaktion 

– viele Änderungen 

– keine historischen Daten, d. h. beim Ändern werden Daten überschrieben 

� Beispielsanwendungen 

– Buchungssysteme: Buchung eines Flugs 

– Bestellung von Waren 

– … 

� Optimierung dieser Datenbanken führte zu der Theorie der Normalformen. 

Normalisiertes Schema ist 

– gut für Datenbanken mit häufigen Änderungsoperationen. 

– schlecht bei anfrageintensiven Anwendungen. 

Seite 358

Online-Analytical Processing (OLAP) 


� Seit 10 Jahren stehen Anwendungen im Vordergrund, die sich mit der Analyse der Daten 

aus verschiedenen heterogenen Datenbanken beschäftigen. 

� Charakterisierung von OLAP-Anwendungen 

– lange Transaktionen 

– hohe Anzahl an Datenzugriffen pro Transaktion 

– lesender Zugriff auf Daten, “keine” Änderungen 

– Zugriff auf historische Daten 

� Beispiele 

– Auslastung der Atlantikflüge über den Zeitraum der letzten 2 Jahren 

– Verkaufszahlen in einem Gebiet in einer Produktgruppe in einem Zeitintervall: 

Wie viel Kaffee wurde in Marburg im letzten Jahr verkauft? 

� Optimierung solcher Datenbanken führt zu der Einführung von Redundanz, um (lesende) 

Anfragen effizient zu unterstützen. 

� Redundante Daten werden in einer separaten Datenbank, dem Data-Warehouse, 

gehalten. 

– Unabhängigkeit von den operativen Systemen 

Seite 359

10.1 Data-Warehouse - eine Definition 

Definition (Immon) 


� Ein Data-Warehouse ist eine themenorientierte, historische und autonome Datenbank 

eines Unternehmens, in der Daten aus verschiedenen unabhängigen heterogenen 

Quellsystemen integriert und verwaltet werden. Ziel ist, einem Unternehmen durch 

zeitbezogene Abfragen und Analysen entscheidungsunterstützende Ergebnisse zu liefern. 

Themenorientierung 

� Entscheidungsrelevante Sachthemen eines Unternehmens stehen im Vordergrund 

– umsatzstärkste Kunden 

– kostenintensivste Produkte 

Man spricht dann auch von einer multidimensionalen Datenbank. 

Integration 

� Verknüpfung der Daten aus verschiedenen heterogenen Datenbanken 

� Passiver Ansatz (lazy, on demand) 

– Extraktion der Daten aus den Quellsystemen bei der Anfrageausführung 

Seite 360

� aktiver Ansatz (eager, in advance) 

– kein Zugriff auf Quellsysteme bei der Anfrageausführung 

– Extraktion im voraus 

� Gründe für den aktiven Ansatz im DW 

– Vermeiden der langsamen Zugriffe auf die Quellsysteme 

– Verfügbarkeit von Quellsystemen nicht erforderlich 

– Wenig Beeinträchtigung der Performance der Quellsysteme 

– Analysen und Anfragen erfordern i.A. nicht die neuesten Daten 

– Anreicherung der Daten bei der Extraktion 

– Historische Daten werden im DW aufbewahrt (kein Löschen der Daten) 

Zeitbezug 

� Daten liegen im DW in mehreren Versionen (bzgl. Zeit) vor. 

� Anfragen können sich nun auf einen Zeitpunkt bzw. Zeitraum beziehen. 

Autonomie 

� DW ist eine eigenständige und voll funktionsfähige Datenbank, die bezgl. der 

spezifischen Anforderungen optimiert ist. 


Seite 361


10.2 Das mehrdimensionale Datenmodell 

� Entscheidungsunterstützung basiert auf einem mehrdimensionalen Datenmodell 

(konzeptionelle Ebene) 

Bestandteile des Datenmodells 

� Messgrößen (Fakten) 

– numerische Wertebereiche 

– Beispiele: Umsatz, verkaufte Einheiten, Kosten, Deckungsbeitrag 

� Dimensionen 

– Messgrößen liegen in einem mehrdimensionalen Kontext 

– Beispiel: Umsatz hängt z. B. ab von den Dimensionen Produkt, Ort und Zeit. Diese 

Dimensionen bezeichnet man auch als die “natürlichen Parameter” von Umsatz. 

– Dimension setzt sich zusammen aus mehreren Attributen. Z. B.: Ort besitzt als 

Attribute Region, Land und Geschäft. 

– Ein Attribut einer Dimension ist eindeutig (innerhalb der Dimension). 

– Attribute einer Dimension sind oft hierarchisch strukturiert 

Tag, Monat, Jahr (d h. es bestehen FDs zwischen den Attributen) 

Seite 362

Land 

Region 

Geschäft 

Repräsentation als Datenwürfel 

Tag 

Monat 

Quartal 

Jahr 

Produkthauptgruppe 

Produktgruppe 

Produkt 


Produkt: Jacobs Krönung 

Geschäft: Tegut, Cappel 

Tag: 10.6.2009 

Umsatz: 47,11 Euro 

Seite 363

10.3 Architektur eines DW-Systems 

Data 

Mart Data 

Mart Data 

Marts 

Extraktor 

Quelle 

OLAP Front-End-Tool, Data-Mining-Tool 


Integrator 

Extraktor 

Quelle 

Metadaten 

Extraktor 

Quelle 


Administrations- & 

Monitoring-Komponente 

Seite 364

10.3.1 Back-End Komponenten 

Voraussetzung für eine effektive Extraktion und Integration 

� Zustand der Quellsysteme 

� Konsistenz zwischen den Quellsystemen (wenn möglich) 

Integration 

1. Phase: Schrubben der Daten (data scrubbing) 

– Eliminierung von Duplikaten 

– Einfügen von Default-Werten 

– Korrektur von Fehlereingaben 

– Aufspüren von Integritätsverletzungen und “ungewöhnlichen” Daten 

2. Phase: Transformation 

– Vereinheitlichung von Maßeinheiten, Attributsnamen, Attributswerten 

– Ableitung von betriebswirtschaftlichen Kennzahlen 


Seite 365

Besonderheiten bei der Integration 


� Datenanreicherung bei der Integration 

– Zusammenführung von Daten aus verschiedenen Quellen 

(z. B. Kunde mit Bonitätsprofil) 

– Dies erfordert jedoch, dass die Daten über den gleichen Schlüssel verfügen. 

Ansonsten benötigt man Heuristiken, um Duplikate zu erkennen. 

� Berücksichtigung der Detailstufe (bei der Zeit) 

� Metadaten unterstützen den Abbildungsprozeß zwischen den Modellen der Quellsysteme 

und dem Modell des Data-Warehouse. 

Seite 366

Laden von Daten ins DW 


� Datenimport kann manuell, periodisch oder ereignisgesteuert ausgelöst werden. 

� Eine komplette Neuerzeugung des DW ist zu aufwendig 

– Stattdessen findet ein inkrementelles Laden der Daten ins Data-Warehouse statt. 

Problem: 

� Wie können Änderungen im Quellsystem erkannt werden? 

� Data Shipping 

Anlegen einer speziellen Log-Datei, in die Änderungen (mittels Trigger) 

hineingeschrieben werden. 

� Transaction Shipping 

Log-Datei des TA-Managers wird durchsucht. 

Aufbau und Erhaltung spezieller Datenstrukturen im DW 

� Anpassen von “materialisierten” Sichten 

� Einfügen der Daten in Indizes 

Seite 367

Administrative Metadaten 

Verwaltung der Metadaten 

� konzeptionelles (mehrdimensionales) Schema 

� logisches Implementierungsschema (z. B. im relationalen Modell) 

� vordefinierte Berichte 

� Beschreibung der Quellsysteme 

� Regeln zur Transformation und Archivierung 

Applikationsspezifische Metadaten 

� Verzeichnis über die Anwendungsterminologie. Man nennt dies auch Onthologie. 

Operationale Metadaten 

� Statistiken des laufenden Betriebs 

– Antwort- und Ladezeiten 

– Nutzung von Indizes und materialisierten Sichten 


Seite 368

Anforderung 

10.3.2 Front-End Komponenten 


� Anwender (z. B. Manager eines Unternehmens) soll selbständig und interaktiv das Data- 

Warehouse durchsuchen können. 

– Kennzahlenvergleich 

– Ursachenanalyse 

� Um diesen Anforderungen gerecht zu werden, stellt die OLAP-Engine einige 

Basisoperationen auf dem Hyperwürfel zur Verfügung 

� Präsentation der Ergebnisse einer Operation in Form von Pivottabellen (Kreuztabellen). 

Produkt Ort Zeit Umsatz 

Kaffee Cappel Januar 47,11 

Kaffee Wehrda Februar 333,33 

Kaffee Cappel Januar 99,01 

Obst … … … 

flache Tabelle 

Kaffee 

Ort 

Zeit 

Produkt 

Seite 369

Beispiel einer Pivottabelle: 


� Die Dimension Produkt wurde auf die Produktgruppe Kaffee “eingefroren”. Man spricht 

dann auch vom Ausblenden einer Dimension 

� Kaffeeumsatz wird jetzt in Abhängigkeit der angezeigten Dimension, Ort und Zeit 

veranschaulicht. 

Mehrdimensionale Pivottabellen 

Januar Februar März Summe 

Cappel 574,11 550,20 1200,30 2324,61 

Wehrda 808,80 770,77 500,34 2079,91 

Kernstadt 478,30 450,28 289,89 1217,47 

Summe 1861,21 1771,25 1990,53 5622,99 

� Durch Verschachtelung zweier Dimensionen können mehr als zwei Dimensionen in einer 

Pivottabelle veranschaulicht werden. Welche Spalten fehlen hier noch? 

Januar Februar März 

Obst Cappel 574,11 550,20 1200,30 

Wehrda 808,80 770,77 500,34 

Spielzeug Cappel 89,89 91,91 1000,01 

Wehrda 890,89 78,34 888,90 

Seite 370

Rotation 


� Vertauschen von angezeigten und ausgeblendeten Dimensionen. 

� Im Fall eines dreidimensionalen Würfels entspricht dies einer Rotation um 90 Grad 

Ort 

Zeit 

Produkt 

Januar 

angezeigte Dimensionen: Produkt, Ort 

ausgeblendete Dimension: Zeit 

eingefrorener Zeitpunkt: Januar 

Ort 

Produkt 

Zeit 

angezeigte Dimensionen: Zeit, Ort 

ausgeblendete Dimension: Produkt 

eingefrorenes Produkt: Kaffee 

Kaffee 

Seite 371

Roll-Up/Drill-Down 

Anfragemuster in SQL 

� Roll-Up 

– Erhöhung der Aggregationsstufe 

– Verdichtung der Messgrößen im Würfel 

� Drill-Down 

– inverse Operation zu Roll-Up 

– Reduzieren der Aggregationsstufe 

– Erhöhung des Detailgrads der Daten 

� Bei diesen Operationen werden sehr oft bereits die Attributshierarchien genutzt 

Weitere Operationen 

� Ranking 

– Was sind die zehn umsatzstärksten Kaffeemärkte? 

� Sortieren 

� Gruppieren / Aggregate 

� Ausnahmebehandlung 


Seite 372

Ziel 

Data Mining 

� Unterstützung der Ursachenanalyse 

� automatische bzw. halbautomatische Mustersuche im Data-Warehouse 

– von besonderem Interesse: Datenausreißer 

Techniken 


� Erstellung einer Klassifikation der Daten (z. B. Autoversicherungsklassen) 

– Klassen sind vorgegeben 

– Gesucht sind die Kriterien für eine Klassifizierung (mittels einer Testmenge) 

� Auffinden von Assoziationsregeln der Form X�Y – X und Y sind typischerweise Produkte, die gemeinsam in Transaktionen auftreten. 

– Konfidenz: 

rel. Häufigkeit der Transaktionen, die bereits X und zusätzlich noch Y enthalten. 

– Support: 

rel. Häufigkeit der Transaktionen, bei denen sowohl X als auch Y vorkommt. 

� Visual Data Mining 

Seite 373

10.4 Datenmodellierung 

� Transformation des mehrdimensionalen Datenmodells in ein ER-Diagramm 

ZID 

Tag 

Woche 

Monat 

Zeit 

PID 

Name 

Gruppe 

Produkt 

Verkauf 

Stückzahl 

Umsatz 

Geschäft 


GID 

Geschäft 

Region 

Land 

Seite 374

Definition 

Star-Schema 


Ein Star-Schema besteht aus einer Menge von Relationen D1 ,…,Dn , F mit folgenden 


1. Jede Relation Di modelliert eine Dimension des Datenwürfels. Zusätzlich zu den 

Attributen der Dimension bekommt Di einen künstlichen Primärschlüssel di zugeordnet. Di wird dann auch als Dimensionsrelation bezeichnet. 

2. Die Relation F verbindet die Dimensionen miteinander, indem die Fremdschlüssel der 

Dimensionsrelation (d. h. d 1 ,…,d n ) und die entsprechenden Messgrößen als Attribute 

umgesetzt werden. Diese Relation wird dann auch als Faktenrelation bezeichnet. 

Bemerkungen: 

� Das Star-Schema (genauer die Dimensionsrelationen) liegen nicht in dritter Normalform 

vor. 

Seite 375

Snowflake-Schema 


� Werden die Dimensionsrelationen des Star-Schemas in Normalform gebracht, so entsteht 

das Snowflake-Schema 

Jahr_ID 

Jahr 

Land_ID 

Land 

Quartal_ID 

Quartal 

Jahr_ID 

Region_ID 

Region 

Land_ID 

Monat_ID 

Monat 

Quartal_ID 

GID 

Geschäft 

Region_ID 

ZID 

Tag 

Monat_ID 

PID 

GID 

ZID 

Umsatz 

Stückzahl 

Faktenrelation 

Seite 376

Beobachtung 

� Die Faktenrelation ist im Vergleich zu den Dimensionsrelationen sehr groß. 

Leistungsbeurteilung 


� Keine Redundanz beim Snowflake-Schema. 

– Wird der Name einer Produktgruppe geändert, so ist im Snowflake-Schema nur ein 

Datensatz, im Star-Schema i. a. mehrere Datensätze, von der Änderung betroffen. 

– Das Snowflake-Schema benötigt i. a. weniger Speicherplatz (zusätzlich müssen aber 

die künstlichen Schlüssel gespeichert werden). 

– Die Redundanz besitzt aber auf Grund der obigen Beobachtung kaum eine 

praktische Relevanz. 

� Durch die Denormalisierung werden bei Anfragen im Star-Schema weniger Joins 

berechnet. Zudem kann der Join zwischen der Faktenrelation und seinen 

Dimensionsrelationen sehr effizient berechnet werden. 

Seite 377

Anforderungen 

Anfragen auf dem Star-Schema 

� Ausführung von Aggregationen auf Teilmengen im Würfel 

� Detailierungsgrad des Würfels soll beliebig einstellbar sein 

Allgemeine Form einer Anfrage 


select g1 ,…,gk , agg(f1 ), …, agg(fm ) 

aggregierte Messgrößen 

from 

where 

D1 ,…,Dn , F 

 

Relationen des Star-Schemas 

and 

… and 

and 

D.d 1 = F.d 1 

… 

D.d n = F.d n 

group by g 1 , …,g k ; 

and 

Bedingung des 

Star-Joins 

Seite 378

Beispiel: 


Finde die Quartalsumsätze aller Geschäfte differenziert nach Ländern im Jahr 2006 für die 

Produktgruppe Kaffee. 

select PName, Land, Quartal, sum(Umsatz) 

from Produkt P, Geschäft G, Zeit Z, FaktenRel F 

where Jahr = 2006 and 

Produktgruppe = “Kaffee” and 

Z.ZID = F.ZID and 

P.PID = F.PID 

G.GID = F.GID 

and 

group by PName, Land, Quartal; 

Bemerkungen 

� Die spezielle Form des Joins (Anfrage) wird auch als Star-Join (Star-Anfrage) 

bezeichnet. 

� Die Messgrößen in der Faktentabelle können bereits aggregiert sein (z. B. auf einen Tag). 

Es ist z. B. nicht möglich, die Anzahl der Kunden am Tag x zu bestimmen, die Kaffee 

kauften (da ein Kunde mehrere Kaffeeprodukte gleichzeitig kaufen kann). 

Seite 379

10.5 SQL-Erweiterungen 


� Defizite bei SQL im Hinblick auf Anfragen im Data-Warehouse 

– einfache Gruppierungsanfragen müssen in mehrere SQL Anweisungen aufgespalten 

werden. 

Beispiel 

� Relation: Anrufe(VVWahl, VNummer, ZVWahl, ZNummer, Datum, Länge) 

Ein Tupel dieser Relation protokolliert ein Telefongespräch und registriert dabei die Telefonnummern 

des Anrufers (VVWahl, VNummer), die Nummer des Angerufenen 

(ZVWahl, ZNummer), das Datum und die Länge des Gesprächs. 

� Anfrage: Finde für jeden Kunden, das von ihm geführte längste Telefongespräch und die 

entsprechende Vorwahl. 

� Lösung in SQL in zwei Schritten 

create view Tmp as 

select VVWahl, VNummer, MaxL = max(Länge) 

from Anrufe 

group by VVWahl, VNummer; 

Seite 380


select t.VVWahl, t.VNummer, ZVWahl, Länge 

from Anrufe a, Tmp t 

where Länge = MaxL and 

a.VVWahl = t.VVWahl 

a.VNummer = t.VNummer; 

and 

Die Berechnung besteht aus einem Subselect (Erzeugung von Tmp) und einem Join 

zwischen Tmp und Anrufe. 

Erweiterungsvorschlag von SQL: Gruppierungsvariablen 

� Gruppierungsvariablen werden in der group-by Klausel definiert. 

� In einer zusätzlichen Klausel (suchthat-Klausel) kann der Bereich der 

Gruppierungsvariablen noch eingeschränkt werden. 

� In der select-Klausel können nun die Aggregatsoperationen auf die 

Gruppierungsvariablen angewendet werden. 

� Beispiel: 

select VVWahl, VNummer, R.ZVWahl, R.Länge 

from Anrufe 

group by VVWahl, VNummer: R 

suchthat R.Länge = max(Länge); 

Seite 381

� In der Terminologie des mehrdimensionalen Datenmodells entspricht die suchthat- 

Klausel einem Herausschneiden einer Scheibe aus einem Würfel. 

Noch eine Anfrage: 


� Gib für jeden Kunden, die durchschnittliche Länge der Telefongespräche mit der 

Vorwahl 069 und 089 (in einem Datensatz). 

� In Standard SQL müssen zwei Sub-Anfragen (in Form von Views) und ein Join zwischen 

den Views berechnet werden 

� Durch die Verwendung von Gruppenvariablen vereinfacht sich die Formulierung der 

Anfrage erheblich: 

select VVWahl, VNummer, avg(R.Länge), avg(S.Länge) 

from Anrufe 

group by VVWahl, VNummer: R, S 

suchthat R.ZVWahl = “069” and 

S.ZVWahl = “089”; 

Seite 382

Data-Cube Operator 


� n-dimensionale Generalisierung der Idee der Kreuztabellen 

– 0-dimensionale Data Cube ist ein Punkt 

– 1-dimensionale Data Cube ist eine Linie mit einem Punkt 

– 2-dimensionale Data Cube ist eine Kreuztabelle 

– 3-dimensionale Data Cube ist ein Würfel mit drei sich überschneidenden 

Kreuztabellen 

� Beispiel 

– Dimensionsrelationen: Zeit, Geschäft, Produkt und Faktenrelation Verkauf(Umsatz) 

Getränke 

Cappel 

Erlenr. 

Wehrda 

Tee 

Kaffee 

Saft 

Bier 

1. Quart. 

2. Quart. 

3. Quart. 

4. Quart. 

C 

E 

W 

T K S B 

Summe Summe 

Summe 

Summe 

Geschäft 

Seite 383

Darstellung in einer Relation 

Geschäft Produkt Zeit Umsatz 

NULL NULL NULL 10000 

Cappel NULL NULL 3000 

Erlenr. NULL NULL 2000 

Wehrda NULL NULL 5000 

NULL Bier NULL 8000 

NULL Saft NULL 1500 

NULL Kaffee NULL 300 

NULL Tee NULL 200 

NULL NULL 1. Quart. 1000 



NULL NULL 4. Quart 1000 

Cappel Bier NULL 2500 

Wehrda Bier NULL 4000 

Erlenr. Bier NULL 1500 

... ... ... ... 

Erweiterung von group-by 

� Verwendung des Cube-Schlüsselworts 

Beispiel 


select g.Name, z.Quartal, p.Produkt, v.Umsatz 

from Geschäft g, Zeit z, Produkt p, Verkauf v 

where z.ZID = v.ZIDand p.PID = v.PID 

and g.GID = v.GID and 

p.Produktgruppe = “Getränke” and 

z.Jahr = 2005 and 

g.Region = “Marburg” 

group by cube (g.Name, z.Quartal, p.Produkt); 

Dieser Operator wurde auch in den Standard von 

SQL aufgenommen! 

Seite 384

Motivation 

10.6 Materialisieren von Aggregaten 

� Viele Anfragen: Gruppierung der Faktenrelation F 

select g1 , …,gk , agg(f) 

from F 

group by g1 ,…,gk ; 


Ist die Aggregationsoperation vorgegeben kann solch eine Anfrage allein über die Liste 

der Gruppierungsattribute beschrieben werden. 

Notation: (g1 ,…,gk ) 

� Steigerung der Effizienz von Anfragen Q durch Materialisieren von Sichten V, die den 

oben definierten Anfragen entsprechen. 

– Für eine Anfrage Q und eine Sicht V definieren wir 

Q

Beispiel 

� Betrachten wir die Faktenrelation des TPC-D Benchmarks, die aus 3 

Dimensionsattributen Ware, Lieferant, Kunde besteht. 

� Es ergeben sich nun 23 Gruppierungsmöglichkeiten. 

– Diese Gruppierungsmöglichkeiten lassen sich als Knoten in einem Graphen 

veranschaulichen, wobei die Kanten durch die �-Relation gegeben sind. 

– Zusätzlich notieren wir die Anzahl der Tupel in den Sichten. 

(W, L, K) 6M 

(W, K) 6M (W, L) 0.8M (L, K) 6M 

(W) 0.2M (L) 0.01M (K) 0.1M 

() 1 


Seite 386

Problemstellung 


� Nehmen wir vereinfachend an, dass genau n Sichten materialisiert werden können und 

dass die Anfragen identisch zu den Sichten sind. Welche Sichten der Faktenrelation 

sollen materialisiert werden? 

� Die Kosten einer Anfrage werden dabei durch die Anzahl der Tupel von der Sicht v 

ausgedrückt (Cost(v)), die zur Anfragebearbeitung herangezogen wird. 

� Diese Fragestellung kann dahingehend verallgemeinert werden, dass statt der Anzahl der 

Sichten der verfügbare Speicherplatz vorgegeben wird. 

� Bereits diese stark vereinfachte Problemstellung ist NP-vollständig. Deshalb ist es 

gerechtfertigt, Heuristiken zur Lösung heranzuziehen. 

Folgerungen 

� Die oberste Sicht muss stets materialisiert sein, da sonst die entsprechende Anfrage nicht 

beantwortet werden kann. 

Seite 387

Greedy-Algorithmus 


� Im Folgenden betrachten wir einen iterativen Algorithmus zur näherungsweisen Lösung 

des oben genannten Problems. 

– Menge S enthält die bisher ausgewählten Sichten. S wird anfangs mit der obersten 

Sicht initialisiert. 

– Pro Schritt wird die Sicht mit dem höchsten Gewinn hinzugefügt. 

Algorithmus Gewinn(S, V) 

Eingabe: Menge S der ausgewählten Sichten, V eine noch nicht ausgewählte Sicht 

Ausgabe: Der Gewinn der Sicht V. 

1. FOREACH Sicht W mit W � V DO // W ist mittels V berechbar 

minCost := minX� S�W�X Cost�X�; // Betrachte Sichten aus S 

IF Cost(V) < minCost THEN // Bringt V etwas ? 

BW := minCost - Cost(V); 

ELSE 

BW := 0; 

� 

2. RETURN ; // Summe aller Gewinne von V 

W � V 

B W 

Seite 388


� In diesem Kapitel konnte nur kurz die Problemstellung angerissen werden. 

� Interessante Fragestellungen im Bereich des Data-Warehouse sind unter anderem: 

– Wartung und Aufrechterhaltung materialisierter Sichten 

– Datenintegration 

– effiziente Verfahren zum inkrementellen Laden eines Warehouse 

– schnelle Berechnung von Star-Joins 

– Indexstrukturen für Data-Warehouse (Zeit-Indexstrukturen) 

– Data Mining und Visualisierung 

� Organisation der Tabellen nicht mehr zeilen-, sondern spaltenweise 

– Optimale Unterstützung von eindimensionalen Aggregaten 

– Kompression von Spalten 

– Hoher Performancegewinn bei typischen Data-Warehouse-Benchmarks 


Seite 389

A RS - of the AG Database-Systems

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?