DB2 Universal Database - Systemverwaltung


Planen der Integritätsbedingungen

Eine Integritätsbedingung ist eine Regel, die vom Datenbankmanager angewendet wird. Vier Arten der Behandlung von Integritätsbedingungen werden in diesem Abschnitt beschrieben:

"Eindeutige Integritätsbedingungen"
Stellen die Eindeutigkeit der Schlüsselwerte in einer Tabelle sicher. Alle Änderungen an den Spalten, die den Primärschlüssel bilden, werden auf Eindeutigkeit überprüft.

"Referentielle Integrität"
Implementiert referentielle Integritätsbedingungen für die Operationen INSERT (Einfügen), UPDATE (Aktualisieren) und DELETE (Löschen). Dies ist der Status einer Datenbank, in der alle Werte aller Fremdschlüssel gültig sind.

"Prüfungen auf Integritätsbedingungen in Tabellen"
Stellen sicher, daß keine geänderten Daten gegen Bedingungen verstoßen, die bei der Erstellung oder der Änderung der Tabelle angegeben wurden.

"Auslöser"
Definieren eine Reihe von Aktionen, die ausgeführt werden, wenn sie durch eine Aktualisierungs-, Lösch- oder Einfügeoperation für eine angegebene Tabelle aufgerufen werden.

Eindeutige Integritätsbedingungen

Eine eindeutige Integritätsbedingung ist die Regel, die sicherstellt, daß Schlüsselwerte innerhalb der Tabelle eindeutig sind. Jede Spalte, die Bestandteil des Schlüssels in einer eindeutigen Integritätsbedingung ist, muß mit NOT NULL (keine Nullwerte möglich) definiert werden. Eindeutige Integritätsbedingungen werden in der Anweisung CREATE TABLE oder ALTER TABLE mit Hilfe der Klausel PRIMARY KEY oder UNIQUE definiert.

Eine Tabelle kann eine beliebige Anzahl eindeutiger Integritätsbedingungen enthalten. Jedoch kann nur eine eindeutige Spaltenfolge als Primärschlüssel für eine Tabelle definiert werden. Außerdem kann eine Tabelle nicht mehr als eine eindeutige Integritätsbedingung für dieselbe Gruppe von Spalten besitzen.

Wenn eine eindeutige Integritätsbedingung definiert ist, erstellt der Datenbankmanager einen eindeutigen Index (falls erforderlich) und markiert ihn als primären oder eindeutigen systembedingten Index. Die Einhaltung der Integritätsbedingung wird mit Hilfe des eindeutigen Index gewährleistet. Wenn eine eindeutige Integritätsbedingung für eine Spalte definiert ist, wird die Überprüfung auf Eindeutigkeit bei Aktualisierung mehrerer Zeilen an das Ende der Aktualisierungsoperation verlegt.

Die Spalten, die einer eindeutigen Integritätsbedingung unterliegen, können auch als Primärschlüssel in einer referentiellen Integritätsbedingung verwendet werden.

Referentielle Integrität

Der Datenbankmanager sorgt für die Erhaltung der referentiellen Integrität mit Hilfe referentieller Integritätsbedingungen, die festlegen, daß alle Werte eines bestimmten Attributs oder einer Tabellenspalte auch in einer anderen Tabelle oder Spalte vorhanden sind. Eine referentielle Integritätsbedingung kann zum Beispiel fordern, daß jeder Mitarbeiter in der Tabelle EMPLOYEE in einer Abteilung sein muß, die in der Tabelle DEPARTMENT aufgeführt ist. Kein Mitarbeiter kann in einer Abteilung sein, die nicht existiert.

Referentielle Integritätsbedingungen können in einer Datenbank implementiert werden, um zu gewährleisten, daß die referentielle Integrität erhalten bleibt, und um dem Optimierungsprogramm zu ermöglichen, durch Ausnutzung dieser besonderen Abhängigkeitsbeziehungen Abfragen effizienter zu verarbeiten. Bei der Planung im Hinblick auf referentielle Integrität sollten Sie alle Beziehungen zwischen Datenbanktabellen angeben. Sie können eine Abhängigkeitsbeziehung durch Definition eines Primärschlüssels und referentieller Integritätsbedingungen festlegen.

Betrachten Sie die folgenden, durch eine Beziehung verbundenen Tabellen:

Tabelle 20. Tabelle DEPARTMENT
DEPTNO (Primärschlüssel) DEPTNAME MGRNO
A00 Spiffy Computer Service Div. 000010
B01 Planning 000020
C01 Information Center 000030
D11 Manufacturing Systems 000060

