Apa sebenarnya kunci kandidat yang tumpang tindih?

Bisakah seseorang menjelaskan kepada saya secara sederhana apa itu overlapping candidate key? Apa overlappingnamanya?

Pertimbangkan hubungan di bawah ini

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

Manakah dari ketergantungan fungsional di atas yang membawa kunci kandidat yang tumpang tindih dalam hubungan di atas?

Mari kita batasi diskusi untuk dependensi, saya tidak tertarik pada BCNF saat ini

Anda benar pada uang dengan kunci kandidat yang mungkin, vikkyhacks. Kunci kandidat yang tumpang tindih adalah kunci kandidat gabungan (terdiri dari lebih dari satu atribut) dengan setidaknya satu atribut yang sama. Jadi kunci kandidat Anda yang tumpang tindih adalah NM dan NO (mereka membagikan N).

Penjelasan tambahan di atas, awalnya dibiarkan dalam komentar:

Semua kunci kandidat yang tumpang tindih adalah grup kunci kandidat (misalnya dua atau lebih). Itu berarti kriteria pertama adalah bahwa relasi Anda Rharus memiliki lebih dari satu kunci kandidat (kunci super minimal). Agar salah satu kunci kandidat menjadi tumpang tindih, masing-masing dari mereka (lagi dua atau lebih) harus memenuhi beberapa persyaratan tambahan. 1) Keduanya harus merupakan kunci kandidat gabungan. Mereka harus terdiri dari lebih dari satu atribut, jadi kunci seperti Atidak akan pernah tumpang tindih, tetapi ABmungkin tumpang tindih dengan kunci lain. 2) Kunci komposit harus berbagi atribut. ABtumpang tindih dengan ACdan BDtetapi tidak CDatau EF.

Untuk meringkas: dua set atau lebih atribut di mana 1) setiap set adalah kunci kandidat (superkey minimal) untuk relasi, 2) setiap set adalah kunci komposit (terdiri dari lebih dari satu atribut), dan 3) satu atau lebih dari atribut kunci komposit tumpang tindih dengan atribut kunci lain di set. Jadi Anda bisa mengesampingkan MNOPdan NOPLatas dasar bahwa mereka bukan superkey minimal. Anda dapat mengesampingkan Pdan Latas dasar bahwa itu bukan kunci komposit (mereka terdiri dari satu atribut). Anda memiliki dua kunci, NOdan NM, yang membagikan atribut N, sehingga Anda selesai.

Contoh

Mungkin juga membantu jika Anda memiliki contoh yang benar-benar dapat membungkus kepala Anda. Satu-satunya waktu yang pernah saya lihat di mana Anda akan memiliki kunci kandidat yang tumpang tindih adalah ketika Anda memiliki 1) dua atribut yang secara fungsional menentukan satu sama lain (misalnya hubungan satu-ke-satu antara Adan di Bmana Amemiliki satu Bdan Bmemiliki satu A) dan 2) ini atribut adalah bagian dari kunci kandidat gabungan.

Misalnya, dalam beberapa sistem, a Customermemiliki satu CreditCard, dan CreditCardmilik satu Customer. Di tabel Penyewaan, Anda mengidentifikasi secara unik Rentaloleh EquipmentId, Datedan CustomerId. Untuk kenyamanan, Anda juga telah menyimpannya CreditCarddi meja ini.

Ini berarti bahwa FD berikut ini berlaku:

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

Tapi karena asosiasi itu satu-ke-satu, FD berikut juga berlaku:

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

Sejak CustomerIddan CreditCarddapat digunakan secara bergantian untuk mengidentifikasi pelanggan Anda secara unik.

Dalam skenario di atas, Anda memiliki kunci kandidat yang tumpang tindih:

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

Mereka tumpang tindih karena mereka adalah kunci komposit (mereka terdiri dari lebih dari satu atribut) dan karena setidaknya satu dari atribut mereka dibagikan (dalam hal ini, mereka berbagi keduanya EquipmentIddan Date.

Anda bilang Anda tidak peduli BCNFsaat ini, tetapi untuk membawa pulang ini sepenuhnya, skenario di atas adalah alasan mengapa Anda kadang-kadang akan melihat meja yang ada 3NFtetapi tidak BCNF. Tabel di atas adalah dalam 3NF, tetapi tidak BCNF.

3NFmemungkinkan FD di mana 1) FD sepele 2) sisi kiri FD adalah kunci kandidat atau 3) sisi kanan FD adalah atribut kunci (atribut yang digunakan untuk membuat kunci apa saja). Karena CreditCarddan CustomerIdkeduanya atribut utama, semua FD memenuhi 2 atau 3.

BCNFsangat mirip, tetapi hanya memungkinkan kondisi 1 dan 2 diizinkan oleh 3NF. Karena kondisi ke-3 tidak diizinkan oleh BCNF, dan keduanya CID -> CCserta CC -> CIDmenggunakan kondisi 3, tabel ini tidak BCNF, tetapi memang demikian 3NF.

Untuk tujuan praktis, kasus ini cukup langka dan informasi ini sangat lengkap. Hadiah bahwa meja Anda memiliki masalah adalah fakta bahwa CreditCard/CustomerIdpasangan diulangi di meja Anda. Anda juga mungkin menyadari bahwa tabel tidak akan masuk 2NFtanpa kondisi langka ini di mana sisi kanan FD dapat menjadi atribut kunci karena CreditCardmerupakan ketergantungan parsial pada kunci primer (tergantung pada CustomerIdtetapi tidak EquipmentIdatau Date.

Kunci kandidat adalah sekumpulan atribut yang membentuk superkey minimal. Dua kunci kandidat, A dan B, dikatakan tumpang tindih jika mereka memiliki beberapa atribut yang sama, yaitu: A ∩ B tidak kosong. Dalam kasus Anda, MN dan NO akan tumpang tindih kunci kandidat di R.

Karena persyaratan minimal (irreducibility) salah satu kunci kandidat tidak pernah dapat menjadi bagian dari yang lain dalam hubungan yang sama. Oleh karena itu untuk dua kunci kandidat yang berbeda dari suatu relasi untuk tumpang tindih keduanya harus terdiri dari lebih dari satu atribut, yaitu: untuk setiap pasangan kunci kandidat yang tumpang tindih A - (A ∩ B) harus non-kosong dan B - (A ∩ B ) harus tidak kosong.

Tiga FD pertama bergabung untuk diberikan

MNOP -> L

jadi MNOP adalah salah satu kunci kandidat yang mungkin, CK1.

Demikian pula tiga FD terakhir bergabung untuk memberi

NOPL -> M

jadi NOPL adalah kunci kandidat lain yang mungkin, CK2.

Namun CK1 dan CK2 memiliki kolom NOP yang sama, membuat mereka tumpang tindih kunci kandidat.

Untuk memeriksa apakah suatu relasi memiliki ketergantungan ketergantungan Kandidat kunci yang tumpang tindih:

Periksa apakah ada ketergantungan di mana kunci Kandidat Lengkap menentukan Bagian dari kunci Kandidat. Kemudian ketergantungan OCK berlaku