Mối quan hệ một-nhiều trong cơ sở dữ liệu là gì? Giải thích với các ví dụ

Mối quan hệ một-nhiều là một trong những mối quan hệ cơ sở dữ liệu phổ biến nhất. Nếu bạn muốn tìm hiểu khi nào và cách sử dụng mối quan hệ một-nhiều, thì bài viết này là một điểm khởi đầu tuyệt vời.

Bạn chắc chắn sẽ sử dụng các mối quan hệ một-nhiều để lưu trữ thông tin trong bất kỳ cơ sở dữ liệu quan hệ nào, cho dù bạn đang thiết kế phần mềm cấp doanh nghiệp hay chỉ tạo một cơ sở dữ liệu đơn giản để theo dõi bộ sưu tập tem của chú bạn.

Giới thiệu ngắn gọn về Mô hình quan hệ

Cơ sở dữ liệu quan hệ là thành phần cốt lõi của bất kỳ ứng dụng giao dịch hiện đại nào. Mô hình quan hệ bao gồm các bảng (dữ liệu được tổ chức theo hàng và cột) có ít nhất một khóa duy nhất xác định mỗi hàng. Mỗi bảng đại diện cho một thực thể. Điều này được thể hiện trong ví dụ sau, một phiên bản rất đơn giản của bảng biểu thị đơn đặt hàng của khách hàng:

Sơ đồ trên, mà tôi đã tạo trực tuyến bằng Vertabelo, có một bảng duy nhất. Mỗi hàng trong bảng đại diện cho một đơn đặt hàng và mỗi cột (còn được gọi là thuộc tính ) đại diện cho từng phần thông tin riêng lẻ có trong một đơn đặt hàng.

Đối với những người chưa quen thuộc với công cụ thiết kế Vertabelo, bài viết Các ký hiệu được sử dụng trong sơ đồ ER là gì? giải thích các ký hiệu và quy ước được sử dụng. Bạn cũng có thể muốn tìm hiểu thêm về các mô hình quan hệ và cơ sở dữ liệu bằng cách sử dụng khóa học lập mô hình cơ sở dữ liệu của chúng tôi.

Mối quan hệ là gì và tại sao chúng ta cần chúng?

Nếu chúng ta xem xét sâu hơn bảng được sử dụng trong ví dụ trước, chúng ta sẽ thấy rằng nó không thực sự đại diện cho một thứ tự hoàn chỉnh. Nó không có tất cả thông tin mà bạn mong đợi nó có. Bạn sẽ nhận thấy rằng nó không bao gồm bất kỳ dữ liệu nào liên quan đến khách hàng đã đặt hàng, cũng như không có bất kỳ thông tin nào về các sản phẩm hoặc dịch vụ đã đặt hàng.

Chúng ta phải làm gì để hoàn thành thiết kế này để lưu trữ dữ liệu đơn hàng? Chúng tôi có nên thêm thông tin sản phẩm và khách hàng vào Đơn đặt hàng không bàn? Điều đó sẽ yêu cầu thêm các cột (thuộc tính) mới cho tên khách hàng, mã định danh thuế, địa chỉ, v.v. như được hiển thị bên dưới:

Nếu chúng tôi làm điều đó, chúng tôi sẽ sớm gặp phải vấn đề. Hầu hết khách hàng đặt nhiều hơn một đơn hàng nên hệ thống này sẽ lưu trữ thông tin khách hàng nhiều lần, một lần cho mỗi đơn hàng của mỗi khách hàng. Đó có vẻ không phải là một bước đi thông minh.

Hơn nữa, điều gì sẽ xảy ra khi khách hàng thay đổi số điện thoại của họ? Nếu ai đó cần gọi cho khách hàng, họ có thể tìm thấy số cũ trong các đơn đặt hàng trước đó - trừ khi ai đó cập nhật hàng trăm (hoặc thậm chí hàng nghìn) đơn đặt hàng hiện có bằng thông tin mới. Và điều tương tự cũng xảy ra đối với bất kỳ thay đổi nào khác.

Một mô hình quan hệ yêu cầu chúng ta xác định mỗi thực thể như một bảng riêng biệt và thiết lập mối quan hệ giữa chúng. Lưu trữ tất cả thông tin trong một bảng duy nhất không hoạt động.

Có một số kiểu quan hệ giữa các bảng, nhưng có lẽ phổ biến nhất là mối quan hệ một-nhiều, thường được viết là 1:N. Loại quan hệ này có nghĩa là một hàng trong bảng (thường được gọi là bảng mẹ) có thể có mối quan hệ với nhiều hàng trong bảng khác (thường được gọi là bảng con). Một số ví dụ phổ biến về mối quan hệ một-nhiều là:

