Integritätstypen

Stell dir einen Aktenschrank im Büro vor in den jeder Mitarbeiter reinwerfen darf was er will – ohne Beschriftung, doppelte Akten, halb ausgefüllte Formulare, Verweise auf Akten die längst geschreddert wurden. Nach drei Monaten ist das Chaos perfekt: man findet nichts, niemand vertraut den Daten und jede Auswertung produziert Unsinn. Genau dieses Chaos verhindert eine Datenbank, wenn sie richtig konfiguriert ist.

Das Schlagwort dafür heißt Datenintegrität: die Eigenschaft, dass alle Daten in einer Datenbank korrekt, vollständig, eindeutig und in sich widerspruchsfrei sind – und auch bleiben, egal wer was wann einfügt oder ändert. Das Schöne: das DBMS (Database Management System) übernimmt das Wachen automatisch. Du definierst beim Anlegen einer Tabelle die Regeln (sogenannte Constraints), und ab dann lehnt die Datenbank jeden Einfüge- oder Änderungsversuch ab, der die Regeln bricht. Diese Lektion zeigt dir welche Regeln das sind – die vier klassischen Integritätstypen.

1) Was Datenintegrität konkret bedeutet

Datenintegrität ist kein einzelnes Feature, sondern eine Zusicherung mit mehreren Dimensionen. Eine Datenbank gilt als integer wenn vier Bedingungen gleichzeitig gelten:

• Eindeutigkeit – jede Entität (jeder Kunde, jede Bestellung, jeder Artikel) ist genau einmal vorhanden und unterscheidbar.
• Konsistenz von Beziehungen – wenn eine Entität auf eine andere verweist, existiert das Ziel auch wirklich. Keine „Leerverweise".
• Wertkorrektheit – ein Geburtsdatum ist ein Datum, ein Preis ist eine Zahl, ein Geschlecht hat nur erlaubte Ausprägungen.
• Fachliche Plausibilität – Werte ergeben auch im Kontext deines Geschäfts Sinn (negative Lagerbestände z.B. sind technisch eine Zahl, fachlich aber Unfug).

Genau diesen vier Dimensionen entsprechen die vier Integritätstypen die wir gleich durchgehen. Vor jeder schreibenden Operation prüft das DBMS automatisch: passen die neuen Daten zu allen definierten Constraints? Wenn nein, wird der Vorgang abgewiesen – mit einer Fehlermeldung, nicht mit stillem Wegspeichern. Das ist auch der Grund warum diese Regeln im Datenbankschema stehen sollten und nicht (nur) in deinem Anwendungscode: das DBMS ist die letzte Verteidigungslinie, egal welcher Client schreibt.

2) Die vier Integritätstypen im Überblick

Die vier Typen unterscheiden sich darin was sie schützen. Klick eine Karte um Definition, Regel und ein Beispiel zu sehen:

3) Entitätsintegrität – jede Zeile muss eindeutig sein

„Entität" ist Datenbank-Sprech für „ein Ding" – ein Kunde, eine Bestellung, ein Produkt. Die Entitätsintegrität verlangt: jedes Ding in deiner Tabelle muss eindeutig identifizierbar sein. Sonst weißt du nie ob du Kunde Müller bearbeitest oder versehentlich seinen Doppelgänger. Umgesetzt wird das mit dem Primärschlüssel (Primary Key), den wir in Lektion 2 noch im Detail anschauen.

Ein Primärschlüssel ist eine Spalte (oder Kombination mehrerer Spalten) die in jeder Zeile garantiert vorhanden ist (also NOT NULL) und einmalig (UNIQUE). Diese zwei Bedingungen sind die Entitätsintegrität. Was passiert wenn man dagegen verstößt:

4) Referenzielle Integrität – Beziehungen müssen halten

Selten steht eine Tabelle für sich allein. Bestellungen gehören zu Kunden, Bestellpositionen zu Bestellungen, Kommentare zu Beiträgen. Solche Beziehungen modelliert man mit Fremdschlüsseln (Foreign Keys): eine Spalte in Tabelle A verweist auf den Primärschlüssel in Tabelle B (siehe auch Kardinalitäten in K34).

Die referenzielle Integrität garantiert: ein Fremdschlüssel zeigt nie auf eine nicht-existierende Zeile. Wenn eine Bestellung „Kunde 42" referenziert, muss Kunde 42 auch wirklich existieren. Andernfalls hättest du eine verwaiste Zeile (orphan row): eine Bestellung ohne Besitzer. Hier siehst du den Unterschied:

5) Domänenintegrität – nur erlaubte Werte

