Grober Überblick zu Datendefinitionsanweisungen in SQL

Transkript

1 5.2 Datendefinition mit SQL (DDL) Grober Überblick zu Datendefinitionsanweisungen in SQL Konzeptuelle Ebene - CREATE TABLE, ALTER TABLE, DROP TABLE - CREATE DOMAIN, ALTER DOMAIN, DROP DOMAIN -... Interne Ebene - CREATE INDEX, ALTER INDEX, DROP INDEX - Nicht Bestandteil der aktuellen SQL-Norm (SQL:2003) Externe Ebene - CREATE VIEW, DROP VIEW - Nicht notwendig: ALTER VIEW ( = DROP + CREATE) - Erläuterungen im Abschnitt 5.3 Datenänderung/-zugriff mit SQL (DML) Seite 149

2 5.2.1 CREATE TABLE Syntax (in einfachster Form): CREATE TABLE Basisrelationenname ( Spaltenname_1 Wertebereich_1, [NOT NULL]... Spaltenname_k Wertebereich_k [NOT NULL]) Beispiel (siehe Folie 128): - Definition für Primärschlüssel und Fremdschlüssel fehlen - Testausführung in MS Access - Anweisungen: CREATE TABLE Buch ( InvNr INTEGER NOT NULL, Titel VARCHAR(30), ISBN CHAR(5), Autor VARCHAR(40)) CREATE TABLE Ausleihe ( InvNr INTEGER NOT NULL, Name VARCHAR(20)) Seite 150

3 5.2.1 CREATE TABLE Bedeutung der Anweisung: - Erzeugen einer k-spaltigen Tabelle (Relation mit k Attributen) mit über Spaltenname_i/Wertebereich_i definiertem Relationenschema - Tabelle ist nach dem CREATE zunächst leer, d.h. enthält keine Tupel - NOT NULL Klausel verbietet das Auftreten von Nullwerten (NULL) in den spezifizierten Spalten, ohne Angabe sind Nullwerte erlaubt - Schemainformation wird im Datenbankkatalog abgelegt (teils auch als Data Dictionary bezeichnet) Datenbankkatalog besteht ebenfalls aus Tabellen; Verzeichnis aller erzeugten Tabellen, Attribute, benutzerdefinierten Wertebereiche etc. Katalogtabellen können mit SQL vom Benutzer gelesen werden wie "normale" benutzereigene Tabellen Datenbankkataloge sind prinzipiell normiert Wesentlicher Vorteil von relationalen n im Vergleich zu vorrelationalen DBMS mit "kryptischer" interner Ablage der Kataloginformationen! Seite 151

4 5.2.1 CREATE TABLE Wertebereiche / Datentypen - Numerische Typen: INTEGER, SMALLINT, BIGINT FLOAT(precision), REAL, DECIMAL(precision [, scale]) - Zeichenkettentypen: CHARACTER(n), CHAR(n), VARCHAR(n) - Logische Datentypen: BIT(n), BOOLEAN - Datentypen für Zeit/Datum: DATE, TIME[(precision)], TIMESTAMP[(precision)] - Datentypen für große Objekte CHARACTER LARGE OBJECT[(length)], CLOB[(length)] Datentypen für konkrete relationale n (Produkte) - Grundlage ist immer die Produktliteratur - Oft existieren zusätzliche Datentypen (nicht in der SQL-Norm) Seite 152

5 5.2.1 CREATE TABLE Bemerkungen zu Schlüsseln - SQL-Norm erzwingt keine Primärschlüssel-Definition! - Tabellen dürfen also Duplikate aufweisen Mehrfache Tupel, die in allen ihren Attributwerten übereinstimmen Multimengeneigenschaft ("bags" statt "sets") - Duplikatfreiheit muss bei Bedarf explizit festgelegt werden PRIMARY KEY Klausel als eine Möglichkeit (implizit NOT NULL) Überwachung durch das DBMS Abweichen von der "reinen (relationalen) Lehre"! Beispiel (Erweiterung von Folie 149): CREATE TABLE Buch ( InvNr INTEGER NOT NULL, Titel VARCHAR(30), ISBN CHAR(5), Autor VARCHAR(40), PRIMARY KEY (InvNr)) CREATE TABLE Ausleihe ( InvNr INTEGER NOT NULL, Name VARCHAR(20), PRIMARY KEY (InvNr), FOREIGN KEY (InvNr) REFERENCES Buch(InvNr)) Seite 153

