17.8. Резюме

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

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

/* Построение хеш-таблицы Н по атрибуту S.C */

do j := 1 to n ; /* Внешний цикл */

k := hash (S[j].C)

<добавить в таблицу H[k] запись для S[j]> end ;

/* Теперь выполняется поиск по хеш-таблице для */ /* каждого из кортежей отношения R */

Рис. 17.8. Метод хеширования

Процесс оптимизации в общем случае включает четыре последовательные стадии.

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

• Преобразование в каноническую форму с помощью различных законов преоб- разования.

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

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

Далее обсуждались общие законы распределения, коммутативности и ассоциативно- сти и их применение к реляционным операторам, таким как соединение. Кроме того, рас- сматривалось применение этих законов к арифметическим и логическим операторам, а также к операторам сравнения. Затрагивался и другой общий закон — идемпотентности. Затем обсуждались некоторые специальные преобразования операторов проекции и выбор- ки. После этого была представлена идея семантической оптимизации, т.е. преобразования запросов, которое базируется на знании системой установленных ограничений целостности.

В демонстрационных целях был сделан беглый очерк статистических показателей ба- зы данных, используемых в СУБД DB2 и INGRES. Далее обсуждалась одна из стратегий, построенных по принципу "разделяй и властвуй", — декомпозиция запросов, впервые реализованная в прототипе системы INGRES. Было также отмечено, что стратегии, по- строенные по принципу "разделяй и властвуй", весьма привлекательны для сред с под- держкой параллельных вычислений и распределенных систем.

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

В заключение хотелось бы отметить, что, к сожалению, многие современные про- граммные продукты содержат некоторые замедлители оптимизации, о которых поль- зователь должен по крайней мере знать (даже если с этим ничего нельзя поделать). За- медлитель оптимизации — это функция СУБД, не позволяющая оптимизатору выпол- нять свою работу так, как она могла бы быть выполнена (например, при отсутствии дан- ной функции). К замедлителям оптимизации можно, например, отнести возможность вставки в таблицу записей-дубликатов [5.6], трехзначную логику (глава 18) и реализа- цию трехзначной логики в языке SQL [18.6], [18.10].

Упражнения

17.1. Одни пары выражений в контексте базы данных поставщиков, деталей и про- ектов эквивалентны, а другие — нет. Какие пары выражений действительно эквивалентны?

al) S JOIN ( ( Р JOIN J } WHERE CITY = 'London' a2) ( P WHERE CITY = 'London' ) JOIN ( J JOIN S )

61) ( S MINUS ( { S JOIN SPJ ) WHERE Pi = Pi ( 'P2' ) )

{ Si, SNAME, STATUS, CITY } } {Si, CITY }

62) S { Si, CITY } MINUS

( S { Si, CITY } JOIN

( SPJ WHERE Pi = Pi ( 'P2' ) ) ) { Si, CITY }

в1) ( S { CITY } MINUS P { CITY } ) MINUS J { CITY }

в2) ( S { CITY } MINUS J { CITY } )

MINUS ( P { CITY } MINUS J { CITY } )

rl) ( J { CITY } INTERSECT P { CITY } ) UNION ( S { CITY } )

r2) J { CITY } INTERSECT ( S { CITY } UNION P { CITY } )

д1) ( ( SPJ WHERE Si = Si ('SI' ) )

UNION ( SPJ WHERE Pi = Pi ( 'PI' ) ) )

INTERSECT

( ( SPJ WHERE Ji = Ji ( 'Jl' ) )

UNION ( SPJ WHERE Si = Si ( 'SI' ) ) j

д2) ( SPJ WHERE Si = Si ( 'SI' ) ) UNION

( ( SPJ WHERE Pi = Pi ( 'PI' ) ) INTERSECT ( SPJ WHERE Ji = Ji ( 'Jl' ) ) )

el) ( S WHERE CITY = 'London' ) UNION ( S WHERE STATUS > 10 )

e2) S WHERE CITY = 'London' AND STATUS > 10

ж1) ( S { Si } INTERSECT ( SPJ WHERE Ji = Jl ( 'Jl' ) ) { Si } ) UNION ( S WHERE CITY = 'London' ) { Si }

ж2) S { Si } INTERSECT ( ( SPJ WHERE Ji = Ji ( 'Jl' ) ) { Si } ) UNION { S WHERE CITY = 'London' J { Si } }

3l) ( SPJ WHERE Ji = Ji ( 'Jl' ) } { Si }

MINUS ( SPJ WHERE Pi = Pi ( 'PI' ) ) { St }

з2) { { SPJ WHERE Ji = J| ( 'Jl' ) )

MINUS { SPJ WHERE Pi = PI ( 'PI' ) ) ) { Si } и1) S JOIN ( P { CITY } MINUS J { CITY } ) и2) { S JOIN P { CITY } ) MINUS ( S JOIN J { CITY } )

2. Докажите, что операции соединения, объединения и пересечения являются комму- тативными, а операция вычитания -— нет.

3. Докажите, что операции соединения, объединения и пересечения являются ассо- циативными, а операция вычитания — нет.

4. Докажите, что:

а) объединение распределяется по пересечению;

б) пересечение распределяется по объединению.

17.5. Докажите, что для всех А и В:

а) A UNION ( A INTERSECT В ) = А;

б) A INTERSECT { A UNION В ) = А.

Замечание. Эти два закона называются законами поглощения. Как и законы идемпотентности, коммутативности и т.д., они могут оказаться полезными при проведении оптимизации.

17.6. Докажите следующее.

а) Выборка безусловно распределяема по объединению, пересечению и вычита- нию и условно распределяема по соединению.

б) Проекция безусловно распределяема по объединению и пересечению, условно распределяема по соединению и не распределяема по вычитанию. Запишите соответствующие критерии для условной распределяемости.

7. Распространите правила преобразования, изложенные в разделе 17.4, так, чтобы учитывались операторы EXTEND и SUMMARIZE.

8. Можно ли сформулировать какие-либо полезные правила преобразований для опе- рации реляционного деления?

9. Запишите соответствующий набор правил преобразования для условий, в которых используются операторы AND, OR и NOT. Примером таких правил может служить за- кон коммутативности для оператора AND, т.е. утверждение, что выражение A AND В тождественно выражению В AND А.

10. Распространите ответ на предыдущее упражнение, включив в сферу его действия условия, в которых используются кванторы EXISTS и F0RALL. Примером может служить правило, изложенное в главе 7, и позволяющее преобразовать выражения, использующие квантор F0RALL, в выражения с отрицаемым квантором EXISTS.

17.11.Ниже перечислены ограничения целостности для базы данных поставщиков, дета- лей и проектов.

■ Допустимыми городами являются Лондон ('London'), Париж ('Paris'), Рим ('Rome'), Афины ('Athens'), Осло ('Oslo'), Стокгольм ('Stockholm'), Мадрид ('Madrid') и Амстердам ('Amsterdam').

■ Никакие два проекта не могут быть размещены в одном и том же городе.

• В любой момент в Афинах может находиться не более одного поставщика.

• Ни одна поставка по количеству не может превышать удвоенное среднее значе- ние количества по всем поставкам.

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

• Каждый проект должен находиться в городе, в котором есть хотя бы один по- ставщик этого проекта.

• Должна существовать по крайней мере одна красная деталь.

• Среднее значение статуса поставщика должно быть больше 18.

• Каждый поставщик из Лондона должен поставлять деталь с номером ' Р2'.

• Хотя бы одна красная деталь должна весить меньше 50 фунтов.

• Поставщики из Лондона поставляют больше различных видов деталей, чем по- ставщики из Парижа.

• Поставщики из Лондона поставляют больше деталей (по общему количеству), чем поставщики из Парижа.

Ниже перечислены простые запросы к этой базе данных:

а) выбрать сведения о поставщиках, которые не поставляют деталь с номером ' Р2';

б) выбрать сведения о поставщиках, которые не поставляют детали для какого- либо проекта в том же городе, где они находятся;

в) выбрать сведения о таких поставщиках, для которых не существует других по- ставщиков, поставляющих меньше видов деталей;

г) выбрать сведения о поставщиках из Осло, которые поставляют по крайней мере два разных вида деталей из Парижа для по крайней мере двух разных проектов в Стокгольме;

д) выбрать сведения о парах поставщиков из одного города, поставляющих пары деталей из одного и того же города;

е) выбрать сведения о парах поставщиков из одного города, поставляющих детали парам проектов, находящихся в одном городе;

ж) выбрать сведения о деталях, поставляемых хотя бы для одного проекта, но только теми поставщиками, которые размещены не в том городе, где находится сам проект;

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

Используйте приведенные выше ограничения целостности для преобразования дан- ных запросов в более простую форму (но все еще на обычном языке — от вас не требуется выполнять это упражнение формально). 17.12.Исследуйте доступную вам СУБД. Выполняет ли эта система преобразование вы- ражений (сейчас это делают не все СУБД)? Если это так, то какие выполняются преобразования?

17.13. Попробуйте провести следующий эксперимент. Возьмите простой запрос, например "Выбрать имена поставщиков детали с номером 'Р2'", и запишите его всеми извест- ными вам способами с помощью любого доступного языка запросов (возможно, это будет язык SQL). Создайте и заполните данными подходящую тестовую базу данных, выполните все версии запроса и определите время выполнения каждой версии. Если полученные значения будут сильно различаться, значит, экспериментально доказано,

