Что именно перекрывает кандидатный ключ?

Может кто-нибудь, пожалуйста, объясните мне в простых терминах, что это такое overlapping candidate key? Как следует overlappingиз названия?

Рассмотрим следующее соотношение

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

Какая из приведенных выше функциональных зависимостей привносит перекрывающийся ключ-кандидат в вышеприведенном отношении?

Давайте ограничимся обсуждением зависимостей, меня сейчас не интересует BCNF

Вы правы на деньги с возможными ключами-кандидатами, vikkyhacks. Перекрывающиеся ключи-кандидаты представляют собой составные (состоят из более чем одного атрибута) ключи-кандидаты, имеющие как минимум один общий атрибут. Таким образом, ваши перекрывающиеся ключи-кандидаты - это NM и NO (они разделяют N).

Дополнительные пояснения к вышесказанному, изначально оставленные в комментариях:

Все перекрывающиеся ключи-кандидаты являются группами (например, двух или более) ключей-кандидатов. Это означает, что первым критерием является то, что ваше отношение Rдолжно иметь более одного ключа-кандидата (минимальные супер-ключи). Чтобы любой из возможных ключей перекрывался, каждый из них (опять же два или более) должен удовлетворять нескольким дополнительным условиям. 1) Они оба должны быть составными ключами-кандидатами. Они должны состоять из более чем одного атрибута, поэтому такой ключ Aникогда не будет перекрываться, но ABможет перекрываться с другим ключом. 2) Составные ключи должны иметь общий атрибут. ABперекрывается ACи, BDно не CDили EF.

Подводя итог: два или более наборов атрибутов, где 1) каждый набор является ключом-кандидатом (минимальный суперключ) для отношения, 2) каждый набор является составным ключом (состоит из более чем одного атрибута), и 3) один или несколько из атрибуты составных ключей перекрываются с атрибутом другого ключа в наборе. Таким образом, вы можете исключить MNOPи NOPLна основании того, что они не минимальные суперключи. Вы можете исключить Pи Lна основании того, что они не являются составными ключами (они состоят из одного атрибута). Вы остались с двумя ключами, NOи NM, которые разделяют атрибут N, так что вы закончили.

пример

Это также может помочь иметь пример, который вы действительно можете обернуть вокруг. Единственный раз, когда я видел, где у вас будут перекрывающиеся ключи-кандидаты, это когда у вас есть 1) два атрибута, которые функционально определяют друг друга (например, отношение один-к-одному между Aи Bгде Aесть один Bи Bимеет один A) и 2) эти атрибуты являются частью составных ключей-кандидатов.

Например, в некоторой системе a Customerимеет один CreditCard, а a CreditCardпринадлежит одному Customer. В таблице Rentals вы однозначно определяете Rentalпо EquipmentId, Dateи CustomerId. Для удобства вы также сохранили CreditCardэту таблицу.

Это означает, что выполняются следующие FD:

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

Но поскольку ассоциация является взаимно-однозначной, также выполняются следующие FD:

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

Так как CustomerIdи CreditCardмогут быть использованы взаимозаменяемо для однозначной идентификации вашего клиента.

В приведенном выше сценарии у вас есть перекрывающиеся ключи-кандидаты:

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

Они перекрываются, потому что они являются составными ключами (они состоят из более чем одного атрибута) и потому, что по крайней мере один из их атрибутов является общим (в этом случае они совместно используют оба EquipmentIdи Date.

Вы сказали, что BCNFна данный момент вас это не волнует , но чтобы полностью привезти это домой, сценарий, приведенный выше, является причиной, по которой вы иногда будете видеть стол, в котором есть, 3NFно нет BCNF. Таблица выше есть 3NF, но нет BCNF.

3NFразрешает FD, где 1) FD тривиален 2) левая сторона FD является ключом-кандидатом или 3) правая сторона FD является атрибутом ключа (атрибут, используемый для создания любого ключа). Поскольку CreditCardи CustomerIdоба являются ключевыми атрибутами, все FD либо соответствуют 2 или 3.

BCNFочень похож, но он допускает только условия 1 и 2, разрешенные 3NF. Поскольку 3-е условие не разрешено BCNF, и оба CID -> CCи CC -> CIDиспользуют условие 3, эта таблица не является BCNF, но это так 3NF.

В практических целях случай довольно редок, и эта информация педантична. Отказ в том, что у вашей таблицы есть проблема, состоит в том, что CreditCard/CustomerIdпары повторяются по всей таблице. Вы также можете признать, что таблица даже не будет присутствовать 2NFбез этого редкого условия, когда правая сторона FD может быть ключевым атрибутом, потому что CreditCardэто частичная зависимость от первичного ключа (зависит, CustomerIdно не от EquipmentIdили Date.

Ключ-кандидат - это набор атрибутов, которые составляют минимальный суперключ. Говорят, что два возможных ключа, A и B, перекрываются, если они имеют некоторые общие атрибуты, то есть: A ∩ B не пусто. В вашем случае MN и NO будут перекрывать ключи-кандидаты в R.

Из-за требования минимальности (неприводимости) один ключ-кандидат никогда не может быть подмножеством другого в том же отношении. Отсюда следует, что для двух разных ключей-кандидатов отношения перекрытия оба должны состоять из более чем одного атрибута, то есть: для любой пары перекрывающихся ключей-кандидатов A - (A ∩ B) должны быть непустыми и B - (A ∩ B ) должен быть не пустым.

Первые три FD объединить, чтобы дать

MNOP -> L

поэтому MNOP является одним из возможных ключей-кандидатов, CK1.

Точно так же последние три ФО объединить, чтобы дать

NOPL -> M

таким образом, NOPL - другой возможный ключ-кандидат, CK2.

Однако CK1 и CK2 имеют общие столбцы NOP, что делает их перекрывающими ключи-кандидаты.

Чтобы проверить, имеет ли отношение перекрывающуюся зависимость ключа-кандидата:

Проверьте, есть ли какая-либо зависимость, когда ключ «Полный кандидат» определяет ключ «Часть кандидата». Тогда зависимость OCK имеет место