关系数据库：我们什么时候需要添加更多实体？

Question

我们今天讨论了与 W3 讲座案例研究有关的讨论，讨论每种情况我们需要多少个实体。我有一些困惑如下：

案例 1) 一名员工被分配为团队成员。超过 5 名成员的团队将有一名团队负责人。小组成员选举小组组长。列出您可以在上述陈述中识别的实体？在这种情况下，如果我们不为上述要求创建 2 个实体，我们需要为每个员工添加另外两个属性，这可能会导致以后出现异常问题。因此，我们需要有如下 2 个实体：

EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK teamId&employeeId) -> 2 个实体

案例 2) 公司还引入了指导计划，新员工将与在公司工作时间较长的人配对。”您需要多少个实体来为指导计划建模？

Lecturer 的答案是 1。这样一来，我们必须为每个 Employee 再添加 2 个属性，mentorRole（Mentor 或 Mentee）和 pairNo（以区分不同的配对并知道谁指导谁），不是吗？ ?

我的问题是为什么我们不能创建一个名为 MENTORING 的新实体，它类似于 Q1 中的 TEAM？为什么我们只能在多对多关系的情况下这样做？

EMPLOYEE (PK 是employeeId) (0-M)----------------(0-1) TEAM (PK 是pairNo&employeeId) -> 2 个实体

提前谢谢你

Answer 1

首先，关于术语：我使用实体来表示个人、事物或事件。你和我是两个不同的实体，但由于我们都是 StackOverflow 的成员，所以我们是同一个实体 set 的一部分。 ER模型中实体集与值集对比，而关系模型则没有这种区别。

1. 虽然您对实体集的数量是正确的，但您的实现存在一些问题。 TEAM的PK不应该是teamId, employeeId，应该只有teamId。 EMPLOYEE 表应该有一个teamId 外键（不是PK 的一部分）来指示团队成员身份。 TEAM 表中的employeeId 列可用于表示团队负责人，并且依赖于teamId（因为每个团队最多只能有一个负责人）。

   只有一个实体集，我们可能会将团队成员和领导力表示为：

   EMPLOYEE(employeeId PK, team, leader)

   其中team 是团队成员必须相同的团队名称或编号，leader 是一个真/假列，用于指示该行中的员工是否是其团队的领导者。这个模型的一个问题是我们不能确保一个团队只有一个领导者。

2. 同样，实施存在一些问题。除了所涉及的员工之外，我认为没有必要识别配对，并且拥有mentorRole（导师或学员）表示将为导师和学员记录关联。这是多余的，并为不一致创造了机会。如果目标是表示一对一的关系，还有更好的方法。我建议使用单独的表 MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ)（或者可能是 EMPLOYEE 表中唯一但可为空的 mentorEmployeeId，具体取决于您的 DBMS 如何处理唯一索引中的空值）。

这两种情况的区别在于，团队可以有任意数量的成员和一个领导，通过将团队与员工分开识别来最有效地实施，而指导是一种更简单的关联，由两个人中的任何一个人充分识别涉及（前提是您始终使用与标识符相同的角色）。您可以为指导创建一个单独的实体集，与所涉及的员工建立关系 - 它可能看起来像我的 MENTORING 表，但有一个额外的代理键作为 PK，但不需要额外的标识符。

如果这是多对多关系，为什么我们只能这样做？

什么意思？您的示例不包含多对多关系，我们不会为多对多关系创建额外的实体集。如果您正在考虑所谓的“桥”表，那么您就会混淆一些概念。实体集不是表。实体集是一组值，表表示一组或多组值的关系。在 Chen 的原始方法中，所有 关系在单独的表中表示。只是我们已经习惯了将简单的一对一和一对多关系反规范化到与实体属性相同的表中，但对于多对多二元关系或三元和一般关系较高。