Ключ или отмычка - Введение

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

Схема базы данных создаётся на основе инфологической модели – формального описания предметной области. Как и любая другая модель, инфологическая модель отбрасывает те атрибуты сущностей, которые не играют в ней значимой роли. Например, при приёме на работу нового служащего нас может не интересовать его рост или цвет волос, и эти атрибуты могут быть отброшены, в то время как уровень образования или профессиональные навыки могут быть важны. Может так получиться, что среди несущественных атрибутов окажутся и те атрибуты, которые однозначно идентифицируют экземпляры данной сущности. В результате, сущность, в рамках инфологической модели, может не иметь атрибутов для формирования ключа-кандидата. Однако реляционная модель требует, чтобы каждый кортеж любого отношения имел уникальный идентификатор.

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

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

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

Неадекватность отражения предметной области в виде схемы базы данных приводит к тому, что информация, хранимая в базе данных, может быть рассогласована с информацией существующей в реальном мире. Можно рассмотреть простой пример. Допустим, что для идентификации отношения «Служащие» выбраны ключевые атрибуты паспорта: серия и номер. Тогда нам потребуется ответить на вопросы о том, что произойдёт, если служащий сменит паспорт или предъявит иной, допускаемый в данной ситуации законом, документ? Если смена паспорта потребует изменение ключевых атрибутов, то правильно ли были изначально определены сущности предметной области, их атрибуты и функциональные зависимости? Предположим, что ранее в платёжных документах отмечалась информация, соответствующая атрибутам старого паспорта. Если мы сменим значения атрибутов (серия и номер паспорта) на новые во всех сущностях (таблицах базы данных), то, очевидно, что документы, выданные до смены паспорта, будут искажены.

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

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

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