数据库 - 候选键和FD

现在该问题要求我找出函数依赖关系和候选键。数据库 - 候选键和FD

当我找出FD和Candidate Keys时，我有点困惑。根据我的理解，如果“给定X的一个值，我是否知道Y的一个值”，则可以找到FD？因此，例如，如果我获得studentID，我会知道studentName吗？是。这很简单。

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

现在我有一个场景：

的就业安置机构正在建立一个数据库，记录预约面试的细节。该机构聘用'协助'候选人'（CND）找工作的'职位经理' （PLMs）。经理采访每个职位都会采访很多候选人。然而，一名候选人被分配到一名职位经理。这意味着对于候选人每次约会，它将始终与同一位置经理。任何给定的任命是在一名候选人和他们分配的安置经理之间。

该机构的初步方案是：任命（聘任，PLM＃，PLMname，CND＃，CNDname，CNDaddress，工作）

聘任为预约日期和时间。 PLM＃& PLMname是位置管理器的ID和名称，CND＃是候选人的ID。 CNDname是候选人的姓名。 CNDaddress是候选人的联系地址。工作是在面试中讨论的工作。

所以，对于上述方案的候选键可能是：

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

我在这里的问题是，我不知道是否将它写出来的上述或有仅1个候选键

文件描述符：

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

个

假设任命期间 1工作进行了讨论候选人只能有每一天

1个任命只想得到我的FD我正常化之前检查。

来源

2012-10-04 bigubosu

该FD CND ⟶ Job是可疑的，特别是给予CND, Appt ⟶ Job;这意味着CND只能申请或讨论一份工作。

FD CND ⟶ Appt是可疑的;这意味着即使有50个PLM，也没有两个可以同时进行预约。

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

来源

2012-10-05 06:01:57

数据库 - 候选键和FD

回答

相关问题