Chương 3-Bài 5. Tạo bảng (table) theo quan hệ Nhiều - Nhiều (N-N) - Sử dụng HeidiSQL

Các bước thiết kế Quan hệ Nhiều - Nhiều (N-N)

Step 1: Vẽ mô hình thực thể ER và xem xét Quan hệ giữa 2 table giang_vien và lop_hoc

Ta có Quan hệ thực tế giữa Giảng viên và Lớp học như sau:

• 1 Giảng viên thì có thể cùng lúc tham gia Giảng dạy cho 1 hoặc nhiều Lớp học.
• 1 Lớp học thì có thể có 1 hoặc nhiều Giảng viên giảng dạy.

Mô hình Thực thể ER mô tả Quan hệ giữa 2 table như sau:  

Step 2: đặt tên cho Mối quan hệ Nhiều - Nhiều (N-N)

Trong thực tế, để xác định hay ghi nhận Quá trình Công tác / hoặc Phân công Giảng dạy cho Giảng viên (cũng có thể gọi là sắp Thời khóa biểu) cho Giảng viên. Cán bộ phòng Đào tạo thường sẽ có 1 quyển sổ được đặt tên là bảng "Phân công Công tác/Giảng dạy" để ghi nhận lại Giảng viên nào? tham gia Giảng dạy Lớp học nào?  

Step 3: tiến hành tạo bảng (table) trung gian và chuyển mối liên hệ từ Nhiều - Nhiều (N-N) thành Một-Nhiều (1-N)

Theo quy tắc thiết kế Cơ sở dữ liệu, khi có Quan hệ Nhiều - Nhiều (N-N) xuất hiện, Cơ sở dữ liệu sẽ:

1. Sinh thêm Bảng (table) Trung gian.
2. Bảng (table) Trung gian sẽ có tên là tên của Mối quan hệ Nhiều - Nhiều (N-N). Thường đặt tên là Quá trình / Tham gia / Phân công, ...
3. Trong bảng (table) Trung gian sẽ có đầy đủ khóa ngoại (Foreign key - FK) liên kết đến table Master.
4. Trong bảng (table) Trung gian sẽ có thêm các cột dùng để lưu trữ thông tin bổ sung/làm rõ nghĩa Mối quan hệ Nhiều - Nhiều (N-N). Tuy nhiên, các cột này không bắt buộc (tùy vào thiết kế của bạn)

Dựa theo quy tắc trên, chúng ta có mô hình ER mới như sau:  

Step 4: lưu ý các Ràng buộc Logic về Nghiệp vụ lưu trữ dữ liệu

Thông thường, trong bất kỳ Hệ thống nào, cũng có tồn tại các quy tắc Ràng buộc về mặt lưu trữ. Theo ví dụ trên, ta có ràng buộc logic về Nghiệp vụ lưu trữ dữ liệu như sau:

• Phải đảm bảo rằng Một Giảng viên không được dạy cùng 1 Lớp học (tức là dữ liệu ghi nhận trong table phan_cong_cong_tac không được trùng nhau).
• Hay nói cách khác Một Lớp học không thể cùng lúc có nhiều Giảng viên giảng dạy được (trong 1 tiết học cụ thể, không thể có nhiều hơn 1 Giảng viên cùng đứng trên lớp?!)

Từ Ràng buộc logic về Nghiệp vụ Lưu trữ của Hệ thống yêu cầu như trên, chúng ta cần thiết kế lại mô hình ER như sau:

Cách giải quyết 1:

• Tiến hành tạo ràng buộc Khóa chính (Primary key - PK) bao gồm 2 cột (gv_id, lop_id)

Cách giải quyết 2:

• Tạo thêm 1 cột ID làm khóa chính (Primary key - PK), kiểu số nguyên, tự tăng trong table phan_cong_cong_tac
• Tạo khóa Duy nhất (Unique) bao gồm 2 cột (gv_id, lop_id) để đảm bảo rằng không thể có cặp dữ liệu (gv_id và lop_id) trùng lặp nhau.

Mở rộng thêm bảng (table) mon_hoc

Ta có mối quan hệ thực tế giữa 3 thực thể Giảng viên, Lớp học và Môn học như sau:

• 1 Giảng viên thì có thể cùng lúc tham gia Giảng dạy cho 1 hoặc nhiều Lớp học.
• 1 Lớp học thì có thể có 1 hoặc nhiều Giảng viên giảng dạy.
• 1 Lớp học thì có thể học 1 hoặc nhiều Môn học khác nhau (như Toán, Lý, Hóa, Lập trình Web, Thiết kế CSDL, ...)
• 1 Môn học có thể được dạy ở 1 hoặc nhiều Lớp học khác nhau
• ...

Bài tập: thiết kế CSDL có thể lưu trữ và trả lời được các câu hỏi Nghiệp vụ như sau:

1. Có thể biết và ghi nhận 1 Giảng viên nào? Đang dạy Môn học nào? Cho Lớp nào?
2. Có thể thống kê số lượng các Lớp mà 1 Giảng viên đang phụ trách giảng dạy là bao nhiêu?
3. Môn học nào đang được dạy ở các Lớp nhiều nhất?
4. Lớp nào đang được nhiều Giảng viên giảng dạy nhất?
5. ...

Một số ví dụ Quan hệ Nhiều - Nhiều (N-N) thực tế:

1. 1 Sản phẩm có thể cùng lúc thuộc 1 hoặc nhiều Chuyên mục <-> Một Chuyên mục có thể có 1 hoặc nhiều Sản phẩm.
2. 1 Nhân viên có thể cùng lúc Chấm công nhiều loại hình (Hành chính, Ngoài giờ, Ngày nghỉ, Lễ/Tết, ...) <-> Một loại hình Chấm công có thể có nhiều Nhân viên.
3. Một mẫu Kết quả Xét nghiệm có thể có 1 hoặc nhiều Tiêu chí <-> Một tiêu chí có thể có 1 hoặc nhiều Mẫu Kết quả Xét nghiệm.
4. Một phòng Khách sạn có thể có 1 hoặc nhiều Khách thuê <-> Một Khách thuê có thể thuê 1 hoặc nhiều phòng
5. ...