Füge den Schauspieler Garfield mit der PNR 4711 ein.

Transkript

1 Übersicht Grundlagen Mengenorientierte Anfragen (Retrieval) Möglichkeiten der Datenmanipulation Möglichkeiten der Datendefinition Beziehungen und referentielle Integrität Schemaevolution Indexierung Sichten 51

2 Einfügen von Tupeln INSERT INTO table [ (column-commalist) commalist) ] { VALUES row-constr.-commalist table-exp DEFAULT VALUES } Beispiel: Füge den Schauspieler Garfield mit der PNR 4711 ein. INSERT INTO SP (PNR, NAME, W-ORT) VALUES (4711, Garfield, DEFAULT); Anmerkungen (zum satzweisen Einfügen) 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. 52

3 Einfügen von Tupeln Beispiel: Füge die Schauspieler aus KL in die Relation TEMP ein. INSERT INTO TEMP (SELECT * FROM SP WHERE W-ORT= KL ); Anmerkungen (zum mengenorientierten Einfügen) Im Beispiel sei eine (leere) Relation TEMP vorhanden. Die Datentypen der Attribute in TEMP 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. 53

4 Löschen von Tupeln searched-delete ::= DELETE FROM table [WHERE cond-exp] Aufbau der WHERE-Klausel entspricht dem der SELECT-Anweisung Beispiele: Lösche den Schauspieler mit der PNR DELETE FROM SCHAUSPIELER WHERE PNR = 4711; Lösche alle Schauspieler, die nie gespielt haben. DELETE FROM SCHAUSPIELER S WHERE NOT EXISTS (SELECT * FROM DARSTELLER D WHERE D.PNR = S.PNR); 54

5 Ändern von Tupeln searched-update ::= UPDATE table SET update-assignment-commalist assignment [WHERE cond-exp] Beispiel: 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 ); Einschränkung: Innerhalb der WHERE-Klausel in einer Lösch- oder Änderungsanweisung darf die Zielrelation elation in einer FROM-Klausel nicht referenziert en werden. 55

6 Übersicht Grundlagen Mengenorientierte Anfragen (Retrieval) Möglichkeiten der Datenmanipulation Möglichkeiten der Datendefinition Beziehungen und referentielle Integrität Schemaevolution Indexierung Sichten 56

7 Datendefinition Ziel der SQL-Normierung möglichst große Unabhängigkeit it der DB-Anwendungen von speziellen DBS einheitliche Sprachschnittstelle genügt nicht! Beschreibung der gespeicherten Daten und ihrer Eigenschaften nach einheitlichen und verbindlichen Richtlinien ist genauso wichtig Zweischichtiges Definitionsmodell für die Beschreibung der Daten Informationsschema - einheitliche Sichten auf das Definitionsschema - für den Benutzer zugänglich Definitionsschema - beschreibt hypothetische Katalogstruktur - erlaubt "Altsystemen" mit abweichenden Implementierungen normkonform zu werden 57

8 Definitionsschema Refs PK / unique REFERENTIAL_ CONSTRAINTS Is FK FK PK / unique XOR check ASSERTIONS OR owner Default char set SCHEMATA TABLE_ CONSTRAINTS CHECK_ CONSTRAINTS DOMAIN_ CONSTRAINTS DOMAINS KEY_ COLUMN _ CHECK_ TABLE_ CHECK_ COLUMN_ DATA_TYPE USAGE USAGE USAGE DESCRIPTOR Char set TABLES >0 OR COLUMNS COLLATIONS 58

9 Definitionsschema TABLES >0 COLUMNS COLLATIONS Default collation VIEW_TABLE_ USAGE VIEW VIEW_COLUMN_ USAGE CHARACTER_ USAGE target source TABLE_ PRIVILEGES COLUMN_ PRIVILEGES USAGE_ PRIVILEGES OR TRANSLATIONS grantor grantor grantor grantee grantee grantee USERS SQL_ LANGUAGES 59

10 Definition von Schemata CREATE SCHEMA [schema] [AUTHORIZATION user] [DEFAULT CHARACTER SET char-set] [schema-element-list] Jedes Schema ist einem Benutzer (user) zugeordnet, z.b. DBA Schema erhält Benutzernamen, falls keine explizite Namensangabe erfolgt Definition aller Definitionsbereiche, Basisrelationen, Sichten (Views), Integritätsbedingungen und Zugriffsrechte Beispiel: CREATE SCHEMA Beispiel-DB AUTHORIZATION DB-Admin 60

11 Datentypen CHARACTER [( length )] (Abkürzung: CHAR) CHARACTER VARYING [ ( length ) ] (Abkürzung: VARCHAR)... NUMERIC [ ( precision [, scale] ) ] DECIMAL [ ( precision [, scale ] ) ] (Abkürzung: DEC) INTEGER (Abkürzung: INT) REAL... DATE TIME... 61

12 Definition von Domains CREATE DOMAIN domain [AS] data type [DEFAULT { literal l niladic-function-ref n NULL} ] [ [CONSTRAINT constraint] CHECK (cond-exp) [deferrability]] Spezifikationsmöglichkeiten Optionale Angabe von Default-Werten Wertebereichseingrenzung durch benannte CHECK-Bedingung möglich CHECK-Bedingungen können Relationen der DB referenzieren; SQL-Domänen sind also dynamisch! Beispiele: CREATE DOMAIN ABTNR AS CHAR (6) CREATE DOMAIN ALTER AS INT DEFAULT NULL CONSTRAINT ALTERSBEGRENZUNG CHECK (VALUE = NULL OR (VALUE > 18 AND VALUE < 70)) 62

