数据库 - 候选密钥和FD

Question

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

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

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

现在我有一个场景：

  

就业安置机构正在创建一个记录数据库   面试预约详情。该机构雇用“安置经理”   （PLMs）帮助“候选人”（CND）找工作。每个位置   经理采访了很多候选人但是候选人被分配到   一位安置经理。这意味着每个约会一个   候选人有，它将始终与同一个安置经理。任何   预约是在一名候选人和他们被指派的人之间   安置经理。

     

该机构的初始架构是：   预约（Appt，PLM＃，PLMname，CND＃，CNDname，CNDaddress，Job）

     

Appt是预约日期和时间。 PLM＃＆amp; PLMname是ID和名称   展示位置管理员，CND＃是候选人的ID。 CNDname是   候选人的名字。 CNDaddress是候选人的联系地址。   工作是面试中讨论的工作。

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

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

我的问题是我不确定是将其写出来还是只有一个候选键

{PLM#, CND#, Appt}

的FD：

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

假设 1在约会期间讨论工作 候选人每天只能预约一次

我想在规范化之前检查我的FD。

Answer 1

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

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

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