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