3.5. Оптимизация

Как уже объяснялось выше, реляционные операции, такие как SELECT, PROJECT и JOIN, выполняются на уровне множеств. Поэтому реляционные языки, такие как SQL, часто называют непроцедурными, так как пользователь указывает, что делать, а не как делать, т.е. пользователь говорит, что ему нужно, без указания процедуры получения результата. Процесс "навигации" по хранимой базе данных для удовлетворения пользовательского запроса выполняется системой автоматически, а не пользователем вручную. Поэтому реляционные системы иногда называют системами автоматической навигации. В нереляционных системах за навигацию по базе данных в основном несет ответственность пользователь. На рис. 3.3 приведена яркая иллюстрация преимуществ автоматической навигации— оператору SQL insert противопоставлен код, выпол­няющий навигацию "вручную"; подобный код, возможно, должен написать пользова­тель нереляционной системы для получения того же результата.

Несмотря на эти замечания, следует отметить, что "непроцедурный" — это хотя и общепринятый, но не совсем точный термин, потому что процедурный и непроцедур­ный — понятия относительные. Можно лишь с уверенностью сказать, что язык А более (или менее) процедурный, чем язык Б. Поэтому точнее будет сказать, что реляционные языки, такие как SQL, принадлежат более высокому уровню абстракции, чем языки программирования, такие как С или COBOL (или подъязыки данных, обычно принад­лежащие нереляционным СУБД; убедитесь в этом сами — см. рис. 3.3)

INSERT INTO SP ( S#, P#, QTY )

______VALUES ( 'S4', 'P3', 1000 )

MOVE 'S4' TO S# IN S

FIND CALC S

ACCEPT S-SP-ADDR FROM S-SP CURRENCY

FIND LAST SP WITHIN S-SP

while SP found PERFORM

ACCEPT S-SP-ADDR FROM S-SP CURRENCY

FIND OWNER WITHIN P-SP

GET P

IF P# IN P < 'P3'

leave loop

END-IF

FIND PRIOR SP WITHIN S-SP

END-PERFORM

MOVE 'P3' TO P# IN P

FIND CALC P

ACCEPT P-SP-ADDR FROM P-SP CURRENCY

FIND LAST SP WITHIN P-SP

while SP found PERFORM

ACCEPT P-SP-ADDR FROM P-SP CURRENCY

FIND OWNER WITHIN S-SP

GET S

IF S# IN S < 'S4'

leave loop

END-IF

FIND PRIOR SP WITHIN P-SP

END-PERFORM

MOVE 1000 TO QTY IN SP

FIND DB-KEY IS S-SP-ADDR

FIND DB-KEY IS P-SP-ADDR

STORE SP

CONNECT SP TO S-SP

CONNECT SP TO P-SP

Рис. 3.3. Автоматическая и ручная навигация

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

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

RESULT := ( ЕМР WHERE ЕМР# = 'Е4' ) [ SALARY ] ;

Пояснение. Выражение в первых скобках (емр where ...) означает запрос выборки строк из таблицы ЕМР, а именно строки, в которой значение ЕМР# равно Е4. Название столбца в квадратных скобках (salary) означает запрос выборки столбцов (также назы­ваемый проекцией) из результата выборки строк, а именно столбца SALARY. И, наконец, оператор присвоения (:=) означает запрос присвоения результата выборки столбцов таблице RESULT. Следовательно, после выполнения запроса RESULT — это таблица из одной строки и одного столбца, содержащая зарплату служащего Е4. (Здесь использован синтаксис реляционных операций, который подробно будет описан в сле­дующих главах. Обратите также внимание, что в данном случае в явном виде использу­ется реляционное свойство замкнутости: мы написали вложенное выражение, в кото­ром результат выборки строк — это входные данные для выборки столбцов.)

Даже в этом простом примере существует, по крайней мере, два способа выполне­ния поиска необходимых данных.

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

2. Если есть индекс для столбца ЕМР# (в хранимой версии) таблицы (который, веро­ятно, действительно существует, поскольку этот столбец является первичным ключом, а большинство систем фактически требуют создания индекса по первич­ному ключу), то переход с помощью этого индекса непосредственно к данным служащего Е4.

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

• на какие таблицы есть ссылки в запросе (может быть несколько ссылок, если, на­пример, используются какие-то соединения);

• насколько велики эти таблицы;

• какие индексы созданы;

• как выбраны эти индексы;

• как физически группируются данные на диске;

• какие реляционные операции используются и т.д.

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

Более подробные сведения об оптимизаторе можно получить в главе 18.