Інтеграція Oracle 9i OLAP Option і BusinessObjects

У статті розглядаються можливі способи інтеграції сервера багатовимірних баз даних 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 ми отримуємо наступні переваги:



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


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


Опис прикладу


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



Вимірювання «Час» зберігається в таблиці 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) 
Складність настройки Юніверс (адміністратор) Простіше Складніше
Складність створення звітів (користувач) Складніше Простіше
Можливість використовувати вимірювання з кількома атрибутами і окремі таблиці вимірів Ні Так
Можливість використовувати операцію згортки / деталізація в звітах Ні Так

З наведеної таблиці видно, що витрати на створення Юніверс за другим способом з лишком окупаються перевагами, одержуваними при створенні звітів.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*