Anagrafica (nome, cognome, indirizzo, CAP, citta, provincia, regione, telefono, nazione)

INDIVIDUAZIONE CHIAVE PRIMARIA

Anagrafica (nome (pk), cognome(pk), indirizzo(pk), CAP, citta, provincia, regione, telefono, nazione)

Ipotizzando che allo stesso indirizzo non possano abitare omonimi (nonno-nipote, ecc.). Miglior
compromesso possibile (telefono non può essere pk perché il suo valore può cambiare nel tempo, altra
possibilità sarebbe PK formata da nome, cognome, telefono ma renderebbe molto complessa la risoluzione
dell’esercizio)

1FN

Il database è in 1FN perché tutti i suoi attributi sono atomici

DIPENDENZE FUNZIONALI

Regola importante: fate sempre in modo di avere a destra delle frecce tutti gli attributi NON chiave (tutti gli
attributi NON chiave devono dipendere da uno o più attributi).

Città-->Provincia Nome, cognome, indirizzo --> Telefono

Provincia --> Regione Indirizzo, Città --> CAP

Regione --> Nazione Indirizzo, CAP --> Città

LE ULTIME DUE DIPENDENZE (SOTTOLINEATE E IN GRASSETTO) SONO UN GROSSO PROBLEMA PERCHÈ

SONO ANCHE RECIPROCHE E COMPLICANO INFINITAMENTE LA NOSTRA SOLUZIONE. PER QUESTO MOTIVO
TORNIAMO INDIETRO AL PRIMO STEP: RIDEFINIAMO LA CHIAVE PRIMARIA!

Anagrafica (nome (pk), cognome(pk), indirizzo(pk), CAP, citta (pk), provincia, regione, telefono, nazione)

In questo modo l’ultima dipendenza funzionale non la scriviamo e le cose ci risultano più semplici.

2FN

Il DB non è in 2FN perché CAP dipende solo da una parte della chiave primaria composta. Le altre
dipendenze funzionali non influiscono sulla 2FN perché i determinanti NON sono parte della chiave
primaria (L’ultima dipendenza funzionale l’abbiamo cancellata perché abbiamo ridefinito la chiave
primaria). Dopo aver risolto il problema derivato dall’ultima dipendenza funzionale ne sorge uno nuovo
dovuto alla prima dipendenza funzionale: nel frattempo Città è diventato parte di una chiave primaria e
quindi quella dipendenza funzionale viola i requisiti della 2FN.

Per riportarlo alla 2FN scriviamo:

ANAGRAFICA (Nome (pk), Cognome (pk), Indirizzo (pk), città (pk), Telefono)

RESIDENZA (Indirizzo (pk), Città (pk), Regione, Nazione, CAP)

CITTA (Citta(pk), Provincia)

3FN

Il DB non è in 3FN a causa della seconda e terza dipendenza funzionale (nella colonna di sinistra).

Per riportare tutto in 3FN scriviamo:

ANAGRAFICA (Nome (pk), Cognome (pk), Indirizzo (pk), città (pk), Telefono)

RESIDENZA (Indirizzo (pk), Città (pk), Regione, Nazione, CAP)

CITTA (Citta(pk), Provincia(fk))

PROVINCIA(Provincia(pk), Regione(fk))

REGIONE (Regione(pk), Nazione)

INTERROGAZIONI (materia, voto, data, nome, cognome, classe, sezione)

INDIVIDUAZIONE CHIAVE PRIMARIA

In questa fase è necessario fare una scelta di semplificazione: in teoria, tutto tranne il voto, potrebbe costituire
chiave primaria ma questo, chiaramente, renderebbe la risoluzione del nostro esercizio un vero inferno. Io (ma
ciascuno di voi può fare altre scelte, basta che siano ben spiegate) scelgo la chiave primaria come nello schema
seguente. In questo modo, ipotizzo che NON ci siano in classi diverse due alunni con lo stesso nome e cognome.

