Newsgroup: it.comp.software.database
Titolo: schema per rappresentare tabelle di legame fra pezzi

salve
sto cercando di capire come strutturare uno schema in modo che possa
rappresentare delle tabelle di legame
fra dei pezzi meccanici
In pratica dovrei modellare una situazione in cui ho dei pezzi
meccanici e questi hanno delle tabelle
di compatibilità del tipo
pezzo1 va con pezzo2 e pezzo3
pezzo3 va pezzo4
pezzo4 va con pezzo5 e  6
pezzo7 va con tutto.
qualche idea ?

 pezzo1 va con pezzo2 e pezzo3
Supponendo una tabella che contenga tutti i pezzi:
    Pezzi { Pezzo }
...e supponendo una relazione di compatibilita` non
necessariamente riflessiva, simmetrica ne' aliorelativa,
la seguente:
    Abbinamenti { PezzoConsiderato, PezzoAbbinabile }
...dovrebbe catturare i requisiti per come forniti.
Esempio:
Pezzi
-----
Ingranaggio 10
Ingranaggio 11
Ingranaggio 9
Ingranaggio 12
Catena di distribuzione
Albero a camme
Abbinamenti
-----------
Ingranaggio 10, Ingranaggio 9
Ingranaggio 10, Ingranaggio 11
Ingranaggio 10, Ingranaggio 10
Ingranaggio 10, Catena di distribuzione
Catena di distribuzione, Albero a camme
In questo modo si specifica per ciascun pezzo a cosa puo' essere
abbinato.
Da notare che siccome la relazione non e` riflessiva, devo
esplicitare la riga "Ingranaggio 10, Ingranaggio 10" se voglio
specificare che un pezzo e` abbinabile a se' stesso.
Alcune considerazioni:
- nel caso volessi una relazione riflessiva (un pezzo puo'
andare sempre con se' stesso), dovrei prevedere un
meccanismo che crei la riga "PezzoA, PezzoA" in Abbinamenti in
automatico a partire dalla tabella Pezzi.
In alternativa posso incorporare la relativa logica nel codice
di query.
- nel caso volessi (molto probabilmente si, visto che si tratta
di parti meccaniche) una relazione simmetrica (se un pezzo A
va con B, allora anche B va con A), dovrei prevedere in
automatico l'aggiunta di una riga che scambia
PezzoConsiderato <-> PezzoAbbinabile.
In alternativa posso dare per scontato che la relazione sia
simmetrica, e quindi incorporare la relativa logica nel codice
di query.
- nel caso volessi una relazione aliorelativa (se un pezzo A
va con B allora A e B sono diversi), dovrei proibire il caso
PezzoConsiderato = PezzoAbbinabile.
- siamo ad un passo da tutti i limiti classici della computazione
(insiemi infiniti, recursione, logica di secondo ordine,
attraversamento di grafi) che sono stati storicamente evitati nei
dbms come compromesso per ottenere praticita` di gestione.
Il requisito "pezzo1 va con pezzo2 e pezzo3" io l'ho scomposto in
"pezzo1 va con pezzo2" e "pezzo1 va con pezzo3".
Nel caso il requisito fosse che pezzo1 va contemporaneamente
con pezzo 2 e 3, MA NON solo con uno solo, allora le cose si
complicano significativamente.
L'ultimo requisito, ossia un pezzo che va con tutti (quindi
incluso se stesso), pone dei problemini... dato che la
teoria relazionale tratta insiemi finiti, assumo che quel
"tutti" altro non e` che una scorciatoia per indicare tutti
i pezzi esistenti in tabella Pezzi in un dato momento.
Si potrebbe pensare ad una tabella:
    PezziUniversali { Pezzi }
...su cui costruire una vista AbbinamentiAutomatici che fa un
prodotto cartesiano di PezziUniversali con Pezzi (tenendo anche
qui conto di che tipo di relazione desidero, riflessiva etc),
seguita da una union con la tabella Abbinamenti.
Considerazione finale: fai solo se ti senti sicuro, altrimenti
meglio di no...
bye 

     
Ho letto con interesse tua risposta, e mi sono ricordato di quando ero 
fresco di studi anche una mela era un sistema formale. Mi sembra che 
manchi qualcosa, che con l'algebra relazionale immagino si presti a vere 
gare d'eleganza, ovvero il fatto che probabilmente la relazione è 
transitiva.
Al nostro yappo dirò solo che gli serve una nuova tavola, che abbia come 
chiave due campi, che sono i codici dei prodotti. Si tratta della base 
delle relazioni molti a molti, con cui potrà fare grandi cose, ad 
esempio aggiungendo altri campi.