Главная
страница 1 ... страница 3страница 4страница 5страница 6страница 7

3.5 Выводы


В данной главе была рассмотрена реализация предложенного подхода и осуществлён выбор программных средств, реализующих подход:

  1. OLAP-сервер: Pentaho Mondrian.

  2. Хранилище данных: СУБД PostgreSQL.

  3. Модуль преобразования и загрузки данных: Pentaho Kettle.

  4. OLAP-клиент: JPalo Pivot.

Все выбранные программные средства являются бесплатными.

4. Апробация предложенного подхода


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

4.1 Обзор СППР для департамента РЭП Минпромторга


СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ (в дальнейшем СППР РЭП) предназначена для принятия решений по управлению развитием предприятий отрасли в интересах повышения эффективности и устойчивости их функционирования, снижения рисков невыполнения заданий Федеральных целевых программ на основе методов ситуационного управления.

Основными задачами СППР РЭП являются:



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

  • интеграция с существующими информационными системами, содержащими информацию по предприятиям отрасли;

  • ввод и корректировка исходной информации поддержки принятия управленческих решений;

  • автоматизированная обработка информации текущего финансово-экономического и производственно-технологического состояния организаций радиоэлектронной промышленности:

  • оценка рисков невыполнения предприятиями отрасли программных мероприятий федеральных целевых программ;

  • оценка и прогнозирование состояния предприятий радиоэлектронной отрасли;

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

Основными объектами автоматизации СППР РЭП являются федеральные целевые программы (в дальнейшем программы) и мероприятия. Программа составляется на определённых срок и состоит из набора мероприятий, подлежащих к выполнению организациями-исполнителями в течение указанного срока. Как у мероприятия, так и у программы в целом существуют вероятностные значения рисков невыполнения и ожидаемый ущерб в случае их невыполнения.

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

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

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



Таким образом, можно выделить следующие основные объекты автоматизации:

  • Программа. Существует несколько видов программ. Характеризуется целью, сроками, описанием и ожидаемым результатом от выполнения программы.

  • Предложение. Характеризуется общей стоимостью, сроками выполнения, вероятностью срыва, ущербом от срыва. Состоит из нескольких этапов, каждый из которых характеризуется длительностью и стоимостью. Предложение привязано к определённому направлению деятельности (например, сверхвысокочастотная электроника)

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

  • Организация-исполнитель. Она выполняет мероприятия программы. Характеризуется контактной информацией (почтовый адрес, юридический адрес, телефон, e-mail и др.), а также набором финансово-экономических, производственных и других показателей.

Более подробно модель данных системы поддержки принятия решений представлена на рис. П.1.1. прил. 1.

4.2 Реализация подсистемы многомерного анализа данных в СППР для департамента РЭП Минпромторга

4.2.1 Разработка хранилища данных и многомерных OLAP-кубов


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

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

  • Куб «Анализ стоимости мероприятий», отображающий финансирование мероприятий. Данный куб использует в качестве измерений все справочники информационной базы и не использует пользовательских агрегирующих функций.

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

Можно выделить следующий алгоритм создания куба:

  1. Спроектировать многомерный куб – выделить необходимые измерения, иерархии и меры.

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

  3. В программе Pentaho Kettle создать сценарий преобразования данных из хранилища данных СППР в OLAP-хранилище данных.

  4. Добавить созданный куб в OLAP-сервер.

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

  1. Проектирование и разработка многомерного куба «Анализ показателей организаций-исполнителей»

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

  • Организация (organization_dim)

    • Федеральный округ (fedokrug)

    • Регион (region)

    • Город (city)

    • Название организации

  • Время (prod_indicator_timedim)

    • Год (year)

    • Квартал (quarter)

  • Показатель (prod_indicator)

    • Группа показателей (group)

    • Наименование показателя

Также можно выделить две меры – значение показателя (value) и его прогнозируемое значение (forecast_value).

Спроектированная для куба схема «Звезда» изображена на рис.4.1:



c:\documents and settings\администратор\мои документы\анализ показателей организаций.png

Рис. 4.1 Схема данных многомерного куба «Анализ показателей организаций-исполнителей»

