Воплощение идей SQL-99 в ведущих объектно-реляционных серверах баз данных

ОТ ПЕРЕВОДЧИКА

ЧТО ПРОИСХОДИТ С DB2? *

В этой презентации обсуждаются те новые объектно-реляционные возможности, которые были дополнительно введены в системе DB2 Universal Database (UDB) компании IBM. Описываемые возможности включают поддержку структурных типов, объектные ссылки и иерархии типизированных таблиц и представлений. Эти возможности будут рассматриваться здесь с точки зрения проектировщика базы данных или конечного пользователя. Помимо представления доступных в настоящее время функциональных возможностей в DB2 UDB V5.2, которые стали доступными осенью 1998 г., будут обсуждаться также направления предполагаемой эволюции и влияние, которое будет оказывать эта технология на протяжении времени.

ВВЕДЕНИЕ

В течение десятилетия исследователи систем баз данных изучали способы интеграции объектных технологий и технологий баз данных с тем, чтобы поднять уровень абстракции для моделирования информации предметной области, уменьшить несоответствие импеданса между системами типов в базах данных и в современных языках программирования и обеспечить поддержку средствами баз данных управление новыми, возможно, сложными, определяемыми пользователем типами данных. Изучались различные подходы [1], в том числе, добавление свойства сохраняемости (persistence) в объектно-ориентированные языки программирования, разработка совершенно нового класса систем баз данных (объектно-ориентированных систем баз данных), создание объектно-ориентированного программного обеспечения промежуточного слоя для обеспечения объектного уровня программирования над реляционными системами баз данных и расширение самих реляционных систем баз данных встроенными объектными возможностями (объектно-реляционные системы баз данных). Мы убеждены в том, что по ряду практических причин объектно-реляционный подход является наиболее обещающим, по крайней мере, для универсальных приложений. В частности, объектно-реляционный подход очень привлекателен, поскольку он добавляет объектные возможности к системам, испытанным в индустриальном масштабе и уже предоставляющим ряд других ценных продвинутых возможностей (таких как высоко надежные менеджеры памяти, развитые оптимизаторы запросов по критерию стоимости, поддержка бизнес-логики на стороне сервера с помощью ограничений и триггеров и, наконец, масштабируемые параллельные машины обработки запросов).

Система DB2 Universal Database (UDB) компании IBM следует объектно-реляционному подходу. Первые шаги в объектно-реляционном направлении в DB2 были сделаны еще в 1995 году благодаря выпуску DB2 Version 2 for Common Servers. Этот программный продукт предоставил поддержку для различных определяемых пользователем типов, определяемых пользователем функций, двоичных и символьных больших объектов, а также триггеров (все это относится к возможностям, которые названы Стоунбрейкером элементами объектно-реляционной технологии баз данных [6]). В 1997 году IBM выпустила DB2 Universal Database Version 5.0, в которой добавилась поддержка параллельных платформ (например, IBM SP2), и тем самым была создана одна из ранних параллельных объектно-реляционных систем базы данных [3]. В сентябре 1998 года IBM выпустила DB2 UDB Version 5.2. В этой версии в DB2 была добавлена совокупность существенно новых объектно-реляционных возможностей, которые рождались в результате продолжающегося исследовательского проекта в области объектно-реляционного подхода в исследовательском центре IBM Almaden. В этой работе указанные новые возможности DB2 UDB Version 5.2 рассматриваются с позиций проектировщика базы данных и/или пользователя системы.

ОБЪЕКТНО-РЕЛЯЦИОННЫЕ РАСШИРЕНИЯ

DB2 UDB Version 5.2 включает новые средства поддержки в объектно-реляционном языке определения данных (DDL) и в языке манипулирования данными (DML) для следующего набора возможностей моделирования данных и для соответствующих возможностей запросов.

