我们今天在W3演讲案例研究中进行了讨论，讨论每种情况下我们需要多少个实体。我有些困惑，如下所示：
情况1）一名员工被分配为团队成员。成员超过5人的团队将有一个团队负责人。团队成员选举团队负责人。列出您可以在上述声明中识别的实体？在这种情况下，如果我们没有为上述要求创建2个实体，则需要为每个员工再添加两个属性，这可能会在以后导致异常问题。因此，我们需要具有以下两个实体：
员工（PK是employeeId）（0-M）----------------（0-1）团队（PK teamId＆employeeId）-> 2个实体
案例2）公司还引入了一个指导计划，新员工将与公司里已有较长时间的人结对。“您需要多少个实体来建模指导计划？
讲师的答案是1。因此，我们必须为每个Employee添加更多2个属性，mentorRole（Mentor或Mentee）和pairNo（以区分不同的对并知道谁指导谁），不是吗？ ？
我的问题是，为什么我们不能创建一个名为MENTORING的新实体，该实体与Q1中的TEAM相似？为什么只有在这种多对多关系的情况下才能做到这一点？
员工（PK是employeeId）（0-M）----------------（0-1）团队（PK是pairNo＆employeeId）-> 2个实体
提前谢谢
答案 0 :(得分：0)
首先，关于术语：我用实体来表示个人，事物或事件。您和我是两个不同的实体，但是由于我们都是StackOverflow的成员，因此我们属于同一实体 set 。 ER模型中的实体集与值集形成对比，而关系模型则没有这种区别。
虽然您对实体集的数量是正确的，但是您的实现存在一些问题。 TEAM的PK不应为teamId, employeeId，而应仅为teamId。 EMPLOYEE表应具有teamId外键（不是PK的一部分）以指示团队成员身份。 TEAM表中的employeeId列可用来代表团队负责人，并取决于teamId（因为每个团队最多只能有一个领导者）。
仅设置一个实体，我们可能将团队成员和领导权表示为：
EMPLOYEE(employeeId PK, team, leader)
其中team是一些团队名称或团队成员必须相同的编号，而leader是一个true / false列，以指示该行中的员工是否是其领导者/她的团队。这种模式的问题是我们不能确保团队只有一位领导者。
同样，实现存在一些问题。我认为没有必要确定除所涉及的员工之外的员工对，并且拥有mentorRole（指导者或受指导者）表示将记录指导者和受指导者的关联。这是多余的，并为不一致创造了机会。如果目标是代表一对一关系，则有更好的方法。我建议使用一个单独的表MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ)（或者在EMPLOYEE表中可能是一个唯一但可为空的mentorEmployeeId，这取决于您的DBMS处理唯一索引中的空值的方式。）
这两种情况之间的区别在于，团队可以有任意数量的成员和一个领导者，这是通过将团队与员工分开来确定的，而最有效地实施，而导师制是一个更简单的关联，可以由两个人中的任何一个充分识别参与（前提是您始终使用与标识符相同的角色）。您可以创建一个单独的实体集以进行指导，并与所涉及的员工建立关系-它看起来像我的MENTORING表，但带有一个额外的替代键PK，但是不需要额外的标识符。
为什么只有这种多对多关系我们才能做到？
什么意思？您的示例不包含多对多关系，我们也没有为多对多关系创建其他实体集。如果您正在考虑所谓的“桥接”表，那么您会混淆了一些概念。实体集不是表格。实体集是一组值，一个表表示一个或多个值集之间的关系。在Chen的原始方法中，所有关系在单独的表中表示。只是我们已经习惯于将简单的一对一和一对多关系反规范化为与实体属性相同的表，但是对于多对多的二进制关系或三元和一般而言，人际关系较高。