it-swarm.com.de

Kann ein Fremdschlüssel NULL und/oder ein Duplikat sein?

Bitte klären Sie zwei Dinge für mich:

  1. Kann ein Fremdschlüssel NULL sein?
  2. Kann ein Fremdschlüssel dupliziert werden?

Soweit ich weiß, sollte NULL nicht in Fremdschlüsseln verwendet werden, aber in einigen meiner Anwendungen kann ich NULL sowohl in Oracle als auch in SQL Server eingeben und weiß nicht, warum.

225
jams

Kurze Antwort: Ja, es kann NULL oder doppelt sein.

Ich möchte erklären, warum ein Fremdschlüssel möglicherweise null sein muss oder eindeutig oder nicht eindeutig sein muss. Erinnern Sie sich zuerst an einen Fremdschlüssel, muss der Wert in diesem Feld zuerst in einer anderen Tabelle (der übergeordneten Tabelle) vorhanden sein. Das ist alles, was ein FK per Definition ist. Null per Definition ist kein Wert. Null bedeutet, dass wir den Wert noch nicht kennen.

Lassen Sie mich ein Beispiel aus dem wirklichen Leben geben. Angenommen, Sie haben eine Datenbank, in der Verkaufsvorschläge gespeichert werden. Angenommen, jedem Angebot ist nur ein Verkäufer und ein Kunde zugeordnet. Ihre Vorschlagstabelle hätte also zwei Fremdschlüssel, einen mit der Kunden-ID und einen mit der Vertriebsmitarbeiter-ID. Zum Zeitpunkt der Erstellung des Datensatzes wird jedoch nicht immer ein Vertriebsmitarbeiter zugewiesen (da noch niemand zur Bearbeitung berechtigt ist). Daher ist die Kunden-ID ausgefüllt, die Vertriebsmitarbeiter-ID ist jedoch möglicherweise null. Mit anderen Worten: In der Regel benötigen Sie die Möglichkeit, eine Null-FK zu haben, wenn Sie den Wert zum Zeitpunkt der Dateneingabe möglicherweise nicht kennen. Sie kennen jedoch andere Werte in der Tabelle, die eingegeben werden müssen. Um Nullen in einem FK zuzulassen, müssen Sie im Allgemeinen nur Nullen für das Feld zulassen, das den FK enthält. Der Nullwert ist unabhängig von der Vorstellung, dass es sich um einen FK handelt. 

Ob es eindeutig oder nicht eindeutig ist, bezieht sich darauf, ob die Tabelle eine Eins-zu-Eins-viele-Beziehung zur übergeordneten Tabelle hat. Wenn Sie nun eine Eins-zu-Eins-Beziehung haben, ist es möglich, dass Sie alle Daten in einer Tabelle haben, aber wenn die Tabelle zu groß wird oder wenn die Daten zu einem anderen Thema gehören (das Beispiel für die Arbeitnehmerversicherung @tbone) zum Beispiel), dann wollen Sie separate Tabellen mit einem FK. Sie möchten dann diesen FK entweder auch den PK (der die Eindeutigkeit garantiert) machen oder eine eindeutige Einschränkung darauf setzen. 

Die meisten FKs beziehen sich auf eine Eins-zu-Viele-Beziehung, und das ist es, was Sie von einem FK erhalten, ohne eine weitere Einschränkung für das Feld hinzuzufügen. So haben Sie beispielsweise eine Auftragstabelle und die Auftragsdetails-Tabelle. Wenn der Kunde zehn Artikel gleichzeitig bestellt, verfügt er über einen Auftrag und zehn Auftragsdatensätze, die dieselbe Auftrags-ID wie der FK enthalten. 

401
HLGEM

1 - Ja, seit mindestens SQL Server 2000.

2 - Ja, solange es sich nicht um eine UNIQUE-Einschränkung oder um einen eindeutigen Index handelt.

46
JNK

Aus dem Munde des Pferdes:

Fremdschlüssel lassen Schlüsselwerte zu, die alle NULL sind, auch wenn kein .__ vorhanden ist. übereinstimmende PRIMARY- oder UNIQUE-Tasten 

Keine Einschränkungen für den Fremdschlüssel

Wenn für den Fremdschlüssel keine anderen Einschränkungen definiert sind, eine beliebige Zahl von Zeilen in der untergeordneten Tabelle können auf denselben Wert des übergeordneten Schlüssels verweisen. Dieses Modell erlaubt Nullen im Fremdschlüssel. ...

NOT NULL-Einschränkung für den Fremdschlüssel

