On—Line Transaction Processing

 

ВСТУП

 

 

Важко знайти в комп'ютерному світі людини, яка хоча б на інтуїтивному рівні не розуміла, що таке бази даних  і навіщо вони потрібні. На відміну  від традиційних реляційних СУБД, концепція OLAP не так широко відома, хоча загадковий термін «OLAP» чули, напевно, майже всі. Що ж таке OnLine Analytical Processing, де він мешкає, і з чим його їдять, ми і спробуємо розібратися.

OLAP — це не окремо взятий програмний продукт, не мова програмування і навіть не конкретна технологія. Якщо постаратися охопити OLAP у всіх його проявах, то це сукупність концепцій, принципів і вимог, що лежать в основі програмних продуктів, що полегшують аналітикам доступ до даних. Незважаючи на те, що з таким визначенням навряд хтось не погодиться, сумнівно, щоб воно хоч на йоту наблизило неспеціалістів до розуміння що таке OLAP. Тому в своєму прагненні до пізнання OLAP ми підемо іншим шляхом. Для початку ми з'ясуємо, навіщо аналітикам треба якось спеціально полегшувати доступ до даних.

Справа  в тому, що аналітики — це особливі споживачі корпоративної інформації. Завдання аналітика — знаходити закономірності у великих масивах даних. Тому аналітик не буде звертати уваги на окремо взятий факт, що в четвер четвертого числа контрагенту Чернову була продана партія чорних чорнил — йому потрібна інформація про сотні й тисячі подібних подій. Поодинокі факти в базі даних можуть зацікавити, наприклад, бухгалтера або начальника відділу продажів, в компетенції якого знаходиться угода. Аналітику одного запису мало — йому, приміром, можуть знадобитися всі угоди даного філії або представництва за місяць, рік. Заодно аналітик відкидає непотрібні йому подробиці зразок ІПН покупця, його точної адреси і номера телефону, індексу контракту і тому подібного. В той же час дані, які потрібні аналітику для роботи, обов'язково містять числові значення — це обумовлено самою сутністю його діяльності або інформація начебто, десь і є, її навіть забагато, але вона не структурованості, не узгоджена, розрізнена, не завжди достовірна, її практично неможливо знайти і отримати, для вирішення всіх цих проблем застосовують OLAP системи.

РОЗДІЛ 1

КОНЦЕПЦІЯ СХОВИЩ ДАНИХ ТА ЇЇ ЗАСТОСУВАННЯ В АНАЛІТИЧНИХ ІНФОРМАЦІЙНИХ СИСТЕМАХ (OLAP)

 

1.1 Концепція сховища даних

 

OLAP (On—Line Transaction Processing) — системи оперативної аналітичної обробки, які призначені для підтримки прийняття рішень і орієнтовані головним чином на нерегламентовані запити. Термін OLAP дозволяє описувати технологію обробки даних, в якій застосовується багатомірне представлення агрегованих даних для забезпечення швидкого доступу до даних для поглибленого аналізу.

Концепція сховища даних визначає процес збору, відсіювання, попередньої обробки  та накопичення даних з метою

— довготривалого зберігання даних ;

— надання результуючої інформації користувачам в зручній формі для статистичного аналізу та створення аналітичних звітів .

Концепція OLAP — це концепція комплексного багатомірного аналізу даних, накопичених у сховищі. Теоретично засоби OLAP можна застосовувати і безпосередньо до оперативними даними або їх точним копіям (щоб не заважати оперативним користувачам). Але в цьому випадку ми ризикуємо наступити на свої граблі, оскільки беремося аналізувати оперативні дані, які безпосередньо для аналізу непридатні.

Зауваження: термін OLAP дуже популярний в даний час і OLAP—системою часто називають будь—яку DSS—систему, засновану на концепції сховищ даних і забезпечують малий час виконання (On—Line) аналітичних запитів, не залежно від того, чи використовується багатовимірний аналіз даних. Що не зовсім вірно.

Концепція інтелектуального аналізу даних визначає завдання пошуку функціональних і логічних закономірностей у накопиченій інформації, побудова моделей і правил, які пояснюють знайдені аномалії та / або прогнозують розвиток деяких процесів.

Зразок  структури інформаційно—аналітичної системи, побудованої на основі сховища даних, показана нижче. У конкретних реалізаціях окремі компоненти цієї схеми часто відсутні.

 

Рис. 1.1 Зразок структури інформаційно—аналітичної системи

 

Яка спонукальна причина поява концепції  сховищ даних?

