Posibniki.com.ua Інформатика Корпоративні інформаційні системи БАЗИСНА ТЕХНОЛОГІЯ КОРПОРАТИВНИХ ІНФОРМАЦІЙНИХ СИСТЕМ


< Попередня  Змiст  Наступна >

БАЗИСНА ТЕХНОЛОГІЯ КОРПОРАТИВНИХ ІНФОРМАЦІЙНИХ СИСТЕМ


3.1. Поняття базисної технології та її особливості

3.2. Технологія доступу, зберігання та адміністрування даних у КІС

3.3. Організація електронного документообігу та інтелектуального аналізу в КІС

3.4. Технологія створення складних систем за допомогою реінжинірингу

Резюме

Терміни і поняття

Запитання для перевірки знань

Завдання для індивідуальної роботи Вивчивши матеріал цього розділу, ви будете ЗНАТИ:

— базові стандарти управління бізнесом(MPS, SIC, MRP, MRPII, ERP, CSRP);

— сучасну архітектуру побудови КІС на базі клієнт-серверних і Web-серверних технологій доступу до даних;

— методи підвищення інтелектуальності програмних засобів управління бізнесом за рахунок упровадження в практику роботи підприємств таких програмних продуктів як OLAP (динамічного аналізу даних), DSS (системи підтримки прийняття рішень), Data Mining (розкопка даних) тощо;

— програмні засоби електронного документообігу в КІС;

— технологію використання реінжинірингу в КІС,

а також УМІТИ:

— використовувати програмні засоби ОН-лайнового аналізу в КІС;

— уміти працювати з програмними засобами електронного документообігу.

3.1. ПОНЯТТЯ БАЗИСНОЇ ТЕХНОЛОГІЇ ТА ЇЇ ОСОБЛИВОСТІ

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

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

Усе згадане визначає функціонал КІС, тобто її функціональну структуру, для управління якою на практиці вже давно сформувався набір стандартів (залежно від типу бізнесу) функціонального розгляду процесів виробництва, логістики та їх фінансових результатів у взаємодії. Як уже зазначалося (п. 1.2; 1.3), до базових стандартів управління бізнесом належать MPS, SIC, MRP, MRPII, ERP, CSRP. Але поряд із цим структуру КІС визначають технології, що реалізують цей функціонал. У цьому плані сучасні інформаційні системи мають відповідати набору обов’язкових вимог, серед яких передусім слід назвати використання як базисної технології клієнт-серверної архітектури з можливістю застосування переважно промислових СУБД, забезпечення безпеки різноманітними методами контролю й розмежування доступу до інформаційних ресурсів, підтримку розподіленого оброблення інформації, модульний принцип побудови КІС із програмно незалежних функціональних блоків і можливістю розширення її за рахунок відкритих стандартів (API, COM, DCE, ODBC і ін.), а також підтримку технологій Internet/Intranet.

Сучасні технології побудови КІС спираються здебільшого на клієнт-серверні архітектури. Терміни «клієнт» і «сервер» означають ролі, що її відіграють різні компоненти в середовищі розподілених обчислень. Ці компоненти можуть пра-цювати як у межах однієї потужної машини, так і на різних машинах (як здебільшого й буває). Серверів у мережі може бути кілька: файл-сервер, факс-сервер, сервер друку, прикладний сервер, сервер бази даних тощо. Існують три топологічні моделі інформаційних систем: мала (файл-серверна), середня (дворівнева клієнт-серверна на базі моделей RDA i DBS), велика (трирівнева клієнт-серверна на базі AS-моделі).

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

Середня й велика моделі спираються на складнішу ієрархічну організацію та успішно розвиваються завдяки таким об’єктивним передумовам:

— різкому збільшенню кількості клієнтів інформаційної системи підприємства будь-якого масштабу, що призводить до перенавантаження системи вводу/виводу сервера малої моделі, і він стає вузьким місцем КІС;

— збільшення пропозицій від провідних виробників прикладного програмного забезпечення та промислових СУБД, таких як Oracle, Sybase, Informix, Computer Associates, Software AG та ін.;

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

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

— підвищенню інтелектуальності програмних засобів управління бізнесом, упровадження в практику роботи підприємств таких програмних продуктів, як OLAP (динамічного аналізу даних), DSS (системи підтримки прийняття рішень) тощо;

— використанню нових швидкодіючих мережевих протоколів.

Клієнт і сервер взаємодіють по мережі з конкретною топологією, для підтримки якої завжди використовується певний протокол. Взаємодію має бути організовано в такий спосіб, щоб забезпечувати незалежність як від використовуваного мережевого апаратного забезпечення, так і від протоколів мережевого обміну. Щоб забезпечити прозорий доступ користувачів і програм до віддалених даних у мережі, що поєднує різнорідні комп’ютери, комунікаційний сервер має підтримувати найпоширеніший діапазон мережевих протоколів (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, Apple Talk та ін.).

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

Основною частиною будь-якої системи «клієнт-сервер» є сервер бази даних, який має відповідати таким вимогам: забезпечення мінімального часу виконання запитів за максимально можливої кількості користувачів. Існують дві основ-

ні архітектури для побудови сервера (процесора) бази даних: з кількома процесами і багатопотокова.

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

Багатопотокова архітектура використовує лише один файл, що виконується, з кількома потоками виконання. Основна перевага цієї архітектури — скромніші вимоги до ресурсів, ніж для архітектури з кількома процесами. У цьому разі сервер бере на себе поділ часу між окремими потоками, іноді надаючи перевагу деяким задачам над іншими. Крім того, відпадає потреба у складному механізмі взаємодії процесів. За багатопотоковою архітектурою побудовані MS SQL Server, Sybase SQL Server.

Поряд із перевагами багатопотокова архітектура має певні вади; оскільки сервер може виконуватися лише в одному процесорі, виникає природне обмеження застосування СУБД для мультипроцесорних платформ. Якщо комп’ютер має, скажімо, 4 процесори, то СУБД з одним сервером використовуватиме лише один із них, не завантажуючи решту три. Інколи на практиці цю проблему вирішують заміною виокремленого сервера на диспетчер чи віртуальний сервер (virtual server), який втрачає право монопольно розпоряджатися даними, виконуючи лише функції диспетчеризації запитів до актуальних серверів. Це свідчить про те, що в архітектуру системи додається нова проміжна ланка, яка розташовується між клієнтом і сервером, що підвищує витрати ресурсів на підтримку завантаження (load balancing) і обмежує можливості управління взаємодією «клієнт-сервер». У такій системі сервери стають рівноправними, що, поперше, внеможливлює встановлення пріоритетів обслуговування запитів, подруге, не дає змоги надсилати запит від клієнта конкретному серверу.

Сучасне розв’язання проблеми СУБД для мультипроцесорних платформ залежить від можливості запуску кількох серверів бази даних у різних процесорах. При цьому кожен із серверів може бути багатопотоковим. Якщо ці дві умови виконуються, можна говорити про багатопотокову архітектуру з кількома серверами (multi-threaded, multi-server architecture).

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

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

адекватно відтворювати наявні процеси. Ці вимоги потребують виконання таких завдань:

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

— база даних має бути підпорядкована правилам і законам функціонування предметної області (business rules);

— потрібен постійний моніторинг становища бази даних, відстеження всіх змін і адекватної реакції на них;

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

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

Збережені процедури (stored) детально описано в параграфі 2.3 при характеристиці DBS-моделі сервера бази даних.

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

Механізм подій у базі даних (database events) дає змогу прикладним програмам і серверу бази даних змушувати інші програми здогадатися про прихід до бази даних певної події й цим самим синхронізувати їх роботу. Функції управління подіями реалізуються винятково сервером бази даних.

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

— створити подію). Надалі в усі прикладні програми, перебіг виконання яких може вплинути на всі ці події, включається оператор register advent

