例如，让我们考虑以下关系：
R（ A，B，C ，D，E，F）
其中粗体表示它是主键属性
与
F = {AB-> DE，D-> E}
现在，这看起来是第一种正常形式。它不能在第三范式，因为我有一个传递依赖，它不能是第二种形式，因为并非所有非关键属性都依赖于整个主键。
所以我的问题是：
我不知道如何制作F和C.我没有任何关于它们的功能依赖信息！ F不依赖于什么？如果是这种情况，我想不出任何解决办法让R进入第二范式而不把它拿出来！
C怎么样？ C还存在不在功能依赖性列表中被引用的问题。该怎么办？
我尝试让R进入第二范式会是这样的：
R（的 A，B 下，d）
R'（ D ，E）
但如前所述，我不知道如何处理C和F.它们是多余的，所以我只是将它们拿出来，上面的尝试就是我要做的就是把它变成第二种形式（和第3个！）？
由于
答案 0 :(得分：3)
鉴于R的定义{A，B，C}是主键，那么本质上存在功能依赖：
这就是说A，B和C的值固有地决定或控制D，E和F的值以及它们决定自己价值的微不足道的事实。
你有一些额外的依赖关系，由集合F标识（它与属性F不同 - 表示法不是非常合适，并且可能导致混淆 * ）：
正确诊断时，系统处于1NF（因为1NF实际上意味着“它是一张桌子”）。由于传递依赖性，它不在2NF或3NF或BCNF等中，因为某些属性仅依赖于密钥的一部分。
你是对的，你将最终得到以下两个关系作为分解的一部分：
您还需要第三种关系：
通过这些，您可以使用连接重新创建原始关系R.关系集合{R 1 ，R 2 ，R 3 }是原始关系R的非损失分解。
* 如果识别辅助功能依赖关系集的F意图与属性F相同，那么该属性的定义就会有一些非常奇怪的东西。我需要查看关系R的样本数据，以便有机会知道如何解释它。
答案 1 :(得分：0)
F不依赖于什么？
不，您还没有在表单中获得有关它的任何显式信息
{something -> F}
对于C来说基本上也是如此。你应该通过应用阿姆斯特朗的公理来推断其他依赖关系。 （可能）
想想如何完成这个：
给定R（ A，B，C ，D，E，F）
[后来。 。 。我看到Jonathan Leffler已经打破了这个悬念，所以我将完成这个。]
{ ABC - ＆gt; DEF}（根据定义）因此，
{ ABC - ＆gt; F}（通过分解。这里是F和C进来的地方。这是你的第三个关系。）。
答案 2 :(得分：0)
我认为R的主键设置错误。如果F在功能上与任何无关，那么它必须是密钥的一部分
所以你有R（ ABCF DE）现在处于第一范式（F = {AB-＆gt; DE，D-> E}）现在你可以把它改成第二种正常形式。 DE并不依赖于整个键（部分依赖），因此您将其置于另一种关系中以获得第二种正常形式：
R（ ABCF ）F = {}
R1（ #AB DE）F = {AB-＆gt; DE}
现在这个关系没有任何传递依赖，因此它已经处于第三范式。