ERD Là Gì? Cách Đọc Sơ Đồ Dữ Liệu Như Đọc Bản Đồ

Lần đầu nhìn vào một file ERD, hàng chục ô vuông nối nhau bằng những đường có ký hiệu kỳ lạ ở hai đầu, nhiều người tự hỏi: "Cái này đọc như thế nào? Và tại sao mình cần biết?"

Thực ra ERD không hề phức tạp. Nó chỉ là bản đồ của một cơ sở dữ liệu và đọc bản đồ thì ai cũng học được. Bài viết này sẽ giải thích ERD từ con số 0, không dùng thuật ngữ kỹ thuật khó hiểu, chỉ dùng ví dụ từ cuộc sống hàng ngày.

ERD Là Gì? Giải Thích Bằng Analogy Đời Thường

ERD là viết tắt của Entity–Relationship Diagram – dịch sát nghĩa là Sơ đồ Thực thể – Mối quan hệ.

Tuy nhiên, tên gọi đó nghe có vẻ khô khan. Cách hiểu thực tế nhất là:

ERD là bản đồ thiết kế của một cơ sở dữ liệu cho thấy hệ thống đó lưu trữ những loại thông tin gì, mỗi loại thông tin có những trường dữ liệu nào, và các loại thông tin đó liên kết với nhau ra sao.

Ví dụ dễ hiểu: Trước khi xây một tòa nhà, kiến trúc sư phải vẽ bản thiết kế: phòng nào ở đâu, cửa nào thông sang đâu, chỗ nào đặt điện nước. Không ai xây nhà mà không có bản vẽ.

Cơ sở dữ liệu cũng vậy. Trước khi lập trình viên viết code, trước khi Data Analyst bắt đầu truy vấn SQL, cần có ai đó thiết kế trước: "Hệ thống này cần lưu những bảng dữ liệu nào? Mỗi bảng có những cột nào? Bảng A và bảng B kết nối với nhau qua cột nào?" và ERD chính là tờ giấy ghi lại toàn bộ thiết kế đó.

Ai Cần Đọc ERD?

ERD không chỉ dành cho kỹ sư phần mềm. Trên thực tế, nhiều vai trò khác cần đọc được ERD để làm việc hiệu quả:

Data Analyst / Business Analyst: Khi cần viết SQL để lấy dữ liệu, bạn phải biết dữ liệu nằm ở bảng nào, cột nào, và cần JOIN những bảng gì với nhau. ERD cho bạn câu trả lời trong vài giây thay vì phải mò mẫm từng bảng.

Product Manager: Khi thảo luận về tính năng mới với đội kỹ thuật, hiểu ERD giúp bạn đặt câu hỏi đúng: "Để hiển thị thông tin này, chúng ta cần thêm trường dữ liệu nào?"

Developer mới vào dự án: Thay vì đọc hàng nghìn dòng code để hiểu hệ thống, đọc ERD cho bức tranh tổng thể trong 15 phút.

Người học SQL: Hiểu ERD giúp bạn viết câu lệnh JOIN chính xác, không bị lạc giữa hàng chục bảng dữ liệu.

Ba Thành Phần Chính Của Một ERD

Mọi ERD, dù đơn giản hay phức tạp, đều được xây dựng từ 3 thành phần cơ bản:

Thực Thể (Entity): Các "Nhân Vật" Trong Hệ Thống

Thực thể là bất kỳ đối tượng, khái niệm nào mà hệ thống cần lưu thông tin về nó. Trong ERD, thực thể được biểu diễn bằng hình chữ nhật với tên bên trong.

Ví dụ: Một hệ thống bán hàng sẽ có các thực thể như:

• Khách hàng: lưu thông tin người mua

• Sản phẩm: lưu thông tin hàng hóa

• Đơn hàng: lưu thông tin giao dịch

• Nhân viên: lưu thông tin người bán

Cách nhớ nhanh: Thực thể thường là danh từ: người, vật, địa điểm, sự kiện mà bạn muốn theo dõi và lưu lại.

Thuộc Tính (Attribute): Chi Tiết Của Mỗi Thực Thể

Thuộc tính là các thông tin cụ thể của một thực thể, tương ứng với các cột (column) trong bảng dữ liệu.

Ví dụ: Thực thể Khách hàng có các thuộc tính:

• Mã khách hàng

• Họ tên

• Email

• Số điện thoại

• Địa chỉ

• Ngày đăng ký

Trong ERD, thuộc tính thường được liệt kê bên trong hoặc bên dưới hình chữ nhật của thực thể.

Mối Quan Hệ (Relationship): Cách Các Thực Thể Liên Kết

Mối quan hệ mô tả cách hai thực thể kết nối với nhau được biểu diễn bằng đường thẳng nối giữa hai hình chữ nhật, thường có nhãn là một động từ.

Ví dụ:

• Khách hàng đặt Đơn hàng

• Đơn hàng chứa Sản phẩm

• Nhân viên xử lý Đơn hàng

PK và FK: Chìa Khóa Để Hiểu Mọi ERD

Hai khái niệm này xuất hiện ở khắp nơi trong ERD. Nếu hiểu được PK và FK, bạn đã giải mã được 70% bất kỳ sơ đồ nào.

PK: Khóa Chính (Primary Key)

PK là cột định danh duy nhất cho mỗi dòng trong một bảng. Không có hai dòng nào trong bảng được có cùng giá trị PK.

Trong ERD, PK thường được in đậm, có gạch chân hoặc được đánh dấu bằng biểu tượng chìa khóa.

Ví dụ:

• Bảng Khách hàng có PK là MaKhachHang – mỗi khách hàng có một mã riêng, không trùng ai

• Bảng Sản phẩm có PK là MaSanPham

• Bảng Đơn hàng có PK là MaDonHang

Quy tắc PK: Không bao giờ để trống (NULL), không bao giờ trùng lặp, mỗi bảng chỉ có đúng một PK.

FK: Khóa Ngoại (Foreign Key)

FK là cột trong bảng A dùng để tham chiếu đến PK của bảng B, đây chính là cách hai bảng "biết nhau" và kết nối được với nhau.

Ví dụ: Bảng Đơn hàng có cột MaKhachHang, đây là FK tham chiếu đến PK MaKhachHang của bảng Khách hàng. Nhờ đó, mỗi đơn hàng biết nó thuộc về khách hàng nào.

Bảng	Vai trò	Ý nghĩa
Khách hàng	MaKhachHang = PK	Định danh từng khách hàng
Đơn hàng	MaKhachHang = FK	Chỉ ra đơn này của khách nào

Mối liên hệ với SQL: Khi bạn viết JOIN ... ON kh.id = dh.id_khach, thực ra bạn đang nối PK của bảng Khách hàng với FK của bảng Đơn hàng – đúng như ERD đã thiết kế sẵn!

Ba Kiểu Quan Hệ Trong ERD

Đây là phần quan trọng nhất và cũng là phần nhiều người hay nhầm nhất. Mỗi mối quan hệ trong ERD có thể thuộc một trong ba kiểu sau:

Quan Hệ Một - Một (1:1 / One-to-One)

Một bản ghi ở bảng A tương ứng với đúng một bản ghi ở bảng B, và ngược lại.

Ví dụ thực tế: Mỗi công dân có đúng một số Căn cước công dân. Một số CCCD chỉ thuộc về đúng một công dân.

Trong kinh doanh: Mỗi nhân viên có đúng một hồ sơ lương. Mỗi hồ sơ lương thuộc về đúng một nhân viên.

Kiểu quan hệ này ít gặp nhất trong thực tế vì nếu hai thực thể có quan hệ 1:1, người ta thường gộp chúng vào một bảng cho đơn giản.

Quan Hệ Một – Nhiều (1:N / One-to-Many)

Một bản ghi ở bảng A có thể liên kết với nhiều bản ghi ở bảng B, nhưng một bản ghi ở bảng B chỉ liên kết với đúng một bản ghi ở bảng A.

Ví dụ thực tế:

• Một khách hàng có thể đặt nhiều đơn hàng, nhưng mỗi đơn hàng chỉ thuộc về một khách hàng

• Một giáo viên dạy nhiều học sinh, nhưng mỗi học sinh thuộc một lớp (trong trường hợp 1 lớp – 1 giáo viên chủ nhiệm)

• Một danh mục sản phẩm chứa nhiều sản phẩm, nhưng mỗi sản phẩm thuộc một danh mục

