5. Die Standardsprache 1 SQL

Transkript

1 5. Die Standardsprache 1 SQL GBIS-Rahmen: Einordnung Anwendung Daten Steuerung Funktionen Abbildungsorientierte Sprachen am Beispiel von SQL Seit 1974 viele Sprachentwürfe - SQUARE: Specifying Queries As Relational Expressions - SEQUEL: Structured English Query Language - Weiterentwicklung zu SQL (Structured Query Language) - QUEL, OLQ, PRTV,... Grundlagen - Funktions- und Einsatzbereiche - Befehlsübersicht und SQL-Grammatik Mengenorientierte Anfragen (Retrieval) - Anfragetypen - Aggregatfunktionen - Erklärungsmodell für die Anfrageauswertung - Vergleichsprädikate Möglichkeiten der Datenmanipulation (DML) Möglichkeiten der Datendefinition (DDL) - Basisrelationen - Integritätsbedingungen Abbildung von Beziehungen - Rolle des Fremdschlüssels - Umsetzung der verschiedenen Beziehungstypen Wartung von Beziehungen - Relationale Invarianten - Auswirkungen referentieller Aktionen 1. The nice thing about standards is that there are so many of them to choose from (Andrew S. Tanenbaum) 5-1 SW-Architektur Sprachentwicklung von SQL 2 - Entwicklung einer vereinheitlichten DB-Sprache für alle Aufgaben der DB-Verwaltung - Lehrexperimente mit Studenten mit und ohne Programmiererfahrung - Erweiterung der Anfragesprache zur natürlichen Formulierung bestimmter Fragen - gezielte Verbesserungen verschiedener Sprachkonstrukte zur Erleichterung des Verständnisses und zur Reduktion von Fehlern - leichter Zugang durch verschiedene Sprachebenen anwachsender Komplexität: einfache Anfragemöglichkeiten für den gelegentlichen Benutzer mächtige Sprachkonstrukte für den besser ausgebildeten Benutzer Spezielle Sprachkonstrukte für den DBA SQL wurde de facto -Standard in der relationalen Welt (X3H2-Vorschlag wurde 1986 von ANSI, 1987 von ISO akzeptiert) Weiterentwicklung des Standards SQL2 mit drei Stufen (1992), SQL3 (SQL:1999) und SQL4 (SQL:2003); angekündigt: SQL:2007 (XQuery, SQL/XML, and the Semantic Web) 2. Information Technology Database Language SQL - Part 1 and Part 2: Framework (for SQL:1999) and Foundation (SQL:1999), International Standard ( Information Technology Database Language SQL - Technical Corrigendum xxx for SQL:1999, : >1700 Dokumente 5-2

2 Eigenschaften Anfragen in SQL - Auswahlvermögen äquivalent dem Relationenkalkül und der Relationenalgebra - Vermeidung von mathematischen Konzepten wie Quantoren trotzdem: relational vollständig SQL: strukturierte Sprache, die auf englischen Schlüsselwörtern basiert 3 Grundbaustein SELECT PNR FROM PERS Abbildung WHERE ANR = K55 Ein bekanntes Attribut oder eine Menge von Attributen wird mit Hilfe einer Relation in ein gewünschtes Attribut oder einer Menge von Attributen abgebildet. Allgemeines Format <Spezifikation der Operation> <Liste der referenzierten Tabellen> [WHERE Boolescher Prädikatsausdruck] 3. Ausführliche Behandlung in vielen Lehrbüchern, z. B.: Pernul, G., Unland, R.: Datenbanken im Unternehmen Analyse, Modellbildung und Einsatz, Oldenbourg-Verlag, 2001; Türker, C.: SQL:1999 & SQL:2003, dpunkt.verlag, SQL2-Grammatik Semantik durch allgemeine Regeln in natürlicher Sprache SQL-Syntax (Auszug, Table=Relation, Column=Attribut, Listenelemente durch Komma getrennt) SQL-statement: query INSERT INTO table-name query view-name ( attr-name-list ) VALUES constant-list table-name DELETE FROM view-name WHERE condition UPDATE table-name SET set-list view-name WHERE condition CREATE TABLE table-name ( attr-defn-list, PRIMARY KEY ( attr-name-list ) from: query: CREATE VIEW view-name ( attr-name-list ) DROP TABLE DROP VIEW SELECT table-name view-name GROUP BY DISTINCT var-name table-name view-name expr-list * attr-spec-list from LEFT JOIN from ON condition FROM HAVING 5-4 from-list condition attr-spec: attr-defn: attr-name AS WHERE query ORDER BY set: attr-spec = attr-name table-name var-name INTEGER NUMERIC( DECIMAL( CHAR( VARCHAR( condition expr attr-spec-list condition: predicate expr: constant NOT condition attr-spec arithm.op: + - * / condition AND condition expr arithm.op expr comparison: = <> < > <= >= condition OR condition function predicate: expr comparison function: AVG( expr expr MAX( query MIN( DISTINCT attr-spec ) expr-list comparison expr-list SUM( expr comparison ALL query COUNT(*) ANY COUNT(DISTINCT attr-spec ) expr EXISTS attr-spec attr-spec NOT query IS NOT IN NOT LIKE expr-list query NULL constant bitte keine Aggregatfunktionen verwenden. attr-name length ) ASC DESC NOT NULL )

3 Anfragemöglichkeiten in SQL 4 Beispiel-DB: BÜHNE select-exp ::= SELECT [ALL DISTINCT] select-item-commalist FROM table-ref-commalist [WHERE cond-exp] [GROUP BY column-ref-commalist] [HAVING cond-exp] DICHTER (DI) AUTOR G-ORT G-JAHR DRAMA (DR) TITEL AUTOR KRITIKER U-ORT U-JAHR Mit SELECT kann das ganze Tupel ausgegeben werden FROM-Klausel spezifiziert das Objekt (Relation, Sicht), das verarbeitet werden soll (hier durch SELECT) WHERE-Klausel kann eine Sammlung von Prädikaten enthalten, die mit AND und OR verknüpft sein können SCHAUSPIELER (SP) PNR W-ORT NAME ROLLE FIGUR TITEL R-TYP (RO) Folgende Prädikate (Verbundterme) sind möglich: DARSTELLER (DA) A i Θ a i Θ {=, < >, <, <, >, >} PNR FIGUR A-JAHR A-ORT THEATER A i Θ A j

4 Untermengenbildung in einer Relation Geschachtelte Abbildung Q1: Welche Dramen von Goethe wurden nach 1800 uraufgeführt? Q3: Finde die Figuren, die in Dramen von Schiller oder Goethe vorkommen. SELECT * FROM DRAMA WHERE AUTOR = Goethe AND U-JAHR > 1800 Benennung von Ergebnis-Spalten SELECT FROM NAME, Berechnetes Alter: AS TEXT, CURRENT_DATE GEBDAT AS ALTER SCHAUSPIELER - Ausgabe von Attributen, Text oder Ausdrücken - Spalten der Ergebnisrelation können (um)benannt werden (AS) Ein Prädikat in einer WHERE-Klausel kann ein Attribut auf Zugehörigkeit zu einer Menge testen: A i IN (a 1, a j, a k ) explizite Mengendefinition A i IN (SELECT...) implizite Mengendefinition - innere und äußere Relationen können identisch sein - eine geschachtelte Abbildung kann beliebig tief sein Q2: Finde die Schauspieler (PNR), die Faust, Hamlet oder Wallenstein gespielt haben. SELECT FROM WHERE DARSTELLER PNR FIGUR IN ( Faust, Hamlet, Wallenstein ) - Duplikate in der Ausgabeliste werden nicht eliminiert (Default) - DISTINCT erzwingt Duplikateliminierung Die Menge, die zur Qualifikation herangezogen wird, kann Ergebnis einer geschachtelten Abbildung sein

5 Symmetrische Notation Symmetrische Notation (2) Q4: Finde die Figuren und ihre Autoren, die in Dramen von Schiller oder Goethe vorkommen. Q5: Finde die Dichter (AUTOR, G-ORT), deren Dramen von Dichtern mit demselben Geburtsort (G-ORT) kritisiert wurden. SELECT FROM WHERE AND AND A.AUTOR, A.G-ORT DICHTER A, DRAMA D, DICHTER B A.AUTOR = D.AUTOR D.KRITIKER = B.AUTOR A.G-ORT = B.G-ORT - Welche Rolle spielen die Bedingungen A.AUTOR = D.AUTOR und D.KRITIKER = B.AUTOR in der erhaltenen Lösung? Einführung von Tupelvariablen (correlation names) erforderlich Q6: Finde die Schauspieler (NAME, W-ORT), die bei in Weimar uraufgeführten Dramen an ihrem Wohnort als Held mitgespielt haben. Vorteile der symmetrischen Notation - Ausgabe von Größen aus inneren Blöcken - keine Vorgabe der Auswertungsrichtung (DBS optimiert!) - direkte Formulierung von Vergleichsbedingungen über Relationengrenzen hinweg möglich - einfache Formulierung des Verbundes SELECT FROM WHERE AND AND AND AND AND S.NAME, S.W-ORT SCHAUSPIELER S, DARSTELLER D, ROLLE R, DRAMA A S.PNR = D.PNR D.FIGUR = R.FIGUR R.TITEL = A.TITEL A.U-ORT = Weimar R.R-TYP = Held D.A-ORT = S.W-ORT - Wie sieht das Auswertungsmodell (Erklärungsmodell) bei symmetrischer Notation aus?

6 Ausführung von SQL-Anweisungen Benutzerspezifizierte Reihenfolge der Ausgabe Abstraktes Erklärungsmodell für Q6 ORDER BY order-item-commalist Q7: Finde die Schauspieler, die an einem Ort wohnen, an dem sie gespielt haben, sortiert nach Name (aufsteigend), W-Ort (absteigend). SP DA RO DR SELECT FROM S.NAME, S.W-ORT SCHAUSPIELER S, DARSTELLER D Verbesserter Operatorbaum für Q6 WHERE AND S.PNR = D.PNR S.W-ORT = D.A-ORT ORDER BY S.NAME ASC, S.W-ORT DESC - Ohne Angabe der ORDER-BY-Klausel wird die Reihenfolge der Ausgabe durch das System bestimmt (Optimierung der Auswertung) SP DA RO DR Heuristische Optimierungsregeln 1. Führe Selektionen so früh wie möglich aus! 2. Bestimme die Verbundreihenfolge so, dass die Anzahl und Größe der Zwischenobjekte minimiert wird!

7 Aggregat-Funktionen Aggregat-Funktionen (2) Q9: An wievielen Orten wurden Dramen uraufgeführt (U-Ort)? aggregate-function-ref ::= COUNT(*) {AVG MAX MIN SUM COUNT} ([ALL DISTINCT] scalar-exp) SELECT FROM DRAMA Standard-Funktionen: AVG, SUM, COUNT, MIN, MAX - Elimination von Duplikaten: DISTINCT - keine Elimination: ALL (Defaultwert) Q: An welchen Orten wurden mehr als zwei Dramen uraufgeführt? Versuch: Typverträglichkeit erforderlich Q8: Bestimme das Durchschnittsgehalt der Schauspieler, die älter als 50 Jahre sind. (GEHALT und ALTER seien Attribute von SP) SELECT FROM SCHAUSPIELER WHERE ALTER > 50 SELECT DISTINCT U-ORT FROM DRAMA D WHERE 2 < (SELECT COUNT(*) FROM DRAMA X WHERE X.U-ORT = D.U-ORT) Auswertung - Aggregat-Funktion (AVG) wird angewendet auf einstellige Ergebnisliste (GEHALT) - keine Eliminierung von Duplikaten - Verwendung von arithmetischen Ausdrücken ist möglich: AVG (GEHALT/12) - keine geschachtelte Nutzung von Funktionsreferenzen! - Aggregat-Funktionen in WHERE-Klausel unzulässig! Q11: Welches Drama (Titel, U-Jahr) wurde zuerst aufgeführt? SELECT TITEL, U-JAHR FROM DRAMA WHERE U-JAHR =

8 Partitionierung einer Relation in Gruppen Auswahl von Gruppen GROUP BY column-ref-commalist HAVING cond-exp Beispielschema: PERS (PNR, NAME, GEHALT, ALTER, ANR) PRIMARY KEY (PNR) Beispielschema: PERS (PNR, NAME, GEHALT, ALTER, ANR) PRIMARY KEY (PNR) Q12: Liste alle Abteilungen und das Durchschnittsgehalt ihrer Angestellten auf (Monatsgehalt). Q13: Liste die Abteilungen zwischen K50 und K60 auf, bei denen das Durchschnittsalter ihrer Angestellten kleiner als 30 ist. SELECT ANR, FROM PERS GROUP BY ANR SELECT ANR FROM PERS WHERE ANR K50 AND ANR K60 GROUP BY HAVING - GROUP-BY-Klausel wird immer zusammen mit Aggregat-Funktion benutzt. - Die Aggregat-Funktion wird jeweils auf die Tupeln einer Gruppe angewendet - Die Ausgabe-Attribute müssen verträglich miteinander sein Wie sieht ein allgemeines Erklärungsmodell für die Anfrageauswertung aus?

9 Hierarchische Beziehung auf einer Relation Hierarchische Beziehung auf einer Relation (2) Beispielschema: PERS (PNR, NAME, GEHALT, MNR) PRIMARY KEY (PNR) FOREIGN KEY (MNR) REFERENCES PERS Alternatives Erklärungsmodell für Q14: Verbund von PERS mit sich selbst und anschließende Selektion Q14: Finde die Angestellten, die mehr als ihre (direkten) Manager PERS PNR NAME GEH. MNR PERS PNR NAME GEH. MNR verdienen (Ausgabe: NAME, GEHALT, NAME des Managers) 406 Abel 50 K Abel 50 K Maier 60 K Maier 60 K Müller 55 K Müller 55 K 574 SELECT X.NAME, X.GEHALT, Y.NAME FROM PERS X, PERS Y May 50 K May 50 K - WHERE X.MNR = Y.PNR AND X.GEHALT > Y.GEHALT 4 5 Verbundbedingung: MNR = PNR Erklärung der Auswertung der Formel PERS PERS PNR NAME GEH MNR PNR NAME GEH MNR X.MNR = Y.PNR AND X.GEHALT > Y.GEHALT 406 Abel 50 K Müller 55 K 574 PERS PNR NAME GEH. MNR PERS PNR NAME GEH. MNR 123 Maier 60 K 829 Müller 55 K Müller 55 K 574 May 50 K Abel 50 K Abel 50 K Maier 60 K Maier 60 K Müller 55 K Müller 55 K 574 Selektionsbedingung: GEHALT > GEHALT 574 May 50 K May 50 K - AUSGABE NAME GEHALT NAME AUSGABE X.NAME X.GEHALT Y.NAME Maier Müller 60 K 55 K Müller May

10 Auswertung von SQL-Anfragen Erklärungsmodell 1. Die auszuwertenden Relationen werden durch die FROM-Klausel bestimmt. Aliasnamen erlauben die mehrfache Verwendung derselben Relation 2. Das Kartesische Produkt aller Relationen der FROM-Klausel wird gebildet. 3. Tupeln werden ausgewählt durch die WHERE-Klausel. - Prädikat muss zu true evaluieren 4. Aus den übrig gebliebenen Tupeln werden Gruppen gemäß der GROUP-BY- Klausel derart gebildet, dass eine Gruppe aus allen Tupeln besteht, die hinsichtlich aller in der GROUP-BY-Klausel aufgeführten Attribute gleiche Werte enthalten. Erklärungsmodell von SQL-Anfragen Beispiele FROM R WHERE B <= 50 R A B C Rot Rot Gelb Rot Gelb Blau Blau Blau R A B C Rot Rot Gelb Rot Gelb Blau Blau 80 Blau Gruppen werden ausgewählt, wenn sie die HAVING-Klausel erfüllen. - Prädikat in der HAVING-Klausel muss zu true evaluieren. - Prädikat in der HAVING-Klausel darf sich nur auf Gruppeneigenschaften beziehen (Attribute der GROUP-BY-Klausel oder Anwendung von Aggregat-Funktionen). GROUP BY A R A B C Rot Rot Rot Gelb Blau Blau Die Ausgabe wird durch die Auswertung der SELECT-Klausel abgeleitet. - Wurde eine GROUP-BY-Klausel spezifiziert, dürfen als Select-Elemente nur Ausdrücke aufgeführt werden, die für die gesamte Gruppe genau einen Wert ergeben (Attribute der GROUP-BY-Klausel oder Anwendung von Aggregat- Funktionen). 7. Die Ausgabereihenfolge wird gemäß der ORDER-BY-Klausel hergestellt. - Wurde keine ORDER-BY-Klausel angegeben, ist die Ausgabereihenfolge systembestimmt (indeterministisch). HAVING MAX(C) > 0 SELECT A, SUM(B), 12 ORDER BY A R A B C Rot Rot Rot Gelb Blau Blau R A SUM(B) 12 Blau R A SUM(B) 12 Blau

11 Erklärungsmodell von SQL-Anfragen Beispiele (2) Suchbedingungen PERS PNR ANR GEH BONUS ALTER K45 80K 0 52 K45 30K 1 42 K45 50K 2 43 K56 40K 3 31 K56 80K 3 45 K56 20K 3 41 Sammlung von Prädikaten - Verknüpfung mit AND, OR, NOT - Auswertungsreihenfolge ggf. durch Klammern Nicht quantifizierte Prädikate - Vergleichsprädikate Θ Q151: SELECT ANR, SUM(GEH) FROM PERS WHERE BONUS <> 0 GROUP BY ANR HAVING (COUNT(*) > 1) ORDER BY ANR DESC ANR K56 K45 SUM(GEH) 140K 80K comparison-cond ::= row-constructor Θ row-constructor row-constructor := scalar-exp (scalar-exp-commalist) (table-exp) Q152: SELECT ANR, SUM(GEH) FROM PERS WHERE BONUS <> 0 GROUP BY ANR HAVING (COUNT(DISTINCT BONUS) > 1) ORDER BY ANR DESC ANR K45 SUM(GEH) 80K - BETWEEN-Prädikate row-constr [NOT] BETWEEN row-constr AND row-constr Q153: Die Summe der Gehälter pro Abteilung, in der mindestens ein Mitarbeiter 40 Jahre oder älter ist, soll berechnet werden. Beispiel: GEHALT BETWEEN 80K AND 0K - IN-Prädikate ANR SUM(GEH) - Ähnlichkeitssuche: LIKE-Prädikat - Behandlung von Nullwerten Quantifizierte Prädikate: ALL, ANY, EXISTS Q154: Warum löst folgende Anfrage nicht Q153? SELECT ANR, SUM(GEHALT) FROM PERS WHERE ALTER >= 40 GROUP BY ANR HAVING (COUNT(*) >= 1) ANR K45 K56 SUM(GEH) 160K 0K Weitere Prädikate - MATCH-Prädikat für Tupelvergleiche - UNIQUE-Prädikat zur Bestimmung von Duplikaten

12 IN-Prädikate Ähnlichkeitssuche row-constr [NOT] IN (table-exp) scalar-exp [NOT] IN (scalar-exp-commalist) - x IN (a, b,..., z) x = a OR x = b... OR x = z - row-constr IN (table-exp) row-constr = ANY (table-exp) - x NOT IN erg NOT (x IN erg) Q16: Finde die Namen der Schauspieler, die den Faust gespielt haben SELECT S.NAME FROM SCHAUSPIELER S WHERE Faust IN (SELECT D.FIGUR FROM DARSTELLER D WHERE D.PNR = S.PNR) Unterstützung der Suche nach Objekten - von denen nur Teile des Inhalts bekannt sind oder - die einem vorgegebenen Suchkriterium möglichst nahe kommen Aufbau einer Maske mit Hilfe zweier spezieller Symbole % bedeutet null oder mehr beliebige Zeichen _ bedeutet genau ein beliebiges Zeichen %TENB _ Klassen der Ähnlichkeitssuche 1. Syntaktische Ähnlichkeit (Einsatz von Masken) LIKE M ER SELECT S.NAME FROM SCHAUSPIELER S WHERE S.PNR IN (SELECT D.PNR FROM DARSTELLER D WHERE D.FIGUR = Faust ) 2. Phonetische Ähnlichkeit (Codierung von Lauten)? MAIER SELECT S.NAME FROM SCHAUSPIELER S, DARSTELLER D WHERE S.PNR = D.PNR AND D.FIGUR = Faust 3. Semantische Ähnlichkeit (Ontologien, Synonyme, Oberbegriffe,...) POLITIKER ~

13 LIKE-Prädikate NULL-Werte char-string-exp [ NOT ] LIKE char-string-exp [ ESCAPE char-string-exp ] Attributspezifikation: Es kann für jedes Attribut festgelegt werden, ob NULL-Werte zugelassen sind oder nicht Verschiedene Bedeutungen Unscharfe Suche - LIKE-Prädikat vergleicht einen Datenwert mit einem Muster bzw. einer Maske - Das LIKE-Prädikat ist TRUE, wenn der entsprechende Datenwert der Maske mit zulässigen Substitutionen von Zeichen für % und _ entspricht. - NAME LIKE %SCHMI% wird z. B. erfüllt von H.-W. SCHMITT, SCHMITT, H.-W. BAUSCHMIED, SCHMITZ - ANR LIKE _7% wird erfüllt von Abteilungen mit einer 7 als zweitem Zeichen - NAME NOT LIKE %-% wird erfüllt von allen Namen ohne Bindestrich Suche nach % und _ durch Voranstellen eines Escape-Zeichens möglich - STRING LIKE %\_% ESCAPE \ wird erfüllt von STRING-Werten mit Unterstrich SIMILAR-Prädikat in SQL: erlaubt die Nutzung von regulären Ausdrücken zum Maskenaufbau - Beispiel: NAME SIMILAR TO (SQL-( )) (SQL(1 2 3)) Datenwert ist momentan nicht bekannt - Attributwert existiert nicht für ein Tupel Auswertung von Booleschen Ausdrücken mit einer dreiwertigen Logik NOT AND T F? OR T F? T F F T?? Die Auswertung eines NULL-Wertes in einem Vergleichsprädikat mit irgendeinem Wert ist UNKNOWN (?) PERS PNR ANR GEH PROV GEH > PROV GEH > 70K AND PROV > 50K T T F? F F F F?? F? K45 K45 K45 K56 K : 1111: 1234: 0815: 1234: 80K 30K 20K - 80K T T T T F T F?? T?? - 50K - - 0K GEH > 70K OR PROV > 50K 0815: 1111: 1234: Das Ergebnis? nach vollständiger Auswertung einer WHERE-Klausel wird wie FALSE behandelt 5-26

14 NULL-Werte (2) Quantifizierte Prädikate Eine arithmetische Operation (+, -, *, /) mit einem NULL-Wert führt auf einen NULL-Wert PERS PNR SELECT PNR, GEH + PROV 0815: FROM PERS 4711:...: Verbund Tupel mit NULL-Werten im Verbundattribut nehmen nicht am Verbund teil Achtung Im allgemeinen ist ANR GEH PROV K45 80K - K45 30K 50K K45 20K - K K56 80K 0K AVG (GEH) <> SUM (GEH) / COUNT (PNR) All-or-Any-Prädikate Θ ALL: Prädikat wird zu true ausgewertet, wenn der Θ-Vergleich für alle Ergebniswerte von table-exp true ist Θ ANY / Θ SOME: analog, wenn der Θ-Vergleich für einen Ergebniswert true ist Existenztests row-constr Θ { ALL ANY SOME} (table-exp) [NOT] EXISTS (table-exp) - Das Prädikat wird zu false ausgewertet, wenn table-exp auf die leere Menge führt, sonst zu true - Im EXISTS-Kontext darf table-exp mit (SELECT *...) spezifiziert werde (Normalfall) Spezielles Prädikat zum Test auf NULL-Werte row-constr IS [NOT] NULL Beispiel SELECT PNR, PNAME FROM PERS WHERE GEHALT IS NULL Semantik x Θ ANY (SELECT y FROM T WHERE p) EXISTS (SELECT * FROM T WHERE (p) AND x Θ T.y) x Θ ALL (SELECT y FROM T WHERE p) NOT EXISTS (SELECT * FROM T WHERE (p) AND NOT (x Θ T.y))

15 Quantifizierte Prädikate (2) Quantifizierte Prädikate (3) Q17: Finde die Manager, die mehr verdienen als alle ihre direkten Untergebenen SELECT DISTINCT M.PNR FROM PERS M WHERE M.GEHALT > ALL (SELECT P.GEHALT FROM PERS P WHERE P.MNR = M.PNR) Q18: Finde die Namen der Schauspieler, die mindestens einmal gespielt haben (... nie gespielt haben) SELECT S.NAME FROM SCHAUSPIELER S WHERE (NOT) EXISTS (SELECT * FROM DARSTELLER D WHERE D.PNR = S.PNR) SCHAUSPIELER (PNR, NAME,...) S1... S2 S3 ROLLE (FIGUR, TITEL,...) F... H W DARSTELLER (PNR, FIGUR,...) S1 F S2 F S2 H S2 W S3 H Q19: Finde die Namen aller Schauspieler, die alle Rollen gespielt haben SELECT S.NAME FROM SCHAUSPIELER S WHERE NOT EXISTS (SELECT * FROM ROLLE R WHERE NOT EXISTS (SELECT * FROM DARSTELLER D WHERE D.PNR = S.PNR AND D.FIGUR = R.FIGUR)) NOT EXISTS R S1 S2 S3 F T F NOT EXISTS D S1 S2 S3 F F T T F F T F T Andere Formulierung: Finde die Namen der Schauspieler, so dass keine Rolle existiert, die sie nicht gespielt haben

16 Es gibt immer viele Möglichkeiten! Auch das ist eine SQL-Anfrage Q20: Finde die Messstation mit der niedrigsten gemessenen Temperatur Gegeben: station (snr, name,...) S1... S2 S3... In wettert stehen die täglich gemessenen Minimaltemperaturen der verschiedenen Messstationen. 5 Gute Lösung: (Aggregat-Funktion in Subquery) SELECT s.name FROM station s, wettert w WHERE s.snr=w.snr and w.mintemp= (SELECT MIN(ww.mintemp) FROM wettert ww); Schlechte Lösung: Keine Joins SELECT name FROM station WHERE snr=( SELECT DISTINCT snr FROM wettert WHERE mintemp=( SELECT MIN(mintemp) FROM wettert)); Naja, worst case?!: Keine Aggregat-Funktion SELECT DISTINCT name FROM station WHERE snr IN ( SELECT W1.snr FROM wettert W1 WHERE NOT EXISTS ( SELECT * FROM wettert W2 WHERE W2.mintemp < W1.mintemp)); 5. Zusatz: Die Temperaturen werden als Integer in Zehntelgraden aufgezeichnet. Manche Stationen können bei der Temperatur Nullwerte aufweisen, die als (0 Kelvin) (oder als NULL) codiert sind. Bei allen Lösungen fehlt die Behandlung des Nullwertes wettert (datum, snr, mintemp,...) 01 S S S Durch Tool zur Entscheidungsunterstützung (OnLine Analytical Processing, OLAP) und GUI-Nutzung automatisch erzeugt. select distinct a.fn from T1 a where a.owf = (select min (b.owf) from T1 b where (1=1) and (b.aid= SAS and b.fc in (select c.cid from T2 c where c.cn= HKG ) and b.tc in (select d.cid from T2 d where d.cn= HLYD ) and b.fid in (select e.fid from T3 e where e.did in (select f.did from T4 f where f.dow= saun )) and b.fdid in (select g.did from T4 g where g.dow= saun ))) and (1=1) and (a.aid= SAS and a.fc in (select h.cid from T2 h where h.cn= HKG ) and a.tc in (select i.cid from T2 i where i.cn= HLYD ) and a.did in (select j.fid from T3 j where j.did in (select k.did from T4 k where k.dow= saun )) and a.fdid in (select 1.did from T4 1 where 1.dow= saun )) 5-32

17 Möglichkeiten der Datenmanipulation Löschen von Tupeln durch Suchklauseln Einfügen von Tupeln INSERT INTO table [ (column-commalist) ] { VALUES row-constr.-commalist table-exp DEFAULT VALUES } M1: Füge den Schauspieler Garfield mit der PNR 4711 ein (satzweises Einfügen) INSERT INTO SCHAUSPIELER (PNR, NAME, W-ORT VALUES ( 4711, Garfield, DEFAULT) searched-delete ::= DELETE FROM table [WHERE cond-exp] Der Aufbau der WHERE-Klausel entspricht dem in der SELECT-Anweisung M3: Lösche den Schauspieler mit der PNR DELETE FROM SCHAUSPIELER WHERE PNR = Alle nicht angesprochenen Attribute erhalten Nullwerte - Falls alle Werte in der richtigen Reihenfolge versorgt werden, kann die Attributliste weggelassen werden - Mengenorientiertes Einfügen ist möglich, wenn die einzufügenden Tupel aus einer anderen Relation mit Hilfe einer SELECT-Anweisung ausgewählt werden können. M2: Füge die Schauspieler aus KL in die Relation TEMP ein INSERT INTO TEMP M4: Lösche alle Schauspieler, die nie gespielt haben. DELETE FROM SCHAUSPIELER S WHERE NOT EXISTS (SELECT * FROM DARSTELLER D WHERE D.PNR = S.PNR) - Eine (leere) Relation TEMP sei vorhanden. Die Datentypen ihrer Attribute müssen kompatibel zu den Datentypen der ausgewählten Attribute sein. - Ein mengenorientiertes Einfügen wählt die spezifizierte Tupelmenge aus und kopiert sie in die Zielrelation. - Die kopierten Tupel sind unabhängig von ihren Ursprungstupeln

18 Ändern von Tupeln durch Suchklauseln Datendefinition nach SQL searched-update ::= UPDATE table SET update-assignment-commalist [WHERE cond-exp] M5: Gib den Schauspielern, die am Pfalztheater spielen, eine Gehaltserhöhung von 5% (Annahme: GEHALT in Schauspieler) UPDATE SCHAUSPIELER S SET S.GEHALT = S.GEHALT * 1.05 WHERE EXISTS (SELECT * FROM DARSTELLER D WHERE D.PNR = S.PNR AND D.THEATER = Pfalz ) Was ist alles zu definieren, um eine leere DB zu erhalten? SQL-Umgebung (environment) besteht aus - einer Instanz eines DBMS zusammen mit - einer Menge von Daten in Katalogen (als Tabellen organisiert) - einer Reihe von Nutzern (authorization identifiers) und Programmen (modules) Wichtige Elemente der SQL-Umgebung gehört zu (1,1) Cluster (1,*) zugeordnet (0,*) (0,*) SQL-Umgebung ist in (0,*) Katalog (1,1) (1,*) Einschränkung (SQL-92 Entry/Intermediate) Innerhalb der WHERE-Klausel in einer Lösch- oder Änderungsanweisung darf die Zielrelation in einer FROM-Klausel nicht referenziert werden. unterteilt (1,1) Schema Kataloge bestehen aus SQL-Schemata und können innerhalb einer SQL-Umgebung optional auf ein oder mehrere Cluster 6 verteilt werden SQL-Schema - Katalog kann man als DB (in der DB) ansehen - SQL-Schemata sind Hilfsmittel zur logischen Klassifikation von Objekten innerhalb einer solchen DB - Datendefinitionsteil von SQL enthält Anweisungen zum Erzeugen, Verändern und Löschen von Schemaelementen 6. Sinn dieser Clusterbildung ist die Zuordnung von genau einem Cluster zu jeder SQL-Sitzung und dadurch wiederum die Zuordnung einer Menge von Daten bzw. Katalogen zu dieser Sitzung

19 Elemente des SQL-Schemas Informations- und Definitionsschema Schema Ziel der SQL-Normierung - möglichst große Unabhängigkeit der DB-Anwendungen von speziellen DBS Tabelle Basistabelle Spalte - einheitliche Sprachschnittstelle genügt nicht! - Beschreibung der gespeicherten Daten und ihrer Eigenschaften (Metadaten) nach einheitlichen und verbindlichen Richtlinien ist genauso wichtig Sicht Zweischichtiges Definitionsmodell zur Beschreibung der Metadaten 7 Integritätsbedingung Referentielle Integritätsbedingung Tabellenbedingung Freie Bedingung CHECK- Bedingung Informationsschema bietet einheitliche Sichten in normkonformen Implementierungen ist für den Benutzer zugänglich und somit die definierte Schnittstelle zum Katalog Domäne Domänenbedingung Zeichensatz Zeichenordnung Zeichensatztransformation Legende: ist Definitionsschema beschreibt hypothetische Katalogstrukturen, also Meta-Metadaten erlaubt Altsysteme mit abweichenden Implementierungen normkonform zu werden Zugriffsrecht Zugriffsrecht auf Tabelle hat Welche Meta-Metadaten enthält ein generisches SQL-DBMS? 8 - DEFINITION_SCHEMA umfasst 24 Basistabellen und 3 Zusicherungen Zugriffsrecht auf Spalte - In den Tabellendefinitionen werden ausschließlich 3 Domänen verwendet: SQL_IDENTIFIER, CHARACTER_DATA und CARDINAL_NUMBER Benutzer Zugriffsrecht auf anderes Objekt 7. Als Definitionsgrundlage für die Sichten des Informationsschemas spezifiziert die SQL-Norm das Definitionsschema, das sich auf ein ganzes Cluster von SQL-Katalogen bezieht und die Elemente aller darin enthaltenen SQL-Schemata beschreibt. 8. Das nicht normkonforme Schema SYSCAT von DB2 enthält 37 Tabellen

20 Das Definitionsschema Definition von Schemata REFERENTIAL_ CONSTRAINTS ASSERTIONS owner SCHEMATA Anweisungssyntax (vereinfacht) refs primary key/ unique constr. is for. key primary key / unique constr. for. key xor TABLE_ CONSTRAINTS check or CHECK_ CONSTRAINTS DOMAIN_ CONSTRAINTS default character set DOMAINS CREATE SCHEMA [schema] [AUTHORIZATION user] [DEFAULT CHARACTER SET char-set] [schema-element-list] - Jedes Schema ist einem Benutzer (user) zugeordnet, z.b. DBA KEY_COLUMN_ USAGE CHECK_TABLE_ USAGE CHECK-COLUMN_ USAGE or DATA_TYPE_ DESCRIPTOR char set - Schema erhält Benutzernamen, falls keine explizite Namensangabe erfolgt - Definition aller Definitionsbereiche, Basisrelationen, Sichten (Views), Integritätsbedingungen und Zugriffsrechte D1: Benennung des Schemas TABLES >0 COLUMNS or COLLATIONS CREATE SCHEMA Beispiel-DB AUTHORIZATION DB-Admin VIEW_TABLE USAGE VIEW VIEW_COLUMN_ USAGE default collation CHARACTER_ USAGE Datentypen CHARACTER [ ( length ) ] CHARACTER VARYING [ ( length ) ]... (Abkürzung: CHAR) (Abkürzung: VARCHAR) TABLE_ PRIVILEGES COLUMN_ PRIVILEGES USAGE_ PRIVILEGES grantor grantee grantor grantee grantor grantee or target source TRANSLATIONS NUMERIC [ ( precision [, scale] ) ] DECIMAL [ ( precision [, scale ] ) ] INTEGER REAL... (Abkürzung: DEC) (Abkürzung: INT) USERS SQL_ LANGUAGES DATE TIME

21 Definition von Wertebereichen Definition von Attributen Domänen-Konzept zur Festlegung zulässiger Werte Spezifikationsmöglichkeiten - Optionale Angabe von Default-Werten - Wertebereichseingrenzung durch benamte CHECK-Bedingung möglich - CHECK-Bedingungen können Relationen der DB referenzieren. SQL-Domänen sind also dynamisch! Beispiele CREATE DOMAIN domain [AS] data type [DEFAULT { literal niladic-function-ref NULL} ] [ [CONSTRAINT constraint] CHECK (cond-exp) [deferrability]] - CREATE DOMAIN ABTNR AS CHAR (6) - CREATE DOMAIN ALTER AS INT DEFAULT NULL CONSTRAINT ALTERSBEGRENZUNG CHECK (VALUE=NULL OR (VALUE > 18 AND VALUE < 70)) Bei der Attributdefinition (column definition) können folgende Angaben spezifiziert werden - Attributname - Datentyp bzw. Domain - Defaultwert sowie Constraints Beispiele column-def : : = column { data-type domain } [ DEFAULT { literal niladic-function-ref NULL} ] [ column-constraint-def-list ] - PNAME CHAR (30) - PALTER ALTER (siehe Definition von Domain ALTER) Als Constraints können - Verbot von Nullwerten (NOT NULL) - Eindeutigkeit (UNIQUE bzw. PRIMARY KEY) - FOREIGN-KEY-Klausel - CHECK-Bedingungen definiert werden column-constraint-def : : = [CONSTRAINT constraint] { NOT NULL { PRIMARY KEY UNIQUE } references-def CHECK (cond-exp) } [deferrability] Constraint-Namen sind vorteilhaft Diagnosehilfe bei Fehlern - gezieltes Ansprechen bei SET oder DROP des Constraints 5-42

22 Definition von Attributen (2) Erzeugung von Basisrelationen Beispiel - Verkaufs_Preis DECIMAL (9, 2), CONSTRAINT Ausverkauf CHECK (Verkaufs_Preis <= (SELECT MIN (Preis) FROM Konkurrenz_Preise)) CREATE TABLE base-table (base-table-element-commalist) base-table-element ::= column-def base-table-constraint-def Überprüfungszeitpunkt deferrability : : = INITIALLY { DEFERRED IMMEDIATE } [ NOT ] DEFERRABLE - Jeder Constraint bzgl. einer SQL2-Transaktion ist zu jedem Zeitpunkt in einem von zwei Modi: immediate oder deferred - Der Default-Modus ist immediate Aufbau der FOREIGN-KEY-Klausel references-def : : = REFERENCES base-table [ (column-commalist)] [ON DELETE referential-action] [ON UPDATE referential-action] referential-action : : = NO ACTION CASCADE SET DEFAULT SET NULL - Fremdschlüssel kann auch auf Schlüsselkandidat definiert sein - Referentielle Aktionen werden später behandelt 5-43 Definition einer Relation - Definition aller zugehörigen Attribute mit Typspezifikation - Spezifikation aller Integritätsbedingungen (Constraints) D2: Erzeugung der neuen Relationen PERS und ABT CREATE TABLE PERS (PNR INT PRIMARY KEY, BERUF CHAR (30), PNAME CHAR (30) NOT NULL, PALTER ALTER, (* siehe Domaindefinition *) MGR INT REFERENCES PERS, ANR ABTNR NOT NULL, (* Domaindef. *) W-ORT CHAR (25) DEFAULT, GEHALT DEC (9,2) DEFAULT 0,00 CHECK (GEHALT < ,00) FOREIGN KEY (ANR) REFERENCES ABT) CREATE TABLE ABT (ANR ABTNR PRIMARY KEY, ANAME CHAR (30) NOT NULL, ANZAHL-ANGEST INT NOT NULL,...) Wie kann ANZAHL-ANGEST überprüft werden? 5-44

23 Abbildung von Beziehungen Abbildung von Beziehungen (2) Beispiel: Darstellung einer (1:n)-Beziehung ABT PERS a a 2 3 a 3 4 Abbildungsversuch (FS auf welche Seite?) ABT (ABTNR, PNR,...) PERS (PNR,...) ER-Diagramm: (1:n)-Beziehung ABT Umsetzung ins Relationenmodell ABT (ABTNR..., PERS (PNR...,... ANR..., PRIMARY KEY (ABTNR)) PRIMARY KEY (PNR), FOREIGN KEY (ANR) REFERENCES ABT) Referenzgraph ABT referenzierte [0,n] ist_ beschäftigt_ [0,1] in ANR Relation PERS referenzierende PERS Abbildung im Relationenmodell ABT (ABTNR,...) PERS (PNR, ANR,...) Zusätzliche Einschränkungen Jeder Angestellte (PERS) muss in einer Abteilung beschäftigt sein ([1,1]). PERS.ANR... NOT NULL Jeder Abteilung (ABT: [0,1]) darf höchstens einen Angestellten beschäftigen. PERS.ANR... UNIQUE Bemerkung In SQL2 kann nicht spezifiziert werden, dass ein Vater einen Sohn haben muss, z. B. [1,n]. Die Anzahl der Söhne lässt sich nicht einschränken (außer [0,1]). - Vorschlag für späteren Standard: PENDANT-Klausel, mit welcher der Fall [1,n] abgedeckt werden kann. - Bei der Erstellung müssen solche Beziehungen verzögert überprüft werden

24 Abbildung von Beziehungen (3) Abbildung von Beziehungen (4) ER-Diagramm Ziel: Darstellung einer symmetrischen (1:1)-Beziehung Erster Versuch: ER-Diagramm hat_ [0,n] Büro_ von [1,1] hat_ [0,1] Mgr [0,1] ABT PERS ABT MGR [0,n] arbeitet_ für [0,1] [0,1] leitet_ Abt [0,1] Umsetzung ins Relationenmodell ABT (ABTNR..., PERS (PNR...,... ANRA..., PRIMARY KEY (ABTNR)) ANRB... NOT NULL, PRIMARY KEY (PNR), FOREIGN KEY (ANRA) REFERENCES ABT, FOREIGN KEY (ANRB) REFERENCES ABT) Referenzgraph ANRB ABT PERS ANRA Bemerkung - Für jede FS-Beziehung benötigt man ein separates FS-Attribut. - Mehrere FS-Attribute können auf dasselbe PS/SK-Attribut verweisen Umsetzung ins Relationenmodell ABT (ANR..., MGR (MNR..., MNR... UNIQUE, ANR...UNIQUE, PRIMARY KEY (ANR), PRIMARY KEY (MNR), FOREIGN KEY (MNR) FOREIGN KEY (ANR) REFERENCES MGR) REFERENCES ABT) Es sind alternative Lösungen möglich Zusätzliche Einschränkungen - Jede Abteilung hat einen Manager ABT.MNR... UNIQUE NOT NULL - Jeder Manager leitet eine Abteilung MGR.ANR... UNIQUE NOT NULL Referenzgraph ABT MNR ANR Kann durch die beiden (n:1)-beziehungen eine symmetrische (1:1)-Beziehung ausgedrückt werden? 5-48 MGR

25 Abbildung von Beziehungen (5) Abbildung von Beziehungen (6) Beispiel: Darstellung einer (1:1)-Beziehung ABT MGR a 1 1 a 2 2 a 3 3 a 4 4 Versuch ABT (ABTNR, MNR,...) PERS (MNR, ABTNR,...) Abbildung im Relationenmodell ABT (ABTNR, MNR,...) PERS (MNR,...) ER-Diagramm: Symmetrische (1:1)-Beziehung Umsetzung ins Relationenmodell ABT (ANR..., MGR (MNR..., MNR... UNIQUE NOT NULL, PRIMARY KEY (MNR), PRIMARY KEY (ANR), FOREIGN KEY (MNR) FOREIGN KEY (MNR) REFERENCES ABT(MNR)) REFERENCES MGR) Es sind alternative Lösungen möglich ABT Referenzgraph ABT [1,1] leitet [1,1] MNR MNR MGR MGR - Die Nutzung des MNR-Attributes für beide FS-Beziehungen gewährleistet hier die Einhaltung der (1:1)-Beziehung - Der Fall ([0,1], [0,1]) ist so nicht darstellbar Abbildung im Relationenmodell (Variation über Schlüsselkandidaten) ABT (ABTNR, MNR,...) PERS (SVNR, MNR,...) 5-49 Variation über Schlüsselkandidaten ABT (ANR..., MGR (SVNR..., MNR... UNIQUE, MNR... UNIQUE, PRIMARY KEY (ANR), PRIMARY KEY (SVNR) FOREIGN KEY (MNR) FOREIGN KEY (MNR) REFERENCES MGR(MNR) REFERENCES ABT(MNR)) - Die Nutzung von Schlüsselkandidaten mit der Option NOT NULL erlaubt die Darstellung des Falles ([1,1], [1,1]) - Alle Kombinationen mit [0,1] und [1,1] sind möglich Es sind alternative Lösungen möglich 5-50

26 Abbildung von Beziehungen (7) Abbildung von Beziehungen (8) Beispiel: Darstellung einer (n:m)-beziehung ER-Diagramm: (n:m)-beziehung PERS PROJ 1 j 1 PERS [0,n] bearbeitet [0,m] PROJ j 2 2 j 3 Umsetzung ins Relationenmodell Abbildung im Relationenmodell PERS (PNR,...) PROJ (JNR,...) PERS (PNR..., PROJ (JNR..., PRIMARY KEY (PNR)) PRIMARY KEY (JNR)) MITARBEIT (PNR..., JNR..., PRIMARY KEY (PNR,JNR), FOREIGN KEY (PNR) REFERENCES PERS, FOREIGN KEY (JNR) REFERENCES PROJ) MITARBEIT (PNR, JNR,...) Diese Standardlösung erzwingt Existenzabhängigkeit von MITARBEIT. Soll dies vermieden werden, dürfen die Fremdschlüssel von MITARBEIT nicht als Teil des Primärschlüssels spezifiziert werden. Direkte (n:m)-abbildung? PERS (PNR, JNR,...) PROJ (JNR, PNR,...) Ist die Realisierung von [1,n] oder [1,m] bei der Abbildung der (n:m)- Beziehung möglich? Referenzgraph PERS PROJ PNR JNR MITARBEIT

27 Abbildung von Beziehungen (9) Abbildung von Beziehungen () Beispiel: Darstellung einer (1:n)-Beziehung als Selbstreferenz ER-Diagramm: (1:n)-Beziehung als Selbstreferenz PERS P1 [0,n] P2 P3 PERS [0,1] hat_ Mgr P4 P5 Umsetzung ins Relationenmodell Mögliche Abbildung (Redundanz!) PERS (PNR,...) HAT_MGR (PNR, MNR...) PERS (PNR..., MNR...,... PRIMARY KEY (PNR), FOREIGN KEY (MNR) REFERENCES PERS (PNR)) Lösung erlaubt Darstellung der Personal-Hierarchie eines Unternehmens. Die referentielle Beziehung stellt hier eine partielle Funktion dar, da die obersten Manager einer Hierarchie keinen Manager haben Abbildung im Relationenmodell MNR... NOT NULL lässt sich nur realisieren, wenn die obersten Manager als ihre eigenen Manager interpretiert werden. Dadurch treten jedoch Referenzzyklen auf, was die Frageauswertung und die Konsistenzprüfung erschwert PERS (PNR,..., MNR) Welche Beziehungsstruktur erzeugt MNR... UNIQUE NOT NULL? Referenzgraph PERS MNR

28 Abbildung von Beziehungen Zusammenfassung Beispiel-Miniwelt Relationenmodell hat wertbasierte Beziehungen ER-Diagramm - Fremdschlüssel (FS) und zugehöriger Primärschlüssel/Schlüsselkandidat (PS/SK) repräsentieren eine Beziehung (gleiche Wertebereiche!) - Alle Beziehungen (FS< >PS/SK) sind binär und symmetrisch - Auflösung einer Beziehung geschieht durch Suche - Es sind i. Allg. k (1:n)-Beziehungen zwischen zwei Relationen möglich ist-dekanvon 0,1 1,1 Fachbereich 0,N gehört-zu 1,1 0,N ist- eingeschr.- in 1,1 Prof Prüfung 0,N 0,M Student Objektorientierte Datenmodelle haben referenzbasierte Beziehungen! Spezifikationsmöglichkeiten in SQL PS PRIMARY KEY (implizit: UNIQUE NOT NULL) SK UNIQUE [NOT NULL] FS [UNIQUE] [NOT NULL] Fremdschlüsseldeklaration (in S) Graphische Darstellung des Relationenschemas FB FBNR FBNAME DEKAN STUDENT MATNR SNAME FBNR STUDBEG V 0,n 0,1 S PROF PNR PNAME FBNR FACHGEBIET 0,n 1,1 0,1 0,1 PRUEFUNG 0,1 1,1 PNR MATNR FACH PDATUM NOTE

29 Spezifikation des relationalen DB-Schemas (nach dem SQL2-Standard) Spezifikation des relationalen DB-Schemas (Fortsetzung) Wertebereiche CREATE DOMAIN FACHBEREICHSNUMMER AS CHAR (4) CREATE DOMAIN FACHBEREICHSNAME AS VARCHAR (20) CREATE DOMAIN FACHBEZEICHNUNG AS VARCHAR (20) CREATE DOMAIN NAMEN AS VARCHAR (30) CREATE DOMAIN PERSONALNUMMER AS CHAR (4) CREATE DOMAIN MATRIKELNUMMER AS INT CREATE DOMAIN NOTEN AS SMALLINT CREATE DOMAIN DATUM AS DATE Relationen CREATE TABLE FB ( FBNR FACHBEREICHSNUMMER PRIMARY KEY, FBNAME FACHBEREICHSNAME UNIQUE, DEKAN PERSONALNUMMER UNIQUE NOT NULL, CONSTRAINT FFK FOREIGN KEY (DEKAN) REFERENCES PROF (PNR) ON UPDATE CASCADE ON DELETE RESTRICT) CREATE TABLE PROF ( PNR PERSONALNUMMER PRIMARY KEY, PNAME NAMEN NOT NULL, FBNR FACHBEREICHSNUMMER NOT NULL, FACHGEBIET FACHBEZEICHNUNG, CONSTRAINT PFK1 FOREIGN KEY (FBNR) REFERENCES FB (FBNR) ON UPDATE CASCADE ON DELETE SET DEFAULT) // Es wird hier verzichtet, die Rückwärtsrichtung der ist-dekan-von -Beziehung explizit als Fremdschlüsselbeziehung zu spezifizieren. Damit fällt auch die mögliche Spezifikation von referentiellen Aktionen weg. CREATE TABLE STUDENT ( MATNR MATRIKELNUMMER PRIMARY KEY, SNAME NAMEN NOT NULL, FBNR FACHBEREICHSNUMMER NOT NULL, STUDBEG DATUM, CONSTRAINT SFK FOREIGN KEY (FBNR) REFERENCES FB (FBNR) ON UPDATE CASCADE ON DELETE RESTRICT) CREATE TABLE PRUEFUNG ( PNR PERSONALNUMMER, MATNR MATRIKELNUMMER, FACH FACHBEZEICHNUNG, PDATUM DATUM NOT NULL, NOTE NOTEN NOT NULL, PRIMARY KEY (PNR, MATNR), CONSTRAINT PR1FK FOREIGN KEY (PNR) REFERENCES PROF (PNR) ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT PR2FK FOREIGN KEY (MATNR) REFERENCES STUDENT (MATNR) ON UPDATE CASCADE ON DELETE CASCADE)

30 DB-Schema PROF Darstellung des Inhalts der Miniwelt in Relationen FB FBNR FBNAME DEKAN PNR PNAME FBNR FACHGEB MATNR SNAME FBNR STUDBEG Ausprägungen PRÜFUNG PNR MATNR FACH DATUM NOTE 5-59 STUDENT FB FBNR FBNAME DEKAN FB 9 WIRTSCHAFTSWISS 4711 FB 5 INFORMATIK 2223 PROF PNR PNAME FBNR FACHGEB 1234 HÄRDER FB 5 DATENBANKSYSTEME 5678 WEDEKIND FB 9 INFORMATIONSSYSTEME 4711 MÜLLER FB 9 OPERATIONS RESEARCH 6780 NEHMER FB 5 BETRIEBSSYSTEME STUDENT MATNR SNAME FBNR STUDBEG COY FB MÜLLER FB ABEL FB SCHULZE FB MAIER FB SCHMID FB PRÜFUNG PNR MATNR FACH PDATUM NOTE BWL OR DV DV SP DV BS Wartung von Beziehungen Relationale Invarianten 1. Primärschlüsselbedingung: Eindeutigkeit, keine Nullwerte! 2. Fremdschlüsselbedingung: Zugehöriger PS (SK) muss existieren Welche PROBLEME sind zu lösen? 1. Operationen in der Sohn-Relation a) Einfügen eines Sohn-Tupels b) Ändern des FS in einem Sohn-Tupel c) Löschen eines Sohn-Tupels Welche Maßnahmen sind erforderlich? - Beim Einfügen erfolgt eine Prüfung, ob in einem Vater-Tupel ein PS/SK-Wert gleich dem FS-Wert des einzufügenden Tupels existiert - Beim Ändern eines FS-Wertes erfolgt eine analoge Prüfung 2. Operationen in der Vater-Relation a) Löschen eines Vater-Tupels b) Ändern des PS/SK in einem Vater-Tupel c) Einfügen eines Vater-Tupels Welche Reaktion ist wann möglich/sinnvoll? - Verbiete Operation - Lösche/ändere rekursiv Tupel mit zugehörigen FS-Werten - Falls Sohn-Tupel erhalten bleiben soll (nicht immer möglich, z.b. bei Existenzabhängigkeit), setze FS-Wert zu NULL oder Default 3. Wie geht man mit NULL-Werten um? - Dreiwertige Logik verwirrend: T, F,? - Vereinbarung: NULL NULL (z. B. beim Verbund) - bei Operationen: Ignorieren von NULL-Werten Spezielle Semantiken von NULL-Werten erforderlich 5-60

31 Wartung der referentiellen Integrität Auswirkungen referentieller Aktionen SQL2-Standard führt referential actions ein - genauere Spezifikation der referentiellen Aktionen - für jeden Fremdschlüssel (FS) separat festzulegen Referentielle Aktionen ON DELETE {CASCADE RESTRICT SET NULL SET DEFAULT NO ACTION} ON UPDATE {CASCADE RESTRICT SET NULL SET DEFAULT NO ACTION} 1. Sind Nullen verboten? NOT NULL 2. Löschregel für Zielrelation (referenzierte Relation) ON DELETE {NO ACTION CASCADE SET NULL SET DEFAULT RESTRICT 9 } 3. Änderungsregel für Ziel-Primärschlüssel (PS oder SK) ON UPDATE {NO ACTION CASCADE SET NULL SET DEFAULT RESTRICT} NO ACTION CASCADE Sie ist die Defaulteinstellung. Für die spezifizierte Referenz wird keine referentielle Aktion ausgeführt. Durch eine DB- Operation können jedoch mehrere Referenzen (mit unterschiedlichen Optionen) betroffen sein; am Ende aller zugehörigen referentiellen Aktionen wird die Einhaltung der referentiellen Integrität geprüft Operation kaskadiert zu allen zugehörigen Sätzen 1. Isolierte Betrachtung von STUDENT FB FBNR STUDENT FB Beispiel-DB FB FBNR FBNAME FB9 WIRTSCHAFTSWISS FB5 INFORMATIK STUDENT MATNR SNAME FBNR COY FB MÜLLER FB ABEL FB SCHULZE FB 9 Operationen - Lösche FB (FBNR=FB5) - Ändere FB ((FBNR=FB9) (FBNR=FB)) SET NULL SET DEFAULT RESTRICT FS wird in zugehörigen Sätzen zu Null gesetzt FS wird in den zugehörigen Sätzen auf einen benutzerdefinierten Default-Wert gesetzt Operation wird nur ausgeführt, wenn keine zugehörigen Sätze (FS-Werte) vorhanden sind Referentielle Aktionen - DC, DSN, DSD, DR, DNA - UC, USN, USD, UR, UNA Eindeutigkeit der Operationen? 9. Die Option RESTRICT kam in SQL:1999 neu hinzu; sie ist restriktiver als NO ACTION, da eine integritätsverletzende Anweisung sofort zurückgewiesen wird

32 Auswirkungen referentieller Aktionen (2) Auswirkungen referentieller Aktionen (3) 2. Isolierte Betrachtung von STUDENT PRUEFUNG PROF PROF STUDENT PNR MATNR PRUEFUNG Beispiel-DB PROF PNR PNAME STUDENT MATNR SNAME 1234 HÄRDER COY 4711 MÜLLER ABEL 3. Vollständiges Beispiel FB DC DC FBNR FBNR PROF STUDENT PNR MATNR DC DC PRUEFUNG Einsatz von - USN, DSN Schlüsselverletzung - USD, DSD ggf. Mehrdeutigkeit - UNA, DNA Wirkung identisch mit UR, DR Auswirkungen von Aktualisierungsoperationen - Verträglichkeit der Referentiellen Aktionen PRÜFUNG PNR MATNR FACH OR DV DV OR Student Prof DC DR UC UR DC DR UC UR Unabhängige referentielle Beziehungen können unabhängig definiert und gewartet werden 5-63 Lösche FB (FBNR=FB9) erst links erst rechts - Löschen in FB - Löschen in FB - Löschen in PROF - Löschen in STUDENT - Löschen in PRUEFUNG - Löschen in PRUEFUNG - Löschen in STUDENT - Löschen in PROF - Löschen in PRUEFUNG - Löschen in PRUEFUNG Ergebnis der Operation unabhängig von der Reihenfolge der referentiellen Aktionen Eindeutigkeit des erreichten DB-Zustandes Was heißt Unabhängigkeit der referentiellen Beziehungen? - Es sind mehrere Kombinationen von referentiellen Aktionen möglich: z. B. DSD, UC oder DC, USN - Eindeutigkeit bei allen Aktualisierungsoperationen sicheres Schema 5-64

33 Auswirkungen referentieller Aktionen (4) Auswirkungen referentieller Aktionen (5) 4. Modifikation des Schemas 5. Weitere Modifikation des Schemas PROF DC FB DC STUDENT PROF DC FB DC STUDENT DC PRUEFUNG DR DC PRUEFUNG DNA Lösche FB (FBNR=FB9) Lösche FB (FBNR=FB9) erst links erst rechts - Löschen in FB - Löschen in FB - Löschen in PROF - Löschen in STUDENT - Löschen in PRUEFUNG - Zugriff auf PRUEFUNG - Löschen in STUDENT Wenn ein gerade gelöschter Student - Zugriff auf PRUEFUNG eine Prüfung abgelegt hatte Wenn ein Student bei einem Rücksetzen FB-fremden Professor geprüft sonst: wurde - Löschen in PROF Rücksetzen - Löschen in PRUEFUNG Es können reihenfolgenabhängige Ergebnisse auftreten! Die Reihenfolgenabhängigkeit ist hier wertabhängig erst links erst rechts - Löschen FB - Löschen FB - Löschen PROF - Löschen STUDENT - Löschen PRUEFUNG - Löschen PROF - Löschen STUDENT - Löschen PRUEFUNG Test, ob es noch offene Test, ob es noch offene Referenzen in PRUEFUNG Referenzen in PRUEFUNG auf gelöschte Studenten gibt; auf gelöschte Studenten gibt; wenn ja Rücksetzen wenn ja Rücksetzen - Bei der NA-Option wird der explizite Test der referenzierenden Relation ans Ende der Operation verschoben. Eine Verletzung der referentiellen Beziehung führt zum Rücksetzen. Schema ist immer sicher

34 Eindeutigkeit referentieller Aktionen Durchführung der Änderungsoperationen Aufgabe Verhinderung von mehrdeutigen DB-Operationen Prüfung der referentiellen Integrität (IMMEDIATE/DEFERRED) Maßnahmen BOT Op 1 Op 2 Op 3 COMMIT - Statische Schemaanalyse zur Feststellung sicherer DB-Schemata nur bei einfach strukturierten Schemata effektiv bei wertabhängigen Konflikten zu restriktiv (konfliktträchtige Schemata) Hohe Komplexität der Analysealgorithmen - Dynamische Überwachung der Modifikationsoperationen Bei zyklischen Referenzpfaden FS1 hoher Laufzeitaufwand ABT MGR Vorgehensweise 1. Falls Sicherheit eines Schemas festgestellt werden kann, ist keine Laufzeitüberwachung erforderlich 2. Alternative Möglichkeiten zur Behandlung konfliktträchtiger Schemata a) Sie werden verboten: - Statische Schemaanalyse kann Sicherheit eines Schemas nicht feststellen Dabei sind ggf. pessimistische Annahmen zu treffen, je nachdem, ob bei der Analyse nur Relationen oder auch ihre Attribute (Attributkonflikte) betrachtet werden. b) Sie werden erlaubt: - Die referentiellen Aktionen werden bei jeder Operation dynamisch überwacht - Falls ein Konflikt erkannt wird, wird die Operation zurückgesetzt - wenigstens ein Fremdschlüssel im Zyklus muss NULL erlauben oder - Prüfung der referentiellen Integrität muss verzögert (DEFERRED) werden (z. B. bei COMMIT) Durchführung der referentiellen Aktionen (RA) - Benutzeroperationen (Op) sind in SQL immer atomar - mengenorientiertes oder satzorientiertes Verarbeitungsmodell t 1 Op t 2... t n RA s FS2 - IMMEDIATE-Bedingungen müssen erfüllt sein an Anweisungsgrenzen ( mengenorientierte Änderung) t 1 RA Op t 2 RA... t n RA

35 Beispiel Data Warehousing Create Table Produkt (Pnr P-Nummer (*Domaindef.*), Bezeichnung Char(40),..., Primary Key (Pnr)) Create Table Verkäufer (Vnr V-Nummer (*Domaindef.*) VName Char(20),..., Primary Key (Vnr)) Create Table Zeit (Znr Z-Nummer (*Domaindef.*) Datum Date NOT NULL, Besonderheit Char(80)..., Primary Key (Znr)) Kauf als Entity mit unabhängigen Beziehungen ER-Diagramm Verkäufer l Zeit Produkt m k 1 1 Create Table Lieferant (Lnr L-Nummer (*Domaindef.*) LName Char(20), Ort...,..., Primary Key (Lnr) Create Table Markt (Mnr M-Nummer (*Domaindef.*) Adresse...,..., Primary Key (Mnr)) Kauf Create Table Kauf (Knr K-Nummer (* Unique Not Null*), Pnr P-Nummer (*siehe Domaindefinition*), Vnr V-Nummer (*siehe Domaindefinition*) Znr Z-Nummer (*siehe Domaindefinition*), Lnr L-Nummer (*siehe Domaindefinition*), Mnr M-Nummer (*siehe Domaindefinition*), Menge Integer NOT NULL, Preis Money NOT NULL, Primary Key (Knr), Foreign Key (Pnr) References Produkt ON DELETE SET DEFAULT (oder SET NULL), Foreign Key (Vnr) References Verkäufer ON DELETE SET DEFAULT (oder SET NULL), Foreign Key (Znr) References Zeit ON DELETE SET DEFAULT (oder SET NULL), Foreign Key (Lnr) References Lieferant ON DELETE SET DEFAULT (oder SET NULL), Foreign Key (Mnr) References Markt ON DELETE SET DEFAULT (oder SET NULL)) Lieferant n o Markt Kauf als 5-stellige Beziehung ER-Diagramm Beispiel Data Warehousing (2) Verkäufer Zeit l Produkt m k Create Table Kauf (Pnr P-Nummer (*siehe Domaindefinition*), Vnr V-Nummer (*siehe Domaindefinition*) Znr Z-Nummer (*siehe Domaindefinition*), Lnr L-Nummer (*siehe Domaindefinition*), Mnr M-Nummer (*siehe Domaindefinition*), Menge Integer Not Null, Preis Money Not Null, Primary Key (Pnr, Vnr, Znr, Lnr, Mnr), Foreign Key (Pnr) References Produkt ON DELETE CASCADE, Foreign Key (Vnr) References Verkäufer, ON DELETE CASCADE, Foreign Key (Znr) References Zeit, ON DELETE CASCADE, Foreign Key (Lnr) References Lieferant, ON DELETE CASCADE, Foreign Key (Mnr) References Markt ON DELETE CASCADE) Kauf als existenzabhängiges Entity mit 5 begründ. binären Beziehungen Zeit Lieferant ER-Diagramm m LfdNr n Verkäufer l Produkt k Kauf Kauf 1 1 Lieferant n o o Markt Markt Existenzabhängigleit wird über den Primärschlüssel von Kauf ausgedrückt: Er besteht aus LfdNr und von den konstituierenden Entities ererbten Schlüsselteilen

36 Beispiel Data Warehousing (3) Kauf als existenzabhängiges Entity mit 5 begründenden binären Beziehungen (Forts.) Create Table Kauf (LfdNr Integer, (Pnr P-Nummer (*siehe Domaindefinition*), Vnr V-Numer (*siehe Domaindefinition*) Znr Z-Nummer (*siehe Domaindefinition*), Lnr L-Nummer (*siehe Domaindefinition*), Mnr M-Nummer (*siehe Domaindefinition*), Menge Integer Not Null, Preis Money Not Null, Primary Key (LfdNr, Pnr, Vnr, Znr, Lnr, Mnr), Foreign Key (Pnr) References Produkt ON DELETE CASCADE, Foreign Key (Vnr) References Verkäufer ON DELETE CASCADE, Foreign Key (Znr) References Zeit ON DELETE CASCADE, Foreign Key (Lnr) References Lieferant ON DELETE CASCADE, Foreign Key (Mnr) References Markt ON DELETE CASCADE) Kauf als existenzabhängiges Entity mit einer begr. 6-stelligen Beziehung ER-Diagramm l Verkäufer k Produkt Create Table Kauf (LfdNr Integer, Pnr P-Nummer (*siehe Domaindefinition*), Vnr V-Numer (*siehe Domaindefinition*) Znr Z-Nummer (*siehe Domaindefinition*), Lnr L-Nummer (*siehe Domaindefinition*), Mnr M-Nummer (*siehe Domaindefinition*), Menge Integer Not Null, Preis Money Not Null, Primary Key (LfdNr, Pnr, Vnr, Znr, Lnr, Mnr) Foreign Key (Pnr) References Produkt ON DELETE CASCADE, Foreign Key (Vnr) References Verkäufer ON DELETE CASCADE, Foreign Key (Znr) References Zeit ON DELETE CASCADE, Foreign Key (Lnr) References Lieferant ON DELETE CASCADE, Foreign Key (Mnr) References Markt ON DELETE CASCADE) Beide existenzabhängigen Modellierungen unterscheiden sich in SQL nicht! Kauf 1 hat o Markt 5-71 LfdNr n Lieferant m Zeit SQL-Anfragen Zusammenfassung - Mengenorientierte Spezifikation, verschiedene Typen von Anfragen - Vielfalt an Suchprädikaten - Auswahlmächtigkeit von SQL ist höher als die der Relationenalgebra. - Erklärungsmodell für die Anfrageauswertung: Festlegung der Semantik von Anfragen mit Hilfe von Grundoperationen - Optimierung der Anfrageauswertung durch das DBS Mengenorientierte Datenmanipulation Datendefinition - CHECK-Bedingungen für Wertebereiche, Attribute und Relationen - Spezifikation des Überprüfungszeitpunktes Kontrolle von Beziehungen - SQL erlaubt nur die Spezifikation von binären Beziehungen. - Referentielle Integrität von FS --> PS/SK wird stets gewährleistet. - Rolle von PRIMARY KEY, UNIQUE, NOT NULL - Es ist nur eine eingeschränkte Nachbildung von Kardinalitätsrestriktionen möglich; insbesondere kann nicht spezifiziert werden, dass ein Vater Söhne haben muss. Wartung der referentiellen Integrität - SQL2/3 bietet reichhaltige Optionen für referentielle Aktionen - Es sind stets sichere Schemata anzustreben - Falls eine statische Schemaanalyse zu restriktiv für die Zulässigkeit eines Schemas ist, muss für das gewünschte Schema eine Laufzeitüberwachung der referentiellen Aktionen erfolgen. 5-72