Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn được giao nhiệm vụ xây một ngôi nhà. Trước khi đặt viên gạch đầu tiên, kiến trúc sư phải vẽ bản thiết kế: phòng nào nằm ở đâu, cầu thang đặt chỗ nào, đường ống nước chạy ra sao. Nếu bỏ qua bước này, bạn sẽ có một ngôi nhà mà phòng ngủ thông thẳng vào nhà bếp, hoặc nhà vệ sinh không có đường thoát nước. Data modeling (mô hình hóa dữ liệu) chính là bản thiết kế đó — nhưng cho dữ liệu của một hệ thống phần mềm.
Với người làm Business Analyst (BA), data modeling không phải là việc "của dân kỹ thuật". Đó là ngôn ngữ chung giúp bạn dịch yêu cầu nghiệp vụ mơ hồ của khách hàng thành một cấu trúc dữ liệu rõ ràng mà lập trình viên có thể xây dựng. Khi một chủ doanh nghiệp nói "Tôi cần quản lý khách hàng và đơn hàng", chính bạn là người phải bóc tách câu nói đó ra thành: khách hàng là gì, đơn hàng là gì, một khách hàng có thể có bao nhiêu đơn hàng, mỗi đơn hàng chứa những thông tin nào. Đó là data modeling.
Bài học đầu tiên này đặt nền móng cho cả khóa. Chúng ta sẽ làm quen với khái niệm data model là gì, và đặc biệt là ba cấp độ (3 levels) của mô hình dữ liệu — Conceptual, Logical, và Physical. Hiểu được ba cấp độ này, bạn sẽ biết mình đang đứng ở đâu trong quá trình thiết kế, nói chuyện với đối tượng nào, và chi tiết đến mức nào là đủ. Đây là tấm bản đồ tổng quan trước khi chúng ta đi sâu vào từng thành phần ở các bài sau.
Khái niệm cốt lõi
Data model là gì?
Data model là một biểu diễn trừu tượng về cách dữ liệu được tổ chức, lưu trữ và liên kết với nhau trong một hệ thống. Nói đơn giản, nó trả lời ba câu hỏi: Chúng ta cần lưu những thông tin gì? Các thông tin đó liên quan với nhau ra sao? Và sẽ được lưu trữ như thế nào?
Một data model tốt giống như một cuộc đối thoại được ghi lại bằng sơ đồ. Nó giúp các bên — khách hàng, BA, lập trình viên, kiểm thử viên — cùng nhìn vào một bức tranh và hiểu giống nhau. Thay vì tranh cãi bằng lời nói dễ gây hiểu lầm, mọi người chỉ vào sơ đồ và nói "À, một khách hàng có nhiều đơn hàng, đúng chưa?".
Vì sao phải chia thành 3 cấp độ?
Đây là điểm cốt lõi của bài học. Một sai lầm phổ biến của người mới là cố vẽ tất cả mọi thứ cùng một lúc: vừa nghĩ về nghiệp vụ, vừa lo kiểu dữ liệu, vừa tính chuyện đánh index. Kết quả là một mớ hỗn độn vừa khó hiểu với khách hàng, vừa thiếu chi tiết cho lập trình viên.
Giới chuyên môn giải quyết vấn đề này bằng cách tách quá trình thiết kế thành ba cấp độ trừu tượng, đi từ trừu tượng cao nhất (gần với con người, gần với nghiệp vụ) xuống cụ thể nhất (gần với máy tính, gần với database). Mỗi cấp độ phục vụ một đối tượng khác nhau và trả lời một loại câu hỏi khác nhau.
Cấp độ 1 — Conceptual Data Model (Mô hình khái niệm)
Đây là cấp độ cao nhất, mang tính nghiệp vụ thuần túy.
- Mục tiêu: Nắm bắt bức tranh tổng thể về nghiệp vụ. Trong hệ thống này có những "thực thể" (entity) chính nào và chúng liên hệ với nhau ra sao.
- Thành phần: Chỉ gồm các entity (ví dụ: Khách Hàng, Đơn Hàng, Sản Phẩm) và các mối quan hệ (relationship) giữa chúng. Không có thuộc tính chi tiết, không có kiểu dữ liệu, không có khóa.
- Đối tượng (audience): Lãnh đạo, chủ doanh nghiệp, các bên liên quan nghiệp vụ — những người không quan tâm đến kỹ thuật.
- Ví dụ diễn đạt: "Một KHÁCH HÀNG đặt nhiều ĐƠN HÀNG. Mỗi ĐƠN HÀNG chứa nhiều SẢN PHẨM."
Cấp độ 2 — Logical Data Model (Mô hình logic)
Khi nghiệp vụ đã rõ, ta đi xuống một bậc để bổ sung chi tiết, nhưng vẫn độc lập với công nghệ database cụ thể.
- Mục tiêu: Mô tả đầy đủ cấu trúc dữ liệu một cách chính xác về mặt logic, không phụ thuộc vào việc sau này dùng MySQL, PostgreSQL hay SQL Server.
- Thành phần: Mỗi entity giờ có đầy đủ các thuộc tính (attribute). Ví dụ entity Khách Hàng có: họ tên, số điện thoại, email, ngày sinh. Có khóa chính (primary key) để định danh, có khóa ngoại (foreign key) thể hiện mối quan hệ. Mô hình thường được chuẩn hóa (normalized) để loại bỏ dữ liệu trùng lặp.
- Đối tượng: BA, kiến trúc sư dữ liệu (data architect), trưởng nhóm phát triển.
- Ví dụ diễn đạt: Entity ĐƠN HÀNG gồm mã đơn hàng (khóa chính), ngày đặt, tổng tiền, và mã khách hàng (khóa ngoại trỏ về KHÁCH HÀNG).
Cấp độ 3 — Physical Data Model (Mô hình vật lý)
Đây là cấp độ thấp nhất, cụ thể nhất, gắn chặt với một hệ quản trị cơ sở dữ liệu (DBMS) cụ thể.
- Mục tiêu: Mô tả chính xác cách dữ liệu được hiện thực hóa trong database thật.
- Thành phần: Tên bảng (table) thật, tên cột thật, kiểu dữ liệu cụ thể (VARCHAR(255), INT, DECIMAL(15,2), DATETIME...), index, ràng buộc (constraint), và các yếu tố tối ưu hiệu năng.
- Đối tượng: Lập trình viên backend, quản trị viên cơ sở dữ liệu (DBA).
- Ví dụ diễn đạt: Bảng
don_hangcó cộtma_don_hang BIGINT PRIMARY KEY AUTO_INCREMENT,ngay_dat DATETIME NOT NULL,tong_tien DECIMAL(15,2),ma_khach_hang BIGINT, kèm một index trên cộtma_khach_hang.
CREATE TABLE để dựng database.Mạch chảy từ trừu tượng đến cụ thể
Điểm quan trọng cần khắc cốt ghi tâm: ba cấp độ này không phải ba thứ tách rời, mà là ba lần phóng to dần của cùng một bức tranh. Conceptual trả lời "Cái gì?", Logical trả lời "Như thế nào về mặt logic?", và Physical trả lời "Hiện thực ra sao trong database?". Bạn đi từ ngôn ngữ của con người dần dần xuống ngôn ngữ của máy tính.
Tình huống thực tế
Tình huống 1 — Tiệm bánh Như Lan mở rộng lên hệ thống đặt hàng online
Tiệm bánh Như Lan ở TP.HCM muốn xây một ứng dụng đặt bánh online. Chị chủ tiệm nói với BA: "Tôi cần khách đặt bánh qua app, chọn loại bánh, rồi shipper giao tới nhà."
Ở cấp conceptual, BA ngồi với chị chủ và vẽ ra bốn entity: KHÁCH HÀNG, ĐƠN HÀNG, BÁNH (sản phẩm), và NHÂN VIÊN GIAO HÀNG. Mối quan hệ: một khách hàng đặt nhiều đơn; một đơn chứa nhiều loại bánh; một đơn được giao bởi một nhân viên. Chị chủ — vốn không rành công nghệ — nhìn vào sơ đồ và lập tức bổ sung: "À, thiếu rồi, đơn hàng phải có khuyến mãi nữa, tôi hay tặng voucher." Thế là entity KHUYẾN MÃI được thêm vào. Toàn bộ cuộc trao đổi này không hề nhắc đến database.
Sang cấp logical, BA bổ sung thuộc tính: KHÁCH HÀNG có số điện thoại (dùng làm định danh vì ở Việt Nam số điện thoại gần như là duy nhất), tên, địa chỉ. ĐƠN HÀNG có ngày đặt, trạng thái, tổng tiền. BÁNH có tên, giá, loại.
Đến cấp physical, lập trình viên quyết định dùng MySQL, đặt tên bảng khach_hang, don_hang, cột so_dien_thoai VARCHAR(15), tong_tien DECIMAL(12,2) (vì giá trị tiền Việt Nam cần đủ chữ số), và thêm index trên so_dien_thoai để tra cứu nhanh.
Bài học: Việc tách cấp độ giúp chị chủ tiệm — người không biết gì về kỹ thuật — vẫn tham gia thiết kế được ở cấp conceptual và phát hiện thiếu sót sớm. Nếu BA lao thẳng vào bàn VARCHAR với chị, cuộc họp đã đổ bể.
Tình huống 2 — Ngân hàng số sửa sai vì bỏ qua cấp conceptual
Một ngân hàng số tại Việt Nam (gọi là Ngân hàng X) từng vội vã xây hệ thống quản lý tài khoản. Đội kỹ thuật nhảy thẳng vào physical model, tạo ngay bảng tai_khoan gộp luôn cả thông tin khách hàng vào cùng một bảng. Họ nghĩ "một khách thì một tài khoản, gộp cho gọn".
Sáu tháng sau, nghiệp vụ thay đổi: một khách hàng được phép mở nhiều tài khoản (thanh toán, tiết kiệm, ngoại tệ). Vì đã gộp khách hàng và tài khoản vào một bảng, mỗi lần khách mở tài khoản mới, toàn bộ thông tin cá nhân (tên, CCCD, địa chỉ) lại bị lặp lại. Khi khách đổi địa chỉ, hệ thống phải cập nhật ở nhiều dòng, dẫn đến tình trạng dữ liệu mâu thuẫn — có dòng địa chỉ cũ, có dòng địa chỉ mới.
Nếu họ bắt đầu từ conceptual model, ngay từ đầu họ đã đặt câu hỏi nghiệp vụ: "Một khách hàng có thể có bao nhiêu tài khoản?" Câu trả lời "nhiều" sẽ buộc KHÁCH HÀNG và TÀI KHOẢN trở thành hai entity riêng với quan hệ một-nhiều, và sự cố trên không bao giờ xảy ra.
Bài học: Bỏ qua cấp conceptual để "tiết kiệm thời gian" thường khiến bạn trả giá đắt gấp nhiều lần ở giai đoạn sau. Cấp độ trừu tượng cao nhất chính là nơi bắt được những sai lầm nghiệp vụ tốn kém nhất.
Tình huống 3 — Cùng một logical model, hai physical model khác nhau
Công ty thương mại điện tử Tiki và một startup nhỏ cùng cần một logical model giống hệt nhau cho phần giỏ hàng: KHÁCH HÀNG, GIỎ HÀNG, SẢN PHẨM với các thuộc tính tương tự.
Tuy nhiên ở cấp physical, hai bên rẽ hướng. Startup nhỏ với vài nghìn người dùng chọn PostgreSQL đơn giản, lưu giỏ hàng trong một bảng quan hệ bình thường. Còn một sàn lớn với hàng triệu người dùng đồng thời có thể chọn lưu giỏ hàng tạm trong Redis (một dạng lưu trữ tốc độ cao trên bộ nhớ) để chịu tải, rồi mới ghi xuống database quan hệ khi khách thanh toán. Cùng một logical model, nhưng physical model khác nhau hoàn toàn vì quy mô và công nghệ khác nhau.
Bài học: Logical model độc lập với công nghệ chính là tài sản quý nhất của BA. Nó mô tả "đúng" về mặt nghiệp vụ và logic, để rồi tùy bối cảnh kỹ thuật, đội ngũ có thể hiện thực hóa thành nhiều physical model khác nhau mà không phải làm lại từ đầu.
Hướng dẫn từng bước
Khi bắt đầu mô hình hóa dữ liệu cho một hệ thống mới, hãy đi theo trình tự sau:
- Lắng nghe và thu thập nghiệp vụ. Trò chuyện với các bên liên quan, ghi lại bằng ngôn ngữ tự nhiên. Tìm những "danh từ" quan trọng — chúng thường là ứng viên cho entity (khách hàng, đơn hàng, sản phẩm).
- Dựng Conceptual Model. Vẽ các entity chính và mối quan hệ giữa chúng. Giữ thật đơn giản, không thuộc tính, không kỹ thuật. Đem sơ đồ này đi xác nhận lại với khách hàng cho đến khi mọi người đồng thuận về bức tranh tổng thể.
- Phát triển thành Logical Model. Bổ sung thuộc tính cho từng entity, xác định khóa chính để định danh, và khóa ngoại để thể hiện quan hệ. Đảm bảo mô hình hợp lý về mặt logic và tránh trùng lặp dữ liệu. Vẫn chưa cần quan tâm dùng database nào.
- Chuyển sang Physical Model. Chọn DBMS cụ thể. Đặt tên bảng, tên cột theo quy ước, gán kiểu dữ liệu phù hợp, thêm ràng buộc, index và các tối ưu cần thiết.
- Rà soát ngược. Sau khi có physical model, hãy kiểm tra ngược lên: nó có còn phản ánh đúng conceptual model ban đầu không? Nếu trong quá trình kỹ thuật bạn đã "bẻ" mất một mối quan hệ nghiệp vụ quan trọng, đây là lúc phát hiện.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào physical model. Đây là cái bẫy số một của người mới và cả của những lập trình viên nóng vội. Họ mở ngay công cụ database và tạo bảng. Hậu quả là cấu trúc dữ liệu bị đóng khung theo suy nghĩ kỹ thuật ban đầu, bỏ lỡ những hiểu biết nghiệp vụ quan trọng. Mẹo: luôn ép bản thân vẽ conceptual trước, dù chỉ trong năm phút.
Lỗi 2 — Lẫn lộn các cấp độ. Đưa kiểu dữ liệu VARCHAR vào conceptual model, hoặc ngược lại, trình bày physical model cho lãnh đạo nghiệp vụ rồi ngạc nhiên khi họ không hiểu gì. Mẹo: trước khi vẽ, tự hỏi "Ai sẽ đọc cái này?" để chọn đúng cấp độ.
Lỗi 3 — Coi data model là tài liệu chết. Nghiệp vụ thay đổi thì data model phải thay đổi. Một model lỗi thời còn nguy hiểm hơn không có model, vì nó khiến mọi người tin vào thông tin sai. Mẹo: gắn việc cập nhật model vào quy trình mỗi khi yêu cầu thay đổi.
Lỗi 4 — Quá tham lam ở conceptual. Một số BA cố nhồi nhét hàng chục entity và thuộc tính vào sơ đồ khái niệm khiến khách hàng choáng ngợp. Mẹo: conceptual model lý tưởng chỉ nên gói gọn trong khoảng 5–10 entity cốt lõi để dễ nắm bắt.
Mẹo vàng: Khi bí, hãy luôn quay về câu hỏi gốc của ba cấp độ — Cái gì? (conceptual) → Logic ra sao? (logical) → Hiện thực thế nào? (physical). Ba câu hỏi này là la bàn cho mọi quyết định mô hình hóa.
Bài tập thực hành
Hãy chọn một tình huống quen thuộc: một phòng khám nha khoa nhỏ ở Hà Nội muốn xây hệ thống quản lý lịch hẹn và hồ sơ bệnh nhân.
- Bài tập conceptual: Liệt kê 4–6 entity chính mà bạn nghĩ hệ thống cần (gợi ý: bệnh nhân, bác sĩ, lịch hẹn...). Vẽ tay mối quan hệ giữa chúng bằng các câu dạng "Một X có nhiều Y". Chưa cần thuộc tính.
- Bài tập logical: Chọn entity LỊCH HẸN và liệt kê tối thiểu 5 thuộc tính cho nó. Chỉ ra đâu là khóa chính, và thuộc tính nào là khóa ngoại trỏ tới entity khác.
- Bài tập physical: Với entity LỊCH HẸN ở trên, hãy phác thảo nó thành một bảng database giả định: đặt tên bảng, tên cột, và đề xuất kiểu dữ liệu phù hợp cho từng cột (ví dụ thời gian hẹn nên dùng kiểu gì).
- Tự phản tư: Viết một đoạn ngắn 3–4 câu giải thích vì sao bạn sẽ trình bày kết quả ở bước 1 cho chủ phòng khám, nhưng trình bày kết quả ở bước 3 cho lập trình viên.
Tóm tắt
Data modeling là kỹ năng nền tảng giúp BA biến yêu cầu nghiệp vụ thành cấu trúc dữ liệu rõ ràng cho cả đội cùng hiểu. Trái tim của bài học hôm nay là ba cấp độ của mô hình dữ liệu:
- Conceptual — bức tranh nghiệp vụ tổng thể, chỉ gồm entity và quan hệ, dành cho lãnh đạo và khách hàng. Trả lời câu hỏi Cái gì?
- Logical — chi tiết đầy đủ về thuộc tính, khóa và quan hệ, độc lập với công nghệ, dành cho BA và kiến trúc sư. Trả lời câu hỏi Logic ra sao?
- Physical — hiện thực cụ thể trong một database thật với bảng, cột, kiểu dữ liệu, index, dành cho lập trình viên và DBA. Trả lời câu hỏi Hiện thực thế nào?