Chính xác những gì là chồng khóa ứng cử viên?


8

Ai đó có thể vui lòng giải thích cho tôi bằng những thuật ngữ đơn giản overlapping candidate keykhông? Như overlappingtên cho thấy là gì?

Hãy xem xét các mối quan hệ dưới đây

R(L,M,N,O,P) 
{
    M -> O
    NO -> P
    P -> L
    L -> MN
}

Những phụ thuộc chức năng nào ở trên đang mang lại khóa ứng viên chồng chéo trong mối quan hệ trên?

Cho phép hạn chế thảo luận về các phụ thuộc, hiện tại tôi không quan tâm đến BCNF

Câu trả lời:


9

Bạn đang có tiền với các khóa ứng cử viên có thể, vikkyhacks. Các khóa ứng viên chồng chéo là các khóa ứng viên tổng hợp (bao gồm nhiều hơn một thuộc tính) với ít nhất một thuộc tính chung. Vì vậy, các khóa ứng viên chồng chéo của bạn là NM và NO (chúng chia sẻ N).

Giải thích thêm về những điều trên, ban đầu để lại trong các ý kiến:

Tất cả các khóa ứng viên chồng chéo là các nhóm (ví dụ hai hoặc nhiều) khóa ứng viên. Điều đó có nghĩa là tiêu chí đầu tiên là mối quan hệ của bạn Rphải có nhiều hơn một khóa ứng viên (siêu khóa tối thiểu). Đối với bất kỳ khóa ứng cử viên nào được chồng lấp, mỗi khóa trong số chúng (một lần nữa hai hoặc nhiều hơn) phải đáp ứng một vài điều kiện bổ sung. 1) Cả hai phải là khóa ứng viên tổng hợp. Chúng phải bao gồm nhiều hơn một thuộc tính, do đó, một khóa giống như Asẽ không bao giờ bị chồng chéo, nhưng ABcó thể trùng lặp với một khóa khác. 2) Các khóa tổng hợp phải chia sẻ một thuộc tính. ABchồng chéo với ACBDnhưng không CDhoặc EF.

Tóm lại: hai hoặc nhiều bộ thuộc tính trong đó 1) mỗi bộ là một khóa ứng cử viên (siêu khóa tối thiểu) cho mối quan hệ, 2) mỗi bộ là một khóa tổng hợp (bao gồm nhiều hơn một thuộc tính) và 3) một hoặc nhiều các thuộc tính của các khóa tổng hợp trùng với một thuộc tính của một khóa khác trong tập hợp. Vì vậy, bạn có thể loại trừ MNOPNOPLtrên cơ sở rằng chúng không phải là siêu khóa tối thiểu. Bạn có thể loại trừ PLtrên cơ sở chúng không phải là khóa tổng hợp (chúng bao gồm một thuộc tính). Bạn còn lại hai khóa NONMchia sẻ thuộc tính N, vậy là bạn đã hoàn thành.

Thí dụ

Nó cũng có thể giúp có một ví dụ bạn thực sự có thể quấn đầu xung quanh. Lần duy nhất tôi từng thấy nơi bạn sẽ có các khóa ứng viên chồng chéo là khi bạn có 1) hai thuộc tính có chức năng xác định lẫn nhau (ví dụ: mối quan hệ một-một giữa ABnơi Acó một BBcó một A) và 2) các thuộc tính là một phần của khóa ứng viên tổng hợp.

Ví dụ, trong một số hệ thống, một Customercó một CreditCardvà một CreditCardthuộc về một Customer. Trong bảng Cho thuê nhà, bạn nhận ra duy nhất một Rentalbằng EquipmentId, DateCustomerId. Để thuận tiện, bạn cũng đã lưu trữ CreditCardtrên bảng này.

Điều này có nghĩa là các FD sau giữ:

{CustomerId, EquipmentId, Date} -> {CreditCard}
{CustomerId} -> {CreditCard}

Nhưng vì liên kết là một đối một, các FD sau đây cũng nắm giữ:

{CreditCard} -> {CustomerId}
{CreditCard, EquipmentId, Date} -> {CustomerId}

CustomerIdCreditCardcó thể được sử dụng thay thế cho nhau để xác định duy nhất khách hàng của bạn.

