Question

我有关系

Competitor(PID, EventName, Pname, TeamName, TeamCoach,EventDate, TeamRating).

我有我的FD

PID -> Pname
PID --> TeamName
TeamName --> TeamCoach
EventName --> EventDate
TeamName, EventName --> TeamRating

将形成我的关系

Competitor(_PID_, Pname, TeamName*)
Team(_TeamName_, TeamCoach)
Event(_EventName_, EventDate)
Rating(_TeamName_*, _EventName_*, TeamRating)
Entry(_PID_*, _EventName_*)

但是，由于我的候选键是{PID，EventName}，如果TeamName甚至不是键的一部分，团队关系如何在BCNF中？

Answer 1

在您的问题中记下的一组FD适用于单个关系模式。应用于给定关系模式的FD集合将确定密钥对于该关系模式的。

例如，您的5个FD对应于您开始使用的7列关系架构。这组FD允许确定7列关系模式的密钥确实是{PID EventName}。

但是，如果你将7列模式分成几部分，那么这会影响哪些FD仍然适用，以及哪些部分。

例如。假设你单挑

 Team(_TeamName_, TeamCoach)

并离开

 Competitor(PID, EventName, Pname, TeamName, EventDate, TeamRating).

对于每个单独的FD，您现在必须决定单个FD应用的两个新关系模式中的哪一个。

在手头的例子中：

 Team(_TeamName_, TeamCoach)
 TeamName --> TeamCoach

 Competitor(PID, EventName, Pname, TeamName, EventDate, TeamRating)
 PID -> Pname
 PID --> TeamName
 EventName --> EventDate
 TeamName, EventName --> TeamRating

您现在不仅有两个关系模式，，还有两个不同的FD组，分别适用于它们。 teamname-＆gt; teamcoach FD现在不再适用于（修订的）竞争对手关系模式，而只适用于Team模式。这使您可以得出结论，TeamName将是团队模式的键。

BTW并不总是能够保留所有您开始使用的FD。 FD的整体属性集（左侧和右侧）使得在模式拆分之后，不再存在包含所有这些属性的任何关系模式，这样FD就不再能够被表达，并且必须在生成的设计中恢复为不采用FD（/ key）形式的数据库约束。这就是“依赖性保护”的问题。

这是BCNF的关系吗？

1 个答案: