Dire che ho il seguente diagramma ER:
Quellochesoècheillato"uno" della relazione indica quanto segue:
Ogni studente può incontrare 0 o 1 insegnante.
Quindi, ad esempio student3 può incontrare teacher7 , ma non può soddisfare anche teacher4 .
Ma il lato "uno" della relazione significa anche che lo studente3 può incontrare insegnante7 due o più?
Penso che parte della tua confusione derivi dal tuo diagramma ER che non descrive in modo accurato lo scenario.
Tra i tuoi tavoli Insegnante e Studente dovrebbe esserci una tabella "Riunione". Questa tabella di riunione potrebbe coprire uno o più scenari aziendali:
A seconda di quale di questi scenari si adatta alle tue esigenze, definisce la relazione da uno a molti o molti a molti tra Insegnante e Riunione e / o Studente e Riunione.
Inoltre, gli scenari con più insegnanti o studenti potrebbero essere desiderabili avere altre due tabelle che elencano gli insegnanti o gli studenti che sono rappresentati nella riunione.
But does the "one" side of the relationship also mean that student3 can meet teacher7 twice or more?
Questo semplicemente non si riflette nella configurazione attuale. Se rileggi la tua domanda, vedrai che ti stai contraddicendo:
Le parti in grassetto si contraddicono a vicenda. Inherentemente, la risposta alla tua domanda è no .
Il problema qui è che stai chiedendo come uno stesso studente possa incontrare lo stesso insegnante più di una volta. Ciò suggerisce che stai cercando di tenere traccia di una cronologia delle riunioni, anziché di uno stato corrente.
Ad esempio, pensa a un'applicazione BlockBuster:
Pertanto, imposti lo schema come zero / un cliente su molti video.
Sembra corretto, finché non ti rendi conto che vuoi sapere quali clienti hanno noleggiato questo particolare video in passato. Pertanto, è necessario tracciare la cronologia degli affitti.
Logicamente, solo un cliente può attualmente noleggiare lo stesso video. Tuttavia, molti clienti possono storicamente aver noleggiato questo stesso video.
La necessità di tenere traccia delle modifiche cronologiche richiede l'estensione del modello dati. Nell'esempio di BlockBuster, ciò di cui hai bisogno è un'entità Rental che risiede tra il cliente e il video.
Nel tuo caso, è molto simile. Dovrai definire un'entità Meeting che definisca un incontro singolo tra un insegnante e uno studente.
Nota: questo schema in realtà non ti impedisce di avere un singolo studente che partecipa alle riunioni tenute da diversi insegnanti. Tuttavia, è qualcosa che imponi attraverso la logica aziendale piuttosto che la logica della struttura dei dati.
Il tuo modello non quantifica le riunioni: solo il fatto generale di quale insegnante ha incontrato quale studente, quindi non sono necessariamente preclusi incontri multipli.
Puoi cambiare il modello in vari modi: aggiungi più verbi per distinguere:
ma puoi vedere che questo non è un ottimo modo per contare le cose.
Se si desidera un conteggio delle riunioni, è necessario un valore contatore o assegnare un nome alle riunioni specifiche in modo che possano essere conteggiate individualmente.
In entrambi i casi, è necessario manifestare alcune nozioni sulle riunioni, non solo su una relazione hassined.
Per il primo (solo contando), è una relazione tra insegnante e amp; studente realizzato con un valore di conteggio. Questa è chiamata classe di associazione in UML: è un'associazione (acquisisce la relazione) ma è rappresentata da una classe in modo che possa avere attributi, come un conteggio di quante volte incontrato. Anche a volte chiamato reificazione, ad es. in RDF, dove facciamo un sostantivo (concetto) per un verbo (relazione) in modo che possiamo associare le proprietà al nome che rappresenta la relazione. Ad ogni modo, rende la relazione qualcosa che può avere attributi, in questo caso un valore di conteggio.
Per quest'ultimo, devi documentare ogni riunione, dando ad ogni singolo incontro un'identità di sorta: potrebbe essere un ID, o un orario di inizio, qualcosa di unico.
FWIW, sono diffidente nei confronti di modelli che precludono prematuramente le cardinalità generali (cioè richiedono cardinalità limitate). A volte (non sempre) le relazioni uno-a-molti sono ottimizzazioni premature sulle relazioni molti-a-molti. In questo caso, per esempio, ti piacerebbe essere sicuro che ci siano regole aziendali che impediscono a uno studente di incontrarsi con altri insegnanti, e che queste regole non saranno semplicemente mitigate quando ci sono problemi. Potresti usare molti-a-molti qui (anche se non sono mai stati usati per catturare le relazioni oltre uno-a-molti) e forse non hanno mai avuto un problema (di prestazioni).
Leggi altre domande sui tag database database-design relational-database