 |
Примеры объектно-ориентированных СУБД (проекты ORION и O2).
|
|
|
|
Проект ORION осуществлялся с 1985 по 1989 г. фирмой MCC под руковоством известного еще по работам в проекте System R Вона Кима. Под названием ORION на самом деле скрывается семейство трех СУБД: ORION-1 - однопользовательская система; ORION-1SX, предназначенная для использования в качестве сервера в локальной сети рабочих станций; ORION-2 - полностью распределенная объектно-ориентированная СУБД. Реализация всех систем производилась с использованием языка Common Lisp на рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС Genera 7.0 и SUN-3 в среде ОС UNIX. Описание реализации ORION-2 пока не опубликовано, поэтому мы рассмотрим только ORION-1 и ORION-1SX.
Основными функциональными компонентами системы являются подсистемы управления памятью, объектами и транзакциями. В ORION-1 все компоненты, естественно, располагаются в одной рабочей станции; в ORION-1SX - разнесены между разными рабочими станциями (в частности, управление объектами производится в рабочей станции-клиенте). Применение в ORION-1SX для взаимодействия клиент-сервер механизма удаленного вызова процедур позволило использовать в этой системе практически без переделки многие модули ORION-1. Сетевые взаимодействия основывались на стандартных средствах операционных систем.
В число функций подсистемы управления памятью входит распределение внешней памяти, перемещение страниц из буферов оперативной памяти во внешнюю память и наоборот, поиск и размещение объектов в буферах оперативной памяти (как принято в объектно-ориентированных системах, поддерживаются два представления объектов - дисковое и в оперативной памяти; при перемещении объекта из буфера страниц в буфер объектов и обратно представление объекта изменяется). Кроме того, эта подсистема отвественна за поддержание вспомогательных индексных структур, предназначенных для ускорения выполнения запросов.
|
|
|
Подсистема управления объектами включает подкомпоненты обработки запросов, управления схемой и версиями объектов. Версии поддерживаются только для объектов, при создании которых такая необходимость была явно указана. Для схемы БД версии не поддерживаются; при изменении схемы отслеживается влияние этого изменения на другие компоненты схемы и на существуующие объекты. При обработке запросов используется техника оптимизации, аналогичная применяемой в реляционных системах (т.е. формируется набор возможных планов выполнения запроса, оценивается стоимость каждого из них и выбирается для выполнения наиболее дешевый) [102].
Подсистема управления транзакциями обеспечивает традиционную сериализуемость транзакций, а также поддерживает средства журнализации изменений и восстановления БД после сбоев. Для сериализации транзакций применяется разновидность двухфазного протокола синхронизационных захватов с различной степенью гранулированности [103]. Конечно, при синхронизации учитывается специфика ООБД, в частности, наличие иерархии классов. Журнал изменений обеспечивает откаты индивидуальных транзакций и восстановление БД после мягких сбоев (архивные копии БД для восстановления после поломки дисков не поддерживаются).
Проект O2 реализуется французской компанией Altair, образованной специально для целей проектирования и реализации объектно-ориентированной СУБД. Начало проекта датируется сентябрем 1986 г., и он был расчитан на пять лет: три года на прототипирование и два года на разработку промышленного образца. Текущий прототип системы функционирует в режиме клиент/сервер в локальной сети рабочих станций SUN c соответствующим разделением функций между сервером и клиентами.
|
|
|
Основными компонентами системы (не считая развитого набора интерфейсных средств) являются интерпретатор запросов и подсистемы управления схемой, объектами и дисками. Управление дисками, т.е. поддержание базовой среды постоянного хранения обеспечивает система WiSS [104], которую разработчики O2 перенесли в окружение ОС UNIX.
Наибольшую функциональную нагрузку несет компонент управления объектами. В число функций этой подсистемы входит:
- управление сложными объектами, включая создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем;
- управление передачей сообщений между объектами;
- управление транзакциями;
- управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);
- отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во внешней памяти до тех пор, пока достижим из какого-либо долговременно хранимого объекта);
- управление буферами оперативной памяти (аналогично ORION, представление объекта в оперативной памяти отличается от его представления на диске);
- управление кластеризацией объектов во внешней памяти;
- управление индексами.
Несколько слов про управление транзакциями. Различаются режимы, когда допускается параллельное выполнение транзакций, изменяющих схему БД, и когда параллельно выполняются только транзакции, изменяющие внутренность БД. Первый режим обычно используется на стадии разработки БД, второй - на стадии выполнения приложений. Средства восстановления БД после сбоев и откатов транзакций также могут включаться и выключаться. Наконец, поддерживается режим, при котором все постоянно хранимые объекты загружаются в оперативную память при начале транзакции для увеличения скорости работы прикладной системы.
Компонент управления схемой БД реализован над подсистемой управления объектами: в системе поддерживаются несколько невидимых для программистов классов и в том числе классы "Class" и "Method", экземплярами которых являются, соответственно, объекты, определяющие классы, и объекты, определяющие методы. (Как видно, ситуация напоминает реляционные системы, в которых тоже обычно поддерживаются служебные отношения-каталоги, описывающие схему БД.) Удаление класса, который не является листом иерархии классов или используется в другом классе или сигнатуре какого-либо метода, запрещено.
|
|
|
Даже приведенное краткое описание особенностей двух объектно-ориентированных СУБД показывает прагматичность современного подхода к организации таких систем. Их разработчики не стремятся к полному соблюдению чистоты объектно-ориентированного подхода и применяют наиболее простые решения проблем, которые на самом деле еще не решены. Пока в сообществе разработчиков объектно-ориентированных систем БД не видно работы, которая могла бы сыграть в этом направлении роль, аналогичную роли System R [105] по отношению к реляционным системам. Правда, и проблемы ООБД гораздо более сложны, чем решаемые в реляционных системах.
Многоплатформные СУБД.
Базой систем нового поколения являются профессиональные(многопользовательские, многоплатформенные) СУБД и архитектура «клиент —сервер», реализуемая на их основе.
Профессиональные СУБД обеспечивают выполнение более сложных операций. Они позволяют разработчику расширять сервисные возможности -процедуры базы данных, которые вызываются клиентом и выполняются сервером более производительно, чем компьютеры на рабочих местах пользователей. К профессиональным СУБД относятся Oracle, SyBase, Informix, Ingres, Progress.Перечисленные системы имеют средства обработки информации, распределенной по нескольким узлам сети. Распределенная обработка данных позволяет разместить базу в различных узлах таким образом, чтобы отслеживать изменения на всех узлах и чтобы каждый компонент данных располагался на том узле, где он будет обрабатываться.
Новейшей технологией управления распределенными базами данных является тиражирование. Профессиональные СУБД поддерживают те или иные механизмы тиражирования.
Тиражирование представляет собой асинхронный перенос изменений объектов исходной базы данных в базы данных, принадлежащие различным узлам распределенной системы. При внесении изменений одновременный доступ ко всем узлам, затрагиваемым этими изменениями, не требуется. Данные изменяются на одном узле, а затем переносятся на остальные. Тиражирование может производиться после завершения определенного числа транзакций, в том числе и после каждой транзакции, через равные промежутки или к определенному моменту времени,контролироваться администратором системы или пользовательским приложением.
|
|
|
Распределенная обработка позволяет в широких пределах варьировать вычислительными ресурсами, избегая узких мест, сдерживающих производительность, и добиваясь максимальной эффективности информационных систем.
Особенностью современных информационных систем, например,биржевых или банковских, является требование оперативного оповещения пользователей о происходящих событиях. Например, все участники фондовой биржи должны немедленно получать информацию о совершенных сделках, изменениях котировок и т.д. Другими словами, предполагается наличие некоторого количества процессов, которые должны исполняться параллельно и синхронизироваться во время исполнения. Это приводит к необходимости обмена информации между ними.Профессиональные СУБД типа Oracle позволяют организовать эти процессы в виде отдельных приложений на одной базе данных. Например, при совершении сделки процесс, занимающийся их регистрацией, возбуждает событие «совершена сделка».Результаты ее включаются в общий поток информации о сделках. Если же этот процесс не исполняется, то событие «совершена сделка» не приводит ни к каким дополнительным действиям. Механизмы событий, реализованные в современных профессиональных СУБД, являются готовым технологическим средством, которое позволяет разработчикам информационных систем экономить значительное количество времени и усилий.
По мере развития любой хозяйственной деятельности появляется потребность в наращивании информационной системы. Возникает вопрос, как встроить имеющееся локальное приложение в новую систему. Профессиональные СУБД предоставляют достаточно широкие возможности. Развитые системы шлюзов позволяют строить информационные системы, распределенные по узлам с различными аппаратными и программными платформами. Большой интерес представляет также использование локальными приложениями так называемого ODBC — стандарта (Open DataBase Connectivity, стандарт, предложенный фирмой Microsoft), который дает возможность прозрачного доступа к данным СУБД различных типов. Таким образом,приложение, разработанное с учетом стандарта ODBC, имеет большую гибкость при интеграции в существующую информационную систему.
|
|
|
Потребность в гибких решениях для современных информационных систем диктуется жизнью. На практике чаще всего встречается потребность в объединении возможностей отдельных подсистем или программных модулей; Причем все это нужно иметь на одной базе данных. Через некоторое время соотношение потребностей может измениться. Поэтому для построения информационной системы важно иметь инструмент, который наиболее приспособлен для построения открытых и гибких систем. Таким инструментом в настоящий момент являются профессиональные СУБД SQL, обеспечивающие работу в модели «клиент — сервер» и обладающие развитыми средствами разработки и сопровождения баз данных. Использование профессиональной СУБД позволяет иметь программное обеспечение, в большей степени отвечающее конкретным потребностям организации.
|
|
|
