TÓM TẮT
- 1 1. Giới thiệu chung về Entity Relationship Diagram
- 2 2. Các thành phần cơ bản của ERD
- 3 3. Các bước chi tiết để vẽ một ERD chuẩn
- 3.1 Bước 1: Thu thập và phân tích yêu cầu nghiệp vụ
- 3.2 Bước 2: Xác định các thực thể chính
- 3.3 Bước 3: Xác định thuộc tính cho mỗi thực thể
- 3.4 Bước 4: Xác định các quan hệ và mức độ (cardinality)
- 3.5 Bước 5: Kiểm tra và chuẩn hoá (Normalization)
- 3.6 Bước 6: Vẽ ERD chi tiết bằng công cụ
- 3.7 Bước 7: Rà soát và phê duyệt
- 4 4. Các quy tắc chuẩn hoá khi vẽ ERD
- 5 5. Ví dụ thực tế: Vẽ ERD cho hệ thống bán hàng trực tuyến
- 6 6. Các công cụ phổ biến để vẽ ERD
- 7 7. Các lỗi thường gặp khi vẽ ERD và cách khắc phục
- 8 8. Thực hành: Bước-by-bước vẽ ERD bằng draw.io
- 9 9. Tài liệu tham khảo và nguồn học thêm
- 10 10. Kết luận
1. Giới thiệu chung về Entity Relationship Diagram
Entity Relationship Diagram (ERD) – còn được gọi là sơ đồ thực thể – quan hệ – là một công cụ trực quan quan trọng trong việc thiết kế và phân tích cơ sở dữ liệu. ERD giúp chúng ta mô tả các thực thể (entity), các thuộc tính (attribute) của chúng, cũng như các mối quan hệ (relationship) giữa các thực thể. Khi dự án phần mềm hay hệ thống thông tin được triển khai, việc có một ERD rõ ràng sẽ:
- Giúp nhà phân tích nghiệp vụ xác định yêu cầu dữ liệu một cách chính xác.
- Hỗ trợ lập trình viên trong việc xây dựng cấu trúc bảng, khóa chính, khóa ngoại.
- Đảm bảo tính nhất quán và tối ưu hoá truy vấn trong quá trình phát triển và bảo trì.
- Tránh lỗi thiết kế như dư thừa dữ liệu, mất mát thông tin, hay các mối quan hệ không hợp lý.
Trong bài viết này, chúng ta sẽ đi sâu vào quy trình vẽ ERD từ việc thu thập yêu cầu, xác định thực thể, thuộc tính, quan hệ, cho đến các quy tắc chuẩn hoá và một số công cụ hỗ trợ thực tế. Mục tiêu là cung cấp cho bạn một hướng dẫn chi tiết, dễ thực hiện và áp dụng ngay vào dự án thực tế.
2. Các thành phần cơ bản của ERD
2.1. Thực thể (Entity)
Thực thể là một đối tượng có thể định danh độc lập trong hệ thống, ví dụ: Khách hàng, Sản phẩm, Đơn hàng, Nhân viên. Thực thể thường được biểu diễn bằng hình chữ nhật trong ERD.
2.2. Thuộc tính (Attribute)
Mỗi thực thể có một tập hợp các thuộc tính mô tả chi tiết hơn về thực thể đó. Ví dụ, thực thể Khách hàng có các thuộc tính: CustomerID, Tên, Địa chỉ, Số điện thoại. Thuộc tính được vẽ dưới dạng oval (hình bầu dục) hoặc nằm trong hình chữ nhật của thực thể (theo chuẩn Chen hoặc Crow’s Foot).
- Thuộc tính khóa chính (Primary Key): Được ký hiệu bằng gạch chân hoặc dấu
PK. Đây là thuộc tính duy nhất xác định mỗi bản ghi. - Thuộc tính khóa ngoại (Foreign Key): Dùng để liên kết tới thực thể khác, thường được ký hiệu bằng dấu
FK. - Thuộc tính đa trị (Multivalued Attribute): Khi một thực thể có nhiều giá trị cho cùng một thuộc tính (ví dụ: số điện thoại của khách hàng), được vẽ bằng vòng tròn kép.
2.3. Quan hệ (Relationship)

