Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn được giao nhiệm vụ thiết kế hệ thống cho một chuỗi cửa hàng cà phê đang mở rộng nhanh ở Việt Nam. Sếp nói: "Mình cần một hệ thống quản lý khách hàng, đơn hàng, sản phẩm và nhân viên." Câu hỏi đầu tiên — và cũng là câu hỏi quan trọng nhất — không phải là "Dùng MySQL hay PostgreSQL?", cũng không phải "Bảng này có bao nhiêu cột?". Câu hỏi nền tảng là: Trong nghiệp vụ này, có những "đối tượng" nào mà ta cần lưu thông tin về?
Đó chính là việc xác định entity (thực thể). Và đây là kỹ năng nền móng của toàn bộ data modeling. Nếu bạn xác định sai entity ngay từ đầu — gộp hai thứ lẽ ra phải tách, hoặc tách một thứ lẽ ra phải gộp — thì mọi tầng phía sau (attributes, primary key, relationships, normalization) đều sẽ lệch theo. Giống như xây nhà mà đặt sai móng: càng xây lên cao càng nghiêng.
Trong các bài tiếp theo của khóa học, chúng ta sẽ đi sâu vào attributes (Bài 5), primary key (Bài 6) và relationships (Bài 7). Nhưng bạn không thể nói về thuộc tính của một thứ, hay mối quan hệ giữa hai thứ, nếu chưa định danh rõ ràng "thứ" đó là gì. Vì vậy, bài này tập trung trọn vẹn vào một câu hỏi: Entity là gì, và làm sao nhận ra nó trong một bài toán nghiệp vụ thực tế?
Khái niệm cốt lõi
Entity là gì?
Entity là một đối tượng quan trọng trong nghiệp vụ (business) mà tổ chức cần lưu giữ thông tin về nó. Đối tượng này có thể là một thứ hữu hình (con người, sản phẩm, cửa hàng) hoặc vô hình (đơn hàng, hợp đồng, cuộc hẹn). Điểm chung là: nó đủ quan trọng để ta cần ghi nhận và truy xuất dữ liệu liên quan đến nó nhiều lần.
Một cách hình dung thực tế: khi mô hình hóa dữ liệu, mỗi entity thường tương ứng với một bảng (table) trong cơ sở dữ liệu. Entity Khách hàng trở thành bảng customers, entity Đơn hàng trở thành bảng orders. Mỗi dòng (row) trong bảng là một instance — một cá thể cụ thể của entity đó. Bảng customers là entity, còn dòng "Nguyễn Văn An, sđt 0901234567" là một instance của entity ấy.
Hãy phân biệt rõ ba khái niệm dễ lẫn:
- Entity type (loại thực thể): khái niệm trừu tượng, ví dụ "Khách hàng" nói chung.
- Entity instance (cá thể): một khách hàng cụ thể, ví dụ chị Lan ở Quận 7.
- Attribute (thuộc tính): một mẩu thông tin mô tả entity, ví dụ tên, số điện thoại, ngày sinh.
Tiêu chí xác định một entity
Làm sao biết một danh từ trong yêu cầu nghiệp vụ có xứng đáng trở thành entity hay không? Tôi thường dùng bốn tiêu chí kiểm tra sau. Một entity thực thụ nên thỏa mãn phần lớn trong số này:
- Có thể định danh duy nhất (identity). Mỗi cá thể của entity phải phân biệt được với nhau. Mỗi khách hàng có một mã khách hàng; mỗi đơn hàng có một mã đơn. Nếu bạn không thể chỉ ra cách phân biệt "instance này" với "instance kia", thì rất có thể nó chưa phải entity — nó có thể chỉ là một thuộc tính.
- Có nhiều thuộc tính mô tả nó. Một entity thường mang theo nhiều mẩu thông tin. Khách hàng có tên, ngày sinh, địa chỉ, hạng thành viên... Nếu một thứ chỉ là một giá trị đơn lẻ (ví dụ "màu sắc" của sản phẩm chỉ là chữ "đỏ"), nó thường là attribute chứ không phải entity.
- Có nhiều instance (xảy ra nhiều lần). Tổ chức cần quản lý nhiều khách hàng, nhiều đơn hàng, nhiều sản phẩm. Nếu một thứ chỉ có đúng một giá trị duy nhất cho cả hệ thống (ví dụ "tên công ty của chúng ta"), nó hiếm khi đáng làm entity.
- Quan trọng với nghiệp vụ và bền vững theo thời gian. Ta cần lưu thông tin về nó vì nghiệp vụ thực sự cần, và nhu cầu đó tồn tại lâu dài chứ không phải tạm thời.
Các loại entity
Trong thực hành mô hình hóa, ta phân loại entity theo vai trò để dễ tổ chức tư duy:
Entity độc lập (independent / strong entity): tồn tại được mà không phụ thuộc vào entity khác. Nó tự định danh được bằng chính dữ liệu của nó. Khách hàng, Sản phẩm, Nhân viên đều là entity độc lập — một khách hàng vẫn là khách hàng dù chưa từng đặt đơn nào.
Entity phụ thuộc (dependent / weak entity): sự tồn tại của nó gắn chặt với một entity khác và thường không tự định danh được nếu đứng một mình. Ví dụ kinh điển là Chi tiết đơn hàng (order line item) — một dòng "2 ly cà phê sữa đá" không có ý nghĩa nếu không gắn với một đơn hàng cụ thể. Hay Người phụ thuộc (dependent) của nhân viên trong hệ thống bảo hiểm: con của nhân viên chỉ tồn tại trong hệ thống thông qua nhân viên đó.
Entity liên kết (associative entity / junction entity): sinh ra để mô hình hóa mối quan hệ nhiều-nhiều (many-to-many) và thường mang theo thông tin riêng về chính mối quan hệ đó. Ví dụ: một sinh viên học nhiều môn, một môn có nhiều sinh viên; entity Đăng ký học (enrollment) đứng giữa, lưu thêm thông tin như ngày đăng ký, điểm số. (Cơ chế chi tiết của quan hệ nhiều-nhiều sẽ học kỹ ở Bài 7; ở đây bạn chỉ cần nhận ra rằng loại entity này tồn tại.)
Đừng quá lo lắng về việc phân loại "đúng tên" ngay lập tức. Mục đích của việc phân loại không phải để dán nhãn, mà để giúp bạn đặt câu hỏi đúng: "Thứ này có tự đứng vững không, hay nó dựa vào thứ khác?"
Quy tắc đặt tên entity
Một entity tốt cần một cái tên tốt. Vài quy ước thực hành:
- Đặt tên bằng danh từ số ít, mang nghĩa nghiệp vụ rõ ràng:
KhachHang,DonHang,SanPham— không phải động từ hay câu mô tả. - Nhất quán: nếu chọn dùng tiếng Anh thì dùng tiếng Anh xuyên suốt (
Customer,Order,Product), tránh nửa Anh nửa Việt. - Tránh tên mơ hồ như
Data,Info,Thing. Một cái tên không nói lên đối tượng nghiệp vụ là dấu hiệu bạn chưa hiểu rõ entity đó.
Tình huống thực tế
Tình huống 1 — Chuỗi cà phê The Coffee House mở rộng
Giả định một đội kỹ thuật xây hệ thống quản lý cho chuỗi cà phê 150 chi nhánh. Yêu cầu nghiệp vụ ban đầu viết là: "Khách hàng đặt đồ uống tại cửa hàng. Mỗi đơn hàng gồm nhiều món. Nhân viên pha chế xử lý đơn. Khách tích điểm theo từng đơn."
Cách làm thực hành là gạch chân các danh từ: khách hàng, đồ uống (sản phẩm), cửa hàng, đơn hàng, món (chi tiết đơn), nhân viên, điểm tích lũy.
Áp bốn tiêu chí, ta xác định các entity:
KhachHang— entity độc lập, có mã, có nhiều thuộc tính (tên, sđt, hạng), có nhiều instance. Đạt.SanPham— đồ uống/món, entity độc lập. Đạt.CuaHang— chi nhánh, 150 instance, có địa chỉ, có quản lý. Đạt.DonHang— entity độc lập (đơn tồn tại với mã đơn, ngày giờ, tổng tiền). Đạt.ChiTietDonHang— entity phụ thuộc, một dòng "2 Trà đào x 45.000đ" chỉ có nghĩa khi gắn với một đơn. Đạt, nhưng là weak entity.NhanVien— entity độc lập. Đạt.
DiemTichLuy. Nhưng nếu điểm chỉ là một con số gắn với mỗi đơn hàng, nó là attribute của DonHang (cột diem_cong), không phải entity. Bài học rút ra: không phải mọi danh từ đều là entity — phải kiểm tra xem nó có identity và nhiều thuộc tính riêng hay không.Tình huống 2 — Sàn thương mại điện tử Tiki và bài toán "Người dùng"
Một bạn analyst tại sàn TMĐT thiết kế hệ thống và gặp câu hỏi gai góc: cùng một người vừa có thể là người mua (buyer) vừa có thể là người bán (seller). Bạn ấy tạo hai entity riêng NguoiMua và NguoiBan. Vài tháng sau, vấn đề lộ ra: anh Tuấn vừa bán đồ secondhand vừa mua hàng — dữ liệu của anh bị nhân đôi ở hai bảng, số điện thoại đổi một nơi mà nơi kia vẫn cũ.
Bài toán thật sự là: "người" là một entity duy nhất (NguoiDung), còn "mua" và "bán" là vai trò mà cùng một entity đảm nhận trong các quan hệ khác nhau. (Trường hợp một entity có các phân loại con kiểu này được xử lý bằng kỹ thuật supertype/subtype, sẽ học ở Bài 20.)
Bài học rút ra: đừng nhầm vai trò (role) với entity. Hãy hỏi: "Đây là một loại đối tượng mới, hay chỉ là cách một đối tượng cũ tham gia vào nghiệp vụ?" Nếu chỉ là cách tham gia, đó là vai trò, không phải entity mới.
Tình huống 3 — Ngân hàng số và sự khác nhau giữa "Tài khoản" và "Giao dịch"
Tại một ngân hàng số ở Việt Nam, đội thiết kế bàn về hệ thống lõi. Họ nhận ra hai danh từ then chốt: TaiKhoan (account) và GiaoDich (transaction). Một câu hỏi nảy ra: tại sao không gộp số dư và lịch sử giao dịch vào chung một bảng tài khoản cho gọn?
Phân tích theo tiêu chí entity:
TaiKhoancó identity (số tài khoản), ít instance hơn (mỗi khách vài tài khoản), thông tin tương đối ổn định: chủ tài khoản, loại, số dư hiện tại.GiaoDichcũng có identity (mã giao dịch), nhưng có rất nhiều instance — một tài khoản có thể phát sinh hàng nghìn giao dịch, mỗi giao dịch có thuộc tính riêng (thời điểm, số tiền, loại, tài khoản đối ứng).
GiaoDich thỏa mãn cả bốn tiêu chí và đặc biệt là "nhiều instance lặp lại", nó bắt buộc phải là entity độc lập, không thể nhồi vào bảng tài khoản. Gộp lại sẽ tạo ra cấu trúc lặp lại vô hạn và không thể truy vấn hiệu quả.Bài học rút ra: khi một danh từ "xảy ra lặp đi lặp lại theo thời gian" và mỗi lần đều mang dữ liệu riêng, đó gần như chắc chắn là một entity riêng — đừng cố nhét nó làm thuộc tính của entity khác.
Hướng dẫn từng bước
Đây là quy trình thực hành để xác định entity từ một bản mô tả nghiệp vụ:
- Thu thập mô tả nghiệp vụ bằng ngôn ngữ tự nhiên. Lấy tài liệu yêu cầu, biên bản phỏng vấn, hoặc câu chuyện người dùng (user story). Viết ra thành các câu hoàn chỉnh.
- Gạch chân tất cả danh từ và cụm danh từ. Đây là "kỹ thuật danh từ" (noun analysis) kinh điển. Mỗi danh từ là một ứng viên entity tiềm năng. Đừng lọc vội ở bước này — cứ liệt kê hết.
- Lập danh sách ứng viên và loại trùng lặp. Gộp các từ đồng nghĩa ("người mua", "khách hàng", "buyer" có thể chỉ cùng một entity).
- Áp bốn tiêu chí cho từng ứng viên. Với mỗi danh từ, hỏi: Nó có identity không? Có nhiều thuộc tính không? Có nhiều instance không? Có quan trọng với nghiệp vụ không? Đánh dấu Đạt / Không.
- Phân loại những thứ bị loại. Một ứng viên bị loại thường rơi vào một trong ba nhóm: (a) là attribute của entity khác, (b) là vai trò của một entity đã có, hoặc (c) là một giá trị đơn lẻ. Ghi rõ nó thuộc nhóm nào để không bỏ sót thông tin.
- Phân loại entity còn lại thành độc lập / phụ thuộc / liên kết. Việc này giúp bạn lường trước cấu trúc khi sang phần relationships.
- Đặt tên chuẩn và viết một câu định nghĩa cho mỗi entity. Ví dụ: "
DonHang— đại diện cho một lần khách hàng đặt mua sản phẩm tại một thời điểm." Một câu định nghĩa rõ ràng là phép thử cuối: nếu bạn không viết nổi một câu, có thể bạn chưa hiểu rõ entity đó.
- Rà soát lại cùng người am hiểu nghiệp vụ (SME). Đọc danh sách entity cho người vận hành thực tế nghe. Họ sẽ nhanh chóng chỉ ra thứ bạn thiếu hoặc thừa.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến mọi danh từ thành entity. Kết quả là một mô hình phình to với hàng chục bảng nhỏ vô nghĩa. Mẹo: danh từ chỉ là ứng viên; luôn lọc qua bốn tiêu chí.
Lỗi 2 — Nhầm attribute thành entity. Tạo bảng MauSac, KichThuoc riêng trong khi chúng chỉ là thuộc tính. Mẹo: nếu một thứ chỉ có đúng một giá trị và không có thuộc tính con nào của riêng nó, nó là attribute. (Ngoại lệ: khi danh sách màu cần quản lý tập trung và có thuộc tính riêng, lúc đó nó mới thành entity tham chiếu.)
Lỗi 3 — Nhầm vai trò thành entity. Như tình huống Tiki: tách NguoiMua/NguoiBan. Mẹo: hỏi "đây là loại đối tượng mới, hay cách một đối tượng cũ tham gia nghiệp vụ?"
Lỗi 4 — Gộp hai entity khác bản chất vào một. Ví dụ nhồi cả thông tin công ty và thông tin liên hệ vào chung một bảng KhachHang, trong khi một công ty có nhiều người liên hệ. Mẹo: nếu bạn thấy dữ liệu lặp lại (một công ty xuất hiện nhiều dòng chỉ vì có nhiều người liên hệ), đó là dấu hiệu cần tách thành hai entity.
Lỗi 5 — Đặt tên mơ hồ. Data, Master, Info. Mẹo: tên entity phải là từ mà người làm nghiệp vụ dùng hằng ngày.
Mẹo tổng quát: khi phân vân một thứ là entity hay attribute, hãy hỏi: "Tôi có cần lưu nhiều thông tin về nó, hay nó chỉ là một thông tin của thứ khác?" Lưu thông tin về nó → entity. Là thông tin của thứ khác → attribute.
Bài tập thực hành
Đề bài: Một phòng khám tư ở TP.HCM muốn số hóa việc quản lý. Mô tả nghiệp vụ như sau:
> "Bệnh nhân đặt lịch khám với bác sĩ. Mỗi lịch hẹn diễn ra tại một phòng khám vào một khung giờ. Sau khi khám, bác sĩ kê đơn thuốc gồm nhiều loại thuốc. Bệnh nhân thanh toán hóa đơn cho mỗi lần khám. Mỗi bác sĩ thuộc một chuyên khoa."
Yêu cầu:
- Gạch chân tất cả danh từ và lập danh sách ứng viên entity.
- Áp bốn tiêu chí, xác định danh sách entity cuối cùng.
- Với mỗi ứng viên bị loại, ghi rõ nó là attribute, vai trò, hay giá trị đơn lẻ — và thuộc về entity nào.
- Phân loại các entity còn lại thành độc lập / phụ thuộc / liên kết.
- Viết một câu định nghĩa cho mỗi entity.
BenhNhan, BacSi, PhongKham, LichHen, DonThuoc, Thuoc, HoaDon là các ứng viên mạnh. "Chuyên khoa" — bạn hãy cân nhắc: nó là attribute của BacSi hay là một entity tham chiếu riêng? "Chi tiết đơn thuốc" (loại thuốc nào, liều bao nhiêu trong một đơn) gần như chắc chắn là một weak entity. "Khung giờ" — nhiều khả năng là attribute của LichHen. Hãy tự lý giải từng quyết định bằng bốn tiêu chí.Tóm tắt
- Entity là một đối tượng quan trọng của nghiệp vụ mà ta cần lưu thông tin về; trong cơ sở dữ liệu, mỗi entity thường thành một bảng, mỗi instance là một dòng.
- Phân biệt rõ entity type (khái niệm), entity instance (cá thể) và attribute (thuộc tính mô tả).
- Dùng bốn tiêu chí để kiểm tra một danh từ có xứng làm entity: có identity, có nhiều thuộc tính, có nhiều instance, quan trọng và bền vững với nghiệp vụ.
- Nhận biết ba loại entity: độc lập, phụ thuộc (weak), và liên kết (associative).
- Quy trình thực hành: gạch chân danh từ → lọc ứng viên → áp tiêu chí → phân loại thứ bị loại (attribute / vai trò / giá trị) → đặt tên và định nghĩa → rà soát với SME.
- Tránh năm lỗi kinh điển: mọi danh từ thành entity, nhầm attribute, nhầm vai trò, gộp sai bản chất, đặt tên mơ hồ.