OLAP

Основою концепції OLAP є ідея віртуально багатовимірного OLAP-куба (гіперкуба). Осями (вимірами) OLAP-кубу є числові або короткі лінгвістичні дані про предметну область роботи. Приклади фрагментів даних із різних сфер діяльності: поштові адреси (країна, місто, район, поштовий індекс, вулиця), регіон планети, географічні координати; системний час виконання операції чи процесу; прізвища продавців, номер картки покупця з його ідентифікаційними даними, назви товарів, код товарів, ціни товарів, кількість товарів; лінгвістичні і числові ідентифікатори лікарів і хворих, назви і коди хвороб та їх груп; назви сільгосппродуктів; назва заявки на обслуговування, атрибути оператора, час прийняття і виконання заявки, атрибути виконавця; прізвища та коди працівників силових структур, прізвища порушників, назви і коди порушень та їх групи; назви зразків озброєння і воєнної техніки, їх груп; ін. Кількість таких числових і лінгвістичних видів даних (вимірів, осей) і їх градацій визначається аналітичними потребами, які можуть потребувати від 10 до 100 і більше даних (вимірів, осей). Загальноприйнята назва "багатовимірний куб" (OLAP-куб) є умовною, адже його осі даних мають різну довжину. Для аналізу утворюють OLAP-гіперкуби, які мають як мінімум кілька осей різної координатної довжини. У великих системах вхідні дані для OLAP можуть бути попередньо узагальненими у сховищі даних (Data Warehouse), адже дані у системах реєстрації транзакцій (OLTP-системах) безперервно змінюються, для прикладу, дані у системах реєстрації продажів товарів, квитків, ін.

У теперішній час OLAP-куб часто створюють за допомогою реляційних баз даних із застосуванням схем"зірка", а також "сніжинка". В центрі «зірки» знаходиться таблиця, яка містить ключові факти відповідно до їх назв у сховищі чи кіоску даних. До таблиці фактів приєднується необхідна кількість таблиць-вимірів, які є "променями зірки" у схемі бази даних ROLAP-моделі. Назви стовпчиків цих таблиць - це первинні дані, на основі яких можуть виконуватися базові OLAP-операції. Кількість можливих агрегацій визначається кількістю способів, якими первинні дані можуть бути ієрархічно відображені. Наприклад, всі клієнти можуть бути згруповані за містами, або за регіонами (Захід, Схід, Північ і т. д.), Таким чином, для прикладу, 50 міст, 8 регіонів і 2 країни можуть скласти 3 рівні ієрархії з 60 членами - якщо за основу часткової OLAP-ієрархії взяти географічні частини країни. Також клієнти можуть бути об'єднані за відношенням до продукції; якщо існують 250 продуктів у двох категоріях, 3 групи продукції і 3 виробничих підрозділи, то кількість агрегатів складе 16560. При додаванні вимірів в схему, кількість можливих варіантів швидко досягає десятків мільйонів і більше. Тому необхідно мати певний досвід і специфічне просторове мислення у виборі найбільш ефективних OLAP-візуалізацій за допомогою зведених таблиць (карт), діаграм чи схем для підтримки прийняття рішень.

OLAP-куб забезпечує відповіді на різноманітні аналітичні запити у рамках пойменованих даних у сховищі даних (кіоску даних) і їх OLAP-агрегатів. Через величезну кількість агрегатів, часто повний розрахунок відбувається тільки для деяких вимірювань, для останніх же проводиться «на вимогу».

Традиційно OLAP-системи поділяють на такі види[4]:

• багатовимірна OLAP (Multidimensional OLAP), MOLAP;
• реляційна OLAP (Relational OLAP), ROLAP;
• гібридна OLAP (Hybrid OLAP), HOLAP.

