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?
6 Answers
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.

- 14,056
- 7
- 62
- 75
-
2I understand what you're saying about the ERD diagram being persistence-specific and the class diagram not containing persistence-specific information, however I would consider this an inferred fact rather than a visual one when viewing the diagrams side by side. Also, you mention that the class diagram does not contain any kind of explicit relationships between diagram elements, however if I am showing both associations and multiplicity between elements on the class diagram how does this differ from the relations and cardinalities shown between entities on the ERD diagram? – Adam Jan 13 '11 at 14:27
-
1The relation on the class diagram is logical, but on the other side a ERD relation is a real physical constraint between tables. You are right that the diagrams can look very similar in simple scenarios, but in more complex ones the difference is evident. The class diagram supports far more abstraction than the ERD. If you draw the ERD diagram using classic Chen notation the visual difference compared to a UML class diagram is huge even in simple scenarios. – Faris Zacina Jan 14 '11 at 00:20
-
OK, thanks for the explanation and what you say about a logical versus a physical constaint makes sense to me. Given that a class diagram supports far more abstraction that an ERD diagram, is it fair to say that in a more complex scenario: – Adam Jan 14 '11 at 02:02
-
(continuation of my previous comment)....that the classes represented on a class diagram won't necesaarily match 1-to-1 to the entities shown on the ERD? Thanks for your help on this, I appreciate it – Adam Jan 14 '11 at 02:12
-
2@TheZenCoder: you said, "The class diagram contains just the classes in your object model without any kind of explicit relationships drawn between diagram elements." I've never seen a class diagram without explicit relationships. I expect to see genus–differentia definitions (see http://en.wikipedia.org/wiki/Genus%E2%80%93differentia_definition ) that resonate with the domain in UML class diagrams. – Jim L. Sep 30 '14 at 20:47
-
@Jim you are right. In fact i was thinking about the physical relationships. I will rewrite that part. – Faris Zacina Sep 30 '14 at 21:00
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, ...

- 8,058
- 2
- 33
- 39
-
-
2As I said, ER started with an initial proposal from Peter Cheng but quickly evolved to a complete family of (extended) ER languages that added new features to the language like inheritance. So, yes, some (E)ER versions allow inheritance – Jordi Cabot Feb 23 '16 at 06:06
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.

- 6,177
- 3
- 21
- 47
-
2I think this is the answer that provides the best explanation for the differences and their consequent use over the other. As a rule of thumb, if you want to model DB entities/relationships you are probably looking for an ERD but if you want to model programs/systems then you are probably looking for one-many of the different UML diagrams. – frostini Nov 16 '22 at 19:25
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.

- 11
- 1
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.

- 11
- 2