Database 循环函数依赖关系的主键

我正在准备数据库考试，但有一个问题我不确定，如下所示：

给定关系R={A，B，C，D，E，F，G，H，I}和函数依赖集

F={AB->C

A->DE

C->AB

B->FGH

D->IJ

D->CBE }

这种关系是什么（正常）形式

首先，我知道我必须找到所有候选密钥。看右边，我看到R的每个属性都出现在右边，所以R的任何一个属性都是候选键这一点很重要。所以看左手的大小，只有A、B、C、D出现，所以这些属性中的一个或一些必须出现在候选关键点中

因此，使用A、C和D是可行的（细节跳过），但单独使用B是不行的。考虑使用两个属性ket是没有用的，因为任何不包含A、C或D的键都不会“把我们带回到”R。例如，BE允许我们找到B、E、F、G、H，但是我们不能继续，所以不能找到R的所有属性

此外，在其中使用A、C或D的任何组合都是无用的，因为它包含一个子集（单个属性），该子集是候选键（单个属性）的一部分。例如，AB可以简化为A，然后可以找到R的所有属性

让我讨厌的是AB->C和C->AB，这是一个循环依赖项。我想到了两种可能性：

C是主键，我们可以用它来找到A和B（C->AB）

AB可以简化为A（如上所述），用它我们可以找到C

但很容易看出AB必须是唯一的，C也必须是唯一的

让我们只使用AB->C。我们可以有以下关联：

11->1（A=1，B=1，C=1）

12->1

但是，如果我们重新插入规则C->AB，我们会发现：

1->11

1->12

这不能坚持

所以C必须是唯一的

同样的事情，如果我们只考虑C->AB，然后重新插入规则Ab>C.

我开始认为这是一个技巧，这种关系的真正主键是ABC，以确保AB和C组合的唯一性。然后我们将有以下规则：

F'={

ABC->DEFGH

D->IJ

D->CBE

}

是这样吗？另一个循环依赖关系呢，即C->D（第一条规则）、D->C（第三条规则）和C->D（返回第一条规则）？我真的不在乎吗

如果我不关心它（并且假设主键是ABC），那么很明显这个表不在3NF中，因为ABC确定D（这里是非素数属性），D确定IJ（两个非素数属性）。但它似乎是在2NF中，因为使用候选键的属性子集（这里是ABC）无法获得非素数属性（D，E，F，G，H，I，J）

当然，在两个独立的关系中，我可以考虑主键为A、C或D，并且拆分Ab>-C和C > AB，但我不认为加入这两个表总是尊重Ab>c和C>> Ab.例如，如果有人在表中插入一个新行，则连接可以引入损坏的行。 我想得太多了？我走错方向了吗

谢谢你的帮助：）

我假设你的关系中的FD就是F的传递闭包中的FD（你对你的关系中的F到底说了些什么？）

{}只决定微不足道的结果

{A} 确定DE，它确定IJCB，它确定FGH。CK.
{B} 确定FGH。不是CK。
{C} 确定AB.CK.
{D} 确定IJCBE。CK.
其他的单例集只决定了很小的问题

A、C和D的正确超集不是CKs。
其他适当的超集是B、E、F、G、H、I、J，它们不能确定A、C或D，而不是CKs

它包含所有属性子集。
所以CKs是{A}、{B}和{D}

让我讨厌的是AB->C和C->AB，这是一个循环依赖项

为什么这会困扰你？只要遵守你被赋予的规则。回顾CK的定义以及如何根据FDs确定CK。避免使用非技术术语

这种关系的真正主键

“主键”在规范化中不是一个有用的概念。（我不太明白接下来会发生什么。）

此表不在3NF中，因为

我看不出在你的推理中使用了3NF的任何定义。您似乎使用了BCNF的定义，但并不正确

假设主键是ABC
候选密钥（此处为ABC）

下定决心吧。是否有一个候选键{A，B，C}或三个候选键{A}，{B}和{C}？这是两种不同的情况

它似乎在2NF中，因为使用候选键的属性子集无法获得非素数属性[…]

您的意思是，没有非素数属性在功能上依赖于任何候选密钥的属性的适当子集。你错误地引用了，然后错误地引用了你所引用的，如果它意味着你应该引用的话

---

复习范式的定义和它们所依赖的定义。

我不缺课。

AB -> C
A -> DE
C -> AB
B -> FGH
D -> IJ
D -> CBE