3.3 Constraints, Views, Triggers. Regelkonzepte in SQL: Übersicht

Transkript

1 3.3 Constraints, Views, Triggers Datendefinition und Datenmanipulation in SQL 3.3 Constraints, Views and Triggers in SQL 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 Regelkonzepte in SQL: Übersicht SQL-Schemata enthalten nicht nur reine Strukturdefinitionen, sondern können auch mit semantischem Wissen über den jeweiligen Anwendungsbereich "angereichert" werden, so dass eine "vernünftige" Verwendung der DB erfolgen kann. Drei Repräsentationsformen für logische Zusammenhänge zwischen Tabellen: deklarativ dargestellt: konstruktiv (zur Datenherleitung): Sichten (views) normativ/restriktiv: Integritätsbedingungen (constraints) imperativ dargestellt: Festlegungen automatisch ausgelöster Folgeänderungen "Auslöser" (triggers) Alle drei "Wissensformen" werden aus als Regeln bezeichnet. in diesem Abschnitt: kurze Einführung in die wichtigsten Konzepte zu SQL-Regeln Vertiefung möglich in Spezialvorlesungen zu diesen Konzepten: deduktive Datenbanken (views, constraints) aktive Datenbanken (triggers, constraints) 2002 Prof. Dr. Rainer Manthey Informationssysteme 2

2 Constraints - Integritätsbedingungen Constraints in SQL 2002 Prof. Dr. Rainer Manthey Informationssysteme 3 Constraint-Arten in SQL: Wiederholung Im Zusammenhang mit Schemadefinition wurden bereits verschiedene Formen von Integritätsbedingungen (engl.: [integrity] constraints) eingeführt, die sich direkt auf einzelne Tabellen beziehen: Bei CREATE TABLE-Anweisungen: "column constraints": NOT NULL, UNIQUE, CHECK "row constraints": UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK Auch bei der Definition von Wertebereichen mittels CREATE DOMAIN können "domain constraints" ähnlich "column constraints" definiert werden. CHECK-Constraint für ganze Tabelle: beliebige Bedingung als Integritätsbedingung für diese Tabelle (Absicht der SQL-Designer) Überprüfung der Bedingung bei jeder die Tabelle betreffenden Änderung. Normalfall : CHECK-Bedingung referenziert nur Spalten der jeweiligen Tabelle. aber auch zulässig: CHECK-Bedingung enthält geschachteltes SELECT Überprüfung wird ausgedehnt auf andere Tabellen sogar denkbar: CHECK-Bedingung referenziert ihre Tabelle gar nicht! 2002 Prof. Dr. Rainer Manthey Informationssysteme 4

3 Nicht-lokale CHECK-Constraints Beispiel für eine CHECK-Constraint, die eine "fremde" Tabelle referenziert: CREATE TABLE prüfer ( Name CHAR NOT NULL, CHECK ( Name IN ( SELECT Name FROM professoren )) ) Nur Professoren dürfen Prüfer sein! Würde die Integritätsbedingung nur bei Änderungen der 'prüfer'-tabelle erfolgen, "für die" diese Constraint (lokal) definiert ist, dann gäbe es leicht inkonsistente Zustände! Grund: Sowie ein Professor aus der 'professoren'-tabelle entfernt wird, wären alle 'prüfer'-zeilen, die diesen Professor referenzieren "inkonsistent" im Sinne der obigen Beschränkung! Die hier diskutierte CHECK-Constraint ist direkt äquivalent zu einer Fremdschlüsselbeschränkung auf der Spalte Name! 2002 Prof. Dr. Rainer Manthey Informationssysteme 5 Globale Integritätsbedingungen in SQL bisher nicht behandelt, aber im Standard definiert: assertions (dt.: Zusicherungen) Assertions dienen zur Formulierung globaler Integritätsbedingungen, die semantisch nicht an einzelne Tabellen gebunden sind. Syntaxformat: CREATE ASSERTION <constraint-name> CHECK ( <conditional-expression> ) Assertions sind im Prinzip ausreichend um alle denkbaren Integritätsbedingungen auszudrücken, d.h. alle "lokalen" Formen von Constraints sind redundant Constraint zur 'prüfer'-tabelle als Assertion (offensichtlich aufwändiger): CREATE ASSERTION ausreichend_qualifiziert CHECK NOT EXISTS ( SELECT * FROM prüfer P WHERE P.Name NOT IN ( SELECT Name FROM professoren ) ; 2002 Prof. Dr. Rainer Manthey Informationssysteme 6

4 CHECK-Constraints als Assertions Generelles Prinzip der Umformung (lokaler) CHECK-Constraints in (globale) Assertions: CREATE TABLE t (..... CONSTRAINT icname CHECK ( c )... ) Optional für jede CHECK-Constraint möglich! CREATE ASSERTION icname CHECK NOT EXISTS ( SELECT * FROM t WHERE NOT (c ) ) entspricht einem ansonsten impliziten Allquantor: "Für alle Zeilen von t gilt c!" 2002 Prof. Dr. Rainer Manthey Informationssysteme 7 Assertions als CHECK-Constraints? Ist es umgekehrt möglich, jede Assertion durch (ggf. mehrere) CHECK-Constraints auszudrücken, die auf alle beteiligten Tabellen verteilt sind? im Beispiel: Die Assertion ist direkt äquivalent zu der lokalen Version, die wir bereits auf der 'prüfer'-tabelle kennengelernt haben. Aber könnte man sie ebensogut auch auf der 'professoren'-tabelle lokal vereinbaren, die ja genauso betroffen ist wie 'prüfer'? CREATE ASSERTION ausreichend_qualifiziert CHECK NOT EXISTS ( SELECT * FROM prüfer P WHERE P.Name NOT IN ( SELECT Name FROM professoren )) CREATE TABLE prüfer (......, CHECK ( Name IN ( SELECT Name FROM professoren ) ) ) CREATE TABLE professoren (..., CHECK? ) 2002 Prof. Dr. Rainer Manthey Informationssysteme 8

5 Assertions repräsentiert durch CHECK-Constraints CREATE ASSERTION ausreichend_qualifiziert CHECK NOT EXISTS ( SELECT * FROM prüfer P WHERE P.Name NOT IN ( SELECT Name FROM professoren )) einzige "Lösung" hier: CHECK-Bedingung der Assertion unverändert als CHECK-Constraint auf der Tabelle 'professoren' übernehmen CREATE TABLE professoren (...., CHECK NOT EXISTS ( SELECT * FROM prüfer P WHERE P.Name NOT IN ( SELECT Name FROM professoren )) Unterschiedliche Bedeutung, wenn Professoren- Tabelle leer ist!! 2002 Prof. Dr. Rainer Manthey Informationssysteme 9 CHECK-Constraints mit Referenzen und Assertions: Resümee Die Verwendung der beiden "anspruchsvollen" Formen von SQL-Integritätsbedingungen - CHECK-Constraints mit eingebetteten Anfragen und Assertions - erfordert ein sehr gutes Verständnis der Möglichkeiten zur Formulierung von Bedingungsausdrücken in SQL ganz generell! Insbesondere die Wahl zwischen dem "Lokalisieren" tabellenübergreifender Constraints als Tabellenbeschränkungen oder dem Gebrauch globaler Assertions ist diffizil und sehr fehlerträchtig! im Zweifelsfall: Assertions verwenden! Leider werden beide Konzepte bisher von kommerziellen Produkten nicht zugelassen, obwohl sie seit langem zum SQL-Standard gehören! In der Forschung sind seit langem Methoden zur effizienten Überprüfung solcher "Mehrtabellenbeschränkungen" bekannt. Wer also komplexere Integritätsanforderungen formulieren will, muss auf "Notlösungen" mittels imperativem Code in Anwendungsprogrammen zurückgreifen Prof. Dr. Rainer Manthey Informationssysteme 10

6 Integritätsprüfung in SQL wichtiges Thema im Zusammenhang mit SQL-Constraints: Modalitäten der Überprüfung von Integritätsbedingungen Änderungen werden in SQL i.a. im Rahmen von Transaktionen abgesetzt: Transaktion: Folge von DML-Anweisungen, die als "unteilbare Einheit" angesehen wird Ausführung einer Transaktion erfolgt entweder ganz oder gar nicht! Transaktionen müssen immer zu konsistenten DB-Zuständen führen (alle Integritätsbedingungen erfüllt) genauere Diskussion des Konzepts "Transaktion": später separat! wichtiges Motiv zur Einführung von Transaktionen: Manche Übergänge von konsistentem Zustand in konsistenten Folgezustand sind nur durch inkonsistente Zwischenschritte möglich! Konsequenz für Integritätsprüfung bei Transaktionsverarbeitung: Prüfung sollte (eigentlich immer) am Transaktionsende erfolgen! 2002 Prof. Dr. Rainer Manthey Informationssysteme 11 Integritätsprüfung in SQL (2) in SQL dagegen: Wenn nichts Gegenteiliges definiert, erfolgt Integritätsprüfung immer sofort (d.h., direkt nach Bearbeiten der Änderung). Motivation: Viele einfache Tabellen-Constraints können und sollten sofort geprüft werden, da sie unabhängig von allen anderen Änderungen sind. aber insbesondere für referentielle Zyklen : Prüfung am Transaktionsende ist unerlässlich! z.b.: C 1 : "Jede Vorlesung wird von einem Professor gehalten!" C 2 : "Jeder Professor muss mindestens eine Vorlesung halten!" Vorlesung Professor Bei Einstellung eines neuen Professors wird ein konsistenter Zustand nur durch eine Transaktion aus zwei Einzeleinfügungen erreicht: INSERT INTO professoren INSERT INTO vorlesungen Jeder Zwischenzustand wäre inkonsistent: Keine Reihung möglich! 2002 Prof. Dr. Rainer Manthey Informationssysteme 12

7 Integritätsprüfung in SQL (3) daher: zwei Formen der Integritätsprüfung in SQL vorgesehen IMMEDIATE und DEFERRED Bedeutung: IMMEDIATE-Constraints werden sofort überprüft, DEFERRED-Constraints erst am Transaktionsende: leider: ohne explizite Angabe wird IMMEDIATE als Default-Modus angenommen: Ändern dieser Default-Einstellung: zusätzliche Klausel bei Constraint-Vereinbarung INITIALLY DEFERRED INITIALLY (dt.: anfangs)? Während einer Transaktion kann Default dynamisch geändert werden: SET CONSTRAINTS { < list-of-constraints > ALL } { DEFERRED IMMEDIATE } zusätzlich: Manche Constraints können als NOT DEFERRABLE deklariert werden. Fazit: Integritätsprüfung in "vollem" SQL ist eine diffizile Angelegenheit! 2002 Prof. Dr. Rainer Manthey Informationssysteme 13 Triggers - Reaktionsauslöser Triggers in SQL 2002 Prof. Dr. Rainer Manthey Informationssysteme 14

8 Trigger und aktive Datenbanken bereits in frühen SQL-Entwürfen und in ersten relationalen Systemen: Automatische Auslösung von Änderungen durch das DBMS als Reaktion auf explizite Änderungen durch Benutzer oder Anwendungsprogramme vorgesehen Vereinbarungen solcher automatischen Folgeänderungen in Regelform: Trigger andere Bezeichnung für Trigger: aktive Regel Bezeichnung für DBMS, das Trigger unterstützt: aktives DBMS Name des zugehörigen Forschungsgebiets: aktive Datenbanken im SQL92-Standard: noch kein Triggerkonzept vorgesehen aber: Trigger wurden bereits in fast allen kommerziellen DB-Produkten in ähnlicher Form seit längerem angeboten (ORACLE, DB/2, Sybase, Informix u.a.) im neuen SQL3-Standard (1999): umfangreiches Triggerkonzept erstmals standardisiert 2002 Prof. Dr. Rainer Manthey Informationssysteme 15 Aktive Regeln Aktive Regeln werden auch ECA-Regeln genannt, womit die drei Bestandteile dieser Regeln hervorgehoben werden: E C A "event" Ereignisspezifikation "condition" Auslösebedingung "action" Aktionsspezifikation Beispiel einer ECA-Regel (in Pseudo-Code): E C A ON IF DO modify(kontostand(k), V_neu) V_neu < dispositionskredit(k) sperre_konto(k) 2002 Prof. Dr. Rainer Manthey Informationssysteme 16

9 Aktive Regeln (2) prinzipielle Bedeutung einer aktiven Regel: zusätzliche, automatisch ausgelöste "Hintergrundaktivität" "Oberflächenprozeß" (z.b. Transaktion)... (suspendiert)... beobachten E C A? reagieren "Hintergrundaktivität" prüfen Kann rekursiv weitere aktive Regeln auslösen! 2002 Prof. Dr. Rainer Manthey Informationssysteme 17 SQL-Trigger: erstes Beispiel Beispiel eines SQL-Triggers: Auslösezeitpunkt Triggername CREATE TRIGGER erstevorlesung AFTER INSERT ON professoren REFERENCING NEW ROW AS Newcomer FOR EACH ROW WHEN (NOT EXISTS ( SELECT * Bedingung Aktion auslösende Änderung FROM vorlesungen WHERE Name = Newcomer.Name ) BEGIN ATOMIC INSERT INTO vorlesungen VALUES (Newcomer.Name, NULL, 4-std.); INSERT INTO übungen VALUES (Newcomer.Name, NULL, 2-std.) END "Transitionsvariable" 2002 Prof. Dr. Rainer Manthey Informationssysteme 18

10 SQL-Trigger: Zwischenbilanz Triggerkonzept von SQL: offenbar syntaktisch und semantisch ziemlich anspruchsvoll! im Gegensatz zu Views und Constraints: Trigger werden von Access bisher nicht direkt unterstützt! (nur indirekt über Formulare und Makros z.t. in Visual Basic) daher: detailliertere Einführung in SQL-Trigger erst später in dieser Vorlesung Auch das Zusammenwirken von Triggern und den (konzeptuell sehr ähnlichen) "referential actions" bei Fremdschlüsselbedingungen erfolgt später zusammen mit der Triggerdiskussion. wegen semantischer Probleme (komplexes Ausführungsmodell, komplexes Zusammenspiel mit Integritätsprüfung): SQL-Trigger werden bisher in der Praxis nur selten und mit grosser Vorsicht verwendet! aber: Anwendungsmöglichkeiten für aktive DB-Technologie sind sehr groß und gehen weit über die ursprüngliche Motivation durch "Reparatur" von Integritätsverletzungen hinaus! 2002 Prof. Dr. Rainer Manthey Informationssysteme 19 Views - Sichten Views in SQL 2002 Prof. Dr. Rainer Manthey Informationssysteme 20

11 Anfragen an Sichten: Expandierung zur Erinnerung: Sichtendefinition durch Kopplung eines Tabellennamens mit einer Anfrage (Tabellenausdruck) z.b.: CREATE VIEW C4-profs AS ( SELECT Name, Abteilung FROM professoren WHERE Grad = C4 ) Beantwortung von Anfragen, die sich auf Sichten beziehen, durch vorherige Expandierung der Sichtdefinition: statisches Einsetzen des AS-Ausdrucks SELECT Name FROM C4-profs WHERE Abteilung = III SELECT X.Name FROM ( SELECT Name, Abteilung FROM professoren WHERE Grad = C4 ) WHERE X.Abteilung = III AS X 2002 Prof. Dr. Rainer Manthey Informationssysteme 21 Rekursive Sichten Die Behandlung von Sichten in Anfragen durch Expandierung hat natürlich ihre Grenzen, wenn Sichtdefinitionen rekursiv werden, d.h., wenn eine Sicht sich in ihrem eigenen definierenden Ausdruck selbst referenziert. Beispiel: Gegeben eine Basistabelle 'direkt_benachbart' - definiere eine Sicht 'erreichbar', die Erreichbarkeit über Pfade von direkten benachbarten Knoten beliebiger Länge ausdrückt. In SQL könnte dies im Prinzip so aussehen: CREATE VIEW erreichbar AS ( (SELECT * FROM direkt_benachbart) UNION (SELECT X.von, Y.nach FROM direkt_benachbart AS X, erreichbar AS Y WHERE X.nach = Y.von) ) Diese Definition ist in SQL so nicht direkt erlaubt, aber seit SQL:1999 relativ ähnlich möglich (WITH RECURSIVE...). Um Anfragen über rekursiven Sichten beantworten zu können, muss das DBMS schrittweise während der Auswertung expandieren und stets auf Abbruch testen Prof. Dr. Rainer Manthey Informationssysteme 22

12 Änderungen von Sichten Sichten lassen sich auf zweierlei Weise ändern: Änderungen der zugrundeliegenden Basistabellen sind indirekt die Ursache für zusätzliche oder wegfallende Ableitungsmöglichkeiten: induzierte Änderungen der Sicht Änderungsbefehle werden direkt für die Sicht formuliert und müssen durch systematische Zurückführung auf die zugrundeliegenden Basistabellen realisiert werden: Sichtenänderungen (engl.: "view updates") in SQL: Induzierte Änderungen zeigen sich implizit bei der nächsten, auf die Basisdatenänderung folgenden Anfrage an die Sicht. Sichtenänderungen sind unter "strengen Auflagen" zugelassen, wenn eine eindeutige und sinnvolle automatische Realisierung möglich ist. Forschungsprobleme: nähere Diskussion in der Vorlesung "Deduktive DB" Wie bestimmt man effizient alle induzierten Änderungen? Welche Alternativen gäbe es für die Realisierung (da wo SQL "aufgibt")? 2002 Prof. Dr. Rainer Manthey Informationssysteme 23 Änderungen von Sichten: Beispiel induzierte Änderung auf einer Sicht: CREATE VIEW C4-profs AS ( SELECT Name, Abteilung FROM professoren WHERE Grad = C4 ) C4-profs professoren Name Abteilung Name Abteilung Grad induziert: Martini IV Martini IV C4 INSERT INTO professoren VALUES (,Martini',,IV',,C4') 2002 Prof. Dr. Rainer Manthey Informationssysteme 24

13 Änderungen von Sichten: Beispiel (2) INSERT INTO C4-profs VALUES (,Klein',,I') Sichtenänderung CREATE VIEW C4-profs AS ( SELECT Name, Abteilung FROM professoren WHERE Grad = C4 ) realisiert durch C4-profs professoren Name Abteilung Name Abteilung Grad induziert: Klein I Klein I C4 Sichtenänderungen werden immer nur indirekt durch eine induzierte Änderung wirksam! 2002 Prof. Dr. Rainer Manthey Informationssysteme 25 Sichtenänderungen in SQL: einfaches Grundprinzip häufig: Prinzipiell analoge Behandlung von Sichtenänderungen ("view updates") durch Expandierung ist möglich. Bei Modifikationen ist die Umsetzung meist offensichtlich, z.b.: CREATE VIEW C4-profs AS ( SELECT Name, Abteilung FROM professoren WHERE Grad = C4 ) UPDATE C4-profs SET Name = N.N. WHERE Abteilung = II UPDATE professoren SET Name = N.N. WHERE Abteilung = II AND Grad = C4 analog: Löschen von Zeilen in einer Sicht ist übersetzbar durch Löschen von Zeilen der zugrundeliegenden Basistabellen. bei Einfügungen: In der Sicht fehlende Spalten der Basistabellen sind "auffüllbar" durch Default-Werte (sofern deklariert) oder NULL Prof. Dr. Rainer Manthey Informationssysteme 26

14 Sichtenänderungen: problematische Fälle Problem: Es gibt Sichten, bei denen Änderungen gar nicht oder nicht eindeutig durch Expandierung auf Basistabellen rückführbar sind. charakteristisches Beispiel: JOIN-Sicht professoren Anlauf C3 II Baier C3 I Buhmann C3 III Cremers C4 III?? CREATE VIEW verantwortliche_abt AS ( SELECT P.Abteilung, V.Semester, V.Titel FROM professoren P, vorlesungen V WHERE P.Name = V.name ) vorlesungen Anlauf Inf I WS 00/01 Baier Inf III WS 00/01 Cremers Inf III WS 02/03 INSERT INTO verantwortliche_abt VALUES ( III, WS 01/02, Inf I ) 2002 Prof. Dr. Rainer Manthey Informationssysteme 27 Sichtenänderungen: problematische Fälle Analoge Anwendung des Prinzips "Verwende Defaults für fehlende Werte!" würde zu folgenden Einfügungen führen (mit N.N. als generellem Namensdefault): professoren Anlauf C3 II Baier C3 I Buhmann C3 III Cremers C4 III N.N. C4 III CREATE VIEW verantwortliche_abt AS ( SELECT P.Abteilung, V.Semester, V.Titel FROM professoren P, vorlesungen V WHERE P.Name = V.name ) vorlesungen Anlauf Inf I WS 00/01 Baier Inf III WS 00/01 Cremers Inf III WS 02/03 INSERT INTO verantwortliche_abt VALUES ( III, WS 01/02, Inf I ) N.N. Inf I WS 01/02 Aber ist diese Lösung wirklich gemeint? Warum soll nicht einer der aufgeführten Professoren der Abt. III die Vorlesung halten? Aber welcher? Und wieso gerade ein C4rer? 2002 Prof. Dr. Rainer Manthey Informationssysteme 28

15 Sichtenänderungen: problematische Fälle (3) professoren Anlauf C3 II Baier C3 I Buhmann C3 III Cremers C4 III vorlesungen Anlauf Inf I WS 00/01 Baier Inf III WS 00/01 Cremers Inf III WS 02/03 Noch offensichtlicheres Problem bei Löschungen aus Join-Sichten, z.b.: DELETE FROM verantwortliche_abt WHERE Semester = WS 00/01 AND Titel = Inf III AND Abteilung =,I' zu löschende Sichtzeile: ( I, WS 00/01, Inf III ) Zeile entsteht durch Join folgender Basistabellen-Zeilen: a) in professoren: ( Baier, C3,,I' ) b) in vorlesungen: ( Baier, Inf III, WS 00/01 ) Welche dieser beiden Zeilen soll gelöscht werden? a) oder b) oder beide?? 2002 Prof. Dr. Rainer Manthey Informationssysteme 29 Sichtenänderungen: problematische Fälle (4) DELETE FROM verantwortliche_abt WHERE Semester = WS 00/01 AND Titel = Inf III AND Abteilung = I professoren Anlauf C3 II Baier C3 I Buhmann C3 III Cremers C4 III? vorlesungen Anlauf Inf I WS 00/01 Baier Inf III WS 00/01 Cremers Inf III WS 02/03 Pragmatisch "vernünftige" Lösung: DBMS analysiert Sichtenänderung und bestimmt alle sinnvollen Alternativen der Realisierung Benutzer, der die Änderung wünscht, entscheidet darüber, welche Variante "gemeint" ist (in interaktivem Dialog) im Beispiel: Offensichtlich ist nur die Löschung aus 'vorlesungen' gemeint! 2002 Prof. Dr. Rainer Manthey Informationssysteme 30

16 Änderbare Sichten in SQL in Standard-SQL: Stattdessen drastische Beschränkung der Zulässigkeit von Änderungsoperationen auf Sichten Konzept der änderbaren Sicht (engl.: updatable view ) Ist eine Sicht änderbar, dann sind alle Änderungsoperationen auf dieser Sicht zulässig. Ist eine Sicht dagegen nicht änderbar, dann ist keine solche Operation zulässig. (Differenzierung nach Änderungsart erfolgt nicht, obwohl oft sinnvoll!) Diese Beschränkung ist drastisch, da auch Fälle verhindert werden, in denen eine sinnvolle Rückführung auf Basistabellen denkbar wäre. auch bei änderbaren Sichten: Fehlschlag einer Sichtenänderung ist möglich, wenn Integritätsbedingungen auf zugrundeliegenden Basistabellen durch automatische Rückführung verletzt würden... Defaultvereinbarungen für benötigte Spalten fehlen (bei INSERT) 2002 Prof. Dr. Rainer Manthey Informationssysteme 31 Änderbare Sichten (2) Bedingungen für Änderbarkeit von Sichten in SQL (u.a.): AS-Teil der Sichtdefinition muss ein SELECT-Block sein! ( keine relationenalgebraische Verknüpfung) Kein SELECT DISTINCT zulässig! In der SELECT-Liste: nur direkte, einfache Spaltenreferenzen möglich! (d.h. keine Aggregierung zulässig) FROM-Teil darf nur genau eine Tabelle referenzieren (Basistabelle oder weitere Sicht) Wenn der FROM-Teil eine weitere Sicht referenziert, muss diese Sicht ebenfalls änderbar sein! Der WHERE-Teil darf keine geschachtelte Referenz auf dieselbe Tabelle enthalten, die im FROM-Teil referenziert wird! Keine GROUP BY- oder HAVING-Klausel erlaubt! 2002 Prof. Dr. Rainer Manthey Informationssysteme 32

