Newsgroup: it.comp.appl.access
Titolo: Impedire duplicazione dati su più campi

Ciao a tutti, il mio  problema è questo:
Ho una tabella con i seguenti campi COMUNE FOGLIO MAPPALE SUPERFICIE
quando inserisco i dati ad esempio  MILANO      15               23
4.900
per un determinato soggetto vorrei che tale dato non mi sia più concesso di
inserirlo e
che con un msg mi dica ovviamente che il dato è stato già inserito! Credete
sia possibile?
Poi cè un secondo problema,ma risolvendo questo l'altro va di seguito.
Grazie in anticipo.

 ha scritto nel messaggio
news:_9Q59.58381$n04.1...@twister2.libero.it...

La tua domanda è un pò come dire devo realizzare la gestione di un'agenzia
IMMOBILIARE
come faccio per evitare doppioni...?????
La struttura dei DB Relazionali se ben realizzata ti da una mano in tal
senso, è chiaro
che dipende in che modo hai realizzato l'approccio ai dati, e quì la cosa si
complica....!!!
@Alessandro.

 Devo impostare questo vincolo in un unica tabella formata appunto da vari
campi ma quelli a cui voglio impostare il vincolo sono solo quei campi che
ho detto. Forse non è così difficile, o sbaglio?

 per un determinato soggetto vorrei che tale dato non mi sia più concesso
di ...
Se ho capito bene esiste una tabella che io chiamo "Dati Catastali" con i
campi "Comune", "Foglio", "Mappale", "Superficie", ecc...
Se non vuoi che in un dato Comune sia possibile inserire un duplicato di un
certo Foglio e Mappale basta impostare una chiave univoca (senza duplicati)
composta da "Comune", "Foglio"  e "Mappale" che chiamerai come ti pare.
Credo ci capire che poi assocerai tale record a quello di una (o più
persone) cui fa riferimento logico il Foglio-Mappale, se è così dovrai
creare una tabella "Anagrafe" che dovrà essere in relazione con la tabella
"Dati Catastali".
Spesso in lavori simili si scopre la necessità di creare relazioni
molti<->molti (la realtà delle cose a volte è questa), per cui necessita una
tabella intermedia da gestire con estrema attenzione.
Come già da altri detto comunque ci deve essere un attento studio a monte su
tutte le correlazioni tra i dati in modo da costruire una struttura di
Tabelle e Relazioni congruente con l'obiettivo da raggiungere.
C'è da lavorare e parecchio a tavolino prima di accendere il pc.
Buon lavoro,
                     Luigi.

Ciao,

Partiamo dall'inizio.
Cosa devi fare? Quali sono le funzioni che devi realizzare?
Provo a rispondermi da solo per quella poca esperienza che ho (visto che con
il catasto qualcosina ho avuto a che fare).
Esistono una serie di particelle catastali contraddistinte da Comune, Foglio
e Particella e fin qui tutto bene. Se vogliamo considerare poi il possibile
frazionamento che queste particelle subiscono a partire da un certo momento
allora dobbiamo introdurre per ogni particella i campi "data inizio
validità" e "data fine validità", in modo da poter ricostruire lo "storico"
di ciascuna particella. Se invece a noi interessa soltanto la fotografia al
momento della situazione e non lo storico, possiamo farne a meno, in caso di
frazionamento introdurremo le nuove particelle e cancelleremo la vecchia.
Dobbiamo poi catalogare tutti i possessori a varito titolo delle particelle,
l'anagrafe quindi. Poichè una persona può possede più particelle ed una
paticella può essere in comproprietà tra più persone la relazione tra
anagrafe e catasto sarà
molti<->molti. Questo non è realizzabile direttamente nel DB relazionali o
sicuramente in access, necessita una tabella intermedia che contenga
l'identificativo dell'anagrafico e quello della particella, in tale tabella
inserirei anche  con che titolo di proprietà (nuda, usufrutto, ecc...) si
riferisce l'anagrafico alla particella, la percentuale di proprietà e le
date di inizio/fine validità dell'associazione.
Lo schema delle relazioni sarebbe:
ANAGRAFE 1<->M INTERMEDIA M<->1 PARTICELLE
Devi studiare con molta attenzione i dati (campi) da creare per le varie
tabelle ponendo attenzione alle query che ti verranno richieste; prova a
pensare alle ricerche che dovrai fare ed immagina come rispondere.
Di più mi è difficile scrivere, ti mando questa anche all'e-mail privata,
visto che rispondo con qualche giorno di ritardo.
Bye, Luigi.

 ha scritto nel messaggio
news:ajoglj$rma$1...@lacerta.tiscalinet.it...

Sei stato chiarissimo e per questo ti ringrazio, il mio problema(uno dei
tanti) e principalmente fare in modo che non sia possibile l'inserimento di
un dato foglio,mappale e superficie , che sia stato gia inserito in un'altra
ditta. Per lo storico ho creato un campo "status" nella tbl "proprieta" in
cui sono inseriti tutti i dati catastali, nel momento in cui questa
particella cessa di esistere in quella determinata ditta, lo status si deve
modificare da attiva a spenta. Questo per avere lo storico.
Credi che stia procedendo nella giusta direzione?
Ciao Fabrizio

 Ciao Fabrizio
No, perchč potevi tagliare un bel po' di quoting, come ho fatto io!!!
Antonio

 Antonio , sei terribile!!!! Perň devo ammettere che hai ragione! ;-p


Non so se ho capito bene ma a me pare che tu non utilizzi la tabella
intermedia della quale ho parlato, allora - sempre se ho capito bene - usi
la tabella proprietŕ con i dati catastali associati alla ditta e il campo
status che dŕ validitŕ all'associazione, quindi per me dovresti creare una
chiave univoca con il campi che identificano la particella catastale, la
ditta e il campo status (mi ricorda il campo "versione" utilizzato in
progetti che mi hanno visto coinvolto). Se utilizzo il campo status come
Sě/No, potrň avere solo uno storico dell'associazione particella-ditta ma
non si puň escludere che una ditta che possedeva una particella che poi ha
venduta non la possa successivamente riacquistare, anzi se lo escludi
sicuramente ciň avverrŕ (estensione  della legge di Murphy), quindi io
tratterei questo campo come testo[1] o numerico (meglio) dove il valore 0
(zero) mi contraddistingue il record valido in quel dato momento e le
versioni vecchie di quella particella le rinumero quando la modifico a
partire da 1. Il numero piů alto di versione sarŕ la piů recentemente
sostituita. Nasce da sč che č molto piů importante avere poi una chiave
univoca composta dai dati catastali e dal campo status, cosě potrň avere un
solo stato per ciascuna particella e combinando il tutto con la prima chiave
dovrei avere ciň che desideri e poi posso fare tutte le query piů fantasiose
sullo storico. Comunque lo stessso discorso vale anche se crei la tabella
intermedia.
Non prestare attenzione se cambia il nick, a volte navigo con Win, altre con
Linux a seconda dell'umore e degli esperimenti da fare, l'e-mail č sempre
quella.
Bye, Luigi
ICQ (LICQ)  73039437

 Ho capito, però il problema è buttare giù in access tutto questo. Mi
chiedevo se realizzando una tabella intermedia (come dici tu) il lavoro si
semplifica!