БД В АРХИТЕКТУРЕ «КЛИЕНТ

1
БД В АРХИТЕКТУРЕ «КЛИЕНТ-СЕРВЕР»
План лекции
1. Клиенты и серверы локальных сетей
2. Системная архитектура клиент-сервер
3. Модели рабочих нагрузок в архитектуре клиент/сервер
4. Уровни и модели архитектуры «клиент-сервер»
Рекомендуемая литература:
Т. Конноли. Базы данных. Проектирование, реализация и
сопровождение. Теория и практика.: Пер.с англ. – М.: Изд.дом
«Вильямс», 2006. – 1440 с.
1 Клиенты и серверы локальных сетей
В основе широкого распространения локальных сетей
компьютеров лежит известная идея разделения ресурсов.
Развитие этой идеи приводит к функциональному выделению
компонентов сети: рабочих станций и серверов локальной сети.
Сервер локальной сети (server) предоставляет ресурсы (услуги)
рабочим станциям и/или другим серверам. Рабочая станция
(клиeнты (client)) - кoмпьютepы, ocyщecтвляющиe дocтyп к
ceтeвым pecypcaм, пpeдocтaвляeмым cepвepoм.
В связи с ориентацией на подход открытых систем,
правильнее говорить о логических серверах (имея в виду набор
ресурсов и программных средств, обеспечивающих услуги над
этими ресурсами). Примерами логических серверов могут
служить:
 файловый сервер, поддерживающий общее хранилище
файлов для всех рабочих станций и в случае запроса фaйл
или
дaнныe цeликoм кoпиpyютcя нa зaпpaшивaющий
кoмпьютep;
 сервер приложений выпoлняет пpиклaдныe чacти клиeнтcepвepныx пpилoжeний, a тaкжe содержит дaнныe,
дocтyпныe клиeнтaм;
 сервер баз данных - фактически обычная СУБД,
принимающая запросы по локальной сети и возвращающая
результаты.
2
2 Системная архитектура «клиент-сервер»
Основные принципы системной архитектуры "клиент-сервер"
заключаются в следующем: ИС разбивается на две части,
которые могут выполняться в разных узлах сети - клиентскую и
серверную части.
Серверная сторона функционирует на специализированном
аппаратном комплексе, включающем в себя мощные аппаратные
средства, требуемый набор стандартного программного
обеспечения, систему управления базами данных и БД.
Прикладная
программа
или
конечный
пользователь
взаимодействуют с клиентской частью системы, которая в
простейшем случае обеспечивает просто надсетевой интерфейс.
Клиентская сторона приложения функционирует на рабочем
месте пользователя, в роли которого в подавляющем числе
случаев выступает персональный компьютер.
Клиентская часть системы при необходимости обращается по
сети (локальной или глобальной) к серверной части. При этом с
точки зрения клиента и сервера взаимодействие осуществляется
прозрачно.
Сетевой
компонент,
реализующий
это
взаимодействие включает в себя совокупность необходимого
сетевого оборудования, набор программных технологий,
обеспечивающих передачу данных между узлами сети, а также
собственно интерфейсный программный слой (протокол или
протоколы) для обмена запросами и результатами их
выполнения. В качестве основного интерфейса между
клиентской и серверной частями выступает язык баз данных
SQL.
Наиболее простая форма архитектуры «клиент-сервер» - это
разделение вычислительной нагрузки между двумя отдельными
процессами: клиентом и сервером. Причем между двумя этими
процессами распределяются пять групп функций стандартного
интерактивного приложения:
1) функции диалога (Presentation Logic, PL) или компонент
визуализации. Компонент визуализации прикладной задачи
осуществляет ввод информации пользователем с помощью тех
или иных средств, а также вывод информации на экран и печать.
Компонент визуализации для архитектуры клиент-сервер всегда
исполняется на рабочем месте пользователя (поскольку должен
3
же он наблюдать какие-либо результаты работы программы). Для
организации
презентационной
логики
преимущественно
используется модель графического интерфейса пользователя
GUI (User Interface Graphical) или Web-интерфейс;
2) прикладные функции или это часть кода приложения с
алгоритмами обработки данных (Business Logic, BL). Компонент
прикладной логики решает собственно ту или иную задачу,
связанную с обработкой данных в той или иной предметной
области и представляет собой алгоритмы реакции приложения
на действия пользователя или на внутренние события, правила
обработки данных. Этот компонент может быть распределен
между клиентской и серверной частью различным образом в
зависимости от применяемой модели.
Обычно этот код
программируется на языках программирования высокого уровня:
C, C++, Visual Basic, Object Pascal и т.п.;
3) функции обработки данных внутри приложения (Database
Logic, DL) - это часть кода приложения, связанная с выборкой и
манипулированием данными (данными управляет собственно
СУБД). Подъязыком является язык SQL.
Типовая структура приложения «клиент-сервер»
4) функции управления информационными ресурсами
(Database Manager System, СУБД). Компонент хранения базы
данных осуществляет физические операции, связанные с
4
хранением данных, чтением информации из БД и записью в нее,
связанных с решаемой приложением прикладной задачей. В
архитектуре клиент-сервер этот компонент всегда выполняется
на сервере;
5) служебные функции, играющие роль связок между
предыдущими группами функций.
3 Модели рабочих нагрузок в архитектуре клиент/сервер
«Клиент-серверные» системы могут опираться на несколько
типов распределения обязанностей между клиентом и сервером:
 «интеллектуальные» клиенты (толстый клиент - тонкий
сервер);
 «интеллектуальный» сервер (тонкий клиент
- толстый
сервер);
 смешанные системы;
 многоуровневые системы.
