Database 什么是Boyce Codd范式的良好吻描述？

什么是一个吻（保持简单，愚蠢）的方式来记住什么是Boyce Codd标准形式，以及如何采取一个非标准化的表格和BCNF它

---

信息：对我没有太大帮助。

以下是维基百科页面上的一些有用摘录：

比尔·肯特这样定义了第三范式：

每个非关键属性“必须提供 关于钥匙的事实，整个钥匙， 只有钥匙。”

要求非关键属性 依靠“整把钥匙”确保 一个表是2NF的；进一步的 要求非关键属性 依靠“只有钥匙” 确保表格为3NF格式

Chris Date采用Kent的助记符来定义Boyce Codd范式：

“每个属性都必须表示一个事实 关于钥匙，整个钥匙，还有 除了钥匙什么都没有。”这是钥匙 需求涉及到每一个方面 属性，而不仅仅是 非关键属性

当一个表有多个复合候选键，并且一个候选键中的属性依赖于另一个候选键的一部分时，这一点就开始发挥作用。第三种范式不会禁止这种情况，因为它排除了关键属性。但BCNF也将该规则应用于关键属性

---

至于如何使一个表满足BCNF，您需要用另一个属性表示额外的依赖关系，可能还需要将属性拆分为另一个表。

Chris Date的定义实际上很好，只要您理解他的意思：

每个属性 必须将数据分解为独立的、不同的属性/列/值，这些属性/列/值不依赖于任何其他属性。您的全名是一个属性。你的生日是一个属性。你的年龄不是一个属性，它取决于不属于你生日的当前日期

必须代表一个事实 每个属性都是单个事实，而不是事实的集合。更改属性中的一位会更改整个含义。你的生日是事实。你的全名是事实吗？嗯，在某些情况下是这样的，因为如果你改姓，你的全名就不一样了，对吧？但对于系谱学家来说，你有姓氏和姓氏，如果你改变姓氏，你的姓氏不会改变，所以它们是不同的事实

关于钥匙， 一个属性是特殊的，它是一个键。密钥是一个属性，它对于数据中的所有信息都必须是唯一的，并且永远不能更改。您的全名不是密钥，因为它可以更改。你的社会保险号码不是关键，因为它们会被重复使用。您的SSN plus生日不是一个键，即使组合永远不能重用，因为属性不能是两个事实的组合。GUID是一个键。一个你不断增加但从不重复使用的数字是一个键

整把钥匙,， 单凭钥匙就必须足以[而且是必要的！]识别您的价值观；不同的键不能表示相同的数据，键列的子集也不足以识别事实。 假设您有一个带有GUID键、名称和地址值的通讯簿。如果相同的名字代表不同的人，并且不是“相同的数据”，则可以用不同的键显示两次。 如果会计部的玛丽·琼斯改名为玛丽·史密斯，销售部的玛丽·琼斯也不会改名。 另一方面，如果玛丽·史密斯和约翰·史密斯有相同的街道地址，而且确实是同一个地方，这是不允许的。您必须使用街道地址和新密钥创建一个新的密钥/值对

您也不允许将此新的单一街道地址的键用作通讯簿中的值，因为现在同一街道地址键将被表示两次。 相反，您必须使用地址簿密钥和街道地址密钥的值创建第三个密钥/值对；通过在这组值中匹配某人的book key和address key，可以找到此人的街道地址

除了钥匙什么都没有 除了标识您的值的键之外，不能有其他东西。例如，如果允许您输入“泰姬陵”地址（假设只有一个），则不允许在同一记录中输入城市值， 因为如果你知道地址，你也会知道这个城市。这也将开启在不同城市有不止一座泰姬陵的可能性。 相反，您必须再次创建具有独特值的辅助位置键，如泰姬陵、华盛顿特区的白宫等，以及它们的城市。 或者禁止城市特有的“地址”

帮帮我，Codd.我在谷歌上搜索了“boyce Codd normal form”，这是继维基百科之后的第二个结果。我的教科书给出了关系数据库管理系统的一个非常简单的定义：

每个非平凡FD的左侧必须是一个超级键。

---

-Garcia Molina、Ullman和Widom的《数据库系统全书》。

我读过的最好的非正式回答是，在BCNF中，每个函数依赖项中的每个“箭头”都是候选键中的一个“箭头”。我不记得来源，但可能是Chris Date写的。

基本上，Boyce Codd是“第五范式”。通过数据模型中“属性实体”的存在，例如类型（例如角色、状态、流程状态、位置类型、电话类型等），可以从视觉上识别它。 属性实体（子类型）是对类级实体进行进一步分类的有限值集的列表。因此，您可能有一个电话类型（“移动”、“桌面”、“VOIP”）、电子邮件帐户类型（“业务”、“个人”、“游戏”）、角色（项目经理、数据建模师、超级模型）等。 另一个形态学线索是超类型（又名主类、超类、元实体）的存在，例如Parties（子类型为company、person等）

基本上，分类法已经疯狂到原子级或叶子级（…不，视频没有那么激动人心）；请参阅比尔·卡温（Bill Karwin）的上述评论，了解更多技术性信息