Особенности реализации OLAP-систем

Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Теоретические основы OLAP-систем

1.1 Многомерная модель данных

1.2 Определение OLAP-систем

1.3 Концептуальное многомерное представление

1.3.1 Двенадцать правил Кодда

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

1.3.3 Тест FASMI

1.4 Архитектура OLAP-систем

1.4.1 MOLAP

1.4.2 ROLAP

1.4.3 HOLAP

Глава 2. Реализации OLAP-систем

2.1 Microsoft Analysis Services

2.1.1 История возникновения

2.1.2 Режимы хранения

2.1.3 Программные интерфейсы и объектные модели

2.1.4 Извлечение данных

2.1.5 Администрирование и управление

2.1.6 Языки запросов

2.2 Oracle Essbase

2.2.1 История

2.2.2 DB2 OLAP Server

2.2.3 Режимы хранения

2.2.4 Компоненты Oracle Essbase

2.3 Mondrian OLAP server

2.3.1 Архитектура сервера

Заключение

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

Приложение



Введение

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

Большой объем информации, с одной стороны, позволяет получить более точные расчеты и анализ, с другой - превращает поиск решений в сложную задачу. Неудивительно, что первичный анализ данных был переложен на компьютер. В результате появился целый класс программных систем, призванных облегчить работу людей, выполняющих анализ (аналитиков). Такие системы принято называть системами поддержки принятия решений - СППР (DSS, Decision Support System).

Таким образом, СППР - это системы, обладающие средствами ввода, хранения и анализа данных, относящихся к определенной предметной области, с целью поиска решений.

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

Архитектуру СППР можно разделить на следующие подсистемы.

Подсистема ввода данных. В таких подсистемах, называемых OLTP (Online transaction processing), выполняется операционная (транзакционная) обработка данных. Для реализации этих подсистем используют обычные системы управления базами данных (СУБД).

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

Подсистема анализа. Данная подсистема может быть построена на основе:

? Подсистемы информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка структурных запросов SQL (Structured Query Language);

? Подсистемы оперативного анализа. Для реализации таких подсистем применяется технология оперативной аналитической обработки данных OLAP (On-line analytical processing), использующая концепцию многомерного представления данных;

? Подсистемы интеллектуального анализа. Данная подсистема реализует методы и алгоритмы Data Mining ("добыча данных").

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



Глава 1. Теоретические основы OLAP-систем

1.1 Многомерная модель данных

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

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

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

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

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

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) - это множественная перспектива, состоящая из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ.

Каждое измерение может быть представлено в виде иерархической структуры.

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

Над таким гиперкубом могут выполняться следующие операции.

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

Вращение (Rotate) - изменение расположения измерений, представленных в отчете или на отображаемой странице. Например, операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид. Кроме того, вращением куба данных является перемещение внетабличных измерений на место измерений, представленных на отображаемой странице, и наоборот. Консолидация (Drill Up) и детализация (Drill Down) - операции, которые определяют переход вверх по направлению от детального (down) представления данных к агрегированному (up) и наоборот, соответственно. Направление детализации (обобщения) может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями.



1.2 Определение OLAP-систем

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing).

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

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

1.3 Концептуальное многомерное представление

1.3.1 Двенадцать правил Кодда

Далее перечислены 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 измерений. Более того, каждое из общих измерений не должно быть ограничено по числу определяемых пользователем-аналитиком уровней агрегации и путей консолидации.

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

Набор правил Кодда, послуживших де-факто определением OLAP, достаточно часто вызывает различные нарекания, например, правила 1, 2, 3, 6 являются требованиями, а правила 10, 11 - неформализованными пожеланиями. Таким образом, перечисленные 12 правил Кодда не позволяют точно определить OLAP.

В 1995 году Эдгар Кодд к приведенному перечню добавил следующие шесть правил:

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

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

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

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

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

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

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

1.3.3 Тест FASMI

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

FAST (Быстрый). OLAP-система должна обеспечивать выдачу большинства ответов пользователям в пределах приблизительно 5 секунд. При этом самые простые запросы обрабатываются в течение 1 секунды, и очень немногие - более 20 секунд.

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

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

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

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

1.4 Архитектура OLAP-систем

OLAP-система включает в себя два основных компонента.

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

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

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

MOLAP - многомерный (multivariate) OLAP. Для реализации многомерной модели используют многомерные БД;

ROLAP - реляционный (relational) OLAP. Для реализации многомерной модели используют реляционные БД,

HOLAP - гибридный (hybrid) OLAP. Для реализации многомерной модели используют и многомерные, и реляционные БД.

Часто в литературе по OLAP-системам можно встретить аббревиатуры DOLAP и JOLAP:

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

JOLAP - новая, основанная на Java коллективная OLAP-API-инициатива, предназначенная для создания и управления данными и метаданными на серверах OLAP. Основной разработчик - Hyperion Solutions. Другими членами группы, определяющей предложенный API, являются компании IBM, Oracle и др.



1.4.1 MOLAP

MOLAP-серверы используют для хранения и управления данными многомерных БД. При этом данные хранятся в виде упорядоченных многомерных массивов. Такие массивы подразделяются на гиперкубы и поликубы.

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

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

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

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

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

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

С другой стороны, имеются также существенные недостатки многомерных БД.

За счет денормализации и предварительно выполненной агрегации объем данных в многомерной БД, как правило, соответствует (по оценке Кодда) в 2,5-100 раз меньшему объему исходных детализированных данных.

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

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

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

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

Набор информационных измерений стабилен.

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

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



1.4.2 ROLAP

ROLAP-серверы используют реляционные БД. По словам Кодда, "реляционные БД были, есть и будут наиболее подходящей технологией для хранения данных. Необходимость существует не в новой технологии БД, а скорее в средствах анализа, дополняющих функции существующих СУБД, и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP".

В настоящее время распространены две основные схемы реализации многомерного представления данных с помощью реляционных таблиц: схема "звезда" и схема "снежинка.

Основными составляющими схемы "звезда" (Star Schema) являются денормализованная таблица фактов (Fact Table) и множество таблиц измерений (Dimension Tables).

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

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

Факты, связанные с "моментальными снимками" (Snapshot facts). Они основаны на состоянии объекта (например, банковского счета) в определенные моменты времени (например, на конец дня или месяца). Типичными примерами таких фактов является объем продаж за день или дневная выручка;

Факты, связанные с элементами документа (Line-item facts). Они основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, о количестве, цене, проценте скидки);

Факты, связанные с событиями или состоянием объекта (Event or state facts). Они представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

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

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

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

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

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

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

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

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

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

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

1.4.3 HOLAP

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



Глава 2. Реализации OLAP-систем

2.1 Microsoft Analysis Services

Microsoft Analysis Services (Службы анализа от Microsoft) - часть Microsoft SQL Server, системы управления базами данных (СУБД). Microsoft включила набор служб в SQL Server, связанных с бизнес-анализом и хранением данных. Эти службы включают в себя службы интеграции (Integration Services) и службы анализа (Analysis Services). Analysis Services, в свою очередь, включают в себя набор средств для работы с OLAP и интеллектуальным анализом данных.

2.1.1 История возникновения

В 1996 году Microsoft начала свою экспансию на новый для неё рынок OLAP-серверов путем приобретения программной технологии OLAP у израильской компании Panorama Software. Спустя два года, в 1998 году Microsoft выпускает OLAP Services как часть SQL Server 7. OLAP Services поддерживают архитектуры MOLAP, ROLAP и HOLAP, и использует OLEDB для OLAP как программный интерфейс (API) клиентского доступа, а MDX в качестве языка запросов. Присутствовала возможность работы в режиме клиент-сервера или в режиме "оффлайн" с локальными файлами-кубами.

