Базы данных

  На  рис.2.2 изображена схема интеграции информации двух источников средствами медиатора (как и в случае хранилищ данных, количество источников, разумеется, может быть произвольным).  

    

                     Рис. 2.2 Организация медиатора 

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

                 Как видно из рис.2.2, медиатор посылает запросы каждой из оболочек, а те в свою очередь адресуют их соответствующим источникам. (В определенных случаях медиатор способен направлять какой-либо оболочке целую серию запросов, а к некоторым другим оболочкам не обращаться вовсе.) Оболочка передает медиатору полученный ею итог обработки запроса, а медиатор, осуществляя объединение и трансляцию данных, возвращенных оболочками, формирует окончательный результат и отсылает его пользователю 
 
 

    Лекция 14

ТЕМА 3.   Клиент-серверные системы

                                              3.1. Основные понятия

         Ранее мы отмечали, что с БД  одновременно может работать  много пользователей. Это достигается использованием технологии  "клиент/сервер".

               Архитектура клиент-сервер –  это общее понятие вычислительной  системы состоящей из 3-х частей:  клиента, сервера и коммутационных  средств.

Клиент- это часть системы требующая  для своей работы предоставление некоторых сервисов (услуг).

Сервер  – это часть системы,  обслуживающая  клиента, т.е. предоставляющая сервисы  по запросам клиентов.

Коммутационные  средства – программные и технические  средства,  обеспечивающие взаимодействие сервера с  клиентами.

    Основной принцип архитектуры  клиент-сервер применительно к  технологии баз данных заключается  в разделении функций стандартного пользовательского приложения на 5 групп:

1 функции  ввода-вывода и отображения данных

2 функции  реализации прикладной задачи

3 функции  обработки данных внутри прикладной  задачи

4 функции  управления базой данных

5 служебные  функции

 Состав  типового приложения,  работающего  с БД,  представлен на рис.3.1.

                        Рис.3.1. Состав типового приложения

1. Ввод-вывод и отображение предусматривает:

- формирование  экранных изображений

- чтение  и запись информации в экранные  формы

- обработка  движений мыши и нажатий клавиш  и пр.

Для этого  используются различные графические интерфейсы, например,

GUI,  который поддерживается в разных операционных системах Windows,

OS/2 и др.

2. Реализация  прикладной задачи означает реализацию  алгоритма пользователя. Например,  алгоритма банковской или инженерной  задачи.

Обычно  для такой реализации используются базовые или другие алгоритмические языки (Cи++, Visual Basic и др.). 

3. Обработка  данных внутри  прикладной задачи  предполагает использование запросов  к БД на выборку или модификацию  требуемых данных. Для этого используются  операторы языка SQL.

4. Функции  управления БД – это функции  самой СУБД.

5. Служебные  функции выполняют роль связок  между первыми четырьмя функциями.  Эти функции обеспечиваются промежуточным программным обеспечением (ППО). 

      Распределение указанных 5-ти функций между клиентами и сервером является основной задачей проектирования клиент-серверных систем.

      В настоящее время нет какой-либо методики такого распределения.

 Как  правило,  распределить 5 функций   строго не удается: отдельные   части какой-либо функции могут присутствовать и на клиенте и на сервере.

      Далее будут рассмотрены наиболее  распространенные модели реализации  архитектуры “клиент-сервер”.     

               3.2 Модели клиент  –сервер в архитектуре баз данных 

                     Модель удаленного доступа к данным

                    Клиент                                               Сервер 
 
 
 
 
 
 

                               Рис.3.2. Модель удаленного доступа 

             Частично на сервере может  присутствовать компонент обработки  данных в виде хранимых процедур и триггеров,  осуществляющих контроль данных.

          Основное достоинство – унификация  интерфейса: общение между клиентом  и сервером основывается на  языке SQL.

         Недостаток: Разные клиенты могут  выполнять одинаковые операции. Следовательно,  с одной стороны,  дублируется код клиентов, а с другой – сервер выполняет одинаковые операции. 
 

                              Модель активного сервера БД

            В модели активного сервера   функции реализации прикладной задачи и обработки данных выполняются  на сервере в виде хранимых процедур и в прикладной программе клиента .