что оптимизатор системы не полностью справляется с задачей преобразования вы- ражений. Повторите этот эксперимент с различными исходными запросами. Если возможно, повторите этот же эксперимент в разных СУБД.

Замечание. Безусловно, разные версии запроса должны давать идентичные резуль- таты. Если же результаты различаются, то, возможно, вы совершили ошибку или ошибка существует в оптимизаторе рассматриваемой СУБД. Если обнаружена ошибка в оптимизаторе, сообщите об этом разработчику СУБД!

17.14. Исследуйте любую доступную вам СУБД. Поддерживает ли она какие-либо стати- стические показатели базы данных (это делают не все СУБД)? И если поддерживает, то какие именно? Как эти статистические показатели обновляются — динамически или с помощью какой-либо утилиты? Если статистические показатели обновляются с помощью утилиты, то как называется утилита и как часто она запускается? Насколь- ко выборочно ее действие (в том смысле, что при запуске утилиты со специфически- ми параметрами обновляется только определенная статистика)?

17.15.В разделе 17.5 было сказано, что в состав статистических показателей, поддерживае- мых СУБД DB2, входят второе наибольшее и второе наименьшее значения каждого столбца в каждой базовой таблице. Почему выбраны именно вторые значения?

17.16.В некоторых коммерческих продуктах пользователю разрешается создавать указате- ли для оптимизатора. Например, в СУБД DB2 спецификация OPTIMIZE FOR л ROWS в объявлении SQL-курсора означает, что пользователь предполагает извлечь с помо- щью данного курсора не более л строк (т.е. оператор FETCH будет выполнен для дан- ного курсора не более л раз). Такая спецификация иногда может позволить оптими- затору выбрать более эффективный путь доступа, по крайней мере в случае, когда пользователь действительно выполняет оператор FETCH не более л раз. Оправдано ли, по вашему мнению, применение таких указателей? Обоснуйте свой ответ.

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

Список литературы

Оптимизация представляет собой чрезвычайно большую и постоянно развиваю- щуюся область исследований. Важность этих исследований становится значительнее, чем когда-либо прежде в связи с все возрастающим интересом к системам поддержки принятия решений, речь о которых пойдет в главе 21. Достаточно сказать, что за послед- ние несколько лет около 50% докладов на ежегодных конференциях ACM SIGMOD в той или иной мере были посвящены именно вопросам оптимизации. Приведенный ниже список представляет собой относительно небольшую выборку из обширной литературы по оптимизации и связанным с ней вопросам. Условно он разбит на следующие группы.

■ В [17.1]-[17.7] содержится обзор общих проблем оптимизации или введение в эту тему.

• В [17.8]—[17.17] рассматриваются эффективные методы реализации отдельных реляционных операций, таких как соединение и обобщение.

• В [17.18]—[17.33] представлены различные приемы преобразования выражений, описанные в разделе 17.4. В частности в [17.27]—[17.30] рассматриваются се- мантические преобразования.

• В [17.34]—[17.45] обсуждаются приемы, использованные в System R, СУБД DB2 и СУБД INGRES, а также общая проблема оптимизации вложенных запросов в стиле языка SQL.

• В [ 17.46]—[ 17.61] содержится описание многочисленных приемов, хитростей и идей, подлежащих исследованию в будущем, и т.п. В частности, в [17.58]- [17.61] рассмотрено влияние параллельной обработки на вопросы оптимизации.

Замечание. Публикации, в которых рассматривается оптимизация в распределен- ных системах, умышленно исключены из данного списка (см. главу 20).

17.1. Kim W., Reiner D.S., Batory D.S. (eds.). Query Processing In Database Systems. — New York, N.Y.: Springer-Verlag, 1985.

Это антология работ, посвященных общим проблемам обработки запросов (не только по оптимизации). Книга состоит из вступительного обозрения Джарка (Jarke), Коха (Koch) и Шмидта (Schmidt), которое перекликается с публикацией [17.3], но не по- вторяет ее. Далее следуют работы, описывающие обработку запросов в различных контекстах: распределенные базы данных, гетерогенные СУБД, проблемы обновле- ния представлений (работа [9.11] является одной из статей в этом разделе), нетради- ционные приложения (например, CAD/САМ), оптимизация многооператорных за- просов [17.49], машины баз данных и физическое проектирование базы данных.

2. Special Issue on Query Optimization // IEEE Database Eng. — September, 1982. — 5, № 3. Это сборник из 13 коротких статей (академического и коммерческого направлений), в которых описываются различные аспекты оптимизации запросов.

3. Jarke М., Koch J. Query Optimization in Database Systems // ACM Сотр. Surv. — June, 1984. — 16, №2.

Отличное учебное пособие. Включает обобщенную систему взглядов по проблеме вычисления запросов, подобную представленной в разделе 17.3 данной главы, но базирующуюся на реляционном исчислении, а не на алгебре. После этого в рамках описанной системы взглядов обсуждается множество приемов оптимизации: син- таксические и семантические преобразования, низкоуровневые операции реализа- ции и алгоритмы генерации планов запроса и выбора плана с наименьшей стоимо- стью. Приводится также обширный набор правил синтаксических преобразований. Имеется достаточно большой список литературы (без аннотаций). Заметьте, одна- ко, что после 1984 года по данной теме было опубликовано на порядок больше ра- бот, чем до 1984 года [17.4].

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

17.4. Graefe G. Query Evaluation Techniques for Large Databases // ACM Сотр. Surv. — June, 1993. —25, №2.

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

17.5. Palermo F.P. A Data Base Search Problem // J.T. Todd (ed.), Information Systems: COINS IV. — New York, N,Y,: Plenum Press, 1974.

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

• Никакой кортеж не может извлекаться дважды.

• Ненужные значения удаляются из кортежа во время его извлечения. Здесь под не- нужными значениями подразумеваются либо значения атрибутов, не упомянутых в запросе, либо значения, используемые только для организации выборки. Этот процесс эквивалентен проекции отношения по некоторым "нужным" атрибутам, а потому позволяет сократить не только пространство, выделяемое для каждого кортежа, но и количество кортежей, с которыми ведется работа (в общем случае).

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

• Для создания соединений применяется эффективный метод, основанный, во- первых, на динамическом разложении значений, используемых в соединяемых членах (например таких, как S.Sf = SP.Sf), на полусоединения, которые фак- тически являются некоторой разновидностью динамически создаваемого вто- ричного индекса (полусоединения Палермо отличаются от полусоединений, описанных в главе 6), и, во-вторых, на использовании внутреннего представле- ния каждого соединения, называемого косвенным соединением (indirect join), в котором для идентификации кортежей — участников соединения используются внутренние идентификаторы кортежей. Эти методы предназначены для сокра- щения количества просмотров, необходимых для выполнения соединения, за счет получения гарантии, что соединяемые кортежи каждого члена соединения логически упорядочены в соответствии со значениями атрибутов соединения. Благодаря этому допускается динамическое определение "наилучшей" после- довательности операций доступа к нужным отношениям.

17.6. Gray J. (ed.). The Benchmark Handbook for Database and Transaction Processing Systems (2nd edition). — San Francisco, Calif: Morgan Kaufmann, 1993.

Совет по обработке транзакций (Transaction Processing Council — TPC) является неза- висимой организацией, которая на протяжении ряда лет разработала несколько тестов, фактически принятых в качестве промышленного стандарта. В данной книге содержит-

ся подробное описание этих тестов (а также некоторых других). Тест ТРС-А предназна- чен для измерения производительности OLTP-обработки (где сокращение OLTP озна- чает Online Transaction Processing, т.е. оперативная аналитическая обработка). Тест ТРС- В является особой версией теста ТРС-А, предназначенной для измерения производи- тельности СУБД и базовой операционной системы при игнорировании особенностей взаимодействия с пользователями и т.п. Тест ТРС-С моделирует работу системы приема и регистрации заказов (фактически это существенно расширенный вариант теста ТРС- А). Тест TPC-D предназначен для измерения производительности работы системы под- держки принятия решений. Он включает набор из 17 достаточно сложных SQL- запросов (по сути, это единственный тест из четырех перечисленных выше, который позволяет оценить качество работы собственно оптимизатора).

Замечание. Разработчики СУБД конкурируют друг с другом, добиваясь получения более высоких показателей производительности при тестировании своих продуктов с помощью перечисленных выше тестов. Однако следует отметить, что их рекламные заявления нужно интерпретировать с чрезвычайной осторожностью, поскольку раз- работчики и поставщики систем баз данных склонны прибегать к разнообразным уловкам и трюкам для формального повышения показателей эффективности выпол- нения этих тестов. Поэтому caveat emptor (пусть покупатель будет бдителен)!

17.7. Bitton D., DeWitt D.J., Turbyfill С. Benchmarking Database Systems: A Systematic Approach // Proc. 9th Intern. Conf. on Very Large Data Bases. — Florence, Italy, October-November, 1983.

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

