Referentielle Integrität
Lehrer/innen-Info zum Thema »Referentielle Integrität«
Der erste Satz
Bevor Sie hiermit anfangen, sagen Sie den Schüler/innen: »Leute, das ganze Zeug, was wir jetzt machen, lässt sich in einem Satz zusammenfassen: Zu jedem Fremdschlüssel muss es einen gültigen Primärschlüssel geben.« Und mehr ist das ja auch nicht mit der referentiellen Integrität.
Was man evtl. weglassen kann
Eigentlich sollten die Schüler/innen die Problematik schon nach den Erklärungen des Hackers verstehen, wenn man das im Plenum bespricht.
Primärschlüssel und Fremdschlüssel wurden ja mehrfach schon früher behandelt und sollten einigermaßen klar sein. Die Terminologie "Elterntabelle" und "Kindtabelle" kann nach Geschmack übersprungen werden, ebenso die Anomalien.
Mögliche Vorgehensweisen
Wenn man die Themen dieses Kapitels alle behandeln will, sollte man erst mal gemeinsam den Terminalchat lesen und gemeinsam die Problematik (Fremdschlüssel verweist auf nicht existierenden Primärschlüssel) besprechen.
Anschließend kann man nach der Terminalchat-Besprechung einen knackigen Frontalvortrag halten, wo man die beiden Infozettel erklärt; die Themen referentielle Integrität, Primärschlüssel, Fremdschlüssel werden im nächsten Kapitel angewendet, die Terminologie "Eltern-Kind-Tabellen" ist leicht zu verstehen und muss nur von denen behalten werden, die in die schriftliche Abiturprüfung gehen.
Obwohl ich alles gemacht habe, wie Sie gesagt haben, liefern meine Abfragen auf einmal keine Ergebnisse mehr! Woran kann das liegen?
*LOL* Sie haben eine Person einfach aus der Datenbank gelöscht??? Erstaunlich, dass das überhaupt möglich war.
Was gibt es da zu LOLen? Geben Sie mir gefälligst eine verständliche Erläuterung!
Die Einträge in der Tabelle »einkaeufe« sind alle noch da. Das können Sie einfach sehen mit
SELECT *
FROM einkaeufe e
WHERE
e.FK_pNr = 10542;Aber sobald Sie nach einem Primärschlüssel suchen, etwa mit:
SELECT *
FROM einkaeufe e, personen p, waren w
WHERE
e.FK_pNr = p.pNr AND
e.FK_idWare = w.idWare AND
p.pNr = 10542;ist e.FK_pNr = p.pNr niemals wahr - denn es gibt schlicht keine p.pNr mit 10542!!!
Das heißt, ich habe den Primärschlüssel gelöscht, auf den ein Fremdschlüssel verweist!
Wow, ganz schön smart!!! Richtig!!!! Und damit sind die Daten in der Datenbank nicht mehr KONSISTENT. Sie funktionieren einfach nicht mehr. Sie haben die referentielle Integrität verletzt.
Und deshalb gab es KEIN Problem, als ich Melina Jakobs Einträge im Strafregister gelöscht habe, da ich hier keinen Primärschlüssel gelöscht habe, der noch irgendwo gebraucht wird. Und ebenso als ich ihre Haarfarbe geändert habe.
@@@ host disconnected @@@
Was zur … Hat er Stress mit Melina Jakobs neuer Haarfarbe?
Also. Mal nachdenken. Mist, Kowalsky kennt sich mit solchen Dingen aus, der könnte mir das bestimmt erklären. Aber wozu gibt es das Internet. (Beginnt zu googeln und tippt dabei in ein Dokument).
Oh - da gibt es einige Begrifflichkeiten, die ich mir vielleicht erst mal aufschreiben sollte …
Definitionen
Primärschlüssel
Attribut (oder auch mehrere Attribute), das jeden Datensatz eindeutig kennzeichnet. Jede Tabelle hat einen solchen Primärschlüssel.
Fremdschlüssel
Attribut, das auf einen Primärschlüssel meist in einer anderen (selten: in der gleichen) Tabelle verweist.
Elterntabelle, Kindtabelle
Wenn zwei Tabellen mit einem Fremdschlüssel verbunden sind, dann nennen wir diejenige, in der der Fremdschlüssel steht, die Kindtabelle (auch: Childtabelle, Detailtabelle). Die andere ist die Elterntabelle (auch: Parenttabelle, Mastertabelle). Die Kindtabelle bietet zusätzliche Details zur Elterntabelle. Achtung: Die Elterntabelle ist nicht unbedingt die »wichtigere«!
Im Beispiel oben ist waren die Kindtabelle. Sie gibt uns über den Fremdschlüssel mehr Details zur Kategorie Heimwerker in der Elterntabelle warentypen.
Merkhilfe 1: Kleine Kinder FREMDELN irgendwann (sie haben Angst vor fremden Leuten). In der Kindtabelle ist der Fremdschlüssel.
Merkhilfe 2: Es gibt kein Kind, das keine Eltern hat (das Kind »braucht« die Eltern). Umgekehrt gibt es Eltern ohne Kind.
Ok. Und was ist das mit der referentiellen Integrität, was dieser Hacker geredet hat?
Referentielle Integrität
Definition: Referentielle Integrität besagt, dass Attributwerte eines Fremdschlüssel auch als Attributwerte des Primärschlüssels vorhanden sein müssen.
Daten werden bspw. dann inkonsistent, wenn die referentielle Integrität verletzt ist.
Im folgenden Beispiel gibt es zum Fremdschlüssel einkaeufe.FK_pNr keinen entsprechenden Primärschlüssel in personen.pNr. (Der Fremdschlüssel verweist immer auf einen Primärschlüssel!).
Grundregel der referentiellen Integrität
Fremdschlüssel müssen IMMER auf existierende Primärschlüssel verweisen!
Wie werden Daten inkonsistent?
Unter anderem durch:
Löschanomalien
Es wird ein Datensatz aus der Elterntabelle gelöscht, zu dem in der Kindtabelle noch ein Fremdschlüssel existiert.
Beispiel: Anton Schmitt mit pNr = 10542 wird aus der Tabelle personen gelöscht; es existieren jedoch in der Tabelle einkaeufe noch zahlreiche Fremdschlüsseleinträge, die auf pNr 10542 verweisen. Entsprechend auch im folgenden Bild Löschen von idWare 411.
Einfügeanomalien
Es wird in einer Kindtabelle ein Datensatz mit einem Fremdschlüssel eingefügt, zu dem es in der Elterntabelle keinen Primärschlüssel gibt.
Beispiel (voriges Kapitel): Ein neuer Eintrag in der Tabelle strafregister mit Werten für die Fremdschlüssel, zu denen es keine vorhandenen Primärschlüssel gibt.
Anderes Beispiel: Ein neuer Eintrag in der Tabelle einkaeufe mit einem Wert für den Fremdschlüssel FK_idWare, zu dem es in der Elterntabelle waren keinen vorhandenen Primärschlüssel gibt.
Änderungsanomalie
Es wird bspw. in einer Kindtabelle der Fremdschlüssel auf einen Wert geändert, zu dem es in der Elterntabelle keinen Primärschlüssel gibt.
Beispiel (voriges Kapitel): In der Tabelle krankenakten wird bei FK_idKrankheit der Wert 15 in den Wert 500 geändert. Es gibt eine Krankheit mit der idKrankheit = 15, aber keine Krankheit mit der idKrankheit = 500.
Anderes Beispiel: Der Primärschlüssel 10542 wird in der Elterntabelle personen auf den Wert 3 geändert. Damit gibt es zu den Fremdschlüsseln FK_pNr = 10542 in der Kindtabelle keinen Primärschlüssel mehr.
*grübel - Letztlich heißt das ja nur, dass ich einfach aufpassen muss, dass kein Fremdschlüssel ins Nichts verweist. Na, das hätte man auch einfacher erklären können. Konsalik hätte das bestimmt gekonnt … Eigentlich war er kein so übler Typ. Im Gegensatz zu diesem widerlichen, verfressenen Smith!
Alles klar - ich wäre so weit!
Gut. Hier ist die echte Datenbank: maulwurfstadtDB.db. Verwenden Sie NICHT die Datenbank, mit der Sie eben noch gearbeitet haben, dort haben Sie ja schon eine Menge kaputt gemacht. Werfen Sie diese am besten gleich weg.
Merci. Wir bleiben in Kontakt.
@@@ host disconnected
Besonders gute Umgangsformen hat er ja nicht. Also - los geht's! Wollen wir diesen Parasiten mal einheizen!