— зареєструвати подію. Цей оператор сповіщає сервер бази даних, що ваша програма здогадалася про прихід події. Тепер будь-яка прикладна програма чи процедура бази даних може викликати подію оператором Raise advent — визвати подію.

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

Поряд із клієнт-серверною технологією останніми роками широкого розвитку набуває Web-серверна технологія, котра починає активно використовуватися в корпоративному середовищі у зв’язку з поширенням Internet-технологій, і пе-

редусім Web-браузерів. Якщо звернути уваги на швидкість, з якою такі фірми, як Oracle, SAP, Dun & Bradstreet Software i Peoplesoft змагаються, щоби створити клієнтську частину своїх промислових клієнт-серверних додатків у вигляді Web-браузерів, то можна стверджувати, що в недалекому майбутньому основною платформою КІС стане Web-серверна технологія. Інтернет може виявитися архітектурним рішенням корпоративних мереж для великих компаній упродовж наступних років. Використання Web-клієнта забезпечить низку переваг: нижча вартість функціонування системи, простота використання як для адміністраторів, так і для звичайних користувачів, стандартизація різних підходів до розроблення.

Наявний сьогодні Web-інтерфейс поки що не може забезпечити такого набору можливостей, як нинішні інструменти клієнт-серверних технологій, але він здатен суттєво розширитися, якщо компанії-виробники клієнт-серверних додатків змодифікують браузери й перебудують свою клієнтську технологію для використання Java. Хоча це станеться не дуже скоро, але в цьому напрямі є певні зрушення. Так, компанія Oracle вже пропонує три бізнес-додатки — Web-споживач, Web-постачальник і Web-службовець. Вони дають можливість виконувати нескладні функції: отримувати звіти про розповсюдження товарів, відстежувати стан людських ресурсів та запасів і руху товарів на складах. Компанія SAP оголосила, що разом з One Wave готується до випуску Web-клієнтів з обліку кадрів, управління обслуговуванням, постачанням і отриманням фінансових звітів для своєї корпоративної системи R/3.

До речі, паралельно із зазначеною виникає ще одна проблема, яка гальмує впровадження Web-серверних технологій. У наш час більшість користувачів не готові довіряти конфіденційні дані додаткам, що працюють в Інтернеті. Мережа Інтернет залишається надто відкритою, аби довіряти їй важливу інформацію. Тому хоч Oracle, SAP й інші фірми адаптуються до вимог ринку, пропонуючи Web-браузери як клієнтську частину у своїх продуктах, багато споживачів все одно віддають перевагу надійним серверним додаткам і звичайним клієнтам для них.

З переходом на Web технології перед фірмами-розробниками додатків постало завдання не лише створити загальні технології, які дозволять використовувати наявні прикладні програми, а й перебудувати звичайні додатки в додатки Java, забезпечивши в такий спосіб сумісність на рівні коду. Сьогодні активно створюються додатки на основі об’єктно-орієнтованої Java-технології. Використовуючи Web-браузер як клієнта, пересічний користувач зможе взаємодіяти з багатьма вузлами, завантажуючи в браузер необхідні в певний момент додатки. Зрештою використання Web-технологій знизить вартість і складність програмного забезпечення для користувачів.


< Попередня  Змiст  Наступна >
Iншi роздiли:
3.3. ОРГАНІЗАЦІЯ ЕЛЕКТРОННОГО ДОКУМЕНТООБІГУ ТА ІНТЕЛЕКТУАЛЬНОГО АНАЛІЗУ В КІС
3.4. ТЕХНОЛОГІЯ СТВОРЕННЯ СКЛАДНИХ СИСТЕМ ЗА ДОПОМОГОЮ РЕІНЖИНІРИНГУ
ТИРАЖУВАННЯ ДАНИХ У КОРПОРАТИВНИХ ІНФОРМАЦІЙНИХ СИСТЕМАХ
4.2. МОДЕЛІ ТИРАЖУВАННЯ ДАНИХ
4.3. СХЕМИ ТИРАЖУВАННЯ ДАНИХ
Дисциплiни

Медичний довідник новиниКулінарний довідникАнглійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki (2022)