Схему реализации выбирают на основе анализа требований:
 к сетевому трафику;
 к ресурсам клиента и сервера;
 к производительности базы данных.
5
«Интеллектуальные»
клиенты
один
из
самых
распространенных методов реализации «клиент-серверных»
приложений. «Интеллектуальному» клиенту можно доверить
выполнение
сервисов
представления,
бизнес-логики
и
управление данными. В этом случае функции сервера
ограничены поддержкой собственно базы данных (хранение
данных). Вся информация обрабатывается локально на клиенте,
что освобождает ресурсы сервера.
Достоинства «интеллектуальных» клиентов:
 простота архитектуры, что облегчает разработку и
сопровождение системы;
 наличие хорошо известных и достаточно мощных средств
разработки клиентских приложений;
Недостатки «интеллектуальных» клиентов:
 выполнение бизнес-правил на клиенте иногда увеличивает
сетевой трафик из-за необходимости передавать клиенту
все данные для принятия решения на основе правил;
 для модификации бизнес-логики необходимо повторное
развертывание всех клиентов.
«Интеллектуальные» серверы. Перенеся все бизнес-правила
на SQL Server, где они реализуются в виде хранимых процедур и
триггеров БД, создается «интеллектуальный» сервер», сервер
также отвечает за хранение и функционирование БД. Интеллект
сервера проявляется, также, в способности манипулировать
данными
(выполнять SQL-запросы) и возвращать клиенту
результирующий набор данных.
На
компьютере-клиенте
реализуется
только
логика
представления данных.
Достоинства:
 увеличение производительности работы ИС: бизнес-логика
выполняется в том же адресном пространстве, что и код
доступа к базе данных, и, кроме того, тесно интегрирован с
механизмом поиска данных. Это означает, что данные не
нужно перемещать или копировать перед обработкой, а
значит, сетевой трафик минимизируется;
 на сервере легче обеспечить целостность данных;
 при
необходимости
бизнес-логика
модифицируется
централизованно, без изменения клиентов.
Недостатки:
6
 повышение требований к ресурсам сервера, где
выполняются все запросы и манипуляции с данными.
Смешанные системы. Возможны и смешанные варианты,
обладающие достоинствами, как интеллектуальных серверов,
так и интеллектуальных клиентов. На сервере обычно
разворачивают СУБД, логику манипулирования данными, и ту
часть бизнес-логики, которая является общей для многих
клиентов. На клиенте разворачивают логику представления
данных и часть бизнес-логики, которая характерна именно для
этого клиента.
Достоинства смешанных систем:
 серверный код одновременно доступен многим клиентам,
что снижает накладные расходы при выполнении
однотипных запросов;
 эффективность работы клиентов меньше зависит от
сетевого трафика.
Недостатки:
 бизнес-логика распределена между клиентом и сервером и
при модернизации приложения требуется распространение
новых версий клиентской части среди широкой аудитории.
Многоуровневая
система
(ее
иногда
называют
трехуровневой)
позволяет
разделить
пользовательский
интерфейс, бизнес-правила и базу данных. В многоуровневой
системе бизнес-правила помещают на сервере приложений –
программный компонент, который размещают между сервером
БД и клиентами. Клиент отвечает только за интерфейс с
пользователем,
сервер
БД
–
за
поддержание
и
функционирование самой БД. Промежуточный слой является
для пользователя сервером, а для системы управления базами
данных - клиентом. Клиенты при необходимости обращаются к
серверу приложений, а тот в свою очередь обращается к серверу
БД за данными, необходимыми для реализации запросов
клиентов.
Достоинства многоуровневых систем:
 разделение компонентов интерфейса, бизнес-правил и
