Для всех современных коммерческих реляционных СУБД основным языком доступа к базам данных является SQL. В 1989 г. появился первый международный стандарт этого языка, и большинство производителей СУБД объявляют свои системы соответствующими этому стандарту. Но стандарт 1989 г. был довольно ограниченным (например, в него не входили средства манипулирования схемой БД, динамический SQL и т.д.), а многие вошедшие в стандарт аспекты языка были специфицированы недостаточно строго. Поэтому разные реализации различаются в достаточно важных вопросах.
В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а конструкции SQL-92 специфицированы в стандарте более полно. Первой компанией, которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со своей седьмой версией (это произошло в 1992 г.). Теперь и все остальные компании выпускаютпродукты, соответствующие стандарту SQL-92.
Кроме того, производители стремятся добавить к своим продуктам качества, превышающие требования стандарта. Например, современные версии Oracle и Ingres содержат возможности определения триггеров (подробнее об этом см. ниже), в системе uniVerse компании VMark поддерживается расширенная ненормализованная реляционная модель и т.д. Другими словами, компании стремятся смотреть в будущее, предвидя требования следующего стандарта SQL (его условно называют SQL-3).

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

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

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

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

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

Как эффективно определить набор вспомогательных действий, вызываемых прямым действием пользователя? (т.е. алгоритм самого триггера).

Каким образом распознавать циклы в цепочке “действие-условие-действие-...” и что делать при возникновении таких циклов?

Реляционная модель не поддерживает время как особую переменную, хотя и располагает в SQL некоторыми функциями обработки данных типа date и time. Обычные БД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени t некоторого объекта приводит к недоступности состояния этого объекта в предыдущий момент времени. В большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа со стороны пользователя нет.
Конечно, можно явно ввести в хранимые отношения явный временной атрибут и поддерживать его значения на уровне приложений. Более того, в большинстве случаев так и поступают. Недаром в стандарте SQL появились специальные типы данных date и time. Но в таком подходе имеются несколько недостатков: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений; появляется дополнительная избыточность хранения (предыдущее состояние объекта данных хранится и в основной БД, и в журнале изменений); языки запросов реляционных СУБД не приспособлены для работы со временем.
Существует отдельное направление исследований и разработок в области темпоральных БД. В этой области исследуются вопросы моделирования данных, языки запросов, организация данных во внешней памяти и т.д. Основной тезис темпоральных систем состоит в том, что для любого объекта данных, созданного в момент времени t1 и закончившего жизненный цикл в момент времени t2, в БД сохраняются (и доступны пользователям) все его состояния во временном интервале [t1,t2]. (Частично мы решаем этот вопрос за счет жизненного цикла, архива и т.п.). Исследования и построения прототипов темпоральных СУБД обычно выполняются на основе некоторой реляционной СУБД. Как и в случае дедуктивных БД темпоральная СУБД - это надстройка над реляционной системой. Конечно, это не лучший способ реализации с точки зрения эффективности, но он прост и позволяет производить достаточно глубокие исследования.
Примером кардинального решения проблемы темпоральных БД может служить СУБД Postgres. Эта система была разработана М.Стоунбрекером для исследований и обучения студентов в университете г.Беркли.

Главными особенностями системы управления памятью в Postgres является, во-первых, то, что в ней не ведется обычная журнализация изменений базы данных. Во-вторых, система управления памятью поддерживает исторические данные. Запросы могут содержать временные характеристики интересующих объектов. Реализационно эти два аспекта связаны.
Основное решение состоит в том, что при модификациях кортежа изменения производятся не на месте его хранения, а заводится новая запись, куда помещаются измененные поля. Эта запись содержит, кроме того, данные, характеризующие транзакцию, производившую изменения (в том числе и время ее завершения), и подшивается в список к изменявшемуся кортежу. В системе поддерживается уникальная идентификация транзакций и имеется специальная таблица транзакций, хранящаяся в стабильной памяти. Таким образом, после сбоев просто не следует обращать внимание на хвостовые записи списков, относящиеся к незакончившемся транзакциям.
Отдельный компонент системы осуществляет архивизацию объектов базы данных. Он производит сборку разросшихся списков изменявшихся кортежей и записывает их в область архивного хранения. К этой области тоже могут адресоваться запросы, но уже только на чтение.
Соответствующие возможности работы с историческими данными заложены в язык Postquel. Возможна выборка информации, хранившейся в базе данных в указанное время, в указанном временном интервале и т.д. Кроме того, имеется возможность создавать версии отношений, и допускается их последующая модификация с учетом изменений основных вариантов.

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

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

Термин “системы следующего (или третьего) поколения” вошел в жизнь после опубликования группой известных специалистов в области БД “Манифеста систем баз данных третьего поколения”. Сторонники этого направления придерживаются принципа эволюционного развития возможностей СУБД без коренного изменения предыдущих подходов и с сохранением совместимости с системами предыдущего поколения.
Частично требования к системам следующего поколения означают просто необходимость реализации или усиления давно известных свойств, отсутствующих в большинстве текущих реляционных СУБД (ограничения целостности, триггеры, модификация БД через VIEW и т.д.). В число новых требований входит полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.
Одной из наиболее известных СУБД третьего поколения является система Postgres, а создатель этой системы М.Стоунбрекер, по всей видимости, является вдохновителем всего направления. В Postgres реализованы многие интересные средства: поддерживается темпоральная модель хранения и доступа к данным и в связи с этим абсолютно пересмотрен механизм учёта изменений, откатов транзакций и восстановления БД после сбоев; обеспечивается мощный механизм ограничений целостности; поддерживаются ненормализованные отношения.
Cистемы Postgres близки к объектно-ориентированным СУБД в том ,что в Postgres допускается хранение в полях отношений данных абстрактных, определяемых пользователями типов. Это обеспечивает возможность внедрения поведенческого аспекта в БД, т.е. решает ту же задачу, что и ООБД, но семантические возможности модели данных Postgres существенно слабее, чем у объектно-ориентированных моделей данных.
Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только условно, можно выделить три направления в области СУБД следующего поколения. Будем обозначать их именами наиболее характерных СУБД.

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

В общей классической постановке объектно-ориентированный подход базируется на концепциях:

• объекта и идентификатора объекта;
• атрибутов и методов;
• классов;
• иерархии и наследования классов.

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

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

Первой формализованной и общепризнанной моделью данных была реляционная модель Кодда. В этой модели, как и во всех следующих, выделялись три аспекта - структурный, целостный и манипуляционный. Структуры данных в реляционной модели основываются на плоских нормализованных отношениях, ограничения целостности выражаются с помощью средств логики первого порядка и, манипулирование данными осуществляется на основе реляционной алгебры или равносильного ей реляционного исчисления. Своим успехом реляционная модель данных во многом обязана тому, что опиралась на строгий математический аппарат теории множеств, отношений и логики первого порядка. Разработчики любой конкретной реляционной системы считали своим долгом показать соответствие своей конкретной модели данных общей реляционной модели, которая выступала в качестве меры “реляционности” системы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. Поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны Майер утверждает, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Классическим представителем объектно-ориентированного подхода есть СУБД O2 . В O2 поддерживаются объекты и значения. Объект - это пара (идентификатор, значение), причем объекты инкапсулированы, т.е. их значения доступны только через методы - процедуры, привязанные к объектам. Значения могут быть атомарными или структурными. Структурные значения строятся из значений или объектов, представленных своими идентификаторами, с помощью конструкторов множеств, кортежей и списков. Элементы структурных значений доступны с помощью предопределенных операций (примитивов). Возможны два вида организации данных: классы, экземплярами которых являются объекты, инкапсулирующие данные и поведение, и типы, экземплярами которых являются значения. Каждому классу сопоставляется тип, описывающий структуру экземпляров класса. Типы определяются рекурсивно на основе атомарных типов и ранее определенных типов и классов с применением конструкторов. Поведенческая сторона класса определяется набором методов. Объекты и значения могут быть именованными. С именованием объекта или значения связана долговременность его хранения: любые именованные объекты или значения долговременны; любые объект или значение, входящие как часть в другой именованный объект или значение, долговременны. С помощью специального указания, задаваемого при определении класса, можно добиться долговременности хранения любого объекта этого класса. В этом случае система автоматически порождает значение-множество, имя которого совпадает с именем класса. В этом множестве гарантированно содержатся все объекты данного класса. Метод - программный код, привязанный к конкретному классу и применимый к объектам этого класса. Определение метода в O2 производится в два этапа. Сначала объявляется сигнатура метода, т.е. его имя, класс, типы или классы аргументов и тип или класс результата. Методы могут быть публичными (доступными из объектов других классов) или приватными (доступными только внутри данного класса). На втором этапе определяется реализация класса на одном из языков программирования O2. В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.

Поддерживается предопределенный класс “Оbject”, являющийся корнем решетки классов; любой другой класс является неявным наследником класса “Object” и наследует предопределенные методы (“is_same”, “is_value_equal” и т.д.). Специфической особенностью модели O2 является возможность объявления дополнительных “исключительных” атрибутов и методов для именованных объектов. Это означает, что конкретный именованный объект-представитель класса может обладать типом, являющимся подтипом типа класса. C такими атрибутами не работают стандартные методы класса, но специально для именованного объекта могут быть определены дополнительные (или переопределены стандартные) методы, для которых дополнительные атрибуты уже доступны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному объекту, а к имени, за которым в разные моменты времени могут стоять разные объекты. Для реализации исключительных атрибутов и методов требуется развитие техники позднего связывания.

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

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

ООБД совпало с пиком популярности языка Smalltalk. Этот язык оказал большое влияние на разработку первых систем ООБД, и, в частности, использовался в качестве языка программирования ..

Трудности с эффективной практической реализацией языка Smalltalk побудили разработчиков систем ООБД к поиску альтернативных базовых языков. Известная близость объектно-ориентированного и функционального подходов к программированию позволяет успешно опираться на функциональные языки программирования. В частности, язык Лисп (Common Lisp) является основой проекта ORION. В этом проекте Лисп является и инструментальным языком, и базой объектно-ориентированного языка программирования в среде ORION.

Потребности в еще более эффективной реализации заставляют использовать в качестве основы объектно-ориентированного языка языки более низкого уровня. Например, в системе VBASE наряду со специально разработанным языком TDL, предназначенным для определения типов, используется объектно-ориентированное расширение языка Си - COP (C Object Processor). В уже упоминавшемся проекте O2 наряду с функциональным объектно-ориентированным языком программирования используются два объектно-ориентированных расширения языков Бейсик и Си. При этом, наибольшее распространение среди пользователей этой системы получил язык CO2, являющийся расширением языка Си.

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

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

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

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

Третий подход основывается на применении дедуктивного подхода. В основном это отражает стремление разработчиков к сближению направлений дедуктивных и объектно-ориентированных БД.

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

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

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

Особый интерес представляет декларативный язык запросов системы O2 RELOOP. Это декларативный язык запросов с SQL-ориентированным синтаксисом, основанный на специально разработанной для модели O2 алгебре объектов и значений. Особенно впечатляющим качеством языка RELOOP является естественность его построения в общем контексте модели O2. Запрос задается всегда на значении-множестве или списке. Результатом запроса может являться объект, значение-множество или значение-список. При этом элементами значений-множеств могут являться объекты (простая выборка), либо значения-кортежи с элементами-объектами разных классов. В совокупности эти особенности языка позволяют формулировать запросы над несколькими классами (специфическое соединение, порождающее не новые объекты, а кортежи из существующих объектов), а также употреблять вложенные подзапросы.

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

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

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

К чисто объектно-ориентированным СУБД относятся ORION и O2 .

Основными функциональными компонентами системы являются подсистемы управления памятью, объектами и транзакциями.

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

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

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

Проект O2 реализуется французской компанией Altair, образованной специально для целей проектирования и реализации объектно-ориентированной СУБД. Начало проекта датируется сентябрем 1986 г., и он был рассчитан на пять лет: три года на прототипирование и два года на разработку промышленного образца. Текущий прототип системы функционирует в режиме клиент/сервер в локальной сети рабочих станций SUN c соответствующим разделением функций между сервером и клиентами.

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

Наибольшую функциональную нагрузку несет компонент управления объектами. В число функций этой подсистемы входит:

• управление сложными объектами, включая создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем;
• управление передачей сообщений между объектами;
• управление транзакциями;
• управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);
• отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во внешней памяти до тех пор, пока достижим из какого-либо долговременно хранимого объекта);
• управление буферами оперативной памяти (аналогично ORION, представление объекта в оперативной памяти отличается от его представления на диске);
• управление кластеризацией объектов во внешней памяти;
• управление индексами.

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

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

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

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

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

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

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

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

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

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

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