ER Diagram vs UML Class Diagram: What's the Difference?
An ER diagram and a UML class diagram can look almost identical - boxes with fields, lines between them - yet they answer different questions. Knowing which to reach for saves confusion.
At a glance an entity relationship diagram and a UML class diagram are twins: both are boxes containing a name and a list of fields, connected by lines that carry cardinality. But they model different layers of a system and answer different questions. An ER diagram describes data at rest - the tables in a database, their columns, and the foreign keys between them. A UML class diagram describes the software objects in a running program - their attributes, their behavior, and the associations between them. Confusing the two leads to diagrams that mix concerns and satisfy neither audience.
This guide draws the distinction clearly: what each diagram is for, how their notations differ, where they overlap, and when a project genuinely needs both. You can build ER diagrams in Atlas Diagram Studio at /diagrams with the ERD tool at /diagram-tools/erd-tool, and class diagrams with the UML diagram tool at /diagram-tools/uml-diagram. Understanding the difference helps you choose the right tool for the question you are actually trying to answer, rather than drawing a hybrid that blurs data and code.
What each diagram models
An ER diagram is a database-centric view. Its entities are tables, its attributes are columns with data types, and its relationships are foreign key constraints annotated with crow's foot cardinality. It is entirely about structure and storage: what data exists, how it is keyed, and how records reference one another. There is no notion of behavior in an ER diagram, because a database table does not have methods - it only holds data. The questions it answers are about the shape and integrity of stored information.
A UML class diagram is a code-centric view. Its classes are the objects in your program, containing not only attributes but also operations - the methods that define behavior. Its relationships are richer than an ERD's: alongside plain associations it distinguishes inheritance, where one class is a specialized kind of another; composition, where one object owns another; and aggregation, a looser has-a relationship. These concepts exist in object-oriented code and have no direct equivalent in a flat relational table, which is the deepest difference between the two diagram types.
Where the notations differ
The visual differences follow from the conceptual ones. The clearest is that class boxes have three compartments - name, attributes, and operations - while entity boxes have two, name and attributes, because entities have no behavior. Relationship notation differs too: ERDs use crow's foot symbols for cardinality, while UML writes multiplicities as numbers and ranges like 1, 0..1, and asterisk, and adds special arrowheads and diamonds for inheritance, composition, and aggregation that ER diagrams simply do not have.
- Class boxes show operations (methods); entity boxes never do, since tables have no behavior.
- ERDs use crow's foot symbols for cardinality; UML uses numeric multiplicities like 1 and asterisk.
- UML has inheritance (a hollow triangle arrow); ER diagrams have no native inheritance concept.
- UML distinguishes composition (filled diamond) and aggregation (hollow diamond); ERDs do not.
- ERDs mark primary and foreign keys explicitly; class diagrams rarely show keys, since objects use references.
- An ER many-to-many needs a junction entity; a UML many-to-many can use an association class.
- ERD attributes carry database data types; class attributes carry programming-language types.
Where they overlap
The overlap is real and is why the two are so often confused. Many applications persist their objects to a database, so a class in the code frequently corresponds to a table in the database, with the class's attributes mapping to the table's columns. Object-relational mapping tools formalize exactly this correspondence. In such systems the class diagram and the ER diagram describe two views of the same underlying concepts - a User object and a User table - which is why they look so alike and why one can sometimes be derived from the other.
But the correspondence is never perfect, and the gaps matter. Inheritance in the object model has to be flattened into tables using one of several patterns, none of which the class diagram shows. A many-to-many association that is a single line in UML becomes a junction table in the ERD. Computed properties and behavior in the class have no place in the schema at all. Treating the two diagrams as interchangeable hides these translation decisions, which are often where subtle bugs live. They are complementary views, not duplicates.
When to use each, or both
Use an ER diagram when your question is about data: designing a schema, documenting a database, reasoning about keys and integrity, or onboarding someone to how information is stored. Use a class diagram when your question is about code: designing object structure and behavior, showing inheritance hierarchies, or documenting how the software is organized. If you find yourself wanting to show methods, you need a class diagram; if you find yourself marking foreign keys, you need an ERD.
Many projects benefit from both, kept as distinct diagrams that reference each other rather than a single hybrid. The class diagram documents the domain model as the code sees it; the ER diagram documents the schema as the database stores it; and the mapping between them - how objects become rows - is itself worth noting where it is non-obvious. Build each with the tool suited to it, the UML diagram tool at /diagram-tools/uml-diagram and the ERD tool at /diagram-tools/erd-tool, and see the ER notation guide for how UML multiplicities relate to crow's foot symbols.