ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.12.2020
Просмотров: 1222
Скачиваний: 2
95
При описі технології заповнення Сховища будемо розрізняти три
взаємозалежні задачі: Збір Даних (Data Acquisition), Очищення Даних (Data
Cleansing) і Агрегування Даних (Data Consolidation).
Під Збором Даних будемо розуміти процес, що полягає в організації
передачі даних із зовнішніх джерел у Сховище. Лише деякі аспекти цього
процесу цілком або частково автоматизовані в наявних продуктах.
Насамперед, це відноситься до інтерфейсів з існуючими БД. Як правило,
тут існує кілька можливостей. По-перше, підтримуються інтерфейси усіх
великих виробників серверів баз даних (Oracle, Informix, ADABAS і т.д.).
По-друге, практично завжди є ODBC-інтерфейс, і, по-третє, можна
витягати дані з текстових файлів у форматі CSV (comma separated values) і
з деяких структурованих файлів, наприклад файлів dBase. Набір наявних
інтерфейсів - найважливіша характеристика, що часто дозволяє оцінити,
для яких задач проектувався продукт. Так, якщо серед підтримуваних
інтерфейсів є AS/400, DB2/400, IMS, VSAM (як у популярному продукті
PASSPORT фірми Carleton), та він призначений скоріше для використання
в системах, що працюють на великих мэйнфреймах, ніж у мережі з ПК.
Під очищенням даних звичайно розуміється процес модифікації
даних по ходу заповнення Сховища: виключення небажаних дублікатів,
відновлення пропущених даних, приведення даних до єдиного формату,
видалення небажаних символів (наприклад, керуючих) і уніфікація типів
даних, перевірка на цілісність. Практично всі продукти наділені тим або
іншим набором засобів очищення даних і відповідних засобів діагностики.
При заповненні Сховища агрегованими даними ми повинні
забезпечити вибірку даних із транзакційної бази даних і інших джерел
відповідно до метаданх, оскільки агрегування відбувається в термінах
бізнес-понять. Так, наприклад, агрегована величина "обсяг продажів
продукту Х в регіоні Y за останній квартал" містить поняття "продукт" і
"регіон", що є бізнес-поняттями даного підприємства. Варто підкреслити,
що задача вибірки необхідних даних не може бути вирішена цілком
автоматично: можливі колізії (відсутність необхідних даних, помилки в
даних і т.п.), коли втручання людини виявиться необхідним. Далі,
припускаючи, що об'єктом аналізу є числові показники, зв'язані з бізнес-
поняттями, такі як ОБСЯГ ПРОДАЖІВ або ПРИБУТОК, необхідно
визначити правила обчислення цих показників для складних бізнесів-
понять, виходячи з їхніх значень для більш простих бізнес-понять. Це і є
правила агрегування.
Найпростішою архітектурою системи на основі СД є архітектура
клієнт-сервер. Традиційно саме сховище розміщується на сервері (або на
серверах), а аналіз даних виконується на клієнтах. Деяке ускладнення в цю
схему вносять Вітрини Даних. Вони також розміщуються на серверах, але,
з огляду на взаємодії між Вітринами, приходиться вводити так названі
переходники (Hub Servers), через які йде обмін даними між Вітринами.
96
Аналіз даних: OLAP
Припустимо тепер, що в загальному випадку існує корпоративне СД
і ряд Вітрин Даних. Яким чином варто організувати доступ до інформації
для аналізу? Зараз прийнята точка зору, відповідно до якої потрібно
забезпечити можливість аналізу даних як з Вітрин, так і безпосередньо зі
Сховища. Різниця тут визначається не стільки розміром бази, скільки тим,
що Вітрини, як правило, не містять детальних - неагрегованих даних. Це
означає, що аналіз даних Вітрини не вимагає глибокої деталізації і часто
може бути виконаний більш простими засобами.
Поряд з могутніми серверами багатомірних баз даних і ROLAP-
серверами на ринку пропонуються клієнтські OLAP-сервери, які
пропонуються, головним чином, для роботи з невеликими обсягами даних і
орієнтовані на індивідуального користувача. Подібні системи були названі
настільними, або DOLAP-серверами (Desktop OLAP). У цьому напрямку
працюють фірми Business Objects (Business Objects 5.0), Andyne
(CubeCreator, PaBLO), Cognos, Brio Technology.
Лідером поки вважається компанія Cognos, що поставляє продукти
PowerPlay, Impromptu і Scenario. PowerPlay - це настільний OLAP-сервер,
для витягу даних з реляційних баз даних (Paradox, dBase, Clipper),
"плоских"
файлів
і
електронних
таблиць
(Microsoft
Excel)
використовується генератор запитів і звітів Impromptu. Потім спеціальний
компонент, який називається Transformer, поміщає витягнуті дані в
клієнтську багатомірну базу, що називається PowerCube. Споживачам
надаються широкі можливості по керуванню PowerCube: передавати її від
користувача до користувача по запиту і примусово, поміщати на сервер
для поділу доступу до неї або пересилати по електронній пошті. Cognos
постаралася зробити свій продукт максимально відкритим: по-перше,
PowerCube може бути поміщений у реляційні бази Oracle, Informix, Sybase,
MS SQL Server на платформах UNIX, HP/UX, Sun Solaris, IBM AIX, по-
друге, сам PowerPlay здатний аналізувати вміст не тільки PowerCube, але й
інших багатомірних баз даних.
Варто відзначити, що всі ці фірми поєднують прагнення включити у
свої продукти компоненти, призначені для Інтелектуального Аналізу
Даних (Data Mining, ІАД). Наприклад, зусилля Business Objects і Cognos
спрямовані на підготовку остаточних версій компонентів Business Miner і
Scenario, відповідно, призначених саме для ІАД.
Необхідно також згадати про новий напрямок розвитку архітектур
систем клієнт-сервер, який називається трирівневою архітектурою клієнт-
агент-сервер. Відповідно до СППР традиційна дворівнева архітектура
враховує, що Сховище Даних або Вітрина Даних розміщуються на сервері,
а аналітична обробка і інтерфейси користувачів підтримуються клієнтом.
Можна вказати деякі умови, при яких дворівнева архітектура працює
ефективно:
97
обсяг даних, що пересилаються між клієнтом і сервером, не
дуже великий;
велика частина обчислень може бути виконана заздалегідь;
коло користувачів-клієнтів чітко визначене, так що сервер
обслуговує помірне число запитів в одиницю часу;
немає необхідності підтримувати поділ даних між клієнтами
(клієнти ізольовані один від одного);
додатки не вимагають постійних модифікацій і удосконалень.
Практика показує, що аналітична обробка, незважаючи на
підготовленість агрегованих даних у Сховищі або Вітрині, може виявитися
не такою простою задачею. Наприклад, якщо потрібно проаналізувати
відношення прибутку до витрат, можливо, цю задачу прийдеться
вирішувати динамічно, оскільки саме такого відношення в Сховище може і
не бути (при тому, що прибуток і витрати, швидше за все, там присутні).
Виконання подібних обчислень на клієнті перевантажує систему, збільшує
час відгуку, вимагає повторних обчислень при повторенні запиту або
збереження один раз обчислених значень у пам'яті клієнта. У цьому
випадку прийнято говорити, що клієнт стає "важким" (fat), що призводить
до деградації всієї системи.
У трехрівневих архітектурах між клієнтом і сервером (який тепер
називається корпоративним сервером) міститься ще один сервер, який
називається сервером додатків. Обов'язком корпоративного сервера є
робота з корпоративними даними, наприклад зі Сховищем Даних:
організація доступу до Сховища, поділ ресурсів між клієнтами і т.д. Клієнт
як і раніше реалізує інтерфейс користувача, виконує операції з даними, які
виконує користувач, і зберігає локальні дані. Сервер додатків виконує роль
посередника між клієнтом і корпоративним сервером, знижуючи
навантаження на останній.
Для даної архітектури в прикладі з пошуком відношення
прибуток/витрати обчислення цього відношення варто було б виконувати
на сервері додатків. У ROLAP-системах сервер додатків виконує з'єднання
таблиць відповідно до запиту користувача. Крім того, сервер додатків
може здійснювати динамічне агрегування даних. У DOLAP-системах
сервер додатків може зберігати клієнтські гіперкуби.
Логічний поділ системи на три рівні не означає наявності трьох
фізичних рівнів обробки. Теоретично всі три рівні можуть бути реалізовані
на одній машині. Наявність трьох логічних рівнів означає, по-перше,
жорсткий поділ обов'язків між рівнями і, по-друге, регламентацію зв'язків
між ними. Так, наприклад, клієнт не може безпосередньо звернутися до
корпоративного сервера.
1.9.3
Інтелектуальний аналіз даних
Інтелектуальний аналіз даних (ІАД) звичайно визначають як метод
підтримки прийняття рішень, заснований на аналізі залежностей між
98
даними. У рамках такого загального формулювання звичайний аналіз
звітів, побудованих в базі даних, також може розглядатися як різновид
ІАД.
Існує два підходи до автоматичного пошуку залежностей між
даними. У першому випадку користувач сам висуває гіпотези щодо
залежностей між даними. Фактично традиційні технології аналізу
розвивали саме цей підхід. Дійсно, гіпотеза приводила до побудови звіту,
аналіз звіту до висування нової гіпотези і т.д. Це справедливо і у тому
випадку, коли користувач застосовує такі засоби, як OLAP, оскільки
процес пошуку як і раніше цілком контролюється людиною. У багатьох
системах ІАД у цьому процесі автоматизована перевірка вірогідності
гіпотез, що дозволяє оцінити імовірність тих або інших залежностей у базі
даних. Типовим прикладом може служити, такий висновок: імовірність
того, що ріст продажів продукту А обумовлений ростом продажів
продукту В, складає 0,75.
Другий підхід ґрунтується на тому, що залежності між даними
шукаються автоматично. Кількість продуктів, що виконують автоматичний
пошук залежностей, говорить про зростаючий інтерес виробників і
споживачів до систем саме такого типу. Повідомляється про різкий ріст
прибутків клієнтів за рахунок вірно знайденої, заздалегідь невідомої
залежності. Згадується приклад мережі британських універсамів, де ІАД
застосовувався при аналізі збитків від розкрадань товарів у торговельних
залах. Було виявлено, що до найбільших збитків призводять розкрадання
дрібних "супутніх" товарів: ручок, батарейок і т.п. Простий перенос
прилавків з цими товарами ближче до розрахункових вузлів дозволив
знизити збитки на 100%.
Сьогодні кількість фірм, що пропонують продукти ІАД,
обчислюється десятками, однак, не розглядаючи їх докладно, приведемо
лише класифікацію процесів ІАД, що застосовуються на практиці.
Процеси ІАД розділяються на три великі групи: пошук залежностей
(discovery), прогнозування (predictive modelling) і аналіз аномалій (forensic
analysis). Пошук залежностей полягає в перегляді бази даних з метою
автоматичного виявлення залежностей. Проблема тут полягає в доборі
дійсно важливих залежностей з величезного числа існуючих у БД.
Прогнозування припускає, що користувач може пред'явити системі запис із
незаповненими полями і запросити відсутні значення. Система сама
аналізує вміст бази і робить правдоподібне прогнозування щодо цих
значень. Аналіз аномалій – це процес пошуку підозрілих даних, що сильно
відхиляються від стійких залежностей.
У системах ІАД застосовується надзвичайно широкий спектр
математичних, логічних і статистичних методів: від аналізу дерев рішень
(Business Objects) до нейроних мереж (NeoVista).
99
2
ТЕОРІЯ ПРИЙНЯТТЯ РІШЕНЬ. ПРАКТИКУМ
2.2
Лабораторна робота 1. Експертні процедури прийняття
рішень.
Методи
обробки
експертної
інформації:
одномірне
шкалювання
Завдання.
Є матриця результатів оцінювання
m
параметрів
інформаційної системи
d
експертами. Оцінити відносну важливість
параметрів
інформаційної
системи,
використовуючи
одномірне
шкалювання як метод обробки експертної інформації.
Студент самостійно ранжує об'єкти, виступаючи в ролі експертів
(набір параметрів вибирається студентом). Об'єкти ранжуються по
ступеню важливості.
Таблиця 20 – Дані результатів оцінки
№ варіанта
m d
1
6 5
2
7 4
3
8 5
4
5 6
5
6 5
6
6 4
7
5 6
8
5 5
9
5 5
10
5 5
11
7 6
12
7 6
13
8 4
14
8 4
15
9 4
16
9 4
17
5 6
18
7 6
19
6 5
20
7 4
21
8 5
22
9 4
23
5 4
24
5 7
25
6 6