Понятие первичного ключа

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

На рис. 1.4 показана таблица "Сотрудники". В качестве первичного ключа не могут использоваться поля:

• ФИО - поскольку практически известно, что даже в одном отделе могут работать однофамильцы с одинаковыми инициалами или даже полные тезки;

• должность - поскольку хотя для данного примера названия должностей и уникальны, в любом отделе наверняка найдутся сотрудники, занимающие одну и ту же должность;

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

№ пропуска ФИО

Должность

Отдел

Год рожд.

111222

Иванов И.И.

нач. отдела

122

1940

333444

Петров П.П.

диспетчер

122

1942

234567

Сидоров С.С.

наладчик

118

1940

101010

Петраков А.И.

кладовщик

118

1967

202020

Мамукин М.М.

инженер

196

1966

Рис. 1.4. Таблица "Сотрудники"

В качестве первичного ключа может выступать номер пропуска, но при этом нужно сделать оговорку. Если номер пропуска недавно уволившегося сотрудника не может быть назначен сотруднику, впоследствии принятому на работу (т.е. является уникальным во времени), нет никаких ограничений на использование этого поля в качестве первичного ключа. Если же номер пропуска уволившегося сотрудника может быть назначен вновь поступившему сотруднику, следует изучить вопрос - удаляется ли информация об уволившемся сотруднике из базы данных? Если да, то поле может быть первичным ключом; если нет - не может быть первичным ключом, поскольку в базе данных могут присутствовать два сотрудника с одинаковым номером пропуска. В этом случае следует добавить в таблицу семантически незначащее поле (то есть не имеющего иного смысла, кроме обеспечения уникальности записи), например числовое поле NN (рис. 1.5.).

№

№ продукта

ФИО

Должность

Отдел

Год рожд.

111222

Иванов И.И.

нач. отдела

122

1940

333444

Петров П.П.

диспетчер

122

1942

234567

Сидоров С.С.

наладчик

118

1940

101010

Петраков А.И.

кладовщик

118

1967

202020

Мамукин М.М.

инженер

196

1966

Рис. 1.5. Таблица "Сотрудники" после введения уникального поля

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

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

счета, при условии, что в организации существуют деловые правила, согласно которым один и тот же номер не может быть назначен двум счетам или накладным.

Приведем другие примеры первичных ключей:

• номер и серия паспорта;

• номер двигателя;

• фамилия и инициалы автора, название книги, год издания, издательство. В случае, если принять во внимание, что в течение одного года книга может издаваться тем же издательством повторно, в первичный ключ следует добавить номер издания (2-е, 3-е и т.д.);

• название факультета, кафедры, года приема - для именования учебных групп в вузах;

• номер лицевого счета в бухгалтерском балансе;

• дата - если событие может случиться в течение даты только единожды, например, поставка продуктов в заводскую столовую;

• дата и время отказа сетевого оборудования, а при наличии нескольких потенциально сбойных узлов - адрес (номер) узла (если сбой узла характеризуется несколькими типами ошибок - еще и номер ошибки);

• почтовый адрес организации - с указанием номеров комнат, в случае, если в одном здании располагается несколько организаций (например, офисное здание);

• банковские реквизиты;

• регистрационный номер банка, организации;

• дата, номер страхового полиса, специализация и (или) фамилия и инициалы врача-специалиста - при обращении в поликлинику и т.д.

Замечание.
Может показаться, что банковские реквизиты не могут однозначно характеризовать организацию, поскольку одна организация может иметь несколько счетов в различных банках. Но реквизиты конкретного счета являются уникальными и, следовательно, могут однозначно характеризовать организацию; наименование же организации не может однозначно характеризовать реквизиты ее банковских счетов, которых может быть несколько. На практике, реквизиты счета вряд ли будут использованы в качестве первичного ключа, поскольку эти реквизиты громоздки; тем не менее, с теоретической точки зрения, такое возможно.

При детальном рассмотрении природы первичных ключей рано или поздно возникает вопрос: если в рамках данной предметной области мы можем обойтись без первичного ключа, стоит ли вводить искусственный первичный ключ? Например, пусть приведенная выше на рис. 1.1 таблица "Отпуск товаров со склада" используется только для подсчета суммарного отпуска товаров за временной период. Тогда однозначно характеризовать запись вроде бы ни к чему - записи используются только в группировках по датам. Однако в процессе отладки приложений, работающих с базами данных, при возникновении сбоев, потерь данных, нарушении смысловой целостности всегда нужно знать, с какой именно записью мы имеем дело. Роль уникального идентификатора записи в этом случае трудно переоценить. Поэтому не только правила хорошего тона при разработке структур баз данных, но и чисто практические соображения должны побудить разработчика всегда определять первичный ключ для таблицы базы данных.

Содержание раздела