Question

我对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，如果所有属性都显示模式为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'''''=（E，F）

但我认为我错了......

有人可以帮助理解这个问题吗？

由于

Answer 1

（为便于阅读而重新格式化）

我的理解是，如果我应用3NF表示架构   如果非素数的所有属性都不过度依赖于任何属性，则为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 ⁶ = {E，F}

<3> 3NF意味着a）关系在2NF中，并且b）每个非主要属性在每个候选键上直接依赖（即，不是传递依赖）。

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

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

E ⁰ = {A，B，C，D，E，F}

不在2NF。您可以通过将该依赖属性移动到新关系来修复它，并将确定它的属性复制到相同的关系。

R ⁰ = { ABC DEF}这个关系 - 我们开始使用，并且不在2NF中 - 消失了，被替换为< / p>
R ¹ = { ABC EF}
R ² = { AB D}

你想从这里继续吗？

Answer 2

当谈到正确化时，没有什么可以替代理解正式定义。如果你仍在努力建立这种理解，那么人们会用一个可爱的小助记来帮助记住3NF的本质，并判断他们正在看的桌子是否是3NF。

“钥匙，整个钥匙，只有钥匙，所以请帮助我Codd。”

你如何申请？关系的每个属性都必须依赖于密钥。它必须依赖于整个键。我不能依赖不是键的任何东西。当你看你的例子时，显然存在问题，你需要规范化。您需要达到违反3NF的每个非键列都超出原始关系的程度。每个非键列D，E和F都违反3NF。

请注意，您的其他功能依赖项涵盖原始关系中的所有非键列。这些额外的功能依赖性中的每一个都将导致关系：

{ A B D} - 这解决了属性D
的3NF { C D E} - 这解决了属性E
的3NF { E F} - 这解决了属性F

的3NF

你原来的关系还剩下什么？除候选键外没有其他内容：

{ A B C }

3NF普通形式

2 个答案: