лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

5.2.5. Питання проектування користувацького інтерфейсу


Загальні вимоги до проекту
користувацького інтерфейсу

Мета проектування інтерфейсу користувача — це розроблення схеми або макету екрана і інтерфейсу, щоб вони були зручними для користування й візуально привабливими. Розроблювачі інтерфейсу мають приділяти значну увагу його ергономіці, ставлячи за мету забезпечити комфортну й ефективну взаємодію користувачів зі склад­ною системою оброблення інформації, а також досягти повноти знань, які використовуються в цьому процесі. Зацікавлені користувачі системи підтримки прийняття рішень і проектувальники інфор­маційних систем мають брати активну участь у процесах проектування і оцінювання інтерфейсів користувача СППР.
Перелічимо основні принципи, що зумовлюють певний стандарт інтерфейсу користувача.
1. Щодо засобів відображення й керування — домагатися, щоб уся відображувана інформація була легко зрозумілою і користувач постійно контролював ситуацію; передбачити засоби, що допомагають користувачеві пересуватися по СППР.
2. Щодо діалогу між користувачем і системою — мінімізувати складність завдань введення даних користувачем та ймовірність помилок введення. Передбачити альтернативні методи введення. Ретельно визначити процедуру оброблення помилок.
3. Підтримувати сумісність відображуваної інформації та діалогу по всій СППР.
4. З метою повторного входу до системи (якщо користувач перервав роботу із СППР) необхідно передбачити засоби зберігання виконаної роботи і забезпечити «дружній» режим повторного входу.
5. Передбачити спеціалізовані й умонтовані засоби протоколювання (разом з бібліотекою стандартних протоколів, доступних для користувача), а також діалогове відображення протоколів, діалогові засоби підказування для полегшення розуміння протоколів.
6. Мати на увазі, що для керівників ключовим засобом інтерфейсу є графічне відображення, перетворення табличних даних на графіки й діаграми.
7. Необхідно забезпечити точні та ефективні процедури керування базою даних для завдань підтримки великих масивів даних (включаючи засоби введення й оновлення), а також створити засоби супроводження даних, куди належать форми для введення даних,
і забезпечити можливість реєстрації транзакцій з метою перевірки.
8. Для прийому зовнішніх даних у СППР необхідно вмонтувати засоби інформаційного зв’язку.
Оскільки принципи застосування користувацького інтерфейсу мають, як правило, узагальнений характер, то за виконання практичних робіт зі створення СППР необхідно ураховувати також і потреби потенційних користувачів. Типи користувачів, завдань і ситуацій, пов’язаних з прийняттям рішень, мають визначити специфічні особливості всього процесу розроблення користувацького інтерфейсу.
Для керівників вищої ланки управління конче потрібна і є доречнішою зовсім інша, ніж для керівників середньої ланки, техніка користувацького інтерфейсу; СППР, орієнтовані на швидкість реакції або на кризові ситуації, мають зовсім інші вимоги до інтерфейсу, ніж системи підтримки довгострокового планування; альтернативні контексти задач (наприклад, чи передбачається використання СППР для підтримки структурування задачі або для одержання прогнозів) також потрібно враховувати у процесі синтезу або добору формальних засобів та інструментів для компонування мов дій і відображень людино-машинного інтерфейсу.
Отже, підтримка прийняття рішень у контексті побудови людино-машинних інтерфейсів має характер, явно зорієнтований на людські якості (специфіку роботи) користувача. Слід також зазначити, що сама проблема розуміння ролі СППР з боку користувача є неоднозначною, зокрема, розрізняють пасивне й активне розуміння цієї системи.
Пасивне розуміння СППР стосується критерію простоти (дружнього ставлення) в користуванні або механізму користування системою, тобто роботи термінала, процедур введення і виведення, синтаксису використовуваного діалогу. Активне розуміння передбачає жорсткіші стандарти оцінювання системи, зокрема, ця форма розуміння потребує ставлення до СППР з погляду спроможності надання допомоги в розв’язаннях проблем, а також визначає ті характеристики інтерфейсу, які дійсно придатним до вимірювання способом підвищують можливості керівників у прийнятті рішень.
Але при оцінюванні СППР важливо аналізувати інтеграцію аспекту керування з боку користувача з процесом прийняття рішень за допомогою системи. Тому з метою створення ефективних інтерфейсів користувача СППР потрібні удосконалення в напрямі обох форм розуміння. Більше того, СППР може бути дуже дружньою з погляду комфортності роботи користувача чи навіть фактичного використання системи, але не впливати на якість прийнятих рішень. Можна також уявити ситуацію, коли СППР підвищує ефективність процесу прийняття рішень (особливо в тому разі, коли процедури і правила роботи менеджерів без системи є дуже суб’єктивними або мають очевидні дефекти), але при цьому дістає негативну оцінку з боку користувачів.
ROMC — підхід до проектування
користувацького інтерфейсу

