Язык определения данных (SQL DDL)

Как вы должно быть заметили, в сообщении об ошибке нарушения ограничения первичного ключа фигурирует имя ограничения ('product_PK'). А что будет в случае, если имя не задано? Так было у нас, когда спецификация PRIMARY KEY была включена в определение столбца model. Кстати, во втором варианте мы тоже можем не указывать имя (тогда и ключевое слово CONSTRAINT также опускается):

DROP TABLE Product;
CREATE TABLE Product (
maker varchar(10), 
model varchar(50), 
type varchar(50),
PRIMARY KEY (model)
);

И так ли важно нам знать имя ограничения? Помимо того, что оно может помочь нам понять причину ошибки, имя требуется при удалении ограничения, когда мы меняем структуру существующей таблицы. Если мы не задаем имя ограничения, СУБД сама присвоит его. И это имя, которое должно быть уникальным в пределах базы данных, мы можем узнать из информационной схемы – стандартного представления метаданных. Например, чтобы узнать имя ограничения первичного ключа, созданного в последнем скрипте, можно выполнить обычный запрос на выборку из таблицы (представления) информационной схемы:

SELECT CONSTRAINT_NAME 
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS 
WHERE TABLE_NAME='Product' AND CONSTRAINT_TYPE ='primary key';

У меня это имя получилось таким: PK__Product__0B7E269E30F848ED. У вас, вероятно, будет другим, поскольку его генерирует СУБД.

Примером составного ключа может послужить первичный ключ в таблице Outcomes (база данных «Корабли»). Здесь только пара {корабль, сражение} может быть уникальной, поскольку корабль может принять участие в нескольких сражениях, а в одном сражении участвует несколько кораблей. Корабль же в отдельной битве не может быть упомянут дважды, что и запретит сделать первичный ключ. Создать таблицу Outcomes с упомянутым первичным ключом можно следующим образом:

CREATE TABLE Outcomes (
ship varchar(50),
battle varchar(20),
result varchar(10),
PRIMARY KEY(ship, battle)
);

Следует заметить, что мы не можем написать так:

CREATE TABLE Outcomes (
ship varchar(50) PRIMARY KEY,
battle varchar(20) PRIMARY KEY,
result varchar(10)
);

Если первичный ключ может быть только один в таблице, то как быть в том случае, если в нашей модели должны быть уникальны разные комбинации атрибутов? Другими словами, как создать альтернативные ключи, например, если нам потребуется добавить уникальный столбец  out_id  в таблицу Outcomes?

Для этой цели в языке  Язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. SQL имеется спецификация UNIQUE. Вот так мог бы выглядеть запрос на создание таблицы Outcomes с дополнительным столбцом out_id:

CREATE TABLE Outcomes (
ship varchar(50),
battle varchar(20),
result varchar(10),
out_id int,
PRIMARY KEY(ship, battle),
UNIQUE (out_id)
);

Как уже упоминалось выше, ограничений UNIQUE может быть создано несколько для одной таблицы.

Есть еще одно отличие этого ограничения от ограничения PRIMARY KEY. Столбец, на котором создано ограничение UNIQUE, может содержать NULL-значение, но только одно. Вы можете спросить, - как же в этом случае быть с идентификацией объекта? Вспомним пример с книгами, когда мы ищем книгу по уникальному названию. Пусть мы имеем ограничение UNIQUE на столбце названия книги. Поскольку  NULL-значение может быть только одно, то найти книгу с неизвестным названием мы можем, исключив все книги с известными названиями.

Если же нам потребуется альтернативный ключ, не допускающий NULL-значений, то совместно с UNIQUE мы можем наложить ограничение NOT NULL. К этому мы сейчас и переходим.