我们今天讨论了与 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 is employeeId) (0-M)----------------(0-1) TEAM (PK is pairNo&employeeId) -> 2 个实体
先感谢您
首先，关于术语：我使用实体来表示个人、事物或事件。你和我是两个不同的实体，但由于我们都是 StackOverflow 的成员，我们属于同一个实体集。实体集与ER模型中的值集对比，而关系模型没有这种区别。
虽然您对实体集的数量是正确的，但您的实现存在一些问题。TEAM的PK不应该是teamId, employeeId，应该只是teamId。EMPLOYEE 表应该有一个teamId外键（不是 PK 的一部分）来指示团队成员身份。employeeIdTEAM 表中的列可用于表示团队负责人，并依赖于teamId（因为每个团队最多只能有一个负责人）。
如果只有一个实体集，我们可能会将团队成员和领导力表示为：
EMPLOYEE(employeeId PK, team, leader)
哪里team是团队成员必须相同的团队名称或编号，leader是一个真/假列，表示该行中的员工是否是他/她的团队的领导者。这个模型的一个问题是我们不能确保一个团队只有一个领导者。
同样，实施存在一些问题。除了所涉及的员工之外，我认为没有必要确定配对，并且拥有mentorRole（导师或受指导者）表示将记录导师和受指导者的关联。这是多余的，并创造了不一致的机会。如果目标是表示一对一的关系，还有更好的方法。我建议使用单独的表MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ)（或者可能是mentorEmployeeIdEMPLOYEE 表中唯一但可以为空的表，具体取决于您的 DBMS 如何处理唯一索引中的空值）。
这两种情况的区别在于团队可以有任意数量的成员和一个领导者，通过将团队与员工分开识别来最有效地实施，而导师制是一种更简单的关联，由所涉及的两个人中的任何一个充分识别（提供您始终使用与标识符相同的角色）。您可以为指导创建一个单独的实体集，并与所涉及的员工建立关系 - 它可能看起来像我的 MENTORING 表，但有一个额外的代理键作为 PK，但不需要额外的标识符。
为什么我们只能在这是多对多关系的情况下才能做到这一点？
你的意思是？您的示例不包含多对多关系，我们不会为多对多关系创建额外的实体集。如果您正在考虑所谓的“桥接”表，那么您就会混淆一些概念。实体集不是表。实体集是一组值，表表示一组或多组值的关系。在 Chen 的原始方法中，所有关系都在单独的表中表示。只是我们已经习惯于将简单的一对一和一对多关系非规范化到与实体属性相同的表中，但我们不能对多对多二元关系或三元关系做同样的事情一般较高的关系。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句