Обработка данных выполняется операторами встроенного SQL.

       В основном хранимыми процедурами  реализуются общие задачи многих  пользователей по контролю данных (рис. 3.3).. 
 

 

                  Клиент                                                 Сервер

              
 
 
 
 

                           Рис.3.3. Модель активного сервера БД

          К достоинству модели следует  отнести то, что хранимые процедуры могут быть использованы разными клиентами. Это существенно уменьшает дублирование  отдельных фрагментов прикладной программы.

     Недостатком  модели является большая загрузка  сервера. 

                                  Модель сервера  приложений

Данная трехзвенная модель находит В настоящее время все большее число поклонников находит трехзвенная модель сервера приложений (рис.3.4). Это обусловлено ее гибкостью

            Клиент                     Сервер приложений      Сервер БД

 
 
 
 
 
 
 
 
 

                Рис.3.4. Модель сервера приложений        

            Общие части многих приложений  различных пользователей (прежде всего это относится к задачам проверки целостности данных) реализуются на сервере приложений в виде хранимых процедур. Причем реализация общих  задач может быть выполнена на любых алгоритмических языках.

        К недостаткам модели следует  отнести  большие затраты на  ее реализацию, обусловленные большей  сложностью.

Кроме того эта  модель менее надежная по сравнению  с двухзвенной.

   

                                  3.3.     Промежуточное программное обеспечение

          Клиенты и серверы в принципе могут располагаться на одном ПК.

Но более типично  использование нескольких ПК,  связанных  сетью.

       Для работы с сетью используются специальные промежуточные программные средства (иногда называемые коммуникационным программным обеспечением).

    На  рис.3.5 показано взаимодействие между компонентами ППО.

        

                                       Рис.3.5. Взаимодействие между компонентами ППО

Клиент выдает запрос  на SQL. ППО передает этот запрос в виде сообщения сетевым протоколам. При этом ППО форматирует это сообщение в соответствии с требованиями соответствующего протокола. На приемном конце ППО преобразует сообщение в запрос,  понятный серверу.

     Таким  образом,  ППО обычно включает в себя 3 компонента, показанные на рис.3.6:

-программный  интерфейс приложения (Application Programming Interfase, API),

• транслятор запросов,

-   сетевой  транслятор.

                                 

                         Рис. 3.6. Компоненты ППО 

         Эти компоненты (или их функции)  в основном распределяются по  нескольким  уровням программного  обеспечения.

          Программный интерфейс приложения (АР1)  открыт для клиентского приложения. Программист взаимодействует с ППО через АРI, поставляемый вместе с ППО. API ППО позволяет программисту писать стандартный код SQL вместо кода, специфичного для данного сервера БД. Иначе говоря, АР1 обеспечивает  независимость клиентского процесса от сервера БД. Такая независимость означает, что сервер можно заменить без необходимости переписывать клиентское приложение.

        Транслятор запросов  транслирует SQL-запросы в специфичный синтаксис сервера -БД. На уровне транслятора БД SQL-запрос отображается на SQL-протокол БД. Поскольку сервер базы данных может иметь какие-то специальные функциональные возможности, транслятор запросов к БД может оптимально транслировать основной SQL-запрос в специфичный формат, используемый на сервере БД. Если SQL-запрос использует данные от двух различных серверов БД, то транслятор запросов берет на  себя заботу о связи с каждым сервером и об извлечении данных в формате, подходящем для клиентского приложения.

     Сетевой транслятор управляет сетевыми  коммуникационными протоколами.   

Напомним,  что  сервер может использовать любые  сетевые протоколы. Поэтому если клиентское приложение подключается к двум базам данных, в одной из которых используется протокол TCP/IP,  а в другой  IPX/SPX , то сетевой транслятор обрабатывает все детали связи каждой базы данных прозрачно для клиентского приложения.