Referentielle Integrität

2025-02-05T13:23:29Z

193.158.248.56: /* Nachteile */

'''Referentielle Integrität''' ('''RI''') ist ein Begriff aus der [[Informatik]]. Man versteht darunter Bedingungen, die zur Sicherung der [[Konsistenz (Datenspeicherung)#Konsistenz in klassischen relationalen Datenbanken|Datenintegrität]] bei Nutzung [[Relationale Datenbank|relationaler Datenbanken]] beitragen können. Nach der RI-Regel dürfen Datensätze (über ihre [[Fremdschlüssel]]) nur auf existierende Datensätze verweisen.

Danach besteht die RI grundsätzlich aus zwei Teilen:<ref>Albrecht, Nicol: ''Access 2002 programmieren''. ISBN 3-8273-1942-0</ref>
# Ein neuer Datensatz mit einem Fremdschlüssel kann nur dann in einer Tabelle eingefügt werden, wenn in der referenzierten Tabelle ein Datensatz mit entsprechendem Wert im [[Schlüssel (Datenbank)#Primärschlüssel und Alternativschlüssel|Primärschlüssel]] oder einem eindeutigen [[Schlüssel (Datenbank)#Primärschlüssel und Alternativschlüssel|Alternativschlüssel]] existiert.
# Eine Datensatzlöschung oder Änderung des [[Schlüssel (Datenbank)|Schlüssels]] in einem Primär-Datensatz ist nur möglich, wenn zu diesem Datensatz keine abhängigen Datensätze in Beziehung stehen.

== Definitionen ==
„Die referentielle Integrität (auch '''Beziehungsintegrität''') besagt, dass Attributwerte eines Fremdschlüssels auch als Attributwert des Primärschlüssels vorhanden sein müssen.“<ref>{{Internetquelle |url=https://www.wirtschaftsinformatik-24.de/datenbanken/referentielle-integritaet.php |titel=Referentielle Integrität |abruf=2020-12-04 |werk=Wirtschaftsinformatik-24}}</ref>

„Über die referentielle Integrität werden in einem [[Datenbank|DBMS]] die Beziehungen zwischen Datenobjekten kontrolliert.“

== Begriffe und ihre Bedeutung ==
''Ursprung/Hintergrund:'' Nach der [[Relationale Datenbank|Relationentheorie]] werden zu speichernde Daten i. d. R. auf mehrere Tabellen aufgeteilt. Die Datensätze dieser Tabellen weisen untereinander meist logische Zusammenhänge (Beziehungen) auf. Siehe [[Relationale Datenbank#Beziehungen zwischen Tabellen|Beispiel „Bücherei“]]: Buch X ist entliehen von Büchereibenutzer Y. Daraus entstand die Anforderung, die Konsistenz dieser „Referenzen“ bei Bedarf durch ein besonderes und sicheres Konzept (die „RI“) schützen zu können.

Nach der wörtlichen Bedeutung bezeichnet „RI“ einen gegebenen oder beabsichtigten ''Qualitätszustand'' von Daten: Integer (''makellos, heil, „ganz“''<ref>Duden ''Herkunftswörterbuch''</ref>) im Hinblick auf die darin enthaltenen gegenseitigen Referenzen. Gleichzeitig versteht man unter „RI“ jedoch auch die ''Integritätsregel'' bzw. die funktionale Unterstützung, durch die ein DBMS diese Qualität sichert.

Die RI-Regel ist eine Erweiterung bei der ''[[Spezifikation]] von [[Entity-Relationship-Modell|Beziehungstypen]]'' – die meist eine [[Kardinalität (Datenbankmodellierung)|Kardinalität]] von ''1:n'' aufweisen. Die darin beteiligten [[Entity-Relationship-Modell|Entitätstypen]] (= [[Tabelle]]n) bezeichnet man – rollenspezifisch für genau einen Beziehungstyp, nicht generell für die Tabelle geltend – als ''Mastertabelle'' und ''Detailtabelle''. Wirksam sind diese Festlegungen für die in konkreten Beziehungen stehenden Datensätze. Master- und Detailtabelle kann auch dieselbe Tabelle sein (rekursive Beziehungen).

''Andere Bezeichnungen für Mastertabelle'' sind Primär-, Parent-, Eltern-<ref>Uni Frankfurt {{Webarchiv|url=http://www.dbis.informatik.uni-frankfurt.de/downloads/teaching/DB-Vorlesung/2007_2008_WS/07d_referentielle_integritaet_in_sql.pdf |wayback=20160225065405 |text=dbis.informatik.uni-frankfurt.de |archiv-bot=2024-04-24 00:34:08 InternetArchiveBot }} (PDF; 85 kB)</ref> oder referenzierte Tabelle. Die ''Detailtabelle'' wird auch verknüpfte*, Child/Kind-, abhängige, verwandte*, referenzierende, verweisende Tabelle<ref>
{{Webarchiv |url=http://msdn.microsoft.com/de-de/library/aa292166%28v=vs.71%29.aspx |wayback=20120116105325 |text=msdn.microsoft.com Microsoft ''MSDN''}}</ref> oder „Tabelle mit dem Fremdschlüssel“ genannt.<br />
<small>(*) = begrifflich eher ungeeignet, weil das Abhängigkeitsverhältnis unklar bleibt.</small>

Ein klassischer Fall für RI-Spezifikationen inkl. Löschweitergabe sind sog. ''Beziehungstabellen'', die häufig nur die Fremdschlüssel der an einer [[Kardinalität (Datenbankmodellierung)#UmsetzungRelDM|n:m-Beziehung]] beteiligten Datensätze enthalten. Verweise auf nicht existente Primärdatensätze darf es hier nicht geben; wird einer der beiden Primärdatensätze gelöscht, so kann/muss auch der Datensatz in der Beziehungstabelle gelöscht werden.

''Abgekürzt'' wird der (etwas sperrige) Begriff „referentielle Integrität“ (im Englischen “referential Integrity”) häufig mit '''RI oder R.I.''', auch wird verbreitet die neue deutsche Rechtschreibung (referenziell mit „z“) verwendet.

'''Abgrenzung:'''<br />
* Neben der referentiellen Integrität kennt man (als Teilaspekte von [[Datenqualität]] und -Konsistenz) weitere [[Integritätsbedingung]]en wie die ''Wertebereichsintegrität'' (gültige Werte auf Datenfeldebene), die ''[[Eindeutigkeit]] von [[Schlüssel (Datenbank)|Schlüsselbegriffen]]''. Darüber hinaus sichern Datenbanksysteme vor allem im [[Mehrbenutzersystem|Mehrbenutzerbetrieb]] die Konsistenz von Daten auf ''[[Transaktion (Informatik)|Transaktionsebene]]'' (alle oder keine Updates, z. B. bei technischem Abbruch) sowie gegen Updates ''konkurrierender Benutzer/Transaktionen''.
* RI-ähnliche Konsistenzbedingungen in nicht relational gespeicherten Datenbeständen fallen nicht unter den Begriff 'referentielle Integrität', sondern werden mit anderen Mitteln überprüft, z. B. individuell in der IT-Anwendung. Beispiel: Daten in Konfigurations und [[Registrierungsdatenbank|Registrydateien]], [[Hyperlink]]s in [[Wiki]]s etc.

== Erweiterungen / Besonderheiten ==
Während die RI grundsätzlich vor inkonsistenten Datenaktionen schützt, bieten viele Datenbanksysteme Zusatzfunktionen an, die bei Updates von Master-Datensätzen nützlich sein können:

; Änderungsweitergabe (ÄW)
: Wenn der eindeutige Schlüssel eines Datensatzes geändert wird, kann das DBMS die Fremdschlüssel in allen abhängigen Datensätzen anpassen – anstatt die Änderung abzulehnen. Änderungsweitergabe wird insbesondere dann benutzt, wenn [[Schlüssel (Datenbank)#Anderweitige Begriffsverwendungen|natürliche Schlüssel]] (die sich ändern können; Familienname bei Heirat) verwendet werden; denn [[Surrogatschlüssel|künstliche Schlüssel]] sind i. d. R. unveränderlich und eine Änderungsweitergabe nicht erforderlich.
; Löschweitergabe (LW)
: In bestimmten Fällen ergibt es einen Sinn, abhängige Datensätze bei Löschung des Masterdatensatzes mitzulöschen.
Diese Funktionen können in der RI-Spezifikation optional gesetzt und (je nach DBMS) durch zusätzliche Bedingungen (siehe [[Integritätsbedingung#Beispiele|Beispiel]]) erweitert/präzisiert werden. Sie wirken nur bei Updates von Masterdatensätzen, Detaildaten können jederzeit gelöscht oder anderen (vorhandenen) Mastersätzen zugeordnet werden.

Weitere Besonderheiten im Zusammenhang mit der RI sind:

; Rekursive Beziehungen
: Die RI kann sich auch auf Daten in nur einer Tabelle beziehen, etwa wenn sich in der Tabelle ABTEILUNG Unterabteilungen ihrer gemeinsamen Hauptabteilung zuordnen.
; Kaskadierung
: Wenn die abhängigen Datensätze aus einer RI-Beziehung selbst wiederum Primärdatensatz sind, kann sich die RI-Regel auch auf deren abhängige Sätze beziehen. Eine Lösch- oder Änderungsweitergabe kann also mehrstufig wirken.
; Beziehung auf sich selbst
: In bestimmten Situationen kann ein Detaildatensatz auch auf sich selbst verweisen. Beispiel: Die Beziehung „Ort gehört zu Kreisstadt“ in der Tabelle ORT: Der Datensatz des Ortes, der die Kreisstadt ist, verweist mit dem Fremdschlüssel „Kreisstadt“ auf sich selbst. In solchen Fällen wird jedoch häufig auch ein Nullwert verwendet – was als „ist selbst Kreisstadt“ interpretiert werden kann.

== Handlungs- und Wirkungsebenen ==
[[Datei:RI-Spezifik Access.png|miniatur|RI-Einstellung bei MS Access (2003)]]
Die RI wird im Verlauf der ''[[Datenmodellierung]]'' als relevant erkannt, festgelegt und in der jeweiligen [[Syntax]] spezifiziert. Dies geschieht je ''Beziehungstyp'' (häufig vereinfachend nur „Beziehung“ genannt), an dem jeweils mehrere Entitätstypen (= Tabellen) beteiligt sind. Die Spezifikationen sind Teil des einmalig erstellten [[Datenbankschema]]s.

Aufgrund dieser Angaben überprüft das DBMS bei der ''Ausführung'' von [[CRUD|ändernden]] Datenoperationen im laufenden Betrieb die Einhaltung der RI-Regeln. Solche Operationen werden von IT-Anwendungen (ggf. nach einer [[Eingabe und Ausgabe|Eingabe bzw. Erfassung]] von [[Benutzer]]n) ausgelöst und führen bei Einhaltung der Regeln zu Veränderungen im Datenbestand, ansonsten zu Fehlermeldungen bei unverändertem Bestand.

== Beispiel ==
[[Datei:Ref Integr Bsp.png|miniatur|Beispiele für RI-Einstellungen]]
Die nebenstehende Grafik zeigt am Beispiel eines einfachen [[Entity-Relationship-Diagramm|ER-Diagramms]], welche Überlegungen im Zusammenhang mit der Festlegung von RI-Regeln angestellt werden können:
* Wenn es möglich ist, dass sich der Primärschlüssel von „KUNDEN-Einträgen“ ändert, sollten auch die in BESTELLUNG enthaltenen Fremdschlüssel automatisch mitgeändert werden: RI mit Änderungsweitergabe.
* Wenn ADRESSEN immer nur zu genau einem KUNDEN gehören, ergibt es einen Sinn, diese bei Löschung des KUNDEN (d. h. der Daten über ihn) automatisch mitzulöschen: RI mit Löschweitergabe.
* Da sich BESTELLUNGEN immer auf ARTIKEL beziehen (über „Bestell-Position“), muss verhindert werden, dass ein ARTIKEL im Datenbestand gelöscht wird, wenn noch BESTELLUNGEN (mit Positionen) vorhanden sind. Umgekehrt dürfen nur solche Bestellpositionen angelegt werden, die sich auf einen (im Datenbestand) existenten ARTIKEL beziehen: Normale RI ohne LW/ÄW.
* Wenn Löschweitergabe in der Beziehung „KUNDE:BESTELLUNG“ nicht definiert ist, würde die Löschung eines KUNDEN bei Existenz von BESTELLUNGEN (dieses Kunden) abgelehnt werden. Wäre Löschweitergabe spezifiziert, so würde im Fall der Kundenlöschung ein „kaskadierendes Löschen“ (inkl. Bestellposition) eintreten.
* Ohne jegliche RI-Spezifikation müsste die [[Anwendungssoftware|Anwendung]] / der [[Benutzer]] selbst für die Konsistenz der Datenbeziehungen Sorge tragen; sonst könnten inkonsistente Daten entstehen, die zur Folge hätten, dass in der automatischen Verarbeitung dieser Daten z. B. keine Versand-ADRESSE und kein Rechnungsempfänger (Kunde) bekannt wäre.

== DBMS-abhängige Unterschiede ==
Der Umfang an Unterstützung zur RI, den Datenbanksysteme leisten können, kann unterschiedlich sein. Neben der Grundfunktion, die RI überhaupt zu schützen, kann das zum Beispiel die folgenden Zusatzaspekte betreffen:
* Löschweitergabe, Änderungsweitergabe
* kaskadierende Lösch- oder Änderungsweitergabe
* zusätzliche Bedingungen, unter denen die Lösch- und Änderungsweitergabe erfolgen soll
* RI über die Daten mehrerer Datenbanken hinweg.

== RI-Darstellung in Datenmodellen / Diagrammen ==
Zur Darstellung der referentiellen Integrität in Datenmodellgrafiken werden kaum einheitliche Regeln angewendet. In manchen Modell-Werkzeugen wird der Beziehungspfeil bei RI fett dargestellt. Zusatzfunktionen wie Löschweitergabe sind meist nur textuell in den spezifizierten Beziehungstypen bzw. im [[Quellcode]] des Datenbankschemas sichtbar.

== Technische Umsetzung ==
Technisch wird die referentielle Integrität über einen so genannten Fremdschlüssel realisiert. Die beteiligten Relationen (= Tabellen) benötigen gleichartige Attribute, die in der abhängigen Tabelle als Fremdschlüssel und in der anderen Relation als Primärschlüssel verwendet werden. Beide Attribute müssen vom selben oder einem kompatiblen Datentyp sein. Die Datensätze verweisen („referenzieren“) mit dem Fremdschlüssel auf Datensätze mit identischem Wert in ihrem Primärschlüssel. Das DBMS stellt sicher, dass nur Verweise auf existierende Datensätze möglich sind und überprüft dies beim Anlegen oder Löschen von Datensätzen oder beim Ändern von Schlüsselfeldern.

Bei Systemen, die nach dem [[Transaktion (Informatik)|Transaktionsprinzip]] arbeiten, werden bei Verletzung von RI-Regeln alle innerhalb der Transaktion getätigten Updates zurückgesetzt ([[Rollback]]).

Primärschlüssel und Fremdschlüssel können auch aus mehreren Attributen/Tabellenspalten bestehen.

Die Festlegung sinnvoller RI-Regeln, insbesondere der Lösch-Weitergabe, sind eine wichtige Aufgabenstellung beim Datendesign, um ungewollte Löschmengen oder nicht durchführbare Löschweitergaben zu verhindern.

== Nachteile ==
Die Vorteile der referenziellen Integrität haben aber auch ihren Preis, denn jede Prüfung, die von einem RDBMS vorgenommen wird, kostet Rechnerressourcen, insbesondere Zeit.

So könnte es beispielsweise bei einem regelmäßigen Import größerer Datenmengen zweckmäßig sein, im aufnehmenden System die RI-Regeln temporär außer Kraft zu setzen, insbesondere wenn im Liefersystem die Konsistenz der Daten gesichert ist.

== Weblinks ==
{{Wikibooks|Einführung in SQL: Fremdschlüssel-Beziehungen#Einfüge- und Lösch-Reihenfolge bestimmen|Einfüge- und Lösch-Reihenfolge bestimmen}} Einführung in SQL
* [https://www.datenbanken-verstehen.de/datenmodellierung/referentielle-integritaet/ Referentielle Integrität ] (zusammengefasst)

== Einzelnachweise ==
<references />

[[Kategorie:Datenbanktheorie]]

Wikipedia (Deutsch) – Lokale Kopie - Benutzerbeiträge [de]

Referentielle Integrität