“Errare umano, ma per incasinare davvero tutto ci vuole un computer.” Così si legge variamente. Ne trovo conferme nella mia vita professionale, collaborando con diversi team informatici di aziende, anche note.

I dati sono il nuovo tesoro delle organizzazioni. Prendersi cura dei dati, della loro qualità e integrità, significa rendere facile e sicuro il loro utilizzo e risparmiare risorse.

In questo articolo prendo in esame alcuni esempi di consuetudini “vintage”, che rendono difficile il lavoro con i dati, presentando possibili vie d’uscita. Tali esempi riguardano soprattutto i dati personali, ma sono facilmente estensibili ad altri casi.

• Romeo, perché sei tu ROMEO?
• Testo ingessato
• In quale provincia italiana si trova Londra?
• Spazio ai dati!
• La macchina per scrivere, il computer per validare
• Quando si danno i numeri
• Ottantotto modi di ordinare un caffè
• Nuove tecnologie, vecchie mentalità
• Epilogo?

Romeo, perché sei tu ROMEO?

Se, in un’applicazione aziendale, l’origine dei dati testuali è rappresentata dall’inserimento manuale e/o automatico di fonti esterne, è comune trovare nomi scritti completamente o in maiuscolo o in minuscolo. Al posto di “Romeo Montecchi” troveremo quindi “ROMEO MONTECCHI” oppure “romeo montecchi”. Questo assomiglia al modo di scrittura dei commenti lasciati nelle reti sociali, i cui utenti sembrano troppo indolenti per usare shift. L’impiego delle sole maiuscole è un retaggio degli anni Sessanta, quando nei computer IBM non esistevano le lettere minuscole. La mancanza di cura nell’uso della maiuscola può arrecare danni all’immagine di un’azienda che, agli occhi dei clienti, pare non riesca a controllare la qualità dei propri dati. Inoltre, il testo che rispetta l’uso corretto di maiuscolo e minuscolo (“Romeo Montecchi”) è più leggibile del testo tutto in maiuscolo, aumentando così la produttività di chi deve lavorare con questi dati. Interessante, a questo proposito, l’articolo in lingua inglese https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2016788/

L’applicazione che inserisce nel database nomi di persone e toponimi assunti dalle maschere o da fonti esterne può “pulirli” automaticamente. Se il testo è scritto tutto in lettere maiuscole o tutto in lettere minuscole, si applica la funzione in cui ogni parola inizia con la maiuscola, convertendo il resto della parola in minuscolo. In questo modo “ROMEO MONTECCHI” e “romeo montecchi” diventano “Romeo Montecchi”, mentre “McCartney” rimane “McCartney” e non diventa “Mccartney”. La sigla provincia e il codice nazione invece vanno convertiti in maiuscolo.

Nelle lettere accentate, fa un brutto effetto anche la sostituzione dell’accento con l’apostrofo. Questo crea evidenti problemi nel confronto delle informazioni. Un programma, ad esempio, può decidere che “CALO’”, “CALO’”, “Calò” e “CALÒ” siano tutti cognomi diversi. Nel caso di emulazione delle lettere accentate è rischiosa una conversione automatica in quanto l’apostrofo può davvero fare parte del nome (vedi “O’Hara”). È possibile tuttavia implementare un report che estrae questi casi da sottoporre al controllo manuale. L’uso delle lettere accentate appare quindi imprescindibile.

