传递性功能依赖在这里如何发生？

Question

因此，我正在阅读数据库规范化，并且似乎在大多数情况下，我们许多人已经在不了解2NF甚至3NF的情况下对其进行跟踪。我不知道为什么我们的教授4年前告诉我们，那是大师数据库课程中讨论的一个话题，因为它的“太复杂了”哈哈...听起来真的很直白...

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

给出的示例是此图像，但我不明白...非键列的值如何更改另一个非键列的值？如果有的话，对我来说，这听起来像是系统中的一个小故障...

考虑表1.更改非关键列全名可能会更改称呼。

Answer 1

那篇文章很糟糕。显然，有些人很难理解规范化。 （许多人都在为3NF与Boyce-Codd NF之间的区别而苦苦挣扎，本文对此予以解释。）

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

这不是规范设计的主要原因。确实，在关系模型的早期（当磁盘价格昂贵时，例如日期有两位数的年份），规范化（即垂直分区）与具有成本效益的方法相反，因此，很多注意力都集中在交易-在（部分）非规范化模式中关闭。

进行标准化的主要原因是避免重复的信息和/或重复的步调不一致，这被称为“更新异常”。具体来说：

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

这是一种糟糕的表达方式。但可能意味着：更新一行（Full Name 3）的一列（Membership Id）时，您还需要更新同一行或其他行（[C0 ] 2？）;否则，将破坏数据的一致性。

本文没有告诉我们期望持有什么FD。 Salutation确定Membership Id吗？Full Name3 Salutation是否有资格成为医生，因此可以更改其Membership ID而没有Robert Phil 2也成为医生？然后，从Salutation到Member没有FD，看起来重复的条目也不是。

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

归一化（假设从Salutation到Salutation Id的FD）：

• 将Full Name和Salutation放在一个单独的表中，用Full Name键表示-表示FD之一。
• 从Salutation表中删除Full Name。
• 不引入Salutation字段。
• 您可以通过加入Membership表来恢复原始的Salutation ID表。

所谓的3NF表格尚未删除传递功能依赖性，因此3NF也不例外。它所做的就是用Membership至Full Name, Salutation至Membership ID中的一个替换从Full Name至Salutation至Membership ID的过渡FD。因此，如果Full Name 3将其名称从Salutation ID更改为Member，则在初始设计下，Robert Phil必须逐步从Roberta Phil更改为Salutation；根据所谓的3NF设计still

，Mr必须从Ms更改为Salutation ID。

还有其他理由认为所谓的3NF设计不是3NF。我希望从Person到1和2都具有依赖性。没有列Full Name，因此有两个Address。他们是同一个人吗？那如果他们放在一起怎么办？本文尝试引入复合键Person，但这无济于事；同名父亲和儿子住在同一个地址是很普遍的。我们会有两个人在同一地址同名。 （如果其中一个人有资格获得博士学位怎么办？）

归一化将为带有列Mr Robert Phil，{Full Name, Address}，Person ID的Person表引入Full Name键。分区的Salutation表将具有列Address（键），Membership（外键引用Membership ID）。