Для преобразования данных из хранилища СППР в OLAP-хранилище воспользуемся следующим сценарием, построенным в Kettle (рис. 4.2):

Рис. 4.2 Сценарий преобразования данных для куба «Анализ показателей организаций-исполнителей»

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


  • использование временных меток создания записи для каждого кортежа в оперативной БД и затем при выборе данных из БД дополнительно в каждый SQL-запрос вставлять условие WHERE;

  • использование элемента «Поиск и обновление» (combination lookup/update) в качестве промежуточного элемента в сценарии преобразования данных.

В данной работе использовался второй способ, т.к. он не требует внесений изменений в структуру хранилища данных СППР. Рассмотрим данный способ на примере.

На рис. 4.2 приведён сценарий преобразования данных для разрабатываемого куба, состоящий из четырёх этапов преобразования. Каждый этап загружает данные в таблицы OLAP-хранилища и состоит из нескольких шагов (рис. 4.3):



Рис. 4.3 Шаги типичного этапа преобразования

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

Таблица 4.1

SQL-запросы, применяемые для загрузки исходных данных

Этап

SQL-запрос

Заполнение organization_dim

SELECT o.id, o.short_name AS name, r.id AS region_id, r.name AS region_name, c.id AS city_id, c.name AS city_name, f.id AS fedokrug_id, f.name AS fedokrug_name

FROM organization o

JOIN city c ON o.city_id = c.id

JOIN region r ON o.region_id = r.id

JOIN fed_okrug f ON r.fedokrug_id = f.id;

Заполнение prod_indicator_dim

SELECT pi.id, pi.name, pig.id AS group_id, pig.name AS group_name

FROM prod_indicator pi

JOIN prod_indicator_group pig ON pi.prod_indicator_group_id = pig.id;

Заполнение prod_indicator_timedim

SELECT piv.year || '_' || piv.quarter AS id, piv.year, piv.quarter,

CASE


WHEN piv.quarter = 1 THEN 'I квартал'

WHEN piv.quarter = 2 THEN 'II квартал'

WHEN piv.quarter = 3 THEN 'III квартал'

WHEN piv.quarter = 4 THEN 'IV квартал'

END AS quarter_name

FROM prod_indicator_value piv

GROUP BY 1,2,3

ORDER BY 1,2,3;

Заполнение prod_indicator_fact

SELECT piv.id, piv.prod_indicator_id, piv.year || '_' || piv.quarter AS time_id, piv.organization_id, piv.value, piv.forecast_value

FROM prod_indicator_value piv;

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

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

Далее необходимо добавить созданный куб в OLAP-сервер с помощью программного продукта Pentaho Mondrian Workbench. Данный продукт позволяет описывать используемые измерения, иерархии, меры и типы агрегирующих функций для мер.

В данном кубе для мер была выбрана агрегирующая функция avg (среднее значение). Таким образом, при просмотре информации за какой-либо период времени пользователю будет выдаваться именно среднее значение показателя.

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


  1. Проектирование и разработка многомерного куба «Анализ стоимости мероприятий»

Мероприятия, входящие в программу, финансируются из средств бюджетных и внебюджетных источников. Финансирование планируется на какие-то периоды времени, обычно по годам. Например, если какое-нибудь мероприятие выполняется в период с 2011 и по 2018 годы, то деньги на него могут быть выделены следующим образом: на 2011 год – 1 млн. руб., на период 2012-2015 года – 5 млн. руб., 2016-2018 – 2 млн. руб. Каждое мероприятие выполняется какой-либо организацией-исполнителем.

У каждой разрабатываемой программы существует государственный заказчик – одно из 5 предприятий: Минпромторг, Росатом, Роскосмос, Рособразование, Роспром.

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

Разрабатываемый куб решает следующие задачи:



  • анализ хода выполнения программы в целом и каждого конкретного мероприятия в частности;

  • анализ подготовленных вариантов программ.

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

В разрабатываемом кубе можно выделить следующие измерения и иерархии:



  • Организация-исполнитель (organization_dim)

    • Федеральный округ (fedokrug)

    • Регион (region)

    • Город (city)

    • Название организации

  • Период финансирования (work_cost_dim)

    • Период (work_cost_period)

  • Мероприятие (work_usage_dim)

    • Тип программы (program_type)

    • Программа (program)

    • Вариант программы (program_variant)

    • Вид направления деятельности (work_direction_type)

    • Направление деятельности (work_direction)

    • Название мероприятия

  • Государственный заказчик (customer_dim)

    • Наименование заказчика

Следует отметить, что в данном кубе используется разработанное ранее измерение organization_dim. В кубе используются две меры – бюджетные (budget_sum) и внебюджетные (outbudget_sum) средства, выделенные на финансирование. Спроектированная для куба схема звезды изображена на рис.4.4:

c:\documents and settings\igoroshkov\мои документы\анализ стоимости мероприятий.png

Рис. 4.4 Схема данных многомерного куба «Анализ стоимости мероприятий»

Для преобразования данных из хранилища данных СППР в OLAP-хранилище воспользуемся следующим сценарием, построенным в программе Kettle (рис. 4.5):

Рис. 4.5 Сценарий преобразования данных для куба

«Анализ стоимости мероприятий»

Этапы данного сценария аналогичны этапам предыдущего сценария, поэтому не будут подробно рассматриваться. Ниже приведены SQL-запросы, используемые при выборке исходных данных в сценарии:

Таблица 4.2

SQL-запросы, применяемые для загрузки исходных данных



Этап

SQL-запрос

Заполнение work_cost_period_dim

SELECT wcp.id, wcp.period FROM work_cost_period wcp;

Заполнение customer_dim

SELECT c.id, c.shortname as name FROM customer c;

Окончание табл. 4.2

Заполнение work_usage_dim

SELECT wu.id, pt.id AS program_type_id, pt.name AS program_type_name, p.id AS program_id, p.name AS program_name, pv.id AS program_variant_id, pv.name AS program_variant_name, wd.id AS work_direction_id, wd.name AS work_direction_name, wdt.id AS work_direction_type_id, wdt.name AS work_direction_type_name, wu.id AS work_id, wu.name AS work_name

FROM work_usage wu

JOIN program_variant pv ON wu.program_variant_id = pv.id

JOIN program p ON pv.program_id = p.id

JOIN program_type pt ON p.program_type_id = pt.id

JOIN work w ON wu.work_id = w.id

JOIN work_direction wd ON w.work_direction_id = wd.id

JOIN work_direction_type wdt ON wd.work_direction_type_id = wdt.id;

Заполнение work_cost_fact

SELECT wu.id AS work_usage_id, wu.organization_id, wc.budget_sum, wc.outbudget_sum, wc.work_cost_period_id, c.id AS customer_id

FROM work_cost wc

JOIN work_usage wu ON wc.work_usage_id = wu.id

JOIN program_variant pv ON wu.program_variant_id = pv.id

JOIN work w ON wu.work_id = w.id

JOIN customer c ON w.customer_id = c.id;

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

  1. Проектирование и разработка многомерного куба «Анализ рисков и оценочной стоимости предложений»

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

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

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

Разрабатываемый куб решает следующие задачи:



  • анализ оценочной стоимости предложений;

  • анализ степени рисков невыполнения мероприятий и возможного ущерба при невыполнении.

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

В разрабатываемом кубе можно выделить следующие измерения и иерархии:



  • Период финансирования этапов (work_stage_period_dim)

    • Год (year)

  • Предложение (work_dim)

    • Тип программы (program_type)

    • Программа (program)

    • Вид направления деятельности (work_direction_type)

    • Направление деятельности (work_direction)

    • Название предложения

    • Этап предложения (work_stage)

  • Государственный заказчик (customer_dim)

    • Наименование заказчика

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

В кубе можно выделить три меры – оценочная стоимость (cost_estimation), вероятность срыва предложения (risk_failure_percent) и ущерб (risk_loss), понесённый при невыполнении предложения.

Спроектированная для куба схема звезды изображена на рис.4.6:

c:\documents and settings\igoroshkov\мои документы\анализ рисков и стоимости предложений.png

