CHUYỂN SƠ ĐỒ ER SANG BẢNG

Khóa ngoại và bảng mới biến mọi liên kết trên sơ đồ ER thành ràng buộc mà cơ sở dữ liệu tự giữ

---

Một sơ đồ thực thể liên kết (ER) được vẽ cẩn thận là bản thiết kế tốt nhất mà người làm cơ sở dữ liệu có trong tay. Nhưng hệ quản trị cơ sở dữ liệu không đọc được sơ đồ. Nó chỉ hiểu bảng, cột, khóa và ràng buộc. Giữa bản vẽ và hệ thống chạy thật vì thế có một bước dịch, gọi là chuyển đổi ER sang mô hình quan hệ và đây là bước mà nhiều lỗi thiết kế nằm im suốt nhiều năm: một khóa ngoại đặt sai phía, một bảng trung gian chọn sai khóa chính, một liên kết một – một quên ràng buộc duy nhất.

Tin tốt là bước dịch này có quy tắc rõ ràng. Toàn bộ các quy tắc chỉ dùng hai công cụ: khóa ngoại và bảng mới. Phần khó không nằm ở việc nhớ quy tắc mà ở việc chọn khóa chính cho đúng nghiệp vụ và hiểu mỗi quyết định để lại hệ quả gì trên dữ liệu. Bài viết này đi qua các quy tắc đó trên sơ đồ của Sen Vàng Mart, một chuỗi siêu thị giả định có 18 cửa hàng và dùng chính dữ liệu bán hàng của chuỗi để đo hệ quả của từng quyết định.

Bài viết đi theo trình tự sau. Mục 1 nhắc lại những gì làm nên một bảng quan hệ và các loại khóa. Mục 2, 3 và 4 lần lượt trình bày cách chuyển ba loại liên kết: một – nhiều, nhiều – nhiều, một – một. Mục 5 gom các cấu trúc đặc biệt vào một bảng tra cứu. Mục 6 áp dụng tất cả cho sơ đồ Sen Vàng Mart và mục 7 đưa ra cách kiểm tra một lược đồ, kể cả lược đồ do công cụ hay AI sinh ra. Bài tiếp nối bài Mô hình thực thể liên kết ER và cách đọc bản số, nơi sơ đồ được vẽ.

1. Bảng quan hệ và các loại khóa

Trước khi chuyển đổi, cần rõ đích đến. Mục này nhắc lại các điều kiện của một bảng quan hệ và vai trò của từng loại khóa.

Mô hình quan hệ tổ chức mọi dữ liệu thành các quan hệ (relation), tức những bảng hai chiều có tên. Mỗi cột là một thuộc tính, mỗi dòng ghi một thể hiện và tập giá trị hợp lệ của một cột là miền (domain) của nó (Codd, 1970). Không phải bảng nào cũng là quan hệ. Để là một quan hệ, bảng phải thỏa vài điều kiện mà bảng tính không đòi hỏi: mỗi ô chứa đúng một giá trị, không có hai dòng trùng nhau hoàn toàn và thứ tự dòng cũng như thứ tự cột không mang nghĩa. Điều kiện cuối là nơi người quen Excel hay vấp. Trong bảng tính, người ta thường dựa vào vị trí, chẳng hạn quy ước "dòng cuối là dòng tổng"; trong một quan hệ, thông tin nào phụ thuộc vào vị trí phải được ghi thành giá trị trong một cột.

Vì không có hai dòng trùng nhau, mỗi bảng luôn có một tập cột đủ để phân biệt mọi dòng; đó là khóa. Bảng 1 tóm tắt các loại khóa sẽ dùng trong bài.

Bảng 1. Các loại khóa và vai trò của chúng

Nguồn: dựa trên Elmasri và Navathe (2016), Jukić (2025).

Khóa chính được chọn theo bốn tiêu chí: duy nhất, ổn định, luôn có giá trị và ngắn gọn, vì nó sẽ được chép sang mọi bảng trỏ tới nó. Không cột nào thuộc khóa chính được phép rỗng; đó là ràng buộc toàn vẹn thực thể (Codd, 1970). Khi không có khóa tự nhiên nào đạt yêu cầu, người thiết kế dùng khóa thay thế. Ở đây có một cạm bẫy phổ biến: thêm một cột ID tự tăng vào mọi bảng rồi coi như xong việc chọn khóa. Cột ID bảo đảm hai dòng khác nhau về ID, nhưng không gì ngăn một nhà cung cấp được nhập hai lần với hai ID mà cùng một mã số thuế. Khóa thay thế giải quyết bài toán kỹ thuật là có cái để trỏ tới, không giải quyết bài toán nghiệp vụ là không trùng đối tượng. Dùng khóa thay thế thì định danh nghiệp vụ vẫn phải được khai báo UNIQUE.

Quy tắc chuyển một thực thể khá thẳng: mỗi thực thể thành một bảng, mỗi thuộc tính đơn thành một cột, định danh thành khóa chính. Phần còn lại của bài là về liên kết, nơi mọi quyết định khó nằm.

2. Liên kết một – nhiều

Đây là loại liên kết phổ biến nhất. Mục này trình bày quy tắc, cạm bẫy và hệ quả đo được của một chi tiết nhỏ là bản số tối thiểu.

Liên kết một – nhiều trở thành một khóa ngoại đặt ở bảng phía nhiều, trỏ tới khóa chính của bảng phía một. Mỗi hóa đơn thuộc đúng một cửa hàng, nên mỗi dòng HOADON có đúng một ô MaCH để ghi cửa hàng đó; một cửa hàng có hàng chục nghìn hóa đơn nhưng không cần cột nào để liệt kê chúng. Hình 1 đặt ba loại liên kết cạnh nhau cùng kết quả chuyển đổi của mỗi loại.

Hình 1. Ba loại liên kết và kết quả chuyển đổi: khóa ngoại ở phía nhiều, bảng mới cho nhiều – nhiều, khóa ngoại có ràng buộc duy nhất cho một – một. Nguồn: dựa trên Jukić (2025).

Cạm bẫy thường gặp nhất là đặt khóa ngoại ở phía "một". Đọc câu "một cửa hàng có nhiều hóa đơn", người mới thường thêm vào bảng cửa hàng một cột DanhSachHoaDon và điền "HD0001, HD0003, HD0007...". Từ "có" khiến ta đặt thông tin vào chủ ngữ của câu. Kết quả vi phạm điều kiện mỗi ô một giá trị, không kiểm soát được tham chiếu và mỗi hóa đơn mới buộc phải sửa dòng cửa hàng. Mẹo kiểm tra đơn giản: phía nào chỉ cần ghi một giá trị thì khóa ngoại nằm ở phía đó.

Bản số tối thiểu trên sơ đồ cũng phải đi theo sang bảng. Mỗi hóa đơn bắt buộc có cửa hàng, nên cột MaCH trong HOADON được khai báo NOT NULL. Ngược lại, khách hàng tham gia tùy chọn: khách vãng lai không có thẻ thành viên, nên cột MaKH trong HOADON được phép rỗng. Một chữ "tùy chọn" trên sơ đồ nghe nhỏ, nhưng hệ quả của nó trên dữ liệu thì không. Bảng 2 đo hệ quả đó trên toàn bộ dữ liệu bán hàng hai năm của Sen Vàng Mart.

Bảng 2. Hóa đơn có và không có mã khách hàng, Sen Vàng Mart 2024 và 2025

Nguồn: kết quả truy vấn trên bộ dữ liệu mô phỏng Sen Vàng Mart, SQLite.

Bảng 2 cho thấy gần hai phần ba hóa đơn và doanh thu thuộc về khách vãng lai. Nếu người thiết kế ép cột MaKH thành bắt buộc, hai phần ba giao dịch sẽ không ghi được, hoặc thu ngân sẽ bịa ra một "khách hàng chung" làm méo mọi phân tích về khách. Cột được phép rỗng là lựa chọn đúng, nhưng nó kéo theo một trách nhiệm cho người viết truy vấn: phép kết nối thông thường giữa HOADON và KHACHHANG chỉ giữ những dòng khớp, nên một báo cáo "doanh thu theo khách hàng" viết bằng INNER JOIN sẽ lặng lẽ báo 19,40 tỷ thay vì 55,23 tỷ đồng. Cách giữ lại các dòng không khớp, kết nối ngoài, được trình bày trong bài SQL từ cơ bản đến nâng cao.

3. Liên kết nhiều – nhiều

Liên kết nhiều – nhiều không thể biểu diễn bằng một khóa ngoại. Mục này trình bày bảng mới sinh ra từ nó và câu hỏi quan trọng nhất khi chọn khóa chính cho bảng đó.

Một hóa đơn có nhiều sản phẩm, nên bảng hóa đơn không có chỗ cho một ô MaSP; một sản phẩm có mặt trên nhiều hóa đơn, nên bảng sản phẩm cũng không. Lời giải là tạo một bảng mới gồm hai khóa ngoại trỏ tới hai bảng tham gia; khóa chính của bảng mới thường là tổ hợp hai khóa ngoại đó; các thuộc tính của liên kết trở thành những cột còn lại (Jukić, 2025). Ở Sen Vàng Mart, bảng này mang tên nghiệp vụ CHITIETHD, mỗi dòng là một sản phẩm trên một hóa đơn, với hai thuộc tính của liên kết là số lượng và đơn giá bán. Đơn giá bán nằm ở đây chứ không ở bảng sản phẩm, vì cùng một sản phẩm có thể bán với giá khác nhau trên các hóa đơn khác nhau khi có khuyến mãi. Bảng chi tiết thường là bảng lớn nhất của một hệ bán hàng: Sen Vàng Mart có 399.148 hóa đơn nhưng 939.668 dòng chi tiết.

Liên kết giữa nhân viên và cửa hàng cho thấy vì sao không thể "đơn giản hóa" một liên kết nhiều – nhiều thành một khóa ngoại. Dữ liệu phân công có 421 dòng cho 296 nhân viên; 87 nhân viên được phân công làm ở hơn một cửa hàng, chẳng hạn nhân viên thời vụ được điều động giữa các cửa hàng gần nhau. Nếu người thiết kế đặt một cột MaCH trong bảng nhân viên vì nghĩ "mỗi người làm ở một cửa hàng", 87 người này chỉ ghi được một nơi làm việc và lịch sử phân công thật sẽ mất. Câu hỏi "một nhân viên có thể làm ở nhiều cửa hàng không?" phải được hỏi người dùng ngay từ khi vẽ sơ đồ.

Khóa chính ghép (SoHD, MaSP) mang theo một tuyên bố nghiệp vụ: một sản phẩm xuất hiện nhiều nhất một lần trên một hóa đơn. Với siêu thị, điều đó đúng, vì mua ba chai nước thì ghi một dòng số lượng 3. Nhưng thử nghĩ tới một thư viện, nơi bảng mượn sách có khóa (SoThe, MaSach): khóa này tuyên bố một người chỉ mượn một cuốn sách đúng một lần trong đời và điều đó sai. Khi liên kết nhiều – nhiều ghi lại một sự kiện có thể lặp lại giữa cùng một cặp, có hai cách sửa: đưa thuộc tính phân biệt các lần lặp vào khóa, như (SoThe, MaSach, NgayMuon), hoặc dùng một khóa thay thế như MaLuotMuon. Cách thứ nhất vẫn sai nếu một người có thể mượn cùng cuốn hai lần trong một ngày. Câu hỏi phải đặt cho người dùng là: cặp này có bao giờ lặp lại không và nếu có thì điều gì phân biệt các lần?

4. Liên kết một – một

Liên kết một – một cho phép đặt khóa ngoại ở bất kỳ phía nào, nên câu hỏi là phía nào tốt hơn. Mục này trả lời bằng số liệu.

Xét liên kết "là cửa hàng trưởng": mỗi cửa hàng có đúng một cửa hàng trưởng, mỗi nhân viên làm trưởng nhiều nhất một cửa hàng. Sen Vàng Mart có 300 nhân viên và 18 cửa hàng. Nếu đặt khóa ngoại MaCHQuanLy trong bảng nhân viên, chỉ 18 nhân viên có giá trị và 282 ô còn lại, tức 94%, là NULL. Nếu đặt khóa ngoại MaNVTruong trong bảng cửa hàng, cả 18 ô đều có giá trị, cột có thể khai báo NOT NULL và hệ quản trị tự kiểm soát luôn quy tắc "mọi cửa hàng phải có trưởng". Quy tắc rút ra: đặt khóa ngoại ở phía tham gia bắt buộc; nếu cả hai phía cùng bắt buộc hoặc cùng tùy chọn thì chọn phía nào cũng được (Jukić, 2025).

Chi tiết hay bị quên là khóa ngoại của liên kết một – một phải mang ràng buộc UNIQUE. Không có UNIQUE, không gì ngăn một nhân viên được ghi làm trưởng của ba cửa hàng; liên kết một – một trên sơ đồ đã lặng lẽ thành một – nhiều trong cơ sở dữ liệu. Lược đồ của Sen Vàng Mart khai báo cột này như sau:

MaNVTruong TEXT NOT NULL UNIQUE REFERENCES NHANVIEN (MaNV)

