WWW.KONF.X-PDF.RU
БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Авторефераты, диссертации, конференции
 

Pages:   || 2 | 3 | 4 | 5 |

«МОДЕЛЬНЫЕ ПРЕДСТАВЛЕНИЯ И АЛГОРИТМЫ ПРОВЕРКИ ПРАВИЛ В АКТИВНЫХ БАЗАХ ДАННЫХ ...»

-- [ Страница 1 ] --

ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

На правах рукописи

ЗУДОВ АНТОН БОРИСОВИЧ

МОДЕЛЬНЫЕ ПРЕДСТАВЛЕНИЯ

И АЛГОРИТМЫ ПРОВЕРКИ ПРАВИЛ

В АКТИВНЫХ БАЗАХ ДАННЫХ

Специальность:

05.13.17 – Теоретические основы информатики



Диссертация на соискание ученой степени кандидата технических наук

Научный руководитель:

доктор технических наук профессор Макарычев П.П.

ПЕНЗА 2015

СОДЕРЖАНИЕ

Введение

1 АНАЛИЗ МОДЕЛЕЙ, МЕТОДОВ И СРЕДСТВ ПОСТРОЕНИЯ АКТИВНЫХ БАЗ

ДАННЫХ

1.1 Анализ современных технологий обработки событий в базах данных.............10

1.2 Обработка событий на основе технологии активных баз данных

1.3 Модельные представления активных правил

1.4 Оценивание области значений активных правил путём синтеза конечного автомата по поведению

Выводы

2 МОДЕЛИ И АЛГОРИТМЫ АНАЛИЗА ВЗАИМОДЕЙСТВИЯ АКТИВНЫХ

ПРАВИЛ

2.1 Конфликты взаимодействия активных правил

2.2 Свойства набора активных правил

2.3 Модельное представление взаимодействия активных правил на основе графа экземпляров событий

2.4 Алгоритм интервального оценивания области значений активных правил с числовыми параметрами

2.5 Оценивание области значений активных правил со строковыми параметрами путём синтеза конечного автомата по регулярным выражениям

2.6 Модельное представление потенциальных взаимодействий активных правил в виде графа областей значений

Выводы

3 МЕТОДИКА ПОСТРОЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ АКТИВНОЙ БАЗОЙ

ДАННЫХ

3.1 Компоненты системы управления активными базами данных

3.2 Подсистема динамической проверки и исполнения

3.3 Ведение репозитория активных правил

3.4 Подсистема статической проверки в составе программных средств разработки активных правил

Выводы

4 РАЗРАБОТКА И ЭКСПЕРИМЕНТАЛЬНАЯ ОЦЕНКА ЭФФЕКТИВНОСТИ

СИСТЕМЫ УПРАВЛЕНИЯ АКТИВНОЙ БАЗОЙ ДАННЫХ ДЛЯ ЭЛЕКТРОННОЙ

КАРТЫ ГОРОДА

4.1 Обработка событий в электронной карте города

4.2 Особенности архитектуры и программной реализации системы управления активной базой данных

4.3 Реализация обработки событий с помощью активных правил

4.4 Экспериментальная оценка эффективности на основе эксплуатации системы управления активными базами данных

Выводы

ОСНОВНЫЕ РЕЗУЛЬТАТЫ РАБОТЫ

СЛОВАРЬ ТЕРМИНОВ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ А. РЕЗУЛЬТАТЫ МОДЕЛИРОВАНИЯ ПОТЕНЦИАЛЬНЫХ

ВЗАИМОДЕЙСТВИЙ РЕКУРСИВНОГО АКТИВНОГО ПРАВИЛА

ПРИЛОЖЕНИЕ Б. ОПИСАНИЕ ИНТЕРФЕЙСА И ФУНКЦИОНАЛЬНОСТИ

КЛИЕНТСКОГО ПРИЛОЖЕНИЯ РАЗРАБОТКИ АКТИВНЫХ ПРАВИЛ.........174

ПРИЛОЖЕНИЕ В. ПЕРЕЧЕНЬ АКТИВНЫХ ПРАВИЛ ДЛЯ ОБРАБОТКИ

СОБЫТИЙ В ЭЛЕКТРОННОЙ КАРТЕ ГОРОДА

ПРИЛОЖЕНИЕ Г. ОПИСАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ МУП

«ОГСАГиТИ»

ПРИЛОЖЕНИЕ Д. АКТЫ О ВНЕДРЕНИИ РЕЗУЛЬТАТОВ ДИССЕРТАЦИОННОЙ

РАБОТЫ

ВВЕДЕНИЕ

Актуальность темы. Обработка событий, возникающих в базах данных и соответствующих по уровню абстракции терминам предметной области, требует применения событийно-ориентированной системы, по отношению к которой база данных является объектом мониторинга. В качестве средств построения систем обработки событий используются различные программные продукты и технологии, выбор которых зависит от специфики моделируемых бизнес-процессов, так как на сегодняшний день не существует единого стандарта обработки событий базы данных (БД).

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





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

Концепция активных баз данных (АБД) учитывает возможность наличия промежуточных элементарных событий, что означает принципиальную возможность полной проверки изменений, вносимых пользователями в логику обработки событий. В качестве обработчиков событий в активных БД используются активные правила, хранимые наравне с традиционным наполнением БД и обеспечивающие реагирование на события без необходимости в командах от внешнего приложения. Функциональность системы управления активной базой данных (СУАБД) включает проверку активных правил, позволяющую, в том числе, выявлять конфликты правил, связанные с промежуточными элементарными событиями.

Расширение интенсиональной части базы данных в соответствии с концепцией АБД отражено в нотациях SQL3, О++ и таких специализированных средствах обработки событий современных СУБД, как правила PostgreSQL и автономные транзакции Oracle.

Существенный вклад в развитие концепции активных баз данных, в частности в разработку моделей представления обработчиков событий и методов анализа взаимодействий, внесли: J. Widom, A. Aiken, E. Baralis, С.В. Шибанов, С.Д.

Кузнецов, А. Егоров. Классификацию моделей, функций и прототипов СУАБД провели N.W. Paton и O. Diaz. Математические модели взаимодействия активных правил были разработаны J. Bailey, A. Couchot. Важные исследования, касающиеся рекурсии активных правил, содержащие параметры только вещественного типа, провели Timothy J. Hickey, Saumya K. Debray.

Однако вне их внимания остались правила, в которых возможен рекурсивный запуск через промежуточное событие. В связи с этим, существует проблема проверки активных правил в процессе исполнения и проектирования. Первый аспект проблемы связан с отсутствием удовлетворительных способов безопасного выполнения рекурсивных активных правил. Второй аспект заключается в отсутствии формального описания критериев проверки активных правил и способов выявления потенциальных сценариев взаимодействия. Третий аспект относится к составу компонентов, необходимых для полной реализации функциональности систем обработки событий БД.

Цель диссертационной работы – теоретическое обоснование и исследование модельных представлений и алгоритмов проверки правил в активных базах данных, обеспечивающих расширение функциональных возможностей интенсиональной части базы данных, сокращение времени и количества ошибок при вводе данных.

Задачи исследования:

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

2. Разработка модельных представлений статической и динамической проверки активных правил базы данных;

3. Разработка математических, прагматических моделей функционирования и взаимодействия компонент системы управления активными базами данных;

4. Разработка системы управления активными базами данных и экспериментальная оценка эффективности применения предложенных моделей.

Объектом исследования является система управления активными базами данных.

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

Соответствие паспорту научной специальности. Область исследования соответствует п. 3 «Исследование методов и разработка средств кодирования информации в виде данных. Принципы создания языков описания данных, языков манипулирования данными, языков запросов. Разработка и исследование моделей данных и новых принципов их проектирования» и п. 4 «Исследование и разработка средств представления знаний. Принципы создания языков представления знаний, в том числе для плохо структурированных предметных областей и слабоструктурированных задач; разработка интегрированных средств преставления знаний, средств представления знаний, отражающих динамику процессов, концептуальных и семиотических моделей предметных областей».

Методы исследования основаны на теоретических положениях интервального анализа, теории графов, конечных автоматов, механизма регулярных выражений и алгебры событий.

Научная новизна работы:

1. Разработано модельное представление динамической проверки активных правил в виде дерева, отличающееся заданием экземпляров событий вершинами графа, а активных правил – дугами, что позволяет снизить время ввода данных на 15%.

2. Разработан алгоритм интервального оценивания областей значений активных правил, отличающийся использованием полученных ранее оценок в качестве критерия интервального метода дробления бруса, что позволяет расширить функциональные возможности интенсиональной части базы данных при обработке событий с вещественными атрибутами.

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

4. Предложено модельное представление статической проверки активных правил в виде деревьев, отличающееся заданием областей значений вершинами, а фактов инициируемости правил – дугами графа, что позволяет снизить количество ошибок при вводе данных об активных правилах приблизительно в 8 раз.

5. Предложена методика построения системы управления активными базами данных, отличающаяся разделением процесса исполнения правил на стадию динамической проверки и стадию записи изменений в базу данных и вынесением функциональности по статической проверке в клиентское приложение, что позволяет моделировать бизнес-процессы, в которых возникают промежуточные элементарные события.

Результаты исследования Практическая значимость исследований.

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

Достоверность и обоснованность научных и практических результатов работы подтверждается: использованием апробированного математического аппарата; экспериментальными данными тестовой эксплуатации разработанных программных средств; практическим применением полученных результатов, указанных в актах о внедрении; апробацией на научно-технических конференциях.

Основные результаты, выносимые на защиту:

1. Модельное представление взаимодействующих активных правил в виде графа экземпляров событий и алгоритмы динамической проверки активных правил для выявления фактических и потенциальных шаблонов взаимодействия.

2. Алгоритм оценивания областей значений в виде вещественных интервалов для выявления возможности опосредованного инициирования активных правил с вещественными параметрами.

3. Модельное представление областей значений в виде конечных автоматов для выявления возможности опосредованного инициирования активных правил со строковыми параметрами.

4. Модельное представление и алгоритм статической проверки активных правил для проверки терминальности и конфлюентности.

5. Методика построения системы управления активными базами данных с поддержкой обработки промежуточных элементарных событий базы данных.

Реализация и внедрение результатов работы. Результаты диссертационного исследования использованы при разработке программных средств управления активными правилами в составе информационной системы электронной карты города Пензы, используемой в МУП «ОГСАГиТИ» и в Администрации города Пензы, что подтверждается актами о внедрении.

Апробация работы. Основные результаты диссертации докладывались и обсуждались на следующих конференциях: «Надежность и качество» (2010), «Технологии Microsoft в теории и практике программирования» (2010), «Актуальные вопросы современной науки и образования» (2010), «Математическое и программное обеспечение систем в промышленной и социальной сферах» (2011), «Университетское образование» (2012).

Публикации. По теме диссертационного исследования опубликовано 13 печатных работ, из которых 3 входят в перечень изданий, рекомендованных ВАК.

Личный вклад. Автором был выполнен основной объём исследований:

сформулированы задачи анализа активных правил, предложены и обоснованы варианты их решения; определены основные характеристики, архитектура, а также разработан прототип СУАБД, используемый в составе электронной карты города Пенза. Поддержку электронной карты осуществляет МУП «ОГСАГиТИ».

