Мова опису інформаційних моделей EXPRESS

Типи GENERIC, AGGREGATE, а також ARRAY, SET, BAG і LIST OF GENERIC забезпечують узагальнену реалізацію функцій і процедур з використанням абстракцій простих і агрегатних даних.
Для об'єктних типів використовується конструкція ENTITY, що передбачає різноманітні моделі простого та множинного спадкування за допомогою кваліфікаторів AND, ANDOR, ONEOF. При специфікування об'єктного типу задаються атрибути та асоціації різної кратності (EXPLICIT), зворотні асоціації (INVERSE), а також похідні обчислювані властивості об'єктів (DERIVED). Останні визначаються типами і виразами, які можуть включати в себе значення явних атрибутів, константи, виконувані оператори, включаючи виклик функцій і процедур, як стандартних, так і для користувача.
Обмеження цілісності даних задаються безпосередньо при визначенні об'єктного типу за допомогою конструкції WHERE, визначальною логічні умови у вигляді виразів логічного типу, а також за допомогою кваліфікатора UNIQUE, приписуваного умова унікальності атрибутам, асоціаціям і похідним властивостями в популяціях споріднених об'єктів. Для завдання глобальних обмежень над різнорідними об'єктами передбачена конструкція RULE, що дозволяє описати обмеження у вигляді формальної специфікації функції логічного типу.
Визначення глобальних констант, простих і об'єктних типів даних, глобальних обмежень об'єднуються в розділі інформаційної схеми моделі (SCHEMA). За допомогою конструкцій імпорту USE і REFERENCE досягається можливість використання в одній схемі визначень з інших схем, що забезпечує розробку складних інформаційних моделей шляхом ієрархічної композиції окремих схем. Таким чином, охоплюються різноманітні практично змістовні випадки об'єктно-орієнтованого моделювання прикладних даних.
Нижче представлений приклад інформаційної моделі на мові EXPRESS - схема ActorResource, специфицируются інформацію про персони і організаціях, що беруть участь у спільному проекті, їх ролі в ньому і стосунки між ними.
SCHEMA ActorResource;
TYPE ActorSelect = SELECT (Organization, Person);
END_TYPE;
TYPE AddressTypeEnum = ENUMERATION OF (
END_TYPE;
TYPE Label = STRING (255);
END_TYPE;
TYPE ActorRole = Label;
END_TYPE;
ENTITY Address
ABSTRACT SUPERTYPE OF (ONEOF (PostalAddress, TelecomAddress));
Purpose: AddressTypeEnum;
UserDefinedPurpose: OPTIONAL STRING;
INVERSE
OfPerson: SET OF Person FOR Addresses;
OfOrganization: SET OF Organization FOR Addresses;
WHERE
WR1: (Purpose <> AddressTypeEnum.USERDEFINED) OR
((Purpose = AddressTypeEnum.USERDEFINED) AND
EXISTS (UserDefinedPurpose));
END_ENTITY;
ENTITY PostalAddress
SUBTYPE OF (Address);
AddressLines: LIST [1:?] OF Label;
END_ENTITY;
ENTITY TelecomAddress
SUBTYPE OF (Address);
TelephoneNumbers: OPTIONAL LIST [1:?] OF Label;
FacsimileNumbers: OPTIONAL LIST [1:?] OF Label;
ElectronicMailAddresses: OPTIONAL LIST [1:?] OF Label;
WWWUrls: OPTIONAL LIST [1:?] OF Label;
WHERE
WR1: EXISTS (TelephoneNumbers) OR EXISTS (FacsimileNumbers) OR
EXISTS (ElectronicMailAddresses) OR EXISTS (WWWUrls);
END_ENTITY;
ENTITY Organization;
Id: INTEGER;
Name: Label;
Description: OPTIONAL STRING;
Roles: LIST [0:?] OF UNIQUE ActorRole;
Addresses: LIST [1:?] OF UNIQUE Address;
INVERSE
IsRelatedBy: SET OF OrganizationRelationship FOR RelatedOrganizations;
Relates: SET OF OrganizationRelationship FOR RelatingOrganization;
Engages: SET OF Person FOR EngagedIn;
UNIQUE
UR1: Id;
END_ENTITY;
ENTITY OrganizationRelationship;
Name: Label;
Description: OPTIONAL STRING;
RelatingOrganization: Organization;
RelatedOrganizations: SET [1:?] OF Organization;
END_ENTITY;
ENTITY Person;
Id: INTEGER;
FamilyName: OPTIONAL Label;
GivenName: OPTIONAL Label;
MiddleNames: OPTIONAL LIST [1:?] OF Label;
PrefixTitles: OPTIONAL LIST [1:?] OF Label;
SuffixTitles: OPTIONAL LIST [1:?] OF Label;
Roles: LIST [0:?] OF UNIQUE ActorRole;
Addresses: OPTIONAL LIST [1:?] OF UNIQUE Address;
EngagedIn: SET OF Organization;
UNIQUE
UR1: Id;
WHERE
WR1: EXISTS (FamilyName) OR EXISTS (GivenName);
END_ENTITY;
END_SCHEMA;
До теперішнього часу в рамках міжнародних програм по стандартизації прикладних інформаційних моделей та інтероперабельності програмних додатків накопичений значний ресурс багатопрофільних міждисциплінарних моделей. Ресурс охоплює такі наукові та промислові області, як машинобудування, авіаційну та космічну промисловість, суднобудування, нафтогазовий комплекс, архітектуру і будівництво, електронну промисловість, фармацевтику, геоінформатику. Значна частина розроблених на мові EXPRESS специфікацій прийнята в якості документів ISO-10303. Інша частина розробляється безпосередньо промисловими альянсами для подальшого подання до міжнародної організації по стандартах.
До істотних особливостей прикладних інформаційних моделей слід віднести:
· Складність і масштабність моделей, що виражаються у великій кількості типів, що визначаються в рамках однієї інформаційної схеми, у застосуванні альтернативних механізмів множинного спадкоємства і поліморфного перевизначення властивостей об'єктних типів, а також у використанні вкладених агрегатних і селективних конструкцій і двонаправлених асоціацій;
· Необхідність підтримки запитів до даних у декларативному предикативному і навігаційному стилях, а також ефективну реалізацію базових операцій маніпулювання ними;
· Широкий контекст використання моделей у додатках, що оперують як з даними однієї багатопрофільної інформаційної схеми, так і з даними декількох незалежних схем.
Дані особливості обумовлюють пошук ефективних рішень для об'єктно-реляційного відображення та їх систематизацію для комплексного використання в конкретних прикладних контекстах.

6. Загальна систематизація підходів

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

Незалежно від особливостей застосовуваних підходів нам бачиться ряд пов'язаних між собою аспектів відображення прикладних даних з об'єктно-орієнтованої моделі в реляційну. Перш за все, це технічні питання семантичного відображення в реляційну метамодель базових конструкцій мови EXPRESS, а саме:
· Елементарних базових типів;
· Перелічуваних типів;
· Асоціативних зв'язків між об'єктами;
· Селективних типів;
· Агрегатних типів;
· Вкладених структур даних, заснованих на базових, перелічуваних, асоціативних, селективних і агрегатних типах даних;
· Простих і складних об'єктних типів у рамках моделі множинного спадкування;
· Інформаційних схем.
Не менш істотними для практичного застосування є часто суперечать один одному проблеми:
· Вибору стратегії відображення у відповідності з контекстом використання семантики інформаційної моделі;
· Підтримки метаданих в реляційному поданні та їх конструктивного застосування в ході сесії користувачів;
· Ефективності реалізації об'єктних запитів і операцій маніпулювання об'єктами (створення, модифікація, видалення);
· Оптимізації використовуваних ресурсів, включаючи витрати пам'яті;
· Сопровождаемости рішень та їх гнучкості по відношенню до можливої ​​еволюції використовуваних прикладних моделей.

6.2 Відображення інформаційних схем

Питання про вибір стратегії відображення в рамках схемо-залежного (СЗ) або схемо-незалежного (СН) підходів є найбільш принципових для систематизації методів об'єктно-реляційного відображення та їх адекватного застосування в додатках.

6.2.1 Схема-незалежна стратегія

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

6.2.2 Схема-залежна стратегія

Схемо-залежна стратегія більшою мірою орієнтована на додатки, які оперують з єдиною моделлю даних, не змінюваної протягом усього життєвого циклу проекту. Організація реляційної системи в цьому випадку може відображати і враховувати особливості конкретної прикладної моделі. Схемо-залежна стратегією не виключається і одночасна підтримка декількох моделей. Однак у силу складності супроводу і адміністрування реляційних баз даних з великою кількістю таблиць її використання в цьому випадку може виявитися вкрай обтяжливим.
Перевагою схемо-залежною стратегії є можливість більш ефективної реалізації об'єктних запитів і операцій маніпулювання об'єктами за рахунок безпосередньої адресації до таблиць з збереженими даними, на відміну від схемо-незалежної стратегії, де така адресація здійснюється опосередковано через таблиці метаданих.
Як різновид схемо-залежною стратегії може розглядатися змішана (СМ) стратегія, яка полягає в організації системи таблиць по заданій прикладної моделі при одночасному використанні словників метаданих. При певній надмірності у поданні даних така стратегія забезпечує більш ефективну реалізацію складних запитів безпосередньо засобами реляційної СУБД, оскільки вся необхідна метаінформація може також зберігатися у вигляді таблиць і бути доступною при обробці запитів.

6.3 Відображення спадкування класів

Патерни, призначені для відображення відносин простого наслідування між класами, є добре відомими. У цій роботі ми обговоримо можливі варіанти відображень в рамках розвиненої моделі множинного наслідування мови EXPRESS.

6.3.1 Паттерн OneInheritanceHierarchy-OneTable

Перший, найбільш простий патерн OneInheritanceHierarchy-OneTable відповідає випадку відображення всіх конкретних споріднених класів, які мають загальний набір прабатьків, в одну таблицю <Hierarchy> _Instances. Прабатьком будемо називати клас-предок, у якого немає власних батьків.
У разі простого наслідування даний патерн трансформується в стратегію представлення конкретних класів у кожному дереві спадкування однієї реляційної таблицею. Атрибути всіх споріднених класів, які є вершинами дерева, відображаються у стовпці цієї таблиці. Якщо ієрархія наслідування класів у прикладній моделі представлена ​​кількома деревами, то кожному такому дереву буде відповідати окрема таблиця.
У загальному випадку множинного успадкування ієрархія класів представляється набором таблиць, кожна з яких відповідає одному із поєднань прабатьків. Усі атрибути класів, об'єднаних єдиним набором прабатьків, відображаються у стовпці конкретної таблиці з цього набору. Для записів об'єктів, в яких не визначено будь-які атрибути, у відповідних стовпцях прописуються нульові значення.
Перевагою патерну є можливість ефективної реалізації базових операцій над довільними об'єктами без додаткових витрат на складання значень атрибутів з різних таблиць і їх зворотне розподіл за ним. Також безпосередньо реалізується полиморфное читання. Єдина складність полягає у визначенні типу запитуваних об'єктів. Простота підтримки та розвитку такої СЗ стратегії робить її досить привабливою. Недоліком є ​​надмірне споживання пам'яті за рахунок надлишкового зберігання нульових значень, а іноді й необхідність індексування великого числа стовпців для прискорення виконання запитів за значеннями окремих атрибутів. При великій глибині спадкування класів, що є типовим в наукових і промислових моделях STEP, це може виявитися критичним як для споживання пам'яті, так і для продуктивності.

6.3.2 Паттерн OneClass-OneTable

У паттерні OneClass-OneTable кожен конкретний або абстрактний класи в ієрархії спадкоємства представляються окремої таблицею <Class> _Instances, при цьому власні атрибути даного класу відображаються в її стовпці. Для зв'язку з успадкованими атрибутами вона зберігає вторинні ключі відповідних записів у таблицях батьківських класів. У разі простого наслідування - один вторинний ключ, у разі множинного наслідування - кілька вторинних ключів, кожен з яких відповідає таблиці одного з батьків.
Оскільки при множинному спадкуванні можливі неоднозначні ситуації, коли атрибути одного й того самого базового класу успадковуються кілька разів, реалізація даного патерну пов'язана з аналізом і дозволом подібних ситуацій. У мові EXPRESS припустиме лише віртуальне успадкування, при якому будь-які атрибути базових класів повинні успадковуватися один раз. Тому при аналізі реконструюється основне дерево наслідування, а гілки, що призводять до циклів, ігноруються в результаті обнулення відповідних вторинних ключів до записів у таблицях батьківських класів. Випадки багаторазового успадкування атрибутів обробляються автоматично і не вимагають додаткового аналізу.
Паттерн забезпечує гарну продуктивність на операціях поліморфного читання, проте реалізація базових операцій над об'єктами пов'язана з витратами на складання значень атрибутів з декількох таблиць при читанні і їх розсилку за таблицями при записі і модифікації. При глибокій ієрархії успадкування такі витрати можуть виявитися істотними.
Витрати пам'яті в реалізації даного патерну близькі до оптимальних, оскільки зберігання вторинних ключів не вимагає великих накладних витрат. Як елемент схемо-залежною стратегії патерн не забезпечує простоту підтримки та еволюції складних прикладних моделей з розвиненою ієрархією наслідування.

6.3.3 Паттерн OneInheritancePath-OneTable

Деякі недоліки попереднього патерну компенсуються в результаті серіалізациі таблиць класів по відносинам спадкування. У паттерні OneInheritancePath-OneTable кожному конкретному класу відповідає своя таблиця <Concrete_Class> _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

Даний патерн застосуємо до прямих множинним асоціаціям за умови, що відповідна зворотна асоціація є простою. Іншими словами, з кожним об'єктом, що беруть участь у зв'язку, може бути асоційоване деякий безліч об'єктів. Однак кожен об'єкт таких множин може брати участь тільки в одній зворотного асоціації зв'язку з цим. Паттерн реалізується в рамках схемо-залежною стратегії шляхом включення в таблицю асоційованого класу <Associated_Class> (класу, на який міститься посилання в класі асоціації) зовнішнього ключа на таблицю <Associating_Class>. Ім'я ключа може відповідати імені зв'язку у відповідній специфікації <Associating_Class>. У разі упорядкованих множинних асоціацій (LIST або ARRAY OF ENTITY) може знадобитися додатковий стовпець у таблиці <Associated_Class> для зберігання індексу асоціації. Якщо зв'язок реалізується як елемент вкладеної агрегатної конструкції, то в даній таблиці передбачається необхідне число стовпців індексів для кожного з упорядкованих множин, що беруть участь в ній. Аналогічно, якщо зв'язок реалізується як елемент селективної конструкції, то в таблицю додається відповідний стовпець для подання дискримінатора. Більш докладно ці випадки описані в патернах відображення селективних і агрегатних конструкцій.
Читання асоціює об'єкта реалізується за допомогою однієї операції з'єднання або двох операцій запиту до таблиць <Associated_Class> і <Associating_Class>, один з яких є множинним. Запис об'єкта також пов'язана з множинною операцією модифікації зовнішніх ключів в записах асоційованих об'єктів. Витрати пам'яті в реалізації патерну близькі до оптимальних, оскільки витрати припадають лише на зберігання додаткового зовнішнього ключа, а іноді й індексу асоціації в таблиці <Associated_Class>, для кожного зв'язку, в якій асоційований клас бере участь.

6.4.3.2 Паттерн ClassAssociation

Даний патерн дозволяє безпосередньо представити множинні асоціативні відносини в результаті використання окремої таблиці в рамках схемо-залежною стратегії. Така таблиця <Class1> _ <Class2> _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

У тих випадках, коли у визначенні атрибута селективного типу беруть участь агрегатні конструкції, застосування розглянутого вище патерну є проблематичним і виникає необхідність представлення значень атрибута класу окремою таблицею <Class> _ <Attribute> _Select. Організація цієї таблиці повторює структуру стовпців у попередньому паттерні відображення за винятком того, що резервуються додаткові стовпці для зберігання індексів елементів агрегатів, які беруть участь у визначенні селективного типу. Кількість стовпців, необхідне для цього, визначається максимальною глибиною вкладеності використовуваних конструкцій упорядкованих агрегатів. Для зв'язку з об'єктами використовується посилання з таблиці <Class> _ <Attribute> _Select на відповідну таблицю об'єктів класів у вигляді зовнішнього ключа записів у ній.
У порівнянні з попереднім паттерном для реалізації базових операцій над об'єктами виникає необхідність доступу до кількох таблиць, але при цьому він охоплює найбільш загальний випадок визначення атрибутів довільного селективного типу. Відзначимо, що допоміжні операції зі значеннями селективних атрибутів виконуються досить ефективно, оскільки в таблиці зберігаються лише значення, відповідні одному атрибуту (або декільком однотипним атрибутами) одного класу. Однак число реляційних таблиць при відображенні масштабних прикладних моделей може бути значним з урахуванням повторюваності використовуваних селективних типів у визначеннях класів.

6.4.4.3 Паттерн HierarchySelect

Цей патерн усуває зазначений вище недолік за рахунок використання однієї таблиці для кожного селективного типу, встречаемого у визначенні самостійної ієрархії спадкування класів. Проте контекст його використання обмежується єдиним паттерном відображення класів OneInheritanceHierarchy-OneTable. Організація таблиці для кожного селективного типу повторює попередній випадок. Для зв'язку з об'єктами використовується зовнішній ключ записів об'єктів в таблиці <Hierarchy> _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

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

6.4.5.2 Паттерн HierarchyAggregate

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

6.4.5.3 Паттерн GenericAggregate

Даний патерн надає типове рішення для узагальненого реляційного представлення довільних атрибутів агрегатного типу. Він застосовується в поєднанні з паттерном відображення класів AllClasses-OneTable в рамках схемо-незалежної стратегії.
Таблиця Aggregates зберігає записи дескрипторів агрегатних даних, включаючи їх розмірності і посилання на об'єкти в таблиці Instances, атрибутами яких вони є. Таблиця є батьківського для елементів агрегату, що зберігаються в інших таблицях Integer_Elements, Real_Elements, String_Elements, Binary_Elements, Logical_Elements, Enum_Elements і Associations. У свою чергу, кожен запис в таблиці Aggregates може мати посилання на запис у цій же таблиці, якщо агрегат є елементом, вкладеним в інший батьківський агрегат, а також зберігати відповідний індекс у ньому. Якщо агрегат є одним зі значень селективного типу, то він посилається на відповідну батьківську конструкцію, подану записом в таблиці Selections. В інших випадках записи таблиці Aggregates посилаються на відповідні записи в таблиці Attributes для отримання метаінформації про агрегатному атрибуті.

6.5 Відображення метаданих

Для представлення метаданих в рамках схемо-незалежної і змішаної стратегій об'єктно-реляційного відображення необхідно передбачити спеціальну систему таблиць, яка в свою чергу може розглядатися як результат відображення об'єктно-орієнтованої метамоделі мови EXPRESS на реляційну модель. Оскільки повна метамодель мови EXPRESS досить складна, а об'єктно-реляційне відображення допускає безліч реалізацій, в тому числі на основі вищеописаних патернів, обмежимося розглядом наступного можливого варіанту організації таблиць. Система таблиць, дозволяє представити необхідну метаінформацію про EXPRESS схемою, її складі у вигляді визначених простих і об'єктних типів даних і організації атрибутів у класах об'єктів. Допустимі розширення реляційної схеми, що забезпечують подання різного роду обмежень, що допускаються мовою EXPRESS.
Таблиця Schemas призначена для подання інформаційних схем мови EXPRESS, зареєстрованих в реляційній базі даних. Вона зберігає первинні ключі записів і унікальні імена схем. Defined_Types - це таблиця простих типів даних, визначених користувачем, яка зберігає первинний ключ типу, його ім'я, а також посилання на базовий тип у вигляді зовнішнього ключа запису в цій же таблиці. Одинадцять визначених типів, відповідних семи елементарним типам мови EXPRESS, узагальненим асоціативному і перераховуємо типам, а також селективного і агрегатному супертіпа, заносяться заздалегідь при ініціалізації таблиці. Визначені типи є листками на дереві ієрархії складних типів, рекурсивно визначених користувачем і занесені до цієї таблиці у вигляді окремих записів. Defined_Types_To_Schemas - це таблиця відповідності визначених типів даних конкретних схемами. Зв'язок між користувальницьким типом та інформаційної схемою встановлюється через окрему таблицю, а не через зовнішній ключ у таблиці Defined_Types, оскільки один і той же тип може включатися в різні схеми, якщо у специфікації на мові EXPRESS для нього визначені директиви імпорту. Таблиця зберігає зовнішні ключі визначених користувачем типів і відповідних їм інформаційних схем. Пара зовнішніх ключів «тіп-схема» формує складовою первинний ключ запису в таблиці Defined_Types_To_Schemas, ніж контролюється унікальність включення типу в одну й ту саму схему.
Для детального опису перелічуваних, селективних і агрегатних типів додатково використовуються таблиці Enumeration_Constants, Select_Types і Aggregate_Types. Таблиця Enumerations_Constants містить списки можливих значень для кожного перечислимого користувальницького типу. Її стовпці зберігають символьні значення перечислимого типу і зовнішній ключ відповідного запису типу в таблиці Defined_Types. Аналогічним чином, таблиця Select_Types представляє списки базових типів, що входять у визначення кожного конкретного селективного типу, у вигляді зовнішніх ключів записів типів в таблиці Defined_Types. У стовпцях таблиці агрегатних типів Aggregate_Types міститься інформація про тип агрегату (ARRAY, LIST, SET або BAG), базовому типі його елементів у вигляді зовнішнього ключа відповідного запису в таблиці Defined_Types, дозволених значеннях нижньої і верхньої меж агрегату, ознаках допустимості наявності унікальних і невизначених елементів .
Таблиця класів Entities призначена для представлення об'єктних типів інформаційної схеми, зареєстрованої в базі даних. Її стовпці зберігають первинні ключі записів і унікальні імена сутностей. Аналогічно визначаються типами, прив'язка класів до схеми здійснюється через окрему таблицю відповідності Entities_To_Schemas. Для реконструкції відносин наслідування між класами використовується таблиця Inheritance_Relations, в якій дані відносини представлені парами зовнішніх ключів записів класів батьків і нащадків в таблиці Entities. Оскільки мова EXPRESS допускає множинне спадкування з ознаками AND або ANDOR, важливо мати альтернативне подання ієрархії наслідування у вигляді множин всіх батьківських класів, дані яких включаються до конструюються об'єкти складних класів. Для цієї мети використовується таблиця Complex_Entities. Для однаковості обробки об'єктів прості класи також представляються записами цієї таблиці. Таблиця Complex_Entities_To_Entities зберігає всі відповідності складних класів батьківським класам у вигляді пари зовнішніх ключів записів у таблицях Complex_Entities і Entities.
Нарешті, таблиця атрибутів Attributes містить стовпці для представлення імені атрибута, класу, в якому даний атрибут визначається (або перевизначається), у вигляді відповідного зовнішнього ключа запису в таблиці Entities, типу атрибуту у вигляді зовнішнього ключа запису в таблиці Defined_Types, ознаки обов'язковості значень і контексту використання (EXPLICIT, DERIVED або INVERSE).
На закінчення відзначимо, що наведена схема досить зручна для реалізації проміжного об'єктно-реляційного шару в рамках схемо-незалежної і змішаної стратегій безпосередньо засобами реляційної СУБД. Разом з тим, можливий ряд її модифікацій, пов'язаних з іншими способами реляційного представлення метамоделі EXPRESS шляхом використання альтернативних патернів відображення прикладних об'єктно-орієнтованих моделей, розглянутих вище.

7. Реалізація проміжного об'єктно-реляційного шару в

середовищі Oracle 9

В даний час в рамках проекту створення програмної платформи для інтеграції програм ведеться розробка проміжного об'єктно-реляційного шару загального призначення. Об'єктно-реляційний шар призначений для роботи з довільними прикладними об'єктно-орієнтованими даними, моделі яких описані мовою EXPRESS.
Для інтегровних додатків об'єктно-реляційний шар надає програмні об'єктно-орієнтовані інтерфейси доступу до прикладних даними на деяких популярних мовах реалізації). Організація цих інтерфейсів слід перерахованим вище принципам прозорого маніпулювання збереженими даними, декларованим Маніфестом об'єктно-орієнтованих баз даних. Інтерфейси надають функціонально розвинений набір операцій для маніпулювання збереженими і тимчасовими об'єктами, включаючи операції створення, модифікації, видалення об'єктів, навігації по їх односпрямованим і двонаправленим асоціативним зв'язкам та вибірки об'єктів на основі мови запитів. Запити базуються на конструкції QUERY мови EXPRESS, що дозволяє задати довільний предикат на безлічі об'єктів і відібрати ті з них, які задовольняють умові даного предиката. Інтерфейси передбачають кілька песимістичних і оптимістичних моделей транзакцій з різними способами ізоляції на рівні окремих прикладних об'єктів і самостійних об'єктних популяцій, змістовних для колективних сесії користувачів та беруть участь у них додатків.
По специфікації дані інтерфейси сумісні з відповідними частинами міжнародного інформаційного стандарту за інтероперабельності STEP і тому забезпечують інтегрованість широкого класу успадкованих і знову створюваних програмних систем наукового та промислового призначення.
В якості сховища даних реалізація об'єктно-реляційного шару передбачає використання реляційних СУБД зі схемами, заснованими на розглянутих вище патернах об'єктно-реляційного відображення. При цьому функції з управління транзакціями, вирішення запитів, контролю цілісності даних, управління версіями і контролю прав доступу розподіляються між сервером об'єктно-реляційного шару, через який безпосередньо взаємодіють програми, і реляційної СУБД, яка виступає в ролі вторинного сховища даних.
Найважливішими функціями, реалізованими безпосередньо засобами реляційної СУБД, є операції маніпулювання збереженими об'єктами та виконання простих об'єктних запитів. З цією метою на мові PL / SQL розробляються пакети програм, що емулюють об'єктно-орієнтовані інтерфейси доступу до даних шляхом надання функціональних засобів для створення, модифікації, пошуку і видалення об'єктів. Оскільки повна підтримка об'єктної мови запитів засобами реляційної СУБД представляється проблематичним з урахуванням різноманітності імперативних конструкцій мови EXPRESS, пакети програм виконують найпростіші види запитів на основі збережених об'єктних ідентифікаторів (PID), об'єктних типів і навігаційних маршрутів у вигляді графів переходів по асоціативних зв'язків типізованих об'єктів. Підтримуючи кешування об'єктів, посередник у ряді випадків дозволяє запити самостійно, а іноді переадресовує їх реляційної СУБД. При цьому відбувається редукція клієнтського запиту, поданого в загальній формі, до запиту спрощеного виду, що розширює безліч об'єктів і здійсненного пакетом програм реляційної СУБД. Результати потім обробляються посередником з метою виключення об'єктів, отриманих в результаті інтерпретації спрощеного запиту і не задовольняють вихідному.