С точки зрения разработчиков информационных систем подход OOБД кажется очень заманчивым. Более того, на рынке программных продуктов управления базами данных сегодня существует около двух десятков коммерческих систем, которые более или менее успешно продаются (примерами таких систем являются O2 компании O2 Technology (www.o2tech.com), ObjectStore компании ObjectDesignInc., (www.odi.com), Objectivity/DB компании Objectivity, Inc., Versant компании VersantObjectTechnology (www.versant.com), ONTOSDB компании ONTOS, Inc., (www.ontos.com) и т.д.). Во всех этих системах поддерживается возможность распределенного хранения баз данных; имеется возможность написания приложений и/или методов объектов на одном или нескольких языках объектно-ориентированного программирования (как правило, в минимальный набор языков входят Си++ и Java); обеспечиваются удобные средства доступа к базам данных в среде Internet и т.д. Тем не менее, объектно-ориентированные системы оказались не в состоянии конкурировать с реляционными системами, поставляемыми ведущей шестеркой поставщиков программных средств управления базами данных.

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

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

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

Рис. 8.1. Ортогональность языков программирования и языков баз данных

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

Рис. 8.2. Сглаживание ортогональности средствами языка SQL

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

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

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