Объектно-реляционные системы баз данных

Автор классифицирует проблемы управления различными базами данных в соответствии с тем, являются ли их данные простыми или сложными, а также требуют ли они наличия средств запроса. Классификация сопровождается примерами проблем для кащдой из четырех выделенных категорий, предлагаются наиболее подходящие решения. Три категории содержат хорошо известные решения, для которых на рынке существует множество коммерческих продуктов. Четвертая категория - средства запросов к сложным данным - помечена новым видом СУБД, обьектно-реляционной СУБД.

Формулируются преимущества каждого класса СУБД в отношении приложений, указываются трудности, с которыми сталкивается каждая система, выполняя приложения из других категорий.

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

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

Четыре квадрата

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

Начнем с традиционного примера обработки деловых данных, ТР1[AnoN85], которому Совет по Обработке Транзакций (Transaction Processing Council) придал формальный статус ТРС-А. Говоря коротко, транзакция моделирует изъятие денег из банкомата или обналичивание чека. Она использует следующие четыре таблицы:

ЗАКАЗЧИК (номер_счета, баланс)
КАССИР (кассир_ид, наличные)
БАНК (баланс)
ИСТОРИЯ (номер_счета, сумма_чека)

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

ТР1 имеет три параметра (ЭТОТ_ЗАКАЗЧИК, ЭТОТ_КАССИР и ЭТОТ_ЧЕК) и осуществляет набор извлечений и обновлений данных в указанных таблицах, как описано в следующем фрагменте:

Select баланс from ЗАКАЗЧИК
 where номер_счета = ЭТОТ_ЗАКАЗЧИК
if баланс > ЭТОТ_ЧЕК {
 update ЗАКАЗЧИК
 set баланс = баланс - ЭТОТ_ЧЕК update КАССИР
 set наличные = наличные - ЭТОТ_ЧЕК
 where кассир_ид = ЭТОТ_КАССИР update БАНК
 set баланс = баланс - ЭТОТ_ЧЕК insert
 into ИСТОРИЯ
 values (3TOT_ЗАКАЗЧИК, ЭТОТ_ЧЕК) commit
}

Все данные ТР1 просты - они целиком принадлежат числовым типам. (В общем случае, данные приложения просты, если они состоят из цепочек символов, целых, чисел с плавающей точкой, данных типа "время" и типа "деньги". Иначе говоря, данные просты, если они могут быть описаны с использованием типов данных из SQL-89.) Кроме того, приложение ТР1 записано на SQL (другими словами, оно представляет собой набор запросов для выполнения их СУБД, поддерживающей SQL-89). Следовательно, TP1 - приложение, требующее наличия возможности запроса к простым данным.

Поставщики реляционных СУБД (таких как Oracle, Informix, Sybase, Ingres) предприняли значительные усилия по оптимизации своих систем для выполнения ТР1. Эти улучшения включают все или некоторые из приемов, перечисленных ниже:

Процедура базы данных (хранимая процедура) позволяет СУБД рассматривать всю ТР1 как единичную команду, снижая тем самым требование посылки СУБД каждой из 6 команд SQL по отдельности. Процедуры базы данных способны увеличить производительность ТР1 на 25 процентов и могут быть реализованы большинством поставщиков реляционных систем. Для поддержки большого количества пользователей, каждый из которых выполняет ТР1, поставщики реляционных СУБД обычно используют концепцию сервера, согласно которой все клиенты СУБД обслуживаются одним серверным процессором, обладающим возможностью осуществлять планпрование и управление памятью оптимальным образом. Блокирование малых объектов требуется для предотвращения "сталкивания" транзакций ТР1 на блокирующих запросах, с помощью этого снижается время ожидания. Поддержка концепции "собранных" вместе групп транзакций так, чтобы они могли быть зафиксированы одновременно, является способом уменьшения числа операций ввода/вывода, которые должны быть выполнены с журналами СУБД, и увеличения, таким образом, производительности. Ведение нескольких журналов - другой путь достижения того же эффекта. Логическое журналирование - техника для сокращения числа байт, выводимых в записи журнала для каждой транзакции, уменьшающая тем самым размер журнала ТР1 и увеличивающая производительность. И, наконец, увеличение производительности СУБД при выполнении последовательности очень простых команд, так называемых накладных расходов "на простой", - заключительный способ повышения эффективности.

