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

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

Поддержка архитектуры клиент-сервер

Средства должны работать в архитектуре клиент-сервер.

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



Принцип

Описание

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-система вычисляет весь набор суммарных значений в момент загрузки.


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

  2. Затраты на внедрение и сопровождение. Стоимость 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 тем, что это трёх- и более-мерная проекция куба.

pic3-02

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



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

  • Запросы вида drill-across комбинируют кубы, которые имеют одно или несколько общих измерений. С точки зрения реляционной алгебры такая операция выполняет слияние (join).

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

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

pic3-03

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

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

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



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


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

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



c:\documents and settings\администратор\мои документы\схема звезда.png

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

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

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

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

c:\documents and settings\администратор\мои документы\схема снежинки.png

Рис.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-кубов.



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