Newsgroup: it.comp.software.database
Titolo: ricerca database

Salve a tutti
scusatemi se vi faccio una domanda forse banale ma non sono molto 
pratico di teoria dei database. Devo costruire un database relazionale 
del tipo padri e figli; mi spiego meglio: ho una tabella con degli 
elementi identficati da un codice. Ognuno di questi elementi ï¿œ legato 
agli altri elementi della tabella da una relazione padre-figlio, nel 
senso che, fissato un elemento esso avrï¿œ un certo numero di elementi 
della stessa tabella come padri (livello superiore) ed un numero di 
elementi della stessa tabella come figli (livello inferiore). Ovviamente 
io devo essere in grado di spostarmi all'interno di questo database, nel 
senso che posso salire e scendere all'interno di esso a mio piacere. 
Sapreste dirmi se con Access ï¿œ possibile realizzare questo tipo di 
database o altrimenti con quale tipo di software sia possibile senza 
prima laurearsi in informatica?
Grazie mille a tutti in anticipo per l'aiuto e la pazienza.
Alessandro

 Alessandro
Secondo me si.
Devi fare 3 tabelle
A) Padri
B) Figli
in relazione molti a molti tramite la tabella
C) RelazioneMM
Le chiavi delle 3 tabelle potrebbero essere:
Padri = IDPadri + gli altri campi della tabella
Fogli = IDFigli + gli altri campi della tabella
RelazioneMM = IDRelazioneMM,  IDPadri,  IDFigli (3 campi)
Tramite la tabella RelazioneMM potrai "spostarti" all'interno del database.
Ciao
Leonardo

 Devi fare 3 tabelle
Perché tre e non due, cioè una tabella con codice e nome elemento ed 
un'altra con la relazione PadreFiglio?


Perch� se un figlio ha molti padri ed un padre ha moli figli questo � il 
modo per mettere padri e figli in relazione.
Prendi un esempio analogo, Scrittori e Libri.
Abbiamo 2 tabelle Scrittori e Libri.
Uno scrittore pu� scrivere molti libri e sarebbe una relazione 1 a Molti fra 
scrittore e libri.
Ma un libro pu� essere scritto da pi� scrittori ed avremo una relazione 1 a 
Molti fra libri e scrittori.
Va da se che le stesso scrittore pu� avere dei libri scritti da solo ed 
altri scritti insieme ad altri scrittori appartenenti alla tabella 
Scrittori.
Quindi il rapporto � Molti a Molti.
Il modo per metterli in relazione fra loro � la tabella
RelazioneMM = IDRelazioneMM,  IDPadri,  IDFigli (3 campi) [IDAutori , 
IDLIbri]
IDPadri � legato allo IDPadri (principale) della tabella padri
IDFigli � legato allo IDFigli (principale) della tabella figli.
Ciao
Leonardo
 

 il modo per mettere padri e figli in relazione.
[cut]
occhio che l'op parla di relazioni molti a molti tra elementi simili, tutti 
inseriti nella stessa tabella.
con una sola tabella di 'esseri umani', la relazione padri - figli puo' 
essere gestita con due sole tabelle
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 inseriti nella stessa tabella.
Esatto, non sono due entità distinte, c'è una sola entità che ha una 
relazione M-M su sé stessa.


Interessante, puoi farmi uno schema minimale?
Grazie
Leonardo

 Interessante, puoi farmi uno schema minimale?
PERSONA(id, nome)
PADRE_FIGLIO(id, id_padre, id_figlio)
dove id è chiave primaria nelle due tabelle e id_padre e id_figlio sono 
foreign key su PERSONA(id).

 foreign key su PERSONA(id).
mi � capitato di vedere la stessa struttura ra�ppresentata cos�:
persona(id,nome,id_padre)
funzionare funziona, non mi pronuncio sulla complessit�
cumputazionale,complessit� delle query, etc.

 persona(id,nome,id_padre)
Ma c'è il vincolo che tutti partecipano alla relazione in qualità di 
figlio?

 IDFigli � legato allo IDFigli (principale) della tabella figli.
IDRelazioneMM e` attributo estraneo alla chiave, in quanto
{IDPadri, IDFigli} e` sufficiente ad identificare la relazione
PadreFiglio. Inoltre e` dannoso nel senso che come altri usi
degli ID artificiali puo' permettere dati errati sottoforma di
duplicati, ad es:
RelazioneMM {IDRelazioneMM,  IDPadri,  IDFigli}
1, Abramo, Isacco
2, Abramo, Isacco
3, Abramo, Isacco
etc...

 o altrimenti con quale tipo di software sia possibile
Per MySQL c'e` un engine dedicato: 
http://www.openquery.com/graph/

 figlio?
Non proprio... il requisito originale e` piu` complesso di
quello che e` stato detto sinora, e mi sembra che nessun altro
l'abbia notato ;-)
"Ognuno di questi elementi � legato agli altri elementi della
tabella da una relazione padre-figlio, nel senso che, fissato
un elemento esso avr� un certo numero di elementi della stessa
tabella come padri (livello superiore) ed un numero di
elementi della stessa tabella come figli (livello inferiore)"
Questo significa che dato un nodo X, ci saranno un certo numero
di padri nel livello X-1 ed un certo numero di figli nel livello
X+1; quindi non sara` piu` sufficiente una relazione padre-figlio
a due posti, ma a TRE posti, come segue:
PadreIoFiglio { MioPadre, Io, MioFiglio }
(Da notare che non e` una relazione "Nonno", per la quale
basterebbero due posti).
Per tornare alla tua domanda, il requisito e` che un elemento
"partecipi" alla relazione, ma non e` detto in che ruolo; diverso
sarebbe stato se avesse detto "dato un elemento QUALSIASI", il
che per� porterebbe ad una tabella infinita! (perche' ogni
elemento avrebbe un figlio nel livello X+1 che a sua volta
avrebbe un figlio nel livello X+2 etc...)
(da notare che senza il requisito dei livelli si potrebbe ancora
avere un numero finito di nodi).
Non so se l'op se ne era avveduto, ma questo va significativamente
a complicare la struttura... all'inizio gia` un albero non
poteva essere in quanto un figlio poteva avere piu` padri, ma
neppure un grafo, in quanto un arco non puo' essere destinato a
due nodi contemporaneamente, per cui dovrebbe trattarsi di un
ipergrafo(!) nel quale dal nodo "Io" parte un arco destinato
ad un numero variabile di Padri e Figli.
Notare inoltre come la relazione sia una struttura sufficiente
a descriverle tutte quante, e scusate se e` poco...

 due nodi contemporaneamente, 
Però puoi disegnare più archi, uno per ogni destinazione.

 Per� puoi disegnare pi� archi, uno per ogni destinazione.
Affermazione un po' ingenua... se fossero equivalenti, per
quale motivo i matematici avrebbero creato teorie differenti?
Credo che sia dunque necessario chiarire quanto segue:
una relazione ad N posti vale contemporanemente per tutti gli
attributi coinvolti; se la "rompo" in relazioni piu` piccole
vado a perdere certe informazioni.
Faccio l'esempio classico che spero risolva il problema della
decomposizione ed il problema degli archi multipli; pensatelo
come un simpatico quiz se volete.
Una certa materia viene insegnata da un certo docente e viene
seguita da un certo studente; non c'e` vincolo alle materie
e ai docenti frequentabili da uno studente.
Lezioni {Materia, Docente, Studente}
--------------------------------
Pittura,  Michelangelo, Mario
Pittura,  Davinci,      Mario
Scultura, Michelangelo, Mario
Scultura, Davinci,      Mario
La decomposizione su relazioni binarie sarebbe:
Competenze {Docente, Materia }
-----------------------------
Michelangelo, Pittura
Michelangelo, Scultura
Davinci,      Pittura
Davinci,      Scultura
Interessi {Materia, Studente}
-----------------------------
Pittura,  Mario
Scultura, Mario
Docenze {Docente, Studente}
---------------------------
Michelangelo, Mario
Davinci,      Mario
A prima vista sembrano riportare dei dati che, una volta
ricombinati, danno di nuovo le stesse informazioni, vero? Sbagliato...
Aggiungiamo le seguenti righe nelle rispettive tabelle, questa
volta per lo studente Luigi:
Interessi {Materia, Studente}
-----------------------------
Pittura,  Luigi
Scultura, Luigi
Docenze {Docente, Studente}
---------------------------
Michelangelo, Luigi
Davinci,      Luigi
Noterete che sono le stesse medesime righe di Mario.
Quindi... stessi dati, stesse informazioni?
Prima della soluzione, rifletteteci bene perche' il punto sta
tutto qui...
.
.
.
.
.
Questo e` lo schema per Luigi:
Lezioni {Materia, Docente, Studente}
--------------------------------
Pittura,  Michelangelo, Luigi
Pittura,  Davinci,      Luigi
Scultura, Davinci,      Luigi
Luigi NON segue il corso di scultura di Michelangelo, e questa
informazione non e` catturabile dalla corrispondente suddivisione
in uno schema binario.
Per gli archi di un grafo/ipergrafo, il concetto e` simile.
Immaginiamo la rete di strade che collegano Roma, Milano, Napoli
piu` le altre citta`; esse sono un reticolo in cui diciamo che
ogni citta` ha una strada che la collega a quelle vicine; a
queste condizioni uno schema con 2 nodi ed 1 arco e` sufficiente
a descrivere ogni strada.
Ora immaginate un arco che colleghi CONTEMPORANEAMENTE Roma,
Milano e Napoli; possiamo paragonarla all'autostrada.
Se entro in autostrada, posso andare DIRETTAMENTE in queste
tre citta` senza essere obbligato a compiere le tappe intermedie,
semplicemente restando in autostrada; questa strada e` distinta
dalla strada normale, e la caratteristica che ci interessa e` che
posso andare dal nodo Milano al nodo Napoli con un singolo arco.
Ricapitolando, la relazione ad N posti ha come caratteristica la
valenza _simultanea_ tra tutti i suoi termini; nel database
modeling e` interessante perche` una relazione ad N termini puo`
avere attributi propri che esistono solo al manifestarsi
simultaneo di questi N termini.
bye

 relazioni a due posti senza PERDITA di informazioni.
Mi è chiaro, quello che non mi sembra è che la richiesta dell'OP 
prevedesse una relazione ternaria, nel tuo messaggio precedente hai 
cercato di spiegare proprio questo ma non sono convinto fosse quello che 
lui intendeva.

 quello che lui intendeva.
Beh ma se e` per questo, neanche io so cosa lui intendeva, io
tengo valido innanzitutto quello che uno scrive...
Comunque permane anche da parte mia una certa parte di dubbio su
cosa gli serva, per cui se fossimo in una situazione lavorativa
"reale" un incontro vis a vis sarebbe chiaramente indispensabile.