Титульник

ТЗ

Аннотация

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

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

Abstract

This paper is devoted to online multidimensional data analysis (OLAP) in decision support systems (DSS). Paper is focused on the>

The first chapter is research of>

The next chapter is devoted to describing of offered approach. And the last one is about implementing and testing on the DSS that used in the Ministry of Industry and Trade.

Оглавление

Список сокращений, используемых в работе 6

Введение 7

1. Аналитический обзор 9

1.1 Оперативный анализ данных (OLAP) 9

1.1.1 Подходы к построению OLAP-систем 14

1.1.2 Хранилища данных, используемые в OLAP-системах 17

1.1.3 Многомерная модель данных в OLAP-анализе 19

1.1.4 Подходы к реализации многомерной модели данных 23

1.1.5 Классификация OLAP-систем по способу хранения данных 26

1.2 Системы поддержки принятия решений 27

1.2.1 Применение многомерного анализа данных в СППР 28

1.2.2 Особенности СППР, учитывающих риски предприятий 29

1.2.3 Недостатки существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих риски предприятий 30

1.3 Выводы 30

2. Описание предложенного подхода 31

2.1 Предлагаемый подход к построению подсистемы многомерного анализа данных в СППР, учитывающих особенности изменяемых во времени факторов 31

2.2 Архитектура подхода 32

2.3 Достоинства подхода 34

2.4 Выводы 34

3. Реализация предложенного подхода 35

3.1 Выбор OLAP-сервера 35

3.1.1 Сравнительный анализ существующих OLAP-серверов 37

3.2 Выбор хранилища данных 48

3.3 Выбор модуля преобразования и загрузки данных 50

3.4 Выбор OLAP-клиента 52

3.4.1 Сравнительный анализ существующих OLAP-клиентов 53

3.5 Выводы 55

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

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

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

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

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

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

4.3 Анализ качества 83

4.4 Выводы 86

Заключение 87

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

Приложения 89

Список сокращений, используемых в работе

OLAP	— совокупность концепций, принципов и требований, лежащих в основе программных продуктов, обеспечивающих сбор, хранение, манипулирование и оперативный анализ многомерных данных.
OLTP	— обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.
СППР	— система поддержки принятия решений.
РЭП	— радиоэлектронная промышленность.
СППР РЭП	— система поддержки принятия решений для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ.
Минпромторг	— Министерство промышленности и торговли РФ.
ФЦП	— Федеральная целевая программа.
Хранилище данных (ХД)	— предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации.

Введение

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

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

За последние 20 лет информационно-аналитические системы меняли свои названия и содержание, пройдя путь от информационных систем руководителя (executive information systems, EIS) до систем поддержки принятия решений (СППР).

Современные СППР строятся на основе технологий, позволяющих пользователю-непрограммисту легко и оперативно извлекать информацию из различных источников, формировать собственные настраиваемые отчеты или графические представления, проводить многомерный анализ данных. Разнообразие этих технологий принято объединять термином «бизнес-аналитика» или Business Intelligence (BI). Развитие систем бизнес-аналитики прошло путь от «толстых» клиентов до Web-приложений, в которых пользователь ведет исследование с помощью браузера и может работать удаленно.

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

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

Для достижения поставленной цели необходимо сформулировать и решить следующие задачи:

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

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

Предметом исследования является технология оперативного многомерного анализа данных (OLAP), применяемая в СППР.

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

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

1. Аналитический обзор

1.1 Оперативный анализ данных (OLAP)

OLAP (Online Analytical Processing) — это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, обеспечивающих сбор, хранение, манипулирование и анализ многомерных данных.

Термин OLAP был предложен доктором Е.Ф. Коддом, его супругой С.Б. Кодд и их коллегой С.Т. Солли в исследовательской статье "OLAP для пользователей-аналитиков: информационно-технологический мандат". Эта статья была опубликована в начале 1993 года и спонсировалась корпорацией Arbor Software, создателем и распространителем первого OLAP-продукта Essbase. Статья определяет OLAP как «имя, данное динамическому анализу предприятия, необходимому для создания, манипулирования, оживления и синтезирования информации на базе "моделей информации о предприятии" ("Enterprise Data Models")».

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

Оперативность в современном бизнесе — один из факторов успеха. Аналитику нужен такой инструмент, который позволил бы визуализировать данные быстро, просто и удобно. В качестве такого инструмента и выступает OLAP.

В 1993 году Кодд сформулировал «12 принципов аналитической обработки в реальном времени» [8] (см. табл. 1.1):

Таблица 1.1

Принципы аналитической обработки в реальном времени

№	Принцип	Описание
1	Многомерное представление данных	Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.
2	Прозрачность	Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда они берутся.
3	Доступность	Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником данных. Средства должны обеспечивать автоматическое отображение их собственной логической схемы в различные гетерогенные источники данных.
4	Согласованная производительность	Производительность практически не должна зависеть от количества Измерений в запросе.
5	Поддержка архитектуры клиент-сервер	Средства должны работать в архитектуре клиент-сервер.
6	Равноправность всех измерений	Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).
7	Динамическая обработка разреженных матриц	Неопределенные значения должны храниться и обрабатываться наиболее эффективным способом.
8	Поддержка многопользовательского режима работы с данными	Средства должны обеспечивать возможность работать более чем одному пользователю.
9	Поддержка операций на основе различных измерений	Все многомерные операции (например, агрегация) должны единообразно и согласованно применяться к любому числу любых измерений.
10	Простота манипулирования данными	Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс.
11	Развитые средства представления данных	Средства должны поддерживать различные способы визуализации (представления) данных.
12	Неограниченное число измерений и уровней агрегации данных	Не должно быть ограничений на число поддерживаемых измерений.

