SQL BEIM LÖSCHEN EINSCHRÄNKEN: Verhindere versehentlichen Datenverlust

Daten in SQL zu löschen ist meistens nicht so einfach wie das Entfernen einer einzelnen Zeile. In relationalen Datenbanken sind Tabellen oft miteinander verbunden, und das Löschen eines Datensatzes in einer Tabelle kann Auswirkungen auf eine andere Tabelle haben. 

SQL hat die Klausel „ ON DELETE “, die festlegt, was passieren soll, wenn eine referenzierte Zeile gelöscht wird. Nach der Klausel „ ON DELETE “ kannst du festlegen, was passieren soll, z. B. das Löschen blockieren, die abhängige Zeile automatisch entfernen oder die referenzierten Daten aktualisieren.

In diesem Tutorial zeige ich dir die Einschränkung „ ON DELETE RESTRICT “, die verhindert, dass eine übergeordnete Zeile gelöscht wird, wenn noch abhängige untergeordnete Zeilen vorhanden sind. Ich werde auch ausführlich darauf eingehen, wie die Einschränkung funktioniert, warum Datenbanken sie durchsetzen und wann sie im Vergleich zu anderen Löschregeln die richtige Wahl ist. Wenn du das umgekehrte Verhalten suchst – also dass beim Löschen einer übergeordneten Zeile automatisch die zugehörigen Datensätze entfernt werden –, schau dir unseren Leitfaden „ SQL ON DELETE CASCADE “ an.

Was bedeutet ON DELETE RESTRICT in SQL?

Die Einschränkung „ ON DELETE RESTRICT “ in SQL ist eine Funktion für die Sicherheit von Datenbanken. Es stellt sicher, dass du einen „übergeordneten” Datensatz nicht löschen kannst, wenn noch „untergeordnete” Datensätze darauf verweisen.

Anmerkung: Während Datenbanken wie PostgreSQL und MySQL das Schlüsselwort „ RESTRICT “ direkt unterstützen, setzt SQL Server die gleiche Einschränkung stattdessen über „ ON DELETE NO ACTION “ durch.

Referenzielle Integrität und Fremdschlüssel

Referenzielle Integrität ist das Prinzip, dass die Beziehungen zwischen Tabellen immer gültig bleiben müssen. Fremdschlüssel sorgen dafür, indem sie verlangen, dass die Werte in einer untergeordneten Tabelle mit den vorhandenen Zeilen in einer übergeordneten Tabelle übereinstimmen. Zum Beispiel kann ein „ DepartmentID ” in der Tabelle „ Employees ” auf einen bestimmten „ ID ” in der Tabelle „ Departments ” verweisen.

Deshalb gibt's die SQL- DELETE -Regeln, weil das Löschen einer übergeordneten Zeile diese Beziehung kaputt machen kann. Die Datenbank braucht klare Anweisungen, ob sie das Löschen blockieren, kaskadieren oder eine andere Aktion auf abhängige Zeilen anwenden soll.

Was RESTRICT wirklich bedeutet

Wenn du einen Fremdschlüssel mit „ ON DELETE RESTRICT “ definierst, schaut die Datenbank nach, ob es zugehörige untergeordnete Zeilen gibt, bevor sie das Löschen macht. Wenn ein untergeordneter Datensatz vorhanden ist, wird der Löschvorgang automatisch abgelehnt.  In diesem Fall verhindert „ RESTRICT “ die Löschung, anstatt die Daten zu ändern, wie wir später im Tutorial sehen werden.

Wie ON DELETE RESTRICT in SQL funktioniert

Um zu verstehen, wie die Einschränkung „ ON DELETE RESTRICT “ funktioniert, musst du wissen, wie die Datenbank Löschungen während einer Transaktion Schritt für Schritt auswertet.

Beziehungen zwischen Eltern- und Kind-Tabellen

In SQL hat die übergeordnete Tabelle die primären Datensätze, während die untergeordnete Tabelle die abhängigen Datensätze hat. Deine Datenbank könnte zum Beispiel eine übergeordnete Tabelle „ Categories “ mit dem Feld „ category_id “ (Produktkategorie) und dem Wert „Elektronik“ haben. Die Kindtabelle „ Products “ hat einen Eintrag „Smartphone“, der dann über „ category_id “ mit der übergeordneten Tabelle verknüpft wird.

