Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы

Таблица 1. Мифы об объектных СУБД.
Таблица 2. Критерии оценки объектных СУБД, основанные на особенностях модели данных
Таблица 3.
Таблица 4. Основные коммерческие объектные СУБД.
Таблица 5. Обзор критериев оценки СУБД на практике

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

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

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

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

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

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

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

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

Эта тенденция заметна по динамике роста продаж различных СУБД. Безусловно, абсолютные объемы продаж чисто объектных систем ниже, но динамика роста объемов продаж очень высока и по разным оценкам составляет от 45 до 50% в год, в то время как лучшие по этому показателю производители реляционных и объектно-реляционных СУБД достигали в разные годы уровня роста не более 35%. При этом некоторые исследователи прогнозируют темпы роста объектных систем более 50% в год. При сохранении таких темпов роста общий объем продаж объектных СУБД к 2000 году должен по разным оценкам составлять от 1,2 до 1,6 миллиарда долларов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь коротко рассмотрим влияние различных других параметров СУБД на те или иные характеристики. Анализ проведем в различных областях, которые связаны с особенностями архитектуры объектных СУБД, ее функционирования, программирования интерфейса приложений (Application Progamming Interface или сокращенно – API), организации запросов, и разработки приложений. Результаты анализа обобщены в Таблице 3. Более подробный материал по всему рассматриваемому в статье кругу вопросов вы можете найти на WEB-сайтее http://www.inteltec/ru, где мы стараемся оперативно отслеживать всю последнюю информацию в области объектных СУБД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Производители объектных СУБД стараются максимально учесть эти субъективные факторы для чего предусматривается поддержка сразу нескольких объектных языков и языка 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.