database - 具有 3 个以上属性的主键

Question

考虑一个描述大学辅导室预订的关系。每个教员都会指定一个人来处理该教员所有辅导班的预订。该人的电子邮件地址作为联系人提供给大学的预订系统。预订（b_date，b_starttime，b_endtime，unit_code，contact_person，room_no，tutor_id）。

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

1) 辅导课程可以是 1 小时或 2 小时。

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

3) 辅导班不设平行时段。

我的回答：候选键 1 是 (tutor_id, d_date)。我的建议键可以使每个元组唯一但是没有约束可以防止用户输入错误，如下所示：

AAAA | 星期一 | 下午 6 点 | 晚上 8 点 | FIT1111 |

BBBB | 星期一 | 下午 6 点 | 晚上 7 点 | FIT1111 |

或者

AAAA | 星期一 | 下午 6 点 | 晚上 8 点 | FIT1111 |

BBBB | 星期一 | 晚上 7 点 | 晚上 8 点 | FIT1111 |

因此，我的密钥不符合业务规则 3。然后，我向候选键（tutor_id、d_date、b_starttime、b_endtime）添加了另外 2 个属性。

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

谢谢。

score 1 · Accepted Answer

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

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

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

CK 用于对更高 NF（范式）的规范化，这消除了某些有问题的约束，即一个表必须始终是您可以拥有的其他表的连接。它会删除您当前的表并引入这些表及其 CK 约束和有时 FK（外键）约束，这些子行必须作为 CK 出现在其他地方。但是仍然有其他约束可以保持应该声明。

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

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

（阅读并在谷歌上搜索“stackexchange 作业”并发布一个新问题，显示您在教科书找到 CK 之后的工作。）

1 回答 1