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

Введение 

Начиная с версии 9i в состав СУБД Oracle входит опция Oracle OLAP Option, представляющая собой сервер многомерных баз данных (OLAP сервер). OLAP Option позволяет создавать как многомерные (MOLAP), так и реляционные (ROLAP) базы для хранения многомерных данных. В OLAP Option существует два набора функций для работы с ROLAP базами: CWM1 (CWMLITE) и CWM2. CWM2 предоставляет наиболее полный набор OLAP возможностей, включая функции прогнозирования. Сравнение возможностей CWM1 и CWM2 приведено в [1], в этой статье мы будем рассматривать CWM2. 

OLAP Option позволяет хранить многомерные данные, однако для их обработки нужен специализированный OLAP клиент. В настоящее время Oracle предлагает набор компонент BI Beans для разработки пользовательских приложений в среде JDeveloper, способных работать с данными, хранимыми в OLAP Option. Однако не всегда есть возможность и время для разработки собственного аналитического приложения, в этом случае целесообразно использовать существующее приложение для доступа к данным и создания нерегламентной отчетности. Одним из лучших инструментов в этом классе является BusinessObjects (BO) компании Business Objects. Многие организации уже используют BusinessObjects для создания отчетов на обычных реляционных базах Oracle, в этом случае использование новой опции Oracle OLAP Option позволит повысить производительность работы аналитических приложений.

При использовании BO с OLAP Option мы получаем следующие преимущества: 

• возможность использования богатых возможностей BO для создания отчетов;

• возможность использования функций OLAP Option (отношение роста, прогнозирования и т.д.);

• возможность повышения производительности аналитического приложения за счет использования заранее рассчитанных средствами OLAP Option агрегатов для кубов данных;

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

Для создания аналитического приложения в среде BusinessObjects, работающего с CWM2 данными OLAP Option, необходимо на первом этапе в среде OLAP Option выполнить следующие операции: спроектировать модель данных; загрузить данные в таблицы; рассчитать агрегированные значения и при необходимости добавить вычисляемые объекты. При расчете агрегатов OLAP Option создает материализованное представление, содержащие все данные куба: как нижний уровень, так и агрегаты для всех вышестоящих уровней. Для приложения BusinessObjects именно это материализованное представление является источником данных. На втором шаге необходимо описать в юниверсе (universe) BO это материализованное представление, таблицы, содержащие элементы измерений, и создать объекты семантического слоя (измерения и показатели).

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

Описание примера 

В качестве примера будем использовать простую схему типа «звезда», состоящую из двух измерений («Время», «Продукты») и четырех показателей («Кол-во продаж», «Сумма продаж», «Цена», «Унифицированные единицы продаж»). Измерение «Продукты» хранится в таблице PRODUCT и имеет следующую структуру (уровни и атрибуты): 

• Все продукты

  • Идентификатор (ALL_PRODUCT_ID)

  • Название (ALL_PRODUCT_LON)

• Группа продуктов

  • Идентификатор (GROUP_PRODUCT_ID)

  • Название (GROUP_PRODUCT_LON)

• Продукт

  • Идентификатор (PRODUCT_CODE)

  • Название (PRODUCT_LON)

Измерение «Время» хранится в таблице TIME_VIEW и состоит из четырех уровней «Год», «Квартал», «Месяц», «День», каждый из который имеет атрибуты «Идентификатор», «Название», «Дата окончания действия периода», «Длина периода».

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

Способ Business Objects 

Компания Business Objects предложила решить проблему доступа к агрегированным данных OLAP Option из BusinessObjects методом построения искусственных соединений (join) на каждый уровень измерения (справочника) через таблицу SYS.DUAL [2]. Метод создания юниверса заключается в следующем:

1. Создание справочника. На основе таблицы SYS.DUAL для каждого уровня иерархии измерения в юниверсе создается псевдоним (alias). Рассмотрим это на примере измерения «Продукты». Следуя описанному методу, создаем 3 псевдонима для таблицы SYS.DUAL: PRODUCT, PROD_GROUP, PROD_ALL (см. Рис. 1)

Рис. 1. Псевдонимы для каждого уровня измерения «Продукты» на основе таблицы SYS.DUAL (BusinessObjects)

2. Создание иерархии. Для описания иерархии необходимо создать связи между таблицами уровней измерения. Для этого в юниверсе создаются искусственные связи, например, по вырожденному условию 1=1. 

3. Создание связей между справочником и кубом данных. Таблица фактических данных OLAPCUBE наряду с данными по нижнему уровню измерения содержит агрегированные значения, рассчитанные средствами OLAP Option для верхних уровней. Для использования этих агрегатов необходимо в юниверсе создать дополнительные связи между таблицами уровней измерения (PROD_ALL, PROD_GROUP, PRODUCT) и таблицей фактов (OLAPCUBE) (Рис. 2).

Рис. 2. Создание связей между уровнями измерения и таблицей фактов (BusinessObjects)

Более подробно данный метод описан в [2]. Ограничением рассмотренного способа является необходимость реализации всех измерений как вырожденных. Т.е. хранение атрибутов измерений непосредственно в таблице фактов и использовании смысловых атрибутов (например, код продукта или название категории) в качестве идентификаторов элементов измерения. Другим недостатком является отсутствие возможности использования любимых конечными пользователями операций свертки/детализации данных (DrillUp/DrillDown) в отчетах BO, создаваемых на основе построенных по этому способу юниверсов. Для просмотра детальных данных (данных на другом уровне агрегации) пользователю необходимо добавить в отчет новые уровни измерений, т.е. создать новый запрос.

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