17.8. Bing Yao S. Optimization of Query Evaluation Algorithms // ACM TODS.— June, 1979. —4, №2.

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

■	Индексирование выборок	■	Фильтрация выборки
■	Индексирование соединений	■	Фильтрация соединения
■	Пересечение	■	Сортировка
■	Доступ к записям	■	Конкатенация
■	Последовательный просмотр	■	Проекция
■	Связный просмотр

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

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

17.9. Blasgen M.W., Eswaran К.Р. Storage and Access in Relational Databases // IBM Sys. J. — 1977. — 16, № 4.

Представлены результаты сравнения различных приемов обработки запросов, в ко- торых используются операции проекции, выборки и соединения, на основе их стоимости, выраженной в операциях ввода-вывода. Основные компоненты этих методов реализованы в системе System R [17.34]. 17.10.Merrett Т.Н. Why Sort/Merge Gives the Best Implementation of the Natural Join // ACM SIGMOD. —January, 1983. — 13, №2.

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

а) операция соединения будет наиболее эффективной, если оба отношения будут отсортированы по значениям атрибута, по которому выполняется соединение (поскольку в данном случае, как показано выше, в разделе 17.7, слияние — дос- таточно эффективный метод оптимизации, а выборка каждой страницы выпол- няется только один раз, что действительно является оптимальным);

б) стоимость сортировки отношений в необходимом порядке (на достаточно больших машинах) будет, вероятно, меньше стоимости любой схемы, в которой не требуется упорядоченность кортежей в обоих отношениях.

Тем не менее автор допускает, что для его радикальной позиции могут существо- вать исключения. Например, одно из отношений может быть настолько мало (например, в случае, когда оно является результатом предыдущей операции вы- борки), что прямой доступ ко второму отношению через индекс или хеш-таблицу будет иметь меньшую стоимость, чем сортировка второго отношения. В [17.8]— [17.11] приведены дополнительные примеры, в которых метод сортировки-слияния на практике не является лучшим приемом обработки. 17.11.Sacco G.M. Fragmentation: A Technique for Efficient Query Processing // ACM TODS. — June, 1986. — 11, № 2.

Представлен один из методов, использующих принцип "разделяй и властвуй" для выполнения операции соединения. Согласно этому методу соединяемые от- ношения рекурсивно разбиваются на подмножества кортежей (фрагменты) и в этих фрагментах выполняется серия последовательных просмотров. В отличие от метода сортировки-слияния этот метод не требует предварительной сортиров- ки отношений. Показано, что фрагментация всегда работает эффективнее сорти- ровки-слияния, когда последний метод требует предварительной сортировки обоих отношений, и иногда работает лучше, если метод сортировки-слияния требует предварительной сортировки только одного (большего) отношения. Ав- тор утверждает, что данный метод можно применять и для других операций, та- ких как пересечение и вычитание. 17.12. Shapiro L.D. Join Processing in Database Systems with Large Main Memories // ACM TODS. — September, 1986. — 11, Ns 3.

Представлено три новых алгоритма хеширования при выполнении операции со- единения. Один из них "особенно эффективен при наличии основной памяти в размере, значительно превышающем размер одного из соединяемых отношений". Алгоритмы работают благодаря разбиению отношений на непересекающиеся части (т.е. выборки), которые можно обрабатывать в основной памяти. Автор заявляет, что, исходя из наблюдаемого снижения цен на первичную память, методы на осно- ве хеширования могут стать одними из лучших. 17.13.Negri М., Pelagatti G. Distributive Join: A New Algorithm for Joining Relations // ACM TODS. — December, 1991. — 16, № 4.