Спрага (Sprague) і Карлсон (Carlson) 1982 року запропонували підхід до проектування СППР і особливо до інтерфейсу користувача під назвою ROMC. Їхній підхід має чотири орієнтовані на користувача аспекти: 1) Representations: зображення інформації, що передається до користувача: 2) Operations: операції з маніпулювання відображуваними даними; 3) Memory aids: допомога для пам’яті користувача; 4) Control aids: забезпечення допомоги користувачу щодо контролю СППР, тобто засобами керування.
Хоча ROMC спочатку розглядався як підхід стосовно виявлення необхідних можливостей СППР, він також може служити для створення проектів екрана і для побудови інтерфейсу користувача СППР. Чотири компоненти цього підходу можуть удосконалити проектування екрана і його компоновку (розміщення, набір інструментів), тому він може бути корисним інструмен-тальним засобом для проектування користувацького інтерфейсу СППР.
Хоча на відміну від проектування користувацьких інтерфейсів на персональних комп’ютерах, де розроблені стандарти користувацьких інтерфейсів (див. наприклад, Проектирование пользовательского интерфейса. Стандарт фирмы IBM/ Под редакцией М. Дадашова, DBS LTD, 186 с.), для проектування користувацьких інтерфейсів СППР ще не створені стандарти, проте у розпорядженні розроблювачів СППР є різні керівні вказівки з проектування інтерфейсів, існують сотні загальних принципів і до-кладних специфікацій. Наприклад, Сміт і Моз’єр склали аж 679 конкретних вказівок для розроблення програмного забезпечення користувацького інтерфейсу інформаційних систем у такому плані: 1) введення даних; 2) відображення даних; 3) послідовність керування; 4) керівництво користувача; 5) передавання даних; 6) захист даних. Розроблені й інші підходи до створення користувацьких інтерфейсів СППР.
Керівні вказівки для проектування
діалогу й інтерфейсу користувача

