Sự khác biệt giữa các mối quan hệ xác định và không xác định là gì?


800

Tôi chưa thể nắm bắt được sự khác biệt. Bạn có thể mô tả cả hai khái niệm và sử dụng các ví dụ thực tế?


11
câu trả lời cho câu hỏi này rất khó hiểu, nó không vui chút nào
Dennis

Câu hỏi hay, bánh xe không được phát minh lại: Peter Chen. Mô hình quan hệ thực thể, hướng tới một quan điểm thống nhất về dữ liệu, 1976 § 2.3.2: " Nếu các mối quan hệ được sử dụng để xác định các thực thể, chúng ta sẽ gọi nó là mối quan hệ thực thể yếu. Nếu các mối quan hệ không được sử dụng để xác định các thực thể, chúng ta sẽ gọi đó là một mối quan hệ thực thể thường xuyên ". Câu hỏi OP sôi nổi là: Quan hệ thực thể yếu / thường xuyên là gì? .
phút

Câu trả lời:


1063
  • Một mối quan hệ xác định là khi 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 cha. Điều này có thể gây nhầm lẫn bởi vì ngày nay, thông thường là tạo ra một mã giả cho bảng con, nhưng không tạo khóa ngoại cho phần cha mẹ của khóa chính của trẻ. Chính thức, cách "đúng" để làm điều này là biến phần khóa ngoài của khóa chính của trẻ. Nhưng mối quan hệ logic là đứa trẻ không thể tồn tại mà không có cha mẹ.

    Ví dụ: A Personcó một hoặc nhiều số điện thoại. Nếu họ chỉ có một số điện thoại, chúng ta có thể lưu nó vào một cột Person. Vì chúng tôi muốn hỗ trợ nhiều số điện thoại, chúng tôi tạo một bảng thứ hai PhoneNumbers, có khóa chính bao gồm bảng person_idtham chiếu Person.

    Chúng ta có thể nghĩ (các) số điện thoại thuộc về một người, mặc dù chúng được mô hình hóa như các thuộc tính của một bảng riêng biệt. Đây là một manh mối mạnh mẽ rằng đây là một mối quan hệ xác định (ngay cả khi chúng tôi không bao gồm nghĩa đen person_idtrong khóa chính của PhoneNumbers).

  • Một mối quan hệ không xác định là khi các thuộc tính khóa chính của cha mẹ không phải trở thành thuộc tính khóa chính của trẻ. Một ví dụ điển hình của việc này là bảng tra cứu, chẳng hạn như khóa ngoại khi Person.statetham chiếu khóa chính của States.state. Personlà một bảng con đối với States. Nhưng một hàng trong Personkhông được xác định bởi statethuộc tính của nó . Tức statelà không phải là một phần của khóa chính của Person.

    Một mối quan hệ không xác định có thể là tùy chọn hoặc bắt buộc , có nghĩa là cột khóa ngoài cho phép NULL hoặc không cho phép NULL tương ứng.


Xem thêm câu trả lời của tôi cho Vẫn còn nhầm lẫn về Xác định so với Mối quan hệ không xác định


9
+1: Bill, "thực tế phổ biến hiện nay là tạo một mã giả cho bảng con, nhưng không tạo khóa ngoại cho phần cha mẹ của khóa chính của trẻ" - có liên kết nào về lý do tại sao không? Google đang làm tôi thất bại.
hobodave

17
Có vẻ như việc xây dựng các mối quan hệ xác định "đúng" sẽ dẫn đến các khóa chính rất lớn đáng ghét. vd: Tòa nhà có Tầng có Phòng có Giường. PK cho Giường sẽ là (bed_id, floor_id, room_id, Building_id). Có vẻ lạ là tôi chưa bao giờ thấy điều này trong thực tế, cũng không nghe thấy nó gợi ý như một cách để làm bất cứ điều gì. Đó là rất nhiều dữ liệu dư thừa trong PK.
hobodave

24
@hobodave: Tôi đã thấy các khóa chính nhiều cột thậm chí còn lớn hơn. Nhưng tôi có quan điểm của bạn. Hãy xem xét rằng các khóa chính nhiều cột truyền tải nhiều thông tin hơn; bạn có thể truy vấn các Bedsbảng cho tất cả các giường trong một tòa nhà cụ thể mà không làm bất kỳ tham gia.
Bill Karwin