Структура и объём работы. Диссертация состоит из введения, четырёх глав, заключения, списка литературы из 112 наименований и пяти приложений. Объём работы – 168 страниц основного текста, включая 67 рисунков.

1 АНАЛИЗ МОДЕЛЕЙ, МЕТОДОВ И СРЕДСТВ ПОСТРОЕНИЯ

АКТИВНЫХ БАЗ ДАННЫХ

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

1.1 Анализ современных технологий обработки событий в базах данных Реагирование события в вычислительных системах осуществляется в соответствии с традиционной или событийно-ориентированной концепцией.

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

Событийно-ориентированной концепции соответствует асинхронная обработка событий в реальном времени. Каждое событие обрабатывается непосредственно в момент обнаружения. В данном случае реагирование на события является основной функцией вычислительной системы, что отражено в её архитектуре. Событийно-ориентированная архитектура (Event-Driven Architecture, EDA) – архитектурный шаблон программного обеспечения, в котором одна или более компонент системы выполняется в ответ на получение одного или более уведомления о событиях.

События могут быть описаны на разных уровнях абстракции. Обнаружение простых событий осуществляется с помощью источников событий, или агентов, которые получают данные непосредственно из объекта мониторинга. Сложные события выявляются в результате анализа простых событий или сложных событий более низкого уровня абстракции. Реакция на события и преобразование выполняется потребителями событий, или подписчиками [86, 94, 109, 110, 112].

На данный момент событийно-ориентированные системы нашли широкое применение в виде SCADA-систем (Supervisory Control and Data Acquisition, диспетчерское управление и сбор данных). SCADA-системы предназначены для контроля над технологическими процессами в реальном времени. Ключевой особенностью SCADA-систем является поддержка нескольких языков программирования, благодаря чему логика обработки данных может быть реализована на уровне релейных схем, функциональных блоков, диаграмм состояний, ассемблера и аналога языка Паскаль. Это позволяет описывать и задавать реакцию на события на том уровне абстракции, который наиболее точно соответствует моделируемому явлению предметной области.

Системы SCADA используются для экологического и метеорологического мониторинга, мониторинга ресурсоснабжающих сетей (электрических, водопроводных и иных), систем безопасности. Системы SCADA входят в состав автоматизированных систем управления технологическим процессом, применяются при обслуживании транспортных потоков для организации платного проезда, на автоматических парковках и при управлении светофорными объектами.

Для областей применения событийно-ориентированных систем характерно то, что смена состояний объекта мониторинга не может быть точно предсказана по текущему состоянию и воздействию на объект. В случае SCADA-систем это объясняется случайной природой событий, неизбежно возникающих в технологически сложных системах, над которыми осуществляется контроль.

В последние годы характерные черты технологических процессов, выступающих в качестве объекта объектов мониторинга SCADA-систем, наблюдаются в базах данных. Во-первых, при большом числе активных пользователей состояние базы данных может меняться очень быстро, и точно его предугадать на момент той или иной операции становится невозможно. Вовторых, во многих предметных областях возможно появление событий без внешнего воздействия – например, по таймеру. В-третьих, всё чаще бизнес-логика моделируемых процессов изначально предполагает взаимодействие объектов через события.

На данный момент не существует единого стандарта обработки событий в базах данных. Существующие концепции позволяют моделировать только частные аспекты обработки событий, не решая задачу в целом. Это остро ставит проблему выбора программных средств, функциональность которых наиболее полно соответствует требованиям той или иной предметной области.

Исследование рынка систем обработки событий позволяет утверждать, что, несмотря на динамичное развитие и постоянно обновляющийся функционал, спрос многократно превышает предложение. Иными словами, потребности многих предприятий в данной сфере шире возможностей любого существующего программного продукта [111, 112].

Помимо специализированных систем, обработка событий может в некоторой степени осуществляться средствами системы управления базами данных. Чаще всего для этого применяется механизм триггеров. Триггер – это хранимая процедура особого типа, которую СУБД запускает при возникновении сопоставленных триггеру событий. В зависимости от описания, триггер может быть запущен непосредственно до, после наступления события или даже вместо него.

Некоторый набор допустимых событий является одинаковым во всех СУБД.

Это операции обработки данных – вставка, удаление и модификация кортежей;

операции со структурой данных – создание, удаление и изменение структуры таблиц; события, касающиеся работы самой системы – открытие и закрытие базы данных или сессии пользователя.

Загрузка...
Также в некоторых системах встречаются специфичные события. Например, в SQL Server возможно срабатывание триггера при операции выборки данных. В PostgreSQL для обработки таких событий используется механизм правил – в дополнение к механизму триггеров. В СУБД Oracle событием может быть регистрация сообщения об ошибке сервера и зависание транзакции. Таким образом, события триггеров являются элементарными в том смысле, что ни одно из них не может быть получено из других. Эти события могут быть сгенерированы только самой СУБД, пользователь не может вызвать триггер как обычную хранимую процедуру [20, 21, 27, 28, 36, 59, 61, 67].

Такой способ запуска триггера на исполнение отражается на специфике выполняемых им действий и накладывает некоторые ограничения.

Если событию сопоставлено несколько триггеров, то для задания порядка выполнения во многих СУБД возможно лишь указать только первый и последний триггер. Остальные запускаются в случайной последовательности.

Выполнение в коде триггера операции, инициирующей его событие, в общем случае должно привести к рекурсивному вызову. Однако количество срабатываний триггеров при обработке одного инициирующего события во всех СУБД ограничено с целью избежания бесконечной рекурсии. Кроме того, присутствует возможность уменьшения этого числа и запрещения непосредственного рекурсивного вызова в настройках схемы данных [58, 67].

