什么是关系完整性
What is Relational Integrity
在问题, PerformanceDBA中谈到Relational Integrity并指出它不同于Referential Integrity。
我听说过 Referential Integrity，它与 Foreign Keys.
有关
但是 关系完整性 对我来说似乎很奇怪。
本题中Are relational integrity and referential integrity the same thing?, Chris说两者是一回事
数据库领域的术语和定义让我很困惑。
有人可以解释一下关系完整性吗？
关系数据库理论从Edgar F. Codd proposed the Relational Model in his paper in 1970.
建立了几十年
然而，在书籍或网络上，对于范式、完整性等并没有一致的定义。
作为一个学习者，我很困惑。
毫无疑问，他打算将术语 ("relational integrity") 表示为“100% 忠实于 Codd 设计的原始模型”。难得属性。不要去 SQL 系统中寻找它。请记住，这不是一个艺术术语 - 更不用说一个商定的术语了。
混乱
我会按照整体合理的顺序回答您的问题，并缩短篇幅。
The relational database theory has been established for decades since Edgar F. Codd proposed the Relational Model in his paper in 1970. However, there aren't consistent definitions for normal forms, integrity, etc, in books or on the web.
As a learner, I am confused.
The terminologies and definitions in the database world are really confusing me.
我想说，这是数据库行业最大的问题。有两个营地。
科德营地
- 我们坚持 Dr E F Codd 的定义。
- 这些定义不会混淆
- 这些定义完全相互集成
- 无需成为理论家或 "theoretician" 即可理解它们。它们以简单的技术英语编写，并有数学定义支持。
- Codd 编写了第一个关系代数。
换句话说，任何有资格的人都可以理解并使用它们（不需要能够阅读和理解数学定义。）
high-end RDBMS 供应商完全属于这个阵营。几十年来，他们与客户一起领导 SQL 委员会实施 关系模型 和 SQL 的数据子语言（请注意 SQL 不是一种语言，而是一种用于访问数据库的子语言）。
一个结果是，关系模型的自然发展。批评者建议的功能是 "incomplete"，已经 "completed" 并已实施。任何忠实地实施 关系模型 的人都会将其视为自然进展，而不是 "extensions".
所有微小但重要的进步和进步都是由为 high-end 供应商工作的真正的理论家和科学家实现的。 （也就是说，无论是我，还是客户，还是供应商，他们都提出了供应商实施的这种进步，建议 关系模型 是 "incomplete"，或者我们 "completed" 它。我们高兴地接受这不是 "outside" 关系模型 。）
non-SQLs 和 pretend-SQLs 不在该类别中。
"Theoretician"
真正的理论家和科学家的时代早已一去不复返了。我们现在所拥有的是完全孤立于他们声称服务的行业的人；否认其他科学（例如物理定律、逻辑定律和常识）；谁撰写了他们引用的学术论文，从而提升了他们的水平。学术论文和数学证明仅基于这样一个事实，即在这样的否认和孤立中，他们证明了他们打算证明的东西。事实证明在现实世界中是纯粹的垃圾，如果相关科学被否定，它只能是"true"，这与他们无关。
这种对现实的否认是精神分裂症。不幸的是，如今他们在大学级别教授它。
因此，您看到论文排名上升纯粹是因为它们有很多引用（来自精神分裂症患者），而不是基于它是否科学。
对于没有"educated"精神分裂症的人来说，销毁这样的文件很容易。在给你的另一个回答中，我已经给出了证明：
我的Response to Hidders（其中他在 "relational database" 中建议 "problem" 他向 "solve" 提出 "problem" ] 消失 将数据放在关系上下文中的简单操作。
我的 Response to Köhler（他在 "relational database" 中建议 "problem" 他建议 "solve" 创作另一部小说 "normal form"，并且 "problem" 消失 在将数据放入关系上下文的简单操作中。
除了证明 "theoreticians" 发表的论文是建立在稻草人方法上的证据之外，最重要的是他们对 关系一无所知他们声称要写的模型。
这是大规模的欺诈，因为它是在新的 "education" 系统中建立的。
Post-Codd古拉格
这个营地最初由"theoreticians"组成。自 关系模型 发表以来的四十五年里，他们没有产生任何推动或进步它的东西。
现在它由他们所有的追随者和支持者组成。又因为他们出过书，现在被用作大学课程的教科书，它包括所有"professors"教这些垃圾的人，像鹦鹉学舌，没有自己验证理论。
然而，他们产生了一堆碎片，他们声称是 "relational"。他们将 Codd 的定义分解成小块，并孤立地处理每个块，要么攻击 Codd 定义，要么支持他们自己的片段。
例如。 Codd 对 1NF, 2NF, 3NF 有明确的 straight-forward 定义（最后包括功能依赖的定义），任何有能力的人都可以应用它们，这些生物有：
NF 的六个片段（“1NF”、“2NF”、“3NF”、"BCNF"（又名“3.5NF”）、“4NF”、“5NF”）
加在一起，连 Codd 的三个 NF 所涵盖的一小部分都没有涵盖。
这就是为什么我在其他答案中说，如果一个人理解并应用 Codd 的三个 NF，在精神和文字上，它涵盖了上述六个 NF 片段，以及任何 NF 片段尚未写入（由 "theoreticians"）。
DKNF 是最终的 NF，并且显然是 关系模型 的目标（对于任何真正想要理解它的人），但没有定义为这样的。这是自然进程之一（上图），对于忠实的实施者来说是显而易见的。虽然我不会说这很容易，但它是完全可行的：自 2007 年以来我所有的数据库都是 DKNF。
- 但是"theoreticians"定义了DKNF的一小部分，并发表为"DKNF"，他们断然表示这是不可能的。
当然，他们的片段是不完整的，他们永远在他们的定义中找到 "holes"，并且 "filling" 他们。 "holes"没有尽头，"fillers"也没有尽头。 Codd 的定义没有漏洞，不需要填充物。
当然，也没有他们众多碎片的整合。这是 dis-integration.
的定义
他们生产了一些 "relational algebras"（我数不清）来与 Codd 的关系代数竞争。当然，其中 none 甚至更接近，而 Codd 的 是 关系代数。
他们声称 关系模型 在某种程度上是 "incomplete"，并且他们的发明 "complete" 它。他们没有。他们的发明证明他们不理解他们向 "complete" 提出的 关系模型 。这是欺诈的一部分，以提升他们原本令人难以置信的发明。
在做这一切的过程中，他们当然带来了混乱。这是他们的目标，因为他们是 关系模型 的批评者。他们42左右的"relational models"和"relational algebras"只能存在于迷茫状态，从业者和求道者对Relational Model是什么感到困惑。
这个答案很长，只是因为，为了回答你的问题，我必须首先消除混淆，关系模型是什么不是，其次，确认 关系模型 是什么。如果这些生物没有引入所有这些欺诈，这种混乱，如果 关系模型 是清晰的，并且定义没有被破坏，那么问题的答案很简单并且 straight-forward :
- 关系完整性是由关系模型提供的数据完整性形式，pre-relational记录归档系统不提供。
但是对于混淆，这还不够，我必须提供更多的细节和证据来消除混淆。
请注意，他们已经确立了一切都是见仁见智的观念；的争论;这是主观的。当然，真相是objective，不予置评；讨论;或争论。证明很容易：只需阅读 关系模型 并亲自查看是否定义了某些内容，以及该定义是什么。
差异
科德集中营与 "Theoreticians" 古拉格集中营的主要区别在于：
post-Codd 作者不理解关系模型。四十年来，除了他们没有向 关系模型 添加一丁点这一事实之外，他们已经建立了一个私有的 "relational model" （实际上是几个），以及他们的私有定义和私人条款。证据是 four-fold:
首先，他们只了解关系模型的一小部分。他们不知道（例如）关系键；关系完整性。
其次，他们宣传关系模型中明确禁止的各种发明：（例如）代理人；访问路径依赖；循环引用。同样，这只有在他们不了解 关系模型
第三，他们对术语有私有定义，与关系模型中的定义不匹配。仅此一点就可以保证他们与他们声称服务的行业脱节，并且不服务于该行业。此外，他们无法与任何关系模型从业者交谈。
第四，他们在关系模型中有不是的捏造术语（和私人定义） .但是他们欺骗性地宣称这些发明是 "relational model".
总而言之，这意味着他们所实践和宣扬的"relational"或"relational model"，远非Relational，事实上，根据证据，它是Anti-relational.
因为他们不理解关系模型，所以他们理解、传播的是什么？
好吧，根据堆积如山的证据（即他们自己的著作：书籍、教科书、学术论文等），他们只了解和传播我们在 之前拥有的技术关系模型 和 RDBMS 的出现：1970 年前的记录归档系统。
关系数据库（即符合 关系模型).
如果要描述 pre-relational DBMS 和关系型 DBMS 之间的区别，用一句话来说就是 pre-relational 系统相关 records by Record ID，无法控制记录的内容，而Relational system related 行 通过关系键，完全控制（完整性）行内容。
可见差异
上面指出的差异是理论上的，有理论基础的人可以理解（并被"theoreticians"否认）。不过即使是新手也能看出区别，有两点（有很多，我就揭两个很明显的），这里我可以提供具体的证据：
关系模型需要一个主键，然后用作外键来建立关系.批评者将记录 ID 实现为 "primary key"，其中：
在 关系模型 中定义 Key 失败。 （关系模型 Key 的定义是它必须由数据组成。记录 ID， GUID 等是制造出来的，它们不是数据。）
实现访问路径依赖，这在关系模型中被明确禁止。访问路径依赖是 pre-relational 记录归档系统的特征限制。
（这导致必须在两个远端文件之间导航每个文件，而在 关系模型 中，两个远端 table 可以是直接加入了。)
（顺便说一句，这证明记录归档系统实际上需要更多而不是更少的 JOIN，这与神话相反。）
因此，他们将代理项、记录 ID 提升到 "key" 的状态。
但这纯粹是骗局。 Relational世界里没有a"surrogate key"这样的东西，因为这两个词互相矛盾，要么是surrogate(anon-key) x要么是Key(anon-surrogate ).
此外，通过使用术语 "surrogate key"，人们自然会期望至少有一些（如果不是全部的话）Key 的品质，并且代理具有 none钥匙的品质。
也就是"normal"在"theoreticians"的世界里，脱离了Relational世界，因为他们没有Keys，他们有surrogates作为"keys"
他们有他们的发明，以及他们的私人定义，"candidate key"。
这是一项隐藏事实的发明，即它们 不是 使用 关系模型 [=471= 中定义的主键]，这本身就违反了关系模型。
同样，这纯粹是欺诈，因为在关系模型中没有定义这样的东西。所以，不管它是什么，它都在关系模型
这是什么？它是Key的一个片段。单独的代理不能提供行唯一性，这是关系模型所要求的。他们需要行唯一性来在他们的记录归档系统中建立一小部分完整性。
现在，请注意，在这一点上，要完整，因此代理始终是一个附加列，即。附加到数据列。从来都不是either/or命题，因为很多新手（比如Fowler和Ambler，比如那些提出它是"opinion"的人，还没到"consensus"）提出来是.
它是关系键的一个片段，因为 "candidate key" 没有作为记录归档系统中跨文件的键来实现。它仅在定义它的单个文件中实现，因此不使用 Relationally。而在 关系模型 中，这样的键将是主键，并且它将是该 table 的每个子项中的外键，即。它将在 tables.
因此它仍然是关系键的一个片段，仅存在于它所在的文件中。
当然"candidate keys"不行。所以他们想出了另一项发明，让它发挥作用。 "superkey"。它也不起作用，需要大量复制。它不提供关系键的任何特性。它只提供了一个片段，一个步骤，在失败的"candidate key"之上，因此整个事情仍然是失败的。
取函数依赖。由于引入了混乱和破坏，我们不得不称之为完全功能依赖。 Codd 的 3NF 定义也给出了函数依赖的定义。这是通俗易懂的技术英语，易于理解和实施。
最重要的是要理解，因为我们在谈论 关系模型 ，当 Codd 使用术语键时，他的意思是关系键。因此，必须先确定密钥并使其可用，然后才能测试密钥上属性的功能依赖性（这是一个测试），其次。
但是破坏者、颠覆者发明了 3NF 定义的片段。我不会详细介绍（除非被问到），但是，如果你检查它们，你会发现它们有一个目的：将它们的 non-relational "candidate key" 以欺诈方式提升到密钥的状态。
此外，他们对与 Codd 的 3NF 定义相关的片段（大约 7 个）的整套定义非常复杂，普通实施者无法理解，更不用说实施了。
总结。如果有人使用术语 { "candidate key"、"superkey"、"partial/transitive dependence" [而不是完全功能依赖] }，他们明确地表明自己是 (a) 不知道 关系模型，以及 (b) Anti-relarional.
结果
结果，这是 "theoreticians" 的真正成就，95% 的实施者实施了记录归档系统，具有 none 的完整性、权力或关系数据库的速度，但他们 认为 他们的 RFS 是 "relational"。非常遗憾的是，"theoreticians"无法承认并享受他们唯一的成就。
"Theoreticians"
的声明
这是我们必须了解的，以便穿透混乱并识别虚假。如果您了解 "theoreticians" 大量投资于他们的 42 左右 "relational models" 和 "relational algebras"，那么它们与 关系模型 完全不同，你会明白其实他们对关系模型.
一窍不通
但这并不能阻止他们对关系模型、它能做什么、不能做什么等做出声明。因此，不要相信任何宣称他们make，就像一个侏儒在宣布飞机飞行（参考众神一定很疯狂）。
问题
The relational database theory has been established for decades
没错。但仅限于高端行业。像我这样的人。有扎实的理论和科学基础，拒绝 post-Codd 时代的 non-science 的人。大多数人（95%）在 anti-relational 系统中接受教育。
In the question How to Set Up Primary Keys in a Relation, PerformanceDBA talked about Relational Integrity and pointed out that it is different from Referential Integrity.
是的。
Could someone explain the Relational Integrity?
是的。但只有真正的关系实践者才能做到这一点。
请注意，由于关系数据库行业的现状、引入的混乱、正在进行的大规模欺诈，如上所述，破坏者和颠覆者会说，要么没有这样的事情，要么有，但是无法实现，或者说和Referential Integrity一样。
- 这将再次证明两件事：(a) 他们不了解 关系模型 ，以及 (b) 他们是 Anti-relational。
I have heard of Referential Integrity, which is related to Foreign Keys.
But Relational Integrity seems strange to me.
In this question Are relational integrity and referential integrity the same thing?, Chris said the two are the same thing.
不，他们不是。
如上所述，该陈述证明他对关系模型一无所知，并且他是Anti-relational。因此，他无法知道 关系模型 是什么，关系 完整性是什么。他们不知道自己缺少什么，因此无法描述或定义它。
我可以。
让我们从参照完整性开始，以便我们了解 (a) 它是什么，以及 (b) 它与关系完整性有何不同。
我们需要一个像样的例子来使用。请注意，欺诈和小偷使用简单的例子，因为任何事情都可以使用简单、陈腐的例子来证明（或反驳）。深入理解需要完整的示例，这些示例 "complex" 足以证明问题。
让我们用我在comp.databases.theory上给出的"theoreticians"的例子来解决。他们解决不了。我给了指点和提示。他们还是解决不了。
这本身就是 "theoreticians" 无法规范化任何东西的证据。尽管他们有 17 个数学定义，它们的异常、零碎、"normal forms"。
我们真的应该在屋顶上大声疾呼。他们没有资格告诉学员任何事情。
这是一个开发人员的典型实现，他一直在阅读批评者的书籍，并仔细关注他们。通常，他认为这是 "relational"。但它根本不是关系数据库，它是一个记录归档系统，具有关系数据库的 none 完整性、功能或速度。
内容大家应该都比较熟悉，所以就不赘述了。请注意，前三个级别有 ISO 和 ANSI/FIPS 标准代码，例如。 ISO-3166-1、3166-2 和 FIPS。
Typical Record Filing System Implementation declared as "relational"
- 开发人员了解了行唯一性，并实施了备用键来提供这一点。这些比通常实施的更先进，但是嘿，我不是在尝试一个稻草人的论点，这些是任何人想出的最好的 "candidate keys"。例如。在状态文件中，他正确地断言 Name 和 StateCode 在一个国家/地区内必须是唯一的。
但是他的"primary keys"不是Primary Keys，而是Record ID。
开发者已将这组文件声明为"satisfies 5NF"。 "theoreticians" 已经这样通过了。
就 Codd 和我而言，(a) 它没有通过 3NF 和 (b) 它没有通过关系。但我们不会在这里处理它，我们只需要一个很好的例子来实现我们的目的，关系完整性。
让我们看看国家文件的 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" 的县，但在纽约没有，而加拿大有一个名为 none 的县。
糟糕，我们刚刚将李县插入了纽约州。这暴露了两个重要问题：
无论是从用户的角度，还是从用户用来维护归档系统中数据的应用程序来看，数据完整性都非常差，因为数据非常少鉴定。 （记录 ID 不是数据，用户甚至不应该看到它们。）
因此，即使该应用程序为州提供了记录 ID，在确定之前，它也必须询问用户 "which State" 县被插入，并提供 drop-dow，这（希望）包含按字母顺序排列的 StateCodes（最低）或 State Names（更好）。
然后提取所选州的记录 ID，放弃州代码。
单纯从数据上看，完全可以识别一个县，并且唯一识别（CountryCode-or-Name，StateCode-or-Name，CountyCode-or-Name）。
但是在"theoreticians"文件系统中，我们被阻止了。
那么问题是什么？
问题是，"theoreticians" 不理解关系键或标识符（IDEF1X 术语）。因为不懂，所以不知道自己少了什么。
解决方案是，使用关系键的关系模型。
参照完整性
首先需要了解一些事情。什么是主键？在 SQL 上下文中，即。在一个实现中，关键字 PRIMARY KEY 的使用不会神奇地将这样命名的列转换为主键（根据 关系模型 ）。它只是强制指定列的唯一性。
什么是参照完整性？
只是在SQL中使用了FOREIGN KEY ... REFERENCES关键字。它不会神奇地提供关系完整性。它仅在服务器（或 non-server，对于 NON-sqls）中强制执行，即引用文件中标识的 FK 是引用文件中的 PK。
让我们在这里停下来评估一下。 "theoreticians"和post-Codd的作者只知道RFS，很少SQL。他们只知道参照完整性（大多数情况下，他们甚至没有实现，但我们不要分心）。因此，他们无法就他们不知道的事情以一种或另一种方式发表声明。
关系完整性远不止参照完整性。
关系集
EF Codd 博士要求我们根据集合来考虑数据。 "theoreticians" 不明白这一点。他们只知道两个集合：包含整个文件的集合；和空集。
在关系世界中，集合远不止于此。
第一层，国家，当然，只有一套，国家。
第二层State，简单集合就是all States of all Countries。但是我们可以使用更多的关系集：
- 属于一个国家的每组国家，Country-States.
第三层County，简单集合是所有Countries的所有Counties。但是我们可以使用更多的关系集：
属于一个州的每组县，在一个国家，Country-State-Counties .
当然，每组属于国家的县，Country-Counties。
因此，虽然 关系模型 提供了 RFS 中未实现的内容，但在此类 RFS 中可能实现的完整性仅限于在同一时间引用一个文件时间，而不是引用数据集。
关系完整性
现在让我们看看关系模型提供的完整性。
为了进行比较，我们需要将该示例转换为关系数据库。只看第 2 页的前三个 table。
让我们看看相同的插页：
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')
这里我们说的是，State 的标识符或关系键是 (CountryCode, StateCode)。没有警报响起 "NT" 的 StateCode，因为 CountryCode 使其独一无二。
INSERT County VALUES
( 'US', 'AL', 'LE', 'Lee' ),
( 'US', 'GA', 'LE', 'Lee' )
我们在这里说，县的标识符或关系键是 (CountryCode, StateCode, CountyCode)。我们不太可能犯错把一个李县放在纽约州，因为当我们输入它的时候，我们知道它是错误的，我们必须主动输入错误的东西"NY"。而当它是一个数字，一个 ID 字段时，我们没有任何线索：
INSERT County VALUES
( 'US', 'NY', 'LE', 'Lee' )
用关系术语来总结：
在 post-Codd 作者和 "theoreticians" 营销和传播的记录归档系统中，没有关系键；没有集合，它们只有 SQL 提供的引用完整性。
- 县限于州文件中存在的任何记录。
在具有关系键和集合的关系数据库中，除了 SQL 提供的参照完整性之外，我们还有关系完整性。
- 县被限制为州 table 中存在的 Country-State 的每个特定组合。
答案超出 SO 限制
我有第二个例子和进一步的解释来完成这个。但是答案太长了。我必须把它转换成一个WP文件，把它放在link，等明天。
一个数据库状态代表了一些世界情况。由于我们应该将关于世界的特定数据库的基表放入，并且因为只有一些世界情况会出现，所以只有一些数据库状态会出现。如果数据库曾经保持过另一个状态，那将是一个错误。
数据库完整性是关于确保数据库永远不会包含无效状态。 （例如，您会看到标题为 "Integrity" 或 "Database Integrity" 的教科书章节讨论了该主题。）
"Relational integrity" 不是常用术语。我希望它指的是关系数据库的数据库完整性。约束共同描述了有效的关系数据库状态。关系 DBMS 启用它们的声明并强制执行它们。
也可以合理地用它来表示遵守关系模型的原则。
引用完整性是关系数据库完整性的一个子主题，它是关于确保数据库永远不会包含由（取决于上下文）外键约束或 SQL FOREIGN 描述的那种无效状态KEY 约束，我们可以称之为外部超级键约束。 （SQL 的 FOREIGN KEY 定义可以涉及对超键的引用，而不仅仅是外键约束中的候选键。）
真正重要的是关系模型的基本概念。常用和 ad-hoc 个术语只是让我们参考它们。
在问题
我听说过 Referential Integrity，它与 Foreign Keys.
有关
但是 关系完整性 对我来说似乎很奇怪。
本题中Are relational integrity and referential integrity the same thing?, Chris说两者是一回事
数据库领域的术语和定义让我很困惑。
有人可以解释一下关系完整性吗？
关系数据库理论从Edgar F. Codd proposed the Relational Model in his paper in 1970.
建立了几十年
然而，在书籍或网络上，对于范式、完整性等并没有一致的定义。
作为一个学习者，我很困惑。
毫无疑问，他打算将术语 ("relational integrity") 表示为“100% 忠实于 Codd 设计的原始模型”。难得属性。不要去 SQL 系统中寻找它。请记住，这不是一个艺术术语 - 更不用说一个商定的术语了。
混乱
我会按照整体合理的顺序回答您的问题，并缩短篇幅。
The relational database theory has been established for decades since Edgar F. Codd proposed the Relational Model in his paper in 1970. However, there aren't consistent definitions for normal forms, integrity, etc, in books or on the web.
As a learner, I am confused.
The terminologies and definitions in the database world are really confusing me.
我想说，这是数据库行业最大的问题。有两个营地。
科德营地
- 我们坚持 Dr E F Codd 的定义。
- 这些定义不会混淆
- 这些定义完全相互集成
- 无需成为理论家或 "theoretician" 即可理解它们。它们以简单的技术英语编写，并有数学定义支持。
- Codd 编写了第一个关系代数。
换句话说，任何有资格的人都可以理解并使用它们（不需要能够阅读和理解数学定义。）
high-end RDBMS 供应商完全属于这个阵营。几十年来，他们与客户一起领导 SQL 委员会实施 关系模型 和 SQL 的数据子语言（请注意 SQL 不是一种语言，而是一种用于访问数据库的子语言）。
一个结果是，关系模型的自然发展。批评者建议的功能是 "incomplete"，已经 "completed" 并已实施。任何忠实地实施 关系模型 的人都会将其视为自然进展，而不是 "extensions".
所有微小但重要的进步和进步都是由为 high-end 供应商工作的真正的理论家和科学家实现的。 （也就是说，无论是我，还是客户，还是供应商，他们都提出了供应商实施的这种进步，建议 关系模型 是 "incomplete"，或者我们 "completed" 它。我们高兴地接受这不是 "outside" 关系模型 。）
non-SQLs 和 pretend-SQLs 不在该类别中。
"Theoretician"
真正的理论家和科学家的时代早已一去不复返了。我们现在所拥有的是完全孤立于他们声称服务的行业的人；否认其他科学（例如物理定律、逻辑定律和常识）；谁撰写了他们引用的学术论文，从而提升了他们的水平。学术论文和数学证明仅基于这样一个事实，即在这样的否认和孤立中，他们证明了他们打算证明的东西。事实证明在现实世界中是纯粹的垃圾，如果相关科学被否定，它只能是"true"，这与他们无关。
这种对现实的否认是精神分裂症。不幸的是，如今他们在大学级别教授它。
因此，您看到论文排名上升纯粹是因为它们有很多引用（来自精神分裂症患者），而不是基于它是否科学。
对于没有"educated"精神分裂症的人来说，销毁这样的文件很容易。在给你的另一个回答中，我已经给出了证明：
我的Response to Hidders（其中他在 "relational database" 中建议 "problem" 他向 "solve" 提出 "problem" ] 消失 将数据放在关系上下文中的简单操作。
我的 Response to Köhler（他在 "relational database" 中建议 "problem" 他建议 "solve" 创作另一部小说 "normal form"，并且 "problem" 消失 在将数据放入关系上下文的简单操作中。
除了证明 "theoreticians" 发表的论文是建立在稻草人方法上的证据之外，最重要的是他们对 关系一无所知他们声称要写的模型。
这是大规模的欺诈，因为它是在新的 "education" 系统中建立的。
Post-Codd古拉格
这个营地最初由"theoreticians"组成。自 关系模型 发表以来的四十五年里，他们没有产生任何推动或进步它的东西。
现在它由他们所有的追随者和支持者组成。又因为他们出过书，现在被用作大学课程的教科书，它包括所有"professors"教这些垃圾的人，像鹦鹉学舌，没有自己验证理论。
然而，他们产生了一堆碎片，他们声称是 "relational"。他们将 Codd 的定义分解成小块，并孤立地处理每个块，要么攻击 Codd 定义，要么支持他们自己的片段。
例如。 Codd 对 1NF, 2NF, 3NF 有明确的 straight-forward 定义（最后包括功能依赖的定义），任何有能力的人都可以应用它们，这些生物有：
NF 的六个片段（“1NF”、“2NF”、“3NF”、"BCNF"（又名“3.5NF”）、“4NF”、“5NF”）
加在一起，连 Codd 的三个 NF 所涵盖的一小部分都没有涵盖。
这就是为什么我在其他答案中说，如果一个人理解并应用 Codd 的三个 NF，在精神和文字上，它涵盖了上述六个 NF 片段，以及任何 NF 片段尚未写入（由 "theoreticians"）。
DKNF 是最终的 NF，并且显然是 关系模型 的目标（对于任何真正想要理解它的人），但没有定义为这样的。这是自然进程之一（上图），对于忠实的实施者来说是显而易见的。虽然我不会说这很容易，但它是完全可行的：自 2007 年以来我所有的数据库都是 DKNF。
- 但是"theoreticians"定义了DKNF的一小部分，并发表为"DKNF"，他们断然表示这是不可能的。
当然，他们的片段是不完整的，他们永远在他们的定义中找到 "holes"，并且 "filling" 他们。 "holes"没有尽头，"fillers"也没有尽头。 Codd 的定义没有漏洞，不需要填充物。
当然，也没有他们众多碎片的整合。这是 dis-integration.
的定义他们生产了一些 "relational algebras"（我数不清）来与 Codd 的关系代数竞争。当然，其中 none 甚至更接近，而 Codd 的 是 关系代数。
他们声称 关系模型 在某种程度上是 "incomplete"，并且他们的发明 "complete" 它。他们没有。他们的发明证明他们不理解他们向 "complete" 提出的 关系模型 。这是欺诈的一部分，以提升他们原本令人难以置信的发明。
在做这一切的过程中，他们当然带来了混乱。这是他们的目标，因为他们是 关系模型 的批评者。他们42左右的"relational models"和"relational algebras"只能存在于迷茫状态，从业者和求道者对Relational Model是什么感到困惑。
这个答案很长，只是因为，为了回答你的问题，我必须首先消除混淆，关系模型是什么不是，其次，确认 关系模型 是什么。如果这些生物没有引入所有这些欺诈，这种混乱，如果 关系模型 是清晰的，并且定义没有被破坏，那么问题的答案很简单并且 straight-forward :
- 关系完整性是由关系模型提供的数据完整性形式，pre-relational记录归档系统不提供。
但是对于混淆，这还不够，我必须提供更多的细节和证据来消除混淆。
请注意，他们已经确立了一切都是见仁见智的观念；的争论;这是主观的。当然，真相是objective，不予置评；讨论;或争论。证明很容易：只需阅读 关系模型 并亲自查看是否定义了某些内容，以及该定义是什么。
差异
科德集中营与 "Theoreticians" 古拉格集中营的主要区别在于：
post-Codd 作者不理解关系模型。四十年来，除了他们没有向 关系模型 添加一丁点这一事实之外，他们已经建立了一个私有的 "relational model" （实际上是几个），以及他们的私有定义和私人条款。证据是 four-fold:
首先，他们只了解关系模型的一小部分。他们不知道（例如）关系键；关系完整性。
其次，他们宣传关系模型中明确禁止的各种发明：（例如）代理人；访问路径依赖；循环引用。同样，这只有在他们不了解 关系模型
时才有可能
第三，他们对术语有私有定义，与关系模型中的定义不匹配。仅此一点就可以保证他们与他们声称服务的行业脱节，并且不服务于该行业。此外，他们无法与任何关系模型从业者交谈。
第四，他们在关系模型中有不是的捏造术语（和私人定义） .但是他们欺骗性地宣称这些发明是 "relational model".
的一部分
总而言之，这意味着他们所实践和宣扬的"relational"或"relational model"，远非Relational，事实上，根据证据，它是Anti-relational.
因为他们不理解关系模型，所以他们理解、传播的是什么？
好吧，根据堆积如山的证据（即他们自己的著作：书籍、教科书、学术论文等），他们只了解和传播我们在 之前拥有的技术关系模型 和 RDBMS 的出现：1970 年前的记录归档系统。
关系数据库（即符合 关系模型).
如果要描述 pre-relational DBMS 和关系型 DBMS 之间的区别，用一句话来说就是 pre-relational 系统相关 records by Record ID，无法控制记录的内容，而Relational system related 行 通过关系键，完全控制（完整性）行内容。
可见差异
上面指出的差异是理论上的，有理论基础的人可以理解（并被"theoreticians"否认）。不过即使是新手也能看出区别，有两点（有很多，我就揭两个很明显的），这里我可以提供具体的证据：
关系模型需要一个主键，然后用作外键来建立关系.批评者将记录 ID 实现为 "primary key"，其中：
在 关系模型 中定义 Key 失败。 （关系模型 Key 的定义是它必须由数据组成。记录 ID， GUID 等是制造出来的，它们不是数据。）
实现访问路径依赖，这在关系模型中被明确禁止。访问路径依赖是 pre-relational 记录归档系统的特征限制。
（这导致必须在两个远端文件之间导航每个文件，而在 关系模型 中，两个远端 table 可以是直接加入了。)
（顺便说一句，这证明记录归档系统实际上需要更多而不是更少的 JOIN，这与神话相反。）
因此，他们将代理项、记录 ID 提升到 "key" 的状态。
但这纯粹是骗局。 Relational世界里没有a"surrogate key"这样的东西，因为这两个词互相矛盾，要么是surrogate(anon-key) x要么是Key(anon-surrogate ).
此外，通过使用术语 "surrogate key"，人们自然会期望至少有一些（如果不是全部的话）Key 的品质，并且代理具有 none钥匙的品质。
也就是"normal"在"theoreticians"的世界里，脱离了Relational世界，因为他们没有Keys，他们有surrogates作为"keys"
他们有他们的发明，以及他们的私人定义，"candidate key"。
这是一项隐藏事实的发明，即它们 不是 使用 关系模型 [=471= 中定义的主键]，这本身就违反了关系模型。
同样，这纯粹是欺诈，因为在关系模型中没有定义这样的东西。所以，不管它是什么，它都在关系模型
之外
这是什么？它是Key的一个片段。单独的代理不能提供行唯一性，这是关系模型所要求的。他们需要行唯一性来在他们的记录归档系统中建立一小部分完整性。
现在，请注意，在这一点上，要完整，因此代理始终是一个附加列，即。附加到数据列。从来都不是either/or命题，因为很多新手（比如Fowler和Ambler，比如那些提出它是"opinion"的人，还没到"consensus"）提出来是.
它是关系键的一个片段，因为 "candidate key" 没有作为记录归档系统中跨文件的键来实现。它仅在定义它的单个文件中实现，因此不使用 Relationally。而在 关系模型 中，这样的键将是主键，并且它将是该 table 的每个子项中的外键，即。它将在 tables.
中按关系使用
因此它仍然是关系键的一个片段，仅存在于它所在的文件中。
当然"candidate keys"不行。所以他们想出了另一项发明，让它发挥作用。 "superkey"。它也不起作用，需要大量复制。它不提供关系键的任何特性。它只提供了一个片段，一个步骤，在失败的"candidate key"之上，因此整个事情仍然是失败的。
取函数依赖。由于引入了混乱和破坏，我们不得不称之为完全功能依赖。 Codd 的 3NF 定义也给出了函数依赖的定义。这是通俗易懂的技术英语，易于理解和实施。
最重要的是要理解，因为我们在谈论 关系模型 ，当 Codd 使用术语键时，他的意思是关系键。因此，必须先确定密钥并使其可用，然后才能测试密钥上属性的功能依赖性（这是一个测试），其次。
但是破坏者、颠覆者发明了 3NF 定义的片段。我不会详细介绍（除非被问到），但是，如果你检查它们，你会发现它们有一个目的：将它们的 non-relational "candidate key" 以欺诈方式提升到密钥的状态。
此外，他们对与 Codd 的 3NF 定义相关的片段（大约 7 个）的整套定义非常复杂，普通实施者无法理解，更不用说实施了。
总结。如果有人使用术语 { "candidate key"、"superkey"、"partial/transitive dependence" [而不是完全功能依赖] }，他们明确地表明自己是 (a) 不知道 关系模型，以及 (b) Anti-relarional.
结果
结果，这是 "theoreticians" 的真正成就，95% 的实施者实施了记录归档系统，具有 none 的完整性、权力或关系数据库的速度，但他们 认为 他们的 RFS 是 "relational"。非常遗憾的是，"theoreticians"无法承认并享受他们唯一的成就。
"Theoreticians"
的声明这是我们必须了解的，以便穿透混乱并识别虚假。如果您了解 "theoreticians" 大量投资于他们的 42 左右 "relational models" 和 "relational algebras"，那么它们与 关系模型 完全不同，你会明白其实他们对关系模型.
一窍不通但这并不能阻止他们对关系模型、它能做什么、不能做什么等做出声明。因此，不要相信任何宣称他们make，就像一个侏儒在宣布飞机飞行（参考众神一定很疯狂）。
问题
The relational database theory has been established for decades
没错。但仅限于高端行业。像我这样的人。有扎实的理论和科学基础，拒绝 post-Codd 时代的 non-science 的人。大多数人（95%）在 anti-relational 系统中接受教育。
In the question How to Set Up Primary Keys in a Relation, PerformanceDBA talked about Relational Integrity and pointed out that it is different from Referential Integrity.
是的。
Could someone explain the Relational Integrity?
是的。但只有真正的关系实践者才能做到这一点。
请注意，由于关系数据库行业的现状、引入的混乱、正在进行的大规模欺诈，如上所述，破坏者和颠覆者会说，要么没有这样的事情，要么有，但是无法实现，或者说和Referential Integrity一样。
- 这将再次证明两件事：(a) 他们不了解 关系模型 ，以及 (b) 他们是 Anti-relational。
I have heard of Referential Integrity, which is related to Foreign Keys. But Relational Integrity seems strange to me.
In this question Are relational integrity and referential integrity the same thing?, Chris said the two are the same thing.
不，他们不是。
如上所述，该陈述证明他对关系模型一无所知，并且他是Anti-relational。因此，他无法知道 关系模型 是什么，关系 完整性是什么。他们不知道自己缺少什么，因此无法描述或定义它。
我可以。
让我们从参照完整性开始，以便我们了解 (a) 它是什么，以及 (b) 它与关系完整性有何不同。
我们需要一个像样的例子来使用。请注意，欺诈和小偷使用简单的例子，因为任何事情都可以使用简单、陈腐的例子来证明（或反驳）。深入理解需要完整的示例，这些示例 "complex" 足以证明问题。
让我们用我在comp.databases.theory上给出的"theoreticians"的例子来解决。他们解决不了。我给了指点和提示。他们还是解决不了。
这本身就是 "theoreticians" 无法规范化任何东西的证据。尽管他们有 17 个数学定义，它们的异常、零碎、"normal forms"。
我们真的应该在屋顶上大声疾呼。他们没有资格告诉学员任何事情。
这是一个开发人员的典型实现，他一直在阅读批评者的书籍，并仔细关注他们。通常，他认为这是 "relational"。但它根本不是关系数据库，它是一个记录归档系统，具有关系数据库的 none 完整性、功能或速度。
内容大家应该都比较熟悉，所以就不赘述了。请注意，前三个级别有 ISO 和 ANSI/FIPS 标准代码，例如。 ISO-3166-1、3166-2 和 FIPS。
Typical Record Filing System Implementation declared as "relational"
- 开发人员了解了行唯一性，并实施了备用键来提供这一点。这些比通常实施的更先进，但是嘿，我不是在尝试一个稻草人的论点，这些是任何人想出的最好的 "candidate keys"。例如。在状态文件中，他正确地断言 Name 和 StateCode 在一个国家/地区内必须是唯一的。
但是他的"primary keys"不是Primary Keys，而是Record ID。
开发者已将这组文件声明为"satisfies 5NF"。 "theoreticians" 已经这样通过了。
就 Codd 和我而言，(a) 它没有通过 3NF 和 (b) 它没有通过关系。但我们不会在这里处理它，我们只需要一个很好的例子来实现我们的目的，关系完整性。
让我们看看国家文件的 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" 的县，但在纽约没有，而加拿大有一个名为 none 的县。
糟糕，我们刚刚将李县插入了纽约州。这暴露了两个重要问题：
无论是从用户的角度，还是从用户用来维护归档系统中数据的应用程序来看，数据完整性都非常差，因为数据非常少鉴定。 （记录 ID 不是数据，用户甚至不应该看到它们。）
因此，即使该应用程序为州提供了记录 ID，在确定之前，它也必须询问用户 "which State" 县被插入，并提供 drop-dow，这（希望）包含按字母顺序排列的 StateCodes（最低）或 State Names（更好）。
然后提取所选州的记录 ID，放弃州代码。
单纯从数据上看，完全可以识别一个县，并且唯一识别（CountryCode-or-Name，StateCode-or-Name，CountyCode-or-Name）。
但是在"theoreticians"文件系统中，我们被阻止了。
那么问题是什么？
问题是，"theoreticians" 不理解关系键或标识符（IDEF1X 术语）。因为不懂，所以不知道自己少了什么。
解决方案是，使用关系键的关系模型。
参照完整性
首先需要了解一些事情。什么是主键？在 SQL 上下文中，即。在一个实现中，关键字 PRIMARY KEY 的使用不会神奇地将这样命名的列转换为主键（根据 关系模型 ）。它只是强制指定列的唯一性。
什么是参照完整性？
只是在SQL中使用了FOREIGN KEY ... REFERENCES关键字。它不会神奇地提供关系完整性。它仅在服务器（或 non-server，对于 NON-sqls）中强制执行，即引用文件中标识的 FK 是引用文件中的 PK。
让我们在这里停下来评估一下。 "theoreticians"和post-Codd的作者只知道RFS，很少SQL。他们只知道参照完整性（大多数情况下，他们甚至没有实现，但我们不要分心）。因此，他们无法就他们不知道的事情以一种或另一种方式发表声明。
关系完整性远不止参照完整性。
关系集
EF Codd 博士要求我们根据集合来考虑数据。 "theoreticians" 不明白这一点。他们只知道两个集合：包含整个文件的集合；和空集。
在关系世界中，集合远不止于此。
第一层，国家，当然，只有一套，国家。
第二层State，简单集合就是all States of all Countries。但是我们可以使用更多的关系集：
- 属于一个国家的每组国家，Country-States.
第三层County，简单集合是所有Countries的所有Counties。但是我们可以使用更多的关系集：
属于一个州的每组县，在一个国家，Country-State-Counties .
当然，每组属于国家的县，Country-Counties。
因此，虽然 关系模型 提供了 RFS 中未实现的内容，但在此类 RFS 中可能实现的完整性仅限于在同一时间引用一个文件时间，而不是引用数据集。
关系完整性
现在让我们看看关系模型提供的完整性。
为了进行比较，我们需要将该示例转换为关系数据库。只看第 2 页的前三个 table。
让我们看看相同的插页：
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')
这里我们说的是，State 的标识符或关系键是 (CountryCode, StateCode)。没有警报响起 "NT" 的 StateCode，因为 CountryCode 使其独一无二。
INSERT County VALUES
( 'US', 'AL', 'LE', 'Lee' ),
( 'US', 'GA', 'LE', 'Lee' )
我们在这里说，县的标识符或关系键是 (CountryCode, StateCode, CountyCode)。我们不太可能犯错把一个李县放在纽约州，因为当我们输入它的时候，我们知道它是错误的，我们必须主动输入错误的东西"NY"。而当它是一个数字，一个 ID 字段时，我们没有任何线索：
INSERT County VALUES
( 'US', 'NY', 'LE', 'Lee' )
用关系术语来总结：
在 post-Codd 作者和 "theoreticians" 营销和传播的记录归档系统中，没有关系键；没有集合，它们只有 SQL 提供的引用完整性。
- 县限于州文件中存在的任何记录。
在具有关系键和集合的关系数据库中，除了 SQL 提供的参照完整性之外，我们还有关系完整性。
- 县被限制为州 table 中存在的 Country-State 的每个特定组合。
答案超出 SO 限制
我有第二个例子和进一步的解释来完成这个。但是答案太长了。我必须把它转换成一个WP文件，把它放在link，等明天。
一个数据库状态代表了一些世界情况。由于我们应该将关于世界的特定数据库的基表放入，并且因为只有一些世界情况会出现，所以只有一些数据库状态会出现。如果数据库曾经保持过另一个状态，那将是一个错误。
数据库完整性是关于确保数据库永远不会包含无效状态。 （例如，您会看到标题为 "Integrity" 或 "Database Integrity" 的教科书章节讨论了该主题。）
"Relational integrity" 不是常用术语。我希望它指的是关系数据库的数据库完整性。约束共同描述了有效的关系数据库状态。关系 DBMS 启用它们的声明并强制执行它们。
也可以合理地用它来表示遵守关系模型的原则。
引用完整性是关系数据库完整性的一个子主题，它是关于确保数据库永远不会包含由（取决于上下文）外键约束或 SQL FOREIGN 描述的那种无效状态KEY 约束，我们可以称之为外部超级键约束。 （SQL 的 FOREIGN KEY 定义可以涉及对超键的引用，而不仅仅是外键约束中的候选键。）
真正重要的是关系模型的基本概念。常用和 ad-hoc 个术语只是让我们参考它们。