„Domäne" meint hier den Wertebereich einer Spalte. Eine Spalte alter ist eine Ganzzahl, vermutlich zwischen 0 und 150. Eine Spalte email ist Text mit @-Zeichen. Eine Spalte status nimmt vielleicht nur die drei Werte 'aktiv', 'inaktiv', 'gesperrt' an. Die Domänenintegrität sorgt dafür dass nur Werte aus dem erlaubten Bereich in die Spalte kommen.

Drei Mechanismen tragen dazu bei, alle drei lernst du beim Tabellen-Erstellen mit SQL kennen:

• Datentyp – durch die Wahl von INT, VARCHAR(50), DATE, DECIMAL(10,2) usw. legst du fest welche Art von Wert überhaupt erlaubt ist. Ein INT-Feld nimmt schlicht keinen Text an.
• NOT NULL – wenn ein Feld immer einen Wert haben muss (z.B. Nachname eines Kunden), markiert man es als NOT NULL. Ein Insert ohne diesen Wert schlägt fehl.
• CHECK-Constraints – feinere Regeln für den Wertebereich. Beispiele: CHECK (alter >= 18), CHECK (status IN ('aktiv', 'inaktiv', 'gesperrt')), CHECK (preis > 0).

Zusätzlich gibt es UNIQUE (jeder Wert nur einmal, aber im Gegensatz zum Primary Key sind NULL-Werte erlaubt) und DEFAULT (Vorgabewert wenn keiner mitgegeben wird). Das ist die alltäglichste Form von Integrität – fast jede Spalte hat irgendeine Form von Domänen-Constraint.

6) Benutzerdefinierte Integrität – die Geschäftsregeln

Manche Regeln kann das DBMS nicht aus dem Schema ableiten – sie ergeben sich aus deinem konkreten Geschäftsfall. Ein paar Beispiele aus der Praxis:

• „Ein Mitarbeiter darf pro Jahr maximal 30 Urlaubstage haben."
• „Die Summe einer Bestellung muss gleich der Summe aller Bestellpositionen sein."
• „Ein Lager darf nicht mehr Ware ausweisen als physisch passt."
• „Ein Kunde ohne aktive Mitgliedschaft darf keine Premium-Inhalte kaufen."

Diese benutzerdefinierten (oder semantischen) Constraints kennt die Datenbank nicht von selbst. Es gibt zwei Strategien sie durchzusetzen: im DBMS per CHECK-Constraint, Trigger oder Stored Procedure – oder in der Anwendung, also dem Programmcode der die Datenbank benutzt. Die saubere Lösung kombiniert beide: die wichtigsten Invarianten als Datenbank-Constraint (damit sie wirklich nie verletzt werden, egal welcher Client schreibt), die feineren Geschäftslogiken in der Applikation.

7) DBMS als Türsteher – probier's mal aus

Wir spielen jetzt die andere Seite: du bist ein bösartiger Client und versuchst, Müll-Daten in eine sauber konfigurierte Datenbank zu schmuggeln. Klick einen der Angriffe und sieh wie das DBMS reagiert:

8) Detektiv-Modus: Welcher Integritätstyp wurde verletzt?

Jetzt du. Sechs Szenarien aus der Praxis – jeweils geht's schief, und du musst entscheiden welcher der vier Integritätstypen verletzt wurde. Klick die Antwort die deiner Meinung nach passt:

9) Konsequenzen: Datenbank mit vs. ohne Integrität

Zum Abschluss der Vergleich. Was unterscheidet eine Datenbank mit ordentlich konfigurierten Constraints von einer ohne? Auf den ersten Blick: in beiden stehen Daten. Auf den zweiten Blick wird der Unterschied dramatisch:

Zusammenfassung

Datenintegrität ist die Eigenschaft, dass Daten in einer Datenbank korrekt, eindeutig, konsistent und plausibel sind – und vom DBMS auch so erhalten werden. Vier Integritätstypen: Entitätsintegrität (jede Zeile eindeutig identifizierbar via Primary Key, automatisch NOT NULL + UNIQUE), referenzielle Integrität (Foreign Keys verweisen nur auf existierende Zeilen, Verhalten beim Löschen/Ändern via ON DELETE/ON UPDATE), Domänenintegrität (nur Werte aus dem erlaubten Wertebereich – durch Datentyp, NOT NULL, CHECK, UNIQUE), benutzerdefinierte Integrität (Geschäftsregeln, die das DBMS nicht von selbst kennt – via CHECK, Trigger, Stored Procedures oder in der Anwendung). Constraints werden im Schema definiert (CREATE TABLE) und vom DBMS bei jedem Insert/Update geprüft. Ohne Integrität: Datenchaos. Mit Integrität: verlässliche Datengrundlage.