• Một nhà sản xuất ô tô tạo ra nhiều mẫu xe khác nhau, nhưng một mẫu ô tô cụ thể chỉ được chế tạo bởi một nhà sản xuất ô tô duy nhất.
• Một khách hàng có thể thực hiện nhiều giao dịch mua, nhưng mỗi giao dịch mua được thực hiện bởi một khách hàng duy nhất.
• Một công ty có thể có nhiều số điện thoại, nhưng một số điện thoại thuộc về một công ty.

Ngoài ra còn có các kiểu quan hệ khác giữa các bảng; nếu bạn muốn tìm hiểu thêm về chúng, hãy xem bài viết này về mối quan hệ nhiều-nhiều.

Quay lại ví dụ về đơn đặt hàng ban đầu của chúng tôi, Customer bảng sẽ là bảng mẹ và Order bàn con; một khách hàng có thể có nhiều đơn đặt hàng, trong khi một đơn đặt hàng có thể thuộc về một khách hàng.

Xin lưu ý rằng định nghĩa một-nhiều cho phép một hàng trong bảng mẹ được liên kết với nhiều hàng trên mỗi bảng con, nhưng nó không yêu cầu. Trên thực tế, thiết kế cho phép khách hàng không có đơn đặt hàng nào (tức là khách hàng mới chưa thực hiện lần mua hàng đầu tiên), một đơn hàng (khách hàng tương đối mới đã mua một lần) hoặc nhiều đơn hàng (khách hàng thường xuyên).

Hiển thị các mối quan hệ một-nhiều trong một sơ đồ ER

Hãy cùng xem một ví dụ đầy đủ hơn về hệ thống đặt hàng của khách hàng đơn giản bằng cách sử dụng sơ đồ ER (hoặc mối quan hệ thực thể). (Nếu bạn muốn tìm hiểu thêm về các sơ đồ này, Các tính năng của Vertabelo:Sơ đồ lôgic là một điểm khởi đầu tuyệt vời.) Đây là mô hình:

Đây là một thiết kế thực tế hơn. Bạn sẽ nhận thấy rằng có các thực thể (bảng) mới trong sơ đồ, hiện có chứa các bảng Customer , Order , Order Detail và Product . Tuy nhiên, điều quan trọng nhất bạn nhận thấy là bây giờ có mối quan hệ giữa các bảng .

Trong một mô hình cơ sở dữ liệu, các mối quan hệ được biểu diễn bằng các đường nối hai thực thể. Đặc điểm của những mối quan hệ này được thể hiện bằng các trình kết nối khác nhau:

• Khi có một đường thẳng đứng, thực thể gần trình kết nối đó chỉ có một hàng bị ảnh hưởng bởi mối quan hệ. Đó là "một" trong một-nhiều.
• Khi có một trình kết nối nhiều dòng trông giống như vết chân chim, đối tượng gần nhất trình kết nối đó có nhiều hàng bị ảnh hưởng bởi mối quan hệ; đó là "nhiều".

Nhìn vào hình ảnh và biết ký hiệu, có thể hiểu đơn giản rằng sơ đồ xác định rằng mỗi Order có thể có nhiều Order Detail và mỗi Order Detail thuộc về một Order .

Thực hiện mối quan hệ một-nhiều giữa các bảng

Để xác định mối quan hệ một-nhiều giữa hai bảng, bảng con phải tham chiếu đến một hàng trên bảng mẹ. Các bước cần thiết để xác định nó là:

1. Thêm một cột vào bảng con sẽ lưu trữ giá trị của số nhận dạng chính. (Trên thực tế, hầu hết các công cụ cơ sở dữ liệu cho phép nó là bất kỳ khóa duy nhất nào từ bảng mẹ, không chỉ là khóa chính.) Cột này có thể được định nghĩa là bắt buộc tùy thuộc vào nhu cầu kinh doanh của bạn; mặc dù vậy, các cột khóa ngoại thường được tạo

Lưu ý: Một thực tiễn tốt là giữ cho tên của các cột tham chiếu giống như trong bảng (cha) được tham chiếu. Điều này làm cho việc hiểu mối quan hệ trở nên đơn giản hơn.

2. Thêm khóa ngoại ràng buộc trên bảng con. Điều này cho biết rằng mỗi giá trị được lưu trữ trong cột mới này tham chiếu đến một hàng trên bảng mẹ.

Ràng buộc khóa ngoại là một tính năng có sẵn trên cơ sở dữ liệu quan hệ thực thi điều đó:

