Olap расшифровка. OLAP-технологии

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

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

Основное назначение OLAP-систем -- поддержка аналитической деятельности, произвольных (часто используется термин ad-hoc) запросов пользователей-аналитиков. Цель OLAP-анализа -- проверка возникающих гипотез.

У истоков технологии OLAP стоит основоположник реляционного подхода Э. Кодд. В 1993 г. он опубликовал статью под названием «OLAP для пользователей-аналитиков: каким он должен быть». В данной работе изложены основные концепции оперативной аналитической обработки и определены следующие 12 требований, которым должны удовлетворять продукты, позволяющие выполнять оперативную аналитическую обработку. Токмаков Г.П. Базы данных. Концепция баз данных, реляционная модель данных, языки SQL. С. 51

Ниже перечислены 12 правил, изложенных Коддом и определяющих OLAP.

1. Многомерность -- OLAP-система на концептуальном уровне должна представлять данные в виде многомерной модели, что упрощает процессы анализа и восприятия информации.

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

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

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

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

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

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

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

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

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

11. Гибкие возможности получения отчетов -- OLAP-система должна поддерживать различные способы визуализации данных, т.е. отчеты должны представляться в любой возможной ориентации. Средства формирования отчетов должны представлять синтезируемые данные или информацию, следующую из модели данных в ее любой возможной ориентации. Это означает, что строки, столбцы или страницы должны показывать одновременно от 0 до N измерений, где N-- число измерений всей аналитической модели. Кроме того, каждое измерение содержимого, показанное в одной записи, колонке или странице, должно позволять показывать любое подмножество элементов (значений), содержащихся в измерении, в любом порядке.

12. Неограниченная размерность и число уровней агрегации -- исследование о возможном числе необходимых измерений, требующихся в аналитической модели, показало, что одновременно может использоваться до 19 измерений. Отсюда вытекает настоятельная рекомендация, чтобы аналитический инструмент мог одновременно предоставить хотя бы 15, а предпочтительно -- 20 измерений. Более того, каждое из общих измерений не должно быть ограничено по числу определяемых пользователем-аналитиком уровней агрегации и путей консолидации.

Дополнительные правила Кодда.

Набор этих требований, послуживших де-факто определением OLAP, достаточно часто вызывает различные нарекания, например, правила 1, 2, 3, 6 являются требованиями, а правила 10, 11 -- неформализованными пожеланиями. Токмаков Г.П. Базы данных. Концепция баз данных, реляционная модель данных, языки SQL. С. 68 Таким образом, перечисленные 12 требований Кодда не позволяют точно определить OLAP. В 1995 г. Кодд к приведенному перечню добавил следующие шесть правил:

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

14. Поддержка всех моделей OLAP-анализа -- OLAP-система должна поддерживать все четыре модели анализа данных, определенные Коддом: категориальную, толковательную, умозрительную и стереотипную.

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

16. Сохранение результатов OLAP: хранение их отдельно от исходных данных -- OLAP-система, работающая в режиме чтения-записи, после модификации исходных данных должна результаты сохранять отдельно. Иными словами, обеспечивается безопасность исходных данных.

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

18. Обработка отсутствующих значений -- OLAP-система должна игнорировать все отсутствующие значения без учета их источника. Эта особенность связана с 17-м правилом.

Кроме того, Кодд разбил все 18 правил на следующие четыре группы, назвав их особенностями. Эти группы получили названия В, S, R и D.

Основные особенности (В) включают следующие правила:

Многомерное концептуальное представление данных (правило 1);

Интуитивное манипулирование данными (правило 10);

Доступность (правило 3);

Пакетное извлечение против интерпретации (правило 13);

Поддержка всех моделей OLAP-анализа (правило 14);

Архитектура «клиент-сервер» (правило 5);

Прозрачность (правило 2);

Многопользовательская поддержка (правило 8)

Специальные особенности (S):

Обработка ненормализованных данных (правило 15);

Сохранение результатов OLAP: хранение их отдельно от исходных данных (правило 16);

Исключение отсутствующих значений (правило 17);

Обработка отсутствующих значений (правило 18). Особенности представления отчетов (R):

Гибкость формирования отчетов (правило 11);

Стандартная производительность отчетов (правило 4);

Автоматическая настройка физического уровня (измененное оригинальное правило 7).

Управление измерениями (D):

Универсальность измерений (правило 6);

