我在建模实体关系图并陷入困境。我不确定我的考虑是否有误或ERD无法建模我想要的东西:

我有三个实体:员工,项目和角色。员工与项目之间存在联系:员工正在从事项目。但是,这名员工不仅从事此项目,还拥有作为角色的工作领域。但是,关系不是仅通过属性来描述吗?我该如何做类似“一名雇员以...身份从事此项目”的工作?当然,就像将其设计为数据库一样,我将roleId用作属性,但是ERD中的关系是什么?

最佳答案

如何为关系...实体...属性建模?
在设计数据库之前,我想将问题建模为实体关系图(使用Chen的表示法)。在此图中,我希望在员工与项目之间创建一个关系,而无需查看其后的关键和约束。
附录:我只知道两个通过属性扩展的实体之间的关系,但是如何为这个“三个实体-关系”建模?
这是完全可以理解的,而且是正确的。纸很便宜,数据库中的对象更改起来要贵一些。为需求建模并不断改进,直到您有信心再实施。
许多站点的问题在于,有许多木匠,尽管他们的想法很周到,但他们将每个问题都视为钉子,并提供了DDL,而不是所需的建模帮助。缺少的是上下文和含义,因此最终结果是使用固定的“键”但没有上下文和含义的严格实现。通过建模,我们可以对与我们相关的各个方面进行建模,而无需担心DDL中的外观。
另一种说法是,OMG回答了一个问题,我该如何建模“一名员工以...作为工作项目”?隔离中;我正在根据上下文回答您的整个问题。
在逻辑层面上,多对多关系是正确的。无需其他考虑的此类关系在物理级别上表示为关联表。但是,再次做出决定还为时过早,因为您仍在建模关系的上下文和含义。
...也不在SO Markdown表示法的范围内提供它。 IME,Oracle Designer之类的工具在创建实体后会生成此类图表
废话。建模的整个想法是,在编写一行代码,购买一个平台或必须实施DDL之前,就使用图表在纸上开发和改进某些东西。实际上,此评论仅是对许多产品提供的事实进行逆向工程。
建模,进度示例
使用对您有意义的任何符号来建模所需的内容。当然,标准符号被更普遍地理解。这是一个
ERD for you
(我不知道“SO降价标记”如何在提供事前建模建议方面造成限制)。我提供了可能发生的进展的示例。没有什么是“正确的”或“错误的”,都是纸屑。直到您确定哪些元素值得确认,然后才有可能继续发展。

  • 当然,起点是简单的多对多关系,根据标题,您已经了解了一些事情。试图建立一种名义上的三方关系模型是不正确的,这是一个模型错误:为了解决三角关系,您需要首先分别确定各方之间的离散关系;这意味着所有关系都是双向的。
  • 项目,员工和角色实体很明确,我们对此有所了解。在这里,我没有开发主要实体,因为它们“强大”,而不是您关注的重点。
  • 进度使用关系的示例属性,您可以使用自己的关系。 (我们的比利时同事已经用言语识别了这个问题,我只是在图片中提供了这个问题。)很多人在通常的实践中不做,应该做;我担心从上到下的真实建模,以便进行改进并得出正确的数据模型。清除所有垃圾,然后继续进行。
  • 我已经假设关系的属性证明一个实体是正确的,所以现在将它们绘制进去。在这里,我使用了椭圆形,您可以使用菱形或人字形来处理所有我关心的事情,只需使用一些符号就可以为您建模需要。
  • 在这里,我们可以清楚地看到:我们不希望Project::Employee::Role,因为那将允许Employee扮演任何角色;我们希望仅在先前已获得该角色批准的情况下才选择雇员。因此,Employee::Role正在变得“更强”。
  • 因此,Employee::Role是一个实体。粉红色的事物是该特定组合或Employee + Role的子级,而不是所有Employee或所有Role的子级。
  • 同样,我们不希望任何员工在任何可能的项目中担任任何可能的工作,我们希望他们仅在已批准的项目中担任已批准的工作。因此Project::Role正在成为一个强大的标识,并且无论如何它都具有属性。
  • 因此,Project::Role是一个实体。剩下的椭圆形是Project + Role(不是所有Project)的特定组合的子代。
  • 我们的粉红色孩子通过其特定属性获得了实体状态。更重要的是,它的约束来自先前约束的实体,而不是简单的约束。
  • 数据具有自然顺序或层次结构,并且在此基础上绘制的图很容易理解。现在,我们有机会查看属性。他们可能看起来相同或相似或令人困惑;而由于上下文和层次结构,现在它们具有明确的含义。

  • 我已经介绍了标识符的概念,但不对其进行扩展,如果需要的话,我将进行讨论。我认为您可以看到,标识符实际上非常非常重要,并且作为建模练习的普通部分公开。
    概括地说(您的问题,与我的示例进展相反),当我们进行“归一化”时,三个初始椭圆可能以一个或两个结束或保留为三个对象。没有属性的简单关联表;或作为具有属性的真实实体...,但我们现在还不应该这样做,也不应在乎。同样,对于DDL或现阶段的规范化还为时过早。我们不知道键是什么。与它们相关的属性;以及与他们的关系如何。而且,我们不在乎。就示例而言,是的,实体是明确且明确的。
    请提供反馈,以便您继续前进。
    编辑:图表已更新,多页。

    10-05 20:29
    查看更多