6 5.2.1 CREATE TABLE Zusätzliche Anweisungen für CREATE TABLE mit Fokus auf der Integritätssicherung, war großes Thema der letzten Jahre (ab SQL-92) - Primär-/Fremdschlüsseldefinition ist im relationalen Fall modellinhärent, "ohne" sollte eigentlich nicht zulässig sein - Falls der Primärschlüssel nur aus einem Attribut besteht, kann die PRIMARY KEY Klausel "in-line" angegeben werden DEFAULT-Klausel zur expliziten, benutzerseitigen Festlegung eines Default- Werts für eine Tabellenspalte -Bsp: CREATE TABLE Buch ( InvNr INTEGER PRIMARY KEY, Titel VARCHAR(30), ISBN CHAR(5), Autor VARCHAR(40) DEFAULT 'Küspert') - Beim Einfügen eines Datensatzes ohne Autor-Angabe wird vom DBVS der Werte 'Küspert' eingetragen Seite 154

7 5.2.1 CREATE TABLE CHECK-Klausel zur Spezifikation von Integritätsbedingungen (nicht nur) für einzelne Attributwerte - Ermöglicht die Angabe von Prädikaten, welche den zulässigen Wertebereich für Tabellenspalten weiter einschränken - Prüfung erfolgt durch das DBVS Bei Tupeleinfügung (INSERT) und Wertänderung (UPDATE) Im Fall einer drohenden Konsistenzverletzung wird die verursachende Anweisung nicht ausgeführt, also zurückgewiesen - CHECK-Klausel ist auch an einer Tabelle gesamt definierbar -Bsp: CREATE TABLE Buch ( InvNr INTEGER PRIMARY KEY CHECK (InvNr BETWEEN 5 AND 9999), Titel VARCHAR(30), ISBN CHAR(5), Autor VARCHAR(40) DEFAULT 'Küspert' CHECK (Autor <> 'Kujau')) Seite 155

8 5.2.2 ALTER TABLE Syntax: ALTER TABLE Basisrelationenname <alter_action> Bedeutung der Anweisung: - Änderung eines mit CREATE TABLE angelegten Relationsschemata (Schemaevolution) - Möglichkeiten der Änderung über <alter_action> Hinzufügen neuer Attribute (Spalten) zu einer Tabelle, seit SQL-89 normiert (seit SQL-92 mit DEFAULT- und CHECK-Klausel) Löschen von Tabellenspalten, erst seit SQL-92 normiert Ändern von Eigenschaften vorhandener Attribute (sehr eingeschänkt!) Hinzufügen von Integritätsbedingungen an einer Tabelle Löschen von Integritätsbedingungen einer Tabelle Seite 156

9 5.2.2 ALTER TABLE Hinzufügen von Tabellenspalten - Neue Spalte wird bei allen in der Tabelle aktuell vorhandenen Tupeln mit NULL belegt (zumindest "logisch") - Neue Spalte (Name, Wertebereich, Tabellenzuordnung) wird im Katalog eingetragen -Bsp: Tabelle "Buch" erhält neue Spalte "Einkaufspreis" Testausführung in MS Access Syntax: Löschen von Tabellenspalten - Umkehrung der Wirkung gegenüber Hinzufügen - Zusätzlich Angabe CASCADE bzw. RESTRICT möglich, Erklärung später -Bsp: Löschen der Spalte "Einkaufspreis" in Tabelle "Buch" Syntax: ALTER TABLE Buch ADD Seitenzahl INTEGER CHECK (Seitenzahl > 0) ALTER TABLE Buch DROP Seitenzahl Seite 157

