Стандарт ODMG, система управления объектными данными, архитектура и основные компоненты объектной модели данных
Несколько наиболее крупных фирм-разработчиков образовали группу Object Database Management Group (ODMG) с целью определения стандартов, необходимых для ООСУБД. Среди них следует упомянуть GenStone Systems, Object Design, O2 Technology, Versant Object Technology, UniSQL, РОЕТ Software, Objectivity, IВEX Computing SA и Lockheed Martin. Груrша ODMG создала объектную модель, которая определяет стандартную модель для семантики объектов базы данных. Эта модель имеет очень большое значение, поскольку в ней определяется встроенная семантика, которая будет понятна для ООСУБД и может быть использована ею. Макеты библиотек классов и приложений с такой семантикой должны быть переносимыми среди разных ООСУБД, в которых поддерживается эта объектная модель (Connolly, 1994).
Ниже перечислены основные компоненты архитектуры ODMG для ООСУБД:
- ODMG
- Объектная модель (Object Model - ОМ).
- Язык определения объектов (Object Definition Language - ODL).
- Язык объектных запросов (Object Query Language - OQL).
- Связующий язык С++.
- Связующий язык Smalltalk.
- Связующий язык Java.
Первая версия стандарта ODMG была выпущена в 1993 году. С тех пор было выпущено несколько небольших поправок к ней, а следующая обновленная версия ODMG 2.0 была принята в сентябре 1997 года. Она включает усовершенствования, перечисленные ниже:
- Новая возможность связывания на основе языка программирования Java фирмы Sun.
- Полностью пересмотренная версия объектной модели с новой метамоделью для поддержки семантики базы данных среди нескольких языков программирования.
- Стандартный внешний вид данных и схемы данных, который позволяет выполнять передачу данных между базами данных.
Предлагаемая ODMG архитектура показана на рисунке ниже.
В этой архитектуре определяются способ хранения данных и разные виды пользовательского доступа к этому “хранилищу данных”. Единое хранилище данных доступно из языка определения данных, языка запросов и ряда языков манипулирования данными.
Центральной в архитектуре является модель данных, представляющая организационную структуру, в которой сохраняются все данные, управляемые ООСУБД. Язык определения объектов, язык запросов и языки манипулирования разработаны таким образом, что все их возможности опираются на модель данных. Архитектура допускает существование разнообразных реализационных структур для хранения моделируемых данных, но важным требованием является то, что все программные библиотеки и все поддерживающие инструментальные средства обеспечиваются в объектно-ориентированных рамках и должны сохраняться в согласовании с данными.
Объектная модель (ОМ)
Объектная модель ODMG является надмножеством объектной модели OMG, позволяющим переносить макет и реализацию между совместимыми системами. В ней определены следующие основные модельные понятия:
1. Основными модельными понятиями являются объект и литерал, но только объект обладает уникальным идентификатором.
2. Объекты и литералы могут быть разбиты на типы. Все объекты заданного типа демонстрируют общее поведение и состояние. Сам по себе тип также является объектом.
3. Поведением называется набор операций, которые могут быть выполнены объектом или над ним.
4. Состояние определяется значениями, которые имеются у набора свойств объекта. Свойство может быть либо атрибутом объекта, либо связью между двумя или несколькими объектами.
5. Объекты хранятся в базе данных, которая позволяет многим пользователям и приложениям совместно использовать их. Она основана на схеме, которая определяется на языке определения объектов (Object Definition Language ODL). База данных содержит экземпляры типов, определенных ее схемой.
Каждый объект обладает уникальным идентификатором объекта, который не изменяется и не используется повторно после удаления этого объекта. Кроме того, объекту можно присвоить одно или несколько удобных для пользователя имен при условии, что каждое имя определяет один объект в области видимости определения этого имени, т.е. в пределах базы данных. В стандарте также указано, что время жизни объекта ортогонально его типу, т.е. перманентность не зависит от типа объекта. Время жизни объекта задается во время его создания и может иметь один из следующих двух типов:
- Временный объект. Память для объекта выделяется и освобождается системой времени выполнения языка программирования. Обычно выделение памяти осуществляется из стека для объектов, объявленных в заголовке процедуры, и из статической или динамической области (кучи) для динамически создаваемых объектов (с областью видимости в рамках процесса).
- Перманентный объект. Хранение объекта обеспечивается средствами СУБД.
Как утверждалось в первом манифесте, одним из важнейших отличий объектов от значений является наличие у объекта уникального идентификатора (объекты обладают свойством идентифицируемости). Накладные расходы, требуемые для обращения к объекту по его идентификатору с целью получения доступа к базовым значениям данных, могут весьма сильно замедлить работу приложений. Поэтому в модели ODMG допускается описание всех данных в терминах объектов и использование традиционного вида значений, которые в модели называются литеральными значениями. Таким образом, возраст человека может задаваться целочисленным литералом, а не объектом, имеющим свойство «возраст». В этом случае значение возраста будет сохраняться как часть структуры данных объекта человек, а не в отдельном объекте. Это, в частности, означает, что объект может входить в состав нескольких других объектов, а литерал – нет. Схема базы данных в модели ODMG главным образом состоит из набора объектных типов, но компонентами этих типов могут быть типы литеральных значений.
Коллекции
В объектной модели ODMG коллекция содержит произвольное количество неименованных однородных элементов, каждый из которых может быть экземпляром атомарного типа, другой коллекции или литерального типа. Единственное отличие между коллекцией объектов и коллекцией литералов заключается в том, что первая обладает идентификатором. Например, набор из всех отделений компании можно определить как коллекцию. Перемещение по коллекции организуется с помощью итератора, который содержит информацию о текущем положении внутри данной коллекции. Коллекции могут быть упорядоченными или неупорядоченными. В упорядоченных коллекциях обход совершается с первого элемента в направлении к последнему элементу или наоборот; тогда как для неупорядоченных коллекций не существует фиксированного порядка обхода.
Типы и классы
В модели ODMG база данных представляет собой коллекцию различимых значений (denotable values ) двух видов – объекты и литералы. Объекты обладают свойствами идентифицируемости и индивидуального существования, а литералы являются компонентами объектов. Модель данных содержит конструкции для спецификации объектных и литеральных типов. Объектные типы существуют в иерархии объектных типов; литеральные типы похожи на типы, характерные для обычных языков программирования (например, С или Pascal). В модели ODMG не используется термин класс. Единственная классификационная конструкция называется типом, и типы описывают как объекты, так и литералы. То, что называлось классом в первом манифесте, в ODMG называется объектным типом.
В модели поддерживается ряд литеральных типов – базовые скалярные числовые типы, символьные и булевские типы (атомарные литералы), конструируемые типы литеральных записей (структур) и коллекций. Конструируемые литеральные типы могут основываться на любом литеральном или объектном типе, но считаются неизменчивыми. Даты и время строятся как литеральные структуры.
Объектный тип состоит из интерфейса и одной или нескольких реализаций. Интерфейс описывает внешний вид типа: какими свойствами он обладает, какие в нем доступны операции и каковы параметры у этих операций. В реализации определяются структуры данных, реализующие свойства, и программный код, реализующий операции. Интерфейс составляет общедоступную (public) часть типа, а в реализации при необходимости могут вводиться дополнительные частные (private) свойства и операции. Все объектные типы (системные или определяемые пользователем) образуют решетку (lattice) типов, в корне которой находится предопределенный объектный тип Object.
Супертип (supertype). Объектные типы связаны структурой типа супертип/подтип. Все атрибуты, связи и операции, определенные для супертипа, наследуются подтипом. В подтипе могут определяться дополнительные свойства и операции, а также могут переопределяться унаследованные свойства и операции.
Экстент (extent). Набор всех экземпляров заданного типа образует его экстент. Программист может потребовать, чтобы в ООСУБД существовал индекс для членов этого набора. Удаление объекта приведет к удалению объекта из экстента того типа, к которому относился этот экземпляр.
Ключ (key). Ключ единственным образом идентифицирует экземпляры некоторого типа.
Атрибуты и связи совместно называются свойствами, а свойства и операции совместно называются характеристиками объектного типа (или объектов данного типа).
Связи
Связи в большинстве объектных систем связи неявно моделируются как свойства, значениями которых являются объекты. Например, если человек работает на некоторую компанию, то у каждого объекта-человека должно иметься свойство, которое можно назвать worksFor и значением которого является соответствующий объект-компания.
В модели ODMG , подобно ER -модели, различаются два вида свойств – атрибуты и связи, хотя и несколько другим образом. Атрибутами называются свойства объекта, значение которых можно получить по OID объекта, но не наоборот. Значениями атрибутов могут быть и литералы, и объекты, но только тогда, когда не требуется обратная ссылка. Связи – это инверсные свойства. В этом случае значением свойства может быть только объект, поскольку литеральные значения не обладают свойствами. Поэтому возраст служащего обычно моделируется как атрибут, а компания, в которой работает служащий, – как связь. При определении связи должна быть определена ее инверсия. В приведенном выше примере, если worksFor определяется как связь, должно быть явно указано, что инверсией является свойство employees объекта-компании, а при определении employees должна быть указана инверсия worksFor.
Операции
Экземпляры объектного типа обладают поведением, которое определяется в виде набора операций. Определение объектного типа включает сигнатуру операции (operation signature) для каждой операции, которая задает имя операции, имена и типы всех ее аргументов, имена всех исключительных ситуаций, которые могут возникнуть при ее выполнении, а также типы возвращаемых значений (если таковые имеются). Операция может быть определена только в контексте единственного объектного типа. Для имен операций поддерживается перегрузка. В этой модели предполагается последовательное исполнение операций, причем не требуется специальная поддержка для параллельных, разделяемых или удаленных операций, хотя такая поддержка не исключается.
Исключительные ситуации
В модели ODMG поддерживаются динамически вложенные дескрипторы исключительных ситуаций. Как уже упоминалось выше, операции могут вызывать появление исключительных ситуаций, которые, в свою очередь, могут обмениваться результатами таких ситуаций. Исключительные ситуации являются объектами "первого класса", способными образовывать иерархию обобщения-специализации с корневым типом Exception, предусмотренным в ООСУБД.
Метаданные
Метаданными называются "данные о данных", Т.е. данные, которые описывают такие объекты системы, как классы, атрибуты и методы. Многие существующие ООСУБД не рассматривают метаданные как самостоятельные объекты, а потому пользователи не могут создавать запросы по отношению к метаданным аналогично тому, как это делается в отношении других объектов. В модели ODMG метаданные описывают следующие компоненты.
1. Области видимости, которые определяют иерархию именования для метаобъектов в репозитории.
2. Метаобъекты, состоящие из модулей, операций, исключительных ситуаций, констант, свойств (состоящих их атрибутов и связей) и типов (состоящих их интерфейсов, классов, коллекций и структурированных типов).
3. Спецификаторы, которые используются для назначения имени определенному типу в некотором контексте.
4. Операнды, которые образуют базовый тип для всех постоянных значений в репозитории.
Транзакции
В модели ODMG поддерживается концепция транзакции, представляющей собой логическую единицу работы, переводящую базу данных из одного непротиворечивого состояния в другое. В этой модели предполагается линейная последовательность выполнения транзакций внутри потока управления. "Управление параллельностью основано на стандартных блокировках для записи/чтения пессимистического протокола управления параллельностью. Все операции доступа, создания, изменения и удаления перманентных объектов должны выполняться в рамках транзакции. В этой модели определены встроенные операторы запуска, фиксации и отмены транзакции, а также операция создания контрольной точки. Операция контрольной точки фиксирует все измененные объекты в базе данных без снятия любых блокировок до возобновления транзакции.
В этой модели не предполагается поддержка распределенных транзакций, но утверждается, что если таковая имеется, то она должна быть ХА-совместимо.
Базы данных
В модели ODMG концепция базы данных понимается как эквивалент области хранения перманентных объектов заданного набора типов. База данных имеет схему, которая представляет собой набор определений типов. Каждая база данных является экземпляром типа Database с встроенными операциями open() и close(), а также с операцией lookup(), предназначенной для проверки наличия в базе данных заданного объекта. Именованные объекты являются точками входа в базу данных, причем имя связывается с объектом с использованием встроенной операции bind(), а разрывается такая связь с помощью встроенной операции unbind().