Основні способи реалізації багатомірної моделі

В основі OLAPлежить ідеябагатомірної моделі даних, у якій на зміну таким поняттям як відношення й сутності приходять поняття вимірів і кубів даних.

З погляду аналізу кожний аналізований факт зручно розглядати як функцію від його характеристик. Наприклад, виробництво виробу є функція від матеріалів, верстатів, робітників, інженерів, технологів, керівників, можливо, ще якихось істотних параметрів. Параметри такого типу називаються вимірами.

По типі вхідної БД продукти OLAP діляться на наступні класи.

MOLAP (Multidimensional OLAP) – для реалізації багатомірної моделі використовуються багатомірні БД. При цьому дані зберігаються у вигляді впорядкованих багатомірних масивів. Такі масиви підрозділяються на гіперкуби, у яких всі збережені в БД комірки мають однакову мірність, і полікуби, у яких кожна комірка зберігається із власним набором вимірів. Фізично дані зберігаються в «плоских» файлах, при цьому куб представляється у вигляді однієї плоскої таблиці, у яку рядками вписуються всі комбінації елементів всіх вимірів з відповідними їм значеннями мер.

Дані передаються від джерела даних у багатомірну базу даних, а потім база даних піддається агрегації. Попередній розрахунок прискорює OLAP-запити, оскільки розрахунок зведених даних уже зроблений. Час запиту стає функцією винятково часу, необхідного для доступу до окремого фрагмента даних і виконання розрахунку. Цей метод підтримує концепцію, відповідно до якої робота виконується один раз, а результати потім використовуються знову й знову. Багатомірна база найчастіше буде надлишковою. Куб, побудований на її основі, буде сильно залежати від числа вимірів. При збільшенні кількості вимірів об'єм куба буде експоненційно рости. Іноді це може привести до «підривного росту» обсягу даних, що паралізує в результаті запити користувачів.

«Вибух» бази даних являє собою феномен багатомірних баз. Це пов'язане з розрідженістю бази даних і попередньою агрегацією даних. Якщо багатомірна база даних містить невелике число елементів даних, порівнянне з кількістю забезпечуваних нею рівнів агрегації, кожний фрагмент даних буде вносити більший вклад в усі одержувані з нього дані. Коли база даних «вибухає», розмір її стає істотно більше, ніж він повинен бути.

Переваги використання MOLAP:

· пошук і вибірка даних здійснюється значно швидше, ніж при багатомірному концептуальному погляді на реляційну БД, тому що багатомірна БД денормалізована й містить заздалегідь агреговані показники, забезпечуючи оптимізований доступ до запитуваних комірок і не вимагаючи додаткових перетворень при переході від множини зв'язаних таблиць до багатомірної моделі; середній час відповіді на нерегламентований запит при використанні багатомірної СКБД звичайно на один-два порядки менше, ніж у випадку реляційної СКБД із нормалізованою схемою даних;

· у випадку багатомірних БД легко включити в інформаційну модель різноманітні убудовані функції, тоді як обмеження мови SQL роблять виконання цих задач на основі реляційних БД досить складним, а іноді й неможливим;

· структура й інтерфейси щонайкраще відповідають структурі аналітичних запитів. Цей спосіб більше схожий з ментальною моделлю людини, тому що аналітик звик оперувати плоскими таблицями. Провадячи перетин куба двовимірною площиною в тім або іншому напрямку, легко одержати взаємозалежність будь-якої пари величин щодо обраної міри. Наприклад, як змінювалася вартість виготовлення виробу (міра) у часі (вимір) у розрізі по ділянках, цехам і виробництвах (інший вимір).

Недоліки MOLAP:

· за рахунок денормалізації й попередньо виконаної агрегації обсяг даних у багатомірній БД, як правило, відповідає (по оцінці Кодда) в 2,5... 100 разів меншому обсягу вхідних деталізованих даних;

· у переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому виді, невизначені значення вдається видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані в максимально великі безперервні групи. Крім того, оптимальний з погляду зберігання розріджених даних порядок сортування, швидше за все, не буде збігатися з порядком, що найчастіше використовується в запитах. Тому в реальних системах доводиться шукати компроміс між швидкодією й надмірністю дискового простору, зайнятого базою даних;

· багатомірні БД чутливі до змін у багатомірній моделі. Наприклад, при додаванні нового виміру доводиться змінювати структуру всієї БД, що спричиняє великі витрати часу.

На підставі аналізу достоїнств і недоліків багатомірних БД можна виділити наступні умови, при яких їхнє використання є ефективним:

· обсяг вхідних даних для аналізу не занадто великий (не більше декількох гігабайт), тобто рівень агрегації даних досить високий;

· набір інформаційних вимірів стабільний;

· час відповіді системи на нерегламентовані запити є найбільш критичним параметром;

· потрібне широке використання складних убудованих функцій для виконання кросвимірних обчислень над комірками гіперкуба, у тому числі можливість написання користувальницьких функцій.

ROLAP (Relational OLAP) – для реалізації багатомірної моделі використовуються реляційні БД.

Достоїнства:

· у більшості випадків корпоративні СД реалізуються засобами реляційних СКБД, і інструменти ROLAP дозволяють виконувати аналіз безпосередньо над ними. При цьому розмір сховища не є таким критичним параметром, як у випадку MOLAP;

· у випадку змінної розмірності задачі, коли зміни в структуру вимірів доводиться вносити досить часто, ROLAP-системи з динамічним представленням розмірності є оптимальним рішенням, тому що в них такі модифікації не вимагають фізичної реорганізації БД;

