Навігація
Головна
 
Головна arrow Інформатика arrow Бази даних
< Попередня   ЗМІСТ   Наступна >

Віддалений варіант режиму клієнт-сервер

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

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

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

Для цілей налагодження БД вводять дві фази реалізації однорівневої структури.

А. Має місце тільки один клієнт (один інтерфейс).

Б. У програмі є декілька клієнтів.

А. На цій фазі серверну частину програми залишають на основному комп'ютері, а клієнтську візуально-програмну частину переносять на інший комп'ютер.

При реалізації БД виконується така послідовність операцій.

Однорівнева структура віддаленого варіанту режиму клієнт-сервер

Рис. 15.6. Однорівнева структура віддаленого варіанту режиму клієнт-сервер

  • 1. Інсталюється на сервері Delphi і віддалений варіант InterBase.
  • 2. На компиогере-клієнті встановлюються:
    • а) протокол доступу до InterBase (частіше всією - TCP / IP) у файлі SERVICES (папка WINDOWS)

gds_db 3050 / tcp;

  • б) IP-адресу сервера у файлі HOSTS (папка WINDOWS), що складається з цифрового коду та імені сервера, наприклад
  • 192.196.10.12 Server
  • 3. На клієнті ставиться Delphi і (тільки для процедури створення БД) частково встановлюється InterBase (WISQL, InterBase Server Manager (IBSM)).
  • 4. Проводиться переустановка аліаса:
    • а) за допомогою серверної утиліти BDE Administrator (далі - BDE) знищується локальний алиас;
    • б) в клієнтському BDE перевіряється наявність відповідного драйвера з набору SQL Links;
    • в) з клієнтського BDE встановлюється новий алиас. У його шляху до БД ім'я диска замінюється на ім'я сервера: 195.201.72.76:d ....
  • 5. Через клієнтську утиліту WISQL (або утиліту IBSM) проводиться з'єднання клієнта з БД па сервері.
  • 6. На клієнті встановлюється клієнтська візуально-програмна Deiphi-частина програми. У властивості AliasName компонента Database вибирається знову побудований алиас. У властивості DataBaseName встановлюється інше ім'я, що служить аліасом для компонент Query (так само як і для Table, DataModule).

Тепер клієнт може запустити програму в Delphi і почати роботу.

Відзначимо особливості "введення" нових користувачів. В якості параметрів входу в БД можуть бути використані або параметри системного адміністратора (user - SYSDBA, password - masterkey), або інші параметри.

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

Можлива реєстрація користувачів і з іншими параметрами (наприклад, DIMA і whr відповідно). Такі користувачі зможуть тільки під'єднатися до БД, проте не отримають права доступу ні до одного об'єкту БД. У цьому випадку права доступу задаються за допомогою операторів привілеїв.

Так, для таблиці statrasp ("Штатний розклад") і збереженої процедури proc_statrasp, що звертається до цієї таблиці, завдання привілеїв можливо в такій формі

GRANT ALL ON stat_rasp TO DIMA, (A)

GRANT EXECUTE ON PROCEDURE proc.statrasp TO DIMA. (B)

Якщо до отримання доступу (В) до збереженій процедурі доступ (А) не було наведено, то на додаток до оператора (В) слід задати

GRANT ALL ON stat_rasp TO PROCEDURE proc_statrasp. (C)

Якщо з таблиці stat rasp сформувати відповідні види для кожного користувача і забезпечити (через оператори привілеїв) доступ до цих видів, то таблиця stat_rasp буде фрагментована. При цьому кожен користувач отримає доступ тільки до "своїх" даними.

Після успішної апробації для процедури використання БЗ на комп'ютері-клієнті видаляються утиліти WISQL, IBSM.

♦ Б. При переході до другої фази необхідно врахувати фрагментацію, виконану раніше.

У прикладі є два підрозділи: наукове та виробниче. Наукове підрозділ зацікавлений у прийнятті наукових співробітників, виробниче - у прийнятті інженерів. Таким чином, маємо два клієнти-користувача.

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

Доступ до даних різним клієнтам забезпечимо за допомогою формування видів (View) для таблиць "Штатний розклад", "Кадри", "Правила". Через горизонтального поділу даних використання привілеїв доступу GRANT проблематично: використання привілеїв для певних стовпців позбавить клієнта можливості змінювати види, що необхідно відповідно до алгоритму роботи користувача.

Щоб надалі можна було вносити зміни у види (перегляди), необхідно дотримуватися таких умов:

  • а) перегляд повинен містити всі поля вихідної таблиці;
  • б) вихідна таблиця для виду повинна бути тільки одна;
  • в) оператор SELECT перегляду не повинен використовувати функцій агрегації даних, пропозиції HAVING, сполуки таблиць, збережених процедур, функцій, визначених користувачем.

Таким видом для таблиці "Кадри" (науковий підрозділ) може бути

CREATE VIEW Kadry_nauch

AS

SELECT * FROM Kadry

WHERE (dolgnos = 'науч_coтp' or dolgnos = 'відмовити' or dolgnos IsNull);

Тепер збережена процедура для клієнта (науковий підрозділ) звертається до виду Kadry_nauch.

