Dire che ho il seguente diagramma ER:
Illato"uno" della relazione del diagramma sopra indica quanto segue:
Ogni studente può incontrare 0 o 1 insegnante.
Quindi non posso fare qualcosa del genere:
Mapossofarequalcosadisimile?:
Penso che la risposta sia No , perché queste due implementazioni sono solo due modi diversi di registrare lo stesso fatto (che è quello con studente con id di 1 incontrato < em> insegnante con id 1 due volte).
Sono corretto?
La mia interpretazione di diagrammi ER come il tuo
cheetichettalarelazionecomeundiagrammadiChen.Èchepuoiignorareil"incontrato". È semplicemente un termine descrittivo e non indica una tabella di collegamento.
Quindi avresti la struttura del database
Teacher
Id PK
Student
Id PK
TeacherId nullable FK -> Teacher.id
Se si desidera avere riunioni come entità, è necessario aggiungerle al diagramma come una scatola.
Limitare le relazioni per evitare che uno studente incontri più di un insegnante diventa complesso una volta introdotta questa tabella aggiuntiva. Non sono sicuro che tu possa farlo solo con gli FK a meno che tu non abbandoni l'immutabilità dell'incontro con i partecipanti
Non sono sicuro che "Ogni studente può incontrare 0 o 1 insegnante" significa quello che stai dicendo. Il rapporto di incontri per un insegnante con uno studente è 1 per molti ha senso, ma solo in contesti specifici, ad esempio una classe / corso. Per una scuola, no (molti insegnanti e studenti che prendono molte classi).
Ma se c'è un solo insegnante e un corso, la prima soluzione va bene. Cioè, tenere un elenco di riunioni (anche se potrei avere una sorta di timestamp / programma id come un modo di separare temporaneamente le riunioni). Quindi la tabella di collegamento Teacher_met_student può registrare tutte le riunioni degli insegnanti degli studenti per un'organizzazione.
Per me, il pezzo mancante è il Corso, che dovrebbe avere 1 insegnante (e IRL, questo è troppo restrittivo, molti corsi hanno più istruttori), molti studenti e le riunioni dovrebbero avere insegnanti, corsi, studenti per aggregare le riunioni in un particolare contesto.
Il diagramma ER mostrato descrive le tabelle e le loro relazioni con le chiavi esterne, ma lascia fuori le colonne precise in ogni tabella e i loro nomi. Quindi spetta a te quali colonne aggiungi a ogni tabella.
Il tuo primo esempio di implementazione non corrisponde al diagramma perché possiamo presupporre che il diagramma mostri le tutte tabelle e relazioni (o almeno tutte tra Student e Teacher ), ma qui non è una tabella Teacher_met_Student nel diagramma ER. La seconda implementazione, tuttavia, è soddisfacente e sì, puoi aggiungere una colonna number_of_times... , se richiesta.
Questo non ha nulla a che fare con entrambe le implementazioni che hanno quasi la stessa semantica, si tratta puramente di "sintassi", nient'altro.
Leggi altre domande sui tag database database-design relational-database