MÔ HÌNH THỰC THỂ LIÊN KẾT

Cách hỏi người dùng, vẽ sơ đồ ER và đọc đúng bản số để bắt lỗi thiết kế trước khi có bảng

---

Khi một chuỗi siêu thị mini giả định tên Sen Vàng Mart quyết định bỏ 18 tệp Excel để chuyển sang một hệ quản lý bán hàng, nhóm phát triển phỏng vấn chủ chuỗi trong một buổi chiều. Một trong những câu ghi lại được là: "Mỗi nhân viên làm việc tại một cửa hàng." Câu này nghe hiển nhiên nên không ai hỏi thêm. Hệ thống được thiết kế để mỗi nhân viên gắn với đúng một cửa hàng, rồi được xây dựng, kiểm thử và đưa vào sử dụng.

Ba tháng sau, quản lý vùng Hà Nội phàn nàn rằng không xếp được lịch cho nhân viên thời vụ. Những người này làm sáng thứ Hai ở Cầu Giấy, chiều thứ Tư ở Đống Đa, cuối tuần ở Hoàn Kiếm, một thực tế mà chủ chuỗi biết rõ nhưng không nghĩ tới khi nói câu kia. Sửa lỗi lúc này không phải sửa một dòng mô tả: phải đổi cấu trúc bảng, sửa màn hình chấm công, sửa báo cáo lương và chuyển đổi dữ liệu đã nhập. Toàn bộ sự cố bắt nguồn từ một câu hỏi không được đặt ra: "Có khi nào một nhân viên làm ở nhiều hơn một cửa hàng không?"

Mô hình thực thể liên kết (entity–relationship model, mô hình ER) là công cụ để đặt những câu hỏi như vậy một cách có hệ thống và ghi lại câu trả lời sao cho người dùng nhìn vào là thấy ngay chỗ sai. Bài viết gồm sáu mục. Mục 1 bàn cách thu thập yêu cầu dữ liệu. Mục 2 giới thiệu thực thể, thuộc tính và định danh. Mục 3 trình bày liên kết và bản số, phần khó nhất và quan trọng nhất. Mục 4 phân loại thuộc tính. Mục 5 đi qua các cấu trúc đặc biệt thường bị vẽ sai. Mục 6 ráp mọi thứ thành sơ đồ của Sen Vàng Mart và so sánh các ký pháp ER.

1. Thu thập yêu cầu dữ liệu

Bài Quy trình phát triển hệ thống cơ sở dữ liệu đã cho thấy thu thập yêu cầu là bước đầu tiên và quyết định nhất. Yêu cầu dữ liệu (data requirements) là mô tả những gì cơ sở dữ liệu cần lưu trữ: các đối tượng, đặc điểm của chúng, mối liên hệ giữa chúng và các quy tắc nghiệp vụ ràng buộc dữ liệu (Jukić, 2025). Yêu cầu dữ liệu khác yêu cầu chức năng ("hệ thống phải in được hóa đơn"): nó không nói hệ thống làm gì mà nói hệ thống phải nhớ gì.

1.1. Bốn nguồn và một quy tắc viết

Người phân tích có bốn nguồn chính. Phỏng vấn người dùng ở các vị trí khác nhau, vì mỗi người thấy một phần của nghiệp vụ. Chứng từ và biểu mẫu đang dùng cho biết dữ liệu nào đang thật sự được ghi. Quan sát công việc thực tế, vì người ta thường mô tả quy trình như nó nên diễn ra chứ không như nó đang diễn ra. Và hệ thống cũ, như các tệp Excel, vừa cho biết dữ liệu hiện có vừa phơi bày những chỗ dữ liệu đang mâu thuẫn.

Sản phẩm của bước này là một danh sách câu yêu cầu viết dưới dạng khẳng định có thể kiểm chứng: "Mỗi hóa đơn được lập tại đúng một cửa hàng", chứ không phải "hệ thống quản lý hóa đơn của các cửa hàng". Câu thứ nhất có thể sai và chính vì có thể sai nên người dùng mới kiểm tra được. Câu thứ hai không bao giờ sai, nên cũng không giúp được gì.

