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

• Качественные атрибуты объектов
• Семантика объектных атрибутов
• Формализм (1)
• OID. Качество "уникальный объект"
• Формализм (2). Отображение "объекты" "отношения"
• Стержневое отношение RO
• Ассоциативные качества. Ссылки
• Объекты
• Каталог
• Как это работает
• Свойства модели "объект-качество" и реализующей ее системы
  

Качественные атрибуты объектов

Значение атрибута объекта как значение отношения

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

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

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

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

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

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

1. совокупности изменяющихся во времени табличных отношений, основными свойствами которых являются ключи и домены;
2. правил вставки-обновления-удаления (соблюдение ограничений по первичным и внешним ключам);
3. реляционной алгебры состоящей из набора реляционных операторов.

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

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

Семантика объектных атрибутов

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

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

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

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

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

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

Формализм (1)

Придадим сказанному более точный смысл.

Пусть существует конечное множество D доменов {D₁, D₂..., D_n}, и множество Q определенных на D отношений

Пусть существует домен D_S (DОD), содержащий значения, которые можно рассматривать как уникальные имена D_S = {S₁, S₂, .... S_m}. Каждому имени Si ставиться в соответствие подмножество s_i отношение Q_j, которое можно назвать доменом Q_j = dom(s_i) ,1<=i <=m, Q_j ОQ.

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

Схемой класса С называется конечное подмножество D_S, C = {S_i | S_i D ОS} (будем называть такое S_i именем атрибута класса С). Тогда класс c со схемой C - это конечное множество отображений {o₁, o₂, ..., o_k} из C в Q, причем каждое отображение oс должно удовлетворять следующему ограничению: o(s_i) Н Q_i. Такие отображения o будем называть объектами. Другими словами , объектом о класса c называется множество {s_i:S_i | s_i является именованным (имеющим имя S_i) подмножеством соответсвуещего Q_j , s_i Н Q_j }.

Поскольку D_S можно рассматривать как объединение всех схем классов C (D_S = C₁И C₂И ....И C_m, где m - число классов существующих в системе), то множество всех объектов всех классов O=c₁И c₂И ....И cm можно рассматривать как множество отображений из домена Ds в то же самое множество Q.

OID. Качество "уникальный объект"

Понятие "уникальный объектный идентификатор" (OID) является одним из основных в СОК. Как уже говорилось, именно OID, являясь единственным критерием позволяющим отличить один объект от другого, используется в объектных системах для организации доступа к объектам. Любому объекту oi на всем протяжении его жизни соответствует одно уникальное и неизменное значение OID_i . Множество возможных значений OID образует домен D_OID. Следует отметить, что понятие OID служит для описания логической организации данных, то есть относится к логической уровню СОК. Рассмотрим, что же представляет из себя OID с концептуальной точки зрения.

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

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

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

Подобно любому другому, качество "уникальный объект" обладает реляционной природой. Множество значений этого качества можно рассматривать как отношение Q_OID. Каждому объекту O_i, идентифицируемому соответствующим OID_i, в модели "объект-качество" соответствует один и только один кортеж отношения Q_OID. Таким образом ранее описанный домен D_OID, являющийся множеством возможных значений уникальных идентификаторов объектов, может и должен рассматриваться как домен, на котором определен атрибут отношения Q_OID, являющийся первичный ключ этого отношения.

Формализм (2). Отображение "объекты""отношения"

Пусть существует домен D_OID (D_OID D), содержащий значения, являющиеся уникальными идентификаторами, и каждому объекту о существующему в системе ставиться в соответствие одно и только одно значение из этого домена т.е. O   D_OID. Поскольку любое o (o   O) мы рассматриваем как отображение из D_S в Q, и каждому такому отображение соответствует определенное значение O_ID (O_IDD_OID), то O можно рассматривать как подмножество прямого произведения D_OID, D_S и Q

O М D_OID ґ D_S ґ Q (2)

Исходя из того, что предыдущее выражение можно переписать как

