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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MOLAP.

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

ROLAP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Продаж.

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

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

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

3. Ціни.

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

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

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

5. Склад.

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

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

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

7. Бюджет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

p align="justify"> З концепцією багатовимірного аналізу даних тісно пов'язують оперативний аналіз, який виконується засобами OLAP-систем.

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

Основне призначення OLAP-систем - підтримка аналітичної діяльності, довільних (часто використовують термін ad-hoc) запитів користувачів-аналітиків. Мета OLAP-аналізу - перевірка гіпотез, що виникають.

Біля джерел технології OLAP стоїть основоположник реляційного підходу Е. Кодд. У 1993 р. він опублікував статтю під назвою «OLAP для користувачів-аналітиків: якою вона має бути». У цій роботі викладено основні концепції оперативної аналітичної обробки та визначено наступні 12 вимог, яким повинні задовольняти продукти, що дозволяють виконувати оперативну аналітичну обробку. Токмак Г.П. Бази даних. Концепція бази даних, реляційна модель даних, мови SQL. С. 51

Нижче наведено 12 правил, викладених Коддом та визначальних OLAP.

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

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

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

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

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

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

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

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

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

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

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

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

Додаткові правила Кодда.

Набір цих вимог, що послужили де-факто визначенням OLAP, досить часто викликає різні нарікання, наприклад правила 1, 2, 3, 6 є вимогами, а правила 10, 11 - неформалізованими побажаннями. Токмак Г.П. Бази даних. Концепція бази даних, реляційна модель даних, мови SQL. С. 68 Таким чином, перераховані 12 вимог Кодда не дозволяють точно визначити OLAP. У 1995 р. Кодд до переліку додав такі шість правил:

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

14. Підтримка всіх моделей OLAP-аналізу - OLAP-система повинна підтримувати всі чотири моделі аналізу даних, визначені Коддом: категоріальну, тлумачну, умоглядну та стереотипну.

15. Обробка ненормалізованих даних - OLAP-система має бути інтегрована з ненормалізованими джерелами даних. Модифікації даних, виконані серед OLAP, не повинні призводити до змін даних, збережених у вихідних зовнішніх системах.

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

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

18. Обробка відсутніх значень - OLAP-система повинна ігнорувати всі відсутні значення без урахування їхнього джерела. Ця особливість пов'язана із 17-м правилом.

Крім того, Кодд розбив усі 18 правил на наступні чотири групи, назвавши їх особливостями. Ці групи отримали назви, S, R і D.

Основні особливості (В) включають такі правила:

Багатовимірне концептуальне представлення даних (правило 1);

Інтуїтивне маніпулювання даними (правило 10);

Доступність (правило 3);

Пакетне вилучення проти інтерпретації (правило 13);

Підтримка всіх моделей OLAP-аналізу (Правило 14);

Архітектура "клієнт-сервер" (правило 5);

Прозорість (правило 2);

Розрахована на багато користувачів підтримка (правило 8)

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

обробка ненормалізованих даних (правило 15);

збереження результатів OLAP: зберігання їх окремо від вихідних даних (правило 16);

Виняток відсутніх значень (правило 17);

Обробка відсутніх значень (Правило 18). Особливості подання звітів (R):

гнучкість формування звітів (правило 11);

Стандартна продуктивність звітів (Правило 4);

Автоматичне налаштування фізичного рівня (змінене оригінальне правило 7).

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

Універсальність вимірів (правило 6);

Необмежену кількість вимірювань та рівнів агрегації (правило 12);

Необмежені операції між розмірами (Правило 9).

Вступ

