45408 (Создание систем поддержки принятия решений), страница 3

Наряду с мощными серверами многомерных баз данных и ROLAP-серверами на рынке предлагаются клиентские OLAP-серверы, предназаначенные, главным образом, для работы с небольшими объемами данных и ориентированные на индивидуального пользователя. Подобные системы были названы настольными, или DOLAP-серверами (Desktop OLAP). В этом направлении работают фирмы Business Objects (Business Objects 5.0), Andyne (CubeCreator, PaBLO), Cognos, Brio Technology.

Лидером пока считается компания Cognos, поставляющая продукты PowerPlay, Impromptu и Scenario. PowerPlay - это настольный OLAP-сервер, для извлечения данных из реляционных баз данных (Paradox, dBase, Clipper), "плоских" файлов и электронных таблиц (Microsoft Excel) используется генератор запросов и отчетов Impromptu. Затем специальный компонент, называемый Transformer, помещает извлеченные данные в клиентскую многомерную базу, которая называется PowerCube. Потребителям предоставляются широкие возможности по управлению PowerCube: передавать ее от пользователя к пользователю по запросу и принудительно, помещать на сервер для разделения доступа к ней или пересылать по электронной почте. Cognos постаралась сделать свой продукт максимально открытым: во-первых, PowerCube может быть помещен в реляционные базы Oracle, Informix, Sybase, MS SQL Server на платформах UNIX, HP/UX, Sun Solaris, IBM AIX, во-вторых, сам PowerPlay способен анализировать содержимое не только PowerCube, но и других многомерных баз данных.

Стоит отметить, что все эти фирмы объединяет стремление включить в свои продукты компоненты, предназначенные для Интеллектуального Анализа Данных (Data Mining, ИАД). Например, усилия Business Objects и Cognos направлены на подготовку окончательных версий компонентов Business Miner и Scenario, соответственно, предназначенных именно для ИАД.

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

• объем данных, пересылаемых между клиентом и сервером, не очень велик;

• большая часть вычислений может быть выполнена заранее;

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

• нет необходимости поддерживать разделение данных между клиентами (клиенты изолированы друг от друга);

• приложения не требуют постоянных модификаций и усовершенствований.

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

В трехуровневых архитектурах между клиентом и сервером (который теперь называется корпоративным сервером) помещается еще одни сервер, называемый сервером приложений. Обязанностью корпоративного сервера является работа с корпоративными данными, например с Хранилищем Данных: организация доступа к Хранилищу, разделение ресурсов между клиентами и т. д. Клиент по-прежнему реализует пользовательский интерфейс, выполняет пользовательские операции с данными и хранит локальные данные. Сервер приложений выполняет роль посредника между клиентом и корпоративным сервером, снижая нагрузку на последний.

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

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

3. Интеллектуальный анализ данных

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

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

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

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

Процессы ИАД подразделяются на три большие группы: поиск зависимостей (discovery), прогнозирование (predictive modelling) и анализ аномалий (forensic analysis). Поиск зависимостей состоит в просмотре базы данных с целью автоматического выявления зависимостей. Проблема здесь заключается в отборе действительно важных зависимостей из огромного числа существующих в БД. Прогнозирование предполагает, что пользователь может предъявить системе записи с незаполненными полями и запросить недостающие значения. Система сама анализирует содержимое базы и делает правдоподобное предсказание относительно этих значений. Анализ аномалий - это процесс поиска подозрительных данных, сильно отклоняющихся от устойчивых зависимостей.

В системах ИАД применяется чрезвычайно широкий спектр математических, логических и статистических методов: от анализа деревьев решений (Business Objects) до нейронных сетей (NeoVista). Пока трудно говорить о перспективности или предпочтительности тех или иных методов. Технология ИАД сейчас находится в начале пути, и практического материала для каких-либо рекомендаций или обобщений явно недостаточно.

Необходимо также упомянуть об интеграции ИАД в информационные системы. Многие методы ИАД возникли из задач экспертного анализа, поэтому входными данными для них традиционно служат "плоские" файлы данных. При использовании ИАД в СППР часто приходится сначала извлекать данные из Хранилища, преобразовывать их в файлы нужных форматов и только потом переходить собственно к интеллектуальному анализу. Затем результаты анализа требуется сформулировать в терминах бизнес-понятий. Важный шаг вперед сделала компания Information Discovery, разработавшая системы OLAP Discovery System и OLAP Affinity System, предназначенные специально для интеллектуального анализа многомерных агрегированных данных.

Заключение

Создание СППР на основе хранилищ данных - сложный, но обозримый процесс, требующий знания бизнеса, программно-технического инструментария и опыта выполнения крупных проектов. Вместе с тем внедрение подобных систем может дать преимущества в бизнесе, которые будут тем ощутимее, чем раньше организация начнет создание СППР. По прогнозам консалтинговой фирмы Gartner Group, к 2010 году примерно 90-95% компаний будут использовать хранилища данных.

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

• закупка и тестирование разнообразных продуктов, применяемых при создании СППР и ХД (к сожалению, большинство из них плохо сопрягаются друг с другом, из-за чего создается ложное впечатление "неподъемности" проблемы);

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

Список литературы

1. Система поддержки принятия решений в человеко-машинных системах управления. Труды Института проблем управления РАН им. В.А.Трапезникова. Том УШ. М.: ИПУРАН, 2000г. с. 46-59. 

2. Арлазаров В.Л., Журавлев Ю.И., Ларичев О.И., Лохин В.М., Макаров И.М., Рахманкулов В.З., Финн В.К. Теория и методы создания интеллектуальных компьютерных систем // Информационные технологии и вычислительные системы. -1998. -№1.

3. Валькман Ю.Р. Интеллектуальные технологии исследовательского проектирования. -Киев.: Port-Royal. -1998.

4. Комарцова Л.Г. Оптимизация вычислительной системы на ее имитационной модели. // Вестник МГТУ им. Н.Э.Баумана. - сер. "Приборостроение". -1999. -№2. -С.48-60.

5. Литвак Б.Г. Экспертные технологии управления. М.: Дело, 2004г.

6. Трахтенгеру Э.А. Компьютерная поддержка принятия решений. – М.: Наука, 1998.

7. Чекинов Г.П., Куляница А.Л., Бондаренко В.В. Применение ситуационного управления в информационной поддержке принятия решений при проектировании организационно-технических систем // Информационные технологии в проектировании и производстве, № 2, 2003.