我正在攻读我的数据库考试，我不确定一个问题如下：
给定关系R = {A，B，C，D，E，F，G，H，I}和函数依赖集
F = {AB - ＆gt; C，
A - ＆gt; DE，
C - ＆gt; AB，
B - ＆gt; FGH，
D - ＆gt; IJ，
D - ＆gt; 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 - ＆gt; C和C - ＆gt; AB，这是一个循环依赖。我想到了两种可能性：
但很容易看出AB必须是唯一的，C也必须是唯一的。
我们只使用AB - ＆gt; C.我们可以拥有以下协会：
11 - ＆gt; 1（A = 1，B = 1，C = 1）
12 - ＆gt; 1
但是，如果我们重新插入规则C - ＆gt; AB，我们发现：
1 - ＆gt; 11
1 - ＆gt; 12
无法容纳。
所以C必须是独一无二的。
如果我们只考虑C - >＆gt; AB，然后重新插入规则AB - ＆gt;下进行。
我开始认为这是一个技巧，这个关系的真正主键是ABC，以确保AB和C组合的唯一性。我们将有以下规则：
F'= {
ABC - ＆gt; DEFGH
D - ＆gt; IJ
D - ＆gt; CBE
}
这是对的吗？那另一个循环依赖，即C - > D（第一规则），D - > C（第三规则）和C - > D（回到第一条规则）？我根本不关心它吗？
如果我不关心它（假设主键是ABC），那么很明显这个表不在3NF，因为ABC确定D（这里是非主要属性），D确定IJ ，两个非主要属性。但它似乎在2NF，因为没有非主要属性（D，E，F，G，H，I，J）可以使用候选键的属性子集（这里是ABC）获得。
当然，我可以认为主键是A，C或D并且分开AB - ＆gt; C和C - ＆gt; AB在两个独立的关系中，但我不认为加入这两个表将始终遵守规则AB - ＆gt; C和C - ＆gt; AB。例如，如果有人在其中一个表中插入新行，则连接可能会引入无效行。
我在想太多？我的方向是错误的吗？
感谢您的帮助：）
答案 0 :(得分：1)
AB -> C
A -> DE
C -> AB
B -> FGH
D -> IJ
D -> CBE
我会假设你的关系中的FD正好是F传递闭包中的那些（你对你的关系有什么实际的F？）
{}只能轻易确定。
{A}确定DE，它确定决定FGH的IJCB。 CK。
{B}确定FGH。不是CK
{C}确定AB。 CK。
{D}确定IJCBE。 CK。
其他单身套装只是简单地确定。
A，C和D的正确超集不是CK 其他合适的超集是B，E，F，G，H，I，J，它们不能确定A，C或D.不是CK。
这说明了属性的所有子集 所以CK是{A}，{B}和{D}。
让我烦恼的是AB - ＆gt; C和C - ＆gt; AB，这是一个循环依赖。
为什么要这个错误？只需遵循您给出的规则即可。回顾CK的定义以及如何从FD中确定CK。避免使用非技术术语。
这种关系的真正主键
“主键”在规范化中不是一个有用的概念。 （我无法理解后面的内容。）
此表格不在3NF中
我没有看到你的推理中使用了3NF的任何定义。您似乎使用BCNF的定义，但不正确。
假设主键是ABC
候选键（ABC在这里）
下定决心。是否有一个候选键{A，B，C}或三个候选键{A}，{B}和{C}？这是两种不同的情况。
它似乎在2NF中，因为使用候选键的属性子集不能获得非素数属性
你的意思是没有非素数属性在功能上依赖于任何候选键的适当属性子集。你错误引用，然后滥用你所引用的内容，好像它意味着你应该引用的内容。
查看正常表格的定义及其所依赖的定义。