View Full Version : DATABASE : Associazione molti a molti
Il mio problema è il seguente : nel modello concettuale del problema da risolvere ho due entità . Una si chiama "Docenti" e l'altra "Materie" . Siccome sto analizzando la situazione di una scuola , un docente può insegnare più materie e una materia può essere insegnata da più di un docente . L'associazione , come è chiaro è "molti a molti" . Per poter andare avanti , l'associazione in questione viene divisa in due associazioni "uno a molti" introducendo una nuova relazione (tabella) . In questa tabella si andranno a riportare le chiavi primarie delle due tabelle di partenza . L'entità docenti presenta come attributi : id,nome,cognome,indirizzo . L'entità materia : id,nome,descrizione . Ora siccome il mio problema è stato risolto con l'introduzione di un'altra relazione devo pure far in modo che questa relazione contenga qualche dato . I dati devo per forza immetterglieli io , oppure posso creare una query che fa tutto da solo ? Credo che devo farlo io , in fondo lui cosa ne sa che il docente xxxx insegna xxxxxx ? Voi cosa ne pensate ? Vi prego rispondete e indicatemi la strada più giusta . Grazie di tutto ?
Ricapitolando hai tre tabelle:
Docenti (id,nome,cognome,indirizzo)
Materie (id,nome,descrizione)
Competenze (id_docente,id_materia)
Hai due relazioni 1 a molti:
tra Materie.id e Competenze.id_materia
tra Docenti.id e Competenze.id_docente
I dati dovranno essere inseriti a mano: occorre riempire prima le tabelle Docenti e Materie, in seguito sarà possibile fare l'associazione tra docenti e materie nella tabella Competenze.
Originally posted by "tas"
Ricapitolando hai tre tabelle:
Docenti (id,nome,cognome,indirizzo)
Materie (id,nome,descrizione)
Competenze (id_docente,id_materia)
Hai due relazioni 1 a molti:
tra Materie.id e Competenze.id_materia
tra Docenti.id e Competenze.id_docente
I dati dovranno essere inseriti a mano: occorre riempire prima le tabelle Docenti e Materie, in seguito sarà possibile fare l'associazione tra docenti e materie nella tabella Competenze.
quella che tu chiami competenze in realta è fattac così :
Competenze (id,id_docente,id_materia)
Si , ma infatti le informazioni sui docenti e sulle materie l'ho riempita a mano , mi sembra logico . Quello che non volevo riempire io era la tebella competenze . Ma poi mi sono detto : lo può fare lui in automatico ? Mi sono dato anche una risposta : come fa a riepire in automatico non sapendo quel professore cosa insegna ? Sono tutte ipotesi che mi sono formulato . Volevo sapere se vanno bene o se si può veramente farla riempire a lui questa tabella
quella che tu chiami competenze in realta è fattac così :
Competenze (id,id_docente,id_materia)
Si
oops, mi sono dimenticato l'ID!
No, non puoi farla riempire a lui, a meno che queste informazioni non siano desumibili da altre tabelle.
Originally posted by "tas"
oops, mi sono dimenticato l'ID!
No, non puoi farla riempire a lui, a meno che queste informazioni non siano desumibili da altre tabelle.
allora avevo immaginato bene .
si che lo fa in aut. altrimenti a cosa servirebbe la rel. molti a molti?
la tabella competenze ti si deve "autocompilare" basta usare una semplice form.
l'errore è che la tabella competenze non deve avere un campo contatore o indice. E' una tabella di congiunzione che è formata da 2 chiavi esterne ID_materia;ID_docente.
la chiave primaria della tab. competenze sono entrambi i suoi campi (di tipo numerico ovviomente).
Ti si deve compilare da sola nel senso che puoi scegliere i valori solo fra quelli delle chiavi delle altre due tabelle...ma non che la tabella ti si compila da sola ;)
Confermo...non ha senso mettere un campo ID nella tabella competenze perchè per definizione non ci possono essere 2 competenze con gli stessi valori nei campi id_materia e id_docente...
Anzi mettendo un ID si correrebbe il rischio di poter specificare due volte la stessa competenza...
La tabella è tuttachiave...
Inoltre non ci dovrebbe essere nemmeno la possibilità di aver due materie con lo stesso nome e la stessa descrizione... Così se si vuole fare le cose secondo la teoria (per minimizzare la ridondanza) anche l'ID della tabella Materie andrebbe tolto e la tabella sarebbe anch'essa tuttachiave...
Riguardo agli insegnanti se si ammette che possano esistere almeno due insegnanti con stesso nome, cognome e indirizzo all'ora l'ID ci vuole... Non è una cosa probabile, ma sicuramente non impossibile...
nel momento che in una maschera metti il Docente e la materia che insegna, questi dati dove vengono memorizzati? Nella tabella congiunzione o sbaglio. I docenti e le materie li prendi dalle rispettive tab, magari con una combobox, e si associano nella competenze.
Originally posted by "borga"
nel momento che in una maschera metti il Docente e la materia che insegna, questi dati dove vengono memorizzati? Nella tabella congiunzione o sbaglio. I docenti e le materie li prendi dalle rispettive tab, magari con una combobox, e si associano nella competenze.
Si ma in ogni caso anche con combobox sei sempre tu a dirgli che il professore xxx insegna la materia xxx . Capito ?
Ma a cosa serve una chiave primaria in un db?
Originally posted by "abxide"
Ma a cosa serve una chiave primaria in un db? La chiave primaria è quell'attributo della tabella che identifica univocamente un record . Per farti un esempio : se tu crei una tabella dove sono riportati cognome,nome,indirizzo di alcune persone come fai poi ad individuare la persona xxx ? Potresti trovarti in difficoltà siccome più persone potrebbero avere cognome,nome e indirizzo uguale . Se invece aggiungo una chiave primaria per esempio di tipo contatore , ogni persona avrà un suo codice identificativo e facendo riferimento a quel codice starò considerando quella e soltanto quella persona . Un pò come accade per i codici fiscali .
La chiave primaria può essere anche più di un attributo...
Originally posted by "cionci"
La chiave primaria può essere anche più di un attributo...
Si certo ... in questo caso si parlerà di chiave primaria composta .... .Ah ho dimenticato una cosa prima ..... la chiave primaria è anche una chiave indicizzata
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.