Verifica un indirizzo

La migrazione di anagrafiche clienti numerose: le differenze di struttura dati (1 Di 3)

La migrazione di anagrafiche clienti è un’operazione sempre più frequente in ambito aziendale. Essa diventa necessaria ad esempio in caso di migrazione di sistemi operativi, di scambio dati fra sistemi diversi come il CRM verso il datawarehouse, o nell’ambito della acquisizione di aziende il che richiede il trasferimento dei clienti dal sistema acquisito al sistema corrente.

Questa operazione presenta delle criticità tipiche specialmente se l’anagrafica risulta essere abbastanza numerosa (cioè al di sopra dei 100.000 record). Una delle difficoltà che più frequentemente si incontra è la differenza di struttura dati fra il database sorgente ed il database target.

Le anagrafiche clienti rappresentano dati semi strutturati, come nomi, cognomi, ragioni sociali e indirizzi. Specialmente l’indirizzo è spesso rappresentato in grande libertà e la struttura selezionata da ogni singolo sistema è diversa dalle altre.

sistemi informativi più moderni tendono ad avere requisiti più stringenti e rappresentano l’indirizzo in modo più dettagliato. Ecco alcuni esempi:

 DB SORGENTEDB DESTINAZIONE
INDIRIZZOIl campo LOCALITÀ è rappresentato con un unico valore. Per esempio:
INDIRIZZO: “VIA CAPRERA, 3/A”
Il campo INDIRIZZO è rappresentato in più campi separati. Per esempio:
INDIRIZZO: “VIA CAPRERA” NUMERO CIVICO: “3/A”
oppure:
DUG: “VIA” TOPONIMO: “CAPRERA CIVICO: “3” INT: “A”
LOCALITÀIl campo LOCALITÀ, o comune, è unico e contiene il COMUNE, la FRAZIONE o entrambi: Per esempio:
LOCALITÀ: “PARONA VERONA”
Il campo LOCALITÀ distingue il COMUNE e l’eventuale FRAZIONE o LOCALITÀ di dettaglio.
Per esempio:
COMUNE: “VERONA”
FRAZIONE: “PARONA”
COORDINATE GEOGRAFICHEIl sistema sorgente è privo di riferimenti geografici.Il sistema Target utilizza le coordinate geografiche.
CODICI TERRITORIALI Il sistema target potrebbe richiedere codici non presenti i input, come:
CODICE ISTAT
CODICE CATASTALE
CODICE REMI
CODICE STRADA O LOCALITÀIl sistema SORGENTE contiene dati testuali “liberi” non uniformati:
Ad esempio:
LOCALITÀ: “DESENZANO S GARDA”
LOCALITÀ: “DESENZANO DEL GARDA”
LOCALITÀ: “DESENZANO S GARDA”
LOCALITÀ: “DESENZ. SUL G.”
Il sistema target potrebbe avere uno stradario di riferimento, in cui ogni elemento è codificato anche numericamente. Per evitare dizioni difformi della stessa località:
ES: LOCALITÀ: “DESENZANO DEL GARDA”
CODLOC: 12668

La produzione dunque dei dati necessari al sistema target può presentare delle complessità che rientrano i alcune tipologie:

  • il dato necessario non è presente in input e va ottenuto analizzando il dato in input
    • Ad esempio: il codice ISTAT del comune può essere ottenuto verificando la validità del campo COMUNE
  • alcuni campi di input vanno elaborati e scomposti per poter essere utilizzati nel sistema target. Ad esempio:
    • INDIRIZZO INPUT: “STRADA STATALE 235, KM 35 C/O MANEGGIO L’ARCOBALENO”
      • DUG_OUT: “STRADA STATALE”
      • TOPONIMO_OUT: “35”
      • NUM_CIV_OUT= “KM 35”
      • ALTRO= “C/O MANEGGIO L’ARCOBALENO”
    • VIA MAZZINI ANG. VIA ROSA NR. 16
      • DUG_OUT: “VIA”
      • TOPONIMO_OUT: “GIUSEPPE MAZZINI”
      • NUM_CIV_OUT= “16”
      • ALTRO= “ANG. VIA ROSA”
  • il dato in ingresso va elaborato, ad esempio:
    • LOCALITÀ: SAN FLORIANO (VR) deve diventare FRAZIONE: PARONA, COMUNE: SAN PIETRO IN CARIANO

Affrontare manualmente e senza un approccio questo tipo di trasformazione può rivelarsi oneroso e soprattutto essere destinata a notevoli problematiche che emergono ad una ad una durante il processo, o purtroppo come spesso avviene anche alla fine dell’operazione, quando è troppo tardi per porre rimedio.

