OLAP

OLAP (англ. online analytical processing, аналітична обробка у реальному часі)^[1] — це інтерактивна система що дозволяє переглядати різні підсумки по багатовимірних даних. Термін "в реальному часі" (англ. online) означає що нові результати отримуються протягом секунд, без довгого очікування на результат запиту^[2].

Основоположником OLAP є автор реляційної моделі даних Едгар Кодд, який запропонував у 1993 році «12 правил аналітичної обробки в реальному часі»^[1] - за аналогією з раніше сформульованими ним 12-ма правилами для реляційних БД. У 1995 році Едгар Кодд додав ще 6 правил та переформатував їх . У 2001 році для визначення OLAP був запропонований більш простий тест FASMI (4 вимоги)^[3].

Як зазначив Е. Кодд, головною причиною розробки OLAP стала невідповідність класичної реляційної моделі даних потребам аналітиків щодо швидкого (online) отримання відповідей на різноманітні евристичні аналітичні запити ^[1]. Реляційні БД зберігають сутності в окремих таблицях, які зазвичай добре нормалізовані - ця структура зручна для операційних БД (транзакційні системи, OLTP - Online Transaction Processing), але складні багатотабличні запити в ній виконуються відносно повільно. Зручнішою моделлю для виконання запитів (але не для внесення змін) є просторова БД. OLAP робить миттєвий знімок реляційної БД і структурує її в просторову модель для запитів. Заявлений час обробки запитів в OLAP становить близько 0,1 % від аналогічних запитів до реляційної БД.^{[джерело?]}

Концепція OLAP

Докладніше: 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

Першим продуктом, що виконував 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.

Примітки

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

[codd_whitepaper-1] а ^б ^в Codd, E. F.; S B Codd; C T Salley (26 липня 1993). Providing OLAP to User-Analysts: An IT Mandate (PDF). Computerworld. Архів оригіналу (PDF) за 8 серпня 2017.

[FOOTNOTESilberschatzKorthSudarshan2011197-2] Silberschatz, Korth та Sudarshan, 2011, с. 197.

[pendse-3] What is OLAP? by Nigel Pendse, Principal of OLAP Solutions and Co-author of the OLAPreport.com, 06.09.2001. Архів оригіналу за 24 грудня 2018. Процитовано 24 грудня 2018.

[FOOTNOTESilberschatzKorthSudarshan2011204-4] Silberschatz, Korth та Sudarshan, 2011, с. 204.

[1]

[2]

[3]

[4]