3. Grundlagen des Relationalen Datenmodells

Transkript

1 3. Grundlagen des Relationalen Datenmodells Grundkonzepte Relationale Invarianten Primärschlüsselbedingung Fremdschlüsselbedingung (referentielle Integrität) Wartung der referentiellen Integrität Abbildung ERM / UML RM Nachbildung von Generalisierung und Aggregation im RM Relationenalgebra Mengenoperationen relationale Operatoren: Selektion, Projektion, Join Kapitel 4: Die Standard-Anfragesprache SQL Kapitel 5: Logischer DB-Entwurf (Normalformenlehre) Kapitel 6: Datendefinition und -kontrolle DB-Anwendungsprogrammierung: ->DBS2 WS3/4, Prof. Dr. E. Rahm 3 - Lernziele Grundbegriffe des Relationenmodells Relationale Invarianten, insbesondere Vorkehrungen zur Wahrung der referentiellen Integrität Abbildung von ER/UML-Diagrammen in Relationenschema (und umgekehrt) Operationen der Relationenalgebra: Definition und praktische Anwendung WS3/4, Prof. Dr. E. Rahm 3-2

2 Relationenmodell - Entwicklung Vorschlag von Edgar F. Codd (IBM) A Relational Model of Data for Large Shared Data Banks. Commun. ACM 3(6): (970) Konzept, Relationenalgebra Erste Prototypen relationaler DBS (ab ca. 975) System R (IBM Research, San Jose), u.a. Query-Sprache SEQUEL / SQL (D. Chamberlin), ACID-Techniken (Jim Gray et al.), Query-Optimierung etc. Ingres (Berkeley Univ.) unter Leitung von Mike Stonebraker, Query-Sprache QUEL seit ca. 980: kommerzielle relationale DBS zunächst Oracle (Larry Ellison): 979 Version 2 IBM DB2 WS3/4, Prof. Dr. E. Rahm 3-3 Genealogie ausgewählter relationaler DBS Berkeley Ingres Ingres VectorWise (Actian) Informix Postgres PostgreSQL Illustra Netezza IBM Informix Greenplum (IBM) (EMC) Sybase ASE Microsoft SQL Server Microsoft Access msql MySQL Sybase IQ (Oracle) (SAP) Oracle RDB (DEC) (Oracle) Teradata (NCR) (Teradata) System-R (IBM) SQL/DS DB2 DB2 z/os DB2 for VM DB2 UDB dbase (Ashton-Tate) (Borland) (dbase Inc.) GDBM SQLite Berkeley DB HSQLDB DBM NDBM VDN/RDS DDB4 (Nixdorf) (Siemens) AdabasD (Software AG) SAP DB (MySQL) MaxDB (SAP) Adabas (Software AG) (Oracle) SAP HANA Quelle: Hasso Plattner Institut, Potsdam. WS3/4, Prof. Dr. E. Rahm 3-4

3 Relationenmodell - Übersicht Datenstruktur: Relation (Tabelle) einzige Datenstruktur (neben atomaren Werten) alle Informationen ausschließlich durch Werte dargestellt Integritätsbedingungen auf/zwischen Relationen: relationale Invarianten Operatoren auf (mehreren) Relationen Vereinigung, Differenz Kartesisches Produkt Projektion Selektion zusätzlich: Änderungsoperationen (Einfügen, Löschen, Ändern) WS3/4, Prof. Dr. E. Rahm 3-5 Relationenmodell - Grundkonzepte Attribut Definitionsbereich Primärschlüssel } wie im ERM Entity-Menge (Klassen) Relationship-Menge (Assoziationen) Relation normalisierte Relation R (A, A 2,..., A n ) W (A ) W (A 2 )... W (A n ) D i D j D k Relation = Untermenge des kartesischen Produktes der Attributwertebereiche nur einfache Attibute (atomare Werte)! Darstellungsmöglichkeit für R: n-spaltige Tabelle (Grad der Relation: n) Kardinalität: Anzahl der Sätze (Tupel) Relation ist eine Menge: Garantie der Eindeutigkeit der Zeilen/Tupel über Primärschlüssel (ggf. mehrere Schlüsselkandidaten) WS3/4, Prof. Dr. E. Rahm 3-6

