none
Eine Fremdschlüsseltabelle für mehrere Primärschlüsseltabellen RRS feed

  • Frage

  • Hallo zusammen,

    ich versuche gerade, für eine umfangreichere Datenbank die Beziehungen zwischen den einzelnen Tabellen anzulegen.

    Ich habe bspw. eine Tabelle "Adresse", deren Primärschlüssel "ID" ist. Dann habe ich drei verschiedene Tabellen, als Beispiel "Person", "Serviceadresse", "Nutzer", welche über die Spalte "adresse" auf die ID der Tabelle "Adresse" verweisen. (In der Praxis gibt es noch viel mehr dieser Verweise)

    Die Tabellen sind auch gut mit Daten gefüllt. Mein Problem ist jetzt, dass ich scheinbar keine Beziehung zwischen "Person" und "Adresse" herstellen kann, weil "Adresse" ja auch von anderen Tabellen genutzt wird, es somit Einträge gibt, zu welchen sich in "Person" kein Schlüssel befindet. Ich erhalte dann immer folgende Fehlermeldung:

    - Die Beziehung "FK_iPerson_adresse" kann nicht erstellt werden.  
    Die ALTER TABLE-Anweisung steht in Konflikt mit der FOREIGN KEY-Einschränkung "FK_iPerson_adresse". Der Konflikt trat in der Isipp_xml_import-Datenbank, Tabelle "dbo.adresse", column 'ID' auf.

    Es gibt auch in der "Person"-Tabelle Einträge ohne verknüpfte Adresse.

    Wie kann ich das umgehen? Mit "Vorhandene Daten bei Erstellung oder Reaktivierung überprüfen: nein" geht es, nur weiß ich da nicht, wie sich das zukünftig auf das Befüllen der Datenbank aus der Anwendung heraus auswirkt.

    Weiß jemand Rat?

    Grüße

    Eiko


    • Bearbeitet Eiko Richter Donnerstag, 10. Oktober 2019 20:57
    Donnerstag, 10. Oktober 2019 20:56

Antworten

  • Ich habe meinen Fehler gefunden.

    In der "Person"-Tabelle gibt es Adress-IDs, welche in der "Adresse"-Tabelle nicht vorhanden sind. Ändere ich die testweise auf einen vorhandenen Wert, dann kann ich die Beziehung erstellen.

    • Als Antwort markiert Eiko Richter Donnerstag, 10. Oktober 2019 21:15
    Donnerstag, 10. Oktober 2019 21:15

Alle Antworten

  • Ich habe meinen Fehler gefunden.

    In der "Person"-Tabelle gibt es Adress-IDs, welche in der "Adresse"-Tabelle nicht vorhanden sind. Ändere ich die testweise auf einen vorhandenen Wert, dann kann ich die Beziehung erstellen.

    • Als Antwort markiert Eiko Richter Donnerstag, 10. Oktober 2019 21:15
    Donnerstag, 10. Oktober 2019 21:15
  • Foreign Key ist ja gleichzeitig eine ein "referential Constraint", also eine Muss-Beziehung zwischen Tabellen (analog zu einer Parent->Child-Beziehung).
    Dies führt u.a. auch dazu, dass der Fremdschlüssel nicht gelöscht werden kann, so lange es noch Childs gibt.

    Wenn du also Personen ohne Adressen hast, so musst du die Adressen mit den Verweis-Id's erstellen, denn da hat wohl jemand Adressen gelöscht obwohl die Personen noch da sind.
    Zukünftig wird das dann nicht mehr gehen.
    Freitag, 11. Oktober 2019 08:45
  • Dass es Personen ohne Adresse (also mit NULL) gibt ist Standard in der Anforderung der Anwendung an die Datenbank. Das müsste ich halt mal testen, ob ich nach dem Erstellen der Beziehung Personen ohne Adresse anlegen kann.

    In der Datenbank löscht eigentlich niemand herum, hier muss ich meine Anwendung daraufhin überprüfen, ob sie beim Import der Daten irgendwo einen Fehler beim Ermitteln des Adresse-Indexes gemacht hat. Glücklicherweise sind es nur 5 von 20k Einträgen, welche nen Fehler haben.

    Freitag, 11. Oktober 2019 13:22
  • Ein Foreign Key darf leider nicht NULL sein, sonst wäre es kein Constraint.
    Hier gilt dieselbe Bedingung wie Unique-Key, der auch nicht NULL sein darf.

    Also solltest du eine Adresse "Not Assigned" erstellen und diese den NULL-Personen zuweisen wenn ein Foreign Key benötigt wird.

    Freitag, 11. Oktober 2019 15:12
  • Ein Foreign Key darf leider nicht NULL sein, sonst wäre es kein Constraint.

    Warum sollte ein FK nicht NULL sein dürfen?

    Der PK der Tabelle, die die FKs bereitstellt, darf natürlich nicht NULL sein, die Spalte in der Tabelle, die auf den FK verweist, aber natürlich schon. Macht ja sonst auch oftmals überhaupt keinen Sinn.

    Also solltest du eine Adresse "Not Assigned" erstellen und diese den NULL-Personen zuweisen wenn ein Foreign Key benötigt wird.

    Iiiiiiiikh. Nicht dein Ernst, oder?

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport


    Freitag, 11. Oktober 2019 15:48
    Moderator
  • Ein Foreign Key darf leider nicht NULL sein, sonst wäre es kein Constraint.
    Hier gilt dieselbe Bedingung wie Unique-Key, der auch nicht NULL sein darf.

    Also solltest du eine Adresse "Not Assigned" erstellen und diese den NULL-Personen zuweisen wenn ein Foreign Key benötigt wird.

    Irgendwelche NULL-Datensätze zu erstellen ist nicht möglich/nicht praktikabel.

    Darf der FK nicht NULL sein oder kann er nicht?

    Laut dem hier geht es ja:

    https://social.msdn.microsoft.com/Forums/sqlserver/de-DE/325c11b9-e5c4-4db7-94e6-f82b44412b9b/is-it-possible-to-allow-null-values-in-foreign-key?forum=transactsql

    Und wie Stefan sagt, der PK ist ja eindeutig und nicht NULL.


    Freitag, 11. Oktober 2019 16:12
  • Nun ja, wenn man so seine Gedanken schweifen lässt.
    Die Richtung muss natürlich stimmen;-).

    Ich bezog mich halt auf die Fehlermeldung, dass ein Konflikt auftritt.

    https://docs.microsoft.com/de-de/sql/relational-databases/tables/create-foreign-key-relationships?view=sql-server-2017

    D.h., dass ID in dbo.Adresse aktuell nicht Unique ist. Hier wird eine N:1-Bedingung benötigt:
    N-Personen können 1 Adresse haben.


    • Bearbeitet bfuerchau Freitag, 11. Oktober 2019 16:35
    Freitag, 11. Oktober 2019 16:34