Новый способ создания юниверса BO 

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

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

При описании показателя его значение полагается равным результату выполнения функции @AggregateAware. 

Синтаксис функции @AggregateAware следующий:
@AggregateAware(sum(агр_таблица1),…sum(агр_таблица_n)), 

где агр_таблица1 - это таблица с наибольшим уровнем агрегирования, а таблица агр_таблица_n - с наименьшим.

Применение механизма «Aggregate Awareness» в юниверсах - это процесс, состоящий из следующих действий:

1. Создание псевдонимов (alias) для материализованного представления в количестве, равном количеству срезов, для которых были просчитаны агрегаты (количество срезов = LevelCount1 x LevelCount2 x … x LevelCountN, где LevelCountI - количество уровней в измерении I, для которых были просчитаны агрегаты; N - количество измерений в кубе).

2. Создание показателей.

3. Определение несовместимых объектов по всем таблицам фактов.

4. Определение необходимых контекстов.

Как и в предыдущем случае, рассмотрим предлагаемый способ создания юниверса на примере (Рис. 3).

Рис. 3. Создание юниверса на основе AggeregateAware

1. Создание псевдонимов для таблицы фактов. Для каждого среза данных создаем псевдоним таблицы фактов: OLAPCUBE используем для извлечения данных нижнего уровня «Продукт-День»; CUBE_SALES_PROD_TYPE_MONTH будем использовать для извлечения агрегированных значений по срезу «Группа продуктов-Месяц».

2. Описание связей таблиц измерений с таблицами фактов. Далее, необходимо описать связи (join) между таблицами измерений и фактов. Связь для таблицы фактов нижнего уровня (OLAPCUBE) строится стандартным способом. Связь для таблицы агрегатов CUBE_SALES_PROD_TYPE_MONTH рассмотрим подробнее. При описании связей с таблицей фактов, содержащей агрегаты, необходимо учитывать специфику построения материализованных представлений OLAP Option для таблицы фактов: при построении материализованного представления формируется сложный составной ключ, обеспечивающий доступ к агрегатам. Для корректного извлечения агрегатов необходимо осуществлять проверку нижних уровней на пустоту. То есть для агрегатов уровня «Группа продуктов» уровень «Продукт» должен быть пустым.

Подобные связи необходимо создать для всех измерений (в нашем примере еще для измерения «Время»).

3. Создание показателей.Следующий шаг заключается в определении показателей (Measure) с помощью функции @AggregateAware. Это определение появляется в поле Select в свойствах объекта, как показано ниже (Рис. 4).

Рис. 4. Определение показателя

4. Определение несовместимых объектов. Следующая фаза настройки механизма «Aggregate Awareness» - это определение несовместимых объектов для каждой таблицы в юниверсе. Установка несовместимых объектов, позволяет BusinessObjects определить, какими агрегатными таблицами пользоваться во время генерации SQL выражений. Относительно агрегатной таблицы, объект (уровень измерения) может быть совместимым или несовместимым. Правила для совместимости следующие:

• Если объект на том же уровне или выше уровня агрегирования таблицы фактов, то он совместим с этой таблицей.

• Если объект на более низком уровне агрегирования, чем таблица фактов (или если он не связан с таблицей), то он не совместим с этой таблицей.

Определение несовместимых объектов приводит к тому, что при операциях с элементами измерений на нижних уровнях строятся SQL запросы к таблице с детальными данными OLAPCUBE. А при операциях с элементами измерений на верхних уровнях - к таблице с агрегированными данными OLAPCUBE_PROD_TYPE_MONTH.

5. Определение контекстов. Заключительный шаг построения юниверса заключается в определении контекстов по обнаруженным циклам.

В результате выполненных действий мы получаем юниверс, который позволяет пользователю работать в среде BusinessObjects с многомерным кубом, созданным средствами Oracle OLAP Option. Предложенный нами способ имеет более сложную реализацию на этапе создания юниверса. В процессе создания юниверса участвует большое количество таблиц (количество используемых псевдонимов равняется количеству срезов, для которых были просчитаны агрегаты в OLAP Option). Однако, этот способ является более функциональным и удобным для пользователя. При движении пользователя по иерархиям измерений BusinessObjects автоматически, невидимо для пользователя, переключается между таблицами агрегатов, что позволяет пользователю свободно выполнять операции свертки/детализации (DrillUp/DrillDown) для получения данных на разных уровнях детализации. При этом в процессе работы с отчетом пользователь оперирует одним запросом по всем срезам данных. 

Заключение 

Начиная с версии 9i в состав СУБД Oracle входит опция OLAP Option, позволяющая хранить и обрабатывать многомерные данные. Для доступа к этим данным могут быть использованы либо специализированные аналитические приложения, разработанные с использованием Oracle BI Beans и JDeveloper, либо стандартные инструменты для создания аналитических отчетов и OLAP приложений.

В статье было рассмотрено два механизма интеграции инструмента BusinessObjects с OLAP Option. Первый механизм подробно описан в [2] и основан на использовании фиктивных таблиц (SYS.DUAL). Второй способ основан на механизме «Aggregate Awareness» BusinessObjects и подробно рассмотрен в этой статье.

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

• Подробнее о продуктах Business Objects
• Приобрести продукты Business Objects в электронном магазине ITShop.ru
• Курсы обучения по продуктам Business Objects
• Подробнее о продуктах Oracle
• Приобрести продукты Oracle в ITShop.ru
• Курсы обучения по продуктам компании Oracle
• Подписаться на рассылку СУБД Oracle "с нуля"
• Обратиться в "Интерфейс" за дополнительной информацией/по вопросу приобретения продуктов