Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa hoàn thành một mô hình dữ liệu (data model) đẹp đẽ, chuẩn hóa tới 3NF, đầy đủ entity, attribute, relationship. Bạn tự hào gửi nó cho team phát triển. Một tuần sau, lập trình viên quay lại hỏi: "Anh ơi, tại sao bảng KhachHang lại có trường HanMucTinDung? Nghiệp vụ nào yêu cầu cái này? Ai duyệt hạn mức? Khi nào nó thay đổi?" — và bạn không có câu trả lời nào ngoài "ờ thì... lúc đó anh thấy nên có".
Đó chính là khoảnh khắc bạn nhận ra: một mô hình dữ liệu không gắn với tài liệu yêu cầu (requirements documentation) chỉ là một bức tranh đẹp nhưng vô chủ. Không ai biết nó đến từ đâu, phục vụ nhu cầu nghiệp vụ nào, và khi nghiệp vụ thay đổi thì phần nào của mô hình phải đổi theo.
Với vai trò Business Analyst (BA), giá trị lớn nhất bạn mang lại không chỉ là vẽ được ERD, mà là bắc được cây cầu giữa nhu cầu nghiệp vụ và cấu trúc dữ liệu. Bài học này tập trung đúng vào cây cầu đó: làm sao để mô hình dữ liệu của bạn không sống tách biệt, mà gắn chặt, truy vết được (traceable), và đồng bộ với toàn bộ hệ thống tài liệu yêu cầu — từ business need, quy trình nghiệp vụ (BPMN), use case, user story, cho tới business rules.
Đây là kỹ năng phân biệt một người "biết vẽ ERD" với một BA dữ liệu thực thụ.
Khái niệm cốt lõi
Mô hình dữ liệu nằm ở đâu trong dòng chảy yêu cầu
Mô hình dữ liệu không tự sinh ra. Nó là sản phẩm cuối của một chuỗi suy luận bắt đầu từ nhu cầu kinh doanh. Hãy nhìn dòng chảy này:
Nhu cầu nghiệp vụ (Business Need)
↓
Mô hình quy trình nghiệp vụ (Business Process Model — BPMN)
↓
Conceptual Data Model (mô hình khái niệm — cái gì, không phải làm thế nào)
↓
Use Cases / User Stories (hành vi hệ thống)
↓
Logical Data Model (mô hình logic — chuẩn hóa, chi tiết)
↓
Business Rules (ràng buộc nghiệp vụ)
↓
Physical Data Model (mô hình vật lý — triển khai trên DBMS)
Điểm mấu chốt: mỗi entity, mỗi attribute, mỗi relationship trong mô hình của bạn phải truy ngược được tới một yêu cầu nghiệp vụ cụ thể. Nếu không truy ngược được, nó là "rác mô hình" (model junk) — hoặc bạn đang thiếu một yêu cầu chưa được ghi nhận.
Truy vết hai chiều (Bidirectional Traceability)
Đây là khái niệm trung tâm của bài. Truy vết hai chiều nghĩa là:
- Xuôi (forward): Từ một yêu cầu, tôi chỉ ra được nó tạo ra entity/attribute nào trong mô hình. Ví dụ yêu cầu "Hệ thống phải lưu lịch sử giao dịch trong 5 năm" → sinh ra entity
GiaoDichvới attributeNgayGiaoDichvà chính sách lưu trữ. - Ngược (backward): Từ một thành phần trong mô hình, tôi chỉ ra được nó phục vụ yêu cầu nào. Ví dụ attribute
KhachHang.SoCMND→ phục vụ yêu cầu định danh khách hàng theo quy định KYC của Ngân hàng Nhà nước.
Hai nguồn dữ liệu chính cho mô hình: Danh từ và Quy tắc
Khi đọc tài liệu yêu cầu, BA dữ liệu rút ra mô hình theo hai loại "tín hiệu":
- Danh từ (nouns) → Entity và Attribute. Trong câu "Khách hàng đặt đơn hàng gồm nhiều sản phẩm", các danh từ "Khách hàng", "đơn hàng", "sản phẩm" là ứng viên entity. Đây là kỹ thuật phân tích danh từ (noun analysis).
- Động từ và mệnh đề điều kiện (verbs, conditions) → Relationship và Business Rule. "Đặt" là relationship giữa Khách hàng và Đơn hàng. "Mỗi đơn hàng phải có ít nhất một sản phẩm" là một business rule biến thành ràng buộc cardinality.
Đồng bộ vòng đời (Lifecycle Synchronization)
Tài liệu yêu cầu và mô hình dữ liệu phải tiến hóa cùng nhau. Khi một change request (yêu cầu thay đổi) được duyệt, quy trình của bạn phải bao gồm bước cập nhật mô hình. Nếu hai thứ này lệch pha, bạn sẽ rơi vào tình trạng "tài liệu nói một đằng, database làm một nẻo" — cơn ác mộng của mọi dự án bảo trì.
Tình huống thực tế
Tình huống 1: Ví VNPAY và yêu cầu hoàn tiền không được mô hình hóa
Một fintech giả định lấy cảm hứng từ các ví điện tử Việt Nam — gọi là "ViPay" — đang xây tính năng nạp/rút tiền. Tài liệu yêu cầu (SRS) có ghi rõ một dòng: "Khi giao dịch nạp tiền thất bại nhưng tiền đã bị trừ ở ngân hàng, hệ thống phải hỗ trợ quy trình hoàn tiền (refund) trong vòng 7 ngày làm việc."
BA đầu tiên mô hình hóa entity GiaoDich với các trạng thái THANH_CONG, THAT_BAI, DANG_XU_LY. Trông có vẻ ổn. Nhưng khi đối chiếu RTM, team phát hiện yêu cầu hoàn tiền không ánh xạ tới bất kỳ thành phần nào trong mô hình. Không có entity HoanTien, không có trạng thái DANG_HOAN_TIEN, không có liên kết tới giao dịch gốc.
Hậu quả nếu bỏ qua: khi vận hành, mỗi vụ hoàn tiền phải xử lý thủ công qua Excel, không truy vết được, và khi thanh tra Ngân hàng Nhà nước yêu cầu báo cáo, công ty không xuất được dữ liệu.
Sau khi truy vết ngược, BA bổ sung entity HoanTien (MaHoanTien, MaGiaoDichGoc — khóa ngoại tự tham chiếu tới GiaoDich, SoTien, NgayYeuCau, NgayHoanTat, TrangThai) với relationship one-to-one tới giao dịch gốc.
Bài học: RTM không chỉ để "đẹp tài liệu". Nó là công cụ phát hiện lỗ hổng — những yêu cầu có thật nhưng bị mô hình bỏ quên. Một yêu cầu không có dòng nào trong mô hình là một quả bom hẹn giờ.
Tình huống 2: Tiki và attribute "mồ côi" không ai dùng
Một sàn thương mại điện tử giả định kiểu Tiki có entity SanPham với 47 attribute. Trong đợt review, một BA mới vào hỏi: "Trường DiemUuTienHienThi (priority score) này dùng để làm gì?" Không ai trả lời được. Tìm trong tài liệu yêu cầu — không có user story nào nhắc đến nó. Tìm trong code — không có truy vấn nào đọc nó.
Đây là vấn đề ngược lại của tình huống 1: attribute mồ côi (orphan attribute) — một thành phần mô hình không truy ngược được tới yêu cầu nào. Hóa ra 2 năm trước có một lập trình viên thêm vào để thử nghiệm thuật toán sắp xếp, rồi quên xóa. Nó kéo theo chi phí: tăng kích thước bảng, gây nhầm lẫn cho team mới, và mỗi lần migration đều phải xử lý nó.
Khi đối chiếu RTM, team đánh dấu attribute này là "không có nguồn yêu cầu" và sau khi xác nhận với product owner, loại bỏ an toàn trong sprint dọn dẹp.
Bài học: Truy vết hai chiều bảo vệ bạn ở cả hai phía. Yêu cầu thiếu mô hình thì sinh lỗ hổng; mô hình thừa so với yêu cầu thì sinh nợ kỹ thuật. Một mô hình "sạch" là mô hình mà mọi thành phần đều có lý do tồn tại được ghi nhận.
Tình huống 3: Công ty bảo hiểm và business rule biến thành cardinality
Một công ty bảo hiểm nhân thọ tại TP.HCM xây hệ thống quản lý hợp đồng. Trong buổi workshop, chuyên gia nghiệp vụ nói: "Một hợp đồng bảo hiểm phải có ít nhất một người được bảo hiểm, nhưng một người chỉ được đứng tên người mua trên tối đa 3 hợp đồng đang hiệu lực cùng lúc — đây là quy định kiểm soát rủi ro của công ty."
BA giỏi không chỉ ghi câu này vào tài liệu rồi quên. Anh ta phân tách nó thành hai loại ràng buộc:
- "Ít nhất một người được bảo hiểm" → ràng buộc cardinality trong mô hình logic: relationship
HopDong–NguoiDuocBaoHiemlà one-to-many với cận dưới bắt buộc (mandatory, ký hiệu Crow's Foot là "một và chỉ một trở lên"). Cái này mô hình hóa được trực tiếp. - "Tối đa 3 hợp đồng đang hiệu lực cùng lúc" → đây là business rule động, phụ thuộc trạng thái, không mô hình hóa được bằng cardinality tĩnh. Nó phải được ghi vào data dictionary như một ràng buộc cần xử lý ở tầng ứng dụng hoặc trigger.
Bài học: Không phải business rule nào cũng trở thành đường kẻ trong ERD. Kỹ năng của BA là phân loại: cái nào thành cardinality, cái nào thành constraint, cái nào phải đẩy lên tầng nghiệp vụ. Ghi rõ điều này trong tài liệu giúp lập trình viên không "đoán" sai.
Hướng dẫn từng bước
Đây là quy trình thực hành để tích hợp mô hình dữ liệu với tài liệu yêu cầu, áp dụng được ngay cho dự án của bạn.
Bước 1 — Thu thập và đọc kỹ tài liệu yêu cầu. Tập hợp tất cả: tài liệu BRD (Business Requirements Document), SRS (Software Requirements Specification), bộ user story, sơ đồ BPMN, biên bản workshop. Đọc với tâm thế "đi săn danh từ và quy tắc".
Bước 2 — Phân tích danh từ để rút entity và attribute. Gạch chân mọi danh từ. Phân loại: danh từ nào là entity độc lập (Khách hàng, Đơn hàng), danh từ nào chỉ là attribute của entity khác (số điện thoại, địa chỉ → attribute của Khách hàng). Lập danh sách ứng viên entity.
Bước 3 — Phân tích động từ để rút relationship. Với mỗi cặp entity, tìm động từ nối chúng trong tài liệu: "đặt", "thuộc về", "duyệt", "thanh toán". Mỗi động từ là một ứng viên relationship. Xác định cardinality từ các cụm "mỗi", "ít nhất", "tối đa", "có thể không có".
Bước 4 — Lập ma trận truy vết (RTM). Tạo bảng với các cột: Mã yêu cầu | Mô tả yêu cầu | Entity | Attribute | Relationship | Business Rule | Ghi chú. Mỗi yêu cầu chiếm một hoặc nhiều dòng. Đây là tài liệu sống, cập nhật liên tục.
Bước 5 — Kiểm tra hai chiều. Quét xuôi: mọi yêu cầu có ánh xạ tới ít nhất một thành phần mô hình không? Yêu cầu nào trống là lỗ hổng (như tình huống ViPay). Quét ngược: mọi entity/attribute có truy về một yêu cầu không? Thành phần nào mồ côi là nợ kỹ thuật (như tình huống Tiki).
Bước 6 — Phân loại và đặt business rule đúng chỗ. Với mỗi business rule, quyết định: nó là cardinality, CHECK constraint, unique constraint, hay logic tầng ứng dụng? Ghi rõ vào data dictionary và RTM (như tình huống bảo hiểm).
Bước 7 — Thiết lập quy trình đồng bộ. Quy ước rằng mọi change request được duyệt phải đi kèm bước "đánh giá tác động lên mô hình dữ liệu". Gắn việc cập nhật RTM vào Definition of Done của mỗi thay đổi.
Lỗi thường gặp & mẹo
Lỗi 1 — Vẽ mô hình trước, viết yêu cầu sau. Nhiều BA mới hào hứng vẽ ERD ngay khi nghe sơ qua nghiệp vụ, rồi mới quay lại "hợp thức hóa" bằng tài liệu. Kết quả là mô hình phản ánh giả định của bạn, không phải nhu cầu thật. Mẹo: luôn để tài liệu yêu cầu dẫn đường; mô hình là hệ quả, không phải điểm xuất phát.
Lỗi 2 — Coi RTM là việc làm một lần. Lập RTM lúc đầu dự án rồi để mốc. Sau vài sprint, nó lệch hoàn toàn với thực tế và trở nên vô dụng. Mẹo: gắn việc cập nhật RTM vào quy trình change management, biến nó thành tài liệu sống.
Lỗi 3 — Nhồi mọi business rule vào ERD. Cố gắng vẽ cả những quy tắc động ("tối đa 3 hợp đồng") thành cardinality khiến mô hình sai lệch hoặc bất khả thi. Mẹo: phân loại rõ rule nào mô hình hóa được, rule nào đẩy lên tầng ứng dụng, và ghi chú minh bạch.
Lỗi 4 — Dùng từ ngữ khác nhau giữa tài liệu và mô hình. Tài liệu gọi "Người dùng", mô hình gọi Account, code gọi member. Sự lệch thuật ngữ này gây hiểu nhầm triền miên. Mẹo: duy trì một bảng thuật ngữ (glossary) thống nhất, dùng cùng tên xuyên suốt từ yêu cầu tới mô hình.
Lỗi 5 — Bỏ qua các yêu cầu phi chức năng (non-functional). Yêu cầu như "lưu trữ 5 năm", "audit mọi thay đổi", "ẩn danh dữ liệu cá nhân" cũng tác động tới mô hình (cần cột timestamp, bảng audit, chính sách che dữ liệu). Mẹo: khi quét RTM, đừng chỉ nhìn yêu cầu chức năng.
Mẹo vàng: Trong mỗi buổi review mô hình với stakeholder, hãy chỉ vào từng entity và hỏi "yêu cầu nào sinh ra cái này?". Nếu im lặng kéo dài, bạn vừa tìm ra một vấn đề.
Bài tập thực hành
Cho đoạn tài liệu yêu cầu sau của một hệ thống đặt phòng khách sạn (giả định chuỗi khách sạn "Mường Thanh Mini"):
> "Khách hàng có thể đặt một hoặc nhiều phòng cho cùng một kỳ lưu trú. Mỗi đặt phòng phải gắn với đúng một khách hàng đã đăng ký. Hệ thống phải lưu lịch sử mọi thay đổi trạng thái đặt phòng (đã đặt, đã xác nhận, đã hủy, đã nhận phòng). Một khách hàng VIP được phép giữ tối đa 5 đặt phòng chưa thanh toán cùng lúc. Hệ thống phải lưu thông tin đặt phòng tối thiểu 3 năm để phục vụ kế toán."
Yêu cầu:
- Phân tích danh từ: liệt kê các ứng viên entity và attribute từ đoạn trên.
- Phân tích động từ: xác định các relationship và cardinality (dùng ký hiệu "1", "nhiều", "ít nhất một").
- Lập RTM rút gọn: tạo bảng 4 dòng, mỗi dòng một câu trong đoạn, ánh xạ tới entity/attribute/relationship/rule tương ứng.
- Phân loại business rule: với quy tắc "VIP tối đa 5 đặt phòng chưa thanh toán" và "lưu tối thiểu 3 năm", hãy chỉ ra cái nào mô hình hóa được trong ERD và cái nào phải xử lý ở tầng ứng dụng / chính sách. Giải thích vì sao.
- Tự kiểm tra hai chiều: có yêu cầu nào trong đoạn không ánh xạ được tới mô hình của bạn không? Có thành phần nào bạn vẽ ra mà không có câu nào trong đoạn yêu cầu?
LichSuTrangThaiDatPhong) chứ không chỉ một cột trạng thái duy nhất — nếu bạn chỉ vẽ một cột, bạn đã bỏ sót một yêu cầu.Tóm tắt
Mô hình dữ liệu không sống một mình. Giá trị thật sự của một Business Analyst dữ liệu nằm ở khả năng gắn kết mô hình với tài liệu yêu cầu một cách truy vết được. Hãy ghi nhớ những điểm cốt lõi:
- Mô hình dữ liệu là hệ quả của dòng chảy yêu cầu: từ business need → BPMN → conceptual → use case → logical → physical. Nó không phải điểm xuất phát.
- Truy vết hai chiều là kim chỉ nam: mỗi yêu cầu phải sinh ra thành phần mô hình, và mỗi thành phần mô hình phải truy về một yêu cầu. Thiếu hướng nào cũng sinh vấn đề — lỗ hổng hoặc nợ kỹ thuật.
- Ma trận truy vết (RTM) là công cụ trung tâm, và nó là tài liệu sống, cập nhật cùng mọi change request.
- Phân tích danh từ ra entity/attribute, phân tích động từ và điều kiện ra relationship/business rule.
- Không phải business rule nào cũng thành đường kẻ trong ERD — kỹ năng là phân loại đúng chỗ thực thi.
- Giữ thuật ngữ thống nhất từ yêu cầu tới mô hình tới code, và đừng quên các yêu cầu phi chức năng.