Математические модели анализа данных
Структура и принципы построения информационной системы
Технология Интернет/Intranet OLAP
Подходы, реализующие Web-OLAP-технологию
HTML с расширениями — CGI, связующее ПО
Применение HTML с использованием Java-апплетов
При проектировании и внедрении программного и технического обеспечения ситуационного центра необходимо учитывать особенности задач, для решения которых создается данный ситуационный центр (СЦ). Точность и качество результатов работы зависит от качества получаемых данных, глубины и разносторонности их рассмотрения и обработки, объяснимости, презентативности, а также качества построенных моделей.
Таким образом, требования, предъявляемые к программному обеспечению ситуационных центров достаточно широки, среди них — наличие математических моделей, грамотно описывающих деятельность СЦ и решаемые им задачи, умение работать с большим набором архивных и поступающих данных (структурировать, согласовывать, анализировать, выявлять закономерности, прогнозировать).
Математические модели, которые внедрены в программное обеспечение ситуационного центра, по большей части определяют способности и возможности системы по обработке данных. И в зависимости от функциональной направленности ситуационного центра, могут носить различный характер действия (оценка, прогнозирование, учет и т. д.). С точки зрения задач системной интеграции важно различие моделей по методам моделирования: аналитическое, имитационное моделирование, а также их комбинация в сложных моделях.
При применении аналитического моделирования, каждый объект представляется функциональной зависимостью от входных, выходных и накопленных данных. Использование данного метода обосновано лишь в том случае, когда поведение объекта хорошо известно или изучено, т. е. его можно описать с известным уровнем адекватности формальным математическим аппаратом. Использование аналитического моделирования в ситуационных центрах основано на применении пакетов прикладных программ (которые обрабатывают информацию, поступающую из отдельных источников данных, специализированных хранилищ интегрированной информации), а также на визуализации сформированных данных.
В настоящее время наиболее широко используются две технологии аналитического моделирования (или их модификации):
Процесс имитационного моделирования позволяет воспроизводить события во времени. При этом происходит моделирование элементарных событий, при сохранении их логической структуры и последовательности. Преимущество таких моделей состоит в том, что их можно испытывать с различными параметрами. Таким образом, можно сгенерировать и проанализировать возможное развитие состояния системы в реальности, и соответственно, прогнозировать поведение исследуемого объекта. Их основное применение заключается в построении и поиске оптимального поведения в условиях недостаточной адекватности, сложности других моделей (или их отсутствия). Имитационные модели чаще всего являются независимыми пакетами, и их сложнее интегрировать в ПО СЦ. Это можно объяснить необходимостью предварительной обработки данных и достаточного их количества.
На начальном этапе создания СЦ вполне возможным является использование, как инструмента математического моделирования, MS Excel. По мере развития программного и аппаратного комплекса и уточнения требований к моделированию, возможен переход на более технологичные программные продукты на основе многомерных баз данных: Oracle, DB2 OLAP Server, MS SQL Server, Informics US и т. д.
Аналитический комплекс «Прогноз»
Физический уровень представлен реляционной моделью данных, содержащей принципы визуализации, хранимые процедуры, SQL-запросы, с возможностью поддержки следующих СУБД: Oracle, MS SQL Server, Informics и др. В модуле импорта/экспорта данных предоставлена возможность работы с вышеперечисленными СУБД, а также базами данных MS Access, dBase, FoxPro, Paradox и др. и файлами MS Excel, Edifact, XML и текстовыми файлами произвольной структуры. В конструкторе отчетов возможен экспорт в файлы MS Excel, RTF, PDF и HTML.
В Московском физико-техническом институте разработана система имитационного моделирования динамических систем с использованием сетей Петри в трехуровневой архитектуре «клиент–сервер». В основу системы было положено объектно-ориентированное описание сетей Петри в UML-нотации (Unified Modeling Language). Система реализована с помощью CASE-технологии DoomXL, разработанной в ЦОС и ВТ МФТИ. Применение современной промышленной СУБД Informix US в качестве серверной части системы позволяет хранить большие массивы данных по структуре сетей Петри, а также осуществлять моделирование динамики сетей Петри с помощью механизма транзакций, что обеспечивает высокую надежность системы.
Еще одним примером является типовой функциональный комплекс программ «Практика-ИПС» компании «Эврика», описанный в предыдущем номере «КИ» («КИ» № 21/2004).
Как мы уже сказали выше, ПО СЦ должно уметь оперативно обрабатывать огромные массивы данных. Для этого в основе СЦ лежит информационно-аналитическая система, которая обеспечивает необходимые функции и свойства центра. Практически, построение информационно-аналитической системы состоит в использовании технологии хранилищ данных и аналитической системы принятия решений. Данные в таких системах проходят преобразования прежде чем попасть от источника к информационной системе (так называемая технология ISP — Information Supply Chain, цепочки доставки информации).
Управление системой непосредственно в процессе работы и эффективное использование ресурсов — еще один немаловажный аспект функционирования СЦ. Такие системы управления построены на основе Workflow-технологий.
Workflow (управление потоком работ) часто рассматривается как основная технология интеграции систем, что обеспечивает связь между процессами и информацией, необходимой для их реализации, а также позволяет объединить приложения и ПО в хорошо адаптируемую распределенную инфраструктуру. Или, по определению консорциума Workflow Management Coalition, управление потоком работ представляет собой «полную или частичную автоматизацию бизнес-процессов, в ходе которых документы, информация и задачи пересылаются для обработки от одного участника к другому в соответствии с определенными процедурными правилами».
Ранее используемые технологии, на основе которых реализовывались хранилища данных, были ориентированы на анализ небольших выборок данных. С течением времени круг пользователей, как и объемы необходимой для обработки информации расширялись, но ориентация на небольшие объемы сохранялась. В настоящее время разработаны и внедрены технологии, предназначенные для оперативной обработки постоянно увеличивающихся огромных объемов информации, содержащейся в хранилищах.
При построении многомерного хранилища данных необходимо, прежде всего, выбрать режим хранения, который определяет способ организации данных на диске. Выбранный режим обуславливает использование определенного дискового пространства, а также скорость поиска и извлечения информации.
Существуют три режима:
В чем преимущества и недостатки каждого режима?
При применении MOLAP дисковое пространство на OLAP-сервере за счет хранения данных в проиндексированном, многомерном формате организовано более эффективно.
ROLAP же создает реляционные таблицы для хранения агрегированных данных в хранилище и обращается к базе данных этого хранилища, чтобы получить данные из таких таблиц при обработке клиентских запросов.
HOLAP, как понятно из названия, представляет собой гибрид MOLAP и ROLAP. Принцип хранения данных такой же, как у MOLAP, но для доступа к информации в таблицах данных происходит обращение к БД хранилища.
В большинстве случаев приемлемым считается использование MOLAP, так как скорость обработки запросов при его использовании значительно выше, чем в случае с ROLAP или HOLAP, также он превосходит ROLAP при структурировании многомерных данных.
Однако если необходимо использовать возможность обратной записи в OLAP (использование многомерных данных с целью прогнозирования, в этом случае данные автоматически записываются в реляционную таблицу, остальные же данные хранятся в выбранном ранее режиме хранения при создании хранилища), или при необходимости использования инструментов real-time OLAP, тогда использование MOLAP нецелесообразно. Логично строить хранилище в режиме ROLAP без агрегирования данных, если планируется использовать real-time OLAP. В этом случае пользователь, посылая MDX-запросы, может последовательно обновлять на экране результаты запросов для отслеживания изменений данных.
Для снятия накладываемых ими ограничений на количество пользователей, в нынешнем поколении ПО используются аналитические методы в совокупности с технологией Интернет/Intranet. И если ранее возможность работы сотни пользователей считалась приемлемой, то сейчас поддержка нескольких тысяч человек считается обычной, а в будущем предполагается обеспечивать сотни тысяч и более.
Появление динамических технологий в результате развития WWW предоставило альтернативные возможности традиционным клиент-серверным OLAP-методам. Таким образом, появился широкий круг OLAP-средств (их называют Web-OLAP или WOLAP), обладающих возможностью работы с использованием Web. Они выполняют традиционные для OLAP аналитические функции, такие как агрегирование и детализация, а также обеспечивают высокую производительность в сочетании со всеми преимуществами, которые представляет Web-ориентированное приложение.
Для таких приложений свойственен более легкий процесс установки и конфигурирования, основной смысл которого заключается в настройке специализированного Web-сервера и Web-приложения на машине администратора хранилища данных, где и происходят все вычисления, а клиентской машине необходим только Web-браузер и подключение к Intranet/Интернет.
С внедрением WebOLAP-средств все более размытыми становятся границы, отделяющие OLAP-рынок от смежных категорий программного обеспечения. Существующие Web-платформы интерактивной отчетности по своей функциональности похожи на стандартные Web-OLAP-продукты.
Сегодня Intranet-технологии часто применяются для развертывания хранилищ данных и предоставления OLAP-функций в масштабе СЦ или комплексной системы управления, а затем, для связи с управляющим звеном, переходят к технологиям extranet (IP-приложение, связывающее различные части системы, которое чаще всего базируется на Web-технологии и использует в качестве среды передачи данных Интернет), чтобы обеспечить защищенный доступ к хранилищу данных и OLAP-средствам. Такой способ расширенной поддержки принятия решений позволяет совместно и продуктивно использовать информационные ресурсы и находить новые возможности развития, управления и анализа данных.
На данном этапе возникает проблема определенного уровня конфиденциальности и защищенности информации. Поэтому, прежде чем реализовать систему поддержки принятия решений в extranet, необходимо четко определить информационные и аналитические потребности конкретной структуры, входящей в состав СЦ.
Очевидно, что использование возможностей Web достаточно эффективно позволяет обмениваться информацией между различными частями СЦ, участвующими в процессе принятия решений. Применяя технологию Web-OLAP наряду со средствами оперативной доставки данных на сервер (push-technology — необходимые для работы заранее определенные данные автоматически подгружаются из хранилища), можно предоставить управляющим органам приоритетную информацию, связанную и обработанную по определенным правилам.
С помощью Web-браузеров производится независимая от установленной платформы поддержка интерактивной OLAP-отчетности. Обучение сотрудников центра OLAP-анализу минимально за счет использования стандартных Internet-функций и методов навигации.
Для реализации архитектуры, применяющей идею Web-OLAP, недостаточно использования стандартной клиент-серверной модели. Необходимы новые технологии обработки не только больших объемов данных, но и возможности масштабирования с учетом количества пользователей.
Большая часть Web-OLAP-приложений использует общую архитектуру, в которой клиентский браузер получает HTML-документы, взаимодействуя с HTTP-сервером. Однако, кроме этого, используется еще и связующее ПО, хранящееся на сервере. Благодаря чему существует возможность специализированной обработки данных и отсылка их HTTP-серверу или клиентскому Web-браузеру. Web-OLAP-компонент связующего уровня выполняет набор функций, которые не может обеспечить HTML, а именно:
Таким образом, видно, что обеспечивается достаточная безопасность при извлечении данных из реляционной базы, за счет использования связующего звена: Web-браузер не соединяется с БД напрямую, а клиент также получает ограниченный доступ на HTML-сервер.
Обычно связующее ПО хранится на той же машине, что и HTTP-сервер, хотя это и не обязательно. Оно должно грамотно взаимодействовать с БД хранилища, а также обеспечивать и разграничивать права пользователей и сетевой доступ таким образом, чтобы промежуточный (связующий) компонент мог извлекать данные, необходимые для нормальной работы OLAP-приложений. Связующий компонент должен проектироваться оптимально, иначе, при неправильной настройке, сложная программа промежуточного уровня может очень медленно выполнять запросы клиентов, тем самым понизив общую производительность системы.
Подход, при котором связующее ПО размещается между HTTP-сервером и Web-клиентом, позволяет предотвратить нелогичное увеличение базы данных хранилища (применение централизованного хранения информации, доступного для пользователей с помощью OLAP, позволит свести на нет риск работы с устаревшими данными, так как все данные доступны и обновляются в режиме реального времени).
Спектр реализованных подходов к Web-OLAP в настоящее время достаточно широк, в том числе на основе технологий HTML (DHTML), Java, ActiveX, а также комбинации вышеназванных.
Перечислим основные типы продуктов:
Для реализации OLAP-функциональности в Web-браузере используется только HTML. Например, использование OLAP-инструментов только для получения и отсылки запросов с помощью Web-браузера.
Это самый простой способ получения данных. В этом случае используются планировщики, которые формируют статические HTML-отчеты по HTML-шаблонам, по данным, получаемым с автономного HTML-сервера. Причем одним из требований, предъявляемых при проектировании шаблона, является согласованный вид генерируемого отчета. Одним из преимуществ статических отчетов, является их хорошая переносимость, быстрая обработка браузером, при этом практически отсутствует взаимодействие пользователя с браузером, так как обработка и структурирование данных происходит на Web-сервере. Для большей функциональности и простоты навигации по отчету возможно создание группы отчетов, связанных между собой гиперссылками.
При использовании другого, чаще применяемого, подхода, OLAP-сервер заполняет HTML-шаблон данными в оперативном режиме, по мере поступления запроса пользователя через браузер. В этом случае на Web-сервере достаточно хранить только шаблоны отчетов и метаданные, содержащие информацию, необходимую для передачи Web-сервером определенной информации в HTML-файл, перед отправкой их в клиентский браузер.
Возможно хранение метаданных на сервере в двух форматах:
HTML-шаблоны также представимы в одном из двух форматов. Если для создания шаблонов используется готовый редактор, то они хранятся в обычных гипертекстовых файлах на Web-сервере. Пользователь может щелкнуть в браузере по ссылке с названием отчета и HTML-шаблона. Иногда предлагаются инструментальные Web-средства для создания и хранения метаданных шаблонов вместе с метаданными отчетов в двоичном формате. В таком случае и отчет, и шаблон могут быть созданы в оперативном режиме с помощью специальных процессов Web-сервера.
Вне зависимости от способа хранения метаданных шаблонов, выделяемая Web-сервером информация формируется согласно коду отчета, посылаемому с клиентского браузера. Полученная из базы данных информация объединяется на основе шаблона в отчет и передается в браузер.
Одно из слабых мест HTML — невозможность хранить состояния (предыдущие транзакции). Одним из способов решения проблемы является использование CGI (Common Gateway Interface — общий шлюзовой интерфейс) или других Web API (Application Programming Interface — интерфейс прикладного программирования) для реализации связующего ПО. Благодаря использованию таких методов, можно обеспечить хранение состояний, а также буферизацию строк, возвращаемых на клиентскую машину, и выполнение некоторых вычислений над передаваемыми данными.
При использовании такой архитектуры совместимость для клиентских платформ обеспечивается за счет использования HTML в качестве интерфейса. Однако в зависимости от реализации приложения Web-сервера, возможен переход с одной серверной платформы на другую. В частности, CGI-приложения обладают высокой переносимостью. О большинстве других Web API этого сказать нельзя.
Но и в данной ситуации использование только HTML налагает определенные ограничения на пользовательский интерфейс (проблема с правильным отображением графиков и отчетов). Решение этой проблемы возможно с применением Java-апплетов, обладающих большими возможностями по визуализации представляемых данных.
Что касается интерфейса, то интеграция свойств HTML и Java-апплетов позволяет создать качественное Web-OLAP-решение. Для выполнения простых интерфейсных функций вполне удовлетворительным является использование HTML-решений, а в случае необходимости описания более сложных компонентов интерфейса, согласованности отображения графиков, таблиц или диаграмм (особенно если их необходимо изменять в режиме реального времени), помогает применение Java-апплетов или компонентов ActiveX, за счет более широких графических возможностей, нежели HTML. Возможно два направления использования этих компонентов.
В одном случае Web-OLAP-сервер заполняет двоичный файл данными для запрошенных отчетов, и компоненты интерфейса посылаются в браузер вместе с ответным сгенерированным HTML-файлом. На машине клиента в зависимости от свойств управляющего элемента (ActiveX или Java) задается название соответствующего файла данных для браузера. Браузер загружает этот файл, а управляющий компонент получает требуемую информацию. Можно заметить, что компоненты обеспечивают выполнение следующих OLAP-функций: агрегирование, детализация с помощью удобного интерфейса, без обращения к серверу. А в связи с тем, что передача данных происходит в двоичном формате, обеспечивается наиболее безопасное соединение.
Во втором случае компонент интерфейса напрямую устанавливает соединение с сервером, который в режиме реального времени передает информацию на машину клиента по мере поступления запросов от пользователя. В этом случае открывается HTTP-канал, по которому интерфейсный компонент запрашивает данные с Web-сервера; получив и проанализировав результаты с сервера, он отсылает данные на объект для отображения.
А использование связующего приложения удобно благодаря предварительной буферизации данных и выполнения предварительных вычислений и агрегации данных, перед передачей данных на клиентскую машину. Таким образом, может повыситься производительность Web-OLAP-приложения.