Замечание. Поскольку каждому Q ставиться в соответсвие множество dom^-1(Q) именованных атрибутов s, для которых это Q является доменом Q=dom(s), s Оdom^-1(Q) , dom^-1(Q) Н DS то более точным будет выражение

Выражение (3) можно переписать как

Видно, что множество O является реляционной системой. Каждому значению <d₁,...,dn>качества Qi со схемой [D₁, ..., Dn ], входящему в атрибут sj, объекта ok соответствует кортеж <OIDk, Sj, d₁, ..., d_n> отношения R_i со схемой [D_OID:OID, S, D₁, ..., D_n ]. Каждому качеству Q_i ставиться в соответствие отношений R_i, содержащее значения всех атрибутов этого качества, принадлежащих всем существующим в системе объектам. Любой набор данных представленный в виде О (множество объектов) может быть сохранен в виде R (множество отнощений). Другими словами модель "объект-качество" определяет однозначный переход от объектного представления данных (объектный уровень или уровень представления данных) к их реляционному хранению (реляционный уровень или уровень хранения данных). Именно этот переход и должна осуществить система, построенная на основании модели "объект-качество".

Наиболее интересным является то, что уровень хранения является полностью реляционным и описывается в терминах доменов и отношении. Таким образом, модель "объект-качество" не меняет реляционную модель - но она позволяет представить информацию хранящуюся реляцонно, в виде сложных идентифицируемых объектов. Архитектура систем хранения и обработки информации, основанных на таком подходе, может быть проиллюстрирована следующим образом:

Рассмотрим отношение R_i со схемой [D_OID:OID, S, D₁, ..., D_n ] (уровень хранения). Любое такое отношение имеет атрибуты OID и S. Будем называть их K-частью (от англ. key) отношения R_i. Главная функция этих атрибутов - представить информацию, содержащуюся в остальных атрибутах D₁, ..., D_n (будем называть их Q-частью (от англ. quality) отношения R_i) любого из кортежей этого отношения как значение качества, входящее в определенный атрибут (S) того или иного объекта (OID). К-часть отношения любого отношения R_i неизменна - она должна генерироваться и поддерживаться системой. Схема Q-части должна соответствовать схеме соответствующего качества Q_i, которое определяется пользователем.

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

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

В выражении (4) случай, когда i = 2, определяет существование особого отношения R_o со схемой [D_OID:OID, S]. Обратим особое внимание на то, что, поскольку в этом отношении отсутствует Q-часть, его существование не может быть определено путем явного задания на уровне представления какого-либо качества Q и, следовательно, должно поддерживаться системой по умолчанию. Поскольку на уровне представления отношение R₀ никак не представлено, то атрибут S отношения R₀ не играет никакой роли и, в принципе, может отсутствовать.

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

В связи с отсутствием Q-части и неопределенностью атрибута S в качестве первичного ключа отношения R₀ может использоваться только атрибут OID. Для всех остальных отношений R_i (i > 0) множества R атрибут OID должен рассматриваться как внешний ключ, связанный с первичным ключом отношения R₀. Следствием этого является то, что каждому существующему в системе объекту будет обязательно будет соответствовать один и только один кортеж этого отношения. Таким образом, отношение R₀ связывает кортежи всех остальных отношений по атрибуту OID, перечисляя OID всех существующих в системе объектов (по этим причинам оно может быть названо стержневым). Стержневое отношение является важнейшим компонентом модели "объект-качество", позволяющим представить множество кортежей различных отношений в виде единого объекта.

Ассоциативные качества. Ссылки

Межобъектные ассоциации представляются в модели "объект-качество" точно так же как и любая другая информация об объектах, то есть как качество. В дальнейшем мы будем называть такое качество ассоциативным. На уровне представления такое ассоциативное качество в самом общем виде может быть описано как отношение Q_a со схемой [D_OID:ref₁ .... D_OID:ref_i, D_j, ..., D_n] где ref₁ .... ref_i атрибуты, содержащие OID ассоциированных объектов (т.е. эти атрибуты определены на домене D_OID), а D_j, ..., D_n - атрибуты содержащие другую информацию об этой ассоциации.

