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

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

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

Евгений Григорьев (grg@comail.ru)

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

Не вдаваясь в подробности можно сказать, что недостатки каждой модели неразрывно связаны с их преимуществами и фактически противоположны друг другу. Реляционные системы (R-системы) критикуются за отсутствие гибкости, являющейся следствием формальностии (а следовательно, строгости и стабильности), а объектные (O-системы) – за отсутствие формальности, являющейся следствием гибкости. [1,6,7,8, 19,21,22,23]

Данная работа исходит из практической завершенности как реляционной так и объектной концепций. Цель данной статьи – показать, что эти концепции абсолютно не противоречат друг другу и не требуют каких-либо изменений для того, что бы использоваться в общей системе, обладающей всеми свойствами как объектных,так и реляционных систем.

Это идея основывается на следующих утверждениях:

Один и тот же набор данных может одновременно описываться несколькими разными моделями

Реляционная и Объектная модели – разные модели.

Структуру любой сложности можно нормализовать.

Рассмотрим эти утверждения подробнее

Один и тот же набор данных может одновременно описываться разными моделями.

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

Что же можно понимать под разными моделями данных? Можно рассмотреть этот вопрос с точки зрнения классификации моделей данных. В настоящее время выделяют три уровня моделирования прикладной области – концептуальный, логический и физический[18,20]. В приведенном примере можно выделить модели концептуального уровня ( объектная модель языка C++) и физического уровня (модель ОЗУ). Таким образом, можно предположить, что разными являются модели относящиеся к разным уровням. Однако такое определение является весьма условным.

Более строго разными моделями данных можно назвать ортогональные модели. Определение ортогональных моделей является весьма нетривиальным. В рамках данной статьи интересным представляется следствие ортогональности (основанное на том, что модель данных можно определить как множество возможных типов данных [2]): любой тип данных определенный в модели М* ортогональной данной модели М, может рассматриваться в данной модели М только как скалярный (базовый) тип[6,8,10,12, 13,15]. В приведенном примере такими скалярными типами, используемыми в объектной модели языка С++, являются базовые типы int, char и т.п. описывающие возможные типы элементов хранилища данных, т.е. определенные в модели ОЗУ. Таким образом можно сказать, что один и тот же набор данных может одновременно описываться несколькими ортогональными моделями.

Реляционная и Обьектная модели – разные модели

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

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

Операция ADR(X) (где X – элемент системы) является необходимой и достаточной для однозначной идентификации элемента Х системы, т.е. ADR(X_i) № ADR(X_j) (при X_i№ X_j) и ADR(X_i) =ADR(X_j) (при X_i = X_j). Возвращает величину необходимую для однозначной идентификации элемента X.

Операция IS(X) возвращает тип элемента Х. Поскольку тип можно определить как множество имен атрибутов, то можно сказать, что в системе существует некое множество являщееся объединением всех множеств имен атрибутов всех типов, которое в дальнейшем будем называть пространством определения типов. Таким образом операция IS(X) проецирует элемент X на простанство определения типов.

В случае O-систем операция ADR(X) возвратит уникальное значение А ( или OID) объекта Х или, говоря по другому, спроецирует объект Х на адресное пространство ( пространство значений OID ) системы. Можно сказать, что результатом операции ADR(X) будет (А) где A – адрес. Исходя из определения операции ADR(X), действительным является выражение А_i № А_j (где Х_i № Х_j). Кроме того из самой возможности сравнивать A_i и A_j следует что IS(A_i) = IS(A_j). Для сохранения адресов используются элементы особого базового типа – ссылки или указатели.

Следует сказать, что в общем случае пространство определения типов О-системы является сложным и многомерным, что следует из многобразия способов типообразования в этой системе.[5,18] Одним из этих способов является наследование. Этот способ присущ только О-системам и позволяет при определении новых типов использовать уже существующие, более общие по смыслу, базовые типы. Благодаря наследованию в О-системах один и тот же атрибут может быть определен в разных типах. На иллюстации класс В является наследником класса А и поэтому атрибут I определенный в классе А определен также и в классе-наследнике В. [1,5,16]

