OLAP технології. Аналітичні системи OLAP Інформаційні технології аналізу даних olap

Умови високої конкуренції та динаміки зовнішнього середовища диктують підвищені вимоги до систем управління підприємства. Розвиток теорії та практики управління супроводжувалися появою нових методів, технологій та моделей, орієнтованих на підвищення ефективності діяльності. Методи та моделі у свою чергу сприяли появі аналітичних систем. Затребуваність аналітичних систем у Росії – висока. Найцікавіші з погляду застосування ці системи у фінансовій сфері: банки, страховий бізнес, інвестиційні компанії. Результати роботи аналітичних систем потрібні насамперед людям, від вирішення яких залежить розвиток компанії: керівникам, експертам, аналітикам. Аналітичні системи дозволяють вирішувати завдання консолідації, звітності, оптимізації та прогнозування. До теперішнього часу не склалося остаточної класифікації аналітичних систем, як і немає загальної системи визначень у термінах, що використовуються в даному напрямку. Інформаційна структура підприємства може бути представлена послідовністю рівнів, кожен з яких характеризується своїм способом обробки та управління інформацією, та має свою функцію у процесі управління. Таким чином, аналітичні системи будуть розташовуватися ієрархічно на різних рівнях цієї інфраструктури.

Рівень трансакційних систем

Рівень сховищ даних

Рівень вітрин даних

Рівень OLAP – систем

Рівень аналітичних програм

OLAP - системи - (OnLine Analytical Processing, аналітична обробка в теперішньому часі) - є технологією комплексного багатовимірного аналізу даних. OLAP - системи застосовні там, де є завдання аналізу багатофакторних даних. Є ефективним засобом аналізу та генерації звітів. Розглянуті вище сховища даних, вітрини даних та OLAP – системи відносяться до систем бізнес – інтелекту (Business Intelligence, BI).

Найчастіше інформаційно-аналітичні системи, створювані для безпосереднього використання особами, які приймають рішення, виявляються надзвичайно прості у застосуванні, але жорстко обмежені у функціональності. Такі статичні системи називаються в літературі Інформаційними системами керівника (ІСР) або Executive Information Systems (EIS). Вони містять у собі зумовлені безлічі запитів і, будучи достатніми для повсякденного огляду, нездатні відповісти на всі питання до наявних даних, які можуть виникнути при прийнятті рішень. Результатом роботи такої системи зазвичай є багатосторінкові звіти, після ретельного вивчення яких у аналітика з'являється нова серія питань. Однак кожен новий запит, непередбачений при проектуванні такої системи, повинен спочатку формально описаний, закодований програмістом і тільки потім виконаний. Час очікування у такому разі може становити години та дні, що не завжди прийнятно. Таким чином, зовнішня простота статичних СППР, яку активно бореться більшість замовників інформаційно-аналітичних систем, обертається катастрофічної втратою гнучкості.

Динамічні СППР, навпаки, спрямовані на обробку нерегламентованих (ad hoc) запитів аналітиків до даних. Найбільш глибоко вимоги до таких систем розглянув E. F. Codd у статті, що започаткувала концепцію OLAP. Робота аналітиків із цими системами полягає в інтерактивній послідовності формування запитів та вивчення їх результатів.

Але динамічні СППР можуть діяти у області оперативної аналітичної обробки (OLAP); Підтримка прийняття управлінських рішень на основі накопичених даних може виконуватись у трьох базових сферах.

Сфера деталізованих даних. Це область впливу більшості систем, орієнтованих на пошук інформації. Найчастіше реляційні СУБД добре справляються з які виникають тут завданнями. Загальновизнаним стандартом мови маніпулювання реляційними даними є SQL. Інформаційно-пошукові системи, що забезпечують інтерфейс кінцевого користувача в задачах пошуку деталізованої інформації, можуть використовуватися як надбудови як над окремими базами даних транзакційних систем, так і над загальним сховищем даних.

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

Сфера закономірностей. Інтелектуальна обробка проводиться методами інтелектуального аналізу даних (ІАД, Data Mining), головними завданнями яких є пошук функціональних та логічних закономірностей у накопиченій інформації, побудова моделей та правил, які пояснюють знайдені аномалії та/або прогнозують розвиток деяких процесів.

Оперативне аналітичне оброблення даних

В основі концепції OLAP лежить принцип багатовимірного представлення даних. У 1993 році у статті EF Codd розглянув недоліки реляційної моделі, насамперед вказавши на неможливість "об'єднувати, переглядати та аналізувати дані з точки зору множинності вимірювань, тобто найзрозумілішим для корпоративних аналітиків способом", і визначив загальні вимоги до систем OLAP, що розширює функціональність реляційних СУБД і що включає багатовимірний аналіз як одну зі своїх характеристик.

Класифікація продуктів OLAP за способом представлення даних.

В даний час на ринку є велика кількість продуктів, які в тій чи іншій мірі забезпечують функціональність OLAP. Близько 30 найбільш відомих перераховано у списку оглядового Web-сервера http://www.olapreport.com/. Забезпечуючи багатовимірне концептуальне уявлення з боку інтерфейсу користувача до вихідної бази даних, всі продукти OLAP діляться на три класи за типом вихідної БД.

Найперші системи оперативної аналітичної обробки (наприклад, Essbase компанії Arbor Software, Oracle Express Server компанії Oracle) належали до класу MOLAP, тобто могли працювати лише зі своїми власними багатовимірними базами даних. Вони ґрунтуються на патентованих технологіях для багатовимірних СУБД і є найдорожчими. Ці системи забезпечують повний цикл обробки OLAP. Вони або включають, крім серверного компонента, власний інтегрований клієнтський інтерфейс, або використовують для зв'язку з користувачем зовнішні програми роботи з електронними таблицями. Для обслуговування таких систем потрібен спеціальний штат співробітників, які займаються установкою, супроводженням системи, формуванням уявлень даних кінцевих користувачів.

Системи оперативної аналітичної обробки реляційних даних (ROLAP) дозволяють представляти дані, що зберігаються в реляційній базі, в багатовимірній формі, забезпечуючи перетворення інформації в багатовимірну модель через проміжний шар метаданих. ROLAP-системи добре пристосовані до роботи з великими сховищами. Подібно до систем MOLAP, вони вимагають значних витрат на обслуговування фахівцями з інформаційних технологій і передбачають розрахований на багато користувачів режим роботи.

Нарешті, гібридні системи (Hybrid OLAP, HOLAP) розроблені з метою поєднання переваг та мінімізації недоліків, властивих попереднім класам. До цього класу належить Media/MR компанії Speedware. За твердженням розробників, він поєднує аналітичну гнучкість та швидкість відповіді MOLAP з постійним доступом до реальних даних, властивих ROLAP.

Багатовимірний OLAP (MOLAP)

У спеціалізованих СУБД, заснованих на багатовимірному поданні даних, дані організовані над формі реляційних таблиць, а вигляді упорядкованих багатовимірних масивів:

1) гіперкубів (всі зберігаються в БД осередки повинні мати однакову мірність, тобто перебувати в максимально повному базисі вимірів) або