1.2. Câu hỏi phỏng vấn quyết định cấu trúc

Phần lớn lỗi thiết kế nằm ở các con số "một" và "nhiều" ẩn trong lời kể. Người dùng hiếm khi nói thẳng ra chúng, nên người phân tích phải hỏi. Bảng 1 gom các câu hỏi phỏng vấn theo cấu trúc ER mà câu trả lời quyết định.

Bảng 1. Câu hỏi phỏng vấn và cấu trúc ER mà câu trả lời quyết định

Nguồn: dựa trên Jukić (2025).

Mỗi ký hiệu trên sơ đồ ER phải truy được về câu trả lời cho một câu hỏi trong Bảng 1; bản số nào không hỏi thì sẽ bị đoán. Một cạm bẫy thường gặp ở bước này là mô hình hóa biểu mẫu thay vì nghiệp vụ: cầm tờ hóa đơn in lên rồi vẽ một thực thể "HÓA ĐƠN IN" với đủ các cột trên giấy, gồm tên và địa chỉ cửa hàng, tên thu ngân, tên và giá từng món. Kết quả là chép lại đúng sự dư thừa của các tệp Excel. Tờ hóa đơn là một báo cáo tổng hợp từ nhiều thực thể như cửa hàng, nhân viên, sản phẩm, hóa đơn, chứ không phải một thực thể.

2. Thực thể, thuộc tính và định danh

Ba khái niệm nền của mô hình ER có định nghĩa ngắn gọn, nhưng mỗi khái niệm đi kèm một quyết định thiết kế. Mục này trình bày từng khái niệm và cạm bẫy đi kèm.

Thực thể (entity) là một loại đối tượng mà tổ chức muốn lưu dữ liệu về nó: một người, một vật, một sự kiện hay một khái niệm, như KHACHHANG, SANPHAM, HOADON. Mỗi đối tượng cụ thể thuộc loại đó là một thể hiện (instance): khách hàng Nguyễn Thị Lan là một thể hiện của KHACHHANG. Thuộc tính (attribute) là một đặc điểm của thực thể mà ta muốn ghi lại, như họ tên hay ngày sinh. Trên sơ đồ, thực thể vẽ bằng hình chữ nhật, thuộc tính bằng hình bầu dục nối với thực thể.

Mỗi thực thể phải có ít nhất một định danh (identifier): một thuộc tính mà giá trị của nó khác nhau ở mọi thể hiện, được gạch chân trên sơ đồ. Chọn định danh là một quyết định thiết kế, không phải một quan sát. Một định danh tốt phải duy nhất, ổn định và luôn có giá trị. Tên khách hàng trượt ngay tiêu chí đầu, vì một chuỗi vài chục nghìn thành viên chắc chắn có nhiều người trùng tên. Số điện thoại trượt tiêu chí thứ hai, vì khách đổi số và nhà mạng cấp lại số cũ cho người khác. Vì vậy hầu hết hệ thống tự đặt một mã riêng như MaKH, một mã không mang nghĩa gì ngoài việc định danh nên không có lý do gì để thay đổi.

Hai cạm bẫy hay gặp ở mục này. Thứ nhất, vẽ thể hiện thành thực thể: sơ đồ có ba hình chữ nhật CUAHANG_CAUGIAY, CUAHANG_HAICHAU, CUAHANG_QUAN1 và mỗi lần mở cửa hàng mới lại phải sửa sơ đồ, dấu hiệu chắc chắn rằng đó là dữ liệu chứ không phải cấu trúc. Thứ hai, coi một giá trị như thuộc tính: vẽ thuộc tính "HangVang" cho KHACHHANG, trong khi hạng Vàng chỉ là một giá trị của thuộc tính HangTV bên cạnh Đồng và Bạc.

3. Liên kết và bản số

Thực thể đứng riêng thì chưa nói được gì về nghiệp vụ; nghiệp vụ nằm ở cách chúng gắn với nhau. Mục này trình bày khái niệm quan trọng nhất của mô hình ER, cũng là nơi sinh ra phần lớn lỗi thiết kế.

3.1. Cách đọc bản số

