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

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

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

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

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

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

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

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

По наше.му мнению, совершенно несоответствующий термин. Глава 25. Объектно-реляционные базы данных 1013

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

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

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. По-видимому, предпочтительнее была бы такая система, которая вначале выполняет операцию д. Тогда вызов р выполнялся бы только в том случае, когда результат выполнения операции сравнения q был бы равен true. В действительности некоторые классические эвристические алгоритмы преобразования выражений, которые всегда проверяют ограничение перед операцией соединения, не всегда пригодны для типов и операторов, определяемых пользователем (см. [25.7], [25.18]).

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

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

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

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

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

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