Newsgroup: it.comp.appl.access
Titolo: Relazione molti a molti sulla stessa tabella

Salve a tutti e in anticipo auguri per il natale...
Il mio problema consiste nel fatto che ho una tabella(Contatti) con i
dati relativi a dei contatti con campi quali nome,cognome e via
dicendo. Il problema è che fra le voci c'è figura di riferimento, che
ha sua volta è un contatto e risulta all'interno della tabella
Contatti stessa.
Dato che ad ogni contatto può corrispondere più di una figura di
riferimento e viceversa mi ritrovo davanti a una relazione molti a
molti sulla stessa tabella del database...
Il più che nn so implementarla...qualcuno saprebbe suggerirmi il modo?
Auguri ancora

 ha scritto nel messaggio 
news:1166976277.9...@i12g2000cwa.googlegroups.com...

Auguri ancora
Dividi le tabelle. Se "figura di riferimento" è una persona diversa da 
contatto, puoi fare così:
TAB_CONTATTI    TAB_RIF        TAB_FIG_RIF
ID                                                      ID
NOME                                              NOME
RIF(numerico)-------RIF(contat)-----RIF(numerico)
Dove, Tab_Contatti molti-1 Tab_Rif e Tab-Fog_Rif molti-1 Tab_Rif sempre 
tramite la chiave esterna RIF.
In questo modo dovresti aver creato una relazione molti-molti fra 
Tab_Contatti e Tab_Fig_Rif
Spero di avere capito il problema :)
Ciao.
eSQueL

 eSQueL
No...una figura di riferimento è a sua volta un contatto...è questo
il problema...in pratica io ho i vari campi nella tabella contatti tra
cui risulta anche "figura di riferimento"...in teoria in questo devrei
poter collegare gli id di altri contatti

 ha scritto nel messaggio 
news:1166979150....@42g2000cwt.googlegroups.com...


____________
mm ... prova a modellare le tabelle come ti ho descritto. Se Tizio e Caio 
hanno come figura di rif. Sempronio, tutti e tre saranno legati tramite la 
chiave esterna Rif(numerico, es.:1) alla chiave primaria (contatore) della 
tabella Rif.
Se domani Caio cesserà d'avere come figura di riferim. Sempronio, cambierai 
la sua chiave esterna, assegnadogli quella di un altro (o nessuna).
Non l'ho provato, ma ad occhio dovrebbe fungere (:P).
Ciao.
eSQueL

 
La questione e' che tipo di operazioni vuoi farci dopo.
Ho sempre fatto una tabella con, a parte gli attributi aggiuntivi, 
Contatto(Figlio) Riferimento (Padre). Se il livello di profondita' e' al 
massimo 2 non dovrebbero esserci problemi. Nel "senza padre" l'attributo 
"rferimento" e' a null. Per cercare i padre/figlio o "vaisvirsa" e' 
sufficente una selfJoin. Se il livello di profondita' e' maggiore di due 
siamo nel classico della "distinta base" (o binary tree che dir si 
voglia) e l'affare si ingrossa. Con una sola tabella, se non erro, non 
e' possibile fare integrita' referenziale e quindi eventuali modifiche 
di un padre non si riflettono sui figli.
-- 
ac
y-1=x

Mentre testo il suggerimento di eSQueL ti spiego un minimo l'so che
dovrò fare del db.
E' un db di contatti per un'azienda che deve contenere tutte le info su
chi lavora presso l'azienda e tutti i collaboratori esterni, nonchè
alcune info sulle aziende presso cui lavorano quest'ultimi.
Al contempo deve memorizare dati relativi a progetti interni
all'azienda e quindi ad ogni progetto corrisponde una figura di
riferimento alla quale i componenti del gruppo di progetto fanno
riferimento.
Dato che una persona può far parte di più "gruppi" progetto, deve
relazionarsi con più figure di riferimento. Le suddette figure sono
viste comunque impiegati che "al momento" sono figure di riferimento
per quel progetto in corso, ma chemagari nn lo saranno per altri o nn
lo saranno più.
Per questo parlavo di relazione molti a molti nella stessa tabella.
Spero di essermi spiegato appieno...appena riesco a finire di provare
la versione di eSQueL (natale permettendo) faccio sapere se funziona in
pratica...nel frattempo accetto tutti i suggerimenti^_-
Auguri a tutti

Wolverine ha scritto:

Come ti ha spiegato Alessandro se vuoi rendere flessibile la tua
gestione ti serve una tabella Distinta, nella quale hai 2 campi PK...!
In pratica la tabella Contatti apare 2 volte, una lato Padre ed una
lato Figlio.
Dovrai fare attenzione ad inserire però un campo attributivo alla
tabella contatti in quanto immagino che non tutti i contatti possono
far parte della distinta, quindi come ti ha suggerito Alessandro
sarebbe buona cosa prima chiarire bene come e cosa devi ottenere,
quindi normalizzare....!
@Alex

 ha scritto nel messaggio 
news:1167086454.1...@n51g2000cwc.googlegroups.com...
Dovrai fare attenzione ad inserire però un campo attributivo alla
tabella contatti in quanto immagino che non tutti i contatti possono
far parte della distinta, quindi come ti ha suggerito Alessandro
sarebbe buona cosa prima chiarire bene come e cosa devi ottenere,
quindi normalizzare....!
Io ho avuto lo stesso problema con la tabella 
clienti/fornitori/rappresentanti, ritenevo inutile avere tre tabelle con gli 
stessi campi e quindi ho costruito una sola tabella e ho creato un campo 
nella tabella dove specifico se il soggetto può essere uno delle tre 
tipologie oppure tutti e tre.
Fatto ciò nella tabella dove registro i dati (nel mio caso del preventivo) 
filtro nel campo cliente solo i soggetti che risultano essere solo clienti 
mentre nel campo fornitori filtro solo i soggetti che hanno il campo 
fornitori e così via.
A livello di relazioni quindi non ho avuto grossi problemi l'unico 
accorgimento è stato appunto quello di filtrare maschere e combobox in 
maniera da non far confusione.
Spero di esser stato chiaro e di aver capito il problema.
Saluti Andrea