Титульник

Титульник ТЗ 2 Аннотация Диссертация посвящена вопросу оперативного многомерного анализа данных (OLAP) в системах поддержки принятия решений (СППР). Рассматривается класс систем, учитывающих для формирования оптимальных решений изменяемые с течением времени факторы (оценки, риски, вероятности и др.). В работе исследуются классические подходы построения подсистем многомерного анализа и выявляются их недостатки при применении к СППР рассматриваемого класса. Автор диссертации предлагает модифицированный подход построения подсистем многомерного анализа данных в СППР, учитывающий недостатки классических подходов. Предложенный подход реализуется и тестируется в СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ. Abstract This paper is devoted to online multidimensional data analysis (OLAP) in decision support systems (DSS). Paper is focused on the class of DSS that use estimations, risks and probabilities for making correct decisions. The first chapter is research of classic OLAP-system design approaches. There are some lacks in these approaches applied to the DSS of considering class. The author offers a modified approach to OLAP-system design that can be applied to the DSS of considering class. The next chapter is devoted to describing of offered approach. And the last one is about implementing and testing on the DSS that used in the Ministry of Industry and Trade. 3 Оглавление Список сокращений, используемых в работе....................................................... 6 Введение ................................................................................................................... 7 1. Аналитический обзор .......................................................................................... 9 1.1 Оперативный анализ данных (OLAP) ......................................................... 9 1.1.1 Подходы к построению OLAP-систем ............................................... 14 1.1.2 Хранилища данных, используемые в OLAP-системах .................... 17 1.1.3 Многомерная модель данных в OLAP-анализе ................................ 19 1.1.4 Подходы к реализации многомерной модели данных ..................... 23 1.1.5 Классификация OLAP-систем по способу хранения данных .......... 26 1.2 Системы поддержки принятия решений .................................................. 27 1.2.1 Применение многомерного анализа данных в СППР ...................... 28 1.2.2 Особенности СППР, учитывающих риски предприятий ................. 29 1.2.3 Недостатки существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих риски предприятий ................................................................................................... 30 1.3 Выводы ......................................................................................................... 30 2. Описание предложенного подхода.................................................................. 31 2.1 Предлагаемый подход к построению подсистемы многомерного анализа данных в СППР, учитывающих особенности изменяемых во времени факторов .............................................................................................. 31 2.2 Архитектура подхода .................................................................................. 32 2.3 Достоинства подхода .................................................................................. 34 2.4 Выводы ......................................................................................................... 34 4 3. Реализация предложенного подхода ............................................................... 35 3.1 Выбор OLAP-сервера .................................................................................. 35 3.1.1 Сравнительный анализ существующих OLAP-серверов ................. 37 3.2 Выбор хранилища данных.......................................................................... 48 3.3 Выбор модуля преобразования и загрузки данных ................................. 50 3.4 Выбор OLAP-клиента ................................................................................. 52 3.4.1 Сравнительный анализ существующих OLAP-клиентов................. 53 3.5 Выводы ......................................................................................................... 55 4. Апробация предложенного подхода ............................................................... 56 4.1 Обзор СППР для департамента РЭП Минпромторга .............................. 56 4.2 Реализация подсистемы многомерного анализа данных в СППР для департамента РЭП Минпромторга .................................................................. 59 4.2.1 Разработка хранилища данных и многомерных OLAP-кубов......... 59 4.2.2 Настройка OLAP-сервера .................................................................... 79 4.2.3 Подключение OLAP-клиента .............................................................. 80 4.3 Анализ качества ........................................................................................... 83 4.4 Выводы ......................................................................................................... 86 Заключение ............................................................................................................ 87 Список литературы ............................................................................................... 88 Приложения ........................................................................................................... 89 5 Список сокращений, используемых в работе OLAP — совокупность концепций, принципов и требований, лежащих в основе программных продуктов, обеспечивающих сбор, хранение, манипулирование и оперативный анализ многомерных данных. OLTP — обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа. СППР — система поддержки принятия решений. РЭП — радиоэлектронная промышленность. СППР РЭП — система департамента поддержки принятия радиоэлектронной решений для промышленности Министерства промышленности и торговли РФ. Минпромторг — Министерство промышленности и торговли РФ. ФЦП — Федеральная целевая программа. Хранилище данных — (ХД) предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью решений в организации. 6 поддержки принятия Введение Современные условия ведения бизнеса, характеризующиеся возрастающей жесткой конкуренцией и нестабильностью экономических условий, предъявляют повышенные требования к оперативности и качеству принимаемых решений на всех уровнях управления предприятием или организацией. При этом объем информации, которую необходимо учитывать для формирования оптимальных обоснованных решений, неуклонно растет. Это приводит к ситуации, когда становится невозможно эффективно управлять компанией без использования современных средств информационного обеспечения. За последние 20 лет информационно-аналитические системы меняли свои названия и содержание, пройдя путь от информационных систем руководителя (executive information systems, EIS) до систем поддержки принятия решений (СППР). Современные СППР строятся на основе технологий, позволяющих пользователю-непрограммисту легко и оперативно извлекать информацию из различных источников, формировать собственные настраиваемые отчеты или графические представления, проводить многомерный анализ данных. Разнообразие этих технологий принято объединять термином «бизнесаналитика» или Business Intelligence (BI). Развитие систем бизнес-аналитики прошло путь от «толстых» клиентов до Web-приложений, в которых пользователь ведет исследование с помощью браузера и может работать удаленно. Цель технологий BI - своевременно принимать решения, основываясь на корректных данных. Сегодня создание и внедрение BI технологий сформировалось в самостоятельное динамично развивающееся направление индустрии информационных технологий. 7 Целью выпускной квалификационной работы является выбор подхода построения подсистем многомерного анализа данных для СППР, учитывающих риски предприятий, и его применение в СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ. Для достижения поставленной цели необходимо сформулировать и решить следующие задачи: 1. Исследовать существующие подходы к построению подсистем многомерного анализа данных. 2. Разработать архитектуру подсистем многомерного анализа данных для СППР, учитывающих риски предприятий. 3. Реализовать подсистему многомерного анализа данных в СППР для департамента радиоэлектронной промышленности Минпромторга. Объектом исследования является класс СППР, учитывающих для формирования оптимальных обоснованных решений изменяемые с течением времени факторы (оценки, риски, вероятности и др.). Предметом исследования является технология оперативного многомерного анализа данных (OLAP), применяемая в СППР. Новизна работы состоит в обосновании и использовании нового подхода для построения подсистем многомерного анализа данных в СППР, учитывающих изменяемые с течением времени факторы. Практическая значимость работы заключается в реализации предложенного подхода в СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ. 8 1. Аналитический обзор 1.1 Оперативный анализ данных (OLAP) OLAP (Online Analytical Processing) — это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, обеспечивающих сбор, хранение, манипулирование и анализ многомерных данных. Термин OLAP был предложен доктором Е.Ф. Коддом, его супругой С.Б. Кодд и их коллегой С.Т. Солли в исследовательской статье "OLAP для пользователей-аналитиков: информационно-технологический мандат". Эта статья была опубликована в начале 1993 года и спонсировалась корпорацией Arbor Software, создателем и распространителем первого OLAP-продукта Essbase. Статья определяет OLAP как «имя, данное динамическому анализу предприятия, необходимому для создания, манипулирования, оживления и синтезирования информации на базе "моделей информации о предприятии" ("Enterprise Data Models")». Основная цель оперативного анализа данных — проверка аналитиками возникающих гипотез. Аналитики являются особыми потребителями корпоративной информации, задача которых находить закономерности в больших массивах данных и делать выводы о текущем состоянии бизнеса. Данные, которые требуются аналитику для работы, обязательно содержат числовые значения, что обусловлено самой сущностью его деятельности. Оперативность в современном бизнесе — один из факторов успеха. Аналитику нужен такой инструмент, который позволил бы визуализировать данные быстро, просто и удобно. В качестве такого инструмента и выступает OLAP. 9 В 1993 году Кодд сформулировал «12 принципов аналитической обработки в реальном времени» [8] (см. табл. 1.1): Таблица 1.1 Принципы аналитической обработки в реальном времени № Принцип 1 Многомерное представление Средства данных Описание должны поддерживать многомерный на концептуальном уровне взгляд на данные. 2 Прозрачность Пользователь не должен знать о том, какие конкретные средства используются обработки для хранения данных, как и данные организованы и откуда они берутся. 3 Доступность Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником Средства должны автоматическое данных. обеспечивать отображение их собственной логической схемы в различные гетерогенные источники данных. 4 Согласованная Производительность практически не производительность должна зависеть от количества Измерений в запросе. 5 6 Поддержка архитектуры клиент- Средства должны работать в сервер архитектуре клиент-сервер. Равноправность всех измерений Ни одно из измерений не должно 10 быть базовым, все они должны быть равноправными (симметричными). 7 Динамическая обработка Неопределенные значения должны разреженных матриц храниться и обрабатываться наиболее эффективным способом. 8 Поддержка Средства многопользовательского обеспечивать режима возможность работать более чем работы с данными 9 должны одному пользователю. Поддержка операций на основе Все различных измерений многомерные (например, операции агрегация) единообразно и должны согласованно применяться к любому числу любых измерений. 10 Простота манипулирования Средства данными должны иметь максимально естественный удобный, и комфортный пользовательский интерфейс. 11 Развитые средства представления Средства данных должны поддерживать различные способы визуализации (представления) данных. 12 Неограниченное число измерений Не должно быть ограничений на и уровней агрегации данных число поддерживаемых измерений. В 1995 году на основе принципов, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие оперативного анализа данных [2]: 11 требования к приложениям  предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;  возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;  многопользовательский соответствующих доступ механизмов к данным с блокировок поддержкой и средств авторизованного доступа;  многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP);  возможность обращаться к любой нужной информации независимо от ее объема и места хранения. Большинство из существующих OLAP-средств удовлетворяют всем этим требованиям. Однако в реализации подобных приложений возникает ряд проблем, прежде всего связанных с увеличением объёма данных, которые необходимо хранить. В настоящее время встречаются следующие применения OLAP:  Анализ данных. Задача, для которой изначально использовались и до сих пор остаются самыми популярными OLAP-средства. Многомерная модель данных, возможность анализировать значительные объёмы данных и быстрый отклик на запросы делают подобные системы незаменимыми для анализа продаж, маркетинговых мероприятий, дистрибуции и других задач с большим объёмом исходных данных. Примеры продуктов: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, 12 Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy, Business Objects.  Финансовое планирование\бюджетирование. Многомерная модель позволяет одновременно вводить данные и легко анализировать их (например, план-факт анализ). Поэтому ряд современных продуктов класса CPM (Corporate Performance Management) используют OLAP-модели. Важная задача – многомерный обратный расчёт (back-solve, breakback, writeback), позволяющий рассчитать требуемые изменения детальных ячеек при изменении агрегированного значения. Это инструмент для анализа «что-если» (what-if), т.е. для проигрывания различных вариантов событий при планировании. Примеры продуктов: Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac.  Финансовая консолидация. Консолидация данных согласно международным стандартам учёта, принимая во внимание доли владения, различные валюты и внутренние обороты – актуальная задача в связи с ужесточающимися требованиями проверяющих органов (SOX, Basel II) и выходом компаний на IPO (Initial Public Offering — первая публичная продажа акций частной компании). OLAP-технологии позволяют ускорить расчёт консолидированных отчётов и повысить прозрачность всего процесса. Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller. 13 1.1.1 Подходы к построению OLAP-систем По аналогии с подходами построения клиент-серверных систем выделяют два подхода к построению OLAP-систем: 1. Подход, основанный на двухзвенной архитектуре (рис. 1.1). 2. Подход, основанный на трёхзвенной архитектуре (рис. 1.2). Рис. 1.1 Двухзвенная архитектура построения OLAP-систем Рис. 1.2 Трёхзвенная архитектура построения OLAP-систем OLAP-система, построенная на двухзвенной архитектуре, состоит из хранилища данных, настольной OLAP-системы и сетью передачи данных между ними. Хранилище данных является источником входных данных для анализа. Структуры данных хранилища специальным образом оптимизированы (см. подразд. 1.1.4) для уменьшения времени обработки запросов, посылаемых настольной OLAP-системой. Настольная OLAPсистема вычисляет и отображает анализируемые данные. OLAP-система, построенная на трёхзвенной архитектуре, состоит из хранилища данных, OLAP-клиента, OLAP-сервера и сетью передачи данных 14 между ними. Хранилище данных играет туже роль, что и в двухзвенной архитектуре. В отличие от предыдущего подхода, выделяются OLAP-сервер, отвечающий за вычисления анализируемых данных, и OLAP-клиент, отображающий анализируемые данные. Исходные данные для анализа, находящиеся в хранилище, могут поступать из различных источников данных, таких как оперативные (OLTP) БД, таблицы Microsoft Excel, XML-документы и др. Эти данные поступают в хранилище с определённой периодичностью (например, еженедельно или ежедневно — в зависимости от потребностей), поэтому на момент анализа могут быть не актуальными. С одной стороны, это не является проблемой, когда аналитик просматривает данные, за прошедший период времени, т.к. аналитик не обращает внимания на отдельно взятые факты — ему необходима суммарная информация о сотнях и тысячах событий. Но с другой стороны, это может вызывать проблему при планировании, т.к. выбор того или иного решения зависит от текущей ситуации, которая может изменяться несколько раз в течение одного дня (см. подразд. 1.2.2). Сравним данные подходы по эксплуатационным и стоимостным показателям: 1. Объем обрабатываемых данных. Объем данных определяется предметной областью анализируемых данных, а также количеством записей в хранилище данных. Как и настольная OLAP-система, так и OLAP-сервер, вынуждены кешировать данные в оперативной памяти для уменьшения количества запросов к хранилищу данных. Таким образом, объем данных, обрабатываемых настольной OLAP-системой и OLAP-сервером, находится в прямой зависимости от объема оперативной памяти. У серверов объём оперативной памяти больше, чем у пользовательских ПК, поэтому OLAP-сервер может обрабатывать большие объемы данных, чем настольная OLAP-система. 15 2. Производительность системы. Эта характеристика определяется следующими факторами: объемом обрабатываемых данных и мощностью компьютеров. При возрастании количества входных анализируемых снижается за данных счет производительность значительного всех увеличения OLAP-систем количества высчитываемых суммарных значений, но при этом темпы снижения разные. Продемонстрируем эту зависимость на графике (рис. 1.3): Рис. 1.3 Зависимость времени отклика OLAP-системы от объема обрабатываемых данных Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и настольной OLAP-системой. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки", в то время как настольная OLAP-система вычисляет весь набор суммарных значений в момент загрузки. 3. Сетевой трафик. При использовании OLAP-сервера по сети на ПК OLAP-клиента передаются только данные для отображения, в то время как настольная OLAP-система получает весь объем данных первичной 16 выборки. Поэтому там, где применяется настольные OLAP-системы, сетевой трафик будет выше. Но, при применении OLAP-сервера операции пользователя, например детализация, порождают новые запросы к многомерной базе, а, значит, новую передачу данных. Выполнение же OLAP-операций настольной OLAP-системой производится в оперативной памяти и, соответственно, не вызывает новых потоков данных в сети. Также необходимо отметить, что современное сетевое оборудование обеспечивает высокий уровень пропускной способности. 4. Затраты на внедрение и сопровождение. Стоимость OLAP-сервера достаточно высока. Дополнительно следует учитывать стоимость выделенного сервера и постоянные затраты на администрирование хранилища данных. Кроме того, внедрение и сопровождение OLAPсервера требует от персонала достаточно высокой квалификации. Стоимость настольной OLAP-системы на порядок ниже стоимости OLAP-сервера. Администрирования и дополнительного технического оборудования для настольной OLAP-системы не требуется. К квалификации персонала при внедрении настольных OLAP-систем высоких требований не предъявляется. Настольная OLAP-система может быть внедрена значительно быстрее OLAP-сервера. Таким образом, использование трёхзвенной архитектуры предпочтительнее при больших объемах исходных данных и небольшой скорости сети передачи данных. 1.1.2 Хранилища данных, используемые в OLAP-системах Хранилище данных – обязательная составляющая любой OLAPсистемы. В хранилище содержатся исходные данные для анализа. Хранилище данных (англ. Data Warehouse) — очень большая предметно-ориентированная информационная корпоративная база данных, 17 специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации. Строится на базе клиент-серверной архитектуры, реляционной СУБД и утилит поддержки принятия решений. Данные, поступающие в хранилище данных, обычно становятся доступны только для чтения. Данные из промышленной OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы промышленной системы и не нарушал её стабильность. Существуют два архитектурных направления построения хранилищ данных – нормализованные хранилища данных и размерностные хранилища. В нормализованных хранилищах, данные находятся в предметно ориентированных таблицах третьей нормальной формы. Нормализованные хранилища характеризуются как простые в создании и управлении, недостатки нормализованных хранилищ – большое количество таблиц как следствие нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих таблиц одновременно, что приводит к ухудшению производительности системы. Размерностные хранилища используют ненормализованные структуры данных (см. подразд. 1.1.4), что увеличивает размер базы данных, но уменьшает время обработки запросов на выборку данных вследствие меньшего использования соединений таблиц. Основным достоинством размерностных хранилищ является простота и понятность для разработчиков и пользователей, также, благодаря более эффективному хранению данных и формализованным размерностям, облегчается и ускоряется доступ к данным, особенно при сложных анализах. Основным недостатком является более сложные процедуры подготовки и загрузки данных, а также управление и изменение размерностей данных. 18 Для OLAP-анализа используется второй тип хранилищ – размерностные хранилища. 1.1.3 Многомерная модель данных в OLAP-анализе Преимущество использования OLAP-анализа — это оперативность обработки запросов, поступающих от аналитика в процессе его работы. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. Более хорошей моделью для запросов, а не для изменения, является многомерная (нередко называемая пространственной) модель данных [7]. Многомерная модель данных — это расширение реляционной модели. В отличие от реляционной модели, где основным понятием является «отношение», в многомерной модели основным понятием является многомерный «куб» (нередко называемый также OLAP-кубом), который является обобщением реляционных таблиц на любое число измерений. Набор соответствующих кубов составляет многомерную базу данных. Многомерная модель данных не рассчитана на частое выполнение транзакций, но очень удобна именно для анализа больших массивов данных. Она наиболее адекватна представлениям о предметной области, которыми оперирует аналитик. Некоторые преимущества многомерной модели по сравнению с реляционной [7]:  Возможность анализа больших объемов данных с приемлемой скоростью;  Возможность осуществления любых «срезов» и «углублений» в определённой структуре БД; 19  Быстрая локализация трендов и проблемных областей. Многомерный куб представлен набором мер и измерений, а именно, куб — это декартовое произведение измерений, где для каждого элемента произведения проставлен набор мер. Измерения куба – набор доменов, по которым создаётся многомерное пространство. Другими словами, измерение – это упорядоченный набор значений, соответствующий грани куба. Многомерное моделирование предусматривает использование измерений для предоставления максимальной информативности [3]. В отличие от реляционных баз данных, контролируемая избыточность в многомерных базах данных считается оправданной, если она увеличивает информационную ценность. Измерения используются для выбора и агрегирования данных на требуемом уровне детализации. Измерения организуются в иерархию, состоящую из нескольких уровней, каждый из которых представляет уровень детализации, требуемый для соответствующего анализа. Многомерная модель данных предназначена для анализа информации. Единицей анализируемой информации считается когда-либо произошедший факт, т.е. факты представляют субъект — некий шаблон или событие, которые необходимо проанализировать. В большинстве многомерных моделей данных факты однозначно определяются комбинацией значений измерений. Факт существует только тогда, когда ячейка для конкретной комбинации значений не пуста. гранулярностью, определенной Каждый факт обладает некоторой уровнями, из которых создается их комбинация значений измерений. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:  факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами 20 которых являются телефонный звонок или снятие денег со счета с помощью банкомата);  факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;  факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);  факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Мера (или показатель) – это определяется фиксированным значение, набором которое измерений и однозначно количественно характеризует анализируемые факты. Меры бывают трёх типов:  аддитивные (additive) меры – допускающие агрегирование относительно любого измерения куба данных;  неаддитивные (nonadditive) меры – которые не могут агрегироваться ни по какому измерению куба данных;  полуаддитивные (semiadditive) меры – которые допускают агрегирование относительно одних измерений и не допускают относительно других. Многомерная база данных естественным образом предназначена для определенных типов запросов: 21  Запросы вида slice и dice (срезы куба) — формирование подмножества многомерного массива данных, соответствующего единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Если рассматривать термин slice с позиции конечного пользователя, то наиболее часто его роль играет двумерная проекция куба (рис. 1.4). Срез dice отличается от slice тем, что это трёхи более-мерная проекция куба. Фиксированное значение Срез Рис. 1.4 Операция среза (slice)  Запросы вида drill-down (детализация) и roll-up (обобщение) — взаимообратные операции, которые используют иерархию измерений и меры для агрегирования. Направление детализации/обобщения может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями.  Запросы вида drill-across комбинируют кубы, которые имеют одно или несколько общих измерений. С точки зрения реляционной алгебры такая операция выполняет слияние (join).  Запросы вида ranking возвращают только те ячейки, которые появляются в верхней или нижней части упорядоченного определенным образом списка.  Поворот (rotating) куба дает пользователям возможность увидеть данные, сгруппированные по другим измерениям (рис. 1.5). Например, 22 операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид. Измерение1 Измерение2 Измерение2 Измерение1 Вращение Измерение3 Измерение3 Рис. 1.5 Операция вращения (rotating) Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации. 1.1.4 Подходы к реализации многомерной модели данных Многомерная структура хранения данных может быть реализована с помощью многомерных БД или в системе управления реляционными БД с использованием схемы звезды (star schema) или схемы снежинки (snowflake schema) [7]. Схема звезды (рис. 1.6) является реляционным воплощением многомерной представления данных. Она является проекцией куба на «реляционную плоскость» и состоит из одной таблицы фактов (fact table) и 23 нескольких таблиц измерений (dimension table). Таблица фактов содержит по одной строке для каждого факта — минимально рассматриваемого атома анализируемого процесса. Рис.1.6 Пример куба, построенного по схеме «Звезда» Полями таблицы фактов, помимо ключей, являются меры (measures), описывающие количественную характеристику факта. Таблицы измерений содержат собственно значения измерений, то есть информацию, характеризующую факты. Обычно это неизменяемые, либо редко изменяемые данные. Каждая таблица измерений находится в отношении «один ко многим» с таблицей фактов. Время является несколько особенным и практически необходимым измерением любого хранилища данных. Схема звезды не соответствует требованиям нормальной формы. С точки зрения нормализации таблицы измерений хранят избыточные данные. 24 Рис.1.7 Пример куба, построенного по схеме «Снежинка» Схема снежинки является модификацией схемы звезды — часть таблиц измерений разбита на несколько связанных таблиц (рис. 1.7). Благодаря частичной нормализации, «снежинка» позволяет сэкономить дисковое пространство, но она уменьшает скорость просмотра измерений. Решение в сторону использования схемы звезды или схемы снежинки, обуславливается относительной мощностью платформы БД, и инструментария для реализации запросов. Схема снежинки подходит окружению, в котором инструментарий реализации запросов предоставляет пользователям широкий доступ к структуре таблиц, а также в окружениях, где большинство запросов просты по своей природе. Схема звезды более подходит для случаев применения более сложного инструментария для реализации запросов, который в большей степени изолирует пользователей от детальной структуры таблиц, а также для среды с множеством запросов сложной структуры. 25 1.1.5 Классификация OLAP-систем по способу хранения данных И исходные и агрегатные (суммарные) данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP) [2]. Соответственно, OLAP-системы по способу хранения данных делятся на три аналогичные категории:  в случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе;  в ROLAP-системах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-системы;  в случае использования HOLAP архитектуры исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-системы на основе реляционных и многомерных данных. Сохранение всех агрегатных данных не всегда оправданно. При добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (говорят о «взрывном росте» объема данных). Степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов. Некоторые OLAP-системы поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако 26 большинство современных OLAP-систем поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. 1.2 Системы поддержки принятия решений Система поддержки принятия решений (СППР) (англ. Decision Support System, DSS) — компьютерная автоматизированная система, целью которой является помощь людям, принимающим решение в сложных условиях для полного и объективного анализа предметной деятельности [7]. СППР обладает следующими четырьмя основными характеристиками: 1. СППР использует и данные, и модели; 2. СППР предназначены для помощи менеджерам в принятии решений для слабоструктурированных и неструктурированных задач; 3. Они поддерживают, а не заменяют, выработку решений менеджерами; 4. Цель СППР — улучшение эффективности решений. Принятие решений предусматривает последовательное выполнение следующих шагов: осмысливание проблемы, диагностика, концептуальное или математическое моделирование, выработка альтернатив и выбор тех, которые в наибольшей степени удовлетворяют поставленным целям, а также мониторинг осуществления решения. Как правило, СППР имеют модульную структуру, что позволяет быстро включать новые методы анализа информации для принятия эффективных обоснованных решений. Это могут быть: информационный 27 поиск, интеллектуальный анализ данных, поиск знаний в базах данных, рассуждение на основе прецедентов, имитационное моделирование, эволюционные вычисления и генетические алгоритмы, нейронные сети, ситуационный анализ, когнитивное моделирование, многомерный анализ данных и др. 1.2.1 Применение многомерного анализа данных в СППР Многомерный анализ данных – это извлечение полезной информации из многомерной структуры данных посредством оперативного анализа (OLAP). Многомерный анализ данных является современным методом анализа данных в СППР для принятия эффективных обоснованных решений [9]. Многомерный анализ позволяет лицу, принимающему решение (ЛПР), делать срезы многомерных данных, высчитывать суммарные значения по любым измерениям, тем самым обеспечивая ЛПР любой интересующей информацией. Другими словами, многомерный анализ данных позволяет формировать любой отчёт без участия программистов и без знания языков запросов к базам данных. Большим преимуществом многомерного анализа данных по сравнению с другими способами анализа является автоматический подсчёт агрегатных (суммарных, средних и др.) значений. Таким образом, ЛПР может посмотреть любой интересующую его статистическую информацию за определённый промежуток времени. Многомерный анализ данных применяется только в СППР, ориентированных на работу с данными (Data-driven DSS) и имеющих большую базу исходных данных, накопленных за значительный период времени. 28 1.2.2 Особенности СППР, учитывающих риски предприятий Современные СППР для принятия обоснованных решений учитывают очень большое количество факторов, например, риски предприятий. Под рисками предприятий понимается вероятность успешного выполнения предприятием определённого задания и ожидаемый ущерб, нанесённый заказчику при срыве задания. Часть из всех факторов, рассматриваемых СППР, такие как риски, оценки, вероятности и др. могут изменяться с течением времени и, следовательно, СППР должна учитывать это. В теории менеджмента существует специальный подход к выбору оптимального решения в обстановке изменяемых во времени факторов – ситуационный подход [7]. Ситуация, в данном случае, – это состояние значений всех динамически изменяемых факторов в текущий момент времени. Ситуационный подход предполагает создание различных вариантов решений, каждое из которых пригодно в той или иной ситуации. Самым эффективным решением в конкретной ситуации является решение, которое более всего соответствует данной ситуации. Факторы, изменяемые в течение времени, накладывают ограничения на структуру хранилища данных СППР. Это связано с тем, что история изменения значений факторов не сохраняется в хранилище данных, т.к. предыдущее значение фактора становится неактуальным для СППР сразу же после изменения и не используется ею в дальнейшем. С другой стороны значения данных факторов могут изменяться очень часто (несколько раз в день), что приводит к пересчёту большого количества параметров, зависящих от данного фактора. Это приводит к тому, что часть хранилища данных нормализована и оптимизирована для обновления данных, а не для хранения. 29 1.2.3 Недостатки существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих риски предприятий Основным недостатком существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих изменяемые с течением времени факторы, в частности риски предприятий, является их неэффективность использования, т.к. часть хранилища данных, используемая СППР и подсистемой многомерного анализа, обязательно нормализована и оптимизирована для быстрого обновления, а не для анализа. 1.3 Выводы В данной главе была рассмотрена технология оперативного анализа данных – OLAP и её применение в системах поддержки принятия решений. OLAP – актуальная и востребованная тема исследований, её практические результаты имеют широкое применение. Несмотря на достаточно долгую историю исследований, до сих не существует единых терминологических стандартов, стандартов передачи данных, языка запросов и формирования кубов. Растущие объёмы корпоративных данных повышают значимость средств анализа, большая часть которых построена на OLAPпринципах, в связи с чем, актуальны проблемы выбора оптимальных схем хранения и обработки OLAP-кубов. Системы поддержки принятия решений используют технологию оперативного многомерного анализа данных для принятия эффективных обоснованных решений. Был рассмотрен класс СППР, учитывающих при выборе решений значения факторов, изменяемых с течением времени. Также были рассмотрены особенности и недостатки существующих классических подходов построения подсистем многомерного анализа данных для СППР этого класса. 30 2. Описание предложенного подхода 2.1 Предлагаемый многомерного подход анализа к данных построению в СППР, подсистемы учитывающих особенности изменяемых во времени факторов Принимая построению во внимание подсистем недостатки многомерного классических анализа данных подходов для к СППР, учитывающих изменяемые во времени факторы, автором ВКР был предложен улучшенный подход, устраняющий эти недостатки. Суть подхода заключается в добавлении нового хранилища данных (OLAP-хранилище), которое будет использоваться подсистемой многомерного анализа и будет полностью оптимизировано для анализа. Подход основывается на трёхзвенной архитектуре построения OLAP-систем (рис 2.1). Рис. 2.1 Предлагаемый подход к построению OLAP-системы При добавлении нового хранилища возникает проблема актуальности содержащихся в нём данных. Проблема решается путём вызова принудительного обновления данных в OLAP-хранилище в момент начала работы с подсистемой многомерного анализа. 31 2.2 Архитектура подхода Архитектура предлагаемого подхода представлена ниже (рис. 2.2). В левой части рисунка представлена архитектура подсистемы многомерного анализа данных, а в правой – типичная архитектура СППР. Рис. 2.2 Архитектура подхода Архитектура состоит из четырёх основных модулей и сетью передачи данных между ними: 1. OLAP-хранилище данных 2. Модуль преобразования и загрузки данных 3. OLAP-сервер 4. OLAP-клиент 32 OLAP-хранилище содержит исходные данные для анализа. Структура данных многомерна и оптимизирована специально для OLAP-анализа. Данные, находящиеся в хранилище, всегда актуальны для аналитика, работающего с подсистемой. Основная функция модуля преобразования и загрузки данных – это поддержка данных в хранилище в актуальном состоянии. Другая не менее важная функция – это преобразование данных. Структура данных хранилища СППР может кардинальным образом отличаться от многомерной структуры. Задача модуля – преобразовать данные из структуры СППР в многомерную структуру данных и загрузить их в OLAP-хранилище. Необходимо учесть, что данная операция выполняется каждый раз при начале работы пользователя с подсистемой, поэтому должна выполняться за приемлемое время. OLAP-сервер выполняется все операции по запросу многомерных данных, а также подсчитывает и хранит в оперативной памяти агрегатные (суммарные, средние и др.) значения. Необходимо отметить, что исходные данные для анализа – специфичны (риски, оценки, вероятности и др.), поэтому OLAP-сервер должен поддерживать возможность использования пользовательских функций для вычисления различных значений мер (в частности, пользовательские агрегирующие функции для подсчёта вероятностей). OLAP-клиент отображает полученные от OLAP-сервера данные в удобном для пользователя виде. Как OLAP-клиент, так и OLAP-сервер должны обмениваться информацией по единому унифицированному протоколу. При начале работы пользователя с системой OLAP-клиент уведомляет об этом модуль загрузки и преобразования данных. 33 OLAP-клиент может быть исполнен в виде настольного (desktop) приложения, либо в виде веб-приложения. Во втором случае в роли OLAPклиента выступают веб-браузер и веб-сервер. В зависимости от производительности серверов, на которых будет реализован подход, и вида OLAP-клиента, модули могут располагаться как на одном физическом сервере (в случае, когда в качестве OLAP-клиента выступает веб-приложение), так и на разных серверах. Все модули исполнены в виде функционально завершённых элементов, поэтому архитектура инвариантна к структуре исходных данных хранилища СППР и количеству создаваемых многомерных кубов для анализа. 2.3 Достоинства подхода Достоинства предлагаемого подхода:  ориентирован на уменьшение времени обработки запросов;  анализируемые данные всегда актуальны;  расширяемость OLAP-хранилища – возможность добавления новых кубов данных без модификации других модулей подсистемы. 2.4 Выводы В данной главе был предложен модифицированный подход к созданию подсистем многомерного анализа данных для СППР, учитывающих влияние изменяемых с течением времени факторов, основанный на классической трехзвенной архитектуре построения OLAP-систем. В подходе были учтены все недостатки классических подходов к построению OLAP-подсистем в СППР, учитывающих влияние изменяемых с течением времени факторов. Была предложена архитектура подсистемы, реализующей предложенный подход, состоящей из четырёх модулей и сетью передачи данных между ними. Также были перечислены достоинства предлагаемого подхода. 34 3. Реализация предложенного подхода 3.1 Выбор OLAP-сервера Основные требования, предъявляемые к OLAP-серверу: • возможность создания пользовательских функций для вычисления значений мер (в частности, создание пользовательских агрегирующих функций); • доступ OLAP-клиентов по унифицированному протоколу; • возможность добавления новых кубов; • широкий спектр поддерживаемых СУБД. На сегодняшний день существует множество поставщиков OLAPсерверов. Все крупные поставщики СУБД, такие как Oracle, Microsoft, IBM, Sybase, выпускают также и OLAP-сервера к своим СУБД. Помимо крупнейших производителей СУБД на рынке OLAP-продуктов фигурируют и другие компании, работающие в области Business Intelligence, такие как MicroStrategy, Pentaho, SAS Institute, Jedox. Все современные OLAP-серверы удовлетворяют принципам аналитической обработки в реальном времени, изложенным Коддом в 1993 году (см. подразд. 1.1), а позднее дополненными в 1995 году. Основными проблемами использования OLAP-серверов являются проблемы производительности, разреженности данных и «взрыва» данных. Проблема производительности связана к требованию к OLAP-продукту – времени отклика сервера (которое должно быть не более 5 секунд по тесту FASMI, см. подразд. 1.1). Объём анализируемых данных часто превышает миллионы записей, поэтому такое время сложно достичь. Данная проблема производителями решается по-разному, 35 но в основном, решения основываются на кешировании сосчитанных агрегатных (суммарных) значениях, либо на предварительном их вычислении и хранении в базе данных. Предварительное вычисление и хранения в БД агрегатных значений порождает новую проблему – проблему эффекта «взрыва данных», т.е. к резкому увеличению объёма хранимых данных. Это вызвано тем, что количество хранимых агрегатов растёт в экспоненциальной зависимости от числа измерений в кубе. Синдром взрыва может приводить к еще большим проблемам при разреженном распределении исходных данных по многомерному кубу. Отсутствующие или недопустимые значения данных создают разрежение в модели данных OLAP. Наиболее удачные OLAPсерверы борются с этой проблемой, не сохраняя пустые значения, таким образом, даже плохо заполненные кубы «не раздуваются» в объеме. Все современные OLAP-серверы могут работать одновременно с несколькими кубами, поддерживать работу с большим числом измерений, мер и иерархий. Некоторые продукты поддерживают несколько иерархий для измерения, несбалансированные иерархии, полуаддитивные меры и некоторые другие функции, такие как «write-back», позволяющую аналитику изменить любое значение в таблице-отчёте, посмотреть к каким последствиям оно приведёт и при необходимости сохранить новое значение в хранилище данных. У каждого сервера есть свои протоколы обмена информацией и языки запросов к многомерным данным – в области OLAP на данный момент не существует каких-либо стандартизованных протоколов обмена информацией. Но при этом почти каждый сервер поддерживает стандарты «де факто» обмена информацией – XMLA (XML for Analysis) и языка запросов к многомерным данным фирмы Microsoft Expressions). 36 – MDX (Multidimensional Для выбора удовлетворяющего OLAP-сервера, заявленным требованиям, было принято решение провести сравнительный анализ наиболее известных серверов. 3.1.1 Сравнительный анализ существующих OLAP-серверов В виду достаточно большого количества производителей OLAPсерверов было принято решение рассмотреть только наиболее известные и долго работающие на рынке фирмы, а также ряд бесплатных продуктов. Таким образом, были выбраны следующие продукты (табл. 3.1): Таблица 3.1 Исследуемые OLAP-сервера № Фирма-производитель Название OLAP-сервера 1 Microsoft Analysis Services 2 Oracle Essbase 3 IBM Cognos TM1 4 Pentaho Mondrian 5 Jedox Palo Для исследования возможностей и сравнения OLAP-серверов необходимо определить критерии, по которым данные продукты можно сравнивать. Выбор критериев сравнения серверов происходил на основании требований, предъявляемых к OLAP-серверу, а также некоторых характеристик, влияющих на быстродействие сервера, гетерогенность и безопасность среды, в которой работает сервер. Таким образом, были выбраны следующие критерии: 1. Список поддерживаемых СУБД. 37 2. Список поддерживаемых форм хранения данных (MOLAP/ROLAP/HOLAP). 3. Возможность создания вычисляемых меток. С помощью вычисляемых меток можно включать в многомерную базу меры, которых нет в исходных данных, но которые можно вычислить по формуле. 4. Возможность создания пользовательских агрегирующих функций. Агрегирующие функции – функции, вычисляющие суммарный результат, например сумма значений, среднее значение, количество элементов и др. Помимо стандартных агрегирующих функций, необходимо предусмотреть возможность создания пользовательских функций, вычисляющих агрегирующее значение по определённой формуле. 5. Оптимизация схемы агрегирования, т.е. возможность изменения количества вычисленных заранее агрегирующих значений (агрегатов). Чем больше агрегатов хранится в готовом виде, тем выше производительность системы и тем меньше среднее время ответа на запрос. В то же время, увеличение количества хранимых агрегатов приводит к увеличению объема хранимых данных. Возможность сохранять только те агрегаты, которые наиболее часто используются в запросах пользователей, позволяет получить наименьший объем хранилища данных при максимальной производительности для наиболее популярных запросов к БД. Поэтому данный критерий достаточно важен при выборе OLAPсервера. 6. Масштабируемость и расширяемость. Масштабируемость – возможность работы с различными объемами данных: от очень маленьких (менее 10 тыс. записей) до очень больших (более 1 млн. записей) без изменения состава 38 программного продукта. Расширяемость – возможность добавления новых многомерных кубов данных без изменения состава программного продукта. 7. Удобные средства создания кубов и администрирования. 8. Решение проблемы «взрыва данных». 9. Решение проблемы разреженности данных. 10. Список поддерживаемых API и языков запросов. Необходимо, чтобы API и язык запросов, используемые OLAP-сервером, поддерживались OLAP-клиентом. 11. Поддержка Unix-подобных операционных систем. 12. Документирование. OLAP-сервер должен иметь хорошую документацию для быстрого освоения продукта. 13. Цена продукта на минимальную конфигурацию. Проанализируем каждый продукт по предложенным критериям: 1) OLAP-сервер Microsoft Analysis Services Microsoft Analysis Services (MSAS) - часть Microsoft SQL Server, включающий в себя набор средств для работы с OLAP и интеллектуальным анализом данных. Последняя версия - Microsoft Analysis Services 2008. 1. MSAS поддерживает только одну СУБД - Microsoft SQL Server. 2. MSAS поддерживает все три вида хранения данных: MOLAP, ROLAP и HOLAP. 3. MSAS поддерживает создание отметить, что для этого вычисляемых меток. Следует предусмотрен удобный мастер, облегчающий создание вычисляемой метки и редактирования её формулы. 4. MSAS поддерживает создание пользовательских агрегирующих функций. 39 5. MSAS предусматривает оптимизацию схемы агрегирования. Используя Storage Design Wizard можно найти компромисс между быстродействием системы и размером хранимых на диске агрегатов. 6. MSAS поддерживает гибкую модель масштабирования, включающую оптимизацию хранения, компрессию данных и распределённые вычисления (т.е. часть вычислений можно перенести на клиент). 7. MSAS содержит множество различных «мастеров» и «дизайнеров» по созданию кубов, измерений, иерархий и администрированию. 8. Проблема «взрыва данных» в MSAS решена. 9. Проблема разреженности данных в MSAS также решена (посредством компрессии данных). 10. MSAS поддерживает спецификации OLE DB, ADO DB, XMLA. Язык запросов к многомерным данным – MDX. 11. MSAS может быть установлен только на ОС Windows совместно с Microsoft SQL Server. 12.MSAS очень подробно документирован. Документация на русском языке. 13. Стоимость SQL Server 2008 Workgroup Edition - 4000$. Следует отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 2) OLAP-сервер Oracle Essbase Oracle Essbase (в дальнейшем Essbase) – первый в мире OLAP-сервер. Данный сервер изначально создавался фирмой Hyperion как расширение электронных таблиц Lotus 1-2-3 и Microsoft Excel, но впоследствии в 2007 году Oracle купил Hyperion и переименовал продукт в Oracle Essbase. Последняя версия - Oracle Essbase V.11.1.2 1. Essbase поддерживает только свою СУБД – Oracle. 40 2. Essbase поддерживает 2 вида хранения данных: MOLAP и HOLAP. 3. Essbase поддерживает создание вычисляемых меток. Стоить отметить, что помимо обычных математических формул можно использовать процедурный язык программирования - PL/SQL. 4. Essbase поддерживает создание пользовательских агрегирующих функций, используя язык PL/SQL. 5. Essbase, так же как и MSAS, предусматривает гибкую оптимизацию схемы агрегирования. 6. Essbase поддерживает включающую гибкую кластеризацию, модель функции масштабирования, отказоустойчивости, оптимизацию хранения и компрессию данных. 7. Essbase содержит удобный графический интерфейс, напоминающий интерфейс Microsoft Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка. 8. Проблема «взрыва данных» в Essbase решена. 9. Проблема разреженности данных в Essbase также решена. 10. Essbase поддерживает API для языков Java, C, Visual Basic и спецификацию XMLA. Язык запросов к многомерным данным – MDX. 11. Essbase может быть установлен как на ОС Windows, так и на Unixподобную ОС. 12. Essbase, так же как и MSAS, очень подробно документирован. Документация на русском языке. 13. Стоимость Oracle Essbase V.11.1.2– 40 000 $ Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 41 3) OLAP-сервер IBM Cognos TM1 Изначально продукт разрабатывался фирмой Cognos, но в 2009 году Cognos была поглощена компанией IBM и продукт был переименован в IBM Cognos TM1. Основное отличие TM1 от предыдущих двух серверов заключается в том, что это запатентованный 64-разрядный OLAP-сервер, использующий подход In-memory OLAP. Данный подход состоит в кешировании исходных данных и агрегатов в оперативной памяти, тем самым увеличивается производительность сервера. Последняя версия Cognos TM1 9.5 1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется дополнительный инструмент Turbo Integrator, поддерживающий большинство существующих СУБД. Подключение в данном случае происходит через ODBC-драйвер. 2. TM1 поддерживает один вид хранения данных – MOLAP. 3. TM1 поддерживает создание вычисляемых меток. 4. TM1 поддерживает создание пользовательских агрегирующих функций. 5. Помимо кеширования TM1 позволяет сохранять подсчитанные агрегаты в БД, тем самым предусматривается гибкая оптимизация схемы агрегирования. 6. TM1 поддерживает гибкую модель масштабирования, включающую кластеризацию, функции отказоустойчивости, оптимизацию хранения и компрессию данных. 7. TM1 содержит удобный графический интерфейс, встраиваемый в Microsoft Excel, а также собственный Web-интерфейс. 8. Проблема «взрыва данных» в TM1 решена. 9. Проблема разреженности данных в TM1 также решена. 42 10. TM1 поддерживает спецификации OLE DB, XMLA. Язык запросов к многомерным данным – MDX. 11. TM1 может быть установлен как на ОС Windows, так и на Unixподобную ОС. 12. TM1, так же как Essbase и MSAS, очень подробно документирован. Документация на русском языке. 13. Стоимость IBM TM1 – 50 000 $ Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 4) OLAP-сервер Pentaho Mondrian В отличие от вышеперечисленных OLAP-серверов данный продукт является открытым и распространяется под лицензией EPL. Mondrian написан на Java, что с одной стороны уменьшает быстродействие (ввиду javaмашины), но с другой – добавляет свойство гетерогенности среды, в которой будет использоваться сервер. Так же, как и IBM TM1, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Pentaho Analysis. Последняя версия сервера - Mondrian 3.0.4 1. Для подключения к хранилищам данных Mondrian используется JDBC-драйвер. Таким образом, сервер поддерживает СУБД, к которым можно подключаться через JDBC. 2. Mondrian поддерживает только один вид хранения данных – ROLAP. 3. Mondrian поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX. 4. Mondrian не поддерживает агрегирующих функций. 43 создание пользовательских 5. Mondrian изначально хранит все агрегаты в оперативной памяти, но существует возможность создавать для агрегатов свои таблицы в хранилище данных. 6. Mondrian масштабируем только с точки зрения увеличения исходных данных. Функций кластеризации и отказоустойчивости у сервера нет. 7. Mondrian содержит достаточно простой, но с другой стороны, удобный графический интерфейс для создания кубов. Графического интерфейса для администрирования сервера нет – всё администрирование сводится к изменениям параметров в XMLфайлах. 8. Проблема «взрыва данных» в Mondrian решена. 9. Проблема разреженности данных в Mondrian также решена. 10. Mondrian поддерживает API для языков Java (OPAL4J) и спецификации XMLA и OLE DB. Язык запросов к многомерным данным – MDX. 11. Mondrian может быть установлен любую машину, для которой существует Java-машина. В частности, на Windows и Unix-подобную ОС. 12. Сервер документирован достаточно хорошо. Документация на английском языке. 13. Продукт предоставляется бесплатно. Кроме того доступны исходные коды продукта. Следует отметить, что данный продукт поддерживает все типы иерархий, но не поддерживает полуаддитивные меры и функцию «writeback». 44 5) Jedox Palo Данный продукт, так же как Mondrian является открытым и распространяется под лицензией GPL. Так же, как IBM TM1 и Mondrian, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Palo Suite. Последняя версия сервера - Palo 3.1 1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется продукт Palo ETL Server, поддерживающий большинство существующих СУБД. 2. Palo поддерживает только один вид хранения данных – MOLAP. 3. Palo поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX. 4. Palo не поддерживает создание пользовательских агрегирующих функций. 5. Palo хранит все агрегаты в оперативной памяти. Не существует возможности сохранять агрегаты на жёстком диске. Стоить отметить, что сервер использует процессор видеоадаптера (GPU), что способствует уменьшению времени вычисления агрегатов. 6. Palo масштабируем с точки зрения увеличения исходных данных. Palo очень эффективно использует ресурсы процессоров (CPU и GPU), поэтому сервер хорошо масштабируем в сторону увеличения количества процессов (ядер процессоров). Функций кластеризации и отказоустойчивости у сервера нет. 7. Palo содержит достаточно удобный графический интерфейс для создания кубов и администрирования сервера. Palo может быть 45 встроен в Microsoft Excel и в Open Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка. 8. Проблема «взрыва данных» в Palo решена. 9. Проблема разреженности данных в Palo также решена. 10. Palo поддерживает API для языков Java, C/C++, PHP, .NET и спецификации OLE DB и XMLA. Язык запросов к многомерным данным – MDX. 11. Palo может быть установлен как на ОС Windows, так и на Unixподобную ОС. 12. Сервер документирован достаточно хорошо, но только на английском языке. 13. Продукт предоставляется бесплатно. Кроме того доступны исходные коды продукта. Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». Результаты сравнительного анализа Объединим результаты сравнения OLAP-серверов в одну сводную таблицу: Таблица 3.2 Сравнительный анализ OLAP-серверов Критерий/OLAP-сервер Поддержка PostgreSQL Поддерживаемые формы хранения данных (MOLAP/ROLAP/HOLAP) Создание вычисляемых меток Создание пользовательских агрегирующих функций Оптимизация схемы MSAS - Essbase - TM1 + Mondrian + Palo + (+/+/+) (+/-/-) (+/-/-) (-/+/-) (+/-/-) + + + + + + + + - - + + + + - 46 агрегирования Масштабируемость Удобные средства создания кубов и администрирования Решение проблемы «взрыва данных» Решение проблемы разреженности данных Поддержка XMLA и MDX Поддержка Unixподобных операционных систем Подробное документирование на русском языке Цена продукта на минимальную конфигурацию + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + - - 4000$ 40000$ 50000$ беспл. беспл. В ходе проведённого анализа можно сделать следующие выводы:  все рассматриваемые продукты полностью соответствуют принципам аналитической обработки в реальном времени, изложенным Коддом, и тесту FASMI (см. подразд. 1.1);  у платных продуктов очень гибкая схема масштабирования, включающая кластеризацию, функции отказоустойчивости;  платные продукты поддерживают все типы иерархий и мер, а также функцию «write-back»;  платные продукты очень подробно документированы (на русском языке);  все рассматриваемые продукты поддерживают создание вычисляемых меток; 47  бесплатные продукты не поддерживают создание пользовательских агрегирующих функций;  во всех продуктах решена проблема «взрыва данных» и разреженности данных;  все рассматриваемые продукты поддерживают спецификацию XMLA и язык запросов к многомерным данным - MDX;  TM1, Mondrian, Palo используют принцип In-Memory OLAP, что увеличивает быстродействие OLAP-сервера;  Mondrian и Palo имеют открытый исходный код. Для предлагаемого подхода было принято решение использовать OLAP-сервер Pentaho Mondrian, исходя из следующих соображений:  Стоимость - сервер Mondrian абсолютно бесплатен.  Открытость исходного кода. Сервер изначально не поддерживает создание пользовательских агрегирующих функций (в отличие от платных серверов), но существует возможность доработать сервер и добавить недостающую функциональность (решение этой проблемы описано в подразд. 4.2.1).  Mondrian написан на языке Java, являющимся кроссплатформенным. Это позволяет использовать предлагаемый подход в любой среде. Palo написан на языке C++, который не является кроссплатформенным.  Графический интерфейс создания и администрирования кубов у Mondrian удобнее, чем у Palo. 3.2 Выбор хранилища данных Основное требование к хранилищу данных – это оптимизация структур данных, на которых построено хранилище, для оперативного анализа данных. Также необходимо учесть выбор OLAP-сервера – выбранный OLAP48 сервер Mondrian является ROLAP-сервером, поэтому хранилище данных должно быть построено на реляционной СУБД. Для выполнения первого требования об оптимизации структур данных было принято решение использовать схему «Звезда» для проектирования структур данных хранилища. Схема «Звезда» по сравнению со схемой «Снежинка» снижает время выполнения запросов за счет уменьшения количества таблиц, объединяемых в одном запросе. В настоящее время на рынке производителей СУБД предлагается широкий спектр СУБД. В предложенном подходе рассматривались две СУБД – MySQL и PostgreSQL. Обе СУБД являются бесплатными. Выбор был сделан в пользу PostgreSQL, т.к. данная СУБД обладает большими функциональными возможностями по сравнению с MySQL. В частности, PostgreSQL поддерживает следующие расширения языка SQL 92:  хранимые процедуры;  триггеры;  правила;  агрегирующие функции, задаваемые пользователем;  встроенные языки программирования: o SQL; o PL/pgSQL; o PL/Tcl; o PL/Perl; o Embedded SQL в С.  операторы, создаваемые пользователем;  генераторы числовых последовательностей, пользователем;  новые типы данных, задаваемые пользователем. 49 задаваемые 3.3 Выбор модуля преобразования и загрузки данных Основные требования, предъявляемые к модулю преобразования и загрузки данных: • возможность загрузки в OLAP-хранилище только изменённых данных; • возможность преобразования данных в процессе загрузки; • поддержка актуальности данных в OLAP-хранилище. Ввиду принудительного запуска выполнения процедуры загрузки данных в OLAP-хранилище модуль должен поддерживать загрузку только обновлённых данных. Структуры хранилища данных СППР отличаются от структур данных в OLAP-хранилище, поэтому для обновления данных в OLAP-хранилище необходимо применять некоторые модификации к исходным данным. Такой процесс преобразования данных называется ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка»), включающий в себя:  извлечение данных из внешних источников;  их трансформация и очистка (англ. Data cleansing), чтобы они соответствовали нуждам бизнес-модели;  и загрузка их в хранилище данных. Необходима возможность описания ETL-процесса, а также запуска процесса по требованию. Рассматривались следующие варианты реализации модуля:  реализовать собственный модуль;  использовать готовый открытый программный продукт Pentaho Kettle. Выбор был сделан в пользу готового программного продукта, т.к. данный продукт полностью удовлетворяет заявленным требованиям. 50 Продукт Kettle оперирует такими понятиями как преобразование (transformation) и задание (job). Задание – это специально описанная в виде направленного графа последовательность преобразований данных и условий, в зависимости от которых будет выбираться направление обхода графа. Описать ETL-процесс в Kettle – означает построить направленный граф, узлами которого являются операции преобразования данных, задания и некоторые другие элементы, такие как работа с файловой системой, условиями, сценариями, электронной почтой и др. Входными источниками данных для Kettle могут быть:  таблицы в БД (любого производителя);  таблицы Microsoft Excel;  текстовые и XML файлы;  данные, полученные из RSS-канала;  данные, полученные по протоколу XMLA;  данные, полученные по LDAP (например, учётные записи пользователей домена);  Kettle может заполнить входные данные псевдослучайными значениями. В Kettle существуют готовые элементы преобразования, которые могут обновлять данные в хранилище (Lookup/update), дублировать строки/столбцы таблиц, генерировать новые идентификаторы, а также выполнять какие-либо действия на основании условий. ETL-процесс, описанный в Kettle, может быть вызван из командной строки Kettle написан на Java и, соответственно, может работать в гетерогенной среде. 51 3.4 Выбор OLAP-клиента Основные требования, предъявляемые к OLAP-клиенту: • возможность добавления новых кубов данных без модификации продукта; • выполнение всех операций над многомерными данными: срезы, детализация/обобщение, поворот и др.; • доступ к OLAP-серверу по унифицированному протоколу. На сегодняшний день существует множество поставщиков OLAPклиентов. Некоторые из них исполнены в виде настольных приложений, другие – в виде веб-приложений. Все современные OLAP-клиенты удовлетворяют принципам аналитической обработки в реальном времени, изложенным Коддом в 1993 году (см. подразд. 1.1), а позднее дополненными в 1995 году. У каждого клиента есть свои протоколы обмена информацией с OLAPсервером и языки запросов к многомерным данным – в области OLAP на данный момент не существует каких-либо стандартизованных протоколов обмена информацией. Но при этом почти каждый клиент поддерживает стандарты «де факто» обмена информацией – XMLA (XML for Analysis) и языка запросов к многомерным данным фирмы Microsoft – MDX (Multidimensional Expressions). Для выбора OLAP-клиента, удовлетворяющего заявленным требованиям, было принято решение провести сравнительный анализ наиболее известных клиентов. 52 3.4.1 Сравнительный анализ существующих OLAP-клиентов В виду достаточно большого количества производителей OLAPклиентов было принято решение рассмотреть только тех клиентов, которые исполнены в виде веб-приложений, т.к. веб-приложения в настоящий момент являются перспективой областью развития IT и в скором времени вытеснят настольные программы. Таким образом, были выбраны следующие продукты (табл. 3.3): Таблица 3.3 Исследуемые OLAP-клиенты № Фирма-производитель Название OLAP-клиента 1 MicroStrategy MicroStrategy 9i 2 Cognos PowerPlay 3 Jedox JPalo Pivot 4 Pentaho JPivot Для исследования возможностей и сравнения OLAP-клиентов необходимо определить критерии, по которым данные продукты можно сравнивать. Выбор критериев сравнения клиентов происходил на основании требований, предъявляемых к OLAP-клиентам. Были выбраны следующие критерии: 1. Поддержка всех операций над многомерными данными: срезы, детализация/обобщение, поворот и др. 2. Возможность фильтрации входящих данных. Аналитику бывает необходимо сравнить не все значения иерархии, а только часть (например, значения за два определённых года). Данный критерий достаточно важен при выборе OLAP-клиента. 53 3. Документирование. OLAP-клиент должен иметь хорошую документацию для быстрого освоения продукта. 4. Список поддерживаемых API и языков запросов. Необходимо, чтобы API и язык запросов, используемые клиентом, поддерживались OLAP-сервером. 5. Цена продукта. В ходе сравнительного анализа были получены следующие результаты: Таблица 3.4 Сравнительный анализ OLAP-клиентов Критерий/OLAP-клиент Поддержка всех операций над многомерными данными Возможность фильтрации входящих данных Подробная документированность на русском языке Поддержка XMLA и MDX Цена продукта MicroStrategy PowerPlay JPalo Pivot JPivot + + + + + + + - + + - - + + + + 1000$ 1000$ беспл. беспл. Таким образом, можно сделать следующие выводы:  все рассматриваемые продукты полностью соответствуют принципам аналитической обработки в реальном времени, изложенным Коддом, и тесту FASMI (см. подразд. 1.1);  платные продукты полностью удовлетворяют всем заявленным критериям; 54  платные продукты очень подробно документированы (на русском языке);  все рассматриваемые продукты поддерживают спецификацию XMLA и язык запросов к многомерным данным - MDX;  в отличие от JPivot, в котором относительно плохо реализована фильтрация входящих данных, JPalo Pivot поддерживает эту функциональность на уровне платных продуктов; Для предлагаемого подхода было принято решение использовать OLAP-клиент JPalo Pivot, исходя из следующих соображений:  Стоимость - клиент JPalo Pivot абсолютно бесплатен.  Возможности по фильтрации входящих данных в JPalo Pivot гораздо шире, чем у JPivot.  Графический интерфейс у JPalo Pivot удобнее, чем у JPivot. 3.5 Выводы В данной главе была рассмотрена реализация предложенного подхода и осуществлён выбор программных средств, реализующих подход: 1. OLAP-сервер: Pentaho Mondrian. 2. Хранилище данных: СУБД PostgreSQL. 3. Модуль преобразования и загрузки данных: Pentaho Kettle. 4. OLAP-клиент: JPalo Pivot. Все выбранные программные средства являются бесплатными. 55 4. Апробация предложенного подхода Предложенный подход создания подсистем многомерного анализа данных для СППР, учитывающих влияние изменяемых в течение времени факторов, был апробирован на СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ. 4.1 Обзор СППР для департамента РЭП Минпромторга СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ (в дальнейшем СППР РЭП) предназначена для принятия решений по управлению развитием предприятий отрасли в интересах повышения эффективности и устойчивости их функционирования, Федеральных целевых снижения программ на рисков основе невыполнения методов заданий ситуационного управления. Основными задачами СППР РЭП являются:  получение и обработка информации о ходе выполнения программных мероприятий и поддержания в актуальном состоянии системы исходных данных для оценки и прогнозирования состояния предприятий отрасли, а также оценки рисков невыполнения заданий федеральных целевых программ;  интеграция с существующими информационными системами, содержащими информацию по предприятиям отрасли;  ввод и корректировка исходной информации поддержки принятия управленческих решений;  автоматизированная обработка информации текущего финансовоэкономического и производственно-технологического организаций радиоэлектронной промышленности: 56 состояния  оценка рисков невыполнения предприятиями отрасли программных мероприятий федеральных целевых программ;  оценка и прогнозирование состояния предприятий радиоэлектронной отрасли;  поддержку принятия программных управленческих мероприятий решений федеральных по целевых реализации программ и развитию радиоэлектронной отрасли. Основными объектами автоматизации СППР РЭП являются федеральные целевые программы (в дальнейшем программы) и мероприятия. Программа составляется на определённых срок и состоит из набора мероприятий, подлежащих к выполнению организациями-исполнителями в течение указанного срока. Как у мероприятия, так и у программы в целом существуют вероятностные значения рисков невыполнения и ожидаемый ущерб в случае их невыполнения. Программа формируется из предложений, поступающих от государственных заказчиков, и в случае принятия предложения оно становится мероприятием программы. По специальным методикам пользователь системы может оценить стоимость и риски предложений. Для мероприятий по методике анализа иерархий (МАИ) выбирается оптимальная организация-исполнитель. Данные об организациях- исполнителях периодически обновляются в хранилище данных из внешних источников данных. Эти данные включают в себя контактные данных организации, а также и финансово-экономические, производственные и другие виды показателей. Пользователь может создавать несколько вариантов для одной и той же программы, чтобы впоследствии сравнить полученные варианты и выбрать наиболее оптимальный. После выбора наиболее оптимального варианта 57 программа подлежит утверждению и в случае утверждения приобретает соответствующий статус, после чего все стоимостные характеристики программы становятся нередактируемыми. Таким образом, можно выделить следующие основные объекты автоматизации:  Программа. Существует несколько видов программ. Характеризуется целью, сроками, описанием и ожидаемым результатом от выполнения программы.  Предложение. Характеризуется общей стоимостью, сроками выполнения, вероятностью срыва, ущербом от срыва. Состоит из нескольких этапов, длительностью определённому и каждый из стоимостью. направлению которых характеризуется Предложение деятельности привязано к (например, сверхвысокочастотная электроника)  Мероприятие. Это предложение, включенное в программу. Отличается от предложения тем, что на мероприятие уже выделяется финансирование из бюджетных и внебюджетных средств.  Организация-исполнитель. программы. Она Характеризуется выполняет контактной мероприятия информацией (почтовый адрес, юридический адрес, телефон, e-mail и др.), а также набором финансово-экономических, производственных и других показателей. Более подробно модель данных системы поддержки принятия решений представлена на рис. П.1.1. прил. 1. 58 4.2 Реализация подсистемы многомерного анализа данных в СППР для департамента РЭП Минпромторга 4.2.1 Разработка хранилища данных и многомерных OLAP-кубов Для разработки хранилища данных было принято решение создать следующие многомерные кубы, различной степени сложности:  Куб «Анализ показателей организаций-исполнителей», показывающий основные тренды развития организаций. Данный куб использует небольшое число измерений и не использует пользовательских агрегирующих функций.  Куб «Анализ стоимости мероприятий», отображающий финансирование мероприятий. Данный куб использует в качестве измерений все справочники информационной базы и не использует пользовательских агрегирующих функций.  Куб «Анализ рисков и оценочной стоимости предложений», показывающий параметры рисков предложений и их оценочную стоимость. Данный куб использует пользовательские агрегирующие функции для подсчёта суммарных вероятностей. Можно выделить следующий алгоритм создания куба: 1. Спроектировать многомерный куб – выделить необходимые измерения, иерархии и меры. 2. На основании предыдущего пункта создать в хранилище данных соответствующие таблицы измерений и фактов. 3. В программе Pentaho Kettle создать сценарий преобразования данных из хранилища данных СППР в OLAP-хранилище данных. 4. Добавить созданный куб в OLAP-сервер. Остановимся подробнее на каждом разрабатываемом многомерном кубе, так каждый из них содержит разные по сложности сценарии 59 преобразования данных, при написании которых автор сталкивался с различными проблемами. 1) Проектирование и разработка многомерного куба «Анализ показателей организаций-исполнителей» Все организации-исполнители характеризующие ликвидности или имеют ряд показателей, их деятельность (например, коэффициент текущей среднесписочная численность работников). Такие показатели объединены в группы, например, финансовые показатели или производственные показатели. Организации отчитываются о значениях показателей раз в квартал. СППР РЭП также позволяет прогнозировать эти значения. Каждая организация располагается в каком-либо городе России. Исходя из этих данных, можно выделить следующие измерения и иерархии:  Организация (organization_dim) o Федеральный округ (fedokrug) o Регион (region) o Город (city) o Название организации  Время (prod_indicator_timedim) o Год (year) o Квартал (quarter)  Показатель (prod_indicator) o Группа показателей (group) o Наименование показателя Также можно выделить две меры – значение показателя (value) и его прогнозируемое значение (forecast_value). 60 Спроектированная для куба схема «Звезда» изображена на рис.4.1: Рис. 4.1 Схема данных многомерного куба «Анализ показателей организаций-исполнителей» Для преобразования данных из хранилища СППР в OLAP-хранилище воспользуемся следующим сценарием, построенным в Kettle (рис. 4.2): Рис. 4.2 Сценарий преобразования данных для куба «Анализ показателей организаций-исполнителей» 61 Одной из проблем, с которой столкнулся автор, была проблема обновления данных в хранилище, т.е. перенос в хранилище не всех данных, а только изменённых и добавленных после последнего запуска сценария преобразования. У данной проблемы есть несколько путей решения:  использование временных меток создания записи для каждого кортежа в оперативной БД и затем при выборе данных из БД дополнительно в каждый SQL-запрос вставлять условие WHERE;  использование элемента «Поиск и обновление» (combination lookup/update) в качестве промежуточного элемента в сценарии преобразования данных. В данной работе использовался второй способ, т.к. он не требует внесений изменений в структуру хранилища данных СППР. Рассмотрим данный способ на примере. На рис. 4.2 приведён сценарий преобразования данных для разрабатываемого куба, состоящий из четырёх этапов преобразования. Каждый этап загружает данные в таблицы OLAP-хранилища и состоит из нескольких шагов (рис. 4.3): Рис. 4.3 Шаги типичного этапа преобразования 62 На первом шаге по определённому 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 piv.quarter, CASE WHEN piv.quarter = 1 THEN WHEN piv.quarter = 2 THEN WHEN piv.quarter = 3 THEN WHEN piv.quarter = 4 THEN 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 AS id, piv.year, 'I квартал' 'II квартал' 'III квартал' 'IV квартал' FROM prod_indicator_value piv; На следующем шаге происходит проверка выбранных записей на предмет их существования в хранилище. Если выбранная запись уже существует и не изменялась с момента последнего запуска сценария преобразования данных, то такая запись отбрасывается и не поступает на следующий шаг. 63 На последнем шаге происходит загрузка данных в хранилище. На данном шаге выбирается таблица-получатель и указывается соответствие между полями исходных данных и таблицы-получателя. Далее необходимо добавить созданный куб в OLAP-сервер с помощью программного продукта Pentaho Mondrian Workbench. Данный продукт позволяет описывать используемые измерения, иерархии, меры и типы агрегирующих функций для мер. В данном кубе для мер была выбрана агрегирующая функция avg (среднее значение). Таким образом, при просмотре информации за какойлибо период времени пользователю будет выдаваться именно среднее значение показателя. Разработанный куб решает задачу анализа трендов показателей предприятий. С его помощью можно проанализировать изменения значений показателей предприятий за какой-либо промежуток времени, сравнивать организации, находить среднее значение показателя организации за определённый промежуток времени и многое другое. 2) Проектирование и разработка многомерного куба «Анализ стоимости мероприятий» Мероприятия, входящие в программу, финансируются из средств бюджетных и внебюджетных источников. Финансирование планируется на какие-то периоды времени, обычно по годам. Например, если какое-нибудь мероприятие выполняется в период с 2011 и по 2018 годы, то деньги на него могут быть выделены следующим образом: на 2011 год – 1 млн. руб., на период 2012-2015 года – 5 млн. руб., 2016-2018 – 2 млн. руб. Каждое мероприятие выполняется какой-либо организацией-исполнителем. 64 У каждой разрабатываемой программы существует государственный заказчик – одно из 5 предприятий: Минпромторг, Росатом, Роскосмос, Рособразование, Роспром. Мероприятия программы группируются по различным направлениям деятельности, такими как сверхвысокочастотная электроника, микроэлектроника, типовые базовые технологические процессы и др. Разрабатываемый куб решает следующие задачи:  анализ хода выполнения программы в целом и каждого конкретного мероприятия в частности;  анализ подготовленных вариантов программ. Куб позволит анализировать стоимость выполнения, как отдельных мероприятий, так и направлений деятельности в целом, узнавать, сколько средств выделено на определённый период финансирования, высчитывать количество средств, выделенных на программу, сравнивать различные варианты программ и многое другое. В разрабатываемом кубе можно выделить следующие измерения и иерархии:  Организация-исполнитель (organization_dim) o Федеральный округ (fedokrug) o Регион (region) o Город (city) o Название организации  Период финансирования (work_cost_dim) o Период (work_cost_period)  Мероприятие (work_usage_dim) o Тип программы (program_type) o Программа (program) 65 o Вариант программы (program_variant) o Вид направления деятельности (work_direction_type) o Направление деятельности (work_direction) o Название мероприятия  Государственный заказчик (customer_dim) o Наименование заказчика Следует отметить, что в данном кубе используется разработанное ранее измерение organization_dim. В кубе используются две меры – бюджетные (budget_sum) и внебюджетные (outbudget_sum) средства, выделенные на финансирование. Спроектированная для куба схема звезды изображена на рис.4.4: Рис. 4.4 Схема данных многомерного куба «Анализ стоимости мероприятий» 66 Для преобразования данных из хранилища данных СППР в OLAPхранилище воспользуемся следующим сценарием, построенным в программе Kettle (рис. 4.5): Рис. 4.5 Сценарий преобразования данных для куба «Анализ стоимости мероприятий» Этапы данного сценария аналогичны этапам предыдущего сценария, поэтому не будут подробно рассматриваться. Ниже приведены SQL-запросы, используемые при выборке исходных данных в сценарии: Таблица 4.2 SQL-запросы, применяемые для загрузки исходных данных Этап SQL-запрос Заполнение work_cost_period_dim SELECT wcp.id, wcp.period Заполнение customer_dim SELECT c.id, c.shortname as name FROM customer c; Заполнение 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 67 FROM work_cost_period wcp; 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 (сумма). Таким образом, при просмотре информации за какой-либо период времени пользователю будет выдаваться сумма денежных средств. 3) Проектирование и разработка многомерного куба «Анализ рисков и оценочной стоимости предложений» Программа формируется из списка предложений, поступающих от государственных заказчиков. При внесении предложения в программу оно становится мероприятием и для его выполнения выделяются денежные средства. Процесс выполнения предложения разбивается на несколько этапов, каждый из которых имеет свою стоимость и сроки выполнения. 68 По специальным методикам можно оценить стоимость и риски предложений еще до момента внесения их в программу. Риски предложений – это вероятность невыполнения (срыва) предложения и ущерб, понесённый заказчиком, если оно не выполняется в установленные сроки. Разрабатываемый куб решает следующие задачи:  анализ оценочной стоимости предложений;  анализ степени рисков невыполнения мероприятий и возможного ущерба при невыполнении. Куб позволит анализировать риски и оценочную стоимость как предложений в целом, так и этапов в частности. На основании этих данных можно принимать решение о включении предложений в разрабатываемую программу. В разрабатываемом кубе можно выделить следующие измерения и иерархии:  Период финансирования этапов (work_stage_period_dim) o Год (year)  Предложение (work_dim) o Тип программы (program_type) o Программа (program) o Вид направления деятельности (work_direction_type) o Направление деятельности (work_direction) o Название предложения o Этап предложения (work_stage)  Государственный заказчик (customer_dim) o Наименование заказчика Следует отметить, что в данном кубе используется разработанное ранее измерение customer_dim. 69 В кубе можно выделить три меры – оценочная стоимость (cost_estimation), вероятность срыва предложения (risk_failure_percent) и ущерб (risk_loss), понесённый при невыполнении предложения. Спроектированная для куба схема звезды изображена на рис.4.6: Рис. 4.6 Схема данных многомерного куба «Анализ рисков и оценочной стоимости предложений» Для преобразования данных из хранилища данных СППР в OLAPхранилище воспользуемся следующим сценарием, построенным в программе Kettle (рис. 4.7): 70 Рис. 4.7 Сценарий преобразования данных для куба «Анализ рисков и оценочной стоимости предложений» На первом этапе выполняется заполнение таблицы измерения времени. Данная таблица содержит только одно поле – год выполнения этапа, но в хранилище данных СППР этапы имеют конкретную дату начала и завершения. Поэтому для заполнения данной таблицы необходимо взять все даты начала и завершения этапов и выделить из них только года. Полученный результат необходимо сгруппировать. Ниже приведена детализация данного этапа (рис. 4.8): Рис 4.8 Шаги этапа заполнения таблицы work_stage_period_dim 71 Этап состоит из двух 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; Последний этап – заполнение таблицы фактов. Сложность в данном этапе заключается в преобразовании данных. В хранилище данных СППР информация об этапе содержится за конкретный промежуток времени с точностью до месяца, а в результате необходимо получить информацию об 72 этапах за каждый календарный год. Рассмотрим пример. Пусть какой-нибудь этап выполняется с 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 73 В начале данного этапа из хранилища СППР берутся данные о каждом этапе с помощью следующего 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», позволяющий добавлять новые строки к таблице, основываясь на значении какого-либо 74 поля. В данном шаге разделение основывается на поле js_y – для каждого значения года, перечисленного в поле, создаётся новый кортеж данных. Рассмотрим данное преобразование на конкретном примере (рис. 4.10): Поле 1 Поле 2 Поле 3 Поле js_y aaa bbb ccc 2010;2011;2012 ddd eee fff 2011;2012 Поле 1 aaa aaa aaa ddd ddd Поле 2 bbb bbb bbb eee eee Поле 3 ccc ccc ccc fff fff Поле js_y 2010 2011 2012 2011 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); 75 }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 customer_id risk_failure_percent cost_estimation risk_loss year id Поля, используемые на данном этапе work_stage_id customer_id new_risk_failure_percent new_cost_estimation new_risk_loss y2 new_id 76 В разрабатываемом кубе для оценочной стоимости и ожидаемого ущерба используется агрегирующая функция 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 ]), 77 где:  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 78 RETURN $1*$2; END; $BODY$ LANGUAGE 'plpgsql' После создания собственной агрегирующей функции необходимо доработать OLAP-сервер Mondrian так, чтобы он вызывал данную функцию. Mondrian имеет открытый исходный код, написанный на Java. mondrian.rolap.RolapAggregator – класс, отвечающий за вызов агрегирующих функций. В данном классе имеется перечисление (enum), хранящее список 6 предопределённых агрегирующих функций. Необходимо в это перечисление добавить созданную агрегирующую функцию (см. прил. 2): public static final EnumeratedValues<RolapAggregator> enumeration = new EnumeratedValues<RolapAggregator>( 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: 79 <DataSourceInfo> Jdbc = jdbc:postgresql://192.168.77.156/risks; JdbcDrivers = org.postgresql.Driver; JdbcUser = risks; JdbcPassword = risks; Catalog = /WEB-INF/Risks.mondrian.xml </DataSourceInfo> В параметре 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 решает следующие задачи:  выполнение всех операций над многомерными данными: срезы, детализация/обобщение, поворот и др.;  фильтрация входящих данных – возможность выбора собственного набора измерений, а также скрытие любых колонок и строк в таблице; 80  сохранение и печать полученных отчётов; Основным элементом интерфейса 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 может работать с 81 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. 82 GSP-страницы – это динамически формируемые на стороне сервера веб-страницы, использующие синтаксис языка Java и Groovy. Для подключения визуализатора JPalo необходимо создать GSP-страницу olap.gsp, в которую будет встроен OLAP-клиент. На страницу вставляется HTML-тэг IFRAME, который отображает дополнительное окно с вебстраницей. Созданная GSP-страница помещается в папку views. Остановимся подробнее на тэге IFRAME. Ниже приведён фрагмент GSP-кода, подключающего JPalo Pivot на страницу (исходный код GSP-страницы приведён в прил. 4): <iframe src="${paloUrl}" width="100%" height="600" align="left"></iframe> В данном коде, используется переменная paloUrl, формируемая в контроллере (используется модель MVC) и задающая URL к JPalo Pivot. Для подключения OLAP-клиента использовалась среда для разработки Intellij IDEA 9.1, т.к.: 1. Intellij IDEA полностью поддерживает язык Groovy, включая отладку и рефакторинг Groovy-кода. 2. Intellij IDEA поддерживает технологию Grails, тем самым ускоряя разработку Grails-приложений. 4.3 Анализ качества Для анализа качества предложенного подхода были следующие критерии:  время отклика подсистемы (должно быть не более 5 с);  актуальность анализируемых данных. 83 выбраны Анализ качества предложенного подхода проводился на СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ по методу «чёрного ящика». При анализе качества было использовано OLAP-хранилище данных объемом порядка 100 тыс. записей. Программные продукты устанавливались согласно диаграмме развёртывания (рис. 4.12): Рис. 4.12 Диаграмма развёртывания реализованной подсистемы Используемые программные продукты размещены на трёх физических серверах со следующими характеристиками: CPU – Xeon (4 ядра, 2800 МГц), ОЗУ – 4 Гб, ОС – Microsoft Windows 2003 Server, Java-машина – JDK 1.6.11. Скорость сети передачи данных – 100 Мбит/с. Для доступа к подсистеме многомерного анализа клиенты использовали веб-браузер Microsoft Internet Explorer 7.0. Время отклика системы измерялось с помощью простого таймера. Для куба «Анализ показателей организаций-исполнителей» были получены следующие результаты (табл. 4.5): 84 Таблица 4.5 Анализ качества подхода при анализе первого куба данных Количество запрашиваемых данных 1000 1500 2000 Время отклика системы 2с 2,5с 3с Актуальность данных да да да Для куба «Анализ стоимости мероприятий» были получены следующие результаты (табл. 4.6): Таблица 4.6 Анализ качества подхода при анализе второго куба данных Количество запрашиваемых данных 1200 1700 2200 Время отклика системы 2с 2,5с 3с Актуальность данных да да да Для куба «Анализ рисков и оценочной стоимости предложений» были получены следующие результаты (табл. 4.7): Таблица 4.7 Анализ качества подхода при анализе третьего куба данных Количество запрашиваемых данных 1200 1800 2500 Время отклика системы 2,5с 3с 3,5с Актуальность данных да да да На основании полученных результатов можно сделать следующие выводы: 85  все три куба данных удовлетворяют заданным критериям качества: время отклика составляет менее 5 с и все запрашиваемые данные актуальны;  в последнем кубе время отклика системы увеличивается за счёт использования пользовательских агрегирующих функций;  предложенный подход удовлетворяет заявленным критериям качества. 4.4 Выводы В данной главе описано применение предложенного построения подсистем многомерного анализа данных в департамента радиоэлектронной промышленности подхода СППР для Министерства промышленности и торговли РФ. Результат представлен на диаграмме развёртывания (рис. 4.12) и на рис. П.5.1 прил. 5. Для анализа качества подхода были разработаны три многомерных куба данных и выбраны соответствующие критерии качества. В результате тестирования, проводимого по методу «черного ящика», предложенный подход можно признать работоспособным. 86 Заключение 1. Выбран подход построения подсистемы многомерного анализа данных для СППР, учитывающих особенности изменяемых с течением времени факторов. 2. Предложена основанная архитектура на подсистемы модифицированной многомерного трёхзвенной анализа, архитектуре построения OLAP-систем. 3. Выбраны и доработаны программные средства для реализации предложенной архитектуры. 4. Разработана подсистема многомерного анализа данных в СППР для департамента радиоэлектронной промышленности и торговли РФ. 87 промышленности Министерства Список литературы 1. Архипенков С. Хранилища данных. / Д. Голубев, О. Максименко – М.: Диалог-МИФИ, 2002. 2. Методы и модели анализа данных: OLAP и Data Mining. / А. Барсегян [и др.] – СПб.: БХВ-Петербург, 2004. 3. Бергер А. Microsoft SQL Server 2005 Analysis Services. OLAP и многомерный анализ данных. – СПб.: БХВ-Петербург, 2007. 4. Смит Г. Grails. Гибкость Groovy и надежность Java. / П. Ледбрук – М.: Символ-Плюс, 2010. 5. Спирли Э. Корпоративные хранилища данных. Планирование, разработка и реализация. – М.: Вильямс, 2001. 6. Харинатх С. SQL Server 2005 Analysis Services и MDX для профессионалов. / С. Куинн – М.: Диалектика, 2008. Интернет-ресурсы: 7. http://ru.wikipedia.org/wiki - свободная Интернет-энциклопедия. 8. http://www.fpm.com/refer/codd.html - статья Е.Ф. Кодда, С.Б. Кодда и С.Т. Солли "OLAP для пользователей-аналитиков: информационнотехнологический мандат". 9. http://www.olap.ru – сайт о бизнес-аналитике. 88 Приложения Приложение 1. Схема данных СППР РЭП Рис. П.1.1 Схема данных СППР РЭП 89 Приложение 2. Код модифицированного класса OLAP-сервера, вызывающего агрегирующие функции package mondrian.rolap; import mondrian.calc.Calc; import mondrian.olap.Aggregator; import mondrian.olap.EnumeratedValues; import mondrian.olap.Evaluator; import mondrian.olap.fun.FunUtil; import java.util.List; public abstract class RolapAggregator extends EnumeratedValues.BasicValue implements Aggregator { private static int index = 0; public static final RolapAggregator Sum = new RolapAggregator("sum", index++, false) { public Object aggregate(Evaluator evaluator, List members, Calc exp) { return FunUtil.sum(evaluator, members, exp); } }; public static final RolapAggregator Count = new RolapAggregator("count", index++, false) { public Aggregator getRollup() { return Sum; } public Object aggregate(Evaluator evaluator, List members, Calc exp) { return FunUtil.count(evaluator, members, false); } }; public static final RolapAggregator Min = new RolapAggregator("min", index++, false) { public Object aggregate(Evaluator evaluator, List members, Calc exp) { return FunUtil.min(evaluator, members, exp); } }; public static final RolapAggregator Max = new RolapAggregator("max", index++, false) { public Object aggregate(Evaluator evaluator, List members, Calc exp) { return FunUtil.max(evaluator, members, exp); } }; public static final RolapAggregator Avg = new RolapAggregator("avg", index++, false) { public Aggregator getRollup() { return null; } public Object aggregate(Evaluator evaluator, List members, Calc exp) { return FunUtil.avg(evaluator, members, exp); } }; public static final RolapAggregator DistinctCount = new RolapAggregator("distinct-count", index++, true) { public Aggregator getRollup() { 90 // Distinct counts cannot always be rolled up, when they can, // it's using Sum. return Sum; } public RolapAggregator getNonDistinctAggregator() { return Count; } public Object aggregate(Evaluator evaluator, List members, Calc exp) { throw new UnsupportedOperationException(); } public String getExpression(String operand) { return "count(distinct " + operand + ")"; } }; public static final RolapAggregator Prob = new RolapAggregator("prob_aggr", index++, false) { public Aggregator getRollup() { return null; } public Object aggregate(Evaluator evaluator, List members, Calc exp) { return FunUtil.count(evaluator, members, false); } }; public static final EnumeratedValues<RolapAggregator> enumeration = new EnumeratedValues<RolapAggregator>( new RolapAggregator[]{Sum, Count, Min, Max, Avg, DistinctCount, Prob}); protected abstract static class BaseAggor extends RolapAggregator { protected final String factCountExpr; protected BaseAggor(final String name, final String factCountExpr) { super(name, index++, false); this.factCountExpr = factCountExpr; } public Object aggregate(Evaluator evaluator, List members, Calc exp) { throw new UnsupportedOperationException(); } } public static class AvgFromSum extends BaseAggor { public AvgFromSum(String factCountExpr) { super("AvgFromSum", factCountExpr); } public String getExpression(String operand) { StringBuilder buf = new StringBuilder(64); buf.append("sum("); buf.append(operand); buf.append(") / sum("); buf.append(factCountExpr); buf.append(')'); return buf.toString(); } } public static class AvgFromAvg extends BaseAggor { public AvgFromAvg(String factCountExpr) { super("AvgFromAvg", factCountExpr); } public String getExpression(String operand) { 91 StringBuilder buf = new StringBuilder(64); buf.append("sum("); buf.append(operand); buf.append(" * "); buf.append(factCountExpr); buf.append(") / sum("); buf.append(factCountExpr); buf.append(')'); return buf.toString(); } } public static class SumFromAvg extends BaseAggor { public SumFromAvg(String factCountExpr) { super("SumFromAvg", factCountExpr); } public String getExpression(String operand) { StringBuilder buf = new StringBuilder(64); buf.append("sum("); buf.append(operand); buf.append(" * "); buf.append(factCountExpr); buf.append(')'); return buf.toString(); } } private final boolean distinct; public RolapAggregator(String name, int ordinal, boolean distinct) { super(name, ordinal, null); this.distinct = distinct; } public boolean isDistinct() { return distinct; } public String getExpression(String operand) { StringBuilder buf = new StringBuilder(64); buf.append(name); buf.append('('); if (distinct) { buf.append("distinct "); } buf.append(operand); buf.append(')'); return buf.toString(); } public RolapAggregator getNonDistinctAggregator() { throw new UnsupportedOperationException(); } public Aggregator getRollup() { return this; } } 92 Приложение 3. Файл конфигурации OLAP-сервера Risks.mondrian.xml <Schema name="Риски" measuresCaption="Значения"> <Dimension type="StandardDimension" name="Мероприятие"> <Hierarchy hasAll="true" allMemberCaption="Все мероприятия" primaryKey="id"> <Table name="work_usage_dim" schema="public"> </Table> <Level name="Тип программы" column="program_type_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="program_type_name"> </Level> <Level name="Программа" column="program_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="program_name"> </Level> <Level name="Вариант программы" column="program_variant_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="program_variant_name"> </Level> <Level name="Вид направления деятельности" column="work_direction_type_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="work_direction_type_name"> </Level> <Level name="Направление делятельности" column="work_direction_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="work_direction_name"> </Level> <Level name="Мероприятие" column="work_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="work_name"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" name="Период финансирования"> <Hierarchy hasAll="true" allMemberCaption="Все периоды финансирования" primaryKey="id"> <Table name="work_cost_period" schema="public"> </Table> 93 <Level name="Период финансирования" column="period" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" name="Гос. заказчик"> <Hierarchy hasAll="true" allMemberCaption="Все гос. заказчики" primaryKey="id"> <Table name="customer" schema="public"> </Table> <Level name="Гос. заказчик" column="shortname" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" name="Предложение"> <Hierarchy hasAll="true" allMemberCaption="Все предложения" primaryKey="id"> <Table name="work_dim" schema="public"> </Table> <Level name="Тип программы" column="program_type_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="program_type_name"> </Level> <Level name="Программа" column="program_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="program_name"> </Level> <Level name="Вид направления деятельности" column="work_direction_type_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="work_direction_type_name"> </Level> <Level name="Направление деятельности" column="work_direction_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="work_direction_name"> </Level> <Level name="Предложение" column="work_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="work_name"> </Level> 94 <Level name="Этап" column="id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="name"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" name="Показатель"> <Hierarchy hasAll="true" allMemberCaption="Все показатели" primaryKey="id"> <Table name="prod_indicator_dim" schema="public"> </Table> <Level name="Группа показателей" column="group_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="group_name"> </Level> <Level name="Показатель" column="id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="name"> </Level> </Hierarchy> </Dimension> <Dimension type="StandardDimension" name="Организация"> <Hierarchy hasAll="true" allMemberCaption="Все организации" primaryKey="id"> <Table name="organization_dim" schema="public"> </Table> <Level name="Федеральный округ" column="fedokrug_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="fedokrug_name"> </Level> <Level name="Регион" column="region_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="region_name"> </Level> <Level name="Город" column="city_id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="city_name"> </Level> <Level name="Организация" column="id" type="Numeric" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="name"> </Level> 95 </Hierarchy> </Dimension> <Cube name="Анализ стоимости мероприятий" cache="true" enabled="true"> <Table name="work_cost_fact" schema="public"> </Table> <DimensionUsage source="Период финансирования" name="Период финансирования" foreignKey="work_cost_period_id"> </DimensionUsage> <DimensionUsage source="Мероприятие" name="Мероприятие" foreignKey="work_usage_id"> </DimensionUsage> <DimensionUsage source="Гос. заказчик" name="Гос. заказчик" foreignKey="customer_id"> </DimensionUsage> <DimensionUsage source="Организация" name="Исполнитель" foreignKey="organization_id"> </DimensionUsage> <Measure name="Бюджетные средства" column="budget_sum" datatype="Numeric" aggregator="sum" visible="true"> </Measure> <Measure name="Внебюджетные средства" column="outbudget_sum" datatype="Numeric" aggregator="sum" visible="true"> </Measure> </Cube> <Cube name="Анализ рисков и оценочной стоимости предложений" cache="true" enabled="true"> <Table name="work_fact" schema="public"> </Table> <DimensionUsage source="Предложение" name="Предложение" foreignKey="work_stage_id"> </DimensionUsage> <DimensionUsage source="Гос. заказчик" name="Гос. заказчик" foreignKey="customer_id"> </DimensionUsage> <Dimension type="StandardDimension" foreignKey="year" name="Время"> <Hierarchy hasAll="true" allMemberCaption="Всё время" primaryKey="year"> <Table name="work_stage_period_dim" schema="public"> </Table> <Level name="Год" column="year" type="Integer" uniqueMembers="false" levelType="Regular" hideMemberIf="Never" captionColumn="year"> 96 </Level> </Hierarchy> </Dimension> <Measure name="Оценочная стоимость" column="cost_estimation" datatype="Numeric" aggregator="sum" visible="true"> </Measure> <Measure name="Вероятность срыва" column="risk_failure_percent" datatype="Numeric" aggregator="prob_aggr" visible="true"> </Measure> <Measure name="Стоимость ущерба" column="risk_loss" datatype="Numeric" aggregator="sum" visible="true"> </Measure> </Cube> <Cube name="Анализ показателей предприятий" cache="true" enabled="true"> <Table name="prod_indicator_fact" schema="public"> </Table> <Dimension type="TimeDimension" foreignKey="time_id" name="Время"> <Hierarchy hasAll="true" allMemberCaption="Всё время" primaryKey="id"> <Table name="prod_indicator_timedim" schema="public"> </Table> <Level name="Год" column="year" type="Numeric" uniqueMembers="false" levelType="TimeYears" hideMemberIf="Never" captionColumn="year"> </Level> <Level name="Квартал" column="quarter" type="Numeric" uniqueMembers="false" levelType="TimeQuarters" hideMemberIf="Never" captionColumn="quarter_name"> </Level> </Hierarchy> </Dimension> <DimensionUsage source="Показатель" name="Показатель" foreignKey="prod_indicator_id"> </DimensionUsage> <DimensionUsage source="Организация" name="Организация" foreignKey="organization_id"> </DimensionUsage> <Measure name="Значение" column="value" datatype="Numeric" aggregator="avg" visible="true"> </Measure> <Measure name="Прогноз" column="forecast_value" datatype="Numeric" aggregator="avg" visible="true"> </Measure> </Cube> </Schema> 97 Приложение 4. Исходный код GSP-страницы с OLAP-клиентом <template:useTemplate template="/mainTemplate"> <menu:init name="OlapMenu" active="${activeMenu}"/> <template:block name="appTitle">СППР РЭП</template:block> <template:block name="activeTab">Многомерный анализ</template:block> <template:block name="path"><menu:renderPath/></template:block> <template:block name="leftNav"><menu:renderMenu/></template:block> <template:block name="style"> div#contentBody{ background-color:transparent; } </template:block> <template:block name="title"> Многомерный анализ данных в СППР РЭП </template:block> <template:block name="main"> <iframe src="${paloUrl}" width="100%" height="600" align="left"> Ваш браузер не поддерживает плавающие фреймы. Обратитесь в службу поддержки ОАО "НИЦ СПбЭТУ". </iframe> </template:block> </template:useTemplate> 98 Приложение 5. Графический пользовательский интерфейс подсистемы многомерного анализа данных в СППР РЭП Рис П.5.1 Окно анализа стоимости мероприятий 99

Титульник

Related documents

Products

Support

Титульник

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib