Особливості архітектури розподіленої ІС

2.4.1. Передумови появи розподілених ІС та проблеми проектування розподілених БД

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

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

Рис. 2.4. Схема розподілу даних між серверами

У загальному випадку розподілена або дистрибутивна БД (DDВ –Distributed DataBase) - це сукупність множини взаємопов'язаних баз даних, що розподілені в комп'ютерній мережі.

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

Така БД корпорації може бути подана або як система баз даних з віддаленим доступом на основі розширеної архітектури «клієнт-сервер», або як розподілена база даних, що відповідає фундаментальному принципу РБД [11].

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

У випадку дистрибутивної БД має виконуватися фундаментальний принцип РБД «Rule Zero», або «Правило нуль»: «Для користувача розподілена система має виглядати такою ж, як і нерозподілена». Тобто, усі проблеми розподілу мають бути внутрішніми, а не зовнішніми (не для користувачів) [ 11].

Дж. Дейт сформулював дванадцять цілей забезпечення «Rule Zero»: локальна автономія, незалежність від центрального вузла, безперервне функціонування, незалежність від розташування, незалежність від фрагментації, незалежність під реплікації, обробка розподілених запитів, керування розподіленими трансакціями, незалежність від апаратного забезпечення, незалежністьвід операційної системи, незалежність від мережі, незалежність від СУБД [11]. Кожна з них є ідеальною, але сучасні розробки ІС повинні наближатися до їх виконання.

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

Рис. 2.5. Єдине рішення для всієї корпоративної інформації

Рис. 2.6 ілюструє архітектуру програмного забезпечення бізнес-об'єктів корпорації.

Рис. 2.6. Архітектура програмного забезпечення бізнес об'єктів

корпорації

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

Для користувачів повинні бути забезпечені:

• автономність роботи з даними;

• простота і зручність інтерфейсу.

Контроль роботи самої системи вимагає:

• могутньої системи безпеки;

• масштабованої архітектури;

• розширюваності, відкритості компонентів.

2.4.2. Особливості архітектури та концепції організації даних в аналітичній частині корпоративної інформаційної системи

База даних корпорації поділяється на дві частини - оперативну(деталізовану, операційну або трансакційну) та аналітичну.

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

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

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

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

Одним із головних моментів при розробці СППР є організація бази даних.

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

• час обробки запитів до розподіленої БД часто є неприйнятним для аналітичних систем, тому що структура бази даних СОД, розрахованої на інтенсивне відновлення, у високому ступені нормалізована, і в аналітичному запиті до неї потрібне з'єднання значної кількості таблиць;

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

• головним недоліком є відсутність практичної можливості огляду тривалих історичних послідовностей.

Відомі такі концепції побудови аналітичних систем, принципово відмінні від варіанта РБД: Information Warehouse - сховища даних (СД); Data Mart - вітрини даних (ВД), або кіоски даних, для яких властива ОLАР-обробка даних; Relational Оп-Line Analytical Processing (ROLAP) - оперативна аналітична обробка даних реляційної моделі; Multidimensional Оп- Line Analytical Processing (MOLAP) - оперативна аналітична обробка даних багатовимірної моделі; Hybrid Оп- Line Analytical processing (HOLAP) - оперативна аналітична обробка даних гібридної моделі [39].

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

У табл. 2.1 наведено порівняння характеристик даних в інформаційних системах, орієнтованих на операційну та аналітичну обробку. У табл. 2.2 наведені основні вимоги до даних у сховищі даних.

Таблиця 2.2

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Стандарти на розробку забезпечувальної компоненти КІС	\|	Основні вимоги до даних у сховищі даних

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.