La storicizzazione (parte II)

Dopo aver dedicato un po' di tempo a prendere confidenza con il concetto di storicizzazione (un concetto semplice che potremmo semplificare in tenere traccia di quando succede qualcosa e di chi esegue un'azione), vediamo se è possibile estendere questo concetto in modo semplice, senza alcun impatto pesante sulle strutture delle banche dati e dei programmi che su di esse si appoggiano.
Sicuramente invalidare dei dati è importante: maschera le informazioni passate per l'utente che attualmente usa l'applicazione, ma tiene traccia delle informazioni pregresse. Così facendo si è gestita una delle tre istruzioni principali di manipolazione dei dati che ci mette a disposizione SQL: delete. Ma oltre a delete, che in realta noi abbiamo trasformato in update, ci sono appunto update e insert.
Anche solo come semplice estensione del concetto, potremmo pensare che update e insert vadano gestite come la delete, con le stesse proprietà e modalità. Tale assunto è anche completamente armonico con il concetto di OOP (Object Oriented Programming, Programmazione Orientata agli Oggetti), un paradigma molto di moda alcuni anni fa, oggi un po' meno in voga, ma che rimane comunque la base di moltissimi linguaggi di programmazione che vanno per la maggiore, prima di tutto Java e derivati, e dell'architettura di molti sistemi operativi e strumenti di sviluppo in uso. Ovviamente qui sto parlando di ereditarità: le tre istruzioni sono sorelle, quindi hanno lo stesso padre e quidi dovrebbero ereditare le stesse proprietà, gli stessi attributi, la stessa interfaccia e quindi necessitano degli stessi campi in banca dati.
Parlo quindi di aggiungere i seguenti campi:
DATA_INIZIO_VALIDITA
UTENTE_INIZIO_VALIDITA
DATA_MODIFICA
UTENTE_MODIFICA
Ovviamente la prima coppia supporta le operazioni di insert, che rimangono insert di nuovi record con due campi in più, mentre l seconda coppia supporta le modifiche ai record, che rimangono delle update che lavorano su due campi in più.
La semantica dei campi è piuttosto immediata: usiamo DATA_INIZIO_VALIDITA e UTENTE_INIZIO_VALIDITA per rispondere alle domande su quando e chi ha inserito l'informazione nell'ambiente di riferimento; usiamo DATA_MODIFICA e UTENTE_MODIFICA per rispondere alle domande su quando e chi ha effettuato l'ultima modifica dei dati.

La storicizzazione (parte I)

Per quanto possa sembrare strano, quando si gestisce un database servono sempre dei campi di supporto alla storicizzazione.
Il primo campo che mi viene in mente è DATA_FINE_VALIDITA. Questa data permette, ad esempio, di filtrare in una query successiva, i dati ancora validi da quelli che non lo sono più e sono conservati solo per ragioni storiche. Con questo campo abbiamo già raggiunto un buon livello di storicizzazione. Adesso abbiamo un campo che può essere utilizzato come flag nelle query (se NULL il dato è valido, se compilato il dato non è più valido). La data porta però, insieme a sé, anche l'informazione su quando la validità è cessata: quindi con pochi byte in più per ogni record, è possibile tracciare informazioni più di dettaglio. Il campo è gestito sia applicativamente (facendo un update del campo del record e non la delete del record, che magari sarebbe impossibile per motivi di chiavi esterne), sia direttamente in banca dati valorizzandolo manualmente.
Un secondo campo utile da affiancare al precedente è UTENTE_FINE_VALIDITA. Possiamo quindi decidere di tenere traccia di chi ha effettuato l'operazionee non solo quando. Come nel caso del campo precedente, possiam gestire il campo sia applicativamente (facendo un update del campo del record e non la delete del record), sia direttamente in banca dati valorizzandolo manualmente. Nel caso in cui si proceda via applicativo, l'utente sarà un utente applicativo, altrimenti si potrebbe usare un utente fittizio o un'utenza dedicata all'amministratore del sistema.