Sự khác biệt giữa mối quan hệ một-nhiều và nhiều-một


117

Sự khác biệt thực sự giữa mối quan hệ một-nhiều và nhiều-một là gì? Nó chỉ được đảo ngược, loại?

Tôi không thể tìm thấy bất kỳ hướng dẫn 'hay và dễ hiểu' nào về chủ đề này ngoài chủ đề này: SQL cho người mới bắt đầu: Phần 3 - Mối quan hệ cơ sở dữ liệu


1
Đây là lời giải thích hoàn hảo: en.wikipedia.org/wiki/Many-to-many_(data_model)
RobertPitt

@RobertPitt có liên quan đến bài viết nhiều đến nhiều với câu hỏi như thế nào? Có thể bạn muốn nói đến en.wikipedia.org/wiki/One-to-many_(data_model)
TMG

Câu trả lời:


111

Có, nó ngược lại. Nó phụ thuộc vào mặt nào của mối quan hệ mà thực thể hiện diện.

Ví dụ: nếu một bộ phận có thể tuyển dụng nhiều nhân viên thì giữa bộ phận với nhân viên là mối quan hệ một với nhiều (1 bộ phận sử dụng nhiều nhân viên), trong khi mối quan hệ giữa nhân viên với bộ phận là nhiều với một (nhiều nhân viên làm việc trong một bộ phận).

Thông tin thêm về các loại mối quan hệ:

Mối quan hệ cơ sở dữ liệu - Tài liệu DB2 của IBM


2
Tôi sợ rằng không làm được cảnh! ( KHÔNG CHẮC CHẮN NHƯNG ) tôi nghĩ thứ tự thể hiện sự phụ thuộc! Phải không ?? EG, Một người dùng với vai trò có thể là 1 đến nhiều nhưng không nhiều với một vì người dùng không thể nhận được tham chiếu của người dùng sử dụng vai trò! Điều đó có ý nghĩa?
Amanuel Nega

Có thể các mối quan hệ cơ sở dữ liệu bây giờ?
fragorl

29

Từ trang này về Thuật ngữ cơ sở dữ liệu

Hầu hết các quan hệ giữa các bảng là một-nhiều.

Thí dụ:

  • Một khu vực có thể là nơi sinh sống của nhiều độc giả.
  • Một người đọc có thể có nhiều đăng ký.
  • Một tờ báo có thể có nhiều đăng ký.

Mối quan hệ Nhiều với Một cũng giống như một-nhiều, nhưng theo một quan điểm khác.

  • Nhiều độc giả sống trong một khu vực.
  • Nhiều đăng ký có thể của một và cùng một người đọc.
  • Nhiều đăng ký dành cho một và cùng một tờ báo.

20

Sự khác biệt thực sự giữa mối quan hệ một-nhiều và nhiều-một là gì?

Có sự khác biệt về khái niệm giữa các thuật ngữ này sẽ giúp bạn hình dung dữ liệu và những khác biệt có thể có trong lược đồ đã tạo cần được hiểu đầy đủ. Phần lớn sự khác biệt là một trong những góc nhìn.

Trong mối quan hệ một-nhiều , bảng cục bộ có một hàng có thể được liên kết với nhiều hàng trong bảng khác. Trong ví dụ từ SQL cho người mới bắt đầu , một cái Customercó thể được liên kết với nhiều Orders.

Trong mối quan hệ nhiều-một ngược lại , bảng cục bộ có thể có nhiều hàng được liên kết với một hàng trong bảng khác. Trong ví dụ của chúng tôi, nhiều Orders có thể được liên kết với một Customer. Sự khác biệt về khái niệm này rất quan trọng đối với sự thể hiện tinh thần.

Ngoài ra, lược đồ hỗ trợ mối quan hệ có thể được biểu diễn khác nhau trong các bảng CustomerOrder. Ví dụ: nếu khách hàng có các cột idname:

id,name
1,Bill Smith
2,Jim Kenshaw

