Потребность в поддержании в объектно-ориентированной СУБД не только языка (или семейства языков) программирования ООБД, но и развитого языка запросов в настоящее время осознается практически всеми разработчиками. Система должна поддерживать легко осваиваемый интерфейс, прямо доступный конечному пользователю в интерактивном режиме. Один из подходов основывается на поддержании обходчиков. В этом случае конечный интерфейс обычно является графическим. На экране отображается схема (или подсхема) ООБД, и пользователь осуществляет доступ к объектам в навигационном стиле. По мнению Бансилона в этом случае разумно игнорировать принцип инкапсуляции объектов и предъявлять пользователю внутренность объектов. В большинстве существующих систем ООБД подобный интерфейс существует, но всем понятно, что навигационный язык запросов - это в некотором смысле шаг назад по сравнению с языками запросов даже реляционных систем. Ведутся активные поиски подходов к организации декларативных языков запросов к ООБД.
Беери отмечает существование трех подходов. Первый подход - языки, являющиеся объектно-ориентированными расширениями языков запросов реляционных систем. Наиболее распространены языки с синтаксисом, близким к известному языку SQL. Это связано, конечно, с общим признанием и чрезвычайно широким распространением этого языка. В частности, в своем Манифесте третьего поколения СУБД М. Стоунбрекер и его коллеги по комитету перспективных систем БД утверждают необходимость поддержания SQL-подобного интерфейса во всех СУБД следующего поколения.
Второй подход основывается на построении полного логического объектно-ориентированного исчисления. По поводу построения такого исчисления имеются теоретические работы, но законченный и практически реализованный язык запросов нам неизвестен. Видимо, к этому же направлению строго теоретически обоснованных языков запросов можно отнести и работу Леллани и Спиратоса, основанную на алгебраической теории категорий.
Наконец, третий подход основывается на применении дедуктивного подхода. В основном это отражает стремление разработчиков к сближению направлений дедуктивных и объектно-ориентированных БД. Примером простого дедуктивного объектно-ориентированного языка запросов может служить.
Независимо от применяемого для разработки языка запросов подхода перед разработчиками встает одна концептуальная проблема, решение которой не укладывается в традиционное русло объектно-ориентированного подхода. Понятно, что основой для формулирования запроса должен служить класс, представляющий в ООБД множество однотипных объектов. Но что может представлять собой результат запроса? Набор основных понятий объектно-ориентированного подхода не содержит подходящего к данному случаю понятия. Обычно из положения выходят, расширяя базовый набор концепций концепцией множества объектов и полагая, что результатом запроса является некоторое подмножество объектов-экземпляров класса. Это довольно ограничительный подход, поскольку автоматически исключает возможность наличия в языке запросов средств, аналогичных реляционному оператору соединения. В конце этого раздела мы коротко изложим собственные (в достаточной степени предварительные) соображения по этому поводу, но сначала кратко рассмотрим особенности нескольких конкретных декларативных языков запросов к ООБД.
В языке запросов объектно-ориентированной СУБД ORION полностью поддерживается принцип инкапсуляции объектов. В реализованном варианте языка запросы могут основываться только на одном классе (хотя в описывается подход к определению запроса на нескольких классах в стиле расширения семантики реляционного оператора соединения). Синтаксис языка ориентирован на SQL. Очень развит набор допустимых предикатов селекции. В частности, для атрибута, доменом которого является суперкласс, можно указать имя интересующего пользователя подкласса.
Язык запросов системы Iris находится в значительной степени под влиянием реляционной парадигмы. Даже название этого языка OSQL отражает его тесную связь с реляционным языком SQL. По сути дела, OSQL - это реляционный язык, рассчитанный на работу с ненормализованными отношениями. Естественно, при таком подходе в OSQL нарушается инкапсуляция объектов.
На наш взгляд, особый интерес представляет декларативный язык запросов системы O2 RELOOP. В общих словах, это декларативный язык запросов с SQL-ориентированным синтаксисом, основанный на специально разработанной для модели O2 алгебре объектов и значений. (Кстати, это не единственная работа в направлении построения алгебры для объектно-ориентированных моделей данных. На наш взгляд, особенно впечатляющим качеством языка RELOOP является естественность его построения в общем контексте модели O2. Запрос задается всегда на значении-множестве или списке. Если мы вспомним, что долговременному классу в O2 соответствует одноименное значение-множество, то тем самым можно определить запрос на любом хранимом классе. Результатом запроса может являться объект, значение-множество или значение-список. При этом элементами значений-множеств могут являться объекты (простая выборка), либо значения-кортежи с элементами-объектами разных классов (например). В совокупности эти особенности языка позволяют формулировать запросы над несколькими классами (специфическое соединение, порождающее не новые объекты, а кортежи из существующих объектов), а также употреблять вложенные подзапросы.
Теперь кратко остановимся на собственных предложениях. Суть их состоит в том, чтобы попытаться построить алгебру классов объектов, оставаясь в пределах базового набора концепций объектно-ориентированного подхода. Для этого достаточно, чтобы была возможность интерпретации результата выполнения алгебраической операции над классами в виде класса. Предлагаемый подход, аналогично модели O2, частично основывается на семантике включения, т.е. суперкласс как множество объектов включает все множества объектов подклассов, хотя некоторые операции не соответствуют этой семантике.
Идея нашего предложения основывается на следующем наблюдении. Среди операций реляционной алгебры имеются два вида операций: теоретико-множественные операции и операция селекции формируют из операндов-отношений отношение-результат с той же схемой; операции же проекции и соединения формируют отношение-результат со схемой, которая в общем случае не описывалась статически в составе схемы БД, т.е. в другой терминологии эти операции формируют не только значение, но и тип этого значения. И это не вызывает никакой двусмысленности, потому что схему отношения-результата (тип результата) можно определить в статике до выполнения операции.
Встает вопрос: почему бы не попытаться распространить подобный подход на классы объектов? Возможно, например, следующее неформальное определение алгебры классов объектов. Эта алгебра включает набор теоретико-множественных операций, а также операции декартова произведения, селекции и проекции. Теоретико-множественные операции определяются для "однотипных" классов, и класс результата помещается в решетку классов схемы БД в соответствии с семантикой включения. (Во время вычисления алгебраического выражения одновременно формируется соответствующий временный вариант решетки классов.) Операция декартова произведения формирует класс, включающий объединение наборов методов классов-операндов и являющийся их подклассом. Операция селекции формирует класс, являющийся подклассом класса-операнда. Операция проекции формирует класс, включающий указанное подмножество методов класса-операнда и являющийся его суперклассом. С использованием операций декартова произведения и проекции можно определить операцию соединения классов. Можно расширить алгебру операцией присваивания, и в этом случае класс, которому присваивается результат алгебраического выражения должен быть определен в схеме БД заранее.
5.1 Ограничения систем постоянного хранения.
Одна из целей современных ООБД - унификация языков программирования и баз данных в одном языке (например, С++ или Smalltalk). Эта цель вызвана текущим положением дел, когда прикладные программы пишутся на универсальном языке программирования (в основном, COBOL, FORTRAN, PL/I, С), а встроенные в приложение функции управления базой данных - на языке базы данных (например, SQL). Универсальный язык программирования и язык базы данных весьма различны по синтаксису и модели данных (структурам и типам данных), и необходимость изучать и использовать два разных языка при разработке приложений баз даннь~х часто рассматривается как главный недостаток. Поскольку C++ и Smalltalk уже включают средства для определения классов и их иерархии (т.е. определения данных), эти языки являются хорошей основой для унификации. Первый шаг, предпринятый производителями ранних ООБД, заключался в том, чтобы сделать постоянными кроссы и экземпляры кроссов, то есть поместить их во вторичную память и дать возможность доступа к ним даже после завершения программ, которые их определили и создали.
Большинство современных ООБД не делают существенного шага вперед к полным возможностям запросов по сравнению с РБД; они обладают простыми средствами извлечения постоянных объектов. Так или иначе, даже те ООБД, которые предоставляют постоянное хранилище для объектно-ориентированных языков, накладывают некоторые ограничения в определении постоянных данных. В частности, большинство систем по-разному трактуют постоянные и непостоянные данные (например, недопустимо в постоянном объекте наличие идентификатора временного объекта); поэтому пользователи должны явно объявлять, постоянный объект или нет. Кроме того, некоторые типы данных нельзя сделать постоянными, и поэтому они запрещаются.