© Евгений Григорьев
Статья была опубликована на сайте www.citforum.ru

• Языковая конструкция
• Сущность "OID"
• Объектные типы (схемы классов)
• Группы повторения
• Связи и ссылки
• Триггеры R*O-системы
• Еще о триггерах
• R*O и объектно-реляционная модель
• Заключение
  

Языковая конструкция

Тот факт, что R*O - система полностью описывается ее проекциями (реляционной и объектной), позволяет предположить, что язык, используемый для описания системы должен объединять конструкции языка реляционных БД (например, SQL) и O-языка (например, Java или С++). Например, следующая конструкция

CREATE TABLE ADDR
{
...
};
class Client
{
...
ADDR postaddress;
...
};

вводит в класс Client поле postaddress описывающее запись созданной ранее таблицы ADDR. Для каждого объекта данного класса существующего в системе, в таблице ADDR будет существовать запись, принадлежащая этому объекту, и имеющая семантическое значение postaddress. Такую запись можно назвать полем табличного типа или табличным атрибутом объекта. (Надо заметить, что объект может содержать кортежи любых, в том числе и производных отношений).

Подобный подход может представлять интерес, поскольку подразумевает неизменность исходных языковых конструкций и, вместе с тем, придает им новые возможности. В принципе, можно использовать языковые конструкции любых О- и R- языков. Отметим, что в данном случае SQL не является встроенным языком и, соответственно, О-язык не является базовым языком. Скорее О-язык можно рассматривать как расширение DDL SQL позволяющее объединить отдельные записи в виде сложных объектов.

Сущность "ОID"

Представим адресное пространство R*O-системы в виде отношения OIDs имеющего поле OID в качестве первичного ключа. Ранее отмечалось, что информация о OID является существенной для любого кортежа RxO системы. Поэтому любое отношение, содержащее информацию об объектах, должно иметь поле OID, которое должно быть объявлено как внешний ключ, ссылающийся на поле OID отношения OIDs. Данная связь определяет, атрибутами каких именно объектов являются определенные кортежи этих отношений. После этого проекцию SR-SA можно будет представить в следующем виде (рис.7)

Рис. 7. R-проекция после введения таблицы OID (классы на рисунке не представлены)

Отношение OIDs фактически отражает наличие сущности являющейся общей и обязательной для любого объекта. Смысл данной сущности можно выразить выражением "идентифицируемый объект". Множество значений первичного ключа (поля OID) отношения OIDs фактически является адресным пространством O-проекции R*O-системы. Существование любого объекта системы определяется существованием кортежа отношения OIDs, содержащего уникальный OID этого объекта. Очевидно, что отношение OIDs может содержать и другую информацию, существенную для любого объекта системы. К информации такого рода относится информация, определяющая класс объекта (СlassID).

Объектные типы (схемы классов)

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

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

Обратим внимание на то, что отличает между собой типы А и В. Это некоторая разность D_B = В - А. В данном случае D_B означает, что множество имен атрибутов класса составляющих эту D впервые определено в типе В. Можно описать D_A = A. С другой стороны A= D_A, B = D_A + D_B (или B=A+ D_B что фактически описывает операцию наследования, существующую в O-языках; возможен вариант, описывающий множественное наследование B=A1+A2+...+Ak+ D_B ).

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

Рис. 8. проекция R*O-системы на плоскость SC-SR
(Классы состоят из D являющихся набором имен сущностей)

Каждый класс может быть представлен как сумма D . В данном случае класс A = D_A, а класс B = D_A + D_B . D-ы являются непересекающимися подмножествами пространства определения типов классов. Каждая из этих Dсодержит именованные (здесь: x1, x2, y1) поля различных сущностей (здесь: сущности ADDR и LegIn).

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

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

Из того факта, что каждой D, существующей в системе, может быть поставлен в соответствие некоторый класс, в котором описываются поля входящие в эту D, следует, что число классов равно числу D (и наоборот). Таким образом, можно сказать, что отношение CLASSes описывает также все D, которые существуют в данной системе.

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

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

3. ATTRIBUTES - содержит информацию обо всех существующих в системе атрибутах классов, определяет в какие и D, соответственно, в какие классы эти атрибуты входит.

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

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

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

Рис. 9. R-проекция после введения отношения T_OID и каталога классов
(на рисунке из каталога классов имеется только отношение ATTRIBUTes)

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

Пример: Если объект включает кортеж отношения адрес, то он является адресуемым объектом в самом что ни на есть бытовом смысле этого слова - ему можно направить почтовую корреспонденцию и определить его положение на карте.

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

Пример: мы можем получить информацию о фактических адресах клиентов или о юридических адресах фирм.

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

SELECT ...
FROM Client.postaddress

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

Группы повторения

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

class Client
{
     ...
     ADDR [] otheraddresses;
     ...
};

В данном случае в каждом объекте класса 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, определяющего семантическое значение ссылок в контексте содержащих их объектов, позволит определить для множества ссылок, имеющих одинаковое семантическое значение, правила, присущие связи, которая этим семантическим значением характеризуется.

Пример: предположим, что в системе должна сохраняться информация о людях (физических лицах) являющихся сотрудниками фирм (юридических лиц). Логично описать это, определив в классе "Фирма" множество ссылок на объекты класса "Человек" имеющих семантическое значение "сотрудник" = SIDX (это множество является группой повторения).

Class Person extended Client
{
....
}
Class Firm extended Client
{
          Person [] emloyee;
          ...
}

Существует правило, согласно которому человек (объект, идентифицируемый неким OIDY) может являться сотрудником только одной фирмы. Тогда во множестве кортежей отношения LINKs (среди всех ссылок существующих в системе) не может существовать более одного кортежа со значениями поля SID = SIDX и поля refOID = OIDY.

Пример: предположим, что в системе должна сохраняться информация о родственных связях людей (имеется в виду связь "родитель - ребенок"). Логично описать эту связь, определив в классе "Человек" множество ссылок на объекты класса "Человек" имеющих семантическое значение "ребенок" = SIDК (это множество является группой повторения).

Class Person extended Client
{
          Person [] children
....
}

Тогда множество кортежей отношения LINKs имеющих данное семантическое значение определяет существование однородной структуры переменной глубины, которая фактически описывает генеалогическое древо. Поскольку человек (объект, идентифицируемый неким OID_M) обязательно должен иметь двух родителей, в множества кортежей отношения LINKs (среди всех ссылок существующих в системе) должно существовать два кортежа со значениями поля SID = SID_K и поля refOID = OID_M.

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

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

... employee.children ...

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

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

Триггеры R*O-системы

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

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

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

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

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

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

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

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

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

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

Еще о триггерах

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

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

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

R*O и объектно-реляционная модель

Отметим, что основным предположением, на котором основывается 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, № 7.
12. C.J. Date. The relational model will stand the test of time. Intelligent Enterprise, 1999, Vol. 2, № 8.
13. C.J. Date. When's an extension not an extension? Intelligent Enterprise, June 1, 1999, Volume 2, № 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.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме
Отправить ссылку на страницу по e-mail