[Considerate che, in quanto a scelte di normalizzazione, il DB della nostra scuola è fatto anche peggio di così: la
vostra ex prof.ssa di Matematica, sul Registro Elettronico, si chiama “Giovanna IngravalloL” perché c’è una
collega con il suo stesso nome e cognome ed evidentemente, i tecnici della Spaggiari hanno ritenuto che
nome+cognome fosse una buona scelta per una chiave primaria per la tabella DOCENTI: non è possibile creare
due docenti con lo stesso nome+cognome nella stessa scuola!]

INTERROGAZIONI (materia (pk), voto, data (pk), nome (pk), cognome (pk), classe, sezione)

1FN

Il database non è in 1FN perché c’è data e quindi lo riportiamo a questa forma

INTERROGAZIONI (materia (pk), voto, giorno (pk), mese (pk), anno(pk), nome (pk), cognome (pk), classe, sezione)

DIPENDENZE FUNZIONALI

Materia, Giorno, Mese, Anno, Nome, Cognome --> Voto

Nome, Cognome --> Classe, Sezione

2FN

Il DB non è in 2FN a causa della seconda dipendenza funzionale quindi scriviamo:

INTERROGAZIONI (materia (pk), voto, giorno (pk), mese (pk), anno(pk), nome (pk), cognome (pk))

ALUNNI(nome(pk), cognome(pk), classe, sezione)

3FN

Il DB è già in 3FN