13 Definition von Attributen column-def ::= column { data-type domain } [ DEFAULT { literal niladic-function-ref NULL} ] [ column-constraint-def-list ] Spezifikation von Attributname Datentyp bzw. Domain Defaultwert Constraints Beispiele: PNAME CHAR (30) PALTER ALTER (siehe Definition von Domain ALTER) 63

14 Definition von Attributen Constraints column-constraint-def on ::= [CONSTRAINT constraint] { NOT NULL { PRIMARY KEY UNIQUE } references-def CHECK (cond-exp) } [deferrability] Als Constraints können definiert werden Verbot von Nullwerten (NOT NULL) Eindeutigkeit (UNIQUE bzw. PRIMARY KEY) FOREIGN-KEY-Klausel CHECK-Bedingungen Vorteile der Vergabe von Constraint-Namen Diagnosehilfe bei Fehlern gezieltes Ansprechen bei SET oder DROP des Constraints Beispiel: Verkaufs_Preis DECIMAL (9, 2), CONSTRAINT Ausverkauf CHECK ( Verkaufs_Preis <= (SELECT MIN (Preis) FROM Konkurrenz_Preise)) 64

15 Definition von Attributen FOREIGN-KEY-Klausel references-def ::= REFERENCES base-table [ (column-commalist)] [ON DELETE referential-action] [ON UPDATE referential-action] referential-action ::= NO ACTION CASCADE RESTRICT SET DEFAULT SET NULL Bezieht sich der Fremdschlüssel auf den PRIMARY KEY der base-table, so kann die column-commalist l entfallen Fremdschlüssel kann auch auf Schlüsselkandidat definiert sein Referentielle Aktionen werden später behandelt 65

16 Definition von Attributen Überprüfungszeitpunkt deferrability ::= [ NOT ] DEFERRABLE [ INITIALLY { DEFERRED IMMEDIATE } ] Jeder Constraint t bzgl. einer SQL2-Transaktion ist zu jedem Zeitpunkt in einem von zwei Modi: IMMEDIATE oder DEFERRED IMMEDIATE: Constraint wird am Ende einer SQL-Anweisung überprüft DEFERRED: Constraint wird erst am Ende der Transaktion überprüft Der Default-Modus für Constraints ist NOT DEFERRABLE Der Default für Constraints, die als DEFERRABLE angegeben sind, ist IMMEDIATE Anweisung SET CONSTRAINTS erlaubt den Wechsel des Modus 66

17 Erzeugen von Basisrelationen CREATE TABLE base-table (base-table-element-commalist) base-table-element ::= column-def base-table-constraint-def base-table-constraint-def bl t t ::= [CONSTRAINT constraint] t] { { PRIMARY KEY UNIQUE } (column-commalist) FOREIGN KEY (column-commalist) references-def CHECK (cond-exp) } [deferrability] Definition iti aller zugehörigen Attribute t mit Typfestlegung Spezifikation aller Integritätsbedingungen (Constraints) 67

18 Erzeugen von Basisrelationen Beispiel: Definition der Relationen ABT und PERS CREATE TABLE ABT (ANR ABTNR NOT NULL, ANAME CHAR (30) NOT NULL, ANZAHL-ANGEST INT NOT NULL, PRIMARY KEY (ANR)) 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 ) 68

19 Übersicht Grundlagen Mengenorientierte Anfragen (Retrieval) Möglichkeiten der Datenmanipulation Möglichkeiten der Datendefinition Beziehungen und referentielle Integrität Schemaevolution Indexierung Sichten 69

20 (1:n) - Beziehungen Beispiel (ERM): ABT [0,n] ist_ beschäftigt_ [0,1] in PERS Abbildung: ABT ( ABTNR..., PERS ( PNR...,... ANR..., PRIMARY KEY (ABTNR)) PRIMARY KEY (PNR), Referenzgraph: FOREIGN KEY (ANR) REFERENCES ABT) ABT referenzierte ANR Relation PERS referenzierende 70

21 (1:n) - Beziehungen Bemerkung: Für jede FS-Beziehung benötigt man einen separaten FS. Mehrere FS können auf denselben PS/SK verweisen. Mögliche zusätzliche Einschränkungen: Jeder Angestellte muss in einer Abteilung beschäftigt sein (PERS: [1,1]): PERS.ANR... NOT NULL Jede Abteilung darf höchstens einen Angestellten beschäftigen (ABT: [0,1]): PERS.ANR... UNIQUE Bemerkung: In SQL2 kann (im Rahmen der Erzeugung von Relationen) nicht spezifiziert i werden, dass - eine Abteilung einen Mitarbeiter haben muss (z. B. ABT:[1,n]) - die Anzahl der Mitarbeiter pro Abteilung einschränkt sein soll (außer [0,1]) Bei der Erstellung müssen solche Beziehungen verzögert überprüft werden. 71

22 (1:n) - Beziehungen Beispiel (ERM): hat_ [0,n] Büro_ von [1,1] ABT PERS [0,n] arbeitet_ für [0,1] Abbildung: 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 ANRA PERS 72