2) полікубів (кожна змінна зберігається з власним набором вимірювань, і всі пов'язані з цим складності обробки перекладаються на внутрішні механізми системи).

Використання багатовимірних БД у системах оперативної аналітичної обробки має такі переваги.

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

Багатовимірні СУБД легко справляються із завданнями включення до інформаційної моделі різноманітних вбудованих функцій, тоді як об'єктивно існуючі обмеження мови SQL роблять виконання цих завдань на основі реляційних СУБД досить складним, а іноді й неможливим.

З іншого боку, є суттєві обмеження.

Багатомірні СУБД не дозволяють працювати з великими базами даних. До того ж за рахунок денормалізації та попередньо виконаної агрегації обсяг даних у багатовимірній базі, як правило, відповідає (за оцінкою Кодда) у 2.5-100 разів меншому обсягу вихідних деталізованих даних.

Багатомірні СУБД у порівнянні з реляційними дуже неефективно використовують зовнішню пам'ять. У переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому вигляді, невизначені значення вдається видалити лише за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані максимально безперервні групи. Але навіть у цьому випадку проблема вирішується лише частково. Крім того, оптимальний з точки зору зберігання розріджених даних порядок сортування швидше за все не співпадатиме з порядком, який найчастіше використовується в запитах. Тому в реальних системах доводиться шукати компроміс між швидкодією та надмірністю дискового простору, зайнятого базою даних.

Отже, використання багатовимірних СУБД виправдано лише за таких умов.

Обсяг вихідних даних для аналізу невеликий (не більше кількох гігабайт), тобто рівень агрегації даних досить високий.

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

Час відповіді системи на нерегламентовані запити є критичним параметром.

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

Реляційний OLAP (ROLAP)

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

Найчастіше корпоративні сховища даних реалізуються засобами реляційних СУБД, і інструменти ROLAP дозволяють проводити аналіз безпосередньо з них. При цьому розмір сховища не є таким критичним параметром як у випадку MOLAP.

У разі змінної розмірності завдання, коли зміни до структури вимірювань доводиться вносити досить часто, ROLAP системи з динамічним уявленням розмірності є оптимальним рішенням, оскільки такі модифікації не вимагають фізичної реорганізації БД.

Реляційні СУБД забезпечують значно вищий рівень захисту даних та хороші можливості розмежування прав доступу.

Головний недолік ROLAP у порівнянні з багатовимірними СУБД – менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних та налаштування індексів, тобто великих зусиль з боку адміністраторів БД. Тільки при використанні зіркоподібних схем продуктивність добре налаштованих реляційних систем може бути наближена до продуктивності систем на основі багатовимірних баз даних.

У 1993 році основоположник реляційного підходу до побудови баз даних Едгар Кодд з партнерами (Edgar Codd, математик і стипендіат IBM), опублікували статтю, ініційовану компанією "Arbor Software" (сьогодні це найвідоміша компанія "Hyperion Solutions"), озаглавлену "Обе аналітичної обробки) для користувачів-аналітиків", у якій сформульовано 12 особливостей технології OLAP, які згодом були доповнені ще шістьма. Ці положення стали основним змістом нової та дуже перспективної технології.

Основні особливості технології OLAP (Basic):

багатовимірне концептуальне представлення даних;
інтуїтивне маніпулювання даними;
доступність та деталізація даних;
пакетне вилучення данихпроти інтерпретації;
моделі аналізу OLAP;
архітектура "клієнт-сервер" (OLAP доступний з робочого столу);
прозорість (прозорий доступ до зовнішніх даних);
розрахована на багато користувачів підтримка.

Спеціальні особливості( Special ):

обробка неформалізованих даних;
збереження результатів OLAP: зберігання їх окремо від вихідних даних;
виключення відсутніх значень;
обробка відсутніх значень.

Особливості подання звітів(Report):

гнучкість формування звітів;
стандартна продуктивність звітів;
автоматичне налаштування фізичного рівня вилучення даних.

Управління вимірами(Dimension):

універсальність вимірів;
необмежену кількість вимірювань та рівнів агрегації;
необмежену кількість операцій між розмірностями.

Історично склалося так, що сьогодні термін "OLAP" має на увазі не тільки багатовимірний погляд на дані з боку кінцевого користувача, але й багатовимірне представлення даних у цільовій БД. Саме з цим пов'язана поява як самостійні терміни "Реляційний OLAP"(ROLAP) та "Багатомірний OLAP"(MOLAP).

OLAP-сервіс є інструментом для аналізу великих обсягів даних у режимі реального часу. Взаємодіючи з OLAP - системою, користувач зможе здійснювати гнучкий перегляд інформації, отримувати довільні зрізи даних та виконувати аналітичні операції деталізації, згортки, наскрізного розподілу, порівняння у часі одночасно за багатьма параметрами. Вся робота з OLAP-системою відбувається в термінах предметної області та дозволяє будувати статистично обґрунтовані моделі ділової ситуації.

Програмні засоби OLAP - це інструмент оперативного аналізу даних, що містяться у сховищі. Головною особливістю є те, що ці кошти орієнтовані на використання не фахівцем у галузі інформаційних технологій, не експертом-статистиком, а професіоналом у прикладній галузі управління – менеджером відділу, департаменту, управління та, нарешті, директором. Кошти призначені для спілкування аналітика з проблемою, а не з комп'ютером. На рис. 6.14 показаний елементарний OLAP-куб, що дозволяє проводити оцінки даних за трьома вимірами.

Багатовимірний OLAP-куб та система відповідних математичних алгоритмів статистичної обробки дозволяє аналізувати дані будь-якої складності на будь-яких часових інтервалах.

Рис. 6.14.

Маючи у своєму розпорядженні гнучкі механізми маніпулювання даними та візуального відображення (рис. 6.15, рис. 6.16), менеджер спочатку розглядає з різних сторін дані, які можуть бути (а можуть і не бути) пов'язані з вирішуваною проблемою.

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

Рис. 6.15.

У керівника фірмою, наприклад, може зародитися гіпотеза у тому, що розкид зростання активів у різних філіях підприємства залежить від співвідношення у яких фахівців із технічним та економічним образованием. Щоб перевірити цю гіпотезу, менеджер може запросити зі сховища і відобразити на графіку його співвідношення для тих філій, у яких за поточний квартал зростання активів знизилося в порівнянні з минулим роком більш ніж на 10%, і для тих, у яких підвищився більш ніж на 25%. Він повинен мати можливість використовувати простий вибір із пропонованого меню. Якщо отримані результати відчутно розпадуться на дві відповідні групи, це має стати стимулом подальшої перевірки висунутої гіпотези.

В даний час швидкий розвиток отримав напрям, званий динамічним моделюванням(Dynamic Simulation), що повною мірою реалізує зазначений вище принцип FASMI.

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

Рис. 6.16.

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

Таблиця 6.3.

Характеристика	Статичний аналіз	Динамічний аналіз
Типи запитань	Хто? Що? Скільки? Як? Коли? Де?	Чому так? Що було б, якщо...? Що буде якщо…?
Час відповіді	Не регламентується	Секунди
Типові операції роботи з даними	Регламентований звіт, діаграма, таблиця, малюнок	Послідовність інтерактивних звітів, діаграм, екранних форм. Динамічна зміна рівнів агрегації та зрізів даних
Рівень аналітичних вимог	Середній	Високий
Тип екранних форм	В основному визначений заздалегідь регламентований	Визначається користувачем, є можливості налаштування
Рівень агрегації даних	Деталізовані та сумарні	Визначається користувачем
"Вік" даних	Історичні та поточні	Історичні, поточні та прогнозовані
Типи запитів	В основному, передбачувані	Непередбачувані - час від часу
Призначення	Регламентована аналітична обробка	Багатопрохідний аналіз, моделювання та побудова прогнозів

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

OLAP застосовується скрізь, де є завдання аналізу багатофакторних даних. Взагалі, за наявності деякої таблиці з даними, у якій є хоча б одна описова колонка та одна колонка з цифрами, OLAP-інструмент буде ефективним засобом аналізу та генерації звітів. Як приклад застосування OLAP-технології розглянемо дослідження результатів процесу продажу.

Ключові питання "Скільки продано?", "На яку суму продано?" розширюються в міру ускладнення бізнесу та накопичення історичних даних до деякої множини факторів, або розрізів: ".. у Санкт-Петербурзі, в Москві, на Уралі, в Сибіру ...", ".. у минулому кварталі, в порівнянні з нинішнім", " ..від постачальника А проти постачальником Б…" тощо.

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

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

Час. Як правило, це кілька періодів: Рік, Квартал, Місяць, Декада, Тиждень, День. Багато інструментів OLAP автоматично обчислюють старші періоди з дати і обчислюють результати по них.

Категорія товару. Категорій може бути кілька, вони відрізняються для кожного виду бізнесу: Сорт, Модель, Вид упаковки та ін. Якщо продається тільки один товар або асортимент дуже невеликий, то категорія не потрібна

Товар. Іноді використовуються назва товару (або послуги), його код або артикул. У тих випадках, коли асортимент дуже великий (а деякі підприємства мають десятки тисяч позицій у своєму прайс-листі), початковий аналіз з усіх видів товарів може не проводитися, а узагальнюватись до деяких узгоджених категорій.

Регіон. Залежно від глобальності бізнесу можна на увазі Континент, Група країн, Країна, Територія, Місто, Район, Вулиця, Частина вулиці. Звичайно, якщо є лише одна торгова точка, то цей вимір відсутній.

Продавець. Цей вимір також залежить від структури та масштабів бізнесу. Тут може бути: Філія, Магазин, Дилер, Менеджер з продажу. У деяких випадках вимір відсутній, наприклад, коли продавець не впливає на обсяги збуту, магазин лише один і так далі.

Покупець. У деяких випадках, наприклад, у роздрібній торгівлі, покупець знеособлений і вимір відсутня, в інших випадках інформація про покупця є, і вона важлива для продажу. Цей вимір може містити назву фірми-покупця або безліч угруповань і характеристик клієнтів: Галузь, Група підприємств, Власник і так далі. Аналіз структури продажів для виявлення найважливіших складових у розрізі, що цікавить. Для цього зручно використовувати, наприклад, діаграму типу "Пиріг" у складних випадках, коли досліджується відразу 3 виміри - "Стовпці". Наприклад, у магазині "Комп'ютерна техніка" за квартал продаж комп'ютерів склали $100000, фототехніки -$10000, витратних матеріалів - $4500. Висновок: оборот магазину залежить великою мірою від продажу комп'ютерів (насправді, можливо, витратні матеріали необхідні для продажу комп'ютерів, але це вже аналіз внутрішніх залежностей).

Аналіз динаміки ( регресійний аналіз- Виявлення трендів). Виявлення тенденцій, сезонних коливань. Наочно динаміку відображає графік типу "Лінія". Наприклад, обсяги продажів продуктів компанії Intel протягом року знижувалися, а обсяги продажів Microsoft зростали. Можливо, покращився добробут середнього покупця, або змінився імідж магазину, а з ним і склад покупців. Потрібно провести коригування асортименту. Інший приклад: протягом 3 років узимку знижується обсяг продажу відеокамер.

Аналіз залежностей(Кореляційний аналіз). Порівняння обсягів продажу різних товарів у часі для виявлення необхідного асортименту – "корзини". Для цього зручно використовувати графік типу "Лінія". Наприклад, при видаленні з асортименту принтерів протягом перших двох місяців виявилося падіння продажів картриджів із порошком.

Основні особливості технології OLAP (Basic):

багатовимірне концептуальне представлення даних;
інтуїтивне маніпулювання даними;
доступність та деталізація даних;
пакетне вилучення даних проти інтерпретації;
моделі аналізу OLAP;
архітектура "клієнт-сервер" (OLAP доступний із робочого столу);
прозорість (прозорий доступ до зовнішніх даних);
розрахована на багато користувачів підтримка.

Спеціальні особливості (Special):

обробка неформалізованих даних;
збереження результатів OLAP: зберігання їх окремо від вихідних даних;
виключення відсутніх значень;
обробка відсутніх значень.

Особливості подання звітів (Report):

гнучкість формування звітів;
стандартна продуктивність звітів;
автоматичне налаштування фізичного рівня вилучення даних.

Управління вимірами (Dimension):

універсальність вимірів;
необмежену кількість вимірювань та рівнів агрегації;
необмежену кількість операцій між розмірностями.

Історично склалося так, що сьогодні термін "OLAP" має на увазі не тільки багатовимірний погляд на дані з боку кінцевого користувача, але й багатовимірне представлення даних у цільовій БД. Саме з цим пов'язана поява як самостійні терміни "Реляційний OLAP" (ROLAP) і "Багатомірний OLAP" (MOLAP).

OLAP-сервіс є інструментом для аналізу великих обсягів даних у режимі реального часу. Взаємодіючи з OLAP-системою, користувач зможе здійснювати гнучкий перегляд інформації, отримувати довільні зрізи даних та виконувати аналітичні операції деталізації, згортки, наскрізного розподілу, порівняння в часі одночасно за багатьма параметрами. Вся робота з OLAP-системою відбувається в термінах предметної області та дозволяє будувати статистично обґрунтовані моделі ділової ситуації.

Програмні засоби OLAP – це інструмент оперативного аналізу даних, що містяться у сховищі. Головною особливістю є те, що ці кошти орієнтовані на використання не фахівцем у галузі інформаційних технологій, не експертом-статистиком, а професіоналом у прикладній галузі управління – менеджером відділу, департаменту, управління та, нарешті, директором. Кошти призначені для спілкування аналітика з проблемою, а не з комп'ютером. На рис. 6.14 показаний елементарний OLAP-куб, що дозволяє проводити оцінки даних за трьома вимірами.

Рис. 6.14.Елементарний OLAP-куб

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

Рис. 6.15.

В даний час швидкий розвиток отримав напрямок, званий динамічним моделюванням (Dynamic Simulation), що повною мірою реалізує зазначений вище принцип FASMI.

Рис. 6.16.Аналітична ІС вилучення, обробки даних та подання інформації

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

Ціль доповіді

У цій доповіді йтиметься про одну з категорій інтелектуальних технологій, які є зручним аналітичним інструментом – OLAP-технологіями.

Мета доповіді: розкрити та висвітлити 2 питання: 1) поняття OLAP та їх прикладне значення у фінансовому управлінні; 2) реалізація OLAP-функціональності у програмних рішеннях: відмінності, можливості, переваги, недоліки.

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