4 Normalisierte Relationen in Tabellendarstellung FAK FNR FNAME... WI Wirtschaftswiss.... MI Math./Informatik... STUDENT MATNR SNAME FNR W-ORT Coy MI Halle Abel WI Leipzig Maier MI Delitzsch Schulz MI Leipzig Grundregeln: Jede Zeile (Tupel) ist eindeutig und beschreibt ein Objekt (Entity) der Miniwelt Die Ordnung der Zeilen ist ohne Bedeutung Die Ordnung der Spalten ist ohne Bedeutung, da sie eindeutigen Namen (Attributnamen) tragen Jeder Datenwert innerhalb einer Relation ist ein atomares Datenelement Alle für Benutzer relevanten Informationen sind ausschließlich durch Datenwerte ausgedrückt Darstellung von Beziehungen durch Fremdschlüssel (foreign key) Attribut, das in Bezug auf den Primärschlüssel einer anderen (oder derselben) Relation definiert ist (gleicher Definitionsbereich) WS3/4, Prof. Dr. E. Rahm 3-7 Anwendungsbeispiel ER-Diagramm Fakultät gehört-zu Dekan ist- eingeschr.- in n n Prof n Prüfung m Student Relationales Schema FAK FNR FNAME DEKAN STUDENT PROF PNR PNAME FNR FACHGEB MATNR SNAME FNR W-Ort PRÜFUNG PNR MATNR FACH DATUM NOTE WS3/4, Prof. Dr. E. Rahm 3-8

5 Relationale Invarianten inhärente Integritätsbedingungen des Relationenmodells (Modellbedingungen). Primärschlüsselbedingung (Entity-Integrität) Eindeutigkeit des Primärschlüssels keine Nullwerte! 2. Fremdschlüsselbedingung (referentielle Integrität): zugehöriger Primärschlüssel muss existieren d.h. zu jedem Wert (ungleich Null) eines Fremdschlüsselattributs einer Relation R2 muss ein gleicher Wert des Primärschlüssels in irgendeinem Tupel von Relation R vorhanden sein Graphische Notation: STUDENT referenzierende Relation FNR FAK referenzierte Relation WS3/4, Prof. Dr. E. Rahm 3-9 Relationale Invarianten (2) Fremdschlüssel und zugehöriger Primärschlüssel tragen wichtige interrelationale (bzw. intrarelationale) Informationen gleicher Wertebereich gestatten Verknüpfung von Relationen Fremdschlüssel können Nullwerte aufweisen, wenn sie nicht Teil eines Primärschlüssels sind. Fremdschlüssel ist zusammengesetzt, wenn zugehöriger Primärschlüssel zusammengesetzt ist eine Relation kann mehrere Fremdschlüssel besitzen, die die gleiche oder verschiedene Relationen referenzieren Zyklen sind möglich (geschlossener referentieller Pfad) eine Relation kann zugleich referenzierende und referenzierte Relation sein (selbstreferenzierende Tabelle) WS3/4, Prof. Dr. E. Rahm 3-0

6 Relationale Invarianten (3) DDL-Spezifikation in SQL bei CREATE TABLE Primary KEY- und FOREIGN KEY-Klauseln Angaben für Attributdefinition : - Attributname sowie Datentyp - Default-Werte - Eindeutigkeit (UNIQUE bzw. PRIMARY KEY) - FOREIGN-KEY-Klausel - Verbot von Nullwerten (NOT NULL) CREATE TABLE STUDENT (MATNR INT, SNAME VARCHAR (50) NOT NULL, FNR INT, PRIMARY KEY (MATNR), FOREIGN KEY (FNR) REFERENCES FAK ) CREATE TABLE FAK (FNR INT PRIMARY KEY, FNAME VARCHAR(50) NOT NULL, DEKAN INT REFERENCES PROF... ) WS3/4, Prof. Dr. E. Rahm 3 - Wartung der referentiellen Integrität Gefährdung bei INSERT, UPDATE, DELETE R (FAK) FNR R2 (STUDENT) Fall 0: INSERT auf R, DELETE auf R2 Fall : INSERT bzw. UPDATE auf FS der referenzierenden (abhängigen) Relation R2: Ablehnung falls kein zugehöriger PS-Wert in referenzierter Relation R besteht Fall 2: DELETE auf referenzierter Relation R bzw. UPDATE auf PS von R. Unterschiedliche Folgeaktionen auf referenzierender Relation R2 möglich, um referentielle Integrität zu wahren WS3/4, Prof. Dr. E. Rahm 3-2

