Подробное рассмотрение возможных способов представления объектных типов в терминах R-системы не является целью данной статьи. Поэтому предлагаемую далее схему можно рассматривать только как пример описывающий принципы сохранения информации о классах в таблицах реляционной БД.

Рассмотрим два класса – A,В – где В наследуется от А. В пространстве определений типов O-системы данная ситуация выглядит следующим образом.

Для того чтобы лучше описать структуру этих таблиц необходимо вернуться к рис.4 изображающему пространство R*O-системы (рис. 8).

Вся эта информация может быть описана с помощью трех отношений.

1.CLASSES – определяет существующие в системе классы.

2.DELTAS – содержит информацию о том из каких Ж состоит класс.

Здесь каждому атрибуту любого из описанных в системе классов ставится в соответствие уникальный идентификатор SemanticID. Поскольку информация о семантическом значении (наравне с OID) является существенной для любого кортежа R*O-системы, содержащей пользовательские данные, каждый кортеж должен содержать поле SID, в котором это значение будет сохраняться. Это поле должно быть объявлено как внешний ключ ссылающийся на поле SemanticID таблицы SCHEME.

Отношения CLASSes, DELTAs и ATTRIBUTes, являющиеся фактически каталогом классов, вместе с полем SID, существующем во всех таблицах данных, являются механизмом, позволяющим определить семантическое значение (смысл) записи в контексте класса объекта, атрибутом которого эта запись является. Можно также предположить, что спроектированный соответствующим образом каталог классов может сохранять всю информацию о классах (константы, методы и т.д.).

После введения отношения OIDs и каталога классов R-проекция R*O-системы примет следующий вид (рис.9).

Объекту R*O-системы, имеющего атрибут, являющийся кортежем отношения, тем самый присущ смысл характерный для данного отношения.

С другой стороны для каждого кортежа R*O системы определено его семантическое значение (смысл) в контексте содержащего его объекта. Это семантическое значение можно использовать для поиска и выборки информации.

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

SELECT ...

      FROM Client.postaddress

Более общим является случай когда отношение, входящие в R*O-систему, содержит произвольное количество кортежей имеющих одинаковые значения полей OID и значения полей SID. Эти записи представляют из себя множество полей идентифицируемого этим OID объекта, имеющими одинаковое семантическое значение SID в контексте класса данного объекта и, таким образом, являются группой повторения.[1]

В данном случае в каждом объекте класса Client может содержаться любое количество записей ранее созданной таблицы ADDR имеющих семантическое значение otheraddress. Отметим, что R*O не определяет какие-либо конструктивы позволяющие упорядочить элементы группы повторения – возможный порядок может определяться лишь информацией содержащейся в них:

ADDR [ORDER BY .../*имена

атрибутов отношения ADDR*/...] otheraddresses

Все связи имеющиеся в R*O-системе фактически являются связями между отношениями т.е . связями характерными для R-системы. Однако существует особый случай который описывает связи характерные для O-систем

Связи между объектами в O-системах осуществляются с помощью элементов специального типа, которые могут быть названы ссылками(или указателями). Понятие “ссылка” определяется и поддерживается системой; структура элемента имеющего тип “ссылка на объект определенного класса” не зависит от типа объекта на который данная ссылка указывает.

По сути дела ссылка определяет существование осмысленной связи между двумя идентифицируемыми объектами. В терминах R*O, где существование объекта определяеться существованием кортежа отношения OIDs, содержащим OID некоторого объекта, эта связь может быть описана парой значений OID. Одно значение соответствует содержащему эту ссылку объекту, второе определяет объект, на который первый объект ссылаеться. Кроме того, должно быть определено семантическое значение ссылки в контексте содержащего ее объекта. [2].

Исходя из этого, для описания и сохранения элементов ссылочного типа можно использовать специальное отношение LINKs .

Отношение LINKs соответствует сущности, смысл которой можно выразить выражением “осмысленная связь между идентифицируемыми объектами”.

