1. Введение
В период с 1989 по 1995 гг. авторские группы, включающие известных специалистов в области баз данных, подготовили и опубликовали три документа [1-3], которые отражали точки зрения авторов относительно перспектив развития технологии баз данных. С легкой руки авторов хронологически первого документа эти документы получили название манифестов, что, в общем-то, отражало их суть: в каждом из документов провозглашался набор идей и требований, на которых, по мнению авторов, должны были базироваться системы баз данных следующего поколения.
Интересно отметить различия между коллективами авторов каждого из манифестов. “Манифест систем объектно-ориентированных баз данных” [1] (далее в этой статье для краткости мы будем называть его Первым манифестом) написан академическими исследователями; почти все они являются профессорами различных университетов. Конечно, это нашло свое отражение в стиле Первого манифеста – очень мягком и умеренно рекомендательном (хотя по своему духу предложения этого манифеста были весьма радикальными).
Авторы документа “Системы баз данных третьего поколения: Манифест” (Второго манифеста) являлись представителями индустрии (вернее, индустриально-ориентированных исследований). Второй манифест написан в более жестком стиле и во многом направлен на защиту инвестиций крупных компаний-производителей программного обеспечения SQL-ориентированных СУБД. Конечно, Второй манифест во многом представлял собой реакцию индустрии на революционные предложения Первого манифеста. Эти предложения подвергались критике, но если говорить очень грубо, критика заключалась в том, что, по мнению авторов Второго манифеста, можно добиться аналогичных результатов, не производя революцию в области технологии баз данных, а эволюционно развивая технологию SQL-ориентированных СУБД.
“Третий манифест” (так и будем называть его далее) являлся одновременно наиболее консервативным и наиболее радикальным. Консервативность Третьего манифеста заключается в том, что его авторы всеми силами утверждают необходимость и достаточность использования в системах базах данных следующего поколения классической реляционной модели данных. Радикальность состоит в том, что (a) авторы полностью отрицают подходы, предлагаемые в первых двух манифестах, расценивая их как необоснованные, плохо проработанные, избыточные и даже вредные (за исключением одной общей идеи о потребности обеспечения развитой системы типов); (b) фактически, авторы полностью отбрасывают технологию, созданную индустрией баз данных за последние 25 лет, и предлагают вернуться к истокам реляционной модели данных, т.е. к начальным статьям Э. Кодда [4].
После издания манифестов прошло в среднем около 10 лет. Как кажется автору этой статьи, пришло время оглядеться и оценить, каким образом реально повлияли эти документы на развитие технологии баз данных. Сбылись ли ожидания авторов хотя бы одного из манифестов? Не пора ли придумывать новый манифест, или же время манифестов прошло? В данной статье не делаются попытки заглянуть в будущее (как показывает история, эта задача является неблагодарной и безнадежной). Ограничимся взглядом на недавнее прошлое и настоящее.
В следующих далее трех основных разделах статьи поочередно обсуждаются основные идеи манифестов, и рассматривается их влияние на развитие соответствующих направлений области баз данных. Все приводимые характеристики отражают исключительно личное (и во многом субъективное) мнение автора.
Объектно-ориентированные СУБД
В последнем подразделе этого раздела мы обсудим специфические черты наиболее известных и распространенных в мире ООСУБД. Трудно гарантировать, что это обсуждение полностью соответствует текущему положению дел, поскольку ситуация изменяется очень быстро, и то, что пишется сегодня и полностью отвечает истинному положению дел, может оказаться не совсем (или совсем не) верным завтра. Но, тем не менее, мы считаем, что такой подраздел должен присутствовать в разделе про Первый манифест, чтобы показать читателям реальное (или близкое к реальному) состояние дел в соответствующей области информационной технологии.
Немного истории
В начале 80-х гг. осознание полезности объектно-ориентированного подхода применительно к логической организации баз данных привело к тому, что многие исследователи приступили к созданию ООСУБД. В ранних проектах ООСУБД участвовали группы из университетов и исследовательских институтов, ведущих компьютерных компаний и небольших начинающих компаний.
Университетские исследовательские группы внесли огромный вклад в развитие технологии баз данных, и не только в области реляционных систем. Многие университетские исследователи с энтузиазмом приняли объектно-ориентированный подход, особенно в применении к области человеко-машинных взаимодействий. К наиболее успешным проектам, в которых производились исследования с целью объединения объектно-ориентированного подхода с технологией баз данных, можно отнести следующие:
Encore в Брауновском университете (Broun University );
Cactis вКолорадскомуниверситете (University of Colorado at Boulder);
Thor в Массачусетском технологическом институте (MIT );
Exodus в Висконсинском университете (University of Wisconsin );
Pisa в университетах Глазго и Св. Эндрю (Universities of Glasgo and St. Andrew).
Среди исследовательских институтов, в которых существовали мощные группы, ориентированные на исследования в области объектно-ориентированных баз данных, входили OGI (Oregon Graduate Institute ), MCC (Microelectronics and Computer Technology Corporation ) и французский исследовательский центр INRIA . На базе исследований OGI была создана ООСУБД Gemstone ; исследования, проводившиеся в MCC , привели к созданию ООСУБД Itasca и UniSQL ; в результате исследовательского проекта Altair , выполнявшегося в INRIA , появилась ООСУБД O 2.
Среди наиболее значительных прототипов ООСУБД, созданных в результате исследований, которые проводились в ведущих компьютерных компаниях, можно выделить систему IRIS компании Hewlett -Packard и систему Trellis компании DEC . Идеи и методы, заложенные в этих проектах, были впоследствии использованы в большинстве коммерческих ООСУБД. Тем не менее, руководители крупных компаний решили не производить коммерческие ООСУБД самостоятельно, а предоставить эту возможность начинающим компаниям.
Первыми компаниями, выпустившими на рынок ООСУБД в виде законченных продуктов, были следующие компании:
Grapael сООСУБД G-Base (1986 г);
Servio-Logic сООСУБД Gemstone (1987 г.);
Symbolics сООСУБД Statice (1988 г.);
Ontologic Ltd. сООСУБД Vbase (1988 г.).
Ко всем ранним реализациям ООСУБД применительны следующие замечания.
Системы были почти неприменимы для практического использования, поскольку они очень медленно работали, поддерживали только однопользовательский режим работы и были крайне ненадежны. В них не поддерживались распределенные данные, безопасность и возможность восстановления после сбоев. Почти во всех системах отсутствовали развитые механизмы формулировки запросов. При построении пользовательских интерфейсов не использовались даже уже имевшиеся результаты, полученные группами из области человеко-машинных взаимодействий.
Разработчики практически всех систем полностью игнорировали язык C ++, поскольку считалось, что применение этого языка в контексте ООСУБД вызывает серьезные проблемы. В системах G -Base и Statice использовался Lisp ; Gemstone опиралась на Smalltalk ; для Vbase были разработаны собственные языки определения данных (TDL ) и манипулирования данными (COP ). В исследовательских группах также предпочитали не опираться на C ++, а разрабатывать новые языки, в большей степени соответствующие направлению исследований. Среди отрицательных последствий игнорирования C ++ было то, что пользователей заставляли изучать новый язык; они вынуждались одновременно использовать два языка; отсутствие поддержки C ++ ограничивало рынок ООСУБД.
Новые компании Objectivity , Object Design и Versant , образованные в конце 80-х, ориентировались на создание ООСУБД, которые опирались бы на C ++. Компания Ontologic отказалась от развития Vbase и переключилась на разработку системы ONTOS , основанной на C ++. В Европе были образованы компании O 2Technology и BKS Software . Задачей первой компании было создание коммерческой ООСУБД O2 49 на основе результатов проекта Altair . BKS начала разработку системы POET . В 90-е годы для реализации коммерческих проектов, основанных на результатах MCC , были образованы компании UniSQL 50 и Itasca .
К концу 90-х существовало около десяти компаний, производящих коммерческие продукты, позиционируемые на рынке как ООСУБД. Каждый продукт обладал индивидуальными особенностями, частично определяемыми жизненным опытом разработчиков, но большей частью проистекающими из требований клиентов компании. Далее в этом подразделе мы кратко охарактеризуем наиболее известные коммерческие ООСУБД, а в заключение подраздела опишем современное состояние дел в области ООСУБД (которое, по мнению автора, является совсем не блестящим).
GemStone
Как отмечалось выше, ООСУБД GemStone была одной из первых коммерчески доступных ООСУБД. Система была разработана компанией Servio -Logic совместно с OGI . В исходном варианте системы разработчики GemStone опирались на язык Smalltalk . Хотя в первых выпусках системы ее основной язык назывался Opal , сразу было видно, что в действительности этого всего лишь Smalltalk с поддержкой стабильного хранения объектов, и вскоре название языка было заменено на GemStone Smalltalk . Впоследствии в GemStone была обеспечена поддержка языков C и C ++, но во все времена базовым языком оставался Smalltalk , а все остальные интерфейсы строились поверх базового. И серверная, и клиентская части системы могут работать под управлением всех основных ветвей ОС UNIX и всех развитых вариантов Windows . В настоящее время продукт поддерживается, развивается и распространяется компанией GemStone Systems Inc.
Система основана на трехзвенной архитектуре клиент-сервер, в которой прикладная обработка данных производится на среднем уровне между процессом взаимодействия с пользователем и процессом, поддерживающим хранилище данных. Важность этого подхода состоит в том, что, если в приложении используется много данных, то код приложения целесообразно расположить на стороне хранилища данных, а если в приложении производится много изменений над небольшим объемом данных, то имеет смысл разместить код приложения на стороне пользователя. Тем самым, архитектура позволяет уменьшить объем сетевого трафика без перегрузки сервера, что повышает скорость обработки данных.