NORMALIZZAZIONE

Abbiamo spiegato nella risposta 51 che il data base relazionale è una raccolta esauriente e completa di dati relativi ad un certo reparto, ad un prefissato tema ecc. A causa delle sue impegnative caratteristiche, il data base relazionale va puntualmente controllato in fase di progetto e la normalizzazione stabilisce i criteri da seguire, in particolare dà le regole dettagliate perché ogni tabella sia corretta e quindi di conseguenza lo sia tutto il data base.
 

Come principio generale si assume che l'esperto controlli l'assoluta coerenza interna della tabella mediante la chiave cui ogni attributo deve dipendere con rigore. In particolare per ogni valore della chiave deve sussistere un solo valore dell'attributo.

Tabella
CHIAVE

ATTRIBUTO-A

ATTRIBUTO-B

ATTRIBUTO-C

ATTRIBUTO-D

 ECC. ECC.
           
           
           

 

Quando questo principio non è verificato, allora l'esperto riconosce che l'attributo non è strettamente pertinente, lo toglie e lo mette in un'altra tabella già costituita oppure in una del tutto nuova.
La normalizzazione esplica il principio sopra illustrato in tre passi di severità crescente i quali rispettivamente controllano che ogni campo, cioè ogni valore dell'attributo, dipenda:

1NF : dalla chiave,
2NF : da tutta la chiave e non da una sua parte,
3NF : direttamente dalla chiave.

Le sigle 1NF, 2NF, 3NF sono l'abbreviazione di first normal form o prima forma normale, second normal form, third normal form. Indicano le tre fasi della normalizzazione che via via si approfondisce e si completa. Andrebbero ricordate anche le verifiche 4NF e 5NF che però sono abbastanza rare ed inusuali.
Quando il tecnico ha completato la normalizzazione ciascuna tabella riporta tutti e soltanto i dati che la riguardano, e dunque tutto il database è corretto.
Vediamo in dettaglio i tre passi.


1°: Si controlla che ogni dato sia identificato in modo univoco dalla chiave. Prendiamo come esempio la tabella Prodotti che contiene il codice del prodotto (COD), la sua tipologia (TIP), il prezzo unitario (PZ), il magazzino dove si trova (MAG), la quantità disponibile in tale magazzino (QTA) e l'indirizzo del magazzino

Prodotti
COD TIP PZ MAG QTA IND
1267 sedia 12000 A2 100 via dei giardini 5
      A3 230 p.za Italia 89
3920 tavolo 23500 A2 20 via dei giardini 5
7602 anta 29000 A1 8 galleria vittorio
      A3 2 p.za Italia 89
      A4 30 p.za Belli 10

Si nota come ad un valore di COD non corrisponde un solo magazzino ma diversi magazzini dunque gli ultimi tre dati vanno portati via. Viene corretta la tabella Prodotti e viene creata la tabella Depositi che illustra i quantitativi depositati nei vari magazzini. Depositi è una tabella con chiave doppia.

Prodotti
COD TIP PZ
1267 sedia 12000
3920 tavolo 23500
7602 anta 29000

Depositi
COD MAG QTA IND
1267 A2 100 via dei giardini 5
1267 A3 230 p.za Italia 89
3920 A2 20 via dei giardini 5
7602 A1 8 galleria vittorio
7602 A3 2 p.za Italia 89
7602 A4 30 p.za Belli 10

 

2° - Quando la chiave è composta, ciascun dato deve dipendere da tutte le sue parti e non da una parte soltanto. Ad esempio in Depositi QTA dipende sia da COD sia da MAG, invece l'indirizzo del magazzino dipende sono da MAG. Dunque la tabella Depositi va corretta e ne va creata una nuova dietro lo scorporo degli indirizzi dei magazzini

Depositi
COD MAG QTA
1267 A2 100
1267 A3 230
3920 A2 20
7602 A1 8
7602 A3 2
7602 A4 30

