Продолжается подписка на наши издания! Вы не забыли подписаться?

Построение и оптимизация Java/JDO-приложений на базе объектно-ориентированной СУБД Versant FastObjects

Авторы: Ровдо Алексей Александрович
ЗАО «Софткей»

Введение

История возникновения объектно-ориентированных СУБД

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

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

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

Что же такое особенное предлагает объектный подход? И почему существуют задачи, в которых реляционная модель оказывается неудобной? Причин здесь несколько. Взглянем на типичное приложение, написанное с использованием принципов ООП. Оно состоит из взаимодействующих между собой связанных объектов, которые объединяются в классы и могут содержать атрибуты и методы. При обращении к реляционной базе данных приходится проводить некоторое преобразование табличных реляционных данных в объектные и наоборот. Такое преобразование принято называть объектно-реляционным отображением (object-relational mapping). Говоря по-простому, отдельные атрибуты некоторых объектов отображаются на записи в таблицах реляционной модели. И для нормальной работы такого отображения, так или иначе, приходится вводить в приложение некоторый дополнительный код. Более того, оказывается, что иногда нужно вносить некоторые коррективы и в саму объектную модель, чтобы она лучше совмещалась с возможностями используемой реляционной СУБД.

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

Самой первой коммерческой объектно-ориентироВанной СУБД принято считать разработку компании GemStone Systems, осуществленную в 1983-1984 гг. и выведенную на рынок в 1987 г. Вскоре за ней последовали и другие. Многие из них родились в стенах известнейших университетов и стали своего рода фундаментом для систем следующих поколений.

Разработка и выход первых объектных СУБД сопровождались активными дискуссиями в научном сообществе. И если в начале 80-х ученый мир в основном знакомился с этой технологией, впитывая и переваривая ее основные идеи, то ко второй половине этого десятилетия в нем воцарилась настоящая эйфория. Казалось, что еще чуть-чуть и волна новых объектно-ориентированных решений сметет с рынка только вошедшие в силу реляционные СУБД так же, как они когда-то смели решения CODASYL. В 1988 году прошел организованный университетом Беркли симпозиум разработчиков баз данных, отчет о котором, ставший широко известным под названием «Laguna Beach Report», уже содержал все основные идеи объектно-ориентированных СУБД и объявлял эту линию одной из самых перспективных в отрасли. А в 1989 году на конференции в Киото был принят так называемый «Первый манифест объектно-ориентированных СУБД», безоговорочно отдававший приоритет дальнейшего развития в руки разработчиков объектных СУБД. Тема развития объектного подхода к управлению данными оказалась настолько востребованной, что в составе консорциума Object Management Group в 1991 году была образована специальная группа ODMG для стандартизации отдельных решений по хранению и доступу к объектным данным. В последующем идеи, выработанные этой группой, оказали весьма значительное влияние на становление популярнейшего сегодня языка UML и некоторых других стандартов.

Но к началу 90-х вспыхнувшая в научных кругах эйфория стала постепенно затихать. Оказалось, что для объектных СУБД очень трудно построить такое же простое и полное теоретическое обоснование, которое нашел Кодд для реляционной модели. К тому же, многие практические реализации объектных СУБД в те времена были слишком узко специализированы и ориентировались на постепенно вытесняемый язык Smalltalk вместо активно развивающегося C++, а компании, вложившие средства в разработку систем на базе реляционных решений, просто не желали переучивать людей и переходить на новые технологии. Начались попытки каким-то образом связать объектный подход с реляционным, обеспечив пользователям возможность плавного перехода от одного к другому. Начало и середина 90-х — достаточно сложный для объектных СУБД период. Будучи противопоставлены реляционным решениям, они подвергались множеству нападок и откровенному остракизму, как со стороны основных идеологов индустрии, так и со стороны архитекторов и разработчиков информационных систем. Достаточно вспомнить так называемый «Манифест третьего поколения СУБД», озвученный на конференции ACM SIGMOD в 1990 году Майклом Стоунбрейкером — отцом-основателем системы Illustra, которая дала начало целой ветви так называемых объектно-реляционных СУБД. Но особенно можно отметить «Третий манифест» Кристофера Дейта и Хью Дарвина, впервые озвученный в 1995 году и подробно изложенный в их книге, вышедшей в 1998 году. Теория, активно продвигавшаяся Крисом Дейтом в те годы, практически говорила о том, что право на существование имеет только чистый реляционный подход, а объектно-ориентированные и любые другие системы вполне могут быть представлены в рамках реляционной модели. Забавно, кстати, что и популярнейшие СУБД от Oracle и IBM Дейт считал совсем нереляционными и предлагал отказаться от многих привычных уже вещей, вроде языка SQL.

Но времена великих споров прошли, и, несмотря на их остроту и эмоциональность, сегодня взгляд на эти проблемы стал гораздо более утилитарным. Фактически реляционная и объектная концепции просто примирились между собой и научились сосуществовать. В целом оказалось, что объектные базы данных обладают рядом ограничений, которые не позволяют им стать столь же универсальным инструментом, каким сегодня являются реляционные СУБД. Именно универсальность и применимость практически для любых задач и стали залогом их успешного развития и удержания лидерства на рынке СУБД. Но время показало и другое — всегда были и продолжают развиваться очень разные направления автоматизации человеческой деятельности, предъявляющие самые разные требования к системам хранения данных. Более того, сложность типовых бизнес-задач постоянно растет, что неизбежно сказывается и на структуре и способах организации данных в соответствующих информационных системах, а описанная выше проблема, проявляющаяся на стыке реляционной БД и объектно-ориентированного приложения, постепенно становится все заметнее. Развитие таких объектно-ориентированных языков программирования как Java, C++, C# только еще больше высвечивает этот аспект, вынуждая разработчиков искать хоть какие-то альтернативы реляционным хранилищам. И именно ООСУБД сегодня такие альтернативы предлагают.

Специализированные решения, применяемые в своей "родной стихии", всегда могут дать большую фору любым универсальным системам. Если вы полагаете, что решаемая вами задача несколько выходит за среднестатистические рамки, а выбор технологий разработки, обработки и хранения данных еще не сделан, то расширение вашего кругозора и знакомство с современными ООСУБД вам ничем не повредит и может сыграть очень хорошую службу. Во всем разнообразии нашего мира всегда были и остаются сферы, в которых объектные СУБД чувствуют себя прекрасно и активно развиваются. Примером может служить самая большая в мире база данных SLAC (Stanford Linear Accelerator Center), построенная на базе промышленной ООСУБД. В военной сфере ООСУБД всегда применялись весьма активно. В бионформатике и генетическом анализе им практически нет альтернативы сегодня. Телекоммуникации — достаточно широкая и разнообразная сфера, но в ней также есть сегменты, в которых ООСУБД всегда были сильны и очень популярны. Существуют многочисленные примеры реального использования ООСУБД в названных сферах крупнейшими компаниями — лидерами рынка. Ну а потребительские свойства по мере развития продуктов только улучшаются, и если 10 лет назад это было определенной проблемой ООСУБД, то сегодня нет практических сложностей именно с этой точки зрения.

Семейство ООСУБД Versant FastObjects

........................
"С полным содержанием данной статьи можно ознакомиться в печатной версии журнала"

Copyright © 1994-2016 ООО "К-Пресс"