Tabelle 21. Tabelle EMPLOYEE
EMPNO (Primärschlüssel) FIRSTNAME LASTNAME WORKDEPT (Fremdschlüssel) PHONENO
000010 Christine Haas A00 3978
000030 Sally Kwan C01 4738
000060 Irving Stern D11 6423
000120 Sean O'Connell A00 2167
000140 Heather Nicholls C01 1793
000170 Masatoshi Yoshimura D11 2890

Viele der folgenden Konzepte, die zum Verständnis der referentiellen Integrität hilfreich sind, werden mit Bezug auf diese Tabellen diskutiert.

Ein eindeutiger Schlüssel ist eine Spalte oder Spaltengruppe, in denen Werte einer Zeile in keiner anderen Zeile nochmals vorkommen. Für die Tabelle kann ein eindeutiger Schlüssel als Primärschlüssel definiert werden. Ein eindeutiger Schlüssel kann auch als übergeordneter Schlüssel bezeichnet werden, wenn sich ein Fremdschlüssel auf ihn bezieht.

Ein Primärschlüssel ist ein eindeutiger Schlüssel, der Teil der Definition der Tabelle ist. Jede Tabelle kann einen und nur einen Primärschlüssel besitzen. In den vorangegangenen Beispielen sind die Spalten DEPTNO und EMPNO Primärschlüssel der Tabellen DEPARTMENT und EMPLOYEE.

Ein Fremdschlüssel ist eine Spalte oder eine Spaltengruppe in einer Tabelle, die sich auf einen eindeutigen Schlüssel oder den Primärschlüssel derselben oder einer anderen Tabelle bezieht. Ein Fremdschlüssel wird zur Herstellung einer Abhängigkeitsbeziehung mit einem eindeutigen Schlüssel oder dem Primärschlüssel verwendet, um die referentielle Integrität zwischen Tabellen zu gewährleisten. Die Spalte WORKDEPT in der Tabelle EMPLOYEE ist ein Fremdschlüssel, weil sie auf den Primärschlüssel, die Spalte DEPTNO, in der Tabelle DEPARTMENT bezogen ist.

Ein zusammengesetzter Schlüssel ist ein Schlüssel, der aus mehr als einer Spalte besteht. Sowohl Primär- als auch Fremdschlüssel können zusammengesetzte Schlüssel sein. Wenn zum Beispiel Abteilungen eindeutig durch eine Kombination aus Unternehmensbereichsnummer und Abteilungsnummer identifiziert würden, wären zwei Spalten erforderlich, um den Schlüssel für die Tabelle DEPARTMENT zu bilden.

Ein übergeordneter Schüssel ist ein Primärschlüssel oder eindeutiger Schlüssel einer referentiellen Integritätsbedingung. Als Integritätsbedingung über Primärschlüssel wird der übergeordnete Standardschlüssel der referentiellen Integritätsbedingung festgelegt, wenn keine Gruppe übergeordneter Schlüsselspalten angegeben wird.

Eine übergeordnete Tabelle ist eine Tabelle mit einem übergeordneten Schlüssel, auf den mindestens ein Fremdschlüssel in derselben oder einer anderen Tabelle verweist. Eine Tabelle kann in beliebig vielen Beziehungen eine übergeordnete Tabelle sein. Die Tabelle DEPARTMENT, die einen Primärschlüssel in der Spalte DEPTNO hat, ist zum Beispiel eine übergeordnete Tabelle zur Tabelle EMPLOYEE, die den Fremdschlüssel WORKDEPT enthält.

Eine übergeordnete Zeile ist eine Zeile einer übergeordneten Tabelle, deren Wert des übergeordneten Schlüssels mit mindestens einem Wert eines Fremdschlüssels in einer abhängigen Tabelle übereinstimmt. Eine Zeile in einer übergeordneten Tabelle ist nicht unbedingt eine übergeordnete Zeile. Die vierte Zeile (D11) der Tabelle DEPARTMENT ist die übergeordnete Zeile der dritten und der sechsten Zeile in der Tabelle EMPLOYEE. Die zweite Zeile (B01) der Tabelle DEPARTMENT ist jedoch keine übergeordnete Zeile zu irgendeiner anderen Zeile.

Eine abhängige Tabelle ist eine Tabelle, die einen oder mehrere Fremdschlüssel enthält. Eine abhängige Tabelle kann gleichzeitig auch eine übergeordnete Tabelle sein. Eine Tabelle kann in einer beliebigen Anzahl von Beziehungen eine abhängige Tabelle sein. Die Tabelle EMPLOYEE enthält den Fremdschlüssel WORKDEPT und ist von der Tabelle DEPARTMENT abhängig, deren Primärschlüssel die Spalte DEPTNO ist.