Wenn in .__ keine Nullen zulässig sind. Bei einem Fremdschlüssel muss jede Zeile in der untergeordneten Tabelle explizit auf eine .__-Anweisung verweisen. Wert im übergeordneten Schlüssel, da im fremden .__ keine Nullen zulässig sind. Schlüssel.

Eine beliebige Anzahl von Zeilen in der untergeordneten Tabelle kann auf dasselbe übergeordnete Element verweisen. Schlüsselwert, so dass dieses Modell eine Eins-zu-Viele-Beziehung herstellt zwischen dem übergeordneten und dem fremden Schlüssel. Jede Zeile im untergeordneten Tabelle muss einen Verweis auf einen übergeordneten Schlüsselwert haben. das Fehlen eines Wert (eine Null) im Fremdschlüssel ist nicht zulässig. Dasselbe Beispiel in Der vorige Abschnitt kann verwendet werden, um eine solche Beziehung zu veranschaulichen. In diesem Fall müssen die Mitarbeiter jedoch einen Verweis auf ein bestimmtes .__ haben. Abteilung.

EINZIGARTIGE Einschränkung für den Fremdschlüssel

Wenn eine UNIQUE-Einschränkung .__ ist. Für den Fremdschlüssel definiert, kann nur eine Zeile in der untergeordneten Tabelle einen angegebenen übergeordneten Schlüsselwert referenzieren. Dieses Modell erlaubt Nullen in der Unbekannter Schlüssel.

Dieses Modell stellt eine Eins-zu-Eins-Beziehung zwischen dem übergeordneten Element her und Fremdschlüssel, die unbestimmte Werte (Nullwerte) in der .__ zulassen. Unbekannter Schlüssel. Nehmen Sie beispielsweise an, dass die Employee-Tabelle eine Spalte hatte genannt MEMBERNO, bezieht sich auf eine Mitarbeiter-Mitgliedsnummer in der Versicherung der Firma. Eine Tabelle mit dem Namen INSURANCE hat auch eine primäre Schlüssel mit dem Namen MEMBERNO, und andere Spalten der Tabelle behalten die jeweiligen Informationen in Bezug auf eine Arbeitnehmerversicherung. Die MEMBERNO in Die Employee-Tabelle muss sowohl ein Fremdschlüssel als auch ein eindeutiger Schlüssel sein:

  • So setzen Sie referenzielle Integritätsregeln zwischen EMP_TAB und .__ durch. INSURANCE-Tabellen (die FOREIGN KEY-Einschränkung)

  • Um zu gewährleisten, dass jeder Mitarbeiter eine eindeutige Mitgliedsnummer hat (Schlüsselbedingung UNIQUE)

UNIQUE- und NOT NULL-Einschränkungen für den Fremdschlüssel

Wenn beide UNIQUE und NOT NULL-Einschränkungen sind für den Fremdschlüssel definiert, nur eine Zeile in der untergeordneten Tabelle kann auf einen bestimmten übergeordneten Schlüsselwert verweisen, und weil NULL-Werte sind im Fremdschlüssel nicht zulässig. Jede Zeile im untergeordneten Element Die Tabelle muss explizit auf einen Wert im übergeordneten Schlüssel verweisen.

Sieh dir das an:

Oracle 11g-Link

37
tbone

Ja, Fremdschlüssel können, wie bereits von älteren Programmierern angegeben, null sein. Ich würde ein weiteres Szenario hinzufügen, bei dem Fremdschlüssel null sein muss .... Angenommen, wir haben Tabellenkommentare, Bilder und Videos in einer Anwendung, die Kommentare zulässt zu Bildern und Videos. In der Kommentartabelle können wir zwei Fremdschlüssel-PictureId und VideosId zusammen mit der Primärschlüssel-Kommentar-ID verwenden. Wenn Sie also ein Video kommentieren, wäre nur VideosId erforderlich, und pictureId wäre null. Wenn Sie ein Bild kommentieren, wäre nur PictureId erforderlich, und VideosId wäre null. 

15

es hängt davon ab, welche Rolle dieser foreign key in Ihrer Beziehung spielt.

  1. wenn dieses foreign key auch ein key attribute in Ihrer Beziehung ist, kann es nicht NULL sein
  2. wenn dies foreign key ein normales Attribut in Ihrer Beziehung ist, kann es NULL sein.
5
shinxg

Hier ein Beispiel mit Oracle-Syntax:
Zuerst erstellen wir eine Tabelle COUNTRY