Liên kết (relationship) là mối gắn kết giữa các thực thể, vẽ bằng hình thoi nối với các thực thể tham gia và đặt tên bằng một động từ: CUAHANG LapTai HOADON. Mỗi đầu của liên kết mang một ràng buộc bản số gồm hai phần. Bản số tối đa cho biết một thể hiện của thực thể bên kia gắn với nhiều nhất bao nhiêu thể hiện của thực thể ở đầu này: một hoặc nhiều. Bản số tối thiểu cho biết gắn với ít nhất bao nhiêu: không (tham gia tùy chọn) hoặc một (tham gia bắt buộc). Trong ký pháp mà bài này dùng, cũng là ký pháp của công cụ ERDPlus, ký hiệu nằm sát thực thể là bản số tối đa (vạch thẳng là một, chân chim là nhiều), ký hiệu xa hơn là bản số tối thiểu (vòng tròn là không, vạch thẳng là một) (Jukić, 2025). Hình 1 cho thấy bốn tổ hợp có thể có.

Hình 1. Bốn tổ hợp ký hiệu bản số. Nguồn: dựa trên Jukić (2025).

Quy tắc đọc cần nhớ chính xác: ký hiệu ở đầu thực thể X cho biết có bao nhiêu thể hiện của X ứng với MỘT thể hiện của thực thể bên kia. Mỗi liên kết hai ngôi vì vậy luôn chứa hai câu và cả hai câu đều phải được người dùng xác nhận. Với liên kết giữa cửa hàng và nhân viên: một cửa hàng có không hoặc nhiều nhân viên (ký hiệu ở đầu NHANVIEN); một nhân viên làm việc tại một hoặc nhiều cửa hàng (ký hiệu ở đầu CUAHANG). Sửa lỗi nhân viên thời vụ ở đầu bài trên sơ đồ chỉ là đổi một ký hiệu, mất vài giây; chính vì rẻ như vậy nên phải làm nó ở đây, trước khi có bảng và màn hình.

Xét bản số tối đa ở hai đầu, liên kết hai ngôi chia thành ba loại: một – một (mỗi cửa hàng có đúng một cửa hàng trưởng), một – nhiều (một cửa hàng lập nhiều hóa đơn, mỗi hóa đơn lập tại đúng một cửa hàng) và nhiều – nhiều (một hóa đơn gồm nhiều sản phẩm, một sản phẩm xuất hiện trên nhiều hóa đơn). Phân loại này không chỉ để gọi tên: khi chuyển sang bảng, liên kết một – nhiều thành một khóa ngoại, còn liên kết nhiều – nhiều thành hẳn một bảng mới. Nhầm hai loại này là nhầm số bảng của cơ sở dữ liệu.

3.2. Bản số là quy tắc, không phải thống kê

Bản số mô tả điều được phép xảy ra, không mô tả điều thường xảy ra. Đây là ranh giới tinh tế nhất của mô hình ER. Đa số hóa đơn ở Sen Vàng Mart là của khách vãng lai; một số ít gắn với khách thành viên. Câu hỏi đúng không phải "phần lớn hóa đơn có khách thành viên không" mà là "có được phép tồn tại một hóa đơn không có khách thành viên không". Câu trả lời là có, nên bản số tối thiểu của KHACHHANG trong liên kết Mua là 0.

Cạm bẫy ở đây là chọn bản số tối thiểu bằng 1 vì "thường thì có". Người thiết kế hỏi "hóa đơn có khách hàng không?", người dùng nghĩ tới trường hợp điển hình và đáp "có". Khi hệ thống chạy, thu ngân không lập được hóa đơn cho khách vãng lai và cách chữa cháy quen thuộc là tạo một khách hàng giả tên "Khách lẻ" để mọi hóa đơn gắn vào, một bản ghi rác làm sai mọi báo cáo về khách hàng sau này. Cách phòng là luôn hỏi câu phủ định: "Có khi nào không có không?" Cạm bẫy thứ hai là đọc ngược chiều: đặt ký hiệu "nhiều" ở đầu CUAHANG khi muốn nói "một cửa hàng có nhiều hóa đơn". Cách kiểm tra nhanh là luôn đọc thành câu đầy đủ, bắt đầu bằng "Một [thực thể bên kia]…".