В 2000 году Microsoft выпускает Analysis Services 2000. Переименование OLAP Services произошло вследствие расширения понятия "Интеллектуальный анализ данных" (Data Mining), и, соответственно, спектр продуктов уже включал в себя не только OLAP. Analysis Services 2000 позиционировались как эволюционный выпуск, так как они были построены на той же архитектуре, что и OLAP Services и за счет этого были обратно совместимы с ними. Среди главных улучшений присутствовала большая гибкость в проектировании размерности за счет поддержки наследственной размерности, смены размерности, и виртуальной размерности. Другой главной областью исправлений стал значительно улучшенный движок вычислений с поддержкой унарных операторов, пользовательских формул свертки (custom rollups) и многомерных выражений (cell calculations). Также новыми возможностями стали защита размерности, счет без повторов (distinct count), взаимодействие по HTTP, сессионные кубы, уровни группировки и др.

В 2005 году Microsoft выпустила следующее поколение OLAP и технологии Data Mining в виде Analysis Services 2005. Оно поддерживал обратную совместимость на уровне API: несмотря на то, что приложения, написанные с применением OLE DB for OLAP и MDX, продолжали успешно работать, архитектура продукта стала совершенно иной. Главным нововведением в модели стало сведение к концепции унифицированной модели измерений UDM (Unified Dimensional Model).

2.1.2 Режимы хранения

Microsoft Analysis Services занимает нейтральную позицию в споре MOLAP против ROLAP, разгорающемся вокруг OLAP-продуктов. Благодаря этому можно использовать все виды MOLAP, ROLAP и HOLAP внутри одной модели.

2.1.3 Программные интерфейсы и объектные модели

Microsoft Analysis Services поддерживает различные наборы программных интерфейсов (API) и объектных моделей для различных операций в различных программных средах.

2.1.4 Извлечение данных

XML for Analysis - API нижайшего уровня. Может быть использован на любой платформе и с любым языком программирования, поддерживающим HTTP и XML.

OLE DB for OLAP - Расширение OLEDB. Основан на COM и предназначен для использования в Си/C++-программах на Windows-платформе.

ADOMD - Расширение ADO. Основан на COM Automation и предназначен для VB-программ на Windows-платформе.

ADOMD.NET - Расширение ADO.NET. Основан на .NET-технологии и предназначен для программ, написанных с использованием управляемого кода на CLR-платформах.

2.1.5 Администрирование и управление

DSO - Для AS 2000. Основан на COM Automation и предназначен для VB-программ на Windows-платформе.

AMO - Для AS 2005. Основан на .NET-технологии и предназначен для программ, написанных с использованием управляемого кода на CLR-платформах.

2.1.6 Языки запросов

Microsoft Analysis Services поддерживает следующие языки запросов:

DDL (Data Definition Language) язык определения данных в Analysis Services основан на XML и поддерживает такие команды как <Create>, <Alter>, <Delete>, <Process> и т.д. Для моделей импорта и экспорта интеллектуального анализа данных также поддерживается PMML.

Data Manipulation Language (DML):

· MDX - для запроса OLAP-кубов

· DAX - для табулярного запроса OLAP-кубов (Data Analysis eXpressions, PowerPivot)

· SQL - ограниченное подмножество SQL-инструкций для запроса OLAP-кубов и обработки размерности как таблиц

· DMX - для запроса моделей интеллектуального анализа данных



2.2 Oracle Essbase

Essbase - многомерная система управления базами данных. Наименование сформировано как акроним от англ. extended spreadsheet database - расширенная электронно-табличная база данных.

Oracle Essbase - это OLAP сервер, отличающийся от конкурентов мощной поддержкой аналитических задач, позволяя производить многомерный анализ в разрезе множества аналитик, строить прогнозы развития компания, подготовить данные для отчетности. Он поддерживает весь спектр OLAP решений - MOLAP(двух видов Aggregate Storage и Block Storage), ROLAP и HOLAP (MOLAP+ROLAP).

Кроме сервера многомерных баз данных поставляется с набором визуальных средств проектирования, администрирования и формирования запросов, поддерживает языки запросов MDX, MaxL, SQL. В разное время правами на продукт владели компании Arbor, Hyperion, Oracle, в период с 1998 по 2005 год по каналам корпорации IBM продукт продавался под наименованием DB2 OLAP Server как часть линейки DB2.