7 Wartung der referentiellen Integrität (2) SQL-Standard erlaubt Spezifikation der referentiellen Aktionen für jeden Fremdschlüssel Sind Nullwerte verboten? NOT NULL Löschregel für Zielrelation (referenzierte Relation R): ON DELETE {NO ACTION CASCADE SET NULL SET DEFAULT } Änderungsregel für Ziel-Primärschlüssel (Primärschlüssel oder Schlüsselkandidat): ON UPDATE {NO ACTION CASCADE SET NULL SET DEFAULT} Dabei bedeuten: NO ACTION (Voreinstellung): Operation wird nur zugelassen, wenn keine zugehörigen Sätze (Fremdschlüsselwerte) vorhanden sind. Es sind folglich keine referentiellen Aktionen auszuführen CASCADE: Operation kaskadiert zu allen zugehörigen Sätzen SET NULL: Fremdschlüssel wird in zugehörigen Sätzen zu Null gesetzt SET DEFAULT: Fremdschlüssel wird auf einen benutzerdefinierten Default-Wert gesetzt WS3/4, Prof. Dr. E. Rahm 3-3 Anwendungsbeispiel CREATE TABLE TEIL ( TNR INT PRIMARY KEY, BEZEICHNUNG... ) CREATE TABLE LIEFERANT (LNR INT PRIMARY KEY, LNAME... ) CREATE TABLE LIEFERUNG (TNR INT, LNR INT, DATUM... PRIMARY KEY (TNR, LNR, DATUM), FOREIGN KEY (TNR) REFERENCES TEIL, NOT NULL, ON DELETE OF TEIL NO ACTION ON UPDATE OF TEIL.TNR CASCADE, FOREIGN KEY (LNR) REFERENCES LIEFERANT, NOT NULL, ON DELETE OF LIEFERANT NO ACTION, ON UPDATE OF LIEFERANT.LNR CASCADE ) TEIL LIEFERANT LIEFERUNG WS3/4, Prof. Dr. E. Rahm 3-4

8 Abbildung ERM / UML -> RM E R E2 Relation Relation 2? Relation 3 Kriterien Informationserhaltung Minimierung der Redundanz Minimierung des Verknüpfungsaufwandes Natürlichkeit der Abbildung keine Vermischung von Objekten Verständlichkeit Regeln: Jeder Entity-Typ muss als eigenständige Relation (Tabelle) mit einem eindeutigen Primärschlüssel definiert werden. Relationship-Typen können als eigene Relationen definiert werden, wobei die Primärschlüssel der zugehörigen Entity-Typen als Fremdschlüssel zu verwenden sind. WS3/4, Prof. Dr. E. Rahm Entitymengen mit n: - Verknüpfung ABT n ABT-ZUGEH PERS ABT ABT-ZUGEH * PERS.) Verwendung von drei Relationen ABT (ANR, ANAME,...) PERS (PNR, PNAME,...) ABT-ZUGEH (PNR, ANR, ) 2.) Besser: Verwendung von zwei Relationen ABT (ANR, ANAME,...) PERS (PNR, PNAME,..., ANR) Regel: n:-beziehungen lassen sich ohne eigene Relation darstellen. Hierzu wird in der Relation, der pro Tupel maximal Tupel der anderen Relation zugeordnet ist, der Primärschlüssel der referenzierten Relation als Fremdschlüssel verwendet WS3/4, Prof. Dr. E. Rahm 3-6

9 Entitymenge mit : Verknüpfung PERS Ehemann Ehefrau EHE Ehe 0.. PERS 0...) Verwendung von zwei Relationen PERS (PNR, PNAME,...) EHE ( PNR, GATTE,...) 2.) Verwendung von einer Relation PERS (PNR, PNAME,..., GATTE) Unterscheidung zu n:? WS3/4, Prof. Dr. E. Rahm 3-7 Entitymenge mit m:n-verknüpfung Stückliste TEIL n Struktur * TEIL Darstellungsmöglichkeit im RM: m Struktur * TEIL STRUKTUR A B G D 5 (TNR, BEZ, MAT, BESTAND) (OTNR, UTNR, ANZAHL) C 2 E Teil TNR BEZ MAT BESTAND A Getriebe - 0 B Gehäuse Alu 0 C Welle Stahl 00 D Schraube Stahl 200 E Kugellager Stahl 50 F Scheibe Blei 0 G Schraube Chrom 00 Struktur OTNR UTNR Anzahl A B A C 5 A D 8 B D 4 B G 2 C D 4 C E 2 Regel: Ein n:m-relationship-typ muss durch eine eigene Relation dargestellt werden. Die Primärschlüssel der zugehörigen Entitymengen treten als Fremdschlüssel auf. WS3/4, Prof. Dr. E. Rahm 3-8

