Unter dem Oberbegriff Datenintegrität versteht man die Konsistenz, Fehlerlosigkeit und Richtigkeit der in einer Datenbank gespeicherten Daten. Dabei geht es nicht um physikalische Sicherheit, Fehlertoleranz oder Datensicherungen. Bildlich gesprochen geht es bei Datenintegrität darum, den Müll aus einer Datenbank fernzuhalten. Man unterscheidet vier Arten von Datenintegrität

1. Entitätsintegrität
2. Domänenintegrität
3. Referentielle Integrität
4. Benutzerdefinierte

Ganz allgemein gesprochen wird Entitätenintegrität auf Zeilenebene, Domänenintegrität auf Spaltenebene und referentielle Integrität auf Tabelleneben angewendet. Nachfolgend sollen die grundlegenden Konzepte von Datenintegrität diskutiert werden. Datenintegrität kann auf Datenbankebene und/oder auf Applikationsebene implementiert werden. Zum Beispiel könnte eine Applikation Dateneingaben in ihre Oberfläche validieren, bevor diese an den Datenbankserver gesendet werden. Hingegen hat die Implementierung von Datenintegritätsregeln auf Datenbankebene zweifelsohne den Vorteil der Unabhängigkeit von einer externen Applikation. Gleichzeitig wird auch der Dnwendungsentwickler entlastet, da er sich um viele Aspekte der Datenintegrität in seinem Programm keine Gedanken zu machen muss.

Datenintegrität in der Applikation zu kodieren kann folgende mehr oder weniger schwerwiegende Probleme mit sich bringen.

1. zusätzlichen Programmieraufwand
2. Inkonsistenzen und potentielle Fehler
3. Anderungen werden schwerer durchführbar
4. Geringere Sicherheit, d.h. sie ist leicher zu umgehen

Datenintegrität lässt sich auf zwei verschiedene Arten in SQL Server implementieren.

• Deklarativ
• Prozedural

Entitätenintegrität

Entitätenintegrität stellt sicher, dass jede Zeile einer Tabelle sich eindeutig identifizieren lässt, also zwei vollkommen identische Zeilen ausschliesst. Solange dies aber nicht explizit angegeben wird,
lässt SQL Server dies zu. Entitätenintegrität ist eines der Schlüsselkonzepte in der relationalen Datenbanktheorie. Daten in einer relationalen Datenbank sind unabhängig von ihrem physikalischen Speicherort. Dies wird erreicht durch das Vorhandensein der Möglichkeit, jede einzelne Zeile durch einen einzigen Wert zu referenzieren, der oft auch Schlüssel genannt wird. Entitätenintegrität nun stellt sicher, dass jede Zeile einen eindeutigen Identifizierer hat, der die Unterscheidung ermöglicht. Die wohl gebräuchlichste Erzwingung von Entitätenintegrität erfolgt wohl durch Platzierung einer Primärschlüssel (PK) Einschränkung (PrimaryKey Constraint) auf eine oder mehrere Spalten einer Tabelle.

Weitere Möglichkeiten wären eine UNIQUE Einschränkung, ein eindeutiger Index oder die IDENTITY Eigenschaft.

Die Primärschlüsseleinschränkung zwingt jeden Wert,der in eine Spalte eingegeben werden soll,
oder in eine Kombination von Spalten eingegeben werden soll, eindeutig zu sein. Der Versuch eine doppelten, nicht eindeutigen Wert einzugeben, wird einen Fehler auslösen und die INSERT Operation scheitern lassen.