1992 року Шнайдерман (Ben Shneiderman) розробив кілька засадних принципів проектування, що, на його переконання, найпридатніші для діалогових систем. Ці основні принципи інтерфейсного проекту отримані евристичним шляхом завдяки досвіду проектування і використання СППР.
Постарайтеся узгодити. Цей принцип є одним із тих, що найчастіше порушуються, але є найлегшим із тих, які можна виправити і/або уникнути їх порушень. Узгоджені послідовності дій мають дотримуватися всередині подібних ситуацій; ідентична тер­мінологія повинна використовуватися в командних рядках, меню
і екранах допомоги; узгоджені команди мають застосовуватися всюди. Особливі ситуації мають бути зрозумілими і обмеженими кількісно. Система мусить виглядати, функціонувати і бути відчутною однаково всюди.
Забезпечте повсюдні скорочення (короткі форми, абревіатури) для користувачів. Як тільки зростає частота використання, то користувач бажає зменшити кількість і збільшити темпи взаємодій. Часто грамотні й досвідчені користувачі цінують скорочення, спеціальні клавіші, невидимі (приховані) команди і засоби макровизначення. Коротша тривалість відповіді і швидші параметри показу є привабливішими для постійних користувачів. Система має реагувати на потреби користувачів, що відрізняються.
Забезпечте зворотний зв’язок (відгук). Для кожної дії користувача має бути деяка система зворотного зв’язку. Для частих і незначних дій відповідь може бути помірною, тоді як для рідкісних та головних дій відповідь має бути суттєвішою.
Проектуючи діалог, створи його припинення. Послідовності дій мають бути організовані в групи, які мусять мати початок, середину і кінець. Зворотний зв’язок у разі завершення групи дій має задовольнити користувача досягнутим чи він може стати сигналом до ігнорування відхилень дійсного функціонування від планів роботи, або бути показником того, як підготуватися до наступної групи дій. Потужності діалогу і команд мають відповідати можливостям користувачів їх сприймати. Потужність є мірою кількості роботи, яка завершується даною командою до СППР.
Забезпечте просте відновлення у разі допущення помилок. Проектуйте систему так, щоб користувач не зміг зробити серйозної помилки. Якщо помилка зроблена, то система має її виявити і дати просту пропозицію та зрозумілі дії для відповідного виправлення. Користувачеві немає необхідності повторно вводити пов-ну команду, йому скоріше потрібно тільки виправити помилкову частину команди. Помилкові команди мають залишати стан системи без змін, або система сама має дати команду про відновлення нормального стану.
Надайте змогу щодо легкої реверсивності (протилежності напрямку або зворотності) дій. Дії користувача мають бути ревер­сивними, тобто здатними до зміни напрямку на протилежний. Ця властивість забезпечує меншу тривогу користувача, оскільки він знає, що помилки можна легко виправити; це також заохочує досліджувати незнайомі опції та параметри. Елементами зворотності можуть бути прості дії, введення даних або завершена група дій.
Підтримуйте контроль з боку користувача. Досвідчені користувачі хочуть відчувати, працюючи з СППР, що вона завжди реагує на їхні дії. Система із сюрпризними діями, яка має нудні послідовності введення даних, її нездатність або труднощі за не-обхідності одержувати інформацію і виконувати бажану дію — все це створює невпевненість і незадоволення з боку користувача.
Зменшуйте інформаційне навантаження. Інформаційне навантаження є тією мірою, за якої може використовуватися пам’ять користувача, щоб обробити інформацію, відображену у вікнах дисплея. Це є метою виконуваного завдання, ознайомленості ОПР з ним та проекту інтерфейсу безпосередньо. Обмеження щодо здатності людини обробляти інформацію в режимі оперативної пам’яті потребує, щоб покази залишалися простими і протягом достатнього для тренування періоду, який є необхідним для вивчення команд (стану) і визначення послідовності дій. Проектувальники можуть зменшити інформаційне навантаження за допомогою забезпечення скоріше графічного, ніж буквенно-цифрового показу, та інших форматів, що відповідають вимогам отримання невідкладної інформації користувачами, використання легких для розуміння слів, які забезпечують прості діалоги.
Фактори, що впливають на успішне
проектування користувацького інтерфейсу

Згідно з Ларсоном (Larson) на успішне проектування інтерфейсу користувача впливають одинадцять факторів. Деякі з них подібні до розглянутих щойно пропозицій Шнайдермана. До цієї системи факторів належать: тривалість виконання або проходження завдання в СППР; різноманітність або експлуатаційна гнучкість системи; якість допомоги, яка забезпечується; адаптивність; уніфікованість (однорідність) команд і інтерфейсу. До людських факторів можна віднести: тривалість навчання для здатності користування СППР; легкість повторного виклику (згадування); помилки, що допускають кінцеві користувачі; концентрація, яка вимагається; втома від застосування системи; задово-лення, яке користувач має, використовуючи систему. Ларсон детально описує кожен із цих факторів, що так чи інакше впливають на інтерфейс користувача СППР.
Симулятор користувацького інтерфейсу
Корисним засобом для дослідження проектування і розроблення прикладних систем може бути симулятор користувацького (людино-машинного) інтерфейсу MMIST, який являє собою універсальну інтерактивну програмну систему, розміщену в пам’яті машини VAX11/780, з апаратно незалежним графіч­ним пакетом. Розробники СППР можуть використовувати цю
систему для створення і демонстрування інтерактивних засобів відображення, меню та послідовності оброблення інформації на стадії проектування програмного забезпечення життєвого циклу СППР.
Головними цілями симулятора MMIST є реалізація трьох мож-ливостей, до яких належать:
— робастий інструмент побудови відображень чи меню, який забезпечує досить детальне подання;
— дружній інтерфейс, що задовольняє навіть недосвідчених користувачів;
— потужні засоби симуляції (імітації) інтерфейсу, за допомогою якого користувачі можуть досліджувати й оцінювати єрархію меню і форматів відображення ще до початку кодування робочих програм.
Система MMIST і інші симулятори інтерфейсу, створювані у вигляді ще складніших версій, цілком сумісні з новими стратегіями побудови прототипів СППР. Ідея полягає в тому, щоб
дати користувачам можливість побачити, дослідити і навіть реально використати в інтерактивному, хоча і симульованому, режимі запропоновані засоби інтерфейсу для застосувань до СППР; потім інтерфейс може підлягати модифікаціям, кількість і обсяг яких визначається інтенсивністю зворотного зв’язку з користувачами.
Заключні зауваження
Приклади трьох типів інтерфейсів (меню-орієнтовані, графічні та на природній мові) не охоплюють всього діапазону різноманіття інтерфейсів; існує також багато змішаних типів і різ­них поєднань. Тому розробнику СППР важливо зорієнтуватись
у цій множині можливостей; ключовим аспектом у такому разі має бути важливість створення сумісного і дружнього інтерфейсу користувача, який би функціонував ефективно й продуктивно, забезпечуючи зв’язок користувача з системою в цілому, з базою даних і базою моделей СППР, зокрема.
Закінчуючи описання проблеми взаємодії користувач — СППР зауважимо, що дослідження і роботи зі створення користувацького інтерфейсу проводяться в багатьох країнах, і тому можна сподіватися на появу досконаліших механізмів взаємодії користувача із системою (наприклад, проводяться дослідження інтерфейсу віртуальної реальності, де користувач взаємодіє з генерованим комп’ютерним трьохвимірним (3-D) середовищем, які зі зрозумілих причин у даному розділі не розглянуті.

5.3 База даних і система керування
базою даних у СППР

5.3.1. База даних у СППР
Еволюція використання даних у СППР
Головну роль у будь-яких інформаційних системах, включаючи СППР, відіграють, як було показано в розділі 2, інформація і дані. Зазвичай дані зберігалися у файлах залежно від їх застосування. Це означало, що постійно в них відбувалися зміни і тому файли, пов’язані з кожною конкретною прикладною задачею, розв’язання якої потребує цих даних, також необхідно було змінювати. Наприклад, нехай СППР розроблена для полегшення процесу планування на підприємствах. Вхідними даними для цієї задачі є попит на кожний продукт, що виробляється. Використовуючи традиційний файловий підхід, кожному менеджеру підприємства необхідно надавати інформацію про виробництво кожного продукту адміністраторам з оброблення
даних у СППР, який модернізує відповідні файли. Потім кожному менеджеру з продажу необхідно надсилати інформацію адміністратору з оброблення даних стосовно обсягів продажу цих продуктів, включаючи інформацію про брак попиту на них. Отже, дані вводяться за допомогою деякого механізму у відповідному форматі згідно з їх застосуванням. Один або більше файлів надсилаються адміністратору з оброблення даних, який трансфор­мує дані у формат, придатний для використання в СППР, та мо­дернізує ці файли.
Частота такої модернізації залежить від потреб у своєчасності надходження даних, необхідності збереження даних з метою використання за призначенням та інтенсивності бізнес-процесів. Однак зрозуміло, що такий процес трансформації файлів, особливо, якщо файли зберігаються в різних форматах (що, головно,
і трапляється), є в кращому разі неефективним. Помилки введення даних важко ідентифікувати у всіх прикладних задачах, а також
важко гарантувати, що всі користувачі мають доступ до тих самих даних. Коли потреби різних прикладних задач змінюються та створюються нові поля або знищуються старі, то тоді означені вище проблеми ще більше ускладнюються, тим більше, що оскільки дані зберігаються в багатьох місцях, то необхідно розмножувати і засоби зберігання цих даних.
Як тільки корпорації зрозуміли важливість даних як загального ресурсу, вони активізували процеси збирання та зберігання даних. Одним з найзначніших досягнень інформаційних технологій було створення корпоративних баз даних, що являють собою сукупність взаємопов’язаних даних. Концепція такої бази даних — сумісне зберігання пов’язаних даних у форматі, незалежному від конкретної СППР. Коли зберігання та використання даних незалежні, то і рішення стосовно зберігання даних стають незалежними від рішень щодо їх використання. Ті, хто займається зберіганням даних, можуть сконцентрувати свої зусилля на мінімізації витрат на їх зберігання. Якщо дані зберігаються тільки на рівні корпорації, то обсяг витрат значно зменшується.
Крім того, різноманітні СППР можуть використовувати ті самі бази даних по-різному. Отже, інформація, яка фізично міститься в різних засобах зберігання даних, може бути поєднана в одному масиві для передавання на екрани користувачів з мінімальними витратами часу та машинних ресурсів. Коли потреби прикладних задач змінюються, то добавлення або переміщення якогось поля даних може бути виконано достатньо ефективно. Більше того, рішення можна легше скоординувати, тому що кожний користувач використовує ту саму модифіковану версію даних. У такий спосіб, наприклад, інформаційна система рівня підприємства може використовувати дезагреговані дані про товарні запаси для визначення доступності конкретних матеріалів тоді, коли вони потрібні, у той час як відділ корпоративного планування може використовувати агреговані дані про товарні запаси для визначення можливості ефективнішого розміщення замовлень, що зменшує частоту оброблення даних.
У більшості корпорацій нині дуже мало ведеться дебатів щодо вибору між традиційним обробленням файлів та використанням технології баз даних. Хоча перехід від технології оброблення файлів до технології використання баз даних є важким та дорогим на початку, але коли вже цей перехід здійснено, то така технологія забезпечує гнучкість та узгодженість даних і використовує мінімальний обсяг пам’яті для їх зберігання. Такі переваги сприяють ширшому застосуванню СППР. Однак з позиції користувача ця технологія має деякі недоліки. Якщо файл розробляється для однієї прикладної задачі, то це дає змогу користувачу краще контролювати дані та мати швидкий доступ до них. Як тільки зберігання даних може бути адаптоване до конкретної прикладної задачі, то це забезпечує їх оброблення дещо легшим, дешевшим та швидшим способом. Усі ці переваги спостерігаються лише до тих пір, поки не зміниться сама задача чи потреби користувача. Тоді користувачі мають створювати все спочатку та перебудовувати вхідні дані, а це потребує додаткових зусиль і коштів. Усе це з урахуванням легкості поєднання даних, збільшення кількості доступних полів, довшим терміном використання та меншими затратами на зберігання даних допомагає зрозуміти переваги технології баз даних.
Особливості бази даних у СППР
Загалом базу даних можна визначити як сукупність елементів, організованих згідно з певними правилами, які передбачають загальні принципи описання, зберігання і маніпулювання даними незалежно від прикладних програм. Зв’язок кінцевих користувачів (прикладних програм) з базою даних відбувається з допомогою СКБД. Остання являє собою систему програмного забезпечення, яка містить засоби оброблення даних спеціальними мовами баз даних і забезпечує створення бази даних та її цілісність, підтримує її в актуальному стані, дає змогу маніпулювати даними і обробляти звернення до БД, які надходять від прикладних програм і (або) кінцевих користувачів за умов застосовуваної технології оброблення інформації. До складу мов бази даних, які використовуються для вивчення і звертання до даних, належить мова опису даних (МОД) і мова маніпулювання даними (ММД).
Мова опису даних призначена для формування структури бази даних. Описання даних окремої проблемної галузі може виконуватися на кількох рівнях абстрагування, причому на кожному рів-ні використовується своя МОД. Опис на будь-якому рівні називається схемою. Найчастіше використовується трирівнева система, яка складається з концептуального, логічного і фізичного рівнів. На концептуальному рівні описуються взаємозв’язки між системами даних, що відповідають реально існуючим залежностям між факторами та параметрами проблемного середовища. Структура даних на концептуальному рівні називається концептуальною схемою. На логічному рівні вибрані взаємозв’язки відбиваються в структурі записів бази даних. На фізичному рівні розв’язуються питання організації розміщення структури записів на фізичних носіях інформації.
Мова маніпулювання даними забезпечує доступ до даних і містить засоби для зберігання, пошуку, оновлення і стирання записів. Мови маніпулювання даними, які можуть використовуватися кінцевими користувачами в діалоговому режимі, часто називають мовами запитів.
Бази даних і СКБД використовуються в будь-яких комп’ю­терних системах. Проте порівняно зі звичайними підходами до реалізації бази даних для розв’язування деяких задач до функцій та інструментів БД і СКБД у контексті системи підтримки прийняття рішень висувається ряд додаткових і специфічних вимог.
Для використання СППР необхідний доступ до інформації зі значно ширшого діапазону джерел, аніж це передбачено у звичайних інформаційних системах. Iнформацію потрібно діставати від зовнішнього середовища і внутрішніх джерел; потреба в зовнішніх даних тим більша, чим вищий рівень керівництва, яке обслуговується вибраною СППР. Окрім того, звичайні, орієнтовані на бухгалтерський облік дані (характерні для систем оброблення даних і адміністративних інформаційних систем) необхідно доповнити нетрадиційними типами даних, зокрема й такими, які досі взагалі не бралися до уваги за комп’ютеризації. Сюди належать: текстова інформація, матеріал систем автоматизованого проектування виробів і технологій, автоматизованого виробництва, а також інші джерела інформації, необхідні для прийняття рішень.
Заслуговує також на увагу особливість процесу «здобування і захоплення» даних у СППР на відміну від загальнішого процесу збирання даних із джерел. Призначення СППР потребує, щоб процес здобування (і СКБД, яка керує цим процесом) був достатньо гнучким, аби швидко здійснювати доповнення та зміни згідно з непередбаченими запитами, які надходять від користувачів. Для виконання процесу «здобування і захоплення» даних у сучасних СППР широко застосовуються програмні (інтелектуальні) агенти (див. розділ 9.6), засоби дейтамайнінгу (які докладно описані в розділі 9.3), а також сховища даних (див. розділ 10.2).
У системах підтримки прийняття рішень передбачається засіб, за допомогою якого користувач може налагоджувати базу даних згідно зі своїми особистими вимогами. З огляду на це існують процедури й команди для гнучкого переструктурування схем і схемної підмножини СКБД. Зауважимо, що сучасні програмні засоби для керування даними і СКБД характеризуються достатньою гнучкістю і простотою використання в межах колективу користувачів. Проте згадані засоби не можна переупорядкувати і пристосувати до конкретного користувача чи до розв’язування конкретної задачі з бажаною гнучкістю і досить малими витра-тами.
5.3.2. Підсистема даних у СППР
Схема підсистеми даних у СППР
Будь-яка система підтримки прийняття рішень містить підсистему даних, яка складається з двох основних частин: бази даних і системи керування базою даних (СКБД). Притаманний технології СППР акцент на оброблення неструктурованих і слабоструктурованих задач зумовлює деякі специфічні вимоги до цих елементів комп’ютерної системи. Насамперед ідеться про необхідність виконувати значний обсяг операцій з переструктурування даних. Потрібно передбачити можливість завантаження і наступного оброблення даних із зовнішніх джерел; функціонування СКБД у середовищі СППР на відміну від звичайної технології оброблення інформації в управлінських інформаційних системах потребує ширшого ряду функцій. Це стосується також і бази даних.
Схема підсистеми даних у СППР зображена на рис. 5.5. Основою СППР є корпоративна база даних. Такі системи забезпечують користувачів даними про велику кількість угод та справ повсякденного життя корпорації. Внутрішні бази даних містять інформацію щодо продажу та купівлі товарів, витрат корпорації, персоналу, планів і прогнозів на майбутнє та інших аспектів діяльності організації. Потім ці дані можуть служити основою моделей у СППР. Але важливо те, що сьогодні цих службових записів про корпорації недостатньо для підтримки прийняття рішень.


Види баз даних у СППР
Зовнішні дані. У нинішньому столітті ОПР не можуть приймати ефективні рішення за браку інформації про один або більше факторів, що знаходяться за межами корпорації та належать до зовнішніх даних. Такими зовнішніми даними можуть бути, наприклад: інформація про надання переваг покупцями щодо деяких товарів, попит на продукцію конкурентів у конкретних регіонах, дані перепису населення або статистичні звіти різних галузей.
Публічні (загальнодоступні) дані. Деякі дані збираються та зберігаються в самих корпораціях. Наприклад, відділ маркетингу може збирати інформацію щодо поділу ринку та/або демографічні дані стосовно власних споживачів. Ці дані можуть акумулюватися роками та використовуватися у разі розв’язання багатьох маркетингових завдань. Інші дані доступні з публічних джерел. Деякі бази даних доступні тільки за допомогою комутатора або пошуку шляхом прямого доступу через корпоративні мережі. Інші бази даних є доступнішими через Інтернет, інколи за визначену плату. З кожним днем у всьому світі спрощується доступ до баз даних, що можна використовувати для підтримки прийняття рішень. Документи уряду, копії промов, торгові угоди, газети та інші джерела новин можна знайти та скопіювати в персональний комп’ютер. Навіть книжки, довідкові матеріали та журнали доступні в електронній формі, які використовуються як додаткова інформація в процесі прийняття рішень.
Існує багато шляхів допомоги ОПР щодо використання таких публічних баз даних. По-перше, якщо бази даних зберігаються в корпорації, то розробникам необхідно гарантувати, що доступ до них може забезпечуватися через СППР так само, як і до інших корпоративних даних. Аналогічно, якщо база даних знаходиться в Інтернеті, то розробникам необхідно забезпечити не тільки інтерфейс доступу до неї, але також і зв’язок з Інтернетом через мережу чи модем.
На щастя, коли зв’язок з Інтернетом налагоджено, то існує багато різних засобів для полегшення добування даних. Наприклад, розробники, що використовують Lotus Notes (див. розділ 11.2.4), можуть застосовувати гнучкі засоби пошуку та оброблення інфор­мації, яка знаходиться на Web-сторінці. Слід додати, що можли­вості мови доповнення гіпертексту версії 3.0 (HTML 3.0) та вище дають змогу розробникам вмонтовувати деякі функціональні програми у Web-сторінки.
Приватні дані. Не всі дані зберігаються в базах даних спільного користування. Більшість ОПР використовують власні практичні методи підтримки прийняття рішень, використовуючи дані, які вони збирають cамостійно для одержання стратегічної переваги у своїй корпорації. Інколи вони просто зберігають записи політичних процесів у організації та інформацію стосовно того, як вони можуть вплинути на когось або хтось може вплинути на них за допомогою конкретного рішення. В дійсності ОПР за фор-мулювання альтернативних рішень застосовують ці додаткові дані з метою полегшення власного процесу прийняття рішень.
За умови, що СППР розробляється для реального забезпечення підтримки прийняття рішень, вона має полегшити розвиток та використання приватних баз даних. Тобто система має допомагати ОПР створювати та заповнювати ці бази даних, а також забезпечувати легкий доступ до них з метою пошуку потрібних даних та здійснення необхідних обчислень. Якщо система знаходиться в комп’ютері, то забезпечити доступ до неї легко. Навіть якщо система міститься в мейнфреймі або в середовищі розподіленої системи, то існує можливість підтримувати приватні бази даних на окремих ЕОМ. Однак коли це все зроблено, то вирішальним питанням стає забезпечення достатнього захисту бази даних від несанкціонованого її використання, тобто потрібно гарантувати, що тільки ОПР може мати доступ до цієї інформації.
5.3.3. Системи керування даними в СППР
Обговорення концепції СКБД у СППР
Як уже зазначалося, раніше комп’ютерні системи створювалися з використанням підходу, основаного на обробленні файлів. Коли організації почали рухатися в напрямі до більшої ком-п’ютеризації оброблення своїх даних та технологічних процесів і впровадження сучасніших технологій, то вони почали відмовлятися від здійснення операцій з окремими файлами на користь інтегрованих баз даних. Це означає, що сукупність взаємопов’язаних корпоративних даних консолідується та організується у такий спосіб, щоб бути доступною для різноманітних користувачів.
Для підтримки оброблення інформації з використанням корпоративних баз даних були створені системи керування базами даних (СКБД). СКБД служить буфером між потребами прикладних задач та фізичним зберіганням даних. Вона знаходить і вибирає дані з місця їх фізичного розташування та надає їх у розпорядження конкретної програми у спосіб, сформульований у запиті.
Головною перевагою, яку забезпечує СКБД, є незалежність фактично існуючого розміщення (як вони подані фізично) та вигляду даних (у якому вони надаються для розв’язування прикладної задачі). СКБД забезпечує передавання даних для приклад­ної задачі у такий спосіб, що програмісти, які її розробляють,
можуть сприймати таку організацію даних як визначену. Коли модифікуються функціонуючі прикладні задачі або створюються нові, їх просто необхідно «прикріпити» до СКБД, що значно зберігає термін модернізації. Навіть процес доповнення бази даних новими полями значно легший, ніж доповнення новими полями традиційних файлів.
Розглядаючи технологію баз даних з позиції перспектив розвитку СППР, необхідно зазначити, що не всі структури баз даних є однаковими за гнучкістю та/або практичністю. Існують три фундаментальні класичні структури баз даних — єрархічна, мережева (або сітьова) та реляційна, — кожна з яких має свої переваги та недоліки. Ураховуючи всі їхні переваги та недоліки, можна висновувати, що реляційна структура є найперспективнішою з погляду дальшого розвитку СППР. Розроблені також семантичні моделі даних. Розглянемо коротко класичні структури моделей баз даних.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2017 BPK Group.