Vẫn còn nhầm lẫn về việc xác định các mối quan hệ so với không xác định


76

Vì vậy, tôi đã đọc về các mối quan hệ xác định so với không xác định trong thiết kế cơ sở dữ liệu của mình và một số câu trả lời trên SO có vẻ mâu thuẫn với tôi. Đây là hai câu hỏi tôi đang xem xét:

  1. Sự khác biệt giữa các mối quan hệ xác định và không xác định là gì
  2. Rắc rối khi quyết định về mối quan hệ xác định hoặc không xác định

Nhìn vào các câu trả lời hàng đầu từ mỗi câu hỏi, tôi dường như có hai ý tưởng khác nhau về mối quan hệ xác định là gì.

Câu trả lời của câu hỏi đầu tiên nói rằng mối quan hệ xác định "mô tả tình huống trong đó sự tồn tại của một hàng trong bảng con phụ thuộc vào một hàng trong bảng mẹ." Một ví dụ về điều này được đưa ra là, "Một tác giả có thể viết nhiều cuốn sách (mối quan hệ 1-n), nhưng một cuốn sách không thể tồn tại nếu không có tác giả." Điều đó có ý nghĩa đối với tôi.

Tuy nhiên, khi tôi đọc câu trả lời cho câu hỏi thứ hai, tôi cảm thấy bối rối khi nó nói, "nếu một đứa trẻ xác định cha mẹ của nó, nó là một mối quan hệ xác định." Câu trả lời sau đó tiếp tục đưa ra các ví dụ như Số an sinh xã hội (là nhận dạng của một người), nhưng địa chỉ thì không (vì nhiều người có thể sống tại một địa chỉ). Đối với tôi, điều này nghe giống trường hợp quyết định giữa khóa chính và không phải khóa chính hơn.

Cảm giác của riêng tôi (và nghiên cứu bổ sung trên các trang web khác) chỉ ra câu hỏi đầu tiên và câu trả lời của nó là đúng. Tuy nhiên, tôi muốn xác minh trước khi tiếp tục vì tôi không muốn học điều gì sai khi tôi đang làm việc để hiểu thiết kế cơ sở dữ liệu. Cảm ơn trước.

Câu trả lời:


154

Định nghĩa kỹ thuật của mối quan hệ xác định là khóa ngoại của trẻ là một phần của khóa chính của nó.

CREATE TABLE AuthoredBook (
  author_id INT NOT NULL,
  book_id INT NOT NULL,
  PRIMARY KEY (author_id, book_id),
  FOREIGN KEY (author_id) REFERENCES Authors(author_id),
  FOREIGN KEY (book_id) REFERENCES Books(book_id)
);

Xem? book_idlà một khóa ngoại, nhưng nó cũng là một trong các cột trong khóa chính. Vì vậy, bảng này có mối quan hệ xác định với bảng được tham chiếu Books. Tương tự như vậy, nó có mối quan hệ xác định với Authors.

Nhận xét về video YouTube có mối quan hệ xác định với video tương ứng. Khóa video_id phải là một phần của khóa chính của Commentsbảng.

CREATE TABLE Comments (
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  PRIMARY KEY (video_id, user_id, comment_dt),
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Có thể khó hiểu điều này vì ngày nay, thực tế phổ biến là chỉ sử dụng một khóa đại diện nối tiếp thay vì khóa chính ghép:

CREATE TABLE Comments (
  comment_id SERIAL PRIMARY KEY,
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Điều này có thể che khuất các trường hợp trong đó các bảng có mối quan hệ xác định.

Tôi sẽ không coi SSN đại diện cho một mối quan hệ nhận dạng. Một số người tồn tại nhưng không có SSN. Những người khác có thể nộp đơn để nhận SSN mới. Vì vậy, SSN thực sự chỉ là một thuộc tính, không phải là một phần của khóa chính của người đó.


Nhận xét lại từ @Niels:

Vì vậy, nếu chúng ta sử dụng khóa thay thế thay vì khóa chính ghép, thì không có sự khác biệt đáng chú ý nào giữa việc sử dụng mối quan hệ xác định hoặc không xác định?

Tôi cho là vậy. Tôi ngần ngại khi nói có, vì chúng tôi chưa thay đổi mối quan hệ logic giữa các bảng bằng cách sử dụng khóa thay thế. Tức là bạn vẫn không thể đưa ra Bình luận nếu không tham chiếu đến Video hiện có. Nhưng điều đó chỉ có nghĩa là video_id phải KHÔNG ĐẦY ĐỦ. Và khía cạnh logic, đối với tôi, thực sự là điểm về việc xác định các mối quan hệ.

Nhưng có một khía cạnh vật lý của việc xác định các mối quan hệ. Và đó là thực tế là cột khóa ngoại là một phần của khóa chính (khóa chính không nhất thiết phải là khóa tổng hợp, nó có thể là một cột duy nhất vừa là khóa chính của Nhận xét vừa là khóa ngoại của bảng Video , nhưng điều đó có nghĩa là bạn chỉ có thể lưu trữ một nhận xét cho mỗi video).

Việc xác định các mối quan hệ dường như chỉ quan trọng vì lợi ích của việc lập sơ đồ mối quan hệ thực thể và điều này xuất hiện trong các công cụ mô hình hóa dữ liệu GUI.


2
Vì vậy, nếu chúng ta sử dụng khóa thay thế thay vì khóa chính ghép, không có sự khác biệt đáng chú ý nào giữa việc sử dụng mối quan hệ xác định hoặc không xác định?
csblo

vì vậy mọi thực thể yếu có một mối quan hệ xác định?
Vishnu

Câu trả lời hay, nhưng bạn có thể vui lòng trả lời câu hỏi này về lý do tại sao nó lại quan trọng trong thiết kế ERD không? stackoverflow.com/questions/34846418/…
Tripartio

@Ochado, tôi không trả lời câu hỏi về Stack Overflow nữa.
Bill Karwin

1
:) Tôi nghĩ rằng tôi đang tự cải thiện bản thân một chút bằng cách làm việc với một mô hình logic ngày hôm nay trong khi bình thường thì không. Rất nhiều người nơi mà một bảng tra cứu sẽ nằm ở giữa các loại ném cờ lê vào nó cho tôi. Thứ Tư vui vẻ. Cảm ơn bạn đã chia sẻ kiến ​​thức.
Bill Rosmus

19

"vì tôi không muốn học điều gì sai trái".

Xin chào, nếu bạn thực sự muốn nói như vậy, thì bạn có thể ngừng lo lắng về thuật ngữ và biệt ngữ ER. Nó không chính xác, nhầm lẫn, khó hiểu, hoàn toàn không được thỏa thuận chung và phần lớn là không liên quan.

ER là một loạt các hình chữ nhật và các đường thẳng được vẽ trên một tờ giấy. ER được cố ý sử dụng để trở thành một phương tiện cho mô hình không chính thức . Như vậy, nó là một bước đầu tiên có giá trị trong thiết kế cơ sở dữ liệu, nhưng nó cũng chỉ là: bước đầu tiên.

Sơ đồ ER sẽ không bao giờ có được ở bất cứ đâu gần với độ chính xác, độ chính xác và tính hoàn chỉnh của một thiết kế cơ sở dữ liệu được viết chính thức bằng D.


7
Vì vậy, nếu tôi đọc được câu trả lời của bạn đúng, mô hình ER chỉ là một công cụ giúp khái niệm hóa cơ sở dữ liệu (tương tự như cách mô hình hóa UML là một công cụ được sử dụng để khái niệm hóa hệ thống phần mềm). Mặc dù mỗi công cụ đều hữu ích, nhưng điều đó đi kèm với lưu ý rằng chúng có cú pháp riêng và các vấn đề có thể gây thêm nhầm lẫn. Tôi đã không nghĩ đến khía cạnh này. Cảm ơn.
JasCav

1
Nếu ER có nghĩa là 'Thực thể-Mối quan hệ', thì D có nghĩa là gì?
quantme 30/09/13

3
D là họ của tất cả các ngôn ngữ tuân thủ các quy tắc được nêu trong "Cơ sở dữ liệu, Loại & Mô hình quan hệ" và / hoặc "Tuyên ngôn thứ ba".
Erwin Smout

1
Tuyên ngôn thứ ba, viết tắt là TTM, của Chris Date & Hugh Darwen, là kế hoạch chi tiết của họ về ngôn ngữ xử lý dữ liệu [cơ sở] phải trông như thế nào trong thế kỷ 21. Nó xác định các quy tắc và yêu cầu mà ngôn ngữ thế kỷ 21 phải tuân theo. Một trong những yêu cầu đó là khả năng thể hiện / khai báo bất kỳ ràng buộc cơ sở dữ liệu nào từng có một cách chính xác về mặt hình thức. Đừng hiểu nhầm "ràng buộc cơ sở dữ liệu" có nghĩa là "chỉ các loại ràng buộc mà các công cụ SQL thế kỷ 20 có thể hỗ trợ". Không, "cơ sở dữ liệu hạn chế" thực sự có nghĩa là "bất kỳ khó khăn gì vậy bao giờ mà điều chỉnh cơ sở dữ liệu.
Erwin Smout

2
Về mặt cú pháp, cách diễn đạt chính xác về mặt hình thức "bất kỳ ràng buộc cơ sở dữ liệu nào" sẽ khá gần với ngôn ngữ / cú pháp đặc tả thiết kế cơ sở dữ liệu được sử dụng trong "Toán học Ứng dụng cho Chuyên gia Cơ sở dữ liệu". Nó sẽ (chắc chắn) trông hoàn toàn khác với các kỹ thuật đặc tả ràng buộc của các phương pháp truyền thống hơn như ERD và thậm chí của Halpin ORM (hỗ trợ cho đặc tả ràng buộc hoàn thiện hơn ERD).
Erwin Smout

11

Các mối quan hệ xác định / không nhận dạng là các khái niệm trong mô hình ER - một mối quan hệ là một mối quan hệ nhận dạng nếu nó được biểu diễn bằng khóa ngoại là một phần của khóa chính của bảng tham chiếu. Điều này thường rất ít quan trọng trong các thuật ngữ mô hình quan hệ vì các khóa chính trong mô hình quan hệ và trong cơ sở dữ liệu SQL không có bất kỳ ý nghĩa hoặc chức năng đặc biệt nào như trong mô hình ER.

Ví dụ: giả sử bảng của bạn thực thi hai khóa ứng viên, A và B. Giả sử A cũng là một khóa ngoại trong bảng đó. Do đó, mối quan hệ được biểu diễn được coi là "nhận dạng" nếu A được chỉ định là khóa "chính", nhưng không xác định nếu B là khóa chính. Tuy nhiên, hình thức, chức năng và ý nghĩa của bảng giống hệt nhau trong mỗi trường hợp! Đây là lý do tại sao theo ý kiến ​​của tôi, tôi không nghĩ rằng khái niệm xác định / không xác định thực sự rất quan trọng.


+1 - Cảm ơn bạn đã giải quyết vấn đề này! Tôi (và một đồng nghiệp khác, cũng không quen với thiết kế cơ sở dữ liệu) đã vật lộn với điều này vì chúng tôi không hiểu tại sao cái này hay cái kia lại quan trọng khi nó đạt được hiệu quả tương tự. Điều này thực sự hữu ích.
JasCav

Để theo dõi câu trả lời của bạn, bạn có thể vui lòng trả lời hoặc nhận xét về câu hỏi này về lý do tại sao nó lại quan trọng trong thiết kế ERD không? stackoverflow.com/questions/34846418/…
Tripartio

9

Tôi tin rằng sự khác biệt duy nhất giữa mối quan hệ xác định và không xác định là về Tính vô hiệu của khóa ngoại. Nếu một FK không thể là NULL, thì mối quan hệ mà nó đại diện đang xác định (con không thể tồn tại mà không có cha mẹ) nếu không nó không phải là định danh.


1
Nhưng trong câu trả lời của @ hóa đơn karwin đây ông nói rằng một mối quan hệ không xác định có thể tùy chọn hoặc bắt buộc
Ahmed Mostafa Abdel-Baky

7

một phần của vấn đề ở đây là sự nhầm lẫn của thuật ngữ. xác định các mối quan hệ rất hữu ích để tránh các đường dẫn tham gia dài.

Định nghĩa tốt nhất mà tôi từng thấy là "một mối quan hệ xác định bao gồm PK của cha mẹ trong PK con. Nói cách khác, PK của con bao gồm FK đối với cha cũng như PK" thực tế "của con.


3
+1 cho "xác định mối quan hệ hữu ích để tránh các đường dẫn liên kết dài". Sẽ rất tuyệt nếu bạn giải thích thêm về điều này.
mrmashal

1

Đúng, đi với cái đầu tiên, nhưng tôi không nghĩ cái thứ hai mâu thuẫn với cái đầu tiên. Nó chỉ là công thức hơi khó hiểu ..

CẬP NHẬT:

Chỉ cần kiểm tra - câu trả lời của câu hỏi thứ hai là sai trong một số giả định, .. tác giả cuốn sách không nhất thiết phải là quan hệ 1: n, vì nó có thể là m: n. Trong cơ sở dữ liệu quan hệ tạo bảng giao điểm cho quan hệ m: n này và bạn sẽ xác định được quan hệ giữa bảng giao điểm và 2 bảng khác đó ..


1

xác định mối quan hệ cung cấp một đến nhiều mối quan hệ tùy chọn khi chúng ta phải xác định mối quan hệ cha với con. ngoài ra nó cung cấp cho một mối quan hệ duy nhất từ ​​luồng con đến luồng cha. vì khóa chính của thực thể mẹ sẽ là một phần của khóa chính của thực thể con, cá thể thực thể con sẽ xác định cá thể thực thể mẹ. nó được biểu diễn bằng nét liền trong sơ đồ er.

Đối với sự tồn tại của cá thể thực thể con thì phải có cá thể thực thể mẹ nhưng mỗi cá thể thực thể trong thực thể con có thể liên quan đến nhiều cá thể thực thể của thực thể mẹ. đây là lý do tại sao khóa chính của thực thể mẹ cũng là khóa ngoại của thực thể con, nhưng thực thể con sẽ không lấy khóa chính của thực thể mẹ làm khóa chính. nó sẽ có khóa chính riêng. mối quan hệ nhiều đến nhiều không tồn tại trong sơ đồ er thế giới thực. vì vậy nó cần phải được giải quyết


1

Mối quan hệ xác định thực sự là một khái niệm ERD vì đây là lĩnh vực của mô hình khái niệm, mô hình hóa sự hiểu biết của chúng ta về 'vũ trụ của diễn ngôn'. Đó là một mối quan hệ cha-con, theo đó chúng ta mô hình hóa thực tế là danh tính của mỗi đối tượng con được thiết lập / xác định bởi danh tính của đối tượng cha. Do đó, nó là bắt buộc và bất biến.

Một ví dụ thực tế là với thách thức lâu năm trong việc xác định con người. Bản sắc riêng của một người có thể (một phần) được xác định bởi mối quan hệ của họ với cha và mẹ đẻ của họ. Khi biết, đây là những sự thật bất di bất dịch. Do đó, mối quan hệ giữa cha mẹ đẻ và con cái là mối quan hệ đồng nhất trong đó nó góp phần (bất biến) vào việc xác định danh tính của đứa trẻ.

Chính những phẩm chất này và việc sử dụng các cấu trúc dbms quan hệ dẫn đến PK của con là một khóa tổng hợp bao gồm, thông qua FK, PK của cha. Là một PK, danh tính của đứa trẻ là bắt buộc và bất biến (nó không thể thay đổi) Một 'thay đổi' trong PK thực chất là tạo ra một đối tượng mới. Do đó PK không được thay đổi. Tính bất biến của PK cũng nên được hạn chế. Các ràng buộc DB có thể được sử dụng để triển khai chất lượng PK đó.

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.