Замечание. Поскольку OID представляют объекты, отношение Q_a может интерпретироваться системой как ассоциация объектов со схемой [O:O₁ .... O:O_i, D_j, ..., D_n], где O₁ .... O_i - ассоциируемые объекты принадлежащие множеству объектов O., и даже (если системой поддерживается такой контроль типов) как ассоциация объектов со схемой [c₁:O₁ .... с_i:O_i, D_j, ..., D_n] где O₁ .... O_i - ассоциируемые объекты принадлежащие классам c₁ … c_i. В последнем случае классы c₁ … c_i рассматриваются как домены отношений. Таким образом, модель "объект-качество" не противоречит подходу предлагаемому Дейтом, где класс и домен рассматриваются как эквивалентные понятия.

Обратим особое внимание на то, что речь идет о качестве, и, следовательно, существуют объекты, описываемые различными значениями этого качеством. Таким образом, ассоциативное качество подразумевает, что помимо ассоциируемых объектов существует объект, который может быть назван ассоциирующим. Это становиться ясным когда мы перейдем на уровень хранения и рассмотрим соответсвующее качеству Q_a отношение R_a, которое будет иметь схему [D_OID:OID, S, D_OID:ref₁ .... D_OID:ref_i, D_j, ..., D_n ]. Здесь атрибут OID (из K-части) как и везде содержит OID описываемого (ассоциирующего) объекта, а атрибуты refOID₁ .... refOID_i (из Q-части) содержат OID связанных с ним ассоциируемых объектов.

Атрибуты ref₁ .... ref_i входящие в Q-часть отношения R_a могут и должны рассматриваться как внешние ключи, для которых в качестве первичного ключа выступает атрибут OID стержневого отношения R₀. Следствием этого является существование ссылочной целостности, то есть невозможности уничтожить объект в том случае, если в системе существует ассоциативная запись (кортеж отношения со схемой R_a), содержащая OID этого объекта в одном из полей ref₁ .... ref_i.

Частным, но очень важным случаем ассоциаций является существующие в объектных системах ссылки. Любая ссылка в модели "объект-качество" рассматривается как значения качества (типа) "объектная ссылка". По сути дела речь идет о качестве Q_ref, которое на уровне представления в самом общем виде можно рассматривать как 1-арное отношение со схемой [D_OID:ref], где единственный атрибут ref определен на домене D_OID. Значением этого качества может являться OID одного из существующих в системе объектов.

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

Следует особо отметить, что ассоциация, являющаяся на объектном уровне направленной (ассоциирующий объект ссылается на ассоциируемые объекты), на уровне хранения (реляционном уровне) является симметричной. Например множество ссылок образует на уровне хранения отношение Rref со схемой [D_OID:OID, S, D_OID:ref]. Конечно мы по прежнему можем подразумевать, что один объект, OID которого содержится в поле "OID" (К-часть), ссылается на другой объект, OID которого содержится в поле "ref" (Q-часть). Однако фактически отношение Rref является симметричной ассоциации объектов, что позволяет описать связь (между объектами) как связь типа многие-ко-многим.

Такой подход дает некоторые возможности, недоступные в традиционных объектных системах. Например, для любого объекта возможно определить объекты, ссылающиеся на него - для этого достаточно отобрать кортежи отношения R_ref у которых в поле ref содержится OID данного объекта. В традиционных объектных системах для того, что бы получить такую информацию придется перебрать и проанализировать все существующие объекты, что представляется практически неосуществимым.

Объекты

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

