当x-> y和z-> y时,FD(函数依赖)是否完全为fd,其中z不是x的子集?

时间:2016-03-11 14:47:06

标签: rdbms database-normalization functional-dependencies

我已经看到很多关于完全功能依赖的例子,但是他们用来说:

x-> y使得y不应由x的任何适当子集确定,x必须是关键。

但是,如果y是由x的正确子集或子集以外的属性确定的话。

假设我有一个学生表,其中包含rollno(主键),姓名,电话号码唯一不为空,电子邮件唯一不为空。

由于rollno是主键,因此将其设为x并将名称设为y。

现在x-> y,但是电话或电子邮件也确定y(名称)不是x的子集。这仍然被称为完全功能依赖吗?

如果是,我们应该检查y的决定因素,它们只是x的子集吗?

如果不是,我做错了什么?

2 个答案:

答案 0 :(得分:1)

  

x-> y使得y不应该由x的任何适当子集确定,x必须是关键。

你正在混淆"完全功能依赖的定义"定义" 2NF"。完全功能依赖的定义与超级键或候选键或主键无关。对于2NF的关系,如果 X是候选键 Y是非素数则Y不能由任何适当的X子集确定。

功能依赖性X - >当Y在功能上依赖于X的适当/较小子集时,Y是部分的。否则它是满的。

。其他事情并不重要。

超级键是一列或一组列,用于在功能上确定每一列。如果里面没有较小的超级密钥则它是候选密钥。当每个属性在功能上完全依赖于每个候选键时,关系是2NF。

。其他事情并不重要。

您可以选择一个候选键来调用主键。所以主键是候选键。否则,"主键"的概念;与功能依赖和规范化无关。

(在SQL primary key中表示与unique not null相同,即 superkey 。只有在其中没有较小的超级密钥时才是候选密钥。所以一组声明 primary key甚至可能不是主键。而在SQL中,您不能将{}声明为超级键。)

  

由于rollno是主键,因此将其设为x并将名称设为y。

主键是候选键,因此{rollno}确定每个属性,{rollno}的正确子集不会确定每个属性。所以{},{rollno}唯一合适的子集,不是超级密钥。 ({}是超级密钥,当表中最多只能有一行时。)但是{} - >仍然可能。 name。 (如果name列一次最多只包含一个名称,那就是这样。)然后{rollno} - > name会偏袒,因为其正确的子集{}会确定name

  

现在x-> y,但是电话或电子邮件也确定y(名称)不是x的子集。这仍然被称为完全功能依赖吗?

如果{rollno}没有合适的子集确定name,那么{rollno} - >完全name,否则部分。这就是定义所说的。别的都无所谓。但我们不知道 {rollno}的正确子集是否确定name,因为您没有说明{} - > name

如果{rollno},{phoneno}和{email}是候选键,{}无法确定name,那么name完全在功能上依赖于所有三个(因为它们中任何一个的正确子集都没有确定name)。

答案 1 :(得分:0)

你在说:

  

x-> y使得y不应由x的任何适当子集确定,x必须是关键。

但这混合了两个不同的概念,即“完全功能依赖”和“密钥”概念。

如果你不能删除左边部分的任何元素而不会失去确定正确部分的属性,那么函数依赖是 full 。因此,如果函数依赖项在左侧部分只有 一个属性(如rollno → name),则总是完成。

另一方面,(候选)键是一组属性,它们确定关系的所有属性,并且不能从中删除任何属性而不会失去作为键的属性(因此,它不是一个超级键)。

在您的示例中,有三个不同的键,rollnophoneemail,每个键都由一个属性组成。

当然,如果你知道属性集X是一个键,你可以写X → T,其中T是关系的所有属性,功能依赖已完成。