Mở đầu — vì sao bài này quan trọng
Trong suốt hành trình ôn thi ECBA, bạn đã làm quen với nhiều kỹ thuật mô hình hóa: từ process modelling (BPMN), use cases, cho đến user stories. Nhưng có một câu hỏi mà gần như mọi dự án phần mềm đều phải trả lời sớm hay muộn: "Hệ thống này sẽ lưu trữ những dữ liệu gì, và các dữ liệu đó liên hệ với nhau ra sao?" Đây chính là lúc Data Modelling lên tiếng, và công cụ phổ biến nhất để làm việc này là ERD — Entity-Relationship Diagram (sơ đồ thực thể - quan hệ).
Với một Business Analyst, ERD không phải là chuyện "của dân kỹ thuật". Theo BABOK Guide v3, Data Modelling là một trong 50 kỹ thuật chính thức mà BA cần nắm, nằm trong nhóm hỗ trợ cho Requirements Analysis and Design Definition. Lý do rất thực tế: khi bạn mô tả nghiệp vụ, bạn đang ngầm định nghĩa các "đối tượng" mà doanh nghiệp quan tâm — khách hàng, đơn hàng, sản phẩm, hóa đơn. ERD giúp bạn biến những danh từ mơ hồ đó thành một bức tranh rõ ràng, không trùng lặp, không mâu thuẫn, để cả nghiệp vụ lẫn đội phát triển cùng hiểu giống nhau.
Trong đề thi ECBA, bạn sẽ không phải vẽ một ERD phức tạp, nhưng bạn cần hiểu bản chất ba phần tử cốt lõi, đọc được một sơ đồ đơn giản, và phân biệt được khái niệm cardinality (lượng số quan hệ). Bài học này sẽ trang bị đúng những điều đó — đủ để bạn tự tin trong phòng thi và đủ để bạn nói chuyện ngang hàng với một data architect ngoài đời.
Khái niệm cốt lõi
ERD là gì?
Entity-Relationship Diagram là một dạng sơ đồ dùng để mô hình hóa dữ liệu của một nghiệp vụ: nó thể hiện những thực thể (đối tượng mà doanh nghiệp cần lưu thông tin), các thuộc tính của chúng, và các mối quan hệ giữa chúng. Khái niệm này do Peter Chen đề xuất năm 1976 và đến nay vẫn là nền tảng của hầu hết thiết kế cơ sở dữ liệu quan hệ.
Hãy nhớ một câu mấu chốt: ERD trả lời câu hỏi "Dữ liệu nào tồn tại và liên kết ra sao?" — chứ không phải "Quy trình diễn ra thế nào?" (đó là việc của BPMN). Đây là điểm phân biệt quan trọng mà đề thi hay kiểm tra.
Ba phần tử chính
1. Entity (Thực thể) — Là một "thứ" mà doanh nghiệp cần lưu trữ dữ liệu về nó. Thực thể thường là một danh từ trong mô tả nghiệp vụ: Khách hàng (Customer), Đơn hàng (Order), Sản phẩm (Product), Nhân viên (Employee). Một thực thể đại diện cho một tập hợp các đối tượng cùng loại — ví dụ "Khách hàng" là loại, còn "Chị Lan, mã KH001" là một instance (thể hiện) cụ thể. Trong sơ đồ, entity thường được vẽ bằng hình chữ nhật.
2. Attribute (Thuộc tính) — Là đặc điểm mô tả một thực thể. Thực thể "Khách hàng" có thể có các thuộc tính: Mã khách hàng, Họ tên, Số điện thoại, Email, Địa chỉ. Mỗi thuộc tính giữ một mảnh thông tin. Có một loại thuộc tính đặc biệt gọi là Primary Key (khóa chính) — một thuộc tính (hoặc tổ hợp) định danh duy nhất cho mỗi instance. Mã khách hàng KH001 là khóa chính: không có hai khách hàng nào trùng mã.
3. Relationship (Mối quan hệ) — Là sự liên kết có ý nghĩa nghiệp vụ giữa hai thực thể. Ví dụ: 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. Relationship thường được diễn đạt bằng động từ. Trong sơ đồ, nó là đường nối giữa hai entity.
Cardinality — lượng số của quan hệ
Đây là phần "tinh túy" nhất của ERD và hay xuất hiện trong câu hỏi thi. Cardinality mô tả bao nhiêu instance của thực thể này liên kết với bao nhiêu instance của thực thể kia. Có ba dạng cơ bản:
- One-to-One (1:1): Mỗi instance bên A liên kết tối đa một instance bên B. Ví dụ: mỗi Nhân viên có đúng một Hồ sơ lương.
- One-to-Many (1:N): Một instance bên A liên kết nhiều instance bên B. Ví dụ: một Khách hàng đặt 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.
- Many-to-Many (M:N): Nhiều instance bên A liên kết nhiều instance bên B. Ví dụ: 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.
Mức độ trừu tượng của data model
Bạn nên biết ba cấp độ, vì BA thường làm việc ở cấp đầu tiên:
- Conceptual model: Chỉ thực thể và quan hệ, ngôn ngữ nghiệp vụ thuần túy — đây là sân chơi của BA.
- Logical model: Thêm thuộc tính, khóa chính, khóa ngoại, chuẩn hóa dữ liệu — thường là sự phối hợp giữa BA và data architect.
- Physical model: Bảng, kiểu dữ liệu, index thực tế trong cơ sở dữ liệu — phần này thuộc về kỹ thuật.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử "ChợViệt"
Giả sử bạn là BA cho startup "ChợViệt", một sàn thương mại điện tử nhỏ tại TP.HCM với khoảng 5.000 người bán và 80.000 khách hàng. Đội phát triển cần một ERD cho phân hệ đặt hàng. Bạn ngồi với chủ sản phẩm và bóc tách các danh từ: Khách hàng, Đơn hàng, Sản phẩm, Người bán.
Bạn vẽ ra:
- Một Khách hàng đặt nhiều Đơn hàng (1:N) — vì một người mua hàng nhiều lần trong năm.
- Một Đơn hàng chứa nhiều Sản phẩm, và một Sản phẩm nằm trong nhiều Đơn hàng (M:N).
- Một Người bán đăng nhiều Sản phẩm (1:N).
Bài học rút ra: Khi gặp quan hệ Many-to-Many, gần như luôn cần một associative entity (thực thể liên kết) ở giữa. Và chính thực thể trung gian này thường là nơi chứa dữ liệu nghiệp vụ quan trọng — như giá tại thời điểm mua, thứ mà nếu bỏ sót sẽ gây tranh cãi khi giá sản phẩm thay đổi sau đó.
Ví dụ 2: Phòng khám đa khoa "An Tâm"
Một chuỗi phòng khám "An Tâm" ở Hà Nội muốn số hóa hồ sơ bệnh nhân. Là BA, bạn xác định các thực thể: Bệnh nhân, Bác sĩ, Lịch hẹn (Appointment), Hồ sơ bệnh án.
Khi mô hình hóa, bạn phát hiện một điểm tinh tế về cardinality:
- Một Bệnh nhân có nhiều Lịch hẹn, một Bác sĩ cũng có nhiều Lịch hẹn — nên Lịch hẹn đứng giữa, liên kết một Bệnh nhân với một Bác sĩ tại một thời điểm.
- Quan hệ Bệnh nhân — Hồ sơ bệnh án là 1:1: mỗi bệnh nhân có đúng một hồ sơ tổng hợp.
Bài học rút ra: ERD không phải vẽ một lần là xong. Cardinality phải được xác nhận với stakeholder bằng câu hỏi nghiệp vụ cụ thể: "Một X có thể có nhiều Y không? Một Y có bắt buộc thuộc về một X không?" Chính những câu hỏi này giúp bạn lộ ra các luật nghiệp vụ ẩn (business rules) mà không ai nghĩ tới khi chỉ mô tả bằng lời.
Ví dụ 3: Trung tâm tiếng Anh "EduSmart"
Trung tâm "EduSmart" ở Đà Nẵng quản lý khóa học bằng Excel và bắt đầu rối khi có 40 lớp, 600 học viên. Bạn được mời làm BA. Bạn dựng ERD nhanh với: Học viên, Lớp học, Giảng viên, Khóa học.
Lúc đầu đội kỹ thuật định gộp "tên giảng viên" thành một thuộc tính của Lớp học cho gọn. Nhưng bạn chỉ ra: giảng viên là một thực thể độc lập, có số điện thoại, bằng cấp, lịch dạy riêng — và một giảng viên dạy nhiều lớp. Nếu nhét tên giảng viên vào Lớp học, khi giảng viên đổi số điện thoại bạn phải sửa ở hàng chục dòng (dữ liệu trùng lặp, dễ sai lệch).
Bài học rút ra: Một dấu hiệu để tách thực thể riêng là khi một "thuộc tính" bắt đầu có thuộc tính của riêng nó hoặc bị lặp lại ở nhiều nơi. Đây là tinh thần của chuẩn hóa dữ liệu (normalization) — tránh dư thừa để dữ liệu nhất quán.
Hướng dẫn từng bước
Khi xây dựng một ERD ở mức conceptual, bạn có thể đi theo trình tự sau:
- Thu thập mô tả nghiệp vụ từ tài liệu yêu cầu, kết quả elicitation, user stories. Đọc kỹ để có nguyên liệu.
- Gạch chân các danh từ — chúng là ứng viên cho thực thể (entity). Lọc bỏ những danh từ chỉ là thuộc tính (ví dụ "số điện thoại" thường là attribute, không phải entity).
- Xác định thực thể chính và đặt tên rõ ràng, dạng số ít (Customer chứ không phải Customers).
- Liệt kê thuộc tính cho từng thực thể, và chỉ ra khóa chính — thứ định danh duy nhất mỗi instance.
- Tìm động từ nối giữa các thực thể để xác định relationship: "đặt", "chứa", "thuộc về", "đăng ký".
- Xác định cardinality cho mỗi quan hệ bằng cách hỏi hai chiều: "Một A có nhiều B không?" và "Một B có nhiều A không?". Kết hợp câu trả lời để ra 1:1, 1:N hay M:N.
- Xử lý quan hệ M:N bằng cách thêm associative entity ở giữa nếu cần.
- Rà soát tính bắt buộc/tùy chọn (mandatory/optional) của từng đầu quan hệ.
- Review với stakeholder — đọc to mô hình bằng ngôn ngữ tự nhiên: "Một khách hàng có thể đặt nhiều đơn hàng; mỗi đơn hàng phải thuộc về đúng một khách hàng." Nếu họ gật đầu, mô hình đúng.
Lỗi thường gặp & mẹo
- Nhầm ERD với sơ đồ quy trình. ERD mô tả dữ liệu tĩnh, không phải luồng xử lý. Nếu bạn thấy mình vẽ mũi tên "bước 1 → bước 2", bạn đang vẽ nhầm sang BPMN.
- Biến thuộc tính thành thực thể (và ngược lại). "Màu sắc" của sản phẩm thường là thuộc tính, nhưng nếu nghiệp vụ cần quản lý danh mục màu với mã riêng thì nó lại thành thực thể. Quyết định dựa trên nhu cầu nghiệp vụ, không có công thức cứng.
- Bỏ quên cardinality hoặc đoán mò. Đây là lỗi nguy hiểm nhất vì nó che giấu business rule. Luôn xác nhận với stakeholder, đừng tự suy diễn.
- Để quan hệ M:N "trần". Trong cơ sở dữ liệu quan hệ, M:N cần associative entity. Quên điều này khiến đội kỹ thuật phải làm lại thiết kế.
- Đặt tên mơ hồ. "Data", "Info", "Object" không phải tên thực thể tốt. Tên phải phản ánh ngôn ngữ nghiệp vụ — đồng bộ với Glossary mà bạn xây ở bài khác.
- Mẹo thi ECBA: Hãy nhớ ERD thuộc kỹ thuật Data Modelling trong BABOK. Nhớ ba phần tử (Entity, Attribute, Relationship), nhớ ba dạng cardinality, và nhớ rằng BA chủ yếu làm việc ở mức conceptual. Câu hỏi thường kiểm tra việc bạn phân biệt các khái niệm, không phải vẽ sơ đồ.
Bài tập thực hành
Hãy lấy bối cảnh một thư viện 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ó nhiều bản sao. Một sinh viên có thể mượn nhiều cuốn cùng lúc, và mỗi lượt mượn có ngày mượn, ngày hẹn trả."
- Liệt kê các thực thể bạn nhận ra (gợi ý: ít nhất ba).
- Với mỗi thực thể, viết ra 3 thuộc tính và chỉ rõ khóa chính.
- Xác định cardinality giữa Sinh viên và lượt mượn; giữa lượt mượn và Sách.
- Quan hệ giữa Sinh viên và Sách có phải Many-to-Many không? Nếu có, hãy đề xuất một associative entity và cho biết nó nên chứa thuộc tính gì.
- Viết một câu tiếng Việt tự nhiên đọc to để review mô hình của bạn với thủ thư.
Tóm tắt
ERD — Entity-Relationship Diagram — là công cụ cốt lõi để mô hình hóa dữ liệu của một nghiệp vụ, trả lời câu hỏi "có dữ liệu gì và chúng liên kết ra sao". Ba phần tử bạn phải thuộc nằm lòng là Entity (thực thể — danh từ, hình chữ nhật), Attribute (thuộc tính, trong đó có Primary Key định danh duy nhất), và Relationship (mối quan hệ — động từ nối hai thực thể). Linh hồn của ERD nằm ở cardinality với ba dạng One-to-One, One-to-Many và Many-to-Many; mỗi quan hệ M:N gần như luôn cần một associative entity để hiện thực hóa.
Với vai trò BA và mục tiêu ECBA, bạn không cần trở thành chuyên gia thiết kế cơ sở dữ liệu, nhưng bạn cần đọc hiểu một ERD, đặt đúng câu hỏi để xác nhận cardinality, và dùng nó để lộ ra các luật nghiệp vụ ẩn. Hãy nhớ: ERD là cầu nối giúp nghiệp vụ và kỹ thuật nói cùng một ngôn ngữ về dữ liệu — và một mô hình tốt luôn được sinh ra từ việc đọc to nó bằng ngôn ngữ con người để stakeholder gật đầu.