Tổng quan về ERD và 5 bước đọc file ERD
Mục lục
Giới thiệu
ERD (Entity–Relationship Diagram) có thể hiểu đơn giản là “bản đồ dữ liệu” của một hệ thống. Ví dụ, khi một ứng dụng cần lưu thông tin như khách hàng, đơn hàng, sản phẩm hay lớp học, cơ sở dữ liệu sẽ phải được thiết kế sao cho dữ liệu không bị trùng lặp, dễ tìm kiếm và dễ mở rộng. ERD được dùng ở bước đầu của quá trình thiết kế để mô tả hệ thống sẽ có những bảng nào, mỗi bảng lưu những thông tin gì và các bảng liên kết với nhau ra sao. ERD hữu ích vì nó giúp nhìn thấy cấu trúc dữ liệu theo cách trực quan, từ đó hiểu logic của database.
Khái niệm ERD và thành phần chính trong ERD
ERD (Entity–Relationship Diagram) là sơ đồ mô tả các thực thể (entities) cần quản lý, thuộc tính (attributes) của thực thể, và các mối quan hệ (relationships) giữa các thực thể
Thành phần chính trong ERD:
- Thực thể (Entity): các đối tượng hoặc khái niệm cần lưu dữ liệu (thường tương ứng với bảng trong CSDL quan hệ). Ví dụ như Customer (Khách hàng), Order (Đơn hàng), Product (Sản phẩm)
- Thuộc tính (Attribute): Mỗi bảng sẽ có các thuộc tính, tức là “cột” (column), ví dụ Customer có Name, Email, Phone.
- PK (Primary Key) = Khóa chính: mã duy nhất cho mỗi dòng trong bảng
Ví dụ: CustomerID là PK ⇒ không có 2 khách hàng trùng CustomerID. - FK (Foreign Key) = Khóa ngoại: cột dùng để trỏ sang bảng khác
Ví dụ: Order có CustomerID (FK) để biết đơn này thuộc khách hàng nào. - UK/Unique key: đảm bảo giá trị không trùng lặp nhưng không nhất thiết là PK (Có thể có hoặc không)
Ví dụ: Trong bảng Customer, email không phải khóa chính nhưng không trùng nhau
- PK (Primary Key) = Khóa chính: mã duy nhất cho mỗi dòng trong bảng
- Mối quan hệ (Relationship): cách các thực thể liên kết với nhau (tương ứng với quan hệ giữa các bảng thông qua khóa).
Mối quan hệ và lực lượng tham gia (Relationship, Cardinality & Ordinality)
Một quan hệ mô tả cách hai bảng/thực thể (entities) liên kết với nhau. Bội số tối đa(cardinality) cho biết số lượng bản ghi tối đa liên quan:
- 1–1 (One-to-One): mỗi bản ghi A tương ứng tối đa một bản ghi B. Ví dụ: Một khách hàng chỉ có 1 một số điện thoại, một số điện thoại thuộc về 1 khách hàng.
- 1–N (One-to-Many): một bản ghi A có thể liên quan nhiều bản ghi B. Ví dụ: một khách hàng có thể có nhiều đơn hàng, nhưng mỗi đơn hàng thường chỉ thuộc về một khách hàng.
- N–N (Many-to-Many): nhiều A liên quan nhiều B. Ví dụ: Một đơn hàng có nhiều sản phẩm và một sản phẩm có thể xuất hiện trong nhiều đơn hàng
Mức tối thiểu(Ordinality) cho biết tối thiểu có bao nhiêu bản ghi liên quan:
| Optional – 0: Có thể có hoặc không | 0..1 – có thể không có bản ghi liên quan; nếu có thì chỉ 1 |
| 0..N – có thể không có; nếu có thì có thể nhiều | |
| Mandatory – 1: Bắt buộc phải có | 1..1 – bắt buộc phải có đúng 1 bản ghi liên quan |
| 1..N – bắt buộc có ít nhất 1; và có thể nhiều |
Trong thực hành cơ sở dữ liệu quan hệ, quan hệ N–N thường không triển khai trực tiếp mà cần bảng trung gian (junction/associative table) chứa ít nhất hai FK trỏ về hai bảng gốc. Đây là quy tắc nền tảng để biểu diễn chính xác mối quan hệ N-N khi hiện thực hóa.
Cách đọc file ERD
Khi nói “đọc file ERD”, thực chất bạn đang đọc một sơ đồ để hiểu cấu trúc database. Dù file ERD là ảnh, PDF, Lucidchart, draw.io hay MySQL Workbench, cách đọc hiệu quả vẫn giống nhau. Khi đọc một file ERD, bạn nên xem nó như một “câu chuyện dữ liệu” thay vì cố học thuộc ký hiệu ngay lập tức.
Bước 1: Nhìn toàn sơ đồ để liệt kê các bảng chính. Bạn chỉ cần đọc tên bảng và tự đoán vai trò của chúng theo nghĩa tiếng Anh/logic nghiệp vụ, ví dụ Customer là khách hàng, Order là đơn hàng. Mục tiêu của bước này là để bạn có “bản đồ tổng thể” và không bị lạc khi ERD có nhiều bảng.
Bước 2: Tìm khóa chính (PK) của từng bảng. PK giống như “số căn cước” của bảng: mỗi dòng dữ liệu phải có một giá trị PK riêng. Khi bạn xác định PK, bạn sẽ hiểu được đâu là cột quan trọng nhất của bảng đó và các bảng khác sẽ thường “trỏ” vào cột này.
Bước 3: Tìm khóa ngoại (FK) và xem nó trỏ đi đâu. Nguyên tắc đơn giản: cột nào là FK thì nó đang “mượn ID” của bảng khác để nói rằng dữ liệu này có liên quan. Ví dụ, nếu bảng Order có cột CustomerID, bạn hiểu ngay: mỗi đơn hàng thuộc về một khách hàng. Nói cách khác, bảng chứa FK thường là bảng “bên phụ thuộc” trong mối quan hệ.
Bước 4: Đọc cardinality/ordinality để hiểu đúng ràng buộc giữa các bảng
Bước 5: Nhận diện quan hệ N–N và kiểm tra bảng trung gian. Nếu ERD có quan hệ nhiều–nhiều, hãy tìm bảng trung gian (ví dụ OrderItem) chứa hai FK (OrderID, ProductID) và các thuộc tính thuộc về quan hệ (ví dụ Quantity). Đây là bước quyết định để bạn truy vấn đúng và tránh “gắn nhầm thuộc tính” vào sai bảng.
Các lỗi thường gặp khi đọc ERD
- Nhầm 1-N thành N-N → dẫn đến thiếu bảng trung gian hoặc thiết kế sai đường join.
- Bỏ qua ordinality (0 hay 1) → hiểu sai “bắt buộc/tùy chọn”, kéo theo sai ràng buộc NULL và sai nghiệp vụ.
- Chỉ nhìn tên bảng mà không đọc PK/FK → join nhầm cột, đặc biệt khi nhiều bảng đều có các cột “ID” giống nhau.
- Không phân biệt thuộc tính của thực thể và thuộc tính của quan hệ → ví dụ Quantity thuộc về bảng trung gian (quan hệ), không thuộc riêng Order hay Product
Kết luận
ERD là công cụ nền tảng để mô hình hóa dữ liệu, giúp mô tả thực thể, thuộc tính và quan hệ một cách có cấu trúc trước khi triển khai thành cơ sở dữ liệu quan hệ. Để “đọc file ERD” hiệu quả, người học cần xác định notation, tìm PK/FK, đọc cardinality/ordinality và đặc biệt nhận diện đúng quan hệ N–N thông qua bảng trung gian. Khi thực hiện đúng quy trình này, ERD hỗ trợ kiểm tra logic nghiệp vụ và xây dựng truy vấn SQL chính xác.
