Может ли первичным ключом быть Null?

Может ли первичный ключ быть NULL?

Нет, первичный ключ (PRIMARY KEY) в реляционных базах данных не может содержать значение NULL ни в одном из своих столбцов. Это одно из фундаментальных и неизменных ограничений, определенных реляционной моделью и реализованных во всех основных СУБД (таких как PostgreSQL, MySQL, Oracle, SQL Server).

Причины и обоснование

Запрет на NULL в первичном ключе вытекает из самой его сущности и назначения:

1. Уникальная идентификация: Первичный ключ — это уникальный идентификатор каждой записи (строки) в таблице. Его основная задача — гарантировать, что каждая строка может быть однозначно отличима от любой другой. Значение NULL, по определению, представляет отсутствие информации или неизвестное значение. Если бы двум или более строкам был разрешен NULL в PK, они перестали бы быть уникально идентифицируемыми, что нарушает саму цель ключа.

2. Целостность ссылок (Referential Integrity): Первичный ключ является целью для внешних ключей (FOREIGN KEY) из других таблиц. Эти внешние ключи ссылаются на конкретное, существующее значение первичного ключа. Ссылка на NULL была бы бессмысленной — невозможно сослаться на "неизвестную" или "отсутствующую" запись. Это разрушило бы логику связей между таблицами.

3. Требования реляционной модели: Согласно классической реляционной теории (Кодда), первичный ключ должен соответствовать свойству отсутствия дубликатов (unique) и свойству отсутствия неопределенных значений (not null). Это аксиоматичное правило.

Что происходит на практике?

При попытке вставить или обновить запись, устанавливая NULL в столбец первичного ключа, СУБД немедленно выдаст ошибку нарушения ограничения.

Пример на SQL:

-- Создаем таблицу с первичным ключом
CREATE TABLE employees (
    id INT PRIMARY KEY, -- id НЕ МОЖЕТ быть NULL
    name VARCHAR(100) NOT NULL,
    department VARCHAR(50)
);

-- Успешная вставка
INSERT INTO employees (id, name) VALUES (1, 'Иван Петров');

-- Эта вставка ВЫЗОВЕТ ОШИБКУ, так как id явно NULL
INSERT INTO employees (id, name) VALUES (NULL, 'Мария Сидорова');
-- Ошибка в PostgreSQL: ERROR: null value in column "id" violates not-null constraint
-- Ошибка в MySQL: ERROR 1048 (23000): Column 'id' cannot be null

-- Эта вставка также ВЫЗОВЕТ ОШИБКУ (id не указан, подразумевается NULL)
INSERT INTO employees (name) VALUES ('Сергей Иванов');
-- Та же ошибка нарушения ограничения NOT NULL

Важные нюансы и смежные концепции

• Составной первичный ключ (Composite Primary Key): Если первичный ключ состоит из нескольких столбцов, то ни один из этих столбцов в отдельности не может быть NULL. Вся комбинация значений должна быть уникальной и полностью определенной.
• Автоинкрементные поля (AUTO_INCREMENT, SERIAL, IDENTITY): Это самый распространенный способ гарантировать уникальность и не-null значение PK. СУБД сама генерирует следующее числовое значение.
• Уникальный ключ (UNIQUE KEY) vs Первичный ключ: Вот здесь — ключевое отличие. На уникальный ключ (UNIQUE constraint) ограничение NOT NULL не накладывается автоматически (хотя его можно добавить отдельно). В большинстве СУБД столбец с UNIQUE может содержать несколько строк со значением NULL (хотя в SQL Server только одна строка может иметь NULL). Это подчеркивает, что первичный ключ — это особый, строгий случай уникального ключа.
• Альтернативный ключ (Alternate Key): Это любой уникальный ключ, не выбранный в качестве первичного. Он может допускать NULL, если это не запрещено явно.

Заключение

Запрет значений NULL в первичном ключе — это не техническое ограничение конкретной СУБД, а логическая и структурная необходимость, обеспечивающая целостность и надежность данных. Это краеугольный камень проектирования реляционных баз данных. Любая попытка обойти это правило (например, используя специальные значения вместо NULL) указывает на потенциальные проблемы в модели данных. Если возникает потребность в уникальном идентификаторе, допускающем неопределенность, следует рассмотреть использование UNIQUE KEY с отдельным, не входящим в него, столбцом для первичного ключа.