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

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

Оглавление

Введение.

Формальное описание системы.

Стержневое отношение.

Ссылки.

Проектирование схемы данных.

    Ортогональные типы данных.

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

Свойства системы.

    Групповые операции. Ненавигационный доступ к данным.

    Групповые операции над ссылками.

    Вычисляемые атрибуты объектов. Инкапсуляция.

    Наследование.

    Переопределение атрибутов.

Метаданные

    Каталог.

    Связь данных и метаданных.

Методы.

Заключение.

 
Также статья доступна в формате MS Word: OOORD.zip

Введение.

Современные информационные системы можно рассматривать как многоуровневые кибернетические¹⁾ системы, в которых поступающие извне команды управления данными, существующими в программных объектах описывающих сущности моделируемой предметной области [4], трансформируются в команды, управляющие используемым оперативным запоминающим устройством (ОЗУ). В свою очередь данные, существующие в ОЗУ, приводятся к виду, определяемому используемой абстракцией. Преобразования команд и данных, позволяющие реализовать используемую абстракцию, описываются программой. ОЗУ можно рассматривать как терминальный механизм²⁾ хранения с неизвестным устройством, который определен только через способ обращения к нему и действия, которые он производит по отношению к другим частям системы.

Для долговременного хранения данных программа должна обращается к внешним запоминающим устройствам. Такая организация является следствием ряда причин, среди которых можно выделить неспособность подавляющего большинства типов ОЗУ к постоянному хранению информации, а также ограничение размера адресуемого ОЗУ и его относительную дороговизну. Используемые в настоящее время СУБД представляют собой результат развития средств управления внешними запоминающими устройствами (ВЗУ) [5]. С этой позиции объектная программа, которая работает с данными, находящимися в линейной оперативной памяти (линейное ОЗУ), и использует для их постоянного хранения реляционную СУБД, будет выглядеть следующим образом.

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

Утверждая, что программы (в том числе и объектные) работают с данными, хранящимися в оперативной памяти, а СУБД являются средством управления внешних запоминающих устройств, необходимо обратить внимание на то, что  деление запоминающих устройств на оперативные и внешние с развитием программных и аппаратных средств смещается с физического уровня на логический. В самом деле, предоставляемый современными операционными системами логический ресурс, называемый "оперативная память", представляет собой виртуальную память, размеры которой могут многократно превосходить имеющееся в наличие физическое ОЗУ за счет использования дисковых подсистем (т.е. ВЗУ). Существуют ОС, позволяющие сохранять на диске полный образ ОЗУ, что фактически делает хранящиеся в нем данные постоянными во времени. С другой стороны, организую эффективную работу с ВЗУ, современные СУБД используют огромные массивы физического ОЗУ ⁴⁾.

Сравнивая линейное ОЗУ и реляционную СУБД как терминальные механизмы хранения данных, можно прийти к выводу, что наиболее важным логическим отличием между ними является отличие в организации доступа к данных. OЗУ предполагает адресный способ доступа. Отметим, что системы управления БД в процессе своего развития [5] отказались от такой организации. Реализуя принцип независимости данных [6], реляционные СУБД организует ассоциативный доступ к данным по явно заданному значению.

Реляционные системы обладают рядом неоспоримых преимуществ, существенных именно для систем хранения данных. Они являются реализациями математически строгой модели[7,8], дающей однозначные и строгие определения используемых структур и операций. Реляционная алгебра работает с множеством записей как с единым целым, применяя операцию к множеству записей целиком и производя множество записей в результате. Для доступа к данным реляционные системы используют непроцедурный высокоуровневой язык, реализующий ненавигационный доступ к данным [9,10].

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

 

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

• Существующая реляционная модель данных не нуждается в каких-либо изменениях или дополнения.
• Отсутствует необходимость в организации обмена данных между разными терминальными механизмами хранения данных.
• Решается вопрос перманентности данных

 

Формальное описание системы

Сформулируем задачу.

В системе хранения данных, реализующей реляционную модель, необходимо сохранить информацию об объектах моделируемой предметной области. Информация о моделируемых объектах представляет собой набор сложных значений oV, хранящихся в идентифицируемых переменных (в дальнейшей – объекты данных). Объект данных o можно описать как {OID, S, oV}, где OID – уникальный идентификатор указанной переменной, S – информация, описывающая структуру указанной переменной (метаданные), где, в частности, перечисляются поименованные атрибуты объекта данных, oV - сложное значение, описывающее состояние объекта. Каким же образом эта информация может быть представлена в реляционном ОЗУ?

Теория реляционных БД предполагает, что  для обеспечения эффективного хранения  данных (что подразумевает их целостность и непротиворечивость) , эти данные должны быть нормализованы [8,9,10]. Процесс нормализации сложных значений является формальным методом, основанным на анализе зависимостей между значениями атрибутов этого сложного значения. В результате этого процесса информация, описывающая систему, состоящую из многих объектов, преобразуется к множеству значений разных отношений. Между исходным множеством объектов и результирующим множеством отношений существует отношение "многие ко многим": каждое отношение может состоять из кортежей, описывающих многие объекты, и, в свою очередь, каждый объект может описываться кортежами, входящими во многие отношения, причем в каждое отношение может входить любое число кортежей, описывающих данный объект. Каждому из исходных объектов в каждом их результирующих отношений будет соответствовать некоторое, возможно пустое подмножество кортежей. Поскольку любое подмножество кортежей отношения также является отношением, можно утверждать, что полное значение oV любого объекта o из исходного множества объектов можно представить в виде набора значений разных отношений.

Таким образом, объект o можно описать как {OID, S, {r₁,r₂….r_n}} где r_i – некоторое значение отношения R_i, возникшее в результате нормализации значения oV (в дальнейшем мы остановимся на процессе проектирования более подробно). Отметим, что на данном этапе мы никак не определяем возможные схемы отношений R_i. Предполагается, что возможность, позволяющая описать объектную переменную и задать множество значений отношений {r₁,r₂….r_n}, не может быть выражена в терминах реляционной модели данных и, следовательно, ортогональна ей.

Будем рассматривать каждое из значений r_i как значение именованного атрибута объекта о. Тогда атрибут должен рассматриваться как переменная отношения, а схема объекта данных должна перечислять имена атрибутов. Соответственно, объект o будет описываться как

o = {OID,{_oa₁, _oa₂,…, _oa_n},{r₁,r₂….r_n}}, <0>

где r_i – значение отношения R_i со схемой (_ra₁:D₁, _ra₂:D₂….), r_i = relval(R_i), D_j, - не обязательно разные домены из множества D доменов. Заметим, что в системе O может одновременно существовать множество не обязательно разных значений r одного и того же отношения R, являющихся значениями атрибутов разных объектов или значениями разных атрибутов одного и того же объекта.

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

Рассмотрим множество O всех входящих в в систему объектов о вида <0>. Мы можем говорить о существовании множества _oa всех имен атрибутов _oa этих объектов. Каждому объекту o_i(o_i О O) ставиться в соответствие схема объекта S_i = oSchema(o_i), которая является собственным подмножеством множества _oa , S Н _oa . Одна и та же схема S может быть поставлена в соответствие многим объектам. Классом С, С Н O называют множество объектов с одинаковой схемой: объекты o_i {OID_i, S_i, oV_i} и o_j {OID_j, S_j, oV_j} принадлежат одному и тому же класс С только тогда, когда oSchema(o_i) = oSchema(o_j). Таким образом, можно утверждать, что между множеством схем и множеством классов существует функциональное соответствие S= Schema(C)

