Réponse courte :Oui, il peut être NULL ou en double.
Je veux expliquer pourquoi une clé étrangère peut avoir besoin d'être nulle ou peut avoir besoin d'être unique ou non unique. Rappelez-vous d'abord qu'une clé étrangère nécessite simplement que la valeur de ce champ existe d'abord dans une table différente (la table parent). C'est tout ce qu'un FK est par définition. Null par définition n'est pas une valeur. Null signifie que nous ne savons pas encore quelle est la valeur.
Permettez-moi de vous donner un exemple concret. Supposons que vous disposiez d'une base de données qui stocke les propositions commerciales. Supposons en outre que chaque proposition n'ait qu'un seul vendeur affecté et un seul client. Ainsi, votre table de proposition aurait deux clés étrangères, une avec l'ID client et une avec l'ID du représentant commercial. Cependant, au moment de la création de l'enregistrement, un commercial n'est pas toujours affecté (car personne n'est encore libre de travailler dessus), donc l'ID client est renseigné mais l'ID commercial peut être nul. En d'autres termes, vous devez généralement avoir la possibilité d'avoir un FK nul lorsque vous ne connaissez peut-être pas sa valeur au moment de la saisie des données, mais que vous connaissez d'autres valeurs dans le tableau qui doivent être saisies. Pour autoriser les valeurs nulles dans un FK, il vous suffit généralement d'autoriser les valeurs nulles sur le champ contenant le FK. La valeur nulle est distincte de l'idée qu'il s'agit d'un FK.
Qu'elle soit unique ou non unique dépend du fait que la table a une relation un-un ou un-plusieurs avec la table parent. Maintenant, si vous avez une relation un-un, il est possible que vous ayez toutes les données dans une seule table, mais si la table devient trop large ou si les données portent sur un sujet différent (l'employé - exemple d'assurance @tbone a donné par exemple), alors vous voulez des tables séparées avec un FK. Vous voudriez alors faire de ce FK soit également le PK (ce qui garantit l'unicité), soit lui imposer une contrainte d'unicité.
La plupart des FK sont pour une relation un à plusieurs et c'est ce que vous obtenez d'un FK sans ajouter de contrainte supplémentaire sur le champ. Vous avez donc une table de commande et la table des détails de la commande par exemple. Si le client commande dix articles à la fois, il a une commande et dix enregistrements de détail de commande qui contiennent le même ID de commande que le FK.
