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



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

1. ОГЛЯД І АНАЛІЗ РОЗГЛЯДУВАНОЇ ПРОБЛЕМИ І ІСНУЮЧИХ МЕТОДІВ І ЗАСОБІВ ЇЇ ВИРІШЕННЯ


1.1 Огляд архітектури “КЛІЄНТ-СЕРВЕР”


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

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

Реальне поширення архітектури “клієнт-сервер” стало можливим завдяки розвитку й широкому впровадженню в практику концепції відкритих систем. Тому ми почнемо з короткого введення про них.

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

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

Практичною опорою системних і прикладних програмних засобів відкритих систем є стандартизована операційна система. У цей час такою системою є UNIX. Фірмам-постачальникам різних варіантів ОС UNIX у результаті тривалої роботи вдалося прийти до угоди про основні стандарти цієї операційної системи. Зараз всі розповсюджені версії UNIX в основному сумісні по частині інтерфейсів, наданих прикладним (а в більшості випадків і системним) програмістам. Як здається, незважаючи на появу системи, що претендує на стандарт, Windows NT, саме UNIX залишиться основою відкритих систем у найближчі роки.

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

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



1.1.2 Клієнти та сервери локальних мереж.


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

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

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

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

Прикладами серверів можуть служити:

• сервер телекомунікацій, що забезпечує послуги зі зв'язку даної локальної мережі із зовнішнім світом;

• обчислювальний сервер, що дає можливість робити обчислення, які неможливо виконати на робочих станціях;

• дисковий сервер, що володіє розширеними ресурсами зовнішньої пам'яті й їх у використання користувачам й, можливо, іншим серверам;

• файловий сервер, що підтримує загальне сховище файлів для всіх робочих станцій;

• сервер баз даних, фактично звичайна СУБД, що приймає запити по локальній мережі й повертає результати.

Сервер локальної мережі надає ресурси (послуги) робочим станціям й/або іншим серверам.

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




1.1.3 Системна архітектура “клієнт-сервер”


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

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

Інтерфейс серверної частини визначений і фіксований. Тому можливо створення нових клієнтських частин існуючої системи (приклад інтероперабельності на системному рівні).

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

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

Загальним рішенням проблеми мобільності систем, заснованих на архітектурі “клієнт-сервер” є опора на програмні пакети, що реалізують протоколи вилученого виклику процедур (RPC - Remote Procedure Call). При використанні таких засобів звертання до сервісу у вилученому вузлі виглядає як звичайний виклик процедури. Засоби RPC, у яких, природно, утримується вся інформація про специфіку апаратур локальної мережі й мережних протоколів, переводить виклик у послідовність мережних взаємодій. Тим самим, специфіка мережного середовища й протоколів схована від прикладного програміста.

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

Якщо система реалізована на основі стандартного пакета RPC, вона може бути легко перенесена в будь-яке відкрите середовище.

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

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

Рисунок 1. Обробка даних у різних архітектурах
Локальний комп'ютер



Локальний додаток




СУБД


Дані


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




Клієнт

Файл-сервер

Мережевий додаток

Дані



СУБД




Клієнт


Мережевий додаток





Пересилання даних

СУБД


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



Сервер БД

Клієнтський додаток




Дані


Клієнтський додаток



пересилання запитів

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




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


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

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