23

什么是 KISS（保持简单，愚蠢）方式来记住 Boyce-Codd 范式是什么以及如何获取非规范化表和 BCNF？

维基百科的信息：对我没有太大帮助。

4

6 回答 6

49

Chris Date 的定义其实挺好的，只要你明白他的意思：

每个属性

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

必须代表一个事实

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

关于钥匙，

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

整个钥匙，

单独的密钥必须是足够的 [和必要的！] 确定您的价值观；您不能用不同的键表示相同的数据，键列的子集也不能足以识别事实。假设您有一个带有 GUID 键、名称和地址值的地址簿。如果它们代表不同的人并且不是“相同的数据”，则可以使用不同的键出现两次相同的名称。如果会计部门的 Mary Jones 将她的名字改为 Mary Smith，那么销售部门的 Mary Jones 也不会更改她的名字。另一方面，如果 Mary Smith 和 John Smith 有相同的街道地址并且确实是同一个地方，则这是不允许的。您必须使用街道地址和新键创建一个新的键/值对。

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

只有钥匙

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

所以帮助我，科德。

于 2009-02-12T04:15:30.253 回答
11

以下是第三范式的维基百科页面的一些有用摘录：

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

每个非关键属性“必须提供关于关键的事实、完整的关键，而且只有关键”。

要求非键属性依赖于“整个键”确保表在 2NF 中；进一步要求非键属性依赖于“只有键”确保表在 3NF 中。

Chris Date 改编 Kent 的助记符来定义 Boyce-Codd 范式：

“每个属性必须代表一个关于密钥的事实，整个密钥，除了密钥之外什么都没有。” 这里的要求涉及表中的每个属性，而不仅仅是非关键属性。

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

至于如何使一个表满足BCNF，你需要用另一个属性来表示额外的依赖关系，并且可能通过将属性拆分到另一个表中。

于 2009-02-12T00:06:28.853 回答
1

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

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

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

于 2012-10-10T05:46:36.657 回答
0

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

于 2013-02-02T16:08:54.063 回答
0

基本上 Boyce-Codd 是“第五范式”。对于类型（例如角色、状态、流程状态、位置类型、电话类型等），数据模型中存在“属性实体”可以直观地识别它。属性实体（子子类型）是进一步分类类级别实体的有限值集的列表。所以你可能有电话类型（'mobile'、'desk'、'VOIP'）电子邮件帐户类型（'business'、'personal'、'gaming'）、角色（项目经理、数据建模师、超级模特）等. 另一个形态线索是超类型的存在，（又名大师班、超班、元实体），例如派对（子类型是公司、人等）。

基本上分类学已经疯狂（..no视频不是那么令人兴奋）到原子或叶级；有关更多技术性的解释，请参阅上面的 Bill Karwin 的评论。

Boyce-Codd 级别模型本质上是高度详细的逻辑模型，源自更简单的基于业务的概念模型。**它们通常不会在 PHYSICAL 模型中逐字执行，因为 PDM 对性能（或功能简单性）的优化可能会导致超类型和属性实体在 UI 中作为下拉列表或在幕后逻辑中进行管理在应用程序中，或在数据库约束和方法中强制引用完整性。（即它们可能最终成为 PDM 模式中的查找表，或者它们可能由代码处理而不在数据库中表示）。

那么 - 如果它们最终可能不会出现在 PDM 中，为什么还要这样做呢？出于同样的原因，您在“优化”之前构建了一个良好的 3NF 模型，以便数据库结构反映现实世界，因此比我们继承的典型 kludges 更稳定，并且必须采取英勇的行动才能使我们的业务/客户工作需求变化。

于 2014-04-09T00:22:02.017 回答
-1

很多时候，倾听你的直觉是最容易的，这会自然而然地发生。一般来说，如果你遇到了 3NF，你就遇到了 BCNF。这不包括对 ERD 的详细分析或有示例，但根据 Codd 有 13 条规则。我发现最好遵循这些规则，但始终记住没有一种正确的做事方式，因此请松散地遵循它们。因此，关于 RDBMS，以下是规则：

http://www.87android.com/12-rules-of-relational-database-model-by-codd/

这可能无法直接回答问题，但如果您询问如何获得 BCNF 或一种简单的记忆方法，那么您对规范化的理解还不够好。不过，这无关紧要。关系数据库有多种形式，但做得好的很少。你能做的最好的事情就是知道什么是关系，遵循上面的规则，不要担心规范化的水平。标准化过程消除了数据的重复。通过迁移功能依赖关系，每个级别都更是如此。记住这一点，你会没事的，剩下的就是你的直觉和智力。

于 2014-07-15T21:52:01.927 回答