考虑一个描述某所大学的辅导室预订的关系。每个学院分配一个人来处理该学院所有教程课程的预订。该人的电子邮件地址将作为联系人提供给大学的预订系统。 预订（b_date，b_starttime，b_endtime，unit_code，contact_person，room_no，tutor_id）。
锻炼：如果适用以下业务规则，则确定关系的候选键和主键：
1）辅导课的时间可以为1小时或2小时。
2）导师只能在给定的单元中教授一个辅导课。
3）没有并行的教程课程。
我的回答：候选键1是（tutor_id，d_date）。我的建议键可以使每个元组唯一，但没有约束，可以防止用户错误输入，如下所示：
tutor_id | d_date | b_starttime | b_endtime | unit_code |
AAAA |周一|下午6点|晚上8点| FIT1111 |
BBBB |周一|下午6点|晚上7点| FIT1111 |
OR
tutor_id | d_date | b_starttime | b_endtime | unit_code |
AAAA |周一|下午6点|晚上8点| FIT1111 |
BBBB |周一|晚上7点|晚上8点| FIT1111 |
因此，我的钥匙不符合3号业务规则。然后，我向候选键添加了另外2个属性（tutor_id，d_date，b_starttime和b_endtime）。
我的问题是，当我们选择候选键时，除了保证每个元组的唯一性之外，是否还需要防止用户输入错误而可能破坏业务规则？如果是，那么例如当我们将4个属性（A，B，C，D）设置为主键时，DBMS是否阻止用户执行上表中的错误输入操作？
谢谢。
答案 0 :(得分：1)
我的问题是，当我们选择候选键时，除了保证每个元组的唯一性外，是否还需要防止用户输入错误而破坏业务规则？
是的，我们应该声明足够的约束以禁止所有无效状态。是的，声明一个或所有CK（候选密钥）并不一定足够。 （为什么会这样？您认为您有理由这么做吗？）
CK不仅说明了一组属性的唯一性。它还指出该集合的任何适当子集的非唯一性。
CK用于规范化到更高的NF（正常形式），从而摆脱了某些问题约束，即一个表必须始终是其他表的连接，而这些表可能已经替代了。它将删除当前表并介绍这些表及其CK约束，有时还包括FK（外键）约束，这些子行必须在其他地方显示为CK。但是还有其他约束可以保留，应该声明。
如果是，例如，当我们将4个属性（A，B，C，D）设置为主键时，DBMS是否阻止用户执行上表中的错误输入操作？
您提到特定的CK约束不会阻止某些无效状态。但是，由于您应该始终声明所有CK，因此在开始查找不会阻止的无效状态之前，应该找到它们 all 。同样，“然后，我向候选密钥添加2个更多的属性”是没有意义的，因为1.这不是我们找到CK的方式，并且2. CK加其他属性不能成为CK。
（阅读谷歌搜索“ stackexchange homework”的热门歌曲并采取行动，并在教科书中找到CK之后发布一个新问题来展示您的工作。）