Le lettere accentate e quelle con il segno diacritico (à, è, ç, ñ eccetera) presenti nelle lingue europee possono avere codifiche (presentazioni in sequenze di bit) diverse. Quando si stabilisce la struttura dei dati (tracciato record) da scambiare tra diversi sistemi informativi, è necessario concordare anche la codifica. In caso contrario, il già citato “Calò” potrebbe diventare “Calò” passando da un sistema all’altro. Per i file di testo a lunghezza fissa potrebbe essere utile usare la codifica a singolo byte ISO/IEC 8859-15 (http://std.dkuug.dk/JTC1/SC2/WG3/docs/n404.pdf) perché sostituisce in modo indolore la codifica ASCII. Per i formati più moderni come XML e JSON la codifica più adatta è una variante di Unicode, ad esempio UTF-8 (http://www.utf-8.com/), perché comprende il più vasto insieme di caratteri internazionali.

Testo ingessato

Molti sistemi informativi trattano esclusivamente formati di testo con colonne a lunghezza fissa che “ingessano” lo scambio dei dati. L’utilizzo di formati più moderni come XML (https://www.w3.org/XML/), JSON (https://www.json.org/) o almeno CSV (https://tools.ietf.org/html/rfc4180) risolve i seguenti problemi:

• Possibilità di aumentare la lunghezza del campo. Il famoso millennium bug è stato affrontato con un costoso cambio dei tracciati record per estendere l’anno da due a quattro cifre. La necessità di una simile estensione può riguardare qualsiasi dato, la cui lunghezza dovesse eventualmente cambiare in futuro: codice fiscale, IBAN, CAP eccetera. XML, JSON e CSV in genere non fissano a priori la lunghezza dei campi.
• Possibilità di inserire o di togliere un campo. Nel formato a lunghezza fissa i nuovi campi vengono in genere inseriti in fondo alla riga, per non dover riscrivere i programmi già esistenti, che hanno imparato a leggere i campi in una sequenza ferrea. I tracciati record veterani sono spesso chiazzati di filler (campi non più usati). In XML e in JSON i campi hanno un nome, quindi la sequenza non ha molta importanza e si possono aggiungere nuovi campi o togliere quelli non più in uso.
• Strutturazione dei dati. Alcuni dati per loro natura hanno una relazione gerarchica, a matrioska. Prendiamo l’esempio del portfolio assicurativo: i dati di una polizza contengono i nuclei familiari assicurati, ognuno dei quali contiene a loro volta i dati delle singole persone componenti del nucleo. La struttura gerarchica è naturale per XML e per JSON. Inoltre, anche la struttura dei dati è facilmente modificabile. Nel nostro esempio possiamo aggiungere all’interno della polizza un elenco di pagamenti a rate del premio.

In quale provincia italiana si trova Londra?

Ci sono molti sistemi informativi xenofobi. Infatti, nei loro dati prevalgono i formati italiani per codici fiscali, IBAN, indirizzo postale. Ci sono casi in cui si tenta, senza successo, di “far entrare” un indirizzo straniero nella struttura dell’indirizzo italiano, con CAP a 5 cifre e con la sigla provincia.

Per risolvere il problema occorre prevedere più spazio per il campo del codice fiscale e dell’IBAN.

La lunghezza dell’IBAN arriva a 32 caratteri e nel futuro li potrebbe superare (https://www.iban.com/structure). Quindi, 40-50 caratteri sono sufficienti.

A livello europeo il codice fiscale e la partita IVA diventano gli identificatori dei contribuenti (https://data.europa.eu/euodp/it/data/dataset/taxpayer-identification-number-tin e https://ec.europa.eu/taxation_customs/tin/). Anche per questo dato non sbaglieremo se useremo 40-50 caratteri.

L’indirizzo postale deve poter rappresentare quello di altri paesi. Come minimo deve contenere:

• indirizzo all’interno di un centro abitato (via e civico o simile), almeno 180 caratteri;
• codice postale, almeno 20 caratteri;
• nome del centro abitato (città, località), 180 caratteri;
• suddivisione postale infranazionale (provincia italiana, stato degli USA eccetera), 20 caratteri per la sigla, meglio se 100 quando non c’è sigla (vedi oblast’ nella Federazione Russa);
• sigla della nazione, 2 caratteri per il codice ISO 3166-2 della nazione https://www.iso.org/iso-3166-country-codes.html).

Il formato degli indirizzi è consultabile nel sito dell’Universal Postal Union http://www.upu.int/. Un elenco dei codici postali del mondo è costantemente aggiornato in https://www.geonames.org/.

Spazio ai dati!

Gli spazi superflui all’inizio e alla fine dei nomi o in mezzo a un nome composto (ad esempio “_Carlos__Pablo_”: qui lo spazio è presentato con il trattino basso) generalmente non sono visibili nella pagina HTML. Essi però creano problemi quando il dato viene confrontato o quando i record vengono ordinati per questo dato. Da tali nomi, provenienti da data entry, occorre togliere gli spazi superflui, prima di salvare il testo nel database.

Il problema inverso si ha quando vengono lasciati pochi caratteri per contenere i dati. Succede di dover lavorare con un campo di 35 caratteri che deve contenere cognome e nome, con un probabile troncamento.

Tenere nello stesso campo cognome e nome crea un problema ulteriore. È più facile conservare separatamente i dati e all’occorrenza unirli che conservarli uniti avendo qualche volta la necessità di averli separati. Infatti, il destinatario di una comunicazione generata automaticamente dovrebbe essere indicato con nome e cognome, mentre negli elenchi con cognome e nome.

In alcuni sistemi l’IBAN italiano è presentato non come una stringa di 27 caratteri, ma diviso in 6 campi (ad esempio “IT”, “60”, “X”, “05428”, “11101”, “000000123456”). Quest’ultimo formato deriva dai tempi in cui le coordinate bancarie venivano presentate come ABI, CAB, CIN e numero di conto corrente. I tempi sono passati, gli IBAN non sono solo italiani, quindi è il momento di usare un unico campo.

La macchina per scrivere, il computer per validare

I dati che vengono scambiati tra i sistemi sono a volte incoerenti e non controllati. Questo porta agli scarti di file trasmessi e alla necessità di correggerli e di ritrasmetterli, quindi a una perdita di tempo e di altre risorse.

Se c’è un modo di validare dati, occorre usarlo nel sistema di origine. Ad esempio, se si tratta di informazioni anagrafiche personali, validiamo il codice fiscale italiano con il cognome, il nome, il sesso e la data di nascita. Si veda ad esempio l’algoritmo nell’articolo https://datainvest.eu/it/2003/08/12/come-e-costruito-il-codice-fiscale/. Controlliamo la validità dell’IBAN prima di comunicarlo (algoritmo in https://datainvest.eu/it/2003/08/12/iban-standard-di-comunicazione-delle-coordinate-bancarie-internazionali/#chk-algo).

Lo stesso vale per i dati più semplici contenuti nelle tabelle di codifica, come sigla provincia. Basterebbe solo verificare che una data sigla sia contenuta nella tabella. Un controllo più sofisticato e utile sarebbe quello di verificare che una data coppia di CAP e di sigla provincia sia contenuta nella tabella. Lo stesso procedimento è applicabile alla tripletta di codice postale, suddivisione postale infranazionale e codice nazione.

Il formato XML insieme con DTD può inoltre aiutare a controllare ‑ sia all’origine sia al ricevimento dei dati ‑ alcune fra le regole da applicare alla struttura dei dati di interscambio, come ad esempio l’obbligatorietà condizionata delle informazioni.

Quando si danno i numeri

Per comunicare gli importi in euro vengono usati i numeri con virgola mobile (floating point number). Nei file di testo con le colonne a lunghezza fissa questi numeri vengono scritti con o senza virgola decimale, con due cifre riservate ai decimali; il numero è allineato a destra e riempito con gli zeri a sinistra. Il termine “virgola virtuale” coniato in COBOL può creare confusione. Significa semplicemente che gli importi vengono specificati come numeri interi in centesimi di euro. È il caso, allora, di usare quest’ultima più semplice definizione quando vengono definiti i tracciati.

Capita di vedere l’anno scritto con due cifre. Non essendo rarissimo il caso di ultracentenari, occorre usare quattro cifre.

Lo standard statunitense per le date è “mese-giorno-anno”, quello europeo è “giorno-mese-anno”. Il formato, a mio avviso, più logico è “anno-mese-giorno” (“yyyy-mm-dd”). Infatti, i suoi componenti sono scritti dai più ai meno significativi, come nella forma decimale dei numeri. Lo stesso è ancora più vero per il formato di orario “yyyy-mm-dd hh:mi:ss”.

Quando il nome del file include la data, è utile esprimerla nel formato “yyyymmdd”, ad esempio “Vendite20210424.txt”. Questo aiuta ad avere, in una directory, i file già ordinati per la data contenuta nel nome.

All’alba dell’era informatica i prefissi K, M, G eccetera venivano usati per i multipli binari 2^10, 2^20, 2^30 eccetera. Questo creava, e continua a farlo, confusione in quanto i veri significati di K, M e G sono i multipli decimali 10^3, 10^6, 10^9 eccetera. Infatti, la capacità dello stesso disco in un sistema operativo può essere presentata come 1862 GB, in un altro come 2000 GB: non è certo una differenza trascurabile. La soluzione è di dare a Cesare quel che è di Cesare, ovvero utilizzare K, M e G per i prefissi decimali del sistema SI e Ki, Mi, Gi per i prefissi binari previsti nello standard IEC 60027-2:2000. Vedi https://www.bipm.org/en/measurement-units/prefixes.html per il sistema SI e https://www.cl.cam.ac.uk/~mgk25/information-units.txt per lo standard IEC citato.

Ottantotto modi di ordinare un caffè

Per mettere ordine nei dati è bene associare ad essi una categoria.

Vediamo ad esempio le seguenti categorie di immobili in vendita:

• 1 locale
• 2 locali
• 3 locali
• 4 o più locali
• Attico
• Bar
• Negozio
• Pasticceria
• Ufficio
• Villa

e così via per un totale che può arrivare fino a 30 voci. È evidente l’ambiguità di questa classificazione. Infatti, come classificare uno spazio commerciale vuoto al piano terra utilizzabile indifferentemente per bar, pasticceria, gelateria, negozio o ufficio?

Se nel precedente esempio volessimo distinguere l’immobile secondo la zona (urbana o rurale), saremmo costretti raddoppiare l’elenco aggiungendo ad ogni voce la parola “urbano” e “rurale”. Ripetendo questa operazione per altre caratteristiche, allungheremmo esponenzialmente la lista. Sono incappato in una di queste liste, che conteneva circa 2000 voci. In genere una singola lista molto lunga di categorie (più di 5-10 valori) è un segnale di classificazione non solo male strutturata ma anche difficile da aggiornare. Inoltre, l’utilizzo di elenchi troppo lunghi spesso implica una scarsa qualità dei dati con la conseguenza che l’utente si ferma alla prima voce, che sembra quella giusta per lui, senza verificare le restanti.

Delle stesse difficoltà soffrono le seguenti categorie del commercio elettronico:

• Articoli d’antiquariato e arte
• Film, DVD, Blu-Ray
• Fotografia, video
• Francobolli
• Fumetti
• Libri, riviste
• Musica, vinili, CD
• TV, audio, video
• …

Dovendo classificare un libro di fumetti d’arte o un libro di francobolli, che categoria uso? “Film” e “video” compaiono addirittura in tre categorie. Come classifico un DVD audio di musica?

Una buona categorizzazione è:

• completa, cioè copre tutti i casi possibili;
• univoca, cioè ogni voce è distinta dall’altra;
• gerarchica, cioè contiene le categorie macro divise in categorie sempre più dettagliate;
• multidimensionale, cioè è divisa in categorie indipendenti, ognuna delle quali classifica una caratteristica diversa;
• possibilmente compatibile con classificazioni ufficiali.

In questo modo una lunga lista di 88 modi di ordinare il caffè, trovata in un bar (caffè ristretto, caffè corretto schiuma, caffè in vetro macchiato freddo con acqua calda a parte lungo eccetera), si scompone in 13 brevissime liste di categorie indipendenti. Queste considerazioni sono illustrate nell’articolo https://datainvest.eu/it/2016/07/02/come-classificare-i-modi-di-ordinare-un-caffe-e-i-dati-aziendali/.

Nuove tecnologie, vecchie mentalità

Se due organizzazioni devono scambiarsi i dati, occorre concordare tracciato record, formato, codifica caratteri eccetera. Nella mia vita professionale, quando propongo di usare gli standard moderni, spesso mi sento obiettare: “È inutile: tutti gli altri usano gli standard vecchi. I nuovi formati non saranno mai compatibili con i sistemi attuali.”

È chiaro che se tutti usassimo le nuove tecnologie, avremmo solo vantaggi. Infatti, quando abbiamo convenuto di usare dall’inizio la forma XML per lo scambio di dati complessi, siamo riusciti facilmente e più volte ad aggiungere altre informazioni alla struttura iniziale.

Epilogo?

Gli argomenti trattati riguardano l’attenzione basilare alla qualità dei dati. L’Italia è un paese di prodotti agroalimentari e manifatturieri di pregio. Perché non può eccellere anche in campo informatico?

Mi piacerebbe sapere se anche a voi sono capitati problemi simili e quali soluzioni avete individuato per risolverli.