10 3 Entitymengen mit m:n-verknüpfung Lieferant p Teil n Lieferung m Projekt Datum Anzahl LIEFERANT (LNR, LNAME, LORT,...) PROJEKT (PRONR, PRONAME,PORT,...) TEIL (TNR, TBEZ, GEWICHT,... ) LIEFERUNG ( WS3/4, Prof. Dr. E. Rahm 3-9 M Entity-Mengen (Stern-Schema) Kunde Produkt Verkauf Filiale Anzahl Umsatz Zeit KUNDE (KNR, KNAME, Geschlecht,...) PRODUKT (PNR, PNAME, PTyp,...) FILIALE (FNR, Ort, Land,... ) ZEIT (ZNR, Tag, Monat, Jahr, Quartal...) WS3/4, Prof. Dr. E. Rahm 3-20

11 Abbildung mehrwertiger Attribute bzw. schwacher Entitymengen PNR Name PERS Lieblingsessen Vorname Alter n KIND Darstellungsmöglichkeit im RM PERS (PNR, NAME...) WS3/4, Prof. Dr. E. Rahm 3-2 Abbildungen von Generalisierung und Aggregation im RM RM sieht keine Unterstützung der Abstraktionskonzepte vor keine Maßnahmen zur Vererbung (von Struktur, Integritätsbedingungen, Operationen) Simulation der Generalisierung und Aggregation eingeschränkt möglich Generalisierungsbeispiel: UNI-ANGEH ID: int Name: String ANGESTELLTE Tarif: String Beamte TECHNIKER Erfahrung: String WISS-MA Gebiet: String WS3/4, Prof. Dr. E. Rahm 3-22

12 Generalisierung relationale Sicht pro Klasse Tabelle (3 Varianten) oder insgesamt nur Tabelle Lösungsmöglichkeit : vertikale Partitionierung jede Instanz wird entsprechend der Klassenattribute in der IS-A-Hierarchie zerlegt und in Teilen in den zugehörigen Klassen (Relationen) gespeichert. nur das ID-Attribut wird dupliziert UNI-ANGEH ANGESTELLTE WISS-MA TECHNIKER ID Name ID Tarif ID Gebiet ID Erfahrung 007 Garfield 007 E4 007 XML 23 Linux 23 Donald 23 E 765 Cloud 333 Daisy 333 E9 765 Grouch 765 E3 Ernie Eigenschaften geringfügig erhöhte Speicherungskosten, aber hohe Aufsuch- und Aktualisierungkosten Integritätsbedingungen: TECHNIKER.ID ANGESTELLTE.ID, usw. Instanzenzugriff erfordert implizite oder explizite Verbundoperationen Beispiel: Finde alle TECHNIKER-Daten WS3/4, Prof. Dr. E. Rahm 3-23 Generalisierung relationale Sicht (2) Lösungsmöglichkeit 2: horizontale Partitionierung jede Instanz ist genau einmal und vollständig in ihrer Hausklasse gespeichert. keinerlei Redundanz UNI-ANGEH ID Name Ernie WISS-MA ID Gebiet Name Tarif 007 XML Garfield E4 765 Cloud Grouch E3 ANGESTELLTE ID Name Tarif 333 Daisy E9 TECHNIKER ID Erfahrung Name Tarif 23 Linux Donald E Eigenschaften niedrige Speicherungskosten und keine Änderungsanomalien Eindeutigkeit von ID zwischen Relationen aufwändiger zu überwachen Retrieval kann rekursives Suchen in Unterklassen erfordern. explizite Rekonstruktion durch Relationenoperationen ( => Beispiel: Finde alle ANGESTELLTE WS3/4, Prof. Dr. E. Rahm 3-24

13 Generalisierung relationale Sicht (3) Lösungsmöglichkeit 3: volle Redundanz eine Instanz wird wiederholt in jeder Klasse, zu der sie gehört, gespeichert. sie besitzt dabei die Werte der Attribute, die sie geerbt hat, zusammen mit den Werten der Attribute der Klasse UNI-ANGEH ANGESTELLTE WISS-MA ID Name ID Name Tarif ID Name Tarif Gebiet 007 Garfield 007 Garfield E4 007 Garfield E4 XML 23 Donald 23 Donald E 765 Grouch E3 Cloud 333 Daisy 333 Daisy E9 765 Grouch 765 Grouch E3 TECHNIKER Ernie ID Name Tarif Erfahrung 23 Donald E Linux Eigenschaften hoher Speicherplatzbedarf und Auftreten von Änderungsanomalien. einfaches Retrieval, da nur die Zielklasse (z. B. ANGESTELLTE) aufgesucht werden muss WS3/4, Prof. Dr. E. Rahm 3-25 Generalisierung: Verfahrensvergleich Vertikale Partitionierung Horizontale Partitionierung Volle Redundanz Änderungen Lesen WS3/4, Prof. Dr. E. Rahm 3-26

14 Wide Table -Realisierung Verwendung einer gemeinsamen Tabelle pro Klassenhierarchie Verwendung eines Diskrimatorattributs zur Angabe der Klasse Minimale Redundanz ermöglicht effiziente Verwaltung Keine explizite Modellierung der Klassenhierarchie und Is-A- Semantik Nutzer müssen Abhängigkeiten bei Lese- und Änderungsoperationen selbst beachten UNI-ANGEH ID Name Typ Tarif Gebiet Erfahrung 007 Garfield WISS-MA E4 XML NULL 23 Donald TECHNIKER E NULL Linux 333 Daisy ANGESTELLTE E9 NULL NULL 765 Grouch WISS-MA E3 Cloud NULL Ernie UNI-ANGEH NULL NULL NULL WS3/4, Prof. Dr. E. Rahm 3-27 Aggregation relationale Sicht Fakultät UNIVERSITÄT Name: String Gründung: int #Fak: int * Name: String #Profs: int Rechenzentrum * Institut Leiter: String #PC: int Universität ID Name Gründung #Fak UL Univ. Leipzig TUD TU Dresden Fakultät FID Uni Name #Profs 23 UL Theologie 4 32 UL Mathe/Informatik 28 Institut ID FID Name Neutestamentliche Wissenschaft Alttestamentliche Wissenschaft Praktische Theologie Informatik Komplexe Objekte erfordern Zerlegung über mehrere Tabellen WS3/4, Prof. Dr. E. Rahm 3-28

15 Sprachen für das Relationenmodell Datenmodell = Datenobjekte + Operatoren im RM wird vereinheitlichte Sprache angestrebt für: Anfragen (Queries) im Stand-Alone -Modus Datenmanipulation und Anfragen eingebettet in eine Wirtssprache Datendefinition Zugriffs- und Integritätskontrolle Unterstützung verschiedener Benutzerklassen: Anwendungsprogrammierer, DBA, gelegentliche Benutzer Verschiedene Grundtypen von Sprachen Formale Ansätze: Relationenalgebra und Relationenkalkül Abbildungsorientierte Sprachen (z. B. SQL) Graphik-orientierte Sprachen (z. B. Query-by-Example) WS3/4, Prof. Dr. E. Rahm 3-29 Relationenalgebra Algebra: ein System, das aus einer nichtleeren Menge und einer Familie von Operationen besteht Relationen sind Mengen Operationen auf Relationen arbeiten auf einer oder mehreren Relationen als Eingabe und erzeugen eine Relation als Ausgabe (Abgeschlossenheitseigenschaft) => mengenorientierte Operationen Operationen: Klassische Mengenoperationen: - Vereinigung - Differenz - kartesisches Produkt - Durchschnitt (ableitbar) Relationenoperationen: - Restriktion (Selektion) - Projektion - Verbund (Join) (ableitbar) - Division (ableitbar) WS3/4, Prof. Dr. E. Rahm 3-30

16 Selektion (Restriktion) Auswahl von Zeilen einer Relation über Prädikate, abgekürzt P P (R) = { t t R P(t)} P = log. Formel (ohne Quantoren!) zusammengestellt aus: Operanden: Attributnamen oder Konstanten Vergleichsoperatoren {<, =, >,,, } logische Operatoren:,, Beispiele: GEHALT < PROVISION (PERS) BERUF= Programmierer ALTER < 50 (PERS) Eigenschaften grad ( P (R)) = grad (R) card ( P (R)) <= card (R) WS3/4, Prof. Dr. E. Rahm 3-3 Projektion Auswahl der Spalten (Attribute) A, A 2,..., A k aus einer Relation R (Grad n >= k) A, A2,..., Ak (R) = { p t R : p = < t [ A ],..., t [ A k ] >} Beispiel: NAME, GEHALT (PERS) Eigenschaften: Wichtig: Duplikate werden entfernt! (Mengeneigenschaft) grad ( A (R)) <= grad (R) card ( A (R)) <= card (R) WS3/4, Prof. Dr. E. Rahm 3-32

17 Relationenalgebra: Beispiel-DB ABT ANR ANAME ORT K5 Planung Leipzig K53 Einkauf Frankfurt K55 Vertrieb Frankfurt PERS PNR Name Alter Gehalt ANR MNR 406 Abel K Schulz K5-829 Müller K Schmid K55 23 Finde alle Angestellten aus Abteilung K55, die mehr als verdienen Finde alle Abteilungsorte Finde den Abteilungsnamen von Abteilung K53 WS3/4, Prof. Dr. E. Rahm 3-33 Klassische Mengenoperationen Voraussetzung: Vereinigungsverträglichkeit der beteiligten Relationen: Gleicher Grad - Gleiche Bereiche: => W(A i ) = W(B i ) : i =, n (A, A 2,... A n ) (B, B 2,..., B n ) D i D j... D k Vereinigung: R S = { t t R t S } card (R S) <= card (R) + card (S) Differenz: R - S = { t t R t S } card (R - S) <= card (R) Durchschnitt: R S = R - (R - S) ={ t t R t S } card (R S) <= min (card (R), card (S)) WS3/4, Prof. Dr. E. Rahm 3-34

18 (Erweitertes) Kartesisches Produkt R (Grad r) und S (Grad s) beliebig R S = { k R, y S : k = x y } Beachte: k = x y = < x,..., x r, y,..., y s > nicht <<x,..., x r >, <y,..., y s >> wie übliches kart. Produkt grad (R S) = grad (R) + grad (S); card (R S) = card (R) card (S) Beispiel R S R A B C a d 2 b 3 S D E F b 3 d 2 WS3/4, Prof. Dr. E. Rahm 3-35 Allgemeiner Verbund (Theta-Join) grob: Kartesisches Produkt zwischen zwei Relationen R (Grad r) und S (Grad s). eingeschränkt durch -Bedingungen zwischen Attribut A von R und Attribut B von S. -Verbund zwischen R und S: R S A B = R A B S mit arithm. Vergleichsoperator {<, =, >,,, } Bemerkungen: Gleichverbund (Equijoin): = = : WS3/4, Prof. Dr. E. Rahm 3-36

19 Natürlicher Verbund (Natural Join) grob: Gleichverbund über alle gleichen Attribute und Projektion über die verschiedenen Attribute Natürlicher Verbund zwischen R und S: gegeben: R (A, A 2,..., A r-j+,..., A r ), S (B, B 2,..., B j,..., B s ) o.b.d.a.:(sonst. Umsortierung: B = A r-j+, B 2 = A r-j+2... B j = A r A A r, B j+ B s R.A r-j R S = + = S.B ) R.A r = S.B j ) (R S) Zeichen für Natural Join = = Join-Attribute sind durch Übereinstimmungsbedingung gegeben R A B C a b c S C D E c d e = Resultat A B C D E a 2 b 2 c 2 c 3 d 2 e 2 a b c d e WS3/4, Prof. Dr. E. Rahm 3-37 Join-Beispiel ABT ANR ANAME ORT K5 Planung Leipzig K53 Einkauf Frankfurt K55 Vertrieb Frankfurt PERS PNR Name Alter Gehalt ANR MNR 406 Abel K Schulz K5-829 Müller K Schmid K55 23 Finde alle Angestellten (PNR, ALTER, ANAME), die in einer Abteilung in Frankfurt arbeiten und älter als 30 sind. WS3/4, Prof. Dr. E. Rahm 3-38

20 Semi-Join Ergebnisbeschränkung des Gleichverbundes auf eine der beiden Eingaberelationen S R = S-Attribute (S R) S R = R-Attribute (S R) S A B C a b c a 2 b 2 c 2 R C D E c d e c 3 d 2 e 2 = Resultat A B C a b c S A B C a b c a 2 b 2 c 2 R C D E c d e c 3 d 2 e 2 = Resultat C D E c d e WS3/4, Prof. Dr. E. Rahm 3-39 Äußerer Verbund (Outer Join) Ziel: Verlustfreier Verbund soll erzwungen werden Ein Gleichverbund zwischen R und S heißt verlustfrei, wenn alle Tupel von R und S am Verbund teilnehmen. Die inverse Operation Projektion erzeugt dann wieder R und S (lossless join). R S verlustfrei Bisher: R S liefert nur vollständige Objekte Es sollen aber auch Teilobjekte als Ergebnis geliefert werden (z. B. komplexe Objekte) R S Trick: Einfügen künstlicher Verbundpartner WS3/4, Prof. Dr. E. Rahm 3-40

21 Outer Join (2) Def.: Seien A die Verbundattribute, { } der undefinierte Wert und R := R (( A (S) - A (R)) { }... { }) S := S (( A (R) - A (S)) { }... { }) Äußerer Gleichverbund R S := R.A = S.A R S R.A = S.A Äußerer natürlicher Verbund R S := R S Linker und rechter äußerer Gleichverbund Nur die linke bzw. rechte Argumentrelation bleibt verlustfrei (Einfügen künstlicher Verbundpartner in rechter bzw. linker Eingaberelation) R S := R.A = S.A R S R S := R.A=S.A R.A = S.A Linker äußerer Gleichverbund R S R.A = S.A Rechter äußerer Gleichverbund Verallgemeinerung auf 2 (oder mehr) Joins, z.b. selbst isolierte Tupel können zu einem vollständigen Pfad expandiert werden WS3/4, Prof. Dr. E. Rahm 3-4 R S T Outer Join - Beispiel PERS n ABT PERS ABT-ZUGEH 0..* 0.. ABT PERS PERS ABT PNR ANR... PNR ANR ANAME... PERS ABT PNR ANR ANAME... P P2 P3 A A A2 ABT P4 - P5 - ANR ANAME... PERS ABT PNR ANR ANAME... PNR ANR ANAME... A A2 A3 A B C PERS WS3/4, Prof. Dr. E. Rahm 3-42 ABT

22 Division Beantwortung von Fragen, bei denen eine ganze Relation zur Qualifikation herangezogen wird Simulation des Allquantors => ein Tupel aus R steht mit allen Tupeln aus S in einer bestimmten Beziehung Definition Voraussetzung: S-Attribute R-Attribute Sei R vom Grad r und S vom Grad s, r > s t sei (r-s)-tupel, u sei s-tupel; Dann gilt: R S = { t u S : t u R } grad (R S ) = card (R S ) WS3/4, Prof. Dr. E. Rahm 3-43 Beispiel LNR PNR TNR L L L2 L2 L2 LPT P P2 P P P2 T T T T2 T Division (2) PNR P P P2 PT TNR T T2 T Welche Lieferanten beliefern alle Projekte? Welche Lieferanten liefern alle Teile? Zusammenhang zwischen Division und kartesischem Produkt: ( R S ) S = R WS3/4, Prof. Dr. E. Rahm 3-44

23 Beispiel-DB: Bühne DRAMA DRAMA TITEL U-ORT U-JAHR AUTOR n ROLLE SCHAUSPIELER PNR W-ORT NAME n Darsteller ROLLE FIGUR TITEL R-Typ m SCHAU- SPIELER DARSTELLER PNR FIGUR A-JAHR A-ORT THEATER WS3/4, Prof. Dr. E. Rahm 3-45 Beispielanfragen Welche Darsteller (PNR) haben im Schauspielhaus gespielt? Finde alle Schauspieler (NAME, W-ORT), die einmal im Faust mitgespielt haben. Finde alle Schauspieler (NAME), die bei in Weimar uraufgeführten Dramen an ihrem Wohnort als Held mitgespielt haben Finde die Schauspieler (PNR), die nie gespielt haben Finde alle Schauspieler (NAME), die alle Rollen gespielt haben. WS3/4, Prof. Dr. E. Rahm 3-46

24 Zusammenfassung Relationenalgebra saubere mathematische Definition mengenorientierte Operationen keine Änderungsoperationen! für Laien nicht leicht verständlich Vereinigung Durchschnitt Restriktion Projektion Differenz a 2 3 b 2 (Nat.) Verbund (Join) b 2 3 c 2 3 WS3/4, Prof. Dr. E. Rahm 3-47 a 2 3 b 2 c 2 a b c Produkt x y a a b b c c x y x y x y a a a b c x y z x y Division x z a