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

如果我创建了一个概念类关系图，这样每个类都可以捕获“名称”和“属性”，但不能捕获“操作”，那么我基本上还没有创建一个ERD吗？我试图了解创建我所描述的概念类图与将其称为ERD之间的区别？如果这仍然是两种不同的动物，有人能解释一下它们的区别吗

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

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

---

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

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

---

诚然，它们在图形级别上看起来非常不同，因为它们对元素使用不同的符号，但“语义”非常相似。它们都允许继承（再一次，我说的是EER）、n元关联、关联类等等，这取决于您可能不喜欢执行ER-D的情况。但是想象一下，如果您有一个单独的数据层来处理数据逻辑。在这种情况下，数据的许多细节不应与应用层共享。类图不能超出应用层。我必须强调，这两个图表并不相等。在某些情况下，您需要同时执行这两种操作，主要是在多层体系结构中，并且在某些情况下，您可能只需要使用类图；e、 g.单层应用程序

---

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

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

类、关联和属性

方法

属性类型

适航性

依赖关系

我所看到的ER图（最常见的是ERWIE表示法）侧重于数据库的设计。它们与主键、外键有关，具有未命名的关系，并且通常没有泛化/专门化

另一方面，一个好的UML概念类图与键无关，它反映了问题域，并且具有至少暗示事物为何相关的语义的关联结束属性。这有助于将领域向下传达给更多的初级开发人员，这样他们就不必猜测了。

IMO

类图描述了系统如何工作的详细信息。

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

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

目标： 设计如何“有效”保持系统状态的蓝图。 考虑什么样的查询（读写），是否需要连接？ 因此，请找出要编制索引的列 使用标准化、酸性属性

---

PS：请注意，这两个图都试图在其on方面高效地完成工作。

我理解您所说的ERD图是持久性特定的，而类图不包含持久性特定的信息，然而，当并排查看图表时，我会认为这是推断的事实，而不是视觉上的事实。另外，您提到类图不包含图元素之间的任何类型的显式关系，然而，如果我在类图上显示元素之间的关联和多重性，这与ERD图上实体之间显示的关系和基数有何不同？类图上的关系是逻辑的，但另一方面，ERD关系是表之间真正的物理约束。您是对的，这些图表在简单场景中看起来非常相似，但在更复杂的场景中，差异是显而易见的。类图比ERD支持更多的抽象。如果您使用经典的Chen符号绘制ERD图，那么即使在简单的场景中，与UML类图相比，视觉上的差异也是巨大的。好的，感谢您的解释，您所说的逻辑结构与物理结构对我来说是有意义的。考虑到类图比ERD图支持更多的抽象，可以公平地说，在更复杂的场景中：（继续我之前的评论）…类图上表示的类不一定与ERD上显示的实体1:1匹配吗？谢谢你在这方面的帮助，我很感激it@TheZenCoder：您说过，“类图只包含对象模型中的类，没有在图元素之间绘制任何类型的显式关系。”我从未见过没有显式关系的类图。我希望在UML类图中看到与领域产生共鸣的属-差异定义（see）。ERD如何允许继承？！正如我所说的，ER从Peter Cheng的初始提案开始，但quic