Quan hệ Nhiều-Nhiều: Hướng dẫn Thiết kế Cơ sở dữ liệu

Người dùng và người theo dõi, sinh viên và khóa học, khách hàng và sản phẩm: thế giới của chúng ta đầy những quan hệ nhiều-nhiều một cách tự nhiên. Tuy nhiên, chúng không phải lúc nào cũng được chuyển hóa tốt thành các thiết kế cơ sở dữ liệu. Quan hệ nhiều-nhiều được thiết kế kém là một trong những nguồn gốc phổ biến nhất gây trùng lặp dữ liệu, phân tích sai lệch và khó khăn bảo trì dài hạn trong các hệ thống sản xuất.

Trong bài viết này, tôi sẽ đi từ những nguyên lý đầu tiên đến triển khai trong thế giới thực của quan hệ nhiều-nhiều. Chúng ta cũng sẽ khám phá các mẫu thiết kế nâng cao, chuẩn hóa, các yếu tố hiệu năng, và cách quan hệ nhiều-nhiều được triển khai trên các hệ thống quan hệ và NoSQL.

Kết thúc bài, bạn sẽ có thể thiết kế các lược đồ có khả năng mở rộng, dễ bảo trì, mô hình hóa đúng các quan hệ phức tạp, tránh bất thường dữ liệu và hỗ trợ báo cáo cũng như quy trình BI đáng tin cậy. 

Với độc giả muốn củng cố nền tảng trong quá trình đọc, tôi khuyến nghị tham gia khóa Giới thiệu Cơ sở dữ liệu Quan hệ trong SQL của chúng tôi.

Quan hệ Nhiều-Nhiều là gì

Quan hệ nhiều-nhiều (M:N) là một quan hệ cơ sở dữ liệu hai chiều, trong đó mỗi bản ghi ở Bảng A có thể liên quan tới nhiều bản ghi ở Bảng B, và mỗi bản ghi ở Bảng B có thể liên quan tới nhiều bản ghi ở Bảng A. Khác với các loại quan hệ đơn giản hơn, tính lực lượng (cardinality) tồn tại ở cả hai phía.

Quan hệ này xuất hiện ở khắp nơi trong các hệ thống thực tế:

• Giáo dục: Một sinh viên có thể đăng ký nhiều khóa học, và mỗi khóa học có thể có nhiều sinh viên.
• Thương mại điện tử: Một sản phẩm có thể thuộc nhiều danh mục, và mỗi danh mục có thể chứa nhiều sản phẩm.
• Nền tảng xã hội: Người dùng có thể tham gia nhiều nhóm, và nhóm có thể có nhiều người dùng.
• Y tế: Một bệnh nhân có thể được kê nhiều loại thuốc, và mỗi loại thuốc có thể được kê cho nhiều bệnh nhân.

Quan hệ mang ý nghĩa và thường có dữ liệu riêng. Hiểu rõ khác biệt này là điều cốt yếu để thiết kế lược đồ và truy vấn đúng, đặc biệt khi kết nối bảng phục vụ phân tích.

Quan hệ nhiều-nhiều so với một-nhiều

Để hiểu vì sao quan hệ nhiều-nhiều cần xử lý đặc biệt, sẽ hữu ích khi so sánh với các lực lượng đơn giản hơn.

• Một-một (1:1): Mỗi bản ghi ở Bảng A liên quan chính xác một bản ghi ở Bảng B, và ngược lại (ví dụ: người dùng và hồ sơ người dùng).
• Một-nhiều (1:N): Một bản ghi ở Bảng A có thể liên quan tới nhiều bản ghi ở Bảng B, nhưng mỗi bản ghi ở Bảng B chỉ liên quan tới một bản ghi ở Bảng A (ví dụ: một khách hàng và các đơn hàng của họ).

For example, trong thiết kế một-nhiều, bảng đơn hàng thường chứa khóa ngoại customer_id với mỗi đơn hàng duy nhất có order_id. Mỗi đơn hàng thuộc về đúng một khách hàng, nhưng một khách hàng có thể có nhiều khóa order_id.

Giờ hãy so sánh với ví dụ sinh viên–khóa học. Nếu bạn cố gắng lưu course_id trực tiếp trên bảng sinh viên, mỗi sinh viên sẽ liên kết với nhiều giá trị course_id. Ngược lại, trong bảng khóa học, mỗi khóa sẽ có nhiều tham chiếu student_id. Thay vì một quan hệ một chiều gọn gàng, thì cả hai hướng đều chia sẻ thông tin qua lại.

