Объектно-ориентированные vs реляционные

Хотя реляционные базы данных долгие годы остаются абсолютно преобладающей технологией, поиски альтернативных решения не прекращались никогда, и сегодня они становятся особенно актуальны. Но до сих пор многие даже не знают о каких-либо альтернативах — а те, кто о них наслышан, считают это абстрактным баловством, экспериментальными игрушками без особой рыночной перспективы. Lotus Notes/Domino пока остается единственным примером полномасштабной коммерческой нереляционной системы управления данными. Впрочем, после поглощения компании Lotus гигантом IBM, в этом направлении нет существенного технологического прогресса; насильственная адаптация Notes/Domino к собственным технологиям IBM и типовым Web-платформам уже привела к отходу от изначальной идеи — и ничего светлого от будущего ждать не приходится. По всей видимости, собственные структуры данных Lotus вскоре уступят место реляционным форматам DB2. Можно еще вспомнить, как к начале 1990-х, базы данных Jasmine пытались конкурировать с продуктами на основе SQL, и поначалу даже неплохо получалось. К сожалению, авторы вскоре забросили этот проект и перепрофилировали его под еще одну платформу интеграции, так что собственно базы данных остались не у дел. На том все и кончилось.

Но надежда все же есть. Реляционный подход обязан своими успехами традиционному представлению базе данных как способу складирования принципиально статичных сущностей. Такое хранилище преимущественно используется для того, чтобы вытаскивать из него данные и скармливать их какой-нибудь интерактивной оболочке, которая занимается обслуживанием пользовательских запросов. На заре компьютерной эры большинство пользователей знало и воспринимало одну-единственную форму отчета — таблицу (возможно, с довесками в виде типовых диаграмм). Совершенно логично, что базовые структуры выбирались из соображений этой повсеместной необходимости и оптимизировались прежде всего для генерации таблиц. Вся дальнейшая обработка происходила вне СУБД и не влияла на ее функциональность. Потом Ray Ozzie придумал Lotus Notes — первая брешь в реляционной стене. Это уже не просто база данных — а интегрированная система групповой работы, предназначенная прежде всего для обслуживания документооборота, а не только для хранения данных. Упор на совместную работу, параллельная обработка данных, индивидуализация и безопасность коммуникаций требуют принципиально иной парадигмы, устраняющей застарелую слабость реляционных баз данных — недостаточную поддержку модификации данных одновременно в нескольких согласованных потоках. Фокус таким образом смещается от базы данных к приложению, способному комбинировать разношерстные данные прозрачным для пользователя образом.

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

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

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

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

Аналогично, можно указать, что на практике чисто объектной системы хранения не бывает — поскольку реально запись создается как некоторая простая структура (набор полей), а вся логика обработки переносится в формы представления (способ доступа к данным), и хранится отдельно от контента. А значит, ОБД всегда можно спроецировать на РБД, оснащенную подходящими обработчиками событий; так и поступают в реализациях Lotus Notes/Domino, привязанных к IBM DB2.

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

Исходя из всего вышесказанного, возможность роста доли ОБД в технологических решениях для распределенных хранилищ не кажется такой уж призрачной — хотя, скорее всего, речь будет идти о чем-то третьем, отличным как от РБД, так и от ОБД, и сочетающим их сильные стороны. И все же, в пределах сегодняшнего опыта, есть смысл приглядеться к некоторым ходячим предрассудкам.

Предрассудок 1. Структуры данных ОБД совершенно не похожи на таблицы.
На самом деле это не так. Таблицы — такой же объект, как и все остальные, с определенными свойствами и методами, — и любая комбинация таблиц может быть выражена в объектно-ориентированном стиле (динамически) не хуже, чем при использовании SQL (преимущественно статический запрос). Напротив, любую совокупность объектов можно трактовать как таблицу, строки которой соответствуют индивидуальным объектам, а столбцы содержат значения свойств. Например, такая возможность реализована в приложениях Lotus Notes, позволяющих формировать обычные SQL-запросы, основанные на конкретных видах (views) и формах (forms). Если к тому же положить, что методы класса реализованы как поля данных (ссылки на код), отличий от реляционной структуры вообще не остается.

Предрассудок 2. ОБД слишком неудобны для гибкого формирования отчетов.
Это мнение основано на опыте имеющих ОБД — таких как Lotus Notes или Jasmine; однако, отсутствие эффективной реализации вовсе не означает принципиальной невозможности. Разумеется, если нам ничего не нужно, кроме таблиц, придется оснастить ОБД специальными средствами быстрой выборки данных по заданному разрезу — точно так же, как к РБД приходится добавлять средства поддержки документооборота. И все же, с развитием технологий data mining, управления знаниями, многофакторного анализа и семантического моделирования, преимущества объектно-ориентированного подхода становятся очевидными. Вместо пристального разглядывания необъятных таблиц в надежде наткнуться на какие-то закономерности — пользователь сможет видеть лишь компактную общую картину, и развертывать ее по мере необходимости, иерархически, начиная с любого места — и это намного удобнее для гибкой отчетности, чем жесткие и неповоротливые таблицы.

В реальной жизни РБД вовсе не так удобны для пользователя, как пишут в рекламных проспектах. Чтобы построить правильный SQL-запрос для получения удобно организованной нетривиальной выборки из нескольких таблиц — требуется квалифицированный программист. Это вполне подобно тому, как в клиенте Lotus Notes всякий пользователь может легко строить персонализированные виды (views) для (динамического) формирования простых табличных отчетов — но построить вид для более сложных запросов может лишь опытный программист. Хорошо спроектированная ОБД гораздо понятнее, поскольку пользователь имеет дело с естественными свойствами объектов, а не абстрактными полями данных. Но если вдруг пользователю понадобится какая-то нестандартная структура (эффективно связанная с объектами другого типа), переход к ней от уже существующих форматов может оказаться проблематичным. Считается, что в предположении многочисленных нестандартных запросов следует стремиться к нормализации дизайна — но как раз высокая степень нормализации и делает РБД столь недружественными по отношению к пользователю, который начисто теряется в нагромождении взаимосвязанных таблиц, когда никому толком неизвестно, где что лежит. Можно пока только мечтать о настоящей иерархической базе данных, позволяющей динамически формировать структуры — с автоматической подстройкой дисковых форматов по мере необходимости.

Предрассудок 3. ОБД приводят к большим размерам файлов.
В некоторых старых реализациях это действительно так. Общеизвестно, что реляционные системы давно уже ушли от хранения данных в виде плоских таблиц (вроде первых версий формата DBASE, которые приводили к размерам файлов намного превышающим типичный размер файла .nsf в Lotus Notes. Мощности современных компьютеров позволяют на лету сжимать и распаковывать данные — что было совершенно невозможно в старые времена, когда базы данных только начинали вводиться в обиход. Очевидно, размер файлов зависит от сложности данных. Так, статическое поле требует ровно столько места, сколько нужно для хранения соответствующего значения; напротив, элемент документооборота предполагает наличие дополнительной информации о времени модификации, версии, шифровании, цифровой подписи и т. д. В идеале ОБД должна предоставлять полный контроль над тем, что будет храниться, тем самым допуская различные стратегии экономии.

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

Предрассудок 4. ОБД слишком сложны, это затрудняет эффективное управление.
Это как посмотреть. Действительно, РБД используют сравнительно небольшой набор базовых операций — тогда как ОБД требуют особых «драйверов» для каждого типа объектов. Но современные программные продукты в достаточной мере расширяемы — в них предусмотрено добавление внешней функциональности. Следовательно, достаточно реализовать стандартный протокол расширения в ядре ОБД (наряду с минимумом общеупотребительных классов), чтобы любые индивидуализированные решения можно было подключать как внешние компоненты и отключать после использования. В конечном итоге ОБД окажутся существенно быстрее РБД, поскольку время обработки в ОБД меньше зависит от сложности запроса.

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

Предрассудок 5. ОБД хуже масштабируемы по сравнению РБД.
Часто приходится слышать, что ОБД несовместимы с высокой интенсивностью запросов и большим количеством пользователей. Это поверхностное мнение происходит из сравнения несопоставимых сторон ОБД и РБД. В пределах одной и той же функциональности — никаких различий не будет. Так, большинство документооборотных задач на базе РБД выполняется внешними приложениями, которые запрашивают необходимые им данные в РБД. Чтобы сравнить эффективность таких систем с ОБД, надо включать в сравнение и эти внешние приложения. Если же использовать ОБД исключительно как хранилища данных (то есть, не предполагая никакой внутренней обработки), они окажутся ничуть не хуже масштабируемыми, чем РБД. В обоих случаях есть проблемы с доступом к записям большого размера (например, мультимедийным); такие записи, как правило, лучше хранить как отдельно от базы данных, в файловой системе.

Отделение данных от способов их обработки может где-то оказаться полезным — тогда как в других случаях это лишь усложняет дело. В хорошо утроенной (иерархической) базе данных уровень разделения должен быть подвижным, с возможностью адаптации к конкретному приложению и операционной среде.

Предрассудок 6. ОБД когда еще появятся! — а РБД уже здесь и сейчас.
Это серьезный аргумент. Гонка за быстрыми деньгами отвлекает производителей программного обеспечения от инновационных проектов. Однако объективная необходимость заставляет рынок предпочесть больше модульности, единообразия и гибкости — хотя эти требования пока возможно удовлетворить путем расширения традиционных SQL-систем, что делает их все менее похожими на РБД. Продолжаются эксперименты в области технологий работы с данными и знаниями, документооборота и методов совместной работы. Вполне возможно, что прорыв уже совсем рядом — и кто-нибудь из ведущих игроков выбросит на рынок качественно новый продукт, пытаясь захватить перспективную нишу.