laden - LS1 - Logik in der Informatik

Datenbanktheorie
Sommersemester 2012 - Thomas Schwentick
Teil A: Einleitung
1: Grundbegriffe
Version von: 4. April 2012 (11:49)
Inhalt
1.1 Das relationale Datenmodell
1.2 Anfragen an relationale Datenbanken
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 1
Relationales Modell: Tabellen
• Grundidee des relationalen Datenmodells:
◮ Daten werden in Tabellen organisiert
◮ Einfache Operationen für Tabellen:
Zeilen einer Tabelle auswählen
Spalten einer Tabelle auswählen
Tabellen kombinieren
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 2
Relationales Modell: Tabellen
• Grundidee des relationalen Datenmodells:
◮ Daten werden in Tabellen organisiert
◮ Einfache Operationen für Tabellen:
Zeilen einer Tabelle auswählen
Spalten einer Tabelle auswählen
Tabellen kombinieren
Beispiel
P ROFESSOREN
PersNr
Name
Raum
201
Turing
134
212
Gödel
27
238 von Neumann 212
213
Knuth
144
211
Chomsky
312
205
Shannon
213
202
Dijkstra
321
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 2
Relationales Modell: Tabellen
• Grundidee des relationalen Datenmodells:
◮ Daten werden in Tabellen organisiert
◮ Einfache Operationen für Tabellen:
Zeilen einer Tabelle auswählen
Spalten einer Tabelle auswählen
Tabellen kombinieren
Beispiel
P ROFESSOREN
PersNr
Name
Raum
201
Turing
134
212
Gödel
27
238 von Neumann 212
213
Knuth
144
211
Chomsky
312
205
Shannon
213
202
Dijkstra
321
• Das relationale Datenmodell wurde 1970
von Codd vorgeschlagen und ist seit Ende
der 80er Jahre der „Industriestandard“
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 2
Relationales Modell: Tabellen
Kurz-Bio: Edgar Codd
• Grundidee des relationalen Datenmodells:
◮ Daten werden in Tabellen organisiert
◮ Einfache Operationen für Tabellen:
Zeilen einer Tabelle auswählen
Spalten einer Tabelle auswählen
Tabellen kombinieren
• Geboren: 23.8.1923, Isle of Portland (Eng•
•
•
Beispiel
•
P ROFESSOREN
PersNr
Name
Raum
201
Turing
134
212
Gödel
27
238 von Neumann 212
213
Knuth
144
211
Chomsky
312
205
Shannon
213
202
Dijkstra
321
land)
Studium der Mathematik und Chemie in
Oxford
Ab 1948 Mathematischer Programmierer
bei IBM
1970: A Relational Model of Data for Large
Shared Data Banks
Gestorben: 18.4.2003
• Das relationale Datenmodell wurde 1970
von Codd vorgeschlagen und ist seit Ende
der 80er Jahre der „Industriestandard“
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 2
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
aus Relationen
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
aus Relationen
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
a
c
d
1
1
4
z
y
x
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
Tabellenschema
DBT / Schwentick / SoSe 12
Mathematisch
Formal
Relationsschema
R
Einleitung 1. Grundbegriffe
1
1
4
z
y
x
Beispiel
(R,{A1 ,A2 ,A3 })
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
R
name(R)
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
R
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
R
name(R)
A
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
R
A2
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
R
name(R)
A
Dom(A)
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
R
A2
Dom(A2 ) = N
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
Spaltenüberschriften
Attributmenge
R
name(R)
A
Dom(A)
sort(R)
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
R
A2
Dom(A2 ) = N
{A1 ,A2 ,A3 }
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
Spaltenüberschriften
Attributmenge
Anzahl Spalten
Stelligkeit
R
name(R)
A
Dom(A)
sort(R)
arity(R)
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
R
A2
Dom(A2 ) = N
{A1 ,A2 ,A3 }
3
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
Spaltenüberschriften
Attributmenge
Anzahl Spalten
Stelligkeit
R
name(R)
A
Dom(A)
sort(R)
arity(R)
Zeile
R-Tupel
DBT / Schwentick / SoSe 12
R
A2
Dom(A2 ) = N
{A1 ,A2 ,A3 }
3
t : sort(R) → dom t1 = {A1 7→ a,
A 7→ 1, A3 7→
t(A) ∈ Dom(A) z} 2
Einleitung 1. Grundbegriffe
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
Spaltenüberschriften
Attributmenge
Anzahl Spalten
Stelligkeit
R
name(R)
A
Dom(A)
sort(R)
arity(R)
Zeile
R-Tupel
Tabelle
Tupelmenge
DBT / Schwentick / SoSe 12
R
A2
Dom(A2 ) = N
{A1 ,A2 ,A3 }
3
t : sort(R) → dom t1 = {A1 7→ a,
A 7→ 1, A3 7→
t(A) ∈ Dom(A) z} 2
R-Relation
{t1 ,t2 ,t3 }
Einleitung 1. Grundbegriffe
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
Intuitiv
1
1
4
z
y
x
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
Spaltenüberschriften
Attributmenge
Anzahl Spalten
Stelligkeit
R
name(R)
A
Dom(A)
sort(R)
arity(R)
Zeile
R-Tupel
Tabelle
Tupelmenge
Mögliche Tabellen
Menge aller
R-Relationen
DBT / Schwentick / SoSe 12
R
A2
Dom(A2 ) = N
{A1 ,A2 ,A3 }
3
t : sort(R) → dom t1 = {A1 7→ a,
A 7→ 1, A3 7→
t(A) ∈ Dom(A) z} 2
R-Relation
{t1 ,t2 ,t3 }
inst(R)
Einleitung 1. Grundbegriffe
. Folie 3
Relationales Modell: Tabellen vs. Relationen (1/2)
• Intuitiv bestehen relationale Datenbanken aus
Tabellen
• Aus mathematischer Sicht bestehen sie aber
R
A1 A2 A3
a
c
d
aus Relationen
• Notation: inst steht für „instances“
1
1
4
z
y
x
Dom für „domain“
Intuitiv
Mathematisch
Formal
Beispiel
Tabellenschema
Relationsschema
(R,{A1 ,A2 ,A3 })
Tabellenname
Relationsname
Spaltenüberschrift
Attribut
Mögliche Spaltenwerte
Wertebereich
Spaltenüberschriften
Attributmenge
Anzahl Spalten
Stelligkeit
R
name(R)
A
Dom(A)
sort(R)
arity(R)
Zeile
R-Tupel
Tabelle
Tupelmenge
Mögliche Tabellen
Menge aller
R-Relationen
DBT / Schwentick / SoSe 12
R
A2
Dom(A2 ) = N
{A1 ,A2 ,A3 }
3
t : sort(R) → dom t1 = {A1 7→ a,
A 7→ 1, A3 7→
t(A) ∈ Dom(A) z} 2
R-Relation
{t1 ,t2 ,t3 }
inst(R)
Einleitung 1. Grundbegriffe
. Folie 3
Relationales Modell: Tabellen vs. Relationen (2/2)
• Attribute:
◮ Ein Attribut A hat einen Namen A
und einen Wertebereich Dom(A)
◮ Wir unterscheiden (wie gerade eben)
◮
in der Notation nicht zwischen Attributen und ihren Namen
Wir nehmen eine unendliche Menge
att von Attributen als gegeben an
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 4
Relationales Modell: Tabellen vs. Relationen (2/2)
• Attribute:
◮ Ein Attribut A hat einen Namen A
und einen Wertebereich Dom(A)
◮ Wir unterscheiden (wie gerade eben)
◮
in der Notation nicht zwischen Attributen und ihren Namen
Wir nehmen eine unendliche Menge
att von Attributen als gegeben an
• Relationenschemata:
◮ Ein Relationenschema
R = (name(R),sort(R)) besteht
aus einem Relationennamen und einer
Menge von Attributen
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 4
Relationales Modell: Tabellen vs. Relationen (2/2)
• Attribute:
◮ Ein Attribut A hat einen Namen A
und einen Wertebereich Dom(A)
◮ Wir unterscheiden (wie gerade eben)
◮
in der Notation nicht zwischen Attributen und ihren Namen
Wir nehmen eine unendliche Menge
att von Attributen als gegeben an
• Relationenschemata:
◮ Ein Relationenschema
R = (name(R),sort(R)) besteht
aus einem Relationennamen und einer
Menge von Attributen
• Datenbankschemata:
◮ Ein Datenbankschema beschreibt die
◮
Struktur einer Datenbank
Ein Datenbankschema D ist (zunächst) einfach eine endliche Menge
von Relationenschemata
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 4
Relationales Modell: Tabellen vs. Relationen (2/2)
• Attribute:
◮ Ein Attribut A hat einen Namen A
und einen Wertebereich Dom(A)
◮ Wir unterscheiden (wie gerade eben)
◮
in der Notation nicht zwischen Attributen und ihren Namen
Wir nehmen eine unendliche Menge
att von Attributen als gegeben an
• Relationenschemata:
◮ Ein Relationenschema
R = (name(R),sort(R)) besteht
• Relationen:
◮ Anders als die Zeilen einer Tabelle sind die
Tupel einer Relation nicht geordnet!
• Datenbanken:
◮ Eine Datenbank zu Schema D hat eine
Relation je Relationsschema R ∈ D
◮ Eine Datenbank D zu Schema D
ist formal eine Abbildung von D in die
Menge der möglichen Relationen mit
D(R) ∈ inst(R), für jedes R ∈
D
aus einem Relationennamen und einer
Menge von Attributen
• Datenbankschemata:
◮ Ein Datenbankschema beschreibt die
◮
Struktur einer Datenbank
Ein Datenbankschema D ist (zunächst) einfach eine endliche Menge
von Relationenschemata
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 4
Relationales Modell: Tabellen vs. Relationen (2/2)
• Attribute:
◮ Ein Attribut A hat einen Namen A
und einen Wertebereich Dom(A)
◮ Wir unterscheiden (wie gerade eben)
◮
in der Notation nicht zwischen Attributen und ihren Namen
Wir nehmen eine unendliche Menge
att von Attributen als gegeben an
• Relationenschemata:
◮ Ein Relationenschema
R = (name(R),sort(R)) besteht
• Relationen:
◮ Anders als die Zeilen einer Tabelle sind die
Tupel einer Relation nicht geordnet!
• Datenbanken:
◮ Eine Datenbank zu Schema D hat eine
Relation je Relationsschema R ∈ D
◮ Eine Datenbank D zu Schema D
ist formal eine Abbildung von D in die
Menge der möglichen Relationen mit
D(R) ∈ inst(R), für jedes R ∈
D
aus einem Relationennamen und einer
Menge von Attributen
• Datenbankschemata:
◮ Ein Datenbankschema beschreibt die
◮
Struktur einer Datenbank
Ein Datenbankschema D ist (zunächst) einfach eine endliche Menge
von Relationenschemata
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 4
Relationales Modell: Tabellen vs. Relationen (2/2)
• Attribute:
◮ Ein Attribut A hat einen Namen A
und einen Wertebereich Dom(A)
◮ Wir unterscheiden (wie gerade eben)
◮
in der Notation nicht zwischen Attributen und ihren Namen
Wir nehmen eine unendliche Menge
att von Attributen als gegeben an
• Relationenschemata:
◮ Ein Relationenschema
R = (name(R),sort(R)) besteht
aus einem Relationennamen und einer
Menge von Attributen
• Datenbankschemata:
◮ Ein Datenbankschema beschreibt die
◮
• Relationen:
◮ Anders als die Zeilen einer Tabelle sind die
Tupel einer Relation nicht geordnet!
• Datenbanken:
◮ Eine Datenbank zu Schema D hat eine
Relation je Relationsschema R ∈ D
◮ Eine Datenbank D zu Schema D
ist formal eine Abbildung von D in die
Menge der möglichen Relationen mit
D(R) ∈ inst(R), für jedes R ∈
D
• Keine Angst: Ganz so formal wird es in dieser
Vorlesung nicht bleiben
➞ Aller Anfang ist schwer
◮ Wann immer möglich, werden wir uns auf
einer intuitiven Ebene bewegen...
Struktur einer Datenbank
Ein Datenbankschema D ist (zunächst) einfach eine endliche Menge
von Relationenschemata
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 4
Relationales Modell: Notation
• Um das Verständnis etwas zu erleichtern,
werden gleichartige Objekte in dieser Vorlesung möglichst durch gleichartige Bezeichner benannt
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 5
Relationales Modell: Notation
• Um das Verständnis etwas zu erleichtern,
werden gleichartige Objekte in dieser Vorlesung möglichst durch gleichartige Bezeichner benannt
• Einige allgemeine Konventionen:
◮ att: abzählbare Menge aller Attribute (geordnet)
◮ A,B,C : Attribute
◮ U,V,W : endliche Mengen von Attribu◮
ten
Abkürzende Schreibweise: ABC statt
{A,B,C}
◮ dom: abzählbare Menge aller Datenwerte
◮ a,b,c: Werte aus dom
◮ Dom(A): Wertebereich des Attributes
A
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 5
Relationales Modell: Notation
• Um das Verständnis etwas zu erleichtern,
werden gleichartige Objekte in dieser Vorlesung möglichst durch gleichartige Bezeichner benannt
• Einige allgemeine Konventionen:
◮ att: abzählbare Menge aller Attribute (geordnet)
◮ A,B,C : Attribute
◮ U,V,W : endliche Mengen von Attribu◮
ten
Abkürzende Schreibweise: ABC statt
• Weitere „statische“ Bezeichnungen:
◮ R: Relationenschema
◮ R,S : Relationsnamen
◮ sort(R), arity(R), name(R): Attributmenge, Stelligkeit und Name von R
◮ inst(R): Menge der Relationen zu
Schema R
◮ D : Datenbankschema
◮ inst(D): Menge der Datenbanken zu
Schema D
{A,B,C}
◮ dom: abzählbare Menge aller Datenwerte
◮ a,b,c: Werte aus dom
◮ Dom(A): Wertebereich des Attributes
A
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 5
Relationales Modell: Notation
• Um das Verständnis etwas zu erleichtern,
werden gleichartige Objekte in dieser Vorlesung möglichst durch gleichartige Bezeichner benannt
• Einige allgemeine Konventionen:
◮ att: abzählbare Menge aller Attribute (geordnet)
◮ A,B,C : Attribute
◮ U,V,W : endliche Mengen von Attribu◮
ten
Abkürzende Schreibweise: ABC statt
{A,B,C}
◮ dom: abzählbare Menge aller Datenwerte
◮ a,b,c: Werte aus dom
◮ Dom(A): Wertebereich des Attributes
A
DBT / Schwentick / SoSe 12
• Weitere „statische“ Bezeichnungen:
◮ R: Relationenschema
◮ R,S : Relationsnamen
◮ sort(R), arity(R), name(R): Attributmenge, Stelligkeit und Name von R
◮ inst(R): Menge der Relationen zu
Schema R
◮ D : Datenbankschema
◮ inst(D): Menge der Datenbanken zu
Schema D
• Weitere „dynamische“ Bezeichnungen:
◮ t,s: Tupel
◮ Abkürzung: t.A := t(A) für „Eintrag
in Zeile t und Spalte A“
◮ R,S : Relationen (aus dem Kontext klar,
◮
◮
ob Relationenname gemeint ist)
D : Datenbank
RD : Relation mit Namen R in Datenbank D
Einleitung 1. Grundbegriffe
. Folie 5
Unsere Beispieldatenbank
P ROFESSOREN
PersNr
Name
Raum
201
Turing
134
212
Gödel
27
238 von Neumann 212
213
Knuth
144
211
Chomsky
312
205
Shannon
213
202
Dijkstra
321
S TUDIERENDE
MatrNr
Name
Semester
21301
Wirth
6
22736
Pnueli
4
23195 Hartmanis
2
19216 Feigenbaum
12
22196
Yao
4
20894
Milner
8
23153
Blum
2
VORLESUNGEN
VorlNr
Titel
Dozent
2002 Rechnerarchitektur 238
2003 Verteilte Systeme 202
2021 Berechenbarkeit 201
2004 Informationstheorie 205
2012 Formale Sprachen 211
2019
Logik
212
2031 Programmierung 202
2025
KI
201
2006
Linguistik
211
2005 Quantenmechanik 238
M ITARBEITER
PersNr Name
Gebiet
Betreuer
4021 Sutherland Computergraphik
205
4033 Sedgewick
Algorithmen
213
4012
Gandy
Mengenlehre
201
4031 HabermannProgrammiersprachen 202
4029
Broder
Web Research
213
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
H ÖRT
MatrNrVorlNr
21301 2031
23195 2025
22736 2019
19216 2021
19216 2019
23153 2012
23195 2021
22196 2004
S ETZT VORAUS
VorlNrVorausNr
2025 2019
2021 2012
2003 2031
2031 2012
2003 2002
2006 2012
2012 2019
P RÜFT
MatrNrVorlNrPersNrNote
21301 2031 213
1
23195 2025 201
2
20894 2003 202
1
. Folie 6
Beispieldatenbank: Schemas
• DUni = {RP ROFESSOREN , RVORLESUNGEN , RH ÖRT ,
RS TUDIERENDE , RS ETZVORAUS , RM ITARBEITER , RP RÜFT }
• sort(RVORLESUNGEN ) = {VorlNr, Titel, Dozent}
• name(RVORLESUNGNEN ) = VORLESUNGEN
• arity(RVORLESUNGEN ) = 3
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 7
Inhalt
1.1 Das relationale Datenmodell
1.2 Anfragen an relationale Datenbanken
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 8
Anfragen: Beispiele
(1) Welche Zimmernummer hat Turing?
(2) Welcher Mitarbeiter ist auf Mengenlehre
spezialisiert?
(9) Welche Personen sind an Prüfungen in
Programmierung beteiligt (Prüfer und Prüflinge)?
(3) Welche Vorlesungen (Nr und Titel) bietet
Chomsky an?
(10) Wer bietet keine Vorlesungen an?
(4) Gibt es eine Vorlesung über Logik?
(12) Wer prüft Vorlesungen, die er nicht
liest?
(5) Welche zwei Professoren prüfen jeweils
Vorlesungen, die der andere liest?
(11) Wer bietet genau eine Vorlesung an?
(13) Wer hört mehr als eine Vorlesung?
(6) Je zwei Studierende, die dieselbe Vorlesung besuchen?
(14) Wer wird von einem Prüfer geprüft, der
keine Vorlesungen anbietet?
(7) Welche Vorlesungen werden von
Shannon oder Dijkstra angeboten?
(15) Welche Veranstaltungen sind (direkte oder indirekt) Voraussetzung für
Verteilte Systeme?
(8) Welche Vorlesungen werden von Dijkstra
angeboten oder geprüft?
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 9
Anfragen und Anfragefunktionen
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
D
R = q(D)
q
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
D
R = q(D)
q
• Eine Anfrage ist die Spezifikation einer
Anfragefunktion, meistens in der Form eines Strings
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
Beispiel
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
D
• SELECT
Raum
FROM
P ROFESSOREN
WHERE
Name = „Turing“
ist eine Anfrage in SQL
R = q(D)
q
• Eine Anfrage ist die Spezifikation einer
Anfragefunktion, meistens in der Form eines Strings
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
Beispiel
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
D
R = q(D)
• SELECT
•
Raum
FROM
P ROFESSOREN
WHERE
Name = „Turing“
ist eine Anfrage in SQL
Die durch diese Anfrage spezifizierte Anfragefunktion ordnet jeder Datenbank mit
einer Relation P ROFESSOREN die Menge
der Werte der Raum-Attribute aller Tupel
zu, deren Name-Attribut den Wert Turing
hat...
q
• Eine Anfrage ist die Spezifikation einer
Anfragefunktion, meistens in der Form eines Strings
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
Beispiel
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
D
• SELECT
•
R = q(D)
q
•
Raum
FROM
P ROFESSOREN
WHERE
Name = „Turing“
ist eine Anfrage in SQL
Die durch diese Anfrage spezifizierte Anfragefunktion ordnet jeder Datenbank mit
einer Relation P ROFESSOREN die Menge
der Werte der Raum-Attribute aller Tupel
zu, deren Name-Attribut den Wert Turing
hat...
In unserer Beispieldatenbank ist das
Anfrage-Ergebnis also {134}
• Eine Anfrage ist die Spezifikation einer
Anfragefunktion, meistens in der Form eines Strings
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 10
Anfragen und Anfragefunktionen
Beispiel
• Streng genommen müssen wir zwischen
den Begriffen Anfrage und Anfragefunktion unterscheiden:
◮ Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu
◮ Formaler: Eine Anfragefunktion ist eine
Abbildung, die, für ein Datenbankschema
D und ein Relationenschema R, jeder
Datenbank D über D eine Relation R
über R zuordnet
D
• SELECT
•
R = q(D)
q
•
Raum
FROM
P ROFESSOREN
WHERE
Name = „Turing“
ist eine Anfrage in SQL
Die durch diese Anfrage spezifizierte Anfragefunktion ordnet jeder Datenbank mit
einer Relation P ROFESSOREN die Menge
der Werte der Raum-Attribute aller Tupel
zu, deren Name-Attribut den Wert Turing
hat...
In unserer Beispieldatenbank ist das
Anfrage-Ergebnis also {134}
• Obwohl die prinzipielle Unterscheidung zwi• Eine Anfrage ist die Spezifikation einer
Anfragefunktion, meistens in der Form eines Strings
DBT / Schwentick / SoSe 12
schen Anfrage und Anfragefunktion wichtig ist, werden wir sprachlich meistens von
ihr absehen:
◮ Meistens verwenden wir die Bezeichnung
Anfrage für beides!
Einleitung 1. Grundbegriffe
. Folie 10
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
• Wegen des Tupels h201,Turing,134i ist das Ergebnis für die Beispiel-DB {134}
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
• Wegen des Tupels h201,Turing,134i ist das Ergebnis für die Beispiel-DB {134}
• Wenn wir 134 in diesem Tupel durch 205 ersetzen, wie soll sich das Ergebnis ändern?
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
• Wegen des Tupels h201,Turing,134i ist das Ergebnis für die Beispiel-DB {134}
• Wenn wir 134 in diesem Tupel durch 205 ersetzen, wie soll sich das Ergebnis ändern?
• Wenn wir Turing in diesem Tupel durch Kleene
ersetzen, wie soll sich das Ergebnis ändern?
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
• Wegen des Tupels h201,Turing,134i ist das Ergebnis für die Beispiel-DB {134}
• Wenn wir 134 in diesem Tupel durch 205 ersetzen, wie soll sich das Ergebnis ändern?
• Wenn wir Turing in diesem Tupel durch Kleene
ersetzen, wie soll sich das Ergebnis ändern?
• Was lernen wir daraus?
◮ Wenn sich die Datenwerte einer DB ändern,
sollen sich die Ergebnisse einer Anfrage „entsprechend“ ändern
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
• Wegen des Tupels h201,Turing,134i ist das Ergebnis für die Beispiel-DB {134}
• Wenn wir 134 in diesem Tupel durch 205 ersetzen, wie soll sich das Ergebnis ändern?
• Wenn wir Turing in diesem Tupel durch Kleene
ersetzen, wie soll sich das Ergebnis ändern?
• Was lernen wir daraus?
◮ Wenn sich die Datenwerte einer DB ändern,
◮
sollen sich die Ergebnisse einer Anfrage „entsprechend“ ändern
Ausnahme: Explizite Vorkommen von Werten
in der Anfrage sollen bei der Auswertung nicht
als geändert interpretiert werden
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (1/2)
Beispiel
• Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern
die folgenden Eigenschaften haben:
(a) Das Ergebnis sollte nicht von Details der Speicherung abhängen
sondern nur von der logischen
Sicht:
◮ q ist Funktion
inst(D) → inst(R)
(b) Anfragefunktionen sollten durch
Computer ausgewertet werden
können:
◮ q ist berechenbar
(c) Das Ergebnis sollte möglichst nur
von der Struktur der Datenbank
abhängen, aber nicht so sehr von
den einzelnen Werten:
◮ Hierzu betrachten wir zunächst
ein Beispiel
DBT / Schwentick / SoSe 12
• Wir betrachten noch einmal die folgende Anfrage:
(1) Welche Zimmernummer hat Turing?
• Wegen des Tupels h201,Turing,134i ist das Ergebnis für die Beispiel-DB {134}
• Wenn wir 134 in diesem Tupel durch 205 ersetzen, wie soll sich das Ergebnis ändern?
• Wenn wir Turing in diesem Tupel durch Kleene
ersetzen, wie soll sich das Ergebnis ändern?
• Was lernen wir daraus?
◮ Wenn sich die Datenwerte einer DB ändern,
◮
sollen sich die Ergebnisse einer Anfrage „entsprechend“ ändern
Ausnahme: Explizite Vorkommen von Werten
in der Anfrage sollen bei der Auswertung nicht
als geändert interpretiert werden
➞ Eigenschaft (c): g ist generisch
Einleitung 1. Grundbegriffe
. Folie 11
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
Definition
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
Definition
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
• Illustration:
q
D
q(D)
π
π
π(D)
q
q(π(D)) = π(q(D))
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
Definition
• Wenn in einer Anfrage Konstanten vorkommen (wie in
Anfrage (1)) ist diese Definition zu einschränkend:
◮ Permutation, die in der DB Turing verändern, wollen wir dann nicht betrachten
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
• Illustration:
q
D
q(D)
π
π
π(D)
q
q(π(D)) = π(q(D))
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
Definition
• Wenn in einer Anfrage Konstanten vorkommen (wie in
Anfrage (1)) ist diese Definition zu einschränkend:
◮ Permutation, die in der DB Turing verändern, wollen wir dann nicht betrachten
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
• Illustration:
q
D
Definition
• Sei C ⊆ dom eine endliche Menge
• Eine Anfragefunktion q heißt C -generisch, falls
◮ für jede Datenbank D und
◮ jede Permutation π von dom
(mit π(x) = x für x ∈ C )
gilt: π(q(D)) = q(π(D))
q(D)
π
π
π(D)
q
q(π(D)) = π(q(D))
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
Definition
• Wenn in einer Anfrage Konstanten vorkommen (wie in
Anfrage (1)) ist diese Definition zu einschränkend:
◮ Permutation, die in der DB Turing verändern, wollen wir dann nicht betrachten
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
• Illustration:
q
D
Definition
• Sei C ⊆ dom eine endliche Menge
• Eine Anfragefunktion q heißt C -generisch, falls
◮ für jede Datenbank D und
◮ jede Permutation π von dom
(mit π(x) = x für x ∈ C )
gilt: π(q(D)) = q(π(D))
q(D)
• Anfrage (1) ist also {Turing}-generisch
π
π
π(D)
q
q(π(D)) = π(q(D))
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
Anfragefunktionen jetzt formal
Definition
• Wenn in einer Anfrage Konstanten vorkommen (wie in
Anfrage (1)) ist diese Definition zu einschränkend:
◮ Permutation, die in der DB Turing verändern, wollen wir dann nicht betrachten
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
• Illustration:
q
D
π
π(D)
• Sei C ⊆ dom eine endliche Menge
• Eine Anfragefunktion q heißt C -generisch, falls
◮ für jede Datenbank D und
◮ jede Permutation π von dom
(mit π(x) = x für x ∈ C )
gilt: π(q(D)) = q(π(D))
q(D)
π
q
Definition
q(π(D)) = π(q(D))
DBT / Schwentick / SoSe 12
• Anfrage (1) ist also {Turing}-generisch
• Wir betrachten nur C -generische Anfragefunktionen
q , wobei C jeweils die Menge derjenigen Konstanten ist, die in der Spezifikation von q explizit genannt
werden
Einleitung 1. Grundbegriffe
. Folie 12
Anfragefunktionen: Eigenschaften (2/2)
• Wir definieren Eigenschaft (c) von
• Wenn in einer Anfrage Konstanten vorkommen (wie in
Anfrage (1)) ist diese Definition zu einschränkend:
◮ Permutation, die in der DB Turing verändern, wollen wir dann nicht betrachten
Anfragefunktionen jetzt formal
Definition
• Eine Anfragefunktion q heißt generisch, falls für jede Datenbank
D und jede Permutation π von
dom gilt:
π(q(D)) = q(π(D))
• Illustration:
q
D
π
π(D)
• Sei C ⊆ dom eine endliche Menge
• Eine Anfragefunktion q heißt C -generisch, falls
◮ für jede Datenbank D und
◮ jede Permutation π von dom
(mit π(x) = x für x ∈ C )
gilt: π(q(D)) = q(π(D))
q(D)
π
q
Definition
q(π(D)) = π(q(D))
• Anfrage (1) ist also {Turing}-generisch
• Wir betrachten nur C -generische Anfragefunktionen
q , wobei C jeweils die Menge derjenigen Konstanten ist, die in der Spezifikation von q explizit genannt
•
DBT / Schwentick / SoSe 12
werden
Zur Beruhigung: Alle Anfragesprachen, die wir betrachten, können nur Anfragen beschreiben, die die
Generizitäts-Eigenschaft (c) haben
Einleitung 1. Grundbegriffe
. Folie 12
„ja“/„nein“-Anfragen
• Manche Anfragen lassen sich nur mit „ja“ oder „nein“
beantworten:
◮ Beispiel: (4) Gibt es eine Vorlesung über Logik?
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 13
„ja“/„nein“-Anfragen
• Manche Anfragen lassen sich nur mit „ja“ oder „nein“
beantworten:
◮ Beispiel: (4) Gibt es eine Vorlesung über Logik?
• Wie passen solche Anfragen in unseren allgemeinen
Rahmen, der immer Relationen als Anfrageergebnisse vorsieht?
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 13
„ja“/„nein“-Anfragen
• Manche Anfragen lassen sich nur mit „ja“ oder „nein“
beantworten:
◮ Beispiel: (4) Gibt es eine Vorlesung über Logik?
• Wie passen solche Anfragen in unseren allgemeinen
Rahmen, der immer Relationen als Anfrageergebnisse vorsieht?
• Da „ja“/„nein“-Anfragen keine Datenwerte im Ergebnis haben, ist es nahe liegend, dass ihr Resultat 0stellige Relationen sind
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 13
„ja“/„nein“-Anfragen
• Manche Anfragen lassen sich nur mit „ja“ oder „nein“
beantworten:
◮ Beispiel: (4) Gibt es eine Vorlesung über Logik?
• Wie passen solche Anfragen in unseren allgemeinen
Rahmen, der immer Relationen als Anfrageergebnisse vorsieht?
• Da „ja“/„nein“-Anfragen keine Datenwerte im Ergebnis haben, ist es nahe liegend, dass ihr Resultat 0stellige Relationen sind
• Es gibt zwei 0-stellige Relationen: {} und {hi}
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 13
„ja“/„nein“-Anfragen
• Manche Anfragen lassen sich nur mit „ja“ oder „nein“
beantworten:
◮ Beispiel: (4) Gibt es eine Vorlesung über Logik?
• Wie passen solche Anfragen in unseren allgemeinen
Rahmen, der immer Relationen als Anfrageergebnisse vorsieht?
• Da „ja“/„nein“-Anfragen keine Datenwerte im Ergebnis haben, ist es nahe liegend, dass ihr Resultat 0stellige Relationen sind
• Es gibt zwei 0-stellige Relationen: {} und {hi}
• Konvention:
◮ {hi} ≡ „ja“
◮ {} ≡ „nein“
(Eine mathematische Rechtfertigung für diese Konvention werden wir noch kennen lernen)
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 13
Anfragesprachen
• Dieselbe Anfragefunktion kann in verschiedenen Anfragesprachen beschrieben werden
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 14
Anfragesprachen
• Dieselbe Anfragefunktion kann in verschiedenen Anfragesprachen beschrieben werden
Beispiel
SQL:
SELECT Raum
FROM
P ROFESSOREN
WHERE Name = „Turing“
Relationale Algebra:
πRaum (σName=„Turing“ (P ROFESSOREN))
Datalog:
R ESULT(x) :- P ROFESSOREN(y,„Turing“,x)
Relationen-Kalkül:
{(x) | ∃y P ROFESSOREN(y,„Turing“,x)}
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 14
Anfragesprachen
• Dieselbe Anfragefunktion kann in verschiedenen Anfragesprachen beschrieben werden
Beispiel
SQL:
SELECT Raum
FROM
P ROFESSOREN
WHERE Name = „Turing“
Relationale Algebra:
πRaum (σName=„Turing“ (P ROFESSOREN))
Datalog:
R ESULT(x) :- P ROFESSOREN(y,„Turing“,x)
Relationen-Kalkül:
{(x) | ∃y P ROFESSOREN(y,„Turing“,x)}
• Bemerkung: Anfragesprachen unterscheiden sich hinsichtlich ihrer Ausdrucksstärke
und hinsichtlich ihrer algorithmischen Eigenschaften
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 14
Anfragesprachen
• Dieselbe Anfragefunktion kann in verschiedenen Anfragesprachen beschrieben werden
• Hierarchie der betrachteten Anfragesprachen:
Datalog¬
Beispiel
SQL:
SELECT Raum
FROM
P ROFESSOREN
WHERE Name = „Turing“
+ Rekursion
+ Negation
Datalog
Relational vollständige
Sprachen
+ Rekursion
Relationale Algebra:
+ Negation
πRaum (σName=„Turing“ (P ROFESSOREN))
Datalog:
R ESULT(x) :- P ROFESSOREN(y,„Turing“,x)
Relationen-Kalkül:
{(x) | ∃y P ROFESSOREN(y,„Turing“,x)}
• Bemerkung: Anfragesprachen unterschei-
Rekursions-freies
Datalog
+ Disjunktion
Und-Anfragen
den sich hinsichtlich ihrer Ausdrucksstärke
und hinsichtlich ihrer algorithmischen Eigenschaften
DBT / Schwentick / SoSe 12
Einleitung 1. Grundbegriffe
. Folie 14