хранения данных, что повышает производительность
работы сервера БД и его защиту от несанкционированного
доступа;
 централизованная модификация бизнес-правил;
7
Недостатки:
 увеличивается сетевой трафик.
 подобные
системы намного сложнее в разработке,
внедрении и эксплуатации и требуют значительных затрат
и высококвалифицированного персонала.
4 Уровни и модели архитектуры «клиент-сервер»
С точки зрения количества составных частей клиентсерверные системы делятся на двухуровневые и трехуровневые.
Двухуровневые системы состоят только из клиента и сервера
К двухуровневым моделям архитектуры «клиент-сервер»
относятся:
1) модель файлового сервера (FS-модель);
2) модель удаленного доступа (RDA-модель);
3) модель активного сервера (DBS-модель).
Трехуровневая
модель
представлена разновидностью
архитектуры «клиент-сервер», основанной на схеме «клиент сервер приложений». Такая архитектура позволяет более гибко
распределять функции системы и нагрузку между компонентами
программно-аппаратного комплекса, а также может снизить
требования к ресурсам рабочих мест пользователей.
Архитектура «файл-сервер»
В архитектуре «файл-сервер» (File Server, FS-модель) все
основные функции приложения информационной системы
(презентационная логика, бизнес-логика и функции обработки и
управления данными) располагаются на клиенте (рис. 2).
На сервере находятся файлы с данными и поддерживается
доступ к файлам.
В этой модели клиент обращается к серверу с запросом к
данным. Запрос клиента формулируется в командах ЯМД. СУБД
переводит этот запрос в последовательность файловых команд,
Система управления файлами (СУФ) считывает запрашиваемые
данные из БД и поблочно передает эти данные клиентскому
приложению, далее на клиенте СУБД анализирует полученную
информацию, и если в полученном блоке не содержится ответ на
запрос, то принимается решение о перекачке следующего блока
информации и т. д. Фактически, FS-модель предполагает
автономную работу программного обеспечения ИС на разных
8
машинах в сети. Компоненты ИС взаимодействуют только за счет
наличия общего хранилища данных. Безусловно, таким
хранилищем должна быть хорошо спроектированная БД под
управлением СУБД, поддерживающей FS-модель, например,
СУБД Informix SE. Такого рода СУБД нельзя считать «истинным
сервером».
Модель архитектуры файлового сервера
При использовании FS-модели копия СУБД создается для
каждого инициированного пользователем сеанса работы с СУБД,
которая выполняется на том же процессоре, что и
пользовательский процесс.
В целом в архитектуре ИС «файл-сервер» мы имеем
«толстого» клиента и очень «тонкий» сервер в том смысле, что
почти вся работа выполняется на стороне клиента, а от сервера
требуется только достаточная емкость дисковой памяти.
К недостаткам архитектуры «файл-сервер» можно отнести:
 высокий сетевой трафик, который связан с передачей по сети
множества блоков и файлов, необходимых приложениям
клиентов;
 ограниченное множество команд манипулирования данными,
фактически это только файловые команды;
 низкая производительность (зависит от производительности
сети, сервера, клиента);
 плохая возможность подключения новых клиентов;
9
отсутствие развитых средств защиты данных (только на
уровне файловой системы).
К несомненным достоинствам следует отнести
 высокую эффективность работы с небольшими объемами
данных в однопользовательском режиме.
 удобство централизованного управления доступом;
 низкая стоимость разработки;
 высокая скорость разработки;
 невысокая стоимость обновления и изменения ПО.
FS-модель не отвечает современным представлениям о
технологии «клиент-сервер» в общепринятом смысле, поэтому,
этот
способ
организации
распределенных
вычислений
рассматривается как отдельная архитектура файлового сервера.
Модель удаленного доступа к данным, RDA (Remote Data
Access, RDA)
Исторически эта модель была разработана самой первой. В
этой модели серверная часть осуществляет только хранение
данных, здесь же размещается ядро СУБД и реализуется логика
манипулирования данными, а всю прикладную логику реализует
клиентская часть. При этом клиент будет передавать серверу
запросы на получение данных, а сервер возвращать клиенту те
или иные выборки. Самым распространенным средством
общения между клиентом и сервером в этом случае является
SQL (структурированный язык запросов) - стандартный
непроцедурный язык, ориентированный на обработку данных.
Клиент заметно «похудел» по сравнению с FS-моделью, зато
значительно расширились функции сервера, сократился сетевой
трафик, а самое главное достоинство модели RDA: появился
язык SQL с расширенным множеством команд определения
данных и манипулирования данными, который унифицировал
интерфейс клиент-сервер.

10
Модель архитектуры удаленного доступа к данным






Достоинства RDA-модели:
перенос Business Logic на клиента существенно разгружает
сервер БД, сводя к минимуму общее число процессов в
операционной системе;
сервер БД освобождается от несвойственных ему функций, а
значит процессор можно целиком загрузить операциями
обработки запросов, данных и транзакций;
резко уменьшается загрузка сети так как по ней от клиентов к
серверу передаются не запросы на ввод-вывод в файловой
терминологии, а запросы на SQL, и их объем существенно
меньше. В ответ на запросы клиент получает только данные,
релевантные запросу, а не блоки файлов, как в FS-модели.
Недостатки RDA-модели:
по-прежнему высокий сетевой трафик, особенно при большом
количестве клиентов
и их интенсивной работе в
интерактивном режиме;
излишнее дублирование кода приложения, например
повторение бизнес-логики для каждого клиента;
усложнение клиентских приложений в части контроля за
информационными ресурсами. Сервер играет пассивную роль.
Действительно, например, если нам необходимо выполнять
контроль страховых запасов товаров на складе, то каждое
приложение, которое связано с изменением состояния склада,
11
после
выполнения
операций
модификации
данных,
имитирующих продажу или удаление товара со склада, должно
выполнять проверку на объем остатка, и в случае, если он
меньше страхового запаса, формировать соответствующую
заявку на поставку требуемого товара. Это усложняет
клиентское приложение
Модель сервера БД (иногда называют активный сервер)
Модель сервера (Data Base Server, DBS) - концепция, в
соответствии с которой прикладной компонент (бизнес-логика)
частично или полностью располагается на сервере базы данных
(рис.4).
Бизнес-логика
реализована
в
виде
хранимых
программных единиц (ПрЕ), триггеров, пользовательских типов
данных, которые хранятся в БД, а управляются сервером. В базе
данных также накапливаются данные и формируется база
метаданных (БМД).
Клиентское приложение обращается к
серверу с командой запуска ПрЕ, а сервер при необходимости
выполняет её и фиксирует изменения в БД. Сервер возвращает
результат запроса клиенту либо для вывода на периферийное
устройство, либо для выполнения части бизнес-логики, которая
расположена на клиенте. При таком способе распределения
обработки данных сетевой трафик резко уменьшается.
Триггер - механизм отслеживания специальных событий,
которые связаны с состоянием БД. Триггер в БД является как
бы некоторым тумблером, который срабатывает при
возникновении определенного события в БД. Ядро СУБД
проводит мониторинг всех событий, которые вызывают
созданные и описанные триггеры в БД, и при возникновении
соответствующего
события
сервер
запускает
соответствующий триггер => триггер - это программа,
которая выполняется над БД и вызывает хранимые
процедуры.
Данная модель сервера является активной, потому что не
только клиент, но и сам сервер используют механизм триггеров.
Достоинства:
DBS-модель поддерживает большинство современных СУБД:
Oracle, Sybase, Ingres, Informix, MS SQL Server, хотя
функциональные возможности у них разные.
12
Модель активного сервера БД
Достоинства DBS-модели:
 возможность
централизованного
администрирования
прикладных функций;
 снижение сетевого трафика за счет возможностей удаленного
вызова процедур;
 возможность
разделения
процедур
несколькими
приложениями и экономия ресурсов компьютера за счет
использования единожды созданного плана выполнения SQLзапроса. (так как хранимые процедуры и триггеры хранятся в
словаре БД и могут быть использованы несколькими
клиентами => уменьшается дублирование алгоритмов
обработки данных в разных клиентских приложениях).
Недостатки:
 Очень большая загрузка сервера.
Функции сервера:
1.
Осуществляет мониторинг событий, связанных с
описанными триггерами;
2.
Обеспечивает автоматическое срабатывание триггеров
при возникновении связанных с ними событий;
3.
Обеспечивает исполнение внутренней программы
каждого триггера;
4.
Запускает
хранимые
процедуры
по
запросам
пользователей;
5.
Запускает хранимые процедуры из триггеров;
6.
Возвращает требуемые данные клиенту;
7.
Обеспечивает все функции СУБД: доступ к данным,
контроль и поддержка целостности данных в БД, контроль
13
доступа, обеспечение корректной работы всех пользователей с
единой БД.
Действительно, сервер выполняет большой набор функций и
обслуживает множество клиентов. Для разгрузки сервера были
разработаны
многоуровневые
модели
и,
в
частности
трехуровневая модель.
Сервер приложений
Сервер приложений (Application server, AS) - разновидность
многоуровневой архитектуры «клиент-сервер», основанный на
схеме «клиент - сервер приложений».
В данной модели вводится дополнительный промежуточный
уровень между клиентом и сервером. Этот промежуточный
уровень содержит один или несколько серверов приложений.
Отсюда и идентичное название - «модель сервера приложений»
AS (Application Server).
В этой модели все компоненты ИС делятся между тремя
исполнителями.
Клиент реализует интерфейс с пользователем, обеспечивает
презентационную логику приложения, запускает локализованный
на клиентской машине код клиентского приложения, который
выполняет коммуникационные функции доступа в локальную или
глобальную
сеть,
интерфейс
авторизации,
алгоритмы
шифрования, проверку вводимых значений на допустимость и
соответствие формату, несложные операции (сортировка,
группировка, подсчет значений) с данными, уже загруженными на
интерфейсный (обычно графический) компонент, то есть
собственно приложение для конечного пользователя. Клиент и
сервер приложений общаются посредством API, а сервер
приложений и сервер БД общаются посредством языка запросов
SQL.
Модель сервера приложений
14
Серверы приложений исполняют наиболее общие правила
бизнеса, поддерживают доменную среду, обеспечивают обмен
сообщениями между компонентами приложений. Прикладные
функции
сервера приложений оформлены как отдельные
службы или сервисы (Service). Служба предоставляет некоторые
услуги всем программам, которые желают и могут ими
воспользоваться. В архитектуре ИС серверов приложений может
быть несколько, и каждый из них предоставляет определенный
набор сервисов. Любая программа, которая пользуется ими,
рассматривается как клиент сервера приложений AC (Application
Client). Детали реализации прикладных функций в сервере
приложений полностью скрыты от клиента приложения. АС
обращается с запросом к конкретному сервису, а не к AS.
Запросы выстраиваются в очередь к AS-процессу, который
передает их для обработки конкретной службе согласно
установленным приоритетам.
Серверы БД в этой модели занимаются исключительно
функциями СУБД.
В простейшей конфигурации физически сервер приложений
может быть совмещен с сервером базы данных на одном
компьютере, к которому по сети подключается один или
несколько клиентов.
В "правильной" (с точки зрения безопасности, надежности,
масштабирования) конфигурации сервер базы данных находится
на выделенном компьютере (или кластере), к которому по сети
подключены один или несколько серверов приложений, к
которым, в свою очередь, по сети подключаются клиенты.
Достоинства AS-модели:
 повышение производительности за счет разгрузки сервера;
 удешевление эксплуатации ИС;
 возможность
усложнения бизнес-логики без потери
производительности;
 улучшение свойств переносимости и масштабируемости
ИС за счет использования стандартных языков
программирования, например С, С++, Borland Pascal, Small
Talk, Java, для реализации большей части бизнес-логики.
 клиентское ПО не нуждается в администрировании;
15
конфигурируемость – изолированность уровней друг от
друга позволяет быстро и простыми средствами
переконфигурировать систему при возникновении сбоев
или при плановом обслуживании на одном из уровней;
 высокая безопасность;
 высокая надежность;
 низкие
требования к скорости канала (сети) между
клиентами и сервером приложений;
 низкие требования к производительности и техническим
характеристикам клиентов, как следствие снижение их
стоимости.
Недостатки:
 растет сложность серверной части и, как следствие,
затраты на администрирование и обслуживание;
 более высокая сложность создания приложений;
 сложнее в разворачивании и администрировании;
 высокие
требования к производительности серверов
приложений и сервера базы данных, а, значит, и высокая
стоимость серверного оборудования;
 высокие требования к скорости канала (сети) между
сервером базы данных и серверами приложений.

Популярную сейчас архитектуру
представить в трехзвенном варианте.
Веб
Архитектура Веб-приложений
систем
можно