Кафедра економічної кібернетики
Контрольна робота
З дисципліни:
“Інформаційні системи в менеджменті"
Організація роботи користувача з АБД
Автоматизований банк даних (АБД) є специфічною базою даних, яка проектується і наповнюється, щобпідтримувати створення рішень в організації. Це є пакет, своєрідна системакерування базою даних, що існує окремо від оперативних систем, обновлюється іструктурується для термінових оперативних запитів і управлінських підсумків. Зазмістом та часовим горизонтом вона відрізняється від оперативних систем. Прицьому сховище даних є незмінним у часі, а, отже, здатним підтримуватирізноманітні види аналізу. Переважно такі бази даних є архівами операційнихданих, відібраних для забезпечення підтримки прийняття рішень та оптимізованихдля взаємодії з СППР організації. На рис.1 зображена спрощена схема формуваннята використання автоматизованого банку даних. Дані беруться з різноманітнихджерел оперативних даних. Після переміщення проводиться їх відбір длягарантування того, що вони мають достатню значимість, є безперервними і точними.Потім дані завантажуються в реляційні таблиці, які в змозі підтримуватирізноманітні види аналізу та запитів, і оптимізуються для тих таблиць, які, якочікується, будуть найчастіше застосовуватися. І, нарешті, дані зберігаютьсядля подальшого використання.
/>
АБД />/>/>/>
Рис. 1. Схема формування і використання АБД.
Згідно з концепцією засновника АБД Б. Інмона (BillInmon)«АБД є тематично орієнтованою, інтегрованою, динамічною (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».
Коли АБД уже створений та оптимізований,необхідно ефективно завантажувати нові дані в систему без переривання процесупідтримки прийняття рішень. Однак у разі збільшення обсягу даних розробникамнеобхідно визначити нові синтаксичні формати та формати запитів, які є швидшимий легшими, а також визначити нові підходи до поєднання реляційних таблиць тадобування даних з цих дуже великих баз даних з використанням різновидупрограмних агентів — інтелектуальних («розумних») агентів (Intelligentagents).
Список використаної літератури
1. Ананьєв О.М. Інформаційні системи і технології в комерційній діяльності[Текст]: підручник / О.М. Ананьєв, В.М. Білик, Я.А. Гончарук. — Львів: НовийСвіт-2000, 2006. — 584 с.
2. Антонов В.М. Фінансовий менеджмент: сучасні інформаційні технології [Текст]:навчальний посібник / В.М. Антонов, Г.К. Яловий; ред. В.М. Антонов; Мін-воосвіти і науки України, КНУ ім. Т.Г. Шевченка. — К.: ЦНЛ, 2005. — 432 с.
3. Гужва В.М. Інформаційні системи і технології на підприємствах [Текст]: навчальнийпосібник / В.М. Гужва; Мін-во освіти і науки України, КНЕУ. — К.: КНЕУ, 2001. — 400 с.
4. Гуржій А.М. Інформатика та інформаційні технології [Текст]: підручник /А.М. Гуржій, Н.І. Поворознюк, В.В. Самсонов. — Х.: Компанія СМІТ, 2003. — 352 с.
5. Информационные системы и технологии: приложения в экономике и управлении:Кн.6 [Текст]: учебное пособие / Мин-во образования и науки Украины, Донецкийнац. ун-т; ред. Ю.Г. Лысенко. — Донецк: Юго-Восток, 2004. — 377 с.
6. Інформаційні системи в менеджменті [Text]: підручник / В.О. Новак, Ю.Г. Симоненко,В.П. Бондар, В.В. Матвєєв. — К.: Каравела: Піча Ю.В., 2008. — 616 с.
7. Писаревська Т.А. Інформаційні системи в управлінні персоналом таекономіки праці [Текст]: навчально-методичний посібник для самост. вивч. дисц. /Т.А. Писаревська, О.В. Городній; Мін-во освіти і науки України, Київський нац. економічнийун-т ім. Вадима Гетьмана. — К.: КНЕУ, 2006. — 284 с.
8. Пономаренко Л.А. Електронна комерція [Текст]: підручник / Л.А. Пономаренко,В.О. Філатов; Мін-во освіти і науки України, Київський нац. торговельно-економ.ун-т. — К.: Київський нац. торг. — економ. ун-т, 2002. — 443 с.
9. Татарчук М.І. Корпоративні інформаційні системи [Текст]: навчальнийпосібник / М.І. Татарчук; Мін-во освіти і науки України, Київський нац. економічнийун-т. — К.: КНЕУ, 2005. — 291 с.