概念性 UML 类图和 ERD 之间的区别？
如果我创建一个概念类图，使每个类捕获“名称”和“属性”，但不捕获“操作”，那么我基本上没有创建什么会被视为 ERD 吗？我试图了解创建我所描述的概念类图与将其称为 ERD 之间有什么区别？如果它们仍然是两种不同的动物，有人可以解释一下它们之间的区别吗？
If I create a conceptual class diagram such that each class captures 'name' and 'attributes' but not 'operations', have I not basically created what would be otherwise considered an ERD? I'm trying to gain an understanding of what the differences are between creating a conceptual class diagram as I have described versus calling it a ERD? If these are still two different animals, can somebody please explain what the differences are?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
类图仅包含对象模型中的类以及连接图元素的最终链接/关系。然而，这些链接不一定对应于 ERD 图中的物理关系，而是代表逻辑连接。
类图只是应用程序的对象模型，不包含任何特定于持久性的信息。当您考虑类图时，请忘记数据库或您可能使用的任何其他存储。
另一方面，ERD 图是一个特定于持久性的图，它显示（最常见的）关系数据库中存在的实体（表）。它还显示这些表和所有其他特定于数据库的信息之间的物理关系（和基数）。 ERD 图有时看起来与类图相似，但这并不意味着与类图相同。
The class diagram contains just the classes in your object model with eventual links/relationships connecting diagram elements. However those links don't necessarily correspond to physical relationships like in an ERD diagram, but instead they represent logical connections.
The class diagram is just the object model of your application and does not contain any persistence-specific information. When you think about the class diagram forget about the database or any other storage you may use.
The ERD diagram on the other side, is a persistence-specific diagram which display the entities (tables) existing in a (most often) relational database. It also displays the physical relations (and cardinalities) between those tables and all other database-specific information. The ERD diagram can sometimes look similar to the class diagram, but that doesn't mean is the same as a class diagram.
如果您使用扩展实体关系图（当今最常见的情况），两者的表达能力几乎没有什么区别（如果我们只关注属性、类和关联部分）
，确实，它们在图形级别上看起来非常不同，因为它们元素使用不同的符号，但“语义”非常相似。它们都允许继承（再次，我说的是 EER）、n 元关联、关联类……
There´s little difference in the expressiveness of both (if we just focus on the attributes, classes and associations part) if you use Extended Entity Relationship diagrams (the most common case nowadays)
True, they look very different at the graphical level since they use different symbols for the elements but the "semantics" are quite similar. They both allow inheritance (again, I´m talking about EER), n-ary associations, association classes, ...
我见过的 ER 图（最常见的是 ERWin IE 表示法）主要关注数据库的设计。它们与主键、外键有关，具有未命名的关系，并且通常没有泛化/专门化。
另一方面，一个好的 UML 概念类图不关心键，反映问题域，并且具有至少暗示事物为何相关的语义的关联端属性。这有助于将领域传达给更多初级开发人员，这样他们就不必猜测。
The ER diagrams I've seen (most frequently ERWin IE notation) have focused on the design for a database. They are concerned with primary keys, foreign keys, have unnamed relationships, and usually have no generalization / specialization.
A good UML conceptual class diagram, on the other hand, is not concerned with keys, reflects the problem domain, and has association-end properties that at least hint at the semantics of why things are related. This helps communicate the domain down to more junior developers so they don't have to guess.
这取决于您可能不喜欢做 ER-D 的情况。但想象一下，如果您有一个单独的数据层来处理数据逻辑。在这种情况下，数据的许多细节不应与应用层共享。并且类图不应超出应用程序层。我必须强调这两个图并不相等。在某些情况下，您需要同时执行这两种操作，主要是在多层架构中，而在某些情况下，您可能只能使用类图；例如单层应用程序。
我强烈主张类图不会废除 ER 图。
It depends on the situation where you may not like to do the ER-D. But imagine if you have a seperate data layer where the data logic is handled. In this case many details of data shall not be shared with the application layer. And you class diagram shall not go beyond the application layer. I must stress that both the diagrams are not equal. And there are situations where you need to do both, mainly in multi-tier architecture, and there are situations where you may be able to just use class diagram; e.g. single-tier application.
I strongly advocate the view that class diagram doesn't abrogate the E-R diagram.
设计类图由概念模型和协作图组成。
设计类图包括：
Design class diagrams are made from conceptual model and collaboration diagrams.
Design class diagrams include:
IMO 简单来说
类图描述了系统如何工作的细节。
ER 图描述了系统如何将“状态”持久化为蓝图。
目标：
详细说明系统组件（类）的状态和行为。
使用 Solid 原则设计“高效”、灵活的系统（更少的耦合和更多的内聚）。
目标：
设计如何“有效”地保留系统状态的蓝图。
考虑将进行哪种查询（读与写），是否需要任何联接
因此找出用于索引的列
使用标准化、ACID 属性。
PS：请注意，这两个图都试图在各自方面有效地完成任务。
IMO In Simple terms
Class diagram depicts the details of how will the system work.
ER diagram depicts how the system persists 'state' as a blue print.
Goal:
Detail out state and behavior of the components(classes) of the system.
Design 'efficient', flexile system(less coupling and more cohesion) using Solid principles.
Goal:
Design a blue print of how to 'efficiently' persist the state of the system.
Consider what kind of queries will be made (read vs write), are there any joins required
consequently figure out the columns for indexing
Use Normalization, ACID properties.
PS: notice the both the diagram tries to efficiently do thing in their on respect.