В 1995 году на основе принципов, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям оперативного анализа данных [2]:

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

Большинство из существующих 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.
• Финансовая консолидация. Консолидация данных согласно международным стандартам учёта, принимая во внимание доли владения, различные валюты и внутренние обороты – актуальная задача в связи с ужесточающимися требованиями проверяющих органов (SOX, Basel II) и выходом компаний на IPO (Initial Public Offering — первая публичная продажа акций частной компании). OLAP-технологии позволяют ускорить расчёт консолидированных отчётов и повысить прозрачность всего процесса. Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller.

1.1.1 Подходы к построению OLAP-систем

По аналогии с подходами построения клиент-серверных систем выделяют два подхода к построению OLAP-систем:

1. Подход, основанный на двухзвенной архитектуре (рис. 1.1).
2. Подход, основанный на трёхзвенной архитектуре (рис. 1.2).

Рис. 1.1 Двухзвенная архитектура построения OLAP-систем

Рис. 1.2 Трёхзвенная архитектура построения OLAP-систем

OLAP-система, построенная на двухзвенной архитектуре, состоит из хранилища данных, настольной OLAP-системы и сетью передачи данных между ними. Хранилище данных является источником входных данных для анализа. Структуры данных хранилища специальным образом оптимизированы (см. подразд. 1.1.4) для уменьшения времени обработки запросов, посылаемых настольной OLAP-системой. Настольная OLAP-система вычисляет и отображает анализируемые данные.

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

Исходные данные для анализа, находящиеся в хранилище, могут поступать из различных источников данных, таких как оперативные (OLTP) БД, таблицы Microsoft Excel, XML-документы и др. Эти данные поступают в хранилище с определённой периодичностью (например, еженедельно или ежедневно — в зависимости от потребностей), поэтому на момент анализа могут быть не актуальными. С одной стороны, это не является проблемой, когда аналитик просматривает данные, за прошедший период времени, т.к. аналитик не обращает внимания на отдельно взятые факты — ему необходима суммарная информация о сотнях и тысячах событий. Но с другой стороны, это может вызывать проблему при планировании, т.к. выбор того или иного решения зависит от текущей ситуации, которая может изменяться несколько раз в течение одного дня (см. подразд. 1.2.2).

Сравним данные подходы по эксплуатационным и стоимостным показателям:

1. Объем обрабатываемых данных. Объем данных определяется предметной областью анализируемых данных, а также количеством записей в хранилище данных. Как и настольная OLAP-система, так и OLAP-сервер, вынуждены кешировать данные в оперативной памяти для уменьшения количества запросов к хранилищу данных. Таким образом, объем данных, обрабатываемых настольной OLAP-системой и OLAP-сервером, находится в прямой зависимости от объема оперативной памяти. У серверов объём оперативной памяти больше, чем у пользовательских ПК, поэтому OLAP-сервер может обрабатывать большие объемы данных, чем настольная OLAP-система.
2. Производительность системы. Эта характеристика определяется следующими факторами: объемом обрабатываемых данных и мощностью компьютеров. При возрастании количества входных анализируемых данных производительность всех OLAP-систем снижается за счет значительного увеличения количества высчитываемых суммарных значений, но при этом темпы снижения разные. Продемонстрируем эту зависимость на графике (рис. 1.3):

Рис. 1.3 Зависимость времени отклика OLAP-системы от объема обрабатываемых данных

Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и настольной OLAP-системой. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки", в то время как настольная OLAP-система вычисляет весь набор суммарных значений в момент загрузки.

3. Сетевой трафик. При использовании OLAP-сервера по сети на ПК OLAP-клиента передаются только данные для отображения, в то время как настольная OLAP-система получает весь объем данных первичной выборки. Поэтому там, где применяется настольные OLAP-системы, сетевой трафик будет выше. Но, при применении OLAP-сервера операции пользователя, например детализация, порождают новые запросы к многомерной базе, а, значит, новую передачу данных. Выполнение же OLAP-операций настольной OLAP-системой производится в оперативной памяти и, соответственно, не вызывает новых потоков данных в сети. Также необходимо отметить, что современное сетевое оборудование обеспечивает высокий уровень пропускной способности.
4. Затраты на внедрение и сопровождение. Стоимость OLAP-сервера достаточно высока. Дополнительно следует учитывать стоимость выделенного сервера и постоянные затраты на администрирование хранилища данных. Кроме того, внедрение и сопровождение OLAP-сервера требует от персонала достаточно высокой квалификации. Стоимость настольной OLAP-системы на порядок ниже стоимости OLAP-сервера. Администрирования и дополнительного технического оборудования для настольной OLAP-системы не требуется. К квалификации персонала при внедрении настольных OLAP-систем высоких требований не предъявляется. Настольная OLAP-система может быть внедрена значительно быстрее OLAP-сервера.

