4.2. Ключи

Для реальной работы с объектами, описанными в таблице, нужно уметь их различать. Один и тот же поставщик может поставлять два разных товара с одним и тем же названием (джинсы и джинсы). При этом могут совпадать и другие атрибуты (например, цена). Тем не менее, физически это будут разные товары. Для идентификации записей используются ключи. Ключ - это набор атрибутов, которые позволяет идентифицировать запись внутри таблицы, при этом никакое подмножество этих атрибутов не будет ключом. Ключ может быть простым и составным. Простой ключ состоит из одного атрибута, составной ключ - из двух и более. Атрибут, входящий в тот или иной ключ, называется ключевым атрибутом. Соответственно, ключ, который не входит ни в один из ключей, называется неключевым атрибутом.

Заметим, что ключ должен гарантировать уникальную идентификацию записи для всех возможных комбинаций записей в отношении. Например, в таблице с описанием товаров, представленной на рисунках 4.1. и 4.2., если смотреть по ее конкретному состоянию, поле “Товар” вроде бы может считать ключом (в этой таблице 4 записи, в поле “Товар” имеем 4 разных значения и каждая запись в данной ситуации может быть идентифицирована по полю “Товар”). Однако очевидно, что один и тот же товар может поставляться несколькими поставщиками и в общем случае в данной таблице поле “Товар” не может считаться ключевым. Более того, в той схеме, какую эта таблица имеет сейчас, вообще нет ключей.

Некоторый ключ, который разаработчики или проектировщики схемы базы данных выделяют и стараются использовать, называется первичным. Любой из ключей может считаться первичным, вопрос именно в предпочтении и простоте использования.

Ключи бывают естественными и искусственными. Естественный ключ состоит из реальных атрибутов, то есть атрибутов, которые существуют в предметной области и которые представляют интерес для решаемой задачи (например, фамилия-имя-отчество, номер счета и т.д.). Искусственный ключ вводится специально и используется как исскуственный атрибут именно для выполнения функции ключа. Потребность во введении искусственных ключей возникает по нескольким причинам. Первое, естественный ключ может состоять из большого числа атрибутов и работать с таким ключом очень неудобно. Второе, как показывает опыт, естественные ключи, то есть набор реальных атрибутов, действительно однозначно определяющих запись в отношении встречается очень редко. Даже такой, казалось бы, естественный ключ для идентификации человека, как номер внутреннего паспорта, не может быть естественным ключом (хотя бы по той причине, что паспорта выдаются только в 16 лет).

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

Рассмотрим пример. Предположим, мы все же хотим ввести ключ в таблицу “Товары” (см. Рисунок 4.2.). Вообще говоря, товар может идентифицироваться по бар-коду, который дается данному изделию производителем.

---------T----------T ----------------------T-----------------+ ¦ Товар ¦ Бар-код ¦ производитель ¦ Адрес ¦ +--------+----------+----------------------+-----------------+ ¦ рога ¦ 46131313 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ копыта ¦ 46061235 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ 01000004 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ джинсы ¦ 02000551 ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ L--------+----------+----------------------+------------------

Рис. 4.3. Модифицированная таблица “Товары”.

Однако, введение атрибута “Бар-код” не до конца решает задачу идентификации записи в таблице, так как один и тот же товар может поставляться несколькими фирмами. Следовательно, ключом надо будет считать пару атрибутов (Бар-код, Производитель). В простейшей системе такое решение, может быть, и будет правильным, но в реальной жизни возможны всякие нюансы типа того, что нам потребуется различать поставку оптовой партией и мелкого заказа и это будет разным видом поставляемого товара. Кроме того, не все производители пока еще используют бар-код для идентификации товара. Более того, возможны и подделки. Поэтому, скорее всего, наиболее оптимальным вариантов введения ключа в таблицу товары будет введение искусственного ключа, некоего внутреннего номера. Для единообразия будем такие ключи именовать именем “id” (идентификатор) и использовать для него целые значения (а сами конкретные значения ключа будем записывать начиная с символа “#”):

---------T----------T ----------------------T-----------------+ ¦ Товар ¦ id ¦ Производитель ¦ Адрес ¦ +--------+----------+----------------------+-----------------+ ¦ рога ¦ #105 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ копыта ¦ #106 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ #214 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ джинсы ¦ #157003 ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ L--------+----------+----------------------+------------------

Рис. 4.4. Таблица “Товары” с введеным искусственным ключом.

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