Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Business Analyst (BA) trong một dự án xây dựng ứng dụng đặt vé xem phim. Khách hàng nói: "Tôi muốn người dùng đặt vé, chọn ghế, thanh toán, rồi nhận vé điện tử." Nghe thì đơn giản, nhưng khi đội phát triển bắt tay vào làm, hàng loạt câu hỏi nảy sinh: Một người dùng có thể đặt nhiều vé không? Một vé gắn với mấy ghế? Nếu hai người cùng chọn một ghế thì sao? Dữ liệu suất chiếu lưu thế nào để biết phim nào, rạp nào, giờ nào?
Nếu BA chỉ mô tả yêu cầu bằng câu chữ, đội phát triển sẽ tự hiểu theo cách của họ — và mỗi người hiểu một kiểu. Kết quả là phần mềm làm xong không khớp với thực tế nghiệp vụ, phải sửa đi sửa lại tốn kém.
Mô hình hóa và phân tích dữ liệu (Data Modeling and Analysis) chính là công cụ giúp bạn diễn đạt yêu cầu về dữ liệu và mối quan hệ giữa các dữ liệu một cách rõ ràng, không nhập nhằng. Đây là cầu nối quan trọng giữa ngôn ngữ nghiệp vụ (của khách hàng) và ngôn ngữ kỹ thuật (của lập trình viên, kỹ sư dữ liệu). Một BA giỏi mô hình hóa dữ liệu sẽ phát hiện được những lỗ hổng nghiệp vụ ngay từ giai đoạn phân tích — trước khi một dòng code nào được viết. Trong bài này, chúng ta sẽ tập trung vào hai công cụ kinh điển và đắc dụng nhất: Sơ đồ Quan hệ Thực thể (ERD) và Sơ đồ Luồng Dữ liệu (DFD).
Khái niệm cốt lõi
Mô hình hóa dữ liệu là gì?
Mô hình hóa dữ liệu là quá trình biểu diễn một cách trực quan các loại dữ liệu mà tổ chức cần lưu trữ, ý nghĩa của chúng, và cách chúng liên kết với nhau. Nó trả lời ba câu hỏi: Chúng ta cần lưu cái gì (dữ liệu gì)? Mỗi cái có đặc điểm gì (thuộc tính)? Và chúng liên hệ với nhau ra sao?
Lưu ý quan trọng: ở vai trò BA, bạn mô hình hóa dữ liệu để làm rõ nghiệp vụ, không phải để thiết kế cơ sở dữ liệu vật lý. Việc tối ưu bảng, chỉ mục (index), kiểu dữ liệu cụ thể là việc của Database Administrator. BA dừng lại ở mức mô hình khái niệm (conceptual) và mô hình logic (logical) — tập trung vào đúng nghiệp vụ.
Sơ đồ Quan hệ Thực thể (ERD)
ERD (Entity Relationship Diagram) là loại sơ đồ phổ biến nhất để mô hình hóa dữ liệu tĩnh. Nó gồm ba thành phần:
1. Thực thể (Entity) — là một "đối tượng" mà nghiệp vụ cần lưu thông tin về nó. Thực thể thường là danh từ: Khách hàng, Đơn hàng, Sản phẩm, Vé, Suất chiếu. Trên sơ đồ, thực thể thường được vẽ bằng hình chữ nhật.
2. Thuộc tính (Attribute) — là đặc điểm mô tả một thực thể. Thực thể "Khách hàng" có thuộc tính: mã khách hàng, họ tên, số điện thoại, email. Trong số đó có khóa định danh (identifier/primary key) — thuộc tính giúp phân biệt duy nhất một bản ghi, ví dụ mã khách hàng.
3. Mối quan hệ (Relationship) — diễn tả cách hai thực thể liên kết với nhau, kèm theo bản số (cardinality) cho biết mức độ liên kết. Có ba dạng cơ bản:
- Một–Một (1:1): Một nhân viên có một thẻ chấm công, và một thẻ thuộc về một nhân viên.
- Một–Nhiều (1:N): Một khách hàng có thể có nhiều đơn hàng, nhưng mỗi đơn hàng chỉ thuộc về một khách hàng. Đây là dạng phổ biến nhất.
- Nhiều–Nhiều (N:M): Một đơn hàng chứa nhiều sản phẩm, và một sản phẩm xuất hiện trong nhiều đơn hàng. Quan hệ N:M thường cần một thực thể trung gian (ví dụ "Chi tiết đơn hàng") để giải quyết.
Sơ đồ Luồng Dữ liệu (DFD)
Nếu ERD mô tả dữ liệu ở trạng thái "tĩnh" (cấu trúc), thì DFD (Data Flow Diagram) mô tả dữ liệu "động" — dữ liệu chảy qua hệ thống như thế nào, được xử lý ở đâu, lưu vào đâu. DFD gồm bốn thành phần:
- Tác nhân ngoài (External Entity): Nguồn hoặc đích của dữ liệu nằm ngoài hệ thống — ví dụ Khách hàng, Cổng thanh toán, Ngân hàng. Thường vẽ bằng hình vuông.
- Tiến trình (Process): Hoạt động biến đổi dữ liệu đầu vào thành đầu ra — ví dụ "Xác thực đơn hàng", "Tính phí vận chuyển". Thường vẽ bằng hình tròn hoặc bo góc.
- Kho dữ liệu (Data Store): Nơi lưu trữ dữ liệu — ví dụ "Kho khách hàng", "Kho đơn hàng". Thường vẽ bằng hai vạch song song.
- Luồng dữ liệu (Data Flow): Mũi tên thể hiện dữ liệu di chuyển từ đâu đến đâu.
ERD và DFD bổ trợ cho nhau
Một sai lầm thường gặp là nghĩ phải chọn một trong hai. Thực tế chúng trả lời hai câu hỏi khác nhau và bổ sung cho nhau: ERD nói "dữ liệu được tổ chức thế nào", DFD nói "dữ liệu di chuyển và được xử lý thế nào". Kho dữ liệu trong DFD thường tương ứng với các thực thể trong ERD — đây là điểm để bạn kiểm tra tính nhất quán giữa hai sơ đồ.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán quan hệ Nhiều–Nhiều
Một đội BA tại sàn thương mại điện tử (lấy bối cảnh giống Tiki) được giao mô tả dữ liệu cho tính năng giỏ hàng. Ban đầu họ vẽ ERD đơn giản: thực thể Đơn hàng và thực thể Sản phẩm, nối với nhau bằng quan hệ. Khi rà soát, một BA hỏi: "Một đơn hàng có nhiều sản phẩm, một sản phẩm bán trong nhiều đơn hàng — vậy số lượng từng sản phẩm trong đơn lưu ở đâu? Giá tại thời điểm mua lưu ở đâu?"
Câu hỏi này lộ ra rằng quan hệ N:M không thể lưu trực tiếp được. Họ bổ sung thực thể trung gian Chi tiết đơn hàng (Order Item) với các thuộc tính: mã đơn, mã sản phẩm, số lượng, đơn giá tại thời điểm mua. Chi tiết "đơn giá tại thời điểm mua" cực kỳ quan trọng: nếu sau này sản phẩm thay đổi giá, đơn hàng cũ vẫn phải giữ giá lúc khách mua. Nhờ phát hiện sớm qua ERD, đội tránh được một lỗi nghiệp vụ nghiêm trọng có thể gây tranh chấp với khách hàng.
Bài học: Mỗi khi gặp quan hệ Nhiều–Nhiều, hãy luôn hỏi "có thuộc tính nào thuộc về chính mối quan hệ này không?" — câu trả lời thường dẫn bạn đến một thực thể trung gian bị bỏ sót.
Tình huống 2 — Phòng khám tư nhân ở TP.HCM và quan hệ tùy chọn
Một chuỗi phòng khám tư khoảng 5 chi nhánh tại TP.HCM muốn số hóa hồ sơ bệnh nhân. BA vẽ ERD với các thực thể: Bệnh nhân, Lượt khám, Bác sĩ, Đơn thuốc. Khi trình bày với bác sĩ trưởng, một chi tiết bị bỏ qua được phát hiện: không phải lượt khám nào cũng kê đơn thuốc — có lượt chỉ tư vấn hoặc làm xét nghiệm.
Điều này thay đổi bản số và tính bắt buộc: quan hệ giữa Lượt khám và Đơn thuốc là 1:N tùy chọn (một lượt khám có thể có 0, 1 hoặc nhiều đơn thuốc). Nếu BA để mặc định "bắt buộc phải có đơn thuốc", hệ thống sẽ ép nhập đơn thuốc cho cả những lượt chỉ xét nghiệm — gây phiền toái và dữ liệu rác. Họ cũng phát hiện một bệnh nhân có thể khám ở nhiều chi nhánh, nên thực thể Bệnh nhân phải dùng chung toàn chuỗi, không gắn cứng vào một chi nhánh.
Bài học: Tính bắt buộc (optionality) quan trọng ngang với bản số. Đừng giả định mọi quan hệ đều bắt buộc — hãy hỏi rõ "trường hợp nào không có thì sao?"
Tình huống 3 — Ví điện tử và DFD để vạch ranh giới hệ thống
Một startup ví điện tử ở Đông Nam Á cần làm rõ luồng nạp tiền. BA vẽ DFD Mức 0: tác nhân ngoài gồm Người dùng, Ngân hàng liên kết, Cổng thanh toán; ở giữa là tiến trình duy nhất "Hệ thống Ví điện tử". Sơ đồ context này lập tức làm sáng tỏ một câu hỏi gây tranh cãi: phần xác thực số dư tài khoản ngân hàng thuộc về ai? Nhìn vào DFD, ai cũng thấy đó là trách nhiệm của Ngân hàng (tác nhân ngoài), ví chỉ gửi yêu cầu và nhận kết quả.
Sang DFD Mức 1, họ tách thành các tiến trình: "Nhận yêu cầu nạp", "Gọi cổng thanh toán", "Cập nhật số dư ví", "Ghi lịch sử giao dịch" — với kho dữ liệu "Kho số dư" và "Kho giao dịch". Khi đối chiếu, "Kho giao dịch" trong DFD trùng khớp với thực thể Giao dịch trong ERD, xác nhận hai mô hình nhất quán.
Bài học: DFD Mức 0 (context diagram) là công cụ tuyệt vời để thống nhất ranh giới hệ thống — cái gì hệ thống tự làm, cái gì giao cho bên ngoài. Đây là cuộc trò chuyện cần có sớm để tránh hiểu lầm về phạm vi.
Hướng dẫn từng bước
Dưới đây là quy trình mô hình hóa dữ liệu bạn có thể áp dụng cho hầu hết dự án:
Bước 1 — Thu thập từ vựng nghiệp vụ. Đọc tài liệu yêu cầu, gạch chân các danh từ (ứng viên thành thực thể) và động từ (ứng viên thành mối quan hệ hoặc tiến trình). Ví dụ trong câu "Khách hàng đặt đơn hàng gồm nhiều sản phẩm": Khách hàng, đơn hàng, sản phẩm là thực thể; "đặt", "gồm" là quan hệ.
Bước 2 — Xác định thực thể và khóa định danh. Với mỗi thực thể, hỏi: cái gì giúp phân biệt duy nhất một bản ghi? Nếu không có, có thể đó không phải thực thể độc lập mà chỉ là thuộc tính.
Bước 3 — Liệt kê thuộc tính. Mỗi thực thể cần thuộc tính gì? Cẩn thận đặt đúng thuộc tính vào đúng thực thể (số điện thoại thuộc Khách hàng hay thuộc Đơn hàng?).
Bước 4 — Xác định mối quan hệ, bản số và tính bắt buộc. Với từng cặp thực thể liên quan, hỏi hai chiều: "Một A liên kết với bao nhiêu B?" và "Một B liên kết với bao nhiêu A?". Luôn kiểm tra trường hợp "không có".
Bước 5 — Giải quyết quan hệ Nhiều–Nhiều. Mỗi quan hệ N:M cần một thực thể trung gian. Tìm các thuộc tính thuộc về chính mối quan hệ để đưa vào thực thể này.
Bước 6 — Vẽ DFD để kiểm tra luồng. Bắt đầu từ context diagram (Mức 0), rồi phân rã xuống Mức 1. Đảm bảo mỗi tiến trình có cả đầu vào và đầu ra (không có tiến trình "phép màu" tự sinh dữ liệu).
Bước 7 — Đối chiếu chéo. Kiểm tra kho dữ liệu trong DFD có khớp với thực thể trong ERD không. Mọi luồng dữ liệu phải có nguồn lưu trữ tương ứng.
Bước 8 — Xác nhận với stakeholder. Trình bày sơ đồ bằng ngôn ngữ nghiệp vụ, để chính người dùng nghiệp vụ "đọc" được và phản hồi. Đây là bước phát hiện sai sót rẻ nhất.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm thuộc tính thành thực thể (và ngược lại). Ví dụ coi "địa chỉ" là thuộc tính của Khách hàng, nhưng nếu một khách có nhiều địa chỉ giao hàng thì Địa chỉ nên là thực thể riêng. Mẹo: nếu một "thuộc tính" có thể có nhiều giá trị hoặc có thuộc tính con, hãy tách nó thành thực thể.
Lỗi 2 — Bỏ qua quan hệ Nhiều–Nhiều. Nối thẳng hai thực thể N:M mà không có thực thể trung gian sẽ khiến không lưu được dữ liệu của mối quan hệ. Mẹo: mỗi N:M = một thực thể trung gian, không có ngoại lệ.
Lỗi 3 — Quên tính bắt buộc. Mặc định mọi quan hệ là "bắt buộc" dẫn đến hệ thống ép nhập dữ liệu không cần thiết. Mẹo: với mỗi quan hệ, luôn hỏi "có thể bằng 0 không?".
Lỗi 4 — DFD có tiến trình "hố đen" hoặc "phép màu". Tiến trình chỉ có đầu vào mà không có đầu ra (hố đen), hoặc chỉ có đầu ra mà không có đầu vào (phép màu) là dấu hiệu mô hình sai. Mẹo: mỗi tiến trình phải nhận đủ dữ liệu để tạo ra đầu ra của nó.
Lỗi 5 — Sa đà vào chi tiết kỹ thuật. BA vẽ ERD với kiểu dữ liệu, độ dài trường, chỉ mục... khiến stakeholder nghiệp vụ không hiểu. Mẹo: giữ ở mức khái niệm/logic, dùng từ ngữ nghiệp vụ.
Mẹo chung: Dùng công cụ trực quan như draw.io (miễn phí), Lucidchart, hoặc dbdiagram.io để vẽ nhanh. Quan trọng hơn công cụ là việc bạn xác nhận sơ đồ với người dùng nghiệp vụ — sơ đồ đẹp mà sai nghiệp vụ thì vô nghĩa.
Bài tập thực hành
Hãy thực hành với một tình huống: Hệ thống quản lý thư viện của một trường đại học.
Yêu cầu nghiệp vụ tóm tắt: Sinh viên mượn sách. Mỗi cuốn sách có thể có nhiều bản sao (đầu sách giống nhau nhưng mã vạch khác nhau). Một sinh viên có thể mượn nhiều bản sao cùng lúc. Mỗi lần mượn có ngày mượn và ngày hẹn trả. Một số sách chỉ được đọc tại chỗ, không cho mượn về.
- Liệt kê các thực thể bạn nhận diện được và khóa định danh của mỗi thực thể. (Gợi ý: chú ý sự khác biệt giữa "đầu sách" và "bản sao sách".)
- Xác định mối quan hệ giữa Sinh viên và Bản sao sách: đó là quan hệ gì? Có cần thực thể trung gian không? Nếu có, thực thể đó tên gì và có thuộc tính nào?
- Thuộc tính "chỉ đọc tại chỗ" nên gắn vào thực thể nào — Đầu sách hay Bản sao? Vì sao?
- Vẽ DFD Mức 0 (context diagram) cho nghiệp vụ "mượn sách", xác định các tác nhân ngoài.
- Đối chiếu: kho dữ liệu nào trong DFD của bạn tương ứng với thực thể nào trong ERD?
Tóm tắt
Mô hình hóa dữ liệu là kỹ năng cốt lõi giúp BA chuyển yêu cầu mơ hồ thành mô tả dữ liệu rõ ràng, không nhập nhằng. Hai công cụ chính:
- ERD mô tả dữ liệu ở trạng thái tĩnh: thực thể, thuộc tính, mối quan hệ với bản số (1:1, 1:N, N:M) và tính bắt buộc. Quan hệ Nhiều–Nhiều luôn cần thực thể trung gian.
- DFD mô tả dữ liệu ở trạng thái động: dữ liệu chảy qua các tiến trình, kho dữ liệu, và tác nhân ngoài. Vẽ phân cấp từ context diagram (Mức 0) xuống các mức chi tiết hơn.