Eine abhängige Zeile ist eine Zeile einer abhängigen Tabelle, die einen Nichtnullwert im Fremdschlüssel enthält, der mit dem Wert eines übergeordneten Schlüssels übereinstimmt. Der Wert des Fremdschlüssels stellt einen Verweis der abhängigen Zeile auf die übergeordnete Zeile dar. Da Fremdschlüssel Nullwerte akzeptieren kann, ist eine Zeile einer abhängigen Tabelle nicht unbedingt auch eine abhängige Zeile.

Eine Tabelle ist eine untergeordnete Tabelle zu einer anderen Tabelle, wenn sie selbst eine abhängige Tabelle oder eine untergeordnete Tabelle zu einer abhängigen Tabelle ist. Eine untergeordnete Tabelle enthält einen Fremdschlüssel, der bis zu einem übergeordneten Schlüssel einer Tabelle zurückverfolgt werden kann.

Ein Referenzzyklus ist ein Pfad von Abhängigkeitsbeziehungen, durch den eine Tabelle mit sich selbst verknüpft wird. Wenn eine Tabelle direkt mit sich selbst verknüpft ist, handelt es sich um eine auf sich selbst verweisende Tabelle. Wenn die Tabelle EMPLOYEE eine weitere Spalte mit dem Namen MGRID enthielte, in der die EMPNO (Personalnummern) für jeden Manager eines Mitarbeiters aufgeführt wären, wäre die Tabelle EMPLOYEE eine auf sich selbst verweisende Tabelle. MGRID wäre ein Fremdschlüssel für die Tabelle EMPLOYEE.

Eine auf sich selbst verweisende Tabelle ist innerhalb derselben Beziehung sowohl übergeordnete als auch abhängige Tabelle. Eine auf sich selbst verweisende Zeile ist eine Zeile, die sowohl eine übergeordnete als auch eine abhängige Zeile zu sich selbst ist. Die Integritätsbedingung, die in diesem Fall vorhanden ist, wird als auf sich selbst verweisende Integritätsbedingung bezeichnet. Wenn beispielsweise der Wert für den Fremdschlüssel in einer Zeile einer auf sich selbst verweisenden Tabelle mit dem Wert des eindeutigen Schlüssels in dieser Zeile übereinstimmt, dann verweist die Zeile auf sich selbst.

Eine referentielle Integritätsbedingung ist eine Festlegung, daß Nichtnullwerte eines bestimmten Fremdschlüssels nur gültig sind, wenn sie auch als Wert für einen eindeutigen Schlüssel einer bestimmten Tabelle vorkommen. Der Zweck referentieller Integritätsbedingungen ist die Gewährleistung, daß Datenbankbeziehungen erhalten bleiben und Dateneingaberegeln befolgt werden.

Auswirkungen auf SQL-Operationen

Die Implementierung referentieller Integritätsbedingungen hat besondere Auswirkungen für einige SQL-Operationen, bei denen unterschieden wird, ob es sich um übergeordnete oder abhängige Tabellen handelt. In diesem Abschnitt werden die Auswirkungen einer Wahrung der referentiellen Integrität auf SQL-Operationen mit den Anweisungen INSERT, DELETE, UPDATE und DROP behandelt.

DB2 sorgt nicht automatisch für die systemübergreifende Erhaltung referentieller Integritätsbedingungen. Wenn also referentielle Integritätsbedingungen systemübergreifend realisiert werden sollen, müssen die Anwendungen die erforderliche Logik enthalten.

Die folgenden Themen werden behandelt:

Regeln zur Anweisung INSERT

Sie können jederzeit eine Zeile in einer übergeordnete Tabelle einfügen, ohne daß eine Aktion in abhängigen Tabellen durchgeführt wird. In einer abhängigen Tabelle hingegen können Sie keine Zeile einfügen, sofern es keine Zeile in der übergeordneten Tabelle mit einem übergeordneten Schlüsselwert gibt, der mit dem Fremdschlüsselwert der einzufügenden Zeile übereinstimmt, wenn dieser Fremdschlüsselwert nicht NULL ist. Der Wert eines zusammengesetzten Fremdschlüssels ist NULL, wenn irgendeine Komponente des Werts NULL ist.

Diese Regel gilt implizit, wenn ein Fremdschlüssel definiert wird.

Bei dem Versuch, eine Zeile in einer Tabelle mit referentiellen Integritätsbedingungen einzufügen, ist die Operation INSERT nicht zulässig, wenn einer der Nichtnullwerte des Fremdschlüssels nicht im übergeordneten Schlüssel der übergeordneten Tabelle vorkommt. Wenn die Operation INSERT bei dem Versuch, mehrere Zeilen einzufügen, aufgrund einer Zeile fehlschlägt, wird keine der Zeilen eingefügt.

Regeln zur Anweisung DELETE

Wenn eine Zeile aus einer übergeordneten Tabelle gelöscht wird, prüft DB2, ob es abhängige Zeilen in abhängigen Tabellen mit übereinstimmenden Fremdschlüsselwerten gibt. Werden abhängige Zeilen gefunden, sind mehrere Aktionen möglich. Sie können bestimmen, welche Aktion ausgeführt wird, indem Sie bei der Erstellung der abhängigen Tabelle eine Löschbedingung angeben.

Die Löschbedingungen, die für eine abhängige Tabelle (die Tabelle, die den Fremdschlüssel enthält) für den Fall, daß ein Primärschlüssel gelöscht wird, angegeben werden können, sind folgende:

RESTRICT
Diese Löschbedingung verhindert, daß eine Zeile in der übergeordneten Tabelle gelöscht wird, wenn eine oder mehrere abhängige Zeilen gefunden werden. Wenn sowohl die übergeordneten als auch die abhängigen Zeilen gelöscht werden sollen, müssen die abhängigen Zeilen zuerst gelöscht werden. Löschen zuerst der übergeordneten Zeilen verletzt die referentielle Integritätsbedingung und ist nicht zulässig.

NO ACTION
Sichert das Vorhandensein einer übergeordneten Zeile für jede untergeordnete Zeile, nachdem alle referentiellen Integritätsbedingungen angewendet wurden.

CASCADE
Diese Löschbedingung legt fest, daß durch Löschen einer Zeile der übergeordneten Tabelle automatisch auch alle abhängigen Zeilen in der abhängigen Tabelle gelöscht werden. Diese Löschbedingung ist sinnvoll, wenn eine Zeile in der abhängigen Tabelle ohne die Zeile in der übergeordneten Tabelle keine Bedeutung mehr hätte.

Das Löschen der übergeordneten Zeile bewirkt zunächst, daß die abhängigen Zeilen, die auf einen Primärschlüssel verweisen, automatisch gelöscht werden. Daher ist es nicht nötig, die abhängigen Zeilen zuerst zu löschen. Wenn einige dieser abhängigen Zeilen selbst übergeordnete Zeilen zu abhängigen Zeilen sind, wird die Löschbedingung auf diese Abhängigkeitsbeziehungen ebenfalls angewendet. DB2 verwaltet gestaffelte Löschoperationen.

SET NULL
Diese Löschbedingung bewirkt, daß durch das Löschen einer Zeile der übergeordneten Tabelle die Werte des Fremdschlüssels in allen abhängigen Zeilen auf NULL gesetzt werden. Die anderen Spalten der Zeilen bleiben unverändert.

Wenn bei der Erstellung keine Löschbedingung explizit definiert wird, wird die Löschbedingung NO ACTION verwendet.

Jede Tabelle, die in eine Löschoperation mit einbezogen werden kann, wird als durch übergreifendes Löschen verknüpft bezeichnet. Die folgenden Einschränkungen gelten für Verknüpfungen durch übergreifendes Löschen.

In einer abhängigen Tabelle können zu jeder Zeit Zeilen gelöscht werden, ohne daß eine Aktion in der übergeordneten Tabelle erforderlich wird. Zum Beispiel könnte in der Abteilung-Mitarbeiter-Beziehung (DEPARTMENT-EMPLOYEE) ein Mitarbeiter in den Ruhestand gehen, so daß seine Zeile aus der Tabelle EMPLOYEE ohne Auswirkung auf die Tabelle DEPARTMENT gelöscht würde. (In der umgekehrten Mitarbeiter-Abteilung-Beziehung (EMPLOYEE-DEPARTMENT) ist die Abteilungsmanager-ID ein Fremdschlüssel mit Verweis auf den übergeordneten Schlüssel der Tabelle EMPLOYEE ist. Wenn ein Manager in den Ruhestand tritt, hat dies natürlich eine Auswirkung auf die Tabelle DEPARTMENT.)

Regeln zur Anweisung UPDATE

DB2 läßt nicht zu, daß ein eindeutiger Schlüssel einer übergeordneten Zeile aktualisiert wird. Wenn ein Fremdschlüssel in einer abhängigen Tabelle aktualisiert wird und der Fremdschlüssel nicht NULL ist, muß er mit einem Wert des übergeordneten Schlüssels der übergeordneten Tabelle der Abhängigkeitsbeziehung übereinstimmen. Wenn eine referentielle Integritätsbedingung durch eine Operation UPDATE verletzt wird, tritt ein Fehler auf, und keine Zeile wird aktualisiert.

