Вступ

В наш час без систем управління базами даних не обходиться практично жодна організація, особливо серед тих, які традиційно орієнтовані взаємодію з клієнтами. Банки, страхові компанії, авіа- та інші транспортні компанії, мережі супермаркетів, телекомунікаційні та маркетингові фірми, організації, зайняті у сфері послуг та інші - всі вони збирають та зберігають у своїх базах гігабайти даних про клієнтів, продукти та сервіси. Цінність подібних відомостей безперечна. Такі бази даних називають операційними чи транзакційними, оскільки вони характеризуються величезною кількістю невеликих транзакцій чи операцій запису-читання. Комп'ютерні системи, які здійснюють облік операцій і доступ до баз транзакцій, прийнято називати системами оперативної обробки транзакцій (OLTP - On-Line Transactional Processing) або обліковими системами.

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

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

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

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

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

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

Метою курсової роботирозгляд технології OLAP.

багатовимірний аналітичний аналіз

Основна частина

1 Основні відомості про OLAP

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

У великій кількості публікацій абревіатурою OLAP позначається як багатомірний погляд на дані, а й зберігання самих даних у багатовимірної БД. Взагалі кажучи, це неправильно, оскільки сам Кодд зазначає, що "Реляційні БД були, є і будуть найбільш підходящою технологією для зберігання корпоративних даних. Необхідність існує не в нової технологіїБД, а, швидше, у засобах аналізу, що доповнюють функції існуючих СУБД та досить гнучких, щоб передбачити та автоматизувати різні видиінтелектуального аналізу, властиві OLAP". Така плутанина призводить до протиставлень на кшталт "OLAP або ROLAP", що не зовсім коректно, оскільки ROLAP (реляційний OLAP) на концептуальному рівні підтримує всю певну терміном OLAP функціональність. Більш переважним здається використання для OLAP на основі спеціального терміна MOLAP За Коддом, багатовимірне концептуальне подання (multi-dimensional conceptual view) є множинною перспективою, що складається з декількох незалежних вимірів, вздовж яких можуть бути проаналізовані певні сукупності даних. напрями консолідації даних, що складаються із серії послідовних рівнів узагальнення, де кожен вищестоящий рівень відповідає більшою мірою агрегації даних за відповідним виміром.

Виконавець може визначатися напрямом консолідації, що складається з рівнів узагальнення "підприємство – підрозділ – відділ – службовець". Вимір Час може навіть включати два напрями консолідації - "рік - квартал - місяць - день" і "тиждень - день", оскільки рахунок часу за місяцями та тижнями несумісний. У цьому випадку стає можливим довільний вибір бажаного рівня деталізації інформації щодо кожного з вимірів. Операція спуску (drilling down) відповідає руху від найвищих ступенів консолідації до нижчих; навпаки, операція підйому (rolling up) означає рух від нижчих рівнів до вищих.

Кодд визначив 12 правил, яким має задовольняти програмний продукткласу OLAP.

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

Багатовимірне концептуальне подання даних (Multi Dimensional Conceptual View). Концептуальне представлення моделі даних у продукті OLAP має бути багатовимірним за своєю природою, тобто дозволяти аналітикам виконувати інтуїтивні операції "аналізу вздовж і поперек" ("slice and dice"), обертання (rotate) та розміщення (pivot) напрямків консолідації. Прозорість (Transparency). Користувач не повинен знати про те, які конкретні засоби використовуються для зберігання та обробки даних, як дані організовані та звідки беруться.

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

Стійка продуктивність (Consistent Reporting Performance). Зі збільшенням числа вимірювань та розмірів бази даних аналітики не повинні зіткнутися з будь-яким зменшенням продуктивності. Стійка продуктивність необхідна для підтримки простоти використання та свободи від ускладнень, які потрібні для доведення OLAP до кінцевого користувача.

Клієнт – серверна архітектура (Client-Server Architecture). Більшість даних, потребують оперативної аналітичної обробки, зберігається в мейнфреймових системах, а витягується з персональних комп'ютерів. Тому однією з вимог є здатність продуктів OLAP працювати серед клієнт-сервер. Головною ідеєю тут є те, що серверний компонент інструменту OLAP повинен бути досить інтелектуальним і мати здатність будувати загальну концептуальну схему на основі узагальнення та консолідації різних логічних та фізичних схем корпоративних баз даних для забезпечення ефекту прозорості.

Рівноправність вимірів (Generic Dimensionality). Усі виміри даних мають бути рівноправними. Додаткові характеристики можуть бути надані окремим вимірам, але оскільки всі вони симетричні, ця додаткова функціональність може бути надана будь-якому виміру. Базова структура даних, формули та формати звітів не повинні спиратися на один вимір.

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

