Месяцев после ОП, но на всякий случай это полезно.
@ Джефф Стерн находится на правильном пути. Основная проблема заключается в управлении трехсторонними (тройными) отношениями между студентами, классами и местами. Поскольку это реляционная проблема, давайте пока остановимся на реляционных концепциях и назовем их FavouriteSeat (Student, Classroom, Seat).
Как описано, проблема не требует каких-либо знаний о любом из них, кроме уникального идентификатора. Давайте пока воспользуемся псевдотипом «ID» (на самом деле это не имеет значения, если каждый из них уникален).
В псевдо-sql имеем:
create table FavouriteSeat(
StudentID ID not null,
ClassroomID ID not null,
SeatID ID not null)
Стандартные операции CRUD (создание / чтение / обновление / удаление) для этой таблицы обеспечивают все необходимые операции. Тем не менее, отсутствуют некоторые ограничения. Прямо сейчас у ученика может быть 2 или более любимых места в классе. Хотя это и не указано явно, ОП подразумевает, что у ученика должно быть не более одного (0 или 1) любимого места в любой заданной классной комнате.
Мы можем исправить это, добавив уникальный ключ на стол. Снова используя псевдо-sql:
alter table FavouriteSeat add unique key (StudentID, ClassroomID)
Теперь у ученика может быть только одно любимое место в любом классе. Там все еще остается вопрос. В настоящее время решение не поддерживает определение того, какие места доступны в каких классах. Мы можем решить это следующим образом:
Добавление новой таблицы со списком действительных мест в каждом классе:
создать таблицу ClassroomSeat (
Идентификатор ClassroomID не нулевой,
Идентификатор SeatID не нулевой)
изменить таблицу ClassroomSeat добавить уникальный ключ (ClassroomID, SeatID)
Добавление внешнего ключа в таблицу FavouriteSeat, чтобы он мог ссылаться только на действительные ClassroomSeats:
изменить таблицу FavouriteSeat добавить внешний ключ FK_Seat (ClassroomID, SeatID ссылается на FavouriteSeat (ClassroomID, SeatID).
Вот и все. 2 отношения, 3 ключа и стандартные операции CRUD охватывают все указанные требования.
Реляционная модель может быть легко переведена в OO / DDD. Ему нужны Entity для FavouriteSeat и ClassroomSeat с методами для операций CRUD. Методы должны будут обеспечивать соблюдение ограничений уникального и внешнего ключа, описанных выше.
Чтобы соответствовать только указанным требованиям, Customer, Classroom и Seat могут быть типами значений (хотя могут существовать более широкие неустановленные требования, которые могут изменить это). В любом случае им нужно свойство уникального идентификатора, которое можно проверить в методах FavouriteSeat.