Database 具有3个以上属性的主键

考虑一个关系，该关系描述了大学中的补习室预订。每个教员指定一人处理该教员所有补习班的预订。此人的电子邮件地址作为联系人发送给大学的预订系统。 预订（预订日期、开始时间、结束时间、单位代码、联系人、房间号、导师id）

练习：如果以下业务规则适用，则确定关系的候选密钥和主键：

1） 补习班可以是1小时或2小时

2） 一个导师只能在一个给定的单元中教授一门辅导课

3） 没有平行的辅导课程

我的答案是：1的候选人关键是（导师id，d_日期）。My suggestion键可以使每个元组都是唯一的，但没有任何约束可以防止用户输入错误，如下所示：

---

导师id d日期b开始时间b结束时间单位代码|

AAAA |周一|下午6点|晚上8点| FIT1111|

BBBB |周一|下午6点|晚上7点|菲特1111|

---

或

---

导师id d日期b开始时间b结束时间单位代码|

AAAA |周一|下午6点|晚上8点| FIT1111|

BBBB |周一|晚上7点|晚上8点|菲特1111|

---

因此，我的密钥不符合第3条业务规则。然后，我向候选键添加了另外两个属性（导师id、d_日期、b_开始时间、b_结束时间）

我的问题是，当我们选择候选密钥时，除了保证每个元组的唯一性外，我们是否需要防止用户输入可能会破坏业务规则的错误信息？如果是，例如，当我们将4个属性（A、B、C、D）设置为主键时，DBMS是否会阻止用户执行上表中的错误输入操作

谢谢

我的问题是，当我们选择候选密钥时，除了保证每个元组的唯一性外，我们是否需要防止用户输入可能会破坏业务规则的错误信息

是的，我们应该声明足够的约束来禁止所有无效状态。是的，声明一个甚至所有CKs（候选密钥）并不一定足够。（为什么会这样？你认为你有理由这样做吗？）

CK不仅仅表示一组属性的唯一性。它还声明了该集合的任何适当子集的非唯一性

CKs用于规范化到更高级别的NFs（普通表单），这消除了某些有问题的约束，即一个表必须始终是您可以使用的其他表的连接。它会删除当前表并引入这些表及其CK约束，有时还会引入FK（外键）约束，子视图必须在其他地方显示为CK。但还有其他约束条件可以适用，应该声明

如果是，例如，当我们将4个属性（A、B、C、D）设置为主键时，DBMS是否会阻止用户执行上表中的错误输入操作

您提到特定的CK约束不会阻止某些无效状态。但由于您应该始终声明所有CK，因此在开始查找未被阻止的无效状态之前，您应该找到所有CK。此外，“然后，我向候选键添加了2个属性”也没有意义，因为1。这不是我们找到CKs和2的方式。CK加上其他属性不能是CK

---

（在谷歌上搜索“stackexchange家庭作业”并发布一个新的问题，展示你在课本中找到CKs后的工作。）

Hi。你的主要问题是什么。但很难讨论这个例子，因为您不够清楚。在谷歌搜索“stackexchange家庭作业”时，阅读并按点击进行操作。CKs由FDs确定。您的FD和所有CKs是什么？为什么？还有什么进一步的限制？为什么？按照教科书中的定义和算法展示你的作品。PS在代码块中格式化表格。请参阅编辑帮助&在发布之前，请始终查看文章的格式化版本。请不要以使已发布的合理答案无效的方式编辑问题。请每个帖子只问一个问题。