Datenbanken I 2. Relationale DB - Technologie der ...

Prof. Dr. rer.nat.habil. Bernhard Thalheim 

Information Systems Engineering 

Institute of Computer Science and Applied Mathematics 

Christian-Albrechts-University Kiel 

Olshausenstr. 40 

D - 24098 Kiel 

 

[];a,, 

Vorlesung Datenbanken I 2. Relationale DB SS 2008 

2 Relationale Datenbanken 

Paradigmen 

formale Sprache \ Theorie Abstraktion Entwurf 

erfinden • • 

verwirklichen 

• 

benutzen 

• 

2.1 Das relationale Modell 

2.1.1 Informale Einführung 

Spezialfall des (nachfolgenden (Kapitel 3)) Entity-Relationship-Modelles: 

keine Relationship-Typen 

damit gelten spezifische Einschränkungen: 

keine expliziten rekursiven Typen 

Sichten ohne rekursive Definition 

Vorteil: nur ein Typenkonstruktur ⇒ einfache Theorie, einfache Operationen, einfache Systeme, Optimierung 

Dafür: 

umfangreiche Theorie der Integritätsbedingungen 

funktionale Abhängigkeiten X −→ Y 

Gültigkeit von funktionalen Abhängigkeiten 

mehrwertige Abhängigkeiten X → Y 

Verbundabhängigkeiten (X 1 , ...X m ) 

Inklusionsabhängigkeiten R[X] ⊆ S[Y ] 

Relationenschema R = (R, X, Σ) über Datenschema BT 

primärer Schlüssel X oder Menge von Schlüsseln K 

Integritätsbedingungen Σ 

Σ ⊆ L R 

für die logische Sprache L R über R 

es werden dem Relationenschema Basis-Datentypen unterlegt 

deshalb besser Basis-Datentypen BT mit Elementen DT (D) = (domain(D), Ops(D), P red(D) 

und Assoziationsschema zum Namensraum dom : U → BT 

Instanz (Ausprägung) [Klasse] als zeitveränderliche Menge von Elementen 

SAT (R)

CAU Kiel, IfI, ISE β SS 2008 Datenbanken I 2. Relationale DB 2 

Modell im Sinne der Modelltheorie der mathematischen Logik 

aufgrund der Mengendefinition: Jede Relation hat mindestens einen Schlüssel: R 

Wir sprechen hier von Schlüsseln und minimalen Schlüsseln 

in anderen Bücher oft Superschlüssel und Schlüssel verwandt 

mitunter auch Schlüsselkandidat 

ein Schlüssel wird ausgezeichnet zur Hauptidentifikation 

außerdem: kürzeste Schlüssel bzgl. der Anzahl der Attribute 

meist wird angenommen: Schlüssel nicht leer 

ansonsten nur einelementige Klassen betrachtet 

Implementationsentscheidung: Primärschlüssel-Werte sind stets vollständig definiert 

wird bei den meisten Systemen gefordert und demzufolge auch in der Literatur 

Relationales Datenbankschema DB = (R 1 , ..., R n , Φ) 

Instanz (Datenbank) 

mit dem Assosiationsschemata dom Ri : R i → BT 

sowie einer Erklärung der Bedeutung der einzelnen Attribute und Relationenschemata 

Dynamisches Relationenschema Dyn R = (R, Dyn Σ) 

über R = (R, X, Σ) über Datenschema BT 

Dynamische Integritätsbedingungen Dyn Σ über ListSAT ((R)) 

Dynamisches relationales Datenbankschema DB = ( Dyn R 1 , ..., Dyn R n , Dyn Φ) 

db - Instanz eines relationalen Datenbankschemas 

Dyn db - Liste von Instanzen eines relationalen Datenbanksschemas, in der Dyn Φ gilt 

Klassifikation der Integritätsbedingungen 

Statische Integritätsbedingungen für eine Datenbank oder eine Klasse meist als implikative Formeln oder auch 

Hornformeln 

Gleichungspostulate, die aus der Gültigkeit von (Un-)Gleichungen die (Un-)Gültigkeit von weiteren Gleichungen 

folgt, insbesondere 

• funktionale Abhängigkeiten 

insbesondere Schlüsselbeziehungen 

Existenzpostulate, die aus der Existenz von Objekten die Existenz von anderen Objekten fordern, insbesondere 

• Inklusionsabhängigkeiten 

• Exklusionsabhängigkeiten 

• mehrwertige, hierarchische und Verbundabhängigkeiten 

Anzahlbeschränkungen, die eine Minimal-/Maximalanzahl von Objekten in Klassen oder Datenbanken 

angeben (formulierbar oft als Gleichungspostulate) 

Dynamische Integritätsbedingungen für Listen von Datenbanken bzw. Klassen 

Transitionsabhängigkeiten, die aufeinanderfolgende Elemente einer Liste beschränken 

temporale Formeln, mit denen für Listen die Gültigkeit eines Zustandes für ein Element der Liste postuliert 

wird 

Instanz ist eine Liste von Klassen, in der Dyn Σ gilt


Update-Operationen 

• Insert - Einfügen eines Elementes in eine Menge 

• Delete - Streichen eines Elementes aus einer Menge nach entsprechender Identifikation 

• Update - Verändern von Attributwerten nach vorgegebener Spezifikation (single-tuple oder multiple-tuple - 

je nach Spezifikation) 

Zusätzliche Annahme: Unique-name-assumption 

Attribute mit den gleichen Namen meinen Gleiches. 

Zusammenhang wird über Inklusionsbeziehung modelliert 

2.1.2 Implizite Annahmen der Spezifikationssprache 

Harmonisierte Assoziationen zu Basis-Datentypen d.h. falls dom Ri (A) und dom Rj (A) beide definiert sind, 

dann sind sie gleich 

dann kann auch dom als eine Funktion geführt werden 

kann ausgebaut werden zur unique name assumption: noch Attribute mit gleicher Bedeutung tragen gleichen 

‘Namen’ 

kann noch weiter ausgebaut werden zur unique flavour assumption: 

nur Attribute mit gleichem Namen können durch (Un)Gleichungsanfragen verbunden werden 

bei allen anderen Attributen ist dies wenig sinnvoll 

für disziplinierte Entwicklung durch aus sinnvoll 

Primary key assumption: alle Werte zum Primärschlüssel sind definiert 

weiterhin: Alle Objekte sind identifizierbar 

Mengensemantik für alle Klassen, alle Komponenten (z.B. Attribute, Relationennamen) 

in SQL-Datenbanken allerdings: Multimengen-Semantik 

Endlichkeitsannahme: alle Klassen sind endlich, eine Datenbank besteht aus endlich vielen Klassen 

2.1.3 Tabellendarstellung von Relationen 

Darstellung der Daten in Tabellenform 

• Tabelle beschreibt einen Entity-Typen 

Klassen werden in Tabellen dargestellt 

• Spalte entspricht einem Attribut 

Spaltennamen - Relationenschema 

• Zeile stellt ein Objekt dar 

Vorsicht: Tabelle kann auch wiederholende Einträge besitzen 

Relation nicht (ist eine Menge) 

Reihenfolge der Zeilen und Spalten unwesentlich wegen eindeutiger Identifikation 

• Attribute durch Attributnamen 

• Zeilen durch ihre Werte auf allen Attributen oder einem Teil der Attribute


Damit kann in Tabellenform der Inhalt dargestellt werden : 

STUDENT 

PNum SNum Hauptf Nebenf Betreuer 

... 

VORLESUNG 

Kurs Raum Zeit Semester Lesender 

.... ... ... .... .... 

VORLESUNG stellt bereits eine Beziehung dar 

damit ist auch eine komplexere Integritätsbeschränkung verbunden: z.B. muß der Kursname legitim sein 

Relationenname, Attributnamen, Schlüssel 

2.1.4 Einschub: Probleme des relationalen Modelles 

Darstellung einer Beziehung von Objekten 

(Relationenmodell unterscheidet nicht zwischen Objekt und Beziehung) 

• als eigenes Relationenschema 

• als Teil eines Relationenschemas, das mehrere Relationenschemata verknüpft 

Problem: 

• Redundanz 

• Konsistenz 

• Verluste (Anomalien) 

Lösung: Normalformen 

• unique-name-assumption 

gleiche Namen bedeuten das Gleiche 

Anmerkung zur Normalisierung: andere Formen neben der vertikalen (attributbasierten) Normalisierung sind 

• horizontale Normalisierung 

• deduktive Normalisierung 

Probleme mit nichtnormalisierten Schemata 

VORLESUNGSBESUCH 

Kurs Raum Zeit Semester Lesender Student Note 

.... ... ... .... .... ... ... 

Eine Verlegung einer Vorlesung in einen anderen Raum bedingt eine umfangreiche Änderung in der Tabelle (nicht 

nur die Änderung eines Datums); 

Löschen einer Note des letzten Studenten läßt letzten Hinweis auf Vorlesung verschwinden; 

ein Eintrag einer neuen Vorlesung ist erst mit der Belegung von Studenten möglich 

damit ist die Tabelle nicht in der geeigneten Form 

Lösung : Normalisierung (s. Kapitel 3)


2.1.5 Darstellung durch Hypergraphen 

Relationales Datenbankschema läßt sich durch Hypergraphen darstellen. 

Damit: Querying Hypergraphen 

Beispiel aus dem Unibeispiel 

Bestimme für den Studenten “Alf Brummkopf” den Fachbereich seines Hauptfaches. 

Relationen: 

• Person = ({Name.First, Name.Fam, Name.Titel, Addr...., Personennummer} , 

{ Personennummer}, ∅) 

• Student = ( { StudNr, Person.Personennummer, Hauptfach.Fachber.DName }, {StudNr}, 

{ { Personennummer } −→ { StudNr } } ) 

• sonstige Semantik: Student[Person.Personennummer] ⊆ Person[Personennummer] ... 

Damit kann dann die Anfrage im Hypergraphen direkt dargestellt werden. 

PERSON 

Name 

Adresse 

PNum 

Spezialis 

PROFESSOR 

SNum 

Hauptf 

Nebenf 

Betreuer 

STUDENT 

Kurs 

Semester 

Note 

TEILNAHME 

Zeit 

Raum 

VORLES 

Darstellung erfolgt nach Einführung der Algebra. 

2.1.6 Die unterlegten Datentypen 

Datentypen sind gegeben durch 

• Wertebereich, 

• Operationen mit entsprechenden Axiomen, 

• Prädikate mit entsprechenden Axiomen. 

Daraus sind insbesondere die folgenden Eigenschaften für die Benutzung in Datenbanken von Relevanz: 

Präzision und Genauigkeit und daraus resultierende Eigenschaften von Operationen


Granularität 

Ordnungsrelationen zur Anordnung von Werten mit unterschiedlichen Ordnungschemata 

Klassifikation (linear, hierarchisch, ...; eindimensional, mehrdimensional; polydimensional; analytisch/synthetisch; 

mono-/polythetisch) 

Speicherformate ggf. mit Auswahl 

Präsentationsformate ggf. mit Verkürzunsregeln 

Default-Werte mit spezifischer Bedeutung 

Rundungsregeln zur Anpassung von / an Werte anderer Typen 

Maßeinheiten mit ggf. Umwandlungsregeln 

Aggregationsoptionen 

Ggf. wird mit der Assoziation eines Datentypen mit einem Attribut eine Verfeinerung vorgenommen. 

Außerdem können Nullwerte zugelassen sein, assoziierbar sein oder auch verboten sein. 

Funktionen besitzen an den “Randpunkten” i.a. anderes Verhalten. 

Spezielle Implementations-Eigenschaften von Attributen u.a. Typen (meaning) 

1. Zeitinvariante Attribute (kein update) (eigentlich aber eine Implementationseinschränkung (es ist nichts in 

der ‘real world’ zeitinvariant)) 

Vorteil: keine Inkonsistenz von Attributwerten (besonders bei Frendschlüsseln bzw. referentieller Integrität - einfache 

Pflege) 

2. Einelementige Schlüssel 

Vorteil: einfache Organisation 

3. (Keine-Nullwerte)-Beschränkung (Totalität von Attributen) 

Vorteil: verwendbar für alles 

4. Ausschluß von Hierarchien 

Vorteil: lesbare und einfache Darstellung von Objekten 

5. Totale, ausschließliche Schlüssel 

Vorteil: Standardrepräsentation, updates sind eindeutig, unique-meaning-assumption, universal-relation-assumption 

6. Default-Werte anstatt Nullwerte 

Vorteil: updates einfacher 

Nachteil: Anfragen verschieden interpretierbar 

Aber Preis dafür ist hoch: 

• Schemas weit entfernt vom Verständnis 

• inflexibel, unnatürlich, redundant 

• Integritätsbedingungen unterrepräsentiert 

• Anfragen sind schwierig darzustellen 

Auffinden der gesuchten Information 

Auswahl bestimmter Objekte durch Spezifikation: 

der Benutzer beschreibt die Zeile (oder Zeilen) mit Hilfe von Mengenoperationen (Relationenalgebra) (Welche 

Information soll aus der Datenbank geliefert werden?) 

Ergebnisrelation


2.1.7 Einführung in die Theorie relationaler Datenbanken 

Wertebereichsschema als Basis-Datentypen: 

DT (D) = (domain(D), Ops(D), P red(D) 

mit Wertebereich, Operationen, Prädikaten (mindestens =) 

Universum der relationalen Datenbank: U = {A 1 , ..., A n } 

Datenschema BT = (U = {A 1 , ..., A n }, {DT (D 1 ), ...., DT (D m )}, dom) 

mit dom : U → {DT (D 1 ), ...., DT (D m )} 

Relationenschema R = (R, X, Σ) über Datenschema BT 

primärer Schlüssel X bzw. Menge von Schlüsseln K ⊆ 2 R , die Sperner-Menge bildet X, Y ∈ K ⇒ X ⊈ Y 

Integritätsbedingungen Σ 

Tupel als Funktion t : R → ∪ A∈R dom(A) mit t(A) ∈ dom(A) 

mitunter auch partielle Funktionen zugelassen 

Instanz (Ausprägung) als Menge von Tupeln 

auch Klasse genannt 

SAT (R) 

jeder Attributname beschreibt eine von n Eigenschaften eines Objektes 

dom(A j ) Menge von atomaren Werten, die Objekte bzgl. A j annehmen können 

R beschreibt eine Klasse von Objekten 

Relation R C stellt Klasse von Objekten dar 

Reihenfolge der Tupel und der Attribute nicht relevant, da Relation und Attributmenge 

1. Normalform: alle Attribute sind atomar 

Dafür: 

umfangreiche Theorie der Integritätsbedingungen 

aufgrund der Mengendefinition: Jede Relation hat mindestens einen Schlüssel: R 

maximale Schlüsselanzahl: 

( ) ‖R‖ 

⌊ ‖R‖ 

2 ⌋ 

läßt sich die Relationengröße abschätzen und bleibt relativ stabil, dann sind fast alle minimalen Schlüssel von der 

Länge 2 ∗ log |dom(R)| (|R C |) 

funktionale Abhängigkeiten X −→ Y 

Gültigkeit von funktionalen Abhängigkeiten 

zwei Tupel mit gleichen X-Werten haben auch gleiche Y -Werte 

Beispiele: 

VORLESUNG: { Kurs, Semester } −→ { Lesender, Zeit, Raum } 

VORLESUNG: { Semester, Raum, Zeit} −→ { Kurs } 

STUDENT: { PNum } −→ { SNum } 

STUDENT: { SNum } −→ { PNum } 

Axiomatisierung für jeweils einen Typen 

Axiome 

X ∪ Y 

−→ Y


Regeln 

X −→ Y 

X ∪ Z ∪ W −→ Y ∪ Z 

X −→ Y , Y −→ Z 

X −→ Z 

weitere Regeln: 

X −→ Y , Y ∪ W −→ Z 

X ∪ W −→ Z 

X −→ Y , X −→ Z 

X −→ Y ∪ Z 

X −→ Y ∪ Z 

X −→ Z 

Theorem 1 Diese Axiomatisierung ist korrekt und vollständig. 

Hüllenkonstruktion mit Schalen 

Σ 1 := {X −→ {A} | A ∈ Y for X −→ Y ∈ Σ} 

X 0 := X 

X i+1 := {A | Z ⊆ X i , Z −→ {A} ∈ Σ 1 } 

Lemma 1 Aus Y ⊆ X ∗ folgt Σ |= X −→ Y 

Beweis: Nachrechnen der Regeln 

Lemma 2 Σ |= X −→ X + 

Beweis: durch Induktion über die Schalen der Hüllenkonstruktion 

i = 0 : Reflexivität 

i+1: Annahme gültig für i-Schale 

d.h. X −→ X i is in R C gültig 

Induktionsziel: X −→ X i+1 is in R C gültig 

damit gilt insbesondere für Objekte mit t = X t ′ auch t = Xi t ′ 

Es sei nun V −→ W in R C gültig 

Fall 1: V ⊈ X “nothing to prove” 

Fall 2: V ⊆ X : damit falls t = V t ′ für t, t ′ ∈ R C damit auch wegen Gültigeit in R C t = W t ′ 

Zum anderen aber : aufgrund der Schalenkonstruktion der Hülle: 

t = Xi+1 t ′ 

Lemma 3 Y ⊆ X ∗ falls Σ |= X −→ Y 

Beweis über die Konstruktion einer Kontraposition 

Armstrong-Relation R C mit der gezeigt werden kann Y ⊈ X + 

Kontraposition: t, t ′ mit t(A) = t ′ (A) gdw. A ∈ X + 

1. {t, t ′ } ̸|= X −→ Y für eine X −→ Y ∈ Σ


damit auch ein Attribut von Y nicht Element von X + 

damit Eigenschaft erfült 

2. {t, t ′ } |= Σ 

gegeben nun V −→ W ∈ Σ 

Fall 1 : {t, t ′ } |= V −→ W wegen t ≠ V t ′ 

Fall 2 : t = V t ′ damit auch W ⊆ X ∗ wegen vorigen Lemmas 

damit auch t = X t ′ und somit {t, t ′ } |= V −→ W 

Schichtung und graphische Darstellung für funktionale Abhängigkeiten 

Beispiel: 

{ PersNr } −→ { Name, Raum, PLZ, Straße } 

{ Raum } −→ { PersNr } 

{ Ort, Bundesland, Straße } −→ { PLZ } 

{ PLZ } −→ { Ort, Bundesland } 

{ Ort, Bundesland } −→ { Vorwahl, Einwohneranzahl } 

{ Bundesland } −→ { ParteiMinisterpräsident } 

mehrwertige Abhängigkeiten X → Y 

Gültigkeit mehrwertiger Abhängigkeiten 

mehrere äquivalente Definitionen: 

• Die Y -Werte hängen von den X-Werten prädikativ ab und nur von diesen. 

(σ X=x (R C ))[Y ] = (σ X=x∧Z=z (R C ))[Y ] Z = R \ (X ∪ Y ) 

Durch Z-Werte kann man die tupel nicht genauer unterscheiden, wenn man die X-Werte schon zur Unterscheidung 

herangezogen hat. 

• Stimmen zwei Tupel über X überein, dann exisitiert ein drittes Tupel, das Werte vom ersten Tupel über 

X ∪ Y und vom zweiten Tupel über X ∪ (R \ Y ) übernimmt. 

∀t 1 , t 2 ∃t 3 ((P R (t 1 ) ∧ P R (t 1 ) ∧ t 1 = X t 2 ) −→ (P R (t 3 ) ∧ t 1 = X∪Y t 3 ∧ t 2 = X∪Z t 3 )) 

• Die Relation läßt sich in der genesteten Form X, Y \ X, R \ (X ∪ Y ) darstellen. 

X Y \ X R \ (X ∪ Y ) 

A 1 ... A k B 1 ... B l C 1 ... C m 

... ... ... ... ... ... ... ... ... 

• Man kann die Relation verlustfrei zerlegen in eine Projektion über X ∪ Y und über X ∪ (R \ Y ). Alle Tupel 

und nur diese lassen sich aus diesen Projektionen wiedergewinnen. 

Beispiele: 

STUDENT: { PNum } → { Nebenf } 

STUDENT: { SNum } → { Betreuer } 

Axiomatisierung gemeinsam mit funktionalen Abhängigkeiten 

Axiome 

X ∪ Y −→ Y ; X ∪ Y → Y | Z 

Regeln 

X → Y | Z 

X → Z | Y 

X −→ Y 

X ∪ V ∪ W −→ Y ∪ V 

X −→ Y , Y −→ Z 

X −→ Z 

X ∪ Y ∪ Z → V | W ∪ U , X → Y ∪ V ∪ W | Z ∪ U 

X ∪ Y → V | Z ∪ W ∪ U 

X −→ Y 

X → Y | Z Z = attr(R) − (X ∪ Y ) X → Y | V , Z −→ W 

X −→ W 

W ⊆ Y, Y ∩ Z = ∅ .


Verbundabhängigkeiten (X 1 , ...X m ) 

X 1 ∪ ... ∪ X m = R 

Gültigkeit der Verbundabhängigkeiten 

Man kann die Relation verlustfrei zerlegen in eine Projektion über X 1 , ... über X m . Alle Tupel und nur diese lassen 

sich aus diesen Projektionen wiedergewinnen. 

Inklusionsabhängigkeiten R[X] ⊆ S[Y ] 

auch zur Darstellung der referentiellen Integrität (Tupel, die von Tupelns anderer Relationen referenziert werden) 

(Existenzbedingung) 

Gültigkeit der Inklusionsabhängigkeiten 

Die X-Werte von R C kommen in S C [Y ] vor. 

Beispiel: 

VORLESUNGSBESUCH[Student] ⊆ STUDENT[SNum] 

Exklusionsabhängigkeiten R[X]||S[Y ] 

Gültigkeit der Exklusionsabhängigkeiten 

Die X-Werte von R C kommen nicht in S C [Y ] vor. 

Beispiel: 

VORLESUNGSBESUCH[Student] || VORLESUNGSBESUCH[Lesender] 

weitere Bedingungen über funktionale und mehrwertige Abhängigkeiten 

siehe auch Entwurfstheorie - hier nur im Vorgriff 

2. Normalform Teilschlüssel implizieren nicht Nicht-Schlüsselattribute 

3. Normalform jedes Nicht-Schlüssel-Attribut darf nur direkt von einem Schlüssel abhängen (kein transitiver 

Schluß) 

Boyce-Codd-Normalform jede nicht-triviale funktionale Abhängigkeit ist eine Schlüsselabhängigkeit 

4. Normalform jede geltende mehrwertige Abhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten 

5. Normalform jede geltende Verbundabhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten 

Einfüge-, Lösch- und Update-Anomalien treten genau dann nicht auf, wenn nur funktionale Abhängigkeiten gelten 

und Relationenschema in BCNF ist 

2.2 Die relationale Algebra 

2.2.1 Operationen der Relationenalgebra und ihre Eigenschaften 

Operationen der Relationenalgebra 

Selektion: Auswahl einer Zeile mit bestimmten Wertemerkmalen (erfüllen gestellte Bedingung) 

Projektion: Auswahl von Teilen von Zeilen (Spalten) 

Verbund: Verknüpfung zweier Tabellen zu eienr Tabelle, die alle Attribute beider Tabellen enthält; Zeilen der Ergebnistabelle 

bestehen aus Verkettung einer Zeile der ersten Tabelle und einer Zeile der zweiten Tabelle, wobei


diese beiden Zeilen in den gemeinsamen Attributen übereinstimmen müssen (dadurch kann Doppelung weggelassen 

werden) 

Mengenoperationen: Vereinigung, Durchschnitt, Mengendifferenz 

Operationen des relationalen Modelles 

• Für R C , R ′C R = (R, X, Σ) : 

• R C ∪ R ′C (Vereinigung), 

• R C ∩ R ′C (Durchschnitt) und 

• R C \ R ′C (Mengen- Differenz) 

• D R DD \ RC Komplement unsafe !! 

• Für R C ∈ SAT (R), A, C ∈ {B 1 , ..., B n }, Wert a ∈ dom(A), Vergl.-op. θ ∈ {≤, ≥, ≠, =, }, 

Selektionen σ Aθa , σ AθC sind die Teilmengen {t ∈ R C | t(A)θa} und {t ∈ R C | t(A)θt(C)} von R C . 

Für t über Y ⊆ R Beschränkung von R C nach t ist definiert: σ t (R C ) = {t ′ ∈ R C | t ′ [X] = t} 

• Operationen zwischen Schemata: 

Für Tupel t über R und Teilmenge Y ⊆ R Projektion von t auf X, t[Y ] : Einschränkung von t auf Y 

Projektion R C [Y ] = π X (R C ) von R C auf Y : {t[Y ] | t ∈ R C } 

Attributabbildungsfunktion η : R −→ S 

η-Projektion π η (R C ) = {s ∈ D S DD |∃t ∈ RC : s = η(t)} 

damit Projektion, Umbenennung, Vervielfachung von Spalten 

• Zwei Schemas R = (R, X, Σ), R ′ = (R ′ , X ′ , Σ ′ ) und Relationen R C , R ′C 

• (natürlicher) Verbund R C ✶ R ′C von R C , R ′C 

{t | t[{B 1 , ..., B n }] ∈ R C , t[{B ′ 1 , ..., B′ n ′ }] ∈ R ′C } definiert über R ∪ R ′ 

• allgemeiner Verbund (Theta-Join) 

• kartesisches Produkt - R ∩ R ′ = ∅ - natürlicher Verbund 

• Teilverbund (semijoin oder equi-semijoin) R C ×⊲ S C = R C ✶ π R∩S (S C ) 

• verallgemeinerte Vereinigung R C + S C = {τ ∈ D R∪S 

DD |τ(R) ∈ RC ∨ τ(S) ∈ S C } 

• Division (Quotient) R C /S C = {τ ∈ D R\S 

DD |∀ν ∈ π R∩S(S C ) : {τ} ∪ {ν} ⊆ R C } 

= {τ ∈ π R∩S (R C )|{τ} ✶ π R∩Y (S C ) ⊆ R C } 

Die Division ist darstellbar durch 

π R−S (R C ) \ π R−S ((π R−S (R C ) × S) \ R) for R − S = attr(R) \ attr(S). 

Diese Operation is wichtig für die horizontale Reduktion oder Dekomposition. Man kann R C /S C 

nutzen zur Wiedergewinnung von R C durch 

R C = (π attrR ((R C /S C ) × S C )) ∪ (R C \ R C /S C ) 

Umschreibung: ∀s ∈ S C ∃t ∈ R C : s[attr(S) ∩ attr(R)] = t[attr(S) ∩ attr(R)] 

damit ist ein Generalisator mit gegeben. 

Die Division wird oft auch mit R C ÷ S C angegeben. 

Ein Beispiel einer auf diese Art einfach formulierbaren Anfrage ist 

Alle Studenten, die alle Vorlesungen von Thalheim hörten: 

Teilnahme ÷ π V orlesNr (σ Dozent=“T halheim ′′(V orlesung)). 

• linker äußerer Verbund 

R C –✶ S C = R C ✶ S C ∪ 

{t×NULL ∈ dom(attr(R)∪attr(S)|π attr(R)∩attr(S) (t) ∉ π attr(R)∩attr(S) (S C )}


• rechter äußerer Verbund 

R C ✶– S C = R C ✶ S C ∪ 

{NULL×t ∈ dom(attr(R)∪attr(S)|π attr(R)∩attr(S) (t) ∉ π attr(R)∩attr(S) (R C )} 

• voller äußerer Verbund 

• linker Halb-Verbund (left Semi-Join) R C ⋉ S C = π attr(R)\attr(S) (R C ✶ S C ) 

• rechter Halb-Verbund (right Semi-Join) R C ⋊ S C = π attr(S)\attr(R) (R C ✶ S C ) 

• Algebra mit Nullwerten 

Vorsicht: Ist durch Nullwerte verschieden von bisher betrachteter Algebra! 

Nullwerte haben mindestens 14 verschiedene Bedeutungen. Gewöhnlich betrachten wir als Bedeutungen 

• (a) unbekannt (no information, unknown) 

• (b) not applicable 

• (c) not existent 

Die Anfragen σ Note


• Eigenschaften : 

• Verbund: kommutativ, assoziativ, 

monoton (R C ⊆ S C ⇒ R C ✶ T C ⊆ S C ✶ T C ), 

absorbtiv (R C ⊆ R t+ ⇒ R C ✶ R t+ = R C ), 

idempotent, R C ✶ ∅ = ∅ 

R C ✶ S C = R C × S C falls R ∩ S = ∅ 

R C ✶ S C = R C ∪ S C falls R = S 

• 

⎧ 

⎨ σ A=c (R C ) ✶ S C 

σ A=c (R C ✶ S C ) = σ 

⎩ A=c (R C ) ✶ σ A=c (S C ) 

R C ✶ σ A=c (S C ) 

falls A ∈ R \ S 

falls A ∈ R ∩ S 

falls A ∈ S \ R 

• R C ⊆✶ k i=1 π X i 

(R C ) für ∪ k i=1 X i = R 

• π Xj (✶ k i=1 RC i ) ⊆ RC j 

• R C =✶ k i=1 π X i 

(R C ) dann gilt die Verbundabhängigkeit (X 1 , ...X k ) in R C 

• π X (R C ✶ S C ) = π X (R C ) ✶ π X (S C ) falls R ∩ S ⊆ X 

• π X (σ A=c (R C ) = σ A=c (π X (R C )) falls A ∈ X ∩ R 

• π X (π Y (R C )) = π X∩Y (R C ) 

• verallgemeinerte Vereinigung ist kommutativ, idempotent, monoton, assoziativ, distributiv mit Verbund 

• Selektion σ A=c , σ A≠c definieren Partition 

• σ X=Y (R C ) = σ A1 =B 1 

(σ A2 =B 2 

(...σ Am =B m 

(R C )...)) für X = A 1 , ...A m , Y = B 1 , ..., B m 

• (R C ✶ S C )/S C = R C falls R ∩ S = ∅ 

r C /S C = π R\S (R C ) \ π R\S ((π R\S (R C ) ✶ π R∩S (S C )) \ R C ) 

• R = (R, X, Σ), Attribute A ∈ R, B ∈ U \ {B 1 , ..., B n } Relation R C Umbenennung ϱ A|B (R C ) : 

{t | for some t ′ ∈ R C : t(B) = t ′ (A), t[{B 1 , ..., B n } \ {A}] = t ′ [{B 1 , ..., B n } \ {A}]} 

über ({B 1 , ..., B n } \ {A}) ∪ {B} 

• Strukturelle Rekursion Gegeben T , T ′ , Kollektionstypen C T über T (d.h. Wertemengen vom Typ T , Multimengen, 

Listen) 

Operationen wie verallgemeinerte Vereinigung ∪ C T , verallgemeinerten Durchschnitt ∩ C T , verallgemeinertes 

leeres Element ∅ C T von C T 

gegeben h 0 über T ′ und 2 Funktionen 

h 1 : T → T ′ h 2 : T ′ × T ′ → T ′ . 

• Strukturelle Rekursion mit Insert-Definition für R C über T 

srec h0 ,h 1 ,h 2 

(∅ C T ) = h 0 

srec h0 ,h 1 ,h 2 

({|s|}) = h 1 (s) für ein-elementige Kollektionen {|s|} 

srec h0 ,h 1 ,h 2 

({|s|} ∪ C T R C ) = h 2 (h 1 (s), srec h0 ,h 1 ,h 2 

(R C )) gdw. {|s|} ∩ C T R C = ∅ C T . 

• Strukturelle Rekursion über Vereinigungs-Definition 

srec h0 ,h 1 ,h 2 

(∅ C T ) = h 0 

srec h0 ,h 1 ,h 2 

({|s|}) = h 1 (s) für einelementige Kollektionen {|s|} 

srec h0 ,h 1 ,h 2 

(R1 C ∪ C T RC 2 ) = h 2(srec h0 ,h 1 ,h 2 

(R1 C), srec h 0 ,h 1 ,h 2 

(R2 C)) gdw. RC 1 ∩ C T RC 2 = 

∅ C T . 

• Einschränkung auf Funktionen h 0 =⊥, Vereinigung ∪ T ′, Nullelement ⊥ of T ′ 

dann immer wohldefiniert 

• eingeschränkte strukturelle Rekursion definiert durch Funktion h 1 

d.h. Erweiterung der Funktion h 1 

ext(h 1 )(R C ) = srec ⊥,h1 ,∪ T ′ (R C ) .


Äquivalent zu comprehensions 

• allgemeine Aggregation pump definiert durch strukturelle Rekursion mit T ′ = IN 

Beispiele: 

• sum mit Startwert 0 und + für h 2 

d.h. pump = srec 0,h1 ,+ = ext(h 1 ) 

• map - restrukturiert jedes Element über T 

Typ T ′ ist Kollektionstype 

mit einem Paramenter h 1 und für R C ⊆ T C wird der Wert {h 1 ({s}) | s ∈ R C } erzeugt, d.h. 

srec ∅,h1 ,∪ = ext(h 1 ) 

nest basiert auf einer Äquivalenzrelation über einem oder mehreren Attributen von T C mit gemeinsamen 

Werten und Kombinator h 2 

• filter Operation über splitting von h 1 und h 2 = ∪, T ′ = {T }, d.h. srec ∅,h1 ,∪ = ext(h 1 ) 

definiert über Formeln α von L T mit einer freien Variablen x ( α = α(x), filter = filter α ) 

h 1 ({s}) = 

{ {s} if |= α(s) 

if ̸|= α(s) 

h 0 

• SQL-Ausdruck der Form Select ... From ... Where ... sind Ausdrücke der Form map(filter(...)) 

• Group By ... Konstrukt - spezieller map Ausdruck 

Beispiele zur relationalen Algebra. 

(aus dem Material 1 der vorangegangenen Jahre) 

Relationen sind Mengen von Tupeln. Deshalb lassen sich die üblichen Mengenoperationen auf Relationen anwenden. 

Seien R un S zwei Relationen über denselben Attributen. Dann ist 

Beispiele: 

MITARBEITER 

Name Wohnort 

Max Müller 

Tina Schmidt 

Klaus Meyer 

Kiel 

Lübeck 

Kiel 

MITARBEITER ∪ STUDENTEN 

Name Wohnort 

Max Müller 

Tina Schmidt 

Klaus Meyer 

Andre Petersen 

Thomas Ebert 

Kiel 

Lübeck 

Kiel 

Hamburg 

Rendsburg 

MITARBEITER \ STUDENTEN 

Name 

Wohnort 

R ∪ S = {t|t ∈ R ∨ t ∈ S} 

R ∩ S = {t|t ∈ R ∧ t ∈ S} 

R\S = {t|t ∈ R ∧ t /∈ S} 

STUDENTEN 

Name 

Max Müller 


Thomas Ebert 

Wohnort 

Kiel 

Hamburg 

Rendsburg 

MITARBEITER ∩ STUDENTEN 

Name Wohnort 

Max Müller 

Tina Schmidt Lübeck 

Klaus Meyer Kiel 

Wichtig: die Mengenoperationen sind nur für Relationen mit denselben Attributen definiert! 

1 Dieser Teil des Skriptum wurde von G. Fiedler (mein Dank dafür) erstellt. 

Kiel


Selektion. 

Mit Hilfe der Selektion werden auf Grundlage einer gegebenen aussagenlogischen Formel die Tupel aus einer 

Relation ausgewählt, die diese Formel erfüllen. Die Formel ϕ darf nur Aussagen über Attribute enthalten, die in R 

vorhanden sind. 

Beispiele: 

σ W ohnort= ′ Kiel ′(MITARBEITER) 

Name Wohnort 

σ ϕ (R) = {t|t ∈ R ∧ t |= ϕ} 

Max Müller Kiel 

Klaus Meyer Kiel 

MITARBEITER ∪ (σ W ohnort= ′ Rendsburg ′(STUDENTEN)) 

Name 

Max Müller 

Tina Schmidt 

Klaus Meyer 

Thomas Ebert 

Projektion. 

Wohnort 

Kiel 

Lübeck 

Kiel 

Rendsburg 

Die Projektion erstellt aus einer gegebenen Relation eine neue Relation, indem sie nur eine Teilmenge der vorhandenen 

Attribute auswählt. Während die Selektion Tupel auswählt, also bildlich gesprochen ” 

Zeilen entfernt“, 

wählt die Projektion Attribute aus, d.h. es werden ” 

Spalten entfernt“. Die Liste der Attribute, die in die Zielrelation 

übernommen werden sollen, werden der Projektion als Parameter mitgegeben. Die Menge der Zielattribute muß 

natürlich eine (echte oder unechte) Teilmenge der Attribute der gegebenen Relation sein. Man beachte, daß Relationen 

Mengen sind. Falls durch die Projektion doppelte Tupel entstehen, fallen diese zu einem einzigen Tupel in der 

Zielrelation zusammen. Da wir Tupel als Funktionen definiert haben, die Attribute auf Werte abbilden, können wir 

die Projektion als Einschränkung des Definitionsbereichs der Funktion auf die gewünschten Attribute definieren. 

Beispiele: 

π Name (STUDENTEN) 

Name 

Max Müller 


Thomas Ebert 

π W ohnort (MITARBEITER) 

Wohnort 

Kiel 

Lübeck 

Umbenennung. 

π A1 ,...,A n 

(R) = {t| A1 ,...,A n 

| t ∈ R} 

Die Umbenennung gibt einem Attribut einen neuen Namen. Die Wertebereichsfunktion muß diese Umbenennung 

zulassen, d.h. die Datentypen des alten und des neuen Attributs müssen identisch sein. Außerdem darf der 

neue Attributname noch nicht in der Menge der Attribute der Relation enthalten sein. Sei attr(R) die Menge der 

Attribute der Relation R: 

ϱ A→B (R) = {t| attr(R)\{A} ∪ {(B, t(A))} | t ∈ R}


Natürlich kann man mehrere Attribute “in einem Rutsch” umbenennen. Dabei schreibt man die einzelnen Umbenennungen 

mit Komma getrennt als Parameter des Operators. Dies ist dann identisch mit der Nacheinanderausführung 

der einzelnen Umbenennungen. 

Beispiel: 

ϱ W ohnort→Ort (STUDENTEN) 

Name Ort 

Max Müller 


Thomas Ebert 

Natürlicher Verbund. 

Kiel 

Hamburg 

Rendsburg 

Der natürliche Verbund wird benutzt, um zwei Relationen zu verbinden. Die Attribute der beiden Relationen R 

und S lassen sich in drei Gruppen einteilen: 

1. Attribute, die in R, aber nicht in S vorkommen 

2. Attribute, die in S, aber nicht in R vorkommen 

3. Attribute, die in beiden Relationen vorkommen 

Die Attribute der dritten Kategorie bilden das ” 

verbindende Element“ der beiden Relationen. Wir erzeugen die 

Tupel t der Ergebnisrelation R ⊲⊳ S so, daß 

1. wenn wir t auf die Attribute von R projizieren, ein gleiches Tupel in R existiert und 

2. wenn wir t auf die Attribute von S projizieren, ein gleiches Tupel in S existiert. 

Daraus folgt, daß wir alle Paare von Tupeln r ∈ R und s ∈ S betrachten, die in den gemeinsamen Attributen 

(Kategorie drei) die gleichen Werte haben. Wir verbinden die beide Tupel r und s zu t und fügen t zur Ergebnisrelation 

hinzu. 

R ⊲⊳ S = {t | t| attr(R) ∈ R ∧ t| attr(S) ∈ S} 

Wenn wir uns einen Algorithmus zum Berechnen des natürlichen Verbunds zweier Relationen überlegen, 

können wir u.a. den Nested-Loop-Join“ anwenden. Seien A ” 1 , ..., A n die gemeinsamen Attribute der Relationen R 

und S, dann berechnet sich der natürliche Verbund T = R ⊲⊳ S folgendermaßen: 

T := ∅ 

FORALL r IN R DO 

FORALL s IN S DO 

IF r.A 1 = s.A 1 AND ... AND r.A n = s.A n THEN 

t := r ∪ s 

T := T ∪ {t} 

END IF 

END FOR 

END FOR 

RETURN T 

Weitere (effizientere) Algorithmen zur Berechnung des natürlichen Verbunds werden wir später kennenlernen. 

Beispiele:


VORLESUNG 

Kuerzel Bezeichnung 

SysInf IV 

Info III 

Info II 

SysInf I 

Datenbanken I 

Softwaretechnologie 

Algorithmen und Datenstrukturen 

Digitale Systeme 

STUDENTEN ⊲⊳ HOERT 

Name Wohnort Kuerzel 

Max Müller Kiel SysInf IV 

Max Müller Kiel Info III 

Andre Petersen Hamburg Info II 

Andre Petersen Hamburg Info III 

STUDENTEN ⊲⊳ HOERT ⊲⊳ VORLESUNG 

Name Wohnort Kuerzel Bezeichnung 

HOERT 

Name 

Max Müller 

Max Müller 



Kuerzel 

Max Müller Kiel SysInf IV Datenbanken I 

Max Müller Kiel Info III Softwaretechnologie 

Andre Petersen Hamburg Info II Algorithmen und Datenstrukturen 

Andre Petersen Hamburg Info III Softwaretechnologie 

π Name,Bezeichnung ((σ W ohnort= ′ Kiel ′(STUDENTEN)) ⊲⊳ HOERT ⊲⊳ VORLESUNG) 

Name 

Bezeichnung 

SysInf IV 

Info III 

Info II 

Info III 

Max Müller Datenbanken I 

Max Müller Softwaretechnologie 

Der Student Max Müller hört die Veranstaltungen mit den Kürzeln SysInf IV“ und Info III“. Wenn wir die 

” ” 

Relationen STUDENTEN und HOERT verbinden, ist Name das einzige gemeinsame Attribut. Wir schauen also 

alle Tupel in STUDENTEN an. Für jeden gefundenen Studenten schauen wir uns alle Tupel in HOERT an. Wenn 

wir einen Studenten und ein HOERT-Tupel finden, die im Attribut Name übereinstimmen, dann verbinden wir die 

beiden Tupel und fügen das neue Tupel zum Ergebnis hinzu. Da der Student Thomas Ebert keine Veranstaltung 

hört, fällt er aus dem Ergebnis heraus. 

Auf die gleiche Art und Weise können wir das so entstandene Ergebnis mit der Relation VORLESUNG verbinden. 

Kuerzel ist das verbindende Attribut. Da die Veranstaltung SysInf I“ von keinem Studenten gehört wird, 

” 

taucht sie in der Ergebnisrelation nicht auf. 

Falls die beiden Relationen R und S keine gemeinsamen Attribute haben, wird das Kreuzprodukt beider Relationen 

gebildet, d.h. jedes Tupel aus R wird mit jedem Tupel aus S verknüpft. 

Division. 

Der Divisionsoperator erlaubt die kompakte Formulierung von für-alle“-Anfragen. Betrachten wir folgende 

” 

Relationen: 

HOERT 

VORLESUNG 

Name Kuerzel 

Kuerzel Bezeichnung 

Max Müller SysInf IV 

SysInf IV Datenbanken I 

Max Müller Info III 

Info III Softwaretechnologie 

Max Müller Info II 

Info II Algorithmen und Datenstrukturen 

Max Müller SysInf I 

SysInf I Digitale Systeme 

Andre Petersen Info II 

Andre Petersen Info III 

Wenn man jetzt die Anfrage Welcher Student hört alle Vorlesungen“ stellt, dann suchen wir die Namen, für 

” 

die für jedes Kürzel in der Relation VORLESUNG ein passendes Tupel in der Relation HOERT existiert (in unserem 

Beispiel ist dies Max Müller.) Das leistet der Divisionsoperator: 

HOERT ÷ (π Kuerzel (VORLESUNG))


Name 

Max Müller 

Formal gesprochen: es existieren zwei Relationen R und S, wobei die Attributmenge der Relation S eine echte 

Teilmenge der Attributmenge von R ist: attr(S) attr(R). Das Ergebnis der Division ist eine Relation über 

den Attributen, die in R, aber nicht in S vorkommen (attr(R ÷ S) = attr(R)\attr(S)). Diese Relation enthält 

genau die Tupel t, die aus einem Tupel r ∈ R durch Projektion auf attr(R)\attr(S) entstehen, so daß man dieses 

Tupel mit allen Tupeln s ∈ S ergänzen kann, um wieder ein Tupel aus R zu erzeugen. Mit anderen Worten: das 

Ergebnistupel t steht in R mit allen Tupeln der Relation S ” 

in Beziehung“: 

Anfragebeispiele. 

R ÷ S = {t | attr(t) = attr(R)\attr(S) ∧ {t} ⊲⊳ S ⊆ R} 

Wir wenden nun die vorgestellten Operationen an, um Anfragen an ein Beispielschema zu stellen. Wichtig: 

wir stellen Anfragen immer gegen ein Datenbankschema, nicht gegen einen konkreten Datenbankzustand. Die 

Auswertung der Anfrage erfolgt stets bzgl. eines konkreten Datenbankzustandes. Unsere Anfrage muß aber für 

alle gültigen Zustände unseres Schemas funktionieren. 

Wir benutzen folgendes Beispielschema (Primärschlüssel sind unterstrichen): 

{ 

STUDENT({MatrikelNr,Name,Wohnort}), 

MITARBEITER({BearbeiterNr,PersonalNr,Name,Wohnort}), 

VORLESUNG({VorlesungsNr,Bezeichnung}), 

DOZENT({BearbeiterNr,PersonalNr,VorlesungsNr}), 

HOERT({MatrikelNr,VorlesungsNr,Wiederholung}), 

FINDETSTATT({VorlesungsNr,Zeit,RaumNr}), 

RAUM({RaumNr,Bezeichnung}) 

} 

Folgende Fremdschlüssel sind definiert: 

DOZENT [BearbeiterNr, P ersonalNr] ⊆ MIT ARBEIT ER[BearbeiterNr, P ersonalNr] 

DOZENT [V orlesungsNr] ⊆ V ORLESUNG[V orlesungsNr] 

HOERT [MatrikelNr] ⊆ ST UDENT [MatrikelNr] 

HOERT [V orlesungsNr] ⊆ V ORLESUNG[V orlesungsNr] 

F INDET ST AT T [V orlesungsNr] ⊆ V ORLESUNG[V orlesungsNr] 

F INDET ST AT T [RaumNr] ⊆ RAUM[RaumNr] 

1. Anfrage Gib die Bezeichnung der Vorlesung ’080104’.“ 

” 

Die Daten zu Vorlesungen stehen in der Relation VORLESUNG. ’080104’ ist eine Vorlesungsnummer einer konkreten 

Vorlesung, also müssen wir diese konkrete Vorlesung selektieren. Wir interessieren uns nur für die Bezeichnung 

dieser Vorlesung, also müssen wir das Ergebnis auf das Attribut Bezeichnung projizieren: 

π Bezeichnung (σ V orlesungsNr= ′ 080104 ′(V ORLESUNG)) 

2. Anfrage Gib die Namen aller Studenten, die die Veranstaltung ’080104’ hören, zusammen mit den Namen 

” 

aller Dozenten der Veranstaltung ’080104’. 

Die Daten der Studenten stehen in der Relation STUDENTEN, die Teilnahme in der Relation HOERT. Wenn 

wir aus HOERT die Tupel für die Veranstaltung ’080104’ selektieren, erhalten wir die Matrikelnummern der an 

’080104’ teilnehmenden Studenten. Wenn wir dieses Zwischenergebnis mit der Relation STUDENTEN verbinden 

und anschließend projizieren, erhalten wir die Namen dieser Studenten. Analog verfahren wir mit DOZENT und 

MITARBEITER. Beide Relationen zusammen bilden das Ergebnis der Anfrage.


π Name ((σ V orlesungsNr= ′ 080104 ′(HOERT )) ⊲⊳ ST UDENT EN) ∪ 

π Name ((σ V orlesungsNr= ′ 080104 ′(DOZENT )) ⊲⊳ MIT ARBEIT ER) 

3. Anfrage Angenommen, der Name identifiziert eine Person eindeutig. ” 

Gib die Personen, die Dozent einer 

Veranstaltung sind und sich parallel dazu für diese Veranstaltung als Student angemeldet haben.“ 

Wir verbinden die DOZENT-Relation mit der MITARBEITER-Relation und projizieren anschließend auf die Attribute 

Name und VorlesungsNr, so bekommen wir die Namen der Dozenten einer Veranstaltung. Analog verfahren 

wir mit den eingeschriebenen Studenten. Der Durchschnitt beider Mengen enthält die Personen, die gleichzeitig 

Dozent und Student einer Vorlesung sind. 

π Name,V orlesungsNr (DOZENT ⊲⊳ MIT ARBEIT ER) ∩ 

π Name,V orlesungsNr (HOERT ⊲⊳ ST UDENT ) 

4. Anfrage Finde Überschneidungen, d.h. gib die Namen der Studenten zusammen mit der entsprechenden Zeit 

” 

aus, so daß dieser Student zu diesem Zeitpunkt in zwei Räumen präsent sein muß.“ 

Wir bilden für jeden Studenten Paare von Teilnahmen an Vorlesungsdurchführungen und verwerfen die Paare, 

deren Zeiten unterschiedlich sind. Teilnahmen an Vorlesungsdurchführungen erhalten wir durch das Verbinden der 

Relationen HOERT und FINDETSTATT. Da Fremdschlüssel bzgl. der Relation VORLESUNG definiert sind, können 

wir die Relation VORLESUNG weglassen 2 . Wir benötigen das Attribut MatrikelNr aus HOERT und die Attribute 

Zeit und RaumNr aus FINDETSTATT. Wir führen diese Anfrage zweimal aus, beim zweiten mal benennen wir 

alle Attribute bis auf die Matrikelnummer um. Anschließend selektieren wir alle Tupel, deren Zeiten gleich, deren 

Räume aber verschieden sind. Diese Menge verbinden wir mit der STUDENT-Relation und projizieren alles außer 

dem Namen und der Zeit aus. π Name,Zeit ( 

σ Zeit=Zeit2∧RaumNr!=RaumNr2 ( 

π MatrikelNr,Zeit,RaumNr (HOERT ⊲⊳ F INDET ST AT T ) 

⊲⊳ 

(ϱ Zeit→Zeit2,RaumNr→RaumNr2 ( 

π MatrikelNr,Zeit,RaumNr (HOERT ⊲⊳ F INDET ST AT T ) 

)) 

) 

⊲⊳ 

STUDENT 

) 

5. Anfrage Gib die Studenten, die bei allen Dozenten eine Veranstaltung hören.“ 

” 

Zunächst benötigen wir eine Zuordnung von Studenten (Matrikelnummern) zu Dozenten (Bearbeiternummer, Personalnummer). 

Anschließend teilen wir diese Relation durch die Relation mit allen Dozenten (Bearbeiternummer, 

Personalnummer) und erhalten das gewünschte Ergebnis. 

(π MatrikelNr,BearbeiterNr,P ersonalNr (HOERT ⊲⊳ DOZENT )) 

÷ 

(π BearbeiterNr,P ersonalNr (DOZENT )) 

2.2.2 Anfragen mit der Relationenalgebra 

• Abbildung Q DD : SAT (RS) −→ SAT (R) 

• universumstreu µ ∈ Q DD ∧ A ∈ R ⇒ µ(A) ∈ D DD 

2 Überlegen Sie sich, was passiert, wenn die Fremdschlüssel nicht definiert wären.


• berechenbar - partiell rekursive Funktion 

• isomorphietreu - für Datenbanken M, M’ über Datenschemes DD, DD ′ und eine Bijektion von DD auf 

DD ′ 

M 

h 

✲ 

M ′ 

Q 

❄ 

Q(M) 

h 

✲ 

Q 

❄ 

h(Q(M)) = q(M ′ ) = Q(h(M)) 

Damit: Querying Hypergraphen 

Beispiel aus dem Unibeispiel 

Bestimme für den Studenten “Alf Brummkopf” den Fachbereich seines Hauptfaches. 

Relationen: 

• Person = ({Name.First, Name.Fam, Name.Titel, Addr...., Personennummer} , 

{ Personennummer}, ∅) 

• Student = ( { StudNr, Person.Personennummer, Hauptfach.Fachber.DName }, {StudNr}, 

{ { Personennummer } −→ { StudNr } } ) 

• sonstige Semantik: Student[Person.Personennummer] ⊆ Person[Personennummer] ... 

Damit kann dann die Anfrage im Hypergraphen direkt dargestellt werden. 

PERSON 

Name 

Adresse 

PNum 

Spezialis 

PROFESSOR 

SNum 

Hauptf 

Nebenf 

Betreuer 

STUDENT 

Kurs 

Semester 

Note 

TEILNAHME 

Zeit 

Raum 

VORLES 

Darstellung erfolgt nach Einführung der Algebra. Folgende Schritte führen zur korrekten Anfrage: 

1. Person P ersonennummer ✶ P erson.P ersonennummer Student 

2. σ Name.F irst=‘Alf ′ ∧Name.F am=‘Brummkopf ′ (Person P ersonennummer ✶ P erson.P ersonennummer Student)


3. (σ Name.F irst=‘Alf ′ ∧Name.F am=‘Brummkopf ′ (Person)) P ersonennummer ✶ P erson.P ersonennummer Student 

4. π Hauptfach.F achber.DName ((σ Name.F irst=‘Alf ′ ∧Name.F am=‘Brummkopf ′ 

(Person)) P ersonennummer ✶ P erson.P ersonennummer Student) 

5. π Hauptfach.F achber.DName ( 

(σ Name.F irst=‘Alf ′ ∧Name.F am=‘Brummkopf ′ (Person)) 

P ersonennummer ✶ P erson.P ersonennummer Student) 

6. π Hauptfach.F achber.DName ( 

(σ Name.F irst=‘Alf ′ ∧Name.F am=‘Brummkopf ′ ( 

π P ersonennummer,Name.F irst,Name.F am (Person)) 

P ersonennummer ✶ P erson.P ersonennummer π P erson.P ersonennummer,Hauptfach.F achbereich.DName Student) 

Anfragen werden in einer Anfragesprache Q = L S1 ,S 2 

formuliert, die über Schemata S i definiert ist. 

Das Schema S 1 wird Input-Schema genannt, das Schema S 2 Output-Schema. 

Gegeben seien weiterhin die Menge Inst Si aller Datenbanken über S i . 

Wir können die Berechnung von Anfragen als Relation auffassen: 

RS Q 1 ,S 2 

= { (q, D 1 , D 2 ) | q ∈ Q ∧ D 1 ∈ Inst S1 ∧ D 2 ∈ Inst S2 }. 

Eine Funktion f : Q × Inst S1 → P(Inst S2 ) realisiert eine Relation R Q S 1 ,S 2 

falls für jedes q ∈ Q und jede 

Datenbank D 1 ∈ Inst S1 gilt, daß 

(1) falls kein y ∈ R Q S 1 ,DS 2 

existiert mit (x, D 1 , y) ∈ R Q S 1 ,S 2 

dann f(x) = λ und 

(2) f(x) = y für (x, D 1 , y) ∈ R Q S 1 ,S 2 

mit y ≠ λ. 

Eine Realisierung muß demzufolge nicht die Menge aller möglichen Resultate berechnen, sondern mindestens eines, 

falls es existiert. 

Eine Anfrage q ist in einer Anfragesprache Q über einem Schema S formuliert und liefert für eine Datenbank D 

über S ein oder mehrere Resultate. 

Demzufolge ist eine Anfrageanforderung eine spezifische Suchrelation definierbar: 

R Π = { (x, s) | x ∈ D Π ∧ s ∈ S Π (x) }. 

Eine Funktion f : Σ ∗ → Σ ∗ realisiert eine Relation R falls für jedes x ∈ Σ ∗ gilt, daß 

(1) falls kein y ∈ Σ + existiert mit (x, y) ∈ R dann f(x) = λ und 

(2) f(x) = y für (x, y) ∈ R mit y ≠ λ. 

Eine Anfrageanforderung besteht intentional aus zwei Komponenten: 

Suchkonzept: Ein Suchkonzept beschreibt die Suchanforderung. Wir haben dazu Anfrageformen eingeführt. 

Resultatkonzept: Ein Resultatkonzept beschreibt die Einbettung von Anfrageresultaten in ein Medienobjekt, das 

neben einem Tupelraum zur Aufnahme der Daten auch über eine eigenständige Repräsentation verfügt, sowie 

Strukturierungs- und Repräsentationsfunktionen. 

Die Forschung zur Datenbankanfrage-Unterstützung hat sogar eine allgemeinere Formulierung für Anfragen 

hervorgebracht, wie in Bild 1 illustriert. 

Der Zugang über Anfrage- und Antwortformen wird durch folgende Abbildungsvorschriften unterstützt: 

map : search concept ↦→ query form 

compile : (query form , database schema) ↦→ SQL query 

map : result concept ↦→ answer form 

process : SQL query ↦→ SQL answer set 

output : (SQL answer set , answer form) ↦→ answer to search 

Ziele einer Anfrageformulierung sind demzufolge:


Datenbank 

schema 

DBMS-Anfrageinterface 

Suchanforderung 

✿ 

Suchkonzept 

❄ 

3 Resultatkonzept 

✲ Antwortform 

✲ 

✛ 

✲ Anfrageform 

❄ 

SQLanfrage 

❄ 

SQL-Antwortmenge 

❄ ✮ 

Antwort 

auf Suche 

 

DBMS-Antwortrepräsentation 

Abbildung 1: Konzeptbasiertes Berechnen von Anfragen im klassischen Zugang und mit Anfrage- und Antwortformen 

Eingrenzung des Nichtdeterminismus: Jede Anfrage sollte so eindeutig wie nur möglich gestellt werden. 

Berechenbarkeit: Jede Anfrage sollte in eine Anfragevorschrift transformierbar sein, die ein Computer berechnen 

kann. 

Effektive Berechenbarkeit: Anfragen sollten auch in hinreichend kurzer Zeit bemessen am zu bewältigenden 

Datenumfang berechnet werden. 

Abbildung auf die Anfragesprache: Die Anfragen sollten in der zur Verfügung stehenden Anfragesprache formulierbar 

sein. 

Demzufolge ist die Formulierung einer Anfrage stets ein Vierschrittverfahren: 

1. Ergänzung der Anfrageäußerung zu einer genau formulierten Anfrage durch 

• Disambiguierung von Fragesätzen, 

• Ergänzung der Ellipsen zu vollständigen Sätzen, 

• Klärung, inwieweit eine Closed-World-Assumption oder eine partiell offene Datenwelt in der Datenbank 

unterlegt wird (Behandlung von Nullwerten) und 

• Schärfung der Formulierung von Aggregationsfunktionen; 

2. Reformulierung der Anfrage in eine existentiell geprägte Form wobei 

• nicht alle Generalisierungen aufgelöst werden müssen, sondern über ALL und ANY abgebildet werden 

können, und 

• ggf. auch besser überschaubare Boolesche Bedingungen erzeugt werden, indem z.B. die Negation 

möglichst weit zu den atomaren Formeln gezogen wird. 

3. Abbildung der Anfragebegriffe auf das Datenbank-Schema wobei ggf. 

• Spezifika der Schema-Definition mit beachtet werden wie z.B. 

• Nullwerte und Default-Werte, die eine Anfrageberechnung verändern können, und 

• referentielle Inklusionsabhängigkeiten, die zur Verkürzung der Anfragepfade mit herangezogen 

werden können, 

• auch Hilfstabellen temporär für die Anfrage gebildet werden oder Sichten als Tabellen für eine ‘Nebenrechnung’ 

bereitgestellt werden, sowie 

• eine Schrittfolge zur Berechnung der Resultate durch eine Prozedur bereitgestellt wird. 

4. Abbildung der Resultatskonzepte auf Antwortformen und Repräsentation dieser in SQL-Form.


2.2.3 Der generierende Kern der Relationenalgebra 

Da einige Operationen andere ausdrücken können (z.B. gilt M ∩ N = M \ (M \ N)), können wir die Relationenalgebra 

einschränken auf die folgenden Operationen 

Projektion 

Umbenennung 

Verbund 

Vereinigung 

Differenz 

Selection 

Lemma 4 Der Theta-Verbund ist ausdrückbar durch Selektion und Verbund. 

R Aj Θ Bk R ′ = σ Aj ΘB k 

(R × R ′ ) 

Proposition 1 Alle Operationen der Relationenalgebra sind ausdrückbar durch Ausdrücke über Relationennamen 

und den Operationen Projektion, Umbenennung, Verbund, Selektion, Vereinigung und Differenz. 

Corollary 1 Alle Operationen der Relationenalgebra sind ausdrückbar durch Ausdrücke über Relationennamen 

und den Operationen Projektion, Umbenennung, kartesisches Produkt, Selektion, Vereinigung und Differenz. 

2.2.4 Sichten 

Relationale Sicht wird definiert durch Relationenschema V der Sicht (meist wird außerdem angenommen Σ V = 

∅) und einer Anfrage über einem relationalen Datenbankschema 

Relationale Sichtensuite wird definiert durch ein Datenbankschema mit relationalen Sichten 

Probleme: 

Modifikation der Grunddatenbank durch Sichten (Sichten-Update-Problem) [Bei Nichtidentifizierbarkeit von 

Objekten der Grunddatenbank durch eine Sicht, ist ein Modifikation der Datenbank verboten. Dieses Problem 

kann gelöst werden durch separate Modifikationssichten neben den Retrievalsichten, die durch Hilfssichten 

miteinander und mit der Grunddatenbank gekoppelt werden.] 

Virtualisierung oder Materialisierung von Sichten ohne oder mit Kollaborationsvertrag 

2.2.5 Eine bessere mathematische Grundlage der relationalen Algebra 

Der folgende Teil zeigt, daß auch die Väter des relationalen Modelles nicht allzu viel von Mathematik verstanden 

und deshalb auch die falsche Welt erfunden haben. Erstaunlich ist, wie überlebensfähig die unmathematischen 

Denkweisen sind und wie gut trotzdem die Technologien geworden sind. 

“Die Vater” und nicht der ‘Vater’, weil nicht die Arbeit 

E. F. Codd A Relational Model of Data for Large Shared Data Banks. Commun. ACM., 13 (6): pp. 377-387, 1970 

sondern die (Codd durchaus sehr gut bekannte) Arbeit 

D. L. Childs, Feasibility of a set-theoretical data structure - a general structure based on a reconstituted definition of relation. Proc. IFIP Cong., North Holland Pub. Co., Amsterdam, pp. 162-172., 1968 

das relationale Modell eingeführt hat. 

Zylindrische Algebren (Henkin 1985) R C ∨ S C , ∼ R C , R C [X] = π X (R C ), D i,j (R C ) = σ i=j (R C ) 

Explizite Mitführung des Headers R einer Relation R C (wie wir dies bereits für die Operationen vorn betrachtet 

haben) erlaubt die Einführung folgender Operationen und Prädikate


• Projektion: wie üblich 

• Teiltyp: (R, R C ) ⊑ (S, S C ) falls R ⊇ S und π S (R C ) ⊆ S C 

• dem natürlichen Verbund ⊗ als “meet”-Operation oder infimum-Operation mit 

(R, R C ) ⊗ (S, S C ) := (R ∪ S, R C ✶ S C ) 

• der inneren Summe ⊕ als “join”-Operation als supremum-Operation 

(R, R C ) ⊕ (S, S C ) := (R ∩ S, π R∩S (R C ) ∪ π R∩S (S C )) 

Die Operationen ⊗ und ⊕ sind idempotent, kommutative und assoziativ. Sie erfüllen auch das Adsorptionsgesetz 

R C ⊗ (R C ⊕ S C ) = R C 

R C ⊕ (R C ⊗ S C ) = R C . 

Die Teiltyprelation führt direkt auf einen (nicht-distributiven, modularen) relationalen Verband 

• mit einem maximalen Element ⊤ := (∅, ∅) 

• dem minimalen Element ⊥ := (U, ∅) 

• ⊗ und ⊕ sind die infimum- und supremum-Operationen des Verbandes für die partielle Ordnung 

• partiellen Distributivitätsgesetzen, bei denen die Übereinstimmung der header gefordert werden muß 

(R, R C ) ⊗ ((S, S C ) ⊕ (T, T C )) = ((R, R C ) ⊗ (S, S C )) ⊕ ((R, R C ) ⊗ (T, T C )) 

mit der Einschränkung R ∩ S = R ∩ T 

(R, R C ) ⊕ ((S, S C ) ⊗ (T, T C )) = ((R, R C ) ⊕ (S, S C )) ⊗ ((R, R C ) ⊕ (T, T C )) 

mit der Einschränkung R ∩ S = R ∩ T = S ∩ T 

Führt man explizit auch die Zylinderalgebra-Operationen 

• die Diagonale D A,B = {(a, b) ∈ Dom(A) × Dom(B)|a = b} und 

• die Entleeruung (R, R C ) ∅ := (R, ∅) 

mit ein, dann kann man alle Operationen der relationalen Algebra ausdrücken: 

• Selektion σ A=B (R C ) durch (R, R C ) ⊗ D A,B 

• Projektion π X (R C ) durch (R, R C ) ⊕ (X, ∅) 

• Join durch ⊗ 

• Umbenennung ρ A↦→B (R C ) durch ((R, R C ) ⊗ D A,B ) ⊕ (R \ {A} ∪ {B}, ∅) 

• Vereinigung direkt für gleiche header 

2.3 Der relationale Kalkül / Relationenkalkül / Tupelkalkül 

2.3.1 Der Relationenkalkül 

Relationenalgebra und Relationenkalkül 

zwei verschiedene Anfragesprachen 

relationale Anfragesprache: formale Sprache L, die für jeden Ausdruck angewandt auf eine Relation wiederum 

eine Relation liefert 

i.a. endliche Relation 

2 Arten 

Relationenalgebra natürlicher Verbund, Vereinigung, Selektion, Projektion, Vergleich, Komplement 

Relationenkalkül Sprache der Prädikatenlogik


Ausdrücke der relationalen Algebra definiert über 

• R i ∈ L Al 

type(R i ) = R i 

• T ✶ T ′ ∈ L Al type(T ✶ T ′ ) = type(T ) ∪ type(T ′ ) 

• T + T ′ ∈ L Al type(T ✶ T ′ ) = type(T ) ∪ type(T ′ ) 

• π η (T ) ∈ L Al type(η) = T ′ , type(π η (T )) = T ′ 

• σ A=B (T ) ∈ L Al type(σ A=B ) = type(T ) 

• σ A≠B (T ) ∈ L Al type(σ A=B (T )) = type(T ) 

• γ(T ) = D T DD \ T ∈ L Al type(γ(T )) = type(T ) 

Diese Sprache ist nicht sicher, falls man die Endlichkeit von Relationen voraussetzt. 

Analog läßt sich eine sichere Algebra aufbauen: 

• Selektionsausdrücke 

• Join, Projektion, Umbennenung, (Vereinigung,) Differenz 

Semantik beider Sprachen in der üblichen Art definiert 

Definition der Auswertungsfunktion eval 

siehe Semantik von PS 

Eigenschaften 

1. Jede Anfrage der relationalen Algebra ist eine Anfrage im Sinne der obigen Definition. 

2. Die sichere Algebra ist nicht isomorphietreu (σ A=c ). 

3. Die transitive Hülle ist mit keiner von beiden Algebren berechenbar. 

R = {A, B}, (R C ) ∗ = {(a, b)|∃a 1 , ..., a k : (a, a 1 ), (a 1 , a 2 ), ...(a k−1 , a k ), (a k , b) ∈ R C } 

Beweis über die Nichtexistenz eines Ausdruck, mit dem (R C ) ∗ berechnet werden kann. Ausdrückbar ist: es 

gibt einen Weg der fixierten Länge n. 

Mit logischen Modellen aussdrückbar. 

4. Eine Anfrage e(db) ist in L Al genau dann definierbar, wenn sie invariant geüber allen Automorphismen 

vondb ist. 

Relationenkalkül 3 (Attributkalkül (Variable Attributen zuordnet (tupelwertige Kalüle sind analog)) 

• P Ri (v i,1 , ..., v i,ni ), v i,j Variable vom Typ A j für R i = {A 1 , ..., A ni } und Ordnung über R i 

kurz: R i (v i,1 , ..., v i,ni ) 

• α ◦ β, ◦ ∈ {∨, ∧} 

• ¬α 

3 Der Tupelkalkül ist eine der Verirrungen der Datenbankforschung. Man hat brute-force den Prädikatenkalkül genutzt. Leider wurde 

dabei übersehen, daß endliche Mengen andere Kalküle erfordern und sich dann extensiv bemüht mit vielen Begriffen, die Anfangsfehler 

algorithmisch oder zumindest begrifflich für die Konstruktionen auszumerzen. Ein anderes solches Beispiel ist auch die Definition des Begriffes 

“dependency”, die heute kaum noch jemand so nutzt, sondern nur für die speziellen Klassen. 

Diese Situation ist typisch für viele Entwicklungen in der Informatik: Erst unglücklich anstellen bei der Definition und dann Generationen 

von Forschern verbraten mit der Reparatur. Brute-force-Entwicklungen ohne Verständnis des Gegenstandes führen meist zu Verirrungen 

und aufwendigen Reparaturmaßnahmen. XML wiederholt gerade diese Geschichte. Gestartet als extrem einfaches und wundervolles Austauschformat 

und dort extrem nützlich und nun mittlerweile als volle Programmier- und Darstellungssprache mit einem Wirrwarr, das man 

kaum übertreffen kann. 

Frei nach H. Thiele: Definitionen sind Glücksache. Und Glück haben nur wenige.


• ∃v α, 

∀v α 

Der Relationenkalkül kann elegant eingeführt werden in Verallgemeinerung von Atzeni/Ceri/Paraboschi/Torlone 

als Tripel 

{target structure | context | conditions} 

Damit kann man z.B. auch XML-Abhängigkeiten elegant formulieren, wie Link und Hartmann zeigten. Ursprünglich 

verwendeten Atzeni/Ceri/Paraboschi/Torlone das Tripel 

{target structure | C | conditions} 

für den Bereich (range) [context] C. 

Diese Struktur ist elegant direkt mit SQL verbindbar sowie auch der relationalen Algebra . 

Der “algebraische” Relationenkalkül ist besser einführbar nach Thalheim (Teubner 1991) durch: 

{t | R | 1} for each relation schema R 

{t | C | β} 

{t | C | β ∧ α} 

{t 1 | C 1 | α 1 } , {t 2 | C 2 | α 2 } 

{t 1 ✶ t 2 | C 1 ∪ C 2 | α 1 ∧ α 2 } 

{t | C | α 1 } , {t | C | α 2 } 

{t | C | α 1 ∨ α 2 } 

{t | C | α 1 } , {t | C | α 2 } 

{t | C | α 1 ∧ ¬α 2 } 

{t | C | α} 

{ρ(t) | C | α} 

{t | C | α} 

{π X (t) | C | α} 

2.3.2 Syntax des relationalen Tupelkalküls 

4 

for selection σ α 

for join ✶ 

for union ∪ 

for set difference \ 

for renaming ρ 

for projection π X 

Der relationale Tupelkalkül (engl. tuple relational calculus, TRC) ist eine Anfragesprache für relationale Datenbanken, 

die Ausdrücke der Prädikatenlogik erster Stufe benutzt, um das gewünschte Ergebnis einer Anfrage zu 

beschreiben. Eine mögliche Anfrage an das Vorlesungs- und Studentenbeispiel aus dem Übungsskript zur relationalen 

Algebra könnte z.B. sein: 

Gib die Namen und Matrikelnummern der Studenten, die eine Vorlesung hören, die von einem Dozenten namens 

Meyer gehalten wird. 

Wer die relationale Algebra benutzt, muß eine Operationsfolge angeben, die das Ergebnis aus den Relationen 

der Datenbank konstruiert. Die Anfrage ist aber eigentlich anders formuliert: die gesuchten Studenten werden durch 

die sie charakterisierenden Eigenschaften beschrieben, nämlich die Eigenschaft, daß sie bestimmte Vorlesungen 

hören. Diese Vorlesungen sind dadurch charakterisiert, daß sie von einem bestimmten Dozenten (mit dem Namen 

Meyer) gehalten werden. Der TRC versucht, diese Charakterisierung auf einem formalen Wege durchzuführen. 

Sei ein Datenbankschema D gegeben. Wir definieren eine Menge von Variablen. In den folgenden Ausführungen 

werden wir Variablen mit kleinen lateinischen Buchstaben schreiben. Die Variablen stellen Platzhalter für 

4 Dieser Teil des Skriptum wurde von G. Fiedler (mein Dank dafür) erstellt. 

Wir empfehlen trotz der obigen Bemerkung das Studium des Tupelkalkül, weil die in der Datenbanktechnologie übliche Mengenverarbeitung 

dem in der sequentiellen Programmierung erprobten Informatiker etwas ungebräuchlich ist. Meist fällt dem Anfänger eine Anfrageformulierung 

mit dem TRC leichter, man sollte aber über die Probleme und die schwierige Behandlung sich im Klaren sein.


Tupel dar. Jeder Variablen ist ein Typ zugeordnet: seien A 1 , ..., A n die Attribute über denen die Tupel, die der 

Variable später zugeordnet werden sollen, definiert sind. Dann ist die Menge {A 1 , ..., A n } der Typ der Variable. 

Den Typ einer Variablen, z.B. der Variablen x, bezeichnen wir mit type(x). 

In unserem Beispiel suchen wir z.B. die Namen und die Matrikelnummern der Studenten. Deshalb können wir 

z.B. einen Typ type(x) = {MatrikelNr, Name} einführen. Die Variable x ist jetzt Platzhalter für Tupel über 

MatrikelNr und Name. 

Eine Anfrage des TRC ist eine prädikatenlogische Formel (erster Stufe) der folgenden Form: 

• Wenn R ein Relationenschema in D und x eine Variable mit type(x) = attr(R) ist, dann ist R(x) eine 

Formel im Sinne des TRC mit x als freier Variablen. 

Beispiele: 

ST UDENT (y) mit type(y) = {MatrikelNr, Name, W ohnort} 

RAUM(z) mit type(z) = {RaumNr, Bezeichnung} 

• Wenn x und y Variablen, A ∈ type(x) und B ∈ type(y) Attribute und ⊙ ein Prädikat über den Typen von 

A und B ist, dann ist x.A ⊙ y.B eine Formel im Sinne des TRC mit den freien Variablen x und y. Analog 

wird der Vergleich mit Konstanten definiert. 

Beispiele: 

y.W ohnort = ′ Kiel ′ 

x.Name = y.Name 

• Wenn ϕ und ψ Formeln im Sinne des TRC sind, dann sind auch die aussagenlogischen Verknüpfungen von 

ϕ und ψ Formeln im Sinne des TRC. Die freien Variablen entsprechen denen der Formeln ϕ und ψ. 

Beispiele: 

y.W ohnort = ′ Kiel ′ ∧ x.Name = y.Name 

x.Name = ′ P etersen ′ =⇒ y.Name = ′ Schmidt ′ 

• Wenn ϕ eine Formel im Sinne des TRC und x eine freie Variable in ϕ ist, dann sind auch 

(∀x)(ϕ) 

(∃x)(ϕ) 

Formeln des TRC. Die freien Variablen dieser Formeln entsprechen den freien Variablen von ϕ ohne x. 

Beispiel: 

(∀v)(V ORLESUNG(v) =⇒ (∃f)(F INDET ST AT T (f) ∧ f.V orlesungsNr = v.V orlesungsNr)) 

Erste Semantikdefinition des TRC. 

Im Übungsskript “Grundlagen der Logik” wurde der Begriff des Modells für eine Formel ϕ der Prädikatenlogik 

erster Stufe eingeführt. Wir gehen in dieser Diskussion von gegebenen Wertebereichen und einer festen (und 

trivialen) Belegung der Konstantensymbole aus, deshalb sind wir an Paaren I, ϱ interessiert, die unsere Formel ϕ 

wahr werden lassen. 

Die Interpretation I ordnet den Prädikaten eine Ausprägung zu, also die Menge von Tupeln, für die das Prädikat 

zu wahr ausgewertet wird. Im TRC betrachten wir 2 verschiedene Arten von Prädikaten: 

1. R(x) für ein Relationenschema R,


2. ⊙, definiert auf Ebene der Datentypen. 

Es liegt nahe, die Ausprägung der Prädikate der ersten Art an die Relationen unserer Datenbank zu binden. 

Für die Prädikate der zweiten Art benutzen wir die Definitionen der Prädikate in den Datentypen. Da wir diese 

Definition als konstant ansehen, werden wir in der weiteren Diskussion nur noch die Prädikate der ersten Art 

betrachten. 

Als Interpretation benutzen wir demnach einen ( ” 

den aktuellen“) Zustand σ(D) zu unserem Datenbankschema 

D. Als Ergebnis einer TRC-Anfrage bezeichnen wir die Menge der Variablenbelegungen ϱ, so daß 

σ(D), ϱ |= ϕ 

Da i.d.R. nicht die Belegungen aller Variablen interessant sind, wird pro Antwort auf die Anfrage ϕ nur die 

Belegung der freien Variablen in ϕ angegeben. Um auch dies weiter einzuschränken, kann man vor die Formel 

ϕ eine Projektionsliste mit den gewünschten Attributen schreiben. Seien x 1 , ..., x k die freien Variablen in ϕ und 

A 1 , ..., A l Attribute in den Typen von x 1 , ..., x k , dann kann man schreiben: 

x 1 .A 1 , ..., x i .A j 

Diese Schreibweise konstruiert Tupel über {A 1 , ..., A j } als Ergebnis der Anfrage. 

Beispiel: ” 

Gib die Namen und Matrikelnummern aller Kieler Studenten zusammen mit den Veranstaltungsnummern, 

so daß dieser Student diese Veranstaltung mindestens in der ersten Wiederholung hört.“ 

s.Name, s.MatrikelNr, h.V orlesungsNr | ST UDENT (s) ∧ HOERT (h)∧ 

h.MatrikelNr = s.MatrikelNr ∧ h.W iederholung ≥ 1 

Wenn die Menge der freien Variablen der Formel ϕ leer ist (d.h. alle Variablen in ϕ sind an Quantoren gebunden), 

dann ist die Antwort entweder ja (d.h. σ(D) |= ϕ) oder nein (d.h. σ(D) ϕ). 

Selbststudium Führen Sie sich anhand der folgenden Semantikdefinition vor Augen, daß die Variablenbelegung 

ϱ in diesem Falle für die Erfüllbarkeit keine Rolle spielt. Führen Sie sich weiterhin vor Augen, daß die Projektion 

auf die gewünschten Attribute nur syntaktischer Zucker“ ist. 

” 

Nachdem wir festgelegt haben, welche Attribute als Antwort auf die Anfrage auszugeben sind, können wir eine 

erste Semantikdefinition des TRC angeben. Sei ϱ eine Variablenbelegung: 

1. Sei R ein Relationenschema und x eine Variable, dann gilt σ(D), ϱ |= R(x) gdw. ϱ(x) ∈ σ(R), d.h. das 

Tupel, mit dem x belegt ist, ist in der zu R gehörenden Relation enthalten. 

2. σ(D), ϱ |= x.A ⊙ y.B gdw. ⊙(ϱ(x)(A), ϱ(y)(B)), d.h. wir betrachten die Tupel, mit denen die Variablen 

x und y belegt sind. Wenn das Prädikat ⊙ auf die Werte der Attribute A und B dieser Tupel angewendet 

wird, muß es wahr ergeben, damit der Datenbankzustand und die Variablenbelegung ein Modell bilden. 

Vergleiche mit Konstanten werden analog behandelt. 

3. σ(D), ϱ |= ϕ ∧ ψ für zwei Formeln ϕ und ψ gdw. σ(D), ϱ |= ϕ und σ(D), ϱ |= ψ. Die anderen aussagenlogischen 

Verknüpfungen werden analog behandelt. 

4. σ(D), ϱ |= (∃x)(ϕ), gdw. es eine Variablenbelegung ϱ ′ gibt, so daß sich ϱ ′ von ϱ höchstens in der Belegung 

von x unterscheidet und σ(D), ϱ ′ |= ϕ gilt. 

5. σ(D), ϱ |= (∀x)(ϕ), gdw. für alle Variablenbelegungen ϱ ′ , die sich von ϱ höchstens in der Belegung von x 

unterscheiden, gilt, daß σ(D), ϱ ′ |= ϕ. 

| ϕ 

Auswertung einer Anfrage. 

Es sei der folgende Zustand gegeben (es sind nur die relevanten Relationen angegeben):


STUDENT 

MatrikelNr Name Wohnort 

190245 Max Müller Kiel 

327641 Tina Petersen Flensburg 

612491 Tobias Schulze Kiel 

762198 Uwe Schmidt Rendsburg 

VORLESUNG 

VorlesungsNr 

Bezeichnung 

080104 SysInf IV 

080016 Info IV 

080127 Info II 

080176 SysInf II 

HOERT 

MatrikelNr VorlesungsNr Wiederholung 

190245 080104 0 

190245 080016 0 

327641 080127 0 

327641 080176 0 

612491 080104 0 

612491 080016 0 

612491 080127 1 

612491 080176 1 

762198 080104 2 

Betrachten wir obige Anfrage 

s.Name, s.MatrikelNr, h.V orlesungsNr | ST UDENT (s) ∧ HOERT (h)∧ 

h.MatrikelNr = s.MatrikelNr ∧ h.W iederholung ≥ 1 

Wir müssen nun für alle beliebigen Variablenbelegungen prüfen, ob der Datenbankzustand und die Belegung 

ein Modell der Anfrage bilden. Die möglichen Variablenbelegungen ergeben sich aus den Wertebereichen der 

Attribute: 

type(s) = {MatrikelNr, Name, W ohnort} 

type(h) = {MatrikelNr, V orlesungsNr, W iederholung} 

Die Belegungen der Variablen s bestehen demnach aus allen Kombinationen möglicher Matrikelnummern, Namen 

und Wohnorte. Wenn wir davon ausgehen, daß alle drei Attribute über dem Datentyp ” 

Zeichenkette“ definiert 

sind, müssen wir alle Kombinationen aus drei beliebigen und beliebig langen Zeichenketten betrachten. Damit 

ergeben sich z.B. folgende Belegungen:


ρ(s) MatrikelNr Name Wohnort 

000000 a a 

000001 a a 

000002 a a 

... ... ... 

190245 Max Müller Kiel 

190245 Max Müller Lübeck 

190245 Max Müller Flensburg 

... ... ... 

327641 Tina Petersen Flensburg 

327641 Max Müller Flensburg 

327641 Max Müller aW349(3! 

... ... ... 

zsafhgsadz HTjhsbva,! OiEwiuq43D 

... ... ... 

Es ist leicht ersichtlich, daß es unendlich viele Kombinationen dreier (beliebig langer) Zeichenketten gibt. Eine 

analoge Diskussion kann für die Belegung der Variablen h erfolgen. Durch scharfes Hinsehen“ 5 stellen wir aber 

” 

fest, daß für alle Belegungen, die s kein Tupel aus der Relation ST UDENT zuweisen, die gesamte Formel niemals 

erfüllt werden kann. Analog wird die Formel nur erfüllt, wenn der Variablen h ein Tupel aus der Relation HOERT 

zugeordnet wird. Die letzten beiden Bedingungen schränken dies weiter ein: es werden alle Kombinationen aus s 

und h verworfen, die die beiden Vergleiche nicht erfüllen. Es bleiben die folgenden Belegungen übrig: 

s 

ϱ 1 



ϱ 2 



ϱ 3 


762198 Uwe Schmidt Rendsburg 

h 


612491 080127 1 


612491 080176 1 


762198 080104 2 

Diese projizieren wir auf die gegebenen Attribute und erhalten unsere Antwort: 

Name MatrikelNr VorlesungsNr 

Tobias Schulze 612491 080127 

Tobias Schulze 612491 080176 

Uwe Schmidt 762198 080104 

Betrachten wir weiterhin folgende Anfrage (type(x) = attr(V ORLESUNG)): 

¬V ORLESUNG(x) 

Auch hier müssen wir alle Tupel betrachten, die sich aus zwei beliebig langen Zeichenketten (VorlesungsNr und 

Bezeichnung) bilden lassen. Durch ” 

scharfes Hinsehen“ stellen wir fest, daß sich die vier im Zustand der Datenbank 

aufgeschriebenen Tupel nicht für die Antwort qualifizieren. Jede andere Kombination aus einer Zeichenkette für die 

Vorlesungsnummer und die Bezeichnung — auch alle unsinnigen Kombinationen — sind Teil der Antwortmenge. 

Da es unendlich viele solche Kombinationen gibt, dauert es unendlich lange, bis die Antwort berechnet ist. Mit 

anderen Worten ausgedrückt: unser Algorithmus terminiert nicht, das Ergebnis der Anfrage ist nicht berechenbar. 

Ausdrücke dieser Form nennen wir in Zukunft ” 

unsichere Ausdrücke“ (da man sich, vereinfacht gesprochen, nicht 

sicher sein kann, ein Ergebnis zu erhalten.) Ausdrücke, die stets eine endliche Menge von Ergebnistupeln liefern, 

nennen wir ” 

sichere Ausdrücke“. ” 

Stets“ bedeutet in diesem Zusammenhang, daß die Endlichkeit des Ergebnisses 

für alle gültigen Datenbankzustände garantiert ist. 

Sicherheit und Wertebereichsunabhängigkeit. 

5 Systematischere Verfahren lernen Sie in der Veranstaltung ” 

Datenbanktheorie“ oder in der Logikprogrammierung kennen.


Die Menge der sicheren TRC-Ausdrücke ist unentscheidbar, d.h. es gibt keinen Algorithmus, der für einen 

beliebigen gegebenen TRC-Ausdruck bestimmt, ob dieser sicher oder unsicher ist. Aus diesem Grunde betrachtet 

man eine weitere Eigenschaft: die Wertebereichsabhängigkeit bzw. -unabhängigkeit eines TRC-Ausdrucks. 

Das Problem der unsicheren TRC-Ausdrücke liegt in der Tatsache begründet, daß über einem unendlichen 

Wertebereich gearbeitet wird und sich prinzipiell jedes Tupel dieser unendlichen Menge für das Ergebnis qualifizieren 

kann. Unsinnige Wertekombinationen in Tupeln der Antwort (z.B. die Vorlesungsbezeichnung lhiGf!r5W ) 

interessieren uns aber eigentlich nicht. Deshalb können wir untersuchen, was passiert, wenn wir nicht mehr alle 

beliebigen Belegungen unserer Variablen betrachten, sondern nur noch die Belegungen, deren (Attribut-)Werte auf 

irgendeine Art und Weise im Datenbankzustand oder in der Anfrage vorkommen, die wir also als ” 

sinnvoll“ erachten. 

Wenn eine Anfrage jetzt eine andere Antwort liefert als im vorher diskutierten Fall, dann hängt das Ergebnis 

nicht nur vom Datenbankzustand ab, sondern von den Werten der Wertebereiche der Attribute. In diesem Fall sprechen 

wir von einem wertebereichsabhängigen TRC-Ausdruck. Wenn sich das Ergebnis nicht verändert, dann ist der 

TRC-Ausdruck wertebereichsunabhängig. Die erste Anfrage im Abschnitt 2.3.2 ist eine wertebereichsunabhängige 

Anfrage: Egal welche Wertebereiche wir betrachten 6 , die Anfrage liefert bzgl. eines fest gewählten Datenbankzustands 

immer die gleiche Antwort. Die zweite Anfrage (¬V ORLESUNG(x)) ist wertebereichsabhängig, denn 

z.B. je nach den möglichen Vorlesungsbezeichnungen entsteht jedesmal eine andere Antwort. 

Es gilt: Jeder wertebereichsunabhängige TRC-Ausdruck ist sicher. Die Umkehrung muß nicht zwangsläufig 

gelten 7 . Leider ist die Menge der wertebereichsunabhängigen Ausdrücke immer noch unentscheidbar. Um eine 

Entscheidbarkeit zu erzwingen, werden die vom System zugelassenen Anfragen syntaktisch eingeschränkt, d.h. 

wir erlauben nicht mehr beliebige Anfragen des TRC. Dies führt uns zur Definition der erlaubten Ausdrücke. 

Erlaubter TRC-Ausdruck In einem erlaubten TRC-Ausdruck wird jede Variable an den Datenbankzustand gebunden“. 

Um dies festzustellen, prüfen wir für jedes Attribut A jeder Variablen x, ob das Paar (x, A) in einem ” 

Ausdruck ϕ positiv oder negativ beschränkt ist: 

1. (x, A) ist positiv beschränkt in R(x) 

2. Sei c eine Konstante. Dann ist (x, A) positiv beschränkt in x.A = c und c = x.A. Wir setzen die übliche 

Definition des Gleichheitsprädikats voraus. 

3. (x, A) ist positiv beschränkt in x.A = y.B bzw. y.B = x.A, wenn der Term Teil einer Konjunktion ist 

(F 1 ∧ ... ∧ x.A = y.B ∧ ... ∧ F n ), in der y.B positiv beschränkt ist. 

4. (x, A) ist positiv beschränkt in ¬ϕ, wenn (x, A) negativ beschränkt ist in ϕ. 

5. (x, A) ist positiv beschränkt in ϕ ∧ ψ, falls (x, A) positiv beschränkt ist in ϕ oder in ψ. 

6. (x, A) ist positiv beschränkt in ϕ ∨ ψ, falls (x, A) positiv beschränkt ist in ϕ und in ψ. 

7. (x, A) ist positiv beschränkt in ϕ =⇒ ψ, falls (x, A) negativ beschränkt ist in ϕ und positiv beschränkt in 

ψ. 

8. (x, A) ist positiv beschränkt in (∃y)(ϕ) oder in (∀y)(ϕ), falls (x, A) positiv beschränkt ist in ϕ. 

9. (x, A) ist negativ beschränkt in ¬ϕ, falls (x, A) positiv beschränkt ist in ϕ. 

10. (x, A) ist negativ beschränkt in ϕ ∧ ψ, falls (x, A) negativ beschränkt ist in ϕ und in ψ. 

11. (x, A) ist negativ beschränkt in ϕ ∨ ψ, falls (x, A) negativ beschränkt ist in ϕ oder in ψ. 

12. (x, A) ist negativ beschränkt in ϕ =⇒ ψ, falls (x, A) positiv beschränkt ist in ϕ oder negativ beschränkt in 

ψ. 

6 Die Werte des Datenbankzustands müssen natürlich in den Wertebereichen enthalten sein, sonst widerspricht dies unseren Definitionen 

des relationalen Modells! 

7 Wenn man z.B. nur endliche Wertebereiche betrachtet, dann ist jeder Ausdruck sicher. Er kann aber sehr wohl wertebereichsabhängig 

sein.


13. (x, A) ist negativ beschränkt in (∃y)(ϕ) oder in (∀y)(ϕ), falls (x, A) negativ beschränkt ist in ϕ. 

Eine Variable x ist positiv (negativ) beschränkt in einem Ausdruck ϕ, falls die positive (negative) Beschränkung 

für alle Attribute dieser Variablen gilt. 

Ein TRC-Ausdruck ϕ heißt erlaubt, wenn folgendes gilt: 

1. Jede freie Variable in ϕ ist positiv beschränkt. 

2. Für jeden Teilausdruck (∃x)(ψ) ist die Variable x positiv beschränkt in ψ. 

3. Für jeden Teilausdruck (∀x)(ψ) ist die Variable x negativ beschränkt in ψ. 

Jeder erlaubte Ausdruck ist wertebereichsunabhängig und demnach sicher. Damit läßt sich ein Algorithmus 

angeben, der überprüft, ob ein gegebener Ausdruck wertebereichsunabhängig ist: 

1. Ist der Ausdruck nach obiger Definition erlaubt? Wenn ja: der Ausdruck ist wertebereichsunabhängig. 

2. Sonst: Läßt sich ein Gegenbeispiel angeben? Man konstruiert sich ein Universum, daß genau die Konstanten 

aus dem Datenbankzustand und der Anfrage enthält und führt die Anfrage aus. Anschließend fügt man weitere 

Werte zum Universum hinzu und führt die Anfrage erneut aus. Wenn sich unterschiedliche Ergebnisse 

erzeugen lassen, ist die Anfrage wertebereichsabhängig. 

3. Falls kein Gegenbeispiel gefunden wurde: läßt sich die Formel umstellen (De Morgansche Gesetze, Quantorumformung, 

etc.)? Falls ja, gehe zu 1. 

4. Falls nicht: keine Entscheidung möglich. 

Bereichsbeschränkte TRC-Ausdrücke. 

Es gibt eine weitere Möglichkeit, nur sichere und wertebereichsunabhängige Ausdrücke zu formulieren: Variablen 

müssen strikt an Relationenschemata gebunden werden: 

• freie Variablen stehen in einem Term der Form R(x) 

• Quantifizierte Variablen werden nur mit Tupeln aus einer Relation belegt: 

(∃x ∈ R)(ϕ) 

(∀x ∈ R)(ϕ) 

TRC-Ausdrücke dieser Form heißen beschränkte Ausdrücke bzw. R-beschränkte Ausdrücke. Bei R-beschränkten 

Ausdrücken ist eine Projektion auf Attribute in der Zielliste nicht länger syntaktischer Zucker. Beispiele sind: 

Welche Studenten hören welche Vorlesung?“ 

” 

s.MatrikelNr, h.V orlesungsNr | ST UDENT (s) ∧ HOERT (h) ∧ h.MatrikelNr = s.MatrikelNr 

Welche Studenten hören alle Vorlesungen?“ 

” 

s.Name | 

ST UDENT (s) ∧ (∀v ∈ V ORLESUNG)( 

(∃h ∈ HOERT )(h.MatrikelNr = s.MatrikelNr ∧ h.V orlesungsNr = v.V orlesungsNr) 

)


Integritätsbedingung: ” 

Jeder Student hört mindestens zwei verschiedene Vorlesungen.“ 

(∀s ∈ ST UDENT )( 

(∃h1 ∈ HOERT )( 

(∃h2 ∈ HOERT )( 

h1.MatrikelNr = s.MatrikelNr ∧ h2.MatrikelNr = s.MatrikelNr∧ 

¬(h1.V orlesungsNr = h2.V orlesungsNr) 

))) 

Gib die Namen und Matrikelnummern der Studenten, die eine Vorlesung hören, die von einem Dozenten namens 

Meyer gehalten wird. 

s.Name, s.MatrikelNr | 

ST UDENT (s) ∧ (∃h ∈ HOERT )(h.MatrikelNr = s.MatrikelNr∧ 

(∃d ∈ DOZENT )(d.V orlesungsNr = h.V orlesungsNr∧ 

(∃m ∈ MIT ARBEIT ER)( 

m.BearbeiterNr = d.BearbeiterNr ∧ m.P ersonalNr = d.P ersonalNr∧ 

m.Name = ′ Meyer ′ 

))) 

2.3.3 Vergleich von Relationenkalkül und Relationenalgebra 

Proposition 2 Der algebraische Relationenkalkül und der bereichsbeschränkte Tupelkalkül und die relationale 

Algebra haben die gleiche Ausdruckskraft, d.h. 

∀db∀db ′ (∃α ∈ L Kal : eval(α(db)) = db ′ ⇔ ∃e ∈ L Al : eval(e(db)) = db ′ . 

Beweis durch Nachrechnen. 

Damit: Mengenorientierte, deklarative Semantik des Relationenkalküls kann durch Relationenalgebra korrekt und 

vollständig operationalisiert werden. 

Damit allgemeiner Zugang für die Bewertung von Datenmodellen gerechtfertigt: Die operationale Fixpunktsemantik ist gleich der deklarativen Semantik. 

2.3.4 Erweiterung der Relationenalgebra und des Relationenkalküls 

Aggregationsoperationen mit einem Zweistufenverfahren: 

Eine Aggregationsoperation ist definiert als Familie F = {f 0 , ...., f k , ..., f ω } mit Funktionen f k : Bag k → 

Num , die Multimengen mit k Elementen vom Typ T auf einen numerischen Datentyp Num abbilden. Wir 

lassen nur solche Typen zu, die ein minimales und ein maximales Element in dom(T ) besitzen. Es müssen 

zwei Eigenschaften bezüglich der Ordnung auf dom(T ) erfüllt sein: 

• Es gelten die Gleichungen f k (min, ...., min) = min und f k (max, ..., max) = max für die minimalen 

und maximalen Elemente in dom(T ). 

• Die Funktionen sind monoton bzgl. der Ordnung von dom(T ). 

Da Nullwerte explizit zugelassen sind, benutzen wir zwei Hilfsfunktionen für die strukturelle Rekursion: 

{ 

h 0 0 falls s = NULL 

f (s) = f(s) falls s ≠ NULL 

h undef 

f (s) = 

{ undef falls s = NULL 

f(s) falls s ≠ NULL . 

Wir können nun die folgenden üblichen Aggregationsfunktionen einführen: 

Summierung in unterschiedlichen Varianten abhängig von der Behandlung von Nullwerten:


• Summierung für Klassen ohne Nullwerte: 

sum = srec 0,Id,+ ; 

• Summierung für Klassen mit Nullwerten, die durch die 0 ersetzt werden: 

sum null 

0 = srec 0,h 0 

Id ,+ ; 

• Summierung für Klassen mit Nullwerten, die durch die undef ersetzt werden: 

sum null 

undef = srec 0,h undef 

Id ,+ . 

Üblich ist die Anwendung der zweiten Option. 

Zählen der Objekte je nach Behandlung der Nullwerte: 

• Für Klassen ohne Nullwerte: count = srec 0,1,+ ; 

• Für Klassen mit Nullwerten: count null 

1 = srec 0,h 0 

1 ,+ ; 

• Alternativ für Klassen mit Nullwerten: count null 

undef = srec 0,h undef 

1 ,+ . 

Genutzt wird oft die zweite Option. 

Bildung der maximalen bzw. minimalen Werte in Abhängigkeit von den Ordnungen für NULL: 

• Die leere Menge erlaubt keine Bestimmung von minimalen bzw. maximalen Werten: 

• max NULL = srec NULL,Id,max bzw. min NULL = srec NULL,Id,min 

• max undef = srec undef,Id,max bzw. min undef = srec undef,Id,min 

Diese Funktionen hängen davon ab, wie die Nullwerte in dom(T ) eingeordnet werden. 

Bildung des Durchschnittes: Die Durchschnittsbildung ist eine komplexere Funktion. Es gibt dafür eine 

Reihe von Möglichkeiten: 

(++) 

sum 

count 

(SQL!?) sumnull 0 

count 

(+?!) sumnull undef 

count 

(??) 

(+!) 

sum 

count null 

1 

sum null 

0 

count null 

1 

(??) sumnull undef 

count null 

1 

(??) 

(??) 

(++) 

sum 

count null 

undef 

sum null 

0 

count null 

undef 

sum null 

undef 

count null 

undef 

SQL benutzt eine Variante, die nicht die intuitivste ist. Wir präferieren in der HERM-Algebra die 

mit “+” annotierten Varianten für den Fall von Klassen mit Nullwerten. Die Funktionen avg null 

0 ,1 und 

avg null 

undef werden dabei der SQL-Form avgnull vorgezogen. 

Ordnungsoperationen je nach Basis-Datentypen und benutztem Konstruktor (Tupel, Menge) 

Abgeleitete Elementaroperationen sind die Modifikationsoperationen der Datenbanksysteme: 

Einfügen von Elementen: Die insert-Operation Insert(R C , o) ist durch die Vereinigung R C ∪{o} von 

Mengen für Klassen R C und Objekte o vom gleichen Typ R beschreibbar. 

Streichen von Elementen: Die delete-Operation Delete(R C , o) ist durch die Differenz R C \ {o} von 

Mengen für Klassen R C und Objekte o vom gleichen Typ R definierbar. Analog kann man auch das 

Streichen von Mengen delete(R C , R C′ ) einführen. 

Update von Elementen: Die Modifikation Update(R C , α, γ) von Klassen R C ist für Prädikate α und 

Ersetzungsfamilien γ = {(o, R Co )} ist definiert durch die 

⋃ 

Menge 

R C \ σ α (R C ) ∪ R Co . 

o∈σ α(R C ) 

Eine oft verwendete Definition basiert auf dem Ausdruck R C \ σ α (R C ) ∪ R C′ . Damit wird jedoch ein 

anderer Effekt erzielt. Gilt z.B. σ α (R C ) = ∅ und R C′ ≠ ∅, dann wird die ursprüngliche Intention verloren. 

Dieser Einführung liegt jedoch die oft praktizierte Ersetzung von Update(R C , o, {o ′ }) durch 

die Folge Delete(R C , o); InsertUpdate(R C , o ′ ) zugrunde.


Eine Ersetzungsfamilie γ = {(o, R Co )} vom Typ R ist eine Menge bestehend aus einem Paar von Objekten 

und Klassen vom Typ R. Eine Ersetzungsfamilie beschreibt für Objekte vom Typ R jeweils eine Klasse von 

Objekten, durch die dieses Objekt ersetzt wird. 

Weitere Operationen erlauben die Einführung verschachtelter bzw. komplexer Typen (außerhalb der ersten 

Normalform): 

Schachtelung: Es sei R ′ ein Element von R. Dann wird die Schachtelung ν R ′(R C ) von R C entlang von R ′ 

definiert als Klasse über dem Typ T = (R \ R ′ ) ⊔ R {R ′ } mit der Menge von Objekten 

{ o ∈ Dom(T ) | ∃o ′ ∈ R C : o[R \ R R ′ ] = o ′ [R \ R R ′ ] 

∧ o(R ′ ) = { o ′′ [R ′ ] | o ′′ ∈ R C ∧ o ′ [R \ R X] = t ′′ [R \ R R ′ ]}}. 

Entschachtelung: Es sei R ′ ein Mengenelement von R. Die Entschachtelung µ ′ R (RC ) einer Klasse definiert einen 

neuen Typen T = (R \ R {R ′ }) ◦ R ′ für die Konkatenation ◦ und die neue Klasse 

{ o ∈ Dom(T ) | ∃o ′ ∈ R C : o[R \ R {R ′ }] = o ′ [R \ R {R ′ }] ∧ o[X] ∈ o ′ (X)}. 

Potenzmenge: Die Potenzmenge P(R C ) = {M|M ⊆ R C } ist eine geschachtelte Klasse über dem Typ {R} . 

Im allgemeinen können Objekte und Strukturen mit folgenden Konstruktoren konstruiert werden: 

Tupelkonstruktor bzw. kartesisches Produkt 

Mengenkonstruktor 

Listenkonstruktor 

Vereinigungskonstruktor 

Multimengenkonstruktor 

... 

Relationale Datenbanken sind definiert durch Anwendungen eines Listen- auf einen Mengenkonstruktor, der wiederum 

auf einen Tupelkonstruktor angewandt wird. 

Mit den Konstruktoren sind definiert durch folgenden Definitionsrahmen: 

• mit Selektoren für retrieval (z.B. Select) und update-Funktionen (z.B. Insert, Delete, und Update) ür die 

Abbildung von Werten des neuen Typen auf die Komponententypen, 

• mit einem Korrektheitskriterium und Regeln zur Kontrolle der Korrektheit, 

• mit default-Werten 

• mit (ggf. mehreren Repräsentationstypen, und 

• mit (ggf. mehreren) Implementationstypen oder Eigenschaften der Implementationstypen. 

2.3.5 Beispiel zum Relationenkalkül/Tupelkalkül 

Angestellter(Nummer, Name, Gehalt, Abteilung, Geburtsjahr, Einstellungsdatum) 

Abteilung(Nummer, Name, Filiale, Stock, Leiter) 

Filiale(Nummer, Stadt, Land) 

Lieferant(Nummer, Name, Stadt, Land) 

Artikel(Nummer, Name, Abteilung, Preis, Bestand, Lieferant) 

Verkauf(Nummer, Datum, Abteilung, Artikel, Anzahl, Angestellter, Betrag) 

Anfragen:


• Namen aller Angestellten mit einem Gehalt von weniger als 400 Euro 

{ t.Name | Angestellter(t) ∧ t.Gehalt < 400 } 

• Namen und Preise aller Artikel, die von einem Lieferanten aus Schleswig-Holstein geliefert werden 

{ t.Name,t.Preis | Artikel(t) ∧ ∃ l (Lieferant(l) ∧ t.Lieferant = l.Nummer ∧ l.Land = ’SH’) } 

• Namen und Bestände aller Filialen in Berlin 

{ t.Name,t.Bestand | Artikel(t) ∧ ∃ f ( Filiale(f) ∧ f.Stadt = ’Berlin’ ∧ 

∃ v ∃ a (Verkauf(v) ∧ Abteilung(a) v.Abteilung = a.Nummer 

∧ a.Filiale = f.Nummer ∧ v.Artikel = a.Nummer)) } 

• Namen und Nummern aller Artikel, die teurer als 1.000 Euro sind und deren Bestand mindestens 500 Exemplare 

beträgt 

{ t.Name,t.Nummer | Artikel(t) ∧ t.Preis > 1.000 ∧ t.Bestand ≥ 500 } 

• Namen aller Abteilungen, Namen ihrer Leiter und ihre Gehälter, wobei Abteilungsleiter Angestellte sind 

{ t.Name,t.Abteilung, t.Gehalt | Angestellter(t) ∧ ∃ a (Abteilung(a) ∧ a.Leiter = t.Nummer) } 

• Alle Artikel, die in einer Abteilung verkauft wurden, deren Leiter ”Helmut K. Raffke” ist, die er aber nicht 

selbst verkauft hat 

{ t | Artikel(t) ∧ ∃ v ∃ a ∃ e1 ∃ e2 (Verkauf(v) ∧ Abteilung(a) 

∧ Angestellter(e1) ∧ Angestellter(e2) 

∧ t.Nummer = v.Artikel ∧ v.Abteilung = a.Nummer 

∧ a.Leiter = e.Nummer ∧ e.Name = ’Helmut K. Raffke’ 

∧ v.Angestellter = e2.Nummer ∧ e2.Nummer ≠ e1.Nummer ) } 

2.4 Einführung in SQL 

Paradigmen 

formale Sprache \ Theorie Abstraktion Entwurf 

erfinden 

verwirklichen 

• 

benutzen 

• 

2.4.1 SQL 

SQL - tupelorientierter Relationenkalkül mit einigen algebraischen Elementen, angereichert durch arithmetische 

und textverarbeitende Elemente 

2.4.2 Vorbemerkung 

Erinnerung: Normalform von Ausdrücken der (einfachen) relationalen Algebra (erzeugt über Selektion, Projektion, 

Verbund, Differenz, Umbenennung ohne Vereinigung) 

• Kernausdruck: ρ γ (π X (σ α (R 1 ✶ ... ✶ R n ))) 

• Induktiver Aufbau: anstelle von R i jeder Ausdruck 

Vereinigung kann nachgeschoben werden, falls Typenäquivalenz nachweisbar 

Dreischrittverfahren aufgrund Kalkülteils 

1. Tupelerzeugung FROM 

• Semantik: Erzeugung aller Tupel t 1 ∈ R 1 , ..., t k ∈ R k


• Syntax: Bindung der Tupelvariablen t 1 an das Relationensymbol R 1 , ... t k an das Relationensymbol R k 

2. Auswahl der gesuchten Tupel WHERE 

• Semantik: Auswahl aller Tupelkombinationen, die eine Formel erfüllen 

• Syntax: Setzen der Tupelvariablen mit entsprechend passenden Attributen und Vergleichen 

3. Projektion SELECT (sinnvoller Projekt) 

• Semantik: Auswahl der Komponenten in entsprechender Kombination 

• Syntax: µ i,1 .A 1 , ..., µ i,m .A m 

Beispiel: 

PERSON = ({Name, Adresse, PNum}, {Pnum}, ∅ ) 

STUDENT = ({PNum, SNum, Hauptf, Nebenf, Betreuer }, {SNum} , { {PNum} −→ {SNum} } ) 

PROFESSOR = ({ PNum, Spezialis }, { PNum }, ∅ ) 

VORLES = ({ Kurs, Raum, Zeit, Semester, Lesender.PNum }, { Raum, Zeit, Semester }, ... ) 

TEILNAHME = ({ Kurs, Semester, Lesender.PNum, SNum, Note }, { SNum, Kurs, Semester }, ... ) 

Darstellung durch Hypergraph 

PERSON 

Name 

Adresse 

PNum 

Spezialis 

PROFESSOR 

SNum 

Hauptf 

Nebenf 

Betreuer 

STUDENT 

Kurs 

Semester 

Note 

TEILNAHME 

Zeit 

Raum 

VORLES 

2.4.3 SQL-Schema-Definition 

Datendefinition in SQL 

DBSchemaDef := CREATE SCHEMA [ SchemaName ] 

[ AUTHORIZATION BenutzerName ] 

[ DEFAULT CHARACTER SET character-set ] 

[ ListeTabDef ] 

ListeTabDef := TabDef { TabDef } 

TabDef := CREATE TABLE Name ( AttrDefinitionListe


TabIntegritBedingListe ) ; 

AttrDefinitionsListe := AttrDefinition { , AttrDefinition } 

AttrDefinition := AttributName Datentyp | Domain 

[ DefaultDefinition ] 

[ IntegritBedingungListe ] 

Datentypen: NATIONAL CHAR[ACTER] [VARYING], VARCHAR, INT[EGER], SMALLINT, 

NUMERIC, DEC[IMAL], FLOAT, REAL, DOUBLE PRECISION, BIT, BIT VARYING 

DATE, TIME, TIMESTAMP, TIME WITH TIME ZONE, TIMESTAMP WITH TIME ZONE 

INTERVAL 

IntegritBedingungListe := [ PRIMARY KEY | UNIQUE ] (AttrListe) | 

FOREIGN KEY (AttrListe) 

REFERENCES TabName [ ( AttrListe) ] 

[ MATCH FULL | MATCH PARTIAL ] 

[ ON DELETE 

NO ACTION | CASCADE | 

SET DEFAULT | SET NULL ] 

[ ON UPDATE 

NO ACTION | CASCADE | 

SET DEFAULT | SET NULL ] 

[ CHECK Klausel ] 

[ ASSERTION Bedingung ] 

Unique - Schlüssel 

Weiterhin noch möglich: CREATE TEMPORARY TABLE 

CREATE SCHEMA UniEinfach AUTHORIZATION Rektor ( 

CREATE TABLE PERSON ( Name VARCHAR(15) NOT NULL , 

Adresse VARCHAR(30), 

PNum INTEGER, 

PRIMARY KEY (PNum)); 

CREATE TABLE STUDENT ( PNum INTEGER NOT NULL , 

SNum INTEGER NOT NULL, 

Hauptf CHAR(3) NOT NULL, 

Nebenf CHAR(3), 

Betreuer VARCHAR(15), 

PRIMARY KEY (SNum) 

FOREIGN KEY (PNum) REFERENCES PERSON ); 

CREATE TABLE PROFESSOR ( PNum INTEGER NOT NULL , 

Spezialis CHAR(10), 

PRIMARY KEY (PNum) 

FOREIGN KEY (PNum) REFERENCES PERSON ); 

CREATE TABLE VORLES ( Kurs VARCHAR(20) NOT NULL , 

Raum CHAR(5), 

Zeit CHAR(3), 

Semester CHAR(5) NOT NULL, 

Lesender.PNum INTEGER NOT NULL, 

PRIMARY KEY (Raum, Zeit, Semester) 

FOREIGN KEY (Lesender.PNum) REFERENCES PROFESSOR ); 

CREATE TABLE TEILNAHME ( Kurs VARCHAR(20) NOT NULL , 

Semester CHAR(5) NOT NULL, 

LesenderPNum INTEGER NOT NULL,


DROP TABLE TEILNAHME 

ALTER TABLE VORLES ADD SNum INTEGER 

SNum INTEGER, 

Note DEC(2,1), 

PRIMARY KEY (SNum, Kurs, Semester), 

FOREIGN KEY (SNum) REFERENCES STUDENT , 

NOT NULL 

ein Student muß existieren 

ON DELETE RESTRICT 

Nichtentfernen des 

ON UPDATE CASCADE ) 

) 

letzten Student 

Sichtendefinition in SQL über Anfragesprache 

als VIRTUELLE Tabelle 

CREATE VIEW SUPERSTUDIOSI (Name, Fach, Lehrer) 

AS SELECT x.Name, y.Kurs, z.Name 

FROM PERSON x, TEILNAHME y, PERSON z, STUDENT, PROFESSOR 

WHERE STUDENT.PNum = x.PNum AND y.SNum = STUDENT.SNum 

AND y.LesenderPNum = PROFESSOR.PNum AND PROFESSOR.PNum = z.PNum 

AND y.Note = 1.0 

GROUP BY x.Name 

DROP VIEW SUPERSTUDIOSI 

Vorsicht mit updates über Sichten 

Indizes in SQL 

für effiziente Verarbeitung und Suche 

CREATE INDEX VORLES INDEX ON VORLES (Kurs, Semester, LesenderPNum) 

CREATE UNIQUE INDEX VORLES ZUGR INDEX 

ON VORLES (Raum, Zeit, Semester) 

2.4.4 SQL-Anfragen 

beachte Anfragen sind einfach Funktionen der Form: 

f : S × U → U 

mit Datenbank und Informationssystem-Umgebung (z.B. Anfrageinterface und Ergebnisinterface) 

wir unterschieden deshalb 

• Anfrageformen 

• Ergebnisformen 

Man hat deshalb immer einen Anfragetypen und einen Ergebnistypen. 

Aufgrund des Umformungssatzes gilt, daß jede Anfrage kanonisch dargestellt werden kann durch: 

algebraischer Ausdruck π Ri,1 .A 1 ,...,R i,m .A m 

(σ Φ (R 1 × ... × R k )) 

oder allgemeiner:


map π (filter Φ (map × (R 1 , ..., R k ))) 

entsprechender SQL-Ausdruck 

SELECT DISTINCT µ 1 .A 1 ,...,µ m .A m 

FROM R 1 µ 1 ... R k µ k 

WHERE Φ 

Vereinfachungen 

• Tupelvariable kann weggelassen und R i auch verwendet werden 

• Klammerung µ.A kann zu A vereinfacht werden 

• Falls keine echte Projektion: ∗ 

Bestimme für die Datenbankprofessoren ihre Vorlesungen. 

(σ Spezialis=‘Datenbanken ′(V ORLES × P ROF ESSOR)) 

SELECT DISTINCT ∗ 

FROM VORLES, PROFESSOR 

WHERE PROFESSOR.Spezialis = ‘Datenbanken’ 

AND PROFESSOR.PNum = VORLESUNG.PNum 

GROUP BY PROFESSOR.PNum 

Bestimme alle Namen von Professoren, die Datenbanken lesen. 

π P ERSON.Name (σ V ORLES.Kurs=‘Datenbanken ′ 

(P ERSON P Num ✶ P Num P ROF ESSOR P Num ✶ P Num V ORLES)) 

SELECT DISTINCT Name 

FROM PERSON, PROFESSOR, VORLES 

WHERE PERSON.PNum = PROFESSOR.PNum 

AND PERSON.PNum = VORLES.PNum 

AND VORLES.Kurs = ‘Datenbanken’ 

Bestimme alle Namen von Professoren, die selbst eine Vorlesung Datenbanken hörten und eine solche Vorlesung 

lesen. 


((V ORLES Lesender.P Num ✶ P Num P ROF ESSOR P Num ✶ P Num P ERSON 

P Num ✶ P Num ST UDENT ) SNum,Kurs ✶ SNum,Kurs )) 

σ V ORLES.Kurs=‘Datenbanken ′(T EILNAHME))) 

SELECT DISTINCT t.Name 

FROM PERSON y, PROFESSOR p , VORLES v, TEILNAHME t, STUDENT s 

WHERE y.PNum = p.PNum 

AND y.PNum = v.PNum 

AND v.Kurs = ‘Datenbanken’ 

AND t.SNum = s.SNum 

AND s.PNum = y.PNum 

AND t.Kurs = ‘Datenbanken’ 

Wird zusätzlich die Semantik benutzt (nur Studenten nehmen an Vorlesungen teil, nur Professoren lesen Vorlesungen), 

dann kann man die Anfrage vereinfachen: 


((V ORLES Lesender.P Num ✶ P Num P ERSON P Num ✶ P Num ST UDENT ) 

SNum,Kurs ✶ SNum,Kurs T EILNAHME)) 

SELECT DISTINCT t.Name 

FROM PERSON y, VORLES v, TEILNAHME t, STUDENT s


WHERE y.PNum = v.PNum 

AND v.Kurs = ‘Datenbanken’ 

AND t.SNum = s.SNum 

AND s.PNum = y.PNum 

AND t.Kurs = ‘Datenbanken’ 

SQL erlaubt außerdem auch Multimengen. Solche sind nicht im tupelorientierten Relationenkalkül darstellbar. 

Generiere eine Namensliste der Vorlesungsteilnehmer für die Vorlesung(en) ‘Datenbanken’ im Wintersemester 

2004. 

Unter Voraussetzen obiger Inklusionsbedingungen erhalten wir: 

SELECT PERSON.Name 

FROM PERSON, TEILNEHMER, STUDENT 

WHERE PERSON.PNum = STUDENT.PNum 

AND STUDENT.SNum = TEILNEHMER.SNum 

AND TEILNEHMER.Semester = ‘WS 2004/2005’ 

AND TEILNEHMER.Kurs = ‘Datenbanken’ 

Wie kann man alle Teilnehmer von der Vorlesung ‘Datenbanken’ erhalten ? 

Man generiere zuerst eine vereinigte Teilnehmerliste aller Datenbankvorlesungen und bestimme dann eine Teilnehmertabelle. 

SELECT PERSON.Name 

FROM PERSON , STUDENT 

WHERE PERSON.PNum = STUDENT.PNum 

AND SNum IN ( SELECT DISTINCT SNum 

FROM STUDENT, TEILNEHMER 

WHERE STUDENT.SNum = TEILNEHMER.SNum 

AND TEILNEHMER.Semester = ‘WS 2004/2005’ 

AND TEILNEHMER.Kurs = ‘Datenbanken’ ) 

Komplexere Anfragen bedürfen einer wohldurchdachten Umsetzung ! 

Man generiere die Namen aller Studenten, die alle Vorlesungen gehört haben, die Professor ‘Gerste’ gelesen hat. 

SELECT DICTINCT x.Name 

FROM PERSON x, STUDENT s 

WHERE x.PNum = S.PNum 

AND NOT EXISTS (SELECT * 

FROM PERSON y, VORLES z 

WHERE y.Name = ‘Gerste’ AND y.PNum = z.Lesender 


FROM TEILNAHME t 

WHERE y.PNum = t.Lesender 

AND t.Kurs = z.Kurs 

AND s.SNum = t.SNum ) ) 

All Mitarbeiter, die einen Kurs leiten, an der der Leiter ihres Institutes teilnimmt. 

SELECT m2.PersNr, m2.Name 

FROM Mitarbeiter m1, Mitarbeiter m2, Institut, Kurs, Kursteilnahme 

WHERE m2. Institut = Insitut.Bezeichnung AND Institut.PersNrLeiter = m1. PersNr AND 

Kursteilnahme.KursNr = Kurs.KursNr AND Kurs.Leitung = m2.PersNr; 

andere Version davon als geschachtelte Variante 

SELECT m2.PersNr, m2.Name


FROM Mitarbeiter m2 

WHERE m2.Institut IN 

(SELECT Bezeichnung 

FROM Institut i 

WHERE i.PersNrLeiter IN 

(SELECT PersNr 

FROM Kursteilnahme 

WHERE KursNr IN 

(SELECT KursNr 

FROM Kurs 

WHERE Leitung = m2.PersNr))); 

andere Varianten durch Auswertung von 2 Wegen über m1 zu Mitarbeiter m2 

Backus-Naur-Form einfacher SQL-Anfragen: { - beliebig oft (0..), 

[ - optional, | - choice, @ - rechtsassoziativer Operator 

einfache SQL-Anfrage := SELECT DISTINCT Attributtermliste 

FROM Variablenbindungsliste 

[ WHERE Formel ] 

[ GROUP BY Gruppierung ] 

[ HAVING Suchbedingung ] 

[ ORDER BY Gruppierung ] 

Attributtermliste := ∗ | AttributTerm [ { , AttributTerm } ] 

Attributterm := [ Tupelvariable . | Relationensymbol . ] Attribut 

Variablenbindungsliste := Relationensymbol [ Tupelvariable ] 

[ { , Variablenbindungsliste } ] 

FORMEL := Atomformel | NOT Formel | ( Formel ) 

Formel AND Formel | 

Formel OR Formel 

Atomformel := Term Vergleichsprädikat Term 

Term := Attributterm | Konstantenzeichen 

Vergleichsprädikat := = | ̸= 

Gruppierung := Attributterm { , Attributterm } 

Suchbedingung 

Algebraischer Teil 

SQL-Anfrage := einfache SQL-Anfrage | Mengenop SQL-Anfrage 

Mengenop := INTERSECT | UNION | MINUS 

Multimengen-Teil 

ohne DISTINCT 

Genestete Anfragen 

im WHERE-Teil andere Anfrage 

gekoppelt über IN (Tupel Element der inneren Anfrage) 

EXISTS (eine Menge ist nicht leer) 

NOT EXISTS (eine Menge ist leer) 

gekoppelt über Variable 

Namen, Adresse aller Studenten ohne Fehlleistung 

SELECT Name, Adresse 

FROM PERSON , STUDENT 

WHERE PERSON.PNum = STUDENT.SNum


AND NOT EXISTS ( SELECT ∗ 

FROM TEILNAHME 

WHERE TEILNAHME.SNum = STUDENT.SNum 

AND TEILNAHME.Note = 5 

ORDER BY Name ) 

Dazu ist die folgende Anfrage äquivalent: 

SELECT Name, Adresse 

FROM PERSON 

WHERE PNum IN (SELECT PNum 

FROM STUDENT 

WHERE NOT EXISTS ( SELECT ∗ 


WHERE TEILNAHME.SNum = STUDENT.SNum 

AND TEILNAHME.Note = 5 ) ) 

Explizite Werteangabe 

Wie oft ist ein Student in ‘Datenbanken’ (fast) durchgefallen? 

SELECT COUNT(∗) 


WHERE TEILNAHME.Note IN (4,5) AND TEILNAHME.Kurs = ‘Datenbanken’ 

Geschachtelte Anfragen sind auch möglich in SELECT- und FROM-Teilen 

• geschachtelte Anfragen im SELECT-Teil 

Lehrbelastung aller Profs 

SELECT PersNr, Name, (SELECT sum(SWS) AS Lehrbelastung 

FROM Vorlesungen 

WHERE Dozent = PersNr) 

FROM Person 

• Anfrage kann auch mit FROM-Teil verbunden sein: (Marktanteil der Dozenten) 

SELECT t.KursNr, t.AnzahlProVorlesung, g.GesamtAnzahl 

h.AnzahlProVorlesung/g.GesamtAnzahl AS Marktanteil 

FROM (SELECT KursNr, COUNT(*) AS AnzahlProVorlesung 

FROM Teilnehmer 

GROUP BY KursNr) t, 

(SELECT COUNT(*) AS GesamtAnzahl 

FROM Student ) g; 

Geschachtelte Anfragen können mitunter einfach aufgelöst werden: 

• SELECT * 

FROM Student s 

WHERE EXISTS 

(SELECT p.* 

FROM Professor p 

WHERE p.Geburtsdatum > s.Geburtsdatum ); 

• SELECT * 

FROM Student s JOIN Person p1 ON p1.Name = s.Name AND p1.Geburtsdatum = s.Geburtsdatum 

WHERE s.Geburtsdatum < 

(SELECT max(p.Geburtsdatum)


FROM Professor p); 

Geschachtelte Anfragen können durch Umformungen aufgelöst werden: 

• SELECT m.* 

FROM Mitarbeiter m JOIN LeiterVon l ON m.PersNr = l.MitarbeiterPersNr 

WHERE EXISTS 

(SELECT p.* 

FROM Professor p 

WHERE l.Chef = m.PersNr AND p.Geburtsdatum < s.Geburtsdatum); 

• SELECT * 

FROM Mitarbeiter m JOIN LeiterVon l ON m.PersNr = l.MitarbeiterPersNr 

JOIN Professor p ON p.PersNr = l.Chef ; 

Aufgrund des Fehlens von ∀ und ⇒ in SQL muß eine Umformung vorgenommen werden, falls man derartige 

Aussagen braucht: 

alle Studenten, die alle vierstündigen Vorlesungen hören 

SELECT s.* 

FROM Student s 

WHERE s.Hautfach = “Informatik” AND 

NOT EXISTS 

(SELECT * 

FROM Vorlesung v 

WHERE v.SWS = 4 AND NOT EXISTS 

(SELECT * 

FROM Teilnahme t 

WHERE t.KursNr = v.KursNr AND t.MatrNr = s.MatrNr)); 

Kommerzielle Systeme können dies mitunter schwer auflösen 

COUNT-Trick 

alle Studenten, die alle Vorlesungen hören 

SELECT s.* 

FROM Student s JOIN Teilnahme t ON s.MatrNr = t.MatrNr 

WHERE s.Hautfach = “Informatik” 

GROUP BY s.MatrNr SELECT s.* 

HAVING COUNT(*) = 

(SELECT COUNT(*) FROM Vorlesung JOIN Professor ON Vorlesung.Dozent = Professor.PersNr 

WHERE Professor.In = “Institut für Informatik”); 

Arithmetischer Teil 

Aggregatfunktionen: AVG, SUM, MAX, MIN, COUNT 

4 Grundrechenarten 

arithmetische Vergleichsoperationen 

Wie oft ist ein Student in ‘Datenbanken’ durchgefallen? 

SELECT COUNT(∗) 


WHERE TEILNAHME.Note = 5 AND TEILNAHME.Kurs = ‘Datenbanken’


Was ist die Durchschnittnote in ‘Datenbanken’ ? Wieviele Teilnehmer hatte dieser Kurs insgesamt ? 

SELECT AVG(Note), COUNT(∗) 


WHERE TEILNAHME.Note = 5 AND TEILNAHME.Kurs = ‘Datenbanken’ 

Textverarbeitender Teil 

Konstantenzeichen sind nichtatomare Zeichenfolgen, die man bzgl. Vorkommen von Teilworten testen, konkatenieren 

usw. kann 

LIKE 

Update-Operationen 

INSERT INTO PERSON VALUES (‘Gerste’, ‘Zentrum’, 0815) 

auch mit Tabellen 

INSERT INTO TEILNAHME SELECT x.Kurs, x.Semester, x.PNum,, y.SNum, z.Note 

FROM VORLESUNG x, STUDENT y, TEILNAHME t, 

PERSON, TEILNAHME z 

WHERE x.Kurs LIKE ‘%Geschichte%’ AND PERSON.PNum = y.PNum 

AND PERSON.Name LIKE ‘B% AND z.SNum = y.SNum 


FROM TEILNAHME w 

WHERE w.SNum = z.SNum AND w.Note < z.Note 

(alle Studenten mit B*-Namen haben die ‘Geschichte’-Kurse zu besuchen, erhalten dann gleich ihre beste Note) 

(manchmal statt Buchstaben) 

DELETE FROM PROFESSOR WHERE Spezialis LIKE ‘%Geschichte%’ 

UPDATE VORLES 

SET Raum = ‘HG133’ 

WHERE Raum = ‘HG 130’ AND Zeit = ‘Mo2’ AND Semester = ‘WS94’ 

2.4.5 Erweiterungen 

Embedded SQL 

eingebettet in eine Hostsprache 

Zugriffsrechte 

siehe Abschnitt 4.1. der Vorlesung 

definiert über GRANT 

Direktdefinition der Operationen 

in SQL2 

Projektion 

SELECT DISTINCT ... FROM R 

Selektion 

SELECT * FROM R WHERE Φ


Vereinigung 

SELECT DISTINCT ... ... UNION SELECT DISTINCT ... 

Differenz 

SELECT DISTINCT * FROM R EXCEPT SELECT DISTINCT * FROM S 

Verbund 

SELECT * FROM R NATURAL JOIN S 

Kartesisches Produkt 

SELECT * FROM R CROSS JOIN S 

Theta-Verbund 

SELECT * FROM R JOIN S ON R.B = S.C 

Outer Join (äußerer Verbund) 

SELECT * FROM R LEFT OUTER JOIN S ON .. 

hängende Tupel von R um Nullwerte ergänzt über S 

analog RIGHT OUTER JOIN 

und FULL OUTER JOIN 

Nullwerte-Auswertung in SQL 

• in arithmetischen Ausdrücken propagiert (NULL führt zu NULL) 

• SQL nutzt einfache dreiwertige Logik mit UNKNOWN als Rückgabewert bei NULL 

• logische Operatoren AND, NOT, OR als mittleren Wert 

• in WHERE-Bedingung nur solche Tupel weitergereicht, die zu ‘true’ ausgwertet werden 

• beim Gruppieren ist NULL eine eigene Gruppe 

es wird aufgrund der SQL-Auswertung: nur zu ‘true’-ausgewertete Bedingungen werden weiter ausgewertet 

dann ggf. nur zu “Mit Sicherheit bekannt, daß ... ” ausgewertet 

Beispiel: 

• äquivalente Anfragen: 

• SELECT P.Name 

FROM Person P 

WHERE NOT EXISTS 

(SELECT * 

FROM FamousPeople F 

WHERE F.Geburtsdatum = P. Geburtsdatum); 


FROM Person P 

WHERE P.Geburtsdatum NOT IN 

(SELECT Geburtsdatum 

FROM FamousPeople F); 

• nicht äquivalent sind dagegen für z.B. den Fall, daß alle Geburtstage der in Kiel geborenen in FamousPeople 

fehlen:



FROM Person P 

WHERE NOT EXISTS 

(SELECT * 


WHERE F.Geburtsdatum = P. Geburtsdatum AND 

F. Geburtsort = “Kiel”); 

wird ausgewertet zu allen Tupeln in Person 

weil F.Geburtsdatum = NULL 

demzufolge nicht true sondern unknown 

deshalb is NOT EXISTS (∅) stets wahr 


FROM Person P 

WHERE P.Geburtsdatum NOT IN 

(SELECT Geburtsdatum 


WHERE F. Geburtsort = “Kiel”); 

nur unbekannte Geburtstage, demzufolge keine Antworttupel 

Darstellung der Rekursion in SQL 

ORACLE-Variante 

SELECT KursTitel 

FROM Kurs 

WHERE KursNr IN (SELECT Vorgänger 

FROM Voraussetzung 

CONNECT BY Nachfolger = PRIOR Vorgänger 

START WITH Nachfolger = (SELECT KursNr 

FROM Kurs 

WHERE KursTitel = ‘Datenbanksysteme I’)); 

DB2-Variante 

WITH TransHülle (Vorg, Nachf) 

AS (SELECT Vorgänger, Nachfolger FROM Voraussetzung 

UNION ALL 

SELECT t.Vorg, v.Nachfolger 

FROM TransHülle t, Voraussetzung v 

WHERE t.Nachf = v.Vorgänger) 

SELECT KursTitel 

FROM Kurs 

WHERE KursNr IN 

(SELECT Vorg FROM TransHülle WHERE Nachf IN 

(SELECT KursNr 

FROM Kurs 

WHERE KursTitel = ‘Datenbanksysteme I’)); 

SQL-Entwicklung im Überblick als Diagramm 2:


Rekursion 

Komplexe Datentypen, SQL/PSM, SQL/CLI, SQL/MED, 

SQL/OLB, SQL/Schemata, SQL/JRT, SQL/XML 

Strukturelle Objektoptimierung 

Abstrakte Datentypen 

SQL-Funktionen, prozedurale Elemente 

Neue Funktionen: RECURSIVE JOIN, 

JOIN USING FOREIGN KEY 

Trigger, Sicherungspunkte 

Call-level-Interface 

Schnittstellendefinition für dynamisches 

SQL über C-Funktionsaufrufe 

CREATE ASSERTION 

SET CONSTRAINT 

Rollender Cursor 

FETCH PRIOR, FETCH RELATIVE 

Verbindungsaufbau 

zwischen Client/Server 

OUTER JOIN, UNION JOIN 

UNION EXCEPT, INTERSECT 

Domains, Schemamanipulat. (ALTER) 

Referentielle Aktionen 

Dynamisches SQL 

Erweit. d. Hostsprachen 

(ADA, C) 

Erweit. Fehlermeld. 

SQL-Einbett. in 

Hostsprachen 

(COBOL, PL/1) 

Erweit. Int.-beding. 

PRIMARY KEY, FOREIGN KEY, CHECK 

Datendefintion 

Datenmanipulation 

ANSI 

SQL/89 

Level 2 

Embedded 

SQL 

X/Open 

SAG 

CLI 

SQL/92 

Full 

level 

SQL/92 

Intermediate 

level 

SQL/92 

Entry 

Level 

SQL 4 

als 

SQL:2003 

SQL 3 

als 

SQL:1999 

ANSI 

ANSI 

SQL 

SQL/89 

Level 1 

1986 1989 1989 1991 1992 1995/99 2000/03 

Abbildung 2: Die Entwicklung von SQL und Funktionalität


2.4.6 QBE 

entwickelt von IBM Yorktown Heights für Büroautomation 

werteorientierter Relationenkalkül ohne viel Logikvoraussetzungen 

Konzepte 

Tabellengerüst jede Relation durch Tabelle darstellbar 

Beispiele Werte für σ 

Variable alle nicht durch “P” gebundenen Variablen sind mit der Semantik ∃ definiert 

Operatoren P (rint), I (nsert), D (elete), U (pdate) 

Verbindung über Variable 

Zeilen einer Tabelle als ∨ interpretiert; evt. auch mit ¬ 

Ergebnis: alle Tupel, die auf Bedingungen passen 

Vergleichsoperatoren über Variable 

Generiere eine Namensliste der Vorlesungsteilnehmer für die Vorlesung(en) ‘Datenbanken’ im Wintersemester 

2004. 

PERSON Name Adresse PNum 

P.x 

y 

TEILNEHMER Kurs Semester Lesender.PNum SNum Note 

‘Datenbanken’ ‘WS 2004/2005’ z 

STUDENT PNum SNum Hauptf Nebenf Betreuer 

y z 

Namen, Adresse aller Studenten mit mindestens einmal ohne Fehlleistung 

PERSON Name Adresse PNum 

P. P. y 

TEILNEHMER Kurs Semester Lesender.PNum SNum Note 

¬ z 5 

STUDENT PNum SNum Hauptf Nebenf Betreuer 

y z 

weiterhin: Datenschemadefinition über leere Tabelle 

analog Sichtendefinition 

2.4.7 Visual SQL 

Datenbank-Programmierung ist für den Novizen und auch den Programmierer oft ein Buch mit sieben Siegeln, 

sobald die Programmieraufgabe etwas komplexer wird. Der Grund liegt auf der Hand: Es ist unmenschlich, eine 

oder auch mehrere Seiten Code zu lesen, diesen zu verstehen und auch in allen Facetten zu erfassen. Meist sind 

viele kleinere Nebenbedingungen mit zu erfassen bzw. im Auge zu behalten. Oft erschweren Unzulänglichkeiten 

von SQL auch die Formulierung. 

In diesem Teil des Skriptum wird eine andere Auffassung begründet, die sich mehr auf die Möglichkeiten der 

multimedialen Welt stützt und dem Benutzer durch eine graphische Gestaltung entgegen kommt. Es wird basierend 

auf dem ER-Modell ein andere Formulierung von komplexen SQL-Anfragen vorgenommen, die sich stark an das 

ER-Paradigma anlehnt.


SQL - Möglichkeiten und Grenzen. 

SQL ist wie jede lineare Sprache beschränkt überschaubar. Schemata sind wesentlich besser geeignet, um 

strukturelle Zusammenhänge einfach und zugleich konsistent zu beherrschen. Deshalb wird eine Sprache Visual 

SQL entwickelt, mit der die Datenbankprogrammierung visualisiert werden kann. 

SQL ist als Kompromiss entstanden. SQL hat als Sprache der vierten Generation viel aus den Fehlern anderer 

Programmiersprachen gelernt. Durch eine auf Kompromiss ausgerichtete Standardisierung sind allerdings auch 

‘features’ entstanden, die wenig durchdacht erscheinen und deren Anwendung auch eine gute Ausbildung und viel 

Praxiserfahrung erfordert. Die Vor- und Nachteile von relationalen Sprachen sind sehr gut in Heuer92 erläutert. 

Die Einschränkung auf relational vollständige Sprachen ist an der Einfachheit und relativen problemlosen Realisierbarkeit 

der relationalen Algebra orientiert. Zum anderen ist SQL eine Sprache, die weit über die Mächtigkeit 

der Prädikatenlogik der ersten Stufe hinausgeht. Damit ist bereits der gut ausgebildete Informatiker relativ einfach 

zu überfordern. Grund für diese ungerechtfertigte Mächtigkeit sind Aggregations- und Gruppierungsoperationen, 

denen eine wohldurchdachte Ausarbeitung nicht zugesprochen werden kann. Noch schlimmer sind Nullwerte, die 

mit amerikanischer Unbedarftheit eingeführt worden sind, die in der praktischen Benutzung stark mit unterschiedlichen 

Bedeutungen belastet werden und aufgrund der fehlenden Dokumentationserzwingung von SQL auch dann 

einen Benutzer zum Kunden des Orakels von Delphi werden lässt. Typisch für den letzteren Fall sind Unterscheidungen, 

die ein Benutzer zwischen NOT IN und NOT EXISTS vornehmen muss, sobald Nullwerte erlaubt 

sind. 

SQL ist bewusst so beschränkt worden, damit alle Algorithmen, die die Datenbankoperationen unterlegen, auch 

mit einer maximalen Komplexität von O(n log n) realisiert werden können. Dazu gehört auch die Nichtaufnahme 

einer Rekursion in SQL’92. 

Wie jeder Visualisierung ist auch Visual SQL eine Grenze gesetzt. Visualisierung ist nur dann sinnvoll, wenn 

sie überschaubar bleibt, d.h. auf ein Teilschema begrenzt, das sich auf einer Seite repräsentieren lässt. Visualisierung 

ist nutzlos für sehr grosse Zusammenhänge, ersetzt auch nicht das Nachdenken und Formulieren, sondern 

dient nur als Hilfestellung. Die undurchdachte Losung, dass durch ein Bild tausend Worte ersetzt werden, ist von 

Denkfaulen leicht akzeptiert, hält aber keiner genaueren Betrachtung stand. SQL und Programmierung erfordern 

eine Ausbildung und können weder in Jauch’schen Quiz-Shows noch in bebilderten Knoff-Hoff-Sendungen gelernt 

werden. 

Jede Gemeinschaft lebt von der Entwicklung, so auch die SQL-Programmierer- und -Anwender-Gemeinschaft. 

SQL wurde bereits in der Variante von SQL’92 mit Konstrukten versehen, die einer theoretischen Basis entbehren. 

So wird z.B. die Erzwingung von Integritätsbedingungen mit einer Vielzahl von Varianten unterstützt, die nicht 

ohne weiteres unterschieden werden und modelliert werden können. Es können Integritätsbedingungen vor der 

Ausführung von Anweisungen kontrolliert werden und so auch die Ausführung vollständig blockieren, solange 

die Datenbank sich in einem Zustand befindet, der inkonsistent zu den Bedingungen ist. Damit wird eine globale 

Semantik des Datenbankverhaltens unterstützt. Dies war sicherlich nicht die Intention von SQL’92. Die Isolationsmodi 

für Transaktionen sind ein anderes Beispiel. Da ein Programm auch die Kontrolle der Integritätsbedingungen 

mit steuern kann, werden auch dynamische Integritätsbedingungen unterstützt. 

Ein Problemkreis von SQL muss mit besonderer Vorsicht behandelt werden: SQL nutzt Multimengen (“bag”) 

und nicht nur Mengen. Demzufolge haben die relationalen Operationen andere Gesetzmässigkeiten als die SQL- 

Operationen. Damit werden auch Auswertungsoperationen anders spezifizierbar, kommutieren nicht und müssen 

auf andere Art programmiert werden. 

Ausführliche Darstellung von Visual SQL und Sourcen. 

siehe in den Materialien zur Vorlesung und vor allem zu den Übungen 

Literaturhinweis 

Bernhard Thalheim: Entity-Relationship Modeling, Foundations of Database Technology. Springer, 2000. ISBN 

3-540-65470-4


An die Teilnehmer der Veranstaltung wird der Verkauf des Buches zu einem ermäßigten Preis (80% bzw. weniger) durch das 

Sekretariat TIS organisiert. Bitte sprechen Sie persönlich bei Frau Kruse vor. 

Joachim Biskup: Grundlagen von Informationssystemen, Vieweg, 1995 

Das Skriptum zu Vorlesungen zu diesem Buch ist abgelegt unter: 

http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/biskup/Biskup.pdf 

Alfons Kemper, André Eickler: Datenbanksysteme - Eine Einführung, 5. Auflage. Oldenbourg 2003 

Die Skripte zur Vorlesung sind abgelegt unter: 

http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/kemper/kapitel1.pdf — kapitel 13.pdf 

Weitere Literaturquellen sind: 

• Ramesh Elmasri, Sham B. Navathe: Fundamentals of Database Systems (4nd Edition), Benjamin/Cummings, 

Redwood City etc., 2004 (auch in Deutsch) 

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

• Andreas Heuer, Gunter Saake: Datenbanken: Konzepte und Sprachen. Pearson 2000 

• Chris Date: An Introduction to Database Systems, 8th ed., Pearson, 2004. 

• A. Silberschatz, H. F. Korth, S. Sudarshan: Database System Concepts, McGraw-Hill, 2001.


Anhang 

8 

Logik in a nutshell 

Um eine unmißverständliche Anfrage an ein Datenbanksystem zu stellen, ist eine formale Definition der Anfragesprache 

notwendig. Diese Definition bestimmt, welche Anfragen als gültig betrachtet werden und welche Bedeutung 

(Semantik) diesen Anfragen zugeordnet ist. 

Wir behandeln hier zwei Ansätze formaler Sprachen für die Formulierung von Anfragen an Datenbanksysteme. 

Die relationale Algebra definiert eine Menge von möglichen Operationen über den Relationen einer Datenbank. 

Diese Operationen bilden die Relationen der Datenbank auf andere Relationen ab. Eine Anfrage der relationalen 

Algebra ist eine Folge von Anweisungen, die angibt, welche Operationen auf welche Relationen angewendet 

werden müssen, um das gewünschte Ergebnis zu erhalten. 

Der relationale Tupelkalkül geht einen anderen Weg: mit Hilfe einer Sprache werden die Eigenschaften des 

gewünschten Ergebnisses beschrieben. Das Datenbanksystem bestimmt aus den Relationen der Datenbank den 

Zustand, der diese Eigenschaften erfüllt. 

Beide Anfragesprachen benutzen die mathematischen Grundlagen der Logik. Deshalb beginnen wir in diesem 

Skript mit einer kurzen Einführung in die Begriffswelt der Logik. Dabei beschränken wir uns auf die Elemente, die 

für unsere Anfrageformulierung wichtig sind. 

Aussagenlogik 

Formeln, Interpretationen und Modelle 

Die Aussagenlogik stellt einen Rahmen für die Bestimmung der Wahrheitgehalts von Aussagen bzgl. einer gegebenen 

Welt bereit. Eine Aussage wird dabei aus Teilaussagen zusammengesetzt, die mittels Junktoren verbunden 

werden. Die Basis bilden strukturlose Elementaraussagen, die nicht weiter zerlegt werden können. 

Betrachten wir folgende Aussagen: 

A 1 : ” 

Es regnet.“ 

A 2 : ” 

Die Straße ist naß.“ 

Aus beiden (Elementar-)Außagen können weitere Aussagen zusammengesetzt werden: 

A 3 : ” 

Es regnet und die Straße ist naß.“ 

A 4 : ” 

Wenn es regnet, ist die Straße naß.“ 

A 5 : ” 

Die Straße ist nicht naß.“ 

A 6 : ” 

Wenn die Straße naß ist, regnet es.“ 

A 7 : ” 

Wenn es regnet, ist die Straße naß. Die Straße ist nicht naß. Es regnet nicht.“ 

A 8 : ” 

Die Straße ist genau dann naß, wenn es regnet.“ 

Das Verbinden von Teilaussagen zu komplexeren Aussagen geschieht mit Hilfe von Junktoren. Typische Junktoren 

sind ” 

und“ (∧), ” 

oder“ (∨), ” 

nicht“ (¬), die Implikation (⇒) und die Äquivalenz (⇔). Mit Hilfe dieser 

Symbole lassen sich die Aussagen A 3 bis A 8 z.B. wie folgt als Formeln schreiben: 

A 3 : A 1 ∧ A 2 

8 Dieser Anhang wurde von G. Fiedler erstellt.


A 4 : A 1 ⇒ A 2 

A 5 : ¬A 2 

A 6 : A 2 ⇒ A 1 

A 7 : (A 1 ⇒ A 2 ) ∧ (¬A 2 ) ∧ (¬A 1 ) 

A 8 : A 1 ⇔ A 2 

Bis jetzt ist eine Aussage nur ein syntaktischer Ausdruck, dem eine Bedeutung (Semantik) zugeordnet werden 

muß. Der Wahrheitswert einer Aussage bestimmt sich aus den Wahrheitswerten der Teilaussagen und der Verknüpfung 

dieser Wahrheitswerte durch den Junktor. Als Wahrheitswerte werden üblicherweise wahr“ (W ) und 

” 

falsch“ (F ) benutzt. Die Verknüpfungen können mit Hilfe von Wertetabellen dargestellt werden: 

” 

A ∧ B A ist falsch A ist wahr 

B ist falsch falsch falsch 

B ist wahr falsch wahr 

A ∨ B A ist falsch A ist wahr 

B ist falsch falsch wahr 

B ist wahr wahr wahr 

A ⇒ B A ist falsch A ist wahr 

B ist falsch wahr falsch 

B ist wahr wahr wahr 

A ⇔ B A ist falsch A ist wahr 

B ist falsch wahr falsch 

B ist wahr falsch wahr 

¬A A ist falsch A ist wahr 

wahr falsch 

Der Wahrheitswert einer Elementaraussage ergibt sich aus der betrachteten Welt. Nehmen wir folgende Situationen 

an: 

Situation 1 Situation 2 Situation 3 

A 1 ist wahr A 1 ist falsch A 1 ist falsch 

A 2 ist wahr A 2 ist wahr A 2 ist falsch 

In Situation 1 sind A 1 und A 2 beide wahr. Ein Blick in die Wertetabellen der Junktoren verrät, daß demnach 

auch A 3 , A 4 , A 6 und A 8 wahr sind. A 5 ist falsch. Für A 7 wenden wir die Verknüpfung über mehrere Stufen an: 

A 1 ⇒ A 2 ist nach Wertetabelle wahr und ¬A 2 ist falsch. Demnach ist (A 1 ⇒ A 2 ) ∧ (¬A 2 ) falsch. ¬A 1 ist ebenso 

falsch. Deshalb folgt, daß die Gesamtaussage A 7 falsch ist. 

A 3 A 4 A 5 A 6 A 7 A 8 

Situation 1 W W F W F W 

Situation 2 F W F F F F 

Situation 3 F W W W W W 

Mathematisch können wir die Situationen als Funktionen auffassen, die den Aussagen jeweils einen Wahrheitswert 

zuweisen. Diese Funktionen nennen wir in Zukunft Interpretationen. Wenn eine Formel ϕ unter einer 

Interpretation I zu wahr ausgewertet wird, sagen wir: ” 

I ist ein Modell von ϕ.“ und schreiben I |= ϕ, beispielsweise 

ist die Situation 1 ein Modell der Formel A 3 : 

Die Situation 2 ist dagegen kein Modell der Formel A 6 : 

|= A 3


Eine Formel ϕ heißt erfüllbar, wenn es eine Interpretation gibt, unter der ϕ zu wahr ausgewertet wird. In 

unserem Beispiel sind die Aussagen A 1 bis A 8 demnach alle erfüllbar. Eine Formel heißt allgemeingültig, wenn 

sie unter allen Interpretationen zu wahr ausgewertet wird. Allgemeingültige Formeln werden auch Tautologien 

genannt. In unserem Beispiel ist die Aussage A 4 eine Tautologie (wenn angenommen wird, daß nur die drei gegebenen 

Situationen existieren.) Da die konkrete Interpretation für den Wahrheitswert einer Tautologie keine Rolle 

spielt, läßt man sie weg und schreibt 

A 6 

|= A 4 

Theorien und Ableitungen 

Das Wissen über Modelle von Formeln kann benutzt werden, um aus einer gegebenen Menge von Formeln diejenigen 

Formeln abzuleiten, die zwingend auch gelten. Wenn beispielsweise bekannt ist, daß die Aussagen A 1 und A 2 

beide wahr sind, dann wissen wir auch (aufgrund der Definition der Junktoren), daß u.a. auch die Formel A 1 ∨ A 2 

wahr ist. Anders gesprochen: alle Interpretationen, die Modell von A 1 und Modell von A 2 sind, sind auch Modell 

von A 1 ∨ A 2 . Ein zweites Beispiel: Alle Modelle der Formel A 1 ∧ A 2 sind auch Modell der Formel A 1 und Modell 

der Formel A 2 . Andererseits gilt dies nicht zwingend für A 1 ∨ A 2 : in unserem Beispiel sind Situation 1 und 

Situation 2 Modelle der Formel A 1 ∨ A 2 , die Situation 2 ist aber kein Modell der Formel A 1 . 

Wenn jedes Modell einer Formelmenge Φ auch Modell einer Formel ψ ist, dann folgt ψ aus Φ, geschrieben 

Φ |= ψ. Die Formelmenge Φ nennen wir eine Theorie. Eine Interpretation I ist Modell einer Theorie, wenn sie 

Modell jeder Formel der Theorie ist. Wenn eine Theorie mindestens ein Modell hat, nennen wir sie konsistent, 

ansonsten inkonsistent. 

Wenn eine Theorie (z.B. T = {A 1 , A 2 }) gegeben ist, dann wäre es interessant zu wissen, welche Formeln 

auch gelten. Die Folgerungsrelation |= definiert dies zwar, gibt aber keine Möglichkeit zur Bestimmung der Menge 

vor. Aus diesem Grunde definieren wir eine Ableitungsrelation {ϕ 1 , ..., ϕ n } ⊢ ψ, indem wir Ableitungsregeln 

(Inferenzregeln) angeben. Ableitungsregeln werden folgendermaßen geschrieben: 

ϕ 1 , ..., ϕ n 

ψ 

Die Formelmenge ϕ 1 , ..., ϕ n stellt die Voraussetzung der Regel dar. Wenn jede der Formeln der Voraussetzung 

abgeleitet werden kann, dann kann auch die Konsequenz der Regel, die Formel ψ unterhalb des Strichs, abgeleitet 

werden. Wichtige Ableitungsregeln sind: 

Modus Ponens (Implikationsbeseitigung): Wenn es eine Implikation gibt und die Voraussetzung der Implikation 

abgeleitet werden kann, dann kann man auch die Konsequenz ableiten: 

⊢ ϕ 

⊢ ϕ ⇒ ψ 

⊢ ψ 

Und-Beseitigung: Wenn eine Konjunktion ableitbar ist, dann auch jede der Teilformeln: 

⊢ ϕ 1 ∧ ... ∧ ϕ n 

⊢ ϕ i 

Und-Einführung: Wenn eine Menge von Formeln ableitbar ist, dann auch ihre Konjunktion: 

⊢ ϕ 1 , ..., ⊢ ϕ n 

⊢ ϕ 1 ∧ ... ∧ ϕ n 

Unit-Resolution: Wenn eine Disjunktion zusammen mit der Negation einer der beiden Teilformeln ableitbar 

ist, dann ist die andere Teilformel ableitbar: 

⊢ ϕ 1 ∨ ϕ 2 , ⊢ ¬ϕ 2 

⊢ ϕ 1


Es gibt noch weitere Ableitungsregeln. In unserem Beispiel läßt sich folgende Ableitung bilden: wir gehen 

davon aus, daß Aussage A 4 allgemeingültig ist ( ” 

Wenn es regnet, ist die Straße naß.“). Wir sehen aus dem Fenster 

und stellen fest, daß es regnet. 

∅ ⊢ A 1 (Elementaraussage der Welt) 

∅ ⊢ A 1 ⇒ A 2 (als Tautologie akzeptiert, ” 

Wissen“) 

nach Modus Ponens folgt nun 

{A 1 , (A 1 ⇒ A 2 )} ⊢ A 2 

oder anders ausgedrückt: die Straße ist naß. 

Anwendungen der Aussagenlogik in relationalen Datenbanken 

Wir werden die Erkenntnisse über die Aussagenlogik sowohl in der relationalen Algebra als auch im relationalen 

Tupelkalkül benutzen, um Bedingungen über Tupeln auszudrücken. Jedes Tupel ist vergleichbar mit einer Situation 

im obigen Beispiel. Für unsere Tupel können wir Elementaraussagen definieren, indem wir die Prädikate der den 

Attributen zugeordneten Datentypen benutzen. Sei z.B. ein Relationenschema ANGEST ELLT ER(Name, W ohnort, Nieder 

gegeben. Den Attributen Name, W ohnort und Niederlassung sei der Datentyp ” 

Zeichenkette“ zugeordnet. Der 

Datentyp ” 

Zeichenkette“ verfüge über ein Gleichheitsprädikat =, daß auf lexikalische Gleichheit prüft. Dem Attribut 

” 

Gehalt“ seien neben einem Gleichheitsprädikat auch Ordnungsprädikate zugeordnet. Dann können 

wir folgende Elementaraussagen formulieren: 

A 9 : W ohnort = ′ Kiel ′ 

A 10 : W ohnort = Niederlassung 

A 11 : Gehalt > 4000 

Wir betrachten folgenden Zustand für das Relationenschema ANGEST ELLT ER (die erste Spalte enthalte 

Variablennamen für die einzelnen Tupel, damit wir sie referenzieren können): 

Name Wohnort Niederlassung Gehalt 

t 1 Müller Kiel Kiel 3500 

t 2 Meyer Kiel Rendsburg 4000 

t 3 Petersen Flensburg Flensburg 4300 

t 4 Schmidt Lübeck Hamburg 4400 

Die vier Tupel entsprechen den vier möglichen Situationen ( mögliche Welten“, engl. possible worlds“.) Wir 

” ” 

erhalten folgende Wahrheitswerte: 

A 9 A 10 A 11 A 10 ∧ A 11 

t 1 W W F F 

t 2 W F F F 

t 3 F W W W 

t 4 F F W F 

Demnach ist t 1 ein Modell der Aussagen A 9 und A 10 (t 1 |= A 9 , t 1 |= A 10 ). Das Tupel t 3 ist z.B. ein Modell 

der Aussagen A 10 , A 11 und A 10 ∧ A 11 (t 3 |= A 10 , t 3 |= A 11 , t 3 |= (A 10 ∧ A 11 ).) 

Prädikatenlogik erster Stufe 

Die Aussagenlogik erlaubt es nicht, Aussagen über Mengen von möglichen Welten zu treffen. Wenn wir unser 

Angestellten-Relationenschema aus dem letzten Abschnitt als Beispiel nehmen, dann kann die Aussage ” 

Alle Angestellten 

der Hamburger Niederlassung verdienen mehr als 3000 e.“ nicht mit Hilfe der Aussagenlogik formuliert 

werden 9 . Aus diesem Grunde erweitern wir unseren Formelbegriff um folgende Konstrukte: 

9 Die Aussage kann natürlich als Elementaraussage über den Niederlassungen formuliert werden. Allerdings ist es dann nicht mehr 

möglich, Zusammenhänge z.B. zum Gehalt eines einzelnen Angestellten der Niederlassung herzustellen.


• Wir führen Variablen ein. 10 Wir benutzen hier getypte Variablen (analog zur Diskussion über die Attribute 

des relationalen Datenmodells.) 

• Es werden Prädikate definiert. Die Aussagen der Aussagenlogik entsprechen 0-stelligen Prädikaten, z.B. 

EsRegnet(). Wir erlauben aber jetzt auch Prädikate höherer Stelligkeit, z.B. IstNaß(x) oder MuendetIn(x, y), 

wobei der Wertebereich der Variablen x und y die Menge aller Straßen ist. 

• Weiterhin existieren Quantoren: sei ϕ eine Formel der Prädikatenlogik erster Stufe. Dann sind auch 

(∃x)(ϕ) 

(∀x)(ϕ) 

es gibt“ 

” 

für alle“ 

” 

Formeln der Prädikatenlogik erster Stufe, wobei die Variable x in ϕ ” 

frei“ sein muß: sie darf in ϕ noch nicht 

an einen Quantor (∃ oder ∀) gebunden sein. 

Mit Hilfe der Quantoren lassen sich jetzt Aussagen über Mengen von Objekten machen, beispielsweise ” 

Es 

gibt eine nasse Straße“: 

oder ” 

Jede Straße mündet in eine andere Straße.“ 

(∃x)(IstNaß(x)) 

(∀x)((∃y)(MuendetIn(x, y))) 

Die üblichen Junktoren der Aussagenlogik bleiben uns erhalten: ” 

Wenn es regnet, sind alle nichtüberdachten 

Straßen naß.“: 

EsRegnet() ⇒ (∀x)((¬Ueberdacht(x)) ⇒ IstNaß(x)) 

Nicht alle Variablen müssen an Quantoren gebunden sein: ” 

Die nassen Straßen“ 

IstNaß(x) 

Eine Interpretation einer Formel der Prädikatenlogik erster Stufe ist eine Funktion, die allen Prädikaten eine 

Ausprägung (Extension) zuordnet, d.h. eine Menge von Tupeln, die das Prädikat erfüllen. 11 

Eine Variablenbelegung ϱ ordnet jeder Variablen einen Wert ihres Wertebereichs zu. Damit können wir die |= 

- Relation definieren: 

I, ϱ |= P (x 1 , ..., x n ) gdw. (ϱ(x 1 ), ..., ϱ(x n )) ist in der durch I gegebenen Ausprägung des Prädikats P enthalten. 

Beispiel: Betrachten wir die Formel IstNaß(x). Sei die Menge aller Straßen S = {Olshausenstr, W estring, W aitzstr, Os 

Die Interpretation I weise dem Prädikat IstNaß die Menge {Olshausenstr, W estring, W aitzstr} zu. Die Variablenbelegung 

ϱ 1 weise der Variablen x den Wert W estring zu. Dann gilt I, ϱ 1 |= IstNaß(x), da ϱ 1 (x) = 

W estring und W estring ∈ {Olshausenstr, W estring, W aitzstr}. Wenn wir die Variablenbelegung ϱ 2 betrachten, 

die der Variablen x den Wert Ostring zuweist, dann gilt I, ϱ 2 IstNaß(x), da Ostring /∈ {Olshausenstr, W estring 

Wenn wir aber die Interpretation I 2 betrachten, die dem Prädikat IstNaß die Menge {Olshausenstr, W estring, W aitzstr, Ost 

zuordnet, dann gilt I 2 , ϱ 2 |= IstNaß(x). 

Für die Junktoren ist die |= - Relation entsprechend der Aussagenlogik definiert. Für die Quantoren gilt: 

I, ϱ |= (∀x)(ϕ) gdw. I, ϱ ′ |= ϕ für alle möglichen ϱ ′ , die sich von ϱ höchstens in der Belegung von x unterscheiden. 

10 W ohnort, Niederlassung und Gehalt in den Formeln der Aussagenlogik sind keine Variablen in diesem Sinne, da die Formel 

jeweils immer für eine ganz bestimmte Welt (für ein ganz bestimmtes Tupel) ausgewertet wurde; dort sind den Attributen aber eindeutige 

Werte zugeordnet. 

11 Korrekterweise ist die Interpretation ein Tripel bestehend aus dem Wertebereich, der Belegung der Konstantensymbole und der Prädikatsausprägung, 

aber dies vernachlässigen wir hier.


I, ϱ |= (∃x)(ϕ) gdw. es gibt eine Variablenbelegung ϱ ′ , die sich von ϱ höchstens in der Belegung von x 

unterscheidet, so daß gilt: I, ϱ ′ |= ϕ. 

Wenn I, ϱ |= ϕ für alle Belegungen ϱ gilt, dann schreiben wir auch I |= ϕ und sagen I erfüllt ϕ bzw. I 

ist ein Modell von ϕ. Die Definitionen der Erfüllbarkeit und Allgemeingültigkeit orientieren sich an denen der 

Aussagenlogik. 

Wir werden die Prädikatenlogik erster Stufe im Kontext des relationalen Tupelkalküls benutzen, um Anfragen 

an Datenbanksysteme zu formulieren. 

Mehrwertige Logiken 

Bisher haben wir zweiwertige Logiken betrachtet: eine Aussage war immer entweder wahr oder falsch. Es ist 

jedoch nicht in allen Situationen möglich, diese Entscheidung zu treffen: manchmal ist eine Aussage ” 

ein bisschen 

wahr und ein bisschen falsch“, manchmal wissen wir nicht, ob eine Aussage wahr oder falsch ist. Betrachten wir 

z.B. folgende Personen: 

Anna Kristina Joe Sandra Thomas 

blondes Haar rotes Haar Glatze Welche Haarfarbe? Glatze oder Haare? 

Anna hat offensichtlich blondes Haar. Kristina hat rotes Haar und Joe trägt eine Glatze. Sandra färbt sich öfters 

die Haare, deshalb weiß man es nie so genau, welche Haarfarbe sie momentan hat. Da man Thomas nur mit seinem 

Helm sieht, weiß man nicht, ob er eine Glatze trägt bzw. welche Farbe seine Haare haben. Wenn wir eine Relation 

mit den Haarfarben der Personen aufschreiben, dann kann man für Anna und Kristina eindeutig ’blond’ bzw. ’rot’ 

eintragen. Joe hat keine Haare und demnach auch keine Haarfarbe. Bei Sandra kennen wir die Farbe nicht und 

bei Thomas sind wir uns nicht sicher, ob er eine Haarfarbe hat. Unsere ” 

Unwissenheit“ können wir mit einem 

null-Wert im Wertebereich des Attributs Haarfarbe ausdrücken: 

Name 

Anna 

Kristina 

Joe 

Sandra 

Thomas 

Haarfarbe 

blond 

rot 

null 

null 

null 

Angenommen, in der ” 

realen Welt“ gibt es nur die Haarfarben blond, rot, braun und schwarz. Wir können eine 

Aussage A 12 formulieren: Haarfarbe = ′ blond ′ ∨Haarfarbe = ′ rot ′ ∨Haarfarbe = ′ braun ′ ∨Haarfarbe = ′ 

schwarz ′ . Offensichtlich gilt: 

Name : Anna, Haarfarbe : blond |= A 12 

Name : Kristina, Haarfarbe : rot |= A 12 

Obwohl wir alle möglichen Haarfarben aufzählen, fallen Joe, Sandra und Thomas unter den Tisch. Dies ist in 

der Tatsache begründet, daß der null-Wert der Haarfarbe ein künstlicher Wert ist, der keine Entsprechung in der 

realen Welt“ hat. Er vermischt das konkrete Datum Haarfarbe mit dem Wissen über die Existenz des Datums 

” 

Haarfarbe. 

Wir können eine Aussage A 13 definieren: ¬Haarfarbe = ′ blond ′ . Für Kristina und Joe ergibt dies das 

gewünschte Ergebnis. Bei Sandra und Thomas wissen wir aber nicht, ob sie evtl. doch blond sind. Wenn dies 

der Fall ist, wäre die Antwort unseres Systems falsch.


Aus diesem Grunde kann die klassische zweiwertige Logik erweitert werden. Der hier vorgestellte Ansatz 

wurde von Jan Łukasiewicz 1920 eingeführt. Es wird ein dritter Wahrheitswert definiert, der zwischen wahr“ und ” 

” falsch“ angesiedelt ist. Der Wahrheitsgehalt dieses Werts wird als möglich, aber nicht bewiesen“ gedeutet. Wir 

” 

könnten also das Prädikat =“ des Datentyps Haarfarbe so verändern: 

” 

=(x,y) blond rot schwarz braun null 

blond W F F F M 

rot F W F F M 

schwarz F F W F M 

braun F F F W M 

null M M M M M 

Das Prädikat sagt jetzt folgendes aus: die Werte blond, rot, schwarz und braun werden untereinander im üblichen 

Sinne verglichen. Wenn einer der Werte null ist, dann ist das Vergleichsergebnis möglicherweise wahr, möglicherweise 

aber auch falsch. 

Wir müssen natürlich die Wertetabellen der Junktoren anpassen: 

A ∧ B A ist falsch A ist möglich A ist wahr 

B ist falsch falsch falsch falsch 

B ist möglich falsch möglich möglich 

B ist wahr falsch möglich wahr 

Wenn eine der Teilaussagen falsch ist, dann kann die Gesamtaussage nicht wahr werden. Wenn beide Teilaussagen 

wahr sind, ist die Gesamtaussage wahr. Wenn eine Teilaussage wahr und die zweite Teilaussage möglicher- 

” 

weise wahr ist, dann ist die Gesamtaussage möglicherweise wahr. Wenn beide Teilaussagen möglicherweise wahr 

sind, ist die Gesamtaussage möglicherweise wahr.“ 

A ∨ B A ist falsch A ist möglich A ist wahr 

B ist falsch falsch möglich wahr 

B ist möglich möglich möglich wahr 

B ist wahr wahr wahr wahr 

Wenn eine der Teilaussagen wahr ist, wird die Gesamtaussage wahr. Wenn beide Teilaussagen falsch sind, ist 

” 

die Gesamtaussage falsch. Sonst ist die Gesamtaussage möglich.“ 

Es gibt zwei Arten der Negation: die starke Negation ¬A und die schwache Negation ∼ A: 

¬A A ist falsch A ist möglich A ist wahr 

wahr möglich falsch 

∼ A A ist falsch A ist möglich A ist wahr 

wahr wahr falsch 

Aufbauend auf den beiden Negationen gibt es zwei Implikationen: A ⇒ B = def ¬A ∨ B, A → B = def ∼ 

A ∨ B. Man beachte, daß die Tautologien der klassischen Logik (z.B. A ∨ ¬A) in der dreiwertigen Logik nicht 

unbedingt gelten müssen. 

Aufbauend auf der mehrwertigen Logik lässt sich jetzt z.B. die Anfrage Wer hat ganz sicher keine blonden 

” 

Haare?“ von der Anfrage Wer hat möglicherweise keine blonden Haare?“ unterscheiden. 

” 

Die hier vorgestellte dreiwertige Logik hat immer noch Probleme: Auf die Anfrage Wer hat möglicherweise 

” 

blonde Haare?“ qualifiziert sich Joe immer noch, obwohl er als Glatzenträger mit Sicherheit keine blonden Haare 

hat. Allerdings fällt er bei der Anfrage Wer hat mit Sicherheit keine blonden Haare?“ unter den Tisch. Deshalb 

” 

kann die dreiwertige Logik erweitert werden, um verschiedene Arten von null-Werten zu unterstützen. In unserem 

Beispiel unterscheidet sich die Bedeutung des null-Werts für Joe, Sandra und Thomas: bei Joe drückt die null 

aus, daß es keinen Wert für die Haarfarbe gibt, bei Sandra, daß die Haarfarbe unbekannt ist und bei Thomas, daß 

unbekannt ist, ob es einen Wert für die Haarfarbe gibt. Mit diesen Erweiterungen werden wir uns hier aber nicht 

beschäftigen.


Anhang 

12 

Einführung 

Mit SQL existiert eine standardisierte Sprache, um auf Daten eines relationalen Datenbanksystems zuzugreifen. Die 

Art und Weise, wie SQL-Anfragen an das System übermittelt werden, ist jedoch für jedes Datenbankmanagementsystem 

spezifisch. Oftmals unterscheiden sich sogar verschiedene Versionen desselben DBMS in den verwendeten 

Schnittstellen. 

Eine Anwendung, die auf ein DBS zugreifen möchte, muss die Kommunikationsprotokolle des DBMS kennen. 

Die Hersteller bieten deshalb für die gängigen Programmiersprachen und Laufzeitumgebungen Bibliotheken an, die 

den Datenbankzugriff ermöglichen. In PHP kann man beispielsweise auf eine MySQL-Datenbank folgendermaßen 

zugreifen (die Variablen sind selbsterklärend, die Fehlerbehandlung wurde weggelassen): 

$conn = mysql_connect($host,$user,$password); 

mysql_select_db($db,$conn); 

$result = mysql_query("select HOTEL_CODE,HOTEL_NAME from ACCOMMODATION"); 

while($row = mysql_fetch_row($result)) 

{ 

echo "Code: $row[0], Name: $row[1]"; 

} 

mysql_close($conn); 

Wenn diese Anwendung z.B. nach PostgreSQL portiert werden soll, so müssen alle mysql *-Aufrufe z.B. 

durch entsprechende pg *-Aufrufe des PostgreSQL-Moduls ersetzt werden. 

Um anwendungsseitig einen (relativ) DBMS-neutralen Zugriffsmechanismus auf Datenbanken zu ermöglichen, 

wurden diverse Frameworks spezifiziert, z.B. die Open Database Connectivity (ODBC), ActiveX Data Objects 

(ADO) oder die Java Database Connectivity (JDBC). Mit letzterem wollen wir uns hier beschäftigen. 

Um ein mögliches Missverständnis auszuschließen: JDBC ist kein Framework, daß die systemspezifische Unterstützung 

verschiedener SQL-Dialekte abstrahiert. Die JDBC-Infrastruktur sorgt lediglich dafür, daß eine SQL- 

Anfrage von der Anwendung standardisiert an das DBS übergeben und das Ergebnis zurückgeliefert wird. JDBC 

sorgt nicht dafür, daß z.B. die in MySQL optionale from-Klausel beim Zugriff auf andere Systeme automatisch 

ergänzt wird. ” 

SQL Tuning“ für spezifische Systeme bleibt weiterhin Aufgabe des Programmierers. 

Grundgerüst eines JDBC-basierten Programms 

Abbildung 3 zeigt den Grobaufbau einer JDBC-basierten Anwendung. Sie besteht aus 3 Schichten: 

• Anwendungslogik: Sie definiert die Verarbeitungsregeln der Geschäftsprozesse. 

• JDBC-Datenbanktreiber: Er kapselt die Spezifika des Datenbanksystems und stellt der Anwendungslogik 

die Daten der Datenbank mit Hilfe einer standardisierten Schnittstelle zur Verfügung. 

• Datenbank: Speichert die Daten. Der Treiber kommuniziert mit der Datenbank über ein DBMS-spezifisches 

Protokoll. 

Aus Sicht des Java-Programmierers ist ein JDBC-Datenbanktreiber eine Bibliothek bestehend aus einer Reihe 

von Klassen. Die Klassen implementieren die Interfaces der Standard-Packages java.sql und javax.sql. 

Diese Interfaces erlauben das datenbankunabhängige Programmieren mit Hilfe von JDBC: die Anwendung ” 

sieht“ 

nur ein java.sql-Interface. Welche Klasse aus welchem Treiber letztlich instanziiert wurde, bleibt verborgen. 

Der Zugriff auf eine Datenbank über JDBC innerhalb eines Java-Programms lässt sich in einzelne Phasen 

aufteilen, die nacheinander ausgeführt werden müssen, Abbildung 4 zeigt eine Übersicht. 

12 Dieser Anhang wurde von G. Fiedler erstellt.


. 

. 

Applikationslogik 

. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 

. 

. 

. 

. 

JDBC- 

Treiber 

. 


Treiber 

. 


Treiber 

. 

. 

. 

ODBC- 

Treiber 

. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 

. 

DB2 

. 

Oracle 

. 

CSV-Datei 

. 

Abbildung 3: Aufbau einer JDBC-basierten Anwendung 

1. Laden des Treibers: 

In dieser Phase werden die Klassen des JDBC - Treibers dynamisch in die Anwendung eingebunden und 

registriert. 

2. Herstellen der Verbindung: 

Der Treiber baut eine Verbindung zum DBMS auf. 

3. Erzeugen eines Statements: 

Statements sind die JDBC-Repräsentation für SQL-Anweisungen. Bevor eine SQL-Anfrage gestartet werden 

kann, muss sie in ein Statement ” 

verpackt“ werden. 

4. Ausführen des Statements: 

Die SQL-Anfrage wird an das DBMS übermittelt und dort ausgeführt. Die Resultate werden zurückgeliefert. 

5. Auswertung der Ergebnisse: 

Über die Methoden des Interfaces java.sql.ResultSet kann das Ergebnis einer Anfrage ausgewertet 

werden. 

6. Schließen der Verbindung: 

um nicht weiter benötigte Ressourcen freizugeben. 

Die Phasen im Detail 

Dieser Abschnitt verdeutlicht die einzelnen Phasen eines JDBC-Zugriffs anhand von Codebeispielen und Abbildungen. 

Grundlage bildet wieder unsere 3-Schichten-Anwendung:


Laden des Treibers 

♣ 

♣ 

♣ 

Herstellen der Verbindung 

zum DBMS 

♣ 

Erzeugen eines 

Statement-Objekts 

♣ 

♣ 

♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣ 

Ausführen 

einer Anfrage 

♣♣♣♣♣♣♣♣♣♣♣♣ ♣ 

Ausführen 

eines Updates 

♣ 

Auswertung 

der Ergebnisse 

♣ 

♣ 

Schließen 

der Verbindung 

Abbildung 4: Phasen des Datenbankzugriffs 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 

DB2-Treiber 

. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 


. 

Laden des Treibers 

Wie bereits angedeutet, ist ein JDBC-Datenbanktreiber nichts anderes als eine Bibliothek diverser Java-Klassen, 

welche die Interfaces aus java.sql und javax.sql implementieren. Jeder Treiber enthält als Repräsentanten 

eine ” 

Hauptklasse“, die das Interface java.sql.Driver implementiert. Über diese Klasse wird der Treiber


identifiziert und angesprochen. 

Eine zentrale JDBC-Komponente ist der Treibermanager. Er wird durch die Klasse java.sql.DriverManager 

repräsentiert und ist zuständig für die Verwaltung und den Zugriff auf die Datenbanktreiber. Ein Treiber steht der 

Anwendung erst zur Verfügung, wenn er sich beim Treibermanager registriert hat. 

Das dynamische Laden eines Treibers gestaltet sich genauso wie das Laden jeder anderen beliebigen Java- 

Klasse. Angenommen, wir möchten den Treiber für DB2-Datenbanken laden. Die ” 

Hauptklasse“ des JDBC-Treibers 

hat den Namen com.ibm.db2.jcc.DB2Driver: 

try Class.forName(com.ibm.db2.jcc.DB2Driver“).newInstance(); catch(ClassNotFoundException e) // Fehlerbehandlung, 

falls Klasse nicht gefunden wurde 

Die Treiberklasse sorgt automatisch für eine Registrierung beim Treibermanager. Das Laden des Treibers muss 

nur einmal während der Initialisierungsphase durchgeführt werden, der Treiber steht bis zum Ende der Anwendung 

zur Verfügung: 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 


. 

Herstellen der Verbindung 

Nachdem der Datenbank-Treiber in die Anwendung integriert wurde, kann die Verbindung zur Datenbank geöffnet 

werden. Dafür sind die folgenden Informationen von Bedeutung: 

• Welcher Treiber soll benutzt werden? 

• Wie heißt die Datenbank und wo befindet sie sich? 

• Mit welchen Daten authentifiziere ich mich gegenüber der Datenbank? 

• ... 

Das Öffnen der Verbindung wird durch den Treibermanager und dessen statische Methode getConnection() 

veranlasst. Diese Methode liefert ein Objekt zurück, dessen Klasse das Interface java.sql.Connection implementiert. 

Die oben genannten Daten werden der Methode in Form einer URL (uniform resource locator) übergeben. 

Diese URL hat die folgende standardisierte Form: 

jdbc:: 

Über die Zeichenkette wird der gewünschte Treiber spezifiziert. Der Inhalt von 

hängt vom konkreten Treiber ab. Der DB2-Treiber erwartet beispielsweise folgende URL: 

jdbc:db2://:/:


Die Kombination aus und gibt dabei den Server an, auf dem sich die Datenbank befindet, 

spezifiziert den Namen der Datenbank. Zusätzliche Parameter können in der Form =; 

nach dem Doppelpunkt angegeben werden. Für Verbindungsparameter sei auf das DB2-Handbuch verwiesen. 

Angenommen, der Nutzer joe (Passwort: foo) möchte die DB2-Datenbank namens Personal auf dem 

Rechner dbserver nutzen. Das DBMS ist über Port 1234 erreichbar. 

Es gibt 3 verschiedene Varianten der DriverManager.getConnection-Methode: 

• DriverManager.getConnection(String url): 

Der allgemeine Fall. Alle Daten müssen gemäß der oben genannten Vorschrift in eine URL verpackt werden: 

String url = “jdbc:db2://dbserver:1234/Personal:user=joe;password=foo;“; 

Connection conn = DriverManager.getConnection(url); 

• DriverManager.getConnection(String url, Properties info): 

Der Methode wird zusätzlich ein assoziatives Array info übergeben, welches die Parameter aufnehmen 

kann, die normalerweise nach dem Fragezeichen der URL stehen würden. Sinnvoll ist diese Trennung, wenn 

diese Parameter dynamisch generiert werden. Dann entfällt die umständliche Kodierung der URL: Properties 

props = new Properties(); props.put(üser“,“joe“); props.put(password“,foo“); String url = “jdbc:db2://dbserver:1234/Person 

Connection conn = DriverManager.getConnection(url,props); 

• DriverManager.getConnection(String url, String user, String password): 

Analog zur 2. Variante, falls als Parameter nur Nutzername und Passwort benötigt werden: String url = 

“jdbc:db2://dbserver:1234/Personal“; 

Connection conn = DriverManager.getConnection(url,“joe“,foo“); 

Nach Abschluß dieser Phase besteht eine Kommunikationsverbindung zwischen der Anwendung und der Datenbank: 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 


 

. 

 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 

. 


. 

2.4.8 Datasources 

In realen Umgebungen ist es normalerweise notwendig, den Verbindungsaufbau weiter zu abstrahieren. In der URL 

sind z.B. der Datenbankserver und der Name der Datenbank vermerkt. Eine Anwendung wird i.d.R. in verschiedenen 

Umgebungen eingesetzt, und es kann relativ häufig passieren, daß sich die Konfigurationsparameter der 

Datenbank ändern. Außerdem ist vielleicht eine zentrale Konfiguration für verschiedene Anwendungen sinnvoll, 

die alle parallel auf ein Datenbanksystem zugreifen möchten.


Seit der JDBC-Version 2.0 existiert ein neues Interface namens javax.sql.DataSource, welches sich 

dieses Problems annimmt. DataSource-Objekte kapseln eine Datenquelle. Über die Methode getConnection 

des DataSource-Interfaces kann man sich eine vorkonfigurierte Verbindung zu dieser Datenquelle geben lassen. 

DataSources spielen ihre Vorteile insbesondere in J2EE-Umgebungen aus. Dort übernimmt der Anwendungsserver 

die zentrale Verwaltung aller bekannten Datenquellen. Über einen Verzeichnisdienst (JNDI, ” 

Gelbe Seiten“) 

kann eine Anwendung auf eine Datenquelle des Anwendungsservers über einen Namen zugreifen. Wenn sich die 

physischen Parameter der Datenquelle ändern (z.B. wenn die Datenbank auf einen neuen Rechner umzieht), dann 

muß diese Änderung nur zentral im Anwendungsserver durchgeführt werden. 

Die Benutzung von Datenquellen hat einen weiteren entscheidenden Vorteil: das Öffnen einer Verbindung ist 

ein relativ kostenintensiver Prozeß, der einige Sekunden dauern kann. Die zentrale Verwaltung von Datenbankverbindungen 

erlaubt die Implementierung des ” 

Pooling“-Patterns: Die Datenquelle verwaltet einen Pool von offenen 

Verbindungen. Wenn eine Anwendung eine Verbindung anfordert, dann wird keine neue Verbindung geöffnet, sondern 

sie bekommt eine der offenen Verbindungen zugeteilt, die sich im Pool befinden. Wenn die Anwendung die 

Verbindung schließt, dann wird die Verbindung wieder als ” 

frei“ markiert. Durch diesen Mechanismus, der einigen 

vielleicht aus dem Kontext von Prozessen und Threads bekannt ist, wird eine erhebliche Performance-Steigerung 

erreicht. 

Erzeugen eines Statements 

SQL-Anfragen werden unter JDBC in Statement-Objekte eingekapselt. Bevor eine Anfrage ausgeführt werden 

kann, muß ein derartiges Objekt erzeugt werden. Dies geschieht durch Aufruf der createStatement-Methode 

des im vorherigen Schritt erzeugten Connection-Objekts: 

Statement stmt = conn.createStatement(); 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 


 

 

. 

stmt 

. 

 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 

. 


. 

Neben einfachen SQL-Anfragen, wie wir sie hier betrachten, können über Statement-Objekte auch spezielle 

vorcompilierte Anfragen (prepared statements) und stored procedures ausgeführt werden. Außerdem läßt sich über 

die Statement-Objekte die Rückgabe des Ergebnisses steuern. Zu beachten ist: ein einzelnes Statement kann 

nicht mehrere SQL-Anfragen gleichzeitig verwalten. Ergebnisse müssen verarbeitet werden, bevor mit diesem 

Statement-Objekt eine neue Anfrage gestellt wird. 

Ausführen eines Statements 

Das Statement-Objekt stellt Methoden zum Ausführen von SQL-Anweisungen bereit. Aufgrund der unterschiedlichen 

Bedürfnisse werden zwei verschiedene Anweisungsarten unterschieden: Anfragen und Updates.


Anfragen sind SQL-Anweisungen, die ein Ergebnis zurückliefern, typischerweise select - Anweisungen. Sie 

werden über die executeQuery-Methode des Statement-Objekts ausgeführt, diese Methode nimmt die Anfrage 

als Parameter in Textform entgegen und liefert das Ergebnis in einem ResultSet-Objekt zurück: 

ResultSet result = stmt.executeQuery(SSELECT * FROM staff“); 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 



result 

 

. 

stmt 

. 

♣♣ 

 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. . 

 

. 

♣♣ ♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣ ♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣ ♣ 

. 

♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣♣ ♣ 

♣ ♣♣♣♣♣♣♣♣♣♣ ♣ 

. 

♣ 

♣ 

SELECT * FROM staff 

. 

Updates entsprechen den drei DML-Anweisungen insert, update und delete. Sie werden über die 

executeUpdate-Methode des Statement-Objekts ausgeführt. Diese Methode liefert als Ergebnis die Anzahl 

der durch das Update betroffenen Tupel zurück, vorausgesetzt der Treiber sowie das DBMS unterstützen dies: 

stmt.executeUpdate( ÜPDATE staff SET salary=3000 WHERE name=’Joe Hacker’“); 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 


♣ 

♣ 

♣ ♣ ♣ ♣ ♣ ♣ ♣ ♣ ♣ 

stmt 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 

. 

. 

. 

♣ 

. 


. 

. . 

UPDATE staff SET salary=3000 

WHERE name=’Joe Hacker’ 

Auswertung der Ergebnisse 

Wurde eine Anfrage ausgeführt, muß in dieser Phase das zurückgelieferte ResultSet ausgewertet werden. Dies 

geschieht nach dem Iterator-Pattern. Das Objekt besitzt einen internen Zeiger auf das jeweils aktuelle Tupel der 

Ergebnismenge. Über die Methode next() wird dieser Zeiger auf das jeweils nächste Tupel gesetzt. Ist kein Tupel 

mehr vorhanden, so liefert die next-Methode den boolschen Wert false zurück. Zu Beginn steht der Zeiger vor 

dem ersten Tupel. 

Auf die einzelnen Attribute des aktuellen Tupels kann über die getXXX-Methoden des ResultSet-Objekts 

zugegriffen werden. XXX steht dabei für die Namen der Standarddatentypen, z.B. String oder Double. Diese 

Methoden erwarten entweder den Index des Attributs (Achtung: die Zählung beginnt bei 1!) oder dessen Namen. 

Es wird vorausgesetzt, daß der Typ des jeweiligen Attributs bekannt ist. 

while( result.next() ) System.out.println( result.getString(name“)+“: “+ Double.toString(result.getDouble(ßalary“)));


Schließen der Verbindung 

Wird eine Datenbank-Verbindung nicht mehr benötigt, kann sie durch einen Aufruf der close-Methode des 

Connection-Objekts geschlossen werden, um Systemressourcen freizugeben. Gleiches gilt für Resultsets und 

Statements: 

result.close(); stmt.close(); conn.close(); 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 

. 


. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. 


. 

Man sollte sich angewöhnen, jedes Resultset, jedes Statement und jede Verbindung explizit zu schließen und 

sich nicht auf den Garbage-Collector der JVM verlassen. 

Ein zusammenhängendes Beispiel 

Nachfolgend sind die Codebeispiele des letzten Abschnitts nochmal in einem Block zusammengefaßt: 

// Import der Interfaces des java.sql-Packages import java.sql.*; import java.util.Properties; 

public class JDBCMain public static void main(String args[]) try // Laden des DB2-Treibers Class.forName(kom.ibm.db2.jcc.DB2Driver“).newInstance(); 

catch(ClassNotFoundException e) e.printStackTrace(); System.err.println(TTreiber 

nicht gefunden!“); System.exit(-1); 

try String url = “jdbc:db2://dbserver:1234/Personal“; 

// Oeffnen der Verbindung zum DBMS // Nutzername und Passwort sollten natuerlich // vom Nutzer abgefragt 

werden! Connection conn = DriverManager.getConnection(url,“joe“,foo“); 

// Erzeugen eines Statements Statement stmt=conn.createStatement(); 

// Ausfuehren eines Updates String sql = ÜPDATE staff SET salary=3000 WHERE name=’Joe Hacker’“; 

stmt.executeUpdate(sql); 

// Ausfuehren einer Anfrage sql = SSELECT * FROM staff“; ResultSet result = stmt.executeQuery(sql); 

// Auswerten der Anfrage-Ergebnisse while( result.next() ) System.out.println( result.getString(name“)+“: “+ 

Double.toString(result.getDouble(ßalary“))); result.close(); 

stmt.close(); 

// Beenden der Verbindung conn.close(); catch(Exception e) // Ausgabe der Fehlermeldung e.printStackTrace(); 

System.exit(-1); 

Weitergehende Möglichkeiten mit JDBC 

Die Möglichkeiten von JDBC gehen weit über die hier vorgestellten Grundlagen hinaus. Dieser Abschnitt stellt als 

Beispiele einige fortgeschrittene Techniken vor: Abfrage der Schema-Information, die Bearbeitung von Ergebnismengen 

und Transaktionen.


Nutzung von Metadaten 

Bisher wurde vorausgesetzt, daß der Programmierer das Schema der Datenbank genau kennt. Wenn z.B. der Typ eines 

Attributs eines Tupels der Ergebnismenge unbekannt ist, weiß der Entwickler nicht, welche getXXX-Methode 

zu benutzen ist. 

Diese Schema-Informationen (Metadaten) sind allerdings im Data Dictionary der Datenbank gespeichert und 

können über JDBC abgefragt werden, sofern der Treiber und das DBMS dies unterstützen. Metadaten stehen an 

zwei Stellen zur Verfügung: 

• Connection.getMetaData liefert ein DatabaseMetaData - Objekt zurück, das Informationen über 

die Datenbank im Allgemeinen enthält, d.h. die Tabellenstruktur, die gespeicherten Prozeduren, den verwendeten 

SQL-Dialekt, etc. 

• ResultSet.getMetaData liefert ein ResultSetMetaData - Objekt zurück, das Informationen über 

die Struktur einer Ergebnismenge enthält, also z.B. Namen und Typen der Attribute. 

Das folgende Code-Fragment (aufbauend auf der oben genutzten Personal-Datenbank) analysiert die Attribut- 

Struktur der Ergebnismenge einer Anfrage: 

/* ... */ 

// Anfrage ausfuehren ResultSet result = stmt.executeQuery(SSELECT * FROM staff“); 

// Metadaten auslesen ResultSetMetaData md = result.getMetaData(); 

// Ausgabe aller Attributnamen // ACHTUNG: das erste Attribut hat die Position 1 ! for(int idx=1; idx¡=md.getColumnCount() 

idx++) System.out.println(md.getColumnName(idx)); 

/* ... */ 

Verarbeitung von Ergebnismengen 

Ein normales ResultSet-Objekt hat zwei einschränkende Eigenschaften: 

• Die Werte können nicht verändert werden. 

• Sie besitzen ein sogenanntes forward-only-Cursor 13 , d.h. die Menge kann nur genau einmal vom ersten bis 

zum letzten Element durchlaufen werden. 

Seit JDBC Version 2.0 existieren scrollbare ResultSets. Mittels diverser Navigationsmethoden kann der 

Zeiger innerhalb der Menge beliebig gesetzt werden: auf absolute Positionen, vorwärts oder rückwärts. 

Außerdem ist es wünschenswert, wenn man die Daten eines ResultSets nachbearbeiten kann. Zu diesem Zweck 

existieren änderbare ResultSet-Objekte mit updateXXX-Methoden. 

Der Typ eines ResultSets wird durch das Statement bestimmt, in dessen Kontext es erzeugt wird. Ein 

Statement, das mittels conn.createStatement() erzeugt wurde, generiert stets nicht veränderbare und nicht 

scrollbare ResultSets. Werden der Methode zwei Parameter übergeben, läßt sich dieses Verhalten ändern: 

Statement stmt = conn.createStatement(int resultSetType, int resultSetConcurrency); 

Der Parameter resultSetType kann folgende Werte annehmen: 

resultSetType 

ResultSet.TYPE FORWARD ONLY 

ResultSet.TYPE SCROLL INSENSITIVE 

ResultSet.TYPE SCROLL SENSITIVE 

Bedeutung 

Das ResultSet kann nur einmal vom ersten 

bis zum letzten Element durchlaufen 

werden. 

Das ResultSet ist scrollbar, simultane 

Änderungen anderer Nutzer bleiben verborgen 

Das ResultSet ist scrollbar, Änderungen 

anderer Nutzer schlagen auf die Werte durch. 

13 Cursor steht hier für current set of records.


Für resultSetConcurrency gibt es diese Möglichkeiten: 

resultSetConcurrency 

ResultSet.CONCUR READ ONLY 

ResultSet.CONCUR UPDATABLE 

Bedeutung 

Das Ergebnis kann nicht verändert werden. 

Das Ergebnis kann editiert werden. 

Das folgende Code-Fragment erzeugt ein Statement für scrollbare und änderbare ResultSets: 

/* ... */ Statement stmt = conn.createStatement(ResultSet.TYPE S CROLL I NSENSIT IV E, ResultSet.CONCUR U P D 

... ∗ / 

// ausfuehren einer Anfrage ResultSet result = stmt.executeQuery(SSELECT * FROM staff“); 

// setzt den Zeiger auf Position 2 result.absolute(2); 

// setzt den Zeiger auf das erste Tupel result.first(); 

// aendert das Gehalt result.updateDouble(ßalary“,2000); 

Transaktionen 

Die JDBC-API unterstützt die Nutzung von Transaktionen. Standardmäßig ist definiert, daß jede SQL-Anweisung, 

die per executeQuery oder executeUpdate ausgeführt wird, einer Transaktion entspricht. Dieses Verhalten 

läßt sich über die setAutoCommit-Methode des Connection-Objekts ändern. Durch den Parameter false 

wird nach Ausführung von executeXXX-Methoden ein expliziter Aufruf von Connection.commit bzw. 

Connection.rollback erwartet: 

/* ... */ 

// eine Transaktion fuer sich stmt.executeUpdate( ÜPDATE staff SET salary=3000 WHERE name=’Joe Hacker’“); 

conn.setAutoCommit(false); 

/**** * Beginn der Transaktion ****/ 

stmt.executeUpdate( ”DELETE FROM staff WHERE name=’Alf Weise’“); 

stmt.executeUpdate( ÏNSERT INTO staff (name,salary) VALUES(’Tina Kunterbunt’,1000)“); 

// Commit conn.commit(); 

/**** * Ende der Transaktion ****/ /**** * Beginn einer neuen Transaktion ****/ 

stmt.executeUpdate( ÜPDATE staff SET salary=2000 WHERE name=’Tina Kunterbunt’“); 

// Rollback conn.rollback(); 

/**** * Ende der Transaktion ****/ 

/* ... */ 

Hinweis: Das zugrunde liegende DBMS muß natürlich Transaktionen unterstützen! 

Weiterführende Lektüre 

Im WWW sind eine Vielzahl von Dokumenten über den Gebrauch von JDBC verfügbar, z.B.: 

• Java-API Dokumentation: 

http://java.sun.com/products/jdk/1.4.2/docs/api/index.html 

• JDBC-Tutorial von Sun: 

http://java.sun.com/docs/books/tutorial/jdbc/ 

• ein weiteres Sun-Tutorial: 

http://developer.java.sun.com/developer/Books/JDBCTutorial/ 

• Kurzübersicht: 

http://www.cs.unc.edu/Courses/wwwp-s98/members/thornett/jdbc/ 

• Code-Beispiele für Java allgemein: 

http://www.exampledepot.com/ 

• ...

Datenbanken I 2. Relationale DB - Technologie der ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?