Mở đầu — vì sao bài này quan trọng
Có một câu chuyện tôi hay kể cho học viên mới: một BA fresher tại một công ty fintech ở Quận 1 (TP.HCM) viết một user story rất đẹp — "Là khách hàng, tôi muốn xem lịch sử giao dịch của mình để đối soát chi tiêu". Story được dev nhận, làm, demo. Nhưng khi lên môi trường thật, khách hàng có hai tài khoản (một ví, một thẻ tín dụng) thì màn hình lịch sử... trộn lẫn cả hai, không tách được. Lỗi không nằm ở dev. Lỗi nằm ở chỗ BA không mô tả rõ một khách hàng có thể có nhiều tài khoản, và mỗi giao dịch thuộc về đúng một tài khoản nào. Đó chính là data model — và nếu BA hiểu ERD, cuộc họp làm rõ requirement đã bắt được lỗ hổng này từ đầu.
Với BA fresher, có một hiểu lầm phổ biến: "Data model là việc của dev và DBA, mình chỉ cần lo nghiệp vụ". Sai. Data model chính là nghiệp vụ được viết dưới dạng cấu trúc. Khi bạn nói "một đơn hàng có nhiều sản phẩm", "một nhân viên chỉ thuộc một phòng ban", "một khách hàng có thể để lại nhiều đánh giá" — bạn đang mô tả quan hệ dữ liệu. ERD (Entity-Relationship Diagram) chỉ là cách vẽ những câu đó ra thành hình cho ai cũng nhìn thấy và không cãi nhau được.
Bài này sẽ trang bị cho bạn đúng mức mà một BA junior cần: đọc được ERD, vẽ được ERD ở mức khái niệm, và dùng nó như một công cụ để làm rõ requirement với stakeholder và dev — chứ không phải để thay thế DBA thiết kế database vật lý.
Khái niệm cốt lõi
ERD là gì
ERD (Entity-Relationship Diagram) là biểu đồ mô tả các thực thể (entity) trong hệ thống và quan hệ (relationship) giữa chúng. Nói đơn giản: nó vẽ ra "hệ thống lưu những loại thông tin gì, và các loại thông tin đó liên kết với nhau ra sao".
Với BA, ERD trả lời ba câu hỏi vàng trong mỗi dự án:
- Hệ thống cần lưu những đối tượng nào? (Khách hàng, Đơn hàng, Sản phẩm...)
- Mỗi đối tượng có những thông tin gì? (Khách hàng có tên, số điện thoại, email...)
- Các đối tượng liên kết với nhau thế nào? (Một khách hàng đặt nhiều đơn hàng...)
Ba thành phần chính
1. Entity (Thực thể) — thường vẽ bằng hình chữ nhật. Entity là một "danh từ" nghiệp vụ mà hệ thống cần lưu trữ dữ liệu về nó. Ví dụ: Khách hàng, Đơn hàng, Sản phẩm, Nhân viên. Trong database, mỗi entity thường tương ứng một table (bảng). Một mẹo để nhận diện entity: nếu bạn có thể đặt câu "hệ thống lưu danh sách các ___", thì cái điền vào chỗ trống thường là entity.
2. Attribute (Thuộc tính) — là các thông tin mô tả entity, thường vẽ bằng hình bầu dục hoặc liệt kê bên trong hình chữ nhật entity. Ví dụ entity Khách hàng có attribute: họ tên, email, số điện thoại, ngày sinh. Trong database, attribute là column (cột).
Có một attribute đặc biệt gọi là khóa chính (Primary Key - PK): giá trị định danh duy nhất cho mỗi bản ghi. Ví dụ customer_id. Không có hai khách hàng nào có cùng customer_id. Và khóa ngoại (Foreign Key - FK): một attribute trỏ đến khóa chính của entity khác — đây chính là "sợi dây" tạo ra quan hệ. Ví dụ bảng Đơn hàng có cột customer_id (FK) để biết đơn này của khách nào.
3. Relationship (Quan hệ) — là đường nối giữa hai entity, thể hiện chúng liên kết ra sao. Quan hệ luôn đi kèm cardinality (bản số) — con số cho biết "bao nhiêu". Đây là phần quan trọng nhất với BA.
Cardinality — trái tim của ERD
Có ba loại quan hệ cơ bản BA phải nằm lòng:
- One-to-One (1:1) — một-một. Ví dụ: một
Nhân viêncó mộtHồ sơ lươngvà ngược lại. Ít gặp, thường dùng để tách thông tin nhạy cảm ra bảng riêng.
- One-to-Many (1:N) — một-nhiều. Phổ biến nhất. Ví dụ: một
Khách hàngcó nhiềuĐơn hàng, nhưng mỗiĐơn hàngchỉ thuộc mộtKhách hàng. Trong ký hiệu "chân quạ" (crow's foot notation), phía "nhiều" được vẽ như bàn chân chim tách ba.
- Many-to-Many (N:N) — nhiều-nhiều. Ví dụ: một
Đơn hàngchứa nhiềuSản phẩm, và mộtSản phẩmxuất hiện trong nhiềuĐơn hàng. Điểm mấu chốt BA cần biết: quan hệ N:N không lưu trực tiếp được trong database, nó luôn phải tách thành một bảng trung gian (junction table / associative entity) — ví dụ bảngOrder_Item(chi tiết đơn hàng), lưu từng dòng sản phẩm trong từng đơn kèm số lượng và giá.
Ba mức độ của data model
Đây là điều phân biệt BA hiểu chuyện với BA "học vẹt":
- Conceptual model (mức khái niệm): chỉ có entity và quan hệ, không có chi tiết kỹ thuật. Đây là mức BA làm việc với business stakeholder. Ví dụ: "Khách hàng — đặt — Đơn hàng".
- Logical model (mức logic): thêm attribute, PK, FK, cardinality rõ ràng, chuẩn hóa dữ liệu. BA phối hợp với dev/BA senior ở mức này.
- Physical model (mức vật lý): kiểu dữ liệu cụ thể (VARCHAR, INT, DATETIME), index, constraint. Đây là địa hạt của dev và DBA — BA fresher không cần vẽ, nhưng nên đọc hiểu.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử — bài học về bảng trung gian
Một BA fresher tại một startup e-commerce ở Hà Nội (giả định tên "ChợViệt") được giao làm rõ tính năng giỏ hàng và đặt hàng. Ban đầu bạn ấy vẽ đơn giản: Đơn hàng nối thẳng với Sản phẩm, ghi chú "một đơn có nhiều sản phẩm". Dev đọc xong hỏi lại: "Thế nếu khách mua 3 chai dầu gội cùng loại thì lưu số lượng ở đâu? Giá tại thời điểm mua khác giá hiện tại thì lấy giá nào?".
BA đứng hình. Vấn đề là quan hệ Đơn hàng — Sản phẩm là many-to-many, và bản thân mối nối đó cần lưu dữ liệu riêng: số lượng, đơn giá tại thời điểm đặt. Giải pháp là thêm entity trung gian Chi tiết đơn hàng (Order_Item):
Đơn hàng(1) — (N)Chi tiết đơn hàngSản phẩm(1) — (N)Chi tiết đơn hàngChi tiết đơn hàngcó attribute:số lượng,đơn giá tại thời điểm mua
đơn giá tại thời điểm mua là ví dụ kinh điển — nếu không lưu, mọi báo cáo doanh thu quá khứ sẽ sai khi giá sản phẩm thay đổi.Ví dụ 2: Ngân hàng — khách hàng và tài khoản (chính là câu chuyện mở đầu)
Quay lại công ty fintech ở đầu bài. Sau sự cố lịch sử giao dịch bị trộn, BA senior ngồi vẽ lại ERD với đội. Kết quả:
Khách hàng(1) — (N)Tài khoản: một khách có thể có ví, thẻ tín dụng, tài khoản tiết kiệm.Tài khoản(1) — (N)Giao dịch: mỗi giao dịch thuộc đúng một tài khoản.
Tài khoản, và câu user story ban đầu thiếu mất chi tiết "theo tài khoản nào". BA fresher sau đó viết lại acceptance criteria: "Khi khách hàng có nhiều tài khoản, hệ thống hiển thị bộ chọn tài khoản; mặc định chọn tài khoản mở gần nhất".Bài học: ERD không chỉ để thiết kế database — nó là công cụ soi lỗ hổng requirement. Vẽ ra quan hệ 1:N buộc bạn phải hỏi: "Khi có nhiều, thì UI xử lý thế nào? Lọc ra sao? Mặc định là gì?". Những câu hỏi này chính là giá trị của BA.
Ví dụ 3: Hệ thống quản lý khóa học — cẩn thận với "một hay nhiều"
Một nền tảng học trực tuyến (giống chính bối cảnh khóa học này) cần model quan hệ giữa Học viên, Khóa học, và Giảng viên. BA fresher vẽ:
Giảng viên(1) — (N)Khóa học: một giảng viên dạy nhiều khóa, mỗi khóa một giảng viên chính. Hợp lý.Học viên(N) — (N)Khóa học: một học viên học nhiều khóa, một khóa có nhiều học viên → cần bảng trung gianĐăng ký (Enrollment).
Đăng ký hóa ra rất giàu thông tin: ngày đăng ký, tiến độ %, trạng thái (đang học/hoàn thành), ngày hoàn thành. Đây lại là một minh chứng bảng trung gian mang dữ liệu nghiệp vụ then chốt — toàn bộ tính năng "theo dõi tiến độ" và "cấp chứng chỉ" đều dựa vào bảng này.Nhưng có một cái bẫy: khi PO nói "khóa học có thể do một nhóm giảng viên đồng dạy", quan hệ Giảng viên — Khóa học lập tức đổi từ 1:N thành N:N, kéo theo phải thêm bảng trung gian mới. Bài học: một từ trong câu nói của stakeholder ("một" hay "nhiều", "chính" hay "đồng") có thể thay đổi toàn bộ cấu trúc. BA phải nghe rất kỹ những lượng từ này và xác nhận lại.
Hướng dẫn từng bước
Đây là quy trình vẽ một conceptual/logical ERD mà BA fresher có thể áp dụng ngay:
Bước 1 — Gạch chân danh từ. Đọc lại tài liệu requirement hoặc biên bản họp, gạch chân mọi danh từ nghiệp vụ lặp lại: khách hàng, đơn hàng, sản phẩm, thanh toán... Đây là ứng viên entity. Bỏ qua các danh từ chỉ hành động hoặc thuộc tính đơn lẻ.
Bước 2 — Lọc entity thật. Hỏi với mỗi ứng viên: "Hệ thống có cần lưu một danh sách các đối tượng này, mỗi cái có nhiều thông tin không?". Nếu có → entity. Nếu nó chỉ là một thuộc tính (ví dụ "màu sắc" của sản phẩm) → đó là attribute, không phải entity.
Bước 3 — Liệt kê attribute và xác định khóa chính. Với mỗi entity, ghi ra các thông tin cần lưu. Xác định cái nào định danh duy nhất (PK). Nếu không có sẵn, thường tạo một id nhân tạo.
Bước 4 — Xác định quan hệ và cardinality. Nối các entity có liên hệ. Với mỗi cặp, đọc thành câu theo cả hai chiều: "Một khách hàng có bao nhiêu đơn hàng?" (nhiều) và "Một đơn hàng thuộc bao nhiêu khách hàng?" (một) → suy ra 1:N. Luôn hỏi hai chiều, đây là kỹ thuật quan trọng nhất.
Bước 5 — Xử lý quan hệ N:N. Mỗi quan hệ nhiều-nhiều, tách ngay thành bảng trung gian. Rồi tự hỏi: "Bảng trung gian này có cần lưu thông tin gì riêng không?" (số lượng, ngày, trạng thái...).
Bước 6 — Rà lại bằng use case. Lấy vài kịch bản nghiệp vụ thật (khách A mua 2 sản phẩm, thanh toán 1 lần) và "chạy thử" trên ERD xem có lưu đủ dữ liệu không. Bước này bắt được hầu hết lỗi thiếu.
Bước 7 — Rà soát cùng dev. Ngồi với dev/BA senior để kiểm tra tính khả thi kỹ thuật. Đây là lúc chuyển từ conceptual/logical sang bàn về physical.
Công cụ vẽ: BA fresher không cần phần mềm đắt tiền. draw.io (diagrams.net) miễn phí, Lucidchart, dbdiagram.io (rất tiện, gõ text ra ERD), hay thậm chí Miro/Figma đều được. Với logical model, dbdiagram.io là lựa chọn tuyệt vời vì cú pháp text đơn giản và xuất được cả sang SQL.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm attribute thành entity (hoặc ngược lại). Người mới hay tạo entity riêng cho "giới tính" hay "trạng thái". Mẹo: nếu đối tượng chỉ có một-hai giá trị mô tả và không có danh sách bản ghi riêng, nó là attribute.
Lỗi 2 — Quên bảng trung gian cho quan hệ N:N. Đây là lỗi kinh điển nhất. Mẹo: mỗi khi đọc câu quan hệ hai chiều đều ra "nhiều", dừng lại và thêm bảng trung gian ngay.
Lỗi 3 — Không xác định cardinality, chỉ nối đường suông. Một đường nối không có bản số là vô nghĩa với dev. Mẹo: luôn đọc quan hệ thành câu tiếng Việt đầy đủ có lượng từ "một/nhiều".
Lỗi 4 — Ôm luôn physical model. BA fresher đi định nghĩa VARCHAR(50) hay INT — vượt vai trò và dễ sai. Mẹo: dừng ở logical, để dev/DBA quyết kiểu dữ liệu.
Lỗi 5 — Không lưu dữ liệu "tại thời điểm". Như ví dụ giá sản phẩm. Mẹo: với mọi dữ liệu có thể thay đổi theo thời gian (giá, tỷ giá, thông tin khách), hỏi "báo cáo quá khứ cần giá trị lúc đó hay lúc này?".
Lỗi 6 — Vẽ ERD một mình rồi giấu trong ngăn kéo. ERD chỉ có giá trị khi được dùng để đối thoại. Mẹo: mang ERD nháp vào cuộc họp requirement, dùng nó đặt câu hỏi. Stakeholder nhìn hình dễ phản hồi hơn nhìn chữ.
Mẹo vàng: ERD là ngôn ngữ chung giữa nghiệp vụ và kỹ thuật. Nó giúp bạn "dịch" câu nói mơ hồ của khách thành cấu trúc mà dev làm được. Một BA giỏi không phải người vẽ ERD đẹp nhất, mà là người dùng ERD để hỏi đúng câu hỏi.
Bài tập thực hành
Bài 1 — Đọc hiểu. Cho mô tả: "Một thư viện có nhiều đầu sách. Mỗi đầu sách có nhiều bản in (bản sao vật lý). Độc giả mượn các bản in; một bản in tại một thời điểm chỉ được một độc giả mượn, nhưng theo thời gian được nhiều người mượn." Hãy xác định: các entity, các quan hệ và cardinality, và có cần bảng trung gian nào không.
Bài 2 — Vẽ conceptual ERD. Cho tính năng: "Ứng dụng đặt đồ ăn. Khách hàng đặt đơn từ một nhà hàng. Mỗi đơn gồm nhiều món. Mỗi đơn được giao bởi một shipper. Khách có thể đánh giá nhà hàng sau khi nhận đơn." Vẽ ERD (dùng draw.io hoặc dbdiagram.io) với đầy đủ entity, quan hệ, cardinality và bảng trung gian nếu cần.
Bài 3 — Soi lỗ hổng. Dùng ERD bạn vẽ ở Bài 2, viết ra 3 câu hỏi làm rõ requirement mà ERD giúp bạn phát hiện (ví dụ: "một khách có thể đặt cùng lúc từ nhiều nhà hàng trong một đơn không?").
Bài 4 — Chạy thử use case. Lấy kịch bản "Khách An đặt 2 phần cơm gà và 1 trà đào từ quán X, shipper Bình giao, sau đó An đánh giá 5 sao". Kiểm tra ERD Bài 2 có lưu đủ toàn bộ dữ liệu trong kịch bản này không. Ghi lại chỗ nào thiếu và bổ sung.
Tóm tắt
- ERD mô tả entity (đối tượng cần lưu), attribute (thông tin), và relationship (quan hệ) — chính là nghiệp vụ được viết dưới dạng cấu trúc dữ liệu.
- Ba thành phần: Entity (table), Attribute (column, có PK/FK), Relationship (đường nối kèm cardinality).
- Cardinality là phần quan trọng nhất với BA: 1:1, 1:N, và N:N. Quan hệ N:N luôn cần bảng trung gian, và bảng đó thường mang dữ liệu nghiệp vụ then chốt (số lượng, giá tại thời điểm, trạng thái).
- Ba mức model: conceptual (làm với business), logical (làm với dev), physical (để dev/DBA lo). BA fresher sống ở hai mức đầu.
- Kỹ thuật cốt lõi: đọc mỗi quan hệ thành câu hai chiều có lượng từ "một/nhiều" để suy ra cardinality.
- Giá trị lớn nhất của ERD với BA không phải vẽ đẹp, mà là dùng nó để soi lỗ hổng requirement và làm ngôn ngữ chung giữa nghiệp vụ và kỹ thuật.