Newsgroup: it.comp.appl.access
Titolo: [Semi-OT] "normalizzare" un nominativo

L'altro giorno stavo discutendo con uno dei responsabili del sistema
informativo dell'azienda per la quale (per il momento) lavoro.
La discussione si è fatta interessante (almeno per me) quando ho visto che
la tabella delle anagrafiche contiene un campo nel quale va a finire una
versione "normalizzata" del nominativo.
Faccio un esempio per chiarire.
Supponiamo che una persona si chiami "Giovanni Serbelloni Saccà" (con
l'accento sull'ultima "a".
Per questo nominativo, nel campo "normalizzato" andrebbe a finire una
stringa simile alla seguente: "GIVANISERBELONISACA".
Non capendo, io, l'utilità di questa cosa, ho chiesto al responsabile di
cui sopra e mi ha spiegato che la procedura (della quale stavamo parlando
insieme) provvede ad effettuare una "normalizzazione" dei nominativi ad
esempio eliminando spazi, lettere doppie, prendendo solo la prima vocale di
uno iato, sostituendo una lettera accentata con la relativa non accentata e
così via.
Mi è stato spiegato che l'utilità della cosa deriva dal fatto che si vuole
un livello maggiore di tranquillità rispetto al semplice controllo del
codice fiscale per evitare di trovarsi con nominativi similiari relativi
alla stessa persona fisica.
Dopo avere mostrato un certo stupore, mi è stato anche detto che questa è
una tecnica molto utilizzata.
Vorrei sapere da voi se eravate a conoscenza di simili metodologie e se le
avete viste applicate da qualche parte.
-- 
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution


Mah, la cosa potrebbe avere un certo senso, se poi magari si usa ad esempio la funzione di Levenshtein o qualche altra funzione di comparazione simile per trovare nominativi similari e avvisare l'utente.
Sinceramente non l'ho mai vista implementata in questo modo, l'unica cosa che mi è stata chiesta una volta era un campo aggiuntivo alla ragione sociale per una velocità di ricerca, es. la tua ragione sociale è 
PBSoft SRL di Gabriele Bertolucci... ma tutti di te ricodano solo che ti chiami Bertolucci, pertanto compilerai il cognome.
Altro esempio.
Az. Agricola Vattelapesca SS potrebbe essere codificato come sola "vattelapesca", evitando tipologia, natura giurididica ecc.
Ciao,
Max

 skype:pbsoftsolution
Ciao, Carlo 

Ciao Gabriele.
E' un pò come avere il codice HASH della stringa...
Purtroppo in IT ci sono 600000 Omocodie di C.F. che in effetti fanno
impazzire, molte dovute
ai nuovi Nominativi Extracomunitari(beh anche tedeschi o nord europei) con
solo Consonanti
oppure con pochissime lettere come i nomi Cinesi...
In ogni caso nel giro di breve dovrebbe essere inutile il ministero deputato
ha in previsione di
sostituire il vecchio sistema di codifica del C.F. Alfanumerico con un nuovo
sistema UNIVOCO
NUMERICO un pò come un Counter... ;-)
Per questo motivo l'algoritmo in questione dovrebbe in qualche modo
sopperire alle OMOCODIE.
Il problema è che in questo modo la PK dovrebbe essere DOPPIO_CAMPO
altrimenti l'utilità
potrebbe esserne compromessa in parte.
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.alessandrobaraldi.it
---------------------------------------------------------------------------

"Gabriele Bertolucci" <"info[at]pbsoft[dot]it"> ha scritto nel messaggio 
news:140d51n5i8585.1...@40tude.net...

