Ключ или отмычка - Почему выбирают суррогатные ключи
Устойчивость суррогатных ключей - Ошибки проектирования

Ошибки проектирования, в результате которых в последствии приходится изменять структуру первичного ключа, являются достаточно распространённым явлением. В этой связи интересно рассмотреть ещё один фрагмент из работы Joe Celko [D&D], где приводится разбор примера предложенного К. Дейтом. «Крис Дейт и другие сторонники реляционных баз данных приводят доводы в пользу искусственных ключей и против интеллектуальных, что изменения в данных входящих в интеллектуальный ключ будут разрушать базу данных (см. глава 30, «Не включайте информацию в первичный ключ!» в RELATIONAL DATABASE WRITINGS 1989-1991 by Chris Date, Addison-Wesley, 1992, ISBN 0-201-54303-6). Использованная в одном из примеров Дейта Автомобильная компания Zitzi применяет часть номеров от 0000 до 4999 для запчастей, которые покупаются у внешних поставщиков, и номера от 5000 до 9999 для запчастей, сделанных у себя. Однажды компания купит 5001 запчасть у внешнего поставщика, и, цитирую Дейта: «Любая программа, которая полагалась на факт, что покупные запчасти имеют номера меньше чем 5000, потерпит неудачу». Я думаю, что это хороший пример его точки зрения. Автомобильная Компания Zitzi положила не ключевые атрибуты в их первичный ключ. Поставщики, несомненно, могут меняться, поэтому источник запчасти не должен быть включён в этот ключ. Возможно, номер запчасти должен относиться к сборке или подпроцессу сборки, которой запчасть принадлежит. Это согласуется с промышленным стандартом для кодов частей самолётов. Эти коды являются составными, они становится всё длиннее и длиннее по мере того, как мы углубляемся в более мелкие части. Идеально, когда некоторый физический элемент используется в более чем одном подпроцессе сборки, ключ одинаково заканчивается в обоих случаях. Например, xxxxxx-005 и yyyyyy-005 могут означать: «винт номер пять используется в Frammistat» и «винт номер пять используется в Freppometer», которые есть раздельные номерные части, но тот же самый физический элемент».

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

Ответы на эти вопросы не столь просты, как того, наверное, хотелось бы. И, к сожалению, некоторые проектировщики баз данных пользуются «простым» решением, основанном на применении суррогатного ключа, вместо тщательного исследования предметной области. Решение, предлагаемое К. Дейтом для процитированного выше примера, состоит во введении суррогатного ключа и не требует дополнительного исследования предметной области. Но предположим, что интеллектуальный ключ всё-таки существует. Существование интеллектуального ключа является объективным фактором, который не зависит от наших представлений о предметной области. Не менее объективным фактором являются и функциональные зависимости, в частности, зависимости неключевых атрибутов от интеллектуального ключа. Но в таком случае, решение, основанное на введении суррогатного ключа, порождает транзитивную зависимость:

суррогатный ключ Þ интеллектуальный ключ Þ неключевые атрибуты
(здесь знак Þ обозначает термин «определяет»)

Наличие транзитивной зависимости нарушает третью нормальную форму (3НФ). Таким образом, бездумное использование суррогатных ключей, приводит к нарушению нормализации, а, следовательно, и к аномалиям. При этом проектировщики будут не готовы к появлению аномалий, поскольку они не исследовали функциональные зависимости между атрибутами. Следовательно, аномалии не будут предотвращены, и могут повлиять на операции с хранимой в базе данных информацией.

Трудно представить, что К. Дейт, автор множества работ в области реляционной модели, призывал к денормализации базы данных. Но такой результат отчасти становится неизбежным, если следовать его совету, а не заниматься тщательным исследованием предметной области. Отсюда можно сделать и другой вывод, что использование суррогатных ключей, как средства исправления ошибок проектирования, не только не решает проблему, но может серьёзно усугубить её решение. Или, говоря другими словами, суррогатные ключи не являются способом понижения сложности предметной области и простота их использования весьма обманчива. Как следствие, применение суррогатных ключей в данном случае, равнозначно попытке страуса избежать опасности, спрятав голову в песок.

Хотелось бы отметить тот любопытный факт, что сторонники суррогатных ключей часто используют грубые ошибки проектирования в качестве доказательства правильности своей позиции. Типичным примером этого положения может служить, например, учебное пособие по MS SQL 7.0 Ю. Тихомирова [ЮТ MSS]. В разделе «Первичные ключи. Что выбрать в качестве первичных ключей для каждой из этих таблиц?» он пишет: «Рассмотрим таблицу Authors. Среди её столбцов очевидным кандидатом на первичный ключ является name. Авторов всегда можно различить по имени. Однако использовать этот столбец в качестве первичного ключа достаточно проблематично по нескольким причинам. Во-первых, значения в столбце name состоят из имени и фамилии автора». А чуть ниже, в этом же разделе, следует такая сентенция «И эта комбинация будет удовлетворять нас, пока таблица не разрастётся до такой степени, что в ней не появятся авторы с одинаковыми именами и фамилиями». Для читателя так и осталось загадкой, как можно различать авторов по имени и фамилии, если существуют авторы с одинаковыми именами и фамилиям. Наверное, было бы правильнее при постановке задачи сказать, что сущность Authors не имеет ключей-кандидатов в списке атрибутов, рассматриваемых Ю. Тихомировым, а, следовательно, суррогатный ключ был выбран на безальтернативной основе. Но такой выбор никак нельзя соотнести с необходимостью использования суррогатных ключей при наличии альтернативы в виде интеллектуальных ключей. В результате же столь неудачного доказательства складывается впечатление, что автор данной книги никогда не посещал публичных библиотек, не искал книги по каталогам. К сожалению, подобные примеры далеко не редкость.