Ключ или отмычка - Почему выбирают суррогатные ключи
Пересекая границы базы данных

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

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

С другой стороны, если не включать атрибут суррогатного ключа в схему репликации, то появляется проблема с репликацией отношения «Позиции». Каждая позиция должна быть связана со своим заказом, а поскольку первичный ключ из отношения «Заказы» при репликации исчезает, то теряется и связь между заказом и его позициями.

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

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

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

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

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

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