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

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

Нет, в реляционной базе данных не может быть несколько первичных ключей (PRIMARY KEY) в одной таблице. Однако, может быть один составной (композитный) первичный ключ, состоящий из нескольких столбцов, и несколько уникальных ограничений (UNIQUE CONSTRAINT), которые функционально иногда называют «альтернативными ключами».

Подробное объяснение

1. Определение и роль первичного ключа

Первичный ключ (Primary Key, PK) — это фундаментальное понятие в реляционной модели данных. Его главные свойства:

• Уникальность: Каждое значение (или комбинация значений) в ключе должно однозначно идентифицировать строку в таблице.
• Непустота (NOT NULL): Ни один из столбцов, входящих в первичный ключ, не может содержать значение NULL.
• Единственность: В таблице может быть объявлен только один первичный ключ.

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

2. Составной (композитный) первичный ключ

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

-- Пример создания таблицы с составным первичным ключом
CREATE TABLE OrderItems (
    order_id INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT,
    PRIMARY KEY (order_id, product_id) -- Один PK из двух колонок
);

В этом примере один order_id может встречаться много раз (для разных товаров), и один product_id может встречаться много раз (в разных заказах). Но комбинация (order_id, product_id) — уникальна. Это один первичный ключ, а не несколько.

3. Уникальные ограничения (UNIQUE) как «альтернативные ключи»

Если таблице требуется обеспечить уникальность по нескольким наборам столбцов (помимо PK), для этого используются уникальные ограничения (UNIQUE CONSTRAINT). Они также гарантируют уникальность, но, в отличие от PK:

• Разрешены значения NULL (в большинстве СУБД, хотя это зависит от реализации. Например, в PostgreSQL несколько NULL в колонке с UNIQUE считаются разными значениями, а в SQL Server только один NULL разрешён, если колонка не NOT NULL).
• Их может быть несколько на одной таблице.
• Они не являются основным идентификатором строки.

CREATE TABLE Employees (
    employee_id INT PRIMARY KEY, -- Единственный PK
    email VARCHAR(100) UNIQUE,   -- Первое уникальное ограничение (альтернативный ключ)
    passport_series VARCHAR(10),
    passport_number VARCHAR(20),
    UNIQUE (passport_series, passport_number) -- Второе уникальное ограничение (составной альтернативный ключ)
);

Здесь:

• employee_id — первичный ключ.
• email — уникальное ограничение (не может повторяться).
• Комбинация (passport_series, passport_number) — еще одно уникальное ограничение.

С точки зрения бизнес-логики, и email, и паспортные данные могут служить уникальными идентификаторами сотрудника, но с точки зрения базы данных первичным ключом является только employee_id.

4. Почему важен этот вопрос для QA Engineer?

Понимание этой разницы критично для тестирования, потому что оно напрямую связано с:

1. Тестированием целостности данных: Нужно проверять не только PK на уникальность и NOT NULL, но и все заявленные UNIQUE-ограничения.
2. Анализом требований: Если в спецификации сказано «таблица должна иметь два первичных ключа», это — ошибка в требовании. QA должен уточнить: речь идет о составном ключе или о нескольких уникальных ограничениях.
3. Дизайном тестовых сценариев:

    *   Негативное тестирование: попытка вставить дубликат по PK или по любому `UNIQUE`-полю должна вызывать предсказуемую ошибку (`IntegrityConstraintViolation`).
    *   Проверка работы с `NULL`: Как ведет себя приложение и БД при вставке `NULL` в поле с `UNIQUE` ограничением?

1. Пониманием связей между таблицами (FOREIGN KEY): Внешний ключ всегда ссылается либо на первичный ключ, либо на уникальное ограничение родительской таблицы. Знание, куда именно происходит ссылка, важно для тестирования каскадных операций (удаление, обновление).

Вывод

Таким образом, строго говоря, таблица имеет ровно один первичный ключ, который может быть составным. Однако, она может иметь неограниченное количество уникальных ограничений, которые часто на концептуальном уровне называют «потенциальными» или «альтернативными» ключами. Для QA-инженера важно не только знать это формальное различие, но и понимать, как оно влияет на проектирование тестов, валидацию данных и анализ требований.