数据库模式规范化违规答案

【问题标题】：Database Schema Normalization Violation数据库模式规范化违规
【发布时间】：2017-03-11 18:12:01
【问题描述】：

据我所知，以下内容不违反 1NF 或 2NF。是否违反了 3NF，因为 LocationID 和 LocationName 没有分成不同的表？

部门（DNum PK、DName、LocationID、LocationName）

【问题讨论】：

【解决方案1】：

您不能仅根据属性名称列表确定关系是否被规范化。真正重要的是应用于这些属性的依赖项。例如，给定以下一组依赖项

F: {DNum}->{LocationID}->{DNum,DName,LocationName}

我们可以说 Department 关于 F 满足 3NF（因此满足 2NF），因为 DNum 和 LocationID 都应该是 Department 的键，并且除了这些键所隐含的那些之外，没有其他功能依赖关系。就规范化而言，主键的选择是无关紧要的，因为一个关系可能有多个键，并且所有键都同等重要。

或者，给定以下一组依赖项

G: {DNum}->{DName,LocationID,LocationName}, {LocationID}->{LocationName}

Department 关系违反了关于 G 的 3NF，因为 LocationID 是非关键决定因素。

【讨论】：

【解决方案2】：

是的，违反了 3NF。

3NF 需要 2NF 并且没有非关键字段应该依赖于另一个非关键字段。

LocationName 取决于 LocationID，因为（我假设）LocationID 是一个 PK，这就是违规。

^{我之前在这个another answer中解释了1NF、2NF和3NF。}

【讨论】：

+1 唯一的例外是每个部门都有自己的位置名称。就像位置可能会发生变化，但每个部门都知道自己的位置作为部门创建时的当前名称。与在电子商务系统中记录每个订单的产品价格类似的问题。价格可能会发生变化，因此每个订单都需要记录下订单时的价格。
@BillKarwin：这是您指出的一个很好的例外情况。为此 +1。
因此，如果我正确阅读了您的其他答案，以下将违反 2NF，因为没有唯一索引？ “客户（客户名称、客户名称_地址、描述）”
@TechTubeCentral：您的意思是 Customer 表中没有 PK。在这种情况下是的，也违反了 2NF。
@TechTubeCentral，范式不需要主键是整数。如果 CustName 是唯一的并且是表的主键，那么您的示例 Customer 表满足 2NF 和 3NF。