Підтримка розрахованого на багато користувачів режиму (Multi-User Support). Часто кілька аналітиків мають потребу працювати одночасно з однією аналітичною моделлю або створювати різні моделіна основі одних корпоративних даних. Інструмент OLAP повинен надавати їм конкурентний доступ, забезпечувати цілісність та захист даних.

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

Інтуїтивне маніпулювання даними (Intuitive Data Manipulation). Переорієнтація напрямків консолідації, деталізація даних у колонках і рядках, агрегація та інші маніпуляції, властиві структурі ієрархії напрямків консолідації, повинні виконуватися в максимально зручному, природному та комфортному інтерфейсі користувача.

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

Необмежена кількість вимірювань та рівнів агрегації (Unlimited Dimensions and Aggregation Levels). Настійно рекомендується припущення в кожному серйозному інструменті OLAP як мінімум п'ятнадцяти, а краще двадцяти, вимірювань в аналітичній моделі.

2 Компоненти OLAP

2.1 Сервер. Клієнт. Інтернет

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

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

Сервер Прикладною частиною системи OLAP є сервер OLAP. Ця складова виконує всю роботу (залежно від моделі системи) і зберігає в собі всю інформацію, до якої забезпечується активний доступ. Архітектурою сервера управляють різні концепції. Зокрема, основною функціональною характеристикою OLAP-продукту є використання зберігання багатомірної (ММБД, MDDB) чи реляційної (РДБ, RDB) бази даних. Агреговані/Попередньо агреговані дані

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

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

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

Незважаючи на те, що сервер - це як би "хребет" OLAP-рішення, клієнт не менш важливий. Сервер може забезпечити міцний фундамент для полегшення маніпуляцій з даними, але якщо клієнт складний або малофункціональний, користувач зможе скористатися всіма перевагами потужного сервера. Клієнт настільки важливий, що багато постачальників зосереджують свої зусилля виключно на розробці клієнта. Все, що включається до складу цих додатків, є стандартним поглядом на інтерфейс, заздалегідь певні функціїта структуру, а також швидкі рішеннядля більш менш стандартних ситуацій. Наприклад, популярні фінансові пакети. Заздалегідь створені фінансові програми дозволять спеціалістам використовувати звичні фінансові інструменти без необхідності проектувати структуру бази даних або загальноприйняті форми та звіти. Інструмент запитів/генератор звітів. Інструмент запитів або генератор звітів пропонує простий доступ до даних OLAP. Вони мають простий у використанні графічний інтерфейсі дозволяють користувачам створювати звіти переміщенням об'єктів до звіту методом "drag and drop". Тоді як традиційний генератор звітів дає користувачеві можливість швидко випускати форматовані звіти, генератори звітів, які підтримують OLAP, формують актуальні звіти. Кінцевий продукт є звітом, що має можливості поглиблення в дані до рівня подробиць, обертання (півотинг) звітів, підтримки ієрархій та ін. Add-Ins (доповнення) електронних таблиць.

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

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

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

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

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

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

2.2 OLAP – клієнти

OLAP-клієнти із вбудованою OLAP-машиною встановлюються на ПК користувачів. Вони не вимагають сервера для обчислень, і їм властиво нульове адміністрування. Такі клієнти дозволяють користувачеві налаштуватися на існуючі бази даних; як правило, при цьому створюється словник, який приховує фізичну структуру даних за її предметним описом, зрозумілим фахівцю. Після цього OLAP-клієнт виконує довільні запити і їх відображає в OLAP-таблиці. У цій таблиці, у свою чергу, користувач може маніпулювати даними та отримувати на екрані або папері сотні різних звітів. OLAP-клієнти, призначені для роботи з РСУБД, дозволяють аналізувати дані, що вже є в корпорації, наприклад зберігаються в БД OLTP . Однак другим їх призначенням може бути швидке та дешеве створення сховищ або вітрин даних - у цьому випадку програмістам організації потрібно лише створити сукупності таблиць типу "зірка" у реляційних БД та процедури завантаження даних. Найбільш трудомістка частина роботи - написання інтерфейсів з численними варіантами запитів і звітів - реалізується в OLAP-клієнті буквально за кілька годин. Кінцевому користувачеві для освоєння такої програми потрібно близько 30 хвилин. OLAP-клієнти поставляються самими розробниками баз даних як багатовимірних, так і реляційних. Це SAS Corporate Reporter, що є майже еталонним за зручністю та красою продуктом, Oracle Discoverer, комплекс програм MS Pivot Services та Pivot Table та ін. проводить корпорацію Microsoft. Як правило, вони є покращеними варіантами Pivot Table та розраховані на використання у MS Office або Web-браузері. Це продукти фірм Matryx, Knosys і т. д., завдяки простоті, дешевизні та ефективності, що набули величезної популярності на Заході.

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

3.1 Багатовимірний OLAP

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

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

2. Системи оперативної аналітичної обробки реляційних даних (ROLAP) дозволяють подавати дані, що зберігаються в реляційній базі, в багатовимірній формі, забезпечуючи перетворення інформації в багатовимірну модель через проміжний шар метаданих. До цього класу відносяться DSS Suite компанії MicroStrategy, MetaCube компанії Informix, DecisionSuite компанії Information Advantage та інші. Програмний комплексІнфовізор, розроблений в Росії, в Іванівському державному енергетичному університеті, також є системою цього класу. ROLAP-системи добре пристосовані до роботи з великими сховищами. Подібно до систем MOLAP, вони вимагають значних витрат на обслуговування фахівцями з інформаційним технологіямі передбачають розрахований на багато користувачів режим роботи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Частково вирішують цю проблему розширення мови SQL (оператори GROUP BY CUBE", "GROUP BY ROLLUP" та "GROUP BY GROUPING SETS"), крім того, пропонується механізм пошуку компромісу між надмірністю та швидкодією, рекомендуючи створювати таблиці фактів не для всіх можливих поєднань вимірювань , а тільки для тих, значення осередків яких не можуть бути отримані за допомогою наступної агрегації повніших таблиць фактів (Додаток В).

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

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

Висновок

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

Це такі:

Звідки надходять дані? – Дані, які підлягають аналізу, можуть бути у різних місцях. Можливо, що база даних OLAP отримуватиме їх із корпоративного Сховища даних або з OLTP-системи. Якщо OLAP-продукт вже має можливість отримати доступ до якогось джерела даних, процеси категоризації та очищення даних скорочуються.

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

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

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

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

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

Глосарій

1 Голіціна О.Л., Максимов Н.В., Попов І.І. Бази даних: Навчальний посібник. - М.: ФОРУМ: ІНФРА-М, 2003. - 352 с.

2 Дейт К. Введення у системи баз даних. - М.: Hаука, 2005 - 246 с.

3 Єлманова Н.В., Федоров А.А. Введення в OLAP технології Microsoft. - М.: Діалог-МІФІ, 2004. - 312 с.

4 Карпова Т.С. Бази даних: моделі, розробка, реалізація. - СПб.: Пітер, 2006. - 304 с.

5 Коровкін С. Д., Левенець І. А., Ратманова І. Д., Старих В. А., Щавельов Л. В. Вирішення проблеми комплексного оперативного аналізу інформації сховищ даних // СУБД. – 2005. – № 5-6. – 47-51 с.

6 Кречетов Н., Іванов П. Продукти інтелектуального аналізу даних ComputerWeek-Москва. – 2003. – № 14-15. – 32-39 с.

7 Пржиялковський В. В. Складний аналізДані великого обсягу: нові перспективи комп'ютеризації // СУБД. – 2006. – № 4. – 71-83 с.

8 Сахаров А. А. Концепція побудови та реалізації інформаційних систем, орієнтованих аналіз даних // СУБД. – 2004. – № 4. – 55-70 с.

9 Ульман Дж. Основи систем баз даних. - М.: Фінанси та статистика, 2003. - 312 c.

10 Хаббард Дж. Автоматизоване проектування баз даних. - М.: Світ, 2007. - 294 с.

Коровкін С. Д., Левенець І. А., Ратманова І. Д., Старих В. А., Щавельов Л. В. Вирішення проблеми комплексного оперативного аналізу інформації сховищ даних // СУБД. – 2005. – № 5-6. – 47-51 с.

Ульман Дж. Основи систем баз даних. - М.: Фінанси та статистика, 2003. - 312 c.

Барсегян А.А., Купріянов М.С. Технології аналізу даних: DataMining, VisualMining, TextMining, Olap. - СПб.: BHV-Петербург, 2007. - 532 с.

Єлманова Н.В., Федоров А.А. Введення в OLAP технології Microsoft. - М.: Діалог-МІФІ, 2004. - 312 с.

Дейт К. Введення у системи баз даних. - М.: Hаука, 2005 - 246 с.

Голіцина О.Л., Максимов Н.В., Попов І.І. Бази даних: Навчальний посібник. - М.: ФОРУМ: ІНФРА-М, 2003. - 352с.

Сахаров А. А. Концепція побудови та реалізації інформаційних систем, орієнтованих на аналіз даних // СУБД. – 2004. – № 4. – 55-70 с.

Пржиялковський У. У. Складний аналіз даних великого обсягу: нові перспективи комп'ютеризації // СУБД. – 2006. – № 4. – 71-83 с.

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

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

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

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

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

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

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

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.

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

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

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

Метою курсової роботи є вивчення технології 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-аналізу є перевірка гіпотез, що виникають.