La colonne (ou les colonnes) d'une clé primaire doit être NOT NULL. Un enregistrement ne peut pas être identifié de manière unique par un NULL. Ainsi, les colonnes d'ID à l'extrémité référencée de la clé étrangère doivent être définies comme NON NULL.
Cependant, c'est une décision de conception légitime qu'une relation de clé étrangère soit facultative, et la façon de représenter cela est de rendre facultative la fin de référence de la clé, c'est-à-dire d'autoriser les valeurs NULL.
En termes de modélisation de données, ce que vous avez décrit est un arc (exclusif):"une table ... avec deux clés étrangères ou plus où une et une seule d'entre elles peut être non nulle". Dans la modélisation logique, les arcs sont parfaitement acceptables, mais il existe une forte opinion en faveur de leur mise en œuvre sous forme de tables séparées. Dans votre scénario, ce serait une Sale générique table plus deux tables de sous-type, VehicleSale et PieceSale .
Les avantages de l'implémentation de table séparée sont :
- plus facile d'appliquer les contraintes de clé étrangère ;
- plus facile d'ajouter des colonnes supplémentaires concernant (disons) les ventes de véhicules qui ne s'appliquent pas aux ventes à la pièce ;
- plus facile d'étendre le modèle avec des sous-types supplémentaires ;
- modèle de données plus clair, qui peut simplifier le développement d'applications.
Cependant, les avantages ne sont pas tous à sens unique. Bien qu'il soit assez facile de s'assurer qu'une Sale s'applique soit à une VehicleSale ou une PieceSale mais pas les deux, en appliquant une règle selon laquelle une Sale doit avoir un enregistrement enfant devient en fait assez épineux.
Ainsi, le conseil qui prévaut est qu'un arc exclusif est erroné, et c'est généralement un bon conseil. Mais ce n'est pas aussi clair que certains le prétendent.