Wenn du den Befehl „ DELETE “ für die übergeordnete Tabelle ausführst, checkt die Datenbank-Engine sofort alle zugehörigen untergeordneten Tabellen, um zu sehen, ob irgendwelche Zeilen auf diese bestimmte übergeordnete ID zeigen.

Was passiert, wenn du versuchst, eingeschränkte Zeilen zu löschen?

Wenn du versuchst, eine übergeordnete Zeile zu löschen, auf die noch verwiesen wird, bricht die Datenbank den Vorgang ab und gibt eine Fehlermeldung aus. Diese Fehlermeldung zeigt an, dass du gegen eine Fremdschlüsselbeschränkung verstoßen hast.

Das ist so gewollt, damit du dich bewusst entscheiden musst, ob du zuerst die abhängigen untergeordneten Zeilen löschst oder aktualisierst oder ob du nochmal überlegst, ob die übergeordnete Zeile überhaupt entfernt werden soll.

SQL ON DELETE RESTRICT vs. Andere Löschregeln

In einem DBMS gibt's bestimmte Regeln, die festlegen, wie Daten aus verbundenen Tabellen gelöscht werden können. In diesem Abschnitt schauen wir uns die Einschränkung „ ON DELETE RESTRICT “ im Vergleich zu den üblichen Löschregeln in SQL an, damit du genau siehst, wie sich jede einzelne auf die zugehörigen Daten auswirkt.

RESTRICT vs. CASCADE in SQL

Die SQL- RESTRICT -Einschränkung verhindert, dass übergeordnete Zeilen gelöscht werden, wenn untergeordnete Zeilen darauf verweisen, und sorgt so dafür, dass keine Daten aus Versehen verloren gehen. Die folgende Abfrage zeigt, wie man beim Definieren der Schemas der Tabellen „ RESTRICT “ einbaut. Es verhindert, dass ein Kunde gelöscht wird, wenn es Bestellungen gibt, die sich auf diesen Kunden beziehen.

-- Parent table
CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100)
);

-- Child table with ON DELETE RESTRICT
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE RESTRICT
);

Die SQL-Einschränkung „ CASCADE “ sorgt aber dafür, dass beim Löschen automatisch alle abhängigen untergeordneten Zeilen mit gelöscht werden. Im folgenden Beispiel lässt „ CASCADE “ zu, dass alle Bestellungen, die mit einem Kunden verbunden sind, automatisch gelöscht werden, wenn der Kundendatensatz gelöscht wird.

-- Child table with ON DELETE CASCADE
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE CASCADE
);

RESTRICT vs. SET NULL und SET DEFAULT

Die SQL-Einschränkungen „ SET NULL “ und „ SET DEFAULT “ behalten die untergeordneten Zeilen bei, ändern aber, wie sie auf die übergeordnete Zeile verweisen.

In der folgenden Abfrage wird zum Beispiel beim Löschen eines Kunden das Feld „ customer_id “ in den zugehörigen Bestellungen auf „ NULL “ gesetzt, sodass die Bestelldatensätze erhalten bleiben, aber die Verknüpfung zum Kunden entfernt wird.

-- Child table using SET NULL
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NULL,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE SET NULL
);

Wenn du die Einschränkung „ SET DEFAULT “ (Kunden-ID als Platzhalterwert verwenden) einsetzt, wird beim Löschen eines Kunden der Feldwert „ customer_id “ (Kunden-ID) in den zugehörigen Bestellungen auf seinen Standardwert gesetzt, sodass die Bestelldatensätze erhalten bleiben und ihnen ein vordefinierter Platzhalterwert zugewiesen wird.

-- Child table using SET DEFAULT
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT DEFAULT 0,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE SET DEFAULT
);

Erstellen von Fremdschlüsseln mit ON DELETE RESTRICT in SQL

Um die Einschränkung „ ON DELETE RESTRICT “ in SQL zu machen, musst du sie beim Erstellen der Beziehung zwischen zwei Tabellen festlegen.

RESTRICT in Tabellenschemata definieren

Du kannst das Löschverhalten in SQL beim Erstellen der Tabelle festlegen oder es nachträglich hinzufügen, wenn deine Tabelle schon da ist.