Magazzini
MAG IND
A2 via dei giardini 5
A3 p.za Italia 89
A2 via dei giardini 5
A1 galleria vittorio
A3 p.za Italia 89
A4 p.za Belli 10

3° -  Talora un dato dipende dalla chiave non direttamente ma per il tramite di un altro dato. La terza normalizzazione corregge tale dipendenza transitiva. Come esempio prendiamo la seguente tabella che riporta il numero ordine (NUM), il codice del prodotto venduto (COD), la data, il codice del cliente (CODCLI) che ha effettuato l'ordine, la sua ragione sociale (RAG) e l'importo dell'ordine (IMP):

Ordini
NUM COD DATA CODCLI RAG IMP
267 1267 11/01 BF37 Alfa srl 2300
340 1267 12/01 SW45 Novasud 1230
457 3920 20/01 KR02 Compar 2500
561 7602 08/02 KR02 Compar 2450
602 7602 22/02 GA66 Minior 800
733 7602 30/03 GQ21 Qualified 2200

Evidentemente la ragione sociale non dipende direttamente dalla chiave quanto piuttosto dipende dal codice cliente. Dunque c'è una dipendenza transitiva e l'attributo RAG va espluso per creare la nuova tabella Clienti

Ordini
NUM COD DATA CODCLI IMP
267 1267 11/01 BF37 2300
340 1267 12/01 SW45 1230
457 3920 20/01 KR02 2500
561 7602 08/02 KR02 2450
602 7602 22/02 GA66 800
733 7602 30/03 GQ21 2200

Clienti
CODCLI RAG
BF37 Alfa srl
SW45 Novasud
KR02 Compar
KR02 Compar
GA66 Minior
GQ21 Qualified

La normalizzazione è conclusa. Dopo aver rivisto le tabelle iniziali Prodotti ed Ordini, ne abbiamo trovate altre tre: Depositi, Magazzini e Clienti. La normalizzazione dimostra che i contenuti delle tabelle iniziali erano confusi e dunque abbiamo ora una soluzione corretta che esplica separatamente cinque diversi temi in cinque tabelle separate.

 

***

La normalizzazione serve per progettare un data base ex-novo, in questo caso si dice che si segue un metodo top-down. Si parte dall'analisi generale formalizzata mediante il grafo ERD (Entity relationship Diagram) (usato anche nell'articolo Data Base Relazionale) poi si fissano i contenuti delle tabelle ed infine le si controlla con la normalizzazione.

ERD -> Normalizzazione

 


La normalizzazione interviene anche in altre situazioni. Ad esempio, succede che si trasformano due o tre archivi in un data base relazionale, questo va normalizzato ed allora si producono un grande numero di tabelle. Questo metodo di lavoro, chiamato bottom-up, comincia con la normalizzazione e si conclude con l'ERD che raccoglie i risultati.Ad esempio le tabelle sopra normalizzate vanno raccolte nel seguente ERD che dà la visione conclusiva del data base

 

In pratica si segue un ordine inverso al precedente

Normalizzazione  ->  ERD

l due metodi dimostrano in modo palese il valore e la forza della normalizzazione la quale progressivamente aiuta a scoprire nuove tabelle ed insieme garantisce la loro correttezza.

* * *

E' importante sottolineare che la più parte dei manuali in circolazione non presentano la normalizzazione così da far vedere il suo completo significato, ma la illustrano come "un metodo di ottimizzazione", cioè con scopi migliorativi e dunque accessori.
Invece la normalizzazione assicura la correttezza del progetto e per tale scopo essa è ineludibile. Se l'esperto non avesse una regola certa per controllare il suo lavoro, non potrebbe dimostrare né a se stesso né agli altri che il data base è ben fatto. Tutto resterebbe vago, invece grazie alla normalizzazione prova che il suo lavoro è obiettivamente valido e corretto. Dunque la normalizzazione non è accessoria ma basilare.

 


  Indietro

 

anno 2007
=