什么是KISS（保持简单，愚蠢）的方式来记住Boyce-Codd正常形式是什么以及如何采用非标准化表格和BCNF呢？
Wikipedia的信息：对我来说不是很有帮助。
答案 0 :(得分：50)
Chris Date的定义实际上非常好，只要你明白他的意思：
您的数据必须分成单独的，不同的属性/列/值，这些属性/列/值不依赖于任何其他属性。您的全名是一个属性。你的生日是一个属性。您的年龄不是属性，它取决于当前日期，而不是您的出生日期的一部分。
每个属性都是一个事实，而不是事实的集合。更改属性中的一位会改变整个含义。你的出生日期是事实。你的全名是一个事实吗？好吧，在某些情况下，它是，因为如果你改变你的姓氏，你的全名是不同的，对吧？但是对于一个系谱学家来说，你有姓氏和姓氏，如果你改姓，你的姓氏就不会改变，所以他们是不同的事实。
一个属性很特别，它是一个关键。密钥是一个属性，对于数据中的所有信息必须是唯一的，并且永远不能更改。您的全名不是关键，因为它可以更改。您的社会保险号码不是关键因素，因为它们可以重复使用。即使组合永远不能重复使用，您的SSN加上生日也不是关键，因为属性不能是两个事实的组合。 GUID是关键。你增加并永不重用的数字是关键。
单独的密钥必须足够[且必要！]来识别您的价值观;您不能拥有由不同密钥表示的相同数据，密钥列的子集也不足以识别该事实。 假设您有一个带有GUID密钥，名称和地址值的地址簿。如果它们代表不同的人并且不是“相同的数据”，则可以使用不同的密钥出现两次相同的名称。 如果玛丽琼斯在会计上改名为玛丽史密斯，玛丽琼斯在销售中也不会改变她的名字。 另一方面，如果玛丽史密斯和约翰史密斯拥有相同的街道地址并且它实际上是相同的地方，则不允许这样做。您必须使用街道地址和新密钥创建新的键/值对。
您也不被允许将此新单街道地址的密钥用作地址簿中的值，因为现在相同的街道地址密钥将被表示两次。 相反，您必须使用地址簿键和街道地址键的值创建第三个键/值对;您可以通过匹配此组值中的书籍密钥和地址键来查找某人的街道地址。
除了识别您的价值观的钥匙外，别无其他。例如，如果您被允许使用“泰姬陵”的地址（假设只有一个），则不允许在同一记录中使用城市值， 因为如果你知道地址，你也会知道这个城市。这也将开启在不同城市中有不止一个泰姬陵的可能性。 相反，您必须再次创建具有唯一值的辅助位置键，例如Taj，DC中的白宫等，以及他们的城市。 或者禁止一个城市独有的“地址”。
答案 1 :(得分：12)
以下是Third Normal Form上维基百科页面的一些有用摘录：
Bill Kent以这种方式定义第三范式：
每个非关键属性“必须提供 关于钥匙的事实，整个钥匙， 除了钥匙外别无他物。“
要求非关键属性 依赖“整个关键”确保 一张桌子在2NF;进一步 要求非关键属性 依赖于“只有关键” 确保表格在3NF。
Chris Date使用Kent的助记符来定义Boyce-Codd Normal Form：
“每个属性都必须代表一个事实 关于钥匙，整个钥匙，和 只有关键。“这里 要求与每一个有关 表中的属性，而不仅仅是 非关键属性。
当表具有多个复合候选键，并且一个候选键中的属性依赖于另一个候选键的部分时，这会发挥作用。第三范式不会禁止这一点，因为它排除了关键属性。但BCNF也将规则应用于关键属性。
至于如何使表满足BCNF，您需要使用另一个属性表示额外的依赖关系，并可能通过将属性拆分到另一个表中。
答案 2 :(得分：1)
我用Google搜索“boyce codd normal form”，在维基百科之后这是第二个结果。我的教科书在关系数据库管理系统方面给出了一个非常简单的定义：
每个重要FD的左侧必须是超级钥匙。
- Garcia-Molina，Ullman和Widom的“数据库系统全集”。
答案 3 :(得分：1)
基本上，博伊斯 - 科德是“第五范式”。它可以通过数据模型中“属性实体”的存在来识别，例如类型（例如角色，状态，进程状态，位置类型，电话类型等）。 属性实体（子子类型）是有限值集的列表，其进一步对类级实体进行分类。因此，您可能有电话类型（“移动”，“桌面”，“VOIP”）电子邮件帐户类型（“业务”，“个人”，“游戏”），角色（项目经理，数据建模，超级模型）等。 另一种形态线索是超类型的存在，（例如，大师班，超类，元实体），例如缔约方（子类型是公司，人等）。
基本上，分类学在原子或叶子层面上变得疯狂（...视频不那么令人兴奋）;请参阅Bill Karwin上面的评论，以获得更多技术性解释。
Boyce-Codd级别模型本质上是非常详细的逻辑模型，源自更简单的基于业务的概念模型。 **它们通常不会在PHYSICAL模型中实现，因为性能（或功能简单）的PDM优化可能导致超类型和属性实体作为UI中的下拉列表或幕后逻辑进行管理在应用程序中，或在数据库约束和方法中强制引用完整性。 （即它们可能最终成为PDM模式中的查找表，或者它们可能由代码处理而不在数据库中表示）。
那么 - 如果他们可能不会进入PDM，他们为什么要这样做？出于同样的原因，你在“优化”之前建立了一个好的3NF模型，这样数据库结构就能反映现实世界，因此比我们继承的典型kludges更稳定，并且必须做英雄行为才能使我们的业务/客户工作要求改变。
答案 4 :(得分：0)
我读过的最好的非正式回答是，在BCNF，每一个＆＃34;箭头＆＃34;在每个功能依赖中都是一个＆＃34;箭头＆＃34;一个候选键。我不记得这个消息来源，但这可能是Chris Date写的。
答案 5 :(得分：0)
通常最容易听到你的直觉，这将是自然而然的。一般来说，如果你遇到3NF，你就遇到了BCNF。这并不包括对ERD的详细分析或有示例，但根据Codd有十三条规则。我发现最好遵循这些规则，但始终记住，没有一种正确的方法可以做到，所以要松散地遵循它们。关于RDBMS，以下是规则：
http://www.87android.com/12-rules-of-relational-database-model-by-codd/
这可能不会直接回答这个问题，但是如果你问的是如何到达BCNF或者一个简单的方法来记住它，那么你就不能很好地理解正常化。但这并不重要。关系数据库采用多种形式，很少有很好的表现。你能做的最好的事情就是知道关系是什么意思，遵循上面的规则，不要担心规范化的程度。规范化过程消除了数据的重复。通过迁移功能依赖的迁移，每个级别都更加如此。牢记这一点，你会很好，你的直觉和智力将完成其余的工作。