Sau đó, để a Orderđược liên kết với a Customer, nhiều triển khai SQL thêm vào Orderbảng một cột lưu trữ idcủa liên kết Customer(trong lược đồ này customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

Trong các hàng dữ liệu trên, nếu chúng ta nhìn vào customer_idcột id, chúng ta thấy rằng Bill Smith(id khách hàng # 1) có 2 đơn đặt hàng được liên kết với anh ta: một đơn hàng với giá 12,34 đô la và một đơn hàng có giá 7,58 đô la. Jim Kenshaw(customer-id # 2) chỉ có 1 đơn đặt hàng với giá $ 158,01.

Điều quan trọng cần nhận ra là thông thường mối quan hệ một-nhiều không thực sự thêm bất kỳ cột nào vào bảng là "một". Không Customercó cột bổ sung mô tả mối quan hệ với Order. Trên thực tế, hàm Customercũng có thể có mối quan hệ một-nhiều với ShippingAddressSalesCallcác bảng nhưng không có cột bổ sung nào được thêm vào Customerbảng.

Tuy nhiên, để mô tả mối quan hệ nhiều-một, thường một idcột được thêm vào bảng "nhiều" là khóa ngoại của bảng "một" - trong trường hợp này, một customer_idcột được thêm vào Order. Đối với đơn đặt hàng số 10 được liên kết với $ 12,34 Bill Smith, chúng tôi chỉ định customer_idcột cho Bill Smithid 1 của.

Tuy nhiên, cũng có thể có một bảng khác mô tả mối quan hệ CustomerOrderđể không cần thêm trường bổ sung vào Orderbảng. Thay vì thêm một customer_idtrường vào Orderbảng, có thể có một Customer_Orderbảng chứa các khóa cho cả CustomerOrder.

customer_id,order_id
1,10
1,11
2,12

Trong trường hợp này, một-nhiềunhiều-một đều là khái niệm vì không có thay đổi lược đồ nào giữa chúng. Cơ chế nào phụ thuộc vào lược đồ và triển khai SQL của bạn.

Hi vọng điêu nay co ich.


3
Trường hợp chung được gọi là phụ thuộc bao hàm. Ràng buộc khóa ngoại là loại phụ thuộc bao hàm phổ biến nhất nhưng không phải tất cả các ràng buộc bao hàm đều liên quan đến khóa ngoại. Thuộc tính chung hoặc các thuộc tính ("tham chiếu") luôn tồn tại trong cả hai bảng. Ở phía "một" các thuộc tính đó được gọi là khóa ứng viên. Về phía "nhiều", chúng có thể là một khóa ngoại. Các thuật ngữ "một-nhiều" hoặc "nhiều-một" có thể được áp dụng cho bất kỳ phụ thuộc bao gồm nào liên quan đến ít nhất một khóa ứng viên mà không nhất thiết ngụ ý bên nào có thể là tùy chọn.
nvogel

@Sqlvogel thú vị. Trong Java javax.persistence.OneToManykhác với ManyToOne. Bạn đang nói rằng chúng đồng nghĩa hay chỉ điều đó phụ thuộc vào việc triển khai? Câu trả lời của tôi có sai không?
Grey

2
Câu hỏi là về cơ sở dữ liệu quan hệ và SQL, không phải Java. Có thể bạn nói đúng về Java.
nvogel

Tôi đang sử dụng nó làm ví dụ @sqlvogel. Bạn đang nói rằng "một-nhiều" và "nhiều-một" có đồng nghĩa với nhau không?
Grey

2
Tôi đang nói rằng đó là hai cách mô tả chính xác cùng một mối quan hệ nhưng từ các khía cạnh khác nhau. Tương tự như "A là tập con của B" có nghĩa giống như "B là tập hợp con của A".
nvogel

4

Không có sự khác biệt. Nó chỉ là vấn đề ngôn ngữ và sở thích về cách bạn thể hiện mối quan hệ.


1
Chắc chắn có một sự khác biệt, cả về khái niệm cũng như lược đồ được tạo. Xem câu trả lời của tôi: stackoverflow.com/a/37954280/179850
Grey

4
@ Gray. Không có. Câu trả lời của bạn không chỉ không chính xác mà còn gây nhầm lẫn cho những người mới bắt đầu (những người đặt câu hỏi này).
PerformanceDBA

4

Câu trả lời cho câu hỏi đầu tiên của bạn là: cả hai đều giống nhau,

Câu trả lời cho câu hỏi thứ hai của bạn là: one-to-many -> một MAN (bảng MAN) có thể có nhiều vợ (bảng WOMEN) nhiều với một -> nhiều phụ nữ đã kết hôn với một MAN.

Bây giờ nếu bạn muốn liên kết mối quan hệ này với hai bảng MAN và WOMEN, một hàng của bảng MAN có thể có nhiều quan hệ với các hàng trong bảng WOMEN. hy vọng nó rõ ràng.


3

Thí dụ

Hai bảng với một mối quan hệ

SQL

Trong SQL, chỉ có một loại quan hệ, nó được gọi là Tham chiếu. (Giao diện người dùng của bạn có thể làm những điều hữu ích hoặc khó hiểu [chẳng hạn như trong một số Câu trả lời], nhưng đó là một câu chuyện khác.)

  • Một chính nước ngoài trong một bảng ( referenc ing bảng)
    Tài liệu tham khảo
    một Primary Key trong bảng khác ( referenc ed bảng)
  • Trong thuật ngữ SQL, Bar tham chiếu Foo
    Không phải ngược lại

    CREATE TABLE Foo (
        Foo   CHAR(10)  NOT NULL, -- primary key
        Name  CHAR(30)  NOT NULL
        CONSTRAINT PK             -- constraint name
            PRIMARY KEY (Foo)     -- pk
        )  
    CREATE TABLE Bar (
        Bar   CHAR(10)  NOT NULL, -- primary key
        Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
        Name  CHAR(30)  NOT NULL
        CONSTRAINT PK                -- constraint name
            PRIMARY KEY (Bar),       -- pk
        CONSTRAINT Foo_HasMany_Bars  -- constraint name
            FOREIGN KEY   (Foo)      -- fk in (this) referencing table
            REFERENCES Foo(Foo)      -- pk in referenced table
        )
  • Foo.Foolà Khóa chính nên nó là duy nhất, chỉ có một hàng cho bất kỳ giá trị nhất định nào củaFoo

  • Bar.Foolà Tham chiếu, Khóa ngoại và không có chỉ mục duy nhất trên đó, nên có thể có nhiều hàng cho bất kỳ giá trị nhất định nào củaFoo
  • Do đó, mối quan hệ Foo::Barlà một-nhiều
  • Bây giờ bạn có thể nhận thức (nhìn vào) mối quan hệ theo cách khác, Bar::Foolà nhiều-một
    • Nhưng đừng để điều đó làm bạn bối rối: đối với bất kỳ Barhàng nào, chỉ có một Foohàng mà nó Tham chiếu
  • Trong SQL, đó là tất cả những gì chúng ta có. Đó là tất cả những gì cần thiết.

Sự khác biệt thực sự giữa mối quan hệ một với nhiều và nhiều với một là gì?

Chỉ có một mối quan hệ, do đó không có sự khác biệt. Nhận thức (từ một "đầu" hoặc "đầu kia") hoặc đọc ngược lại, không thay đổi quan hệ.

Cardinality

Cardinality được khai báo đầu tiên trong mô hình dữ liệu, có nghĩa là Logic và Vật lý (ý định), sau đó là trong việc triển khai (ý định được hiện thực hóa).

Cardinality

Một đến không-nhiều
Trong SQL, (ở trên) là tất cả những gì được yêu cầu.

Một đến một nhiều
Bạn cần một Giao dịch để thực thi một giao dịch trong bảng Tham chiếu.

One to zero-to-one
Bạn cần Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Một đối một
Bạn cần một Giao dịch để thực thi một giao dịch trong bảng Tham chiếu.

Nhiều đến nhiều
Không có điều đó ở mức Vật lý (nhớ lại, chỉ có một kiểu quan hệ trong SQL).

Ở các cấp độ lôgic ban đầu trong quá trình thực hành mô hình hóa, việc vẽ một quan hệ như vậy sẽ rất thuận tiện . Trước khi mô hình gần được triển khai, tốt hơn hết bạn nên nâng cao thành chỉ sử dụng những thứ có thể tồn tại. Mối quan hệ như vậy được giải quyết bằng cách triển khai Bảng liên kết.

Nhiều đến nhiều đã được giải quyết


1
@Martijn Peters. Tôi có thể chỉnh sửa nó để tuân thủ quy tắc ứng xử. Nhưng bạn cũng đã loại bỏ (a) giải thích, và (b) các dữ kiện được chứng minh trong thực tế. Tôi phải làm gì với những thứ đó?
PerformanceDBA

3
Tìm một cách khác để thể hiện những điều đó mà không cần dùng đến cách nói xấu, gọi tên, và tạo ra sự hoang mang về trí tuệ hoặc hành vi nghề nghiệp của bất kỳ ai. Tập trung vào công nghệ, không phải vào những người có thể sai hoặc không sai.
Martijn Pieters

2

One-to-Many và Many-to-One tương tự về Đa dạng nhưng không giống nhau về Phương diện (tức là Tính định hướng).

Ánh xạ các liên kết giữa các lớp thực thể và Mối quan hệ giữa các bảng. Có hai loại Mối quan hệ:

  1. Tính đa dạng (thuật ngữ ER: cardinality)
    • Mối quan hệ một-một : Ví dụ Chồng và Vợ
    • Mối quan hệ một-nhiều : Ví dụ về Mẹ và Con
    • Mối quan hệ Nhiều-Nhiều : Ví dụ Sinh viên và Đối tượng
  2. Tính định hướng : Không ảnh hưởng đến việc lập bản đồ nhưng tạo ra sự khác biệt về cách chúng ta có thể truy cập dữ liệu.
    • Mối quan hệ đơn hướng : Một trường quan hệ hoặc thuộc tính đề cập đến thực thể khác.
    • Mối quan hệ hai chiều : Mỗi thực thể có một trường quan hệ hoặc thuộc tính tham chiếu đến thực thể kia.

Không có "định hướng" trong cơ sở dữ liệu quan hệ. Mỗi mối quan hệ có hai "kết thúc": Tham chiếu (bảng đang được tham chiếu) và Tham chiếu (bảng thực hiện tham chiếu). SQL / DML cho phép tham chiếu bất kỳ bảng nào, theo bất kỳ cách nào bạn muốn… một bên… bên kia… cả hai bên… không bên.
PerformanceDBA

0

Không có sự khác biệt thực tế. Chỉ cần sử dụng mối quan hệ có ý nghĩa nhất theo cách bạn nhìn nhận vấn đề của mình như Devendra đã minh họa.


Chắc chắn có một sự khác biệt, cả về khái niệm cũng như lược đồ được tạo. Xem câu trả lời của tôi: stackoverflow.com/a/37954280/179850
Grey

3
@ Gray. Không có. Câu trả lời của bạn không chỉ không chính xác mà còn gây nhầm lẫn cho những người mới bắt đầu (những người đặt câu hỏi này).
PerformanceDBA

0
  • --- Một đến Nhiều --- Một Cha mẹ có thể có hai con trở lên.
  • --- Nhiều đến một --- 3 đứa trẻ đó có thể có một Cha mẹ duy nhất.

    Cả hai đều tương tự nhau. Điều này có thể được sử dụng thuộc về nhu cầu. Nếu bạn muốn tìm con cho một cha mẹ cụ thể, thì bạn có thể chọn One-To-Many. hoặc nếu không, muốn tìm cha mẹ cho một cặp song sinh, bạn có thể đi với Nhiều người một. Tương tự ....,


-6

một-nhiều có lớp cha chứa n số lớp con nên nó là một ánh xạ tập hợp.

nhiều-một có n số phần tử con chứa một cha mẹ nên nó là một ánh xạ đối tượng


câu trả lời này là tốt và có thông tin bổ sung không hiểu tại sao nó bị bỏ phiếu, trong ngữ cảnh đơn hướng một đến nhiều và nhiều với một sẽ không cung cấp chất lượng mã giống nhau tùy thuộc vào UX: Nếu bạn cần lấy một bộ dữ liệu liên quan vì vậy một đến nhiều sẽ khôn ngoan hơn nếu bạn không cần câu lệnh select trong đó một số điều kiện ổn vì tập hợp đó có trong bản đồ, tuy nhiên, nếu người dùng không cần lấy tập dữ liệu và quan tâm đến mỗi hàng là một mong muốn dụ rất nhiều để một là sự lựa chọn khôn ngoan hơn
Mohammed Housseyn Taleb

Nó có thể là một câu trả lời hay, nhưng chúng không giống nhau: nhiều-một có lớp cha chứa n số con, một-nhiều có nhiều cha là một con. Trong SQL, nó có thể không tạo ra sự khác biệt vì mối quan hệ nhiều-một có thể là đa hướng nhưng trong một khuôn khổ như Django, đây là một vấn đề lớn, vì không có mối quan hệ một-nhiều và khóa ngoại giao dịch với mối quan hệ Nhiều-Một chỉ hoạt động tự nhiên theo một hướng, điều này không thể được sử dụng theo cách khác theo cùng một cách.
iFunction
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.