Im relationalen Datenbankmodell sind Tabellen über „Schlüssel“ verbunden; der Primärschlüssel ist eine innerhalb der Tabelle für jeden Datensatz eindeutige ID; diese eindeutige, primäre ID kann von einer anderen Tabelle referenziert werden. Diese Referenz zu einer ID in eine andere Tabelle nennt sich „Fremdschlüssel“. Show
ER-Diagramm Beispiel: In einer Datenbank für die Verwaltung von Benutzern soll die Zuordnung zu einem Land über einen zweistelligen Länder-Code (z.B. ‚DE’ für
Deutschland) abgebildet werden. Die Länder werden mit Code und Bezeichnung in einer eigenen Tabelle gespeichert und haben den Länder-Code als eindeutige ID (Primärschlüssel). Die Nutzerdaten-Tabelle referenziert nun diesen Primärschlüssel der Ländertabelle mit einem diesem Schlüssel entsprechenden Wert. Für den Eintrag dieses referenzierten, also entfernten bzw. fremden Schlüssels in die Nutzerdaten-Tabelle ist in der Nutzerdaten-Tabelle eine entsprechende Fremdschlüssel-Spalte vorgesehen. Damit
stehen beide Tabellen in einer „Relation“. Diese Relationen lassen sich auch über die XML-Konfiguration des ZMSSqldb-Objektes abbilden: Dazu wird der zu referenzierende Tabellenname (tablename) und diejenige Tabellespalte bezeichnet, die als Fremdschlüssel (fieldname) referenziert wird. Das Beispiel zeigt ein Tabellen-Item (Spalte, columns-item), das als Select-Liste abgebildet wird und seine Werte aus einer referenzierten Länder-Tabelle erhält: So sieht das entsprechende Redaktions-Interface aus: Konfigurations-Code für das Datenmodell der oben dargestellten Einfachauswahl-Liste
„Länder“: ... <item> <dictionary> <item key="id">country</item> <item key="label">Country</item> <item key="fk"> <dictionary> <item key="tablename">countries</item> <item key="fieldname">countryid</item> <item key="displayfield">title</item> </dictionary> </item> </dictionary> </item> ... Alternativ ist es auch möglich bei fehlender Bezugtabelle willkürliche Auswahlwerte vorzugeben. Über das option-Element lassen sich Werte explizit vorgeben, ohne dass diese in einer Datenbank-Tabelle stehen müssen: <item> <dictionary> <item key="id">lang</item> <item key="label">Language</item> <item key="hide" type="int">1</item> <item key="fk"> <dictionary> <item key="options"> <list> <item> <list> <item type="int">1</item> <item>English</item> </list> </item> <item> <list> <item type="int">2</item> <item>German</item> </list> </item> </list> </item> </dictionary> </item> </dictionary> </item> (Einführung in SQL: Fremdschlüssel-Beziehungen) In diesem Kapitel werden wir die Verknüpfungen zwischen Tabellen über Fremdschlüssel behandeln. Bereits in den einleitenden Kapiteln wurde die „referentielle Integrität“ betont, dass nämlich die Datensätze in verschiedenen Tabellen dauerhaft zueinander passen müssen. Diesem Zweck dienen die Fremdschlüssel. Problemstellung[Bearbeiten]In der Beispieldatenbank gibt es viele Verweise von einer Tabelle auf andere Tabellen:
Es wäre viel Aufwand, wenn ein Anwender alle diese Bedingungen immer selbständig beachten müsste. In einem Büro kann man immer einmal gestört werden; und schon fehlt eine der unbedingt erforderlichen Informationen: Ein neuer Vertrag wird gespeichert, aber der Kunde fehlt noch; dann kommt ein Telefonat dazwischen; dann macht die Mitarbeiterin mit dem nächsten Vertrag weiter. Und wohin soll die Rechnung zum vorigen Vertrag gehen? Viel sinnvoller ist es, wenn das DBMS in die Lage versetzt wird, diese Bedingungen direkt zu berücksichtigen. Dies wird über die Fremdschlüssel – englisch: ForeignKeys (FK) – geregelt. Grundsätze der Lösung[Bearbeiten]Beziehungen beschreiben[Bearbeiten]Bei all diesen Beziehungen geht es um die referentielle Integrität, dass nämlich die Verbindungen zwischen den Tabellen und Querverweise immer auf dem aktuellen Stand sind und die Werte in allen Tabellen korrekt zusammenpassen. Weiter unten wird es als „interne Datensicherheit“ bezeichnet: Die Daten sollen innerhalb der Datenbank insofern sicher sein, dass keine Widersprüche zwischen den Daten in verschiedenen Tabellen auftreten. Durch die Fremdschlüssel werden Beziehungen zwischen Datensätzen verschiedener Tabellen definiert. Das DBMS sorgt dann für die richtigen Verknüpfungen:
Ergänzend sind weitere Bedingungen denkbar:
Die letzten Bedingungen können vernachlässigt werden, da die Beziehungen über die IDs geregelt werden. Nach den Regeln der relationalen Datenbanken hat die ID keine andere Bedeutung als die Identifizierung der Datensätze; es gibt niemals die Notwendigkeit, sie zu ändern. Beziehungen definieren[Bearbeiten]In der Tabellenstruktur der Beispieldatenbank sind bei den einzelnen Tabellen in der Spalte Erläuterung die Verknüpfungen aufgeführt, beispielsweise:
In allen Fällen bedeuten die Verweise: In einem Datensatz der jeweils ersten Tabelle stehen keine weiteren Einzelheiten (z. B. zum Versicherungsnehmer). Stattdessen steht dort eine ID; die Angaben dazu sind im Datensatz der „weiteren“ Tabelle unter der genannten ID zu finden. Soweit es sich um einen optionalen Verweis handelt, kann in der „ersten“ Tabelle auch der NULL-Wert stehen; ob ein NULL-Verweis mit einem Fremdschlüssel automatisiert gesteuert werden kann, hängt vom DBMS ab. Syntax und Optionen[Bearbeiten]Es sind also zwei Punkte sicherzustellen:
Begriffe[Bearbeiten]Auf der Ebene von Tabellen werden die folgenden Begriffe verwendet; diese beziehen sich immer auf eine bestimmte Fremdschlüssel-Beziehung.
Der Begriff Detailtabelle hat in diesem Beispiel nichts damit zu tun, dass in der Tabelle Einzelheiten zum Fahrzeug oder zum Sachbearbeiter stünden (das ist gerade nicht der Fall). Mit dem Beispiel im Wikipedia-Artikel „Fremdschlüssel“ wird die Bedeutung von Master und Detail verständlich: Die Kunden sind die maßgebende Tabelle; zu jedem Kunden gehören als Details „seine“ Bestellungen. Wir sprechen deshalb von Detailtabelle mit Fremdschlüsseln: Eine Spalte in der Detail-Tabelle wird über den Fremdschlüssel verknüpft mit dem Primärschlüssel in der Primärtabelle. Die Syntax[Bearbeiten]Die Fremdschlüssel gehören zur Definition der Tabellen, ihre Definition über FOREIGN KEY ist also Bestandteil der Data Definition Language (DDL). Wie bei anderen Erweiterungen der Tabellendefinition gibt es mehrere Wege:
<Definition der Spalte> -- ergänzt durch: REFERENCES <Primärtabelle> ( <Spaltenname> ) [ <Optionen> ]
[ CONSTRAINT <Constraint-Name> ] FOREIGN KEY ( <Spaltenname> ) REFERENCES <Primärtabelle> ( <Spaltenname> ) [ <Optionen> ]
ALTER TABLE <Detailtabelle> ADD [ CONSTRAINT <Constraint-Name> ] FOREIGN KEY ( <Spaltenname> ) REFERENCES <Primärtabelle> ( <Spaltenname> ) [ <Optionen> ] Zu dem Zeitpunkt, an dem ein FOREIGN KEY festgelegt wird, muss die Tabelle, auf die verwiesen wird, bereits definiert sein. Der letzte Weg ist deshalb in der Regel am sichersten: zuerst werden alle Tabellen bestimmt, danach alle FOREIGN KEYs als Verknüpfung. Zur eigentlichen Definition gehören die folgenden Bestandteile:
Die Optionen werden im nächsten Abschnitt erläutert. Der Vollständigkeit halber sei darauf hingewiesen: Eine solche Verknüpfung kann sich auch auf mehrere Spalten beziehen, nämlich sowohl als Primärschlüssel als auch als Fremdschlüssel. Da ein Primärschlüssel keine weitere Bedeutung haben soll, besteht er sowieso (fast) immer aus einer einzelnen Spalte; deshalb wird in der Übersicht nur ein <Spaltenname> erwähnt. Optionen[Bearbeiten]Die Optionen eines FOREIGN KEY bestimmen das Verhalten der Tabelle, die die Verweise (Fremdschlüssel) benutzt – also der Detailtabelle –, sobald in der Primärtabelle die Primärschlüssel geändert werden. Allgemein steht folgendes Verhalten zur Auswahl:
Die verschiedenen Update- und Lösch-Optionen werden nicht von allen DBMS unterstützt. Die Option ON UPDATE CASCADE z. B. wird von den meisten DBMS nicht angeboten. Im einzelnen wirken sich diese Optionen wie folgt aus. Bei Neuaufnahmen in der Primärtabelle sind die Datensätze in der übergeordneten Tabelle noch nicht vorhanden. Also kann es keine Probleme geben; deshalb muss dies bei den Optionen nicht beachtet werden. Die folgenden Optionen wirken sich bei Änderungen und Löschungen in der Primärtabelle in gleicher Weise aus:
Die folgende Option wirkt sich bei Änderungen und Löschungen unterschiedlich aus:
Wenn der Primärschlüssel „richtig“ definiert ist, nämlich für alle Zeiten unveränderlich ist, dann wäre die UPDATE-Option eigentlich überflüssig. Aber man sollte vorbereitet sein, falls man doch auf die Idee kommt, einen Primary Key zu ändern. Auswirkungen[Bearbeiten]Änderungen in der Primärtabelle haben mit den Optionen nichts zu tun. Sie werden durch einen direkten Befehl – INSERT, UPDATE, DELETE – ausgelöst. Ein Fremdschlüssel steuert mit den Optionen nur, inwieweit eine solche Änderung Auswirkungen auf die Detailtabelle hat oder nicht. Allerdings kann es passieren, dass durch die Restriktion nicht nur die Änderung in der Detailtabelle, sondern auch die Änderung in der Primärtabelle verhindert wird. Änderungen in der Detailtabelle werden durch einen FK wie folgt eingeschränkt: Bei INSERT und UPDATE dürfen in den Spalten des Fremdschlüssels nur solche Werte eingefügt werden, die in der Primärtabelle als Primärschlüssel vorhanden sind. Einzige Ausnahme ist, wenn die Fremdschlüssel-Spalte als optional definiert ist. Dann kann hier auch NULL eingefügt werden, obwohl NULL niemals als Primärschlüssel in der Primärtabelle stehen wird. Beispiele[Bearbeiten]Versicherungsvertrag und Kunden[Bearbeiten]Beginnen wir für die Tabelle Versicherungsvertrag mit dem Verweis von der Spalte Versicherungsnehmer_ID auf die Tabelle Versicherungsnehmer. ALTER TABLE Versicherungsvertrag ADD CONSTRAINT Versicherungsvertrag_VN FOREIGN KEY (Versicherungsnehmer_ID) REFERENCES Versicherungsnehmer (ID); Wie fast immer benutzen wir eine Einschränkung mit Namen. Wie bei den anderen Constraints hängen wir an den Namen der Tabelle „etwas“ an (Suffix), das für die Art der Einschränkung steht. Wenn eine Tabelle nur einen Fremdschlüssel bekommt, wäre FK als Suffix geeignet. Da zur Tabelle Versicherungsvertrag drei Fremdschlüssel gehören, verwenden wir stattdessen den jeweiligen Tabellen-Alias. Mit diesem CONSTRAINT ist festgelegt: Ein neuer Versicherungsvertrag kann nur dann registriert werden, wenn die dort vorgesehene Versicherungsnehmer_ID in der Tabelle Versicherungsnehmer als ID bereits registriert ist. Wie gesagt: Eine „richtige“ ID wird niemals mehr geändert. Vorsichtshalber legen wir aber auch die Optionen fest: ALTER TABLE Versicherungsvertrag ADD CONSTRAINT Versicherungsvertrag_VN FOREIGN KEY (Versicherungsnehmer_ID) REFERENCES Versicherungsnehmer (ID) ON UPDATE RESTRICT ON DELETE RESTRICT; Die Änderung der ID oder die Löschung eines Versicherungsnehmers ist also nicht zulässig, wenn zu diesem Kunden ein Versicherungsvertrag registriert ist. Mitarbeiter und Abteilung[Bearbeiten]Die Beziehung zwischen diesen Tabellen kann so festgelegt werden: ALTER TABLE Mitarbeiter ADD CONSTRAINT Mitarbeiter_FK FOREIGN KEY (Abteilung_ID) REFERENCES Abteilung (ID) ON UPDATE CASCADE ON DELETE RESTRICT; Das DBMS sorgt damit für die interne Datensicherheit:
Kombination von Fremdschlüsseln[Bearbeiten]Grundsätzlich kann eine Detail-Tabelle gleichzeitig als Master-Tabelle (Primärtabelle) für eine andere Tabelle definiert werden. In unserer Beispieldatenbank betrifft das die mehrfachen Verknüpfungen: Versicherungsvertrag ⇔ Versicherungsnehmer ⇔ Versicherungsgesellschaft ⇔ Fahrzeug ⇔ Fahrzeugtyp ⇔ Fahrzeughersteller ⇔ Mitarbeiter ⇔ Abteilung Fahrzeug ⇔ Zuordnung_SF_FZ ⇔ Schadensfall Dann sind aber nicht alle Kombinationen der Optionen CASCADE (Weitergabe) und RESTRICT (Restriktion) zulässig – weder bei DELETE noch bei UPDATE. Das DBMS prüft beim Ausführen der DDL-Befehle, ob die gewünschte Regel zulässig ist oder nicht. Nicht zulässig sind die folgende Verknüpfungen: Tabelle C Tabelle B Tabelle A (Details zu Tabelle B) (Details zu Tabelle A, (Master zu Tabelle B) (Master zu Tabelle C) Versicherungsvertrag ⇔ Versicherungsnehmer ⇔ Versicherungsgesellschaft ON DELETE RESTRICT ON DELETE CASCADE Erläuterung: Es ist nicht zulässig, einen Versicherungsnehmer zu löschen, wenn zu ihm noch (mindestens) ein Vertrag registriert ist. Andererseits sollen mit einer Versicherungsgesellschaft auch alle ihre Versicherungsnehmer automatisch gelöscht werden. Diese automatische Löschung stünde im Widerspruch zur Verhinderung der Löschung bei vorhandenen Verträgen. Zulässig sind die folgende Verknüpfungen: Tabelle C Tabelle B Tabelle A (Details zu Tabelle B) (Details zu Tabelle A, (Master zu Tabelle B) (Master zu Tabelle C) Versicherungsvertrag ⇔ Versicherungsnehmer ⇔ Versicherungsgesellschaft ON DELETE CASCADE ON DELETE RESTRICT Erläuterung: Das Löschen der Versicherungsgesellschaft ist nicht zulässig, wenn noch Versicherungsnehmer registriert sind. Damit wird die Weitergabe oder Restriktion der Löschung vom Versicherungsnehmer zum Versicherungsvertrag überhaupt nicht beeinflusst. Möglich sind auch Ring-Verkettungen: Tabelle A ⇔ Tabelle B ⇔ Tabelle C ⇔ Tabelle A Ob Sie diese Verknüpfungen von rechts nach links lesen oder umgekehrt, ist gleichgültig: Eine Tabelle hat Verweise auf eine andere, diese auf eine nächste und eine weitere wieder auf die erste. Rekursive Fremdschlüssel[Bearbeiten]Fremdschlüsselbeziehungen können auch rekursiv definiert werden. Dabei verweist in einer Tabelle eine abhängige Spalte auf den eigenen Primärschlüssel. Als Beispiel verwenden wir eine hierarchische Gliederung der Abteilungen: CREATE TABLE Abteilung ( AbtNr INTEGER NOT NULL, UebergeordneteAbt INTEGER, AbtName VARCHAR(100), PRIMARY KEY (AbtNr), FOREIGN KEY (UebergeordneteAbt) REFERENCES Abteilung (AbtNr) ON DELETE CASCADE ); Die gesamte Firma wird mit AbtNr = 1 gespeichert; zu ihr gehört keine UebergeordneteAbt. Bei jeder anderen Abteilung wird in dieser Spalte die AbtNr derjenigen Abteilung registriert, der sie direkt zugeordnet ist: Eine Hauptabteilung gehört direkt zur Firma, eine beliebige Abteilung zu ihrer Hauptabteilung, eine Arbeitsgruppe zu einer bestimmten Abteilung usw. Praktische Probleme[Bearbeiten]Rekursive Fremdschlüsselbeziehungen sind etwas problematisch in der Handhabung. Die Neuaufnahme von Datensätzen muss in einer bestimmten Reihenfolge geschehen: zuerst die oberste Ebene (Firma), dann die nächste Ebene (Hauptabteilungen) usw. Auf jeder Ebene ist eine Neuaufnahme nur dann möglich, wenn der übergeordnete Eintrag schon vorhanden ist. Beim Löschen von Datensätzen kann es zu verschiedenen Problemen kommen. Mit Lösch-Weitergabe – ON DELETE CASCADE – könnten wesentlich mehr Daten gelöscht werden, als in der WHERE-Bedingung angegeben wird: DELETE FROM Abteilung WHERE AbtNr = 33; Bei diesem Beispiel werden auch alle Sätze gelöscht, die der Abteilung 33 untergeordnet sind. Mit Lösch-Restriktion – ON DELETE RESTRICT – wird nach jeder einzelnen Löschung geprüft, ob es keine Fremdschlüsselverletzung gibt. Selbst wenn alle Sätze aus der Tabelle entfernt werden sollen, kann es passieren, dass die Ausführung fehlschlägt. Das liegt daran, dass bei der Ausführung des DELETE-Befehls die Sätze in einer beliebigen Reihenfolge gelöscht werden, meistens in der Reihenfolge, in der sie „real“ in der Tabelle gespeichert sind. Nur wenn die Sätze exakt in der richtigen Reihenfolge (von der untersten Abteilung beginnend bis zur obersten Abteilung) gespeichert sind, dann kann die Ausführung des DELETE-Statements gelingen. Dass der Erfolg eines SQL-Befehls von der physischen Speicherreihenfolge der Sätze abhängig ist, darf in einem DBMS nicht vorkommen. Daher bieten einige DBMS die Möglichkeit der verzögerten Prüfung bei der Löschweitergabe. Durch ein einziges DELETE-Statement können mehrere Sätze und unter Umständen auch alle Sätze einer Tabelle gelöscht werden. Innerhalb einer Transaktion können mehrere DELETE-Statements ausgeführt werden. Standardmäßig erfolgt die Prüfung, ob eine Lösch-Operation ausgeführt werden darf, nach jedem einzelnen Satz, der gelöscht wurde. Das hat den Vorteil, dass bei einer unzulässigen Löschung gleich abgebrochen werden kann und der Rollback nicht unnötig viel zu tun hat. Maßnahmen[Bearbeiten]Um die oben beschriebenen Lösch-Anomalien zu vermeiden, kann bei einigen DBMS die Prüfung, ob die Löschung zulässig ist, als Gesamtprüfung stattfinden und nicht nach jedem einzelnen Satz:
Reihenfolge der Maßnahmen beachten[Bearbeiten]Wenn die Tabellen in einer Datenbank mit Fremdschlüsseln verbunden sind, dann muss beim Bearbeiten der Tabellen eine bestimmte Reihenfolge eingehalten werden, und zwar sowohl beim Einfügen als auch beim Löschen. Ob auch das Ändern mit Schwierigkeiten verbunden sein kann, hängt von der Situation ab. Alle hier genannten Probleme beziehen sich ausschließlich auf diejenigen Spalten, die mit Fremdschlüsseln an andere Tabellen gebunden sind. Änderungen in anderen Spalten können immer ohne Probleme ausgeführt werden. Bei INSERT[Bearbeiten]Man muss mit den Tabellen beginnen, die keine Fremdschlüssel haben. Danach können die Tabellen befüllt werden, die auf diese Tabellen verweisen, und so weiter. Bei unserer Beispieldatenbank bedeutet das für einen neuen Versicherungsvertrag:
Erst jetzt sind alle Voraussetzungen vorhanden, sodass der Vertrag gespeichert werden kann. Wenn Ring-Verkettungen vorkommen, dann müssen Tools zum initialen Befüllen verwendet werden; oder es muss mit Sätzen begonnen werden, die NULL als Fremdschlüssel enthalten. Bei DELETE[Bearbeiten]Zum Löschen von Datensätzen muss – sofern nicht mit einer automatischen Lösch-Weitergabe gearbeitet wird – genau die umgekehrte Reihenfolge eingehalten werden. Bei UPDATE[Bearbeiten]Die Fremdschlüssel-Beziehungen verlangen, dass die Datensätze in der Primärtabelle, auf die aus der Detailtabelle verwiesen wird, vorhanden sind. Ändert man einen Fremdschlüssel in der Detailtabelle, muss der neue Wert ebenfalls in der Primärtabelle vorhanden sein. Wenn man einen Schlüsselwert in der Primärtabelle ändern will, dann ist das nur möglich, wenn der alte Wert von keinem Satz in der Detailtabelle verwendet wird. Sollte der Wert doch verwendet (referenziert) werden, dann ist der UPDATE nicht möglich. Theoretisch wäre auch ein UPDATE-CASCADE vorstellbar. Das würde bedeuten, dass die Änderung eines Wertes in der Primärtabelle auch gleichzeitig alle referenzierten Werte in der Detailtabelle mitändert. Eine solche Funktion wird jedoch von den meisten Datenbanken nicht angeboten. Wie geht man also vor, wenn man einen Schlüsselwert in der Primärtabelle ändern will, der von mehreren Sätzen in der Detailtabelle verwendet wird? Diese Aufgabe wird in drei Schritten gelöst:
Bestimme die „Einfüge-Reihenfolge“[Bearbeiten]Theoretisch handelt es sich hier um ein Problem der „topologischen Sortierung“. Bei großen Datenmodellen sollte man alle vorhandenen Tabellen in der Reihenfolge notieren, in der sie befüllt werden können. Dazu kann man die Struktur der Datenbank auslesen; Tabellen und Fremdschlüssel müssen also bereits definiert sein. Beispiele dazu sind im Kapitel Tipps und Tricks zu finden. Zusammenfassung[Bearbeiten]In diesem Kapitel erfuhren wir einiges darüber, wie mit Fremdschlüsseln (= FOREIGN KEYs) die Verbindungen zwischen Tabellen sichergestellt werden:
Übungen[Bearbeiten]Bei allen SQL-Befehlen benutzen Sie bitte CONSTRAINTS mit Namen. Welche der folgenden Aussagen sind wahr, welche sind falsch?
Welche Fremdschlüssel sind bei den Tabellen Fahrzeug und Mitarbeiter der Beispieldatenbank vorzusehen? Nennen Sie jeweils die betreffenden Spalten. Sind bei den Primärtabellen weitere Fremdschlüssel vorzusehen? Verknüpfen Sie die Tabelle Fahrzeugtyp mit der Tabelle Fahrzeughersteller als Fremdschlüssel auf die entsprechenden Spalten. Verknüpfen Sie die Tabelle Dienstwagen mit den Tabellen Mitarbeiter und Fahrzeugtyp als Fremdschlüssel auf die entsprechenden Spalten. Welche der folgenden Aussagen sind wahr, welche sind falsch?
Welche der folgenden Aussagen sind wahr, welche sind falsch?
Nennen Sie die Reihenfolge der INSERT-Befehle, wenn ein Schadensfall mit drei beteiligten Fahrzeugen aufzunehmen ist. Dabei soll ein Fahrzeug zu einem „Eigenen Kunden“ und zwei Fahrzeuge zu „Fremdkunden“ gehören; die eine „fremde“ Versicherungsgesellschaft soll schon gespeichert sein, die andere nicht. Lösungen Die Aussagen 1, 2, 4, 7, 9 sind wahr. Die Aussagen 3, 5, 6, 8, 10, 11 sind falsch. Hinweis zu Aussage 6: Die Ergänzung „immer“ macht die Aussage falsch. Wenn die ID ausgenommen würde, wäre die Aussage wahr. Fahrzeug: Fahrzeugtyp_ID verweist auf ID der Tabelle Fahrzeugtyp.
ALTER TABLE Fahrzeugtyp ADD CONSTRAINT Fahrzeugtyp_FK FOREIGN KEY (Hersteller_ID) REFERENCES Fahrzeughersteller (ID);
ALTER TABLE Dienstwagen ADD CONSTRAINT Dienstwagen_FZ FOREIGN KEY (Fahrzeugtyp_ID) REFERENCES Fahrzeugtyp (ID), ADD CONSTRAINT Dienstwagen_MI FOREIGN KEY (Mitarbeiter_ID) REFERENCES Mitarbeiter (ID);
Die Aussagen 1, 2, 6 sind wahr. Die Aussagen 3, 4, 5 sind falsch.
Die Aussagen 3, 4 sind wahr. Die Aussagen 1, 2, 5, 6 sind falsch.
Siehe auch[Bearbeiten]Grundlagen und weitere Einzelheiten sind in den folgenden Kapiteln zu finden:
Wikipedia bietet verschiedene grundlegenden Informationen:
Was sind primär und Fremdschlüssel?Was bei der Verknüpfung in der einen Tabelle der Primärschlüssel ist, ist in der zweiten Tabelle der Fremdschlüssel. Der Fremdschlüssel enthält den gleichen Wert wie der Primärschlüssel, kann aber öfters vorkommen (je nach Beziehungsart). So kann er einmal, niemals oder mehrmals vorkommen.
Was ist ein Primärschlüssel in einer Datenbank?Eine Tabelle verfügt normalerweise über eine Spalte oder eine Kombination aus Spalten, die Werte enthalten, die jede Zeile in der Tabelle eindeutig identifizieren. Diese Spalte oder Kombination aus Spalten wird als Primärschlüssel (PK, Primary Key) der Tabelle bezeichnet und erzwingt die Entitätsintegrität der Tabelle.
Welche Aufgabe hat der Fremdschlüssel?Fremdschlüssel (FK, Foreign Key)
Ein Fremdschlüssel verweist auf einen Primärschlüssel einer anderen oder dergleichen Tabelle und dient dazu Verbindungen zwischen verschiedenen Tabellen herstellen zu können.
Welche Eigenschaften hat ein Primärschlüssel?In der Tabelle "Kunden" handelt es sich um den Primärschlüssel.. Er identifiziert jede Zeile eindeutig.. Er ist niemals leer oder Null und enthält immer einen Wert.. Er ändert sich selten (idealerweise nie). |