10 5.2.2 ALTER TABLE Ändern von Tabellenspalten - Ändern/Löschen einer Default-Angabe - Aktualisierung des Katalogs - Bsp 1: Default-Wert an der Spalte "ISBN" in Tabelle "Buch" setzen Syntax: ALTER TABLE Buch ALTER ISBN SET DEFAULT '0-000' - Bsp 2: Default-Wert für Spalte "ISBN" in Tabelle "Buch" löschen Syntax: ALTER TABLE Buch ALTER ISBN DROP DEFAULT Hinzufügen einer Tabellen-Integritätsbedingung - Aktuelle Daten der Tabelle müssen die Bedingung erfüllen! - Aktualisierung des Katalogs -Bsp: Spalte "Autor" und "Titel" in Tabelle "Buch" sollen eindeutig sein Syntax: ALTER TABLE Buch ADD UNIQUE(Autor, Titel) Seite 158

11 5.2.2 ALTER TABLE Bemerkungen - Wunsch nach viel mehr Möglichkeiten vorallem beim Verändern einer bestehenden Tabellenspalte Bsp: Ändern des Datentyps Keine Unterstützung durch SQL-Norm (warum wohl?!) - Relationale DBMS-Produkte unterstützen diesbezüglich meist nur kleinen Teil der SQL-92-Norm: ALTER TABLE... ADD... Schemaänderung generell heikles Thema bei DBMS - Was geschieht mit den vorhandenen Daten (Tupeln in Tabellen)? Sofortige Transformation in neues Format Verzögerte Transformation in neues Format Was, wenn Transformation scheitert / nicht automatisch durchführbar? - Auswirkungen auf vorhandene Anwendungen Programme, gespeicherte SQL-Anfragen Teilweise Abhilfe durch Sichten (Views) Seite 159

12 5.2.3 DROP TABLE Syntax: DROP TABLE Basisrelationenname <drop_behavior> Bedeutung der Anweisung: - Tabelle "Basisrelationenname" wird gelöscht (Schema und Daten!) Einträge zur Schemabeschreibung (Relationsname, Attributnamen, Wertebereichsangaben,...) werden aus dem Katalog entfernt Üblicherweise nicht zwischen normalen DB-Veränderungen in einer Transaktion erlaubt - Definition der Reaktion des DBVS über <drop_behavior>, wenn die Tabelle noch über Integritätsbedingungen/Sichten referenziert wird: CASCADE: bezugnehmende Objekte werden mit gelöscht RESTRICT: Löschung der Tabelle wird zurückgewiesen Beispiel: DROP TABLE Buch RESTRICT Seite 160

13 5.2.4 CREATE DOMAIN Syntax: CREATE DOMAIN Domainname Wertebereich Bedeutung der Anweisung: - Möglichkeit zur Vereinbarung benutzerdefinierter Wertebereiche Eigene Datentypen (Domänen) im Gegensatz zur Einschränkung des Wertebereichs von Standarddatentypen mit CHECK-Klausel Analog zu Programmiersprachen - Definition darf mit DEFAULT- und CHECK-Klausel verwendet werden Beispiel: - Neues Attribut "Gebiet" in Tabelle "Buch" mit nutzerdefinierten Typ CREATE DOMAIN Fachgebiet VARCHAR(20) DEFAULT 'Informatik' CHECK (VALUE IN ('Informatik', 'Physik', 'BWL', 'Mathematik')) CREATE TABLE Buch ( InvNr INTEGER PRIMARY KEY, Titel VARCHAR(30), Gebiet Fachgebiet, ISBN CHAR(5), Autor VARCHAR(40)) Seite 161

