OLAP

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

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

Цю статтю треба вікіфікувати для відповідності стандартам якості Вікіпедії. Будь ласка, допоможіть додаванням доречних внутрішніх посилань або вдосконаленням розмітки статті. (січень 2019)

Як зазначив Е. Кодд, головною причиною розробки 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.

Примітки

  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.
  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. Архів оригіналу за 24 грудня 2018. Процитовано 24 грудня 2018.
  4. Silberschatz, Korth та Sudarshan, 2011, с. 204.


  • п
  • о
  • р
 
Створення сховища даних
Концепції
Варіанти
  • Якірне моделювання[en]
  • Стовпчикова система керування базами даних[en]
  • Data vault[en]
  • HOLAP
  • MOLAP
  • ROLAP
  • Operational data store
Елементи
Факт
Заповнення
 
Використання сховища даних
Концепції
Мови
  • Data Mining Extensions (DMX)[en]
  • MultiDimensional eXpressions (MDX)[en]
  • XML for Analysis (XMLA)[en]
Інструменти
 
Пов'язані
Особи
  • Білл Інмон[en]
  • Ралф Кімбол[en]
Продукти
  • Порівняння OLAP-серверів[en]