Здавалося б, навіщо будувати сховища даних  — адже вони містять завідомо надлишкову інформацію, яка і так є в базах або файлах оперативних систем? Відповісти можна коротко: аналізувати дані оперативних систем безпосередньо неможливо або дуже важко. Це пояснюється рядом причинами, в тому числі

— розрізненістю даних (OLTP—системи, текстові звіти, xls—файли);

— зберіганням їх у форматах різних СУБД і в різних вузлах корпоративної мережі.

Але навіть якщо на підприємстві всі дані зберігаються на центральному сервері БД (що буває вкрай рідко), аналітик майже напевно не розбереться в їх складних, часом заплутаних структурах.

Є і ще одна причина, що виправдує появу  окремого сховища — складні аналітичні запити до оперативної інформації гальмують поточну роботу компанії, надовго блокуючи таблиці і захоплюючи ресурси сервера.

Можна констатувати, що практично в будь—якій організації склалася парадоксальна ситуація: — інформація начебто, десь і є, її навіть забагато, але вона неструктурованість, неузгоджена, розрізнена, не завжди достовірна, її практично неможливо знайти і отримати. В результаті можна говорити про відсутність інформації за наявності і навіть надлишку.

Для того, щоб витягувати корисну інформацію з даних, вони повинні бути організовані способом, відмінним від прийнятого в OLTP—системах Чому?

У OLTP—системах використовуються нормалізовані таблиці бази даних. Нормалізація ефективна, якщо відносини часто перебудовуються, але дає негативний ефект у разі операції вибірки (особливо у разі складних запитів). А в DSS—системах лише операції вибірки, і дані рідко змінюються, тому дані доцільно зберігати у вигляді слабо нормалізованих відносин, що містять заздалегідь обчислені основні підсумкові дані. Велика надмірність і пов'язані з нею проблеми тут не страшні, тому оновлення відбувається тільки в момент завантаження нової порції даних. При цьому відбувається як додавання нових даних, так і перерахунок підсумків.

Виконання деяких аналітичних запитів вимагає  хронологічній впорядкованості  даних. Реляційна модель не передбачає існування порядку записів в таблицях.

У разі аналітичних запитів частіше  використовуються не детальні, а узагальнені (агреговані дані).

В результаті дані, застосовувані для  аналізу, стали виділяти в окремі спеціальні бази даних, що згодом отримали назву сховищ даних (Data Warehouse).

Сховище даних (визначення Білла Інмона (Bill Inmon)) — предметно—орієнтований, інтегрований, прив'язаний до часу і незмінний набір даних, призначений для підтримки прийняття рішень. Базові вимоги до сховища даних:

— Орієнтація на предметну область. Сховище повинно розроблятися з урахуванням специфіки предметної області (клієнти, товари, продажу), а не прикладних областей діяльності (виписка рахунків, контроль запасів, продаж товарів).

— Інтегрованість і внутрішня несуперечність. Оскільки дані в сховищі надходять з різних джерел (OLTP—системи, архіви та інше), необхідно привести їх до єдиного формату (дата: 5 січня, 5.01, :). У процесі завантаження сховища повинна бути забезпечена, очищення та узгодженість даних.

— Прив'язка до часу. Облік хронології досягається введенням атрибутів «Дата» та «Час». Впорядкування по цим атрибутам дозволяє скоротити час виконання аналітичних запитів.

— Незмінюваність. Дані не оновлюються в оперативному режимі, а лише регулярно поповнюються з систем оперативної обробки по заданій дисципліні.

— Підтримка високої швидкості отримання даних зі сховища.

— Можливість отримання і порівняння так званих зрізів даних (slice and dice);

— Повнота і достовірність даних, що зберігаються;

— Підтримка якісного процесу поповнення даних.

1.2 OLAP — основні відомості

 

Термін OLAP був запропонований в 1993 р. Едвардом Коддом (E. Codd — автор реляційної моделі даних) За Коду OLAP—технологія — це технологія комплексного динамічного синтезу, аналізу та консолідації великих обсягів багатовимірних даних. Він же сформулював 12 принципів OLAP, які пізніше були перероблено в так званий тест FASMI:

— Fast (швидкий) — надання користувачу результатів аналізу за прийнятний час (зазвичай не більше 5 с), нехай навіть ціною менш детального аналізу;

— Analysis (аналіз) — можливість здійснення будь—якого логічного та статистичного аналізу, характерного для даного додатка, і його збереження в доступному для кінцевого користувача вигляді;

— Shared (що розділяється) — багатокористувацький доступ до даних з підтримкою відповідних механізмів блокувань і засобів авторизованого доступу;