14 5.2.4 CREATE DOMAIN Erläuterungen zum Beispiel: - Neuer benutzerdefinierter Typ "Fachgebiet", welcher Zeichenketten der Länge 20 aufnehmen kann Standardwert ist 'Informatik' Erlaubte Werte sind 'Informatik', 'Physik', 'Mathematik' und 'BWL' Was wäre, wenn in der Liste der erlaubten Werte 'Informatik' fehlt? - Einfügen eines Buch-Tupels ohne Gebiet-Angabe scheitert, weil DBVS den Default-Wert 'Informatik' generiert, CHECK-Klausel aber nicht erfüllt ist Hinweise: - Anweisung CREATE DOMAIN sowie DEFAULT- und CHECK-Klausel sind erst ab SQL-92 normiert - Realisierung in der gezeigten Form nicht in allen Produkten vorhanden Seite 162

15 5.2.5 ALTER DOMAIN Syntax: ALTER DOMAIN Domainname <alter_action> Bedeutung der Anweisung - Verändert einen existierenden nutzerdefinierten Datentyp - Möglichkeiten der Änderung über <alter_action> SET DEFAULT: Setzen eines (neuen) Defaultwertes DROP DEFAULT: Defaultwert löschen ADD CHECK: Check-Klausel hinzufügen/überschreiben DROP CHECK: Check-Klausel löschen Beispiel: - Setzen des neuen Default-Wertes 'BWL' am Datentyp "Fachgebiet" ALTER DOMAIN Fachgebiet SET DEFAULT 'BWL' Seite 163

16 5.2.6 DROP DOMAIN Syntax: DROP DOMAIN Domainname <drop_behavior> Bedeutung der Anweisung - Löscht einen existierenden nutzerdefinierten Datentyp - Definition der Reaktion des DBVS über <drop_behavior>, wenn der Datentyp noch verwendet wird: CASCADE: Gleichzeitige Löschung der abhängigen Objekte, z.b. Tabellenspalten RESTRICT: Zurückweisen der Löschung Beispiel: - Löschen des Datentyps "Fachgebiet" - Abhängige Objekte (z.b. Tabellenspalte "Buch.Gebiet") sollen auch gelöscht werden DROP DOMAIN Fachgebiet CASCADE Seite 164

17 5.2.7 CREATE / DROP INDEX Syntax: CREATE [UNIQUE] INDEX Indexname ON Basisrelationenname ( Spaltenname_1 Ordnung_1,... Spaltenname_k Ordnung_k) Bedeutung der Anweisung - Erzeugung eines Zugriffspfads (Index), der zum schnellen Zugriff auf bestimmte Tupel bei gegebenem Attributwert dient - UNIQUE-Angabe spezifiziert, dass die Werte im Index eindeutig sein müssen (keine Duplikate) - Ordnung_i: mögliche Werte ASC (ascending) und DESC (descending) PRIMARY KEY-Definition bei CREATE TABLE erzeugt implizit einen Unique Index auf dem Primärschlüssel - Keine Forderung der (SQL-)Norm, aber Realität in Produkten - Grund: Effizienz beim Prüfen der Werteeindeutigkeit! Seite 165

18 5.2.7 CREATE / DROP INDEX Bemerkung zur Indexrealisierung - Art der Realisierung auf konzeptueller und externe Ebene nicht sichtbar - Sogar die (Nicht-)Existenz eines Index bleibt verborgen - Grund Datenunabhängigkeit: Indexe können erzeugt/gelöscht werden, ohne dass der Anwender etwas davon merkt (außer Performance)! Beispiel (siehe Folie 128): - Index-Ausprägung zum Primärschlüssel "InvNr" in Tabelle "Buch" z.b. B*-Baum Dr. No......Datenbanken......Datenbanken......Objektbanken......Pascal... Seite 166

