传递函数依赖如何在这里发生？
How would transitive functional dependencies occur here?
所以我正在阅读有关数据库规范化的内容，似乎在大多数情况下，我们中的很多人已经在没有意识到的情况下关注 2NF 甚至 3NF。我想知道为什么我们的教授 4 年前告诉我们这是硕士数据库课程中讨论的一个话题，因为它 "too complicated" 哈哈……对我来说听起来很直接……
无论如何，this article here 的一部分讨论了 3NF，要实现这一点，您需要具有 2NF 并且没有传递函数依赖性。
给出的示例是这张图片，但我不明白...非键列的值如何更改另一个非键列的值？如果有的话，对我来说这听起来像是系统中的一个故障，如果发生这种情况...
考虑 table 1. 更改非键列 Full Name 可能会更改 Salutation。
那篇文章太糟糕了。很明显，有些人发现很难理解规范化。 （很多人都在为 3NF 与 Boyce-Codd NF 之间的区别而苦恼，这篇文章没有解释。）文章说
Normalization helps produce database systems that are cost-effective and have better security models.
这不是规范化设计的主要原因。事实上，在关系模型的早期（当磁盘很昂贵时，例如日期有两位数的年份），规范化（即垂直分区）与成本效益相反，并且很多注意力都集中在贸易上在（部分）非规范化模式中关闭。
规范化的主要原因是避免重复信息 and/or 重复失调，称为 'update anomalies'。具体来说：
A transitive functional dependency is when changing a non-key column, might cause any of the other non-key columns to change
是一种糟糕的表达方式。但可能意味着：当您更新一行 (Membership Id 3) 的一列 (Full Name) 时，您还需要更新同一行或其他行的其他列 (Salutation) (s) (Membership Id 2?);如果不这样做，就会破坏数据的一致性。
这篇文章没有告诉我们 FD 应该持有什么。 Full Name 是否决定 Salutation？有没有可能 Membership ID 3 Robert Phil 有资格成为医生并因此改变他的 Salutation 而 Member 2 也没有成为医生？那么从Full Name到Salutation就没有FD了，貌似重复的条目也没有
大概这个例子试图展示的（我不确定，因为它是错误的）是 Full Name 和 Salutation 之间存在依赖关系。引入一个Salutation Id太...愚蠢了，我很想说"not even wrong"。它根本没有删除传递函数依赖。
规范化会（假设有一个从 Full Name 到 Salutation 的 FD）：
- 将
Full Name 和 Salutation 放在单独的 table 中，由 Full Name 键入——代表其中一个 FD。
- 从
Membership table 中删除 Salutation。
- 不引入
Salutation ID 字段。
- 您可以通过加入
Full Name, Salutation table. 来恢复原来的 Membership table
所谓的 3NF 形式没有去除传递函数依赖，因此不在 3NF 中。它所做的只是用一个从 Membership ID 到 Full Name 到 Salutation ID 的传递 FD 替换从 Membership ID 到 Full Name 到 Salutation。因此，如果 Member 3 将其名称从 Robert Phil 更改为 Roberta Phil，则在初始设计下 Salutation 必须逐步从 Mr 更改为 Ms;根据所谓的 3NF 设计 still Salutation ID 必须从 1 更改为 2.
还有其他理由认为所谓的 3NF 设计不是 3NF。我期望从 Person 到 Full Name 和 Address 的依赖关系。没有列 Person，因此有两个 Mr Robert Phil。他们是同一个人吗？那如果他们一起平了怎么办？文章试图引入复合键{Full Name, Address}，但这无济于事；同名父子住在同一个地址是很常见的。我们会在同一个地址有两个同名的人。 （如果他们中的一个人获得了医生资格呢？）
规范化会引入 Person ID，Person table 的键，列 Full Name、Salutation、Address。分区的 Membership table 将包含列 Membership ID（键）、Person ID（外键引用 Person）。
所以我正在阅读有关数据库规范化的内容，似乎在大多数情况下，我们中的很多人已经在没有意识到的情况下关注 2NF 甚至 3NF。我想知道为什么我们的教授 4 年前告诉我们这是硕士数据库课程中讨论的一个话题，因为它 "too complicated" 哈哈……对我来说听起来很直接……
无论如何，this article here 的一部分讨论了 3NF，要实现这一点，您需要具有 2NF 并且没有传递函数依赖性。
给出的示例是这张图片，但我不明白...非键列的值如何更改另一个非键列的值？如果有的话，对我来说这听起来像是系统中的一个故障，如果发生这种情况...
考虑 table 1. 更改非键列 Full Name 可能会更改 Salutation。
那篇文章太糟糕了。很明显，有些人发现很难理解规范化。 （很多人都在为 3NF 与 Boyce-Codd NF 之间的区别而苦恼，这篇文章没有解释。）文章说
Normalization helps produce database systems that are cost-effective and have better security models.
这不是规范化设计的主要原因。事实上，在关系模型的早期（当磁盘很昂贵时，例如日期有两位数的年份），规范化（即垂直分区）与成本效益相反，并且很多注意力都集中在贸易上在（部分）非规范化模式中关闭。
规范化的主要原因是避免重复信息 and/or 重复失调，称为 'update anomalies'。具体来说：
A transitive functional dependency is when changing a non-key column, might cause any of the other non-key columns to change
是一种糟糕的表达方式。但可能意味着：当您更新一行 (Membership Id 3) 的一列 (Full Name) 时，您还需要更新同一行或其他行的其他列 (Salutation) (s) (Membership Id 2?);如果不这样做，就会破坏数据的一致性。
这篇文章没有告诉我们 FD 应该持有什么。 Full Name 是否决定 Salutation？有没有可能 Membership ID 3 Robert Phil 有资格成为医生并因此改变他的 Salutation 而 Member 2 也没有成为医生？那么从Full Name到Salutation就没有FD了，貌似重复的条目也没有
大概这个例子试图展示的（我不确定，因为它是错误的）是 Full Name 和 Salutation 之间存在依赖关系。引入一个Salutation Id太...愚蠢了，我很想说"not even wrong"。它根本没有删除传递函数依赖。
规范化会（假设有一个从 Full Name 到 Salutation 的 FD）：
- 将
Full Name和Salutation放在单独的 table 中，由Full Name键入——代表其中一个 FD。 - 从
Membershiptable 中删除Salutation。 - 不引入
Salutation ID字段。 - 您可以通过加入
Full Name, Salutationtable. 来恢复原来的
Membership table
所谓的 3NF 形式没有去除传递函数依赖，因此不在 3NF 中。它所做的只是用一个从 Membership ID 到 Full Name 到 Salutation ID 的传递 FD 替换从 Membership ID 到 Full Name 到 Salutation。因此，如果 Member 3 将其名称从 Robert Phil 更改为 Roberta Phil，则在初始设计下 Salutation 必须逐步从 Mr 更改为 Ms;根据所谓的 3NF 设计 still Salutation ID 必须从 1 更改为 2.
还有其他理由认为所谓的 3NF 设计不是 3NF。我期望从 Person 到 Full Name 和 Address 的依赖关系。没有列 Person，因此有两个 Mr Robert Phil。他们是同一个人吗？那如果他们一起平了怎么办？文章试图引入复合键{Full Name, Address}，但这无济于事；同名父子住在同一个地址是很常见的。我们会在同一个地址有两个同名的人。 （如果他们中的一个人获得了医生资格呢？）
规范化会引入 Person ID，Person table 的键，列 Full Name、Salutation、Address。分区的 Membership table 将包含列 Membership ID（键）、Person ID（外键引用 Person）。