Questa è la mia soluzione che dipende dalla mia scelta di chiave primaria: diverse scelte di chiave
primaria derivanti da diverse ipotesi o semplificazioni (ben spiegate) portano a differenti soluzioni
CD Musicali (gruppo, titolo, canzone1, canzone2, … canzoneN, genere, lingua)
Quando ci sono degli attributi x1, x2,…,xn bisogna SEPARARLI dal resto della tabella (lo leggo a pagina 580 del
PDF sulle forme normali: “Separiamo ora dalla tabella principale i gruppi di campi che si ripetono, altrimenti
avremo delle celle della tabella con più valori, e quindi non in 1NF.”

CD Musicali (gruppo, titolo, genere, lingua)

Canzoni (Canzone)

INDIVIDUAZIONE CHIAVE PRIMARIA

CD Musicali (gruppo(pk), titolo (pk), genere, lingua)

Canzoni (Canzone (pk), gruppo(fk), titolo(fk))

Chiaramente sto ipotizzando che un gruppo non possa incidere due CD con lo stesso titolo.

1FN

Non ci sono attributi composti quindi è in 1FN

DIPENDENZE FUNZIONALI

Canzone --> Genere, Lingua

Attenzione: secondo me, un gruppo può cantare canzoni di generi e lingue diverse. È solo la canzone a
determinare il valore di queste caratteristiche (anche se, andando per il sottile, può essere incisa in altre lingue o
seguendo generi diversi ma NON andiamo per il sottile)

2FN

Sembra strano ma il DB è in 2FN perché genere e lingua NON dipendono proprio dalla chiave primaria

3FN

Il DB NON è in 3FN a causa della dipendenza funzionale che ho scritto quindi ristrutturando otteniamo:

CD Musicali (gruppo(pk), titolo (pk))

Canzoni (Canzone (pk), gruppo(fk), genere, lingua, titolo(fk))

Animali (cod_Anagrafico, razza, nome_Proprio, sesso, data_Nascita, luogo_Nascita, nazione)

INDIVIDUAZIONE CHIAVE PRIMARIA

Animali (cod_Anagrafico (pk), razza, nome_Proprio, sesso, data_Nascita, luogo_Nascita, nazione)

1FN

Animali (cod_Anagrafico (pk), razza, nome_Proprio, sesso, giorno_Nascita, mese_Nascita, anno_Nascita,

luogo_Nascita, nazione)

DIPENDENZE FUNZIONALI

cod_Anagrafico --> razza, nome_Proprio, sesso, giorno_Nascita, mese_Nascita, anno_Nascita, luogo_Nascita

luogo_Nascita --> Nazione

2FN

La chiave primaria è semplice quindi il DB è già in 2FN se è in 1FN

3FN

La seconda dipendenza funzionale viola i principi della 2FN quindi ristrutturiamo così:

Animali (cod_Anagrafico (pk), razza, nome_Proprio, sesso, giorno_Nascita, mese_Nascita, anno_Nascita,

luogo_Nascita (fk))

Luoghi (Luogo_Nascita (pk), Nazione)

Dipendenti (matricola, nominativo, stipendio, progetto, cod_Bilancio, funzione, sede)

INDIVIDUAZIONE CHIAVE PRIMARIA

Dipendenti (matricola (pk), nominativo, stipendio, progetto, cod_Bilancio, funzione, sede)

1FN

Abbiamo chiaramente nominativo e sede che non sono atomici quindi riscriviamo così

Dipendenti (matricola (pk), nome, cognome, stipendio, progetto, cod_Bilancio, funzione, indirizzo, città)

CAP non lo metto altrimenti fare le dipendenze funzionali diventa estremamente noioso (come abbiamo visto
stamattina)

DIPENDENZE FUNZIONALI

Matricola --> nome, cognome, stipendio

cod_Bilancio --> progetto, indirizzo, città

Matricola, cod_Bilancio --> funzione (un dipendente può stare in diversi progetti con funzioni diverse)

2FN

Chiaramente siamo in 2FN perché la chiave è semplice

3FN

Non siamo in 3FN perché ci sono attributi che non dipendono da Matricola. Riscriviamo così:

DIPENDENTI (Matricola(pk), Nome, Cognome, Stipendio, Funzione, Cod_Bilancio(fk))

PROGETTI(Cod_Bilancio(pk), Progetto, Indirizzo, città)

Come la precedente, questa è la MIA soluzione: voi potete trovare differenti dipendenze (basta che siano
corrette): per esempio, avreste potuto scrivere che indirizzo e città dipendono da Matricola e Cod_Bilancio
perché un dipendente si sposta in diverse sedi in base al progetto a cui deve lavorare e per me andava bene lo
stesso (chiaramente lo schema finale sarebbe stato differente).

Fornitori (fornitore, indirizzo, numero_Fat, data, descrizione, quantità, prezzo_Unitario)

INDIVIDUAZIONE CHIAVE PRIMARIA

Supponendo che ogni fornitore abbia un nome univoco, scrivo:

Fornitori (fornitore (pk), indirizzo, numero_Fat, data, descrizione, quantità, prezzo_Unitario)

1FN

Indirizzo potrebbe crearmi dei problemi: o lo lascio così oppure scrivo

Fornitori (fornitore (pk), indirizzo, città, numero_Fat, data, descrizione, quantità, prezzo_Unitario)

DIPENDENZE FUNZIONALI

Fornitore --> indirizzo, città

Numero_Fat --> data

Descrizione --> prezzo_Unitario (Qui sto facendo un’ipotesi abbastanza forte ma è l’unica cosa che posso fare
data la carenza di attributi che la traccia mi propone: sto ipotizzando che la descrizione di un articolo sia la sua
chiave primaria cioè che un singolo articolo sia identificato dalla sua descrizione; è come se gli articoli venduti su
Amazon fossero identificati dal loro nome e non dal codice ASIN o altri modi che loro usano per identificarli.
Purtroppo, me lo devo tenere in questo modo perché NON posso aggiungere attributi a quelli proposti dalla
traccia)

Numero_Fat, Descrizione --> quantità

2FN

La chiave primaria è semplice quindi, essendo in 1FN è automaticamente anche in 2FN

3FN

Non è in 3FN a causa di alcune dipendenze funzionali quindi ristrutturo così:

FORNITORI (fornitore (pk), indirizzo, città)

FATTURE (numero_Fat (pk), data, descrizione (fk), quantità)

PRODOTTI (Descrizione (pk), prezzo_Unitario, fornitore(fk))

Qui sono andato anche un po’ “a senso” per inserire le chiavi esterne oltre che seguendo le regole. Va bene farlo
per ottenere un risultato finale soddisfacente.

In questo esercizio era ammissibile, all’inizio, anche considerare numero_Fat come attributo multiplo (come
Canzone1,…CanzoneN) dei CD Musicali dell’esempio precedente. Il risultato sarebbe stato presumibilmente lo
stesso alla fine.