Когда мы имеем дело с иерархией, которая подобна вышеописанной, иногда кажется, что решение о том, где вводить суррогатный ключ, может быть произвольным. Однако вспомните, что проектирование базы данных тесно связано с функциональными требованиями. Для реализации некоторых функций может потребоваться подъем по иерархии. Если каскадные ключи ведутся, то такой подъем может быть трансформирован в прыжок , при котором убираются посредники и выполняется более оптимальный запрос. Это можно продемонстрировать путем соединения таблицы HOUSES непосредственно с таблицей REGIONS (минуя таблицы STREETS и TOWNS).

SELECT MAX (hs.no) FROM houses hs

,regions reg WHERE hsl.f reg name = reg.name AND hs .metropolitan f = N;

Цель этого запроса - найти самый большой номер дома в немуниципальной области (еще один запрос из архива фирмы Бесцельные запросы ).

Предупреждение

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

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

Если первичный ключ таблицы имеет более четырех компонентов и с ней связаны подчиненные таблицы, то такой первичный ключ является хорошим кандидатом на замену суррогатным ключом.

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

Другие ключи

Выше мы подробрго рассмотрели первичные ключи. Сейчас мы изугим еше два типа ключей - возможные и внешние.

Возможные ключи

Возможные ключи (или ключи-кандидаты) появляются при наличии у сушности более одного уникального идентификатора. Например, автомобиль можно уникальрю идентифицировать номерным знаком или заводским номером шасси. О номерном знаке и заводском номере шасси говорят, что они являются возможными ключами, так как оба могут играть роль первичного ключа.

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

Какой ключ выбрать в качестве первичного?

Что делать с ключом, который не является первичным?

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

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

Внешние ключи

Внешние ключи используются в таблице, которая является подчиненной по отношению к другой таблице (или к самой себе). Проблем проектирова-РПГЯ, связанных с внешними ключами, можно назвать только две - одна связана с дугами (см. главу 3), а вторая касается слутая, когда и главная, и подчиненная таблицы действительны по дате (ее мы рассмотрим в главе 7).

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

Индексы: обзор

Зачем создавать индекс для столбца или группы столбцов? До появления Oracle? было три возможных причины:

чтобы ускорить поиск в этих столбцах;

чтобы обеспечить уникальное значение в этих столбцах (только индексы UNIQUE);

чтобы извлекать строки в заданном порядке на основании индексированных столбцов.

Примечпппе

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

В Oracle? уникальность записи следует обеспечивать ограничениями PRIMARY KEY или UNIQUE. Мы, конечно, знаем, что если вводится ограничение, то эти ключи фактически используют уникальный индекс. Тем не менее, важно отметить, что в Oracle? мы явно создаем ограничение, а не индекс.

До версии 7,3, кроме полного сканирования таблицы, в Oracle было всего два способа поиска записей:

при помощи индексов, имеющих структуру В*-дерева (сбалансированного дерева) - для таблиц и кластеров;

itio