Integritätsbedingung

Der Begriff Integritätsbedingung bezeichnet in der Informatik Bedingungen, die an den Zustand eines Prozesses oder einer Datenstruktur gestellt werden. In Bezug auf Datenbanken werden Zustände als konsistent bezeichnet, wenn sie die Integritätsbedingungen erfüllen.

Definition

Integritätsbedingungen beschreiben Annahmen, die über die Daten bzw. den Zustand getroffen werden, beispielsweise ein bestimmter Datentyp, ein Wertebereich oder eine Abhängigkeitsbeziehung zwischen zwei Objekten. Basierend auf diesen Annahmen kann ein Programmierer Verarbeitungsprozesse beschreiben und gegebenenfalls den Zustand eines Prozesses verändern. Die Einhaltung der Integritätsbedingungen sollte nicht dem Programmierer überlassen werden, sondern vom System geprüft werden. Inkonsistente Zustände (das heißt Zustände, die die Integritätsbedingungen verletzen) oder ungenau definierte Integritätsbedingungen sind häufige Ursachen für Programmierfehler, da die einzelnen Unterprogramme / Funktionen sich auf deren Einhaltung verlassen.

Beispiele

Datenbanken

Relationale Datenbanksysteme bieten die Möglichkeit, bei der Definition eines relationalen Schemas Integritätsbedingungen zu formulieren, deren Einhaltung von dem System garantiert wird. Ein typisches Beispiel für Integritätsbedingungen sind Schlüssel- und Fremdschlüsselbeziehungen.

Es lässt sich spezifizieren, auf welche Art die Einhaltung gewährleistet bzw. wie auf Änderungen reagiert werden soll. Eine Änderung, die eine Integritätsbedingung verletzt, kann entweder ganz unterbunden werden oder aber weitere Änderungen zur Wiederherstellung der Integrität nach sich ziehen (siehe hierzu: Datenbanktrigger). Das nachfolgende SQL-Beispiel modelliert auf stark vereinfachte Weise einen Zusammenhang zwischen Professoren, Studenten, Vorlesungen und Prüfungen. Das Augenmerk soll hier auf die Fremdschlüsselbeziehungen gelegt werden:

create table Professor (
  ID           integer primary key
);
create table Student (
  MatrNr       varchar(16) primary key
);
create table Vorlesung (
  ID           integer primary key,
  Name         varchar(32),
  Prof         integer references Professor.ID
               on delete set null
);
create table Prüfung (
  Datum        date,
  Vorlesung    integer not null
               references Vorlesung.ID
               on delete no action,
  Stud         varchar(16) not null
               references Student.MatrNr
               on delete cascade
);

Folgende Integritätsbedingungen werden in diesem Beispiel definiert:

→ Hauptartikel: Referentielle Integrität

• Eine Vorlesung referenziert einen Professor. Falls der Professor emeritiert (und der entspr. Datensatz gelöscht wird), bleibt die Vorlesung erhalten. Der Zusatz on delete set null löscht die Referenz auf den Professor, falls der referenzierte Datensatz gelöscht wird (Integritätsbedingung: der referenzierte Professor hält die Vorlesung).
• Jede Prüfung referenziert eine Vorlesung. Solange noch eine Prüfung für eine Vorlesung existiert, darf diese Vorlesung nicht aus der Datenbank gelöscht werden. Der Zusatz on delete no action verhindert, dass ein referenzierter Datensatz aus der Tabelle „Vorlesung“ gelöscht wird. (Integritätsbedingung: Zu jeder Prüfung gibt es auch eine Vorlesung).
• Jede Prüfung referenziert einen Studenten, der die Prüfung abgibt. Falls der Student exmatrikuliert (und der entspr. Datensatz gelöscht wird), findet auch die Prüfung nicht statt. Der Zusatz on delete cascade führt dazu, dass eine Prüfung gelöscht wird, falls der referenzierte Student gelöscht wird. (Integritätsbedingung: Ohne Student gibt es auch keine Prüfung).

Die Einhaltung dieser Bedingung gewährleistet die Datenbank.

Benutzerrechte

Naturgemäß schränkt die Spezifikation von Integritätsbedingungen die Zahl der erlaubten Operationen ein. Da sich in einer relationalen Datenbank diese Einschränkungen auch auf andere Tabellen auswirken können, als auf die konkrete Tabelle innerhalb derer die Bedingung spezifiziert wurden, gibt es in manchen Datenbanken eine spezielle Berechtigung, die es erlaubt eine erstellte Tabelle zu referenzieren. Im obigen Beispiel verhindert der Zusatz on delete no action das Löschen von Einträgen der Tabelle Vorlesung. Entsprechend muss der Besitzer der Tabelle Prüfung die Berechtigung besitzen, die Tabelle Vorlesung zu referenzieren.

Optimierung

Da die Einhaltung von Integritätsbedingungen innerhalb der Datenbank aufwändige Prüfungen zur Folge haben kann, wird zur Verbesserung der Laufzeiten, in den meisten Fällen, auf deren explizite Spezifikation verzichtet. Die Folge davon sind Datenschiefstände innerhalb der Datenbank. Die dazugehörende Software muss, je nach Anwendungsszenario, die verbliebenen inkonsistenten Daten innerhalb der Datenbank erkennen und berücksichtigen können. Wenn die Einhaltung der Bedingungen durch die Anwendung selbst nicht gewährleistet ist und der resultierende Datenschiefstand nicht umgangen werden kann, läuft die Software nicht fehlerfrei.

Dokumente

Eine Vielzahl von Integritätsbedingungen lassen sich auch im Kontext der Text- oder Dokumentenverarbeitung finden. Es leuchtet intuitiv ein, dass die Integrität eines Dokumentes verletzt ist, wenn das Inhaltsverzeichnis falsche Seitenzahlen beinhaltet oder Hyperlinks in HTML-Seiten ins Leere zeigen.

In formalisierter Form lassen sich Integritätsbedingungen für XML-Dokumente zum Beispiel durch XML-Schema beschreiben. Die folgende XML-Element Definition könnte zum Beispiel dazu dienen, einen neuen Element-Typ zu definieren der ausschließlich die Angaben der Körpertemperatur von Menschen zulässt. In diesem Fall 3 Dezimalstellen, 1 Nachkommastelle sowie Minimal- und Maximalwerte

<simpleType name="celsiusKörperTemp">
  <restriction base="xsd:decimal">
    <totalDigits value="3"/>
    <fractionDigits value="1"/>
    <minInclusive value="30.0"/>
    <maxInclusive value="42.5"/>
  </restriction>
</simpleType>

Siehe auch

• Constraint

Literatur

• Alfons Kemper, André Eickler: Datenbanksysteme. Eine Einführung. 5., aktualisierte und erweiterte Auflage. Oldenbourg, München u. a. 2004, ISBN 3-486-27392-2.
• Victor M. Markowitz: Safe Referential Structures in Relational Databases. In: Guy M. Lohman, Amílcar Sernadas, Rafael Camps (Hrsg.): Very large Data Bases. Proceedings of the Seventeenth International Conference on Very Large Data Bases. September 3–6, 1991, Barcelona (Catalonia, Spain). Kaufmann, San Mateo CA u. a. 1991, ISBN 1-55860-150-3, S. 123–132.

Weblinks

• Fremdschlüssel in MySQL 5.1, Beispiele zu MySQL 5.1
• Klassifizierung von Integritätsbedingungen und weitere Beispiele