konspect_2010

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

6.СППР побудована за принципом інтерактивного розв’язування

задач.

Користувач має змогу підтримувати діалог із СППР в безпе-

рервному режимі, а не обмежуватися видаванням окремих команд

знаступним очікуванням результатів.

7.СППР зорієнтована на гнучкість та адаптивність для пристосування до змін середовища чи підходів до розв’язування задач, що їх обирає користувач.

Керівник має пристосуватися до змінюваних умов сам і відповідно підготувати систему.

Еволюція та адаптація системи мають бути поєднані з її життєвим циклом.

8.СППР не повинна нав’язувати користувачеві певного процесу прийняття рішень.

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

СППР складається з трьох основних підсистем:

інтерфейсу користувача, який дає змогу особі, котра приймає рішення (ОПР), провадити діалог із системою, використовуючи різні програми вводу, формати і технології виводу;

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

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

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

1.8.2 Інтерфейс користувач–система

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

Фактично, для ОПР система підтримки прийняття рішення — це інтерфейс користувача. Інтерфейс користувача охоплює всі механізми,

80

якими команди, запити і дані вводяться в систему підтримки прийняття рішення, так само як і всі методи, якими результати та інформація виводяться системою.

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

Iнтерфейс користувач–система забезпечує зв’язок ОПР із СППР та її компонентами. При проектуванні й розробці інтерфейсу необхідно додержувати певного еталона, який має три ключові аспекти:

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

мову відображення — що бачить користувач у результаті роботи системи. Варіанти вибору щодо мови відображення досить різноманітні: використання знакових чи рядкових принтерів, екранів, графічних засобів, кольору, графопобудовачів, звукового виводу тощо;

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

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

Можна вирізнити три центральних механізми для організації взаємодії користувачів із СППР:

формальний діалог, що ґрунтується на «кмітливості» комп’ютера з урахуванням структури його як віртуальної машини;

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

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

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

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

2. Щодо компонента діалогу між користувачем і системою — мінімізувати складність задач вводу даних користувачем та ймовірність

81

помилок вводу. Передбачити альтернативні методи вводу. Ретельно визначити процедуру обробки помилок.

3.Підтримувати сумісність відображуваної інформації та діалогу по всій СППР.

4.З метою повторного входу до системи (якщо користувач перервав роботу із СППР) необхідно передбачити засоби зберігання виконаної роботи і забезпечити «дружній» режим повторного входу.

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

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

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

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

8.Для прийому зовнішніх даних у СППР необхідно вмонтувати засоби інформаційного зв’язку.

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

Iнтерфейс, що грунтується на меню

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

Адаптований інтерфейс

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

82

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

Iнтерфейс на базі природної мови

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

Графічні засоби для удосконалення діалогу користувач-система

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

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

графічні пояснювальні засоби на основі аналогії;

графічні засоби переміщення (навігації) по системі.

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

Вмонтоване моделювання процесів з метою контролю за станом системи і для управління — це метод, спрямований на те, щоб дати користувачеві змогу бачити вигляд «згори» усіх функцій, задач і підзадач, які він зможе виконати за допомогою системи. У СППР дуже часто просто неможливо «побачити» загальну структуру процесу розв’язування задачі, яку підтримує система. Вмонтовані моделі саме і є діалоговими вказівками (компасами), завдяки яким користувачеві вже неможливо «загубитися».

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

83

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

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

1.8.3 База даних і система управління базою даних

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

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

84

даних, які використовуються для вивчення і звертання до даних, належить мова опису даних (МОД) і мова маніпулювання даними (ММД).

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

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

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

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

1.8.4 Бази моделей і системи управління базами моделей

Дані та моделі є центральними елементами СППР. Фактичне СППР відрізняється від АIС наявністю інтерактивних програм (з їх допомогою користувач може досліджувати і «мандрувати» по базах даних різних форм, різмірів і типів) та бази моделей (усередині її користувач може конструювати, аналізувати, інтерпретувати одну чи кілька моделей).

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

85

База моделей СППР містить оптимізаційні і неоптимізаційні моделі. До складу оптимізаційних моделей належать моделі математичного програмування — лінійного (розподіл ресурсів, оптимальне планування, аналіз сіткових графіків, транспортна задача), нелінійного, динамічного; моделі обліку; моделі аналізу цінних паперів для визначення інвестиційної стратегії; моделі маркетингу і т.ін.

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

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

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

Основні функції СУБМ такі:

створення нових моделей;

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

зв’язування компонентів моделей у базі моделей;

інтеграція складових елементів моделей;

виконання набору загальних функцій управління СУБМ.

1.8.5 Управління поштою (повідомленнями) в СППР

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

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

86

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

1.9Створення СППР на основі сховища даних [1, 10]

1.9.1 Формування концепції сховища даних

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

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

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

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

87

1.9.2 Технологія розробки і впровадження Сховища Даних

Етапи проекту

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

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

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

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

об'єднує управляючі потоки та інформаційні потоки;

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

Іншими словами, бізнес-подія є стійкішим і більш тісно пов'язаним з інформаційними потоками поняттям, ніж бізнес-процес.

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

88

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

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

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

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

Вибір моделі даних Сховища

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

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

OLAP - системи побудовані на двох базових принципах:

89