17 Integritätsbedingungen für Sichten Obwohl Sichten vom SQL-Standard ebenfalls als Tabellen angesehen werden (abgeleitete Tabellen statt Basistabellen), sind sie in SQL (bisher) nur "Bürger zweiter Klasse", denn man kann ihnen keine Integritätsbedingungen zuordnen, auch wenn dies eigentlich sinnvoll wäre. Folgende Definition wäre z.b. sinnvoll, ist aber nicht zulässig: CREATE VIEW C4-profs AS ( ( SELECT Name, Abteilung FROM professoren WHERE Grad = C4 ), PRIMARY KEY Name, CHECK Abteilung IN ('I'; 'II'; 'III'; 'IV'; 'V'; 'VI') ); Wahrscheinlich wäre die CHECK-Constraint für die Abteilungsnummern bereits auf der Basistabelle 'professoren' vereinbart und würde dadurch auch bei Sichtenänderungen indirekt mit überprüft. Aber die Primärschlüsselbedingung könnte man u.u. nicht herleiten Prof. Dr. Rainer Manthey Informationssysteme 33 Integritätsbedingungen für Sichten (2) Sichten dürfen auch nicht in FOREIGN KEY-Constraints von Tabellen referenziert werden (weil Sichten keine Schlüssel haben dürfen)! aber: Sichten dürfen sowohl in Assertions als auch in CHECK-Constraints innerhalb einer CREATE TABLE-Anweisung referenziert werden! Die meisten SQL-Bücher schweigen sich über diese Möglichkeit aus oder "kennen" sie gar nicht - in den kommerziellen Systemen ist sie sowieso gar nicht erst implementiert worden, da Assertions und Referenzen in CHECK- Constraints generell fehlen. Damit ergibt sich die "seltsame" Situation, dass eine Fremdschlüsselbeziehung zu einer Sicht zwar nicht "direkt" über FOREIGN KEY, aber "indirekt" über eine an sich bedeutungsäquivalente CHECK-Constraint ausdrückbar ist: nicht zulässig: zulässig: REFERENCES C4-profs (Name) CHECK IN (SELECT Name FROM C4-profs) 2002 Prof. Dr. Rainer Manthey Informationssysteme 34

