тривалим.
Клієнт. Клієнт - Це якраз те, що використовується для представлення та маніпуляцій з даними в базі даних. Клієнт може бути і достатньо нескладним - у вигляді таблиці, що включає в себе такі можливості OLAP, як, наприклад, обертання даних (півотінг) і поглиблення в дані (Дриллинг), і представляти собою спеціалізоване, але таке ж просте засіб перегляду звітів або бути таким же потужним інструментом, як створене на замовлення додаток, спроектоване для складних маніпуляцій з даними. Інтернет є новою формою клієнта. Крім того, він несе на собі печатку нових технологій; безліч інтернет-рішень істотно відрізняються за своїми можливостями в цілому і в якості OLAP-рішення - зокрема. У даному розділі обговорюються різні функціональні властивості кожного типу клієнтів.
Незважаючи на те, що сервер - це як би "хребет" OLAP-рішення, клієнт не менш важливий. Сервер може забезпечити міцний фундамент для полегшення маніпуляцій з даними, але якщо клієнт складний або малофункціонален, користувач не зможе скористатися всіма перевагами потужного сервера. Клієнт настільки важливий, що безліч постачальників зосереджують свої зусилля виключно на розробці клієнта. Все, що включається до складу цих додатків, представляє собою стандартний погляд на інтерфейс, заздалегідь певні функції і структуру, а також швидкі рішення для більш-менш стандартних ситуацій. Наприклад, популярні фінансові пакети. Інструмент
Тим не менш, Інтернет. часу і грошей.
більш того. інструменти.
Додатка. Додатки Зазвичай До того Після
В даний час
1. Для
2. сховищами.
3.
Крім перерахованих у додатку.
Використання
1.
2.
З іншого боку,
1. даних.
-->p>
2. У переважній
Отже,
1.
2.
3.іровать запити є найбільш критичним параметром.
4. Потрібно широке використання складних вбудованих функцій для виконання кроссмерних обчислень над осередками гіперкуба, в тому числі можливість написання користувальницьких функцій.
3.2 Реляційний OLAP
Безпосереднє використання реляційних БД в системах оперативної аналітичної обробки має наступні достоїнства.
1. У більшості випадків корпоративні сховища даних реалізуються засобами реляційних СУБД, і інструменти ROLAP дозволяють виробляти аналіз безпосередньо над ними. При цьому розмір сховища не є таким критичним параметром, як у випадку MOLAP.
2. У разі змінної розмірності задачі, коли зміни в структуру вимірювань доводиться вносити достатньо часто, ROLAP системи з динамічним поданням розмірності є оптимальним рішенням, так як в них такі модифікації не вимагають фізичної реорганізації БД.
3. Реляційні СУБД забезпечують значно більш високий рівень захисту даних і хороші можливості розмежування прав доступу.
Головний недолік ROLAP в порівнянні з багатовимірними СУБД - менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних і налаштування індексів, тобто великих зусиль з боку адміністраторів БД. Тільки при використанні зіркоподібних схем продуктивність добре налаштованих реляційних систем може бути наближена до продуктивності систем на основі багатовимірних баз даних [8].
Опису схеми зірки (star schema) і рекомендаціям по її застосуванню повністю присвячені роботи. Її ідея полягає в тому, що є таблиці для кожного виміру, а всі факти поміщаються в одну таблицю, індексований множинним ключем, складеним із ключів окремих вимірів (Додаток А). Кожен промінь схеми зірки задає, в термінології Кодда, напрям консолідації даних за відповідним вимірюванню.
У складних завданнях з багаторівневими вимірами має сенс звернутися до розширень схеми зірки - Схемою сузір'я (fact constellation schema) і схемою сніжинки (snowflake schema). У цих випадках окремі таблиці фактів створюються для можливих поєднань рівнів узагальнення різних вимірів (Додаток Б). Це дозволяє домогтися кращої продуктивності, але часто призводить до надмірності даних і до значних ускладнень в структурі бази даних, в якій виявляється величезна кількість таблиць фактів.
Збільшення числа таблиць фактів в базі даних може виникати не тільки з множинності рівнів різних вимірів, але і з тієї обставини, що в загальному випадку факти мають різні безлічі вимірів. При абстрагуванні від окремих вимірювань користувач повинен отримувати проекцію максимально повного гіперкуба, причому далеко не завжди значення показників в ній повинні бути результатом елементарного підсумовування. Таким чином, при великому числі незалежних вимірювань необхідно підтримувати безліч таблиць фактів, відповідних кожному можливому поєднанню обраних в запиті вимірювань, що також призводить до неекономного використання зовнішньої пам'яті, збільшенню часу завантаження даних в БД схеми зірки із зовнішніх джерел і складнощів адміністрування.
Частково вирішують цю проблему розширення мови SQL (оператори GROUP BY CUBE "," GROUP BY ROLLUP "і" GROUP BY GROUPING SETS "); крім того, пропонується механізм пошуку компромісу між надмірністю та швидкодією, рекомендуючи створювати таблиці фактів не для всіх можливих поєднань вимірювань, а тільки для тих, значення комірок яких не можуть бути отримані за допомогою наступної агрегації більш повних таблиць фактів (Додаток В).
У будь-якому випадку, якщо багатовимірна модель реалізується у вигляді реляційної бази даних, слід створювати довгі і "вузькі" таблиці фактів і порівняно невеликі і "широкі" таблиці вимірів. Таблиці фактів містять чисельні значення осередків гіперкуба, а інші таблиці визначають містить їх багатовимірний базис вимірювань. Частина інформації можна отримувати за допомогою динамічної агрегації даних, розподілених по незвездообразним нормалізованим структурам, хоча при цьому слід пам'ятати, що включають агрегацію запити при високонормалізованной структурі БД можуть виконуватися досить повільно.
Орієнтація на уявлення багатовимірної інформації за допомогою зіркоподібних реляційних моделей дозволяє позбутися проблеми оптимізації зберігання розріджених матриць, гостро стоїть перед багатовимірними СУБД (де проблема розрідженості вирішується спеціальним вибором схеми). Хоча для зберігання кожного осередку використовується ціла запис, яка крім самих значень включає вторинні ключі - посилання на таблиці вимірювань, неіснуючі значення просто не включаються в таблицю фактів.
Висновок
Успішна компанія сьогодні повинна приймати безліч різних рішень. І чим більш обгрунтовані рішення будуть прийняті, тим більшого успіху і прибутку досягне підприємство. Для багатьох осіб, які відіграють ключову роль у прийнятті рішень, здатність швидше і ефективніше конкурента аналізувати бізнес-процеси означає прийняття більш правильних рішень, досягнення більшої прибутковості і більшого успіху. Оптимізація реляційної бази даних надала компаніям можливість продуктивно збирати дані про транзакції, поставляючи інформації особам, що приймають рішення.
Розглянувши питання роботи і застосування технології OLAP перед компаніями виникають питання, відповіді на які дозволять вибрати продукт найкращим чином відповідає потребам користувача.
Це наступні питання:
Звідки надходять дані? - Дані, що підлягають аналізу, можуть перебувати в різних місцях. Можливо, що база даних OLAP буде отримувати їх з корпоративного Сховища даних або з OLTP-системи. Якщо OLAP-продукт вже має можливість отримати доступ до якогось джерела даних, процеси категоризації та очищення даних скорочуються.
Які маніпуляції користувач виробляє над даними? -
Як тільки користувач отримав доступ до бази даних і почав виконувати аналіз, важливо, щоб він був в змозі оперувати даними відповідним чином. В залежності від потреб користувача, може виявитися, що необхідний потужний генератор звітів або можли...
