обертання (rotate) і розміщення (pivot) напрямків консолідації. Прозорість (Transparency). Користувач не повинен знати про те, які конкретні засоби використовуються для зберігання та обробки даних, як дані організовані і звідки беруться.
Доступність (Accessibility). Аналітик повинен мати можливість виконувати аналіз в рамках загальної концептуальної схеми, але при цьому дані можуть залишатися під управлінням залишилися від старого спадщини СУБД, будучи при цьому прив'язаними до загальної аналітичної моделі. Тобто інструментарій OLAP повинен накладати свою логічну схему на фізичні масиви даних, виконуючи всі перетворення, що вимагаються для забезпечення єдиного, узгодженого і цілісного погляду користувача на інформацію.
Стійка продуктивність (Consistent Reporting Performance). Зі збільшенням числа вимірювань і розмірів бази даних аналітики не повинні зіткнутися з яким би то не було зменшенням продуктивності. Стійка продуктивність необхідна для підтримки простоти використання і свободи від ускладнень, що вимагаються для доведення OLAP до кінцевого користувача.
Клієнт - серверна архітектура (Client-Server Architecture). Більша частина даних, що вимагають оперативної аналітичної обробки, зберігається в мейнфреймових системах, а витягується з персональних комп'ютерів. Тому однією з вимог є здатність продуктів OLAP працювати в середовищі клієнт-сервер. Головною ідеєю тут є те, що серверний компонент інструмента OLAP повинен бути достатньо інтелектуальним і мати здатність будувати загальну концептуальну схему на основі узагальнення і консолідації різних логічних і фізичних схем корпоративних баз даних для забезпечення ефекту прозорості.
Рівноправність вимірювань (Generic Dimensionality). Всі вимірювання даних повинні бути рівноправні. Додаткові характеристики можуть бути надані окремим вимірам, але оскільки всі вони симетричні, дана додаткова функціональність може бути надана будь-якому вимірюванню. Базова структура даних, формули і формати звітів не повинні спиратися на якесь один вимір.
Динамічна обробка розріджених матриць (Dynamic Sparse Matrix Handling). Інструмент OLAP повинен забезпечувати оптимальну обробку розріджених матриць. Швидкість доступу повинна зберігатися незалежно від розташування осередків даних і бути постійною величиною для моделей, що мають різне число вимірювань і різну розрідженість даних.
Підтримка багатокористувацького режиму (Multi-User Support). Найчастіше кілька аналітиків мають необхідність працювати одночасно з однією аналітичною моделлю або створювати різні моделі на основі одних корпоративних даних. Інструмент OLAP повинен надавати їм конкурентний доступ, забезпечувати цілісність та захист даних.
Необмежена підтримка кроссмерних операцій (Unrestricted Cross-dimensional Operations). Обчислення і маніпуляція даними по будь-якого числа вимірів не повинні забороняти або обмежувати будь-які відносини між осередками даних. Перетворення, що вимагають довільного визначення, повинні задаватися на функціонально повному формульному мовою.
Інтуїтивне маніпулювання даними (Intuitive Data Manipulation). Переорієнтація напрямків консолідації, деталізація даних в колонках і рядках, агрегація та інші маніпуляції, властиві структурі ієрархії напрямків консолідації, повинні виконуватися в максимально зручному, природному і комфортному інтерфейсі [3].
Гнучкий механізм генерації звітів (Flexible Reporting). Повинні підтримуватися різні способи візуалізації даних, тобто звіти повинні подаватися в будь-якій можливій орієнтації.
Необмежена кількість вимірювань і рівнів агрегації (Unlimited Dimensions and Aggregation Levels). Настійно рекомендується допущення в кожному серйозному OLAP інструменті як мінімум п'ятнадцяти, а краще двадцяти, вимірювань в аналітичній моделі.
2 Компоненти OLAP-систем
2.1 Сервер. Клієнт. Інтернет
OLAP дозволяє виконувати швидкий і ефективний аналіз над великими об'ємами даних. Дані зберігаються в багатовимірному вигляді, що найбільш близько відображає природний стан реальних бізнес-даних. Крім того, OLAP надає користувачам можливість швидше і простіше отримувати зведені дані. З його допомогою вони можуть при необхідності заглиблюватися (Drill down) у вміст цих даних для отримання більш деталізованої інформації [4].
OLAP-система складається з безлічі компонент. На найвищому рівні представлення система включає в себе джерело даних, OLAP-сервер і клієнта. Джерело даних являє собою джерело, з якого беруться дані для аналізу. Дані з джерела переносяться або копіюються на OLAP-сервер, де вони систематизуються і готуються для більш швидкого згодом формування відповідей на запити. Клієнт - це користувальницький інтерфейс до OLAP-сервера. У цьому розділі статті описуються функції кожної компоненти і значення всієї системи в цілому. Джерела. Джерелом в OLAP-системах є сервер, який постачає дані для аналізу. В залежності від галузі використання OLAP-продукту джерелом може служити Сховище даних, що успадковується база даних, містить загальні дані, набір таблиць, які об'єднують фінансові дані або будь-яка комбінація перерахованого. Здатність OLAP-продукту працювати з даними з різних джерел дуже важлива. Вимога єдиного формату або єдиної бази, в яких би зберігалися всі вихідні дані, не підходить адміністраторам баз даних. Крім того, такий підхід зменшує гнучкість і потужність OLAP-продукту. Адміністратори і користувачі вважають, що OLAP-продукти, що забезпечують вилучення даних не тільки з різних, але й з багатьох джерел, виявляються більш гнучкими і корисними, ніж ті, що мають більш жорсткі вимоги.
Сервер. Прикладної частиною OLAP-системи є OLAP-сервер. Ця складова виконує всю роботу (В залежності від моделі системи), і зберігає в собі всю інформацію, до якої забезпечується активний доступ. Архітектурою сервера керують різні концепції. Зокрема, основної функціональної характеристикою OLAP-продукту є використання для зберігання даних багатовимірної (ММБД, MDDB) або реляційної (РДБ, RDB) бази даних. Агреговані/Попередньо агреговані дані
Швидка реалізація запитів є імперативом для OLAP. Це один з базових принципів OLAP - здатність інтуїтивно маніпулювати даними вимагає швидкого витягання інформації. В цілому, чим більше обчислень необхідно зробити, щоб отримати фрагмент інформації, тим повільніше відбувається відгук. Тому, щоб зберегти маленький час реалізації запитів, фрагменти інформації, звернення до яких зазвичай відбувається найбільш часто, але які при цьому вимагають обчислення, піддаються попередній агрегації. Тобто вони підраховуються і потім зберігаються в базі даних в якості нових даних. В якості прикладу типу даних, який допустимо розрахувати заздалегідь, можна навести зведені дані - наприклад, показники продажів по місяцях, кварталах або роках, для яких дійсно введеними даними є щоденні показники [5].
Різні постачальники дотримуються різних методів відбору параметрів, що вимагають попередньої агрегації і числа попередньо обчислюваних величин. Підхід до агрегації впливає одночасно і на базу даних і на час реалізації запитів. Якщо обчислюється більше величин, ймовірність того, що користувач запросить вже обчислену величину, зростає, і тому час відгуку скоротитися, оскільки не доведеться запитувати споконвічну величину для обчислення. Однак, якщо вирахувати всі можливі величини - це не краще рішення - в такому випадку істотно зростає розмір бази даних, що зробить її некерованою, та й час агрегації буде занадто великим. До того ж, коли в базу даних додаються числові значення, або якщо вони змінюються, інформація ця повинна відображатися на попередньо обчислених величинах, що залежать від нових даних. Таким чином, і оновлення бази може також зайняти багато часу в разі великого числа попередньо обчислюваних величин. Оскільки зазвичай під час агрегації база даних працює автономно, бажано, щоб час агрегації було не дуже ...
