SQL 数据库中的函数依赖范式答案

【问题标题】：functional dependencies in SQL databases Normal formsSQL 数据库中的函数依赖范式
【发布时间】：2010-12-10 12:01:24
【问题描述】：

SQL 数据库中有两个函数依赖项。

a) 部分功能依赖：非键列依赖于复合主键中的一些列，但不是所有列。

b) 传递函数依赖：任何非键列都依赖于其他非键列。

对于一个好的 SQL 数据库。

规则 1：列仅包含原子值

规则 2：没有重复的数据组

规则 3：没有部分依赖

规则 4：没有传递依赖

我已经理解了第 1 条和第 2 条规则的要求，为什么我们需要第 3 条和第 4 条规则，而不是说 no 列不应该依赖于其他列。为什么有两个单独的规则（3 和 4）？

来源：Head First SQL

提前致谢！

【问题讨论】：

“没有列不应该依赖于其他列”——你的意思是像“非键列应该只依赖于整个键”吗？英语中的双重否定很棘手。
@outis ：感谢您澄清问题，我的意思是，我们不能说“数据库的列不应依赖于主键以外的任何其他列，而不是单独的规则列。如果主键是复合列，那么，我的意思是，对于这个依赖问题，它将被视为单个列"
是的，当然有不同的方式来解释同一件事。但是，您的定义并不完美。仅依赖一个键（“主键”）是不够的。每个属性都应该依赖于表的所有键。
@dportas ：我不明白你。 >“仅依赖一个键（“主键”）是不够的。每个属性都应依赖于表的所有键。”请详细说明一下。
例如，给定以下一组 FD：AB->C、C->D、C->AB，您需要两个键：AB 和 C。

标签： sql mysql database database-design

【解决方案1】：

好问题。纯粹出于历史和教学原因，这两者经常分开。

第二范式 (2NF) 只涉及消除部分密钥依赖关系。单独的 2NF 通常不是特别重要，因为第三范式、Boyce Codd 范式和更高的范式也消除了那些相同的部分密钥依赖关系，并且那些 NF (> 2NF) 通常是数据库设计中的预期目标。但是，通常的做法是使用分解过程来教授标准化。通过分解方法，通常首先考虑部分关键依赖关系。实际上，大多数从业者很少这样做，他们经常会同时考虑所有依赖项。

高于 2NF 的范式定义根本不需要将部分键依赖关系作为特例。 Boyce Codd 范式可以简单概括为这意味着每个非平凡的函数行列式都是一个超级键 - 换句话说，除了键之外没有任何非平凡的 FD。

【讨论】：