Name : Label;
Description : OPTIONAL STRING;
RelatingOrganization : Organization;
RelatedOrganizations : SET [1:?] OF Organization;
END_ENTITY;
ENTITY Person;
Id : INTEGER;
FamilyName : OPTIONAL Label;
GivenName : OPTIONAL Label;
MiddleNames : OPTIONAL LIST [1:?] OF Label;
PrefixTitles : OPTIONAL LIST [1:?] OF Label;
SuffixTitles : OPTIONAL LIST [1:?] OF Label;
Roles : LIST [0:?] OF UNIQUE ActorRole;
Addresses : OPTIONAL LIST [1:?] OF UNIQUE Address;
EngagedIn : SET OF Organization;
UNIQUE
UR1 : Id;
WHERE
WR1 : EXISTS(FamilyName) OR EXISTS(GivenName);
END_ENTITY;
END_SCHEMA;
К настоящему времени в рамках международных программ по стандартизации прикладных информационных моделей и интероперабельности программных приложений накоплен значительный ресурс многопрофильных междисциплинарных моделей. Ресурс охватывает такие научные и промышленные области, как машиностроение, авиационную и космическую промышленность, судостроение, нефтегазовый комплекс, архитектуру и строительство, электронную промышленность, фармацевтику, геоинформатику. Значительная часть разработанных на языке EXPRESS спецификаций принята в качестве документов ISO-10303. Другая часть разрабатывается непосредственно промышленными альянсами для последующего представления в международную организацию по стандартам.
К существенным особенностям прикладных информационных моделей следует отнести:
· сложность и масштабность моделей, выражающиеся в большом количестве типов, определяемых в рамках одной информационной схемы, в применении альтернативных механизмов множественного наследования и полиморфного переопределения свойств объектных типов, а также в использовании вложенных агрегатных и селективных конструкций и двунаправленных ассоциаций;
· необходимость поддержки запросов к данным в декларативном предикативном и навигационном стилях, а также эффективную реализацию базовых операций манипулирования ими;
· широкий контекст использования моделей в приложениях, оперирующих как с данными одной многопрофильной информационной схемы, так и с данными нескольких независимых схем.
Данные особенности обуславливают поиск эффективных решений для объектно-реляционного отображения и их систематизацию для комплексного использования в конкретных прикладных контекстах.
Независимо от особенностей применяемых подходов нам видится ряд связанных между собой аспектов отображения прикладных данных из объектно-ориентированной модели в реляционную. Прежде всего, это технические вопросы семантического отображения в реляционную метамодель базовых конструкций языка EXPRESS, а именно:
· элементарных базовых типов;
· перечислимых типов;
· ассоциативных связей между объектами;
· селективных типов;
· агрегатных типов;
· вложенных структур данных, основанных на базовых, перечислимых, ассоциативных, селективных и агрегатных типах данных;
· простых и сложных объектных типов в рамках модели множественного наследования;
· информационных схем.
Не менее существенными для практического применения являются часто противоречащие друг другу проблемы:
· выбора стратегии отображения в соответствии с контекстом использования семантики информационной модели;
· поддержки метаданных в реляционном представлении и их конструктивного применения в ходе пользовательских сессий;
· эффективности реализации объектных запросов и операций манипулирования объектами (создание, модификация, удаление);
· оптимизации используемых ресурсов, включая затраты памяти;
· сопровождаемости решений и их гибкости по отношению к возможной эволюции используемых прикладных моделей.
Вопрос о выборе стратегии отображения в рамках схемо-зависимого (СЗ) или схемо-независимого (СН) подходов является наиболее принципиальным для систематизации методов объектно-реляционного отображения и их адекватного применения в приложениях.
Схемо-независимая стратегия ориентирована на использование единой реляционной схемы для представления произвольных прикладных данных, модели которых специфицированы на EXPRESS. Для приложений, оперирующих одновременно с несколькими перманентно изменяемыми прикладными моделями, применение схемо-независимая стратегии является наиболее предпочтительным. Сопровождение и администрирование реляционной базы данных с фиксированной системой таблиц, состав и структура которой не меняется, достаточно просты.
К издержкам стратегии следует отнести необходимость поддержки и использования словарей метаданных, без которых реализация промежуточного объектно-реляционного слоя невозможна. Сами словари также могут быть представлены в виде таблиц, хранящих информацию об исходных прикладных моделях и включенных в состав единой реляционной системы. Другим недостатком является относительно низкая эффективность выполнения базовых операций манипулирования объектами, поскольку их реализация сопряжена с необходимым дополнительным анализом сопутствующих метаданных.
Схемо-зависимая стратегия в большей степени ориентирована на приложения, оперирующие с единственной моделью данных, не изменяемой на протяжении всего жизненного цикла проекта. Организация реляционной системы в этом случае может отражать и учитывать особенности конкретной прикладной модели. Схемо-зависимая стратегией не исключается и одновременная поддержка нескольких моделей. Однако в силу сложности сопровождения и администрирования реляционных баз данных с большим количеством таблиц ее использование в этом случае может оказаться крайне обременительным.
Достоинством схемо-зависимой стратегии является возможность более эффективной реализации объектных запросов и операций манипулирования объектами за счет непосредственной адресации к таблицам с хранимыми данными, в отличие от схемо-независимой стратегии, где такая адресация осуществляется косвенно через таблицы метаданных.
Как разновидность схемо-зависимой стратегии может рассматриваться смешанная (СМ) стратегия, заключающаяся в организации системы таблиц по заданной прикладной модели при одновременном использовании словарей метаданных. При определенной избыточности в представлении данных такая стратегия обеспечивает более эффективную реализацию сложных запросов непосредственно средствами реляционной СУБД, поскольку вся необходимая метаинформация может также храниться в виде таблиц и быть доступной при обработке запросов.
Паттерны, предназначенные для отображения отношений простого наследования между классами, являются хорошо известными. В этой курсовой работе мы обсудим возможные варианты отображений в рамках развитой модели множественного наследования языка EXPRESS.
Первый, наиболее простой паттерн OneInheritanceHierarchy–OneTable соответствует случаю отображения всех конкретных родственных классов, имеющих общий набор прародителей, в одну таблицу <Hierarchy>_Instances. Прародителем будем называть класс-предок, у которого нет собственных родителей.
В случае простого наследования данный паттерн трансформируется в стратегию представления конкретных классов в каждом дереве наследования одной реляционной таблицей. Атрибуты всех родственных классов, являющихся вершинами дерева, отображаются в столбцы данной таблицы. Если иерархия наследования классов в прикладной модели представлена несколькими деревьями, то каждому такому дереву будет соответствовать отдельная таблица.
В общем случае множественного наследования иерархия классов представляется набором таблиц, каждая из которых соответствует одному из сочетаний прародителей. Все атрибуты классов, объединенных единым набором прародителей, отображаются в столбцы конкретной таблицы из этого набора. Для записей объектов, в которых не определены какие-либо атрибуты, в соответствующих столбцах прописываются нулевые значения.
Достоинством паттерна является возможность эффективной реализации базовых операций над произвольными объектами без дополнительных расходов на сборку значений атрибутов из разных таблиц и их обратное распределение по ним. Также непосредственно реализуется полиморфное чтение. Единственная сложность состоит в определении типа запрашиваемых объектов. Простота поддержки и развития такой СЗ стратегии делает ее довольно привлекательной. Недостатком является излишнее потребление памяти за счет избыточного хранения нулевых значений, а иногда и необходимость индексирования большого числа столбцов для ускорения выполнения запросов по значениям отдельных атрибутов. При большой глубине наследования классов, что является типичным в научных и промышленных моделях STEP, это может оказаться критичным как для потребления памяти, так и для производительности.
В паттерне OneClass–OneTable каждый конкретный или абстрактный классы в иерархии наследования представляются отдельной таблицей <Class>_Instances, при этом собственные атрибуты данного класса отображаются в ее столбцы. Для связи с наследуемыми атрибутами она хранит вторичные ключи соответствующих записей в таблицах родительских классов. В случае простого наследования — один вторичный ключ, в случае множественного наследования — несколько вторичных ключей, каждый из которых соответствует таблице одного из родителей.
Поскольку при множественном наследовании возможны неоднозначные ситуации, когда атрибуты одного и того же базового класса наследуются несколько раз, реализация данного паттерна сопряжена с анализом и разрешением подобных ситуаций. В языке EXPRESS допустимо лишь виртуальное наследование, при котором любые атрибуты базовых классов должны наследоваться единожды. Поэтому при анализе реконструируется основное дерево наследования, а ветви, приводящие к циклам, игнорируются в результате обнуления соответствующих вторичных ключей к записям в таблицах родительских классов. Случаи многократного наследования атрибутов обрабатываются автоматически и не требуют дополнительного анализа.