За наявності декількох клієнтів необхідно розглянути два питання:

  • 1) формування нових користувачів;
  • 2) вибір системи блокування даних.
  • 1. Зазвичай спочатку звертаються до користувача-адміністратору БД з ім'ям SYSDBA і паролем masterkey, які згодом можуть бути змінені.

Це робиться за допомогою утиліти InterBase Server Manager. У головному меню вибирають елемент Tasks / User Security. У з'являється вікні фіксується система зареєстрованих па сервері користувачів. За допомогою кнопок Add User, Modify User, Delete User цього вікна можливо додати, змінити або знищити ім'я і пароль користувача.

Зауважимо, що утиліта IBSM здійснює збір статистики, примусову збірку сміття, створення резервної копії, відновлення БД з резервної копії, примусову запис на диск.

2. При роботі декількох клієнтів виникає питання одночасного зміни даних. Для його вирішення існує кілька рівнів ізоляції транзакцій (Transisolation): Dirty Read, Read Commited, Repeatable Read.

Справа в тому, що в Delphi існує дві версії даних: до транзакції зміни і після транзакції зміни.

При рівні Dirty Read конкуруючі транзакції зміни бачать зміни, внесені попередньої транзакцією (1-я фаза), але не підтверджені (2-я фаза). Якщо попередня транзакція використовує відкат, то інші транзакції будуть бачити недостовірні дані. Такий рівень ізоляції використовується рідко.

При рівні ізоляції Read Commited конкуруючі транзакції працюють тільки з підтвердженими змінами.

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

Рівень ізоляції встановлюється властивістю Transisolation компоненти Database. Найчастіше в InterBase використовують рівень Read Commited.

Якщо дві транзакції конкурують на одному запису, "спрацьовує" більш рання у підтвердженні транзакція.

Можливі три варіанти дозволу такого конфлікту, що визначаються в компоненті Database UpdateMode:

WhereAll (за замовчуванням) - пошук запису, яка повинна бути змінена, по всіх полях;

WhereKeyOnly - пошук по ключових полях;

WhereChanged - пошук по ключових полях і тим неключових полях, які були змінені при коригуванні даних.

Окремо слід сказати про кешованих (відкладених) змінах.

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

Для кешування слід в компоненті TQuery встановити властивість

CashedUpdate = True

до запуску програми або під час її виконання. Зроблені кешированниє зміни можуть бути скасовані в компоненті Database методом CancelUpdates. Підтвердження змін здійснюється методом ApplyUpdates. Для фіксації змін у БД використовується метод CommitUpdates.

Властивість UpdateRecordTypes дозволяє вказати тип "видимої" записи (змінена, додавання, видалення, неизмененная).

Помилки, що виникають при підтвердженні кешування, можна врахувати подією UpdateError форми Delphi.

У випадку, коли результати роботи оператора SELECT доступні тільки для читання, разом з компонентом TQuery використовують компонент TUpdateSQL.

Перейдемо до багаторівневої структурі віддаленого варіанту режиму клієнт-сервер (рис. 15.7).

Віддалений варіант режиму клієнт-сервер: багаторівнева структура

Рис. 15.7. Віддалений варіант режиму клієнт-сервер: багаторівнева структура

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

Щоб його спростити і зменшити обсяг додатки, використовують так звану багаторівневу (у ряді літературних джерел - трирівневу) структуру віддаленого варіанту режиму клієнт-сервер (рис. 15.7).

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

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

Для загального випадку розроблено базова технологія багатокомпонентної моделі об'єктів (Component Object Model - COM).

Для баз даних на основі СОМ запропонована спеціальна технологія - MultiTiered Distributed Application Services (MJDAS) або служба багаторівневого розподілу додатки.

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

MIDAS-технологія забезпечується сторінкою MIDAS палітри компонент Delphi і реалізується наступними прикладними технологіями.

Таблиця 15.5

Порівняльні характеристики прикладних технологій

Технологія

Гідності

Недоліки

DCOM

Органічний зв'язок з Windows Простота реалізації

Робота тільки під Windows NT

Немає координації серверів додатків

Немає координації даних

OLEnerprisc

Можливість роботи з Windows 95

Координація серверів додатків

Перемикання клієнтів на інші сервери

Товар Delphi 5

MTS

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

Отримується окремо

CORBA

Гетерогенні операційні системи

Кілька серверів додатків з перемиканням клієнтів

Додатковий захист даних

Складна структура

Деталізована багаторівнева структура режиму клієнт-сервер

Рис. 15.8. Деталізована багаторівнева структура режиму клієнт-сервер:

* - Зміст залежить від застосовуваної прикладної технології

Distributed COM (DCOM) - розширення технології СОМ, яка є в WindowsNT;

Сокети TCP / IP, які можуть працювати і без WindowsNT; OLEnterprise, розроблена фірмою Borland;

Microsoft Transaction Server (MTS) - управління транзакціями, заснована на СОМ з підвищеною помехозащищенностью;

Common Object Request Broker Architecture (CORBA) - архітектура брокера загальних запитів для взаємодії з даними різних операційних систем.

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

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

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

Деталізована схема багаторівневої структури має вигляд, наведений на рис. 15.8.

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук