在How to Set Up Primary Keys in a Relation 问题中，PerformanceDBA谈到了关系完整性并指出它与引用完整性不同。
我听说过与外键有关的参照完整性。
但是关系完整性对我来说似乎很奇怪。
在这个问题中，关系完整性和参照完整性是一回事吗？，克里斯说两者是一回事。
数据库世界中的术语和定义真的让我很困惑。
有人可以解释关系完整性吗？
自Edgar F. Codd在 1970年的论文中提出关系模型以来，关系数据库理论已经建立了几十年。
但是，在书籍或网络上对范式、完整性等没有一致的定义。
作为一个学习者，我很困惑。
我将按照整体合理的顺序回答您的问题，并缩短篇幅。
自 Edgar F. Codd 在 1970 年的论文中提出关系模型以来，关系数据库理论已经建立了几十年。然而，在书籍或网络上，对范式、完整性等的定义并不一致。
作为一个学习者，我很困惑。
数据库世界中的术语和定义真的让我很困惑。
我想说，这是数据库行业最大的问题。有两个营地。
换句话说，任何有资格的人都可以理解并使用它们（不需要能够阅读和理解数学定义。）
高端 RDBMS 供应商就属于这个阵营。几十年来，他们与客户一起领导 SQL 委员会实施关系模型及其数据子语言 SQL 的特性和设施（请注意，SQL 不是一种语言，而是一种用于访问数据库的子语言）。
结果之一是关系模型的自然发展。批评者建议的功能是“不完整的”，已经“完成”并实施了。任何忠实实施关系模型的人都会将其视为自然进展，而不是“扩展”。
所有微小但重要的进步和进展都由为高端供应商工作的真正的理论家和科学家实施。（也就是说，无论是我、客户还是供应商，他们都提出了供应商实施的这种进步，都没有暗示关系模型是“不完整的”，或者我们“完成了”它。我们很高兴地接受这样的不是关系模型的“外部” 。）
非 SQL 和假装 SQL 不在此类别中。
真正的理论家和科学家的时代早已一去不复返了。我们现在拥有的是与他们声称服务的行业完全隔离的人；否认其他科学（例如物理定律、逻辑定律和常识）；以及撰写他们引用并因此提升的学术论文。学术论文和数学证明只是基于这样一个事实，即在这种否认和孤立的情况下，它们证明了他们打算证明的东西。事实证明在现实世界中是纯粹的垃圾，如果相关科学被否定，它只能是“真实的”，这与他们无关。
这种对现实的否认是精神分裂症。不幸的是，这些天他们在大学教授它。
因此，您看到论文被提升纯粹是因为它们有很多引用（来自精神分裂症患者），而不是基于它是否是科学。
对于一个没有被“教育”成精神分裂症的人来说，这样的论文很容易毁掉。在给你的另一个答案中，我已经证明了这一点：
我对 Hidders 的回应（其中他提出了他建议“解决”的“关系数据库”中的一个“问题”，而这个“问题”在将数据置于关系上下文中的简单行为中消失了。
我对 Köhler 的回应（其中他提出了“关系数据库”中的一个“问题”，他建议通过创建另一种新颖的“范式”来“解决”该问题，并且该“问题”在放置数据的简单行为中消失了在关系上下文中。
底线，除了“理论家”的论文是建立在稻草人方法上的证据之外，因此是错误的，是他们对他们声称正在撰写的关系模型一无所知的证据。
这是大规模的欺诈，因为它是在新的“教育”系统中建立的。
这个阵营最初是由“理论家”组成的。自关系模型出版以来的 45 年里，他们没有生产出任何东西来推动或改进它。
现在它由他们所有的追随者和支持者组成。而且因为他们写了书，现在被用作大学课程的教科书，它包括了所有像鹦鹉一样教这种垃圾的“教授”，没有亲自验证理论。
然而，他们产生了一堆碎片，他们声称这些碎片是“相关的”。他们将 Codd 的定义分解成小块，并孤立地处理每一个，要么攻击 Codd 定义，要么支持他们自己的片段。
例如。Codd 对1NF、2NF、3NF有清晰和直接的定义（最后包括功能依赖的定义），任何有能力的人都可以应用它们，这些生物有：
NF 的六个片段（“1NF”、“2NF”、“3NF”、“BCNF”（又名“3.5NF”）、“4NF”、“5NF”）
总而言之，甚至连 Codd 的三个 NF 所涵盖的内容的一小部分都没有涵盖。
这就是为什么我在其他答案中说过，如果一个人在精神和文字上理解并应用了 Codd 的三个 NF，它涵盖了上述六个 NF 片段，以及任何尚未编写的 NF 片段（由“理论家”）。
DKNF 是最终的 NF，并且显然是关系模型的目标（对于任何真正试图理解它的人），但没有这样定义。这是自然进程之一（上图），对于忠实的实施者来说是显而易见的。虽然我不会说这很容易，但它是完全可行的：自 2007 年以来我所有的数据库都是 DKNF。
当然，它们的片段是不完整的，它们永远在定义中寻找“漏洞”，并“填补”它们。“漏洞”没有尽头，“填充物”也没有尽头。Codd 的定义没有漏洞，也不需要填充符。
当然，它们的众多片段并没有整合在一起。这就是解体的定义。
他们产生了许多“关系代数”（我数不清）与 Codd 的关系代数竞争。当然，它们都没有比这更接近，并且 Codd 的关系代数被牢固地确立为关系代数。
他们声称关系模型在某种程度上是“不完整的”，而他们的发明“完成了”它。他们没有。他们的发明证明他们不理解他们建议“完成”的关系模型。这是欺诈的一部分，以提升他们原本令人难以置信的发明。
在做这一切的过程中，他们当然引入了混乱。作为关系模型的批评者，这就是他们的目标。他们的42个左右的“关系模型”和“关系代数”只能存在于混乱状态，从业者和寻求者对关系模型是什么感到困惑。
这个答案很长，只是因为为了回答你的问题，我必须首先消除混淆，关系模型不是什么，其次，确认关系模型是什么。如果这些生物没有引入所有这些欺诈，这种混乱，如果关系模型是清晰的，并且定义没有被破坏，那么问题的答案很简单直接：
但是对于混乱，这还不够，我必须提供更多的细节和证据，以消除混乱。
请注意，他们已经确立了一切都是见仁见智的观念；论据；这是主观的。当然，真相是客观的，不接受意见；讨论; 或论据。这很容易证明：只需阅读关系模型并亲自查看是否定义了某些内容，以及该定义是什么。
科德营和“理论家”古拉格之间的主要区别在于：
后 Codd 的作者不了解关系模型。在这四个十年中，除了他们没有在关系模型中添加一丁点这一事实之外，他们还建立了一个私有的“关系模型”（实际上是几个），具有他们的私有定义和私有术语。这方面的证据有四个：
首先，他们只了解关系模型的一小部分。他们不知道（例如）关系键；关系完整性。
其次，他们传播关系模型中明确禁止的各种发明：（例如）代理；访问路径依赖；循环引用。同样，这只有在他们不了解关系模型的情况下才有可能
第三，他们对术语有私有定义，与关系模型中的定义不匹配。仅此一项就可以保证他们脱离并且不服务于他们声称服务的行业。此外，他们无法与任何关系模型从业者交谈。
第四，他们有不在关系模型中的制造术语（和私有定义） 。但是他们欺骗性地宣称这些发明是“关系模型”的一部分。
总而言之，这意味着他们所实践和宣扬的“关系”或“关系模型”，远非关系，事实上，凭借证据，它是反关系的。
既然他们不理解关系模型，那么他们理解、传播的是什么？
好吧，从大量证据（即他们自己的著作：书籍、教科书、学术论文等）来看，他们只理解和传播我们在关系模型和 RDBMS出现之前所拥有的技术：1970 年前的记录归档系统。
它没有关系数据库（即符合关系模型的数据库）的完整性（我们将详细介绍）、功能或速度。
如果有人要求描述前关系型 DBMS 和关系型 DBMS 之间的区别，一句话，那就是前关系系统通过 Record ID关联记录 ，不控制记录的内容，而关系系统通过记录关联行Relational Key，具有对行内容的完全控制（完整性）。
上面确定的差异是理论上的，对于有理论基础的人来说是可以理解的（并且被“理论家”否认）。然而，即使对于新手来说，差异也很明显，在两个项目中（有很多，我正在揭露两个非常明显的项目），在这里我可以提供具体的证据：
关系模型需要一个主键，然后将其用作外键来建立关系。批评者将记录 ID 实现为“主键”，其中：
关系模型中Key的定义失败。（Key的关系模型定义是它必须由数据组成。记录 ID、GUID 等是制造出来的，它们不是数据。）
实现访问路径依赖，这在关系模型中是明确禁止的。访问路径依赖是前关系记录归档系统的特征限制。
（这导致必须在两个远端文件之间导航每个文件，而在关系模型中，可以直接连接两个远端表。）
（顺便说一句，这证明了记录归档系统实际上需要更多而不是更少的 JOIN，这与神话相反。）
因此，他们将代理项、记录 ID 提升到“关键”状态。
但这是纯粹的欺诈。关系世界中没有“代理键”这样的东西，因为这两个词相互矛盾，要么是代理（非键）x要么是键（非代理）。
此外，通过使用术语“代理键”，人们自然会期望至少某些（如果不是全部）键的特性，而代理不具有键的任何特性。
那是“理论家”世界中的“正常”，与关系世界脱节，因为他们没有钥匙，他们有代理人作为“钥匙”
他们有他们的发明，以及他们的私人定义，“候选钥匙”。
隐藏他们没有使用关系模型中定义的主键这一事实是一项发明，这本身就是对关系模型的破坏。
同样，这纯粹是欺诈，因为关系模型中没有定义这样的东西。所以，不管它是什么，它都在关系模型之外
它是什么 ？它是 Key 的片段。单独的代理不提供行唯一性，这在关系模型中是必需的。他们需要行唯一性来在他们的记录归档系统中建立一小部分完整性。
现在，请注意，此时要完整，因此代理始终是附加列，即。除了数据列。它从来都不是一个非此即彼的命题，正如许多新手（例如 Fowler 和 Ambler，例如那些提出它是“意见”但尚未达成“共识”的人）所建议的那样。
它是关系键的一个片段，因为“候选键”没有在记录归档系统中实现为跨文件的键。它仅在定义它的单个 File 中实现，因此不使用Relationally。而在关系模型中，这样的键将是主键，并且它将是该表的每个子表中的外键，即。它将在关系上跨表使用。
因此，它仍然是关系键的一个片段，仅存在于它所在的文件中。
当然，“候选键”不起作用。所以他们想出了另一个发明，让它发挥作用。“超级钥匙”。它也不起作用，并且需要大量重复。它不提供任何关系键的品质。它仅在失败的“候选密钥”之上提供了一个片段，一个步骤，因此整个事情仍然是失败的。
以功能依赖为例。由于引入了混乱和破坏，我们不得不将其称为全功能依赖。Codd 的 3NF 定义也给出了功能依赖的定义。这是简单的技术英语，很容易理解和实施。
最重要的是要理解，因为我们在谈论关系模型，所以当 Codd 使用术语 Key 时，他的意思是关系键。因此，必须首先确定密钥并使其可用，然后才能测试密钥上的属性的功能依赖性（这是一个测试），其次。
但是破坏者，颠覆者，已经发明了 3NF 定义的片段。我不会详细介绍（除非被问到），但是，如果你检查它们，你会发现它们有一个目的：欺骗性地将它们的非关系“候选密钥”提升到密钥的状态。
此外，他们对与 Codd 的 3NF 定义相关的片段（七个左右）的整套定义很复杂，普通的实现者无法理解，更不用说实现了。
概括。如果有人使用术语 {“candidate key”、“superkey”、“部分/传递依赖”[而不是完全功能依赖]}，他们就明确地将自己标识为 (a) 对关系模型一无所知，并且 ( b) 反关系。
结果，这是“理论家”的真正成就，是 95% 的实施者实施了记录归档系统，它们没有关系数据库的完整性、功能或速度，但他们认为他们的 RFS是“关系”。很遗憾，“理论家”不能承认并享受他们唯一的成就。
这是我们必须了解的，以便穿透混乱并识别虚假本身。如果您了解“理论家”在他们的 42 个左右的“关系模型”和“关系代数”上投入了大量资金，它们与关系模型有很大的不同，那么您就会明白，实际上，他们对关系模型一无所知.
但这并不能阻止他们对关系模型、它做什么、不能做什么等发表声明。因此，不要相信他们发表的任何声明，这就像一个侏儒在发表关于飞机飞行的声明（请参阅众神一定是疯了）。
关系数据库理论已经建立了几十年
真的。但仅限于行业的高端。像我这样的人。那些在理论和科学上有扎实基础的人，他们拒绝后科德时代的非科学。大多数人，95%，在反关系系统中受过教育。
在How to Set Up Primary Keys in a Relation 问题中，PerformanceDBA 谈到了关系完整性并指出它与引用完整性不同。
是的。
有人可以解释关系完整性吗？
是的。但只有真正的关系实践者才能做到这一点。
请注意，由于关系数据库行业的状况，引入的混乱，正在实施的大规模欺诈，如上所述，破坏者和颠覆者会说，要么没有，要么有，但不可能实现，或者它与参照完整性相同。
我听说过与外键有关的参照完整性。但是关系完整性对我来说似乎很奇怪。
在这个问题中，关系完整性和引用完整性是一回事吗？克里斯说两者是一回事。
不，他们不是。
如上所述，该陈述证明他对关系模型一无所知，并且他是反关系的。因此，他无法知道什么是关系模型，什么是关系完整性。他们不知道自己缺少什么，因此无法描述或定义它。
我可以。
让我们从参照完整性开始，以便我们知道 (a) 那是什么，以及 (b) 它与关系完整性有何不同。
我们需要一个体面的例子来工作。请注意，欺诈和窃贼使用简单的例子，因为任何事情都可以使用简单、陈词滥调的例子来证明（或反驳）。深入理解需要完整的示例，这些示例足够“复杂”以证明问题。
让我们使用一个我在 comp.databases.theory 上给“理论家”提供的例子来解决。他们无法解决。我给出了指示和提示。他们仍然无法解决。
这本身就是“理论家”无法规范任何事物的证据。尽管他们有 17 个数学定义来描述他们异常的、支离破碎的“正常形式”。
我们真的应该在屋顶上大喊大叫。他们没有资格告诉从业者任何事情。
这是一个开发人员的典型实现，他一直在阅读批评者的书籍，并仔细关注他们。作为典型，他认为这是“关系”。但它根本不是关系数据库，它是一个记录归档系统，没有关系数据库的完整性、功能或速度。
内容大家应该都很熟悉了，这里就不赘述了。请注意，前三个级别有 ISO 和 ANSI/FIPS 标准代码，例如。ISO-3166-1、3166-2 和 FIPS。
但他的“主键”不是主键，它们是记录 ID。
开发人员已将这组文件声明为“满足 5NF”。“理论家”就是这样通过的。
就 Codd 和我而言，（a）它失败了 3NF 和（b）它失败了关系。但我们不会在这里处理这个问题，我们只需要一个很好的例子来实现我们的目的，即关系完整性。
让我们看一下 Country File 的 DDL。
CREATE TABLE Country (
CountryId INT NOT NULL IDENTITY PRIMARY KEY,
CountryCode CHAR(2) NOT NULL,
Name CHAR(30) NOT NULL,
CONSTRAINT AK1 UNIQUE ( CountryCode ),
CONSTRAINT AK2 UNIQUE ( Name )
)
INSERT Country VALUES
( 'US', 'United States of America'),
( 'CA', 'Canada' ),
( 'AU', 'Australia' )
到现在为止还挺好。让我们看看状态文件。
CREATE TABLE State (
StateId INT NOT NULL IDENTITY PRIMARY KEY,
CountryId INT NOT NULL,
StateCode CHAR(2) NOT NULL,
Name CHAR(30) NOT NULL
CONSTRAINT AK1 UNIQUE ( CountryId, StateCode ),
CONSTRAINT AK2 UNIQUE ( CountryId, Name ),
CONSTRAINT Country_ConsistsOf_State_fk
FOREIGN KEY ( CountryId )
REFERENCES Country ( CountryId )
)
INSERT State VALUES
( 1, 'AL', 'Alabama' ),
( 1, 'GA', 'Georgia'),
( 1, 'NY', 'New York'),
( 2, 'NT', 'Northwest Territories'),
( 3, 'NT', 'Northern Territory')
请注意（例如）加拿大和澳大利亚都有一个州代码“NT”，并且备用键允许这样做。但还要注意，在插入州时，我们被迫使用记录 ID 而不是数据来标识正在插入的州的父国家/地区。这应该敲响警钟。
到目前为止还很普通。让我们看看县档案。
CREATE TABLE County (
CountyId INT NOT NULL IDENTITY PRIMARY KEY,
StateId INT NOT NULL,
CountyCode CHAR(2) NOT NULL,
Name CHAR(30) NOT NULL
CONSTRAINT County_UK1 ( StateId, CountyCode ),
CONSTRAINT County_UK2 ( StateId, Name ),
CONSTRAINT State_IsMadeUpOf_County_fk
FOREIGN KEY ( StateId )
REFERENCES State ( StateId )
)
INSERT County VALUES
( 1, 'LE', 'Lee' ),
( 2, 'LE', 'Lee'),
( 3, 'LE', 'Lee')
插入县时，我们被迫使用记录 ID 而不是数据来标识要插入的县的父州。这应该会敲响更多警钟。请注意，（例如）美国在 12 个州有一个名为“Lee”的县，但在纽约没有，而加拿大没有。
糟糕，我们刚刚将李县插入纽约州。这暴露了两个重要问题：
从用户的角度来看，以及用户用来维护归档系统中数据的应用程序，数据完整性非常低，因为数据标识非常少。（记录 ID 不是数据，用户甚至不应该看到它们。）
因此，即使应用程序提供了州的记录 ID，在确定之前，它也必须询问用户将县插入“哪个州”，并提供一个下拉菜单，其中（希望）包含州代码（最少）或按字母顺序排列的州名（更好）。
然后提取所选状态的记录 ID，放弃 StateCode。
从纯粹的数据角度来看，完全有可能识别一个县，并唯一地识别它（CountryCode-or-Name、StateCode-or-Name、CountryCode-or-Name）。
但是在“理论家”文件系统中，我们被阻止了。
那么问题是什么？
问题是，“理论家”不了解关系键或标识符（IDEF1X 术语）。因为他们不了解它，所以他们不知道自己缺少什么。
解决方案是使用关系键的关系模型。
有一点需要先了解。什么是主键？在 SQL 上下文中，即。在一个实现中，关键字的使用PRIMARY KEY不会神奇地将这样命名的列转换为主键（根据关系模型）。它只是在命名列上强制执行唯一性。
什么是参照完整性？
它只是FOREIGN KEY ... REFERENCES在 SQL 中使用关键字。它不会神奇地提供关系完整性。它仅在服务器（或非服务器，对于 NON-sqls）中提供强制执行，即在引用文件中标识的 FK 是被引用文件中的 PK。
让我们在这里停下来盘点一下。“理论家”和后 Codd 的作者只知道 RFS，很少知道 SQL。他们只知道参照完整性（而且大多数情况下，他们甚至没有实现这一点，但我们不要分心）。因此，他们无法以一种或另一种方式就他们不知道的事情发表声明。
关系完整性不仅仅是参照完整性。
EF Codd 博士要求我们从集合的角度来考虑数据。“理论家”不明白这一点。他们只知道两个集合：包含整个文件的集合；和空集。
在关系世界中，集合远不止这些。
在第一级，国家，当然，只有一组国家。
在第二个层次，国家，简单的集合是所有国家的所有国家。但是我们可以使用更多的关系集：
在第三级县，简单集是所有国家的所有县。但是我们可以使用更多的关系集：
属于一个州的每一组县，在一个国家中，即 Country-State-Counties。
当然，还有属于 Country 的每组 Counties，即 Country-Counties。
因此，虽然关系模型提供了这一点，但 RFS 中并未实现这一点，并且此类 RFS 中可能的完整性仅限于一次引用一个文件，而不是引用数据集。
现在让我们看看关系模型提供的完整性。
为了进行比较，我们需要将该示例转换为关系数据库。只看第 2 页的前三个表。
让我们看一下相同的插入：
INSERT Country VALUES
( 'US', 'United States of America'),
( 'CA', 'Canada' ),
( 'AU', 'Australia' )
INSERT State VALUES
( 'US', 'AL', 'Alabama' ),
( 'US', 'GA', 'Georgia'),
( 'US', 'NY', 'New York'),
( 'CA', 'NT', 'Northwest Territories'),
( 'AU', 'NT', 'Northern Territory')
这里我们说，状态的标识符或关系键是（ CountryCode，StateCode ）。“NT”的州代码没有警钟，因为国家代码使其独一无二。
INSERT County VALUES
( 'US', 'AL', 'LE', 'Lee' ),
( 'US', 'GA', 'LE', 'Lee' )
这里我们说，县的标识符或关系键是（ CountryCode，StateCode，CountyCode ）。我们不太可能犯把李县放在纽约州的错误，因为当我们进入它时，我们知道它是错误的，我们必须主动输入错误的东西“NY”。而当它是一个数字、一个 ID 字段时，我们没有任何线索：
INSERT County VALUES
( 'US', 'NY', 'LE', 'Lee' )
用关系术语总结一下：
在 Codd 后作者和“理论家”营销和传播的记录归档系统中，没有关系密钥；没有集合，它们只有 SQL 提供的参照完整性。
在具有关系键和集合的关系数据库中，除了 SQL 提供的参照完整性之外，我们还有关系完整性。
我有第二个例子和进一步的解释来完成这个。但是答案太长了。我必须把它转换成一个 WP 文件，把它放在一个链接中，等等。明天。
数据库状态代表一些世界情况。因为我们应该把关于世界的特定数据库的基本表放入其中，并且因为只能出现一些世界情况，所以只能出现一些数据库状态。如果数据库曾经拥有另一个状态，那将是一个错误。
数据库完整性是关于确保数据库永远不会包含无效状态。（例如，您会看到一个标题为“Integrity”或“Database Integrity”的教科书章节来讨论这个主题。）
“关系完整性”不是一个常用术语。我希望它指的是关系数据库的数据库完整性。约束统称为有效关系数据库状态的描述。关系 DBMS 启用它们的声明并强制执行它们。
人们也可以合理地使用它来表示遵守关系模型的原则。
参照完整性是关系数据库完整性的一个子主题，它是关于确保数据库永远不会包含由（取决于上下文）外键约束或 SQL FOREIGN KEY 约束所描述的那种无效状态，我们可以称之为外键约束超级键约束。（SQL 的 FOREIGN KEY 定义可以涉及对超键的引用，而不仅仅是外键约束中的候选键。）
真正重要的是关系模型的基本概念。通用和临时术语让我们参考它们。
毫无疑问，他打算使用术语（“关系完整性”）来表示“100% 忠实于 Codd 设计的原始模型”。这是一种稀有的财产。不要在 SQL 系统中寻找它。请记住，这不是一个艺术术语 - 更不用说一个商定的术语了。