Таким образом, использование трёхзвенной архитектуры предпочтительнее при больших объемах исходных данных и небольшой скорости сети передачи данных.

1.1.2 Хранилища данных, используемые в OLAP-системах

Хранилище данных – обязательная составляющая любой OLAP-системы. В хранилище содержатся исходные данные для анализа.

Хранилище данных (англ. Data Warehouse) — очень большая предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации. Строится на базе клиент-серверной архитектуры, реляционной СУБД и утилит поддержки принятия решений. Данные, поступающие в хранилище данных, обычно становятся доступны только для чтения. Данные из промышленной OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы промышленной системы и не нарушал её стабильность.

Существуют два архитектурных направления построения хранилищ данных – нормализованные хранилища данных и размерностные хранилища.

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

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

Для OLAP-анализа используется второй тип хранилищ – размерностные хранилища.

1.1.3 Многомерная модель данных в OLAP-анализе

Преимущество использования OLAP-анализа — это оперативность обработки запросов, поступающих от аналитика в процессе его работы. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. Более хорошей моделью для запросов, а не для изменения, является многомерная (нередко называемая пространственной) модель данных [7].

Многомерная модель данных — это расширение реляционной модели. В отличие от реляционной модели, где основным понятием является «отношение», в многомерной модели основным понятием является многомерный «куб» (нередко называемый также OLAP-кубом), который является обобщением реляционных таблиц на любое число измерений. Набор соответствующих кубов составляет многомерную базу данных.

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

Некоторые преимущества многомерной модели по сравнению с реляционной [7]:

• Возможность анализа больших объемов данных с приемлемой скоростью;
• Возможность осуществления любых «срезов» и «углублений» в определённой структуре БД;
• Быстрая локализация трендов и проблемных областей.

Многомерный куб представлен набором мер и измерений, а именно, куб — это декартовое произведение измерений, где для каждого элемента произведения проставлен набор мер.

Измерения куба – набор доменов, по которым создаётся многомерное пространство. Другими словами, измерение – это упорядоченный набор значений, соответствующий грани куба. Многомерное моделирование предусматривает использование измерений для предоставления максимальной информативности [3]. В отличие от реляционных баз данных, контролируемая избыточность в многомерных базах данных считается оправданной, если она увеличивает информационную ценность.

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

Многомерная модель данных предназначена для анализа информации. Единицей анализируемой информации считается когда-либо произошедший факт, т.е. факты представляют субъект — некий шаблон или событие, которые необходимо проанализировать. В большинстве многомерных моделей данных факты однозначно определяются комбинацией значений измерений. Факт существует только тогда, когда ячейка для конкретной комбинации значений не пуста. Каждый факт обладает некоторой гранулярностью, определенной уровнями, из которых создается их комбинация значений измерений.

Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:

• факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);
• факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;
• факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);
• факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

Мера (или показатель) – это значение, которое однозначно определяется фиксированным набором измерений и количественно характеризует анализируемые факты.

Меры бывают трёх типов:

• аддитивные (additive) меры – допускающие агрегирование относительно любого измерения куба данных;
• неаддитивные (nonadditive) меры – которые не могут агрегироваться ни по какому измерению куба данных;
• полуаддитивные (semiadditive) меры – которые допускают агрегирование относительно одних измерений и не допускают относительно других.

Многомерная база данных естественным образом предназначена для определенных типов запросов:

• Запросы вида slice и dice (срезы куба) — формирование подмножества многомерного массива данных, соответствующего единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Если рассматривать термин slice с позиции конечного пользователя, то наиболее часто его роль играет двумерная проекция куба (рис. 1.4). Срез dice отличается от slice тем, что это трёх- и более-мерная проекция куба.

Рис. 1.4 Операция среза (slice)

• Запросы вида drill-down (детализация) и roll-up (обобщение) — взаимообратные операции, которые используют иерархию измерений и меры для агрегирования. Направление детализации/обобщения может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями.
• Запросы вида drill-across комбинируют кубы, которые имеют одно или несколько общих измерений. С точки зрения реляционной алгебры такая операция выполняет слияние (join).
• Запросы вида ranking возвращают только те ячейки, которые появляются в верхней или нижней части упорядоченного определенным образом списка.
• Поворот (rotating) куба дает пользователям возможность увидеть данные, сгруппированные по другим измерениям (рис. 1.5). Например, операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид.

Рис. 1.5 Операция вращения (rotating)

Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию.

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

1.1.4 Подходы к реализации многомерной модели данных

Многомерная структура хранения данных может быть реализована с помощью многомерных БД или в системе управления реляционными БД с использованием схемы звезды (star schema) или схемы снежинки (snowflake schema) [7].

Схема звезды (рис. 1.6) является реляционным воплощением многомерной представления данных. Она является проекцией куба на «реляционную плоскость» и состоит из одной таблицы фактов (fact table) и нескольких таблиц измерений (dimension table). Таблица фактов содержит по одной строке для каждого факта — минимально рассматриваемого атома анализируемого процесса.