Неограниченное число измерений и уровней агрегации (правило 12);

Неограниченные операции между размерностями (правило 9).

В 1993 году основоположник реляционного подхода к построению баз данных Эдгар Кодд с партнерами (Edgar Codd, математик и стипендиат IBM), опубликовали статью, инициированную компанией "Arbor Software" (сегодня это известнейшая компания "Hyperion Solutions"), озаглавленную "Обеспечение OLAP (оперативной аналитической обработки) для пользователей-аналитиков", в которой сформулированы 12 особенностей технологии OLAP , которые впоследствии были дополнены еще шестью. Эти положения стали основным содержанием новой и очень перспективной технологии.

Основные особенности технологии OLAP (Basic):

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

Специальные особенности ( Special ):

• обработка неформализованных данных;
• сохранение результатов OLAP : хранение их отдельно от исходных данных;
• исключение отсутствующих значений;
• обработка отсутствующих значений.

Особенности представления отчетов ( Report ):

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

Управление измерениями ( Dimension ):

• универсальность измерений;
• неограниченное число измерений и уровней агрегации ;
• неограниченное число операций между размерностями.

Исторически сложилось так, что сегодня термин " OLAP " подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД. Именно с этим связано появление в качестве самостоятельных терминов "Реляционный OLAP" ( ROLAP ) и "Многомерный OLAP" ( MOLAP ).

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

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

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

Рис. 6.14.

Имея в своем распоряжении гибкие механизмы манипулирования данными и визуального отображения (рис. рис. 6.15 , рис. 6.16), менеджер сначала рассматривает с разных сторон данные, которые могут быть (а могут и не быть) связаны с решаемой проблемой.

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

У управляющего компанией, например, может зародиться гипотеза о том, что разброс роста активов в различных филиалах компании зависит от соотношения в них специалистов с техническим и экономическим образованием. Чтобы проверить эту гипотезу, менеджер может запросить из хранилища и отобразить на графике интересующее его соотношение для тех филиалов, у которых за текущий квартал рост активов снизился по сравнению с прошлым годом более чем на 10%, и для тех, у которых повысился более чем на 25%. Он должен иметь возможность использовать простой выбор из предлагаемого меню. Если полученные результаты ощутимо распадутся на две соответствующие группы, то это должно стать стимулом для дальнейшей проверки выдвинутой гипотезы.

В настоящее время быстрое развитие получило направление, называемое динамическим моделированием (Dynamic Simulation ), в полной мере реализующее указанный выше принцип FASMI.

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

В таблице 6.3 приведены сравнительные характеристики статического и динамического анализа.

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

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

Ключевые вопросы "Сколько продано?", "На какую сумму продано?" расширяются по мере усложнения бизнеса и накопления исторических данных до некоторого множества факторов, или разрезов: "..в Санкт-Петербурге, в Москве, на Урале, в Сибири…", "..в прошлом квартале, по сравнению с нынешним", "..от поставщика А по сравнению с поставщиком Б…" и т. д.

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

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

Время . Как правило, это несколько периодов: Год, Квартал, Месяц, Декада, Неделя, День. Многие OLAP -инструменты автоматически вычисляют старшие периоды из даты и вычисляют итоги по ним.

Категория товара . Категорий может быть несколько, они отличаются для каждого вида бизнеса: Сорт, Модель, Вид упаковки и пр. Если продается только один товар или ассортимент очень невелик, то категория не нужна.

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

Регион . В зависимости от глобальности бизнеса можно иметь в виду Континент, Группа стран, Страна, Территория, Город, Район, Улица, Часть улицы. Конечно, если есть только одна торговая точка, то это измерение отсутствует.

Продавец . Это измерение тоже зависит от структуры и масштабов бизнеса. Здесь может быть: Филиал, Магазин, Дилер, Менеджер по продажам. В некоторых случаях измерение отсутствует, например, когда продавец не влияет на объемы сбыта, магазин только один и так далее.

Покупатель . В некоторых случаях, например, в розничной торговле , покупатель обезличен и измерение отсутствует, в других случаях информация о покупателе есть, и она важна для продаж. Это измерение может содержать название фирмы-покупателя или множество группировок и характеристик клиентов: Отрасль, Группа предприятий, Владелец и так далее.. Анализ структуры продаж для выявления важнейших составляющих в интересующем разрезе. Для этого удобно использовать, например, диаграмму типа "Пирог" в сложных случаях, когда исследуется сразу 3 измерения - "Столбцы". Например, в магазине "Компьютерная техника" за квартал продажи компьютеров составили $100000, фототехники -$10000, расходных материалов - $4500. Вывод: оборот магазина зависит в большой степени от продажи компьютеров (на самом деле, быть может, расходные материалы необходимы для продажи компьютеров, но это уже анализ внутренних зависимостей).

Анализ динамики ( регрессионный анализ - выявление трендов ). Выявление тенденций, сезонных колебаний. Наглядно динамику отображает график типа "Линия". Например, объемы продаж продуктов компании Intel в течение года падали, а объемы продаж Microsoft росли. Возможно, улучшилось благосостояние среднего покупателя, или изменился имидж магазина, а с ним и состав покупателей. Требуется провести корректировку ассортимента. Другой пример: в течение 3 лет зимой снижается объем продаж видеокамер.

Анализ зависимостей (корреляционный анализ). Сравнение объемов продаж разных товаров во времени для выявления необходимого ассортимента - "корзины". Для этого также удобно использовать график типа "Линия". Например, при удалении из ассортимента принтеров в течение первых двух месяцев обнаружилось падение продаж картриджей с порошком.

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

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

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

Структура OLAP системы

В основе работы OLAP системы лежит обработка многомерных массивов данных. Многомерные массивы устроены так, что каждый элемент массива имеет множество связей с другими элементами. Чтобы сформировать многомерный массив, OLAP система должна получить исходные данные из других систем (например, ERP или CRM системы), или через внешний ввод. Пользователь OLAP системы получает необходимые данные в структурированном виде в соответствии со своим запросом. Исходя из указанного порядка действий, можно представить структуру OLAP системы.

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

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

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

Существует три основных способа хранения и обработки данных:

• локально . Данные размещаются на компьютерах пользователей. Обработка, анализ и управление данными выполняется на локальных рабочих местах. Такая структура OLAP системы имеет существенные недостатки, связанные со скоростью обработки данных, защищенностью данных и ограниченным применением многомерного анализа.
• реляционные базы данных . Эти базы данных используются при совместной работе OLAP системы с CRM системой или ERP системой . Данные хранятся на сервере этих систем в виде реляционных баз данных или хранилищ данных. OLAP сервер обращается к этим базам данных для формирования необходимых многомерных структур и проведения анализа.
• многомерные базы данных . В этом случае данные организованы в виде специального хранилища данных на выделенном сервере. Все операции с данными осуществляются на этом сервере, который преобразует исходные данные в многомерные структуры. Такие структуры называют OLAP кубом. Источниками данных для формирования OLAP куба являются реляционные базы данных и/или клиентские файлы. Сервер данных осуществляет предварительную подготовку и обработку данных. OLAP сервер работает с OLAP кубом не имея непосредственного доступа к источникам данных (реляционным базам данных, клиентским файлам и др.).

Виды OLAP систем

В зависимости от метода хранения и обработки данных все OLAP системы могут быть разделены на три основных вида.

1. ROLAP (Relational OLAP – реляционные OLAP системы) – этот вид OLAP системы работает с реляционными базами данных. Обращение к данным осуществляется напрямую в реляционную базу данных. Данные хранятся в виде реляционных таблиц. Пользователи имеют возможность осуществлять многомерный анализ как в традиционных OLAP системах. Это достигается за счет применения инструментов SQL и специальных запросов.

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

К недостаткам ROLAP относится низкая производительность (по сравнению с традиционными OLAP системами), т.к. обработку данных осуществляет сервер OLAP. Другим недостатком является ограничение функциональности из-за применения SQL.

2. MOLAP (Multidimensional OLAP – многомерные OLAP системы). Этот вид OLAP систем относится к традиционным системам. Отличие традиционной OLAP системы, от других систем, заключается в предварительной подготовке и оптимизации данных. Эти системы, как правило, используют выделенный сервер, на котором осуществляется предварительная обработка данных. Данные формируются в многомерные массивы – OLAP кубы.

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

К недостаткам MOLAP системы относится ограничение объемов обрабатываемых данных и избыточность данных, т.к. для формирования многомерных кубов, по различным аспектам, данные приходится дублировать.