Inoltre nel contesto di anagrafiche numerose, il numero di micro situazioni da risolvere va moltiplicato per il numero di record, il che porta ad una quantità di lavoro difficile o impossibile da portare a termine nei tempi previsti.

Che cos’è la normalizzazione:

La normalizzazione è un’operazione che si applica ai dati semi-strutturati come quelli che compongono le anagrafiche: nomi, ragioni sociali o indirizzi.

La operazione di normalizzazione ha lo scopo di acquisire in input un’informazione data in modo libero (cioè potenzialmente contenente errori, informazioni mancanti, abbreviazioni o informazioni ridondanti) e di scontrarla (cioè verificarla) con un database di riferimento.

A seguito di tale operazione ogni elemento fornito in input viene riferito ad un elemento presente nel database di riferimento e viene di conseguenza geocodificato (se parliamo di indirizzi, ovvero ad ogni elemento viene associato un valore unico di testo ed un codice), oppure scartato.

I vantaggi di questa operazione, quando applicata agli indirizzi sono:

  • Ogni elemento viene fornito in output nella sua versione ufficiale e corretta. Ad esempio:
    • “V.LE” “VLE” “VIAL” “V.le ” “Viale” sono tradotti in “VIALE”
    • “g.mazzin” “GIUSEPPE M.” “MAZZINI” sono tradotti in “GIUSEPPE MAZZINI”
  • Poiché ogni elemento è stato scontrato con un database di riferimento è certa sia la sua correttezza che la sua esistenza. Ad esempio:
    • “VIA SANDRO PERTINI” a “TORRI DEL BENACO” pur essendo scritta bene (‘) non verrà considerato un valore correttamente normalizzato, poiché tale nome di strada non esiste in quel comune.
  • Poiché ogni elemento è stato scontrato con un database di riferimento contenente informazioni aggiuntive, ogni elemento può essere arricchito di informazioni mancanti o utili. Ad esempio:
    • “VIA VALPOLICELLA 145” “SAN FLORIANO” “VR” è un indirizzo apparentemente completo e utile per alcuni fini. Sottoponendolo a normalizzazione potremo scoprire:
      • (ASSENTE IN INPUT) COMUNE_CORRETTO: “SAN PIETRO IN CARIANO
      • FRAZIONE_CORRETTA: “SAN FLORIANO”
      • (ASSENTE IN INPUT) CAP: “37029”
      • (ASSENTE IN INPUT) CODICE_ISTAT_COMUNE: “005 – 023 – 076”
      • (ASSENTE IN INPUT) CODICE_CATASTALE: “I109” (NUOVO) “D6DW” (VECCHIO)
      • (ASSENTE IN INPUT) COORD_GEOGRAFICHE: “45.5092215000, 10.90343609510”
      • (ASSENTE IN INPUT) ZONAEXOMI: “B1” (ALL’INTERNO DEL COMUNE)
  • Un buon normalizzatore è in grado di intercettare un buon numero di indirizzi affetti da errori più o meno gravi, quali:
    • “DESENZNO DEL GARDA” diventa “DESENZANO DEL GARDA”
    • CAP errati in input vengono corretti
    • Eventuali PROVINCE assenti o errate in input vengono CORRETTE
    • Nomi di strade errati o incompleti vengono corretti:
      • (ASSENTE IN INPUT) “VIA GINO BARTINI” diventa “VIA MONSIGNOR GINO BARTINI
      • “STR. STALE 113” diventa “STRADA STATALE 113”

Conclusioni:

In conclusione sottoponendo una qualunque anagrafica ad una operazione di normalizzazione se ne ottiene una versione verificata ed arricchita, con i seguenti vantaggi:

  • Dalla versione normalizzata che produce il massimo dettaglio di informazione e di struttura è possibile generare una proiezione adatta alla alimentazione di un nuovo sistema con i suoi requisiti di dettaglio
  • Post normalizzazione si esegue anche la selezione fra i record indirizzo validi e quelli invalidi. Limitando di molto le operazioni di correzione e validazione manuale.
  • Si procede quindi ad una alimentazione del nuovo sistema (o del sistema target) con dati verificati, completi e corretti.

Oxygen Icon Box

Street Master Italia SRL
Via Gino Bozzini 3/E
37135 - Verona

Oxygen Icon Box

supporto@streetmaster.it

Oxygen Icon Box

+39 045 8947375

Scarica AppFAQ
© 2024 Street Master. All rights reserved | P.IVA 04375530237 | Privacy e Cookies
envelopephone-handsetmap-markercrossmenu
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram