Объектно-реляционные базы данных

1. Объектно-реляционные базы данных

2. Объектно-ориентированные базы данных

Объектно-реляционные базы данных представляют собой реля­цион­ные базы дан­ных, дополненные надстройкой, пред­ставляющей эти дан­ные как объекты. Все по-прежнему хранится в ви­де таблиц. Этот под­ход позволяет плавно перейти от технологии хра­ни­лища таблиц к технологии хранилища объектов. Остается воз­можность выборки данных с помощью SQL-запросов. Сам SQL расширен командами работы с объ­ектами. Наиболее известным про­дуктом, в котором реализован подоб­ный подход является Oracle ver.8. Комитет ANSI X3H2, разработавший стан­дарт SQL–92, сейчас ра­бо­та­ет над SQL3. Основными усо­вер­шен­ство­ваниями в SQL3 должны стать возможность процедурного доступа на­равне с декларативным и под­держка объектов. Основным недос­тат­ком объ­ект­но-реляционных СУБД является необходимость разбирать объ­екты для размещения их в таблицах и собирать их для передачи поль­зователю из таблиц [2].

Объектно-ориентированные базы данных хранят объекты цели­ком. Для выборки объектов с помощью запросов разра­батывается язык OQL (Object Query Language), в который был вклю­чен стандарт SQL'92. Единство описания структуры БД достигается при­менением языка определения объектов ODL (Object Definition Language), пред­ло­женного ODMG (Object Database Management Group), являющегося расширением языка IDL. Эти виды баз данных обладают высокой произ­води­тель­но­стью, часто в несколько раз более высокой, чем реляционные базы дан­ных. Наиболее известными ООСУБД явля­ются Jasmine, ObjectStore и POET.

Из отечественных разработок в области пост­реляционных баз дан­ных достоверно извест­но лишь о существовании ООСУБД ODB-Jupiter. Похоже, она была написана специ­ально для создания продукта ODB-Text. По крайней мере, ни о каких других приложениях написанных на ODB-Jupiter ничего не известно. Также в Internet было обнаружено опи­сание некой отечественной объектно-ориентированной базы данных вер­сии 1.2. Точнее, это был модуль, предоставляющий функции объектно-ориен­ти­ро­ван­ной СУБД. Доку­мент даже не имел названия. В нем деталь­но рассматривалась орга­низа­ция хранения данных и принцип работы. Похоже, разработка обос­новывалась лишь на принципах, которым долж­на удовлетворять СУООБД. Наиболее интересная идея: назначение строкам уникальных идентификаторов и удаление строк только при упаковке базы. Это дает существенный выигрыш в сравнении строк, так как объекты-строки с одинаковым содержанием имеют одинаковые идентификаторы.

1.3    Краткий сравнительный анализ постреляционных и традиционных баз данных

Постреляционные базы данных вобрали в себя все лучшие черты иерархических, сетевых и реляционных баз данных.

Хотя существуют некоторые сходства, как, например, исполь­зование указателей и вложенная структура записей в сетевой модели. Однако надо отметить, что СУООБД используют логические указатели для обеспечения целостности, а также поддерживают иерархию классов, наследование и методы. Таких средств нет в иерархических и сете­вых моделях [4].

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

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

1.4 Основания дипломной работы В отношении избранных математических моделей

Значительная часть этой дипломной работы основывается на двух мате­мати­чес­ких моделях.

Модель единого представления данных поведений
и сообщений в объектно-ориентированной базе данных

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

Модель согласованного управления в объектно-ориентированной базе данных