Das folgende Beispiel zeigt, wie man die SQL-Fremdschlüsselbeschränkung „ ON DELETE RESTRICT “ in der Anweisung „ CREATE TABLE “ benutzt, wenn man eine neue Tabelle in SQL definiert.

-- Stores department details
CREATE TABLE departments (
    department_id INT PRIMARY KEY, 
    department_name VARCHAR(100)
);

-- -- Prevents deleting a department with employees
CREATE TABLE employees (
    employee_id INT PRIMARY KEY,      -- Unique employee identifier
    department_id INT, 
    CONSTRAINT fk_employees_departments
        FOREIGN KEY (department_id)
        REFERENCES departments(department_id)
        ON DELETE RESTRICT 
);

Die folgende Abfrage fügt dieselbe Fremdschlüsselregel zur bestehenden Tabelle „ employees ” in der SQL-Anweisung „ ALTER TABLE ” hinzu, um zu verhindern, dass Abteilungen gelöscht werden, auf die noch von Mitarbeitern verwiesen wird.

-- Adds a foreign key constraint after the table already exists
ALTER TABLE employees
ADD CONSTRAINT fk_employees_departments
FOREIGN KEY (department_id)
REFERENCES departments(department_id)
ON DELETE RESTRICT;    -- Blocks deletion of departments that have employees

Standardmäßiges Löschverhalten in SQL

In vielen gängigen Datenbanksystemen wie SQL Server, PostgreSQL und MySQL ist „ RESTRICT “ das Standardverhalten. Wenn du einen Fremdschlüssel ohne Angabe einer „ ON DELETE “-Klausel definierst, verhält sich die Datenbank normalerweise so, als hättest du „ ON DELETE NO ACTION “ oder „ ON DELETE RESTRICT “ geschrieben. Dieses Datenbank-Engine-Design sorgt dafür, dass du eine Fehlermeldung bekommst, anstatt aus Versehen große Mengen an Daten zu löschen.

Häufige Anwendungsfälle für ON DELETE RESTRICT in SQL

In der Praxis wird die SQL- ON DELETE RESTRICT -Einschränkung immer dann benutzt, wenn die Datenintegrität eine explizite Überprüfung vor dem Löschen erfordert.

Schutz wichtiger Referenzdaten

Die SQL-Einschränkung „ RESTRICT “ wird oft für Tabellen verwendet, die wichtige Referenzdaten wie Benutzer, Konten, Produkte oder Suchwerte enthalten. Diese Datensätze werden oft in mehreren Teilen des Systems geteilt, und wenn man sie einfach so löscht, kann das zu großem Datenverlust oder Inkonsistenzen führen.

Zum Beispiel ist es meistens nicht sicher, einen Benutzer zu löschen, der noch Bestellungen, Audit-Protokolle oder Berechtigungen hat. Mit der SQL-Einschränkung „ ON DELETE RESTRICT “ verhindert die Datenbank das Löschen und zwingt dich, zuerst diese Abhängigkeiten zu klären, um die Integrität der historischen und Transaktionsdaten zu sichern.

Durchsetzung klarer Aufräum-Workflows

Die SQL- RESTRICT -Einschränkung ist auch nützlich, wenn du eine gezielte und nachvollziehbare Bereinigung durchführen möchtest. Es zwingt Entwickler und Admins dazu, sich genau zu überlegen, wie sie mit Daten umgehen. Anstatt die Datenbank Datensätze automatisch löschen zu lassen, zwingt dich die Einschränkung „ RESTRICT “ dazu, die abhängigen Daten zu überprüfen, um zu entscheiden, ob du die untergeordneten Datensätze löschen, sie einem neuen übergeordneten Datensatz zuweisen oder den Vorgang abbrechen möchtest.

Fehlerbehebung bei DELETE-Fehlern, die durch RESTRICT in SQL verursacht werden

Wenn die Einschränkung „ ON DELETE RESTRICT “ ein Löschen blockiert, kann der daraus resultierende Fehler verwirrend sein, wenn du ihn nicht erwartest. Wenn du diese Fehler verstehst, kannst du sie sicher beheben.

Verständnis von Fehlern wegen Verstoßes gegen Einschränkungen

