Клиент-сервер.

В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL (Structured Query Language

2. Система удаленной обработки или распределенное представление – предполагает мощный компьютер-сервер, а клиентская часть практически вырождена. Функцией клиентской части является просто отображение информации на экране. Модель данного типа имели СУБД ранних поколений, которые работали на малых, средних и больших ЭВМ, использовался я один компьютер с одним процессором.

Удаленный доступ к данным (Remote Data Access -- RDA) отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер.

В RDA-модели программы реализующие функции представления информации (коды компонента представления) и логику прикладной обработки(прикладная компонента), совмещены и выполняются на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовов функций специальной библиотекой API (Application Programming Interfase- интерфейса прикладного программирования). Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель обеспечивает полную децентрализацию управления бизнес-логикой. Однако в случае необходимости выполнения каких-либо изменений в клиентском приложении придется менять исходный код. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL.

В данных системах хранение, выборка и поддержание непротиворечивости данных возлагается на сервер БД, а вся бизнес-логика и логика представления исполняются на клиентских машинах. Так как все операции по манипулированию данными осуществляются только через сервер, производительность и сохранность данных зависит только от сервера БД. Серверы БД изначально рассчитаны на многопользовательский режим работы, имеют эффективные алгоритмы кеширования данных. Современные серверы имеют хорошую масштабируемость.

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

Процесс разработки разделяется на создание БД и написание клиентской части с бизнес-логикой.

Рис 1.4. Модель доступа к удаленным данным.Архитектура с выделенным сервером базы данных

Достоинства:

1. Большое обилие готовых СУБД, имеющих SQL-интерфейсы;

2. Унификация интерфейса "клиент-сервер" в виде языка SQL

3. Высокая производительность, стабильность и надежность при многопользовательской работе.

4. Легко организуется защита данных (шифрование сетевого трафика SSH, SSL)

5. Универсальность языка определения и манипулирования данными

6. Перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС.

7. Процессор сервера целиком загружается операциями обработки данных, запросов и транзакций.

8. Резко уменьшается загрузка сети, запросы на ввод-вывод и на SQL уменьшаются в объеме, т.е. в ответ на запросы клиент получает только данные, удовлетворяющие данному запросу.

9. Унификация интерфейса клиент-сервер.

10. Стандартным при обращении приложения клиента и сервера становится язык SQL.

11. Снижение нагрузки на машины сервера и клиентов;

12. Снижение сетевого трафика и повышение эффективности обработки за счет оптимизации и буферизации ввода-вывода;

13. Защита данных средствами СУБД, позволяющая блокировать не разрешенные пользователю действия;

14. Сервер реализует управление транзакциями и может блокировать попытки одновременного изменения одних и тех же записей

Недостатки

1. Более высокая цена СУБД. (сервер БД продается отдельно).

2. Достаточно высокие требования к квалификации разработчиков

3. Навыки администрирования сервера БД

4. Повышенные требования к пропускной способности сети

5. Повышенные требования к клиентским местам (на них выполняется высокая загрузка систем передачи данных;

6. Неудобны с точки зрения разработки, модификации и сопровождения.

7. Запросы на SQL при интерактивной работе клиента могут существенно загрузить сеть.

8. На клиенте располагаются PL и BL, и если при повторении аналогичных функций в различных приложениях (других клиентов) их код должен быть повторен для каждого клиентского приложения, следовательно, дублирование кода приложения.

9. Сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте => это усложняет клиентское приложение.

10. Бизнес-логика функциональной обработки и представление данных могут быть одинаковыми для нескольких клиентских приложений, что увеличивает потребности в ресурсах (повторение кода программ и запросов);Б

11. Бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми.

Выводы

При количестве пользователей от 2 до ~50 она является хорошим вариантом. С ростом числа пользователейначинает сказываться недостаточная пропускная способность сети.

Удаленное представление сервера БД ( Data Base Server- DBS) Модель сервера баз данных.

В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, то есть ядро СУБД.

Используется возможность современных серверов БД исполнять хранимые SQL процедуры на сервере, куда и переносится максимально возможная часть бизнес-логики. Требования к серверу БД возрастают, однако резко понижаются требования к клиентским машинам (за счет выноса с них бизнес-логики) и к пропускной способности сети (клиенту передаются только данные, необходимые пользователю). Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, поэтому клиент может довольствоваться довольно скромной аппаратной платформой, а сервер объединяет BL и AL. Максимальная загрузка сервера предусматривает выполнение бизнес-логики только с помощью хранимых процедур сервера (Хранимые процедуры – откомпилированные SQL-инструкции, хранящиеся на сервере). Это позволяет максимально централизовать контроль над данными и легко изменять правила работы сразу для целого предприятия. С другой стороны, незначительная корректировка правил, касающаяся только части пользователей, потребует длительной процедуры согласования. В этом случае невозможно реализовать какие-то исключения из общих правил для некоторых пользователей или приложений. В принципе, это хорошо и является залогом безопасности и целостности данных.

Рис.1.5. Модель сервера баз данных. Архитектура «активный сервер баз данных»

Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server.

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

В этой модели бизнес логика разделена между клиентом и сервером. На сервере бизнес логика реализована в виде хранимых процедур - специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедурой, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу.

Трафик обмена информацией между клиентом и сервером резко уменьшается.

Централизованный контроль в данной модели выполняется с использованием механизма триггеров, которые являются частью БД.

Триггер - механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер => триггер - это программа, которая выполняется над БД и вызывает хранимые процедуры.

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

Функции сервера:

1. Осуществляет мониторинг событий, связанных с описанными триггерами;

2. Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;

3. Обеспечивает исполнение внутренней программы каждого триггера;

4. Запускает хранимые процедуры по запросам пользователей;

5. Запускает хранимые процедуры из триггеров;

6. Возвращает требуемые данные клиенту;

7. Обеспечивает все функции СУБД: доступ к данным, контроль и поддержка целостности данных в БД, контроль доступа, обеспечение корректной работы всех пользователей с единой БД.

В архитектуре «активный сервер баз данных»непротиворечивость бизнес-логики контролируется на стороне сервера. Функции бизнес-логики разделяются между клиентской и серверной частями. Общие функции оформляются в видехранимых процедур. Вводится механизмтриггеров, отслеживающих события БД. При возникновении события (обычно изменения данных) выполняется оператор SQL или вызывается хранимая процедура, связанная с триггером.

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

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

Достоинства

1. Возможность централизованного администрирования приложений (прикладных функций);

2. Эффективное использование вычислительных и коммуникационных ресурсов.

3. Снижение трафика (вместо sql-запросов по сети направляются вызовы хранимых процедур),

4. Пониженные, по сравнению с предыдущим классом систем, требования к пропускной способности сети и клиентским местам.

5. Более простой процесс создания бизнес-логики.

6. Хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях

Недостатки

1. Ограничение средств разработки хранимых процедур - сильная привязка операторов хранимых процедур к конкретной СУБД

2. Ограниченность средств, используемых для написания хранимых процедур

3. Отсутствуют возможности отладки и тестирования разработанных хранимых процедур.

4. Повышенные требования к серверу БД.(каждый сеанс "съедает" память из расчета предельной загрузки)

5. Невысокая переносимость (мобильность) системы на другие серверы БД.

6. Очень большая загрузка сервера.

Выводы

По сравнению с предыдущими классами, позволяет держать большую нагрузку.

Современные многопользовательские СУБД опираются на RDA- и DBS-модели и при создании ИС используются смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции выполняются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая работает на компьютере-клиенте (RDA-модель).

Для разгрузки сервера была предложена 3-уровневая модель сервера:

Трехзвенная модель - AS-модель(Application Server) модель сервер-приложения. Каждая из трех функций приложения реализуется на отдельном компьютере. Процесс, выполняющийся на компьютере-клиенте(Application Client - AC), отвечает за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения. Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и называется сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов - базы данных, очереди, почтовые службы и др. Модель с физически выделенным в отдельное приложение блоком BL, таким образом получаем трехуровневую архитектуру “клиент-сервер”. На сервере БД может функционировать “универсальная” часть бизнес-логики (правила на уровне предприятия или группы связанных приложений). Такая схема позволяет поддерживать тонких клиентов на пользовательских компьютерах и в то же время разгрузить сервер БД от чрезмерной загрузки при сохранении гибкой системы работы с бизнес-правилами. В качестве промежуточного сервера может использоваться второй SQL-сервер, но чаще рациональней задействовать персональную СУБД, которая менее требовательна к аппаратным ресурсам и может обеспечить удобные средства построения и поддержки бизнес-логики.

RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.

Эта модель является расширением двухуровневой модели, т.е. вводится дополнительный промежуточный уровень между клиентом и сервером. В этой модели компоненты приложения делятся между тремя исполнителями:

1. Клиент - обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы.

2. Серверы приложений - составляют новый, промежуточный уровень архитектуры.

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

4. Серверы этой модели занимаются исключительно функциями СУБД, функции создания резервных копий БД и восстановления БД после сбоев, управление выполнением транзакций и поддержки устаревших (унаследованных) приложений.

Взаимодействие серверных и клиентских процессов в модели 1:1.

Рис.1.6. Модель сервера приложений. Трехзвенная архитектура сервера приложений

N-уровневая архитектура

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

Тонкий клиент представляет собой некоторый терминал типа HTML-browser или эмуляторы X-терминала

Вся бизнес- логика оформляется в виде набора приложений, запускаемых на сервере приложений под управлением ОС типа UNIX.

Сервера БД занимаются только проблемами хранения, добавления, модификации и поддержания непротиворечивости данных.

Сервер приложений соединен с сервером БД при помощи отдельного высокоскоростного сегмента сети.

Достоинства

1. Повышенная защищенность.

2. Высокая производительность.

3. Легкость развития и модификации.

4. Легкость администрирования.

5. Возможность создания системы с массовым параллелизмом (серверов БД может быть несколько, а сервером приложений могут служить несколько соединенных в кластер компьютеров).

6. Обладает большей гибкостью, чем двухуровневая модель.

Недостатки

1. Высокая сложность.

2. Высокая цена решения.

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

4. Для обслуживания большого числа клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов, а это резко повышает требование к ресурсам ЭВМ, на котором запускались все серверные процессы.

5. Каждый серверный процесс в этой модели запускается как независимый, поэтому если один клиент сформировал запрос, который был выполнен другим серверным процессом для другого клиента, то запрос, тем не менее, выполняется повторно.

6. В этой модели сложно обеспечить взаимодействие серверных процессов

Единственная альтернатива для создания ИС для очень большого количества пользователей.

Вышеперечисленные недостатки устраняются в модели (архитектуре) "систем с выделенным сервером", который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (tread), или потоком, по которому пересылаются запросы.

Такая архитектура получила название многопотоковой односерверной.

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

Связь клиентских рабочих станций с прикладными программами на сервере приложений устанавливается через интерфейс API (Application Programming Interface). Работа клиентской части сводится к вызову функций сервера приложений. Прикладные программы обращаются к серверу БД с помощью SQL-запросов.

Достоинства:

• уменьшается нагрузка на ОС, возникающая при работе большого числа пользователей.

• многократное использование общих функций обработки данных в множестве клиентских приложений;

• централизованное ведение бизнес-логики (при внесении изменений их не нужно тиражировать в клиентских приложениях);

• на клиентских машинах не следует устанавливать компоненту программного обеспечения управления доступом к данным;

• оптимизация доступа к БД (диспетчеризация запросов выполняется сервером приложений);

• возможность отложенного обновления БД при изменении данных в автономном режиме (данные будут обновлены в БД при следующем соединении);

• повышение скорости и надежности за счет дублирования ПО на нескольких серверах приложений, которые могут заменять друг друга;

• перенос проверки полномочий пользователей с сервера БД на сервер приложений.

• уменьшение мощности сервера приложений за счет параллельной работы сервера приложений и сервера Базы данных