ВЫБОР СУБД ДЛЯ ПОСТРОЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ КОРПОРАТИВНОГО УРОВНЯ НА ОСНОВЕ ОБЪЕКТНОЙ ПАРАДИГМЫ

Статья публикуется с разрешения НПЦ "ИНТЕЛТЕК ПЛЮС"

А.М.Андреев, к.т.н., доц. МГТУ им. Н.Э.Баумана,
Д.В.Березкин, к.т.н., директор НПЦ "ИНТЕЛТЕК ПЛЮС",
Ю.А.Кантонистов, ведущий разработчик НПЦ "ИНТЕЛТЕК ПЛЮС"
контактный тел. (095) - 177-35-11

Выбор объектной парадигмы проектирования

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

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

Бурное развитие технологии объектного проектирования привело к необходимости разработки стандартов и спецификаций в этой области [2]. Создание таких стандартов также безусловно положительно сказалось на привлекательности объектного подхода для разработчиков ИС.

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

Итак, первый критерий выбора СУБД продиктован выбором самого подхода к проектированию ИС в целом - если выбран объектный подход, то оправдан выбор объектной СУБД.

Такую ситуацию прекрасно осознают и основные производители реляционных СУБД. Практически каждая уважающая себя фирма обратилась лицом к объектным технологиям и продуктивно сотрудничает с разработчиками объектно-ориентированных СУБД. IBM и Oracle доработали свои СУБД (соответственно, DB2 и ORACLE) добавив объектную надстройку над реляционным ядром системы. Другой путь выбрал Informix, который приобрел серьезную объектно-реляционную СУБД Illustra и встроил ее в свою СУБД. В результате получился продукт, именующийся универсальным сервером. Другой лидер рынка СУБД - Computer Associates, поступил иначе. Он сделал ставку на чисто объектную базу Jasmine, активно пропагандируя ее достоинства. Об особенностях этой СУБД и привлекательности ее для разработчиков приложений мы уже писали [3].

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

Рисунок 1. Объектные базы и реляционные СУБД

В чем же принципиальное отличие реляционных и объектных баз? Мэри Лумис, один из идеологов СУБД Versant, очень кратко и точно сформулировала актуальность объектного подхода к базам данных: "Модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая их по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов".

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

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

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

На последующих стадиях проектирования основная нагрузка ложится на программную реализацию основных элементов системы. Выбор объектного языка программирования в качестве инструмента разработки очевиден для объектного подхода к проектированию. С точки зрения программиста создание программ для объектных баз существенно отличается от написания приложений, взаимодействующих с реляционными СУБД. Объектная СУБД, как правило, поддерживает один или несколько объектно-ориентированных языков - C++, Java, Smalltalk, Object Lisp и т.п. В своих программах разработчики используют объекты и структуры, которые помещаются в базу данных. Это принципиальный момент. Подчеркнем, что программа не требует специальных блоков для общения с базой данных. Чтобы сохранить их в базе не требуется особых усилий. Создатели объектных СУБД стараются максимально облегчить жизнь разработчика программ, поэтому сохранение объектов обеспечивается прозрачным образом. Программист использует единый язык программирования для создания логики приложения, разработки интерфейса и общения с базой данных. В сочетании с визуальными средствами разработки создание прикладных программ может быть проведено с минимальными затратами средств и времени.

Таким образом, если выбран объектный язык программирования как инструмент разработки, то оправдан и выбор объектной СУБД.

Мы рассмотрели очень коротко, те преимущества, которые дают объектные СУБД по сравнению с другими классами СУБД при использовании объектного подхода к проектированию ИС. Более полный сопоставительный анализ различных классов современных СУБД приведен в статье [5]. Здесь мы приведем мифы, которые связаны с объектными СУБД: слева собраны крайние отрицательные точки зрения их противников, а справа слишком оптимистические отзывы (Таблица 1), причем те и другие основываются на недостатке информации или не правильном понимании особенностей этих систем [6]. Мы коротко поясним, в чем заключалась ошибочность этих выводов и надеемся, что дальнейший анализ объектных СУБД позволит читателю составить достаточно полное представление об их особенностях и объективно судить о возможности или целесообразности их использования в различных областях.

Таблица 1. Мифы об объектных СУБД.

Отрицательные отзывы

Легендарные свойства

1. Объектные СУБД не обладают достаточной производительностью. - Очень старый миф. Результаты последних тестирований показывают, что они даже превосходят по производительности реляционные СУБД, особенно при необходимости манипулировать сложными данными. 2. Объектные СУБД не обладают масштабируемостью. - Некоторые СУБД имели проблемы, особенно в своих первых версиях, однако это нельзя распространять на весь класс систем. Следует иметь также в виду, что они позволяют сохранять более сложные данные, следовательно реализовать масштабируемость сложнее, но и возможности создаваемых ИС больше. 3. Объектные СУБД не могут выполнять запросы (т.е. пользователь должен явно программировать путь доступа к данным).- Современные системы поддерживают объектное расширение языка запросов и индексирование БД. 4. У объектных СУБД нет реальных пользователей и реально действующих приложений.- Можно указать множество областей использования, причем среди них много таких, в которых исключительно высоки требования к производительности и надежности СУБД. 5. Объектные СУБД не поддерживают механизм транзакций.- Объектные СУБД поддерживают иные механизмы транзакций, чем реляционные, в связи с этим их приложения имеют ряд ценных преимуществ, о которых речь пойдет ниже. 6. Объектные СУБД - это лишь расширение языка программирования путем добавления в него оператора сохраняемости объектов.- Так как объектные СУБД используют объектные языки программирования, то может возникнуть такая путаница. На самом деле объектные СУБД удовлетворяют всем требованиям к современным СУБД, также их архитектура имеет ряд полезных особенностей, например, поддержка версионности и рабочих групп, которые мы рассмотрим в дальнейшем. 7. Объектные СУБД не поддерживают триггеров событий.- Для регистрации событий в объектных СУБД используется концепция сообщений, которая обладает не меньшими возможностями, чем триггеры реляционных БД.

1. Объектные СУБД в 10 (1000) раз быстрее,чем РБД. - Это действительно так в случае если в программе многократно осуществляется переход от объекта к объекту по ссылке. Действительно поскольку в качестве ссылкам на объект хранится идентификатор объекта, однозначно определяющий его расположение в базе, то переход по такой ссылке осуществляется быстрее, чем ссылка между кортежами отношений по первичному ключу. В объектных СУБД объекты переносятся на клиент покластерно и там загружаются в память прикладной программы. 2. Объектные СУБД устраняют необходимость в языке запросов. - Современные СУБД обладают той или иной разновидностью объектного языка запросов OQL - языка, стандартизованного ODMG (Object Database Management Group). 3. Объектные СУБД устраняют необходимость в соединениях. - По сути ООБД явное соединение заменяют неявным. 4. Объектные СУБД могут поддерживать версии и длинные транзакции. -Если быть точнее, в объектных СУБД легче реализовать эти механизмы.

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

Свое рассмотрение мы начнем с подхода к классификации объектных СУБД.

Классификация объектных СУБД

На сегодняшний день нет общепризнанной классификация объектных СУБД. Можно согласиться с теми авторами, которые в основывают свою классификацию на особенностях моделей данных, которые имеют те или иные БД. С этой точки зрения можно выделить две основные группы: чисто объектные СУБД (pure ODBMS) и СУБД, основанные на модели сохраняемых объектов (persistent storage managers).

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

Как правило, такие системы поддерживают механизмы распределенных баз данных (transparent distributed database capabilities), многопользовательского доступа к БД, имеют встроенные средства разработки и администрирования.

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

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

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

Распределение указанных классов СУБД по занимаемым сегментам рынка иллюстрируется Рис. 2.

Рисунок. 2. Распределение классов современных СУБД по сегментам рынка

Для выработки критериев выбора СУБД рассмотрим те области в которых производятся их оценки, а затем рассмотрим основные критерии этих оценок.

Критерии оценки объектных СУБД

Существующие критерии, по которым можно оценивать СУБД условно делятся на три большие области:

• функциональность;
• особенности разработки приложений;
• смешанные критерии.

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

Существуют еще две области оценок СУБД:

• поддерживаемые платформы;
• производительность.

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

Критерии оценки объектных СУБД с точки зрения разработки высокоэффективных приложений

Критерии влияющие на функциональность СУБД

Проведенное исследование позволяет разбить эту область на пять групп, в которых можно с большой степени независимости анализировать характеристики СУБД и оценивать их влияние на возможные свойства разрабатываемых приложений:

1. Особенности объектной модели;
2. Архитектура СУБД;
3. Механизмы СУБД;
4. Программирование интерфейса приложений;
5. Запросы к объектам.

Рассмотрим подробно каждую из указанных групп.

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

Можно отметить, что такой сопоставительный анализ принесет значительный практический результат, если при его проведении учитывать специфику разрабатываемого приложения. Вы убедитесь в этом, когда мы перейдем к рассмотрению особенностей некоторых приложений, основанных на использовании объектной СУБД VERSANT компании Versant Object Technology Corporation.

Таблица 2. Критерии оценки объектных СУБД,основанные на особенностях модели данных

Оцениваемый параметр	Описание	Критерии оценки	Влияние на характеристики СУБД и их приложений
Идентификатор объекта	Основное понятие объектной СУБД. Каждый объект снабжен уникальным идентификатором, который остается неизменным в процессе выполнения приложений.	Прямое или косвенное хранение идентификаторов объектов.	Скорость доступа к сложносвязанным данным
			Объем БД
			Сложность механизма поддержания целостности ссылок
		Возможность повторного использования идентификатора при удалении объекта.	Дополнительные возможности восстановления неверно удаленных объектов.
Пример СУБД Versant Каждый объект при добавлении в систему получает уникальный идентификатор - так называемый loid. Идентификатор состоит из двух частей. Первая часть однозначно идентифицирует базу данных, в которую помещается объект, а другая - расположение объекта в пределах этой базы. Идентификатор удаленного объекта не используется повторно. Отметим, что таким образом достигается переносимость объектов между базами Versant.
Сложные объекты	Объекты реального мира наиболее естественным образом помещаются в БД. Сложные объекты строятся из простых (целых чисел, символов, символьных строк и т.п.) при помощи конструкторов (множеств, списков, кортежей и др.).	Количество полей, типы данных, особенности хранения ссылок на другие объекты.	Возможность адекватного отражения объектов реального мира в ИС, скорость разработки приложений, возможности разработки многопользовательских систем.
Пример СУБД O2 Объект в O2 состоит из атрибутов, методов, . Атрибутами могут быть атомарные типы (символы, строки, числа и т.п.), составные типы данных (кортежи, списки, множества) и объекты. Допускается рекурсивное определение. class person name: string, photo: bitmap, age: integer, father: person method getName, getPhoto, getAge end
Классы	Основное понятие объектного проектирования, характеризующее множество объектов с общей структурой и поведением. Каждый объект принадлежит только одному классу.	Сохраняемость классов в БД.	В чисто объектных СУБД классы по умолчанию являются сохраняемыми, что в конечном итоге приводит к большей гибкости проектирования, а, в ряде случаев, и производительности приложений.
Атрибуты	Представляют те данные, которые могут входить в тот или иной класс.	Возможность использования в качестве атрибутов текстовых и мультимедийных данных, а также ссылок на другие объекты.	Облегчает разработку и увеличивает производительность приложений, оперирующих со слабоструктурированными, сложносвязанными данными.
Методы	Описывают правила, по которым объекты оперируют со своими атрибутами.	Возможность сохранения методов вместе с данными в одной и той же БД.	Важное преимущество объектных СУБД. Существенно влияет на гибкость разработки приложений и на возможность сложной многопользовательской работы.
Пример СУБД O2 Тип - основная структурная единица языка. Классы - это подмножество типов в языке описания объектов O2. Пример POET Объекты могут быть как сохраняемыми (persistent) так и динамическими (transient). Сохраняемые объекты порождаются от класса , который объявлен persistent: persistent class Person { char *pszName; int iAge; }; Пример Jasmine Атрибуты классов и методы сохраняются вместе в базе данных. Таким образом, Jasmine - активная СУБД.Клиентская прикладная программа переадресует вызов метода объекта на сервер, передает параметры, метод выполняется на сервере и на клиент возвращается результат операции.
Инкапсуляция	Позволяет скрыть атрибуты и методы класса или объекты от других пользователей.	Независимость данных при их модифицировании различными клиентами.	Дополнительные возможности для организации многопользовательской работы. Разработка приложений группой программистов.
Наследование	Позволяет одному классу включать атрибуты и методы других классов. Вводит иерархию "общее/частное", в которой подкласс наследует от одного или нескольких более общих суперклассов.	Единичное или множественное наследование. Управление конфликтами при множественном наследовании.	Множественное наследование является мощным механизмом для повторного наращивания существующих классов. Резко сокращается время разработки приложений.
		Поддержка типа наследования: через подстановку, путем включения, через ограничение и через специализацию.	Преимущества и недостатки того или иного типа наследования не очевидны и проявляются на поздних стадиях разработки приложений. Желательно, что бы СУБД поддерживала несколько или все типы.
Перекрытие, перегрузка и динамическое связывание	Использование одного и того же имени для различных операций (полиморфизм имен). Имена операций транслируются в адрес программы на этапе выполнения (происходит динамическое связывание).	Возможность проверки типов данных на этапе трансляции программ.	Возможность использования разработанных приложений для манипулирования объектами других классов.
			Ускорение модификации приложений.
			Простота отладки приложений.
Пример O2 В целом классы в O2 реализованы в соответствии со схемой, принятой в C++. Особенностью O2 является наличие спецификаторов атрибутов и методов и параметров методов как общедоступные (public), закрытые (private) и только для чтения (read).
Сохраняемость	Отличительная особенность объектных СУБД. Объекты сохраняются в БД и могут многократно использоваться различными приложениями.	Свойство сохраняемости является уникальной характеристикой объекта.	Более простая реализация СУБД. В некоторых приложениях могут возникнуть ограничения на многопользовательскую работу.
		Свойство характеризует класс объектов (по умолчанию объекты относятся к сохраняемому классу или наследуют свойство сохраняемости от некоторого специального класса).	Более сложная реализация СУБД. Высокая эффективность сложных многопользовательских приложений.
		Поддержка целостности ссылок при удалении объектов.	Возможность реализовать 2 стратегии: 1) при удалении объекта удалять все ссылки на него; 2) объект все равно сохраняется, пока на него существуют ссылки из других объектов. Выбор предпочтительной стратегии зависит от особенностей приложений.
Пример Versant В базе данных сохраняется любой экземпляр класса-потомка PtObject. Пример Jasmine Экземпляр любого класса, описанного на языке запросов ODQL (Object Database Query Language) сохраняется в базе данных. Пример O2 В базе данных сохранятся именованные объекты или их коллекции (списки, множества и т.п.) Пример ObjectStore Сохраняемыми являются объекты, созданные с помощью специальной реализации оператора new.
Наименование объектов	Имена объектов должны быть уникальными в пределах некоторой области имен (name scope). Объектная модель представляется в виде сети связанных объектов.	Возможность поддержки нескольких областей имен.	Уменьшение шансов возникновения конфликтов имен объектов.
Пример O2 Объекту или коллекции объектов можно присвоить уникальное имя. Присвоение имени означает сохраняемость объекта (коллекции объектов) в базе данных. Помимо этого уникальное имя служит ключом для доступа к именованному объекту.
Отношения	Важный компонент объектной модели представления данных. Отношения позволяют объектам ссылаться друг на друга в результате чего формируется сеть связанных объектов.	Возможность эффективно и наиболее естественно поддерживать связи между данными.	Высокая эффективность объектных СУБД при выполнении различных операций над сложносвязанными данными.
		Одно- и двунаправленные отношения, отношения один к одному, один ко многим, многие ко многим.	Поддержка всех типов отношений дает дополнительные возможности разработчикам приложений для представления сложносвязанных данных. Поддержка двунаправленных отношений позволяет легко контролировать целостность отношений. Использование отношений для организации различных механизмов кэширования объектов.
Пример POET Наличие отношений между двумя объектами выражается во владении каждым из них уникальным идентификатором другого. Пример Versant Существуют предопределенные типы для использования указателей. Например, указатель на строку записывается как объект PString, указатель на список - PList и т.п.
Составные объекты	Группировка связанных объектов таким образом, чтобы их можно было рассматривать как единый объект.	Возможность моделирования семантических отношений типа часть некоторого целого.	Поддержка групповых операций над объектами (эквивалентность, копирование, удаление, блокировка) позволяет создавать высокоэффективные приложения.
Пример O2 Наряду с возможностью описания нового класса в языке запросов O2 предусмотрена операция создания нового типа путем объединения данных различной структуры. Это так называемые tuple, или кортежи. Например, запись: Person: tuple( name: string, age: integer, sex: char ) означает появление переменной Person, в которая состоит из набора полей - имени, возраста и пола.
Видимость (Location Transpa-rency)	К объекту есть доступ независимо от места его расположения в распределенной БД.	Возможность свободного перемещения объектов без нарушения целостности БД и целостности отношений.	Создание и поддержка распределенных БД и ИС.
Пример O2 В СУБД O2 каждый объект имеет идентификатор, однозначно указывающий положение объекта в базе данных. Программисту идентификатор не доступен. Программист манипулирует объектами согласно правилам языка, например создает объект с помощью оператора new и удаляет с помощью оператора delete в программе на C++. СУБД управляет расположением объектов прозрачным для программиста образом.
Версионность объектов	Сохранение в БД нескольких версий одного и того же объекта.	Автоматическая поддержка версионности. Линейная версионность (Linear Versioning): сохраняется только единственная новая версия объекта или ограниченная версионность (Branch Versioning): каждый пользователь может сохранять собственные версии объектов.	Важно для приложений, использующих "длинные" транзакции. Возможно быстрое неконтролируемое увеличение объема БД, что требует специальных методов контроля.
Пример Versant Пользователю СУБД предоставляется набор функций для порождения и контроля версий объектов. Каждый сохраняемый в базе объект можно объявить версионным. Версии одного объекта могут состоять в отношениях потомок/предок/брат. Для управления отношениями между версиями предусмотрен специальный модуль VersionManager. Он отслеживает версии объекта не только в пределах одной базы, но и при миграции версий объекта между базами. Вот как , например, может выглядеть граф версий одного и того же объекта, претерпевшего миграцию в трех базах:
Поддержка рабочих групп	Возможность управлять доступом к различным сегментам БД.	Автоматическая поддержка рабочих групп. Поддержка персональных БД. Возможность перемещать объекты на рабочие места пользователей, где обрабатывать их в отключенном от БД режиме, затем возвращать обновления в БД.	Возможность создания сложных многопользовательских систем. Особенно важно для многопользовательских САПР, систем управления документооборотом, при разработке CASE-средств и в некоторых других случаях.
Пример Versant, POET, O2. Отметим сразу, что концепция поддержки групповой работы в СУБД Versant, POET И O2 полностью совпадает. Она базируется на фундаментальных операциях - импорте/экспорте (checkin/checkout) объектов из/в базе данных. Versant обеспечивает программный интерфейс, для переноса объектов из групповой базы данных в персональную для ведения. Каждый сотрудник, работающий над проектом, получает версии объектов в персональное пользование на определенное время (операция checkout), возможно, на довольно продолжительное. В течение такого сеанса пересылок по сети не происходит. После завершения работы пользователь возвращает объекты в групповую базу данных (операция checkin).
Схема развития	Определяет, как созданные ранее объекты учитывают изменения в определении класса этих объектов.	Автоматическая поддержка СУБД изменений описаний классов. Различные схемы изменений.	Позволяет осуществлять обновление схемы БД без необходимости отключения пользователей, выгрузки и повторной загрузки БД.
Пример Versant Поддерживается динамическое изменение схемы базы данных. В объектной базе схема - это множество классов, ассоциированное с базой данных. В любой момент схема базы данных может быть изменена без потери данных, накопленных в базе.
Схема доступа	Доступ к схеме БД из приложений.	Возможность модификации схемы БД на этапе выполнения прикладных программ.	Возможность создания динамически расширяемых приложений. Особенно удачно можно использовать в системах объектного моделирования.
Пример Jasmine В любой момент времени пользовательская программа может добавить новое описание класса. Versant СУБД Versant позволяет динамически модифицировать схему базы данных, то есть в случае обновления схемы база данных не нуждается в перезагрузке.
Интеграция с другими СУБД.		Поддержка языка SQL.	Совместимость с реляционными СУБД.
		Поддержка стандарта ODMG-93.	Совместимость с другими объектными СУБД.
Пример POET Связь с реляционными СУБД реализуется за счет поддержки стандарта ODBC. Пример Jasmine Поддерживается стандарт OLEDB, а также в составе СУБД присутствуют шлюзы к реляционным базам: OpenIngres, DB2 и другим. Среди поставляемых классов СУБД есть набор классов для реализации SQL-запросов.
Активные и пассивные СУБД	В активных СУБД методы сохраняются в БД, а в пассивных - нет.	Возможность сохранения методов объектов в БД.	Метод может быть выполнен на сервере, что значительно сокращает трафик компьютерной сети. Дополнительные возможности администрирования доступа к данным.
Пример Jasmine Наряду с атрибутами объекта в базе данных Jasmine сохраняются также методы. Таким образом, реальная обработка данных выполняется на сервере, что существенно уменьшает нагрузку на сеть. Клиентская программа передает на сервер идентификатор объекта и имя метода, который надо выполнить. Также передаются все необходимые аргументы. Сервер выполняет метод и возвращает на клиентское место только результат операции. Например, чтобы вычислить среднемесячный доход Иванова по сведениям из базы данных программист пишет следующую строку: Person Ivanov = Person.new(); int avgrev = Ivanov.AverageRevenue( 01.01.1998, 01.01.1999 ) Последовательность операции следующая:

Теперь аналогичным образом рассмотрим критерии, основанные на особенностях архитектуры объектных СУБД (Таблица 3).

Таблица 3. Критерии оценки объектных СУБД, основанные на особенностях их архитектур.

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

Теперь рассмотрим те параметры объектных СУБД, которые характеризуют особенности ее функционирования и получим новые критерии оценок (Таблица 4).

Таблица 4. Критерии оценки объектных СУБД, основанные на особенностях их функционирования.

Оцениваемый параметр	Описание	Критерии оценки	Влияние на характеристики СУБД и их приложений
Доступ к неограниченным данным	Возможность обеспечить приложению доступ к практически безграничному адресному пространству.	Поддержка механизмов доступа к неограниченным данным.	Приложение может манипулировать очень большими объектами, которые не могут быть размещены в его адресном пространстве.
Целостность	СУБД должна поддерживать структурную и логическую целостность. Структурная целостность означает, что все помещенные в БД объекты удовлетворяют ее схеме. Логическая целостность означает, что введенные ограничения на логические свойства данных всегда выполняются.	Доступ к схеме данных из приложений.	Открывает новые возможности манипулирования данными, которые невозможно реализовать традиционными способами. Затрудняет контроль за целостностью данных.
		Автоматическое удаление ссылок на несуществующие объекты и проверка соответствия объектов определениям соответствующих классов.	Инкапсуляция данных в соответствующих классах и доступ к ним через методы, определенные в этих классах.
		Введение дополнительных ограничителей целостности, специфицируемых на уровне приложений.	Ограничители, выполняемые до соответствующего метода, проверяют правомочность обращения к объекту и входные параметры. Ограничители, выполняемые после выполнения метода, проверяют результирующее состояние объекта и выходные параметры.
Одновременный доступ к данным	СУБД поддерживают механизмы, которые не позволяют нарушить данные при обращении к ним одновременно нескольких пользователей или поместить в БД данные, которые были модифицированы лишь частично.	Поддержка "пессиместическо-го" механизма управления доступом: процесс обновления информации происходит изолированно от других процессов и синхронизуется транзакциями.	БД обновляетсятолько после успешногозавершения транзакции. В противном случае выполняется откат транзакции и все обновления теряются. Механизм оправдан для приложений с "короткими" транзакциями.
		Поддержка "оптимистического" механизма управления доступом: все формы доступа разрешены, конфликты преодолеваются во время транзакций.	В случае конфликта простого отката транзакций не происходит, используется версионность. Механизм получил наибольшее распространение в объектных СУБД, где чащеиспользуется схема "длинных" транзакций. Некоторые СУБД в моменты транзакций оповещают пользователей, которые читают данные, что эти данные находятся в процессе изменения.
		Поддержка механизма "многие читают, а один записывает".	Используется версионность объектов: сперва обновляется версия объекта а запись изменений в БД производится лишь тогда, когда завершены все операции чтения этого объекта другими пользователями. В целом, предпочтительнее те СУБД, в которых механизмом конкуренции можно управлять.
Надежность	БД возвращается в исправное состояние после аппаратных и программных сбоев.	СУБД должна восстанавливаться после сбоев в приложениях, ошибок в системе и в случае дефектов носителей информации.	Как правило, современная объектная СУБД имеет набор средств, которые позволяют восстановить информацию после различных сбоев. Выбор необходимых средств определяется спецификой приложения.
Транзакции	Механизм используемый для управления конкуренциями и поддержания надежности БД.	Поддержка нескольких схем транзакций. Поддержка вложенных (nested) транзакций.	В некоторых объектных СУБД имеется возможность разбивать длинные транзакции на серии вложенных транзакций, что позволяет управлять конкуренциями в распределенных приложениях.
Блокировки	Типичный для СУБД способ выполнения транзакций.	Уровень блокировки: блокировки на уровне объектов или страниц.	Блокировки на уровне объектов являются более сложным механизмом управления блокировками и конкуренцией, однако, при этом достигается наибольшая производительность в многопользовательском режиме.
Определение "мертвых" блокировок (Deadlock Detection)	СУБД используют специальные алгоритмы определения "мертвых" блокировок для преодоления конфликта блокировок.	Использование альтернативных механизмов управления транзакциями для преодоления конфликта блокировок.	Используемые в реляционных СУБД традиционные традиционные подходы приводят к потерям инфорации после прерывания транзакции. Альтернативные механизмы позволяют преодолеть конфликт не потеряв при этом произведенные пользователем изменения.
Сохранение и перезагрузка БД	Копирование (и последующее восстановление) БД на другой носитель в случае ошибок или для сохранения ее состояния на определенный момент времени.	Выполнение резервного копирования в процессе использования БД. Возможность выборочного сохранения отдельных сегментов БД или сохранения только тех изменений которые произошли с момента предыдущего сохранения.	Увеличивает производительность и надежность ИС в целом.
Выгрузка и загрузка данных	Возможность выгрузки информации в понятном пользователю ASCII формате файла.	Поддержка СУБД этой функции.	Повышает надежность хранения информации, упрощает перенос информации в другие прикладные программы, дает дополнительную возможность восстановить БД после сложных сбоев.
Ограничители	Специфицированные на уровне приложений условия, которые в данной БД всегда должны быть истинными.	Ограничители включаются в методы объектов и/или поддерживается отдельный механизм ограничителей.	Использование отдельного механизма ограничителей позволяет более надежно обеспечивать логическую целостность БД.
Модель сообщений (Notification Model)	Дает возможность приложениям узнать об изменении тех или иных объектов или наступлении определенных событий в БД.	Пассивная или активная модель сообщений.	При использовании пассивной модели приложения должны сами периодически запрашивать БД об изменении интересующих их объектов и наступлении тех или иных событий. В активной модели при наступлении определенных изменений или событий в БД автоматически запускаются те или иные программы в приложениях. В ряде случаев активная модель сообщений оказывается проще, чем традиционные триггеры или система ограничителей.
Индексирование	Оптимизация поиска данных в БД по различным критериям путем введения некоторых дополнительных данных - индексов.	Технологии индексирования: кэширование и b-деревья.	Различные алгоритмы индексирования приводят к различным характеристикам конечной системы: время и степень релевантности поиска, объем индексной информации, увеличение времени добавления, удаления, модифицирования объектов и восстановления БД после сбоев, связанное с вычислительной сложностью этих алгоритмов. Все это необходимо учитывать при разработке приложений.
		Поддерживаемые типы поисковых индексов.	Наиболее распространено индексирование по тексту и по изображению.
		Учитывается или не учитывается специфика естественного языка, на котором написаны тексты помещаемые в БД.	Учет специфики языка при индексировании сокращает время поиска и увеличивает степень релевантности. При таком подходе нет необходимости подключения к ИС тезауруса языка.
		Индексирование в пределах класса или сквозное индексирование всей БД.	Сквозное индексирование БД увеличивает полноту поиска, однако, увеличивает время поиска и часто приводит к большой избыточности списков найденных объектов и требует использования дополнительных алгоритмов фильтрации этих списков.
Примеры ODB-Jupiter Специфика языка учитывается при индексировании текстов в разработанной в НПЦ "ИНТЕЛТЕК ПЛЮС" при участи авторов объектной СУБД "ODB-Jupiter" [7], позволяющей эффективно реализовывать полнотекстовые информационно-поисковые системы на русском, английском и др. языках. Индексирование (и поиск) в пределах класса реализовано в СУБД "ODB-Jupiter", что приводит к тому, что в приложении этой СУБД поиск производится среди документов данного типа. POET В языке программирования СУБД POET есть специальное ключевое слово index, которое указывает на необходимость создания индекса по атрибуту класса для всех объектов, сохраняемых в базе данных. persistent class Person { index char *pszName; index int iAge; . . . }; В приведенном примере индексированию подлежат атрибуты pszName и iAge класса Person.
Контроль за использованием памяти	БД должна следить за освобождающимся после удаления объектов адресным пространством.	Осуществление непрерывного контроля.	Исключает возможность непредсказуемого увеличения объема БД.
		Не требуется периодически производить в ручную операции выгрузки и перезагрузки БД.	Поддержка постоянной производительности ИС на уровне, который достигался при первоначальной загрузке БД.
Полнота использования ресурсов CPU	Необходимость максимально полно использовать ресурсы процессора возникают в тех приложениях, которые предполагают высокие скорости доступа к кэшируемым объектам.	Количество команд, которое требуется СУБД для доступа к кэшируемым объектам.	Если этот показатель 10 и меньше, то это говорит о высоком уровне использования ресурсов CPU. Эффект будет заметен, только в некоторых специально спроектированных приложениях.
Безопасность	БД должна защищать свои данные от несанкционированного или ошибочного использования.	Использование различных стратегий безопасности.	Объектные СУБД, как правило, имеют средства аутентификации пользователей. В некоторых из них не сложно реализовать более сложные стратегии, например, метки безопасности. На наш взгляд большей безопасностью будут обладать приложения активных СУБД. В целом, необходимо признать, что в объектных СУБД и их приложениях механизмы безопасности еще не так развиты как в реляционных, что объясняется меньшим сроком пребывания их на рынке и спецификой областей их использования, где требования к безопасности не столь высоки.
Примеры В активных СУБД, например, Jasmine, у которых методы хранятся и выполняются на сервере, минимизируется пересылка информации по сети. Следовательно, уменьшается вероятность искажения информации при передаче, а конфиденциальная информация, при соответствующей организации системы, может вообще не передаваться по сети. Сервер защитить проще, чем всю ИС. Аутентификация пользователей может производиться дважды: сперва при запросе ими на использование того или иного метода, а затем при обращении к данным.

Теперь рассмотрим четвертую группу параметров объектных СУБД, которые связаны с особенностями программирования интерфейса приложений (Application Progamming Interface или сокращенно - API) и получим новые критерии оценок (Таблица 5).

Таблица 5. Критерии оценки объектных СУБД, основанные на особенностях API

Оцениваемый параметр	Описание	Критерии оценки	Влияние на характеристики СУБД их приложений
Языки определения и манипулирования данными	Язык определения данных (Data Definition Language) служит для описания схемы БД. Язык манипулирования данными (Data Manipulation Language) служит для организации доступа к данным.	Близость между языками определения и манипулирования данными.	Упрощается разработка приложений. Сторонники реляционных СУБД видят в этом потенциальную угрозу целостности БД.
		Поддержка нескольких языков программирования: C++, Smaltalk и др. или их расширений.	Упрощает использование объектных СУБД для создания приложений командами программистов, владеющими тем или иным объектным языком программирования и перенос существующего задела в среду объектной СУБД.
		SQL - совместимость.	Основные объектные СУБД поддерживают SQL или подобные ему средства доступа к данным, что обеспечивает совместимость объектных и реляционных СУБД и облегчает переход пользователей реляционных СУБД на новые технологии.