Đây là kiểu quan hệ phổ biến nhất trong bất kỳ cơ sở dữ liệu nào.

Quan Hệ Nhiều – Nhiều (N:N / Many-to-Many)

Nhiều bản ghi ở bảng A có thể liên kết với nhiều bản ghi ở bảng B, và ngược lại.

Ví dụ thực tế:

• Một đơn hàng có thể chứa 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ột sinh viên đăng ký nhiều môn học, và một môn học có nhiều sinh viên

• Một diễn viên đóng nhiều bộ phim, và một bộ phim có nhiều diễn viên

Điểm cực kỳ quan trọng: Trong thực tế, quan hệ N:N không thể lưu trực tiếp vào cơ sở dữ liệu. Cần tạo thêm một bảng trung gian để xử lý. Ví dụ: quan hệ N:N giữa Đơn hàng và Sản phẩm được giải quyết bằng bảng Chi tiết đơn hàng (có cột MaDonHang và MaSanPham).

Ký Hiệu Crow's Foot: Đọc Các Đường Nối

Phần ký hiệu trên đường nối giữa các thực thể khiến nhiều người bối rối. Loại ký hiệu phổ biến nhất hiện nay là Crow's Foot (chân quạ) có hình dạng như chân của con quạ ở đầu đường nối.

Cách Đọc Ký Hiệu Crow's Foot

Mỗi đầu đường nối có 2 ký hiệu xếp cạnh nhau, đọc từ ngoài vào trong:

• Ký hiệu ngoài cùng: Cho biết tối thiểu bao nhiêu bản ghi (bắt buộc hay không)

• Ký hiệu trong: Cho biết tối đa bao nhiêu bản ghi

Ký hiệu	Ý nghĩa
Gạch ngang — (ngoài cùng)	Bắt buộc phải có ít nhất 1
Vòng tròn O (ngoài cùng)	Không bắt buộc (có thể là 0)
Gạch ngang — (trong)	Tối đa là 1
Chân quạ > (trong)	Tối đa là nhiều

Đọc thực tế:

Đường nối từ Khách hàng sang Đơn hàng có ký hiệu:

• Phía Khách hàng: — và — → Mỗi đơn hàng thuộc về bắt buộc đúng 1 khách hàng

• Phía Đơn hàng: O và > → Một khách hàng có thể có 0 đến nhiều đơn hàng (khách mới chưa mua thì có 0 đơn)

Mẹo đọc nhanh: Luôn đọc từ thực thể A sang thực thể B, đọc ký hiệu ở phía gần thực thể B trước. "Một khách hàng có thể có... [nhìn ký hiệu phía đơn hàng] ...nhiều đơn hàng".

Năm Bước Đọc Một File ERD Từ Đầu Đến Cuối

Khi gặp một ERD mới, thay vì nhìn vào tổng thể và bị choáng ngợp, hãy đi theo 5 bước sau:

Bước 1: Xác Định Notation Đang Dùng

Trước tiên, hãy nhìn qua toàn bộ sơ đồ để xác định loại ký hiệu. Hai loại phổ biến nhất là:

• Crow's Foot (chân quạ): Phổ biến nhất, dùng trong hầu hết các công cụ hiện đại

• Chen Notation: Dùng hình thoi cho mối quan hệ, ít phổ biến hơn

Nếu nhìn thấy ký hiệu chân quạ ở đầu các đường nối → đây là Crow's Foot.

Bước 2: Liệt Kê Tất Cả Thực Thể (Bảng)

Đếm có bao nhiêu hình chữ nhật trong sơ đồ, đọc tên từng bảng. Đây giúp bạn biết hệ thống này lưu những loại dữ liệu gì.

Ví dụ: Thấy 6 bảng gồm Khách hàng, Đơn hàng, Chi tiết đơn hàng, Sản phẩm, Danh mục, Nhân viên → đây là hệ thống bán lẻ.

Bước 3: Tìm PK Và FK Của Mỗi Bảng

Với mỗi bảng, xác định:

• Cột nào là PK (thường in đậm hoặc có icon chìa khóa)?

• Cột nào là FK (thường được đánh dấu riêng)?

FK của bảng này chỉ đến PK của bảng nào? Đây chính là "cầu nối" giữa các bảng.

Bước 4: Đọc Từng Mối Quan Hệ Và Cardinality

Với mỗi đường nối giữa hai bảng:

• Đọc nhãn trên đường nối (động từ mô tả quan hệ)

• Đọc ký hiệu ở hai đầu theo cú pháp: "Một [bảng A] có thể... [ký hiệu] ...[bảng B]"

Ví dụ đọc: "Một Khách hàng có thể có 0 đến nhiều Đơn hàng. Mỗi Đơn hàng bắt buộc thuộc về đúng 1 Khách hàng."

Bước 5: Nhận Diện Bảng Trung Gian (N:N Junction Table)

Tìm các bảng có hai FK trỏ đến hai bảng khác nhau, đây là dấu hiệu của bảng trung gian giải quyết quan hệ nhiều-nhiều.

Ví dụ: Bảng Chi_tiet_don_hang có MaDonHang (FK đến Đơn hàng) và MaSanPham (FK đến Sản phẩm) → đây là bảng trung gian giải quyết quan hệ N:N giữa Đơn hàng và Sản phẩm.

Ví Dụ Thực Tế: ERD Hệ Thống Bán Hàng Online

Hãy áp dụng 5 bước vào một ERD thực tế của hệ thống bán hàng online:

Các bảng trong hệ thống:

Bảng	PK	FK	Mô tả
Khách_hàng	id_kh	–	Thông tin người mua
Đơn_hàng	id_don	id_kh → Khách_hàng	Thông tin mỗi lần mua
Chi_tiet_don	id_chitiet	id_don, id_sp	Bảng trung gian N:N
Sản_phẩm	id_sp	id_danhmuc → Danh_mục	Thông tin hàng hóa
Danh_mục	id_danhmuc	–	Phân loại sản phẩm
Nhân_viên	id_nv	–	Người xử lý đơn

Các mối quan hệ:

• Khách hàng (1:N) Đơn hàng: Một khách có thể đặt nhiều đơn

• Đơn hàng (N:N) Sản phẩm (qua bảng Chi_tiet_don): Một đơn có nhiều sản phẩm, một sản phẩm xuất hiện trong nhiều đơn

• Danh_mục (1:N) Sản phẩm: Một danh mục chứa nhiều sản phẩm

• Nhân viên (1:N) Đơn hàng: Một nhân viên xử lý nhiều đơn

Câu SQL tương ứng khi cần báo cáo "Doanh thu theo khách hàng":

sql

SELECT 
    kh.ten_khach_hang,
    COUNT(dh.id_don) AS so_don,
    SUM(ct.so_luong * sp.gia) AS tong_doanh_thu
FROM Khach_hang kh
LEFT JOIN Don_hang dh ON kh.id_kh = dh.id_kh
LEFT JOIN Chi_tiet_don ct ON dh.id_don = ct.id_don
LEFT JOIN San_pham sp ON ct.id_sp = sp.id_sp
GROUP BY kh.ten_khach_hang
ORDER BY tong_doanh_thu DESC;

Nhờ đọc được ERD, bạn biết ngay cần JOIN 4 bảng theo thứ tự nào và nối qua cột nào – không cần đoán mò.

ERD Và SQL: Mối Liên Hệ Quan Trọng

ERD và SQL là hai công cụ bổ trợ hoàn hảo cho nhau:

ERD → SQL: Khi viết câu lệnh JOIN, bạn thực ra đang thực thi đúng mối quan hệ đã vẽ trong ERD. FK trong ERD chính là cột ON trong câu lệnh JOIN.

SQL → ERD: Khi gặp lỗi SQL hoặc kết quả sai, nhìn lại ERD giúp phát hiện ngay bạn đang JOIN sai bảng hoặc sai cột.

Xem thêm:

• SQL là gì?

• JOIN trong SQL là gì?

Công Cụ Vẽ ERD Phổ Biến Nhất

Bạn không cần vẽ ERD bằng tay. Các công cụ sau đây hỗ trợ vẽ ERD nhanh, đẹp và chuyên nghiệp:

Công cụ	Đặc điểm	Phù hợp với
Lucidchart	Trực quan, dễ dùng, có bản miễn phí	DA, BA, người mới học
draw.io / diagrams.net	Hoàn toàn miễn phí, tích hợp Google Drive	Tất cả đối tượng
dbdiagram.io	Vẽ ERD bằng code đơn giản, nhẹ và nhanh	Developer, DA biết cơ bản
MySQL Workbench	Tự động tạo ERD từ database thực	Developer, DBA
DBeaver	Xem ERD trực tiếp từ database đang kết nối	DA, Developer

Khuyến nghị cho người mới: Bắt đầu tại đây, bạn chỉ cần gõ tên bảng, tên cột và mối quan hệ theo cú pháp đơn giản, công cụ tự vẽ ra ERD đẹp. Không cần kéo thả phức tạp.

Lỗi Thường Gặp Khi Đọc ERD

Lỗi 1: Nhầm Chiều Đọc Cardinality

Nhiều người đọc ký hiệu theo chiều sai. Ký hiệu ở phía bảng B cho biết "Một bản ghi của bảng A có thể liên kết với bao nhiêu bản ghi của bảng B", không phải ngược lại.

Lỗi 2: Bỏ Qua Bảng Trung Gian Khi JOIN

Khi thấy ERD có quan hệ N:N giữa Đơn hàng và Sản phẩm (qua bảng Chi tiết đơn hàng), nhiều người vẫn cố JOIN thẳng Đơn hàng với Sản phẩm mà bỏ qua bảng trung gian → kết quả sai.

sql

-- SAI: Bỏ qua bảng trung gian
SELECT * FROM don_hang dh
JOIN san_pham sp ON ???  -- Không có FK trực tiếp!

-- ĐÚNG: Đi qua bảng trung gian
SELECT * FROM don_hang dh
JOIN chi_tiet_don ct ON dh.id_don = ct.id_don
JOIN san_pham sp ON ct.id_sp = sp.id_sp

Lỗi 3: Nhầm PK Và FK

Khi thấy hai cột có cùng tên ở hai bảng (ví dụ MaKhachHang ở cả bảng Khách_hàng và Đơn_hàng), nhiều người không phân biệt được cái nào là PK, cái nào là FK. Nguyên tắc đơn giản: PK nằm ở bảng "cha" (bảng chứa thông tin gốc), FK nằm ở bảng "con" (bảng tham chiếu).

Lỗi 4: Không Đọc Tính Bắt Buộc (Ordinality)

Ký hiệu vòng tròn O cho biết mối quan hệ là không bắt buộc (có thể là 0). Nếu bỏ qua điều này, bạn có thể dùng INNER JOIN trong khi đáng lẽ phải dùng LEFT JOIN dẫn đến mất dữ liệu của những khách hàng chưa có đơn hàng nào.

Tóm lại, ERD là bản đồ dữ liệu của hệ thống giúp bạn thấy toàn bộ cấu trúc của một cơ sở dữ liệu mà không cần nhìn vào từng dòng code hay từng bảng riêng lẻ.

Những điểm cốt lõi cần nhớ:

• Thực thể = bảng trong cơ sở dữ liệu

• Thuộc tính = cột trong bảng

• PK = cột định danh duy nhất; FK = cầu nối sang bảng khác

• Ba kiểu quan hệ: 1:1, 1:N (phổ biến nhất), N:N (cần bảng trung gian)

• Ký hiệu Crow's Foot: đọc từ ngoài vào trong, từ bảng A sang bảng B

Sau khi đọc hiểu ERD, bước tiếp theo là thực hành viết SQL, đặc biệt là câu lệnh JOIN để biến "bản đồ trên giấy" thành dữ liệu thực tế phục vụ phân tích kinh doanh.

Truy cập ngay Mastering Data Analytics để đọc thêm nhiều bài viết thú vị về SQL, phân tích dữ liệu và Data Analytics!

"Mastering Data Analytics - TIÊN PHONG mở ra chương trình Agentic AI Analytics LẦN ĐẦU TIÊN tại Việt Nam"

Với mọi thắc mắc bạn có thể liên hệ Zalo 0961 48 66 48 để được tư vấn miễn phí. Hoặc bạn có thể inbox fanpage Mastering Data Analytics tham khảo lịch khai giảng sớm nhất!

CHI TIẾT KHÓA HỌC: tại đây