7.6.2. Задание первичных ключей
В теории реляционных баз данных таблица представляет собой изначально неупорядоченный набор записей. Единственный способ идентифицировать определённую запись в таблице – это указать набор значений одного или нескольких полей, который был бы определен для любой записи (строки) этой таблицы и различен для любых двух записей. Отсюда и происходит понятие первичного ключа. Первичным ключом называется атрибут (или набор атрибутов (столбцов, полей)), который может быть использован для однозначной идентификации конкретного кортежа (строки, записи), таблицы.
Ключевые поля должны быть первыми в таблице. СУБД автоматически производит сортировку записей по ключу.
Наличие ключей позволяет связать данные из разных таблиц в запросах, формах и отчетах. Ключ может быть простым, состоящим из одного поля, или составным, включающим несколько полей.
Например, для таблицы данных о студентах таким полем может служить номер студенческого билета. Для таблицы, в которой содержатся расписания занятий, такого поля можно и не найти, но его можно создать искусственным комбинированием полей «Время занятия» и «Номер аудитории». Эта комбинация неповторима, так как в одной аудитории в одно и то же время не принято проводить два различных занятия. Если в таблице вообще нет никаких полей, которые можно было бы использовать как ключевые, всегда можно ввести дополнительное поле типа Счетчик — оно не может содержать повторяющихся данных по определению.
Первичный ключ должен всегда иметь значение. Если столбец допускает неназначенное или отсутствующее значение, его не следует использовать в качестве компонента первичного ключа.
Значение первичного ключа не должно меняться, поэтому в качестве первичного ключа не рекомендуется выбирать фамилию или адрес, поскольку такие данные со временем могут измениться.
Рассмотрим процесс создания первичного ключа для отношения (таблицы) Сотрудник.
Здесь можно выделить следующие потенциальные ключи:
Табельный номер;
Номер паспорта;
Фамилия + Имя + Отчество.
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований:
1. Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки.
2. Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если сочетание атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным.
3. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В приведенном примере ключи № 1 и 2 предпочтительней ключа № 3.
4. Атрибуты ключа не должны содержать нулевых значений.
5. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организации может выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа.