Організація роботи користувача з АБД

8

Кафедра економічної кібернетики

Контрольна робота

З дисципліни:

“Інформаційні системи в менеджменті"

Організація роботи користувача з АБД

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

Рис. 1. Схема формування і використання АБД.

Згідно з концепцією засновника АБД Б. Інмона (Bill Inmon)"АБД є тематично орієнтованою, інтегрованою, динамічною (time-variant), довготривалою сукупністю даних для підтримання процесів менеджерів, котрі розробляють рішення". Р. Кімбал (Ralph Kimball, 1996), інший піонер створення АБД, уважає, що "банк даних містить копії даних транзакцій, специфічно структурованих для запитів і аналізу".

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

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

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

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

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

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

Технологія створення.

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

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

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

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

Останній крок - розгортання (Rollout) і зворотний зв'язок (Feedback). Цей крок передбачає реальне розгортання СППР, забезпечення додаткової підготовки, установлення зворотного зв'язку з користувачами, супроводження системи і в багатьох випадках також її розширення та вдосконалення. За такого підходу є підстави сподіватися, що СППР дасть змогу удосконалити створення рішень і тим самим принесе користь як компанії загалом, так і творцям рішень зокрема.

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

АБД потенційно орієнтований на різні джерела (рис.2), включаючи операційні бази даних або дані транзакцій. Інші внутрішні дані, які надходять від електронних таблиць і внутрішньокорпоративних документів, та зовнішні дані, як наприклад бази даних новин чи цін акцій, можуть також бути збережені в АБД. У типовій організації операційні дані розпорошені через використання кількох СКБД у дуже різних форматах і на різних апаратних платформах. Наприклад, операційні дані можуть міститися у великих ЕОМ (мейнфреймах) типу IBM або DEC і знаходитися у файлах інформаційних систем менеджменту (на рис.2 - IMS), забезпечуватися віртуальним методом доступу до файлів даних (VSAM), або знаходитися в СКБД DB2 і базах даних. Успадковані інформаційні системи, як наприклад ті, що зображені на рис.2 з ілюстративною метою, є загальним джерелом даних для АБД.

Рис. 2. Будова і використання автоматизованого банку даних

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

Важливим чинником стимулювання організації сховищ даних у корпораціях стала поява спеціального програмного забезпечення, призначеного для побудови та зберігання банках даних, а також для забезпечення доступу до них. Як видно із рис.2, до групи продавців цих програмних продуктів належать як добре відомі розробники СППР та ВІС (наприклад Pilot, Comshare, IRI) і баз даних (наприклад, Oracle, Focus), так і менш знайомі продавці (Red Brick, Platinum, Carleton), які мають значний вплив у сфері організації банків даних.

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

Дані, які містяться в АБД, можуть бути доступними через програмне забезпечення клієнта, що використовується для підтримки прийняття рішень. Воно може призначатися для ВІС (наприклад, Lightship, Commander), СППР (наприклад, Visual IFPS, Express), або незапланованих (ad hoc) запитів (наприклад, Business Objects, Visualizer). У всіх випадках мається на увазі, що програмне забезпечення легке для користування, так що організаційний персонал з обмеженою комп'ютерною майстерністю і досвідом може ефективно його застосовувати.

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

Для звичайних БД процес їх створення відбувається за схемою: вивчення предметної галузі; побудова інформаційної моделі; розроблення на основі інформаційної моделі проекту бази даних; створення бази даних. Обов'язкові етапи створення АБД відрізняються від такої схеми. Такими етапами є: визначення інформаційних потреб користувачів щодо даних, котрі нагромаджуються в базах даних операційних систем (OLTP-систем), що служать джерелами оперативних даних; вивчення локальних баз даних OLTP-систем; виокремлення від кожної бази даних підмножини даних, необхідних для завантаження в АБД; інтегрування локальних підмножин даних і розроблення загальної погодженої схеми банку. Для виконання робіт зі створення банку даних за даною схемою існують різні інструментальні засоби, зокрема, програмний продукт "Oracle Designer" та його спрощена версія "Oracle Data Mart Designer".

Коли АБД уже створений та оптимізований, необхідно ефективно завантажувати нові дані в систему без переривання процесу підтримки прийняття рішень. Однак у разі збільшення обсягу даних розробникам необхідно визначити нові синтаксичні формати та формати запитів, які є швидшими й легшими, а також визначити нові підходи до поєднання реляційних таблиць та добування даних з цих дуже великих баз даних з використанням різновиду програмних агентів - інтелектуальних ("розумних") агентів (Intelligent agents).

Список використаної літератури