Управління фінансами

Управління фінансами – область, у якій ні в якій іншій важливий аналіз. Будь-яке фінансово-управлінське рішення виникає як результат певних аналітичних процедур. Сьогодні управління фінансами набуває значної ролі для успішного функціонування підприємства. Незважаючи на те, що фінансовий менеджмент є допоміжним процесом на підприємстві, він потребує особливої уваги, оскільки помилкові фінансово-управлінські рішення можуть призвести до великих втрат.

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

Мабуть, важко визначити рівень максимальної ефективності використання ресурсів, але в будь-якому випадку,

Фінансовий директор завжди повинен знати:

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

Щоб отримувати обґрунтовані відповіді на ці питання необхідно мати, аналізувати та знати як аналізувати досить велику кількість показників діяльності. Крім того, ФУ охоплює величезну кількість областей: аналіз грошових потоків (руху коштів), аналіз активів та пасивів, аналіз прибутковості, маржинальний аналіз, аналіз рентабельності, асортиментний аналіз.

Знання

Тому ключовим фактором ефективності процесу управління фінансами є наявність знань:

Особисті знання у предметній галузі (можна сказати теоретико-методологічні), включаючи досвід, інтуїцію фінансиста/фінансового директора
Загальні (корпоративні) знання або систематизована інформація про факти здійснення фінансових операцій на підприємстві (тобто інформація про минуле, сьогодення та майбутній стан підприємства, представлена в різних показниках та вимірах)

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

Що є зараз

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

За результатами дослідження, проведеного фірмою ReutersСеред 1300 міжнародних менеджерів, 38% опитаних стверджують, що витрачають багато часу, намагаючись знайти потрібну інформацію. Виходить, що висококваліфікований фахівець витрачає високооплачуваний час не так на аналіз даних, але в збір, пошук і систематизацію необхідної цього аналізу інформації. У той самий час менеджери відчувають важке завантаження даними, які часто не мають жодного відношення до справи, що знову ж таки знижує ефективність їхньої роботи. Причина такої ситуації: надлишок інформації та нестача знань.

Що треба робити

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

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

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

Базові поняття OLAP-технологій

OLAP-технології (від англ. On-Line Analytical Processing) – це назва конкретного продукту, а цілої технології оперативного аналізу багатовимірних даних, накопичених у сховище. Для того, щоб зрозуміти сутність OLAP, необхідно розглянути традиційний процес отримання інформації для прийняття рішень.

Традиційна система підтримки прийняття рішень

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

Але такий спосіб підтримки прийняття рішень позбавлений гнучкості та має багато недоліків:

використовується дуже мала кількість даних, які можуть бути корисні для прийняття рішень
іноді створюються складні багатосторінкові звіти, з яких реально використовуються 1-2 рядки (інше – про всяк випадок) – інформаційне навантаження
повільна реакція процесу на зміни: якщо необхідне нове подання даних, то запит має бути формально описаний та закодований програмістом, лише потім виконаний. Час очікування: години, дні. А можливе рішення необхідне зараз, негайно. Адже після отримання нової інформації, виникне нове питання (уточнююче)

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

Багато компаній створюють прекрасні реляційні бази даних, ідеально розклавши по поличках гори інформації, яка сама по собі не забезпечує ні швидкої, ні досить грамотної реакції на ринкові події. ТАК – реляційні БД були, є і будуть найбільш підходящою технологією для зберігання корпоративних даних. Йдеться не про нову технологію БД, а, швидше, про інструментальні засоби аналізу, що доповнюють функції існуючих СУБД і досить гнучкі, щоб передбачити та автоматизувати різні види інтелектуального аналізу, притаманні OLAP.

Розуміння OLAP

Що надає OLAP?

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

Для отримання ефекту від використання OLAP-технологій необхідно: 1) розуміти сутність самих технологій та їх можливості; 2) чітко визначитися, які процеси необхідно аналізувати, якими показниками вони будуть характеризуватись і в яких вимірах їх доцільно бачити, тобто створити модель аналізу.

Базові поняття, якими оперують OLAP-технології, є:

Багатовимірність

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

Ці дані представлені у двох вимірах:

стаття
бізнес-одиниця

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

На малюнку видно 3-й вимір, Час, на додаток до перших двох. (Стаття, бізнес-одиниця)

Інший спосіб показати багатовимірні дані - це уявити їх у формі куба:

OLAP-куби дозволяють аналітикам отримувати дані на різних зрізах для отримання відповідей на питання, які ставить бізнес:

Які витрати у яких бізнес-одиницях критичні?
Як змінюються витрати бізнес-одиниць у часі?
Як змінюються статті витрат у часі?

Відповіді на такі питання необхідні для прийняття управлінських рішень: про скорочення певних статей витрат, вплив на їхню структуру, виявлення причин змін витрат у часі, відхилень від плану та їх ліквідація – оптимізація їхньої структури.

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

Зазвичай OLAP-додатки дозволяють отримувати дані за 3 і більше вимірами, наприклад, можна додати ще один вимір – План-Факт, Категорія витрат: прямі, непрямі, Замовлення, Місяці. Додаткові вимірювання дозволяють отримувати більше аналітичних зрізів та забезпечують відповіді на питання з декількома умовами.

Ієрархічність

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

Наприклад, витрати доцільно згрупувати ієрархічно:

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

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

Зміна напрямків аналізу у кубі (обертання даних)

Як правило, оперують поняттями: виміри, задані в стовпцях, рядках (їх може бути кілька), інші формують зрізи, зміст таблиці формують розмірності (продажу, витрати, кошти)

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

Відображення даних куба залежить від:

орієнтації вимірів: які виміри задані у рядках, стовпцях, зрізах;
груп показників, виділених у рядках, стовпцях, зрізах.
Зміна вимірювань лежить у діях користувача.

Таким чином, OLAP дозволяє проводити різні види аналізу та розуміти їх взаємозв'язки їхніх результатів.

Аналіз відхилень – аналіз виконання плану, який доповнюється факторним аналізом причин відхилень шляхом деталізації показників.
Аналіз залежностей: OLAP дозволяє виявляти різні залежності між різними змінами, наприклад при видаленні з асортименту пива протягом перших двох місяців виявилося падіння продажів вобли.
Зіставлення (порівняльний аналіз). Порівняння результатів зміни показника у часі, для заданої групи товарів, у різних регіонах та інших.
Аналіз динаміки дає змогу виявити певні тенденції зміни показників у часі.

Оперативність: можна сказати, що в основу OLAP покладено закони психології: можливість обробки інформаційних запитів у реальному часі - в темпі процесу аналітичного осмислення даних користувачем.

Якщо з реляційної бази даних можна рахувати близько 200 записів на секунду і записати 20, то хороший OLAP-сервер, використовуючи розрахункові рядки та стовпці, може консолідувати 20 000-30 000 осередків (еквівалентно одному запису в реляційній базі даних) за секунду.

Наочність: Слід підкреслити, що OLAP надає розвинені засоби графічного представлення даних кінцевого користувача. Людський мозок здатний сприймати та аналізувати інформацію, яка представлена у вигляді геометричних образів, в обсязі на кілька порядків більшому, ніж інформацію, представлену в алфавітно-цифровому вигляді. Приклад: Нехай Вам потрібно знайти знайоме обличчя на одній із ста фотографій Я вважаю, що цей процес займе у Вас трохи більше хвилини. А тепер уявіть собі, що замість фотографій вам запропонують сто словесних описів тих самих осіб. Думаю, що Вам взагалі не вдасться вирішити запропоноване завдання.

Простота: Головною особливістю цих технологій є те, що вони орієнтовані на використання не фахівцем у галузі інформаційних технологій, не експертом-статистиком, а професіоналом у прикладній галузі – менеджером кредитного відділу, менеджером бюджетного відділу, нарешті, директором. Вони призначені для спілкування аналітика із проблемою, а не з комп'ютером.

Незважаючи на великі можливості OLAP (крім того, ідея порівняно давня – 60-ті роки) реальне застосування практично не зустрічається на наших підприємствах. Чому?

