OLAP технології. OLAP системи Які таблиці використовуються в olap аналізі

Головна / Усунення несправностей

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

Каталог OLAP-рішень та проектів дивіться у розділі OLAP на TAdviser.

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

Вимоги до OLAP-систем. FASMI

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

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

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

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

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

Вище ми зазначили, що OLAP передбачає багатовимірне ієрархічне подання даних, і, у певному сенсі, протиставляється системам, що базуються на РСУБД.

Це, однак, не означає, що всі OLAP-системи використовують багатовимірну модельдля зберігання активних, "робітників" даних системи. Так як модель зберігання активних даних впливає на всі диктовані FASMI-тестом вимоги, її важливість підкреслюється тим, що саме за цією ознакою зазвичай виділяють підтипи OLAP - багатовимірний (MOLAP), реляційний (ROLAP) і гібридний (HOLAP).

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

Зберігання активних даних у багатовимірній БД

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

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

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

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

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

Зберігання активних даних у реляційній БД

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

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

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

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

Зберігання активних даних у «плоських» файлах

Цей підхід передбачає зберігання порцій даних у звичайних файлах. Зазвичай він використовується як доповнення до одного з двох основних підходів для прискорення роботи за рахунок кешування актуальних даних на диску або в оперативній пам'яті клієнтського ПК.

Гібридний підхід до зберігання даних

Більшість виробників OLAP-систем, що просувають свої комплексні рішення, часто включають крім власне OLAP-системи СУБД, інструменти ETL (Extract Transform Load) та звітності, в даний час використовують гібридний підхід до організації зберігання активних даних системи, розподіляючи їх тим чи іншим чином між РСУБД та спеціалізованим сховищем, а також між дисковими структурами та кешуванням в оперативній пам'яті.

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

OLAP(англ. on-line analytical processing) – сукупність методів динамічної обробки багатовимірних запитів у аналітичних базах даних. Такі джерела даних зазвичай мають досить великий обсяг, і в засобах, що застосовуються для їх обробки, однією з найважливіших вимог є висока швидкість. У реляційних БД інформація зберігається в окремих таблицях, які добре нормалізовані. Але складні багатотабличні запити до них виконуються досить повільно. Значно кращі показники швидкості обробки в OLAP-системах досягаються за рахунок особливості структури зберігання даних. Вся інформація чітко організована, і застосовуються два типи сховищ даних: вимірювання(містять довідники, розділені за категоріями, наприклад, точки продажу, клієнти, співробітники, послуги тощо) факти(характеризують взаємодію елементів різних вимірівнаприклад, 3 березня 2010 р. продавець A надав послугу клієнту Б у магазині В на суму Г грошових одиниць). Для обчислення результатів у аналітичному кубі застосовуються заходи. Заходи є сукупністю фактів, агрегованих по відповідним вибраним вимірам та його елементам. Завдяки цим особливостям на складні запити з багатовимірними даними витрачається набагато менше часу, ніж у реляційних джерелах.

Одним з основних вендорів OLAP-систем є корпорація Microsoft. Розглянемо реалізацію принципів OLAP на практичні прикладистворення аналітичного куба у програмах Microsoft SQL Server Business Intelligence Development Studio (BIDS) та Microsoft Office PerformancePoint Server Planning Business Modeler (PPS) та ознайомимося з можливостями візуального представлення багатовимірних даних у вигляді графіків, діаграм та таблиць.

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

Спочатку визначимо виміри. З діяльності підприємства пов'язані такі сутності (категорії даних):

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

Рис.1. Таблиці вимірів та фактів в аналітичній БД. Послідовність створення
Після створення багатовимірного джерела даних BIDS є можливість переглянути його уявлення (Data Source View). У прикладі вийде схема, представлена ​​малюнку нижче.


Рис.2. Подання джерела даних (Data Source View) у Business Intellingence Development Studio (BIDS)

Як бачимо, таблиця фактів пов'язана з таблицями вимірювань у вигляді однозначної відповідності полів-ідентифікаторів (PartnerID, EmployeeID тощо).

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

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 році E. F. 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 («Спочатку запитай дані – потім аналізуй»).

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

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

До переваг другого підходу слід віднести «свіжість» інформації, яку користувач отримує у вигляді багатовимірного звіту – «мікрокуба». Мікрокуб формується на основі нової інформації з актуальної реляційної бази даних. Робота з мікрокубом здійснюється в інтерактивному режимі – отримання зрізів інформації та її деталізація в рамках мікрокуба здійснюється миттєво. Іншим позитивним моментом є те, що проектування структури та наповнення мікрокуба здійснюється користувачем "на льоту", без участі адміністратора баз даних. Однак підхід страждає і на серйозні недоліки. Користувач, який не бачить загальної картини і повинен заздалегідь визначатися із напрямком свого дослідження. В іншому випадку запитаний мікрокуб може виявитися занадто малий і не містити всіх даних, що цікавлять, а користувачеві доведеться запитувати новий мікрокуб, потім новий, потім ще і ще. Підхід 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Концепція технології OLAP була сформульована Едгаром Коддом у 1993 році.

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

Основні вимоги до додатків для багатовимірного аналізу:

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

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

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

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

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

  • - багатовимірний (Multidimensional) OLAP-MOLAP;
  • - реляційний (Relation) OLAP-ROLAP;
  • - Змішаний або гібридний (Hibrid) OLAP-HOLAP.

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

Перевагами MOLAP є:

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

До обмежень MOLAP належать:

  • - Порівняно невеликі розміри баз даних;
  • - за рахунок денормалізації та попередньої агрегації багатовимірні масиви використовують у 2,5-100 разів більше пам'яті, ніж вихідні дані (витрата пам'яті при збільшенні числа вимірювань зростає за експоненційним законом);
  • - відсутні стандарти на інтерфейс та засоби маніпулювання даними;
  • - Є обмеження під час завантаження даних.

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

Перевагами ROLAP-систем є:

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

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

Виконання цих умов дозволяє при використанні ROLAP-систем домогтися схожих з MOLAP-системами показників щодо часу доступу, а також перевершити в економії пам'яті.

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

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

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

Режим виявлення закономірностей ґрунтується на інтелектуальній обробці даних. Головним завданням тут є виявлення закономірностей у досліджуваних процесах, взаємозв'язків та взаємовпливу різних факторів, пошук великих «незвичних» відхилень, прогноз перебігу різних суттєвих процесів. Ця сфера належить до інтелектуального аналізу (Data mining).

© 2022 androidas.ru - Все про Android