Вычислительная полнота	Способность языка БД своими собственными средствами решать все вычислительные задачи.	Степень обладания вычислительной полнотой.	Традиционные языки запросов, такие как SQL, не обладают вычислительной полнотой и должны встраиваться в стандартные языки, на которых реализуются приложения. Языки объектных СУБД обладают вычислительной полнотой, что приводит к более простым и эффективным прогаммным решениям.
Стиль языка	Использование тех или иных механизмов для доступа к данным.	Степень интеграции языка БД со стандартным языком программирования.	Особенности программной реализации приложений. Полная совместимость со стандартным языком, например, как это реализовано в СУБД Object Store, компании Object Design Inc., безусловно упрощает разработку приложений, однако, при этом не всегда удается достичь максимальной производительности системы..
Независимость данных	Способность изменять схему БД без нарушения доступа к данным со стороны приложения.	Различные способы поддержания независимости данных: инкапсуляция и поддержка производных атрибутов.	Желательно, чтобы поддерживались оба этих способа.
Примеры Производные атрибуты поддерживаются языком Eiffel, а, следовательно, и СУБД, язык которой совместим с ним, например, СУБД VERSANT.
Поддержка стандартов	Спецификации интерфейса БД должны удовлетворять стандартам, выработанным группой разработчиков объектных СУБД Object Database Management Group (ODMG).	Близость интерфейса СУБД положениям стандарта ODMG-93.	Свободное перемещение приложений в среду других объектных СУБД. Производители объектных СУБД не в полной мере выполняют рекомендации стандарта, что является одной из причин тормозящих их проникновение на рынок СУБД. По мнению различных экспертов требованиям стандарта наиболее полно удовлетворяет СУБД Objectivity компании Objectivity/DB.

Теперь рассмотрим последнюю группу параметров объектных СУБД, которые связаны с особенностями организации запросов и получим новые критерии для оценок (Таблица 6).

Таблица 6. Критерии оценки объектных СУБД, основанные на особенностях запросов.

Оцениваемый параметр	Описание	Критерии оценки	Влияние на характеристики СУБД их приложений
Ассоциативные запросы	Возможность обращения к данным без необходимости явно программировать пути доступа к ним.	Поддержка объектных расширений SQL - запросов.	Расширение возможностей SQL - запросов: возможность выборки из коллекции разнородных объектов по различным критериям, произвольный тип результата запроса (значение, объект, коллекция объектов), генерация отчетов в виде текстов и т.д.
Устойчивость к ошибкам (Impedance Mismatch)	Независимость данных и исключение их ошибочного искажения прикладными программами.	Поддержка специальных процедур обеспечивающих независимость данных.	Если в реляционной СУБД независимость достигается тем, что язык манипулирования данными (например, SQL) и язык приложений (например, C) совершенно отличны, то в объектных они одинаковые и необходимо использовать специальные методы поддержания независимости данных: использование поисковых процедур в сохраняемых классах, поддержка объектных расширений SQL - запросов и т.д.
Вызов запросов и обращение к методам	Приложения должны иметь возможность вызова запросов, а также обращения к методам.	Наличие средств просмотра и анализа вызванных ранее запросов (ad hoc query invocation).	Повышает эффективность приложений, например, путем кэширования поисковых запросов и соответствующим им результатов поиска.
Пример Подобные механизмы реализованы в созданной на основе СУБД VERSANT системе позволяющей реализовать эффективный доступ к ИНТЕРНЕТу через медленные каналы связи.

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

Критерии влияющие на эффективность разработки приложений

Результаты анализа этой группы параметров обобщены в Таблице 7.

Таблица 7. Критерии оценки объектных СУБД, основанные на особенностях разработки приложений.

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

Смешанные критерии оценки

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

Учет этих параметров в перву очередь необходим, чтобы обеспечить эффективное вложение средств в новый продукт и гарантировать сделанные инвестиции.

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

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

Нам хотелось лишь выявить дополнительные критерии оценок объектных СУБД, чтобы читатель обязательно учитывал их в том случае, если перед ним встанет задача выбора СУБД для создания КИС.

Результаты анализа сведены в Таблицу 8.

Таблица 8. Критерии оценки объектных СУБД, основанные на смешанных показателях .

Оцениваемый параметр	Критерии оценки	Влияние на характеристики СУБД и их приложений
Зрелость компании-поставщика СУБД	1. Размер компании и время работы на рынке. 2. Существующий опыт компании и опыт ее персонала в области СУБД. 3. Финансовая стабильность. 4. Доход компании. 5. Динамика прироста дохода. 6. Отношение дохода к общему количеству служащих компании и динамика этого показателя.	Качественное и долговременное сопровождение программного продукта, гарантии сохранения инвестиций. Высокая динамика прироста капитала в ряде случаев важнее его размера, она говорит об успехе компании на рынке. Высокая величина отношения дохода к количеству служащих говорит о высокой эффективности управления компанией.
Маркетинговая политика компании	1. Стратегия продажи продуктов: ориентация на конечных пользователей или на компании интегрирующие СУБД в свои продукты (системные интеграторы, VAR и т.д.). 2. Общее количество контрактов на поставку продукции. 3. Общее количество проданных лицензий на продукты компании. 4. Специализация в некоторых выбранных областях или стремление охватить наиболее широкий сегмент рынка СУБД.	Необходимо выбирать компанию, маркетинговая политика которой более близка Вашим интересам. При этом следует учесть, что компании реализующие свои продукты через системных интеграторов могут иметь мало прямых контрактов, но большое число проданных лицензий. Компании заявляющие о высокой универсальности своих решений должны в полной мере сочетать хорошие технические характеристики своих продуктов с большими финансовыми возможностями и иметь большой опыт работы на рынке.
Зрелость продукта	1. Время существования продукта на рынке. 2. Количество новых версий, динамика их появления, полнота учета новых требований (стандарты, форматы, интерфейсные возможности и т.д.) 3. Оценка продукта пользователями. 4. Общее количество и особенности разработанных приложений. 5. Количество и особенности приложений ставших самостоятельными коммерческими продуктами.	Следует выбирать СУБД хорошо зарекомендовавшую себя на рынке. При этом следует учесть на сколько динамично и качественно компания-поставщик отслеживает новые тенденции в развитии программного обеспечения. Если СУБД планируется использовать для разработки самостоятельного коммерческого продукта, то следует проанализировать имеющийся опыт использования данной СУБД для таких целей в конкретной области. Анализ должен включать как полученные технические характеристики, так и организационно-экономические: затраты на разработку, трудоемкость разработки, квалификация разработчиков, затраты на маркетинг готового продукта, время на освоение рынка, объемы продаж и т.д.
Полнота технической документации	Ясность, последовательность изложения, полнота документации, наличие исчерпывающих примеров.	Сокращает время на освоение СУБД, повышает эффективность разработки приложений.
Система обучения	1. Наличие многоуровневой системы обучения. 2. Удобное территориальное расположение учебных центров. 3. Наличие у компании партнеров, имеющих собственные учебные центры.	Сокращает время на проектирование приложений и последующее внедрение ИС. Возможность получить консультацию и обучить специалистов у компании имеющей опыт самостоятельного использования СУБД в конкретной области.
Сопровождение и консультации	Наличие высококвалифицированных консультантов, к которым можно обратиться в любое время суток по телефону или по электронной почте.	Сокращает время на освоение СУБД, повышает эффективность разработки приложений.
Участие компании-поставщика СУБД в выработке стандартов в области объектных языков программирования, CASE-средств, открытых систем, протоколов обмена данными и т.д.	1. Участие в организациях: OMG, ODMG. 2. Участие в работе над выработкой стандартов ANSI, PCTE, CDIF, PDES/STEP и др.	Указывает на то, что СУБД будет отражать все последние требования принятых стандартов и существующих тенденций в стандартизации.
Стоимость лицензий на отдельные компоненты БД	1. Стоимость рабочего места разработчика. 2. Стоимость сервера БД с учет ценовой политики учета количества пользователей (ограничивается число одновременно подключеных пользователей или общее количество пользователей, количество пользователей не ограничивается и т.п.) 3. Стоимость клиентских рабочих мест. 4. Стоимость специальных утилит. 5. Возможность бесплатного получения оценочной версии продукта и технической документации. 6. Стоимость сопровождения с учетом того какие именно услуги оно предполагает. 7. Стоимость обучения. 8. Наличие и величина скидок на продукты приобретаемые в последствии. 9. Величина и условия предоставления диллерских, ресселеровских и прочих скидок, связанных с заключением партнерских соглашений.	Важные показатели, которые во многом влияют на принятие окончательного решения о приобретении той или иной СУБД. На наш взгляд, предпочтительны те продукты, которые можно покупать именно в той конфигурации, которая Вам необходима. Так как ценовая политика компании часто меняется, то предложить более подробные рекомендации трудно. Можно лишь отметить, что стабильность ценовой политики, условий и размеров различных скидок на приобретаемый продукт говорит о стабильном положении на рынке как самого продукта, так и компании в целом. Это же в полной мере относится, а иногда более сильно заметно в том случае, когда Вы ведете переговоры о приобретении СУБД с диллером компании-поставщика.

