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

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

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

Рис. 6.15.

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

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

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

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

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

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

p align="justify"> Інформаційні системи масштабу підприємства, як правило, містять додатки, призначені для комплексного багатовимірного аналізу даних, їх динаміки, тенденцій і т.п. Такий аналіз зрештою покликаний сприяти прийняттю рішень. Нерідко ці системи і називаються – системи підтримки прийняття рішень.

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

Технологія комплексного багатовимірного аналізу даних одержала назву OLAP (On-Line Analytical Processing).

OLAP – ключовий компонент організації сховищ даних.

Концепція OLAP була описана в 1993 Едгаром Коддом, відомим дослідником баз даних і автором реляційної моделі даних (див.E.F. Codd, S.B. Codd, і C.T. Technical report, 1993).

У 1995 році на основі вимог, викладених Коддом, був сформульований так званий тест FASMI (Fast Analysis of Shared Multidimensional Information – швидкий аналіз багатовимірної інформації, що розділяється), що включає наступні вимоги до додатків для багатовимірного аналізу:

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

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

· розрахований на багато користувачів доступ до даних з підтримкою відповідних механізмів блокувань і засобів авторизованого доступу;

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

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

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

2. Що таке OLAP

OLAP – абревіатура від англійської On-Line Analytical Processing – це назва не конкретного продукту, а цілої технології. Російською найзручніше називати OLAP оперативною аналітичною обробкою. Хоча в деяких виданнях аналітичну обробку називають і онлайновою, і інтерактивною, проте прикметник “оперативна” якнайточніше відображає сенс технології OLAP.

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

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

Історично склалося так, що рішення щодо автоматизації оперативної діяльності найбільш розвинені. Йдеться про системи транзакційної обробки даних (OLTP), які простіше називають оперативними системами. Ці системи забезпечують реєстрацію деяких фактів, їхнє нетривале зберігання та збереження в архівах. Основу таких систем забезпечують системи управління реляційними базами даних (РСУБД). Традиційним підходом є спроби використати вже збудовані оперативні системи для підтримки прийняття рішень. Зазвичай, намагаються будувати розвинену систему запитів до оперативної системи та використовувати отримані після інтерпретації звіти безпосередньо для підтримки рішень. Звіти можуть будуватися на базі, тобто. керівник запитує звіт, і на регулярній, коли звіти будуються після досягнення деяких подій або часу. Наприклад, традиційний процес підтримки прийняття рішень може мати такий вигляд: керівник йде до спеціаліста інформаційного відділу і ділиться з ним своїм питанням. Потім спеціаліст інформаційного відділу будує запит до оперативної системи, отримує електронний звіт, інтерпретує його і потім доводить його до керівного персоналу. Звичайно, така схема забезпечує певною мірою підтримку прийняття рішень, але вона має вкрай низьку ефективність та величезну кількість недоліків. Низька кількість даних використовується для підтримки критично важливих рішень. Є інші проблеми. Подібний процес дуже повільний, оскільки тривалий процес написання запитів і інтерпретації електронного звіту. Він займає багато днів, в той час, коли керівнику може бути необхідно ухвалити рішення прямо зараз, негайно. Якщо врахувати, що керівника після отримання звіту може зацікавити інше питання (скажімо, уточнює або вимагає розгляду даних в іншому розрізі), цей повільний цикл повинен повторитися, а оскільки процес аналізу даних оперативних системвідбуватиметься ітераційно, то часу витрачається ще більше. Інша проблема – проблема різних галузей діяльності фахівця з інформаційним технологіямта керівника, які можуть мислити у різних категоріях і, як наслідок, – не розуміти один одного. Тоді будуть потрібні додаткові уточнюючі ітерації, а це знову час, якого завжди не вистачає. Ще однією важливою проблемою є складність звітів для розуміння. У керівника немає часу вибирати цікаві цифри зі звіту, тим більше, що їх може виявитися занадто багато (згадаймо величезні багатосторінкові звіти, в яких реально використовуються кілька сторінок, а інші – про всяк випадок). Зазначимо також, що робота з інтерпретації лягає найчастіше на спеціалістів інформаційних відділів. Тобто грамотний фахівець відволікається на рутинну та малоефективну роботу з малювання діаграм тощо, що, звісно, ​​неспроможна сприятливо позначатися його кваліфікації. Крім того, не є секретом присутність у ланцюжку інтерпретації доброзичливців, зацікавлених у навмисному спотворенні інформації, що надходить.

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