Таким образом, безопасность взаимодействия триггеров достигается ограничением функциональности. Поэтому в некоторых СУБД триггеры обладают дополнительными возможностями помимо традиционного функционала. Триггеры предназначены для реализации узкоспециализированных, но полезных в ряде ситуаций сценариев обработки событий. Например, в Oracle присутствует механизм автономных транзакций. Данный механизм позволяет успешно завершить вложенную (автономную) транзакцию, откатив родительскую. В результате триггер становится способен не только отменить нежелательное действие, но и сохранить сведения о попытке его совершения [58].

Исходя из сказанного, можно сделать вывод, что триггеры полезны для реагирования на элементарные события при моделировании бизнес-процессов, не требующих сложного взаимодействия через промежуточные события. Например, триггеры хорошо подходят для операций с транзакциями, так как в этом случае обработка должна быть быстрой и длительные вычисления неприемлемы. В то же время реагирование на события, приближенные по уровню абстракции к терминам предметной области, не может выполняться в полной мере в силу ограничений на промежуточные события. Триггеры могут быть использованы на начальном этапе реагирования: выявление событий нижнего уровня абстракции и передача сведений о них какой-либо другой компоненте информационной системы (ИС).

Ограничения функциональности триггеров сказываются при выявлении событий, являющихся композицией из других событий. Например, таким событием может быть одновременное возникновение двух событий или даже прекращение повторения события после многократного возникновения с небольшим интервалом. Иными словами, операции по выявлению сложных событий на основе анализа простых, в совокупности называемые алгеброй событий, могут существенно отличаться от логики, традиционно реализуемой посредством триггеров.

Алгебра событий обычно включает операции следующих типов:

- Темпоральная агрегация, то есть обработка событий, произошедших в рамках некоторого временного интервала;

- Пространственная агрегация, или обработка событий на основе пространственных характеристик связанных с ними объектов;

- Фильтрация и разбиение события на несколько по шаблону;

- Корректирование и внесение дополнительной информации [112].

Яркими примерами ситуаций, требующих выявления сложных событий, являются актуальные сегодня проблемы поведения пользователей в социальных сетях и подобных им ресурсах. Рассылка спама, оскорбительное поведение, создание анкет-дубликатов, размещение запрещённых материалов и заведомо ложной информации не может быть сведено к элементарному событию базы данных.

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

Специализированными средствами выявления событий на разных уровнях абстракции являются системы обработки сложных событий (Complex Event Processing, CEP). В отличие от СУБД, ключевой особенностью таких систем является возможность создания пользовательских типов событий. События могут быть сгенерированы как сторонним приложением, так и самой системой обработки событий по заданным пользователем правилам.

В качестве примеров программных продуктов, реализующих концепцию CEP, можно привести IBM InfoSphere, Oracle CEP, Microsoft Streamsight и CAP Event Insight. Все продукты имеют возможность глубокой интеграции с СУБД своего производителя, что позволяет обеспечить высокую скорость обработки событий. Из всех типов систем, используемых при реагировании на события, системы обработки сложных событий являются наиболее востребованными на сегодняшний момент. Соответствующие программные продукты всё чаще находят применение в коммерческих проектах, обеспечивая динамичное развитие данного сегмента рынка [86].

Информация о возникновении событий распространяется по принципу уведомлений, отправляемых от источника события к подписчику. Источником в глобальном смысле является СУБД, которая отправляет уведомление системе обработки сложных событий. Подписчиком является внешнее приложение, при необходимости выполняющее реагирование на событие при получении уведомления от системы обработки. Данное взаимодействие компонент информационной системы представлено диаграммой последовательностей [2, 6, 32, 33, 47, 48] на рисунке 1.1.

Рисунок 1.1. Взаимодействие компонент ИС при обработке сложных событий

Внутренняя обработка событий выполняется по тому же принципу. Для каждого задаваемого пользователем этапа вычислений создаётся приложениеагент, ожидающее уведомления о событии, на которое оно подписано, и генерирующее события для других агентов или во внешнее приложение. Таким образом, обработка состоит во взаимодействии сети агентов.

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

Несмотря на то, что реагирование на события полностью не решается, сложные события могут быть использованы для ряда важных подзадач:

оперативного распределения информации между компонентами ИС, диагностики состояния БД, предсказания нежелательных ситуаций.

Таким образом, значительная часть логики бизнес-процесса может быть реализована системой обработки сложных событий. Внешнее приложение отвечает только за выполнение действий в качестве реакции на событие.

Однако эффективное моделирование в рамках концепции сложных событий возможно не для всех бизнес-процессов. Строго говоря, применение сложных событий оправдано, если каждое из них соответствует некоторому событию предметной области. Если же бизнес-процесс может быть точнее описан в других терминах, возникает вопрос о применении более гибкой концепции в дополнение к концепции событий. В общем случае, требуется возможность описания реакции на событие на уровне самого события.

Описание не только события, но и всего процесса реагирования на высоком уровне абстракции позволяет существенно сократить внесение изменений в логику работы информационной системы по мере развития бизнес-процессов за счёт снижения доли участия программистов. Иными словами, специалист предметной области получает возможность описывать бизнес-логику в привычных для него терминах.

Для решения задачи описания бизнес-логики на высоком уровне абстракции предназначены системы управления бизнес-правилами (Business Rule Management System, BRMS). Бизнес-правило – это логическое утверждение, которое может быть создано пользователями и является исполнимым. Таким образом, бизнесправило может применяться для обработки данных в информационной системе, сохраняя точное соответствие некоторому явлению реального мира.

Примерами программных продуктов, реализующих концепцию систем управления бизнес-правилами, являются Oracle SOA, IBM Industry Models, Microsoft BizTalk. Продукты предоставляют программные средства для создания, развёртывания, исполнения, настройки и анализа бизнес-правил. Данные системы нашли своё применение в обработке платежей, управлении цепями поставок (supply chain management), межкорпоративном взаимодействии, принятии решений и составлении отчётности.

