Choose the question before the diagram
Choose a class diagram when you need to explain responsibilities, typed members, interfaces, and collaboration in a software design. Choose an entity relationship diagram when the discussion centers on entities and their data relationships. A physical relational ERD goes further by showing tables, keys, and the constraints declared in a schema.
These views can overlap. A conceptual ERD is not necessarily a physical database diagram, and a class model can describe domain information before code exists. The useful distinction is the purpose of the particular drawing: explain behavior and contracts, discuss information structure, or document a database implementation.
| Question | Class diagram | Relational ERD |
|---|---|---|
| What is represented? | Classes, interfaces, attributes, operations, and their relationships. | Tables or data entities, attributes or columns, and relationships. |
| What identifies an instance? | An explicit modeling or implementation decision; a class box need not declare a primary key. | Keys identify stored rows in a relational schema. |
| Where is behavior? | Operation signatures can describe exposed behavior and contracts. | A typical ERD does not display application methods; a database may still enforce rules with constraints or other mechanisms. |
| How are links expressed? | Associations, roles, multiplicities, specialization, realization, and dependencies. | Conceptual relationships, or declared key references in a physical schema. |
| What is checked? | The diagram describes a design; tools may offer advisory checks. | DDL and the database determine which constraints are actually enforced. |
Model the same Order from two viewpoints
In a class diagram, Order may hold number and total and expose addItem(item: OrderItem): void. That drawing helps the team decide where order behavior belongs and which other types it uses. An interface such as Payable can let several implementations expose the same contract without pretending that the interface is a database table.
In a relational ERD, orders may contain id, customer_id, number, and total. The customers table supplies the referenced key. A foreign key can require a non-null customer_id to reference an existing customer when the schema declares both the reference and non-null requirement. That is an enforced data rule, not an operation signature.
The models should use compatible business vocabulary, but their boxes need not match one for one. A class can use information from several tables; a table can support several classes or store a relationship. Explain those mapping decisions instead of copying a diagram and changing its title.
Do not translate symbols into database rules blindly
A UML composition diamond expresses composite ownership in the model. It does not automatically mean that a particular foreign key has ON DELETE CASCADE. Conversely, a schema can use a cascade for practical data maintenance without asserting every semantic claim of UML composition.
Likewise, an association end labeled 1..* does not by itself guarantee that every parent row has a child row. A simple foreign key constrains references from child rows; enforcing a minimum number of children for each parent may require additional design and enforcement. Keep that gap visible during review.
Generalization also needs a deliberate persistence strategy. Inheritance in a class diagram does not select table-per-hierarchy, shared-key subtype tables, or another mapping. Conceptual EER diagrams can represent specialization too, so inheritance-like structures are not exclusive to class models.
Use the workspace that owns your source of truth
Use Class Diagram when editing classes, interfaces, member signatures, roles, and dependencies. Its JSON/cloud files belong to that tool. It exports images and PlantUML text, but does not generate SQL or import a class model into ERD Builder.
Use ERD Builder when you want to draw a conceptual Chen or EER model without writing SQL first. Its Convert ERD to SQL workflow asks for mapping decisions and opens a new SQL document after review. Conversion notes describe constraints that need additional application or database logic.
Use SQL to ERD when DDL is already the authoritative description of the database. Review tables and declared foreign keys there, keeping the schema and diagram together. A class-diagram operation cannot replace a SQL constraint, and a SQL ERD cannot establish which application object should own a calculation.
Keep the two models useful together
For an order-system change, start by naming the responsibility: calculating tax, adding an item, or persisting a customer reference. Review the class model with the people implementing behavior, then review the database model with the people maintaining stored data. A shared glossary prevents OrderItem and order_lines from drifting into contradictory concepts.
Record mappings and exceptions in notes or nearby documentation. State which document is a proposal and which reflects deployed code or DDL. During a change, update both views when their responsibilities intersect; avoid a second diagram that nobody maintains.
For sharing, save each editable source in its owning tool and export a readable view for the audience. Use a class view with operations for a behavior discussion and a key-focused ERD for a schema review. The diagrams work best as complementary explanations, with decisions and enforcement kept explicit.
References and further reading
Try the model in Class Diagram
Start with a blank model or explore the order-system template.