названиями. К тому времени, когда мы доберемся до города (TOWN), который идентифицируется комбинацией названия области (REGION) в пределах страны (COUNTRY) и названия города, ключ будет состоять из трех компонентов. Сущность STREET ( Улица ) будет иметь четыре компонента, сущность HOUSE ( Дом ) - пять и т.д. Чтобы сослаться на конкретный дом в таблице BUILDING CONTRACTOR ( Строительный подрядчик ), мы должны иметь пять компонентов внещнего ключа. Не кажется ли вам, что это многовато? В табл. 6.1 представлены таблицы, которые построены по схеме сущность-отношение , изображенной на рис. 6.3, и содержат некоторые данные (по одной строке в каждой).

Таблица 6.1. Определения таблиц, демонстрирующие длинный каскадный ключ

REGIONS ( Области )

STREETS ( Улицы )

HOUSES ( Дома )

(Таблица BUILDING CONTRACTORS ( Строительные подрядчики ) не показана )

Как видно, в результате каждый столбец таблицы HOUSES является компонентом первичного ключа. Как упростить эту ситуацию? Конечно, Можно снабдить таблицу HOUSES суррогатным ключом. Но предположим, требуется, чтобы по имени владельца можно было найти (с какой-то неясной целью) самый большой номер дома этого владельца на улице. При использовании представленной в табл. 6.1 структуры необходимый для этого SQL-запрос будет выглядеть так:

SELECT МАХ (hsl.no) fROM houses hsl

WHERE EXISTS

(SELECT NULL

FROM houses hs2

WHERE hs2 . f own id = 2061

AND hsl.f st name = hs2.f st name

AND hsl.f tn narae = hs2.f tn name

AND hsl.f reg name = hs2.f reg name

AND hsl.f co name = hs2.fco name);

Введем в таблицу STREETS суррогатный ключ и посмотрим, что изменилось. В табл. 6.2 представлены новые определения таблиц (определения, оставшиеся без изменений, не показаны).

Таблица 6.2. Новые определения таблиц. В таблицу STREETS введен суррогатный ключ STREETS (Улицы)

HOUSES (Дома)

Теперь SQL-запрос для поиска максимального номера дома данного владельца на улице несколько упростился:

SELECT МАХ (hsl.no) FROM houses hsl WHERE EXISTS

(SELECT NULL

FROM houses hs2

WHERE hs2.f own id = 2061

AND hsl.street id = hs2.street id);

Ho получается, что ввод суррогатного ключа не дал нам ничего, кроме упрощения SQL-запроса. Однако не следует отказываться от преимуществ, которые дает такое упрощение, - этот запрос сжат и поэтому прост для чтения и понимания, его легче разбирать, и вероятность ошибок при вводе ниже.

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

Итак, запомните простое правило: чем короче ключи, тем быстрее работают приложения.

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

SELECT МАХ (hsl.no) FROM houses hsl WHERE hsl.f co name = United Kingdom;

Уменьшить степень влияния каскадных ключей можно с помощью сокращенных названий - например, в предыдущем примере вместо United Kingdom в качестве значения внешнего ключа использовать UK, Создание эквивалентного запроса для модели с суррогатными ключами оставляем вам в качестве упражнения, но поверьте, что изящным его не назовешь.

При использовании длинных каскадных ключей возникает еще одна проблема - в случае, когда ключевые столбцы где-то в цепочке нужно обновить. Естественно, чем выше уровень иерархии, на котором происходит это изменение, тем больше объем каскадно распространяющихся обновлений. В наше время ни в коем случае нельзя зависеть от статических вещей! Изменяются даже страны - об этом свидетельствует распад Советского Союза! Давайте рассмотрим не сложный пример, связанный с распадом или объединением, а более простой, когда страна изменяет свое название: Персия стала Ираном, Родезия - Зимбабве и т,д. В нашей модели данных нельзя обойтись простым обновлением таблицы COUNTRIES, обновление необходимо каскадно распространить на таблицы REGIONS, TOWNS, STREETS, HOMES и т.д.

Реляционные пуристы скажут, что нельзя обновлять столбцы первичного ключа, поэтому нужно удалить все адреса в Родезии и вставить их в Зимбабве, Предоставляем вам право самим решить, можно обновлять первичный ключ или нет. У обеих сторон в этом споре есть достаточно веские аргументы. Достаточно сказать, что Oracle? позволяет осуществить обновление первичного ключа без каскадного распространения изменений во внешние ключи. Некоторые другие реляционные системы управления базами данных обновление первичного ключа попросту запрещают. Если в таблице есть возможные первичные ключи (т,е, более одного обязательного уникального ключа), то, конечно, мы считаем, что в качестве первичного следует выбрать тот, который не изменяется.

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