CREATE TABLE TBL_COUNTRY ( COUNTRY_ID VARCHAR2 (50) NOT NULL ) ;
ALTER TABLE TBL_COUNTRY ADD CONSTRAINT COUNTRY_PK PRIMARY KEY ( COUNTRY_ID ) ;

Erstellen Sie die Tabelle PROVINCE

CREATE TABLE TBL_PROVINCE(
PROVINCE_ID VARCHAR2 (50) NOT NULL ,
COUNTRY_ID  VARCHAR2 (50)
);
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_PK PRIMARY KEY ( PROVINCE_ID ) ;
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_COUNTRY_FK FOREIGN KEY ( COUNTRY_ID ) REFERENCES TBL_COUNTRY ( COUNTRY_ID ) ;

In Oracle läuft das einwandfrei. Beachten Sie, dass der Fremdschlüssel COUNTRY_ID in der zweiten Tabelle nicht "NOT NULL" enthält.

Um nun eine Zeile in die PROVINCE-Tabelle einzufügen, genügt es, nur die PROVINCE_ID anzugeben. Wenn Sie jedoch auch eine COUNTRY_ID angeben, muss diese bereits in der Tabelle COUNTRY vorhanden sein.

3
Mouhcine

Standardmäßig gibt es keine Einschränkungen für den Fremdschlüssel. Der Fremdschlüssel kann null und doppelt sein.

wenn Sie beim Erstellen einer Tabelle/Ändern der Tabelle eine Einschränkung der Eindeutigkeit oder nicht null hinzufügen, werden nur die Werte für null/Duplikate nicht zulässig.

1
nitin lalwani

Einfach ausgedrückt: "Nicht identifizierende" Beziehungen zwischen Entitäten sind Bestandteil von ER-Model und stehen in Microsoft Visio zur Verfügung, wenn Sie ER-Diagram entwerfen. Dies ist erforderlich, um die Kardinalität zwischen Entitäten des Typs "Null oder mehr als Null" oder "Null oder Eins" durchzusetzen. Beachten Sie diese "Null" in der Kardinalität anstelle von "Eins" in "Eins zu Viele".

Ein Beispiel für eine nicht identifizierende Beziehung, bei der die Kardinalität "null" (nicht identifizierend) sein kann, ist, wenn wir sagen, dass ein Datensatz/Objekt in einer Entität-A "einen Wert als Referenz auf den Datensatz haben kann" oder "nicht"/s in einem anderen Entity-B. 

Da es eine Möglichkeit gibt, dass sich ein Datensatz der Entität-A gegenüber den Datensätzen anderer Entity-B identifiziert, sollte es in Entity-B eine Spalte geben, um den Identitätswert des Datensatzes von Entity-B zu erhalten. Diese Spalte kann "Null" sein, wenn kein Datensatz in Entity-A den Datensatz bzw. die Datensätze (oder Objekte) in Entity-B identifiziert. 

Im objektorientierten (realen) Paradigma gibt es Situationen, in denen ein Objekt der Klasse B nicht notwendigerweise (stark gekoppelt) vom Objekt der Klasse A abhängig ist, was bedeutet, dass die Klasse B lose mit der Klasse B gekoppelt ist. Eine solche Klasse A kann ein Objekt der Klasse A "enthalten" (Containment), während das Objekt der Klasse B im Gegensatz zu dem Objekt der Klasse B ein Objekt der Klasse A enthalten muss (Zusammensetzung). B) Schöpfung.

Aus Sicht der SQL-Abfrage können Sie alle Datensätze in Entität-B abfragen, die "nicht null" für Fremdschlüssel sind, die für Entity-B reserviert sind. Dadurch werden alle Datensätze mit bestimmten entsprechenden Werten für Zeilen in Entity-A angezeigt. Alternativ werden alle Datensätze mit dem Wert Null die Datensätze sein, für die in Entity-A in Entity-B kein Datensatz vorhanden ist.

0
Fakhar

Die Idee eines Fremdschlüssels basiert auf dem Konzept, auf einen Wert zu verweisen, der bereits in der Haupttabelle vorhanden ist. Aus diesem Grund wird es in der anderen Tabelle als Fremdschlüssel bezeichnet. Dieses Konzept wird als referentielle Integrität bezeichnet. Wenn ein Fremdschlüssel als Nullfeld deklariert wird, verstößt er gegen die Logik der referentiellen Integrität. Worauf wird es sich beziehen? Es kann sich nur auf etwas beziehen, das in der Haupttabelle vorhanden ist. Daher ist es meines Erachtens falsch, ein Fremdschlüsselfeld als null zu deklarieren. 

0
SQLDev