Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn được mời vào một cuộc họp khởi động dự án với ban giám đốc một chuỗi siêu thị. Họ muốn xây hệ thống quản lý khách hàng thân thiết. Bạn — với tư cách BA (Business Analyst) — bắt đầu vẽ bảng, cột, kiểu dữ liệu VARCHAR(255), khóa ngoại... Ngay lập tức, ánh mắt của vị Giám đốc Marketing đờ ra. Ông ấy không quan tâm customer_id là BIGINT hay UUID. Ông ấy chỉ muốn biết: "Một khách hàng có thể có nhiều thẻ thành viên không? Một đơn mua hàng có gắn với một cửa hàng cụ thể không? Điểm thưởng tính theo khách hay theo thẻ?"
Đó chính xác là lý do Conceptual Data Model (CDM) — Mô hình dữ liệu mức khái niệm tồn tại. Nó là bản vẽ ở độ cao lớn nhất, nơi bạn và những người ra quyết định kinh doanh cùng nhìn vào một bức tranh chung về dữ liệu gì tồn tại trong nghiệp vụ và chúng liên hệ với nhau ra sao — mà tuyệt nhiên không vướng vào một chi tiết kỹ thuật nào.
Trong toàn bộ hành trình mô hình hóa dữ liệu (Conceptual → Logical → Physical) mà bạn sẽ học ở các bài sau, CDM là tầng đầu tiên và cũng là tầng dễ bị bỏ qua nhất. Nhiều BA non kinh nghiệm nhảy thẳng vào thiết kế bảng, để rồi ba tháng sau phát hiện ra mình đã hiểu sai bản chất nghiệp vụ. Bài này giúp bạn làm chủ tầng quan trọng nhất để "chốt" sự đồng thuận với stakeholder trước khi một dòng SQL nào được viết ra.
Khái niệm cốt lõi
Conceptual Data Model là gì?
Conceptual Data Model là biểu diễn trừu tượng, mức cao về dữ liệu của một tổ chức, chỉ gồm hai thành phần chính:
- Entities (thực thể) — những "thứ" mà doanh nghiệp quan tâm và cần lưu thông tin: Khách hàng, Đơn hàng, Sản phẩm, Cửa hàng, Nhân viên.
- Relationships (mối quan hệ) — cách các thực thể đó liên kết với nhau: một Khách hàng đặt nhiều Đơn hàng, một Đơn hàng chứa nhiều Sản phẩm.
- Không có kiểu dữ liệu (data type), không có độ dài cột.
- Không có khóa chính/khóa ngoại cụ thể (primary key, foreign key) — bạn sẽ học sâu ở Bài 6.
- Không có bảng trung gian cho quan hệ nhiều-nhiều.
- Không quan tâm hệ quản trị CSDL nào (MySQL, PostgreSQL, Oracle).
- Thường chỉ liệt kê vài thuộc tính tiêu biểu mang ý nghĩa nghiệp vụ, chứ không liệt kê toàn bộ.
Đối tượng khán giả (audience) của CDM
Đây là điểm phân biệt cốt lõi. CDM được tạo ra để giao tiếp với những người không phải kỹ thuật:
- Ban lãnh đạo, giám đốc nghiệp vụ (business stakeholder).
- Chủ sở hữu sản phẩm (product owner), chuyên viên nghiệp vụ phòng ban.
- Khách hàng dự án (client) trong các công ty outsourcing.
tbl_cust hay txn_master. Một CDM tốt là tấm bản đồ mà bất kỳ trưởng phòng nào cũng đọc được mà không cần bạn giải thích từng ký hiệu.Vị trí của CDM trong ba tầng mô hình
| Tiêu chí | Conceptual (Bài 9) | Logical (Bài 10) | Physical (Bài 11) |
|---|---|---|---|
| Mục tiêu | Hiểu nghiệp vụ | Cấu trúc dữ liệu chuẩn hóa | Triển khai trên DBMS |
| Khán giả | Lãnh đạo, nghiệp vụ | BA, kiến trúc sư dữ liệu | DBA, developer |
| Khóa, kiểu dữ liệu | Không | Có khóa logic, không kiểu DBMS | Đầy đủ, theo DBMS |
| Quan hệ nhiều-nhiều | Vẽ trực tiếp | Tách bảng nối | Tách bảng nối + chỉ mục |
Mức độ chi tiết vừa đủ
Một CDM điển hình cho một hệ thống cỡ vừa thường chỉ có khoảng 7 đến 15 thực thể. Nếu sơ đồ của bạn phình lên 40 thực thể với hàng trăm thuộc tính, gần như chắc chắn bạn đã trượt xuống tầng logical mà không nhận ra. CDM phải "vừa một trang giấy A4" để giám đốc nhìn vào trong 30 giây là nắm được bức tranh.
Tình huống thực tế
Tình huống 1 — Tiki và bài học "đặt tên theo nghiệp vụ"
Giả sử một nhóm BA tại một sàn thương mại điện tử lớn như Tiki khởi động dự án nâng cấp hệ thống đánh giá sản phẩm. Trong buổi workshop đầu tiên, BA vẽ ngay một sơ đồ với các bảng review_tbl, usr, prod, kèm cột rt (rating) kiểu TINYINT. Phía nghiệp vụ ngồi im, gật gù cho qua chuyện.
Ba tuần sau, khi demo, Giám đốc Trải nghiệm khách hàng mới phát hiện: trong mô hình, mỗi Đánh giá chỉ gắn với một Khách hàng và một Sản phẩm. Nhưng nghiệp vụ thực tế của họ là đánh giá phải gắn với Đơn hàng đã hoàn tất — chỉ người đã mua mới được đánh giá. Cả một mảng logic chống đánh giá giả mạo đã bị bỏ sót, chỉ vì sơ đồ kỹ thuật che mất bản chất nghiệp vụ.
Nhóm làm lại bằng đúng tinh thần CDM: vẽ bốn thực thể bằng tiếng Việt — Khách hàng, Đơn hàng, Sản phẩm, Đánh giá — với mối quan hệ rõ ràng: Khách hàng tạo Đánh giá, Đánh giá tham chiếu đến một Sản phẩm trong một Đơn hàng đã mua. Lần này, ngay trong 10 phút đầu workshop, phía nghiệp vụ chỉ ra được lỗ hổng.
Bài học: Khi sơ đồ nói bằng ngôn ngữ nghiệp vụ và bỏ hết nhiễu kỹ thuật, stakeholder mới thực sự đọc được và phản biện được. CDM không chỉ là tài liệu — nó là công cụ moi ra yêu cầu ẩn.
Tình huống 2 — Công ty bảo hiểm và quan hệ nhiều-nhiều
Một công ty bảo hiểm nhân thọ tại TP.HCM (ta gọi là Bảo An Life) thuê đội BA xây hệ thống quản lý hợp đồng. Buổi vẽ CDM với ban giám đốc, đội BA đề xuất các thực thể: Khách hàng, Hợp đồng bảo hiểm, Sản phẩm bảo hiểm, Đại lý (tư vấn viên), Yêu cầu bồi thường.
Khi vẽ mối quan hệ giữa Khách hàng và Hợp đồng, đội BA ban đầu vẽ "một Khách hàng có một Hợp đồng". Vị Phó tổng phụ trách kinh doanh lập tức phản đối: "Không, khách VIP của chúng tôi mua tới 3-4 hợp đồng: bảo hiểm sức khỏe cho bản thân, bảo hiểm giáo dục cho con, bảo hiểm hưu trí. Và một hợp đồng có thể có nhiều người được bảo hiểm."
Đây là khoảnh khắc CDM tỏa sáng. Đội BA sửa ngay trên sơ đồ: một Khách hàng ký nhiều Hợp đồng (one-to-many), và một Hợp đồng bảo vệ nhiều Người được bảo hiểm, một Người được bảo hiểm có thể nằm trong nhiều Hợp đồng (many-to-many). Họ vẽ thẳng mối quan hệ nhiều-nhiều này như một đường nối — không tách bảng trung gian, vì đó là việc của tầng logical. Cuộc họp tập trung vào việc liệu nghiệp vụ có đúng vậy không, chứ không sa đà vào kỹ thuật.
Bài học: Cardinality (bản số — bạn sẽ học ký hiệu chi tiết ở Bài 8) là thứ duy nhất về "số lượng" mà CDM cần thể hiện. Và chính những cuộc tranh luận về "một hay nhiều" này mới là giá trị lớn nhất của buổi vẽ CDM — nó phơi bày các giả định sai về nghiệp vụ trước khi chúng trở thành lỗi tốn kém trong code.
Tình huống 3 — Startup giao đồ ăn và cái bẫy "vẽ quá chi tiết"
Một startup giao đồ ăn ở Hà Nội (gọi là FoodFast) có một BA rất chăm chỉ. Khi được giao vẽ CDM cho hệ thống đặt món, anh dành cả tuần và mang đến cuộc họp một sơ đồ khổng lồ: 38 thực thể, mỗi thực thể đầy đủ 15-20 thuộc tính với cả created_at, updated_at, is_deleted, kèm các bảng nối order_item_mapping, restaurant_category_junction...
Kết quả? Buổi họp với ban giám đốc kéo dài 2 tiếng mà không ai hiểu gì. Mọi người mải đếm các ô vuông li ti, CEO bỏ về giữa chừng. Yêu cầu nghiệp vụ cốt lõi — "tài xế có thể nhận nhiều đơn cùng lúc trong một chuyến giao gộp không?" — chẳng ai kịp thảo luận.
Người mentor của anh yêu cầu làm lại trên một trang giấy duy nhất, chỉ 9 thực thể: Khách hàng, Nhà hàng, Món ăn, Đơn hàng, Tài xế, Chuyến giao, Thanh toán, Khuyến mãi, Đánh giá. Mỗi thực thể chỉ ghi 2-3 thuộc tính tiêu biểu. Lần này buổi họp chỉ mất 40 phút và làm rõ được mô hình "một Chuyến giao gộp nhiều Đơn hàng" — đúng câu hỏi cốt lõi.
Bài học: "Conceptual" nghĩa là trừu tượng và súc tích. Sự cám dỗ lớn nhất của BA là vẽ quá nhiều. Hãy nhớ: nếu lãnh đạo không nắm được bức tranh trong vòng một phút, CDM của bạn đã thất bại.
Hướng dẫn từng bước
Dưới đây là quy trình bảy bước để xây một Conceptual Data Model vững chắc.
Bước 1 — Thu thập danh từ nghiệp vụ. Đọc kỹ tài liệu yêu cầu, biên bản phỏng vấn, user story. Gạch chân tất cả các danh từ lặp đi lặp lại: khách hàng, đơn hàng, sản phẩm, hóa đơn, kho, nhân viên... Đây là kỹ thuật "noun analysis" kinh điển. Danh từ là ứng viên cho thực thể.
Bước 2 — Lọc ra thực thể thật sự. Không phải danh từ nào cũng thành thực thể. Hỏi: "Doanh nghiệp có cần lưu nhiều bản ghi của thứ này, mỗi bản có thông tin riêng không?" Nếu có — đó là thực thể (Khách hàng). Nếu nó chỉ là một thuộc tính của thứ khác (màu sắc, trạng thái) — chưa phải thực thể. (Định nghĩa và phân loại thực thể được đào sâu ở Bài 4.)
Bước 3 — Đặt tên theo ngôn ngữ nghiệp vụ. Dùng danh từ số ít, tiếng Việt rõ nghĩa hoặc thuật ngữ chuẩn của ngành. "Hợp đồng bảo hiểm", không phải policy_tbl.
Bước 4 — Xác định mối quan hệ. Với từng cặp thực thể, hỏi: "Chúng có liên hệ gì không, và bằng động từ nào?" Khách hàng đặt Đơn hàng. Đơn hàng chứa Sản phẩm. Ghi động từ lên đường nối — nó kể câu chuyện nghiệp vụ.
Bước 5 — Xác định bản số (cardinality). Với mỗi mối quan hệ, hỏi hai chiều: "Một A liên kết với bao nhiêu B? Một B liên kết với bao nhiêu A?" Trả lời bằng one-to-one, one-to-many, hay many-to-many. Đây là bước quan trọng nhất để moi ra giả định nghiệp vụ.
Bước 6 — Thêm vài thuộc tính tiêu biểu (tùy chọn). Chỉ ghi 2-4 thuộc tính mang ý nghĩa nghiệp vụ cho mỗi thực thể, ví dụ Khách hàng: Họ tên, Số điện thoại, Hạng thành viên. Bỏ qua mọi thuộc tính kỹ thuật.
Bước 7 — Xác nhận với stakeholder. Trình bày sơ đồ, đi từng mối quan hệ và đọc to thành câu: "Một khách hàng có thể đặt nhiều đơn hàng, đúng không ạ?" Chính nghi thức đọc to này giúp phát hiện hiểu lầm. Ghi nhận phản hồi, sửa, lặp lại cho đến khi tất cả gật đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Đưa chi tiết kỹ thuật vào. Thấy VARCHAR, NOT NULL, hay khóa ngoại trong CDM là dấu hiệu bạn đã trượt tầng. Hãy xóa hết. Mẹo: tự hỏi "Giám đốc Marketing có quan tâm dòng này không?" Nếu không — bỏ.
Lỗi 2 — Vẽ quá nhiều thực thể. Như tình huống FoodFast. Mẹo: đặt giới hạn cứng, ví dụ tối đa 15 thực thể cho một CDM. Nếu vượt, gom nhóm hoặc tách thành nhiều CDM theo miền nghiệp vụ (domain).
Lỗi 3 — Đặt tên kỹ thuật khó hiểu. txn, mst, dim_cust khiến nghiệp vụ mù tịt. Mẹo: nếu một người mới vào công ty đọc nhãn mà không hiểu, hãy đổi tên.
Lỗi 4 — Bỏ qua bước xác định cardinality. Đây là lỗi đắt giá nhất, vì nó giấu các giả định sai về nghiệp vụ. Mẹo: với mọi đường nối, luôn buộc mình trả lời câu hỏi "một-hay-nhiều" theo cả hai chiều.
Lỗi 5 — Bỏ qua bước xác nhận. Vẽ xong rồi cất vào ngăn kéo, không ai duyệt. CDM mất hết giá trị. Mẹo: coi CDM là biên bản đồng thuận, bắt buộc có chữ ký (hoặc email xác nhận) của chủ nghiệp vụ.
Mẹo vàng: Vẽ CDM ngay trên bảng trắng cùng stakeholder, theo thời gian thực, thay vì vẽ sẵn ở nhà rồi mang đến trình bày. Quá trình cùng vẽ chính là quá trình moi yêu cầu hiệu quả nhất.
Bài tập thực hành
Bài tập 1 — Phân tích danh từ. Cho đoạn mô tả nghiệp vụ một phòng khám tư: "Bệnh nhân đến đặt lịch khám với một bác sĩ. Mỗi lần khám, bác sĩ kê một đơn thuốc gồm nhiều loại thuốc. Phòng khám xuất hóa đơn cho mỗi lần khám." Hãy gạch chân các danh từ, lọc ra 5-6 thực thể, và đặt tên nghiệp vụ cho chúng.
Bài tập 2 — Xác định bản số. Với các thực thể vừa tìm được ở Bài tập 1, hãy xác định mối quan hệ và cardinality giữa: (a) Bệnh nhân và Lịch khám, (b) Lịch khám và Bác sĩ, (c) Đơn thuốc và Thuốc. Viết mỗi quan hệ thành một câu tiếng Việt đầy đủ.
Bài tập 3 — Vẽ CDM hoàn chỉnh. Vẽ sơ đồ Conceptual Data Model cho phòng khám trên một trang giấy hoặc dùng công cụ vẽ tự do. Tối đa 7 thực thể, mỗi thực thể ghi 2-3 thuộc tính nghiệp vụ, ghi động từ lên các đường nối. Tuyệt đối không thêm kiểu dữ liệu hay khóa.
Bài tập 4 — Tự phản biện. Đọc to từng mối quan hệ trong sơ đồ của bạn như đang trình bày với bác sĩ trưởng. Bạn có phát hiện giả định nào đáng ngờ không? Ví dụ: "Một lần khám chỉ có một bác sĩ" — liệu có trường hợp hội chẩn nhiều bác sĩ không? Ghi lại ít nhất hai câu hỏi bạn sẽ đem hỏi nghiệp vụ.
Tóm tắt
Conceptual Data Model là tầng cao nhất và trừu tượng nhất trong mô hình hóa dữ liệu, được sinh ra để giao tiếp với người ra quyết định kinh doanh — không phải với máy tính. Nó chỉ gồm thực thể và mối quan hệ (kèm bản số), được đặt tên bằng ngôn ngữ nghiệp vụ, và cố tình loại bỏ mọi chi tiết kỹ thuật như kiểu dữ liệu, khóa, hay bảng trung gian.
Giá trị thật của CDM không nằm ở bản vẽ đẹp, mà ở những cuộc đối thoại mà nó kích hoạt: chính lúc bạn hỏi "một khách hàng có nhiều hợp đồng không?" là lúc các giả định sai về nghiệp vụ bị phơi bày — rẻ tiền để sửa trên giấy, đắt đỏ để sửa trong code. Ba tình huống Tiki, Bảo An Life và FoodFast cho thấy ba bài học cốt lõi: đặt tên theo nghiệp vụ, tận dụng cardinality để moi yêu cầu, và giữ sơ đồ thật súc tích.
Hãy luôn nhớ câu thần chú: CDM trả lời "CÁI GÌ", không phải "NHƯ THẾ NÀO". Khi bạn đã chốt được sự đồng thuận ở tầng này, hành trình xuống Logical Model (Bài 10) sẽ trở nên vững vàng và ít rủi ro hơn rất nhiều.