L’intelligenza dei dati - parte seconda

di Piero Giuseppe Goletto

Nel primo articolo di questa serie abbiamo accennato alla necessità di acquisire, standardizzare e in pratica “pulire” i nostri dati.

Questa è una necessità che sorge indipendentemente dallo strumento tecnico che si usa nella pratica; basterebbe prendere in mano le nostre agende cartacee e le nostre rubriche telefoniche per capire il problema.

Proviamo a entrare nel concreto, e per mostrare alcuni casi pratici useremo un foglio elettronico. La scelta dipende dal fatto che il foglio elettronico permette di visualizzare subito eventuali “anomalie”.

La prima anomalia che può verificarsi nei dati è un errore. Tralasciando gli errori di digitazione , l’esempio  che proponiamo è abbastanza clamoroso: attribuire all’ex pilota di F1 Eddie Cheever un romanzo scritto da John Cheever (fig. 1)

Fig. 1

 La seconda anomalia che può verificarsi, tra le tante, è un’incongruenza nel formato dei dati. E’ quello che successe per esempio con l’anno 2000: non si poteva più avere date quali 23-02-67 perché trascorso il 1° gennaio 2000 queste sarebbero risultate ambigue. In realtà, i sistemi che gestiscono  basi dati erano predisposti da tempo per gestire date anche più lontane;  al di fuori delle basi dati insidie potevano manifestarsi ovunque.

La terza anomalia è una diversità nel formato dei dati. Un classico: nel mondo anglosassone i numeri con decimali sono rappresentati con il punto (il numero 3,14 viene indicato come 3.14). In una base dati i numeri devono sempre essere rappresentati in modo omogeneo.  

Un altro passaggio che può rendersi necessario – e che può rivelarsi particolarmente importante se si considerano gli obblighi derivanti dalla normativa sulla protezione dei dati (GDPR) è la “normalizzazione” dei dati.

Qui proponiamo un caso pratico per il quale non occorre tenere conto di tale normativa

Si immagini di avere registrati su tabelle diverse i seguenti dati:

Tabella 1 – popolazione residente

Tabella 2 – Superficie (Kmq)

Tabella 3 – Fuso orario

Se dovessimo unificare soltanto questi dati l’operazione si potrebbe effettuare a mano, senza difficoltà, in poco tempo. Provate a immaginare di doverlo fare per tutti i Comuni italiani e, magari, per tutta una serie di dati storicizzati. Un modo per unificare questi dati è di disporre di una tabella coi codici dei Comuni.

A ogni Comune è assegnato un codice ISTAT e un codice catastale (dall’amministrazione finanziaria; è quello che si usa anche nel Codice Fiscale). Possiamo scegliere il codice Istat:

Tabella 3 – Codici Istat

Adesso siamo in grado, a parità di denominazione del Comune, di Codice Istat, o di Codice Catastale, di unificare i dati raccolti.

Con solo tre Comuni è molto intuitivo quello che facciamo, tant’è che mostriamo direttamente il risultato dell’unificazione.

Tabella 4 – Dati di alcuni comuni italiani

Si noti, tra l’altro, che si sono presi in considerazione tutti gli elementi della tabella dei fusi orari aventi nazione = “IT” (codice che corrisponde all’Italia).

Si deve però pensare, come detto, che quanto da noi fatto manualmente nella gestione concreta delle basi dati viene fatto per migliaia o milioni di elementi attenendosi a procedure e processi ad hoc con passi di controllo e quadratura ben definiti.

I passi di controllo si avvalgono di programmi di diagnostica. Tali programmi non sono che un aiuto per la verifica, ma il primo strato di controllo rimane comunque l’intelligenza di chi lavora sui dati.

Le quadrature  vengono realizzate sui dati in input e in output effettuando le sommatorie sulle quantità in ingresso e in uscita, in modo da sincerarsi che ancorché classificati in modo differente i totali corrispondano.