Microsoft не объявляет о планах перехода к использованию объектно-реляционного подхода. Пока развитие SQL-сервера происходит в рамках все большего внедрения в этот продукт компонентов, основанных на общей объектной архитектуре COM (ComponentObjectArchitecture - компонентная объектная архитектура). Основываясь на спецификациях OLE (ObjectLinkingandEmbedding - связывание и встраивание объектов), которые обеспечивают объектное представление различных сервисов операционной системы, а также развитие OLE - OLEDB, компания Microsoft пытается обеспечить пользователям общую объектную среду компонентов (включая данные, поддерживаемые SQL-сервером, которые могут разнообразным образом комбинироваться).

8.1.2. Насколько возможности серверов баз данных соответствуют потребностям приложений?

Как мы отмечали в вводной части этого раздела, реляционные базы данных обладают достоинствами и недостатками. Для некоторых приложений перевешивают достоинства, для других - недостатки. Можно сказать, что современные серверы реляционных баз данных (такие как Infor- mixOnLine версии 6 и выше, Oracle 7.x, SybaseV.11) обладают качествами, близкими к предельно возможным при использовании традиционной технологии. Еще возможны совершенствование оптимизации запросов, применение более эффективных методов распараллеливания, реализация более высоких уровней стандарта SQL и т.д., но принципиально при этом ничего не изменится. Реляционные СУБД могут управлять очень большими базами данных; эффективно используют возможности симметричных и массивно параллельных компьютеров; позволяют хранить в таблицах текстовую и графическую информацию произвольного размера; поддерживают достаточно развитое подмножество языка SQL; обеспечивают возможности частичного переноса логики приложений на сторону сервера за счет использования ограничений целостности, триггеров и хранимых процедур.

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

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

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

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

8.1.3. Преобразование реляционного подхода к организации баз данных в объектно-реляционный подход

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

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

Объектно-реляционный подход возник как эволюционная альтернатива революционному объектно-ориентированному подходу. Заметим, что термин "объектно-реляционные СУБД" вошел в обиход далеко не сразу, и даже сейчас системы соответствующего класса часто характеризуются другими терминами. Точкой отсчета можно считать опубликование в 1990 г. "Манифеста систем баз данных третьего поколения" (перевод на русский язык опубликован в журнале "СУБД", N 2, 1995 г.). В этом манифесте выдвигалась идея и обосновывались преимущества эволюционного развития возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения. Частично требования к системам следующего поколения включали просто необходимость реализации давно известных свойств, которые отсутствовали в большинстве текущих реляционных СУБД (ограничения целостности общего вида, триггеры, модификация БД через представления и т.д.). В число новых требований входили полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.