Диссертация (Методы и алгоритмы обработки информации в информационно-аналитических системах для анализа развития событий кризисных ситуаций), страница 14

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

4.2) [85, 86]. Данноерешение позволило интегрировать новые методики моделирования и необходимый инструментарий. Временный вывод, метода расчета, хранилище данныхинформационно-аналитических систем и т.д., обеспечивает интегрированнаясреда разработки.82Интеграция эталонных (информационных) моделей, визуализация и анализ с помощью интуитивно понятных интерфейсов, в том числе графиков временных рядов, – задача интегрированной среды разработки лица принимающего решение.РедактормоделинамеренийВизуализацияСредапроектированияСредамоделированияИнтегрированная среда разработкиИнтегрированная среда разработкиЛица принимающего решениеРазработчикаРис.

4.2. Двухступенчатая архитектура интегрированной среды разработкиДля реализации многоуровневой темпоральной системы управления базой данных (СУБД) были проработаны следующие способы: преобразования науровне ядра реляционной СУБД [87, 88], преобразование на уровне пользовательского приложения и использование независимого промежуточного proxyуровня. Первый способ предоставил максимум возможностей по расширениюсинтаксиса языка баз данных, обеспечению различных проверок, а также оптимизации.

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

Подобнаяабстракция (пусть и на уровне приложения) позволила сократить число ошибоки отделить аналитическую логику приложения от технической составляющейхранения данных.83Далее в работе, принято решение в разрабатываемой СППР создать между пользовательским приложением и СУБД некоторого промежуточного «черного ящика» (proxy-уровень), который реализован в виде сервиса [88].

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

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

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

С другойстороны, под управлением темпоральной СУБД вполне может находитьсяобычная реляционная база данных. Более того, для части таблиц темпоральнаяподдержка может быть включена, а для других таблиц – нет. При построениимодели языка запросов к темпоральной базе данных ставились следующие цели. Во-первых, при переходе к темпоральной модели желательно расширить всетри компонента модели данных: структуру данных, операции и ограниченияцелостности. Во-вторых, любая корректная конструкция в исходном языке запросов должна остаться корректной в новом языке, и семантика этих конcтрукций должна остаться прежней; например, результат, возвращаемый запросом,должен быть таким же. То есть необходимо обеспечить восходящую совместимость языка запросов и базы данных. Кроме того, необходимо обеспечить темпоральную совместимость, чтобы после добавления в систему темпоральнойподдержки все унаследованные конструкции продолжали работать так же, каки раньше. Из этого следует, что все существующие приложения не должны«почувствовать» переход от обычной реляционной СУБД к темпоральнойСУБД.

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

В этом заключается принцип гибкости положенный в основу разрабатываемой СППР для внедрения новых методик и инструментария.Таким образом, темпоральная СУБД в СППР реализована на уровне независимого промежуточного proxy-уровня, в силу того, что интенсивность обмена данными оказалась на порядок выше, чем между proxy-уровнем и БАМН.Proxy-уровень реализует задачу системы временных решений, обеспечивает пе-85реход с одной модели временного вывода на другую, поддерживает как транзакционный (по запросу), так и автоматический режим работы.На рис. 4.3 показано место блока активного моделирования намерений вразработанной структурной схеме СППР "Визуально-аналитическое сопровождение процессов обработки структурированных данных" [70] и вероятностноепричинно-следственное моделирование с включением динамических байесовских алгоритмов сети.

Из рис. 4.3. показано, что данные ИАС поступают вБАМН, где происходит обработка информации выше описанными способами иалгоритмами, осуществляется взаимодействие с ТБЗБ через прокси-уровень ипроизводится вывод результата обработанной информации на экран с помощьюмодуля визуализации.Блок активного моделированиянамеренияМногоуровневая архитектуратемпоральной СУБДКонтент анализ, ивент-анализинформационного массиваСУБДфильтрВходные данныеСканерproxy-уровеньБДРазборсообщений.АнализсвязностисобытийВероятностноепричинноследственноемоделированиетемпоральныйзапрос QтрансляторSQLзапрос Q’ТБЗБпарсерМодульвизуализацииАктивнаякорректировка моделинамеренийметаданныерезультатРезультат моделированияРис. 4.3. Структурная схема СППР "Визуально-аналитическое сопровождение процессовобработки структурированных данных" [19]Система временных решений, реализованная в БАМН работает через интерфейс связи (рис.

4.3), архитектура СВР включает два основных блока: контроля и базы моделей. Блок контроля реализует протокол взаимодействия с ин-86терфейсом связи и обеспечивает доступ к экземплярам задачи согласованиявременных ограничений (ЗСВО), содержащимся в хранилище (БД) [81].Реляционная модель данных оказалась очень подходящей для храненияданных информационно-аналитических систем, обработки и представления результатов запросов, и поэтому темпоральную базу данных с самого началапредполагалось основывать на существующей реляционной модели, так кактемпоральное расширение является лишь одним из дополнительных признаковхранимых данных.База моделей может содержать модели, для которых решение ЗСВО основывается на различной алгоритмической базе и внутреннем представлении.При этом модуль СВР абстрагирован от тонкостей внутренней организации модулей-решателей ЗСВО за счет стандартизированного интерфейса связи и протокола взаимодействия, работа которого основана на языке запросов СВР - TQL(Temporal Query Language) (рис.