Một dòng khai báo chứa đủ ba quyết định: NOT NULL giữ bản số tối thiểu, UNIQUE giữ bản số tối đa bằng một ở phía nhân viên, REFERENCES giữ toàn vẹn tham chiếu. Đây là ví dụ rõ nhất cho ý chính của bài: mỗi ký hiệu trên sơ đồ ER đều phải đi đâu đó trong lược đồ, nếu không nó chỉ còn tồn tại trong trí nhớ của người thiết kế.

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

Các cấu trúc còn lại trên sơ đồ ER đều dùng lại hai công cụ đã có, theo những cách kết hợp riêng. Mục này gom chúng vào một bảng tra cứu.

Thuộc tính đa trị, như một khách hàng có nhiều số điện thoại, trở thành một bảng riêng gồm khóa của thực thể và cột giá trị. Cách làm sai phổ biến là tạo sẵn các cột SoDienThoai1, SoDienThoai2, SoDienThoai3: khách có bốn số thì không có chỗ, phần lớn khách chỉ có một số thì hai cột kia rỗng và câu hỏi "khách nào có số 0905..." phải tìm trong ba cột. Liên kết đệ quy một – nhiều, như nhân viên có quản lý cũng là nhân viên, trở thành khóa ngoại trỏ về chính bảng đó, với tên cột phản ánh vai trò (MaNVQuanLy); cột này được phép rỗng vì giám đốc chuỗi không có quản lý và trong dữ liệu Sen Vàng Mart đúng 1 trên 300 nhân viên có ô này rỗng. Thực thể yếu, như kệ hàng chỉ có số thứ tự trong từng cửa hàng, có khóa chính ghép từ khóa của thực thể chủ và định danh bộ phận. Bảng 3 tổng hợp mọi quy tắc.

Bảng 3. Bảng tra cứu quy tắc chuyển đổi ER sang lược đồ quan hệ

Nguồn: dựa trên Jukić (2025), Elmasri và Navathe (2016).

Dòng thuộc tính dẫn xuất trong Bảng 3 đáng một lời giải thích. Tổng tiền của hóa đơn có thể tính từ các dòng chi tiết, nên không lưu thành cột. Lưu nó lại nghĩa là cùng một sự thật được ghi ở hai nơi và sớm muộn hai nơi sẽ lệch nhau khi ai đó sửa một dòng chi tiết mà quên sửa tổng. Ngoại lệ hợp lý duy nhất là khi tính lại quá tốn kém và có cơ chế bảo đảm đồng bộ; quyết định đó thuộc về bước tối ưu hiệu năng, không thuộc bước chuyển đổi.

6. Ví dụ tổng hợp: lược đồ Sen Vàng Mart

Áp dụng Bảng 3 cho toàn bộ sơ đồ của Sen Vàng Mart cho ra một lược đồ hoàn chỉnh. Mục này đọc lược đồ đó như một bản đối chiếu với sơ đồ gốc.

Sơ đồ ER của chuỗi có chín thực thể và mười hai liên kết. Chín thực thể sinh ra chín bảng: nhóm hàng, sản phẩm, khuyến mãi, nhà cung cấp, nhân viên, cửa hàng, phiếu nhập, khách hàng và hóa đơn. Bốn liên kết nhiều – nhiều sinh ra bốn bảng mới, được đặt tên theo cách nghiệp vụ vẫn gọi: chi tiết hóa đơn, chi tiết phiếu nhập, phân công và sản phẩm khuyến mãi. Tám liên kết còn lại, gồm sáu liên kết một – nhiều, liên kết một – một "là cửa hàng trưởng" và liên kết đệ quy "quản lý", không sinh bảng mà trở thành khóa ngoại. Hình 2 vẽ lược đồ thu được.

Hình 2. Lược đồ quan hệ Sen Vàng Mart: 13 bảng và 16 khóa ngoại. Mỗi mũi tên là một liên kết trên sơ đồ ER đã thành ràng buộc.

Số khóa ngoại trong Hình 2 kiểm được bằng một phép cộng: bốn bảng sinh ra từ liên kết nhiều – nhiều, mỗi bảng hai khóa ngoại, là tám; tám liên kết còn lại, mỗi liên kết một khóa ngoại, là tám nữa; tổng cộng 16. Truy vấn danh mục hệ thống của cơ sở dữ liệu thật cũng cho đúng 16 khóa ngoại. Phép đối chiếu này là cách kiểm tra rẻ nhất cho một lược đồ: nếu con số lệch, có một liên kết bị bỏ sót hoặc bị chuyển sai.