Насправді ці проблеми не є наслідком низької якості оперативної системи або її невдалої споруди. Коріння проблем криється у фундаментальній відмінності тієї оперативної діяльності, яка автоматизується оперативною системою, та діяльністю з розробки та прийняття рішень. Відмінність це полягає в тому, що дані оперативних систем є просто записами про деякі події, факти, що мали місце, але ніяк не інформацією в загальному сенсі цього слова. Інформація – те, що знижує невизначеність у будь-якій галузі. І дуже непогано, якби інформація знижувала невизначеність у галузі підготовки рішень. З приводу непридатності для цієї мети оперативних систем, побудованих на РСУБД, свого часу висловився відомий E.F. Codd, людина, що стояла в 70-і роки біля витоків технологій систем управління реляційними БД: “Хоча системи управління реляційними БД доступні для користувачів, вони ніколи не вважалися засобом, що дає потужні функції синтезу, аналізу та консолідації (функцій, званих багатовимірним аналізом даних )”. Йдеться саме про синтез інформації, про те, щоб перетворювати дані оперативних систем на інформацію і навіть на якісні оцінки. OLAP дозволяє виконувати таке перетворення.

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

3. Історія створення OLAP-технології

Ідея обробки даних на багатовимірних масивах не є новою. Фактично вона походить від 1962 року, коли Ken Iverson опублікував свою книгу "Мова програмування" ("A Programming Language", APL). Перша практична реалізація APL відбулася пізніх шістдесятих компанією IBM. APL – це дуже витончена, математично визначена мова з багатовимірними змінними та оброблюваними операціями. Він мав на увазі як оригінальний потужний засіб роботи з багатовимірними перетвореннями в порівнянні з іншими практичними мовами програмування.

Однак ідея довгий час не отримувала масового застосування, оскільки не настав час графічних інтерфейсів, що друкують пристроїв високої якості, а відображення грецьких символів вимагало спеціальних екранів, клавіатур і друкуючих пристроїв. Пізніше англійські слова іноді використовували для заміни грецьких операторів, проте борці за чистоту APL запобігли спробам популяризації їхньої улюбленої мови. APL також поглинав машинні ресурси. У дні його використання вимагало великих витрат. Програми дуже повільно виконувались і, крім того, їхній запуск обходився дуже дорого. Потрібно було багато пам'яті, на ті часи просто шокуючі обсяги (близько 6 МБ).

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

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

У 80-х роках APL став доступним на персональних машинах, але не знайшов ринкового застосування. Альтернативою було програмування багатовимірних програм з використанням масивів в інших мовах. Це було дуже важким завданням навіть професійних програмістів, що змушувало чекати наступного покоління багатовимірних програмних продуктів.

У 1972 році кілька прикладних багатовимірних програмних продуктів, які раніше використовувалися в навчальних цілях, знайшли комерційне застосування: Express. Він у повністю переписаному вигляді залишається і зараз, проте оригінальні концепції 70-х років перестали бути актуальними. Сьогодні, в 90-х, Express є однією з найпопулярніших OLAP-технологій, і Oracle (r) просуватиме його та доповнюватиме новими можливостями.

Більше багатовимірних продуктів з'явилося у 80-х роках. На початку десятиліття – продукт з назвою Stratagem, що пізніше називається Acumate (сьогодні власником є ​​Kenan Technologies), який ще просувався до початку 90-х, але сьогодні, на відміну від Express, практично не використовується.

Comshare System W був багатовимірним продуктом іншого стилю. Представлений у 1981 році, він був першим, де передбачалася велика орієнтованість на кінцевого користувача та розробку фінансових додатків. Він привніс багато концепцій, які, щоправда, були добре адаптовані, такі, як повністю непроцедурні правила, повноекранний перегляд і редагування багатовимірних даних, автоматичне перерахування і пакетна інтеграція з реляційними даними. Однак Comshare System W був досить важким для апаратного забезпеченняна той час у порівнянні з іншими продуктами і менше використовувався в майбутньому, продавався все менше, і в продукті не робилося жодних покращень. Хоча він і сьогодні доступний на UNIX, він не є клієнт-серверним, що не сприяє підвищенню його пропозиції на ринку аналітичних продуктів. У пізніх 80-х Comshare випустив продукт для DOS, а згодом для Windows. Ці продукти називалися Commander Prism і використовували самі концепції, як і System W.

Інший творчий продукт пізніх 80-х називався Metaphor. Він призначався професійних маркетологів. Він також запропонував багато нових концепцій, які тільки сьогодні починають широко використовуватись: клієнт-серверні обчислення, використання багатовимірної моделі на реляційних даних, об'єктно-орієнтована розробка додатків. Однак стандартне апаратне забезпечення персональних машин тих днів не було здатне працювати з Metaphor і постачальники змушені були розробляти власні стандарти на персональні машини та мережі. Поступово Metaphor став працювати вдало і на серійних персональних машинах, проте продукт був виконаний виключно для OS/2 і мав власний графічний інтерфейс користувача.

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