3.3. Kiểm tra bằng thể hiện và thuộc tính của liên kết

Một kỹ thuật đơn giản để kiểm tra bản số là viết ra vài thể hiện cụ thể và xem chúng có phá vỡ ràng buộc nào không (Jukić, 2025). Bảng 2 liệt kê các cặp hóa đơn và sản phẩm của ba hóa đơn giả định.

Bảng 2. Vài thể hiện cụ thể của liên kết giữa hóa đơn và sản phẩm (giả định)

Bảng 2 đủ để bác bỏ một bản số sai: HD0001 có ba sản phẩm và SV0101 có mặt trên hai hóa đơn, nên liên kết không thể là một – nhiều theo chiều nào cả. Kỹ thuật này có một giới hạn: dữ liệu chỉ có thể bác bỏ một bản số, không thể chứng minh nó. Dữ liệu cũ chưa có trường hợp một hóa đơn thuộc hai cửa hàng không có nghĩa là quy tắc cấm điều đó. Quy tắc phải lấy từ người dùng; dữ liệu chỉ dùng để thử.

Bảng 2 còn cho thấy một điều: cột "Số lượng" và "Đơn giá bán" không thuộc về hóa đơn, cũng không thuộc về sản phẩm, mà là đặc điểm của cặp hóa đơn và sản phẩm, tức của chính liên kết. Mô hình ER cho phép gắn thuộc tính vào hình thoi để diễn đạt điều này. Đơn giá bán là ví dụ đáng giá: sản phẩm đã có giá niêm yết, nhưng giá niêm yết thay đổi theo thời gian và theo khuyến mãi, như mì ly ở HD0003 bán 8.100 đồng trong đợt giảm 10%. Nếu chỉ lưu giá ở SANPHAM, khi giá đổi thì mọi hóa đơn cũ tự động "đổi giá" theo và doanh thu quá khứ bị viết lại.

4. Các loại thuộc tính

Không phải thuộc tính nào cũng là một giá trị đơn, bắt buộc và được lưu trữ. Mô hình ER phân biệt thêm nhiều loại, mỗi loại dẫn tới một cách xử lý khác nhau khi chuyển sang bảng. Bảng 3 gom các loại cùng câu hỏi nhận biết từng loại.

Bảng 3. Các loại thuộc tính và câu hỏi nhận biết

Nguồn: dựa trên Jukić (2025).

Hai dòng của Bảng 3 đáng giải thích thêm. Với thuộc tính phức hợp, có nên tách hay không phụ thuộc vào câu hỏi nghiệp vụ: nếu chuỗi cần thống kê khách theo tỉnh thì phải tách; nếu địa chỉ chỉ để in lên phiếu giao hàng, một chuỗi văn bản là đủ. Thuộc tính dẫn xuất có giá trị tính được từ dữ liệu khác nên không được lưu trữ: một giá trị được lưu ở hai nơi, gốc và kết quả tính, sẽ có lúc lệch nhau. Ngoại lệ có chủ đích là lưu giá trị dẫn xuất để tăng tốc truy vấn, được bàn trong bài Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF dưới tên phi chuẩn hóa.

5. Các cấu trúc đặc biệt

Các cấu trúc trong mục này không cần nhiều ký hiệu mới; chúng là cách dùng các ký hiệu đã biết cho những tình huống nghiệp vụ thường bị vẽ sai. Mục này đi qua năm cấu trúc rồi đối chiếu ba cấu trúc dễ nhầm nhất.

Liên kết đệ quy là liên kết mà một thực thể tham gia hai lần với hai vai trò khác nhau: NHANVIEN tham gia liên kết QuanLy vừa với vai trò "quản lý" vừa với vai trò "bị quản lý". Vai trò phải được ghi rõ trên sơ đồ, vì không có chúng thì hai đầu liên kết trông giống hệt nhau và bản số không còn đọc được. Nhiều liên kết giữa cùng hai thực thể: CUAHANG và NHANVIEN gắn với nhau theo hai cách độc lập, làm việc tại (nhiều – nhiều) và là cửa hàng trưởng của (một – một). Gộp chúng làm một, chẳng hạn thêm thuộc tính "LaTruong" vào liên kết làm việc, không diễn đạt được quy tắc "mỗi cửa hàng có đúng một trưởng".

