不同表中的数据冗余是否不遵循第三范式（3NF）？答案

【问题标题】：Does data redundancy in different tables not follow Third Normal Form (3NF)?不同表中的数据冗余是否不遵循第三范式（3NF）？
【发布时间】：2017-04-03 10:57:53
【问题描述】：

我有 4 张桌子。它们中的每一个都包含以下属性：

Table 1 :
 Person (Id (Primary key), Name, Occupation, Location, SecondJob, PerHour, HoursWorked, Phone, Workphone)

Table 2 :
 Job (Id (Foreign key that refers to Person), Title, Name, Location, Salary)

Table 3 :
 SecondJob (Id (Foreign key that refers to Person), Title, Name)

Table 4:
 PhoneNumber (Id (Foreign key that refers to Person), Name, Phone, Workphone)

我可以使用以下伪 SQL 语句从 Person 表中获取 Name、Title、Phone 和 Workphone 等每个属性的值：

Select (ATTRIBUTE NAME) FROM Person WHERE Id IN (PERSONS ID)

某些信息在不同的表中重复（数据冗余）这一事实是否打破（即不遵循）第三范式 (3NF)？

或者应该将这些值单独放入其他表中，并说明什么属性与表的主键标识？
我通过从 Person 获取 PerHour 和 HoursWorked 来计算工作中的薪水，然后将它们相乘。我还听说这是冗余数据，因为您可以从表格中的现有数据推断出这些数据。

但是，这是否违反了第三范式？？

【问题讨论】：

这在标准化方面非常糟糕。为什么“名字”随处可见？为什么这些信息没有合并到 Person 记录中？如果您出于性能原因故意去规范化，您是否有方法使这些数据保持同步并了解每个字段的规范来源？为什么 PhoneNumber 包含两个号码？你需要做很多工作来解决细节问题。
记住在正确的数据库设计中你只有Zero, One or Infinity，没有两个。这就是为什么SecondJob 作为表格非常令人担忧。如果他们有第三份工作怎么办？第四个？十九？人们转行，升职，调动，可以预料人们会转换N次。同样，工资信息应该与工作相关联，而不是与人员相关联。
对您的回复的反馈： 1. 虽然您的第二篇文章实际上有一些有效的观点 - 指出诸如“在规范化方面如此糟糕”之类的东西，没有明确的指向为什么，基本上没有用回馈。 2. Secondjob 只是一个名字。它是如何形成的，仍然允许几个不同的工作来填充它——通过 ID 引用外键。 3. 规范化仍然依赖于主键和对所述键的整体识别。存在重复数据。不过，手机部分需要修改。
“将值分别放入其他表中，原因是什么属性与表的主键标识”不清楚。
主题的主要关注点是不同表中的值重复。这意味着我提出的一个建议是将重复值放入单独的表中 - 而不是在多个表中重复相同的值。即：一张表中的姓名和 ID，一张表中的工作和电话号码等。

标签： mysql database-normalization

【解决方案1】：

信息在不同表中重复（数据冗余）这一事实是否违反了 3NF 规范化？

没有。表值或变量是否在给定的 NF 中。这独立于任何其他表。（我们也讨论了一个数据库在 NF 中，而它的所有表都在该 NF 中。）

规范化可以说是消除冗余。但是规范化没有解决很多冗余问题。并且有很多冗余也不错。重复不一定是冗余。仅仅因为 data 被重复并不意味着“信息”被重复。数据在表中的存在与否取决于表的含义。

但是您似乎认为，仅仅因为在不同的表中复制数据不违反 3NF，它就不会违反其他良好设计的原则。那是错误的。此外，重要的是 5NF。使用较低 NF 的唯一原因是 SQL DBMS 不能很好地支持 5NF。

或者我应该将值单独放入其他表中，并说明用表的主键标识的属性是什么？

我猜你是想说，我应该只将值放在一个表中，然后通过涉及共享键的查询重建第二个表吗？即，如果您可以通过查询数据库的其余部分来获取列中的值，那么您是否应该避免使用该列？一般来说，是的。

您的问题是一种误解。这不是“（排他的）或”的问题。你应该两者都做。

我通过从 Person 获取 PerHour 和 HoursWorked 来计算工作中的薪水，然后将它们相乘。我听说这也是冗余数据，因为它是您可以从表中的现有数据中推断出来的数据。

考虑到数据库的其余部分，这是多余的，因为您可以使用查询来代替。如果你没有适当地限制工资值，那么这就是不好的冗余。即使您执行列和约束会使架构复杂化。

但它会破坏 3NF 标准化吗？

不，因为一个表的 NF 独立于其他表。但这并不意味着没问题。

（如果您将 Salary 添加到 Person，则新表将不在 3NF 中。但是，SQL DBMS 具有 计算列 可以通过将具有 Salary 的非 3NF 表设为没有它的 3NF 表的视图。）

了解一些数据库设计方法以及它们如何应用良好设计的原则。您的表格不必要地处理应用程序的重叠方面。还可以在编写查询时了解 JOIN。

【讨论】：