具有唯一值的第三范式

Posted 2023-03-24

【中文标题】具有唯一值的第三范式

【英文标题】：3rd normal form with unique values

【发布时间】：2019-11-29 01:44:01

【问题描述】：

我有表 USER 和架构 USER(user_id, email, first_name, last_name, ...)。 电子邮件是我数据库中的唯一值，user_id 是主键。因此，user_id 和 email 是候选键。 这是否意味着我在这里有传递依赖（user_id -> email -> (first_name, last_name, ...)），因此数据库不在 NF3 中？

【问题讨论】：

您的第一个明确问题是什么？如果是某个 FD 是否具有传递性，那么您的意思是什么 FD？您在哪里将定义应用于它？ PS您的多个不清楚的问题涉及结论是否正确，但您只给出了模糊的定义和推理片段。您只是要求我们用定制的教程重写您的教科书并完成您的（家庭）作业。引用和使用定义，显示推理的所有步骤并在您遇到困难时提出 1 个具体问题。请参阅How to Ask，点击谷歌搜索“stackexchange 作业”和投票箭头鼠标悬停文本。

你的意思可能是表不在3NF中，不是数据库，email是表中的唯一列 i>，而不是 我的数据库中的唯一值。因为数据库不仅仅是一个表。

【参考方案1】：

注意Relational Database 标签。

主要的问题，混淆了一切，是有一个关系模型，然后是各种被别人宣传为“关系”的废话。

E F Codd 博士的唯一原创关系模型。

这是一个坚如磐石的定义，自 1970 年 6 月以来一直没有改变，也不需要改变。真理是永恒的，它不会改变。它是商业平台提供商可以构建平台的基础，并且在 1980 年代就已经这样做了。

Date & Darwen & Fagin 版本，即 1960 年代的 Record Filing Systems，前数据库和前关系：正是 RM 替换。加上来自关系模型的几个片段（不是整个概念）。大量宣传和营销为“关系型”，这是不正确的。

这是一个片段的集合，永远在变化。它们现在多达几个“关系代数”； 17个不正常的“范式”（他们已经改变了原来的范式以适应自己的目的）；等等

关系模型中不存在以下术语，它们是用于提升 RFS 中的片段以获得一点关系外观的术语。

“传递依赖” “候选键”

1960 年的 RFS 的特征是 Record ID（您的是 user_id），它是一个物理（非逻辑）指针。这在 RM 中是明确禁止的，这是合乎逻辑的，并且脱离了之前的基于指针的系统。

1960 年代的 RFS 和 RM 之间的主要区别（不是唯一区别）是，而 RFS 使用物理指针（例如 Record ID）关联物理记录，RM 使用数据中出现的自然键关联数据的逻辑行（不是记录）。

在 1990 年代出现的非商业平台提供商通常会参考这些附加内容，或在RM 中禁止的供应条款，有时会提供一些功能来缓解由此带来的痛苦。

Relational Model 是免费的（在那个时候，只有合格的人才尝试数据库设计）。但是，这些术语已过时，因此今天无法理解。它是开创性的，密集的。支持者以此为基础，将他们的方法推广为“关系型”。

---

关系模型

我会回答关系模型。为了避免多次重复同一项目，我将按逻辑顺序处理问题。

RM 要求每一行（不是记录，因为它超出记录）都是唯一的。

在RM中，为每个表选择一个或多个唯一键。每个密钥必须“由数据组成”。此外，每个 Key 必须是非冗余的，即最小的 Key。如果有多个 Key，则选择一个作为 Primary Key，作为 Foreign Key 迁移到下级行。选择主键后，剩下的所有键都是备用键。

虽然 Keys 在选举前可能被粗略地称为“候选人”，但在选举后他们不再是“候选人”，而是失败者。

使用“候选者”一词仅用于 (a) 保持不从“候选者”之一中选择主键的紧张状态（根据 RM 的要求），以及（ b) 从而允许一个非密钥（例如伪造的Record ID 或user_id 作为PRIMARY KEY。

数据中不存在Record ID 字段，它是由系统制造的（GUID; AUTO INCREMENT；等）。这样的字段非常适合以物理术语 (RFS) 感知数据，就好像它是一个令人震惊的网格，因此抑制了将数据感知为相关的逻辑组件 (RM)。

真正的钥匙有许多重要的属性。将非键声明为PRIMARY KEY（这在 SQL 中是可能的）不会神奇地赋予非键任何这些属性。

因此架构是USER(user_id, email, first_name, last_name, ...)

您已经认识到email 是一个唯一标识符。伟大的。事实上，对于该架构，它是唯一的 Key，因此您不必担心从众多可能中选择一个。

这是一个比较。

我所有的数据模型都在 IDEF1X 中呈现，这是自 1993 年以来为关系数据库建模的标准。

我的IDEF1X Introduction是初学者的必备读物。

---

现在您要检查表是否满足 3NF。德米特里的意图是正确的，尽管他的定义可能不正确。 E F Codd 博士的 3NF，而不是伪装者：

一行是第三范式，当且仅当每个非素数属性在功能上依赖于键、整个键，且仅依赖于键。

RM只有“完整”的功能依赖，它不帮助那些将Key碎片化的人来处理他们的碎片。

传递性是一个逻辑和数学术语，它没有在 RM 中减去，相反，它根本不适用，不是必需的，因为它处理整个 Key，而 RFS 处理带有钥匙的碎片。

first_name, last_name, ... 每个功能都依赖于email，除了email。

因此它满足 3NF。

---

1960 年代档案系统