Der PK verbietet auch jegliche NULL Wert Eingaben in seinen Spalten, auch wenn es die erste und einzige NULL Wert Eingabe wäre. Der PK kann auch als Surrogate Key bezeichnet werden, wenn anstelle von Benutzergenerierten Daten nur ein eindeutiger Bezeichner verwendet wird. Werden hingegen Benutzergenerierte Daten als PK verwendet, spricht man von einem intelligenten Schlüssel. Jede Tabelle kann nur einen einzigen PK enthalten. Ein PK hingegen kann sich auch aus mehreren Spalten zusammensetzen. Solch einen PK würde man bilden, wenn keine einzelne Spalte des PK für sich selbst einmalig wäre. Für den Fall, dass man die Einmaligkeit für mehr als
einen Spalte durchsetzen muss, empfiehlt es sich, eine PK Einschränkung auf eine Spalte zu setzen und eine UNIQUE oder IDENTITY Einschränkung auf jede andere Spalte, die keine Duplikate enthalten darf. Nicht PK Spalten für die Einmaligkeit erzwungen wird, werden Alternativschlüssel (Alternative Keys AK) genannt. Durch diese Bezeichnung wird im Grunde schon die Tatsache ausgedrückt, dass sie Alternativen zum PK sind, welches sie auch zu guten Kandidaten für JOIN Operationen macht

Domänenintegrität

In der Datenbanksprache wird unter einer Domäne eine Reihe oder ein Satz von erlaubten Werten für eine Spalte verstanden. Domänenintegrität definiert die erlaubten Eingaben in eine Spalte, den Datentyp, die Bandbreite oder auch das Eingabeformat.

Ein anderer Begriff für Domänenintegrität ist auch Attributintegrität.

Domänenintegrität kann durch DEFAULT Einschränkungen, FOREIGN KEY, CHECK Einschränkungen, Datentypen oder auch durch Regeln oder datenbankweite DEFAULT erzwungen werden

Referentielle Integrität

Referentielle Integrität befasst sich damit, die Relationen zwischen den Tabellen sychronisiert zu halten. Typischerweise wird sie durch eine PK-FK Kombination erzwungen. Während der P bereits weiter oben erläutert wurde, besteht ein Fremdschlüssel oder FK ebenfalls aus ein oder mehreren Spalten in einer Tabelle, die oft auch als Child Tabelle bezeichnet wird. Diese Spalte(n) erhalten (erben) ihren Wert vom PK in einer anderen Tabelle, die in diesem Zusammenhang oft auch als Parent Tabelle bezeichnet wird. Ist erst einmal die Relation eingerichtet, ist es möglich, jeden Eintrag in einer Child Tabelle einem bestimmten Eintrag in der Parent Tabelle zuzuordnen. Zwar repräsentieren PK-FK Kombinationen logische Zusammenhänge, durch sie wird aber nicht
notwendigerweise die möglichen Zugriffspfade auf die Daten eingeschränkt. Eine Grundvoraussetzung für die Sicherstellung referentieller Integrität ist, dass der FK in der Child
Tabelle nur solche Werte akzeptieren kann, die als PK in der Parent Tabelle existieren. Damit wird auch das Hauptziel referentieller Integrität deutlich. Es sollen 'verwaiste' Daten verhindert werden, d.h. Zeilen in der Child Tabelle, die nicht zu einer Zeile in der Parent Tabelle in Beziehung gesetzt werden können. Die Erzwingung referentieller Integrität muss sich erstrecken auf das Hinzufügen neuer Daten (INSERT), die Veränderung bestehender Daten (UPDATE) und das Löschen von Daten (DELETE). Obwohl zwar die PK-FK Kombination der wahrscheinlich gebräuchlichste Weg ist, RI durchzusetzen, stehen dem Datenbankentwickler mit dem Einsatz von Triggern und gespeicherter Prozeduren weitere Möglichkeiten zur Verfügung.

Gefahren für die Referentielle Integrität (RI)

Die Datenaktualisierungsgefahr (UPDATE)