Также мы можем говорить о существовании множества R всех определенных на множестве доменов D отношений R, значения которых являются значениями атрибутов _oa объектов из множества O. Каждому атрибуту _oa ставиться в соответствие одно и только одно отношение R из множества R, тем самым ограничивая множество возможных значений атрибута _oa значениями этого отношения R. Поскольку речь идет о паре "множество - определенное на этом множестве значение " отношение R можно обозначить как домен атрибута _oa. Однако, поскольку значение, определенное на этом домене, представляет собой значение отношения (relval) и также является множеством, будем называть отношение R реляционным доменом атрибута _oa, R = rdom(_oa). Возможен случай, что домены разных атрибутов совпадают rdom(_oa_i) = rdom(_oa_j), a_i№a_j.

Таким образом, мы можем говорить о функциональном соответствии между множеством атрибутов _oa и множеством отношений R,

R = rdom(_oa) <2>

Это соответствие должно указываться в схеме объекта, которая будет перечислять пары _oa : R, где R = rdom(_oa)

o = {OID,{_oa₁:R₁, _oa₂:R₂,…, _oa_n:R_n},{r₁,r₂….r_n}}, <0'>

Собственное значение объекта o, принадлежащего классу С, можно представить как такое отображение oV из множества _oa в множество R (_oa--^Schema(C))-->R), что каждому _oa_i принадлежащему Schema(C) (_oa_i О Schema(C)) будет соответствовать значение отношения R_n, являющегося доменом _oa_i oV(_oa_i) = rval(R_n) , R_n = rdom(_oa_i), а каждому _oa_j, не принадлежащему S (_oa_j П S), будет соответствовать пустое множество oV(_oa_j) = Ж.

Каждое такое отображение соответствует уникальному значению, являющемуся идентификатором этого объекта. Тогда множество идентифицируемых объектов O есть функциональное соответствие между множеством OID уникальных идентификаторов OID объектов o, и множеством oV отображений (_oa--^Schema(C)-->R), формирующих собственные значения этих объектов.

O = (OID -> _oV). где _oV = {oV| oV = _oa--^Schema(C)-->R} <3>

Крайне важен тот факт, что предлагаемая формализация однозначно определяет способ, позволяющий представить информацию, описывающую множество O объектов вида <0>, в терминах реляционной модели данных. В самом деле, исходя из <3>, множество объектов O можно представить как отношение, построенное на множествах OID, _oa и R, то есть как подмножество декартового произведения множеств OID, _oa и R.

O М OID ґ _oa ґ R        <4>

Предположим, что значения уникальных идентификаторов объектов, входящих в множество OID, определены на домене D_OID (OID Н D_OID), а имена их атрибутов, входящих в множество _oa – на домене D_A (_oa Н D_A), и рассмотрим множество доменов D', такое, что D' - D = {D_OID,D_A}. Можно показать, что

O М R' , R' = { R'_i| R'_i М D_OID ґ D_A ґ R_i, R_i О R}        <5>

Поскольку отношения R_i входящие в множество R определены на множестве доменов D ( R_i (_ra₁:D₁, _ra₂:D₂….), D О D), то R'_i является отношением, определенным на множестве доменов D'.

( Поскольку R = rdom(A), то <5> то более точным будет следующее

O М R' , R' = { R'_i| R'_i М D_OID ґ rdom^-1(R_i) ґ R_i, R_i О R },        <6>

Тем самым мы ограничили число возможных значений определенного на домене D_A атрибута отношений R'_i, именами только тех атрибутов объекта, для которых доменом является соответствующее отношению R'_i отношение R_i. )

Таким образом, множество O объектов o вида <0> может быть однозначно преобразовано к множеству значений отношений R', входящих во множество R', причем между множеством R отношений, являющихся доменами атрибутов объектов o , и множеством R' существует такое взаимно-однозначное соответствие

R <--> R'          <7>

что для любого отношения R_i (_ra₁:D₁, _ra₂:D₂….), принадлежащему R, во множестве R' будет существовать соответствующее отношение R'_i (_ra_OID: D_OID, _ra_oa:D_A, _ra₁:D₁, _ra₂:D₂….), D О D'). В дальнейшем мы будем называть атрибуты _ra_OID и _ra_oa системными атрибутами.

Это можно проиллюстрировать следующим образом. Предположим, что в объекте o со схемой (… , _oa:R , …), идентифицируемый уникальным значением OID_i, атрибут _oa содержит значение r отношения R со схемой (_ra₁:D₁, … , _ra_n:D_n) o._oa = rval(R), состоящее из кортежей t_i.

Значение r атрибута _oa объекта o в множестве R' будет представлено в виде подмножества кортежей t'_i отношение R' со схемой (_ra_OID: D_OID, _ra_oa:D_A, _ra₁:D₁, … , _ra_n:D_n), у которых атрибут _ra_OID содержит значение OID_i и атрибут _ra_oa содержит значение _oa, t'_i._ra_OID = OID_i, t'_i._ra_oa = _oa.

Реляционная переменная o._oa (атрибут _oa объекта o) представлена в множестве R' как следующее подмножество кортежей отношения R'

o._oa _Oє_R' s_{(raOID= OIDi, raoa = oa )} (R')           <8>

а собственное значение r указанной реляционной переменной вычисляется как