23 (1:1)-Beziehungen Beispiel (ERM): hat_ [0,1] Mgr [0,1] ABT MGR [0,1] leitet_ Abt Abbildung (1.Ansatz): ABT ( ANR..., MGR ( MNR..., MNR... UNIQUE, ANR... UNIQUE, PRIMARY KEY (ANR), PRIMARY KEY (MNR), FOREIGN KEY (MNR) FOREIGN KEY (ANR) REFERENCES MGR) REFERENCES ABT) [0,1] Referenzgraph: ABT MNR ANR MGR 73

24 (1:1)-Beziehungen Alternative Lösungen möglich! Mögliche zusätzliche Regeln zu obigem Beispiel: Jede Abteilung hat einen Manager ABT.MNR... UNIQUE NOT NULL Jeder Manager leitet eine Abteilung MGR.ANR... UNIQUE NOT NULL Frage: Kann durch die beiden Beziehungen eine symmetrische (1:1)-Beziehung ausgedrückt werden? 74

25 Beispiel Diskussion der verschiedenen Ansätze am Beispiel ABT MGR a 1 1 a 2 2 a 3 3 a Ansatz: ABT (ANR, MNR,...) PERS (MNR, ANR,...) a1 1 1 a2 a2 2 2 a3 a3 3 3 a1 a

26 Symmetrische (1:1)-Beziehung Beispiel (ERM): ABT [1,1] 1] leitet t [1,1] 1] MGR Abbildung (2. Ansatz): 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) Referenzgraph: Nutzung des MNR-Attributes für beide FS-Beziehungen gewährleistet Einhaltung der (1:1)-Beziehung Fall ([0,1], [0,1]) so nicht darstellbar ABT MNR MNR MGR 76

27 Beispiel Diskussion der verschiedenen Ansätze am Beispiel ABT MGR a 1 1 a 2 2 a 3 3 a Ansatz: ABT (ANR, MNR,...) PERS (MNR,...) a1 a2 1 2 a ?? 77

28 Symmetrische (1:1)-Beziehung Variation über Schlüsselkandidaten Abbildung (3. Ansatz): 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,1]) 1]) Alle Kombinationen mit [0,1] und [1,1] sind möglich Es sind alternative Lösungen möglich 78

29 Beispiel Diskussion der verschiedenen Ansätze am Beispiel ABT MGR a 1 1 a 2 2 a 3 3 a Ansatz: ABT (ANR, MNR,...) PERS (SVNR, MNR,...) a1 1 x 1 a2 a3 2 3 y z 2 3 a4 - w - 79

30 Beispiel (ERM): Abbildung: (n:m)-beziehungen PERS [0,n] bearbeitet [0,m] PROJ 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) Diese Standardlösung erzwingt eine Existenzabhängigkeit von MITARBEIT; soll dies vermieden werden, dürfen die Fremdschlüssel von MITARBEIT nicht als Teil des Primärschlüssels spezifiziert werden. Ist die Realisierung von [1,n] oder [1,m] bei der Abbildung der (n:m)-beziehung ng möglich? PERS PROJ Referenzgraph: PNR JNR MITARBEIT 80

31 Reflexive (1:n)-Beziehung Beispiel (ERM): [0,n] Abbildung: PERS [0,1] hat_ Mgr PERS (PNR..., MNR...,... Referenzgraph: PRIMARY KEY (PNR), FOREIGN KEY (MNR) REFERENCES PERS (PNR)) PERS MNR 81

32 Reflexive (1:n)-Beziehung Mit Hilfe der gezeigten Lösung kann die Personal-Hierarchie eines Unternehmens nehmen dargestellt werden eden Die referentielle Beziehung stellt hier eine partielle Funktion dar, da die obersten Manager einer Hierarchie keinen Manager haben 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 Welche Beziehungsstruktur erzeugt MNR... UNIQUE NOT NULL? 82

33 Zusammenfassung Beziehungen Relationenmodell hat wertbasierte Beziehungen 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 Objektorientierte Datenmodelle haben referenzbasierte Beziehungen! Spezifikationsmöglichkeiten in SQL: PS PRIMARY KEY (implizit: UNIQUE NOT NULL) SK UNIQUE [NOT NULL] FS [UNIQUE] [NOT NULL] 83

34 Zusammenfassung Beziehungen Fremdschlüsseldeklaration in S V S [0,n] [0,1] FS... [0,n] [1,1] FS... NOT NULL [0,1] [0,1] FS... UNIQUE [0,1] [1,1] FS... UNIQUE NOT NULL 84

35 Miniwelt (ER-Diagramm) Beispiel Datendefinition Fachbereich 0N 0,N ist-dekan- von 0,1 1,1 0,N gehört-zu 1,1 ist- eingeschr.- in 1,1 Prof Prüfung 0,N 0,M Student 85

36 Illustration des DB-Schemas Beispiel Datendefinition FB FBNR FBNAME DEKAN STUDENT MATNR SNAME FBNR STUDBEG PROF PNR PNAME FBNR FACHGEBIET PRUEFUNG PNR MATNR FACH PDATUM NOTE 86

37 Beispiel Datendefinition 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 87

38 Beispiel Datendefinition 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) 88

39 Beispiel Datendefinition Relationen: 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 darauf 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. 89

40 Beispiel Datendefinition Relationen: 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) 90