19 5.2.7 CREATE / DROP INDEX Beispiele: - CREATE UNIQUE INDEX Titel_Index ON Buch (Titel ASC) Ergebnis: kann nicht erfolgreich durchgeführt werden, da keine Werteeindeutigkeit in Spalte "Titel" Lösung: Weglassen der UNIQUE-Angabe - CREATE INDEX Autoren_Index ON Buch (Autor ASC) Ermöglicht schnellen Zugriff auf die zu einem Autor gehörigen Bücher - CREATE INDEX Autoren_Titel_Index ON Buch (Autor ASC, Titel ASC) Index enthält Werte-Paare (Autor, Titel) Gut geeignet, wenn Anfragen häufig mit Autoren- und Titelangabe erfolgen ("Ist das Pascal-Buch von Wirth vorhanden?") - CREATE INDEX InvNr_Index ON Ausleihe (InvNr ASC) Unnötig, da "InvNr" Primärschlüssel in Tabelle "Ausleihe" ist und Index somit vorhanden (sogar UNIQUE) - DROP INDEX Autoren_Index Index mit global eindeutigem Namen "Autoren_Index" wird gelöscht Seite 167

20 5.2.7 CREATE / DROP INDEX Gedankenspiel: angenommen, "InvNr" wäre nicht als Primärschlüssel in "Ausleihe" vereinbart, warum erscheint Index auf "InvNr" trotzdem sinnvoll? - "InvNr" ist Fremdschlüssel in "Ausleihe" mit Bezug auf den Primärschlüssel (InvNr) von "Buch" - DBVS muss deshalb Integritätsüberwachung vornehmen, z.b. dass ein Buch nicht gelöscht werden darf, wenn noch ausgeliehen - Erfordert aus Effizienzgründen einen Index (welcher von realen Produkten nicht erzwungen wird!) Abschließende Bemerkungen zur Index-Thematik - Seit SQL-92 gibt es eine UNIQUE-Spezifikation, die genau so eingesetzt werden darf, wie die PRIMARY KEY-Spezifikation - Damit adäquates Mittel zur Definition von Schlüsselkandidaten Unterstützung nicht in allen Produkten Unschöne Alternative: Vereinbarung von Schlüsselkandidaten mit CREATE UNIQUE INDEX Seite 168

21 5.3 Datenänderung/-zugriff mit SQL (DML) Hinweis: - DML-Anweisungen sind mengenorientiert - Mit einer Anweisungen kann mehr als ein Tupel eingefügt, geändert, gelöscht oder gelesen werden Benutzungs- und Effizienzvorteile (Client-Server-Szenario!) Anweisungen für Datenänderung: - INSERT - UPDATE - DELETE Anweisungen für Datenzugriff: - SELECT - CREATE / DROP VIEW (Konzeptuelle Ebene) Seite 169

22 5.3.1 INSERT Befehl zum Einfügen von Datensätzen in eine Tabelle - Erweiterung des Entityset eines Entitytyp (siehe Folie 57) - Ausprägungsformen Einfügen von Tupeln als Konstanten Einfügen von Tupeln als Abfrageergebnis auf einer (anderen) Relationen (SFW-Klausel, siehe Abschnitt SELECT) Voraussetzung für aufgeführte Beispiele (Test in MS Access): - Tabelle Buch, Tabelle Ausleihe - Anweisungen von Folie 152: CREATE TABLE Buch ( InvNr INTEGER NOT NULL, Titel VARCHAR(30), ISBN CHAR(5), Autor VARCHAR(40), PRIMARY KEY (InvNr)) CREATE TABLE Ausleihe ( InvNr INTEGER NOT NULL, Name VARCHAR(20), PRIMARY KEY (InvNr), FOREIGN KEY (InvNr) REFERENCES Buch(InvNr)) Seite 170

