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

Федеральноеагентство по образованию
Сибирскаягосударственная автомобильно-дорожная академия
(СибАДИ)
КафедраУК и С
КУРСОВАЯРАБОТА
натему: Язык описания информационных моделей (EXPRESS)
подисциплине «CALS-технологии»
Выполнила:ст-ка гр.41С
Проверил:
Омск– 2009

Содержание
Введение
1 Преимущества CALS
2 CALS в России
3 Государство покровительствует CALS-технологиям
4 Проблемы стандартизации описания продукции,технологии и бизнеса
5 Объектно-ориентированное моделирование наEXPRESS
6 Общая систематизация подходов
6.1 Классификация паттернов отображения
6.2 Отображение информационных схем
6.2.1 Схемо-независимая стратегия
6.2.2 Схемо-зависимая стратегия6.3 Отображение наследования классов
6.3.1 Паттерн OneInheritanceHierarchy–OneTable6.3.2 Паттерн OneClass–OneTable6.3.3 Паттерн OneInheritancePath–OneTable
6.3.4 Паттерн AllClasses–OneTable
6.3.5 Паттерн BLOB6.4 Отображение атрибутов6.4.1Представление простых типов6.4.2Отображение атрибутов простых типов6.4.2.1Паттерн Attribute–Column6.4.2.2Паттерн Attribute–Table6.4.3 Отображение ассоциаций
6.4.3.1 Паттерн ForeignKeyAssociation
6.4.3.2 Паттерн ClassAssociation
6.4.3.3 Паттерн GenericAssociation
6.4.4 Отображение селективных типов6.4.4.1Паттерн Select–Columns6.4.4.2Паттерн ClassSelect6.4.4.3Паттерн HierarchySelect
6.4.4.4 Паттерн GenericSelect
6.4.5 Отображение агрегатов6.4.5.1Паттерн ClassAggregate6.4.5.2Паттерн HierarchyAggregate6.4.5.3Паттерн GenericAggregate6.5 Отображение метаданных7 Реализацияпромежуточного объектно-реляционного слоя в среде Oracle97.1 Схемо-независимая стратегия7.2 Схемо-зависимаястратегия7.3 BLOB стратегия8 РекомендациииспользованияЗаключение
Список используемых источников

Введение
Термин CALS(Continuous Acquisition and Lifecycle Support — непрерывная информационнаяподдержка поставок и жизненного цикла) означает совокупность принципов итехнологий информационной поддержки жизненного цикла продукции на всех егостадиях. Русскоязычный аналог понятия CALS — Информационная Поддержкажизненного цикла Изделий (ИПИ). В последнее время за рубежом наряду с CALSиспользуется также термин Product Lifecycle Management (PLM).
Цельвнедрения CALS — минимизация затрат в ходе жизненного цикла изделия, повышениеего качества и конкурентоспособности.
Для описаниясхем данных используется разработанный язык EXPRESS. Этот язык регламентирует:
·          Черчение(прямое и ассоциативное)
·          Проектированиеконструкций
·          Инженерныйанализ
·          Технологическуюподготовку
·          Производство
·          Тестированиеданных и обмен ими в специальном текстовом формате

