(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Интеграция Oracle 9i OLAP Option и BusinessObjects

Источник: bilanit
Шовкун А.В.

В статье рассматриваются возможные способы интеграции сервера многомерных баз данных 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. 

Связываемые таблицы  Условие связи 
PROD_ALL, PROD_GROUP /* PROD_ALL.DUMMY=PROD_GROUP.DUMMY */ 1=1
PROD_GROUP, PRODUCT /* PROD_GROUP.DUMMY=PRODUCT.DUMMY */ 1=1

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

Связываемые таблицы  Условия связи 
PROD_ALL, OLAPCUBE /* PROD_ALL.DUMMY */ OLAPCUBE.GID=3
PROD_GROUP, OALPCUBE /* PROD_GROUP.DUMMY */ OLAPCUBE.GID=2
PRODUCT, OALPCUBE /* PRODUCT.DUMMY */ OLAPCUBE.GID=1

Рис. 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 для таблицы фактов: при построении материализованного представления формируется сложный составной ключ, обеспечивающий доступ к агрегатам. Для корректного извлечения агрегатов необходимо осуществлять проверку нижних уровней на пустоту. То есть для агрегатов уровня «Группа продуктов» уровень «Продукт» должен быть пустым.

Уровень измерения  Связываемые таблицы  Условие связи 
«Все продукты» PRODUCT, OLAPCUBE_PROT_TYPE_MONTH CUBE_SALES_PROD_TYPE_MONTH.ALL_PRODUCT _ID=PRODUCT.ALL_PRODUCT_ID AND CUBE_SALES_PROD_TYPE_MONTH.PRODUCT_ GROUP_IDIS NULLAND CUBE_SALES_PROD_TYPE_MONTH.PRODUCT_ CODE IS NULLAND PRODUCT.GROUP_PRODUCT_ID IS NULLAND PRODUCT.GROUP_PRODUCT_CODE IS NULL
«Группа продуктов» PRODUCT, OLAPCUBE_PROT_TYPE_MONTH CUBE_SALES_PROD_TYPE_MONTH.PRODUCT_ GROUP_ID= PRODUCT.GROUP_PRODUCT_IDAND PRODUCT.GROUP_PRODUCT_ID IS NULLAND PRODUCT.GROUP_PRODUCT_CODE IS NULL
«Продукт» PRODUCT, OLAPCUBE OLAPCUBE.PRODUCT_CODE= PRODUCT. PRODUCT_CODE

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

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

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

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

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

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

Таблица  Несовместимые объекты  Примечания 
OLAPCUBE отсутствуют Для таблицы OLAPCUBE все объекты являются совместимыми, так ее мы используем для извлечения данных по нижним уровням измерений.
OLAPCUBE_PROD_TYPE_MONTH «Продукт», «День» Эта таблица используется для извлечения данных, начиная с уровней «Продукт» и «День» и выше.

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

  Способ 1 (SYS.DUAL)  Способ 2 (Aggregate Awareness) 
Сложность настройки юниверса (администратор) Проще Сложнее
Сложность создания отчетов (пользователь) Сложнее Проще
Возможность использовать измерения с несколькими атрибутами и отдельные таблицы измерений  Нет Да
Возможность использовать операцию свертка/детализация в отчетах Нет Да

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

Ссылки по теме


 Распечатать »
 Правила публикации »
  Обсудить материал в конференции Oracle »
Обсудить материал в конференции SAP Business Objects »
Написать редактору 
 Рекомендовать » Дата публикации: 05.03.2008 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
SAP® Crystal Presentation Design 2016 WIN INTL NUL
SAP® Crystal Reports 2016 WIN INTL NUL
SAP® Crystal Dashboard Design Departmental 2016 WIN INTL NUL
SAP CRYSTAL Reports 2013 WIN INTL NUL
SAP Crystal Reports XI R2 Dev 2006 INTL WIN NUL License (Version 11)
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
CASE-технологии
СУБД Oracle "с нуля"
Новые материалы
Компьютерные книги. Рецензии и отзывы
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Парная нелинейная регрессия по параметрам (1)
Модуль «Парная нелинейная регрессия по параметрам». Вход: двумерный массив чисел; одномерный...
 
Как заказчики обманывают наивных художников и дизайнеров (9)
Ни один уважающий себя деловой человек не будет бесплатно раздавать свою работу и тратить время...
 
Разработка программ базы данных (43)
Написание прикладных компьютерных программ (базы данных) на заказ. Разработка корпоративных...
 
Вакансия: Java-программист уровня middle-senior на удаленку (1)
Всем добрый день! Я рекрутер компании GameShells, которая занимается разработкой мобильных...
 
Написание программ на заказ для компьютеров и контроллеров (2)
Программист (удаленный работник) оказывает (принимает заявки на разработку и написание программ...
 
 
 



    
rambler's top100 Rambler's Top100