Qu'est-ce que la clé candidate qui se chevauche exactement?

Quelqu'un peut-il m'expliquer en termes simples ce que c'est overlapping candidate key? Qu'est-ce overlappingque son nom l'indique?

Considérez la relation ci-dessous

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

Laquelle des dépendances fonctionnelles ci-dessus apporte la clé candidate qui se chevauche dans la relation ci-dessus?

Permet de limiter la discussion aux dépendances, je ne suis pas intéressé par BCNF pour le moment

Vous avez raison sur l'argent avec les clés de candidats possibles, vikkyhacks. Les clés candidates qui se chevauchent sont des clés candidates composites (composées de plusieurs attributs) avec au moins un attribut en commun. Vos clés candidates qui se chevauchent sont donc NM et NO (elles partagent N).

Explication supplémentaire de ce qui précède, initialement laissée dans les commentaires:

Toutes les clés candidates qui se chevauchent sont des groupes (par exemple deux ou plusieurs) clés candidates. Cela signifie que le premier critère est que votre relation Rdoit avoir plus d'une clé candidate (super clés minimales). Pour qu'une des clés candidates se chevauche, chacune d'elles (encore deux ou plus) doit remplir quelques conditions supplémentaires. 1) Ils doivent tous deux être des clés candidates composites. Ils doivent être constitués de plusieurs attributs, de sorte qu'une clé comme Ane se chevauchera jamais, mais ABpourrait chevaucher une autre clé. 2) Les clés composites doivent partager un attribut. ABchevauche avec ACet BDmais pas CDou EF.

Pour résumer: deux ou plusieurs ensembles d'attributs où 1) chaque ensemble est une clé candidate (super-clé minimale) pour la relation, 2) chaque ensemble est une clé composite (se compose de plus d'un attribut) et 3) un ou plusieurs de les attributs des clés composites chevauchent un attribut d'une autre clé dans l'ensemble. Vous pouvez donc exclure MNOPet NOPLsur la base qu'ils ne sont pas des super-clés minimales. Vous pouvez exclure Pet Lsur la base qu'il ne s'agit pas de clés composites (elles se composent d'un attribut). Vous vous retrouvez avec deux clés NOet NMqui partagent l'attribut N, vous avez donc terminé.

Exemple

Il peut également être utile d'avoir un exemple que vous pouvez vraiment comprendre. La seule fois où j'ai jamais vu où vous aurez des clés candidates qui se chevauchent, c'est lorsque vous avez 1) deux attributs qui se déterminent fonctionnellement (par exemple, une relation un à un entre Aet Boù en Aa une Bet en Ba une A) et 2) ces les attributs font partie des clés candidates composites.

Par exemple, dans certains systèmes, a en Customera un CreditCardet a CreditCardappartient à un Customer. Dans le tableau Locations, vous identifiez de manière unique un Rentalpar le EquipmentId, Dateet CustomerId. Pour plus de commodité, vous avez également stocké CreditCardsur cette table.

Cela signifie que les FD suivants détiennent:

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

Mais comme l'association est un à un, les FD suivants détiennent également:

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

Depuis CustomerIdet CreditCardpeut être utilisé de manière interchangeable pour identifier de manière unique votre client.

Dans le scénario ci-dessus, vous avez des clés candidates qui se chevauchent:

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

Ils se chevauchent car ils sont des clés composites (ils se composent de plusieurs attributs) et parce qu'au moins un de leurs attributs est partagé (dans ce cas, ils partagent les deux EquipmentIdet Date.

Vous avez dit que vous ne vous souciez pas pour BCNFle moment, mais pour ramener complètement cette maison à la maison, le scénario ci-dessus est la raison pour laquelle vous verrez parfois un tableau qui est dedans 3NFmais pas BCNF. Le tableau ci-dessus est dans 3NF, mais pas BCNF.

3NFautorise les FD où 1) le FD est trivial 2) le côté gauche du FD est une clé candidate ou 3) le côté droit du FD est un attribut de clé (un attribut utilisé pour créer n'importe quelle clé). Étant donné que CreditCardet CustomerIdsont tous deux des attributs clés, tous les FD respectent 2 ou 3.

BCNFest très similaire, mais il n'autorise que les conditions 1 et 2 autorisées par 3NF. Puisque la 3ème condition n'est pas autorisée par BCNF, et les deux, CID -> CCet CC -> CIDutilise la condition 3, cette table ne l'est pas BCNF, mais elle l'est 3NF.

Pour des raisons pratiques, le cas est assez rare et cette information est pédante. Le cadeau que votre table a un problème sera le fait que les CreditCard/CustomerIdpaires sont répétées à travers votre table. Vous pouvez également reconnaître que la table ne serait même pas dans 2NFcette condition rare où le côté droit d'un FD peut être un attribut de clé car il CreditCards'agit d'une dépendance partielle de la clé primaire (cela dépend de CustomerIdmais pas EquipmentIdou Date.

Une clé candidate est un ensemble d'attributs qui constituent une super-clé minimale. On dit que deux clés candidates, A et B, se chevauchent si elles ont certains attributs en commun, c'est-à-dire: A ∩ B n'est pas vide. Dans votre cas, MN et NO chevaucheraient les clés candidates dans R.

En raison de l'exigence de minimalité (irréductibilité), une clé candidate ne peut jamais être un sous-ensemble d'une autre dans la même relation. Il s'ensuit que pour deux clés candidates distinctes d'une relation à chevaucher, les deux doivent être constituées de plus d'un attribut, c'est-à-dire que pour toute paire de clés candidates qui se chevauchent, A - (A ∩ B) doit être non vide et B - (A ∩ B ) doit être non vide.

Les trois premiers FD se combinent pour donner

MNOP -> L

MNOP est donc une clé candidate possible, CK1.

De même, les trois derniers FD se combinent pour donner

NOPL -> M

donc NOPL est une autre clé candidate possible, CK2.

Cependant, CK1 et CK2 ont des colonnes NOP en commun, ce qui les fait se chevaucher les clés candidates.

Pour vérifier si une relation a une dépendance de clé candidate qui se chevauche:

Vérifiez s'il existe une dépendance où une clé de candidat complet détermine une partie de la clé de candidat. Ensuite, la dépendance OCK tient