关系数据库：我们什么时候需要添加更多实体？
Relational Database: When do we need to add more entities?
我们今天讨论了与 W3 讲座案例研究相关的问题，即每种情况下我们需要多少个实体。我有一些困惑如下：
案例 1) 一名员工被分配为团队成员。超过 5 人的团队将有一名团队负责人。小组成员选举小组长。列出您可以在上述陈述中识别的实体？在这种情况下，如果我们不为上述要求创建 2 个实体，我们需要为每个员工添加两个属性，这可能会导致以后出现异常问题。因此，我们需要有如下两个实体：
EMPLOYEE（PK 是 employeeId）（0-M）----------------（0-1）TEAM（PK teamId&employeeId）-> 2 个实体
案例 2) 公司还引入了一个指导计划，新员工将与在公司工作时间较长的人配对。”您需要多少 entity/ies 来模拟指导计划？
Lecturer 的答案是 1。因此，我们必须为每个 Employee 添加 2 个属性，mentorRole（Mentor 或 Mentee）和 pairNo（区分不同的配对并知道谁指导谁），does'是吗？
我的问题是为什么我们不能创建一个名为 MENTORING 的新实体，它类似于 Q1 中的 TEAM？为什么我们只能在多对多关系中这样做？
EMPLOYEE（PK 是 employeeId）（0-M）----------------（0-1）TEAM（PK 是 pairNo&employeeId）-> 2 个实体
提前致谢
首先，关于术语：我使用实体来表示个体的人、事物或事件。你和我是两个截然不同的实体，但由于我们都是 Whosebug 的成员，所以我们属于同一个实体 set。实体集与ER模型中的值集对比，而关系模型没有这种区别。
虽然您对实体集的数量是正确的，但您的实施存在一些问题。 TEAM的PK不应该是teamId, employeeId，应该只是teamId。 EMPLOYEE table 应该有一个 teamId 外键（不是 PK 的一部分）来指示团队成员身份。 TEAM table 中的 employeeId 列可以用来表示团队领导者，它依赖于 teamId（因为每个团队最多只能有一个领导者）。
只有一个实体集，我们可能将团队成员和领导表示为：
EMPLOYEE(employeeId PK, team, leader)
其中 team 是一些团队名称或编号，团队成员必须相同，leader 是一个 true/false 列，用于指示该行中的员工是否his/her 队的队长。这个模型的一个问题是我们不能保证一个团队只有一个领导者。
同样，实施存在一些问题。我认为除了所涉及的员工之外，没有必要识别配对，并且拥有 mentorRole（导师或受训者）表示将记录导师和受训者的关联。这是多余的，并且会造成不一致的机会。如果目标是表示一对一关系，则有更好的方法。我建议在 EMPLOYEE table 中使用单独的 table MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ)（或者可能是唯一但可为空的 mentorEmployeeId，具体取决于您的 DBMS 如何处理唯一索引中的空值）。
这两种情况的区别在于，团队可以有任意数量的成员和一名领导者，这是通过将团队与员工分开来最有效地实现的，而导师制是一种更简单的关联，可以由其中任何一个充分识别涉及两个人（前提是您始终使用相同的角色作为标识符）。您可以创建一个单独的实体集用于指导，并与所涉及的员工建立关系 - 它可能看起来像我的 MENTORING table 但有一个额外的代理键作为 PK，但不需要额外的标识符。
And why we can only do that if this is a many-many relationship?
你是什么意思？您的示例不包含多对多关系，我们不会为多对多关系创建额外的实体集。如果您正在考虑所谓的 "bridge" table，那么您可能混淆了一些概念。实体集不是 table。实体集是一组值，table 表示一组或多组值之间的关系。在 Chen 的原始方法中，所有 关系在单独的 table 中表示。只是我们已经习惯于将简单的一对一和一对多关系反规范化为与实体属性相同的table，但我们不能对多对多做同样的事情二元关系或一般的三元和更高关系。
我们今天讨论了与 W3 讲座案例研究相关的问题，即每种情况下我们需要多少个实体。我有一些困惑如下：
案例 1) 一名员工被分配为团队成员。超过 5 人的团队将有一名团队负责人。小组成员选举小组长。列出您可以在上述陈述中识别的实体？在这种情况下，如果我们不为上述要求创建 2 个实体，我们需要为每个员工添加两个属性，这可能会导致以后出现异常问题。因此，我们需要有如下两个实体：
EMPLOYEE（PK 是 employeeId）（0-M）----------------（0-1）TEAM（PK teamId&employeeId）-> 2 个实体
案例 2) 公司还引入了一个指导计划，新员工将与在公司工作时间较长的人配对。”您需要多少 entity/ies 来模拟指导计划？
Lecturer 的答案是 1。因此，我们必须为每个 Employee 添加 2 个属性，mentorRole（Mentor 或 Mentee）和 pairNo（区分不同的配对并知道谁指导谁），does'是吗？
我的问题是为什么我们不能创建一个名为 MENTORING 的新实体，它类似于 Q1 中的 TEAM？为什么我们只能在多对多关系中这样做？
EMPLOYEE（PK 是 employeeId）（0-M）----------------（0-1）TEAM（PK 是 pairNo&employeeId）-> 2 个实体
提前致谢
首先，关于术语：我使用实体来表示个体的人、事物或事件。你和我是两个截然不同的实体，但由于我们都是 Whosebug 的成员，所以我们属于同一个实体 set。实体集与ER模型中的值集对比，而关系模型没有这种区别。
虽然您对实体集的数量是正确的，但您的实施存在一些问题。 TEAM的PK不应该是
teamId, employeeId，应该只是teamId。 EMPLOYEE table 应该有一个teamId外键（不是 PK 的一部分）来指示团队成员身份。 TEAM table 中的employeeId列可以用来表示团队领导者，它依赖于teamId（因为每个团队最多只能有一个领导者）。只有一个实体集，我们可能将团队成员和领导表示为：
EMPLOYEE(employeeId PK, team, leader)其中
team是一些团队名称或编号，团队成员必须相同，leader是一个 true/false 列，用于指示该行中的员工是否his/her 队的队长。这个模型的一个问题是我们不能保证一个团队只有一个领导者。同样，实施存在一些问题。我认为除了所涉及的员工之外，没有必要识别配对，并且拥有
mentorRole（导师或受训者）表示将记录导师和受训者的关联。这是多余的，并且会造成不一致的机会。如果目标是表示一对一关系，则有更好的方法。我建议在 EMPLOYEE table 中使用单独的 tableMENTORING(menteeEmployeeId PK, mentorEmployeeId UQ)（或者可能是唯一但可为空的mentorEmployeeId，具体取决于您的 DBMS 如何处理唯一索引中的空值）。
这两种情况的区别在于，团队可以有任意数量的成员和一名领导者，这是通过将团队与员工分开来最有效地实现的，而导师制是一种更简单的关联，可以由其中任何一个充分识别涉及两个人（前提是您始终使用相同的角色作为标识符）。您可以创建一个单独的实体集用于指导，并与所涉及的员工建立关系 - 它可能看起来像我的 MENTORING table 但有一个额外的代理键作为 PK，但不需要额外的标识符。
And why we can only do that if this is a many-many relationship?
你是什么意思？您的示例不包含多对多关系，我们不会为多对多关系创建额外的实体集。如果您正在考虑所谓的 "bridge" table，那么您可能混淆了一些概念。实体集不是 table。实体集是一组值，table 表示一组或多组值之间的关系。在 Chen 的原始方法中，所有 关系在单独的 table 中表示。只是我们已经习惯于将简单的一对一和一对多关系反规范化为与实体属性相同的table，但我们不能对多对多做同样的事情二元关系或一般的三元和更高关系。