1. Khi bạn thêm một hàng vào bảng con, giá trị của cột tham chiếu phải khớp với một (và chỉ một) giá trị trong bảng mẹ. (Đó là lý do tại sao một cột hoặc tập hợp các cột tạo nên khóa chính hoặc khóa duy nhất phải được tham chiếu).
2. Nếu ai đó cố gắng xóa một hàng khỏi bảng chính hoặc cố gắng sửa đổi các giá trị của khóa duy nhất / chính được sử dụng làm tham chiếu và có một bảng con tham chiếu đến hàng đó, thao tác sẽ không thành công.

Hai tính năng này đảm bảo rằng cơ sở dữ liệu giữ được tính toàn vẹn của nó. Không có cơ hội tạo đơn đặt hàng liên quan đến khách hàng không tồn tại, cũng như xóa khách hàng đã có đơn đặt hàng.

Tạo khóa ngoại

Cú pháp khóa ngoại thường phụ thuộc vào công cụ cơ sở dữ liệu đích. Khi bạn đã xác định mô hình lôgic của mình, bạn có thể sử dụng tính năng “Tạo mô hình vật lý…” trên sơ đồ lôgic Vertabelo để chuyển mô hình (bất khả tri cơ sở dữ liệu) thành mô hình vật lý phù hợp với nhà cung cấp cơ sở dữ liệu của bạn. Vertabelo cũng sẽ tạo tập lệnh SQL được yêu cầu cho phép bạn tạo các bảng và mối quan hệ trong cơ sở dữ liệu mục tiêu của mình.

Một số ví dụ thực tế về mối quan hệ 1:N

Bây giờ, hãy xem lại một số ví dụ về mối quan hệ một-nhiều trong thế giới thực.

Mối quan hệ một-nhiều sử dụng các khóa chính

Đây có lẽ là tình huống phổ biến nhất khi xác định mối quan hệ một-nhiều. Bảng con sử dụng giá trị khóa chính của bảng mẹ để thiết lập mối quan hệ.

Ví dụ này mô tả một dịch vụ phát trực tuyến cơ bản. Hãy xem lại những gì được lưu trữ trong mỗi bảng và chúng liên quan như thế nào với các bảng khác trong mô hình của chúng tôi:

1. Mỗi ServiceType xác định cách tài khoản 'hoạt động' (ví dụ:số lượng người dùng có thể kết nối với hệ thống cùng một lúc, nếu tài khoản đã bật Full HD, v.v.). Nó có một mối quan hệ với các thực thể khác:
   • Mối quan hệ một-nhiều với Account , nghĩa là mỗi loại dịch vụ có thể có nhiều tài khoản thuộc loại đó.
2. Mỗi Account lưu trữ thông tin về một khách hàng. Nó có hai mối quan hệ trực tiếp với các thực thể khác:
   • Mỗi tài khoản thuộc về một ServiceType , như đã giải thích ở trên.
   • Bảng này có mối quan hệ một-nhiều với Profile , nghĩa là nhiều người dùng có thể kết nối với hệ thống của chúng tôi bằng cùng một tài khoản.
3. Từng Profile đại diện cho một người dùng trong hệ thống của chúng tôi. Nó có hai mối quan hệ với các thực thể khác:
   • Mỗi cấu hình thuộc về một Account . Điều này cho phép tất cả các thành viên trong gia đình (hoặc có thể là một nhóm bạn) chia sẻ cùng một tài khoản trong khi mỗi người đều có các thuộc tính cá nhân riêng của họ (ví dụ:tên hồ sơ).
   • Mỗi cấu hình có một Avatar duy nhất .
4. Mỗi Avatar là hình ảnh cho phép chúng tôi nhanh chóng xác định từng người dùng tài khoản. Nó có một mối quan hệ với một thực thể khác:
   • Mối quan hệ một-nhiều với Profile , nghĩa là có thể chỉ định một hình đại diện cho các hồ sơ trên các tài khoản khác nhau.

Mối quan hệ một-nhiều với các khóa duy nhất tự nhiên hoặc thay thế

Việc sử dụng các khóa chính thay thế là một cách lập bảng mô hình được chấp nhận rộng rãi. (Các khóa chính thay thế được tạo bởi cơ sở dữ liệu và không có giá trị kinh doanh thực tế.) Phương pháp này tạo ra các khóa dễ sử dụng hơn và thêm một số tính linh hoạt khi cần thay đổi.

Tuy nhiên, có những tình huống - ví dụ:khi chúng ta cần tương tác với các hệ thống bên ngoài - nơi sử dụng khóa được tạo trong cơ sở dữ liệu của chúng ta là một cách tiếp cận không tốt. Đối với những trường hợp đó, thường tốt hơn là sử dụng các khóa tự nhiên, là các giá trị duy nhất là một phần của thực thể đang được lưu trữ và không được cơ sở dữ liệu của chúng tôi tạo tự động.

Ví dụ sau đại diện cho mô hình dữ liệu cơ bản của một tổ chức theo dõi các loại xe (tức là loại xe, kiểu dáng, màu sắc và năm), chủ sở hữu của chúng và mọi vi phạm giao thông liên quan. Khi chúng tôi xác định nó, chúng tôi đã sử dụng khóa chính thay thế để thiết lập mối quan hệ giữa phương tiện và sản xuất, kiểu xe và chủ sở hữu, vì tất cả thông tin này được hệ thống của chúng tôi xử lý nội bộ.

Trong hệ thống này, làm cách nào để cảnh sát viên ở một thành phố khác có thể báo cáo một chiếc ô tô đang đậu trái phép bằng cách sử dụng khóa chính của xe của chúng tôi (VehicleID )? Thông tin như vậy không tự nhiên có trên xe đang đậu, nhưng biển số xe thì có. Điều đó có nghĩa là cách đơn giản nhất để nhận và liên kết thông tin từ một nguồn bên ngoài (trong ví dụ này là bất kỳ sở cảnh sát nào trong nước) là sử dụng khóa duy nhất tự nhiên thay vì khóa chính thay thế.

Việc triển khai vật lý của sơ đồ logic này cho SQL Server có sẵn tại đây:

Mối quan hệ một-nhiều trên cùng một bảng

Các ví dụ trước tập trung vào mối quan hệ giữa hai hoặc nhiều bảng, nhưng cũng có những trường hợp trong đó mối quan hệ xảy ra giữa các hàng của cùng một bảng. Loại quan hệ một-nhiều này còn được gọi là quan hệ thứ bậc; nó được sử dụng trong nhiều hệ thống để biểu thị cấu trúc dạng cây, tức là sơ đồ tổ chức, tài khoản sổ cái chung hoặc sản phẩm và các bộ phận cấu thành của nó.

Lần đầu tiên bạn cần tạo loại cấu trúc này, bạn sẽ bị cám dỗ để xác định một bảng cho từng cấp trong hệ thống phân cấp của mình, như thể hiện trong sơ đồ sau:

Có nhiều vấn đề đối với cách tiếp cận này:

• Tất cả các bảng gần như giống hệt nhau và lưu trữ thông tin giống hệt nhau.
• Nếu tổ chức của bạn thêm một cấp độ mới, bạn sẽ phải sửa đổi mô hình dữ liệu và thêm một bảng mới, khóa ngoại mới, v.v.
• Nếu nhân viên được thăng chức, bạn cần xóa họ khỏi bảng này và chèn họ vào bảng khác.

Do đó, cách tốt nhất để mô hình hóa loại cấu trúc này là sử dụng một bảng duy nhất tham chiếu chính nó, như thể hiện trong sơ đồ sau:

Ở đây, chúng tôi thấy một Employee bảng và một cột có tên EmployeeID_Manager . Cột đó tham chiếu đến một nhân viên khác trong cùng một tổ chức là người giám sát / quản lý của nhân viên hiện tại.

Tôi đã thêm _Manager hậu tố để phân biệt giữa ID của hàng hiện tại và ID của người quản lý. (Chúng tôi có thể sử dụng ManagerID thay vào đó, nhưng tôi muốn giữ lại tên ban đầu của cột được tham chiếu và, trong những trường hợp cả hai đều nằm trong cùng một bảng, hãy thêm một hậu tố giải thích vai trò thực sự của nó).

Việc hiểu các mối quan hệ thứ bậc phức tạp hơn các mối quan hệ một-nhiều khác. Nhưng nếu bạn quên mất bảng nơi lưu trữ tất cả thông tin và tưởng tượng rằng thực sự có các bảng khác nhau, mỗi bảng đại diện cho một cấp trong hệ thống phân cấp, thì sẽ dễ hình dung hơn một chút. Hãy tưởng tượng rằng bạn tạo mối quan hệ giữa hai thực thể và sau đó kết hợp chúng thành một thực thể.

Tiếp theo là gì?

Các ví dụ được cung cấp sẽ giúp bạn xác định các tình huống khác nhau yêu cầu mối quan hệ một-nhiều. Bạn có thể bắt đầu thiết kế cấu trúc cơ sở dữ liệu của riêng mình bằng cách sử dụng Vertabelo Database Modeler, một công cụ dựa trên web cho phép bạn không chỉ tạo mô hình logic mà còn tạo phiên bản vật lý của nó cho nhà cung cấp cơ sở dữ liệu mà bạn cần.

Bây giờ đến lượt bạn - sử dụng phần nhận xét để cho chúng tôi biết suy nghĩ của bạn về bài viết này, hỏi thêm bất kỳ câu hỏi nào hoặc chia sẻ kinh nghiệm lập mô hình cơ sở dữ liệu của bạn.