Первичный ключ с более чем 3 атрибутами
Рассмотрим отношение, которое изображает учебный номер бронирования в университете. Каждый факультет назначает человека для обработки бронирования для всех учебных классов для этого факультета. Адрес электронной почты этого человека передается в систему бронирования университета в качестве контактного лица. БРОНИРОВАНИЕ (b_date, b_starttime, b_endtime, unit_code, contact_person, room_no, tutor_id).
Упражнение: Определите потенциальные ключи и первичный ключ для отношения, если применимы следующие бизнес-правила:
1) Занятия могут быть продолжительностью 1 час или 2 часа.
2) Репетитор может преподавать только один учебный класс в данном модуле.
3) Нет параллельных сессий обучающих занятий.
Мой ответ: 1 из ключей-кандидатов (tutor_id, d_date). Мой ключ предложения может сделать каждый кортеж уникальным, НО нет ограничений, которые не позволяют пользователям вводить неправильно, как показано ниже:
tutor_id | d_date | b_starttime | b_endtime | код единицы |
AAAA | Пн | 6 вечера | 8 вечера | FIT1111 |
BBBB | Пн | 6 вечера | 7 вечера | FIT1111 |
ИЛИ ЖЕ
tutor_id | d_date | b_starttime | b_endtime | код единицы |
AAAA | Пн | 6 вечера | 8 вечера | FIT1111 |
BBBB | Пн | 7 вечера | 8 вечера | FIT1111 |
Следовательно, мой ключ не соответствует бизнес-правилу № 3. Затем я добавляю еще 2 атрибута в ключ-кандидат (tutor_id, d_date, b_starttime, b_endtime).
Мои вопросы: когда мы выбираем ключ-кандидат, помимо гарантии уникальности каждого кортежа, нужно ли нам предотвращать неправильный ввод пользователей, который может нарушить бизнес-правила? Если да, когда мы устанавливаем, например, 4 атрибута (A, B, C, D) в качестве первичного ключа, блокирует ли СУБД пользователей неправильное действие ввода, как в таблице выше?
Благодарю.
1 ответ
Мои вопросы: когда мы выбираем ключ-кандидат, помимо гарантии уникальности каждого кортежа, нужно ли нам предотвращать неправильный ввод пользователей, который может нарушить бизнес-правила?
Да, мы должны объявить достаточно ограничений, чтобы запретить все недопустимые состояния. И да, объявление одного или даже всех CK (ключей-кандидатов) не обязательно достаточно. (С чего бы это? Как вы думаете, у вас есть причина, почему это должно быть?)
CK не просто утверждает уникальность набора атрибутов. Это также заявляет о неединственности любого правильного подмножества этого набора.
CK используются при нормализации к более высоким NF (нормальным формам), что позволяет избавиться от определенных проблемных ограничений, заключающихся в том, что таблица всегда должна быть объединением других таблиц, которые вы могли бы иметь вместо этого. Он удаляет вашу текущую таблицу и вводит эти таблицы и их ограничения CK, а иногда и ограничения FK (внешний ключ), которые в другом месте должны отображаться как CK. Но могут сохраняться и другие ограничения, которые должны быть объявлены.
Если да, когда мы устанавливаем, например, 4 атрибута (A, B, C, D) в качестве первичного ключа, блокирует ли СУБД пользователей неправильное действие ввода, как в таблице выше?
Вы упоминаете, что конкретное ограничение CK не предотвратит некоторые недопустимые состояния. Но так как вы всегда должны объявлять все CK, вы должны найти их все, прежде чем начнете искать недопустимые состояния, которые не предотвращены. Кроме того, "затем я добавляю еще 2 атрибута к ключу-кандидату" не имеет смысла, потому что 1. это не то, как мы находим CK, и 2. CK плюс другие атрибуты не могут быть CK.
(Читайте и действуйте по хитам, ища "домашнюю работу stackexchange" и публикуйте новый вопрос, показывающий вашу работу после того, как ваш учебник нашел CK.)