3. HOLAP (Hybrid OLAP – гибридные OLAP системы). Гибридные OLAP системы представляют собой объединение систем ROLAP и MOLAP. В гибридных системах постарались объединить преимущества двух систем: использование многомерных баз данных и управление реляционными базами данных. HOLAP системы позволяют хранить большое количество данных в реляционных таблицах, а обрабатываемые данные размещаются в предварительно построенных многомерных OLAP кубах. Преимущества этого вида систем заключаются в масштабируемости данных, быстрой обработке данных и гибком доступе к источникам данных.

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

К таким видам относятся:

• WOLAP (Web OLAP). Вид OLAP системы с поддержкой web интерфейса. В этих системах OLAP есть возможность обращаться к базам данных через web интерфейс.
• DOLAP (Desktop OLAP). Этот вид OLAP системы дает возможность пользователям загрузить на локальное рабочее место базу данных и работать с ней локально.
• MobileOLAP . Это функция OLAP систем, которая позволяет работать с базой данных удаленно, с использованием мобильных устройств.
• SOLAP (Spatial OLAP). Этот вид OLAP систем предназначен для обработки пространственных данных. Он появился как результат интеграции географических информационных систем и OLAP системы. Эти системы позволяют обрабатывать данные не только в буквенно-цифровом формате, но и в виде визуальных объектов и векторов.

Преимущества OLAP системы

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

Основными преимуществами OLAP системы являются:

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

Основные характеристики хранилищ данных.

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

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

• многомерное представление данных ;
• поддержка сложных расчетов;
• правильный учет фактора времени.

Преимущества OLAP :

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

OLAP и OLTP. Характеристики и основные отличия

Правила Кодда для OLAP систем

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

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

Введение

В наше время без систем управления базами данных не обходится практически ни одна организация, особенно среди тех, которые традиционно ориентированы на взаимодействие с клиентами. Банки, страховые компании, авиа- и прочие транспортные компании, сети супермаркетов, телекоммуникационные и маркетинговые фирмы, организации, занятые в сфере услуг и другие - все они собирают и хранят в своих базах гигабайты данных о клиентах, продуктах и сервисах. Ценность подобных сведений несомненна. Такие базы данных называют операционными или транзакционными, поскольку они характеризуются огромным количеством небольших транзакций, или операций записи-чтения. Компьютерные системы, осуществляющие учет операций и собственно доступ к базам транзакций, принято называть системами оперативной обработки транзакций (OLTP - On-Line Transactional Processing) или учетными системами.

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

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

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

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

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

Именно это и обусловило интерес к системам поддержки принятия решений, ставших основной сферой применения OLAP (On-Line Analytical Processing, оперативная аналитическая обработка, оперативный анализ данных), превращающей “руду” OLTP-систем в готовое “изделие”, которое руководители и аналитики могут непосредственно использовать. Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть в суть" накопленных данных за счет быстрого и согласованного доступа к широкому спектру представлений информации.

Целью курсовой работы является рассмотрение технологии OLAP.

многомерный аналитический обработка данный

Основная часть

1 Основные сведения об OLAP

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

В большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД. Вообще говоря, это неверно, поскольку сам Кодд отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP". Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что не совсем корректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP. По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение.

Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим.

Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP .

1.2 Требования к средствам оперативной аналитической обработки

Многомерное концептуальное представление данных (Multi Dimensional Conceptual View). Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice"), вращения (rotate) и размещения (pivot) направлений консолидации. Прозрачность (Transparency). Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.

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

Устойчиваяпроизводительность(Consistent Reporting Performance). С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.

Клиент - серверная архитектура (Client-Server Architecture). Большая часть данных, требующих оперативной аналитической обработки, хранится в мэйнфреймовых системах, а извлекается с персональных компьютеров. Поэтому одним из требований является способность продуктов OLAP работать в среде клиент-сервер. Главной идеей здесь является то, что серверный компонент инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности.

Равноправие измерений (Generic Dimensionality). Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.

Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling). Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных.

Поддержка многопользовательского режима (Multi-User Support). Зачастую несколько аналитиков имеют необходимость работать одновременно с одной аналитической моделью или создавать различные модели на основе одних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных.

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

Интуитивное манипулирование данными (Intuitive Data Manipulation). Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе .

Гибкий механизм генерации отчетов (Flexible Reporting). Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации.

Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels). Настоятельно рекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели.

2 Компоненты OLAP-систем

