Ключи. Первичный ключ

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

Замечание.

Данное утверждение легко доказать методом от противного. Действительно, пусть i-ая и k-ая строки отличаются друг от друга некоторой комбинацией столбцов (A). Если предположить, что в таблице отсутствует комбинация столбцов, которая однозначно бы отличала одну строку от другой, то, следовательно, должна существовать некоторая n-ая строка, у которой комбинация столбцов (A) должна быть идентичной той же комбинации  k-й строки.  Но поскольку эти строки должны отличаться друг от друга, то должна существовать комбинация  (B), отличная от (A), которая и отличает их друг от друга. Но n-ая строка должна отличаться и от i-й строки. Если она отличается комбинацией (B), то таким образом мы противоречим утверждению, что комбинации, которая отличает одну строку от другой, не существует. Если же предположить, что комбинация (B) у этих строк одинакова, то это противоречит тому, что она различна для k-й и n-й строк (условие транзитивности на условие тождественности  или не тождественности строк).

Такой набор столбцов называется ключом.

Определение

Если ключ не содержит других  комбинаций, однозначно определяющих строку (других ключей), то его называют первичным ключом (Primary Key). 

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

Замечание

Иногда в литературе определяют первичный ключ, как «минимальный набор столбцов однозначно определяющих строки таблицы». Такое определение несколько двусмысленно. Во всяком случае, выбор среди нескольких возможных ключей таблицы не обязательно должен диктоваться минимальностью длины ключа. Здесь минимальность подразумевается в том смысле, что любой первичный ключ не содержит в себе других ключей (в соответствие с тем определением, которое мы дали выше).

В качестве примера выбора первичного ключа рассмотрим следующую таблицу <fam,imja,otch,n_podr,inn,number>[1], которая содержит данные о работниках предприятия.  Расшифруем обозначение столбцов таблицы: fam – фамилия работника, imja – имя работника, otch – отчество работника, n_podr - номер подразделения, где числиться данный работник, inn – универсальный номер налогоплательщика, number – номер работника в подразделении, где он работает.  Таблица интересна тем, что в ней можно выделить несколько возможных первичных ключей. Самым очевидным кандидатом в первичные ключи является комбинация, состоящая всего из одного столбца (inn). Действительно налоговый номер является уникальной характеристикой совершеннолетнего гражданина России  и тем более уникален в рамках одного предприятия. Вторым претендентом на первичный ключ является комбинация (n_podr,number). Если значение n_podr уникальным образом определяет подразделение в рамках одного предприятия, а значение number  работника в рамках данного подразделения, то комбинация этих столбцов однозначно определяет работника в рамках всего предприятия.  Наконец, с некоторой натяжкой первичным ключом можно объявить и совокупность (fam,imja,otch,n_podr), так как вероятность того, что в одном подразделении работают два человека с одинаковой фамилией, именем и отчеством весьма мала. 

Первичный ключ принято использовать для установления связей между таблицами и это следует учитывать при его выборе. Рассмотрим несколько основных моментов такого выбора:

■           Во-первых, следует обратить внимание на уникальность выбранного ключа.  В последнем примере одним из вариантов первичного ключа была совокупность  (fam,imja,otch,n_podr). Конечно, вероятность того, что в данном подразделении будут работать два человека имеющие одинаковые фамилию, имя и отчество довольно мала, но ведь не равна же нулю. И что будет, если это (совпадение) все-таки произойдет? А все очень просто – ваша система в этом случае перестанет корректно работать. При выборе первичного ключа не стоит полагаться на «авось». 

■           Убедившись, что выбранный вами первичный ключ уникален в пределах данной таблицы, вы должны решить, нужно ли распространять уникальность ключа на всю базу данных. Я совсем не шучу, и такая необходимость может возникнуть. Дело в том, что в процессе проектирования или уже эксплуатации  может появиться потребность в объединении двух или более таблиц, выполняющих схожие функции.  Например, в одной таблице у вас хранятся, товары, пришедшие на склад, а в другой товары, отправленные   в магазин.  Функции таблиц схожие, а поэтому, почему бы их ни объединить в одну таблицу. Но если база уже заполнена, а первичные ключи   уникальны лишь в пределах  одной таблицы, то у вас возникнет проблема, которая, конечно же разрешима, но потребует от вас дополнительных усилий и времени.

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

■           Первичный ключ может состоять из нескольких столбцов, но удобнее использовать первичные ключи, состоящие всего из одного столбца (простой атрибут). В последнем примере таким ключом будет (inn).  Как быть, если в данной таблице нет одностолбцового первичного ключа?  Значит нужно добавить новый столбец с автоматической генерацией  уникального значения. Современные СУБД предоставляют такую возможность.  Более того, как раз удобнее иметь первичный ключ никак не связанный с описываемой предметной областью. Последнее довольно очевидно, поскольку достаточно трудно предвидеть все возможные реальные ситуации,  которые могут возникнуть при эксплуатации вашей системы, приводящие к нарушению уникальности первичного ключа. Выбирая же независимый от содержимого базы данных ключ, уникальность которого к тому же гарантируется системой,  вы страхуете себя от подобных ситуаций. В простейшем случае первичный ключ генерируется просто как номер вновь добавляемой строки таблицы (номер добавления).

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

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