і дані.
Для багатовимірного аналізу придатні таблиці фактів, що містять якомога більш докладні дані, тобто відповідні членам нижніх рівнів ієрархії відповідних вимірювань. У таблиці фактів немає жодних відомостей про те, як групувати записи при обчисленні агрегатних даних. Наприклад, в ній є ідентифікатори продуктів або клієнтів, але відсутня інформація про те, до якої категорії відноситься даний продукт або в якому місті знаходиться даний клієнт. Ці відомості, надалі використовуються для побудови ієрархій у вимірах куба, містяться в таблицях вимірів.
Таблиці вимірювань містять незмінні або рідко змінювані дані. У переважній більшості випадків ці дані представляють собою по одному запису для кожного члена нижнього рівня ієрархії у вимірі. Таблиці вимірювань також містять як мінімум одне описове поле (зазвичай з ім'ям члена виміру) і, як правило, цілочисельне ключове поле (зазвичай це сурогатний ключ) для однозначної ідентифікації члена виміру. Якщо вимірювання, відповідне таблиці, містить ієрархію, то така таблиця також може містити поля, що вказують на «батька» даного члена в цій ієрархії. Кожна таблиця вимірювань повинна знаходитися у відношенні «один-до-багатьох» з таблицею фактів.
У складних завданнях з ієрархічними вимірами має сенс звернутися до розширеної схемою «сніжинка» (Snowflake Schema). У цих випадках окремі таблиці фактів створюються для можливих поєднань рівнів узагальнення різних вимірів (малюнок 6). Це дозволяє домогтися кращої продуктивності, але часто призводить до надмірності даних і до значних усложнениям в структурі бази даних, в якій опиняється величезна кількість таблиць фактів.
Збільшення числа таблиць фактів в базі даних визначається не тільки множинністю рівнів різних вимірів, а й тією обставиною, що в загальному випадку факти мають різні безлічі вимірів. При абстрагуванні від окремих вимірювань користувач повинен отримувати проекцію максимально повного гіперкуба, причому далеко не завжди значення показників в ній повинні бути результатом елементарного підсумовування. Таким чином, при великому числі незалежних вимірювань необхідно підтримувати безліч таблиць фактів, відповідних кожному можливому поєднанню обраних в запиті вимірювань, що також призводить до неекономного використання зовнішньої пам'яті, збільшення часу завантаження даних в БД схеми «зірки» із зовнішніх джерел і складнощам адміністрування.
Використання реляційних БД в OLAP-системах має такі переваги: ??
в більшості випадків корпоративні сховища даних реалізуються засобами реляційних СУБД, і інструменти ROLAP дозволяють виробляти аналіз безпосередньо над ними. При цьому розмір сховища не є таким критичним параметром, як у випадку MOLAP;
у разі змінної розмірності задачі, коли зміни в структуру вимірювань доводиться вносити досить часто, ROLAP-системи з динамічним поданням розмірності є оптимальним рішенням, тому в них такі модифікації не вимагають фізичної реорганізації БД;
реляційні СУБД забезпечують значно вищий рівень захисту даних і хороші можливості розмежування прав доступу.
Головний недолік ROLAP в порівнянні з багатовимірними СУБД - менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних і налаштування індексів, тобто великих зусиль з боку адміністраторів БД. Тільки при використанні схем типу «зірка» продуктивність добре налаштованих реляційних систем може бути наближена до продуктивності систем на основі багатовимірних баз даних. інформація зберігання мережу локальний
HOLAP-сервери використовують гібридну архітектуру, яка об'єднує технології ROLAP і MOLAP. На відміну від MOLAP, яка працює краще, коли дані більш-менш щільні, сервери ROLAP показують кращі параметри в тих випадках, коли дані досить розріджені. Серверипріменяют підхід ROLAP для розріджених областей багатовимірного простору і підхід MOLAP - для щільних областей. Сервери HOLAP поділяють запит на кілька підзапитів, направляють їх до відповідних фрагментам даних, комбінують результати, а потім надають результат користувачеві.
Висновок
Таким чином, по-перше, сховище даних повинне вирішувати певні завдання: отримання повної інформації про клієнта, надання конкретних даних для подальшого аналізу певного сегмента ринку і т.д. По-друге, сховище має бути гнучким. Практика показує, що в міру розвитку бізнесу завдання змінюються. Відповідно, змінюються вимоги до даних, звітності і, як наслідок, до сховища. Поява нових систем, злиття і поглинання компаній є відправною точкою для наповнення сховища новою інформацією. Звідси випливає, що використовуються для завантаження даних в сховища ETL-засоби також повинні забезпеч...