2.1 Сервер. Клиент. Интернет

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

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

Сервер. Прикладной частью OLAP-системы является OLAP-сервер. Эта составляющая выполняет всю работу (в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечивается активный доступ. Архитектурой сервера управляют различные концепции. В частности, основной функциональной характеристикой OLAP-продукта является использование для хранения данных многомерной (ММБД, MDDB) либо реляционной (РДБ, RDB) базы данных. Агрегированные/Предварительно агрегированные данные

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

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

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

Несмотря на то, что сервер - это как бы "хребет" OLAP-решения, клиент не менее важен. Сервер может обеспечить прочный фундамент для облегчения манипуляций с данными, но если клиент сложен или малофункционален, пользователь не сможет воспользоваться всеми преимуществами мощного сервера. Клиент настолько важен, что множество поставщиков сосредотачивают свои усилия исключительно на разработке клиента. Все, что включается в состав этих приложений, представляет собой стандартный взгляд на интерфейс, заранее определенные функции и структуру, а также быстрые решения для более или менее стандартных ситуаций. Например, популярны финансовые пакеты. Заранее созданные финансовые приложения позволят специалистам использовать привычные финансовые инструменты без необходимости проектировать структуру базы данных или общепринятые формы и отчеты. Инструмент запросов/Генератор отчетов. Инструмент запросов или генератор отчетов предлагает простой доступ к OLAP-данным. Они имеют простой в использовании графический интерфейс и позволяют пользователям создавать отчеты перемещением объектов в отчет методом "drag and drop". Тогда как традиционный генератор отчетов предоставляет пользователю возможность быстро выпускать форматированные отчеты, генераторы отчетов, поддерживающие OLAP, формируют актуальные отчеты. Конечный продукт представляет собой отчет, имеющий возможности углубления в данные до уровня подробностей, вращения (пивотинг) отчетов, поддержки иерархий и др.. Add-Ins (дополнения) электронных таблиц.

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

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

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

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

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

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

2.2 OLAP - клиенты

OLAP-клиенты со встроенной OLAP-машиной устанавливаются на ПК пользователей. Они не требуют сервера для вычислений, и им присуще нулевое администрирование. Такие клиенты позволяют пользователю настроиться на существующие у него базы данных; как правило, при этом создается словарь, скрывающий физическую структуру данных за ее предметным описанием, понятным специалисту. После этого OLAP-клиент выполняет произвольные запросы и результаты их отображает в OLAP-таблице. В этой таблице, в свою очередь, пользователь может манипулировать данными и получать на экране или на бумаге сотни различных отчетов. OLAP-клиенты, предназначенные для работы с РСУБД, позволяют анализировать уже имеющиеся в корпорации данные, например хранящиеся в БД OLTP . Однако вторым их назначением может быть быстрое и дешевое создание хранилищ или витрин данных - в этом случае программистам организации нужно лишь создать совокупности таблиц типа "звезда" в реляционных БД и процедуры загрузки данных. Наиболее трудоемкая часть работы - написание интерфейсов с многочисленными вариантами пользовательских запросов и отчетов - реализуется в OLAP-клиенте буквально за несколько часов. Конечному же пользователю для освоения такой программы требуется порядка 30 минут. OLAP-клиенты поставляются самими разработчиками баз данных, как многомерных, так и реляционных. Это SAS Corporate Reporter, являющийся почти эталонным по удобству и красоте продуктом, Oracle Discoverer, комплекс программ MS Pivot Services и Pivot Table и др. Многие программы, предназначенные для работы с MS OLAP Services, поставляются в рамках кампании "OLAP в массы", которую проводит корпорация Microsoft. Как правило, они являются улучшенными вариантами Pivot Table и рассчитаны на использование в MS Office или Web-браузере. Это продукты фирм Matryx, Knosys и т. д., благодаря простоте, дешевизне и эффективности приобретшие огромную популярность на Западе.

3 Классификация продуктов OLAP

3.1 Многомерный OLAP

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

1. Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software, Oracle Express Server компании Oracle) относились к классу MOLAP, то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.

2. Системы оперативной аналитической обработки реляционных данных (ROLAP) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. К этому классу относятся DSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. Программный комплекс ИнфоВизор, разработанный в России, в Ивановском государственном энергетическом университете, также является системой этого класса. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам MOLAP, они требуют значительных затрат на обслуживание специалистами по информационным технологиям и предусматривают многопользовательский режим работы.

