Se una tabella con una chiave surrogata ha una colonna nota per avere valori non nulli univoci (ad esempio SSN), viola 3NF?

A quanto ho capito, la terza forma normale (3NF) significa sostanzialmente che dovrebbe esserci esattamente una chiave.

Se una tabella che indica una idcolonna di incremento automatico ha anche una colonna nota per essere univoca e non nulla, ad esempio un numero di previdenza sociale, questa colonna potrebbe essere utilizzata come chiave.

Ignorare i problemi pratici / aziendali (ad es. Rischio di sicurezza / privacy quando si passa a SSN come chiave / FK), da un aspetto strettamente progettuale dello schema, una tabella del genere non sarebbe in 3NF perché ci sono effettivamente 2 chiavi?

La risposta varierebbe se esistesse una chiave univoca sull'altra colonna? Se è così, perché?

Una relazione R è in terza forma normale se ogni attributo non primo di R dipende non transitivamente da ogni chiave candidata di R

EFCodd, 1971, Ulteriore normalizzazione del modello relazionale della base di dati

È implicito nella definizione di una relazione che una relazione deve avere almeno una chiave. Nulla di 3NF o di qualsiasi altra forma normale richiede che una relazione debba avere una sola chiave.

Sfortunatamente, i libri sulla progettazione e la normalizzazione dei database contengono numerosi esempi di relazioni con una sola chiave e piuttosto meno esempi con più di una chiave. Questo mi sembra strano dato che oggigiorno più chiavi sembrano essere una pratica molto comune. La scarsità di esempi pratici nella letteratura non accademica sembra essere una delle cause di confusione sul ruolo delle chiavi nella progettazione del database. Un'altra causa di confusione è il popolare mnemonico "nient'altro che la chiave". Quella frase è generalmente attribuita a Bill Kent ma non è una definizione accurata di 3NF.

Poiché la domanda si basa sull'interpretazione di una regola, dovremmo prima guardare a quell'informazione collegata, che è (enfatizzare la mia):

2. tutti gli attributi in una tabella sono determinati solo dalle chiavi candidate di quella tabella e non da attributi non primi.

Penso che la confusione sia il risultato di un'interpretazione errata del termine "chiavi candidate". Possono esserci più chiavi candidate in una tabella. Questo è il motivo per cui abbiamo termini modificatori da specificare ulteriormente in questo gruppo: Primario e Alternativo. Se le tabelle potessero avere una e una sola chiave, il termine "Chiave primaria" sarebbe fuorviante e avrebbe dovuto invece essere chiamato qualcos'altro (forse "Genitore" o "Origine" o "Identificazione", ecc.). Ma "Primario" implica che ci possono essere chiavi "secondarie", e quelle sono chiamate chiavi "alternative".

Le chiavi alternative sono indicate nei modelli fisici tramite un vincolo univoco o un indice univoco. Va anche notato che entrambi i tipi di chiavi candidate (primaria e alternativa) possono essere referenziati da chiavi esterne (anche se generalmente non si dovrebbe / non si dovrebbe fare una cosa del genere senza un motivo molto valido!).

La risposta varierebbe se esistesse una chiave univoca sull'altra colonna? Se è così, perché?

No, perché è una questione di modellazione fisica vs logica. Puoi avere una tabella che ha un IDENTITYcampo ma non è stata ancora definita una chiave primaria. La tabella e i suoi dati possono essere facilmente in 3NF, anche se il modello fisico non lo applica. Questa distinzione è simile alla definizione o meno di chiavi esterne. Puoi sicuramente unire le tabelle e non avere record orfani, indipendentemente dal fatto che siano stati definiti PK / FK. E i dati possono essere corretti al 100% senza quei costrutti. Ma avere PK e FK definiti è la differenza tra Integrità referenziale (logica) e Integrità referenziale dichiarativa (fisica). Avere i vincoli nel modello fisico aiuta semplicemente a far rispettare le regole del modello logico.