Каждый из объектов должен обладать заранее определенной внутренней структурой. Говоря о структуре объекта мы имеем в виду множество пар (имя атрибута), (качественный тип атрибута). Естественно, что если объекты принадлежат одному и тому же классу, то их структура одинакова. Можно предположить, что она может быть сравнима по сложности со структурой традиционных реляционными БД и включать в себя виды, хранимые процедуры, триггеры и т.п. Надо понимать, что поскольку эти механизмы описывают объект, то они должны быть определены внутри этого объекта. Соответственно, описывающие их выражения, которые можно рассматривать как методы класса, должны находиться в области видимости этого класса.

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

Мы вновь возвращаемся к идее о существовании в системе описания данных двух ортогональных компонент, каждая из которых представлена своей, отличной от другой системой типов. Любой тип, описанный в одной из компонент, может рассматриваться в ортогональной компоненте как базовый. Это расширяет предлагаемое Дейтом утверждение, которое звучит следующим образом: класс есть домен атрибута отношение. Поскольку мы говорим о взаимной ортогональности, то, следовательно, можно утверждать также, что отношение есть домен атрибута класса.

Каталог

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

1) Каталог качеств определяет существование множества именованных качеств и описывает структуру этих качеств. Можно предполагать, что строение этой части каталога должна быть похожа на строение каталогов традиционных реляционных БД. Поскольку существование множества качеств Q на уровне представления определяют существование множества отношений R на уровне хранения, то информация представленная в каталоге качеств служит для построения системы сохранения данных. В каталоге качеств должно существовать отношение R_Q, перечисляющее существующее в системе качества с первичным ключом IDQ_prim, в качестве которого может выступать атрибут, содержащий уникальные имена качеств или их уникальные идентификаторы.

2) Каталог классов определяет существование множества именованных классов и содержит полную информацию о структуре этих классов. Существовании множества классов подразумевает наличие в каталоге классов отношения R_C с первичным ключом ClassID_prim, в качестве которго может выступать атрибут, содержащий уникальные имена классов или их уникальные идентификаторы. Мы уже говорили, что информация, позволяющая определить класс объекта, должна содержаться в стержневом отношении R₀. Эта информация должна рассматриваться как внешний ключ ClassID, связанный с первичным ключом ClassID_prim отношения R_C. Это гарантирует, что для каждого существующего в системе объекта в каталоге классов будет содержаться его описание; информацию о структуре класса невозможно удалить, пока в системе существует хотя бы один объект этого класса.

Так же в каталоге классов определяется существование множества именованных атрибутов классов. Это подразумевает наличие в каталоге классов отношения R_S, в котором перечисляются существующие в системе атрибуты объектов. Совершенно естественно, что первичным ключом этого отношения должен являться атрибут S_prim, определенный на домене D_S. Для всех остальных отношений R_i (i > 0) множества R атрибут S (К-часть) должен рассматриваться как внешний ключ, связанный с первичным ключом Sprim отношения R_S. Таким образом, каждому атрибуту качественного типа ставиться в соответствии его описание в каталоге классов.

Отношение R_S, перечисляющее атрибуты классов, должно служить так же для того, что бы хранить информацию о типах атрибутов. Эта информация может быть представлена в виде атрибута, являющимся внешним ключом IDQ, связанным с первичным ключом IDQ_prim отношения R_Q.

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

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

Как это работает

В самом общем виде работа системы основанной на модели "объект-качество", может быть проиллюстрирована следующим примером (исключительно иллюстративным) . Предположим, что нами определено качество Q

Property Q
{

int i;
long l;

}

При обработке этого выражения системой на уровне хранение будет создано новое отношение R со схемой [OID, S, i:int, l:long]. Следующее выражение

Class C
{

Attr Q;

}

приведет к тому, что в каталоге классов появиться информация о новом классе С, с качественным атрибутом типа Q. Теперь мы можем создать объект этого класса:

C rObject = new C;

Это процесс можно разделить на следующие этапы

• в стержневое отношение R₀ система добавляет кортеж, в котором содержится OID создаваемого объекта и информация о том, что этот объект будет ассоциироваться со схемой класса С
• на основании информации, содержащейся в ассоциированной схеме класса, в отношение R система добавляет новый кортеж. Значение атрибута "OID" этого кортежа равно OID созданного объекта, а значение атрибута "S" соответствует имени атрибута "Attr"