Рис.1.6 Пример куба, построенного по схеме «Звезда»

Полями таблицы фактов, помимо ключей, являются меры (measures), описывающие количественную характеристику факта.

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

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

Рис.1.7 Пример куба, построенного по схеме «Снежинка»

Схема снежинки является модификацией схемы звезды — часть таблиц измерений разбита на несколько связанных таблиц (рис. 1.7). Благодаря частичной нормализации, «снежинка» позволяет сэкономить дисковое пространство, но она уменьшает скорость просмотра измерений.

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

1.1.5 Классификация OLAP-систем по способу хранения данных

И исходные и агрегатные (суммарные) данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP) [2]. Соответственно, OLAP-системы по способу хранения данных делятся на три аналогичные категории:

• в случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе;
• в ROLAP-системах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-системы;
• в случае использования HOLAP архитектуры исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-системы на основе реляционных и многомерных данных.

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

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

1.2 Системы поддержки принятия решений

Система поддержки принятия решений (СППР) (англ. Decision Support System, DSS) — компьютерная автоматизированная система, целью которой является помощь людям, принимающим решение в сложных условиях для полного и объективного анализа предметной деятельности [7].

СППР обладает следующими четырьмя основными характеристиками:

1. СППР использует и данные, и модели;
2. СППР предназначены для помощи менеджерам в принятии решений для слабоструктурированных и неструктурированных задач;
3. Они поддерживают, а не заменяют, выработку решений менеджерами;
4. Цель СППР — улучшение эффективности решений.

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

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

1.2.1 Применение многомерного анализа данных в СППР

Многомерный анализ данных – это извлечение полезной информации из многомерной структуры данных посредством оперативного анализа (OLAP).

Многомерный анализ данных является современным методом анализа данных в СППР для принятия эффективных обоснованных решений [9]. Многомерный анализ позволяет лицу, принимающему решение (ЛПР), делать срезы многомерных данных, высчитывать суммарные значения по любым измерениям, тем самым обеспечивая ЛПР любой интересующей информацией. Другими словами, многомерный анализ данных позволяет формировать любой отчёт без участия программистов и без знания языков запросов к базам данных.

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

Многомерный анализ данных применяется только в СППР, ориентированных на работу с данными (Data-driven DSS) и имеющих большую базу исходных данных, накопленных за значительный период времени.

1.2.2 Особенности СППР, учитывающих риски предприятий

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

Часть из всех факторов, рассматриваемых СППР, такие как риски, оценки, вероятности и др. могут изменяться с течением времени и, следовательно, СППР должна учитывать это. В теории менеджмента существует специальный подход к выбору оптимального решения в обстановке изменяемых во времени факторов – ситуационный подход [7]. Ситуация, в данном случае, – это состояние значений всех динамически изменяемых факторов в текущий момент времени. Ситуационный подход предполагает создание различных вариантов решений, каждое из которых пригодно в той или иной ситуации. Самым эффективным решением в конкретной ситуации является решение, которое более всего соответствует данной ситуации.

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

1.2.3 Недостатки существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих риски предприятий

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

1.3 Выводы

В данной главе была рассмотрена технология оперативного анализа данных – OLAP и её применение в системах поддержки принятия решений.

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

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

2. Описание предложенного подхода

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

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

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

Рис. 2.1 Предлагаемый подход к построению OLAP-системы

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

2.2 Архитектура подхода

Архитектура предлагаемого подхода представлена ниже (рис. 2.2). В левой части рисунка представлена архитектура подсистемы многомерного анализа данных, а в правой – типичная архитектура СППР.

Рис. 2.2 Архитектура подхода

Архитектура состоит из четырёх основных модулей и сетью передачи данных между ними:

1. OLAP-хранилище данных
2. Модуль преобразования и загрузки данных
3. OLAP-сервер
4. OLAP-клиент

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

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

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

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

OLAP-клиент может быть исполнен в виде настольного (desktop) приложения, либо в виде веб-приложения. Во втором случае в роли OLAP-клиента выступают веб-браузер и веб-сервер.

В зависимости от производительности серверов, на которых будет реализован подход, и вида OLAP-клиента, модули могут располагаться как на одном физическом сервере (в случае, когда в качестве OLAP-клиента выступает веб-приложение), так и на разных серверах.

Все модули исполнены в виде функционально завершённых элементов, поэтому архитектура инвариантна к структуре исходных данных хранилища СППР и количеству создаваемых многомерных кубов для анализа.

2.3 Достоинства подхода

Достоинства предлагаемого подхода:

• ориентирован на уменьшение времени обработки запросов;
• анализируемые данные всегда актуальны;
• расширяемость OLAP-хранилища – возможность добавления новых кубов данных без модификации других модулей подсистемы.

2.4 Выводы

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

3. Реализация предложенного подхода

3.1 Выбор OLAP-сервера

Основные требования, предъявляемые к OLAP-серверу:

• возможность создания пользовательских функций для вычисления значений мер (в частности, создание пользовательских агрегирующих функций);
• доступ OLAP-клиентов по унифицированному протоколу;
• возможность добавления новых кубов;
• широкий спектр поддерживаемых СУБД.