r = p_{!(raOID, raoa)}( s_{(raOID= OIDi, raoa = oa)}(R'))         <8'>

где s_{(raOID= OIDi, raoa = oa )} - операция выборки по атрибутам _ra_OID и _ra_oa, а p_{!(raOID, raoa)} – операция проекции, отсекающая эти атрибуты.

Обозначение _Oє_R' показывает, что выражению, обращающемуся к данным, представленным в виде объектов, входящих в множество O (выражение слева от _Oє_R'), соответствует выражение, управляющее данными, организованными в виде множества R' отношений, существующих в терминальной систем хранения, т.е. реляционном ОЗУ (выражение справа).

Заметим, что на основании R = rdom(_oa) и R'« R, можно говорить о существовании между множествами R' и _oa функционального соответствие rstorage, определяющего, какое из отношений R' будет служить для хранений значений атрибутов _oa:

R' = rstorage(_oa).        <9>

В отношении R' представлены значения всех определенных на реляционном домене R атрибутов, существующих во всех объектах о из множества O. Каждому имени атрибута _oa_i соответствует подмножество A_i кортежей отношения R', A = s_{( raoa = oai)}(R'), где R' = rstorage(_oa_i). Подмножество A_i по сути дела представляет собой объединение значений всех существующих атрибутов _oa_i (o₁._oa_i И …И o_n._oa_i) где o_i – объект содержащий атрибут _oa_i. Поскольку атрибут _oa_i, объявленный в некотором классе С (_oa_i О Schema(C) ), определен только в объектах этого класса С и в объектах классов С⁺, наследующих класс C, объединение (o₁._oa_i И …И o_n._oa_i) будем обозначать как С.a_i ,

С.a_{i O}є_R A, A = s_{( raoa = oai)}(R'), где R' = rstorage(_oa_i).        <10>

В дальнейшем множество O мы будем называть уровнем представления данных, а множество R' – уровнем хранения данных. На уровне представления данные существуют в виде объектов вида <0'>, причем

1. объекты имеет уникальный идентификатор, и, следовательно, в системе могу существовать два объекта с абсолютно одинаковым собственным значением,
2. значение атрибутов объектов есть значения отношений, представляющее собой множество кортежей – другими словами атрибут можно рассматривать как группу повторения.

На уровне хранения эта же информация представлена в виде множества значений отношений R' определенных на доменах из множества D'. Как мы уже сказали, что D' - D = {D_OID, D_A}, что, по сути дела, означает, что информация о уникальных идентификаторах объектов o_i и о значениях, определяющих семантику атрибутов, на уровне хранения существует точно в таком же виде, как и информация о собственных значениях этих объектов, а именно в виде явно заданных значений атрибутов кортежей отношений R'. Таким образом, уровень хранения полностью описывается в терминах реляционной модели данных, что говорит о принципиальной возможности реализации метафоры "реляционное ОЗУ". С практической точки зрения этот факт интересен тем, что он позволяет реализовать уровень хранения, используя существующие реляционные СУБД. В наших дальнейших построениях мы будем исходить из того, что уровень хранения должен описываться только в терминах реляционной модели данных.

Стержневое отношение.

Говоря об образующем собственное значение объекта множестве {r₁,r₂….r_n} значений отношений R_i, мы предположили, что возможность, позволяющая организовать такое множество, не может быть описана в терминах реляционной модели и, следовательно, ортогональна ей. С другой стороны данные на уровне хранения полностью описываются в терминах реляционной модели данных. Можно предположить, что механизм, организующий такое множество (в дальнейшем O-механизм), на уровне хранения R' должен использовать атрибуты _ra_OID и _ra_oa, которые определены на доменах D_OID и D_A, не заданных на уровне представления O.

Из соответствию <7> R« R', следует, что на уровне хранения может существовать отношению R'₀(_ra_OID: D_OID, _ra_oa:D_A), для которого на уровне представления соответствующий реляционный домен R₀(Ж) фактически отсутствует. Поскольку имя атрибута не определено, это отношение сводиться к отношению R'₀(_ra_OID: D_OID), где поле _ra_OID будет являться первичным ключом . Главная цель указанного отношения R'₀ – перечислять объектные идентификаторы всех существующих в системе объектов. По сути дела, отношения R'₀ (в дальнейшем мы будем называть его стержневым) организует адресное пространство системы. Поле _ra_OID других отношений R'_i, существующих на уровне хранения , должно быть внешним ключом связанный с R'_{0. r}a_OID. Эта связь гарантирует, что любой кортеж любого отношения R'_i содержит информацию об адресуемом объекте.

Отметим, что в стержневое отношение R'₀ могут входить другие атрибуты, содержащие системную информацию, в частности информация о классе объекта (см. далее "Связь данных и метаданных"). В любом случае существенны два условия: 1) отношение R'₀ должно быть скрыто от пользователя 2) поле _ra_OID должно являться первичным ключом.

Ссылки.

На домене D_OID может быть определен не только атрибут _ra_OID, но и любой другой атрибут _ra_i отношения R'. Этот факт важен, поскольку между множеством OID определенных на D_OID значений объектных идентификаторов (на уровень хранения), и множеством O объектов данных вида <0'> (уровень представления), существует взаимно-однозначное соответствие (OID « O). Это позволяет рассматривать множество объектов как множество, на которых может быть определен любой атрибут _ra_i отношения R, входящего во множество R, и говорить о существования домена D_O (D_O О D) однозначно соответствующего домену объектных идентификаторов D_O. « D_OID, существующему на уровню хранения (D_OID О D').

Таким образом некоторые объекты из множества O могут входить в отношения R_ref (R_refО R) со схемой (… , _ra_ref : D_O, …), которые будут являться реляционными доменами атрибутами других объектов из этого же множества. На уровне хранения отношению R_ref соответствует отношение R'_ref (R'_refО R') со схемой (_ra_OID: D_OID, _ra_oa:D_A,… , _ra_ref : D_OID, …). Рассмотрим объект o_i с атрибутом _oa определенным на реляционном домене R_ref (o_i ) и кортеж t (… , o_ref , …) этого атрибута, поле _ra_ref содержит ссылку на объект o_ref . Используя точечную нотацию можно сказать, что выражение o_i._oa._ra_ref определяет существование множества, содержащее объект o_ref. На уровне хранения кортежу t соответствует кортеж t' (OID_i, o_a, … , OID_ref , …) отношения R'_ref.

Предлагаемый подход позволяет реализовать принцип целостности ссылок, используя реляционные механизмы обеспечения целостности данных. Для этого поле _ra_ref должно быть объявлено как внешний ключ, связанный с полем _ra_OID стержневого отношения R₀, что является гарантией того, что объект с идентификатором OID_ref не может быть удален, пока в системе существует хоть одна ссылка на него.

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

Проектирование схемы данных.

Ортогональные типы.

Как мы сказали, значение объекта является совокупностью значений отношений, принадлежащих множеству R, а возможность, позволяющая организовать множество {r₁,r₂….r_n} этих значений в виде объекта, не может быть описана в терминах реляционной модели и, следовательно, ортогональна ей. С другой стороны, множество объектов O можно рассматривать как домен D_O, на котором может быть определен атрибут отношения из множества R.

Тем самым предполагается, что система типов, служащих для описания информация, состоит из двух ортогональных компонент. Каждая из компонент системы типов обладает присущей только ей свойствами, которые не могут быть выражены в ортогональной компоненте. Первая компонента (классы), включая ограниченный набор предопределенных примитивных типов, описывающих объекты системы хранения, может расширяться за счет классов, определяемых пользователем. Вторая компонента состоит из определяемых пользователем отношений. Любой тип, определенный в одной из компонент может рассматриваться в другой компоненте только как базовый тип: любой класс может (примитивный класс должен) являться доменом атрибута отношения, любое отношений определяется нами как реляционный домен (rdom) на котором определен атрибут класса. Следствием этого является то, что, создавая систему, состоящую из множества объектов, принадлежащих определяемым пользователем классам, мы должны описать моделируемые данные одновременно в обеих компонентах, что позволяет предположить, что системе, основанной на предлагаемом подходе, будут присущи свойства как объектных, так и реляционных систем (далее мы это продемонстрируем).

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

Рассмотрим весьма простую ситуацию. Создавая схему данных, позволяющую описывать предметы, имеющие определенный вес, мы должны определить тип "вес", переменные (возможно сложные) которого будут атрибутами сложных переменных типа "предмет". Предположим, что типы "предмет" и "вес" являются классами, а их переменные объектами. Тогда каждому объекту моделируемой предметной области (т.е. описываемому предмету) в системе хранения будет соответствовать два разных объекта с, соответственно, разными OID: объект класса "предмет" и являющийся его атрибутом объект класса "вес". Адекватна ли эта схема данных описываемой предметной области?

Не вызывает сомнения, что сущность "предмет" должна описываться идентифицируемой переменной. Необходимость идентификации обусловлена тем, тем, что в реальном мире вполне могут существовать два разных предмета, которые на заданном уровне абстракции описываются одинаковой информацией (например, могут существовать два разных предмета имеющие одинаковый вес). Можно утверждать, что для сущности "предмет" объектный идентификатор существенен[11], поскольку именно он идентифицирует эту сущность в рамках информационной системы.

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

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

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

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

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

NoS	Уникальный номер отгрузки
Date	Дата отгрузки
EmpID	Идентификатор ответственного сотрудника
EmpName	Имя сотрудника
GoodsID	Уникальный артикул товара
СoodsName	Наименование товара
Pieces	Количество отгруженного товара (штуки)

На начальном этапе мы должны

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

2) нормализовать имеющуюся схему данных. В процессе нормализации мы получили несколько 3НФ отношений (первый столбец содержит имя атрибута, второй – накладываемые на него ограничения)

rStaff (информация о сотрудниках)

StaffID	Primary key
StaffName

rGoods (информация о товарах)

GoodsID	Primary key
GoodsName

rShipments (общие данные об отгрузках)

NoS	Primary key
Sdate
StaffID

rShipmentComments (необязательные комментарии об отгрузках)

NoS	Primary key, Foreign key on rShipments.NoS
Comments

rShipmentItems(детальные данные об отгрузках)

NoS	Primary key, Foreign key on rShipments.NoS
GoodsID	Primary key, Foreign key on rGoods.GoodsID
Pieces

Дальнейшие шаги по созданию схемы данных основаны на выявлении функциональных зависимостей С->R._ra между классами и ключевыми атрибутами отношений, возникших в процессе нормализации данных. Атрибут функционально зависит от класса в том случае, когда каждому объекту этого класса может соответствовать одно единственное значение атрибута. Интуитивно понятно, что подобные зависимости говорят о том, что информация в кортежах, ключи которых зависят от объекта, характеризуют этот объект и, следовательно, должна быть представлена в виде атрибутов этого объекта.

Существование таких зависимостей, однако, позволяет утверждать, что отношения в том виде, в котором они существуют после процедуры нормализации, требуют дальнейших преобразований. Суть проблемы становиться понятной, когда мы рассмотрим отношений R, атрибут _ra_i которого функционально зависит от класса С (каждому объекту класса C соответствует одно значение атрибута _ra_i , С->R._ra_i). При переходе на уровень представления эта зависимость трансформируется в существующую в соответствующем отношении R' зависимость атрибута _ra_i от системного атрибута _ra_OID, _ra_OID -> _ra_i . И в случае, если атрибут _ra_i входит в состав ключа отношения R, можно утверждать, что соответствующее ему на уровне хранения отношение R' содержит нежелательные функциональные зависимости, что говорит о неоптимальной организации хранящихся данных.

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

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

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

Объектная привязка использует нескольких простых правил. Основное правило звучит так: если ключ отношения, возникшего в результате нормализации, полностью зависит от класса, то схема этого отношение может определять структуру объектов этого класса. Можно выделить случай, когда ключ, полностью зависящий от класса, не является внешним ключом, и не содержит поля, являющиеся внешними ключами. Будем называть такое отношение сильным (другие отношения, соответственно, являются слабыми). В качестве примера можно рассмотреть функциональную зависимоcть, сушествующую между классом cStaff и полем StaffID отношения rStaff (служащему присвоен номер).

На уровне хранения в отношении rStaff' (_ra_OID, StaffID, StaffName) присутствует транзитивная зависимость _ra_OID -> StaffID, StaffID -> StaffName.С другой стороны, поскольку StaffID является ключом (служащему присвоен уникальный номер), можно утверждать, что существует обратная зависимость StaffID -> _ra_OID. По сути дела поле StaffID можно рассматривать как явно заданный ключ класса cStaff (не путать с OID!).

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

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

CLASS cStaff{

}

Тем самым неявно определено свойство одноименное классу и являющее для этого класса главным, корневым. Модификатор GLOBAL UNIQUE, определяющий уникальность значение поля StaffID в объектах класса cStaff, позволяет рассматривать это поле как явно заданный ключ класса cStaff. Существование этого ключа определяется тем, что поле StaffID является ключом сильного отношения. Такому описанию класса (и корневого свойства) на уровне хранение будет соответствовать следующее отношение rStaff'

raOID	Primary key, Foreign key on R0. raOID
raoa
rStaffID	Unique
rStaffName

Аналогичные рассуждения верны для отношений rGoods, которое является основой для класса cStaff. со следующей схемой

CLASS cGoods{

}

PROPERTY pShipmentComments{

    Comments AS STRING;

}

PROPERTY pShipmentItems{

}

Class cShipment{

}

PROPERTY pGoodsSupply{

}

PROPERTY pSupplyItems{

    Good As cGoods UNIQUE;

    Pieces AS INT;

}

CLASS cSuppliesPerDate {

    SupplyDate AS DATE GLOBAL UNIQUE;

    SupplyItems AS SET OF pSupplyItems;

}

CLASS cStaff

}

CLASS cGoods{

}

PROPERTY pShipmentComments{

Comments AS STRING;

}

PROPERTY pGoodsItems {

Good As cGoods PRIMARY KEY;

Pieces AS INT;

}

CLASS cShipments{

	NoS AS LONG GLOBAL UNIQUE;

	SDate As DATE;

	Staff AS cStaff;

	ShipmentItems AS SET OF pGoodsItems;

	Comment AS pShipmentComments; 

}

CLASS cSuppliesPerDate{

	SupplyDate AS DATE GLOBAL UNIQUE;

	SupplyItems AS SET OF pGoodsItems;

}

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

Свойства системы.

Групповые операции. Ненавигационный доступ к данным.

Рассмотрим класс С со схемой (_oa₁:R₁, …, _oa_n:R_n) содержащий объекты {o₁ , … ,o_m}. Предположим, что существует реляционный оператор

_calcR = E( R₁, … , R_n), <11>

где R_i – отношения (rdom), на которых определены атрибуты объектов класса С, _calcR - отношение (rdom), на котором определен результат. Применим оператор E к объекту o_i класса С и рассмотрим выражение o_i.E(_oa₁, … , _oa_n), которое, исходя из значений атрибутов {_oa₁, … , _oa_n} этого объекта, вычисляет некоторое значение _calcr

_calcr_i = o_i.E(_oa₁, … , _oa_n)        <12>

Как мы уже показали, атрибут _oa объекта o на уровне хранения представлен как

s_{(raOID= OID, raoa = oa)}(R') , где R' = rstorage(_oa),          <13>

или

s_{(raOID= OID)}(A), где A = s_{(raoa = oa)}(R').           <13'>

В последнем случае мы рассматриваем подмножество A отношения R', содержащее все значения атрибута _oa всех объектов класса с. Исходя из этого, перепишем правую часть выражение <12> как

o_i.E(_oa₁, … , _oa_n) _Oє_R' E( s_{(raOID= OIDi)}(A₁), … , s_{(raOID= OIDi)}(A_n))           <14>

Для перечисленных далее операторов реляционной алгебры[8,10] справедливы следующие равенства:

-для объединения

s_{( raOID= OID)}(A_k) И s_{( raOID= OID)}(A_m) = s_{( raOID= OID)}(A_k И A_m),

-для пересечения

s_{( raOID= OID)}(A_k) З s_{( raOID= OID)}(A_m) = s_{( raOID= OID)}(A_k З A_m),

-для декартова произведения

s_{( raOID= OID)}(A_k) ґ s_{( raOID= OID)}(A_m) = s_{( raOID= OID)}(A_k ><_{( raOID)} A_m),

-для вычитания

s_{( raOID= OID)}(A_k) - s_{( raOID= OID)}(A_m) = s_{( raOID= OID)}(A_k - A_m),

-для проекции

p_(rai) (s_{( raOID= OID)}A_k) ) = s_{( raOID= OID)}( p_(rai) (A_k) ),

-для выборки

s_(q)( s_{( raOID= OID)}(A_k)) = s_{( raOID= OID)}( s_(q)(A_k) ), где q - предикат ,

-для соединения

s_{( raOID= OID)}(A_k) ><_F s_{( raOID= OID)}(A_m) = s_{( raOID= OID)}(A_k ><_{(raOID and F)} A_m), где F – предикат,

-для деления

s_{( raOID= OID)}(A_k) ё s_{( raOID= OID)}(A_m) = s_{( raOID= OID)}(A_k ё A_m).

Исходя из этого, можно утверждать, что для любого выражения E (уровень представления данных) найдется такое выражение E' (уровень хранения данных), что

o_i.E(_oa₁, … , _oa_n) _Oє_R' s_{( raOID= OIDi)}( E' (A₁, … , A_n))           <15>

Рассмотрим объединение результатов применение оператора E к объектам из множества g_C = {o₁ , … ,o_k} , g_C Н С

o₁.E(_oa₁, … , _oa_n) И … И o_k.E(_oa₁, … , _oa_n) _Oє_R'

s_{( raOID= OID1)}( E' (A₁, … , A_n)) И … И s_{( raOID= OIDk)} ( E' (A₁, … , A_n))           <16>

из чего следует, что

o₁.E(_oa₁, … , _oa_n) И … И o_k.E(_oa₁, … , _oa_n) _Oє_R' s_{(raOID О {OID1, … , OIDk})} ( E' (A₁, … , A_n))           <17>

