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

Как объяснялось в разделе 3.2, реляционные операции, такие как выборка, проекция и соединение, выполняются на уровне множеств. Поэтому реляционные языки часто на- зывают непроцедурными, так как пользователь указывает, что делать, а не как делать. Фактически пользователь говорит лишь, что ему нужно, без указания процедуры получе- ния результата. Процесс "навигации" по хранимой базе данных с целью удовлетворения запроса пользователя выполняется системой автоматически, а не пользователем вручную. Поэтому реляционные системы иногда называют системами автоматической навигации. В нереляционных системах за навигацию по базе данных, в основном, несет ответственность сам пользователь. На рис. 3.5 приведена яркая иллюстрация преиму- ществ автоматической навигации — оператору языка SQL INSERT противопоставлен код, выполняющий навигацию "вручную". Подобный код, возможно, должен написать для получения того же результата пользователь нереляционной системы (в данном случае — сетевой системы CODASYL; пример взят из главы по сетевым базам данных в [1.5]).

п Замечание. Здесь используется широкоизвестная база данных деталей и поставщиков. За.родробностями обратитесь к разделу 3.9.

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

INSERT INTO SP ( St, Pt, QTY )

VADLDES ( 'S4', 'P3', 1000 ) ; MOVE 'S4' TO St 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 Pt IN P < 'P3'

leave loop END-IF

FIND PRIOR SP WITHIN S-SP END-PERFORM MOVE 'P3' TO Pt 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 St 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.5. Примеры автоматической навигации и навигации вручную

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

RESULT := ( ЕМР WHERE EMPI = 'Е4' ) { SALARY } ;

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

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

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

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

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

• на какие переменные-отношения есть ссылки в запросе;

• насколько велики эти переменные-отношения;

• какие существуют индексы;

• насколько избирательны эти индексы;

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

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

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

Более подробные сведения об оптимизаторе приводятся в главе 17.