· реляційні СКБД забезпечують значно більш високий рівень захисту даних і гарні можливості розмежування прав доступу.

Головний недолік ROLAP у порівнянні з багатомірними СКБД – менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного пророблення схеми бази даних і настроювання індексів.

HOLAP (Hybrid OLAP) – для реалізації багатомірної моделі використовуються й багатомірні, і реляційні БД. HOLAP-сервери використовують гібридну архітектуру, що поєднує технології ROLAP і MOLAP. На відміну від MOLAP, що працює краще, коли дані більш-менш щільні, сервери ROLAP показують кращі параметри в тих випадках, коли дані досить розріджені. Сервери HOLAP застосовують підхід ROLAP для розріджених областей багатомірного простору й підхід MOLAP – для щільних областей. Сервери HOLAP розділяють запит на кфлька підзапитів, направляють їх до відповідних фрагментів даних, комбінують результати, а потім надають результат користувачеві.

Питання для самоперевірки

1. У чому складаються основні розходження між системами оперативної обробки даних і системами оперативного аналізу даних?

2. Перелічите користувачів аналітичних систем.

3. Які типи даних використовуються в аналітичних системах?

4. Опишіть функції аналітичних систем.

5. Який тест описує вимоги до застосувань для багатомірного аналізу?

6. Що описують правила Кодда?

7. Перелічите основні характеристики OLAP-Систем.

8. Які рівні багатомірності даних Ви знаєте?

9. Назвіть достоїнства й недоліки МOLAP реалізації багатомірної моделі.

10. У чому складаються основні достоїнства ROLAP?

Методичні вказівки до лекції:[1, с. 2-–23]; [2, с. 44–45, 48–57]; [4, с. 873–875]; [5, с. 848–949, 985–986]; [6, с. 64–79]..

Вправи

1. Приведіть приклади історичних, агрегованих і прогнозованих даних для предметної області «Оператор кабельного телебачення».

2. Приведіть приклад запитів із системи оперативної обробки даних і аналітичної системи для обраної Вами предметної області.

3. Приведіть приклад предметної області, для якої корисно створити аналітичну систему.

4. Приведіть приклади аналітичних запитів для предметної області «Оператор кабельного телебачення».

5. Додайте приклади аналітичних запитів для предметної області «Медицина».

ЛЕКЦІЯ №4
 АРХІТЕКТУРА СХОВИЩА ДАНИХ

Розглядаються наступні питання:

· архітектури СД, розповсюджені в цей час;

· фактори, що впливають на вибір архітектури;

· практичні ради на вибір архітектури СД;

· успіх архітектур;

· віртуальні сховища даних.

На сьогоднішній день запропонована множинаархітектур, серед них найпоширеніші:

1) незалежні вітрини даних (independent data marts);

2) шина взаємозалежних вітрин даних (data-mart bus architecture with linked dimensional data marts);

3) архітектура «зірка» (hub-and-spoke);

4) централізоване сховище даних (centralized data warehouse);

5) федеративна архітектура (federated architecture).

Незалежні вітрини даних

Нерідка ситуація, коли кожний підрозділ компанії розробляє свою власну вітрину даних.

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

Всі вітрини задовольняють потреби, для яких створювалися, але при цьому не залежать друг від друга й не забезпечують єдиного представлення про ситуацію в компанії. У них неузгоджено задані дані, використовуються різні виміри й показники, а, отже, аналіз даних між вітринами утруднений.

Шина взаємозалежних вітрин даних

Запропонована Ральфом Кимбеллом (Ralph Kimball).

Створення такої архітектури починається з аналізу вимог для конкретних бізнес-процесів, таких як замовлення, клієнти, рахунки й ін. Перша вітрина даних будується для одного бізнес-процесу з використанням вимірів і показників, які надалі будуть застосовуватися в інших компонентах.

Наступні вітрини даних розробляються з використанням цих вимірів, що в результаті приводить до створення логічно інтегрованих вітрин.

Архітектура «Зірка»

Просувається відомим експертом в області сховищ даних Білом Інмоном (Bill Inmon). Являє собою централізоване сховище даних із залежними вітринами даних.

На основі використання корпоративного представлення даних виконується ітеративна розробка архітектури, при цьому залучається одна предметна область за іншою. Детальні дані зберігаються в нормалізованій формі в сховищі даних. Залежні ВД одержують дані зі сховища даних.

Залежні ВД розробляються для підрозділів або конкретних функціональних областей, цілей (наприклад, для data mining) і можуть бути як нормалізованими, так і денормалізованими, або у вигляді будь-якої агрегованої структури даних. Більшість користувачів виконує запити на залежних вітринах даних.

Така архітектура має три рівні:

1) корпоративне СД на основі однієї із сучасних реляційних СКБД. Це СД інтегрованих в основному деталізованих даних. Реляційні СКБД забезпечують ефективне зберігання й керування даними дуже великого обсягу, але не занадто добре відповідають потребам OLAP-систем, зокрема, у зв'язку з вимогою багатомірного представлення даних;

2) вітрини даних на основі багатомірної СКБД (приклад - Oracle Express Server). Такі СКБД майже ідеально підходять для цілей розробки OLAP-систем, але не дозволяють зберігати надвеликі обсяги даних. У цьому випадку це й не потрібно, оскільки мова йде про вітрини даних. Вітрина даних не обов'язково повинна бути повністю сформована. Вона може містити посилання на СД і добирати звідти інформацію по мірі надходження запитів. Це збільшує час відгуку, але знімає проблему обмеженого обсягу багатомірної БД;

3) клієнтські робочі місця кінцевих користувачів, на яких установлюються засоби оперативного аналізу даних.