— Multidimensional (багатовимірної) — багатовимірне концептуальне уявлення даних, включаючи повну підтримку ієрархій та множинних ієрархій (ключова вимога OLAP);

— Information (інформації) — можливість звертатися до будь—якої потрібної інформації незалежно від її обсягу та місця зберігання.

У найзагальнішому вигляді OLAP = багатовимірне  представлення = куб

OLAP—технологія являє для аналізу дані у вигляді багатовимірних (і, отже, не реляційних) наборів даних, званих багатовимірними кубами (гіперкуб, мета куб, кубом фактів), осі якого містять параметри, а осередки — залежні від них агрегатні дані.

При тому гіперкуб є концептуальною логічною моделлю організації даних, а не фізичною реалізацією їх зберігання, оскільки зберігатися такі дані можуть і в реляційних таблицях («реляційні БД були, є і будуть найбільш придатною технологією для зберігання корпоративних даних» — E. Codd).

По  Кодду, багатовимірне концептуальне уявлення (multi—dimensional conceptual view) являє собою множинну перспективу, що складається з декількох незалежних вимірів, уздовж яких можуть бути проаналізовані певні сукупності даних. Одночасний аналіз по декількох вимірах визначається як багатовимірний аналіз. Осями багатовимірної системи координат служать основні атрибути аналізованого бізнес—процесу (те, по чому ведеться аналіз). Наприклад, для продажу це можуть бути тип товару, регіон, тип покупця. В якості одного з вимірів використовується час. На перетинах осей — вимірів (dimensions) — знаходяться дані, що кількісно характеризують процес — заходи (measures): суми та інші агрегатні функції (min, max, avg, дисперсія, ср відхилення і пр.). Кожен вимір включає напрямки консолідації даних, що складаються із серії послідовних рівнів узагальнення (рівнів ієрархії), де кожен вищестоящий рівень відповідає більшому ступені агрегації даних по відповідному вимірюванню (різні рівні їх деталізації). У цьому випадку стає можливим довільний вибір бажаного рівня деталізації інформації по кожному з вимірів.

 

Рис. 1.2 Багатовимірне концептуальне уявлення за Коддом

 

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

Приклад. Тривимірний куб, де в якості фактів використані суми продажів, а в якості вимірювань — час, товар і магазин, визначених на різних рівнях угруповання: товари групуються за категоріями, магазини — по країнах, а дані про час здійснення операцій — по місяцях.

 

Рис. 1.3 Тривимірний куб

 

Значення, «відкладені» уздовж вимірювань, називаються членами або мітками (members). Мітки використовуються в операціях маніпулювання вимірами.

Мітки можуть об'єднуватися в ієрархії, що складаються з одного або декількох  рівнів деталізації (levels). Наприклад, мітки виміру «Магазин» (Store) природно об'єднуються в ієрархію з рівнями:

All (світ)         

Country (країна)                

State (штат)                    

City (місто)                          

Store (магазин)

У відповідності до рівнів ієрархії обчислюються агрегатні значення, наприклад обсяг продажів для USA (рівень «Country») або для штату California (рівень «State»). В одному вимірі можна реалізувати більше однієї ієрархії — скажімо, для часу: {Рік, Квартал, Місяць, День} і {Рік, Тиждень, День}.

Оскільки  в розглянутому прикладі в загальному випадку в кожній країні може бути кілька міст, а в місті — декілька клієнтів, можна говорити про ієрархіях значень у вимірі — регіон. У цьому випадку на першому рівні ієрархії розташовуються країни, на другому — міста, а на третьому — клієнти.

 

Рис. 1.4 Ієрархія значень у вимірі — регіон.

 

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

Іноді для таких ієрархій використовується термін Parent - child hierarchy.

 

Рис. 1.5 Типовий приклад незбалансованої ієрархії

 

Існують також ієрархії, що займають проміжне положення між збалансованими і незбалансованими (вони позначаються терміном ragged - «нерівний»). Зазвичай вони містять такі члени, логічні «батьки» яких знаходяться не на безпосередньо вищестоящому рівні (наприклад, в географічній ієрархії є рівні Country, City та State, але при цьому в наборі даних є країни, які не мають штатів або регіонів між рівнями Country і City ).

 

Рис. 1.6 Проміжна ієрархія

 

Аналітичні OLAP—операції:

— Перетин. При виконанні операції перетину формується підмножина гіперкуба, в якому значення одного або більше вимірів фіксовано (значення параметрів для фіксованого, наприклад, місяця).

— Обертання (rolling). Операція обертання змінює порядок подання вимірювань, забезпечуючи уявлення мета куба в більш зручній для сприйняття формі.