So với cách lưu dữ liệu bằng hàng chục tệp Excel trước đây của chuỗi, 13 bảng không ít hơn về số lượng, nhưng khác hẳn về bản chất. Trong các tệp Excel, giá niêm yết của một sản phẩm được chép ở mọi cửa hàng; trong lược đồ này, giá niêm yết ghi đúng một lần ở bảng sản phẩm, còn giá bán thực tế ghi một lần cho mỗi dòng chi tiết, hai sự thật khác nhau mỗi sự thật một chỗ. Mọi tham chiếu đi qua khóa ngoại, nên không thể trỏ tới một mã không tồn tại. Việc kiểm định lại lược đồ bằng một công cụ độc lập là chuẩn hóa, được trình bày trong bài Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF.

7. Kiểm tra lược đồ, kể cả khi do máy sinh ra

Các công cụ vẽ sơ đồ như ERDPlus có chức năng tự chuyển sơ đồ ER sang lược đồ quan hệ theo đúng các quy tắc ở Bảng 3 (ERDPlus, n.d.) và các mô hình ngôn ngữ lớn cũng làm được việc này với sơ đồ vừa phải. Mục này nêu những chỗ máy hay sai và một danh sách kiểm tra cho người duyệt.

Công cụ áp dụng quy tắc chính xác nhưng không biết nghiệp vụ. Nó không thể tự nhận ra rằng bảng mượn sách ghi một sự kiện lặp lại, hay rằng bảng sinh ra từ liên kết "Gom" nên mang tên "chi tiết hóa đơn". Các mô hình ngôn ngữ thì hay sai ở ba chỗ: đặt khóa ngoại của liên kết một – một ở phía tùy chọn, quên UNIQUE và giữ thuộc tính dẫn xuất thành cột. Bảng 4 gom các câu hỏi kiểm tra mà người duyệt nên đặt cho mọi lược đồ, dù do người hay máy làm ra.

Bảng 4. Danh sách kiểm tra một lược đồ quan hệ sau chuyển đổi

Dòng cuối của Bảng 4 trỏ tới một giới hạn của mọi lược đồ. Có những quy tắc mà cả sơ đồ ER lẫn lược đồ không diễn đạt được bằng ký hiệu, chẳng hạn "ngày kết thúc khuyến mãi phải sau ngày bắt đầu" hay "mức giảm từ 1% đến 50%". Chúng cần được ghi thành một danh sách riêng ngay khi chuyển đổi, để ở bước cài đặt trở thành ràng buộc CHECK hoặc trigger. Thiếu danh sách đó, các quy tắc này thường bị cài rải rác trong mã ứng dụng, hoặc bị quên.

Kết luận

Chuyển sơ đồ ER sang bảng là bước có ít quy tắc nhất trong quá trình thiết kế cơ sở dữ liệu: chỉ hai công cụ, khóa ngoại và bảng mới, cộng với một bảng tra cứu ngắn. Nhưng nó là bước mà từng chi tiết nhỏ của sơ đồ biến thành hành vi có thật của hệ thống. Một chữ "tùy chọn" quyết định gần hai phần ba giao dịch của chuỗi siêu thị có được ghi hay không. Một liên kết nhiều – nhiều bị đơn giản hóa thành khóa ngoại làm mất lịch sử làm việc của 87 nhân viên. Một chữ UNIQUE bị quên biến quy tắc "mỗi người làm trưởng một cửa hàng" thành một lời hứa không ai giữ.

Vì vậy, người làm chuyển đổi không nên dừng ở việc áp quy tắc, mà nên đọc lại lược đồ như một bản đối chiếu với sơ đồ: mỗi mũi tên khóa ngoại tương ứng với liên kết nào, mỗi cột được phép rỗng tương ứng với bản số tối thiểu nào, mỗi khóa chính ghép đang tuyên bố điều gì về nghiệp vụ. Khi mọi câu trả lời đều khớp, lược đồ sẵn sàng cho bước chuẩn hóa và cài đặt.

Đọc thêm

• Mô hình thực thể liên kết ER và cách đọc bản số
• Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF
• Quy trình phát triển hệ thống cơ sở dữ liệu
• SQL từ cơ bản đến nâng cao

Tài liệu tham khảo

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685

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

ERDPlus. (n.d.). ERDPlus: A web-based database modeling tool. https://erdplus.com/

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