Інтеграція 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>

*

*