2.2.1 История

В 30 марта 1992 года компания Arbor Software запатентовала под наименованием Essbase метод и вычислительный аппарат хранения и получения многомерных данных на компьютере, в этом же году на основе патента создан клиент-серверный программный продукт, хранящий и обрабатывающий на серверной стороне базы данных и обеспечивающий доступ к этим данным из электронно-табличных программ Microsoft Excel и Lotus 1-2-3. Серверная часть в первой версии продукта работала только под операционной системой OS/2, в 1993 году была добавлена поддержка UNIX и Windows NT. Разработка кубов осуществлялась специализированной клиентской программой под наименованием Essbase Application Manager, работающей под управлением Windows 3.x, визуализация информации осуществлялась только двумя способами: через клиентскую программу формирования запросов Essbase query builder, и через Essbase spreadhseet client - специализированные плагины для Microsoft Excel и Lotus 1-2-3, также разработки Arbor.

В 1993 году продукт получил известность благодаря публикации Эдгара Кодда, в которой он ввёл понятие об OLAP и предложил 12 принципов аналитической обработки, и в качестве референтного продукта, удовлетворяющего предложенным принципам, указал Essbase. Примечательно, что впоследствии публикация была изъята из архивов Computerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor. При этом, исторически первой многомерной системой управления базами данных считается разработанная в 1970 году Express (позднее приобретённая корпорацией Oracle и преобразованное в OLAP-опцию для Oracle Database), а Essbase отмечен только как "первая коммерчески успешная OLAP-система".

В 1995 году Arbor заключила соглашение с Borland, IBM, Advanced Visual Systems и Applix на разработку дополнительных сторонних средств визуализации многомерной информации, хранимой на OLAP-сервере.

В 1997 году Essbase занял доминирующую долю рынка серверных средств аналитической обработки данных.

В 1998 году IBM и Arbor договорились о распространении продукта по каналам продаж корпорации IBM под наименованием DB2 OLAP Server, под этим названием, параллельно с основным, продукт продавался до 2005 года.

В 1998 году Arbor Software поглощена компанией Hyperion, и Essbase стал технологическим компонентом приложений для финансового планирования и анализа этой компании.

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

В 2007 году Hyperion поглощён корпорацией Oracle, вскоре Essbase был включён в линейку Hyperion Business Intelligence Techonlogy, поставляется как технологический компонент EPM, а также проведена интеграция с продуктами всей линейки Oracle Business Intelligence (сформированных, в основном, на базе аналитической платформы приобретённой компании Siebel). По состоянию на 2011 год цена на Essbase установлена в $2,9 тыс. за пользователя или $184 тыс. за процессорную единицу (которая исчисляется от количества процессорных ядер сервера, умноженного на коэффициент от ? до 1 в зависимости от процессорной архитектуры).

2.2.2 DB2 OLAP Server

DB2 OLAP Server - торговое наименование Essbase при поставках по каналам IBM в рамках расширения линейки DB2. Версия 1.0 DB2 OLAP Server вышла в феврале 1998 года, она соответствовала Essbase 5.0 и поддерживала хранение данных только в DB2 UDB и развёртывание на операционных системах OS/2, AIX и Windows NT; версия 1.0.1, вышедшая в октябре того же года поддерживалась также на серверах процессорной архитектуры SPARC под управлением Solaris и на архитектурах PA-RISC под управлением HP-UX. В сентябре 1999 года на базе версии Essbase 5.0.2 выпущена версия DB2 OLAP Server 1.1, в ней в дополнение к реляционному хранилищу поддержано блочное многомерное хранилище Essbase, с 2000 года эта версия поддержана на мейнфреймах под управлением OS/390 и на AS/400-серверах.

Также в 2000 году на основе Essbase версии 6.0 вышла новая версия DB2 OLAP Server, получившая номер 7.1. Некоторые средства Hyperion (в частности, Hyperion Analyzer), поставлялись дополнительно к DB2 OLAP Server с префиксом IBM DB2 OLAP.