Datenaktualisierungen stellen insofern eine Geafhr für die RI dar, wenn der PK und/oder der FK dieser Aktualisierung betroffen sind. Um auch weiterhin RI zu gewährleisten, kann ein solches UPDATE unzulässig deklariert werden, indem der FK den PK referenziert. Alternativ könnte das UPDATE kaskadierend durchgeführt werden. Der Vollständigkeit halber soll hier noch als dritte Möglichkeit angeführt werden, bei der UPDATE Operation, den FK auf NULL zu setzen, sobald sich der PH ändert. Aus einleuchtenden Gründen ist dies im allgemeinen keine empfehlenswerte Lösung.

Die Datenneueingabegefahr (INSERT)

Diese Gefahr besteht nur für Dateneingaben in die Child Tabelle. Sie besteht darin, dass Daten in die Child Tabelle eingegeben werden, denen kein Datensatz in der Parent Tabelle zugeordnet werden kann. Das Ergebnis sind verwaiste Daten. Hier gibt es zwei Möglichkeiten, dieser Gefahr zu begegnen.

1. Die INSERT Operation wird als unzulässig deklariert. Dies erfolgt automatisch wenn der FK den PK referenziert.
2. wie bereits erwähnt, kann der FK auf NULL gesetzt werden. Auch hier keine gute Idee.

INSERTS können nicht kaskadierend durchgeführt werden.

Die Datenlöschgefahr (DELETE)

Diese Art von Gefahr betrifft nut Daten in der Parent Tabelle und besteht darin, dass, wenn Daten aus der Parent Tabelle gelöscht werden, zu denen Daten aus der Child Tabelle logisch gehören, wieder als Ergebnis verwaiste Daten entstehen.

Wie bei UPDATE Operationen gibt es auch bei DELETE Operationen drei Arten, diese zu verhindern. Nähere Erläuterungen finden sich bei UPDATE.

Benutzerdefinierte Datenintegrität

Hierunter versteht man spezielle Geschäftsregeln, die nicht durch die drei anderen Mechanismen abgedeckt werden. Vorzugsweise wird diese Art von Datenintegrität durch Trigger oder Gespeicherte Prozeduren sichergestellt.

Datenintegrität implementieren

Wie bereits zu Anfang erwähnt, gibt es generell zwei verschiedene Ansätze, um Datenintegrität zu implementieren.

Deklarative Datenintegrität

Sie stellt Datenintegrität primär durch CONSTRAINTS dar, indem die CONSTRAINTS auf die entsprechenden Spalten deklariert werden.

Beispiele für CONSTRAINTS sind:

• UNIQUE
• FK REFERENCES
• CHECK
• DEFAULT

Deklarative Datenintegrität unterstützt alle Arten von Datenintegrität. Sie wird definiert, wenn die
Tabelle erstellt oder geändert witd. Sie hat weniger Overhead und ist weniger fehleranfällig als
Prozedurale Datenintegrität.

Ein Sonderfall stellt die Deklarative Referenzielle Integrität (DRI) dar, die automatisch Datenintegrität durchsetzt, indem sie alle Datenmodifikationen zurückweist, die eine Verletzung der Integrität zur Folge hätten.

Prozedurale Datenintegrität

Sie setzt Datenintegrität hauptsächlich durch Views, Trigger und Gespeicherte Prozeduren durch. Der Vorteil dieses Ansatzes ist zweifelsohne die grössere Flexibilität bei der Durchsetzung von Datenintegrität. Dies hat allerdings seinen Preis in dem höheren Grad an Fehleranfälligkeit und höherem Overhead. Referentielle Aktionsintegrität (RAI) stellt Datenintegrität durch Views, Trigger und Gespeicherte Prozeduren sicher.

Kurze Erläuterung des Begriffs 'Kaskadierend'

Eine kaskadierende UPDATE oder DELETE Operation bedeutet, dass die Datenmodifikationen in einer Tabelle automatisch auf die verwandten Tabellen ausgeweitet werden. So führt ein kaskadierendes UPDATE dazu, dass die Datenänderung in Schlüsselfeldern einer Parent Tabelle automatisch auch eine Datenaktualisierung in dem Feld der Child Tabelle auslöst.