В связи с тем, что поле refOID отношения LINKs является внешним ключом, связывающим эту отношние с отношением OIDs, кортеж этого отношения, а следовательно и объект, существование которых определено этим кортежем, невозможно удалить до тех пор, пока в системе будут присутствовать ссылки (кортежи отношения LINKs) на данный объект. Таким образом для поддержки O-ссылочной целостности в R*O-системе используются реляционные механизмы.

Пары значений OID и refOID некоторого кортежа отношения LINKs описывает соотношение “содержащий -включенный”, существующее между двумя идентифицируемыми объектами системы. Следует отметить, что все пары OID и refOID, существующие в отношении LINKs, в целом описывают сложную неоднородную сетевую структуру переменной глубины, которая является следствием возможного существования в системе любого числа элементов любого числа полей любого числа ссылочных типов, описанных в любом числе классов. [2]

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

R*O поддерживает ссылочные конструкции характерные для навигационного способа доступа к данным [14,22,25] присущего сетевым и иерархическим системам [2].

... employee.children ...

которая является примером навигационного способа доступа к данным. В терминах R*O эта конструкция описывает реляционное соединение 2-х подмножеств кортежей отношения LINKs : подмножество кортежей имеющих семантическое значение “сотрудник” (по полю refOID) с подмножеством кортежей имеющих семантическое значение “ребенок” (по полю OID).

Таким образом R*O позволяет представить ссылочные конструкции в терминах реляционных систем.

Триггеры являются ключевым механизмом реализации активности данных, и способом поддержания их целостности. [1]

Исходя из того, что каждый элемент R*O-системы

1) является кортежем некоторого отношения (имеет определенный реляционный смысл) и

2) принадлежит объекту (имеет смысл в контексте этого объекта)

можно сказать, что реакция на изменения данных содержащихся в этом элементе должна состоять из двух частей. Эти части служат для описания правил, соответственно,

1) характерных для сущности, описывающей элемент (R-правила);

2) характерных для объекта, которому элемент принадлежит (O-правила).

R-триггеры являются прямым аналогом триггеров реляционной БД. Эти триггеры являются способом поддержания закономерностей, присущих некоторой сущности.

Пример: Для сущности “АДРЕС” можно определить следующее правило: “Если страна – Россия, то вводимый ZIP-код (индекс), должен содержать шесть цифр”. Данное правило должно выполняться для любого кортежа отношения “АДРЕС”, вне зависимости от смысла, который данный кортеж имеет в контексте объекта

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

Пример: для атрибута содержащего физический адрес клиента можно определить следующее правило – “Физический адрес обязательно должен содержать индекс (ZIP-код)”. Для юридического адреса, имеющего чисто формальное значение, индекс можно и не указывать.

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

S-правила (Structure)

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

Отметим, что основным предположением, на котором основываеться R*O является предположение об ортогональности объектной и реляционной моделей представления данных. Существующая объектно – реляционная модель также основывается на этой посылке. С точки зрения этой модели класс является доменом атрибута отношения. Следует отметить, что R*O не противоречит этому (это следует хотя бы из того, что в R*O определен специальный тип позволяющий сохранять OID объектов в реляционных кортежах). Более того – следует рассматривать это утверждение как равноправную составляющую R*O модели. Таким образом из ортогональности объектной и реляционной моделей данных следует два взаимодополняющих утверждениня:

– отношение является доменом атрибута скалярного(базового) типа класса;

– класс является доменом атрибута отношения.

Соблюдение этих принципов позволяет описать все существующие в системе данные в терминах как объектной так и реляционной моделей рассматривая объект как:

– осмысленную совокупность сущностей опредляющих его связи с другими объектами;

– носителя информации существенной для описания сущностей и связей между ними.

Реляционная модель является моделью хранения данных. Существуют разные модели хранения данных. Например ОЗУ компьютера также описывается определенной моделью, однако никто не говорит о том, что эта модель противоречит (или не противоречит) модели данных используемой программой написанной на С++ и сохраняющей свои данные в ОЗУ в виде объектов. Конечно реляционная база данных является гораздо более сложным хранилищем данных чем оперативная память. Более того – реляционная модель обладает собственной семантикой – семантикой сущностей и связей между ними. Имеено наличие собственной семантики отличной от семантики O-систем (которая в первую очередь направлена на адекватное описание сложных структур) и требующей выполнения определенных условий является основным затруднением в объединение этих R- и O- систем. Предлагаемая R*O- система является попыткой преодоления данного затруднения.

