Язык описания информационных моделей EXPRESS

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 16.12.2009
Размер файла 51,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

6.4.4.4 Паттерн GenericSelect

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

Таблица Selections хранит записи дескрипторов селективных данных, включая их дискриминаторы и ссылки на объекты в таблице Instances, атрибутами которых они являются. Сами данные хранятся в таблицах представления простых типов Integer_Elements, Real_Elements, String_Elements, Binary_Elements, Logical_Elements, Enum_Elements и в таблице ассоциаций Associations.

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

6.4.5 Отображение агрегатов

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

В отношении способов представления вложенных типов данных, в том числе основанных на предопределенных конструкциях, паттерны отображения селективных и агрегатных типов довольно близки. Паттерны ClassAggregate и HierarchyAggregate предназначены для использования с паттернами отображения классов OneClass-OneTable, OneInheritancePath-OneTable и OneInheritanceHierarchy-OneTable в рамках схемо-зависимой стратегии. Паттерн GenericAggregate применяется вместе с паттерном AllClasses-OneTable, соответствуя СН стратегии отображения.

6.4.5.1 Паттерн ClassAggregate

Данный паттерн предполагает организацию специальных столбцов для хранения размерностей агрегата непосредственно в таблице объектов класса, а также создание отдельной таблицы <Class>_<Attribute>_Aggregate для хранения значений и индексов элементов агрегата. Такая таблица создается для каждого агрегатного атрибута каждого класса. Для связи с объектами используется ссылка из <Class>_<Attribute>_Aggregate на соответствующую таблицу объектов классов в виде внешнего ключа записей в ней.

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

6.4.5.2 Паттерн HierarchyAggregate

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

6.4.5.3 Паттерн GenericAggregate

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

Таблица Aggregates хранит записи дескрипторов агрегатных данных, включая их размерности и ссылки на объекты в таблице Instances, атрибутами которых они являются. Таблица является родительской для элементов агрегата, хранящихся в других таблицах Integer_Elements, Real_Elements, String_Elements, Binary_Elements, Logical_Elements, Enum_Elements и Associations. В свою очередь, каждая запись в таблице Aggregates может иметь ссылку на запись в этой же таблице, если агрегат является элементом, вложенным в другой родительский агрегат, а также хранить соответствующий индекс в нем. Если агрегат является одним из значений селективного типа, то он ссылается на соответствующую родительскую конструкцию, представляемую записью в таблице Selections. В остальных случаях записи таблицы Aggregates ссылаются на соответствующие записи в таблице Attributes для получения метаинформации об агрегатном атрибуте.

6.5 Отображение метаданных

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

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

Для детального описания перечислимых, селективных и агрегатных типов дополнительно используются таблицы Enumeration_Constants, Select_Types и Aggregate_Types. Таблица Enumerations_Constants содержит списки возможных значений для каждого перечислимого пользовательского типа. Ее столбцы хранят символьные значения перечислимого типа и внешний ключ соответствующей записи типа в таблице Defined_Types. Аналогичным образом, таблица Select_Types представляет списки базовых типов, входящих в определение каждого конкретного селективного типа, в виде внешних ключей записей типов в таблице Defined_Types. В столбцах таблицы агрегатных типов Aggregate_Types содержится информация о типе агрегата (ARRAY, LIST, SET или BAG), базовом типе его элементов в виде внешнего ключа соответствующей записи в таблице Defined_Types, разрешенных значениях нижней и верхней границ агрегата, признаках допустимости наличия уникальных и неопределенных элементов.

Таблица классов Entities предназначена для представления объектных типов информационной схемы, зарегистрированной в базе данных. Ее столбцы хранят первичные ключи записей и уникальные имена сущностей. Аналогично определяемым типам, привязка классов к схеме осуществляется через отдельную таблицу соответствия Entities_To_Schemas. Для реконструкции отношений наследования между классами используется таблица Inheritance_Relations, в которой данные отношения представлены парами внешних ключей записей классов родителей и потомков в таблице Entities. Поскольку язык EXPRESS допускает множественное наследование с признаками AND или ANDOR, важно иметь альтернативное представление иерархии наследования в виде множеств всех родительских классов, данные которых включаются в конструируемые объекты сложных классов. Для этой цели используется таблица Complex_Entities. Для единообразия обработки объектов простые классы также представляются записями этой таблицы. Таблица Complex_Entities_To_Entities хранит все соответствия сложных классов родительским классам в виде пары внешних ключей записей в таблицах Complex_Entities и Entities.

Наконец, таблица атрибутов Attributes содержит столбцы для представления имени атрибута, класса, в котором данный атрибут определяется (или переопределяется), в виде соответствующего внешнего ключа записи в таблице Entities, типа атрибута в виде внешнего ключа записи в таблице Defined_Types, признака обязательности значений и контекста использования (EXPLICIT, DERIVED или INVERSE).

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

7. Реализация промежуточного объектно-реляционного слоя в

среде Oracle 9

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

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

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

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

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

Поскольку выбор стратегии отображения для реализации объектно-реляционного слоя подобной функциональности крайне неоднозначен с учетом разнообразия потенциальных приложений, предполагается реализация и поддержка нескольких альтернативных стратегий, а именно: схемо-независимого, схемо-зависимого и BLOB подходов. Они базируются на тех или иных сочетаниях рассмотренных выше паттернов ОР отображения и используют собственные пакеты программ на PL/SQL для реализации базовой функциональности объектно-реляционного слоя. Хотя все пакеты реализуют семантически эквивалентные наборы операций для манипулирования объектами и их поиска, их внешние интерфейсы не допускают унификацию в силу ограниченных возможностей языка SQL при формировании клиентских запросов со стороны объектно-реляционного посредника для специфических реляционных схем представления объектно-ориентированных моделей данных. Для адаптации посредника к иным объектно-реляционным стратегиям в его архитектуре предусмотрены специальные компоненты-адаптеры, обеспечивающие требуемую виртуализацию хранилищ данных. Каждый адаптер реализуется с учетом специфики конкретного ОР отображения.

В качестве целевой платформы реализации промежуточного объектно-реляционного слоя выбрана СУБД Oracle9.

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

Разработанная схемо-независимая стратегия состоит в применении обобщенных паттернов AllClasses-OneTable, Attribute-Table, GenericAssociation, GenericSelect, GenericAggregate для отображения схем, классов и атрибутов, а также паттерна представления соответствующих метаданных прикладной модели реляционными таблицами.

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

Пакет lb_defined_types для работы с метаинформацией о пользовательских типах данных, определенных EXPRESS схемой:

· procedure Register_Defined_Type - регистрация в базе данных пользовательского типа схемы;

· procedure Save_Enum_Type - сохранение метаданных для перечислимого типа;

· procedure Save_Select_Type - сохранение метаданных для селективного типа;

· procedure Save_Aggregate_Type - сохранение метаданных для агрегатного типа;

· function Get_Type - выдача метаинформации о пользовательском типе данных.

Пакет lb_entity предназначен для работы с метаинформацией, относящейся к объектным типам EXPRESS схемы:

· function Register_Entity - регистрация объектного типа схемы;

· procedure Save_Attribute - сохранение метаданных для атрибута, определяемого в регистрируемом объектном типе;

· procedure Save_Inheritance_Relations - сохранение информации о подтипах и супертипах регистрируемого объектного типа;

· function Add_Entity_From_Schema - экспортирование информации об объектном типе из другой схемы;

· function Get_Entity - выдача метаинформации об объектном типе;

· function Get_Attribute - выдача метаинформации об атрибуте, определяемом в объектном типе схемы.

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

· function Init_Instance - инициация сохранения объекта;

· procedure Init_Attribute_List - инициация сохранения значений атрибутов объекта;

· procedure Put_Simple_Attribute_{R, I, S, B, L, E} - сохранение значения атрибута вещественного, целочисленного, символьного, бинарного, логического, перечислимого типа, соответственно;

· procedure Put_Association - сохранение значения атрибута ассоциативного типа;

· function Put_Aggregate - инициация сохранения элементов агрегата;

· function Put_Select - инициация сохранения селективного элемента;

