konspect_2010

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

мова маніпулювання даними заснована на використанні бізнес-

понять.

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

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

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

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

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

поворот;

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

розкриття (drill-down). Одне зі значень виміру заміняється сукупністю значень з наступного рівня ієрархії виміру; відповідно замінюються значення в осередках гіперкуба;

згортка (roll-up/drill-up). Операція, зворотна розкриттю;

перетин (slice-and-dice).

У залежності від відповіді на питання, чи існує гіперкуб як окрема фізична структура або лише як віртуальна модель даних, розрізняють системи MOLAP (Multidimensional OLAP) і ROLAP (Relational OLAP). У

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

(Multidimensional Data Base, MDB), а потім ефективно обробляються

OLAP-сервером.

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

90

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

систем служать MetaCube фірми Informix і Discoverer 3.0 фірми Oracle. На практиці іноді реалізується комбінація цих підходів.

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

Вибір структури Сховища Даних

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

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

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

91

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

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

При проектуванні структури сховища часто виникає бажання використовувати якнайбільше агрегатів і за рахунок цього підвищити продуктивність системи. Неважко підрахувати, що для моделі "зірка" з 10 вимірами можна побудувати 10!=3.63 мільйона різних агрегованих значень, розміщення яких у пам'яті при встановленні зв'язків з відповідними вимірами призведе до різкого збільшення займаного дискового простору й уповільненню доступа до даних. Інша крайність полягає у використанні занадто малого числа агрегатів, а це може призвести до необхідності виконувати агрегування динамічно, що помітно знижує ефективність запитів. За деякими оцінками, при визначенні оптимальної кількості агрегатів варто дотримуватися принципу 80:20 - 80% прискорення досягається за рахунок використання 20% кандидатів на агрегати.

Вітрини Даних

Ідея Вітрини Даних (Data Mart) виникла кілька років тому, коли стало очевидно, що розробка корпоративного сховища - довгий і дорогий процес. Це обумовлено як організаційними, так і технічними причинами:

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

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

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

потрібні значні інвестиції до того, як проект почне окупатися;

як правило, потрібна значна модифікація існуючої технічної бази;

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

на етапі розробки буває важко налагодити взаємодію між розроблювачами і майбутніми користувачами Сховища.

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

92

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

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

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

Сховище Метаданных (Репозитарій)

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

Широко відомі Репозитарії, що входять до складу популярних CASE-

засобів (Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA Research)), систем розробки додатків (Developer 2000 (Oracle), Power

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

93

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

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

аналіз процесів виникнення, зміни і використання метаданих;

проектування структури збереження метаданих (наприклад, у складі реляційної бази даних);

організація прав доступу до метаданих;

блокування і розв’язок конфліктів при спільному використанні метаданих (що дуже часто виникає при зміні загальних бізнесів-понять у рамках структурного підрозділу);

поділ метаданих між Вітринами Даних;

узгодження метаданих СД із Репозитаріями CASE-засобів, застосованих при проектуванні і розробці Сховищ;

реалізації інтерфейсу користувача з Репозитарієм.

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

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

Evolutionary Technologies International або Prism Solutions (Data Warehouse

Directory).

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

Завантаження Сховища

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

94

При описі технології заповнення Сховища будемо розрізняти три взаємозалежні задачі: Збір Даних (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), через які йде обмін даними між Вітринами.

95

обсяг даних, що пересилаються між клієнтом і сервером, не дуже великий;

велика частина обчислень може бути виконана заздалегідь;

коло користувачів-клієнтів чітко визначене, так що сервер обслуговує помірне число запитів в одиницю часу;

немає необхідності підтримувати поділ даних між клієнтами (клієнти ізольовані один від одного);

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

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

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

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

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

1.9.3 Інтелектуальний аналіз даних

Інтелектуальний аналіз даних (ІАД) звичайно визначають як метод підтримки прийняття рішень, заснований на аналізі залежностей між

97

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

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

Другий підхід ґрунтується на тому, що залежності між даними шукаються автоматично. Кількість продуктів, що виконують автоматичний пошук залежностей, говорить про зростаючий інтерес виробників і споживачів до систем саме такого типу. Повідомляється про різкий ріст прибутків клієнтів за рахунок вірно знайденої, заздалегідь невідомої залежності. Згадується приклад мережі британських універсамів, де ІАД застосовувався при аналізі збитків від розкрадань товарів у торговельних залах. Було виявлено, що до найбільших збитків призводять розкрадання дрібних "супутніх" товарів: ручок, батарейок і т.п. Простий перенос прилавків з цими товарами ближче до розрахункових вузлів дозволив знизити збитки на 100%.

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

Процеси ІАД розділяються на три великі групи: пошук залежностей

(discovery), прогнозування (predictive modelling) і аналіз аномалій (forensic analysis). Пошук залежностей полягає в перегляді бази даних з метою автоматичного виявлення залежностей. Проблема тут полягає в доборі дійсно важливих залежностей з величезного числа існуючих у БД. Прогнозування припускає, що користувач може пред'явити системі запис із незаповненими полями і запросити відсутні значення. Система сама аналізує вміст бази і робить правдоподібне прогнозування щодо цих значень. Аналіз аномалій – це процес пошуку підозрілих даних, що сильно відхиляються від стійких залежностей.

У системах ІАД застосовується надзвичайно широкий спектр математичних, логічних і статистичних методів: від аналізу дерев рішень

(Business Objects) до нейроних мереж (NeoVista).

98

2ТЕОРІЯ ПРИЙНЯТТЯ РІШЕНЬ. ПРАКТИКУМ

2.2Лабораторна робота 1. Експертні процедури прийняття рішень. Методи обробки експертної інформації: одномірне шкалювання

Завдання. Є матриця результатів оцінювання m параметрів інформаційної системи d експертами. Оцінити відносну важливість параметрів інформаційної системи, використовуючи одномірне шкалювання як метод обробки експертної інформації.

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

Таблиця 20 – Дані результатів оцінки

99