Для того чтобы изобразить пространство R-системы необходимо вспомнить о ключе.Это понятие является одним из основных для R-систем и определяется следующим образом: ключом отношения называют такое подмножество внутри множества имен атрибутов отношения, что кортежи отношения могут быть однозначно определены значениями соответствующих атрибутов этого подмножества. Таким образом ключ состоит из набора значений которые однозначно определяют любую строку таблицы. Определенное значение ключевого поля (или полей), принадлежащих записи некоторой таблицы, позволяет найти эту запись внутри этой таблицы.[1,4]

Для однозначной идентификации кортежа Х некоторого отношения R операция ADR(X) должна вернуть выражение вида (R,K), которое звучит как “Ключ K кортежа X отношения R где R = IS(X)” . На этом определении основывается понятие внешнего ключа, который может быть назван R-аналогом ссылок и указателей O-систем. Определение подобного рода позволяет ввести в R-системы (рис. 2) механизм поддержки ссылочной целостности не позволяющий присвоить ссылке(внешнему ключу) значение выходящее из области значений первичного ключа соответствующего отношения.

Если сравнивать пространства R- и O- систем то можно отметить два различия:

в O-системе объекты существуют в едином адресном пространстве в то время как в R-системе для каждого отношения существует свое собственное пространство значений первичного ключа. Можно сказать, что в O-системе адресное пространство является характеристикой присущей системе в целом и понятие “адрес” вводится до начала описания каких-либо классов, в то время как в R-системе пространство первичного ключа отношения R является характеристикой только этого отношения и и оно не определено до описания самого этого отношения. Данные рассуждения верны также и для элементов системы позволяющих сохранять адрес. Существующий в O-системах ссылочный тип данных определяется системой и не зависит от типа объектов на который ссылка указывает. Возможно объявить неопределенную ссылку (в C++ – это указатель void* ) или на класс, который является базовым для любого другого класса и существует в системе по умолчанию (в Java – ссылка на объект класса Object). В R-системах внешний ключ должен быть связан с первичным ключом определенного отношения, и следовательно может быть объявлен только после того как это отношение описано.
В пространстве определения типов: рис.1 иллюстрирует наследование – одно из ключевых понятий O-систем. На рисунке класс B является наследником класса А.

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

все данные, имеющиеся в такой системе должны быть представлены как объекты прозвольной структуры.
все данные, имеющиеся в такой системе должны быть представлены в виде реляционных переменных [9]

Кажется, что наиболее простым путем создания системы имеющей свойства R- и O-систем будет расширение R-системы за счет введения в нее общего адресного пространства и применения к отношениям операции наследования. Рассмотрим это подробнее.

Создание общего адресного пространства в R-системе

Расcмотрим пару (R,K) подробнее. Поскольку она описывает результат операции ADR(X), однозначно идентифицирующей кортеж Х внутри системы, можно сказать что (Ri,Ki) № (Rj,Kj) при Хi№ Хj. Отдельные части описываемой пары данное условие не поддерживают и возможен случай когда Ki = Kj при Хi!=Хj. Можно предположить, что исключение подобных случаев является одним из условий приведения R-системы к O-системе. Выполнение условия Ki№ Kj (при Хi№ Хj) не будет нарушать R-систему, поскольку (Ri,Ki) № (Rj,Kj) не становиться от этого менее строгим. Однако следует заметить, что в R-системах невозможно однозначное сравнение между Ki и Kj поскольку в них могут существовать такие Ki и Kj что IS(Ki) № IS(Kj) (поле или поля первичного ключа разных отношений могут иметь разный тип). Таким образом для создания общего адресного пространства в R-системе требуется введение другого условия IS(Ki) =IS(Kj).

Эти рассуждения приводят нас к введению в R-систему понятия RecID – идентификатора, позволяющего однозначно определить любой кортеж системы. Следует заметить, что поле содержащее RecID является ключевым для любой таблицы хотя может быть и не определено явно как ключ.

Введение RecID не представляет особой сложности. Смысл, однако, заключается не в самом RecID. Важным является возможность использовать его значение для инициализации ссылок (или указателей), которые позволяют другим частям системы обращаться к данному кортежу. Можно рассмотреть два случая:

ссылочный элемент, содержащий RecID, является внешним ключом (здесь RecID должен являться первичным ключом некоторого отношения R). Следовательно этот элемент может ссылаться на кортежи только одного отношения (этого отношения R). Можно сказать, что здесь теряется смысл RecID, как элемента позволяющего идентифицировать любой кортеж любого отношения;
ссылочный элемент не является внешним ключом. Конечно, этот элемент может ссылаться на любой кортеж, существующий в системе. Однако в данном случае отсутствует контроль ссылочной целостности, и возможно такая ситуация когда ссылка указывает на отсутствующий кортеж.

