Class diagrams and Entity-Relationship Diagrams (ERDs) are both essential modeling tools in software development, but they serve different purposes. Understanding when and how to use each—and how they complement each other—is crucial for building robust systems.
A UML (Unified Modeling Language) diagram that represents the object-oriented structure of a system. It shows:
Purpose: Design the software architecture and object interactions.
A diagram that represents the data structure of a database. It shows:
Purpose: Design the database schema.
| Aspect | Class Diagram | ERD |
|---|---|---|
| Focus | Object-oriented design | Data storage structure |
| Shows | Classes, methods, relationships | Tables, columns, relationships |
| Level | Application/logic layer | Database/persistence layer |
| Relationships | Inheritance, association, composition, aggregation | One-to-one, one-to-many, many-to-many |
| Used By | Developers, architects | Database designers, backend developers |
| Timing | Early design phase | Database design phase |
Here's a practical workflow for combining both diagrams:
Detailed Workflow Example: E-Commerce System
From requirements, we identify: Users, Products, Orders, OrderItems, Categories, Reviews
@startuml
skinparam backgroundColor white
skinparam classAttributeIconSize 0
class User {
-userId: Long
-username: String
-email: String
-password: String
+register(): void
+login(): boolean
+updateProfile(): void
}
class Product {
-productId: Long
-name: String
-description: String
-price: Decimal
-stockQuantity: Integer
+getDetails(): Product
+updateStock(quantity: Integer): void
}
class Category {
-categoryId: Long
-name: String
-description: String
+getProducts(): List<Product>
}
class Order {
-orderId: Long
-orderDate: DateTime
-status: String
-totalAmount: Decimal
+placeOrder(): Order
+cancelOrder(): void
+getStatus(): String
}
class OrderItem {
-orderItemId: Long
-quantity: Integer
-unitPrice: Decimal
+getSubtotal(): Decimal
}
class Review {
-reviewId: Long
-rating: Integer
-comment: String
-reviewDate: DateTime
+submitReview(): void
}
User "1" -- "0..*" Order : places >
Order "1" *-- "1..*" OrderItem : contains >
Product "1" -- "0..*" OrderItem : included in >
Product "0..*" -- "1" Category : belongs to >
User "1" -- "0..*" Review : writes >
Product "1" -- "0..*" Review : receives >
note right of OrderItem
OrderItem is a composition
of Order - it cannot exist
without an Order
end note
@enduml
Not all classes need database tables:
@startuml
skinparam backgroundColor white
entity "Users" as users {
* user_id : number <<PK>>
--
username : varchar(50)
email : varchar(100)
password_hash : varchar(255)
created_at : timestamp
}
entity "Products" as products {
* product_id : number <<PK>>
--
name : varchar(100)
description : text
price : decimal(10,2)
stock_quantity : integer
category_id : number <<FK>>
created_at : timestamp
}
entity "Categories" as categories {
* category_id : number <<PK>>
--
name : varchar(50)
description : text
}
entity "Orders" as orders {
* order_id : number <<PK>>
--
user_id : number <<FK>>
order_date : timestamp
status : varchar(20)
total_amount : decimal(10,2)
}
entity "Order_Items" as order_items {
* order_item_id : number <<PK>>
--
order_id : number <<FK>>
product_id : number <<FK>>
quantity : integer
unit_price : decimal(10,2)
}
entity "Reviews" as reviews {
* review_id : number <<PK>>
--
user_id : number <<FK>>
product_id : number <<FK>>
rating : integer
comment : text
review_date : timestamp
}
users ||--o{ orders : places
orders ||--|{ order_items : contains
products ||--o{ order_items : includes
categories ||--o{ products : categorizes
users ||--o{ reviews : writes
products ||--o{ reviews : receives
@enduml
The mapping shows how object-oriented concepts translate to relational database concepts:
| Class | Table | Notes |
|---|---|---|
| User | users | 1:1 mapping |
| Product | products | Foreign key to categories |
| Category | categories | Simple entity |
| Order | orders | Foreign key to users |
| OrderItem | order_items | Junction table for Order-Product many-to-many |
| Review | reviews | Foreign keys to users and products |
Key Observations:
OrderItem class becomes a separate table to resolve the many-to-many relationship between Orders and Products
@startuml
skinparam backgroundColor white
skinparam classAttributeIconSize 0
class Author {
-authorId: Long
-name: String
-bio: String
-email: String
+writePost(): Post
+editProfile(): void
}
class Post {
-postId: Long
-title: String
-content: String
-publishDate: DateTime
-status: String
+publish(): void
+archive(): void
}
class Comment {
-commentId: Long
-content: String
-createdDate: DateTime
+postComment(): void
+deleteComment(): void
}
class Tag {
-tagId: Long
-name: String
+getPosts(): List<Post>
}
Author "1" -- "0..*" Post : writes >
Post "1" -- "0..*" Comment : has >
Post "0..*" -- "0..*" Tag : tagged with >
Author "1" -- "0..*" Comment : writes >
@enduml
@startuml
skinparam backgroundColor white
entity "Authors" as authors {
* author_id : number <<PK>>
--
name : varchar(100)
bio : text
email : varchar(100)
}
entity "Posts" as posts {
* post_id : number <<PK>>
--
author_id : number <<FK>>
title : varchar(200)
content : text
publish_date : timestamp
status : varchar(20)
}
entity "Comments" as comments {
* comment_id : number <<PK>>
--
post_id : number <<FK>>
author_id : number <<FK>>
content : text
created_date : timestamp
}
entity "Tags" as tags {
* tag_id : number <<PK>>
--
name : varchar(50)
}
entity "Post_Tags" as post_tags {
* post_id : number <<PK, FK>>
* tag_id : number <<PK, FK>>
}
authors ||--o{ posts : writes
posts ||--o{ comments : has
authors ||--o{ comments : writes
posts }|--|{ post_tags : tagged
tags }|--|{ post_tags : tagged
@enduml
Note: The many-to-many relationship between Posts and Tags requires a junction table (post_tags).
@startuml
skinparam backgroundColor white
skinparam classAttributeIconSize 0
abstract class Person {
#personId: Long
#firstName: String
#lastName: String
#email: String
+getFullName(): String
+updateContact(): void
}
class Student extends Person {
-studentId: String
-enrollmentDate: DateTime
-gpa: Decimal
+enrollCourse(): void
+getTranscript(): Transcript
}
class Professor extends Person {
-professorId: String
-department: String
-hireDate: DateTime
+teachCourse(): void
+gradeStudent(): void
}
class Course {
-courseId: String
-courseName: String
-credits: Integer
-maxEnrollment: Integer
+addStudent(): boolean
+removeStudent(): void
}
class Enrollment {
-enrollmentId: Long
-semester: String
-year: Integer
-grade: String
+calculateGPA(): Decimal
}
Student "0..*" -- "0..*" Course : enrolls in >
Professor "1" -- "0..*" Course : teaches >
Student "1" -- "0..*" Enrollment : has >
Course "1" -- "0..*" Enrollment : contains >
@enduml
@startuml
skinparam backgroundColor white
entity "Persons" as persons {
* person_id : number <<PK>>
--
first_name : varchar(50)
last_name : varchar(50)
email : varchar(100)
person_type : varchar(20)
}
entity "Students" as students {
* student_id : varchar(20) <<PK>>
--
person_id : number <<FK>>
enrollment_date : date
gpa : decimal(3,2)
}
entity "Professors" as professors {
* professor_id : varchar(20) <<PK>>
--
person_id : number <<FK>>
department : varchar(50)
hire_date : date
}
entity "Courses" as courses {
* course_id : varchar(20) <<PK>>
--
course_name : varchar(100)
credits : integer
max_enrollment : integer
professor_id : varchar(20) <<FK>>
}
entity "Enrollments" as enrollments {
* enrollment_id : number <<PK>>
--
student_id : varchar(20) <<FK>>
course_id : varchar(20) <<FK>>
semester : varchar(10)
year : integer
grade : varchar(2)
}
persons ||--|| students : is
persons ||--|| professors : is
professors ||--o{ courses : teaches
students }|--|{ enrollments : has
courses }|--|{ enrollments : contains
@enduml
Note: Inheritance (Student/Professor extending Person) is mapped using separate tables with foreign keys to the parent table.
In Class Diagram:
@startuml
class Order
class Product
Order "0..*" -- "0..*" Product
@enduml
In ERD (requires junction table):
@startuml
entity "Orders" as orders {
* order_id : number <<PK>>
}
entity "Products" as products {
* product_id : number <<PK>>
}
entity "Order_Products" as order_products {
* order_id : number <<PK, FK>>
* product_id : number <<PK, FK>>
quantity : integer
}
orders }|--|{ order_products
products }|--|{ order_products
@enduml
Class Diagram shows the difference:
@startuml
class House
class Room
class Furniture
House *-- Room : composition (Room can't exist without House)
House o-- Furniture : aggregation (Furniture can exist independently)
@enduml
ERD doesn't distinguish composition/aggregation—both become foreign key relationships.
Single Table Inheritance:
@startuml
entity "Vehicles" as vehicles {
* vehicle_id : number <<PK>>
--
type : varchar(20)
make : varchar(50)
model : varchar(50)
engine_size : decimal(3,1)
cargo_capacity : integer
}
note right: All subclasses in one table with discriminator column
@enduml
Class Table Inheritance:
@startuml
entity "Vehicles" as vehicles {
* vehicle_id : number <<PK>>
--
make : varchar(50)
model : varchar(50)
}
entity "Cars" as cars {
* vehicle_id : number <<PK, FK>>
--
engine_size : decimal(3,1)
}
entity "Trucks" as trucks {
* vehicle_id : number <<PK, FK>>
--
cargo_capacity : integer
}
vehicles ||--|| cars : extends
vehicles ||--|| trucks : extends
@enduml
| Class Diagram Concept | ERD Equivalent |
|---|---|
| Class | Table |
| Attribute | Column |
| Method | Not represented (application logic) |
| Association | Foreign Key relationship |
| Composition | Foreign Key with CASCADE DELETE |
| Aggregation | Foreign Key (optional) |
| Inheritance | Separate tables or single table with discriminator |
| Multiplicity (1..*) | Foreign Key constraint |
| Multiplicity (..) | Junction/Bridge table |
| Abstract Class | May not have a table, or base table |
| Interface | Not directly represented |
❌ Trying to show methods in ERDs – ERDs are for data structure only
❌ Ignoring normalization in ERDs – leads to data redundancy
❌ Creating too many tables from simple class associations
❌ Forgetting junction tables for many-to-many relationships
❌ Not considering performance – some class designs don't translate well to efficient queries
✅ Do: Validate your ERD with sample queries
✅ Do: Consider read/write patterns when designing both diagrams
✅ Do: Use tools that can generate one from the other (with caution)
✅ Do: Get feedback from both developers and DBAs
Class diagrams and ERDs are complementary tools in your software design toolkit:
By using both together, you create a complete picture of your system—from the application logic down to the database layer. Start with class diagrams to design your object model, then create ERDs to plan your data storage, and finally map between them to ensure consistency.
Remember: Good software design considers both the object world and the data world. Master both diagrams, and you'll be well-equipped to build robust, maintainable systems!