2
@Eugene, vâng tôi mong đó là mối quan hệ không xác định. user_idphải là khóa chính của chính nó và updated_bykhông phải là một phần của khóa chính nhiều cột.
Bill Karwin

4
Tôi sẽ không bao giờ sử dụng điều này để mô hình hóa điều đó. Câu trả lời tốt nhất là từ "aqsa rao" bên dưới có nội dung như sau: "Mối quan hệ xác định có nghĩa là bảng con không thể được xác định duy nhất mà không có cha mẹ." Bởi vì định nghĩa của bạn là thêm ngữ nghĩa không cần thiết có thể gây nhầm lẫn cho mọi người. Đó không phải là sự phụ thuộc giữa các thực thể lý do bạn tạo mối quan hệ xác định hoặc không xác định.
Sebastian

888

Có một lời giải thích khác từ thế giới thực:

Một cuốn sách thuộc về chủ sở hữu và chủ sở hữu có thể sở hữu nhiều sách. Nhưng, cuốn sách cũng có thể tồn tại mà không cần chủ sở hữu và quyền sở hữu của nó có thể thay đổi từ chủ sở hữu này sang chủ sở hữu khác. Mối quan hệ giữa một cuốn sách và chủ sở hữu là một mối quan hệ không xác định.

Tuy nhiên, một cuốn sách được viết bởi một tác giả và tác giả có thể đã viết nhiều cuốn sách. Nhưng, cuốn sách cần được viết bởi một tác giả - nó không thể tồn tại mà không có tác giả. Do đó, mối quan hệ giữa cuốn sách và tác giả là mối quan hệ xác định.


2
Một lời giải thích hợp lý nhưng tôi tin rằng nó cũng được khuyến khích để mở rộng ví dụ một chút. Một cuốn sách có một số trang. Nó không thể tồn tại mà không có trang và do đó chúng tôi có thể kết luận rằng mối quan hệ giữa một cuốn sách và số trang mà nó có cũng là mối quan hệ xác định. Nhưng liệu số lượng thuộc tính trang có phải là một phần của bất kỳ lược đồ nhận dạng (khóa) nào cho cuốn sách không? Chắc là không. Thuật ngữ "xác định mối quan hệ" thường được dành riêng cho các mối quan hệ liên quan đến việc xác định các thuộc tính - thuộc tính nguyên tố trong các thuật ngữ quan hệ.
nvogel

13
Điều gì xảy ra nếu cuốn sách được viết bởi hơn 1 tác giả? Nó không xác định mối quan hệ nữa là loại M: N, tại sao?
NGix

2
Những ví dụ thực tế là vô dụng. Khi bạn nhận ra cách bạn tạo các bảng trong ER và cách toàn vẹn dữ liệu sẽ giữ, bạn sẽ loại bỏ các ví dụ này. Nếu bạn tạo mối quan hệ chặt chẽ giữa hai thực thể, bạn buộc phải tạo khóa chính trong bảng thực thể kết hợp với PK từ thực thể kia. Nếu mô hình của bạn cho phép bạn cùng một cuốn sách có thể có nhiều tác giả, thì bạn có thể mạnh mẽ. Nhưng nếu mô hình của bạn chỉ cho phép bạn 1 tác giả 1 cuốn sách, bạn không thể có ràng buộc đó bằng cách sử dụng mối quan hệ mạnh mẽ bởi vì PK(Book.id, Book.person_id).
Sebastian

2
nhưng cách sử dụng thực sự là "cuốn sách có thể tồn tại mà không có tác giả?". Câu trả lời là có trong thực tế, bởi vì mọi người sẽ tìm kiếm cuốn sách trực tiếp. Do đó, trong thực tế, trong trường hợp này, chúng phải luôn là "mối quan hệ không xác định".
Windmaomao

3
chuyện gì đang xảy ra vậy các bạn !!, đây không phải là một ví dụ hợp lệ cho the Identifying relationship !!! vâng, một cuốn sách không thể được viết mà không có tác giả, nhưng trường tác giả trong bảng sách KHÔNG ĐƯỢC XÁC NHẬN hàng sách !!!
Kế toán م

33