Это позволяет утверждать, что реляционный оператор E применим и к множеству g_C объектов класса С

g_C.E(_oa₁, … , _oa_n). <18>

Рассмотрим класс C ={o₁ , … ,o_m} со схемой (_oa₁:R₁, …, _oa_n:R_n) целиком. Поскольку речь идет о всех объектах, входящих в класс, можно утверждать, что множество их идентификаторов {OID₁, … , OID_m} равно множеству p_(raOID) A_i для любого атрибута _oa_i класса C ( A_i = s_{( raOID= OIDi)}(R'), где R' = rstorage(_oa_i), _oa_i О Schema(С). Исходя из этого, можно показать, что

С.E(_oa₁, … , _oa_n) _Oє_R' E' (A₁, … , A_n)                <19>

Таким образом, предлагаемый подход допускает использование основанных на реляционной алгебре групповых операций, которые могут применяться к множествам объектов одного класса. Важнейшим следствием этого является то, что классы можно рассматривать как интенсиональные множества [1] объектов, причем принадлежность объектов к этим множествам однозначно определяется уже в момент создания объекта.

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

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

Предлагаемая альтернатива основана на том, что на уровне хранения информация об объектных идентификаторах существует точно в таком же виде, как и информация о собственных значениях этих объектов, а именно в виде явно заданных значений атрибутов кортежей отношений. В самом деле, любое отношения A_i ( A_i = ( s_{( raOID= OIDi)} (R'), где R' = rstorage(_oa)) входящее в состав выражения E' (…,A_i ,…) содержит атрибут _ra_OID определенный на домене D_OID и, следовательно, указанный атрибут может являться атрибутом отношения, являющегося результатом вычисление выражения E'. Рассмотрим оператор E' (A₁, … , A_n), результатом которой является отношение _calcR' со схемой {… , _ra_OID : D_OID, …}. Поскольку значения атрибута _ra_OID любого из исходных отношений A_i ограничены классом C, в котором определен атрибут a_i, а также с учетом взаимно-однозначного соответствия OID « O, можно предполагать, что результатом соответствующей ей на уровне представления операции E(С) будет являться отношение _calcR со схемой {… , _ra_o : C, …}.

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

Примером может служить запрос, который будет возвращать количество товара, отгруженного сотрудником сегодня

SELECT Sum(ShipmetItems.Pieces)

	FROM cShipment

	WHERE cShipment.Date = Today()           <П.1>

Групповые операции над ссылками.

Поскольку отношение R_ref'(см. раздел "Ссылки") содержит значения всех определенных на реляционном домене R_ref атрибутов всех существующих в системе объектов, можно утверждать, что это отношение R' содержит все пары (OID_i OID_ref) описываемые ссылкой _oa._ra_ref. Это позволяет говорить о возможности групповых операций над ссылками. Рассмотрим множество g_с = (o₁ , … ,o_n) объектов класса c, содержащего атрибут _oa определенный на ранее описанном реляционном домене R_ref. Можно говорить о том, что на уровне представления данных возможна операция

g_ref = p_(raref)(g_c._oa._ra_ref)             <20>

которая возвращает множество объектов g_ref, на которые ссылаются объекты, входящие в множество g_c. На уровне хранения она будет реализовываться следующим образом

p_(raref)(g_c._oa._ra_ref) _Oє_R p_(raref) ( s_{(raOID О {OID1, … ,OIDn}, raoa = oa)}(R')) , где R' = rstorage(_oa)                <21>

Так же возможна операция, разрешающая обратную ссылку. Например, для объекта o_ref можно найти множество g_backref объектов класса c, которые ссылаются на него по ссылке _oa._ra_ref:

g_backref = p_(с) (s_{(raref = oref)}(с._oa._ra_ref))                <22>

На уровне хранения данной операции соответствует следующее выражение:

p_(с) (s_{(raref = oref)}(с._oa._ra_ref)) _Oє_R p_(raOID) ( s_{(raref = OIDrefi, raoa = oa)}(R')), где R' = rstorage(_oa)         <23>

Примером может служить запрос, который будет возвращать количество товара, отгруженного сотрудником с именем Вася Петров

SELECT Sum(ShipmetItems.Pieces)

	FROM cShipment

	WHERE cShipment.Staff.StaffName = ' Вася Петров ' <П.2>

Вычисляемые атрибуты объектов. Инкапсуляция.

Рассматривая атрибут _oa объекта o_i, до сих пор мы предполагали, что на уровне хранения он представлен как подмножество кортежей отношения R', o_i._oa _Oє_R' s_{(raOID= OIDi, raoa = oa)} (R') где R' = rstorage(_oa). Будем называть такой атрибут хранимым. Однако возможен и другой случай, когда значение атрибута объекта вычисляется исходя из значений других атрибутов данного объекта. Будем называть такие атрибуты вычисляемыми.

Рассмотрим реляционный оператор E_a

R₁ = E_a( R₂, … , R_n),

где R_i – отношения, являющиеся реляционными доменами (rdom), на которых определены атрибуты объектов класса С. Применим оператор E к объекту o_i класса С и рассмотрим выражение

o_i. _oa₁ = o_i.E(_oa₂, … , _oa_n),

которое, исходя из значений атрибутов _oa₂, … , _oa_n, вычисляет значение атрибута a₁.

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

o. _oa₁ = o_i.E(_oa₂, … , _oa_n) _Oє_R' s_{(raOID= OIDi)}( E'_a (A₂, … , A_n)) ґ {a₁}              <24>

, где {a₁} - 1-арное отношение, единственный кортеж которого содержит имя вычисляемого атрибута { a₁ }. Рассмотрим класс C и значение C.a₁ = {o₁. _oa₁ И … И o_k.a₁}. Можно показать, что

С. _oa_{1 O}є_R' A₁ , A₁ = E'_a (A₂, … , A_n) ґ {a₁}                    <25>

Выражение E_a , вычисляющее значение атрибута, должно входить в метаданные, описывающие структуру объекта. Таким образом, схема S содержащего вычисляемые атрибуты объекта класса С (S = Schema(C) ), будет выглядеть следующим образом:

S = {_oa₁:R₁:E_a (_oa₂, … , _oa_n), _oa₂:R₂,…, _oa_n:R_n}              <26>

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

_calcr_i =С.E(_oa₁, … , _oa_n) _Oє_R' E' (A₁ , … , A_n)               <27>

зависит исключительно от типов (rdom) использующихся в ней атрибутов a_i, и не зависит от того, является эти атрибуты хранимыми или вычисляемыми. Оператор Е может быть определен на основании схемы _publicS = {_oa₁:R₁, _oa₂:R₂,…, _oa_n:R_n}, которую можно рассматривать как спецификацию схемы объектов класса С. Информация же об ассоциированных с атрибутами операторах Е_а, служащих для вычисления значений этих атрибутов, не является необходимой для использования объектов класса С (естественно, речь идет об использовании в операциях, основанных на реляционной алгебре), и, фактически, описывает некоторую реализацию схемы объектов класса . Это позволяет утверждать, что предлагаемый подход позволяет реализовать принцип инкапсуляции [4,1] - один из основных принципов объектно-ориентированного программирования, предполагающий разделения спецификации и реализации объекта.

Наследование.

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

Рассмотрим класс С со спецификацией _publicS_C = {_oa₁:R₁, _oa₂:R₂,…, _oa_n:R_n}. Предположим, что для этого класса определен реляционный оператор E

С.E(_oa₁, … , _oa_n)

Рассмотрим класс Сi, являющийся наследником класса C. Спецификация класса Сi определяется как _publicS_Ci = S_C И {_oa_n+1:R_n+1,…, _oa_p:R_p } = {_oa₁:R₁, _oa₂:R₂,…, _oa_n:R_n, _oa_n+1:R_n+1,…, _oa_p:R_p }. Поскольку объекты класса Ci содержат те же атрибуты, определенные на тех же реляционных доменах (rdom), что и в объекты класса С, то можно утверждать, что оператор Е применим и к объектам любых классов Ci являющихся наследниками класса C. Это позволяет рассматривать объекты классов-наследников как объекты родительского класса С.

В свете этого имеет смысл более подробно рассмотреть отношения, существующих между множеством O объектов и множеством C классов. Можно выделить два типа отношений. Первое, традиционно обозначаемое как отношение ISA, характеризуется фразой "объект o_i является объектом класса C". Эта связь учитывает существующую между классами связь "обобщение-специализация", которая определяет иерархию наследования. Отношение ISA описывает связь типа "многие ко многим" – один класс может содержать множество объектов и, поскольку объекты класса-наследника считаются объектами родительского класса, одному объекту может соответствовать несколько классов. Если объект o_i связан с классом C связью ISA, можно утверждать, что спецификация этого объекта содержит атрибуты, определенные в спецификации класса, ISA (o_i,C) => _publicSchema(C) Н _publicoSchema (o_i)

Второе отношение, которое в дальнейшем мы будем обозначать как отношение OFA, описывает связь, характеризующуюся фразой "объект o_i создан как объект класса C". Эта связь не учитывает наследования и является связью типа "многие к одному", из чего следует, что отношение OFA является функциональным, O –^OFA-> C. Для объектов и связанных с ними связью OFA классов существует точное соответствие схемы объекта и схемы класса, OFA (o_i,C) => oSchema (o_i) = Schema(C).Обратное отношение OFA^-1 ,для каждого класса C будет формировать множество объектов D_C, созданных как объекты класса C, D_C = OFA^-1(C). Заметим, что множества объектов D_C являются непересекающимися D_Ci  З D_Ci   = Ж если С_i № С_j.

Рассмотрим множество I_C0 классов С_i содержащий атрибут _oa, _oa О _publicSchema (C_i). Эти классы образуют иерархию наследования, где и один из них - класс С₀ , в котором атрибут _oa объявлен впервые - является родительским для остальных классов C_i (i > 0), наследующих этот атрибут. Множество объектов, входящих в класс С₀, является объединением всех объектов, созданных как объекты классов, входящих в иерархию I_C0, C₀ = И D_Ci , где C_i О I_C0. Таким образом, значение C₀._oa, представляющее собой объединение значений атрибутов _oa объектов, принадлежащих классу C₀, является объединением значений D_Ci .  _oa, представляющих собой объединения значений атрибутов _oa объектов, созданных как объекты класса, входящих в иерархию I, С₀._oa = D_Ci . _oa, где D_Ci . _oa = o._oa.

Переопределение атрибутов.

Значение вычисляемого атрибута _oa определяется оператором E_a, ассоциированным с этой переменной. Поскольку этот оператор определен только в реализации схемы объектов класса C, можно предположить, что он может переопределяться в процессе наследования. Отметим, что переопределение, подразумевающее изменение реализации схемы объектов при неизменной спецификации, является одним из способов создания полиморфных[4] систем.

Рассмотрим класс С₀ со схемой S_C0 = {_oa₁: R₁: _C0E_a , _oa₂:R₂,…, _oa_n:R_n}. Атрибут _oa₁ вычисляется исходя из значений других атрибутов выражением _C0E_a, _oa₁ = _C0E_a (_oa₂, … , _oa_n). Предположим, что для этого класса определен реляционный оператор E

С₀.E(_oa₁, … , _oa_n)

Рассмотрим иерархию I_C0 и входящие в нее классы С_i (i > 0), которые являются наследником класса C₀ и имеют схему S_Ci = { _oa₁:R₁:_CiE_a, _oa₂:R₂,…, _oa_n:R_n, _oa₂:R₂,…, _oa_n:R_n, _oa_n+1:R_n+1,…, _oa_p:R_p }. В процессе наследования, выражение, вычисляющее значение атрибута _oa₁, может быть переопределено, причем, возможно, оно будет учитывать значения атрибутов _oa_n+1,…, _oa_p, отсутствующих в родительском класса C₀

_oa₁ = _CiE_a (_oa₂, … , _oa_p).

Рассмотрим значение С₀._oa₁ представляющее собой объединение значений атрибутов _oa₁ объектов класса С₀, o О C₀

С₀._oa₁ = D_Ci . _oa₁ , где D_Ci._oa = o._oa.                    <28>

Как мы ранее показывали, значение переопределяемого атрибута _oa объекта o_k любого из классов C_i на уровне хранения будет вычисляться следующим выражением

o_k._oa₁ = o_k. _CiE(_oa₂, … , _oa _n, …) _Oє_R' s_{(raOID= OIDk)} (_CiE'_a (A₂, … , A_n, … )) ґ {a₁}                <29>

Выражение, объединяющее значения атрибутов _oa всех объектов, созданных как объекты класса С_i, будет выглядеть как

D_{Ci o}a₁ = D_Ci . _CiE(_oa₂, … , _oa _n, …) _Oє_R' s_{(raOID OFA Ci )}( _CiE'_a (A₂, … , A _n, …)) ґ {a₁}              <30>

(реализация предикатов OFA и ISA на уровне хранения будет рассмотрена далее – см. "Связь данных и метаданных"). Следовательно, значение С₀._oa₁ представляющее собой объединение значений атрибутов _oa₁ полиморфных объектов класса С₀, на уровне хранения будет вычисляться как

C₀.a_{1 O}є_R' (s_{(raOID OFA Ci )}( _CiE'_a (A₂, … , A _n, …)) ) ґ {a₁}              <31>

Случай, когда переопределяемый атрибут a₁ в процессе наследования становиться или, наоборот, перестает быть хранимым, выглядит немного сложнее:

C₀.a_{1 O}є_R' (  (s_{(raOID OFA Ci )}( _CiE'_a (A₂, … , A _n, …)) ) ґ {a₁}  )  И A₁        <32>

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

Возможность переопределение атрибутов заслуживает внимания, поскольку позволяет создавать гибкие расширяемые системы. Рассмотрим групповой реляционный оператор С₀.E(_oa₁, … , _oa_n), который может применяться к множеству объектов класса C₀. Принимая во внимание тот факт, что он определен на основании спецификации схемы объектов этого класса, можно утверждать, что его можно применять к объектам, принадлежащим любым классам C_i, наследующим класс С₀, в том числе и классам с переопределенными атрибутами.

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

PROPERTY pSaledGoods{

Good As cGoods PRIMARY KEY;

Price As DOUBLE;

Pieces AS INT;

}

С учетом всего сказанного, схема класса cSales должна содержать выражение, переопределяющее описанный в классе cShipment аргумент ShipmentItems таким образом, что бы он вычислялся на основании данных о продажах, хранящихся в атрибуте, определенным на свойстве pSaledGoods

CLASS cSales EXTENDS cShipment {

…;

SalesItems AS pSaledItems; //Теперь данные хранятся здесь.

REDEFINE ShipmentItems //Этот аргумент вычисляется на основании данных…

AS SELECT Good, Pieces FROM SalesItems; // …хранящихся в SalesItems.

…; 

} <П.4>

Поскольку такая схема реализует спецификацию класса cShipment, можно утверждать, что объекты класса cSales являются один из вариантов объектов полиморфного класса cShipment. Особо отметим, что созданные ранее (см. <П.1> и <П.2>) запросы, возвращающие информацию об отгруженном товаре, останутся корректными, и по-прежнему будут возвращать информацию обо всем отгруженном товаре, включая информацию о товаре, отгруженном в рамках продаж.

Метаданные.

Схема данных, описывающая предметную область в терминах классов и свойств, определяет существование множества C классов, множества _oa их атрибутов, множества R отношений (свойств), являющихся реляционными доменами этих атрибутов, а также ряда отношений между указанными множествами. Совокупность перечисленных множеств и отношений представляет собой метаданные (данные о данных), позволяющие представить данные, хранящиеся в терминальном механизме хранения данных (реляционное ОЗУ), в терминах используемой абстракции (свойства и классы).

Предполагая, что единственно возможный терминальный механизм хранения данных основан на реляционной модели данных, можно утверждать, что и сами метаданные должны храниться в виде набора отношений, совокупность которых образует каталог системы. Таким образом, перманентное реляционное ОЗУ используется для совместного хранения данных и метаданных,

Каталог.

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

1)RDOMENSs - перечисляет существующие реляционные домены - отношения из множества R (rdom)

IDR

Primary key

Уникальный идентификатор реляционного домена.

Для любого реляционного домена R, отношение RDOMENSs должно содержать единственный кортеж, ключевое поле IDR которого содержит значение id_R , идентифицирующее этот домен.

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

2) CLASSES - перечисляет существующие классы.

IDC

Primary key

Уникальный идентификатор класса (например имя класса).

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

3) ISA – определяет отношение ISA, существующее между классами (множествами объектов)

IDC	Primary key, Foreign key on CLASSES.IDC	Идентификатор класса.
ISAС	Primary key, Foreign key on CLASSES.IDC	Идентификатор класса с которым класс IDC связан отношением ISA.

Это отношение содержит информацию о классах, связанных отношением ISA. Например для класса С'' , являющегося наследником С', который в свою очередь наследует базовый класс C, отношение ISA должно содержать кортежи {id_C'', id_C''}(класс С'' является сам собой), {id_C'', id_C'} (класс С'' является наследником класса C'), и {id_C'', id_C} (класс С'' является наследником базового класса C). Таким образом, отношение ISA содержит полную информацию о иерархии наследования. Применяя к нему оператор выборки, для любого класса С' можно найти все его классы наследники, или все классы, для которых он является наследником.

4) ATTRspecification –перечисляет существующие атрибуты, определяет, в каких классах они впервые объявлены, определяет реляционный домен (rdom) каждого атрибута