Оценка производительности приложений объектных СУБД

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

Выделим те параметры по которым стоит в первую очередь оценивать производительность:

1. Время доступа к распределенным данным и скорость выполнения гетерогенных операций (именно эти показатели часто имеют в виду пользователи, когда говорят о хорошей масштабируемости ИС);
2. Время чтения объектов;
3. Время перехода по ссылке от одного объекта к другому;
4. Время обновления объектов;
5. Время выполнения методов;
6. Время выполнения запросов.

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

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

При проведении пользовательского тестирования мы рекомендуем обратить внимание на следующее:

1. Схема БД должна быть правильно спроектирована и полностью отражать особенности проектируемого приложения;
2. Выбрана адекватная схема управления транзакциями;
3. Учтено реальное количество одновременно работающих пользователей ИС;
4. Выбрана адекватная топологогия компьютерной сети;
5. Проверено функционирование БД на реальных объемах информации;
6. Проведен аналих производительности во времени: она не должна заметно ухудшаться при достаточно долгой эксплуатации.

Для того, чтобы читатель составил наиболее полное представление о коммерческих СУБД мы приведем ниже данных об основных представленных на рынке продуктах и их поставщиках, дадим их адреса в ИНТЕРНЕТе, а также те сферы деятельности, в которых они добились наибольшего успеха (Таблица 9).

Здесь же Вы найдете информацию о поддерживаемых платформах.

Таблица 9. Основные коммерческие объектные СУБД.

Компания- разработчик	Название СУБД, номер последней версии	Поддерживае- мые языки	Платформы	Области применения
Objectivity/DB www.objy.com	Objectivity 5.0	C++, Java, Smalltalk	DEC, Sun4/SPARC, VAX, HP 9000, IBM RISC System/6000, Silicon Graphics, NCR System.	Моделирование, САПР, обработка изображений, физика
ONTOS, Inc www.ontos.com	ONTOS DB 2.5	C++, VisualBasic, Java	IBM RISC System/6000, IBM PC, HP 9000, SCO 386, Sun4/SPARC.	САПР, управление производством
Versant Object Technology www.versant.com	Versant, Release 5	C++, Java, Small-talk	Sun4/SPARC, IBM RISC System/6000, HP 9000, DEC, Sequent, IBM PC, Silicon Graphics, NeXT.	Моделирование, САПР, обработка изображений, имитационное моделирование
ObjectDesign, Inc. Www.odi.com	ObjectStore, 5.0	C++, Java	Sun, HP, DEC, NCR, Univel, Olivetti, IBM RISC System/6000, Silicon Graphics, IBM PC.	Моделирование, САПР, CASE, обработка изображений
Gemstone, Inc. Www.gemstone.com	Gemstone, 5.0	Small-talk, Java	Sun4/SPARC, IBM RISC System/6000, HP 9000, DEC, Sequent.	Моделирование, САПР, CASE, телекоммуникации
POET Software GmbH www.poet.com	POET, 5.0	C++, Java, VisualBasic	Windows NT 3.51, Os/2 Warp, Novell Netware, Macintosh 68K, PowerPC, Sun Solaris, HP-UX, IBM AIX, SCO, SGI IRIX 5.3	Управление производством, автоматизация офисной деятельности
Ardent Software; www. o2tech.com	O2, 5.0	C++, Java, Smalltalk	Нет данных	Моделирование, САПР, CASE, управление производством, телекоммуникации
Ibex Computing, Inc www.iprolink.com\ibexcom	Itasca, 5.0	Lisp, CLOS, C++, C	HP-UX, Sun Solaris,, Windows NT 4.0, Digital UNIX, SGI, AIX, клиентская часть в Windows 95, Windows NT	Моделирование, САПР, телекоммуникации
Computer Associates , Inc. www.cai.com	Jasmine, 1.1	C++, C, Java, VisualBasic	Sun Solaris, HP-UX, DEC, IBM RISC System/6000,Windows NT 4.0	Обработка изображений, телекоммуникации, электронная коммерция
НПЦ "Интелтек Плюс" www.inteltec.ru	ODB-Jupiter, 3.0	C++	Windows 3.x/95, Windows NT 4.0	Автоматизация офисной деятельности, образование

Примеры выбора объектной СУБД на практике

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

Таблица 10. Обзор критериев оценки СУБД на практике

