Лекція 14. Розподілені бази даних

Концепція відкритих систем. Архітектура "кліент-сервер", кліенты і сервери мереж. Технологія роботи в архітектурі "кліент-сервер". Принципи взаємодії між кліентськими та серверними частинами. Типичний поділ функцій між кліентами и серверами. Розподілена обробка інформації [23, С. 8-20]

Проблемі розподіленої обробки даних присвячено безліч джерел: статті, книги, монографії. Широко відома монографія К. Дейта "Введення в системи баз даних" (Наука, 1996), яка витримала 8 видань. Однак, на наш погляд, найбільш концентрована інформація представлена ​​в навчальному посібнику Л.В. Найхановой [23]. Тут розглядається створення і обслуговування розподілених баз даних (РБД) і розробка програм, що дозволяють організувати з їхньою допомогою розподілені обчислення.

Ми в даній лекції розглянемо тільки (в силу обмежень за часом) стисле викладення 1-й лекції 1-й частини книги Найхановой. Цей матеріал можна розглядати як введення в частину згаданої проблеми, присвячену розподіленим баз даних. З іншого боку, студенти, які вивчають даний курс, знайомі з основами організації баз даних по курсу лекцій «Бази даних», прочитаного ним у 4 семестрі.

Відкриті системи

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

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

Практичною опорою системних і прикладних програмних засобів відкритих систем є стандартизована операційна система. В даний час такими системами є UNIX та Windows NT.

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

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

 

Клієнти і сервери мереж

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

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

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

- обсяг оперативної пам'яті (далеко не всі категорії користувачів мають потребу в наявності великої оперативної пам'яті);

- наявність і обсяг дискової пам'яті (досить популярні бездискові робочі станції, що використовують зовнішню пам'ять дискового сервера);

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

При необхідності можна використовувати ресурси і / або послуги (сервіси), що надаються сервером.

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

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

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

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

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

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

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

• та інші.

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

Технологія роботи в архітектурі "клієнт-сервер"

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

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

• Сервер – це власне СУБД. Він підтримує всі основні функції СУБД: визначення даних, обробку даних, захист і цілісність даних і т.д.

Зокрема, він надає повну підтримку на зовнішньому, концептуальному і внутрішньому рівнях. Тому "сервер" в цьому контексті – це просто інше ім'я СУБД.

• Клієнт – це різні додатки, які виконуються "над" СУБД: додатки, написані користувачами, і вбудовані додатки, надані постачальниками СУБД або деякими сторонніми постачальниками програмного забезпечення. Звичайно, з точки зору користувачів, немає різниці між вбудованими додатками і додатками, написаними користувачем, – всі вони використовують один і той же інтерфейс сервера, а саме інтерфейс зовнішнього рівня. Винятками є спеціальні "службові" додатки, які називаються утилітами. Такі додатки іноді можуть працювати тільки безпосередньо на внутрішньому рівні системи. Утиліти швидше відносяться до безпосередніх компонентів СУБД, ніж до додатків в звичайному сенсі.

Додатки, в свою чергу, можна класифікувати на кілька чітко визначених категорій.

1. Програми, написані користувачами. Це в основному професійні прикладні програми, написані або на загальноприйнятій мові програмування, наприклад С, або на деяких оригінальних мовах, таких як FOCUS, хоча в обох випадках ці мови повинні якось зв'язуватися з відповідним підмовою даних.

2. Додатки, що надаються постачальниками (часто звані інструментальними засобами). В цілому призначення таких засобів – сприяти в процесі створення і виконання інших додатків, тобто додатків, які робляться спеціально для деякої специфічної задачи (хоча створені додатки можуть і не виглядати як додатки в загальноприйнятому сенсі). Дійсно, ця категорія інструментальних засобів дозволяє користувачам, особливо кінцевим, створювати додатки без написання традиційних програм. Наприклад, одне з наданих постачальниками інструментальних засобів може бути процесором мови запитів, за допомогою якого кінцевий користувач може видавати незаплановані запити до системи. Кожен такий запит є, по суті, не чим іншим, як спеціальним додатком (наприклад, ISQL СУБД MS SQL Server), призначеним для виконання деяких специфічних функцій.

Поставляються інструментальні засоби, в свою чергу, діляться на кілька самостійних класів:

• другие средства разработки приложений, включая CASE-продукты (CASE или Computer-Aided Software Engineering - автоматизация разработки программного обеспечения), и т.д.