Có thể bạn quan tâm: Cách Vẽ Emoji Bằng Paint: Hướng Dẫn Chi Tiết Từ A Đến Z
Quan hệ mô tả cách các thực thể tương tác với nhau. Ví dụ, Khách hàng đặt Đơn hàng. Quan hệ được biểu diễn bằng hình thoi (diamond) trong mô hình Chen, hoặc bằng các đường nối trong mô hình Crow’s Foot.
- Cardinality (Mức độ quan hệ): Xác định số lượng bản ghi của một thực thể có thể liên quan tới một bản ghi của thực thể khác. Các mức độ phổ biến:
- One-to-One (1:1) – Mỗi bản ghi ở thực thể A chỉ liên quan tới một bản ghi ở thực thể B và ngược lại.
- One-to-Many (1:N) – Một bản ghi ở thực thể A có thể liên quan tới nhiều bản ghi ở thực thể B, nhưng mỗi bản ghi B chỉ liên quan tới một bản ghi A.
-
Many-to-Many (M:N) – Nhiều bản ghi ở thực thể A có thể liên quan tới nhiều bản ghi ở thực thể B. Để biểu diễn M:N trong cơ sở dữ liệu quan hệ, chúng ta thường tạo một thực thể trung gian (junction table).
-
Participation (Tham gia):
- Total participation (Tham gia toàn phần) – Mọi bản ghi của thực thể phải tham gia vào quan hệ (đánh dấu bằng đường nét dày).
- Partial participation (Tham gia một phần) – Chỉ một phần các bản ghi tham gia (đánh dấu bằng đường nét mỏng).
3. Các bước chi tiết để vẽ một ERD chuẩn
Bước 1: Thu thập và phân tích yêu cầu nghiệp vụ
- Phỏng vấn người dùng: Hỏi về các quy trình kinh doanh, các thực thể quan trọng, các báo cáo cần thiết.
- Xem xét tài liệu hiện có: Các biểu mẫu, báo cáo, tài liệu hướng dẫn, hệ thống cũ.
- Xác định mục tiêu: Biết rõ mục đích của hệ thống (quản lý bán hàng, quản lý nhân sự, v.v.) để tập trung vào các thực thể và quan hệ cốt lõi.
Bước 2: Xác định các thực thể chính
- Liệt kê các danh mục: Từ yêu cầu, liệt kê các danh mục dữ liệu như
Khách hàng,Sản phẩm,Đơn hàng,Nhân viên,Kho. - Kiểm tra tính độc lập: Đảm bảo mỗi thực thể có thể tồn tại độc lập và có khóa chính duy nhất.
- Loại bỏ thực thể lặp lại: Nếu một thực thể có thể được biểu diễn dưới dạng thuộc tính của thực thể khác, hãy cân nhắc gộp chúng lại (ví dụ: địa chỉ có thể là thuộc tính của khách hàng nếu chỉ có một địa chỉ).
Bước 3: Xác định thuộc tính cho mỗi thực thể
- Liệt kê mọi thông tin cần lưu trữ cho mỗi thực thể.
- Phân biệt thuộc tính khóa:
- Primary Key: Chọn một hoặc nhiều trường duy nhất (thường là ID tự tăng hoặc mã số).
- Foreign Key: Các trường dùng để liên kết tới thực thể khác.
- Xác định tính chất:
- Không null (bắt buộc) hoặc có thể null (không bắt buộc).
- Độ dài, kiểu dữ liệu (VARCHAR, DATE, INT, …).
Bước 4: Xác định các quan hệ và mức độ (cardinality)
- Vẽ sơ đồ sơ khởi: Nối các thực thể bằng các đường thẳng, viết tên quan hệ lên thoi (hoặc trên đường nối).
- Xác định cardinality:
- Đối với mỗi quan hệ, xác định “một” hay “nhiều” ở cả hai phía.
- Dùng ký hiệu Crow’s Foot (mũi tên có ba chân) để biểu thị “nhiều”.
- Dùng ký hiệu “|” để biểu thị “một”.
- Ví dụ:
Khách hàng (1) ——< Đặt >—— (N) Đơn hàng.
Bước 5: Kiểm tra và chuẩn hoá (Normalization)