Рис. 4.6 Схема данных многомерного куба «Анализ рисков и оценочной стоимости предложений»

Для преобразования данных из хранилища данных СППР в OLAP-хранилище воспользуемся следующим сценарием, построенным в программе Kettle (рис. 4.7):

Рис. 4.7 Сценарий преобразования данных для куба

«Анализ рисков и оценочной стоимости предложений»

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



Рис 4.8 Шаги этапа заполнения таблицы work_stage_period_dim

Этап состоит из двух SQL-запросов, результаты которых объединяются в одну таблицу. Ниже приведены SQL-запросы, используемые на данном этапе:

Таблица 4.3

SQL-запросы, применяемые для загрузки исходных данных

Действие

SQL-запрос

Выборка всех дат начала этапов и выделение из них годов

select date_part('year', begin_date) as "year" from work_stage group by 1;

Выборка всех дат завершения этапов и выделение из них годов

select date_part('year', end_date) as "year" from work_stage group by 1;

Следующий этап аналогичен этапам, разработанным ранее, и поэтому не будет подробно рассматриваться. SQL-запрос, используемый на данном этапе:

SELECT ws.id, ws.name as name, w.id as work_id, w.name as work_name, pt.id AS program_type_id, pt.name AS program_type_name, p.id AS program_id, p.name AS program_name, wd.id AS work_direction_id, wd.name AS work_direction_name, wdt.id AS work_direction_type_id, wdt.name AS work_direction_type_name

FROM work_stage ws

JOIN work w on ws.work_id = w.id

JOIN work_direction wd ON w.work_direction_id = wd.id

JOIN work_direction_type wdt ON wd.work_direction_type_id = wdt.id

JOIN program p ON w.program_id = p.id

JOIN program_type pt ON p.program_type_id = pt.id;

Последний этап – заполнение таблицы фактов. Сложность в данном этапе заключается в преобразовании данных. В хранилище данных СППР информация об этапе содержится за конкретный промежуток времени с точностью до месяца, а в результате необходимо получить информацию об этапах за каждый календарный год. Рассмотрим пример. Пусть какой-нибудь этап выполняется с 1 августа 2011 года по 1 мая 2012 года. Стоимость этапа оценили в 1 млн. рублей, вероятность срыва этапа – 30%, а ожидаемый ущерб от срыва – 100 тыс. руб. Тогда в OLAP-хранилище должна быть записана следующая информация: за 2011 год на этап ожидается выделить 5/9 млн. руб, а за 2012 – 4/9 млн. руб, где



  • 5 – продолжительность этапа в 2011 году (в месяцах);

  • 4 – продолжительность этапа в 2012 году (в месяцах);

  • 9 – продолжительность выполнения этапа (в месяцах).

Аналогичным образом преобразуется ожидаемый ущерб. Вероятность срыва этапа в 2011 году равна 0.35/9, а в 2012 – 0.34/9, т.к. вероятность наступления одновременно всех событий, равна произведению вероятностей наступления каждого из них.

Рассмотрим подробнее данный этап (рис. 4.9):



Рис 4.9 Шаги этапа заполнения таблицы фактов work_fact

В начале данного этапа из хранилища СППР берутся данные о каждом этапе с помощью следующего SQL-запроса:

SELECT ws.id as work_stage_id, w.customer_id, ws.risk_failure_percent, ws.cost_rel_estimation, ws.cost_abs_estimation,

ws.begin_date, ws.end_date, ws.risk_loss



FROM work_stage ws

JOIN work w on work_id=w.id;

После выполнения данного SQL-запроса имеем:



  • дату начала выполнения этапа;

  • дату завершения выполнения этапа;

  • оценочную стоимость этапа;

  • вероятность срыва этапа;

  • ожидаемый ущерб от срыва этапа;

  • идентификаторы, ссылающиеся на таблицы измерений.

Затем с помощью элемента «Modified Java Script Value» к каждой строке полученной таблицы добавляется новое поле js_y, содержащее перечисление годов, входящий в срок выполнения этапов. Например, если этап выполняется с 1 июня 2010 до 1 сентября 2013 года, то поле js_y будет иметь значение [2010;2011;2012;2013]. Элемент «Modified Java Script Value» позволяет применять к каждому кортежу преобразования, описанные на языке JavaScript:

