Обзор статьи "Extended Relational DBMSs: The Technology, Part 1"
DBMS, vol.10, N 6, June 1997, www.dbmsmag.com

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

Еще до прихода Web большинство производителей РСУБД работало над расширением возможностей СУБД для поддержки более сложных данных и приложений; появление Web приложений потребовало незамедлительного решения этой задачи.

В этой статье рассматриваются требования приложений, которые влияют на расширение функций РСУБД для управления сложными данными. Во второй части статьи, которая должна появиться в июле, будут обсуждаться текущие результаты и планы пяти ведущих производителей РСУБД: Informix Software Inc., IBM Corp., Microsoft Corp., Oracle Corp. и Sybase Inc.

Пользователи всегда хотели иметь унифицированный доступ ко всем данным организации, т.е. иметь возможность интегрированного поиска данных. Однако РСУБД по-настоящему понимали только сильно структурированные алфавитно-цифровые данные. Текст и картинки можно было хранить в виде BLOB'ов (Binary Large OBjects), но сама РСУБД ничего не знала о содержимом этих BLOB'ов. Пользователям приходилось использовать специализированные серверы или встраивать соответствующую обработку в логику самого приложения. Кроме того, усложнилась организация корпоративных информационных систем, в которых стремятся интегрировать функции оперативной системы, склада данных и Web-ориентированной системы.

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

Другим фактором, стимулирующим усилия по расширению РСУБД, является извечное желание повысить продуктивность разработчиков. Одним из связанных с этим аспектов является потребность в едином API (Application Programming Interface) для доступа ко всем данным. Текущий вариант распространенного языка SQL не очень подходит на роль такого API, и в мире объектно-реляционных СУБД питают надежды использовать SQL-3. С другой стороны, компания Microsoft хотела бы видеть в качестве универсального API свой общий объектный интерфейс OLE DB. Другим аспектом, связанным с продуктивностью разработки, является погружение методов моделирования объектов в сам сервер баз данных. Эти методы включают возможность инкапсуляции данных и связанных с ними методов в виде объектов и повторного использования кода на основе наследования и полиморфизма.

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

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

Между этими подходами имеется два ключевых отличия. Первое определяется тем, как и где происходит управление данными. Являются ли данные тесно интегрированными и управляемыми одним сервером баз данных, или же данные слабо интегрированы и управляются несколькими серверами? Второе отличие связано с тем, где происходит оптимизация запросов и насколько она эффективна. Выполняется ли оптимизация сервером баз данных (подход универсального сервера) или же промежуточным программным обеспечением (подход OLE DB)? Хорошая оптимизация особенно важна в среде, в которой данные могут храниться в одной таблице, в нескольких таблицах, в нескольких базах данных или во внешних файлах.

При использовании подхода "универсального сервера" возможности РСУБД расширяются для понимания и хранения сложных данных и управления ими на уровне самого сервера. Этот подход реализуют Informix, IBM и Oracle (Informix Universal Server, IBM DB2 Universal Server и Oracle 8). В будущем компания Sybase собирается добавить ограниченные возможности работы со сложными данными в Sybase SQL Server. Подход предполагает, что все данные физически хранятся в базе данных.

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

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

Другим подходом является использование промежуточного программного обеспечения для координации и выполнения заявок между несколькими разнородными серверами (РСУБД, сервер текстового поиска, система хранения картинок и плоские файлы). Промежуточное программное обеспечение обеспечивает единообразное представление данных, производит глобальную оптимизацию запросов и выполняет глобальное управление транзакциями. В расширенной архитектуре управления данными используются два типа промежуточного программного обеспечения. В обоих типах используется SQL и обеспечиваются драйверы для доступа к каждому поддерживаемому серверу. К первому типу относится промежуточное программное обеспечения баз данных (например, IBM DataJoiner и Sybase OmniConnect), поддерживающее интегрированный доступ к неоднородным данным.

С другой стороны, OLE DB и DCOM компании Microsoft и другие брокеры объектных заявок представляют собой промежуточное программное обеспечение приложений. OLE DB разбивает функции СУБД на компоненты, которые могут выполняться в пространстве промежуточного программного обеспечения или в операционной системе. OLE DB будет внутреннем компонентом операционных систем и серверов Microsoft, что порождает вопрос: а нужны ли будут после этого СУБД как отдельные продукты? Вопрос станет особенно интересным, если SQL-3 не оправдает возлагаемых на него надежд.

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

Подход объектного уровня обеспечивает интегрированное объектное представление и соответствующую функциональность на уровне приложений. Подход включает управление кэшем на стороне клиента, навигацию в пространстве объектов, локальное выполнение функций и локальную оптимизацию запросов. Конечно, для использования этого подхода более пригодны объектные СУБД. При применении же РСУБД должна иметься возможность отображения объектов приложения в объекты базы данных, чтобы реляционные данные могли быть материализованы в виде "родных" объектов Си, Си++, Java и т.д. Преимуществом подхода является более тесная интеграция между менеджером данных и языком разработки приложений и потенциально лучшая производительность. IBM планирует обратиться к подходу объектного уровня в своем проекте объектной среды разработки клиентских приложений. Некоторые черты этого подхода можно найти в Oracle 8. Конечно же, объектный уровень представления данных обеспечивает и OLE DB.

Рассмотрим коротко, каким образом производители расширенных РСУБД удовлетворяют потребности пользователей. Многие, хотя и не все возможности, включены в проект стандарта SQL-3 (см. ниже).

Расширяемая системы типов. Расширенные РСУБД должны поддерживать определяемые пользователями типы данных (UDT - User-Defined Types) на уровне столбцов и строк. UDT уровня столбцов могут быть уточненными или абстрактными. Уточненные типы расширяют существующие базовые типы данных столбцов. В строго типизированной системе пользователю не разрешается прямо сравнивать значения типов с разными именами даже если у них общие базовый тип и длина. Абстрактные типы данных более сложные, со специальными внутренней структурой и атрибутами. Внутренняя структура абстрактного типа данных скрывается от пользователя; выборка данных и манипулирование ими могут производиться на основе набора внешних атрибутов и функций. Абстрактные типы данных определяются с использованием языка SQL или традиционных языков программирования.

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

Коллекции являются конструкторами типов, используемыми для определения коллекций других типов - массивов, списков и множеств. С использованием коллекций можно хранить несколько значений в одном столбце таблицы; в частности, таблица может содержать другую таблицу.

Важным аспектом является наследование, при котором подтипы наследуют атрибуты и поведение своих супертипов.

Определяемые пользователями функции (UDF - User-Defined Functions) служат для определения методов для манипулирования данными и являются важным дополнением к UDT. Расширенная РСУБД должна обладать существенной гибкостью, позволяя UDF возвращать сложные значения (например, таблицы), которыми потом можно манипулировать. Пользователи должны иметь возможность выбора между безопасностью и эффективностью при выполнении функций. Для упрощения процесса разработки приложений должна допускаться перегрузка имен функций.

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

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

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

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

Статья написана на основе отчета компании InfoIT "Object-Relational DBMSs". Полный текст доступен на сервере www.infoit.com