Эта модель [19] также оказала значительное влияние на данную работу, поскольку дополнила собой модель представления данных. Ни одна современная система управ­ления базой данных не может обойтись без подсистемы транзакций. Природа тран­зак­ций в таких при­ложениях, как CAD, мультимедийные базы данных, является весь­ма раз­лич­ной. Эти приложения характеризуются совместно выпол­ня­емыми продол­житель­ными транзакциями с произвольными опера­ци­ями. У продолжительных поль­зова­тель­ских транзакций время выпол­не­ния может быть растянуто на часы, а то и дни. Это усло­вие при­водит к тому, что хорошо извест­ный, и ставший уже классическим для тра­ди­ци­он­ных баз данных, кри­те­рий сериализуемости становится непри­меним непосредственно.

О са­мом критерии сериализуемости и спо­собах реализации меха­низ­ма транзакций достаточно подробно из­ло­жено в [9] и [22].

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

Другие работы, также повлиявшие на организацию структуры системы управления

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

Принципы журнализации заимствованы из системы POSTGRES [23] и [15].

Принципы кэширования взяты из [1].

В отношении языка реализации

Было решено реализовывать прототип СУООБД на ДССП. ДССП – диалоговая система структурного программирования – была разра­ботана в 1980 году Н.П.Брусенцовым в МГУ [5]. Система имеет под собой теоре­ти­ческое обоснование. Принцип ДССП «Слово есть слово», т.е. одно слово программы соответствует одному слову кода. Принципы управляющих конструкций наследуются от троичной вычислительной машины Сетунь-70, имевшей память на магнитных сердечниках. Словарь и обозначения – от языка Ч.Мура Forth. ДССП превосходит Forth по многим параметрам. Язык ДССП обладает существенно более низ­кой, чем язык ассемблера трудоемкостью в прог­рам­­ми­ро­ва­нии, не усту­пая ему в компактности кода и быстродействии, позво­ляет про­верять работу подпрограмм в интерактивном режиме и имеет возможность моди­фи­кации прог­рамм практически без внесения из­ме­нений в осталь­ные части ко­да.

Основные черты ДССП:

·     Двухстековая архитектура

·     Обратная польская запись

·     Словари

·     Поддержка нисходящего программирования

·     Встроенный отладчик с рекомпиляцией

·     Высокоуровневые структуры данных и операции

·     Высокоуровневый механизм программных прерываний и исключительных ситуаций

·     Компактный код

·     Гибкость, мобильность, наращиваемость

·     Наличие сопрограммного механизма

К сожалению, при всех этих достоинствах, ДССП на данный мо­мент является только системой программирования. Она не предос­тав­ляет сервис СУБД и не взаи­мо­действует ни с одной СУБД. Данная рабо­та направлена на то, чтобы обеспечить ДССП воз­можность обра­батывать данные в качестве СУБД, создав тем самым дешевый (Jasmine стоит порядка $15000), но эффективный инструмент, спо­соб­ный работать даже в самых непритязательных условиях, которые так часто встре­чаются сейчас в России. Разработка не ограничивается расширением ДССП и способна работать в ка­честве сервера ООБД на файл-сервере ЛВС.

1.5 Анализ полученного результата

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

В виде программного кода реализовано:

·     Создание, открытие ООБД

·     Менеджер виртуальной памяти

·     Система управления каналами

·     Система управления кэшированием объектов

·     Создание основных объектов

·     Клонирование объектов

·     Переопределение поведений и действий

·     Изменение данных в объектах

·     Журнализация изменений в объектах

·     Выполнение действий (knowhow)

2. Уточнение методов решения задачи 2.1 Наследование

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

Совокупности свойств объекта в объектно-ориентированной базе данных уделя­ет­ся большее внимание, чем во многих объектно-ориентированных языках прог­рам­миро­ва­ния, поскольку они являются также целью запросов. Объект=состояние+поведение. Чаще всего существует только одна иерархия наследования. Этот подход перешел и в C++. Однако, возможно разделение иерархий наследования данных и наследования по­ве­де­ний. Не всегда желательно иметь точно такую же иерархию наследования пове­де­ния, как и иерархию наследования свойств. Разделение этих двух иерархий повышает возможности переиспользования (reuse) поведений.

Значение переиспользования поведений

Предположим, мы имеем класс Студент и хотим создать класс Аспирант. Чтобы стать аспирантом, человек должен сначала получить высшее образование как студент. В общем случае экземпляры этих классов различны. Мы не можем наследовать Аспирант от Студент, т.к. аспирант не является студентом. В противном случае, мы имели бы право рассматривать аспиранта как экземпляр класса Аспирант и, с тем же правом, как экземпляр класса студент. Тем не менее, оба класса обладают общими атрибутами, таки­ми как: имя, адрес, номер_личной_карточки, а также большинством общих пове­де­ний. Это обстоятельство побуждает создать класс Аспирант, унаследовав свойства и по­веде­ния Студента. Однако, хотя экземпляры класса Аспирант будут подмножеством всех экземпляров класса Студент (т.к. все аспиранты были студентами, но не все студенты стали аспирантами), это представление будет некорректно с точки зрения моде­лиро­вания ситуации в реальном мире.

На рисунке представлено дерево наследования:

Рис. 2: Диаграмма наследования

Свойства классов Студент и Аспирант наследуются от класса Учащийся.

Поведение класса Аспирант наследуется от Студент. Обычно подкласс наследует все атрибуты и методы из суперклассов. В приложении к наследованию поведений это означает, что класс-ученик (demandclass) состоит в отношении Переиспользовать-от (Reuse-Of) с другим классом, называемым классом-учителем (supplyclass), и класс-ученик должен наследовать все поведения от класса-учителя.

Эталоны наследования: классы или прототипы?

В системе отсутствуют классы и типы. Роль класса может брать на себя любой объект, называемый объектом-образцом. Такой вид наследования называется насле­до­ванием на основе прототипов.

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

Независимо от модели наследования (классы или прототипы) существует две раз­личные стратегии реализации механизма наследования: делегирование и конкате­нация.

Способ наследования: делегирование или конкатенация?

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

И конкатенация, и делегирование имеют свои достоинства и недостатки. Делеги­рование обеспечивает возможность гибкого распространения изменений: любое измене­ние свойств родителя автоматически отражается на потомках. Подход, использующий конкатенацию, допускает изменение свойств родителей и потомков независимо друг от друга, что также может быть полезно во многих ситуациях. Делегирование обычно тре­бует меньших затрат по памяти, в то время как конкатенация является более эффек­тивной по времени. Simula и C++ являются примерами языков, которые реализуют на­следование на основе классов с использованием делегирования. В Smalltalk реализовано наследование на основе прототипов с использованием делегирования.

Обоснование избранного механизма наследования

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

Система поддерживает множественное наследование. Необходимость множест­венного наследования остается предметом горячих споров. Практика говорит о том, что «множественное наследование играет роль парашюта: в нем нет постоянной необхо­димости, но если он вдруг понадобился, то большое счастье иметь его под рукой» [8].

Определение родства

 

Остается важный вопрос: как определить, является ли объект потомком другого объекта? Разделение наследований состояния и поведения приводит к тому, что слово «потомок объекта» обретает двойственное значение. С одной стороны, это потомок по данным, с другой стороны, это потомок по поведению.

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

2.2 Инкапсуляция

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

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

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

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

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

Здесь уместно вспомнить о “проблеме 2000 года”, возникшей из-за того, что в СУБД отводилось всего два разряда на год даты. Чтобы исправить возникающую ошиб­ку, нужно пересмотреть заново весь код приложения! В ООБД для решения анало­гичной проблемы требуется исправление небольшого количества методов, работающих с данными даты.

2.3 Идентификатор объекта Назначение идентификатора

Объекты в БД обладают индивидуальностью. Даже при изменении структуры и поведения объекта, его индивидуальность сохраняется. Два объекта в системе отлича­ются своими идентификаторами. Идентификатор является характеристикой индиви­дуальности. Понятие индивидуальности ново для реляционных баз данных. В чисто реляционной БД все кортежи в пределах одной таблицы отличаются между собой. Характеристика различия – первичный ключ. Многие современные реляционные базы данных допускают существование в пределах одной таблицы одинаковых кортежей. И потребность в этом есть, иначе не было бы квалификатора DISTINCT в операторе SQL SELECT.