Правила исполняются специальной компонентой системы – подсистемой выполнения правил (rule engine). В зависимости от степени характеристик информационной системы и типов исполняемых правил, одновременно может действовать несколько подсистем выполнения. Координация работы обеспечивается системой развёртывания, напрямую связанной с репозиторием правил. Добавление правил в репозиторий осуществляется пользователями с помощью приложений управления правилами. Приложения связаны как с самим репозиторием через систему проектирования, так и с системой анализа бизнесправил, отвечающей за тестирование и верификацию. Таким образом, пользователь имеет возможность не только изменять набор правил, но и проверять взаимодействие друг с другом.

Пример структуры BRMS приведён на рисунке 1.2.

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

–  –  –

Рисунок 1.2.

Архитектура системы управления бизнес-правилами Различные вариации данного подхода сегодня используются во множестве предметных областей. Однако подход имеет ряд недостатков:

- Необходимость использования трёх дорогостоящих программных продуктов;

- Задержка при реагировании на события, неизбежно возникающая при взаимодействии нескольких различных систем;

- Необходимость описания бизнес-процессов с использованием двух непохожих нотаций для вычисления сложных событий и реакций на них;

- Анализ заданных пользователем типов событий и анализ бизнес-правил может проводиться только отдельно от базы данных и друг от друга.

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

Данное обстоятельство напрямую свидетельствует о необходимости единой концепции реагирования на события в базах данных.

1.2 Обработка событий на основе технологии активных баз данных

Большинство информационных систем в том или ином виде реализует реагирование на события. Однако реагирование не обязательно полностью автоматизируется, оставляя те или иные функции за пользователем.

Например, на пользователя часто возлагается принятие решения о том, как реагировать на событие, выявленное информационной системой. Такая ситуация характерна для систем слежения за движущимися объектами. Допустим, система ведёт учёт перемещений автомобилей, оснащённых GPS-передатчиком, который отправляет сообщения о перемещении и срабатывании датчика удара. В данном случае система с помощью механизма сложных событий способна выявить столкновение двух автомобилей по времени и месту произошедших с ними аварий.

Затем сведения о происшествии отправляются клиентскому приложению диспетчера. Соответствующий сценарий взаимодействия представлен диаграммой последовательностей на рисунке 1.3.

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

Рисунок 1.3. Пример взаимодействия элементов ИС движущихся объектов

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

Рисунок 1.4.

Взаимодействие элементов ИС при реагировании на событие, предусматривающее операцию с источником события Логика такого бизнес-процесса разнесена по различным элементам ИС, что затрудняет её анализ. Тем не менее, подобные бизнес-процессы моделируются успешно, если операция с источником события оказывается завершающей и не влияет на последующий процесс обработки событий.

Если же операция с источником события является промежуточной, корректное моделирование такого бизнес-процесса становится нетривиальной задачей.

Рассмотрим базу данных агентства недвижимости, в которой хранятся сведения о стоимости и расположении домов на продажу. Допустим, при изменении цены любого дома, должна частично меняться стоимость соседних домов, причём для каждого последующего изменения процесс рекурсивно повторяется.

Соответствующий сценарий приведён на рисунке 1.5.

Рисунок 1.5. Пример взаимодействия элементов ИС агентства недвижимости

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

Рассмотрим информационную систему оператора мобильной связи. Допустим, состояние лицевого счёта абонента определяется как количеством денежных средств, так и суммой бонусных баллов. При совершении вызова сначала со счёта списываются баллы, а затем – деньги. Когда последнее значение падает до нуля, вызов должен обрываться, чтобы баланс не стал отрицательным. На рисунке 1.6 представлена диаграмма последовательностей для данного сценария взаимодействия.

Рисунок 1.6. Пример взаимодействия элементов ИС мобильного оператора

В приведённом варианте взаимодействия промежуточные элементарные события обрабатываются по-разному в зависимости от момента возникновения.

Данное обстоятельство делает затруднительным эффективную обработку событий с помощью программных средств, описанных выше.

–  –  –

Таким образом, можно сделать вывод о недостаточной общности существующих подходов к обработке событий в базах данных, а также о необходимости единой концепции реагирования, учитывающей возможность возникновения промежуточных элементарных событий.

В этом качестве может быть рассмотрена концепция активных баз данных (АБД). В активной базе данных хранятся как сами данные, при действиях с которыми могут возникать события, так и полное описание реакции на них. Система управления активными базами данных (СУАБД) в дополнение к функциональности традиционных СУБД должна быть способна обнаруживать события и реагировать на них на том же уровне абстракции, что и системы обработки сложных событий [94, 107, 112].

Для реагирования предназначен механизм активных правил. Активное правило

– это хранящийся в АБД объект специального вида, задающий реакцию на событие.

В отличие от триггеров, событие активного правила не является элементарным.

Информация о событиях, с которыми могут быть сопоставлены активные правила, хранится в редактируемом реестре событий. Событие активного правила может быть вызвано программно при исполнении кода хранимых процедур, триггеров или других активных правил. Таким образом, функциональность активных правил является не заменой, а дополнением к функциональности триггеров, позволяя по примеру агентов в системах обработки сложных событий реагировать на события более высокого уровня абстракции.

Классической нотацией описания активных правил является ECA (EventCondition-Action, Событие-Условие-Действие) [17, 30, 31, 35, 52, 107, 67, 77-79, 82Существуют понятия типа и экземпляра события. Тип характеризуется именем события, именами и типами параметров, а также опционально может быть указан объект-источник события, например, некоторая таблица БД. Параметры события называют входными параметрами активного правила. Экземпляр состоит из описания типа события, отметки времени его возникновения и контекста, представляющего собой комбинацию значений параметров.

Условие представляет собой логическую функцию от контекста события, определяющую, необходимо ли выполнение реакции на событие, или же оно должно быть проигнорировано. Условие позволяет подняться на более высокий уровень абстракции без необходимости генерации нового события в тех случаях, когда вычисления не подразумевают агрегацию нескольких событий.

Действие активного правила – это последовательность операций с базой данных, выполняемых в качестве реакции. Параметры операций с БД, указанных в действии, называют выходными параметрами правила. Действие может приводить к выполнению другого активного правила. Во-первых, действие может напрямую содержать генерацию события. Во-вторых, в действии может присутствовать операция, соответствующая некоторому элементарному событию, к которому привязан триггер. В обоих случаях правила называют непосредственно инициирующим и непосредственно инициируемым. Кроме того, активные правила могут инициировать друг друга опосредованно через промежуточные правила [108].

В зависимости от хода своего выполнения, правило проходит несколько стадий.

При появлении экземпляра события, правило считается вызванным и для него вычисляется условие. Если результат оказывается истинным, правило является запущенным. Таким образом, выполненное правило характеризуется экземпляром события и результатом вычисления условия, а в случае истинности дополнительно отметкой времени запуска и завершения действия, а также значениями выходных параметров.

Выполнение активных правил является ядром функциональности системы управления активными базами данных [103].

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

При появлении экземпляра события СУАБД находит все сопоставленные ему правила и вызывает их. Как и в случае с триггерами, порядок выполнения правил может быть настраиваемым. Для вызванных правил СУАБД производит вычисление условия на основе значений контекста. Результаты запросов к БД, производимых при вычислении условия, также будем считать частью контекста.

Активные правила с истинными условиями запускаются в том же порядке, что и были вызваны. Важной функцией СУАБД при этом является журнализация значений выходных параметров и временных отметок.

Открытым вопросом в концепции АБД остаётся порядок вызова непосредственно инициируемого правила. Правило может быть вызвано как после полного выполнения инициирующего правила, так и сразу после операции, генерирующей экземпляр события. Данные альтернативы называют соответственно итеративной (iterative) и рекурсивной (recursive) циклической политикой (cycle policy) [107, 109].

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

Проверку активных правил во время выполнения называют динамическим проверкой правил (dynamic analysis). Динамическая проверка необходима для обеспечения стабильности работы системы путём контроля корректности выполняемых правил, а также реализации наиболее эффективного варианта запуска в случаях, когда правил много [71, 71, 92, 105, 106].

Конфликтом взаимодействия является зацикливание (livelock) – ситуация, возникающая при выполнении активных правил, при которой правила бесконечно инициируют вызов друг друга. Проблема зацикливания описана в работах [71-74, 80, 83-85, 89, 97, 101, 107, 108].

В СУБД для решения проблемы бесконечного вызова триггеров существует ограничение на количество запусков (обычно 32). В СУАБД такое решение не является допустимым, так как ограничивается функциональность активных правил, область применения которых подразумевает большое число промежуточных событий.

Другим конфликтом взаимодействия является состояние гонки (race condition) – ситуация, возникающая при обработке события, когда несколько активных правил независимо друг от друга изменяют состояние некоторого объекта. При этом сохраняется только последнее изменение, которое определяется случайно, а именно фактическим порядком запуска правил, не связанных между собой. Из-за состояния гонки активных правил результат обработки события оказывается непредсказуемым.

Эта проблема описана в работах [70-75, 80, 83-85, 97, 103, 107].

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

В традиционных СУБД проблема стабильности системы осуществляется путём ограничения функциональности триггеров при взаимодействии. В случае активных правил такой вариант не может быть приемлемым в силу специфики решаемых задач, требующих сложного взаимодействия правил [68, 77, 79, 87-89, 95, 98, 109-112].

В системах обработки сложных событий данная проблема также решается на концептуальном уровне. При преобразовании сложных событий друг в друга обычно происходит переход на более высокий уровень абстракции. Возвращение к элементарным событиям, в отличие от концепции АБД, невозможно.

Таким образом, в случае СУАБД динамическая проверка является необходимой, несмотря на то, что происходит усложнение процесса выполнения.

Динамическая проверка требуется как на стадии запуска правила для проверки выходных параметров, так и на стадии вызова для контроля правомерности выполнения активного правила в целом.

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

Как и в случае бизнес-правил, в АБД входит репозиторий активных правил для хранения кода. Однако, в отличие от систем управления бизнес-правилами, активные правила всегда выполняются в конкретной базе данных и не требуется координировать взаимодействие нескольких подсистем выполнения. Поэтому при выполнении активных правил является возможным прямое обращение к репозиторию без посредника в виде системы развёртывания.

Для обеспечения стабильности работы системы, СУАБД должна предоставлять возможность проектирования взаимодействия правил при редактировании содержимого репозитория. Иными словами, при каждом изменении активных правил должна предоставляться информация о том, как это отразится на работе других правил.

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

Проверка активных правил при верификации называется статической проверкой (static analysis). Статическая проверка состоит в исследовании возможных вариантов взаимодействия правил и выделение среди них потенциальных угроз с точки зрения стабильности работы системы [69, 99, 100].

Динамическая проверка правил позволяет выявить некорректные взаимодействия во время обработки событий. Но с точки зрения проектирования, проверка правил до начала фактического использования является более предпочтительной, так как позволяет выявить угрозы раньше и не затрагивает работу остальных правил.

Статическая проверка может проводиться как непосредственно перед добавлением правил в репозиторий, так и в дополнение к тестированию.

Резюмируя сказанное выше, можно сделать вывод, что основная функциональность СУАБД состоит в следующем:

1) Выполнение активных правил, включающую в себя возможность создания экземпляров событий, вызов и запуск правил, сопровождающийся динамической проверкой;

