Oracle View, October 1997, David Wells, adw@ovum.com
A senior consultant at Ovum, an international technology and telecommunications analyst group
Перевод - Сергей Кузнецов, ЦИТ
После выпуска в июне 1997 г. продукта Oracle8 маркетинговая политика компании ориентирована на улучшенную масштабируемость системы и значение сетевой вычислительной архитектуры (NCA - Network Computing Architecture). Однако Oracle8 обладает существенным набором объектно-реляционных средств, о которых компания говорит несправедливо мало.
Компания обещает предоставить своим пользователям объектно-реляционные возможности с 1992 г. Пятилетняя эволюция серверных продуктов происходила виде компромисса между потребностями рынка и необходимостью переписи частей системы в разумном порядке.
В Oracle6 были внесены изменения в архитектурные компоненты нижнего уровня с целью повышения производительности (например, средства распараллеливания и блокировок уровня записи). В Oracle7 были модифицированы компоненты верхнего уровня с целью внедрения новых функциональных возможностей, таких как хранимые процедуры и двухфазная фиксация распределенных транзакций. Выпущенная в первом квартале 1996 г. версия Oracle 7.3 была первой, которую компания назвала "универсальным сервером", поскольку в этой версии поддерживались улучшенные средства документального поиска (ConText Option) и пространственные типы данных (Spatial Data Option). В теперешний выпуск Oracle8 включены основные архитектурные изменения, затрагивающие не только объектно-реляционные возможности, но также средства копирования и восстановления и новые качества масштабирования для поддержки сверхбольших баз данных.
Общая стратегия компании представляет собой интересную смесь консерватизма и инновации. Прагматический подход Oracle к объектно-реляционной технологии является относительно консервативным, хотя NCA представляет собой одно из первых действительно существенных решений ведущего независимого производителя программного обеспечения. основанного на распределенной объектной технологии CORBA. Кроме того, решение компании об использовании Oracle8 для поддержки репозитория ее собственных средств разработки приложений обеспечивает лучшую среду для проектирования приложений, чем конкурирующие объектно-реляционные системы.
Стратегия Oracle кажется исключительно разумной. Исследования и разработки компании всегда направляются потребностями рынка, а до 1996 г. рынок мало нуждался в объектно-реляционной технологии. В результате, когда Informix и IBM начали в середине 1996 г. воздвигать профиль объектно-реляционной технологии, компания Oracle казалась настроенной строго. Это впечатление подтверждали агрессивные заявления и рекламная деятельность компании. Возникало впечатление, что компания Oracle стремилась дискредитировать конкурирующую технологию, которуя сама компания предложить не могла. Объектно-реляционная технлология, появившаяся в Oracle8, категорически опровергает эту точку зрения.
Oracle по-прежнему полагает, что требования улучшенной масштабируемости не менее важны, чем объектно-реляционная технология, и что хотя требования к последней в настоящее время возрастают, исключительно важно сохранить стоимость перехода на низком уровне.
Кроме того, компания считает, что бизнес-логика не относится исключительно к серверу баз данных; многие компоненты более естественно расположить на сервере приложений. Oracle противопоставляет этот подход сервер-ориентированным архитектурам, предлагаемым в Informix Universal Server и DB2 Universal Database компании IBM.
Принципиальные расширения в поддержке больших объектов и триггеров INSTEAD-OF могут быть лицензированы отдельно от основной части сервера Oracle8 в виде Object Option. Что касается дополнительных встроенных типов данных, то Oracle предлагает четыре расширенных реляционных типа данных: большие объекты с улучшенным управлением содержимым; два вида типов данных коллекции - VARRAY и вложенные таблицы; расширенный тип данных, реализующий указатели.
Два типа коллекций предназначены для поддержки нескалярных доменов. Типы категории VARRAY позволяют хранить массивы в столбцах таблиц; для большинства типов данных Oracle8, включая объектные типы, их значения могут храниться в VARRAY. Ряд ограничений в VARRAY затрудняет их применение в некоторых целях. Например, должен быть объявлен максимальный размер массива, и в настоящее время такие массивы и их содержимое не полностью доступны из SQL (хотя доступ к ним возможен из PL/SQL или кода приложения на 3GL).
Другим типом коллекции являются вложенные таблицы. Как следует из названия, вложенные таблицы позволяют хранить в столбцах табличные значения. В отличие от VARRAY, вложенные таблицы полностью доступны из SQL.
Наконец, имеется расширенный тип данных, реализующий указатели, которые в Oracle8 называются REF. REF реализуются с использованием генерируемых системой объектных идентификаторов; указатели на объекты могут храниться в объектных таблицах, и на основе указателей возможна навигация. Указателями можно манипулировать и производить навигацию из SQL с использованием ключевых слов REF, DEREF и VALUE. Указатели играют важную роль при выполнении операций объектного кэша клиента.
Объектные типы. Система объектных типов Oracle8 позволяет определять и хранить именованные структуры данных, например:
CREATE TYPE customer_type AS OBJECT (
name VARCHAR2 (20),
no_of_purchases NUMBER,
MEMBER FUNCTION get_no_of_purchases RETURN NUMBER);
Любой тип Oracle8 может выступать в качестве члена объектного типа, включая VARRAY, вложенные таблицы и другие объектные типы. В бета-версиях Oracle8 объектные типы назывались "абстрактными типами данных" (термин, используемый в проектах SQL3 и в академических кругах), но позже было решено, что термин "объектные типы" является более понятным и точным. (На самом деле, объектные типы Oracle8 представляют собой обобщение именованных типов строк и абстрактных типов данных SQL3.)
В объектных типах могут определяться методы, реализация которых может быть представлена на PL/SQL или в виде вызовов функций 3GL. Методы похожи на хранимые процедуры и могут вызываться из SQL или PL/SQL для вычисления и получения информации об объектах данного типа и/или их модификации. Каждый объектный тип имеет по меньшей мере один метод - конструктор. Это определенная в системе функция, которая создает объект данного типа. В дополнение к общим методам, при необходимости могут быть реализованы специальные методы, меняющие для объектного типа порядок сортировки и операции сравнения.
Объектные типы можно использовать двумя способами. Во-первых, с использованием объектного типа можно определить объектные таблицы, специфицируя тип таблицы целиком:
CREATE TABLE customers OF customer_type
В этом примере каждая строка результирующей таблицы будет содержать объект типа customer_type с членами-атрибутами, специфицированными при объявлении этого объектного типа (другими словами, "name" и "no_of_purchases"). К каждой строке-объекту Oracle8 добавляет "скрытый" столбец, содержащий генерируемый системой уникальный идентификатор (ID) объекта. Этот ID можно использовать в указателях (REF) на объекты таблицы из других таблиц или реализовывать указатели между объектами этой же таблицы. При желании столбец ID можно индексировать для более быстрого поиска REF.
Во-вторых, объектные типы можно использовать для определения типов столбцов. В этом случае при определении типов столбцов таблицы имена объектных типов помещаются вместо имен базовых типов. Например, объявленный выше тип customer_type можно было бы использовать для определения структурированного столбца "customer" в обычной таблице. Члены такого "объектного столбца" доступны из SQL с использованием расширенной точечной нотации, например, путем выборки my_table.customer.name.
Эти два вида применение объектных типов соответствуют двум способам отображения структурированных объектов в реляционную схему.
Объектный кэш клиента. В Oracle8 также обеспечиваются значительные возможности манипулирования объектами на стороне клиентских приложений. Объектный кэш клиента может быть реализован и доступен для манипулирования с использованием вызовов нового интерфейса OCI (Oracle Call Interface), с применением прекомпилятора C/C++ со встроенным SQL (приобретается отдельно), либо на основе библиотеки классов C++ и среды поддержки времени исполнения, управляемой ожидаемым вскоре продуктом Oracle Object Database Designer (развитие Designer/2000).
С использованием интерфейса уровня OCI объекты из объектных таблиц Oracle8 могут быть загружены в кэш поосле выполнения запроса на расширенном SQL, выбирающего идентификаторы объектов; после этого возможно манипулирование объектами. Все изменения могут быть впоследствии вытолкнуты на сервер. OCI также дает возможность приложению сохранить указатели на другие объекты, которые будут подкачиваться в кэш клиента по мере необходимости. Поддерживается управляемый уровень упреждающего чтения в кэш объектов, на которые ссылается базовый объект. Эта возможность похожа на "листание объектов", которое обеспечивается в некоторых объектных системах баз данных.
Прекомпилятор предоставляет представление более высокого уровня тех же функциональных возможностей, которые предоставляются разработчикам традиционных баз данных. Более детальный интерфейс OCI более подходит для разработчиков приложений.
В Oracle8 обеспечивается компонент Object Type Translator (OTT), который может генерировать соответствующий С-структуры для использования клиентскими приложениями при работе с объектным кэшем.
Поддержка компанией согласованного многоверсионного чтения расширяется на кэшированные объектные данные и позволяет улучшить масштабируемость за счет возможности клиентов объектного кэша работать без запроса блокировок по чтению в базе данных. Каждый клиент кэша видит свою собственную частную версию базы данных в той точке, в которой этот клиент начал манипулировать объектами.
В кэше клиента может поддерживаться несколько нитей (thread), каждая из которых владеет собственной сессией с базой данных и видит частную порцию кэша, соответствующую собственной транзакции нити.
Объектные представления. Oracle8 обеспечивает объектные представления, которые особенно существенны для постепенного перехода к использованию возможностей объектно-реляционного подхода и для новых применений существующих баз данных без изменения их схемы. Объектные представления похожи на традиционные реляционные представления, но в них могут использоваться строгая типизация, сложные структуры (не в первой нормальной форме), методы и возможности ссылок на существующие реляционные данные.
Многотабличные объектные представления могут быть сделаны обновляемыми за счет наличия нового вида триггера INSTEAD OF, который перехватывает команды SQL, направленные на обновление представления, и выполняет соответствующее действие. Осмысленно применять такие триггеры и для того, чтобы сделать обновляемым любое традиционное реляционное представление.
Некоторые простые, но полезные объектные представления являются обновляемыми по своей природе. Например, с помощью объектного представления можно представить таблицу customers, состоящую из нескольких столбцов, каждый из которых содержит фрагмент адреса, как таблицу, к которой один столбец содержит структурированные объекты address. Поскольку такие структуры являются обновляемыми, они легко надстраиваются над существующей схемой.
"Виртуальными объектами", определенными с помощью объектного представления, можно манипулировать и с использованием описанных раньше возможностей клиентского кэша, так как если бы они были "реальными" объектами из объектных таблиц. Для создания пригодных идентификаторов виртуальных объектов в определениях объектной таблицы должен быть специфицирован соответствующий уникальный составной ключ для объектного представления.
По причине наличия некоторых незначительных ограничений объектные представления не полностью эквивалентны объектным таблицам. Например, обычно невозможно хранить указатели на виртуальные объекты в объектных представлениях, поскольку такие указатели должны конструироваться с использованием составного первичного ключа и могут изменяться (в отличие от генерируемых системой идентификаторов реальных объектов).
Развитие возможностей в будущем. Пока компания Oracle не объявила время выпуска и точный набор функциональных возможностей Oracle 8.1. Однако, если основывываться на истории компании, она должна объявить следующий общий выпуск во второй половине 1998 г., включив в него поддержку языка Java для выполнения функций управления базами данных (реализации хранимых процедур и методов), явную поддержку наследования таблиц, расширенную службу картриджей баз данных. Картридж для работы с временными рядами планируется выпустить несколько раньше.
Многие покупатели средств управления базами данных не заинтересованы по-крупному в быстром развитии объектно-реляционной технологии. До сих пор ни один поставщик не смог объяснить преимущества этой технологии для пользователей баз данных основного потока. Более того, во всех ведущих продуктах управления реляционными базами данных под одной и той же вывеской объектно-реляционного подхода предлагаются в значительной степени разные средства. На основе чего пользователи могут сравнить эти продукты?
Трудно обсуждать природу и значение объектно-реляционной технологии, поскольку, в отличие от реляционной модели, эта концепция не является единой и хорошо оформленной. Объектно-реляционная парадигма является скорее слабо связанным набором многих отдельных полезных компонентов. Более 120 функциональных аспектов называют "объектно-реляционными", от наследования и полиморфизма до поддержки больших объектов, расширяемой индексации и кэширования и кластеризации сложных объектов. Некоторые из этих аспектов учитываются в процессе выработки стандарта SQL3, другие (например, кэширование и кластеризация) - нет. В ведущих продуктах реализуются существенно разные поднаборы функций.
Поэтому не удивительно, что многие потенциальные пользователи этой технологии находятся в замешательстве. Аргументы отдельных поставщиков относительно того, какие части технологии являются обязательными для "истинных" объектно-реляционных баз данных, не помогают. Для того, чтобы устранить это замешательство и остаться в стороне от сражений поставщиков, можно использовать модель, группирующую объектно-реляционные свойства, базируясь на их значимости для конечного пользователя баз данных и не принимая во внимание реализационные особенности.
Развитая технология баз данных может (и должна) обеспечить следующие категории свойств:
На основе приведенной модели можно оценить функциональные возможности пяти ведущих поставщиков продуктов управления базами данных - Oracle8, Informix Universal Server, DB2 Unversal Database, Sybase Adaptive Server и Microsoft SQL Server (вместе с OLE DB). Модель можно с тем же успехом применить к чисто реляционным или чисто объектным базам данных, а также для иллюстрации связи между разными технологиями и их эволюции.
В оригинале статьи приведены диаграммы, иллюстирующие эволюцию технологии баз данных от базовых СУБД, поддерживающих стандарт SQL-89, до "идеального" универсального сервера. Кроме того, с использованием модели показаны основные характеристики Oracle8 и ожидаемые характеристики Oracle 8.1.