La normalizzazione nelle basi di dati

La normalizzazione è il processo di organizzazione e riorganizzazione dei dati in un database. Solitamente un progetto di database ben fatto non dovrebbe richiedere una operazione di normalizzazione ma potrebbe comunque presentarsi tale necessità. Il processo comprende la creazione di tabelle e la definizione di relazioni tra di esse sulla base di regole progettate, o riprogettate, in modo da garantire la coerenza dei dati e rendere il database più efficiente mediante l’eliminazione delle ridondanze, ovvero di dati duplicati, e delle dipendenze incoerenti.

La presenza di dati ridondanti comporta uno spreco di spazio su disco nonché problemi di manutenzione ed aggiornamento. Infatti se è necessario modificare dati presenti in più posizioni, righe o tabelle che sia, la modifica deve essere effettuata ovunque seguendo le stesse modalità, individuando tali dati e sanandoli in modo coerente. L’uso delle relazioni e delle chiavi esterne diventa il punto vincente della normalizzazione. Se devo aggiornare un dato, lo aggiorno solo su una tabella e non sulle righe di più dati che puntano a quella informazione.

Che cos’è una “dipendenza incoerente”? E’ come avere in tabelle di un certo tipo dati afferenti ad altre entità/tipologie. In questo modo non è facile reperire i dati che si cercano se sono sparsi in modo poco coerente tra le tabelle. Le dipendenze incoerenti possono rendere difficile l’accesso ai dati con le query e rendere molto complesso l’aggiornamento.

Ci sono 3 più una quarta regola detta forma normale, che possiamo seguire per ottimizzare le nostre tabelle e dati.

Prima forma normale

• Eliminare i gruppi/colonne ripetute in singole tabelle.
• Creare una tabella separata per ciascun insieme di dati correlati, seconda una relazione 1 a N o N a N
• Identificare ciascun insieme di dati correlati associandovi una chiave primaria.

E’ la forma un po’ più rara da trovare errata perché comunque poco intuitiva. E’ classico delle tabelle piatte in cui un singolo record può avere una stessa tipologia di attributo ripetuto in più colonne

In questo caso è bene creare una tabella colori separata e nella tabella principale ripetere tre volte il record, ognuna con valore di chiave esterna opportuno

Seconda forma normale

• Creare tabelle separate per insiemi di valori ripetuti per più record
• Correlare queste tabelle con una chiave esterna opportuna
• Tutti i campi non devono dipendere da una parte della chiave

E’ il caso più semplice ed usuale dove si trova una relazione 1 a N o N a N nei record e colonne presenti. Vanno suddivise in modo opportuno creando tabelle nuove opportune.

Nell’esempio abbiamo una tabella con chiave composita a due campi IDVolo + IDCliente. Al di la della definizione, l’anomalia è subito evidente e grossolana: il campo Cognome dipende solo da una parte della chiave, qui IDCliente, mentre Compagnia dipende da IDVolo, Questi campi è bene spostarli solo nelle rispettive anagrafiche, mentre il campo posto può tranquillamente rimanere in questa tabella poiché non rappresenta una informazione delle singole anagrafiche ma ibrida di entrambe.

Terza forma normale

• Eliminare i campi che non dipendono dalla chiave

Classico caso di una tabella Impiegati con chiave primaria IDImpiegato. Il campo telefono ufficio presenta un paio di problemi. Mentre IDUfficio può tranquillamente fungere da chiave esterna verso una tabella collegata, il campo/colonna TelefonoUfficio palesemente non dipende dalla chiave primaria, al massimo da quella esterna, generando un problema di ridondanza e di aggiornamento. Va scorporato dalla tabella impiegato e inserito unicamente nella anagrafica Ufficio a cui punta il campo IDUfficio.

Esempio

Vediamo un esercizio classico completo dove ci viene chiesta la normalizzazione.

Come procediamo in questi casi? Sicuramente lo studente, arrivato a questo argomento, vanta una grande quantità di esempi di esperienza già visti. Bisogna partire dall’individuare le incoerenze che questa mega tabella può avere. Innanzi tutto individuiamo il tema centrale della tabella. Sembrerebbe una anagrafica “dipendente scolastico”. Quali sono le informazioni del dipendete strettamente connesse alla sua anagrafica? Sicuramente nome e cognome che andrebbero arricchite da una chiave primaria univoca e stipendio che è un attributo semplice. Il ruolo è un classico attributo che possiamo andare a rendere esterno con una chiave su una tabella. Gli altri attributi Ruolo e Sede andrebbero linkati con una chiave esterna e inseriti in anagrafiche separate. Altra nomalia però sulla cardinalità delle tabelle esterne da creare: ogni dipendente può essere dislocato in più sedi che implica una relazione N a N, mentre il Ruolo è unico e specifico per ogni dipendete così da rendere la relazione 1 a N. In questi casi provare a disegnare il diagramma E/R aiuta molto ad intuire le relazioni e le rispettive entità se funzionano bene.

Sfruttando il modello E/R e traducendo nel rispettivo modello logico, otteniamo le seguenti sottotabelle normalizzate.

Ultima modifica 14 Ottobre 2023

Articoli simili:

Modello concettuale e logico “gestione banca” Modello concettuale e logico “prenotazioni ristorante” Modello conecttuale e logico “Gestione spese condomini” I trigger SQL