Применяя эти средства, поставщики реляционных систем значительно увеличили производительность ТР1 на протяжении последних лет; всеми признано, что они предлагают блестящие решения для приложений, подобных ТР1. Некоторые приложения обработки деловых данных похожы на ТР1 и требуют наличия запросов к простым данным, попадая в левую верхнюю часть таблицы.

Вторая часть таблицы представляет простые данные, которым не требуется наличие запросов. Текстовый редактор, существующий на большинстве аппаратных платформ, предоставляет пользователю возможность считывать текстовый объект в основную память и затем редактировать его содержимое. После окончания редактирования объект записывается обратно на диск. Все известные автору текстовые редакторы реализованы на основе файловой системы. Файловые системы предоставляют поддержку текстовых строк, обрабатываемых большинством текстовых редакторов. Кроме того, поскольку текстовый редактор считывает весь объект в основную память, отсутствует необходимость в СУБД для выполнения SQL-запросов. Следовательно, файловая система - подходящее решение для приложений из левого нижнего квадрата таблицы. По мере усложнения текстовых объектов, двигающихся к так называемым гипертекстовым представлениям, файловые системы станут менее подходящими в качестве механизмов хранения, поскольку данные уже не будут простыми и такое приложение должно будет переместиться в другую часть таблицы.

Рассмотрим теперь пример сложных данных, необходимость запросов к которым отсутствует. Наш пример использует следующие таблицы:

ЗДАНИЕ (номер_этажа, план_расположения_этажа)
РАБОТНИК (имя, номер_этажа,
расположение_рабочего_места)

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

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

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

{прочитать план этажа для каждого этажа
прочитать расположение рабочего места
для каждого работника
уплотнить работников
записать расположение рабочих мест
для всех работников}

Для этого приложения характерно, что большинство данных не являются простыми. И расположение_рабочего_места и план_расположения_этажа - полигональные данные и не содержатся в типах данных SQL. Следовательно, нам следует классифицировать эти данные как сложные. Кроме того, приложение считывает все объекты из таблиц ЗДАНИЕ и РАБОТНИК в основную память и, после обработки, записывает их обратно. Как и в примере с текстовым редактором, не требуется поиска, и псевдокод не содержит предложений SQL.

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

Упростить написание этой программы пользователям помогает концепция постоянной (persistent) программы в универсальном языке программирования. Следовательно, структуры данных ЗДАНИЕ и РАБОТНИК могут быть сделаны постоянными для процедуры уплотнения, и пользователю необходимо написать лишь следующее:

уплотнить работников

В реализующих эту концепцию языках программирования предприняты соответствующие меры при чтении и записи объектов данных и конвертировании их в соответствующие форматы. Поставщики объектно-ориентированных СУБД (такие как Object Design, Ohjectivity, Versant, Servio, Ontologic) реализуют концепцию постоянности для языка С++. Они оптимизировали свои системы, используя некоторые или все следующие приемы:

Большинство поставщиков объектно-ориентированных СУБД реализуют систему типов, близкую к системе С++. Это позволяет описать расположение_рабочего_места и план_расположения_этажа как структуры С++. Кроме того, если в этих структурах присутствуют указатели, они перенастраиваются в процессе загрузки объектов в основную память, поэтому последовательный доступ процедуры уплотнения к данным может быть максимально эффективным. В действительности, кэш данных основной памяти находится в формате С++. И, наконец, кэш основной памяти находится в том же адресном пространстве, что и процедура уплотнения, что опять-таки увеличивает производительность доступа.

Таким образом, поставщики объектно-ориентированных СУБД сконцентрировались на методах, которые наилучшим образом будут поддерживать приложения из нижнего правого квадрата нашей таблицы. Как и поставщики реляционных СУБД, они сфокусировались на одной категории приложений и разработали средства, оптимальные для этой категории.

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

УЧАСТОК (участок_ид, расположение,
владелец, план_строений) ХРЕБЕТ
(имя, линия_хребта)

