Ключ
или отмычка - Заключение
|
На основании изложенного выше, можно сделать вывод о том, что использование суррогатных ключей оправдано в двух случаях:
Отсутствие интеллектуального ключа возможно в случае, когда предметная область не включает в себя атрибуты, которые позволяют идентифицировать кортеж. С другой стороны, атрибуты, которые позволяют идентифицировать каждый кортеж отношения, могут быть слишком велики и их совокупный размер может превысить ограничение на размер ключа у конкретной СУБД. Иногда называют третий случай, когда оправдано применение суррогатных ключей: необходимость унифицировано идентифицировать кортежи любого отношения базы данных. Однако в данной ситуации лучше использовать уникальный индекс на вспомогательном, как правило, целочисленном атрибуте. Пресловутая устойчивость суррогатных ключей связана в основном с просчётами при проектировании и не может служить оправданием повышению сложности базы данных и запросов. Это тем более очевидно, если учесть тот факт, что модификации схем баз данных или отдельных отношений в хорошем проекте представляют собой исключительное события, в то время как взаимодействие с базами данных ведётся повседневно в оперативном режиме. Стоит ли повседневную работу приносить в жертву гипотетически возможным изменениям. В отличие от суррогатных ключей интеллектуальные ключи позволяют получать более простые и элегантные структуры баз данных. В силу своей информативности интеллектуальные ключи делают проще и эффективнее запросы, исключая избыточные соединения. Помимо этого, схемы, построенные на интеллектуальных ключах, устойчивы к появлению коллизий, а значит, эти ключи лучше обеспечивают достоверность информации в базе данных. Эти ключи требуют тщательного изучения предметной области и детального знания атрибутов сущностей, а также функциональных зависимостей между атрибутами. Однако этот процесс изучения имеет свои положительные стороны, позволяя получать продуманные и устойчивые к внешним изменениям схемы баз данных. Учитывая компактность многих интеллектуальный ключей, не следует ожидать увеличения размеров баз данных при их использовании. Применение суррогатных ключей вызвано определённым несовершенством современных СУБД, в частности, способом хранения информации по кортежам. В такой ситуации одна и та же информация многократно дублируется в различных структурах. Так атрибуты первичного ключа хранятся не только в самом отношении, но, как правило, входят и в уникальный индекс, который автоматически создаётся для каждого первичного ключа. Если какое-то отношение ссылается на другое отношения, то внешний ключ опять же сохраняется не только в ссылочном отношении, но и в индексе, построенном на внешнем ключе. При связи между отношениями один-ко-многим значения первичного ключа могут многократно повторяться во внешнем ключе. Таким образом, одни и те же значения из атрибутов первичного ключа многократно представляются в базе данных. Давая определение термину отношения, Е. Кодд писал [ЕК РМ]: «Термин отношение используется здесь в его общепринятом математическом смысле. Для заданных множеств S1, S2, ..., Sn (не обязательно различных) R является отношением на этих n множествах, если представляет собой множество кортежей степени n, у каждого из которых первый элемент взят из множества S1, второй - из множества S2 и т.д. Мы будем называть Sj j-тым доменом R». Это определение позволяет представить отношение как совокупность атрибутов. В таком случае, ключевые атрибуты, на основании которых происходит связь между отношениями, могут разделяться несколькими отношениями, находящимися в связи. Внутреннее устройство этих атрибутов является их внутренним делом и неизвестно отношениям, которые разделяют атрибуты. Следовательно, их можно организовать наиболее удобным образом, например, в виде иерархической структуры, повышающей скорость поиска затребованных значений. В свою очередь, организация атрибутов в виде индекса позволяет иметь только одно представление информации в базе данных. (Более подробно эта схема хранения рассмотрена в письмах по проектированию, посвящённых проекту СУБД). При данной схеме хранения информации потребности в суррогатных ключах не возникает, поскольку здесь не потребуются ни каскадные модификации, при изменении значения или удалении первичного ключа, ни сложных манипуляций с базой данных при изменении структуры атрибутов, составляющих первичный ключ. А поскольку такая схема хранения не противоречит реляционной модели, предложенной Е. Коддом, то можно сделать вывод о том, что суррогатные ключи являются привнесёнными в эту модель с целью попытки компенсации недостатков конкретных СУБД. Фактически к той же мысли можно придти, анализируя высказывание К. Дейта о существенности, о чём уже говорилось ранее. |