Удаленный вариант режима клиент-сервер

Удаленный вариант режима клиент-сервер может быть реализован в виде однои многоуровневой структуры.

Первоначально рассмотрим реализацию одноуровневой структуры (рис. 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. ©.

Если из таблицы 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

Сравнительные характеристики прикладных технологий

Рис. 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.