GITTA-Logo
PDF Version of this document Search Help Glossary

Lesson Navigation IconRelationales Datenmodell

Unit Navigation IconKonzepte

Unit Navigation IconAbbildung ER-Schema

Unit Navigation IconDatenintegrität

LO Navigation IconSchlüsselintegrität

LO Navigation IconGegenstandsintegrität

LO Navigation IconReferentielle Integrität

LO Navigation IconIntegritätsgefährdung

Unit Navigation IconNormalisierung

Unit Navigation IconSommaire

Unit Navigation IconLittérature recommandée

Unit Navigation IconGlossaire

Unit Navigation IconBibliographie

Unit Navigation IconMéta-données


GITTA/CartouCHe news:


Go to previous page Go to next page

Referentielle Integritätsbedingung

Im Gegensatz zum GBM gibt es im relationalen Modell kein Konstrukt, mit dem Beziehungen zwischen Tupeln explizit modelliert werden können. Beziehungen werden hier implizit mit Hilfe des Primär-Fremdschlüssel-Konzepts dargestellt.

Fremdschlüssel:
Ein Attribut in einem Relationenschema R1 ist ein Fremdschlüssel wenn es in Beziehung zu einem Primärschlüsselattribut aus R2 steht und es gilt:
  • Die Domäne des Fremdschlüssels aus R1 ist identisch mit der Domäne des Primärschlüssels aus R2
  • Die Menge der Fremdschlüsselattributwerte von R1 muss eine Teilmenge der vorhandenen Primärschlüsselattributwerte von R2 sein.
Fremdschlüssel werden meist gestrichelt unterstrichen dargestellt.

Eine Beziehung zwischen zwei Relationen wird nun so hergestellt, dass die Domänen des Primärschlüssels der einen Relation in die zweite Relation als Fremdschlüsseldomänen (mit entsprechenden Attributen) aufgenommen werden.

Referentielle Integritätsbedingungen verlangen, dass aktuelle Fremdschlüsselwerte sich immer nur auf Primärschlüsselwerte von existierenden Tupeln beziehen.

Formal ausgedrückt heisst dies:

Gegeben sind:

  • Ein Tupel t1 einer Relation R1 mit dem SchemaR1=(A1, ..., Am, ...), wobei Ai die Primärschlüsselattribute sind.
  • Ein Tupel t2 einer Relation R2 mit dem Schema R2=(B1, B2, ..., Bn, ..., A1, ..., Am, ...), wobei Ai die Fremdschlüsselattribute sind.

Das Tupel t2 ist genau dann referentiell integer, wenn ein Tupel t1 existiert mit der Eigenschaft t1.Ai=t2.Ai (i=1, ..., m), oder wenn t2.Ai =NULL (i=1, ..., m) gilt.

Bildlich betrachtet, muss jedes Tupel der Fremdschlüsselrelation ein Tupel der Primärschlüsselrelation referenzieren (oder auf NULL gesetzt sein). Daher spricht man im Zusammenhang mit referentieller Integrität auch davon, dass keine "hängenden Referenzen" existieren dürfen (also Verweise auf etwas, das nicht existiert).

Das Relationenschema mit dem Fremdschlüssel wird als referenzierendes, das mit dem entsprechenden Primärschlüssel als referenziertes Relationenschema bezeichnet. Ein Fremdschlüssel kann dabei auch das eigene Relationenschema referenzieren. Die meisten der heutigen relationalen Datenbanksysteme unterstützen die automatische Einhaltung der referentiellen Integrität, zum Teil sogar schon PC-basierte Systeme.

Beispiel Referentielle IntegritätBeispiel Referentielle Integrität

Die Tabelle Abteilung hat die Abteilungsnummer als Primärschlüssel. Dieser wird in der Tabelle Mitarbeiter als Fremdschlüssel verwendet, um die Abteilungszugehörigkeit eines Mitarbeiters zu fixieren. Die Fremd-Primärschlüssel-Beziehung erfüllt die Regel der referentiellen Integrität, falls alle Abteilungsnummern des Fremdschlüssels aus der Tabelle Mitarbeiter in der Tabelle Abteilung als Primärschlüsselwerte aufgeführt sind. In unserem Beispiel ist also die Regel der referentiellen Integrität nicht verletzt.

Nehmen wir an, wir möchten in die Tabelle Mitarbeiter, ein neues Tupel "Id: 4, Weber, A5" einfügen. Unsere Einfügeoperation wird abgewiesen, falls das Datenbanksystem die referentielle Integrität unterstützt. Der Wert A5 wird nämlich als ungültig erklärt, da er in der referenzierten Tabelle Abteilung nicht vorkommt.

Top Go to previous page Go to next page