• Иерархии определяемых пользователем структурных типов (т.е., именованных типов с атрибутами) и их подтипов.
• Типизированные таблицы, называемые также «таблицами объектов», с подтаблицами, содержащими экземпляры подтипов.
• Идентификаторы объектов и ссылочные типы для непосредственного моделирования связей вида «одного-ко-многим».
• Типизированные представления (view), называемые также «объектными представлениями», с подпредставлениями (subview), позволяющими иметь дело с экземплярами подтипов.
• Семантические расширения для операторов SELECT, UPDATE, INSERT и DELETE языка SQL системы DB2, обеспечивающие поддержку операций над иерархиями таблиц и представлений.
• Модель авторизации, позволяющая обеспечить защиту информации (включая информацию о типах) в иерархиях таблиц и представлений.
• Выражения путей для навигации по ссылкам в SQL-запросах без необходимости выписывать операции соединения.
• Дополнительные возможности DML для запросов о типе указанного объекта на стадии исполнения и/или для реакции на полученную такую информацию.

Более подробные сведения относительно этих возможностей можно найти в недавнем техническом отчете IBM [2], в котором они обсуждаются как с позиций внешнего пользователя, так и с точки зрения реализации и проектирования систем. Кроме того, эти возможности детально документированы в Справочном руководстве по языку SQL системы DB2 UDB Version 5.2, которое доступно в режиме on-line [5].

КОМУ АДРЕСОВАНА ЭТА ПРЕЗЕНТАЦИЯ

Мы полагаем, что эта презентация будет интересна участникам конференции ACM SIGMOD по нескольким причинам. Во-первых, с выпуском UDB Version 5.2 система DB2 стала обладать комбинацией объектно-реляционных возможностей, которые не присущи (по крайней мере, пока) продуктам других основных поставщиков программного обеспечения реляционных систем баз данных. Когда пишутся эти строки, Oracle еще не поддерживает наследования или иерархии таблиц/представлений, а Informix еще не поддерживает ссылок с выражениями пути или объектных представлений. Поэтому участникам конференции должно быть интересно увидеть, как выглядят и работают вместе эти объектно-ориентированные возможности в объектно-реляционной системе. Во-вторых, поддержка объектных представлений в Version 5.2 является совершенно новым подходом и сама по себе может рассматриваться как новый научный результат. Поэтому этот аспект презентации должен, вероятно, вызвать интерес у исследователей объектно-ориентированных баз данных. Наконец, компания IBM сыграла важную роль, работая вместе с ее коллегами - поставщиками объектно-реляционных программных продуктов, в разработке стандарта SQL-99 (который был известен до совсем недавнего времени как SQL3 [4]) в части объектных расширений языка SQL. Изучение относительно новых объектно-реляционных возможностей Version 5.2, таким образом, - это способ, позволяющий участникам конференции SIGMOD получить конкретное представление о том, что представляют собой возможности SQL-99 в этой области.

В этой презентации предполагается сочетать содержательное обсуждение с демонстрацией системы в реальном времени. Презентация будет иметь технический характер и охватит новые объектно-реляционные возможности DB2 UDB Version 5.2 с позиций языков SQL DDL и DML. Обсуждение с применением проекционной техники будет использоваться для представления каждой из новых возможностей. Каждая такая возможность будет, кроме того, демонстрироваться в процессе этого выступления в реальном времени (с использованием DB2 UDB на платформе Windows NT/IBM ThinkPad) на некотором примере базы данных. В заключение будут подведены итоги тому, какие возможности предоставляет сегодня Version 5.2, и будут обсуждаться будущие направления развития объектно-реляционных возможностей DB2 в рамках разработок Version 6 и Version 7, а также и в дальнейшем.

Литература

РЕАЛИЗАЦИЯ ИДЕЙ SQL-99 *

В этой статье описывается текущая версия INFORMIX Dynamic Server с компонентом Universal Data (INFORMIX IDS/UD) - версия 9.2 или Centaur, сравниваются и противопоставляются функциональные возможности этой версии и стандарта языка SQL-99. В программном продукте IDS/UD поддерживается большинство инноваций нового стандарта, хотя в настоящее время в языке запросов INFORMIX реализуется несколько отличный синтаксис. Помимо этого, в статье анализируется ранний опыт использования объектно-реляционных СУБД (ОРСУБД). По нашему мнению, возникшие при этом трудности указывают на то, что стандарт языка SQL-99 в сегодняшнем его виде может оказаться в значительной степени не релевантным в том смысле, что разработчики не будут использовать его при реализации информационных систем следующего поколения, а поставщики СУБД и их партнеры должны будут обходиться без него в своих программных продуктах.

ВВЕДЕНИЕ

Сервер баз данных IDS/UD Release 9.2 компании INFORMIX реализует большинство возможностей модели данных, стандартизированных в языке SQL-99. В этой презентации приводится обзор указанных функциональных возможностей. Кроме того, кратко описывается, как реализуются две из этих возможностей - расширяемый менеджер языка (extensible language manager) и типы с множеством представлений (multi-representational types).

Интересный урок наших первых двух лет поставок объектно-реляционной СУБД состоял в том, что разработка в стиле SQL-99 выдвигает ряд совершенно иных задач по сравнению с задачами, с которыми приходилось сталкиваться при использовании

SQL-92. Мы подытоживаем эти трудности и утверждаем, что, как они показывают, стандарт языка SQL-99 будет в значительной степени не релевантным потребностям разработчиков систем следующего поколения.

Программный продукт IDS/UD компании INFORMIX

Таблица, приведенная на рис. 1, представляет частичный список интересных возможностей SQL-99, поддерживаемых IDS/UD. Компания INFORMIX была среди первых поставщиков, стремящихся обеспечить расширяемость и объектно-ориентированную модель данных в качестве возможностей СУБД. В то время, когда мы начали разрабатывать эти функциональные возможности, мы сосредоточились, кроме того, на реализации проекта стандарта SQL-3. С тех пор синтаксис стандарта существенно изменился.

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

Используя эти возможности, можно реализовать другие аспекты стандарта, не относящиеся к его ядру, такие как пространственные типы данных и функции SQL/MM (SQL Multi-Media - одна из частей стандарта SQL3. - Прим. пер.), временные расширения. Например, типом данных SQL-99 Period, который представляет фиксированный интервал времени, можно оперировать как с UDT. Для того, чтобы поддерживать эти возможности эффективно, IDS/UD предоставляет интерфейсы, которые позволяют разработчикам расширений осуществлять перегрузку наших сервисов управления данными, таких как сортировка, индексирование, тиражирование данных и т.д.

За рамками стандарта

Сервер баз данных IDS/UD версии 9.2 включает функциональные возможности, которые в нескольких областях выходят за рамки рассматриваемого стандарта. Таким образом, компания INFORMIX работает над тем, чтобы воздействовать на направления развития стандарта. Приведенный ниже список (рис. 2) включает дополнительные, специфические для INFORMIX функциональные возможности.

Примеры реализации

В этом разделе более детально поясняются две возможности: как IDS/UD оперирует с UDR, реализованными на многих языках, и как поддерживаются типы данных сильно изменяющейся длины.

Расширяемость менеджера языков

Разработчики, использующие IDS/UD, могут реализовать расширения, используя ряд процедурных языков: собственный язык хранимых процедур INFORMIX; частично компилируемый, подобный Java, или «С» с помещением результатов компиляции в разделяемую двоичную библиотеку. Для всех этих альтернатив обеспечения расширяемости общим является то, что определяемый пользователем код выполняется в том же самом адресном пространстве памяти, что и процесс СУБД. Благодаря этому достигается оптимальная эффективность, поскольку минимизируются накладные расходы, возникающие, когда ОРСУБД вызывает определяемый пользователем код.

Ранее в процессе проектирования нашего программного продукта мы решили, что для менеджера языков необходим абстрагированный интерфейс, который поддерживал бы пополнение многоязыковой среды. Такой универсальный механизм расширения состоит из набора вызовов процедур, которые должны быть реализованы в «C» и должны обрабатывать передачу аргументов, вызов процедур, возвращаемые значения и исключительные ситуации. Разработчики, интегрирующие полностью среды, подобные Java или Visual Basic, должны также отображать системные вызовы (запросы ресурсов, таких как память, запросы ввода/вывода и управления потоками) в их эквиваленты в IDS/UD.

