【发布时间】：2014-07-16 05:52:01
【问题描述】：
什么是 KISS（保持简单，愚蠢）方法来记住 Boyce-Codd 范式是什么以及如何获取非规范化表和 BCNF？
Wikipedia 的信息：对我没有太大帮助。
【问题讨论】：
-
@Smith325，首字母缩略词 KISS 的意思是“保持简单愚蠢”。他没有说任何人愚蠢。 :)
标签： database database-normalization bcnf
【发布时间】：2014-07-16 05:52:01
【问题描述】：
Chris Date的定义其实挺好的，只要你明白他的意思：
每个属性
您的数据必须分解为不依赖于任何其他属性的独立、不同的属性/列/值。你的全名是一个属性。你的生日是一个属性。您的年龄不是一个属性，它取决于当前日期，而不是您的生日。
必须代表一个事实
每个属性都是一个事实，而不是事实的集合。更改属性中的一位会改变整个含义。你的生日是事实。你的全名是事实吗？嗯，在某些情况下是这样，因为如果你改变你的姓氏，你的全名就不同了，对吧？但是对于系谱学家来说，你有一个姓氏和一个姓氏，如果你改变你的姓氏，你的姓氏不会改变，所以它们是不同的事实。
关于钥匙，
一个属性是特殊的，它是一把钥匙。键是一个属性，对于数据中的所有信息必须是唯一的，并且不得更改。您的全名不是关键，因为它可以更改。您的社会保险号不是关键，因为它们会被重复使用。你的 SSN 加上生日不是关键，即使这个组合永远不能重复使用，因为一个属性不能是两个事实的组合。 GUID 是一个键。一个你递增但从不重复使用的数字是一个关键。
整个键，
密钥本身必须足以 [ 并且是必要的！] 来识别您的价值观；您不能用不同的键表示相同的数据，键列的子集也不能足以识别事实。 假设您有一个带有 GUID 键、名称和地址值的地址簿。如果它们代表不同的人并且不是“相同的数据”，则可以使用不同的键出现两次相同的名称。 如果会计部门的 Mary Jones 将她的名字改为 Mary Smith，那么销售部门的 Mary Jones 也不会更改她的名字。 另一方面，如果 Mary Smith 和 John Smith 有相同的街道地址并且确实是同一个地方，则这是不允许的。您必须使用街道地址和新键创建一个新的键/值对。
您也不能将这个新的单一街道地址的键用作地址簿中的值，因为现在相同的街道地址键将被表示两次。 相反，您必须使用地址簿键和街道地址键的值创建第三个键/值对；您可以通过在这组值中匹配他们的书本键和地址键来找到一个人的街道地址。
只有钥匙
除了标识您的价值观的键之外，别无其他。例如，如果允许您使用“The Taj Mahal”的地址（假设只有一个），则不允许在同一记录中使用城市值， 因为如果你知道地址，你也会知道这个城市。这也将开启在不同城市拥有不止一座泰姬陵的可能性。 相反，您必须再次创建具有唯一值的辅助位置键，例如泰姬陵、华盛顿特区的白宫等，以及它们的城市。 或者禁止一个城市独有的“地址”。
所以帮帮我，科德。
【讨论】：
-
信息丰富的答案，但您认为您可以详细说明 BCNF 和 3NF 之间的区别吗？这个描述听起来和我读到的 3NF 完全一样
-
@Graphics，所有 BCNF 表都在 3NF 中，但如果一个键依赖于另一个键，则相反。比尔卡尔文的回答提到了这一点。我的示例是只能存在于某些城市的“地址”。这在 3NF 中是允许的，但在 BCNF 中是不允许的。检测这需要知道数据的含义，您无法从模式中检测到它。 en.wikipedia.org/wiki/BCNF 有一个将 3NF 转换为 BCNF 的示例。
-
首先，我喜欢签名“所以请帮帮我，Codd”，但我确实有一点要指出，并不是说您不正确。根据我的经验，Guids 被过度使用，无论是通过混淆或对象映射来实现安全性。在任何一种意义上，我都发现不需要它们。您经常强调 Guid 的使用，所以我只想指出，我不会说永远有更好的键。身份、顺序 Guid、INT NOT NULL、VARCHAR（如果它保证唯一）。这将允许在连接上进行聚集索引搜索，因此速度更快。
-
这不仅仅是信号。这是整个短语..“每个属性都必须......所以帮助我 Codd”。它来自肯特，早在 1989 年之前。
-
值得指出的是，一个键是一组n个属性，n=1的特例。 dpxo.net/articles/whycompositekeys.htm
以下是来自Third Normal Form 上的维基百科页面的一些有用摘录：
Bill Kent 这样定义第三范式：
每个非关键属性“必须提供 关于钥匙的事实，整个钥匙， 只有钥匙。”
要求非关键属性 依赖“全键”确保 表在 2NF 中；更远 要求非关键属性 依赖于“只有钥匙” 确保表在 3NF 中。
Chris Date 改编 Kent 的助记符来定义 Boyce-Codd 范式：
"每个属性必须代表一个事实 关于密钥，整个密钥，以及 只有钥匙。”这里的 要求与每一个 表中的属性，而不仅仅是 非关键属性。
当一个表有多个复合候选键，并且一个候选键中的一个属性依赖于另一个候选键的 part 时，这就会发挥作用。第三范式不会禁止这一点，因为它排除了关键属性。但 BCNF 也将规则应用于关键属性。
至于如何使一个表满足BCNF，你需要用另一个属性来表示额外的依赖关系，并且可能通过将属性拆分到另一个表中。
【讨论】：
-
这是我见过的对 BCNF 与 3NF 最好的解释
-
感谢@PiotrekDe！我试图在我的书 SQL Antipatterns: Avoiding the Pitfalls of Database Programming 的附录中写下所有正常形式的清晰描述
我用谷歌搜索了“boyce codd normal form”，在维基百科之后，这是第二个结果。我的教科书就关系数据库管理系统给出了一个非常简单的定义：
每个重要 FD 的左侧都必须是超级键。
-Garcia-Molina、Ullman 和 Widom 所著的“数据库系统全书”。
【讨论】：
-
啊，但是什么是超级键？ :-)
-
哇。我想这可以作为一个定义，但肯定不是一般的解释或记住 BCNF 的方式。任何我必须逐字逐句找出的解释都不能很好地发挥作用。
-
@MirroredFate 其他人在几段中解释了什么，这句话用一句话解释了。英语很直接。如果你关心 BCNF，你可能已经知道函数依赖和超级键，其余的都是简单的英语。
-
你需要解释一下FD & superkey。
我读过的最好的非正式答案是，在 BCNF 中，每个函数依赖项中的每个“箭头”都是候选键中的一个“箭头”。我不记得出处了，但可能是 Chris Date 写的。
【讨论】：
-
在每个重要的 FD 中。那么这就需要对 FD & CK 进行简单的定义。
基本上 Boyce-Codd 是“第五范式”。对于类型（例如角色、状态、流程状态、位置类型、电话类型等），它可以通过数据模型中存在的“属性实体”在视觉上识别。 属性实体（子子类型）是进一步分类类级别实体的有限值集的列表。所以你可能有电话类型（'mobile'、'desk'、'VOIP'）电子邮件帐户类型（'business'、'personal'、'gaming'）、角色（项目经理、数据建模师、超级模特）等. 另一个形态线索是超类型（又名大师班、超班、元实体）的存在，例如派对（子类型是公司、人等）。
基本上分类法已经变得疯狂（..no 视频不是那么令人兴奋）到原子级或叶级；有关更多技术性的解释，请参阅上述 Bill Karwin 的评论。
Boyce-Codd 级别模型本质上是高度详细的逻辑模型，源自更简单的基于业务的概念模型。 **它们通常不会在 PHYSICAL 模型中逐字实现，因为 PDM 性能（或功能简单性）优化可能会导致超类型和属性实体在 UI 中作为下拉列表或在幕后逻辑中进行管理在应用程序中，或在数据库约束和方法中强制引用完整性。 （即它们可能最终成为 PDM 模式中的查找表，或者它们可能由代码处理而不在数据库中表示）。
那么 - 如果它们最终可能不会出现在 PDM 中，为什么还要这样做呢？出于同样的原因，您在“优化”之前构建了一个良好的 3NF 模型，以便数据库结构反映现实世界，因此比我们继承的典型 kludges 更稳定，并且必须采取英勇的行动才能使我们的业务/客户工作需求变化。
【讨论】：
-
5NF 是 5NF & BCNF 不是 5NF。
通常情况下，听从你的直觉是最容易的，这会自然而然地发生。一般来说，如果你遇到了 3NF，你就遇到了 BCNF。这不包括对 ERD 的详细分析或示例，但根据 Codd 有 13 条规则。我发现最好遵循这些规则，但始终记住没有一种正确的做事方式，因此请松散地遵循它们。因此，关于 RDBMS，以下是规则：
http://www.87android.com/12-rules-of-relational-database-model-by-codd/
这可能无法直接回答问题，但如果您问的是如何获得 BCNF 或一种简单的记忆方法，那么您对规范化的理解还不够好。不过，这无关紧要。关系数据库有多种形式，但做得好的很少。你能做的最好的事情就是知道什么是关系，遵循上面的规则，不要担心规范化的水平。标准化过程消除了数据的重复。通过迁移功能依赖关系，每个级别都更是如此。记住这一点，你会没事的，剩下的就是你的直觉和智力。
【讨论】：