Vi phạm Dạng chuẩn thứ nhất và bài toán Nhiều-Nhiều

Một lỗi phổ biến là cố đại diện trực tiếp quan hệ nhiều-nhiều bằng cách lưu nhiều giá trị trong một cột dưới dạng mảng (ví dụ course_ids trên bảng students) hoặc các cột lặp như course_1, course_2, course_3. 

Cách tiếp cận này vi phạm Dạng chuẩn thứ nhất (1NF), yêu cầu mỗi cột chứa các giá trị nguyên tử, không thể chia nhỏ. Đọc bài blog này về chuẩn hóa trong SQL để ôn lại.

Vi phạm 1NF dẫn đến các bất thường cập nhật kinh điển:

• Bất thường chèn: Thêm một quan hệ mới đòi hỏi sửa đổi cấu trúc hàng hiện có.
• Bất thường cập nhật: Thay đổi một quan hệ yêu cầu cập nhật nhiều hàng, nhiều cột hoặc các giá trị nhúng, làm tăng rủi ro không nhất quán.
• Bất thường xóa: Xóa một quan hệ có thể vô tình xóa thông tin không liên quan.

Vượt ra ngoài lý thuyết chuẩn hóa, còn có một hệ quả phân tích nghiêm trọng gọi là bài toán nhiều-nhiều. Khi các bảng có quan hệ nhiều-nhiều không được nối cẩn thận, rất dễ dẫn tới nhân bản hàng. Điều này có thể gây ra vấn đề về thời gian tính toán và lỗi tổng hợp trong phân tích. 

Ví dụ, nối courses với students dựa trên student_id có thể khiến mỗi khóa học bị nối nhiều lần do nhiều bản ghi sinh viên. Khi đó việc tổng hợp có thể dẫn tới sai lệch phân tích như doanh thu hay số lượng sinh viên. 

Thiết kế lược đồ đúng ảnh hưởng trực tiếp đến độ chính xác báo cáo, tính toán tài chính và niềm tin vào sản phẩm dữ liệu. Thêm nữa, nó giúp đơn giản hóa các phép nối để giảm lỗi do con người. Để biết thêm chi tiết về các sai sót thường gặp khi nối, hãy xem hướng dẫn nối SQL này và luyện tập với Top 20 câu hỏi về SQL Joins.

Bảng nối: Nền tảng và Cấu trúc

Giải pháp tiêu chuẩn cho quan hệ nhiều-nhiều trong hệ thống quan hệ là bảng nối (còn gọi là join table, bridge table, hoặc bảng kết hợp). Thay vì cố lưu trữ quan hệ trực tiếp, bạn đưa vào một bảng trung gian tham chiếu cả hai bảng cha.

Về mặt khái niệm, điều này biến A ↔ B thành A ← JT→ B.

Giờ đây, mỗi bảng có quan hệ một-nhiều với bảng nối, giúp đơn giản hóa lược đồ phân tích. Tôi sẽ trình bày cách chúng ta xây dựng các bảng nối này và cách chúng được sử dụng.

Cấu trúc và thành phần

Một bảng nối cơ bản gồm có:

• Một khóa ngoại tham chiếu khóa chính của Bảng A
• Một khóa ngoại tham chiếu khóa chính của Bảng B

Trong hầu hết trường hợp, hai khóa ngoại này cùng tạo thành một khóa chính tổng hợp. Điều này đảm bảo cùng một quan hệ không thể được chèn hai lần và thực thi tính duy nhất ở mức cơ sở dữ liệu.

Ví dụ, một bảng enrollments có thể dùng phép nối student_id và course_id làm khóa chính. Cơ sở dữ liệu giờ có một khóa tham chiếu duy nhất cho quan hệ và chúng ta có thể bắt đầu xây dựng các bài toán nghiệp vụ.

Ví dụ bảng nối enrollments có thể trông như thế nào.

Thêm thuộc tính vào bảng nối

Khi một bảng nối lưu trữ thêm thuộc tính, nó trở nên gần với một thực thể kết hợp hơn là một đồ tạo tác thuần cấu trúc. Điều này cho phép bảng nối chứa thông tin ngữ cảnh về quan hệ. Các ví dụ phổ biến gồm:

• Ngày tháng: enrollment_date, creation_date và các thông tin theo thời gian tương tự

• Vai trò: ví dụ admin so với thành viên trong một nhóm

• Chỉ số: điểm liên quan trong hệ thống gợi ý

Điều này giúp quan hệ mang nhiều ý nghĩa hơn. Độ phức tạp truy vấn tăng nhẹ, nhưng lược đồ mô hình hóa thực tế chính xác hơn. Sự đánh đổi này gần như luôn xứng đáng trong các hệ thống nơi quan hệ tiến hóa theo thời gian. Chúng ta có thể bổ sung thông tin và biến bảng nối thành công cụ phân tích hữu ích.

Duy trì toàn vẹn dữ liệu

Bảng nối phụ thuộc nhiều vào toàn vẹn tham chiếu. Ràng buộc khóa ngoại đảm bảo mỗi hàng quan hệ tham chiếu các bản ghi cha hợp lệ, ngăn dữ liệu mồ côi.

Quy tắc xóa rất quan trọng:

• CASCADE: Tự động xóa các hàng ở bảng nối khi một bản ghi cha bị xóa.
• RESTRICT / NO ACTION: Ngăn xóa bản ghi cha nếu vẫn còn quan hệ tồn tại.

Lựa chọn phụ thuộc vào ngữ nghĩa nghiệp vụ. Ở một số miền, dọn dẹp tự động là phù hợp; ở miền khác, quan hệ lịch sử phải được bảo toàn hoặc xem xét rõ ràng trước khi gỡ bỏ.

Chuẩn hóa và bảng nối

Bảng nối là ứng dụng trực tiếp của Dạng chuẩn thứ ba (3NF). Chúng loại bỏ phụ thuộc bắc cầu và xóa bỏ việc lưu trữ dư thừa dữ liệu quan hệ. Mục tiêu của nó là cải thiện mức độ chuẩn hóa trong cơ sở dữ liệu.

Trong nhiều trường hợp, bảng nối cũng giúp thỏa mãn Dạng chuẩn Boyce–Codd (BCNF) vì khóa chính tổng hợp xác định đầy đủ mọi thuộc tính không khóa. Điều này quan trọng vì nó giảm thiểu bất thường cập nhật và đảm bảo rằng sửa đổi một quan hệ chỉ cần thay đổi đúng một hàng.

Để hiểu sâu hơn tầm quan trọng của việc đảm bảo 3NF trong cơ sở dữ liệu, hãy xem bài viết về phụ thuộc bắc cầu.

Thiết kế và Triển khai Quan hệ Nhiều-Nhiều

Hãy bàn cách chúng ta thực sự xây dựng cơ sở dữ liệu để hỗ trợ quan hệ nhiều-nhiều. Chúng ta sẽ đề cập các thực hành tốt giúp bạn dễ dàng hơn.

Quy ước đặt tên và tính rõ ràng của lược đồ

Đặt tên bảng rõ ràng giúp giảm gánh nặng nhận thức và cải thiện khả năng bảo trì. Các quy ước phổ biến thường gồm TableA_TableB hoặc join_TableATableB, ví dụ:

• student_course

• user_group

• join_user_group

Tên cột nên phản chiếu khóa chính của bảng cha (ví dụ student_id, course_id) để phép nối trở nên hiển nhiên và dễ đọc. Tính nhất quán trở nên quan trọng khi lược đồ lớn dần và đội ngũ mở rộng.

Các mẫu phổ biến và biến thể

Có một vài cách khác nhau để xây dựng bảng nối, từ theo dõi quan hệ rất đơn giản tới quan hệ đa hình phức tạp hơn.

Bảng nối đơn giản

Bảng nối đơn giản chỉ chứa các khóa ngoại và lý tưởng cho những quan hệ tĩnh hoặc ít ngữ cảnh. Chúng rất dễ bảo trì với chi phí tối thiểu vì thường chỉ quan tâm thể hiện hai bảng liên quan thế nào. Những bảng nối này không có dữ liệu thời gian hay ngữ cảnh.

Quan hệ nhiều-nhiều tự tham chiếu 

Quan hệ nhiều-nhiều tự tham chiếu xảy ra khi cả hai khóa ngoại đều tham chiếu cùng một bảng. 

Ví dụ, nếu chúng ta theo dõi một ứng dụng mạng xã hội bao gồm theo dõi người dùng, người theo dõi của họ và những ai họ đang theo dõi, chúng ta có thể có quan hệ user_id tới follower_id theo cả hai hướng. Có thể cần thêm ràng buộc để ngăn trùng lặp bất hợp lệ hoặc đối xứng.

Quan hệ nhiều-nhiều đa hình 

Quan hệ nhiều-nhiều đa hình cho phép một bảng nối kết nối nhiều kiểu thực thể bằng bộ phân biệt loại. Điều này mang lại tính linh hoạt nhưng chuyển việc đảm bảo toàn vẹn sang logic ứng dụng và làm phức tạp truy vấn. 

Chẳng hạn, một bảng nối tên Tag cho ứng dụng mạng xã hội có thể liên hệ Posts, Comments và Users với một cột ngữ cảnh bổ sung để gán thẻ với thực thể phù hợp.

Quan hệ theo thời gian và có trọng số

Cả quan hệ theo thời gian và có trọng số đều lưu thông tin về quan hệ trong các thuộc tính bổ sung.

Quan hệ nhiều-nhiều theo thời gian thêm các cột cung cấp thông tin thời gian, như active_from, active_to hoặc created_on, để theo dõi tính hiệu lực lịch sử. Khóa enrolled_on trong cơ sở dữ liệu sinh viên–khóa học ở trên là một ví dụ về quan hệ theo thời gian.

Chúng rất cần thiết cho dấu vết kiểm toán, quan hệ thay đổi chậm và phân tích tại thời điểm. Điều này thêm chút phức tạp khi người dùng phải cẩn thận lọc theo thang thời gian phù hợp và cân nhắc các hàng có thể không còn hiệu lực.

Quan hệ có trọng số, ngược lại, lưu xếp hạng hoặc chỉ số độ mạnh. Các công cụ gợi ý, hệ thống gắn thẻ và chấm điểm mức độ liên quan thường dựa vào mẫu này để theo dõi những thứ như độ tin cậy gợi ý.

Quan hệ nhiều chiều

Trong khi hầu hết hệ thống OLTP tránh các quan hệ liên quan hơn hai thực thể, thì hệ thống phân tích lại thường sử dụng. Bảng fact trong mô hình chiều đóng vai trò như bảng nối kết nối các bảng ở mức độ chi tiết khác nhau. Những thiết kế này mạnh mẽ nhưng đòi hỏi truy vấn kỷ luật và tài liệu rõ ràng. 

Một thiết kế khả dĩ là tạo bảng nối có khóa ngoại tới tất cả các thực thể tham gia. 

Ví dụ, nếu mở rộng từ sinh viên và khóa học, một bảng thứ ba có thể là số phòng học. Một bảng nối có thể chứa các khóa ngoại cho một sinh viên trong một lớp cụ thể ở một phòng cụ thể. Dễ thấy rằng khi số lượng quan hệ tăng, việc truy vấn và lược đồ trở nên phức tạp theo cấp số nhân.

Để tìm hiểu sâu hơn về xây dựng cơ sở dữ liệu, hãy tham gia khóa học về thiết kế cơ sở dữ liệu của chúng tôi.

Tối ưu hiệu năng và Hiệu quả truy vấn

Với bất kỳ thiết kế cơ sở dữ liệu phức tạp nào, chúng ta phải xem xét hiệu năng và truy vấn. Càng thêm nhiều thành phần, càng dễ gặp nút thắt cổ chai hiệu năng!

Mẫu truy vấn và tối ưu hóa

Hãy xem trước vài cách chúng ta có thể truy vấn bảng nối. Các mẫu truy cập phổ biến gồm:

• Lấy tất cả thực thể liên quan từ Bảng B cho một thực thể ở Bảng A
• Đếm số lượng quan hệ
• Lọc theo thuộc tính của quan hệ

Để tối ưu các truy vấn này:

• Đánh chỉ mục các khóa ngoại trong bảng nối

• Dùng GROUP BY hoặc DISTINCT để tránh đếm trùng

• Cân nhắc chỉ mục bao phủ cho khối lượng đọc lớn

• Cụ thể hóa các mệnh đề WHERE để giới hạn lượng dữ liệu được nối.

Những kỹ thuật này là nền tảng cho các phép nối và tổng hợp hiệu quả. Nhớ rằng, nếu bạn đang dùng bảng nối để bắc cầu hai bảng, hãy nghĩ cách nối ba bảng một cách hiệu quả.

Tác vụ hàng loạt và đồng thời

Bảng nối thường có khối lượng ghi cao. Chèn và cập nhật theo lô giúp giảm chi phí giao dịch. 

Tuy nhiên, tranh chấp cao trên các khóa ngoại phổ biến có thể tạo nút thắt khóa. Hãy theo dõi hiệu năng và phân vùng bảng để cho phép xử lý song song.

Chuẩn hóa so với phi chuẩn hóa

Hãy dành chút thời gian xem sự khác biệt then chốt giữa chuẩn hóa và phi chuẩn hóa như một cách tiếp cận thiết kế cơ sở dữ liệu:

• Thiết kế chuẩn hóa phù hợp với hệ thống ghi nhiều, yêu cầu tính nhất quán nghiêm ngặt (ví dụ tài chính, ERP). Nếu cần tính nhất quán chặt chẽ, không có khả năng trùng lặp hay dữ liệu thừa, hãy tập trung vào thiết kế chuẩn hóa nghiêm.
• Thiết kế phi chuẩn hóa phù hợp với phân tích đọc nhiều nơi chấp nhận tính nhất quán cuối cùng. Nếu khả năng truy cập dữ liệu quan trọng hơn và chấp nhận dữ liệu “ổn định” sau đó, thì có thể dùng thiết kế phi chuẩn hóa, miễn là có hướng dẫn thực hành chặt chẽ.

Hãy thật sự cân nhắc mẫu truy cập, chuyên môn của đội ngũ và ràng buộc vận hành.

Đánh đổi của phi chuẩn hóa

Phi chuẩn hóa có thể cải thiện hiệu năng trên các hệ thống ghi nhiều nhưng không thay đổi thường xuyên. Cái giá phải trả là độ phức tạp tăng, gánh nặng bảo trì lớn hơn, và rủi ro dữ liệu lỗi thời. 

Ý kiến cá nhân: Phi chuẩn hóa chỉ nên là phản ứng có cân nhắc đối với nút thắt đọc-nhiều và luôn phải đi kèm kiểm tra tính nhất quán thường xuyên.

Triển khai trên các Hệ quản trị CSDL

Các hệ thống SQL và NoSQL có cách tiếp cận hơi khác nhau khi triển khai quan hệ nhiều-nhiều. 

Kiến trúc quan hệ và NoSQL

Cơ sở dữ liệu quan hệ như PostgreSQL, MySQL và SQL Server triển khai quan hệ nhiều-nhiều một cách tường minh bằng bảng nối với khóa ngoại và khóa chính tổng hợp. Tương tự, các CSDL quan hệ trên đám mây như Snowflake cũng theo mẫu thiết kế này.

Hệ thống NoSQL thường biểu diễn quan hệ nhiều-nhiều bằng cách nhúng mảng các ID liên quan hoặc lưu trữ tham chiếu do logic ứng dụng quản lý. Điều này là do ưu tiên hiệu năng đọc và khả năng mở rộng ngang trong CSDL NoSQL. Cách này cải thiện hiệu năng đọc và linh hoạt lược đồ nhưng đánh đổi với việc hy sinh chuẩn hóa.

SQL so với NoSQL

Cơ sở dữ liệu quan hệ được ưu tiên khi bạn cần một cấu trúc lược đồ được xác định rõ. Những cơ sở dữ liệu này dễ thao tác và cho phép quản lý dữ liệu tốt hơn. Hãy cân nhắc tập trung dùng CSDL quan hệ SQL khi:

• Quan hệ thay đổi thường xuyên
• Tính toàn vẹn là yếu tố sống còn của doanh nghiệp
• Truy vấn liên quan tới join phức tạp

CSDL NoSQL phù hợp với các tình huống ưu tiên tính linh hoạt và khả năng thao tác hàng loạt. Ví dụ, CSDL NoSQL như MongoDB cho phép dùng các toán tử như updateMany khi cần cập nhật trên rất nhiều tài liệu. Dưới đây là vài nguyên tắc định hướng khi bạn nên cân nhắc triển khai NoSQL:

• Lực lượng (cardinality) có thể dự đoán
• Lượt đọc vượt xa lượt ghi
• Tính linh hoạt lược đồ quan trọng hơn tính nhất quán nghiêm ngặt

Kết luận

Quan hệ nhiều-nhiều là điều không tránh khỏi trong các mô hình dữ liệu thực tế. Thiết kế đúng là tối quan trọng cho toàn vẹn dữ liệu, khả năng mở rộng và độ chính xác phân tích. Khi được chuẩn hóa và đánh chỉ mục đúng cách, bảng nối cung cấp nền tảng vững chắc, mở rộng từ hệ thống giao dịch đến phân tích cấp doanh nghiệp.

Mọi thiết kế đều liên quan đến đánh đổi: chuẩn hóa so với hiệu năng, đơn giản so với linh hoạt, và trừu tượng so với kiểm soát. Điều cốt lõi là lập hồ sơ mẫu truy cập của bạn, chọn mẫu phù hợp với khối lượng công việc, và xác thực thiết kế qua rà soát lược đồ cùng thử nghiệm truy vấn.

Với những người thực hành muốn nâng cao kỹ năng thiết kế cơ sở dữ liệu, tôi rất khuyến nghị đăng ký lộ trình nghề nghiệp Associate Data Analyst in SQL của chúng tôi.