Sí, debe crear una Meeting entidad para representar la relación muchos a muchos entre Student y Supervisor . En él puede relacionar esas tablas usando claves foráneas que correspondan a esas tablas respectivas. En SQL puede ser algo como esto:
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)
}
También haría lo mismo para Supervise entre Project y Supervisor . También podría usar algo llamado clave compuesta en su mesa de reuniones, supongo que se trata de una preferencia personal, generalmente lo hago de esta manera cuando represento relaciones de muchos a muchos. No digo que esta sea la sintaxis que usará, eso depende de su base de datos, este fue solo un ejemplo para orientarlo en la dirección correcta. Espero que ayude.
También para su diagrama (supongo que esto es para una clase), es posible que desee buscar un software como visio o paradigma visual para crear su diagrama ER. Si bien la mayoría de las personas podrán comprender su diagrama actual, ese no es un modelo correcto.
Por diversión, hice un diagrama basado en sus tablas:
Desearía una entidad entre Supervisor y Project si son una relación de muchos a muchos. Esto se llama una associative entity . Etiqueté el mío como SupervisorProject solo para que queden un poco más claros.
Editar Pasé por alto el hecho de que el estudiante y el proyecto eran muchos a uno, lo arreglé, lo siento.