Có thể bạn quan tâm: Cách Vẽ Emoji Bằng Paint: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
- Kiểm tra chuẩn 1NF (First Normal Form): Mỗi ô trong bảng phải chứa một giá trị nguyên tố (không có tập hợp hoặc danh sách).
- Chuẩn 2NF: Tất cả các thuộc tính không khóa phải phụ thuộc toàn phần vào khóa chính.
- Chuẩn 3NF: Không có thuộc tính nào phụ thuộc bắc cầu vào khóa chính (phụ thuộc vào thuộc tính không khóa).
- Nếu có quan hệ M:N, tạo thực thể trung gian (junction table) và chuyển sang hai quan hệ 1:N.
Bước 6: Vẽ ERD chi tiết bằng công cụ
- Chọn công cụ: Lucidchart, draw.io, Microsoft Visio, MySQL Workbench, ER/Studio, hoặc các công cụ miễn phí như DBDesigner.
- Thiết lập mẫu: Đặt các thực thể, thuộc tính, quan hệ, ký hiệu cardinality, và nhãn rõ ràng.
- Kiểm tra lại: Đảm bảo không có thực thể lặp, không có thuộc tính thừa, và mọi quan hệ đã được biểu diễn đúng.
Bước 7: Rà soát và phê duyệt
- Rà soát với người dùng: Đưa ERD cho người dùng cuối, quản lý dự án, hoặc nhà phân tích nghiệp vụ để xác nhận tính đúng đắn.
- Cập nhật: Sửa đổi theo phản hồi, cập nhật tài liệu thiết kế.
4. Các quy tắc chuẩn hoá khi vẽ ERD
4.1. Quy tắc về tên thực thể và thuộc tính
- Tên thực thể: Dùng danh từ số nhiều hoặc số ít, nhưng đồng nhất trong toàn dự án (ví dụ:
CustomerhoặcCustomers– không nên dùng cả hai). - Tên thuộc tính: Dùng từ khóa mô tả ngắn gọn, không chứa ký tự đặc biệt, tránh trùng lặp với tên thực thể (ví dụ:
CustomerIDthay vìID).
4.2. Quy tắc về khóa chính
- Tên khóa chính thường là
<TênThựcThể>ID(ví dụ:ProductID). - Không sử dụng thông tin có ý nghĩa (như số CMND) làm khóa chính nếu có khả năng thay đổi.
4.3. Quy tắc về quan hệ M:N
- Tạo bảng trung gian: Ví dụ, quan hệ
Sinh viên–Môn học(M:N) sẽ tạo bảngStudentCoursevới các khóa ngoạiStudentIDvàCourseID, đồng thời có thể có thuộc tínhGrade. - Đặt tên bảng trung gian: Thường dùng dạng
<ThựcThể1>_<ThựcThể2>hoặc<ThựcThể1><ThựcThể2>.
4.4. Quy tắc về thuộc tính đa trị
- Nếu một thuộc tính có nhiều giá trị (ví dụ:
PhoneNumbercủa khách hàng), tạo một thực thể phụ (ví dụ:CustomerPhone) và liên kết 1:N.
4.5. Quy tắc về thuộc tính tính toán