1. ПреимуществаCALS
Технологии,стандарты и программно-технические средства CALS обеспечивают эффективный иэкономичный обмен электронными данными и безбумажными электронными документами,что дает следующие преимущества:
· возможностьпараллельного выполнения сложных проектов несколькими рабочими группами(параллельный инжиниринг), что существенно сокращает время разработок;
· планированиеи управление многими предприятиями, участвующими в жизненном цикле продукции,расширение и совершенствование кооперационных связей (электронный бизнес);
· резкое сокращениеколичества ошибок и переделок, что приводит к сокращению сроков реализациипроектов и существенному повышению качества продукции;
· распространениесредств и технологий информационной поддержки на послепродажные стадиижизненного цикла — интегрированная логистическая поддержка изделий.
Наэкономические показатели предприятий, применяющих CALS-технологии,непосредственно влияют следующие факторы:
· сокращениезатрат и трудоемкости процессов технической подготовки и освоения производствановых изделий;
· сокращениесроков вывода на рынок новых конкурентоспособных изделий;
· сокращениебрака и затрат, связанных с внесением изменений в конструкцию;
· увеличениеобъемов продаж изделий, снабженных электронной технической документацией (вчастности, эксплуатационной), составленной в соответствии с требованиямимеждународных стандартов;
· сокращениезатрат на эксплуатацию, обслуживание и ремонт изделий («затрат навладение»), которые для сложной наукоемкой продукции подчас равны илипревышают затраты на ее закупку.
Вот некоторыеколичественные оценки эффективности внедрения CALS в промышленности США:
· прямоесокращение затрат на проектирование — от 10 до 30%;
· сокращениевремени разработки изделий — от 40 до 60%;
· сокращениевремени вывода новых изделий на рынок — от 25 до 75%;
· сокращениедоли брака и объема конструктивных изменений — от 20 до 70%.
· сокращениезатрат на подготовку технической документации — до 40%;
· сокращениезатрат на разработку эксплуатационной документации — до 30%.
По зарубежнымданным, потери, связанные с несовершенством информационного взаимодействия споставщиками, только в автомобильной промышленности США составляет порядка 1млрд. долл. в год. Аналогичные потери имеют место и в других отрасляхпромышленности.
В тех жеисточниках указывается, что затраты на разработку реактивного двигателя GE 90для самолета «Боинг-777» составили 2 млрд. долл., а разработка новой моделиавтомобиля компании «Форд» стоит от 3 до 6 млрд. долл. Это означает, чтоэкономия от снижения прямых затрат на проектирование только по двум указаннымобъектам может составить от 500 млн. до 2,2 млрд. долл.
Как видим,внедрение CALS-технологий приводит к существенной экономии и получениюдополнительной прибыли. Поэтому эти технологии и их отдельные компоненты широкоприменяются в промышленности развитых стран. Так, из числа 500 крупнейшихмировых компаний, входящих в перечень Fortune 500, около 100% используют такойважнейший компонент CALS, как средства PDM (Product Data Management —«управление данными об изделии»). Среди предприятий с годовым оборотом свыше 50млн. долл. такие системы используют более 80%.
В связи сбольшими объемами ожидаемой экономии и дополнительных прибылей в эту сферупривлекаются значительные инвестиции, измеряемые миллиардами долларов. По даннымзарубежных источников, инвестиции правительства США в сферу CALS-технологийсоставляют около 1 млрд. долл. в год. Затраты других стран меньше, однако,например, правительство Финляндии затратило на национальную программу в этойобласти свыше 20 млн. долл. и примерно такую же сумму (около 25 млн. долл.)вложили в нее частные компании. Корпорация General Motors в течение 1990 — 1995годов израсходовала на эти цели 3 млрд. долл. Средние затраты на один проект,посвященный решению локальной задачи в области CALS-технологий (например,разработка стандарта или программы), составляют 1,2 — 1,5 млн. долл. присреднем сроке выполнения от двух до четырех лет.
Эти цифрысвидетельствуют о том, какое значение придают на Западе проблематике, связаннойс CALS-технологиями.

2. CALS вРоссии
Россиясущественно отстает от ведущих промышленно развитых стран в части внедрениясовременных ИТ, в том числе технологий CALS. Это отставание чревато далекоидущими негативными последствиями, прежде всего, высокой вероятностью резкогосокращения экспортного потенциала российских производителей наукоемкойпродукции, вплоть до полного вытеснения их с международного рынка, что может,по мнению зарубежных экспертов, произойти к 2005 — 2008 году.
Мировой рынокполностью отторгнет продукцию, не снабженную электронной документацией и необладающую средствами интегрированной логистической поддержкипостпроизводственных стадий жизненного цикла. Уже сегодня многие иностранныезаказчики отечественной продукции выдвигают требования, удовлетворение которыхневозможно без внедрения CALS-технологий:
· представлениеконструкторской и технологической документации в электронной форме;
· представлениеэксплуатационной и ремонтной документации в форме интерактивных электронныхтехнических руководств, снабженных иллюстрированными электронными каталогамизапасных частей и вспомогательных материалов и средствами дистанционного заказазапчастей и материалов;
· организацияинтегрированной логистической поддержки изделий на постпроизводственных стадияхих жизненного цикла;
· наличие ифункционирование электронной системы каталогизации продукции;
· наличие напредприятиях соответствующих требованиям стандартов ИСО 9000:2000 системменеджмента качества и т. д.
Выполнениеэтих требований предопределяет необходимость внедрения на отечественныхпредприятиях CALS-технологий в полном объеме.

3. Государствопокровительствует CALS-технологиям
В период с1999-го по 2002 год Минпромнауки РФ совместно с Госстандартом РФ иМинобразования РФ осуществили ряд мер, направленных на создание предпосылок квнедрению CALS-технологий в промышленности России.
Были созданыначальные элементы инфраструктуры, необходимой для разработки и внедренияCALS-технологий: Государственный научно-образовательный центр CALS-технологий,Научно-исследовательский центр (НИЦ) CALS-технологий «Прикладная логистика» итехнический комитет ТК 431 Госстандарта России, координирующий разработкуотечественной нормативной базы.
Подготовленынаучно-методические разработки: концепция развития CALS-технологий впромышленности России [1], концепция интегрированной логистической поддержкинаукоемких изделий и концепция внедрения CALS-технологий на машиностроительномпредприятии.
Предпринятыразработки в области создания нормативной базы: Госстандарт РФ утвердил шестьдокументов ГОСТ Р ИСО 10303 и шесть документов в статусе рекомендаций постандартизации Р 50. Были подготовлены проекты 7 ГОСТ Р и три проектаавиационных отраслевых стандартов. Кроме того, разработана программа работ поподготовке новых стандартов и корректировке существующих (ЕСКД, СРПП и др.).
Созданыпрограммные средства, реализующие CALS-технологии. В их числе — программныйпродукт Technical Guide Builder, предназначенный для автоматизированнойподготовки электронной технической эксплуатационной документации наэкспортируемую продукцию, соответствующей требованиям CALS-стандартов. Созданиес помощью этого продукта интерактивных электронных технических руководствзначительно повышает конкурентоспособность продукции. Другой продукт — PDM STEPSuite — служит для управления данными об изделии в процессе конструирования итехнологической подготовки производства, что крайне необходимо предприятиям,как разрабатывающим наукоемкую продукцию, так и продающим лицензии на еепроизводство.
Наконец,разработаны методические основы создания интегрированной системы управлениякачеством продукции, соответствующей требованиям стандартов ИСО серии 9000версии 2000 года.
Работы повнедрению CALS-технологий в промышленность России интенсивно продолжаются припристальном внимании и поддержке Минпромнауки РФ, Госстандарта РФ и другихминистерств и ведомств России. Авторы надеются, что эти работы позволят если неполностью преодолеть, то хотя бы существенно сократить отставание российскойпромышленности от промышленности ведущих стран Запада.

4.Проблемы стандартизации описания продукции, технологии и
бизнеса
Началомсовременного этапа стандартизации описания продукции и технологии можно считатьпоявление в середине 80-х годов проекта STEP (STandard for the Exchange of Productmodel data ) – серии стандартов для обеспечения универсального механизма обменаданными о продукции и технологии как между различными организациями, так имежду разными этапами жизненного цикла продукции. Ядром STEP был почтиобъектно-ориентированный язык информационного моделирования EXPRESS (ISO 10303,part11). Не являясь языком программирования, не поддерживая “методы” имеханизмы их наследования, действующая версия EXPRESS обеспечиваетобъектно-ориентированную идеологию для описания концептуальных моделей данных(множественное наследование данных и ограничений, выводимые атрибуты и др.).
Вторым«китом», на котором основан EXPRESS, является модель “сущность-связь”(E-R модель). Так же, чувствуется влияние и SQL. Графическая версия – EXPRESS-Gуже полностью вытеснила IDEF 1X, который использовался на начальных этапахпроекта STEP. В новой версии – EXPRESS v2 уже предполагается полнаяобъектно-ориентированность, с поддержкой моделирования процессов, событий,транзакций, а также единая формальная метамодель, гораздо болеедетализированная и семантически более строгая, чем части Generic Resourcesсерии стандартов ISO 10303 (parts 41-49).
Всяработа над проектом велась под эгидой подкомитета 4, технического комитета 184ISO (ISO TC184/SC4), к концу 90-х годов в рамках которого появилось ещенесколько серий стандартов (разной степени завершенности), связанных сописанием уже не только продукции и технологии (ISO 13584, ISO 14959, ISO15926), но и управления производством (Manufacturing Management – MANDATE — ISO15531) и использующих в качестве основы язык EXPRESS.
За15 лет вокруг EXPRESS и STEP сформировалась уже целая отрасль ИТ, котораяобеспечивает значительное уменьшение трудозатрат при “запуске” новых технологийи новых видов продукции. Причем, если серия ISO 10303 начиналась прежде всегодля обслуживания автомобильной и аэрокосмической промышленностей, то сейчас онаохватывает уже большинство видов производств, включая электротехническое,кораблестроительное, строительство, нефтехимическое и т.п. Появились не толькокомпании, специализирующиеся на инструментарии технологии STEP, но иорганизации общеметодологического плана, связанные с развитием технологии“данных о продукции” (Product Data Technology- PDT), например EuroSTEP, PDTSolutions, PDTAG, PDES и др.
Важноотметить активное использование Internet при разработке стандартов, в работенад которыми принимают участие многие организации и специалисты всех ведущихстран мира. Это и серии телеконференций с дискуссиями по наиболее важнымвопросам, и электронное голосование по утверждению проектов стандартов наразных стадиях разработки вплоть до статуса Международного стандарта, иорганизация очных семинаров/конференций, и организация полного электронногоархива, доступного по Сети. Такая технология организации проектов на основеуправления знаниями симптоматична для “новой эры” однако она делает толькопервые шаги и серьезно противоречит существующим социальным институтам.
Несмотряна внешние успехи сама идеология, методология и технология STEP/EXPRESS требуетглубокого совершенствования. С одной стороны, нужна “гармонизация” и“модуляризация” стандартов внутри самого ISOTC184/SC4, c другой, оказалосьнеобходимым выйти за рамки описания “продукции и технологии” и включить болееширокий круг вопросов бизнеса, с третьей стороны все более возникаетнеобходимость в согласовании аналогичных работ с другими организациями,занимающимися разработками в том же направлении и прежде всего с группами CSMF(Conceрtual Schema Modelling Facilities) и CDIF (CASE Data Interchange Format)в рамках объединенного технического комитета ISO и МеждународнойЭлектротехнической Комиссии (ISO/IEC JTC1), с консорциумом WWW (W3C), сбазовыми подгруппами OMG (Object Management Group), с группой KIF ( KnowledgeInterchange Format ) ANSI ASC X3T2, а также с OAG (Open Application Group).

5.Объектно-ориентированное моделирование на EXPRESS
Краткорассмотрим подмножество языка 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, специфицирующая информацию о персонах и организациях,участвующих в совместном проекте, их ролях в нем и отношениях между ними.
SCHEMAActorResource;
TYPEActorSelect = SELECT (Organization, Person);
END_TYPE;
TYPEAddressTypeEnum = ENUMERATION OF (
END_TYPE;
TYPELabel = STRING(255);
END_TYPE;
TYPEActorRole = Label;
END_TYPE;
ENTITYAddress
 ABSTRACTSUPERTYPE 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;
ENTITYPostalAddress
 SUBTYPEOF(Address);
 AddressLines: LIST [1:?] OF Label;
END_ENTITY;
ENTITYTelecomAddress
 SUBTYPEOF(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;
ENTITYOrganization;
 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;
ENTITYOrganizationRelationship;
 Name  : Label;
 Description : OPTIONAL STRING;
 RelatingOrganization: Organization;
 RelatedOrganizations: SET [1:?] OF Organization;
END_ENTITY;
ENTITYPerson;
 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 стратегияобъединяет в себе паттерны наследования, агрегации и ассоциации.
Возможныразновидности данного паттерна, связанные с различными способами представлениястроки значений атрибутов как в бинарном формате, так и в одном из текстовыхметаформатов. В частности, применительно к метамодели EXPRESS стандарт STEPопределяет формат текстового кодирования прикладных данных (ISO-10303-21) инесколько альтернативных способов XML разметки документов (ISO-10303-28),порождаемых соответствующей прикладной моделью данных, специфицируемой на языкеEXPRESS.
Главнымнедостатком BLOB паттерна является невозможность разрешения запросов иреализации объектных операций непосредственно средствами реляционной СУБД. Вданном случае она играет роль простого хранилища, а эти функции выполняетпромежуточный слой. Как паттерн схемо-независимой стратегии он не требуетбольших затрат на поддержку реляционной схемы при эволюции прикладной модели,поскольку связанные с этими изменениями функции затрагивают лишь промежуточныйслой.6.4 Отображение атрибутов
Атрибутыклассов представляются либо столбцами соответствующих таблиц объектов классов,либо самостоятельными таблицами. Как и в случае паттернов отображения классов,альтернативы представления атрибутов во многом определяются применяемойсхемо-зависимой или схемо-независимой стратегией объектно-реляционногоотображения. Рассмотрим их, следуя введенной классификации паттерновотображения атрибутов простых, селективных, агрегатных типов и ассоциаций.6.4.1 Представление простых типов
Соответствиебазовых типов языка EXPRESS типам данных в SQL достаточно прозрачно. В таблицу1 сведены базовые типы EXPRESS и возможные способы их представления в некоторыхпопулярных коммерческих и свободно распространяемых реляционных СУБД.
Таблица1. Соответствие базовых типов EXPRESS и SQL в реляционных СУБД ЕXPRESS MySQL PostgreSQL Oracle INTEGER INTEGER INTEGER INTEGER REAL
REAL,
DOUBLE PRECISION
FLOAT8,
DOUBLE PRECISION
NUMBER,
DOUBLE PRECISION REAL(n) FLOAT(n) NUMERIC(n) NUMBER(n) NUMBER
REAL,
DOUBLE PRECISION
FLOAT8,
DOUBLE PRECISION
NUMBER,
DOUBLE PRECISION BOOLEAN
CHAR(1),
TINYINT
CHAR(1),
SMALLINT
CHAR(1),
INTEGER LOGICAL
CHAR(1),
TINYINT
CHAR(1),
SMALLINT
CHAR(1),
INTEGER ENUMERATION
VARCHAR(128),
INTEGER
VARCHAR(128),
INTEGER
VARCHAR2(128),
INTEGER STRING
TEXT (up to 64K),
LONGTEXT (up to 4Gb) TEXT (about 1Gb)
VARCHAR2(4000),
LONG (up to 2Gb) STRING(n) VARCHAR(n) VARCHAR(n) VARCHAR2(n) STRING(n) FIXED CHAR(n) CHAR(n) CHAR(n) BINARY
BLOB (up to 64K),
LONGBLOB (up to 4Gb) BYTEA LONG RAW (up to 2Gb) BINARY(n) VARCHAR(n) BINARY VARBIT(n) RAW(n) BINARY(n) FIXED CHAR(n) BINARY BIT(n) RAW(n) ENTITY (reference)
VARCHAR(128),
FOREIGN KEY
VARCHAR(128),
FOREIGN KEY
VARCHAR2(128),
FOREIGN KEY
Помимоуказанных вариантов представления точности числовых значений и ограниченийдлины строковых и двоичных переменных, важные отличия затрагивают способыпредставления атрибутов типа BOOLEAN, LOGICAL и ENUMERATION. С точки зрениясемантики языка EXPRESS значения этих типов упорядочены, и для них определеныоперации сравнения. Поэтому, если предполагается реализация запросов сиспользованием подобных операций, более предпочтительным выглядит представлениепеременных этих типов как целых чисел. В этом случае функция интерпретациизначений в терминах исходной прикладной модели возлагается на промежуточныйпрограммный слой, возможно, с использованием словарей метаданных. Значения,представленные в виде символьных строк, интерпретируются непосредственноклиентскими приложениями. Средствами СУБД может контролироваться также икорректность данных, для чего должны быть наложены соответствующие ограниченияна область допустимых значений.6.4.2 Отображение атрибутов простых типов6.4.2.1 Паттерн Attribute–Column
Реализацияпаттерна представления атрибутов простых типов в виде столбцов соответствующихтаблиц объектов довольно прозрачна и естественна для применения в рамках схемо-зависимойстратегии. В этом случае каждая таблица объектов классов включает в себясоответствующий столбец для представления значений простого атрибута. Типстолбца определяется возможными вариантами представления базовых типов языкаEXPRESS, рассмотренными в предыдущем разделе. В качестве имени столбца могутбыть выбраны либо имя атрибута, уникальное в пределах класса, либо конкатенацияимен класса и атрибута, уникальная в пределах информационной схемы.6.4.2.2 Паттерн Attribute–Table
Данныйпаттерн предполагает использование самостоятельных таблиц для представленияпростых однотипных атрибутов. Его применение возможно лишь в рамках схемо-независимойи смешанной стратегий с одновременным использованием таблиц метаданных.Привязка значений атрибутов к дескрипторам объектов осуществляется по внешнимключам записей объектов в таблице Instances, представленным в таблицахатрибутов. Для идентификации хранимых величин как значений атрибутовопределенных классов в них также хранятся внешние ключи записей метаинформациио соответствующих атрибутах в таблице Attributes в составе системы таблицметаданных.
Независимоот принадлежности различным классам значения однотипных атрибутов хранятся водной таблице. Для представления всех атрибутов простых типов, допускаемыхметамоделью языка EXPRESS, в общей реляционной схеме достаточно иметьфиксированный набор из шести таблиц: Integer_Attributes, Real_Attributes,Logical_Attributes, String_Attributes, Binary_Attributes и Enum_Attributes. Предполагается,что в схеме хранения данные типа NUMBER всегда представимы типом REAL, а данныетипа BOOLEAN — типом LOGICAL.6.4.3 Отображение ассоциаций
ЯзыкEXPRESS допускает определение разного рода ассоциативных отношений междуклассами, отличающихся как по типу, так и по кратности. Ассоциацииоднонаправлены в том смысле, что ассоциируемый объект может быть получен посоответствующей ссылке из объекта, содержащего ассоциативную связь. Вместе стем, допускается задание двунаправленных связей с помощью определения обратныхатрибутов (INVERSE) в ассоциируемом классе. При определении прямой и обратнойассоциации допустимо указание диапазона кратности связи как ограничения,налагаемого на количество объектов, участвующих в ней как со стороныассоциируемых, так и со стороны ассоциирующих объектов.
Ассоциации“один-к-одному” реализуются как простые атрибуты, имеющие тип объектной ссылки.Ассоциации “один-ко-многим” представляются средствами языка как агрегатыпростых ассоциативных отношений. Ассоциации вида “многие-ко-многим”непосредственно конструкциями языка не поддерживаются, однако могут бытьпредставлены в прикладной модели в виде дополнительных объектов, через которыена основе множественных ассоциаций могут быть установлены требуемые отношениямежду прикладными объектами.
Рассмотримзадачу отображения множественных ассоциаций вида “один-ко-многим” как наиболеетиповой случай, к которому могут быть непосредственно редуцированы ассоциации “один-к-одному”и “многие-ко-многим”. Видятся три наиболее содержательных случая представленияассоциаций и соответствующих им паттерна отображения.6.4.3.1 Паттерн ForeignKeyAssociation
Данныйпаттерн применим к прямым множественным ассоциациям при условии, чтосоответствующая обратная ассоциация является простой. Иными словами, с каждымобъектом, участвующим в связи, может быть ассоциировано некоторое множествообъектов. Однако каждый объект таких множеств может участвовать только в однойобратной ассоциации этой связи. Паттерн реализуется в рамках схемо-зависимойстратегии путем включения в таблицу ассоциированного класса (класса, на который содержится ссылка в классеассоциации) внешнего ключа на таблицу . Имя ключаможет соответствовать имени связи в соответствующей спецификации. В случае упорядоченных множественных ассоциаций(LIST или ARRAY OF ENTITY) может потребоваться дополнительный столбец в таблице для хранения индекса ассоциации. Если связьреализуется как элемент вложенной агрегатной конструкции, то в данной таблицепредусматривается необходимое число столбцов индексов для каждого изупорядоченных множеств, участвующих в ней. Аналогично, если связь реализуетсякак элемент селективной конструкции, то в таблицу добавляется соответствующийстолбец для представления дискриминатора. Более подробно эти случаи описаны впаттернах отображения селективных и агрегатных конструкций.
Чтениеассоциирующего объекта реализуется посредством одной операции соединения илидвух операций запроса к таблицам и, один из которых является множественным. Записьобъекта также сопряжена с множественной операцией модификации внешних ключей взаписях ассоциированных объектов. Затраты памяти в реализации паттерна близки коптимальным, поскольку издержки приходятся лишь на хранение дополнительноговнешнего ключа, а иногда и индекса ассоциации в таблице, для каждой связи, в которой ассоциируемый классучаствует.6.4.3.2 Паттерн ClassAssociation
Данныйпаттерн позволяет непосредственно представить множественные ассоциативныеотношения в результате использования отдельной таблицы в рамках схемо-зависимойстратегии. Такая таблица __Associations создаетсядля каждой пары классов, участвующих в ассоциативной связи, и содержит парывнешних ключей записей в таблицах классов ассоциируемых и ассоциирующихобъектов.
Вотличие от предыдущего, данный паттерн обеспечивает представление произвольныхассоциативных отношений, не ограниченных кратностью обратных ассоциаций.6.4.3.3 Паттерн GenericAssociation
Данныйпаттерн соответствует схемо-независимой стратегии. Он реализует идеюунифицированного представления всех видов ассоциаций, участвующих в прикладноймодели, одной таблицей Associations. Ассоциативные связи в таблицеустанавливаются через ссылки на дескрипторы прикладных объектов в таблицеInstances в виде внешних ключей соответствующих записей в ней. Поскольку дляреализации схемо-независимой стратегии важна привязка элементов данных кприкладной модели, для каждой ассоциации в таблице Associations хранится такжессылка на метаинформацию о соответствующем атрибуте, представленную в таблицеAttributes. Если ассоциация устанавливается как элемент агрегатной илиселективной конструкции, то указывается также ссылка на соответствующую записьв таблицах Aggregates или Selections. Таким образом, таблица Associationsхранит множество записей обо всех видах ассоциаций прикладных данных, контекстеих использования в составе агрегатных или селективных конструкций и их привязкек прикладной информационной модели, представимыми соответствующими таблицамиметаданных.6.4.4 Отображение селективных типов
Посколькуселективные типы данных в языке EXPRESS по существу являются альтернативнымпредставлением других базовых типов, паттерны их отображения тесно связаны ссоответствующими паттернами отображения тех базовых типов, на которых ониоснованы. Важно отметить, что селективные типы могут быть основаны на простыхтипах данных, ассоциативных типах, агрегатах различного вида и на ранеепредопределенных селективных типах иной организации. Дискриминатор установкиселективного элемента данных в одно из альтернативных состояний в реляционнойсхеме представим столбцом в таблице хранения значений атрибутов объектов. Типстолбца дискриминатора соответствует рассмотренным способам отображения данныхперечислимого типа ENUMERATION (см. раздел 6.4.1). А способ представлениясамого состояния элемента определяется одним из паттернов отображения атрибутовбазовых типов. Поскольку в качестве базовых могут выступать пользовательскиетипы данных, эквивалентные с точки зрения способов представления в реляционнойсхеме, то для исключения избыточности и минимизации затрат памяти целесообразновыделить подмножество неэквивалентных базовых типов и предусмотреть способы ихадекватного реляционного представления. При этом дискриминатор селективногоэлемента позволит однозначно идентифицировать, в каком именно состояниихранимые данные находятся.
Удобноразличать два встречаемых на практике случая определения селективного типа.Первый случай соответствует селективным типам, базируемым только на простых иассоциативных типах данных, учитывая возможный вложенный характер составныхтипов. Второй общий случай охватывает все возможные варианты определенияселективного типа на основе произвольной комбинации базовых, в том числе и сучастием агрегатов.6.4.4.1 Паттерн Select–Columns
Данныйпаттерн применим к отображению атрибутов селективных типов, относящихся кпервому случаю. В реляционной схеме селективный элемент такого видапредставляется набором столбцов в таблице объектов класса. Один из столбцоврезервируется для хранения дискриминатора селективных элементов. А остальныеиспользуются для хранения всех возможных альтернативных неэквивалентныхсостояний самих селективных данных. В случаях, когда селективный тип являетсясоставным вложенным, в таблице резервируется необходимое число столбцов поддискриминаторы для каждого вложенного селективного типа, участвующего вопределении составного типа, и под каждое неэквивалентное состояние, в которомселективные данные могут находиться.
Достоинствомданного паттерна является возможность эффективной реализации базовых операцийнад объектами с участием атрибутов селективного типа путем непосредственнойадресации к таблице объектов. Он может использоваться в сочетании со всемирассмотренными выше паттернами отображения классов в рамках схемо-зависимойстратегии.6.4.4.2 Паттерн ClassSelect
Втех случаях, когда в определении атрибута селективного типа участвуютагрегатные конструкции, применение рассмотренного выше паттерна являетсяпроблематичным и возникает необходимость представления значений атрибута классаотдельной таблицей __Select. Организация даннойтаблицы повторяет структуру столбцов в предыдущем паттерне отображения заисключением того, что резервируются дополнительные столбцы для храненияиндексов элементов агрегатов, участвующих в определении селективного типа.Число столбцов, необходимое для этого, определяется максимальной глубинойвложенности используемых конструкций упорядоченных агрегатов. Для связи собъектами используется ссылка из таблицы __Selectна соответствующую таблицу объектов классов в виде внешнего ключа записей в ней.
Посравнению с предыдущим паттерном для реализации базовых операций над объектамивозникает необходимость доступа к нескольким таблицам, однако при этом онохватывает наиболее общий случай определения атрибутов произвольного селективноготипа. Отметим, что вспомогательные операции со значениями селективных атрибутоввыполняются достаточно эффективно, поскольку в таблице хранятся толькозначения, соответствующие одному атрибуту (или нескольким однотипным атрибутам)одного класса. Однако число реляционных таблиц при отображении масштабныхприкладных моделей может быть значительным с учетом повторяемости используемыхселективных типов в определениях классов.6.4.4.3 Паттерн HierarchySelect
Настоящийпаттерн устраняет отмеченный выше недостаток за счет использования однойтаблицы для каждого селективного типа, встречаемого в определениисамостоятельной иерархии наследования классов. Однако контекст егоиспользования ограничивается единственным паттерном отображения классовOneInheritanceHierarchy–OneTable. Организация таблицы для каждого селективноготипа повторяет предыдущий случай. Для связи с объектами используется внешнийключ записей объектов в таблице _Instances. Данный паттернпозволяет существенно сократить число таблиц, необходимых для реляционногопредставления масштабных прикладных моделей, за счет хранения однотипныхселективных данных в единых таблицах. Их размер естественно возрастает, чтоприводит к замедлению операций работы с хранимыми селективными данными, однакообщее число таблиц, критичное для большинства современных реализацийреляционных СУБД, снижается.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
Данныйпаттерн предполагает организацию специальных столбцов для хранения размерностейагрегата непосредственно в таблице объектов класса, а также создание отдельнойтаблицы __Aggregate для хранения значений ииндексов элементов агрегата. Такая таблица создается для каждого агрегатногоатрибута каждого класса. Для связи с объектами используется ссылка из__Aggregate на соответствующую таблицу объектовклассов в виде внешнего ключа записей в ней.
Паттернохватывает наиболее общий случай определения атрибутов произвольногоагрегатного типа. При этом число реляционных таблиц при отображении масштабныхприкладных моделей обычно велико с учетом повторяемости эквивалентныхагрегатных типов в определениях классов.6.4.5.2 Паттерн HierarchyAggregate
Настоящийпаттерн уменьшает число таблиц, необходимых для представления агрегатных данныхза счет использования одной таблицы для каждого агрегатного типа, встречаемогов определении самостоятельной иерархии наследования классов. Размер такихтаблиц при этом увеличивается, что приводит к замедлению операций работы схранимыми агрегатными данными, однако общее число таблиц, критичное длябольшинства современных реализаций реляционных СУБД, снижается. Контекстиспользования паттерна ограничивается соответствующей схемой отображенияклассов OneInheritanceHierarchy–OneTable. Для связи с объектами используетсявнешний ключ записей объектов в таблице _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 схемой:
·          procedureRegister_Defined_Type – регистрация в базе данных пользовательского типа схемы;
·          procedureSave_Enum_Type – сохранение метаданных для перечислимого типа;
·          procedureSave_Select_Type – сохранение метаданных для селективного типа;
·          procedureSave_Aggregate_Type – сохранение метаданных для агрегатного типа;
·          functionGet_Type – выдача метаинформации о пользовательском типе данных.
Пакетlb_entity предназначен для работы с метаинформацией, относящейся к объектнымтипам EXPRESS схемы:
·          functionRegister_Entity – регистрация объектного типа схемы;
·          procedureSave_Attribute – сохранение метаданных для атрибута, определяемого врегистрируемом объектном типе;
·          procedureSave_Inheritance_Relations – сохранение информации о подтипах и супертипахрегистрируемого объектного типа;
·          functionAdd_Entity_From_Schema – экспортирование информации об объектном типе из другойсхемы;
·          functionGet_Entity – выдача метаинформации об объектном типе;
·          functionGet_Attribute – выдача метаинформации об атрибуте, определяемом в объектномтипе схемы.
Пакетlb_instance предназначен для работы с данными: занесения данных в базу, а такжедля извлечения данных из нее на основе запросов:
·          functionInit_Instance – инициация сохранения объекта;
·          procedureInit_Attribute_List – инициация сохранения значений атрибутов объекта;
·          procedurePut_Simple_Attribute_{R, I, S, B, L, E} – сохранение значения атрибутавещественного, целочисленного, символьного, бинарного, логического,перечислимого типа, соответственно;
·          procedurePut_Association – сохранение значения атрибута ассоциативного типа;
·          functionPut_Aggregate – инициация сохранения элементов агрегата;
·          functionPut_Select – инициация сохранения селективного элемента;
·          procedurePut_Element_{R, I, S, B, L, E} – сохранение значения элемента агрегатной илиселективной конструкции вещественного, целочисленного, символьного, бинарного,логического, перечислимого типа, соответственно;
·          procedureGet_Instances_By_ID – выборка объектов по заданным идентификаторам;
·          procedureGet_Instances_By_Type – выборка объектов по заданному типу;
·          procedureGet_Instances_By_Route – выборка объектов по заданному навигационному маршруту;
·          procedureAdd_Route_Path – метод формирования навигационного маршрута;
·          procedure Get_All_Instances – выборка всех объектов;
·          procedureDelete_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.3BLOB стратегия
Наконец,третий разработанный вариант реализации адаптера основан на применении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.