Это упрощенная версия базы данных, используемой в муниципалитете. Администрация хранит информацию об участках земли, находящихся под ее юрисдикцией, включая многоугольники для представления каждого участка, законного владельца, представленного как группа лиц, имеющих имена и почтовые адреса, и план_строений для любого сооружения на участке, представленный набором изображений. Помимо этого, многие города в Калифорнии заботятся о сохранении вида на их горные хребты из домов, расположенных в долинах. Поэтому существуют правила, касающиеся высоты сооружений, которые могут быть построены вблизи вершин горной гряды. Соответственно, во второй таблице хранятся имя и форма хребта для принимаемых во внимание горных цепей. Очевидно, что это приложение обрабатывает, в основном, сложные данные, поскольку большинство полей не содержит данные типов SQL-89.

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

Если требуется перепланировка участка ХХХХ, необходимо выполнить следующий запрос:

select владелец from участок where
расположение~ select расположение
from ЧАСТОК where участок_ид = XXXX

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

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

select участок_ид from УЧАСТОК, ХРЕБЕТ
where
 имя YYYY and раположение~ линия_хребта
 and максимальная_высота (план_строений) >
 высота (ближайшая_точка
 (линия_хребта.расположение))

Здесь первая фраза в условии ограничивает поиск рамками заданного хребта, тогда как вторая определяет участки, расположенные в пределах 1000 футов от линии соответствующего хребта. И наконец, третья фраза использует три определяемых пользователем функции для нахождения требуемых значений. Функция максимальная_высота рассматривает план_строений каждого участка и вычисляет максимальную высоту строений на этом участке, вторая функция, ближайшая_точка, вычисляет точку горной гряды, ближайшую к участку, рассматриваемому в запросе. Третья функция вычисляет затем высоту этой пространственной точки, и, в итоге, третья фраза определяет сооружения, более высокие, чем линия хребта.

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

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

Объектно-реляционный пример, приведенный выше, иллюстрирует несколько других концепций, определяющих объектно-реляционную СУБД. Во-первых, должно быть возможным определение новых базовых типов данных для расширения набора типов SQL-89. Например, в нашем простом приложении требуется тип многоугольник, и несложно представить приложения, для которых необходимы такие типы данных, как точка, линия, прямоугольник, окружность, эллипс, комплексные числа.

Далее, в примере требуется наличие определяемого пользователем оператора -, который имеет два операнда типа многоугольник и возвращает логическое значение. Рассмотрим первый запрос после выполнения внутреннего блока SQL.

select владелец from УЧАСТОК
where расположение~РАСПОЛОЖЕНИЕ_XXXX

Здесь результатом внутреннего блока является расположение участка ХХХХ, которое мы обозначили как РАСПОЛОЖЕНИЕ_ХХХХ. Хорошо известно, что этот запрос не может быть эффективно исполнен с использованием метода доступа В-дерева, поскольку одномерный метод доступа не может выполнять двухмерный поиск. Для исполнения этого запроса предпочтительнее использование многомерного метода доступа, например, дерево более высокой размерности, R-дерево или сеточный файл. Таким образом, для обеспечения эффективности использования этого запроса необходимо, чтобы СУБД допускала определяемые пользователем методы доступа. Более того, оптимизатор запросов и исполнительное ядро должны быть реализованы таким образом, чтобы приведенный выше запрос использовал определенный пользователем метод доступа в случае, если этот метод был определен в СУБД, применяемой в этом запросе.

Следующая объектно-реляционная концепция - возможность поддержки сложных объектов, представляющих собой наборы других объектов. И план строений и владелец в таблице УЧАСТОК являются такими сложными объектами. Если кому-то необходимы имена владельцев участка ХХХХ, он может записать это так:

select владелец.иия from УЧАСТОК
where участок_ид = XXXX

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

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

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

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

Рисунок 2.
Иерархия наследования.

Кроме того, объектно-реляционная СУБД должна поддерживать наследование функций. К примеру, рассмотрим функцию

размер (УЧАСТОК)

возвращающую площадь участка в квадратных футах. Даже если эта функция определена для таблицы УЧАСТОК, она должна быть унаследована тремя специальными типами участков, так чтобы вычислялась площадь участка любого типа. Таким образом, наследование должно поддерживаться и для данных, и для функций.

Последнее требование касается массивов данных. Например, обычные участки могут содержать сумму налога, состоящую из двух частей, одна из которых действует по апрель, а другая по декабрь. Следовательно, сумме_налога следует быть массивом типа int[2]. Далее, следует предоставить возможность определения суммы налога для участка XXXX следующим образом:

select сумма_налога [2] from ОБЫЧНЫЙ_УЧАСТОК
where участок_ид XXXX

Это требует типа массивов, поддерживаемого нотацией массивов SQL.

Для того чтобы, построить объектно-реляционную СУБД, необходимо расширить SQL2, добавив к нему поддержку всех 10 представленных концепций. Более точное определение того, что мы понимаем под SQL3, доступно сейчас в виде драфта.

Достоинства трех типов систем

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

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

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

Рисунок 1.
Классификация приложений СУБД.

Если мы попытаемся использовать реляционные СУБД для сложных данных (т.е. для приложений правой части таблицы), то, скорее всего, результат будет плохим. Как показано в [CATT92], реляционные СУБД в несколько раз медленнее, чем объектно-ориентированные СУБД для приложений из нижнего правого квадрата. Более того, несоответствие между системами типов SQL-89 и С++ делает крайне трудным написание таких приложений. В силу этого, разочарование и плохая производительность - типичные результаты попытки использования реляционных систем для приложений из нижнего правого угла.

Точно так же, если реляционная система используется для приложения, расположенного в правом верхнем углу, пользователь должен моделировать его сложные данные в терминах простых типов данных SQL-89. И это моделирование утомительно, неестественно и, как правило, в результате приводит к очень плохой производительности. Снова разочарование и недостаточная производительность - результат попытки использования реляционной системы для приложения из несоответствующей категории.

Рассмотрим теперь объектно-ориентированные СУБД, попадающие в нижний правый квадрат. Они не концентрируются на поддержке SQL или методах обработки транзакций, рассмотренных ранее и необходимых для максимизации производительности ТР1. В итоге, не только очень трудно реализовать ТР1 на объектно-ориентированных СУБД, но, кроме того, при реализации может быть получена очень низкая производительность. Как видим, типичным результатом попытки использования и объектно-ориентированной СУБД для приложения из несоответствующей категории являются разочарование и плохая производительность.

Далее, если объектно-ориентированные СУБД используются для приложения, расположенного в правом верхнем углу, отсутствие объектно-ориентированных конструкций в SQL сильно затруднит запись запросов этого приложения. Кроме того, поскольку отсутствует возможность автоматического выбора оптимизатором запросов корректного пути доступа, возможна крайне низкая производительность. И опять попытка использования объектно-ориентированной системы для приложения из несоответствующей категории принесет только разочарование и недостаточную производительность.

Обратимся к объектно-реляционным СУБД такого уровня, как Montage. Они не обеспечивают столь тесной связи с С++, какую предлагают поставщики объектно-ориентированных СУБД. В действительности, они не соответствуют приложениям, расположенным в нижнем правом квадрате таблицы. Кроме того, Montage не сфокусирован на производительности ТР1 и, в результате, может обеспечить меньшую производительность для этой категории приложений, чем реляционные системы, настроенные специально для проведения тестов.

Подведем итоги. Реляционные, объектно-ориентированные и объектно-реляционные СУБД оптимизированы для приложений из соответствующих категорий. Далее, любое приложение СУБД содержит компоненты из всех частей таблицы на Рисунке 1. Следовательно, оно представляет собой смесь простых и сложных данных с необходимостью поиска и без таковой. Любой пользователь должен выбрать один из доступных видов решений и, в итоге, должен решить, какая из частей Рисунка 1. содержит "центр тяжести" его приложения. Сейчас центр тяжести большинства приложений содержится в верхнем левом углу таблицы. Однако мы ожидаем вскоре его перемещения и далее поговорим об этом подробнее.

Что готовит будущее

Рынок реляционных СУБД оценивается в 4 миллиарда долларов в год, в то время как рынок объектноориентированных СУБД составляет приблизительно 30 миллионов долларов в год. Таким образом, только один процент рынка находится вне верхнего левого угла. Тем не менее, существуют два фактора, которые, как мы верим, значительно изменят это состояние в ближайшем будущем.

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

Традиционно проблемы обработки деловых данных считались сложными, поскольку достижение требуемой скорости обработки транзакций было затруднено. По сути дела, существовал выделенный фокус в левом верхнем квадрате. Однако высокоскоростные RISC-компьютеры, часто в многопроцессорной конфигурации с разделяемой памятью, делают вычисления предельно дешевыми. Кроме того, дисковые массивы а-ля RAID увеличивают количество дисковых накопителей, доступных для осуществления ввода/вывода, и увеличивают тем самым производительность дисковых систем. В результате, довольно просто выполнять сотни ТР1-транзакций в секунду. К 1995 году, по-видимому, будет возможным выполнение 1000 ТР1-транзакций на компьютере стоимостью 200000 долларов или менее. Поскольку большинство пользователей хотят выполнять 100 ТР1-транзакций в секунду или менее, наверное, будет возможно решать почти все проблемы обработки деловых данных на части 200000-долларового компьютера. Это должно уменьшить значимость левой стороны таблицы.

Таким образом, мы пришли к заключению, что центр активности СУБД сдвинется в правый верхний квадрат, где расположены объектно-ориентированные СУБД.

Подходы к построению обьектно-реляционных СУБД

Существует три наиболее вероятных способа построения объектно-реляционных СУБД. Рассмотрим по очереди каждый из них:

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

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

Теперь обратимся к архитектуре существующих реляционных СУБД. Все они содержат метаданные, описываемые набором таблиц, но они не имеют информации о типах, операторах, функциях или наследовании. Более того, существующие типы, операторы и функции SQL-89 являются жестковстроенными в ядро. Например, информация о том, что операторы целочисленного сравнения представляют собой множество {<, <=, =, ,=,<}, является жестко встроенной в парсер. Далее, в оптимизаторе жестко закодировано, что В-деревья являются наилучшим путем доступа к операндам типа символьная строка, целое число, число с плавающей точкой, как только оператор включен во множество {<, <=, =, , =}. Далее, исполнитель жестко связан с использованием машинных команд целочисленного сложения в случае суммирования двух целых констант. Следовательно, семантическая интерпретация каждой функции и оператора жестко встроена в исполнитель. И наконец, методы доступа к В-деревьям имеют обозначение < для символьных строк, целых и чисел с плавающей точкой.

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

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

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

Технологию надстройки сейчас использует компания Hewlett-Packard, чья Open ООВ реализована как надстройка над Allbase. Ожидается также, что 8-я версия Oracle будет включать, по крайней мере, некоторые собственные функции, реализованные как надстройка над 7-й версией Огас1е..Пользователям следует весьма осторожно относиться к производительности любого продукта, основанного на технологии надстройки.

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

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

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

Итоговая черта может быть подведена так: поставщики реляционных систем должны переписать свои продукты для движения из левого верхнего квадрата в правый верхний. Это потребует от них больших временных затрат и очень рискованно технически, вынуждая всех их создавать "надстройки", обеспечивающие нужную функциональность, но с очень плохой производительностью. Поставщики объектно-ориентированных систем должны реализовать много функций, чтобы переместиться из нижней части таблицы наверх. Кроме того, некоторые из их архитектурных решений были мотивированы созданием высокопроизводительного ядра для С++ и не подходят для основанной на SQL объектно-реляционной СУБД. Поэтому они также столкнутся с трудностями обеспечения работоспособности, безопасности, динамической расширяемости, присущих объектно-реляционным СУБД.

В то же время, уже сегодня доступны высокопроизводительные, безопасные и расширяемые объектно-реляционные СУБД, и в их числе - СУБД от Montage Software.

Литература

[ANON85] Anon et. al., "A Measure of Transaction Processing Power", Tandem Technical Report 85.1 Tandem Computers, Cupertino, Ca., August 1985.

[CATT92] Cattell, R. and Skeen, J., "Engineering Database Benchmark", АСМ TODS, July 1992.