Una dipendenza funzionale completa è uno stato di normalizzazione del database che equivale allo standard di normalizzazione di Second Normal Form (2NF). In breve, ciò significa che soddisfa i requisiti di First Normal Form (1NF) e che tutti gli attributi non chiave dipendono completamente dalla chiave primaria.
Non è così complicato come potrebbe sembrare. Diamo un'occhiata a questo in modo più dettagliato.
Riepilogo della prima forma normale
Prima che un database possa essere completamente funzionalmente dipendente, deve prima essere conforme al Primo modulo normale.
Tutto ciò significa che ogni attributo deve contenere un singolo valore atomico.
Ad esempio, la seguente tabella fa non rispettare 1NF, perché il dipendente Tina è collegato a due posizioni, entrambe in una singola cella:
| Dipendente | Posizione |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Consentire questo design potrebbe influire negativamente sugli aggiornamenti o le voci dei dati. Per garantire la conformità 1NF, riorganizzare la tabella in modo che tutti gli attributi (o celle di colonna) mantengano un singolo valore:
Prima conformità alla forma normale
Ma 1NF non è ancora abbastanza per evitare problemi con i dati.
Come funziona 2NF per garantire la piena dipendenza
Per essere completamente dipendenti, tutti gli attributi chiave non candidati devono dipendere dalla chiave primaria. (Ricordare, un attributo chiave candidato è una chiave qualsiasi (ad esempio, una chiave primaria o esterna) utilizzata per identificare univocamente un record del database.
I progettisti di database utilizzano una notazione per descrivere le relazioni dipendenti tra attributi:
Se l'attributo A determina il valore di B, lo scriviamoA -> B- significa che B è funzionalmente dipendente da A. In questa relazione, A determina il valore di B, mentre B dipende da A.
Ad esempio, nel seguito Dipartimenti dei dipendenti tabella, EmployeeID e DeptID sono entrambe le chiavi candidate: EmployeeID è la chiave primaria della tabella mentre DeptID è una chiave esterna.
Qualsiasi altro attributo, in questo caso, EmployeeName e DeptName, deve dipendere dalla chiave primaria per ottenerne il valore.
| Numero Identità dell'impiegato | Nome dipendente | deptid | Nome_Dip |
|---|---|---|---|
| Emp1 | John | Dept001 | Finanza |
| Emp2 | Tina | Dept003 | I saldi |
| Emp3 | Carlos | Dept001 | Finanza |
In questo caso, la tabella non dipende completamente perché, mentre EmployeeName dipende dalla chiave primaria EmployeeID, DeptName dipende invece dal DeptID. Questo è chiamato dipendenza parziale .
Per rendere questa tabella conforme a 2NF, dobbiamo separare i dati in due tabelle:
| Numero Identità dell'impiegato | Nome dipendente | deptid |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Rimuoviamo l'attributo DeptName dal I dipendenti tabella e creare una nuova tabella dipartimenti :
| deptid | Nome_Dip |
|---|---|
| Dept001 | Finanza |
| Dept002 | Risorse umane |
| Dept003 | I saldi |
Ora le relazioni tra le tabelle sono completamente dipendenti o in 2NF.
Perché la piena dipendenza è importante
La piena dipendenza tra gli attributi del database aiuta a garantire l'integrità dei dati ed evitare anomalie dei dati.
Ad esempio, considera la tabella nella sezione precedente che aderisce solo a 1NF. Eccolo, ancora:
| Dipendente | Posizione |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina ha due dischi. Se aggiorniamo uno senza renderci conto che ce ne sono due, il risultato sarebbe dati incoerenti.
Oppure, cosa succede se vogliamo aggiungere un dipendente a questo tavolo, ma non conosciamo ancora la posizione? Potremmo non essere autorizzati a aggiungere un nuovo dipendente se l'attributo Posizione non consente valori NULL.
La piena dipendenza non è l'intera immagine, tuttavia, quando si tratta di normalizzazione. È necessario assicurarsi che il database sia in Terza forma normale (3NF).
