Mở đầu — vì sao bài này quan trọng
Có một câu nói trong giới BA mà tôi rất tâm đắc: "Nếu bạn không hiểu dữ liệu của hệ thống, bạn không thực sự hiểu nghiệp vụ." Nghe có vẻ cường điệu, nhưng càng làm lâu bạn càng thấy đúng. Mọi quy trình kinh doanh, mọi luồng nghiệp vụ, cuối cùng đều quy về một câu hỏi: hệ thống lưu cái gì, mối quan hệ giữa các cái đó ra sao, và quy tắc nào ràng buộc chúng.
Với bạn — một developer đang chuyển sang BA — đây chính là vùng đất bạn có lợi thế tuyệt đối so với các BA xuất thân từ kinh tế, marketing hay quản trị. Bạn đã từng viết CREATE TABLE, đã từng đau đầu vì foreign key, đã từng debug vì quan hệ một-nhiều bị thiết kế sai. Bạn hiểu chuẩn hóa (normalization), hiểu khóa chính khóa ngoại, hiểu index. Đó là kiến thức mà nhiều BA phải mất hàng năm mới chạm tới.
Nhưng — và đây là cái "nhưng" quan trọng nhất của bài hôm nay — vai trò của bạn đã đổi. Là developer, bạn mô hình hóa dữ liệu để máy chạy được. Là BA, bạn mô hình hóa dữ liệu để con người hiểu được nghiệp vụ và thống nhất với nhau trước khi máy chạy. Hai mục tiêu này dẫn tới hai loại mô hình khác nhau, ở những cấp độ trừu tượng khác nhau. Nhầm lẫn giữa chúng là lỗi kinh điển của dev-turned-BA: bạn nhảy thẳng vào vẽ bảng vật lý trong khi stakeholder còn chưa thống nhất "Khách hàng" và "Người dùng" có phải là một thực thể hay không.
Bài này sẽ giúp bạn dùng lại kiến thức cũ một cách đúng chỗ, và bổ sung phần tư duy BA mà trường lớp dev không dạy.
Khái niệm cốt lõi
Data modeling dưới góc nhìn BA là gì
Data modeling (mô hình hóa dữ liệu) là quá trình mô tả một cách có cấu trúc: hệ thống quan tâm tới những thực thể (entity) nào, mỗi thực thể có những thuộc tính (attribute) gì, và các thực thể quan hệ (relationship) với nhau ra sao.
Khác biệt cốt lõi: BA dùng data modeling như một công cụ giao tiếp và xác nhận yêu cầu, không phải như bản thiết kế kỹ thuật cuối cùng. Mô hình của BA là cầu nối giữa ngôn ngữ nghiệp vụ ("một đơn hàng có thể chứa nhiều sản phẩm") và ngôn ngữ kỹ thuật (bảng order_items với khóa ngoại). BA vẽ để stakeholder gật đầu; developer vẽ để compiler chạy.
Ba cấp độ mô hình: Conceptual, Logical, Physical
Đây là khung xương của cả bài. Cùng một nghiệp vụ, ta mô hình hóa ở ba cấp độ trừu tượng giảm dần.
1. Conceptual Data Model (Mô hình khái niệm)
Đây là cấp cao nhất, trừu tượng nhất, và là cấp mà BA dành nhiều thời gian nhất. Ở đây ta chỉ quan tâm:
- Có những thực thể nghiệp vụ nào? (Khách hàng, Đơn hàng, Sản phẩm, Cửa hàng...)
- Chúng quan hệ với nhau thế nào? (Khách hàng đặt nhiều Đơn hàng; Đơn hàng chứa nhiều Sản phẩm)
2. Logical Data Model (Mô hình logic)
Cấp này chi tiết hơn: thêm đầy đủ thuộc tính cho từng thực thể, xác định kiểu dữ liệu logic (số, chuỗi, ngày, boolean — chưa cần biết VARCHAR(255) hay TEXT), xác định khóa chính/khóa ngoại logic, và thường được chuẩn hóa (normalization) tới 3NF để loại bỏ trùng lặp dữ liệu.
Logical model vẫn độc lập với công nghệ — nó không quan tâm bạn dùng PostgreSQL, MySQL hay MongoDB. Đây là tầng mà BA và technical lead bàn bạc kỹ với nhau. Là dev cũ, bạn sẽ thấy cực kỳ quen thuộc, vì nó gần với cách bạn nghĩ về schema, chỉ là chưa cột vào DBMS cụ thể.
3. Physical Data Model (Mô hình vật lý)
Cấp thấp nhất, gắn chặt với DBMS cụ thể: kiểu dữ liệu thật (VARCHAR(255), DECIMAL(15,2), BIGINT), tên bảng/cột thật, index, partition, constraint, denormalization vì lý do hiệu năng. Đây là lãnh địa của developer và DBA, không phải của BA. BA hiểu cấp này để đối thoại được với đội kỹ thuật, nhưng thường không phải người sản xuất ra nó.
Một cách nhớ đơn giản: Conceptual trả lời "Cái gì trong nghiệp vụ?", Logical trả lời "Dữ liệu trông như thế nào?", Physical trả lời "Lưu ra sao trong DB này?".
ERD — ngôn ngữ vẽ chung
ERD (Entity-Relationship Diagram) là ký pháp phổ biến nhất để thể hiện cả ba cấp độ trên. Là dev bạn chắc đã quen, nhưng với vai trò BA hãy nắm vững ký pháp Crow's Foot (chân quạ) vì nó thể hiện cardinality rất trực quan cho người không kỹ thuật:
- Một gạch ngang (
|): chính xác một (exactly one) - Vòng tròn (
o): không hoặc (optional, zero) - Chân quạ (
<): nhiều (many)
Khách hàng ||--o{ Đơn hàng đọc là "Một khách hàng có thể có không hoặc nhiều đơn hàng, và mỗi đơn hàng bắt buộc thuộc về đúng một khách hàng". Chính cái "không hoặc" và "bắt buộc" đó mới là phần nghiệp vụ mà BA phải khai thác — đừng bao giờ vẽ quan hệ mà không hỏi "có bắt buộc không, tối thiểu bao nhiêu, tối đa bao nhiêu".Domain Model — khác gì ERD?
Đây là điểm dễ nhầm nhất. Domain Model là mô hình mô tả các khái niệm nghiệp vụ (domain concept) cùng hành vi và quy tắc của chúng — nó xuất phát từ thế giới Domain-Driven Design (DDD), thiên về ý nghĩa nghiệp vụ, không phải về cách lưu trữ.
Sự khác biệt cốt lõi:
- ERD tập trung vào dữ liệu được lưu trữ và quan hệ giữa các bảng. Câu hỏi: "Ta cần lưu gì?"
- Domain Model tập trung vào khái niệm và ngôn ngữ nghiệp vụ (Ubiquitous Language). Câu hỏi: "Trong nghiệp vụ này, các khái niệm có nghĩa là gì và chúng tương tác ra sao?"
Tình huống thực tế
Tình huống 1: Sàn TMĐT và cú nhầm "Khách hàng = Người dùng"
Một công ty TMĐT tầm trung ở TP.HCM (tạm gọi ShopNhanh) thuê một BA vốn là backend dev. Anh này nhận yêu cầu "làm tính năng đánh giá sản phẩm" và ngay lập tức vẽ luôn physical schema: bảng reviews với cột user_id, product_id, rating, comment. Rất nhanh, rất gọn.
Nhưng khi demo conceptual model cho phòng nghiệp vụ, một chị bên CSKH hỏi: "Người mua hàng và người viết đánh giá có nhất thiết là một người không? Có khách đặt hộ cho mẹ, mẹ mới là người dùng và đánh giá đấy." Cả phòng ngớ ra. Hóa ra trong nghiệp vụ tồn tại hai khái niệm tách biệt: Tài khoản (đăng nhập, thanh toán) và Người thụ hưởng/đánh giá. Anh BA đã gộp chúng làm một vì trong đầu anh "user là user".
Bài học: Nếu anh dừng lại ở conceptual model và đối thoại với stakeholder trước khi nhảy vào schema, vấn đề này lộ ra trong 15 phút họp. Vì nhảy thẳng xuống physical, đội phải sửa schema giữa sprint, tốn thêm khoảng một tuần công. Conceptual model không phải thủ tục rườm rà — nó là nơi rẻ nhất để phát hiện hiểu sai nghiệp vụ.
Tình huống 2: Fintech và quan hệ N-N bị bỏ sót
Một startup ví điện tử ở Việt Nam (giả định tên MoMoLite) xây tính năng "ví gia đình" — nhiều người dùng chung một ví. BA ban đầu mô hình Người dùng ||--|| Ví (một người một ví). Đơn giản, ai cũng gật.
Đến khi vẽ logical model và rà lại từng cardinality với đội vận hành, BA phát hiện thực tế là N-N: một người có thể tham gia nhiều ví (ví cá nhân + ví gia đình + ví nhóm bạn), và một ví có nhiều thành viên. Quan hệ N-N này đòi hỏi một thực thể trung gian (associative entity) — tạm gọi Thành viên ví — chứa thêm thuộc tính nghiệp vụ quan trọng: vai trò (chủ ví/thành viên), hạn mức chi tiêu, ngày tham gia.
Cái thực thể trung gian đó không phải chi tiết kỹ thuật vô nghĩa — nó là nơi chứa quy tắc nghiệp vụ về phân quyền và hạn mức, thứ ảnh hưởng trực tiếp tới compliance và rủi ro gian lận.
Bài học: Mọi quan hệ N-N trong ERD đều là tín hiệu để BA đào sâu: thực thể trung gian thường giấu những thuộc tính và business rule quan trọng nhất. Đừng vội vẽ một đường N-N rồi đi tiếp; hãy hỏi "khi A gắn với B, ta cần ghi lại thêm thông tin gì về bản thân mối quan hệ đó?".
Tình huống 3: Domain Model cứu một dự án ngân hàng khỏi loạn từ vựng
Một ngân hàng số tại Việt Nam triển khai hệ thống cho vay tiêu dùng, có cả đội trong nước và đội offshore. Trong ba tuần đầu, các cuộc họp liên tục rối vì cùng một thứ mà mỗi bên gọi một kiểu: "khoản vay", "hợp đồng tín dụng", "loan", "facility", "khế ước". Có lúc dev hiểu "khoản vay" là toàn bộ hợp đồng, BA nghiệp vụ lại hiểu "khoản vay" là từng lần giải ngân.
BA trưởng (xuất thân dev, hiểu giá trị của sự chính xác) quyết định dựng một Domain Model với Ubiquitous Language rõ ràng: phân biệt Hợp đồng tín dụng (Entity, có số hợp đồng) với Lần giải ngân (Entity con) và Số tiền (Value Object). Mỗi khái niệm có một định nghĩa duy nhất, được dán lên Confluence và dùng thống nhất từ tài liệu nghiệp vụ tới tên class trong code.
Bài học: Domain Model không chỉ là sơ đồ — nó là một cam kết về ngôn ngữ chung. Trong các domain phức tạp như banking, giá trị lớn nhất của data modeling đôi khi không nằm ở các đường nối, mà ở việc cả tổ chức cuối cùng gọi cùng một tên cho cùng một thứ.
Hướng dẫn từng bước
Đây là quy trình thực chiến để bạn xây mô hình dữ liệu với tư cách BA:
Bước 1 — Thu thập danh từ nghiệp vụ. Đọc lại tài liệu yêu cầu, biên bản phỏng vấn stakeholder, và gạch chân tất cả danh từ quan trọng: Khách hàng, Đơn hàng, Sản phẩm, Khuyến mãi... Đây là ứng viên cho các thực thể. Mẹo kinh điển: danh từ thường là entity, động từ thường là relationship.
Bước 2 — Dựng Conceptual Model. Vẽ các thực thể (chỉ tên, chưa thuộc tính), nối chúng bằng động từ nghiệp vụ và xác định cardinality cho từng quan hệ. Với mỗi đường nối, hỏi đủ bốn câu: tối thiểu bao nhiêu? tối đa bao nhiêu? bắt buộc hay tùy chọn? hai chiều ra sao?
Bước 3 — Xác nhận với stakeholder nghiệp vụ. Đưa conceptual model lên họp với người không kỹ thuật. Diễn giải bằng lời: "Một khách hàng có thể có nhiều đơn, mỗi đơn thuộc đúng một khách." Để họ phản biện. Đây là bước rẻ nhất và quan trọng nhất.
Bước 4 — Phát triển thành Logical Model. Thêm thuộc tính cho từng thực thể, gán kiểu dữ liệu logic, xác định khóa chính, chuẩn hóa tới 3NF, và đặc biệt: biến mọi quan hệ N-N thành thực thể trung gian, rồi đào các thuộc tính của nó.
Bước 5 — Gắn Business Rules. Với mỗi thực thể và quan hệ, ghi chú quy tắc nghiệp vụ liên quan: "Tổng giá trị đơn hàng phải > 0", "Một khách chỉ dùng được mỗi mã khuyến mãi một lần". (Bài 24 sẽ đào sâu phần tách business rules — ở đây bạn chỉ cần đánh dấu.)
Bước 6 — Bàn giao cho đội kỹ thuật để dựng Physical Model. BA không tự vẽ physical, nhưng ngồi cùng dev/DBA để đảm bảo logical model được hiện thực đúng tinh thần nghiệp vụ, và ghi nhận lại các quyết định denormalization để tài liệu khớp thực tế.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng xuống Physical (bệnh nghề nghiệp của dev). Bạn quen nghĩ bằng CREATE TABLE nên bỏ qua conceptual. Kết quả: hiểu sai nghiệp vụ lộ ra muộn, sửa đắt. Mẹo: tự cấm mình mở công cụ vẽ DB cho tới khi stakeholder gật đầu với conceptual model.
Lỗi 2 — Mô hình quá chi tiết khi giao tiếp với người nghiệp vụ. Đưa một ERD đầy VARCHAR(255), index, FK cho chị trưởng phòng kinh doanh là cách nhanh nhất để mất họ. Mẹo: luôn có sẵn hai phiên bản — conceptual cho nghiệp vụ, logical/physical cho kỹ thuật.
Lỗi 3 — Bỏ qua cardinality tối thiểu. Dev thường chỉ nghĩ "1-N hay N-N", quên hỏi "có thể là zero không". Một đơn hàng bắt buộc phải có khách, nhưng một khách có thể chưa có đơn nào. Khác biệt này quyết định ràng buộc NOT NULL và cả luồng nghiệp vụ. Mẹo: dùng đúng ký pháp Crow's Foot để buộc mình trả lời cả phần optional.
Lỗi 4 — Coi N-N là chuyện nhỏ. Như tình huống ví điện tử, N-N luôn giấu thực thể trung gian giàu nghiệp vụ. Mẹo: gặp N-N là dừng lại đào, đừng đi tiếp.
Lỗi 5 — Lẫn lộn ERD và Domain Model. Cố nhồi mọi khái niệm nghiệp vụ thành bảng, hoặc ngược lại, bỏ qua những value object quan trọng. Mẹo: nhớ ERD = "lưu gì", Domain Model = "nghĩa là gì".
Mẹo công cụ: Với BA, ưu tiên công cụ vẽ nhanh, dễ chia sẻ: draw.io (miễn phí), Lucidchart, hoặc dbdiagram.io. Đặc biệt Mermaid (cú pháp erDiagram) rất hợp với dev cũ vì bạn viết text ra sơ đồ, nhúng thẳng vào tài liệu Confluence/Markdown và version control được — tận dụng lợi thế quen Git của bạn.
Bài tập thực hành
Hãy lấy một nghiệp vụ quen thuộc: hệ thống đặt phòng khách sạn (kiểu Booking/Agoda thu nhỏ cho một chuỗi khách sạn ở Đà Nẵng).
- Conceptual Model: Liệt kê tối thiểu 6 thực thể (gợi ý: Khách, Khách sạn, Phòng, Loại phòng, Đặt phòng, Thanh toán). Vẽ quan hệ và cardinality giữa chúng bằng ký pháp Crow's Foot. Với mỗi quan hệ, viết một câu nghiệp vụ diễn giải nó.
- Tìm quan hệ N-N: Trong mô hình của bạn, có quan hệ N-N nào không (gợi ý: một đặt phòng có thể gồm nhiều phòng, một phòng qua thời gian được nhiều lượt đặt)? Nếu có, hãy tạo thực thể trung gian và liệt kê ít nhất 3 thuộc tính nghiệp vụ của nó.
- Logical Model: Chọn 3 thực thể, thêm đầy đủ thuộc tính, kiểu dữ liệu logic, khóa chính và khóa ngoại. Chuẩn hóa tới 3NF.
- Domain Model nhỏ: Xác định trong nghiệp vụ này đâu là Entity, đâu là Value Object (gợi ý: "Khoảng thời gian lưu trú" và "Giá tiền" là value object). Viết Ubiquitous Language: định nghĩa ngắn gọn cho 5 khái niệm để cả team dùng chung.
- Tự phản biện: Tìm một chỗ trong mô hình mà nếu bạn nhảy thẳng vào physical schema, bạn sẽ hiểu sai nghiệp vụ. Viết 3 câu hỏi bạn sẽ đặt cho stakeholder để làm rõ.
Tóm tắt
- Là dev chuyển sang BA, bạn có nền data modeling sẵn, nhưng phải đổi mục tiêu: từ "để máy chạy" sang "để con người hiểu và thống nhất nghiệp vụ".
- Nắm vững ba cấp độ: Conceptual (cái gì — BA dành nhiều thời gian nhất, dùng để chốt nghiệp vụ), Logical (trông thế nào — chi tiết, chuẩn hóa, độc lập DBMS), Physical (lưu ra sao — lãnh địa của dev/DBA).
- ERD trả lời "lưu gì", dùng ký pháp Crow's Foot để thể hiện cardinality trực quan; Domain Model trả lời "nghĩa là gì", thống nhất Ubiquitous Language và phân biệt Entity với Value Object.
- Lỗi chí mạng của dev-turned-BA là nhảy thẳng xuống physical — hãy ép mình dừng ở conceptual cho tới khi stakeholder gật đầu.
- Mọi quan hệ N-N đều giấu một thực thể trung gian giàu nghiệp vụ — gặp là đào.
- Mô hình tốt là mô hình bạn có thể giải thích trôi chảy bằng lời cho người không biết SQL. Đó mới là giá trị BA.