Kapitel 3 Datenintegrität

Transkript

1 Kapitel 3 Datenintegrität Flien zum Datenbankpraktikum Wintersemester 2012/13 LMU München 2008 Thmas Bernecker, Tbias Emrich 2010 Tbias Emrich, Erich Schubert unter Verwendung der Flien des Datenbankpraktikums aus dem Wintersemester 2007/08 vn Dr. Matthias Schubert

2 Übersicht 3.1 Integritätsbedingungen 3.2 Deklarative Cnstraints 3.3 Przedurale Cnstraints (Trigger) LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 2

3 Integritätsbedingungen (Integrity Cnstraints) Bedingungen, die vn einer Datenbank zu jedem Zeitpunkt erfüllt sein müssen Einschränkungen der möglichen DB-Zustände (Ausprägungen der Relatinen) Einschränkungen der möglichen Zustandsübergänge (Update-Operatinen) Vn wem werden Integritätsbedingungen überwacht: vm DBMS? vm Anwendungsprgramm? LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 3

4 Integritätsbedingungen sind Teil des Datenmdells wünschenswert ist eine zentrale Überwachung im DBMS innerhalb des Transaktinsmanagements Einhaltung unabhängig vn der jeweiligen Anwendung gewährleistet, es gelten dieselben Integritätsbedingungen für alle Benutzer für eine Teilmenge vn Integritätsbedingungen (primary key, unique, freign key, nt null, check) ist dies bei den meisten relatinalen Datenbanken realisiert für anwendungsspezifische Integritätsbedingungen ist häufig eine Definitin und Realisierung im Anwendungsprgramm ntwendig Prblem: Nur bei Verwendung des jeweiligen Anwendungsprgrammes ist die Einhaltung der Integritätsbedingungen garantiert swie Krrektheit etc. Oracle: einfache Integritätsbedingungen direkt in DDL (deklarativ), Unterstützung für kmplexere Integritätsbedingungen durch Trigger- Mechanismus (przedural) LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 4

5 Übersicht 3.1 Integritätsbedingungen 3.2 Deklarative Cnstraints 3.3 Przedurale Cnstraints (Trigger) LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 5

6 Deklarative Cnstraints Teil der Schemadefinitin (create table...) Arten: Schlüsseleigenschaft: primary key (einmal), unique (beliebig) keine Nullwerte: nt null (implizit bei primary key) Typintegrität: Datentyp Wertebedingungen: check (<Bedingung>) referenzielle Integrität: freign key... references... (nur Schlüssel) Cnstraints können attributsbezgen (für jeweils ein Attribut) und tabellenbezgen (für mehrere Attribute) definiert werden. Beschreibung möglich durch geschlssene lgische Frmeln (Sätze) 1.Stufe. Bsp. (Ntatin wie Tupelkalkül): Es darf keine zwei Räume mit gleicher R_ID geben. IB 1 : r 1 Raum ( r 2 Raum (r 1 [R_ID]= r 2 [R_ID] r 1 = r 2 )) Für jede Belegung muss ein entsprechender Raum existieren. IB 2 : b Belegung ( r Raum (b[r_id]= r[r_id])) LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 6

7 Definitin des Beispiels in SQL: Bei IB 1 handelt es sich um eine Eindeutigkeitsanfrderung an die Attributswerte vn R_ID in der Relatin Raum (Schlüsseleigenschaft). IB 2 frdert die referenzielle Integrität der Attributswerte vn R_ID in der Relatin Belegung als Fremdschlüssel aus der Relatin Raum. CREATE TABLE raum ( ); r_id varchar2(10) UNIQUE / PRIMARY KEY (IB 1 )... CREATE TABLE belegung ( ); b_id r_id number(10), varchar2(10) CONSTRAINT fk_belegung_raum REFERENCES raum(r_id) (IB 2 )... LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 7

8 Weiteres Beispiel: CREATE TABLE stadt ( name varchar2(25) NOT NULL, attributsbezgen bezirk varchar2(25) NOT NULL, attributsbezgen kfz_kennz char(4), flaeche number(10,2) NOT NULL attributsbezgen CONSTRAINT check_flaeche CHECK (flaeche > 0), attributsbezgen CONSTRAINT pk PRIMARY KEY (name,bezirk) tabellenbezgen ); ALTER TABLE stadt DISABLE CONSTRAINT check_flaeche; ALTER TABLE stadt ENABLE CONSTRAINT check_flaeche; ALTER TABLE stadt DROP CONSTRAINT check_flaeche; LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 8