• процесори мов запитів;

• генератори звітів;

• графічні бізнес-підсистеми;

• електронні таблиці:

• процесори звичайних мов;

• засоби управління копіюванням;

• генератори додатків;

• інші засоби розробки додатків, включаючи CASE-продукти (CASE або Computer-Aided Software Engineering - автоматизація розробки програмного забезпечення), і т.д.

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

Необхідно відзначити, що, так як система в цілому може бути чітко розділена на дві частини (сервер і клієнти), з'являється можливість роботи цих двох частин на різних машинах. Інакше кажучи, існує можливість розподіленої обробки.

Розподілена обробка передбачає, що окремі машини можна з'єднати якій-небудь комунікаційною мережею таким способом, що певна задача, яка оброблює дані, може бути розподілена на декількох машинах в мережі. Насправді, ця можливість настільки приваблива з різних міркувань, головним чином практичним, що термін "клієнт/сервер" став застосовуватися виключно в разі, якщо сервер і клієнти дійсно знаходяться на різних машинах. Таке застосування терміна – недбале, але дуже поширене. Технологія, що підтримує розподілену обробку даних, повинна забезпечувати клієнту доступ до розподіленої БД точно так же, як доступ до централізованої БД. При цьому дані можуть зберігатися на локальному вузлі, на віддаленому вузлі або обох вузлах – їхнє розташування повинне залишатися прозорим як для кінцевого користувача, так і для програм.

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

1. База даних на мейнфреймі.

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

3. Архітектура клієнт/сервер.

Історично з'явилася перша. Видобування даних та обробка відбувається на одній машині. Ця архітектура розрахована на одного користувача системи.

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

Час реакції на запит користувача складається з часу передачі даних з файл-сервера на робочу станцію і часу виконання запиту на робочій станції. Щоб час реакції такої системи був прийнятним, треба прискорити обмін даними з диском і наростити обсяг оперативної пам'яті для кешування даних з диска. Також бажано в якості робочої станції використовувати потужний комп'ютер. Вузьким місцем може виявитися мережеве середовище, тому пропускна здатність мережевий шини – теж важливий показник. Якщо зростає кількість одночасно працюючих користувачів і об'єм інформації, розмір пересилаємої інформації росте, тобто збільшується мережевий трафік. І як результат, час реакції системи значно падає. Така технологія має на увазі, що на кожній робочій станції знаходиться свій екземпляр СУБД, що працює з одними і тими ж даними. Взаємодія цих СУБД для синхронізації роботи через проміжну ланку у вигляді файл-сервера призводить до додаткових втрат.

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

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

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

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

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

Сервер розподіленої БД (Distributed DataBase Server) – це невелика операційна система, яка повинна вирішувати як мінімум наступні задачі:

• управління іменами в розподіленому середовищі (глобальний словник даних);

• оптимізація розподілених запитів;

• управління розподіленими транзакціями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Але якщо можуть виникнути потреби перерозподілу функцій між клієнтом і сервером, то вже зовсім не все одно, які операційні системи використовуються.

Утиліти

Утиліти – це програми, розроблені для адміністратора баз даних; вони використовуються при виконанні різних адміністративних завдань. Як уже згадувалося вище, деякі утиліти виконуються на зовнішньому рівні системи і тому являють собою не що інше, як додатки спеціального призначення.

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

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

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

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

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

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

Розподілена обробка

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

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

• Машина сервера може бути виготовлена ​​за спеціальним замовленням, пристосована для роботи з СУБД ( "машина бази даних") і може забезпечити кращу продуктивність СУБД.

• Машина клієнта може бути персональною станцією, пристосованою до потреб кінцевого користувача, і тому забезпечувати кращий інтерфейс, повну відповідність вимогам, швидку реакцію і в цілому додаткові зручності при використанні.

• Кілька різних машин клієнтів можуть мати доступ до однієї і тієї ж машині сервера. Тому одна база даних може спільно використовуватися декількома окремими клієнтськими системами.

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

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

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

• Клиент может получать доступ к любому количеству серверов одновременно (т.е. за один запрос можно получить комбинированные данные двух или более серверов). В этом случае серверы рассматриваются клиентом как один (с логической точки зрения), и пользователь не обязан знать, на какой именно машине какая часть данных содержится.

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

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

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

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

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

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур. При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры.

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

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

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

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