Thực thể yếu là thực thể không có định danh riêng, được định danh nhờ liên kết với một thực thể chủ cộng với một định danh bộ phận của chính nó (Jukić, 2025). Mỗi cửa hàng đánh số kệ từ 1, nên "kệ số 3" chỉ xác định được khi đi kèm "của cửa hàng Cầu Giấy". Thực thể kết hợp là một liên kết nhiều – nhiều được nâng thành thực thể khi nó cần định danh riêng hoặc cần tham gia liên kết khác, như hợp đồng cung ứng giữa nhà cung cấp và sản phẩm. Liên kết ba ngôi nối ba thực thể cùng lúc, như sự kiện "nhà cung cấp A cung ứng sản phẩm X cho cửa hàng C". Bảng 4 phân biệt ba cấu trúc này.

Bảng 4. Ba cấu trúc dễ nhầm

Nguồn: dựa trên Jukić (2025).

Người mới thường thay liên kết ba ngôi bằng ba liên kết hai ngôi vì trông đơn giản hơn, nhưng cách đó làm mất thông tin. Nếu A cung ứng sữa cho Cầu Giấy, B cung ứng sữa cho Hải Châu và A cung ứng mì cho Hải Châu, thì ba bảng cặp đều có (A, sữa), (sữa, Hải Châu) và (A, Hải Châu); từ đó ta "suy ra" A cung ứng sữa cho Hải Châu, điều chưa từng xảy ra. Tuy vậy, liên kết ba ngôi khó đọc bản số và hiếm gặp; trước khi vẽ, nên hỏi người dùng xem sự kiện có thật sự gắn ba bên cùng lúc không.

6. Sơ đồ của Sen Vàng Mart và các ký pháp

Mục cuối ráp các cấu trúc đã học thành một sơ đồ hoàn chỉnh, rồi đặt ký pháp của bài cạnh các ký pháp phổ biến khác.

6.1. Ba vòng phản hồi

Sau buổi phỏng vấn đầu tiên, nhóm phát triển có 14 câu yêu cầu về cửa hàng, nhân viên, nhóm hàng, sản phẩm, nhà cung cấp, phiếu nhập, khách hàng thành viên, hóa đơn và khuyến mãi. Bản nháp sơ đồ đầu tiên được đem lại cho chủ chuỗi đọc và qua ba vòng phản hồi, ba lỗi bị phát hiện. Vòng 1: liên kết làm việc được vẽ một – nhiều theo câu "mỗi nhân viên làm việc tại một cửa hàng"; chủ chuỗi chỉ ra trường hợp nhân viên thời vụ và liên kết đổi thành nhiều – nhiều. Vòng 2: bản số tối thiểu của KHACHHANG trong liên kết Mua là 1; chủ chuỗi nhắc rằng phần lớn khách là khách vãng lai và nó đổi thành 0. Vòng 3: chỉ có giá niêm yết ở SANPHAM; chủ chuỗi cho biết giá trên hóa đơn ngày khuyến mãi khác giá niêm yết và liên kết Gom được thêm thuộc tính đơn giá bán. Hình 2 là phần chính của sơ đồ sau vòng 3.

Hình 2. Sơ đồ ER rút gọn của Sen Vàng Mart sau ba vòng phản hồi (tình huống giả định).

Cả ba lỗi trong Hình 2 đều là lỗi bản số hoặc lỗi chỗ đặt thuộc tính, đúng hai loại lỗi mà Bảng 1 dự báo và cả ba được sửa trong vài phút trên giấy, trước khi có bất kỳ bảng hay màn hình nào. Một điều làm người mới bối rối: cùng một bộ yêu cầu có thể cho ra nhiều sơ đồ đúng. Tiêu chí chọn không phải sơ đồ nào "đẹp" hơn, mà là sơ đồ nào khớp mọi yêu cầu và không thêm điều gì yêu cầu không nói. Bước tiếp theo là chuyển sơ đồ thành các bảng, như bài SQL từ cơ bản đến nâng cao dùng.