2.2.3 Режимы хранения

Oracle Essbase поддерживает весь спектр OLAP решений - MOLAP(двух видов Aggregate Storage и Block Storage), ROLAP и HOLAP (MOLAP+ROLAP).

2.2.4 Компоненты Oracle Essbase

Essbase Analytics Module (Block Storage) - модуль Analytic Services создает базу данных в основе, которой лежит понятие блок - это таблица, состоящая из всех возможных вариантов плотных направлений, и эти блоки размещаются на пересечении разряженных направлений.

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

Предназначен для:

· Приложений, связанных с итеративным планированием, распределениями, сложным анализом (анализ продаж, анализ прибыльности)

· Если необходимо много процедурных вычислений и запись изменений на любой уровень агрегации

Управление порядком вычисления измерений

Вычисление всей или части БД

Выполнение сложных вычислений

Enterprise Analytics Module (ASO Aggregate Storage) - модуль Analytic Services создает "агрегированную" базу данных, в себе хранит элементы нулевого уровня, автоматически рассчитывая все значения более высокого уровня, по своей структуре чем-то напоминает ROLAP.

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

Предназначен для

· Для крупномасштабных, разреженных данных

· Стандартный набор правил агрегации

Административная консоль Analytic Administration Services - это интерфейс администратора базы данных Analytic Services, поддерживающий единую точку администрирования для множества серверов баз данных. Используя этот инструмент, Вы можете разрабатывать, обслуживать и управлять как серверами, так и приложениями и их базами данных.

Интеграционная консоль - Essbase Integration Studio (не развивается, предшественик Essbase Integration Studio )

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

Essbase SpreadSheat Add-in for Excel - Это программное решение предназначено для получения AD-HOC отчетов в Microsoft Excel, оно непосредственно подключается к многомерной базе данных. Развитие остановлено.

Smart View for Office позволяет получить доступ к данным из всего пакета программ Microsoft Office, отличается от Essbase SpreadSheet технологическим решением. Усиленно развивается.

EssCMD - интерфейс командный строки, предназначен для проведения административных задач, таких как остановка приложения, запуск сервисных утилит, резервное копирование и др.

MaxL DDL - Интерфейс командный строки, для проведения административных задач.

Essbase API - это инструмент разработчика программного обеспечения, позволяет обращать к многомерной базе данных из VB, C, или JAVA.

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

2.3 Mondrian OLAP server

Mondrian - сервер OLAP (аналитической обработки в реальном времени) с открытыми исходными кодами, написанный на языке Java. Разрабатывается и поддерживается корпорацией Pentaho.

Поддерживает язык запросов MDX, а также спецификации XML for Analysis и JOLAP (JSR-69). Для хранения данных может использовать любую систему управления базами данных с поддержкой SQL, поддерживаются другие источники данных, умеет кэшировать в памяти суммарные результаты.

С ноября 2005 года входит как программный компонент в BI-пакет Pentaho BI Suite, как компонент фигурирует под наименованием Pentaho Analysis Services Community Edition (бесплатная реализация с открытым кодом), также поставляется в рамках коммерческого продукта Pentaho Analysis Enterprise Edition.

2.3.1 Архитектура сервера

Сервер Mondrian состоит из трёх слоёв, выделяются слой измерений, звёздный слой и слой хранения.

Слой измерений (англ. dimensional layer) разбирает, проверяет и выполняет MDX-запросы. MDX-запрос в Mondrian выполняется в несколько этапов. Сначала вычисляются оси, затем значения ячеек на осях, для эффективности, слой измерений посылает запросы к ячейкам на уровень агрегирования партиями. Трансформатор запросов позволяет приложению управлять существующими запросами, вместо того чтобы строить MDX-выражения с нуля для каждого запроса. Метаданные описывают и собственно модель измерений, и то, как она отображается на реляционную модель.

Слой звезды (англ. star layer) отвечает за поддержание кэша агрегатов. Слой измерений посылает запросы для получения набора ячеек. Если требуемые ячейки не находятся в кэше, или получаются свёртыванием агрегатов в кэше, менеджер агрегатов посылает запрос на слой хранения.

