OLAP

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

OLAP (англ. online analytical processing, аналітична обробка у реальному часі)[1] — це концепція, технологія і засоби багатовимірного аналізу (Multidimensional analysis, MDA), що полягають у отримуванні аналітиком відповідей на свої різноманітні запити у online режимі у формі зведених таблиць, зведених діаграм (карт) та зведених схем - на основі даних зі сховища даних (Data Warehouse) чи з кіоску або вітрини даних (Data Mart). OLAP є автономною але не достатньою частиною Business intelligence  та Business Analytics Software і потребує також Data Mining, ін. [3] . Активно використовується у будь-яких областях аналізу числової та короткої лінгвістичної інформації, приведеної до табличної форми (підготовка бізнес-звітів з продажів, маркетингу, аналізу телекомунікаційної інформації, банківської інформації, медичної інформації, результатів виробництва, правової інформації, веб-аналізу, для потреб управління, фінансової звітності, ін.). OLAP також корисна для аналізу оцінок багатьох експертів по багатьом показникам, які можуть бути рознесеними у просторі і часі [4] [5].

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

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

У зв`язку зі значним збільшенням швидкодії та пам`яті комп`ютерів стають популярними OLAP на основі реляційних баз даних (ROLAP, Relation OLAP), які використовують спеціальні схеми даних Star Schema (схема "зірка"), а також Snowlake Schema (схема "сніжинка") і у деяких випадках їх можна використовувати для сховища даних (Data Warehouse) - це значно спрощує і здешевлює аналітичну систему [5] [3] [6].

Концепція OLAP[ред. | ред. код]

Докладніше: OLAP-куб

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

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

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

Концептуально OLAP є автономною, але не самодостатньою частиною Business Intelligence і повинен використовуватися у комплексі з іншими аналітичними підсистемами [7] [6].

Типи[ред. | ред. код]

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

  • 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» заявляють про більшу масштабованість їх продуктів в плані підтримки дуже великих обсягів даних.

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

Примітки[ред. | ред. код]

  1. а б в Codd E.F., Codd S.B., and Salley C.T. (1993). "Providing OLAP (On-line Analytical Processing) to UserAnalysts: An IT Mandate". Codd & Date, Inc. Date of Entry: 09/23/93. [Електронний ресурс] -20
  2. Dr. E. F. Codd's 12 rules for defining a fully relational database. [Електронний ресурс] – 2008 - Режим доступу: http://www.cse.ohio-state.edu/~sgomori/570/coddsrules.html
  3. а б в г д Круковський І. А. Удосконалені вимоги до реалізації olap у DSS для часткових проблемних областей інформаційно-аналітичної роботи / І. А. Круковський // Військово-технічний збірник. - 2010. - Вип. 3. - С. 26-33. - Режим доступу: http://nbuv.gov.ua/UJRN/vtzb_2010_3_8.
  4. What is OLAP? by Nigel Pendse, Principal of OLAP Solutions and Co-author of the OLAPreport.com, 06.09.2001
  5. Bill Inmon. When Are Star Schemas Okay in a Data Warehouse?
  6. а б в Круковський І.А. Узагальнена архітектура системи підтримки прийняття рішень на основі Business Intelligence у розширеному тлумаченні / І.А. Круковський // Вісник ЖДТУ. – 2010. – Вип. 2 (53). – С. 103-111.
  7. Круковський, Ігор (01.01.2011 р.). Головна сторінка сайту Business Intelligence+KMS (Knowledge Management System). Business Intelligence+KMS (українська). Круковський І.А. Процитовано 23.12.18 р..