var js_y = "";
var i;

for (i=year(begin_date); i<=year(end_date);i++){

js_y+=i;

if (i!=year(end_date)) js_y+=";";

}

Далее применяется элемент «Split field to rows», позволяющий добавлять новые строки к таблице, основываясь на значении какого-либо поля. В данном шаге разделение основывается на поле js_y – для каждого значения года, перечисленного в поле, создаётся новый кортеж данных. Рассмотрим данное преобразование на конкретном примере (рис. 4.10):



Поле 1

Поле 2

Поле 3

Поле js_y

aaa

bbb

ccc

2010;2011;2012

ddd

eee

fff

2011;2012



Поле 1

Поле 2

Поле 3

Поле js_y

aaa

bbb

ccc

2010

aaa

bbb

ccc

2011

aaa

bbb

ccc

2012

ddd

eee

fff

2011

ddd

eee

fff

2012

Рис. 4.10 Преобразование «Split field to rows»

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

Далее с помощью элемента «Modified Java Script Value» для каждой строки пересчитываются значения рисков и оценочной стоимости. Для этого высчитывается общая продолжительность этапа в месяцах (lenAll) и продолжительность этапа в текущем году (y):

var len = 0;//продолжительность этапа в текущем году y
var lenAll = 12*(year(end_date)-year(begin_date)-1) + 13 - month(begin_date) + month(end_date);//общая продолжительность этапа (в месяцах)
var koef = 1;
if (year(begin_date)==y){

len = 12 - month(begin_date);

}else if (year(end_date)==y){

len = month(end_date) + 1;

} else{

len = 12;

}
koef = len/lenAll;
var new_cost_estimation = cost_abs_estimation*koef;//оценочная стоимость этапа

var new_risk_loss = risk_loss*koef;//ожидаемый ущерб от срыва этапа

var new_risk_failure_percent =

java.lang.Math.pow(risk_failure_percent,koef);//вероятность срыва этапа



var new_id = work_stage_id + "_" + y;//формируем новый идентификатор

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

На следующем шаге этапа происходит преобразование значения года (y) из строкового представления в числовое (y2):

var y2 = java.lang.Integer.valueOf(y);

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

На последнем этапе происходит запись информации в таблицу фактов work_fact OLAP-хранилища данных, причём необходимо явно указать соответствие полей, т.к. поля, используемые на данном этапе, отличаются от полей в таблице фактов:

Таблица 4.4

Соответствие между полями таблиц


Поля таблицы фактов

Поля, используемые на данном этапе

work_stage_id

work_stage_id

customer_id

customer_id

risk_failure_percent

new_risk_failure_percent

cost_estimation

new_cost_estimation

risk_loss

new_risk_loss

year

y2

id

new_id

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

  • count – количество элементов;

  • distinct-count – количество уникальных элементов;

  • sum – сумма всех элементов;

  • max – максимальное значение;

  • min – минимальное значение;

  • avg – среднее значение элементов.

Рассмотрим основные этапы решения возникшей проблемы:

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

  2. Корректировка исходного кода Mondrian сервера.

  3. Сборка исправленной версии Mondrian.

  4. Использование созданной функции в кубе.

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

CREATE AGGREGATE name (

BASETYPE = input_data_type,

SFUNC = sfunc,

STYPE = state_data_type

[ , FINALFUNC = ffunc ]

[ , INITCOND = initial_condition ]), где:


  • input_data_type – тип входных данных;

  • state_data_type – тип временной переменной, хранящей значение агрегирующей функции на каждой итерации;

  • sfunc – функция, вызываемая на каждой итерации;

  • ffunc – функция, вызываемая после выполнения последней итерации;

  • initial_condition – начальное значение промежуточной переменной.

Формат используемых функций следующий:

sfunc( internal-state, next-data-item ) ---> next-internal-state

ffunc( internal-state ) ---> aggregate-value

Функция sfunc() принимает на вход уже сосчитанное промежуточное значение и значение следующего элемента. Данная функция описывает основное преобразование над исходным набором значений. В разрабатываемом кубе функция sfunc() перемножает элементы.

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

В разрабатываемом кубе создаётся следующая агрегирующая функция prob_aggr, перемножающая входящий набор элементов:

CREATE AGGREGATE prob_aggr (

BASETYPE = double precision,

SFUNC = s_multiplication,

STYPE = double precision

), где s_multiplication – это функция, перемножающая два входных параметра:

CREATE FUNCTION s_multiplication(double precision, double precision)

RETURNS double precision AS

$BODY$


BEGIN

RETURN $1*$2;

END;

$BODY$ LANGUAGE 'plpgsql'



После создания собственной агрегирующей функции необходимо доработать OLAP-сервер Mondrian так, чтобы он вызывал данную функцию. Mondrian имеет открытый исходный код, написанный на Java. mondrian.rolap.RolapAggregator – класс, отвечающий за вызов агрегирующих функций. В данном классе имеется перечисление (enum), хранящее список 6 предопределённых агрегирующих функций. Необходимо в это перечисление добавить созданную агрегирующую функцию (см. прил. 2):

public static final EnumeratedValues enumeration =

new EnumeratedValues(

new RolapAggregator[]{Sum, Count, Min, Max, Avg, DistinctCount, Prob});

Следующий шаг – это сборка проекта OLAP-сервера. Для сборки используется среда разработки Intellij IDEA 9.1. Собранный OLAP-сервер представляет собор war-файл, который в дальнейшем помещается в веб-сервер (контейнер-сервлетов) Apache Tomcat 6.0.20.

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


4.2.2 Настройка OLAP-сервера


OLAP-сервер Mondrian поставляется как веб-приложение в виде WAR-файла, помещаемого в веб-сервер Apache Tomcat. Настройка сервера заключается в указании XML-файла конфигурации многомерных кубов, а также настроек подключения к OLAP-хранилищу данных. Эта информация содержится в файле datasources.xml:

Jdbc = jdbc:postgresql://192.168.77.156/risks;

JdbcDrivers = org.postgresql.Driver;

JdbcUser = risks;

JdbcPassword = risks;

Catalog = /WEB-INF/Risks.mondrian.xml



В параметре Jdbc указывается URL для подключения к базе данных, содержащий ip-адрес сервера СУБД и название схемы БД. Параметр JdbcDriver указывает на используемый для подключения JDBC-драйвер, по умолчанию, для PostgreSQL это org.postgresql.Driver. Параметры JdbcUser и JdbcPassword содержат данные для авторизации пользователя в СУБД. Параметр Catalog указывает на путь к XML-файлу, содержащему описания многомерных кубов. Содержимое файла Risks.mondrian.xml приведено в прил. 3.

После настройки OLAP-сервера он готов к работе. Для начала работы сервера необходимо запустить веб-сервер Apache Tomcat. Для получения доступа к OLAP-серверу по протоколу XMLA используется URL вида http://имя_сервера:порт/mondrian/xmla, где имя_сервера и порт – соответственно имя компьютера и порт, на котором запущен Apache Tomcat.

4.2.3 Подключение OLAP-клиента


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

  • выполнение всех операций над многомерными данными: срезы, детализация/обобщение, поворот и др.;

  • фильтрация входящих данных – возможность выбора собственного набора измерений, а также скрытие любых колонок и строк в таблице;

  • сохранение и печать полученных отчётов;

Основным элементом интерфейса JPalo Pivot является динамическая таблица, значения ячеек которой определяются соответствующим набором измерений, используемых аналитиком. Весь набор измерений представлен в виде объектов, находящихся в верхней части экрана. Каждый объект имеет заголовок – название измерения и кнопку вызова фильтра, в котором аналитик может настраивать иерархии, используемые в измерении. Переносом объектов с помощью мыши (drag’n’drop) можно добавлять в таблицу используемые измерения.

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

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

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

JPalo, также как и Mondrian, поставляется в виде WAR-файла, помещаемого в веб-сервер Apache Tomcat. Настройка JPalo заключается в указании URL к OLAP-серверу, работающему по протоколу XMLA.

