概念 UML 类图和 ERD 之间的区别？答案

【问题标题】：Differences between a conceptual UML class diagram and an ERD?概念 UML 类图和 ERD 之间的区别？
【发布时间】：2011-06-08 11:46:26
【问题描述】：

如果我创建一个概念类图，使得每个类都捕获“名称”和“属性”而不是“操作”，那么我基本上没有创建否则会被视为 ERD 的东西吗？我试图了解创建我所描述的概念类图与将其称为 ERD 之间的区别是什么？如果这些仍然是两种不同的动物，有人可以解释一下有什么区别吗？

【问题讨论】：

【解决方案1】：

IMO 简单来说

类图描述了系统如何工作的细节。

ER 图描绘了系统如何将“状态”保持为蓝图。

目标： 详细说明系统组件（类）的状态和行为。使用 Solid 原则设计“高效”、灵活的系统（耦合更少，内聚更多）。

目标： 设计一个如何“有效”保持系统状态的蓝图。考虑将进行什么样的查询（读取与写入），是否需要任何连接因此找出索引的列使用标准化、ACID 属性。

PS：请注意这两个图表都试图有效地做事。

【讨论】：

【解决方案2】：

如果您使用扩展实体关系图（现在最常见的情况），两者的表达能力（如果我们只关注属性、类和关联部分）几乎没有区别

的确，它们在图形级别上看起来非常不同，因为它们对元素使用不同的符号，但“语义”非常相似。它们都允许继承（同样，我说的是 EER）、n 元关联、关联类……

【讨论】：

ERD 如何允许继承？！
正如我所说，ER 从 Peter Cheng 的最初提议开始，但很快演变成一个完整的（扩展的）ER 语言家族，为语言添加了新的特性，如继承。所以，是的，一些 (E)ER 版本允许继承

【解决方案3】：

类图仅包含对象模型中的类，并带有连接图元素的最终链接/关系。然而，这些链接不一定对应于 ERD 图中的物理关系，而是它们代表逻辑连接。

类图只是应用程序的对象模型，不包含任何特定于持久性的信息。当您考虑类图时，请忘记数据库或您可能使用的任何其他存储。

另一方面，ERD 图是一个特定于持久性的图，它显示（最常见的）关系数据库中存在的实体（表）。它还显示这些表和所有其他特定于数据库的信息之间的物理关系（和基数）。 ERD 图有时看起来类似于类图，但这并不意味着与类图相同。

【讨论】：

我理解您所说的 ERD 图是持久性特定的，而类图不包含持久性特定的信息，但是在查看图表并排。此外，您提到类图不包含图元素之间的任何类型的显式关系，但是，如果我在类图上显示元素之间的关联和多重性，这与 ERD 上实体之间显示的关系和基数有何不同图？
类图上的关系是合乎逻辑的，但另一方面，ERD 关系是表之间真正的物理约束。您是对的，这些图表在简单场景中看起来非常相似，但在更复杂的场景中，差异是显而易见的。类图支持比 ERD 更多的抽象。如果您使用经典 Chen 表示法绘制 ERD 图，即使在简单的场景中，与 UML 类图相比视觉差异也是巨大的。
好的，感谢您的解释，您所说的逻辑与物理约束对我来说很有意义。鉴于类图支持比 ERD 图更多的抽象，可以说在更复杂的场景中：
（我之前评论的继续）....类图上表示的类不一定与 ERD 上显示的实体一对一匹配？感谢您对此的帮助，我很感激
@TheZenCoder：您说过，“类图只包含对象模型中的类，而在图元素之间没有任何明确的关系。”我从未见过没有明确关系的类图。我希望看到与 UML 类图中的域产生共鸣的属差异定义（参见 en.wikipedia.org/wiki/Genus%E2%80%93differentia_definition）。

【解决方案4】：

我见过的 ER 图（最常见的 ERWin IE 表示法）都侧重于数据库的设计。它们与主键、外键有关，具有未命名的关系，通常没有泛化/特化。

另一方面，一个好的 UML 概念类图不关心键，反映了问题域，并且具有关联端属性，至少提示事物为什么的语义有关的。这有助于将域传达给更多初级开发人员，因此他们不必猜测。

【讨论】：

【解决方案5】：

设计类图由概念模型和协作图组成。设计类图包括：

【讨论】：

【解决方案6】：

这取决于您可能不喜欢做 ER-D 的情况。但是想象一下，如果您有一个单独的数据层来处理数据逻辑。在这种情况下，许多数据细节不应与应用层共享。而且你的类图不能超出应用层。我必须强调这两个图表是不相等的。并且有些情况你需要两者都做，主要是在多层架构中，有些情况你可能只使用类图；例如单层应用程序。

我强烈主张类图不会废除 E-R 图的观点。

【讨论】：