Database 关系规范化问题 让我们考虑一下下面的关系：

R（A、B、C、D、E、F）

其中，粗体表示它是主键属性

与

F={AB->DE，D->E}

现在，这看起来是第一个标准形式。它不可能在第三个标准形式上，因为我有一个可传递的依赖项，也不可能在第二个形式上，因为不是所有的非键属性都依赖于整个主键

因此，我的问题是：

我不知道如何理解F和C。我没有关于它们的任何函数依赖信息！F不依赖于任何东西？如果是这样的话，我想不出任何解决办法，不把R去掉，就把R变成第二个正规形式

那么C呢？C还面临着不在函数依赖项列表中引用的问题。怎么办

我试图将R转换为第二个标准形式，类似于：

R（A，B，D）

R'（D，E）

但是如前所述，我不知道如何处理C和F。它们是多余的吗？所以我只是简单地把它们取出来，上面的尝试就是我要做的全部，以使它们进入第二种形式（和第三种形式！）

谢谢

F不依赖于任何东西

不，你只是没有在表格中得到任何明确的信息

{something -> F}

本质上，C也是如此。我们希望通过应用阿姆斯特朗的公理来推断其他依赖关系。（可能吧。）

思考如何完成此任务：

给定R（A，B，C，D，E，F）

• {ABC->？}

[稍后……我看到乔纳森·莱夫勒打破了悬念，所以我就把这件事做完。]

{ABC->DEF}（根据定义）因此

---

{ABC->F}（通过分解。这里是F和C的位置。这是你的第三个关系。）。

我认为R的主键设置错误。如果F在功能上与任何东西都不相关，那么它必须是键的一部分

所以你有R（ABCFDE），它现在是第一个范式（F={AB->DE，D->E}），现在你可以把它改成第二个范式。DE不依赖于整个键（部分依赖），因此可以将其放在另一个关系中，以获得第二个标准形式：

R（ABCF）F={}

R1（#ABDE）F={AB->DE}

---

现在这个关系没有任何可传递的依赖关系，所以它已经是第三范式了。

给定R的定义，{A，B，C}是主键，那么就有一个固有的函数依赖关系：

• ABC→ ABCDEF

也就是说，A、B和C的值内在地决定或控制着D、E和F的值，以及它们决定自己的值这一微不足道的事实

您还有一些额外的依赖项，由集合F标识（与属性F不同-表示法不太恰当，可能会引起混淆*）：

• AB→ 德
• D→ E

正如您正确诊断的那样，系统处于1NF中（因为1NF实际上意味着“它是一个表”）。它不在2NF、3NF或BCNF等中，因为它具有可传递依赖性，并且因为某些属性仅依赖于部分键

您是对的，在分解过程中，您将得到以下两个关系：

• R1（D，E）
• R2（A，B，D）

您还需要第三个关系：

• R3（A，B，C，F）

通过这些，您可以使用联接重新创建原始关系R。关系集{R1，R2，R3}是原始关系R的无损失分解

---

---

*如果识别辅助函数依赖集的F与属性F相同，那么该属性的定义就有点奇怪。我需要查看关系R的样本数据，以便有机会知道如何解释它。

我只得到了上面显示的信息。我没有更多的信息。一点也不，我一点都不知道。我不明白为什么只有A、B、D和E上有FPs，我可以推断出C和FI的一些东西，我会说ABC和AB一样，但它可能不再是一个主要（甚至是候选）键了。你运用了阿姆斯特朗的哪一条公理得出了这个结论？坐下来一会儿。（意思是“思考，不要打字”）当你看到这个：

{ABC->？}

，问问自己“ABC决定了什么？”F是由ABC决定的——因为ABC是R的主键，主键的定义意味着ABC决定了ABCDEF。