Newsgroup: it.comp.software.database
Titolo: Angrafica persone

Salve a tutti !!!
Volevo realizzare una database con un file di anagrafica per persone
fisiche. Pensavo ad una tabella che potesse ospitare i dati di un numero
considerevole di persone (sia italiani che non). Mi sono pertanto
chiesto
quali informazioni utilizzare per realizzare la chiave primaria della
mia
tabella.
Ho pensato:
NOME
COGNOME
DATA di NASCITA
LUOGO di NASCITA
Ovviamente se si presentano casi del tipo "A Milano nello stesso giorno
sono
nati due Mario Rossi", mi occorrono altre informazioni per definire la
chiave primaria.
La prima idea è stata il codice fiscale, ma gli stranieri non hanno il
codice fiscale. Inoltre non tutti dispongono del codice fiscale (ad
esempio
i bambini non ce l'hanno).
Altre informazioni come residenza o numero di telefono non possono
essere
utilizzate come chiave primaria in quanto si tratta di informazioni
variabili e possono creare situazioni di ambiguità.
Nessuno si è mai posto un problema del genere?
Quale informazione si può usare per risolvere il problema?
Grazie
Cricca
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Quale informazione si può usare per risolvere il problema?
tutti ce lo siamo posti e abbiamo risolto con un codice persona
assegnato tramite contatore.
Ciao
Matteo
PS il codice fiscale viene assegnato appena nati...

 PS il codice fiscale viene assegnato appena nati...
Perfetto! Non lo sapevo.
Ma dimmi come riesci a distinguere un Mario Rossi da un altro?
Se mi permetti faccio un caso pratico.
Prendiamo l'ufficio anagrafe. Uno dei due Mario Rossi muore.
Un figlio si presenta in anagrafe per segnalare il decesso del padre.
In anagrafe non possono certo sperare che il figlio si ricordi il numero
progressivo che l'ufficio anagrafe ha assegnato al padre.
In anagrafe per quale Mario Rossi registrano il decesso?
La risposta che mi attendo è "il codice fiscale".
Allora complichiamoci la vita e supponiamo che i due Mario Rossi invece di
nascere lo stesso giorno a Milano, nascono in Svizzera a Chiasso.
Ora rifaccio la domanda: In anagrafe come li distinguono?


L'ultima lettera è un carattere di controllo: AFAIK in caso di Codici
Fiscali "omonimi" in quello più recente viene modificato il carattere di
controllo per renderlo univoco. Cmq le probabilità che ci siano due
persone nate esattamente lo stesso giorno nello stesso comune (ogni
comune ha un suo codice, ed è anche presumibile che nei grandi centri
come Milano ci possano essere delle sotto-aree) con un nome e cognome
che possono generare la stessa sestina (tre lettere per il cognome e tre
lettere per il nome), è molto bassa ed è sufficiente cambiare il
carattere di controllo.
Per gli stranieri penso che al posto del comune venga assegnato un
"codice nazione".
La normativa è cambiata molto da quando è stato introdotto il codice
fiscale (inizialmente non era univoco).
L'unico che fa fede è quello rilasciato dal Ministero delle Finanze.
M.

 ha scritto nel messaggio 
news:sCoie.1399010$35.52...@news4.tin.it...


Ora rifaccio la domanda: In anagrafe come li distinguono?
Posta in questi termini direi che, in generale, non li distinguono. Cioč,
il database deve necessariamente distinguerli, ma non č detto che, dato un
insieme qualunque di attributi, li si possa distinguere nel database.
Stando all'esempio, si potrebbe tentare di distinguerli in base al nome del
figlio. Se entrambi hanno avuto un figlio con lo stesso nome, data
l'incompenetrabilitŕ dei corpi, immagino si arriverebbe a distinguerli
sulla base di chi ha abitato ad un certo indirizzo ad una certa data.
Se, alla fine, non si riesce a trovare nessun elemento che li distingua, si
puň cominciare che si tratti della stessa persona registrata due volte
(caso pur possibile, e che l'esistenza di un identificativo univoco non
serve ad eliminare).
Tutto dipende comunque da quanti e quali dati sono disponibili nel database
e noti nell'universo per ogni individuo.
Ciao.

 La risposta che mi attendo è "il codice fiscale".
divago...
quando vado a rinnovare la carta di identità mi chiedono sempre il 
domicilio...non mi hanno mai chiesto il codice fiscale...

 ha scritto nel messaggio
news:arpie.909206$b5.39...@news3.tin.it...

una cosa e' idenfificare il record, un altra la persona
id autoincrement identifica il record (sempre)
CF lo puoi usare come indice per impedire  2 mario rossi
il resto sono cavoli tuoi

 il resto sono cavoli tuoi
IMHO č impossibile creare una chiave candidata per un entitą persona 
partendo dai dati anagrafici; il discorso di utilizzare come chiave 
univoca il CF cade a fronte di un qualsiasi cittadino straniero(CF -> null)

 se il cittadino straniero e' regolare per l'italia ha il CF
si sava parlando di una anagrafica in generale o cosa?

 ha scritto nel messaggio
news:xkqie.909567$b5.39...@news3.tin.it...

ste palle


 l'utilizzo di serial)
Sono d'accordo. Io di solito uso il CF come rafforzo delle regole di
verifica dei doppioni.
M.

Il mio obiettivo in questo thread è trovare un meccanismo che possa valere
come regola generale.
Dalle informazioni che ho raccolto, mi pare di aver capito che anche agli
stranieri che vengono a vivere in Italia gli viene assegnato un codice
fiscale.
Personalmente non ho informazioni in merito (vedrò di procurarmele).
Il fatto che in precedenza abbia fornito l'esempio dell'ufficio anagrafe di
una città voleva solo essere un modo per tradurre in pratica un problema di
natura più teorica. Forse non sono riuscito pienamente a rendere l'idea del
problema e allora ci riprovo con un nuovo esempio.
Supponiamo di dover creare l'angrafica dei pazienti di un ospedale (dove
almeno in una grande città passa un numero considerevole di persone). Ogni
persona nuova che arriva verrà ovviamente inserita in anagrafica. Di queste
persone si cercherà di raccogliere dati come Nome, Cognome, Luogo e Data di
nascita a altro ancora. Ma se nel nostro database utilizziamo come chiave un
banale progressivo numerico, temo che possano sorgere problemi
potenzialmente molto pericolosi. Supponiamo che uno dei nostri Mario Rossi
si presenti al pronto soccorso per l'ospedale dove viene registrato e magari
gli viene diagnosticata un'allergia agli antibiotici. Poi in un secondo
tempo si presenta il secondo Mario Rossi. Quando gli prendono i dati come
fanno gli impiegati a sapere che il secondo Mario Rossi non è il primo?
Magari viene scambiato per il primo e avrebbe bisogno di una tempestiva cura
di antibiotici. Ritengo che sia indispensabile poterlo distinguere dal
primo.
Sento già qualcuno che dice "ma c'è sempre il codice fiscale?".
Allora torno a riportare la modifica al problema: supponiamo che i due Mario
Rossi protagonisti della storia siano nati entrambi a Chiasso nella stessa
data e si trovano in Italia solo di passaggio, perchè magari vengono
periodicamente in vacanza a Milano. Qui non c'è codice fiscale che possa
aiutarci. Ora capisco che si tratti di una situazione limite, ma in una
struttura dove passano quotidianamente decine di migliaia di persone, il
rischio che anche un caso limite a bassa probabilità possa manifestarsi un
giorno o l'altro non è poi così trascurabile.
Quindi credo il problema da me posto non possa essere risolto con un
qualsiasi codice numerico progressivo e nemmeno con un dato come il codice
fiscale che non tutti hanno. Sottolineo inoltre che dati variabili come
residenza, numero di telefono, ecc.. non possono essere usati come campi
chiave. Se il primo Mario Rossi la prima volta che va al pronto soccorso
abita in via delle Mele, poi cambia casa, va in via delle Pere, quindi torna
al pronto soccorso, se ussano la residenza come chiave di accesso potrebbero
pensare che non è lo stesso Mario Rossi.
Attendo commenti al riguardo
Ciao
Cricca

 data e si trovano in Italia solo di passaggio