2) Ведение репозитория активных правил, в том числе проектирование правил, включающее в себя верификацию с помощью статической проверки.

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

На данный момент в концепции АБД остаётся открытым вопрос о способе реализации системы верификации: в виде отдельной подсистемы, в составе системы проектирования или за пределами СУАБД [93, 96, 97, 107].

В настоящее время не существует общепризнанного подхода к построению внутренней архитектуры подсистемы выполнения правил в СУАБД. Одна из концепций обобщённой архитектуры описана в [107]. В ней набор компонентов основывался на ECA-модели активных правил.

Данная архитектура представлена на рисунке 1.8.

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

Кроме того, событие АБД может формироваться из нескольких элементарных, так как сведения о них также содержатся в истории.

–  –  –

Рисунок 1.8.

Обобщённая архитектура СУАБД, основанная на ECA-модели.



Pages:   || 2 | 3 | 4 | 5 |
 
Похожие работы:

«Биричевский Алексей Романович Аппаратно-программные методы защиты информации в мобильных устройствах телекоммуникационных и информационных систем Специальность 05.13.19 – Методы и системы защиты информации, информационная безопасность Диссертация на соискание ученой степени Кандидата технических наук Научный руководитель д.т.н,...»

«Талдонова Светлана Сергеевна МЕТОДИЧЕСКИЙ ИНСТРУМЕНТАРИЙ ОЦЕНКИ ИНВЕСТИЦИОННОЙ ПРИВЛЕКАТЕЛЬНОСТИ В СИСТЕМЕ КОРПОРАТИВНОГО УПРАВЛЕНИЯ ОРГАНИЗАЦИЕЙ Специальность 08.00.05 – Экономика и управление народным хозяйством (менеджмент) ДИССЕРТАЦИЯ на соискание учной степени кандидата...»

«Баженова Ирина Васильевна МЕТОДИКА ПРОЕКТИВНО-РЕКУРСИВНОГО ОБУЧЕНИЯ ПРОГРАММИРОВАНИЮ СТУДЕНТОВ МАТЕМАТИЧЕСКИХ НАПРАВЛЕНИЙ ПОДГОТОВКИ 13.00.02 – Теория и методика обучения и воспитания (информатика, уровень профессионального образования) Диссертация на соискание учёной степени кандидата педагогических наук Научный руководитель: доктор...»

«ВОРОБЬЕВ МИХАИЛ ВИКТОРОВИЧ НАУЧНОЕ ОБОСНОВАНИЕ СИСТЕМЫ ОБЕСПЕЧЕНИЯ ИНФЕКЦИОННОЙ БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ПЕРСОНАЛА И ПАЦИЕНТОВ ПРИ ОКАЗАНИИ СТОМАТОЛОГИЧЕСКОЙ ПОМОЩИ 14.02.03 – Общественное здоровье и здравоохранение Диссертация на соискание ученой степени доктора медицинских наук Научный консультант: Доктор медицинских наук, профессор...»

«Рафикова Юлия Юрьевна ГЕОИНФОРМАЦИОННОЕ КАРТОГРАФИРОВАНИЕ РЕСУРСОВ ВОЗОБНОВЛЯЕМЫХ ИСТОЧНИКОВ ЭНЕРГИИ (на примере Юга России) Диссертация на соискание ученой степени кандидата географических наук Специальность 25.00.33 «Картография» Научный руководитель Доктор географических наук, профессор Б.А. Новаковский Москва 201 Содержание Введение.. Глава 1....»

«УДК 316.32 АБДУЛЛАЕВ Ильхом Заирович «ИНФОРМАТИЗАЦИЯ ОБЩЕСТВЕННО-ПОЛИТИЧЕСКОЙ ЖИЗНИ В УСЛОВИЯХ ГЛОБАЛИЗАЦИИ РАЗВИТИЯ» Специальность – 23.00.04 – Политические проблемы мировых систем и глобального развития Диссертация на соискание ученой степени доктора политических наук Ташкент – 2007 ОГЛАВЛЕНИЕ с. 3 – 15 ВВЕДЕНИЕ Глава 1. Понятийно-категориальные основы теории информационного...»

«Конфектов Михаил Николаевич Картографирование типов застройки Подмосковья по космическим снимкам Диссертация на соискание ученой степени кандидата географических наук по специальности 25.00.33 картография Научный руководитель: в. н. с., д. г. н. Кравцова В. И. Москва, 2015 Содержание ВВЕДЕНИЕ 1. ГЕОГРАФИЧЕСКИЕ И ИСТОРИЧЕСКИЕ УСЛОВИЯ ФОРМИРОВАНИЯ ЗАСТРОЙКИ...»

«САВОСТЬЯНОВА ИРИНА ЛЕОНИДОВНА МЕТОДИЧЕСКАЯ СИСТЕМА ФОРМИРОВАНИЯ ПРОФЕССИОНАЛЬНОЙ ИНФОРМАЦИОННОЙ КОМПЕТЕНТНОСТИ БУДУЩИХ БАКАЛАВРОВ-ЭКОНОМИСТОВ В ДИСЦИПЛИНАХ ИНФОРМАЦИОННОГО ЦИКЛА 13.00.02 – Теория и методика обучения и воспитания (информатика, уровень высшего профессионального образования) Диссертация на соискание ученой степени кандидата...»

«Егоров Алексей Юрьевич ФОРМИРОВАНИЕ И РАЗВИТИЕ РЫНКА ОРГАНИЧЕСКОЙ АГРОПРОДОВОЛЬСТВЕННОЙ ПРОДУКЦИИ (НА ПРИМЕРЕ ЦФО) Специальность 08.00.05 Экономика и управление народным хозяйством (экономика, организация и управление предприятиями, отраслями, комплексами – АПК и сельское хозяйство) ДИССЕРТАЦИЯ на соискание ученой степени кандидата экономических наук...»

«НИКОНОРОВ Артем Владимирович ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ВОССТАНОВЛЕНИЯ ЦВЕТНЫХ И...»

«Конорев Максим Эдуардович ВИРТУАЛЬНЫЙ ИСТОРИЧЕСКИЙ АРХИВ КАК СРЕДСТВО ИНФОРМАТИЗАЦИИ ИСТОРИЧЕСКОГО ОБРАЗОВАНИЯ ПРИ ПОДГОТОВКЕ БАКАЛАВРОВ В ВУЗЕ 13.00.02 – теория и методика обучения и воспитания (информатизация образования) Диссертация на соискание ученой степени кандидата педагогических наук Научный руководитель: доктор педагогических...»

«Масленников Андрей Геннадьевич РАЗРАБОТКА МЕТОДА ОБРАБОТКИ ТРАФИКА В ОЧЕРЕДЯХ МАРШРУТИЗАТОРОВ МУЛЬТИСЕРВИСНОЙ СЕТИ НА ОСНОВЕ НЕЧЁТКОЙ ЛОГИКИ Специальность 05.12.13 — Системы, сети и устройства телекоммуникаций Диссертация на соискание учёной степени кандидата технических наук Научный руководитель: кандидат технических наук Деарт В.Ю. Москва – 2015 Оглавление Стр. Введение............................»

«Агрова Ксения Николаевна МЕТОД, АЛГОРИТМ И СТРУКТУРНО-ФУНКЦИОНАЛЬНАЯ ОРГАНИЗАЦИЯ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ОБ УЧАСТИИ КОМПАНИЙ НА ЭЛЕКТРОННЫХ ТОРГОВЫХ ПЛОЩАДКАХ Специальность 05.13.10 «Управление в социальных и экономических системах» Диссертация на соискание ученой степени кандидата...»

«ЖЕЛЕЗНЯКОВ ВЛАДИМИР АНДРЕЕВИЧ Разработка методики геоинформационного обеспечения оперативного обновления электронных карт большого объёма с использованием банка пространственных данных Специальность 25.00.35 – Геоинформатика Диссертация на соискание учёной степени кандидата технических наук Научный руководитель: доктор...»

«Родионова Татьяна Васильевна Исследование динамики термокарстовых озер в различных районах криолитозоны России по космическим снимкам Диссертация на соискание ученой степени кандидата географических наук по специальности 25.00.33 картография Научный руководитель: в. н. с., д. г. н. Кравцова В. И. Москва 2013 Оглавление Введение...3 1. Термокарстовые озера...»

«Андреева Надежда Михайловна МЕТОДИКА ИСПОЛЬЗОВАНИЯ ДОРОЖНЫХ КАРТ ПРИ ЭЛЕКТРОННОМ ОБУЧЕНИИ СТУДЕНТОВ ИНФОРМАТИКЕ (на примере экономических и биологических направлений подготовки) 13.00.02 – Теория и методика обучения и воспитания (математика, уровень профессионального образования) ДИССЕРТАЦИЯ на соискание учёной степени кандидата...»

«ВОРОБЬЕВ МИХАИЛ ВИКТОРОВИЧ НАУЧНОЕ ОБОСНОВАНИЕ СИСТЕМЫ ОБЕСПЕЧЕНИЯ ИНФЕКЦИОННОЙ БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ПЕРСОНАЛА И ПАЦИЕНТОВ ПРИ ОКАЗАНИИ СТОМАТОЛОГИЧЕСКОЙ ПОМОЩИ 14.02.03 – Общественное здоровье и здравоохранение Диссертация на соискание ученой степени доктора медицинских наук Научный консультант: д.м.н., профессор М.А. Иванова...»

«Денисов Дмитрий Вадимович АНТЕННЫЕ И ДИФРАКЦИОННЫЕ ХАРАКТЕРИСТИКИ ЛИНЗ ЛЮНЕБЕРГА ПРИ ОБЛУЧЕНИИ ПОЛЕМ КРУГОВОЙ ПОЛЯРИЗАЦИИ Специальность 05.12.07 – Антенны, СВЧ устройства и их технологии Диссертация на соискание ученой степени кандидата технических наук Научный руководитель – доктор технических наук, профессор Панченко Б.А. Екатеринбург – 2015...»

«Федосеева Марина Васильевна СЕТЕВЫЕ СООБЩЕСТВА КАК СРЕДСТВО ОРГАНИЗАЦИИ УЧЕНИЧЕСКОГО САМОУПРАВЛЕНИЯ 13.00.02 — теория и методика обучения и воспитания (информатизация образования) Диссертация на соискание ученой степени кандидата педагогических наук Научный руководитель академик РАО, доктор педагогических наук, профессор Кузнецов А.А. МОСКВА 201...»

«ЛЯШ Ася Анатольевна МЕТОДИКА ОБУЧЕНИЯ БУДУЩИХ УЧИТЕЛЕЙ ИНФОРМАТИКИ ИСПОЛЬЗОВАНИЮ ИНФОРМАЦИОННО-ОБРАЗОВАТЕЛЬНЫХ СИСТЕМ В ПРОФЕССИОНАЛЬНОЙ ДЕЯТЕЛЬНОСТИ Специальность 13.00.02 – теория и методика обучения и воспитания (информатика) Диссертация на соискание ученой степени кандидата педагогических наук Научный руководитель: доктор педагогических...»









 
2016 www.konf.x-pdf.ru - «Бесплатная электронная библиотека - Авторефераты, диссертации, конференции»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.