Wenn du versuchst, eine übergeordnete Zeile zu löschen, auf die noch verwiesen wird, gibt die Datenbank eine Fremdschlüsselbeschränkungsverletzung aus. Die Nachricht wird in verschiedenen Datenbanksystemen wie folgt angezeigt:

• PostgreSQL: ERROR: update or delete on table "parent_table" violates foreign key constraint "fk_name" on table "child_table"

• MySQL: Error Code: 1451. Cannot delete or update a parent row: a foreign key constraint fails…

• SQL Server: The DELETE statement conflicted with the REFERENCE constraint "FK_Name". The conflict occurred in database "DBName", table "dbo.ChildTable", column 'ParentID'.

In allen Datenbanken wird die Fehlermeldung Folgendes anzeigen:

• Welche Fremdschlüsselbeschränkung wurde verletzt?
• Welche Tabelle ist die untergeordnete Tabelle?
• Welcher Schlüsselwert wird noch referenziert?

Sichere Lösung für blockierte Löschvorgänge

Wenn du die Fehlermeldung „Löschen blockiert“ bekommst, aber die übergeordnete Zeile löschen wolltest, empfehle ich dir, eine der folgenden Optionen zu nutzen:

Lösch zuerst den untergeordneten Datensatz: Wenn die abhängigen Daten nicht mehr gebraucht werden, mach erst mal eine „ DELETE “-Anweisung für die untergeordneten Zeilen und lösche dann den übergeordneten Datensatz.

-- Step 1: Remove dependencies
DELETE FROM Orders WHERE CustomerID = 501; 
-- Step 2: Now the parent delete will work
DELETE FROM Customers WHERE CustomerID = 501;

Kinderreferenzen aktualisieren: Wenn du die untergeordneten Zeilen behalten, aber die übergeordnete Zeile löschen willst, ändere die untergeordneten Zeilen so, dass sie auf eine andere übergeordnete ID verweisen.

-- Reassign orders to a "General" customer account (ID 999)
UPDATE Orders SET CustomerID = 999 WHERE CustomerID = 501;

Ändere die Einschränkung: In seltenen Verwaltungssituationen kannst du Fremdschlüsselprüfungen vorübergehend deaktivieren. Das ist eine riskante Sache, die zu Datenproblemen führen kann, wenn man nicht super vorsichtig ist.

Datenbankspezifische Hinweise und Verhalten

Das Konzept der Einschränkung „ ON DELETE RESTRICT “ in SQL ist zwar in allen SQL-Datenbanken gleich, aber die verschiedenen Engines gehen mit dem Timing und der internen Logik ein bisschen unterschiedlich um.

Verhalten von PostgreSQL, MySQL und SQL Server

In PostgreSQL, MySQL und SQL Serververhindert die Einschränkung „ ON DELETE RESTRICT “, dass eine übergeordnete Zeile gelöscht wird, wenn es noch zugehörige untergeordnete Zeilen gibt. Allerdings haben diese Engines ein paar kleine Unterschiede in der Syntax:

MySQL: Hält sich strikt an die SQL- RESTRICT -Einschränkungen. Wenn du keine Regel angibst, wird standardmäßig „ RESTRICT “ verwendet.

-- MySQL: RESTRICT is the default if no rule is specified
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

PostgreSQL: Unterstützt sowohl Einschränkungen vom Typ „ RESTRICT “ als auch „ NO ACTION “. Obwohl sie fast gleich funktionieren, ist „ RESTRICT “ sofort ausgeführt, während „ NO ACTION “ eine verzögerte Überprüfung ermöglicht.

-- PostgreSQL: NO ACTION (can be deferred)
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE NO ACTION
);

SQL Server: Verwendet die Einschränkung „ NO ACTION “ als Äquivalent zum Standardverhalten „ RESTRICT “. Es benutzt das Schlüsselwort „ RESTRICT “ nicht direkt in seiner T-SQL-Syntax, macht aber dasselbe, indem es das Löschen verhindert.

-- SQL Server: Uses NO ACTION instead of RESTRICT
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE NO ACTION
);

Ich empfehle dir, unsere Kurse „Einführung in SQL Server“ und „Erstellen von PostgreSQL-Datenbanken“ zu besuchen, ummehr über die Unterschiede zwischen den SQL-Dialekten beim Erstellen von Datenbanken zu erfahren.

Aufgeschobene Einschränkungen und Transaktionsverhalten

In fortgeschrittenen Datenbankkonfigurationen wie PostgreSQL oder Oracle kann man auf verzögerte Einschränkungen stoßen. Das heißt, die Einschränkung wird beim Commit der Transaktion überprüft und nicht gleich, wenn die Anweisung „ DELETE “ ausgeführt wird.

In solchen Systemen kann es passieren, dass ein Löschvorgang, der normalerweise durch „ RESTRICT “ blockiert würde, innerhalb einer Transaktion vorübergehend erfolgreich erscheint, aber beim Versuch, die Transaktion zu committen, fehlschlägt. Das macht komplexe Vorgänge mit mehreren Schritten möglich, wie zum Beispiel das Löschen und erneute Einfügen von Daten innerhalb derselben Transaktion, und sorgt trotzdem dafür, dass am Ende alles korrekt ist.

Unsere Einführung in Oracle SQL hilft dir dabei, besser zu verstehen, wie Oracle Abfragen verarbeitet.

Die richtige ON DELETE-Strategie auswählen

Die richtige Einschränkung zu wählen hilft dir, ein Gleichgewicht zwischen Datenintegrität und Benutzerfreundlichkeit der Anwendung zu finden. Schau dir die folgenden Szenarien an, um die richtige Methode mit der Klausel „ ON DELETE “ zu finden.

Wenn RESTRICT die sicherste Wahl ist

Benutze die SQL- ON DELETE RESTRICT -Einschränkung, wenn:

• Die Daten sind echt wertvoll: Die übergeordneten Datensätze sind wichtig und werden in der Datenbank oft genutzt.

• Eine manuelle Überprüfung ist nötig: Du willst, dass ein Mensch oder ein bestimmter Geschäftslogikablauf entscheidet, was mit abhängigen Daten passiert.

• Verhindern von „stillen“ Löschungen: Du willst sichergehen, dass ein Entwickler nicht aus Versehen Tausende von Zeilen mit einem einzigen Befehl „ CASCADE “ löscht.

Ich schlage vor, du probierst mal den SQL Server für Datenbankadministratoren aus, wenn du regelmäßig Datenbanken entwirfst oder verwaltest. 

Wann man Alternativen in Betracht ziehen sollte

Wenn die Einschränkung „ RESTRICT “ für dein System zu streng ist, kannst du die folgenden Optionen in Betracht ziehen:

• Benutze die Einschränkung „ CASCADE “, wenn der untergeordnete Datensatz ohne den übergeordneten Datensatz keinen Sinn ergibt.

• Benutze die Einschränkung „ SET NULL “, wenn die Beziehung optional ist.

• Benutze die Einschränkung „ SET DEFAULT “, wenn du einen „Platzhalter“ hast, der alle verwaisten Datensätze übernehmen soll, damit das System reibungslos läuft.

Fazit

Die SQL-Einschränkung „ ON DELETE RESTRICT “ ist eine Schutzregel für Fremdschlüssel, die die Datenintegrität über die Benutzerfreundlichkeit stellt, indem sie das Löschen von übergeordneten Zeilen verhindert, wenn noch abhängige untergeordnete Datensätze vorhanden sind. Durch die Förderung von bewussten Bereinigungsstrategien und klaren Verantwortlichkeiten für Löschvorgänge fungiert die SQL- RESTRICT -Einschränkung als Sicherheitsfunktion im relationalen Design. Als bewährte Vorgehensweise solltest du SQL-Löschregeln immer nach der Geschäftslogik und der Datensemantik auswählen, statt dich einfach auf Bequemlichkeit oder kurzfristige Bedürfnisse zu verlassen.

Ich empfehle dir, unseren Kurs „Datenbankdesign“ zu machen. Da lernst du, wie man Datenbanken erstellt und verwaltet und das passende DBMS für deine Bedürfnisse auswählt. Ich empfehle dir auch, unseren Lernpfad „Associate Data Engineer in SQL“ auszuprobieren, um die Grundlagen des Data Engineering und Data Warehousing zu lernen.