В отношении комбинация из трёх атрибутов уникальна, но после удаления любого одного атрибута уникальность сохраняется. Можно ли считать эту комбинацию кандидатным ключом?
Нет. Такая комбинация является суперключом, но не кандидатным ключом, потому что кандидатный ключ должен быть минимальным: удаление любого его атрибута должно нарушать уникальность. В данном случае кандидатным ключом будет меньшая комбинация, сохраняющая уникальность.
В реляционной модели ключи нужны для однозначной идентификации кортежей. Понятие кандидатного ключа отделяет сам факт уникальности от минимального набора атрибутов, действительно необходимого для идентификации.
Это различие помогает выявлять избыточные зависимости и точнее моделировать предметную область. В SQL ограничение уникальности проверяет уникальность указанного набора столбцов, но само по себе не проверяет его минимальность.
Если объявить уникальным избыточный набор столбцов, база данных может формально гарантировать уникальность, но модель будет скрывать настоящую структуру данных. Лишний атрибут в ключе усложняет внешние ключи, индексы, соединения и понимание функциональных зависимостей.
Кроме того, разработчик может ошибочно решить, что все атрибуты составного ключа необходимы для идентификации строки. Это повышает риск дублирования ограничений и неверного проектирования связанных таблиц.
Суперключ — любой набор атрибутов, однозначно идентифицирующий строку. Он может содержать лишние атрибуты. Кандидатный ключ — минимальный суперключ: если убрать любой его атрибут, уникальность исчезнет.
Например, если комбинация A, B уже уникальна, то A, B, C тоже будет суперключом, но не кандидатным ключом. Атрибут C не добавляет идентифицирующей информации.
Минимальность определяется не экспериментом на текущих данных, а бизнес-правилом и функциональными зависимостями. Временное отсутствие дубликатов не доказывает, что набор атрибутов является ключом: будущие данные могут нарушить предполагаемую уникальность.
В SQL избыточность можно выразить так:
В этом примере ограничение UNIQUE над тремя столбцами не делает тройку кандидатным ключом, если пара student_id, course_id уже уникальна. Более того, такое дополнительное ограничение обычно избыточно и должно быть удалено, если для него нет отдельного бизнес-смысла.
Первичный ключ выбирают из кандидатных ключей. Остальные кандидатные ключи могут быть реализованы как альтернативные уникальные ограничения. Важно отличать это от произвольного суперключа: уникальность избыточного набора ещё не означает, что он является самостоятельным ключом модели.
В системе обучения разработчик сделал первичным ключом сочетание идентификатора студента, курса и семестра. Позже выяснилось, что студент может проходить один курс только один раз, поэтому уже пара идентификатора студента и курса однозначно определяет запись.
Рассматривались два варианта. Можно было оставить тройной ключ: это требовало бы более широких внешних ключей и скрывало бы лишний атрибут. Можно было выбрать пару студента и курса: схема становилась проще, но это решение корректно только при подтверждённом правиле запрета повторного прохождения курса.
Выбрали пару как составной первичный ключ, а семестр оставили обычным атрибутом. В результате ссылки на запись стали короче, а ключ точнее выразил правило идентификации. Если бизнес-правило изменится и повторное прохождение станет допустимым, ключ потребуется пересмотреть, например включив семестр в действительно минимальный набор.
Ответ: Да. Суперключом может быть любой уникальный набор, включая набор с лишними атрибутами. Например, если A уникален, то A, B также является суперключом, но не является кандидатным ключом из-за неминимальности.
UNIQUE над набором столбцов, что этот набор является кандидатным ключом?Ответ: Нет. UNIQUE гарантирует отсутствие повторяющихся комбинаций в соответствии с правилами конкретной СУБД, но не анализирует, можно ли удалить один из столбцов без потери уникальности. Минимальность устанавливается проектировщиком на основании бизнес-правил и функциональных зависимостей.
Ответ: Ссылка на минимальный ключ содержит только необходимые идентифицирующие значения. Если использовать неминимальный суперключ, дочерняя таблица будет хранить лишние столбцы, усложнится индекс и возрастёт вероятность несогласованности при изменении данных. Поэтому для ссылочной связи обычно выбирают первичный или альтернативный кандидатный ключ, а не произвольный расширенный набор уникальных атрибутов.