Система, основанная на R*O-модели

• обеспечивает поддержку и хранение сложных объектов;
• дает возможность определять новые типы и расширять существующие, в т.ч. за счет множественного наследования. Наследуются не только объектные но и реляционные свойства;
• обеспечивает целостность объектных ссылок за счет реляционных механизмов;
• поддерживает нереляционные (сетевые и иерархические) структуры;
• позволяет создавать триггеры являющиеся механизмом инкапсуляции данных;
• для описания объектов системы могут использоваться существующие O-языки;
• являясь надмножеством R-систем может быть создана на основе существующих в настоящее время реляционных БД использующих SQL, который может быть расширен для реляционного доступа к объектам и их данным.

[1.] Крис Дейт. Введение в базы данных. Изд. 6-е. Киев, “Диалектика”, 1998.

[2.] Дж.Мартин.Организация баз данных в вычислительных системах. Изд. 2-е 1980 “Мир” (Москва)

[3.] А.В. Замулин Системы программирования баз данных и знаний 1990 Наука (Новосибирск)

[4.] Д. Мейер. Теория реляционных баз данных. 1984 “Мир” (Москва)

[5.] Гради Буч Объектно-ориентированое Проектирование с примерами применений 1992 Диалектика(Киев) & И.В.К. (Москва)

[6.] Х.Дарвин, К.Дэйт. Третий манифест. “СУБД” № 1/1996

[7.] М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С. Здоник. Манифест систем объектно-ориентированных баз данных. “СУБД” № 4/1995

[8.] Системы баз данных третьего поколения: Манифест. “СУБД” № 2 1995

[9.] C.J.Date. Persistence Not Orthogonal to Type. Database Programming & Design OnLine October 1998

[10.]C.J. Date. Encapsulation Is a Red Herring. DataBase Programming & Design OnLine September 1998

[11.]C.J. Date. An Analysis of Codd’s Contribution to the Great Debate Intelligent Enterprise. 1999 Vol. 2, No7

[12.]C.J. Date. The relational model will stand the test of time. Intelligent Enterprise, 1999, Vol. 2, No 8

[13.]C.J. Date. When’s an extension not an extension? Intelligent Enterprise, June 1, 1999, Volume 2, Number 8

[14.]Девид Васкевич Стратегии Клиент/Сервер 1996 Диалектика (Киев)

[15.]С.Д. Кузнецов. Третий манифест Кристофера Дейта и Хью Дарвена: предпосылки и обзор http://www.citforum.ru/database/digest/date_3m_1.shtml

[16.]В. Шринивасан, Д. Т. Чанг Долговременное хранение объектов в объектно-ориентированных приложениях. “Открытые системы” № 3/1999

[17.]С.Д. Кузнецов. Направления исследований в области управления базами данных: краткий обзор. “СУБД” № 1/1995

[18.]В. В. Пржиялковский Абстракции в проектировании БД. “СУБД” № 1-2/1998

[19.]В. В. Пржиялковский Новые одежды знакомых СУБД: Объектная реальность, данная нам “СУБД” № 4/1997

[20.]М.Р. Когаловский Абстракции и модели в системах баз данных “СУБД”.№ 4-5/1998

[21.]Базы данных: достижения и перспективы на пороге 21-го столетия. Под ред. Ави Зильбершатца, Майка Стоунбрейкера и Джеффа Ульмана, “СУБД” № 3/1996

[22.]Ким Вон Технология объектно-ориентированных баз данных. Открытые системы № 4/1994

[23.]Михаэл Стоунбрейкер Объектно-реляционные системы баз данных. “Открытые системы” № 4/1994

[24.]А. Ю. Медников, А.Ю.Соловьев. Объектно-ориентированные базы данных сегодня или завтра? “Открытые системы” № 4/1994

[25.]Джим Грей. Управление данными. Прошлое настоящее и будущее. “СУБД” № 3/1998