Этого механизма в общем случае достаточно для того, чтобы связывать библиотеку JAVA.LIB, поставляемую в различных дистрибутивах Java, с адресным пространством СУБД. В нашей первоначальной реализации Java в системе базы данных был принят более ортодоксальный подход - исполнение виртуальной машины Java в собственном адресном пространстве и коммуникации с ней через разделяемую память. Более тесная интеграция обеспечила значительные преимущества в эффективности. Мы используем точно такой же подход в реализации интерфейсов COM на платформе Windows.

Типы с множеством представлений

С управлением типами данных переменной длины связаны некоторые трудные проблемы. Например, одним из типов данных, которыми мы управляем в сервере, является st_polygon из SQL-99/MM. В нашей реализации длины сторон многоугольников, представляющих штаты США и границы территорий, изменяются в диапазоне нескольких порядков. Для хранения данных о границах таких штатов, как Колорадо и Нью-Мехико, имеющих квадратную конфигурацию, требуется лишь 72 байта, в то время как для границ штатов Техас и Мэн может потребоваться до сотен килобайт. В приведенной ниже таблице (рис. 3) представлена гистограмма числа точек на единицу периметра границы (на дуге в 1.4 градуса).

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

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

РЕЛЕВАНТНОСТЬ SQL-99

Стандарт языка релевантен в такой степени, в какой он является полезным и используемым. Под «полезным» мы понимаем ту степень, в какой стандарт справляется с проблемами, для решения которых он предназначен. В данном случае речь идет о мобильности приложений и о предоставлении набора профессиональных инструментальных средств. Под «используемым» мы понимаем, грубо говоря, ту степень, в какой его принимают и следуют ему поставщики программных продуктов и разработчики приложений. В остальной части этой статьи мы покажем, основываясь на нашем раннем опыте, что стандарт SQL-99 не является полезным при создании приложений, которые включают UDT, и не будет широко использоваться.

Наше намерение состоит отнюдь не в том, чтобы преуменьшить достижения SQL-99. Этот стандарт - основательный и строгий документ, продукт больших и целенаправленных усилий. Вполне возможно также, что ОРСУБД могут быть использованы как системы, несколько более общие по сравнению с РСУБД. Например, преимущества SQL-99 - модульность и повторное использование - могут быть отнесены к таким возможностям, как ROW TYPES (строковые типы) и наследование, а также к расширенным типам, определенным в SQL-99/MM.

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

В следующих разделах описывается несколько проблем, с которыми нам пришлось столкнуться при разработке информационных систем с использованием расширяемых СУБД.

Проблема множества расширений

В базах данных SQL-92 схема состоит из совокупности взаимосвязанных таблиц, каждая из которых является набором столбцов. Язык SQL-92 стандартизирует простую систему типов для этих столбцов и множество выражений для языка запросов. Все, что должен знать разработчик, использующий SQL-92, - это проект схемы и несколько сотен страниц учебника по SQL [2,6]. Но в ОРСУБД база данных включает значительно больше типов и функций. Например, расширения для GIS, поставляемые партнерами INFORMIX, включают около пятидесяти типов данных и примерно тысячу функций. Разработчик приложений в стиле SQL-99, использующий расширяемую СУБД, обязан помнить правильное написание идентификатора каждой из этих функций, порядок их аргументов, и в случае, когда несколько функций объединяется в единое выражение запроса, ему необходимо также знать тип возвращаемого значения для каждой функции.

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

В целом ряде коммерческих и исследовательских систем было продемонстрировано, каким образом графические методы могут «узурпировать» значительную часть функциональности языка запросов [1,7]. В этих системах и в инструментальных средствах, подобных INFORMIX-Visionary, интерфейс генерирует запросы и показывает их результаты таким образом, что пользователь не знает о вовлечении в этот процесс выражений на SQL.

Проблема API

Достигнутое в настоящее время состояние развития интерфейсов прикладного программирования (API) предусматривает использование либо подхода с встроенным языком - ESQL/C, встроенный Java (SQLJ Часть 0), либо интерфейса уровня вызовов (Call Level Interface, CLI) - SQL-99/CLI [5], ODBC, JDBC. Любой из этих стилей может быть действительно полезен только тогда, когда система типов СУБД точно соответствует системе типов программы на включающем языке. Это почти всегда имеет место для SQL-92. В прошлом язык SQL был предназначен для встраивания в КОБОЛ или «C» и лишь совсем недавно - в языки четвертого поколения (4GL). Небольшое число исключений (например, тип DECIMAL в SQL не имеет какого-либо очевидного эквивалента в «C») обрабатывается клиентскими библиотеками поставщиков.

Но при использовании SQL-99 программа на включающем языке не может знать типа возвращаемого запросом значения, пока ОРСУБД не выполнит его. Поэтому в среде внешнего языка программирования почти наверняка неизвестно, что делать с теми видами данных, которые возвращаются ОРСУБД. Рассмотрим, например, следующий запрос (рис. 4):

В этом примере агрегат Histogram возвращает сложный тип данных. Первая проблема состоит в том, что определение этого типа данных может изменяться между вызовами запроса. Другими словами, каждый запрос ОРСУБД является динамическим. Эта проблема не возникает для систем, использующих SQL-92, где каждое выражение имеет стандартизованные свойства. Вторая проблема заключается в том, что стандарт языка не специфицирует (да и не должен этого делать) структуры данных нижнего уровня (хотя, в случаях, подобных SQL-99/MM [4], двоичные стандарты пространственных типов данных на самом деле существуют). Этот стандарт в действительности обеспечивает средства отображения или конвертирования объекта на стороне сервера в объект на стороне клиента. Но для поставщиков инструментальных средств, которые должны будут обеспечивать доступ к базе данных, содержащей определяемые пользователем типы с произвольными структурами данных, такое отображение не решает проблему.

Все API стандарта ориентированы на данные (data-centric). Иначе говоря, они разрабатываются таким образом, чтобы управлять значениями данных. Но этого недостаточно для расширяемой СУБД. Для ОРСУБД должен иметься механизм, обеспечивающий полные интерфейсы назад, к среде включающего языка, т.е. средства для манипулирования результирующими объектами запроса на стороне клиента, которые не требуют, чтобы внешней программе априори было известно, каковы будут возвращаемые СУБД результаты.** Более полезным для

ОРСУБД был бы компонентный или ориентированный на объекты API стандарт, а не просто стандарт, ориентированный на данные.

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

Проблема мобильности запросов в SQL-99

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

Эта проблема в большей мере семантическая, чем синтаксическая. Запросы, которые возвращают один результат при одном наборе расширений для обработки текстов, возвращают иные результаты при других наборах расширений, даже если синтаксис запроса идентичен. Например, если для заданной библиотеки медицинских статей при использовании функций расширения одного из поставщиков запрашиваются все статьи, содержащие понятие «гипертония», в течение нескольких секунд может быть выдан неупорядоченный список из 100 статей. При использовании того же самого выражения запроса и расширений другого поставщика в течение одной - двух минут может возвращаться список из 200 статей, упорядоченный по степени их концептуальной релевантности. Никакой из этих ответов не является неправильным.

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

Проблема архитектурных расхождений

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

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

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

НАПРАВЛЕНИЯ РАЗВИТИЯ ИНТЕРФЕЙСОВ СУБД

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

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

ЗАКЛЮЧЕНИЕ

Мы кратко представили, в какой степени INFORMIX поддерживает стандарт языка SQL-99. Программный продукт IDS/UD поддерживает большинство инновационных возможностей SQL-99: типы и функции, определяемые пользователем, объектные возможности такого рода, как наследование и полиморфизм, а также новые возможности языка запросов, например, транзитивное замыкание. Хотя синтаксис, используемый INFORMIX, несколько отличается от синтаксиса стандарта, мы ожидаем, что он весьма быстро приблизится к стандарту.

Литература

ОБЪЕКТНО-РЕЛЯЦИОННАЯ ТЕХНОЛОГИЯ СТАЛА МАГИСТРАЛЬНЫМ НАПРАВЛЕНИЕМ *

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

ВВЕДЕНИЕ

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

Благодаря дополнению объектно-реляционных расширений сервер баз данных Oracle8i может быть расширен разработчиками путем создания их собственных типов данных, специфических для предметной области. Например, можно создать новые типы данных, представляющие заказчиков, портфели ценных бумаг, фотографии или телефонные сети, и таким образом добиться того, чтобы программное обеспечение системы базы данных имело дело с тем же уровнем абстракции, что и принят в данной области приложений. Во многих случаях желательно интегрировать эти новые типы данных области приложений в максимально возможной степени с сервером, так чтобы они интерпретировались на равных со встроенными типами, подобными NUMBER и VARCHAR. При такой интеграции сервер базы данных может быть легко расширен для новых областей приложений.

ОБЪЕКТНО-РЕЛЯЦИОННАЯ ТЕХНОЛОГИЯ ORACLE

Среда расширяемости

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

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

Интерфейсы программирования, которые позволяют расширять различные сервисы, в совокупности называются средой расширяемости.

Эта среда дает возможность создавать основанные на сервере компоненты, называемые картриджами данных. Например, картридж пространственных данных может обеспечить для географической области приложений исчерпывающие функциональные возможности такие, как способность сохранять пространственные данные, выполнять сравнения таких данных по критерию близости/перекрытия, а также интегрировать пространственные данные с сервером путем обеспечения возможности их индексирования. Картриджи данных могут иметь широкий горизонтальный спектр применения (изображения, временные ряды, пространственные данные) или узкую вертикальную направленность (диаграммы трубопроводов, сети или банковские счета). Программный интерфейс картриджей данных является общедоступным и используется также в interMedia (см. ниже).

Система объектных типов

В прошлом приложения сосредотачивались на доступе и обновлении общих данных, которые хранятся в таблицах, образуемых из данных встроенных в SQL типов - INTEGER (целое), NUMBER (число), DATE (дата) и CHAR (символ). В Oracle8i имеется поддержка не только для этих встроенных типов, но также и для новых «объектных» типов данных, в соответствии с семантикой приближающегося стандарта SQL3.

Объектные типы

Объектный тип, в отличие от встроенных типов данных SQL, определяется пользователем и специфицирует как лежащие в его основе сохраняемые (persistent) данные (называемые «атрибутами» объектного типа), так и связанное с ним поведение («методы» объектного типа). Объектные типы используются для расширения возможностей моделирования, обеспечиваемых встроенными типами данных. Объектные типы могут использоваться для того, чтобы лучшим образом моделировать сложные сущности реального мира, связывая атрибуты данных с семантикой поведения.

Метод - это процедура или функция, которая является частью определения объектного типа. Методы могут исполняться в среде исполнения Oracle8i или направляться для исполнения вне ее.

Типы коллекций

Коллекции представляют собой типы данных SQL, которые содержат многие элементы. Каждый элемент или значение в коллекции имеет один и тот же тип данных. В Oracle8i имеются два типа коллекции - VARRAY и вложенные таблицы (Nested Tables). Коллекция типа VARRAY содержит переменное число упорядоченных элементов. Тип данных VARRAY может использоваться как столбец таблицы или как атрибут объектного типа.

При использовании языка SQL в системе Oracle8i может быть создан именованный тип таблицы. Такие типы могут использоваться как вложенные таблицы с тем, чтобы обеспечить семантику неупорядоченной коллекции. Как и в случае с типом VARRAY, тип вложенных таблиц может использоваться в качестве столбца таблицы или атрибута объектного типа.

Типы связей

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

Большие объекты

Oracle8i обеспечивает типы больших объектов (Large Object Type, LOB), которые позволяют справляться с требованиями к хранению изображений, видеоклипов, документов и других таких форм данных. Большие объекты хранятся таким способом, который позволяет оптимизировать использование пространства памяти и обеспечивает эффективный доступ. Более конкретно, большие объекты образуются из локаторов и связанных с ними двоичных или символьных данных. Локаторы LOB хранятся как встроенные вместе с другими столбцами записи таблицы. При этом данные для внутренних LOB (BLOB, CLOB и NCLOB) могут размещаться в отдельной области памяти. Для внешних LOB (BFILE) данные хранятся вне табличного пространства базы данных в файлах операционной системы.