На сегодняшний день существует множество поставщиков OLAP-серверов. Все крупные поставщики СУБД, такие как Oracle, Microsoft, IBM, Sybase, выпускают также и OLAP-сервера к своим СУБД. Помимо крупнейших производителей СУБД на рынке OLAP-продуктов фигурируют и другие компании, работающие в области Business Intelligence, такие как MicroStrategy, Pentaho, SAS Institute, Jedox.

Все современные OLAP-серверы удовлетворяют принципам аналитической обработки в реальном времени, изложенным Коддом в 1993 году (см. подразд. 1.1), а позднее дополненными в 1995 году.

Основными проблемами использования OLAP-серверов являются проблемы производительности, разреженности данных и «взрыва» данных.

Проблема производительности связана к требованию к OLAP-продукту – времени отклика сервера (которое должно быть не более 5 секунд по тесту FASMI, см. подразд. 1.1). Объём анализируемых данных часто превышает миллионы записей, поэтому такое время сложно достичь. Данная проблема производителями решается по-разному, но в основном, решения основываются на кешировании сосчитанных агрегатных (суммарных) значениях, либо на предварительном их вычислении и хранении в базе данных.

Предварительное вычисление и хранения в БД агрегатных значений порождает новую проблему – проблему эффекта «взрыва данных», т.е. к резкому увеличению объёма хранимых данных. Это вызвано тем, что количество хранимых агрегатов растёт в экспоненциальной зависимости от числа измерений в кубе. Синдром взрыва может приводить к еще большим проблемам при разреженном распределении исходных данных по многомерному кубу. Отсутствующие или недопустимые значения данных создают разрежение в модели данных OLAP. Наиболее удачные OLAP-серверы борются с этой проблемой, не сохраняя пустые значения, таким образом, даже плохо заполненные кубы «не раздуваются» в объеме.

Все современные OLAP-серверы могут работать одновременно с несколькими кубами, поддерживать работу с большим числом измерений, мер и иерархий. Некоторые продукты поддерживают несколько иерархий для измерения, несбалансированные иерархии, полуаддитивные меры и некоторые другие функции, такие как «write-back», позволяющую аналитику изменить любое значение в таблице-отчёте, посмотреть к каким последствиям оно приведёт и при необходимости сохранить новое значение в хранилище данных.

У каждого сервера есть свои протоколы обмена информацией и языки запросов к многомерным данным – в области OLAP на данный момент не существует каких-либо стандартизованных протоколов обмена информацией. Но при этом почти каждый сервер поддерживает стандарты «де факто» обмена информацией – XMLA (XML for Analysis) и языка запросов к многомерным данным фирмы Microsoft – MDX (Multidimensional Expressions).

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

3.1.1 Сравнительный анализ существующих OLAP-серверов

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

Таблица 3.1

Исследуемые OLAP-сервера

№	Фирма-производитель	Название OLAP-сервера
1	Microsoft	Analysis Services
2	Oracle	Essbase
3	IBM	Cognos TM1
4	Pentaho	Mondrian
5	Jedox	Palo

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

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

1. Список поддерживаемых СУБД.
2. Список поддерживаемых форм хранения данных (MOLAP/ROLAP/HOLAP).
3. Возможность создания вычисляемых меток. С помощью вычисляемых меток можно включать в многомерную базу меры, которых нет в исходных данных, но которые можно вычислить по формуле.
4. Возможность создания пользовательских агрегирующих функций. Агрегирующие функции – функции, вычисляющие суммарный результат, например сумма значений, среднее значение, количество элементов и др. Помимо стандартных агрегирующих функций, необходимо предусмотреть возможность создания пользовательских функций, вычисляющих агрегирующее значение по определённой формуле.
5. Оптимизация схемы агрегирования, т.е. возможность изменения количества вычисленных заранее агрегирующих значений (агрегатов). Чем больше агрегатов хранится в готовом виде, тем выше производительность системы и тем меньше среднее время ответа на запрос. В то же время, увеличение количества хранимых агрегатов приводит к увеличению объема хранимых данных. Возможность сохранять только те агрегаты, которые наиболее часто используются в запросах пользователей, позволяет получить наименьший объем хранилища данных при максимальной производительности для наиболее популярных запросов к БД. Поэтому данный критерий достаточно важен при выборе OLAP-сервера.
6. Масштабируемость и расширяемость. Масштабируемость – возможность работы с различными объемами данных: от очень маленьких (менее 10 тыс. записей) до очень больших (более 1 млн. записей) без изменения состава программного продукта. Расширяемость – возможность добавления новых многомерных кубов данных без изменения состава программного продукта.
7. Удобные средства создания кубов и администрирования.
8. Решение проблемы «взрыва данных».
9. Решение проблемы разреженности данных.
10. Список поддерживаемых API и языков запросов. Необходимо, чтобы API и язык запросов, используемые OLAP-сервером, поддерживались OLAP-клиентом.
11. Поддержка Unix-подобных операционных систем.
12. Документирование. OLAP-сервер должен иметь хорошую документацию для быстрого освоения продукта.
13. Цена продукта на минимальную конфигурацию.

