3. Реализация предложенного подхода
реклама
Титульник ТЗ 2 Аннотация 3 Оглавление Список сокращений, используемых в работе....................................................... 6 Введение ................................................................................................................... 7 1. Аналитический обзор .......................................................................................... 9 1.1 Оперативный анализ данных (OLAP) ......................................................... 9 1.1.1 Подходы к построению OLAP-систем ............................................... 14 1.1.2 Хранилища данных, используемые в OLAP-системах .................... 17 1.1.3 Многомерная модель данных в OLAP-анализе ................................ 19 1.1.4 Подходы к реализации многомерной модели данных ..................... 23 1.1.5 Классификация OLAP-систем по способу хранения данных .......... 26 1.2 Системы поддержки принятия решений .................................................. 27 1.2.1 Применение многомерного анализа данных в СППР ...................... 28 1.2.2 Особенности СППР, учитывающих риски предприятий ................. 29 1.2.3 Недостаток существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих риски предприятий ................................................................................................... 30 1.3 Выводы ......................................................................................................... 30 2. Описание предложенного подхода.................................................................. 31 2.1 Предлагаемый подход к построению подсистемы многомерного анализа данных в СППР, учитывающих особенности изменяемых во времени факторов .............................................................................................. 31 2.2 Архитектура подхода .................................................................................. 31 2.3 Достоинства подхода .................................................................................. 32 2.4 Выводы ......................................................................................................... 32 4 3. Реализация предложенного подхода ............................................................... 32 3.1 Выбор хранилища данных.......................................................................... 32 3.2 Выбор модуля преобразования и загрузки данных ................................. 32 3.3 Выбор OLAP-сервера .................................................................................. 32 3.3.1 Сравнительный анализ существующих OLAP-серверов ................. 32 3.4 Выбор OLAP-клиента ................................................................................. 32 3.4.1 Сравнительный анализ существующих OLAP-клиентов................. 32 3.5 Выводы ......................................................................................................... 32 4. Апробация предложенного подхода ............................................................... 32 4.1 Обзор СППР для департамента РЭП Минпромторга .............................. 32 4.2 Реализация подсистемы многомерного анализа данных в СППР для департамента РЭП Минпромторга .................................................................. 32 4.2.1 Разработка хранилища данных и многомерных OLAP-кубов......... 32 4.2.2 Настройка OLAP-сервера .................................................................... 32 4.2.3 Подключение OLAP-клиента .............................................................. 32 4.3 Выбор критериев качества для предложенного подхода ........................ 33 4.4 Анализ качества и рекомендации по его улучшению ............................. 33 4.5 Выводы ......................................................................................................... 33 Заключение ............................................................................................................ 33 Список литературы ............................................................................................... 33 Приложения ........................................................................................................... 33 5 Список сокращений, используемых в работе 6 Введение Современные условия ведения бизнеса, характеризующиеся возрастающей жесткой конкуренцией и нестабильностью экономических условий, предъявляют повышенные требования к оперативности и качеству принимаемых решений на всех уровнях управления предприятием или организацией. При этом объем информации, которую необходимо учитывать для формирования оптимальных обоснованных решений, неуклонно растет. Это приводит к ситуации, когда становится невозможно эффективно управлять компанией без использования современных средств информационного обеспечения. За последние 20 лет информационно-аналитические системы меняли свои названия и содержание, пройдя путь от информационных систем руководителя (executive information systems, EIS) до систем поддержки принятия решений (СППР). Современные СППР строятся на основе технологий, позволяющих пользователю-непрограммисту легко и оперативно извлекать информацию из различных источников, формировать собственные настраиваемые отчеты или графические представления, проводить многомерный анализ данных. Разнообразие этих технологий принято объединять термином «бизнесаналитика» или Business Intelligence (BI). Развитие систем бизнес-аналитики прошло путь от «толстых» клиентов до Web-приложений, в которых пользователь ведет исследование с помощью браузера и может работать удаленно. Цель технологий BI - своевременно принимать решения, основываясь на корректных данных. Сегодня создание и внедрение BI технологий сформировалось в самостоятельное динамично развивающееся направление индустрии информационных технологий. 7 Целью выпускной квалификационной работы является выбор подхода построения подсистем многомерного анализа данных для СППР, учитывающих риски предприятий, и его применение в СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ. Для достижения поставленной цели необходимо сформулировать и решить следующие задачи: 1. Исследовать существующие подходы к построению подсистем многомерного анализа данных. 2. Разработать архитектуру подсистем многомерного анализа данных для СППР, учитывающих риски предприятий. 3. Реализовать подсистему многомерного анализа данных в СППР для департамента радиоэлектронной промышленности Минпромторга. Объектом исследования является класс СППР, учитывающих изменяемые с течением времени факторы (оценки, риски, вероятности и др.) для формирования оптимальных обоснованных решений. Предметом исследования является технология оперативного многомерного анализа данных (OLAP), применяемая в СППР. Новизна работы состоит в предложении нового подхода для построения подсистем многомерного анализа данных в СППР, учитывающих изменяемые с течением времени факторы. Практическая значимость работы заключается в реализации предложенного подхода в СППР для департамента радиоэлектронной промышленности Министерства промышленности и торговли РФ. 8 1. Аналитический обзор 1.1 Оперативный анализ данных (OLAP) OLAP (Online Analytical Processing) — это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, обеспечивающих сбор, хранение, манипулирование и анализ многомерных данных. Термин OLAP был предложен доктором Е.Ф. Коддом, его супругой С.Б. Кодд и их коллегой С.Т. Солли в исследовательской статье "OLAP для пользователей-аналитиков: информационно-технологический мандат". Эта статья была опубликована в начале 1993 года и спонсировалась корпорацией Arbor Software, создателем и распространителем первого OLAP-продукта Essbase. Статья определяет OLAP как «имя, данное динамическому анализу предприятия, необходимому для создания, манипулирования, оживления и синтезирования информации на базе "моделей информации о предприятии" ("Enterprise Data Models")». Основная цель оперативного анализа данных — проверка аналитиками возникающих гипотез. Аналитики являются особыми потребителями корпоративной информации, задача которых находить закономерности в больших массивах данных и делать выводы о текущем состоянии бизнеса. Данные, которые требуются аналитику для работы, обязательно содержат числовые значения, что обусловлено самой сущностью его деятельности. Оперативность в современном бизнесе — один из факторов успеха. Аналитику нужен такой инструмент, который позволил бы визуализировать данные быстро, просто и удобно. В качестве такого инструмента и выступает OLAP. 9 В 1993 году Кодд сформулировал «12 принципов аналитической обработки в реальном времени» [8] (см. табл. 1.1): Таблица 1.1 Принципы аналитической обработки в реальном времени № Принцип 1 Многомерное представление Средства данных Описание должны поддерживать многомерный на концептуальном уровне взгляд на данные. 2 Прозрачность Пользователь не должен знать о том, какие конкретные средства используются обработки для хранения данных, как и данные организованы и откуда они берутся. 3 Доступность Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником Средства должны автоматическое данных. обеспечивать отображение их собственной логической схемы в различные гетерогенные источники данных. 4 Согласованная Производительность практически не производительность должна зависеть от количества Измерений в запросе. 5 6 Поддержка архитектуры клиент- Средства должны работать в сервер архитектуре клиент-сервер. Равноправность всех измерений Ни одно из измерений не должно 10 быть базовым, все они должны быть равноправными (симметричными). 7 Динамическая обработка Неопределенные значения должны разреженных матриц храниться и обрабатываться наиболее эффективным способом. 8 Поддержка Средства многопользовательского обеспечивать режима возможность работать более чем работы с данными 9 должны одному пользователю. Поддержка операций на основе Все различных измерений многомерные (например, операции агрегация) единообразно и должны согласованно применяться к любому числу любых измерений. 10 Простота манипулирования Средства данными должны иметь максимально естественный удобный, и комфортный пользовательский интерфейс. 11 Развитые средства представления Средства данных должны поддерживать различные способы визуализации (представления) данных. 12 Неограниченное число измерений Не должно быть ограничений на и уровней агрегации данных число поддерживаемых измерений. В 1995 году на основе принципов, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие оперативного анализа данных [2]: 11 требования к приложениям предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа; возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде; многопользовательский соответствующих доступ механизмов к данным с блокировок поддержкой и средств авторизованного доступа; многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP); возможность обращаться к любой нужной информации независимо от ее объема и места хранения. Большинство из существующих OLAP-средств удовлетворяют всем этим требованиям. Однако в реализации подобных приложений возникает ряд проблем, прежде всего связанных с увеличением объёма данных, которые необходимо хранить. В настоящее время встречаются следующие применения OLAP: Анализ данных. Задача, для которой изначально использовались и до сих пор остаются самыми популярными OLAP-средства. Многомерная модель данных, возможность анализировать значительные объёмы данных и быстрый отклик на запросы делают подобные системы незаменимыми для анализа продаж, маркетинговых мероприятий, дистрибуции и других задач с большим объёмом исходных данных. Примеры продуктов: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, 12 Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy, Business Objects. Финансовое планирование\бюджетирование. Многомерная модель позволяет одновременно вводить данные и легко анализировать их (например, план-факт анализ). Поэтому ряд современных продуктов класса CPM (Corporate Performance Management) используют OLAP-модели. Важная задача – многомерный обратный расчёт (back-solve, breakback, writeback), позволяющий рассчитать требуемые изменения детальных ячеек при изменении агрегированного значения. Это инструмент для анализа «что-если» (what-if), т.е. для проигрывания различных вариантов событий при планировании. Примеры продуктов: Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac. Финансовая консолидация. Консолидация данных согласно международным стандартам учёта, принимая во внимание доли владения, различные валюты и внутренние обороты – актуальная задача в связи с ужесточающимися требованиями проверяющих органов (SOX, Basel II) и выходом компаний на IPO (Initial Public Offering — первая публичная продажа акций частной компании). OLAP-технологии позволяют ускорить расчёт консолидированных отчётов и повысить прозрачность всего процесса. Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller. 13 1.1.1 Подходы к построению OLAP-систем По аналогии с подходами построения клиент-серверных систем выделяют два подхода к построению OLAP-систем: 1. Подход, основанный на двухзвенной архитектуре (рис. 1.1). 2. Подход, основанный на трёхзвенной архитектуре (рис. 1.2). Рис. 1.1 Двухзвенная архитектура построения OLAP-систем Рис. 1.2 Трёхзвенная архитектура построения OLAP-систем OLAP-система, построенная на двухзвенной архитектуре, состоит из хранилища данных, настольной OLAP-системы и сетью передачи данных между ними. Хранилище данных является источником входных данных для анализа. Структуры данных хранилища специальным образом оптимизированы (см. подразд. 1.1.2) для уменьшения времени обработки запросов, посылаемых настольной OLAP-системой. Настольная OLAPсистема вычисляет и отображает анализируемые данные. OLAP-система, построенная на трёхзвенной архитектуре, состоит из хранилищ данных, OLAP-клиента, OLAP-сервера и сетью передачи данных 14 между ними. Хранилище данных играет туже роль, что и в двухзвенной архитектуре. В отличие от предыдущего подхода, выделяются OLAP-сервер, отвечающий за вычисления анализируемых данных, и OLAP-клиент, отображающий анализируемые данные. Исходные данные для анализа, находящиеся в хранилище, могут поступать из различных источников данных, таких как оперативные БД, таблицы Microsoft Excel, XML-документы и др. Эти данные поступают в хранилище с определённой периодичностью (например, еженедельно или ежедневно — в зависимости от потребностей), поэтому на момент анализа могут быть не актуальными. С одной стороны, это не является проблемой, когда аналитик просматривает данные, за прошедший период времени, т.к. аналитик не обращает внимания на отдельно взятые факты — ему необходима суммарная информация о сотнях и тысячах событий. Но с другой стороны, это может вызывать проблему при планировании, т.к. выбор того или иного решения зависит от текущей ситуации, которая может изменяться несколько раз в течение одного дня (см. подразд. 1.2.2). Сравним данные подходы по эксплуатационным и стоимостным показателям: 1. Объем обрабатываемых данных. Объем данных определяется предметной областью анализируемых данных, а также количеством записей в хранилище данных. Как и настольная OLAP-система, так и OLAP-сервер, вынуждены кешировать данные в оперативной памяти для уменьшения количества запросов к хранилищу данных. Таким образом, объем данных, обрабатываемых настольной OLAP-системой и OLAP-сервером, находится в прямой зависимости от объема оперативной памяти. У серверов объём оперативной памяти больше, чем у пользовательских ПК, поэтому OLAP-сервер может обрабатывать большие объемы данных, чем настольная OLAP-система. 15 2. Производительность системы. Эта характеристика определяется следующими факторами: объемом обрабатываемых данных и мощностью компьютеров. При возрастании количества входных анализируемых снижается за данных счет производительность значительного всех увеличения OLAP-систем количества высчитываемых суммарных значений, но при этом темпы снижения разные. Продемонстрируем эту зависимость на графике (рис. 1.10): Рис. 1.3 Зависимость времени отклика OLAP-системы от объема обрабатываемых данных Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и настольной OLAP-системой. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки", в то время как настольная OLAP-система вычисляет весь набор суммарных значений в момент загрузки. 3. Сетевой трафик. При использовании OLAP-сервера по сети на ПК OLAP-клиента передаются только данные для отображения, в то время как настольная OLAP-система получает весь объем данных первичной 16 выборки. Поэтому там, где применяется настольные OLAP-системы, сетевой трафик будет выше. Но, при применении OLAP-сервера операции пользователя, например детализация, порождают новые запросы к многомерной базе, а, значит, новую передачу данных. Выполнение же OLAP-операций настольной OLAP-системой производится в оперативной памяти и, соответственно, не вызывает новых потоков данных в сети. Также необходимо отметить, что современное сетевое оборудование обеспечивает высокий уровень пропускной способности. 4. Затраты на внедрение и сопровождение. Стоимость OLAP-сервера достаточно высока. Дополнительно следует учитывать стоимость выделенного сервера и постоянные затраты на администрирование хранилища данных. Кроме того, внедрение и сопровождение OLAPсервера требует от персонала достаточно высокой квалификации. Стоимость настольной OLAP-системы на порядок ниже стоимости OLAP-сервера. Администрирования и дополнительного технического оборудования для настольной OLAP-системы не требуется. К квалификации персонала при внедрении настольных OLAP-систем высоких требований не предъявляется. Настольная OLAP-система может быть внедрена значительно быстрее OLAP-сервера. 1.1.2 Хранилища данных, используемые в OLAP-системах Хранилище данных – обязательная составляющая любой OLAPсистемы. В хранилище хранятся исходные данные для анализа. Хранилище данных (англ. Data Warehouse) — очень большая предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в 17 организации. Строится на базе клиент-серверной архитектуры, реляционной СУБД и утилит поддержки принятия решений. Данные, поступающие в хранилище данных, становятся доступны только для чтения. Данные из промышленной OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы промышленной системы и не нарушал её стабильность. Существуют два архитектурных направления построения хранилищ данных – нормализованные хранилища данных и размерностные хранилища. В нормализованных хранилищах, данные находятся в предметно ориентированных таблицах третьей нормальной формы. Нормализованные хранилища характеризуются как простые в создании и управлении, недостатки нормализованных хранилищ – большое количество таблиц как следствие нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих таблиц одновременно, что приводит к ухудшению производительности системы. Размерностные хранилища используют ненормализованные структуры данных (см. подразд. 1.1.4), что увеличивает размер базы данных, но уменьшает время обработки запросов на выборку данных вследствие меньшего использования соединений таблиц. Основным достоинством размерностных хранилищ является простота и понятность для разработчиков и пользователей, также, благодаря более эффективному хранению данных и формализованным размерностям, облегчается и ускоряется доступ к данным, особенно при сложных анализах. Основным недостатком является более сложные процедуры подготовки и загрузки данных, а также управление и изменение размерностей данных. Для OLAP-анализа используется размерностные хранилища. 18 второй тип хранилищ – 1.1.3 Многомерная модель данных в OLAP-анализе Преимущество использования OLAP-анализа — это оперативность обработки запросов, поступающих от аналитика в процессе его работы. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. Более хорошей моделью для запросов, а не для изменения, является многомерная (нередко называемая пространственной) модель данных [7]. Многомерная модель данных — это расширение реляционной модели. В отличие от реляционной модели, где основным понятием является «отношение», в многомерной модели основным понятием является многомерный «куб» (нередко называемый также OLAP-кубом), который является обобщением реляционных таблиц на любое число измерений. Набор соответствующих кубов составляет многомерную базу данных. Многомерная модель данных не рассчитана на частое выполнение транзакций, но очень удобна именно для анализа больших массивов данных. Она наиболее адекватна представлениям о предметной области, которыми оперирует аналитик. Некоторые преимущества многомерной модели по сравнению с реляционной [7]: Возможность анализа больших объемов данных с приемлемой скоростью; Возможность осуществления любых «срезов» и «углублений» в определённой структуре БД; Быстрая локализация трендов и проблемных областей. 19 Многомерный куб представлен набором мер и измерений, а именно, куб — это декартовое произведение измерений, где для каждого элемента произведения проставлен набор мер. Измерения куба – набор доменов, по которым создаётся многомерное пространство. Другими словами, измерение – это упорядоченный набор значений, соответствующий грани куба. Многомерное моделирование предусматривает использование измерений для предоставления максимальной информативности [3]. В отличие от реляционных баз данных, контролируемая избыточность в многомерных базах данных считается оправданной, если она увеличивает информационную ценность. Измерения используются для выбора и агрегирования данных на требуемом уровне детализации. Измерения организуются в иерархию, состоящую из нескольких уровней, каждый из которых представляет уровень детализации, требуемый для соответствующего анализа. Многомерная модель данных предназначена для анализа информации. Единицей анализируемой информации считается когда-либо произошедший факт, т.е. факты представляют субъект — некий шаблон или событие, которые необходимо проанализировать. В большинстве многомерных моделей данных факты однозначно определяются комбинацией значений измерений. Факт существует только тогда, когда ячейка для конкретной комбинации значений не пуста. гранулярностью, определенной Каждый факт обладает некоторой уровнями, из которых создается их комбинация значений измерений. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся: факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами 20 которых являются телефонный звонок или снятие денег со счета с помощью банкомата); факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Мера (или показатель) – это определяется фиксированным значение, набором которое измерений и однозначно количественно характеризует анализируемые факты. Меры бывают трёх типов: аддитивные (additive) меры – допускающие агрегирование относительно любого измерения куба данных; неаддитивные (nonadditive) меры – которые не могут агрегироваться ни по какому измерению куба данных; полуаддитивные (semiadditive) меры – которые допускают агрегирование относительно одних измерений и не допускают относительно других. Многомерная база данных естественным образом предназначена для определенных типов запросов: 21 Запросы вида slice и dice (срезы куба) — формирование подмножества многомерного массива данных, соответствующего единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Если рассматривать термин slice с позиции конечного пользователя, то наиболее часто его роль играет двумерная проекция куба (рис. 1.4). Срез dice отличается от slice тем, что это трёхи более-мерная проекция куба. Фиксированное значение Срез Рис. 1.4 Операция среза (slice) Запросы вида drill-down (детализация) и roll-up (обобщение) — взаимообратные операции, которые используют иерархию измерений и меры для агрегирования. Направление детализации/обобщения может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями. Запросы вида drill-across комбинируют кубы, которые имеют одно или несколько общих измерений. С точки зрения реляционной алгебры такая операция выполняет слияние (join). Запросы вида ranking возвращают только те ячейки, которые появляются в верхней или нижней части упорядоченного определенным образом списка. Поворот (rotating) куба дает пользователям возможность увидеть данные, сгруппированные по другим измерениям (рис. 1.5). Например, 22 операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид. Измерение1 Измерение2 Измерение2 Измерение1 Вращение Измерение3 Измерение3 Рис. 1.5 Операция вращения (rotating) Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации. 1.1.4 Подходы к реализации многомерной модели данных Многомерная структура хранения данных может быть реализована с помощью многомерных БД или в системе управления реляционными БД с использованием схемы звезды (star schema) или схемы снежинки (snowflake schema) [7]. Схема звезды (рис. 1.6) является реляционным воплощением многомерной представления данных. Она является проекцией куба на «реляционную плоскость» и состоит из одной таблицы фактов (fact table) и 23 нескольких таблиц измерений (dimension table). Таблица фактов содержит по одной строке для каждого факта — минимально рассматриваемого атома анализируемого процесса. Рис.1.6 Пример куба, построенного по схеме «Звезда» Полями таблицы фактов, помимо ключей, являются меры (measures), описывающие количественную характеристику факта. Таблицы измерений содержат собственно значения измерений, то есть информацию, характеризующую факты. Обычно это неизменяемые, либо редко изменяемые данные. Каждая таблица измерений находится в отношении «один ко многим» с таблицей фактов. Время является несколько особенным и практически необходимым измерением любого хранилища данных. Схема звезды не соответствует требованиям нормальной формы. С точки зрения нормализации таблицы измерений хранят избыточные данные. 24 Рис.1.9 Пример куба, построенного по схеме «Снежинка» Схема снежинки является модификацией схемы звезды — часть таблиц измерений разбита на несколько связанных таблиц (рис. 1.9). Благодаря частичной нормализации, «снежинка» позволяет сэкономить дисковое пространство, но она уменьшает скорость просмотра измерений. Решение в сторону использования схемы звезды или схемы снежинки, обуславливается относительной мощностью платформы БД, и инструментария для реализации запросов. Схема снежинки подходит окружению, в котором инструментарий реализации запросов предоставляет пользователям широкий доступ к структуре таблиц, а также в окружениях, где большинство запросов просты по своей природе. Схема звезды более подходит для случаев применения более сложного инструментария для реализации запросов, который в большей степени изолирует пользователей от детальной структуры таблиц, а также для среды с множеством запросов сложной структуры. 25 1.1.5 Классификация OLAP-систем по способу хранения данных И исходные и агрегатные (суммарные) данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP) [2]. Соответственно, OLAP-системы по способу хранения данных делятся на три аналогичные категории: в случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе; в ROLAP-системах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-системы; в случае использования HOLAP архитектуры исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-системы на основе реляционных и многомерных данных. Сохранение всех агрегатных данных не всегда оправданно. При добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (говорят о «взрывном росте» объема данных). Степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов. Некоторые OLAP-системы поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако 26 большинство современных OLAP-систем поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. 1.2 Системы поддержки принятия решений Система поддержки принятия решений (СППР) (англ. Decision Support System, DSS) — компьютерная автоматизированная система, целью которой является помощь людям, принимающим решение в сложных условиях для полного и объективного анализа предметной деятельности. СППР обладает следующими четырьмя основными характеристиками: 1. СППР использует и данные, и модели; 2. СППР предназначены для помощи менеджерам в принятии решений для слабоструктурированных и неструктурированных задач; 3. Они поддерживают, а не заменяют, выработку решений менеджерами; 4. Цель СППР — улучшение эффективности решений. Принятие решений предусматривает последовательное выполнение следующих шагов: осмысливание проблемы, диагностика, концептуальное или математическое моделирование, выработка альтернатив и выбор тех, которые в наибольшей степени удовлетворяют поставленным целям, а также мониторинг осуществления решения. Как правило, СППР имеют модульную структуру, что позволяет быстро включать новые методы анализа информации для принятия эффективных обоснованных решений. Это могут быть: информационный 27 поиск, интеллектуальный анализ данных, поиск знаний в базах данных, рассуждение на основе прецедентов, имитационное моделирование, эволюционные вычисления и генетические алгоритмы, нейронные сети, ситуационный анализ, когнитивное моделирование, многомерный анализ данных и др. 1.2.1 Применение многомерного анализа данных в СППР Многомерный анализ данных – это извлечение полезной информации из многомерной структуры данных посредством оперативного анализа (OLAP). Многомерный анализ данных является современным методом анализа данных в СППР для принятия эффективных обоснованных решений. Многомерный анализ позволяет лицу, принимающему решение (ЛПР), делать срезы многомерных данных, высчитывать суммарные значения по любым измерениям, тем самым обеспечивая ЛПР любой интересующей информацией. Другими словами, многомерный анализ данных позволяет формировать любой отчёт без участия программистов и без знания языков запросов к базам данных. Большим преимуществом многомерного анализа данных по сравнению с другими способами анализа является автоматический подсчёт агрегатных (суммарных, средних и др.) значений. Таким образом, ЛПР может посмотреть любой интересующую его статистическую информацию за определённый промежуток времени. Многомерный анализ данных применяется только в СППР, ориентированных на работу с данными (Data-driven DSS) и имеющих большую базу исходных данных, накопленных за значительный период времени. 28 1.2.2 Особенности СППР, учитывающих риски предприятий Современные СППР для принятия обоснованных решений учитывают очень большое количество факторов, например, риски предприятий. Под рисками предприятий понимается вероятность успешного выполнения предприятием определённого задания и ожидаемый ущерб, нанесённый заказчику при срыве задания. Часть из всех факторов, рассматриваемых СППР, такие как риски, оценки, вероятности и др. могут изменяться с течением времени и, следовательно, СППР должна учитывать это. В теории менеджмента существует специальный подход к выбору оптимального решения в обстановке изменяемых во времени факторов – ситуационный подход. Ситуация, в данном случае, – это состояние значений всех динамически изменяемых факторов в текущий момент времени. Ситуационный подход предполагает создание различных вариантов решений, каждое из которых пригодно в той или иной ситуации. Самым эффективным решением в конкретной ситуации является решение, которое более всего соответствует данной ситуации. Факторы, изменяемые в течение времени, накладывают ограничения на структуру хранилища данных СППР. Это связано с тем, что история изменения значений факторов не сохраняется в хранилище данных, т.к. предыдущее значение фактора становится неактуальным для СППР сразу же после изменения и не используется ею в дальнейшем. С другой стороны значения данных факторов могут изменяться очень часто (несколько раз в день), что приводит к пересчёту большого количества параметров, зависящих от данного фактора. Это приводит к тому, что часть хранилища данных нормализована и оптимизирована для обновления данных, а не для хранения. 29 1.2.3 Недостаток существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих риски предприятий Основным недостатком существующих подходов к построению подсистем многомерного анализа данных в СППР, учитывающих изменяемые с течением времени факторы, в частности риски предприятий, является их неэффективность использования, т.к. часть хранилища данных, используемая СППР и подсистемой многомерного анализа, обязательно нормализована и оптимизирована для быстрого обновления данных. 1.3 Выводы В данной главе была рассмотрена технология оперативного анализа данных – OLAP и её применение в системах поддержки принятия решений. OLAP – актуальная и востребованная тема исследований, её практические результаты имеют широкое применение. Несмотря на достаточно долгую историю исследований, до сих не существует единых терминологических стандартов, стандартов передачи данных, языка запросов и формирования кубов. Растущие объёмы корпоративных данных повышают значимость средств анализа, большая часть которых построена на OLAPпринципах, в связи с чем, актуальны проблемы выбора оптимальных схем хранения и обработки OLAP-кубов. Системы поддержки принятия решений используют технологию оперативного многомерного анализа данных для принятия эффективных обоснованных решений. Был рассмотрен класс СППР, учитывающих при выборе решений значения факторов, изменяемых с течением времени. Также были рассмотрены особенности и недостатки существующих классических подходов построения подсистем многомерного анализа данных для СППР этого класса. 30 2. Описание предложенного подхода 2.1 Предлагаемый многомерного подход анализа к данных построению в СППР, подсистемы учитывающих особенности изменяемых во времени факторов Учитывая недостатки классических подходов к построению подсистем многомерного анализа данных для СППР, учитывающих изменяемые во времени факторы, автором ВКР был предложен улучшенный подход, устраняющий эти недостатки. Суть подхода заключается в добавлении нового хранилища данных, которое будет использоваться подсистемой многомерного анализа и будет полностью оптимизировано для анализа. Подход основывается трёхзвенной архитектуре построения OLAP-систем (рис 2.1). Рис. 2.1 Предлагаемый подход к построению OLAP-системы 31 на 2.2 Архитектура подхода 2.3 Достоинства подхода 2.4 Выводы 3. Реализация предложенного подхода 3.1 Выбор хранилища данных 3.2 Выбор модуля преобразования и загрузки данных 3.3 Выбор OLAP-сервера 3.3.1 Сравнительный анализ существующих OLAP-серверов 3.4 Выбор OLAP-клиента 3.4.1 Сравнительный анализ существующих OLAP-клиентов 3.5 Выводы 4. Апробация предложенного подхода 4.1 Обзор СППР для департамента РЭП Минпромторга 4.2 Реализация подсистемы многомерного анализа данных в СППР для департамента РЭП Минпромторга 4.2.1 Разработка хранилища данных и многомерных OLAP-кубов 4.2.2 Настройка OLAP-сервера 4.2.3 Подключение OLAP-клиента 32 4.3 Выбор критериев качества для предложенного подхода 4.4 Анализ качества и рекомендации по его улучшению 4.5 Выводы Заключение Список литературы Приложения 33
