Сайт Информационных Технологий

Каталог >> Базы Данных >>

Представления идентифицируемых сложных объектов в реляционной базе данных

Евгений Григорьев

Продолжение. Начало.


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

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

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

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

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

p align="center">

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

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

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

Столбец Тип Ключ Описание
ClassID TypeCID Primary Идентификатор класса ( и ??)
ClassName char[…]   Имя класса

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

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

Столбец Тип Ключ Описание
ClassID TypeCID Primary, references CLASSes (ClassID) Идентификатор класса
DeltaID TypeCID Primary, references CLASSes (ClassID) Идентификатор D

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

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

Столбец Тип Ключ Описание
SemanticID TypeSID Primary Идентификатор элемента схемы классов
DeltaID TypeCID References CLASSes (ClassID) Идентификатор D-ы содержащей его (так же можно рассматривать как идентификатор класса где описан этот атрибут )
Name Char[…]   Имя поля
TableName Char[…]   Табличный тип данного поля (имя отношения кортежем которого это поле является)

Здесь каждому атрибуту любого из описанных в системе классов ставится в соответствие уникальный идентификатор 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]

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 .

Столбец Тип Ключ Описание .
OID TypeOID References (OIDs)OID OID объекта содержащего ссылку
SID TypeSID References (SCHEMA)SemanticID SID определяющий смысл ссылки в объекте
RefOID TypeOID References (OIDs)OID OID объекта, на который указывает ссылка

Отношение 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М) обязательно должен иметь двух родителей., в множества кортежей отношения LINKs (среди всех ссылок существующих в системе) должно существовать два кортежа со значениями поля SID = SIDK и поля refOID = OIDM.

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-модели

Литература.

[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


Site of Information Technologies
Designed by  inftech@webservis.ru.