Ciao Gabriele... probabilmente (anzi sicuramente) non lo sai... io gestisco 
banche dati CV abbastanza grandi come mole di dati... pensa a qualcosa come 
800mila e rotti CV... quindi con altrettanti CF...
il problema quindi dovrebbe interessarmi, ma se pur in IT come detto da Ale 
vi è tutta quella roba duplicata (omonicode) a me è capitato appena 2 volte 
in tutti questi anni, e per di+ con un extracomunitario che lo avrebbe 
cambiato di quì a una settimana, per cui mai affrontato per bene... ma 
leggendo mi chiedo :
un ESPOSITO GENNARO che avrebbe un normalizzato pari ad es. a ESPOSITGENAR, 
nel suo omonimo caricato, non avrebbe lo stesso campo valorizzato visto che 
è un processo standard? quindi o CF (PK) uguali, o CF & Campo_Normalizzato 
(PK) uguali, non è la stessa cosa?... la normalizzazione o qualsiasi 
stratagemma usato, o serve a rendere univoco un elemento o non serve ti 
trovi?
forse non avrò capito bene io, quindi magari se non ti scoccia, spiaga 
meglio...
-- 
---
Ciao
Pablitomf 

 meglio...
Credo che il problema nasca dal fatto che nell'anagrafica in questione
vengono fatti inserimenti da parte di diverse procedure e, soprattutto, di
diversi (tanti) operatori che non pongono poi tutta questa attenzione a
quello che fanno.
Aggiungi poi che anche le persone che forniscono i dati da inserire, spesso
omettono di informare della presenza di un secondo o terzo nome, oppure te
ne danno uno "derivato" come potrebbe accadere per "Antonino" e "Antonio".
In questi casi il sistema che mi hanno mostrato, in effetti, potrebbe
aiutare, ma non poi cosě in maniera determinante.


 altrimenti l'utilità potrebbe esserne compromessa in parte.
In che modo?


 In che modo?
Beh quale campo usi per avere i JOIN...?
;-)
Concordo anche con la giusta osservazione di Maurizio... Nomi
Uguali(che restituiscono C.F. uguali) restituiscono Stringhe Uguali
anche con una funzione che non fa altro che ricommettere l'errore del
C.F. ... non è un gran sistema a meno che la Funzione in questione non
sia Meglio di quella del Ministero...
;-)
Il modo più corretto è una PK univoca come un GUID o un progressivo...
ma sempre gestito dal ministero.
@Alex


Perfetto... allora io una soluzione l'ho pensata... vedi se ti piace...
Tabella :
CF (pk)... non i 16 caratteri standard... ma 18 (ti spiego)
....
all'inserimento CF apri recordset filtrato sullo stesso contandolo... se il 
risultato č 0 vuol dire che č il primo inserito di quel tipo per cui in CF 
inserisci il CF & 01... se č >0 in CF inserisci CF & 
format(totcontato+1,"00")...
in questo modo di certo il CF č univoco (hai 2 cifre finali, quindi 99 
ipotetici duplicati per CF)
ovviamente parsando CF puoi poi ottenere il CF vero...
-- 
---
Ciao
Pablitomf

 ovviamente parsando CF puoi poi ottenere il CF vero...
A questo punto, se proprio vogliamo scialare, prevedi il campo di 19
caratteri visto che, per definizione di omocodia sul codice fiscale,
possono esistere 128 codici omologhi a quello di base.


 PBsoft di Gabriele Bertolucci
Ma no... usiamo l'esadecimale... così essendo già Alfanumerico il CF
hai a disposizione con 2 Char(00÷FF) quindi 255 che è maggiore di 128...
Oppure 128 con la possibilità di avere il Segno +/-
Ma quanto tempo da perdere avete...?
;-)


 Ma quanto tempo da perdere avete...?
wema tu non stavi trollando con Thomas? jà che quà abbiamo da normalizzare i 
CF :-D
Cmq Gabriè, dillo ai tuoi responsabili di sistema, che gli abbiamo risolto 
il problema ;-)

 jà che quà abbiamo da normalizzare i CF :-D
Un lavoraccio ...
Pensa a me invece che devo fare le borse e tra 36 ore sarò al caldo al
mare... ;-)


 mare... ;-)
normalizzerai i reflussi delle maree o ottimizzerai la vista sui toples??... 
bhè no, più probabile che andrai in overflow sullo shopping della signora. 
Mi raccomando solo a una cosa... debugga bene i processi prima di partire, 
non vorrai mica mandare in crash il sistema su un loop 0 per la visa? :-D
Buone vacanze Alessà 


Cioè Giuseppe Bianco e Giuseppe Bancò sono la stessa persona?
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access