CC BY
23
УДК 004.896
ИНТЕГРАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ МЕТОДА СЛИЯНИЯ ОНТОЛОГИИ ПРИ РАСЧЕТЕ БАЛАНСА ПРОИЗВОДСТВЕННЫХ МОЩНОСТЕЙ
© 2018 Н.Г. Ярушкина, A.A. Романов, A.A. Филиппов, А.Ю. Долгановская, М.С. Григоричева
Ульяновский государственный технический университет
Статья поступила в редакцию 01.11.2018
В этой статье представлен подход к интеграции данных на основе интегрирующей модели. Строится онтологическая модель данных, отображение данных из информационных систем в онтологическую модель. Рассматривается поясняющий иллюстративный пример. Ключевые слова: онтология, интеграция информационных систем, модель данных.
Исследование выполнено при финансовой поддержке РФФИ и Правительства Ульяновской области в рамках научных проектов № 16-47-732054, № 18-47-732016, № 18-47-730022. Исследование проведено в рамках государственного задания Минобрнауки РФ № 2.1182.2017/4.6 «Разработка методов и средств автоматизации производственно-технологической подготовки агрегатно-сборочного самолетостроительного производства в условиях мульти-продуктовой
производственной программы»
ВВЕДЕНИЕ
При разработке системы, позволяющей планировать балансировку мощностей производства авиастроительного предприятия [1], особое внимание следует обратить на то, что на таком предприятии уже существует фрагментарная автоматизация бизнес-процессов. Существующее информационное обеспечение (ИО) авиастроительного предприятия, как правило, покрывает потребности при выполнении основных бизнес-процессов производства. Однако в настоящее время проявляются следующие проблемы, связанные с динамикой развития ИО предприятия:
1. Увеличение объемов хранимых данных.
2. Расширение границ предметной области (ПрО).
3. Рост численности и количества команд разработчиков и пользователей информационных систем (ИС).
Решение данных проблем требует наложения ограничений по согласованности данных и знаний, находящихся как в хранилищах ИС, так
Ярушкина Надежда Глебовна, доктор технических наук, профессор, заведующий кафедрой «Информационные системы». E-mail: jng@ulstu.ru
Романов Антон Алексеевич, кандидат технических наук, доцент кафедры «Информационные системы». E-mail: romanov73@gmail.com
Филиппов Алексей Александрович, кандидат технических наук, доцент кафедры «Информационные системы». E-mail: al.al.filippov@gmail.com Долгановская Александра Юрьевна, аспирант. E-mail: adolganovskaya@mail.ru Григоричева Мария Сергеевна, аспирант. E-mail: gms4295@mail.ru
и в неструктурированном или неформализованном виде в ряде других источников.
Согласованности можно достичь путем решения следующих методологических проблем интеграции системы оптимизации ресурсов авиастроительного предприятия с существующим на предприятии ИО [2, 3, 4, 5]:
• отсутствие корректного формата или семантического слоя для слияния двух и более несопоставимых наборов данных. Устранение семантических различий между приложениями - одна из наиболее сложных и неформали-зуемых задач интеграции. Действительно, одна и та же сущность может иметь несколько различных семантик, ограничений и допущений в каждой системе;
• необходимость наличия методологии для документирования таких технических аспектов интеграции, как определение записей, структур данных, интерфейсов и потоков данных в масштабах всей организации;
• необходимость определения правил и методов согласования данных во всех интеграционных проектах.
Интеграция данных подразумевает объединение данных, находящихся в различных источниках, и предоставление данных пользователям в унифицированном виде. Системы интеграции данных могут обеспечивать интеграцию данных на физическом, логическом и семантическом уровнях. Интеграция данных на физическом уровне сводится к преобразованию данных, полученных из различных источников, в определенный унифицированный формат представления. Интеграция данных на логическом уровне подразумевает возможность получения данных,
расположенных в различных источниках, через единую точку входа - метасистему. Интеграция данных на семантическом уровне сводится к наличию единого представления данных с учетом их семантики.
Сложность процесса интеграции различается для каждого из выше представленных уровней интеграции [2, 3, 4, 5]:
• на физическом уровне могут использоваться различные форматы представления данных;
• на логическом уровне может иметь место неоднородность используемых моделей и/или схем данных для различных источников;
• на семантическом уровне различным источникам данных могут соответствовать различные ПрО или фрагменты ПрО, имеющие различный понятийный аппарат.
К основным проблемам интеграции данных относятся:
1. Разнородность (гетерогенность) моделей данных.
2. Автономность - независимость ИС друг от друга.
3. Распределенность - данные могут располагаться в различных сегментах локальной сети предприятия и/или в сети Интернет.
4. Различие формата данных.
5. Различие в представлении значений.
6. Потеря актуальности данных одним из источников.
Таким образом, при организации информационного взаимодействия системы оптимизации ресурсов авиастроительного предприятия с существующим на предприятии ИО возникает необходимость решения следующих методологических задач [2, 3, 4, 5]:
1. Создание интегрирующей модели данных, являющейся основой единого пользовательского интерфейса в системе интеграции.
2. Разработка методов отображения моделей данных и построение отображений в интегрирующую модель для конкретных моделей, поддерживаемых отдельными источниками данных.
3. Интеграция метаданных, используемых в системе источников данных.
4. Преодоление неоднородности источников данных.
5. Разработка механизмов семантической интеграции источников данных.
1. ПОСТАНОВКА ПРОБЛЕМЫ
Цели, которые требуется достичь при реализации механизмов информационного взаимодействия системы оптимизации ресурсов авиастроительного предприятия с существующим на предприятии ИО:
1. Обеспечить полноту и непротиворечивость данных, необходимых для оптимиза-
ции ресурсов производства авиастроительного предприятия.
2. Минимизировать дополнительный ввод информации, требуется максимально эффективно использовать накопленные в хранилищах ИС авиастроительного предприятия сведения.
3. Обеспечить возможность расширения системы. ИО системы оптимизации ресурсов авиастроительного предприятия должно требовать минимальных затрат на процесс сопровождения при добавлении в систему новой функциональности.
Для достижения первой и второй цели следует решить задачу интеграции с существующим ИО авиастроительного предприятия. Основным требованием в данном случае является совмещения интерфейсов и типов данных.
Интеграция позволяет избежать дублированного ввода данных, что в свою очередь сокращает нагрузку на лиц, ответственных за их актуализацию. При этом также устраняется проблема противоречивости данных, поскольку их потоки не будут двунаправленными, т.е. исключается момент синхронизации и одновременной актуализации данных в нескольких ИС. Вместо этого поток данных направляется от производящей стороны - существующие ИС авиастроительного предприятия, в сторону потребителя - системы оптимизации ресурсов авиастроительного предприятия.
Поставленная ранее цель сделать систему расширяемой предусматривает необходимость хранения наиболее полных сведений об объекте ПрО, т.е. информация хранится в виде списков с перечнем атрибутов. При проектировании ИО системы оптимизации ресурсов авиастроительного предприятия следует найти баланс в использовании методов типизации.
2. ПОДХОД К ИНТЕГРАЦИИ ИС НА ОСНОВЕ ИНТЕГРИРУЮЩЕЙ МОДЕЛИ ДАННЫХ
Для решения методологической задачи построения интегрирующей модели данных ИС обычно используются методы Linked Data.
Термин Linked Data был введен Тимом Бернерс-Ли и стал известен как «принципы связанных данных» [6]:
1. Использование унифицированных идентификаторов ресурса.
2. Организация доступа к списку ресурсов с применением протокола HTTP.
3. Использование стандартных технологий Semantic Web: RDF, OWL, SWRL, SPARQL.
4. Использование гиперссылок для идентификации не только веб-документов, но и любой сущности ПрО.
Принцип связанных данных предполагает
наличие стандартных средств и механизмов для определения наличия и семантики связей между сущностями, представленными данными. В рамках данного исследования в качестве такого средства используется язык представления знаний OWL [7], позволяющий описывать сущности ПрО и отношения между ними. Язык представления знаний OWL обладает следующими преимуществами [6]:
1. Позволяет связывать сущности ПрО и документы.
2. Ссылки и отношения между сущностями ПрО типизированы.
3. С помощью уникального идентификатора ресурсов существует возможность связывать любыми видами отношений любые сущности ПрО.
4. Каждая сущность ПрО является частью глобальных метаданных, каждая сущность ПрО может быть использована в качестве отправной точки для просмотра всего пространства данных.
5. Возможность установки связи между данными из различных источников.
6. Информация из различных источников может быть объединена путем слияния набора сущностей в один семантический граф.
7. Возможность смешивать термины различных словарей для представления данных.
8. Гибкость структуры модели данных.
Таким образом, язык представления знаний
OWL используется в интегрирующей модели данных в качестве единой, объединяющей ме-тамодели данных, опирающейся на общие словари путем предоставления терминов из различных словарей внешних источников.
2.1. ОНТОЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
В рамках данного исследования для реализации интегрирующей модели данных ИО системы оптимизации ресурсов авиастроительного предприятия с ИО существующих на предприятии ИС используются методы онтологического инжиниринга.
Онтология - модель представления знаний определенной ПрО, состоящая из множества определений основных понятий (имен классов, индивидуалов, свойств и т.д.), а также различного рода семантических связей между ними. В основе онтологии находится словарь терминов, отражающих понятия ПрО, и совокупность правил (аксиом), согласно которым эти термины могут быть скомбинированы для построения достоверных утверждений о состоянии рассматриваемой области в некоторый момент времени [8].
Таким образом, основываясь на онтологическом подходе, онтология модели данных будет иметь вид:
O = C ,P,L,R), (1)
где C = (Cj,C2,...,Cnj - множество классов онтологии модели данных;
P = {Pi, P2,..., Pm] - множество свойств классов онтологии модели данных;
L = - множество ограниче-
ний свойств классов онтологии модели данных;
R - множество отношений онтологии модели данных следующего вида:
R = \RC >RP RL }>
где RC - множество отношений, формирующих иерархию классов онтологии модели данных;
RP - множество отношений, определяющих связь вида «класс-свойство» онтологии модели данных;
Rl - множество отношений, определяющих связь вида «свойство-ограничение» онтологии модели данных.
2.2. ОТОБРАЖЕНИЕ МОДЕЛИ ДАННЫХ ИО ИС В ОНТОЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ МОДЕЛИ ДАННЫХ
В настоящее время для организации ИО ИС обычно используются реляционные базы данных (РБД). РБД содержат описание ПрО в виде связанных между собой сущностей (таблиц) [9, 10]. Необходимо разработать метод отображения структуры РБД в онтологическое представление модели данных.
Реляционную модель данных можно представить в виде следующего выражения:
RDM = (E ,H ,R), (2)
где E = {E\,E2,...,Ek} - множество сущностей (таблиц) РБД;
Ei = (name, Row, Col) - i -я сущность РБД, состоящая из имени и множества строк Row и столбцов Col ;
Colj = {name, type, constraints) - j -й столбец сущности РБД, содержащий свойства: название, тип и набор ограничений;
H = (Hj,H2,..., H¡] - иерархия сущностей РБД в случае использования функции наследования таблиц, при этом:
Hj = EtD( x) Eh,
где Ei ,Eh - сущности (таблицы и представления) РБД;
D(x) - связь вида «родитель-потомок» между сущностями Ei и E. РБД;
R = \R[,R1,..., Rm) - множество связей РБД, при этом:
Rk - eME
G(x)
h
где Et ,Eh - сущности (таблицы и представления) РБД;
F (х) - связь между сущностями Ei и Eh
РБД;
0(х) - связь между сущностями Eh и Ei РБД.
Функции F(х) и 0(х) РБД могут принимать значения: U - единичная связь и N - множественная связь.
Для отображения структуры РБД (выражение 2) в онтологическое представление модели данных (выражение 1) используется следующая функция:
F (RDM ,ü):{Erdm ,Hrdm ,RRdm} ^{C° ,P° ,L° ,R° }
где { ERDM, HRDM, RRdm) - множество сущностей РБД и отношений между ними (выражение 2);
|C°,P°,L°- множество сущностей онтологии модели данных (выражение 1).
В процессе отображения структуры РБД в онтологическое представление модели данных необходимо:
Шаг 1. Формирование классов онтологического представления модели данных
На основе множества сущностей РБД формируется множество классов C онтологии O модели данных Ei ^ Ci. Количество классов C должно быть равно количеству сущностей E РБД. Названием i -о класса онтологии O будет являться название i -й сущности РБД.
Шаг 2. Формирование свойств классов онтологического представления модели данных
На основе множества колонок Col i -й сущности Ei РБД формируется множество свойств P i -о класса Ci онтологии O модели данных Colj ^ Pj. Количество свойств i -о класса Ci онтологии ° должно быть равно количеству колонок i -й сущности Ei РБД. Названием j -о свойства P. класса будет являться название j -й
J J
колонки Col} сущности РБД.
Шаг 3. Формирование ограничений свойств классов онтологического представления модели данных
На основе множества колонок Col i -й сущности Ei РБД формируется множество ограничений свойств L i -о класса C онтологии O модели данных Colk ^ Lk. Размер полученного множества ограничений Lk i -о класса Ct онтологии ° должен быть равен количеству ограничений колонок i -й сущности Ei РБД . В данном случае возникает ограничение данного подхода, связанное с трудностями отображения ограничений в случае их представления в качестве триггеров или хранимых процедур.
Шаг 4. Формирование иерархии классов онтологического представления модели данных
Если в РДБ применяется наследование та-
блиц необходимо сформировать множество отношений RC онтологии O между всеми дочерними и родительскими классами, соответствующим иерархии сущностей РБД H ^ RC В качестве домена j -о отношения R.C онтологии O модели данных указывается ссылка на с
класс-родитель parent онтологии 0. В качестве диапазона отношения R.jC указывается ссылка на класс-потомок Cchild онтологии O.
Шаг 5. Формирование отношений между классами и свойствами классов онтологического представления модели данных
На основе множества колонок Col i -й сущности Ei и множества связей R РБД формиру-
ется множество отношении
й Rn
онтологии
о.
При этом для каждого j -о свойства Pj онтологии 0 формируется два вида отношений:
Отношение вида «класс владелец - свойство». В качестве домена k -о отношения Rp¿ онтологии O модели данных указывается ссылка на i -й класс Ci онтологии O, которому принадлежит данное свойство, а в качестве диапазона ссылка на j -е свойство Pj онтологии O. Отношение вида «свойство - класс типа
данных». В качестве домена k -о отношения Rpk онтологии O модели данных указывается ссылка на j -е свойства Pj онтологии O, а в качестве диапазона ссылка на l -й класс Cl онтологии O, соответствующий l-й сущности El множества связей R РБД R ^ Rp, либо указывается ссылка на m -й класс Cm онтологии O , соответствующий m -у типу данных РБД j -й колонки Col ^ Rp .
Шаг 6. Формирование отношений между свойствами классами и ограничениями свойств классов онтологического представления модели данных На основе множества колонок Col i -й сущности Ei РБД формируется множество отношений Rl онтологии O. В качестве домена j -о отношения RjL онтологии O модели данных указывается ссылка на k -е свойство Pk онтологии O. В качестве диапазона отношения Rj¿yKa3HBaeTCfl ссылка на k -е ограничения Lk онтологии O Col ^ Rl .
Таблица 1 содержит описание сопоставления структурных компонентов РБД с сущностями онтологии O модели данных.
2.3. ФОРМИРОВАНИЕ ИНТЕГРИРУЮЩЕЙ МОДЕЛИ ДАННЫХ
После отображения структуры РБД каждой из интегрируемых ИС в онтологическое пред-
Таблица 1. Соответствие компонентов РБД и онтологии модели данных
Компонент РБД Сущность онтологии
Таблица Класс
Представление Класс
Встроенные типы данных Класс
Иерархия таблиц Отношение
Колонка с Свойство класса
внешним ключом Отношение
Колонка с данными Свойство класса
Отношение
Ограничение Ограничение
Отношение
ставление модели данных необходимо выполнить процесс формирования интегрирующей модели данных на основе полученных онтологических представлений.
В качестве формального представления интегрирующей модели данных можно использовать определение онтологической системы [11]:
О / /-лЫВТЛ /-лШ
х °=ometa ,üis ,m) ,
-\META
где О - онтология интегрирующеи модели данных (метаонтология);
Ов = {О®, О2 О™} - множество онтологических представлений модели данных ИО интегрируемых ИС;
М - модель машины вывода.
Для формирования интегрирующей модели
данных ОМЕТА на основе множества онтологических представлений модели данных ИО интегрируемых ИС ОБ необходимо выполнить следующие шаги:
Шаг 1. Выделение общего понятийного аппарата ПрО
Процесс формирования интегрирующей модели данных ОМЕТА обеспечивается наличием общей терминологии, и все частные онтологические представлений модели данных ИО интегрируемых ИС должны строиться на основе единого выделенного понятийного аппарата. Понятийный аппарат формируется экспертом ПрО на основе анализа полученных онтологических представлений.
Шаг 2. Создание интегрирующей модели данных ОМЕТА
На данном шаге в интегрирующую модель данных ОМЕТ'А добавляется множество классов верхнего уровня СМЕТ'А, описывающих ИО интегрируемых ИС и используемых в качестве основы в процессе слияния онтологий. Такие классы позволяют составить описание для ИО каждой ИС: название, метод подключения, сведения для авторизации и т.д.
Шаг 3. Формирование иерархии классов инте-
грирующей модели данных ОМЕТ'А
На данном шаге в интегрирующей модели
глМЕТА
данных О устанавливается соответствие
ОБ
между иерархиями классов С 1 онтологических представлений модели данных ИО интегрируемых ИС из множества О188 = {о^,0™,...,О® }.
Шаг 4. Формирование свойств классов интегрирующей модели данных ОМЕТ'А
На данном шаге в интегрирующей модели данных ОМЕТ'А устанавливается соответствие
ОЕ
между свойствами Р 1 классов онтологических представлений модели данных ИО интегрируемых ИС из множества О18 = {о{8 ,О'28 ,—,0® }■ На данном шаге эксперт принимает решение о том, какие свойства классов должны войти в интегрирующую модель данных ОМЕТА.
Шаг 5. Определение аксиом классов и свойств
О МЕТА
и проверка интегрирующей модели данных О на согласованность
На данном шаге происходит наложение ограничений на свойства и классы интегрирующей модели данных ОМЕТА с учетом ограничений, присутствующих в онтологических представлениях модели данных ИО интегрируемых ИС из множества Ож = {о® , О^,...,078 } . После этого полученную интегрирующую модель данных ОМЕТ-А необходимо проверить на внутреннюю согласованность с помощью машины вывода М . В данном случае требуется разработка методов проверки выполнения условий ограничений, так как существующие машины вывода не поддерживают работу с такими объектами.
3. ИЛЛЮСТРАТИВНЫЙ ПРИМЕР ПРОЦЕССА ФОРМИРОВАНИЯ ИНТЕГРИРУЮЩЕЙ МОДЕЛИ ДАННЫХ
Для иллюстрации процесса формирования интегрирующей модели данных рассмотрим следующий пример: необходимо осуществить интеграцию ИО системы оптимизации ресурсов
Таблица 2. Таблица РБД системы источника, реализующая сущность «Оборудование и инструменты»
Название Тип данных Описание
t2 ob CHAR(200) Название
t2_ng NUMBER(5) Номер группы
t2 nn NUMBER(6) Порядковый номер
t2_r1 CHAR Признак 1: 0 - оборудование 1 - инструмент 2 - материал 6 - специнструмент
t2_r2 CHAR Признак 2: 0 - гостированный 1 - специальный
t2_r3 CHAR Признак 3: 20 - нет 21 - эскиз 30 - модель 31 - эскиз и модель
t2_p1 CHAR(2) nullable Название параметра 1
t2_z1 CHAR(8) nullable Значение параметра 1
t2_p2 CHAR(2) nullable Название параметра 2
t2_z2 CHAR(8) nullable Значение параметра 2
t2_p3 CHAR(2) nullable Название параметра 3
t2_z3 CHAR(8) nullable Значение параметра 3
t2_gm BLOB Геометрическое представление инструмента
up_dt DATE Дата последней корректировки
up_us CHAR(32) Пользователь
t2 dc BLOB Прикреплённый документ
t2 vid CHAR(4) Вид технологической оснастки
t2 doc CHAR(100) Обозначение документа
t2_prim CHAR(100) nullable Примечания
t2_yyyy CHAR(4) Год производства
авиастроительного предприятия (приемник) с ИС, содержащей данные об оснащенности цехов авиастроительного предприятия (источник).
Система источник содержит в составе своего ИО РБД, в рамках данной БД реализована сущность «Оборудование и инструменты», представленная таблицей 2.
Система приемник содержит в составе своего ИО РБД, в рамках данной БД сущность «Оборудование и инструменты» реализована в виде следующих таблиц:
1. Оборудование (таблица 3).
2. Тип оборудования (таблица 4).
3. Параметры оборудования (таблица 5).
4. Таблица «Оборудование Параметры оборудования», реализующая связь «многие ко многим» для таблиц «Оборудование» и «Параметры оборудования» (таблица 6).
source
Онтологическое представление O сущности «Оборудование и инструменты» (таблица 2) системы источника будет иметь следующий вид:
Таблица 6. Таблица «Оборудование Параметры оборудования» РБД системы приемника
Таблица 3. Таблица «Оборудование» РБД системы приемника
Название Тип данных Описание
id INTEGER Первичный ключ
name VARCHAR(255) Название
serial_number VARCHAR(255) nullable Серийный номер
inventory_number VARCHAR(255) Инвентарный номер
production_date DATE Дата производства
tool_types_id INTEGER Ссылка на таблицу «Тип оборудования»
Таблица 4. Таблица «Тип оборудования» РБД системы приемника
Название Тип данных Описание
id INTEGER Первичный ключ
name VARCHAR(255) Название
Таблица 5. Таблица «Параметры оборудования» РБД системы приемника
Название Тип данных Описание
id INTEGER Первичный ключ
name VARCHAR(255) Название
Название Тип данных Описание
tool id INTEGER Ссылка на таблицу «Оборудование»
tool_parameter_id INTEGER Ссылка на таблицу «Параметры оборудования»
value VARCHAR(255) Значение параметра
Osource _ ^
C = (Оборудование и инструменты (Об), CHAR,
NUMBER, BLOB, DATE}, P = (t2_ob, t2_ng , t2_nn, t2_r1, t2_r2, t2_r3, t2_p1,
t2_z1, t2_p2, t2_z2, t2_p3, t2_z3, t2_gm, t2_p3, t2_z3, t2_gm, up_dt, up_us, t2_dc, t2_
vid, t2_doc, t2_prim, t2_yyyy} L = (nullable, <length, 2>, <length, 4>, <length, 8>,
<length, 32>, <length, 100>, <length, 200>, <length, 255>, <precision, 5>,
<precision, 6>} RP = (<06, t2_ob, CHAR>, <06, t2_ng, NUMBER>,
<06, t2_nn, NUMBER>, <06, t2_r1, CHAR>, <06, t2_r2, CHAR>, <06, t2_r3,
CHAR>, <06, t2_p1, CHAR>, <06, t2_z1, CHAR>, <06, t2_p2, CHAR>, <06, t2_z2,
CHAR>, <06, t2_p3, CHAR>, <06, t2_z3, CHAR>, <06, t2_gm, CHAR>, <06, up_
dt, DATE>, <06, up_us, CHAR>, <06, t2_dc, BLOB>, <06, t2_vid, CHAR>, <06, t2_
doc, CHAR>, <06, t2_prim, CHAR>, <06, t2_yyyy, CHAR>} Rl = (<t2_ob, <length, 200>>, <t2_ng, <precision,
5>>, <t2_nn, <precision, 6>>, <t2_p1, <length, 2>>, <t2_p1, nullable>, <t2_z1,
<length, 8>>, <t2_z1, nullable>, <t2_p2, <length, 2>>, <t2_p2, nullable>, <t2_z2,
<length, 8>>, <t2_z2, nullable>, <t2_p3, <length, 2>>, <t2_p3, nullable>, <t2_z3,
<length, 8>>, <t2_z3, nullable>, <up_us, <length, 32>>, <t2_vid, <length, 4>>, <t2_
doc, <length, 100>>, <t2_prim, <length, 100>>, <t2_doc, nullable>, <t2_ yyyy, <length, 4>>}
.
Онтологическое представление Qreceiver сущности «Оборудование и инструменты» (таблицы 3, 4, 5, 6) системы приемника будет иметь следующий вид:
O receiver _ ^
C = (Оборудование (Об), Тип оборудования
(ТОб), Параметры оборудования (ПОб), Оборудование Параметры оборудования (06-ПОб), INTEGER, VARCHAR, DATE},
P = (06_id, 06_name, serial_number, inventory_
number, production_date, tool_types_id, T06_id, T06_name, n06_id, n06_name, tool_id,
tool_parameter_id, value} L = (nullable, <length, 255>}
rp = (<06, 06_id, INTEGER>, <06, 06_name, VARCHAR>,
<06, serial_number, VARCHAR>, <06, inventory_
number, VARCHAR>, <06, production_date, DATE>, <06, tool_types_id, INTEGER >,
<T06, T06_id, INTEGER>, <T06, T06_name, VARCHAR>,
<П0б, n06_id, INTEGER>, <П0б, n06_name, VARCHAR>,
<06П0б, tool_id, INTEGER>, <06П0б, tool_ parameter_id, INTEGER>,
<06П0б, value, VARCHAR>} R
L = |<06_name, <length, 255>>, <serial_number, <length, 255>>, <serial_number, nullable>, <inventory_number,
<length, 255>>, <T06_name, <length, 255>>, <n06_name, <length, 255>>, <value, <length, 255>>}
Для полученных онтологических представ-
source receiver
лении O и O процесс формирования интегрирующей модели данных OM1ET'A будет состоять из следующих шагов:
Шаг 1. Выделение общего понятийного аппарата ПрО:
1. Термин «Порядковый номер» системы источника соответствует термину «Первичный ключ» системы приемника.
2. Термин «Примечание» системы источника со-
ответствует термину «Инвентарный номер» системы приемника.
3. Термин «Год производства» системы источника соответствует термину «Дата производства» системы приемника.
Шаг 2. Создание интегрирующей модели данных OMETA
CM1ST'4 = |<Источник, Oracle, <login, password», <Приемник, PostgreSOL, <login, password»}.
Шаг 3. Формирование иерархии классов инте-
у-Л.META
грирующеи модели данных O rc^ta _ {<источник, Оборудование и инструменты^ <Приемник, Оборудование^ <Приемник, Тип оборудования^ <Приемник, Параметры оборудования^
<Приемник, Оборудование Параметры оборудования>}. Шаг 4. Формирование свойств классов интегрирующей модели данных omet'a rmeta = {«Источник, t2_nn>, t2_nn_06_id, <Приемник, 06_id>>, «Источник, t2_ob>, t2_ob_06_name, <Приемник, 06_name>>, «Источник, t2_prim>, t2_prim_inv_ numbrt, <Приемник, inventory_ number>>,
«Источник, t2_yyyy>, t2_yyyy_prod_
date, <Приемник, production_date>>, «Источник, t2_r1>, t2_r1_T06_name, <Приемник, T06_name >>, «Источник, t2_p1>, t2_p1_n06_name, <Приемник, n06_name>>, «Источник, t2_z1>, t2_z1_value, <Приемник, value>>,
«Источник, t2_p2>, t2_p2_n06_name, <Приемник, n06_name>>, «Источник, t2_z2>, t2_z2_value, <Приемник, value>>,
«Источник, t2_p3>, t2_p3_n06_name, <Приемник, n06_name>>, «Источник, t2_z3>, t2_z3_value, <Приемник, value»}.
Шаг 5. Определение аксиом классов и свойств
r\META
и проверка интегрирующеи модели данных O на согласованность
RLMeta = |<t2_ob_06_name, <Приемник, < length, 255>>, <t2_r1_T06_name, <Приемник, < length, 255>>, <t2_p1_n06_name, <Приемник, < length, 255>>, <t2_z1_value, <Приемник, < length, 255>>, <t2_p2_n06_name, <Приемник, < length, 255>>, <t2_z2_value, <Приемник, < length, 255>>, <t2_p3_n06_name, <Приемник, < length, 255>>, <t2_z3_value, <Приемник, < length, 255>>}.
После получения интегрирующей модели данных OMETA запуск машины вывода M позволит проверить логическую целостность и непротиворечивость получившейся онтологии. Для проверки выполнения условий ограничений
tMETA
L требуется разработка соответствующих методов, так как существующие машины вывода не поддерживают данную функциональность.
Таким образом, в результате выполнения данных шагов на основе полученных онтологических представлений Osource и oreceiver моделей данных формируется интегрирующая модель данных OMETA, позволяющая обеспечить полноту и непротиворечивость данных, а также минимизировать дополнительный ввод информации за счет направления потока данных от существующей на предприятии ИС в сторону системы оптимизации ресурсов авиастроительного предприятия.
ЗАКЛЮЧЕНИЕ
В данной статье представлена реализация метода интеграции ИС авиастроительного предприятия с системой оптимизации ресурсов. В результате использования принципов связанных данных и онтологического инжиниринга для каждого ИО интегрируемых ИС выполняется процесс отображения структуры РБД ИС в онтологическое представление модели данных. На основе полученных онтологичеких представлений модели данных ИО интегрируемых ИС, с
помощью предложенной методики, формируется интегрирующую модель данных.
Таким образом, были решены поставленные ранее методологические задачи:
1. Создана интегрирующая модели данных, являющейся основой единого пользовательского интерфейса в системе интеграции.
2. Разработан метод отображения ИО интегрируемых ИС в онтологическое представление модели данных.
3. Предложена методика слияния онтологических представлений модели данных ИО интегрируемых ИС в интегрирующую модель данных.
4. Произведена интеграция метаданных ИО интегрируемых ИС.
5. Решена проблема неоднородности источников данных.
6. Разработан механизм семантической интеграции источников данных.
В качестве направления дальнейших исследований можно выделить следующие задачи:
1. Разработка подхода к автоматическому обмену данными между ИС авиастроительного предприятия и системой оптимизации ресурсов на основе сформированной интегрирующей модели данных.
2. Разработка методов проверки выполнения условий ограничений, так как существующие машины вывода не поддерживают работу с такими объектами.
СПИСОК ЛИТЕРАТУРЫ
1. Интеграция проектных диаграмм и онтологий в
задаче балансировки мощностей авиастроительного предприятия / Н.Г. Ярушкина, Т.В., Негода
B.Н. Афанасьева, М.К. Самохвалов, А.М. Наместников, А.А. Романов, Г.Ю. Гуськов // Автоматизация процессов управления. 2017. № 4. C. 85-93.
2. Когаловский М.Р. Методы интеграции данных в информационных системах // Институт проблем рынка РАН: [сайт]. URL: http://www.ipr-ras.ru/articles/ kogalov10-05.pdf (дата обращения 16.10.2018).
3. Кусов А А Проблемы интеграции корпоративных информационных систем. URL: https://cyberleninka. ru/article/n/problemy-integratsii-korporativnyh-informatsionnyh-sistem (дата обращения 16.10.2018).
4. Морозова О.А. Интеграция корпоративных информационных систем: Учебное пособие. — М.: Финансовый университет, 2014. С. 8-23.
5. Степанов Д.Ю. Способы интеграции данных корпоративных информационных систем // Естественные и технические науки. — М., 2014. С. 207-213.
6. C. Bizer, T. Heath, T. Berners - Lee Linked Data - The Story So Far [Электронный ресурс] // Home - Tom Heath: [сайт]. URL: http://tomheath.com/papers/ bizer-heath-berners-lee-ijswis-linked-data.pdf (дата обращения 15.10.2018).
7. OWL 2 Web Ontology Language Document Overview (Second Edition) // World Wide Web Consortium: [сайт]. URL: https://www.w3.org/TR/owl2-overview/ (дата обращения 15.10.2018).
8. T. Gruber Ontology // Tom Gruber [сайт]. URL: http:// tomgruber.org/writing/ontology-in-encyclopedia-of-dbs.pdf (дата обращения 10.10.2018).
9. A. Poggi, D. Lembo, D. Calvanese, G. De Giacomo, M. Lenzerini, R. Rosati. Linking data to ontologies // Data Semantics, 2008, C.133-173.
10. D. Calvanese, B. Cogrel, S. Komla-Ebri, R. Kontchakov, D. Lanti, M. Rezk, M. Rodriguez-Muro, G. Xiao. Ontop: Answering SPAROL Queries over Relational Databases // Semantic Web journal: [сайт]. URL: http://www.semantic -web-journal.net/system/files/ swj1278.pdf (дата обращения 11.10.2018).
11. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. - СПб.: Питер, 2000,
C.59-98.
INTEGRATION OF INFORMATION SYSTEMS BASED ON ONTOLOGY MERGING FOR THE BALANCING OF INDUSTRIAL PROCESSES
© 2018 N.G. Yarshkina, A.A. Romanov, A.A. Filippov, A.Y, Dolganovskaya, M.S. Grigoricheva
Ulyanovsk State Technical University
This paper presents an approach to data integration based on an integrating model. An ontological data model is created, a data mapping from information systems to an ontological model is maked. An illustrative example is considered.
Keywords: ontology, integration of information systems, data model.
Nadezhda Yarushkina, Doctor of Technics, Professor at the Information Systems Department. E-mail: jng@ulstu.ru Anton Romanov, Candidate of Technics, Associate Professor at the Information Systems Department. E-mail: romanov73@gmail.com
Aleksey Filippov, Candidate of Technics, Associate Professor
at the Information Systems Department.
E-mail: al.al.filippov@gmail.com
Aleksandra Dolganovskaya, Postgraduate Student.
E-mail: adolganovskaya@mail.ru
Mariya Grigoricheva, Postgraduate Student.
E-mail: gms4295@mail.ru
