Д в OLAP-системах:
пошук і вибірка даних здійснюються значно швидше, ніж при багатовимірному концептуальному погляді на реляційну БД, оскільки багатовимірна база даних денормалізована і містить заздалегідь агреговані показники, забезпечуючи оптимізований доступ до запитуваною осередкам і не вимагаючи додаткових перетворень при переході від безлічі зв'язаних таблиць до багатовимірної моделі;
багатовимірні БД легко справляються з завданнями включення в інформаційну модель різноманітних вбудованих функцій, тоді як об'єктивно існуючі обмеження мови SQL роблять виконання цих завдань на основі реляційних БД досить складним, а іноді й неможливим.
З іншого боку, є також суттєві недоліки:
за рахунок денормалізації і попередньо виконаної агрегації обсяг даних в багатовимірної БД, як правило, відповідає (за оцінкою Кодда) в 2,5 ... 100 раз меншого об'єму вихідних деталізованих даних;
в переважній більшості випадків інформаційного гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому вигляді, невизначені значення вдається видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані в максимально великі безперервні групи. Але навіть у цьому випадку проблема вирішується тільки частково. Крім того, оптимальний з точки зору зберігання розріджених даних порядок сортування, швидше за все, не буде збігатися з порядком, який найчастіше використовується в запитах. Тому в реальних системах доводиться шукати компроміс між швидкодією і надмірністю дискового простору, зайнятого базою даних;
багатовимірні БД чутливі до змін в багатовимірної моделі. Так при додаванні нового виміри доводиться змінювати структуру всієї БД, що тягне за собою великі витрати часу.
На підставі аналізу достоїнств і недоліків багатовимірних БД можна виділити наступні умови, за яких їх використання є ефективним:
обсяг вихідних даних для аналізу не надто великий (не більше декількох гігабайт), тобто рівень агрегації даних досить високий;
набір інформаційних вимірювань стабільний;
час відповіді системи на нерегламентовані запити є найбільш критичним параметром;
потрібно широке використання складних вбудованих функцій для виконання кроссмерних обчислень над осередками гіперкуба, у тому числі можливість написання користувальницьких функцій.сервери використовують реляційні БД. За словами Кодда, «реляційні БД були, є і будуть найбільш придатною технологією для зберігання даних. Необхідність існує не в новій технології БД, а скоріше в засобах аналізу, доповнюючих функції існуючих СУБД, і досить гнучких, щоб передбачити й автоматизувати різні види інтелектуального аналізу, властиві OLAP ».
В даний час поширені дві основні схеми реалізації багатовимірного представлення даних за допомогою реляційних таблиць: схема «зірка» (малюнок 5) і схема «сніжинка» (малюнок 6).
Малюнок 5. Приклад схеми «зірка»
Малюнок 6. Приклад схеми «сніжинка»
Основними складовими таких схем є денормалізованная таблиця фактів (Fact Table) і безліч таблиць вимірів (Dimension Tables).
Таблиця фактів, як правило, містить відомості про об'єкти або події, сукупність яких буде надалі аналізуватися. Зазвичай говорять про чотирьох найбільш часто зустрічаються типах фактів. До них відносяться:
факти, пов'язані з транзакціями (Transaction facts). Вони засновані на окремих подіях (типовими прикладами яких є телефонний дзвінок або зняття грошей з рахунку за допомогою банкомату);
факти, пов'язані з «моментальними знімками» (Snapshot facts). Засновані на стан об'єкта (наприклад, банківського рахунку) в певні моменти часу, наприклад на кінець дня чи місяця. Типовими прикладами таких фактів є обсяг продажів за день або денна виручка;
факти, пов'язані з елементами документа (Line-item facts). Засновані на тому чи іншому документі (наприклад, рахунку за товар або послуги) і містять детальну інформацію про елементи цього документа (наприклад, кількості, ціні, відсотку знижки);
факти, пов'язані з подіями або станом об'єкта (Event or state facts). Представляють виникнення події без подробиць про нього (наприклад, просто факт продажу або факт відсутності такої без інших подробиць).
Таблиця фактів, як правило, містить унікальний складовою ключ, об'єднуючий первинні ключі таблиць вимірів. При цьому як ключові, так і деякі не ключові поля повинні відповідати вимірам гіперкуба. Крім цього таблиця фактів містить одне або кілька числових полів, на підставі яких в подальшому будуть отримані агрегатн...