23 5.3.1 INSERT Tupel als Konstanten Syntax: INSERT INTO Basisrelationenname [(Spaltenname_1,..., Spaltenname_k)] VALUES (Wert_1 1,..., Wert_k 1 ) [,..., (Wert_1 n,..., Wert_k n )] Beispiel 1: Einfügen eines Tupels in Relation "Buch" INSERT INTO Buch (InvNr, Titel, ISBN, Autor) VALUES (1201,'Objektbanken','3-111','Heuer') Beispiel 2: Einfügen eines unvollständigen Tupels in Relation "Buch" INSERT INTO Buch (InvNr, ISBN) VALUES (4867,'3-221') Werte für "Autor" und "Titel" werden auf NULL gesetzt! Beispiel 3: Einfügen eines Tupels in Relation "Buch" ohne Inventarnummer INSERT INTO Buch (Titel, ISBN, Autor) VALUES ('Modula-4','3-222','Wirth') NULL-Wert für InvNr nicht erlaubt (Primärschlüssel!) Fehlermeldung Seite 171

24 5.3.1 INSERT Tupel als Konstanten Beispiel 4: Weglassen der Attributliste bei der INTO-Klausel INSERT INTO Buch VALUES (4710,'Modula-4','3-222','Wirth') - Werte der VALUES-Klausel werden den Attributen in der Reihenfolge zugeordnet, wie sie beim CREATE-Statement aufgeführt waren 4711 InvNr, 'Modula-4' Titel, '3-222' ISBN, 'Wirth' Autor Funktioniert nur, weil SQL Tabellenspalten nicht als (ungeordnete!) Menge auffasst Abweichung von der "reinen" Lehre! Beispiel 5: Einfügen eines Tupels in Relation "Ausleihe" INSERT INTO Ausleihe VALUES (0815,'Liebisch') Anweisung scheitert, da keine zugehöriger Primärschlüsselwert (InvNr = 0815) in Relation "Buch" existiert (Fremdschlüssel-Beziehung verletzt!) Beispiel 6: Einfügen von zwei Tupeln in Relation "Ausleihe" INSERT INTO Ausleihe (InvNr, Name) VALUES (1201,'Liebisch'), (4710,'Küspert') Seite 172

25 5.3.1 INSERT Tupel als SFW-Klausel Syntax: INSERT INTO Basisrelationenname [(Spaltenname_1,..., Spaltenname_k)] <lesende SQL-Anfrage> Wirkung: - Ergebnis der lesenden SQL-Anfrage (SFW: Select-From-Where) wird in die angegebene Relation eingefügt Abgeschlossenheit: SELECT-Anfrage liefert wieder eine Menge Mengenorientiertheit: INSERT-Operation kann Mengen verarbeiten - Voraussetzung sind strukturell gleiche Relationen Identische Anzahl von Attributen Kompatibilität der Attribut-Wertebereiche Reihenfolge der Attribute wichtig oder explizite Benennung - SQL-Anfrage kann beliebig komplex sein Seite 173

26 5.3.1 INSERT Tupel als SFW-Klausel Beispiel 7: Verdopplung der Tupel in Relation "Ausleihe" INSERT INTO Ausleihe SELECT * FROM Ausleihe Selektion aller Tupel (= *) aus Relation "Ausleihe" als Menge Einfügen der Tupelmenge in Relation "Ausleihe" Anweisung scheitert wegen Primärschlüssel-Verletzung Beispiel 8: Kopieren von Inhalten verschiedener Tabellen - Angenommen, es gibt zusätzlich eine Relation Ausleihe_alt mit denjenigen Büchern, die schon länger als 2 Jahre ausgeliehen sind - Inhalt dieser Relation soll nun, damit er nicht in Vergessenheit gerät, wieder in Relation Ausleihe übernommen werden INSERT INTO Ausleihe (InvNr, Name) SELECT InvNr_alt, Name_alt FROM Ausleihe_Alt Anweisung fügt alle Tupel aus Relation "Ausleihe_alt" in Relation "Ausleihe" ein (Kopieren) Seite 174

