I dati che un’azienda o un’organizzazione possiedono sono il loro tesoro. Trascurando la qualità delle informazioni contenute nel database dei sistemi applicativi, i dati presto diventano “spazzatura”, aumentano l’incertezza nelle decisioni e richiedendo un continuo e costoso lavoro manuale. Inoltre i dati non formattati in modo omogeneo (ad esempio “ROMA”, “milano”, ” TOrino”) che appaiono nelle pagine dell’applicazione lasciano nei clienti l’impressione di un lavoro non professionale.
In questo articolo tratteremo della buona pratica che permette di mantenere in salute le informazioni contenute nel database.
Quando intervenire?
I momenti principali in cui è possibile occuparsi della qualità dei dati sono:
- progettazione del database e dell’applicazione
- immissione, manuale o automatica, delle informazioni nel database
- controllo post immissione
- malfunzionamento dell’applicazione a causa dei dati “sporchi”
Come accade con la salute, è meglio prevenire che curare. Quindi ci occuperemo dei tre primi momenti.
Progettazione
La struttura ben ideata del database e del sistema applicativo elimina la maggior parte degli errori più comuni nei dati.
Progettazione dell’applicazione
Le informazioni del sistema applicativo vanno divise in entità correlate. La divisione deve essere la più minuziosa possibile. Ad esempio occorre rappresentare ogni persona come entità Persona, mentre il suo indirizzo come l’entità separata Indirizzo. Questo approccio fa collocare le informazioni in modo da non doverle ripetere, evitando in tal modo una discordanza di informazioni sulla stessa entità.
I sistemi applicativi moderni separano la presentazione dei dati dalla logica di business. Un esempio di tale architettura è MVC (model-view-controller). Questa separazione permette di concentrare l’attenzione sulla logica operativa dei dati indipendentemente dall’interfaccia con l’utente.
Molti dei controlli sui dati si possono implementare come le regole di logica di business previste nel componente M (model) dell’applicazione. Un model, tipicamente, rappresenta un’entità ed è collegato ad una tabella del database. La logica di business impone, ad esempio: la corrispondenza tra le date (la data di inizio di un periodo non deve essere posteriore alla data di fine), l’integrità delle coordinate bancarie IBAN, la corrispondenza del codice fiscale italiano della persona fisica con il cognome, il nome, la data di nascita e il sesso. Inoltre, è utile impostare i controlli della coerenza delle informazioni tra le entità correlate; ad esempio la data di nascita del figlio non può essere anteriore alla data di nascita del suo genitore.
Progettazione del database
Ogni tabella del database classico relazionale rappresenta un’entità: le righe sono le istanze, le colonne sono gli attributi. È possibile istruire il database in modo da non accettare i dati mancanti nelle colonne (ad esempio cognome della persona), evitando così l’assenza di attributi importanti. È inoltre possibile verificare l’univocità del dato, ad esempio che la tabella Persona non contenga due righe con lo stesso valore del codice fiscale.
La relazione fra le entità è curata dal database attraverso le chiavi esterne. Ad esempio, è possibile gestire un nucleo familiare creando le due entità-tabelle: il nucleo e il familiare. Ogni familiare deve essere collegato con il nucleo attraverso le chiave esterna. La relazione gestita a livello del database evita una serie di errori di relazione tra le informazioni: un familiare senza nucleo oppure un familiare inserito in più nuclei, oppure una sigla provincia non prevista nella tabella delle province italiane.
Prendiamo in esame una gestione confusa delle informazioni anagrafiche riferite alle persone di una polizza assicurativa. Si tratta di un’unica tabella con i dati della polizza e della persona assicurata. In questo modo ogni annualità della polizza viene registrata come una riga nella tabella, ripetendo il cognome, il nome e gli altri dati dell’assicurato. Diventa tuttavia difficile interpretare i casi in cui nella stessa polizza, nelle righe riguardanti i diversi anni cambia il nome della persona: il nome è diverso per mero errore materiale oppure si tratta di due persone distinte? Spostando invece i dati della persona in una tabella dedicata, avremo un solo record per ogni persona, eliminando così la discordanza delle informazioni.
Immissione dei dati
I dati possono arrivare nel database attraverso un inserimento manuale dalle maschere dell’applicazione, oppure importando un flusso dei dati. Il momento dell’immissione dei dati è ideale per controllare la loro validità. È inoltre possibile effettuare una correzione “al volo” delle informazioni immesse.
Inserimento manuale
Nel controllo della qualità, il momento dell’immissione manuale dei dati ha un vantaggio, in quanto l’operatore può subito correggere i dati avendo le informazioni originali sottomano. Il sistema applicativo deve aiutare l’operatore ad accorgersi dell’errore nei dati, avvalendosi della logica di business inserita nell’applicazione.
Vi sono due momenti tipici di controllo, quando l’utente inserisce i dati in una maschera web: prima e dopo aver inviato i dati al server.
Nel primo momento, i programmi in JavaScript o simili, incorporati nella maschera web, controllano i dati inseriti, evidenziando immediatamente gli errori: dati mancanti, formato errato di data o di numero, date discordanti, eccetera. La verifica immediata riduce lo scambio dei dati con il server, aumentando la velocità dell’inserimento.
Nel secondo momento, l’applicazione deve controllare anche i dati inviati dall’utente al server. Questi controlli servono per le verifiche che si possono fare solo nel server, ad esempio la coerenza con altri dati già presenti nel database, o quelli che richiedono calcoli impegnativi. È buona norma comunque ripetere gli stessi controlli già effettuati nella maschera di inserimento.
Un altro metodo di evitare i dati errati è l’utilizzo di elementi di maschera che non permettano l’inserimento dei dati non validi:
- i pulsanti radio (radio buttons) o la lista a cascata (drop-down list) limitano la scelta solo ai valori previsti, ad esempio per il sesso o per la provincia italiana
- il pulsante calendar limita la scelta fra le date presentate in una finestra di calendario e garantisce il formato corretto delle date
Importazione del flusso
Si tratta dell’inserimento di un flusso di dati provenienti da fonti esterne. I dati sono contenuti in uno o più file. La struttura dei file è concordata a priori fra il produttore e il consumatore del flusso.
Un aspetto spesso trascurato dai progettisti dei flussi di interscambio è l’accordo sulla codifica di testo. Dalla codifica infatti dipende l’interpretazione delle lettere accentate. Inoltre, se vengono prodotti dati nella codifica multibyte (ad esempio UTF-8), mentre il consumatore dei dati attende una codifica a byte singolo (ISO8859-15 o ASCII), i record del testo a colonne fisse vengono rovinati. In entrambi i casi i dati ricevuti sono “sporchi”.
Per controllare la qualità dei dati è utile sfruttare la logica di business impostata nel sistema applicativo. L’importazione, quando incontra errori, può reagire in uno di questi tre modi:
- segnalarli tutti, scartando l’intera importazione
- importare solo le entità che non presentano problemi, segnalando e scartando quelle errate
- importare tutto contrassegnando le entità e gli attributi non validi
Nell’ultimo caso il database deve essere munito dei flag che indicano le entità e gli attributi non validi. I dati non validi infatti non devono partecipare in pieno alla “vita” dell’applicazione, finche le informazioni non saranno corrette.
Correzione al volo
È utile fare le seguenti correzioni “d’ufficio” dei dati che vengono inseriti nel database attraverso l’applicazione, anziché segnalare l’errore:
- eliminare gli spazi superflui all’inizio e alla fine del testo e gli spazi doppi
- convertire il testo tutto minuscolo o tutto maiuscolo; ad esempio “MILANO” o “milano” diventano “Milano”
- permettere una certa flessibilità nei formati dei numeri decimali e delle date. Ad esempio “1.23” e “1,23” diventeranno “1,23”; “1-1-2016” diventerà “01/01/2016”
Controllo post immissione
Vi sono alcuni casi in cui conviene controllare i dati già presenti nel database:
- dopo una migrazione massiva dei dati da una versione precedente dell’applicazione, senza aver applicato tutti i controlli
- aggiunta di una nuova logica di business
- modifica dei dati, ad esempio per attribuire sigla provincia dopo lo scorporo delle province
- ricerca di situazioni sospette, ad esempio la frode assicurativa
In genere queste verifiche sono semi automatiche, effettuate direttamente nel database con l’ausilio delle query.
Ambiti di controllo
Il controllo della qualità dei dati viene eseguito nei seguenti ambiti:
- singolo attributo
- più di un attributo della stessa istanza di entità
- più istanze della stessa entità
- entità correlate
Qualità di ogni singolo attributo
Per ogni singolo attributo è possibile controllare:
- che sia valorizzato
- che il valore cada in un certo intervallo (ad esempio, età della persona compresa tra 0 e 150)
- il formato (ad esempio, la data deve avere il formato “dd/mm/yyyy”, l’indirizzo email deve contenere “@”)
- l’integrità dei codici, ad esempio di IBAN o di codice fiscale
Discordanza tra più attributi
Nei casi in cui i valori degli attributi della stessa istanza dell’entità sono correlati, occorre verificare ad esempio che:
- la data di inizio di un periodo non sia posteriore alla data di fine di quel periodo
- per la persona fisica siano obbligatori inseriti il cognome e il nome e per la persona giuridica la denominazione
Discordanza tra più istanze della stessa entità
Si tratta di controllare, ad esempio, che non vi sono due persone con lo stesso codice fiscale.
Discordanza tra le entità correlate
I valori degli attributi delle entità correlate devono concordare:
- la sigla della provincia dell’indirizzo rientra tra i valori previsti nella tabella delle province italiane
- un nucleo familiare deve contenere almeno un familiare
- ogni familiare deve essere inserito esclusivamente in un nucleo
Conclusione
Il controllo di qualità delle informazioni deve avvenire in ogni fase dell’attività informatica, dalla progettazione all’immissione dei dati. La pulizia costa poco e vale molto, restituendo infatti all’azienda un patrimonio di dati fruibili.
Risorse
- Un libro sui principi di database relazionale:
C. J. Date, Database in Depth. Relational Theory for Practitioners, Sebastopol, O’Reilly Media, 2005. ISBN 978-0596100124 - Un articolo sull’evoluzione dell’architettura delle interfacce utente, MVC inclusa:
http://martinfowler.com/eaaDev/uiArchs.html - Un articolo sulla codifica di testo:
http://www.joelonsoftware.com/articles/Unicode.html - Una serie di articoli sul controllo della correttezza del codice fiscale italiano e dell’IBAN:
http://datainvest.eu/it/category/il-paradiso-del-codice-fiscale/