Normalization 3NF范式

我有一个关于3NF范式的问题：

Normalize, with respect to 3NF, the relational scheme E(A, B, C, D, E, F) 
by assuming that (A, B, C) is the unique candidate key and that the following additional functional dependencies hold: 
    A,B -> D 
    C,D -> E 
    E -> F 

我的理解是，如果我应用3NF，即如果所有属性

非素数不可传递地依赖于任何关键候选项，结果应为：

E'=（A，B，C，E，F），E'=（B，D），E'=（A，B，C，D，F），E'=（D，E），E'=（A，B，C，D，E）

（E，F）

但我认为我错了

有人能帮助理解这个问题吗

谢谢

（为了可读性重新格式化）

我的理解是，如果我应用3NF，它表示一个模式 如果所有非素数属性不可传递地依赖于任何 关键候选人，结果应为：

• E1={A，B，C，E，F}
• E2={B，D}
• E3={A，B，C，D，F}
• E4={D，E}
• E5={A，B，C，D，E}
• E6={E，F}

3NF表示a）关系在2NF中，b）每个非素数属性直接依赖于（即，不是传递依赖于）每个候选键

反过来，2NF意味着a）关系在1NF中，b）每个非素数属性依赖于每个候选密钥的整体，而不仅仅依赖于任何候选密钥的一部分

给定{ABC}是一个候选键，并且给定{AB->D}，您可以看到D依赖于候选键的一部分。所以

• E0={A，B，C，D，E，F}

不在2NF中。通过将依赖属性移动到新关系，并将确定它的属性复制到同一关系，可以解决此问题

• R0={ABCDEF}我们开始的这个关系，不在2NF中，消失了，要用

• R1={ABCEF}

• R2={ABD}

---

您想从这里继续吗？

当谈到正确的规范化时，理解形式化定义是无可替代的。如果你还在努力建立这种理解，有一个可爱的小助记符，人们用它来帮助记住3NF的本质，并判断他们看到的桌子是否是3NF

“钥匙，整个钥匙，除了钥匙什么都没有，所以帮帮我。”

如何应用它？关系的每个属性都必须依赖于键。这必须取决于整个钥匙。我不能依赖任何不是关键的东西。当您查看您的示例时，显然存在问题，您需要规范化。您需要达到这样一个点，即每个违反3NF的非键列都超出了原始关系。每个非键列D、E和F都违反3NF

请注意，您的附加函数依赖项涵盖了原始关系中的所有非键列。这些附加的功能依赖项中的每一项都将产生一种关系：

{abD}-这解决了属性D的3NF问题
{cdE}-这解决了属性E的3NF问题
{EF}-这解决了属性F的3NF问题

你原来的亲戚还有什么要隐瞒的？除了候选密钥外，没有其他内容：

---

{abc}

这是家庭作业吗？这是一个标签。”…3NF表示，如果所有非素数属性都不可传递地依赖于任何关键候选项，那么模式就是3NF。3NF表示a）关系是2NF，b）每个非素数属性都是直接依赖的（即，不是可传递依赖的）在每一个候选键上。谢谢Catcall。我想如果我有随身携带，我必须写：R3（ABCDF），R4（CDE），R5（ABCDE），R6（EF）…我是对的吗？这意味着我开始使用的关系现在是规范化的。关键是检查R是否在2NF中，然后开始使用规范化。正确吗？@user962800：你是如何推导出“R3（ABCDF）”的非常感谢你的回答。我想我已经掌握了要点。你认为我能找到关于规范化的练习吗？谢谢。没问题！如果你喜欢的话，请随意投票。我相信有很多正常化练习。试着在谷歌上搜索数据库+规范化+练习。“关键点，整个关键点…”助记符基本上是不准确的。规范化同样涉及所有候选键，而不是每个表中的任何一个键。所以说“关键”是不够的，好像只有一个关键需要考虑。这就是为什么我不希望在没有进一步澄清的情况下看到特定的助记符重复出现。你会注意到，我的回答是以“当涉及到正确的规范化时，没有什么可以替代理解正式定义…”。根据我的经验，许多程序员在通过数学理论时有一点困难，因此他们很难识别任何给定的表是否为3NF。显然，记忆法是一种简化。既然上面写的是“关键”，那么在候选键与主键之间的问题上，助记符是否松散、不正确或沉默将由English.StackExchange.com来决定。