Kapitel 4 (Teil 3/3)
Werbung
'DWHQLQWHJULWlW Integritätsbedingungen Einschränkung der Datenbankzustände auf diejenigen, die tatsächlich in der realen Welt existieren. Integritätsbedingungen sind aus dem erstellten Datenmodell ableitbar (semantisch) und können deshalb bei der Erstellung des Schemas bereits angegeben werden. Folgende Vorteile ergeben sich: – Einmalige Angabe der Konsistenzbedingungen – Keine lästige Überprüfung der Konsistenzbedingungen durch die AWPs – Verzögerte Überprüfung der Integritätsbedingungen aus Effizienzgründen, Z. B. bei einer Masseneingabe von Daten Zwei Klassen von Integritätsbedingungen VWDWLVFKH Bedingungen – sind definiert bzgl. Datenbankzuständen G\QDPLVFKH Bedingungen – sind definiert bzgl. Zustandsänderungen Seite 136 von 152 6FKOVVHO Schlüssel in einer Relation (mittels primary key) Syntax – Wenn der Schlüssel nur ein Attribut umfasst, kann primary key direkt an das Ende der Attributdeklaration geschrieben werden. – Wenn der Schlüssel mehrere Attribute umfasst, gibt es eine eigene Klausel primary key (A1,…,An) – Es gibt höchstens einen Primärschlüssel in einer Relation. Semantik – Die als Primärschlüssel spezifizierten Attribute sind eindeutig. – Die Attribute dürfen nicht den Wert null annehmen. Schlüssel (mittels unique) Syntaktisch wird nun das Schlüsselwort unique benutzt. Semantik (SQL´92, QLFKWLQ,QWHUEDVH) – Im Gegensatz zum Primärschlüssel ist der Wert null bei unique-Attributen erlaubt. – Es können mehrere Tupel existieren, die im unique-Attribut den Wert null besitzen. Seite 137 von 152 Fremdschlüssel Damit bezeichnet man Attribute, die zur Modellierung einer Beziehung benutzt werden. Semantik: Seien R1 und R2 Relationen mit dem Schema RS1 und RS2. Sei K ( RS1). Schlüssel von R1 (gekennzeichnet durch primary key oder unique). Dann wird F RS2 )UHPGVFKOVVHO von R2 genannt, falls zu jedem Datensatz s aus der Relation R2 eine der folgenden Bedingungen gilt: – s[F] = NULL – es gibt einen Datensatz r aus R1, so dass s[F] = r[K] gilt. Mögliche Probleme, wenn referentielle Integrität nicht erfüllt ist: – Kunde bestellt eine Ware, die es nicht gibt. – Waren können von Kunden bestellt werden, der nicht existieren. Definition einer Fremdschlüsselbedingung: KNr muss bereits in der Relation Kunde vorher als Primärschlüssel oder mit dem Schlüsselwort unique gekennzeichnet worden sein. – create table Bestellt(KNr int,,…, foreign key(KNr) references Kunde(Knr)) oder Seite 138 von 152 – create table Bestellt(KNr int references Kunde(Knr), …) oder – create table Bestellt(KNr int,,…, constraint test foreign key(KNr) references Kunde(Knr)) In diesem Fall wird die Bedingung mit einem Namen versehen, was insbesondere die Flexibilität bei Änderungsoperationen erhöht. Seite 139 von 152 (LQKDOWXQJUHIHUHQWLHOOHU,QWHJULWlW In einer Relation, die eine Beziehung modelliert, sollte gewährleistet sein, dass die Fremdschlüssel mit Werten belegt sind. Relationale Algebra: – Relation R mit Primärschlüssel K – Relation S mit Fremdschlüssel F (bezieht sich auf K) S) 6 S.5 Erlaubte Änderungen – Einfügen eines Tupels s in S, wenn V > ) @ S . 5 – Verändern eines Attributwerts eines Tupels s aus S, wenn … – Verändern von U > . @ eines Tupels r aus R, wenn V ) = U > . @ 6 = Löschen eines Tupels r aus R, wenn … – Seite 140 von 152 hEHUZDFKXQJGHUUHIHUHQWLHOOHQ,QWHJULWlW Defaulteinstellung Löschen eines Tupels r aus einer Relation R ist i.A. nicht möglich, falls es noch Tupel aus anderen Relationen gibt, die über einen Fremdschlüssel an r gebunden sind. Kaskadierendes Löschen/Ändern Wenn ein Tupel r aus einer Relation R gelöscht/geändert wird, können auch Datensätze aus anderen Relationen automatisch gelöscht/geändert werden, die sich über einen Fremdschlüssel auf das Tupel r beziehen. Bei der Definition des Fremdschlüssels kann diese Einstellung mit aufgenommen werden: Setzen auf Null Wird ein Tupel gelöscht, wird der Wert aller davon abhängigen Attribute auf null gesetzt. create table Bestellt( KName char(20) constraint fk_kunde references kunde(KName) on delete cascade) on update set null, … ) Seite 141 von 152 =HLWSXQNWGHUhEHUSUIXQJ In SQL gibt es noch die Möglichkeit den Zeitpunkt der Überprüfung einer Integritätsbedingung zu beeinflussen. Motivation – Eine Integritätsbedingung gewährleistet, dass die Kontostände aller Konten eines Kunden stets über -5000 liegen. – Per Überweisung sollen 2000 EURO von einem Konto K1 eines Kunden auf ein anderes Konto K2 des gleichen Kunden übertragen werden. – Was passiert bei einem Kontostand von jeweils -2000 Euro? Anforderung – Bündelung von mehreren Operationen zu einer Einheit (7UDQVDNWLRQ) – Überprüfung der Integritätsbedingung am Beginn / Ende einer Transaktion Eine Integritätsbedingung kann nun mit folgenden Schlüsselworten versehen werden: – not deferrable: Die Integritätsbedingung wird sofort hinter einer Änderung überprüft. – deferrable: Es besteht jetzt die Möglichkeit der verzögerten Überprüfung. – deferrable initially deferred: Überprüfung erfolgt am Ende der Transaktion. – deferrable initially immediate: Überprüfung vor der Änderung. Seite 142 von 152 Eine mit dem Schlüsselwort deferrable versehene Bedingung mit einem Namen, sagen wir einfach MeineBedingung, kann noch zur Laufzeit angepasst werden: – set constraint MeineBedingung deferred – set constraint MeineBedingung immediate Seite 143 von 152 6WDWLVFKH,QWHJULWlWVEHGLQJXQJHQ Attributs-Bedingungen Diese Bedingungen beziehen sich auf ein Attribut einer Relation. – Die Überprüfung dieser Bedingungen findet immer dann statt, wenn das Attribut durch eine Änderung betroffen ist. Dies sorgt aber nicht dafür, dass auch tatsächlich die Bedingung stets erfüllt bleibt (wenn z. B. die Bedingung noch von einem anderen Attribut oder einer anderen Relation abhängt). Ausschluss von Nullwerten create table Kunde (KName char(20) QRWQXOO, …) – Wert des entsprechenden Attributs muss bei jedem Tupel vorliegen. Check-Bedingungen – sind beliebig komplexe Bedingungen, die ähnlich zu einer where-Klausel von SQL angegeben werden können. Dabei kann man sich direkt auf das Attribut beziehen. – Beispiel: create table Kunde( KName char(20) check(100 > (select count(*) from Auftrag A where A.KName = KName)), … ) Seite 144 von 152 Relationen-Bedingungen Einschränkung der Werte, die ein Tupel bzgl. seiner verschiedenen Attribute annehmen darf. – Diese Bedingungen werden immer dann überprüft, wenn ein Tupel in die Relation eingefügt wird oder ein bestehendes Tupel sich ändert. In SQL kann eine Relationen-Bedingung durch die check-Klausel beim Anlegen des Schemas angegeben werden. – In der Bedingung kann man sich auf alle Attribut der zugehörigen Relation beziehen. Die Deklaration einer solchen Bedingung erfolgt direkt bei der Deklaration der Relation oder zu einem späteren Zeitpunkt. Beispiele: – Stelle sicher, dass ein Kunde derzeit nicht mehr als 100 Waren bestellt hat. alter table Auftrag add check(100 > (select count(*) from Auftrag A where A.KName = KName)) – Stelle sicher, dass die Summe der Kontostände aller Kunden über 500 liegt. alter table Kunde add check(500 < (select sum(KTO) from Kunde K)) Seite 145 von 152 9HUZDOWHQYRQ,QWHJULWlWVEHGLQJXQJHQ Integritätsbedingungen können in SQL durch Verwendung des Schlüsselworts constraint implementiert und dabei mit einem Namen versehen werden. Hinzufügen/Löschen von Integritätsbedingungen alter table Bestellt add constraint plus_const check (Preis*Anzahl < 10000) – Dies ist eine Relationen-Bedingung. Ein Hinzufügen von Attribut-Bedingungen ist nicht möglich. alter table Kunde add constraint name_unique unique KName alter table <Name> drop constraint <CName> – Löschen wird für beliebige Bedingungen unterstützt. Seite 146 von 152 'DWHQEDQN%HGLQJXQJHQ Hierbei handelt sich um die mächtigste Form von Integritätsbedingungen. create assertion <name> check <condition> – Die Deklaration erfolgt außerhalb einer Deklaration einer Relation. – Die Überprüfung der Bedingung bei Änderung einer der beteiligten Relationen. – Leider werden diese Bedingungen nur von wenigen Systemen unterstützt. Im Gegensatz zu den vorherigen check-Klauseln gibt es nicht die Möglichkeit sich direkt auf ein Attribut einer Relation zu beziehen. Vergleich von verschiedenen Bedingungen Typ Attribut-Bedingung Ort der Deklaration Attribut Auslösen der Überprüfung Unteranfragen Einfügen in die Relation Ändern des Attributs Nein Relationen-Bedingung Relationenschema Einfügen in die Relation Ändern eines Tupels Nein Datenbank-Bedingung Datenbankschema Änderung einer der beteiligten Relationen Ja Seite 147 von 152 7ULJJHU.RQ]HSW Zusätzlich können komplexe Integritätsbedingungen auch über so genannte Trigger spezifiziert werden. – Trigger werden bereits seit langem von verschiedenen Herstellern angeboten, wobei erst mit SQL3 diese standardisiert wurden. – Im Gegensatz zu Assertion können mit einem Tigger auch G\QDPLVFKH ,QWHJULWlWVEHGLQJXQJHQ definiert werden. Da das Trigger-Konzept mit einer prozeduralen Erweiterung (PL/SQL) Hand in Hand geht, verschieben wir eine detaillierte Diskussion auf ein späteres Kapitel. Seite 148 von 152 $QOHJHQDQGHUHU6WUXNWXUHQ ,QGH[H Indexe sind Bestandteil der physischen Ebene. Sie dienen “nur” zur Verbesserung der Anfragezeit und haben keinen Einfluss auf die Anfragesemantik. – Maß für die Effizienz in Datenbanken: Anzahl der Plattenzugriffe Ein Index ist eine Instanz einer Indexstruktur. – In kommerziellen Systemen gibt es folgende Indexstrukturen: B-Bäume und Hashverfahren. – Eine detaillierte Diskussion der Beschreibung der Indexstrukturen erfolgt in einem separaten Abschnitt. Ein Index bezieht sich auf ein Attribut, bzw. eine Folge von Attributen – Bei mehreren Attributen werden diese lexikographisch miteinander verknüpft. Seite 149 von 152 $QOHJHQHLQHV,QGH[ create [unique] index <Index-Name> on <Relationen-Name> (<Attributname> [<Ordnung>] [,<Attributname>[<Ordnung>]]*) <Ordnung>::= Asc | Desc unique: Für alle Attributsnamen sind keine zwei Tupel mit gleichen Werten in diesem Attribut erlaubt Schlüsselbedingung ist erfüllt. In Datenbanksystemen, wie z. B. Oracle, können noch weitere Optionen beim Erzeugen von Indexen angegeben werden. – Ein &OXVWHULQGH[ bestimmt die physische Ordnung der Daten. – Ein “gewöhnlicher” Index hat keinen Einfluss auf die Ordnung. Man spricht dann auch von einem 6HNXQGlULQGH[. Beispiel: create unique index Kundenindex on Kunde (KName,KAdresse) /|VFKHQHLQHV,QGH[ drop index <Index-Name> Seite 150 von 152 6LFKWHQ Sichten entsprechen den externen DB-Schemata. In relationalen Systemen werden Sichten als (abgeleitete) Relationen aufgefasst, die durch Anfragen definiert werden. create view <Sichtname> [(<Attributname>[,<Attributname>]*)] as <Subquery> [with check option] Beispiel: create view Gute_Kunden as select * from Kunde where Kto > 100 with check option 6LFKWHQO|VFKHQ drop view <Sicht-Name> Seite 151 von 152 bQGHUQHLQHU6LFKWHQLQVWDQ] Durch das Schlüsselwort ZLWKFKHFNRSWLRQ können nur Datensätze in eine Sicht eingefügt werden, die bei einer Suche auf der Sicht auch wieder gefunden werden können. – Dies ist die einzig sinnvolle Variante einer View. Beim Einfügen eines Tupels in einer Sicht müssen die Basisrelationen angepasst werden. die zur Definition der Sicht benutzt wurden. – In einer Sicht werden keine Daten gespeichert! Die Zuordnung zu den Basisrelationen ist aber nicht immer möglich! – z. B. wenn ein Attribut einer Sicht durch eine Aggregatfunktion berechnet wird. Sichten sind in Oracle / Interbase veränderbar, wenn folgende Bedingungen gelten: – keine Aggregatfunktionen – keine Anweisungen mit distinct, group by, having, union und minus – from-Klausel enthält nur eine Relation – ein Schüssel der Basisrelationen muss in der select-Klausel enthalten sein. Es gibt aber durchaus veränderbare Sichten, die aber nicht alle vier der oben genannten Bedingungen, erfüllen. Seite 152 von 152