Câu trả lời của Bill là chính xác, nhưng thật sốc khi thấy rằng trong số tất cả các câu trả lời khác, không ai chỉ ra khía cạnh quan trọng nhất.

Người ta nói đi nói lại rằng mối quan hệ trong và xác định đứa trẻ không thể tồn tại mà không có cha mẹ. (ví dụ: người dùng287724 ). Điều này là đúng, nhưng hoàn toàn bỏ lỡ điểm. Nó là đủ để khóa ngoại là không null để đạt được điều này. Nó không cần phải là một phần của khóa chính.

Vì vậy, đây là lý do thực sự:

Mục đích của mối quan hệ xác định là khóa ngoại có thể KHÔNG BAO GIỜ THAY ĐỔI , vì đó là một phần của khóa chính ... do đó, xác định !!!


2
+1 cho "Nó là đủ đủ để khóa ngoại không phải là null, để đạt được điều này." Nó nên là đủ, nhưng tiếc là nó không phải là khi nói đến một cái gì đó giống như Entity Framework, mà không làm việc đúng, trừ khi bạn sử dụng một mối quan hệ xác định, nhưng sau đó "Id" lĩnh vực của một thực thể mất nó độc đáo như một kết quả của việc chỉ một phần của khóa tổng hợp.
Triynko

25

Một mối quan hệ Xác định xác định rằng một đối tượng con không thể tồn tại mà không có đối tượng cha

Các mối quan hệ không xác định chỉ định một liên kết thường xuyên giữa các đối tượng, tỷ lệ chính 1: 1 hoặc 1: n.

Các mối quan hệ không xác định có thể được chỉ định là tùy chọn trong đó không yêu cầu cha mẹ hoặc bắt buộc khi yêu cầu cha mẹ bằng cách đặt thẻ chính của bảng cha mẹ ...


6
Điều này nghe có vẻ giống như một mô tả về tổng số tham gia vào một mối quan hệ, hơn là một mối quan hệ xác định.
Thomas Padron-McCarthy

1
Bạn thực sự đang cạnh tranh với một anh chàng có 218k danh tiếng. Chỉ cần ném nó ra khỏi đó bởi vì cả hai bạn chắc chắn biết nhiều hơn tôi.
Marc DiMillo

Tôi không đồng ý với các định nghĩa trên. Bạn có thể có một đối tượng phụ thuộc vào cha mẹ của nó và bạn muốn đối tượng đó bị ràng buộc chỉ được liên kết với 1 hàng cha. A HouseWalls. Bạn xóa nhà và bạn không có tường. Nhưng một bức tường chỉ thuộc về một ngôi nhà. Vì vậy, thực hiện mối quan hệ mạnh mẽ sẽ không hoạt động: PK(Wall.id, House.id)sẽ cho phép bạn chèn vào mô hình cùng một bức tường đến một ngôi nhà khác.
Sebastian

15

Đây là một mô tả hay:

Mối quan hệ giữa hai thực thể có thể được phân loại là "xác định" hoặc "không xác định". Xác định mối quan hệ tồn tại khi khóa chính của thực thể mẹ được bao gồm trong khóa chính của thực thể con. Mặt khác, một mối quan hệ không xác định tồn tại khi khóa chính của thực thể mẹ được bao gồm trong thực thể con nhưng không phải là một phần của khóa chính của thực thể con. Ngoài ra, các mối quan hệ không xác định có thể được phân loại thêm thành "bắt buộc" hoặc "không bắt buộc". Một mối quan hệ không xác định bắt buộc tồn tại khi giá trị trong bảng con không thể rỗng. Mặt khác, tồn tại một mối quan hệ không xác định không bắt buộc khi giá trị trong bảng con có thể là null.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Đây là một ví dụ đơn giản về mối quan hệ xác định:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

Đây là một mối quan hệ không xác định tương ứng:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

1
Câu trả lời của bạn mâu thuẫn với câu trả lời của Bill Karwin, về sự khác biệt giữa việc Khóa ngoài "không phải" hay "không phải" là một phần của Khóa chính trong hàng Con.
Nicole

@Andy White Nhưng khóa chính của cha mẹ trong mối quan hệ xác định có thể là không bắt buộc, nghĩa là không, khi nó là một phần của khóa chính hỗn hợp ba cột?
Frederik Krautwald

10

Câu trả lời của user287724 đưa ra ví dụ sau về mối quan hệ của cuốn sách và tác giả:

Tuy nhiên, một cuốn sách được viết bởi một tác giả và tác giả có thể đã viết nhiều cuốn sách. Nhưng cuốn sách cần được viết bởi một tác giả, nó không thể tồn tại mà không có tác giả. Do đó, mối quan hệ giữa cuốn sách và tác giả là mối quan hệ xác định.

Đây là một ví dụ rất khó hiểu và chắc chắn không phải là một ví dụ hợp lệ cho một identifying relationship.

Vâng, một bookkhông thể được viết mà không có ít nhất một author, nhưng author(đó là khoá ngoại) của bookKHÔNG XÁC ĐỊNH sự booktrong booksbảng!

Bạn có thể loại bỏ các author(FK) từ bookhàng và vẫn có thể xác định được hàng cuốn sách của một số lĩnh vực khác ( ISBN, ID, ... vv), nhưng không phải là tác giả của cuốn sách !!

Tôi nghĩ rằng một ví dụ hợp lệ của một identifying relationshipsẽ là mối quan hệ giữa (bảng sản phẩm) và (bảng chi tiết sản phẩm cụ thể)1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

Trong ví dụ này, Product_IDtrong printers_detailsbảng được coi là FK tham chiếu products.idbảng và CSONG PK trong printers_detailsbảng, đây là mối quan hệ xác định vì Product_ID(FK) trong bảng máy in ĐƯỢC XÁC NHẬN hàng bên trong bảng con, chúng tôi không thể xóa các product_idtừ bảng con vì chúng ta không thể xác định được hàng nữa bởi vì chúng tôi mất đó là khóa chính

Nếu bạn muốn đặt nó thành 2 dòng:

mối quan hệ xác định là mối quan hệ khi FK trong bảng con được coi là PK (hoặc mã định danh) trong bảng con trong khi vẫn tham chiếu bảng cha

Một ví dụ khác có thể là khi bạn có 3 bảng (nhập khẩu - sản phẩm - quốc gia) trong một nhập khẩu và xuất khẩu cho một số cơ sở dữ liệu quốc gia

Các importbảng là đứa trẻ đó có các lĩnh vực (các product_id(FK), các country_id(FK), lượng hàng nhập khẩu, giá cả, các đơn vị nhập khẩu, cách vận chuyển (không khí, nước biển)) we may use the (product_id , thecountry_id`) để xác định mỗi hàng nhập khẩu "nếu tất cả chúng trong cùng một năm" ở đây, cả hai cột có thể kết hợp một khóa chính trong bảng con (nhập) và cũng tham chiếu các bảng cha.

Xin vui lòng, cuối cùng tôi cũng hiểu khái niệm về identifying relationshipnon identifying relationship, vì vậy xin đừng nói với tôi rằng tôi đã sai với tất cả các phiếu bầu cho một ví dụ hoàn toàn không hợp lệ

Có một cách hợp lý một cuốn sách không thể được viết mà không có tác giả nhưng một cuốn sách có thể được xác định mà không có tác giả, thực tế nó không thể được xác định với tác giả!

Bạn có thể xóa 100% tác giả khỏi hàng sách và vẫn có thể xác định sách! .


5
Bạn nói đúng, nếu bạn chỉ có bảng sách và tác giả. Không có mối quan hệ xác định ở đó. Nhưng nếu bạn sử dụng bảng thứ ba để thể hiện mối quan hệ nhiều-nhiều, khóa chính của bảng thứ ba đó bao gồm hai khóa ngoại, tham chiếu bảng sách và bảng tác giả. Bảng đó có mối quan hệ xác định với cả sách và tác giả. Xem ví dụ của tôi trong stackoverflow.com/questions/2814469/ Mạnh
Bill Karwin

8

Mối quan hệ không xác định

Một mối quan hệ không xác định có nghĩa là một đứa trẻ có liên quan đến cha mẹ nhưng nó có thể được xác định bởi chính nó.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

Mối quan hệ giữa TÀI KHOẢN và CÁ NHÂN là không xác định.

Xác định mối quan hệ

Một mối quan hệ xác định có nghĩa là cha mẹ là cần thiết để cung cấp danh tính cho trẻ. Đứa trẻ chỉ tồn tại vì cha mẹ.

Điều này có nghĩa là khóa ngoại cũng là một khóa chính.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

Mối quan hệ giữa ITEM_LANG và ITEM đang được xác định. Và giữa ITEM_LANG và NGÔN NGỮ cũng vậy.


2
CÁ NHÂN và TÀI KHOẢN không xác định như thế nào? TÀI KHOẢN có thể tồn tại mà không cần CÁ NHÂN?
MrRobot9

Tại sao không có câu trả lời cho nhận xét trước? @ MrRobot9
AAEM

4

Nếu bạn cho rằng mục con nên bị xóa khi cha mẹ bị xóa, thì đó là một mối quan hệ xác định.

Nếu mục con nên được giữ ngay cả khi cha mẹ bị xóa, thì đó là một mối quan hệ không xác định.

Ví dụ, tôi có một cơ sở dữ liệu đào tạo với các học viên, đào tạo, văn bằng và các buổi đào tạo:

  • Thực tập sinh có mối quan hệ xác định với các buổi đào tạo
  • đào tạo có mối quan hệ xác định với các buổi đào tạo
  • nhưng thực tập sinh có mối quan hệ không xác định với văn bằng

Chỉ nên xóa các buổi đào tạo nếu một trong những học viên, đào tạo hoặc bằng tốt nghiệp liên quan bị xóa.


3

Các mối quan hệ xác định có nghĩa là thực thể con hoàn toàn phụ thuộc vào sự tồn tại của thực thể cha mẹ. Ví dụ bảng người tài khoản bảng và personaccount. Bảng tài khoản người được xác định chỉ bằng sự tồn tại của tài khoản và bảng người.

Mối quan hệ không xác định có nghĩa là bảng con không được xác định bởi sự tồn tại của ví dụ bảng cha có bảng là tài khoản và bảng account.accounttype không được xác định với sự tồn tại của bảng tài khoản.


2

Giống như được giải thích rõ trong liên kết bên dưới, một mối quan hệ xác định có phần giống như mối quan hệ kiểu thực thể yếu với cha mẹ của nó trong mô hình khái niệm ER. CAD kiểu UML để mô hình hóa dữ liệu không sử dụng các biểu tượng hoặc khái niệm ER và loại quan hệ là: xác định, không xác định và không cụ thể.

Xác định các mối quan hệ là cha mẹ / con cái trong đó đứa trẻ là một thực thể yếu (ngay cả ở mô hình ER truyền thống, nó được gọi là mối quan hệ xác định), không có khóa chính thực sự bởi các thuộc tính riêng của nó và do đó không thể được xác định duy nhất bằng chính nó . Mọi quyền truy cập vào bảng con, trên mô hình vật lý, sẽ phụ thuộc (bao gồm cả về mặt ngữ nghĩa) vào khóa chính của cha mẹ, biến thành một phần hoặc toàn bộ khóa chính của con (cũng là khóa ngoại), thường dẫn đến khóa tổng hợp về phía con Các khóa hiện có cuối cùng của chính đứa trẻ chỉ là khóa giả hoặc khóa một phần, không đủ để xác định bất kỳ trường hợp nào của loại Thực thể hoặc Tập thực thể đó, không có PK của cha mẹ.

Mối quan hệ không xác định là các mối quan hệ thông thường (một phần hoặc toàn bộ), của các tập thực thể hoàn toàn độc lập, mà các trường hợp không phụ thuộc vào các khóa chính của nhau để được xác định duy nhất, mặc dù chúng có thể cần khóa ngoại cho các mối quan hệ một phần hoặc toàn bộ, nhưng không là chìa khóa chính của trẻ. Đứa trẻ có khóa chính của nó. Các idem cha. Cả hai độc lập. Tùy thuộc vào số lượng của mối quan hệ, PK của một người đi như một FK sang bên kia (bên N) và nếu một phần, có thể là null, nếu tổng, phải không phải là null. Nhưng, tại một mối quan hệ như thế này, FK sẽ không bao giờ là PK của đứa trẻ, vì khi một mối quan hệ xác định là trường hợp.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships


2

Các thuộc tính được di chuyển từ cha mẹ sang con có giúp xác định 1 đứa trẻ không?

  • Nếu : sự phụ thuộc nhận dạng tồn tại, mối quan hệ được xác định và thực thể con là "yếu".
  • Nếu không : sự phụ thuộc nhận dạng không tồn tại, mối quan hệ là không xác định và thực thể con "mạnh".

Lưu ý rằng sự phụ thuộc nhận dạng ngụ ý sự phụ thuộc tồn tại, nhưng không phải là cách khác. Mỗi FK không phải là NULL có nghĩa là một đứa trẻ không thể tồn tại mà không có cha mẹ, nhưng điều đó một mình không làm cho mối quan hệ được xác định.

Để biết thêm về điều này (và một số ví dụ), hãy xem phần "Xác định mối quan hệ" trong Hướng dẫn phương pháp ERwin .

Tái bút Tôi nhận ra rằng tôi (cực kỳ) đến bữa tiệc muộn, nhưng tôi cảm thấy các câu trả lời khác không hoàn toàn chính xác (xác định nó dưới dạng phụ thuộc tồn tại thay vì phụ thuộc vào nhận dạng), hoặc hơi uốn khúc. Hy vọng câu trả lời này cung cấp rõ ràng hơn ...


1 FK của trẻ là một phần của ràng buộc CHÍNH HÃNG của trẻ hoặc ràng buộc (không phải NULL).


1

Một ví dụ tốt đến từ xử lý đơn hàng. Một đơn đặt hàng từ khách hàng thường có Số thứ tự xác định đơn hàng, một số dữ liệu xảy ra một lần cho mỗi đơn hàng như ngày đặt hàng và ID khách hàng và một loạt các chi tiết đơn hàng. Mỗi chi tiết đơn hàng chứa một số mục xác định một chi tiết đơn hàng trong một đơn hàng, một sản phẩm được đặt hàng, số lượng sản phẩm đó, giá của sản phẩm và số lượng cho chi tiết đơn hàng có thể được tính bằng cách nhân số lượng với giá bán.

Số xác định một mục hàng chỉ xác định nó trong ngữ cảnh của một đơn hàng. Mục hàng đầu tiên trong mỗi đơn hàng là số mục "1". Danh tính đầy đủ của một mục hàng là số mục cùng với số thứ tự mà nó là một phần.

Do đó, mối quan hệ cha mẹ giữa các đơn hàng và chi tiết đơn hàng là mối quan hệ xác định. Một khái niệm liên quan chặt chẽ trong mô hình ER có tên là "subentity", trong đó chi tiết đơn hàng là một phần phụ của đơn hàng. Thông thường, một người con có mối quan hệ nhận dạng cha-con bắt buộc với thực thể mà nó phụ thuộc.

Trong thiết kế cơ sở dữ liệu cổ điển, khóa chính của bảng LineItems sẽ là (OrderNumber, ItemNumber). Một số nhà thiết kế ngày nay sẽ cung cấp cho một mục một ItemID riêng, đóng vai trò là khóa chính và được DBMS tự động bổ sung. Tôi đề nghị thiết kế cổ điển trong trường hợp này.


0

Hãy nói rằng chúng ta có những bảng:

user
--------
id
name


comments
------------
comment_id
user_id
text

mối quan hệ giữa hai bảng sẽ xác định mối quan hệ. Bởi vì, bình luận chỉ có thể thuộc về chủ sở hữu của nó, không phải người dùng khác. ví dụ. Mỗi người dùng có nhận xét riêng và khi người dùng bị xóa, bình luận của người dùng này cũng sẽ bị xóa.


0

Một mối quan hệ xác định là giữa hai thực thể mạnh mẽ. Một mối quan hệ không xác định có thể không phải luôn luôn là mối quan hệ giữa thực thể mạnh và thực thể yếu. Có thể tồn tại một tình huống trong đó bản thân một đứa trẻ có khóa chính nhưng sự tồn tại của thực thể của nó có thể phụ thuộc vào thực thể mẹ của nó.

Ví dụ: mối quan hệ giữa người bán và sách nơi người bán đang bán sách có thể tồn tại trong đó người bán có thể có khóa chính của mình nhưng thực thể của nó chỉ được tạo khi sách được bán

Tham khảo dựa trên Bill Karwin


5
Nó có thể giúp xác định những gì bạn có nghĩa là một thực thể "mạnh" và "yếu" ở đây.
nullability
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.