18 Sichtdefinitionen als Integritätsbedingungen? bei genauerer Betrachtung: Eine Sichtdefinition sollte eigentlich selbst wie eine Integritätsbedingung wirken! CREATE VIEW ordinarien AS ( SELECT Name, Grad FROM professoren WHERE Grad > C3 ) kritisch INSERT INTO ordinarien VALUES ( Manthey, C3 ) Beispielzustand von professoren : ordinarien Karpinski C4 V Martini C4 IV Cremers C4 III Blum C3 V Buhmann C3 III Manthey C3 NULL INSERT INTO professoren VALUES ( Manthey, C3, NULL) vernünftig (aber trotzdem problematisch): Gewünschte Zeile sollte eigentlich nicht in neuen Zustand der Sicht erscheinen! 2002 Prof. Dr. Rainer Manthey Informationssysteme 35 CHECK-Option für Sichten für solche Fälle: Möglichkeit, Sichtdefinition quasi als Integritätsbedingung zu vereinbaren CHECK OPTION Wird CHECK OPTION bei einer Sichtdefinition mit vereinbart, dann werden alle Sichtenänderungen zurückgewiesen, die die Sichtdefinition verletzen : CREATE VIEW ordinarien AS ( SELECT Name, Grad FROM professoren WHERE Grad > C3 ) WITH CHECK OPTION bei Sichten, die auf anderen Sichten aufbauen: Wahl zwischen LOCAL und CASCADED als Variante der CHECK OPTION (Default: CASCADED) LOCAL: Überprüfung nur auf der nächsten Ebene CASCADED: Überprüfungen bei allen zugrundeliegenden Sichten Folge: sehr komplexe, oft nicht intuitiv nachvollziehbare Automatismen (Empfehlung von Date: immer CHECK OPTION mit CASCADED ) 2002 Prof. Dr. Rainer Manthey Informationssysteme 36