Идентификатор объекта в БД позволяет различить между собой два одинаковых по значению объекта. Фактически, он играет роль дескриптора адреса объекта. Таким образом, пользователь работает с объектом не через его адрес, а через его иденти­фи­катор.

Строение идентификатора

В современных ООБД для ускорения доступа к объектам идентификаторы наде­ляются составной структурой.

Имеются два основных подхода для идентификации объектов:

·     Составной адрес (Structured address)

·     Заменитель (Surrogate)

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

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

В работе [16] описан подход к построению идентификаторов-заменителей. Иденти­фикатор состоит из двух частей: кода кластера и номера в последовательности. Такой подход основывается на следующих трех принципах:

1)   Идентификатор объекта должен содержать информацию о кластере, который группирует совместно используемые объекты

2)   Должны быть допустимы произвольные размеры кластеров

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

Есть три признака, по которым СУБД могут принимать решение о месте размещения объектов:

1)   Правила, заданные в схеме БД

2)   Указание пользователя

3)   Статистика доступа

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

Идентичность и эквивалентность

В ООБД при сравнении двух объектов между собой различают идентичность и эквивалентность объектов.

Определение идентичности

 Два объекта являются идентичными, если их идентификаторы совпадают. Поскольку в системе не может быть двух объектов с одинаковыми идентификаторами, это означает, что это один и тот же объект, на который ссылаются с двух разных мест. Идентичность обозначается так: o₁ º o₂.

Определение N-эквивалентности

Пусть 0-эквивалентность (обозначается »₀) то же самое, что проверка идентичности º. Тогда для любых двух объектов o₁, o₂ÎO, o₁ и o₂ n-эквивалентны (обозначается o₁ »_n o₂) для n > 0, если:

Существует атомарный объект c, такой, что значение(o₁) = значение(o₂) и их поведения идентичны;

Существует объект-агрегат c, такой, что FID каждого поля с присутствует в o₁ и o₂, а также верно обратное: FID каждого поля o₁ (o₂) присутствует в c,
значение(o₁)=[A₁ : x₁, …, A_m : x_m] и значение(o₂)=[A₁ : y₁, …, A_m : y_m], и при этом
x_i »_n-1y_i для 1£ i £ n; или

Существует объект-условие c, такой, что значение(o₁) = <x₁,  x₂,  x₃> и значение(o₂) = <y₁,  y₂,  y₃> и x_i »_n-1y_i для 1£ i £ 3; или

Существует объект-множество c, такой, что значение(o₁) = {x₁, …,  x_l} и значение(o₂)
= {y₁, …,  y_m}  и  l = m и для каждого x_i(y_j) существует один y_j(x_i) : x_i »_n-1y_j для 1£ i,j £ l; или

Существует объект-список c, такой, что значение(o₁) = (x₁, …,  x_l) и значение(o₂) = (y₁, …,  y_m)  и  l = m и x_i »_n-1y_i для 1£ i £ l.

Два объекта называются эквивалентными (o₁ » o₂) тогда и только тогда, когда
o₁ »_n o₂ для некоторого n > 0.

2.4 Идентификатор поля агрегата

Введение идентификатора поля позволяет преодолеть трудность определения размещения данных полей агрегатов. Суть проблемы заключается в том, что если мы наследуем классы B и C от класса A, а затем наследуем множественно класс D от классов B и C, то экземпляр класса D одновременно является экземпляром классов A, B и C. При этом важно, чтобы "старый" класс (например, A) умел работать с объектами класса D. Эта проблема рассматривается в работе [10], в которой авторы вводят следующие ограничения целостности структуры объектов: