Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » SQL Anywhere Server - SQL-Benutzerhandbuch » Datenbanken erstellen » Datenintegrität gewährleisten » Entitäts- und referenzielle Integrität erzwingen » Referenzielle Integrität prüfen

 

Integritätsprüfungen bei DELETE oder UPDATE

Fremdschlüsselfehler können auch dann auftreten, wenn Sie einen Aktualisierungs- oder einen Löschvorgang ausführen. Beispiel: Sie möchten die Abteilung R&D aus der Abteilungstabelle "Departments" löschen. Das Feld "DepartmentID" ist der Primärschlüssel der Abteilungstabelle "Departments" und stellt die EINS-Seite der Eins-zu-Viele-Beziehung dar. Beim Feld "DepartmentID" der Tabelle "Employees" handelt es sich um den entsprechenden Fremdschlüssel und damit um die VIELE-Seite. Ein Datensatz auf der EINS-Seite einer solchen Beziehung kann erst dann gelöscht werden, wenn alle entsprechenden Einträge auf der VIELE-Seite ebenfalls gelöscht sind.

Fehler der referenziellen Integrität bei DELETE

Angenommen, Sie versuchen, die Abteilung R&D (DepartmentID 100) in der Departments-Tabelle zu löschen. Es wird ein Fehler gemeldet, der darauf hinweist, dass andere Datensätze in der Datenbank enthalten sind, die die Abteilung R&D referenzieren, und der Löschvorgang wird nicht ausgeführt. Um die Abteilung R&D zu löschen, müssen Sie zuerst die darin enthaltenen Mitarbeiter entfernen, und zwar folgendermaßen:

DELETE
FROM Employees
WHERE DepartmentID = 100;

Nachdem Sie alle Mitarbeiter, die zur Abteilung R&D gehören, gelöscht haben, können Sie nun die Abteilung R&D löschen.

DELETE 
FROM Departments 
WHERE DepartmentID = 100;

Machen Sie diese Änderungen in der Datenbank rückgängig, indem Sie eine ROLLBACK-Anweisung eingeben:

ROLLBACK;
Fehler der referenziellen Integrität bei UPDATE

Jetzt möchten Sie zum Beispiel das Feld "DepartmentID" in der Tabelle "Employees" ändern. Das Feld "DepartmentID" ist der Fremdschlüssel der Tabelle "Employees" und stellt die VIELE-Seite der Eins-zu-Viele-Beziehung dar. Beim Feld "DepartmentID" der Tabelle "Departments" handelt es sich um den entsprechenden Primärschlüssel und damit um die EINS-Seite. Ein Datensatz auf der VIELE-Seite einer solchen Beziehung kann erst dann geändert werden, wenn er einen entsprechenden Eintrag auf der EINS-Seite besitzt. Das heißt, erst dann, wenn er über einen Primärschlüssel zum Referenzieren verfügt.

Folgende UPDATE-Anweisung verursacht zum Beispiel einen Integritätsfehler:

UPDATE Employees
SET DepartmentID = 600
WHERE DepartmentID = 100;

Die Fehlermeldung Kein Primärschlüsselwert für Fremdschlüssel 'FK_DepartmentID_DepartmentID' in Tabelle 'Employees' wird ausgegeben, da es keine Abteilung mit der DepartmentID 600 in der Tabelle "Departments" gibt.

Um den Wert im Feld "DepartmentID" in der Tabelle "Employees" ändern zu können, muss er mit einem vorhandenen Wert in der Tabelle "Departments" übereinstimmen. Zum Beispiel:

UPDATE Employees
SET DepartmentID = 300
WHERE DepartmentID = 100;

Diese Anweisung kann ausgeführt werden, da die "DepartmentID" 300 mit der bereits vorhandenen Abteilung "Finance" übereinstimmt.

Machen Sie diese Änderungen in der Datenbank rückgängig, indem Sie eine ROLLBACK-Anweisung eingeben:

ROLLBACK;
Integrität zum Zeitpunkt der Festschreibung mit COMMIT prüfen

In den oben genannten Beispielen wurde die Integrität der Datenbank geprüft, als die Befehle ausgeführt wurden. Es wird kein Vorgang ausgeführt, der zu einer Inkonsistenz in der Datenbank führen würde.

Sie können die Datenbank auch so konfigurieren, dass die Integrität erst zum Zeitpunkt der Festschreibung mit COMMIT geprüft wird, indem Sie die wait_for_commit-Option verwenden. Wählen Sie diese Option, wenn Sie Änderungen vornehmen möchten, die bei der Eingabe von Änderungen zu temporären Dateninkonsistenzen führen können. Beispiel: Sie möchten die Abteilung R&D aus den Tabellen "Employees" und "Departments" löschen. Da diese Tabellen aufeinander verweisen und die Löschungen jeweils nur in einer Tabelle durchgeführt werden können, sind in den Tabellen während des Löschvorgangs Inkonsistenzen vorhanden. In diesem Fall kann die Datenbank erst einen COMMIT-Vorgang ausführen, wenn der Löschvorgang abgeschlossen ist. Aktivieren Sie die wait_for_commit-Option, um Dateninkonsistenzen zuzulassen, bis der COMMIT-Vorgang ausgeführt wird. Weitere Hinweise finden Sie unter wait_for_commit-Option [Datenbank].

Sie können auch Fremdschlüssel so definieren, dass sie automatisch entsprechend den Änderungen der Primärschlüssel abgeändert werden. Wenn für den Fremdschlüssel aus "Employees" zu "Departments" zum Beispiel mit ON DELETE CASCADE eine kaskadierende Löschung festgelegt ist, werden bei einer Löschung der Abteilungskennung automatisch auch die entsprechenden Einträge in der Tabelle "Employees" gelöscht.

In den obigen Fällen besteht keine Möglichkeit, eine inkonsistente Datenbank auf Dauer festzuschreiben. SQL Anywhere unterstützt auch alternative Aktionen, wenn Änderungen die Datenbank inkonsistent machen würden. Weitere Hinweise finden Sie unter Datenintegrität gewährleisten.