这里将如何发生传递函数依赖？答案

【问题标题】：How would transitive functional dependencies occur here?这里将如何发生传递函数依赖？
【发布时间】：2020-05-15 07:09:21
【问题描述】：

所以我正在阅读数据库规范化，而且似乎在大多数情况下，我们很多人已经在关注 2NF 甚至 3NF 而没有意识到这一点。我想知道为什么我们的教授在 4 年前告诉我们这是硕士数据库课程中讨论的主题，因为它“太复杂”了哈哈……听起来对我来说真的很直接……

无论如何，this article here 的一部分讨论了 3NF，为了实现这一点，您需要有 2NF 并且没有传递函数依赖。

给出的例子是这张图片，但我不明白......非键列的值如何改变另一个非键列的值？如果有的话，在我看来，如果发生这种情况，这听起来像是系统中的一个小故障......

考虑表 1。更改非键列 Full Name 可能会更改 Salutation。

【问题讨论】：

我不知道为什么 3NF 会被描述为“太复杂”。 “一次存储数据并将其放入适当的实体”的原则对我来说似乎很简单。诚然，它确实有一些反作用。
@GordonLinoff 是的，实际上，整个规范化主题在当时对本科生来说被认为“太复杂”了。所以我当时是个天真的 CS 学生，我只是按照我们被告知的内容滚动，并没有费心去探索它，因为我认为这是一个 PHD 主题或什么的。你学到的东西......
。 .我发现它的学术处理相当复杂。向学生展示一些构建数据库的正确方法的示例；解释关键原则；给他们家庭作业如何解决一些问题。然后测试它们。从实际数据库设计的角度来看，我发现1NF、2NF等的处理有点抽象。
@GordonLinoff 我不骗你，我记得在数据库课上学过的只是理论和数学。实际实施和实际建立数据库？不，我们是靠自己的。我希望他向我们展示了我们开始所需的工具，以及现有的不同数据库并实际向我们展示了示例。一直以来这只是理论上的，我发现主键/外键/复合键的概念非常混乱，直到我不得不在工作中实现它时才理解它。它如此简单，但它们使事情变得如此复杂，荒谬
。 .我想我很幸运。我不得不从头开始构建一个——然后是另一个——来了解数据库。理论中唯一引起共鸣的部分是底层算法的算法和复杂性。

标签： relational-database database-normalization functional-dependencies

【解决方案1】：

那篇文章很糟糕。很明显，有些人发现很难理解规范化。（很多人都在为 3NF 与 Boyce-Codd NF 之间的区别而苦恼，这篇文章没有解释。）文章说

规范化有助于生成具有成本效益且具有更好安全模型的数据库系统。

这不是规范设计的主要原因。确实在关系模型的早期（当磁盘很昂贵时，例如日期有两位数的年份），规范化（即垂直分区）与成本效益相反，并且很多注意力都放在了交易上—— （部分）非规范化模式中的偏移。

规范化的主要原因是避免重复信息和/或重复不同步，称为“更新异常”。具体来说：

传递函数依赖是在更改非键列时，可能会导致任何其他非键列发生更改

这是一种糟糕的表达方式。但可能意味着：当您更新一行 (Membership Id 3) 的一列 (Full Name) 时，您还需要更新同一行或其他行 (@987654324) 的其他列 (Salutation) @ 2？）；否则，您会破坏数据的一致性。

这篇文章没有告诉我们预期持有什么 FD。 Full Name 是否确定 Salutation？ Membership ID 3 Robert Phil 是否有可能有资格成为医生，因此在Member 2 也没有成为医生的情况下更改他的Salutation？那么Full Name到Salutation之间就没有FD了，看起来重复的条目也没有。

大概该示例试图显示的内容（我不确定，因为它是错误的）是Full Name 和Salutation 之间存在依赖关系。介绍Salutation Id 太……愚蠢，我很想说“甚至没有错”。它根本没有移除传递函数依赖。

标准化将（假设有一个从Full Name 到Salutation 的FD）：

将Full Name 和Salutation 放在一个单独的表中，以Full Name 为关键字——代表其中一个FD。
从Membership 表中删除Salutation。
不引入Salutation ID 字段。
您可以通过加入Full Name, Salutation 表来恢复原始Membership 表。

所谓的 3NF 形式没有删除传递函数依赖，因此不在 3NF 中。它所做的只是将一个从Membership ID 到Full Name 到Salutation 的传递FD 替换为从Membership ID 到Full Name 到Salutation ID 的一个。因此，如果Member 3 将其名称从Robert Phil 更改为Roberta Phil，则在初始设计下Salutation 必须逐步从Mr 更改为Ms；在所谓的 3NF 设计下仍然，Salutation ID 必须从 1 更改为 2。

还有其他理由认为所谓的 3NF 设计不是 3NF。我希望 Person 依赖于 Full Name 和 Address。没有Person 列，因此有两个Mr Robert Phils。他们是同一个人吗？那如果他们在一起呢？文章试图介绍一个复合键{Full Name, Address}，但这无济于事；同名父子住在同一个地址是很常见的。我们会有两个同名的人在同一个地址。（如果其中一个有资格成为医生呢？）

规范化将引入一个Person ID，一个Person 表的键，包含Full Name、Salutation、Address 列。分区的Membership 表将包含列Membership ID（键）、Person ID（外键引用Person）。

【讨论】：

我明白了，谢谢你的详细分类！现在我明白了，所以它基本上就像说： person -> full name , fullname->salutation, person ->salutation 是一个函数依赖，所以为了在 3NF 中对其进行规范化，将表划分为 person 表和 members 表，然后通过人员 ID PK 将它们链接起来，这将确保数据/参考完整性，规范化的目标
这篇文章不值得再浪费时间了。它讨论了传递 FD，但没有定义 FD，也没有给我们任何 FD。因此，我根据介绍文章中通常发现的那种 FD 进行猜测（以及文章似乎试图提出的观点）。我猜这篇文章认为有一个 FD fullname->salutation。但这不现实：Mr 和 Dr 可能有相同的全名；一位女士、一位女士和一位博士可能有相同的全名（同一个人未婚然后结婚然后有资格）。更现实的是 2 个 FD person->fullname、person->Salutation 和 person->Address。
知道了，谢谢！这是搜索引擎上出现的第一篇文章，所以认为排名/评级一定意味着它相当不错。
@Cataster & AntC "规范化将引入Person ID，Person 表的关键..." 在常识下适当的基本简单设计可以做到这一点。规范化不会。对更高 NF 的规范化不会引入新的属性名称。此外，“规范化”必须适用于特定表或表集合。它用自然连接回它的较小的表来替换基表。我确信 AntC 知道这一切。
@Cataster 关注一本（好的）出版的关于信息建模、关系模型和数据库设计和查询的学术教科书。（用于记录和使用设计的语言和工具的手册不是这样的教科书。）（维基文章或网络帖子也不是。）数十个在线免费。还有 DBMS 参考手册。