默认情况下，对外键没有约束，外键可以为null和重复。

在创建表/修改表时，如果你添加了唯一性或非空的约束，那么只有它不允许空值/重复值。

我认为最好考虑一下表中可能存在的基数。 我们可以让最小的基数为0。当它是可选的时，相关表的元组的最小参与可以是零，现在你面临着外键值被允许为空的必要性。

但答案是，这完全取决于业务。

默认情况下，对外键没有约束，外键可以为null和重复。

在创建表/修改表时，如果你添加了唯一性或非空的约束，那么只有它不允许空值/重复值。

简单地说，实体之间的“非识别”关系是ER-Model的一部分，在设计ER-Diagram时可以在Microsoft Visio中使用。这需要在类型为“0或大于0”或“0或1”的实体之间强制执行基数。注意基数中的“0”，而不是“一对多”中的“1”。

现在，一个非识别关系的例子，其中基数可能是“零”(非识别)，当我们说一个实体- a中的记录/对象“可能”或“可能”有一个值作为对另一个实体- b中的记录/s的引用。

由于实体a的一条记录有可能向其他实体b的记录标识自己，因此实体b中应该有一列具有实体b记录的标识值。如果实体a中没有记录标识实体b中的记录或对象，则此列可能为“Null”。

在面向对象(现实世界)范式中，b类对象的存在不一定依赖于a类对象(强耦合)，这意味着b类与a类是松散耦合的，因此a类可以“包含”a类对象(Containment)，而不是b类对象必须有a类对象(Composition)的概念，才能创建b类对象。

从SQL Query的角度来看，可以查询实体b中所有“非空”的外键为实体b保留的记录。这将为实体a中的行带来具有特定对应值的所有记录，或者所有具有Null值的记录将是实体b中实体a中没有任何记录的记录。

外键的思想是基于引用一个已经存在于主表中的值的概念。这就是为什么在另一个表中它被称为外键。这个概念被称为参考完整性。如果外键被声明为空字段，它将违反引用完整性的逻辑。它指的是什么?它只能引用主表中存在的内容。因此，我认为将外键字段声明为null是错误的。

Yes foreign key can be null as told above by senior programmers... I would add another scenario where Foreign key will required to be null.... suppose we have tables comments, Pictures and Videos in an application which allows comments on pictures and videos. In comments table we can have two Foreign Keys PicturesId, and VideosId along with the primary Key CommentId. So when you comment on a video only VideosId would be required and pictureId would be null... and if you comment on a picture only PictureId would be required and VideosId would be null...