外键可以是 NULL 和/或重复的吗？

Question

请为我澄清两件事：

1. 外键可以是 NULL 吗？
2. 外键可以重复吗？

据我所知， NULL不应该用于外键，但在我的某些应用程序中，我可以在 Oracle 和 SQL 服务器中输入NULL ，我不知道为什么。

Answer 1

简短回答：是的，它可以是 NULL 或重复。

我想解释为什么外键可能需要为空或可能需要唯一或不唯一。 首先记住外键只是要求该字段中的值必须首先存在于不同的表（父表）中。 这就是 FK 的定义。 根据定义，空不是一个值。 Null 意味着我们还不知道这个值是什么。

让我给你举一个现实生活中的例子。 假设您有一个存储销售建议的数据库。 进一步假设每个提案只分配了一名销售人员和一名客户。 因此，您的提案表将有两个外键，一个是客户 ID，另一个是销售代表 ID。 但是，在创建记录时，并不总是分配销售代表（因为还没有人可以自由地处理它），因此填写了客户 ID，但销售代表 ID 可能为空。 换句话说，当您在输入数据时可能不知道它的值，但您知道表中需要输入的其他值时，通常您需要具有空 FK 的能力。 要在 FK 中允许空值，通常您所要做的就是在具有 FK 的字段上允许空值。 空值与其作为 FK 的想法是分开的。

是否唯一与表与父表是一对一还是一对多关系有关。 现在，如果您有一对一的关系，您可以将所有数据都放在一个表中，但是如果表太宽或者数据属于不同的主题（员工 - 保险示例@tbone 给出了例如），那么您需要带有 FK 的单独表。 然后，您可能想让这个 FK 也成为 PK（保证唯一性）或对其施加唯一约束。

大多数 FK 是一对多的关系，这就是您从 FK 中获得的，而无需在该领域增加进一步的约束。 例如，您有一个订单表和订单详细信息表。 如果客户一次订购十件商品，则他有一个订单和十个订单明细记录，其中包含与 FK 相同的订单 ID。

Answer 2

1 - 是的，至少从 SQL Server 2000 开始。

2 - 是的，只要它不是UNIQUE约束或链接到唯一索引。

Answer 3

从马嘴里说：

外键允许全为 NULL 的键值，即使没有匹配的 PRIMARY 或 UNIQUE 键

外键没有限制

当外键上没有定义其他约束时，子表中的任意数量的行都可以引用相同的父键值。 此模型允许外键为空值。 ...

外键的 NOT NULL 约束

当外键中不允许出现空值时，子表中的每一行都必须显式引用父键中的一个值，因为外键中不允许出现空值。

子表中的任意多行都可以引用同一个父键值，因此该模型在父键和外键之间建立了一对多的关系。 但是，子表中的每一行都必须有一个对父键值的引用； 不允许在外键中缺少值（空值）。 可以使用上一节中的相同示例来说明这种关系。 但是，在这种情况下，员工必须参考特定部门。

外键的唯一约束

当在外键上定义了 UNIQUE 约束时，子表中只有一行可以引用给定的父键值。 此模型允许外键为空值。

此模型在父键和外键之间建立一对一的关系，允许外键中存在未确定的值（空值）。 例如，假设员工表有一个名为 MEMBERNO 的列，它指的是公司保险计划中的员工会员编号。 此外，名为 INSURANCE 的表具有名为 MEMBERNO 的主键，该表的其他列保存与员工保险单相关的相应信息。 雇员表中的 MEMBERNO 必须既是外键又是唯一键：

• 在 EMP_TAB 和 INSURANCE 表之间强制执行参照完整性规则（FOREIGN KEY 约束）

• 保证每个员工都有唯一的会员编号（UNIQUE 键约束）

外键的 UNIQUE 和 NOT NULL 约束

当在外键上同时定义了 UNIQUE 和 NOT NULL 约束时，子表中只有一行可以引用给定的父键值，并且由于外键中不允许 NULL 值，因此子表中的每一行都必须显式引用父键中的一个值。

看到这个：

Oracle 11g 链接

Answer 4

是的，正如上面的高级程序员所说，外键可以为空......我会添加另一个场景，其中外键需要为空......假设我们在一个允许对图片和图片进行评论的应用程序中有表格评论，图片和视频视频。 在评论表中，我们可以有两个外键 PicturesId 和 VideosId 以及主键 CommentId。 因此，当您对视频发表评论时，仅需要 VideosId 并且 pictureId 将为空...如果您对图片发表评论，则仅需要 PictureId 并且 VideosId 将为空...

Answer 5

这取决于此外foreign key在您的关系中扮演的角色。

1. 如果此外foreign key也是您关系中的key attribute ，则它不能为 NULL
2. 如果此外foreign key是您关系中的正常属性，则它可以为 NULL。

Answer 6

这是使用 Oracle 语法的示例：
首先让我们创建一个表 COUNTRY

