Oui, vous devez créer une Meeting entité pour représenter la relation plusieurs à plusieurs entre Student et Supervisor . Dans celui-ci, vous pouvez vous rapporter à ces tables en utilisant des clés étrangères qui correspondent à ces tables respectives. En SQL, cela peut ressembler à ceci :
Create table Meeting {
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
student_id INT NOT NULL,
supervisor_id INT NOT NULL,
//rest of the fields...
FOREIGN KEY (student_id) REFERENCES Student(id)
FOREIGN KEY (supervisor_id) REFERENCES Supervisor(id)
}
Vous feriez également la même chose pour le Supervise entre Project et Supervisor . Vous pouvez également utiliser quelque chose appelé une clé composite sur votre table de réunion, je suppose que cela dépend de vos préférences personnelles, je le fais généralement de cette façon lorsque je représente plusieurs relations. Je ne dis pas que c'est la syntaxe que vous utiliserez, cela dépend de votre base de données, c'était juste un exemple pour vous orienter dans la bonne direction. J'espère que ça aide.
De plus, pour votre diagramme (je suppose que c'est pour une classe), vous voudrez peut-être vous pencher sur des logiciels tels que visio ou paradigme visuel pour créer votre diagramme ER. Bien que la plupart des gens puissent comprendre votre diagramme actuel, ce n'est pas une modélisation correcte.
Pour le plaisir j'ai fait un schéma basé sur vos tableaux :
Vous voudriez une entité entre Supervisor et Project s'il s'agit d'une relation plusieurs à plusieurs. C'est ce qu'on appelle une associative entity . J'ai étiqueté le mien SupervisorProject juste pour qu'ils soient un peu plus clairs.
Modifier Oublié le fait que l'étudiant et le projet étaient plusieurs à un, corrigé cela, désolé.