ПОДДЕРЖКА ЯЗЫКА JAVA

Oracle обеспечивает в СУБД встроенную поддержку языка Java. Иначе говоря, Oracle разработал свою собственную виртуальную машину Java (Java VM), которая тесно интегрирована с механизмами базы данных для обеспечения высокой эффективности и масштабируемости. Кроме того, система базы данных встроенным образом поддерживает

JDBC и SQLJ, брокер объектных запросов (Object Request Broker, ORB) и среду EJB (Enterprise JavaBeans). Oracle8i поставляется также с Web-сервером, поэтому система базы данных может служить механизмом приема данных (listener) по каналу связи с протоколом HTTP.

Объектно-реляционные средства обеспечивают более естественный и более производительный способ поддержки структурной непротиворечивости множества Java-классов на прикладном уровне и модели данных на уровне хранения данных. Благодаря интеграции Java с сервером Oracle8i компания Oracle обеспечивает тесную интеграцию между его объектно-реляционными средствами и Java. Это достигается тремя важными способами.

• Экземпляры Java-класса могут храниться как экземпляры объектного типа Oracle.
• Объектно-реляционная схема для сервера может быть отображена в Java-классы.
• Язык Java выбран для реализации методов объектных типов.

ОБЪЕКТНЫЙ КЭШ

Oracle8i поставляется с кэшем на стороне клиента для объектно-реляционных данных с тем, чтобы обеспечить следующие преимущества для приложений.

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

ПРОГРАММНЫЕ ПРОДУКТЫ ORACLE, ОСНОВАННЫЕ НА ОБЪЕКТНО-РЕЛЯЦИОННОЙ ТЕХНОЛОГИИ

interMedia

Приложения, основанные на Internet, требуют продвинутых сервисов управления данными, которые поддерживают развитые типы данных, используемые в каталогах систем электронной коммерции, в корпоративных репозиториях и в других приложениях, использующих развитые среды. Oracle interMedia повышает надежность Oracle8i и способность его поддерживать приложения, нуждающиеся в доступе к изображениям, данным аудио и видео, к данным, указывающим местоположение (location), к текстовым и реляционным данным.

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

interMedia тесно интегрируется с системой баз данных Oracle через посредство среды расширяемости.

5.2. Файловая система Internet

Файловая система Internet - iFS (Internet File System) - компании Oracle позволяет интерпретировать систему управления базами данных таким образом, как будто она является просто совместно используемым сетевым драйвером. Это означает, что пользователи могут хранить файлы и осуществлять выборку из файлов, управляемых СУБД, как будто бы они представляют собой файлы, находящиеся под управлением файлового сервера.

iFS дает возможность представлять реляционные данные, хранимые в таблицах базы данных, как если бы они были файлами и папками, управляемыми сетевым драйвером. Благодаря этому конечные пользователи могут обращаться к файлам и папкам с использованием всего многообразия протоколов iFS и тем самым располагают универсальными возможностями доступа к своим данным. Это означает, что пользователь iFS имеет доступ к одним и тем же своим файлам и папкам с помощью Windows Explorer, какого-либо другого браузера, клиента электронной почты или клиента FTP.

iFS использует объектно-реляционную среду непосредственно и косвенным образом через interMedia для того, чтобы индексировать документы, облегчать их поиск и издавать запросы.

Усовершенствованное управление очередями

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

Усовершенствованное управление очередями Oracle использует объектно-реляционную среду для того, чтобы хранить, запрашивать и формировать информацию из сообщений, которые по существу интерпретируются как непрозрачные объекты.

БЛАГОДАРНОСТИ

Авторы выражают благодарность А. Мендельсону, Кенету Нг, Чин-Хенг Хонгу, группам iFS и AQ, interMedia и SQL, объектной группе и группе по расширяемости за обеспечение возможности использования объектно-реляционной технологии в магистральном потоке приложений.