QUAL È LA TERZA FORMA NORMALE? (BANCHE DATI) - TECNOLOGIA - 2024

La terza forma normale (database) è una tecnica di progettazione di database relazionali, in cui le diverse tabelle che lo compongono non solo rispettano la seconda forma normale, ma tutti i suoi attributi o campi dipendono direttamente dalla chiave primaria.

Quando si progetta un database, l'obiettivo principale è creare una rappresentazione accurata dei dati, delle relazioni tra loro e delle limitazioni sui dati rilevanti.

Fonte: pixabay.com

Per raggiungere questo obiettivo, è possibile utilizzare alcune tecniche di progettazione di database, tra cui la normalizzazione.

Si tratta di un processo di organizzazione dei dati in un database per evitare ridondanze e possibili anomalie nell'inserimento, aggiornamento o eliminazione dei dati, generando un disegno semplice e stabile del modello concettuale.

Inizia esaminando la relazione funzionale o la dipendenza tra gli attributi. Questi descrivono alcune proprietà dei dati o la relazione tra loro.

Forme normali

La normalizzazione utilizza una serie di test, denominati moduli normali, per identificare il raggruppamento ottimale di questi attributi e, infine, stabilire la serie appropriata di relazioni che supportano i requisiti di dati di un'azienda.

Cioè, la tecnica di normalizzazione è costruita attorno al concetto di forma normale, che definisce un sistema di vincoli. Se una relazione soddisfa i vincoli di una particolare forma normale, si dice che la relazione sia in quella forma normale.

Prima forma normale (1FN)

Si dice che una tabella sia in 1FN se tutti gli attributi o i campi al suo interno contengono solo valori univoci. Cioè, ogni valore per ogni attributo deve essere indivisibile.

Per definizione, un database relazionale sarà sempre normalizzato alla prima forma normale, perché i valori degli attributi sono sempre atomici. Tutte le relazioni in un database sono in 1FN.

Tuttavia, semplicemente lasciare il database in questo modo stimola una serie di problemi, come la ridondanza e possibili errori di aggiornamento. Per correggere questi problemi sono state sviluppate forme normali superiori.

Seconda forma normale (2FN)

Si occupa della rimozione delle dipendenze circolari da una tabella. Si dice che una relazione sia in 2FN se è in 1FN e inoltre ogni campo o attributo non chiave dipende interamente dalla chiave primaria, o più specificamente, assicura che la tabella abbia un unico scopo.

Un attributo non chiave è qualsiasi attributo che non fa parte della chiave primaria di una relazione.

Terza forma normale (3FN)

Si occupa di eliminare le dipendenze transitive da una tabella. Ovvero, rimuovere gli attributi non chiave che non dipendono dalla chiave primaria, ma da un altro attributo.

Una dipendenza transitiva è un tipo di dipendenza funzionale in cui il valore di un campo o attributo non chiave è determinato dal valore di un altro campo che non è anch'esso chiave.

Cerca valori ripetuti negli attributi non chiave per assicurarti che questi attributi non chiave non dipendano da qualcosa di diverso dalla chiave primaria.

Si dice che gli attributi siano reciprocamente indipendenti se nessuno di essi dipende funzionalmente da una combinazione di altri. Questa indipendenza reciproca garantisce che gli attributi possano essere aggiornati individualmente, senza il pericolo di influenzare un altro attributo.

Pertanto, affinché una relazione in un database sia nella terza forma normale, deve essere conforme a:

- Tutti i requisiti di 2FN.

- Se sono presenti attributi non legati alla chiave primaria, è necessario rimuoverli e collocarli in una tabella separata, mettendo in relazione entrambe le tabelle tramite una chiave esterna. Cioè, non dovrebbero esserci dipendenze transitive.

Esempi di terza forma normale

Esempio 1

Sia la tabella STUDENT, la cui chiave primaria è l'identificazione dello studente (STUDENT_ID) ed è composta dai seguenti attributi: STUDENT_NAME, STREET, CITY e POST_CODE, che soddisfano le condizioni per essere 2FN.

In questo caso STREET e CITY non hanno una relazione diretta con la chiave primaria STUDENT_ID, poiché non sono direttamente correlate allo studente, ma sono totalmente dipendenti dal codice postale.

Poiché lo studente si trova nel sito determinato da CODE_POSTAL, STREET e CITY sono correlate con questo attributo. A causa di questo secondo grado di dipendenza, non è necessario memorizzare questi attributi nella tabella STUDENT.

Crea una nuova tabella

Supponiamo che ci siano più studenti situati nello stesso codice postale, con la tabella STUDENTE che ha un'enorme quantità di record, ed è necessario cambiare il nome della via o della città, quindi questa via o città deve essere trovata e aggiornata nell'intera tabella ALUNNO.

Ad esempio, se devi cambiare la strada "El Limón" in "El Limón II", dovrai cercare "El Limón" nell'intera tabella STUDENTE e quindi aggiornarla in "El Limón II".

La ricerca in una tabella enorme e l'aggiornamento di uno o più record richiederà molto tempo e quindi influirà sulle prestazioni del database.

Invece, questi dettagli possono essere conservati in una tabella separata (POSTCARD) correlata alla tabella STUDENT utilizzando l'attributo POST_CODE.

La tabella POST avrà un numero relativamente inferiore di record e questa tabella POST dovrà essere aggiornata solo una volta. Ciò si rifletterà automaticamente nella tabella STUDENT, semplificando il database e le query. Quindi i tavoli saranno in 3FN:

Esempio 2

Consentire la seguente tabella essere utilizzata con il campo Project_Num come chiave primaria e con valori ripetuti in attributi che non sono chiavi.

Il valore Telefono viene ripetuto ogni volta che viene ripetuto il nome di un manager. Questo perché il numero di telefono ha solo una dipendenza di secondo grado dal numero di progetto. Dipende innanzitutto dal manager e questo a sua volta dipende dal numero del progetto, il che crea una dipendenza transitiva.

L'attributo Project_Manager non può essere una possibile chiave nella tabella Projects perché lo stesso manager gestisce più di un progetto. La soluzione per questo è rimuovere l'attributo con i dati ripetuti (Telefono), creando una tabella separata.

Gli attributi corrispondenti devono essere raggruppati insieme, creando una nuova tabella per salvarli. I dati vengono inseriti e viene verificato che i valori ripetuti non fanno parte della chiave primaria. La chiave primaria viene impostata per ogni tabella e, se necessario, vengono aggiunte chiavi esterne.

Per rispettare la terza forma normale, viene creata una nuova tabella (Manager) per risolvere il problema. Entrambe le tabelle sono correlate tramite il campo Project_Manager:

Riferimenti

1. Teradata (2019). Prima, seconda e terza forma normale. Tratto da: docs.teradata.com.
2. Coppa Tutorial (2019). Terza forma normale (3NF). Tratto da: tutorialcup.com.
3. Database Dev (2015). Terza forma normale (3NF): normalizzazione del database. Tratto da: databasedev.co.uk.
4. Progettazione DB relazionale (2019). Introduzione alla terza forma normale. Tratto da: relationaldbdesign.com.
5. Manichini (2019). SQL prima, seconda e terza forma normale. Tratto da: dummies.com.