Слой хранения (англ. storage layer) обеспечивает хранение исходных данных, необходимых для получения агрегатов. Принципиально, Mondrian поддерживает любые jdbc-источники данных. В частности, заявляется о коммерческой поддержке SQL-серверов DB2, Oracle Database, Microsoft SQL Server, MySQL, PostgreSQL, колоночных хранилищ Greenplum и Infobright, аппаратно-программных комплексов Teradata Database, Netezza, Neoview, а также возможен доступ к неструктурированным источникам, включая некоторые NoSQL-системы, в частности, поддерживаются MongoDB и Hadoop-источники - HDFS, HBase, Hive.



Заключение

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

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

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

Над многомерной моделью - гиперкубом - могут выполняться операции: среза, вращения, консолидации и детализации. Многомерную модель и эти операции реализуют OLAP-системы.

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

Для определения OLAP-систем Кодд разработал 12 правил, позднее дополнил к ним еще шесть и разбил 18 правил на четыре группы: основные особенности, специальные особенности, особенности представления отчетов и управление измерениями.

В 1995 г. Пендсон и Крит на основании правил Кодда разработали тест FASMI, определив OLAP как "Быстрый Анализ Разделяемой Многомерной Информации".

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

Во второй главе мы рассмотрели примеры практической реализации OLAP-систем. А именно Microsoft Analysis Services, Oracle Essbase и Mondrian OLAP server.



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

1. Барсегян А.А. Технология анализа данных: Data Mining, Visual Mining, Text Mining, OLAP. [Текст]: учебное пособие / А.А. Барсегян, М.С. Куприянов, В.В. Степаненко, И.И. Холод. - 2-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2007. - 384 с.

2. Елманова Н. Введение OLAP-технологии Microsoft [Текст]: учебное пособие / Н. Елманова, А. Федоров - М.: Диалог-МИФИ, 2002. - 272 с.



Приложение

Создание хранилища данных

В качестве инструментов для создания OLAP-куба мы будем использовать Microsoft Analysis Services из поставки Microsoft SQL Server 2000 SP4. Для начала нам нужно будет создать хранилище данных на основе оперативной базы. Воспользуемся базой данных Northwind входящей в качестве образца в Microsoft SQL Server 2000. Данная база данных имеет следующую структуру.

Назавем наше хранилище Northwind_Mart. В SQL Query Analyzer выполни SQL запрос:

CREATE DATABASE Northwind_Mart ON PRIMARY (NAME=Northwind_Mart_Data, FILENAME='D:\Northwind_Mart\Northwind_Mart_Data.MDF', SIZE=5MB, FILEGROWTH=10% ) LOG ON ( NAME=Northwind_Mart_Log, FILENAME='D:\Northwind_Mart\Northwind_Mart_Log.LDF', SIZE=2MB, FILEGROWTH=10% )

GO

USE Northwind_Mart

GO

CREATE TABLE [dbo].[Customer_Dim] ( [CustomerKey] [int] IDENTITY (1, 1) NOT NULL , [CustomerID] [nchar] (5) NOT NULL , [CompanyName] [nvarchar] (40) NOT NULL , [ContactName] [nvarchar] (30) NOT NULL , [ContactTitle] [nvarchar] (30) NOT NULL , [Address] [nvarchar] (60) NOT NULL , [City] [nvarchar] (15) NOT NULL , [Region] [nvarchar] (15) NOT NULL , [PostalCode] [nvarchar] (10) NULL , [Country] [nvarchar] (15) NOT NULL , [Phone] [nvarchar] (24) NOT NULL ,[Fax] [nvarchar] (24) NULL) ON [PRIMARY]

GO

CREATE TABLE [dbo].[Employee_Dim] ([EmployeeKey] [int] IDENTITY (1, 1) NOT NULL, [EmployeeID] [int] NOT NULL , [EmployeeName] [nvarchar] (30) NOT NULL , [HireDate] [datetime] NULL) ON [PRIMARY]

GO

