CC BY
411
Акимов А.А., Богатърев В.Е., Финогеев А.Г. СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ НА БАЗЕ БЕСПРОВОДНЫХ СЕНСОРНЫХ СЕТЕЙ С ИСПОЛЬЗОВАНИЕМ ИНТЕЛЛЕКТУАЛЬНОГО АНАЛИЗА ДАННЫХ
Рассмотрены вопросы проектирования системы поддержки принятия решений в сфере образования с использованием хранилищ данных для целей интеллектуального анализа данных и поддержка мобильного доступа на основе беспроводных сенсорных сетей. Кроме того, приводится описание технологий и средств проведения подобной работы на опыте разработки информационно-аналитической среды кафедры САПР Пензенского государственного университета.
В той или иной степени системы поддержки принятия решений (СППР) присутствуют в любой информационно-аналитической системе (ИАС). По мере развития любой сферы человеческой жизнедеятельности, упорядочения структуры организации и налаживания межкорпоративных связей, проблема разработки и внедрения СППР становится особенно актуальной. Сфера образования не исключение. Одними из подходов к созданию ИАС стало использование хранилищ данных(Data Warehouse), алгоритмов интеллектуального анализа данных(Data Mining, ИАД), а также беспроводных сенсорных сетей для организации мобильного доступа к системе.
СППР можно, в зависимости от данных, с которыми они работают, разделить на оперативные (Executive Information Systems, ИСР), предназначенные для немедленного реагирования на текущую ситуацию, и стратегические(Decision Support System) - основанные на анализе большого количества информации из разных источников с привлечением сведений, содержащихся в системах, аккумулирующих опыт решения проблем [1].
СППР первого типа получили название информационных систем руководства. По сути, они представляют собой конечные наборы отчетов, построенные на основании данных из транзакционной информационной системы предприятия или OLTP(Online Transaction Processing)-системы, в идеале адекватно отражающей в режиме реального времени все аспекты производственного цикла предприятия. Для ИСР характерны следующие основные черты:
отчеты, как правило, базируются на стандартных для организации запросах; число последних относительно невелико;
ИСР представляет отчеты в максимально удобном виде, включающем, наряду с таблицами, деловую графику, мультимедийные возможности и т. п.;
как правило, ИСР ориентированы на конкретный вертикальный рынок, например управление ресурсами, финансы.
СППР второго типа предполагают достаточно глубокую проработку данных, специально преобразованных так, чтобы их было удобно использовать в ходе процесса принятия решений. Неотъемлемым компонентом СППР этого уровня являются правила принятия решений, которые на основе агрегированных данных подсказывают менеджерскому составу выводы и придают системе черты искусственного интеллекта. Такого рода системы создаются только в том случае, если структура организации уже достаточно определена и имеются основания для обобщения и анализа не только данных, но и процессов их обработки. Если ИСР есть не что иное как развитие системы оперативного управления производственными процессами, то СППР в современном понимании - это механизм развития, который включает в себя некоторую часть управляющей информационной системы, обширную систему внешних связей предприятия, а также технологические процессы его развития.
Если посмотреть на СППР с функциональной стороны, можно выделить следующие ее компоненты [2]: сервер хранилища данных; инструментарий OLAP; инструментарий Data Mining.
Хранилища данных
Хранилища данных - это архитектура построения информационных систем, получившая развитие вследствие желания конечных пользователей иметь непосредственный единообразный доступ к необходимым им данным, источники происхождения которых организационно и территориально распределены, а анализ которых может способствовать принятию решений. Билл Инмон (W. Inmon), автор концепции хранилищ данных, определил их как «предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления», призванные выступать в роли «единого и единственного источника истины», обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений [3]. Ричард Хакаторн (R. Hackthorn), другой основоположник этой концепции, писал, что цель хранилищ данных -обеспечить для организации «единый образ существующей реальности» [4].
Такой образ реальности должен быть представлен единой информационной моделью. Проблематика моделирования данных связана с таким представлением информации, которое наиболее естественно отражает реальный мир и, в то же время, может поддерживаться компьютерными средствами. Следовательно, модель, с одной стороны, должна описывать сложную структуру данных и их взаимосвязь, а с другой -быть достаточно просто организованной, чтобы обеспечить быстрый и надежный доступ к хранимым данным. На протяжении всей истории развития информационных систем предпринимались различные попытки разрешения этого противоречия. Так возникли «классические» модели данных - иерархическая, сетевая и реляционная, реализованные различными СУБД. Семантические характеристики каждой из этих моделей имеют свои достоинства и недостатки, однако сегодня главенствующее положение занимает реляционная модель, поскольку ее концепция наилучшим образом формализуется традиционными механизмами математической логики. Представление данных в реляционной форме обладает достаточной гибкостью, но не обеспечивает должной интуитивности восприятия описываемых объектов с точки зрения конечного пользователя информационных систем.
Целью построения хранилища данных является интеграция, актуализация и согласование оперативных данных из разнородных источников для формирования единого непротиворечивого взгляда на объект управления в целом. При этом в основе концепции хранилищ данных лежит признание необходимости разделения наборов данных, используемых для транзакционной обработки, и наборов данных, применяемых в системах поддержки принятия решений. Такое разделение возможно путем интеграции разъединенных в системах обработки данных (СОД) и внешних источниках детализированных данных в едином хранилище, их согласования и, возможно, агрегации.
Несмотря на различия в подходах и реализациях, всем хранилищам данных свойственны следующие общие черты [5]:
Предметная ориентированность. Информация в хранилище данных организована в соответствии с основными аспектами деятельности; это отличает хранилище данных от оперативной БД, где данные организованы в соответствии с процессами. Предметная организация данных в хранилище способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Вы-
ражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных. В случае хранения данных в реляционной СУБД применяется схема «звезды» (star) или «снежинки» (snowflake). Кроме того, данные могут храниться в многомерной СУБД в n-мерных кубах.
Интегрированность. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются и загружаются в хранилище. Такие данные намного проще анализировать.
Привязка ко времени. Данные в хранилище всегда напрямую связаны с определенным периодом времени. Данные, выбранные их оперативных БД, накапливаются в хранилище в виде «временных слоев», каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции в развитии организации.
Неизменяемость. Попав в определенный «временной слой» хранилища, данные уже никогда не будут изменены. Это также отличает хранилище от оперативной БД, в которой данные все время меняются, и один и тот же запрос, выполненный дважды с интервалом в несколько минут, может дать разные результаты. Стабильность данных, также облегчает их анализ.
Концепция хранилищ данных предполагает не просто единый логический взгляд на данные организации, а действительную реализацию единого интегрированного источника данных. Альтернативным по отношению к этой концепции способом формирования единого взгляда на корпоративные данные является создание виртуального источника, опирающегося на распределенные базы данных различных СОД. При этом каждый запрос к такому источнику динамически транслируется в запросы к исходным базам данных, а полученные результаты на лету согласовываются, связываются, агрегируются и возвращаются к пользователю. Однако такой способ обладает рядом существенных недостатков:
Время обработки запросов к распределенному хранилищу значительно превышает соответствующие показатели для централизованного хранилища. Кроме того, структуры баз данных СОД, рассчитанные на интенсивное обновление одиночных записей, в высокой степени нормализованы, поэтому в аналитическом запросе к ним требуется объединение большого числа таблиц, что также приводит к снижению быстродействия.
Интегрированный взгляд на распределенное хранилище возможен только при выполнении требования постоянной связи всех источников данных в сети. Таким образом, временная недоступность хотя бы одного из источников может либо сделать работу ИАС невозможной, либо привести к ошибочным результатам.
Выполнение сложных аналитических запросов над таблицами СОД потребляет большой объем ресурсов сервера БД и приводит к снижению быстродействия СОД, что недопустимо, так как время выполнения операций в СОД часто весьма критично.
Различные СОД могут поддерживать разные форматы, данные в них могут быть несогласованны. Очень часто на один и тот же вопрос может быть получено несколько вариантов ответа, что может быть связано с несинхронностью моментов обновления данных, отличиями в трактовке отдельных событий, понятий и данных, ошибками при вводе и т. д. В таком случае цель - формирование единого непротиворечивого взгляда на объект управления - может не быть достигнута.
Главным же недостатком следует признать практическую невозможность обзора длительных исторических последовательностей, ибо при физическом отсутствии центрального хранилища доступны только те данные, которые на момент запроса есть в реальных БД связанных СОД. Основное назначение СОД -оперативная обработка данных, поэтому они не могут позволить себе роскошь хранить данные за длительный (более нескольких месяцев) период; по мере устаревания данные выгружаются в архив и удаляются из транзакционной БД. Что касается аналитической обработки, для нее как раз наиболее интересен взгляд на объект управления в исторической ретроспективе.
Таким образом, хранилище данных функционирует по следующему сценарию. По заданному регламенту в него собираются данные из различных источников - баз данных систем оперативной обработки. В хранилище поддерживается хронология: наравне с текущими хранятся временные данные с указанием
времени, к которому они относятся. В результате необходимые доступные данные об объекте управления собираются в одном месте, приводятся к единому формату, согласовываются и, в ряде случаев, агрегируются до минимально требуемого уровня обобщения.
Облегченным вариантом хранилища данных могут быть витрины данных (Data Mart), то есть тематические БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации. Концепция витрин данных была предложена Forrester Research в 1991 году [6]. При этом главная идея заключалась в том, что витрины данных содержат тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное хранилище данных, и, следовательно, требующие менее производительной техники для поддержания. В 1994 году Марк Демарест (M. Demarest) предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника для многочисленных витрин данных[7].
В самом простом варианте для хранилищ данных используется та модель данных, которая лежит в основе транзакционной системы. Если, как это часто бывает, транзакционная система функционирует на реляционной СУБД (Access, MySQL, PostgreSQL и т. п.), самой сложной задачей становится выполнение запросов ad-hoc, поскольку невозможно заранее оптимизировать структуру БД так, чтобы все запросы работали эффективно.
Однако при создании СППР было выявлено, что существует зависимость между частотой запросов и степенью агрегированности данных, с которыми запросы оперируют, а именно чем более агрегированными являются данные, тем чаще запрос выполняется. Другими словами, круг пользователей, работающих с обобщенными данными, шире, чем тот, для которого нужны детальные данные. Это наблюдение легло в основу подхода к поиску и выборке данных, называемого оперативной аналитической обработкой (Online Analytical Processing, OLAP)[8].
OLAP
OLAP-системы построены на двух базовых принципах:
все данные, необходимые для принятия решений, предварительно агрегированы на всех соответствующих уровнях и организованы так, чтобы обеспечить максимально быстрый доступ к ним;
язык манипулирования данными основан на использовании бизнес-понятий.
В основе OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные, например объемы продаж. Измерения представляют собой совокупности значений других данных, скажем наименование дисциплин и названий семестров года. В простейшем случае двумерного куба (квадрата) мы получаем таблицу, показывающую значения успеваемости студентов по дисциплинам и семестров. Дальнейшее усложнение модели данных может идти по нескольким направлениям:
увеличение числа измерений - данные о продажах не только по семестрам и дисциплинам, но и по группам;
усложнение содержимого ячейки - например, нас может интересовать не только общая успеваемость, но и, скажем, успеваемость по дисциплинам различных циклов. В этом случае в ячейке будет несколько значений;
введение иерархии в пределах одного измерения - общее понятие время естественным образом связано с иерархией значений: год состоит из семестров, семестр из месяцев и т. д.
Речь пока идет не о физической структуре хранения, а лишь о логической модели данных. Другими словами, определяется лишь пользовательский интерфейс модели данных. В рамках этого интерфейса вводятся следующие базовые операции: поворот;
проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону;
раскрытие (drill-down). Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба; свертка (roll-up/drill-up). Операция, обратная раскрытию; сечение (slice-and-dice).
Существует три способа хранения данных в OLAP-системах или три архитектуры OLAP-серверов [9]:
MOLAP (Multidimensional OLAP);
ROLAP (Relational OLAP);
HOLAP (Hybrid OLAP).
В случае MOLAP, исходные и многомерные данные хранятся в многомерной БД или в многомерном локальном кубе. Такой способ хранения обеспечивает высокую скорость выполнения OLAP-операций. Но многомерная база в этом случае чаще всего будет избыточной. Куб, построенный на ее основе, будет сильно зависеть от числа измерений. При увеличении количества измерений объем куба будет экспоненциально расти. Иногда это может привести к «лавинообразному» росту объема данных, парализующему в результате запросы пользователей.
Для систем ROLAP гиперкуб - это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. В этой структуре можно хранить очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP - операций. Опыт эксплуатации ROLAP-продуктов показал, что они больше подходят на роль интеллектуальных генераторов отчетов, чем действительно оперативных средств анализа[10]. Они применяются в таких областях, как телекоммуникации, финансы, где количество данных велико, а высокой эффективности запросов не требуется.
В случае использования гибридной архитектуры, т.е. в HOLAP-продуктах, исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-средства на основе реляционных и многомерных данных. Такой подход позволяет избежать взрывного роста данных. При этом можно достичь оптимального времени исполнения клиентских запросов.
Многие современные OLAP-серверы поддерживают все три способа хранения данных: MOLAP, ROLAP и HOLAP. Одним из самых распространенным в настоящее время серверным решением является OLAP-сервер корпорации Microsoft, который и был использован при разработке данной системы.
С помощью OLAP-сервера может быть организовано физическое хранение обработанной многомерной информации [8], что позволяет быстро выдавать ответы на запросы пользователя. Кроме того, предусматривается преобразование данных из реляционных и других баз в многомерные структуры в режиме реального времени.
При построении программно-технологической архитектуры хранилища следует иметь в виду, что система принятия решения, на какие бы визуальные средства представления она ни опиралась, должна предоставить пользователю возможность детализации информации.
Интеллектуальный анализ данных
Интеллектуальный анализ данных обычно определяют как метод поддержки принятия решений, основанный на анализе зависимостей между данными. В рамках такой общей формулировки обычный анализ отчетов, построенных по базе данных, также может рассматриваться как разновидность ИАД. Чтобы перейти к рассмотрению более продвинутых технологий ИАД, посмотрим, как можно автоматизировать поиск зависимостей между данными.
Существует два подхода. В первом случае пользователь сам выдвигает гипотезы относительно зависимостей между данными. Фактически традиционные технологии анализа развивали именно этот подход. Действительно, гипотеза приводила к построению отчета, анализ отчета к выдвижению новой гипотезы и т. д. Это справедливо и в том случае, когда пользователь применяет такие развитые средства, как OLAP, поскольку процесс поиска по-прежнему полностью контролируется человеком. Во многих системах ИАД в этом процессе автоматизирована проверка достоверности гипотез, что позволяет оценить вероятность тех или иных зависимостей в базе данных. Типичным примером может служить, такой вывод: вероятность того, что рост продаж продукта А обусловлен ростом продаж продукта В, составляет
0,25.
Второй подход основывается на том, что зависимости между данными ищутся автоматически. Количество продуктов, выполняющих автоматический поиск зависимостей, говорит о растущем интересе производителей и потребителей к системам именно такого типа.
Процессы ИАД подразделяются на три большие группы: поиск зависимостей (discovery), прогнозирование (predictive modelling) и анализ аномалий (forensic analysis). Поиск зависимостей состоит в просмотре базы данных с целью автоматического выявления зависимостей. Проблема здесь заключается в отборе действительно важных зависимостей из огромного числа существующих в БД. Прогнозирование предполагает, что пользователь может предъявить системе записи с незаполненными полями и запросить недостающие значения. Система сама анализирует содержимое базы и делает правдоподобное предсказание относительно этих значений. Анализ аномалий - это процесс поиска подозрительных данных, сильно отклоняющихся от устойчивых зависимостей.
Технологии ИАД позволяют решать множество задач с привлечением методов математической статистики и теории вероятности, а также методов искусственного интеллекта. Наибольшее распространение нашли методы использования, позволяющие решать следующие задачи:
Классификация - отнесение объекта (события, предмета) к одному из заранее известных классов по его характеристикам.
Регрессия - прогнозирование значения какого-либо выходного параметра объекта по набору входных параметров.
Кластеризация - задача заключается в группировке объектов на кластеры (независимых групп) по значениями присущих объектам параметров. Решение этой задачи помогает лучше понять данные.
Поиск ассоциативных правил - выявление закономерностей между какими-либо связанными объектами. Решение этой задачи помогает лучше понять природу анализируемых данных и может служить для прогнозирования появления событий.
Предсказание последовательностей - нахождение зависимостей между объектами или событиями в форме правил, указывающих, что после некоего события A наступает событие B.
Анализ отклонений - анализ данных на предмет вхождения явных нехарактерных шаблонов.
Несмотря на то, что для каждой прикладной задачи анализа данных подходит преимущественно один способ решения, в целом решение задач является зачастую комплексом из применяемых методов интеллектуального анализа данных.
Необходимо также упомянуть об возможностях интеграции ИАД в информационные системы. Многие методы ИАД возникли из задач экспертного анализа, поэтому входными данными для них традиционно служат "плоские" файлы данных. При использовании ИАД в СППР часто приходится сначала извлекать данные из хранилища, преобразовывать их в файлы нужных форматов и только потом переходить собственно к интеллектуальному анализу.
Беспроводные сенсорные сети
Новой технологией в построении современных систем мониторинга является использование беспроводных сенсорных сетей в качестве альтернативы проводным соединениям в системах сбора данных и инфракрасной связи в системах дистанционного управления.
Беспроводные сенсорные сети (БСС) на базе стандарта IEEE 802.15.4 являются новым классом систем, состоящих из множества распределенных в пространстве устройств, обладающих набором сенсоров, микроконтроллером, памятью и радиочастотным трансивером для связи на короткие расстояния. В качестве сенсоров сетях используются различные датчики для сбора информации различного рода. Данные, собираемые с множества сенсоров, после соответствующей обработки содержат весьма полную информацию о наблюдаемом объекте или субъекте в целом. Самыми распространенными, на сегодняшний день, являются сети, созданные на базе технологиях ZigBee, 6LowPAN, Wibree, NanoNET, российской платформе Mesh Logic.
Рассмотрим некоторые механизмы интеллектуального управления БСС.
Синергетический принцип самоорганизации сенсорной сети определяет возможность синтеза беспроводной сети с произвольной топологией путем автоматического поиска и объединения сенсорных узлов в сеть, с возможностью реконфигурации виртуальных маршрутов и динамическим изменением топологии при отключении отдельных узлов.
При использовании БСС в общем информационном пространстве беспроводных сетей WiFi или Bluetooth, работающих в аналогичном частотном диапазоне, например 2,4-2,4835 ГГц, часть радиоканалов стандарта IEEE 8 02.15.4 могут быть заняты другими сетями. Для решения подобных проблем производится выбор свободного частотного диапазона, причем на различных участках сети трафик может передаваться на разных радиочастотных каналах. Смену канала выполняют только те узлы, для которых это действительно необходимо, остальная часть сети продолжает функционировать на прежнем канале.
Важным моментом при работе автономной сенсорной сети является ее отказоустойчивость и поведения в случае перемещения узлов, отказа или отключении. Сенсорная сеть должна постоянно адаптироваться к изменению окружающей сетевой виртуальной среды. Для этого узел постоянно следит за соседями, обновляя маршрутные таблицы на основе оценки мощности сигналов RSSI. В результате, при изменении местоположения соседей или их исчезновении из сети (физического удаления устройств, прекращения энергопитания и т.п.), вычисляется новый маршрут.
Другим немаловажным вопросом в БСС является минимизация энергопотребления узлов. Наименьшее энергопотребление достигается при синхронизированном доступе к среде, который позволяет переводить в «спящий» (энергосберегающий) режим сетевые узлы по некоторому заданному алгоритму, по команде от узла-координатора или по отсутствию внешних событий. Задача должна быть решена с использованием интеллектуальных алгоритма оптимизации с учетом всех перечисленных факторов и критерию выбора оптимального маршрута с точки зрения энергопотребления сети.
Заключение
Создание СППР c использованием интеллектуального анализа данных и поддержкой мобильного доступа на основе беспроводных сенсорных сетей - сложный процесс, требующий знания предметной области, программно-технического инструментария и опыта выполнения крупных проектов. Вместе с тем внедрение подобных систем может дать преимущества, которые будут тем ощутимее, чем раньше организация начнет создание СППР. Значимость информационных систем подобного уровня очевидна. Их использование в в сфере образования позволяет существенно повысить профессиональный уровень выпускников кафедры ВУЗа, а также повысить эффективность работы структурного подразделения в целом.
ЛИТЕРАТУРА
1. Inmon W.H. Using the Data Warehouse / W.H. Inmon, R. Hackthorn. Willey. -1994.
2. Щавелёв Л. В. Способы аналитической обработки данных для поддержки принятия решений / Ща-велёв Л. В. // СУБД. - 1998. - № 4-5.
3. Inmon W. H.. Building the Data Warehouse / W.H. Inmon. -Willey. - 2005.
4. Hackathorn R.. Reinventing Enterprise Systems Via Data Warehousing / R. Hackthorn. - Wash-
ington, DC: The Data Warehousing Institute Annual Conference. - 1995.
5. Drewek K. Data Warehousing: Similarities and Differences of Inmon and Kimball / K.
Drewek. - Electronic data.- Mode access :http://www.b-eye-network.com/view/7 4 3.
6. Сахаров А. А. Концепция построения и реализации информационных систем, ориентированных на
анализ данных / А. А. Сахаров // СУБД. - 1996. - № 4. - С. 55-70.
7. Demarest M. Building the Data Mart / M. Demarest.- DBMS. - 1994. - № 7. - P. 44-50.
8. Львов В. Создание систем поддержки принятия решений на основе хранилищ данных / В. Львов // СУБД.- 1997.- №3.- C. 30-40.
9. Чубукова И.А. Data Mining / И.А. Чубукова.- БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру.- 2008
10. Громов Ю.Ю. Управление данными : учебное пособие / Ю.Ю. Громов, О.Г. Иванова, В.Н. Точка. - Тамбов : Изд-во Тамб.гос. техн. ун-та, 2009. - 80 с. - ISBN 978-5-8265-0877-0.
