ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.12.2020
Просмотров: 1218
Скачиваний: 2
85
даних, які використовуються для вивчення і звертання до даних, належить
мова опису даних (МОД) і мова маніпулювання даними (ММД).
Мова опису даних
призначена для визначення структури бази даних.
Опис даних заданої проблемної області може виконуватися на кількох
рівнях абстрагування, причому на кожному рівні використовується своя
МОД. Опис на будь-якому рівні називається схемою. Найчастіше
використовується трирівнева система: концептуальний, логічний і
фізичний рівні. На концептуальному рівні описуються взаємозв’язки між
системами даних, що відповідають реально діючим залежностям між
факторами та параметрами проблемного середовища. Структура даних на
концептуальному рівні називається концептуальною схемою. На логічному
рівні вибрані взаємозв’язки відбиваються в структурі записів бази даних.
На фізичному рівні розв’язуються питання організації розміщення
структури запису на фізичних носіях інформації.
Мова маніпулювання даними
забезпечує доступ до даних і містить
засоби для зберігання, пошуку, оновлення і стирання записів. Мови
маніпулювання даними, які можуть використовуватися кінцевими
користувачами в діалоговому режимі, часто називають мовами запитів.
Бази даних і СУБД використовуються в будь-яких комп’ютерних
системах. Проте порівняно зі звичайними підходами до реалізації бази
даних для розв’язування деяких задач до функцій та інструментів БД і
СУБД у контексті системи підтримки прийняття рішень висувається ряд
додаткових і спеціалізованих вимог.
Для умов використання СППР існує необхідність доступу інформації
зі значно ширшого діапазону джерел, аніж це передбачено у звичайних
інформаційних системах. Iнформацію потрібно діставати від зовнішнього
середовища і внутрішніх джерел; потреба в зовнішніх даних тим більша,
чим вищий рівень керівництва, яке обслуговує вибране СППР.
1.8.4
Бази моделей і системи управління базами моделей
Дані та моделі є центральними елементами СППР. Фактичне СППР
відрізняється від АIС наявністю інтерактивних програм (з їх допомогою
користувач може досліджувати і «мандрувати» по базах даних різних
форм, різмірів і типів) та бази моделей (усередині її користувач може
конструювати, аналізувати, інтерпретувати одну чи кілька моделей).
Система управління моделями є одним із компонентів універсальної
СППР. Функціями цього компонента є класифікація, організація і доступ
до моделей, тобто ці функції аналогічні функції системи управління
базами даних.
86
База моделей СППР містить оптимізаційні і неоптимізаційні моделі.
До складу оптимізаційних моделей належать моделі математичного
програмування — лінійного (розподіл ресурсів, оптимальне планування,
аналіз сіткових графіків, транспортна задача), нелінійного, динамічного;
моделі обліку; моделі аналізу цінних паперів для визначення
інвестиційної стратегії; моделі маркетингу і т.ін.
До неоптимізаційних моделей належать статистичні моделі
(лінійний і нелінійний аналіз регресій); методи прогнозування (аналізу)
часового ряду; альтернативні методи моделювання (наприклад, машинна
імітація) тощо.
У більшості відомих з літературних джерел систем для
маніпулювання і зберігання моделей використовувались поняття і методи
подання знань (формальна логіка, моделі продукції, семантичні сітки,
фрейми та їхні гибриди), а також реляційний базис, аналогічні реляційні
моделі даних.
Системи управління базами моделей (СУБМ), як узагальнені
програмні засоби, забезпечують користувачам широкий набір моделей і
дають змогу проводити гнучкий доступ, оновлення та зміну бази моделей.
Основні функції СУБМ такі:
створення нових моделей;
каталогізація і оцінювання широкого діапазону моделей;
зв’язування компонентів моделей у базі моделей;
інтеграція складових елементів моделей;
виконання набору загальних функцій управління СУБМ.
1.8.5
Управління поштою (повідомленнями) в СППР
Традиційно фахівці вважали поштову систему, навіть електронну
пошту, додатковою функцією СППР. Тобто розробники систем підтримки
прийняття рішень розуміли, що особа, яка приймає рішення, ймовірно
має системи доставки електронної пошти, але такі системи ігноруються
при проектуванні і розробці СППР. Для використання електронної пошти
ОПР спочатку повинні були б припинити роботу з СППР. Навіть коли
з’явилася технологія «роботи з вікнами» прикладних програм, яка
дозволила користувачеві легко переміщуватися в прикладну програму
електронної пошти, СППР і електронна пошта існували як все ще
незалежні такі програми. ОПР не міг легко пересилати документи, графіку
чи текст прямо з СППР або отримувати такі, щоб використовувати
всередині СППР.
У сьогоднішньому електронному середовищі безшовна інтеграція
СППР з системою електронної пошти означає серйозні обмеження на
87
інформацію та аналізи, доступні ОПР. Зростаюче число менеджерів
вважають електронну пошту продуктивно розширювальним інструментом.
Інтерфейс з системою електронної пошти дозволяє ОПР більший доступ до
груп обговорення, баз даних Інтернет, інших електронних даних та
інструментальних засобів для прийняття рішень. Ці ресурси можуть
розширювати діапазон доступної інформації і можуть, в деяких випадках,
забезпечити доступ до більш нових даних. Використання електронної
пошти може допомагати ОПР зв’язуватися з колегами, щоб обговорити
інформацію та дослідження, а також встановити загальноприйнятну
перспективу рішень. Це може, у свою чергу, покращити зв’язок ОПР з
підлеглими і сформувати підтримку для вибору, що є важливими кроками
в процесі прийняття рішень.
1.9
Створення СППР на основі сховища даних [1, 10]
1.9.1
Формування концепції сховища даних
Ясно, що чим більше інформації залучено в процес прийняття
рішень, тим більш обґрунтованыше рішення може бути прийняте.
Інформація, на основі якої приймається рішення, має бути достовірною,
повною, несуперечливою і адекватною. Тому при проектуванні СППР
виникає питання про те, на основі яких даних ці системи працюватимуть.
У СППР традиційна технологія підготовки інтегрованої інформації
на основі запитів і звітів стала неефективною із-за різкого збільшення
кількості і різноманітності початкових даних. Це почало стримувати
менеджмент, для якого необхідним є швидке приймання рішення. Крім
того, поступове накопичення в БД підприємства даних для прийняття
рішень і наступний їх аналіз стали негативно позначатися на оперативній
роботі з даними.
Рішення було знайдене і сформульоване у вигляді концепції
Сховища Даних (Data Warehouse, СД), яке виконувало б функції
попередньої підготовки і зберігання даних для СППР на основі інформації
з системи управління підприємством (чи бази даних підприємства), а
також інформації із зовнішніх джерел, які в достатній кількості стали
доступні на ринку інформації.
Цей підхід потребував нових технологічних рішень. Сьогодні
накопичений великий досвід розробки і впровадження спеціалізованих
структур даних і створення СППР на основі СУБД різних типів. Відома і
технологія створення великих Сховищ, як правило, на основі реляційних
СУБД.
88
1.9.2
Технологія розробки і впровадження Сховища Даних
Етапи проекту
Першою фазою проекту розробки СД є бізнес-аналіз процесів і даних
підприємства. Незважаючи на широке поширення CASE - технологій, до
бізнес-аналізу і проектування даних на концептуальному рівні не завжди
відносяться досить серйозно. Можна з упевненістю стверджувати, що
розробка СППР на основі сховища даних без подібного аналізу заздалегідь
приречена на невдачу. Без ясного розуміння розробниками цілей бізнесу,
способів їх досягнення, проблем, що виникають при цьому, і методів їх
рішення, ресурси, необхідні для розробки СД, будуть витрачені даремно.
Найкритичнішим з ресурсів зараз являється час, і той, хто почав розробку
СППР, не визначивши заздалегідь, хто, коли, навіщо і як прийматиме
рішення, який вплив те або інше рішення робить на бізнес, які рішення
віднести до оперативних, а які до стратегічних і т. д., прирікає себе на
неминуче відставання в конкурентній боротьбі.
Основне призначення моделі підприємства – визначення і
формалізація даних, дійсно необхідних в процесі ухвалення рішення.
Відомо два підходи до бізнес-аналізу. Перший орієнтується на опис бізнес-
процесів, що протікають на підприємстві, яке моделюється набором
взаємозв'язаних функціональних елементів. Оскільки ці процеси, як
правило, добре відомі, на перший погляд здається, що це найприродніший
і швидший шлях бізнес-аналізу. Дійсно, якщо бізнес стабільний і зовнішні
чинники не грають в ньому вирішальної ролі або також стабільні, цей
шлях може виявитися найбільш ефективним. Другий підхід заснований на
первинному аналізі бізнес-подій. При проектуванні СППР на основі СД
саме він забезпечує найбільшу ефективність:
дозволяє гнучко модифікувати бізнес-процеси, ставлячи їх в
залежність від бізнес-подій;
інтегрує дані, які при аналізі бізнес-процесів залишаються
прихованими в алгоритмах обробки даних;
об'єднує управляючі потоки та інформаційні потоки;
наочно показує, яка саме інформація потрібна при обробці бізнес-
події і в якому вигляді вона представляється.
Іншими словами, бізнес-подія є стійкішим і більш тісно пов'язаним з
інформаційними потоками поняттям, ніж бізнес-процес.
Через аналіз бізнес-подій необхідно перейти до аналізу даних, які
використовує підприємство. При цьому має бути зібрана інформація про
зовнішні, дані які використовуються, і їх джерела; про формати даних,
періодичність і формі їх надходження; про внутрішні інформаційні
системи підприємства, їх функції і алгоритми обробки даних, які
використовуються коли настають бізнес-події. Такий аналіз, як правило,
робиться при проектуванні будь-якої інформаційної системи. Особливість
аналізу даних при проектуванні СППР на їх основі полягає в необхідності
створення моделей представлення інформації. Те, що в транзакційних
89
системах є другорядним поняттям, а саме склад і форма даних в СППР
набуває особливої важливості, оскільки треба виявити усі без виключення
ознаки, потрібні для менеджерів.
При проектуванні транзакційної системи зазвичай строго
витримується послідовність процесів : бізнес-аналіз, концептуальна модель
даних, фізична модель даних, структура інтерфейсу і т. п. Повернення на
попередній рівень відбувається рідко і вважається відхиленням від
нормального ходу виконання проекту. У разі СППР на основі СД
нормальним вважається ітераційний, а іноді і паралельний, характер
моделювання, при якому повернення на попередню стадію - звичайне
явище. Це пов'язано з необхідністю виділення усіх необхідних даних для
довільних запитів (ad - hoc), для чого слід скласти вичерпний перелік
необхідних даних і побудувати схему їх зв'язків через бізнес-події. При
цьому із загального масиву виділяється значуща інформація і з'ясовується
потреба в додаткових джерелах даних для прийняття рішень.
В ході аналізу бізнес-подій необхідно також сформувати схему
взаємодії між транзакційною і аналітичною системами на підприємстві.
Окрім того, що транзакційна система дуже часто є найважливішим
джерелом даних для сховища, бажано використовувати один і той же
інтерфейс користувача в ІСР і СППР. Підходи до спільного використання
цих систем визначаються саме на цій фазі виконання проекту.
Отже, за результатами аналізу бізнес-процесів і структур даних
підприємства відбирається дійсно значуща для бізнесу інформація з
урахуванням невизначеності майбутніх запитів. Наступний крок
пов'язаний з розумінням того, в якому виді і на яких апаратних і
програмних платформах розміщувати структуру даних СППР на основі
СД.
Вибір моделі даних Сховища
У найпростішому варіанті для Сховищ Даних використовується та
модель даних, яка лежить в основі транзакційної системи. Якщо, як це
часто буває, транзакційна система функціонує на реляційній СУБД (Oracle,
Informix, Sybase і т. п.), найскладнішим завданням стає виконання запитів
ad - hoc, оскільки неможливо заздалегідь оптимізувати структуру БД так,
щоб усі запити працювали ефективно.
Проте практика прийняття рішень показала, що існує залежність між
частотою запитів і мірою агрегування даних, з якими запити оперують, а
саме чим більш агрегованими є дані, тим частіше запит виконується.
Іншими словами, коло користувачів, працюючих з узагальненими даними,
ширше, ніж те, для яких потрібні детальні дані. Це спостереження є
основою підходу до пошуку і вибірки даних, яке називається Оперативною
Аналітичною Обробкою (On - line Analytical Processing, OLAP).
OLAP - системи побудовані на двох базових принципах: