Mở đầu — vì sao bài này quan trọng
Bạn còn nhớ cảm giác lần đầu mở file Figma của một designer khác không? Hàng chục frame, component, auto-layout chằng chịt. Nhưng vì bạn hiểu ngôn ngữ của Figma, chỉ sau vài phút bạn đã đọc được ý đồ thiết kế. ERD (Entity Relationship Diagram) chính là "file Figma" của đội developer — chỉ khác là nó mô tả cấu trúc dữ liệu thay vì giao diện.
Với một Designer đang chuyển sang BA, đây là kỹ năng dễ bị né tránh nhất. Nhìn vào một sơ đồ đầy hình chữ nhật, đường nối và ký hiệu "chân gà" (crow's foot), nhiều người tự nhủ "cái này là việc của dev, không phải của mình". Đây là một hiểu lầm tai hại. Trong thực tế, BA là người đứng giữa business và kỹ thuật. Khi business nói "tôi muốn khách hàng có thể lưu nhiều địa chỉ giao hàng", chính BA phải hiểu điều đó tác động thế nào đến schema (cấu trúc bảng dữ liệu) mà dev đã dựng.
Nếu bạn không đọc được ERD, bạn sẽ rơi vào một trong hai cái bẫy. Một là bạn viết requirement mà hệ thống không thể đáp ứng vì mâu thuẫn với cấu trúc dữ liệu hiện có. Hai là bạn để dev tự quyết định mọi thứ về data, rồi ba tháng sau phát hiện hệ thống không thể trả lời câu hỏi "khách hàng này đã mua bao nhiêu lần" chỉ vì thiếu một trường dữ liệu.
Tin tốt là: bạn không cần biết code, không cần dựng database. Là BA, bạn chỉ cần đọc hiểu ERD và biết cách đề xuất bổ sung. Bài này sẽ dạy bạn đúng phần đó — vừa đủ để tự tin ngồi vào bàn với dev, không thừa để biến bạn thành kỹ sư dữ liệu.
Khái niệm cốt lõi
ERD là gì?
ERD là bản đồ mô tả dữ liệu của hệ thống được tổ chức thế nào. Nó trả lời ba câu hỏi: Hệ thống lưu những loại thông tin gì? Mỗi loại thông tin gồm những thuộc tính nào? Các loại thông tin đó liên kết với nhau ra sao?
Hãy tưởng tượng một hệ thống bán khoá học online. Nó cần lưu thông tin về học viên, về khoá học, và về việc ai đã đăng ký khoá nào. Ba "loại thông tin" đó chính là ba Entity (thực thể).
Ba thành phần bạn phải nhận diện
Entity (Thực thể) — thường được vẽ bằng hình chữ nhật, đại diện cho một "danh từ" mà hệ thống cần lưu: Học viên, Khoá học, Đơn hàng, Sản phẩm. Trong database, mỗi entity thường tương ứng với một table (bảng). Bạn có thể hình dung một bảng như một sheet Excel: mỗi dòng là một bản ghi (record), mỗi cột là một thuộc tính.
Attribute (Thuộc tính) — là các cột trong bảng, mô tả đặc điểm của entity. Entity "Học viên" có thể có các attribute: họ tên, email, số điện thoại, ngày đăng ký. Có hai loại attribute đặc biệt bạn cần thuộc lòng:
- Primary Key (PK, khoá chính): một trường định danh duy nhất cho mỗi bản ghi, ví dụ
student_id. Không có hai học viên nào trùngstudent_id. Đây là "số căn cước công dân" của mỗi dòng dữ liệu. - Foreign Key (FK, khoá ngoại): một trường trỏ tới PK của bảng khác, tạo ra mối liên kết. Ví dụ trong bảng Đơn hàng có trường
student_idđể biết đơn này của học viên nào.
Đọc "cardinality" — ngôn ngữ của mối quan hệ
Cardinality mô tả một bản ghi bên này liên kết với bao nhiêu bản ghi bên kia. Có ba dạng bạn sẽ gặp 99% thời gian:
- One-to-One (1:1): Mỗi học viên có đúng một hồ sơ (profile). Hiếm gặp, thường dùng để tách thông tin nhạy cảm.
- One-to-Many (1:N): Một học viên có thể có nhiều đơn hàng, nhưng mỗi đơn hàng chỉ thuộc về một học viên. Đây là dạng phổ biến nhất.
- Many-to-Many (N:N): Một học viên đăng ký nhiều khoá học, và một khoá học có nhiều học viên. Dạng này không thể lưu trực tiếp — nó phải được tách ra bằng một bảng trung gian (junction table), ví dụ bảng
enrollment(đăng ký).
Ví dụ: đường nối giữa student và order có một gạch phía student và chân gà phía order, nghĩa là "một học viên có nhiều đơn hàng". Nếu phía order còn có thêm vòng tròn, nghĩa là "học viên có thể chưa có đơn hàng nào".
Vì sao BA phải quan tâm bảng trung gian?
Bảng trung gian là nơi ẩn giấu nhiều requirement quan trọng nhất. Quay lại ví dụ N:N học viên — khoá học: bảng enrollment không chỉ nối hai bên, nó còn có thể lưu ngày đăng ký, tiến độ học, trạng thái hoàn thành, điểm số. Khi business hỏi "làm sao biết học viên hoàn thành bao nhiêu phần trăm khoá học", câu trả lời nằm ở việc có hay không một trường progress trong bảng trung gian này. Một BA giỏi luôn nhìn vào bảng trung gian đầu tiên khi phân tích các nghiệp vụ phức tạp.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán "nhiều địa chỉ giao hàng"
Giả sử bạn là BA tại một sàn thương mại điện tử kiểu Tiki. Business đưa ra yêu cầu: "Khách hàng phàn nàn rằng họ chỉ lưu được một địa chỉ. Nhiều người mua hàng gửi về nhà, gửi về công ty, gửi tặng người thân. Hãy cho họ lưu nhiều địa chỉ."
Bạn mở ERD hiện tại và thấy: bảng customer có sẵn các trường address, city, district nằm ngay trong bảng khách hàng. Nghĩa là mỗi khách hàng chỉ có một địa chỉ — quan hệ 1:1 được nhúng thẳng vào bảng.
Đọc được điều này, bạn hiểu ngay bản chất yêu cầu: cần chuyển quan hệ từ 1:1 sang 1:N. Cụ thể, phải tách địa chỉ ra thành một entity riêng — bảng shipping_address mới, với FK customer_id trỏ về bảng khách hàng. Mỗi khách hàng khi đó có nhiều dòng địa chỉ. Bạn còn đề xuất thêm trường is_default (địa chỉ mặc định) và label (nhãn: "Nhà", "Công ty") vì đó là điều khách hàng thực sự cần.
Bài học rút ra: Vì đọc được ERD, bạn không chỉ dịch được yêu cầu mơ hồ của business thành thay đổi cấu trúc rõ ràng, mà còn chủ động đề xuất trường bổ sung mà business chưa nghĩ tới. Bạn ngồi vào buổi refinement với dev bằng ngôn ngữ của họ, và ước lượng công việc trở nên chính xác hơn nhiều.
Tình huống 2 — Ngân hàng số và trường dữ liệu bị thiếu
Một BA tại một ngân hàng số ở Việt Nam (kiểu Cake hoặc TNEX) nhận yêu cầu: "Bộ phận marketing muốn gửi ưu đãi cho khách hàng theo dịp sinh nhật."
Nghe đơn giản, nhưng khi mở ERD bảng account, BA phát hiện bảng chỉ lưu full_name, phone, id_number (số CCCD) và created_at (ngày mở tài khoản). Không có trường ngày sinh riêng. Ngày sinh đang nằm ẩn trong số CCCD.
Đây là khoảnh khắc mà kỹ năng đọc ERD tạo ra khác biệt. BA có hai lựa chọn để trình bày: một là parse (bóc tách) ngày sinh từ số CCCD — nhưng số CCCD cũ (9 số) không chứa ngày sinh, chỉ CCCD 12 số mới có, dẫn đến dữ liệu không đồng nhất. Hai là bổ sung một trường date_of_birth mới vào bảng và có kế hoạch thu thập lại. BA viết requirement nêu rõ cả rủi ro dữ liệu lịch sử (những khách hàng cũ sẽ trống trường này), và đề xuất chiến dịch cập nhật thông tin.
Bài học rút ra: Nếu không đọc ERD, BA sẽ hứa với marketing một tính năng mà hệ thống không có dữ liệu để chạy. Đọc ERD giúp bạn phát hiện "lỗ hổng dữ liệu" (data gap) từ giai đoạn phân tích, trước khi nó biến thành khủng hoảng lúc go-live.
Tình huống 3 — Startup giáo dục và mối quan hệ N:N bị hiểu sai
Tại một startup edtech, một BA mới (vừa từ Design chuyển qua) viết requirement cho tính năng "một giáo viên dạy một lớp". Bạn thiết kế quan hệ 1:N: một giáo viên có nhiều lớp, mỗi lớp một giáo viên. Dev dựng schema đúng như vậy.
Sáu tháng sau, trường mở mô hình "co-teaching" — hai giáo viên cùng đứng một lớp. Lúc này schema 1:N trở thành rào cản: bảng class chỉ có một FK teacher_id, không thể gán hai giáo viên. Phải migration (chuyển đổi) dữ liệu, tạo bảng trung gian class_teacher — một việc tốn kém và rủi ro trên dữ liệu production đang chạy.
Bài học rút ra: Khi đọc và thiết kế ERD, BA cần hỏi business câu "liệu trong tương lai quan hệ này có thể trở thành nhiều-nhiều không?". Nhận diện đúng cardinality ngay từ đầu — đặc biệt là phân biệt 1:N với N:N — giúp tránh những cuộc migration đau đớn. Một chút tư duy trước giúp tiết kiệm hàng tuần công sức về sau.
Hướng dẫn từng bước
Đây là quy trình để bạn đọc một ERD lạ và biến nó thành hiểu biết nghiệp vụ.
Bước 1 — Xác định các entity chính. Nhìn tổng thể, liệt kê tất cả hình chữ nhật. Đặt câu hỏi: mỗi bảng này đại diện cho "danh từ nghiệp vụ" nào? Khoanh vùng những entity liên quan trực tiếp đến feature bạn đang làm, bỏ qua phần còn lại để không bị ngợp.
Bước 2 — Đọc primary key của từng entity. Tìm trường được đánh dấu PK (thường in đậm hoặc có biểu tượng chìa khoá). Điều này cho bạn biết "cái gì làm nên một bản ghi duy nhất". Đôi khi PK là tổ hợp hai trường (composite key) — dấu hiệu cho thấy đây có thể là bảng trung gian.
Bước 3 — Lần theo các foreign key và mối quan hệ. Với mỗi FK, xác định nó trỏ đến bảng nào và đọc cardinality của đường nối. Diễn giải thành câu tiếng Việt trọn nghĩa: "Một đơn hàng thuộc về một khách hàng; một khách hàng có thể có nhiều đơn hàng."
Bước 4 — Đối chiếu với nghiệp vụ thực tế. Đây là bước quan trọng nhất và là nơi BA khác dev. Hỏi: cấu trúc này có phản ánh đúng cách business vận hành không? Ví dụ ERD nói "một đơn hàng một khách hàng", nhưng business có tình huống "mua hộ, thanh toán hộ" không? Nếu có, schema có thể đang thiếu.
Bước 5 — Ghi chú các trường quan trọng cho báo cáo và metrics. Nhìn xem các trường cần cho báo cáo có tồn tại không: created_at, status, amount. Nếu business muốn báo cáo "doanh thu theo tháng" mà bảng đơn hàng không có created_at hoặc total_amount, đó là data gap cần nêu.
Bước 6 — Đề xuất bổ sung dưới dạng requirement rõ ràng. Khi cần thêm trường hoặc bảng, hãy viết ngắn gọn theo mẫu: tên trường/bảng — kiểu dữ liệu gợi ý — thuộc entity nào — bắt buộc hay không — lý do nghiệp vụ. Ví dụ: "Bổ sung trường is_default (boolean) vào bảng shipping_address, không bắt buộc, mặc định false — để đánh dấu địa chỉ giao hàng mặc định của khách."
Một mẹo nhỏ: bạn không cần công cụ đắt tiền để tự vẽ nháp ERD. Các công cụ miễn phí như dbdiagram.io (viết cú pháp đơn giản ra sơ đồ), draw.io hay Lucidchart đều đủ dùng để bạn phác thảo ý tưởng trước khi trao đổi với dev.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm attribute với entity. Người mới hay tách mọi thứ thành bảng riêng, ví dụ tạo hẳn một entity "Số điện thoại". Ngược lại, cũng có người nhồi mọi thứ vào một bảng khổng lồ. Nguyên tắc: nếu một "thứ" cần lưu nhiều bản ghi độc lập và có mối quan hệ riêng, nó là entity; nếu chỉ là một đặc điểm đơn lẻ, nó là attribute.
Lỗi 2 — Bỏ qua cardinality "optional" (0 hay 1). Sự khác biệt giữa "bắt buộc có" và "có thể trống" cực kỳ quan trọng. Nếu trường email là bắt buộc nhưng business cho phép đăng ký chỉ bằng số điện thoại, bạn đã tạo mâu thuẫn. Luôn hỏi rõ mỗi mối quan hệ và mỗi trường: trống được không?
Lỗi 3 — Không nhận ra bảng trung gian che giấu requirement. Như đã nói, bảng junction trong quan hệ N:N thường chứa dữ liệu nghiệp vụ giá trị. Đừng coi nó chỉ là "bảng nối" vô hồn — hãy hỏi nó nên lưu thêm thông tin gì.
Lỗi 4 — Lấn sân sang việc của dev. BA đề xuất cái gì cần lưu và tại sao, còn lưu thế nào (kiểu index, chuẩn hoá đến mức nào, hiệu năng) là việc của dev/kỹ sư database. Đừng cố quyết định thay họ; hãy trình bày nhu cầu nghiệp vụ và để họ thiết kế kỹ thuật.
Mẹo vàng — Luôn diễn giải ERD thành câu tiếng Việt. Cách kiểm tra bạn đã hiểu đúng: đọc to mỗi mối quan hệ thành một câu nghiệp vụ hoàn chỉnh và đưa cho một người non-tech xác nhận. Nếu người của business gật đầu "đúng rồi", schema phản ánh đúng thực tế. Nếu họ nhíu mày, bạn vừa tìm ra một lỗ hổng.
Mẹo — Hỏi dev cho xem ERD ngay ngày đầu tiên. Khi tham gia dự án mới, một trong những tài liệu đầu tiên bạn nên xin là ERD (hoặc data dictionary). Nó cho bạn bức tranh nhanh nhất về cách hệ thống "suy nghĩ" về dữ liệu, nhanh hơn nhiều so với đọc hàng trăm màn hình.
Bài tập thực hành
Bài 1 — Đọc và diễn giải. Cho ba entity của một hệ thống đặt bàn nhà hàng: customer (PK: customer_id), reservation (PK: reservation_id, FK: customer_id, restaurant_id, có trường booking_time, party_size), restaurant (PK: restaurant_id). Hãy viết ra ba câu tiếng Việt diễn giải mối quan hệ giữa chúng, và xác định cardinality của từng cặp.
Bài 2 — Phát hiện data gap. Business của một app giao đồ ăn muốn báo cáo "thời gian giao trung bình theo từng shipper mỗi tuần". Bảng delivery hiện chỉ có: delivery_id, order_id, shipper_id, status. Hãy liệt kê những trường còn thiếu để chạy được báo cáo này, kèm lý do.
Bài 3 — Xử lý quan hệ N:N. Một hệ thống HR cần lưu: một nhân viên có thể thuộc nhiều dự án, một dự án có nhiều nhân viên; đồng thời cần biết mỗi người đóng vai trò gì (role) và làm việc bao nhiêu giờ (allocation) trong từng dự án. Hãy phác thảo các entity cần có (kể cả bảng trung gian) và các trường của bảng trung gian. Bạn có thể vẽ thử trên dbdiagram.io.
Bài 4 — Viết đề xuất. Chọn một tính năng của ứng dụng bạn hay dùng (ví dụ tính năng "lưu bài viết yêu thích"). Giả định schema hiện tại chưa hỗ trợ, hãy viết đề xuất bổ sung theo mẫu ở Bước 6: bảng/trường mới, kiểu dữ liệu, thuộc entity nào, bắt buộc hay không, lý do nghiệp vụ.
Tóm tắt
ERD là bản đồ dữ liệu của hệ thống, và đọc được nó là một trong những kỹ năng tạo khác biệt lớn nhất giữa một BA nghiệp dư và một BA chuyên nghiệp. Bạn cần nắm ba thành phần: entity (bảng, tương ứng danh từ nghiệp vụ), attribute (cột, gồm hai loại đặc biệt là PK và FK), và relationship (mối quan hệ, đọc qua cardinality 1:1, 1:N, N:N).
Vai trò của BA không phải dựng database mà là đọc hiểu schema dev đã có và đề xuất trường/bảng mới khi nghiệp vụ đòi hỏi. Ba tình huống trong bài — nhiều địa chỉ giao hàng, trường ngày sinh bị thiếu, và quan hệ co-teaching — đều cho thấy cùng một chân lý: đọc được ERD giúp bạn phát hiện lỗ hổng dữ liệu từ sớm, dịch yêu cầu mơ hồ thành thay đổi cấu trúc rõ ràng, và tránh những cuộc migration tốn kém.
Hãy nhớ mẹo vàng: luôn diễn giải mỗi mối quan hệ thành một câu tiếng Việt và kiểm chứng với business. Đó là cách một Designer với con mắt tinh tường về trải nghiệm người dùng có thể trở thành một BA sắc bén về cấu trúc dữ liệu. Ở bài tiếp theo, bạn sẽ bước sang thế giới quy trình làm việc của BA với Jira và Confluence — nơi những requirement dữ liệu này được biến thành công việc cụ thể cho cả đội.