{"id":55001586,"date":"2026-02-01T00:00:00","date_gmt":"2026-02-06T13:37:05","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1586"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Warum_Beziehungen_mit_referenzieller_Integritaet","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Warum_Beziehungen_mit_referenzieller_Integritaet\/","title":{"rendered":"Warum Beziehungen mit referenzieller Integrität?"},"content":{"rendered":"

\"\"In unseren Access-Audits mit unseren Kunden treffen wir immer wieder auf das folgende Problem: Es gibt Tabellen, die zwar über ein Feld Datensätze aus anderen Tabellen referenzieren, aber es wurde gar keine Beziehung für diese Zuordnung definiert. Und wenn eine Beziehung angelegt wurde, wurde für diese keine referenzielle Integrität festgelegt. Das birgt verschiedene Gefahren, die unter Umständen sogar Auswirkungen auf den Unternehmensumsatz haben. Welche das sind und wie Sie diese Probleme beheben, zeigen wir in diesem Beitrag. Die Definition von Beziehungen mit referenzieller Integrität ist essenziell und sollte, wenn diese noch nicht vorhanden sind, schnellstens nachgerüstet werden. Das funktioniert in vielen Fällen aber gar nicht so leicht, weil die Tabellen bereits inkonsistente Daten enthalten. Auch zur Identifizierung und Korrektur solcher Datensätze liefert dieser Beitrag die passenden Lösungen.<\/b><\/p>\n

Stellen wir uns vor, wir hätten eine Tabelle zum Speichern von Bestellungen und eine für die entsprechenden Bestellpositionen. Die Tabelle der Bestellungen enthält ein Primärschlüsselfeld, welches die erste Voraussetzung für ein konsistentes Datenmodell ist – somit können alle Datensätze dieser Tabelle eindeutig identifiziert werden.<\/p>\n

Auch die Tabelle der Bestellpositionen enthält ein solches Primärschlüsselfeld. Neben den übrigen, typischen Feldern für eine Bestellposition enthält diese auch ein Feld, mit dem wir die Bestellposition einer Bestellung zuordnen können – nennen wir es BestellungID<\/b>.<\/p>\n

Grundsätzlich ist die Zuordnung von Bestellpositionen zu einer Bestellung also gewährleistet. Aber welche Probleme können auftreten, wenn wir keine referenzielle Integrität definieren?<\/p>\n

Probleme bei fehlender Beziehung oder ohne referenzielle Integrität<\/h2>\n

Schauen wir uns das Datenmodell aus Bild 1 an. Hier sehen wir die beiden Tabellen, anhand derer wir die Vorteile der referenziellen Integrität beschreiben wollen.<\/p>\n

\"Tabellen<\/p>\n

Bild 1: Tabellen der Beispieldatenbank<\/span><\/b><\/p>\n

Der Tabelle tblBestellungen <\/b>fügen wir die Datensätze aus Bild 2 hinzu.<\/p>\n

\"Beispieldaten<\/p>\n

Bild 2: Beispieldaten in der Tabelle tblBestellungen<\/span><\/b><\/p>\n

In der Tabelle tblBestellpositionen <\/b>legen wir nun eine Bestellposition für die erste Bestellung an, indem wir das Feld BestellungID <\/b>auf den Wert 1 <\/b>einstellen, also auf die erste Bestellung der Tabelle tblBestellungen<\/b>. Soweit ist das kein Problem – die Bestellposition ist einer Bestellung zugeordnet.<\/p>\n

Das decken wir normalerweise ab, indem wir jeweils eine Bestellung in einem Hauptformular abbilden und in einem Unterformular die Bestellpositionen. Wenn der Name des Fremdschlüsselfelds in der Tabelle des Unterformulars mit dem des Primärschlüsselfelds in der Datensatzquelle des Hauptformulars übereinstimmt, erkennt Access dies sogar beim Hinzufügen des Unterformulars und trägt dies korrekt in die Eigenschaften Verknüpfen nach <\/b>und Verknüpfen von <\/b>des Unterformular-Steuerelements ein (siehe Bild 3).<\/p>\n

\"Bestellungen<\/p>\n

Bild 3: Bestellungen und Bestelldetails in Haupt- und Unterformular<\/span><\/b><\/p>\n

Damit ordnet das Formular neue Bestellpositionen, die wir in das Unterformular eintragen, automatisch dem Bestelldatensatz im Hauptformular zu, weil das Fremdschlüsselfeld BestellungID <\/b>direkt mit dem entsprechenden Primärschlüsselwert aus dem Hauptformular gefüllt wird.<\/p>\n

Bei 99 % der ausgewerteten Anwendungen funktionierte dies nicht!<\/h2>\n

Auch wenn dies eine scheinbare Sicherheit vorgaukelt: In unseren Untersuchungen von Kundendatenbanken haben wir bei fast allen Anwendungen herausgefunden, dass dies nicht zuverlässig funktioniert. Die Gründe dafür sind nicht genauer bekannt, weil die betroffenen Datensätze oft vor langer Zeit angelegt wurden. Aber: Wir haben nahezu überall Probleme aufgedeckt, die zeigen, dass Benutzer erfinderisch sind und Wege finden, um die Zuordnung von Bestellungen und Bestellpositionen zu unterminieren.<\/p>\n

Dies zeigte sich in den folgenden Ergebnissen:<\/p>\n