Продолжая публикацию архивных материалов, предлагаем вашему вниманию статью из № 40 (255) «Компьютерного Обозрения» от 18 октября 2000 г. Материал, который задумывался как краткое введение в технологию объектно-ориентированных СУБД...
Даже сравнительно небольшой промежуток времени, истраченный с пользой для дела, может коренным образом повлиять на само дело. В случае с этой статьей именно так и случилось — изначально задуманная как краткое введение в технологию объектно-ориентированных СУБД (Систем Управления Базами Данных), за неполные две недели она неузнаваемо изменилась. Скрытая взаимосвязь самых, казалось бы, различных фрагментов современных масштабных программных систем сводит на нет все попытки «узнавания целой картины по отдельным мозаикам».
ДАВНЫМ-ДАВНО...
К концу 60-х годов программная индустрия нарастила достаточные «мускулы» и приобрела практический опыт, необходимые для создания высокоуровневых систем. Остающиеся популярными языки программирования Cobol и Fortran прекрасно соответствовали (и соответствуют по сей день) требованиям разработчиков ПО из двух основных «отраслей производства программ» — бизнеса и науки. Казалось бы, приблизился «момент истины», в который весь накопленный алгоритмический и программный потенциал реализуется в мощных, надежных, долгоживущих и одновременно сложных программных комплексах. Но... Именно в это время проявился «капризный характер основного сырья» информационной индустрии — данных.
Для абстракций оказалось очень непросто придумать «склады» и способы учета. Первые попытки «складирования» заканчивались созданием зависимых от самих данных программ, актуальность которых утрачивалась синхронно со старением информации. «Достижения» этого периода подтолкнули и теоретиков computer science, и производителей ПО к необходимости разработки более или менее универсальных механизмов представления и хранения «данных вообще».
Первой моделью «склада данных», характеризующейся достаточной степенью общности, мы обязаны обладателю престижнейшей премии Алана Тьюринга Чарльзу Уильяму Бахману (C. W. Bachman). Настоящий ветеран компьютинга, активно проработавший «на будущее» более 44 лет, Бахман знаменит как создатель фундамента теории и практики баз данных. С 1960 г. в General Electric он занимался исследованиями и практической реализацией СУБД IDS (Integrated Data Store). Всего за четыре года (фантастически короткий срок, если принять во внимание новизну разработки, низкий уровень технологических средств, «корпоративный масштаб» проекта... из двух человек) IDS была «доведена» до пригодного к продажам состояния и стала первой коммерческой СУБД. Идеологическая основа (более «научно» называемая моделью базы данных) IDS, за которую Бахман заслуженно был удостоен в 1973 г. высшей компьютерной награды ACM, получила название «сетевой» (network).
Практически одновременно с General Electric разработку СУБД вела и IBM в содружестве с будущей не менее знаменитой Rockwell (в начале 60-х она называлась North American Aviation). Детище альянса увидело свет на несколько лет позднее IDS и, несмотря на похожее аббревиатурное название (IMS, Information Management System), ознаменовало новый период в развитии «складов для информации». В IMS применялась иерархическая (hierarchical) модель базы данных.
Обе системы, IDS и IMS, позволяли использовать свои ресурсы из программ, написанных на языках программирования высокого уровня (в первую очередь — Cobol), но только с помощью низкоуровневых интерфейсов. Сама возможность связи прикладных программ и СУБД, естественно, потенциально обеспечивала больше удобств при разработке, сопровождении и модификациях программных систем, но на деле низкоуровневый характер межкомпонентных интерфейсов оставлял весь этот потенциал нереализованным.
«Технологический взрыв» назревал, и в 1970 г. он «прогремел» во всю мощь. Эдгар Кодд (Edgar F. Codd, так же, как и Бахман, награжденный Тьюринговской премией) опубликовал статью, в которой описывалась принципиально новая модель базы данных, идеологически почти идеально соответствующая потребностям одновременно и высокоуровневых разработчиков бизнес-приложений, и программистов-кодировщиков «низкого» уровня. Получившая не совсем удачное название «реляционной» (в конце концов, все модели баз данных строились и строятся на основе понятия «отношение» (relation)) табличная модель базы данных Кодда ознаменовала начало самого продолжительного этапа в развитии «хранилищ информации», длящегося фактически по сей день. Абстракция таблицы прижилась — она оказалась простой и эффективной для большого класса финансовых и деловых задач (а именно в этих областях наиболее широко использовались дорогие мэйнфреймы в 70–80-е годы). «Врожденные способности» самого «бизнес-языка программирования» Cobol манипулировать табличными структурами данных освобождали программистов от необходимости написания низкоуровневых подпрограмм доступа и обеспечивали высокую степень формализации процессов доступа к данным. Наступила «безмятежно-реляционная эпоха» (20 лет по меркам компьютинга — действительно продолжительный срок), лучше всего характеризующаяся знаменитыми и знакомыми всем именами: Oracle, Informix, Ingres, IBM DB2.
Но... безмятежность не бывает абсолютной — очередной «взрыв» рынка рабочих станций, вызвавший бурный рост совершенно новых сегментов рынка ПО (в первую очередь — CAD/CAM/CAE), выявил ранеемалозаметныенедостаткиреляционной модели. На «прокрустово ложе» таблиц прекрасно «укладывались» форм-ориентированные документы финансового мира, но компьютеры перестали быть исключительно его атрибутом. Новые классы задач требовали новых подходов...
ПАРАЛЛЕЛЬНЫЕ МИРЫ
Умышленно вынесенная автором на передний план «панорамы эволюции идей» картина из мира СУБД не должна заслонять остальные, не менее важные события. Параллельно с СУБД развивались и технологии программирования, и операционные системы. Интересно, что «с высоты птичьего полета» количество принципиально важных событий в «параллельных мирах» точно совпадает и равно трем (в «мире СУБД» ими были сетевая, иерархическая и реляционная модели баз данных).
Технология программирования прошла три важнейших этапа — алгоритмический, структурный и объектно-ориентированный (ООП). В алгоритмический период максимальная концентрация сил наблюдалась «на фронте» теоретического обоснования ставших уже примитивными (но не утративших неочевидность) базовых конструкций языков высокого уровня, низкоуровневых алгоритмов и численных математических методов. Второе поколение «технологов» получило достаточно мощный инструментарий, подготовленный алгоритмистами, и смело бросилось «в бой со сложностью» — казалось, что нерешаемых задач больше нет и не будет. Действительность, как всегда, сыграла главную и отрезвляющую роль — «чистый алгоритмический» подход начал давать сбои при проектировании сложных программ. Появилось структурное программирование, в лексиконе разработчиков стали использоваться новые фразы и слова: «архитектура программ», модули, интерфейсы, реализации... Структурное программирование оказалось мощной, достаточно простой и реально работоспособной концепцией — созданные на ее основе программные комплексы на редкость живучи и надежны. Но аппетиты и потребности росли, сложность программ увеличивалась, подготовка квалифицированных программистов становилась все продолжительнее и дороже, а рынок неумолимо требовал сокращения сроков разработки. Попытки «индустриализировать» производство ПО увенчались относительным успехом — выручила на время хорошо забытая и изначально узкоспециализированная технология моделирования дискретных систем, реализованная в конце 60-х годов в языке моделирования Simula (Simulation Language). Претерпевшая косметические терминологические изменения Simula (а также Clos, SmallTalk) «взорвалась», и «ударная волна» этого взрыва разнесла по всему миру необъятное количество бумаги — новые терминология, идеология, технология требовали принципиально новых учебников, новых специалистов. Правда, в отличие от «реляционного аналога», эпоха «ООП всего» не наступила. Возможно потому, что «прокрустово ложе» ООП стало заметно практически сразу — для многих задач абстракции объектов, существующих только на этапе программирования (или, если хотите, только для программиста), оказались явно недостаточными. Объекты «рвались» в «реальный мир»...
Три этапа в развитии операционных систем, несмотря на явную взаимосвязь с технологией программирования (и неявную — с СУБД), в большей степени определялись развитием аппаратного обеспечения ЭВМ и компьютерных коммуникаций. Первый этап пакетной обработки полностью соответствовал как уникальности компьютеров, так и их низкой производительности. Машинное время выделялось только для решения самых важных и «сложных» задач, а скорость вычислений «быстродействующих калькуляторов» не позволяла даже и думать о разделении времени между задачами и пользователями. Рост производительности,сопровождающийся ростом стоимости (вспомните — речь ведь идет о периоде ЭВМ, собранных из дискретных электронных компонентов), заставил разработчиков системного ПО всерьез задуматься об эффективности утилизации ресурсов, стоящих многие миллионы мэйнфреймов. Решения не заставили себя ждать — наступила пора виртуализации. Виртуальное машинное время, подкрепленное виртуальной памятью и свойственным человеку невысоким быстродействием, создавали (и не менее успешно создают) иллюзию непрерывного выполнения сразу нескольких задач в чуть ли не бесконечной оперативной памяти. «Виртуальный период», можно сказать, длится по сей день, но... С развитием глобальных сетей все больший интерес представляет технология распределенной обработки данных, требующая соответствующей поддержки со стороны ОС. Представители «третьего поколения» — сетевые операционные системы, находящиеся в экспериментально-узкоспециализированном состоянии, — пока задают больше вопросов, чем дают ответов или предоставляют возможностей. И главный вопрос — что будет с выполняющейся распределенно задачей в целом при случайном отключении (сбое, утрате связи) одного из вычислительных узлов? Как защитить распределенную вычислительную систему от подобных «фатальных неприятностей» — ведь идеально надежных каналов связи не существует.
ТРИ ПРОБЛЕМЫ
Цифра «три», вероятнее всего, обладает некоей магией. По крайней мере, еще одной «тройки» нам точно не избежать. Конечная цель нашего краткого исторического экскурса — логическое обоснование предпосылок малоизвестного, но очень важного и многообещающего направления в компьютинге.
Итак, несмотря на допущенные упрощения и умышленные историко-технологические упущения (они, естественно, были), продвигаясь по трем различным «путям развития», мы пришли к моменту, в котором и разработчики всех уровней, и пользователи из различных прикладных областей почувствовали тесноту «прокрустова ложа». Возникла необходимость по возможности одновременно решить сразу три проблемы: устранить ограничение «табличного» представления данных в современных СУБД, «овеществить объекты» в ООП-системах и, наконец, обеспечить живучесть «овеществленных объектов» в «неблагоприятной» распределенной вычислительной среде с ненадежными коммуникациями. Естественно, что специалисты из смежных областей компьютинга находили и находят частные решения этих подзадач, но есть и «радикальное средство». Пока это «лекарство», обещающее быть сильнодействующим, почти не выходит за стены лабораторий, но потребность в нем ощущается всеми.
ОРТОГОНАЛЬНАЯ ПЕРСИСТЕНТНОСТЬ (ОП)
Да, ничего не скажешь, термин характерно «лекарственный». Увы, удачные русские эквиваленты фразе «orthogonal persistence» найти трудно, и даже составители специализированных словарей ограничиваются именно такой «фонетической калькой». К счастью, в современной науке за «страшными» терминами кроются вещи относительно несложные и иногда даже хорошо известные.
Ортогональность в этом определении подразумевает «полную взаимную независимость особенностей и возможностей». Такое туманное толкование на деле означает отсутствие необходимости изучения и использования всех особенностей и возможностей некоторой системы в тех случаях, когда для решения задачи с помощью этой системы достаточно только знания/ использования их ограниченного набора. Ортогональность — исключительно важное свойство для всех хорошо спроектированных систем и, в первую очередь, оно характеризует даже не удобство, а более емкую «пригодность к использованию» (usability). К слову, многие популярные технологические средства программирования хронически страдают «неортогональным характером». Так, язык программирования С++ подвергается серьезной и обоснованной критике не столько за сложность языковых конструкций, сколько за их взаимосвязь (что вынуждает программистов расплачиваться за использование той или иной возможности языка знанием всех нюансов «сопутствующих» конструкций).
Персистентность же означает «постоянство существования». Все персистентные объекты обладают общим свойством — они есть всегда (до момента принудительного стороннего уничтожения), вне зависимости от работоспособности аппаратных средств, поддерживающих «существование» этих объектов, каналов связи и прочих, «сторонних» по отношению к самим объектам, факторов. С точки зрения рядового потребителя «плодов информационных технологий», персистентный характер, например, текстового редактора, означает, что создаваемое с его помощью бессмертное литературное произведение не надо периодически сохранять активацией соответствующей команды меню (хотя эта возможность и не исключается), при аппаратных сбоях текст не утратит ни одного символа, а после «перезагрузки» компьютера будет автоматически восстановлено точное и полное состояние программы в момент сбоя.
Объединение двух терминов («ортогональность» и «персистентность») формирует, скажем так, уточненное понятие «постоянства существования»: этим свойством должны обладать все объекты системы (то есть не может быть «чуточку ортогонально персистентных» объектов), и для всех объектов обеспечивающие персистентность механизмы должны быть с точки зрения пользователя/программиста одинаковыми (иначе ни о какой ортогональности и речи быть не может.
Полноценная реализация ОП в рамках объектно-ориентированной технологии и является тем самым «сильнодействующим» лекарством, которое действительно необходимо современным разработчикам. Ортогонально-персистентные объекты уже являются и «овеществленными», так как требование ортогональности заставляет «упрятывать» (инкапсулировать) в объект механизмы управления «постоянством существования», и «живучими» (по определению персистентности). И наконец, они не предъявляют никаких ограничений на форму представления содержания — в них могут храниться и таблицы, и растровые картинки, и 3D-модели, и даже метаданные. Все три «прокрустовых ложа» устранены спомощью одной концепции!
Но... на теоретическом уровне. Практика, увы, особых сюрпризов не приносит. Единственная область, в которой концепция ортогональной персистентности активно развивается и достигла коммерческого уровня, — системы управления базами данных. А именно — объектно-ориентированные СУБД. Пока только они (и несколько исследовательских операционных систем) представляют собой «частную реализацию ОП». В отличие от классических (реляционных), ОО СУБД не навязывают табличного характера данных. Более того, он этим СУБД «абсолютно безразличен».
На уровне объектно-ориентированных языков программирования работа с ОО СУБД практически ничем не отличается от работы с «живущими во время исполнения программы» объектами (хороший пример ортогональности): данные-объекты просто наследуют свойства основного класса ОО СУБД, в который инкапсулированы все необходимые операции с базой данных и скрытая управляющая информация системного характера. Самое важное характерное отличие ОО СУБД — хранение именно объектов, а не содержимого данных, подразумевающее целостность не только самих данных, но и состояний операций, над ними производимых (персистентность).
Спектр существующих реализаций ОО СУБД обширен. Есть так называемые «встраиваемые системы», используемые в качестве программных компонентов в проектах, разрабатываемых на объектно-ориентированных языках программирования (в первую очередь — C++ и Java, например недорогая и популярная система Poet одноименной американской компании, www.poet.com). На более высоком уровне находится система одного из лидеров рынка ОО СУБД — Versant Corporation (www.versant.com/us/index.html). И наконец, «вершиной» функциональной насыщенности можно по праву считать интегрированную систему Jasmine разработки Computer Associates (www.cai.com/products/jasmine.htm), ориентированную на применение в системах электронной коммерции. Создателям Jasmine удалось почти полностью реализовать потенциал ОО СУБД за счет интеграции механизмов ОП с элементами систем «разведки данных» (data mining) — нейронными сетями и Internetинтерфейсами.
В области НИР и НИОКР тема ОП остается актуальной и исключительно интересной. Полноценная реализация ОП, естественно, требует радикальных изменений в теории и практике проектирования операционных систем и языков программирования. С некоторыми достижениями в этих областях можно ознакомиться на сайтах разработчиков ОП ОС Grasshopper (www.psrg.cs.usyd.edu.au/Grasshopper/), Mungi (www.cse.unsw.edu.au/~disy/Mungi/), ядра и системного окружения ОС Brix (www.qzx.com/brix/). Наиболее отважные могут попробовать «на вкус» работоспособную ОС Eros (www.erosos.org) с открытыми исходными текстами.