· procedure Put_Element_{R, I, S, B, L, E} - сохранение значения элемента агрегатной или селективной конструкции вещественного, целочисленного, символьного, бинарного, логического, перечислимого типа, соответственно;

· procedure Get_Instances_By_ID - выборка объектов по заданным идентификаторам;

· procedure Get_Instances_By_Type - выборка объектов по заданному типу;

· procedure Get_Instances_By_Route - выборка объектов по заданному навигационному маршруту;

· procedure Add_Route_Path - метод формирования навигационного маршрута;

· procedure Get_All_Instances - выборка всех объектов;

· procedure Delete_Instances - удаление объектов по заданным идентификаторам.

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

declare

l_Sch_ID Schemas.sch_id%TYPE;

l_Ent_ID Entities.ent_id%TYPE;

begin

lb_defined_types.register_defined_type

('Label','string',l_Sch_ID);

lb_defined_types.register_defined_type

('ActorRole','Label',l_Sch_ID);

lb_defined_types.register_defined_type

('AddressTypeEnum','enumeration',l_Sch_ID);

lb_defined_types.save_enum_type('OFFICE');

lb_defined_types.save_enum_type('HOME');

lb_defined_types.save_enum_type('USERDEFINED');

l_Ent_ID := lb_entity.register_entity

('Organization',l_Sch_ID,false);

lb_entity.save_attribute('Id','integer',1,'','',0,'E');

lb_entity.save_attribute('Name','Label',2,'','',0,'E');

lb_entity.save_attribute

('Description','string',3,'','',1,'E');

lb_entity.save_attribute

('Roles','aggregate',4,'','',0,'E');

lb_entity.save_attribute

('Addresses','aggregate',5,'','',0,'E');

lb_entity.save_attribute

('IsRelatedBy','OrganizationRelationship',

6,'OrganizationRelationship','RelatedOrganizations',0,'I');

lb_entity.save_attribute

('Relates','OrganizationRelationship',

7,'OrganizationRelationship','RelatingOrganization',0,'I');

lb_entity.save_attribute

('Engages','Person',8,'Person','EngagedIn',0,'I');

l_Ent_ID := lb_entity.register_entity

('Address',l_Sch_ID,false);

lb_entity.save_attribute

('Purpose','AddressTypeEnum',1,'','',0,'E');

lb_entity.save_attribute

('UserDefinedPurpose','string',2,'','',1,'E');

lb_entity.save_attribute

('OfPerson','Person',3,'Person','Addresses',0,'I');

lb_entity.save_attribute

('OfOrganization','Organization',

4,'Organization','Addresses',0,'I');

l_Ent_ID := lb_entity.register_entity

('PostalAddress',l_Sch_ID,false);

lb_entity.save_inheritance_relations('Address',false);

lb_entity.save_attribute

('AddressLines','aggregate',1,'','',0,'E');

end;

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

-- Фрагмент исходного файла с данными в формате ISO-10303-21

#10=POSTALADDRESS(.OFFICE., $,

('25, B.Kommunisticheskaya str., Moscow, 109004, Russia'));

#11=ORGANIZATION(770901001, 'ISP RAS', $,

('Research','Development','Teaching'), (#10));

-- Фрагмент PL/SQL скрипта для занесения данных в БД

DECLARE

type Agg_Level_Type is table of

Aggregates.agg_type%TYPE index by binary_integer;

type Agg_Level_ID is table of

Aggregates.agg_id%TYPE index by binary_integer;

l_Sch_ID Schemas.sch_id%TYPE;

l_Ent_ID Entities.ent_id%TYPE;

l_Ins_ID Instances.ins_id%TYPE;

l_Atr_ID Attributes.atr_id%TYPE;

l_Agg_Type Agg_level_Type;

l_Agg_ID Agg_level_ID;

BEGIN

l_Ent_ID := lb_entity.get_entity('Organization',l_Sch_ID);

l_Ins_ID := lb_instance.init_instance

(l_Ent_ID,l_MO_ID,l_Rep_ID,'#11');

lb_instance.init_attribute_list(l_Ent_ID);

l_Atr_ID := lb_entity.get_attribute(1);

lb_instance.put_simple_attribute_i

(l_Ins_ID,l_Atr_ID,770901001);

l_Atr_ID := lb_entity.get_attribute(2);

lb_instance.put_simple_attrib_s

(l_Ins_ID,l_Atr_ID,'ISP RAS');

l_Atr_ID := lb_entity.get_attribute(4);

l_Agg_Type(1) := lb_defined_types.get_type

('ActorRole',l_Sch_ID);

l_Agg_ID(1) := lb_instance.put_aggregate(l_Agg_Type(1),

NULL,NULL,l_Atr_ID,l_Ins_ID,l_MO_ID,NULL,NULL);

lb_instance.put_element_s(0,'Research',

NULL,l_Agg_ID(1),NULL);

lb_instance.put_element_s(1,'Development',

NULL,l_Agg_ID(1),NULL);

lb_instance.put_element_s(2,'Teaching',

NULL,l_Agg_ID(1),NULL);

l_Atr_ID := lb_entity.get_attribute(5);

l_Agg_Type(1) := lb_defined_types.get_type

('Address',l_Sch_ID);

l_Agg_ID(1) := lb_instance.put_aggregate

(l_Agg_Type(1),NULL,NULL,l_Atr_ID,l_Ins_ID,

l_MO_ID,NULL,NULL);

lb_instance.put_association

(l_Ins_ID,l_Atr_ID,'#10',0,l_Agg_ID(1),NULL);

l_Ent_ID := lb_entity.get_entity

('PostalAddress',l_Sch_ID);

l_Ins_ID := lb_instance.init_instance

(l_Ent_ID,l_MO_ID,l_Rep_ID,'#10');

lb_instance.init_attribute_list(l_Ent_ID);

l_Atr_ID := lb_entity.get_attribute(1);

lb_instance.put_simple_attribute_e

(l_Ins_ID,l_Atr_ID,'office');

l_Atr_ID := lb_entity.get_attribute(3);

l_Agg_Type(1) := lb_defined_types.get_type

('Label',l_Sch_ID);

l_Agg_ID(1) := lb_instance.put_aggregate(l_Agg_Type(1),

NULL,NULL,l_Atr_ID,l_Ins_ID,l_MO_ID,NULL,NULL);

lb_instance.put_element_s(0,'25, B.Kommunisticheskaya

str.,Moscow, 109004, Russia',NULL,l_Agg_ID(1),NULL);

END;

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

Альтернативу рассмотренному способу реализации объектно-реляционного отображения составляет разработанный вариант схемо-зависимой стратегии, основанный на использовании паттернов отображения классов и атрибутов OneInheritancePath-OneTable, Attribute-Column, ClassAssociation, ClassSelect и ClassAggregate. Данный вариант представляет собой попытку оптимизировать реляционную схему для наиболее эффективной работы с данными внутри одной прикладной модели. Подобная постановка задачи возникает довольно часто на практике и представляет интерес для приложений, оперирующих с одной, возможно масштабной, междисциплинарной прикладной моделью. Указанное сочетание паттернов отображения приводит к большому количеству таблиц, требуемых для адекватного представления объектно-ориентированных данных. Однако при этом оно обеспечивает более эффективную реализацию базовых операций манипулирования объектами. Паттерн OneInheritancePath-OneTable использует преимущества сериализованного представления атрибутов конкретных классов и упрощает компоновку наследуемых атрибутов для объектов выбранных типов. Перечисленные паттерны отображения исключают многоуровневую косвенную адресацию при доступе к таблицам атрибутов и обеспечивают высокую эффективность реализации вспомогательных операций сборки значений из таблиц атрибутов при чтении объектов и их рассылку по соответствующим таблицам при записи и модификации объектов.

Реализация адаптера посредника для схемо-зависимой стратегии существенно отличается от реализации схемо-независимой стратегии. Во-первых, реляционная схема для СУБД генерируется соответствующим CASE инструментом для каждой прикладной модели, специфицированной на языке EXPRESS. Ниже представлен фрагмент описания такой схемы на языке SQL для прикладной модели ActorResource, приведенной ниже. Во-вторых, одновременно со схемой генерируются исходные тексты пакета процедур на языке PL/SQL для манипулирования объектами данной прикладной модели. Каждая процедура пакета ориентирована на работу с объектами определенного типа и имеет специфический для него интерфейс. Поддержка подобных хранимых процедур со стороны реляционной СУБД существенно упрощает реализацию адаптера для посредника и позволяет повысить эффективность его работы за счет компиляции соответствующих директив манипулирования объектами в среде самой СУБД. В-третьих, не требуется какая-либо работа с метаданными, поскольку организация таблиц данных следует структурным особенностям прикладной информационной модели и позволяет явно адресоваться к ним при работе.

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

ActorResource

CREATE TABLE actorresource_instance (

PID INTEGER DEFAULT 1 NOT NULL PRIMARY KEY,

Title VARCHAR2(128) NOT NULL,

Entity VARCHAR2(128) NOT NULL,

Model INTEGER NOT NULL,

Commentary VARCHAR2(4000),

FOREIGN KEY (Model) REFERENCES model(PID)

ON DELETE CASCADE

);

CREATE SEQUENCE sq$actorresource_instance;

CREATE UNIQUE INDEX i$actorresource_title_model

ON actorresource_instance (Title, Model);

CREATE INDEX i$actorresource_entity_model

ON actorresource_instance (Entity, Model);

CREATE INDEX i$actorresource_model

ON actorresource_instance (Model);

-- таблица для объектов типа Organization

CREATE TABLE actorresource_organization (

PID INTEGER DEFAULT 1 NOT NULL PRIMARY KEY,

Instance INTEGER NOT NULL,

Id_ INTEGER NOT NULL,

Name_ VARCHAR2(255) NOT NULL,

Description_ VARCHAR2(4000),

FOREIGN KEY (Instance) REFERENCES

actorresource_instance(PID) ON DELETE CASCADE

);

CREATE SEQUENCE sq$actorresource_organization;

CREATE INDEX i$actorresource_organization

ON actorresource_organization (Instance);

CREATE TABLE actorresource_organizat_3 (

PID INTEGER DEFAULT 1 NOT NULL PRIMARY KEY,

Parent INTEGER NOT NULL,

Element_Index1 INTEGER,

Element_Value VARCHAR2(255),

FOREIGN KEY (Parent) REFERENCES

actorresource_organization(PID) ON DELETE CASCADE

);

CREATE SEQUENCE sq$actorresource_organizat_3;

CREATE INDEX i$actorresource_organizat_3

ON actorresource_organizat_3 (Parent);

CREATE TABLE actorresource_organizat_4 (

PID INTEGER DEFAULT 1 NOT NULL PRIMARY KEY,

Parent INTEGER NOT NULL,

Element_Index1 INTEGER,

Element_Value VARCHAR2(128),

FOREIGN KEY (Parent) REFERENCES

actorresource_organization(PID) ON DELETE CASCADE

);

CREATE SEQUENCE sq$actorresource_organizat_4;

CREATE INDEX i$actorresource_organizat_4

ON actorresource_organizat_4 (Parent);

7.3 BLOB стратегия

Наконец, третий разработанный вариант реализации адаптера основан на применении BLOB&Text&XML_Encoding паттернов для реляционного представления объектов классов и их атрибутов. Этот вариант воспроизводит упрощенную схему СН стратегии за счет упакованного представления значений атрибутов объекта в виде бинарной или текстовой строки. Сами строки хранятся как элементы записей в таблице объектов BLOB_Instances. Как следствие, таблицы представления простых и сложных атрибутов отсутствуют. Модифицированная таблица Associations хранит ассоциации всех видов и используется для реализации навигационных запросов по ним. Из таблиц метаданных поддерживаются лишь Schemas, Entities, Entities_To_Schemas, Inheritance_Relations, Complex_Entities и Complex_Entities_To_Entities, записи которых воспроизводят отношения наследования классов в прикладной модели и используются для реализации запросов по типам объектов. Соответствующий CASE инструмент позволяет сгенерировать скрипт инициализации таблиц метаданных по спецификации прикладной информационной модели на языке EXPRESS.

Разработанный на языке PL/SQL пакет процедур предоставляет базовый набор операций манипулирования объектами и их поиска по идентификаторам, типам и навигационным маршрутам в рамках BLOB стратегии. Поскольку значения атрибутов объекта представлены в БД единой строкой, функции по упаковке и распаковке строк целиком ложатся на адаптер посредника. В силу этой же причины в рамках BLOB стратегии невозможно выполнение более тонких запросов на основе атрибутных свойств объектов непосредственно средствами СУБД.

8. Рекомендации использования

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

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

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

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

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

Заключение

В данной курсовой работе мы выяснили, что значение языка EXPRESS заключается в описании информационных моделей.

Язык EXPRESS:

· опирается на объектно-ориентированный подход

· использует разбиение на иерархические уровни

Язык EXPRESS может быть использован двумя путями:

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

2. моделирование понятий и функциональных (информационных) связей отдельно; проектирование информационной модели включает 3 этапа:

А) информационное моделирование

Б) функциональное моделирование

