1

我试图理解 Edgar Codd 在 1970 年最初定义的关系模型规则。

具体来说，我对参照完整性是否是他的关系模型的一部分感兴趣。我将尝试在以下示例中进行演示（只是为了使这个问题变得漂亮）：

顾客

+------+------------
| Name | Address
|------+------------
| John | ....
| Mike | ....
| Kate | ....
+------+------------

发票

+------+------------
|  ID  | Customer
|------+------------
|   1  | John
|   2  | John
|   3  | Mary
+------+------------

现在，显然如您所见，我们有一张客户（外键）为Mary的发票。这会违反他的关系模型吗？Edgar Codd 会不会看着这个说，哎呀，这到底是怎么回事？或者他会说，这完全没问题……

这是理论上的问题。

4

6 回答 6

4

如果 Customers 表中没有名为 Mary 的客户，则表之间不存在参照完整性。具体来说，外键是指不存在的主键。

这会破坏关系模型吗？不，它是在关系模型中定义的（即缺乏参照完整性），并且表明基础数据存在问题。

摘自 Edgar Codd 的“大型共享数据库的数据关系模型”（摘自 Communications of the ACM，第 13 卷，第 6 期，1970 年 6 月）：

可能是用户打算将一些其他元素插入到 P 中 - 一个元素的插入会将一致状态转换为一致状态。关键是系统通常无法在不询问其环境（可能是造成不一致的用户）的情况下解决此问题。

因此，假定存在引用完整性问题，并且需要用户或系统通过某种编程方法解决这些问题。

于 2009-03-16T16:23:29.210 回答
3

对于被认为是关系完整的语言（Codd 创造的短语），它必须支持一组关系运算符，称为关系代数。请注意，没有一个真正的关系代数：Codd 提出了第一个，但其他人已经改进并建立在 Codd 的基础上（例如The Third Manifesto），我相信他会认为这是正确和正确的。

参照完整性不是关系运算符，因此不是语言关系完整性的要求。参照完整性约束是DBMS的有用还是必要的特性是另一回事。

于 2011-03-23T11:36:09.640 回答
2

我阅读了以下内容，清楚地说明了关系模型中包含参照完整性：

两个完整性规则适用于每个关系数据库：

1 实体完整性：
在作为基础关系主键组成部分的任何属性中都不允许使用任何一种类型的标记

2 参照完整性：
设 D 是一个域，一个或多个单属性主键从中提取它们的值。假设 K 是一个外键，它从域 D 中提取其值。出现在 K 中的每个未标记值也必须作为某个基本关系的主键中的值存在于数据库中。

“关系数据库中的缺失信息（适用和不适用） ”，EF Codd，ACM SIGMOD 记录，第一卷。15，没有。4，第 53-78 页，1986 年。

通过“任一类型的标记”，他指的是一个未知值，我们今天使用 NULL。本文提出了两种不同类型的未知值，一种是“适用但缺失”，一种是“不适用”。

通过“未标记”，他的意思是不为 NULL。

来自@dportas 的重新评论：确实，您甚至不需要引用的关系为空来提出您的论点。它可以包含一些行，但是由于不能说 K 中的 A 标记等于该引用关系中存在的任何值，因此无法说假设的缺失值满足约束条件。因此，允许 A-mark 必须成为一种信念行为，即一旦提供了一个值，它将满足约束，因为否则该行从插入的那一刻起就是无效的，我们必须支持的概念追溯约束违反，这是毫无意义的。

于 2009-03-16T17:33:29.337 回答
2

关系模型不需要引用完整性特性来应用于每个关系数据库——如果这些约束不相关或不想要，那将是荒谬的。想象一个由姓名、地址和会员编号组成的俱乐部会员名单。RI 约束不一定有任何用处，但如果数据以关系的形式存储，它仍然是一个关系数据库。

甚至 Codd 的 13 条规则也不要求 RDBMS 必须支持创建 RI 约束的能力。只是外键非常有用，以至于大多数 RDBMS 都希望拥有它们。

于 2011-03-16T15:05:09.703 回答
1

首先你要问的是 RM 的 RI 部分：

参照完整性是否是他的关系模型的一部分

是的。来自 Codd 的经典著作“你的 DBMS 真的是关系型的吗？” 计算机世界，1985 年 10 月 14 日：

然而，至关重要的是要记住关系模型包括三个主要部分：结构部分、操作部分和完整性部分——这是一个经常被遗忘的事实。

规则 10：特定于特定关系数据库的完整性约束必须可以在关系数据子语言中定义，并且可以存储在目录中，而不是存储在应用程序中。

但是随后您转述了一个不同且模棱两可的问题：

我们有一张发票，其中客户（外键）是 Mary。这会违反他的关系模型吗？

如果您的意思是：RM 是否允许违反声明的 FK，即不被 DBMS 阻止？

不，那将是一个允许您声明 FK 约束但不强制执行它的 DBMS。这样的 DBMS 在这方面是非关系型的。

如果您的意思是：RM 是否允许规定发票客户也必须出现在客户名称中的业务规则（即所有有效的数据库状态都是这样，即从发票客户到客户名称存在 FK 约束）不是向 DBMS 声明（例如通过 FK 声明）？

是的。但这是一个糟糕的设计，因为它允许一些无效状态。

于 2015-07-02T23:32:45.927 回答
0

我认为这是否可以取决于您的设计。

发票应包含发票创建或发送时的数据。因此，它似乎需要与客户数据相关但不直接与外键相关的数据，尤其是在您使用自然键时。

例如，假设 Mary Jones 订购了某样东西，并于 2010 年 5 月 31 日开具发票。2010 年 9 月 12 日，她将姓名更改为 Mary Jones-Smith，并搬到了她丈夫的地址。发票是一张及时的照片，应保留 Mary Jones 的姓名和原始地址。最好它还可以保留指向当前客户及其信息的链接（这就是为什么我会在名称更改时在客户表中拥有一个客户 ID 和一个 Customerid inteh incvoice 表的 FK）。但是当 Mary Jones 不再存在于 customer 表中时存储 Mary Jones 不仅没问题，还需要对实际发生的事情进行跟踪。

产品、价格和发票也是如此。您不希望发票反映现在的价格，而是反映发票时的过程，即使这与现在的情况没有直接关系。在这种情况下，Product 表可能更像是一个查找表，而不是真正的父子关系。如果您将产品的所有详细信息存储在发票明细表中，那么您不需要产品的外键，只需在下订单时查找有效产品即可。事实上，如果供应商更改它或完全放弃产品，过去发票的型号肯定不再出现在产品表中。但是您不希望丢失过去购买了哪些产品的数据。

另一方面，如果关系要求数据与当前值保持一致，那么正式的外键是最好的方法。

于 2011-09-13T20:34:22.137 回答