0

现在问题要求我找出功能依赖关系和候选键。

当我弄清楚 FD 和候选键时，我有点困惑。根据我的理解，如果“给定 X 的一个值我知道 Y 的一个值”，您可以找到 FD？例如，如果给我一个学生ID，我会知道学生姓名吗？是的。这很简单。

现在对于候选键，我认为它们是可能是主键但必须用作主键的键。

现在我有一个场景：

一家职业介绍所正在创建一个数据库来记录面试预约的详细信息。该机构聘用“安置经理”（PLM）协助“候选人”（CND）找工作。每个安置经理都会面试许多候选人。但是，候选人被分配给一位安置经理。这意味着对于候选人的每次任命，它总是与同一个安置经理。任何给定的任命都是在一名候选人和他们指定的安置经理之间进行的。

该机构的初始模式是：Appointment(Appt, PLM#, PLMname, CND#, CNDname, CNDaddress, Job)

Appt 是预约日期和时间。PLM# & PLMname 是安置经理的 ID 和姓名，CND# 是候选人的 ID。CNDname 是候选人的姓名。CNDaddress 是候选人的联系地址。工作是面试中讨论的工作。

因此，对于上述情况，候选键可能是：

{PLM# Appt} and {CND#, Appt}

我的问题是我不确定是像上面那样写出来还是只有 1 个候选键

{PLM#, CND#, Appt}

FD：

PLM# -> PLMName
CND# -> CNDName
CND# -> CNDAddress
CND#, PLM# -> Appt
CND#, Appt -> Job
CND# -> Appt
CND# -> Job
CND# -> PLM#

假设 1 个职位在任命期间讨论 候选人每天只能有 1 个预约

只是想在我正常化之前检查我的 FD。

4

1 回答 1

1

FDCND ⟶ Job是可疑的，尤其是考虑到CND, Appt ⟶ Job; 这意味着 CND 永远只能申请或讨论一项工作。

FDCND ⟶ Appt是可疑的；这意味着即使有 50 个 PLM，也没有两个可以同时预约。

关于key的问题：两列key中的每一个都是候选key，是不可约的。建议的三列键不是不可约的（因为它可以简化为两个两列候选键中的任何一个）。因此，三列键是（严格）超级键而不是候选键。

于 2012-10-05T06:01:57.997 回答