В) программная реализация

Второй путь является наиболее предпочтительнее для CALS, т.к. есть разделение функциональных обязанностей.

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

1) описание типов

2) описание констант (ввод постоянных)

3) создание правил

4) функции

5) процедуры

Функции и процедуры необходимы для проверки правил, для вычисления каких-то переменных.

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

Язык EXPRESS включил 2 особенности, которых нет у других программных средств:

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

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

Список используемых источников

1. В.П. Иванников, С.С. Гайсарян, К.В. Антипин, В.В. Рубанов. Объектно-ориентированное окружение, обеспечивающее доступ к реляционным СУБД. // Труды Института системного программирования РАН, том 2, 2001, c. 89-114.

2. Судов Е. В., Левин А. И., Давыдов А. Н., Барабанов В. В. Концепция развития CALS-технологий в промышленности России. М.: НИЦ CALS-технологий «Прикладная логистика», 2002.

3. Ю. Шрейдер. “Социальные аспекты информатики” //Научно-техническая информация, Серия 2, 1989, #1.

4. Владимир Пржиялковский. “Волшебство нового программирования” // Директору Информационной Службы (ComputerWorld), 2000, #3

5. Кнорина Л.В. “Природа слова в Универсальном Языке Ньютона” // Научно--техническая информация, Серия 2 , 1994, #9.


Подобные документы

  • Структура модели на языке Express. Правила записи супертипов и подтипов. Разработка информационных моделей в рамках концепции CALS. Типы данных в языке Express. Структура портативного зарядного устройства ЗарядON. Изображение сущности на языке Express-G.

    курсовая работа [487,9 K], добавлен 18.01.2013

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

    лабораторная работа [159,4 K], добавлен 26.05.2014

  • Применение, настройка и правила работы в программе Outlook Express. Управление e-mail аккаунтами и аккаунтами новостных групп, быстрый просмотр сообщений. Адресная книга, отправка и получение защищенных сообщений. Ошибки и средства устранения неполадок.

    статья [21,7 K], добавлен 03.05.2010

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

    контрольная работа [23,9 K], добавлен 17.02.2011

  • Общая характеристика отрасли авиастроения, обоснование необходимости внедрения новых информационных технологий в данной сфере. Изучение концепции и механизма использования CALS-технологий в российском авиастроении: основные проблемы и пути их решения.

    курсовая работа [1,2 M], добавлен 10.02.2014

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

    курсовая работа [439,9 K], добавлен 05.06.2014

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

    методичка [950,2 K], добавлен 23.01.2014

  • Разработка клиентского приложения для информационной системы "Работа торгового склада" с помощью языка объектно-ориентированного программирования Delphi 6 и технологии InterBase Express. Описание реляционной модели данных и этапы ее проектирования.

    курсовая работа [1,0 M], добавлен 19.03.2009

  • Использование скриптового языка программирования для разработки web-приложений (сценариев). Изучение основ объектно-ориентированного программирования в языке PHP. Ознакомление со специальными методами для работы с классами. Назначение интерфейсов.

    контрольная работа [25,1 K], добавлен 14.03.2015

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

    курсовая работа [795,9 K], добавлен 14.12.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.