А О Примостка - Архітектура інформаційно-аналітичних систем еволюція та типологія - страница 1

Страницы:
1 

IV. Економіко-математичні методи

УДК 004.65

А. О. Примостка, аспірант кафедри інформаційного менеджменту, ДВНЗ «КНЕУ імені Вадима Гетьмана»

АРХІТЕКТУРА ІНФОРМАЦІЙНО-АНАЛІТИЧНИХ СИСТЕМ: ЕВОЛЮЦІЯ ТА ТИПОЛОГІЯ

Анотація. Досліджено основні типи архітектури інформаційно-аналітичних систем: централізована, розподілення файлів, архіте­ктура клієнт—сервер; виявлено їх переваги та недоліки, обґрунто­вано пріоритети вибору інтеграційного базису для побудови при­кладних систем.

Ключові слова: інформаційно-аналітична система, архітектура, клієнт, сервер.

Аннотация. Исследованы основные типы архитектуры информа­ционно-аналитических систем: централизованная, разделения файлов, архитектура клиєнт—сервер; выявлены их преимущества и недостатки, обоснованы приоритеты выбора интеграционного базиса для построения информационно-аналитических систем.

Ключевые слова: информационно-аналитическая система, архіте­ктура, клиент, сервер.

Annotation. The main types of the architecture of information-analytical systems have been researched: centralized, files distribution, client-server architecture; their advantages and disadvantages have been shown, the priorities of integration basis for building information-analytical systems have been proved.

Key words: information-analytical system, architecture, client, server.

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

© А. О. Примостка, 2012

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

Аналіз останніх джерел та публікацій. Розвиток підходів до побудови універсальної архітектури інформаційно-аналітичних систем відбувається протягом останніх п' ятдесяти років. Дослі­дженню цієї проблематики присвятили свої праці багато вітчиз­няних науковців [1—4], не залишаються осторонь і зарубіжні учені та практики [5—10]. В процесі розвитку інформаційних технологій сформувалися різні концепції та підходи до побудови архітектури інформаційно-аналітичних систем, які відрізняються за можливостями доступу до сховищ і баз даних, логікою пред­ставлення, рівнем автоматизації, кількістю користувачів [1—3]. Зараз поширення набула триланкова архітектура, яка має різно­манітні модифікації і дозволяє підтримувати інтеграцію з різни­ми спеціалізованими програмними продуктами [3, 4, 9]. Однак проблема формування інтеграційного базису для цілісної інфор­маційно-аналітичної системи потребує подальших досліджень і практичних розробок, а пошуки у напрямі створення універсаль­ної архітектури інформаційно-аналітичних систем тривають.

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

Централізована архітектура. За такого підходу одна могутня універсальна ЕОМ слугує єдиною платформою, що виконує всі алгоритми логіки додатка (рис. 1). Централізована архітектура має багато переваг: проста розробка додатків, легкість обслуго­вування і керування. Саме ці переваги і забезпечили досить три­вале функціонування цих систем. Зникнення універсальних ЕОМ неодноразово прогнозувалося після появи чотирьох- і восьмироз-рядних персональних комп'ютерів (ПК) на початку 1980-х років, таких як комп'ютери PET і Уі-20 компанії Commodore, TRS-80 компанії Касііо Shack, комп'ютери на базі процесорів Z-80, а та­кож 6502 і 6800 виробництва Motorola. Однак універсальні ЕОМ продовжували працювати, здійснюючи щоденно десятки мільйо­нів транзакцій і пристосовуючись до постійно зростаючого нава­нтаження.

Термінал

 

Термінал

 

 

 

rt

Термінал

Термінал

Процесор переднього плану

Бізнес-логіка

Дані

Термінал

Рис. 1. Централізована архітектура. Блок «Дані» включає алгоритми доступу до даних, СУБД і власне базу даних

Архітектура розподілення файлів. Поява ПК супроводжувала­ся очікуванням того, що велика кількість малих комп' ютерів мо­же замінити, а в окремих випадках і перевершити за продуктив­ністю, універсальну ЕОМ. Першим кроком до реалізації цього проекту стала архітектура розподілення файлів, що включає фай­ловий сервер і багато настільних ПК, які зв' язані мережею (рис. 2). Файловий сервер завантажує файли з відокремленого місця розташування ПК, а прикладні програми виконуються цілковито ПК. Архітектура розділення файлів набула популярності при ви­користанні програмних продуктів на зразок dBASE, FoxPro і CHpper. Спочатку мережі ПК були засновані на ідеї спільного ви­користання файлів, тому що це найпростіший варіант. Однак така мережа добре працювала лише в окремих випадках, адже мала низку обмежень.

ПК

Логіка представлення Бізнес-логіка Логіка доступу до даних Дані

ПК

[

Логіка представлення

 

Бізнес-логіка

 

Логіка доступу до даних

 

Дані

 

ПК

Логіка представлення Бізнес-логіка Логіка доступу до даних

Дані

ПК

Логіка представлення Бізнес-логіка Логіка доступу до даних

Дані

Рис. 2. Архітектура розділення файлів

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

Архітектура клієнт— сервер. Прагнення до удосконалення архітектури розподілення файлів привело до заміни файлового сервера сервером баз даних. Замість передачі файлів у цілісній формі сервер баз даних пересилає тільки відповіді на запити клі­єнтів, зменшуючи в такий спосіб навантаження на мережу. Реалі­зація цього підходу привела до появи у 1980-х роках архітектуриклієнт—сервер (рис. 3). Розробка цієї архітектури супроводжува­лася введенням поняття «клієнта» як сторони, котра запитує фу­нкції/обслуговування, та поняття «сервера» як сторони, яка надає функції/обслуговування. На рівні програмного забезпечення по­діл «клієнт — сервер» був цілком логічним, адже процеси клієнта і сервера можуть фізично розміщуватися як на одному, так і на різних комп' ютерах.

ПК

Логіка представлення Бізнес-логіка Логіка доступу до даних Дані

ПК

 

Логіка представлення Бізнес-логіка Логіка доступу до даних

Дані

 

 

 

ПК

Логіка представлення Бізнес-логіка Логіка доступу до даних

Дані

 

ПК

 

Логіка представлення

 

Бізнес-логіка

 

Логіка доступу до даних

 

Дані

Рис. 3. Ранні архітектури клієнт—сервер

Слід підкреслити, що загальна назва архітектури клієнт—сер-вер включає три типи архітектури: дволанкову, триланкову і ба-гатоланкову. Серед цих типів найперше була розроблена дволан-кова архітектура.

Дволанкова архітектура розділяє додаток на дві части­ни, клієнтську і серверну (рис. 4). Клієнтська частина містить логіку представлення, а логіка доступу до даних, систе­ма управління базою даних і сама база даних розміщується у серверній частині. Алгоритми бізнес-логіки можуть розміщу­ватися як на комп' ютері клієнта разом з логікою представлен­ня (конфігурація «товстий клієнт»), так і на стороні сервера (конфігурація «тонкий клієнт»), а також можуть бути розподі­лені між ними. На практиці більш поширена конфігурація «товстий клієнт», оскільки сумарна обчислювальна потужність клієнтів, принаймні теоретично, перевищує потужність єдино­го сервера.

Клієнт

Клієнт

Клієнт

Логіка представлення

Бізнес-логіка

А) Конфігурація „товстий" клієнт / "тонкий" сервер

Клієнт

Клієнт

Клієнт

Логіка представлення

Бізнес-логіка

Сервер

Бізнес-логіка Дані

Б) Конфігурація „тонкий" клієнт / " товстий" сервер

Рис. 4. Дволанкова архітектура

Разом з тим, дволанкова архітектура (особливо конфігура­ція «товстий клієнт») має низку недоліків. Як і архітектура розділення файлів, дволанкова архітектура має обмеження, які випливають з потужності окремих обчислювальних машин клієнтів. Фундаментальний недолік стосується обмеження кі­лькості одночасних з' єднань із сервером, який підтримує від­крите з' єднання з усіма активними клієнтами, навіть якщо жо­дної діяльності з їх боку немає. Це необхідно, щоб сервер одержував сигнали тактового імпульсу. Якщо клієнтів менше ста, цей недолік не дуже явний. Однак, якщо кількість клієнтів перевищує сотню, продуктивність системи починає швидко деградувати до неприпустимо низького рівня. У деяких при­кладних системах бізнес-логіку реалізують за допомогою збе­режених процедур, хоча ці механізми від системи до системи можуть відрізнятися. Розглянуте дозволяє зробити висновок, що дволанкова архітектура добре працює в маленьких робо­чих групах.

Триланкова архітектура. Із середини 1990-х років визнання фахівців отримала триланкова архітектура, яка, як і дволанкова, підтримує концепцію клієнт-сервер, але за рахунок розподілу си­стеми за функціональним призначенням між трьома ланками: ло­гікою представлення, бізнес-логікою і логікою доступу до даних

(рис. 5).

Клієнт

Клієнт

Клієнт

Логіка представлення

Середня ланка

Сервер програм

Бізнес-логіка

Ланка сервера

Сервер

Дані

Рис. 5. Триланкова архітектура

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

Виділяють чотири варіанти побудови інформаційно-аналітичних систем, заснованих на триланковій архітектурі: із сервером додатків, з монітором обробки транзакцій, із серве­ром передачі повідомлень, із брокером об' єктних запитів. Усі варіанти базуються на перенесенні частини функціоналу на проміжні програмні комплекси, тому для прикладу розглянемо тільки сервер додатків. У триланковій архітектурі з сервером додатків ланка клієнта містить тільки логіку представлення, тоді як алгоритми бізнес-логіки і логіки доступу до даних пе­реміщені в середню ланку (рис. 6). За такого підходу сервер програм є сховищем бізнес-правил і процедур, а клієнти з' єднуються із сервером програм і надають йому дані для об­робки.

Середня ланка

Ланка сервера

Клієнт

Логіка представлення

Клієнт

|_

 

 

Логіка представлення

 

 

 

Клієнт

 

 

 

Логіка представлення

 

 

Сервер

 

 

 

Дані

 

 

Сервер

 

 

 

Дані

 

 

Сервер

 

 

 

Дані

Рис. 6. Триланкова архітектура з сервером програм

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

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

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

Таблиця 1

ПЕРЕВАГИ ТА НЕДОЛІКИ РІЗНИХ ТИПІВ АРХІТЕКТУРИ ПРИКЛАДНИХ СИСТЕМ

Тип архітектури

Максимальна кількість ко­ристувачів

Переваги

Недоліки

 

 

 

 

Централізована

Тисячі

Простота, достатньо висо­ка масштабованість

Орієнтація на певну апаратну платфор­му; недостатня гну­чкість

Розподілення файлів

Десятки

Простота

Надмірна обмеже­ність

Дволанкова

Сотні

Достатня простота; дуже потужні інструменти роз­робки

Дуже мала кількість користувачів

Триланкова

Необмежена

Висока масштабованість; висока продуктивність і надійність; основа для ба­гатократного використання існуючих компонентів; гнучкість

Велика складність з погляду розробки програмного забез­печення

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

Література

1. Інформаційні системи в економіці: монографія // за заг. ред. д-ра екон. наук, проф. С.В. Устенка. — К.: КНЕУ, 2012. — 425 с.

2. Козак І.А. Інформаційні технології віртуальних організацій // На­вчальний посібник. — К.: КНЕУ, 2005. — 380 с.

3. Ситник Н.В. Проектування сховищ і баз даних // Навчальний по­сібник. — К.: КНЕУ, 2004. — 348 с.

4. Шаховська Н.Б., Пасічник В.В. Сховища та простори даних // Монографія. — Л.: Видавництво Львівської політехніки, 2009. 244 с.

5. Журкин И. Г., Шайтура С. В. Геоинформационные системы. — М.: КУДИЦ-ПРЕСС, 2009. — 272 с.

6. Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с.

7. Codd E.F., Codd S.B., Salley CJ.Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate. // E.F.Codd & Associates, 1993.

8. Leon, Alexis. Enterprise Resource Planning. — 2nd. — New Dehli: McGraw-Hill, 2008. — С. 224. — 500 с.

9. Meer, Kamran H. Best Practices in ERP Software Applications.Lincoln, NE: iUniverse, 2005. — 232 с.

10. Hamilton, Scott. Maximizing your ERP system: a practical guide for managers. McGraw-Hill, 2003. — 392 с.

Статтю подано до редакції 22.04.12 р.

Страницы:
1 


Похожие статьи

А О Примостка - Архітектура інформаційно-аналітичних систем еволюція та типологія