Per quanto riguarda SSN (" Numero di previdenza sociale " per coloro che non hanno familiarità con quell'acronimo), che è una chiave alternativa e con un indice / vincolo univoci su di esso:

Consiglierei di non considerare un SSN come una chiave alternativa e di inserire un vincolo o un indice univoci su di esso, anche se è comune farlo (SSN è spesso considerato una chiave "naturale" - quella che esiste nel mondo reale) . Ci sono due ragioni principali:

1. Precisione: il più delle volte, questi valori vengono inseriti in un sistema da qualcuno che compila un modulo, sia su carta che online. Le persone commettono errori durante l'immissione dei dati per tutto il tempo, soprattutto se la fonte era un modulo cartaceo che viene inserito da qualcuno che legge la scrittura sciatta di qualcun altro (come il mio, che è a malapena leggibile).

   Anche se i dati provengono da un altro sistema, puoi essere sicuro che il sistema di origine abbia convalidato le informazioni? Puoi essere sicuro che non ci sia stato un bug nell'esportazione dei dati? Cosa succede se è presente un bug nell'importazione dei dati?

2. Unicità: anche se la principale amministrazione della previdenza sociale non ha mai emesso un ID duplicato, ciò non significa che non sia avvenuta la duplicazione. Al di fuori delle questioni relative al furto di identità, ricordo di aver sentito anni fa qualcuno che aveva lavorato come DBA per il Dipartimento delle entrate degli Stati (credo) e che dovevano occuparsi delle prestazioni di sicurezza sociale, di come stessero avendo "problemi" riguardanti ciò che era un pratica precedente di riassegnare l'SSN di una persona deceduta al coniuge superstite (di solito la vedova) in modo che fosse più facile per il coniuge sopravvissuto continuare a riscuotere i pagamenti delle indennità. Sono sicuro che questa pratica è stata interrotta qualche tempo fa, ma i dati "duplicati" erano ancora nel sistema.

A quanto ho capito, la terza forma normale (3NF) significa sostanzialmente che dovrebbe esserci esattamente una chiave.

No. 2NF, 3NF e Boyce Codd Normal Form (BCNF) si occupano di dipendenze funzionali . Una tabella in 2NF indica che non vi sono dipendenze di chiavi parziali in cui una colonna non chiave dipende da un sottoinsieme corretto di una chiave multi-colonna. Tabelle come quella del nostro esempio sono già in 2NF poiché ogni chiave candidata è una singola colonna. Una tabella in 3NF significa che ogni colonna non chiave non dipende anche funzionalmente da qualche altra colonna non chiave e quindi crea una dipendenza transitiva. Non importa se ci sono una o cento chiavi candidate. In realtà è BCNF, non 3NF, che è la forma normale "finale" per quanto riguarda le dipendenze funzionali. Questo perché una tabella può essere in 3NF ma non essere in BCNF poiché potrebbero esserci più chiavi candidate che si sovrappongono. Pertanto, quando usiamo il termine 3NF per indicare "completamente normalizzato" rispetto alle dipendenze funzionali, ciò che realmente intendiamo è BCNF.

Se una tabella che indica una colonna ID con incremento automatico ha anche una colonna nota per essere univoca e non nulla, ad esempio un numero di previdenza sociale, questa colonna potrebbe essere utilizzata come chiave.

Non solo potrebbe essere, esso deve essere, se vogliamo garantire che i dati memorizzati nel database rimane coerente con le norme che abbiamo identificato nel mondo reale!

Ignorare i problemi pratici / aziendali (ad es. Rischio di sicurezza / privacy quando si passa a SSN come chiave / FK), da un aspetto strettamente progettuale dello schema, una tabella del genere non sarebbe in 3NF perché ci sono effettivamente 2 chiavi?

Come spiegato sopra, se la tabella è o meno in 3NF (o, soprattutto, BCNF) è ortogonale a quante chiavi candidate contiene.

La risposta varierebbe se esistesse una chiave univoca sull'altra colonna? Se è così, perché?

No, semplicemente perché determinare se la tabella è o non è in 3NF non ha nulla a che fare con quante chiavi candidate ha. Ha invece tutto a che fare con la garanzia che tutte le colonne non chiave siano completamente funzionalmente dipendenti da quelle chiavi candidate.

Ma questo fa emergere un punto interessante. Si noti che una chiave univoca quando definita come vincolo in un DBMS non è la stessa di un identificatore univoco definito come regola aziendale in un modello aziendale concettuale. Forse nel nostro mondo conosciamo sempre l'SSN della persona e quindi funge da chiave candidata per una persona, e forse introduciamo anche una chiave surrogata nello schema logico che chiamiamo ID persona . Il nostro modello di business include la regola che afferma che SSN è un identificatore univoco per una persona nel nostro mondo. Ciò implica una dipendenza funzionaledi tutti gli attributi descrittivi su questo attributo di identità. Questa regola non cambia solo perché ci siamo dimenticati o abbiamo scelto di non informare il DBMS. Questo è precisamente il motivo per cui è essenziale dichiarare il vincolo, in modo che il DBMS possa garantire che i dati memorizzati siano coerenti con le regole del modello di business! Se non abbiamo creato quel vincolo univoco su SSN, ora possiamo inavvertitamente creare più di una riga per la stessa persona con lo stesso SSN; ogni riga ha un ID persona diverso!

Un eccellente spunto su questi argomenti è la serie Practical Database Foundation di Fabian Pascal e la teoria del design e della relazione relazionale di Chris Date , da cui deriva questa risposta. Mentre ogni articolo di Fabian è un must, il documento n. 1 (che definisce chiaramente la differenza tra i livelli concettuale, logico e fisico) e il documento n. 4 (che definisce chiaramente i vari tipi di chiavi) affrontano specificamente questa domanda. Allo stesso modo, l'intero libro di Chris è assolutamente da leggere, mentre la Parte II è la sezione dedicata alla normalizzazione rispetto alla dipendenza funzionale.