9 Überwachung vn Integritätsbedingungen durch das DBMS Definitinen: S sei ein Datenbankschema IB sei eine Menge vn Integritätsbedingungen I über dem Schema S DB sei Instanz vn S, d.h. der aktuelle Datenbankzustand (über dem Schema S) U sei eine Update-Transaktin, d.h. eine Menge zusammengehöriger Einfüge-, Lösch- und Änderungsperatinen U(DB) sei der aktuelle Datenbankzustand nach Ausführen vn U auf DB Check(I,DB) bezeichne den Test der Integritätsbedingung I auf dem aktuellen Datenbankzustand DB Check(I,DB) = true, falls I in DB erfüllt ist false, falls I in DB nicht erfüllt ist LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 9

10 Prüfen der Integrität Wann sllen Integritätsbedingungen geprüft werden? Peridisches Prüfen der Datenbank DB gegen alle Integritätsbedingungen: if (Check(I,DB)) then <k> else <Rücksetzen auf letzten knsistenten Zustand>; Prbleme: Rücksetzen auf letzten geprüften knsistenten Zustand ist aufwändig beim Rücksetzen gehen auch krrekte Updates verlren erflgte lesende Zugriffe auf inknsistente Daten sind nicht mehr rückgängig zu machen LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 10

11 Inkrementelle Überprüfung bei jedem Update Vraussetzung: Update erflgt auf einem knsistenten Datenbankzustand dazu flgende Erweiterung: Check(I,U(DB)) = true, falls I durch Update U auf DB nicht verletzt ist false, falls I durch Update U auf DB verletzt ist dann: <führe U durch>; if ( I IB: Check(I,U(DB))) then <k> else <rllback U>; LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 11

12 Bei jedem Update U alle Integritätsbedingungen gegen die gesamte Datenbank zu testen ist zu teuer, daher Verbesserungen: 1. Nur betrffene Integritätsbedingungen testen; z.b. kann die referenzielle Integritätsbedingung Belegung Raum, nicht durch Änderungen an der Relatin Dzent verletzt werden Einfügen in die Relatin Raum verletzt werden Löschen aus der Relatin Belegung verletzt werden 2. Abhängig vn U nur vereinfachte Frm der betrffenen Integritätsbedingungen testen; z.b. muss bei Einfügen einer Belegung x nicht die gesamte Bedingung IB 2 getestet werden, sndern es genügt der Test vn: r Raum (x[r_id]= r[r_id]) LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 12

13 Bei welchen Operatinen muss geprüft werden? Beispiel: create table t1 ( a_id primary key (a_id)) create table t2 ( b_id... a_id... primary key (b_id), freign key (a_id) references t1) Insert/Update in Tabelle t2: Existiert zu einem eingefügten/geänderten Fremdschlüssel in t2 kein entsprechender Schlüssel in t1, dann wird die Operatin zurückgewiesen. LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 13

14 Update in Tabelle t1: Existiert zu einem Schlüssel in t1 ein abhängiger Datensatz (Fremdschlüssel) in t2, dann wird jede Änderung des Schlüssels zurückgewiesen. Löschen in Tabelle t1: Löschen immer möglich, wenn kein abhängiger Datensatz in t2 existiert weitere Optinen: Optin ON DELETE NO ACTION ON DELETE RESTRICT Wirkung Änderungsperatin wird zurückgewiesen, falls abhängiger Datensatz vrhanden ON DELETE CASCADE ON DELETE SET NULL ON DELETE SET DEFAULT Abhängige Datensätze in t2 werden autmatisch gelöscht; kann sich über mehrstufige Abhängigkeiten frtsetzen Wert des abhängigen Fremdschlüssels t2 wird auf null gesetzt Wert des abhängigen Fremdschlüssels t2 wird auf den Default-Wert der Spalte gesetzt Beispiel: freign key (a_id) references t1 n delete cascade LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 14

15 Übersicht 3.1 Integritätsbedingungen 3.2 Deklarative Cnstraints 3.3 Przedurale Cnstraints (Trigger) LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 15

16 Przedurale Cnstraints (Trigger) Mtivatin: Kmplexere Bedingungen als bei deklarativen Cnstraints und damit verbundene Aktinen wünschenswert. Trigger: Aktin (PL/SQL-Prgramm), die einer Tabelle zugerdnet ist und durch ein bestimmtes Ereignis ausgelöst wird. Ein Trigger enthält Cde, der die mögliche Verletzung einer Integritätsbedingung bei einem bestimmten Ereignis-Typ testet und daraufhin bestimmte Aktinen veranlasst. mögliche Ereignisse: insert, update, delete zwei Arten: Befehls-Trigger (statement trigger): werden einmal pr auslösendem Befehl ausgeführt. Datensatz-Trigger (rw trigger): werden einmal pr geändertem/eingefügtem/gelöschtem Datensatz ausgeführt. mögliche Zeitpunkte: vr (BEFORE) der nach (AFTER) dem auslösenden Befehl LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 16

17 Datensatz-Trigger haben Zugriff auf zwei Instanzen eines Datensatzes: vr und nach dem Ereignis (Einfügen/Ändern/Löschen) Adressierung durch Präfix: :new. bzw. :ld. Zu einer Integritätsbedingung I gehören in der Regel mehrere Trigger T i I T 1 T n Je nach auslösendem Ereignis-Typ unterschiedliche Trigger für die Integritätsbedingung LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 17

18 Aufbau eines Trigger-Prgramms: create r replace trigger <trig_name> befre/after/instead f -- Trigger vr/nach/alt. zu Auslöser ausführen insert r update f <attrib1>, <attrib2>,... r delete -- Trigger-Ereignisse n <tab_name>/<view_name>/ -- zugehörige Tabelle d. View (DML-Trigger) <schema_name>/<db_name> -- Schema d. Datenbank (DDL-Trigger) [fr each rw] -- Datensatz-Trigger when <bedingung> -- zusätzliche Trigger-Restriktin declare... begin if inserting then <pl/sql> end if; if updating (<attrib1>) then <pl/sql> end if; if deleting then <pl/sql> end if; Cde hier gilt für alle Ereignisse end; LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 18

19 Beispiel Ausgangspunkt: Relatin Perid_Belegung mit regelmäßig stattfindenden Lehrveranstaltungen in einem Hörsaal Hier müssen flgende Bedingungen gelten: p Perid_Belegung (0 p[tag] 6 p[erster_termin] p[letzter_termin] Wchentag(p[Erster_Termin]) = p[tag] Wchentag(p[Letzter_Termin]) = p[tag] ) Frmulierung als deklaratives Cnstraint: ALTER TABLE Perid_Belegung ADD CONSTRAINT check_day CHECK ( (Tag between 0 and 6) and (Erster_Termin <= Letzter_Termin) and (t_number (t_char (Erster_Termin, 'd')) = Tag) and (t_number (t_char (Letzter_Termin, 'd')) = Tag) ); LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 19

20 Frmulierung als przedurales Cnstraint (Trigger): CREATE OR REPLACE TRIGGER check_day BEFORE INSERT OR UPDATE ON Perid_Belegung FOR EACH ROW DECLARE tag number; et date; lt date; BEGIN tag := :new.tag; et := :new.erster_termin; lt := :new.letzter_termin; if (tag < 0) r (tag > 6) r (et > lt) r (t_number(t_char(et, 'd'))!= tag) r (t_number(t_char(lt, 'd'))!= tag) then raise_applicatin_errr(-20089, 'Falsche Tagesangabe'); end if; END; LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 20

21 Sequenzen für die Erstellung eindeutiger IDs CREATE SEQUENCE <seq_name> [INCREMENT BY n] -- Default: 1 [START WITH n] -- Default: 1 [{MAXVALUE n NOMAXVALUE}] -- Maximalwert (10^27 bzw. -1) [{MINVALUE n NOMINVALUE}] -- Mindestwert (1 bzw. -10^26) [{CYCLE NOCYCLE}] [{CACHE n NOCACHE}]; -- Vrcachen, Default: 20 Zugreifen über NEXTVAL (nächster Wert) und CURRVAL (aktueller Wert): CREATE SEQUENCE seq_pers; INSERT INTO Persn (p_id, p_name, p_alter) VALUES (seq_pers.nextval, 'Ulf Mustermann', 28); LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 21

22 Beispiel mit Trigger: CREATE OR REPLACE TRIGGER pers_insert BEFORE INSERT ON Persn FOR EACH ROW BEGIN END; SELECT seq_pers.nextval INTO :new.p_id FROM dual; INSERT INTO Persn (p_name, p_alter) VALUES ('Ulf Mustermann', 28); kein expliziter Zugriff (.NEXTVAL) nötig! LMU München Flien zum Datenbankpraktikum Wintersemester 2012/13 22