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

во-первых, необходимы и типы, и отношения (без типов нам не о чем говорить, без отношений мы ничего не сможем сказать);

во-вторых, типы и отношения достаточны так же, как и необходимы, т.е., логически говоря, нам не нужно что-либо еще.

Замечание. Также можно сделать вывод о том, что типы и отношения - это не одно и то же. К сожалению, в некоторых коммерческих продуктах (нереляционных по определению!) эти два понятия смешиваются. Мы еще вернемся к данному вопросу в главе 25 (раздел 25.2).

Кстати, важно понимать, что каждое отношение имеет связанный с ним предикат, включая отношения, полученные с помощью реляционных операторов, например оператора соединения. Отношение DEPT на рис. 3.1 и три результирующих отношения на рис. 3.2 имеют такие предикаты.

DEPT. Отдел с номером DEPTt называется DNAME и имеет бюджет BUDGET .

Выборка строк из DEPT, где BUDGET > 8М: Отдел с номером DEPTt называется DNAME и имеет бюджет BUDGET, который больше восьми миллионов долларов .

Извлечение столбцов DEPTi и BUDGET из DEPT: Отдел с номером DEPTt имеет какое-то название и бюджет BUDGET .

Соединение переменных-отношений DEPT и ЕМР на основе столбца DEPTi: Отдел с номером DEPTt называется DNAME и имеет бюджет BUDGET, а служащий с номером EMPt по фамилии ENAME работает в отделе с номером DEPTt и получает зарплату SALARY (заметим, что этот предикат имеет шесть параметров, а не семь, поскольку две ссылки на DEPTt обозначают один и тот же параметр).

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

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

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

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

INSERT INTO SP ( SI, Pi, QTY )

VADLUES ( S4, P3, 1000 ) ; MOVE S4 TO SI 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 Pi IN P < P3

leave loop END-IF

FIND PRIOR SP WITHIN S-SP END-PERFORM MOVE P3 TO PI 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 Si 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

Puc. 3.5. Примеры автоматической навигации и навигации вручную

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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