CREATE TABLE TBL_COUNTRY ( COUNTRY_ID VARCHAR2 (50) NOT NULL ) ;
ALTER TABLE TBL_COUNTRY ADD CONSTRAINT COUNTRY_PK PRIMARY KEY ( COUNTRY_ID ) ;

创建表 PROVINCE

CREATE TABLE TBL_PROVINCE(
PROVINCE_ID VARCHAR2 (50) NOT NULL ,
COUNTRY_ID  VARCHAR2 (50)
);
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_PK PRIMARY KEY ( PROVINCE_ID ) ;
ALTER TABLE TBL_PROVINCE ADD CONSTRAINT PROVINCE_COUNTRY_FK FOREIGN KEY ( COUNTRY_ID ) REFERENCES TBL_COUNTRY ( COUNTRY_ID ) ;

这在 Oracle 中运行得非常好。 请注意，第二个表中的 COUNTRY_ID 外键没有“NOT NULL”。

现在要将一行插入到 PROVINCE 表中，只需指定 PROVINCE_ID 就足够了。 但是，如果您也选择指定 COUNTRY_ID，则它必须已存在于 COUNTRY 表中。

Answer 7

默认情况下，外键没有限制，外键可以为空和重复。

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

Answer 8

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

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

由于实体 A 的一条记录有可能将自己标识为其他实体 B 的记录，因此实体 B 中应该有一列具有实体 B 记录的身份值。 如果实体 A 中没有记录标识实体 B 中的记录（或对象），则此列可能为“空”。

在面向对象（现实世界）范式中，有些情况下，B 类对象的存在不一定依赖（强耦合）A 类对象，这意味着 B 类与类松散耦合- A 类可以“包含”（Containment）A 类对象，而不是 B 类对象的概念必须具有（组合）A 类对象，因为它的（类对象- B) 创造。

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

Answer 9

外键可以为NULL吗？

现有答案侧重于单列方案。 如果我们考虑多列外键，我们可以使用MATCH [SIMPLE | PARTIAL | FULL] MATCH [SIMPLE | PARTIAL | FULL] SQL 标准中定义的MATCH [SIMPLE | PARTIAL | FULL]子句：

PostgreSQL-创建表

插入到引用列中的值使用给定的匹配类型与引用表和引用列的值进行匹配。 共有三种匹配类型：MATCH FULL、MATCH PARTIAL 和 MATCH SIMPLE（这是默认值）。 MATCH FULL将不允许多列外键的一列为空，除非所有外键列都为空； 如果它们都为空，则该行不需要在引用的表中具有匹配项。 MATCH SIMPLE允许任何外键列为空； 如果它们中的任何一个为空，则该行不需要在引用的表中具有匹配项。 MATCH PARTIAL尚未实施。

（当然，可以将 NOT NULL 约束应用于引用列以防止出现这些情况。）

例子：

CREATE TABLE A(a VARCHAR(10), b VARCHAR(10), d DATE , UNIQUE(a,b));
INSERT INTO A(a, b, d) 
VALUES (NULL, NULL, NOW()),('a', NULL, NOW()),(NULL, 'b', NOW()),('c', 'b', NOW());

CREATE TABLE B(id INT PRIMARY KEY, ref_a VARCHAR(10), ref_b VARCHAR(10));

-- MATCH SIMPLE - default behaviour nulls are allowed
ALTER TABLE B ADD CONSTRAINT B_Fk FOREIGN KEY (ref_a, ref_b) 
REFERENCES A(a,b) MATCH SIMPLE;

INSERT INTO B(id, ref_a, ref_b) VALUES (1, NULL, 'b');  

-- (NULL/'x') 'x' value does not exists in A table, but insert is valid
INSERT INTO B(id, ref_a, ref_b) VALUES (2, NULL, 'x');  

ALTER TABLE B DROP CONSTRAINT IF EXISTS B_Fk; -- cleanup

-- MATCH PARTIAL - not implemented
ALTER TABLE B ADD CONSTRAINT B_Fk FOREIGN KEY (ref_a, ref_b) 
REFERENCES A(a,b) MATCH PARTIAL;
-- ERROR:  MATCH PARTIAL not yet implemented

DELETE FROM B; ALTER TABLE B DROP CONSTRAINT IF EXISTS B_Fk; -- cleanup

-- MATCH FULL nulls are not allowed
ALTER TABLE B ADD CONSTRAINT B_Fk FOREIGN KEY (ref_a, ref_b) 
REFERENCES A(a,b) MATCH FULL;

-- FK is defined, inserting NULL as part of FK
INSERT INTO B(id, ref_a, ref_b) VALUES (1, NULL, 'b');
-- ERROR:  MATCH FULL does not allow mixing of null and nonnull key values.

-- FK is defined, inserting all NULLs - valid
INSERT INTO B(id, ref_a, ref_b) VALUES (1, NULL, NULL);

db<>小提琴演示

Answer 10

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

但答案是这一切都取决于业务。

Answer 11

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

Answer 12

我认为一个表的外键也是另一个表的主键。所以它不允许空值。所以外键中没有空值的问题。