Có thể bạn quan tâm: Cách Vẽ Ema Trên Mt4: Hướng Dẫn Chi Tiết Từ A Đến Z
- Các thuộc tính được tính toán (ví dụ:
TotalPrice = Quantity UnitPrice) không nên lưu trong bảng, thay vào đó tính khi truy vấn hoặc trong lớp dịch vụ.
5. Ví dụ thực tế: Vẽ ERD cho hệ thống bán hàng trực tuyến
5.1. Thu thập yêu cầu
- Quản lý khách hàng, sản phẩm, đơn hàng, giỏ hàng, và thanh toán.
- Mỗi khách hàng có thể có nhiều địa chỉ giao hàng.
- Một đơn hàng có thể chứa nhiều sản phẩm, mỗi sản phẩm có thể xuất hiện trong nhiều đơn hàng.
- Hệ thống cần lưu lịch sử thanh toán và trạng thái đơn hàng.
5.2. Xác định thực thể
| Thực thể | Mô tả |
|---|---|
| Customer | Thông tin khách hàng |
| Address | Địa chỉ giao hàng (nhiều địa chỉ cho một khách hàng) |
| Product | Thông tin sản phẩm |
| Order | Đơn hàng |
| OrderItem | Chi tiết đơn hàng (sản phẩm, số lượng, giá) |
| Payment | Thanh toán |
| Cart | Giỏ hàng tạm thời |
| CartItem | Chi tiết giỏ hàng |
5.3. Thuộc tính chi tiết
Customer
- CustomerID (PK)
- FirstName
- LastName
- Email (Unique)
- PhoneNumber
Address
- AddressID (PK)
- CustomerID (FK)
- Street
- City
- State
- ZipCode
- IsDefault
Product
- ProductID (PK)
- ProductName
- Description
- UnitPrice
- StockQuantity
Order
- OrderID (PK)
- CustomerID (FK)
- OrderDate
- ShippingAddressID (FK)
- OrderStatus (Pending, Shipped, Delivered, Cancelled)
OrderItem
- OrderItemID (PK)
- OrderID (FK)
- ProductID (FK)
- Quantity
- UnitPrice
- SubTotal (Quantity UnitPrice) – tính toán, không lưu
Payment
- PaymentID (PK)
- OrderID (FK)
- PaymentDate
- Amount
- PaymentMethod (CreditCard, PayPal, …)
- PaymentStatus (Paid, Failed)
Cart
- CartID (PK)
- CustomerID (FK)
- CreatedDate
CartItem
- CartItemID (PK)
- CartID (FK)
- ProductID (FK)
- Quantity
5.4. Quan hệ và cardinality
- Customer (1) —< Address (N): Một khách hàng có nhiều địa chỉ.
- Customer (1) —< Order (N): Một khách hàng có nhiều đơn hàng.
- Order (1) —< OrderItem (N): Một đơn hàng chứa nhiều dòng sản phẩm.
- Product (1) —< OrderItem (N): Một sản phẩm có thể xuất hiện trong nhiều đơn hàng.
- Order (1) —< Payment (N): Một đơn hàng có thể có nhiều thanh toán (trường hợp trả góp).
- Customer (1) —< Cart (1): Mỗi khách hàng chỉ có một giỏ hàng hiện tại.
- Cart (1) —< CartItem (N): Giỏ hàng chứa nhiều sản phẩm.
- Product (1) —< CartItem (N): Một sản phẩm có thể nằm trong nhiều giỏ hàng.
5.5. Vẽ sơ đồ (định dạng Crow’s Foot)
Customer ──|<------ Address | |<------ Order ──|<------ OrderItem ──> Product | | | |------> Payment | |------> Cart ──|<------ CartItem ──> Product
- Dấu “|<” biểu thị “một” ở phía thực thể bên trái và “nhiều” ở phía bên phải.
- Đường “>” biểu thị quan hệ 1:N hoặc M:N tùy vào thực thể trung gian.
5.6. Kiểm tra chuẩn hoá
- 1NF: Tất cả các bảng đều có giá trị nguyên tố, không có cột chứa danh sách.
- 2NF: Các thuộc tính không khóa phụ thuộc hoàn toàn vào khóa chính (ví dụ,
SubTotalkhông lưu, tính tại truy vấn). - 3NF: Không có phụ thuộc bắc cầu;
CustomerIDtrongOrderchỉ phụ thuộc vàoOrder, không phụ thuộc vàoAddress.
6. Các công cụ phổ biến để vẽ ERD

Có thể bạn quan tâm: Cách Vẽ Em Đến Trường: Hướng Dẫn Từng Bước Để Tạo Ra Một Bức Tranh Đầy Cảm Xúc
| Công cụ | Ưu điểm | Nhược điểm | Giá |
|---|---|---|---|
| MySQL Workbench | Tích hợp trực tiếp với MySQL, hỗ trợ reverse engineering | Giao diện hơi cồng kềnh | Miễn phí |
| draw.io (diagrams.net) | Web-based, không cần cài đặt, hỗ trợ xuất PNG, SVG | Không có tính năng tự động reverse engineering | Miễn phí |
| Lucidchart | Giao diện hiện đại, cộng tác thời gian thực | Giới hạn trong phiên bản miễn phí | Gói trả phí |
| Microsoft Visio | Tích hợp Office, nhiều mẫu chuẩn | Chi phí cao, không chuyên cho DB | Trả phí |
| ER/Studio | Công cụ chuyên nghiệp, hỗ trợ nhiều DBMS | Phức tạp, giá thành cao | Trả phí |
| DbSchema | Hỗ trợ nhiều DB, auto layout | Giao diện hơi lạ đối với người mới | Có phiên bản trả phí và miễn phí |
Lưu ý khi chọn công cụ: Nếu dự án nhỏ hoặc học tập, draw.io hoặc MySQL Workbench là đủ. Đối với dự án doanh nghiệp lớn, nên cân nhắc Lucidchart hoặc ER/Studio để tận dụng tính năng cộng tác và quản lý phiên bản.
7. Các lỗi thường gặp khi vẽ ERD và cách khắc phục
- Nhầm lẫn giữa thực thể và thuộc tính
- Triệu chứng: Vẽ một thuộc tính như một thực thể độc lập.
-
Khắc phục: Kiểm tra xem đối tượng có tồn tại độc lập không; nếu không, chuyển thành thuộc tính.
-
Quên tạo bảng trung gian cho quan hệ M:N
- Triệu chứng: Khi triển khai, gặp lỗi khóa ngoại hoặc dữ liệu không thể lưu.
-
Khắc phục: Tạo bảng junction (ví dụ:
StudentCourse) và chuyển quan hệ sang 1:N. -
Sử dụng khóa chính không ổn định
- Triệu chứng: Khóa chính dựa trên thông tin có thể thay đổi (như email).
-
Khắc phục: Dùng surrogate key (ID tự tăng) làm PK, lưu thông tin thay đổi dưới dạng thuộc tính.
-
Lãng quên quan hệ bắt buộc (total participation)
- Triệu chứng: Một thực thể có thể tồn tại mà không có bản ghi liên quan, gây logic lỗi.
-
Khắc phục: Đánh dấu quan hệ bắt buộc bằng đường nét dày và thiết lập ràng buộc NOT NULL trên khóa ngoại.
-
Ràng buộc không đồng nhất giữa các bảng
- Triệu chứng: Khi cập nhật một bản ghi, các bảng liên quan không đồng bộ.
- Khắc phục: Sử dụng cascade update/delete hoặc viết trigger để duy trì tính toàn vẹn.
8. Thực hành: Bước-by-bước vẽ ERD bằng draw.io
8.1. Chuẩn bị
- Truy cập https://app.diagrams.net/
- Chọn “Device” để lưu file cục bộ hoặc “Google Drive” để lưu đám mây.
- Chọn Blank Diagram → Đặt tên “ERD_BanHang”.
8.2. Tạo thực thể
- Kéo Rectangle từ thanh công cụ “General”.
- Đổi tên thành “Customer”.
- Nhấn Ctrl + D để sao chép và tạo các thực thể còn lại:
Address,Product,Order,OrderItem,Payment,Cart,CartItem.
8.3. Thêm thuộc tính
- Chọn thực thể “Customer”.
-
Nhấn Text → Gõ danh sách thuộc tính, mỗi dòng một thuộc tính, ký hiệu PK bằng
PKhoặc gạch chân.
PK CustomerID FirstName LastName Email PhoneNumber
Cách Vẽ Entity Relationship Diagram -
Lặp lại cho các thực thể khác.
8.4. Vẽ quan hệ
- Chọn công cụ Connector (đường nối).
- Kết nối “Customer” tới “Address”.
- Khi thả, double-click vào đường nối để nhập tên quan hệ (ví dụ: “has”).
- Để biểu diễn cardinality, vào Format → Shape → Line → Arrow và chọn Crow’s Foot cho phía “many”.
8.5. Đánh dấu cardinality
- Click vào đường nối → Style → Line End → Chọn “One” (dòng thẳng) cho phía “one”, “Many” (Crow’s Foot) cho phía “many”.
- Lặp lại cho các quan hệ còn lại.
8.6. Kiểm tra và lưu
- Kiểm tra các thực thể, thuộc tính, quan hệ có đúng không.
- Nhấn File → Export As → PNG hoặc PDF để lưu bản vẽ.
- Đặt tên file “ERD_BanHang_Final”.
9. Tài liệu tham khảo và nguồn học thêm
- “Database System Concepts” – Abraham Silberschatz, Henry F. Korth, S. Sudarshan – Chương 7 về thiết kế dữ liệu.
- “Data Modeling Made Simple” – Steve Hoberman – Hướng dẫn thực tiễn về ERD.
- Trang chính của Crow’s Foot Notation – https://www.crow-foot.com/
- MySQL Workbench Documentation – https://dev.mysql.com/doc/workbench/en/
- Video tutorial: “How to Design an ER Diagram” trên YouTube – Kênh “The Coding Train” và “Academind”.
10. Kết luận
Việc vẽ Entity Relationship Diagram không chỉ là một bước kỹ thuật trong thiết kế cơ sở dữ liệu, mà còn là cầu nối quan trọng giữa nhà phân tích nghiệp vụ và lập trình viên. Khi thực hiện đúng quy trình – từ việc thu thập yêu cầu, xác định thực thể, thuộc tính, quan hệ, chuẩn hoá, cho tới việc sử dụng công cụ hỗ trợ – bạn sẽ có một mô hình dữ liệu sạch, logic, dễ bảo trì và mở rộng.
Hãy nhớ:
- Luôn bắt đầu bằng yêu cầu thực tế: Không vội vã thiết kế mà chưa hiểu rõ quy trình kinh doanh.
- Tuân thủ chuẩn hoá: Giảm thiểu dư thừa và lỗi dữ liệu.
- Sử dụng ký hiệu chuẩn (Crow’s Foot hoặc Chen) để mọi người trong dự án có thể đọc hiểu nhanh.
- Kiểm tra, rà soát và phê duyệt: Đảm bảo mô hình được đồng thuận trước khi triển khai.
- Lựa chọn công cụ phù hợp: Tùy vào quy mô dự án và ngân sách.
Với những kiến thức và hướng dẫn chi tiết ở trên, bạn hoàn toàn có thể tự tin thiết kế ERD cho bất kỳ hệ thống nào, từ các dự án nhỏ đến các ứng dụng doanh nghiệp phức tạp. Chúc bạn thành công trong việc xây dựng những mô hình dữ liệu vững chắc và tối ưu!