Trong kịch bản trên, bạn có các khóa ứng viên chồng chéo:

{CreditCard, EquipmentId, Date}
{CustomerId, EquipmentId, Date}

Chúng chồng chéo vì chúng là các khóa tổng hợp (chúng bao gồm nhiều hơn một thuộc tính) và vì ít nhất một thuộc tính của chúng được chia sẻ (trong trường hợp này, chúng chia sẻ cả hai EquipmentIdDate.

Bạn nói rằng bạn không quan tâm BCNFvào lúc này, nhưng để mang đầy đủ căn nhà này, kịch bản ở trên là lý do tại sao bạn sẽ thỉnh thoảng nhìn thấy một cái bàn ở trong 3NFnhưng không BCNF. Bảng trên là trong 3NF, nhưng không BCNF.

3NFcho phép các FD trong đó 1) FD là tầm thường 2) bên trái của FD là khóa ứng cử viên hoặc 3) bên phải của FD là một thuộc tính khóa (một thuộc tính được sử dụng để tạo bất kỳ khóa nào). Vì CreditCardCustomerIdlà cả hai thuộc tính chính, tất cả các FD đều đáp ứng 2 hoặc 3.

BCNFlà rất giống nhau, nhưng nó chỉ cho phép điều kiện 1 và 2 cho phép 3NF. Vì điều kiện thứ 3 không được phép BCNFvà cả hai CID -> CCCC -> CIDsử dụng điều kiện 3, bảng này không có BCNF, nhưng nó là 3NF.

Đối với các mục đích thực tế, trường hợp này là khá hiếm và thông tin này là phạm vi. Giveaway mà bảng của bạn có vấn đề sẽ là thực tế rằng CreditCard/CustomerIdcác cặp được lặp lại trên bảng của bạn. Bạn cũng có thể nhận ra rằng bảng thậm chí sẽ không tồn tại 2NFnếu không có tình trạng hiếm gặp này trong đó phía bên phải của FD có thể là thuộc tính khóa vì CreditCardphụ thuộc một phần vào khóa chính (nó phụ thuộc vào CustomerIdnhưng không EquipmentIdhoặc Date.


4

Khóa ứng cử viên là một tập hợp các thuộc tính tạo thành một siêu khóa tối thiểu. Hai khóa ứng viên, A và B, được cho là trùng nhau nếu chúng có một số thuộc tính chung, nghĩa là: A B không trống. Trong trường hợp của bạn, MN và NO sẽ chồng lấp các khóa ứng viên trong R.

Do yêu cầu tối thiểu (không thể sửa chữa), một khóa ứng viên không bao giờ có thể là tập hợp con của một khóa khác trong cùng một mối quan hệ. Theo sau, đối với hai khóa ứng viên riêng biệt có mối quan hệ trùng lặp cả hai phải bao gồm nhiều hơn một thuộc tính, nghĩa là: đối với bất kỳ cặp khóa ứng viên chồng chéo nào A - (A B) phải không trống và B - (A B) ) phải không trống.


1

Ba FD đầu tiên kết hợp để cung cấp

MNOP -> L

vì vậy MNOP là một khóa ứng cử viên có thể, CK1.

Tương tự ba kết hợp của FD cuối cùng để cung cấp

NOPL -> M

vì vậy NOPL là một khóa ứng cử viên khả thi khác, CK2.

Tuy nhiên, CK1 và CK2 có các cột NOP chung, làm cho chúng trùng nhau với các khóa ứng cử viên.


1
NOPL và MNOP là siêu phím, các phím ứng cử viên có thể là P, L, NO, và NMMột đủ tiêu chuẩn siêu chính là một chìa khóa ứng cử viên duy nhất nếu không có bất kỳ tập con tối thiểu. Lấy ví dụ của bạn MNOPlà siêu khóa vì tập hợp con tối thiểu Ptrong nó có thể rút ra tất cả các thuộc tính khác trong mối quan hệ
vikkyhacks

-1

Để kiểm tra xem mối quan hệ có phụ thuộc khóa Ứng viên chồng chéo hay không:

Kiểm tra xem có bất kỳ sự phụ thuộc nào trong đó khóa Ứng viên hoàn chỉnh đang xác định một phần của khóa Ứng viên hay không. Sau đó, phụ thuộc OCK giữ

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.