Проанализируем каждый продукт по предложенным критериям:

1. OLAP-сервер Microsoft Analysis Services

Microsoft Analysis Services (MSAS) - часть Microsoft SQL Server, включающий в себя набор средств для работы с OLAP и интеллектуальным анализом данных. Последняя версия - Microsoft Analysis Services 2008.

1. MSAS поддерживает только одну СУБД - Microsoft SQL Server.
2. MSAS поддерживает все три вида хранения данных: MOLAP, ROLAP и HOLAP.
3. MSAS поддерживает создание вычисляемых меток. Следует отметить, что для этого предусмотрен удобный мастер, облегчающий создание вычисляемой метки и редактирования её формулы.
4. MSAS поддерживает создание пользовательских агрегирующих функций.
5. MSAS предусматривает оптимизацию схемы агрегирования. Используя Storage Design Wizard можно найти компромисс между быстродействием системы и размером хранимых на диске агрегатов.
6. MSAS поддерживает гибкую модель масштабирования, включающую оптимизацию хранения, компрессию данных и распределённые вычисления (т.е. часть вычислений можно перенести на клиент).
7. MSAS содержит множество различных «мастеров» и «дизайнеров» по созданию кубов, измерений, иерархий и администрированию.
8. Проблема «взрыва данных» в MSAS решена.
9. Проблема разреженности данных в MSAS также решена (посредством компрессии данных).
10. MSAS поддерживает спецификации OLE DB, ADO DB, XMLA. Язык запросов к многомерным данным – MDX.
11. MSAS может быть установлен только на ОС Windows совместно с Microsoft SQL Server.
12. MSAS очень подробно документирован. Документация на русском языке.
13. Стоимость SQL Server 2008 Workgroup Edition - 4000$.

Следует отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back».

2. OLAP-сервер Oracle Essbase

Oracle Essbase (в дальнейшем Essbase) – первый в мире OLAP-сервер. Данный сервер изначально создавался фирмой Hyperion как расширение электронных таблиц Lotus 1-2-3 и Microsoft Excel, но впоследствии в 2007 году Oracle купил Hyperion и переименовал продукт в Oracle Essbase. Последняя версия - Oracle Essbase V.11.1.2

1. Essbase поддерживает только свою СУБД – Oracle.
2. Essbase поддерживает 2 вида хранения данных: MOLAP и HOLAP.
3. Essbase поддерживает создание вычисляемых меток. Стоить отметить, что помимо обычных математических формул можно использовать процедурный язык программирования - PL/SQL.
4. Essbase поддерживает создание пользовательских агрегирующих функций, используя язык PL/SQL.
5. Essbase, так же как и MSAS, предусматривает гибкую оптимизацию схемы агрегирования.
6. Essbase поддерживает гибкую модель масштабирования, включающую кластеризацию, функции отказоустойчивости, оптимизацию хранения и компрессию данных.
7. Essbase содержит удобный графический интерфейс, напоминающий интерфейс Microsoft Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка.
8. Проблема «взрыва данных» в Essbase решена.
9. Проблема разреженности данных в Essbase также решена.
10. Essbase поддерживает API для языков Java, C, Visual Basic и спецификацию XMLA. Язык запросов к многомерным данным – MDX.
11. Essbase может быть установлен как на ОС Windows, так и на Unix-подобную ОС.
12. Essbase, так же как и MSAS, очень подробно документирован. Документация на русском языке.
13. Стоимость Oracle Essbase V.11.1.2– 40 000 $

Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back».

3. OLAP-сервер IBM Cognos TM1

Изначально продукт разрабатывался фирмой Cognos, но в 2009 году Cognos была поглощена компанией IBM и продукт был переименован в IBM Cognos TM1. Основное отличие TM1 от предыдущих двух серверов заключается в том, что это запатентованный 64-разрядный OLAP-сервер, использующий подход In-memory OLAP. Данный подход состоит в кешировании исходных данных и агрегатов в оперативной памяти, тем самым увеличивается производительность сервера. Последняя версия - Cognos TM1 9.5

1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется дополнительный инструмент Turbo Integrator, поддерживающий большинство существующих СУБД. Подключение в данном случае происходит через ODBC-драйвер.
2. TM1 поддерживает один вид хранения данных – MOLAP.
3. TM1 поддерживает создание вычисляемых меток.
4. TM1 поддерживает создание пользовательских агрегирующих функций.
5. Помимо кеширования TM1 позволяет сохранять подсчитанные агрегаты в БД, тем самым предусматривается гибкая оптимизация схемы агрегирования.
6. TM1 поддерживает гибкую модель масштабирования, включающую кластеризацию, функции отказоустойчивости, оптимизацию хранения и компрессию данных.
7. TM1 содержит удобный графический интерфейс, встраиваемый в Microsoft Excel, а также собственный Web-интерфейс.
8. Проблема «взрыва данных» в TM1 решена.
9. Проблема разреженности данных в TM1 также решена.
10. TM1 поддерживает спецификации OLE DB, XMLA. Язык запросов к многомерным данным – MDX.
11. TM1 может быть установлен как на ОС Windows, так и на Unix-подобную ОС.
12. TM1, так же как Essbase и MSAS, очень подробно документирован. Документация на русском языке.
13. Стоимость IBM TM1 – 50 000 $

Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back».

