Уважаемые читатели!
В последние несколько месяцев бурные дебаты относительно объектно-реляционных технологий и "универсальных серверов баз данных" несколько затихли. Это выражается и в изменении маркетинговой политики компаний-поставщиков, и в изменении тона в компьютерной прессе. Пришло время осмысления места объектно-реляционного подхода в мире объектных технологий. В статье Сета Граймса, краткий пересказ которой предлагается Вашему вниманию, предпринята попытка такого анализа. Кроме широты набора тем, затрагиваемых в статье, и соответствующей моим собственным представлениям общей ориентации, меня привлек список не слишком известных в России компаний, деятельность которых тем или иным образом затрагивает объектные технологии. Очень полезно познакомиться с ними поближе, посетив их Web-сайты.
Наконец, как обычно, замечу, что все упоминаемые в статье книги Вы можете заказать в электронном книжном магазине www.mistral.ru
С уважением, Сергей Кузнецов
Являются ли объектно-реляционные СУБД (ОРСУБД) "следующей большой волной"? При всем хорошем к ним отношении ответ автора статьи - "нет". Возможно, волны ОРСУБД будет биться о берег в течение нескольких следующих лет, но это не цунами. Ситуация объясняется природой объектно-реляционных моделей, существующих в контексте более широкой тенденции, которая опирается на распределенные объекты.
Технологию объектно-реляционных баз данных нельзя считать устоявшейся, и, более того, она далеко не так развита, как обещалось. Первая значимая коммерческая ОРСУБД Illustra появилась в 1993 г., а в 1997 г. несколько ведущих компаний-поставщиков СУБД стали предлагать свои оъектно-реляционные продукты, но во всех них остаются большие дыры. В каждой из этих ОРСУБД (Oracle8, IBM DB2 Universal Database и Informix Universal Server) объектные расширения реляционной модели реализуются неполно и разными способами. Доступно лишь немного средств проектирования и разработки, пригодных для использования в объектно-реляционных средах, и рынок приложений, основанных на этом подходе, развивается медленно. В результате поставщики ОРСУБД переосмысляют свои маркетинговые и технологические стратегии в свете навеянного Internet бума в распределенных объектных вычислениях, а поставщики чистых РСУБД (такие как Sybase и Microsoft) принимают решение обойтись поддержкой объектов на основе промежуточного программного обеспечения (middleware), не входящего в состав СУБД.
В статье кратко объясняется, как понятия объектно-реляционного подхода реализованы в разных продуктах, и описываются некоторые альтернативные подходы, обеспечивающие объектно-реляционное представление реляционных данных. После этого приводится обзор инструментальных средств ОРСУБД и некоторых ключевых прикладных областей.
РСУБД заменили предшествовавшие им иерархические и сетевые системы баз данных по причине своей гибкости и наличия интерфейсов, изолирующих код приложения от схем физического хранения. Объектно-реляционные системы основываются на знакомых реляционных таблицах, принципом проектирования является нормализация, методология основана на применении диаграмм "сущность-связь", используется язык SQL и интерфейсы ODBC и JDBC. Стремление выйти за рамки реляционных систем выражается в возможности определения пользовательских типов и функций, что позволяет полее естественно моделировать бизнес-объекты и инкапсулировать бизнес правила совместно с соответствующими данными. Набор расширенных базовых типов включает большие объекты, строчные типы и вложенные таблицы, типы коллекций и ссылочные указатели. Реализуются средства, совместимые со стандартом ANSI SQL-92 и грядущим стандартом SQL-3. Ключевые понятия объектно-реляционного подхода описаны в различных источниках, начиная с книги Майкла Стоунбрейкера (Michael Stonebraker, Object-Relational DBMSs: The Next Great Wave, Morgan Kaufmann, 1996).
Конечно, имеются альтернативные подходы к модернизации РСУБД. К одному из них относятся объектные СУБД (ОСУБД), хотя многие относятся к ним, как к элегантным средствам хранения данных, которые никогда не заменят РСУБД и ОРСУБД. Кроме того, средства распределенных объектных вычислений, основанные на серверах приложений и транзакций и поддерживающие собственные модели данных, могут снизить роль сервисов баз данных.
Какая из этих технологий приблизит нас к объектно-реляционным представлениям: ОРСУБД, ОСУБД или распределенные объекты? Ответ основывается на четырех ключевых аспектах принятия на рынке технологии баз данных: реализация, эффективность, инструментальные средства, приложения. Для начала рассмотрим текущие реализации объектно-реляционного компонента этого уравнения.
Oracle. Предложенная компанией сетевая вычислительная архитектура (Network Computing Architecture - NCA) производит неотразимое впечатление: распределенные объектные вычисления на основе объектных расширений CORBA на стороне клиента, сервер приложений, составляющий среднее звено и сервер баз данных. Имеет ли значение то, что к настоящему времени полностью реализовано только звено сервера приложений, что были допущены ошибки, такие как продукт Sedona, никогда не являвшийся образцом средств разработки приложений, или то, что предлагаемое решение дороже сетевого PC? Нет, поскольку контролирование около половины рынка РСУБД обеспечивает компании такой же простор, как если бы она владела 90 процентами рынка настольных операционных систем.
Подход Oracle к разработке "универсального сервера" в форме Oracle 7.3 состоял в том, чтобы объединить несколько разных серверов данных под одним названием. В Oracle8 эти различные серверы были преобразованы в картриджи ("картридж" - это термин, введенный компанией для обозначения модуля объектных расширений, подключаемого к данным NCA или звену приложений). В настоящее время Oracle предлагает пять картриджей данных: ConText, Image/VIR, Spatial, Time Series и Video. Что касается общей поддержки объектов, то Oracle следует тактике Microsoft: объявить, поставить ровно столько, сколько достаточно и надеяться, что никто не заметит, что королю несколько маловато новое платье; после всего этого запланировать поставку всего, что было обещано, но только после того, как этого потребует рынок.
Как отмечают в своей книге Дэвид Энсор и Ян Стивенсон (David Ensor and Ian Stevenson, Oracle8 Design Tips, O'Reilly, 1997), они не могли бы прямо сейчас рекомендовать использовать объектную поддержку Oracle8 в каких-либо реальных корпоративных приложениях. Эта поддержка не является полной; синтаксис сложен; могут применяться очень немногие распространенные инструментальные средства.
Кроме того, в Oracle8 объектно-реляционная модель реализована не полностью. Инкапсуляция возможна только при использовании для программирования методов языка PL/SQL. Вложенность таблиц ограничена одним уровнем, не поддерживается наследование. Функции могут быть перегруженными, но нет динамического полиморфизма. Вызов внешних процедур, которые могут быть написаны исключительно на языке Си, допускается из PL/SQL, но не из SQL. И конечно, вызовы внешних процедур намного более накладны, чем вызовы процедур, прикомпонованных к серверу, но Oracle не обеспечивает второй возможности по соображениям безопасности. Усовершенствования, включающие Java VM (Virtual Machine), ожидаются в версии 8.1, выпуск которой обещан в конце 1998 г.
Informix. История Маленького Принца Антуана де Сент-Экзюпери начинается с того, как удав проглотил слона. Подобно этому, компания Informix оттеснила Sybase с позиции основного конкурента Oracle, проглотив пионерскую ОРСУБД Illustra Майкла Стоунбрейкера. Казалось, что этот брак совершен на небесах: объединение новаторской архитектуры объектных расширений с самым быстрым и наиболее масштабируемым традиционным реляционным ядром.
Оптимизатор системы Illustra умеет работать с определенными пользователями типами и функциями, пространственными индексами в виде R-деревьев и обычными реляционными данными. В системе поддерживаются модули объектных расширений DataBlades, обеспечивающие управление полнотекстовыми, геопространственными, мутьтимедийными и другими данными. Основной продукт компании Online Dynamic Server (называемый теперь Informix-Dynamic Server 7.x) обладает наилучшими среди подобных систем возможностями распараллеливания на симметричных мультипроцессорах.
Технология Informix-Dynamic Server в настоящее время является лучшей объектно-реляционной технологией, хотя в текущем выпуске 9.13 отсутствуют такие важные возможности как репликация, множественное наследование, объектные расширения с использованием Java и надежная поддержка типов коллекций. Кроме того, трудно заставить работать портированный оптимизатор Illustra так же хорошо, как он работал в исходной системе. Эти проблемы должны быть устранены в выпуске 9.2, ожидаемом летом 1998 г. Ожидается также появление новых интересных интерфейсов запросов и сервисов, обеспечивающих транзакционное управление внешними данными.
IBM. IBM является единственной компанией, технология и ресурсы которой могут позволить бросить вызов доминирующей позиции Oracle на рынке серверов баз данных. Применение новой технологии, перенос системы на платформы Windows NT и UNIX-платформы других производителей и агрессивная маркетинговая политика относительно DB2 Universal Database V.5 позволяют IBM занять представительную позицию на рынке открытых СУБД.
DB2 Universal Database имеет репутацию надежной реализации ОРСУБД, которая в состоянии конкурировать с реализацией Informix. Единственно, что вызывает недовольство разработчиков,- это отсутствие возможности вызова SQL-операторов из определенных пользователями функций.
Строго говоря, Sybase не предлагает ОРСУБД. Стратегия компании, воплощенная в Adaptive Server и Adaptive Component Architecture, включает три составляющих. Во-первых, Adaptive Server будет объединять различные механизмы управления данными на основе унифицированного интерфейса и Java VM, встроенной в СУБД. В виде Java-классов будет реализован богатый набор типов данных. Java-объекты будут храниться в традиционных реляционных таблицах, но управляться Java VM; доступ к серверу будет обеспечиваться через JDBC. Этот подход предложен для принятия в качестве части стандарта SQL-3. Сервер, соответствующий этому стандарту, по существу, будет служить контейнером Java-объектов, обеспечивая объектно-реляционное представление в традиционных РСУБД. Предположительно, тот факт, что Adaptive Server является виртуальной ОРСУБД, будет прозрачен для средств разработки приложений.
Во-вторых, такие средства сторонних поставщиков как менеджер временных рядов компании FAME Information Services, Inc., Spatial Query Server компании Vision International, Image Engine компании Virage Inc., механизм полнотекстового поиска компании Verity Inc. будут обеспечивать расширенные типы данных. По утверждению Sybase, ее DirectConnect устанавливает мосты между Adaptive Server и десятками внешних хранилищ данных.
В-третьих, Sybase занимается не только управлением объектов баз данных, но также поддерживает Jaguar Component Transaction Server (CTS) как сервер промежуточного программного обеспечения, сочетающий функции монитора транзакций и сервера приложений. Однако отсутствует информация о том, каким образом Sybase собирается заставить работать эти три части стратегии вместе.
Аналогичным образом, на объектном представлении реляционных данных базируется подход Microsoft. Компания не объявляет планов создания "истинной" ОРСУБД. Промежуточной задачей является выпуск SQL Server 7.0, в котором ожидается объединение OLAP-сервер Plato с наиболее устойчивой доступной версией ядра сервера реляционных баз данных. Однако требуется большая работа, чтобы обеспечить продукту место в секторе рынка крупномасштабных корпоративных СУБД. Для достижения успеха, в частности, нужно иметь 64-разрядный вариант Windows NT с хорошей масштабруемостью в симметричных мультипроцессорных и кластерных архитектурах.
Нельзя сказать, что многие пользователи SQL Server и Windows NT считают эти продукты идеальными для управления мультимедийными данными, временными рядами или геопространственной информацией, хотя компания добилась существенного процесса в области Web. Попытки расширить компонентную объектную модель (Component Object Model - COM) для использования на неоднородных платформах, обеспечить возможность распределенных вычислений с применением Microsoft Transaction Server позволяют предполагать, что Microsoft ограничится возможностью вызова внешних пользовательских программ и не будет стараться обеспечивать истинную объектно-реляционную среду. Вместо этого будет продолжаться агитация к использованию API OLE DB для "универсального доступа к данным" с введением новых типов данных (например, текстовых).
Текущие и ожидаемые в ближайшем будущем результаты Microsoft, связанные с объектно-реляционными возможностями, не слишком значительны. В более отдаленной перспективе успех подхода объектно-реляционного представления данных может определяться широтой области распространения OLE DB, на что, в свою очередь будет влиять успешность внедрения JavaBeans, JDBC и Java со встроенным SQL.
Теоретически ОСУБД в состоянии моделировать объектно-реляционные (и чисто реляционные) базы данных и управлять ими. Зачем же тогда беспокоиться о более ограничительных моделях?
Объектные базы данных не вытеснили РСУБД в конце 80-х - начале 90-х, поскольку на ранней стадии существования они обеспечивали, по существу, лишь среду постоянного хранения для программ, написанных на языках Си++ и Smalltalk, а их API были ограничены привязкой к объектно-ориентированным языкам. Со временем ОСУБД "подросли", приобретя интерфейс SQL и средства разработки приложений. Но в течение того же времени производители РСУБД переписали свои системы для эффективного использования мультипроцессоров. В системах появились многопотоковость (multithreading) и распараллеливание выполнения запросов. Потеря соответствия (impedance mismatch) между множественными результатами реляционных запросов и ориентированным на записи процедурным программированием была компенсирована во многих средствах разработки, что снизило преимущества объектного моделирования данных в ОСУБД. Кроме того, в последних выпусках РСУБД и ОРСУБД в дополнение к обычным типам индексации, основанной на B-деревьях и хэшировании поддерживаются битовая индексация, R-деревья и другие виды индексов, играющие важную роль при организации хранилищ данных (datawarehousing) и управлении геопространственными данными. В этих СУБД теперь применяется оптимизация на основе оценок, а табличное пространство может быть разделено (фрагментировано) между устройствами и даже серверами.
Майкл Стоунбрейкер любит называть компанию Computer Associates "домом отставного программного обеспечения", возможно, по причине неудовольства тем, что его РСУБД Ingres стала относительно незаметной после ее приобретения этой компанией. В Ingres никогда не было реализовано собственное видение реляционной СУБД, расширенной объектными свойствами, хотя модули управления объектами и знаниями поставлялись в начале 90-х, и это представляло первую попытку приближения к ОРСУБД. В частности, модуль управления объектами дает пользователям возможность расширения Ingres определяемыми ими типами и методами, хотя сложность Си-кода, требуемого для реализации, делает их практически неиспользуемыми. Но на самом деле характеристика CA, данная Соунбракером, неверна. Продукты Unicenter-TNG и ОСУБД Jasmine далеки от пенсионного возраста.
Другой широко обсуждаемой компанией является Ardent Software, Inc., недавно образованная путем слияния компаний O2 Technology, Unidata и Vmark. Система Unidata относится к классу РСУБД, поддерживающих ненормализованную реляционную модель данных (в частности, допускаются вложенные таблицы). Поддержка аналогичных возможностях в ОРСУБД за счет механизмов строчных типов или вложенных таблиц обеспечивает существенно большую масштабируемость. Кроме того, Ardent предлагает РСУБД UniVerse, близкую по подходу к Unidata, и ОСУБД O2. Вполне понятно, что Unidata и UniVerse не справятся с ОРСУБД, но система O2, рекламируемая на рынке как "универсальный объектный сервер", - это достаточно впечатляющий продукт.
Продукт Cashe компании InterSystems Corp. представляет еще один пример постреляционной СУБД (ПРСУБД). СУБД Cashe выглядит и функционирует подобно реляционной системе, но основана на многомерной моделе данных, оптимизированной для обработки сложных транзакций.
Несмотря на такие достоинства ПРСУБД как сильная технология, стандартизованные интерфейсы, совместимость с реляционным подходом и наличие ряда впечатляющих приложений, сомнительно, чтобы эти системы смогли вытеснить РСУБД или ОРСУБД. Функциональных возможностей ПРСУБД недостаточно, чтобы потеснить занимающие твердые позиции Oracle, IBM и Informix. Распределенные объекты представляют более жизненную альтернативу.
Как говорилось выше, ориентированные на приложения распределенные объектные вычислительные системы потенциально могут понизить значимость сервисов баз данных. Это утверждение опирается на доминирующую роль объектно-ориентированных языков программирования и методологий, а также на наличие визуальных объектно-ориентированных инструментальных средств. На этот подход делают ставку компании Sybase и Microsoft, а Oracle и IBM ограничивают инвестирование своих ОРСУБД. (На самом деле, объектные расширения Oracle наиболее полно реализованы в среднем звене сервера приложений.) И конечно, не случайно все четыре компании являются ведущими поставщиками инструментальных программных средств.
Главным аргументом в пользу ОРСУБД и ОСУБД является их эффективность. Как писали Джим Грей и Андреас Рейтер в своей классической книге (Jim Gray and Andreas Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993), накладные расходы при межпроцессных взаимодействиях даже в самых простых случаях в тысячи раз превышают расходы на прямой доступ к основной памяти. Если переформулировать этот факт в терминах объектов, то операция может быть послана объекту, предположительно управляемому сервером объектов где-то в сети (подход ORB - Object Request Broker), или же объект может быть перемещен в приложение и обработан локально (подход баз данных). С каждым из этих подходов связаны свои проблемы эффективности, связанные с перемещением объекта "здесь" или посылкой операции для выполнения "там". Решения об использовании объектной базы дынных или ORB не являются взаимно исключающими. Объектный сервер в среде ORB может в действительности использовать объектную базу данных для хранения управляемых им объектов. В придачу к этому, следует учитывать, что коммуникационные расходы, необходимые для синхронизации серверов, возрастают квадратично при росте числа серверов.
Итак, соображения эффективности работают в пользу ОРСУБД. Но базы данных существуют не сами по себе; они должны поддерживать прикладные программы. Поэтому жизнеспособность объектно-реляционного подхода будет определяться наличием инструментальных средств и приложений.
С точки зрения инструментальных средств и приложений большее значение имеют объектно-реляционные модели и интерфейсы, а не детали реализации. Средства проектирования баз данных и разработки программного обеспечения играют ключевую роль в облегчении работы администраторов баз данных и программистов с объектно-реляционными моделями.
Проектирование баз данных. Несколько компаний сделало шаги по направлению к объектно-реляционному подходу. Компания Platinum Technology, Inc. недавно поглотила компанию Logic Works и теперь предлагает следство OR Compass. Компания Silverrun Technologies, Inc. распространяет Universal Modeler. Компания Visio Corp. поглотила компанию InfoModelers и продает средство InfoModeler. Другие инструментальные средства, среди которых Object Database Designer компании Oracle и Retional Rose компании Retional Software Corp., позволяют создавать объектно-реляционные схемы. Многие производители поддерживают только реляционные части Oracle8 и DB2, предпочитая дождаться развития рынка.
По поводу имеющихся методологий и инструментальных средств можно сделать два критических замечания. Во-первых, в большинстве средств проектирования баз данных не используются должным образом бизнес-процессы и правила, из-за чего, вероятно, потребуется переход к Unified Modeling Language, разработанному Object Management Group. Во-вторых, ни один из существующих инструментов не помогает пользователям решить, каким образом реализовывать бизнес-правила - как определяемые пользователями функции в ОРСУБД или внешним образом в объектах приложения.
Разработка приложений. Традиционная разработка приложений баз данных базируется на языках четвертого поколения (4GL), встроенном SQL или интерфейсах уровня вызова типа ODBC или JDBC, API промежуточного программного обеспечения, а также на абстрактных объектах данных, основанных на низкоуровневых интерфейсах. История объектно-реляционных средств разработки подобна истории серверов - частичные успехи и обещаемые достижения.
Продукт JavaBlend компании Sun Microsystems, находящийся в состоянии бета-тестирования и ожидаемый к выпуску в июне 1998 г., отображает объекты и методы запросов Java на объекты базы данных и SQL с использованием JDBC, а также создает Java-классы для реляционных таблиц. По утверждению компании, программный интерфейс JavaBlend был специально спроектирован для соответствия стандарту ODMG для объектно-реляционных отображений и объектных баз данных. Ожидается, что JavaBlend будет даже автоматически выводить отношения наследования между таблицами и создавать их для подклассов Java. Во втором выпуске продукта обещается наличие отображения на объектно-реляционные расширения.
Вот фрагмент JavaBlend-кода, показывающий, как транзакции и объекты базы данных отображаются на конструкции Java:
Transaction t = Transaction.create();
Customer c = Customer.selectElement("custID=123");
SalesRep s = c.rep; /* follow foreign key */
c.address = newAddress;
s.sales = s.sales + thisOrder;
t.commit(); /* write c & s back to database */
Подход JavaBlend поход на те, которые применяют компании Ardent Software в продукте Java Relational Binding (JRB), где Java-классы отображаются в реляционные таблицы посредством JDBC, и Informix в продукте Data Director for Java (DDJ), позволяющем создавать Java-приложения с использованием объектно-реляционных данных. Имеется несколько реализационных различий: в DDJ для взаимодействия клиента с сервером приложений используется Java RMI (Remote Method Invocation), в то время как в JavaBlend будет применяться OQL. Похоже, что поддержка управления транзакциями и запросами в JavaBlend будет более скромной, чем в DDJ. Кроме того, JRB и DDJ доступны уже сейчас.
Программное обеспечение Formida Fire компании Formida Software Corp., включающее Universal Development Environment (UDE), является единственным известным автору пакетом средств разработки приложений, поставляемый независимым производителем и способным работать с ОРСУБД.
Пользователи будут переходить к ОРСУБД, если их собственным или разработанным сторонними поставщиками приложениям потребуются объектные расширения. ОРСУБД приняты в ряде важных прикладных областей, но в их число не входят области, обеспечивающие хлеб для РСУБД.
Success Story. Области, в которых у ОРСУБД дела обстоят хорошо, включают управление графической, аудио, видео, текстовой информацией, временными рядами, геопростраственными данными, а также Web-приложения. Для управления медиа-информацией требуется применение идейно простых методов к неструктурированным данным. В отличие от этого, управление временными рядами и геопространственными данными требует наличия относительно сложных структур данных и применения аналитических методов. Web-приложения занимают промежуточную позицию, основываясь на неструктурированных данных для представления шаблонов динамических страниц и усложненных методах управления переменными, логикой страниц и запросами к базам данных. Принятие для использования расширяемого языка разметки (eXtensible Markup Language - XML) поможет добиться большей структуризации шаблонов Web-страниц и других документов.
До появления ОРСУБД управление временными рядами, текстовыми и геопространственными данными обычно проиводилось с помощью специализированного программного обеспечения с нестандартизованными интерфейсами и языками запросов. Медиа-данные (и часто тексты) хранились в файловых системах и индексировались с помощью специальных средств. ОРСУБД привнесли во все эти области возможности, которые дают возможность манипулировать данными с помощью стандартного языка, интегирующего запросы к обычным и экзотическим данным.
OLAP и хранилища данных (datawarehousing). OLAP (On-Line Analitycal Processing) - это интерактивный, исследовательский анализ данных, основанный на выделении нужных слоев многомерных кубов и агрегировании по измерениям. Развитые OLAP-системы позволяют связывать индивидуальные значения с агрегатами и с другими значениями. Для этих систем важно то, что можно делать с данными, а не как они хранятся. Можно хранить кубы в специализированной многомерной базе данных или с помощью РСУБД. В последнем случае многомерное представление достигается с помощью реляционных OLAP-систем (ROLAP).
У каждого поставщика ОРСУБД имеются OLAP-средства. Компания IBM интегрирует продукт Essbase компании Arbor Software Corp. с DB2 и обеспечивает использование своего продукта Visual Warehouse в продуктах компании Cognos, Inc.. Informix продает средство Metacube ROLAP, которое основано на технологии, полученной от Stanford Technology Group. Oracle предлагает Express Server (купленный у компании Information Resources, Inc., в просторечии IRI Software), история которого восходит к 1970 г. Однако перспективы встраивания функций OLAP в ОРСУБД кажутся отдаленными. Расширения собственных аналитических возможностей СУБД выглядят, в лучшем случае, неоднородными. К хорошим примерам относятся продукты SQL Expander для DB2 компании The Fillmore Group, Inc., обеспечивающий ряд аналитических функций для обычных данных DB2, и S-Plus DataBlade компании Mathsoft Inc., предоставляющий возможности статистического анализа, моделирования и визуализации.
Возможно, поставщики не имеют стимула, полагая, что их текущие реляционные и многомерные СУБД хорошо обслуживают приложения. Но имеются и технические проблемы, такие как написание эффективного кода для управления большими разреженными многомерными массивамм данных с множественными иерархиями и потребность в единообразных, быстрых, не ограниченных одним измерением вычислениях. Аналогичные трудности сохраняются для хранилищ данных, которые обычно основываются на многомерных моделях данных, реализуемых звездообразными схемами (или вариантами "снежинка" и "создездие"). В реализациях используются битовые индексы, доступные в традиционных СУБД. (Джерри Додж и Тим Горман (Gary Dorge and Tim Gorman, Oracle8 Data Warehousing, John Wiley & Sons, 1998) утверждают, что они осветили все возможности Oracle7 и Oracle8, но во всей книге не разу не упомянута поддержка объектов в Oracle8.)
Планирование ресурсов предприятия (Enterprise Resource Planning - ERP) требует наличия нескольких приложений, критичных для крупномасштабных организаций: финансы, человеческие ресурсы, управление системой поставок и т.д. На рынке ERP доминирует всего несколько поставщиков, в число которых входят SAP, Baan, PeopleSoft и Oracle. Их программное обеспечение обычно строится поверх РСУБД.
ERP-приложения выполняют много транзакционных функций, которые базируются на нормализации для гарантирования высокого уровня параллельности и эффективности за счет минимизации числа обращений к дискам и блокировок. Другой важной областью применения РСУБД являются приложения, не относящиеся к категории ERP: резервирование, управление продажами, обслуживание заказчиков и т.д. Не слышно, чтобы поставщики таких приложений собирались перейти к использованию ОРСУБД. Продукт Universal Database Enabler компании Formida дает возможность использования объектов R/3 в приложениях Formida, но из этого не следует, что SAP применяет средства ОРСУБД. Единственной новостью, вызывающей вопросы, является участие компании Baan в разработке JavaBlend. Заключение автора: современные ОРСУБД могут являться универсальными серверами, но они далеки от универсального использования. Они могут управлять новыми типами данных, но поставщики корпоративных приложений вполне удовлетворены набором типов и ограниченными возможностями расширений РСУБД.
Распределенные объектные вычисления, развитие которых стимулировалось взрывообразным ростом Internet, являются превалирующей тенденцией середины и конца 90-х: настоящая следующая большая волна. Сегодняшние сражения происходят не в связи с настольными операционными системами или офисным программным обеспечением (до следующей смены парадигмы лидером в этих областях останется Microsoft), не в связи с браузерами или СУБД. Реальные баталии ведутся по поводу объектных моделей: COM против JavaBeans против CORBA/IIOP (если еще не слишком поздно).
Потенциально ОРСУБД могут играть роль центра в распределенной сети объектов. При наличии в ОРСУБД надежного управления транзакциями, масштабируемости, интерфейсов CORBA, COM, Java RMI и Beans, эти системы могут служить естественным выбором для поддержки брокеров объектных заявок и управления неоднородными распределенными транзакциями. Имеются признаки того, что IBM и Informix развивают свои СУБД для обеспечения этих сервисов. Это особенно критично для компании Informix, которой нужно дождаться развития рынка приложений ОРСУБД. Следует ожидать интересных результатов.