Применение XML-СУБД в задачах автоматизации бизнеса Текст научной статьи по специальности «Компьютерные и информационные науки»

* X \ о.

где x (t) - задающее воздействие.

Как было описано выше, из-за неточностей восстановления обратного оператора систему целесообразно охватить обратной связью.

В итоге имеем

u(t) = u *(t) + Aut.

Расчетный пример.

В качестве ЛДС было взято ДУ второго порядка x" + Xf + 7 X = 14u.

Модель строилась при условиях S = 200. At = Ат = 0.05 на основе измерений переходной характеристики.

Изучающая добавка Au имела вид Aut = 0.3 (x (t) - x(t-1)).

Рис. 3 - Результаты управления ЛДС из расчетного примера

Литература

1. Цыпкин Я.З Адаптация и обучение в автоматических системах. Москва, Наука, 1968.-400с.

2. Сергеева Н.А., Соколов И.В. О непараметрической идентификации динамических процессов// XV Байкальская международная школа-семинар "Методы оптимизации и их приложения", т.3 Оптимальное управление// Иркутск, РИО ИДСТУ СО РАН, 2011.- с.109-114.

3. Медведев А.В. Элементы теории непараметрических систем управления. Актуальные проблемы информатики, прикладной математики и механики. Новосибирск-Красноярск: Изд. СО РАН, 1996. - 112 с.

4. Медведев А.В. Непараметрические системы адаптации. - Новосибирск: Наука., 1983. - 174 с. УДК 004.4, 005

ПРИМЕНЕНИЕ XML-СУБД В ЗАДАЧАХ АВТОМАТИЗАЦИИ БИЗНЕСА

Ермаков Илья Евгеньевич, преподаватель, Технологический институт им. Н.Н. Поликарпова ФГОУ ВПО «ГУ - УНПК», технический директор, НПО «Тесла», Россия, Орёл, [email protected]

1. Проблемы организации БД при автоматизации сложных предметных областей

При решении интересных задач автоматизации объекты предметной области часто с трудом отображаются в плоскую табличную структуру. Основными проблемами является,

57

во-первых, сложная и неоднородная структура признаков таких объектов, во-вторых, изменения и уточнения такой структуры в процессе использования системы. Реляционное проектирование решает первую проблему либо с использованием гигантских таблиц, либо с введением огромного их количества. Вторая проблема решается, как правило, неудовлетворительно. Единственная действительно адаптивная организация реляционной БД предполагает её «вырождение» до представления отдельной записью каждого атрибута каждого объекта — т.е. наличия единой таблицы «Атрибуты» и таблиц метаинформации о типах объектов. Однако при таком подходе теряется продуктивность SQL-запросов и вообще смысл использования реляционной СУБД — целесообразнее применить СУБД из популярного сегодня класса NOSQL, например, типа «ключ-значение» (Berkeley DB, Apache Cassandra и др.) Однако надстраивать механизмы запросов к данным придётся самостоятельно, а это в сочетании со сложностью решаемой прикладной задачи может создать серьёзные риски для успешного завершения проекта автоматизации.

2. Подход с использованием XML-СУБД

Одним из достаточно преемственных по отношению к реляционному подходу и SQL, но в то же время обладающим преимуществами объектно-ориентированных «течений», является применение прирождённой (native) XML-СУБД и языка XQuery. Анализ XML-технологий и их связи с объектно-ориентированным подходом был нами представлен в [1].

Нами (НПО «Тесла») XML-подход к организации БД используется в проекте автоматизации торгово-сервисного предприятия (система документооборота и SCM). В качестве СУБД используется СУБД «Седна» [2]. Одним из принципиальных решений является разработка серверной части проекта полностью на XQuery. XQuery привлекателен своей интеграцией с БД и с XML-моделью, при этом, в отличие от «любительских» сценарных языков (PHP, Python и проч.), он является надёжным, модульным языком со статической системой типов (которая основана на формальной семантике).

Общее впечатление от использования XML-подхода — двойственное. Проявились некоторые проблемы, которые не были очевидны изначально. XML-технологии несут в себе избыточность и особенности, связанные с происхождением XML (это и язык разметки, и формат данных). Очевидно, что те же качества, ради которых выбирается XML-СУБД, могут быть обеспечены более прямым и элегантным образом; однако сопоставимой альтернативы (если рассматривать в аспекте не только модели данных — где десятилетиями известен, например, зарекомендовавший себя MUMPS/Cache-подход, — но и качеств языка запросов) нам пока не известно. В идеальном случае хотелось бы иметь меньше «шероховатостей», но в реальности для нашего случая сложной предметной области мы оцениваем сокращение трудоёмкости более чем вдвое, в сравнении с применением в автоматизированной системе традиционной реляционной БД.

3. Проблемы реализации процедурной логики на XQuery

Стандартный XQuery является чистым функциональным языком, без побочных эффектов по отношению к хранимым данным. Используя хранимые модули с функциями XQuery, можно продуктивно и надёжно реализовывать сколь угодно сложные алгоритмы обработки XML-данных, но невозможно осуществить обновление БД. Это является первым огорчительным препятствием, с которым сталкивается разработчик, у которого возникло естественное желание реализовывать серверные компоненты системы полностью на XQuery.

Очевидным решением представляется применение триггеров и событийной архитектуры системы (введение потоков сообщений между компонентами, реализованными с использованием триггеров). Но непреодолимым препятствием к такому решению для нас стала невозможность импорта в триггерах СУБД «Седна» хранимых модулей и обращения к их функциям. Разработчики СУБД утверждают, что такая возможность вряд ли появится в дальнейшем, потому что имеются серьёзные технические проблемы с её реализацией (связанные с введённой оптимизацией механизмов триггеров). Таким образом, применение триггеров в СУБД «Седна» ограничено сферой контроля целостности данных и другими

