Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Transkript

1 Grundlagen relationaler Datenbanksysteme Kapitel III Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 3. Grundlagen relationaler Datenbanksysteme Motivation Relationenmodell Sprachen des Basismodells Relationen-Algebra Relationen-Kalkül 2 G. Specht: Datenbanksysteme 3-1

2 Motivation 3 Motivation Ende der 60er Jahre Grundlagenforschung am IBM-Forschungslabor San Jose, California, mit dem Ziel, die Erstellung von Datenbankanwendungen einfacher zu machen erste Veröffentlichung von E.F. Codd zum Relationalen Datenmodell In der Folge verschiedene Prototyp-Entwicklungen, am bekanntesten wurden System R, IBM Ingres, University of California, Berkeley Heute wichtigste kommerziell verfügbare Datenbanktechnologie Inzwischen sind viele relationale DBS auf dem Markt DB2 (IBM) Oracle (Oracle) SQL-Server (Microsoft) Sybase (Sybase) Informix (IBM) etc. 4 G. Specht: Datenbanksysteme 3-2

3 Relationenmodell 5 Motivation Das haben wir: E/R-Modell Bsp.: KursDB 6 G. Specht: Datenbanksysteme 3-3

4 Motivation Da wollen wir hin: Bsp. Relationen zur KursDB Kurs Kursleiter Vorauss Fuehrt_durch KursNr Titel PersNr Name Gehalt VorNr KursNr AngNr KursNr PersNr G08 Grundlagen I Meier, I G08 P13 1 G G10 Grundlagen II Schulze, H G10 P13 2 G P13 C-Programmierung Huber, L G08 I09 1 G I09 Datenbanken Müller, K G10 I09 2 G P13 I09 1 P Teilnehmer TnNr Name Ort 143 Schmidt, M. Bremen 145 Huber, Chr. Augsburg Nimmt_teil AngNr KursNr TnNr 2 G P P I I I Abele, I. Senden 1 G Angebot 149 Kircher, B. Bochum 1 P AngNr KursNr Datum Ort 155 Meier, W. Stuttgart 1 I G München 171 Möller, H. Innsbruck 2 P G Bremen 173 Schulze, B. Stuttgart 1 I G München 177 Mons, F. Essen 1 I G Hamburg 185 Meier, K. Heidelberg 1 I P Innsbruck 187 Karstens, L. Hamburg 2 P P Essen 194 Gerstner, M. Innsbruck 1 I I Stuttgart 2 I P I Hamburg 3 I München 7 Basiskonzepte Darstellung der Miniwelt in Tabellenform (Datenbank = Menge von Relationen/Tabellen) Ansatz Einzige Datenstruktur: Tabelle Relation Saubere mathematische Grundlage: Mengentheorie (vgl. math. Relation) Einfache Operationen, mengenorientiert Abgeschlossenheit: Operationen überführen Tabellen in Tabellen Entwurfstheorie (was sind gute Tabellen?) Relation = Menge von Tupeln (mit atomaren Komponenten) 8 G. Specht: Datenbanksysteme 3-4

5 Eigenschaften Alle Informationen werden als Relationen modelliert Relation = zweidimensionale Tabelle von Werten = Menge von Tupeln (keine Duplikate, keine Reihenfolge!) Jede Zeile - genannt Tupel - entspricht einem Entity oder/und einer Beziehung Die Spalten der Tabelle (Relation) sind benannt und werden als die Attribute bezeichnet Die Reihenfolge der Spalten ist nicht relevant, da sie über ihren Namen identifiziert werden Jedem Attribut ist ein Wertebereich (sog. Domain) zugeordnet. Ein Wertebereich ist eine Menge atomarer Werte, welche - aus Sicht des DBMS - elementar sind, d.h. keine weitere Substruktur mehr aufweisen. Beziehungen werden ausschließlich über Attributwerte realisiert Bem: Wie wir später noch sehen werden, werden die letzten beiden Forderungen im Kontext der objektorientierten Erweiterungen von SQL wieder aufgeweicht bzw. fallengelassen. 9 Mathematische Notation für alle Element aus kein Element aus Subset, Teilmenge, kann auch ganze Menge sein echtes Subset, Teilmenge Vereinigung daraus folgt es gibt Delta Äquivalent (Menge) UND ODER NICHT Äquivalent (Logik) 10 G. Specht: Datenbanksysteme 3-5

6 Schreibweisen und Definitionen Relation R mit Attributen A 1 bis A 5 : R ( A 1, A 2, A 3, A 4, A 5 ) Relation mit Attributen A bis D oft auch: ABCD Domain dom(a i ) = D i Domäne (Wertebereich) von A i Schema sch(r) = {A 1,..., A n } Schema einer Relation Wert val(r) dom(a 1 ) x... x dom(a n ) Wert einer Relation Tupel t = <A 1 :v 1,..., A n :v n > mit v i D i, meist mit fester Reihenfolge der Attribute: t = (v 1,..., v n ), t val(r) 11 Schreibweisen und Definitionen Tupelkomponenten/Attributwerte: t (A i ) = v i oder auch t[a i ] oder t.a i, auch mit A sch(r) : t(a) ( Set of Mappings Definition von Relationen: Relation ist Menge von Abbildungen t j : sch(r) D i, so dass t j (A i ) D i ) K sch (R) heißt Schlüsselkandidat oder auch nur kurz Schlüssel, wenn t, t' : t(k) = t'(k) t = t' und K minimal Primärschlüssel : ein ausgewählter Schlüsselkandidat [1] Fremdschlüssel F in Relation R : F sch(s) und F sch(r) für eine Relation S, in der F Primärschlüssel ist A sch(r) ist Schlüsselattribut, wenn es Teil eines Schlüsselkandidaten ist [1] Eine Relation kann also mehrere Attribute oder Attributkombinationen besitzen, die Schlüsseleigenschaft haben (= Schlüssel(kandidaten)), wie z. B. Personalnummer oder Sozialversicherungsnummer oder (Vorname, Nachname, Straße, Plz, Ort). Einer davon wird dann als bevorzugter Schlüssel (= Primärschlüssel) ausgewählt. 12 G. Specht: Datenbanksysteme 3-6

7 Modellinhärente Integritätsbedingungen des Relationenbasismodells 1. Entity Integrity Primärschlüsselattribute dürfen nie undefiniert (NULL) sein 2. Referential Integrity Fremdschlüssel sind entweder undefiniert (NULL) oder es gibt ein entsprechendes Tupel mit diesem Primärschlüssel in der anderen Relation. 3. Domains Attribute dürfen nur Werte aus der jeweiligen Domain annehmen (oder undefiniert ( NULL )) sein. Nullwerte Nullwerte sind spezielle logische Werte und entsprechen nicht dem Leerzeichen oder dem numerischen Wert Null. Mittels Nullwerten lässt sich eine dreiwertige Logik realisieren: Prädikat = {true false unknown} Hinweise In den folgenden Relationen werden Nullwerte durch "--" dargestellt, im DBS muss stattdessen NULL eingeben werden. Im nächsten Kapitel werden wir noch ausführlicher auf Nullwerte eingehen. 13 Umsetzregeln: E/R-Modell ins Relationenmodell 1. Abbildung von Entity-Typen auf Relationen: Entity-Typ E mit Attributen A i aus Domäne D i (1 i k) wird abgebildet auf k-stellige Relation E(A 1 :D 1, A 2 :D 2,..., A k :D k ) Falls außerdem "E isa F" besteht oder E ein schwacher Entity-Typ, existenz-abhängig von F ist, werden alle Schlüsselattribute von F hinzugenommen. G. Specht: Datenbanksysteme 3-7

8 Umsetzregeln: E/R-Modell ins Relationenmodell 2. Abbildung von Relationship-Typen auf Relationen: 2.1. n:m-beziehungen und alle 3er, 4er,... etc. Beziehungen: Relationship R zwischen Entity-Typen E 1... E n wird abgebildet auf Relation R, deren Attribute aus den Primärschlüsseln der E i bestehen. Gleiche Attributnamen werden durch Umbenennung in R eindeutig gemacht. Falls R eigene Attribute hat, werden diese hinzugenommen :n Beziehung zwischen nur 2 Entitytypen E und F (oft)): Keine Relation R aus Relationship, statt dessen Primärschlüssel von E in Relation F als Fremdschlüssel aufnehmen. Falls Relationship R eigene Attribute hat, müssen diese auch in F aufgenommen werden :1 Beziehung zwischen nur 2 Entitytypen E und F: Keine Relation R aus Relationship, statt dessen Primärschlüssel von E in Relation F oder Primärschlüssel von F in Relation E als Fremdschlüssel aufnehmen isa Beziehungen und Existenzabhängigkeiten "E isa F" und Existenabhängigkeiten werden nicht in Relationen abgebildet, da sonst redundante Tupel der Art isa (133, 133) entstehen. Beispiel (selbst probieren): Name Adresse Vegetarier? Passagier (1,*) hat gebucht Pass# Preis Sitz# Passagier n hat gebucht m Flug (0,*) (1,1) wird ausgeführt Datum Flug# Flugzeug# vgl: n:m Darstellung: Flug n wird ausgeführt 1 (0,*) Hersteller Flugzeug Flugzeug Typ 16 G. Specht: Datenbanksysteme 3-8

9 Bsp.: KursDB 17 Bsp.: Relationen zur KursDB Kurs Kursleiter Vorauss Fuehrt_durch KursNr Titel PersNr Name Gehalt VorNr KursNr AngNr KursNr PersNr G08 Grundlagen I Meier, I G08 P13 1 G G10 Grundlagen II Schulze, H G10 P13 2 G P13 C-Programmierung Huber, L G08 I09 1 G I09 Datenbanken Müller, K G10 I09 2 G P13 I09 1 P Teilnehmer TnNr Name Ort 143 Schmidt, M. Bremen 145 Huber, Chr. Augsburg Nimmt_teil AngNr KursNr TnNr 2 G P P I I I Abele, I. Senden 1 G Angebot 149 Kircher, B. Bochum 1 P AngNr KursNr Datum Ort 155 Meier, W. Stuttgart 1 I G München 171 Möller, H. Innsbruck 2 P G Bremen 173 Schulze, B. Stuttgart 1 I G München 177 Mons, F. Essen 1 I G Hamburg 185 Meier, K. Heidelberg 1 I P Innsbruck 187 Karstens, L. Hamburg 2 P P Essen 194 Gerstner, M. Innsbruck 1 I I Stuttgart 2 I P I Hamburg 3 I München 18 G. Specht: Datenbanksysteme 3-9

10 Sprachen des Basismodells 19 Sprachen des Basismodells Zwei formale (mathematische) Abfragesprachen als Basis für reale Sprachen (z.b.: SQL): Relationenalgebra: operational (wird intern verwendet für die Optimierung und Ausführung) Relationenkalkül: deklarativ (man beschreibt was man haben möchte, nicht wie) 20 G. Specht: Datenbanksysteme 3-10

11 Sprachen des Basismodells cont. Eigenschaften Mengenorientiert (im Gegensatz zu tupelorientiert, navigierend) abgeschlossen d.h. Operationen liefern immer wieder Relationen orthogonal d.h. Operationen lassen sich beliebig kombinieren Mathematische Fundierung: Relationen-Algebra (5 Basisoperatoren: Vereinigung, Differenz, Produkt, Selektion, Projektion) Relationen-Kalkül (vgl. Prädikatenkalkül 1. Ordnung) 21 Relationen-Algebra 22 G. Specht: Datenbanksysteme 3-11

