<\/p>\n
Wenn man Beziehungen zwischen zwei Tabellen erstellt, kann man dies ohne referenzielle Integrität erledigen oder auch mit. Wir empfehlen dringend, immer referenzielle Integrität zu definieren, außer es ist technisch nicht möglich – beispielsweise, weil die Tabellen nicht in der gleichen Datenbank liegen. Manchmal ist das Kind jedoch bereits in den Brunnen gefallen. Der Entwickler hat für die Tabellen nur eine einfache Beziehung ohne referenzielle Integrität definiert und die Benutzer haben dies unwissend ausgenutzt: So sind Inkonsistenzen im Datenbestand entstanden, die früher oder später zu gravierenden Problemen führen können. Also zeigen wir in diesem Artikel zunächst, wie solche Probleme überhaupt auftreten können und wie wir diese wieder beheben. Und wir schauen uns auch an, welche Rolle Eigenschaften wie Eingabe erforderlich und die Löschweitergabe in dieser Situation spielen.<\/p>\n
Die Beispiele dieses Artikels findest Du in der Datenbank TabellenBasics_ReferenzielleIntegritaetNachruesten.accdb<\/b>.<\/p>\nBeispieltabellen<\/h2>\n
Wir schauen uns das Problem an zwei einfachen Tabellen unserer Beispieldatenbank zur Verwaltung von Büchern an. In unserer Beispieldatenbank sind diese beiden Tabellen über das Fremdschlüsselfeld KategorieID <\/b>in der Tabelle tblBuecher <\/b>miteinander verknüpft.<\/p>\n
Wir haben natürlich ordnungsgemäß direkt beim Anlegen und vor dem Einfügen jeglicher Daten eine Beziehung mit referenzieller Integrität definiert (siehe Bild 1).<\/p>\n
Bild 1: Formular-Entwurf unseres Beispielformulars<\/p>\n Diese werden wir nun erst einmal entfernen, damit wir nachstellen können, welche Probleme bei Verwendung von Beziehungen ohne referenzielle Integrität auftreten können. Dazu klicken wir doppelt auf den Beziehungspfeil und entfernen aus dem Dialog Beziehungen bearbeiten <\/b>die Option Mit referenzieller Integrität<\/b> (siehe Bild 2).<\/p>\n Bild 2: Entfernen der referenziellen Integrität<\/p>\n Danach geschieht erst einmal nichts Besonders – wir können nach wie vor Daten in die beiden Tabellen eingeben und insbesondere über das Fremdschlüsselfeld KategorieID <\/b>die Kategorien für unsere Bücher auswählen, da wir für dieses ein Nachschlagefeld definiert haben (siehe Bild 3).<\/p>\n Bild 3: Auswahl von Werten aus der Tabelle tblKategorien<\/p>\n Wir können auch nach wie vor Einträge in der Tabelle tblKategorien <\/b>bearbeiten, also zum Beispiel neue Kategorien hinzufügen. Und natürlich lassen sich auch leicht Kategorien entfernen. Oh! Kategorien entfernen Aber kann das nicht zu Problemen führen Ja, das ist das erste Problem, das wir uns anschauen.<\/p>\n Wir sehen in der Tabelle tblBuecher <\/b>eine Reihe von Einträgen, die der Kategorie Fachbuch <\/b>zugeordnet sind. Also stellen wir uns mal vor, ein Mitarbeiter löscht diesen Eintrag zufällig (siehe Bild 4). Die Warnmeldung aus erscheint auch nur, wenn die entsprechende Einstellung in den Access-Optionen aktiviert ist, aber Warnmeldungen ignoriert man ja gelegentlich auch mal.<\/p>\n Bild 4: Meldung beim Löschen eines Datensatzes der Tabelle tblKategorien<\/p>\n Öffnen wir nun erneut die Tabelle tblBuecher<\/b>, stellen wir fest, dass für einige Bücher nun keine Kategorie mehr in der Spalte Kategorie <\/b>angezeigt wird (siehe Bild 5). Stattdessen sehen wir ein leeres Feld. Aber was genau hat das zu bedeuten<\/p>\n Bild 5: Die Bücher haben plötzlich keine Kategorie mehr. Oder doch<\/p>\n Jedenfalls erscheint die fehlende Kategorie Fachbuch <\/b>nun nicht mehr in der Auswahlliste.<\/p>\n Aber ist das Fremdschlüsselfeld KategorieID <\/b>nun wirklich leer oder sieht es nur so aus Und wie können wir das herausfinden Wenn man etwas versierter ist, kann man dies schnell mit VBA lösen. Dazu schreibt man die folgende Anweisung im VBA-Editor in den Direktbereich und betätigt die Eingabetaste. Am schnellsten gelangt man dort mit Strg + G <\/b>hin:<\/p>\n Das Ergebnis lautet, wie wir auch in Bild 6sehen, 2. Die Kategorie ist also nach wie vor auf den richtigen Wert für die Kategorie eingestellt, allerdings ist diese nicht mehr in der Tabelle tblKategorien <\/b>vorhanden. Dementsprechend kann das Nachschlagefeld auch keine Kategorie mehr anzeigen denn: Es ist darauf ausgelegt, einen Datensatz aus der Tabelle tblKategorien <\/b>auszulesen, der den Wert 2 <\/b>im Feld KategorieID <\/b>hat, und zu diesem Datensatz den Inhalt des Feldes Kategorie <\/b>anzuzeigen. Aber da dieser Datensatz nicht mehr da ist, kann er auch nicht mehr angezeigt werden. Wer kein VBA bemühen möchte, um sich davon zu überzeugen, welcher Wert tatsächlich hinter dem in einem Nachschlagefeld angezeigten Feld steckt, kann auch noch andere Methoden wählen:<\/p>\n Bild 6: Das Feld KategorieID enthält einen Wert.<\/p>\n Die erste Variante greift in den Tabellenentwurf ein, daher sollte man diese normalerweise nicht wählen. Dabei öffnen wir die Tabelle im Entwurf, zeigen die Eigenschaften für das Nachschlagefeld KategorieID<\/b> an und wechseln dort zum Bereich Nachschlagen<\/b>. Dort stellen wir die Eigenschaft Steuerelement anzeigen <\/b>auf den Wert Textfeld <\/b>ein (siehe Bild 7).<\/p>\n Bild 7: Temporäres Umwandeln des Nachschlagefeldes in ein herkömmliches Tabellenfeld<\/p>\n Die Eigenschaften, die Du mit dem Nachschlage-Assistent oder sogar von Hand für das Nachschlagefeld dort eingetragen hast, sind allerdings mit dem Speichern des neuen Entwurfs verloren – und das Speichern ist erforderlich, sobald Du in die Datenblattansicht wechseln möchtest. Mit dem Speichern werden die Eigenschaften für das Nachschlagefeld wieder auf die Standardwerte zurückgesetzt.<\/p>\n Wechseln wir nun in die Datenblattansicht, sehen wir im Feld KategorieID<\/b> die Werte, die darin tatsächlich gespeichert sind (siehe Bild 8) – in diesem Fall zum Beispiel der Wert 2 <\/b>für die Felder, die der Kategorie Fachbuch <\/b>zugeordnet waren.<\/p>\n Bild 8: Anzeige der tatsächlichen Werte im Fremdschlüsselfeld<\/p>\n Wer nicht direkt in den Tabellenentwurf eingreifen möchte, kann sich auch eine Abfrage erstellen, die nur die tatsächlich in dem Feld gespeicherten Werte anzeigt. Dazu erstellen wir eine Abfrage, die alle Felder der zu untersuchenden Tabelle enthält. Auch hier können wir für die Nachschlagefelder die Eigenschaft Steuerelement<\/b> einstellen (siehe Bild 9). In der Datenblattansicht wird auch diese Abfrage nun die tatsächliche Werte des Feldes KategorieID <\/b>liefern.<\/p>\n Bild 9: Aktivieren der Anzeige als Textfeld<\/p>\n Das erste Problem ist bereits offensichtlich zu sehen: Die Kategorien der bisher als Fachbuch kategorisierten Bücher werden nicht mehr in der Tabelle angezeigt. Aber es geht noch weiter. Stellen wir uns vor, wir wollen eine Liste aller Bücher für einen Bericht aufbereiten und stellen eine entsprechende Abfrage als Datensatzquelle zusammen.<\/p>\n Dieser wollen wir in der Regel die Inhalte der verknüpften Tabellen, die wir im Bericht anzeigen wollen, ebenfalls hinzufügen – in diesem Fall den Namen der Kategorie und die Beschreibung der Kategorien, die wir zum Beispiel in einem Gruppenkopf für die Kategorie abbilden wollen. Also fügen wir der Abfrage neben der Tabelle tblBuecher <\/b>wie in Bild 10 auch noch die Tabelle tblKategorien <\/b>hinzu (die übrigen Tabellen lassen wir an dieser Stelle aus Gründen der Übersicht weg).<\/p>\n Bild 10: Abfrage mit Büchern und Kategorien<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>![\"Formular-Entwurf](\"..\/tl_files\/images\/pic_656_001.png\")
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nGefahr: Kategorien entfernen<\/h2>\n
<\/a><\/p>\nBücher ohne Kategorie<\/h2>\n
<\/a><\/p>\n DLookup(\"KategorieID\", \"tblBuecher\", \"BuchID = 2\")<\/pre>\n
<\/a><\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nProbleme durch das Löschen der Kategorie<\/h2>\n
<\/a><\/p>\n
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t