25.4. Вопросы реализации

Одним из важных следствий надлежащей поддержки типов данных является то, что сторонние изготовители, а также сами изготовители СУБД могут встраивать и продавать отдельно пакеты "типов данных", которые могут эффективно включаться в СУБД. При­мерами таких пакетов могут служить пакеты для поддержки сложной обработки текстов, пакеты для обработки финансовых хронологических рядов данных, анализа геокосмиче­ских (картографических) данных и т.д. Такие пакеты называются по-разному, "data blades" ("пластины данных") в СУБД Informix, "data cartridges" ("кассеты данных") в СУБД Oracle, "relational extenders" ("реляционные расширители") в СУБД DB2 корпора­ции IBM⁴ и т.д. Мы же здесь будем использовать термин пакеты типов.

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

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

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

• В-третьих, компонент, который контролирует физическое хранение данных, дол­жен поддерживать новые структуры хранения (Q-деревья, R-деревья и т.д.), уже упоминавшиеся в разделе 25.1. Ему может также потребоваться поддержка воз­можности вводить новые структуры хранения и собственные методы доступа, предоставляемой достаточно подготовленным пользователям (см. [25.21], [25.33]).

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

По нашему мнению, совершенно несоответствующий термин.

Анализ запросов и проверка типа

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

1. Информация относительно типов и операторов, определяемых пользователем, а также, возможно, и относительно встроенных типов и операторов хранится в сис­темном каталоге. Поэтому такой каталог должен быть перепроектирован или по крайней мере расширен. Очевидно, что при установке нового пакета типов потре­буются многочисленные изменения в каталоге. (В терминах языка Tutorial D такое обновление каталога может быть выполнено неявно, как часть процесса выполне­ния соответствующих операторов определения — TYPE и OPERATOR.)

2. Сам компилятор должен быть переписан, чтобы иметь доступ к каталогу с целью получения необходимых данных о типах и операторах. Эти данные будут исполь­зоваться компилятором для проверки типа во время компиляции, как описано в главах 5, 8 и 19.

Оптимизация

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

■ Преобразование выражения ("переписывание запроса"). Как указывалось в гла­ве 17, обычный оптимизатор переписывает запросы, используя определенные за­коны преобразования. Исторически так сложилось, что все эти законы "зашиты" в оптимизатор, поскольку все типы и операторы встроены. В объектно-реляционной системе, напротив, соответствующие правила (по крайней мере для того, чтобы использовать типы и операторы, определяемые пользователем) должны храниться в каталоге. Поэтому требуется дополнительное расширение каталога, а также пе­реработка оптимизатора. Приведем несколько конкретных примеров.

а) Пусть имеется выражение NOT (QTY > 500). Хороший обычный оптимизатор преобразует его в выражение QTY < 500, поскольку в этом виде индекс QTY можно использовать, а в первоначальном — нет. По аналогичным причинам новому оптимизатору необходимо знать, когда один определенный пользовате- лем оператор является отрицанием другого.

б) Хорошему обычному оптимизатору известно, что, например, выражения QTY > 500 и 500 < QTY логически эквивалентны. Поэтому для нового оптими- затора также требуется информация, когда два определенных пользователем оператора являются противоположными в этом смысле.

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

• Селективность. Булево выражение, такое как QTY > 500, оптимизаторы обычно приблизительно оценивают на селективность, т.е. определяют процент кортежей, для которых оно будет иметь значение true. Для обычных оптими­заторов информация о селективности, опять же, может быть "зашита" в опти­мизатор. Для типов и операторов, определяемых пользователем, необходимо обеспечить способ передачи информации оптимизатору с помощью вызова некоторого определяемого пользователем кода, позволяющего оценить селек­тивность выражения.

• Стоимость формулы. Оптимизатору необходимо знать, какова стоимость выпол­нения данного оператора, определяемого пользователем. Например, пусть задано выражение р AND g, где р, скажем, — вызов оператора AREA, область определения которого представляет какой-то сложный многоугольник, ад— операция просто­го сравнения, такая как QTY > 500. По-видимому, предпочтительнее была бы та­кая система, которая вначале выполняет операцию д. Тогда вызов р выполнялся бы только в том случае, когда результат выполнения операции сравнения g был бы равен true. В действительности некоторые классические эвристические алгоритмы преобразования выражений, которые всегда проверяют ограничение перед опера­цией соединения, не всегда пригодны для типов и операторов, определяемых пользователем (см. [25.7], [25.18]).

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

Структуры хранения

Должно быть ясно, что для объектно-реляционных систем требуется больше спосо­бов, возможно, значительно больше способов хранения и доступа к данным на физиче­ском уровне по сравнению с тем, что обычно предоставляется традиционными SQL-системами. Перечислим некоторые из новых подходов.

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

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

■ Индексы по результатам выполнения оператора. Возможно, будет не слишком много пользы в построении индекса непосредственно по значениям данных типа POLYGON (многоугольник). Вероятнее всего, все, что удастся получить, — это та­кой индекс, в котором многоугольники будут упорядочены в соответствии с ихвнутренним кодированным представлением в виде строк байтов⁴. Однако в дейст­вительности более полезен был бы индекс, построенный на основании областей, охватываемых этими многоугольниками.

Замечание. В главе 21 мы назвали такие индексы функциональными.