Для меня нормально использовать объединяющую таблицу с отдельным ключом и сопоставлением "многие-к-одному", так как таким образом ваша объединяемая таблица становится отдельной сущностью, что является обычным в мире SQL. Вы также можете указать для него более удобное имя, которое соответствует вашему бизнес-кейсу, например, SubjectTeacherJoin и Students могут быть CourseAtendee и StudentSubjectTeacherJoin, а Assignments может быть Schedule или что-то подобное. Вы должны назвать это. На следующем этапе я бы также подумал, какие запросы будут выполняться больше всего. Поскольку большинство операций являются операциями чтения, вам не будет выгодно иметь довольно сложные соединения для наиболее часто используемых запросов в вашей системе. Это подводит меня к другому предложению - денормализации. Вы можете добавить в свои промежуточные таблицы несколько полей, которые нужны для большинства запросов, чтобы в этом случае вы могли уменьшить нагрузку и опустить сложное соединение для всех запросов. И если у вас будет несколько дубликатов данных, которые заставят вас чувствовать себя некомфортно, подумайте, что это может быть приемлемым компромиссом для упрощения ваших запросов и повышения производительности.