На головну

Клієнт-серверні додатки

  1.  Amp; && 106. Де на робочому столі відображається інформація про запущені додатках Windows
  2.  Intranet-додатки
  3.  Як додаток. Політ Гоголя, або дещо про фабулі і сюжеті
  4.  вкладка Додатки
  5.  Геометричні застосування визначеного інтеграла
  6.  Геометричні застосування визначеного інтеграла
  7.  Геометричні застосування визначеного інтеграла.

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

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

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

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

Мал. 4.3. Загальне уявлення інформаційної системи в архітектурі "клієнт-сервер"

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

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

Тут необхідно зробити ще два зауваження.

Зазвичай компанії, що виробляють розвинені сервери баз даних, дистанціюються від того, щоб забезпечити можливість використання своїх продуктів не тільки в стандартних на сьогоднішній день TCP / IP-орієнтованих мережах, але в мережах, заснованих на інших протоколах (наприклад, SNA або IPX / SPX) . Тому при організації мережевих взаємодій між клієнтської і серверної частинами СУБД часто використовуються не стандартні засоби високого рівня (наприклад, механізми програмних гнізд або викликів віддалених процедур), а власні функціонально подібні засоби, менш залежні від особливостей мережевих транспортних протоколів.

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

Подивимося тепер, що ж відбувається на стороні сервера баз даних. У продуктах практично всіх компаній сервер отримує від клієнта текст оператора мовою SQL. Сервер виробляє компіляцію отриманого оператора. Не будемо тут зупинятися на тому, який мову перекладу використовується конкретним компілятором; в різних реалізаціях застосовуються різні підходи Головне, що в будь-якому випадку на основі інформації, що міститься в таблицях-каталогах бази даних виробляється перетворення непроцедурного уявлення оператора в деяку процедуру його виконання. Далі (якщо компіляція завершилася успішно) відбувається виконання оператора. Ми знову не будемо обговорювати технічні деталі, оскільки вони різняться в реалізаціях. Розглянемо можливі дії операторів SQL.

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

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

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

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

Аналогічно, тригери можуть спрацьовувати при знищенні об'єктів схеми бази даних (доменів, таблиць, обмежень цілісності і т.д.). Особливий клас операторів мови SQL складають оператори виклику раніше визначених і збережених в базі даних процедур. Якщо процедура визначається за допомогою досить розвиненої мови, що включає і непроцедурного оператори SQL, і чисто процедурні конструкції (наприклад, мови PL / SQL компанії Oracle), то в таку процедуру можна помістити серйозну частину програми, яка при виконанні оператора виклику процедури виконуватиметься на стороні сервера, а не на боці клієнта. При виконанні оператора завершення транзакції сервер повинен перевірити дотримання всіх, так званих, відкладених обмежень цілісності (до таких обмежень відносяться обмеження, що накладаються на вміст таблиці бази цілком або на кілька таблиць одночасно; наприклад, сумарна зарплата співробітників відділу 999 не повинна перевищувати 150 млн. Руб .). Знову до перевірки відкладених обмежень цілісності можна ставитися як до виконання серверної частини програми. Як видно, в клієнт-серверної організації клієнти можуть бути досить "тонкими", а сервер повинен бути "товстим" настільки, щоб бути в змозі задовольнити потреби всіх клієнтів (рисунок 4.4).

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

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

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

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



 Призначення. |  Intranet-додатки

 ПРИМІТКА |  ПРИМІТКА |  Тема 4. Загальні принципи проектування АІС |  Використання загальноприйнятих, стандартних нотацій і угод |  ПРИМІТКА |  ПРИМІТКА |  ПРИМІТКА |  Тема №7 |  Тема №8. Рівні подання інформаційних систем |  Файл-серверні додатки |

© um.co.ua - учбові матеріали та реферати