4. OLAP-сервер Pentaho Mondrian

В отличие от вышеперечисленных OLAP-серверов данный продукт является открытым и распространяется под лицензией EPL. Mondrian написан на Java, что с одной стороны уменьшает быстродействие (ввиду java-машины), но с другой – добавляет свойство гетерогенности среды, в которой будет использоваться сервер. Так же, как и IBM TM1, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Pentaho Analysis. Последняя версия сервера - Mondrian 3.0.4

1. Для подключения к хранилищам данных Mondrian используется JDBC-драйвер. Таким образом, сервер поддерживает СУБД, к которым можно подключаться через JDBC.
2. Mondrian поддерживает только один вид хранения данных – ROLAP.
3. Mondrian поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX.
4. Mondrian не поддерживает создание пользовательских агрегирующих функций.
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. Продукт предоставляется бесплатно. Кроме того доступны исходные коды продукта.

Следует отметить, что данный продукт поддерживает все типы иерархий, но не поддерживает полуаддитивные меры и функцию «write-back».

5. Jedox Palo

Данный продукт, так же как Mondrian является открытым и распространяется под лицензией GPL. Так же, как IBM TM1 и Mondrian, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Palo Suite. Последняя версия сервера - Palo 3.1

1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется продукт Palo ETL Server, поддерживающий большинство существующих СУБД.
2. Palo поддерживает только один вид хранения данных – MOLAP.
3. Palo поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX.
4. Palo не поддерживает создание пользовательских агрегирующих функций.
5. Palo хранит все агрегаты в оперативной памяти. Не существует возможности сохранять агрегаты на жёстком диске. Стоить отметить, что сервер использует процессор видеоадаптера (GPU), что способствует уменьшению времени вычисления агрегатов.
6. Palo масштабируем с точки зрения увеличения исходных данных. Palo очень эффективно использует ресурсы процессоров (CPU и GPU), поэтому сервер хорошо масштабируем в сторону увеличения количества процессов (ядер процессоров). Функций кластеризации и отказоустойчивости у сервера нет.
7. Palo содержит достаточно удобный графический интерфейс для создания кубов и администрирования сервера. Palo может быть встроен в Microsoft Excel и в Open Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка.
8. Проблема «взрыва данных» в Palo решена.
9. Проблема разреженности данных в Palo также решена.
10. Palo поддерживает API для языков Java, C/C++, PHP,.NET и спецификации OLE DB и XMLA. Язык запросов к многомерным данным – MDX.
11. Palo может быть установлен как на ОС Windows, так и на Unix-подобную ОС.
12. Сервер документирован достаточно хорошо, но только на английском языке.
13. Продукт предоставляется бесплатно. Кроме того доступны исходные коды продукта.

Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back».

Результаты сравнительного анализа

Объединим результаты сравнения OLAP-серверов в одну сводную таблицу:

Таблица 3.2

Сравнительный анализ OLAP-серверов

Критерий/OLAP-сервер	MSAS	Essbase	TM1	Mondrian	Palo
Поддержка PostgreSQL	-	-	+	+	+
Поддерживаемые формы хранения данных (MOLAP/ROLAP/HOLAP)	(+/+/+)	(+/-/-)	(+/-/-)	(-/+/-)	(+/-/-)
Создание вычисляемых меток	+	+	+	+	+
Создание пользовательских агрегирующих функций	+	+	+	-	-
Оптимизация схемы агрегирования	+	+	+	+	-
Масштабируемость	+	+	+	+	+
Удобные средства создания кубов и администрирования	+	+	+	+	+
Решение проблемы «взрыва данных»	+	+	+	+	+
Решение проблемы разреженности данных	+	+	+	+	+
Поддержка XMLA и MDX	+	+	+	+	+
Поддержка Unix-подобных операционных систем	-	+	+	+	+
Подробное документирование на русском языке	+	+	+	-	-
Цена продукта на минимальную конфигурацию	4000$	40000$	50000$	беспл.	беспл.

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

• все рассматриваемые продукты полностью соответствуют принципам аналитической обработки в реальном времени, изложенным Коддом, и тесту FASMI (см. подразд. 1.1);
• у платных продуктов очень гибкая схема масштабирования, включающая кластеризацию, функции отказоустойчивости;
• платные продукты поддерживают все типы иерархий и мер, а также функцию «write-back»;
• платные продукты очень подробно документированы (на русском языке);
• все рассматриваемые продукты поддерживают создание вычисляемых меток;
• бесплатные продукты не поддерживают создание пользовательских агрегирующих функций;
• во всех продуктах решена проблема «взрыва данных» и разреженности данных;
• все рассматриваемые продукты поддерживают спецификацию XMLA и язык запросов к многомерным данным - MDX;
• TM1, Mondrian, Palo используют принцип In-Memory OLAP, что увеличивает быстродействие OLAP-сервера;
• Mondrian и Palo имеют открытый исходный код.

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

• Стоимость - сервер Mondrian абсолютно бесплатен.
• Открытость исходного кода. Сервер изначально не поддерживает создание пользовательских агрегирующих функций (в отличие от платных серверов), но существует возможность доработать сервер и добавить недостающую функциональность (решение этой проблемы описано в подразд. 4.2.1).
• Mondrian написан на языке Java, являющимся кроссплатформенным. Это позволяет использовать предлагаемый подход в любой среде. Palo написан на языке C++, который не является кроссплатформенным.
• Графический интерфейс создания и администрирования кубов у Mondrian удобнее, чем у Palo.

3.2 Выбор хранилища данных

Основное требование к хранилищу данных – это оптимизация структур данных, на которых построено хранилище, для оперативного анализа данных. Также необходимо учесть выбор OLAP-сервера – выбранный OLAP-сервер Mondrian является ROLAP-сервером, поэтому хранилище данных должно быть построено на реляционной СУБД.

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

В настоящее время на рынке производителей СУБД предлагается широкий спектр СУБД. В предложенном подходе рассматривались две СУБД – MySQL и PostgreSQL. Обе СУБД являются бесплатными. Выбор был сделан в пользу PostgreSQL, т.к. данная СУБД обладает большими функциональными возможностями по сравнению с MySQL. В частности, PostgreSQL поддерживает следующие расширения языка SQL 92:

• хранимые процедуры;
• триггеры;
• правила;
• агрегирующие функции, задаваемые пользователем;
• встроенные языки программирования:
• SQL;
• PL/pgSQL;
• PL/Tcl;
• PL/Perl;
• Embedded SQL в С.
• операторы, создаваемые пользователем;
• генераторы числовых последовательностей, задаваемые пользователем;
• новые типы данных, задаваемые пользователем.

3.3 Выбор модуля преобразования и загрузки данных

Основные требования, предъявляемые к модулю преобразования и загрузки данных:

• возможность загрузки в OLAP-хранилище только изменённых данных;
• возможность преобразования данных в процессе загрузки;
• поддержка актуальности данных в OLAP-хранилище.

Ввиду принудительного запуска выполнения процедуры загрузки данных в OLAP-хранилище модуль должен поддерживать загрузку только обновлённых данных. Структуры хранилища данных СППР отличаются от структур данных в OLAP-хранилище, поэтому для обновления данных в OLAP-хранилище необходимо применять некоторые модификации к исходным данным. Такой процесс преобразования данных называется ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка»), включающий в себя:

• извлечение данных из внешних источников;
• их трансформация и очистка (англ. Data cleansing), чтобы они соответствовали нуждам бизнес-модели;
• и загрузка их в хранилище данных.

Необходима возможность описания ETL-процесса, а также запуска процесса по требованию.

Рассматривались следующие варианты реализации модуля:

• реализовать собственный модуль;
• использовать готовый открытый программный продукт Pentaho Kettle.

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

Продукт Kettle оперирует такими понятиями как преобразование (transformation) и задание (job). Задание – это специально описанная в виде направленного графа последовательность преобразований данных и условий, в зависимости от которых будет выбираться направление обхода графа. Описать ETL-процесс в Kettle – означает построить направленный граф, узлами которого являются операции преобразования данных, задания и некоторые другие элементы, такие как работа с файловой системой, условиями, сценариями, электронной почтой и др.

Входными источниками данных для Kettle могут быть:

• таблицы в БД (любого производителя);
• таблицы Microsoft Excel;
• текстовые и XML файлы;
• данные, полученные из RSS-канала;
• данные, полученные по протоколу XMLA;
• данные, полученные по LDAP (например, учётные записи пользователей домена);
• Kettle может заполнить входные данные псевдослучайными значениями.

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

ETL-процесс, описанный в Kettle, может быть вызван из командной строки Kettle написан на Java и, соответственно, может работать в гетерогенной среде.

3.4 Выбор OLAP-клиента

Основные требования, предъявляемые к OLAP-клиенту:

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

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

Все современные OLAP-клиенты удовлетворяют принципам аналитической обработки в реальном времени, изложенным Коддом в 1993 году (см. подразд. 1.1), а позднее дополненными в 1995 году.

У каждого клиента есть свои протоколы обмена информацией с OLAP-сервером и языки запросов к многомерным данным – в области OLAP на данный момент не существует каких-либо стандартизованных протоколов обмена информацией. Но при этом почти каждый клиент поддерживает стандарты «де факто» обмена информацией – XMLA (XML for Analysis) и языка запросов к многомерным данным фирмы Microsoft – MDX (Multidimensional Expressions).

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

3.4.1 Сравнительный анализ существующих OLAP-клиентов

В виду достаточно большого количества производителей OLAP-клиентов было принято решение рассмотреть только тех клиентов, которые исполнены в виде веб-приложений, т.к. веб-приложения в настоящий момент являются перспективой областью развития IT и в скором времени вытеснят настольные программы. Таким образом, были выбраны следующие продукты (табл. 3.3):

Таблица 3.3

Исследуемые OLAP-клиенты

№	Фирма-производитель	Название OLAP-клиента
1	MicroStrategy	MicroStrategy 9i
2	Cognos	PowerPlay
3	Jedox	JPalo Pivot
4	Pentaho	JPivot