Grundvorlesung Informationssysteme

Inhaltsverzeichnis
Teil I: Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Grundvorlesung Informationssysteme
1 Modelle und Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1 Überblick: Thema der Vorlesung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Aufgaben eines Informationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Beispiele für Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Grundformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
große Mengen von Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
dauerhaft verfügbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
verlässlich verfügbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Verlässlichkeit umfasst insbesondere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
für viele und verschiedenartige Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Verwaltung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
verschiedenartige Blickwinkel auf ein Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
weitreichendster Blickwinkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Joachim Biskup
ISSI - Informationssysteme und Sicherheit
Universität Dortmund
1.2 Information und Kommunikation: Vermittlung durch Informationssysteme . . . . .35
Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
eine wahrscheinlichkeitstheoretische Sicht von Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
eine modelltheoretische Sicht von Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
© Joachim Biskup, Universität Dortmund
Informationssysteme
17. Juli 2003
1
Beispiel für Information und Informationsübertragung bei logischer Programmierung . . . . . . . . . . . . . 39
Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Kommunikation als eine Handlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Grundzüge menschlichen Handelns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
kommunikatives Handeln (nach Habermas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Veranschaulichung kommunikativ Handelnder mit Weltbezügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Geltungsansprüche und Begründungen beim kommunikativen Handeln . . . . . . . . . . . . . . . . . . . . . . . . 46
Rückbezüglichkeit und Offenheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Unterstützung durch ein Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Soziale Systeme (nach Luhmann) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Unterstützung durch ein Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Gestaltung von Informationssystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Benutzerrahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Vermittlung von Kommunikation durch ein Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
‘‘formales Kommunikationsverhalten’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Kommunikation und Mensch-Rechner-Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Interaktion und Protokollausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Vermittlung durch ein Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
17. Juli 2003
17. Juli 2003
2
1.4 Formalisierung: Logik und Mengenlehre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Prädikatenlogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Prädikatenlogik und ER-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Mengenlehre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Logik und Informationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
1.5 Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Programmieren? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Programmieren: Modellieren und Formalisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Wirklichkeit - Begriffsraum - Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Begriffsgerüst der Entity-Relationship Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
statische Gesichtspunkte eines Unternehmens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
typische Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Informationssysteme: Inhaltsverzeichnis
Informationssysteme: Inhaltsverzeichnis
typische Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
dynamische Gesichtspunkte eines Unternehmens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
zeitabhängige und zeitunabhängige Teile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Schema und Instanz, ‘‘Ontologie’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ER-Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Regeln und Regelgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Beispiel für ER-Modellierung: Seiendenklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Beispiel für ER-Modellierung: Beziehungenklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Beispiel für ER-Modellierung: Beziehungenklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Beispiel für ER-Modellierung: Aggregation und Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Beispiel für ER-Modellierung: Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Beispiel für ER-Modellierung: Klassen mit Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
1.3 Modellierung: Wirklichkeit und Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
© Joachim Biskup, Universität Dortmund
© Joachim Biskup, Universität Dortmund
Architektur eines Informationssystems: Grobstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Anwendungsumgebungen für ein Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Entwurfsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Arbeitsplatzumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Programmierumgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
4
2.1 relationale Strukturen: Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Netzwerkumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Informationssystem-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Schichtung und Komponenten eines Informationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
konzeptionelle Schicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
interne Schicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Datenwörterbuch (data dictionary) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Inhalte des Datenwörterbuchs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Zugriffe auf Datenwörterbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Transaktionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Basissystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Architektur: benutzersichtbarer Teil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Architektur: ‘‘eigentliches Informationssystem’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Architektur: Basissystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
föderierte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
mediierte Syteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
föderiert versus mediiert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Semantische Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Schreibweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Relationenschema und Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Relationales Datenbankschema und Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Beispiel: (vereinfachte) Arztpraxis als ER-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Beispiel: (vereinfachte) Arztpraxis als Hypergraph des Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Beispiel: (vereinfachte) Arztpraxis als Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Beispiel: Tabellengerüste zum relationalen Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Beispiel: eine Instanz zum relationalen Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
2.2 relationale Meta-Strukturen: Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Schema als Selbstbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
(vereinfachtes) ‘‘Metaschema’’ für relationale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Hypergraph zum relationalen Datenbankschema für Schemas (“Metaschema’’) . . . . . . . . . . . . . . . . 126
Beispiel: Instanz zum relationalen Datenbankschema für Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2.3 relationale Strukturen: Pragmatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Teil II: relationale Systeme mit strukturierten Daten . . . . . . . . . . . . . . 108
2.4 relationale Strukturen: Praxis (Oracle-SQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
ER-Diagramm für Präsidenten-Datenbank (Ausschnitt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Hypergraph zum Oracle-Schema für Präsidenten-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Oracle-Schema für Präsidenten-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
einige syntaktische Regeln für Oracle-SQL-Schemavereinbarungen . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Oracle-SQL Syntax für “CREATE TABLE’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2 Relationales Datenmodell: Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
relationales Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
5
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
3 Relationales Datenmodell: Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.2 relationale Anfrageoperationen: Pragmatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
relationales Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Formalisierung von Anfragen (grobes ‘‘Kochrezept’’) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Hypergraph für Beispiel ‘‘Arztpraxis’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Instanz für Beispiel ‘‘Arztpraxis’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Anfrage: ‘‘Bestimme für Kind theresia ihr Geschlecht und ihre Eltern!” . . . . . . . . . . . . . . . . . . . . 169
Anfrage: “Bestimme alle Ärzte, die weibliche Patienten behandeln!” . . . . . . . . . . . . . . . . . . . . . . . . . 170
Anfrage: “Für welche Patienten wurden alle medizintechnischen Möglichkeiten ausgenutzt?” . . . . . . 172
3.1 relationale Anfrageoperationen: Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Operationen der relationalen Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
natürlicher Verbund (natural join) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
einfacher Algorithmus für natürlichen Verbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Spezialfälle des natürlichen Verbunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
A=c-Selektion (A=c-selection) als abgeleitete Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
algebraische Eigenschaften des natürlichen Verbunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Projektion und q-Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
einfacher Algorithmus für Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Projektion und natürlicher Verbund (als eine Art ‘‘Quasi-Inverse’’) . . . . . . . . . . . . . . . . . . . . . . . . . . 152
eine “verlustbehaftete” Zerlegung (lossy join) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
ein hängendes Tupel (dangling tuple) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Teilverbund (semijoin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Projektion und andere Operationen (optimierende Umformungen) . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Vereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
grundlegende Eigenschaften der Vereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
A=B-Vergleich und A≠B-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Komplement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Differenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
grundlegende Eigenschaften der Differenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
grundlegende Eigenschaften der Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
6
3.3 relationale Anfrageoperationen: Vorgriff auf Praxis (Oracle-SQL) . . . . . . . . . . . .174
4 Relationale Anfragesprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
relationale Anfragen: anschaulich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
relationale Anfragen: formale Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
relationale Anfragesprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Beispiel für relationale Anfragesprache: Relationenalgebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Beweisidee für grundlegende Aussage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Mächtigkeit der Relationenalgebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Beweis von “⇒’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Beweisidee für ‘‘⇐’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Beispiel für relationale Anfragesprache: Relationenkalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Beispiele für relationale Formeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Gleichmächtigkeit von Algebra und Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Behauptung 1: Kalkül in Algebra äquivalent übersetzbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Behauptung 2: Algebra in Kalkül äquivalent übersetzbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Beispiel für Konstruktion von (πq(Φ))* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Beispiel für Übersetzung ‘‘Algebra in Kalkül’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
7
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
8
Zusammenfassung: Relationenalgebra und logische Verknüpfungen . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Teil III: erweiterte und alternative Systeme . . . . . . . . . . . . . . . . . . . . . . 235
5 Structured Query Language - SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6 Relationales Datenmodell und Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
relationale Anfragen und relationale Anfragesprachen (Zusammenfassung) . . . . . . . . . . . . . . . . . . . . 204
6.1 relationales Datenmodell: Rückblick und Würdigung . . . . . . . . . . . . . . . . . . . . . . . .236
5.1 Kern von Structured Query Language (SQL): Theorie . . . . . . . . . . . . . . . . . . . . . . .205
einige Eigenschaften des relationalen Datenmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
relationales Datenmodell und mögliche Varianten, Erweiterungen, Verallgemeinerungen . . . . . . . . . 242
Structured Query Language, SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Ansatz für Grundform des Kalkülteils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Ansatz beschreibt Dreischrittverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
einige Vereinfachungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
(stark vereinfachte, abstrakte) Syntax der Kalkülteile von SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
(vereinfachte, abstrakte) Syntax des algebraischen Teils von SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Übersicht über Sprachmittel von SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
natürlicher Verbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
A=c-Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Vereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
A=B-Vergleich und A≠B-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Differenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.2 relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen .243
Eigenschaften als Ausgangspunkt für weitergehende Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7 Erweiterte Navigationsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Navigation in Schema und Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Navigation im relationalen Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
7.1 erweiterte Navigation durch Horn-Formeln als Anfragen . . . . . . . . . . . . . . . . . . . .266
Ansatz für beweistheoretische Deutung der Strukturen des relationalen Datenmodells . . . . . . . . . . . . 267
Schreib- und Redeweisen für Horn-Formeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
erweiterte Operationen mit beweistheoretischer Deutung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Ansatz für formale Definition der deklarativen Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Grundfakten-Transformation als Grundbaustein für operationale Fixpunktsemantik . . . . . . . . . . . . . . 273
Grundfakten-Transformation und Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Beispiel für iterierte Anwendung der Grundfakten-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Fixpunktsatz für Grundfakten-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
operationale Fixpunktsemantik von LOGODAT-Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
5.2 Structured Query Language (SQL): Praxis mit Oracle . . . . . . . . . . . . . . . . . . . . . . .224
Oracle-SQL Syntax für “SELECT’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
9
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
Auswertung von LOGODAT-Anfragen: grober Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
einfaches Beispiel für naive Auswertung: transitive Hülle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Beispiel für Document Type Definition (DTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
einige Sprachelemente für DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
7.2 erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle .285
9 Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Beispiel: eine Modellierung mit objektorientierter Formalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
objektorientierte Formalisierung eines Patienten namens Maria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Regeln mit Dereferenzierungen in F-Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Veranschaulichung der Horn-Klausel für wert_relationBEH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
9.1 Aufgaben, Anforderungen und Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
die Information Retrieval Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
das Such-Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Ostereiersuchen im Wald . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
die Stecknadeln im Heuhaufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
eine einfache Modellierung von Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Qualitätsbeurteilung bezüglich (im Allgemeinen fiktiver) Relevanz . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Recall-Precision-Paare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Beispiel für Recall-Precision Paare bei Rang-sortierter Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
8 Datenmodelle für halb-strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
strukturierte versus halb-strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
einige Anforderungen an Datenmodelle für halb-strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Beispiel: OEM (Object Exchange Model) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Aufbau elementarer OEM-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
graphische Veranschaulichung und textuelle Schreibweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
ein Geflecht in textueller Schreibweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
baumartige Geflechte für . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Grundform von OEM-Anfragen: Syntax und beabsichtigte Semantik . . . . . . . . . . . . . . . . . . . . . . . . . 304
mengenorientiertes, zusammengesetztes Rückgabe-Objekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Definition von OEM-Pfaden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Syntax in BNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Joker (wildcards) in Pfadausdrücken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Variablen in Pfadausdrücken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Rückgabe von Objekt-Identifikatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Beispiel: XML (Extensible Markup Language) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Beispiel für XML Dokument (ohne Kopf, mit “Einheitstyp”) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
10
9.2 einige grundlegende Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Merkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
hierarchische Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
flaches Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Thesaurus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
9.3 Modelle für Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Modelle mit Merkmals-Vektoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
ein (stark vereinfachtes) wahrscheinlichkeitstheoretisches Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
11
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
12
Teil IV: Effizienz (in relationalen Systemen) . . . . . . . . . . . . . . . . . . . . . 342
Verfahren für NestedLoop mit Blockliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Aufwand von NestedLoop mit Blockliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Sortiertes Mischen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Verfahren für Sortiertes Mischen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Beispiel für Sortiertes Mischen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Aufwand vom Sortierten Mischen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Link-Verbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Veranschaulichung der (vereinfachten) Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Operationen auf den Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Aufwand von Link-Verbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Hash-Filter-Verbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Verfahren des Hash-Filter-Verbunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Beispiel für Hash-Filter-Verbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Aufwand des Hash-Filter-Verbunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Zusammenfassung der Verbund-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
10 Zugriffsstrukturen und Verbund-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . 343
10.1 Anforderungen an die interne Schicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Verwirklichung der grundlegenden relationalen Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Dauerhaftigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Bestimmung von Adressen aus Tupelidentifikatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Effizienz für Anfragen und Änderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
10.2 Zugriffsstrukturen zur Steigerung der Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . .348
Zugriffsstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
B*-Baum als Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Beispiel für einen B*-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
schrittweiser Aufbau des Beispiels, Einfügungen a-e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
schrittweiser Aufbau des Beispiels, Einfügungen f-g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Index bezüglich eines Nichtschlüsselattributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Beispiel: gemeinsamer B*-Baum für mitglied und entfernung . . . . . . . . . . . . . . . . . . . . . . . . 356
11 Anfrage-Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Optimierung von Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Optimierungsaufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Optimierung: besonders wichtig und besonders schwierig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Beispiel: “naive Auswertungen” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Beispiel: verbesserte Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Beispiel: günstiger Fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Beispiel: Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Ziel der Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Methoden der Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Grundlagen der Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
10.3 Verbund-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358
Verbund: Definition und Nested-Loop (Wiederholung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Hauptaufgabe jeder Verwirklichung des natürlichen Verbunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Grundverwirklichung - NestedLoop mit Blockliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Veranschaulichung der (vereinfachten) Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Operationen auf den Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
13
Schemaentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Entwurfsheuristiken für relationale Formalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Theorie des relationalen Schemaentwurfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
12.1 funktionale Abhängigkeiten und Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412
funktionale Abhängigkeiten: Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
funktionale Abhängigkeiten: Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
funktionale Abhängigkeiten: Pragmatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
logische Implikationen für funktionale Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Reflexivität, Transitivität und Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Satz über die Korrektheit des Entscheidungsverfahrens für das Implikationsproblem . . . . . . . . . . . . . 418
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
formale Definition von “Schlüssel” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Relationenschemas mit genau einem Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
17. Juli 2003
17. Juli 2003
14
3. Normalform und Boyce / Codd-Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Relationenschemas in Boyce / Codd-Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Kostenarten beim Betreiben einer Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Kosten und Normalformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Überlegung zur Redundanzfreiheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Instanzenunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Instanzenunterstützung und Anfrageübersetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Verbundabhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Verbund-Unterstützung eines Universalrelation-Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Verbund-Unterstützung eines Universalrelation-Schemas mit funktionalen Abhängigkeiten . . . . . . . 439
Verbund-unterstützte Zerlegung in Boyce / Codd-Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Beispiel für Zerlegung in Boyce / Codd-Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Boyce / Codd-Normalform und treue Unterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
treue Zerlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
treue Verbund-Unterstützung eines Universalrelation-Schemas mit funktionalen Abhängigkeiten . . . 446
treue und Verbund-unterstützende Synthese in 3.Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Syntheseverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Beispiel für Syntheseverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
12 relationaler Schemaentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Informationssysteme: Inhaltsverzeichnis
Informationssysteme: Inhaltsverzeichnis
12.2 Normalformen und Schema-Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . .427
einige Heuristiken zur Optimierung relationaler Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Zusammenfassen von Ausdrücken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Entfernen von Redundanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Vorziehen von Selektionen und Projektionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Auswahl von Verbund-Reihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Entfernen von Redundanz logik-orientiert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Lemma [äquivalente Umformungen von Anfragen] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Redundanz von Anfrageklauseln oder Prämissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Aufwandsschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Beispiel für Aufwandsschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
© Joachim Biskup, Universität Dortmund
© Joachim Biskup, Universität Dortmund
Teil V: Mehrbenutzerbetrieb und Transaktionen . . . . . . . . . . . . . . . . . 450
13 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Transaktionen: einige Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Parallelität und Unabhängigkeit: ein Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
15
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
16
eine parallele Nutzung eines gemeinsamen Informationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
eine unerwünschte sequentielle Ausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
eine weitere Vorüberlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
ACID- Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Transaktionen erhalten Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Datenebenen und Wirksamwerden: einfachstes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Beispiele mit Bearbeitung von zwei Objekten/Folgeänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Transaktionen laufen parallel und voneinander unabhängig ab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
zwei Randfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
korrekte Reihenfolgen und Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Anweisungen, Transaktionen, Pläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Schreibweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Plan P zu Transaktionen T = { t1, t2, t3, t4 } mit “Datenflüssen” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Read/Write-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Read/Write-Modell: Annahme A1*/A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Read/Write-Modell: Annahme A3* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Read/Write-Modell: Annahme A4/A5/A6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Read/Write-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Satz über Test für Konflikt-Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Beispiel zum Test: Transaktionen und Konflikte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Beispiel zum Test: Plan und Konfliktgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Satz über Test für Konflikt-Serialisierbarkeits: Beweis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Satz über Test für Konflikt-Serialisierbarkeits: Beweis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
14.2 Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483
Abbruch, Wirksamwerden und Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
absichtlicher Abbruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
absichtlicher Abbruch: zukünftige Leseanweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
absichtlicher Abbruch: vorangegangene Leseanweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
ein Ansatz zur Vermeidung von Folgeabbrüchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Versionsverwaltung: einige Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Versionsfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
15 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
vereinfachtes Modell eines Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Konfliktgraphen-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Sperrprotokoll-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
beabsichtigte Semantik von Sperren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Verträglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Sperrprotokoll-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Konflikt-Serialisierbarkeit unter dem Zwei-Phasen-Sperrprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Sperrprotokoll-Scheduler verlangt Zwei-Phasen-Sperrprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Verklemmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Striktes Sperrverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
14 Serialisierbarkeit und Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
14.1 Konflikte und Konflikt-Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474
Konflikte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Aufgaben zur Konfliktbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Konflikt-Äquivalenz von Read/Write-Plänen, Konflikt-Serialisierbarkeit . . . . . . . . . . . . . . . . . . . . . . 476
Konfliktgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
17
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
Zeitmarken-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Zeitmarken-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Beispiel für Zeitmarken-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Konflikt-Serialisierbarkeit unter dem Zeitmarken-Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
nutzlose Schreibanweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Unvergleichbarkeit von Zwei-Phasen-Sperrprotokoll und Zeitmarken-Scheduler . . . . . . . . . . . . . . . . 512
pessimistische und optimistische Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
17. Juli 2003
18
17. Juli 2003
20
Teil I
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Grundlagen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Inhaltsverzeichnis
17. Juli 2003
19
© Joachim Biskup, Universität Dortmund
Informationssysteme
•
Grundlagen
01 Information/Kommunikation/Modellierung/Datenmodelle/Architekturen
•
1 Modelle und Architekturen
relationale Systeme mit strukturierten Daten
02
03
04
05
1.1 Überblick: Thema der Vorlesung
•
erweiterte und alternative Systeme
06
07
08
09
•
relationales Datenmodell/Beispiel Oracle-SQL/Schema und Instanz
relationale Operatoren
relationale Anfragesprachen, Relationenalgebra, Relationenkakül, Äquivalenz
Kern von SQL, Oracle-SQL-Datenmanipulationssprache
relationales Datenmodell: Würdigung, Varianten, Erweiterungen, Verallgemeinerungen
erweiterte Navigationsmöglichkeiten, Horn-Formeln und Dereferenzierungen
halb-strukturierte Daten, OEM, XML
Information Retrieval
Effizienz
10 Zugriffsstrukturen, Verbund-Algorithmen
11 Anfrage-Optimierung
12 Schemaentwurf
•
Mehrbenutzerbetrieb und Transaktionen
13 Transaktionen: Serialisierbarkeit, Recovery
14 Scheduler: Konfliktgraph-, Sperrverfahren
15 Scheduler: Zeitmarkenverfahren, Sicht-Serialisierbarkeit
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
21
© Joachim Biskup, Universität Dortmund
Literatur
•
22
Empfehlung für Vorlesung
Ramez Elmasri, Shamkat B. Navathe:
Fundamentals of Database Systems (3rd edition), Addison Wesley, Reading etc, 2000.
955 + 30 + 24 Seiten.
Jeffrey D. Ullman, Jennifer Widom:
A First Course in Database Systems, Prentice Hall, Upper Saddle River, 1997.
470 Seiten.
•
große Mengen von
(large amount)
•
strukturierten oder halb-strukturierten Daten
((semi-)structured data)
•
dauerhaft
(persistent)
•
verlässlich
(dependable)
•
für im Allgemeinen viele
und verschiedenartige Benutzer verfügbar
(shared)
•
effizient verwalten
(management)
•
d.h. Anfragen und Änderungen bearbeiten
(queries/updates)
Lesetipps
S. Abiteboul, R. Hull, V. Vianu: Foundations of Databases
C.J. Date: (Introduction to) Database Systems
Th. Härder, E. Rahm: Datenbanksysteme - Konzepte und Techniken der Implementierung
P.M. Lewis, A. Bernstein, M. Kifer: Database and Transaction Processing
B. Thalheim: Entity-Relationship Modeling - Foundations of Database Technology
J.D. Ullman: Principles of Database and Knowledge-Base Systems
G. Vossen: Datenbankmodelle, Datenbanksprachen und Datenbankmanagement-Systeme
•
17. Juli 2003
Aufgaben eines Informationssystems
Joachim Biskup:
Grundlagen von Informationssystemen, Vieweg, Braunschweig/Wiesbaden, 1995.
543 Seiten.
•
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
sehr viele weitere Lehrbücher und Monographien/Zeitschriften/Tagungen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
23
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
24
Beispiele für Anwendungen
•
•
•
•
•
•
•
•
•
•
•
•
Grundformen
Unternehmensführung
Personal-, Kunden- und Materialverwaltung
Auftragsabwicklung, Betriebsmittel- und Finanzüberwachung
Statistik und Vorhersagemodelle
Literaturnachweis und Bibliothekswesen
Begriffswörterbücher
Landvermessung und Bodennutzung
Versuchsplanung, -durchführung und -auswertung
Bildauswertung und -archivierung
Entscheidungsunterstützung
rechnergestütztes Entwerfen und Konstruieren (CAD)
rechnergestützte Fertigung (CIM), Programmentwicklung (CASE)
Falls die benötigte “Information’’ in Form von
mehr oder weniger strukturierten oder wenigstens semi-strukturierten “Daten’’ vorliegt
oder einigermaßen leicht derart aufzubereiten ist:
•
•
Datenbanksystem
Wissensbanksystem
(database system)
(knowledgebase system)
Falls hauptsächlich weitgehend unstrukturierte Texte verwaltet werden:
•
“Information Retrieval-System’’
(information retrieval system)
Falls neben ‘‘Daten’’ und ‘‘Texten’’ auch andere Formen von ‘‘Information’’
wie Bilder, Videos, Ton etc. mit einbezogen werden:
•
‘‘Multimedia-System’’
(multi-media system)
Anwendungen treten auf in den Unternehmen
• manchmal einzeln
• häufiger aber in Zusammenstellungen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
25
© Joachim Biskup, Universität Dortmund
große Mengen von Daten
•
nicht alle gleichzeitig im Hauptspeicher
•
auf externen Speichergeräten wie Magnetplatten
•
größte Systeme verwalten inzwischen Datenmengen im Bereich
von vielen Gigabytes oder gar Terabytes
•
andere Fragestellungen als etwa bei der Verwaltung der Werte
lokaler und dynamischer Variablen in prozeduralen Programmiersprachen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
26
17. Juli 2003
28
dauerhaft verfügbar
17. Juli 2003
27
•
Daten außer im Hauptspeicher stets
auch auf externen Speichergeräten halten
•
Daten auf jeden Fall durch (Sicherungs-) Kopien schützen
•
Daten im Allgemeinen mehrfach halten,
gegebenenfalls zusätzlich auch noch in (leicht veränderten) Versionen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
verlässlich verfügbar
Verlässlichkeit umfasst insbesondere
Genau die vorgesehenen Benutzer sollen
•
zu den von ihnen bestimmten Zeitpunkten
•
mit genau den für ihre Verpflichtungen benötigten
•
und jeweils zutreffenden Daten
•
die gewünschten Bearbeitungen ausführen lassen können.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
29
•
Anforderungen der Sicherheit:
- Verfügbarkeit
(von Daten und Bearbeitungsverfahren),
- Integrität
(Schutz vor unbeabsichtigter oder bösartiger
Veränderung oder Zerstörung von Daten
oder zumindest deren Erkennbarkeit)
- Vertraulichkeit (für ‘‘Datenschutz’’, Betriebsgeheimnisse, ... )
•
gebräuchliche Mechanismen für Sicherheit:
- Zugriffskontrolle mit Authentisierung und Überwachung
- Kryptographie, insbesondere Verschlüsselung und digitale Signaturen
•
Zuverlässigkeit und Fehlertoleranz
durch Redundanz, insbesondere durch Kopien
•
inhaltliches Zutreffen der (durch die) Daten (dargestellten Gegebenheiten)
durch Erhaltung semantischer Bedingungen
•
wechselseitige Isolierung der Benutzer bei Mehrbenutzerbetrieb
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
für viele und verschiedenartige Benutzer
Verlässlichkeit
•
dauerhafte Speicherung
•
Gegebenheiten der Anwendung werden benutzerübergreifend modelliert und
mit Hilfe geeigneter Datenmodelle (Datentypen für Informationssysteme) und
entsprechender Datendefinitionssprachen formalisiert und vereinbart
•
Beantwortung von Anfragen
•
vom Informationssystem-Administrator
als sogenanntes Schema getroffene Vereinbarungen
stellen das entscheidende Bindeglied zwischen den späteren (End-) Benutzern dar
•
auf das gemeinsame Schema und die unter diesem Schema gespeicherten Daten
werden sogenannte Sichten eingerichtet
•
Schema, Sichten und Daten werden durch eine ‘‘Ontologie’’ gedeutet
17. Juli 2003
32
- einfachste Form: direktes Wiederauffinden gespeicherter Daten
- anspruchsvollste Form: vollständige Operationalisierung der logischen Implikation
- jeweils alle einer Anfrage genügenden Antworten liefern, also:
- deklarativ (durch Angabe des Was, aber nicht des Wie)
- mengenorientiert (alle Antworten)
- effizient, d.h. insbesondere zeitlich schnell
- (Halb-) Strukturierung der Daten dabei wichtiges Hilfsmittel
- klassische Zugriffsstrukturen wie Sortierungen, Suchbäume und Hashing
allgemein gemäß Brockhaus: die philosophische Lehre vom Sein, besonders von den
Bestimmungsgründen des Seienden (Wesen, Dasein), von den Seinsweisen (real, ideal), den
Seinsmodalitäten (Möglichkeit, Wirklichkeit, Notwendigkeit) und den Seinsschichten (z.B.
anorganische Natur, organische Natur, Seele, Geist)
(nicht erreichte) Wunschvorstellung in der “Informatik”: umfassende, operationalisierte
Beschreibung der Gegebenheiten einer Anwendung
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
30
Verwaltung der Daten
•
© Joachim Biskup, Universität Dortmund
17. Juli 2003
17. Juli 2003
31
- besondere Verfahren zur Optimierung von Anfragen
•
Durchführung von Änderungen
- insbesondere die semantischen Bedingungen erhalten
(inhaltliches Zutreffen der Daten absichern)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
verschiedenartige Blickwinkel auf ein Informationssystem
•
weitreichendster Blickwinkel
Modell einer ‘‘Miniwelt’’ bilden:
Ein Informationssystem vermittelt Mitteilungen
zwischen “in einem Unternehmen’’ handelnden Menschen.
- Daten und Schema sollen Gegebenheiten einer Miniwelt abbilden.
- Durch Änderungen im Informationssystem werden
Vorgänge in der Miniwelt nachvollzogen.
- Anfragen werden bezüglich des Modells beantwortet;
- sinngemäß gedeutet, entsprechen den Antworten (hoffentlich)
jeweils Gegebenheiten in der Miniwelt.
•
Diese Menschen handeln in einer Miniwelt,
deren Gegebenheiten und Vorgänge
durch Dokumente abgebildet werden,
eigenständige Miniwelt verwalten:
- Miniwelt besteht im Wesentlichen aus (Original-) Dokumenten.
- Diese liegen ausschließlich im Informationssystem vor.
Anfragen werden bezüglich dieser Miniwelt beantwortet
und bedürfen keiner weiteren Deutung.
•
über die sich die Menschen
mit Hilfe des Informationssystems
Mitteilungen machen.
Mitteilungen vermitteln:
- Wie ein “großes Schwarzes Brett’’ benutzt.
- Änderungen im Informationssystem bedeuten dann,
dass neue Mitteilungen hinterlegt und “am Brett angeschlagen’’ und
dass alte Mitteilungen abgeändert oder entfernt werden.
- Anfragen werden bezüglich der hinterlegten, “angeschlagenen’’ Mitteilungen beantwortet.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
33
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Überblick: Thema der Vorlesung
17. Juli 2003
34
17. Juli 2003
36
Information
1.2 Information und Kommunikation: Vermittlung durch
Informationssysteme
•
Begriff der ‘‘Information’’ grundlegend für eine Vielzahl von Betrachtungen
•
‘‘Information’’ als dritter Grundbegriff, neben Materie und Energie
•
Begriff der ‘‘Information’’ schwer allgemein fassbar,
nur mit Mühe und für eingeschränkte Anwendungen genauer definierbar
•
Gemeinsames Grundmuster zur Annäherung:
- Es wird ein Rahmen von Möglichkeiten abgesteckt,
wobei Unsicherheit über die tatsächlich vorliegenden Verhältnisse besteht.
- Es werden aufeinanderfolgende mögliche Ereignisse
zueinander in Beziehung gesetzt unter dem Gesichtspunkt,
wie weit die Unsicherheit über die tatsächlich vorliegenden Verhältnisse
verringert wurde.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
35
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
eine wahrscheinlichkeitstheoretische Sicht von Information
•
eine modelltheoretische Sicht von Information
‘‘Rahmen der Möglichkeiten’’ durch eine Zufallsvariable beschrieben:
•
ai
mögliche Werte der Zufallsvariablen
p(ai) Wahrscheinlichkeiten ihres Eintreffens
•
M = (d,r1,...,rn) wobei jeweils
Informationsgehalt eines Wertes ai
•
bestimmt als die durch das tatsächliche Eintreffen von ai beseitigte Unsicherheit
•
‘‘Nichtereignis’’ (vorher) in Beziehung gesetzt zum Eintreffen (nachher)
•
Informationsgehalt eines Wertes ai als
I(ai) = - ld p(ai) = ld 1/p(ai)
•
Randfälle:
•
k
∑
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
•
Randfälle und Beispiele:
- falls || Modκ(Φ) || = 1, so liegt keine Unsicherheit vor
- falls Modκ(Φ) = κ,
so liegt höchste Unsicherheit vor
- für Klasse der Strukturen mit einer zweistelligen Relation über festem Universum,
κ = {(d,r) | r ⊂ d×d} mit d = {0,...,n}:
- stets wahre Aussage ϕ1 :≡ ∀x[x = x] läßt uns völlig im Unsicheren:
Modκ(ϕ1) = κ
- Aussage ϕ2 :≡ ∀x∀y∀z [(x,y) ∈ R ∧ (x,z) ∈ R ⇒ y = z] beschreibt Funktionen:
Modκ(ϕ2) = {(d,r) | r ist partielle Funktion von d nach d}
p ( ai ) ⋅ I ( ai )
17. Juli 2003
37
Beispiel für Information und Informationsübertragung bei logischer
Programmierung
zweistelliges Prädikatenzeichen:
R
Aussage:
Φ :≡ ∀y [ R(0,y) ⇒ R(y,0) ] ∧ R(0,0) ∧ R(0,1)
‘‘Rahmen der Möglichkeiten“ absteckende Klasse: κ := { (d,r) | r ⊂ d×d } mit d:={0,1,2}
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
38
Klasse der Möglichkeiten: κ := { (d,r) | r ⊂ d×d } mit d:={0,1,2}, entspricht ℘ (d × d)
Aussage:
Φ :≡ ∀y [ R(0,y) ⇒ R(y,0) ] ∧ R(0,0) ∧ R(0,1)
Modellklasse
Modκ (Φ)
Modκ(Φ) echte Teilmenge von κ:
das ‘‘Wissen’’ Φ lässt nicht völlig im Unsicheren,
aber es verbleibt die Unsicherheit, welche der Strukturen aus Modκ (Φ) tatsächlich vorliegt
•
Hinzufügen eines neuen Literals zum ‘‘Wissen’’ Φ:
man kann gegebenenfalls das „Wissen verbessern“,
d.h. hier die Unsicherheit über die tatsächlich vorliegende Struktur verringern
Die Aussage Φ ist in allen solchen Strukturen gültig,
die die Paare (0,0) und (0,1) enthalten und
mit jedem Paar der Form (0,y) auch das Paar (y,0) enthalten.
•
17. Juli 2003
Hinzufügen des Literals R(0,2):
man erhält die Aussage:
Φ1 :≡ Φ ∧ R(0,2),
für die zugehörigen Modellklassen gilt: Modκ (Φ1) ⊂≠ Modκ (Φ),
(zum Beispiel { (0,0), (0,1), (1,0) } ∉ Modκ (Φ1) )
Die zugehörige Modellklasse hat also folgendes (unvollständig aufgeschriebenes) Aussehen:
Modκ (Φ) = { { (0,0) , { (0,0) , { (0,0)
, ... }
(0,1)
(0,1)
(0,1)
(1,0) }
(1,0)
(1,0)
(0,2)
(0,2)
(2,0) }
(2,0)
(1,1) }
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
© Joachim Biskup, Universität Dortmund
•
Diese Klasse von Strukturen enthält also im Wesentlichen
alle zweistelligen Relationen r über dem Universum {0,1,2};
wird im Folgenden identifiziert mit:
℘ (d × d)
© Joachim Biskup, Universität Dortmund
eine Aussage ϕ ist in einer Struktur M entweder falsch oder gültig (wahr)
ist ϕ in M gültig, so ist M ein Modell von ϕ
zugehörige Modellklasse:
Modκ(ϕ) := {M | M ∈ κ und ϕ ist gültig in M} ⊂ κ
für Menge Φ von Aussagen:
Modκ(Φ) := ∩ϕ ∈ Φ Modκ(ϕ)
Unsicherheit bei Aussagenmenge Φ: welches der Modelle aus Modκ(Φ) liegt vor?
i=1
© Joachim Biskup, Universität Dortmund
nichtleeres Universum
Relationen über d, d.h. ri ⊂ d ×...× d
•
I(ai) = ld 1 = 0
I(aj) = ld 2 = 1
Entropie, mittlerer Informationsgehalt der möglichen Werte: H ( a ) =
d
ri
‘‘Ereignisse’’ sind in einer geeigneten Logiksprache formalisierte Aussagen:
-
für p(ai) ≠ 0
für mit Sicherheit eintreffenden Wert mit p(ai) = 1:
für zwei gleichwahrscheinliche Werte mit p(a1) = p(a2) =1/2:
‘‘Rahmen der Möglichkeiten’’ beschrieben durch eine Klasse κ von Strukturen:
•
Hinzufügen des Literals R(1,0):
man erhält die Aussage:
Φ2 :≡ Φ ∧ R(1,0)
für die zugehörigen Modellklassen gilt:
Modκ (Φ2) = Modκ (Φ),
(hinzugefügtes ‘‘Wissen’’ ist ‘‘redundant’’, logische Implikation des ursprünglichen ‘‘Wissens’’)
39
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
40
Kommunikation
Kommunikation als eine Handlung
•
Begriff der ‘‘Kommunikation’’ ebenfalls - wie ‘‘Information’’ - sehr vielfältig benutzt
•
Beide Begriffe sind aufeinander bezogen:
•
•
- bei Erörterung von ‘‘Information’’:
auch ‘‘Informationsübertragung’’ betrachten
- bei Erörterung von ‘‘Kommunikation’’: auch übermittelten ‘‘Informationsgehalt’’ betrachten
•
•
•
Kommunikation:Handlung zwischen vernunft- und sprachbegabten Menschen
Sprache:
nicht alleiniges, aber herausragendes Mittel
der Kommunikation zwischen Menschen.
natürliche Sprache:
Beteiligte müssen über einen gemeinsamen Bezugsrahmen verfügen:
- ein unermesslicher gemeinsamer Erfahrungsschatz als vorgefundener Bezugsrahmen
- steckt die Möglichkeiten ihrer Verständigung ab
- kann schon vorgefunden sein
- oder wird, abgestützt auf Vorgefundenes, zwischen den Beteiligten erst festgelegt
- Möglichkeiten zur Verabredung von Bezugsrahmen und zum einmaligen Ausdruck
- Möglichkeiten zur Entfaltung neuer Bezüge
- formale Sprachen als Grundlage von ‘‘Informationssystemen’’ definieren
Bei Unterstützung von Kommunikation durch ‘‘Informationssysteme’’
- dem für die Unterstützung ausdrücklich vereinbarten Bezugsrahmen,
nämlich dem ‘‘Schema’’ und zusätzlicher ‘‘Ontologie’’ kommt entscheidende Bedeutung zu
•
- Datendefinitionssprache
- Datenmanipulationssprache mit Anfragesprache
- Unterstützung nur in dem Maße erfolgreich,
wie für die beteiligten Menschen sowohl die vorgefundenen,
oftmals nicht ausdrücklich genannten Bezüge,
als auch die erstrebenswert einvernehmlich verabredeten Bezüge
klar ersichtlich und bedeutsam sind
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
Über Informationssysteme vermittelte Kommunikation bedarf formaler Sprachen
•
Verdichtung, Verengung oder auch Verarmung der Ausdrucksmöglichkeiten:
der Übergang von natürlicher Sprache zu formalen Sprachen
betrifft den Gesamtvorgang der Kommunikation
zwischen den ein Informationssystem nutzenden Menschen
17. Juli 2003
41
© Joachim Biskup, Universität Dortmund
Grundzüge menschlichen Handelns
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
42
kommunikatives Handeln (nach Habermas)
Handlungszug
Funktion
Prägung durch
Weltauffassung
Geltungsanspruch
teleologisch
(strategisch)
Zweck
verwirklichen
Sachverhalte
objektiv
Wahrheit und
Wirksamkeit
normenreguliert
Beziehungen
pflegen
Erwartungen
anderer
sozial
Berechtigung
dramaturgisch
sich selbst
darstellen
eigenes
Erleben
subjektiv
Wahrhaftigkeit
•
im kommunikativen Handeln verbinden sich die schon genannten Züge
•
zwei oder mehrere Handelnde
‘‘suchen eine Verständigung über ihre Handlungssituation,
um ihre Handlungspläne und damit ihre Handlungen einvernehmlich zu koordinieren’’
(J. Habermas)
•
wichtigstes Hilfsmittel dabei ist die Sprache:
die beteiligten Handelnden versuchen damit,
ihre Einstellungen zur ‘‘Welt’’ gegenseitig darzustellen, also zu
- den (objektiven) Sachverhalten,
- den (sozialen) Erwartungen anderer,
- dem (subjektiven) eigenen Erleben
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
43
auf der Grundlage eines gemeinsamen erfahrenen Ausschnittes der ‘‘Lebenswelt’’
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
44
Veranschaulichung kommunikativ Handelnder mit Weltbezügen
Geltungsansprüche und Begründungen beim kommunikativen
Handeln
•
objektive Welt
(Sachverhalte)
soziale Welt
(Erwartungen)
Beteiligte drücken mit Sprachhandlungen die Handlungsabsicht vorbehaltlos aus:
etwa ein Versprechen, einen Befehl, einen Wunsch, ...
•
Erfolg oder Misserfolg der gesuchten Verständigung:
erweist sich darin, ob die ausgedrückten Geltungsansprüche bezüglich
- Wahrheit von Sachverhalten,
- Berechtigung von Erwartungen und
- Wahrhaftigkeit von Selbstdarstellungen
angenommen oder abgelehnt werden
Sprachhandlungen
•
Geltungsansprüche von Betroffenen:
- können begründet zurückgewiesen werden,
d.h. Wahrheit und Berechtigung können bestritten
und Wahrhaftigkeit angezweifelt werden
subjektive
Welt 2
(Erleben)
subjektive
Welt 1
(Erleben)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
- werden die erhobenen Ansprüche bekräftigt,
so werden hierfür ebenso wie für die Zurückweisung
Begründungen verlangt
17. Juli 2003
45
© Joachim Biskup, Universität Dortmund
Rückbezüglichkeit und Offenheit
•
•
•
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
46
Unterstützung durch ein Informationssystem
Kommunikatives Handeln ist von Anbeginn darauf angelegt,
dass Auseinandersetzungen zwischen den Handelnden geschlichtet werden,
indem Gründe beigebracht werden
•
Entscheidungsoffenheit stellt große Herausforderung dar
•
nicht nur Bezugsrahmen durch ‘‘Schema’’ und ‘‘Ontologie’’ ausdrücklich vereinbaren
Auseinandersetzungen mit Begründungen kann ein Handelnder
in einem rückbezüglichen Verhältnis zu sich selbst vorwegnehmen,
indem Sprachhandlungen von vornherein
im Hinblick auf mögliche Zurückweisungen begründet vorgetragen werden
•
ebenfalls Zurückweisungen vermittelter Sprachhandlungen mitbedenken
•
ein ‘‘Administrator’’ kann Herausforderung allenfalls näherungsweise gerecht werden
•
spätere Endbenutzer erfahren das Informationssystem häufig als
starrer und einengender als wünschenswert
kommunikatives Handeln in zweierlei Hinsicht offen in die Zukunft:
- ein Angesprochener kann Geltungsansprüche annehmen oder zurückweisen
- ein Sprecher kann Entscheidungsoffenheit bereits berücksichtigen.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
47
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
48
Soziale Systeme (nach Luhmann)
•
•
•
Kommunikation
ein System und seine Umwelt als differenzierte Einheit verstehen
System benutzt Grenze zur Umwelt, um Differenz zur Umwelt zu bewahren
großes System mit Umwelt kann sich (aus)differenzieren:
begriffen
vorhandenes Teilsystem erscheint als ‘‘interne Umwelt’’ für ein neues Teilsystem
•
Information verringert Unsicherheit:
- Rahmen von Möglichkeiten: Systemzustände
- Information: Ereignis, das Systemzustände auswählt,
also Möglichkeiten zu Tatsächlichkeiten werden lässt
- Ereignis ist durch die Möglichkeiten abgesteckt,
verändert das System mit dessen eigener Mitwirkung;
während das Ereignis vorübergeht, dauert der veränderte Systemzustand an
- sinngemäße Wiederholung führt zu keiner neuen Auswahl (keine Information)
- getroffene Auswahl schließt vorher vorhandene Möglichkeiten aus
•
•
Die Information wählt aus einem Rahmen von Möglichkeiten.
•
Die Mitteilung wird von einem Sender als sein sichtbares Verhalten gewählt.
•
Das Verstehen verändert die Möglichkeiten des Empfängers.
•
Im Anschluss an die genannten drei Selektionen kann
der Empfänger jeweils eine vierte Selektion treffen:
Die Annahme oder die Ablehnung des Verstandenen durch den Empfänger
bestimmt dessen weiteres Handeln.
Information steigert Unsicherheit:
-
neue Möglichkeiten treten zutage
in einem ‘‘Informationssystem’’ nur recht beschränkt zu verwirklichen
als ‘‘Schema’’ vereinbarter Bezugsrahmen (weitgehend) fest und unveränderbar angenommen
für Schema-Änderungen benötigt man sogenannte ‘‘Metaschemas’’,
die nun ihrerseits die Änderungsmöglichkeiten für ‘‘Schemas’’ abstecken
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
‘‘als Synthese dreier Selektionen,
als Einheit aus Information, Mitteilung und Verstehen’’:
17. Juli 2003
49
•
Rückbezüglichkeit: Kommunikation als auf sich selbst bezogener Vorgang,
der Sender und der Empfänger können unterscheiden, berücksichtigen, überprüfen
- Information (in gewissem Sinne die ‘‘Absicht’’)
- Mitteilung (in gewissem Sinne das ‘‘Beobachtbare’’)
© Joachim Biskup, Universität Dortmund
Unterstützung durch ein Informationssystem
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
50
Gestaltung von Informationssystemen
zwei Grundeinsichten:
•
bewirkt Verengungen
•
‘‘Mitteilungen’’: im Wesentlichen nur Ausdrücke aus verwirklichter formaler Sprache
•
‘‘Verstehen’’ von Mitteilungen:
• Kommunikation zwischen Menschen auffassen als hochkomplexe Handlung,
die nur näherungs- und modellweise verstanden (und auch nur verstehbar) ist
• Jede Vermittlung durch ‘‘Informationssysteme’’ kann dazu führen,
dass möglicherweise wichtige Gesichtspunkte unterdrückt werden
nur soweit nichttrivial,
d.h. mehr als bloßes Hinzufügen (oder gegebenfalls auch Entfernen) einer Mitteilung,
Die bei der Modellbildung gewonnenen Erkenntnisse über Kommunikation
kann man wenigstens ansatzweise soweit formalisieren,
dass wichtige Bestandteile von Kommunikation
unter Benutzung formaler Sprachen nachgebildet werden können
als es im Vorhinein in der Semantik der Änderungsoperationen vorgesehen
und in den entsprechenden Verfahren verwirklicht worden ist
Indem man also die Unterschiede zwischen
- voller menschlicher Kommunikation einerseits und
- über Informationssysteme vermittelter Kommunikation andererseits
in ihren Einzelheiten verdeutlicht (und dann auch den Endbenutzern offenlegt),
kann man Operationalisierungen zur Überbrückung der Unterschiede gewinnen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
51
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
52
Benutzerrahmen
Vermittlung von Kommunikation durch ein Informationssystem
Benutzer 1
Benutzer 2
umfasst Angaben für folgende, näherungsweise zu formalisierende Gesichtspunkte:
•
Selbstbild
•
Partnerbild(er) mit vermuteten Erwartungen des Partners
•
Gewohnheiten gemäß Vereinbarungen oder erworbenen Erfahrungen
•
Absichten mit Handlungsplänen
•
eigenes Wissen
Sprachhandlungen
Selbstbild
S1
Partnerbild
P1(B2)
Partnerbild
P2(B1)
Selbstbild
S2
Mit-
B1
teilungen
in
einer
formalen
Sprache
Ab- Gewohn- Wissen
sichten heiten
A1
G1
W1
B2
Wissen Gewohn- Abheiten sichten
A2
W2
G2
benutzerorientierte
Einsatz-Schnittstelle
benutzerorientierte
Einsatz-Schnittstelle
InformationssystemSchnittstelle
IS
gemeinsames Wissen, einschließlich Schema
Informationssystem
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
53
© Joachim Biskup, Universität Dortmund
‘‘formales Kommunikationsverhalten’’
•
•
•
•
•
•
17. Juli 2003
54
Kommunikation und Mensch-Rechner-Interaktion
die ‘‘Benutzer’’ sehen einander noch als “kommunikativ Handelnde’’
ihre Sprachhandlungen oder ihre Mitteilungen in einer formalen Sprache erscheinen
jeweils als von einem bestimmten Sender an einen bestimmten Empfänger gerichtet
Vermittlung durch ein Informationssystem eröffnet neue technische Möglichkeiten,
insbesondere die Vermittlungen auch ungerichtet zu verwenden
Informationssystem überbrückt bei Kommunikation Zeit und Raum
In das Informationssystem eingegangene Mitteilungen
werden als Daten dauerhaft verfügbar gehalten und
unter Verwendung von Netzwerkumgebungen räumlich verteilt
seinen Benutzern wieder angeboten
•
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
Informationssystem kann selbst (als ‘‘formal’’ bezeichnete) Handlungen ausführen
für einen Kommunikation suchenden Benutzer:
•
Kommunikation:
Handlung zwischen vernunft- und sprachbegabten Menschen
•
Interaktion:
Wechselbeziehung zwischen
einem handelnden Menschen und
einem Rechensystem, dem über
Arbeitsteilung und Programmierung
Teilaufgaben menschlicher Tätigkeit übertragen worden sind
•
Protokollausführung: Wechselbeziehung zwischen
verschiedenen Rechensystemen
(oder hinreichend selbständigen Teilen eines Rechensystems)
das Informationssystem als Träger formaler Handlungen erscheint
wie das eigentliche Gegenüber;
ein bei unmittelbaren Sprachhandlungen
ursprünglich vorhandener menschlicher Kommunikationspartner
bleibt (zunächst jedenfalls) unberücksichtigt
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
55
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
56
Interaktion und Protokollausführung
Vermittlung durch ein Informationssystem
Ein Informationssystem vermittelt die Mitteilungen der kommunikativ Handelnden.
Benutzer
Administrator
...
...
Systementwickler
Die Besonderheiten dieser Vermittlung kann man wie folgt zusammenfassen:
•
Es stehen jeweils große Mengen von Daten vermittlungsbereit zur Verfügung.
•
Die Vermittlung erfolgt im allgemeinen zeitlich verzögert.
•
Die Qualität der Vermittlung wird durch besondere Protokolle abgesichert, die der
unmittelbaren Kontrolle der (End-) Benutzer entzogen werden.
•
Die Vermittlung wird im Allgemeinen vielen und verschiedenartigen Handelnden
angeboten.
•
Wird die Vermittlung tatsächlich in Anspruch genommen, so geschieht sie unter
einengenden zeitlichen und räumlichen Anforderungen.
Interaktion
Protokollausführung
Informationssystem
Informationssystem
Interaktionen
Unternehmensleiter
© Joachim Biskup, Universität Dortmund
Administrator
...
...
Benutzer
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
57
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Information und Kommunikation: Vermittlung durch Informationssysteme
17. Juli 2003
58
Programmieren?
1.3 Modellierung: Wirklichkeit und Modell
“schwammig”
programmieren?
Aufgabenstellung
“unklar”
reale
Maschine
“ausgefranst“
(hardware)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
59
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
60
Programmieren: Modellieren und Formalisieren
Wirklichkeit - Begriffsraum - Sprache
“schwammig“
modellieren
Wirklichkeit:
Aufgabenstellung
“unklar“
aus einfachen Elementen wohlstrukturiert
zusammengesetzte Erscheinungen
Modell der
“ausgefranst“
Aufgabenstellung
formalisieren
bedeuten
vertreten
virtuelle Maschine für anwendungsnahe
formale Programmiersprache
Sprache:
benennen
Ausdrücke und Sätze
. . .
reale
Maschine
Raum der Begriffe und
Gesetze der Logik
. . .
(hardware)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
61
© Joachim Biskup, Universität Dortmund
Begriffsgerüst der Entity-Relationship Modellierung
•
Seiendes, Entität (entity):
Einheit der ‘‘Mini-Welt’’
•
Beziehung (relationship):
ein Zusammenhang zwischen Seienden
•
Eigenschaft / Attribut (predicate / attribute):
beschreibt Seiendes oder Beziehung
•
Rolle (role):
•
Klassenbildung (abstraction): Zusammenfassung
gleichartiger Seienden/Beziehungen
Ergänzungen notwendig:
•
•
Aussonderung (separation/ specialization):
für eine Aussageform und eine Klasse
diejenigen Seienden/Beziehungen,
für die die entsprechende Aussage gilt
Verallgemeinerung (generalization): Vereinigung wohlbestimmter Klassen
•
Aggregation (aggregation):
© Joachim Biskup, Universität Dortmund
62
erster Ansatz: Aufzählungen
- der vorhandenen Seienden,
- ihrer zutreffenden Eigenschaften und
- ihrer Beziehungen
Bedeutung eines Seienden in einer Beziehung
•
17. Juli 2003
statische Gesichtspunkte eines Unternehmens
•
•
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
Gesamtheit der als möglich angesehenen Seienden, Beziehungen etc. nicht darstellbar
Bedingungen an (wirklichkeits-)getreue Aufzählungen nicht ausdrückbar
keine Meta-Aussagen über zukünftige Beschreibungen möglich
Das aufzählend dargestellte Wissen wird ergänzt durch Wissen folgender Formen:
• Bedingungen (constraints): schränken die Aufzählungen ein
• Regeln (rules):
erschließen Seiendes, Beziehungen etc.
Beziehungen als Seiendes betrachtet
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
63
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
64
typische Bedingungen
•
typische Regeln
Schlüsselbedingung (key constraint): innerhalb einer Seiendenklasse müssen die Werte
gewisser Attribute die Seienden eindeutig bestimmen
•
•
Gesamtheitsregel (universe of discourse rule):
Die Gesamtheit der möglichen Seienden einer Art wird
abschließend durch die Angaben ... < die hier genauer einzufügen wären >... beschrieben.
•
Verneinungsregel (negation rule):
Ist eine Beziehung in der Gesamtheit der möglichen Beziehungen,
aber weder in der Aufzählung noch erschließbar,
so soll die entsprechende Aussage nicht gelten.
•
Sichtregel (view rule):
Sind die Beziehungen R1,...,Rk in der Aufzählung oder schon erschlossen,
so soll auch die Beziehung erschlossen werden können,
die man aus R1,...,Rk
gemäß den Angaben ...< die hier genauer einzufügen wären >... erstellen kann.
Aussonderungsbedingung (specialization constraint, isa-constraint):
jedes Seiende aus einer (Teil-)Klasse Si muss auch in der (Ober-)Klasse S sein
•
Verallgemeinerungsbedingung oder Partitionsbedingung (partition constraint):
jedes Seiende aus (Ober-)Klasse S muss auch in [genau] einer (ihrer Unter-)Klasse(n) Si sein
•
viele-eins-Bedingung (many-one-constraint, n:1-constraint):
jedes Seiende aus Klasse S1 darf nur mit
höchstens einem Seienden aus Klasse S2 in Beziehung stehen
•
Seinsbedingung (existence constraint):
jedes Seiende aus Klasse S1 muss mit
mindestens einem Seienden aus Klasse S2 in Beziehung stehen
•
Verweisbedingung (referential constraint):
in einer Beziehungenklasse auftretende Seiende
müssen in einer Seiendenklasse (oder einer anderen Beziehungenklasse) vorkommen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
65
© Joachim Biskup, Universität Dortmund
dynamische Gesichtspunkte eines Unternehmens
man erwartet häufig Änderungen und
möchte diese in der tatsächlichen Verwirklichung leicht durchführen können
zeitunabhängige Beschreibungen:
man erwartet im Allgemeinen keine Änderungen;
sie können also in der tatsächlichen Verwirklichung
ausschließlich unter dem Gesichtspunkt leichter Nutzung behandelt werden
Dynamische Gesichtspunkte kann man auch direkter beschreiben,
indem man die kommunikativen Handlungen in den Mittelpunkt der Betrachtung stellt:
eine (formale) Handlung (action) wird dann wie folgt angegeben:
• eine Änderung im Wissen eines Senders, d.h. eine Information,
• löst eine Mitteilung an einen (oder mehrere) Empfänger aus,
• die dann ihrerseits ihr Wissen geeignet verändern oder eine anschließende Handlung auslösen,
d.h. zu verstehen versuchen.
Verstehen offen für Annahme oder Ablehnung und für Anschlusskommunikation:
nicht nur einzelne Handlungen, sondern auch (formale) Handlungsfolgen beschreiben
Wissen und Handlung, statische und dynamische Gesichtspunkte:
stets unmittelbar aufeinander bezogen, nur für Formalisierung begrifflich getrennt
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
66
zeitabhängige Beschreibungen:
- fasst man Mitteilungen ebenfalls als (Bruchstücke von) Wissen auf,
so bedeutet eine Mitteilung die Aufforderung an den Empfänger, sein Wissen zu verändern.
- da der Empfänger sein Wissen nur gemäß Bedingungen aufbauen kann (oder will),
müssen gegebenenfalls auftretende Widersprüche unter den Beteiligten aufgelöst werden.
© Joachim Biskup, Universität Dortmund
17. Juli 2003
zeitabhängige und zeitunabhängige Teile
Bedingungen beschreiben indirekt auch dynamische Gesichtspunkte:
•
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
67
im Allgemeinen als zeitabhängig angesehen:
• aufzählend dargestelltes Wissen
im Allgemeinen als zeitunabhängig angesehen:
• Formate für die Aufzählungen
• Bedingungen
• Regeln für die Gesamtheit der möglichen Seienden und für negative Information
• formale Handlungen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
68
Schema und Instanz, ‘‘Ontologie’’
ER-Diagramme
Schema (Deklaration): Zusammenfassung der zeitunabhängigen Teile
Zeichen für Bedingungen
Zeichen für Klassen
• Formate (Typen) für Aufzählungen
• Bedingungen (Invarianten) für Aufzählungen
• Regeln (vordefinierte Prozeduren) zum Erschließen von Nicht-Aufgezähltem
Instanz (Zustand): Zusammenfassung der zeitabhängigen Teile
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
dann
ISA
Aussonderungsbedingung: jedes
Seiende aus Si muß auch in S sein
© Joachim Biskup, Universität Dortmund
(Verallgemeinerung)
...
Sk
(Aussonderung)
Aggregation
...
Aggregation durch
Beziehungenklasse,
aufgefaßt als
Seiendenklasse
17. Juli 2003
69
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
70
17. Juli 2003
72
Beispiel für ER-Modellierung: Seiendenklassen
Name
Vorname
Geschlecht
Geburtstag:
Geburtsort
Anschrift:
Straße, Nr, Plz, Ort
Tag, Monat, Jahr
Person
private Telefonnummer
weitere Telefonnummern
ISA
ϕ(t1,...,tn)
or
Behandelnder
...
and
ψ(r1,...,rk)
(Aussonderung)
Verallgemeinerungsbedingung
(Partitionsbedingung): jedes
Seiende aus S muß auch in
(genau) einem Si sein
(! )
ISA
Rolle
trifft auch die Aussage ϕ(t1,...,tn) zu,
wobei die Terme ti wie angegeben gebildet werden.’’
Gleichheitsbedingung
...
Sk
S
S
1
die Aussagen ψ(r1,...,rk),..., χ(s1,...,sl) und die Gleichheitsbedingung
alle zutreffen
oder
eine alternative Menge
von Aussagen mit entsprechender Gleichheitsbedingung zutrifft,
t1 := exp1(r1,...,rk,...,s1,...,sl)
.
.
tn := expn(r1,...,rk,...,s1,...,sl)
...
S
1
mengenwertiges
Attribut
Regeln und Regelgraphen
‘‘Wenn
Beziehungenklasse
A
‘‘Ontologie’’: meistens nur umgangssprachliche oder halb-formale
inhaltliche Deutungen von Schema und Instanzen
© Joachim Biskup, Universität Dortmund
(Verallgemeinerung)
Attribut
Rolle
In den Verwirklichungen versucht man im Allgemeinen
das Schema und die Instanz
mit den gleichen (oder zumindest ähnlichen) Techniken zu behandeln.
S
A
• Aufzählung entsprechend Formaten, erfüllt Invarianten
In einer aus Schema und Instanz bestehenden Beschreibung
kann das Schema als eine Art Selbstbeschreibung angesehen werden.
Seiendenklasse
ISA
and
χ(s1,...,sl)
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
...
Arzt
17. Juli 2003
71
© Joachim Biskup, Universität Dortmund
Angestellter
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
Patient
Beispiel für ER-Modellierung: Beziehungenklassen
Beispiel für ER-Modellierung: Beziehungenklasse
Datum
Arbeitgeber
Behandlung
Patient
Behandelnder
beschäftigt bei
Protokoll
Patient
Versicherter
1
1
Versicherung
Versicherungsnehmer
Person
!
Versicherungsgesellschaft
ISA
!
ISA
Anamnese
AOK
Ersatzkasse
verordnete
Therapie
Untersuchung /
Befunde
Privatkasse
Beschwerden
durchgeführte
Therapie
Diagnose
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
73
© Joachim Biskup, Universität Dortmund
Beispiel für ER-Modellierung: Aggregation und Regeln
Sonstiges
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
74
17. Juli 2003
76
Beispiel für ER-Modellierung: Klassen
Name, Vorname, Geschlecht, Geburtstag, Geburtsort
Jung
Alt
Vorfahr
Datum
Patient
Behandelnder
Behandlung
1
Elternschaft
Protokoll
behandlung(pat,dat,prot,beh)
Kind
Eltern
1
Dokumentation
dat, prot, beh
Patient
1
Kind
Anonym
Mutterschaft
Karteikarte
Kind
1
1
Geschlecht
Vaterschaft
!
ISA
Jahrgang
dok(patient,kartei)
Mutter
Vater
andere Merkmale
Frau
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
75
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
Mann
Beispiel für ER-Modellierung: Klassen mit Regeln
Jung
Alt
Vorfahr
1.4 Formalisierung: Logik und Mengenlehre
Jung := Kind
Alt := Eltern
or
Jung := Kind
Alt := Alt
and
Eltern = Jung
Elternschaft
or
Kind := Kind
Eltern := Mutter
Kind
Eltern.Geschlecht = weiblich
Kind := Kind
Eltern := Vater
Eltern
Geschlecht
Eltern.Geschlecht = männlich
Patient
Kind := Kind
Mutter := Eltern
Kind
Kind := Kind
Vater := Eltern
Kind
1
1
Mutterschaft
Vaterschaft
!
ISA
Mutter
Vater
Frau
© Joachim Biskup, Universität Dortmund
Mann
Informationssysteme: Modelle und Architekturen - Modellierung: Wirklichkeit und Modell
17. Juli 2003
77
© Joachim Biskup, Universität Dortmund
Prädikatenlogik
∪n ∈ IN Fn mit Fn = {f0n, f1n, f2n...} für einfache Seiende
Funktionszeichen: F =
•
Individuenvariablen: V = {v0,v1,v2,...} für unbestimmte (‘‘beliebige’’) Seiende
•
Terme: induktiv aus Funktionszeichen und Individuenvariablen gebildet,
für (zusammengesetzte) Seiende oder
andere durch die Teilterme t1,...,tn bezeichnete Gegebenheit
Grundterme: Terme ohne Individuenvariablen.
•
Prädikatenzeichen: P = ∪n ∈ IN Pn mit Pn = {P0n, P1n, P2n, ...}
Funktionszeichen
speziell: Konstantenzeichen
•
Formeln (speziell Aussagen)
bieten Ausdruckmittel für
n-stelliges Prädikatenzeichen und t1,...,tn Terme:
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
80
aussagenlogische Verknüpfungen
(prädikatenlogische) Quantoren
Aggregation
Verallgemeinerung
Klassenbildung
Aussonderung
Pn(t1,...,tn) (atomare) Formel
- für Φ und Ψ Formeln und x eine Individuenvariable:
(Φ ∧ Ψ), (Φ ∨ Ψ), (¬Φ), (∀x)Φ, (∃x)Φ Formeln
© Joachim Biskup, Universität Dortmund
17. Juli 2003
atomare Formeln (speziell Aussagen)
bezeichnen (grundlegende)
Beziehungen, Eigenschaften
Gleichheitszeichen: = , Element aus
für Identität zwischen Seienden
Formeln (1. Stufe): induktiv aus Prädikatenzeichen und Termen
mit aussagenlogischen Junktoren und Quantoren für Individuen gebildet,
für Aussagen und Aussageformen über Seiende, Beziehungen und Eigenschaften:
- für
Terme
bezeichnen Seiende
Prädikatenzeichen
P2
Pn
78
Individuenvariablen
für mögliche Beziehungen und Eigenschaften (Attribute)
•
17. Juli 2003
Prädikatenlogik und ER-Modellierung
•
•
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
.
.
.
17. Juli 2003
79
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
Syntax
Funktionszeichen
Individuenvariablen
Struktur M = (d,δ) und Variablenbelegung ß legen Bedeutung aller Sprachmittel fest:
1. ß auf beliebige Terme fortsetzen:
Terme
atomare
Formeln
Prädikatenzeichen
2. Formeln auswerten:
Formeln
š,›™
x, x
Semantik
Struktur (Interpretation): M = (d,δ) mit
d nichtleere (Werte-) Menge (Universum)
δ Zuordnung
×i=1,...,n
n
δ(P ) ⊂ ×i=1,...,n
δ(fn) :
von Funktionszeichen zu Funktionen auf d,
und von Prädikatenzeichen zu Relationen auf d:
(Gleichheitszeichen = stets durch {(x,x) | x ∈ d} interpretiert)
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
81
:gdw
|=M,ß Φ und |=M,ß Ψ
|=M,ß (Φ ∨ Ψ)
:gdw
|=M,ß Φ oder |=M,ß Ψ
|=M,ß (¬Φ)
:gdw
nicht |=M,ß Φ
|=M,ß (∀x) Φ
:gdw
für alle ß' mit ß =x ß' gilt |=M,ß' Φ
|=M,ß (∃x) Φ
:gdw
es gibt ß' mit ß =x ß' mit |=M,ß' Φ
ß =x ß'
die Variablenbelegungen ß und ß' sind für alle Variablen gleich,
bis auf möglicherweise für die Variable x
bedeutet hier:
© Joachim Biskup, Universität Dortmund
:gdw für alle Belegungen ß gilt : |=M,ß Φ
•
{M | Φ ist gültig in M}.
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
:gdw es gibt Struktur M, die Modell von Φ ist
Unerfüllbarkeit:
:gdw es gibt keine Struktur M,
die Modell von Φ ist
logische Implikation:
•
Formel (-menge) Φ impliziert logisch Formel (-menge) Ψ, Φ |= Ψ,
:gdw Mod (Φ) ⊂ Mod (Ψ)
82
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
17. Juli 2003
17. Juli 2003
84
Bildung neuer Mengen aus vorgegebenen Mengen, hier insbesondere:
aus einer Menge d von (einfachen) Werten
neue Mengen von möglicherweise strukturierten Werten induktiv gewinnen:
Bildung von Teilmengen oder ausgesonderten Mengen:
ist M = (d,δ) eine Struktur und
ist Φ eine Formel, in der die Variablen x1,...,xk frei vorkommen,
so die durch Φ (aus ×i=1,...,k d) ausgesonderte Menge konstruieren:
Allgemeingültigkeit, Erfüllbarkeit, Unerfüllbarkeit, logische Implikation:
- hier deklarativ definiert
- führen aus dem Bereich des (algorithmisch) Entscheidbaren hinaus
- verbleiben mit Ausnahme der Erfüllbarkeit im Bereich des (algorithmisch) Aufzählbaren
© Joachim Biskup, Universität Dortmund
17. Juli 2003
ist d eine nichtleere Menge,
so aus d induktiv eine Klasse κd von Mengen konstruieren:
d ist in κd
sind m, n aus κd, so auch
m×n
kartesisches Produkt,
m∪n
Vereinigung,
℘m
Potenzmenge
:gdw jede Struktur M ist Modell von Φ
Erfüllbarkeit:
Formel Φ ist unerfüllbar
•
|=M,ß (Φ ∧ Ψ)
Mengenlehre
:=
Formel Φ ist erfüllbar
•
17. Juli 2003
Allgemeingültigkeit:
Formel Φ ist allgemeingültig
•
(ß(t1),...,ß(tn)) ∈ δ(Pn)
d
Modellklasse einer Formel (-menge) Φ:
Mod (Φ)
•
:gdw
Modell einer Formel:
M = (d,δ) ist Modell einer Formel Φ,
|=M Φ (Φ gültig in M)
•
d→d
|=M,ß Pn(t1,...,tn)
ß:V→d
Variablenbelegung zur Struktur M = (d,δ):
:= δ(f0)
ß(f0)
n
ß(f (t1,...,tn)) := δ(fn)(ß(t1),...,ß(tn))
dM,Φ := { (ß(x1),...,ß(xk))
83
© Joachim Biskup, Universität Dortmund
|
ß ist Variablenbelegung mit |=M,ß Φ }
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
Logik und Informationssysteme
Administrator
Definitionssprache
Anwender
Änderungssprache
1.5 Architekturen
Anwender
Anfragesprache
Formate (Typen)
Aufzählungen:
Anfrage:
für Aufzählungen
(dauerhaft gespeicherte
Aussagen in der Form
von “Daten“)
Aussagen
und
Antwortformat
Bedingungen
Regeln
Algorithmus
zur Bestimmung der Implikationsbeziehung
alle implizierten Aussagen entsprechend Antwortformat
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Formalisierung: Logik und Mengenlehre
17. Juli 2003
85
Architektur eines Informationssystems: Grobstruktur
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
86
17. Juli 2003
88
Anwendungsumgebungen für ein Informationssystem
Einsatz-Schnittstelle
Anwendungsumgebung
Administrator
Benutzer
Netz
InformationssystemSchnittstelle
Entwurfsumgebung
Arbeitsplatzumgebung
...
Programmierumgebung
...
Netzumgebung
...
"eigentliches"
Informationssystem
BasissystemSchnittstelle
(virtuelles) Basissystem
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
87
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
Entwurfsumgebung
Arbeitsplatzumgebung
•
unterstützt die Modellierung eines Anwendungsfalles
durch eine häufig Administrator genannte Person (oder Personengruppe)
•
unterstützt die Tätigkeiten von Benutzern
entsprechend ihrer jeweiligen Verpflichtungen und Rollen in einem Unternehmen
•
stellt (hoffentlich) graphische Werkzeuge zur Verfügung
•
Beispiele: Büroautomation oder rechnergestützter Entwurf technischer Erzeugnisse
•
Modellierung umfasst im Allgemeinen
sowohl die dynamischen als auch die statischen Gesichtspunkte
•
Dienste eines Informationssystems in zweierlei Formen ansprechbar:
- Datenmanipulationssprache wird interaktiv und selbständig
vom Endbenutzer direkt verwendet
•
als zeitunabhängig angesehene Teile müssen formalisiert werden
zu einem (Datenbank-) Schema
•
dies wird vereinbart über
eine an der Informationssystem-Schnittstelle angebotene Datendefinitionssprache
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
- vordefinierte, möglicherweise parametrisierte Anfragen werden
über Menüs oder ähnliche Formen der Benutzerführung
vom Endbenutzer ausgewählt
89
© Joachim Biskup, Universität Dortmund
Programmierumgebungen
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
90
Netzwerkumgebung
•
Programme in (höherer) Programmiersprache erstellen und ausführen
•
dabei Aufrufe des Informationssystems aus dem jeweiligen Programm ermöglichen
•
dazu an Informationssystem-Schnittstelle angebotene Datenmanipulationssprache in
die jeweilige Wirtssprache (host language) ‘‘einbetten’’
•
zu behandelnde Gesichtspunkte:
- Übersetzung von Wirtssprachenprogrammen mit eingestreuten Aufrufen
des Informationssystems, etwa mit Hilfe einer Präkompilierung
- Interaktion zwischen Prozessen der Wirtssprache und
denen des Informationssystems
- Angleichung der in der Wirtssprache und der im Informationssystem
verwirklichten grundlegenden Datentypen
•
vorliegendes Informationssystem als Komponente
eines größeren, mit Hilfe eines Netzwerkes aufgebauten Gesamtsystems benutzen:
föderierte Systeme, mediierte Systeme, Web-Informationssysteme, ...
•
Gesamtsystem nennt man heterogen,
wenn Komponenten von unterschiedlicher Art (z.B. in der Wahl des Datenmodells)
•
aus der Sicht eines Endbenutzers:
innerer Aufbau des Gesamtsystems und die Unterschiedlichkeit der Komponenten
möglichst weitgehend verborgen
•
aus Sicht der Netzwerkumgebung:
erforderliche Übersetzungs- und Verwaltungsdienste anbieten
- Anpassung der üblicherweise satzorientierten Arbeitsweise der Wirtssprache
an die mengenorientierte Arbeitsweise des Informationssystems
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
91
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
92
Informationssystem-Schnittstelle
Schichtung und Komponenten eines Informationssystems
InformationssystemSchnittstelle
eingebettet
interaktiv, selbständig
Datenmanipulationssprache (DML)
Datendefinitionssprache (DDL)
Sprachanalyse
Vereinbarungen
Änderungen
Anfragen
Aufbereitung
von
Antworten
Antworten
Erklärungen
Relationen (Klassen),
Tupel (Objekte)
Datenwörterbuch
• Datendefinitionssprache (data definition language, DDL): für Vereinbarungen
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Transaktionsverwaltung
MengenSchnittstelle
• Datenmanipulationssprache (data manipulation language, DML):
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
für Änderungen und Anfragen
• Antworten auf Anfragen (oder andere Reaktionen): für Rückgaben
• Erklärungen: für ‘‘benutzerfreundlich’’ aufbereitetete Hinweise, z.B.
interne Schicht
(Datensatz-orientiert)
welche Zwischenergebnisse aufgetreten sind oder
welche (äquivalenten) Umformungen an der Anfrage vorgenommen worden sind
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
93
© Joachim Biskup, Universität Dortmund
konzeptionelle Schicht
•
erledigt die mengenorientierte Verarbeitung von Anfragen und Änderungen
•
leistet die Hauptarbeit der Optimierung
•
Strukturen und Operationen der Mengen-Schnittstelle:
•
•
•
17. Juli 2003
94
verwirklicht Zugriff auf einzelne Tupel (bzw. Objekte)
behandelt diese als zu suchende, zu transportierende oder zu verarbeitende Datensätze
setzt zur Effizienzsteigerung geeignete Zugriffsstrukturen ein
Strukturen der Tupel-Schnittstelle:
-
für Änderungen:
- Relationen (Klassen), Tupel (Objekte)
- Einfügen, Entfernen, Abändern (und weitere Klassenfunktionen)
für Anfragen:
- Relationen (Klassen)
- Relationen- (Klassen-) Algebra (Klassenfunktionen),
möglicherweise Erweiterung durch Rekursion usw
Informationssysteme: Modelle und Architekturen - Architekturen
Informationssysteme: Modelle und Architekturen - Architekturen
interne Schicht
•
© Joachim Biskup, Universität Dortmund
TupelSchnittstelle
•
Operationen der Tupel-Schnittstelle:
-
17. Juli 2003
95
Relationen (Klassen) als Dateien
Zugriffsstrukturen: sequentielle Listen, Indexe, Links
Relationendurchläufe (Klasseniteratoren)
Tupel (Objekte) als Datensätze
Tupelidentifikatoren (Surrogate)
Anlegen und Entfernen von Relationen (Klassen)
Anlegen und Entfernen von Zugriffsstrukturen, insbesondere Sortieren
Öffnen, Schließen von Durchläufen
Bestimmen eines Tupelidentifikators (Surrogates), insbesondere bei Durchläufen
Transport eines Tupels (Objektes) als Datensatz, insbesondere
Herstellen einer Hauptspeicherkopie bzw.
(Zurück-) Schreiben in den dauerhaften Speicher
Erzeugen, Vergleichen, Abändern, Entfernen
von Hauptspeicherkopien von Tupeln (Objekten)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
96
Datenwörterbuch (data dictionary)
Sicht_1
Schema
...
Inhalte des Datenwörterbuchs
Sicht_n
Schema
•
konzeptionelles Schema (conceptual scheme):
im Wesentlichen aufbereitete Form des (Datenbank-) Schemas
•
internes Schema (internal scheme):
von der internen Schicht benötigte, verfeinerte und zusätzliche Angaben,
etwa über Typen, Speicherbereiche, Zugriffsstrukturen oder Durchläufe
•
Sichtschemas (view schemes, external schemes)
stellen die sogenannten Sichten aufbereitet dar
konzeptionelles Schema
internes Schema
•
•
•
Zugriffe auf Datenwörterbuch
vom Informationssystem unterhaltene Datenstruktur
enthält alle Vereinbarungen
in üblicherweise (nach ANSI/X3/SPARC) dreistufiger Form
Zugriffe von
Sprachanalyse/Antwortaufbereitung, konzeptioneller und interner Schicht
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
97
•
Datenwörterbuch wird mit den gleichen oder ähnlichen Mitteln verwirklicht
wie die eigentliche Datenbank.
•
Datenmanipulationssprache kann auch auf das Datenwörterbuch angewendet werden.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
Transaktionsverwaltung
17. Juli 2003
98
Basissystem
(virtueller) flüchtiger und dauerhafter Speicher
•
•
für Mehrbenutzerbetrieb, Konsistenzwahrung, Verlässlichkeit, Fehlertoleranz, ...
Segmente, Blöcke;
Einrichten und Freigeben, Lesen und Schreiben
muss im Allgemeinen schichtenübergreifend angelegt werden,
weil hierbei die konzeptionellen Strukturen und die internen Strukturen
quer zueinander liegen können
SpeicherSchnittstelle
GeräteSchnittstelle
Speichergeräte
...
• (virtuelles) Basissystem:
bietet virtuellen, zweigeteilten Speicher an,
dessen dauerhafter Teil durch geeignete Speichergeräte physisch verwirklicht wird
• Speicher-Schnittstelle:
zum Einrichten/Freigeben sowie Lesen/Schreiben von Blöcken auf den Speichergeräten,
also Transport von Blöcken zwischen den Speichergeräten und den Pufferbereichen
• Geräte-Schnittstelle: zum Benutzen der eigentlichen Speichergeräte
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
99
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
100
Architektur: benutzersichtbarer Teil
Entwurfsumgebung
Arbeitsplatz- . . .
umgebung
Netzumgebung
Programmier- . . .
umgebung
Datenmanipulationssprache (DML)
Änderungen
Vereinbarungen
EinsatzSchnittstellen
eingebettet
interaktiv, selbständig
Datendefinitionssprache (DDL)
...
Anfragen
Antworten
Erklärungen
Entwurfsumgebung
InformationssystemSchnittstelle
Entwurfsumgebung
Arbeitsplatz- . . .
umgebung
Netzumgebung
Programmier- . . .
umgebung
Datendefinitionssprache (DDL)
Sicht i
Schema
Vereinbarungen
Aufbereitung
von
Antworten
Sprachanalyse
..
.
..
.
Sprachanalyse
Sicht i
Schema
Relationen (Klassen),
Tupel (Objekte)
konzeptionelles
Schema
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Transaktionsverwaltung
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
internes Schema
Datenmanipulationssprache (DML)
Änderungen
Anfragen
Antworten
Erklärungen
interaktiv, selbständig
InformationssystemSchnittstelle
Datendefinitionssprache (DDL)
Aufbereitung
von
Antworten
Vereinbarungen
..
.
MengenSchnittstelle
konzeptionelles
Schema
internes Schema
TupelSchnittstelle
Relationen (Klassen),
Tupel (Objekte)
Transaktionsverwaltung
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
TupelSchnittstelle
..
.
(virtueller) flüchtiger und dauerhafter Speicher
SpeicherSchnittstelle
(virtueller) flüchtiger und dauerhafter Speicher
© Joachim Biskup, Universität Dortmund
konzeptionelles
Schema
17. Juli 2003
101
© Joachim Biskup, Universität Dortmund
interaktiv, selbständig
Datendefinitionssprache (DDL)
Arbeitsplatz- . . .
umgebung
Netzumgebung
Programmier- . . .
umgebung
Vereinbarungen
..
.
Datenmanipulationssprache (DML)
Änderungen
Sprachanalyse
Sicht i
Schema
Anfragen
Antworten
Erklärungen
internes Schema
Änderungen
Anfragen
Antworten
Erklärungen
InformationssystemSchnittstelle
Entwurfsumgebung
Relationen (Klassen),
Tupel (Objekte)
Transaktionsverwaltung
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
..
.
Vereinbarungen
Sprachanalyse
Aufbereitung
von
Antworten
..
.
Netzumgebung
Programmier- . . .
umgebung
TupelSchnittstelle
konzeptionelles
Schema
...
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Transaktionsverwaltung
17. Juli 2003
Änderungen
Anfragen
Antworten
Erklärungen
InformationssystemSchnittstelle
internes Schema
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
TupelSchnittstelle
interne Schicht
(Datensatz-orientiert)
Aufbereitung
von
Antworten
Relationen (Klassen),
Tupel (Objekte)
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Transaktionsverwaltung
MengenSchnittstelle
konzeptionelles
Schema
internes Schema
Relationen (Klassen),
Tupel (Objekte)
Transaktionsverwaltung
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
MengenSchnittstelle
(virtueller) flüchtiger und dauerhafter Speicher
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
TupelSchnittstelle
internes Schema
GeräteSchnittstelle
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
TupelSchnittstelle
GeräteSchnittstelle
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
SpeicherSchnittstelle
...
Speichergeräte
GeräteSchnittstelle
interne Schicht
(Datensatz-orientiert)
Speichergeräte
SpeicherSchnittstelle
interne Schicht
(Datensatz-orientiert)
(virtueller) flüchtiger und dauerhafter Speicher
SpeicherSchnittstelle
102
..
.
(virtueller) flüchtiger und dauerhafter Speicher
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
MengenSchnittstelle
EinsatzSchnittstellen
eingebettet
Datenmanipulationssprache (DML)
Sprachanalyse
Sicht i
Schema
MengenSchnittstelle
interne Schicht
(Datensatz-orientiert)
...
Arbeitsplatz- . . .
umgebung
Datendefinitionssprache (DDL)
..
.
..
.
konzeptionelles
Schema
Vereinbarungen
Sicht i
Schema
Aufbereitung
von
Antworten
Aufbereitung
von
Antworten
eingebettet
Datenmanipulationssprache (DML)
interaktiv, selbständig
InformationssystemSchnittstelle
InformationssystemSchnittstelle
Architektur: Basissystem
eingebettet
interaktiv, selbständig
Datendefinitionssprache (DDL)
...
Anfragen
Antworten
Erklärungen
Informationssysteme: Modelle und Architekturen - Architekturen
Architektur: ‘‘eigentliches Informationssystem’’
Entwurfsumgebung
eingebettet
Speichergeräte
Informationssysteme: Modelle und Architekturen - Architekturen
EinsatzSchnittstellen
Änderungen
Relationen (Klassen),
Tupel (Objekte)
Speichergeräte
SpeicherSchnittstelle
GeräteSchnittstelle
...
EinsatzSchnittstellen
..
.
GeräteSchnittstelle
...
...
Datenmanipulationssprache (DML)
Sprachanalyse
Sicht i
Schema
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
Netzumgebung
MengenSchnittstelle
interne Schicht
(Datensatz-orientiert)
interne Schicht
(Datensatz-orientiert)
Programmier- . . .
umgebung
eingebettet
interaktiv, selbständig
..
.
...
Arbeitsplatz- . . .
umgebung
EinsatzSchnittstellen
...
Speichergeräte
(virtueller) flüchtiger und dauerhafter Speicher
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
103
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
104
föderierte Systeme
client_1
mediierte Syteme
client_m
global
answer
global
query
global
query
federation
designer
...
query
decomposition
and translation
at design time
query
decomposition
and translation
mediator
schema
answer
integration
and layout
schema integration
111111111111111
000000000000000
.
..
federated
schema
global
answer
mediator
designer
11111111111111
00000000000000
..
.
..
.
..
.
..
.
..
.
..
.
..
.
...
..
.
..
.
client_i
wrapper
construction
at contraction
time
answer
integration
and layout
local data
materialization
local
answer
subquery
1111111111
0000000000
local
schema
local
schema
..
.
..
.
..
.
query
processing
local
data
00
11
11
00
local
data
111111111
000000000
local
schema
query
processing
1
0
0
1
..
.
..
.
..
.
111111111
000000000
local
data
source_m
source_1
query
1
0
0
1
1
0
processing
source_j
at contraction time
at design time
at design time
at query time
CLOSED WORLD
(more) OPEN WORLD
at query time
(more) static environment
(more) organizational structures
© Joachim Biskup, Universität Dortmund
local
answer
...
..
.
..
.
subquery
(more) dynamic environment
(more) contractual relationships
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
105
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
17. Juli 2003
106
föderiert versus mediiert
client_1
client_m
global
query
global
answer
global
query
11111111111111
00000000000000
..
.
query
decomposition
and translation
wrapper
construction
at contraction
time
materialization
local
answer
subquery
111111111
000000000
..
.
..
.
..
.
processing
00
11
11
00
local
data
query
local
data
processing
1
0
0
1
source_m
source_1
local
schema
..
.
..
.
..
.
local
schema
query
at design time
at contraction time
CLOSED WORLD
(more) static environment
(more) organizational structures
© Joachim Biskup, Universität Dortmund
Informationssysteme: Modelle und Architekturen - Architekturen
processing
source_j
at design time
at query time
at query time
query
1
0
0
1
1
0
.
..
1111111111
0000000000
111111111
000000000
local
answer
..
.
subquery
relationale Systeme mit strukturierten Daten
answer
integration
and layout
local data
..
.
at design time
query
decomposition
and translation
mediator
schema
answer
integration
and layout
schema integration
111111111111111
000000000000000
.
..
federated
schema
.
..
local
data
global
answer
mediator
designer
federation
designer
local
schema
Teil II
..
.
..
.
..
.
..
.
..
.
..
.
.
..
..
.
..
.
client_i
(more) OPEN WORLD
(more) dynamic environment
(more) contractual relationships
17. Juli 2003
107
© Joachim Biskup, Universität Dortmund
Informationssysteme
17. Juli 2003
108
Datenmodell
(abstrakter) Datentyp für Informationssysteme
2 Relationales Datenmodell: Strukturen
- Strukturen:
- Operationen:
Schema und Instanzen
Änderungen und Anfragen
bekannte Datenmodelle:
•
•
•
•
•
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen
17. Juli 2003
109
hierarchisch
Netzwerkrelational
logikorientiert
objektorientiert
...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen
17. Juli 2003
110
17. Juli 2003
112
relationales Datenmodell
Spezialfall eines logikorientierten Modells
2.1 relationale Strukturen: Theorie
- mächtige Abstraktion von Dateien gleichartiger Records
- modelltheoretischer Ansatz: Relationen (Tabellen) stellen Strukturen dar
- werteorientiert: aus Benutzersicht erfolgen Identifikationen nur über Werte
- Stellen der Relationensymbole bestimmen durch:
- Attribute (attributes)
(Spaltenüberschriften der Tabellen)
- semantische Bereichsnamen
(anwendungsorientierte Typbezeichner)
- Domänen (domains)
(syntaktische Wertemengen von Typen)
- außer Konstantenzeichen keine ‘‘echten Funktionszeichen’’;
Konstantenzeichen werden eindeutig, durch sich selbst interpretiert;
Annahme eindeutiger Namen (unique name assumption)
- keine Rekursionen (bei Anfragen, Sichtdefinitionen, semantischen Bedingungen)
- semantische Bedingungen:
eingeschränkte Klasse von Hornformeln
für lokale (innerrelationale) und globale (zwischenrelationale) Bedingungen
- einfacher Ansatz für ‘‘negative Information’’
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen
17. Juli 2003
111
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
Semantische Bedingungen
Schreibweisen
eingeschränkte Klasse von Hornformeln
(der implikativen Form: A0 :- A1, A2, ... , Am)
mit Bedeutung: “wenn die Prämissen A1 und A2 und ... Am gelten, so auch die Konklusion A0”)
in praktischen Systemen meist nur Spezialfälle verfügbar
•
funktionale Abhängigkeiten (functional dependencies)
Y = Y' :- R(X1,...,Xk, Y , Z1,...,Zl), R(X1,...,Xk, Y' , Z'1,...,Z'l)
(manchmal Variablen als ‘‘Attribute’’ auffassen, dann kurz als: X1,...,Xk → Y
•
)
mehrwertige Abhängigkeiten (multivalued dependencies)
R(X1,...,Xk, Y'1,...,Y'l, Z1,...,Zm) :R(X1,...,Xk, Y1,...,Yl, Z1,...,Zm), R(X1,...,Xk, Y'1,...,Y'l, Z'1,...,Z'm)
(kurz als: X1,...,Xk → → Y1,...,Yl / Z1,...,Zm )
•
unendliche Menge der Attribute
R, S,..., X,Y, Z
endliche Mengen von Attributen
B
Menge der semantischen Bereichsnamen
C
unendliche Menge der Konstantenzeichen
b : B → ℘C
ordnet semantischen Bereichsnamen Domänen zu
R
Menge der Relationensymbole
µ:X→C
Tupel mit
dom µ := X ⊂endlich A
Definitionsbereich
oder als
µY mit
µY : dom µ ∩ Y → C,
µY(A) := µ(A)
für A ∈ dom µ ∩ Y
Enthaltenseinsabhängigkeiten (inclusion dependencies)
R1(X1,...,Xk) :- S1(X1,...,Xk)
mit R1 und S1 Projektionen von Basisrelationen R und S
(manchmal “algebraisch” ausgedrückt: πX1,...,Xk (S) ⊂ πX1,..., Xk(R)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
113
Relation
dom r := dom µ für µ ∈ r
Definitionsbereich
© Joachim Biskup, Universität Dortmund
RS = < <R1 | X1 | SC1> ,..., <Rn | Xn | SCn> | SC | a >
Instanz (oder gültige Ausprägung) zu < R | X | SC > :gdw
i)
d ⊂endlich C
ii)
dom r = X und r ⊂endlich {µ | µ : X → d}
17. Juli 2003
114
Syntax:
Relationensymbol
Attribute
lokale semantische Bedingungen
Semantik: (d,r)
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
Relationales Datenbankschema und Instanz
< R | X | SC > (Relationen-) Schema mit
- R∈R
- X ⊂endlich A
- SC
Einschränkung von µ auf Y
r ⊂endlich {µ | µ : X → C} für ein X ⊂ A
Relationenschema und Instanz
Syntax:
A
A
µ = (  1  , …,  n  )
 µ ( A 1 )
 µ ( A n )
µ = ( µ(A1), ... , µ(An) )
für X = {A1,...,An} kann man µ aufschreiben als
Verbundabhängigkeiten (join dependencies)
Verallgemeinerung von mehrwertigen Abhängigkeiten
•
A
(relationales Datenbank-) Schema mit
- < Ri | Xi | SCi >
- SC
Relationenschema mit Ri ≠ Rj für i ≠ j
(globale) semantische Bedingungen
- a : ∪i=1,...,n Xi → B
Vereinbarung der semantischen Bereichsnamen
Semantik:
M = (d,r1,...,rn) Instanz (oder gültige Ausprägung) zu RS :gdw
iii) (d,r) ist Modell von SC
i)
sat< R | X | SC > := { r | r ist Instanz zu < R | X | SC > }
d ⊂endlich C
ii) (d,ri) ist Instanz zu < Ri | Xi | SCi >
iii) (d,r1,...,rn) ist Modell von SC
iv) falls µ ∈ ri und A ∈ Xi , dann gilt µ(A) ∈ b ° a (A)
satRS := { (d,r1,...,rn) | (d,r1,...,rn) ist Instanz zu RS }
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
115
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
116
Beispiel: (vereinfachte) Arztpraxis als ER-Diagramm
Name
Beispiel: (vereinfachte) Arztpraxis als Hypergraph des Schemas
Knoten:
runde Hyperkanten:
rechteckige Hyperkanten:
Geschlecht
Attribute
Relationenschemas
(nichttrivial benutzte) semantische Bereichsnamen
Geschlecht
Person
Name
Eltern
Patient
Arzt
PERSON
ELT
Kind
Eltern
Behandlung
Elternschaft
Patient
Arzt
ArtPro
BEH
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
117
Beispiel: (vereinfachte) Arztpraxis als Datenbankschema
<
< PERSON | {Name, Geschlecht}
| {Name → Geschlecht}
< BEH
| {Patient, Arzt, ArtPro} | ∅
< ELT
| {Name, Eltern}
| ∅
|
{ πPatient (BEH) ⊂ πName (PERSON),
πArzt (BEH) ⊂ πName (PERSON),
πName (ELT) ⊂ πName (PERSON),
πEltern (ELT) ⊂ πName (PERSON) }
|
a (Name) := a (Patient) := a (Arzt) := a (Eltern)
:= Mensch,
a (Geschlecht)
:= Geschlecht,
a (ArtPro)
:= ArtPro
>
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
118
Beispiel: Tabellengerüste zum relationalen Datenbankschema
RS =
b (Mensch)
© Joachim Biskup, Universität Dortmund
ArtPro
PERSON
>,
>,
>
BEH
Name
Geschlecht
Mensch
Geschlecht
Patient
Arzt
ArtPro
Mensch
Mensch
ArtPro
ELT
Name
Eltern
Mensch
Mensch
:= Σ* ⊂ C
b (Geschlecht) := { mann, weib } ⊂ C
b (ArtPro)
:= { untersuchung, beratung, hausbesuch, labor, röntgen } ⊂ C
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
119
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
120
Beispiel: eine Instanz zum relationalen Datenbankschema
BEH
© Joachim Biskup, Universität Dortmund
2.2 relationale Meta-Strukturen: Theorie
Name
Geschlecht
Name
Eltern
Mensch
Geschlecht
Mensch
Mensch
wilhelmine
fritz
anton
theresia
maria
hugo
alfons
josef
gerda
weib
mann
mann
weib
weib
mann
mann
mann
weib
maria
hugo
alfons
anton
anton
theresia
theresia
gerda
anton
anton
theresia
wilhelmine
fritz
wilhelmine
fritz
josef
PERSON
ELT
Patient
Arzt
ArtPro
Mensch
Mensch
ArtPro
maria
maria
maria
anton
anton
anton
fritz
theresia
gerda
gerda
gerda
josef
josef
josef
josef
josef
labor
hausbesuch
röntgen
untersuchung
labor
beratung
beratung
röntgen
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Theorie
17. Juli 2003
121
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Meta-Strukturen: Theorie
17. Juli 2003
122
17. Juli 2003
124
Schema als Selbstbeschreibung
•
•
mit den gleichen Techniken wie die Instanzen behandeln
die als zeitunabhängig angesehenen Gegebenheiten des gedachten
“Unternehmens relationale Datenbank” mit semantischen Begriffen
vereinfacht modellieren:
Relationensymbol
Stellenbezeichnung
Schlüsselzugehörigkeit
Relationensymbol
Stellenbezeichnung
Attribut
Attribut
1
1
Typ
Enthaltensein
semantischer
Bereichsname
Teilmenge
Obermenge
1
1
Werte
Relationensymbol
Stellenbezeichnung
Attribut
Domäne
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Meta-Strukturen: Theorie
17. Juli 2003
123
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Meta-Strukturen: Theorie
(vereinfachtes) ‘‘Metaschema’’ für relationale Datenbanken
RSSchema = <
< RELATION
| {Symbol, Attribut, Schlüssel} | {Symbol, Attribut → Schlüssel}
< TYP
| {Attribut, SemBereich}
| {Attribut → SemBereich}
< WERTE
| {SemBereich, Domäne}
| {SemBereich → Domäne}
< ENTHALTEN | {Teil_Symbol, Teil_Attribut, Ober_Symbol, Ober_Attribut} | Ø
|
{ πTeil_Symbol, Teil_Attribut (ENTHALTEN) ⊂ πSymbol, Attribut (RELATION),
πOber_Symbol, Ober_Attribut (ENTHALTEN) ⊂ πSymbol, Attribut (RELATION) }
|
a (Symbol) := a (Teil_Symbol) := a (Ober_Symbol) := RelationenId,
a (Attribut) := a (Teil_Attribut) := a (Ober_Attribut) := AttributId,
a (SemBereich)
:= SemBereich,
a (Domäne)
:= Domäne,
a (Schlüssel)
:= SchlüsselInd
>
mit zum Beispiel:
b (RelationId)
:=
b (Domäne)
:=
b (SchlüsselInd) :=
© Joachim Biskup, Universität Dortmund
b (AttributId) := b (SemBereich) := Σ*
{boolean, integer, cardinal, real, string, ...}
{false, true}
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Meta-Strukturen: Theorie
Hypergraph zum relationalen Datenbankschema für Schemas
(“Metaschema’’)
>,
>,
>,
>
RelationenId
AttributId
Teil_Symbol
Teil_Attribut
Ober_Symbol
Ober_Attribut
Symbol
Domäne
17. Juli 2003
125
© Joachim Biskup, Universität Dortmund
Schlüssel
Attribut
SemBereich
⊂C
⊂C
⊂C
ENTHALTEN
RELATION
TYP
WERTE
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Meta-Strukturen: Theorie
17. Juli 2003
126
Beispiel: Instanz zum relationalen Datenbankschema für Schemas
RELATION
Symbol
Attribut
Schlüssel
RelationenId
AttributId
SchlüsselInd
PERSON
PERSON
BEH
Name
Geschlecht
true
false
true
true
BEH
BEH
ELT
ELT
TYP
true
true
true
Name
Eltern
SemBereich
SemBereich
Domäne
AttributId
SemBereich
SemBereich
Domäne
Name
Patient
Mensch
Mensch
Mensch
Geschlecht
string
weibmann
Arzt
Eltern
Gechlecht
Mensch
Mensch
Geschlecht
ArtPro
ArtPro
ubhlr
ENTHALTEN
WERTE
Die Pragmatik wird in den Übungsaufgaben anhand von Beispielen erarbeitet.
Attribut
ArtPro
© Joachim Biskup, Universität Dortmund
Patient
Arzt
ArtPro
2.3 relationale Strukturen: Pragmatik
Teil_Symbol
Teil_Attribut
Ober_Symbol
Ober_Attribut
RelationenId
AttributId
RelationenId
AttributId
BEH
BEH
ELT
ELT
Patient
Arzt
PERSON
PERSON
Name
Eltern
PERSON
PERSON
Name
Name
Name
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Meta-Strukturen: Theorie
Anhand der dabei gewonnenen Erfahrungen kann man grobe Faustregeln aufstellen,
wie man die Bestandteile einer Modellierung (Konstrukte eines ER-Diagramms)
in die Komponenten eines relationalen Datenbankschemas überträgt.
Name
17. Juli 2003
127
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Pragmatik
17. Juli 2003
128
ER-Diagramm für Präsidenten-Datenbank (Ausschnitt)
Name
Person
2.4 relationale Strukturen: Praxis (Oracle-SQL)
Vice_Pres_Name
ISI
Vice_
President
...
President
born_in
Spouse
married
Pres_Name
Spouse_Name
Adminis
-tration
State
...
Admin
President
State_Name
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
129
© Joachim Biskup, Universität Dortmund
Hypergraph zum Oracle-Schema für Präsidenten-Datenbank
Pres_Hobby
create table State (
State_Name
Admin_Entered
Year_Entered
);
Vice_Pres_Name
Hobby
Admin_Nr
Pres_Name
Spouse_Name
Pr-Age
Sp_Age
Nr_Children
Mar_Year
Year_Inaugurated
Birth_Year
Years_Serv
Death_Age
Party
State_Born
Administration
State_Name
Admin_Entered State
Year_Entered
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
varchar2(17)
number(3),
number(4)
create table President (
Pres_Name
varchar2(17)
Pres_Marriage
Birth_Year
Years_Serv
Death_Age
Party
State_Born
Vice_President
17. Juli 2003
130
17. Juli 2003
132
Oracle-Schema für Präsidenten-Datenbank
Admin_Pr_Vp
President
Admin_Pr_Vp
number(4)
number(2)
number(3),
varchar2(12)
varchar2(17)
primary key,
not null
primary key
check (Pres_Name LIKE '% _'),
not null,
not null,
not null,
not null
);
create table Pres_Hobby (
Pres_Name
varchar2(17)
Election_Year
Election Candidate
Votes
Winner_Looser_Indic
Hobby
references President
on delete cascade,
varchar2(18),
primary key ( Pres_Name, Hobby )
);
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
131
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
create table Administration (
Admin_Nr
number(3),
Pres_Name
varchar2(17)
Year_Inaugurated number(4)
references President,
not null,
primary key ( Admin_Nr, Pres_Name ),
check (Year_Inaugurated
BETWEEN 1785+4*Admin_Nr AND 1789+4*Admin_Nr)
create table Pres_Marriage (
Pres_Name
varchar2(17)
Spouse_Name
varchar2(17),
Pr_Age
number(3)
Sp_Age
number(3)
Nr_Children
number(2)
Mar_Year
number(4)
);
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
create table Election (
Election_Year
Candidate
Votes
Winner_Loser_Indic
133
© Joachim Biskup, Universität Dortmund
... references <table_identifier>
vereinbart attribute_identifier als
Attribut (Stellenbezeichner) mit Domäne (Type) domain
... on delete cascade
semantische Bedingungen:
verlangt einen definierten Wert,
in Schlüsselvereinbarungen eingeschlossen
... primary key
vereinbart entsprechendes Attribut als (Primär-) Schlüssel,
d.h. insbesondere die funktionale Abhängigkeit
“entsprechendes Attribut’’ → “alle Attribute’’
primary key (<attribute_list>)
vereinbart die aufgelisteten Attribute als (Primär-) Schlüssel,
d.h. insbesondere die funktionale Abhängigkeit
“aufgelistete Attribute’’ → “alle Attribute’’
check ( <tuple_condition> )
verlangt bei Einfügungen und Änderungen
die genannte Bedingung
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
17. Juli 2003
134
bezieht sich auf den
Schlüssel des genannten Relationensymbols,
vereinbart eine Enthaltenseinsabhängigkeit zwischen
dem entsprechenden Attribut und
dem Schlüssel des genannten Relationensymbols
vereinbart table_identifier als Relationensymbol
Attribute:
not null
not null,
primary key ( Election_Year, Candidate )
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
Relationensymbole:
<attribute_identifier> <domain> ...
number(4),
varchar2(17),
number(3),
char(1)
);
einige syntaktische Regeln für Oracle-SQL-Schemavereinbarungen
create table <table_identifier> ( ... )
not null,
not null,
not null,
not null,
primary key ( Pres_Name, Spouse_Name )
);
create table Admin_Pr_Vp (
Admin_Nr
number(3),
Pres_Name
varchar2(17),
Vice_Pres_Name varchar2(17),
foreign key ( Admin_Nr, Pres_Name ) references Administration,
primary key ( Admin_Nr, Pres_Name, Vice_Pres_Name ),
check (Pres_Name != Vice_Pres_Name)
);
© Joachim Biskup, Universität Dortmund
references President,
vereinbart eine “kaskadierende Folgeaktion’’
(z.B. Entfernen weiterer Tupel)
bei Verletzung der Enthaltenseinsabhängigkeit
durch Enfernen eines Tupels
bezüglich des genannten Relationensymbols
foreign key (<attribute_list>) references <table_identifier>
bezieht sich auf den
Schlüssel des genannten Relationensymbols,
vereinbart eine Enthaltenseinsabhängigkeit zwischen
den aufgelisteten Attributen und
dem Schlüssel des genannten Relationensymbols
135
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
136
Oracle-SQL Syntax für “CREATE TABLE’’
relational_table::=
GLOBAL
Auszug aus:
Oracle 9i - SQL Reference, Release 2 (9.2), March 2002, Part No.A96540-01, pp. 15-7 bis 15-79
TEMPORARY
schema
CREATE
.
TABLE
table
DELETE
ON
(
create_table::=
relational_properties
physical_properties
COMMIT
)
ROWS
PRESERVE
table_properties
;
relational_table
object_table
XMLtype_table
relational_properties::=
,
inline_constraint
Im Folgenden wird nur der erste Fall, relationale Tabellen, sehr kurz behandelt.
DEFAULT
column
expr
inline_ref_constraint
datatype
out_of_line_constraint
out_of_line_ref_constraint
supplemental_logging_props
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
137
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
138
17. Juli 2003
140
physical_properties::=
data_segment_compression
3 Relationales Datenmodell: Operationen
segment_attributes_clause
segment_attributes_clause
data_segment_compression
HEAP
ORGANIZATION
segment_attributes_clause
INDEX
index_org_table_clause
EXTERNAL
external_table_clause
,
CLUSTER
cluster
(
column
)
table_properties::=
column_properties
table_partitioning_clauses
row_movement_clause
CACHE
NOROWDEPENDENCIES
MONITORING
NOCACHE
ROWDEPENDENCIES
NOMONITORING
parallel_clause
© Joachim Biskup, Universität Dortmund
enable_disable_clause
AS
subquery
Informationssysteme: Relationales Datenmodell: Strukturen - relationale Strukturen: Praxis (Oracle-SQL)
17. Juli 2003
139
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen
relationales Datenmodell
•
Strukturen
Schema:
3.1 relationale Anfrageoperationen: Theorie
RS = < <R1 | X1 | SC1> ,..., <Rn | Xn | SCn> | SC | a > mit
-
< Ri | Xi | SCi >
SC
Relationenschema mit Ri ≠ Rj für i ≠ j
(globale) semantische Bedingungen
-
a : ∪i=1,...,n Xi → B
Vereinbarung der semantischen Bereichsnamen
Instanzen: M = (d,r1,...,rn) mit
i) d ⊂endlich C
ii) (d,ri) ist Instanz zu < Ri | Xi | SCi >
iii) (d,r1,...,rn) ist Modell von SC
iv) falls µ ∈ ri und A ∈ Xi , dann gilt µ(A) ∈ b ° a (A)
•
Operationen
Änderungen:
- elementar:
‘‘insert Ri(c1, ... ck)’’ und ‘‘delete Ri(c1, ... ck)’’ mit cj Konstantenzeichen
- als Transaktion: ‘‘begin op1 ; ... ; opm end’’ mit opj elementar
- deklarativ:
Konstantenzeichen durch Anfragen bestimmt, mengenorientiert
Anfragen:
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen
17. Juli 2003
141
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
Operationen der relationalen Algebra
•
Definition
r
Selektion
Projektion
s := { µ | µ : dom r ∪ dom s → C, und
Vergleich
•
Vereinigung
Beispiel
r
Komplement
Differenz
Division
A
B
a
b
e
b
f
g
dom r ∪ dom s
r
17. Juli 2003
143
µ dom r ∈ r und µ dom s ∈ s }
:= { µ | µ : ∪i=1,...,k dom ri → C, und µ dom ri ∈ ri für i = 1,...,k }
i=1,...,k ri
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
142
natürlicher Verbund (natural join)
natürlicher Verbund
© Joachim Biskup, Universität Dortmund
17. Juli 2003
s
=
s
dom r ∩ dom s
ABC
A
B
C
a
b
c
e
b
c
© Joachim Biskup, Universität Dortmund
B
C
b
c
=
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
B
17. Juli 2003
144
einfacher Algorithmus für natürlichen Verbund
Spezialfälle des natürlichen Verbunds
s = { µ | es gibt α ∈ r, β ∈ s : α(A) = β(A) für alle A ∈ dom r ∩ dom s; µ = α ∪ β }
r
•
liefert:
kartesisches Produkt
falls dom r ∩ dom s = ∅:
PROCEDURE NestedLoopJoin(r, s : Relation) : Relation;
VAR ergebnis
: Relation;
α, β
: Tupel;
•
s
=
r×s
r
s
=
r∩s
Durchschnitt
falls dom r = dom s:
BEGIN
ergebnis := Ø;
FOR ALL α ∈ r DO
FOR ALL β ∈ s DO
IF Passend(α,β)
(* liefert TRUE gdw α(A) = β(A) für alle A ∈ dom r ∩ dom s *)
THEN ergebnis := ergebnis ∪ {α ∪ β}
END
END
END;
RETURN ergebnis
END NestedLoopJoin;
r
natürlicher Verbund ist doppelgesichtig:
• er kann aggregierend wirken und
damit (quadratisch) vergrößerte Ergebnisse liefern
•
er kann aussondernd wirken und
damit verkleinerte Ergebnisse liefern
•
beide Wirkungen können sich auch überlagern
Laufzeit: O ( || r || * || s || )
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
145
© Joachim Biskup, Universität Dortmund
A=c-Selektion (A=c-selection) als abgeleitete Operation
•
17. Juli 2003
146
algebraische Eigenschaften des natürlichen Verbunds
Definition
für A ∈ dom r und c ∈ C:
σA=c (r) := r
(r
{ (A,c) }
= { µ | µ : dom r ∪ {A}→ C, und µ dom r ∈ r und µ {A} ∈ { (A,c) }}
= { µ | µ ∈ r und µ (A) = c }
•
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
r
s
=
s
r
s)
t
=
r
(s
kommutativ
t)
assoziativ
r⊂s
⇒
r
t
⊂ s
r⊂s
⇒
r
s
=
r
absorbtiv
r
r
=
r
idempotent
r
∅
=
∅
Nullelement
σA=c (r
s)
=
σA=c (r)
s
σ−distributiv
A ∈ dom r ∩ dom s
⇒
σA=c (r
s)
=
σA=c (r)
σA=c (s)
σ−distributiv
t
monoton
Beispiel
r
A
B
a
b
e
b
f
g
© Joachim Biskup, Universität Dortmund
σB=b(r) =
A B
a
b
e
b
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
A ∈ dom r ⇒
17. Juli 2003
147
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
148
Projektion
Projektion und q-Projektion
Definition
1. für X ∩ dom r ≠ ∅:
•
πX(r) := {νX | ν ∈ r}
Projektion (projection) der Relation r auf X
πq(r) := {µ | µ : X → C, es gibt ν ∈ r mit µ = ν ° q}
q-Projektion der Relation r vermöge q,
•
Funktionengleichheit µ = ν ° q
gdw
für alle A∈X: µ(Α) = ν ° q (A)
= ν (q (A))
Beispiel für X := { B } und q(C) := A, q(D) := A, q(E) := B
r
A
B
a
b
e
b
f
g
© Joachim Biskup, Universität Dortmund
πB(r) =
B
πq(r) =
πq(r) =
{µ | µ : X → C, es gibt ν ∈ r mit µ = ν ° q }
=
{µ | µ : X → C, es gibt ν ∈ r mit µ = ν X }
=
{ν X | ν ∈ r }
=
πX(r)
C D E
b
a
a
b
g
e
e
b
f
f
g
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
149
einfacher Algorithmus für Projektion
© Joachim Biskup, Universität Dortmund
für
150
∪i=1,...,k Xi = dom r : r ⊂
i=1,...,k πXi (
r)
Gleichheit kann durch eine passende semantische Bedingung,
nämlich eine Verbundabhängigkeit erzwungen werden.
Falls das Tupel ν ° q noch nicht in der Relation ergebnis enthalten ist, so füge es ein;
diese Elementtest-Und-Einfüge-Operation kann durch geeignete Datenstrukturen
für die Relation ergebnis, z.B. sortierte Liste oder B*-Baum,
unterstützt werden. *)
2. eine an einem natürlichen Verbund teilnehmende Relation rj
enthält die entsprechende Projektion des Verbundes, genauer:
END;
RETURN ergebnis
END SequentialProject;
πdom rj (
i=1,...,k ri)
⊂ rj
Gleichheit kann durch passende semantische Bedingungen,
nämlich Enthaltenseinsabhängigkeiten erzwungen werden.
Laufzeit: O ( || r || ⋅log || r || )
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
1. eine durch überdeckende Projektionen zerlegte Relation r
ist im natürlichen Verbund der Projektionen enthalten, genauer:
BEGIN
ergebnis := ∅;
FOR ALL ν ∈ r DO
ergebnis := ergebnis ∪ {ν ° q}
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
Projektion und natürlicher Verbund (als eine Art ‘‘Quasi-Inverse’’)
PROCEDURE SequentialProject
(q : Attributfunktion; r : Relation) : Relation;
VAR ergebnis : Relation;
ν:
Tupel;
(*
für A ∈ X ⊂ dom r
dann gilt:
2. für q : X → Y, Y ⊂ dom r, X ≠ ∅:
wobei:
q:X→X
q(A) := A
sei
17. Juli 2003
151
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
152
eine “verlustbehaftete” Zerlegung (lossy join)
r =
A
B C
a
b
a
a
SA,B (r) = A
B
S B,C (r) = B
C
a
b
a
a
a
a
a
b
a
b
S A,B (r)
....
ein hängendes Tupel (dangling tuple)
S B,C (r) =
A
B
C
a
a
b
b
a
a
a
a
a
b
a
b
r=
r
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
r
s= B
C
a
a
a
b
a
a
a
b
s= A B
C
a
a
a
b
s) =
A
B
a
a
17. Juli 2003
153
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
154
Projektion und andere Operationen (optimierende Umformungen)
Definition
s := πdom r (r
=
r
s)
falls dom r ∩ dom s ⊂ X :
s)
=
πX (r)
πX (r
πX (s)
πX ( σA=c (r) )
=
σA=c ( πX (r) )
für X ∩ Y ∩ dom r ≠ ∅:
πX(πY(r))
=
πX∩Y(r)
speziell für X ⊂ Y ⊂ dom r:
πX(πY(r))
=
πX(r)
πdom r ∩ dom s (s)
falls A ∈ X ∩ dom r:
•
a
a
S$% (r
Im Verbundergebnis ist die ‘‘Information’’ von Tupel (a, b) ‘‘verloren gegangen’’.
Teilverbund (semijoin)
•
B
Tupel (a, b) aus Relation r ‘‘hängt’’, d.h.
es findet kein ‘‘kein passendes Tupel’’ in Relation r.
Zerlegung und anschließende ‘‘Wiederherstellung’’ durch den Verbund kann
‘‘neue Tupel erfinden’’, im Beispiel:
( a, a, b )
( b, a, a )
© Joachim Biskup, Universität Dortmund
A
Beispiel
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
155
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
156
Vereinigung
•
Definition
+ (d,r,s) := { µ | µ : dom r ∪ dom s → d,
und ( µ dom r ∈ r oder
•
grundlegende Eigenschaften der Vereinigung
1. falls
dom r = dom s, d.h. r und s sind vereinigungsverträglich,
so
µ dom s ∈ s) }
+ (d,r,s) =
r∪s
Beispiel
2.
d := {e, f, g}
r :=
s :=
© Joachim Biskup, Universität Dortmund
A
B
e
e
f
f
g
f
A
C
e
f
+ (d, r, s) =
A
B
C
e
e
e
e
e
e
f
f
f
e
f
f
f
g
g
g
f
f
f
e
e
f
g
e
f
g
e
f
g
f
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
+ (d,r,s)
=
+ (d,s,r)
t
=
(r
σA=c (r ∪ s)
=
σA=c (r) ∪ σA=c (s)
4. πX (+ (d, r, s) ) =
+ (d, πX (r), πX (s) )
3. (r ∪ s)
t) ∪ (s
t)
speziell für dom r = dom s:
πX (r ∪ s)
17. Juli 2003
157
© Joachim Biskup, Universität Dortmund
=
πX (r) ∪ πX (s)
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
A=B-Vergleich und A≠B-Vergleich
17. Juli 2003
158
17. Juli 2003
160
Komplement
Definition
σA=B(r) := {µ | µ ∈ r, und µ(A) = µ(B)}
•
σA≠B(r) := {µ | µ ∈ r, und µ(A) ≠ µ(B)}
•
Definition
γ (d,r) := {µ | µ : dom r → d} \ r
•
Beispiel
grundlegende Eigenschaften des Vergleiches:
1. σA=B(r) ∪ σA≠B(r) = r
•
d := {e, f, g}
2. σA=B(r) ∩ σA≠B(r) = ∅
3. für
X = {A1,...,Ak}, Y = {B1,...,Bk} mit bekannter Reihenfolge der Aufzählung,
X ∩ Y = ∅,
X ∪ Y ⊂ dom r :
r
A
B
e
e
f
f
g
f
γ (d, r) =
σX=Y(r) := σA1=B1 (σA2=B2 (... σAk=Bk(r)... )
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
159
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
A
B
e
f
f
g
g
g
e
e
g
e
f
g
Differenz
grundlegende Eigenschaften der Differenz
Definition: für dom r ∩ dom s ≠ ∅:
– (d,r,s) := {µ | µ ∈ r, und µ dom r ∩ dom s ∉ πdom r ∩ dom s(s) }
•
=
1. falls dom r = dom s:
γ ( d, πdom r ∩ dom s(s) )
r
Beispiel
•
r :=
d := {e, f, g}
A
B
e
e
f
f
g
f
s :=
A
C
e
f
–(d,r,s)
2. falls dom r ∩ dom s ⊂ X:
=
πX ( – (d, r, s) ) =
r\s
– (d, πX (r), πX (s) )
3. falls A ∈ X ∩ dom r:
σA=c ( – (d, r, s) ) =
– (d, σA=c (r), s)
4. falls A ∈ dom s ∩ dom s:
σA=c ( – (d, r, s) ) =
– (d, σA=c(r), σA=c(s) )
a) Differenz direkt ermittelt:
π (s) =
A
– (d, r, s) =
A
e
A
B
f
f
b) Differenz mit Hilfe der Umschreibung ermittelt:
γ (d, πdom r ∩ dom s (s)) =
r
A
B
e
e
f
f
g
f
γ ( d,
A
) =
A
B
A
e
e
f
f
g
f
f
g
e
© Joachim Biskup, Universität Dortmund
=
A
B
f
f
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
161
© Joachim Biskup, Universität Dortmund
Division
Definition: für ∅ ≠ dom r ∩ dom s ≠ dom r
r/s
Beispiel: Argumente
=
µ ∈ πdom r \ dom s (r) und {µ}
A
a1
a2
a1
Projektionen:
πA(s) =
B
s :=
b
b
d
πB(r) =
A
a1
a2
162
s ≠∅:
und
µ : dom r \ dom s → C, und
für alle ν :wenn ν ∈ πdom r ∩ dom s (s), dann µ ∪ ν ∈ r }
r :=
17. Juli 2003
grundlegende Eigenschaften der Division
:= {µ |
{µ |
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
πdom r ∩ dom s (s) ⊂ r }
A
C
a1
a2
c
c
1. falls
so
dom r ∩ dom s = ∅ und s ≠ ∅,
(r
s) / s = r
2. r /s = πdom r \ dom s(r) \ πdom r \ dom s( (πdom r \ dom s(r)
πdom r ∩ dom s(s) ) \ r)
B
b
d
für Tupel aus πB(r):
- für µ1 := (B, b):
{µ1}
πA(s)
⊂
r
- für µ2 := (B, d):
{µ2}
πA(s)
not ⊂
r
also:
r/s
© Joachim Biskup, Universität Dortmund
= { (B,b) }
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
163
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Theorie
17. Juli 2003
164
Formalisierung von Anfragen (grobes ‘‘Kochrezept’’)
3.2 relationale Anfrageoperationen: Pragmatik
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
165
•
für die umgangssprachlich vorliegenden Begriffe
formale Entsprechungen bestimmen als
Attribute, Relationensymbole, semantische Bereichsnamen oder Konstantenzeichen
•
für die umgangssprachlich vorliegenden Zusammenhänge zwischen den Begriffen
formale Entsprechungen bestimmen als
Pfade im Hypergraphen des Schemas und dann durch Verbunde ausdrücken
•
für die umgangssprachlich vorliegenden Zwecke des Anfragewunsches
formale Entsprechungen ausdrücken als
Selektionen und Projektionen
•
ggf. abschließend mit Hilfe der algebraischen Eigenschaften optimieren
(durch Benutzer oder automatisch vom Datenbankmanagementsystem)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
Hypergraph für Beispiel ‘‘Arztpraxis’’
PERSON
Geschlecht
Eltern
166
17. Juli 2003
168
Instanz für Beispiel ‘‘Arztpraxis’’
PERSON
ELT
17. Juli 2003
Name
Name
Eltern
Geschlecht
Mensch
Mensch
weib
mann
mann
weib
weib
mann
mann
mann
weib
maria
hugo
alfons
anton
anton
theresia
theresia
gerda
anton
anton
theresia
wilhelmine
fritz
wilhelmine
fritz
josef
Name
Geschlecht
Mensch
wilhelmine
fritz
anton
theresia
maria
hugo
alfons
josef
gerda
ELT
Patient
Arzt
BEH
Mensch
ArtPro
BEH
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
167
© Joachim Biskup, Universität Dortmund
Patient
Arzt
ArtPro
Mensch
Mensch
ArtPro
maria
maria
maria
anton
anton
anton
fritz
theresia
gerda
gerda
gerda
josef
josef
josef
josef
josef
labor
hausbesuch
röntgen
untersuchung
labor
beratung
beratung
röntgen
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
Anfrage: ‘‘Bestimme für Kind theresia ihr Geschlecht und ihre
Eltern!”
•
Anfrage: “Bestimme alle Ärzte, die weibliche Patienten behandeln!”
•
Schritt 1:
den nominalen Begriffen Arzt und Patient entsprechen
die Attribute BEH.Arzt und BEH.Patient;
den nominalen Begriffen Kind, Geschlecht und Eltern entsprechen
die Attribute ELT.Name, PERSON.Geschlecht und ELT.Eltern
dem adjektiven Begriff weiblich entspricht
das Konstantenzeichen weib als ein Wert des Attributs PERSON.Geschlecht;
den possessiven Begriffen ihr (Geschlecht) und ihre (Eltern) entsprechen
die Relationensymbole PERSON und ELT
•
dem verbalen Begriff behandeln entspricht das Relationensymbol BEH
Schritt 2:
•
dem vorliegenden Zusammenhang entspricht
der Pfad ‘‘PERSON, Name, ELT’’ im Hypergraphen:
PERSON
ELT
•
σPatient=Name (BEH
Schritt 3:
σName=theresia (PERSON
•
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
PERSON)) oder
πArzt (σGeschlecht=weib (σPatient=Name (BEH
169
© Joachim Biskup, Universität Dortmund
die Selektion nach dem Konstantenzeichen weib des Attributs PERSON.Geschlecht sowie
das Entfernen des Attributs BEH.ArtPro
können vorgezogen werden:
PERSON)))
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
170
Anfrage: “Für welche Patienten wurden alle medizintechnischen
Möglichkeiten ausgenutzt?”
Schritt 4 (Optimierung):
πArzt (πq1 (BEH)
Schritt 3:
πArzt (σGeschlecht=weib (πq (BEH)
die Selektion nach dem Wert theresia des Attributs PERSON.Name bzw. ELT.Name
kann vorgezogen werden:
σName=theresia (PERSON)
σName=theresia (ELT)
•
PERSON)
dem vorliegenden Zweck entspricht
eine Selektion nach dem Konstantenzeichen weib für das Attribut PERSON.Geschlecht
und eine abschließende Projektion nach dem Attribut BEH.Arzt:
ELT)
Schritt 4:
© Joachim Biskup, Universität Dortmund
Schritt 2:
dem vorliegenden Zusammenhang entspricht
der Pfad ‘‘BEH, Patient, Mensch, Name, PERSON’’ im Hypergraphen:
πq (BEH)
PERSON mit q := { (Name, Patient), (Arzt, Arzt), (ArtPro,ArtPro) } oder
dem vorliegenden Zweck entspricht die abschließende Selektion:
•
Schritt 1:
•
Schritt 1:
den nominalen Begriffen Patient und Möglichkeit entsprechen
die Attribute BEH.Patient und BEH.ArtPro;
σGeschlecht=weib (PERSON))
mit q1 = { (Patient,Name), (Arzt, Arzt) }
dem adjektiven Begriff medizintechnisch entspreche hier
die Wertemenge {labor, röntgen} für das Attribut BEH.ArtPro;
oder
dem verbalen Begriff ausgenutzt entspricht das Relationensymbol BEH
πArzt (σPatient=Name (πPatient,Arzt (BEH)
σGeschlecht=weib (PERSON)))
•
Schritt 2:
es liegt ein Zusammenhang vor zwischen
Patienten und tatsächlich ausgenutzten Behandlungsarten einerseits und
möglichen Behandlungsarten andererseits;
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
171
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
172
Zusammenhang nicht unmittelbar aus dem Hypergraphen des Datenbankschemas ablesbar;
- erste Komponente stellt eine Teil-Hyperkante aus dem Graphen dar;
- die zweite kann als durch den Anfragewunsch ergänzt gedacht werden:
3.3 relationale Anfrageoperationen: Vorgriff auf Praxis (Oracle-SQL)
Patient
π
• Patient,ArtPro (BEH)
ArtPro
möglich
Zusammenhang enthält hier eine All-Aussage, die durch eine Division ausdrückbar ist:
•πPatient,ArtPro (BEH) / möglich
mit
möglich =
ArtPro
labor
röntgen
•
Schritt 3: entfällt hier
•
Schritt 4 (Optimierung):
da der Divisor möglich in diesem Fall als konstante Relation bekannt ist
(und nicht erst durch eine Anfrage ausgerechnet werden muß),
kann die All-Aussage schon vom Benutzer in eine Und-Aussage umgewandelt werden:
πPatient (σArtPro=labor (BEH))
πPatient (σArtPro=röntgen (BEH))
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Pragmatik
17. Juli 2003
173
natürlicher Verbund:
© Joachim Biskup, Universität Dortmund
•
für Relationenschemas < R | {A1,..., Ak, B1,..., Bl} | > und < S | {B1,..., Bl, C1,...,Cm} | > :
SELECT DISTINCT
•
Vereinigung: für vereinigungsverträgliche Relationenschemas < R | X | > und < S | X | >:
UNION
SELECT DISTINCT *
AND
R.B2 = S.B2 AND ... AND R.Bl = S.Bl
FROM S
•
A=c-Selektion: für Relationenschema < R | X | > mit A ∈ X:
A=B-Vergleich: für Relationenschema< R | X | > mit {A, B} ⊂ X:
SELECT DISTINCT *
FROM R
FROM R
WHERE A = B
WHERE A = 'c'
•
Projektion: für Relationenschema < R | X | > mit {A1,..., Ak} ⊂ X:
Differenz: für vereinigungsverträgliche Relationenschemas < R | X | > und < S | X | > :
SELECT DISTINCT *
SELECT DISTINCT A1,...,Ak
SELECT DISTINCT *
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Vorgriff auf Praxis (Oracle-SQL)
FROM R
MINUS
FROM R
© Joachim Biskup, Universität Dortmund
174
FROM R
SELECT DISTINCT *
•
17. Juli 2003
SELECT DISTINCT *
R.A1,...,R.Ak,
R.B1,...,R.Bl,
S.C1,...,S.Cm
FROM R, S
WHERE R.B1 = S.B1
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Vorgriff auf Praxis (Oracle-SQL)
17. Juli 2003
175
© Joachim Biskup, Universität Dortmund
FROM S
Informationssysteme: Relationales Datenmodell: Operationen - relationale Anfrageoperationen: Vorgriff auf Praxis (Oracle-SQL)
17. Juli 2003
176
relationale Anfragen: anschaulich
4 Relationale Anfragesprachen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
177
•
sind Operationen auf Instanzen von Schemas,
d.h. die Argumente sind Relationen und gegebenenfalls das Universum,
die zurückgelieferten Werte sind wieder Relationen
•
behandeln Relationen als Mengen von Tupeln,
wobei Mengen als ungeordnet gedacht werden,
und berücksichtigen keine Eigenschaften der Codierungen
von Konstantenzeichen, Tupeln, Relationen usw
•
behandeln Konstantenzeichen als atomare, uninterpretierte Dinge:
über diese Dinge ‘‘weiß das Informationssystem’’ stets nur
- deren Gleichheit bzw. Ungleichheit und
- die in der aktuellen Instanz (d,r1,...,rn) ausgedrückten Beziehungen
© Joachim Biskup, Universität Dortmund
relationale Anfragen: formale Definition
•
Definition
eine formale Sprache L (Syntax) mit:
für jedes Wort Φ ∈ L liefert die Semantik eval (Φ) eine relationale Anfrage
•
Beispiele
1. [getypt mit Signatur X1,...,Xn → X]
Q : satRS → satR, wobei RS = << | X1 | >,...,< | Xn | > | | > und R = < | X | >
dann µ(A) ∈ d
Relationenkalkül:
benutzt im Wesentlichen die Ausdrucksmittel der Prädikatenlogik und der Mengenlehre
4. [isomorphietreu]
sind Instanzen M = (d,r1,...,rn) und M' = (d',r1',...,rn') isomorph
1-1
auf
belegt man Individuenvariablen durch Konstantenzeichen,
so erhält man einen werteorientierten Relationenkalkül;
d', d.h. insbesondere h[M] = M' ,
belegt man Individuenvariablen durch ganze Tupel,
so erhält man einen tupelorientierten Relationenkalkül
so gilt h[Q(M)] = Q(h[M]), d.h. das folgende Diagramm kommutiert:
M
h
Q
M'
Kern der Structured Query Language (SQL):
ein tupelorientierter Relationenkalkül mit algebraischen Ergänzungen
Q
Q(M)
178
Relationenalgebra:
benutzt Operationszeichen für die grundlegenden relationalen Operationen
3. [berechenbar]
Q partiell rekursiv
unter einer Bijektion h: d
17. Juli 2003
relationale Anfragesprache
Funktion Q heißt relationale Anfrage (relational query) der Signatur X1,...,Xn → X
:gdw
2. [universumstreu]
falls µ ∈ Q(d,r1,...,rn) und A ∈ X,
Informationssysteme: Relationale Anfragesprachen
h[Q(M)] = Q(M') = Q(h[M])
h
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
179
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
180
Beispiel für relationale Anfragesprache: Relationenalgebra
•
Syntax von LAl (relationale Ausdrücke
1.
R1,...,Rn ∈ LAl
D ∈ LAl
2.
sind Φ, Ψ ∈ LAl,
dann auch
- (Φ
Ψ) ∈ LAl
Semantik von LAl
eval (Φ) : satRS → sat<
Voraussetzungen
- RS = <<R1 | X1 | >,...,<Rn | Xn | > | | >
- D∉A∪R
•
•
Datenbankschema
ein Name für das Universum
mit
mit
mit
A, B ∈ A ∪ {D},
1.
Definitionsbereichen)
dom Ri
dom D
:=
:=
2.
Xi
{D}
X ⊂endlich A ∪ {D}
Ψ) :=
dom Φ ∪ dom Ψ
| dom Φ | >
eval (Ri) (d,r1,...,rn)
eval (D) (d,r1,...,rn)
eval (Φ
für alle Φ ∈ LAl
:=
:=
ri
{ (D,a) | a ∈ d }
Ψ) (d,r1,...,rn) :=
≅
d
(eval (Φ) (d,r1,...,rn), eval (Ψ) (d,r1,...,rn))
eval (Φ + Ψ) (d,r1,...,rn)
:=
+ (d, eval (Φ) (d,r1,...,rn), eval (Ψ) (d,r1,...,rn))
eval (πq(Φ)) (d,r1,...,rn)
:=
πq(eval (Φ) (d,r1,...,rn))
mit
dom (Φ
- (Φ + Ψ) ∈ LAl
mit
dom (Φ + Ψ)
:=
dom Φ ∪ dom Ψ
eval(σA=B(Φ)) (d,r1,...,rn) :=
σA=B(eval (Φ) (d,r1,...,rn))
- πq(Φ) ∈ LAl, wobei q : X → dom Φ
mit
dom πq(Φ)
:=
X
eval (σA≠B(Φ)) (d,r1,...,rn) :=
σA≠B(eval (Φ) (d,r1,...,rn))
- σA=B(Φ) ∈ LAl, wobei {A,B} ⊂ dom Φ
mit
dom σA=B(Φ) :=
dom Φ
- σA≠B(Φ) ∈ LAl, wobei {A,B} ⊂ dom Φ
mit
dom σA≠B(Φ) :=
dom Φ
eval (γ (Φ)) (d,r1,...,rn)
γ (d, eval (Φ) (d,r1,...,rn))
- γ(Φ) ∈ LAl
mit
dom γ(Φ)
dom Φ
:=
•
:=
grundlegende Eigenschaft
Für alle Ausdrücke Φ ∈ LAl ist eval (Φ) eine relationale Anfrage.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
181
© Joachim Biskup, Universität Dortmund
Beweisidee für grundlegende Aussage
•
17. Juli 2003
182
Mächtigkeit der Relationenalgebra
Behauptung
[Definierbarkeit von (Ergebnis-) Relationen mit Hilfe von (Argument-) Relationen]
Für alle Ausdrücke Φ ∈ LAl ist eval (Φ) eine relationale Anfrage.
•
Informationssysteme: Relationale Anfragesprachen
‘‘s ist in LAl aus (d,r1,...,rn) definierbar
genau dann, wenn
s ist invariant unter allen Automorphismen von (d,r1,...,rn)’’
Begründung
Behauptung ergibt sich unmittelbar aus den Definitionen der relationalen Operationen:
diese benutzen nämlich nur
formal:
- die Mengeneigenschaften der Argumentrelationen
•
- Gleichheits- bzw. Ungleichheitsbeziehungen
zwischen Konstantenzeichen oder aus Konstantenzeichen aufgebauten Tupeln
•
Satz
Sei RS = <<R1 | X1 | >,...,<Rn | Xn | > | | > ein Datenbankschema,
(d,r1,...,rn) ∈ satRS und
s eine Relation mit dom s = X.
Bemerkungen
- Selektion(en) σA=c sind im streng formalen Sinne keine relationalen Anfragen,
weil das Konstantenzeichen c ‘‘nicht isomorphietreu verarbeitet wird’’
Dann gibt es einen Ausdruck Φ ∈ LAl mit eval (Φ) (d,r1,...,rn) = s
genau dann, wenn
- Information Retrieval-Systeme und Multimedia-Systeme betrachten
anstelle von Gleichheitsbeziehungen häufig schwächere ‘‘Ähnlichkeitsbeziehungen’’,
die im Allgemeinen auch ‘‘nicht isomorphietreu verarbeitet’’ werden (können)
für alle Automorphismen h: d
h[s] = s.
1-1
auf
d mit h[d,r1,...,rn] = (d,r1,...,rn) gilt:
- die Umkehrung des Satzes gilt nicht:
es gibt relationale Anfragen, die nicht in der Relationenalgebra ausgedrückt werden können
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
183
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
184
Beweis von “⇒’’
Beweisidee für ‘‘⇐’’
sei Φ ∈ LAl mit eval (Φ) (d,r1,...,rn) = s.
•
AutM := {h | h : d
eval (Φ) ist eine relationale Anfrage und
damit insbesondere isomorphietreu
also gilt für alle Automorphismen h: d
1-1
auf
d mit h[d,r1,...,rn] = (d,r1,...,rn):
h [eval (Φ) (d,r1,...,rn)]
Voraussetzung
=
eval (Φ) (h [d,r1,...,rn])
eval (Φ) isomorphietreu
=
eval (Φ) (d,r1,...,rn)
h Automorphismus
=
s
Voraussetzung
•
•
185
mit
•
Datenbankschema
mit
dom (Φ ∧ Ψ)
:=
dom Φ ∪ dom Ψ
(Φ ∨ Ψ) ∈ LK
mit
dom (Φ ∨ Ψ)
:=
dom Φ ∪ dom Ψ
(¬ Φ) ∈ LK
mit
dom (¬ Φ)
:=
dom Φ
(∃ vAi) Φ ∈ LK
mit
dom (∃ vAi) Φ :=
dom Φ \ {Ai}
(∀ vAi) Φ ∈ LK
mit
dom (∀ vAi) Φ :=
dom Φ \ {Ai}
186
| dom Φ | >
für alle Φ ∈ LK
{µ | µ : dom Φ → d
und |=(d,r1,...,rn), µ Φ }
Bemerkungen
es werden diejenigen Tupel zurückgeliefert, für die gilt:
- der Definitionsbereich des Tupels ist gleich
dem durch die relationale Formel Φ (implizit) spezifizierten Definitionsbereich dom Φ
- das Tupel ist aufgebaut aus Konstantenzeichen des Universums d der (gespeicherten) Instanz
- das Tupel macht die ‘‘relationale Formel wahr in der (gespeicherten) Instanz (d,r1,...,rn)’’
Definitionsbereiche entsprechen genau den frei vorkommenden Variablen:
Aj ∈ dom Φ
genau dann, wenn
vAj kommt in Φ frei vor
es wird hier vorausgesetzt:
eine eineindeutige Korrespondenz zwischen Individuenvariablen vAj und Attributen Aj
3. ist Φ ∈ LK mit Ai ∈ dom Φ, dann auch:
Informationssysteme: Relationale Anfragesprachen
•
17. Juli 2003
Semantik von LK
eval (Φ) (d,r1,...,rn) :=
2. sind Φ, Ψ ∈ LK Formeln des Relationenkalküls, dann auch:
(Φ ∧ Ψ) ∈ LK
Informationssysteme: Relationale Anfragesprachen
eval (Φ) : satRS → sat<
Definitionsbereichen)
1. [Atomformel]
- für Attributmenge Xi = {Ai1,...,Aik}, paarweise verschiedene Individuenvariablen vAj1,...,vAjk:
Ri (Ai1 : vAj1,...,Aik : vAjk) ∈ LK
mit dom Ri (Ai1 : vAj1,...,Aik : vAjk ):= {Aj1,...,Ajk}
- für Individuenvariablen vAi, vAj:
(vAi = vAj) ∈ LK
mit
dom (vAi = vAj) := {Ai,Aj}
© Joachim Biskup, Universität Dortmund
setzt man dann ΦM geeignet in Ψs ein,
© Joachim Biskup, Universität Dortmund
ein Name für das Universum
Syntax von LK ((relationale) Formeln
also: es gibt Ausdrücke ΦM, Ψs ∈ LAl, so dass gilt:
so erhält man einen Ausdruck Φ ∈ LAl mit
eval(Φ)(M) = s
17. Juli 2003
- D∉A∪R
die Relation s ist mit Hilfe von autM derart darstellbar, dass es
eval (Ψs) (eval (ΦM)(M)) = s
•
Informationssysteme: Relationale Anfragesprachen
Voraussetzungen: -RS = <<R1 | X1 | >,...,<Rn | Xn | > | | >
d mit h [M] = M }
einen Ausdruck Ψs ∈ LAl gibt mit
eval (Ψs) (autM) = s
h[s] =
Beispiel für relationale Anfragesprache: Relationenkalkül
•
1-1
auf
ist durch eine Relation autM derart darstellbar, dass es
einen Ausdruck ΦM ∈ LAl gibt mit
eval (ΦΜ) (M) = autM
•
© Joachim Biskup, Universität Dortmund
die Automorphismengruppe von M := (d,r1,...,rn), d.h.
17. Juli 2003
187
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
188
Beispiele für relationale Formeln
•
Gleichmächtigkeit von Algebra und Kalkül
Voraussetzung
- Datenbankschema:
RS = < < R1 | {A,B} | >, < R2 | {B,C} | >, < R3 | {A,B,C} | > | | >
- Hypergraph:
R1
A
B
C
R2
•
(sehr) einfaches Beispiel
relationale Formel:
R3
•
Der Relationenkalkül kann durch die Relationenalgebra verwirklicht werden,
indem man relationale Formeln uniform in relationale Ausdrücke übersetzt
(und damit ihre algorithmische Auswertung ermöglicht).
Syntaxbaum der Formel:
Beispiele mit umgangssprachlichen Umschreibungen:
- liefere die Tupel über Attribute A und B, die in der Instanz von R1 sind:
R1 (A:vA, B:vB)
- liefere die Tupel über Attribute B und C, die in der Instanz von R2 sind:
R2 (B:vB, C:vC)
R3 (A:vA, B:vB, C:vC)
- liefere die Tupel, die in vorgenannter Menge sind oder die in der Instanz von R3 sind:
( ( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) ) ∨ R3 (A:vA, B:vB, C:vC) )
R1 (A:vA, B:vB)
•
17. Juli 2003
R2 (B:vB, C:vC)
Übersetzungen:
R1 (A:vA, B:vB)
R2 (B:vB, C:vC)
( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) )
- liefere die umbenannten Tupel über Attribute D und E, die in der Instanz von R1 sind:
R1 (A:vD, B:vE)
Informationssysteme: Relationale Anfragesprachen
∨
∧
- liefere die ‘‘Zusammensetzungen von passenden Tupeln
aus der Instanz von R1 und der Instanz von R2’’:
( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) )
© Joachim Biskup, Universität Dortmund
( ( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) ) ∨ R3 (A:vA, B:vB, C:vC) )
in
in
R1
R2
in
R1
( ( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) ) ∨ R3 (A:vA, B:vB, C:vC) ) in
189
© Joachim Biskup, Universität Dortmund
(R1
Informationssysteme: Relationale Anfragesprachen
R2
R2) + R3
17. Juli 2003
190
Behauptung 1: Kalkül in Algebra äquivalent übersetzbar
Satz
Die Relationenalgebra und der Relationenkalkül sind gleichmächtig.
zu zeigen: für alle Formeln χ ∈ LK gibt es einen Ausdruck χ∗ ∈ LAl mit evalK (χ) = evalAl (χ∗)
Grundlegendes Ergebnis der Theorie des relationalen Datenmodells:
Beweis:
- die mengenorientierte, deklarative Semantik des Relationenkalküls
kann durch die Relationenalgebra
korrekt und vollständig operationalisiert werden
(und ist damit einer tatsächlichen Verwirklichung zugänglich)
wir bestimmen durch Induktion über den Aufbau von LK
für jede Formel χ ∈ LK
einen Ausdruck χ∗ ∈ LAl mit
evalK(χ) = evalAl (χ∗).
1a.
- die Ausdrucksfähigkeit der operational gegebenen Relationenalgebra
lässt sich durch den Relationenkalkül deklarativ genau beschreiben
evalK(Ri (Ai1 : vAj1,..., Aik : vAjk)) (d,r1,...,rn)
=
Definition evalK
{ µ | µ : {Aj1,...,Ajk} → d,
|=(d,r1,...,rn), µ Ri (Ai1 : vAj1,...,Aik : vAjk) }
{µ | µ : {Aj1,...,Ajk} → d,
µ ° q-1 ∈ ri }
mit
q: {Aj1,..., Ajk} → {Ai1,..., Aik},
q (Ajl) := Ail für l = 1,...,k
=
- (nicht immer erreichtes) Vorbild für andere Datenmodelle!
Definition |=
- konstruktiver Beweis, der ein verifiziertes Übersetzungsverfahren liefert
Definition πq
=
πq(ri)
=
Definition evalAl
evalAl (πq(Ri)) (d,r1,...,rn)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
191
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
192
evalK (Φ ∧ Ψ) (d,r1,...,rn)
2a.
1b.
evalK (vAi = vAj) (d,r1,...,rn)
=
Definition evalK
=
{µ | µ : {Ai, Aj} → d,
|=(d,r1,...,rn), µ (vAi = vAj) }
{µ | µ : {Ai, Aj} → d,
µ (vAi) = µ (vAj) }
=
=
=
Definition |=
=
Definition πqij
=
{ µ | µ : dom Φ ∪ dom Ψ → d, |=(d,r1,...,rn), µ Φ
Definition |=
und |=(d,r1,...,rn), µ Ψ) }
{ µ | µ : dom Φ ∪ dom Ψ → d, |=(d,r1,...,rn), µ dom Φ Φ und |=(d,r1,...,rn), µdom Ψ Ψ) }
Definition evalK
{µ | µ : dom Φ ∪ dom Ψ → d, µ dom Φ ∈ evalK (Φ) (d,r1,...,rn) und
µ dom Ψ ∈ evalK (Ψ) (d,r1,...,rn) }
=
Induktionsannahme
∗
{µ | µ : dom Φ ∪ dom Ψ → d, µ dom Φ ∈ evalAl (Φ ) (d,r1,...,rn) und
πqij (d) mit qij : {Ai, Aj} → {D}
=
Definition evalK
{ µ | µ : dom Φ ∪ dom Ψ → d, |=(d,r1,...,rn), µ (Φ ∧ Ψ) }
Definition evalAl
evalAl (πqij (D)) (d,r1,...,rn)
µ dom Ψ ∈ evalAl (Ψ∗) (d,r1,...,rn) }
=
Definition
evalAl
(Φ∗)
(d,r1,...,rn)
evalAl
(Φ∗
Ψ∗)
evalAl
(Ψ∗)
(d,r1,...,rn)
=
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
193
© Joachim Biskup, Universität Dortmund
(d,r1,...,rn)
Informationssysteme: Relationale Anfragesprachen
=
- evalK (Φ ∨ Ψ) (d,r1,...,rn) =
evalAl (Φ∗ + Ψ∗) (d,r1,...,rn)
- evalK (¬ Φ) (d,r1,...,rn)
evalAl (γ (Φ∗)) (d,r1,...,rn)
=
17. Juli 2003
194
evalK (( ∃ vAi) Φ) (d,r1,...,rn)
3.
entsprechend beweist man:
Definition evalAl
Definition evalK
{ µ | µ : dom Φ \ {Ai} → d,
|=(d, r1,...,rn), µ (∃ vAi) Φ }
{ µ | µ : dom Φ \ {Ai} → d,
Definition |=
es gibt µ' mit µ' : dom Φ → d,
µ =Ai µ',
und |=(d, r1,...,rn), µ' Φ }
=
=
{ µ | µ : dom Φ \ {Ai} → d,
=
=
=
=
es gibt µ' mit µ' : dom Φ → d,
µ = µ' dom Φ \ {Ai}, und |=(d, r1,...,rn), µ' Φ }
Definition evalK
{ µ | µ : dom Φ \ {Ai} → d, es gibt µ' mit µ' : dom Φ → d,
µ = µ' dom Φ \ {Ai}, und µ' ∈ evalK (Φ) (d,r1,...,rn)}
Induktionsannahme
{ µ | µ : dom Φ \ {Ai} → d, es gibt µ' mit
µ = µ' dom Φ \ {Ai}, und µ' ∈ evalAl (Φ∗) (d,r1,...,rn)}
Definition π
πdom Φ \ {Ai} (evalAl (Φ∗) (d,r1,...,rn) )
Definition evalAl
evalAl ( πdom Φ \ {Ai}(Φ∗) ) (d,r1,...,rn) )
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
195
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
196
Behauptung 2: Algebra in Kalkül äquivalent übersetzbar
entsprechend beweist man:
evalK ((∀vAi) Φ) (d,r1,...,rn)
zu zeigen: für alle Ausdrücke χ ∈ LAl
=
evalAl (Φ∗)(d,r1,...,rn) / evalAl (πqi (D)) (d,r1,...,rn)
=
evalAl (χ∗) (d,r1,...,rn),
gibt es eine Formel χ∗ ∈ LK mit evalAl (χ) = evalK (χ∗)
mit qi : {Ai} → {D}
Beweis:
wir konstruieren χ∗ durch Induktion über den Aufbau von χ
Ri∗
≡
Ri (Ai1 : vAi1,..., Aik : vAik)
D∗
≡
(vD = vD)
Ψ) ∗
≡
(Φ∗ ∧ Ψ∗)
≡
(Φ∗ ∨ Ψ∗)
1.
wobei man χ∗ aus Φ∗ und πqi(D) konstruieren kann
entsprechend der Simulation der Division
vermöge Projektion, Komplement und Verbund
2.
(Φ
(Φ + Ψ) ∗
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
197
mit
mit
dom R
q (A1)
q (A2)
q (A5)
=
:=
:=
:=
(Φ∗ ∧ (vAi = vAj))
(σAi≠Aj (Φ)) ∗ ≡
(Φ∗ ∧ ¬(vAi = vAj))
(γ (Φ)) ∗
(¬ Φ∗)
© Joachim Biskup, Universität Dortmund
Beispiel für Konstruktion von (πq(Φ)) ∗
Voraussetzungen:
Φ≡R
q : {A1, A2, A5} → {A1, A2, A3, A4}
(σAi=Aj (Φ)) ∗ ≡
≡
Informationssysteme: Relationale Anfragesprachen
•
{A1, A2, A3, A4},
A1,
A3,
A1.
Voraussetzungen
- Datenbankschema:
RS = < < R1 | {A,B} | >, < R2 | {B,C} | >, < R3 | {A,B,C} | > | | >
- relationaler Ausdruck: χ = πA,C (σA=B ((R1
•
R2) + R3))
Syntaxbaum des Ausdrucks
{A2, A4} = dom R \ range q:
entferne die durch A2, A4 bezeichneten Spalten:
(∃ vA2) (∃ vA4) R (A1 : vA1, A2 : vA2, A3 : vA3, A4 : vA4)
πA,C
σA=B
q (A2) = A3:
benenne die durch A3 bezeichnete Spalte in A2 um
(führe Variable vA2 durch ein Gleichheitsatom ein und “enferne A3”):
(∃ vA3) (∃ vA9) (∃ vA4) (R (A1 : vA1, A2 : vA9, A3 : vA3, A4 : vA4) ∧ (vA3 = vA2))
+
R3(A,B,C)
R1(A,B)
q(A1) = q(A5) = A1:
verdopple die durch A1 bezeichnete Spalte; benenne Verdopplungen durch A1 bzw. A5:
(∃ vA8) (∃ vA3) (∃ vA9) (∃ vA4)[R (A1 : vA8, A2 : vA9, A3 : vA3, A4 : vA4 ) ∧ (vA3 = vA2)
∧ (vA8 = vA1) ∧ (vA8 = vA5)]
Informationssysteme: Relationale Anfragesprachen
198
Beispiel für Übersetzung ‘‘Algebra in Kalkül’’
Formel für das Argument von πq, d.h. für R:
R (A1 : vA1, A2 : vA2, A3 : vA3, A4 : vA4)
© Joachim Biskup, Universität Dortmund
17. Juli 2003
17. Juli 2003
199
© Joachim Biskup, Universität Dortmund
R2(B,C)
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
200
•
Übersetzungen, induktiv entsprechend Baumdurchlauf:
Zusammenfassung: Relationenalgebra und logische Verknüpfungen
SA,C
VA=B
natürlicher Verbund
r
s
:= { µ | µ : dom r ∪ dom s → C, und µ dom r ∈ r und µ dom s ∈ s }
+
R3(A,B,C)
R1(A,B)
R1*
=
R1 (A:vA, B:vB)
R2*
=
R2 (B:vB, C:vC)
=
R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC)
R3*
=
R3 (A:vA, B:vB, C:vC)
((R1
R2) + R3)*
(R1
R2)*
(σA=B ((R1
R2) +
( πA,C (σA=B ((R1
© Joachim Biskup, Universität Dortmund
Projektion
:= {µ | µ : X → C, es gibt ν ∈ r mit µ = ν ° q}
πq(r)
R2(B,C)
Vergleich
σA=B(r) := {µ | µ ∈ r, und µ(A) = µ(B)}
σA≠B(r) := {µ | µ ∈ r, und µ(A) ≠ µ(B)}
Vereinigung
+ (d,r,s) := { µ | µ : dom r ∪ dom s → d, und ( µ dom r ∈ r
= ( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) ) ∨ R3 (A:vA, B:vB, C:vC)
R3)*
Komplement
γ (d,r)
:= {µ | µ : dom r → d, und µ ∉ r (d.h. µ ist nicht Element von r) }
= (( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) ) ∨ R3 (A:vA, B:vB, C:vC))
∧ (vA = vB)
*
R2) + R3)) =
Differenz
– (d,r,s) := {µ | µ ∈ r,
(∃ vB) (
( ( R1 (A:vA, B:vB) ∧ R2 (B:vB, C:vC) )
∨ R3 (A:vA, B:vB, C:vC))
∧ (vA = vB) )
Informationssysteme: Relationale Anfragesprachen
oder µ dom s ∈ s) }
und
µ dom r ∩ dom s ∉ πdom r ∩ dom s(s) }
Division
r/s
:= {µ | µ : dom r \ dom s → C, und
für alle ν : wenn ν ∈ πdom r ∩ dom s (s), dann µ ∪ ν ∈ r }
17. Juli 2003
201
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationale Anfragesprachen
17. Juli 2003
202
relationale Anfragen und relationale Anfragesprachen
(Zusammenfassung)
5 Structured Query Language - SQL
•
relationale Anfragen
- Operationen auf Instanzen von Schemas
- behandeln Relationen als Mengen von Tupeln
- behandeln Konstantenzeichen als atomare, uninterpretierte Dinge
- formale Eigenschaften:
getypt, universumstreu, berechenbar, isomorphietreu
•
relationale Anfragesprache
formale Sprache L derart,
dass die Semantik eval (Φ) für alle Φ ∈ L eine relationale Anfrage liefert
•
Beispiele
- Relationenalgebra
- Relationenkalkül: werteorientiert, falls Individuenvariablen durch Konstantenzeichen belegt
tupelorientiert, falls Individuenvariablen durch ganze Tupel belegt
- Kern der Structured Query Language (SQL):
ein tupelorientierter Relationenkalkül mit algebraischen Ergänzungen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL
17. Juli 2003
203
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL
17. Juli 2003
204
Structured Query Language, SQL
5.1 Kern von Structured Query Language (SQL): Theorie
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
205
•
vom American National Standards Institute, ANSI, genormte
Datendefinitions- und Datenmanipulationssprache
•
enthält eine relationale Anfragesprache als Teilsprache
•
aus theoretischer Sicht:
eine Mischung von: - tupelorientiertem Relationenkalkül
- mit einigen algebraischen Elementen
- angereichert durch arithmetische und
- textverarbeitende Elemente
- sowie mit vielen weiteren Diensten
•
in praktischen Ausprägungen:
sehr umfassende Programmiersysteme für
Informationssysteme aller Art in vielfältigen Anwendungen und Umgebungen
•
weitverbreitete kommerzielle Produkte verfügbar: Oracle, DB2, Postgres...
© Joachim Biskup, Universität Dortmund
Ansatz für Grundform des Kalkülteils
•
17. Juli 2003
208
algebraisch
2. Auswahl zugegriffener Daten
Semantik: wähle diejenigen Kombinationen aus, für die eine Formel Φ mit
Prädikatenzeichen für Komponentenvergleiche wie = oder ≠ gültig ist
in der SQL-Syntax:
- Teil 1 [Zugriff]:
durch Schlüsselwort FROM eingeleitet
- Teil 2 [Auswahl]:
durch Schlüsselwort WHERE eingeleitet
- Teil 3 [Konstruktion]: vorangestellt und
durch Schlüsselwort SELECT eingeleitet
(eigentlich wäre PROJECT angebracht)
Syntax:
entsprechender SQL-Ausdruck hat dann folgendes Aussehen:
•
setze aus Tupelvariablen und passenden Attributen gebildete
Attributterme der Form µ.A in aussagenlogische Kombination von
Prädikatenzeichen für Vergleiche von Werten ein
SELECT
3. Konstruktion der Ausgabedaten
Semantik: liefere dann die Komponenten µi1(A1),...,µil(Al) dieser Kombinationen
Syntax:
bilde Liste der
diese Komponenten bezeichnenden Attributterme µi1.A1,..., µil.Al
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
206
π{Ri1.A1,..., Ril.Al} (σΦ (R1 × ... × Rk))
binde Tupelvariable µ1 an Relationensymbol R1,...,
Tupelvariable µk an Relationensymbol Rk
© Joachim Biskup, Universität Dortmund
17. Juli 2003
Ansatz beschreibt Dreischrittverfahren
1. Zugriff auf gespeicherte Daten
Semantik: erzeuge alle Kombinationen von Tupeln µ1 aus R1,..., µk aus Rk
(wobei die Ri nicht notwendig verschieden sein müssen)
Syntax:
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
DISTINCT µi1.A1 ,..., µil.Al
FROM R1 µ1 ,..., Rk µk
WHERE
207
© Joachim Biskup, Universität Dortmund
Φ
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
einige Vereinfachungen
Beispiel
Schema:
•
Geschlecht
ELT
man darf in der SELECT- und der WHERE-Klausel
das Relationensymbol selbst wie eine Tupelvariable benutzen und
die entsprechende Bindung “Ri Ri” zu “Ri” abkürzen
•
Mensch
ArtPro
BEH
Anfragewunsch:
“Bestimme für Kind theresia Geschlecht und Eltern!”
Ausdruck der Relationenalgebra: σName=theresia (PERSON
ELT)
mit Definitionsbereich {Name, Geschlecht, Eltern}
SQL-Anfrage:
SELECT DISTINCT *
FROM PERSON, ELT
WHERE
PERSON.Name = ELT.Name
AND
PERSON.Name = 'theresia'
mit Definitionsbereich {PERSON.Name, PERSON.Geschlecht, ELT.Name, ELT.Eltern}
anstatt einer Attributtermliste in der SELECT-Klausel,
die alle entsprechend der FROM-Klausel bildbaren Attributterme enthält:
man darf eine solche Attributtermliste durch ‘‘*’’ abkürzen
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
Name
Arzt
anstatt eine Komponente µ(A)
durch den entsprechenden vollständigen Attributterm µ.A zu bezeichnen:
© Joachim Biskup, Universität Dortmund
Eltern
< PERSON | {Name, Geschlecht} | >
< BEH
| {Patient, Arzt, ArtPro} | >
< ELT
| {Name, Eltern}
| >
Patient
man darf auch nur das Attribut A verwenden,
wenn entsprechend der FROM-Klausel und des Datenbankschemas
die fehlende Tupelvariable
eindeutig in Form eines Relationensymbols ergänzt werden kann
•
PERSON
anstatt in der FROM-Klausel
durch “Ri µi” eine Tupelvariable µi an das Relationensymbol Ri zu binden:
17. Juli 2003
209
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
Beispiel
Schema:
ELT
Eltern
Schema:
< PERSON | {Name, Geschlecht} | >
< BEH
| {Patient, Arzt, ArtPro} | >
< ELT
| {Name, Eltern}
| >
Name
PERSON
Geschlecht
ELT
Patient
Arzt
Anfragewunsch:
© Joachim Biskup, Universität Dortmund
Eltern
< PERSON | {Name, Geschlecht} | >
< BEH
| {Patient, Arzt, ArtPro} | >
< ELT
| {Name, Eltern}
| >
Name
Patient
Mensch
ArtPro
BEH
BEH
“Bestimme alle Ärzte, die weibliche Patienten behandeln!”
PERSON) ) )
Anfragewunsch:
“Bestimme die Großeltern des Kindes theresia!”
SQL-Anfrage:
SELECT
SELECT DISTINCT Arzt
FROM BEH, PERSON
WHERE
BEH.Patient = PERSON.Name
AND
PERSON.Geschlecht = 'weib'
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
Mensch
Arzt
ArtPro
Ausdruck der Relationenalgebra:πArzt(σGeschlecht = weib (σPatient = Name (BEH
SQL-Anfrage:
210
Beispiel
PERSON
Geschlecht
17. Juli 2003
17. Juli 2003
GRAD2.Eltern
FROM
ELT
WHERE
211
© Joachim Biskup, Universität Dortmund
GRAD1, ELT
GRAD2
GRAD1.Eltern = GRAD2.Name
AND
GRAD1.Name = 'theresia'
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
212
(stark vereinfachte, abstrakte) Syntax der Kalkülteile von SQL
einfache SQL-Anfrage
SELECT DISTINCT
FROM
Formel
WHERE
einfache SQL-Anfrage
Attributtermliste
Variablenbindungsliste
Attributtermliste
Attributterm
Attributtermliste
SELECT DISTINCT
,
FROM
Variablenbindungsliste
*
Formel
WHERE
Tupelvariable
.
Relationensymbol
Attributterm
Variablenbindungsliste
Attribut
Tupelvariable
Relationensymbol
,
© Joachim Biskup, Universität Dortmund
einfache SQL-Anfrage
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
213
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
214
(vereinfachte, abstrakte) Syntax des algebraischen Teils von SQL
SELECT DISTINCT
FROM
WHERE
Attributtermliste
Variablenbindungsliste
Formel
Formel
SQL-Anfrage
Atomformel
NOT
einfache
SQL-Anfrage
Formel
INTERSECT
AND
Formel
Formel
OR
(
Atomformel
Term
Term
Formel
UNION
)
Vergleichsprädikat
SQLAnfrage
MINUS
Term
Attributterm
Konstantenzeichen
Vergleichsprädikat
=
z
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
215
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
216
Übersicht über Sprachmittel von SQL
•
•
natürlicher Verbund
Kalkülteil
allgemein:
beschreibt Dreischrittverfahren für ‘‘Zugriff-Auswahl-Konstruktion’’
r
s := { µ | µ : dom r ∪ dom s → C, und µ dom r ∈ r und µ dom s ∈ s }
{ µ | es gibt α ∈ r, β ∈ s :
α(A) = β(A) für alle A ∈ dom r ∩ dom s und
µ=α∪β}
algebraischer Teil
verknüpft durch den Kalkülteil gebildete Ergebnisse mengentheoretisch
•
arithmetischer Teil
äquivalent umgeschrieben und speziell
für Relationenschemas < R | {A1,..., Ak, B1,..., Bl} | > und < S | {B1,..., Bl, C1,...,Cm} | > :
benutzt die vier Grundrechenarten mitsamt den arithmetischen Vergleichsoperationen sowie
in der kommerziellen Datenverarbeitung häufig benötigte Aggregatfunktionen
wie Durchschnitt, Summe, Maximum, Minimum, Anzahl
•
textverarbeitender Teil
behandelt Konstantenzeichen als nichtatomare Zeichenfolgen,
die man bezüglich des Vorkommens von Teilworten testen, konkatenieren usw. kann
•
in SQL:
SELECT DISTINCT
weitere Sprachmittel
- SQL-Anfragen ineinander schachteln
- in Ergebnissen Entfernung von Duplikaten unterdrücken
- Ergebnisse weiter aufbereiten
- ...
•
s := { µ | es gibt α ∈ r, β ∈ s :
α(Bj) = β(Bj) für j = 1, ... ,l und
µ=α∪β}
r
R.A1,...,R.Ak,
R.B1,...,R.Bl,
S.C1,...,S.Cm
FROM R, S
WHERE R.B1 = S.B1
AND
R.B2 = S.B2 AND ... AND R.Bl = S.Bl
Relationenalgebra für ‘‘universums-unabhängige’’ Anfragen ausdrückbar:
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
217
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
A=c-Selektion
218
17. Juli 2003
220
Projektion
allgemein für Relationenschema < R | X | > mit A ∈ X:
σA=c (r)
17. Juli 2003
allgemein:
:= { µ | µ : dom r → C, µ ∈ r und µ (A) = c }
πX(r)
speziell in SQL:
:= {µ | µ : X → C, es gibt ν ∈ r mit µ = ν X }
speziell für Relationenschema < R | Y | > mit X = {A1,..., Ak} ⊂ Y:
πX(r) := {µ | µ : {A1,..., Ak}→ C, es gibt ν ∈ r mit µ = ν {A1,..., Ak} }
SELECT DISTINCT *
FROM R
WHERE A = 'c'
speziell in SQL:
SELECT DISTINCT A1,...,Ak
FROM R
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
219
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
Vereinigung
allgemein:
+ (d,r,s)
:= { µ | µ : dom r ∪ dom s → d, und ( µ dom r ∈ r
A=B-Vergleich und A≠B-Vergleich
oder µ dom s ∈ s) }
speziell für vereinigungsverträgliche Relationenschemas < R | X | > und < S | X | >,
d.h. insbesondere X = dom r = dom s = dom r ∪ dom s:
+ (d,r,s)
= r∪s
allgemein für Relationenschema < R | X | > mit {A, B} ⊂ X:
σA=B(r)
σA≠B(r)
:= {µ | µ ∈ r, und µ(A) = µ(B)}
:= {µ | µ ∈ r, und µ(A) ≠ µ(B)}
in SQL:
SELECT DISTINCT *
speziell in SQL:
FROM R
SELECT DISTINCT *
WHERE A = B
FROM R
UNION
SELECT DISTINCT *
SELECT DISTINCT *
FROM S
FROM R
WHERE A ≠ B
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
221
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
222
Differenz
allgemein:
– (d,r,s)
:= {µ | µ ∈ r,
und
5.2 Structured Query Language (SQL): Praxis mit Oracle
µ dom r ∩ dom s ∉ πdom r ∩ dom s(s) }
speziell für vereinigungsverträgliche Relationenschemas < R | X | > und < S | X | > ,
d.h. insbesondere X = dom r = dom s = dom r ∩ dom s:
– (d,r,s)
= {µ | µ ∈ r,
und
µ∉s}
speziell in SQL:
SELECT DISTINCT *
FROM R
MINUS
SELECT DISTINCT *
© Joachim Biskup, Universität Dortmund
FROM S
Informationssysteme: Structured Query Language - SQL - Kern von Structured Query Language (SQL): Theorie
17. Juli 2003
223
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
224
Oracle-SQL Syntax für “SELECT’’
Oracle 9i - SQL Reference, Release 2 (9.2), March 2002, Part No.A96540-01, pp. 8-1 bis 8-16
select_list::=
select::=
*
for_update_clause
subquery
,
;
query_name
subquery::=
table
DISTINCT
schema
UNIQUE
subquery_factoring_clause
hint
FROM
select_list
WHERE
condition
hierarchical_query_clause
materialized view
group_by_clause
AS
table_reference
c_alias
ALL
expr
UNION
INTERSECT
HAVING
condition
© Joachim Biskup, Universität Dortmund
.*
view
ALL
SELECT
,
.
(
subquery
)
MINUS
order_by_clause
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
225
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
226
Oracle 9i - SQL Reference, Release 2 (9.2), March 2002, Part No.A96540-01, pp. 5-1 bis 5-22
table_reference::=
condition::=
flashback_clause
ONLY
query_table_expression
comparison_condition
flashback_clause
t_alias
query_table_expression
logical_condition
(
membership_condition
joined_table
)
joined_table
range_condition
null_condition
query_table_expression::=
query_name
equals_path
PARTITION
SUBPARTITION
(
partition
(
sample_clause
)
subpartition
exists_condition
)
sample_clause
@
schema
like_condition
dblink
table
.
@
view
is_of_type_condition
dblink
under_path
materialized view
subquery_restriction_clause
(
subquery
)
compound_condition
table_collection_expression
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
227
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
228
Type of
Condition
Purpose
Example
=
Equality test.
SELECT *
FROM employees
WHERE salary = 2500;
!=
^=
<>
¬=
Inequality test. Some forms of the
inequality condition may be
unavailable on some platforms.
SELECT *
FROM employees
WHERE salary != 2500;
>
"Greater than" and "less than"
tests.
simple_comparison_condition::=
=
!=
^=
<
"Greater than or equal to" and
"less than or equal to" tests.
>=
<>
SELECT * FROM employees
WHERE salary > 2500;
SELECT * FROM employees
WHERE salary < 2500;
expr
expr
>
SELECT * FROM employees
WHERE salary >= 2500;
SELECT * FROM employees
WHERE salary <= 2500;
<=
ANY
SOME
Compares a value to each value in SELECT * FROM employees
a list or returned by a query. Must
WHERE salary = ANY
be preceded by =, !=, >, <, <=, >=.
(SELECT salary
FROM employees
Evaluates to FALSE if the query
WHERE department_id = 30);
returns no rows.
ALL
Compares a value to every value
in a list or returned by a query.
Must be preceded by =, !=, >, <,
<=, >=.
<
>=
<=
=
,
SELECT * FROM employees
WHERE salary >=
ALL ( 1400, 3000);
!=
(
expr
)
Evaluates to TRUE if the query
returns no rows.
© Joachim Biskup, Universität Dortmund
17. Juli 2003
229
© Joachim Biskup, Universität Dortmund
group_comparison_condition::=
Operation
Example
IN
"Equal to any member of"
test. Equivalent to "= ANY".
SELECT * FROM employees
WHERE job_id IN
(’PU_CLERK’,’SH_CLERK’);
SELECT * FROM employees
WHERE salary IN
(SELECT salary
FROM employees
WHERE department_id =30);
NOT IN
Equivalent to "!=ALL".
Evaluates to FALSE if any
member of the set is NULL.
SELECT * FROM employees
WHERE salary NOT IN
(SELECT salary
FROM employees
WHERE department_id = 30);
SELECT * FROM employees
WHERE job_id NOT IN
(’PU_CLERK’, ’SH_CLERK’);
=
!=
^=
ANY
<>
expression_list
(
)
>
subquery
ALL
<
>=
<=
,
’
NOT
ANY
!=
expr
17. Juli 2003
230
17. Juli 2003
232
membership_condition::=
=
(
)
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
Type of
Condition
SOME
subquery
<>
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
expr
(
^=
)
SOME
^=
(
expression_list
expr
expression_list
IN
(
)
subquery
)
subquery
,
ALL
,
NOT
<>
(
expr
)
expression_list
IN
(
)
subquery
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
231
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
Oracle 9i - SQL Reference, Release 2 (9.2), March 2002, Part No.A96540-01, pp. 18.4 bis 18.44
Type of
Condition
EXISTS
Operation
Example
TRUE if a subquery returns at
least one row.
SELECT department_id
FROM departments d
WHERE EXISTS
(SELECT * FROM employees e
WHERE d.department_id
= e.department_id);
group_by_clause::=
,
expr
GROUP
BY
HAVING
condition
rollup_cube_clause
grouping_sets_clause
exists_condition::=
EXISTS
(
subquery
order_by_clause::=
)
,
expr
SIBLINGS
ORDER
BY
ASC
NULLS
FIRST
DESC
NULLS
LAST
position
c_alias
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
233
© Joachim Biskup, Universität Dortmund
Informationssysteme: Structured Query Language - SQL - Structured Query Language (SQL): Praxis mit Oracle
17. Juli 2003
234
6 Relationales Datenmodell und Erweiterungen
Teil III
6.1 relationales Datenmodell: Rückblick und Würdigung
erweiterte und alternative Systeme
© Joachim Biskup, Universität Dortmund
Informationssysteme
17. Juli 2003
235
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
236
einige Eigenschaften des relationalen Datenmodells
•
keine Funktionszeichen
- Termbildung in Instanzen auf Konstantenzeichen beschränkt
(eher) strukturelle Gesichtspunkte (mit vielen Auswirkungen auf Operationen)
• werteorientiert
•
•
- Identifikation von Tupeln nur vermöge ihrer Werte
- Gleichheit von Tupeln als Gleichheit aller Attributwerte
- keine benutzersichtbaren Tupelidentifikatoren
•
- Instanzen erfüllen getrennt deklariertes Schema
•
•
•
aussagenlogische Junktoren, Quantoren für Individuenvariablen
zweiwertige Wahrheitsfunktion
Negation als ‘‘Nicht-Gültigkeit’’
logische Implikation betrachtet alle Strukturen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
237
(eher) operationale Gesichtspunkte (mit vielen Bezügen zu Strukturen)
• wenige Standardoperationen
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
238
ganz allgemein:
ideelle Trennung von ‘‘universellem Programmiersystem’’ und ‘‘Informationssystem’’
- wohldefinierte Schnittstellen zwischen
‘‘Anwendungsumgebungen’’ und ‘‘eigentlichem Informationssystem’’
- ‘‘eigentliches Informationssystem’’ verarbeitet nur Teilmenge der relationalen Anfragen
- Anfragen sind getypt, universumstreu, berechenbar, isomorphietreu
- Anfragen (query),
Tupel-Einfügen (insert),
Tupel-Entfernen (delete),
Tupel-Ändern (update)
- als “Mehrwertdienst” nur
(mengenorientierte, ausgabeformierte) logische Gültigkeit (Implikation)
•
“bestimmtes Wissen’’
- Tupel entweder gespeichert oder nicht gespeichert, bzw.
entsprechende Aussage entweder wahr oder nicht wahr,
keine Modalitäten, Wahrscheinlichkeiten, Bewertungen usw.
klassische Prädikatenlogik
-
‘‘genaues Wissen’’
- Tupelwerte als atomare Konstantenzeichen
- kein “ungefähr”, ...
modelltheoretisch (und damit vollständig)
- gespeicherte Instanz gedeutet als eine (endliche) Struktur im Sinne der Prädikatenlogik
- in gespeicherter Instanz nur Wahrheitswerte atomarer Aussagen explizit darstellbar
- “vollständiges Wissen’’: jede Aussage (der Prädikatenlogik) entweder wahr oder falsch
•
‘‘vollständiges Wissen’’
- Tupel für alle deklarierten Attribute definiert (keine Nullwerte)
- nichtgespeicherte Tupel als negative Aussage gedeutet
(Annahme der geschlossenen Welt, closed world assumption)
flache Strukturen (“in 1. Normalform’’)
- Tupel aus Konstantenzeichen als Attributwerte aufgebaut (entsprechend record_of)
- Relationen sind homogene Mengen von Tupeln (entsprechend set_of record_of)
- also stark eingeschränkte Verwendung von Typkonstruktoren
•
keine (ausführbaren Programme für) Anfragen als Attributwerte
strukturiert
nur Gleichheits- und Ungleichheits-Vergleiche bezüglich Konstantenzeichen
- Konstantenzeichen atomar
- Gleichheits- und Ungleichheits-Vergleiche kanonisch erweitert auf Tupel und Relationen
•
Konstantenzeichen uninterpretiert
- Semantik der Domänen nur in der Programmierumgebung dargestellt
•
nur “sprungfreie Anfrage-Programme’’
- Anfrageauswertung als Auswertung entsprechend Durchlauf durch Syntaxbaum der Anfrage
- keine Rekursion, unbeschränkte Iteration, ...
- kein ‘‘Ausführungsoperator’’ zum Aufrufen von in der Instanz gespeicherten Anfragen
•
unmittelbar vom Benutzer gesteuert
- Operationen werden explizit vom Benutzer aufgerufen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
239
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
240
relationales Datenmodell und mögliche Varianten, Erweiterungen,
Verallgemeinerungen
(eher) Architektur- und Anwendungsgesichtspunkte
(mit vielen Bezügen zu Strukturen und Operationen)
• ‘‘zentral’’ und “top-down’’
•
pures relationales Datenmodell für viele Anwendungen zu ‘‘ausdrucksschwach’’
‘‘homogen’’
•
- alle Daten vom strukturell gleichen Datentyp (set_of record_of)
- globale Interpretation semantischer Bereichsnamen
Ausgangspunkt für viele Varianten, Erweiterungen, Verallgemeinerungen
•
Wechselbeziehungen
- alle Daten unter einem im Vorhinein deklarierten Schema
•
•
‘‘statisch’’
relational:
‘‘ausdrucksschwach’’, aber:
wohl fundiert,
Äquivalenz von (operationalisierter) Algebra und (deklarativem) Kalkül,
Algorithmen auch bei großen Datenmengen hinreichend effizient,
Optimierung (weitgehend) automatisierbar,
viele zusätzliche Funktionalität zumindest näherungsweise ‘‘simulierbar’’,
wenn auch manchmal mühselig
erweitert:
‘‘ausdruckstärker’’, aber:
Fundiertheit, Effizienz, Optimierbarkeit, ... möglicherweise ‘‘gefährdet’’
- Administrator deklariert Schema im Vorhinein
- Schema wird als zeitlich unverändert angesehen
•
“normativ’’
- semantische Bedingungen werden als zu erzwingende Invarianten angesehen
•
client-server Architektur
- Benutzer und System handeln in festen Rollen, insbesondere als Anfrager und Antworter
manche sonstige Gesichtspunkte
• ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
241
•
Ziel:
•
Wirklichkeit: unzählige Einzelvorschläge, wenig mächtige integrierte Systeme
© Joachim Biskup, Universität Dortmund
Erweiterungen unter weitgehender Beibehaltung der ‘‘guten Seiten’’,
Verträglichkeit der Erweiterungen untereinander sicherstellen
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Rückblick und Würdigung
17. Juli 2003
242
Eigenschaften als Ausgangspunkt für weitergehende Modelle
6.2 relationales Datenmodell: Beispiele für Varianten,
Erweiterungen, Verallgemeinerungen
•
werteorientiert
- Identifikation von Tupeln nur vermöge ihrer Werte
- Gleichheit von Tupeln als Gleichheit aller Attributwerte
- keine benutzersichtbaren Tupelidentifikatoren
objektorientierte Modelle:
- Tupel als Objekte auffassen (dann auch Relationen und alles andere als Objekte auffassen)
- allgemeinere Objekte zulassen
- Objektidentifikatoren, OIDs, (Referenzen) als Objekt-Attributwerte zulassen
- verschiedene Gleichheitsbegriffe, z.B.:
* ‘‘referenzbezogen’’ als Gleichheit der Objektidentifikatoren
* ‘‘wertemäßig’’ als Gleichheit aller (unmittelbaren) Objekt-Attributwerte,
jeweils verstanden als Konstantenzeichen
* ‘‘semantisch’’ als Gleichheit der (impliziten) strukturierten Objekte,
die sich durch transitives Verfolgen aller Referenzen ergeben
- dann manchmal wünschenswert: ‘‘Wertedarstellbarkeit’’ (value representability), d.h.
alle (betrachteten) Gleichheitsbegiffe fallen zusammen
- Objektidentifikatoren und Werte als gleichrangig behandeln
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen 17. Juli 2003 243
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 244
•
flache Strukturen (“in 1. Normalform’’)
•
modelltheoretisch (und damit vollständig)
- Tupel aus Konstantenzeichen als Attributwerte aufgebaut (entsprechend record_of)
- Relationen sind homogene Mengen von Tupeln (entsprechend set_of record_of)
- also stark eingeschränkte Verwendung von Typkonstruktoren
- gespeicherte Instanz gedeutet als eine (endliche) Struktur im Sinne der Prädikatenlogik
- in gespeicherter Instanz nur Wahrheitswerte atomarer Aussagen explizit darstellbar
- “vollständiges Wissen’’: jede Aussage (der Prädikatenlogik) entweder wahr oder falsch
Modelle mit genesteten Strukturen
beweistheoretische Modelle
- gespeicherte Instanz gedeutet als
(endliche) Menge von (geschlossenen) Formeln der Prädikatenlogik
(d.h. von beliebigen Aussagen)
- Tupel können als Attributwerte wieder Relationen enthalten
- allgemeiner:
Tupel können (durch Schema bestimmte) genestete Relationen enthalten
- entsprechend: genestete Relationenschemas
- die gespeicherten Formeln werden als wahr
bezüglich einer (nicht explizit bekannten) Struktur angesehen;
alle erfüllenden Strukturen werden als möglich angesehen
- redefinerte Operationen (auf genesteten Relationen)
- zusätzliche Operationen:
nest
unnest
- in gespeicherter Instanz dann auch Wahrheitswerte beliebiger Aussagen explizit darstellbar,
insbesondere von:
* Disjunktionen
(zusätzlich zu impliziten Konjunktionen vermöge Mengenbildung)
* expliziten Negationen (zusätzlich oder gegebenenfalls notwendig anstelle der impliziten
Annahme der geschlossenen Welt)
- allgemeiner: folgende Typkonstruktoren sind beliebig verwendbar:
Tupelbildung (kartesisches Produkt), Mengenbildung (Potenzmenge)
- zusammen mit objektorientiert sind folgende Typkonstruktoren
beliebig verwendbar und führen zu ‘‘strukturierten Objekten’’:
Tupelbildung (kartesisches Produkt), Mengenbildung (Potenzmenge), Referenzbildung
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 245
- bei Anfragen ‘‘Implikation’’ anstelle von ‘‘Gültigkeit’’ auswerten,
d.h. Anfrageergebnisse beruhen auf Auswertung von:
‘‘ist (substituierte) Anfrageformel logisch impliziert von
gespeicherter Menge der Formeln in Instanz (und Schema)?’’
- gegebenenfalls auch ‘‘unvollständiges Wissen’’ darstellbar:
gespeicherte Menge Φ von Formel kann als logische ‘‘Theorie’’ unvollständig sein,
d.h. es kann (unbeantwortbare) Aussage(n) Ψ geben, so dass weder Φ |= Ψ noch Φ |= ¬Ψ
- semantisch definierte ‘‘Implikation’’ muss als
syntaktisch definierte ‘‘Beweisbarkeit’’ algorithmisiert werden
(was im Allgemeinen wegen der Unentscheidbarkeit der Implikation nicht möglich ist)
- anstelle von Negation als ‘‘Nicht-Gültigkeit in einer Struktur’’ wird verwendet
‘‘Nicht-Impliziertheit von einer Formelmenge’’,
was im Allgemeinen noch nicht einmal rekursiv aufzählbar ist;
algorithmisiert wird dann ‘‘Nicht-Impliziertheit von einer Formelmenge’’
(im Allgemeinen nichtäquivalent) ersetzt
durch ‘‘Nicht-Beweisbarkeit aus einer Formelmenge’’
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 246
klassische Prädikatenlogik
-
aussagenlogische Junktoren, Quantoren für Individuenvariablen
zweiwertige Wahrheitsfunktion
Negation als ‘‘Nicht-Gültigkeit’’
logische Implikation betrachtet alle Strukturen
Modelle mit ‘‘nichtklassichen Logiken’’
- zusätzliche Operatoren, z.B. in Modallogiken für ‘‘Agent i weiss’’ oder für ‘‘Agent i glaubt’’
- mehrwertige Logiken, z.B. statt Wahrheitswerte {falsch, wahr} beliebige Boolesche Algebra
- Negation, z.B. als Komplement-Operation in gewählter Boolscher Algebra
- nur ‘‘wahrscheinliche’’, ‘‘bevorzugte’’, ‘‘eigentlich gemeinte’’ Strukturen betrachten, d.h.
Φ |=κ- preference Ψ :gdw
für alle Strukturen M ∈ κ: falls M Modell von Φ, dann auch M Modell von Ψ
- ...
- wegen der Nichtberechenbarkeitsaussagen
nur für syntaktisch geeignet eingeschränkte Formelmengen durchführbar, z.B. HornFormeln
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 247
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 248
•
•
keine Funktionszeichen
•
- Instanzen erfüllen getrennt deklariertes Schema
logikorientierte Modelle mit Funktionszeichen
- erlauben z.B. Beziehungen ‘‘funktional auszudrücken’’
- erlauben z.B. Identifikationen über funktional ausgedrückte Beziehungen,
etwa wie in ‘‘Peters Frau’’
- ...
Modelle mit halbstrukturierten Daten
- jedes einzelne Datum einer Instanz trägt seine eigene strukturelle Beschreibung (‘‘Schema’’)
z.B. XML
- erlauben z.B. ‘‘Ausnahmen’’ leicht zu formalisieren
- erlauben Anfragen z.B. der folgenden Art:
‘‘welche Struktur hat dieses Datum?’’
‘‘welche Daten haben diese Struktur?’’
‘‘welche Daten haben eine Struktur, die dieser ‘‘ähnlich’’ ist?’’
...
keine (ausführbaren Programme für ) Anfragen als Attributwerte
Modelle mit speicherbaren Programmen
- erfordern zusätzliche Operation der Programmausführung (execute)
- erlauben z.B. dynamisch erzeugte Teil-Anfragen innerhalb einer Anfrage
- erlauben ‘‘reflektives Programmieren’’
- ...
© Joachim Biskup, Universität Dortmund
•
strukturiert
- Termbildung in Instanzen auf Konstantenzeichen beschränkt
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 249
‘‘vollständiges Wissen’’
- Tupel für alle deklarierten Attribute definiert (keine Nullwerte)
- nichtgespeicherte Tupel als negative Aussage gedeutet
(Annahme der geschlossenen Welt, closed world assumption)
Modelle mit Nullwerten
- Nullwert der Art ‘‘nicht existent’’
- Nullwert der Art ‘‘existent, aber unbekannt’’
- indizierte Nullwerte der Art
‘‘existent, dem Wert nach unbekannt, aber unterscheidbar’’, ggf. mit bekannten Gleichheiten
- ‘‘disjunktive Terme’’ der Art ‘‘c1 oder ... oder ck’’
-
als Objekte auch Bilder, Videos, Audios etc. zulassen (Multimedia-Informationssysteme)
inhaltsbasiertes Suchen und Vergleichen solcher Multimedia-Objekte
neue Konstruktoren für Ausgabeergebnisse
...
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 250
‘‘genaues Wissen’’
- Tupelwerte als atomare Konstantenzeichen
- kein “ungefähr”, ...
Modelle mit ungenauem Wissen
- ...
Modelle mit Annahme der offenen Welt
- nicht gespeicherte Daten (nicht aus gespeicherten Daten beweisbare Daten)
werden als ‘‘unbekannt’’ gedeutet
- sogenanntes ‘‘frame problem’’: wie die unübersehbare Fülle von ‘‘negativen Ausagen’’
(speziell bei Änderungsoperationen von invarianten Aussagen) ausdrücken?
- Sprachmittel für gezielten ‘‘Abschluss von Prädikaten’’:
aus einer ‘‘wenn-dann-Definition’’ eine ‘‘genau-dann-wenn-Definition’’gewinnen,
ohne alle ‘‘negativen Fälle’’ ausdrücklich aufzuzählen
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 251
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 252
•
“bestimmtes Wissen’’
- Tupel entweder gespeichert oder nicht gespeichert, bzw.
entspechende Aussage entweder wahr oder nicht wahr,
kein Modalitäten, Wahrscheinlichkeiten, Bewertungen usw.
(eher) operationale Gesichtspunkte (mit vielen Bezügen zu Strukturen)
• wenige Standardoperationen
- Anfragen (query),
Tupel-Einfügen (insert),
Tupel-Entfernen (delete),
Tupel-Ändern (update)
- als “Mehrwertdienst” nur
(mengenorientierte, ausgabeformierte) logische Gültigkeit (Implikation)
Modelle mit ‘‘nichtklassischen Logiken’’
Modelle mit fuzzy logic
- Aussagen erhalten Bewertungen im Intervall [0..1]
- Semantik der logischen Operatoren geeignet redefinieren, z.B.
Konjunktion liefert ‘‘Minimum’’ als Bewertung,
Disjunktion liefert ‘‘Maximum’’ als Bewertung
- ...
Modelle mit Methoden
- Objekte mit typ- oder klassen-spezifischen Methoden
- Informationssystem mit universellem Programmiersystem verbinden
- Informationssystem mit Simulations- und Prognosesystemen verbinden
- ...
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 253
nur Gleichheits- und Ungleichheits-Vergleiche bezüglich Konstantenzeichen
- Konstantenzeichen atomar
- Gleichheits- und Ungleichheits-Vergleiche kanonisch erweitert auf Tupel und Relationen
© Joachim Biskup, Universität Dortmund
•
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 254
Konstantenzeichen uninterpretiert
- Semantik der Domänen nur in der Programmierumgebung dargestellt
Modelle mit vordefinierten Datentypen
- arithmetische Datentypen für Verwaltungsaufgaben
Modelle mit Multimedia-Objekten und Ähnlichkeitsvergleichen
- Ähnlichkeits-Vergleiche für Texte, Bilder, Videos, Audios etc.
- Ähnlichkeit auf Begriff von ‘‘Abstand’’ gründen
- Anfrageergebnisse gemäß Rangfolge bezüglich Ähnlichkeit anordnen
- Datentyp “Zeit’’:
alle Daten mit ‘‘Zeitangaben’’ versehen,
‘‘Ereigniszeit’’ und ‘‘Speicherzeit’’ unterscheiden,
alle Operationen redefinieren
- Datentyp ‘‘Raum’’ (insbesondere für ‘‘geographische Datenbanken’’)
- ...
- ...
- syntaktisch definierte ‘‘Ähnlichkeiten’’ deuten als ‘‘semantische Beziehungen’’
- Qualitätsmaße bezüglich ‘‘Treffer’’ und ‘‘Fehltreffer’’
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 255
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 256
•
nur “sprungfreie Anfrage-Programme’’
•
- Anfrageauswertung als Auswertung entsprechend Durchlauf durch Syntaxbaum der Anfrage
- keine Rekursion, unbeschränkte Iteration, ...
- kein ‘‘Ausführungsoperator’’ zum Aufrufen von in der Instanz gespeicherter Anfragen
- Operationen werden explizit vom Benutzer aufgerufen
Modelle ‘‘aktiver Informationssysteme’’
- Trigger vereinbar: lösen Operationen als Folge anderer Operation aus
Modelle mit Ausdruckskraft für Rekursionen
- programmiersprachlich:
Relationenvariablen und Kontrollstrukturen, insbesondere unbeschränkte Wiederholung
- E(vent)C(ondition)A(ction)-Regeln vereinbaren:
beim Eintreten eines ‘‘events’’ unter der Voraussetzung einer ‘‘condition’’
eine (möglicherweise zusammengesetzte) ‘‘action’’ auslösen
- algebraisch: Fixpunktoperator
- verlangt Lösungen für alle schwierigen Probleme der
Semantik paralleler Programmiersprachen
- monoton logikorientiert: Relationenvariablen und Rekursionen (Auswertung über Fixpunkte)
- nichtmonotone Fälle: Auswertung über geschichtete Fixpunkte, falls möglich und eindeutig
- erlauben z.B. Wirklichkeitsmodelle zu simulieren
- ...
© Joachim Biskup, Universität Dortmund
•
unmittelbar vom Benutzer gesteuert
- ...
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 257
ganz allgemein:
Trennung von ‘‘universellem Programmiersystem’’ und ‘‘Informationssystem’’
- wohldefinierte Schnittstellen zwischen
‘‘Anwendungsumgebungen’’ und ‘‘eigentlichem Informationssystem’’
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 258
(eher) Architektur- und Anwendungsgesichtspunkte
(mit vielen Bezügen zu Strukturen und Operationen)
• ‘‘zentral’’ und “top-down’’
- alle Daten unter einem im Vorhinein deklarierten Schema
integrierte Programmier- und Informationssysteme
- ‘‘semantische Lücken’’ schließen
verteilte Architekturen
- Daten verteilen, zerlegend oder überlappend, und bei Bedarf übermitteln
- Problem der ‘‘Erneuerung’’ (refreshment)
- Operationen verteilen
- ...
- einheitliche Behandlung grundlegender Datentypen
- Programmiersystem mit ‘‘Dauerhaftigkeit (von gespeicherten Daten)’’
- Informationssystem mit ‘‘Universalität (von verfügbaren Anweisungen)’’
- ...
•
‘‘homogen’’
- alle Daten vom strukturell gleichen Datentyp (set_of record_of)
- globale Interpretation semantischer Bereichsnamen
verteilte und inhomogene Architekturen (z.B. föderierte Informationssysteme)
- Übersetzungen zwischen verschieden Formalisierungen
- 5-Schema-Architektur: intern, konzeptionell, extern, export, global
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 259
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 260
•
‘‘statisch’’
•
- Administrator deklariert Schema im Vorhinein
- Schema wird als zeitlich unverändert angesehen
•
client-server Architektur
- Benutzer und System handeln in festen Rollen, insbesondere als Anfrager und Antworter
verteilte und dynamische Architekturen (z.B. mediierte Informationssysteme)
- dynamisches Binden (und Entfernen) von Informationsquellen
Performative unterstützende Modelle
(z.B. Knowledge and Query Manipulation Language, KQML)
- Agenten führen situationsbedingte ‘‘Performative’’ (Sprachhandlungen) aus
- (halb-automatische) Erzeugung von ‘‘wrappern’’
- Absichten, Angebote usw. ausdrückbar
- ...
- Vermittlerdienste dynamisch anbietbar
- ‘‘Ontologien’’ zur Verständigung mitlieferbar
“normativ’’
- ...
- semantische Bedingungen werden als zu erzwingende Invarianten angesehen
‘‘faktisch und explorativ’’
- in vorhandenen Daten werden erfüllte Bedingungen gesucht
- ‘‘data mining’’
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 261
© Joachim Biskup, Universität Dortmund
Informationssysteme: Relationales Datenmodell und Erweiterungen - relationales Datenmodell: Beispiele für Varianten, Erweiterungen, Verallgemeinerungen17. Juli 2003 262
Navigation in Schema und Instanz
•
7 Erweiterte Navigationsmöglichkeiten
relationales Datenmodell
Navigation auf Schemaebene: ‘‘fest-beschränkte’’ Pfade im Hypergraphen des Schemas
Navigation auf Instanzenebene: Auswertung solcher Pfade bezüglich Instanz durch Verbunde
Navigation auf ‘‘Universalrelationsicht’’: (halb-) automatische Generierung solcher Pfade
•
beweistheoretische Modelle mit Horn-Formeln als Anfragen
Navigation auf Schemaebene: ‘‘rekursive Pfadmuster’’ im Hypergraphen des Schemas
Navigation auf Instanzenebene: unbeschränkte, datenabhängige Auswertung solcher Pfade
bezüglich Instanz durch Fixpunkt
•
objektorientierte Modelle mit Dereferenzierung in Anfragen
Navigation auf Schemaebene: ‘‘fest-beschränkte Pfade im ‘‘Verweis-Graphen’’ des Schemas
Navigation auf Instanzenebene: Auswertung solcher Pfade bezüglich Instanz durch
‘‘Verbunde über Dereferenzierungen’’
•
Beispiel aus Theorie:
F-Logik: erlaubt sogar Horn-Formeln als Anfragen mit (abstrakten) Dereferenzierungen
•
Beispiel aus Praxis:
Oracle-SQL: enthält als sogenanntes ‘‘objekt-relationales’’ System einige pragmatische Ansätze
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten
17. Juli 2003
263
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten
17. Juli 2003
264
Navigation im relationalen Datenmodell
grobes ‘‘Kochrezept’’ für Formalisierung einer Anfrage (verkürzte Wiederholung):
bestimme formale Entsprechungen für
•
7.1 erweiterte Navigation durch Horn-Formeln als Anfragen
Begriffe
als Attribute, Relationensymbole, semantische Bereichsnamen oder Konstantenzeichen
•
Zusammenhänge
als Pfad im Hypergraphen des Schemas (entsprechend einer Folge von Verbunden)
•
Zwecke
als Selektionen und Projektionen
also:
• Navigation auf Schemaebene liefert
‘‘fest-beschränkten’’ Pfad im Hypergraphen des Schemas,
im Wesentlichen formalisiert durch einen Ausdruck mit fester Anzahl von Verbunden
• Navigation auf Instanzenebene wertet genau diesen Ausdruck aus,
mit der im Ausdruck festgelegten datenunabhängigen Anzahl von Verbunden
• datenabhängige Anzahl von Verbunden (für z.B. ‘‘transitive Hülle’’) nicht ausdrückbar
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten
17. Juli 2003
265
Ansatz für beweistheoretische Deutung der Strukturen des
relationalen Datenmodells
Relationenschema mit Ri ≠ Rj für i ≠ j
globale semantische Bedingungen
Vereinbarung der semantischen Bereichsnamen
EDB := { R1 ,..., Rn }
Basisrelationen (extensional database relations)
unendliche Menge der Konstantenzeichen
Menge der Relationensymbole
Menge der Individuenvariablen
Menge der Terme
R(t1,...,ts) mit R ∈ R und t1,...,ts ∈ T
R(c1,...,cs) mit R ∈ R und c1,...,cs ∈ C
atomare Formel
atomare Grundformel
rel(K)
concl(K)
gedeutet als entsprechende Menge von Grundfakten
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
C
R
V
T := C ∪ V
A0
A1,...,Am
Ansatz für beweistheoretische Semantik:
µ ∈ ri mit Xi = {A1,...,Asi} gedeutet als Grundfakt (atomare Grundformel)
der Form Ri(A1:c1,...,Asi:csi). mit cj =µ(Aj ), kurz Ri(c1,...,csi).
© Joachim Biskup, Universität Dortmund
17. Juli 2003
266
A0 :- A1,...,Am. mit A0, A1,...,Am atomare Formel und m ∈ IN0, Abkürzung für
A0∨¬A1∨¬A2∨...∨¬Am
(Horn-) Klausel
modelltheoretische Semantik:
M = (d,r1,...,rn)
Instanz zu RS mit
i) d ⊂endlich C
ii) (d,ri) ist Instanz zu < Ri | Xi | SCi >
iii) (d,r1,...,rn) ist Modell von SC
iv) falls µ ∈ ri und A ∈ Xi , dann gilt µ(A) ∈ b ° a (A)
f = ∪i=1,...,n ri
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
Schreib- und Redeweisen für Horn-Formeln
Syntax:
RS = < <R1 | X1 | SC1> ,..., <Rn | Xn | SCn> | SC | a > (relationales Datenbank-) Schema mit
- < Ri | Xi | SCi >
- SC
- a : ∪i=1,...,n Xi → B
© Joachim Biskup, Universität Dortmund
17. Juli 2003
267
Konklusion
Prämissen
:=
:=
Menge der vorkommenden Relationensymbole
das in der Konklusion vorkommende Relationensymbol
A0. Abkürzung für
A0 :- .
A0. mit A0 atomare Grundformel
Fakt
Grundfakt
A0 :- A1,...,Am.
HK
GF
Regel
Menge der Horn-Klauseln
Menge der Grundfakten
© Joachim Biskup, Universität Dortmund
mit m > 1
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
268
erweiterte Operationen mit beweistheoretischer Deutung
Hypergraph für Beispiel:
PERSON
Syntax:
Geschlecht
< R | Q > LOGODAT-Anfrage mit
- R ∈ R \ {=}
Name
Eltern
ELT
Ergebnisrelationensymbol (für Format der Ergebnisse)
- Q ⊂endlich HK mit concl (Q) ⊂ R \ (EDB ∪ {=})
(Hornklausel-)Anfrageprogramm (zum Erschließen der Ergebnisse)
Patient
Mensch
Arzt
beabsichtigte deklarative Semantik:
ArtPro
alle logischen Implikationen aus der gespeicherten Instanz und der Anfrage gemäß Format
BEH
Beziehung
Pfad
Tochter-Elternteil-Beziehung:
Geschlecht, Name, Eltern
Vorfahr-Beziehung, transitive Hülle von ELT: Name, Eltern_1 = Name_2,
Eltern_2 = Name_3, ... , Eltern_t
gleiche-Generation-Beziehung:
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
269
© Joachim Biskup, Universität Dortmund
Beispiele
| { TOCHTER (Name, Eltern) :-
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
270
Ansatz für formale Definition der deklarativen Semantik
Beispiel 1 (Tochter-Elternteil-Beziehung):
< TOCHTER
verfolge simultan Pfade gleicher Länge,
die Nachfahren bestimmen
ELT (Name, Eltern),(AND)
PERSON (Name, Geschlecht),(AND)
= (Geschlecht, weib).
}
>
RS mit EDB = {R1 ,..., Rn}
<R|Q>
Schema
LOGODAT-Anfrage
evalRS (< R | Q >)
ordnet jeder Instanz (Menge von Grundfakten) f zu RS
eine Menge von Grundfakten zum Relationensymbol R zu:
Beispiel 2 (Vorfahr-Beziehung, transitive Hülle von ELT):
< VORFAHR
| { VORFAHR (Name, Ahn)
:-
ELT (Name, Ahn). ,(OR)
VORFAHR (Name, Ahn)
:-
ELT (Name, Eltern),(AND)
VORFAHR(Eltern, Ahn). }
evalRS (< R | Q >) (f) := { R (c1,..., cs). | f ∪ Q |= R (c1,..., cs). mit c1,..., cs ∈ C }
>
|=
Beispiel 3 (gleiche-Generation-Beziehung):
< GLEICHGEN |{GLEICHGEN (Name, Name) :-
ELT (Name, Eltern). ,(OR)
GLEICHGEN (Eltern, Eltern) :-
ELT (Name, Eltern). ,(OR)
GLEICHGEN (Name_1, Name_2) :-
© Joachim Biskup, Universität Dortmund
ELT (Name_1, Eltern_1),(AND)
ELT (Name_2, Eltern_2),(AND)
GLEICHGEN (Eltern_1, Eltern_2). }
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
logische Implikation für LOGODAT-Strukturen,
mit Universum C,
wobei Konstantenzeichen aus C
stets durch sich selbst interpretiert werden,
insbesondere:
alle Elemente des Universums haben einen eindeutigen Namen
(unique name assumption)
>
271
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
272
Grundfakten-Transformation als Grundbaustein für operationale
Fixpunktsemantik
bislang:
deklarative Semantik vermöge |=
gesucht:
dazu äquivalente operationale Semantik
Grundfakten-Transformation und Resolution
Definition Grundfakten-Transformation (Wiederholung):
gegeben:
Klausel K ≡ A0 :- A1,..., Am. mit rel (A0) ∈ R \ {=}
zugeordnete Grundfakten-Transformation TK:
TK : ℘ GF → ℘ GF,
TK (g) := { R (c1,..., cs). |
Grundfakten-Transformation als Grundbaustein dafür:
gegeben:
Klausel K ≡ A0 :- A1,..., Am. mit rel (A0) ∈ R \ {=}
zugeordnete Grundfakten-Transformation TK:
TK : ℘ GF → ℘ GF,
TK (g) := { R (c1,..., cs). |
es gibt Variablenbelegung γ mit
(1) γ (A0) ≡ R (c1,..., cs) und
(2) für alle i = 1,..., m: γ (Ai.) ∈ g ∪ { =(c,c). | c ∈ C } }
es gibt Variablenbelegung γ mit
γ (A0) ≡ R (c1,..., cs) und
γ (Ai.) ∈ g ∪ { =(c,c). | c ∈ C } für i = 1,..., m }
Beobachtung:
Eine Grundfakten-Transformation TK angewendet auf Grundfakten g beinhaltet im Wesentlichen:
alle (derzeit ausführbaren) (Hyper-)Resolutionen
gegeben:
Klauselmenge K mit concl (K) ∈ R \ {=} für alle K ∈ K
zugeordnete Grundfakten-Transformation TK:
von der Klausel K einerseits
mit Atomen aus g und Gleichheitsatomen andererseits
TK : ℘ GF → ℘ GF,
TK (g) :=
© Joachim Biskup, Universität Dortmund
∪K ∈ K
mit jeweiligem allgemeinsten Unifikator γ
TK (g)
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
273
© Joachim Biskup, Universität Dortmund
Beispiel für iterierte Anwendung der Grundfakten-Transformation
K:= { ELT (anton, fritz).
,
ELT (maria, anton). ,
ELT (hugo, anton). ,
GLEICHGEN (Name, Name)
GLEICHGEN (Eltern, Eltern)
(1)
(2)
(3)
::-
GLEICHGEN (Name_1, Name_2) :-
ELT (Name, Eltern). ,
ELT (Name , Eltern). ,
(4)
(5)
ELT (Name_1, Eltern_1),
ELT (Name_2, Eltern_2),
GLEICHGEN (Eltern_1, Eltern_2). }
(6)
g1 := TK(Ø)
=
{
ELT (anton, fritz). ,
g2 := TK(g1)
=
{
ELT (anton, fritz). ,
ELT (maria, anton). , ELT (hugo, anton). ,
GLEICHGEN (anton, anton). , GLEICHGEN (maria, maria). ,
GLEICHGEN (hugo, hugo). , GLEICHGEN (fritz, fritz).
}
g3 :=TK(g2)
=
Beobachtung:
© Joachim Biskup, Universität Dortmund
{
ELT (maria, anton). ,
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
274
17. Juli 2003
276
Fixpunktsatz für Grundfakten-Transformation
bekannt:
(℘ GF, ⊂) ist ein vollständiger Verband
Hilfssatz 1:
TK ist monoton,
d.h. für alle g, g' ⊂ GF gilt:
g ⊂ g' ⇒ TK (g) ⊂ TK (g').
Hilfssatz 2:
TK ist stetig,
d.h. für alle ω-Ketten g0 ⊂ g1 ⊂ g2 ⊂ ... ⊂ GF gilt:
TK ( ∪i ∈ ω gi) =
∪i ∈ ω
TK (gi).
Fixpunktsatz von Tarski-Kleene
ELT (hugo, anton). }
Sei (H, ⊂) eine ω-vollständige Halbordnung
mit kleinstem Element ∅ und Supremumsoperation ∪,
und sei T : H → H eine monotone und stetige Transformation.
1.
ELT (anton, fritz). ,
ELT (maria, anton). , ELT (hugo, anton). ,
GLEICHGEN (anton, anton). , GLEICHGEN (maria, maria). ,
GLEICHGEN (hugo, hugo). , GLEICHGEN (fritz, fritz). ,
GLEICHGEN (maria, hugo). , GLEICHGEN (hugo, maria).
}
2.
T besitzt einen eindeutig bestimmten kleinsten Fixpunkt fix ∈ H,
d.h. es gibt fix ∈ H mit T (fix) = fix und
für alle x ∈ H: T (x) = x ⇒ fix ⊂ x
Der kleinste Fixpunkt fix ergibt sich durch
fix =
∪i ∈ ω
.
Ti (∅).
g3 ist Fixpunkt der Grundfakten-Transformation TK
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
275
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
TK ist monoton, d.h. für alle g, g' ⊂ GF gilt:
g ⊂ g' ⇒ TK (g) ⊂ TK (g')
operationale Fixpunktsemantik von LOGODAT-Anfragen
Definition:
RS mit EDB = {R1 ,..., Rn}
<R|Q>
f
folgt direkt aus der Definition der Grundfakten-Transformation
Schema
LOGODAT-Anfrage
Instanz (Menge von Grundfakten zu EDB)
TK ist stetig,
d.h. für alle ω-Ketten g0 ⊂ g1 ⊂ g2 ⊂ ... ⊂ GF gilt:
TK (
evalRSfix (< R | Q >) (f) := { R (c1,...,ct). | R (c1,...,ct). ∈ fix (f ∪ Q) },
∪i ∈ ω
“⊃”: gemäß Monotonie
“⊂”: betrachte:
Definition von TK:
wobei fix (f ∪ Q) kleinster Fixpunkt
der f ∪ Q zugeordneten Grundfakten-Transformation Tf∪Q
gi) =
∪i ∈ ω
TK (gi)
R (c1,...,cs). ∈ TK ( ∪i ∈ ω gi).
es gibt Klausel K ≡ A0 :- A1,..., Am. ∈ K und
Variablenbelegung γ mit
(1) γ (A0) ≡ R (c1,...,cs) und
(2) γ (Aj.) ∈
Satz [Korrektheit und Vollständigkeit der Fixpunktsemantik]:
evalRSfix (< R | Q >) (f) =
Klausel K endlich:
evalRS (< R | Q >) (f) für alle Instanzen f zu RS
© Joachim Biskup, Universität Dortmund
(1) und (2*):
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
277
Fixpunktsatz von Tarski-Kleene
i = 0:
(1) Ti (∅) ⊂ Ti+1 (∅) für alle i ∈ ω, durch Induktion über i:
i = 0:
T0 (∅)
= ∅ ⊂ T1 (∅)
i > 0:
Ti+1 (∅) = T (Ti (∅))
Definition von Ti+1
i-1
⊃ T (T (∅))
Induktionsannahme und Monotonie von T
= Ti (∅)
Definition von Ti
i
(2) ∪i ∈ ω T (∅) Element von H
ω-Vollständigkeit
(3) Fixpunkt-Eigenschaft:
T ( ∪i ∈ ω Ti (∅)) = ∪i ∈ ω T (Ti (∅))
(1) und Stetigkeit von T
=
=
∪i ∈ ω
(∅)
i
∪i ∈ ω T (∅)
Definition von
T0 (∅) = ∅
(4) kleinster Fixpunkt: für beliebigen Fixpunkt x mit T (x) = x gilt: (∅) ⊂ x für alle i ∈ ω
i = 0: T0 (∅) = ∅ ⊂ x
i + 1: Ti+1 (∅) = T (Ti (∅))
Definition von Ti+1
⊂ T (x)
Induktionsannahme und Monotonie von T
= x
T(x) =x
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
R (c1,...,cs). ∈ TK (ge) ⊂
∪i ∈ ω
279
TK (gi)
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
278
K |= TKi (∅)
trivial wegen TK0 (∅) = ∅
i > 0:
Induktionsannahme:
Voraussetzung:
Voraussetzung:
K |= TKi-1 (∅)
(1)
i
R (c1,...,cs). ∈ TK (∅) \ TK
M ist Modell von K
i-1
(∅)
zu zeigen: M ein Modell von R (c1,...,cs)
Beweis:
(2) mit Definition von TK: es gibt Klausel K ≡ A0 :- A1,...,Am. ∈ K und
Variablenbelegung γ mit
γ (A0) ≡ R (c1,...,cs) und
γ (Aj.) ∈ TKi-1 (∅) ∪ { =(c,c). | c ∈ C } für j = 1,...,m
Ti+1
Ti
© Joachim Biskup, Universität Dortmund
∪ { =(c,c). | c ∈ C } für j = 1,...,m
ge
TKi (∅) enthält nur Implikationen von K:
T : H → H monotone und stetige Transformation für ω-vollständige Halbordnung (H, ⊂)
mit kleinstem Element ∅ und Supremumsoperation ∪:
T besitzt einen eindeutig bestimmten kleinsten Fixpunkt fix ∈ H mit fix = ∪i ∈ ω Ti (∅).
Ti+1
© Joachim Biskup, Universität Dortmund
gi ∪ { =(c,c). | c ∈ C } für j = 1,...,m
es gibt ein Kettenelement ge mit
(2*) γ (Aj.) ∈
Beweisskizzen:
∪i ∈ ω
(3) und (1) zusammen mit der trivialen Gültigkeit von Gleichheitsfakten:
M ist Modell von γ (Aj.) für j = 1,...,m
(3):
M ist Modell von γ (K)
(6) und (7), mit (4):
M ist Modell von γ(A0) ≡ R (c1,...,cs)
(2)
(3)
(4)
(5)
(6)
(7)
kleinster Fixpunkt von TK enthält nur Implikationen von K: K |= fix (K)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
280
kleinster Fixpunkt von TK ist - kanonisch als eine LOGODAT-Struktur aufgefasst ein Modell von K (kleinstes Herbrand-Modell):
Model(fix(K)) ∈ Mod (K)
angenommen:
M := Model (fix (K)) ist kein Modell von K
Definition ‘‘Modell’’:
es gibt es eine Klausel K ≡ A0 :- A1,...,Am. ∈ K, so dass gilt:
M ist kein Modell von K
d.h.:
es gibt eineVariablenbelegung β mit
|≠M,β A0.
|=M,β Aj. für j = 1,...,m
(1a)
(1b)
Definition von M und (1): β (A0.) ∉ fix (K)
β (Aj.) ∈ fix (K) ∪ { =(c,c) | c ∈ C } für j = 1,...,m
(2a)
(2b)
Definition der Grundfakten-Transformation und Fixpunkteigenschaft:
β (A0.) ∈ TK (fix (K)) = fix (K)
(3)
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
17. Juli 2003
- jedes von Fixpunktsemantik erzeugte Grundfakt ist korrekt:
es ist eine logische Implikation der zu verarbeitenden Klauseln
- alle logisch implizierten Grundfakten werden vollständig von der Fixpunktsemantik erzeugt
Behauptung:
evalRSfix (< R | Q >) (f) = evalRS (< R | Q >) (f)
zu zeigen:
für fix := fix (f ∪ Q)
R (c1,...,cs). ∈ fix
“⇒”[Korrektheit]:
Widerspruch zu (2)!
© Joachim Biskup, Universität Dortmund
Äquivalenz der deklarativen Semantik und der operationalen Fixpunktsemantik:
281
andererseits:
Model(fix)
(1) und (2) :
f∪Q
•
•
∈
Mod (f ∪ Q)
(2)
|≠
R (c1,...,cs).
17. Juli 2003
282
Klauselmenge:
•
P( P1:x, P2:y ).
P( P1:x, P2:z ), T( T1:z, T2:y ).
Wertzuweisung mit algebraischem Ausdruck:
T( T1, T2 )
- führe Wiederholungsanweisung durch:
berechne simultan alle Wertzuweisungen,
bis keine Änderungen mehr erfolgen
:=
π[ (T1,X) , (T2,Y) ]( π[ (X,P1) , (Y,P2) ] (P) )
∪
π[ (T1,X) , (T2,Y) ]( π[ (X,P1) , (Z,P2) ] (P)
Abhängigkeitsgraph:
P
π[ (Z,T1) , (Y,T2) ] (T) )
K1
T
K2
differentiell:
- versuche Duplikate zu vermeiden:
jeweils für ein Argument einer Wertzuweisung nur ‘‘gerade neu erzeugte Fakten’’ benutzen
•
(1)
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
K1 ≡ T( T1:x, T2:y ) :K2 ≡ T( T1:x, T2:y ) :-
Projektion-Selektion-Vergleich-Ausdruck
Vergleich-Verbund-Ausdruck
Projektion und ‘‘Relationenvariable’’
Wertzuweisung der Form
‘‘Relationenvariable’’
:= Projektion(Vereinigung-Ausdruck)
- bilde Abhängigkeitsgraphen
als ‘‘Petrinetz-ähnliches Datenfluss-Modell’’ für alle Wertzuweisungen
•
fix
Mod (R (c1,...,cs).)
einfaches Beispiel für naive Auswertung: transitive Hülle
naiv:
- übersetze Klauseln in relationale Algebra:
einzelne Prämisse
in
Folge der Prämissen
in
Konklusion
in
Klauseln mit gleicher Konklusion in
kleinster Fixpunkt enthält nur logische Implikationen
R (c1,...,cs). ∉
Model(fix) ∉
Auswertung von LOGODAT-Anfragen: grober Überblick
•
kleinsten Fixpunkt von Tf∪Q, für c1,...,cs ∈ C:
gdw
f ∪ Q |= R (c1,...,cs).
“⇐”[Vollständigkeit]:
betrachte:
Definition von Model (fix):
© Joachim Biskup, Universität Dortmund
für alle Instanzen f zu RS
•
Wiederholung:
REPEAT
(‘‘magic set-’’) optimiert durch ‘‘Vorziehen von Selektionen’’
- versuche frühestmöglich Variablen mit Konstanten zu binden
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
T_neu := ∅ ;
UNTIL
17. Juli 2003
283
© Joachim Biskup, Universität Dortmund
T
:= T_neu ;
T_neu := Expression( P, T )
T = T_neu ;
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Horn-Formeln als Anfragen
/*wie oben definiert
17. Juli 2003
284
Beispiel: eine Modellierung mit objektorientierter Formalisierung
7.2 erweiterte Navigation durch Dereferenzierung in Anfragen für
objektorientierte Modelle
Person
Name
Kind
ISA
Patient
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
17. Juli 2003
285
© Joachim Biskup, Universität Dortmund
Prot, Arzt
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
17. Juli 2003
286
17. Juli 2003
288
Zeichenerklärung
Dictionary mit zugehörigen
Elementobjekten
Dictionary mit zugehörigen Elementobjekten
Objekt vom Typ
Dictionary(als B*-Baum)
Objekt vom Typ
Set
Dictionary-(über- Person_Typ )Objekt
Dictionary-(über- Patient_Typ )-Objekt
PATIENT
●
Objekt vom Typ Person_Typ, Patient_Typ
Behandlung_Typ
●
i
●
PERSON
●
oder
i
●
●
●
N:
j
jk
K:
●
N:
Person_TypObjekt
●
●
P:
B:
j
K:
●
●
Verweise über Adressen / UIDs (wobei die Schreibweise
eine durchgezogene Linie ersetzt)
i
i
●
●
●
●
•j k
●
●
Person_Typ- Objekt mit
"angeheftetem" Objekt
A:
Patient_TypObjekt
Behandlung_TypObjekt
●
●
durch Verweisstrukturen gebildete
"zusammengesetzte Objekte"
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
Patient_Typ- Objekt mit
"angehefteten" Objekten
●
●
17. Juli 2003
287
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
objektorientierte Formalisierung eines Patienten namens Maria
PATIENT
1
2
4
graphisch:
PERSON
6
1
2
3
4
5
6
6
4
N: "hugo"
K:
K:
B:
B:
6
N: "maria"
P: "haus"
A:
B:
3
4
P: "unter"
A:
P: "labor"
A:
B:
P: "berat"
A:
2
N: "fritz"
3
5
N: "josef"
© Joachim Biskup, Universität Dortmund
behandlung(maria, "labor", gerda) [protokoll
behandlung(maria, "haus", gerda) [protokoll
behandlung(maria, "rönt", gerda) [protokoll
1
P: "berat"
A:
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
17. Juli 2003
289
Regeln mit Dereferenzierungen in F-Logik
dann
wert_relationBEH [ einPatientAusgabe
einProtokollAusgabe
einArztAusgabe
{Y}]
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
290
Yausgabe] :-
⇒ (string);
⇒ (string);
⇒ (string) ]
behAusgabe(X,Y):wert_relationBEH [ einPatientAusgabe
einProtokollAusgabe
einArztAusgabe
X : patient [ name
Xausgabe;
behandlungen
{Y}
Y
[ protokoll
Yausgabe;
Z
[ name
Zausgabe
X ein Objekt der Klasse person bezeichnet,
das unter dem mengenwertigen Attribut kinder
auf ein Objekt Y (vom Typ person_typ) verweist,
bezeichne el_ki(X,Y) ein Objekt der Sicht sur_relationELT,
das unter dem skalaren Attribut eltern auf das Objekt X
und unter dem skalaren Attribut kind auf das Objekt Y verweist’’
© Joachim Biskup, Universität Dortmund
17. Juli 2003
der Relation BEH entsprechende Sicht durch verschmolzene Definition:
dieses Beispiel liefert die Surrogatpaare für die Eltern-Kind-Beziehungen:
‘‘wenn
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
eltAusgabe(Z):wert_relationELT [elternAusgabe
Xausgabe; kindAusgabe
Z : sur_relationELT [eltern
X; kind
Y ],
X
[name
Xausgabe
],
Y
[name
Yausgabe
]
Signaturmoleküle vereinbaren das Schema (Attribute und Domänen) der Sicht, hier:
sur_relationELT [ eltern ⇒ (person_typ); kind ⇒ (person_typ)]
X : person [kinder
gerda ]
gerda ]
gerda ]
wert_relationELT [ elternAusgabe ⇒ (string); kindAusgabe ⇒ (string)]
Terme bildet man mit Hilfe von geeigneten Funktionszeichen, hier:
sur_relationELT:
Konstantenzeichen für die Klasse der in der Sicht enthaltenen Objekte
el_ki:
zweistelliges Funktionszeichen;
el_ki(o1,o2) bezeichnet jeweils ein in der Sicht enthaltenes Objekt
Y ] :-
© Joachim Biskup, Universität Dortmund
"labor"; arzt
"haus"; arzt
"rönt"; arzt
benutzersichtbare Darstellung der zugehörigen Namenspaare durch zusätzliche Sicht:
Sichten (Anfragen) in der F-Logik bestehen aus Objekten, die durch Terme bezeichnet werden
Horn-Klauseln bestimmen die Objekte der Sicht, hier:
el_ki(X,Y): sur_relationELT [ eltern
X; kind
]
K:
K:
B:
3
maria [name
"maria" ]
maria [kinder
{}
]
maria [behandlungen
{ behandlung(maria, "labor", gerda),
behandlung(maria, "haus", gerda),
behandlung(maria, "rönt", gerda) }
6
K:
P: "haus"
A:
in F-Logik:
N: "gerda"
K:
P: "rönt"
A:
N: "anton"
P: "labor"
A:
P: "rönt"
A:
P: "labor"
A:
K:
1
N: "maria"
17. Juli 2003
291
© Joachim Biskup, Universität Dortmund
Xausgabe ;
Yausgabe ;
Zausgabe ]
arzt
Z
:],
],
]
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
17. Juli 2003
292
Veranschaulichung der Horn-Klausel für wert_relationBEH
8 Datenmodelle für halb-strukturierte Daten
PATIENT
X
N: Xausgabe
K:
B:
Y
P: Yausgabe
A:
Z
N:
Zausgabe
K:
© Joachim Biskup, Universität Dortmund
Informationssysteme: Erweiterte Navigationsmöglichkeiten - erweiterte Navigation durch Dereferenzierung in Anfragen für objektorientierte Modelle
17. Juli 2003
293
strukturierte versus halb-strukturierte Daten
strukturiert
© Joachim Biskup, Universität Dortmund
halb-strukturiert
im Vorhinein vereinbart
statisch (zeitunabhängig) bei Einrichtung
für alle (Instanz-)Daten verbindlich
von Instanz-(Daten) “getrennt speicherbar”
“globale” Selbstbeschreibung
der Datengesamtheit
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
294
•
dynamisch angeforderter Austausch und/oder “semantische” Integration
von heterogenen komplexen Objekten (Daten)
zwischen autonomen Agenten
sollen ermöglicht werden
- im Einzelfall gebildet
- dynamisch bei Datenerzeugung
- individuell für einzelnes Datum gültig
- zusammen mit Datum gespeichert
- “lokale” Selbstbeschreibung
eines einzelnen Datums
•
Austausch und “semantische” Integration
sollen miteinander verwoben werden
und halb-algorithmisch durchführbar sein (gegebenenfalls mit Benutzer-Interaktion)
•
austauschbare und “semantisch” integrierbare Objekte
sollen selbstbeschreibend sein
bezüglich “Benutzer-Ontologie” für erkundende Navigation durch Benutzer und
bezüglich syntaktischer Typen (Domänen) für syntaktische Analyse durch System
•
Objekte sollen mit wenigen, elementaren Konstrukten gebildet werden,
die (möglichst) “universell” sind
(bezüglich aller bei beteiligten Agenten eingesetzten Konstrukte)
•
im Übrigen: möglichst viele “schöne Seiten” von Datenmodellen für strukturierte
Daten (insbesondere des relationalen Datenmodells) sollen erhalten bleiben
Anfragen
- Schema datenunabhängig anfragbar
- Schema-bezogene Ausdrucksmittel,
ergänzt durch Konstantenzeichen
- Navigation in
bekannter statischer
(Hypergraph-)Schemastruktur
- schon vor Ausführung optimierbar
17. Juli 2003
einige Anforderungen an Datenmodelle für halb-strukturierte Daten
Schemavereinbarung
-
Informationssysteme: Datenmodelle für halb-strukturierte Daten
- Schemas nur datenabhängig anfragbar
- “Schema-erkundende” Ausdrucksmittel,
ergänzt durch Konstantenzeichen
- “erkundende Navigation” in
erratener oder erfragter dynamischer
Instanzstruktur
- nur während Ausführung optimierbar
17. Juli 2003
295
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
296
Beispiel: OEM (Object Exchange Model)
•
•
Aufbau elementarer OEM-Objekte
Object-ID:
entworfen im Rahmen des Projekts TSIMMIS,
“The Stanford-IBM Manager of Multiple Information Sources”
- Local Object Reference: identifiziert ein Objekt lokal,
z.B. durch Speicheradresse oder lokale OID
Strukturen:
aus elementaren Objekten gebildete,
dreischichtig überlappende,
(im Allgemeinen vorzugsweise) baumartige Geflechte für
- “Benutzer-Ontologie” (“menschliche Semantik”, ... ) zum Navigieren: Label
- syntaktische Analyse für automatische Auswertung:
Type
- atomare Werte oder Referenzen:
Value
- Remote ID:
identifiziert ein Objekt in (entfernter) Informationsquelle
- lexical:
“druckbar”,
von Benutzer in Anfragen “als Einstiegspunkt” verwendbar
- non-lexical:
“nicht druckbar”,
vom System bei Anfrageauswertung
als Belegung von Objektvariablen verwendbar
Object-ID
Label
•
Type
Value
Object-ID
Label
Operationen:
- Erzeugen, Ändern, Entfernen
- Anfragen, durch SQL-ähnliche Syntax bezeichnet
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
297
Value
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
298
17. Juli 2003
300
employee_k
Object-ID
Label
© Joachim Biskup, Universität Dortmund
Type
Type
Angestellter
Value
{component_3,
component_2,
component_1}
SET
component_1
Label:
- Zeichenkette variabler Länge,
- “ontologisch gedeutet” als inhaltliche (Selbst-)Beschreibung
(aber nicht im Vorhinein durch einen Administrator global verbindlich festgelegt),
benutzt zum Navigieren bei Anfragen
Name
STRING
“Meier”
STRING
“GBV/555”
component_2
Type:
- atomic (z.B. STRING, INTEGER, ... ) oder
- SET bzw. LIST
Raum
Value
component_3
- zum atomaren Typ passender Wert variabler Länge oder
- passende Menge bzw. Liste von Object-IDs
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
Bild
17. Juli 2003
299
© Joachim Biskup, Universität Dortmund
BITS
Informationssysteme: Datenmodelle für halb-strukturierte Daten
graphische Veranschaulichung und textuelle Schreibweise
ein Geflecht in textueller Schreibweise
root
is
[ bibliography,
SET,
{doc_1, doc_2, ... , doc_n } ]
doc_1
authors_1
author_1_1
topic_1
call_1
is
is
is
is
is
[ document,
[ author-set,
[ author-last-name,
[ topic,
[ internal-call-no,
SET,
{authors_1, topic_1, call_1 } ]
SET,
{author_1_1} ]
STRING, “Ullman” ]
STRING, “Databases” ]
INTEGER, 25 ]
doc_2
authors_2
author_2_1
author_2_2
author_2_3
topic_2
call-number_2
is
is
is
is
is
is
is
[ document,
[ author-set,
[ author-last-name,
[ author-last-name,
[ author-last-name,
[ topic,
[ dewey-decimal,
SET, {authors_2, topic_2, call-number_2 } ]
SET, {author_2_1, author_2_2, author_2_3} ]
STRING, “Aho” ]
STRING, “Hopcroft” ]
STRING, “Ullman” ]
STRING, “Algorithms” ]
STRING, “BR273” ]
doc_n
authors_n
topic_n
call_n
is
is
is
is
[ document,
[ single-author,
[ topic,
[ fiction-call-no,
SET,
{authors_n, topic_n, call_n } ]
STRING, “Michael Crichton” ]
STRING, “Dinosaurs” ]
INTEGER, 95 ]
employee_k
{component_3,
component_2,
component_1}
SET
Angestellter
component_1
Name
STRING
“Meier”
STRING
“GBV/555”
component_2
Raum
component_3
BITS
Bild
employee_k
component_1
component_2
component_3
© Joachim Biskup, Universität Dortmund
is
[ Angestellter, SET,
is
is
is
[ Name,
[ Raum,
[ Bild,
{component_1, component_2, component_3 }]
...
STRING, “Meier”
]
STRING, “GBV/555” ]
BITS,
]
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
301
baumartige Geflechte für
Typen:
Adressen/Referenzen mit Werten:
bibliography
SET
root
© Joachim Biskup, Universität Dortmund
SET
SET
STRING
STRING
INTEGER
SET
SET
STRING
STRING
STRING
STRING
STRING
...
SET
STRING
STRING
INTEGER
Informationssysteme: Datenmodelle für halb-strukturierte Daten
doc_1
authors_1
author_1_1
topic_1
call_1
doc_2
authors_2
author_2_1
author_2_2
author_2_3
topic_2
call-number_2
...
doc_n
authors_n
topic_n
call_n
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
302
Grundform von OEM-Anfragen: Syntax und beabsichtigte Semantik
Pfade:
document
author-set
author-last-name,
topic
internal-call-no
document
author-set
author-last-name
author-last-name
author-last-name
topic
dewey-decimal
...
document
single-author
topic
fiction-call-no
© Joachim Biskup, Universität Dortmund
SELECT
Fetch-Expression
3) wählt für qualifizierte Objekte jeweils Teilobjekt
und bildet Objekte für Value von Rückgabe-Objekt
(mögliche Erweiterung: Konstruktoren für komplexe, zusammengesetzte OEM-Objekte)
(SET-)Object
FROM
:“Ullman”
:“Databases”
:25
1) alle im VALUE-Teil des (Set-)Objects
aufgeführten Objekte werden betrachtet
(mögliche Erweiterung: Objekt-Objektvariablen-Bindungslisten für kartesische Produkte)
WHERE
:“Aho”
:“Hopcroft”
:“Ullman”
:“Algorithms”
: “BR273”
Condition
2) und jeweils untersucht, ob
sie sich bezüglich Condition qualifizieren;
(Im Wesentlichen: Vergleichs-Prädikate zwischen Pfaden und Konstanten)
mengenorientiertes, zusammengesetztes Rückgabe-Objekt
oid_answer
:“Michael Crichton”
: “Dinosaurs”
: 95
17. Juli 2003
answer
(reserviertes Label)
303
© Joachim Biskup, Universität Dortmund
SET
Informationssysteme: Datenmodelle für halb-strukturierte Daten
{oid_1, ... , oid_n}
(für “qualifizierte Teilobjekte”)
17. Juli 2003
304
Definition von OEM-Pfaden
Syntax in BNF
durch “.” getrennte Folgen von
•
•
•
•
Label-Ausprägungen
“?”
“*”
“OID”
Query
(Zeichenketten, ohne “.”, “?”, “*” und “OID”)
Platzhalter für Label
Platzhalter für Pfad
für Rückgabe von Object-Id(entifier) anstelle von Value,
nur als Pfadabschluss,
wobei Folgenglieder durch Variablen unterschieden werden können
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
305
::=
[ bibliography,
SET,
doc_1
authors_1
author_1_1
topic_1
call_1
is
is
is
is
is
[ document,
[ author-set,
[ author-last-name,
[ topic,
[ internal-call-no,
SET,
{authors_1, topic_1, call_1 } ]
SET,
{author_1_1} ]
STRING, “Ullman” ]
STRING, “Databases” ]
INTEGER, 25 ]
doc_2
authors_2
author_2_1
author_2_2
author_2_3
topic_2
call-number_2
is
is
is
is
is
is
is
[ document,
[ author-set,
[ author-last-name,
[ author-last-name,
[ author-last-name,
[ topic,
[ dewey-decimal,
SET, {authors_2, topic_2, call-number_2 } ]
SET, {author_2_1, author_2_2, author_2_3} ]
STRING, “Aho” ]
STRING, “Hopcroft” ]
STRING, “Ullman” ]
STRING, “Algorithms” ]
STRING, “BR273” ]
doc_n
authors_n
topic_n
call_n
is
is
is
is
[ document,
[ single-author,
[ topic,
[ fiction-call-no,
SET,
{authors_n, topic_n, call_n } ]
STRING, “Michael Crichton” ]
STRING, “Dinosaurs” ]
INTEGER, 95 ]
Path
|
Path.OID
Path
::=
Label
|
Label.Path
Label
::=
string_as_label [ (variable) ]
Object
::=
string_as_lexical_object_identifier
Condition ::=
|
|
|
true
Path
predicate ( Value, ... , Value )
Condition and Condition
Value
Path
::=
© Joachim Biskup, Universität Dortmund
| ? [ (variable) ] | * [ (variable) ]
immer wahr
Pfad muss existieren
Werte müssen Prädikat erfüllen
beide Bedingungen müssen wahr sein
constant
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
306
17. Juli 2003
308
Joker (wildcards) in Pfadausdrücken
“?” kann mit jedem Label belegt werden
(innerhalb einer Anfrage müssen zwei Vorkommen von “?” gleich belegt werden,
sofern nicht durch Variablen ausdrücklich unterschieden), z.B. Anfrage
SELECT
FROM
WHERE
liefert:
17. Juli 2003
bibliography.?.topic
root
bibliography.?.internal-call-no
(für Qualifikation: solch ein Pfad muss vorhanden sein)
object_return
obj_1
is
is
[ answer,
[ topic,
SET,
{obj_1}
]
STRING, “Databases” ]
“*” kann mit jedem nichttrivialen Pfad belegt werden
(innerhalb einer Anfrage müssen zwei Vorkommen von “*” gleich belegt werden,
sofern nicht durch Variablen ausdrücklich unterschieden), z.B. Anfrage
Anfrage
SELECT
bibliography.document.topic
FROM
root
WHERE
bibliography.document.author-set.author-last-name = “Ullman”
(für Qualifikation: es muss Pfad vorhanden und Gleichheitsbedingung erfüllt sein)
liefert zusammengesetztes Rückgabe-Objekt
object_return
is [ answer, SET,
{obj_1, obj_2} ]
obj_1
is [ topic,
STRING, “Databases” ]
obj_2
is [ topic,
STRING, “Algorithms” ]
Informationssysteme: Datenmodelle für halb-strukturierte Daten
|
WHERE Condition
{doc_1, doc_2, ... , doc_n } ]
...
© Joachim Biskup, Universität Dortmund
Object
Fetch-Exp ::=
Beispiel
is
root
Fetch-Exp FROM
SELECT
SELECT
FROM
WHERE
liefert:
307
© Joachim Biskup, Universität Dortmund
*.topic
root
*.internal-call-no
(für Qualifikation: solch ein Pfad muss vorhanden sein)
gleiches Rückgabe-Objekt
Informationssysteme: Datenmodelle für halb-strukturierte Daten
Variablen in Pfadausdrücken
Rückgabe von Objekt-Identifikatoren
unterscheiden mehrfach gewünschte Kanten für Beschreibung von Bäumen, z. B. Anfrage
wird durch Abschluss einer Fetch-Expression durch .OID verlangt, z.B. Anfrage
bibliography.document
root
bibliography.*.author-last-name (author_1) = “Ullman”
SELECT
FROM
WHERE
SELECT
FROM
WHERE
and
bibliography.*.author-last-name (author_2) = “Aho”
(für Qualifikation: solch ein Baum
author-set
author-last-name
liefert Rückgabe-Objekt
object_return
is [ answer, SET,
obj_1
is [ document,
authors_2
is [ author-set,
author_2_1 is [ author-last-name,
author_2_2 is [ author-last-name,
author_2_3 is [ author-last-name,
topic_2
is [ topic,
call-number_2 is [ dewey-decimal,
© Joachim Biskup, Universität Dortmund
(für Qualifikation: solch ein Pfad muss vorhanden sein)
muss vorhanden sein)
bibliography
liefert Rückgabe-Objekt
object_return
author-last-name
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
309
© Joachim Biskup, Universität Dortmund
•
•
Erweiterung einer Teilsprache von SGML (Standard Generalized Markup Language)
•
unter Entwicklung und Standardisierung durch www consortium, W3C:
www.w3.org/XML/
•
derzeit das kommerziell meist benutzte Datenmodell für halb-strukturierte Daten
•
(mindestens) zwei verschiedene Entwicklungslinien für Produkte:
- eigenständige XML-Systeme
- Integration von XML in vorhandene (objekt-relationale) Systeme (z.B. Oracle)
17. Juli 2003
[ answer,
SET,
{doc_2} ]
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
310
Entwicklungslinien für Sprachdefinitionen und Einsatzumgebungen, u.a.:
- DOM, Document Object Model: API für objekt-orientierte Sichten
- SAX, Simple API for XML: ereignisbasierte API mit Rückmeldungen
- namespaces: erlaubt URL-ähnliche Referenzen
-
XSL, Extensible Stylesheet Language: für Transformationen von XML Dokumenten
XPath, XML PathLanguage: einfache Anfragesprache
XPointer, XML Pointer Language: erlaubt erweiterte Navigation mit Referenzen
XLink, XML Linking Language: erlaubt ‘‘symbolische Referenzen’’
XHTML, Extensible HTML: Redefinition von HTML mit Hilfe von XML
- XML Schema: versucht ‘‘schöne Seiten’’ von Schemas (wieder) einzuführen
- RDF, Resource Description Framework:
unterstützt Austauch und ‘‘semantische” Integration zwischen Agenten
•
Informationssysteme: Datenmodelle für halb-strukturierte Daten
is
(doc_2 ist der Objekt-Identifikator des gewählten Teilobjekts
des qualifizierten Objekts)
{obj_1} ]
SET, {authors_2, topic_2, call-number_2 } ]
SET, {author_2_1, author_2_2, author_2_3} ]
STRING, “Aho” ]
STRING, “Hopcroft” ]
STRING, “Ullman” ]
STRING, “Algorithms” ]
STRING, “BR273” ]
Beispiel: XML (Extensible Markup Language)
© Joachim Biskup, Universität Dortmund
bibliography.document.OID
root
*.dewey-decimal
311
- XML Anfragesprachen:
XML-QL,
LOREL (Leightweight Object Repository Language),
XML Query Algebra,
XQuery,
...
...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
312
Beispiel für XML Dokument (ohne Kopf, mit “Einheitstyp”)
Beispiel für Document Type Definition (DTD)
< bibliography >
<document>
<author-last-name>
<topic>
<internal-call-no>
</document>
<document>
<author-last-name>
<author-last-name>
<author-last-name>
<topic>
<dewey-decimal>
</document>
...
<document>
<single-author>
<topic>
<fiction-call-no>
</document>
Ullman
Databases
25
Aho
Hopcroft
Ullman
Algorithms
BR273
(document)*
>
<!ELEMENT document
( (author-last-name)*
(single-author)?
topic
(internal-call-no)?
(dewey-decimal)?
(fiction-call-no)?
)
>
(#PCDATA)
(#PCDATA)
(#PCDATA)
(#PCDATA)
(#PCDATA)
(#PCDATA)
>
>
>
>
>
>
</author-last-name>
</topic>
</internal-call-no>
</author-last-name>
</author-last-name>
</author-last-name>
</topic>
</dewey-decimal>
<!ELEMENT author-last-name
<!ELEMENT single-author
<!ELEMENT topic
<!ELEMENT internal-call-no
<!ELEMENT dewey-decimal
<!ELEMENT fiction-call-no
einige Sprachelemente für DTDs
*:
+:
?:
( ... ) :
( , ... , ) :
#PCDATA :
Michael Crichton </single-author>
Dinosaurs
</topic>
95
</fiction-call-no>
</bibliography >
© Joachim Biskup, Universität Dortmund
<!ELEMENT bibliography
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
313
null oder mehr Vorkommen
ein oder mehr Vorkommen
null oder ein Vorkommen
Reihenfolge-unabhängige “Liste”
(Reihenfolge-abhängige) Liste
“parseable character data” (verschiedene OEM-Typangaben im Beispiel ignoriert)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Datenmodelle für halb-strukturierte Daten
17. Juli 2003
314
17. Juli 2003
316
die Information Retrieval Aufgabe
9 Information Retrieval
9.1 Aufgaben, Anforderungen und Ansätze
Benutzer:
hat jeweils “Informationsbedürfnis”,
System:
verwaltet Dokumente, die “Information enthalten”
Aufgabe:
Benutzer und System versuchen zusammen und gegebenenfalls iterativ,
jeweils genau solche Dokumente zu bestimmen und aufzufinden,
die für das “Informationsbedürfnis” relevant sind
Relevanz: sehr schwieriger Begriff, weil im Allgemeinen
- erst genauer bestimmbar, nachdem Dokument bereits aufgefunden
- nur näherungsweise bestimmbar
- nur (Benutzer-)subjektiv bewertbar
- recht verschiedenartig beschreibbar, z.B.:
im Dokument “enthaltene Information”
- erfüllt
das “Informationsbedürfnis”
- ist ähnlich
dem “Informationsbedürfnis”
- enthält Teil
des “Informationsbedürfnisses”
- ist Instanz (Beispiel) für das “Informationsbedürfnis”
- ist spezieller als
das “Informationsbedürfnis”
- hat geringen Abstand von dem “Informationsbedürfnis”
- ist nicht unabhängig von dem “Informationsbedürfnis”
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
315
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
das Such-Paradox
•
wie kann man etwas finden, von dem man gar nichts weiß?
- was man weiß, braucht man nicht (wieder)zufinden!
- was man nicht weiß, kann man auch nicht (wieder)finden!
•
die Auflösung des Paradoxes für Datenmodelle mit strukturierten Daten:
Fundierung mit Hilfe von Metaschema und Schemas:
Ostereiersuchen im Wald
•
•
•
•
- “Verstecken” (Speichern) und Suche
finden auf der gemeinsamen Grundlage einer vorausgehenden Verständigung statt,
nämlich einem formalen Schema
und der zugrunde liegenden Modellierung mit Hilfe einer Ontologie:
Speicherer: “versteckt” Konstantenzeichen unter bekanntem Schema
Anfrager: sucht Konstantenzeichen unter bekanntem Schema
•
•
•
•
•
- wenn man das Schema weiß,
kann man die (bislang unbekannten) “versteckten” Konstantenzeichen finden
welche Fundierung ohne Schema kann man für Information Retrieval finden?
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
317
die Stecknadeln im Heuhaufen
•
Stecknadeln und Heu(fasern) sind verschieden
•
fast alles ist Heu
vollständiges Suchen ist zu aufwändig,
Laufzeitkomplexität linear in #(Heu),
statt logarithmisch in #(Heu) oder linear in #(Stecknadel)
•
Obermengen von Stecknadeln und Heu
sind trennbar aufgrund von “äußeren Merkmalen”, z.B.:
- Magnetismus: zieht alles (magnetisch) Metallene aus Nichtmetallischem heraus,
also auch Stecknadeln aus Heu
Iteration
318
“Ähnlichkeit”,...
System
...
Relevanz
Doc_n
Formalisierung
Retrieval-Anfrage
bezüglich
(äußerer) Merkmale
Algorithmisierung:
vernichtet zumindest das Heu,
lässt auch Stecknadeln übrig
Abstraktion
der “enthaltenen Information”
Dokument-Merkmal-Strukturen,
Suchhilfen,
...
Qualitätsbeurteilung:
Übereinstimmung zwischen
einerseits dem Gesuchten:
andererseits dem Gefundenen:
einfachere Restaufgabe: iterierte Suche in nunmehr getrennter Obermenge
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
Doc_1
Doc_1
“Informationsbedürfnis”
Anforderung:
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
Benutzer
zufälliges Suchen ist zwecklos,
Erfolgswahrscheinlichkeit zu gering: #(Stecknadeln) / #(Heu)
- Feuer:
© Joachim Biskup, Universität Dortmund
eine einfache Modellierung von Information Retrieval
•
•
•
•
- wenn man das Metaschema weiß,
kann man das (bislang unbekannte) Schema finden
•
•
(auch unbekannte) Ostereier sind erkennbar verschieden
von allen anderen Dingen im Wald (so viel weiß schon jedes Kind)
Ostereier “verraten sich” durch äußere Merkmale wie bunte Farben
Ostereier sind selten (fast alles im Wald ist kein Osterei)
Ostereier sind tatsächlich vorhanden (hoffentlich jedenfalls, so dass die Suche lohnt)
irgendwo muss man anfangen zu suchen (notfalls zufällig anfangen)
wo man ein Osterei findet, könnten nahe bei auch noch mehr Ostereier sein
auch bei schneller grober Suche kann man schon einmal ein Osterei finden
um alle Ostereier zu finden, muss man den gesamten Wald durchsuchen
wenn man genug Ostereier hat, kann man auch vorzeitig aufhören
die Eltern können auch Hinweise geben, etwa “heiß” und “kalt”
Kinder können die “Versteckmethoden” der Eltern lernen
...
17. Juli 2003
319
© Joachim Biskup, Universität Dortmund
Relevanz enthaltener Information für Informationsbedürfnis
“Ähnlichkeit’’ der Merkmale mit Anfrage
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
320
Qualitätsbeurteilung bezüglich (im Allgemeinen fiktiver) Relevanz
falls
ALL
=
Menge aller Dokumente
REL
=
GEF
=
Menge der für Informationsbedürfnis relevanten Dokumente, “zu liefern”
(im Allgemeinen nicht tatsächlich bestimmbar)
Menge der für Retrieval-Anfrage als ähnlich gefundenen Dokumente, “geliefert”
(von Benutzer nachträglich “beurteilbar” bezüglich Relevanz)
dann
GEF ∩ REL
= “gut geliefert”
: gefunden und relevant
GEF \ REL = “zu viel geliefert” : gefunden, aber nicht relevant
REL \ GEF = “zu wenig geliefert” : relevant, aber nicht gefunden
(Benutzer-beurteilbar)
(Benutzer-beurteilbar)
(nicht bestimmbar)
falls
ALL
REL
GEF
“gut”
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
321
Recall-Precision-Paare
Precision
REL ∩ GEF
p = ---------------------------------GEF
Verhältnis von “gut”
zu “geliefert”
Recall
REL ∩ GEF
r = ---------------------------------REL
Verhältnis von “gut”
zu “zu liefern”
versus
“geliefert”
(Benutzer-beurteilbar)
Recall
GEF ∩ REL
r = ---------------------------------- : “gut”
REL
versus
“zu liefern”
(nicht bestimmbar)
Fallout
GEF – REL
f = -------------------------------- : “zu viel” versus “nicht zu liefern”
ALL – REL
bester Fall, jedes gefundene Dokument ist relevant:
- gefunden enthält stets nur relevante Dokumente, also stets:
Precision = 1
- gefunden enthält anfänglich kein Dokument, also anfänglich: Recall
=0
- gefunden enthält schließlich genau die relevanten Dokumente, also schließlich:
Recall
=1
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
322
- kurzer Präfix enthält “eher vorwiegend relevante” Dokumente, aber noch nicht alle relevanten:
Precision “eher hoch”, aber mit Länge des Präfixes abnehmend,
Recall “eher niedrig”, aber mit Länge des Präfixes zunehmend
continue := true;
i := select_a_first_object;
gefunden := {};
while continue do
if query matches doc[i] then insert(doc[i], gefunden);
i := select_another_object;
continue := evaluate_achievements(gefunden, i, ... )
od.
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
GEF ∩ REL
Precision p = ---------------------------------- : “gut”
GEF
häufig tatsächlich vorliegender Fall:
gefundene Dokumente werden vom System mit einem Rang bewertet und
gemäß der Bewertung absteigend sortiert ausgegeben;
gefundene Dokumente mit hohem Rang “sind eher relevant”,
gefundene Dokumente mit niedrigem Rang “sind eher nicht relevant”;
es wird nur ein Präfix (Anfangsstück der gesamten sortierten Ausgabe) tatsächlich gezeigt
einfaches Muster für Suchverfahren:
© Joachim Biskup, Universität Dortmund
(Benutzer-beurteilbar)
(Benutzer-beurteilbar)
(nicht bestimmbar)
auch Precision allenfalls empirisch, Benutzer-abhängig und näherungsweise beurteilbar:
“Relevanz” ist nur fiktiv definiert als die
gewünschte, aber tatsächlich nicht vollständig bekannte Beziehung
REL: zu finden
© Joachim Biskup, Universität Dortmund
= “gut geliefert”
: gefunden und relevant
= “zu viel geliefert” : gefunden, aber nicht relevant
= “zu wenig geliefert” : relevant, aber nicht gefunden
wichtige Verhältnisse:
“zu viel”
“zu
wenig”
Menge aller Dokumente
Menge der für Informationsbedürfnis relevanten Dokumente, “zu liefern”
Menge der für Retrieval-Anfrage als ähnlich gefundenen Dokumente, “geliefert”
dann
GEF ∩ REL
GEF \ REL
REL \ GEF
GEF: gefunden
ALL
=
=
=
- langer Präfix enthält “eher auch nicht relevante” Dokumente, aber insgesamt mehr relevante:
Precision “eher niedrig”
Recall “eher hoch”
dann Wechselwirkungen zwischen Benutzer-Interessen und Benutzer-Aufwand:
•
Benutzer-Interesse: möglichst viele (alle) relevante(n) Dokumente
widerstreitender Benutzer-Aufwand:
viele nicht relevante Dokumente “per Hand herausfinden”
(100%)
(0%)
(100%)
17. Juli 2003
323
•
Benutzer-Interesse: möglichst ausschließlich relevante Dokumente
widerstreitender Benutzer-Aufwand:
Erschwernis bei der Aufgabe, die dem “Informationsbedürfnis” zugrunde liegt
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
324
Beispiel für Recall-Precision Paare bei Rang-sortierter Ausgabe
x = relevant
(für REL = 5 )
Recall
Precision
GEF ∩ REL
GEF ∩ REL
---------------------------------REL
GEF ∩ REL
---------------------------------GEF
x
1
0.2
1.00
x
2
0.4
1.00
2
0.4
0.67
3
0.6
0.75
3
0.6
0.60
4
0.8
0.67
7
4
0.8
0.57
8
4
0.8
0.50
Dokumentnummer
GEF
588
1
589
2
576
3
590
4
986
5
592
6
984
988
“gut”
x
x
578
9
4
0.8
0.44
985
10
4
0.8
0.40
103
11
4
0.8
0.36
591
12
4
0.8
0.33
772
13
5
1.0
0.38
990
14
5
1.0
0.36
© Joachim Biskup, Universität Dortmund
x
Informationssysteme: Information Retrieval - Aufgaben, Anforderungen und Ansätze
17. Juli 2003
9.2 einige grundlegende Techniken
325
Merkmale
•
•
Abstraktion der in einem Dokument “enthaltenen” Information:
Menge von Merkmalen
•
Extraktion von Merkmalen:
- “per Hand” oder (ansatzweise) automatisch
- “auf Vorrat” (bei Speicherung oder nachträglich)
oder auch erst “bei Bedarf” (bei Anfragen)
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
326
Retrieval-Anfragen:
Syntax: Boolesche Kombination von (normalisierten) Merkmalen
Beispiel:
Dokument
Merkmale (Schlagworte)
1
2
3
Schema, halb-strukturiert, navigieren
Schema, relational, Algebra, Kalkül, SQL, anfragen
relational, anfragen
Anfrage
Schema
Schema and relational
relational and ( SQL or anfragen )
relational and (not SQL )
Schema or relational or SQL
Normalisierung von Merkmalen:
Beispiele: - grammatische Grundform
- Skalierung bezüglich eines “Einheitsmaßes”
- Transposition in “Einheitstonleiter”
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - einige grundlegende Techniken
Semantik als “Ähnlichkeit” zwischen Anfrage und abstrahierten Dokumenten:
- Erfüllung (Wahrheit)
der Merkmalskombination aus Retrieval-Anfrage
bezüglich der extrahierten Merkmalsmenge eines Dokuments
- alle in diesem Sinne ähnlichen Dokumente werden geliefert
Beispiele: - Schlagworte (key words)
- geometrische Muster (für Bild-Dokumente)
- “Melodie-Themen” (für Musik-Dokumente)
- “Icons” (für Multimedia-Dokumente)
- ...
•
© Joachim Biskup, Universität Dortmund
17. Juli 2003
327
© Joachim Biskup, Universität Dortmund
Rückgabe-Dokumente
1, 2
2
2, 3
3
1, 2, 3
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
328
•
Bewertung mit Rängen:
Berechnung eines “Grades der Erfüllung”
•
für jedes mögliche oder vorkommende einzelne Merkmal
wird die Menge (Liste) der erfüllenden Dokumente unterhalten
Beispiel: Anzahl der erfüllten Disjunkte in Boolesch-normalisierter Anfrage
Beispiel mit Mengen:
Dokument
Merkmale (Schlagworte)
1
2
3
Schema, halbstrukturiert, navigieren
Schema, relational, Algebra, Kalkül, SQL, anfragen
relational, anfragen
normalisierte Anfrage
1
2
3
Schema
Schema and relational
(relational and SQL) or (relational and anfragen )
relational and (not SQL )
Schema or relational or SQL
1
0
0
0
1
1
1
2
0
3
0
0
1
1
1
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
Algebra
anfragen
halb-strukturiert
Kalkül
navigieren
relational
Schema
SQL
329
Auswertung:
and
( SQL
or
anfragen
set(relational) ∩set ( set(SQL) ∪set set(anfragen)
= {2, 3}
∩set ( {2}
∪set {2, 3}
= {2, 3}
© Joachim Biskup, Universität Dortmund
relational
Auswertung:
bit(relational) ∩bit ( bit(SQL) ∪bit bit(anfragen)
0
= 1
1
and
( SQL
∩bit (
0
1
0
or
∪bit
anfragen
0
1
1
•
)
)
)
Hauptklassen:
A.
B.
C.
D.
E.
F.
G.
H.
I.
J.
K.
Unter-Unterklassen:, z.B.:
H.3
H.3.0
H.3.1
H.3.2
H.3.3
H.3.4
H.3.5
H.3.6
H.3.m
)
)
)
aus Effizienzgründen: Komprimierung der (im Allgemeinen “dünnen”) Bitlisten
Informationssysteme: Information Retrieval - einige grundlegende Techniken
Dok_2
1
1
0
1
0
1
1
1
Dok_3
0
1
0
0
0
1
0
0
17. Juli 2003
330
besondere Merkmale: inhaltlich zusammengehörige, hierarchische Klassen
auffassbar als Teil einer anwendungsbezogenen Ontologie,
Beispiel: ACM Computing Reviews Classification:
0
= 1
1
© Joachim Biskup, Universität Dortmund
Dok_1
0
0
1
0
1
0
1
0
Informationssysteme: Information Retrieval - einige grundlegende Techniken
Beispiel mit Merkmals-Bitlisten:komponenten-weise ausgeführte Bit-Operationen
Anfrage:
2
2, 3
1
2
1
2,3
1, 2
2
hierarchische Klassifikation
Beispiel mit Mengen: Mengenoperationen
relational
Algebra
anfragen
halb-strukturiert
Kalkül
navigieren
relational
Schema
SQL
Beispiel mit Merkmals-Bitlisten:
Auswertung von Retrieval-Anfragen effizient implementieren
durch Operationen auf der Dokument-Merkmal-(Zugriffs)Struktur
Anfrage:
Invertierung
Dokument-Merkmal-(Zugriffs)Struktur:
17. Juli 2003
331
© Joachim Biskup, Universität Dortmund
General Literature
Hardware
Computer Systems Organization
Software
Data
Theory of Computation
Mathematics of Computing
Information Systems
Computing Methodologies
Computing Applications
Computing Milieux
Information Storage and Retrieval
General
Content Analysis and Indexing
Information Storage
Information Search and Retrieval
System and Software
Online Information Systems
Library Automation
Miscellaneous
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
332
•
Extraktion:
als Klassifikation, meistens “per Hand”
•
Normalisierung:
vermöge vorgegebener Klassenbezeichner
•
Retrieval-Anfragen:
wie allgemein bei Merkmalen,
mit Berücksichtigung (Expansion) der Hierarchie
flaches Clustering
•
besondere Merkmale:
mutmaßlich inhaltlich zusammengehörige, disjunkte Klassen
Beispiel: Clustering gemäß Verweisstrukturen von Web-Seiten
•
Invertierung:
wie allgemein bei Merkmalen,
mit Berücksichtigung (Expansion) der Hierarchie
•
Dokumente:
Web-Seiten
Verweisstruktur:
Web-Seite A enthält (textuell) einen Verweis (als URL) auf Web-Seite B
Beobachtungen:
- manche Web-Seiten liegen im Zentrum vieler Verweise
- manche Web-Seiten verweisen wechselseitig aufeinander
Annahme:
- Verweise deuten daraufhin,
dass enthaltene “Informationsgehalte zusammengehörig” sind,
so dass betroffene Web-Seiten als “ähnlich” behandelt werden können
algorithmische Clusterbildung, z.B. mit folgender Heuristik:
- fasse Web-Seiten eines vollständigen Unter-Verweisgraphen zu einem Cluster zusammen
- falls eine Web-Seite ausschließlich in genau ein Cluster verweist,
so füge sie diesem Cluster hinzu
- ...
•
Retrieval-Anfragen: liefern mit einer (auf andere Weise) gefundenen Web-Seite
(ggf. erst auf Anforderung) auch die anderen Web-Seiten des Clusters
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
333
Thesaurus
•
•
© Joachim Biskup, Universität Dortmund
•
17. Juli 2003
334
terminologische Kontrolle der Benennungen durch
- linguistische Normalisierung
(Beispiel: grammatische Grundform, Gleichsetzung von Verb und Substantiv, ... )
eine geordnete Zusammenstellung von Begriffen
mit ihren natürlichsprachlichen Benennungen
- Erfasung von Synonymen
(syntaktisch verschiedene Benennungen für semantisch gleiche Konzepte,
Schreibweisenvarianten, unterschiedliche Sprachstile, ... )
auffassbar als operationalisierter Ausschnitt
des “semiotischen Dreiecks” Wirklichkeit-Begriffsraum-Sprache
als Teil einer anwendungsbezogenen Ontologie:
- Kennzeichnung von Homonymen und Polysemen
(syntaktisch gleiche Benennungen für semantisch verschiedene Konzepte,
bei Homonymen: von Betonung beim Sprechen abhängig)
Wirklichkeit:
- Festlegung von Vorzugsbenennungen (Deskriptoren)
aus einfachen Elementen wohlstrukturiert
zusammengesetzte Erscheinungen
•
bedeuten
Informationssysteme: Information Retrieval - einige grundlegende Techniken
vertreten
Darstellung von Beziehungen zwischen Begriffen
(bereits unabhängig von Benennungen, im Hinblick auf vertretene Wirklichkeit)
- Oberbegriff-Unterbegriff
Sprache:
benennen
Ausdrücke und Sätze
Raum der Begriffe und
Gesetze der Logik
- hierarchische Klassifikation
- “Ähnlichkeit”
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
335
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
336
•
strukturierte Darstellung eines Thesaurus
z.B. als (relationale oder objekt-orientierte) Formalisierung
folgender grober Modellierung (durch ein ER-Diagramm):
BegriffsID
Vorzugsbenennung
Begriff
•
Klasse
Instanz_von
Unterbegriff
Begriffshierarchie
VerwaltungsInfo
Definitionstext
(Deskriptor)
Oberbegriff
9.3 Modelle für Information Retrieval
Oberklasse
Benennung
Synonym
Ausdruck
Unterklasse
Klassenhierarchie
Zugriffsstrukturen für Thesaurus, z.B.:
- Index für alphabetischen Zugriff zu Ausdrücken (oder Vorzugsbenennungen)
- Liste für Klassen-systematischen Zugriff zu Vorzugsbenennungen
- KWIC (keyword in context) als Index für kontextbezogenen Zugriff zu Vorzugsbenennungen
- ...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - einige grundlegende Techniken
17. Juli 2003
337
© Joachim Biskup, Universität Dortmund
Modelle mit Merkmals-Vektoren
zugrunde liegende Abstraktion
- mehrdimensionale (heterogene) Vektoren mit Merkmalen (oder Merkmalsmengen)
- Abstandsmaß zwischen Vektoren
•
Dokument-Abstraktion:
Zuordnung von Dokumenten (Objekten) zu Vektoren,
Dokument-Vektoren bilden (im Allgemeinen dünne) Teilmenge des Gesamtraums
•
Informationsbedürfnis-Formalisierung:
Bildung eines Vektors
•
338
Relevanz als (fiktive) Wahrscheinlichkeit:
bei gegebener Anfrage q: jedem Dokument d wird zugeordnet die (fiktive) Wahrscheinlichkeit
Prob(Rq,d) seiner Relevanz für das durch q formalisierte Informationsbedürfnis
•
•
17. Juli 2003
ein (stark vereinfachtes) wahrscheinlichkeitstheoretisches Modell
•
•
Informationssysteme: Information Retrieval - Modelle für Information Retrieval
Entscheidungssituation für ein einzelnes Dokument:
Fall 1: Dokument relevant
Fall 2: Dokument relevant
Fall 3: Dokument nicht relevant
Fall 4: Dokument nicht relevant
•
grundlegende Anfragetypen:
- bestimme “nächsten Nachbarn”
(des Anfrage-Vektors unter vorkommenden Dokument-Vektoren)
und
und
und
und
Dokument geliefert
Dokument nicht geliefert
Dokument geliefert
Dokument nicht geliefert
:
:
:
:
“gut”
Verlust lzuwenig
Verlust lzuviel
richtig
Minimierung des Verlusts bei Entscheidung über Lieferung:
Fall 1+3:
Dokument d liefern bringt erwarteten Verlust:
( 1 – Prob ( R q ,d ) ) ⋅ l zuviel
Fall 2+4:
Dokument d nicht liefern bringt erwarteten Verlust:
Prob ( R q ,d ) ⋅ l zuwenig
also:
Dokument d liefern
gdw
Prob ( R q ,d ) ⋅ l zuwenig > ( 1 – Prob ( R q ,d ) ) ⋅ l zuviel
- bestimme “δ-Umgebung”
(des Anfrage-Vektors bezüglich vorkommender Dokument-Vektoren)
gdw
mehrdimensionale Such-(Zugriffs-)Strukturen für “Regionen”
- (approximative) Suche auf erfolgversprechende Regionen begrenzen
l zuviel
Prob ( R q ,d )
------------------------------------- > -----------------1 – Prob ( R q ,d ) l zuwenig
gdw
l zuviel
Prob ( R q ,d ) > --------------------------------------l zuviel + l zuwenig
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Modelle für Information Retrieval
17. Juli 2003
339
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Modelle für Information Retrieval
17. Juli 2003
340
•
Retrieval-Antwort für q:
alle Dokumente d mit
l zuviel
Prob ( R q ,d ) > --------------------------------------l zuviel + l zuwenig
nach Wahrscheinlichkeiten absteigend sortiert
•
Teil IV
Schätzung der fiktiven Wahrscheinlichkeiten:
“unbekanntes” event:
Relevanz eines Dokuments d
“beobachtbare” condition: Vorkommen eines Merkmals x
(im Allgemeinen zusammengesetzt)
Effizienz (in relationalen Systemen)
dann ersetzen:
statt
“Relevanz eines Dokuments d’’, d.h. Prob(Rq,d)
einfacher “Relevanz eines Dokuments mit beobachtbarem Merkmal x’’: Prob(Rq,x)
empirisch anhand von Stichproben näherungsweise bestimmen:
•
Prob(Rq,x)
ersatzweise: anstelle von Prob(Rq,d) andere von x abhängige Parameter schätzen
- man verwendet typischerweise den Satz von Bayes:
Prob ( event condition ) ⋅ Prob ( condition ) = Prob ( condition event ) ⋅ Prob ( event )
- man sichert Invarianz der Rangordnung
© Joachim Biskup, Universität Dortmund
Informationssysteme: Information Retrieval - Modelle für Information Retrieval
17. Juli 2003
341
© Joachim Biskup, Universität Dortmund
Informationssysteme
17. Juli 2003
342
Verwirklichung der grundlegenden relationalen Operationen
Entwurfsumgebung
10 Zugriffsstrukturen und Verbund-Algorithmen
Arbeitsplatz- . . .
umgebung
Netzumgebung
Programmier- . . .
umgebung
Vereinbarungen
10.1 Anforderungen an die interne Schicht
..
.
Sicht i
Schema
Datenmanipulationssprache (DML)
Änderungen
Sprachanalyse
EinsatzSchnittstellen
eingebettet
interaktiv, selbständig
Datendefinitionssprache (DDL)
...
Anfragen
Antworten
Erklärungen
InformationssystemSchnittstelle
..
.
konzeptionelles
Schema
internes Schema
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
große Mengen von Daten
dauerhaft und
Aufbereitung
von
Antworten
Relationen (Klassen),
Tupel (Objekte)
verlangt geeignete
Datenstrukturen und Algorithmen,
um insbesondere:
Transaktionsverwaltung
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
MengenSchnittstelle
effizient zu verwalten, d.h.
Anfragen und Änderungen zu bearbeiten
TupelSchnittstelle
interne Schicht
(Datensatz-orientiert)
(virtueller) flüchtiger und dauerhafter Speicher
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
SpeicherSchnittstelle
GeräteSchnittstelle
...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Anforderungen an die interne Schicht
17. Juli 2003
343
© Joachim Biskup, Universität Dortmund
Speichergeräte
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Anforderungen an die interne Schicht
17. Juli 2003
344
Dauerhaftigkeit
Bestimmung von Adressen aus Tupelidentifikatoren
ein Tupel kann auf drei Weisen identifiziert werden:
• aus der Sicht des Benutzers durch seine Schlüsselwerte
• auf der Ebene der Speichermedien durch seine Adresse
• auf der Ebene des Datenbanksystems durch einen Tupelidentifikator, TID
r
Übersetzungstabelle für
Relation mit Nummer r :
Blocknummer
1
2
.
.
.
n
.
.
.
.
.
.
b
.
.
.
b
. . .
Block mit Nummer b, im
allgemeinen auf
Magnetplattenspeicher :
bei benutzergesteuerten Änderungen der Schlüsselwerte
bei Verlagerungen innerhalb der Speichermedien
zwischen zwei Sitzungen eines Benutzers
bei Systemzusammenbrüchen
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Anforderungen an die interne Schicht
n
r
während der Lebensdauer eines Tupels, d.h.
von der benutzergesteuerten Eingabe bis zum benutzergesteuerten Entfernen,
bleibt ein Tupelidentifikator stets invariant und dauerhaft, insbesondere also:
© Joachim Biskup, Universität Dortmund
Relationennummer
Tupelidentifikator :
ein Tupelidentifikator wird bei der erstmaligen Eingabe eines Tupels erzeugt:
• automatisch durch das System
• im Allgemeinen für den Benutzer unsichtbar
• systemweit eindeutig
• über die Zeit unveränderbar
• mit dem eigentlichen Tupel stets “verbunden”
•
•
•
•
(fortlaufende)
Tupelnummer
17. Juli 2003
345
© Joachim Biskup, Universität Dortmund
. . .
Verwaltungsteil
a
Tupelwerte
Informationsteil
( n, r ) : a
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Anforderungen an die interne Schicht
17. Juli 2003
346
17. Juli 2003
348
Effizienz für Anfragen und Änderungen
stark abhängig von der effizienten Umrechnung der drei Identifikationsgrößen eines Tupels:
- benutzersichtbare Schlüsselwerte
- Tupelidentifikator
- Speicheradresse
10.2 Zugriffsstrukturen zur Steigerung der Effizienz
genauer: abhängig vom Aufwand der folgenden Operationen der internen Schicht:
•
schlüsselbezogenes Suchen
Umwandlung “benutzersichtbare Schlüsselwerte |→ Tupelidentifikator (Speicheradresse)”
•
physisches Suchen und Transport
Umwandlung “Tupelidentifikator |→ Speicheradresse”,
mitsamt gegebenenfalls Transport des Tupels vom Hintergrundspeicher in den Hauptspeicher
•
inhaltsbezogenes Suchen
Bestimmung “(benutzersichtbare) Attributwerte |→ Tupelidentifikator (Speicheradresse)”,
um Tupel bzw. Folgen (insbesondere Paare) von Tupeln aufzufinden
auf Grund elementarer Eigenschaften ihrer Werte
(Gleichheit oder Ungleichheit oder gegebenenfalls auch Größenvergleich),
etwa für die A=c-Selektion bzw. für den natürlichen Verbund
•
Relationendurchlauf
systematischer vollständiger Durchlauf einer Relation
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Anforderungen an die interne Schicht
17. Juli 2003
347
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
Zugriffsstrukturen
B*-Baum als Index
Verwendung: - Index für schlüsselbezogenes Suchen
- sequentielle Liste für einen systematischen Durchlauf der TIDs einer Relation
• Ziele: Effizienzanforderungen erfüllen beim
schlüsselbezogenen und inhaltsbezogenen Suchen sowie beim Relationendurchlauf
Voraussetzung: auf der Domäne der Schlüsselwerte ist eine lineare Ordnung definiert
• Ansatz: neben den eigentlichen Relationen mit ihren Tupeln (primäre Information)
speichert man auch Hinweise zum Auffinden dieser Tupel (sekundäre Information)
Eigenschaften:
• teil-ausgeglichener, geordneter Baum, dessen Blätter alle die gleiche Höhe besitzen
• ein Blattknoten enthält eine geordnete Folge von Paaren
< (benutzersichtbarer) Schlüsselwert, TID >
• zusätzlich werden die Blattknoten untereinander doppelt verkettet
• durchläuft man alle Blätter von links nach rechts,
so erhält man die sortierte Folge (ohne Wiederholung)
aller (derzeit) vorhandenen Schlüsselwerte
• ein Elternknoten enthält eine geordnete Folge der Art
Verweis auf Kind, Schlüsselwert, Verweis auf Kind, ... , Schlüsselwert, Verweis auf Kind
• durchläuft man alle Knoten in inorder-ähnlicher Weise,
so erhält man eine sortierte Folge (mit Wiederholung)
aller (derzeit) vorhandenen Schlüsselwerte
• der Baum wächst von den Blättern zur Wurzel,
indem ein voller Knoten geteilt wird und
die entsprechenden Verweise im Elternknoten eingetragen werden
• die Größe eines Knotens ist im Allgemeinen die
für den Hintergrundspeicher verwendete Blockgröße
• Wechselwirkungen:
- entstehende Redundanz vergrößert den Speicheraufwand,
- verringert im Mittel erheblich den Zeitaufwand für Anfragen
- der Zeitaufwand für das Einfügen erhöht sich, aber
der Zeitaufwand für das Entfernen verringert sich
gängige Zugriffsstrukturen:
• sequentielle Listen, etwa durch Felder oder Verkettungen verwirklicht,
zur Unterstützung von Relationendurchläufen
• Indexe,
etwa als B*-Bäume oder durch Hash-Verfahren verwirklicht,
zur Unterstützung des Suchens in einer Relation
• Links,
zur Unterstützung des gleichzeitigen Suchens in mehreren Relationen
• Hashfunktionen,
zur verkleinernden Filterung einer Relation im Hinblick auf eine andere
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
17. Juli 2003
349
Beispiel für einen B*-Baum
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
mitglied
Name
Ort und gegebenenfalls weitere Attribute
interne Relationennummer:
fortlaufende Tupelnummern:
Knotengröße:
2
dezimal dreistellig
höchstens 7 Einträge (Attributwert, TID oder Verweis)
Reihenfolge der Tupeleingaben:
a.
b.
c.
d.
e.
f.
g.
a. Einfügung [meier, dortmund]:
b. Einfügung [müller, bochum]:
dort(mund)
boch(um)
bonn
aach(en)
dort(mund)
dort(mund)
duis(burg)
<bau,0072>, <bil,0052>, <bre,0062>
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
<mei,0012>, <mül,0022>
<mei,0012>, <mül,0022>, <sch,0032>
d. Einfügung [esser, aachen]:
mei
<ess,0042>, <mei,0012>
mei
<ess,0042>, <mei,0012>
350
<mei,0012>
c. Einfügung [schmidt, bonn]:
sich ergebender B*-Baum:
bre
17. Juli 2003
schrittweiser Aufbau des Beispiels, Einfügungen a-e
Relation:
Schlüsselattribut:
Eigenschaftsattribut:
meier
müller
schmidt
esser
biller
brenner
bauer
© Joachim Biskup, Universität Dortmund
e. Einfügung [biller, dortmund]:
<mül,0022>, <sch,0032>
17. Juli 2003
351
mei
<bil,0052>, <ess,0042>, <mei,0012>
© Joachim Biskup, Universität Dortmund
<mül,0022>, <sch,0032>
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
<mül,0022>, <sch,0032>
17. Juli 2003
352
schrittweiser Aufbau des Beispiels, Einfügungen f-g
Index bezüglich eines Nichtschlüsselattributs
zur Unterstützung inhaltsbezogener Suche
als B*-Baum mit
Blattknoten der Form:
< (benutzersichtbarer) Attributwert, Folge von TIDs >
Beispiel für das Nichtschlüsselattribut Ort
•
mei
•
<bil,0052>, <ess,0042>, <mei,0012>
<mül,0022>, <sch,0032>
•
e.
f. Einfügung [brenner, dortmund]:
a.
bre
boch
<dort,0012>
mei
<aach,0042>,<boch,0022>
b.
<bil,0052>, <bre,0062>
<ess,0042>, <mei,0012>
<bonn,0032>,<dort,0012,0052>
<boch,0022>,<dort,0012>
f.
<mül,0022>, <sch,0032>
boch
c.
<boch,0022>,<bonn,0032>,<dort,0012>
<aach,0042>,<boch,0022>
g. Einfügung [bauer, duisburg]:
bre
g.
boch
d
mei
boch
<aach,0042>,<boch,0022>
© Joachim Biskup, Universität Dortmund
<ess,0042>, <mei,0012>
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
<bonn,0032>,<dort,0012,0052,0062>
<duis,0072>
<mül,0022>, <sch,0032>
17. Juli 2003
353
Links
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
17. Juli 2003
354
Beispiel: gemeinsamer B*-Baum für mitglied und entfernung
•
für zwei (oder auch mehr) Relationen jeweils
einen gemeinsamen Index bezüglich der gleichen Domäne (Attribut) bereitstellen
•
B*-Bäume mit Einträgen in die Blattknoten folgender Art:
< (benutzersichtbarer) Attributwert;
Folge von TIDs für erste Relation;
Folge von TIDs für zweite Relation >
•
dort
<bonn,0032>,<dort,0012>
<aach,0042>,<boch,0022>
<bau,0072>, <bil,0052>, <bre,0062>
<bonn,0032>,<dort,0012,0052,0062>
erste Relation:
Schlüsselattribut:
Eigenschaftsattribut:
Instanz:
mitglied
Name
Ort und gegebenenfalls weitere Attribute
wie oben
zweite Relation:
Schlüsselattribut:
Eigenschaftsattribut:
Instanz:
entfernung
Ort
Weglänge (von Hildesheim)
h.
dort
235
i.
boch
250
j.
bonn
366
k.
aach
398
l.
duis
287
manchmal auch sinnvoll:
in die Blätter die Tupel als Ganzes eintragen (anstelle von TIDs)
m.
düss
308
Einträge in Blattknoten des gemeinsamen B*-Baumes (Indexes):
< Stadtname;
Folge von TIDs für mitglied;
km-Angabe für entfernung >
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
17. Juli 2003
355
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
17. Juli 2003
356
boch
bonn
<aach;0042;398>,<boch;0022;250>
<bonn;0032;366>
dort
<duis;0072;287>,<düss; ;308>
10.3 Verbund-Algorithmen
<dort;0012,0052,0062;235>
dieser Baum verwirklicht:
• eine sequentielle Liste für die Tupel der Relation entfernung, sortiert nach dem Stadtnamen
• eine sequentielle Liste für die TIDs der Relation mitglied, sortiert nach dem Stadtnamen
• einen Index für die Relation entfernung bezüglich des Stadtnamens
• einen Index für die Relation mitglied bezüglich des Stadtnamens
• einen Link für die beiden Relationen entfernung und mitglied
bezüglich des Stadtnamens
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Zugriffsstrukturen zur Steigerung der Effizienz
17. Juli 2003
357
© Joachim Biskup, Universität Dortmund
Verbund: Definition und Nested-Loop (Wiederholung)
•
Definition
s = { µ | µ : dom r ∪ dom s → C, und
r
s = { µ | es gibt α ∈ r, β ∈ s : α(A) = β(A) für alle A ∈ dom r ∩ dom s; µ = α ∪ β }
µ dom r ∈ r und µ dom s ∈ s }
•
NestedLoop abstrakt
PROCEDURE NestedLoopJoin(r, s : Relation) : Relation;
VAR ergebnis
: Relation;
α, β
: Tupel;
BEGIN
ergebnis := Ø;
FOR ALL α ∈ r DO
FOR ALL β ∈ s DO
IF Passend(α,β)
(* liefert TRUE gdw α(A) = β(A) für alle A ∈ dom r ∩ dom s *)
THEN ergebnis := ergebnis ∪ {α ∪ β}
END
END
END;
RETURN ergebnis
END NestedLoopJoin;
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
358
Hauptaufgabe jeder Verwirklichung des natürlichen Verbunds
r
•
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
359
die passenden Paare (α, β) finden mit
α ∈ r und
β ∈ s und
α(A) = β(A) für alle A ∈ dom r ∩ dom s
•
dann α und β tatsächlich zusammenfügen zu einem Tupel α ∪ β
•
und dieses Tupel für die Ergebnisrelation t ausgeben
•
grundlegende Verwirklichungen:
- NestedLoop
- Sortiertes Mischen
- Link-Verbund
- Hash-Filter-Verbund
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
360
Grundverwirklichung - NestedLoop mit Blockliste
Veranschaulichung der (vereinfachten) Strukturen
SPEICHER
(Annahmen, Vorbedingungen über) Daten- und Zugriffsstrukturen:
• Argumentrelationen r und s sind blockweise auf einem Magnetplattenspeicher abgelegt
Symbol
ErsterBlock
Puffer
DURCHLAUF
r
r_buffer
s
s_buffer
t
t_buffer
ScanId
LaufenderBlock
r_liste
...
s_liste
...
t_liste
• für jede Relation ist eine sequentielle Liste der Blöcke verfügbar
• Verweis auf den ersten Block ist in einem Datenwörterbuch (data dictionary) eingetragen
r_buffer
• jeder Block enthält einen Verweis auf seinen Nachfolger
A
s_buffer
B
B
C
t_buffer
A
B
C
• für jede Relation ist ein Pufferbereich im Hauptspeicher eingerichtet
• die Ergebnisrelation t soll wieder blockweise auf dem Magnetplattenspeicher erzeugt werden,
wobei gleichzeitig eine sequentielle Liste ihrer Blöcke aufgebaut werden soll
Datentransport
• um die sequentiellen Listen der Blöcke zu benutzen bzw. aufzubauen,
Magnetplattenspeicher
sind Relationendurchläufe (relation scans) verfügbar
r_liste.LaufenderBlock
r-Blöcke :
• in einer Durchlauftabelle (scan table)
r.ErsterBlock
wird für jeden Durchlauf ein Verweis auf den derzeit betrachteten Block abgelegt
1
s-Blöcke :
s_liste.LaufenderBlock
s.ErsterBlock
t-Blöcke :
t_liste.LaufenderBlock
t.ErsterBlock
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
361
Operationen auf den Strukturen
erzeugt einen neuen Durchlauf scanid für die Relation r:
in die Relation DURCHLAUF wird ein neues Tupel µ eingetragen mit
µ(ScanId)
= (neu erzeugter Wert von) scanid,
µ(LaufenderBlock) = r.ErsterBlock
(*
*)
beendet den Durchlauf scanid:
in der Relation DURCHLAUF wird das Tupel µ mit µ(ScanId) = (Wert von) scanid
wieder entfernt
*)
transportiert den Block, auf den scanid.LaufenderBlock verweist,
vom Magnetplattenspeicher in den Pufferbereich buffer
und setzt dann scanid.LaufenderBlock
auf den im transportierten Block enthaltenen Verweis zum Nachfolgerblock
prüft, ob scanid.LaufenderBlock ein leerer Verweis ist
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
= (Wert von) t,
= Verweis auf den eingerichteten ersten Block,
= Verweis auf den eingerichteten Puffer
µ(ScanId)
= (neu erzeugter Wert von) scanid,
µ(LaufenderBlock) =ν(ErsterBlock)
*)
(*
*)
17. Juli 2003
*)
AppendScan(scanid:Scanidentifikator;
buffer:Relationenblock);
EndOfScan(scanid : Scanidentifikator ) : Boolean;
(*
362
und in die Relation DURCHLAUF wird ein neues Tupel µ eingetragen mit
GetNextBlock(scanid : Scanidentifikator;
VAR buffer : Relationenblock );
(*
17. Juli 2003
erzeugt eine (leere) Relation t,
richtet einen zugehörigen Pufferbereich ein,
richtet einen leeren ersten Block auf dem Magnetplattenspeicher ein
und erzeugt einen Durchlauf scanid für die Relation :
in die Relation SPEICHER wird ein neues Tupel ν eingetragen mit
ν(Symbol)
ν(ErsterBlock)
ν(Puffer)
CloseScan(scanid : ScanIdentifikator );
(*
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
CreateRelation(t: Relationensymbol;
VAR scanid : Scanidentifikator );
OpenScan(r : Relationensymbol;
VAR scanid : Scanidentifikator );
(*
© Joachim Biskup, Universität Dortmund
363
transportiert den im Pufferbereich buffer stehenden Block in den Magnetplattenspeicher,
verkettet diesen Block mit dem durch scanid.LaufenderBlock bezeichneten Block
und setzt dann scanid.LaufenderBlock auf den Verweis zum transportierten Block
*)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
364
Verfahren für NestedLoop mit Blockliste
BEGIN (*NestedLoop_BlockScan_Join*)
CreateRelation (t, t_liste);
t_buffer := ∅;
OpenScan (r, r_liste);
WHILE NOT EndOfScan (r_liste) DO
GetNextBlock (r_liste, r_buffer);
OpenScan (s, s_liste);
WHILE NOT EndOfScan (s_liste) DO
GetNextBlock ( s_liste, s_buffer);
InternalJoin ( r_buffer, s_buffer, t_buffer)
END;
CloseScan (s_liste)
END;
CloseScan (r_liste);
PROCEDURE NestedLoop_BlockScan_Join (
r,s
:
Relationensymbol;
t
:
Relationensymbol );
VAR r_liste, s_liste, t_liste
:
Scanidentifikator;
r_buffer, s_buffer, t_buffer
:
Relationenblock;
PROCEDURE InternalJoin( r_buffer, s_buffer : Relationenblock;
VAR t_buffer : Relationenblock);
VAR α, β : RelTupel;
BEGIN
FOR ALL α ∈ r_buffer DO
FOR ALL β ∈ s_buffer DO
IF Passend (α, β)
THEN t_buffer := t_buffer ∪ {α ∪ β};
IF full (t_buffer)
THEN AppendScan (t_liste, t_buffer);
t_buffer := ∅
END
END
END
END
END InternalJoin;
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
IF t_buffer ≠ ∅ THEN AppendScan (t_liste, t_buffer) END;
CloseScan (t_liste)
END NestedLoop_BlockScan_Join;
17. Juli 2003
365
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
Aufwand von NestedLoop mit Blockliste
366
Sortiertes Mischen
(Annahmen, Vorbedingungen über) Daten- und Zugriffsstrukturen:
falls ein Block höchstens tpb(u) viele Tupel (tuple per block) der Relation u aufnehmen kann,
so benötigt das Verfahren ungefähr
• wie bei NestedLoop
r
s
--------------- ⋅  1 + --------------- lesende Blockzugriffe,
tpb ( r ) 
tpb ( s )
• zusätzlich: sequentielle Liste der Blöcke und die Anordnung der Tupel in den Blöcken derart,
dass die Tupel entsprechend ihren Werten auf den Verbundattributen (aufsteigend) sortiert sind
join ( r, s )
-----------------------------------schreibende Blockzugriffe,
tpb ( join ( r, s ) )
wobei lesende und schreibende Zugriffe überlappend sein können
algorithmische Idee:
• T := dom r ∩ dom s
vergrößert man die Pufferbereiche,
kommt man gegebenenfalls mit weniger lesenden Zugriffen aus:
passt zum Beispiel die kleinere Relation, etwa r, vollständig in den Puffer,
so kann diese Relation dort verbleiben und wir benötigen nur
s
1 + --------------lesende Blockzugriffe:
tpb ( s )
r
17. Juli 2003
• Tupel entsprechend der Sortierung fortlaufend numeriert,
etwa
• r
r = {α1,...,α || r ||} und s = {β1,...,β || s ||}
s =
=
=
{α1,...,α || r ||}
∪αi ∈ r ( {αi}
∪αi ∈ r ( {αi}
s
s)
σT=αi T (s) )
s
• σT=αi T (s) bildet jeweils einen
möglicherweise leeren, zusammenhängenden Abschnitt in der Liste von s;
falls der Abschnitt nichtleer ist, hat er also die Form {βanf, βanf+1,...,βend}
• alle zueinander passenden Paare < αi , σT=αi T (s) > können bestimmt werden durch
einen einzigen Durchlauf durch r und einen einzigen Durchlauf durch s
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
367
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
368
Verfahren für Sortiertes Mischen
Beispiel für Sortiertes Mischen
wir durchlaufen die Relation r entsprechend der Sortierung:
für jedes αi ∈ r stellen wir fest, ob
σT=αi T (s) nichtleer ist,
und bestimmen gegebenenfalls
die Anfangsnummer anf und die Endnummer end des entsprechenden Abschnittes,
indem wir zwei Fälle bezüglich des vorangehenden Tupels αi-1 ∈ r unterscheiden:
r
A
B
D1
D2
b
b
d
c
b
c
d
d
b
c
c
c
f
f
g
h
D3
D4
D5
D6
D7
D8
Fall 1:αi-1 T < αi T :
dann sucht man in s entsprechend der Sortierung nach passenden Tupeln,
wobei man bei dem zuletzt betrachteten Tupel βj ∈ s beginnt
die Suche kann abgebrochen werden, sobald αi T < βj T
r
Fall 2:αi-1 T = αi T :
dann ist der zu αi passende Abschnitt gleich dem zu αi-1 passenden Abschnitt
falls dieser Abschnitt nichtleer ist,
so kennen wir seine Anfangsnummer anf und seine Endnummer end und
können αi mit jedem der Tupel βanf,...,βend verbinden für die Ausgaberelation
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
369
Aufwand vom Sortierten Mischen
© Joachim Biskup, Universität Dortmund
Di ªT anf end
s A B C
A
B
C
a
b
c
c
d
d
b
b
d
e
b
f
a
h
Nummer j des
zuletzt
betrachteten
Tupels Ej s
Ej ª 7
b
b
b
1
b
2
2
3
c
b
b
c
c
d
e
2
c
3
4
5
d
d
d
c
c
d
e
3
c
3
4
5
d
c
c
c
c
d
e
4
c
3
4
5
d
5
f
-
-
7
h
6
f
-
-
7
h
7
g
-
-
7
h
8
h
7
7
f
d
17. Juli 2003
s
E1
E2
E3
E4
E5
E6
E7
Nummer i des
betrachteten
Tupels Dir
falls man passende Tupel gefunden hat,
so merken wir uns die Anfangsnummer anf und die Endnummer end des Abschnittes
und verbinden αi mit jedem der Tupel {βanf,...,βend} für die Ausgaberelation
© Joachim Biskup, Universität Dortmund
C
h
a
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
die Blöcke der Relation r werden einmal lesend durchlaufen
jedes α ∈ r wird bezüglich seiner T-Werte mit seinem Vorgänger verglichen:
etwa || r || Vergleiche
nimmt man an, dass die σT=αi T (s)-Abschnitte jeweils ganz im Puffer Platz finden,
so werden auch die Blöcke der Relation s nur einmal lesend durchlaufen
in jedem “Passend-Vergleich” zwischen einem Tupel α ∈ r und einem Tupel β ∈ s
wird mindestens eines dieser Tupel erstmalig benutzt:
höchstens || r || + || s || Vergleiche
17. Juli 2003
372
nimmt man dagegen realistischer an,
dass gelegentlich Blöcke der Relation s wiederholt gelesen werden müssen,
so ergeben sich
r
s
lesende Blockzugriffe,
--------------- + w ⋅ --------------tpb ( r )
tpb ( s )
das gesamte Verfahren:
etwa höchstens 2 * || r || + || s || Vergleiche
c
c
f
f
g
370
Abschätzung der Anzahl der Blockzugriffe:
Abschätzung der Anzahl der Vergleiche:
b
c
17. Juli 2003
a
wobei w ≥ 1 ein (im Allgemeinen nur zu schätzender) Wiederholungsfaktor ist
b
c
c
d
d
wird die Sortierung erst zum Zeitpunkt der Anfrage aufgebaut,
so muss man den Aufwand für das Sortieren hinzurechnen
h
h
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
371
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
Link-Verbund
Veranschaulichung der (vereinfachten) Strukturen
SPEICHER Symbol
(Annahmen, Vorbedingungen über) Daten- und Zugriffsstrukturen:
ErsterBlock Puffer
r
r_buffer
s
s_buffer
t
t_buffer
link
blatt
blatt
r_buffer
DURCHLAUF
ScanId
LaufenderBlock
t_liste
...
• die Argumentrelationen r und s sind blockweise auf einem Magnetplattenspeicher abgelegt
link_liste
...
• für die Relationen r und s ist ein Link bezüglich der Verbundattribute T
als B*-Baum vorhanden
A
s_buffer
B
B
t_buffer
C
A
B
C
• damit sind ebenfalls je eine sequentielle Liste für die TIDs der Relationen verfügbar
• für jede Relation und für den Link ist ein Pufferbereich im Hauptspeicher eingerichtet,
der jeweils genau einen Block aufnehmen kann
Datentransport
Magnetplattenspeicher
• die Ergebnisrelation t soll wieder blockweise auf dem Magnetplattenspeicher erzeugt werden,
Link für r und s :
wobei gleichzeitig eine sequentielle Liste ihrer Blöcke aufgebaut werden soll
• das Datenwörterbuch enthält auch Angaben über die vorhandenen Links
• um die sequentiellen Listen zu benutzen bzw. aufzubauen,
link_liste.LaufenderBlock
link. Erster Block
wird wieder eine Durchlauftabelle angelegt
r-Blöcke :
• es gibt ein geeignetes Verfahren zur Umwandlung von TIDs in Speicheradressen
s-Blöcke :
t_liste.LaufenderBlock
t-Blöcke :
t.ErsterBlock
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
373
Operationen auf den Strukturen
bestimmt aus Angaben im Datenwörterbuch
das Linksymbol für den Link zu r und s bezüglich der Attribute X von r bzw. Y von s
und liefert diesen als Wert des Ausgabeparameters linkid zurück
*)
LocateFetch (tid : Tupelidentifikator;
VAR buffer : Relationenblock;
VAR tupel : RelTupel );
(*
sucht tid zunächst im Pufferbereich buffer;
falls tid dort nicht vorhanden ist,
wird (mittels der Umwandlung von TIDs in Speicheradressen) der tid enthaltende Block
vom Magnetplattenspeicher in den Pufferbereich buffer transportiert;
anschließend wird das durch tid identifizierte Tupel
als Wert des Ausgabeparameters tupel zurückgeliefert
*)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
374
17. Juli 2003
376
ferner wie bei NestedLoop:
DetermineLink ( r, s : Relationensymbol;
X, Y : Attributmenge;
VAR linkid : Linksymbol );
(*
© Joachim Biskup, Universität Dortmund
17. Juli 2003
375
OpenScan
(
linkid
:
VAR scanid :
Relationen_oder_Linksymbol;
Scanidentifikator );
CloseScan
(
scanid
Scanidentifikator );
GetNextBlock
(
scanid
:
VAR buffer :
Scanidentifikator;
Relationen_oder_Linkblock );
EndOfScan
(
scanid
:
Scanidentifikator ) : Boolean;
CreateRelation
(
t
VAR scanid
:
:
Relationensymbol;
Scanidentifikator );
AppendScan
(
scanid
buffer
:
:
Scanidentifikator;
Relationenblock );
© Joachim Biskup, Universität Dortmund
:
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
algorithmische Idee:
PROCEDURE Link_Join (r, s : Relationensymbol; t : Relationensymbol);
VAR link : Linksymbol;
link_liste, t_liste : Scanidentifikator;
r_buffer, s_buffer, t_buffer : Relationenblock;
blatt : Linkblatt;
BEGIN
CreateRelation (t, t_liste);
t_buffer := ∅;
DetermineLink (r, s, T, T, link);
• T := dom r ∩ dom s
• r
s =
=
=
∪α∈r ∪β∈s ( {α} {β} )
∪ µ∈πT(r)∩πT(s) ( ∪ α∈r, αT=µ ∪ β∈s, βT=µ {α ∪ β} )
∪ µ∈πT(r)∩πT(s) ( σT=µ (r)
σT=µ (s) )
• das Verfahren durchläuft die Blattknoten des Links:
OpenScan (link, link_liste);
WHILE NOT EndOfScan (link_liste) DO
GetNextBlock (link_liste, blatt);
Blattjoin (blatt)
END;
CloseScan (link_liste);
die Einträge in diesen Blättern haben die Form
< T-Wert : Folge von TIDs für r ; Folge von TIDs für s >,
wobei für einen T-Wert µ gerade alle TIDs aus σT=µ (r) bzw. σT=µ (s) angegeben sind
• also muss man nur noch für jeden Eintrag
die Tupel der Teilrelationen σT=µ (r) und σT=µ (s) auffinden,
dann σT=µ (r)
σT=µ (s) bilden und
schließlich das so gebildete Teilergebnis ausgeben
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
IF t_buffer ≠ ∅ THEN
AppendScan (t_liste, t_buffer)
END;
CloseScan (t_liste)
END Link_Join;
17. Juli 2003
377
PROCEDURE Blattjoin (blatt);
(* r_buffer, s_buffer, t_buffer und t_liste
werden als globale Variablen verwendet;
blatt sei wie folgt aufgebaut
anzahl : CARDINAL;
liste : ARRAY [1..anzahl] OF
RECORD
schlüssel : Wert;
anz_tids_1 : CARDINAL;
anz_tids_2 : CARDINAL;
tids_1 : ARRAY[1..anz_tids_1] OF Tupelidentifikator;
tids_2 : ARRAY [1..anz_tids_2] OF Tupelidentifikator
END; *)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
378
BEGIN (* Blattjoin *)
FOR eintrag := 1 TO anzahl DO
FOR tid_1 := 1
TO liste [eintrag].anz_tids_1 DO
FOR tid_2 := 1 TO liste [eintrag].anz_tids_2 DO
LocateFetch (liste [eintrag].tids_1 [tid_1], r_buffer, tupel_1);
LocateFetch (liste [eintrag].tids_2 [tid_2], s_buffer, tupel_2);
t_buffer := t_buffer ∪ {tupel_1 ∪ tupel_2};
IF full (t_buffer)
VAR
17. Juli 2003
eintrag, tid_1, tid_2 : CARDINAL;
tupel_1, tupel_2 : RelTupel;
THEN
AppendScan (t_liste, t_buffer);
t_buffer := ∅
END
END
END
END
END Blattjoin;
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
379
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
380
Aufwand von Link-Verbund
Hash-Filter-Verbund
• Aufwand bezüglich der “Passend-Vergleiche” entfällt beim Link-Verbund
• Aufwand bezüglich der lesenden Blockzugriffe ist schwierig analytisch zu bestimmen
• Operation LocateFetch kann sehr schnell oder sehr langsam sein;
(Annahmen, Vorbedingungen über) Daten- und Zugriffsstrukturen:
• alle Strukturen wie bei NestedLoop mit Block-Liste
• für Werte der Attribute aus T ist eine Hashfunktion verfügbar der Form
schnell:
langsam:
das Tupel befindet sich im Pufferbereich und seine dortige Adresse ist bekannt
das Tupel muss im Magnetplattenspeicher gesucht und
von dort in den Pufferbereich geholt werden
• günstiger Fall:
die Relationen r und s sind nach den Verbundattributen (aufsteigend) sortiert gespeichert, und
die Pufferbereiche sind groß genug, dass keine Blöcke wiederholt gelesen werden müssen
hash : Domäne (T) → {1,...,k} mit k >= max (|| r ||, || s ||) lässt wenige Kollisionen erwarten
• für die Relationen r und s stehen zwei Bitlisten bit_r und bit_s der Länge k
zur Verfügung, die mit false initialisiert werden können
algorithmische Idee:
• r
r
s
dann nämlich benötigt man BL + --------------- + --------------- lesende Blockzugriffe,
tpb ( r ) tpb ( s )
BL + 2 ⋅ k ⋅ join ( r, s )
für solche Filterrelationen gilt ebenfalls
lesende Blockzugriffe
17. Juli 2003
381
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
382
(sehr einfache) Hashfunktion: Divisions-Rest-Methode mit Parameter k = 11: hash(x) := x mod 11
2. für jedes α ∈ r berechne hash(αT ) und setze entsprechendes Bit, d.h.:
bit_r (hash (αT)) := true
a)
3. für jedes β ∈ s berechne hash(βT );
falls entsprechendes Bit in bit_r schon gesetzt ist, setze dieses Bit auch in bit_s
und füge β zur neuen Unterrelation s_filter hinzu, d.h.:
stelle := hash (βT);
IF bit_r (stelle)
THEN bit_s (stelle) := true;
insert (β, s_filter)
(* am besten s_filter mit Index und sortiert aufbauen *)
END
r
b)
0
1
2
3
4
5
6
7
8
9
10
4. Für jedes α ∈ r berechne hash (αT ) ;
falls entsprechendes Bit in bit_s gesetzt ist,
füge α zur neuen Unterrelation r_filter hinzu, d.h.:
IF bit_s (hash (αT)
THEN insert (α, r_filter)
(* am besten r_filter mit Index und sortiert aufbauen *)
END
s_filter (* etwa mit Link-Verbund *)
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
s_filter
Beispiel für Hash-Filter-Verbund
1. initialisiere die Bitlisten bit_r und bit_s mit false
© Joachim Biskup, Universität Dortmund
s = r_filter
r;
wobei man am besten die Filterrelationen sortiert aufbaut und
Indexe bezüglich der Verbundattribute bzw. einen gemeinsamen Link erzeugt
Verfahren des Hash-Filter-Verbunds
5. Berechne r_filter
r
s , bzw. s ⊃ s_filter ⊃ s
• man bestimmt solche Filterrelationen mit Hilfe von Bitlisten und einer Hashfunktion,
so muss man den Aufwand für seine Erstellung hinzurechnen
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
πdom r∩dom s (r) )
(s
r_filter bzw. s_filter mit r ⊃ r_filter ⊃ r
• wird der Link erst zum Zeitpunkt der Anfrage aufgebaut,
© Joachim Biskup, Universität Dortmund
πdom r∩dom s (s) )
(r
= (r
s)
(s
r)
wobei
die abgeleitete relationale Operation des Teilverbunds (semi-join) bezeichnet
• die Teilverbünde r
s bzw. s
r sind erwartungsgemäß bedeutend kleiner
als die ursprünglichen Relationen r bzw. s
• die Teilverbünde möglichst gut nach oben schätzen durch Relationen
wobei BL die Anzahl der Blattknoten des Links sei und
jeder Block ein zum Ergebnis beitragendes Tupel enthalte
• ungünstiger Fall:
die Tupel der Relationen r und s sind so unglücklich auf die Blöcke verteilt,
dass jede Ausführung von LocateFetch
eine Suche im Magnetplattenspeicher mit etwa jeweils k vielen Blockzugriffen auslöst
dann benötigt man
s =
17. Juli 2003
383
© Joachim Biskup, Universität Dortmund
A
1
2
5
7
16
1
2
B
1
1
5
1
3
2
2
C
s
bit_r
bit_s
t
t
t
t
t
A
5
1
9
19
3
19
B
C
1
1
9
1
3
7
t
c) s_filter
A
5
1
d) s_filter
r_filter
B
r
C
1
1
A
5
B
5
C
1
1
1
1
2
1
1
A
1
5
16
1
B
1
5
3
2
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
C
17. Juli 2003
384
Aufwand des Hash-Filter-Verbunds
Zusammenfassung der Verbund-Algorithmen
• die Relation r muss zweimal und die Relation s muss einmal durchlaufen werden,
•
wobei der folgende Aufwand anfällt:
r
s
2 ⋅ --------------- + --------------lesende Blockzugriffe
tpb ( r ) tpb ( s )
rfilter
sfilter
----------------------------- + ----------------------------tpb ( rfilter ) tpb ( sfilter )
2⋅ r + s
durchlaufe “äußere Relation”:
für jedes Tupel der äußeren Relation durchlaufe “innere Relation”:
füge jeweils passende Tupel zusammen
schreibende Blockzugriffe
•
die Erstellung der Sortierungen von r_filter und s_filter und des Links
• schlechter Fall, die Filterwirkung fällt gering aus:
•
- der Aufwand für die Aufrufe der Hashfunktion wird im Wesentlichen vergeblich eingesetzt
- für die aufgebauten Zugriffsstrukturen zu r_filter und s_filter
kann geeignetes Verfahren, etwa Link-Verbund, eingesetzt werden
•
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
Link-Verbund
(erstelle Link, gemeinsamen Index, beider Relationen bezüglich Verbundattributen;)
durchlaufe Blattknoten des Links und füge jeweils passende Tupel zusammen
• guter Fall, die Filterwirkung fällt stark aus:
der (in der Größe von r und s) lineare Aufwand zur Erstellung von r_filter
s_filter macht sich dadurch bezahlt,
dass in Schritt 5 erheblich kleinere Relationen als r bzw. s zu verbinden sind
Sortiertes Mischen
(sortiere beide Relationen auf Verbundattributen;)
durchlaufe beide Relationen simultan entsprechend der Sortierung:
für jedes Tupel der “äußeren Relation” bestimme bzw. durchlaufe
den Abschnitt passender Tupel der “inneren Relation”
und füge jeweils passende Tupel zusammen
Aufrufe der Hashfunktion (mit umrahmenden Operationen)
• zusätzlich muss berücksichtigt werden der Aufwand für
© Joachim Biskup, Universität Dortmund
NestedLoop
und
385
Hash-Filter-Verbund
erstelle Filterrelationen mit Hilfe von Hashfunktion und Bitlisten
als Abschätzungen der beiden Teilverbunde;
verbinde die Filterrelationen mit Hilfe von Link-Verbund oder Sortiertem Mischen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Zugriffsstrukturen und Verbund-Algorithmen - Verbund-Algorithmen
17. Juli 2003
386
Optimierung von Anfragen
Informationssystem: stellt einem Benutzer mächtige Anfragesprachen zur Verfügung
11 Anfrage-Optimierung
Benutzer:
kann damit Anfragen ausdrücken,
die im Wesentlichen beschreiben,
was (welche Aussagen, Tupel, Objekte, Objektwerte) er als Ergebnisse erwartet
Informationssystem: um Anfragen effizient zu bearbeiten,
ermittelt aus der Anfrage,
wie die gewünschten Ergebnisse bzw. deren Bestandteile
möglichst schnell (und platzsparend) erzeugt bzw. aufgefunden werden können
Optimierungsaufgabe
bestimme aus der Beschreibung des Was (einer Anfrage)
einen guten Plan für das Wie (einen Algorithmus)!
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
387
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
388
Optimierung: besonders wichtig und besonders schwierig
Entwurfsumgebung
Arbeitsplatz- . . .
umgebung
Netzumgebung
Programmier- . . .
umgebung
Datenmanipulationssprache (DML)
Vereinbarungen
..
.
Sicht i
Schema
Änderungen
Sprachanalyse
EinsatzSchnittstellen
Anfragen
Antworten
Erklärungen
InformationssystemSchnittstelle
•
Aufbereitung
von
Antworten
..
.
Relationen (Klassen),
Tupel (Objekte)
konzeptionelles
Schema
konzeptionelle Schicht
(mengenorientiert,
mit Optimierung)
Transaktionsverwaltung
Zugriffsstrukturen,
Tupelidentifikatoren
(Surrogate), Datensätze
internes Schema
•
einerseits kann Benutzer
anwendungsnahe, mächtige Sprachmittel
auf sehr große Mengen von Daten anwenden
eingebettet
interaktiv, selbständig
Datendefinitionssprache (DDL)
...
Beispiel: “naive Auswertungen”
MengenSchnittstelle
andererseits muss Informationssystem
die volle Kluft zwischen
Benutzersprache und Speicherzugriffen
über alle Zwischenschichten hinweg
überbrücken
TupelSchnittstelle
Benutzer stellt Anfrage als Ausdruck der relationalen Algebra:
σZ=c( R
R und S seien Namen für sehr große Relationen:
etwa mit je 106 Tupeln
S)
cNL * (106)2
cSM * 106
• gefolgt von einem Selektionsverfahren
falls beide Relationen noch nicht sortiert sind,
so erforderte die Sortierung mit einem guten Verfahren,
(das bei Eingabe von n Tupeln eine Laufzeit O(n * log n) hat)
einen zusätzlichen Aufwand ( 20 ≈ Duallogarithmus von 106):
(virtueller) flüchtiger und dauerhafter Speicher
Segmente, Blöcke; Einrichten und Freigeben, Lesen und Schreiben
SpeicherSchnittstelle
GeräteSchnittstelle
© Joachim Biskup, Universität Dortmund
dom R = {X,Y}
dom S = {Y, Z}
auswertbar durch:
• eine geeignete Verwirklichung des natürlichen Verbundes:
- NestedLoop hat eine quadratische Komplexitätsfunktion,
also im Beispiel eine Laufzeit:
- sortiertes Mischen hat unter günstigen Umständen eine
lineare Laufzeit, im Beispiel:
interne Schicht
(Datensatz-orientiert)
...
gemäß Schema:
Speichergeräte
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
389
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
Beispiel: verbesserte Auswertung
17. Juli 2003
390
Beispiel: günstiger Fall
da Z ∈ dom S: σZ=c(R
S) ist äquivalent zu
R
σZ=c(S) ,
wobei Ergebnis der Selektion σZ=c(S) im Allgemeinen viel kleiner als S selbst sein wird
wenn im Datenbankschema das Attribut Z für die Relation S als Schlüsselattribut vereinbart ist
(für Optimierer aus dem Datenbankschema erkennbar),
dann enthält σZ=c(S) höchstens ein Tupel
Anfrage:
σZ=c(R
alle günstigen Annahmen:
- Attribut Z für die Relation S als Schlüsselattribut vereinbart
S)
- Index, B*-Baum, bezüglich Attribut Z in S unterhalten
- Relation R nach dem Attribut Y sortiert gespeichert
wenn zusätzlich ein Index, etwa als B*-Baum, bezüglich Attribut Z in S unterhalten wird,
dann könnte man σZ=c(S) durch eine einzige Suche im B*-Baum verwirklichen
Auswertung von:
erhält man als Ergebnis dieser Suche das Tupel µ aus S zurück,
so reduziert sich der Anfrageausdruck wie folgt:
Aufwand der Größenordnung von vielleicht:
R
2 * cSort * 20 * 106
{µ},
was wiederum äquivalent ist mit: R
{( Y, µ(Y) )}
{(Z,c)} = σY=µ(Y)(R)
{(Z,c)}
d.h. im Wesentlichen:
• nur eine Selektion auf R nach dem zwischenzeitlich ermittelten Wert µ(Y) durchführen und
• jedes Ergebnistupel der Selektion mit dem Wert c für Attribut Z verbinden
σY=µ(Y)(R)
{(Z,c)}
5
Zugriffen längs eines Pfades im B*-Baum (der Tiefe 5) für Relation S und
20
Zugriffen zur logarithmischen Suche desjenigen Blocks von Relation R,
in dem sich die zu selektierenden Tupel befinden
wenn die Relation R nach dem Attribut Y sortiert gespeichert ist,
dann kann die Selektion als schnelle Suche mit Aufwand O(log n) durchgeführt werden
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
391
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
392
Beispiel: Zusammenfassung
Ziel der Optimierung
sehr grobe (sicherlich viel zu optimistische) untere Schranke für eine Zeiteinheit: 1 µsec
im Beispiel ergibt sich folgende Bandbreite:
1012 ∗ 10-6 sec =
NestedLoop:
106 sec
≈
(20 + 1) * 106 * 10-6 sec =
Sortiertes Mischen:
Spezialfall mit B*-Baum, sortierter Speicherung:
25 * 10-6 sec =
Auswertung einer Anfrage:
• zunächst bestimmte Daten (Werte, Tupel, Objekte)
in der gegenwärtigen Instanz des Informationssystems auffinden
•
12 Tage
anschließend aus bzw. in Abhängigkeit von diesen aufgefundenen Daten
die gewünschten Ergebnisse erzeugen
21 sec
Damit ergeben sich folgende Wunsch-Anforderungen (die i. Allg. kaum erfüllbar sind):
25 µsec
O1. [Suchraum beschränken]
ausschließlich auf die zu findenden Daten zugreifen
O2. [Wiederholungen vermeiden]
auf jedes zu findende Datum nur einmal zugreifen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
393
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
Methoden der Optimierung
•
17. Juli 2003
396
Kenntnisse über die Semantik von Anfragen,
insbesondere Regeln für äquivalenzerhaltende Umformungen
•
2. [Erstellung von Ausführungsplänen]
so bestimmte Anfragen jeweils übersetzen
in ein oder mehrere Ausführungspläne,
deren Anweisungen auf tieferen Schichten des Informationssystems liegen
Schemavereinbarung,
insbesondere semantische Bedingungen
3. [Aufwandsschätzung]
für so gewonnene Ausführungspläne
den voraussichtlichen Aufwand abschätzen
•
Kenntnisse über verfügbare Datenstrukturen und Algorithmen
•
Laufzeitinformation über gespeicherte Objekte
(z.B. Anzahl der gespeicherten Tupel einer Relation)
•
4. [Suche nach einem kostengünstigen Ausführungsplan]
alle erfolgversprechenden äquivalenten Umformungen erzeugen (gemäß 1.)
und deren Übersetzungen in Pläne (gemäß 2.)
und jeweils deren Aufwand (gemäß 3.) bestimmen mit dem Ziel,
möglichst schnell einen Plan als kostengünstig (oder im besten Fall als kostengünstigsten)
im Vergleich mit den anderen erzeugten Plänen zu erkennen
Informationssysteme: Anfrage-Optimierung
394
Grundlagen der Optimierung
1. [äquivalente Umformungen der Anfrage]
auf der Ebene der Anfragesprache äquivalente Anfragen bestimmen, in denen
- (im Sinne der Semantik) redundante Teile entfernt sind oder
- Variable (bzw entsprechende Konzepte) an möglichst kleine Mengen gebunden werden
© Joachim Biskup, Universität Dortmund
17. Juli 2003
17. Juli 2003
395
Laufzeitinformation über bereits angelegte Zugriffsstrukturen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
einige Heuristiken zur Optimierung relationaler Ausdrücke
Zusammenfassen von Ausdrücken
•
•
Ausdrücke zusammenfassen
•
Redundanz entfernen
•
Selektionen und Projektionen vorziehen
•
Verbund-Reihenfolge auswählen
eine Folge von direkt hintereinander auszuführenden Selektionen der Form
σA1=c1 ° σA2=c2 ° ... ° σAn=cn(R)
kann zusammengefasst werden zu einer Selektion der Form
σA1=c1 ∧ A2=c2 ∧ ... ∧ An=cn(R)
•
eine Folge von direkt hintereinander auszuführenden Projektionen der Form
πX1 ° ... ° πXn(R)
kann zusammengefasst werden zu einer Projektion der Form
πX1 ∩ ... ∩ Xn(R)
•
ein Verbund-Ausdruck der Form
πX( R1
R2 )
kann als eine Einheit ausgewertet werden,
wenn bei der Erzeugung eines Tupels µ von R1
R2
von vornherein nur die Einschränkung µX geliefert wird
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
397
...
© Joachim Biskup, Universität Dortmund
Entfernen von Redundanz
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
Vorziehen von Selektionen und Projektionen
Selektionen und Projektion möglichst früh ausführen
durch Semantik-erhaltende Vertauschung mit vorangehender Operation:
Zwischenergebnisse möglichst klein halten!
offensichtlich redundante Teile eines Ausdruckes können entfernt werden
zum Beispiel gilt wegen des Absorbtiv-Gesetzes für den natürlichen Verbund:
Vertauschungen sind etwa entsprechend der folgenden (Umformungs)Regeln möglich:
falls
bekannt ist, dass der Wert von R stets Teilmenge des Wertes von S ist,
•
falls A ∈ dom R, dann
σA=c(R
S) =
σA=c(R)
S
dann
kann der Ausdruck R
•
falls A ∈ dom R ∩ dom S, dann
σA=c(R
S) =
σA=c(R)
σA=c(S)
S
verkürzt werden zu R
•
σA=c(R ∪ S)
=
σA=c(R) ∪ σA=c(S)
•
σA=c(R \ S)
=
σA=c(R) \ σA=c(S)
•
falls A ∈ X ∩ dom R, dann
σA=c(πX(R))
=
πX(σA=c(R))
•
falls dom R ∩ dom S ⊂ X, dann
πX(R
=
πX(R)
=
πX(R) ∪ πX(S)
•
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
399
S)
πX(R ∪ S)
•
© Joachim Biskup, Universität Dortmund
398
πX(S)
...
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
400
Auswahl von Verbund-Reihenfolge
Entfernen von Redundanz logik-orientiert
•
Zwischenergebnisse möglichst klein halten !
wesentlicher Kern der Semantik (Wiederholung):
Bestimmung der logischen Implikation |=
•
erst “Durchschnitt-ähnliche” Verbünde ausführen,
dann erst “Produkt-ähnliche” !
RS mit EDB = {R1 ,..., Rn} Schema
< R| Q >
LOGODAT-Anfrage mit (Hornklausel-)Anfrageprogramm
“hängende Tupel” vermeiden !
f = (r1,...,rr)
Ausprägung zu EDB
•
evalRS(< R | Q >)(f)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
401
© Joachim Biskup, Universität Dortmund
Lemma [äquivalente Umformungen von Anfragen]
wenn Q1 |= Q2 ,
dann für alle Ausprägungen f zu RS:
Beweis:
R(c1,...,cs). ∈ evalRS (< R | Q2>)(f)
Definition deklarative Semantik:
f ∪ Q2 |= R(c1,...,cs).
zu zeigen:
f ∪ Q1 |= R(c1,...,cs).
betrachte dazu:
M Modell von f ∪ Q1
nach Voraussetzung:
also:
also:
Q1 |= Q2
M auch Modell von Q2
M auch Modell von f ∪ Q2
gemäß (1):
M Modell von R(c1,...,cs).
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
{R(c1,...,cs). | f ∪ Q |= R(c1,...,cn). mit c1,...,cs ∈ C}
=
{R(c1,...,cs). | T(c1,...,cs). ∈ fix(f ∪ Q)}
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
402
Redundanz von Anfrageklauseln oder Prämissen
evalRS (< R | Q1 >)(f) ⊃ evalRS (< R | Q2 >)(f)
betrachte:
:=
Anfrageklausel K heißt redundant in Q bezüglich RS
:gdw für alle Instanzen f zu RS gilt:
evalRS(< R | Q >)(f) = evalRS(< R | Q \ {K}>)(f)
Prämisse Ai von K ≡ A0 :- A1,..., Ai ,..., Am. heißt redundant in K bezüglich RS und Q
:gdw für alle Instanzen f zu RS gilt:
evalRS(< R | Q >)(f) = evalRS(< R | (Q \ {K}) ∪ {A0 :- A1,..., Ai-1 , Ai+1 ,...,Am.}>)(f)
(1)
o.B.d.A. nur Anfragen mit R = concl(K) ∈ concl(Q \ {K}) betrachten;
in geforderten Gleichheiten ist jeweils eine Inklusion trivial,
denn gemäß Lemma über äquivalente Umformungen:
wegen
folgt
Q |= Q \ {K},
für alle Instanzen f zu RS:
evalRS(< R | Q>)(f) ⊃ evalRS(< R | Q \ {K}>)(f)
bzw.
wegen
folgt
17. Juli 2003
403
(Q \ {K}) ∪ {A0 :- A1,..., Ai-1 , Ai+1 ,...,Am.} |= Q
für alle Instanzen f zu RS:
evalRS(< R | (Q \ {K}) ∪ {A0 :- A1,..., Ai-1 , Ai+1 ,...,Am.}>)(f) ⊃ evalRS(< R | Q>)(f)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
404
Aufwandsschätzung
Beispiel für Aufwandsschätzung
berücksichtigt insbesondere die folgenden Faktoren:
•
äquivalente Ausdrücke aus obigem Beispiel:
Kenngrößen der gespeicherten Relationen, z.B.
- derzeitige Anzahl der Tupel (Eigenschaft der Instanz),
- (maximale) Länge eines Tupels (Eigenschaft des Schemas),
- Anzahl der möglichen Werte für ein Attribut (Eigenschaft des Schemas)
•
•
σZ=c(R
S) und R
σZ=c(S)
dom R = {X,Y} und dom S = {Y, Z}
Kenngrößen der gespeicherten Relationen:
kr
ks
ky
kz
Statistische Annahmen,
:=
:=
:=
:=
Anzahl der Tupel in Instanz von R
Anzahl der Tupel in Instanz von S
Anzahl der Konstantenzeichen in Domäne b(Y)
Anzahl der Konstantenzeichen in Domäne b(Z)
um Erwartungswerte für die Kenngrößen
der als Zwischenergebnisse sich ergebenden Relationen zu berechnen
statistische Annahme:
Kostenfunktionen
alle Zufallsvariablen für interessierende Ereignisse sind gleichverteilt und statistisch unabhängig
für die im Datenbanksystem verfügbaren Algorithmen
zur Verwirklichung der relationalen Operationen
Kostenfunktion:
Laufzeiten der einfachen Algorithmen für die Selektion bzw. den natürlichen Verbund:
kosten (σΑ=c(T)) := Anzahl der Tupel im Wert von T
kosten (U
V) :=
(Anzahl der Tupel im Wert von U) * (Anzahl der Tupel im Wert von V)
Kostenfunktion für zusammengesetzte Ausdrücke additiv fortsetzen,
wobei die Größe eines Zwischenergebnisses durch ihren Erwartungswert geschätzt wird:
© Joachim Biskup, Universität Dortmund
kosten (σZ=c(R
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
S)) =
© Joachim Biskup, Universität Dortmund
Informationssysteme: Anfrage-Optimierung
17. Juli 2003
406
17. Juli 2003
408
kr * ks + kr * ks / ky
=
(kr * ks) * ( 1 + 1/ky )
wobei geschätzte Größe des Wertes von R
kosten (R
405
12 relationaler Schemaentwurf
S: kr * ks / ky
σZ=c(S)) =
ks + kr * ks / kz
=
ks * ( 1 + kr /kz )
wobei geschätzte Größe des Wertes von σZ=c(S):
ks / kz
im Allgemeinen:
Kosten im zweiten Fall (mit vorgezogener Selektion) kleiner als im ersten Fall,
beispielsweise:
kr = ks = ky = kz
kosten (σZ=c(R
kosten (R
© Joachim Biskup, Universität Dortmund
:=
S)) = 106 * 106 * ( 1 + 1/106 ) ≈
σZ=c(S)) = 106 * (1 + 1)
Informationssysteme: Anfrage-Optimierung
≈
106
1012
2 * 106
17. Juli 2003
407
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf
Schemaentwurf
Entwurfsheuristiken für relationale Formalisierung
ein Informationssystem dient insbesondere dazu:
• Daten für verschiedenartige Benutzer verfügbar zu halten
• Anfragen und Änderungen effizient zu bearbeiten
•
eine Basisrelation zählt genau einen Gesichtspunkt auf
(genau eine Klasse von Seienden oder von grundlegenden Beziehungen):
außer den Schlüsselwerten (die jeweils ein Seiendes oder eine Beziehung eindeutig bestimmen)
sollen nur Werte für die genau zugehörigen Eigenschaften hinzugefügt werden
Grundlage dafür sind:
• eine gute Modellierung des Anwendungsfalles, etwa mit Hilfe der semantischen Begriffe:
die angestrebte Unterstützung kommunikativ Handelnder kann dann gelingen,
wenn alle Beteiligten die Modellierung einvernehmlich als gemeinsame Beschreibung
der bedeutsamen Gesichtspunkte des jeweiligen “Unternehmens” annehmen
•
die Trennungsheuristiken sollen Redundanzfreiheit auf die Ebene der Formalisierung übertragen
- welche Beziehungen (relationships) zwischen diesen Seienden sind grundlegend ?
(Vollständigkeit: alle anderen bedeutsamen Beziehungen lassen sich daraus erschließen;
Redundanzfreiheit: grundlegende Beziehungen lassen sich nicht auseinander erschließen)
•
Erschließbarkeit von Gesichtspunkten
alle bedeutsamen, aber nicht durch eine Basisrelation aufgezählten Gesichtspunkte
sind als Sichtrelationen erschließbar:
eine Aufzählung dafür kann durch eine in der relationalen Algebra ausdrückbare Anfrage
(meistens im Wesentlichen mit natürlichem Verbund oder mengentheoretischer Vereinigung)
aus den Basisrelationen gewonnen werden
- welche (formalen) Handlungen sind grundlegend ?
(Änderungsanweisungen sind leicht ausführbar)
• eine geeignete Formalisierung der zeitunabhängigen Teile der Modellierung
die Erschließbarkeitsheuristik soll Vollständigkeit auf die Ebene der Formalisierung übertragen
zu einem (Datenbank-)Schema für das gewählte Datenmodell
Informationssysteme: relationaler Schemaentwurf
Trennung von Spezialisierungen
eine Basisrelation zählt nur Spezialisierungen gleichen Formates auf:
gibt es innerhalb einer Klasse von Seienden Spezialisierungen von unterschiedlichem Format,
so soll für jedes vorkommende Format eine getrennte Basisrelation eingerichtet werden
umfasst insbesondere Verständigung über folgende Fragen:
- welche Seienden (entities) der Welt sind grundlegend
(wird ein “unabhängiges Sein”, eine “wirkliche Existenz” zugesprochen) ?
© Joachim Biskup, Universität Dortmund
Trennung von Gesichtspunkten
17. Juli 2003
409
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf
17. Juli 2003
410
17. Juli 2003
412
Theorie des relationalen Schemaentwurfs
•
formalisiert für Schemas
wertvolle semantische Anforderungen und
wünschenswerte syntaktische Eigenschaften
•
beweist Bezüge zwischen solchen Formalisierungen
•
liefert und untersucht Algorithmen,
um wünschenswerte syntaktische Eigenschaften
zu entscheiden oder zu erreichen
•
beweist, dass wünschenswerte syntaktische Eigenschaften
geringe Kosten erlauben bezüglich
- Speicherung
- Änderungen (einschließlich Erhaltung semantischer Bedingungen)
- Anfragen
•
umfasst insbesondere Untersuchungen über
semantische Bedingungen und deren Einfluss auf die Güte von Schemas:
funktionale Abhängigkeiten, Verbundabhängigkeiten,
Enthaltenseinsabhängigkeiten
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf
12.1 funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
411
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
funktionale Abhängigkeiten: Syntax
<R|U|F>
R
U
F
funktionale Abhängigkeiten: Semantik
Relationenschema
Relationensymbol
Menge von Attributen
Menge von funktionalen Abhängigkeiten (über R und U)
•
eine funktionale Abhängigkeit (functional dependency) ist eine Formel folgender Art:
X→Y
in Kurzform:
mit X ⊂ U, Y ⊂ U
als Menge von Horn-Klauseln: K = { K1,...,Kl }, wobei:
U = { A1,...,An }
X = { Ai1,...,Aik }
Y = { Aj1,...,Ajl }
für jedes Attribut Aje ∈ Y mit e = 1,...,l eine gleichheitsbestimmende Klausel:
Ke ≡ aje = a’je
:-
eine funktionale Abhängigkeit X → Y heißt
gültig in einer Relation r mit dom r = U
(oder r ist Instanz von X → Y)
:gdw
für alle Tupel µ,ν ∈ r: wenn µX = νX, dann auch µY = νY
•
eine Menge von funktionalen Abhängigkeiten F = { X1 → Y1, ... , Xp → Yp } heißt
gültig in einer Relation r mit dom r = U
:gdw
alle Xi → Yi aus F sind gültig in r
(oder r ist Instanz von F)
R (A1 : a1, ..., An : an) ,(AND)
R (A1 : a’1, ..., An : a’n) ,(AND)
ai1 = a’i1, ... , aik = a’ik .
(drückt aus, dass zwei auf den X-Attributen übereinstimmende Tupel aus (der Ausprägung zu)
R auch auf dem Attribut Aje übereinstimmen)
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
413
© Joachim Biskup, Universität Dortmund
funktionale Abhängigkeiten: Pragmatik
•
•
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
•
im vorgegebenen Relationenschema < R | U | F > wird als semantische Bedingungen
ausdrücklich vereinbart, welche funktionalen Abhängigkeiten gültig sein sollen
•
typischerweise die Formalisierung einer Modellierung der folgenden Art:
- ein durch die X-Werte identifiziertes Seiendes
bestimmt eindeutig die durch die Y-Werte beschriebenen Eigenschaften, bzw.
darüber hinaus sind in Instanzen von F im Allgemeinen noch weitere,
nicht ausdrücklich genannte funktionale Abhängigkeiten gültig
•
- ein durch die X-Werte identifiziertes Seiendes
steht mit genau einem durch die Y-Werte identifizierten Seienden in Beziehung
wir betrachten dann diejenigen funktionalen Abhängigkeiten,
die in allen Instanzen von F gültig sind:
•
•
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
414
logische Implikationen für funktionale Abhängigkeiten
mit einer funktionalen Abhängigkeit X → Y kann man als semantische Bedingung
verlangen, dass in den Instanzen zu einem Relationenschema
die X-Werte eines Tupels die Y-Werte eindeutig bestimmen sollen
© Joachim Biskup, Universität Dortmund
17. Juli 2003
17. Juli 2003
415
F impliziert (logisch) X → Y,
F |= X → Y
:gdw
für alle r mit dom r = U : wenn F in r gültig ist,
dann ist auch X → Y in r gültig
F+ := { X → Y | F |= X → Y }
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
416
Reflexivität, Transitivität und Erweiterung
•
•
Satz über die Korrektheit des Entscheidungsverfahrens für das
Implikationsproblem
folgende Implikationen sind für die Klasse der funktionalen Abhängigkeiten korrekt:
[Reflexivität]
für alle Y ⊂ X:
Ø |= X → Y
[Transitivität]
für alle X,Y, Z:
{ X → Y, Y → Z } |= X → Z
[Erweiterung]
für alle W ⊃ Z:
{ X →Y } |= X ∪ W → Y ∪ Z
hieraus einen Entscheidungsalgorithmus für das Problem “X → Y ∈ F ” gewinnen:
Abschluss (closure) einer Attributmenge X ⊂ U unter funktionalen Abhängigkeiten F,
cl (F, X), ist die (bezüglich ⊂ ) kleinste Menge mit den folgenden Eigenschaften:
1. X ⊂ cl (F, X)
für i+1:
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
417
die Behauptung, X → Xi+1∈ F+, prüfen anhand der Definition von “impliziert”:
sei r mit dom r = U eine Relation derart, dass:
F in r gültig
(1a)
insbesondere:
Ri → Si in r gültig
(1b)
gemäß Induktionsannahme:
X → Xi in r gültig
(2)
betrachte Tupel µ,ν ∈ r mit:
µX = νX
(3)
mit (3) wegen (2):
µXi = νXi
(4)
mit (4) wegen Ri ⊂ Xi:
µRi = νRi
(5)
mit (5) wegen (1b):
µSi = νSi
(6)
wegen Xi+1 = Xi ∪ Si besagen (4) und (6)
das für µ,ν zu Zeigende:
µXi+1 = νXi+1
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
betrachte: eine “Berechnung” von cl (F, X), d.h.
eine Folge von Attributmengen
und eine Folge von funktionalen Abhängigkeiten
X =: X0, ... , Xk := cl (F, X)
Ri → Si für i = 0,...,k-1 mit
Ri ⊂ Xi
Ri → Si ∈ F
Xi+1 = Xi ∪ Si.
X → Xi ∈ F+
durch Induktion über i:
für i = 0:
2. wenn R ⊂ cl (F, X) und R → S ∈ F, dann ist auch S ⊂ cl (F, X).
© Joachim Biskup, Universität Dortmund
Y ⊂ cl (F, X)
Beweis von 1.
+
erzeuge vermöge von F für X schrittweise alle Attribute A mit X → A ∈ F+
und prüfe, ob Y ganz in der Menge der so erzeugten Menge von Attribute enthalten ist
•
1. X → cl (F, X) ∈ F+
2. X → Y ∈ F+
genau dann, wenn
die Behauptung, X → X ∈ F+, ist gerade ein Spezialfall der Reflexivität
© Joachim Biskup, Universität Dortmund
Beweis von 2.
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
X → Y ∈ F+
17. Juli 2003
418
17. Juli 2003
420
genau dann, wenn Y ⊂ cl (F, X)
“⇐” [Korrektheit]:
17. Juli 2003
419
betrachte:
Y ⊂ cl (F, X)
(7)
gemäß 1.:
X → cl (F, X) ∈ F+
(8)
mit (7),(8), offensichtlich nach Definition:
X → Y ∈ F+
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
Wiederholung: Definition der Armstrong-Relation
Beweis von 2. X → Y ∈ F+
genau dann, wenn Y ⊂ cl (F, X)
“⇒” [Vollständigkeit in Kontraposition]:
Y ⊄ cl (F, X)
betrachte:
konstruiere Armstrong-Relation r
r enthalte genau zwei Tupel µ und ν:
(9)
mit
a) F in r gültig
b) X → Y in r nicht gültig
d.h. r ist ein Gegenbeispiel dafür, dass X → Y von F impliziert wird:
r enthalte genau zwei Tupel µ und ν:
(10)
ν(A) := 1
ν(A) := 0
falls A ∈ cl (F, X)
falls A ∉ cl (F, X)
(11)
(12)
r
cl(F, X)
U \ cl (F, X)
für alle A ∈ U
(10)
µ
1 ... 1
1 ... 1
ν(A) := 1
ν(A) := 0
falls A ∈ cl (F, X)
falls A ∉ cl (F, X)
(11)
(12)
ν
1 ... 1
0 ... 0
r
cl(F, X)
U \ cl (F, X)
µ
1 ... 1
1 ... 1
ν
1 ... 1
0 ... 0
ex. Attribut A0 ∈ Y \ cl (F, X),
µ verschieden von ν
also:
Eigenschaft b) ist erfüllt
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
zeige Eigenschaft a)
17. Juli 2003
421
betrachte:
funktionale Abhängigkeit Ri → Si aus F
angenommen, (für die einzigen zwei Tupel aus r):
µRi = νRi
nach Konstruktion von r:
Ri ⊂ cl (F, X)
nach Definition des Abschlusses:
Si ⊂ cl (F, X)
nach Konstruktion von r
das für µ,ν zu Zeigende:
µSi = νSi
© Joachim Biskup, Universität Dortmund
Beispiel
Abschluss cl(F, {Id, Arzt}) kann etwa wie folgt berechnet werden:
X0 = { Id, Arzt }
X1 = { Id, Geschlecht, Arzt }
vermöge
X2 = { Id, Geschlecht, DaPa, Arzt }
vermöge
X3 = { Id, Geschlecht, DaPa, Arzt, DaAr }
vermöge
X4 = { Id, Geschlecht, DaPa, Arzt, DaAr, ArtPro } vermöge
also:
{ Id, Arzt } → U ∈ F+
ferner:
cl (F, {Id}) = { Id, Geschlecht, DaPa }
cl (F, {Arzt}) = { Arzt, DaAr }
17. Juli 2003
422
anschaulich: minimale Attributmenge, deren Werte
ein Tupel innerhalb einer Ausprägung schon eindeutig bestimmen
formal:
<R|U|F>
Relationenschema
1. eine Menge von Attributen X ⊂ U heißt Schlüssel (key) von < R | U | F >
:gdw
1. [Eindeutigkeit]
X → U ∈ F+
2. [Minimalität]
für alle Y ⊂≠ X gilt: Y → U ∉ F+
Id → Geschlecht
Id → DaPa
Arzt → DaAr
Id,Arzt → ArtPro
2. ein Attribut A ∈ U heißt Schlüsselattribut von < R | U | F >
:gdw
es gibt einen Schlüssel X von < R | U | F > mit A ∈ X
3. ein Attribut A ∈ U heißt Nichtschlüsselattribut von < R | U | F >
:gdw
A kommt in keinem Schlüssel von < R | U | F > vor
insbesondere: Id → U ∉ F+
Arzt → U ∉ F+
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
formale Definition von “Schlüssel”
Schema:
U = { Id, Geschlecht, DaPa, Arzt, DaAr, ArtPro }
F = { Id → Geschlecht,
Id → DaPa,
Arzt → DaAr,
Id,Arzt → ArtPro }
© Joachim Biskup, Universität Dortmund
für alle A ∈ U
µ(A) := 1
nach (9), Voraussetzung:
damit nach Konstruktion:
© Joachim Biskup, Universität Dortmund
µ(A) := 1
17. Juli 2003
423
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
424
Beispiel
Relationenschemas mit genau einem Schlüssel
Schema:
U = { Id, Geschlecht, DaPa, Arzt, DaAr, ArtPro }
F = { Id → Geschlecht,
Id → DaPa,
Arzt → DaAr,
Id,Arzt → ArtPro }
schon gezeigt:
{ Id, Arzt } ein Schlüssel von < | U | F >
im Allgemeinen:
Beispiel:
ein Relationenschema kann mehrere Schlüssel besitzen
U = { A, B, C }
F = { A,B → C, C → B }
Relationenschema
ex (U,F) := { A | A ∈ U, U \ {A} → A ∉ F+ }
Menge der Extremalattribute
folgende Aussagen sind äquivalent:
1. < R | U | F > besitzt genau einen Schlüssel
{ Id, Arzt } → U ∈ F+
Id → U ∉ F+
Arzt → U ∉ F+
also:
<R|U|F>
2. ex (U,F) ist Schlüssel von < R | U | F >
3. ex (U,F) → U ∈ F+
Beweis: entfällt
- sowohl { A, B } als auch { A, C } sind Schlüssel
- alle Attribute sind Schlüsselattribute
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
425
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - funktionale Abhängigkeiten und Schlüssel
17. Juli 2003
426
3. Normalform und Boyce / Codd-Normalform
12.2 Normalformen und Schema-Transformationen
•
Formalisierung der Entwurfsheuristik “Trennung von Gesichtspunkten”
•
zeichnet diejenigen Relationenschemas aus, in denen
die linken Seiten aller (vereinbarten oder implizierten) funktionalen Abhängigkeiten
einen Schlüssel enthalten
die einzigen durch funktionale Abhängigkeiten ausdrückbaren Strukturen
innerhalb des Relationenschemas sind also gegeben
durch Schlüssel und die jeweils von ihnen funktional abhängigen Attribute
•
Definition
1. ein Relationenschema < R | U | F > heißt in 3.Normalform :
:gdw
für alle Z ⊂ U, für alle Nichtschlüsselattribute A ∈ U:
wenn Z → A ∈ F+ und A ∉ Z, dann Z → U ∈ F+
•
2. ein Relationenschema < R | U | F > heißt in Boyce / Codd-Normalform
:gdw
für alle Z ⊂ U, für alle A ∈ U:
wenn Z → A ∈ F+ und A ∉ Z, dann Z → U ∈ F+
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
427
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
428
Relationenschemas in Boyce / Codd-Normalform
• Boyce / Codd-Normalform ist offensichtlich eine Verschärfung von 3.Normalform,
weil für mehr Attribute (nämlich alle, einschließlich der Schlüsselattribute)
die Normalformeigenschaft gefordert wird
• das Beispiel < R | { A,B,C } | { A,B → C, C → B } > zeigt, dass die Verschärfung echt ist:
- in 3.Normalform, weil das Schema überhaupt keine Nichtschlüsselattribute besitzt
- nicht in Boyce / Codd-Normalform, weil C → B ∈ F ⊂ F+, aber C → A ∉ F+
• schärfere Eigenschaft der Boyce / Codd-Normalform eigentlich wünschenswert,
aber man muss sich manchmal mit der schwächeren Eigenschaft der 3.Normalform begnügen
• in einem Relationenschema in Boyce / Codd-Normalform können insbesondere
die beiden folgenden Situationen nicht auftreten:
- partielle Abhängigkeiten der Form:
X ist Schlüssel
Y ⊂≠ X, d.h. insbesondere Y → X ∉ F+
A ∉ Y und Y → A ∈ F+
(d.h. das Attribut A ist nur von einer echten Teilmenge des Schlüssels X funktional abhängig)
- transitive Abhängigkeiten der Form:
X → Y ∈ F+
Y → X ∉ F+
A ∉ Y und Y → A ∈ F+
(d.h. das Attribut A ist transitiv über Y von X abhängig,
ohne dass Y funktional äquivalent mit X ist)
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
•
Definition
ein Relationenschema < R | U | F > heißt in Boyce / Codd-Normalform
:gdw
für alle Z ⊂ U, für alle A ∈ U:
wenn Z → A ∈ F+ und A ∉ Z, dann Z → U ∈ F+
•
Satz
ein Relationenschema < R | U | F > ist in Boyce / Codd-Normalform
gdw
für alle X → Y ∈ F mit Y ⊄ X gilt: X → U ∈ F+
Bemerkung: es gibt also ein effizientes Entscheidungsverfahren:
man teste einfach die endlich vielen Elemente von F
auf die angegebene Eigenschaft
Beweis:
17. Juli 2003
429
entfällt
© Joachim Biskup, Universität Dortmund
Kostenarten beim Betreiben einer Datenbank
•
Speicherungskosten
•
Normalformen fordern Relationenschemas,
deren Struktur im Wesentlichen bereits durch Schlüssel,
am besten durch genau einen Schlüssel bestimmt sind
•
verwendet man solche Relationenschemas für Basisrelationen,
so kann man durch geeignet angelegte Zugriffsstrukturen, etwa
- als B*-Bäume oder durch Hash-Verfahren verwirklichte
Indexe bezüglich der Schlüsselattribute oder
- Sortierungen bezüglich der Schlüsselattribute,
die Anfragekosten für Selektionen an diese Relationen gering halten
•
ferner sind die Änderungskosten gering, da
- weitgehend nur die lokalen Schlüsselbedingungen überprüft werden müssen
Anfragekosten
entstehen bei der Auswertung von Anfragen;
im Allgemeinen erscheint Schätzung der Anfragekosten nur schwerlich möglich;
häufig jedoch kennt man die Wünsche bestimmter Benutzergruppen und
kann sie etwa als Sichtrelationen ausdrücklich vereinbaren
•
Änderungskosten
entstehen bei der Ausführung von Änderungen, wobei die
Überprüfung und Sicherstellung der semantischen Bedingungen zu berücksichtigen sind
•
430
die drei Kostenarten entsprechen den drei Darstellungsarten von Wissen:
Aufzählungen, (Sicht-)Regeln, Bedingungen
•
17. Juli 2003
Kosten und Normalformen
fallen im Wesentlichen durch das Speichern der Basisrelationen zum Datenbankschema an
•
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
zwischen den Kostenarten bestehen nun offensichtlich Wechselbeziehungen
- keine “Änderungs-Anomalien” auftreten
- “redundanzfreie Speicherung” vorliegt
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
431
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
432
Überlegung zur Redundanzfreiheit
Instanzenunterstützung
Definition
RS = < < R1 | X1 | SC1 >, ... , < Rn | Xn | SCn >
RS’ = < < R’1 | X’1 | SC’1 >, ... , < R’n' | X’n' | SC’n' >
seien Datenbankschemas
(3., Boyce/Codd und weitere) Normalformen besagen auch,
dass die gespeicherten Relationen im gewissen Sinne redundanzfrei sind und
dass damit die Speicherungskosten gering sind:
Beispielüberlegung für Schema < R | U | F > in Boyce / Codd-Normalform:
- betrachte eine nichttriviale funktionale Abhängigkeit Z → A: dann Z → U ∈ F+
- zerlege durch Projektion probeweise in Komponenten Y1 = Z ∪ {A} und Z ⊂ Y2 = X \ {A}
- beide Komponenten besitzen die Eindeutigkeitseigenschaft:
jede Projektion einer gespeicherten Relation r enthält genauso viele Tupel wie r,
d.h. || πY1 (r) || = || πY2(r) || = || r ||
würde man also r in diese Projektionen zerlegen,
so würden beim Wiederherstellen von r als r = πY1(r)
πY2(r)
[siehe später: stets möglich]
keine “wirklich neuen Tupel erzeugt”,
sondern die zusammenpassenden Tupel würden “einander nur verlängern”
| SC |
| SC’|
> und
>
1. RS’ unterstützt RS (mit Anfragesprache L)
:gdw
es gibt (in L ausdrückbare) relationale Anfragen Q1,...,Qn, so daß gilt:
i) Qi : sat << | X’1 | >,...,< | X’n' | > | | > → sat < | Xi | >
ii) die Anfrage Q : = (Q1,...,Qn) mit Q(f’) := (Q1(f’),...,Qn(f’))
ist surjektiv bezüglich Instanzen, d.h.
satRS ⊂ Q[satRS']
2. RS’ unterstützt RS treu,
wenn zusätzlich
Q[satRS'] ⊂ satRS
3. RS’ unterstützt RS eindeutig, wenn zusätzlich Q auf satRS' injektiv
durch das Zerlegen könnten die Speicherungskosten niemals gesenkt werden,
sondern im Gegenteil:
das mehrfache Abspeichern der Werte zu den Verbundattributen würde die Kosten stets erhöhen
umgekehrt: liegt keine Normalform vor, so gibt es ein Beispiel mit || πY1(r) || < || r ||
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
433
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
Instanzenunterstützung und Anfrageübersetzung
“⇒” Voraussetzung: RS’ unterstützt RS vermöge Q := (Q1,...,Qn)
eine Anfrage P bezüglich RS
zu zeigen:
P’ := P ° Q hat die gewünschte Eigenschaft
denn:
zu f ∈ satRS kann man wegen der Surjektivität von Q
ein f’∈ satRS' finden mit f = Q(f’), so dass
P(f) = P(Q(f’)) = P’(f’)
© Joachim Biskup, Universität Dortmund
17. Juli 2003
436
Universalrelation-Schema
Überdeckung der Attributmenge
Syntax:
[X1,...,Xn] heißt Verbundabhängigkeit
Semantik:
[X1,...,Xn] heißt gültig in einer Relation r mit dom r = U
r
Erinnerung:
es gibt zur identischen Anfrage P bezüglich RS mit P(f) := f
eine Anfrage Q bezüglich RS,
so dass für alle f ∈ satRS ein f’ ∈ satRS' existiert mit
f = P(f) = Q(f’), d.h. Q ist surjektiv bezüglich Instanzen
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
< R | U | SC >
U = ∪i=1,...,n Xi
(oder r ist Instanz von
:gdw
“⇐” Voraussetzung: die im Satz angegebene Übersetzungseigenschaft
insbesondere:
434
Verbundabhängigkeiten
Satz
1. RS’ unterstützt RS
gdw
zu jeder Anfrage P bezüglich RS gibt es eine Anfrage P’ bezüglich RS’ derart, dass:
zu jeder Instanz f ∈ satRS gibt es eine Instanz f’ ∈ satRS' mit P(f) = P’(f’)
Beweis:
betrachte:
17. Juli 2003
=
i=1,...,n πXi (
[X1,...,Xn])
r)
“⊂” gilt immer!
Implikationen: entsprechend wie für funktionale Abhängigkeiten definiert;
es gibt Entscheidungsverfahren
17. Juli 2003
435
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
Verbund-Unterstützung eines Universalrelation-Schemas
Satz
< R | U | SC >
RS = < < R1 | X1 | Ø >,..., < Rn | Xn | Ø > | Ø | >
“sat< R | U | SC > ⊂ Q[satRS]” ⇒ “
grundlegende Eigenschaft des Verbunds:
für alle (r1,...,rn) ∈ satRS:
i=1,...,n ri =
j=1,...,n πXj (
Universalrelation-Schema
Datenbankschema
U := ∪i=1,...,n Xi
Q : satRS → sat< R | U | >
Q(r1,...,rn) :=
i=1,...,n ri
Überdeckung
Verbund-Anfrage
wegen sat< R | U | SC > ⊂ Q[satRS]:
1. sat< R | U | SC > ⊂ Q[satRS],
d.h. RS unterstützt < R | U | SC > mit Unterstützungsanfrage Q
“
r ∈ sat< R | U | SC >
wegen [X1,...,Xn] ∈
SC+:
Beweis:
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
437
Verbund-Unterstützung eines Universalrelation-Schemas mit
funktionalen Abhängigkeiten
Satz
<R|U|F>
F
RS = < < R1 | X1 | Ø >, < R2 | X2 | Ø > | Ø | >
X1 ∪ X2 = U und X1 ∩ X2 ≠ Ø
oder
17. Juli 2003
438
Dann gibt es ein Datenbankschema
RS = < < R1 | X1 | F1 >,...,< Rn | Xn | Fn > | | > mit folgenden Eigenschaften:
1.
RS unterstützt < R | U | F > mit Unterstützungsanfrage Q(r1,...,rn) :=
2.
3.
Fi = {X → Y | X ∪ Y ⊂ Xi, X → Y ∈
jede Komponente < Ri | Xi | Fi > ist in Boyce / Codd-Normalform
i=1,...,n ri.
F+}
r2
[X1,X2] ∈ F+
3. X1 ∩ X2 → X1 \ X2 ∈ F+
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
Satz
< R | U | F > Universalrelation-Schema mit
F
funktionale Abhängigkeiten
Dann sind folgende Aussagen äquivalent:
2.
© Joachim Biskup, Universität Dortmund
Verbund-unterstützte Zerlegung in Boyce / Codd-Normalform
Universalrelation-Schema
funktionale Abhängigkeiten
Datenbankschema mit
1. RS unterstützt < R | U | F > mit Unterstützungsanfrage Q(r1,r2) := r1
r =
i=1,...,n πXi (r) = Q(πX1(r),...,πXn(r)),
wobei (πX1(r),...,πXn(r)) ∈ satRS
sat< R | U | SC > ⊂ Q[satRS]
also:
© Joachim Biskup, Universität Dortmund
[X1,...,Xn] ∈ SC+
[X1,...,Xn] ∈ SC+” ⇒ “sat< R | U | SC > ⊂ Q[satRS]”:
betrachte:
[X1,...,Xn] ∈ SC+
i=1,...,n ri)
alle Relationen r ∈ Q[satRS] erfüllen die
Verbundabhängigkeit
[X1,...,Xn]
also:
Dann sind folgende Aussagen äquivalent:
2.
[X1,...,Xn] ∈ SC+”:
(konstruktiver, induktiver) Beweis:
X1 ∩ X2 → X2 \ X1 ∈ F+
Idee:
zerlege Schema schrittweise,
bis alle “verbotenen Teilstrukturen” entfernt sind
Beweis: entfällt
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
439
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
440
zu erreichen:
1. RS unterstützt < R | U | F > mit Unterstützungsanfrage Q(r1,...,rn) :=
2.
3.
Beispiel für Zerlegung in Boyce / Codd-Normalform
i=1,...,n ri.
U
F
Fi = {X → Y | X ∪ Y ⊂ Xi, X → Y ∈ F+}
jede Komponente < Ri | Xi | Fi > ist in Boyce / Codd-Normalform
Induktionsbeginn:
RS0 := < < R | U | F+> | | > erfüllt sicherlich die Eigenschaften 1. und 2.
Induktionsschritt:
dann:
RSj sei schon konstruiert, erfülle 1. und 2., aber noch nicht 3.
es gibt “verbotene” Komponente < Ri | Xi | Fi > von RSj mit
Z ⊂ Xi, A ∈ Xi, Z → A ∈
F+,
A ∉ Z, Z → Xi ∉
zerlege in zwei Komponenten mit Attributmengen:
Xi1 := Z ∪ {A | Z → A ∈ F+} und
< |U|F>
Arzt → DaAr
F+
Xi2 :=
Z ∪ ( Xi \ Xi1)
Definition von RSj+1: ersetze die alte Komponente < Ri | Xi | Fi > durch die neuen Komponenten
< Ri1 | Xi1 | Fi1 > und < Ri2 | Xi2 | Fi2 >,
definiere dabei Fi1 und Fi2 gemäß 2.
nach Konstruktion:
RSj+1 erfüllt wieder 1. und 2.
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
nicht in Boyce / Codd-Normalform:
“verbotene Teilstruktur”
entsprechend zerlegen:
< R1 | {Arzt, DaAr}
| { Arzt →DaAr } >
< R2 | {Id, Geschlecht, DaPa, Arzt, ArtPro} | {Id →Geschlecht, Id → DaPa, Id,Arzt →ArtPro}>
zweites Relationenschema nicht in Boyce / Codd-Normalform:
Id → DaPa
“verbotene Teilstruktur”
entsprechend zerlegen:
< R21 | {Id, Geschlecht, DaPa} | { Id → Geschlecht, Id → DaPa }
< R22 | {Id, Arzt, ArtPro}
| { Id,Arzt →ArtPro }
Zerlegungsvorgang bricht ab: - U ist endlich
- Xi1 und Xi2 der neuen Komponenten
sind jeweils echte Teilmengen von Xi der alten Komponente
© Joachim Biskup, Universität Dortmund
:= { Id, Geschlecht, DaPa, Arzt, DaAr, ArtPro }
:= { Id → Geschlecht,
Id → DaPa,
Arzt → DaAr,
Id,Arzt → ArtPro}
>
>
die durch R1, R21 und R22 benannten Relationenschemas sind alle in Boyce / Codd-Normalform
441
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
Boyce / Codd-Normalform und treue Unterstützung
17. Juli 2003
442
treue Zerlegungen
Satz
<R|U|F>
RS = < < R1 | X1 | F1 >,..., < Rn | Xn | Fn > | | >
< R | {A, B, C} | { A,B → C, C → B} > nicht in Boyce / Codd-Normalform:
C→B
verbotene Teilstruktur
∪i=1,...,n Xi
(versuchsweise) entsprechend zerlegen:
< R1 | {B, C} | { C → B } >
< R2 | {A, C} | Ø >
=
U
F und F1,...,Fn
Mengen von funktionalen Abhängigkeiten
Q : satRS → sat< R | U | > mit
Beobachtungen:
• im ursprünglichen Relationenschema vereinbarte funktionale Abhängigkeit A,B → C
kann in der Zerlegung nicht mehr “repräsentiert” werden
• man kann eine Beispielinstanz (r1,r2) zu der Zerlegung konstruieren,
Universalrelation-Schema und
Datenbankschema mit
Q(r1,...,rn) :=
i=1,...,n ri
Verbund-Anfrage
∪i=1,...,n Fi )+ ⊃ F,
Wenn
(
dann
Q[satRS] ⊂ sat< R | U | F > .
deren Verbund keine Instanz des Universalrelation-Schemas ist:
r1
B
C
b
b
c
d
r2
A
C
a
a
c
d
r1
r2
A
B
C
a
a
b
b
c
d
• man kann nachprüfen, dass auch keine andere Zerlegung
gleichzeitig Relationenschemas in Boyce / Codd-Normalform und treue Unterstützung liefert
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
443
Beweis:
betrachte:
(r1,...,rn) ∈ satRS und r :=
wir zeigen unten:
alle funktionalen Abhängigkeiten X → Y ∈ ∪i=1,...,n Fi sind in r gültig
dann ebenfalls:
alle funktionalen Abhängigkeiten aus ( ∪i=1,...,n Fi )+ in r gültig
nach Voraussetzung:
alle funktionalen Abhängigkeiten aus F in r gültig
also:
r ∈ sat< R | U | F >
© Joachim Biskup, Universität Dortmund
i=1,...,n
ri
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
444
alle funktionalen Abhängigkeiten X → Y ∈ ∪i=1,...,n Fi sind in r gültig
noch zu zeigen:
betrachte:
X → Y ∈ Fi,
insbesondere gilt:
X ∪ Y ⊂ Xi.
betrachte:
zwei Tupel µ ∈ r und ν ∈ r mit µX = νX
Definition von r:
µi := µXi ∈ ri und νi := νXi ∈ ri
ferner:
µiX = νiX.
wegen X → Y in ri gültig:
µiY = νi Y
also auch:
µY = νY
© Joachim Biskup, Universität Dortmund
treue Verbund-Unterstützung eines Universalrelation-Schemas mit
funktionalen Abhängigkeiten
Korollar
<R|U|F>
RS = < < R1 | X1 | F1 >,...,
∪i=1,...,n Xi = U
F und F1,...,Fn
Wenn
Überdeckung
Mengen von funktionalen Abhängigkeiten
[X1,...,Xn] ∈ F+ und ( ∪i=1,...,n Fi )+ ⊃ F,
dann unterstützt RS das Universalrelation-Schema < R | U | F >
treu mit Anfrageunterstützung Q(r1,...,rn) :=
i=1,...,n ri .
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
445
© Joachim Biskup, Universität Dortmund
RS unterstützt < R | U | F > treu mit Unterstützungsanfrage Q(r1,...,rn) :=
2.
3.
Fi = {X → Y | X ∪ Y ⊂ Xi, X → Y ∈
jede Komponente < Ri | Xi | Fi > in 3.Normalform
i=1,...,n ri
konstruktive Beweisidee:
• bestimme zur gegebenen Menge F von funktionalen Abhängigkeiten eine dazu
äquivalente Menge G mit F+ = G+ derart, dass G in gewissem Sinne redundanzfrei ist
• dann “synthetisiere” für die funktionalen Abhängigkeiten aus G Relationenschemas,
die die redundanzfreien funktionalen Abhängigkeiten “repräsentieren”
• sichere Verbund-Unterstützung,
indem ein Relationenschema mit Schlüssel K für die gesamte Attributmenge U hinzufügt wird,
falls keines der “synthetisierten” Relationenschemas schon einen solchen Schlüssel enthält
17. Juli 2003
446
X’ ⊂ X mit X’ → A ∈ G+
und ersetze, falls X’ ⊂≠ X, X → A durch X’ → A
3. [entferne globale Redundanz]
für X → A ∈ G prüfe, ob X → A ∈ (G \ {X → A})+;
falls dies der Fall ist, so entferne X → A aus G
4. [“synthetisiere” Relationenschemas, “repräsentiere” F]
SollG := { X | es gibt A ∈ U mit X →A ∈ G } die Menge der in G vorkommenden linken Seiten
für Yi ∈ SollG bilde ein Relationenschema < Ri | Xi | Fi > mit
Xi := Yi ∪ { A | Yi → A ∈ G }
F+}
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
1. [mache funktionale Abhängigkeiten elementar]
setze G := {X → A | es gibt X → Y ∈ F mit A ∈ Y}
d.h. ersetze X → {A1,...,Ak} ∈ F
durch
X → A1, ... , X → Ak
2. [entferne lokale Redundanz]
für X → A ∈ G bestimme eine (bezüglich ⊂) minimale Attributmenge
es gibt ein Datenbankschema RS = < < R1 | X1 | F1 >,...,< Rn | Xn | Fn > | | > derart, dass:
1.
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
Syntheseverfahren
Universalrelation-Schema
funktionale Abhängigkeiten
© Joachim Biskup, Universität Dortmund
Universalrelation-Schema
Datenbankschema mit
Fi+ ⊂ {R → S | R ∪ S ⊂ Xi, R → S ∈ F+}
treue und Verbund-unterstützende Synthese in 3.Normalform
Satz
<R|U|F>
F
< Rn | Xn | Fn > | | >
447
Fi := { X → Y | X ∪ Y ⊂ Xi, X → Y ∈ G+ } ⊃ { Yi → A | Yi → A ∈ G }
5. [Verbund-Unterstützung]
prüfe, ob für ein Yi ∈ SollG die funktionale Abhängigkeit Yi → U ∈ G+ gilt;
falls dies nicht der Fall ist, so bestimme einen Schlüssel K von < R | U | F > und
bilde ein weiteres Relationenschema mit Xi := K und Fi := Ø
© Joachim Biskup, Universität Dortmund
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
448
Beispiel für Syntheseverfahren
Eingaben:
U
F
=
=
{ Id, Geschlecht, DaPa, Arzt, DaAr, ArtPro }
{ Id → Geschlecht,
Id → DaPa,
Arzt → DaAr,
Id,Arzt → ArtPro }
Teil V
Schritte 1, 2 und 3:
G = F
(die vereinbarten funktionalen Abhängigkeiten bleiben unverändert)
Schritt 4:
SollG = {Id, Arzt, {Id, Arzt}},
und es werden folgende Relationenschemas “synthetisiert”:
Mehrbenutzerbetrieb und Transaktionen
< R1 | {Id, Geschlecht, DaPa} | { Id → Geschlecht, Id → DaPa } >
< R2 | {Arzt, DaAr}
| { Arzt → DaAr }
>
< R3 | {Id, Arzt, ArtPro}
| { Id,Arzt → ArtPro }
>
Schritt 5:
© Joachim Biskup, Universität Dortmund
cl(F, {Id, Arzt}) = U,
so dass kein weiteres Relationenschema hinzugeführt werden muss
Informationssysteme: relationaler Schemaentwurf - Normalformen und Schema-Transformationen
17. Juli 2003
449
© Joachim Biskup, Universität Dortmund
Informationssysteme
17. Juli 2003
450
Transaktionen: einige Vorüberlegungen
13 Transaktionen
•
nicht nur einzelne Handlungen, sondern auch (formale) Handlungsfolgen
•
semantische Bedingungen (als statische Gesichtspunkte)
auch als dynamische Gesichtspunkte:
- Aufzählungen nur derart ändern,
dass anschließend die semantischen Bedingungen wieder erfüllt sind
- bei Änderungswünschen bezüglich mehrerer Objekte oder bei interrelationalen Bedingungen,
neben der eigentlich gewünschten Änderung
auch noch Folgeänderungen notwendig;
möglicherweise werden die Bedingungen zwischenzeitlich verletzt
- Änderungsfolgen als unteilbare Operationen,
die entweder gar nicht oder vollständig ausgeführt werden
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
451
Daten für viele und verschiedenartige Benutzer verfügbar halten:
diese arbeiten im Allgemeinen parallel und möglichst unabhängig voneinander
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
452
Parallelität und Unabhängigkeit: ein Beispiel
Datenbankobjekt:
dessen A-Komponente durch Programm bearbeiten:
R
P ≡
eine parallele Nutzung eines gemeinsamen Informationssystems
BEGIN
Read R.A;
R.A := R.A + 1;
Write R.A
END
zwei Benutzer starten parallel und unabhängig voneinander
jeweils einen das Programm P ausführenden Prozess:
Q1 bzw. Q2
Prozess Qi benutzt lokalen Speicher:
Zi
erhöhe
lokaler Speicher
Z1 von Q1
erhöhe
lokaler Speicher
Z2 von Q2
schreibe
lies
lies
schreibe
Semantik des Programms:
- lies A-Komponente des Objekts R im gemeinsamen Informationssystem
und merke den Wert im lokalen Speicher des Prozesses:
Zi := R.A ;
- erhöhe diesen Wert im lokalen Speicher um 1:
- schreibe den neuen Wert zurück in die A-Komponente
des Objekts R im gemeinsamen Informationssystem:
© Joachim Biskup, Universität Dortmund
Zi
:=
gemeinsames
Informationssystem
mit dauerhaften
Werten
Zi + 1 ;
Objekt R
R.A :=
Zi .
Informationssysteme: Transaktionen
17. Juli 2003
453
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
eine unerwünschte sequentielle Ausführung
Anweisung für Prozeß
Q1
ausgeführte
Semantik
Read R.A
Read R.A
3
4a R.A := R.A+1
- bei schwierigen Fehlerlagen oder
- gar vollständigen Systemzusammenbrüchen
10
— —
ihre Gültigkeit behalten.
Z1 := R.A
10
10 —
Z2 := R.A
10
10 10
Z1 := Z 1 + 1
10
11
4b
R.A := R.A+1
Z2 := Z 2 + 1
5
6
Write R.A
R.A := Z 2
11
11 11
R.A := Z 1
11
11 11
Write R.A
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
456
insbesondere:
einmal als wirksam erklärte Änderungen der gemeinsamen Daten sollen auch
Wertverlauf im
lokalen
gemeinsamen
Informationssystem Speicher
Z1 Z2
1
2
Informationssysteme sollen Daten dauerhaft und verlässlich verwalten,
R.A
Q2
454
eine weitere Vorüberlegung
•
Zeit
17. Juli 2003
11
17. Juli 2003
455
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
Transaktionen
•
programmiersprachliches Konstrukt zur Unterstützung der Vorüberlegungen
•
fasst eine Folge von Anweisungen zu einer Einheit zusammen
•
durch ein geeignetes Klammerpaar syntaktisch gekennzeichnet, etwa
ACID- Eigenschaften
•
Atomarität
•
Consistenzbewahrung
BEGIN_TRANS und END_TRANS
•
(atomicity)
im Sinne von Unteilbarkeit
(consistency preservation),
im Sinne von Erhaltung der semantischen Bedingungen
semantisch sollen folgende Eigenschaften erreicht werden:
•
Isolation
- Transaktionen erhalten die semantischen Bedingungen
(isolation)
im Sinne von Unabhängigkeit
- Transaktionen können parallel ablaufen
•
Dauerhaftigkeit
(durability)
insbesondere im Sinne von Fehlertoleranz
- parallel ablaufende Transaktionen sind im Wesentlichen
voneinander unabhängig und
beeinflussen einander allenfalls in genau vorhersehbarer Weise
- Transaktionen sind unteilbar, d.h. werden gar nicht oder vollständig wirksam
- wirksam gewordene Transaktionen verändern Daten dauerhaft
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
457
Transaktionen erhalten Bedingungen
•
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
458
17. Juli 2003
460
Datenebenen und Wirksamwerden: einfachstes Modell
Benutzer muss dies im Allgemeinen durch
sorgfältigen Entwurf der Transaktionen erreichen
bearbeite
lokale Daten
Informationssystem unterstützt dabei durch programmiersprachliche Konstrukte:
- Meldungen über den Erhalt bzw. die Verletzung von Bedingungen bei Änderungen,
wobei bei Verletzung der Bedingungen eine Liste der betroffenen Objekte geliefert wird,
etwa Affected(objekt_liste)
schreibe
zwischenzeitliche Kopien
lies
- Anweisung zum vorzeitigen Abbruch einer Transaktion,
die die gesamte Transaktion gar nicht wirksam werden lässt,
etwa Abort_Trans
commit
- Anweisung zum vollständigen Wirksamwerden einer Transaktion,
etwa Commit_Trans
dauerhafte Daten
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
459
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
Beispiele mit Bearbeitung von zwei Objekten/Folgeänderungen
PROCEDURE
PROCEDURE Ändere_mit_Folgeänderungen(objekt_1 : Objekt);
VAR
betroffen
: Objekt;
auswirkungen : Objekt_Liste;
BEGIN
BEGIN_TRANS
(*Transaktion wird gestartet*)
Ändere_zwei_Objekte(
objekt_1, objekt_2 : Objekt);
BEGIN
BEGIN_TRANS
Read(objekt_1);
Read(objekt_2);
Read(objekt_1); Bearbeite(objekt_1); Write(objekt_1);
(*Transaktion wird gestartet*)
IF Bedingungen erfüllt
THEN Commit_Trans
(*Änderung wirksam*)
ELSE FORALL betroffen in Affected(auswirkungen) DO
Read(betroffen);
Bearbeite_Folgen(betroffen);
Write(betroffen)
END_FORALL;
IF Bedingungen erfüllt
THEN Commit_Trans (*alle Änderungen wirksam*)
ELSE Abort_Trans (*keine Änderung wirksam*)
END_IF
END_IF
END_TRANS
(*Transaktion wird beendet*)
END Ändere_mit_Folgeänderungen;
Bearbeite(objekt_1, objekt_2);
Write(objekt_1);
Write(objekt_2);
IF Bedingungen erfüllt
THEN Commit_Trans (*beide Änderungen werden wirksam*)
ELSE Abort_Trans (*keine Änderung wird wirksam*)
END
END_TRANS
(*Transaktion wird beendet*)
END Ändere_zwei_Objekte;
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
461
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
Transaktionen laufen parallel und voneinander unabhängig ab
•
muss im Allgemeinen durch das Informationssystem selbst durchgesetzt werden
•
von den Benutzern wird gegebenenfalls verlangt,
dass ihre Transaktionen einen vorgeschriebenen Aufbau (Protokolle) einhalten
•
17. Juli 2003
462
zwei Randfälle
Scheduler kann die Transaktionen beliebig ineinander verschränkt mischen:
- einfache Verwirklichung derart, dass
die Anweisungen in der Reihenfolge angeordnet bleiben,
wie sie angefordert werden
- Scheduler im Wesentlichen nur Warteschlange für Anweisungen
- einerseits hohe Parallelität
der Scheduler hat dann die Aufgabe,
die Anweisungen von parallel auszuführenden Transaktionen
in einer geeigneten Reihenfolge anzuordnen
- andererseits große Unsicherheit über die wechselseitige Beeinflussung der Transaktionen
Scheduler ordnet die Transaktionen als Ganzes seriell an:
- einfache Verwirklichung derart, dass
die Transaktionen in der Reihenfolge angeordnet werden,
wie sie angefordert werden
- Scheduler im Wesentlichen nur Warteschlange für Transaktionen
- einerseits im Wesentlichen keine Parallelität
- andererseits wechselseitige Beeinflussung der Transaktionen genau vorhersehbar
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
463
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
464
korrekte Reihenfolgen und Serialisierbarkeit
Anweisungen, Transaktionen, Pläne
um die Vorteile der beiden Randfälle möglichst gut gleichzeitig zu erreichen,
sollen folgende Reihenfolgen als korrekt (geeignet) definiert werden:
K1. [sichere Vorhersehbarkeit]
eine Reihenfolge,
die durch beliebige serielle Anordnung der Transaktionen als Ganzes entsteht,
sei korrekt
Menge von Operatoren (Aktionen):
A
Menge von Objekten:
O
Menge der Anweisungen:
S := A × O
Menge der Transaktionen:
T := { t | t : {1,...,n} → S , t ist injektiv }
Plan (schedule) zu T:
K2. [erlaubte Parallelität]
jede Reihenfolge,
deren Auswirkung (unter den jeweils getroffenen Annahmen)
ununterscheidbar von der Auswirkung einer nach K1 korrekten Reihenfolge ist,
sei ebenfalls korrekt
für eine Menge von Transaktionen T = {t1,...,tk} mit ti = (ti.1,..., ti.ni)
eine Funktion
P: { 1, ... ,n1+...+nk } ----> { i.j | 1≤i≤k, 1≤j≤ni }
mit
- P ist bijektiv
- für alle i, für alle j1, j2 gilt :
j1 < j2 ⇔ P-1 (i.j1) < P-1 (i.j2)
in Praxis und Theorie:
verschiedene Annahmen und Auswirkungen führen
zu verschiedenen Begriffen von Korrektheit bzw. Serialisierbarkeit
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
465
Schreibweisen
=
=
=
=
( ti.1
, ... , ti.ni
)
(
Opi.1 oi.1 , ... ,
Opi.ni oi.ni)
( 1: Opi.1 oi.1 , ... , ni: Opi.ni oi.ni)
( i.1:Opi.1 oi.1 , ... , i.ni: Opi.ni oi.ni)
t1 := ( 1.1: Read A,
1.2: Write C,
1.3: Write B )
mit ti.j ist j-te Anweisung von ti
mit ti.j = (Opi.j oi.j), Opi.j ∈ A, oi.j ∈ O
für
i.j : Opi.j oi.j bezeichnet also:
i
eine Transaktion ti
j
eine bezüglich der Transaktion ti lokale Anweisungsnummer
Opi.j
die auszuführende Operation
oi.j
das betroffene Objekt
Notation für Pläne:
P = ( p1
, ... , pm )
= ( tp_1
, ... , tp_m )
=
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
t2 := ( 2.1: Read A,
2.2: Read B,
2.3: Write D )
A
mit m = n1+...+nk, pl := il.jl := P(l)
mit tp_l= ti_l.j_l = Opi_l.j_l oi_l.j_l
ist jl-te Anweisung der il-ten Transaktion
( i_1.j_1:Opi_1.j_1 oi_1.j_1, ... , i_m.j_m:Opi_m.j_m oi_m.j_m )
Definitionsbereich von P:
Informationssysteme: Transaktionen
17. Juli 2003
466
Plan P zu Transaktionen T = { t1, t2, t3, t4 } mit “Datenflüssen”
Notation für Transaktionen (und ihre Komponenten):
ti
© Joachim Biskup, Universität Dortmund
beschreibt die Zeitpunkte,
zu denen die einzelnen Anweisungen ausgeführt werden
17. Juli 2003
467
2.1:
1.1:
1.2:
3.1:
1.3:
4.1:
4.2:
2.2:
3.2:
4.3:
2.3:
4.4:
t3 := ( 3.1: Read C,
3.2: Write A )
B
C
t4 := ( 4.1: Read B,
4.2: Read C,
4.3: Write B,
4.4: Write A )
D
Read A,
Read A,
Write C,
Read C,
Write B,
Read B,
Read C,
Read B,
Write A,
Write B,
Write D,
Write A,
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
468
Read/Write-Modell
Read/Write-Modell: Annahme A1*/A2
A1*. Im Operationsteil einer Anweisung seien nur die Operatoren Read und Write erlaubt.
•
betrachtet das Lesen und Schreiben von Daten als getrennte Aktionen
•
nimmt an, dass im lokalen Speicher alle jemals gelesenen Werte gemerkt werden
•
beruht auf einer Reihe von Annahmen
beabsichtigte Semantik von Read:
die Daten aus dem im Operandenteil bezeichneten Objekt
werden in den lokalen Speicher des die Transaktion ausführenden Prozesses gelesen
beabsichtigte Semantik von Write:
die Daten des im Operandenteil bezeichneten Objekts
werden überschrieben mit (möglicherweise) neuen Werten,
die sich aus der Verarbeitung aller vorher gelesenen Daten ergeben können
A2.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
469
Weitere Einzelheiten der Semantik, insbesondere über die Art der Verarbeitung
seien nicht bekannt.
© Joachim Biskup, Universität Dortmund
Read/Write-Modell: Annahme A3*
Informationssysteme: Transaktionen
17. Juli 2003
470
Read/Write-Modell: Annahme A4/A5/A6
A3*. Nachdem eine Read-Anweisung ausgeführt ist,
bleiben die gelesenen Daten zeitlich unbegrenzt und unverändert
im lokalen Speicher verfügbar;
A4.
Alle Objekte seien unstrukturiert und stehen in keinerlei Beziehung zueinander.
A5.
Alle Transaktionen werden vollständig wirksam.
A6.
Alle Transaktionen liegen als unverzweigte Anweisungsfolgen textuell als Ganzes vor.
entsprechend liest eine Transaktion aus jedem Objekt höchstens einmal;
ferner schreibe eine Transaktion in jedes Objekt höchstens einmal
(nach Abschluss aller Verarbeitungen);
wenn eine Transaktion ein Objekt sowohl liest als auch schreibt,
so gehe das Lesen dem Schreiben voran.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
471
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
472
Read/Write-Modell
A1*. Im Operationsteil einer Anweisung seien nur die Operatoren Read und Write erlaubt.
14 Serialisierbarkeit und Versionsverwaltung
beabsichtigte Semantik von Read: die Daten aus dem im Operandenteil bezeichneten Objekt
werden in den lokalen Speicher des die Transaktion ausführenden Prozesses gelesen
beabsichtigte Semantik von Write: die Daten des im Operandenteil bezeichneten Objekts
werden überschrieben mit (möglicherweise) neuen Werten,
die sich aus der Verarbeitung aller vorher gelesenen Daten ergeben können
14.1 Konflikte und Konflikt-Serialisierbarkeit
A2. Weitere Einzelheiten der Semantik, insbesondere über die Art der Verarbeitung seien nicht bekannt.
A3*. Nachdem eine Read-Anweisung ausgeführt ist, bleiben die gelesenen Daten
zeitlich unbegrenzt und unverändert im lokalen Speicher verfügbar;
entsprechend liest eine Transaktion aus jedem Objekt höchstens einmal;
ferner schreibe eine Transaktion in jedes Objekt höchstens einmal (nach Abschluss aller Verarbeitungen);
wenn eine Transaktion ein Objekt sowohl liest als auch schreibt, so gehe das Lesen dem Schreiben voran.
A4. Alle Objekte seien unstrukturiert und stehen in keinerlei Beziehung zueinander.
A5. Alle Transaktionen werden vollständig wirksam.
A6. Alle Transaktionen liegen als unverzweigte Anweisungsfolgen textuell als Ganzes vor.
© Joachim Biskup, Universität Dortmund
Informationssysteme: Transaktionen
17. Juli 2003
473
Konflikte
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
17. Juli 2003
474
Konflikt-Äquivalenz von Read/Write-Plänen, KonfliktSerialisierbarkeit
zwei Transaktionen liegen im Konflikt,
wenn sie ein Objekt o gemeinsam nutzen,
wobei mindestens eine der Transaktionen in o schreibt
1. Sei T = {t1,...,tk} eine Menge von Transaktionen.
Zwei das gleiche Objekt o nutzende Anweisungen aus T, i1.j1 : Op1 o und i2.j2 : Op2 o
liegen (wegen o) im Konflikt :gdw
i1 ≠ i2 und
Op1 = Write oder Op2 = Write.
für eine Menge von Transaktionen T
kann man alle Konflikte im obigen Sinne bestimmen
für einen Plan P
kann man jeweils die Reihenfolge der im Konflikt liegenden Transaktionen bestimmen
Aufgaben zur Konfliktbehandlung
2. Seien P und P’ Read/Write-Pläne zu einer Menge von Transaktionen T.
P ist Konflikt-äquivalent zu P’ :gdw
je zwei im Konflikt liegende Anweisungen werden in P und P’
in der gleichen Reihenfolge ausgeführt.
3. Ein Read/Write-Plan P zu einer Menge von Transaktionen T ist
Konflikt-serialisierbar
:gdw
es gibt einen Read/Write-Plan P’, so dass gilt:
gegeben ein Plan P, suche nach einem seriellen Plan P’,
der alle Konflikte genauso wie P behandelt
falls ein solcher Plan P’ existiert,
wird der Plan P als “korrekt bezüglich der Behandlung von Konflikten” angesehen
(K1) P’ ist serieller Read/Write-Plan.
(K2) P und P’ sind Konflikt-äquivalent.
erzeuge solchermaßen “korrekten” Pläne
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
17. Juli 2003
475
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
17. Juli 2003
476
Konfliktgraphen
Satz über Test für Konflikt-Serialisierbarkeit
um festzustellen, ob
ein Read/Write-Plan P zu einer Menge von Transaktionen T = {t1,...,tk} Konflikt-serialisierbar ist,
konstruieren wir einen Konfliktgraphen Gkonflikt (P) = (Ekonflikt, Kkonflikt ) :
Sei P ein Read/Write-Plan zu einer Menge von Transaktionen T = {t1,...,tk} und
Gkonflikt (P) = ( T, Kkonflikt ) der zugehörige Konfliktgraph.
Dann gilt:
Eckenmenge
Kantenmenge
1.
P ist Konflikt-serialisierbar
genau dann, wenn
Gkonflikt (P) ist azyklisch.
2.
Ist Gkonflikt (P) azyklisch und
ist P’ ein serieller Read/Write-Plan,
der durch topologisches Sortieren aus Gkonflikt gewonnen wird,
so sind P und P’ Konflikt-äquivalent.
Ekonflikt :=
Kkonflikt :=
T
{ (ti1, ti2) | ti1 ≠ ti2, und
es gibt o ∈ O(T), j1, j2:
ti1.j1 = Op1 o und
Op1 = Write
oder
ti2.j2 = Op2 o,
Op2 = Write,
P-1 (i1.j1) < P-1 (i2.j2) }
und
es geht also eine Kante von Transaktion ti1 nach Transaktion ti2,
wenn ti1 eine Anweisung enthält,
die zu einer in P folgenden, aus ti2 stammenden Anweisung
im Konflikt liegt
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
17. Juli 2003
477
© Joachim Biskup, Universität Dortmund
Beispiel zum Test: Transaktionen und Konflikte
Transaktionen:
Plan P mit “Datenflüssen”:
t2 := ( 2.1: Read A,
2.2: Read B,
2.3: Write D )
t3 := ( 3.1: Read C,
3.2: Write A )
t4 := ( 4.1: Read B,
4.2: Read C,
4.3: Write B,
4.4: Write A )
1.1: Read A
1.1: Read A
2.1: Read A
2.1: Read A
3.2: Write A
und
und
und
und
und
3.2: Write A
4.4: Write A
3.2: Write A
4.4: Write A
4.4: Write A
wegen Objekt B:
1.3: Write B
1.3: Write B
1.3: Write B
2.2: Read B
und
und
und
und
2.2: Read B
4.1: Read B
4.3: Write B
4.3: Write B
wegen Objekt C:
1.2: Write C
1.2: Write C
und
und
3.1: Read C
4.2: Read C
wegen Objekt D:
keine Konflikte
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
478
A
B
C
17. Juli 2003
480
D
2.1: Read A,
1.1: Read A,
1.2: Write C,
3.1: Read C,
1.3: Write B,
4.1: Read B,
4.2: Read C,
2.2: Read B,
3.2: Write A,
4.3: Write B,
2.3: Write D,
4.4: Write A,
In T liegen folgende Anweisungen im Konflikt:
wegen Objekt A:
17. Juli 2003
Beispiel zum Test: Plan und Konfliktgraph
T = {t1, t2, t3, t4} mit
t1 := ( 1.1: Read A,
1.2: Write C,
1.3: Write B )
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
Konfliktgraph:
A,B,C
A,C
t1
B
t2
A
t3
A
t4
A,B
Plan P ist Konflikt-äquivalent zum seriellen Plan P’ = {t1, t2, t3, t4},
also Konflikt-serialisierbar
17. Juli 2003
479
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
Satz über Test für Konflikt-Serialisierbarkeits: Beweis
1.
2.
Satz über Test für Konflikt-Serialisierbarkeits: Beweis
P ist Konflikt-serialisierbar genau dann, wenn Gkonflikt (P) azyklisch ist.
Ist Gkonflikt (P) azyklisch und ist P’ ein serieller Read/Write-Plan, der durch
topologisches Sortieren aus Gkonflikt gewonnen wird, so sind P und P’ Konflikt-äquivalent.
1.
2.
Beweis von “⇐” und 2.:
Voraussetzung:
Beweis von “⇒” (in Kontraposition):
Gkonflikt (P) azyklisch ,
P’ durch topologisches Sortieren aus Gkonflikt gewonnen
betrachte:
zwei im Konflikt liegende Anweisungen
i1.j1 : Op1 o und i2.j2 : Op2 o
mit
P-1 (i1.j1) < P-1 (i2.j2)
Def. Konfliktgraph:
(ti1, ti2) ∈ Kkonflikt
topologisches Sortieren:
in P’ wird ti1 vor ti2 ausgeführt, d.h.
© Joachim Biskup, Universität Dortmund
Voraussetzung:
Gkonflikt (P) zyklisch, d.h.
Gkonflikt (P) enthält einen Zykel (ti1,..., tie, ti1)
indirekte Annahme:
P’ sei ein serieller, zu P Konflikt-äquivalenter Plan.
Def. Konflikt-äquivalent: in P’ müssen die am Zykel beteiligten Transaktionen
in der durch den Zykel gegebenen Reihenfolge durchgeführt werden
damit speziell:
P’-1 (i1.j1) < P’-1 (i2.j2).
also:
P ist Konflikt-serialisierbar genau dann, wenn Gkonflikt (P) azyklisch ist.
Ist Gkonflikt (P) azyklisch und ist P’ ein serieller Read/Write-Plan, der durch
topologisches Sortieren aus Gkonflikt gewonnen wird, so sind P und P’ Konflikt-äquivalent.
ein offensichtlicher Widerspruch
P und P’ sind Konflikt-äquivalent
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
in P’ wird ti1 vor sich selbst ausgeführt
17. Juli 2003
481
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Konflikte und Konflikt-Serialisierbarkeit
17. Juli 2003
482
17. Juli 2003
484
Abbruch, Wirksamwerden und Versionen
•
eine Transaktion soll gar nicht oder vollständig wirksam werden
•
bislang gemäß Annahme A5: alle Transaktionen werden vollständig wirksam
•
nunmehr auch zulassen:
14.2 Versionsverwaltung
Transaktionen werden gar nicht wirksam,
zum Beispiel aus folgenden Anlässen:
- durch Benutzer mit Transaktions-Anweisung Abort_Trans,
um semantische Bedingungen zu erhalten
- durch Scheduler mit Abbruch einer Transaktion (und späterem erneuten Start),
um Serialisierbarkeit (oder andere Systemeigenschaften) zu erreichen
- durch Betriebssystem mit Abbruch des Prozesses,
um Fehlersituation aufzulösen
- durch Missgeschick als Zusammenbruch des Rechensystems,
z.B. Stromausfall oder nicht behebbarer Plattenfehler
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
17. Juli 2003
483
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
absichtlicher Abbruch
absichtlicher Abbruch: zukünftige Leseanweisungen
wird ein eine Transaktion ausführender Prozess absichtlich abgebrochen,
so muss sichergestellt werden,
erste Forderung:
alle vorher durchlaufenen Schreibanweisungen der Transaktion
werden nicht beobachtbar für zukünftige Leseanweisungen anderer Transaktionen
dass alle vorher durchlaufenen Schreibanweisungen der Transaktion unwirksam werden, d.h.
erforderliche Maßnahmen:
nach Schreibanweisungen müssen zunächst zwei Versionen eines Objekts unterhalten werden:
• die alte Version,
die (spätestens) nach einem Abbruch der Transaktion (wieder) als die gültige anzusehen ist
• die neue Version,
die (spätestens) nach dem Wirksamwerden der Transaktion gültig werden muss
- nicht beobachtbar werden
für zukünftige Leseanweisungen anderer Transaktionen
- nicht bedeutsam bleiben
für vorangegangene Leseanweisungen anderer Transaktionen,
die möglicherweise eine dieser Schreibanweisungen schon beobachtet haben
es bedarf einer genauen Festlegung,
- welche Version
- zu welchem Zeitpunkt
- für welche Transaktionen
gültig sein soll
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
17. Juli 2003
485
© Joachim Biskup, Universität Dortmund
absichtlicher Abbruch: vorangegangene Leseanweisungen
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
17. Juli 2003
486
17. Juli 2003
488
ein Ansatz zur Vermeidung von Folgeabbrüchen
nach Schreibanweisungen noch möglichst lange
die alte Version für andere Transaktionen als gültig ansehen, nämlich
zweite Forderung:
alle vorher durchlaufenen Schreibanweisungen der Transaktion
bleiben nicht bedeutsam für vorangegangene Leseanweisungen anderer Transaktionen,
die möglicherweise eine dieser Schreibanweisungen schon beobachtet haben
bis durch Verwendung der Anweisung Commit_Trans
die Änderungen ausdrücklich für wirksam,
d.h. die neue Version ausdrücklich als gültig erklärt wird
erforderliche Maßnahmen:
andere Transaktionen,
die schon die neue Version (fälschlicherweise) als gültig angesehen haben
(und damit, wie man sagt, “schmutzige Daten” gelesen haben),
müssen ebenfalls abgebrochen werden;
BEGIN_TRANS
.
.
Read o;
.
.
solche Folgeabbrüche können auch kaskadenhaft auftreten
Write o;
IF Bedingung
THEN Commit_Trans (* neue Version ausdrücklich
gültig erklären
*)
ELSE Abort_Trans
END_IF
END_TRANS
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
17. Juli 2003
487
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
Versionsverwaltung: einige Anforderungen
Versionsfunktion
alte Version
eine Versionsfunktion zu einem Read/Write-Plan bestimmt:
Objekt o:
• welche Version eine Leseanweisung lesen soll
neue Version
Zeit
z0
BEGIN_TRANS
z1
Write o
z2
Commit_Trans
• welche alte Version durch eine Schreibanweisung überschrieben werden
z3
END_TRANS
und damit verloren gehen soll
oder ob eine neue Version angelegt werden soll
alte Version
oder ob überhaupt nichts getan werden soll
Objekt o:
neue Version
Zeit
z0
BEGIN_TRANS
z1
Write o
z2
Abort_Trans
bislang immer eine Standard-Versionsfunktion vorausgesetzt:
z3
END_TRANS
• von einem Objekt wird stets (die einzig vorhandene) aktuelle Version gelesen
• von einem Objekt wird stets die bislang aktuelle Version überschrieben
• zwischen Zeitpunkten z0 und z2 (einschließlich): absichtliche Abbrüche erlauben
• zwischen Zeitpunkten z1 und z2: regeln,
in Praxis und Theorie:
welche Version vom Objekt o unter welchen Umständen als gültig angesehen wird
auch komplexere Versionsfunktionen
• zwischen den (möglichst kurz aufeinanderfolgenden) Zeitpunkten z2 und z3:
Gültigkeit abschließend und für alle Transaktionen verbindlich regeln,
dabei Objekt für andere Transaktionen vollständig sperren
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
17. Juli 2003
489
© Joachim Biskup, Universität Dortmund
Informationssysteme: Serialisierbarkeit und Versionsverwaltung - Versionsverwaltung
17. Juli 2003
490
Scheduler
•
soll für parallel auszuführende Transaktionen
die Anweisungen in einer geeigneten Reihenfolge anordnen
•
muss jeweils die zu benutzenden Versionen geeignet bestimmen
•
soll insbesondere erreichen:
- Serialisierbarkeit unter der Annahme, dass alle Transaktionen wirksam werden
15 Scheduler
- Zuverlässigkeit,
•
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
491
in diesem Zuammenhang:
Unterstützung der Dauerhaftigkeit,
Serialisierbarkeit auch bei Abbrüchen
im Folgenden nur unter vereinfachenden Annahmen:
- alle Transaktionen werden wirksam
- nur Konflikt-Serialisierbarkeit
- keine Versionen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
492
vereinfachtes Modell eines Schedulers
Konfliktgraphen-Scheduler
Scheduler
Folge der
Anweisungen
des Eingabeplanes
Wartebereich
Bedingungen
entsprechend
der
Vorgeschichte
•
einfachster, aber leider praktisch kaum brauchbarer Ansatz für einen Scheduler:
- baut den Konfliktgraphen dynamisch auf
- prüft jeweils auf Zykelfreiheit
- bricht gegebenenfalls eine zykelerzeugende Transaktion ab
•
etwas genauer:
Folge der
Anweisungen
des Ausgabeplanes
- wenn eine Anweisung neu angefordert wird,
prüft der Scheduler,
ob sie mit schon vorher wieder ausgegebenen Anweisungen im Konflikt liegt,
und trägt gegebenenfalls neue Kanten in den Konfliktgraphen ein
• ein Scheduler ist eine Transformation,
die jedem anweisungsweise gegebenen (Eingabe-)Plan zu einer Menge von Transaktionen T
einen (Ausgabe-)Plan zu T, der Konflikt-serialisierbar ist,
wiederum anweisungsweise zuordnet
• der Eingabeplan sei durch das zeitlich geordnete Eintreffen der Anweisungen gegeben,
wie sie von den die Transaktionen ausführenden Prozessen angefordert werden
• der Ausgabeplan werde dadurch erzeugt,
dass die Ausführung einer angeforderten Anweisung gegebenenfalls verzögert wird,
d.h. dass sie zunächst in einen Wartebereich eingeordnet wird und
erst nach dem Eintreffen bestimmter Bedingungen ausgeführt wird
(die durch die vorgezogene Ausführung später angeforderter Anweisungen eingetreten sind);
der anfordernde Prozess muss im Allgemeinen solange unterbrochen bleiben
(und kann damit insbesondere keine weiteren Anweisungen anfordern)
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
- falls kein Zykel entstanden ist,
so wird die Anweisung sofort wieder ausgegeben und ausgeführt
- falls ein Zykel entstanden ist,
so ist die Situation unter den vereinfachenden Annahmen hoffnungslos:
der einzige Ausweg ist ein Abbruch
der anfordernden (oder einer anderen am Zykel beteiligten) Transaktion
mit all den damit verbundenen Problemen
•
17. Juli 2003
493
lässt genau die Konflikt-serialisierbaren Pläne unverändert durch
© Joachim Biskup, Universität Dortmund
Sperrprotokoll-Scheduler
Informationssysteme: Scheduler
17. Juli 2003
494
beabsichtigte Semantik von Sperren
• verlangt, dass die Transaktionen solche Objekte,
wird eine Sperranweisung
i1.j1 : RLock o
erfolgreich ausgeführt,
so hält die Transaktion ti1 eine Lesesperre auf dem Objekt o,
bis die zugehörige Freigabeanweisung i1.j2 : Unlock o ausgeführt wird:
aus denen sie lesen oder in die sie schreiben wollen,
vorher ausdrücklich sperren (lock) und
nachher wieder ausdrücklich freigeben (unlock)
• genauer sind Transaktionen, die einem Sperrprotokoll genügen,
dazwischen kann ti1 aus o lesen, und
aus folgenden Anweisungen aufgebaut:
Read o
:
lies aus Objekt o
Write o
:
schreibe in Objekt o
RLock o
WLock o
:
:
sperre Objekt o zum Lesen
sperre Objekt o zum Schreiben (was auch Lesen erlaubt)
Unlock o
:
gib Objekt o frei
andere Transaktionen können ebenfalls Lesesperren auf o,
aber keine Schreibsperren auf o erhalten
wird eine Sperranweisung
i1.j1 : WLock o erfolgreich ausgeführt,
so hält die Transaktion ti1 eine Schreibsperre auf dem Objekt o,
bis die zugehörige Freigabeanweisung i1.j2 : Unlock o ausgeführt wird:
• Erweiterung der Annahme A3* des Read/Write Modells für Sperren:
- jeder Leseanweisung Read o muss genau eine Anweisung der Form
RLock o oder Wlock o vorausgehen
und genau eine Anweisung der Form Unlock o folgen
dazwischen kann ti1 in o schreiben
oder erst aus o lesen und dann in o schreiben, und
- jeder Schreibanweisung Write o muss genau eine Anweisung der Form
WLock o vorausgehen
und genau eine Anweisung der Form Unlock o folgen
andere Transaktionen können weder eine Lese- noch eine Schreibsperre auf o erhalten
- ferner umklammere jedes Lock-Unlock-Paar eine entsprechende Lese- oder Schreiboperation
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
495
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
496
Verträglichkeiten
Sperrprotokoll-Scheduler
•
Lesesperren können geteilt werden (shared locks)
beachtet nur die Sperr- und Freigabeanweisungen:
•
Schreibsperren werden exklusiv gehalten (exclusive locks)
•
•
Konflikte zwischen Lese- und Schreibanweisungen verschiedener Transaktionen
entsprechen genau den
Unverträglichkeiten zwischen den zugehörigen Sperranweisungen.
- falls dies der Fall ist,
so wird die Sperranweisung ausgeführt, d.h. die verlangte Sperre wird vergeben
•
Verträglichkeitsmatrix:
- falls dies nicht der Fall ist,
so wird die Sperranweisung verzögert und in den Wartebereich eingeordnet
von einer anderen Transaktion
bereits gehaltene Sperre auf o:
von t i1 für o
RLock
angeforderte Sperre:
WLock
© Joachim Biskup, Universität Dortmund
RLock
WLock
+
-
-
-
Informationssysteme: Scheduler
•
17. Juli 2003
497
Sei P ein Plan zu einer
Menge von Transaktionen T = {t1,..., tk} mit folgenden Eigenschaften:
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
Beweis von 2.:
17. Juli 2003
498
folgt unmittelbar aus 1.
Beweis von 1.:
zu zeigen:
a. [Zwei-Phasen-Sperrprotokoll]
alle Transaktionen aus T genügen dem Zwei-Phasen-Sperrprotokoll
je zwei im Konflikt liegende Anweisungen in P und P’
werden in der gleichen Reihenfolge ausgeführt
betrachte solche Anweisungen: seien w1 < w2 Zeitpunkte mit
P(w1) = i1.j1 : Op1 o und P(w2) = i2.j2 : Op2 o und
Op1 = Write oder Op2 = Write
b. [Sperrprotokoll-Scheduler]
im Plan P halten je zwei Transaktionen keine unverträglichen Sperren
(d.h. P ist möglicher Ausgabeplan des Sperrprotokoll-Schedulers)
exklusive Sperre für Write-Anweisung:
Transaktion ti1 muss nach dem Zeitpunkt w1,
etwa zum Zeitpunkt w1*, ein Unlock o ausführen,
Dann gilt:
1. Für i = 1,..., k sei die Sperrzeit zi derjenige Zeitpunkt von P,
zu dem die Transaktion ti ihre letzte Sperranweisung ausführt,
und
π: {1,..., k} → {1,..., k} sei eine Permutation mit
zπ(1) < zπ(2) < ... < zπ(k):
dann ist (nach dem Weglassen der Sperr- und Freigabeanweisungen)
P Konflikt-äquivalent zum seriellen Plan P’ = (tπ(1), tπ(2),..., tπ(k)).
bevor Transaktion ti2 vor dem Zeitpunkt w2,
etwa zum Zeitpunkt w2*, ein WLock o bzw. RLock o ausführt
2. P ist (nach dem Weglassen der Sperr- und Freigabeanweisungen)
Konflikt-serialisierbar.
Informationssysteme: Scheduler
wenn eine Freigabeanweisung neu angefordert wird,
so wird sie ausgeführt:
- die entsprechende Sperre wird aufgehoben und
- gegebenenfalls werden auf diese Freigabe wartende Sperranweisungen
erneut bearbeitet
ein Sperrprotokoll-Scheduler bearbeitet solche Transaktionen erfolgreich,
die dem Zwei-Phasen-Sperrprotokoll genügen,
d.h. in denen alle Sperranweisungen vor allen Freigabeanweisungen liegen
Konflikt-Serialisierbarkeit unter dem Zwei-Phasen-Sperrprotokoll
© Joachim Biskup, Universität Dortmund
wenn eine Sperranweisung neu angefordert wird,
so prüft der Scheduler, ob sie mit den schon gehaltenen Sperren verträglich ist:
17. Juli 2003
499
Zwei-Phasen-Sperrprotokoll:
alle Sperranweisungen vor allen Freigabeanweisungen
also:
also:
zi1 < w1* < w2* <= zi2
die betrachteten Anweisungen werden im seriellen Plan P’
in der gleichen Reihenfolge ausgeführt
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
500
Sperrprotokoll-Scheduler verlangt Zwei-Phasen-Sperrprotokoll
vorliegende Situation kann man sich wie folgt veranschaulichen:
Sperrzeit von ti1
zi1
Die Transaktion t1 genüge einem Sperrprotokoll,
entspreche aber nicht dem Zwei-Phasen-Aufbau.
Sperrzeit von ti2
zi2
Zeit
w1
Ausführungszeit von
i1.j1: Op1 o
w1*
Ausführungszeit von
i1.j1*: Unlock o
w2*
Ausführungszeit von
i2.j2*: Lock o
Dann gibt es eine Transaktion t2 und für T := {t1, t2} einen Plan P,
so dass gilt:
w2
Ausführungszeit von
i2.j2: Op2 o
1. [Sperrprotokoll-Scheduler]
t1 und t2 halten keine unverträglichen Sperren.
2. P ist nicht Konflikt-serialisierbar.
Beweis: entfällt
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
501
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
Verklemmungen
Transaktionen geraten in eine Verklemmung (deadlock), wenn sie wechselseitig
schon von der jeweils anderen Transaktion gehaltene Sperren anfordern
•
ein typisches Muster:
• Phase 1: [Sperren]
angeforderte Anweisung
Verhalten des Schedulers
1.1 : WLock A
t1 erhält Schreibsperre auf A
2.1 : WLock B
t2 erhält Schreibsperre auf B
1.2 : WLock B
Anforderung ist unverträglich:
t1 muss auf die Ausführung von 2.j2 : Unlock B warten
2.2 : WLock A
Anforderung ist unverträglich:
t2 muss auf die Ausführung von 1.j1 : Unlock A warten
zusammen mit Phase 4: Zwei-Phasen-Sperrprotokoll
alle benötigten Objekte werden gesperrt
(falls als unteilbare Operation verwirklicht, werden sogar Verklemmungen vermieden;
andernfalls können Phase 1 und 2 auch ineinander verschränkt werden)
• Phase 2: [Schreiben in eine Logdatei]
zusammen mit Phase 3: für Zuverlässigkeit
alle Schreiboperationen werden zunächst nicht im gemeinsamen Informationssystem,
sondern in einer gesonderten Logdatei durchgeführt;
die Logdatei enthält damit für andere Transaktionen unzugängliche Versionen
• Phase 3: [Kopieren der Logdatei in das Informationssystem]
erreicht die Transaktion die Commit_Trans-Anweisung,
so werden erst dann alle Schreiboperationen auf einmal (als eine unteilbare Operation)
tatsächlich im Informationssystem durchgeführt, indem die Logdatei einfach kopiert wird
• Phase 4: [Freigeben]
alle gesperrten Objekte werden wieder freigegeben
also tritt eine Verklemmung ein: t1 wartet auf t2, und t2 wartet auf t1.
sperren
in Logdatei
schreiben
zwei Ansätze:
- Verklemmungen entdecken und durch Abbruch einer Tranaktion auflösen
- Verklemmungen durch geeignete Maßnahmen verhindern
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
502
Striktes Sperrverhalten
•
•
17. Juli 2003
BEGIN_TRANS
17. Juli 2003
503
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
Logdatei ins
Informationssystem kopieren
Commit_Trans
freigeben
Zeit
END_TRANS
17. Juli 2003
504
Zeitmarken-Scheduler
•
1. [Leseanforderungen]
falls Transaktion ti eine Leseanweisung Read o anfordert,
so wird die Zeitmarke si verglichen mit den Zeitmarken der Transaktionen,
die vorangehende, im Konflikt liegende Schreibanweisungen enthalten:
jeder Transaktion ti wird bei ihrem Start zugeordnet eine
(statische) Zeitmarke
•
Zeitmarken-Scheduler
si
:= Startzeit von ti
für jedes Objekt o werden unterhalten zwei geeignet initialisierte
(dynamische) Zeitmarken oread := max {si | ti hat aus Objekt o gelesen}
owrite := max {si | ti hat in Objekt o geschrieben}
•
ein Zeitmarken-Scheduler beobachtet und verändert nun die Zeitmarken
mit folgendem Ziel:
es werden nur solche Ausgabe-Pläne zugelassen,
die (Konflikt-)äquivalent zu demjenigen seriellen Plan sind,
in dem die Transaktionen in der Reihenfolge ihrer Zeitmarken ausgeführt werden
•
falls wegen eines sichtbar werdenden Konflikts dieses Ziel gefährdet wird,
bricht der Scheduler eine am Konflikt beteiligte Transaktion ab
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
t3 := ( 3.1: Read C,
3.2: Write A )
505
P(1)
P(2)
P(3
P(4)
P(5)
P(6)
P(7)
P(8)
P(9)
P(10)
P(11)
P(12)
© Joachim Biskup, Universität Dortmund
=
=
=
=
=
=
=
=
=
=
=
=
1.1:
2.1:
1.2:
3.1:
1.3:
4.1:
4.2:
2.2:
3.2:
4.3:
2.3:
4.4:
Informationssysteme: Scheduler
Read
Read
Write
Read
Write
Read
Read
Read
Write
Write
Write
Write
falls owrite > si :
Transaktion ti wird abgebrochen
falls oread <= si und owrite < si :
die Schreibanweisung wird ausgeführt, und man setzt
owrite := si
falls oread > si oder owrite > si :
Transaktion ti wird abgebrochen
© Joachim Biskup, Universität Dortmund
P
t4 := ( 4.1: Read B,
4.2: Read C,
4.3: Write B,
4.4: Write A )
Zeitmarken, entsprechend der Startzeiten zugeordnet:
s1 := 1,
s2 := 2,
s3 := 4,
s4 := 6
Plan P:
die Leseanweisung wird ausgeführt, und man setzt
oread := max {oread, si}
2. [Schreibanforderungen]
falls Transaktion ti eine Schreibanweisung Write o anfordert,
so wird die Zeitmarke si verglichen mit den Zeitmarken der Transaktionen,
die vorangehende, im Konflikt liegende Lese- oder Schreibanweisungen enthalten:
Beispiel für Zeitmarken-Scheduler
Transaktionen:
t1 := ( 1.1: Read A,
t2 := ( 2.1: Read A,
1.2: Write C,
2.2: Read B,
1.3: Write B )
2.3: Write D )
falls owrite < si :
A
A
C
C
B
B
C
B
A
B
D
A
17. Juli 2003
507
Informationssysteme: Scheduler
17. Juli 2003
z
Ar
Aw
Br
Bw
Cr
Cw
Dr
Dw
0
0
0
0
0
0
0
0
0
1.1: Read A
1
1
.
.
.
.
.
.
.
Aw < s1
2.1: Read A
2
2
.
.
.
.
.
.
.
Aw < s2
1.2: Write C
3
.
.
.
.
.
1
.
.
Cr <= s1 ∧ Cw < s1
3.1: Read C
4
.
.
.
.
4
.
.
.
Cw < s3
1.3: Write B
5
.
.
.
1
.
.
.
.
Br <= s1 ∧ Bw < s1
4.1: Read B
6
.
.
6
.
.
.
.
.
Bw < s4
4.2: Read C
7
.
.
.
.
6
.
.
.
Cw < s4
2.2: Read B
8
.
.
6
.
.
.
.
.
Bw < s2
3.2: Write A
9
.
4
.
.
.
.
.
.
Ar <= s3 ∧ Aw < s3
4.3: Write B
10
.
.
.
6
.
.
.
.
Br <= s4 ∧ Bw < s4
2.3: Write D
11
.
.
.
.
.
.
.
2
Dr <= s2 ∧ Dw < s2
4.4: Write A
12
.
6
.
.
.
.
.
.
Ar <= s4 ∧ Aw < s4
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
506
erfüllte Bedingung
17. Juli 2003
508
Konflikt-Serialisierbarkeit unter dem Zeitmarken-Scheduler
würde man im Plan P die ersten beiden Anweisungen vertauschen,
so erhielte
Transaktion t1 die Startzeit
s1 := 2
und Transaktion t2 die Startzeit s2 := 1
Sei P ein Plan zu einer Menge von Transaktionen T = {t1,..., tk} mit der Eigenschaft,
dass er möglicher Ausgabeplan des Zeitmarken-Schedulers ist.
1. Für i = 1,.., k sei si die Startzeit von ti und
π : {1,..., k} → {1,..., k} eine Permutation mit sπ(1) < sπ(2) < ... < sπ(k).
dieser Plan wäre nicht Konflikt-äquivalent zum seriellen Plan P’’ = {t2, t1, t3, t4}:
die Anforderung der Leseanweisung 2.2 : Read B
würde zum Zeitpunkt 8 zum Abbruch der Transaktion t2 führen,
Dann ist P Konflikt-äquivalent zum seriellen Plan P’= (tπ(1), ..., tπ(k)).
2. P ist Konflikt-serialisierbar.
weil die Bedingung
nicht erfüllt wäre
© Joachim Biskup, Universität Dortmund
Bw < s2
für Bw = 2 und s2 = 1
Beweis von 1.:
zu zeigen:
Informationssysteme: Scheduler
17. Juli 2003
509
Zeitmarken-Scheduler:
stellt genau dies sicher
Beweis von 2.:
folgt unmittelbar aus 1.
© Joachim Biskup, Universität Dortmund
nutzlose Schreibanweisungen
falls oread <= si und owrite > si :
die Schreibanweisung von ti wird
einfach übersprungen
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
510
Konflikt-Äquivalenz zu demjenigen seriellen Plan sichergestellt,
der die Transaktionen in der Reihenfolge ihrer Sperrzeiten ausführt
• unter dem Zeitmarken-Scheduler wird
Konflikt-Äquivalenz zu demjenigen seriellen Plan sichergestellt,
der die Transaktionen in der Reihenfolge ihrer Startzeiten ausführt
die Schreibanweisung wird ausgeführt,
und man setzt
owrite := si
Transaktion ti wird abgebrochen
17. Juli 2003
• unter dem Zwei-Phasen-Sperrprotokoll wird
2* [Schreibanforderungen]
Transaktion ti fordert eine Schreibanweisung Write o an:
falls oread > si :
Informationssysteme: Scheduler
Unvergleichbarkeit von Zwei-Phasen-Sperrprotokoll und
Zeitmarken-Scheduler
durch Verfeinerung der Regeln kann man
im Konflikt liegende, aber erkennbar nutzlose Schreibanweisungen
einfach überspringen:
falls oread <= si und owrite < si ,:
je zwei im Konflikt liegende Anweisungen werden
in P und P’ in der gleichen Reihenfolge ausgeführt
17. Juli 2003
• beide Verfahren schließen manche eigentlich Konflikt-serialisierbaren Pläne als Ausgaben aus
• die Klassen der jeweils erzeugbaren Ausgabepläne
sind (bezüglich Mengeninklusion) unvergleichbar:
511
1.
es gibt einen Plan P1,
der als Ausgabeplan unter dem Zwei-Phasen-Sperrprotokoll
(nach dem Weglassen von Sperr- und Freigabeanweisungen) möglich ist,
aber nicht unter dem Zeitmarken-Scheduler
2.
es gibt einen Plan P2,
der als Ausgabeplan unter dem Zeitmarken-Scheduler möglich ist,
aber nicht unter dem Zwei-Phasen-Sperrprotokoll
© Joachim Biskup, Universität Dortmund
Informationssysteme: Scheduler
17. Juli 2003
512
pessimistische und optimistische Scheduler
•
Index
pessimistischer Scheduler
versucht durch weitreichende Vorsorge
das Eintreten von nichtserialisierbaren oder verklemmten Situationen
möglichst frühzeitig zu verhindern;
im Allgemeinen sind dazu erforderlich:
- verhältnismäßig großer Aufwand für den Scheduler oder
- verhältnismäßig einschneidende Einschränkungen an die erlaubten Transaktionen
•
Informationssysteme: Scheduler
Differenz 161–162, 176, 202, 223
Division 163–164, 202
Domäne 114, 291
DTD (Document Type Definition) 314
E
Eigenschaft 63
eindeutige Unterstützung 434
Einschränkung 114
Enthaltenseinsabhängigkeit 113, 411
Entität 63
Erfüllbarkeit 83
ER-Modellierung 63, 70, 72–77, 80
Aggregation 63
Attribut 63
Aussonderung 63
Beziehung 63
Eigenschaft 63
Entität 63
Klassenbildung 63
Rolle 63
Seiendes 63
Verallgemeinerung 63
Extremalattribut 426
© Joachim Biskup, Universität Dortmund
Informationssysteme: Index
17. Juli 2003
Aussonderung 63
3.Normalform 428–429
B
A
B*-Baum 350
Basisrelation 267, 410
Beziehung 63
Boyce / Codd-Normalform 428–429, 440, 443
A≠B-Vergleich 159, 202, 222
A=B-Vergleich 159, 176, 202, 222
A=c-Selektion 147, 166, 175, 219, 398, 400
Abhängigkeit
Enthaltenseins- 113, 411
funktionale 113, 411, 413–415
mehrwertige 113
Verbund- 113, 152, 411, 436
Abschluss 417
ACID-Eigenschaften 458
Administrator 31, 48, 57, 89, 241, 261, 299
Aggregation 63
Allgemeingültigkeit 83
Anfrage 32, 93, 95, 291
Anfrageprogramm 269
Armstrong-Relation 421
Attribut 63, 114, 135, 166, 291
optimistischer Scheduler
versucht zunächst
die Anweisungen möglichst unmittelbar wie angefordert auszuführen
und erst nachträglich, wenn dies in der Regel leichter erkennbar ist,
nichtserialisierbare (oder verklemmte) Situationen
durch Abbruch einer Transaktion wieder aufzulösen
© Joachim Biskup, Universität Dortmund
Zahlen
513
F
© Joachim Biskup, Universität Dortmund
Index 349
Individuenvariable 79, 268
Information 36–40, 49
Information Retrieval 316, 320
Information Retrieval-System 26, 183
Informationsgehalt 37
Informationssystem 24, 49
Instanz 69, 115, 116
Interaktion 56–57
Gleichheitszeichen 79
globale semantische Bedingung 116
Grundfakt 267, 268
Grundfakten-Transformation 273–274
Grundformel 268
Grundterm 79
K
kartesisches Produkt 84
Klassenbildung 63
Kommunikation 41–42, 50, 56
Komplement 160, 202
Konflikt 475
Konflikt-Äquivalenz 476, 478
Konfliktgraph 477
Konfliktgraphen-Scheduler 494
Konflikt-Serialisierbarkeit 476, 478, 499, 510
H
halb-strukturierte Daten 26, 295
Handlungsfolge 67, 452
hängendes Tupel 154
Hash-Filter-Verbund 383, 386
Hashfunktion 349
17. Juli 2003
515
© Joachim Biskup, Universität Dortmund
D
Daten
halb-strukturierte 26, 295
strukturierte 26, 295
Datenbanksystem 26
Datendefinitionssprache 31, 42, 89, 93, 206
Datenmanipulationssprache 42, 90, 91, 93, 206
Datenwörterbuch 97–98, 361, 373, 375
Definitionsbereich 114, 181, 187, 467
deklarative Semantik 269, 282
17. Juli 2003
514
Konklusion 113, 268, 283
Konstantenzeichen 114, 166, 268
Kosten 406–407, 431–432
L
I
G
Clustering 334
Informationssysteme: Index
hierarchische Klassifikation 332
Hornformel 111, 113, 247, 264, 268
Hornklausel 268, 273, 283, 291, 402, 413
Hypergraph 118, 166
Fakt 268
Fallout 322
Fetch-Expression 304
Fixpunktsatz von Tarski-Kleene 276
F-Logik 291
föderiertes System 105
Formel 79, 187, 246, 268, 413
funktionale Abhängigkeit 113, 411, 413–415
Funktionszeichen 79, 291
C
Informationssysteme: Index
Link 349
Link-Verbund 373–380, 386
logische Implikation 32, 40, 83, 237, 269, 272, 402,
416–422
LOGODAT-Anfrage 269, 283–284
lokale semantische Bedingung 115
M
mediiertes System 106
mehrwertige Abhängigkeit 113
Menge 84
Metaschema 49, 125–126, 317
Miniwelt 33
Modell 33, 38, 83, 111, 115, 116, 141
Modellklasse 39, 83
Multimedia-System 26, 183
N
natürlicher Verbund 144–146, 148, 152–154, 166, 175,
202, 218, 398
17. Juli 2003
516
NestedLoop 359, 365–366, 386
Nichtschlüsselattribut 424
Object-ID 298
objektorientierte Formalisierung 286
OEM (Object Exchange Model) 297
Ontologie 31, 41, 69, 296, 317, 332, 335
operationale Fixpunktsemantik 277, 282
Optimierung 32, 95, 156, 166, 242, 295, 387
Regel 64, 71, 268
Relation 38, 81, 95, 111, 114, 237, 405
relationale Anfrage 178–179, 180, 182–183, 204
relationales Datenbankschema 116, 119, 267
Relationenalgebra 180, 181–182, 184, 190–201, 202
Relationenkalkül 180, 187–188, 190–201
Relationenschema 115, 118, 141, 267
Relationensymbol 114, 135, 166, 268
Relevanz 316, 321, 340–341
Rolle 63
Rückgabe-Objekt 304, 307, 309, 310
sequentielle Liste 349
Sicht 31, 98, 291
Sichtrelation 410
Signaturmolekül 291
Sortiertes Mischen 368–369, 386
Soziales System 49
Sperrprotokoll-Scheduler 495–502
SQL (Structured Query Language) 180, 206–223
Struktur 81–82
strukturierte Daten 26, 295
Surrogatpaar 291
P
S
T
Scheduler 492–493, 513
Konfliktgraphen- 494
Sperrprotokoll- 495–502
Zeitmarken- 505–512
Schema 31, 41, 49, 69, 89, 98, 110, 123, 141, 264, 272,
295, 317, 411
Schlüssel 135–136, 424, 432
Schlüsselattribut 424
Seiendes 63
semantische Bedingung 30, 111, 135
globale 116
lokale 115
semantischer Bereichsname 114, 166
Teilverbund 155
Term 79, 268, 291
Thesaurus 335–337
Transaktion 99, 141, 457, 484
treue Unterstützung 434
Tupel 95, 96, 114, 154, 345
Tupelidentifikator 345
O
Plan 466
Potenzmenge 84
Prädikatenlogik 79–80, 180
Prädikatenzeichen 39, 79, 207
Prämisse 113, 268, 283
Precision 322–325
Projektion 149–154, 166, 175, 202, 220, 398, 400
Protokollausführung 56–57
R
Read/Write-Modell 469–473
Recall 322–325
Redundanz 30, 399, 402–404, 433
© Joachim Biskup, Universität Dortmund
Informationssysteme: Index
17. Juli 2003
517
Unterstützungsanfrage 437
V
Variablenbelegung 81–82
Verallgemeinerung 63
Verbundabhängigkeit 113, 152, 411, 436
Vereinigung 84, 157–158, 176, 202, 221
Verklemmung 503
Versionsfunktion 490
W
Wissensbanksystem 26
X
XML (Extensible Markup Language) 311–312
DTD (Document Type Definition) 314
Z
Zeitmarken-Scheduler 505–512
Zwei-Phasen-Sperrprotokoll 498
U
Unerfüllbarkeit 83
Unterstützung
eindeutige 434
treue 434
© Joachim Biskup, Universität Dortmund
Informationssysteme: Index
17. Juli 2003
518