Normalizzazione in SQL: 1NF, 2NF, 3NF e BCNF

La normalizzazione è un processo sistematico volto a garantire che un modello di database relazionale sia efficiente, adatto per query generiche e privo di caratteristiche indesiderabili come anomalie di inserimento, aggiornamento e cancellazione, che portano alla perdita dell'integrità dei dati. Questo processo di normalizzazione aiuta anche a eliminare la ridondanza dei dati e riduce le possibilità di incoerenza dopo qualsiasi operazione di inserimento, aggiornamento o eliminazione.

Per una migliore comprensione, si consideri il seguente schema: Studente (Nome, Indirizzo, Materia, Voto)

Ci sono alcuni problemi o inefficienze in questo schema.

1) Ridondanza : L'indirizzo dello studente viene ripetuto per ogni materia a cui è iscritto.

2) Anomalia di aggiornamento : potremmo aver aggiornato l'indirizzo in una tupla (riga) lasciandolo invariato nelle altre righe. Quindi non avremmo un indirizzo univoco coerente per ogni studente.

3) Anomalia di inserimento : non registreremo l'indirizzo di uno studente senza essersi registrati per almeno una materia. Allo stesso modo, quando uno studente vuole iscriversi ad una nuova Materia, è possibile che venga inserito un Indirizzo diverso.

4) Anomalia di cancellazione : Se uno studente decide di interrompere tutte le materie iscritte, anche l'indirizzo dello studente andrà perso nel processo di cancellazione.

Pertanto, è importante rappresentare i dati dell'utente mediante relazioni che non creino anomalie a seguito di operazioni di aggiunta, cancellazione o aggiornamento di tuple. Ciò può essere ottenuto solo mediante un'attenta analisi dei vincoli di integrità, in particolare le dipendenze dei dati del database.

Le relazioni dovrebbero essere progettate in modo che siano raggruppati solo quegli attributi che esistono naturalmente insieme. Questo può essere fatto principalmente da una comprensione di base del significato di tutti gli attributi dei dati. Tuttavia, abbiamo ancora bisogno di alcune misure formali per garantire il nostro obiettivo di progettazione.

La normalizzazione è quella misura formale. Risponde alla domanda sul perché un particolare gruppo di attributi sarà migliore di qualsiasi altro.

Ad oggi esistono sette forme normali:

• Prima forma normale (1NF)
• Seconda forma normale (2NF)
• Terza forma normale (3NF)
• Forma normale Boyce-Codd (BCNF)
• Quarta forma normale (4NF)
• Quinta forma normale (5NF)
• Sesta o chiave di dominio Forma normale (6NF)

Leggi: Tipi di viste in SQL

Prima forma normale (1NF o forma minima)

• Non esiste un ordinamento dall'alto verso il basso per le righe e da sinistra a destra per le colonne.
• Non ci sono righe duplicate.
• Ogni intersezione di riga e colonna contiene esattamente un valore dal dominio applicabile o un valore nullo. Questa condizione indica che tutti i valori delle colonne devono essere atomici, scalari o contenere un solo valore. Qui non è consentita la ripetizione di informazioni o valori in più colonne.
• Tutte le colonne sono regolari (cioè le righe non hanno componenti nascosti come ID riga, ID oggetto o timestamp nascosti).

Prendiamo un esempio di uno schema che non è normalizzato. Supponiamo che un designer desideri registrare i nomi ei numeri di telefono dei clienti. Definiscono una tabella clienti come mostrato:

Qui, non è in 1 NF. La colonna Numeri di telefono non è atomica o non ha un valore scalare, cioè ha avuto più di un valore, che non può essere consentito in 1 NF.

Per farlo 1 NF

• Per prima cosa spezzeremo (scomporremo) il nostro singolo tavolo in due.
• Ogni tabella dovrebbe avere informazioni su una sola entità.

Gruppi ripetuti di numeri di telefono non si verificano in questo progetto. Al contrario, ogni collegamento da cliente a numero di telefono viene visualizzato nel proprio record.

Checkout: domande e risposte per le interviste SQL più comuni

Seconda forma normale

Ogni forma normale ha criteri più vincolanti rispetto al suo predecessore. Quindi qualsiasi tabella che si trova nella seconda forma normale (2NF) o superiore è, per definizione, anche in 1NF. D'altra parte, una tabella che si trova in 1NF può essere o meno in 2NF; se è in 2NF, può essere o meno in 3NF e così via.

Si dice che una tabella 1NF sia in 2NF se e solo se nessuno dei suoi attributi non primi dipende funzionalmente da una parte (sottoinsieme corretto) di una chiave candidata. (Un attributo non primo non appartiene a nessuna chiave candidata.)

Si noti che quando una tabella 1NF non ha chiavi candidate composite (chiavi candidate costituite da più di un attributo), la tabella è automaticamente in 2NF.

Verificare se una relazione R (A, B, C, D, E) con FD è impostata come {BC ? D, AC? ESSERE, B? E } è in 2NF?

• Come possiamo vedere, la chiusura di AC è (AC)+ = {A, C, B, E, D} applicando l'algoritmo di appartenenza. Ma nessuno dei suoi sottoinsiemi può determinare da solo tutti gli attributi della relazione, quindi AC è la chiave candidata per questa relazione. Inoltre, né A né C possono essere derivati ​​da qualsiasi altro attributo della relazione, quindi ci sarà solo 1 chiave candidata che è {AC}.
• Qui {A, C} sono gli attributi primi e {B, D, E} sono gli attributi non primi.
• La relazione R è già nella prima forma normale poiché un DBMS relazionale in 1NF non consente attributi multivalore o compositi.

AVANTI CRISTO ? D è in 2a forma normale perché BC non è un sottoinsieme proprio della chiave candidata AC,

CORRENTE ALTERNATA ? BE è in 2a forma normale poiché AC stessa è la chiave candidata e

B ? E è in 2a forma normale B non è un sottoinsieme appropriato della chiave candidata AC.

Quindi la relazione data R è nella 2a Forma Normale.

Terza forma normale

Si dice che una tabella sia in 3NF se e solo se per ciascuna delle sue dipendenze funzionali.

X → A , vale almeno una delle seguenti condizioni:

• X contiene A (cioè, X → A è una dipendenza funzionale banale), o
• X è una super chiave, o
• A è un attributo primo (cioè, A è presente all'interno di una chiave candidata)

Un'altra definizione di 3NF afferma che ogni attributo non chiave di R è dipendente in modo non transitivo (cioè direttamente dipendente) dalla chiave primaria di R. Ciò significa che nessun attributo non primo (non parte della chiave candidata) è funzionalmente dipendente da altri attributi non primi. Se ci sono due dipendenze tali che A ? B e BC, quindi da questi FD, possiamo derivare A ? C. Questa dipendenza AC è transitiva.

Esempio di 3NF:

Considera la seguente relazione Ordine (Ordine#, Parte, Fornitore, PrezzoUnitario, QtàOrdinata) con il dato set di FD:

Ordine# ? Parte, fornitore, quantità ordinata e fornitore, parte ? Prezzo unitario)

Qui Order# è la chiave della relazione.

Usando gli assiomi di Amstrong, otteniamo

Ordine# ? Parte, ordine? Fornitore e Ordine? Qtà Ordinata.

Ordine# ? Parte, fornitore e fornitore, parte ? Prezzo unitario, entrambi danno Order# ? Prezzo unitario.

Quindi, vediamo che tutti gli attributi non primi dipendono dalla chiave (Ordine#). Tuttavia, esiste una dipendenza transitiva tra Order# e UnitPrice. Quindi questa relazione non è in 3NF. Come lo facciamo in 3NF?

Non possiamo memorizzare il Prezzo Unitario di qualsiasi Parte fornita da qualsiasi Fornitore a meno che qualcuno non effettui un ordine per quella Parte. Quindi dovremo scomporre la tabella per farla seguire 3NF come segue.

Ordine (n. ordine, parte, fornitore, quantità ordinata) e anagrafica prezzo (parte, fornitore, prezzo unitario).

Ora non sono presenti dipendenze transitive. La relazione è in 3NF.

Leggi anche: SQL per Data Science

Impara i corsi di software online dalle migliori università del mondo. Guadagna programmi Executive PG, programmi di certificazione avanzati o programmi di master per accelerare la tua carriera.

Conclusione

C'è di più nella normalizzazione, come BCNF, 4NF, 5NF e 6NF. In breve, BCNF non è altro che un'estensione di 3NF, poiché l'ultima regola di 3NF non si applica qui. Tutte le dipendenze funzionali devono avere gli attributi chiave a sinistra e nessuno a destra. (BCNF è anche chiamato 3.5NF). Tuttavia, le forme normali da 4NF e oltre sono scarsamente implementate nella pratica regolare.

Se sei interessato a saperne di più sullo sviluppo full-stack, dai un'occhiata al programma Executive PG di upGrad & IIIT-B in Full-stack Software Development, progettato per i professionisti che lavorano e offre oltre 500 ore di formazione rigorosa, oltre 9 progetti, e incarichi, status di Alumni IIIT-B, progetti pratici pratici e assistenza sul lavoro con le migliori aziende.