Здесь представлен другой метод соединения, использующий принцип "разделяй и властвуй", который "...базируется на идее о том, что... не нужно полностью сортиро- вать оба отношения... Достаточно отсортировать одно отношение полностью, а дру- гое — лишь частично, избежав таким образом расходов на выполнение полной сор- тировки второго отношения". При частичной сортировке рассматриваемая перемен- ная-отношение разбивается на последовательность неупорядоченных подмножеств кортежей PI, Р2,Рп (похоже на метод Сакко (Sacco) [17.11], за исключением того, что в методе Сакко используется хеширование вместо сортировки), обладающих следующим свойством: MAX(P[i] J < MIN(P[i+l]) для всех i (1, 2, п-1). Ут- верждается, что данный метод работает эффективнее метода сортировки-слияния. 17.14.Graefe G., Cole R.L. Fast Algorithms for Universal Quantification in Large Databases // ACM TODS. — June, 1995. — 20, № 2.

Квантор всеобщности (FORALL) в языке SQL непосредственно не поддерживается, а потому он не поддерживается и в современных коммерческих СУБД, хотя он чрез- вычайно важен для формулировки широкого класса запросов. В этой статье опи- сываются и сравниваются "три известных алгоритма и один недавно предложен- ный алгоритм реляционного деления, которое является алгебраическим операто- ром, включающим квантор всеобщности". В ней также показано, что новый алго- ритм работает "с той же скоростью, с какой выполнение хешированного полусо- единения позволяет получить оценку значения квантора существования для тех же отношений". Помимо всего прочего, авторы делают вывод, что квантор FORALL не- обходимо включить в пользовательский язык, так как большинство оптимизаторов "не распознает его косвенные формулировки на языке SQL". 17.15.Bitton D., DeWitt D.J. Duplicate Record Elimination in Large Data Files // ACM TODS. — June, 1983. — 8, № 2.

Традиционный метод исключения кортежей-дубликатов состоит в сортировке за- писей с последующим последовательным просмотром. Данная работа предлагает альтернативное решение, более эффективное для файлов большого размера. 17.16. Simmen D., Shekita Е., Malkemus Т. Fundamental Techniques for Order Optimization // Proc. 1996 ACM SIGMOD Int. Conf. on Management of Data. — Montreal, Canada, June, 1996. В этой работе представлены методы оптимизации или исключения сортировок. Они частично основаны на работе Дарвена [10.6] и именно в таком виде реализо- ваны в СУБД DB2.

17.17.Manku G.S., Rajagopalan S., Lindsay B.G. Approximate Medians and Other Quantities in One Pass and with Limited Memory // Proc. 1998 ACM SIGMOD Int. Conf. on Management of Data. — Seattle, Wash., June, 1998.

17.18.Smith J.M., Yen-Tang Chang P. Optimizing the Performance of a Relational Algebra Database Interface // CACM. — October, 1975. — 18, № 10.

Описан алгоритм, использовавшийся в языке "Smart Query Interface for a Relational Algebra" (SQUIRAL). Этот алгоритм включает следующее.

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

• Привязка отдельных операций в преобразованном выражении к определенным процессам и использование параллельной и конвейерной обработок для выпол- нения операций.

• Координация порядка сортировки в промежуточных результатах, передаваемых между процессами.

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

Эта статья была одной из первых работ, посвященных преобразованиям выражений. 17.19.Hall P.A.V. Optimization of a Single Relational Expression in a Relational Data Base System // IBM J. R&D. — May, 1976. — 20, № 3.

Описаны некоторые методы оптимизации, используемые в системе PRTV [6.9], ко- торая, как и язык SQUIRAL [17.18], начинает обработку запроса с преобразования данного алгебраического выражения в некоторую более эффективную форму. Осо- бенностью системы PRTV является то, что она не вычисляет каждое выражение автоматически, как только оно будет получено. Вместо этого выражения комбини- руются с полученными ранее в более сложное выражение и вычисление отклады- вается до последнего момента (см. обсуждение пошаговой формулировки запроса в главе 6, раздел 6.5). Таким образом, "отдельное реляционное выражение" (из за- головка статьи) на самом деле представляет целую последовательность операций пользователя. Данный метод оптимизации подобен методу языка SQUIRAL, но в некоторых перечисленных ниже случаях работает лучше.

• Выборка выполняется настолько рано, насколько это возможно.

• Последовательность проекций комбинируется в одну операцию проекции.

• Избыточные операции исключаются.

• Выражения, использующие пустые отношения и тривиальные условия, упрощаются.

• Общие выражения выносятся за скобки.

В заключении работы изложены результаты некоторых экспериментов, а также указаны направления дальнейших исследований. 17.20. Jarke М., Koch J. Range Nesting: A Fast Method to Evaluate Quantified Queries // Proc. 1983 ACM SIGMOD Intern. Conf. on Management of Data. — San Jose, Calif, May, 1983. Предложен вариант реляционного исчисления, в котором допускается примене- ние некоторых дополнительных (и полезных) правил синтаксического преобра- зования. Представлены алгоритмы вычисления выражений в описанном исчис- лении. (Это исчисление очень напоминает исчисление кортежей, упомянутое в главе 7.) Кроме того, описана оптимизация в предложенном исчислении отдель- ного класса выражений, называемых "точными вложенными выражениями". Из- ложены методы преобразования в точные выражения относительно сложных за-

просов (в частности, запросов, использующих квантор FORALL). Авторы показы- вают, что в точные выражения можно преобразовать большое количество запро- сов, используемых на практике.

17.21.Chaudhari S., Shim К. Including Group-By in Query Optimization // Proc. 20th Int. Conf. on Very Large Data Bases. — Santiago, Chile, September, 1994.

17.22.Makinouchi A., Tezuka M., Kitakami H., Adachi S. The Optimization Strategy for Query Evaluation in RDB/V1 // Proc. 7th Intern. Conf. on Very Large Data Bases— Cannes, France, September, 1981.

Система RDB/V1 является прототипом будущего программного продукта AIM/RDB компании Fujitsu (это SQL-система). В публикации описаны приемы оптимизации, используемые в данном прототипе. Они кратко сравниваются с аналогичными прие- мами, используемыми в прототипах систем INGRES и System R. Один из приемов является новым и состоит в применении динамически полученных значений функции МАХ и MIN для выполнения дополнительных выборок. Подобный прием приводит к упрощению процесса выбора порядка соединения и повышает производительность самой операции соединения. В качестве простого примера для последнего утвержде- ния предположим, что нужно соединить отношения поставщиков S и деталей Р по ат- рибуту CITY. Сначала отношение S сортируется по атрибуту S. CITY. В процессе сор- тировки для атрибута S. CITY определяются значения функций МАХ и MIN; обозначим их через HIGH и LOW соответственно. Тогда для уменьшения количества кортежей от- ношения Р, которые потребуется проверять в процессе выполнения соединения, можно использовать следующую выборку.

1. LOW < P.CITY AND P.CITY < HIGH

17.23.Pirahesh H., Hellerstein J.M., Hasan W. Extensible Rule Based Query Rewrite Optimization in Starburst // Proc. 1992 ACM SIGMOD Intern. Conf. on Management Data. — San Diego, Calif, June, 1992.

Как отмечалось в разделе 17.1, для преобразования выражений используется еще одно название — перезапись запросов (query rewrite). По мнению авторов, не- сколько неожиданно то, что в современных реляционных СУБД мало внимания уделяется такому преобразованию (по крайней мере, по состоянию на 1992 год). В работе описан механизм преобразования выражений прототипа системы Starburst корпорации IBM [17.50], [25.14], [25.17], [25.21], [25.22]. Пользователи с соответствующей квалификацией могут в любое время добавить в систему но- вые правила преобразования выражений (вот почему в заголовке статьи указано слово "расширяемый" — "extensible"). 17.24. Mumick I.S., Finkelstein S.J., Pirahesh H., Rarnakrishnan R. Magic is Relevant // Proc. 1990 ACM SIGMOD Intern. Conf. on Management Data. — Atlantic City, N.J., May, 1990. Неудачный термин "magic" ("волшебный") используется в данной публикации для ссылок на метод оптимизации, который изначально создавался для обработки за- просов (в частности, рекурсивных), записанных на языке логических баз данных Datalog (глава 23). Данная работа расширяет этот подход до условно-реляционных систем, утверждая на основе экспериментальных измерений, что он часто эффек- тивнее традиционных приемов оптимизации (заметьте, что запрос не обязательно должен быть рекурсивным, чтобы можно было применить к нему описанный

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

R := EX.ENAME WHERE EX.JOB = 'Clerk' AND EX.SAL >

AVG ( EY WHERE EY.DEPTt = EX.DEPTt, SAL ) ;

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

Tl := ( EX.DEPTl,

AVG ( EY WHERE EY.DEPTi = EX.DEPTl, SAL ) AS ASAL ) ;

T2 := EMP.ENAME WHERE EMP.JOB = 'Clerk' AND

EXISTS Tl ( EMP.DEPTi = Tl.DEPTl AND EMP.SALARY > Tl.ASAL ) ;

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

/* Первое вспомогательное отношение: */ /* Имена, отделы и зарплата клерков */ Tl := ( EMP.ENAME, EMP.DEPTi, EMP.SAL )

WHERE EMP.JOB = 'Clerk' ;

/* Второе вспомогательное отношение: */ /* Отделы, в которых работают клерки */ Т2 := Tl.DEPTl ;

/* Третье вспомогательное отношение: */ /* Отделы, в которых работают клерки, */ /* и средняя зарплата для каждого отдела */ ТЗ := ( T2.DEPTI,

AVG ( EMP WHERE EMP.DEPTi = T2.DEPTI, SAL ) AS ASAL ) ;

/* Отношение-результат */

R := Tl.ENAME WHERE EXISTS T3 ( Tl.DEPTl = T3.DEPTI AND

Tl.SAL > T3.ASAL ) ;

"Волшебство" состоит в том, чтобы определить, какие именно вспомогательные отношения требуется создать.

(См. [17.25], [17.26], а также список литературы в главе 23.)

17.25.Mumick I.S., Pirahesh Н. Implementation of Magic in Starburst // Proc. 1990 ACM SIGMOD Int. Conf. on Management Data. — Minneapolis, Minn., May, 1994.

17.26.Mumick I.S., Finkelstein S.J., Pirahesh H., Ramakrishnan R. Magic Conditions // ACM TODS. — March, 1996. — 21, № 1.

17.27.King J.J. QUIST: A System for Semantic Query Optimization in Relational Databases // Proc. 7th Intern. Conf. on Very Large Data Bases. — Cannes, France, September, 1981. Представлена идея семантической оптимизации (см. раздел 17.4). В статье описана экспериментальная система QUIST (QUery Improvement through Semantic Transformation — улучшение запросов посредством семантических преобразований), способная выполнять подобные преобразования.

17.28. Shenoy S.T., Ozsoyoglu Z.M. A System for Semantic Query Optimization // Proc. 1987 ACM SIGMOD Intern. Conf. on Management of Data. — San Francisco, Calif, May-June, 1987. Эта публикация расширяет работу Кинга (King) [17.27], представляя схему, которая динамически выбирает из потенциально очень большого множества ограничений целостности только те ограничения, которые будут полезны для обработки данного запроса. Рассматриваемые ограничения целостности разде- лены на два типа: ограничения причастности (например, "если партия деталей содержит более 300 единиц, то поставщик должен находиться в Лондоне") и ограничения подмножеств (например, "каждый поставщик, находящийся в Лондоне, должен поставлять хотя бы одну деталь"). Подобные ограничения используются для преобразования запросов посредством исключения избы- точных выборок и соединений и введения дополнительных выборок для ин- дексированных атрибутов. Случаи, когда результат запроса может быть полу- чен непосредственно из ограничений целостности, также эффективно обраба- тываются с помощью изложенного метода.

17.29.Siegel М., Sciore Е., Salveter S. A Method for Automatic Rule Derivation to Support Semantic Query Optimization // ACM TODS. — December, 1992. — 17, № 4. Как было показано в этой главе, семантическая оптимизация использует ограниче- ния целостности для преобразования запросов. Тем не менее существует несколько проблем, связанных с этой идеей.

• Как оптимизатор может узнать, какое преобразование будет эффективным (т.е. какое преобразование сделает запрос более эффективным)?

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

• Некоторые утверждения могут быть справедливы для определенных состояний базы данных (даже для большинства состояний), однако они не будут ограни- чениями целостности. Примером может служить утверждение вида EMP.AGE < 50 (возраст сотрудников— не более 50 лет), которое не является

ограничением целостности как таковым (поскольку могут быть сотрудники и старше 50 лет), но в данный момент в компании может действительно не быть сотрудников старше 50 лет.

В этой публикации описана архитектура системы, учитывающей перечисленные

проблемы.

17.30.Chakravarthy U.S., Grant J., Minker J. Logic-Based Approach to Semantic Query Optimization // ACM TODS. — June, 1990. — 15, № 2.

Цитата из вступления; "В нескольких предыдущих работах авторами была описана и доказана правильность метода семантической оптимизации запросов... В этой работе обобщаются основные результаты из предыдущих работ и особое внимание обращается на методы и их применимость к оптимизации реляционных запросов. Дополнительно в этой работе показано, каким образом описываемый метод подво- дит итоги и обобщает результаты более ранних работ в области семантической оп- тимизации. [Кроме того, отмечается] как методы семантической оптимизации за- просов могут быть распространены на рекурсивные запросы и ограничения цело- стности, содержащие дизъюнкции, отрицания и рекурсию".

17.31.Aho A.V., Sagiv Y., Ullman J.D. Efficient Optimization of a Class of Relational Expressions // ACM TODS. — December, 1979. — 4, № 4.

Класс реляционных выражений, упоминаемый в заголовке этой работы, содержит выражения, использующие только операции отбора по равенству (которые в этой статье называются выборками), проекции и естественного соединения. Этот класс выражений иногда называют SPJ-выражениями (от англ. "select", "projection", "join" — "выборка", "проекция", "соединение"). SPJ-выражения соответствуют за- просам в реляционном исчислении, в которых используются только сравнения на равенство, операции AND и кванторы EXISTS. В работе приводится определенный вид таблицы (табло — tableau), представляющей двумерный массив, в котором столбцы соответствуют атрибутам, а строки — условиям, в частности условиям принадлежности, которые гласят, что конкретный кортеж значений принадлежит конкретному отношению. Строки табло логически связываются посредством по- мещения общих символов в связанные строки. Например, табло

Si STATUS CITY Р| COLOR

al

bl al 'London' - S (поставщики)

Ы b2 - SP (поставки)

Ь2 'Red' - P (детали)

представляет запрос "Выбрать статус (al) поставщиков (Ы) в Лондоне, которые поставляют красные детали (Ь2)". Верхняя строка в табло представляет все атрибу- ты, которые используются в запросе, следующая строка — это "итоги" (она соот- ветствует кортежу-прототипу в запросе, определенном в исчислении, или финаль- ной проекции в алгебраическом запросе), а оставшиеся строки (как уже говори- лось) представляют условия принадлежности. В данном примере эти строки про- комментированы посредством указания относящихся к запросу отношений (точнее, переменных-отношений). Обратите внимание, что b используется для ссылок на связанные переменные, а а — для ссылки на свободную переменную. Итоговая строка содержит только переменные типа а.

Табло — это еще один вариант канонической формулировки для представления запросов (см. раздел 17.3), однако оно не является достаточно общим, чтобы пред- ставить все возможные реляционные запросы. (Фактически табло можно рассмат- ривать как синтаксическую разновидность языка Query-By-Example (QBE), хотя и менее мощную, чем непосредственно язык QBE.) В работе представлены алгорит- мы преобразования одного табло в другое, семантически эквивалентное табло, в котором количество строк уменьшено до минимума. Так как количество строк (не считая двух верхних специальных строк) на единицу больше количества соедине- ний в соответствующем SPJ-выражении, полученное табло представляет опти- мальную форму запроса, хотя и в очень специальном смысле (минимальное коли- чество соединений). (В приведенном выше примере количество соединений уже минимально, поэтому подобная оптимизация не дает никакого эффекта.) После этого полученное минимальное табло можно конвертировать обратно в другое представление для последующей дополнительной оптимизации. Идея минимизации количества соединений также применима к запросам, сформули- рованным в терминах представлений, которые построены на основе операции соеди- нения, в частности к запросам, сформулированным в терминах "универсальных от- ношений" (см. список литературы в конце главы 12). Например, предположим, что пользователю предложено представление V, определенное как соединение отноше- ний S и SP по атрибуту St, и пользователь вводит следующий запрос.

V { Р# }

Прямой алгоритм обработки представлений преобразует данный запрос в следующий.

( SP JOIN S ) { Pt }

Тем не менее, как было показано в разделе 17.4, приведенный ниже запрос дает тот же результат, хотя он вовсе не использует операции соединения (т.е. количество соединений в исходном запросе минимизировано). SP { Р| }

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

17.32.Sagiv Y., Yannakakis М. Equivalences Among Relational Expressions with the Union and Difference Operators // JACM. — October, 1980. — 27, № 4. В этой статье идеи работы [17.31] расширены так, чтобы их можно было приме- нять к запросам, использующим операции объединения и вычитания.

17.33.Levy A.Y., Mumick I.S., Sagiv Y. Query Optimization by Predicate Move-Around // Proc. 1979 ACM SIGMOD Int. Conf. on Very Large Data Bases. — Santiago, Chile, September, 1994.

17.34. Selinger P.G. et al. Access Path Selection in a Relational Database System // Proc. 1979 ACM SIGMOD Intern. Conf. on Management of Data. — Boston, Mass., May-June, 1979. В этой важной статье обсуждаются некоторые методы оптимизации, используемые в прототипе системы System R.

Замечание. Оптимизатор системы System R является предшественником оптимиза- тора СУБД DB2. В [17.35] дана более подробная информация, специфическая для СУБД DB2.

В системе System R запрос представляет собой SQL-выражение, поэтому состоит из набора блоков SELECT-FROM-WHERE (блоков запроса). Одни блоки могут быть вложе- ны в другие. Оптимизатор System R сначала определяет порядок, в котором будут вычисляться блоки запроса, а затем пытается снизить общую стоимость запроса по- средством выбора реализации с наименьшей стоимостью для каждого отдельного блока запроса. Обратите внимание, что данная стратегия (сначала — выбор порядка блоков, а затем — оптимизация отдельных блоков) означает, что конкретный план выполнения всего запроса никогда не рассматривается, и это приводит к "сужению пространства поиска" (см. замечания по этому поводу почти в конце раздела 17.3). Замечание. В случае вложенных блоков оптимизатор вычисляет блоки во вло- женном порядке, который указал пользователь, т.е. внутренний блок выполняет- ся первым. В [17.39]—[17.45] можно найти критику и дальнейшее обсуждение данной стратегии.

Для каждого блока запроса существует два случая, которые следует рассмотреть (первый из них можно рассматривать как частный случай второго).

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

2. Для блоков, в которых используются два или больше отношений, соединенных с помощью операции JOIN, возможно, с локальными выборками и (или) проек- циями отдельных отношений, оптимизатор, во-первых, трактует каждое от- дельное отношение, как случай I, и, во-вторых, определяет последовательность выполнения соединений. Эти две операции не являются независимыми одна от другой. Так, для отдельного отношения А может быть выбрана определенная стратегия доступа (например, на основе некоторого индекса), поскольку она по- зволяет получать кортежи из А в том порядке, который удобен для выполнения последующего соединения отношения А с другим отношением В.

Соединения реализуются с помощью метода сортировки-слияния, поиска по ин- дексу или метода последовательного просмотра. В работе особое значение автор придал тому, что при вычислении, например, вложенного соединения (A JOIN В) JOIN С необязательно полностью вычислять вложенное соединение A JOIN В пе- ред соединением его результата и отношения С. Наоборот, каждый кортеж соеди- нения A JOIN В сразу после вычисления передается процессу, соединяющему этот кортеж с кортежами из отношения С. Поэтому нет необходимости материализовать отношение A JOIN В полностью. (Эта идея конвейерной обработки кратко обсуж- далась в главе 3, раздел 3.2. См. также [17.18], [17.60].)

Эта работа включает и некоторые соображения о стоимости самого процесса опти- мизации. Для соединения двух отношений стоимость приблизительно равна стоимо- сти 5-20 операций выборки. При многократном выполнении оптимизированного за- проса это довольно незначительные расходы. (Отметим, что система System R, как и

СУБД DB2, является компилирующей, поэтому однажды оптимизированный запрос может выполняться сотни и даже тысячи раз.) В работе утверждается, что оптимиза- ция сложных запросов требует "всего нескольких тысяч байтов пространства для хранения и нескольких десятых долей секунды" на компьютере IBM System 370 Model 158. "Соединение восьми таблиц было оптимизировано за несколько секунд."

17.35.Cheng J.M., Loosley C.R., Shibamiya A., Worthington P.S. IBM DATABASE 2 Performance: Design, Implementation, and Tuning // IBM Sys. J. — 1984. — 23, № 2. Здесь содержится краткое описание тактики оптимизации в СУБД DB2 (в первой версии этой системы): методы преобразования запросов, обработка вложенных блоков запроса, методы соединения, выбор пути доступа и обработка индексов. Замечание. В эту работу также включен интересный материал о других аспектах работы СУБД DB2, влияющих на ее производительность.

17.36.Wong Е., Youssefi К. Decomposition— A Strategy foe Query Processing // ACM TODS. — September, 1976. — 1, № 3.

17.37. Youssefi K., Wong E. Query Processing in a Relational Database Management System // Proc.

5th Intern. Conf. on Very Large Data Bases. — Rio De Janeiro, Brazil, September, 1979. 17.38.Rowe L.A., Stonebraker M. The Commercial INGRES Epilogue // M. Stonebraker (ed.).

The INGRES Papers: The Anatomy of a Relational Database Management System. —

Reading, Mass.: Addison-Wesley, 1986.

Коммерческая СУБД Commercial INGRES — это программный продукт, получен- ный из прототипа University INGRES (Университетская система). Ниже перечисле- ны некоторые различия между оптимизаторами систем Commercial INGRES и University INGRES.

1. Университетский оптимизатор использует инкрементное планирование, т.е. оп- ределяет, что нужно сделать сначала, и делает это, затем определяет, что делать дальше, исходя из размера полученного промежуточного результата, и т.д. Коммерческий оптимизатор определяет полный план перед началом выполне- ния на основе оценок размеров промежуточных результатов.

2. Университетский оптимизатор обрабатывает запросы с двумя переменными (например, соединения) с помощью метода подстановки кортежей, обсуждав- шегося в разделе 17.6. Коммерческий оптимизатор поддерживает несколько мощных методов обработки подобных запросов, включая, в частности, метод сортировки-слияния, описанный в разделе 17.7.

3. Коммерческий оптимизатор поддерживает более сложный набор статистиче- ских показателей по сравнению с университетским оптимизатором.

4. Университетский оптимизатор выполняет инкрементное планирование (см. п. 1). Коммерческий оптимизатор выполняет более обширный поиск. Тем не ме- нее поиск прекращается, если на оптимизацию будет затрачено время, превы- шающее наилучшую оценку времени выполнения запроса (в противном случае выполнение оптимизации не даст никаких преимуществ).

5. Коммерческий оптимизатор рассматривает все возможные комбинации индек- сов, все возможные последовательности соединения и "все доступные методы выполнения соединения — сортировку-слияние, частичную сортировку- слияние, поиск по хеш-таблице, ISAM-поиск, поиск по В-дереву и метод после- довательного просмотра" (см. раздел 17.7).

17.39.Kim W. On Optimizing an SQL-Like Nested Query // ACM TODS. — September, 1982. —7, №3. См. комментарий к [17.43].

17.40.Kiessling W. On Semantic Reefs and Efficient Processing of Correlation Queries with Aggregates // Proc. 11th Intern. Conf. on Very Large Data Bases.— Stockholm, Sweden, August, 1985. См. комментарий к [17.43].

17.41. Ganski R.A., Wong H.K.T. Optimization of Nested SQL Queries Revisited // Proc. 1987 ACM SIGMOD Intern. Conf. on Management of Data. — San Francisko, Calif, May, 1987. См. комментарий к [17.43].

17.42.Giinter von Bultzingsloewen. Translating and Optimizing SQL Queries Having Aggregates // Proc. 13th Intern. Conf. on Very Large Data Bases. — Brighton, England, September, 1987. См. комментарий к [17.43].

17.43. Muralikrishna M. Improved Unnesting Algorithms for Join Aggregate SQL Queries // Proc. 18th Intern. Conf. on Very Large Data Bases. — Vancouver, Canada, August, 1992. Язык SQL позволяет создавать "вложенные подзапросы", т.е. блоки SELECT-FROM- WHERE, вложенные внутрь других подобных блоков. Эта конструкция порождает некоторые трудности при реализации. Рассмотрим следующий SQL-запрос ("Определить имена поставщиков детали с номером 'Р2'"), на который далее бу- дем ссылаться, как на запрос Q1. '

SELECT S.SNAME FROM S WHERE S.Sf IN

( SELECT SP.Sl FROM SP

WHERE SP.Pi = 'P2' ) ;

В системе System R [17.34] этот запрос будет реализован следующим образом. Сначала будет вычислен внутренний блок и создана временная таблица Т, со- держащая номера требуемых поставщиков. После этого кортеж за кортежем бу- дет проверена вся таблица S и для каждого выбранного из нее кортежа будет просматриваться таблица Т с целью определения, содержится ли в ней соответ- ствующий номер поставщика. Эта стратегия достаточно неэффективна (поскольку таблица Т не имеет индекса).

Теперь рассмотрим запрос Q2.

SELECT S.SNAME FROM S, SP WHERE S.Si = SP.Sl AND SP.PI = 'P2' ;

Легко установить, что он семантически идентичен предыдущему, но система System R проанализирует дополнительную стратегию реализации данного запроса. В частности, если таблицы S и SP окажутся физически сохраненными в последова- тельности номеров поставщиков, то система применит слияние, которое будет вы-

подняться весьма эффективно. Предположив, что два рассмотренных выше запро- са логически эквивалентны, но второй вариант более удобен с точки зрения эффек- тивности реализации, мы придем к выводу, что возможность преобразования за- просов, подобных Q1, в запросы, подобные Q2, требует более глубокого изучения. Эта возможность и является предметом обсуждения в [17.39]—[ 17.45]. Ким (Kim) [17.39] был первым, кто обратил внимание на эту проблему. В его рабо- те идентифицировано пять типов вложенных запросов и описаны соответствующие алгоритмы. В ней приводятся результаты экспериментов, которые показывают, что предложенные алгоритмы повышают производительность обработки вложенных запросов (обычно на один-два порядка).

Затем Кесслинг (Kiessling) [17.40] показал, что алгоритмы Кима работают не- корректно, если в списке атрибутов выборки вложенного запроса (на любом уровне) содержится обобщающая функция COUNT (алгоритм Кима некорректно обрабатывает случаи, когда аргументы функции COUNT являются пустыми отно- шениями). Термин "семантические рифы" в названии работы Кесслинга указы- вает на сложности, с которыми сталкивается пользователь при попытке получить корректные и непротиворечивые результаты подобных запросов. Более того, Кесслинг показал, что алгоритмы Кима усовершенствовать непросто (поскольку "похоже, не существует единого способа выполнить данное преобразование эф- фективно и корректно при любых условиях").

В работе Гански (Ganski) и Вонга (Wong) [17.41] описано решение проблемы, об- наруженной Кесслингом. Оно состоит в использовании в преобразованной версии запроса внешнего соединения (глава 18) вместо обычного внутреннего соединения. (По мнению современных авторов, это усовершенствование не вполне удовлетво- рительно, потому что оно вводит нежелательную зависимость упорядочения среди операторов в преобразованном запросе.) В данной работе описывается еще одна ошибка в оригинальной работе Кима, которая устраняется аналогичным способом. Тем не менее работа не лишена собственных ошибок. Одни связаны с проблемой строк-дубликатов (печально известные "семантические рифы" [17.40]), другие — с изъянами в реализации квантора EXISTS в языке SQL [18.6].

В [17.42] предпринята попытка сформулировать всю проблему на теоретической основе (основной проблемой предыдущих работ являлось то, что, как обнаружили различные авторы, поведение — семантическое и синтаксическое — вложений и обобщающих функций в языке SQL не совсем понятно). В ней также определены расширенные версии реляционного исчисления и реляционной алгебры (расширения касались действий над обобщениями и неопределенными значениями (NULLS)) и доказана эквивалентность расширенных формулировок (при этом ис- пользовался более элегантный по сравнению с ранее опубликованным метод дока- зательства). Затем семантика языка SQL представлена с помощью отображения конструкций этого языка на расширенное исчисление, определенное в работе. Тем не менее необходимо отметить следующее.

1. Обсуждаемый диалект языка SQL ближе к диалектам, используемым в коммер- ческих продуктах, по сравнению с диалектами языка SQL, которые использу- ются в [17.39]—[17.41]. Однако этот диалект еще не стал полностью общеприня- тым. Он не включает оператора UNION и прямой поддержки операторов типа

"=ALL" и ">ALL" (см. приложение А), а трактовка неизвестных истинных значе- ний отличается от трактовки, обусловленной стандартом языка SQL (на самом деле эта трактовка даже лучше). 2. В данной работе для "технического упрощения" не рассматриваются методы исключения кортежей-дубликатов. Но влияние такого пропуска не совсем ясно просматривается, исходя из того, что (как было показано ранее) наличие или отсутствие кортежей-дубликатов может значительно повлиять на корректность некоторых преобразований [5.6].

Наконец, в [17.43] утверждается, что в некоторых случаях оригинальные алгорит- мы Кима [17.39], несмотря на некорректность, могут быть эффективнее "общей стратегии", изложенной в [17.41]. Поэтому автор работы [17.43] предлагает аль- тернативный способ исправления ошибок в алгоритмах Кима. К тому же в этой ра- боте представлены некоторые улучшения рассматриваемых алгоритмов.

17.44. Baekgrand L., Mark L. Incremental Computation of Nested Relational Query Expressions // ACM TODS. — June, 1995. — 20, № 2.

Еще одна статья об оптимизации запросов, включающих подчиненные запросы в стиле языка SQL, в частности коррелированные запросы ("вложение", упо- мянутое в заголовке статьи, относится к вложенным подчиненным запросам в стиле языка SQL). Предлагаемая стратегия включает преобразование исходно- го запроса в эквивалентный запрос без вложений с последующей инкремент- ной оценкой полученной версии запроса без вложений. "Для поддержки перво- го этапа разработан очень краткий алгоритм преобразования типа "алгебра — алгебра"... В [преобразованном] выражении интенсивно используется оператор MINUS. Для реализации второго этапа предложен и проанализирован эффектив- ный алгоритм инкрементной оценки операций MINUS." Термин инкрементное вычисление означает, что для оценки данного запроса могут использоваться предварительно вычисленные результаты.

17.4S.Rao J„ Ross К.А. Using Invariants: A New Strategy for Correlated Queries // Proc. 1998 ACM SIGMOD Int. Conf. on Management of Data. — Seattle, Wash., June, 1998.

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

17.46.Warren D.H.D. Efficient Processing of Interactive Relational Database Queries Expressed in Logic // Proc. 7th Intern. Conf. on Very Large Data Bases. — Cannes, France, September, 1981.

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

• логические цели, которые являются основными компонентами запроса;

• логические переменные, связывающие эти компоненты;

■ порядок достижения логических целей, который является критическим момен- том с точки зрения реализации.

Из этого следует, что подобные языки весьма удобны в качестве базы для выпол- нения оптимизации. Действительно, такой язык можно рассматривать в качестве еще одного кандидата для внутреннего представления запроса, исходно сформули- рованного с помощью какого-либо другого языка (см. раздел 17.3). 17.47. Ioannidis Y.E., Wong Е. Query Optimization by Simulated Annealing // Proc. 1987 ACM SIGMOD Intern. Conf. on Management of Data. — San Francisco, Calif, May, 1987. С увеличением числа отношений, используемых в запросе, количество возможных пла- нов выполнения этого запроса растет экспоненциально. В традиционных коммерческих приложениях число отношений в запросе обычно невелико и, следовательно, количест- во потенциальных планов выполнения запроса ("пространство поиска") остается в ра- зумных пределах. Тем не менее в современных приложениях количество отношений в запросе может быть достаточно большим (примеры приводятся в главе 21). Более того, в приложениях нового типа ощущается необходимость "глобальной" (т.е. для многих запросов) оптимизации [17.49] и поддержки рекурсивных запросов. Эти функции также значительно увеличивают пространство поиска. Исчерпывающий поиск в таких усло- виях становится неэффективным, и возникает настоятельная необходимость в исполь- зовании методов сужения пространства поиска.

В публикации содержатся ссылки на более ранние работы по проблеме оптимиза- ции запросов с большим количеством отношений и многозапросной оптимизации. Однако в данной работе утверждается, что для оптимизации рекурсивных запросов не разработано ни одного алгоритма, после чего приводится алгоритм, который, как утверждают авторы, применим даже на пространствах поиска большого разме- ра. В частности, показано, как применять предложенный алгоритм в случае рекур- сивных запросов. Данный алгоритм (называемый "модельным отжигом", так как он моделирует процесс отжига, с помощью которого выращивают кристаллы, сна- чала прогревая жидкий раствор, а затем постепенно охлаждая его) является высо- коэффективным алгоритмом, который может успешно применяться для решения проблемы оптимизации в других контекстах. См. также [17.48].

17.48.Swami A., Gupta A. Optimization of Large Join Queries // Proc. 1988 ACM SIGMOD Intern. Conf. on Management of Data. — Chicago, 111., June, 1988. Общая проблема определения оптимального порядка выполнения соединений в за- просах, использующих большое количество отношений (что характерно для дедук- тивных баз данных, описываемых в главе 23), является комбинаторно сложной. В работе представлен сравнительный анализ нескольких алгоритмов, предназначен- ных для решения этой проблемы: возмущенный обход, псевдослучайная генерация данных, последовательные улучшения, последовательные эвристики и модельный отжиг [17.47] (названия методов добавляют немного "поэзии" в предмет обсужде- ния, который выглядит достаточно прозаично). Согласно результатам проведенно- го анализа алгоритм последовательных улучшений превосходит все остальные ал- горитмы, в частности алгоритм модельного отжига "сам по себе" нельзя использо- вать для больших запросов-соединений.

17.49.Sellis Т.К. Multiple-Query Optimization // ACM TODS. — March, 1988. — 13, № 1.

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

• Зарабатывает ли Майк больше $75 ООО?

• Зарабатывает ли Майк больше $60 ООО, и обладает ли он опытом работы ме- нее 5 лет?

• Зарабатывает ли Майк больше $45 ООО, и обладает ли он опытом работы ме- нее 3 лет?

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

В работе рассматриваются запросы, в которых используются только конъюнкции выборок и (или) соединения по эквивалентности, а также излагаются обнадежи- вающие результаты и предлагаются направления дальнейших исследований. 17.50.Lohman G.M. Grammar-Like Functional Rules for Representing Query Optimization Alternatives // Proc. 1988 ACM S1GMOD Intern. Conf. on Management of Data.— Chicago, 111., June, 1988.

В некоторых случаях реляционные оптимизаторы можно рассматривать как экс- пертные системы. Тем не менее исторически сложилось так, что правила, управ- ляющие процессом оптимизации, встраиваются непосредственно в процедурный код, а не записываются отдельно в декларативном виде. Вследствие этого расши- рение оптимизатора путем добавления новых приемов оптимизации ■— непростая задача. Будущие системы баз данных (глава 25), видимо, еще больше усугубят эту проблему, так как явно просматривается необходимость индивидуальной установ- ки дополнительных наборов правил, расширяющих возможности оптимизатора для поддержки определенных пользователем специальных типов данных. Поэтому разные исследователи предложили структурировать оптимизатор как экспертную систему с использованием явно выраженных декларативных правил. Однако эта идея страдает недостаточной производительностью. В частности, на любой стадии обработки запроса может применяться большое количество пра- вил, и поиск подходящего правила может потребовать достаточно сложных вы- числений. В этой работе представлен альтернативный подход (в данный момент используемый в прототипе системы Starburst [25.14], [25.17], [25.21], [25.22]), в котором правила определяются посредством продуктивных правил грамматики, подобной грамматикам формальных языков. Эти правила, называемые правила- ми STAR (STrategy Alternative Rules — правила альтернативной стратегии), по- зволяют осуществлять рекурсивное построение планов выполнения запросов из других планов и "операторов плана нижнего уровня" (low-level plan operator — LOLEPOP), которые являются базовыми операциями над отношениями, такими

как соединение, сортировка и т.п. Каждый из LOLEPOP-операторов имеет свои подвиды. Например, LOLEPOP-оператор соединения имеет подвиды сортировки- слияния, хеширования и т.д.

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

17.51.Nakano R. Translation with Optimization from Relational Calculus to Relational Algebra Having Aggregate Functions // ACM TODS. — December, 1990. — 15, № 4. Как показано в главе 7 (раздел 7.4), запросы на языке, базирующемся на реляци- онном исчислении, можно реализовать посредством преобразования исходного запроса в эквивалентное алгебраическое выражение с последующей оптимизаци- ей полученного алгебраического выражения, которая завершается выполнением этого оптимизированного выражения. Автор предлагает схему объединения пер- вого и второго этапов, т.е. преобразование данного выражения реляционного ис- числении непосредственно в оптимальное выражение в реляционной алгебре. Утверждается, что эта схема "более эффективна и перспективна... так как слож- ное алгебраическое выражение оптимизировать весьма непросто". В процессе оптимизации используются некоторые эвристические преобразования, постро- енные на основе уже имеющихся знаний об эквивалентности некоторых выраже- ний в исчислении и алгебре.

17.52. Whang K-Y., Krishnamurthy R. Query Optimization in a Memory-Resident Domain Relational Calculus Database System // ACM TODS. — March, 1990. — 15, № 1. Наиболее дорогой аспект в обработке запросов (в средах с достаточно большой основной памятью, как предполагается в данной работе) — вычисление логиче- ских выражений. Поэтому в подобных средах целью оптимизации является мини- мизация количества таких вычислений.

17.53.Freytag J.C., Goodman N. On the Translation of Relational Queries into Iterative Programs // ACM TODS. — March, 1989. — 14, № 1.

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

17.54.Ono К., Lohman G.M. Measuring the Complexity of Join Enumeration in Query Optimization // Proc. 16th Intern. Conf. on Very Large Data Bases.— Brisbane, Australia, August, 1990.

Так как операция соединения в своей основе является бинарной, оптимизатор должен разбить соединение N отношений (N > 2) на последовательность бинарных соедине- ний. Большинство оптимизаторов выполняет эту операцию в строго "вложенном" порядке. Оптимизаторы выбирают пару отношений, которые будут соединены пер- выми, после чего соединяют результат с третьим отношением и т.д. Другими слова- ми, выражение, подобное A JOIN В JOIN С JOIN D, будет трактоваться как (( D JOIN В ) JOIN С ) JOIN А, но ни в коем случае не как ( A JOIN D ) JOIN

( В JOIN С ). Более того, традиционные оптимизаторы разрабатываются так, чтобы вообще исключить выполнение операции декартова произведения. Показанные приемы можно трактовать как "сужение пространства поиска", поэтому для выбора последовательности соединения все еще нужны эвристические методы. В данной публикации также содержится описание других аспектов оптимизатора прототипа системы IBM Starburst [17.50], [25.14], [25.17], [25.21], [25.22]. Автор аргументирует это тем, что приведенные тактики в некоторых случаях неуместны, поэтому возникает необходимость в адаптируемом оптимизаторе, который можно заставить использовать разные тактики для различных запросов. Замечание. В отличие от типичных современных коммерческих программных про- дуктов, система Starburst способна трактовать выражение вида R.A = S.B + с как условие "соединения". Кроме того, она поддерживает свойство "транзитивной замкнутости предикатов" (см. раздел 17.4).

17.55. Vance В., Maier D. Rapid Bushy Join-Order Optimization with cartesian Products // Proc. 1996 ACM SIGMOD Int Conf, on Management of Data. — Montreal, Canada, June, 1996. Как сказано в комментарии к предыдущей ссылке, оптимизаторы стремятся "сократить пространство поиска" (помимо всего прочего) за счет исключения пла- нов выполнения запросов, в которых используется декартово произведение. В этой статье показано, что поиск во всем пространстве "допустим в большей степени, чем это признавалось прежде", а исключение декартова произведения не всегда желательно. Согласно утверждениям авторов, основными результатами этой ста- тьи являются полное отделение определения порядка соединения от анализа пре- дикатов и представление "новых технологий реализации" для решения проблемы определения порядка соединения.

17.56.Ioannidis Y.E., Ng R.T., Shim К., Sellis Т.К. Parametric Query Optimization // Proc. 18th Intern. Conf. on Very Large Data Bases. — Vancouver, Canada, August, 1992. Рассмотрим следующий запрос.

EMP WHERE SALARY > <зарплата>

Здесь параметр <зарплата> задается во время выполнения запроса. Предположим, что атрибут SALARY (зарплата) обладает индексом. Тогда получаем следующее.

• Если параметр <зарплата> имеет значение $10 ООО в месяц, то лучшим спосо- бом реализации запроса является индекс (так как можно предположить, что большинство сотрудников не удовлетворяют условию выборки).

• Если параметр <зарплата> имеет значение $1 ООО в месяц, то лучшим способом реализации запроса будет последовательный просмотр (так как можно предполо- жить, что практически все сотрудники будут удовлетворять условию выборки).

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

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

17.57.Kabra N., DeWitt D.J. Efficient Mid-Query Re-Optimization of Sub-Optimal Query Execution Plans // Proc. 1998 ACM SIGMOD Int. Conf. on Management of Data.— Seattle, Wash,, June, 1998.

17.58.Gray J. Parallel Database Systems 101 // Proc. 1995 ACM SIGMOD Int. Conf. on Management of Data. — San Jose, Calif., May, 1995.

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

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

• С разделением оперативной памяти. Сеть позволяет всем процессорам обра- щаться к общей оперативной памяти.

• С разделением дисковой памяти. Каждый процессор обладает собственной оперативной памятью, но сеть позволяет всем процессорам обращаться к об- щей дисковой (внешней) памяти.

• Без разделения. Каждый процессор обладает собственной оперативной и дисковой памятью, но сеть позволяет всем процессорам обмениваться данными между собой.

На практике обычно используется архитектура "без разделения", по крайней мере для больших систем (поскольку в двух других подходах при возрастании числа процессоров очень скоро начинают появляться конфликтные ситуации). Если говорить точнее, то архитектура "без разделения" обеспечивает линей- ное ускорение, т.е. повышение времени отклика в N раз при увеличении вы- числительной мощности аппаратного обеспечения в N раз, и линейное мас- штабирование (scalability), т.е. время отклика остается постоянным при уве- личении вычислительной мощности аппаратного обеспечения и объема данных в одинаковое количество раз.

Ниже представлены некоторые способы секционирования данных (data partitioning), т.е. разбиения отношения г на секции или подчиненные отношения и распределение этих секций между п различными процессорами.

• Секционирование диапазона (range partitioning). Отношение г делится на непе- ресекающиеся секции 1, 2,п на основе значений некоторого подмножества s атрибутов отношения г (концептуально отношение г отсортировано по под- множеству атрибутов s, а результат разделен на п секций равного размера). Секция i при этом соответствует процессору i. Данный подход очень удобен для запросов с выборками на основе условий равенства или соответствия диа- пазону для подмножества атрибутов отношения s.

• Хеш-секционирование (hash partitioning). Каждый кортеж t отношения г соот- ветствует процессору h(t), где h— некоторая хеш-функция. Этот метод пре- красно подходит для запросов с выборками на основе условий равенства для одного или нескольких хеш-атрибутов, а также для запросов с последователь- ным доступом ко всему отношению г.

• Круговое секционирование (round robin partitioning). Концептуально отношение г отсортировано некоторым образом, а i-й кортеж в отсортированном резуль- тате соответствует процессору с номером, вычисленным как результат деления i по модулю п. Этот подход прекрасно подходит для запросов с последователь- ным доступом ко всему отношению г.

Распараллеливание обработки можно применять для выполнения отдельной опе- рации (интраоперационное распараллеливание), для выполнения разных опера- ций внутри одного запроса (межоперационное или интразапросное распаралле- ливание) и для выполнения разных запросов (межзапросное распараллелива- ние). Эти варианты рассмотрены в учебных пособиях [17.4], [17.61]; некоторые методы и алгоритмы обсуждаются в [17.59], [17.60]. Следует отметить, что па- раллельная версия хеш-соединения (см. раздел 17.7) особенно эффективна и ши- роко используется на практике.

17.59.Bitton D., Boral Н., DeWitt D.J., Wilkinson К. Parallel Algorithms for the Execution of Relational Database Algorithms // ACM TODS. — September, 1983. — 8, № 3. Здесь описаны алгоритмы реализации операций сортировки, проекции, соединения, обобщения и обновления в многопроцессорных средах. Представлены также общие формулы стоимости, учитывающие операции ввода-вывода, загрузку процессора и обмен сообщениями. Эти формулы можно адаптировать к различным многопроцессорным архитектурам.

17.60.Hasan W., Motwani R. Optimization Algorithms for Exploiting the parallelism- Communication Tradeoff in Pipelined Parallelism // Proc. 20th Intern. Conf. on Very Large Data Bases. — Santiago, Chile, September, 1994.

17.61.Silberschatz A., Korth H.F., Sudarshan S. Database System Concepts (3rd edition). — New York, N.Y.: McGraw-Hill, 1997.

Это общий учебник по управлению базами данных, который включает целую главу о параллельных системах баз данных, а также главу о различных архитек- турах систем баз данных (централизованных, клиент/серверных, параллельных и распределенных).

Ответы к некоторым упражнениям

1. а— эквивалентны; 6— эквивалентны; в — эквивалентны; г— не эквивалентны; д — эквивалентны; е — не эквивалентны (эти выражения будут эквивалентными, если заменить операцию AND операцией OR); ж — не эквивалентны; з — не эквива- лентны; и — эквивалентны.

2. В демонстрационных целях покажем, что соединение является коммутативным. Соединение A JOIN В отношений А{Х, Y} и B{Y, Z} — это отношение с заголов- ком {X, Y, Z} и такими кортежами {Х:х, Y:y, Z:z}, что кортеж из значений х (для X) и у (для Y) должен присутствовать в отношении А, а кортеж из значений у (для Y) и z (для Z) должен присутствовать в отношении В. Это определение абсо- лютно симметрично относительно А и В. Поэтому A JOIN В тождественно В JOIN А. |

3. Для примера покажем ассоциативность операции объединения. Объединение A UNION В двух отношений А и В совместимых типов — это отношение с тем же заголовком, что А и В, и телом из всех кортежей t, принадлежащих отношению А, В или им обоим одновременно. Таким образом, если С — еще одно совместимое по типу отношение, то:

• объединение ( A UNION В ) UNION С —- это отношение с тем же заголовком и телом, состоящим из всех кортежей t, которые принадлежат отношению A UNION В, отношению С или им обоим одновременно;

• объединение A UNION ( В UNION С ) — это отношение с тем же заголовком и телом, состоящим из всех кортежей t, которые принадлежат отношению В UNION С, отношению А или им обоим одновременно.

Эти два отношения имеют одинаковые заголовки, а тело в каждом случае состоит из всех кортежей, принадлежащих хотя бы одному из отношений А, В или С. Поэто- му приведенные отношения тождественны. Щ

17.4. Покажем, что объединение распределяется по пересечению.

■ Еслис б A UNION ( В INTERSECT С ),TOt е КтиЬ е В INTERSECT С.

• Если t б А, то t € A UNION В и t е A UNION С, и, следовательно, t е ( А UNION В ) INTERSECT ( A UNION С ).

• Если t € В INTERSECT С, то t е В и t е С. Тогда t е ( A UNION В ) и t е (А UNION С ). Следовательно, t е ( A UNION В ) INTERSECT ( A UNION С ).

■ И обратно, еслиt е ( A UNION В ) INTERSECT ( A UNION С ),то t € (A UNION В ) и t б (A UNION С ). Из этого следует, что t е А или t принадлежит обоим отношениям, В и С. Следовательно, t е A UNION ( В INTERSECT С ). |

5. Покажем, что A UNION ( A INTERSECT В ) = А. Если t е А, то ясно, что t е A UNION ( A INTERSECT В j. И обратно, если t 6 A UNION ( A INTERSECT В ),TOt G ктиЬ принадлежит обоим отношениям, А и В. В любом случае получим, что t е А. |

6. Два случая с условиями уже рассмотрены в разделе 17.4. А случаи без условий достаточно просты. Покажем, что проекция не распределяется по разности на ос- нове следующего обратного примера. Пусть отношения A{X,Y} и B{X,Y} содержат

по одному кортежу, а именно — кортежи {Х:х, Y:y} и {Х:х, Y:z} соответственно (y?sz). Тогда (A MINUS В){Х} дает отношение, содержащее только кортеж {Х:х}, тогда как А{Х} MINUS В{Х} дает пустое отношение. |

17.9. Хороший набор подобных правил можно найти в [17.3]. 17.10.Хороший набор подобных правил можно найти в [17.3]. 17.11.

а) Выбрать сведения о поставщиках не из Лондона, не поставляющих деталь с но- мером 'Р2';

б) выбрать сведения о поставщиках из Парижа;

в) выбрать сведения о поставщиках не из Лондона, причем таких, для которых не су- ществует других поставщиков, поставляющих меньше различных типов деталей;

г) выбрать пустое множество сведений о поставщиках;

д) упрощение невозможно;

е) выбрать пустое множество сведений о парах поставщиков;

ж) выбрать пустое множество сведений о деталях;

з) выбрать сведения о таких поставщиках не из Парижа, которые поставляют наи- большее количество различных видов деталей.

Заметьте, что результаты выполнения некоторых запросов (если быть точным, то результаты запросов б, г, е и ж) можно получить непосредственно из ограничений целостности.

17.15. Исходя из особенностей методов обработки, настоящие максимальное и минималь- ное значения иногда являются в некотором роде фиктивными. Например, макси- мальным значением атрибута "employee name" (имя сотрудника) будет строка из букв Z (или букв Я), а ее минимальным значением — строка, составленная из пробелов. Если исходить из этих значений, то оценка, например, среднего расстояния между разными значениями атрибута в таблице может быть вычислена некорректно.

Глава

Отсутствующая информация