<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=336490476836615&amp;ev=PageView&amp;noscript=1">

Smart Blog

Gestire dati errati e duplicati in un sistema di Business Intelligence

Giuseppe Costa,

Sistema di Business Intelligence | ripulire e gestire i dati erratiDurante la realizzazione di un sistema di Business Intelligence è prassi comune il dover recuperare dati da numerose fonti, durante la fase di ETL (Extract, Transform, Load). Spesso i dati sono replicati in ciascuna fonte e si rende necessario riconoscere i record che rappresentano la medesima entità. Cerchiamo di capirne di più insieme.

 

Scopri subito la guida alla Business Intelligence per le aziende!

 

Un esempio classico sono le anagrafiche. Anche nel migliore dei casi, in cui l’azienda mantenga un’anagrafe unica delle persone, conservando in un medesimo archivio i dati di fornitori, dipendenti, collaboratori e così via, spesso questi dati sono replicati in sistemi satellite o, in caso di informazioni molto vecchie, devono essere recuperati da file.

I dati provenienti dai vari sistemi e diverse fonti di informazione devono essere unificati, riconoscendo quando i dati si riferiscono a una medesima persona.

Nella migliore delle ipotesi, un numero di matricola identifica record analoghi sui vari sistemi, ma si tratta di una situazione ideale difficilmente riscontrabile.

La situazione più probabile è quello di dover ricostruire i legami tramite altri identificativi univoci. Trattando dati anagrafici, l’identificativo più indicato è il codice fiscale.

In alcuni casi non è disponibile nemmeno un identificativo univoco e i record devono essere confrontati campo per campo, eventualmente limitando il confronto a un numero di campi che garantiscano l’unicità del record. Nel caso delle persone è possibile, ad esempio, considerare i campi utilizzati per ricavare il codice fiscale (nome, cognome, data di nascita, luogo di nascita e sesso).

Il confronto di questi campi non è sempre fattibile tramite uguaglianza esatta, in quanto i valori in essi contenuti sono sovente soggetti a errori e difformità di formato.

 

Gestione degli errori

Sistema di Business Intelligence | Gestire dati errati

Consideriamo il caso del codice fiscale, ma quello che diremo può essere applicato a qualsiasi stringa (sequenza di caratteri) come il nome, il cognome, l’indirizzo ecc.

Se i sistemi sono sufficientemente moderni, il codice fiscale è altamente affidabile, in quanto in fase di inserimento vengono eseguiti controlli incrociati di correttezza che garantiscono l’assenza di errori. In sistemi più datati, il codice fiscale veniva inserito come semplice stringa e i controlli erano assenti o superficiali. Stesso discorso vale per le informazioni estratte da documenti elettronici, come fogli di calcolo o file di testo formattati (CSV). Anche il codice fiscale potrebbe, dunque, non essere un identificativo affidabile.

Per ovviare ai possibili errori è possibile confrontare i valori non per uguaglianza, ma per “similarità”. Un esempio, nel caso di codice fiscale, potrebbe essere il seguente:

CSTGPP73A25I452U
CSTGP73A25I452U
CSTGPPP73A25I452U

I tre codici differiscono per una lettera (in meno nel secondo e in più nel terzo), ma sono chiaramente lo stesso codice. Un confronto per uguaglianza esatta direbbe che si tratta di tre valori diversi. Serve quindi un sistema che permetta di misurare quanto i valori siano simili. Sulle stringhe esistono diversi criteri che permettono di misurare la “distanza” tra due valori. Una delle più note distanze è la “Levenshtein Distance” (LvnD), che tiene in considerazione il numero di sostituzioni, cancellazioni e inserimenti di lettere necessario a trasformare una stringa in un’altra.

Per poter considerare due valori come equivalenti è possibile fissare delle soglie di tolleranza per la distanza. Fissando come soglia una distanza LvnD minore o uguale a due 2, i tre valori sopra risulterebbero equivalenti in quanto:

LvnD(CSTGPP73A25I452U, CSTGP73A25I452U)=1
LvnD(CSTGPP73A25I452U, CSTGPPP73A25I452U)=1
LvnD(CSTGP73A25I452U, CSTGPPP73A25I452U)=2

Stabilire quale dei record sia quello con il valore corretto è un altro problema importante da risolvere. Nel caso in cui sia presente un’anagrafe centrale, è possibile considerare i valori presenti in tale anagrafe come quelli di riferimento e riportare i valori dei record individuati come analoghi a quelli dell’anagrafe centrale. Se non è possibile identificare una delle fonti come attendibile, si utilizza il criterio del record più frequente. Il valore che compare con maggiore frequenza tra i record analoghi è considerato il valore di riferimento.

 

Gestione delle differenze di formato

Gestire dati errati con un sistema di business intelligence

Oltre al problema degli errori, il caricamento dei dati da più fonti deve tenere in considerazione quello della diversità dei formati di rappresentazione delle informazioni.

Nel caso delle stringhe è necessario porre attenzione alla codifica dei caratteri (ASCII, UTF-8, UTF-16, ecc), utilizzando come formato finale la codifica più estesa, per evitare la perdita di informazioni o una loro errata rappresentazione.

Nel caso delle date (ma anche delle valute o dei numeri decimali) ci sono da considerare altri aspetti, come i possibili differenti formati usati su più sistemi. Per fare un esempio, la stessa data può essere rappresentata in diverse notazioni:

25/01/1973
1973-01-25
01/25/1973
25/01/73

In questo caso si sceglie un formato di riferimento e i confronti vengono effettuati una volta convertiti tutti i valori nel formato scelto.

 

Valori interdipendenti e correzione degli errori

Gestire dati errati e correggerli

Il valore di un determinato campo può essere dipendente dal valore di altri: è quindi possibile verificare la bontà del suo contenuto per un determinato record, verificando che tale dipendenza sia soddisfatta. Un esempio classico è, anche in questo caso, il codice fiscale. Esso è infatti dipendente dai dati anagrafici della persona. Prendendo come esempio la data di nascita, possiamo facilmente stabilire quali dei tre record riportati di seguito possono essere considerati corretti:

CSTGPP73A25I452U 25/01/1973
NDDPRI82E30A859Z 31/05/1982
CSTGPP00A01G732I 01/01/2000

Semplificando leggermente, in quanto ininfluente ai fini dell’esempio, la parte in grassetto del codice fiscale è ricavata dalla data di nascita concatenando:

  • le ultime due cifre dell’anno
  • il mese, rappresentato con una lettera (nell’esempio: A=Gennaio, E=Maggio)
  • il giorno

Appare subito evidente come il secondo record presenti un’incongruenza e possa essere marcato come errato. Se si ha la certezza della correttezza di uno dei campi, è possibile correggere l’altro in accordo. Altrimenti il record può essere marcato come “dubbio”.

Durante la fase di selezione dei valori di riferimento per un gruppo di record analoghi, i record dubbi dovranno necessariamente avere un peso minore rispetto a quelli che non lo sono. Combinando una o più di queste tecniche è possibile ridurre il numero di record riconosciuti erroneamente come differenti, unificando correttamente le informazioni provenienti da più fonti.

In conclusione, possiamo dire che non è sempre possibile gestire dati errati e correggere automaticamente tutti gli errori, ma sicuramente si può ridurre drasticamente il numero di casi da gestire in modo manuale, direttamente durante la fase di ETL del processo di Business Intelligence.

Vuoi conoscere meglio la Business Intelligence, come si utilizza, a cosa si applica e i vantaggi strategici che comporta per le organizzazioni? Clicca sul pulsante qua sotto e scarica la guida completa alla Business Intelligence per le aziende (vantaggi, KPI da non perdere e molto altro). Ti basta un clic:

Guida di Business Intelligence per le aziende

Share this post

   

Commenti

New call-to-action

Iscriviti alla Newsletter

Condividi questo blog