Che cos'è esattamente la chiave candidata sovrapposta?

Qualcuno può spiegarmi in parole semplici cosa è overlapping candidate key? Come overlappingsuggerisce il nome?

Considera la relazione di seguito

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

Quale delle suddette dipendenze funzionali sta portando la chiave candidata sovrapposta nella relazione sopra?

Permettiamo di limitare la discussione alle dipendenze, al momento non sono interessato a BCNF

Hai ragione sul denaro con le possibili chiavi candidate, vikkyhacks. Le chiavi candidate sovrapposte sono chiavi candidate composte (composte da più di un attributo) con almeno un attributo in comune. Quindi le chiavi candidate sovrapposte sono NM e NO (condividono N).

Spiegazione aggiuntiva di quanto sopra, originariamente lasciato nei commenti:

Tutte le chiavi candidate sovrapposte sono gruppi di (ad esempio due o più) chiavi candidate. Ciò significa che il primo criterio è che la tua relazione Rdeve avere più di una chiave candidata (super chiavi minime). Affinché una qualsiasi delle chiavi candidate si sovrapponga, ciascuna di esse (di nuovo due o più) deve soddisfare alcune condizioni aggiuntive. 1) Entrambi devono essere chiavi candidate composte. Devono consistere di più di un attributo, quindi una chiave come Anon si sovrapporrà mai, ma ABpotrebbe sovrapporsi con un'altra chiave. 2) Le chiavi composite devono condividere un attributo. ABsi sovrappone a ACe BDma non CDo EF.

Riassumendo: due o più serie di attributi in cui 1) ogni serie è una chiave candidata (superkey minima) per la relazione, 2) ogni serie è una chiave composita (è composta da più di un attributo) e 3) una o più di gli attributi delle chiavi composite si sovrappongono con un attributo di un'altra chiave nell'insieme. Quindi puoi escludere MNOPe NOPLsulla base del fatto che non sono superkey minime. Puoi escludere Pe Lsulla base del fatto che non sono chiavi composte (sono costituite da un attributo). Ti rimangono due chiavi NOe NM, che condividono l'attributo N, hai finito.

Esempio

Può anche essere utile avere un esempio in cui puoi davvero avvolgere la testa. L'unica volta che ho mai visto dove avrai le chiavi candidate sovrapposte è quando hai 1) due attributi che si determinano funzionalmente l'un l'altro (ad es. Una relazione uno a uno tra Ae Bdove Aha uno Be ne Bha uno A) e 2) questi gli attributi fanno parte di chiavi candidate composte.

Ad esempio, in alcuni sistemi, a ne Customerha uno CreditCarde a CreditCardappartiene a uno Customer. Nella tabella Noleggi, identifichi in modo univoco a Rentalcon EquipmentId, Datee CustomerId. Per comodità, hai archiviato anche CreditCardsu questa tabella.

Ciò significa che valgono i seguenti FD:

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

Ma dal momento che l'associazione è uno a uno, valgono anche i seguenti FD:

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

Poiché CustomerIde CreditCardpuò essere utilizzato in modo intercambiabile per identificare in modo univoco il cliente.

Nello scenario sopra, hai le chiavi candidate sovrapposte:

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

Si sovrappongono perché sono chiavi composte (sono costituite da più di un attributo) e perché almeno uno dei loro attributi è condiviso (in questo caso, condividono entrambi EquipmentIde Date.

Hai detto che non ti interessa BCNFin questo momento, ma per portare completamente a casa questo, lo scenario sopra è il motivo per cui occasionalmente vedrai un tavolo che è dentro 3NFma non BCNF. La tabella sopra è in 3NF, ma non BCNF.

3NFconsente FD dove 1) l'FD è banale 2) il lato sinistro dell'FD è una chiave candidata o 3) il lato destro dell'FD è un attributo chiave (un attributo utilizzato per creare qualsiasi chiave). Poiché CreditCarde CustomerIdsono entrambi attributi chiave, tutti gli FD soddisfano 2 o 3.

BCNFè molto simile, ma consente solo le condizioni 1 e 2 consentite da 3NF. Dal momento che la terza condizione non è consentita da BCNFentrambe, CID -> CCed è la CC -> CIDcondizione 3, la tabella non BCNFlo è, ma lo è 3NF.

Ai fini pratici, il caso è piuttosto raro e questa informazione è pedante. L'omaggio che il tuo tavolo ha un problema sarà il fatto che le CreditCard/CustomerIdcoppie si ripetono sul tuo tavolo. Potresti anche riconoscere che la tabella non si troverebbe nemmeno 2NFsenza questa rara condizione in cui il lato destro di un FD potrebbe essere un attributo chiave perché CreditCardè una dipendenza parziale dalla chiave primaria (dipende da CustomerIdma non EquipmentIdo Date.

Una chiave candidata è un insieme di attributi che costituiscono una superkey minima. Si dice che due chiavi candidate, A e B, si sovrappongano se hanno alcuni attributi in comune, ovvero: A ∩ B non è vuoto. Nel tuo caso, MN e NO si sovrapporrebbero alle chiavi candidate in R.

A causa del requisito di minimalità (irriducibilità) una chiave candidata non può mai essere un sottoinsieme di un'altra nella stessa relazione. Ne consegue che per due chiavi candidate distinte di una relazione da sovrapporre entrambe devono essere costituite da più di un attributo, ovvero: per ogni coppia di chiavi candidate sovrapposte A - (A ∩ B) deve essere non vuota e B - (A ∩ B ) deve essere non vuoto.

I primi tre FD si combinano per dare

MNOP -> L

quindi MNOP è una possibile chiave candidata, CK1.

Allo stesso modo gli ultimi tre FD si combinano per dare

NOPL -> M

quindi NOPL è un'altra possibile chiave candidata, CK2.

Tuttavia CK1 e CK2 hanno colonne NOP in comune, rendendole sovrapposte alle chiavi candidate.

Per verificare se una relazione presenta una dipendenza chiave Candidate sovrapposta:

Verificare se esiste una dipendenza in cui una chiave Candidato completo sta determinando una parte di Chiave candidato. Quindi vale la dipendenza OCK