MOLAP це класична форма OLAP, так що її часто називають просто OLAP. Вона використовує підсумовуючу БД, спеціальний варіант процесора просторових БД і створює необхідну просторову схему даних зі збереженням як базових даних, так і агрегатів. ROLAP працює безпосередньо з реляційним сховищем, факти і таблиці з вимірюваннями зберігаються в реляційних таблицях, і для зберігання агрегатів створюються додаткові реляційні таблиці. HOLAP використовує реляційні таблиці для зберігання базових даних і багатовимірні таблиці для агрегатів. Особливим випадком ROLAP є ROLAP реального часу (Real-time ROLAP, або R-ROLAP). На відміну від ROLAP, в R-ROLAP для зберігання агрегатів не створюються додаткові реляційні таблиці, а агрегати розраховуються у момент запиту. При цьому багатовимірний запит до OLAP-системи автоматично перетвориться в SQL-запит до реляційних даних.

Кожен тип зберігання має певні переваги, хоча є розбіжності в їх оцінці у різних виробників. MOLAP краще всього підходить для невеликих наборів даних, він швидко розраховує агрегати і дає відповіді, але при цьому генеруються величезні обсяги даних. ROLAP оцінюється як більш масштабоване рішення, яке до того ж використовує найменший можливий простір. При цьому швидкість обробки значно знижується. HOLAP знаходиться між цими двома підходами, він досить добре масштабується і швидко обробляється. Архітектура R-ROLAP дозволяє проводити багатовимірний аналіз OLTP-даних в режимі реального часу.

Складність в застосуванні OLAP полягає в створенні запитів, виборі базових даних і розробці схеми, внаслідок чого більшість сучасних продуктів OLAP поставляються разом з величезною кількістю заздалегідь сконфігурованих запитів. Інша проблема полягає в базових даних. Вони повинні бути повними і несуперечливими.

Першим продуктом, що виконував OLAP-запити, був Express (компанія IRI). Проте сам термін OLAP був запропонований «батьком реляційних БД» Едгаром Коддом. А робота Кодда фінансувалася Arbor, компанією, що випустила свій власний OLAP-продукт Essbase роком раніше (пізніше куплений Hyperion, яка в 2007 р. була поглинена компанією Oracle). Як результат, «OLAP» Кодда з'явився в їх описі Essbase.

Інші добре відомі OLAP-продукти включають Microsoft Analysis Services (що раніше називалися OLAP Services, частина Microsoft SQL Server), DB2 OLAP Server від IBM (фактично, EssBase з доповненнями від IBM), продукти MicroStrategy і інших виробників.

З технічної точки зору, представлені на ринку продукти діляться на «фізичний OLAP» і «віртуальний».

У першому випадку наявна програма, що виконує попередній розрахунок агрегатів, які потім зберігаються в спеціальній багатовимірній БД, що забезпечує швидкий доступ. Приклади таких продуктів: Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay.

У другому випадку дані зберігаються у реляційних СУБД, а агрегати можуть не існувати взагалі або створюватися за першим запитом у СУБД або кеші аналітичного ПО. Приклади таких продуктів: SAP BW, BusinessObjects, Microstrategy.

Системи, що мають в своїй основі «фізичний OLAP» забезпечують стабільно кращий час відгуку на запити, ніж системи «віртуальний OLAP». Постачальники систем «віртуальний OLAP» заявляють про більшу масштабованість їх продуктів в плані підтримки дуже великих обсягів даних.

З погляду користувача обидва варіанти виглядають схожими за можливостями.

• Silberschatz, Abraham; Korth, Henry F.; Sudarshan, S. (2011). Database system concepts (вид. 6). New York: McGraw-Hill. ISBN 978-0-07-352332-3. OCLC 436031093.

1. Codd, E. F.; S B Codd; C T Salley (26 липня 1993). Providing OLAP to User-Analysts: An IT Mandate. Computerworld. Архів оригіналу за 8 серпня 2017.
2. Silberschatz, Korth та Sudarshan, 2011, с. 197.
3. What is OLAP? by Nigel Pendse, Principal of OLAP Solutions and Co-author of the OLAPreport.com, 06.09.2001
4. Silberschatz, Korth та Sudarshan, 2011, с. 204.