5.2.3.3.Агрегация данных

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

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

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

5.2.4.Архитектуры olap

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

Таблица 10. Варианты архитектур OLAP

	Хранение многомерных данных
Обработка многомерных данных	Реляционная СУБД	Многомерная СУБД	Файл
SQL	1 - Cartesis Magnitude - MicroStrategy
Многомерный серверный процессор	2 - Crystal Holos (ROLAP mode) - IBM DB2 OLAP Server - CA EUREKA:Strategy - Longview Khalix - Informix MetaCube - Speedware Media/MR - Microsoft Analysis Services - Oracle Express (ROLAP mode) - Pilot Analysis Server - Sagent - Applix iTM1 - WhiteLight	4 - SAS CFO Vision - Crystal Holos - Comshare Decision - Hyperion Essbase - Oracle Express - Gentia - Speedware Media/M - Microsoft Analysis Services - PowerPlay Enterprise Server - Pilot Analysis Server - Applix iTM1
Многомерный клиентский процессор	3 - Oracle Discoverer - Informix MetaCube	5 - Comshare FDC - Dimensional Insight - Hyperion Enterprise - Hyperion Pillar - PwC CLIME	6 - Brio.Enterprise - BusinessObjects - Cognos PowerPlay - Personal Express - iTM1 Perspectives

Другой часто используемой классификацией архитектур OLAP является их подразделение на: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP), HOLAP (Hybrid OLAP), и DOLAP (Desktop OLAP). Эта классификация соотносится с описанной выше следующим образом:

ROLAP – квадраты 1, 2, 3 .

MOLAP – квадраты 4, 5 .

Desktop OLAP – квадрат 6 .

Hybrid OLAP – продукты, названия которых в таблице выделены курсивом.

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