Чисто объектные СУБД и проблема выбора

В этот выпуск включены три статьи, относящиеся не просто к проблеме выбора СУБД, но более конкретно: к оценке объектных СУБД (ОСУБД). Почему сейчас и почему именно в рубрике "Директору"?

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

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

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

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

Статьи С. Макклара и Э. Кей приводятся здесь в сокращенном виде. Вместе с тем их полные тексты интересны сами по себе, и желающие смогут их найти по адресу www.osp.ru/cio - там же, где и материалы предыдущих выпусков рубрики.

Хочу добавить несколько слов к небольшой, но очень полезной статье С. Кузнецова. В целом я разделяю его выводы, однако в отношении одного положения хотел бы представить другую точку зрения. Речь идет об утверждении: "Понятно, что, как правило, данные, хранящиеся во внешней памяти, никому не нужны без обрабатывающих их программ".

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

Существует масса контрпримеров из практики, показывающих самоценность данных. Например, можно сослаться на случаи, когда приложения отмирали, а накопленные данные (описания фактов) продолжали храниться и использоваться спустя годы и даже десятилетия. Я думаю, что читателям известны реальные ситуации, в которых самоценность данных приводит к необходимости отнюдь не дешевых работ по их переносу для других приложений, либо по их архивации для использования в неопределенном будущем. Это относится к управленческим и производственным данным, равно как и к системам самых разных типов: архивам данных о клиентах и справочным системам, юридическим базам данных и системам поддержки принятия решений, инженерной документации и САПР. Все это связано с простым правилом: "одна прикладная программа может работать с разными коллекциями описаний фактов, а одна коллекция описаний фактов может использоваться как входные данные для разных прикладных программ в одно и то же время или в разные периоды времени". Глубинная же суть дела состоит в том, что одно и то же описание некоторого факта может по-разному восприниматься и использоваться разными интерпретаторами (людьми и программами), в том числе - в зависимости от преследуемых целей.

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

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

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

Кстати, загляните в предыдущий выпуск нашей рубрики: говоря о стратегическом планировании, Боб Льюис вовсе не просто так писал, что даже при использовании объектных методов и инструментов мы продолжаем вести раздельный учет данных и приложений!

А в этот выпуск из всех заметок Льюиса, которые, с точки зрения целей предприятия, можно отнести к тактике, включена та, которая касается СУБД и места информационного уровня в архитектуре планируемой системы. (Вы можете также найти полезные советы Льюиса о тактике планирования ресурсов для разработки системы в Computerworld Россия от 18 августа 1998 года, позже мы хотим поместить его советы о тактике, связанной с делегированием полномочий.)

Касаясь его сегодняшней заметки, замечу, что фразу Льюиса "MIS управляла информацией" надо воспринимать весьма хладнокровно. MIS - это все же "управленческая информационная система", это - прикладная информационная система класса, ориентированного на задачи управленцев предприятия. Поэтому в MIS роль приложений или, по Льюису, "обработки" вряд ли предавалась забвению в такой степени, о которой он пишет.

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

И в заключение комментария хочу напомнить, что все эти "АСУ", "АСУП", "АСУТП" и т.п. являются достаточно хорошо определенными и до сих пор полезными терминами.