41 Relationen: CREATE TABLE PRUEFUNG ( Beispiel Datendefinition 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) 91

42 Beispiel Datendefinition Ausprägungen PROF PNR PNAME FBNR FACHGEBIET 1234 HÄRDER FB 5 DATENBANKSYSTEME 5678 WEDEKIND FB 9 INFORMATIONSSYSTEME 4711 MÜLLER FB 9 OPERATIONS RESEARCH 6780 NEHMER FB 5 BETRIEBSSYSTEME 2223 RICHTER FB 5 EXPERTENSYSTEME STUDENT MATNR SNAME FBNR STUDBEG PRÜFUNG PNR MATNR FACH PDATUM NOTE BWL OR DV DV SP DV BS COY FB MÜLLER FB ABEL FB SCHULZE FB MAIER FB SCHMID FB FB FBNR FBNAME DEKAN FB 9 WIRTSCHAFTSWISS 4711 FB 5 INFORMATIK

43 Wartung von Beziehungen Relationale Invarianten: Primärschlüsselbedingung: - Eindeutigkeit, keine Nullwerte! Fremdschlüsselbedingung: - Zugehöriger PS (SK) muss existieren Potentielle Gefährdung der Fremdschlüsselbedingung/referentiellen Integrität Operationen in der Sohn-Relation Operationen in der Vater-Relation 93

44 Potentielle Gefährung der ref. Integrität Operationen in der Sohn-Relation: Einfügen eines Sohn-Tupels FS Sohn-Relation Ändern des FS in einem Sohn-Tupel 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 PS/SK Vater-Relation Operationen in der Vater-Relation: Einfügen eines Vater-Tupels Ändern des PS/SK in einem Vater-Tupel Löschen eines Vater-Tupels Welche Reaktion ist wann möglich? 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 Referential Actions 94

45 Referentielle Aktionen SQL2-Standard führt referential actions ein Spezifikation i der referentiellen Aktionen: Legt für einen Fremdschlüssel (FS) in der Sohn-Relation fest, welche Auswirkungen Operationen in der Vater-Relation haben: Löschregel (Löschen in der Vater-Relation) ON DELETE {CASCADE RESTRICT SET NULL SET DEFAULT NO ACTION} Änderungsregel (Ändern des PS oder SK in der Vaterrelation) ON UPDATE {CASCADE RESTRICT SET NULL SET DEFAULT NO ACTION} Die Option NO ACTION wird hier explizit aufgeführt; sie entspricht dem Fall, dass die gesamte Klausel weggelassen wird. 95

46 Referentielle Aktionen RESTRICT (DR, UR): Operation wird nur ausgeführt, wenn keine zugehörigen Sätze (FS-Werte) vorhanden sind CASCADE (DC, UC): Operation kaskadiert zu allen zugehörigen Sätzen SET NULL (DSN, USN): FS wird in zugehörigen Sätzen zu Null gesetzt SET DEFAULT (DSD, USD): FS wird in den zugehörigen Sätzen auf einen benutzer-definierten Default- Wert gesetzt NO ACTION (DNA, UNA): 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 96

47 Auswirkungen referentieller Aktionen 1. Isolierte Betrachtung von STUDENT-FB STUDENT STUDENT FBNR FB MATNR SNAME FBNR COY FB MÜLLER FB ABEL FB 5 Operationen - Lösche FB (mit FBNR FB5 ) - Ändere FB (FBNR= FB9 FBNR= FB10 ) Referentielle Aktionen SCHULZE FB MAIER FB SCHMID FB 9 - DC, DSN, DSD, DR, DNA FB - UC, USN, USD, UR, UNA FBNR FBNAME FB 9 WIRTSCHAFTSWISS FB 5 INFORMATIK 97

48 Auswirkungen referentieller Aktionen 2. Isolierte Betrachtung von STUDENT-PRUEFUNG-PROF PROF PNR PRUEFUNG STUDENT MATNR PROF PNR PNAME FBNR 1234 HÄRDER FB MÜLLER FB 9 PRUEFUNG Einsatz von - USN, DSN Schlüsselverletzung - USD, DSD ggf. Mehrdeutigkeit PNR MATNR FACH OR DV DV - UNA, DNA Wirkung identisch mit UR, DR OR STUDENT MATNR SNAME FBNR COY FB ABEL FB 5 98

