CC BY
26
1. Штанюк А.А. Перспективы развития объектно-ориентированных операционных систем // Объектные системы. 2013 №7(7), с.29-30.
2. The JX Operating System [Электронный ресурс.] - Режим доступа: http://www4.cs.fau.de/Projects/JX/publications/jx-usenix.pdf (дата обращения 29.11.2015).
3. JX: The fast and flexible JavaOS [Электронный ресурс.] - Режим доступа: http://www4.cs.fau.de/Projects/JX/ (дата обращения 29.11.2015).
4. P.J. Muller. Active Object System. Design and Multiprocessor Implementation. — ETH Zurich, 2002., Diss. ETH № 14755
5. Канторовы системы [Электронный ресурс.] - Режим доступа: http://www.cantorsys.com/2015/05/Theory.html (дата обращения 30.11.2015).
УДК 004.4'236
ГИБРИДНЫЕ ОБЛАЧНЫЕ ТЕХНОЛОГИИ НА ОСНОВЕ РЕЛЯЦИОННОЙ И
ОБЪЕКТНОЙ БАЗ ДАННЫХ3
Микляев Иван Александрович, к.ф.-м. н., доцент, Институт судостроения и морской арктической техники (Севмашвтуз) Северного (Арктического) федерального университета имени М. В.
Ломоносова, Россия, Северодвинск, [email protected] Жирнова Марина Анатольевна, студентка, Институт судостроения и морской арктической техники
(Севмашвтуз) Северного (Арктического) федерального университета имени М. В. Ломоносова, Россия, Северодвинск, [email protected]
Информационное общество вышло на новый виток развития, которое характеризуется началом активного использования облачных технологий, позволяющих эффективно работать с информационными ресурсами, используя различные аппаратно-программные средства независимо от территориального присутствия пользователя.
На предприятии по производству сварочного оборудования используется гибридная информационная система, основанная на обмене данными между информационными системами частного и публичного облаков.
Так как на публичном и частном облаках используются разные структуры данных: реляционные базы данных и матричная универсальная объектно-реляционная база данных (МУОРБД) [2], то требуется нестандартный подход синхронизации баз данных. Поэтому используются собственное программное решение для связи двух частей информационной системы предприятия.
Из определения частного облака [1] следует, что это инфраструктура, предназначенная для использования одной организацией, включающей несколько потребителей, в данном случае потребителями являются подразделения Бухгалтерии, Управления, Производства и Конструкторский отдел. Частное облако находиться в собственности предприятия по производству сварочного оборудования «Агни» и физически существует внутри юрисдикции владельца. На платформе частного облака были разработаны собственными силами предприятия следующие информационные системы, находящиеся в тесной взаимосвязи:
• ERP-система, которая организована для управления данными о заказах, продукции, назначения цены, управления складскими запасами, выполнения технологических операций, ведения табеля и т.д.;
• система электронного документооборота, используется для конструкторской документации;
3 Статья рекомендована к опубликованию в журнале "Прикладная информатика"
58
• справочная система. Динамическая система, используемая для управления информацией о справках и руководствах пользователя в новых модулях информационных систем предприятия;
• система регистрации, изготовления и тестирования изделия используется при конечной операции в изготовлении изделий Агни и присвоение им уникального штрих-кода, после чего существует возможность отслеживать изделие, в частности, устанавливать причины брака.
Система видеонаблюдения Trassir от DSSL, введена на предприятии для дальнейшей интеграции её с модулем контроля рабочего времени в ERP-системе.
Публичное же облако предоставляет услуги хранения файлов и использования вебсервера Apache, СУБД MySQL. На его платформе были построены Информационные системы: МУОРБД-сайт [3] и старый сайт.
Для обмена информацией между публичным и частным облаком используется две программы - диспетчеризации с набором сервисов необходимых функций (рис. 1).
Регистрация изготовления и тестирование изделия
MS SQL
Принтер этикеток
- Справочная система СЭД-система
MS SQL MS SQL —
Рис. 1 - Общая схема гибридной технологии на предприятии по производству сварочного
оборудования
Так как на публичном и частном облаках используются разные структуры данных: реляционная БД и объектная МУОРБД, то требуется нестандартный подход синхронизации баз данных. Поэтому используются собственное программное решение для связи двух частей информационной системы предприятия.
Система обмена данными организована в следующем виде.
Загрузка и обновление списка продукции и её стоимости осуществляется с помощью ERP-системы и сервиса загрузки новой информации через FTP и HTTP протоколы.
С помощью модуля информационной системы происходит подготовка информации о выпускаемой продукции, предназначенной для продажи.
Далее осуществляется отправка подготовленных файлов на хостинг по FTP. Далее запускается сервис загрузки информации в МУОРБД-сайт через компонент «Браузер» в модуле.
Рассмотрим сервис загрузки новой информации на МУОРБД-сайт подробнее. Для этого проанализируем две структуры: МУОРБД и реляционную БД.
Физическая схема части реляционной БД ЕЯР-системы, хранящей информацию о Товарно-Материальной Ценности (ТМЦ), представлена на рисунке 2.
Для организации правильного представления информации в объектной базе данных МУОРБД необходимо изменить характер хранения информации, при этом учесть связи между таблицами в реляционной базе данных.
Товарно-материальная ценность
Код ТМЦ integer
Наименование varchar
Цена float
Описание text
Код ЕИ integer
Add field
Единица Измерения в
P Код ЕИ integer
Наименование varchar
Краткое обозначение varchar
В Add field
Состав ТМЦ
Р Код ТМЦ integer i7 5
Код с одержащейс я ТМ Ц integer
Количество входящей ТМЦ float
В Add field
Ракурс
Код ракурса integer
Наименование varchar
Код род ител ьс кого раку рс а integer
Код ТМЦ integer
S Add field
Рис. 2 - Физическая схема части реляционной БД ERP-системы, хранящей информацию о ТМЦ
Для этого сервис загрузки новой информации на МУОРБД-сайт принимает определенной структуры входной файл. Данная структура представляет собой массив данных с указанием имени таблицы в реляционной БД ERP-системы (окончание Var) и имени сущности в МУОБД, а также полей, между которыми происходит связь. Primary key обозначен PK, а Foreign key - FK. Ниже приводится пример передачи данных правил взаимосвязи:
$ SESSION[ 'QAR' ][0][' NameTable"]="ТМЦ";
$ SESSION[ 'QAR' ][0][' NameTableVarM]=MDBGdsTreeM;
$ SESSION[ 'QAR' ][0][' PK"]="";
$ SESSION[ 'QAR' ][0][' PKVar"]= = "Код ракурса";
$ SESSION[ 'QAR' ][0][' FK"]="";
$ SESSION[ 'QAR' ][0][' FKVar"] 1]="Относиться к";
$ SESSION[ 'QAR' ][0][' TableNameFK"][1]="Ракурс";
$ SESSION[ 'QAR' ][0][' TableNameFKVar"][1]="Код ракурса";
$ SESSION[ 'QAR' ][0][' FKVar"] 2]="idSGDS";
$ SESSION[ 'QAR' ][0][' TableNameFK"][2]="TM^';
$ SESSION[ 'QAR' ] [0] [' TableNameFKVar"][2]="Код ракурса";
$ SESSION[ 'QAR' ][0][' PartNumber"]="1";
$ SESSION[ 'QAR' ][0][' FSprVar ][0]="Максимальная сила постоянного тока";
$ SESSION[ 'QAR' ][0][' FSprVar ][1]="Максимальная сила переменного тока";
$ SESSION[ 'QAR' ][0][' FSprVar ][2]="Количество осей";
$ SESSION[ 'QAR' ][0][' FSprVar ][3]="Вид горелки";
$ SESSION[ 'QAR' ][0][' FSprVar ][4]="Длинная вилка";
$ SESSION[ 'QAR' ][0][' FSprVar ][5]="Длина шлейфа";
$ SESSION[ 'QAR' ][0][' FSprVar ][6]="Охлаждение";
$ SESSION[ 'QAR' ][0][' FSprVar ][7]="Исполнение изоляции";
$ SESSION[ 'QAR' ][0][' FSprVar ][8]="Тип сварочного провода";
$ SESSION[ 'QAR' ][0][' FSprVar ] [9]="Тип присоединительного элемента сварочного провода"
$ SESSION[ 'QAR' ][0][' FSprVar ] [10]="Краник газа";
$ SESSION[ 'QAR' ][0][' FSprVar ][11]="Кнопка управления";
$ SESSION[ 'QAR' ][0][' FSprVar ][12]="Тип присоединительного элемента налива-слива";
$ SESSION[ 'QAR' ][0][' FSprVar ][13]="Тип присоединительного элемента газовой магистрали
Далее прив еден пример передачи данных одного из экземпляров объекта ТМЦ:
$ SESSION[ 'QAR' ][511] ["Вид горелки"]="TIG";
$ SESSION[ 'QAR' ][511] ["Количество осей"]="2";
$ SESSION[ "QAR" [511] ["Максимальная сила постоянного тока"]="315 А";
$ SESSION[ "QAR" [511] ["Охлаждение "]="Жидкостное";
$ SESSION[ "QAR" [511] ["Тип присоединительного элемента газовой магистрали"]= 'НгМ14
$ SESSION[ "QAR" [511] ["Тип присоединительного элемента сварочного провода"]= 'НгМ14
$ SESSION[ "QAR" [511] ["Тип сварочного провода"]="В";
$ SESSION[ "QAR" [511] ["Тип соединительного элемента цепи управления"]="Шр16"
$ SESSION[ "QAR" [511] ["Длина шлейфа"]="20";
$ SESSION[ "QAR" [511] ["Краник газа"]="Есть";
$ SESSION[ "QAR" [511] ["idDBTree "] = "5";
$ SESSION[ "QAR" [511] ["Код ракурса"]="4 7 6 9";
$ SESSION[ "QAR" [511] ["Относиться к"]="4317";
$ SESSION[ "QAR" [511] ["idNext"] =" 4770";
$ SESSION[ "QAR" [511] ["idPrior" ]= "4768";
$ SESSION[ "QAR" [511] ["Наименование"]="Агни-07М Шл.20.В.НгМ14.М14.Шр16 (2273 ";
$ SESSION[ "QAR" [511] ["isFolder "] = "0";
$ SESSION[ "QAR" [511] ["Код ТМЦ" ]= "2273";
$ SESSION[ "QAR" [511] ["UNIT GDS "] ="Шт";
$ SESSION[ "QAR" [511] ["Цена"]=" 12036";
$ SESSION[ "QAR" [511] ["idSGDS"] [1 ]="4870";
$ SESSION[ "QAR" [511] ["NUMBER"] [1 ]="1";
$ SESSION[ "QAR" [511] ["UNIT"][1 ]= "Шт";
$ SESSION[ "QAR" [511] ["idSGDS"] [2 ]="4903";
$ SESSION[ "QAR" [511] ["NUMBER"] [2 ]="1";
$ SESSION[ "QAR" [511] ["UNIT"][2 ]= "Шт";
$ SESSION[ "QAR" [511] ["idSGDS"] [3 ]="4984";
$ SESSION[ "QAR" [511] ["NUMBER"] [3 ]="1";
$ SESSION[ "QAR" [511] ["UNIT"][3 ]= "Шт";
$ SESSION[ "QAR" [511] ["idSGDS"] [4 ]="8758";
$ SESSION[ "QAR" [511] ["NUMBER"] [4 ]="1";
$ SESSION[ "QAR" [511] ["UNIT"][4 ]= "Шт";
Далее в МУОРБД реляционная структура превращается в объектную, убедиться в этом можно после ознакомления с организацией хранения состава ТМЦ в конструкторе МУОРБД-сайта (Рисунок 3). Вся информация по ТМЦ представлена в объектно-древовидной структуре с указанием характеристики и её значения.
1 1
1 1
41 максимальная сила постоянного 180 А (при ПВ=60( а)
тока 111
5 1 Эхлаждение|Газовое
б 1 Тнп присоединительного элемента HrGl 4
сварочного провода
1 1 Тнп сварочного провода||Р||
Я 1 Шр1б
шравления
9 1 Длина шлейф ю 1
10 к1Г>ВТгее||5|||
И Код ракурса |
-|1- 1 (Относиться к||4314|_Д И У|
10||Ракурс |4 ¡14 4192. 41S9 Горелки TIG Горелки TIG с газовым охлаждением Агнн-1б|||
13 itDJextl 6719
14 idPrior 82331
15 Нанменованн е Агнн-16Му Шл.Ю .V.P.HrGl 4.Шр16 <3276) II
16 i$Folder||01
17 Код тмц||зз! 7б|||
1S UNIT_GDSj|L [1т|
19 Ценя||б9621
- :о 1 [idSGDS 4 S С 9
ill
41
3 UNIT [llli
4 TM 4856 485 Сменные н апасныечастн Комплекты ЗИП ЗИП 1 [для неохлаждаемых) [1 58) 158 31 III 1
применяется для неохлаждэемых горелок "Агнн-0 3/07": Агнн -16".
Рис. 3 - Конструктор МУОРБД-сайта
В процессе использования реляционной базы данных при появлении новых задач необходимо изменять изначальную структуру базы данных. Изменение структуры базы данных очень трудоемкая и дорогостоящая операция, поэтому, вместо перепроектирования базы данных для правильного отображения новых свойств объектов предметной области, создаются дополнительные таблицы для решения текущих проблем. В МУОРБД достаточно добавить новые характеристики, а не создавать новые таблицы, как в реляционной базе данных.
Стоит отметить одну очень важную особенность МУОРБД. Пользователи системы на основе реляционной базы (рисунок 2) данных «видят» базу данных только через информационную систему.
МУОРБ-сайт не требует дополнительной интерпретации информации, что позволяет работать с информацией напрямую используя Конструктор МУОРД-сайта(рисунок 3).
Это приводит к тому, что любые изменения, сделанные в Конструкторе МУОРД-сайта, становятся доступны пользователям (рисунок 4) .
Гшршткшптп 5ез шлейфа, для сямосго.тгельэого подключения. ¡Состав
ЗИП-1Л (для неохляждаеиых) £1219)
ЗИП-1 1 применяется для шпослаждаеных горелок "_Агки-03М" и "_Агки-1!?Ы" Состав
Применение Техн^араитернстнкн
Применение Технхарактеристики
Кслпачак НЗО М8х1 (38) X И Шт
Сопло (кер) ¿=12/47М18x1,5 КС (2726) X ■ Шт 06,2 руб
Цанга 505 ¿=3иы(2) X ■ Шт 062: рус
Цанга 505 ¿=4ыы (3) X Щ Шт
Горьтка-ОЗМ (400) * ■ Шг= 213 5,8 руб
Сопло (кер) ¿=9/43М13х1,5 КС (2725) * ■ Шт
Паспорт (03М, 03/07М, 12М, 1Ш) (2290) х Щ Шг= 23,6 руб
Рис. 4 - МУОРБД-сайт
Полученные результаты позволяют судить о возможности равноправно и безболезненно совмещать реляционные и объектно-ориентированные структуры данных в одном информационном пространстве, причём разделяя их поле применимости в зависимости от эффективности их использования.
Литература
1. Облачные вычисления [Электронный ресурс] - Режим доступа: ru.wikipedia.org /wiki/Облачные_вычисления (дата обращения: 25.11.2015).
2. Микляев И.А. Р Матричная универсальная объектно-реляционная база данных на реляционной платформе: монография/ Сев.(Арктич.) федер. Ун-т им. М.В. Ломоносова. -Архангельск: ИД САФУ, 2014. - 226 с.
3. Микляев И.А., Юрецкий А. П. Функциональная схема встроенного объектно-ориентированного интерактивного механизма конструирования страниц сайта на основе
матричной универсальной объектно-реляционной базы данных// Объектные системы - 2014: материалы VIII Международной научно-практической конференции (Ростов-на- Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. - С. 26-32
УДК 614.849
ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ В ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ СТРУКТУРЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ПОЖАРНЫМИ
РИСКАМИ
Хабибулин Ренат Шамильевич, канд. техн. наук, доцент, начальник кафедры информационных технологий, Академия Государственной противопожарной службы МЧС России,
[email protected] Гудин Сергей Витальевич, адъюнкт, Академия Государственной противопожарной службы МЧС
России, [email protected]
В рамках исследовательского проекта по созданию современных информационных систем управления пожарными рисками на территории производственных объектов предлагается использование объектно-ориентированного подхода (ООП) [1-4].
В результате анализа современных информационных систем по оценке пожарных рисков на производственных объектах (РУСЬ, ТОКСИ+Risk, Фогард, RISKCURVES, MERIT, Safeti, Phast) было выявлено, что они не обладают возможностью внедрения новых методов определения значений пожарных рисков, а также не включают в себя алгоритмы для их оптимизации. Таким образом, в настоящее время не существует программной платформы, позволяющей проводить оценку новых методов и алгоритмов, разрабатываемых учеными или специалистами.
В то же время, в связи с большим количеством исходных и промежуточных данных, необходимых для расчета пожарных рисков на территории производственных объектов, а также различных комбинаций возможных мероприятий, направленных на снижение этих рисков, эксперты и специалисты в области пожарной безопасности сталкиваются с проблемами их эффективного применения. В связи с этим актуальным является создание систем поддержки принятия решений (СППР) с использованием алгоритмов оптимизации и интеллектуальных алгоритмов, которые в настоящее время не реализованы в представленных системах.
«FireRisks» (www.firerisks.ru) - разрабатываемая web-ориентированная информационная система, предназначенная для проведения исследований в области пожарной безопасности производственных объектов, в частности, изучения алгоритмов управления пожарными рисками на территории производственных объектов различных отраслей промышленности. Основной её функцией в настоящее время является определение расчетных величин пожарных рисков, а также моделирования зон рисков с использованием интернет-картографических модулей (GoogleMaps). Структура данного программного модуля представлена на Рисунке 1.
Процедуру оценки пожарных рисков можно описать следующим образом:
1. Пользователь при помощи персонального компьютера заходит на специальный вебсайт, содержащий программу;
2. вводит информацию об объектах, содержащихся на территории нефтеперерабатывающего объекта, в блок ввода данных;
3. строит или загружает из базы сценарии развития возможных пожароопасных ситуаций для каждого объекта, присутствующего на территории;