Per quanto riguarda i cittadini italiani il problema ovviamente non si 
pone.
Nel caso di un ricovero neppure perchè tu non sei più "Mario Rossi" ma 
il numero della tua cartella (che è univoco).
Per il pronto soccorso non sò come funziona, ma potrebbe essere 
registrata la tessera sanitaria della persona (giusto poi per sapere 
anche se appartiene ad un paese convenzionato tramite modello E 111) o 
chessò numero carta identità (tanto si tratta di primo soccorso, quindi 
in quel frangente sicuramente non cambierà carta d'identità). Poi 
generalmente tutto avviene in modo immediato con due possibili esiti: ti 
mandano a casa perchè era una cavolata (taglio, contusione, piccola 
bruciatura, ecc..) oppure vieni ricoverato (con relativa cartella 
clinica univoca)
Comunque al di la del caso specifico, quello che tu cerchi è un codice 
che permetta di distinguere in modo univoco una qualsiasi persona del 
globo..... non esiste. :-)
Ciao
Gianni

 globo..... non esiste. :-)
Hash del DNA? ^_^
-- 
Borland C++ Builder Mailing List:
http://tux.linuxtime.it/mailman/listinfo/bcb-it

 Hash del DNA? ^_^
Potrebbero esserci anche due o più DNA uguali..... della serie, 
facciamoci male :D
Ciao
Gianni

problema e allora ci riprovo con un nuovo esempio.
Come ti è stato già detto, una cosa è distinguere un record da un altro in
un database, un'altra distinguere una persona dall'altra nella vita reale
(o, che è lo stesso, identificare quale record del database si riferisce a
quale persona nella vita reale).
Per il primo problema, la "regola generale" è la costruzione di un codice
univoco qualunque (di cui un numero progressivo è l'esempio più semplice).
Per la seconda, la "regola generale" è mettere insieme quanti più dati si
possono, finché sperabilmente non si arrivi ad un dato che consente la
differenziazione ("ma tu sei il Cricca della Rosa, no, non quella del
Mulino, quell'altra che stava a Porta Grande, che poi è morta, poverina,
l'anno che il Francia è scappato con la Pazza?").
Il "problema di natura teorica" è solo il primo, ed ha la soluzione
semplice detta. L'altro è un problema pratico e non ha, in generale, una
soluzione. O, perlomeno, non una soluzione agibile allo stato attuale delle
cose, perché di per sè è molto semplice: marchi tutti alla nascita con un
trasponder e crei un database anagrafico mondiale. Una passatina sotto il
rilevatore ed ecco che sappiamo chi sei, con chi vai, e quante pippe ti
facevi da piccolo. Si tratta, temo, solo di aspettare.
D'altronde, anche senza codice univoco bioimpresso, nella vita pratica
risulta che, più volte di quanto sarebbe desiderabile, riescono comunque a
sapere quante pippe ti facevi da piccolo.
Ciao.


In ogni database che si rispetti l'obiettivo della chiave primaria non è 
semplicemente quello di identificare un record da un altro.
Atrimenti perchè esisterebbero record con chiavi composte da più campi?
Ogni tabella deve avere una chiave primaria significativa. Per significativa 
si intende che il loro contenuto deve essere sgnificativo e porto un esempio 
a sostegno di quanto dico:
Supponiamo di voler fare un tabella con l'elenco dei comuni italiani e 
relativo numero di abitanti.
Io la tabella la farei così:
Provincia
Comune
Numero di abitanti
dove Provincia e Comune sono campi chiave. Questo significa che non possono 
esistere due record con lo stesso comune e la stessa provincia. Se si 
mettesse un campo contatore che faccia da chiave rischieremmo di avere due 
record che fanno riferimento allo stesso comune nella stessa provincia come 
nel caso descritto qui sotto:
Contatore    Provincia    Comune    Num.Abitanti
765                MI            Arcore        7456
834                MI            Arcore        3455
Se qualuno interroga il database perchè vuole sapere qual'è il numero di 
abitanti di Arcore, quale numero di abitanti deve considerare quello giusto?
Spero che conveniate con me che la chiave primaria di una tabella non deve 
essere definita da un banale contatore. Questa se vogliamo è una regola 
generale della progettazione dei database e non una considerazione valida 
solo per l'esempio qui sopra riportato.
Attendo conferme o smentite.
Cricca 

 
C'è una lunga diatriba che pone chi a favore e chi contro i campi
contatore nelle tabelle. Il buon Davide Bianchi ad esempio è del tuo
stesso avviso (
http://www.soft-land.org/cgi-bin/doc.pl?doc=documenti/pk
).
Io mi ritengo a metà via, la cosa la valuto volta per volta a seconda
delle esigenze.
M.



Se vuoi avere un unico campo come chiave primaria, si puo' fare anche
id SERIAL PRIMARY KEY,
...
UNIQUE(Provincia, Comune)
Ma non credo valga la pena (il database deve mantenere due indici).
Saluti  Manlio Perillo

essere definita da un banale contatore.
Continui a saltare da un caso all'altro e da un caso particolare a tutto
l'universo.
Certo che no, un contatore o un'altra chiave univoca "inventata", che non
abbia qualche corrispondenza nel sistema sono, in generale, da evitare.
Quando non si può fare diversamente, la si mette. Normalmente, questo
comporta un "acting out" del modello nel mondo reale: ecco che tutti gli
italiani hanno, oltre a nome e cognome, codice fiscale, codice di
assistenza sanitaria ecc., senza che questi siano, originariamente,
attributi propri di una persona.
Se poi proprio è necessario introdurre un codice univoco che "non esiste in
natura", la mia opinione è che convenga costruire un codice mnemonico,
magari ideato dallo stesso utente (i nickname delle caselle postali, tanto
per fare un esempio di applicazione che funziona).
Ciao.

 porto un esempio a sostegno di quanto dico:
Quindi provincia e comune in totale una 80ina di caratteri?
se nella tabella persona vuoi avere questa informazione è meglio
80 car o un campettino numerico di 4 cifre?
Ma secondo te perchè tutte le applicazioni gestionali hanno un campo
"codice cliente" e non usano invece come chiave primaria
ragione sociale + località + partita Iva + cognome da nubile della donna 
delle pulizie
Saluti

si invece!
Ma l'obiettivo del database č quello di essere un modello di qualche
sistema reale. Sicché, la chiave primaria deve, in prima analisi,
corrispondere a qualche proprietą degli oggetti reali del sistema che
rappresenta.
Ciao.


Se è cosi chiedo scusa,
io pensavo che l'obiettivo del database fosse quello di custodire dati 
organizzati,
comunque valuta anche la seconda parte del mio post.
Saluti

 abitanti di Arcore, quale numero di abitanti deve considerare quello giusto?
Il tuo modello sopra a mio avviso presenta un GRAVE bug in quanto manca 
il CAP che identificherebbe in modo univoco i due comuni Arcore.
Comunque per la creazione della chiave primaria si procede in questo 
modo: dal modello si identificano le chiavi primarie candidate. Si fanno 
tutte le considerazioni del caso e, se le chiavi candidate non 
soddisfano le condizioni, se ne genera una.... come? dipende da caso a caso.
Ciao
Gianni

80 car o un campettino numerico di 4 cifre?
"Meglio" rispetto a che? Evidentemente, il numero di caratteri necessario
non è l'unica metrica possibile.
Se vuoi essere sicuro che ad ogni elemento dell'insieme corrisponda uno ed
un solo record, aggiungere un campo che comunque, da solo, rende unico il
record non è, in generale, l'idea migliore che possa venire in mente (posta
vera l'ipotesi dell'esempio, che non esistano comuni diversi nella stessa
provincia con lo stesso nome, del che non sono sicurissimo).
Come poi riferire i record di una tabella all'interno di un'altra è un
altro problema, che avrà un suo "meglio", secondo diversi parametri. I due
"meglio" potranno anche essere in conflitto, e in qualche modo si sceglierà
che cosa fare. Aggiungere, in ogni caso, sempre, un codice identificativo
univoco non mi pare necessariamente la soluzione ideale.
Ciao.

 rappresenta.
questa è una cazzata...
Se vuoi convincerterne prova a pensare alle transazioni bancarie...


io non ho mai detto di aggiungere, in ogni caso, sempre, un codice 
identificativo,
ma parlavo dei due esempi specifici.
Ti dò ragione se parliamo per esempio di una tabella articoli dove il codice 
dell'articolo,
già di per sè univoco può benissimo essere la chiave primaria.
Saluti

 già di per sè univoco può benissimo essere la chiave primaria.
tutti i codici esistenti sono stati creati per sopperire alla mancanza 
di una chiave candidata...

, scriveva:


Eh, e allora?
Vuoi dire che non ci sono oggetti reali, che non hanno proprietà, che il
database delle transazioni non è un modello di qualcosa che avviene nel
mondo reale, o cosa?
Francamente, sarà che di tecnica bancaria ne so meno che nulla, ma non vedo
in che cosa le transazioni bancarie inficino una considerazione generale
generica e possibilista come quella che ho espresso. In prima analisi, si
cercherà di vedere quali siano le chiavi primarie "naturali" candidate e,
se non sono soddisfacenti, si agirà di conseguenza. Puoi dire che, in caso
di transazioni bancarie, si faccia qualcosa di diverso? che cosa? e perché?
Ciao.

 mondo reale, o cosa?
No che la chiave non è ottenuta da oggetti reali ma da un semplice
progressivo...
Secondo la tua logica un bonifico fatto da me verso te oggi per cento
euro dovrebbe essere identificato da una chiave più o meno del genere
matteooooo2giovannizezza20050520Euro100.
Le basi dati devono esere costruite per gestire efficentemente i dati
non per rispecchiare le proprietà della realtà.
In tantissimi ambiti il contatore non viene utilizzato perchè esistono
dei "contatori" già predisposti da altri(ABI e CAB, Codice avviamento
postale,ecc ecc
PS scusami ... penso di averti inviato una mail personale
...GoogleGroups mi incasina spesso