49 Auswirkungen referentieller Aktionen 3. Vollständiges Beispiel Variante 1 FB DC PROF DC FBNR PNR DC FBNR STUDENT MATNR DC Unabhängigkeit von Beziehungen hinsichtlich referentieller Aktionen? PRUEFUNG Operation: Lösche FB (mit 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 Eindeutigkeit: Ergebnis der Operation ist reihenfolge-unabhängig sicheres Schema! 99

50 Auswirkungen referentieller Aktionen 3. Vollständiges Beispiel Variante 2 FB DC FBNR FBNR DC PROF STUDENT DC PNR MATNR DR PRUEFUNG Operation: Lösche FB (mit 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 eine -Zugriff auf PRUEFUNG Prüfung abgelegt g hatte Wenn ein Student bei einem FB-fremden Rücksetzen Professor geprüft wurde sonst: Rücksetzen - Löschen in PROF - Löschen in PRUEFUNG Es können reihenfolgenabhängige i Ergebnisse auftreten! t Die Reihenfolgenabhängigkeit ist hier wertabhängig 100

51 Auswirkungen referentieller Aktionen 3. Vollständiges Beispiel Variante 2 Operation: Lösche FB (mit FBNR FB9 ) erst links : 1. Löschen in FB 2. Löschen in PROF 3. Löschen in PRUEFUNG 4. Löschen in STUDENT 5. Zugriff auf PRUEFUNG Wenn ein Student bei einem FB-fremden Professor geprüft wurde Rücksetzen PROF PNR PNAME FBNR 1234 HÄRDER FB WEDEKIND FB MÜLLER FB NEHMER FB 5 FB FBNR FB 9 FB RICHTER FB 5 PNR FBNAME WIRTSCHAFTSWISS INFORMATIK PRUEFUNG MATNR STUDENT MATNR SNAME FBNR COY FB MÜLLER FB ABEL FB SCHULZE FB MAIER FB SCHMID FB

52 Auswirkungen referentieller Aktionen 3. Vollständiges Beispiel Variante 2 Operation: Lösche FB (mit FBNR FB9 ) erst rechts : 1. Löschen in FB 2. Löschen in STUDENT 3. Zugriff auf PRUEFUNG Wenn ein gerade gelöschter Student eine Prüfung abgelegt hatte Rücksetzen 4. Löschen in PROF 5. Löschen in PRUEFUNG PROF PNR PNAME FBNR 1234 HÄRDER FB WEDEKIND FB MÜLLER FB NEHMER FB RICHTER FB 5 FB FBNR FB 9 FB 5 PNR FBNAME WIRTSCHAFTSWISS INFORMATIK PRUEFUNG MATNR STUDENT MATNR SNAME FBNR COY FB MÜLLER FB ABEL FB SCHULZE FB MAIER FB SCHMID FB

53 Auswirkungen referentieller Aktionen 3. Vollständiges Beispiel Variante 3 FB DC FBNR FBNR DC PROF STUDENT DC PNR MATNR DNA PRUEFUNG Operation: Lösche FB (mit FBNR FB9 ) 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 Referenzen in Test, ob es noch offene Referenzen in PRUEFUNG auf gelöschte Studenten gibt; PRUEFUNG 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 103

54 Verhinderung von Mehrdeutigkeiten Maßnahmen: Statische Schemaanalyse zur Feststellung sicherer DB-Schemata nur bei einfach strukturierten Schemata effektiv hohe Komplexität der Analysealgorithmen bei wertabhängigen Konflikten zu restriktiv (konfliktträchtige Schemata) Dynamische Überwachung der Modifikationsoperationen hoher Laufzeitaufwand Vorgehensweisen: 1. Falls Sicherheit eines Schemas festgestellt werden kann, ist keine Laufzeitüberwachung erforderlich 2. Alternative Möglichkeiten zur Behandlung konfliktträchtiger Schemata, nachdem die statische Schemaanalyse die Sicherheit des Schemas nicht feststellen konnte - sie werden verboten, oder - sie werden erlaubt und hoher Laufzeitaufwand die referentiellen Aktionen werden bei jeder Operation dynamisch überwacht falls ein Konflikt erkannt wird, wird die Operation zurückgesetzt 104

55 Durchführung der Änderungsoperationen Prüfung der referentiellen Integrität (IMMEDIATE/DEFERRED) BEGIN OP 1 OP 2 OP 3 COMMIT Zyklische Referenzpfade FS1 ABT MGR FS2 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) 105

56 Durchführung der Änderungsoperationen Verarbeitungsmodell Benutzeroperationen (Op) sind in SQL immer atomar mengenorientiertes oder tupelorientiertes Verarbeitungsmodell Op Op t 1 t 2... t n RA s t 1 RA t 2 RA... t n RA IMMEDIATE-Bedingungen müssen an Anweisungsgrenzen erfüllt sein ( mengenorientierte Änderung) 106

57 Übersicht Grundlagen Mengenorientierte Anfragen (Retrieval) Möglichkeiten der Datenmanipulation Möglichkeiten der Datendefinition Beziehungen und referentielle Integrität Schemaevolution Indexierung Sichten 107

58 Schemaevolution Wachsender oder sich ihäd ändernderd Informationsbedarf Erzeugen/Löschen von Tabellen (und Sichten) Hinzufügen, Ändern und Löschen von Spalten Anlegen/Ändern von referentiellen Beziehungen Hinzufügen, Modifikation, Wegfall von Integritätsbedingungen Veränderte Anforderungen bei der DB-Nutzung Dynamisches Anlegen von Zugriffspfaden Aktualisierung der Zugriffskontrollbedingungen Hoher Grad an logischer Datenunabhängigkeit ist sehr wichtig! 108

59 Dynamische Änderung von Tabellen ALTER TABLE-Anweisung ALTER TABLE base-table {ADD [COLUMN] column-def ALTER [COLUMN] column {SET default-def DROP DEFAULT} DROP [COLUMN] column {RESTRICT CASCADE} ADD base-table-constraint-def DROP CONSTRAINT constraint {RESTRICT CASCADE}} 109

60 Beispiele: Dynamische Änderung von Tabellen Erweiterung der Tabellen Abt und Pers um neue Spalten ALTER TABLE Pers ADD Svnr INT UNIQUE ALTER TABLE Abt ADD Geh-Summe INT Verkürzung der Tabelle Pers um eine Spalte ALTER TABLE Pers DROP COLUMN Alter RESTRICT Wenn die Spalte die einzige der Tabelle ist, wird die Operation zurückgewiesen. Da RESTRICT spezifiziert ist, wird die Operation zurückgewiesen, wenn die Spalte in einer Sicht oder einer Integritätsbedingung (CHECK) referenziert wird. CASCADE dagegen erzwingt die Folgelöschung aller Sichten und CHECK, die von der Spalte abhängen. 110

61 Löschen von Schemaelementen DROP-Anweisung DROP { TABLE base-table VIEW view DOMAIN domain SCHEMA schema } { RESTRICT CASCADE } Falls Objekte (Tabellen, Sichten,...) nicht mehr benötigt werden, können sie durch die DROP-Anweisung aus dem System entfernt werden. Mit der CASCADE-Option können abhängige Objekte (z.b. Sichten auf Tabellen oder anderen Sichten) mitentfernt werden RESTRICT verhindert Löschen, wenn die zu löschende Tabelle noch durch Sichten oder Integritätsbedingungen referenziert wird 111

62 Löschen von Schemaelementen Beipiele: Löschen von Tabelle Pers DROP TABLE Pers RESTRICT PersConstraint sei definiert auf Pers ALTER TABLE Pers DROP CONSTRAINT PersConstraint CASCADE DROP TABLE Pers RESTRICT Durchführung der Schemaevolution Aktualisierung von Tabellenzeilen des SQL-Definitionsschemas tabellengetriebene Verarbeitung der Metadaten durch das DBS 112

63 Übersicht Grundlagen Mengenorientierte Anfragen (Retrieval) Möglichkeiten der Datenmanipulation Möglichkeiten der Datendefinition Beziehungen und referentielle Integrität Schemaevolution Indexierung Sichten 113

64 Einsatz von Indexstrukturen Beschleunigung der Suche: Zugriff über Spalten (Schlüsselattribute) Kontrolle von Integritätsbedingungen (relationale Invarianten) Zeilenzugriff in der logischen Ordnung der Schlüsselwerte Gewährleistung der Clustereigenschaft für Tabellen Aber auch: erhöhter Aktualisierungsaufwand u a und Speicherplatzbedarf e p 114

65 Einrichtung von Indexstrukturen Datenunabhängigkeit des Relationenmodells erlaubt ein Hinzufügen und Löschen jederzeit möglich, um z. B. bei veränderten Benutzerprofilen das Leistungsverhalten zu optimieren beliebig viele Indexstrukturen pro Tabelle und mit unterschiedlichen Spaltenkombinationen als Schlüssel möglich Steuerung der Eindeutigkeit der Schlüsselwerte, der Clusterbildung Freiplatzanteil il (PCTFREE) in jeder Indexseite beim Anlegen erleichtert das Wachstum Spezifikation: DBA oder Benutzer DBMS auf Grundlage des Workloads 115

66 Indexierung Im SQL-Standard keine Anweisung vorgesehen, jedoch in realen Systemen (z. B. IBM DB2): CREATE [UNIQUE] INDEX index ON base-table (column [ORDER] [,column[order]]...) [CLUSTER] [PCTFREE] Nutzung eines vorhandenen Index Entscheidung durch DBS-Optimizer 116

67 Indexierung Beispiele: Erzeugung einer Indexstruktur mit Clusterbildung auf der Spalte Anr von Abt CREATE UNIQUE INDEX Persind1 ON Abt (Anr) CLUSTER Realisierung z. B. durch B*-Baum (oder Hashing, mit verminderter Funktionalität) UNIQUE: keine Schlüsselduplikate im Index CLUSTER: zeitoptimale sortiert-sequentielle Verarbeitung (Scan-Operation) Erzeugung einer Indexstruktur auf den Spalten Anr (absteigend) und Gehalt (aufsteigend) von Pers. CREATE INDEX Persind2 ON Pers (Anr DESC, Gehalt ASC) 117

68 B*-Baum Baum Typische Implementierung eines Index ES = S L /E L = max. # Einträge/Seite wird von allen DBS angeboten! h B = Baumhöhe Knotenformat N T = #Zeilenverweise im B*-Baum Z i = Zeiger auf Sohnseite bzw. Satz N B = #Blattseiten im B*-Baum S i = Schlüssel N Tmin = 2 (ES/2) h b -1 N T ES h b = N Tmax S L Realistische Größenverhältnisse: h B = 3 und E L = 20 B Z 0 S 1 Z 1 S 2 Z 2 S m Z m frei E L h B N B 118

69 B*-Baum Baum dynamische Reorganisation durch Aufteilen (Split) und Mischen von Seiten Wesentliche Funktionen direkter Schlüsselzugriff auf einen indexierten Satz sortiert sequentieller Zugriff auf alle Sätze (unterstützt Bereichsanfragen, Verbundoperation usw.) Balancierte Struktur unabhängig von Schlüsselmenge l unabhängig von Einfügereihenfolge 119

70 Indexierung Index mit Clusterbildung Index ohne Clusterbildung I Abt (Anr) I Pers (Anr) Tupel Seite Wurzelseite Zwischenseiten Blattseiten Datenseiten 120

71 Übersicht Grundlagen Mengenorientierte Anfragen (Retrieval) Möglichkeiten der Datenmanipulation Möglichkeiten der Datendefinition Beziehungen und referentielle Integrität Schemaevolution Indexierung Sichten 121

72 Sichten Ziel: Festlegung welche Daten Benutzer sehen wollen (Vereinfachung, leichtere Benutzung) welche Daten sie nicht sehen dürfen (Datenschutz) einer zusätzlichen Abbildung g( (erhöhte Datenunabhängigkeit) gg Sicht (View) mit Namen bezeichnete, aus Tabellen abgeleitete, virtuelle Tabelle (Anfrage) Anlegen von Sichten: CREATE VIEW view [ (column-commalist ) ] AS table-exp [WITH [ CASCADED LOCAL] CHECK OPTION] Korrespondenz zum externen Schema bei ANSI/SPARC; Benutzer sieht jedoch i. allg. mehrere Sichten (Views) und Tabellen 122

73 Sichten Beispiele: Sicht, die alle Programmierer mit einem Gehalt < umfasst. CREATE VIEW Arme_Programmierer (Pnr, Name, Beruf, Gehalt, Anr) AS SELECT Pnr, Name, Beruf, Gehalt, Anr FROM Pers WHERE Beruf = Programmierer AND Gehalt < Sicht für den Datenschutz CREATE VIEW Statistik (Beruf, Gehalt) AS SELECT Beruf, Gehalt FROM Pers 123

74 Sichten Sichten zur Gewährleistung von Eigenschaften: Datenunabhängigkeit Sicht kann wie eine Tabelle behandelt werden Benutzer Sichtsemantik: dynamisches Sicht 4 Fenster auf zugrundeliegende Tabellen Sichten auf Sichten sind möglich Sicht 1 Sicht 2 Sicht 3 Tabelle 1 Tabelle 2 Tabelle 3 Tabelle 4 eingeschränkte Änderungsmöglichkeiten: - aktualisierbare Sichten - nicht-aktualisierbare Sichten 124

75 Semantik: dynamisches Fenster Semantik von Sichten Sicht V als dynamisches Fenster Tabelle R ( A1, A2, A3, A4, A5 ) t1: a 11 a 12 a 13 a 14 a 15 t4: a 41 a 42 a 43 a 44 a

76 Sichtbarkeit von Änderungen Wann werden welche Datenänderungen in der Tabelle/Sicht für die anderen Benutzer sichtbar? (Beachte Beispiel auf vorangegangener Folie) Vor BOT von T1, T2 Nach EOT von T1, T2 B 1 sieht R = {t1, t4} T1 Insert t2 Select t4 R =? B 2 sieht V = {t1 } T2 Insert t3 Select t2 V =? 126

77 Sichtbarkeit von Änderungen Wann werden welche Datenänderungen in der Tabelle/Sicht für die anderen Benutzer sichtbar? Sicht V als dynamisches Fenster Tabelle R ( A1, A2, A3, A4, A5 ) t1: a 11 a 12 a 13 a 14 a 15 t2: t3: a 21 a 22 a 23 a 24 a 25 a 32 a 33 a 34 t4: a 41 a 42 a 43 a 44 a

78 Abbildung von Sicht-Operationen auf Tabellen Sichten werden i. allg. nicht explizit und permanent gespeichert, sondern Sicht-Operationen tionen werden in äquivalente Operationen auf Tabellen umgesetzt Umsetzung ist für Leseoperationen meist unproblematisch Beispiel: Anfrage (Sichtreferenz): SELECT FROM WHERE Name, Gehalt Arme_Programmierer Anr = K55 Ersetzung durch: SELECT FROM WHERE Name, Gehalt PERS Anr = K55 AND Beruf = Programmierer AND Gehalt <

79 Abbildung von Sicht-Operationen auf Tabellen Abbildungsprozess auch über mehrere Stufen durchführbar Sichtendefinitionen: CREATE VIEW V AS SELECT... FROM R WHERE P CREATE VIEW W AS SELECT... FROM V WHERE Q Anfrage: SELECT... FROM W WHERE C Ersetzung durch: SELECT... FROM V WHERE Q AND C SELECT... FROM R WHERE Q AND P AND C 129

80 Abbildung von Sicht-Operationen auf Tabellen Einschränkungen der Abbildungsmächtigkeit: keine Schachtelung von Aggregat-Funktionen und Gruppenbildung (GROUP-BY) keine Aggregat-Funktionen in WHERE-Klausel möglich Beispiel: Sichtendefinition CREATE VIEW Abtinfo (Anr, Gsumme) AS SELECT Anr, SUM (Gehalt) FROM Pers GROUP BY Anr Anfrage SELECT AVG (Gsumme) FROM Abtinfo Ersetzung durch (bei naiver Vorgehensweise) SELECT? FROM Pers GROUP BY Anr 130

81 Löschen von Sichten Beispiel: DROP VIEW Arme_Programmierer CASCADE Alle referenzierenden Sichtdefinitionen und Integritätsbedingungen werden mitgelöscht RESTRICT würde eine Löschung zurückweisen, wenn die Sicht in weiteren Sichtdefinitionen oder CHECK-Constraints referenziert werden würde. 131

82 Änderbarkeit von Sichten alle Sichten theoretisch et änderbare e Sichten in SQL änderbare Sichten Änderbarkeit in SQL nur eine Tabelle (Basisrelation oder Sicht) Schlüssel muss vorhanden sein keine Aggregatfunktionen keine Gruppierung keine Duplikateliminierung i i 132

83 Änderbarkeit von Sichten Sichten über mehrere Tabellen sind im Allg. nicht änderbar W = Π A2,A3,B1,B2 (R S) A3 = B1 Not Null? W R ( A1, A2, A3) S ( B1, B2, B3) a 11 a 21 a 31 a 31 b 21 b 31 a 12 a 22 a 31 a 32 b 22 b 32 a 13 a 23 a 32 Einfügen? Ändern? 133

84 Änderbarkeit von Sichten WITH CHECK OPTION Einfügungen und Änderungen müssen das die Sicht definierende i d Prädikat erfüllen, sonst Zurückweisung nur auf aktualisierbaren Sichtdef. S Prädikat Sichten definierbar A Spezifikationsmöglichkeiten: Weglassen der CHECK-Option WITH CASCADED CHECK OPTION oder äquivalent WITH CHECK OPTION WITH LOCAL CHECK OPTION S N S I V A V N V I CHECK- Option CASCADED S I-1 V I-1 LOCAL/CASCADED/ R 134

85 Änderbarkeit von Sichten Annahmen: Sicht S A mit dem die Sicht definierenden Prädikat V A wird aktualisiert S I ist die höchste Sicht im Abstammungspfad von S A, die die Option CASCADED besitzt Oberhalb von S I tritt keine LOCAL-Bedingung auf Aktualisierung von S A als Prüfbedingung wird von S I aus an S A vererbt : V = V I V I-1... V 1 erscheint irgendeine aktualisierte Zeile von S A nicht in S I, so wird die Operation zurückgesetzt Es ist möglich, dass Zeilen aufgrund von gültigen Einfüge- oder Änderungsoperationen aus S A verschwinden 135

86 Änderbarkeit von Sichten zusätzliche Annahmen: Aktualisierte Sicht besitzt WITH CHECK OPTION Default ist CASCADED Aktualisierung von S A : als Prüfbedingung bei Aktualisierungen i ergibt sich: V = V A V N... V I... V 1 Zeilen können jetzt aufgrund von gültigen Einfüge- oder Änderungsoperationen nicht aus S A verschwinden LOCAL hat eine undurchsichtige Semantik wird hier nicht diskutiert Empfehlung: nur Verwendung von CASCADED 136

87 Änderbarkeit von Sichten Sichtenhierarchie: S 2 mit V 1 V 2 S 1 mit V 1 und CASCADED R R R R S 1 I 2 S 1 S 1 U S 2 S 2 1 U 2 I 1 S 2 U 3 I 3 Aktualisierungsoperationen in S 2 (welche sind erlaubt?) I 1 und U 1 erfüllen das S 2 -definierende Prädikat V 1 V 2 I 2 und U 2 erfüllen das S 1 -definierende Prädikat V 1 I 3 und U 3 erfüllen das S 1 -definierende Prädikat V 1 nicht 137

88 Änderbarkeit von Sichten Beispiel: Tabelle Pers Sicht1 auf Pers: AP1, mit Beruf = Progr AND Gehalt < 30K Sicht2 auf AP1: AP2, mit Gehalt > 20K Sichtdef. CHECK-Optionen AP2 Prädikat > 20K CASC CASC AP1 < 30K CASC CASC PERS 138

89 Änderbarkeit von Sichten Beispiel: Operationen INSERT INTO AP2 (PNR, BERUF, GEHALT, ANR) VALUES ( 1234, Progr, 25K, K55 ) 2. INSERT INTO AP2 (PNR, BERUF, GEHALT, ANR) VALUES ( 4711, Progr, 15K, K55 ) 3. UPDATE AP2 SET Gehalt = Gehalt + 10K WHERE ANR = K55 AP2: > 20K - - CASC CASC AP1: < 30K - CASC - CASC 139

90 Zusammenfassung SQL SQL-Anfragen Mengenorientierte te Spezifikation, verschiedene eschiedenetpen 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 t und Relationen Spezifikation des Überprüfungszeitpunktes 140

91 Zusammenfassung SQL 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. 141

92 Zusammenfassung SQL Schemaevolution Änderung/Erweiterung von Spalten, Tabellen, Integritätsbedingungen,... Indexstrukturen als B*-Bäume mit und ohne Clusterbildung spezifizierbar Balancierte Struktur unabhängig von Schlüsselmenge und Einfügereihenfolge dynamische Reorganisation durch Aufteilen (Split) und Mischen von Seiten direkter Schlüsselzugriff auf einen indexierten Satz sortiert sequentieller Zugriff auf alle Sätze (unterstützt Bereichsanfragen, Verbundoperation usw. Sichtenkonzept Erhöhung der Benutzerfreundlichkeit Flexibler Datenschutz Erhöhte Datenunabhängigkeit Rekursive Anwendbarkeit Eingeschränkte Aktualisierungsmöglichkeiten 142

93 Ergänzende Literatur zu diesem Kapitel [MSG99] Melton, J., Simon, A.R., Gray, J.: SQL: Understanding Relational Language Components, Morgan Kaufmann Series in Data Management Systems, [Me02] Melton, J:Advanced J.: SQL: Understanding Object- Relational and Other Advanced Features, Morgan Kaufmann Series in Data Management Systems,