Datenbanktheorie. Teil A: Einleitung 1: Grundbegriffe. Sommersemester Thomas Schwentick. Version von: 4. April 2012 (11:50)

Transkript

1 Datenbanktheorie Sommersemester Thomas Schwentick Teil A: Einleitung 1: Grundbegriffe Version von: 4. April 2012 (11:50)

2 Inhalt 1.1 Das relationale Datenmodell 1.2 Anfragen an relationale Datenbanken DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 1

3 Grundidee des relationalen Datenmodells: Daten werden in Tabellen organisiert Einfache Operationen für Tabellen: Zeilen einer Tabelle auswählen Spalten einer Tabelle auswählen Tabellen kombinieren Beispiel PROFESSOREN PersNr Name Raum 201 Turing Gödel von Neumann Knuth Chomsky Shannon Dijkstra 321 Das relationale Datenmodell wurde 1970 von Codd vorgeschlagen und ist seit Ende der 80er Jahre der Industriestandard Relationales Modell: Tabellen Kurz-Bio: Edgar Codd Geboren: , Isle of Portland (England) Studium der Mathematik und Chemie in Oxford Ab 1948 Mathematischer Programmierer bei IBM 1970: A Relational Model of Data for Large Shared Data Banks Gestorben: DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 2

4 Relationales Modell: Tabellen vs. Relationen (1/2) Intuitiv bestehen relationale Datenbanken aus Tabellen Aus mathematischer Sicht bestehen sie aber aus Relationen Notation: inst steht für instances Dom für domain R A 1 A 2 A 3 a 1 z c 1 y d 4 x Intuitiv Mathematisch Formal Beispiel Tabellenschema Relationsschema R (R,{A 1,A 2,A 3 }) Tabellenname Relationsname name(r) R Spaltenüberschrift Attribut A A 2 Mögliche Spaltenwerte Wertebereich Dom(A) Dom(A 2 ) = N Spaltenüberschriften Attributmenge sort(r) {A 1,A 2,A 3 } Anzahl Spalten Stelligkeit arity(r) 3 Zeile R-Tupel t : sort(r) dom t(a) Dom(A) t 1 = {A 1 a, A 2 1,A 3 z} Tabelle Tupelmenge R-Relation {t 1,t 2,t 3 } Mögliche Tabellen Menge aller R-Relationen inst(r) DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 3

5 Relationales Modell: Tabellen vs. Relationen (2/2) Attribute: Ein Attribut A hat einen NamenA und einen Wertebereich Dom(A) Wir unterscheiden (wie gerade eben) in der Notation nicht zwischen Attributen und ihren Namen Wir nehmen eine unendliche Menge att von Attributen als gegeben an Relationenschemata: Ein Relationenschema R = (name(r),sort(r)) besteht aus einem Relationennamen und einer Menge von Attributen Datenbankschemata: Ein Datenbankschema beschreibt die Struktur einer Datenbank Ein Datenbankschema D ist (zunächst) einfach eine endliche Menge von Relationenschemata Relationen: Anders als die Zeilen einer Tabelle sind die Tupel einer Relation nicht geordnet! Datenbanken: Eine Datenbank zu SchemaD hat eine Relation je Relationsschema R D Eine Datenbank D zu SchemaD ist formal eine Abbildung vond in die Menge der möglichen Relationen mit D(R) inst(r), für jedesr D Keine Angst: Ganz so formal wird es in dieser Vorlesung nicht bleiben Aller Anfang ist schwer Wann immer möglich, werden wir uns auf einer intuitiven Ebene bewegen... DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 4

6 Relationales Modell: Notation Um das Verständnis etwas zu erleichtern, werden gleichartige Objekte in dieser Vorlesung möglichst durch gleichartige Bezeichner benannt Einige allgemeine Konventionen: att: abzählbare Menge aller Attribute (geordnet) A,B,C: Attribute U,V,W : endliche Mengen von Attributen Abkürzende Schreibweise: ABC statt {A,B,C} dom: abzählbare Menge aller Datenwerte a,b,c: Werte aus dom Dom(A): Wertebereich des Attributes A Weitere statische Bezeichnungen: R: Relationenschema R,S: Relationsnamen sort(r), arity(r), name(r): Attributmenge, Stelligkeit und Name von R inst(r): Menge der Relationen zu Schema R D: Datenbankschema inst(d): Menge der Datenbanken zu Schema D Weitere dynamische Bezeichnungen: t,s: Tupel Abkürzung: t.a := t(a) für Eintrag in Zeiletund SpalteA R,S: Relationen (aus dem Kontext klar, ob Relationenname gemeint ist) D: Datenbank R D : Relation mit NamenRin DatenbankD DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 5

7 PROFESSOREN PersNr Name Raum 201 Turing Gödel von Neumann Knuth Chomsky Shannon Dijkstra 321 STUDIERENDE MatrNr Name Semester Wirth Pnueli Hartmanis Feigenbaum Yao Milner Blum 2 Unsere Beispieldatenbank MITARBEITER PersNr Name Gebiet Betreuer 4021 Sutherland Computergraphik Sedgewick Algorithmen Gandy Mengenlehre HabermannProgrammiersprachen Broder Web Research 213 VORLESUNGEN VorlNr Titel Dozent 2002 Rechnerarchitektur Verteilte Systeme Berechenbarkeit Informationstheorie Formale Sprachen Logik Programmierung KI Linguistik Quantenmechanik 238 HÖRT MatrNrVorlNr SETZTVORAUS VorlNrVorausNr PRÜFT MatrNrVorlNrPersNrNote DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 6

8 Beispieldatenbank: Schemas D Uni = {R PROFESSOREN,R VORLESUNGEN,R HÖRT, R STUDIERENDE,R SETZVORAUS,R MITARBEITER,R PRÜFT } sort(r VORLESUNGEN ) = {VorlNr, Titel, Dozent} name(r VORLESUNGNEN ) = VORLESUNGEN arity(r VORLESUNGEN ) = 3 DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 7

9 Inhalt 1.1 Das relationale Datenmodell 1.2 Anfragen an relationale Datenbanken DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 8

10 Anfragen: Beispiele (1) Welche Zimmernummer hat Turing? (2) Welcher Mitarbeiter ist auf Mengenlehre spezialisiert? (3) Welche Vorlesungen (Nr und Titel) bietet Chomsky an? (4) Gibt es eine Vorlesung über Logik? (5) Welche zwei Professoren prüfen jeweils Vorlesungen, die der andere liest? (6) Je zwei Studierende, die dieselbe Vorlesung besuchen? (7) Welche Vorlesungen werden von Shannon oder Dijkstra angeboten? (8) Welche Vorlesungen werden von Dijkstra angeboten oder geprüft? (9) Welche Personen sind an Prüfungen in Programmierung beteiligt (Prüfer und Prüflinge)? (10) Wer bietet keine Vorlesungen an? (11) Wer bietet genau eine Vorlesung an? (12) Wer prüft Vorlesungen, die er nicht liest? (13) Wer hört mehr als eine Vorlesung? (14) Wer wird von einem Prüfer geprüft, der keine Vorlesungen anbietet? (15) Welche Veranstaltungen sind (direkte oder indirekt) Voraussetzung für Verteilte Systeme? DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 9

11 Streng genommen müssen wir zwischen den Begriffen Anfrage und Anfragefunktion unterscheiden: Eine Anfragefunktion ordnet jeder Datenbank eine Ergebnisrelation zu Anfragen und Anfragefunktionen Formaler: Eine Anfragefunktion ist eine Abbildung, die, für ein Datenbankschema D und ein Relationenschema R, jeder DatenbankD überd eine RelationR über R zuordnet D R = q(d) Eine Anfrage ist die Spezifikation einer Anfragefunktion, meistens in der Form eines Strings q Beispiel SELECT Raum FROM PROFESSOREN WHERE Name = Turing ist eine Anfrage in SQL Die durch diese Anfrage spezifizierte Anfragefunktion ordnet jeder Datenbank mit einer Relation PROFESSOREN die Menge der Werte der Raum-Attribute aller Tupel zu, deren Name-Attribut den Wert Turing hat... In unserer Beispieldatenbank ist das Anfrage-Ergebnis also{134} Obwohl die prinzipielle Unterscheidung zwischen Anfrage und Anfragefunktion wichtig ist, werden wir sprachlich meistens von ihr absehen: Meistens verwenden wir die Bezeichnung Anfrage für beides! DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 10

12 Anfragefunktionen: Eigenschaften (1/2) Anfragefunktionen q sollen nicht irgendwelche Funktionen sein sondern die folgenden Eigenschaften haben: (a) Das Ergebnis sollte nicht von Details der Speicherung abhängen sondern nur von der logischen Sicht: q ist Funktion inst(d) inst(r) (b) Anfragefunktionen sollten durch Computer ausgewertet werden können: q ist berechenbar (c) Das Ergebnis sollte möglichst nur von der Struktur der Datenbank abhängen, aber nicht so sehr von den einzelnen Werten: Hierzu betrachten wir zunächst ein Beispiel Beispiel Wir betrachten noch einmal die folgende Anfrage: (1) Welche Zimmernummer hat Turing? Wegen des Tupels 201,Turing,134 ist das Ergebnis für die Beispiel-DB{134} Wenn wir 134 in diesem Tupel durch 205 ersetzen, wie soll sich das Ergebnis ändern? Wenn wir Turing in diesem Tupel durch Kleene ersetzen, wie soll sich das Ergebnis ändern? Was lernen wir daraus? Wenn sich die Datenwerte einer DB ändern, sollen sich die Ergebnisse einer Anfrage entsprechend ändern Ausnahme: Explizite Vorkommen von Werten in der Anfrage sollen bei der Auswertung nicht als geändert interpretiert werden Eigenschaft (c): g ist generisch DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 11

13 Wir definieren Eigenschaft (c) von Anfragefunktionen jetzt formal Definition Eine Anfragefunktion q heißt generisch, falls für jede Datenbank D und jede Permutationπ von dom gilt: π(q(d)) = q(π(d)) Illustration: π D π(d) q q Anfragefunktionen: Eigenschaften (2/2) q(d) π q(π(d)) = π(q(d)) Wenn in einer Anfrage Konstanten vorkommen (wie in Anfrage (1)) ist diese Definition zu einschränkend: Permutation, die in der DB Turing verändern, wollen wir dann nicht betrachten Definition SeiC dom eine endliche Menge Eine Anfragefunktion q heißt C-generisch, falls für jede Datenbank D und jede Permutation π von dom (mitπ(x) = x fürx C) gilt:π(q(d)) = q(π(d)) Anfrage (1) ist also{turing}-generisch Wir betrachten nur C-generische Anfragefunktionen q, wobei C jeweils die Menge derjenigen Konstanten ist, die in der Spezifikation von q explizit genannt werden Zur Beruhigung: Alle Anfragesprachen, die wir betrachten, können nur Anfragen beschreiben, die die Generizitäts-Eigenschaft (c) haben DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 12

14 ja / nein -Anfragen Manche Anfragen lassen sich nur mit ja oder nein beantworten: Beispiel: (4) Gibt es eine Vorlesung über Logik? Wie passen solche Anfragen in unseren allgemeinen Rahmen, der immer Relationen als Anfrageergebnisse vorsieht? Da ja / nein -Anfragen keine Datenwerte im Ergebnis haben, ist es nahe liegend, dass ihr Resultat 0- stellige Relationen sind Es gibt zwei 0-stellige Relationen:{} und{ } Konvention: { } ja {} nein (Eine mathematische Rechtfertigung für diese Konvention werden wir noch kennen lernen) DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 13

15 Anfragesprachen Dieselbe Anfragefunktion kann in verschiedenen Anfragesprachen beschrieben werden SQL: SELECT Raum FROM WHERE Beispiel PROFESSOREN Name = Turing Relationale Algebra: π Raum (σ Name= Turing (PROFESSOREN)) Datalog: RESULT(x) :- PROFESSOREN(y, Turing,x) Relationen-Kalkül: {(x) y PROFESSOREN(y, Turing,x)} Bemerkung: Anfragesprachen unterscheiden sich hinsichtlich ihrer Ausdrucksstärke und hinsichtlich ihrer algorithmischen Eigenschaften Hierarchie der betrachteten Anfragesprachen: Datalog Datalog + Negation + Rekursion + Rekursion Rekursions-freies Datalog Und-Anfragen Relational vollständige Sprachen + Disjunktion + Negation DBT / Schwentick / SoSe 12 Einleitung 1. Grundbegriffe. Folie 14