В наш час без систем управління базами даних не обходиться практично жодна організація, особливо серед тих, які традиційно орієнтовані взаємодію з клієнтами. Банки, страхові компанії, авіа- та інші транспортні компанії, мережі супермаркетів, телекомунікаційні та маркетингові фірми, організації, зайняті у сфері послуг та інші - всі вони збирають та зберігають у своїх базах гігабайти даних про клієнтів, продукти та сервіси. Цінність подібних відомостей безсумнівна. Такі бази даних називають операційними або транзакційними, оскільки вони характеризуються величезною кількістю невеликих транзакцій або операцій запису-читання. Комп'ютерні системи, що здійснюють облік операцій та власне доступ до баз транзакцій, прийнято називати системами оперативної обробки транзакцій (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 та ін. Багато програм, призначених для роботи з MS OLAP Services, поставляються в рамках кампанії "OLAP в маси", яку проводить корпорацію 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	BI-інструменти	Інструменти та технології, що використовуються для доступу до інформації. Включають OLAP-технології, data mining та складний аналіз; засоби кінцевого користувача та інструменти побудови нерегламентованих запитів, інструментальні панелі для моніторингу господарської діяльності та генератори корпоративної звітності.
2	On-line Analitic Processing, OLAP (Оперативна аналітична обробка)	Технологія аналітичної обробки інформації в режимі реального часу, що включає складання та динамічну публікацію звітів та документів.
3	Slice and Dice (Поздовжні та поперечні зрізи, дослівно - "нарізка на скибочки та кубики")	Термін, що використовується для опису складного аналізу даних, що забезпечується засобами OLAP. Вибірка даних із багатовимірного куба із заданими значеннями та заданим взаємним розташуванням вимірювань.
4	Обертання (півотинг) даних (Data Pivot)	Процес обертання таблиці з даними, тобто перетворення стовпців у рядки та навпаки.
5	Обчислений елемент (Calculated member)	Елемент виміру, чия величина визначається величинами інших елементів (наприклад, математичними чи логічними додатками). Обчислений елемент може бути частиною OLAP сервера або бути описаний користувачем протягом інтерактивної сесії. Обчислений елемент - це будь-який елемент, який вводиться, а обчислюється.
6	Глобальні бізнес-моделі (Global Business Models)	Тип Сховища даних, що забезпечує доступ до інформації, яка розподілена за різними системами підприємства і знаходиться під контролем різних підрозділів або відділів з різними базами даних та моделями даних. Такий тип Сховища даних важкий для побудови через необхідність об'єднання зусиль користувачів різних підрозділів розробки загальної моделі даних для Сховища.
7	Видобуток даних (Data Mining)	Технічні прийоми, що використовують програмні інструменти, призначені для такого користувача, який, як правило, не може заздалегідь сказати, що він шукає, а може вказати лише певні зразки та напрямки пошуку.
8	Клієнт/Сервер (Client/Server)	Технологічний підхід, що полягає у розподілі процесу на окремі функції. Сервер виконує кілька функцій - управління комунікаціями, забезпечення обслуговування бази даних та ін. Клієнт виконує індивідуальні функції користувача - забезпечення відповідних інтерфейсів, виконання міжекранної навігації, надання функцій допомоги (help) та ін.
9	Багатовимірна база даних, СУMБД (Multi-dimensional Database, MDBS and MDBMS)	Потужна база даних дозволяє користувачам аналізувати великі обсяги даних. База даних зі спеціальною організацією зберігання - кубами, що забезпечує високу швидкість роботи з даними, що зберігаються як сукупність фактів, вимірювань та заздалегідь обчислених агрегатів.
10	Поглиблення у дані (Drill Down)	Метод вивчення детальних даних, що використовується під час аналізу сумарного рівня даних. Рівні "поглиблення" залежать від ступеня деталізації даних [ранилище.
11	Центральне Сховище (Central Warehouse)	1. База даних, що містить дані, що збираються з операційних систем організації. Має структуру, зручну для аналізу даних. Призначена для підтримки прийняття рішень та створення єдиного інформаційного простору корпорації. 2. Спосіб автоматизації, що охоплює всі інформаційні системи, що керуються з одного місця.

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 с.

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

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

Розміщено на http://www.allbest.ru/

Курсова робота

з дисципліни: Бази даних

Тема: ТехнологіяOLAP

Виконав:

Чижиков Олександр Олександрович

Вступ

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

2. OLAP-клієнт - OLAP-сервер: "за" та "проти"

3. Ядро системи OLAP

3.1 Принципи побудови

Висновок

Список використаних джерел

Програми

Введення

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

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

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

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

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

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

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

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

Shared (розділений).Система повинна надавати широкі можливості розмежування доступу до даних та одночасної роботи багатьох користувачів.

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

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

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

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

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

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

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

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

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

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

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

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

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

2. OLAP-клієнт - OLAP-сервер: "за" та "проти"

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

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

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

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

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

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

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

Схема 1. Залежність продуктивності клієнтських та серверних OLAP-засобів від збільшення обсягу даних

Швидкісні характеристики сервера OLAP менш чутливі до зростання обсягу даних. Це пояснюється різними технологіями обробки запитів користувачів OLAP-сервером та OLAP-клієнтом. Наприклад, при операції деталізації OLAP-сервер звертається до даних, що зберігаються, і "витягує" дані цієї "гілки". OLAP-клієнт же обчислює весь набір агрегатів у момент завантаження. Однак до певного обсягу даних продуктивність серверних та клієнтських засобів є порівнянною. Для OLAP-клієнтів, що підтримують розподілені обчислення, область сумісності продуктивності може поширюватися на обсяги даних, що покривають потреби в OLAP-аналізі величезної кількості користувачів. Це підтверджують результати внутрішнього тестування MS OLAP Server та OLAP-клієнта "Контур Стандарт". Тест виконаний на ПК IBM PC Pentium Celeron 400 МГц, 256 Mb для вибірки в 1 мільйон унікальних (тобто агрегованих) записів із 7 вимірами, що містять від 10 до 70 членів. Час завантаження куба в обох випадках не перевищує 1 секунди, а виконання різних OLAP-операцій (drill up, drill down, move, filter та ін) виконується за соті частки секунди.

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

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

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

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

Аналогічним чином, ціла низка OLAP-клієнтів дозволяє реалізувати ROLAP- і Desktop-архітектуру з прямим доступом до БД. Це забезпечує аналіз вихідних даних у режимі on-line.

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

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

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

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

Тому там, де застосовується OLAP-клієнт, мережевий трафік буде вищим.

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

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

Тому в переважній більшості випадків аналіз БД "середніх" розмірів за допомогою OLAP-клієнта не гальмуватиме роботу користувача.

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

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

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

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

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

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

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

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

Пояснимо принцип роботи ROLAP-клієнта на прикладі створення динамічного звіту про продаж (див. схему 2). Нехай вихідні дані для аналізу зберігаються у двох таблицях: Sales та Deal.

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

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

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

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

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

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

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

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

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

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

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

3. Ядро системи OLAP

3.1 Принципи побудови

додаток клієнтський ядро ​​дані

З уже сказаного, ясно, що механізм OLAP є на сьогодні одним із найпопулярніших методів аналізу даних. Є два основні підходи до вирішення цього завдання. Перший називається Multidimensional OLAP (MOLAP) - реалізація механізму з допомогою багатомірної бази даних за сервера, а другий Relational OLAP (ROLAP) - побудова кубів " на льоту " з урахуванням SQL запитів до реляційної СУБД. Кожен із цих підходів має свої плюси та мінуси. Їхній порівняльний аналіз виходить за рамки цієї роботи. Тут буде описано лише реалізацію ядра настільного ROLAP модуля.

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

В Інтернеті та пресі можна знайти багато інформації про OLAP системи, але практично ніде не сказано про те, як це влаштовано всередині.

Схема роботи:

Загальну схему роботи настільної системи OLAP можна представити так:

Схема 3. Робота настільної системи OLAP

Алгоритм роботи наступний:

1.Отримання даних у вигляді плоскої таблиці або результату виконання запиту SQL.

2.Кешування даних та перетворення їх до багатовимірного куба.

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

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

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

Таким чином, таблицю можна розділити на такі елементи, з якими ми і працюватимемо надалі:

Заповнюючи матрицю з фактами, ми маємо діяти так:

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

Визначити координати стовпців і рядків підсумків, на які впливає елемент, що додається.

Додати елемент у матрицю та відповідні стовпці та рядки підсумків.

При цьому потрібно відзначити те, що отримана матриця буде сильно розрідженою, чому її організація у вигляді двомірного масиву (варіант, що лежить на поверхні) не тільки нераціональна, але, швидше за все, і неможлива у зв'язку з великою розмірністю цієї матриці, для зберігання якої вистачить жодного обсягу оперативної пам'яті. Наприклад, якщо наш куб містить інформацію про продаж за один рік, і якщо в ньому буде всього 3 виміри - Клієнти (250), Продукти (500) і Дата (365), то ми отримаємо матрицю фактів наступних розмірів: кількість елементів = 250 х 500 х 365 = 45 625 000. І це при тому, що заповнених елементів у матриці може бути лише кілька тисяч. Причому чим більше кількість вимірювань, тим більш розрідженою буде матриця.

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

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

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

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

Схема 4. Структура збереження унікальних значень

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

Описані вище ідеї були покладені в основу створення бібліотеки компонентів CubeBase.

Схема 5. Структура бібліотеки компонентів CubeBase

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

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

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

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

Схематично перетворення можна представити так:

Схема 6. Перетворення бази даних внутрішнього формату на нормалізовану базу даних

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

Схема 7. Перенумерація нормалізованої БД визначення координат значень вимірювань

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

Схема 8. Внутрішнє уявлення гіперкубу

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

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

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

перевірка наявності елемента у словнику;

додавання елемента до словника;

пошук номерів записів, що мають конкретне значення координати;

пошук координати за значенням виміру;

пошук значення виміру за його координатою.

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

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

додавання нового значення;

визначення координати за значенням виміру;

визначення значення координати.

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

PFactLink = ^TFactLink;

TFactLink = record

FactNo: integer; // Індекс факту в таблиці

TDimensionRecord = record

Value: string; // Значення виміру

Index: integer; // значення координати

FactLink: PFactLink; // покажчик початку списку елементів таблиці фактів

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

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

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

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

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

Додаток С

При цьому значення вимірювання логічно зберігати посилання на відповідний елемент таблиці вимірювань багатовимірного куба. Це дозволить скоротити витрати пам'яті для зберігання зрізу та прискорити роботу. Як батьківські та дочірні вузли також використовуються посилання.

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

додатокD

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

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

Тепер розглянемо, у якому вигляді необхідно уявити значення всередині стовпців - тобто як визначити потрібний рядок. Для цього можна використати кілька підходів. Найпростішим було б уявити кожен стовпець у вигляді вектора, але оскільки він буде сильно розрідженим, то пам'ять витрачатиметься вкрай неефективно. Щоб уникнути цього, застосуємо структури даних, які забезпечать більшу ефективність представлення розріджених одновимірних масивів (векторів). Найпростіший із них буде звичайний список, одно- або двозв'язний, однак він неекономічний з точки зору доступу до елементів. Тому використовуватимемо дерево, яке забезпечить швидший доступ до елементів.

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

Схема 9. Зображення зведеної таблиці як двійкового дерева

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

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

1.Визначити номери рядків, до яких додаються елементи

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

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

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

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

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

Першим продуктом, що виконує запити OLAP, був Express (компанія IRI). Проте сам термін OLAP був запропонований Едгаром Коддом, «батьком реляційних БД». А робота Кодда фінансувалася Arbor, компанією, що випустила свій власний OLAP-продукт – Essbase (пізніше куплений Hyperion, яка у 2007 р. була поглинена компанією Oracle) – роком раніше. Інші добре відомі OLAP-продукти включають Microsoft Analysis Services (раніше називалися OLAP Services, частина SQL Server), Oracle OLAP Option, DB2 OLAP Server від IBM (фактично EssBase з доповненнями від IBM), SAP BW, продукти Brio, BusinessObjects, Cognos, MicroStrategy та інших виробників.

З технічної точки зору, представлені на ринку продукти поділяються на "фізичний OLAP" та "віртуальний". У першому випадку є програма, що виконує попередній розрахунок агрегатів, які потім зберігаються в спеціальну багатовимірну БД, що забезпечує швидке вилучення. Прикладами таких продуктів є Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay. У другому випадку дані зберігаються в реляційних СУБД, а агрегати можуть не існувати взагалі або створюватися на перший запит у СУБД або кеші аналітичного ПЗ. Приклади таких продуктів – SAP BW, BusinessObjects, Microstrategy. Системи, що мають у своїй основі "фізичний OLAP", забезпечують стабільно кращий час відгуку на запити, ніж системи "віртуальний OLAP". Постачальники систем "віртуальний OLAP" заявляють про більшу масштабованість їх продуктів щодо підтримки дуже великих обсягів даних.

У цій роботі я хотів би детальніше розглянути продукт компанії BaseGroup Labs - Deductor.

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

Склад системи:

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

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

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

4. Client-Server

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

Принципи роботи:

1. Імпорт даних

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

2. Експорт даних

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

3. Обробка даних

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

4. Візуалізація

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

5. Механізми інтеграції

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

6. Тиражування знань

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

Звиключення

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

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

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

Подібні документи

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

реферат, доданий 12.10.2010


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

курсова робота , доданий 25.12.2013


Вічне зберігання даних. Сутність та значення засобу OLAP (On-line Analytical Processing). Бази та сховища даних, їх характеристика. Структура, архітектура зберігання даних, постачальники. Декілька порад щодо підвищення продуктивності OLAP-кубів.

контрольна робота , доданий 23.10.2010


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

курсова робота , доданий 19.09.2008


Основні відомості про OLAP. Оперативне аналітичне оброблення даних. Класифікація товарів OLAP. Вимоги до засобів оперативної аналітичної обробки. Використання багатовимірних БД у системах оперативної аналітичної обробки, їх переваги.

курсова робота , доданий 10.06.2011


Розробка підсистем аналізу веб-сайту за допомогою Microsoft Access та Olap-технологій. Теоретичні аспекти розробки підсистеми аналізу даних інформаційної системі музичного порталу. Olap-технології у підсистемі аналізу об'єкта дослідження.

курсова робота , доданий 06.11.2009


Розгляд OLAP-засобів: класифікація вітрин та сховищ інформації, поняття куба даних. Архітектура системи підтримки прийняття рішень. Програмна реалізація системи "Abitura". Створення Web-звіту за допомогою технологій Reporting Services.

курсова робота , доданий 05.12.2012


Сховище даних, принципи організації. Процеси роботи із даними. OLAP структура, технічні аспекти багатовимірного зберігання даних. Integration Services, заповнення сховищ та вітрин даних. Можливості систем із використанням технологій Microsoft.

курсова робота , доданий 05.12.2012


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

контрольна робота , доданий 19.12.2015


Призначення сховищ даних. Архітектура SAP BW. Побудова аналітичної звітності на основі OLAP-кубів у системі SAP BW. Основні відмінності між сховищем даних та системою OLTP. Огляд функціональних галузей BEx. Створення запиту у BEx Query Designer.