CREATE TABLE [dbo].[Product_Dim] ([ProductKey] [int] IDENTITY (1, 1) NOT NULL , [ProductID] [int] NOT NULL , [ProductName] [nvarchar] (40) NOT NULL , [SupplierName] [nvarchar] (40) NOT NULL, [CategoryName] [nvarchar] (15) NOT NULL, [ListUnitPrice] [money] NOT NULL) ON [PRIMARY]

GO

CREATE TABLE [dbo].[Sales_Fact] ( [TimeKey] [int] NOT NULL , [CustomerKey] [int] NOT NULL , [ShipperKey] [int] NOT NULL , [ProductKey] [int] NOT NULL , [EmployeeKey] [int] NOT NULL , [RequiredDate] [datetime] NOT NULL , [LineItemFreight] [money] NOT NULL , [LineItemTotal] [money] NOT NULL , [LineItemQuantity] [smallint] NOT NULL , [LineItemDiscount] [money] NOT NULL ) ON [PRIMARY]

GO

CREATE TABLE [dbo].[Shipper_Dim] ( [ShipperKey] [int] IDENTITY (1, 1) NOT NULL ,

[ShipperID] [int] NOT NULL , [ShipperName] [nvarchar] (40) NOT NULL) ON [PRIMARY]

GO

CREATE TABLE [dbo].[Time_Dim] ( [TimeKey] [int] IDENTITY (1, 1) NOT NULL , [TheDate] [datetime] NOT NULL , [DayOfWeek] [nvarchar] (20) NOT NULL , [Month] [int] NOT NULL , [Year] [int] NOT NULL , [Quarter] [int] NOT NULL , [DayOfYear] [int] NOT NULL , [Holiday] [nvarchar] (1) NOT NULL , [Weekend] [nvarchar] (1) NOT NULL , [YearMonth] [nvarchar] (10) NOT NULL , [WeekOfYear] [int] NOT NULL ) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Customer_Dim] WITH NOCHECK ADD CONSTRAINT [PK_Customer_Dim] PRIMARY KEY NONCLUSTERED ([CustomerKey]) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Employee_Dim] WITH NOCHECK ADD CONSTRAINT [PK_Employee_Dim] PRIMARY KEY NONCLUSTERED ([EmployeeKey]) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Product_Dim] WITH NOCHECK ADD CONSTRAINT [PK_Product_Dim] PRIMARY KEY NONCLUSTERED

([ProductKey]) ON [PRIMARY] GO ALTER TABLE [dbo].[Sales_Fact] WITH NOCHECK ADD CONSTRAINT [PK_Sales_Fact] PRIMARY KEY NONCLUSTERED ( [TimeKey], [CustomerKey], [ShipperKey], [ProductKey], [EmployeeKey] ) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Shipper_Dim] WITH NOCHECK ADD CONSTRAINT [PK_Shipper_Dim] PRIMARY KEY NONCLUSTERED ([ShipperKey]) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Time_Dim] WITH NOCHECK ADD CONSTRAINT [PK_Time_Dim] PRIMARY KEY NONCLUSTERED ([TimeKey]) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Sales_Fact] ADD CONSTRAINT [FK_Sales_Fact_Customer_Dim] FOREIGN KEY ([CustomerKey]) REFERENCES [dbo].[Customer_Dim] ([CustomerKey]), CONSTRAINT [FK_Sales_Fact_Employee_Dim] FOREIGN KEY ([EmployeeKey]) REFERENCES [dbo].[Employee_Dim] ([EmployeeKey]), CONSTRAINT [FK_Sales_Fact_Product_Dim] FOREIGN KEY ([ProductKey]) REFERENCES [dbo].[Product_Dim] ([ProductKey]), CONSTRAINT [FK_Sales_Fact_Shipper_Dim] FOREIGN KEY ([ShipperKey]) REFERENCES [dbo].[Shipper_Dim] ([ShipperKey]), CONSTRAINT [FK_Sales_Fact_Time_Dim] FOREIGN KEY ([TimeKey]) REFERENCES [dbo].[Time_Dim] ([TimeKey])

...