27 5.3.2 UPDATE Syntax: UPDATE Basisrelationenname SET Spaltenname_1 = Ausdruck_1 [, Spaltenname_k = Ausdruck_k] [WHERE Bedingung] Wirkung: - In allen Tupeln von Basisrelationenname, - welche die (optionale) Bedingung erfüllen, - werden die Attributwerte der Spaltenname_i wie angegeben ersetzt - Ausdruck_i: Konstante, Attribut, SFW-Ausdruck (Subselect) Beispiel 1: Der Titel des Buches mit der InvNr = 1201 ('Objektbanken') soll in 'Objektdatenbanken' geändert werden UPDATE Buch SET Titel = 'Objektdatenbanken' WHERE InvNr = 1201 Anweisung ändert immer nur ein einzelnes Tupel, weil InvNr als Primärschlüssel definiert ist Seite 175

28 5.3.2 UPDATE Beispiel 2: Alternative Anweisung für Beispiel 1 UPDATE Buch SET Titel = 'Objektdatenbanken' WHERE Titel = 'Objektbanken' Anweisung ändert datenabhängig ein oder mehrere Tupel, je nach dem wieviele Tupel den Titel 'Objektbanken' haben Beispiel 3: Für alle Bücher mit InvNr > 1000 soll der Autor auf 'Dr. Seltsam' gesetzt werden UPDATE Buch SET Autor = 'Dr. Seltsam' WHERE InvNr > 1000 Explizites Mengen-Update Beispiel 4: Gib allen Angestellten der Relation Angest(PNr, Name, Gehalt,...) eine Gehaltserhöhung um 1000,- EUR UPDATE Angest SET Gehalt = Gehalt Seite 176

29 5.3.2 UPDATE Beispiel 5: Für alle Bücher soll die InvNr auf 9999 gesetzt werden UPDATE Buch SET InvNr = 9999 WHERE-Klausel nicht benötigt, da alle Tupel der Relation zu ändern sind Operation verletzt Konsistenz ("Duplicate key") Wird vom DBVS nicht ausgeführt / ungeschehen gemacht Nicht trivial für DBVS (Fehlerbehandlungsmaßnahme) Diskussion des Ausführungsergebnis in MS Access (Atomarität!) Beispiel 6: Das Buch mit InvNr = 1201 soll den gleichen Titel bekommen wie das Buch mit InvNr = 4710 UPDATE Buch SET Titel = (SELECT Titel FROM Buch WHERE InvNr = 4710) WHERE InvNr = 1201 Subselect holt den Titel zum Buch mit InvNr = 4710 Ergebnis wird als Titel für das Buch mit InvNr = 1201 gesetzt Seite 177

30 5.3.3 DELETE Syntax: DELETE FROM Basisrelationenname [WHERE Bedingung] Wirkung: - Alle Tupel in Basisrelationenname, welche die (optionale) Bedingung erfüllen, werden gelöscht - Relationsschema bleibt unverändert (im Gegensatz zu DROP TABLE) Beispiel 1: - Das von Hr. Meyer ausgeliehene Buch mit InvNr = 4711 wurde zurückgegeben und soll aus der Relation "Ausleihe" gelöscht werden DELETE FROM Ausleihe WHERE InvNr = Alternative Bedingung (Name = 'Meyer') löscht eventuell mehr Seite 178

31 5.3.3 DELETE Beispiel 2: - Die Bibliothek hat die Hoffnung aufgegeben, die ausgeliehenen Bücher jemals zurückzuerhalten - Löschungs des gesamten Inhalts der Relation "Ausleihe" DELETE FROM Ausleihe - Eigentlich müssten auch noch die entsprechenden Bücher aus Relation "Buch" gelöscht werden, da "unwiderruflich verschwunden" Beispiel 3: Kann eine DELETE-Anweisung zur Integritätsverletzung führen (analog zu "Duplikate key" beim UPDATE)? DELETE FROM Buch WHERE Titel = 'Objektdatenbanken' Verletzung der Fremdschlüsselbeziehung zwischen Ausleihe und Buch Fremdschlüsselwert 4710 für Ausleihe.InvNr würde ins "Leere zeigen" Zurückweisung der Operation Seite 179