Далее OID объекта присваивается ссылочной переменной rObject. Теперь можно изменить значение атрибута созданного объекта

rObject.Attr.i = 1;

На основании информации, содержащейся в кортеже стержневого отношения, описывающем объект, идентифицируемый OID, содержащемся в ссылочной переменной rObject, система определяет, что этот объект ассоциирован со схемой класса C. В этой схеме класса содержится информация о том, что атрибут Attr имеет качественный тип Q. Поскольку информация об атрибутах этого типа содержится в отнощении R, то предыдущее выражение может быть приведено системой к следующему запросу на изменение данных:

UPDATE SET R.i = 1 WHERE R.OID = rObject AND R.S = "Attr"

Свойства модели "объект-качество" и реализующей ее системы

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

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

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

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

С другой стороны, тот факт, что система, реализующая модель "объект-качество", основана на реляционных принципах, позволяет использовать механизмы поиска и групповой обработки данных, присущих реляционным БД, применительно к объектам (традиционные объектные системы предполагают, что для этой цели должны использоваться итераторы, последовательно перебирающие объекты). На уровне хранения каждому качеству Q соответствует одно единственное отношение R, в котором хранятся все существующие в системе и описывающие разные объекты значения этого качества. Такая организация данных позволяет, например, обратиться к значениям атрибута Attr у множества объектов класса C (а также всех классов C', C''... - наследников С), имеющего качественный тип Q. Для этого на уровне представления может быть использовано следующее выражение

UPDATE C.Attr SET C.Attr.i =.... WHERE C.Attr.j >...//условие отбора

которое при переходе на уровень хранения преобразуется системой к виду

UPDATE R SET R.i.... WHERE R.S = "Attr" AND R.J> ..// условие отбора

где R - отношение соответствующее качеству Q

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

SELECT * FROM C WHERE C.Attr.i =...//условие отбора

которое на уровне хранения преобразуется системой например к следующему виду

SELECT R.OID FROM R WHERE R.S = "Attr" AND R.i =...//условие отбора

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

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

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

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

• Database in crisis and transition: A technical agenda for the year 2001. David Vaskevitch. ACM SIGMOD Record , Proceedings of the 1994 ACM SIGMOD international conference on Management of data May 1994 Volume 23 Issue 2.
• A call to order. David Maier , Bennet Vance. Proceedings of the 12'th ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems., August 1993.
• Абстракции в проектировании БД В. В. Пржиялковский СУБД №01-02/98.
• Абстракции и модели в системах баз данных М.Р. Когаловский СУБД №04-05/98.
• Долговременное хранение объектов в объектно-ориентированных приложениях В. Шринивасан, Д. Т. Чанг Открытые системы №03/99.
• Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния Калиниченко Л.А.СУБД №01/96.
• Снова о объектных СУБД Охотников Евгений Анатольевич Открытые системы №04/99.
• Технология объектно-ориентированных баз данных Ким Вон Открытые системы №04/94.
• Анатомия объектно-реляционных баз данных Д. Чемберлин СУБД №01-02/98.
• Bringing Object Relational Down To Earth Won Kim, vol.10, N 6, June 1997.
• ТРЕТИЙ МАНИФЕСТ. Х. Дарвин и К. Дэйт СУБД №01/96.
• An Analysis of Codd's Contribution to the Great Debate C.J. Date Intelligent Enterprise, May 11, 1999, Volume 2, № 7.
• When's an extension not an extension? C.J. Date Intelligent Enterprise, June 1, 1999, Volume 2, № 8.
• The relational model will stand the test of time C.J. Date Intelligent Enterprise, June 1, 1999, Volume 2, №8.
• Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы. А.М.Андреев, Д.В.Березкин, Ю. А. Кантонистов СУБД №04-05/98.
• Системы баз данных третьего поколения: Манифест. Комитет по развитию функциональных возможностей СУБД СУБД №02/95.
• Манифест систем объектно-ориентированных баз данных. М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С. Здоник СУБД №04/95.
• Новые одежды знакомых СУБД:Объектная реальность, данная нам. В. Пржиялковский СУБД №04/97.
• Persistence Not Orthogonal to Type. C.J.Date. Intelligent Enterprise's Database Programming & Design OnLine October 1998.
• Объектно-ориентированные базы данных сегодня или завтра? А. Ю. Медников А.Ю. Соловьев Открытые системы №04/94.
• SQL:1999, ранее известный как SQL3 Andrew Eisenberg Jim Melton Доступно по адресу: http://www.citforum.ru/database/digest/sql1999.shtml.
• Воплощение идей SQL-99 в ведущих объектно-реляционных серверах баз данных. Материалы ежегодной конференции ACM SIGMOD 1999 год Открытые системы №07-08/99.
• Subtypes and Supertypes: Setting the Scene C.J.Date Intelligent Enterprise's Database Programming & Design OnLine February 1999.
• К объектным базам данных Давид Бич Открытые системы №04/94.
• Что было, то и теперь есть, и что будет, то уже было…Сергей Кузнецов. Доступно по адресу:http://www.citforum.ru/database/articles/oozinder.shtml.
• Schema integration for multidatabases using the unified relational and object-oriented model Soon M. Chung , Pyeong S. Mah Proceedings of the 1995 ACM 23rd annual conference on Computer science February 1995.
• THE THIRD MANIFESTO:FOUNDATION FOR OBJECT/RELATIONAL DATABASES Hugh Darwen and C. J. Date Доступло на сайте http://www.alternativetech.com.
• ODMG-93: a standard for object-oriented DBMSs. R. G. Cattell. Proceedings of the 1994 ACM SIGMOD international conference on Management of data.
• Введение в базы данных. Крис Дейт. Изд. 6-е. Киев, Диалектика, 1998.
• Организация баз данных в вычислительных системах. Дж.Мартин. Изд. 2-е 1980 Мир (Москва).
• Системы программирования баз данных и знаний. А.В. Замулин. 1990 Наука (Новосибирск).
• Теория реляционных баз данных. Д. Мейер. 1984 Мир (Москва).
• Объектно-ориентированое Проектирование с примерами применений. Гради Буч. 1992 Диалектика(Киев) & И.В.К. (Москва).
• Object and relational databases., Chung J.-Y., Lin Y.-J. and Chang D.T., Addendum to the proceedings of the 10th annual conference on Object-oriented programming systems, languages, and applications (Addendum), 1995, Pages 164-169.
• Data Models., Avi Silberschatz and Henry F. Korth., ACM Computer Surveys v.28 №1 March 1996.
• Dimensions of object-based language design, Wegner P., Conference proceedings on Object-oriented programming systems, languages and applications, 1987, Pages 168-182.
• Relation database: a practical foundation for productivity., Codd E.F., Communication of ACM Febr.1982 Vol25 №2.
• The Relational Model for Database Management., Codd, E.F. version 2. Addison-Wesley Publishing Co., New York (1990).
• An object-oriented database. Premeriani William J., Blaha Michael R., Rumbaugh James E., Varwig Thomas A., Communications of the ACM, Nov.1990, Vol.33, №11.
• Procedures as persistent data object. Atkinson Malcolm P. and Morrison Ronald.ACM Transacion on Programming Languages and Systems, Vol.7, №4 Oct.1985.
• Khoshaflan Setrag N., Copeland George P., Object Identity. ACM Conference proceedings on Object Oriented Programming Systems Languages and Applications,1986.
• Access support in object bases., Alfons Kemper , Guido Moerkotte. ACM SIGMOD Record , Proceedings of the 1990 ACM SIGMOD international conference on Management of data May 1990. Volume 19 Issue 2.
• Модель "сущность-связь" - шаг к единому представлению о данных. Петер Пин-Шен Чен. СУБД №03/95.

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

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