[Database] Chiarimenti sulla Terza Forma Normale

[UnknownSoldier]

Salve a tutti. Proprio non mi entra in testa la terza forma di normalizzazione

Ricapitoliamo le prime 2:

1- Ogni attributo deve contenere valori atomici

2- Bisogna rispettare la prima forma e creare una nuova tabella nel caso in cui si trovino attributi non legati alla chiave primaria completa, ad esempio:

Libri:{ISBN, titolo, annoPubblicazione, nomeEditore, pivaEditore}
con ISBN chiave primaria

E' chiaro che editore e la sua partita iva non sono legate alla chiave primaria ISBN quindi si creano due tabelle:

Libri:{ISBN, titolo, annoPubblicazione}
Editori:{nomeEditore, pivaEditore}

Ma la terza forma normale in cosa consiste? Ho letto svariate guide e mi è sembrata identica alla seconda... qualcuno può spiegarmi meglio come funziona?

[morskott]

Per quanto ricordi (ho fatto ste cose tipo 1-2 annetti fa) la terza FN è quella transitiva, se hai in Tab(A,B,C) un A->B->C con A chiave e B NON chiave splitti le tabelle in Tab1(A,B) e Tab2(B,C)

[UnknownSoldier]

Originariamente inviato da morskott

Per quanto ricordi (ho fatto ste cose tipo 1-2 annetti fa) la terza FN è quella transitiva, se hai in Tab(A,B,C) un A->B->C con A chiave e B NON chiave splitti le tabelle in Tab1(A,B) e Tab2(B,C)

Quel "->" vuol dire che il precedente determina il successivo?

[MarcoGG]

Originariamente inviato da UnknownSoldier

Ricapitoliamo le prime 2:

1- Ogni attributo deve contenere valori atomici

2- Bisogna rispettare la prima forma e creare una nuova tabella nel caso in cui si trovino attributi non legati alla chiave primaria completa, ad esempio:

Libri:{ISBN, titolo, annoPubblicazione, nomeEditore, pivaEditore}
con ISBN chiave primaria

E' chiaro che editore e la sua partita iva non sono legate alla chiave primaria ISBN quindi si creano due tabelle:

Libri:{ISBN, titolo, annoPubblicazione}
Editori:{nomeEditore, pivaEditore}

Nel tuo caso forse il DB di esempio è un po' troppo semplice in partenza per apprezzare tutti i risultati intermedi...

Anzitutto, il DB così com'è non risponderebbe nemmeno alla FN1, in quanto "nomeEditore" è ambiguo ( nomeEditore = nome + cognome ), e non rispetterebbe l'atomicità.

La Seconda Forma Normale richiede che il DB :
1. Sia in FN1.
2. Le colonne che non compongono la chiave dipendono funzionalmente da essa.
Il che significa che può bastare che dipendano funzionalmente anche in modo indiretto.

Perciò il tuo DB alla FN2 dovrebbe essere ancora :
Libri : {ISBN, titolo, annoPubblicazione, cognomeEditore, nomeEditore, pivaEditore} con ISBN Pk.

pivaEditore ad esempio dipende in modo indiretto da ISBN, in quanto in mezzo ci sono cognomeEditore e nomeEditore, che, a ben vedere, dipendono da titolo, non strettamente da ISBN... C'è infatti una "catena" di dipendenze transitive, e la FN3 serve a spezzare questa catena...

La Terza Forma Normale richiede che il DB :
1. Sia in FN2.
2. Le colonne che non compongono la chiave dipendono funzionalmente da essa in modo diretto.

Questo comporta che :
1. Non potrò più avere libri ed editori nella stessa tabella.
2. Dovrò inventarmi un campo PK per la tabella Editori, in quanto pivaEditore non può dipendere funzionalmente e in modo diretto da nomeEditore o cognomeEditore...

Perciò alla FN3 :
Libri: {ISBN (PK), titolo, annoPubblicazione, idEditore(FK)}
Editori: {idEditore(PK), cognomeEditore, nomeEditore, pivaEditore}

Il passo successivo sarà dare la possibilità di gestire Libri con più di un editore ( il che è sempre possibile... ) creando un tabella di raccordo "LibriEditori"... a quel punto la normalizzazione sarà finita.

Se vuoi un bell'esempio di normalizzazione in tema di Libri / Autori / Prestiti, con un DB più complesso, dai un'occhiata qui :
http://msdn.microsoft.com/it-it/library/cc185095.aspx

[morskott]

Originariamente inviato da UnknownSoldier

Quel "->" vuol dire che il precedente determina il successivo?

A->B vuol dire che A implica B, in termini di DB, A è una superchiave (se A è fissato allora fissa il valore di B)