Архітектура клієнт-сервер

   

                                                Клієнт

   

                     пересылка     Сетевое приложение

                          данных

   

                                                   СУБД     
 

   Архитектура “клиент-сервер” 

             

               Сервер БД

             Клієнтська   

            СУБД       програма

   

   

       Дані

   

             Клієнтська             програма   

   пересилка запитів

     і результатів 

   Рис.1. Обробка даних в різних архітектурах 

   1.4. Сервери баз даних

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

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

   1.5. Принципи взаємодії  між клієнтськими  і серверними частинами

   Доступ  до бази даних від прикладної програми або користувача проводиться  шляхом звернення до клієнтської  частини системи. В якості основного інтерфейсу між клієнтською і серверною частинами виступає мова баз даних SQL. 

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

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

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

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

   1.6. Переваги протоколів  віддаленого виклику  процедур

   Згадувані вище протоколи віддаленого виклику  процедур особливо важливі в системах управління базами даних, заснованих на архітектурі "клієнт-сервер". 

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

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

   1.7. Типове розділення  функцій між клієнтами  і серверами

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

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

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

   1.8. Архітектури процесора  бази даних.

   Основна частина будь-якої системи "клієнт-сервер" - це сервер БД. З часу виникнення архітектури "клієнт-сервер" з'явилося багато варіантів архітектури процесора БД, оскільки він багато в чому визначає успіх всієї системи. Основна вимога до сервера БД - забезпечення мінімального часу виконання запитів при максимально можливому числі користувачів. Існують дві основні архітектури для побудови процесора БД: архітектура з декількома процесами і багатопотокова архітектура. 

   1. Архітектура з декількома процесами

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

   2. Багаторівнева архітектура

   Ця  архітектура використовує тільки один виконуваний файл, з декількома потоками виконання. Головна перевага - більш скромні вимоги до обладнання, ніж для архітектури з кількома процесами. Тут сервер бере на себе поділ часу між окремими потоками, іноді даючи перевагу деяким завданням над іншими. Крім того, відпадає необхідність у складному механізмі взаємодії процесів. З цієї архітектурі побудовані MS SQL Server та Sybase SQL Server.  
2. Трирівнева архітектура "клієнт-сервер" 
На верхньому рівні абстрагування взаємодії клієнта і сервера достатньо чітко можна виділити наступні компоненти:

    
• презентаційна логіка (Presentation Layer - PL), перед-призначена для роботи з даними користувача;

   • бізнес-логіка (Business Layer - BL), призначена для перевірки правильності даних, підтримки посилальної цілісність-ності ..;

   • логіка доступу до ресурсів (Access Layer - AL), призначе-значення для зберігання даних; 
 
Таким чином можна, можна прийти до декількох моделях клієнт-серверної взаємодії: 

   1. "Товстий" клієнт. (fat client)

   

         Сервер БД                  Користувацький інтерфейс

     

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

          

                                               

   

                Користувацький інтерфейс 

   

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

   Найбільш часто зустрічається варіант реалізації архі-тектури клієнт-сервер у вже впроваджених і активно викорис-вуються системах. Така модель має на увазі об'єднання в клієнтському додатку як PL, так і BL, таким чином забезпечується повна децентралізація управління бізнес-логікою. Однак у разі потреби виконання будь-яких змін у клієнтському додатку доведеться змінювати вихідний код.Серверна частина, при описаному підході, являє собою сервер баз даних, що реалізує AL. До описаної моделі часто застосовують абревіатуру RDA - Remote Data Access.  
 
 
 

   2. "Тонкий" клієнт. (thin client)

   

     

      Бізнес-

       Логіка         Користувацький інтерфейс

     
 

   

       Дані 

           

               Користувацький інтерфейс  
 
 

   Модель, що починає активно використовуватися в корпора-тивної середовищі у зв'язку з поширенням Internet-технологій і, в першу чергу, Web-браузерів. У цьому випадку клієнтське додаток забезпечує реалізацію PL, тому клієнт може задовольнятися досить скромною апаратною платформою, а сервер об'єднує BL і AL. Мак-мально завантаження сервера передбачає виконання бізнес-логіки тільки за допомогою збережених процедур сервера (Збережені процедури - відкомпілювалися SQL-інструкції, що зберігаються на сервері). Це дозволяє максимально централізованому контроль над даними і легко змінювати правила роботи відразу для цілого підприємства. З іншого боку, незначне коректування правил, що стосується тільки частини користувачів, зажадає тривалої процедури зі-годження. У цьому випадку неможливо реалізувати якісь винятки із загальних правил для деяких користувачів або додатків. У принципі, це добре і є запорукою безпеки і цілісності даних. 

 

    3. Сервер бизнес-логики. (трехуровневая архитектура)

   

           Проміжний сервер

                     Користувацький

     Бізнес-логіка                 інтерфейс

     Другого рівня

     
 
 

   

             Сервер БД

                    Користувацький

           Бізнес-логіка               інтерфейс

              сервера

     
 

   

                Дані 
 
 

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

   3. Программные средства  разработки

   3.1. Универсальные средства

   Для разработки клиентских приложений существует громадное число универсальных пакетов программ, которые позволяют выполнить соединение с сервером и разработать для пользователя удобный графический интерфейс, позволяющий эффективно работать с данными. Некоторые из этих средств для разработки приложений в архитектуре “клиент-сервер” перечислены в таблице.