відсутня інформація або не зрозумілі можливості
звичка мислити двовимірно
ціновий бар'єр
надмірна технологічність статей, присвячених OLAP: відлякують незвичні терміни – OLAP, «розкопка та зрізи даних», «нерегламентовані запити», «виявлення істотних кореляцій»

Наш підхід та західний до застосування OLAP

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

Наші та російські автори різних матеріалів, присвячених OLAP, висловлюють таку думку щодо корисності OLAP: більшість сприймає OLAP як такий інструмент, який дозволяє розгортати та згортати дані просто та зручно, здійснюючи маніпуляції, які приходять аналітику в голову в процесі аналізу. Чим більше «зрізів» та «розрізів» даних аналітик бачить, тим більше у нього ідей, які, у свою чергу, для перевірки вимагають нових і нових «зрізів». Це не правильно.

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

Прикладне використання OLAP

Бюджет
Рух грошових коштів

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

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

Фінансова та управлінська звітність (з аналітикою, яка потрібна керівництву)
Маркетинг
Balanced Scorecard
Аналіз прибутковості

За наявності відповідних даних можна знайти різну програму OLAP-технології.

OLAP-продукти

У цьому розділі мова йде про OLAP як про програмне рішення.

Загальні вимоги до OLAP-продуктів

Є багато шляхів реалізації OLAP додатків, то жодна конкретна технологія не повинна бути обов'язковою, або навіть рекомендованою. За різних умов і обставин один підхід може бути кращим за інший. Техніка реалізації включає багато різних патентованих ідей, якими так пишаються постачальники: різновиди архітектури «клієнт-сервер», аналіз часових рядів, об'єктна орієнтація, оптимізація зберігання даних, паралельні процеси тощо. Але ці технології не можуть бути частиною визначення OLAP.

Є характеристики, які мають дотримуватися у всіх OLAP-продуктах (якщо це OLAP-продукт), у яких і полягає ідеал технології. Це 5 ключових визначень, що характеризують OLAP (так званий тест FASMI): Швидкий Аналіз Розділеної Багатомірної інформації.

Швидкий(FAST) – означає, що система має забезпечувати видачу більшості відповідей користувачам у межах приблизно п'яти секунд. Навіть якщо система попередить, що процес триватиме істотно довше, користувачі можуть відволіктися і втратити думку, при цьому якість аналізу страждає. Таку швидкість не просто досягти з великою кількістю даних, особливо, якщо потрібні спеціальні обчислення «на льоту». Постачальники вдаються до широкого розмаїття методів, щоб досягти цієї мети, включаючи спеціалізовані форми зберігання даних, великі попередні обчислення, або ж посилюючи апаратні вимоги. Проте повністю оптимізованих рішень на сьогоднішній день немає. На перший погляд може здаватися дивним, що при отриманні звіту за хвилину, на який нещодавно були потрібні дні, користувач дуже швидко починає нудьгувати під час очікувань, і проект виявляється набагато менш успішним, ніж у разі миттєвої відповіді, навіть ціною менш детального аналізу.
Розділяєтьсяозначає, що система дає можливість виконувати всі вимоги захисту даних та реалізовувати розподілений та одночасний доступ до даних для різних рівнів користувачів. Система повинна бути здатна обробити численні зміни даних своєчасним, безпечним способом. Це головна слабкість багатьох OLAP продуктів, які мають тенденцію припускати, що у всіх додатках OLAP потрібне лише читання, і надають спрощені засоби захисту.
Багатовимірною- Ключова вимога. Якби необхідно було визначити OLAP одним словом, вибрали б його. Система має забезпечити багатовимірне концептуальне подання даних, включаючи повну підтримку для ієрархій та множинних ієрархій, оскільки це визначає найбільш логічний спосіб аналізувати бізнес. Мінімальна кількість вимірювань, які мають бути оброблені, не встановлюється, оскільки це також залежить від програми, і більшість продуктів OLAP має достатню кількість вимірювань для тих ринків, на які вони націлені. І знову ж таки ми не визначаємо, яка основна технологія бази даних повинна використовуватися, якщо користувач отримує дійсно багатовимірне концептуальне подання інформації. Ця особливість - серцевина OLAP
Інформація.Необхідна інформація має бути отримана там, де вона необхідна, незалежно від її обсягу та місця зберігання. Однак багато залежить від програми. Потужність різних продуктів вимірюється в термінах того, скільки вхідних даних можуть оброблятися, але не скільки гігабайт вони можуть зберігати. Потужність продуктів дуже різна - найбільші OLAP продукти можуть оперувати принаймні в тисячу разів великою кількістю даних у порівнянні з найменшими. З цього приводу слід враховувати багато факторів, включаючи дублювання даних, потрібну оперативну пам'ять, використання дискового простору, експлуатаційні показники, інтеграцію з інформаційними сховищами тощо.
Аналізозначає, що система може справлятися з будь-яким логічним та статистичним аналізом, характерним для даної програми, та забезпечує його збереження у вигляді, доступному для кінцевого користувача. Користувач повинен мати можливість ставити нові спеціальні обчислення як частину аналізу без необхідності програмування. Тобто, всі необхідні функціональні можливості аналізу повинні забезпечуватися інтуїтивним способом для кінцевих користувачів. Кошти аналізу могли б включати певні процедури, типу аналізу часових рядів, розподілу витрат, валютних переказів, пошуку цілей та ін. Такі можливості широко відрізняються серед продуктів, залежно від цільової орієнтації.

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

Технологічні аспекти OLAP

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

Компоненти OLAP-систем (з чого складається OLAP-система?)

Як правило, OLAP-система включає наступні компоненти:

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

Слід зазначити, що не всі компоненти є обов'язковими. Існують настільні OLAP-системи, що дозволяють аналізувати дані, що зберігаються безпосередньо на комп'ютері користувача і не потребують OLAP-сервера.

Проте який елемент обов'язковий це джерело даних: наявність даних – це важливе питання. Якщо вони є, у будь-якому вигляді, як Excel-таблиця, у базі даних облікової системи, у вигляді структурованих звітів філій ІТ-фахівець зможе інтегрувати з OLAP-системою безпосередньо або з проміжним перетворенням. Для цього OLAP системи мають спеціальні інструменти. Якщо цих даних немає, або вони мають недостатню повноту та якість, OLAP не допоможе. Тобто OLAP – це лише надбудова над даними, а якщо їх немає, вони стають марною річчю.

Більшість даних для програм OLAP виникають в інших системах. Однак у деяких програмах (наприклад, для планування або бюджетування) дані можуть створюватися безпосередньо в програмах OLAP. Коли дані надходять з інших програм, зазвичай необхідно, щоб дані зберігалися в окремому, дублюючому, формі для програми OLAP. Тому доцільно створювати сховища даних.

Слід зазначити, що термін OLAP нерозривно пов'язаний з терміном сховище даних (Data Warehouse). Сховище даних - це предметно-орієнтоване, прив'язане до часу і незмінне зібрання даних для підтримки процесу прийняття рішень. Дані до сховища потрапляють з оперативних систем (OLTP-систем), призначених для автоматизації бізнес-процесів, сховище може поповнюватися з допомогою зовнішніх джерел, наприклад статистичних звітів.

Незважаючи на те, що вони містять свідомо надмірну інформацію, яка і так є в базах або файлах оперативних систем, сховища даних необхідні тому, що:

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

Завдання сховища – надати «сировину» для аналізу в одному місці та в простій, зрозумілій структурі. Тобто концепція Сховищ Даних - це концепція аналізу даних, скоріш це концепція підготовки даних для аналізу. Вона передбачає реалізацію єдиного інтегрованого джерела даних.

OLAP-продукти: архітектури

При використанні OLAP-продуктів важливі 2 питання: як і де зберігатиі оброблятидані. Залежно від цього, як реалізуються 2 цих процесу розрізняють архітектури OLAP. Існує 3 способи зберігання даних для OLAP та 3 способи обробки цих даних. Багато виробників пропонують кілька варіантів, деякі намагаються довести, що їхній підхід – єдиний найрозумніший. Це, звісно, абсурд. Однак зовсім небагато продуктів можуть оперувати в більш ніж в одному режимі якісно.

Варіанти зберігання OLAP-даних

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

Реляційні бази даних: це типовий вибір, якщо на підприємстві облікові дані зберігаються у РБД. У більшості випадків дані слід зберігати в денормалізованій структурі (найприйнятніша схема «зірка»). Нормалізована база даних не прийнятна через дуже низьку продуктивність виконання запитів при формуванні агрегованих величин для OLAP (часто підсумкові дані зберігаються в агрегованих таблицях).
Файли баз даних на клієнтському комп'ютері (кіоски або вітрини даних): ці дані можуть заздалегідь розповсюджуватися або створюватися за запитами клієнтських комп'ютерів.

Багатовимірні бази даних: припускають, що дані зберігаються у багатовимірній базі даних на сервері. Вона може включати дані, витягнуті та підсумовані з інших систем та реляційних баз даних, файлів кінцевих користувачів та ін. У більшості випадків, багатовимірні бази даних зберігаються на диску, але деякі продукти дозволяють використовувати і оперативну пам'ять, обчислюючи найчастіше використовувані дані на льоту ». Дуже в малій кількості продуктів, заснованих на багатовимірних базах даних, можливе множинне редагування даних, багато продуктів дозволяють одиночну зміну, але множинне читання даних, тоді як інші обмежуються лише читанням.

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

Варіанти обробки OLAP-даних

Існує 3 тих же варіанти обробки даних:

Використання SQL: цей варіант звичайно використовується при зберіганні даних в РБД. Однак SQL не дозволяє здійснювати багатовимірні обчислення одним запитом, тому потрібно написання складних SQL-запитів для того, щоб досягти не більше ніж звичайну багатовимірну функціональність. Однак, це не зупиняє розробників від спроб. У більшості випадків вони виконують обмежену кількість відповідних обчислень на SQL з результатами, які можна отримати і при багатовимірній обробці даних або з клієнтської машини. Можливе також використання оперативної пам'яті, яка може зберігати дані, використовуючи більш ніж один запит: це кардинально покращило відгук.
Багатовимірна обробка на клієнті: клієнтський OLAP-продукт здійснює обчислення самостійно, але така обробка доступна лише в тому випадку, якщо користувачі мають відносно потужні ПК.

Багатовимірна обробка на сервері: це популярне місце для здійснення багатовимірних обчислень у клієнт-серверних OLAP-додатках, що використовується в багатьох продуктах. Продуктивність зазвичай висока, тому що більшість обчислень вже виконано. Однак це потребує великого дискового простору.

Матриця OLAP-архітектур

Відповідно, шляхом поєднань варіантів зберігання/обробка, можна отримати матрицю архітектур OLAP-систем. Відповідно, теоретично може існувати 9 поєднань цих способів. Однак, оскільки 3 з них позбавлені здорового глузду, то насправді існує лише 6 варіантів зберігання та обробки OLAP-даних.

Варіанти зберігання багатовимірних даних Варіанти багатовимірної обробки даних	Реляційна база даних	Серверна багатовимірна база даних	Клієнтський комп'ютер
	Cartesis Magnitude
Багатовимірна серверна обробка	Crystal Holos (ROLAP mode) IBM DB2 OLAP Server CA EUREKA:Strategy Informix MetaCube Speedware Media/MR Microsoft Analysis Services Oracle Express (ROLAP mode) Pilot Analysis Server Applix iTM1	Crystal Holos Comshare Decision Hyperion Essbase Oracle Express Speedware Media/M Microsoft Analysis Services PowerPlay Enterprise Server Pilot Analysis Server Applix iTM1
Багатовимірна обробка на клієнтському комп'ютері	Oracle Discoverer Informix MetaCube	Dimensional Insight Hyperion Enterprise	Cognos PowerPlay Personal Express iTM1 Perspectives

Оскільки саме зберігання визначає обробку, то прийнято групувати за варіантами зберігання, тобто:

ROLAP-продукти у секторах 1, 2, 3
Настільний OLAP – в секторі 6

MOLAP-продукти – у секторах 4 та 5

HOLAP-продукти (дозволяють як багатовимірний, так і реляційний варіант зберігання даних) – у 2 та 4 (виділені курсивом)

Категорії OLAP-продуктів

Існує понад 40 OLAP-постачальників, хоча всіх їх не можна вважати конкурентами, тому що вони можливості їх дуже відрізняються і, фактично, працюють вони в різних ринкових сегментах. Вони можуть бути згруповані в 4 важливі категорії, в основі відмінності яких лежать поняття: складна функціональність - функціональність проста, продуктивність - дискове простір. Зручно зобразити категорії у вигляді квадрата, оскільки це чітко показує взаємозв'язку з-поміж них. Характерна риса кожної з категорій представлена з його боку, а подібності коїться з іншими – на сусідніх сторонах, отже, категорії на протилежних сторонах – принципово хороші.

Особливості

Переваги

Недоліки

Представники

Прикладний OLAP

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

Можливість інтеграції з різними програмами

Високий рівень функціональності

Високий рівень гнучкості та масштабованості

Складність програми (необхідність навчання користувача)

Висока вартість

Hyperion Solutions

Crystal Decisions

Information Builders

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

Висока продуктивність (швидкі обчислення сумарних показників та різні багатовимірні перетворення за будь-яким із вимірювань). Середній час відповіді на нерегламентований аналітичний запит при використанні багатовимірної БД зазвичай на 1-2 порядки менше, ніж у випадку РБД

Високий рівень відкритості: велика кількість продуктів, з якими можлива інтеграція

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

Необхідність великого дискового простору для зберігання даних (через надмірність даних, що зберігаються). Це вкрай неефективне використання пам'яті - за рахунок денормалізації та попередньо виконаної агрегації обсяг даних у багатовимірній базі відповідає у 2.5-100 разів меншому обсягу вихідних деталізованих даних. У будь-якому випадку MOLAP не дозволяє працювати з великими базами даних. Реальна межа - база об'ємом 10-25 гігабайт

Потенційна можливість «вибуху» бази даних – несподіване, різке, непропорційне зростання її обсягів

Відсутність гнучкості за необхідності модифікації структур даних. Будь-яка зміна в структурі вимірювань майже завжди потребує повної перебудови гіперкубу.

Для багатовимірних БД, в даний час відсутні єдині стандарти на інтерфейс, мови опису та маніпулювання даними

Hyperion (Essbase)

DOLAP (Desktop OLAP)

Клієнтські OLAP-продукти, які досить легко впровадити та вимагають низьких витрат у розрахунку на одне місце

Йдеться про таку аналітичну обробку, де гіперкуби малі, розмірність їх невелика, потреби скромні, і для такої аналітичної обробки достатньо персональної машини на робочому столі.

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

Хороша інтеграція з базами даних: багатовимірними, реляційними

Можливість здійснення комплексних покупок, що знижує вартість проектів запровадження

Простота використання програм

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

Дуже обмежена потужність (малі обсяги даних, невелика кількість вимірювань)

Cognos (PowerPlay)

Business Objects

Crystal Decisions

Це найменший сектор ринку.

Детальні дані залишаються там, де вони спочатку - в реляційної БД; деякі агрегати зберігаються у тій же БД у спеціально створених службових таблицях

Чи здатні працювати з дуже великими обсягами даних (економічне зберігання)

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

Вищий рівень захисту даних та хороші можливості розмежування прав доступу

Можливе часте внесення змін до структури вимірювань (не вимагають фізичної реорганізації БД)

Низька продуктивність значно програють за швидкістю відгуку багатовимірним (відгук на складні запити вимірюється в хвилинах або навіть годинах, ніж у секундах). Це зручніші будівельники звітів, ніж інтерактивні аналітичні інструменти

Складність продуктів. Вимагають значних витрат на обслуговування спеціалістами з інформаційних технологій. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних та налаштування індексів, тобто великих зусиль з боку адміністраторів БД

Дорогі для впровадження

Обмеження SQL залишаються реальністю, що не дозволяє реалізувати в РСУБД багато вбудованих функцій, що легко забезпечуються в системах, заснованих на багатовимірному поданні даних.

Information Advantage

Informix (MetaCube)

Слід зазначити, що споживачі гібридних продуктів, які дозволяють вибирати режим MOLAP і ROLAP, таких як Microsoft Analysis Services, OracleExpress, Crystal Holos, IBM DB2 OLAPServer, майже завжди вибирають режим MOLAP.

Кожна з представлених категорій має свої сильні та слабкі сторони, немає єдино оптимального вибору. Вибір впливає на три важливі аспекти: 1) продуктивність; 2) дисковий простір для зберігання даних; 3) можливості, функціональність та особливо на масштабованість OLAP-рішення. При цьому необхідно враховувати обсяги даних, потужність техніки, потреби користувачів і шукати компроміс між швидкодією і надмірністю дискового простору, зайнятого базою даних, простою і багатофункціональністю.

Класифікація Сховищ Даних відповідно до обсягу цільової БД

Недоліки OLAP

Як і будь-яка технологія OLAP також має свої недоліки: високі вимоги до апаратного забезпечення, підготовки та знань адміністративного персоналу та кінцевих користувачів, високі витрати на реалізацію проекту впровадження (як грошові, так і тимчасові, інтелектуальні).

Вибір OLAP-продукту

Правильно вибрати OLAP продукт складно, але дуже важливо, якщо ви хочете, щоб проект не провалився.

Як бачимо, відмінності продуктів лежать у багатьох областях: функціональних, архітектурних, технічних. Деякі продукти дуже обмежені у налаштуваннях. Деякі створені для спеціалізованих предметних галузей: маркетинг, продаж, фінанси. Є продукти для загальних цілей, у яких не закладено прикладне використання, які мають бути досить гнучкими. Як правило, такі продукти дешевші, ніж спеціалізовані, але тут більше витрати на впровадження. Спектр OLAP-продуктів дуже широкий - від найпростіших засобів побудови зведених таблиць та діаграм, що входять до складу офісних продуктів, до засобів аналізу даних та пошуку закономірностей, вартість яких становить десятки тисяч доларів.

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

У процесі вибору необхідно розглянути 2 питання:

оцінити потреби та можливості підприємства
оцінити існуючу на ринку пропозицію, важливі також і тенденції розвитку

Потім все це порівняти і, власне, зробити вибір.

Оцінка потреб

Не можна зробити раціональний вибір продукту без розуміння того, навіщо він використовуватиметься. Багато компаній хочуть отримати "найкращий виріб" без чіткого розуміння, як воно має використовуватися.

Для того, щоб проект був успішно реалізований, фінансовий директор повинен як мінімум грамотно сформулювати перед керівником та спеціалістами служби автоматизації свої побажання та вимоги. Безліч проблем виникає через недостатню підготовленість та поінформованість для вибору OLAP, фахівці з ІТ та кінцеві користувачі відчувають труднощі спілкування вже тільки тому, що маніпулюють при розмові різними поняттями та термінами та висувають суперечливі уподобання. Потрібна узгодженість у цілі в рамках компанії.

Деякі фактори вже стали очевидними після ознайомлення з оглядом категорії OLAP-продуктів, а саме:

Технічні аспекти

Джерела даних: корпоративне сховище даних, OLTP-система, табличні файли, реляційні бази даних. Можливість ув'язування OLAP-інструментарію з усіма СУБД, що використовуються в організації. Як показує практика, інтеграція різнорідних продуктів у стійко діючу систему - одне з найважливіших питань, та її вирішення часом може бути пов'язані з великими проблемами. Необхідно розібратися, наскільки легко і надійно можна інтегрувати засоби OLAP з існуючими в організації СУБД. Важливо також оцінити можливості інтеграції не тільки з джерелами даних, але й іншими додатками, в які, можливо, знадобиться експортувати дані: електронна пошта, офісні програми
Мінливість даних, що враховуються
Платформа сервера: NT, Unix, AS/400, Linux - але не слід наполягати, щоб задані специфікацією OLAP продукти виконувалися на сумнівних або вмираючих платформах, які Ви все ще використовуєте
Стандарти клієнтської частини та браузера
Розгортається архітектура: локальна мережа та модемний зв'язок PC, високошвидкісний клієнт/сервер, intranet, extranet, Internet
Міжнародні особливості: багатовалютна підтримка, багатомовні операції, колективне використання даних, локалізація, ліцензування, оновлення Windows

Обсяги вхідної інформації, які є та які з'являться у майбутньому

Користувачі

Сферу застосування: аналіз продажів/маркетингу, складання бюджету/планування, аналіз показників діяльності, аналіз бухгалтерських звітів, якісний аналіз, фінансовий стан, формування аналітичних матеріалів (звітів)
Число користувачів та їх розміщення, вимоги до поділу прав доступу до даних та функцій, секретність (конфіденційність) інформації
Вигляд користувача: вище керівництво, фінанси, маркетинг, HR, продаж, виробництво і т.д.
Досвід користувача. Рівень кваліфікації користувача. Розглянути питання проведення навчання. Дуже важливо, щоб клієнтська OLAP-програма була такою, щоб користувачі відчували себе впевнено та могли ефективно її використовувати.

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

Впровадження

Хто займатиметься впровадженням та експлуатацією: зовнішні консультанти, внутрішня служба ІТ або кінцеві користувачі
Бюджет: програмне забезпечення, апаратні засоби, послуги, передачі даних. Пам'ятайте, що оплата ліцензій OLAP-продукту – це лише невелика частина загальної вартості проекту. Впровадження та апаратні витрати можуть бути більшими, ніж плата за ліцензію, а тривала підтримка, експлуатація та витрати адміністрації майже напевно значно більші. І якщо Ви прийняли неправильне рішення покупки невідповідного продукту тільки тому, що воно дешевше, остаточно Ви можете мати вищу загальну вартість проекту через вищі витрати на обслуговування, адміністрацію та/або апаратні витрати при тому, що ймовірно, Ви отримаєте нижчий рівень ділових вигод. При прикидці загальних витрат не забудьте з'ясувати такі питання: Наскільки широкий вибір джерел для впровадження, навчання та підтримки? Чи потенційний загальний фонд (службовців, підрядників, консультантів) схильний до зростання чи скорочення? Наскільки широко можна використовувати свій виробничий професійний досвід?

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

Ефект від правильної організації, стратегічного та оперативного планування розвитку бізнесу важко заздалегідь оцінити у цифрах, але очевидно, що він у десятки і навіть сотні разів може перевершити витрати на реалізацію таких систем. Однак не слід і помилятися. Ефект забезпечує не сама система, а люди з нею працюючі. Тому не зовсім коректні декларації на кшталт: «система Сховищ Даних та OLAP-технологій допомагатиме менеджеру приймати правильні рішення». Сучасні аналітичні системи є системами штучного інтелекту і вони можуть ні допомогти, ні перешкодити у прийнятті рішення. Їхня мета своєчасно забезпечити менеджера всією інформацією необхідною для прийняття рішення у зручному вигляді. А яка інформація буде запитана і яке рішення буде прийнято на її основі, залежить тільки від конкретної людини, яка її використовує.

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

4. Класифікація OLAP-продуктів.

5. Принципи роботи OLAP-клієнтів.

7. Сфери застосування OLAP-технологій.

8. Приклад використання OLAP-технологій для аналізу у сфері продажів.

1. Місце OLAP у інформаційній структурі підприємства.

Термін "OLAP" нерозривно пов'язаний з терміном "сховище даних" (Data Warehouse).

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

Завдання сховища - надати "сировину" для аналізу в одному місці та в простій, зрозумілій структурі.

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

Під сховищем можна розуміти не обов'язково гігантське накопичення даних - головне, щоб воно було зручним для аналізу.

Централізація та зручне структурування – це далеко не все, що потрібно аналітику. Адже йому ще потрібен інструмент для перегляду, візуалізації інформації. Традиційні звіти, навіть побудовані на основі єдиного сховища, позбавлені одного – гнучкості. Їх не можна "покрутити", "розгорнути" або "згорнути", щоб отримати бажане представлення даних. От би йому такий інструмент, який дозволив би розгортати та згортати дані просто та зручно! Як такий інструмент і виступає OLAP.

Хоча OLAP і не є необхідним атрибутом сховища даних, він все частіше застосовується для аналізу накопичених у цьому сховищі відомостей.

Місце OLAP у інформаційній структурі підприємства (рис. 1).

Малюнок 1. МісцеOLAP в інформаційній структурі підприємства

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

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

2. Оперативне аналітичне оброблення даних.

В основі концепції OLAP лежить принцип багатовимірного представлення даних. У 1993 році EF Codd розглянув недоліки реляційної моделі, в першу чергу, вказавши на неможливість "об'єднувати, переглядати та аналізувати дані з точки зору множинності вимірювань, тобто найзрозумілішим для корпоративних аналітиків способом", та визначив загальні вимоги до систем OLAP, що розширюють функціональність реляційних СУБД і що включає багатовимірний аналіз як одну зі своїх характеристик.

За Коддом, багатовимірне концептуальне представлення даних (multi-dimensional conceptual view ) є множинною перспективою, що складається з декількох незалежних вимірювань, вздовж яких можуть бути проаналізовані певні сукупності даних.

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

Так, вимір Виконавець може визначатися напрямом консолідації, що складається з рівнів узагальнення "підприємство - підрозділ - відділ - службовець". Вимірювання Час може навіть включати два напрями консолідації - "рік - квартал - місяць - день" і "тиждень - день", оскільки рахунок часу за місяцями та тижнями несумісний. У цьому випадку стає можливим довільний вибір бажаного рівня деталізації інформації щодо кожного з вимірів.

Операція спуску (drilling down) відповідає руху від вищих ступенів консолідації до нижчих; навпаки, операція підйому (rolling up) означає рух від нижчих рівнів до вищих (рис. 2).

Рисунок 2.Вимірювання та напрямки консолідації даних

3. Вимоги до засобів оперативної аналітичної обробки.

Багатомірний підхід виник практично одночасно і паралельно з реляційним. Однак, тільки починаючи з середини 90-х років, а точніше з
1993 р., інтерес до МСУБДпочав набувати загального характеру. Саме цього року з'явилася нова програмна стаття одного із основоположників реляційного підходу е. кодда, в якій він сформулював 12 основних вимог до засобів реалізації OLAP(Табл. 1).

Таблиця 1.

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

Правила оцінки програмних продуктів класу OLAP

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

Пізніше визначення Кодда було перероблено в так званий тест FASMI, що вимагає, щоб OLAP-додаток надавав можливості швидкого аналізу багатовимірної інформації, що розділяється.

Пам'ятати 12 правил Кодда дуже обтяжливо для більшості людей. Виявилося, що можна резюмувати OLAP-визначення лише п'ятьма ключовими словами: Швидкий Аналіз роздільної багатомірної інформації - або, коротко - FASMI (у перекладі з англійської:F ast A nalysis of S hared M ultidimensional I nformation).

Це визначення вперше було сформульовано на початку 1995 року і з того часу не потребувало перегляду.

FAST ( Швидкий - означає, що система повинна забезпечувати видачу більшості відповідей користувачам близько п'яти секунд. При цьому найпростіші запити обробляються протягом однієї секунди і дуже небагато - понад 20 секунд. Дослідження показали, що кінцеві користувачі сприймають процес невдалим, якщо результати не отримані через 30 секунд.

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

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

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

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

MULTIDIMENSIONAL (Багатомірний) - це ключова вимога. Якби потрібно було визначити OLAP одним словом, вибрали б його. Система повинна забезпечити багатовимірне концептуальне представлення даних, включаючи повну підтримку для ієрархій та множинних ієрархій, оскільки це безумовно найбільш логічний спосіб аналізувати бізнес та організації. Не встановлено мінімальну кількість вимірювань, які мають бути оброблені, оскільки вона також залежить від програми, і більшість продуктів OLAP має достатню кількість вимірювань для тих ринків, на які вони орієнтовані.

INFORMATION (Інформації) - це все. Необхідна інформація має бути отримана там, де вона потрібна. Однак багато залежить від програми. Потужність різних продуктів вимірюється в термінах того, скільки вхідних даних можуть оброблятися, але не скільки гігабайт вони можуть зберігати. Потужність продуктів дуже різна - найбільші OLAP продукти можуть оперувати принаймні в тисячу разів великою кількістю даних у порівнянні з найменшими. З цього приводу слід враховувати багато факторів, включаючи дублювання даних, потрібну оперативну пам'ять, використання дискового простору, експлуатаційні показники, інтеграцію з інформаційними сховищами тощо.

Тест FASMI - розумне та зрозуміле визначення цілей, на досягнення яких орієнтовані OLAP.

4. КласифікаціяOLAP-Продуктів.

Отже, суть OLAP полягає в тому, що вихідна для аналізу інформація представляється у вигляді багатовимірного куба, і забезпечується можливість довільно маніпулювати нею та отримувати необхідні інформаційні розрізи – звіти. При цьому кінцевий користувач бачить куб як багатовимірну динамічну таблицю, яка автоматично підсумовує дані (факти) у різних розрізах (вимірювання), і дозволяє інтерактивно керувати обчисленнями та формою звіту. Виконання цих операцій забезпечується OLAP -Машиною (або машиною OLAP-обчислень).

На сьогоднішній день у світі розроблено безліч продуктів, що реалізують OLAP -технології. Щоб легше було орієнтуватись серед них, використовують класифікації OLAP -продуктів: за способом зберігання даних для аналізу та за місцем знаходження OLAP -Машини. Розглянемо докладніше кожну категорію OLAP-продуктів.

Класифікація за способом зберігання даних

Багатовимірні куби будуються на основі вихідних та агрегатних даних. І вихідні та агрегатні дані для кубів можуть зберігатися як у реляційних, так і багатовимірних базах даних. Тому в даний час застосовуються три способи зберігання даних: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) та HOLAP (Hybrid OLAP ). Відповідно, OLAP -продукти за способом зберігання даних поділяються на три аналогічні категорії:

1. У разі MOLAP , вихідні та агрегатні дані зберігаються в багатовимірній БД або в багатовимірному локальному кубі.

2. У ROLAP -продуктах вихідні дані зберігаються в реляційних БД або плоских локальних таблицях на файл-сервері. Агрегатні дані можуть бути розміщені в службові таблиці в тій же БД. Перетворення даних з реляційної БД на багатовимірні куби відбувається за запитом OLAP-кошти.

3. У разі використання HOLAP архітектури вихідні дані залишаються в реляційній основі, а агрегати розміщуються в багатовимірній. Побудова OLAP -куба виконується за запитом OLAP -Кошти на основі реляційних та багатовимірних даних.

Класифікація за місцем розміщення OLAP-Машини.

За цією ознакою OLAP -продукти поділяються на OLAP-сервери та OLAP-клієнти:

· У серверних OLAP -засобах обчислення та зберігання агрегатних даних виконуються окремим процесом - сервером Клієнтська програма отримує лише результати запитів до багатовимірних кубів, які зберігаються на сервері. Деякі OLAP -Сервери підтримують зберігання даних тільки в реляційних базах, деякі - тільки в багатовимірних. Багато сучасних OLAP -Сервери підтримують всі три способи зберігання даних:MOLAP, ROLAP та HOLAP.

MOLAP.

MOLAP – це Multidimensional On-Line Analytical Processing,тобто багатовимірний OLAP.Це означає, що сервер зберігання даних використовує багатовимірну базу даних (МБД). Сенс використання МБД очевидний. Вона може ефективно зберігати багатовимірні за своєю даними, забезпечуючи засоби швидкого обслуговування запитів до бази даних. Дані передаються від джерела даних у багатовимірну базу даних, потім база даних піддається агрегації. Попередній розрахунок - це те, що прискорює OLAP-запити, оскільки розрахунок зведених даних вже зроблено. Час запиту стає функцією виключно часу, необхідного для доступу до окремого фрагмента даних та виконання розрахунку. Цей метод підтримує концепцію, згідно з якою робота проводиться один раз, а результати потім використовуються знову і знову. Багатовимірні бази є відносно новою технологією. Використання МБД має самі недоліки, як і більшість нових технологій. А саме - вони не такі стійкі, як реляційні бази даних (РБД), і так само не оптимізовані. Інше слабке місце МБД полягає у неможливості використовувати більшість багатовимірних баз у процесі агрегації даних, тому потрібен час для того, щоб нова інформація стала доступною для аналізу.

ROLAP.

ROLAP - це Relational On-Line Analytical Processing,тобто Реляційний OLAP.Термін ROLAP означає, що OLAP-сервер базується на реляційній базі даних. Вихідні дані вводяться в реляційну базу даних, зазвичай, за схемою "зірка" або схемою "сніжинка", що сприяє скороченню часу вилучення. Сервер забезпечує багатовимірну модель даних за допомогою оптимізованих SQL-запитів.

Існує низка причин для вибору саме реляційної, а не багатовимірної бази даних. РБД – це добре відпрацьована технологія, що має безліч можливостей для оптимізації. Використання в реальних умовах дало в результаті більш опрацьований продукт. До того ж, РБД підтримують більші обсяги даних, ніж МБД. Вони таки спроектовані для таких обсягів. Основним аргументом проти РБД є складність запитів, необхідні отримання інформації з великої бази даних з допомогою SQL. Недосвідчений SQL-програміст міг би з легкістю обтяжити цінні системні ресурси спробами виконати якийсь подібний запит, який МБД виконується набагато простіше.

Агреговані/Попередньо агреговані дані.

Швидка реалізація запитів є імперативом для OLAP. Це один із базових принципів OLAP – здатність інтуїтивно маніпулювати даними вимагає швидкого вилучення інформації. В цілому, чим більше обчислень необхідно зробити, щоб отримати фрагмент інформації, тим повільніше відбувається відгук. Тому, щоб зберегти невеликий час реалізації запитів, фрагменти інформації, звернення яких зазвичай відбувається найчастіше, але які у своїй вимагають обчислення, піддаються попередньої агрегації. Тобто вони підраховуються і потім зберігаються в базі даних як нові дані. Як приклад типу даних, який можна розрахувати заздалегідь, можна навести зведені дані - наприклад, показники продажів за місяцями, кварталами або роками, для яких дійсно введеними даними є щоденні показники.

Різні постачальники дотримуються різних методів відбору параметрів, що вимагають попередньої агрегації та числа попередньо обчислюваних величин. Підхід до агрегації впливає одночасно і на базу даних та на час реалізації запитів. Якщо обчислюється більше величин, ймовірність того, що користувач запросить вже обчислену величину, зростає, і тому час відгуку скоротитися, тому що не доведеться вимагати початкову величину для обчислення. Однак, якщо обчислити всі можливі величини - це не найкраще рішення - у такому випадку суттєво зростає розмір бази даних, що зробить її некерованою, та й час агрегації буде завеликим. До того ж, коли до бази даних додаються числові значення, або якщо вони змінюються, інформація ця повинна відображатися на попередньо обчислених величинах, що залежать від нових даних. Таким чином, і оновлення бази може також зайняти багато часу у разі великої кількості попередньо обчислюваних величин. Оскільки зазвичай під час агрегації база даних працює автономно, бажано, щоб час агрегації був занадто тривалим.

· OLAP -Клієнт влаштований по-іншому. Побудова багатовимірного куба та OLAP -Обчислення виконуються в пам'яті клієнтського комп'ютера.OLAP -клієнти також поділяються на ROLAP та MOLAP .А деякі можуть підтримувати обидва варіанти доступу до даних.

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

Розробка аналітичних додатків за допомогою клієнтських OLAP-засобів – процес швидкий, що не потребує спеціальної підготовки виконавця. Користувач, який знає фізичну реалізацію бази даних, може розробити аналітичну програму самостійно, без залучення ІТ-спеціаліста.

При використанні OLAP-сервера необхідно вивчити дві різні системи, іноді від різних постачальників, – для створення кубів на сервері, та для розробки клієнтської програми.

OLAP-клієнт надає єдиний візуальний інтерфейс для опису кубів та налаштування до них інтерфейсів користувача.

Отже, у яких випадках застосування OLAP-клієнта для користувачів може виявитися ефективнішим та вигіднішим за використання OLAP-сервера?

· Економічна доцільність застосування OLAP -сервера виникає, коли обсяги даних дуже великі та непосильні для OLAP -Клієнта, інакше більш виправдане застосування останнього. В цьому випадку OLAP -Клієнт поєднує в собі високі характеристики продуктивності та низьку вартість.

· Потужні ПК аналітиків – ще один аргумент на користь OLAP -Клієнтів. При застосуванні OLAP -Сервера ці потужності не використовуються.

Серед переваг OLAP-клієнтів можна назвати таке:

· Витрати використання та супровід OLAP -Клієнта істотно нижче, ніж витрати на OLAP-сервер.

· При використанні OLAP -Клієнта з вбудованою машиною передача даних по мережі проводиться один раз. При виконанні OLAP -операцій нових потоків даних не породжується

5. Принципи роботи OLAP-Клієнтів.

Розглянемо процес створення OLAP-застосування за допомогою клієнтського інструментального засобу (рис. 1).

Малюнок 1.Створення OLAP-застосунку за допомогою клієнтського ROLAP-засобу

Принцип роботи ROLAP-клієнтів – попередній опис семантичного шару, за яким ховається фізична структура вихідних даних. У цьому джерелами даних може бути: локальні таблиці, РСУБД. Список джерел даних, що підтримуються, визначається конкретним програмним продуктом. Після цього користувач може самостійно маніпулювати зрозумілими об'єктами в термінах предметної області для створення кубів і аналітичних інтерфейсів.

Принцип роботи клієнта OLAP-сервера інший. В OLAP-сервері під час створення кубів користувач маніпулює фізичними описами БД. При цьому в самому кубі створюються описи користувача. Клієнт OLAP-сервера налаштовується лише на куб.

При створенні семантичного шару джерела даних – таблиці Sales та Deal – описуються зрозумілими кінцевому користувачеві термінами та перетворюються на «Продукти» та «Угоди». Поле "ID" з таблиці "Продукти" перейменовується в "Код", а "Name" - в "Товар" і т.д.

Потім створюється бізнес-об'єкт «Продаж». Бізнес-об'єкт – це плоска таблиця, з урахуванням якої формується багатовимірний куб. При створенні бізнес-об'єкта таблиці "Продукти" та "Угоди" об'єднуються по полю "Код" товару.Оскільки для відображення у звіті не потрібні всі поля таблиць – бізнес-об'єкт використовує лише поля «Товар», «Дата» та «Сума».

У нашому прикладі на базі бізнес-об'єкта «Продажі» створено звіт із продажу товарів за місяцями.

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

Усі настройки OLAP-програми можуть зберігатися у виділеному репозиторії метаданих, у додатку або системному репозиторії багатовимірної бази даних.Реалізація залежить від конкретного програмного продукту.

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

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

6. Вибір архітектури програми OLAP.

При реалізації інформаційно-аналітичної системи важливо не помилитись у виборі архітектури OLAP-додатку. Дослівний переклад терміна On-Line Analytical Process - «оперативна аналітична обробка» - часто сприймається буквально у тому сенсі, що дані дані оперативно аналізуються. Ця помилка - оперативність аналізу не пов'язана з реальним часом оновлення даних у системі. Ця характеристика стосується часу реакції OLAP-системи на запити користувача. При цьому часто аналізовані дані є знімком інформації «на вчорашній день», якщо, наприклад, дані в сховищах оновлюються раз на добу.

У цьому контексті точніший переклад OLAP як «інтерактивна аналітична обробка». Саме можливість аналізу даних в інтерактивному режимі відрізняє системи OLAP від систем підготовки регламентованих звітів.

Іншою особливістю інтерактивної обробки у формулюванні родоначальника OLAP Е. Кодда є можливість «об'єднувати, переглядати та аналізувати дані з точки зору множинності вимірювань, тобто найзрозумілішим для корпоративних аналітиків способом». У самого Кодда термін OLAP означає виключно конкретний спосіб представлення даних на концептуальному рівні - багатовимірний. Фізично дані можуть зберігатися в реляційних базах даних, проте насправді OLAP-інструменти, як правило, працюють з багатовимірними базами даних, в яких дані впорядковані у вигляді гіперкуба (рис. 1).

Малюнок 1. OLAP– куб (гіперкуб, метакуб)

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

Очевидно, що час формування багатовимірної бази даних істотно залежить від обсягу даних, що завантажуються в неї, тому розумно обмежити цей обсяг. Але як при цьому не звузити можливості аналізу і не позбавити користувача доступу до всієї інформації, що цікавить? Існує два альтернативні шляхи: Analyze then query («Спочатку проаналізуй – потім запитай додаткову інформацію») та Query then analyze («Спочатку запитай дані – потім аналізуй»).

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

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

До переваг другого підходу слід віднести «свіжість» інформації, яку користувач отримує у вигляді багатовимірного звіту – «мікрокуба». Мікрокуб формується на основі нової інформації з актуальної реляційної бази даних. p align="justify"> Робота з мікрокубом здійснюється в інтерактивному режимі - отримання зрізів інформації та її деталізація в рамках мікрокуба здійснюється моментально. Іншим позитивним моментом є те, що проектування структури та наповнення мікрокуба здійснюється користувачем "на льоту", без участі адміністратора баз даних. Однак підхід страждає і на серйозні недоліки. Користувач не бачить загальної картини і повинен заздалегідь визначатися з напрямком свого дослідження. Інакше запитаний мікрокуб може виявитися занадто малий і не містити всіх даних, що цікавлять, а користувачеві доведеться запитувати новий мікрокуб, потім новий, потім ще і ще. Підхід Query then analyze реалізує інструментальний засіб BusinessObjects однойменної компанії та інструментальні засоби платформи Контур компаніїIntersoft Lab.

При підході Analyze then query обсяг даних, що завантажуються в багатовимірну базу даних, може бути досить великий, наповнення має виконуватися за регламентом і може тривати досить багато часу. Однак всі ці недоліки окупаються згодом, коли користувач має доступ практично до всіх необхідних даних будь-якої комбінації. Звернення до вихідних даних у реляційній базі даних здійснюється лише в крайньому випадку, коли потрібна детальна інформація, наприклад, за конкретною накладною.

На роботі єдиної багатовимірної бази даних практично не позначається кількість користувачів, що звертаються до неї. Вони лише читають наявні там дані на відміну підходу Query then analyze , у якому кількість мікрокубів у граничному разі може зростати з тією ж швидкістю, як і кількість користувачів.

При цьому підході збільшується навантаження на ІТ-служби, які, крім реляційних, змушені обслуговувати ще й багатовимірні бази даних.Саме ці служби відповідають за своєчасне автоматичне оновлення даних у багатовимірних базах даних.

Найбільш яскравими представниками підходу "Analyze then query" є інструментальні засоби PowerPlay та Impromptu компанії Cognos.

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

7. Сфери застосування OLAP-технологій.

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

Розглянемо деякі сфери застосування OLAP-технологій, взяті із реального життя.

1. Продаж.

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

2. Закупівлі.

Завдання протилежне аналізу продажу. Багато підприємств закуповують комплектуючі та матеріали у постачальників. Торгові підприємства купують товари для перепродажу. Можливих завдань при аналізі закупівель безліч, від планування коштів на основі минулого досвіду, до контролю за менеджерами, що вибирають постачальників.

3. Ціни.

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

4. Маркетинг.

Під маркетинговим аналізом будемо мати на увазі лише область аналізу покупців або клієнтів-споживачів послуг. Завданням цього аналізу є правильне позиціонування товару, виявлення груп покупців цільової реклами, оптимізація асортименту. Завдання OLAP у разі - дати користувачеві інструмент швидкого, зі швидкістю думки, отримання відповіді питання, інтуїтивно що виникають у процесі аналізу даних.

5. Склад.

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

6. Рух коштів.

Це ціла область аналізу, що має безліч шкіл та методик. OLAP-технологія може бути інструментом реалізації або вдосконалення цих методик, але не їх заміною. Аналізуються грошові обороти безготівкових та готівкових коштів у розрізі бізнес-операцій, контрагентів, валют і часу з метою оптимізації потоків, забезпечення ліквідності, і т.д. Склад вимірів залежить від особливостей бізнесу, галузі, методики.

7. Бюджет.

8. Бухгалтерські рахунки.

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

9. Фінансова звітність.

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

10. Відвідуваність сайту.

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

11. Обсяги виробництва.

Це ще один приклад статистичного аналізу. Таким чином, можна аналізувати обсяги вирощеної картоплі, виплавленої сталі, виробленого товару.

12. Споживання витратних матеріалів.

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

13. Використання приміщень.

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

14. Плинність кадрів для підприємства.

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

15. Пасажирські перевезення.

Аналіз кількості проданих квитків та сум у розрізі сезонів, напрямків, видів вагонів (класів), типів поїздів (літаків).

Цим списком не обмежуються сфери застосування OLAP - технологій. Наприклад розглянемо технологію OLAP -аналізу у сфері продажу.

8. Приклад використання OLAP -технологій для аналізу у сфері продажів

Проектування багатовимірного представлення даних для OLAP -Аналізу починається з формування карти вимірювань. Наприклад, при аналізі продажів може бути доцільно, виділити окремі частини ринку (розвиваються, стабільні, великі та дрібні споживачі, ймовірність появи нових споживачів тощо) та оцінити обсяги продажів за продуктами, територіями, покупцями, сегментами ринку, каналами збуту та розмірів замовлень. Ці напрями утворюють координатну сітку багатовимірного представлення продажів - структуру його вимірів.

Оскільки діяльність будь-якого підприємства протікає в часі, перше питання, яке виникає під час аналізу, це питання про динаміку розвитку бізнесу. Правильна організація осі часу дозволить якісно відповісти на це питання. Зазвичай вісь часу ділиться на роки, квартали та місяці. Можливе ще більше дроблення на тижні та дні. Структура тимчасового виміру формується з урахуванням періодичності надходження даних; може обумовлюватися також періодичністю запитування інформації.

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

Вимірювання «Клієнти» відображає структуру продажу за територіально-географічною ознакою. У кожному вимірі можуть існувати свої ієрархії, наприклад, у даному вимірі це може бути структура: Країни – Регіони – Міста – Клієнти.

Для аналізу ефективності діяльності підрозділів слід створити власний вимір. Наприклад, можна виділити два рівні ієрархії: департаменти і відділи, що входять до них, що і має знайти відображення у вимірі «Підрозділи».

По суті, виміри "Час", "Товари", "Замовники" досить повно визначають простір предметної області.

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

OLAP – куб для аналізу матиме вигляд (рис. 2):

Рисунок 2.OLAP– куб для аналізу обсягу продажу

Саме такий тривимірний масив у термінах OLAP і називається кубом. Насправді, з погляду суворої математики кубом такий масив буде далеко не завжди: у справжнього куба кількість елементів у всіх вимірах має бути однаковим, а у кубів OLAP такого обмеження немає. Куб OLAP зовсім не обов'язково має бути тривимірним. Він може бути і дво-, і багатовимірним - залежно від розв'язуваного завдання. Серйозні OLAP-продукти розраховані на кількість вимірювань близько 20. Простіші настільні програми підтримують десь 6 вимірювань.

Повинні бути заповнені далеко не всі елементи куба: якщо немає інформації про продаж Товару 2 Клієнту 3 у третьому кварталі, значення у відповідному осередку просто не буде визначено.

Однак куб сам для аналізу не придатний. Якщо ще можна адекватно уявити чи зобразити тривимірний куб, то із шести- або дев'ятнадцятимірнимсправа значно гірша. Тому перед вживанням із багатовимірного куба витягують звичайні двовимірні таблиці. Ця операція називається "розрізанням" куба. Аналітик як би бере і "розрізає" вимірювання куба по мітках, що його цікавлять. Цим способом аналітик отримує двовимірний зріз куба (звіт) та з ним працює. Структура звіту представлена малюнку 3.

Рисунок 3.Структура аналітичного звіту

Розріжемо наш OLAP – куб і отримаємо звіт про продаж за третій квартал, він матиме такий вигляд (рис.4).

Рисунок 4.Звіт про продаж за третій квартал

Можна розрізати куб уздовж іншої осі та отримати звіт про продаж групи товарів 2 протягом року (рис. 5).

Малюнок 5.Поквартальний звіт про продаж товару 2

Аналогічно можна проаналізувати відносини з клієнтом 4, розрізавши куб за міткою Клієнти(Рис. 6)

Рисунок 6.Звіт про постачання товарів клієнту 4

Можна деталізувати звіт по місяцях або говорити про постачання товарів до певної філії клієнта.

Категорії

Популярне