Архитектуры распределенной обработки данных. Достоинства и недостатки.

Почти все модели организации взаимодействия пользователя с базой данных построены на основе модели «клиент-сервер». То есть предполагается, что каждое такое приложение отличается способом распределения функций ранее приведенных групп обработки данных между, как минимум, двумя частями:• Клиентской, которая отвечает за целевую обработку данных и организацию взаимодействия с пользователем;• Серверной, которая обеспечивает хранение данных, обрабатывает запросы и посылает результаты клиенту для специальной обработки.Сервер – это программа, реализующая функции собственно СУБД: определение данных, запись – чтение данных, поддержка схем внешнего, концептуального и внутреннего уровней, диспетчеризация и оптимизация выполнения запросов, защита данных.Клиент – это различные программы, написанные как пользователями, так и поставщиками СУБД, внешние или «встроенные» по отношению к СУБД. Программа-клиент организована в виде приложения, работающего «поверх» СУБД, и обращающегося для выполнения операций над данными и компонентами СУБД через интерфейс внешнего уровня.Архитектура «файл-сервер».Организация и управление базой данных (в т.ч. и СУБД) целиком располагается на машине клиента, а база данных, представляющая собой обычно набор специализированных структурированных файлов, на машине-сервере. В этом случае серверная компонента представлена даже не средствами СУБД, а сетевыми составляющими операционной системы, обеспечивающими удаленный разделяемый доступ к файлам.Взаимодействие между клиентом и сервером происходит на уровне команд ввода-вывода файловой системы, которая возвращает запись или блок данных.Достоинство – возможность обслуживания запросов нескольких клиентов.Недостатки:• высокая загрузка сети и машин-клиентов, т.к. обмен идет на уровне единиц информации файловой системы – физических записей, блоков или даже файлов, из которых на машине клиента будут выбраны и представлены необходимые для приложения элементы данных;• низкий уровень защиты данных, так как доступ к файлам БД управляется общими средствами ОС-сервера;• низкий уровень управления целостностью и непротиворечивостью информации, так как бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми и несинхронизированными.Архитектура «выделенный сервер базы данных»Средства управления базой данных и база данных размещены на машине-сервере.Взаимодействие между клиентом и сервером происходит на уровне команд языка манипулирования данными СУБД (обычно SQL), которые обрабатываются СУБД на машине-сервере.Достоинства:• возможность обслуживания запросов нескольких клиентов;• снижение нагрузки на сеть и машины сервера и клиентов;• защита данных осуществляется средствами СУБД, что позволяет блокировать не разрешенные пользователю действия;• сервер реализует управление транзакциями и может блокировать попытки одновременного изменения одних и тех же записей.Недостатки:• Бизнес-логика функциональной обработки и представление данных могут быть одинаковыми для нескольких клиентских приложений, и это увеличит совокупные потребности в ресурсах при исполнении вследствие повторения части кода программ и запросов;• Низкий уровень управления непротиворечивостью информации, так как бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми.Архитектура «активный сервер баз данных»Для того, чтобы устранить недостатки, свойственные архитектуре сервера базы данных, необходимо, чтобы непротиворечивость бизнес-логики и изменения базы данных контролировались на стороне сервера.Для этой функции бизнес-логики разделяются между клиентской и серверной частями. Общие или критически значимые функции оформляются в виде хранимых процедур, включаемых в состав базы данных. Кроме этого вводится механизм отслеживания событий БД – триггеров, также включаемых в состав базы. При возникновении соответствующего события (обычно изменения данных), СУБД вызывает для выполнения хранимую процедуру, связанную с триггером, что позволяет эффектно контролировать изменение базы данных.Хранимые процедуры и триггеры могут быть использованы любыми клиентскими приложениями, работающими с базой данных. Это снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса.Недостатком такой архитектуры становится существенно возрастающая загрузка сервера за счет необходимости отслеживания событий и выполнения части бизнес-правил.Архитектура «сервер приложений»Рассмотренные выше архитектуры являются двухзвенными: здесь все функции доступа и обработки распределены между программой клиента и сервером БД.Дальнейшее снижение требований к ресурсам клиента достигается за счет введения промежуточного звена – сервера приложений, на который переносится значительная часть программных компонентов управления данными и большая часть бизнес-логики. При этом серверы баз данных обеспечивают исключительно функции СУБД по ведению и обслуживанию базы данных.К другим (организационно-технологическим) достоинством трехзвенной архитектуры можно отнести:• централизованное введение бизнес-логики, и в случае внесения изменения отсутствие необходимости их тиражирования в клиентских приложениях;• отсутствие необходимости устанавливать на клиентских машинах компоненту программного обеспечения управления доступа к данным:• возможность отложенного обновления БД в случае изменения данных, запрошенных с сервера, в автономном режиме. Данные будут обновлены в базе после следующего соединения клиентской программы с сервером приложений.