У 80-х народився термін EIS (Executive Information System – інформаційна система керівника). Першим продуктом, який ясно продемонстрував цей напрямок, був Pilot's Command Center. Це був продукт, який дозволяв виконувати спільні обчислення, те, що ми називаємо сьогодні клієнт-серверними обчисленнями. Оскільки потужність персональних комп'ютерів 80-х була обмежена, продукт був дуже “сервероцентричний”, проте цей принцип і сьогодні дуже популярний. Pilot недовго продавав Command Center, але запропонував багато концепцій, які можна дізнатися в сьогоднішніх OLAP-продуктах, включаючи автоматичну підтримку тимчасових проміжків, багатовимірні клієнт-серверні обчислення та спрощене керування процесом аналізу (миша, чутливі екрани тощо). Деякі з цих концепцій були повторно використані пізніше в Pilot Analysis Server.

Наприкінці 80-х електронні таблиці були домінуючими ринку інструментів, надають аналіз кінцевим користувачам. Першу багатовимірну електронну таблицю було представлено продуктом Compete. Він просувався на ринок як дуже дорогий продукт для фахівців, але постачальники не забезпечили можливість захоплення ринку цим продуктом, і компанія Computer Associates набула права на нього разом з іншими продуктами, включаючи Supercalc та 20/20. Основним ефектом від придбання CA Compete було різке зниження ціни на нього та зняття захисту від копіювання, що природно сприяло його поширенню. Однак він не був вдалим. Compete покладено основою Supercalc 5, але багатовимірний аспект не просувається. Старий Compete все ще іноді використовують у зв'язку з тим, що свого часу в нього вкладено чималі кошти.

Компанія Lotus була наступною, хто спробував увійти на ринок багатовимірних електронних таблиць із продуктом Improv, який запускається на NeXT машині. Це гарантувало, щонайменше, що продажі 1-2-3 не знизяться, але коли той згодом був випущений під Windows, Excel вже мав велику частку ринку, що не дозволило Lotus внести будь-які зміни до розподілу ринку. Lotus, подібно CA з Compete, перемістила Improv у нижню частину ринку, однак і це не стало умовою вдалого просування на ринку, і нові розробки в цій галузі не отримали продовження. Виявилося, що користувачі персональних комп'ютерів віддали перевагу електронним таблицям 1-2-3 і не цікавляться новими багатовимірними можливостями, якщо вони не повністю сумісні з їх старими таблицями. Так само концепції маленьких, настільних електронних таблиць, пропонованих як персональні додатки, насправді не виявилися зручними і не прижилися у діловому світі. Microsoft (r) пішла цим шляхом, додавши PivotTables (у російській редакції це називається “зведені таблиці”) до Excel. Хоча мало хто користувачі Excelотримали вигоду від використання цієї можливості, це, ймовірно, єдиний факт широкого використання у світі можливостей багатовимірного аналізу просто тому, що у світі багато користувачів Excel.

4. OLAP, ROLAP, MOLAP ...

Загальновідомо, що коли Кодд опублікував в 1985 свої правила побудови реляційних СУБД, вони викликали бурхливу реакцію і згодом сильно позначилися взагалі на індустрії СУБД. Проте мало хто знає, що у 1993 році Кодд опублікував працю під назвою “OLAP для користувачів-аналітиків: якою вона має бути”. У ньому він виклав основні концепції оперативної аналітичної обробки та визначив 12 правил, яким мають задовольняти продукти, що надають можливість виконання оперативної аналітичної обробки.

Ось ці правила (текст оригіналу збережено по можливості):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Є ще один досить екзотичний вид оперативної аналітичної обробки – DOLAP. Це настільний (desktop) OLAP. Йдеться про таку аналітичну обробку, де гіперкуби малі, розмірність їх невелика, потреби скромні, і для такої аналітичної обробки достатньо персональної машини на робочому столі.

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

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

Метою курсової роботи є вивчення технології OLAP, поняття її реалізації та структури.

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

Великий обсяг інформації дуже ускладнює пошук рішень, але дає можливість отримати набагато точніше розрахунки та аналіз. Для вирішення такої проблеми існує цілий клас інформаційних систем, які виконують аналіз. Такі системи називають системами підтримки ухвалення рішень (СППР) (DSS, Decision Support System).

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

· ввід данних;

· зберігання даних;

· Аналіз даних.

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

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

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

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

У підсистемах введення даних, званих OLTP (On-linetransactionprocessing), реалізується операційна обробка даних. Для реалізації використовують стандартні системи управління БД (СУБД).

Підсистема аналізу може бути побудована на основі:

· Підсистеми інформаційно-пошукового аналізу на базі реляційних СУБД та статичних запитів з використанням мови SQL;

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

· Підсистеми інтелектуального аналізу. Ця підсистема реалізує методи та алгоритми DataMining.

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

1.2 Визначення OLAP-систем

Технологія комплексного багатовимірного аналізу даних одержала назву OLAP. OLAP – це ключовий компонент організації ХД.

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

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

Основне призначення 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 році у статті E. F. 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.

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

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

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

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

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

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

Структура системи OLAP

В основі роботи системи OLAP лежить обробка багатовимірних масивів даних. Багатовимірні масиви влаштовані так, що кожен елемент масиву має велику кількість зв'язків з іншими елементами. Щоб сформувати багатовимірний масив, система OLAP повинна отримати вихідні дані з інших систем (наприклад, ERP або CRM системи), або через зовнішнє введення. Користувач OLAP системи отримує необхідні дані у структурованому вигляді відповідно до свого запиту. Виходячи із зазначеного порядку дій, можна уявити структуру OLAP системи.

Загалом структура OLAP системи складається з наступних елементів:

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

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

Існує три основні способи зберігання та обробки даних:

• локально. Дані розміщуються на комп'ютерах користувачів. Обробка, аналіз та управління даними виконується на локальних робочих місцях. Така структура системи OLAP має істотні недоліки, пов'язані зі швидкістю обробки даних, захищеністю даних та обмеженим застосуванням багатовимірного аналізу.
• реляційні бази даних. Ці бази даних використовуються при спільної роботи OLAP системи з CRM системою або ERP системою. Дані зберігаються на сервері цих систем як реляційних баз даних чи сховищ даних. OLAP сервер звертається до цих баз даних для формування необхідних багатовимірних структур та проведення аналізу.
• багатовимірні бази даних. В даному випадку дані організовані у вигляді спеціального сховища даних на виділеному сервері. Всі операції з даними здійснюються на цьому сервері, який перетворює вихідні дані на багатовимірні структури. Такі структури називають OLAP кубом. Джерелами даних для формування OLAP кубає реляційні бази даних та/або клієнтські файли. Сервер даних здійснює попередню підготовку та обробку даних. OLAP сервер працює з OLAP кубом не маючи безпосереднього доступу до джерел даних (реляційних баз даних, клієнтських файлів та ін.).

Види OLAP систем

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

1. ROLAP (Relational OLAP – реляційні OLAP системи) – цей вид OLAP системи працює з реляційними базами даних. Звернення до даних здійснюється безпосередньо в реляційну базу даних. Дані зберігаються як реляційних таблиць. Користувачі мають можливість здійснювати багатовимірний аналіз як у традиційних системах OLAP. Це досягається за рахунок застосування інструментів SQL та спеціальних запитів.

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

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

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

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

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

3. HOLAP (Hybrid OLAP – гібридні системи OLAP). Гібридні OLAP системи є об'єднання систем ROLAP і MOLAP. У гібридних системах постаралися поєднати переваги двох систем: використання багатовимірних баз даних та управління реляційними базами даних. HOLAP системи дозволяють зберігати велику кількість даних у реляційних таблицях, а оброблювані дані розміщуються у попередньо побудованих багатовимірних OLAP кубах. Переваги цього виду систем полягають у масштабованості даних, швидкій обробці даних та гнучкому доступі до джерел даних.

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

До таких видів належать:

• WOLAP (Web OLAP). Вид OLAP системи з підтримкою веб-інтерфейсу. У цих системах OLAP можна звертатися до баз даних через web інтерфейс.
• DOLAP (Desktop OLAP). Цей вид OLAP системи дозволяє користувачам завантажити на локальне робоче місце базу даних і працювати з нею локально.
• MobileOLAP. Це функція OLAP систем, яка дозволяє працювати з базою даних віддалено, за допомогою мобільних пристроїв.
• SOLAP (Spatial OLAP). Цей вид OLAP систем призначений для обробки просторових даних. Він з'явився як результат інтеграції географічних інформаційних систем та системи OLAP. Ці системи дозволяють обробляти дані у буквено-цифровому форматі, а й у вигляді візуальних об'єктів і векторів.

Переваги системи OLAP

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

Основними перевагами системи OLAP є:

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