Проверка целостности данных для объекта

Question

У меня есть три таблицы СТУДЕНТ, ОТДЕЛ И КУРС в базе данных университета ... У СТУДЕНТА есть UID в качестве основного ключа -> который является УНИКАЛЬНЫМ ID студента ОТДЕЛ имеет Dept_id как первичный ключ -> который является номером департамента КУРС имеет C_id как первичный ключ -> который является идентификатором курса/субъекта

Мне нужно хранить отметки в таблице, связывая первичный ключ СТУДЕНТА, ОТДЕЛ и КУРС для каждого учащегося в каждом курсе.

UID Dept_id C_id marks 
1 CS  CS01 98 
1 CS  CS02 96 
1 ME  ME01 88 
1 ME  ME02 90 

Проблема заключается в том, если я создать таблицу, как это для знаков, то я чувствую, что оператор данных может ввести неправильную комбинацию первичного ключа студента, например

UID Dept_id C_id marks 
1 CS  CS01 98 
1 CS  CS02 96 
1 ME  CS01 88 //wrong C_id (course id) inputted by the DBA 
1 ME  ME02 90 

В этом случае как я могу препятствовать ему это делать? Также есть ли способ сохранить отметки для каждого ученика? Я имею в виду люблю:

UID Dept_id CS01 CS02 
1 CS  98 96 
3 CS  95 92 

Answer 1

Вы должны избегать дублирования данных в базе данных, если это возможно:

UID Dept_id C_id marks 
1 CS  CS01 98 
    ^^  ^^ 

Вы могли:

• Изменение курса идентификатор ключа в два столбца (отдел, номер курса), например («CS», «01»).

или:

• Держите название курса, как это, но поместить поле отдел ID в course таблицы и опустить его из marks таблицы. Если вам нужно рассчитать общие оценки для определенного отдела, вы все равно можете сделать это легко, добавив JOIN к вашему запросу.

Ваше последнее предложение кажется плохой идеей. Вам понадобится столбец в таблице для каждого курса, и большинство значений будет NULL.

Answer 2

Я не уверен, почему вам нужен отдел в этой таблице, если курс указывает на отдел. Таким образом, почему бы не быть вашей таблицей:

UID C_id marks 
1 CS01 98 
1 CS02 96 
1 ME01 88 
1 ME02 90 

Что не хватает в этой таблице, это некоторое указание времени. Например, студент может пройти один и тот же курс дважды, если в первый раз он провалится. Таким образом, вам понадобятся дополнительные столбцы, указывающие семестр и год.

Answer 3

Вы можете добавить ограничения внешнего ключа в свои таблицы, чтобы убедиться, что для идентификаторов учащихся, идентификаторов курса и идентификаторов отдела введено допустимое значение. Вы также можете добавить уникальные ограничения в таблицу, чтобы избежать непреднамеренных дубликатов. Но в конце вы не можете предотвратить ввод некорректных данных; если бы вы знали, что это неверно, вам не нужно будет просить об этом.

Пример: 29 февраля 1957 года не могло быть моего дня рождения; 15 июля 2025 года не могло быть моего дня рождения; 27 сентября 1974 года не было моего дня рождения.

Answer 4

Ваше предложение было бы кошмаром для поддержания. Вам нужно будет добавлять новые столбцы каждый раз, когда новый курс будет добавлен в acment. Также было бы сложнее запросить большую часть времени.

Если вы хотите, чтобы каждый курс был подходящим для отдела, вы можете сделать это в триггере (обязательно обработайте несколько вложений или обновлений записей) или в приложении. Это все равно не будет препятствовать всем ошибкам ввода данных (можно выбрать CS89, если вы имеете в виду CS98), но это уменьшит количество ошибок. В этом случае вряд ли данные будут поступать откуда угодно, кроме приложения, поэтому я, вероятно, предпочту применить правила в приложении. Выпадающий список, в котором они выбрали отдел, и только курсы для этого отдела показали, что это будет трюк.