3. Наконец, гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.

Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP или интегрированные с внешними средствами, выполняющими такие функции. Эти хорошо развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Основными представителями этого класса являются BusinessObjects одноименной компании, BrioQuery компании Brio Technology и PowerPlay компании Cognos. Обзор некоторых продуктов OLAP приведен в приложении.

В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

1) гиперкубов (все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений) или

2) поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

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

С другой стороны, имеются существенные ограничения.

1. Многомерные СУБД не позволяют работать с большими базами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных.

2. Многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память. В подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удаётся удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные в максимально большие непрерывные группы. Но даже в этом случае проблема решается только частично. Кроме того, оптимальный с точки зрения хранения разреженных данных порядок сортировки скорее всего не будет совпадать с порядком, который чаще всего используется в запросах. Поэтому в реальных системах приходится искать компромисс между быстродействием и избыточностью дискового пространства, занятого базой данных.

Следовательно, использование многомерных СУБД оправдано только при следующих условиях.

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

2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).

3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

Непосредственное использование реляционных БД в системах оперативной аналитической обработки имеет следующие достоинства.

1. В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.

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

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

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

Описанию схемы звезды (star schema) и рекомендациям по ее применению полностью посвящены работы. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (Приложение А). Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению.

В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды - схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema). В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (Приложение Б). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.

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

Частично решают эту проблему расширения языка SQL (операторы GROUP BY CUBE", "GROUP BY ROLLUP" и "GROUP BY GROUPING SETS"); кроме того, предлагается механизм поиска компромисса между избыточностью и быстродействием, рекомендуя создавать таблицы фактов не для всех возможных сочетаний измерений, а только для тех, значения ячеек которых не могут быть получены с помощью последующей агрегации более полных таблиц фактов (Приложение В).

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

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

Заключение

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

Это следующие вопросы:

Откуда поступают данные? – Данные, подлежащие анализу, могут находиться в различных местах. Возможно, что база данных OLAP будет получать их из корпоративного Хранилища данных или из OLTP-системы. Если OLAP-продукт уже имеет возможность получить доступ к какому-то источнику данных, процессы категоризации и очистки данных сокращаются.

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

Каков общий объем данных? - Это наиболее важный фактор при определении базы данных OLAP. Реляционные OLAP-продукты способны оперировать большими объемами данных лучше, чем многомерные. Если объем данных не требует использования реляционной базы, многомерный продукт может использоваться с не меньшим успехом.

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

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

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

Глоссарий

1 Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.

2 Дейт К. Введение в системы баз данных. – М.: Hаука, 2005 г. – 246 с.

3 Елманова Н.В., Федоров А.А. Введение в OLAP-технологии Microsoft. – М.:Диалог-МИФИ, 2004. – 312 с.

4 Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2006. – 304 с.

5 Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных // СУБД. - 2005. - № 5-6. - 47-51 с.

6 Кречетов Н., Иванов П. Продукты для интеллектуального анализа данных ComputerWeek-Москва. - 2003. - № 14-15. - 32-39 с.

7 Пржиялковский В. В. Сложный анализ данных большого объема: новые перспективы компьютеризации // СУБД. - 2006. - № 4. - 71-83 с.

8 Сахаров А. А. Концепция построения и реализации информационных систем, ориентированных на анализ данных // СУБД. - 2004. - № 4. - 55-70 с.

9 Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 2003. – 312 c.

10 Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 2007. – 294 с.

Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных // СУБД. - 2005. - № 5-6. - 47-51 с.

Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 2003. – 312 c.

Барсегян А.А., Куприянов М.С. Технологии анализа данных: DataMining, VisualMining, TextMining, Olap. – СПб.: BHV-Петербург, 2007. – 532 с.

Елманова Н.В., Федоров А.А. Введение в OLAP-технологии Microsoft. – М.:Диалог-МИФИ, 2004. – 312 с.

Дейт К. Введение в системы баз данных. – М.: Hаука, 2005 г. – 246 с.

Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352с.

Сахаров А. А. Концепция построения и реализации информационных систем, ориентированных на анализ данных // СУБД. - 2004. - № 4. - 55-70 с.

Пржиялковский В. В. Сложный анализ данных большого объема: новые перспективы компьютеризации // СУБД. - 2006. - № 4. - 71-83 с.