п/п	Название приложения (Компания разработчик)	Почему выбрана объектная СУБД	По каким критериям выбран VERSANT	Особенности разработанного приложения
1	Система заказа билетов компании Air France. (Sabre Decision Technologies).	1. Простота переноса созданного ранее ПО на объектную модель. 2. Информация, хранящаяся в БД не сложная, однако, она очень сложно связана. 3. Необходимость обработки огромного числа транзакций и сообщений в реальном времени.	1. Высокая производительность, основанная на объектном уровне блокировок и эффективном кэшировании объектов. 2. Гибкость. 3. Надежность. 4. Масштабируемость.	Система состоит из 6 БД VERSANT, установленных на многоплатформенных рабочих станциях UNIX. Язык C++. Трудоемкость разработки 24 человеко-года. Разработано 28 классов, состоящих из более 7 миллионов объектов. Время внедрения системы - около 6 месяцев.
2	Распределенная информационная система для здравоохранения. (Health Object Corporation).	1. Необходимость сохранять в единой распределенной системе разнородную информацию. 2. Выбор объектного языка Smaltalk как инструмента разработки. 3. Недостаточная производительность реляционных СУБД при хранении в них процедур и сложносвязанных данных.	1. Высокая производительность в глобальных сетях WAN?. 2. Масштабируемость. 3. Поддержка сложносвязанных данных. 4. Естественная поддержка Smaltakt. 5. Оптимизация блокировок объектов. 6. Поддержка широкого спектра периферийных устройств.	Система состоит из более 100 рабочих станций. Операционная система Windows NT.
3	GALERiE, MAiSTRO, TWiST - системы хранения, поиска и администрирования мультимедийных данных в гетерогенных вычислительных сетях. (DALiM).	1. Необходимость хранить и управлять потоками мультимедийных данных. 2. Необходимость создать универсальное ядро системы управления мультимедийными данными с возможностью его гибкой настройки для учета специфики конкретного клиента. 3. Выбор языка C++ как средства разработки.	1. Масштабируемость: возможность хранить разные компоненты БД на разных машинах, а также переносить их. 2. Многопроцессорная обработка данных. 3. Поддержка большого числа программных платформ.	Широкие возможности поиска мультимедийной информации как в ИНТЕРНЕТе, так и в других компьютерных сетях с последующей загрузкой информации в БД. Управление процессами и ресурсами при создании графических образов и выводе их на печать. Создано 150 классов объектов. Управление мультимедийными БД объемом до 12 Тбайт.
4	Media Vault - средство для хранения, поиска и просмотра видеоинформации в распределенных информационных системах. (Electronic Data Systems).	1. Необходимость хранения и индексирования сложной информации. 2. Гибкость модели представления данных.	1. Полная поддержка языка C++. 2. Поддержка различных платформ. 3. Поддержка протокола TCP/IP и архитектур распределенных БД. 4. Сбалансированная клиент/серверная архитектура. Наиболее полное использование ресурсов сервера, минимизация трафика сети.	Базовый продукт разработан за 6 месяцев, развивается и совершенствуется более 2 лет. Применяется как в ИНТЕРНЕТе, так и в закрытых корпоративных компьютерных сетях. Объем мультимедийной информации более 257 Гбайт, доступ с 32 рабочих станций, находящихся в различных городах США. Применяется в сети Sprint.
5	SONET - система система управления телекоммуника- ционной сетью стандарта 1320NM. (Alcatel Network Management).	1. Распределенная модель представмодель предсавления информации. 2. Высокие требования к производительности, способность поддержать требуемый трафик сети.	1. Управление распределенными транзакциями (2-х фазный механизм передачи). 2. Высокая отказоустойчивость сервера БД. 3. Наличие интегрированного средства уведомления о событиях (integral event notification facility). 4. Поддержка многопроцессорных архитектур. 5. Масштабируемость.	Время разработки - 1 год. Реализовано на платформе рабочей станции HP7000, ОС HP-UXV 9.0. Разработанное ПО легко совместимо с новыми телекоммуника- ционными технологиями и аппаратурой различных производителей.
6	Система для управления сетью сотовой связи. (Mobile Systems, International).	1. Объектная модель представления данных идеально подходит для данной предметной области. 2. Одной из основных функций системы являлось объектное моделирование сети и, как следствие, необходимость хранение моделей в БД. 3. Необходимость поддержки версионности и высокие требования к гибкости проектирования.	1. Активная СУБД: возможность сохранять объекты и их методы. 2. Блокировка на уровне объектов, что позволяет достичь больших возможностей для параллельного проектирования и поддержки версионности. 3. Высокие характеристики надежности. 4. Масштабируемость.	Реализовано более 600 классов, из которых 150 являются сохраняемыми. Платформы Sun и HP.
7	Репозитарий объектов для телекоммуника- ционной САПР. (Ameritech, Inc.)	1. Возможность хранить трехмерные образы объектов. 2. Необходимость использования при проектировании операций наследования и инкапсуляциию 3. Необходимость хранения сложносвязанной информации. 4. Необходимость объектного моделирования сети.	1. Большие возможности распределенной обработки, что позволяет максимально использовать преимущества клиент/сервер. 2. Наличие удобной среды разработки приложений.	Высокая скорость разработки прикладных программ при помощи созданной САПР. Платформы Sun, Windows, Macintosh.
8	SLATE - система поддержки автоматизированного проектирования. (TD Technologies, Inc.).	1. Объектный подход к решению задач проектирования. 2. Высокие требования к производительности системы. 3. Необходимость поддержки механизма длинных транзакций. 4. Поддержка высокоэффективных механизмов распределенного проектирования.	1. Блокировка на уровне объектов. 2. Поддержка механизма длинных транзакций, обеспечение безопасности информации на клиентских местах в случае отказа системы. 3. Высокая производительность: использование СУБД VERSANT вместо применяемой ранее СУБД Ingres Компании Computer Associates позволило увеличить производительность в 2 - 4 раза.	Динамическая многопользовательская система управлять разработкой на всех стадиях разработки изделия. Использование объектной парадигмы позволяет легко настроиться на любую область инженерии - от разработки двигателей внутреннего сгорания до создания программного обеспечения, учитывая при этом другие требования не технического характера, такие как нормативные документы, экономические аспекты и т.д. Платформы Sun, HP.

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

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

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

Методика выбора объектной СУБД

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

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

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

Основные шаги направленные на выбор объектной СУБД нам представляются следующими:

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

Литература

1. Г. Буч Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд./Пер. с англ. - М.: "Издательство Бином", Спб: "Невский диалект", 1998г.
2. Object Management Group. Object Management Architecture Guide. - 1992.
3. А.М. Андреев, Д.В. Березкин, Ю.А. Кантонистов. Объектная СУБД Jasmine: широкие возможности построения приложений // PC WEEK, 37, 1998. - с. 10 - 11.
4. Аткинсон и др. Манифест систем объектно-ориентированных баз данных// СУБД, 1995, №4. - с. 142 - 155.
5. А.М. Андреев, Д.В. Березкин, Ю.А. Кантонистов. Среда и хранилище: ООБД// Мир ПК, №4, 1998. - с.74 - 81.
6. Вон Ким. Объектно-ориентированные базы данных//Открытые системы, № 4,1994.
7. А.М. Андреев, Д.В. Березкин, Ю.А. Кантонистов, Ю.М. Смирнов. Объектно-ориентированная база данных "ODB-Jupiter" // Изв. ВУЗов. Приборостроение, Т.41, № 1 - 2, 1998. - с. 40 - 56.