Рассмотрим подключение клиента в СППР РЭП. Система СППР РЭП является веб-приложением написанным с использованием технологии Grails. Grails — программный каркас для создания веб-приложений, написанный на скриптовом языке Groovy, который в свою очередь основан на Java. Grails основан на шаблоне «Модель-Вид-Контроллер» (MVC) [4]. Grails — это современная инфраструктура для разработки веб-приложений, который соединяет такие Java-технологии, как Spring и Hibernate, с современными подходами, такими как соглашения о конфигурации. Grails может работать с Apache Tomcat, JBoss или любым другим веб-сервером, поддерживающим сервлеты [4]. Для разработки и отладки используется встроенный в Grails веб-сервер Jetty. В качестве сервера базы данных поддерживаются MySQL, Firebird, PostgreSQL, IBM DB2, Oracle и Microsoft SQL Server. Также поддерживается встраиваемая база данных SQLite.

СППР РЭП, как и любое Grails-приложение, имеет следующую структуру (рис. 4.11):

Рис. 4.11 Структура проекта СППР РЭП



  • в каталоге conf содержатся файлы конфигурации приложения;

  • в каталоге controllers содержатся Groovy-классы, представляющие собой контроллеры шаблона Model-View-Controller;

  • в каталоге domains содержатся Groovy-классы, представляющие собой сущности, которые в совокупности со связями между собой, образуют модель шаблона Model-View-Controller;

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

  • в каталоге taglib располагаются пользовательские теги для GSP-страниц;

  • в каталоге views находятся GSP-страницы – представление в шаблоне Model-View-Controller.

GSP-страницы – это динамически формируемые на стороне сервера веб-страницы, использующие синтаксис языка Java и Groovy. Для подключения визуализатора JPalo необходимо создать GSP-страницу olap.gsp, в которую будет встроен OLAP-клиент. На страницу вставляется HTML-тэг IFRAME, который отображает дополнительное окно с веб-страницей. Созданная GSP-страница помещается в папку views. Остановимся подробнее на тэге IFRAME. Ниже приведён фрагмент GSP-кода, подключающего JPalo Pivot на страницу (исходный код GSP-страницы приведён в прил. 4):

В данном коде, используется переменная paloUrl, формируемая в контроллере (используется модель MVC) и задающая URL к JPalo Pivot.

Для подключения OLAP-клиента использовалась среда для разработки Intellij IDEA 9.1, т.к.:


  1. Intellij IDEA полностью поддерживает язык Groovy, включая отладку и рефакторинг Groovy-кода.

  2. Intellij IDEA поддерживает технологию Grails, тем самым ускоряя разработку Grails-приложений.



<< предыдущая страница   следующая страница >>
Смотрите также:
Диссертация посвящена вопросу оперативного многомерного анализа данных (olap) в системах поддержки принятия решений (сппр). Рассматривается класс систем, учитывающих для формирования оптимальных решений изменяемые с течением времени факторы
945.67kb.
7 стр.
«модели представления времени и их применение в интеллектуальных системах»
44.04kb.
1 стр.
На выполнение работ по созданию информационной системы поддержки оперативного принятия решений на основе цифровых ситуационных карт шельфовых проектов
115.71kb.
1 стр.
Программа «Методы анализа и синтеза проектных решений»
26.32kb.
1 стр.
Трехуровневая модель планирования и принятия решений
586.19kb.
5 стр.
Представленная Соколовой Татьяной Петровной диссертация
28.8kb.
1 стр.
Разработка программных средств для интерактивного анализа публикаций на основе olap-технологии
27.73kb.
1 стр.
Теоретические особенности принятия управленческого решения 2 1 Роль и место принятия решений в процессе управления 2
441.69kb.
2 стр.
Маркетинговые информационные системы
187.16kb.
1 стр.
Перспективы создания информационной системы поддержки принятия решений абитуриентами Г. И. Болтунов, А. Л. Лымарь
30.16kb.
1 стр.
Технология принятия управленческих решений
1188.33kb.
7 стр.
Лабораторная работа №5 «Анализ оптимального решения в условиях риска и неопределенности» Задание на лабораторную работу
253.42kb.
1 стр.