моделирования данных является искусство представляющий реальный мир в диаграмме отношений. Ваш режим правильный, но это правда?
Рассмотрите, что такое КЛАСС? Это УЧИТЕЛЬ, ПРЕДМЕТ и СДЕЛКА. Это ваши отношения. Кроме того, вы хотите обеспечить соблюдение правил, которые SUBJECT подходит для этого GRADE, и что преподаватель может преподавать этот SUBJECT в этом GRADE.
Я думаю, ваша проблема заключается в использовании суррогатных ключей в таблицах пересечений. Это таблицы, которые представляют ваши отношения «многие ко многим»: teacher_subject, grade_subject. В любом случае, это синтетические таблицы, и они все равно состоят из ключей. Следовательно, достаточно составного первичного ключа.
Суррогатные первичные ключи не имеют значения, поэтому нам необходимо определить уникальное ограничение на grade_subject(subject_id, grade_id), чтобы у нас не было двух записей для («ФИЗИКА», «ГОД 2»). Учитывая, что grade_subject - это таблица пересечений без каких-либо других столбцов, добавление суррогатного ключа бессмысленно. Значение суррогатных ключей заключается в минимизации влияния изменения бизнес-ключа. Но у grade_subject нет бизнес-ключа, всего двух суррогатных ключей, subject_id и grade_id.
Это имеет преимущество, когда дело доходит до определения ссылочной целостности.
Так что я бы подойти вашу проблему так:
grade_subject
----------------
grade_id
subject_id
primary key (grade_id, subject_id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
teacher_subject
---------------------
teacher_id
grade_id
subject_id
primary key (teacher_id,grade_id, subject_id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
foreign key (teacher_id) reference teacher (teacher_id)
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id)
Class
-----------------------------------
id
teacher_id
grade_id
subject_id
primary key (id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
foreign key (teacher_id) reference teacher (teacher_id)
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id)
foreign key (teacher_id,grade_id,subject_id) reference teacher_subject (teacher_id,grade_id,subject_id)
Это может выглядеть как взгромоздить внешние ключи, и я могу предусмотреть некоторые аргументы в стадии рассмотрения. (Я включаю в себя внешний ключ на grade_subject, поэтому у меня есть что-то, чтобы признать, что меня это не волнует, и поэтому может уступить).
Но мне не нравятся существенные отношения данных, такие как CLASS_SUBJECT, запутанное путем принудительного использования через дочерние отношения, такие как TEACHER_SUBJECT. Я не хочу присоединяться к TEACHER_SUBJECT и SUBJECT_GRADE, чтобы присоединиться к классу SUBJECT.
Теперь, почему я предпочитаю включать ограничения ссылочной целостности в таблицы с одним родителем и таблицу пересечений, когда последний косвенно принуждает первое? Потому что он делает отношения более ясными в модели. Я подчеркиваю модель, потому что в физической базе данных я мог бы отказаться от внешних ключей одной таблицы или отключить их, а также доверять реляционной целостности таблицы пересечений.
Что-то о трехкомпонентных составных ошибках меня, и я думаю, что это так: оно недостаточно нормализовано. У вас может быть специальный случай, но более общей моделью было бы два правила: TEACHER_SUBJECT и TEACHER_GRADE. Это будет выглядеть следующим образом
teacher_subject
---------------------
teacher_id
subject_id
primary key (teacher_id, subject_id)
foreign key (subject_id) reference subject (subject_id)
foreign keye (teacher_id) reference teacher (teacher_id)
teacher_grade
---------------------
teacher_id
grade_id
primary key (teacher_id,grade_id)
foreign key (grade_id) reference grade (grade_id)
foreign key (teacher_id) reference teacher (teacher_id)
Class
-----------------------------------
id
teacher_id
grade_id
subject_id
primary key (id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
foreign key (teacher_id) reference teacher (teacher_id)
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id)
foreign key (teacher_id,subject_id) reference teacher_subject (teacher_id,subject_id)
foreign key (teacher_id,grade_id) reference teacher_grade (teacher_id,grade_id)
Конечно, если вы по-прежнему хотели применять правило, г-н Друри мог только преподавать математику в четвертые шпангоуты и физику для шестых формирователей вам потребуется таблица TEACHER_SUBJECT_GRADE.
Одна вещь, к которой относится ваша модель данных, не является проблемой планирования. Школьные расписания должны иметь сетку, поэтому Классы должны вписываться в заранее определенную сетку. Вероятно, вам нужно определить слоты расписания как отдельную таблицу и связать с ней CLASS. Классам также нужны классные комнаты. Это еще одна таблица.
Спасибо APC за ваш ответ и время. В вашем дизайне есть две вещи, которые мой плохой мозг не может понять. 1) суррогатные ключи: не было бы уникальным (auto increment) целое число? в чем преимущества использования составного первичного ключа? (2) В таблице teacher_subject, почему вы используете (grade_id, subject_id) как внешний ключ, тогда как class_id и subject_id уже используются как внешние ключи отдельно? Извините за мое невежество. Но если вы мне это объясните, я буду благодарен вам. Хороших выходных. –