Die Spalte (oder Spalten) eines Primärschlüssels müssen NOT NULL sein. Ein Datensatz kann nicht eindeutig durch eine NULL identifiziert werden. Daher müssen die ID-Spalten am referenzierten Ende des Fremdschlüssels als NOT NULL definiert werden.
Es ist jedoch eine legitime Entwurfsentscheidung, dass eine Fremdschlüsselbeziehung optional ist, und die Art und Weise, dies darzustellen, besteht darin, das referenzierende Ende des Schlüssels optional zu machen, d. h. NULLen zuzulassen.
In Bezug auf die Datenmodellierung haben Sie einen (exklusiven) Bogen beschrieben:"eine Tabelle ... mit zwei oder mehr Fremdschlüsseln, von denen einer und nur einer nicht null sein kann." Bei der logischen Modellierung sind Bögen vollkommen akzeptabel, aber es gibt eine starke Meinung dafür, sie als separate Tabellen zu implementieren. In Ihrem Szenario wäre das ein generischer Sale Tabelle plus zwei Untertyptabellen, VehicleSale und PieceSale .
Die Vorteile der separaten Tabellenimplementierung sind:
- Einfachere Durchsetzung der Fremdschlüsselbeschränkungen;
- Einfaches Hinzufügen zusätzlicher Spalten in Bezug auf (z. B.) Fahrzeugverkäufe, die nicht für Stückverkäufe gelten;
- einfachere Erweiterung des Modells um zusätzliche Untertypen;
- klareres Datenmodell, das die Anwendungsentwicklung vereinfachen kann.
Die Vorteile liegen jedoch nicht nur in einer Richtung. Es ist zwar ziemlich einfach, dafür zu sorgen, dass ein Sale gilt entweder für einen VehicleSale oder ein PieceSale aber nicht beides, wodurch eine Regel erzwungen wird, dass ein Sale muss einen untergeordneten Datensatz zu haben, wird ziemlich knorrig.
Der vorherrschende Rat ist also, dass ein exklusiver Bogen falsch ist, und es ist im Allgemeinen ein guter Rat. Aber es ist nicht so klar, wie manche glauben.
