Архітектура файл-сервер

Дана архітектура стала популярною в той момент, коли персональні комп'ютери стали об'єднуватися в локальні мережі на основі файлового сервера (наприклад, Novell Netware). Особливо популярною ця архітектура була в середині-кінці 80-х років, в період масового об'єднання персональних комп'ютерів в локальні обчислювальні мережі.

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

Мал. 2. Однокористувальницька інформаційна система і її багато користувачів варіант на основі файл-сервера.

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

На основі моделі файлового сервера функціонують такі популярні СУБД як FoxPro (Microsoft), dBase (Borland), CF-Clipper (Computer Associates International), Paradox (Borland) і ін.

СУБД розглянутого класу коштують недорого, прості в установці і освоєнні. Але вони мають і ряд істотних недоліків:

1. Сильне збільшення трафіку по мережі при інтенсивній роботі декількох користувачів.

2. Незручність спільної роботи з системою.

3. Неможливість відстеження інформації під час апаратних збоїв.

4. Проблема можливих незакритих транзакцій.

5.2. Архітектура "Клієнт-Сервер"

Основні особливості архітектури «клієнт-сервер»

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

Сервер баз даних являє собою мультіпользовательской версію СУБД, виконання, як правило, на потужному комп'ютері. Додатки-клієнти посилають з робочих станцій запити на вибірку (вставку, оновлення, видалення) даних. При цьому сервер виконує всю "брудну" роботу з відбору даних, відправляючи клієнтові тільки необхідний результат.

Мал. 3. Архітектура "клієнт-сервер»

Такий підхід забезпечує рішення трьох важливих завдань:

· - зменшення навантаження на мережу

· - зменшення вимог до комп'ютерів-клієнтам

· - підвищення надійності і збереження логічної цілісності бази даних.

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

Але ці СУБД мають і недоліки:

· Вони набагато дорожче СУБД попереднього класу, складні в освоєнні,

· Для ефективної роботи цих СУБД потрібні високошвидкісні (а тому і дорогі) сервери і мережі.

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

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

5.3. Архітектура з використанням сервера додатків (трехзвенная архітектура)
У комп'ютерних технологіях трирівнева архітектура, синонім трехзвенная архітектура (англ. Three-tier або Multitier architecture) передбачає наявність таких компонентів програми:

клієнтську програму (зазвичай говорять «тонкий клієнт» або термінал), підключений до сервера додатків. який в свою чергу підключений до сервера бази даних.

Вони можуть взаємодіяти один з одним за наступною схемою:

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

1. Представлення даних - на стороні клієнта.
2. Прикладний компонент - на виділеному сервері додатків (як варіант, що виконує функції проміжного ПО).
3. Управління ресурсами - на сервері БД, який і представляє запитувані дані.

Отже, ідея сервера додатків полягає в розбитті програми на дві частини - власне клієнта і сервера цього додатка. Причому сервер додатків може бути один на багато додатків. Клієнти спілкуються з сервером додатків (або з серверами додатків, ніхто не забороняє мати кілька серверів додатків). Клієнти посилають сервера додатків запити, а отримують відповіді. Клієнти можуть звернутися і безпосередньо до сервера бази даних за тими чи іншими даними. Звернення за даними до сервера бази даних може виробляти і сервер додатків.
Використання сервера додатків в триланкової архітектурі дозволяє пом'якшити або звести нанівець недоліки традиційної архітектури "клієнт сервер".