6.2. Các ký pháp ER

Không có một ký pháp ER duy nhất. Chen (1976), người đề xuất mô hình ER, dùng hình thoi cho liên kết và ghi bản số bằng chữ số. Ký pháp chân chim (crow's foot) bỏ hình thoi, ghi tên liên kết lên đường nối và dùng ký hiệu chân chim. UML vẽ thực thể như lớp và ghi bản số dạng 1, 0..*. Ký pháp của bài này là một biến thể của Chen dùng ký hiệu bản số kiểu chân chim, giống Jukić (2025). Điểm khác biệt đáng kể nhất giữa các ký pháp là chỗ đặt thuộc tính của liên kết nhiều – nhiều: ký pháp của bài gắn bầu dục vào hình thoi, ký pháp chân chim phải tạo thực thể trung gian, UML dùng lớp liên kết. Đọc được một ký pháp là chuyển được sang ký pháp kia. Mô hình ER còn có bản mở rộng (EER) với khái niệm khái quát hóa và chuyên biệt hóa, hữu ích khi các loại con của một thực thể khác nhau nhiều (Elmasri & Navathe, 2016).

AI có thể giúp ở hai lượt. Trước khi vẽ, dán các câu yêu cầu vào một trợ lý AI và yêu cầu nó chỉ ra những đầu liên kết chưa rõ bản số, rồi mang câu hỏi đó đi hỏi người dùng. Sau khi vẽ, mô tả sơ đồ bằng văn bản để AI đối chiếu với yêu cầu. Cần cảnh giác: AI hay tự điền bản số tối thiểu theo "lẽ thường" thay vì báo là chưa rõ, đúng cạm bẫy "thường thì có" và đôi khi đọc ngược chiều bản số. Mỗi bản số AI đề xuất phải chỉ được về một câu yêu cầu cụ thể; bài Trí tuệ nhân tạo cho dữ liệu văn phòng có thêm ví dụ dùng AI thiết kế bảng.

Kết luận

Mô hình thực thể liên kết là nơi rẻ nhất để sửa một thiết kế cơ sở dữ liệu. Sự cố nhân viên thời vụ ở Sen Vàng Mart tốn ba tháng và nhiều công sức khi phát hiện trên hệ thống đang chạy, nhưng chỉ tốn vài giây khi phát hiện trên sơ đồ. Muốn phát hiện sớm, người thiết kế cần đặt đúng câu hỏi: có khi nào một A gắn với nhiều B không, có khi nào không có không, thông tin này ghi cho A hay cho mỗi lần A gặp B.

Bản số là quy tắc chứ không phải thống kê, phải lấy từ người dùng và chỉ dùng dữ liệu để thử. Thuộc tính của liên kết, thuộc tính dẫn xuất và các cấu trúc đặc biệt như thực thể yếu hay liên kết ba ngôi đều có lý do tồn tại riêng và nhầm lẫn giữa chúng dẫn tới sai số bảng hoặc mất thông tin. Một sơ đồ tốt là sơ đồ mà mỗi ký hiệu truy được về một câu yêu cầu và người dùng đọc vào là thấy ngay chỗ sai.

Đọc thêm

• Quy trình phát triển hệ thống cơ sở dữ liệu
• Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF
• SQL từ cơ bản đến nâng cao
• Kho dữ liệu là gì và khi nào doanh nghiệp cần nó
• Trí tuệ nhân tạo cho dữ liệu văn phòng
• Hệ thống thông tin trong doanh nghiệp

Tài liệu tham khảo

Chen, P. P.-S. (1976). The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9–36. https://doi.org/10.1145/320434.320440

Elmasri, R., & Navathe, S. B. (2016). Fundamentals of database systems (7th ed.). Pearson. https://www.pearson.com/en-us/subject-catalog/p/fundamentals-of-database-systems/P200000003546/9780137502523

Jukić, N. (2025). Database systems: Introduction to databases and data warehouses (3rd ed.). Prospect Press. https://www.prospectpressvt.com/textbooks/jukic-database-systems-introduction-to-databases-and-data-warehouses-3-0