12 Die relationale Algebra: Operatoren σ Selektion π Projektion ρ Umbenennung x Kreuzprodukt A Join (Verbund) Vereinigung Durchschnitt Mengendifferenz Division F Semi-Join (linker) E Semi-Join (rechter) C linker äußerer Join D rechter äußerer Join Charakteristisch Konstruktion der Ergebnis-Relation durch ggf. geschachtelte Anwendung von Algebra-Operationen auf die Ausgangs-Relation(en). 23 Selektion σ F R steht für eine Selektion (Tupelauswahl) angewandt auf Relation R unter Anwendung der Selektionsformel F Anfrage σ TnNr > 155 Teilnehmer TnNr Name Ort 171 Möller, H. Innsbruck 173 Schulze, B. Stuttgart 177 Mons, F. Essen 185 Meier, K. Heidelberg 187 Karstens, L. Hamburg 194 Gerstner, M. Innsbruck Teilnehmer TnNr Name Ort 143 Schmidt, M. Bremen 145 Huber, Chr. Augsburg 146 Abele, I. Senden 149 Kircher, B. Bochum 155 Meier, W. Stuttgart 171 Möller, H. Innsbruck 173 Schulze, B. Stuttgart 177 Mons, F. Essen 185 Meier, K. Heidelberg 187 Karstens, L. Hamburg 194 Gerstner, M. Innsbruck 24 G. Specht: Datenbanksysteme 3-12

13 Selektion cont. Selektionsformel F Vergleiche (<, >, >=, >=, <>) sowie logische Verknüpfungen (,, ) davon über Attributwerte und Konstanten Anfrage: σ (TnNr <= 146) (Ort = Innsbruck ) Teilnehmer TnNr Name Ort 143 Schmidt, M. Bremen 145 Huber, Chr. Augsburg 146 Abele, I. Senden 171 Möller, H. Innsbruck 194 Gerstner, M. Innsbruck Ergebnis: leere Rel. Anfrage: Ergebnis: σ (TnNr < 180) (Ort = Innsbruck') Teilnehmer TnNr Name Ort 171 Möller, H. Innsbruck Formal: sch(σ F R) = sch(r) val(σ F R) = {t val(r) F(t)} 25 Projektion π Attr R Steht für eine Projektion angewandt auf Relation R, wobei Attr die Teilmenge der Attribute ist, auf die R abgebildet (projiziert) wird. Anfrage: π {TnNr,Name} Teilnehmer Teilnehmer TnNr Name Ort 143 Schmidt, M. Bremen 145 Huber, Chr. Augsburg 146 Abele, I. Senden 149 Kircher, B. Bochum 155 Meier, W. Stuttgart 171 Möller, H. Innsbruck 173 Schulze, B. Stuttgart 187 Karstens, L. Hamburg 194 Gerstner, M. Innsbruck Formal: sch(π L R) = L, wobei L sch(r) TnNr Name 143 Schmidt, M. 145 Huber, Chr. 146 Abele, I. 149 Kircher, B. 155 Meier, W. 171 Möller, H. 173 Schulze, B. 187 Karstens, L. 194 Gerstner, M. Anfrage: π {Ort} Teilnehmer Ort Bremen Augsburg Senden Bochum Stuttgart Innsbruck Hamburg val(π L R) = {t(l): t' val(r) t'(l) = t} 26 G. Specht: Datenbanksysteme 3-13

14 Umbenennung a) Explizite Umbenennung: Operator ρ (griechisch roh, von rename) a1) Relationen-Umbenennung: ρ NeuerRelName Rel Bsp: ρ k1 Kursleiter a2) Attribut-Umbenennung ρ NeuerAttrName <- AlterAttrN ame Rel Benennt nur den Spaltennamen um (zur besseren Ausgabe) Bsp: ρ Voraussetzung_fuer <- KursNr Vorauss b) Implizite Umbenennung: Attribut-Umbenennung Es ist sinnvoll, auch den Projektions-Operator gleich mit der Möglichkeit zur Attribut-Umbenennung zu versehen: π NeuerAttrName : AlterAttrName Rel 27 Zusammengesetzte Anfragen Gib Teilnehmer-Nummer und -Name aller Teilnehmer aus Innsbruck aus Anfrage π {TnNr,Name} (σ Ort = Innsbruck' Teilnehmer) Die logische Abarbeitungsreihenfolge 1. Schritt Berechnung des σ-ausdrucks Rel 1 2. Schritt Anwendung des π-operators auf Rel 1 Erg Die alternative Formulierung σ Ort = Innsbruck' (π {TnNr,Name} Teilnehmer) wäre nicht korrekt. Warum? (Selektion enthält nur Ort, keine TnNr bzw. Namen mehr) 28 G. Specht: Datenbanksysteme 3-14

15 Weitere Operatoren R S steht für die Vereinigung (union) der Relationen R und S, wobei R und S strukturgleich sein müssen, d.h. es muss gelten: sch(r) = sch(s). Kurzschreibweise i=1,2,..k R i R 1 R 2... R k R - S R x S steht für die Differenz der Relationen R und S, d.h. alle Tupel von R, die auch in S vorkommen, werden aus R entfernt. (Auch hier gilt sch(r) = sch(s)). steht für das kartesische Produkt der Relationen R und S. A R B a1 b1 a2 b2 S C D c1 d1 c2 d2 c3 d3 Anmerkung R S R - (R - S) ableitbar, wie üblich. Formal sch(r S) = sch(r - (R - S)) = sch(r) val(r S) = val(r) val(s), val(r - S) = val(r) - val(s) sch(r x S) = sch(r).. sch(s) disjunktive Vereinigung val(r x S) = {t t(sch(r)) val(r) t(sch(s)) val(s)} R xs A B C D a1 b1 c1 d1 a1 b1 c2 d2 a1 b1 c3 d3 a2 b2 c1 d1 a2 b2 c2 d2 a2 b2 c3 d3 29 Verknüpfung von Tabellen Kombination von x und σ, gleichzeitig Beispiel für die Verknüpfung von Tabellen Anfrage Welche Kurse (Ausgabe: Kurs-Nummer und -Titel) sind für welche anderen Kurse (Ausgabe: Kurs-Nummer) Voraussetzung? Ausgangsrelationen Anfrage in der Relationalen Algebra Kurs Vorauss KursNr Titel VorNr KursNr G08 Grundlagen I G08 P13 G10 Grundlagen II G10 P13 P13 C-Programmierung G08 I09 I09 Datenbanken G10 I09 P13 I09 π VorNr,Titel,VorausFür:Vorauss.KursNr (σ VorNr = Kurs.KursNr (Vorauss x Kurs)) 30 G. Specht: Datenbanksysteme 3-15

16 Verknüpfung von Tabellen cont. Abarbeitungsreihenfolge 1. Schritt Berechnung Vorauss x Kurs Rel 1 2. Schritt Anwendung von σ VorNr=Kurs.KursNr auf Rel 1 VorNr Vorauss.KursNr Kurs.KursNr Titel G08 P13 G08 Grundlagen I G10 P13 G10 Grundlagen II G08 I09 G08 Grundlagen I G10 I09 G10 Grundlagen I P13 I09 P13 C-Programmierung VorNr Vorauss.KursNr Kurs.KursNr Titel G08 P13 G08 Grundlagen I G08 P13 G10 Grundlagen II G08 P13 I09 Datenbanken G10 P13 G08 Grundlagen I G10 P13 I09 Datenbanken P13 I09 I09 Datenbanken VorNr Titel Vorauss_für G08 Grundlagen I P P13 C-Programmierung I09 Mögliche Umbenennung von Attributen und Änderung der Attribut-Reihenfolge mittels (erweitertem) π-operator π {VorNr, Titel, Vorauss_für: Vorauss.KursNr} Erg-Rel bzw. π {VorNr, Titel, Vorauss_für: Vorauss.KursNr} σ VorNr = Kurs.KursNr (Vorauss x Kurs) 31 Join (Verbund) Die Verknüpfung von Tabellen aufgrund von Attributwert-Beziehungen ist eine häufige Operation im relationalen Datenmodell, sie wird daher durch spezielle Join-Operation explizit unterstützt. R A F S steht für den Join (Verbund) der Relationen R und S unter Verwendung der Verbundbedingung F. R A F S ist semantisch äquivalent zu σ F (R x S) Beispiel (siehe Beispiel zuvor) Vorauss A VorNr = KursNr Kurs entspricht: σ VorNr = Kurs.KursNr (Vorauss x Kurs) A-Ausführungslogik Nested Loops Algorithmus for each Tupel x in Vorauss do for each Tupel y in Kurs do if x.vornr = y.kursnr then erzeuge Resultat-Tupel x y und füge in Ergebnisrelation ein fi done done 32 G. Specht: Datenbanksysteme 3-16

17 Join cont. Beispiel: Gib KursNr und Titel aller Kurse sowie den Namen des Kursleiters aus, die von dem Kursleiter mit der Personalnummer durchgeführt werden KursNr G08 G10 P13 I09 Mögliche Anfrageformulierung π {Kurs.KursNr, Titel, Name} (σ PersNr = (Kurs A (Kursleiter A Fuehrt_durch))) Anmerkung Kurs Titel Grundlagen I Grundlagen II C-Programmierung Datenbanken Kurs.KursNr = Fuehrt_durch.KursNr Kursleiter PersNr Name Gehalt Meier, I Schulze, H Huber, L Müller, K Kursleiter.PersNr = Fuehrt_durch.PersNr Fuehrt_durch AngNr KursNr PersNr 1 G G G G P P I I I Die Join-Bedingung kann auch mittels <, >, >=, >= sowie (,, ) formuliert werden. 33 Join cont. Equi-Join, Theta-Join Joins über = -Bedingung heißen: Equijoin Joins über <, >,, etc heißen: θ-join (Theta-Join) Natural-Join 1. Joins mit "="-Bedingung sind am häufigsten. Gleiche Spalten werden nur einmal benötigt. Hierauf abgestellte Join-Variante: Natural Join R A S steht für natürlichen Verbund (natural join) der Relationen R und S. Wirkungsweise Alle in R und S auftretenden Attribute gleichen Namens werden mittels "="-Bedingung verknüpft und treten in der Ergebnisrelation nur einmal auf! (implizite Projektion!) Haben R und S keine gemeinsamen Attribute, so hat R A S die gleiche Wirkung wie R x S. 34 G. Specht: Datenbanksysteme 3-17

18 Join cont. Beispiel: Die vorige Anfrage mittels natürlichem Verbund formuliert π {KursNr, Titel} Kurs A ((σ PersNr = Kursleiter) A Fuehrt_durch) Anmerkung Unterschied zum Equi-Join Attribute gleichen Namens treten in der Ergebnis-Relation (sowie in allen Zwischenergebnis-Relationen) natürlich jeweils nur einmal auf. Also: sch(r A S) = sch(r) sch(s) 35 Beispiele zur Relationenalgebra Gegeben R A B C 1 a d 3 c c 4 d f 5 d b 6 e f S B D a 100 b 300 c 400 d 200 e 150 T B D a 100 d 200 f 400 g 120 Anfragen und Ergebnisse σd<300 S B D a 100 d 200 e 150 π{a,c} R A C 1 d 3 c 4 f 5 b 6 f π{c}r C d c f b S T B D a 100 b 300 c 400 d 200 e 150 f 400 g 120 S - T B D b 300 c 400 e 150 T - S B D f 400 g 120 R A R.B=S.B S A R.B C S.B D 1 a d a c c c d f d d b d e f e G. Specht: Datenbanksysteme 3-18

19 Beispiele zur Relationenalgebra cont. R AT S AT R A A*100=D S R T A B C D B D A R.B C S.B D A R.B C T.B D 1 a d 100 a a d a a d a d f 200 d d f c a d d d b c c b a d f a d g c c a c c d c c f c c g d f a d f d d f f d f g d b a d b d d b f d b g e f a e f d e f f e f g Äquivalenzumformungen Seien R, S und T drei jeweils geeignet definierte Relationen. Klassifikation algebraischer Umformungen Kommutativität von unären Operationen (σ, π): U 1 U 2 R U 2 U 1 R Kommutativität von binären Operationen (,,, A): R B S S B R Assoziativität von binären Operationen (,,, A): R B (S B T) (R B S) B T Idempotenz (bzw. Zusammenfassung) von unären Operationen (σ, π): U R U U R Distributivität von unären Operationen in bezug auf binäre Operationen: U (R B S) (U R) B (U S) Hinweis Es gilt: Relations-Typ R Relations-Typ S wenn sch(r) = sch(s) Die Reihenfolge der Attribute ist hierbei ohne Bedeutung, d.h. es gilt: R(A,B,C) R(A,C,B) R(C,A,B)... R(C,B,A). 38 G. Specht: Datenbanksysteme 3-19

20 Äquivalenzumformungen von Relationalen-Algebra-Ausdrücken 39 Äquivalenzumformungen von Relationalen-Algebra-Ausdrücken cont. 40 G. Specht: Datenbanksysteme 3-20

21 Äquivalenzumformungen von Relationialen-Algebra-Ausdrücken cont. 41 Erläuterungen zu den Äquivalenzumformungen Gegeben seien die Relationen R(A,B,C), R1(A,B,C), R2(A,B,C), S(D,E) und T(F,G,H) wobei die Wertebereiche der Attribute A bis H jeweils Teilmengen der natürlichen Zahlen sein sollen. Zu 1: σ A<10 C>8 (σ B>8 R) kann in σ B>8 (σ A<10 C>8 R) transformiert werden und umgekehrt. Zu 2: σ B<200 (π {A,B} R) kann in π {A,B} (σ B<200 R) transformiert werden. - Geht man von der rechten Seite aus, d.h. von π {A,B} (σ B<200 R), so kann die Transformation nur dann durchgeführt werden, wenn sich die Selektions-Bedingung lediglich auf Attribute bezieht, die auch in der Projektion spezifiert sind (siehe NB zu Regel 2). Im vorliegenden Fall entspricht Attr(F) der Attributmenge {B} und A entspricht der Attributmenge {A,B}. Die Nebenbedingung ist also erfüllt. D.h. die Transformation in die " "-Richtung ist ebenfalls möglich. Zu 8: Gegeben sei (R A A=D S) A E=F T. Für die " "-Transformation muss folgende Nebenbedingung erfüllt sein: {E,F} ({D,E} {F,G,H}). Dies ist hier der Fall. Der Ausdruck kann somit in R A A=D (S A E=F T) transformiert werden. - Bei (R A A=D S) A A=F T ginge dies z.b. hingegen nicht. Zu 9: π {A} R kann in π {A} π {A,B} R transformiert werden und umgekehrt. Zu 10: σ A<100 B>30 R kann zerlegt werden in σ A<100 σ B>30 R. Umgekehrt kann man σ A<100 σ B>30 R durch Zusammenfassen der Selektionsbedingungen (UND-Verknüpfung) in σ A<100 B>30 R transformieren. 42 G. Specht: Datenbanksysteme 3-21

22 Erläuterungen zu den Äquivalenzumformungen cont. Zu 11: σ B<300 (R1 R2) kann in (σ B<300 R1) (σ B<300 R2) transformiert werden und umgekehrt. Anmerkung: Hier ist keine Nebenbedingung erforderlich, da die Vereinigung nur zwischen Relationen gleichen Typs definiert ist. Zu 12: σ B<300 (R1 R2) kann in (σ B<300 R1) (σ B<300 R2) transformiert werden und umgekehrt. (σ bei R2 kann auch entfallen!) Zu 13: Gegeben sei σ A<300 D>50 (R S). Dieser Ausdruck kann in zwei Selektion überführt werden, indem man die Selektions-Bedingung geeignet aufspaltet. In diesem Fall wäre etwa (σ A<300 R) (σ D>50 S) eine mögliche Aufspaltung. Zu 14: Da ein Verbund R A F S äquivalent zu σ F (R S) ist, gilt das im vorangegangenen Beispiel Gesagte analog übertragen auch hier. Zu 15: Ein Ausdruck der Art π {A,B} {R1 R2) kann stets ausmultipliziert werden zu (π {A,B} R1) (π {A,B} R2). Zu 16: Die Nebenbedingung für die " "-Richtung besagt, dass nach dem Ausmultiplizieren die Projektions-Attribute so gewählt werden müssen, dass sie für die jeweilige Relation auch definiert sind. Im Falle des Ausdruckes π {A,R.B,D} (R S) wäre z.b. (π {A,R.B} R) (π {D} S) eine korrekte Transformation, (π {A} R) (π {R.B, D} S) hingegen nicht. 43 Erläuterungen zu den Äquivalenzumformungen cont. Zu 17: Die Nebenbedingung für die " "-Richtung kann wie folgt interpretiert werden: Sind die in der Verbund-Bedingung angegebenen Attribute eine Teilmenge der in der Projektion angegebenen Attribute (d.h. gilt Attr(F) A), dann kann der Ausdruck ausmultipliziert werden, wobei wieder zu beachten ist, dass die in der Projektion auf der linken Seite angegebenen Attribute wieder korrekt auf ihre Relationen verteilt werden. Der Ausdruck π{a,b,e}(r A B<E S) kann z.b. transformiert werden in (π {A,B} R) B<E (π {E} S). π {A,B,D} (R A B<E S) hingegen wäre nicht transformierbar, da {B,E} {A,B,D}. Die umgekehrte Richtung (" ") ist trivial. Hier sind lediglich die Projektions-Attribute zusammenzufassen. Wichtiger "Spezialfall": π A1 A2 R? (π A1 R) A (π A2 R) " "-Richtung gilt i.a. nicht!! Voraussetzung, damit es doch gilt: lossless join siehe Kapitel 4 Zu 23: R σ B<200 R kann in σ B 200 R transformiert werden und umgekehrt. Zu 26: (σ A<10 R) (σ B>100 R) kann in σ A<10 B 100 R transformiert werden und umgekehrt. 44 G. Specht: Datenbanksysteme 3-22

23 Abgeleitete Operatoren der Relationenalgebra R S Durchschnitt S R wie üblich: R S R - (R - S) A A B a1 a1 b1 R S Division a2 a2 b1 Sei D = R S, dann muss gelten: a3 a3 b1 sch(s) sch(r) a4 b1 sch(d) = sch(r) - sch(s) a1 b2 t D s val(s): < t,s > val(r) a3 b2 a2 b3 Anwendungsbeispiele Welchen Lieferanten liefern alle Teile? Welche Mitarbeiter arbeiten an allen Projekten mit? Welche Kursleiter können alle Kurse halten? R S B b1 b4 a3 b3 a4 b3 a1 b4 a2 b4 a3 b4 Berechnung von D äquivalent zu (1) Temp1 π Attr(R -S) R (2) Temp2 π Attr(R -S) (( S Temp1 ) - R) (3) D Temp1 - Temp2 45 Abgeleitete Operatoren der Relationenalgebra cont. R C F S Left Outer Join (Einseitiger) äußerer-verbund. Alle Tupel der linken Relation (d.h. alle R-Tupel) sind im Ergebnis enthalten. Gibt es für ein Tupel r i R kein S-Tupel, das F erfüllt, so werden die S-Attribute im Ergebnistupel mit NULL aufgefüllt. Analog A a1 a2 a3 a4 a4 a5 R C S R B b1 b2 b4 b2 b5 b1 Left Outer Join R D S Right Outer Join R S Full Outer Join Weitere Join-Varianten B b1 b1 b2 b3 S C c1 c2 c3 c6 RC R.B=S.B S R.A R.B S.B S.C a1 b1 b1 c1 a1 b1 b1 c2 a2 b2 b2 c3 Semijoin R E S:= π (R A S) alle Attribute von R a3 b Nullwert! a4 b2 b2 c3 a4 b Nullwert! a5 b1 b1 c1 a5 b1 b1 c2 Geeignet für Fragen: wie viele Joinpartner existieren zu S in R. 46 G. Specht: Datenbanksysteme 3-23

24 Bsp. für Query-Auswertung: Weinfreund DB-Schema: Weinfreund (P#, Name, Vorname) Konsum (P#, W#, Datum, Menge) Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte) Wieviel Prozent Alkohol haben die 78 er Weine des Weinbergs Würzburger Stein? π {Prozent, w#} (σ (Jahrgang = 1978) (Weinberg = Würzburger Stein ) (Wein)) 47 Bsp. Weinfreund cont. DB-Schema: Weinfreund (P#, Name, Vorname) Konsum (P#, W#, Datum, Menge) Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte) Ermittle Name und Vorname von Weinfreunden von Silvaner und Riesling π {Name, Vorname} (Weinfreund A ( Konsum A (σ (Rebsorte = Silvaner ) (Rebsorte= Riesling ) (Wein)))) 48 G. Specht: Datenbanksysteme 3-24

25 Bsp. Weinfreund cont. DB-Schema: Weinfreund (P#, Name, Vorname) Konsum (P#, W#, Datum, Menge) Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte) Gesucht sind Name und Vorname von Weinfreunden, die an einem Tag mehr als 10 Gläser 86 er Obereisenheimer Höll getrunken haben, sowie der dazugehörige Alkoholgehalt. π {Name, Vorname, Prozent} (σ (Menge > 10) (Weinberg= Obereisenheimer Höll ) (Jahrgang=1986) (Weinfreund A Konsum A Wein) ) 49 Bsp. Weinfreund cont. DB-Schema: Weinfreund (P#, Name, Vorname) Konsum (P#, W#, Datum, Menge) Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte) W# aller Weine mit mehr Prozent Alkohol als Riesling 1993 π {W2, W#} (σ (w1.rebsorte= Riesling ) (Jahrgang=1993)) (Wein W1 A Wein W2)) W1.Prozent < W2.Prozent 50 G. Specht: Datenbanksysteme 3-25

26 Aggregation Mengenorientierte Operation, die zuerst eine Partitionierung einer Relation in Teilmengen gemäß einer Gruppe von Attributwerten vornimmt (Gruppierung), dann eine Aggregatsfunktion (z.b. sum, min, max, avg, etc.) auf jeder Teilmenge auswertet. Das Ergebnis ist eine Relation, die für jede Gruppe ein Tupel mit dem Aggregationswert enthält. Sei R(x1,..., xn, y,...) eine Relation, mit Gruppierungsattributen X = {x1,..., xn} und Aggregationsattribut y, und agg eine Aggregationsfunktion auf y: groupby (R, X, agg, y, duplicates) mit duplicates {distinct, all}. 51 Aggregation cont. Häufig verwendete Aggregations-Funktionen: COUNT SUM MIN MAX AVG 52 G. Specht: Datenbanksysteme 3-26

27 Aggregation cont. Wie hoch ist jeweils der durchschnittliche Alkoholgehalt der Jahrgänge 1985 und 1986? σ (Jahrgang=1985) (Jahrgang=1986) (groupby(wein, Jahrgang, AVG, Prozent, all)) 53 Aggregation cont. Anmerkung: Aggregationen sollten im Allgemeinen auf Mengen mit Duplikaten (Multisets) angewendet werden, sonst entstehen falsche Ergebnisse. Beispiel: Annahme, es gibt einen weiteren 85 er Wein mit 12.0%, dann ergäbe AVG({11, 10, 12, 12}) mittels distinct dasselbe (jetzt falsche) Resultat. 54 G. Specht: Datenbanksysteme 3-27

28 Query Optimierung Motivationsbeispiel: Sei die Kardinalität der Relationen R und S jeweils Naiver Ansatz: Join wie in Definitionen als σ (R x S) berechnen 10 8 = 100 Mio Tupelzugriffe, je Zugriff nur 10-6 sec Antwortzeit: 100sec!!! Viel zu lange, praktisch untragbar Nichtalgebraische Optimierungen D.h. einzelne Operationen günstiger implementieren. Komplexitäten: Selektion: Relationen-Scan (sequentieller Durchlauf) O(n) Index als B-Baum O(log n) Index als Hash O(1) hoffentlich Projektion naiv O(n 2 ) mit Index Mit Hashindex O(n log n) <= meist O(n) <= wirklich gute Impl. + Kosten für Anlegen des Index 56 G. Specht: Datenbanksysteme 3-28

29 Nichtalgebraische Optimierungen cont. Join nested-loop-join (naiv) O(n 2 ) for i:=1 to R do for j := 1 to S do if r i θ s j then Rel := Rel append(r, s); sort-merge-join O(n log n) R A S A = B R sei sortiert nach A S sei sortiet nach B, 3,, 2,, 4,, 4,, 4,, 4,, 5,, 6, 57 Nichtalgebraische Optimierungen cont. Hash Join R A S O(n) (sei R =n) 1. R sei klein (z.b. Join- oder Selektionsausgabe) 2. auf S.B liege Hash Fragen des Optimierers (Programm): Können bestehende Indexe ausgenutzt werden? Rentiert es sich, einen temporären Index anzulegen, so dass trotz Indexerzeugung die Query-Auswertung schneller wird (auch Indexe brauchen Platz!). 58 G. Specht: Datenbanksysteme 3-29

30 2. Algebraische Optimierungen Ausnützen der Gesetze der relationalen Algebra als Rechenregeln, um möglichst kleine Zwischenrelationen zu erhalten! 1.RA (S A T) = (R A S)AT => optimale Joinreihenfolge 2.σ F1 (σ F2 (R)) = σ F1 F2 (R) 3.σ F (R A S) = σ F (R)A S falls F nur Attribute aus R betrifft 4.σ F (R A S) = R A σ F (S) falls F nur Attribute aus S betrifft 5.σ F (π A (R)) = π A (σ F (R)) falls Attribute(F) A usw. Dazu wird eine komplette Query vom Optimierer in einen Operatorbaum transformiert und dieser dann transformiert. 59 Algebraische Optimierungen cont. Beispiel: Name, Vorname von Weinfreunden, die an einem Tag mehr als 10 Gläser 86 er Obereisenheimer Höll getrunken haben, so wie der zugehörige Alkoholgehalt π Name, Vorname, Prozent (σ Menge > 10 Weinberg = Obereisenheimer Höll Jahrgang = 1986 (Weinfreund A (Konsum A Wein))) Operatorbaum: 60 G. Specht: Datenbanksysteme 3-30

31 Baumtransformationen zur Optimierung z.b. Selektionen und Projektionen zu den Blättern schieben, d.h. heuristisch möglichst kleine Zwischenergebnisse produzieren. Ergebnis: Jetzt viel kleinere Zwischenergebnisse => Joins (n log m) viel billiger Gute Optimierer bauen ist schwierig, da allein das Problem der richtigen Joinreihenfolge NP-vollständig ist. 61 Abschließende Bemerkungen zur Relationen-Algebra In der Relationalen Algebra ist kein Komplementoperator definiert. Grund: im Allgemeinen -große Relationen (außer bei endlichen Domänen) Relationen-Algebra als Datenbanksprache nur bei den ersten relationalen DBMS-Prototypen als Anfragesprache verwendet Jedoch bis heute wichtige formale Grundlage für DBMS-interne Anfrage- Verarbeitung und Optimierung. Darüberhinaus dient die Relationale Algebra als theoretisches Maß für die Ausdrucksmächtigkeit relationaler Datenbank-Sprachen relationale Vollständigkeit Relationale Algebra ist nicht rein deskriptiv, wegen Reihenfolgen abhängigkeiten (funktionale Sprache). Jedoch: Äquivalenz-Umformungen erlauben Optimierung. 62 G. Specht: Datenbanksysteme 3-31

32 Relationen-Kalkül 63 Relationen-Kalkül Relationen-Algebra Konstruktion der Ergebnisrelation durch sukzessive (geschachtelte) Anwendung von Algebra-Operatoren auf die Ausgangsrelationen ( prozedurale Vorgehensweise) Relationen-Kalkül liegt andere Philosophie zugrunde: Beschreibung, welche Bedingungen (Prädikate) die Tupel der Ergebnisrelation erfüllen müssen, vgl. Prädikatenkalkül ( deklarative Vorgehensweise) 64 G. Specht: Datenbanksysteme 3-32

33 Beispiel Gegeben seien die folgenden Relationen: Vorauss(VorNr, KursNr) Kurs(KursNr, Titel) Angebot(AngNr, KursNr, Datum, Ort) Zu beantworten sei folgende Anfrage: Gib für alle Kurse, die zwischen dem und stattfanden und den Kurs G08 als Voraussetzung haben, die KursNr, den Titel, das Datum und den Ort aus. 65 Anfrageformulierung In Algebra (schrittweise Konstruktion der Ergebnismenge) π KursNr, Titel, Datum, Ort (( Kurs A σ < Datum < Angebot) A (σ VorNr = 'G08' Vorauss)) Tupel-Relationenkalkül (prädikative Beschreibung der Ergebnismenge) { t ( a ( v ( k (Kurs(k) Angebot(a) Vorauss(v) k.kursnr = a.kursnr k.kursnr = v.kursnr a.datum > a.datum < v.vornr = 'G08' t.kursnr = k.kursnr t.titel = k.titel t.datum = a.datum t.ort = a.ort )))) } 66 G. Specht: Datenbanksysteme 3-33

34 Anfrageformulierung cont. Relationenkalkül vgl. Prädikatenlogik 1. Stufe Tupel-Relationenkalkül vs. Domain-Relationenkalkül : Variablen für ganze Tupel bzw. für einzelne Attributwerte 67 Tupel-Relationenkalkül (TRC) Atome 1. R(t) : R = Relationenname t = Tupelvariable Aussage: Tupel t ist in R enthalten 2. X Θ Y: X, Y = Konstanten oder Tupelkomponenten t[i] (t = Tupelvariable, i = i-te Tupelkomponente) Θ = arithm. Vergleichsoperator (<, >, =,...) Alle Tupel einer Relation haben eine konstante Stelligkeit. Falls hierauf explizit Bezug genommen wird, so schreiben wir t (s). 68 G. Specht: Datenbanksysteme 3-34

35 Tupel-Relationenkalkül (TRC) freie / gebundene Variablen : Analogie: gebundene Variablen lokale Variablendeklaration einer Prozedur, kann nicht von außen referenziert werden. freie Variablen globale Variablen, außerhalb der betrachteten Prozedur deklariert. Sei eine freie Tupelvariable t global bzgl. Formel F, dann entspricht ( t) bzw. ( t) in etwa der Deklaration der Variablen t. 69 Tupel-Relationenkalkül (TRC) cont. Formeln, freie und gebundene Variablen im TRC: Jedes Atom ist eine Formel. Alle in einem Atom auftretenden Tupelvariablen sind frei Falls F1 und F2 Formeln sind, dann sind auch F1, (F1), F1 F2 und F1 F2 Formeln. Wenn F eine Formel ist, dann ist ( t F)" auch eine Formel. Alle in F auftretenden freien Tupelvariablen t werden an t in der Formel " t F" gebunden. Der Status anderer Tupelvariablen in F ändert sich dadurch nicht Wenn F eine Formel ist, dann ist ( t F)" auch eine Formel. Alle in F auftretenden freien Tupelvariablen t werden an t in der Formel " ( t F)" gebunden. Der Status anderer Tupelvariablen in F ändert sich dadurch nicht Nichts anderes ist eine Formel 70 G. Specht: Datenbanksysteme 3-35

36 Tupel-Relationenkalkül (TRC) cont. Anfrage im TRC: { t F(t) } mit t als einziger freien Tupelvariablen in Formel F Anmerkung: Eine Anfrage des TRC liefert nicht notwendig eine endliche Tupelmenge! 71 Beispiel Vereinigung von R1 und R2: { t R1(t) R2(t) } Anmerkungen: Jedes Tupel hat auch eine feste Stelligkeit. R1 und R2 müssen also entsprechend kompatibel sein. In dieser einfachen Form sind alle Komponenten (Attribute) auch domainkompatibel. Gib alle Tupel t, die nicht in Relation R vorkommen, aus! (Negation): { t R(t) } Anmerkungen: Welche Ergebnistupel (Schema)? Vereinfachende Annahme: Schema von R Welche Ausprägungen? Vereinfachend: Komplement von R bzgl. Produkt der Attributdomains Resultat von Domains abhängig! evtl. nicht endlich! 72 G. Specht: Datenbanksysteme 3-36

37 Beispiel cont. Projektion auf Attribute (Komponenten) i 1, i 2,..., i k von R { t (k) u ( R(u) t[1] = u[i 1 ]... t[k] = u[i k ] ) } Selektion aller Tupel aus R, die Bedingung F erfüllen: { t R(t) F (t) } F(t) steht hier stellvertretende für die konkrete Bedingung an die Tupelkomponente(n) z.b. (t[1] = 17) (t[3] = 24) Differenz zweier Relationen R und S: { t R(t) S(t) } Kartesisches Produkt von R und S: { t (r+s) ( u (r) ( v (s) ( R(u) S(v) t[1] = u[1]... t[r] = u[r] t[r+1] = v[1]... t[r+s] = v[s] ) } 73 Sicherer Tupel-Relationenkalkül Problem: Bei bisheriger TRC-Definition können unendlich Ergebnismengen auftreten { t R(t) } : nur Einschränkung hinsichtlich Stelligkeit von t ( R), hinsichtlich des Domains aber nicht beschränkt Überlegung: 1. Wir fragen nach Werten aus der Datenbank, nicht von sonst irgendwoher 2. Jede Relation in der konkreten Datenbank ist endlich, damit ist auch der betrachteten Datenbank-Zustand endlich 3. Einschränkung: Als Domain (für die Auswertung von Anfragen) werden nur in der DB vorkommende Werte oder in der Anfrage auftretende Konstanten zugelassen 74 G. Specht: Datenbanksysteme 3-37

38 Definition Safety Eine Formel F des TRC heißt sicher, wenn a) keine - Quantoren vorkommen b) bei F 1 F 2, F 1 und F 2 jeweils nur eine freie Variable haben, und zwar die gleiche c) bei (maximalen) konjunktiven Teilformeln F 1 F 2... F n alle freien Tupelkomponenten in den F i begrenzt sind: F i nicht negiert, kein arithm. Vergleich, freie Tupelvariable t alle Komp. von t begrenzt Fi t[a] = c Fi t[a] = t'[a'] begrenzt oder Fi c = t[a], für c... Konstante t[a] begrenzt oder Fi t'[a'] = t [a] und t' [a'] begrenzt t[a] d) Negation ( ) nur auf Termen innerhalb einer Konjunktion wie in c) erlaubt 75 Definition Safety cont. Bemerkung zu a) ( t) F(t) ( t) ( F(t) )... d.h. keine Einschränkung Alternativ: nur in der Form: ( t) ( R(t)...)... und bei : ( t) ( R(t)...) 76 G. Specht: Datenbanksysteme 3-38

39 Relationale Vollständigkeit Satz: Relationenalgebra und sicherer Relationenkalkül (TRC) sind äquivalent Beweisidee: Finde zu jedem Ausdruck in Relationenalgebra einen sicheren TRC Ausdruck und umgekehrt (siehe Lehrbücher) Relational Completeness Eine Anfragesprache für das Relationenmodell heißt relational vollständig, wenn sie (mindestens) so ausdruckskräftig wie die Relationenalgebra (oder der sichere TRC) ist [Codd 70] 77 G. Specht: Datenbanksysteme 3-39