对不起，我帮不了你，因为它是一个不断变化且不可靠的混乱，它处理的是数据片段而不是识别原子，他们会无休止地争论，什么也解决不了。他们研究不在 RM 中的概念，因此被欺骗性地称为“关系”，同时保留了 1960 年面向记录的范式的基本部分：物理 @987654344 的附加字段和附加索引@;以及物理Record ID的引用。 RM 禁止这两者。

---

评论

_{本部分是根据 SO 指南呈现的，特别是：随时纠正错误信息。我确实回应了 cmets，但他们一直在消失。所以我把它放在这里了。}

philipxy: Codd 1971 年的【论文】“Further normalization of the database relational model”介绍了分解为更高 NF 的意义上的“规范化”，包括“FD”、“CK”、“其中一个 CK 被任意指定为 PK”、“ 2NF”表示“部分/全部 FD”，“3NF”表示“传递/非传递 FD”。

引用来自 1971 年的论文，而不是 1970 年 6 月的论文 The Relational Model。它们是两种不同的论文。因此确认：

该内容在 1971 年的论文中

1970 年 6 月的关系模型论文没有该内容。

因此，1971 年的论文可以被驳回。

事实证明，Codd 在这十年（1970 年至 1980 年）期间写了大约 12 篇额外的论文，他试图让 RM 被接受。除了历史目的之外，它们没有任何价值，可以考察他对由 RM 引起的 DBMS 平台供应商剧变的反应方式：这是一种范式转变。

1971 年的论文以及“RM/Tasmania”文章和演示文稿的明确目的是帮助当时根深蒂固的 DBMS 平台用户在不改变平台的情况下在他们的系统中实现一些关系功能，参考文献-物理指针范式（思维模式和实现）。

在关系模型被接受之后，大约在 1985 年，当所有 DBMS 平台供应商开始转向提供 RDBMS 平台时，即。物理指针参考平台已经绝迹，1971 年的论文，以前对他们来说很近而且很珍贵，现在已经过时了。

因此，1971 年的论文可以再次被驳回。

与RM 相关的唯一一篇文章（不是正式论文，但被广泛接受）是 1985 年 ComputerWorld 文章，通常称为 Codd 的十二条规则，它给出了 (a) DBMS 平台和 (b) 数据库的规则，被接受为真正的关系。那是为了克服 DBMS 平台供应商添加关系的点点滴滴，然后将他们的产品标记为“关系”的问题。

还在困惑吗？科学人士会：

认识到RM与1971年的论文相矛盾，1971年的论文与RM相矛盾，

认识到它们不可能同时为真，

应用非矛盾法，

并取消 1971 年的论文。

The Date、Darwen、Fagin 等人以及他们的所有追随者（作者、教授、讲师等）并不愚蠢。因此，以下证据起作用：

所谓的问题 [4] 没有得到解决，

RM 的抑制（原子性；Codd 的三个 NF 不变；关系键；对关系键的“完全”功能依赖），

1971 年过时论文的高度（碎片化；17 个 NF 不断变化的重新定义；物理 RecordID 作为“关键”；部分 FD 处理碎片等），

声明 1971 年的论文在 1985 年就已经过时，与 关系模型 相矛盾，是“关系模型”。 philipxy 等人证明了这一点。

不正确，与原始关系模型不一致。

关系模型的制度化抑制

它通过额外的行为得到加强：

歪曲 Codd 的规则 1（事后从数据库中查看数据）作为确定的、事前对数据的感知，这就是“表”：

欧文·斯努特： 归根结底，数据的关系模型只有一个“规则”：数据库中的所有信息都必须表示为关系元组中的属性值。

关系模型和十二条规则中有超过 40 条规则。将它们简化为一个简洁的规则与 RM 不兼容。

这消除了真正的数据建模的可能性

继续使用完全过时的ERD进行数据分析和建模，它不支持关系模型的核心文章，即复合关系键，因此保持对碎片的感知

禁止使用 IDEF1X，它是为 关系模型 设计的，自 1985 年以来可用，自 1993 年以来用于建模关系数据的 NIST 标准。它将概念形式化RM。

【讨论】：

@BakhanovA。 This Q & A 你可能会感兴趣。

【参考方案2】：

3NF定义says那个

“所有非主属性必须只依赖于候选键。”

如果您有两个候选键，那么它们自然会定义所有其他属性，没关系。 3NF的要点是没有两边都有non-keys的FD。

【讨论】：

不清楚你所说的定义是什么意思，但引用并没有说明 3NF 的必要条件。链接文章中的陈述是错误的。 （***关系模型文章充满了误解和错误。）它可能试图说类似的东西，但它没有说出来。并且不清楚您所说的“NF 或 3NF 的点”是什么意思，但是“没有 FD 两边都没有非键”不是 3NF 的特征或结果。您也没有清楚地将您写的内容与帖子中的（不清楚的）问题联系起来。

@philipxy 好的。 Jeffrey Ullman 的定义是否足够好？它说：“对于每个重要的 FD，左侧是超级键，或者右侧仅包含主要属性。” 帖子中的问题对我来说很清楚，它问 “传递 FD user_id -> email ->（任何其他非关键属性）是否确实违反了 3NF？” 答案：不，它没有，因为在我们知道的所有 FD 中这张桌子左边有个钥匙。

Ullman 的定义和相关推理属于您的答案。请通过编辑而不是 cmets 进行澄清。 PS“Pretty clear”这里是“not clear”的委婉说法。 x->y->z 不是 FD。 user_id -> (first_name, last_name, ...) 不可传递。问题并没有说唯一持有的 FD 是这 2 个 CK 所暗示的。提问者也遵循了一些论点，他们最有可能想知道的是它出了什么问题，而您的评论没有解决这个问题——通常是对不清楚的问题的回答。