Применение наследования для отношений

Взглянем еще раз на рис.(1) описывающий пространство O-системы. Класс B является наследником класса А. Таким образом для операции IS(Bi) (где Вi – объект класса B) возможно два варианта правильного ответа – класс А и класс В. Можно сказать, что IS(Bi) = IS(Aj) в то время как IS(Ai)!=IS(Bj). Эта закономерность является следствием гибкости O-систем в их способности определять новые типы.

Применим к отношениям наследование и определим отношение Rn+1 как наследник Rn. Из этого следует что для кортежа Х относящемуся к Rn+1 действительным будет IS(X) = IS((Rn)X) и в в то же время IS((Rn)X) № IS(X) где (Rn)X – кортеж Х представленный как кортеж отношения Rn или, говоря по другому, приведенный к базовому типу Rn. Тогда операции ADR(Х) возвратит пару (Rn+1, K) где K – ключ кортежа Х в адресном пространстве отношения Rn+1=IS(X). Соответственно ADR((Rn)Х) возвратит пару (Rn, K) где K – тот же самый (поскольку он наследуется) ключ в адресном пространстве отношения Rn=IS((Rn)X). Сравнение этих пар приведет к следующему выводу : ADR(Х) = ADR((Rn)Х) и в то же время ADR((Rn)Х) № ADR(Х). Поскольку операция ADR определяется как операция однозначно определяющая элемент системы (т.е. ADR(Xi) № ADR(Xj) (при Xi№ Xj) и ADR(Xi) =ADR(Xj) (при Xi = Xj) где Xi и Xj – элементы системы) данный вывод говорит о принципиальной невозможности применить к отношениям операцию наследования. Можно сказать, что элемент реляционной системы (кортеж) описываемый типом R, в связи с особенностями адресации (пара (R,K) ), может входят только в одно множество R которое определяется существованием данного типа (схемы отношения) R. Таким образом тип отношения и тип класса не могут быть одним же типом. Это является достаточным, для того что бы сказать, что реляционная и объектная модели являются разными моделями.

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

Структуру любой сложности можно нормализовать

Блок информации любой сложности можно сохранить как набор записей различных таблиц.[2,1] Говоря по другому любой объект можно представить как набор кортежей различных отношений. Эта идея является основой проектирования реляционных БД и используется с момента их создания. По мнению автора именно эту идею нужно рассматривать как основу для создания системы объединяющей свойства объектных и реляционных систем. Причина, по которой существующие в настоящее время реляционные системы не обладают объектными свойствами заключаеться не в том, что эта идея является неверным. Она является неполной.

Для того чтобы понять что имеется в виду, вернемся к примеру с программой сохраняющей свои данные в ОЗУ. Мы можем сказать, что в ОЗУ может быть сохранена любая информация (во всяком случае до сих пор это удавалось). Соответсвенно информация о некотором моделируемом объекте (здесь мы исходим из того, что любая программа в той или иной мере является способом моделирования некой предметной области) представляет из себя некоторое множество элементов ОЗУ. Важным является тот факт, что это верно для любой программы, будь она написана на Си, FORTRAN или ассемблере (все эти языки используют разные парадигмы программирования и не являются объектными) - в любом случае некоторому моделируемому объекту можно поставить в соответствие некоторое множество элементов ОЗУ, сохраняющие данные о этом объекте. Преимущество объектных систем заключается в том, что только они позволяют явно поставить в соответсвие объекту моделируемой области ИДЕНТИФИЦИРУЕМЫЙ и ОСМЫСЛЕННЫЙ(или, по другому, ИМЕЮЩИЙ ОПРЕДЕЛЕННУЮ СТРУКТУРУ) набор элеметов ОЗУ, который также (в терминах О-систем) называется объектом.

Аналогичные рассуждения верны и для объекта, данные о котором необходимо сохранить в реляционной базе данных. Из того факта, что информация о объекте с произвольной внутренней структурой может быть сохранена в реляционной системе, необходимо сделать следующий вывод: любому объекту можно поставить в соответствие ИДЕНТИФИЦИРУЕМЫЙ и ОСМЫСЛЕННЫЙ набор кортежей.

Рассмотрим это положение по частям:

объект есть идентифицируемый набор кортежей. Набору кортежей содержащему данные о некотором объекте можно поставить в соответствие уникальный идентификатор, который фактически является объектным идентфикатором(OID), используя который мы можем обращаться к даному набору кортежей;
объект есть осмысленный набор кортежей. Объект описывается типом, каждому атрибуту которого ставиться я в соответствие определенное семантическое значение. Это семантическое значение определяет смысл кортежа в объекте и ,кроме того, позвляет обращаться к этому кортежу как к атрибуту объекта.

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

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

В каждый объект класса “Юридическое лицо” будет входит три набора данных, три поля, каждое из которых содержит определенную информацию об этом объекте: 1) фактический адрес 2) регистационная информация 3) юридический адрес. Каждый из этих наборов данных содержит информацию о их состоянии в процессе определенного взаимодействия с другими объектами окружающего мира, информацию определяющую возможность этого взаимодействия. Говоря по другому, каждый из этих наборов данных содержит информацию об одной из многих сущностей этого объекта.

Рассмотрим поля содержащие юридический и фактический адреса. В принципе, почтовая корреспонденция может быть послана по любому из этих адресов. Структура этих полей абсолютно одинакова. Эта структура определяется их собственным смыслом (т.е. их смыслом вне объекта, атрибутами которого являются эти поля), определяется их сущностью, которая может быть выражена словом “адрес”. Информация содержащаяся в таких полях является достаточной для установления определенной связи (например почтовой) с содержащими их объектами. Чтобы послать письмо важно наличие у объекта-получателя поля с сущностью “адрес”, а какой объект – человек или фирма – данным адресом идентифицируется, какой текст находится в письме, что представляет данный адрес в контексте объекта – вся эта информация совершенно неважна для того чтобы письмо было послано по почте объекту, которому этот адрес принадлежит. Разница между этими полями (в одном случае адрес является юридическим, в другом – фактическим) существует только если рассматривать их в контексте объекта. Именно класс определяет по какому из этих адресов письмо должно быть послано.

Обратим особое внимание на то, что вне контекста класса все информационное содержимое полей, имеющих сущность “адрес”, определяется только содержащимися в них данными. Только эти данные являются существенными.[11] Из этого следует, что в сущности адрес имеет реляционную природу и может рассматриваться как схема соответсвующего отношения. Тоже можно сказать и про сущность “регистрационная информация”.

Рассмотрим наш пример более формально. Существует класс A описывающий клиентов, которым надо рассылать корреспонденцию.. Этот класс включает поле X₁ содержащее фактический адрес клиента; это поле является котрежом отношения ADDR соответствующего сущности “адрес”. Существует производный класс В (фирма) включающий поле X₂ (юридический адрес) являющееся кортежом того же отношения ADDR и поле Y₁ являющегося кортежом другого отношения LegIn соответствующего сущности “регистрационная информация”. Создадим объект О_А класса А идентифицируемый OID₁ и объект О_В класса В идентифицируемый OID₂.

В нашем примере мы имеем дело и с классами (объектная модель) и с отношениями (реляционная модель). Поскольку объектная и реляционная модели могут рассмариваться только как ортогональные, этот пример может быть проиллюстрирован следующим образом (рис. 4)

Проекция этой системы (которая в силу отрогональности R- и O-компонентов автор называет R*O – системой) на плоскость (S_C-S_OID) дает следующую картину (рис.5)

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

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

OID объекта, к которому относится данный элемент;

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

Именно эта информация является существенной для того чтобы кортеж мог рассматриваться как осмысленная часть идентифицируемого объекта.

Проекция R*O-системы на плоскость (S_R-S_OID) будет выглядеть следующим образом (рис.6)

Пунктирные стрелки показывают что:

каждый элемент принадлежит к тому или иному объекту, имеющему соответствующим OID;
каждый элемент описан как поле класса этого объекта – для каждого элемента существует SID.

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

Таким образом реляционная и объектная системы могут быть рассмотрены как ортогональные проекции общей 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. Данная связь определяет, атрибутами каких именно объектов являются определенные кортежи этих отношений . После этого проекцию S_R-S_A можно будет представить в следующем виде (рис.7)

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

Продолжение

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