Für die Aktualisierung eines Werts in einer Spalte des übergeordneten Schlüssels gilt folgendes:

Zur Aktualisierung des Werts eines übergeordneten Schlüssels, der sich in einer übergeordneten Zeile befindet, müssen Sie zunächst die Beziehung zu allen abhängigen Zeilen in den abhängigen Tabellen durch eine der folgenden Operationen beseitigen:

Wenn es keine Abhängigkeit zum Schlüsselwert in der Zeile mehr gibt, ist die Zeile keine übergeordnete Zeile einer referentiellen Abhängigkeitsbeziehung mehr und kann aktualisiert werden.

Wenn ein Teil eines Fremdschlüssels aktualisiert wird und kein Teil des Fremdschlüssels einen Nullwert (NULL) enthält, muß der neue Wert des Fremdschlüssels als eindeutiger Schlüsselwert in der übergeordneten Tabelle vorhanden sein. Wenn kein Fremdschlüssel von einem bestimmten eindeutigen Schlüssel abhängig ist, d. h., wenn die Zeile mit dem eindeutigen Schlüssel keine übergeordnete Zeile ist, kann ein Teil des eindeutigen Schlüssels aktualisiert werden. Jedoch kann in diesem Fall nicht mehr als eine Zeile gleichzeitig zur Aktualisierung ausgewählt werden, da es sich um einen eindeutigen Schlüssel handelt und mehrere gleiche Werte in verschiedenen Zeilen nicht zulässig sind.

Prüfungen auf Integritätsbedingungen in Tabellen

Geschäftsregeln, die in Ihrem Datenbankentwurf identifiziert wurden, können mit Hilfe von Prüfungen auf Integritätsbedingungen in Tabellen (Table Check Constraints) implementiert werden. Prüfungen auf Integritätsbedingungen für Tabellen geben Suchbedingungen an, die für jede Zeile einer Tabelle angewendet werden. Diese Integritätsbedingungen werden automatisch aktiviert, wenn eine Anweisung UPDATE oder INSERT für eine Tabelle ausgeführt wird. Sie werden durch die Anweisung CREATE TABLE oder ALTER TABLE definiert.

Eine Prüfung auf Integritätsbedingung kann zur Gültigkeitsprüfung der Daten verwendet werden. Zum Beispiel müssen Werte für eine Abteilungsnummer innerhalb des Bereichs von 10 bis 100 liegen, oder die Jobbezeichnung für einen Mitarbeiter (Employee) kann nur "Verkauf" (Sales), "Manager" oder "Sachbearbeiter" (Clerk) lauten, oder ein Mitarbeiter, der länger als acht Jahre in der Firma ist, muß ein Gehalt über 45.500 Dollar beziehen.

Informationen zu den Auswirkungen von Prüfungen auf Integritätsbedingungen in Tabellen auf die Befehle IMPORT und LOAD finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.

Auslöser

Ein Auslöser (Trigger) ist eine definierte Gruppe von Aktionen, die immer dann ausgeführt werden, wenn eine DELETE-, INSERT- oder UPDATE-Operation für eine bestimmte Tabelle ausgeführt wird. Auslöser können zur Unterstützung von Geschäftsregeln definiert werden. Auslöser können außerdem zur automatischen Aktualisierung von Übersichts- oder Prüfdaten verwendet werden. Da ein Auslöser in der Datenbank gespeichert wird, müssen die durch den Auslöser ausgeführten Aktionen nicht mehr in jedem Anwendungsprogramm codiert werden. Der Auslöser wird einmal codiert, in der Datenbank gespeichert und automatisch durch DB2 je nach Bedarf aufgerufen, wenn eine Anwendung auf die Datenbank zugreift. Dadurch ist gewährleistet, daß die auf die Daten bezogenen Geschäftsregeln zu jeder Zeit in Kraft bleiben. Wenn eine Geschäftsregel geändert wird, müssen nur die entsprechenden Auslöser angepaßt werden.

Innerhalb einer ausgelösten SQL-Anweisung kann eine benutzerdefinierte Funktion (UDF) aufgerufen werden. Dadurch ist es möglich, daß die ausgelöste Aktion eine Nicht-SQL-Operation durchführen kann, wenn der Auslöser aktiviert wird. Es kann beispielsweise eine E-Mail-Nachricht als Alert-Mechanismus verschickt werden. Weitere Informationen zu Auslösern (Triggers) finden Sie in Erstellen eines Auslösers und im Handbuch Application Development Guide.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]