Titolo: Teoria della normalizzazione: ridondanze e storicizzazione dei dati
Categoria: Tecniche |
|
Ultimo Aggiornamento: 25/02/05 |
La necessità di storicizzare le informazioni, molto spesso si scontra, apparentemente, con la necessità di normalizzare un database.
Illustro il caso con due tabelle perfettamente normalizzate:
[Cliente]
Codice
RagioneSociale
...
[Fattura]
Numero
Data
CodiceCliente
...
Bene, cosa succede se il cliente in una certa data comunica una variazione di ragione sociale? Tutte le fatture antecedenti alla data di variazione non potrebbero più essere ristampate correttamente.
Per prevenire un problema di questo tipo, normalmente si ricorre all'aggiunta della ragione sociale del cliente anche sulla tabella [Fatture]:
[Fattura]
Numero
Data
CodiceCliente
RagioneSocialeCliente
...
In questo caso la ragione sociale memorizzata sulla fattura non è un dato ridondante ma un dato storico (storicizzato).
L'aspetto interessante, però, è che esiste un'altra via per risolvere il problema, anche se molto più complessa e dispendiosa sotto tutti i punti di vista.
Immaginiamo di voler gestire, per il cliente, anche il cambio di indirizzo di fatturazione (indirizzo, cap, città, provincia...).
Seguendo l'esempio di cui sopra, dovremmo aggiungere anche questi campi alla fattura, oppure, e qui sta l'alternativa, possiamo creare un secondo record cliente, accessibile con data:
[Cliente]
Codice
DataInizioValidità
RagioneSociale
....
Nella tabella [Cliente] è come se il cliente venisse "fotografato" ad una certa data.
Il campo DataInizioValidià viene a far parte, in un certo modo della chiave primaria.
Il cliente continua ad avere un codice solo ma i record sono multipli in base alla data di ricerca (esempio la data della fattura) (primo record con data validità inferiore a quella della fattura...)
Volendo si può sofisticare ancora il metodo, separando i dati storicizzabili in una tabella separata:
[Cliente]
Codice
DatoNonModificabile
....
[ClienteDatiStorici]
Cliente
DataInizioValidità
RagioneSociale
IndirizzoFatturazione
....
Questa tecnica non permette di creare delle relazioni efficienti in 4D perché si otterrebbero delle relazioni n-n. L'accesso al record deve avvenire con una query, un ordinamento decrescente sulla data inizio validità e una first record. Inoltre il presupposto è che tutte le tabelle interessate da questa logica abbiano una data di riferimento da utilizzare per gli accessi (nell'esempio la data della fattura per accedere al cliente).
Ripeto, il metodo è molto complesso, ma in alcune realtà è applicabile.
Consulta da questo link l’indice delle faq sulla normalizzazione
| Inviato da: Alessandro Casassa |
|
Visite: 23059 |
Se accedi con utente e password, puoi aggiungere dei commenti.
