Таблица уникальна по трём столбцам: как проверить, является ли их набор потенциальным ключом отношения?

Краткий ответ

Нужно доказать два свойства: набор столбцов однозначно идентифицирует каждую строку и является минимальным. Если удаление любого одного столбца допускает повторение комбинации, а вся комбинация остаётся уникальной, это потенциальный ключ.

Исторический контекст

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

Постановка проблемы

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

Неверный выбор приводит к более широким внешним ключам, большим индексам и усложнению соединений. Дополнительный риск возникает в SQL: наличие ограничения уникальности ещё не всегда означает полноценный ключ, если столбцы допускают NULL.

Подробное решение

Проверка состоит из двух этапов:

1. Уникальность. Для любых двух различных строк значения всех столбцов набора не должны совпадать. Иначе набор не является даже суперключом.
2. Минимальность. После удаления каждого отдельного столбца уникальность должна нарушаться хотя бы на одной паре строк. Если удаление столбца ничего не меняет, исходный набор избыточен.

Например, если комбинация столбцов «код страны, номер паспорта, дата выдачи» уникальна, но «код страны, номер паспорта» уже уникален, то потенциальным ключом является более короткий набор. Трёхкомпонентный набор остаётся суперключом, но не потенциальным ключом.

В SQL логическую проверку обычно выражают ограничением уникальности и запретом NULL:

CREATE TABLE passport (
    country_code CHAR(2) NOT NULL,
    passport_no  VARCHAR(20) NOT NULL,
    issued_at    DATE NOT NULL,
    UNIQUE (country_code, passport_no)
);

Здесь ограничение показывает предполагаемую уникальность пары, а NOT NULL не позволяет неопределённым значениям обходить смысл идентификации. Точное поведение UNIQUE при NULL зависит от СУБД и настроек, поэтому логический ключ нельзя обосновывать одной только уникальностью.

Из нескольких потенциальных ключей выбирают один первичным по смысловым и техническим критериям: стабильности, компактности, отсутствию чувствительных данных и удобству ссылок. Остальные обычно сохраняют как альтернативные уникальные ограничения.

Ситуация из практики

В системе клиентов комбинация «страна, номер документа» исторически считалась уникальной. Позже выяснилось, что номер документа может быть переиздан, поэтому эта комбинация не является стабильным идентификатором.

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

Выбран компромисс: стабильный технический первичный ключ и отдельное ограничение уникальности на актуальную бизнес-комбинацию, дополненное правилами обработки переиздания документа. Это разделяет идентификацию строки и проверку бизнес-правила, уменьшает размер ссылок и не отменяет контроль качества данных.

Что кандидаты часто упускают

1. Чем потенциальный ключ отличается от суперключа?

Суперключ — любой набор атрибутов, однозначно идентифицирующий строку, включая наборы с лишними атрибутами. Потенциальный ключ — минимальный суперключ: ни один его атрибут нельзя удалить без потери уникальности. Поэтому каждый потенциальный ключ является суперключом, но не каждый суперключ является потенциальным ключом.

2. Достаточно ли ограничения UNIQUE, чтобы получить потенциальный ключ?

Нет. Нужно проверить семантику NULL, поскольку неопределённое значение не всегда сравнивается как обычное равное значение. Для идентифицирующего ключа обычно требуются одновременно уникальность и запрет NULL; кроме того, ограничение должно соответствовать реальному бизнес-правилу, а не случайно наблюдаемым данным.

3. Может ли таблица иметь несколько потенциальных ключей?

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