Титульный лист 1

Титульный лист 1 Техническое задание 2 Аннотация 3 Содержание Список сокращений, используемых в работе ......................................................... 6 Введение ................................................................................................................... 7 1. OLAP – средство оперативного анализа данных ............................................... 10 1.1 Введение в OLAP ............................................................................................ 10 1.2 Хранилища данных ........................................................................................ 15 1.3 Многомерная модель данных ...................................................................... 20 1.3.1 Реализация многомерной модели данных .......................................... 28 1.4 Классификация OLAP-продуктов ................................................................... 31 1.4.1 Классификация по способу хранения данных ...................................... 31 1.4.2 Классификация по месту размещения OLAP-машины ......................... 33 2. Исследование предметной области разрабатываемого модуля многомерного анализа данных ...................................................................................................... 36 2.1 Цели и задачи СППР РЭП ............................................................................... 36 2.2 Структура СППР РЭП ....................................................................................... 37 2.3 Основные объекты автоматизации СППР РЭП ............................................. 37 2.4 Цели и задачи разрабатываемого модуля для СППР РЭП ........................... 39 3. Исследование возможностей современных OLAP-серверов ........................... 41 3.1 Выбор критериев для сравнения .................................................................. 43 3.2 Microsoft Analysis Services.............................................................................. 46 3.3 Oracle Essbase ................................................................................................. 47 3.4 IBM Cognos TM1 ............................................................................................. 49 3.5 Pentaho Mondrian........................................................................................... 50 3.6 Jedox Palo........................................................................................................ 51 4 3.7 Результаты...................................................................................................... 53 4. Разработка хранилища данных и многомерных OLAP-кубов ........................... 57 4.1 Проектирование и разработка многомерного куба «Анализ показателей организаций-исполнителей» .............................................................................. 60 4.2 Проектирование и разработка многомерного куба «Анализ стоимости мероприятий»...................................................................................................... 64 4.3 Проектирование и разработка многомерного куба «Анализ рисков и оценочной стоимости предложений» ................................................................ 68 4.4 Результаты...................................................................................................... 79 5. Разработка модуля многомерного анализа данных для СППР РЭП ................. 80 5.1 Настройка OLAP-сервера ............................................................................... 80 5.2 Подключение визуализатора в СППР РЭП .................................................... 81 5.3 Результаты...................................................................................................... 85 Заключение ............................................................................................................. 86 Список литературы ................................................................................................. 86 Приложения ............................................................................................................ 87 5 Список сокращений, используемых в работе ФЦП — Федеральная целевая программа ГПВ — Государственная программа вооружения ГОЗ — государственный оборонительный заказ РЭП — радиоэлектронная промышленность НИР — научно-исследовательская работа СППР РЭП — автоматизированная поддержки принятия предприятиями информационная решений радиоэлектронной по система выполнению промышленности мероприятий ГПВ, ФЦП и ГОЗ OLAP OLTP (Online — обработка транзакций в реальном времени. Способ Transaction организации Processing) работает с небольшими по размерам транзакциями, но базы данных, при котором система идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа Хранилище данных — (ХД) (англ. Warehouse) очень большая Data информационная предметно-ориентированная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации. Строится на базе клиент-серверной архитектуры, реляционной СУБД и утилит поддержки принятия решений. Данные, поступающие в хранилище данных, становятся доступны только для чтения 6 Введение Обострившиеся в последнее время проблемы, связанные с эффективным планированием и реализацией планов и программ в области обороны и безопасности, требуют оперативной оценки рисков в этой области, повышения качества выработки предложений по основным направлениям военной и оборонно-промышленной безопасности на основе единой базы данных и проведения многопараметрического анализа выполнения ГПВ, ГОЗ, ФЦП, осуществляемых организациями оборонно-промышленного комплекса. Проводимая в ряде федеральных органов исполнительной власти работа по автоматизации процессов разработки и реализации программ в сфере оборонно-промышленного комплекса ведётся без учета необходимости всесторонней оценки степени влияния финансово-технологических рисков на качество разрабатываемых программных и плановых документов. Недостаточное внимание уделяется разработке моделей и моделирующих комплексов для поддержки принятия управленческих решений. Повышение эффективности управленческой деятельности и снижение рисков целевого планирования должно обеспечиваться за счет применения современных информационно-аналитических систем. За последние 20 лет информационно-аналитические системы меняли свои названия и содержание, пройдя путь от информационных систем руководителя (executive information systems, EIS) до систем поддержки принятия решений (decision support systems, DSS). Современные приложения DSS строятся на основе технологий, позволяющих пользователю-непрограммисту легко и оперативно извлекать информацию настраиваемые из различных отчеты многомерный анализ или данных. источников, формировать графические представления, собственные проводить Разнообразие этих технологий принято объединять термином «бизнес-аналитика» или Business Intelligence (BI). 7 В основе технологий BI лежит организация доступа конечных пользователей и анализ структурированных количественных по своей природе данных и информации о бизнесе. BI порождает итерационный процесс бизнеспользователя, включающий доступ к данным и их анализ, и тем самым проявление интуиции, формирование заключений, нахождение взаимосвязей, чтобы эффективно изменять предприятие в положительную сторону. BI имеет широкий спектр пользователей, включая руководителей и аналитиков. Цель технологий BI - своевременно принимать решения, основываясь на корректных данных. Организация, в которой работает автор ВКР, разрабатывает в интересах оборонно-промышленного комплекса систему поддержки принятия решений с учётом влияния финансово-экономических и производственно-технологических рисков. Система используется для контроля выполнения предприятиями радиоэлектронной промышленности мероприятий ГПВ, ФЦП и ГОЗ. Система разрабатывается с использованием передовых BI технологий. Перед автором данной работы была поставлена цель: разработать модуль многомерного оперативного анализа данных для системы поддержки принятия решений с учётом влияния финансово-экономических и производственно-технологических рисков. Для достижения поставленной цели перед автором были поставлены следующие задачи: 1. Провести исследование возможностей современных OLAP- серверов и на основании его выбрать наиболее подходящий для разрабатываемой системы. 2. Разработать хранилище данных и на его основе сформировать необходимые для анализа многомерные кубы. 3. Разработать модуль многомерного анализа данных в системе поддержки принятия решений. 8 Объектом исследования ВКР является технология оперативной аналитической обработки данных (OLAP), которая является одной из составляющих BI технологий. Предметом исследования является создание модуля многомерного анализа данных для системы поддержки принятия управленческих решений с учётом влияния финансово-экономических и производственно-технологических рисков предприятий. Новизна работы состоит в применении технологии многомерного анализа данных в сфере радиоэлектронной промышленности с учетом влияния финансово-экономических и производственно-технологических рисков предприятий. Практическая значимость работы заключается во внедрении системы поддержки принятия решений совместно с модулем многомерного анализа, разрабатываемым соисполнителями,на предприятиях оборонно- промышленного комплекса в качестве системы контроля выполнения предприятиями радиоэлектронной промышленности мероприятий ГПВ, ФЦП и ГОЗ. ВКР разрабатывается в рамках НИР «Разработка методологии оценки финансово-экономических и технологических предприятиями радиоэлектронной промышленности программ и государственных оборонных заказов». 9 рисков выполнения федеральных целевых 1. OLAP – средство оперативного анализа данных 1.1 Введение в OLAP Трудно найти в компьютерном мире человека, который хотя бы на интуитивном уровне не понимал, что такое базы данных и зачем они нужны. В отличие от традиционных реляционных СУБД, концепция OLAP не так широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное, почти все. Что же такое Online Analytical Processing? OLAP (Online Analytical Processing) — это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Аналитики являются особыми потребителями корпоративной информации, задача которых находить закономерности в больших массивах данных и делать выводы о текущем состоянии бизнеса. Аналитики используют большие массивы информации о событиях. Данные, которые требуются аналитику для работы, обязательно содержат числовые значения, это обусловлено самой сущностью его деятельности. Кроме централизации и структурирования хранимых данных предприятия аналитику требуется инструмент для просмотра и визуализации хранимой информации. Традиционные отчеты, даже построенные на основе единого хранилища, лишены гибкости. Их нельзя «прокрутить», «развернуть» или «свернуть», к ним нельзя применить фильтрацию, чтобы получить желаемое представление данных. Конечно, можно вызвать программиста, и он сделает новый отчет достаточно быстро - скажем, в течение часа. Но в современных условиях ведения бизнеса этого недостаточно. Оперативность в данном случае — один из факторов успеха. Аналитику нужен такой инструмент, который 10 позволил бы визуализировать данные быстро, просто и удобно. В качестве такого инструмента и выступает OLAP. Термин OLAP (On-Line Analytical Processing) был предложен доктором Е.Ф. Коддом, его супругой С.Б. Кодд и их коллегой С.Т. Солли в исследовательской статье "OLAP для пользователей-аналитиков: информационно-технологический мандат". Эта статья была опубликована в начале 1993 года и спонсировалась корпорацией Arbor Software, создателем и распространителем первого OLAPпродукта Essbase. Статья определяет OLAP как «имя, данное динамическому анализу предприятия, необходимому для создания, манипулирования, оживления и синтезирования информации на базе "моделей информации о предприятии" ("Enterprise Data Models")». Основная цель OLAP-анализа — проверка возникающих гипотез. В 1993 году Кодд сформулировал «12 принципов аналитической обработки в реальном времени» [8] (см. табл. 1.1): Таблица 1.1. Принципы аналитической обработки в реальном времени № 1 Принцип Многомерное Описание представление Средства должны многомерный данных на поддерживать концептуальном уровне взгляд на данные. 2 Пользователь не должен знать о том, Прозрачность какие конкретные используются обработки для данных, средства хранения как и данные организованы и откуда они берутся. 3 Средства должны сами выбирать и Доступность связываться с наилучшим для формирования ответа на данный 11 запрос источником данных. Средства должны обеспечивать автоматическое отображение их собственной логической схемы в различные гетерогенные источники данных. 4 Согласованная производительность Производительность практически не должна зависеть от количества Измерений в запросе. 5 6 Поддержка архитектуры клиент- Средства должны работать в сервер архитектуре клиент-сервер. Равноправность всех измерений Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными). 7 Динамическая обработка Неопределенные значения должны храниться разреженных матриц и обрабатываться наиболее эффективным способом. 8 Поддержка Средства многопользовательского обеспечивать режима возможность работать более чем работы с данными 9 должны одному пользователю. Поддержка операций на основе Все многомерные (например, различных измерений единообразно операции агрегация) и должны согласованно применяться к любому числу любых измерений. 10 Простота манипулирования Средства должны иметь максимально удобный, естественный 12 и данными комфортный пользовательский интерфейс. 11 Развитые средства представления Средства должны различные данных поддерживать способы визуализации (представления) данных. 12 Неограниченное число измерений Не должно быть ограничений на и уровней агрегации данных число поддерживаемых измерений. В 1995 году на основе принципов, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям оперативного анализа данных [2]:  предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;  возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;  многопользовательский соответствующих доступ механизмов к данным блокировок с поддержкой и средств авторизованного доступа;  многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP);  возможность обращаться к любой нужной информации независимо от ее объема и места хранения. 13 Большинство из существующих OLAP-средств удовлетворяют всем этим требованиям. Однако в реализации подобных приложений возникает ряд проблем, прежде всего связанных с увеличением объёма данных, которые необходимо хранить. В настоящее время встречаются следующие применения OLAP:  Анализ данных. Задача, для которой изначально использовались и до сих пор остаются самыми популярными OLAP-средства. Многомерная модель данных, возможность анализировать значительные объёмы данных и быстрый отклик на запросы делают подобные системы незаменимыми для анализа продаж, маркетинговых мероприятий, дистрибуции и других задач с большим объёмом исходных данных. Примеры продуктов: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, 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. 14  Финансовая консолидация. Консолидация данных согласно международным стандартам учёта, принимая во внимание доли владения, различные валюты и внутренние обороты – актуальная задача в связи с ужесточающимися требованиями проверяющих органов (SOX, Basel II) и выходом компаний на IPO (Initial Public Offering — первая публичная продажа акций частной компании). OLAP-технологии позволяют ускорить расчёт консолидированных отчётов и повысить прозрачность всего процесса. Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller. Таким образом, OLAP – актуальная и востребованная тема исследований, её практические результаты имеют широкое применение. Несмотря на достаточно долгую историю исследований, до сих не существует единых терминологических стандартов, стандартов передачи данных, языка запросов и формирования кубов. Растущие объёмы корпоративных данных повышают значимость средств анализа, большая часть которых построена на OLAPпринципах, в связи с чем, актуальны проблемы выбора оптимальных схем хранения и обработки OLAP-кубов. Задачи бюджетирования, требующие совмещения возможностей скорости ввода транзакционных систем и аналитических OLAP, представляют собой особый класс систем, алгоритмическая база которых только создается. 1.2 Хранилища данных Преимущество использования OLAP — это скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. Более хорошей моделью для запросов, а не для изменения, является пространственная (часто называемая многомерной) БД [7]. 15 Представим себе ситуацию, что в какой-то момент времени с OLTPсистемой работают 1000 пользователей и один из них захотел построить сводный отчёт за относительно большой временной период. Запрос на построение такого рода отчётов, содержащий множество соединений таблиц, выполняется долго и во время выполнения блокирует остальных пользователей. Поэтому проектные решения современных информационноаналитических систем основываются не на одной базе данных, а на нескольких: в одной из них хранятся неизменяемые данные - такая БД называется хранилищем данных (ХД), а в остальных – данные, которые со временем могут измениться (оперативные данные) (рис. 1.1). Неизменяемые данные обычно используются для долговременного хранения статистической информации. Поэтому когда пользователь захочет построить сводный отчёт за большой временной период, то данные для этого отчёта будут приходить именно из хранилища данных и, соответственно, выполняющийся запрос не будет блокировать остальных пользователей. Рис. 1.1 Источники информации для хранилищ данных Данные в хранилище данных могут поступать не только из операционных баз данных, но и из других источников, таких как XML-документы, Excel-таблицы 16 и прочих текстовых документов. Данные загружаются в хранилище с определённой периодичностью (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей), поэтому актуальность данных несколько отстает от OLTP-систем. Таким образом, OLAP используется данные, находящиеся не в операционных БД, а в хранилищах данных. Задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре [1]. Автором концепции хранилищ данных является Б. Инмон [9], который определил хранилища данных как: "предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления", призванные выступать в роли "единого и единственного источника истины", обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений. В основе концепции хранилищ данных лежат две основополагающие идеи [1]:  Интеграция ранее разъединенных детализированных данных в едином хранилище данных, их согласование и, возможно, агрегация: o исторических архивов; o данных из традиционных систем обработки данных; o данных из внешних источников.  Разделение наборов данных, используемых для операционной обработки, и наборов данных, применяемых для решения задач анализа. 17 Цель концепции хранилищ данных - выяснить требования к данным, помещаемым в целевую БД хранилища данных (см. табл. 1.2), определить общие принципы и этапы ее построения, основные источники данных, дать рекомендации по решению потенциальных проблем, возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД [9]. Таблица 1.2 Основные требования к данным в хранилище данных Требование Комментарий Предметная Все данные о некотором предмете (бизнес- ориентированность объекте) собираются различных (обычно из источников), множества очищаются, согласовываются, дополняются, агрегируются и представляются в единой, удобной для их использования в бизнес-анализе форме. Интегрированность Все данные о разных бизнес-объектах взаимно согласованы и хранятся в едином общекорпоративном хранилище. Неизменчивость Исходные (исторические) данные, после того как они были внесены согласованы, в остаются верифицированы общекорпоративное неизменными и и хранилище, используются исключительно в режиме чтения. Поддержка хронологии Данные хронологически отражают историю, выполнения задач за структурированы достаточный для бизнес-анализа и прогнозирования период времени. 18 и Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными оказываются вопросы, связанные с согласованием данных. Основным требованием аналитика является даже не столько оперативность, сколько достоверность ответа. Но достоверность, в конечном счете, определяется согласованностью данных. Пока не проведена работа по взаимному согласованию значений данных из различных источников, сложно говорить об их достоверности. Хранилища данных бывают двух типов: корпоративные хранилища данных (enterprise data warehouses) и витрины данных (data marts) [5]. Первые содержат информацию, относящуюся ко всей корпорации и собранную из множества оперативных источников для консолидированного анализа. Обычно такие хранилища охватывают целый ряд аспектов деятельности корпорации и используются для принятия тактических и стратегических решений. Корпоративное хранилище содержит как детальную, так и суммарную информацию и в объеме может достигать от (условно) 50 Гб до одного или нескольких терабайт. Стоимость создания и поддержки корпоративных хранилищ может быть очень высокой. Обычно их созданием занимаются централизованные отделы информационных технологий, причем создаются они сверху вниз, т.е. сначала проектируется общая схема и лишь затем заполняется данными. Построение такого хранилища может длиться несколько лет. Витрины данных содержат подмножества корпоративных данных и строятся для отделов или подразделений внутри организации. Витрины часто строятся силами самого отдела и охватывают конкретный аспект, интересующий сотрудников данного отдела. Витрина может получать данные из корпоративного хранилища (зависимая витрина данных, dependent data 19 mart) или, что вероятнее, данные могут поступать прямо из оперативных источников (независимая витрина данных, independent data mart). Витрины и хранилища данных строятся по сходным принципам и используют практически одинаковые технологии. Структуры данных хранилища заметно отличаются от применяемых в OLTP-системах. Это в первую очередь определяется предметной ориентированностью хранилища: данные организованы вокруг того или иного аспекта деятельности предприятия. В следующей главе речь пойдёт о многомерной модели данных, на которой основаны хранилища данных. 1.3 Многомерная модель данных Многомерная модель данных — это расширение реляционной модели. В отличие от «отношение», реляционной в модели, многомерной где основным понятием является модели основным понятием является многомерный «куб» (нередко называемый также OLAP-кубом), который является обобщением реляционных таблиц на любое число измерений. Набор соответствующих кубов составляет многомерную базу данных. Многомерная модель данных не рассчитана на частое выполнение транзакций, но очень удобна именно для анализа больших массивов данных. Она наиболее адекватна представлениям о предметной области, которыми оперирует аналитик или управленец. Некоторые преимущества многомерной модели по сравнению с реляционной [7]:  Возможность анализа больших объемов данных с приемлемой скоростью;  Возможность осуществления любых «срезов» и «углублений» в определённой структуре БД; 20  Быстрая локализация трендов и проблемных областей. Многомерные модели данных имеют три важных области применения, связанных с проблематикой анализа данных [3]: 1. Хранилища данных интегрируют для анализа информации из нескольких источников. 2. Системы оперативной аналитической обработки OLAP позволяют оперативно получить ответы на запросы, охватывающие большие объемы данных в поисках общих тенденций. 3. Приложения добычи данных служат для выявления знаний за счет полуавтоматического поиска ранее неизвестных шаблонов и связей в базах данных. Многомерный куб представлен набором мер и измерений, а именно, куб — это декартовое произведение измерений, где для каждого элемента произведения проставлен набор мер. Измерения куба – набор доменов, по которым создаётся многомерное пространство. Другими словами, измерение – это значений, соответствующий грани куба. упорядоченный Многомерное набор моделирование предусматривает использование измерений для предоставления максимальной информативности [3]. В отличие от реляционных баз данных, контролируемая избыточность в многомерных базах данных считается оправданной, если она увеличивает информационную ценность. Измерения используются для выбора и агрегирования данных на требуемом уровне детализации. Измерения организуются в иерархию, состоящую из нескольких уровней, каждый из которых представляет уровень детализации, требуемый для соответствующего анализа. Иногда бывает полезно определять несколько иерархий для измерения. Например, модель может определять время, как в финансовых годах, так и в календарных. Несколько иерархий совместно используют один или несколько 21 общих, самых низких уровней, например, день и месяц, и модель группирует их в несколько более высоких уровней — финансовый квартал и календарный квартал. Чтобы избежать дублирования определений, метаданные многомерной базы данных определяют иерархию измерений. Отметим, что иерархии могут быть сбалансированными (balanced, т.е. иерархии имеют одинаковую высоту по всем ветвям, а каждое значение не корневого уровня — только одного родителя), как, например, иерархия, представленная на рис. 1.2 и несбалансированными (unbalanced) [9]. Типичный пример несбалансированной иерархии — иерархия типа "начальник— подчиненный", представлен на рис. 1.3 Рис. 1.2 Сбалансированная иерархия измерений Рис. 1.3 Несбалансированная иерархия измерений Иногда для таких иерархий используется термин Parent-child hierarchy. Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются 22 термином ragged — "неровный") [3]. Обычно они содержат такие члены, логические "родители" которых находятся не на непосредственно вышестоящем уровне (см. рис. 1.4). Рис. 1.4 "Неровная" иерархия измерений Отметим, что несбалансированные и "неровные" иерархии поддерживаются далеко не всеми OLAP-средствами. Различным в разных OLAPсредствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений [9]. В отличие от линейных пространств, с которыми имеет дело алгебра матриц, многомерные модели, как правило, не предусматривают функций упорядочивания или расстояния для значений измерения. Единственное «упорядочивание» состоит в том, что значения более высокого уровня содержат значения более низких уровней. Однако для некоторых измерений, таких как время, упорядоченность значений размерности может использоваться для вычисления совокупной информации, такой как общий объем продаж за определенный период. В кубе, изображенном на рис.1.5, содержится 3 измерения – «Доставка» (характеризует вид доставки), «Отправка» (географическое местонахождение получателя посылки) и «Время» (время совершения факта отправки посылки). Каждое измерение содержит иерархию измерений, например, измерение 23 «Отправка» состоит из отправки в восточное полушарие и в западное. В свою очередь, восточное полушарие состоит из Африки, Азии, Австралии и Европы, а западное – из Северной и Южной Америк. Рис.1.5 Пример многомерного куба Как было сказано выше, многомерная модель данных предназначена для анализа информации. Единицей анализируемой информации считается когдалибо произошедший факт, т.е. факты представляют субъект — некий шаблон или событие, которые необходимо проанализировать. В большинстве многомерных моделей данных факты однозначно определяются комбинацией значений измерений. Факт существует только тогда, когда ячейка для конкретной комбинации значений не пуста. Каждый факт обладает некоторой гранулярностью, определенной уровнями, из которых создается их комбинация значений измерений. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:  факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами которых 24 являются телефонный звонок или снятие денег со счета с помощью банкомата);  факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;  факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);  факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Мера (или показатель) – это определяется фиксированным значение, набором которое измерений и однозначно количественно характеризует анализируемые факты. В вышеприведенном примере мерами являются количество отправленных посылок и время отправки последней посылки. Так можно сказать, что в Европу в четвертом квартале 1999 года было отправлено 696 посылок, и последняя была отправлена 15.12.99. Меры бывают трёх типов:  Аддитивные (additive) меры – допускающие агрегирование относительно любого измерения куба данных;  Неаддитивные (nonadditive) меры – которые агрегироваться ни по какому измерению куба данных; 25 не могут  Полуаддитивные (semiadditive) меры – которые допускают агрегирование относительно одних измерений и не допускают относительно других. Многомерная база данных естественным образом предназначена для определенных типов запросов:  Запросы вида slice и dice (срезы куба) — формирование подмножества многомерного массива данных, соответствующего единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Если рассматривать термин slice с позиции конечного пользователя, то наиболее часто его роль играет двумерная проекция куба (рис. 1.6). Срез dice отличается от slice тем, что это трёх- и болеемерная проекция куба. Фиксированное значение Срез Рис. 1.6 Операция среза (slice)  Запросы вида drill-down (детализация) и roll-up (обобщение) — взаимообратные операции, которые используют иерархию измерений и меры для агрегирования. Направление детализации/обобщения может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями. Например, если при анализе данных об объемах продаж в Северной Америке выполнить операцию drill-down для измерения "Регион", то на экране будут отображены такие его элементы как "Канада", "Восточные Штаты Америки" и "Западные Штаты Америки". В 26 результате дальнейшей детализации элемента "Канада" будут отображены элементы "Торонто", "Ванкувер", "Монреаль" и т. д  Запросы вида drill-across комбинируют кубы, которые имеют одно или несколько общих измерений. С точки зрения реляционной алгебры такая операция выполняет слияние (join).  Запросы вида ranking возвращают только те ячейки, которые появляются в верхней или нижней части упорядоченного определенным образом списка.  Поворот (rotating) куба дает пользователям возможность увидеть данные, сгруппированные по другим измерениям (рис. 1.7). Например, операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид. Измерение1 Измерение2 Измерение2 Измерение1 Вращение Измерение3 Измерение3 Рис. 1.7 Операция вращения Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию. 27 Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации. За 30 лет с момента своего возникновения технология многомерных баз данных прошла серьезную эволюцию. С недавних пор она стала реализовываться в решениях, предназначенных для массового рынка, а ведущие производители теперь выпускают многомерные ядра вместе со своими реляционными базами данных. Данные, которые необходимо анализировать, становятся все более распределенными. К примеру, это часто необходимо для выполнения анализа, при котором используются данные в формате XML, получаемые с определенных веб-сайтов. Растущая распределенность данных, в свою очередь, требует применения методов, которые позволяют легко добавлять новые данные в многомерные базы данных, тем самым, упрощая задачу создания интегрированного хранилища данных. Технология многомерных баз данных также применяется к новым типам данных, которые современные технологии зачастую не в состоянии адекватно анализировать. Наконец, технология многомерных баз данных все больше будет применяться там, где результаты анализа напрямую передаются в другие системы, тем самым, исключая участие человека в этом процессе. 1.3.1 Реализация многомерной модели данных Многомерная структура хранения данных может быть реализована с помощью многомерных БД или в системе управления реляционными БД с использованием схемы звезды (star schema) или схемы снежинки (snowflake schema) [7]. Схема звезды (рис. 1.8) является практически реляционным воплощением многомерной представления данных. Она является проекцией куба на «реляционную плоскость» и состоит из одной таблицы фактов (fact table) и 28 нескольких таблиц измерений (dimension table). Таблица фактов содержит по одной строке для каждого факта — минимально рассматриваемого атома анализируемого процесса. Рис.1.8 Схема звезды Например, для оптового склада фактом может служить факт продажи изделий. Полями таблицы фактов, помимо ключей, являются меры (measures), описывающие количественную характеристику факта, например, выручка от продажи изделий или количество проданных изделий. Таблицы измерений содержат собственно значения измерений, то есть информацию, характеризующую факты. Обычно это неизменяемые, либо редко изменяемые данные. Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов. Типичными измерениями процесса продажи будут «Покупатель», «Издание», «Время». Время является несколько особенным и практически необходимым измерением любого хранилища данных. Схема звезды не соответствует требованиям нормальной формы. С точки зрения нормализации таблицы измерений хранят избыточные данные. Но 29 избыточность оправдывается двумя соображениями. Во-первых, такая схема понятнее конечному пользователю. Во-вторых, запросы по БД будут выполняться быстрее за счет уменьшения количества таблиц, объединяемых в одном запросе. Рис.1.9 Схема снежинки Схема снежинки является модификацией схемы звезды, как бы уступкой нормализации — здесь часть таблиц измерений разбита на несколько связанных таблиц (рис. 1.9). В случае если в нескольких измерениях повторяются одни и те же данные (например, адрес может встречаться и в измерении «Покупатель» и «Распространитель») необходимо выделить общее географическое измерение, содержащее атрибуты «географических точек». Благодаря частичной нормализации, «снежинка» позволяет сэкономить дисковое пространство, но она уменьшает скорость просмотра измерений. Решение в сторону использования схемы звезды или схемы снежинки, обуславливается относительной мощностью платформы БД, и инструментария для реализации запросов. Схема снежинки подходит окружению, в котором инструментарий реализации запросов предоставляет пользователям широкий 30 доступ к структуре таблиц, а также в окружениях, где большинство запросов просты по своей природе. Схема звезды более подходит для случаев применения более сложного инструментария для реализации запросов, который в большей степени изолирует пользователей от детальной структуры таблиц, а также для среды с множеством запросов сложной структуры. 1.4 Классификация OLAP-продуктов Итак, суть OLAP заключается в том, что исходная для анализа информация представляется в виде многомерного куба, и обеспечивается возможность произвольно манипулировать ею и получать нужные информационные разрезы - отчеты. При этом конечный пользователь видит куб как многомерную динамическую таблицу, которая автоматически суммирует данные (факты) в различных разрезах (измерениях), и позволяет интерактивно управлять вычислениями и формой отчета. Выполнение этих операций обеспечивается OLAP-машиной (или машиной OLAP-вычислений). На сегодняшний день в мире разработано множество продуктов, реализующих OLAP-технологии. Чтобы легче было ориентироваться среди них, используют классификации OLAP-продуктов: по способу хранения данных для анализа и по месту нахождения OLAP-машины. Рассмотрим подробнее каждую категорию OLAP-продуктов. 1.4.1 Классификация по способу хранения данных Начнем рассмотрение с классификации по способу хранения данных. Часто в многомерных хранилищах данных содержатся и агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных — сократить время выполнения запросов, поскольку в большинстве случаев для 31 анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому, обычно, при загрузке данных в многомерную БД вычисляются и сохраняются некоторые агрегатные данные. И исходные и агрегатные данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP) [2]. Соответственно, OLAPпродукты по способу хранения данных делятся на три аналогичные категории:  в случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе;  в ROLAP-продуктах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства;  в случае использования HOLAP архитектуры исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAPсредства на основе реляционных и многомерных данных. Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о «взрывном росте» объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных приемлемой скорости выполнения запросов. 32 агрегатных данных достичь Некоторые OLAP-продукты поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако большинство современных серверных OLAP-продуктов поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. 1.4.2 Классификация по месту размещения OLAP-машины Следующая классификация - по месту размещения OLAP-машины. По этому признаку OLAP-продукты делятся на OLAP-серверы и OLAP-клиенты:  в серверных OLAP-средствах вычисления и хранение агрегатных данных выполняются отдельным процессом – OLAP-сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере;  OLAP-клиент устроен по-другому. Построение многомерного куба и OLAPвычисления выполняются в памяти клиентского компьютера. Сравним серверные и клиентские OLAP-средства по эксплуатационным и стоимостным показателям: 1. Объем обрабатываемых совокупностью количество данных. следующих измерений, Объем характеристик: количество данных определяется количество элементов записей, измерений, длина измерений и количество фактов. OLAP-сервер может обрабатывать большие объемы данных, чем OLAP-клиент при равной мощности компьютера. Это объясняется тем, что OLAP-сервер хранит на жестких дисках многомерную базу данных, содержащую заранее вычисленные кубы. Клиентские программы в момент выполнения OLAP-операций выполняют к ней запросы на SQL-подобном языке, получая не весь куб, а 33 его отображаемые фрагменты. OLAP-клиент в момент работы должен иметь в оперативной памяти весь куб. Таким образом, объем данных, обрабатываемых OLAP-клиентом, находится в прямой зависимости от объема оперативной памяти ПК пользователя. 2. Производительность следующими системы. факторами: Эта объемом характеристика обрабатываемых определяется данных и мощностью компьютеров. При возрастании количества измерений производительность всех OLAP-средств снижается за счет значительного увеличения количества агрегатов, но при этом темпы снижения разные. Продемонстрируем эту зависимость на графике (рис. 1.10): Рис. 1.10 Зависимость времени отклика OLAP-средства от объема обрабатываемых данных Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и OLAP-клиентом. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки", в то время как OLAP-клиент вычисляет весь набор агрегатов в момент загрузки. 34 3. Сетевой трафик. При использовании OLAP-сервера по сети на ПК клиента передаются только данные для отображения, в то время как OLAP-клиент получает весь объем данных первичной выборки. Поэтому там, где применяется OLAP-клиент, сетевой трафик будет выше. Но, при применении OLAP-сервера операции пользователя, например детализация, порождают новые запросы к многомерной базе, а, значит, новую передачу данных. Выполнение же OLAP-операций OLAP-клиентом производится в оперативной памяти и, соответственно, не вызывает новых потоков данных в сети. Также необходимо отметить, что современное сетевое оборудование обеспечивает высокий уровень пропускной способности. 4. Затраты на внедрение и сопровождение. Стоимость OLAP-сервера достаточно высока. Дополнительно следует учитывать стоимость выделенного сервера и постоянные затраты на администрирование многомерной базы. Кроме того, внедрение и сопровождение OLAPсервера требует от персонала достаточно высокой квалификации. Стоимость OLAP-клиента на порядок ниже стоимости OLAP-сервера. Администрирования и дополнительного технического оборудования под OLAP-клиент не требуется. К квалификации персонала при внедрении OLAP-клиента высоких требований не предъявляется. OLAP-клиент может быть внедрен значительно быстрее OLAP-сервера. Разрабатываемый модуль многомерного анализа данных для системы поддержки принятия управленческих решений по требованию заказчика должен быть исполнен в виде тонкого клиента (веб-приложения), поэтому в такой системе может быть использован только OLAP-сервер, а не OLAP-клиент. В разд. 3 проводится исследование возможностей современных OLAP-серверов и выбор наиболее подходящего для разрабатываемого OLAP-модуля, но перед 35 этим следует сказать несколько слов о непосредственной области применения разрабатываемого модуля. По разделу 1 нужны выводы И нужно посмотреть все ли, про что в нем говорилось, используется в разработке, лишнее убрать 2. Исследование предметной области Разрабатываемый модуль многомерного анализа данных является частью автоматизированной информационной системы поддержки принятия решений по выполнению предприятиями радиоэлектронной промышленности мероприятий ГПВ, ФЦП и ГОЗ (в дальнейшем СППР РЭП). 2.1 Цели и задачи СППР РЭП СППР РЭП предназначена для принятия решений по управлению развитием предприятий отрасли в интересах повышения эффективности и устойчивости их функционирования, снижения рисков невыполнения заданий ФЦП, ГПВ и ГОЗ на основе методов ситуационного управления. Основными задачами СППР РЭП являются:  получение и обработка информации о ходе выполнения программных мероприятий и поддержания в актуальном состоянии системы исходных данных для оценки и прогнозирования состояния предприятий отрасли, а также оценки рисков невыполнения мероприятий ФЦП, ГПВ и ГОЗ;  интеграция с существующими информационными содержащими информацию по предприятиям отрасли; 36 системами,  ввод и корректировка исходной информации поддержки принятия управленческих решений;  автоматизированная экономического обработка и информации текущего финансово- производственно-технологического состояния организаций радиоэлектронной промышленности:  оценка рисков невыполнения предприятиями отрасли программных мероприятий ФЦП и заданий ГОЗ;  оценка и прогнозирование состояния предприятий радиоэлектронной отрасли;  многомерный анализ информации в части состояния предприятий радиоэлектронной промышленности, хода выполнения мероприятий ФЦП, ГОЗ и ГПВ;  поддержку программных принятия управленческих мероприятий ФЦП, решений заданий по ГОЗ реализации и развитию радиоэлектронной отрасли. 2.2 Структура СППР РЭП Вставить картинку из Visio 2.3 Основные объекты автоматизации СППР РЭП Основными объектами автоматизации СППР РЭП являются программы и мероприятия. Программа составляется на определённых срок и состоит из набора мероприятий, подлежащих к выполнению организациями- исполнителями в течение указанного срока. Как у мероприятия, так и у программы в целом существуют вероятностные значения рисков невыполнения и ожидаемый ущерб в случае их невыполнения. Программа формируется из предложений, поступающих от государственных заказчиков, и в случае принятия предложения оно становится 37 мероприятием программы. По специальным методикам пользователь системы может оценить стоимость и риски предложений. Для мероприятий по методике анализа иерархий (МАИ) выбирается оптимальная организация-исполнитель. Данные об организациях-исполнителях периодически обновляются в БД из внешних источников данных. Эти данные включают в себя контактные данных организации, а также и финансовоэкономические, производственные и другие виды показателей. Пользователь может создавать несколько вариантов для одной и той же программы, чтобы впоследствии сравнить полученные варианты и выбрать наиболее оптимальный. После выбора наиболее оптимального варианта программа подлежит утверждению и в случае утверждения приобретает соответствующий статус, после чего все стоимостные характеристики программы становятся нередактируемыми. Таким образом, можно выделить следующие сущности:  Программа. Существует несколько видов программ: федеральная целевая программа, государственная программа перевооружения и государственный оборонный заказ. Характеризуется целью, сроками, описанием и ожидаемым результатом от выполнения программы.  Предложение. Характеризуется общей стоимостью, сроками выполнения, вероятностью срыва, ущербом от срыва. Состоит из нескольких этапов, длительностью определённому и каждый из стоимостью. направлению которых характеризуется Предложение деятельности привязано к (например, сверхвысокочастотная электроника)  Мероприятие. Это предложение, включенное в программу. Отличается от предложения тем, что на мероприятие уже 38 выделяется финансирование из бюджетных и внебюджетных средств.  Организация-исполнитель. Она выполняет мероприятия программы. Характеризуется контактной информацией (почтовый адрес, юридический адрес, телефон, e-mail и др.), а также набором финансово-экономических, производственных и других показателей. Более подробно модель данных СППР РЭП представлена в приложении №. 2.4 Требования к разрабатываемому модулю для СППР РЭП Основное назначение разрабатываемого в ВКР модуля многомерного анализа данных – это предоставление аналитику информации в удобной форме. Данный модуль позволит решить следующие задачи:  анализ хода выполнения программы в целом и каждого конкретного мероприятия в частности;  анализ трендов показателей предприятий;  анализ оценочной стоимости предложений;  анализ степени рисков невыполнения мероприятий и возможного ущерба при невыполнении;  анализ подготовленных вариантов программ. Функциональные требования, предъявляемые к разрабатываемому модулю:  возможность просмотра данных из хранилища данных в любом удобном представлении (т.е. выполнение любых многомерных кубов);  автоматический подсчёт суммарных значений;  возможность поиска и фильтрации исходных данных; 39 срезов  сохранение и печать результатов анализа. Нефункциональные требования, предъявляемые к разрабатываемому модулю:  минимизация скорости реакции интерфейса (время отклика должно составлять не более 5 с);  возможность быстрого освоения интерфейса;  наличие дружественного и удобного интерфейса;  возможность использования модуля во всех популярных браузерах: Internet Explorer, Firefox, Safari и Opera. 40 3. Исследование возможностей современных OLAP- серверов Перед разработкой модуля многомерного анализа данных автору ВКР была поставлена задача провести исследование возможностей современных OLAP-серверов и выбрать наиболее подходящий. Эта глава посвящена решению поставленной задачи. На сегодняшний день существует множество поставщиков OLAP-серверов. Все крупные поставщики СУБД, такие как Oracle, Microsoft, IBM, Sybase, выпускают также и OLAP-сервера к своим СУБД. Помимо крупнейших производителей СУБД на рынке OLAP-продуктов фигурируют и другие компании, работающие в области Business Intelligence, такие как MicroStrategy, Pentaho, SAS Institute, Jedox. Все современные OLAP-серверы удовлетворяют принципам аналитической обработки в реальном времени, изложенным Коддом в 1993 году (см. подразд. 1.1), а позднее дополненными в 1995 году. Основными проблемами использования OLAP-серверов являются проблемы производительности, разреженности данных и «взрыва» данных. Проблема производительности связана к требованию к OLAP-продукту – времени отклика сервера (которое должно быть не более 5 с). Такое время сложно достичь, учитывая, что часто объём анализируемых данных превышает миллионы записей. Производители по-разному решают данную проблему, но в основном, решения основываются на кешировании сосчитанных агрегатов, либо на предварительном их вычислении и хранении в базе данных. 41 Второй способ решения проблемы производительности порождает новую проблему – проблему эффекта «взрыва данных», т.е. к резкому увеличению объёма хранимых данных, т.к. количество хранимых агрегатов растёт в экспоненциальной зависимости от числа измерений в кубе. Синдром взрыва может приводить к еще большим проблемам при разреженном распределении исходных данных по многомерному кубу. Отсутствующие или недопустимые значения данных создают разрежение в модели данных OLAP. Наиболее удачные OLAP-серверы борются с этой проблемой, не сохраняя пустые значения, таким образом, даже плохо заполненные кубы «не раздуваются» в объеме. OLAP-серверы отличаются друг от друга гораздо больше, чем, например, реляционные базы данных, языки программирования или текстовые редакторы, что весьма увеличивает возможность ошибки при выборе OLAPсервера. Все современные OLAP-серверы могут работать одновременно с несколькими кубами, поддерживать работу с большим числом измерений, мер и иерархий. Некоторые продукты поддерживают несколько иерархий для измерения, несбалансированные иерархии, полуаддитивные меры и некоторые другие функции, такие как «write-back», позволяющую аналитику изменить какое-либо значение в таблице-отчёте (это нужно, например, для прогнозирования - узнать, как изменится отчёт, если поменять значение в указанной ячейке) и сохранить его в хранилище данных. У каждого продукта свои протоколы обмена информацией и языки запросов к многомерным кубам – в области OLAP до сих пор нет каких-либо стандартизованных протоколов обмена информацией, но при этом почти каждый OLAP-сервер поддерживает стандарты «де факто» обмена информацией – XMLA (XML for Analysis) и языка запросов к многомерным данным фирмы Microsoft – MDX (Multidimensional Expressions) [6]. 42 В виду достаточно большого количества производителей OLAP-серверов было принято решение рассмотреть только наиболее известные и долго работающие на рынке фирмы, а также ряд бесплатных продуктов. Таким образом, были выбраны следующие продукты (табл. 3.1): Таблица 3.1 Исследуемые OLAP-сервера № Фирма-производитель Название OLAP-сервера 1 Microsoft Analysis Services 2 Oracle Essbase 3 IBM Cognos TM1 4 Pentaho Mondrian 5 Jedox Palo 3.1 Выбор критериев для сравнения Для исследования возможностей и сравнения OLAP-серверов нужно определить критерии, по которым данные продукты можно сравнивать. При выборе критериев автор ВКР исходил, прежде всего, из требований к разрабатываемой системе, а также некоторых решений, принятых в ходе проектирования системы:  система принятия решений реализуется как клиент-серверное приложение, причём клиент – это веб-браузер пользователя, т.е. тонкий клиент;  в системе используется БД PostgreSQL;  не исключено, что в системе будут использоваться и другие источники данных, например, таблицы Excel;  объём входной информации для анализа – средний, не превышает 100 тыс. записей;  частота изменений в данных – исходные данные изменяются нечасто; 43  число пользователей разрабатываемой системы – не более 50;  система будет развёрнута в ведомственной локальной сети с большой скоростью передачи данных (100 Мбит/с);  система (серверная часть) разрабатывается на языке программирования Java;  разрабатываемая система развёртывается в Unix-подобной среде;  система визуализации OLAP-анализа будет реализована с использованием продукта JPalo;  система принятия решений достаточно сложная система с точки зрения математических вычислений – в ней используются элементы теории вероятностей и статистики, т.е. многие параметры, подлежащие дальнейшему OLAP-анализу, вычисляются по сложным формулам;  требование к бюджету – получение работоспособной системы за минимальные трудозатраты и стоимость используемого программного обеспечения;  относительно небольшой срок разработки системы (5 месяцев). Исходя из вышеперечисленных факторов, были следующие критерии: 1. Список поддерживаемых СУБД 2. Список поддерживаемых форм хранения данных (MOLAP/ROLAP/HOLAP) 3. Возможность создания вычисляемых меток. Используя вычисляемые метки, можно включить в многомерную базу измерения и меры, которых нет в исходных данных, но которые можно вычислить по формуле 4. Возможность создания пользовательских агрегирующих функций. Помимо стандартных агрегирующих функций, таких как сумма и среднее значение, должна 44 быть предусмотрена возможность создания пользовательских функций, вычисляющих агрегат по определённой формуле 5. Оптимизация схемы агрегирования, т.е. возможность изменения количества вычисленных заранее агрегатов. Чем больше агрегатов хранится в готовом виде, тем выше производительность системы и тем меньше среднее время ответа на запрос. В то же время, увеличение количества хранимых агрегатов приводит к увеличению объема хранимых данных. Возможность сохранять только те агрегаты, которые наиболее часто используются в запросах пользователей, позволяет получить наименьший объем хранилища данных при максимальной производительности для наиболее популярных запросов к БД. Поэтому данный критерий достаточно важен при выборе оптимального OLAP-сервера. 6. Масштабируемость, т.е. возможность работы с различными объемами данных: от очень маленьких (менее 10 тыс. записей) до очень больших (более 1 млн. записей) без изменения состава программного продукта. 7. Удобные средства создания кубов и администрирования 8. Решение проблемы «взрыва данных» 9. Решение проблемы разреженности данных 10. Список поддерживаемых визуализации API OLAP-анализа, и языков используемое запросов. в Средство разрабатываемой системе (JPalo) должно поддерживать взаимодействие с OLAPсервером. 11. Поддержка Unix-подобных операционных систем 12. Безопасность. Часто бывает, что анализируемые данные представляют коммерческую тайну и поэтому при передаче должны быть зашифрованы. Но так как разрабатываемая система будет 45 функционировать в пределах ведомственной локальной сети, то этот пункт является некритичным при выборе оптимального OLAP-сервера. 13. Документирование. Учитывая, что проект выполняется в сжатые сроки, необходимо потратить как можно времени на изучение продукта, поэтому OLAP-сервер должен иметь хорошую документацию. 14. Цена продукта на минимальную конфигурацию Выбрав критерии для сравнения OLAP-серверов, можно перейти к рассмотрению каждого конкретного сервера. 3.2 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 поддерживает создание пользовательских агрегирующих функций 5. MSAS предусматривает оптимизацию схемы агрегирования. Используя Storage Design Wizard можно найти компромисс между быстродействием системы и размером хранимых на диске агрегатов. 6. MSAS поддерживает гибкую модель масштабирования, включающую оптимизацию хранения, компрессию данных и распределённые вычисления (т.е. часть вычислений можно перенести на клиент). 46 7. MSAS содержит множество различных «мастеров» и «дизайнеров» по созданию кубов, измерений, иерархий и администрированию. 8. Проблема «взрыва данных» в MSAS решена. 9. Проблема разреженности данных в MSAS также решена (посредством компрессии данных) 10. MSAS поддерживает спецификации OLE DB, ADO DB, XMLA. Язык запросов к многомерным данным – MDX 11. MSAS может быть установлен только на ОС Windows совместно с Microsoft SQL Server 12. MSAS поддерживает широкий спектр протоколов безопасности, таких как NTLM, Kerberos, SSL. Безопасность обеспечивается на уровне ячейки куба, т.е. доступ проверяется не к конкретному кубу или измерению, а к конкретной ячейке в кубе 13. MSAS очень подробно документирован. Документация на русском языке. 14. Стоимость SQL Server 2008 Workgroup Edition - 4000$ Следует отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 3.3 Oracle Essbase Oracle Essbase (в дальнейшем Essbase) – первый в мире OLAP-сервер. Расшифровывается как Extended Spread Sheet dataBASE. Данный сервер изначально создавался фирмой Hyperion как расширение электронных таблиц Lotus 1-2-3 и Microsoft Excel, но впоследствии в 2007 году Oracle купил Hyperion и переименовал продукт в Oracle Essbase. Последняя версия - Oracle Essbase V.11.1.2 1. Essbase поддерживает только свою БД – Oracle 2. Essbase поддерживает 2 вида хранения данных: MOLAP и HOLAP 47 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 собственный протокол безопасности, но он также поддерживает аунтефикацию по LDAP и протокол шифрования SSL. Безопасность обеспечивается на уровне ячейки куба 13. Essbase, так же как и MSAS, очень подробно документирован. Документация на русском языке. 14. Стоимость Oracle Essbase V.11.1.2– 40 000 $ Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 48 3.4 IBM Cognos TM1 Изначально продукт разрабатывался фирмой Cognos, но в 2009 году Cognos была поглощена компанией IBM и продукт был переименован в IBM Cognos TM1. Основное отличие TM1 от предыдущих двух серверов заключается в том, что это запатентованный 64-разрядный OLAP-сервер, использующий подход In-memory OLAP. Данный подход подразумевает кеширование исходных данных и агрегатов в оперативной памяти, тем самым увеличивая производительность сервера. Последняя версия - Cognos TM1 9.5 1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется дополнительный инструмент Turbo Integrator, поддерживающий большинство существующих БД, в том числе и PostgreSQL. Подключение в данном случае происходит через ODBC-драйвер 2. TM1 поддерживает один вид хранения данных - MOLAP 3. TM1 поддерживает создание вычисляемых меток 4. TM1 поддерживает создание пользовательских агрегирующих функций. 5. Помимо кеширования TM1 позволяет сохранять подсчитанные агрегаты в БД, тем самым предусматривается гибкая оптимизация схемы агрегирования. 6. TM1 поддерживает гибкую модель масштабирования, включающую кластеризацию, функции отказоустойчивости, оптимизацию хранения и компрессию данных. 7. TM1 содержит удобный графический интерфейс, встраиваемый в Microsoft Excel, а также собственный Web-интерфейс. 8. Проблема «взрыва данных» в TM1 решена. 9. Проблема разреженности данных в TM1 также решена. 49 10. TM1 поддерживает спецификации OLE DB, XMLA. Язык запросов к многомерным данным - MDX 11. TM1 может быть установлен как на ОС Windows, так и на Unixподобную ОС 12. У TM1 свой протокол безопасности, но он также поддерживает аунтефикацию по LDAP и протокол шифрования SSL. Безопасность обеспечивается на уровне ячейки куба 13. TM1, так же как Essbase и MSAS, очень подробно документирован. Документация на русском языке. 14. Стоимость IBM TM1 – 50 000 $ Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 3.5 Pentaho Mondrian В отличие от вышеперечисленных OLAP-серверов данный продукт является открытым и распространяется под лицензией EPL. Mondrian написан на Java, что с одной стороны уменьшает быстродействие (ввиду java-машины), но с другой – добавляет кроссплатформенность. Так же, как и IBM TM1, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Pentaho Analysis. Последняя версия сервера - Mondrian 3.0.4 1. Для подключения к хранилищам данных Mondrian используется JDBCдрайвер. Таким образом, сервер поддерживает БД, к которым можно подключаться через JDBC, в том числе PostgreSQL 2. Mondrian поддерживает только один вид хранения данных - ROLAP 3. Mondrian поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX. 50 4. Mondrian не поддерживает создание пользовательских агрегирующих функций. 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. Сервер документирован достаточно хорошо, но только на английском языке. 14. Стоимость Mondrian – бесплатно. Кроме того доступны исходные коды проекта. Следует отметить, что данный продукт поддерживает все типы иерархий, но не поддерживает полуаддитивные меры и функцию «write-back». 3.6 Jedox Palo Данный продукт, так же как Mondrian является открытым и распространяется под лицензией GPL. Так же, как IBM TM1 и Mondrian, данный 51 сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Palo Suite. Последняя версия сервера - Palo 3.1 1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется продукт Palo ETL Server, поддерживающий большинство существующих БД, в том числе и PostgreSQL. 2. Palo поддерживает только один вид хранения данных - MOLAP 3. Palo поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX. 4. Palo не поддерживает создание пользовательских агрегирующих функций. 5. Palo хранит все агрегаты в оперативной памяти. Не существует возможности сохранять агрегаты на жёстком диске. Стоить отметить, что сервер использует процессор видеоадаптера (GPU), что способствует уменьшению времени вычисления агрегатов. 6. Palo масштабируем с точки зрения увеличения исходных данных. Palo очень эффективно использует ресурсы процессоров (CPU и GPU), поэтому сервер хорошо масштабируем в сторону увеличения количества процессов (ядер процессоров). Функций кластеризации и отказоустойчивости у сервера нет 7. Palo содержит достаточно удобный графический интерфейс для создания кубов и администрирования сервера. Palo может быть встроен в Microsoft Excel и в Open Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка. 8. Проблема «взрыва данных» в Palo решена. 9. Проблема разреженности данных в Palo также решена. 52 10. Palo поддерживает API для языков Java, C/C++, PHP, .NET и спецификации OLE DB и XMLA. Язык запросов к многомерным данным - MDX 11. Palo может быть установлен как на ОС Windows, так и на Unixподобную ОС 12. Безопасность обеспечивается на уровне ячейки куба. Передаваемые данные не шифруются 13. Сервер документирован достаточно хорошо, но только на английском языке. 14. Стоимость Palo – бесплатно. Кроме того доступны исходные коды проекта. Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 3.7 Результаты Объединим результаты сравнения OLAP-серверов в одну сводную таблицу: Таблица 3.2 Сравнение OLAP-серверов Критерий/OLAP-сервер MSAS Essbase TM1 Mondrian Palo Поддержка PostgreSQL - - + + + Поддерживаемые формы хранения данных (MOLAP/ROLAP/HOLAP) (+/+/+) (+/-/-) (+/-/-) (-/+/-) (+/-/-) Создание вычисляемых меток + + + + + Создание пользовательских агрегирующих функций + + + - - Оптимизация схемы + + + + - 53 агрегирования Масштабируемость + + + + + Удобные средства создания кубов и администрирования + + + + + Решение проблемы «взрыва данных» + + + + + Решение проблемы разреженности данных + + + + + Поддержка XMLA и MDX + + + + + Поддержка Unixподобных операционных систем - + + + + Обеспечение безопасности + + + - - Подробное документирование на русском языке + + + - - 4000$ 40000$ 50000$ беспл. беспл. Цена продукта на минимальную конфигурацию В исследовании было использовано хранилище данных объемом порядка 100 тыс. записей. Каждый продукт устанавливался на специально выделенный сервер со следующими характеристиками: CPU – Xeon (4 ядра, 2800 МГц), ОЗУ – 4 Гб, ОС – Microsoft Windows 2008 Server. Хранилище данных располагалось на другом сервере. Скорость соединения между серверами – 100 Мбит/с. Для каждого OLAP-сервера создавался небольшой OLAP-куб, содержащий 4 измерения, 3 меры (причём, одну вычисляемую меру) и одну пользовательскую агрегирующую функцию (кроме Mondrian, т.к. он их не поддерживает). OLAPкуб визуализировался с использованием продукта JPalo, запущенным в браузере Internet Explorer 7.0 54 В ходе проведённого исследования можно сделать следующие выводы:  все рассматриваемые продукты полностью соответствуют принципам аналитической обработки в реальном времени, изложенным Коддом, и тесту FASMI (см. подразд. 1.1);  у платных продуктов очень гибкая схема масштабирования, включающая кластеризацию, функции отказоустойчивости;  платные продукты поддерживают все типы иерархий и мер, а также функцию «write-back»;  платные продукты очень подробно документированы (на русском языке);  все рассматриваемые продукты поддерживают создание вычисляемых меток;  бесплатные продукты не поддерживают создание пользовательских агрегирующих функций;  во всех продуктах решена проблема «взрыва данных» и разреженности данных;  все рассматриваемые продукты поддерживают спецификацию XMLA и язык запросов к многомерным данным - MDX;  TM1, Mondrian, Palo используют принцип In-Memory OLAP, что увеличивает быстродействие OLAP-сервера;  во всех продуктах безопасность обеспечивается на уровне ячейки куба, т.е. доступ проверяется не к конкретному кубу или измерению, а к конкретной ячейке в кубе;  Mondrian и Palo имеют открытый исходный код. Для разрабатываемой системы было принято решение использовать OLAP-сервер Pentaho Mondrian, главным образом исходя из следующих соображений:  Стоимость - сервер Mondrian абсолютно бесплатен 55  Открытость исходного кода. Так как сервер не поддерживает создание пользовательских агрегирующих функций (в отличие от платных серверов), то существует возможность доработать сервер и добавить недостающую функциональность (решение этой проблемы описано в подразд. 4.3). Mondrian, в отличие от Palo (который также имеет открытый исходный код и не поддерживает пользовательские агрегирующие функции), написан на языке Java, с которым автор ВКР давно знаком  Графический интерфейс создания и администрирования кубов у Mondrian оказался удобнее, чем у Palo 56 4. Разработка хранилища данных и многомерных OLAPкубов Для разработки модуля многомерного анализа необходимо, прежде всего, подготовить хранилище данных, которое будет являться источником анализируемых данных. Данные в хранилище данных обновляются с определённой периодичностью (один раз в неделю) и поэтому немного «отстают» от актуальных данных, но для анализа информации за большие промежутки времени это не является проблемой. Хранилище данных также было решено реализовывать в СУБД PostgreSQL, потому что сопровождать БД одного производителя легче, чем разных. Данные в хранилище организованы по-другому, нежели в исходной БД. Хранилища обычно организуются по схеме звезды или снежинки (см. подразд. 1.3.1). Поэтому для обновления данных в хранилище необходимо применять некоторые модификации к исходным данным. Такой процесс преобразования данных называется ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка»), включающий в себя:  извлечение данных из внешних источников;  их трансформация и очистка (англ. Data cleansing), чтобы они соответствовали нуждам бизнес-модели;  и загрузка их в хранилище данных. В данной работе для реализации ETL-процесса использовалось средство Pentaho Kettle, так как оно является бесплатным и сочетает в себе хорошую функциональность и удобный графический интерфейс. Kettle оперирует такими понятиями как преобразование (transformation) и задание (job). Задание – это специально описанная в виде направленного 57 графа последовательность преобразований данных и условий, в зависимости от которых будет выбираться направление обхода графа. Описать ETL-процесс в Kettle – означает построить направленный граф, узлами которого являются операции преобразования данных, задания и некоторые другие элементы, такие как работа с файловой системой, условиями, сценариями, электронной почтой и др. Входными источниками данных для Kettle могут быть:  таблицы в БД (любого производителя);  таблицы Microsoft Excel;  текстовые и XML файлы;  данные, полученные из RSS-канала;  данные, полученные по LDAP (например, учётные записи пользователей домена);  Kettle может заполнить входные данные псевдослучайными значениями. Исходя из задач, которые должен выполнять разрабатываемый модуль (см. подразд. 2.4), было решено создать следующие многомерные кубы:  куб «Анализ показателей организаций-исполнителей», показывающий основные тренды развития организаций;  куб «Анализ стоимости мероприятий», отображающий финансирование мероприятий;  куб «Анализ рисков и оценочной стоимости предложений», показывающий параметры рисков предложений и их оценочную стоимость. Все многомерные кубы было решено реализовывать по схеме звезда ввиду времени выполнения запросов к БД – схема звезды по сравнению со схемой снежинки снижает время выполнения запросов за счет уменьшения количества таблиц, объединяемых в одном запросе. 58 Схема звезды, состоящая из таблиц измерений и таблицы фактов, – это «приближённая» реализация многомерной модели данных в реляционной БД, неучитывающая иерархий измерений, агрегирующих функций для мер и некоторых других факторов. Поэтому для ROLAP-серверов необходимо дополнительно явным образом определять иерархии измерений, меры и типы агрегирующих функций, применяемых к мерам. Эти данные описываются в программе Workbench и сохраняются в виде XML-файла. Таким образом, можно выделить следующий алгоритм создания куба: 1. Спроектировать многомерный куб – выделить необходимые измерения, иерархии и меры 2. На основании предыдущего пункта создать в хранилище данных соответствующие таблицы измерений и фактов 3. В программе Pentaho Mondrian Workbench описать все измерения, иерархии и меры 4. В программе Pentaho Kettle создать сценарий преобразования данных из операционной БД в хранилище данных 5. Настроить созданный сценарий на периодическое выполнение (например, раз в неделю) 6. Выполнить сценарий преобразования данных Остановимся подробнее на каждом разрабатываемом многомерном кубе, так каждый из них содержит разные по сложности сценарии преобразования данных, при написании которых автор сталкивался с различными проблемами. Модель данных операционной БД приведена в приложении №? в виде ER-диаграммы. 59 4.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). Спроектированная для куба схема звезды изображена на рис.4.1: 60 Рис. 4.1 Модель хранилища данных для куба «Анализ показателей организаций-исполнителей» Для преобразования данных из оперативной БД в хранилище воспользуемся следующим сценарием, построенным в программе Kettle (рис. 4.2): Рис. 4.2 Сценарий преобразования данных для куба «Анализ показателей организаций-исполнителей» 61 Одной из первых проблем, с которой столкнулся автор, была проблема обновления данных в хранилище, т.е. перенос в хранилище не всех данных, а только изменённых и добавленных после последнего запуска сценария преобразования. У данной проблемы есть несколько путей решения:  использование временных меток создания записи для каждого кортежа в оперативной БД и затем при выборе данных из БД дополнительно в каждый SQL-запрос вставлять условие WHERE;  использование элемента «Поиск и обновление» (combination lookup/update) в качестве промежуточного элемента в сценарии преобразования данных. В данной работе использовался второй способ, т.к. он не требует внесений изменений в структуру оперативной БД. Рассмотрим данный способ на примере. На рис. 4.2 приведён сценарий преобразования данных для разрабатываемого куба, состоящий из четырёх этапов преобразования. Каждый этап загружает данные в таблицы хранилища и состоит из нескольких шагов (рис. 4.3): Рис. 4.3 Шаги типичного этапа преобразования 62 На первом шаге по определённому SQL-запросу выбираются данные из оперативной БД. SQL-запрос может включать в себя как просто выборки и соединения таблиц из оперативной БД, так и некоторые преобразования над выбранными данными. Ниже приведены SQL-запросы, используемые в сценарии: Таблица 4.1 SQL-запросы, применяемые для загрузки исходных данных Этап Заполнение organization_dim SQL-запрос SELECT o.id, o.short_name AS name, r.id AS region_id, r.name AS region_name, c.id AS city_id, c.name AS city_name, f.id AS fedokrug_id, f.name AS fedokrug_name FROM organization o JOIN city c ON o.city_id = c.id JOIN region r ON o.region_id = r.id JOIN fed_okrug f ON r.fedokrug_id = f.id; Заполнение prod_indicator_dim SELECT pi.id, pi.name, pig.id AS group_id, pig.name AS group_name FROM prod_indicator pi JOIN prod_indicator_group pig ON pi.prod_indicator_group_id = pig.id; Заполнение prod_indicator_timedim SELECT piv.year || '_' || piv.quarter AS id, piv.year, piv.quarter, CASE WHEN piv.quarter = 1 THEN 'I квартал' WHEN piv.quarter = 2 THEN 'II квартал' WHEN piv.quarter = 3 THEN 'III квартал' WHEN piv.quarter = 4 THEN 'IV квартал' END AS quarter_name FROM prod_indicator_value piv GROUP BY 1,2,3 ORDER BY 1,2,3; Заполнение prod_indicator_fact SELECT piv.id, piv.prod_indicator_id, piv.year || '_' || piv.quarter AS time_id, piv.organization_id, piv.value, piv.forecast_value FROM prod_indicator_value piv; На следующем шаге происходит проверка выбранных записей на предмет их существования в хранилище. Если выбранная запись уже существует и не 63 изменялась с момента последнего запуска сценария преобразования данных, то такая запись отбрасывается и не поступает на следующий шаг. На последнем шаге происходит загрузка данных в хранилище. На данном шаге выбирается таблица-получатель и указывается соответствие между полями исходных данных и таблицы-получателя. После написания сценария преобразования данных в программе Pentaho Mondrian Workbench осталось описать измерения, иерархии, меры и типы агрегирующих функций для мер. В данном кубе для мер была выбрана агрегирующая функция avg (среднее значение). Таким образом, при просмотре информации за какой-либо период времени пользователю будет выдаваться именно среднее значение показателя. Разработанный куб решает поставленную задачу анализа трендов показателей предприятий. С его помощью можно проанализировать изменения значений показателей предприятий за какой-либо промежуток времени, сравнивать организации, находить среднее значение показателя организации за определённый промежуток времени и многое другое. 4.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 Для преобразования данных из оперативной БД в хранилище воспользуемся следующим сценарием, построенным в программе Kettle (рис. 4.5): Рис. 4.5 Сценарий преобразования данных для куба «Анализ стоимости мероприятий» Этапы данного сценария аналогичны этапам предыдущего сценария (см. подразд. 4.1), поэтому не будут подробно рассматриваться. Ниже приведены 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 (сумма). Таким образом, при просмотре информации за какой-либо период времени пользователю будет выдаваться сумма денежных средств. 4.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 Модель хранилища данных для куба «Анализ рисков и оценочной стоимости предложений» Для преобразования данных из оперативной БД в хранилище воспользуемся следующим сценарием, построенным в программе 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 тыс. руб. Тогда в хранилище данных должна быть записана следующая информация: за 2011 год на этап ожидается выделить 5/9 млн. руб, а за 2012 – 4/9 млн. руб, где  5 – продолжительность этапа в 2011 году (в месяцах);  4 – продолжительность этапа в 2012 году (в месяцах);  9 – продолжительность выполнения этапа (в месяцах). Аналогичным образом преобразуется ожидаемый ущерб. Вероятность срыва этапа в 2011 году равна 0.35/9, а в 2012 – 0.34/9, т.к. вероятность наступления одновременно всех событий, равна произведению вероятностей наступления каждого из них. Рассмотрим подробнее данный этап (рис. 4.9): Рис 4.9 Шаги этапа заполнения таблицы фактов work_fact В начале данного этапа из исходной БД берутся данные о каждом этапе с помощью следующего SQL-запроса: SELECT ws.id as work_stage_id, w.customer_id, ws.risk_failure_percent, ws.cost_rel_estimation, ws.cost_abs_estimation, 73 ws.begin_date, ws.end_date, ws.risk_loss FROM work_stage ws JOIN work w on work_id=w.id; После выполнения данного SQL-запроса имеем:  дату начала выполнения этапа;  дату завершения выполнения этапа;  оценочную стоимость этапа;  вероятность срыва этапа;  ожидаемый ущерб от срыва этапа;  идентификаторы, ссылающиеся на таблицы измерений. Затем с помощью элемента «Modified Java Script Value» к каждой строке полученной таблицы добавляется новое поле js_y, содержащее перечисление годов, входящий в срок выполнения этапов. Например, если этап выполняется с 1 июня 2010 до 1 сентября 2013 года, то поле js_y будет иметь значение [2010;2011;2012;2013]. Элемент «Modified Java Script Value» позволяет применять к кортежу преобразования, описанные на языке JavaScript: var js_y = ""; var i; for (i=year(begin_date); i<=year(end_date);i++){ js_y+=i; if (i!=year(end_date)) js_y+=";"; } Далее применяется элемент «Split field to rows», позволяющий добавлять новые строки к таблице, основываясь на значении какого-либо поля. В данном шаге разделение основывается на поле js_y – для каждого значения года, перечисленного в поле, создаётся новый кортеж данных. Рассмотрим данное преобразование на конкретном примере: 74 Поле 1 Поле 2 aaa bbb ddd eee Поле 3 ccc fff Поле js_y 2010;2011;2012 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); }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;//формируем новый идентификатор 75 и Для каждой строки в таблице фактов необходимо также сформировать идентификатор. В данном случае в роли идентификатора выступает строка, равная конкатенации идентификаторов этапа и года. На следующем шаге этапа происходит преобразование значения года (y) из строкового представления в числовое (y2): var y2 = java.lang.Integer.valueOf(y); Это необходимо сделать вследствие того, что в таблице измерения времени в качестве ключа выступает именно числовое представление года, а не строковое. На последнем этапе происходит запись информации в таблицу фактов work_fact хранилища данных, причём необходимо явно указать соответствие полей, т.к. поля, используемые на данном этапе, отличаются от полей в таблице фактов: Таблица 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 В разрабатываемом кубе для оценочной стоимости и ожидаемого ущерба используется агрегирующая функция sum (сумма). При выборе агрегирующей функции для вероятности срыва предложения автор столкнулся с очередной проблемой – для вероятностей необходимо использовать агрегирующую функцию, перемножающую все элементы, т.к. вероятность наступления одновременно всех событий, равна произведению вероятностей наступления 76 каждого из них. Но в Mondrian существует только предопределённый нерасширяющийся набор агрегирующих функций:  count – количество элементов;  distinct-count – количество уникальных элементов;  sum – сумма всех элементов;  max – максимальное значение;  min – минимальное значение;  avg – среднее значение элементов. Рассмотрим основные этапы решения возникшей проблемы: 1) Создание в PostgreSQL собственной агрегирующей функции, которая будет перемножать все исходные элементы. 2) Корректировка исходного кода Mondrian сервера. 3) Сборка исправленной версии Mondrian. 4) Использование созданной функции в кубе. Остановимся на каждом этапе подробнее. СУБД PostgreSQL позволяется создавать собственные агрегирующие функции, используя следующую команду: CREATE AGGREGATE name ( BASETYPE = input_data_type, SFUNC = sfunc, STYPE = state_data_type [ , FINALFUNC = ffunc ] [ , INITCOND = initial_condition ]), где:  input_data_type – тип входных данных;  state_data_type – тип временной переменной, хранящей значение агрегирующей функции на каждой итерации;  sfunc – функция, вызываемая на каждой итерации;  ffunc – функция, вызываемая после выполнения последней итерации;  initial_condition – начальное значение промежуточной переменной. 77 Формат используемых функций следующий: sfunc( internal-state, next-data-item ) ---> next-internal-state ffunc( internal-state ) ---> aggregate-value Функция sfunc() принимает на вход уже сосчитанное промежуточное значение и значение следующего элемента. Данная функция описывает основное преобразование над исходным набором значений. В разрабатываемом кубе функция sfunc() перемножает элементы. Функция ffunc() принимает на вход результат, полученный в ходе выполнения функции sfunc() на всех итерациях и возвращает конечный результат агрегирующей функции. Эта функция является необязательной и если явно не объявляется, то результатом агрегирующей функции становится результат выполнения функции sfunc() на последнем шаге итерации. В разрабатываемом кубе создаётся следующая агрегирующая функция prob_aggr, перемножающая входящий набор элементов: CREATE AGGREGATE prob_aggr ( BASETYPE = double precision, SFUNC = s_multiplication, STYPE = double precision ), где s_multiplication – это функция, перемножающая два входных параметра: CREATE FUNCTION s_multiplication(double precision, double precision) RETURNS double precision AS $BODY$ BEGIN RETURN $1*$2; END; $BODY$ LANGUAGE 'plpgsql' После создания собственной агрегирующей функции необходимо доработать OLAP-сервер Mondrian так, чтобы он «понимал» эту функцию. Mondrian имеет открытый исходный код, написанный на Java. mondrian.rolap.RolapAggregator – класс, отвечающий за вызов агрегирующих функций. В данном классе имеется перечисление (enum), хранящее список 6 предопределённых агрегирующих функций. Необходимо в это перечисление добавить созданную агрегирующую функцию (см. приложение №): 78 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.4 Результаты В ходе данного этапа было разработано хранилище данных, содержащее три многомерных куба. Каждый куб определяет свою область анализа данных. Разработанное хранилище реализовано на СУБД PostgreSQL и использует многие возможности данного продукта, такие как пользовательские функции (обычные и агрегирующие). Данная СУБД является реляционной, а не многомерной, поэтому для многомерного представления данных используется специальная организация реляционных таблиц – схема звезды (star schema), являющейся более эффективной, но более избыточной по сравнению с другой схемой – схемой снежинки (snowflake schema). Описание многомерных кубов производится в программе Pentaho Mondrian Workbench и сохраняется как XML-файл, текст которого приведён в приложении №. Данный файл в дальнейшем используется OLAP-сервером. В следующей главе описывается разработка модуля многомерного анализа данных, который используется в СППР РЭП визуализировать многомерные кубы и анализировать данные. 79 и позволяет 5. Разработка модуля многомерного анализа данных для СППР РЭП Разрабатываемый модуль многомерного анализа данных в СППР РЭП состоит из следующих элементов (рис 5.1): 1. Хранилища данных, построенного на СУБД PostgreSQL 2. OLAP-сервера Mondrian 3. Визуализатора многомерных кубов JPalo MDX-запрос JPalo SQL-запрос OLAP-сервер Хранилище данных Рис 5.1. Структура разрабатываемого модуля Аналитик, работая с модулем в веб-браузере, производит действия по запросу тех или иных данных, которые представляются в виде многомерной таблицы. На каждое действие пользователя визуализатор формирует OLAPсерверу MDX-запрос. Далее OLAP-сервер преобразует его в обычный SQL-запрос и отправляет в хранилище данных, откуда извлекаются необходимые данные. OLAP-сервер Mondrian использует подход In-Memory OLAP, поэтому на некоторые MDX-запросы сервер отвечает данными, хранимыми в его кэше, тем самым не отправляя SQL-запросов хранилищу. Полученные данные отображаются в веб-браузере в виде динамической таблицы. Организация хранилища данных была описана в предыдущей главе. Рассмотрим подробнее настройку OLAP-сервера и подключение визуализатора JPalo в СППР РЭП. 5.1 Настройка OLAP-сервера OLAP-сервер Mondrian поставляется как веб-приложение в виде WARфайла, помещаемого в веб-сервер Apache Tomcat. Настройка сервера 80 заключается в указании XML-файла конфигурации многомерных кубов, а также настроек подключения к хранилищу данных. Эта информация содержится в файле datasources.xml: <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 приведено в приложении №. После настройки OLAP-сервера он готов к работе. Для начала работы сервера необходимо запустить веб-сервер Apache Tomcat. Для получения доступа к OLAP-серверу по протоколу XMLA используется URL вида http://имя_сервера:порт/mondrian/xmla, где имя_сервера и порт – соответственно имя компьютера и порт, на котором запущен Apache Tomcat. 5.2 Подключение визуализатора в СППР РЭП Основной целью визуализатора является наглядное отображение данных, приходящих от OLAP-сервера. Для достижения поставленной цели визуализатор должен выполнять следующие задачи:  выполнение всех операций над многомерными данными: срезы, детализация/обобщение, поворот и др.;  фильтрация входящих данных – возможность выбора собственного набора измерений, а также скрытие любых колонок и строк в таблице; 81  наличие удобного пользовательского интерфейса;  сохранение и печать полученных отчётов; В процессе работы было решено использовать готовый визуализатор, а не разрабатывать собственный, и встроить его в СППР РЭП. Выбор был сделан в пользу продукта JPalo (см. приложение №), т.к. данный продукт является открытым, бесплатным и выполняет все вышеперечисленные задачи. Основным элементом интерфейса JPalo является динамическая таблица, значения ячеек которой определяются соответствующим набором измерений, используемых аналитиком. Весь набор измерений представлен в виде объектов, находящихся в верхней части экрана. Каждый такой объект имеет заголовок – название измерения и кнопку вызова фильтра, в котором аналитик может настраивать иерархии, используемые в измерении. Переносом объектов с помощью мыши (drag’n’drop) можно добавлять в таблицу используемые измерения. Задача аналитика состоит в наполнении таблицы нужными измерениями и, при необходимости, в использовании фильтров, уменьшающих количество входных данных. В динамической таблице в заголовках полей имеются кнопки, позволяющие производить детализацию или обобщение данных. Сверху располагается панель инструментов, позволяющая сохранить текущие результаты и распечатать таблицу на принтере. JPalo, также как и Mondrian, поставляется в виде WAR-файла, помещаемого в веб-сервер Apache Tomcat. Настройка JPalo заключается в указании URL к OLAP-серверу, работающему по протоколу XMLA (см. подразд. 5.1). Основная проблема заключалась во встраивании JPalo в систему СППР РЭП. Система СППР РЭП является веб-приложением написанным с использованием технологии Grails. Grails — программный каркас для создания 82 веб-приложений, написанный на скриптовом языке Groovy, который в свою очередь основан на Java. Grails основан на шаблоне «Модель-Вид-Контроллер» (MVC) [4]. Grails — это современная инфраструктура для разработки Webприложений, который соединяет такие давно знакомые Java-технологии, как Spring и Hibernate, с современными подходами, такими как соглашения о конфигурации. Grails может работать с Apache Tomcat, JBoss или любым другим веб-сервером, поддерживающим сервлеты [4]. Для разработки и отладки используется встроенный в Grails веб-сервер Jetty. В качестве сервера базы данных поддерживаются MySQL, Firebird, PostgreSQL, IBM DB2, Oracle и Microsoft SQL Server. Также поддерживается встраиваемая база данных SQLite. СППР РЭП, как и любое Grails-приложение, имеет следующую структуру: Рис. 5.2 Структура проекта СППР РЭП  в каталоге conf содержатся файлы конфигурации приложения;  в каталоге controllers содержатся Groovy-классы, представляющие собой контроллеры шаблона Model-View-Controller;  в каталоге domains содержатся Groovy-классы, представляющие собой сущности, которые в совокупности со связями между собой, образуют модель шаблона Model-View-Controller;  в каталоге i18n находятся файлы, обеспечивающие интернационализацию приложения, т.е. процесс адаптации продукта к языковым и культурным особенностям страны, отличной от той, в которой разрабатывался продукт;  в каталоге taglib располагаются пользовательские теги для GSP-страниц; 83  в каталоге views находятся GSP-страницы – представление в шаблоне Model-View-Controller. GSP-страницы – это динамически формируемые на стороне сервера вебстраницы, использующие синтаксис языка Java и Groovy. Для подключения визуализатора JPalo необходимо создать GSP-страницу olap.gsp, в которую будет встроен визуализатор. На страницу вставляется HTML-тэг IFRAME, который отображает дополнительное окно с веб-страницей. Созданная GSP-страница помещается в папку views. Остановимся подробнее на тэге IFRAME. Ниже приведён фрагмент GSP-кода, подключающего JPalo на страницу (исходный код GSP-страницы приведён в приложении №): <iframe src="${paloUrl}" width="100%" height="600" align="left"></iframe> В данном коде, используется переменная paloUrl, формируемая в контроллере (используется модель MVC) и задающая путь к JPalo. Путь к JPalo изменяется в зависимости от запрашиваемого для анализа многомерного куба. Ниже приведён код контроллера OlapContoller.groovy: class OlapController { def index = { String id = params.id; if (id == null) id = "0"; String paloUrl = "/palo/com.tensegrity.wpalo.WPalo/WPalo.html?options=(user=%22admin%22,pass=%22I SMvKXpXpadDiUoOSoAfww==%22,hideNavigator,[openview=%22" + id + "%22,hideStaticFilter,hideTitlebar])"; String activeMenu = "activeMenu"; if ("0".equals(id)) { activeMenu = "Анализ показателей предприятий"; } if ("1".equals(id)) { activeMenu = "Анализ рисков и оценочной стоимости"; } if ("2".equals(id)) { activeMenu = "Анализ стоимости мероприятий"; } render(view: "olap", model: [paloUrl: paloUrl, activeMenu: activeMenu]) } } 84 В контроллере формируется URL к визуализатору JPalo, а также определяется активное меню. Каждый созданный куб имеет идентификатор – 0, 1 или 2. Данный идентификатор передаётся в URL. Помимо идентификатора в URL передаются данные для авторизации и некоторые другие параметры, отвечающие за внешний вид визуализатора. Переменная activeMenu хранит название выделенного пункта меню (см. приложение №). Последняя строка передаёт в GSP-страницу olap.gsp модель данных, состоящую из URL к JPalo и названия выделенного меню activeMenu. Остаётся отметить используемую среду для разработки. В ВКР использовалась интегрированная среда разработки Intellij IDEA 9.1, потому что: 1. Intellij IDEA полностью поддерживает язык Groovy, включая отладку и рефакторинг Groovy-кода. 2. Intellij IDEA поддерживает технологию Grails, тем самым ускоряя разработку Grails-приложений. 5.3 Результаты В ходе данного этапа был разработан модуль многомерного анализа данных, используемый OLAP-сервер Mondrian и визуализатор JPalo. Разработанный модуль полностью выполняет поставленные задачи (см. п. 2.4). Результат разработки модуля многомерного анализа данных приведён в приложении №. 85 Заключение 1. Разработан модуль многомерного анализа данных для системы поддержки принятия предприятиями решений радиоэлектронной по управлению выполнением промышленности мероприятий государственных программ перевооружения, федеральных целевых программ и государственных оборонительных заказов. Модуль позволяет получать различную статистическую информацию, тем самым помогая пользователю в принятии тех или иных управленческих решений. 2. При создании модуля было разработано хранилище данных, что позволило снизить нагрузку на основную базу данных системы поддержки принятия решений. Также на основе анализа различных моделей хранения многомерных данных были спроектированы необходимые для анализа многомерные кубы. 3. Проведено исследование возможностей современных OLAP-серверов. На основании этого исследования и выделенных критериев был выбран подходящий для разрабатываемого модуля OLAP-сервер. 4. Система поддержки принятия решений совместно с разработанным модулем многомерного анализа в ближайшее время будет внедрена у заказчика. Список литературы 1. Архипенков С. Хранилища данных. / Д. Голубев, О. Максименко – М.: Диалог-МИФИ, 2002. 86 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 – сайт о бизнес-аналитике. Приложения 87

Титульный лист 1

Похожие документы

Разделы

Поддержка

Титульный лист 1

Похожие документы

Добавить этот документ в коллекции

Добавить этот документ в сохраненные

Предложите, как улучшить StudyLib