58

простейшими задачами. К сожалению, разработчики XML-инструментов до сих пор недооценивают потенциал XQuery как полноценного языка программирования — их системы оказываются не готовы к такому его использованию.

4. Интерпретатор XQProc как средство реализации процедурной логики на XQuery

Для решения проблемы с процедурной логикой мы разработали специальный подход — формат хранения процедур в виде обычных XQuery-фунций и интерпретатор, обеспечивающий их исполнение. Интерпретатор является посредником между клиентскими приложениями, обращающимися к серверу по HTTP, и СУБД «Седна», в которой в виде хранимых модулей находится вся серверная логика системы. Формат и интерпретатор XQProc являются очень простыми.

Идея XQProc заключается в том, что функция хранимого модуля возвращает своим результатом указания интерпретатору о дальнейших действиях. В частности, такими действиями могут быть запросы на обновление данных. Интерпретатор, в соответствии с возвращёнными указаниями, выполняет необходимые запросы к СУБД.

Функция, предназначенная для вызова через XQProc, получает параметры и возвращает результат в виде XML-элемента. Результат имеет специальную структуру.

Приведём пример, показывающий, как выглядит XQProc-процедура:

declare function s:Update Card($elem as element()) { let

$id as xs:integer* := cr:Split Id(xs:string($elem/@id)), $card id as xs:string? := xs:string($id[2]),

$subsys as xs:string? := cr:Subsys Name($id[1]),

$card as element()? := cr:Card By Id($id)

return

if (name($card) eq name($elem/*[1])) then {

<xqp>

<xqp upd>

update replace

$card as element() in

collection("Card Sys")//cards/{$subsys}/{name($card)}/{name($card)}[@id eq "{$card_id}"]

with {

element {name($card)} {

attribute id {$card id}, $elem/*[1]/*

}

}

</xqp_upd>

<xqp_call>Card_Server.Update_Representation <id>{xs:string($elem/@id)}</id></xqp call>

</xqp>

}

else

};

<xqp>

<xqp res><error /></xqp res>

</xqp>

Как можно видеть, функция возвращает интерпретатору элемент <xqp>. Элемент содержит запрос на обновление — секцию <xqp_upd>, и указание вызвать XQProc-процедуру, хранимую в функции Update_Representation модуля Card_Server.

Выводы

1. Подход с применением XML-СУБД является пригодным для применения в сфере автоматизации бизнеса и позволяет ощутимо уменьшить трудоёмкость разработки и облегчить модификацию системы в тех случаях, когда применение реляционной модели имеет сложности в силу особенностей предметной области и при этом

59

применение объектно-ориентированных СУБД представляется чрезмерно «нетрадиционным» и рискованным.

2. Одной из наиболее сильных сторон XML-подхода является возможность использования языка XQuery, в том числе для полной разработки серверной части автоматизированной системы.

3. В силу недооценки разработчиками XML-СУБД перспектив полной разработки на XQuery, имеется ряд технических проблем для такой разработки, однако они являются преодолимыми.

4. Ценные качества XML-подхода сочетаются с рядом неприятных особенностей, связанных с происхождением XML (как одновременно языка разметки и формата данных).

5. Перспективным решением представляется проектирование СУБД на основе опыта применения XML-СУБД и XQuery, но без избыточного наследия XML.

Литература

1. Ермаков, И. Е. XML-СУБД как возможная основа для объектных технологий ИС. Технология MULTYF / И.Е. Ермаков // Объектные системы — 2011: Материалы I Международной научно-практической конференции. Россия, Ростов-на-Дону, 10-12 мая 2011 г — Ростов-на-Дону, 2010. С. 130-135.

2. Сайт XML-СУБД «Седна» (ИСП РАН) [Электронный ресурс] Режим доступа: http://sedna.org/ УДК 007.52

ИССЛЕДОВАНИЕ СИСТЕМЫ ДЕЦЕНТРАЛИЗОВАННОГО УПРАВЛЕНИЯ ГРУППОЙ РОБОТОВ НА ОСНОВЕ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ1

Галиуллин Венер Юнирович, аспирант, Уфимская Г осударственная Академия Экономики и Сервиса, Россия, Уфа, Vener.Galiullin@,gmail.com

Введение

На начальном этапе проектирования системы управления децентрализованной группой роботов является целесообразным применение имитационного моделирования для определения: влияния начальных параметров, как объектов так и системы, путей улучшения метода[1, 2].

Для определения эффективности исследования системы децентрализованного управления группой роботов на основе имитационного моделирования было проведено имитационное моделирование системы децентрализованного управления группой роботов на основе использования локальных стационарных хранителей информации (СХИ).

1. Описание метода децентрализованного управления группой роботов на основе использования локальных СХИ

Метод основан на бионике, а именно - групповом поведении колонии муравьев, их свойстве маркировки пути феромонами [3, 4], для передачи другим муравьям колонии информации о направления к определенным целям и уровню исследованности территории. Для маркировки пути роботами группы было решено использовать локальные стационарные хранители информации, к примеру, радиомаяки с определенной информацией об исследованной местности, что позволяет остальным членам группы ориентироваться по ним.

Примерами хранимой информации может быть:

• информация об исследовании данной области;

• информация о проходимости местности;

1 Статья рекомендована к опубликованию в журнале "Автоматизация в промышленности"

60