Sviluppo4d.it
Sito indipendente di informazioni tecniche per sviluppatori 4th Dimension italiani  

Sviluppatori 4D

Utility 4D

Risorse 4D



4d logo
Naviga: Prev Next

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: 22674

Se accedi con utente e password, puoi aggiungere dei commenti.


Accesso

User:
Pass: Accedi

Cerca

Se non trovi le informazioni che cerchi scrivi a aiuto@sviluppo4d.it

4D Principali

4D Discussioni

Faq random


Crediti

Dominio registrato da ZetaNet
Sito realizzato da Nexus srl
4D SQL 11.9.0 offerto da 4D & Italsoftware
Icone di FAMFAMFAM
Moderato da Umberto Migliore
301 utenti registrati

Pagina servita il 19/03/24 alle 11:46:15 Valid HTML 4.01! Valid CSS!

Mutuo Facile, iDigitalScout, iDigitalTags e altre app di Nexid srl per iPhone e iPad

Cidroid, distributore italiano lettori barcode per IOS Apple iPhone, iPod, iPad