2001 г

Модель "объект - качество".

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

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

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

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

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

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

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

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

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

Ограниченность современной объектной концепции.

Вкратце общее описание современной объектной концепции (в дальнейшем СОК) можно условно свести к нескольким частям:

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

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

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

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

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

В чем же заключается ограниченность СОК? Рассмотрим следующий пример. Пусть существует класс Cars описывающий транспортные средства и пусть у него определен метод getWeight возвращающий вес транспортного средства. Для хранения информации о весе используется атрибут weight предопределенного типа float.

class Cars 
{...
private:
    float weight;
public:
    int getWeight ()
    {
        // возвращает значение переменной weight
    }...
...}

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

Вернемся к примеру. Существуют два автомобиля имеющие одинаковый вес (1000 кг). Описывая эту ситуацию, мы должны создать два объекта o1 и o2 класса Cars и присвоить значение 1000 переменным o1.weght и o2.weght, которые являются атрибутами этих объектов. Если исходить из СОК, где любой объект отличается от любого другого объекта, то переменные o1 и o2, так же как и переменные o1.weght и o2.weght, являются разными объектами. Однако это не очень соответствует повседневному опыту. Да, в реальной жизни про автомобили мы скажем, что они разные, однако про их вес мы скажем, что он один и тот же. Говоря образно, сравнивая автомобили, мы сравниваем их как переменные, несмотря на то, что информация, описывающая их абсолютно одинакова. Сравнивая же веса, мы сравниваем их значения, и в этом случае факт, что эти значения описывают разные автомобили не играет никакой роли.

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

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

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

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

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

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

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

Базовые типы как логическое понятие.

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

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

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

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

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

Качество (концепция).

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

В статье "Представление сложных идентифицируемых объектов в реляционных базах данных" я попытался ввести термин "сущность", который определяется как "информацию являющейся достаточной для установления определенной связи". К сожалению, использование слов "сущность" и "связь" может вызвать путаницу у русскоязычных читателей. Дело в том, что эти слова уже используется в сфере моделирования данных. Я имею в виду модель "сущность-связь" Чена, где в это слово вкладывается иной (абсолютно иной!) смысл. В русском языке слово "сущность" имеет несколько значений и, соответственно, может быть переведено на английский по-разному. Чен использует слово "entity", что означает "нечто существующее" и близко по смыслу к слову "объект" или "вещь". В упомянутой статье термин "сущность" имеет смысл "существенная характеристика, позволяющая описать вещь с определенной точки зрения". В этом случае слово "сущность" может быть переведено на английский как "essence" и близко по смыслу слову "качество". Поэтому в дальнейшем будет употребляться именно этот термин - "качество". .Ему можно дать следующее определение: качество - это абстракция определяющее и описывающая способность вещей к определенному взаимодействию. Информация о вещи есть информация о её качествах.

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

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

Еще один пример. Для описания некоторых вещей мы можем использовать свойство "адрес". Тем самым мы определяем, что данная вещь (например, человек, или фирма, или что-то еще) является адресуемой (в самом банальном смысле - ей можно послать письмо, или посмотреть по карте её местоположение). Информация о качестве "адрес" является результатом следующих связей между вещами: описываемая вещь находится в доме номер X расположенном на улицеY имеющейся в городе Z. Здесь "дом", "улица" "город" - это вещи, а "номер дома ", "название улицы", "имя города" - качества этих вещей. Свойство "адрес" является обобщением всех вышеперечисленных качеств всех вышеперечисленных вещей. Однако для того, что бы описать адресуемую вещь, нам совершенно не нужно описывать дома, улицы и города - надо просто знать адрес этой вещи. Существование этой информации позволяет сказать, что описываемая этой информацией вещь обладает способность к определенному взаимодействию - ей можно послать письмо, определить ее положение на карте и т.п. И в данном случае атрибут "адрес" не описывает строение реально существующих вещей, однако позволяет описать её способность к определенному взаимодействию с другими вещами.

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

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

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

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

Качество (логика).

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

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

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

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

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

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

Качества можно сравнивать на основании следующих принципов:

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

2. единственным способом сравнения качеств является сравнение значений качества. Качества, описываемые одинаковыми значениями, являются одинаковыми и никак иначе не отличаются друг от друга.

Следствием этого является то, что

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

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

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

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

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

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

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

Качество как отношение.

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

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

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

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

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

int

Value

...

-2

-1

0

1

2

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечание : мы не случайно назвали отношение 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(si) Q_i. Такие отображения o будем называть объектами. Другими словами , объектом о класса c называется множество {s_i:S_i | s_i является именованным (имеющим имя Si) подмножеством соответсвуещего Q_j , s_i Q_j }.

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

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

Понятие "уникальный объектный идентификатор" (OID) является одним из основных в СОК. Как уже говорилось, именно OID, являясь единственным критерием позволяющим отличить один объект от другого, используется в объектных системах для организации доступа к объектам. Любому объекту o_i на всем протяжении его жизни соответствует одно уникальное и неизменное значение 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_ID D_OID), то O можно рассматривать как подмножество прямого произведения D_OID, D_S и Q
O D_OID DS Q (2)

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

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

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

Видно, что множество O является реляционной системой. Каждому значению <d₁,...,d_n>качества Q_i со схемой [D₁,...,D_n ], входящему в атрибут s_j, объекта o_k соответствует кортеж <OID_k, S_j, d₁,...,d_n> отношения R_i со схемой [D_OID:OID, S, D₁,...,D_n ]. Каждому качеству Q_i ставиться в соответствие отношений Ri, содержащее значения всех атрибутов этого качества, принадлежащих всем существующим в системе объектам. Любой набор данных представленный в виде О (множество объектов) может быть сохранен в виде 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). К-часть отношения любого отношения Ri неизменна - она должна генерироваться и поддерживаться системой. Схема Q-части должна соответствовать схеме соответствующего качества Q_i, которое определяется пользователем.

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

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

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

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

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

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

Замечание. Поскольку OID представляют объекты, отношение Qa может интерпретироваться системой как ассоциация объектов со схемой [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 рассматриваются как домены отношений. Таким образом, модель "объект-качество" не противоречит подходу предлагаемому Дейтом, где класс и домен рассматриваются как эквивалентные понятия.

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

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

Объекты.

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

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

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

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

Каталог.

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

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

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

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

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

в стержневое отношение R0 система добавляет кортеж, в котором содержится 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