3.2.4. Сфера застосування багатовимірних субд

Використання багатовимірних БД у системах оперативної аналітичної обробки має певні переваги:

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

2. Багатовимірне представлення даних дозволяє реалізувати ­інструментарій аналітика на основі вбудованих функцій аналізу І ­даних, які не підтримуються засобами реляційних СУБД.

З іншого боку, є істотні обмеження на використання БСУБД:

1. БСУБД не дозволяють працювати з великими базами даних, ­На сьогоднішній день їх реальна межа - 10-20 гігабайт.

2. БСУБД порівняно з реляційними малоефективно використовують зовнішню пам'ять. Чарунки гіперкуба зберігаються в них у ­вигляді логічно впорядкованих масивів (блоків фіксованої довжини), ­причому саме такий блок є мінімальною одиницею, яка індексується. ­Хоч у багатовимірних СУБД блоки, які не містять жодного певного ­значення, не зберігаються, це вирішує проблему тільки частково. ­Оскільки дані зберігаються у впорядкованому вигляді, невизначені значення не завжди віддаляються повністю, а лише в тому випадку, ­коли за рахунок вибору порядку сортування дані вдається організувати в максимально великі безперервні групи. Але порядок сортування, який частіше за все використовується в запитах, може не ­співпадати з порядком, в якому вони повинні бути відсортовані а ­метою максимального усунення неіснуючих значень. Таким чином, ­при проектуванні багатовимірної БД часто доводиться жертвувати ­або швидкодією (а це одна з перших переваг та головна причина ви­ ­бору саме багатовимірної СУБД), або зовнішньою пам'яттю.

3. Для багатовимірних СУБД поки відсутні єдині стандарти на ­інтерфейс, мови опису та маніпулювання даними.

4. Багатовимірні СУБД не підтримують реплікацію даних, яка ­часто використовується як механізм завантаження даних.

Використання БСУБД виправдане тільки при умовах, коли:

1. Рівень агрегації даних досить високий. При цьому об'єм по­чаткових даних для аналізу не дуже великий (не більше кількох ­гігабайт).

2. Набір інформаційних вимірів стабільний (оскільки будь-яка ­зміна в їх структурі майже завжди вимагає повної перебудови ­гіперкуба).

3.3. Реляційний оlар (rоlар)

Забезпечення для реляційних системи продуктивності, набли­женої до продуктивності МОLАР-систем потребує ретель­ної розробки схеми БД. Використання схеми «зірка» («star schema») у реляційних системах забезпечує продуктивність, цілком порівнянну з продуктивністю систем на основі багатовимір­них х баз даних [23].

У цій схемі використовуються два види таблиць - таблиця фактів (фактологічна таблиця) та кілька довідкових таблиць (таблиць вимірювань). Як приклад, на рис. ЗА наведено спрощену схе­му структури сховища даних на основі «зірки». Лініями вказані зв'язки між таблицями, ключові атрибути таблиць виділені напівжирним шрифтом

Рис. 3.4. Приклад БД з радіально пов'язаними таблицями (схема «зірка»)

Кожний промінь схеми «зірка» задає (за термінологією Е. Кодда) напрямок консолідації даних за відповідним виміром.

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

Якщо БД включає велику кількість вимірювань, використовується схема «сніжинка» («snowflake» ). У цій схемі атрибути довідкових таблиць деталізують у додаткових довідкових таблицях {рис. 3.5).

Рис. 3.5. Приклад БД зі схемою «сніжинка»

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

Використання інструментів RОLАР у системах оперативної аналітичної обробки має певні переваги:

1. Вони дозволяють проводити аналіз безпосередньо над сховищем (оскільки в переважній більшості випадків корпоративні сховища даних реалізуються засобами реляційних СУБД).

2. У разі змінної розмірності задачі, коли зміни в структуру вимірів ­доводиться вносити досить часто, RОLАР системи з динамічним представленням розмірності є оптимальним рішенням, оскільки в них такі ­модифікації не вимагають фізичної реорганізації БД.

1. Системи RОLАР можуть функціонувати на набагато менш могутніх клієнтських станціях, ніж системи MOLAP, оскільки головне обчислювальне навантаження в них лягає на сервер, де виконуються складні аналітичні SQL-запити, які формуються системою.

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

5. Реляційні СУБД реалізують реальний досвід роботи з дуже великими базами даних та розвиненими засобами адміністрування.

Недоліками RОLАР-систем є, по-перше, обмежені можливості з точки зору розрахунку значень функціонального типу; по-друге, менша продуктивність порівняно з МОLАР- системами.

Це пов'язано з тім, що побудова схеми «зірка» вимагає створен­ня проміжної таблиці, яка є декартовим добутком довідкових таб­лиць, які використовуються в запиті. Потім виконується послідов­ний перегляд двох таблиць (фактологічної та проміжної), у процесі якого відсіваються усі рядки, які не відповідають умовам вибору. Такий спосіб оптимізації дає ефект тільки тоді, коли проміжна таб­лиця вміщується в ОЗП. Алі це не завжди так. Наприклад, якщо запит посилається на 10 довідкових таблиць, у кожній з яких лише 10 рядків довжиною в 40 символів, унаслідок виконання операції декартового добутку вийде проміжна таблиця в 10 млрд. рядків. А обсяг ОЗП для її розміщення становитиме 400 гігабайт.

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

Сьогодні БСУБД усе частіше і частіше використовують не тільки як самостійний програмний продукт, але й як аналітичні засоби переднього плану по відношенню до систем сховищ даних або тра­диційних оперативних систем, що реалізуються засобами реля­ційних СУБД (рис. 3.6).

Взагалі ІС з аналітичними можливостями включає три рівні використання даних:

• перший рівень - це загальнокорпоративна БД на основі реляційної СУБД із нормалізованою чи слабо нормалізованою схе­мою (деталізована БД);

• другий рівень ~ це БД агрегованих даних рівня підрозділу, реалізована на основі БСУБД;

• третій рівень - персональна БД агрегованих даних на робо­чому місці кінцевого користувача, де безпосередньо встановлений аналітичний інструментарій

Рис. 3.6. Використання БСУБД у багаторівневій архітектурі

інформаційної системи