49515 (609140), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

Язык EXPRESS поддерживает набор стандартных, встроенных в него элементарных типов данных INTEGER, REAL, NUMBER, LOGICAL, BOOLEAN, BINARY и STRING для представления, соответственно, целых, вещественных и произвольных числовых данных, логических и булевых значений, последовательностей двоичных данных и строк. Для перечислимых типов предусмотрена специальная конструкция ENUMERATION. Агрегатные типы ARRAY, SET, BAG и LIST предоставляют возможность определения различного рода контейнеров, таких как массивы, множества, мультимножества и списки. Опционально могут быть заданы их размеры, способы индексации элементов, условие множественности эквивалентных элементов для массивов и списков, а также допустимость разреженности элементов в массивах. Селективные типы, вводимые оператором SELECT, позволяют использовать переменные и константы, принимающие значения одного из альтернативных типов, объявленных в списке оператора. Новые производные типы данных создаются на основе стандартных и предопределенных типов с помощью конструкции TYPE. Допускается произвольная вложенность определений пользовательских типов, которая, в частности, обеспечивает создание многомерных массивов, вложенных селективных и агрегатных конструкций.

Типы GENERIC, AGGREGATE, а также ARRAY, SET, BAG и LIST OF GENERIC обеспечивают обобщенную реализацию функций и процедур с использованием абстракций простых и агрегатных данных.

Для объектных типов используется конструкция ENTITY, предусматривающая разнообразные модели простого и множественного наследования с помощью квалификаторов AND, ANDOR, ONEOF. При специфицировании объектного типа задаются атрибуты и ассоциации различной кратности (EXPLICIT), обратные ассоциации (INVERSE), а также производные вычисляемые свойства объектов (DERIVED). Последние определяются типами и выражениями, которые могут включать в себя значения явных атрибутов, константы, исполняемые операторы, включая вызов функций и процедур, как стандартных, так и пользовательских.

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

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

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

SCHEMA ActorResource;

TYPE ActorSelect = SELECT (Organization, Person);

END_TYPE;

TYPE AddressTypeEnum = ENUMERATION OF (

END_TYPE;

TYPE Label = STRING(255);

END_TYPE;

TYPE ActorRole = Label;

END_TYPE;

ENTITY Address

ABSTRACT SUPERTYPE OF (ONEOF(PostalAddress, TelecomAddress));

Purpose : AddressTypeEnum;

UserDefinedPurpose : OPTIONAL STRING;

INVERSE

OfPerson : SET OF Person FOR Addresses;

OfOrganization : SET OF Organization FOR Addresses;

WHERE

WR1 : (Purpose <> AddressTypeEnum.USERDEFINED) OR

((Purpose = AddressTypeEnum.USERDEFINED) AND

EXISTS(UserDefinedPurpose));

END_ENTITY;

ENTITY PostalAddress

SUBTYPE OF(Address);

AddressLines : LIST [1:?] OF Label;

END_ENTITY;

ENTITY TelecomAddress

SUBTYPE OF(Address);

TelephoneNumbers : OPTIONAL LIST [1:?] OF Label;

FacsimileNumbers : OPTIONAL LIST [1:?] OF Label;

ElectronicMailAddresses : OPTIONAL LIST [1:?] OF Label;

WWWUrls : OPTIONAL LIST [1:?] OF Label;

WHERE

WR1 : EXISTS (TelephoneNumbers) OR EXISTS (FacsimileNumbers) OR

EXISTS (ElectronicMailAddresses) OR EXISTS (WWWUrls);

END_ENTITY;

ENTITY Organization;

Id : INTEGER;

Name : Label;

Description : OPTIONAL STRING;

Roles : LIST [0:?] OF UNIQUE ActorRole;

Addresses : LIST [1:?] OF UNIQUE Address;

INVERSE

IsRelatedBy : SET OF OrganizationRelationship FOR RelatedOrganizations;

Relates : SET OF OrganizationRelationship FOR RelatingOrganization;

Engages : SET OF Person FOR EngagedIn;

UNIQUE

UR1 : Id;

END_ENTITY;

ENTITY OrganizationRelationship;

Name : Label;

Description : OPTIONAL STRING;

RelatingOrganization : Organization;

RelatedOrganizations : SET [1:?] OF Organization;

END_ENTITY;

ENTITY Person;

Id : INTEGER;

FamilyName : OPTIONAL Label;

GivenName : OPTIONAL Label;

MiddleNames : OPTIONAL LIST [1:?] OF Label;

PrefixTitles : OPTIONAL LIST [1:?] OF Label;

SuffixTitles : OPTIONAL LIST [1:?] OF Label;

Roles : LIST [0:?] OF UNIQUE ActorRole;

Addresses : OPTIONAL LIST [1:?] OF UNIQUE Address;

EngagedIn : SET OF Organization;

UNIQUE

UR1 : Id;

WHERE

WR1 : EXISTS(FamilyName) OR EXISTS(GivenName);

END_ENTITY;

END_SCHEMA;

К настоящему времени в рамках международных программ по стандартизации прикладных информационных моделей и интероперабельности программных приложений накоплен значительный ресурс многопрофильных междисциплинарных моделей. Ресурс охватывает такие научные и промышленные области, как машиностроение, авиационную и космическую промышленность, судостроение, нефтегазовый комплекс, архитектуру и строительство, электронную промышленность, фармацевтику, геоинформатику. Значительная часть разработанных на языке EXPRESS спецификаций принята в качестве документов ISO-10303. Другая часть разрабатывается непосредственно промышленными альянсами для последующего представления в международную организацию по стандартам.

К существенным особенностям прикладных информационных моделей следует отнести:

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

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

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

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

6. Общая систематизация подходов

6.1 Классификация паттернов отображения

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

• элементарных базовых типов;

• перечислимых типов;

• ассоциативных связей между объектами;

• селективных типов;

• агрегатных типов;

• вложенных структур данных, основанных на базовых, перечислимых, ассоциативных, селективных и агрегатных типах данных;

• простых и сложных объектных типов в рамках модели множественного наследования;

• информационных схем.

Не менее существенными для практического применения являются часто противоречащие друг другу проблемы:

• выбора стратегии отображения в соответствии с контекстом использования семантики информационной модели;

• поддержки метаданных в реляционном представлении и их конструктивного применения в ходе пользовательских сессий;

• эффективности реализации объектных запросов и операций манипулирования объектами (создание, модификация, удаление);

• оптимизации используемых ресурсов, включая затраты памяти;

• сопровождаемости решений и их гибкости по отношению к возможной эволюции используемых прикладных моделей.

6.2 Отображение информационных схем

Вопрос о выборе стратегии отображения в рамках схемо-зависимого (СЗ) или схемо-независимого (СН) подходов является наиболее принципиальным для систематизации методов объектно-реляционного отображения и их адекватного применения в приложениях.

6.2.1 Схемо-независимая стратегия

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

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

6.2.2 Схемо-зависимая стратегия

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

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

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

6.3 Отображение наследования классов

Паттерны, предназначенные для отображения отношений простого наследования между классами, являются хорошо известными. В этой курсовой работе мы обсудим возможные варианты отображений в рамках развитой модели множественного наследования языка EXPRESS.

6.3.1 Паттерн OneInheritanceHierarchy–OneTable

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

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

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

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

6.3.2 Паттерн OneClass–OneTable

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

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

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

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

6.3.3 Паттерн OneInheritancePath–OneTable

Некоторые недостатки предыдущего паттерна компенсируются в результате сериализации таблиц классов по отношениям наследования. В паттерне OneInheritancePath–OneTable каждому конкретному классу соответствует своя таблица _Instances, в столбцы которой отображаются все атрибуты класса, включая наследуемые от родителей.

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

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

6.3.4 Паттерн AllClasses–OneTable

Паттерн AllClasses–OneTable предполагает использование единой таблицы Instances для представления дескрипторов объектов всех классов. В столбцах таблицы хранятся идентификатор объекта и его тип. Контекст использования паттерна связан с представлением атрибутов классов в виде самостоятельных таблиц. В этом случае связь между таблицами экземпляров классов и значений их атрибутов осуществляется через внешние ключи записей объектов (см. раздел 6.4.2.2). Предполагается, что значения атрибутов одного и того же типа хранятся в единой таблице независимо от их вхождения в состав того или иного класса. Тем самым достигается существенная для схемо-независимой стратегии инвариантность реляционной схемы по отношению к прикладным моделям. Связь простого объекта с его классом осуществляется через внешний ключ записи в таблице классов Entities (см. раздел 6.5). Для сложных объектов предусмотрен внешний ключ записи в соответствующей таблице сложных классов Complex_Entities.

6.3.5 Паттерн BLOB

Паттерн BLOB также предполагает использование единой таблицы BLOB Instances для представления объектов всех классов. Однако в отличие от паттерна AllClasses–OneTable в данной таблице используется дополнительный столбец для хранения значений атрибутов, упакованных в бинарную или текстовую строку переменной длины. Задача упаковки значений в строку и их распаковки для клиентских приложений ложится непосредственно на промежуточный слой программного обеспечения. Хотя чтение и запись данных объекта осуществляются за одну операцию обращения к таблице, дополнительные расходы приходятся на обработку строк промежуточным слоем. По существу в этом случае BLOB стратегия объединяет в себе паттерны наследования, агрегации и ассоциации.

Характеристики

Список файлов курсовой работы