oa	Primary key	Уникальный идентификатор объектного атрибута (например имя атрибута).
IDC	Foreign key on CLASSES.IDC	Идентификатор класса, где этот атрибут впервые объявлен.
IDR		Уникальный идентификатор отношения, являющегося реляционным доменом (rdom) этого атрибута.

Если в классе C впервые объявлен атрибут _oa_i, определенный на реляционном домене R, то это отношение будет содержать кортеж { _oa_i, id_C, id_R}.

5) ATTRrealization – описывает реализацию атрибутов в классах и в наследуемых классах, содержит данные, которые могут быть переопределены в процессе наследования

oa	Primary key, Foreign key on ATTRspecification.oa	Иденитфиткатор объектного атрибута.
IDC	Primary key, Foreign key on CLASSES.IDC	Идентификатор класса, содержащего этот атрибут (из-за наследования таких классов может быть много).
Expr		Выражение, вычисляющее значение атрибута (может переопределяться в процессе наследования классов, отсутствует для хранимых атрибутов).

Если атрибут _oa_i базового класса С переопределен в классе-наследнике C', то это отношение должно содержать кортежи { _oa_i, id_C, _CE} и { _oa_i, id_C', _C'E}, где _CE и _C'E –определенные в классах C и C' выражения, вычисляющие значение атрибута _oa_i. Для хранимых атрибутов выражение _CE может отсутствовать.

Связь данных и метаданных.

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

Описывая стержневое отношение R'₀, существующее на уровне хранения, мы сказали, что в него могут входить атрибуты, характеризующие объекты данных, входящие в состав системы. Важнейшей характеристикой всех без исключения объектов данных является класс этих объектов, поэтому в стержневое отношение должно входить поле IDC связанное с первичным ключом отношения CLASSES. Таким образом, каждому объекту данных ставиться в соответствие схема данных класса, который указан в выражении, которым этот объект был создан. Система должна контролировать, что структура объекта на протяжении всей его соответствует схеме данных, определенной для объектов этого класса.

Таким образом, схема стержневого отношения должна выглядеть следующим образом:

R'₀

raOID	Primary key
IDC	Foreign key on CLASSES.IDC

Рассмотрим выражение

new cShipment;

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

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

new cShipment(123);

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

UPDATE cShipment SET cShipment.SDate = "…" WHERE cShipment.NoS = 123

Отметим следующее. Поскольку для каждого объекта данных на всем протяжении его жизни в стержневом отношении хранится информация о том, что этот объект создан как объект определенного класса, то можно утверждать, что стержневое отношение R'₀ и отношение OFA суть одно и тоже. Введенный ранее предикат OFA реализуется на уровне хранения простой выборкой кортежей этого отношения по атрибуту IDC. Например следующая часть выражение <30> s(_ra_OID OFA C_i )( _CiE'_a (A₂, … , A _n, …)) будет реализована как

s_{(IDC = Ci )}( R'₀ ><_(raOID) ( _CiE'_a (A₂, … , A _n, …)) )                    <30'>

Релизация предиката ISA немногим более сложна. В этом случае мы должны использовать отношение ISA существующее в каталоге системы.

s_{(raOID ISA Ci )}( E'_a ( … , A _n, …)) = s_{(ISAIDC = Ci)} (ISA ><_IDC ( R'₀ ><_(raOID) ( _CiE'_a (A₂, … , A _n, …)) ) )

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

1) Изменение схемы свойства R, определенного на уровне представления, сводится к изменению схемы отношения R', которое существует на уровне хранения.

2) Изменения схемы класса (например: добавление или удаление атрибутов класса, изменение вычисляющих выражений и т.п.), на уровне хранения сводится к кортежным операциям над отношениями ISA, ATTRspecification и ATTRrealisation, входящим в каталог системы.

Во втором случае, для контроля корректности изменения схемы класса, можно использовать связь между атрибутом _ra_oa, каждого из отношений R'_i, и атрибутом _oa отношения ATTRspecification, являющегося первичным ключом этого отношения. Существование такой связи позволяет гарантировать, что для всех кортежей всех отношений R'_i в каталоге существуют ассоциированные с ними описания атрибутов, позволяющие привести хранящиеся в них данные к виду, определяемому используемой абстракцией, т.е. представить эти данные как значения атрибутов объектов данных.

Указанные связи между данными и метаданными (уровень хранения), а также связь между отношениями R'_i и стержневым отношением R'₀, определяют целостность объектов данных o (уровень представления), описываемых как {OID, S, oV}, где OID – уникальный идентификатор указанной переменной, S – метаданные, описывающая структуру указанной переменной, oV - сложное значение, описывающее состояние объекта.

Методы.

Одно из наиболее важных свойств объектно-ориентированных систем определяется тем, что объект характеризуется не только состоянием (набор значений атрибутов) но и поведением [4], выраженным через множество методов, применимых к объекту и инкапсулированных в нем. Методы позволяют управлять состоянием объекта и, следовательно, системы в которую он входит. Таким образом, системы, реализующие объектно-ориентированный подход, объединяют структурные и поведенческие аспекты описания и использования данных.

Предлагаемый подход не содержит каких-либо принципиальных ограничений на определение и использование методов, которые, подобно атрибутам, могут наследоваться и переопределяться. Если предположить, что уровень хранения основан на существующих реляционных СУБД, то метод класса может быть реализован в виде ассоциированной с классом хранимой процедуры, получающей в качестве параметра объектный идентификатор объекта, для которого он вызван. Отметим, что этот идентификатор может быть получен в результате выполнения групповой операции над классом (см. "Групповые операции. Ненавигационный доступ к данным"). Таким образом, возможны вызовы методов из непроцедурных языков высокого уровня. Например, следующее выражение вызовет метод DoShip для объекта класса cShipment, который содержит данные об отгрузке с номер 123

EXEC cShipment.DoShip() WHERE cShipment.NoS = 123.

Можно предположить, что метод может быть вызван и для группы объектов.

EXEC cShippment.DoShip() WHERE cShipment.sDate = Today() <П.5>

Естественно, что возможен вариант, когда к методу неприменимо преобразование, описанное в главе "Групповые операции. Ненавигационный доступ к данным" (например, это будет верно для методов, выполняющих покортежную обработку атрибутов объекта). В этом случае выражение <П.5> может быть реализовано только в виде итератора, последовательно обращающегося к каждому из объектов входящих в обрабатываемую группу. Однако сама группа будет формироваться в результате групповой операции над классом.

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

Заключение.

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

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

Конечно, в небольшой статье невозможно предусмотреть все вопросы, которые могут возникнуть при знакомстве c предложенным подходом. Однако предлагаемые решения могут быть вполне достаточными для практической реализации в виде системы, которая может представлять определенный интерес для широкого круга пользователей.

Автор благодарит участников форума "Проектирование БД", расположенного на сайте www.sql.ru, принявших активное участие в обсуждении статьи, за их ценные замечание и предложения.

Используемая литература:

1. Системы баз данных третьего поколения: Манифест. Комитет по развитию функциональных возможностей СУБД СУБД №02/95
2. Х.Дарвин, К.Дэйт. Третий манифест. СУБД № 1/1996
3. М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С. Здоник. Манифест систем объектно-ориентированных баз данных. СУБД № 4/1995
4. Гради Буч Объектно-ориентированое Проектирование с примерами применений 1992 Диалектика(Киев) & И.В.К. (Москва)
5. Дж.Мартин. Организация баз данных в вычислительных системах. Изд. 2-е 1980 Мир (Москва)
6. C.J. Date. The relational model will stand the test of time. Intelligent Enterprise, 1999, Vol. 2, No 8
7. Codd E.F. “A relational model for large shared data banks”. Commun. ACM 13, 6, June, 1970, 377-387
8. Д. Мейер. Теория реляционных баз данных. 1984 Мир (Москва)
9. Крис Дейт. Введение в базы данных. Изд. 6-е. Киев, Диалектика, 1998.
10. Конноли, Томас и др. Базы данных: Проектирование, реализация и сопровождение. Теория и практика: 2-е изд., испр. и доп.Москва. Изд.дом "Вильямс",2000.
11. An Analysis of Codd's Contribution to the Great Debate C.J. Date Intelligent Enterprise, May 11, 1999, Volume 2, № 7
12. Модель "Объект-качество". Евгений Григорьев. http://www.citforum.ru/database/articles/moq.shtml

1) Определение "кибернетические" в данном случае означает "управляемые". При  определенных внешних воздействиях (в ответ на определенную команду) такая система определенным образом меняет свое состояние. (назад к тексту)

2) Фактически, терминальная система хранения данных предопределяет  существующий в языках программирования набор "базовых" типов (например, целочисленный тип). Она представляет собой среду существование переменных базовых типов и реализует операции над этими переменными.  Говоря про "базовые типы", нельзя не обратить внимание на то, что это понятие обычно ассоциируется с набором простейших типов, реализуемых аппаратной частью компьютера (например, byte, char, int, float и т.п.). Однако отметим, что терминальный механизм не обязательно реализуется аппаратно (в качестве примера можно привести виртуальную Java-машину). Можно предположить, что базовые типы могут быть произвольно сложными - при условии, что эта сложность полностью реализована на уровне терминальной системы. (назад к тексту)

3) Единственным типом, реализуемым реляционными системами хранения данных, является тип "отношение". Переменными этого типа являются переменные отношения "relvar" ( или, в терминах SQL-систем, таблицы) служащие для хранения значений отношений "relval". Реляционная БД - это БД в которой все данные представлены в виде набора значений отношений [9]. (назад к тексту)

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

 

Евгений Григорьев (С) 2003. Некоторые идеи, изложенные в статье, имеют патентную защиту.