Fremdschlüssel übergeben? Die werden definiert, nicht übergeben.
Ich bin den ganzen Thread lang schon nicht ganz sicher, ob wir wirklich vom selben reden.
Eine Tabelle beschreibt eine Zuordnung eines abstrakten Objekts (sagen wir "Person") über deren Eigenschaften (Name, Alter, Schuhgröße, ...). Das ist Definitionssache und nennt sich entsprechend auch DDL wie Data Definition Language als Subset von SQL.
In die Tabelle rein kommen reale Instanzen dieses abstrakten Objekts. Diese haben eine Identität (sagen wir den Personalausweis) welche das Objekt eindeutig(!) identifiziert.
Weil wir hier von PC-Sachen reden und nicht von realen Plastikkarten, beschränken wir uns beispielhaft auf das, was am Personalausweis tatsächliche
Relevanz hat. Das ist die PKZ.
Für unsere Tabelle ist deshalb anschaulich die PKZ Primärschlüssel. Jede Person hat exakt eine, auch Zwillinge haben jeweils eine, selbst Dolly das Klonschaf hat eine eigene; kurz, sogar dann, wenn man Person A von Person B nicht unterscheiden kann (wenn sie vor einem stehen) hat man mit der PKZ alias dem Primärschlüssel DENNOCH die Identität der Person.
Schritt Zwei, ich will die Objekte - die Personen aus meiner einen Tabelle -- in Beziehung setzen zu etwas anderem. Sagen wir der Einfachheit wegen und um unnötigen Argumenten vorzubeugen: Fahrräder. Auf ein Fahrrad paßt exakt eine Person, es hat aber auch eine Farbe, eine Felgengröße und so weiter, sprich wir haben Tabelle No 2 "Fahrrad" mit sagen wir der Rahmennummer als Primärschlüssel, ein paar Attributen wie eben der Farbe und dergleichen UND wir haben eine
Referenz auf den Fahrer.
WER kann das Fahrrad fahren? Personen aus der P-Tabelle. Andere gibt es nicht, denn wenn es sie gäbe, ständen sie in der Personentabelle.
WEIL das so ist, definiere ich auf der Fahrradtabelle einen Fremdschlüssel. Das mach ich immer dann, wenn ich bereits einen
logischen Verweis hab - in einem Haus wohnen Menschen = Referenz, ein Fahrrad hat wechselbare Räder = Referenz, einen Besprechungsraum kann/muß ich für Zeiteinheit X und Personen Y buchen => Multireferenz und in Datenbanksprech immer Fremdschlüssel.
Im Beispiel DEFINIERE ich also auf der Spalte "Fahrer" in der Tabelle "Fahrrad" einen Fremdschlüssel, der auf die Spalte PKZ in der Tabelle Personen verweist. Im Klartext: Wenn ich einen Eintrag in diese Spalte machen will, dann darf ich dafür NUR Werte verwenden, die sich bereits in der Spalte PKZ in Personen befinden. Fremdschlüssel heißen deswegen Constraints (gibt auch andere).
Jetzt kann ich Personen haben
PKZ Name Vorname Geburtsdatum
1 Peter Meier 01.01.2000
2 Gerhard Schöne 02.02.1990
3 Peter Meier 01.01.2000
und Fahrräder
ID Farbe Fahrer
1 blau 2
2 rot 3
3 blau 1
4 gelb null
und habe so DREI Personen auf DREI Fahrräder gesetzt. Daß Person "1" und Person "3" denselben Namen haben und am selben Tag geboren worden... ist mehr oder weniger selten, kommt aber vor. Mit einer extra Spalte Haarfarbe hätten wir das ggfs gesehen - einer ist blond, einer nicht -- aber die Daten haben wir nicht.
Bei den Fahrrädern dasselbe. Wir haben zwei blaue Räder, ein rotes. Die Farbe genügt daher nicht als Identität für das Rad, ebensowenig wie die Felgengröße oder die Sattelfarbe oder das Modell oder irgend etwas; man kann buchstäblich immer zwei identische Räder gleichzeitig im Schuppen haben und dann sind es auch zwei Räder... und nicht eins.
Gäbe es den definierten Fremdschlüssel NICHT, dann könnte ich für den Fahrer von Rad #4 einfach eine 15 eintragen. Hindert mich niemand daran.
Problem ist nur, es gibt gar keine Person mit der 15. In Datenbanksprech ist damit die referentielle Integrität verletzt - es wird Bezug genommen auf eine Person, die nicht existiert, und der Versuch wird notwenigerweise fehlschlagen.
Die einzige Ausnahme von "Wert
muß in der referenzierten Schlüsselspalte existieren" ist NULL wie "nicht bekannt". Das liegt im eigenen Ermessen, was möglich sein muß und was nicht. Im Beispiel ist NULL für Fahrer in der Tabelle Fahrrad erlaubt - wenn man es kauft, sitzt noch niemand im Sattel und diesen Umstand "ich kann nicht sagen, wer da sitzt" gebe ich mit dem Wert NULL an.
Primärschlüssel dagegen DÜRFEN diesen Wert NICHT annehmen, da der PK das Objekt identifiiziert und wenn der PK NULL werden
könnte, dann hab ich buchstäblich eine nicht identifizierbare Person in meiner Tabelle.
Näheres zum Thema findet sich in einschlägigen Tutorials sowie in Texten zum Datenbankdesign.
👍 
