Дипломна робота Розробка бази даних з архітектурою "клієнт-сервер"



Сторінка3/18
Дата конвертації26.12.2016
Розмір1.03 Mb.
1   2   3   4   5   6   7   8   9   ...   18

1.1.4 Сервери баз даних


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

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



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


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

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

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

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

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

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


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

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

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


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


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

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

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

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


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

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

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

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

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

1.2 Трирівнева архітектура “КЛІЄНТ-СЕРВЕР”


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

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

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

• логіка доступу до ресурсів (Access Layer - AL), призначена для зберігання даних;

Рисунок 2. “Товстий” клієнт. (fat client)


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





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



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


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


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

Рисунок 3. “Тонкий” клієнт. (thin client)





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







Дані


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

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

Рисунок 4. Сервер бізнесу-логіки. (Трирівнева архітектура)





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

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

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

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






Сервер БД

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

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




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


1   2   3   4   5   6   7   8   9   ...   18


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка