Обзор статьи "Bringing Object Relational Down To Earth"
, vol.10, N 6, June 1997
, Won Kim
, Центр Информационных Технологий
Существует путаница вокруг понятия универсального сервера баз
данных, и стоит разобраться, что же свойственно истинной
объектно-реляционной системе.
Эра объектно-реляционной технологии баз данных началась в 1992 г.
с выпуском системы баз данных UniSQL/X, сочетающей черты
реляционной и объектно-ориентированной системы. Вскоре после
этого компания Hewlett-Packard выпустила систему OpenOOB (позднее
переименованную в Odapter), представляющую собой объектный слой
над реляционной системой AllBase. В 1993 г. компания Montana
Systems (переименованная впоследствии в Illustra) начала поставки
первой коммерческой версии объектно-реляционной системы Postgres,
в реализации которой наибольшее внимание уделялось управлению
мультимедийными данными.
Эти три производителя вскоре привлекли внимание аналитиков прессы
и индустрии. Компания Informix поглотила Illustra Technology
(интересуясь главным образом технологией DataBlade для расширения
возможностей баз данных). Сегодня такие гиганты как Oracle,
Informix, Sybase, IBM и Microsoft имеют объявленные планы
преобразования своих реляционных продуктов в объектно-реляционные
к концу 1997 г. В результате на рынке объектно-реляционных систем
царствуют сомнения. Для этого есть несколько причин.
Во-первых, в результате поглощения компанией Informix технологии
Illustra и последующей маркетинговой активности в общей
технологии объектно-реляционных систем чрезмерный вес был придан
роли расширяемости типов данных. Во-вторых, озадачивает
отсутствие меры "объектно-реляционной полноты системы", т.е.
уровня поддержки возможностей объектно-реляционного моделирования
и управления данными.
В статье предлагается практическая метрика объектно-реляционной
полноты; эта метрика может применяться для определения того,
насколько продукт является истинным объектно-реляционным. Метрика
состоит из семи основных категорий, в каждой из которых
выделяются "наиболее важные" и "наименее важные" свойства. В
число категорий входит следующее: модель данных, язык запросов,
критически важные сервисы, объектно-ориентированная
вычислительная модель, требования эффективности и
масштабируемости, инструментальные средства, а также то, что
можно было бы назвать "использованием мощности" (harnessing the
power).
Модель данных
Базовая объектная модель (Core Object Modell), определенная
Object Management Group (OMG), включает реляционную модель данных
наряду с базовыми концепциями объектно-ориентированного
моделирования, свойственными объектно-ориентированным языкам
программирования. Модель OMG следовало бы иметь в качестве
стандарта. Объектная модель формирующегося стандарта SQL3 кое в
чем отличается от модели OMG, но обсуждаемые здесь концепции в
равной мере применимы и к SQL3.
Ниже используется аббревиатура RDB для обозначения реляционных
систем, ORDB - для обозначения объектно-реляционных систем, OR -
для обозначения объектно-реляционного подхода, OODB - для
обозначения объектно-ориентированных систем.
Основные модельные концепции OMG состоят в следующем:
В OR-полной ORDB модель данных должна включать понятие класса
(или типа), обладающего атрибутами, методами и ограничениями
целостности. Класс служит шаблоном для экземпляров, которые могут
создавать с разделением атрибутов и методов класса. Доменом
атрибута может быть примитивный тип данных, абстрактный тип
данных или ссылка на класс. Атрибут может содержать атомарные или
множественные значения; в последнем случае может иметь ноль или
много значений. Метод - это функция, применяемая к каждому
экземпляру класса и производящая вычисления на основе значений
его атрибутов. Ограничения целостности включают примитивные
ограничения, поддерживаемые RDB, такие как спецификация
допустимости неопределенных значений атрибута, ограничение
уникальности экземпляров класса и ограничение первичного ключа на
одном или нескольких атрибутах класса.
Экземпляр класса обладает уникальным и неизменным объектным
идентификатором (OID). Пользователь должен иметь возможность
запросить выборку экземпляра по его OID.
Пользователь должен иметь возможность написать метод и
присоединить его к классу. К атрибуту класса можно относиться как
к специальному методу с интерфейсом, включающим только методы
чтения и изменения значения. Язык написания методов должен быть
комбинацией ObjectSQL и основного языка. Основной язык может
являться полным языком программирования, таким как Си или Си++,
или может быть ограниченным языком, подобным тем, на которых в
RDB пишутся хранимые процедуры.
конфликтов имен
Пользователь должен иметь возможность создания класса как
подкласса одного или нескольких существующих классов. Подкласс
наследует спецификации атрибутов и методов всех своих
суперклассов (множественное наследование). Если два или более
суперкласса содержат атрибут или метод с одним и тем же именем,
но с разными спецификациями, возникает "конфликт имен". Хотя по
этой причине применение множественного наследования является
проблематичным, этот подход остается общепринятым стандартом и
должен поддерживаться в ORDB.
OID)
Если домен атрибута является ссылкой на класс, система в
действительности хранит в атрибуте OID экземпляра класса, на
который имеется ссылка. Обычно в качестве OID используются
логические идентификаторы объектов, а не их физические адреса.
Поэтому применение OID'ов в ORDB (и по этим же причинам в OODB)
не требует возврата к физическим указателям иерархических и
сетевых баз данных.
Атрибут с множественным значением может хранить ноль или более
значений, и индивидуальные значения могут выбираться и изменяться
пользователем.
Атрибут с множественным значением может хранить
обычное множество (без элементов-дубликатов), мультимножество (с
потенциально возможными дубликатами) или последовательность
(упорядоченное мультимножество).
ADT конструируется путем комбинирования примитивных типов данных.
Простым примером является тип данных "точка", который
конструируется путем комбинирования координат x и y, каждая из
которых представляется типом данных чисел с плавающей точкой. ADT
представляет собой специальный случай ссылки на класс и
примитивного алфавитно-цифрового типа данных. Подобно последнему,
значение ADT прямо хранится в атрибуте. Подобно ссылке на класс,
это непримитивный тип данных. Более того, как и в случае классов,
пользователи могут организовать ADT в виде иерархии классов.
Поскольку значение ADT прямо хранится в атрибуте, оно не может
совместно использоваться несколькими экземплярами.
Следующие модельные понятия OMG являются менее важными:
Семантика включения множеств, связанная с иерархией наследования
классов, предполагает, что экземпляры подкласса логически
принадлежат его суперклассу. Если домен атрибута специфицирован
как ссылка на класс, то этот домен может включать не только
ссылки на экземпляры указанного класса, но также и ссылки на все
экземпляры классов, являющихся прямыми или косвенными
наследниками данного класса.
Понятно, что экземпляр класса - это объект. Но следует ли
относиться как к объекту к самому классу? Ответ - "да". При
реализации этой идеи пользователи могут специфицировать атрибуты
и методы самого класса, а не только те, которые применимы к его
экземплярам. Атрибут класса может хранить значения, описывающие
класс или всю совокупность его экземпляров; метод класса
применяется к самому классу-объекту. Важными видами использования
атрибутов (и методов) класса являются моделирование агрегатных
свойств всех его экземпляров (например, средний вес автомобиля);
хранение значения, общего для всех экземпляров класса (например,
число колес у автомобиля); спецификация значения атрибута
экземпляра по умолчанию.
Язык запросов (ObjectSQL)
В ORDB должны поддерживаться ObjectSQL (язык баз данных с
минимальными расширениями стандарта реляционного языка SQL) и
соответствующие API (вызовы функций). Расширения SQL необходимы
для чтения и модификации объектов, определяемых и создаваемых на
основе перечисленных выше возможностей объектного моделирования.
Если пользователь не нуждается в использовании возможностей
объектного моделирования базы данных, должен использоваться SQL.
Относительно стандарта ObjectSQL имеются два предложения: SQL3 и
Object Query Language (OQL). Предпринимаются усилия по слиянию
этих двух языков в единый международный стандарт. Стандарт SQL3,
разрабатываемый комитетом ANSI X3H4, включает объектные
расширения стандарта RDB SQL-92. OQL, возникший в результате
усилий Object Data Management Group (ODMG) по стандартизации
языков доступа к объектным базам данных, пока еще не полностью
совместим с SQL3.
Основные свойства ObjectSQL
Поскольку текущим стандартом SQL является спецификация SQL-92,
ObjectSQL для ORDB должен начинаться с SQL-92 и содержать
расширенные средства запросов, соответствующие возможностям
объектного моделирования, которые пользователь может применять
при проектировании базы данных. Фундаментальные возможности
стандартного SQL включают запросы из одной таблицы, соединения
нескольких таблиц, вложенные подзапросы, запросы с GROUP BY,
HAVING и ORDER BY и запросы, включающие операции
объединения/вычитания/пересечения результатов запросов.
Если пользователь создает класс (класс-1) с атрибутом, доменом
которого является ссылка на другой класс (класс-2), и создает
экземпляры этих классов, система будет хранить OID экземпляра
класса-2 в атрибуте класса-1, связывая тем самым экземпляр
класса-1 с экземпляром класса-2. Пользователь должен иметь
возможность выдавать запросы выборки экземпляров класса-1 на
основе условий поиска на экземплярах класса-2 или же запросы
выборки экземпляров класса-2, привязанных к экземплярам класса-1
(удовлетворяющим условиям поиска на экземплярах класса-1).
Конструкция запроса, называемая "выражением пути" ("path
expression"), может позволить пользователю специфицировать
условия поиска на последовательности классов, связанных через
домены атрибутов.
Если пользователь определяет атрибут с множественными значениями
и заносит в него набор значений, то этот пользователь должен
иметь возможность выбирать или изменять любой индивидуальный
элемент множества и любое его подмножество. ObjectSQL должен
обеспечивать соответствующие средства запросов. Хорошим базисом
для этого является конструкция "порождаемой таблицы" ("derived
table") языка SQL-92, но в настоящее время в SQL-92 отсутствуют
полные возможности манипулирования элементами множеств.
Пользователь должен иметь возможность использовать вызов метода в
любом месте запроса, где может содержаться вызов функции или
ссылка на атрибут. Система должна загружать и выполнять метод и
возвращать результат для использования при дальнейшем выполнении
запроса.
Пользователь должен иметь возможность использовать в условии
поиска любой атрибут вне зависимости от вида его домена. В
частности, доменом может являться ADT.
"Представление" ("view") - это подмножество базы данных,
удовлетворяющее определенным пользователем условиям; содержимое
представления создается при выполнении соответствующего запроса.
В RDB представление логически эквивалентно таблице. В ORDB
представление не являются логическим эквивалентом класса, хотя
нужны по тем же причинам, что и в RDB.
Должна иметься возможность
определения представлений с условиями, включающими объектные
расширения.
Менее важные свойства ObjectSQL
Из семантики включения следует, что запрос, адресуемый к
некоторому классу, может затрагивать все экземпляры этого класса
или же все экземпляры классов-наследников. Пользователь должен
иметь возможность специфицировать желаемый результат. Более того,
при формулировке и выполнении запроса часто бывает полезно
исключить некоторые классы иерархии.
Критически важные сервисы
Объектные расширения реляционной модели вызывают далеко идущие
последствия в области архитектуры баз данных. При объектных
расширениях RDB требуется добавление новых компонентах и
модификация основных существующих компонентов. Например, тот
факт, что запрос ObjectSQL может включать в своем условии поиска
выражение пути, требует соответствующих расширений функций
оптимизатора запросов. Поскольку пользователи могут требовать
выборку объектов по их OID'ам, система должна поддерживать
хэш-таблицу для отображения OID'ов в физические адреса объектов.
Из-за того, что пользователи могут пожелать совместно
использовать большие документы как объекты, авторизация доступа
должна производиться на уровне объектов, а не на уровне атрибутов
или таблиц, как это делается в RDB. Далее перечисляются некоторые
требуемые возможности расширенных RDB. Не обсуждаются такие
службы как восстановление после сбоев, репликация, устойчивость к
сбоям, поскольку они не связаны с объектными расширениями. Однако
автор считает, что возможности восстановления относятся к
основным, а службы, обеспечивающие репликацию и устойчивость к
сбоям, являются менее важными.
Первичные возможности: RDB, расширенная до ORDB
В оптимизаторе запросов ORDB должны использоваться все ключевые
методы, внедренные в оптимизаторы запросов RDB, включая генерацию
всех разумных планов выполнения запроса, выбор оптимального плана
на основе оценки ожидаемой стоимости выполнения запроса,
использование методов доступа (индексов и сортировки), применение
алгоритмов вложенных циклов и сортировки со слияниями для
выполнения соединений, использование статистической информации
базы данных для проведения оценок.
Запрос, содержащий выражение пути, часто выполняется наилучшим
образом при прямом применении метода поиска в глубину по
последовательным OID'ам, указывающим на объекты. Другими словами,
ORDB не должна стремиться обрабатывать запрос с выражением пути с
использованием традиционных методов вложенных циклов или
сортировки со слиянием. Поэтому оптимизатор запросов RDB должен
быть расширен для обработки таких запросов. Кроме того, в ORDB
должен быть реализован механизм хранения и доступа к значениям
атрибута с множественными значениями.
В клиент-серверной архитектуре метод может выполняться на стороне
клиента или на стороне сервера (или и там, и там). Оптимизатор
запросов ORDB должен генерировать план выполнения запроса,
минимизирующий пересылку данных между клиентом и сервером при
выполнении запроса, включающего вызов метода. Очень трудно
разработать оптимизатор запросов, автоматически оценивающий
селективность условия поиска (отношение числа объектов,
удовлетворяющих условию поиска, к общему числу объектов в
пространстве поиска запроса), если в него входит вызов метода.
Как минимум, оптимизатор запросов должен уметь минимизировать
объем данных, выбираемых из базы данных, путем установки
приоритетов условий поиска; при этом условия с вызовом метода
имеют высший приоритет.
RDB позволяют пользователям создавать индексы, дающие возможность
оптимизатору запросов ограничить до минимума пространство поиска
базы данных. Для организации этих индексов используется структура
B-дерева. Но индексы использовались только для алфавитно-цифровых
типов данных. Важной задачей является расширения концепции
индексирования для атрибутов, доменами которых являются ADT.
Широко известны индексные структуры, такие как R-деревья,
файлы-решетки (grid files) и k-d деревья, применяемые для
индексации пространственных данных (например, треугольников или
линий).
В ORDB должны полностью использоваться все методы, употребляемые
в RDB, включая двухфазные блокировки, протоколы установки и
снятия блокировок, гранулированные блокировки, иерархические
блокировки, логические и физические блокировки и режимы
блокировок. Объектные расширения требуют некоторых добавок. Для
поддержки запросов с иерархией наследования классов, динамической
эволюцией этой иерархии требуются расширения техники управления
параллельным доступом на основе блокировок. Простым решением,
например, было бы блокирование всей грозди классов, растущей от
данного класса, для того, чтобы избежать некоторых нежелательных
ситуаций. Тот факт, что пользователь ORDB может использовать OID
для доступа к одному объекту, означает, что объект, а не страница
дискового пространства или класс должен быть наименьшей единицей
блокировки в ORDB.
В ORDB должен поддерживаться полный механизм авторизации,
поддерживаемый в RDB, включая авторизацию на уровне атрибута,
класса или представления; рекурсивную передачу и изъятие
привилегий доступа; передачу привилегий индивидуальным
пользователям, группам и сразу всем; авторизацию, привязанную к
ресурсам и т.д.
Объектные расширения вызывают добавление авторизации для
выполнения методов и авторизации для одного объекта. Именно
объект должен быть наименьшей единицей авторизации в ORDB.
Триггеры настолько же важны в ORDB, как в RDB. Но объектные
расширения не требуют существенных добавок, кроме как вызова
методов при выполнении действия триггера.
В ORDB методы присоединяются к конкретным классам и наследуются
подклассами. Методы могут выполняться как клиентом, так и
сервером. Хранимые процедуры настолько же важны в ORDB, как и в
RDB. В RDB хранимая процедура не присоединяется к какой-либо
таблице и поэтому не наследуется одной таблицей от другой. Но в
ORDB хранимая процедура может рассматриваться как метод сервера,
присоединенный к базе данных целиком, а не к какому-либо классу.
RDB позволяют пользователям динамически изменять схему базы
данных; эти изменения обычно ограничены созданием и уничтожением
таблицы и добавлением и уничтожением атрибута. В ORDB схема имеет
больше составляющих, чем в RDB, и поэтому большее число элементов
схемы может динамически изменяться. Расширения включают
добавление метода класса и уничтожение метода, добавление и
уничтожение связи суперкласс/подкласс и даже изменение домена
атрибута.
Менее важные возможности: RDB, расширенная до ORDB
Поддержка мандаторной безопасности всегда была важным вопросом
для пользователей систем баз данных правительственных и военных
учреждений. Внедрение объектных расширений усложняет эту задачу.
Дополнительные трудности связаны главным образом с использованием
методов и OID'ов.
Вычислительная модель
Многие приложения, такие как автоматизированные анализ,
проектирование, моделирование и тестирование, могут выполнять
операции с большими объемами данных в памяти. Эти приложения
управляют большим числом объектов и должны выполнять обширные
вычисления очень быстро, поэтому объекты должны находиться в
памяти и быть заранее скомпонованными. OODB проектируются с
учетом требования производительности, нужной таким приложениям,
при дополнительном предположении, что сами приложения написаны на
объектно-ориентированном языке. Для поддержки быстрого
навигационного доступа к объектам в основной памяти OODB
обеспечивают возможность автоматического управления большим
числом объектов в памяти (это называется "жизненным кэшем" или
"пулом объектных буферов"). OODB автоматически преобразуют
форматы хранения объектов из формата базы данных в формат памяти,
при загрузке в память преобразуют хранимые в объектах OID'ы в
указатели по памяти и при окончании транзакции выталкивают в базу
данных объекты, измененные в памяти. Опасность для приложений,
связанная с использованием указателей по памяти, может быть
сведена к минимуму за счет применения техники косвенных
указателей на описатели объектов.
RDB не поддерживают преобразование указателей и кэширование.
Поэтому приложения RDB использовать явные запросы с соединением
или хотя бы направленные к одной таблице для эмуляции простой
навигации объектов. Более того, приложения RDB должны также
отправлять измененные записи по одной в базу данных через
интерфейс RDB.
В ObjectSQL запросы и вызовы функций API могут использоваться в
комбинации. Запрос ObjectSQL может использоваться для загрузки
объектов в жизненный кэш; последующие вызовы API могут загрузить
дополнительные объекты, на которые имеются ссылки из объектов,
уже находящихся в кэше. При этом преобразование формата объектов,
преобразование указателей, передача объектов из базы данных в
кэш, сборка мусора и перемещение объектов из кэша в базу данных
должны выполняться автоматически. Оператор End Transaction
автоматически вытолкнет измененные объекты в базу данных.
Производительность и масштабируемость
ORDB должны быть нацелены на те сегменты рынка баз данных, в
которых чистые RDB не справляются с трудностями моделирования
сложных данных и управления мультимедийными данными, а также на
те сегменты, потребностям которых не могут удовлетворить OODB по
причине плохой масштабируемости и недостаточной развитости
критически важных служб.
Производительность системы баз данных, в конечном счете,
определяет ее возможный успех и поэтому требования высокой
производительности являются первичными. По отношению к ORDB
требования производительности выглядят следующим образом:
ORDB должна быть совместимой (с возможностью отклонения в
пределах 20 процентов) с производительностью чистых RDB
OID или при навигации в памяти на основе указателей
производительность должна быть совместимой (с возможностью
отклонения в пределах 20 процентов) с производительностью OODB
основе объектных расширений SQL (выражения пути, атрибуты со
значениями абстрактных типов, методы, определяемые пользователями
функции и иерархия наследования).
Масштабируемость тесно связана с производительностью;
производительность (пропускная способность и/или время отклика)
сервера баз данных должна соответствующим образом возрастать при
добавлении дисков и процессоров. Для поддержки больших баз данных
и большого числа пользователей ORDB должны соответствовать уровню
масштабируемости, достигнутому в современных RDB. Основные RDB
основываются теперь на трехзвенной архитектуре "клиент-сервер" и
для поддержки большого числа пользователей связываются с
мониторами транзакций (Tuxedo, Encina, TopEnd). Для увеличения
пропускной способности RDB запускаются на симметричных
мультипроцессорах (SMP), кластерах и даже массивно параллельных
процессорах (MPP). Кроме того, в RDB используются методы
распараллеливания, такие как архитектура множественных серверных
процессов (в которой каждый процесс управляет несколькими
нитями), асинхронные обмены с дисками, параллельный ввод/вывод,
распараллеливание выполнения запросов, распараллеливание
вспомогательных утилит (построения индексов, архивирование,
восстановление, сжатие базы данных, обновление статистики базы
данных, массовая загрузка).
Все эти методы повышения уровня масштабируемости важны и должны
использоваться и в ORDB. Однако, поскольку нельзя внедрить все
сразу, полезно классифицировать методы на первичные и вторичные.
(Поддержка MPP может не быть необходимой по причине
преимущественного использования в настоящее время технологий SMP
и кластеров.)
Первичные требования (для масштабируемости):
(без обеспечения распараллеливания индивидуальных запросов).
Вторичные требования (для масштабируемости):
Инструментальные средства баз данных
Пользователи RDB осознают потребность в инструментальных
средствах, выходящих за пределы непосредственных возможностей
сервера баз данных с его интерфейсами уровня SQL и API, для
поддержки цикла разработки приложений. Эти средства включают
следующее:
производительности и отслеживания использования ресурсов
программирования
для построения, редактирования и просмотра результатов запросов
редактирования схемы базы данных
приложений, обладающих обычно графическим или ориентированным на
формы пользовательским интерфейсом.
Вообще говоря, средства для ORDB должны обладать расширенной
функциональностью, в которой учитываются расширения, присущие
объектному моделированию. В случае отсутствия средств,
специфических для ORDB, в самом крайнем случае ORDB должна иметь
интерфейсную связь с популярными продуктами RDB сторонних
компаний, в которых учитываются возможности объектного
моделирования.
Далее приводится сводка необходимых объектных расширений
инструментальных средств RDB. К наиболее важным возможностям
объектного моделирования с точки зрения пользователей относятся
атрибуты с множественными значениями, ADT и вложенные объекты;
иерархия наследования и методы не столь важны. Поскольку
инструментальные средства баз данных стали составной частью среды
разработки приложений, большинство этих возможностей относится к
первичной категории.
Первичные возможности инструментальных средств баз данных
Браузер/дизайнер базы данных должен позволять пользователям
редактировать и просматривать схему ORDB с учетом иерархии
наследования классов; иерархии вложенности классов на основе
атрибутов, домены которых есть ссылки на другие классы; атрибутов
с множественными значениями; методов и атрибутов со значениями
абстрактных типов данных.
Генератор запросов должен позволять пользователям конструировать
объектные расширения SQL и просматривать результаты запросов,
возвращающих атрибуты с множественными значениями, атрибуты со
значениями абстрактных типов, вложенные объекты и экземпляры из
иерархии наследования классов.
Средство разработки 4GL должно позволять пользователям
проектировать экраны для работы с атрибутами со множественными
значениями, атрибутами со значениями абстрактных типов и
вложенными объектами.
Средства администрирования базы данных должно быть расширено так,
чтобы, по меньшей мере, можно было распознавать планы выполнения
запросов с выражениями пути, методами, иерархией наследования;
кроме того, необходимы средства отслеживания ресурсов жизненного
кэша.
Разработанный компаниями Microsoft и Apple стандарт ODBC
используется как интерфейс RDB для разнообразных приложений,
выполняемых на PC. Если потребуется изменить эти приложения в
расчете на использование объектных расширений ORDB,
соответствующие расширения будут нужны и в ODBC.
Сегодня средства просмотра и публикации Web внесли существенные
изменения в среду разработки приложений. Эти изменения могут
устранить потребность в некоторых средствах, являющихся частью
традиционной среды разработки приложений.
Использование мощности
Объектные расширения в ORDB дают пользователям баз данных по
меньшей мере две важных возможности, выходящих за пределы
моделирования и манипулирования данными, - расширяемость базы
данных и интеграция неоднородных баз данных.
Средства расширения
баз данных были широко оглашены под названиями DataBlades,
Database Extenders и Data Catridges. Об интеграции разнородных
баз данных говорят меньше, но эта тема также очень важна.
Однако, поскольку обе возможности лежат за пределами
ответственности сервера ORDB, их можно рассматривать как
вторичные.
Вторичные возможности "использования мощности"
Тема расширяемости баз данных была настолько раскручена
компаниями Illustra и Informix, что некоторые люди полагают
добавление к RDB DataBlades и других "расширителей" превращает
реляционную систему в объектно-реляционную. Конечно, добавление
средств DataBlades к серверу баз данных - это совсем неплохо. Но
не следует забывать о том, что ORDB должна обеспечивать описанные
выше возможности моделирования и управления и что DataBlades
относятся к категории вторичных возможностей, делающих ORDB еще
более мощной и полезной.
В целом, расширяемость базы данных означает возможность добавлять
любые новые возможности (например, алгоритмы обработки запросов,
новые режимы блокировок, новые методы доступа) к коммерческому
серверу баз данных. Однако для практических целей расширяемость в
действительности включает возможность пользователей (не
производителей) добавлять новые модули управления данными, типы
данных (классы) и операции (методы). Новый модуль управления
данными может быть источником данных стороннего поставщика
(графической или текстовой информации) или механизмом управления
источником данных (для распознавания образов или полнотекстового
поиска). Целью расширения базы данных является обеспечение
использования всех возможностей сервера базы данных (включая
обработку запросов и блокировки) при управление доступными
пользователям новыми данными.
Возможность добавления новых типов данных и операций - это всего
лишь логическое следствие парадигмы объектной ориентации, которая
предполагает разрешение создания новых классов с атрибутами и
методами, наследуемыми от существующих классов. Поэтому
практическая важность расширяемости состоит не только в
обеспечении возможности добавления на уровне пользователя новых
модулей управления данными и новых типов данных, но также в
доступности развитой библиотеки функций для конкретных типов
данных, обеспечиваемой не пользователями, а производителями.
Функции, привязываемые к некоторому типу данных, можно
подразделить на "прикладные функции" и "методы доступа".
Прикладные функции выполняют логику приложения с данными,
выбранными из базы данных; функции-методы доступа производят
хранение, поиск и поддержку данных в базе данных.
Прикладные функции представляют собой разумные и полезные
средства, которые разработчикам приложений следует добавлять к
поставляемым производителями библиотекам. Хотя добавлять
некоторые типы методов доступа (например, методы индексирования
для полнотекстового поиска) могут и пользователи, обычно трудно,
если не невозможно добавлять методы доступа для произвольных
типов данных.
Например, представим себе, что пользователь хочет добавить к
серверу ORDB метод индексации, основанный на R-дереве, для
поддержки геометрических данных. Каким образом после этого
оптимизатор запросов ORDB распознает, что такой индекс теперь
существует? Даже если оптимизатор сможет узнать об этом, как он
сможет оценить селективность индекса при оптимизации
геометрического запроса? Как, в конце концов, менеджер транзакций
будет выполнять функции восстановления и синхронизации
параллельного доступа по отношению к страницам R-дерева?
По определению модель ORDB является комбинацией реляционной
модели данных и объектной модели. Объектная модель включает
ключевые модельные концепции, которые использовались в
иерархических и сетевых базах данных, такие как повторяющиеся
группы (атрибуты с множественными значениями) и навигация по
указателям (на основе OID). Поэтому модель ORDB представляет
собой идеальную схему для интеграции схем все существующих
разнородных баз данных, включая RDB, ORDB, иерархические и
сетевые базы данных и даже плоские файлы.
Ниже приводятся возможности, включение которых в ORDB делает
объектно-реляционную систему возможной основой системы мультибаз
данных (MDBS):
схемы над существующими схемами разнородных баз данных
ObjectSQL в подзапросы, обрабатываемые существующими разнородными
системами баз данных, и выполнять всю необходимую пост-обработку
(сливать отдельные результаты, выполнять соединения между
таблицами разных баз данных, сортировать и группировать отдельные
результаты)
разнородными системами баз данных (в основном, двухфазная
фиксация/откат)
Логически MDBS является окончательным обобщением идеи шлюза;
физически такая система управляет несколькими шлюзами, через
которые производится управление удаленными базами данных. MDBS
может иметь и свою собственную базу данных; например, данные,
извлеченные из удаленных баз данных, могут быть сохранены в
собственной базе данных MDBS - по сути дела, получает склад или
лавка данных (datawarehouse или data mart). В любом случае MDBS
представляет пользователям множество удаленных баз данных как
одну "виртуальную" базу данных.
