1.4 Анализ и выбор средств решения поставленной задачи
Архитектура разрабатываемого комплекса подразумевает наличие в ней централизованного хранилища данных о тестовых наборах (тестах), пользователях, группах пользователей и результатах тестирования знаний пользователей. Эти хранилищем данных будет реляционная база данных, находящаяся под управлением систему управления базой данных (СУБД) Microsoft SQL Server 2005. Данные в базу помещаются и считываться модулями, которые будут разработаны в ходе выполнения дипломного проекта.
Наиболее популярными моделями доступа к данным являются клиент-серверная и многозвенная архитектуры доступа к базам данных. Рассмотрим каждую из этих архитектур.
Архитектура «клиент-сервер»
Было бы неверно думать, что локальные приложения БД работают только на одном компьютере и в этом состоит их главная особенность. На самом деле такая программа вполне может функционировать в локальной сети и обслуживать нескольких клиентов одновременно.
Основное же отличие между локальными и клиент/серверными приложениями заключается в четком разграничении функций приложения и их распределении по различным компьютерам. При этом говорят о серверной и клиентской частях приложения. На сервер ложится обязанность по управлению базой данных и обслуживанию многочисленных клиентских запросов, а клиент обслуживает отдельного пользователя и "умеет" связываться с сервером, отправлять запросы и получать результаты.
Таким образом, архитектура клиент/сервер обеспечивает одновременное обслуживание множества пользователей. Естественно, что применяются они на больших промышленных предприятиях, в крупных компаниях и корпорациях и т. д.
Архитектура клиент/сервер предъявляет очень высокие требования к серверной части, которая строится на основе специальных программных комплексов, которые так и называются серверами БД или серверами SQL, так как при работе с ними используется специальный язык запросов к базам данных SQL (Structured Query Language).
В настоящее время распространена классификация приложений баз данных в соответствии с уровнями обработки данных. В соответствии с ней простые однопользовательские программы, работающие с маломощными локальными СУБД, являются одноуровневыми. В таких приложениях вся обработка данных ведется самой программой, а СУБД лишь обеспечивает доступ к таблицам.
Двухуровневые приложения соответствуют архитектуре клиент/сервер и организуют обработку как на стороне сервера БД, так и на стороне клиентского приложения. В зависимости от распределения функций обработки данных, различают системы клиент/сервер с "тонким" или "толстым" клиентом.
Важнейшей частью приложений в архитектуре клиент/сервер является сервер. Сервер базы данных представляет собой мощную систему управления базой данных, основанную на использовании SQL. Бизнес по разработке и эксплуатации промышленных серверов БД ежегодно имеет оборот в десятки миллиардов долларов. Подавляющее большинство крупных и средних компаний имеют собственные корпоративные базы данных, с которыми работают многоуровневые приложения на самых разных платформах. Серверы Oracle, Informix, Sybase управляют базами данных объемом десятки и сотни гигабайт. Для управления меньшими корпоративными базами данных применяются программные продукты MS SQL Server и InterBase.
Сервер как часть приложения, предназначенная для обеспечения работы клиентов с БД в целом, решает три основных задачи.
Администрирование базы данных
Контроль доступа к данным и разграничение доступа
Управление и манипулирование потоками данных
Связь между клиентскими приложениями и сервером осуществляется на двух уровнях. Во-первых, должна существовать связь между операционными системами компьютеров клиентов и сервера. Это вопрос создания и администрирования компьютерных сетей. Во-вторых, части многоуровневого приложения должны уметь взаимодействовать между собой. Сервер имеет встроенные программные средства, обеспечивающие взаимодействие с клиентами на уровне данных. На клиентской стороне устанавливается специальное ПО клиента.
При формировании запросов в многоуровневых приложениях используется язык SQL. Каждый тип сервера работает на собственном диалекте языка, который в большей или меньшей степени соответствует стандарту ANSI 92. Сервер InterBase имеют немного дополнений. А диалекты серверов Sybase и MS SQL отличаются от стандарта довольно сильно.
Организация обработки данных в приложениях клиент/сервер имеет ряд. особенностей. Поля таблиц базы данных сервера создаются с использованием не стандартных типов данных, а доменов — создаваемых пользователем типов данных с дополнительными ограничениями.
Все операции с данными должны выполняться сервером по заявке клиента. Для этого используются хранимые процедуры — наиболее распространенные запросы, которые хранятся на сервере и выполняются по требованию клиентов. Хранимые процедуры оптимизированы для выполнения на сервере.
Некоторые хранимые процедуры должны выполняться автоматически при возникновении той или иной ситуации. В частности, они используются для поддержания ссылочной целостности данных. Такие запросы называются триггерами.
Объединяя данные из различных таблиц, можно создавать совокупности столбцов из разных таблиц, которые называются просмотрами. Структуру просмотра можно сохранить и использовать в дальнейшем.
Выполнение наборов операций выполняется сервером при помощи механизма транзакций. Транзакция — это группа операторов SQL, все команды которой должны быть успешно выполнены. В этом случае изменения фиксируются на сервере. В противном случае все команды отменяются. Транзакции обеспечивают сохранение целостности данных при работе с сервером многих клиентов одновременно.
Так как с базой данных сервера одновременно работает множество клиентов, поэтому весьма высока вероятность возникновения конфликтов при попытках модификации одних и тех же данных. Чтобы обеспечить целостность данных, серверы вынуждены осуществлять блокировку данных не отдельными записями, как в локальных СУБД, а страницами или даже таблицами. Размер страниц зависит от типа сервера. Табличная блокировка применяется при выполнении запросов модификации данных к целым таблицам (без использования оператора where).
Клиентская часть приложения может создаваться как при помощи специализированных программных сред, поставляемых совместно с сервером, так и при помощи обычных средств разработки программ. Delphi позволяет создавать клиентские приложения на любой вкус и любой степени сложности.
В целом, клиентские приложения обеспечивают выполнение следующих стандартных функций:
обеспечение сеанса связи с сервером, при этом одно приложение может одновременно поддерживать несколько соединений;
формирование запросов и передача их серверу;
получение результатов выполнения запросов и их отображение при помощи стандартных интерфейсных элементов;
обеспечение редактирования, дополнительной обработки, преобразования данных и т. д.
Многозвенная архитектура баз данных
Многозвенная архитектура приложений баз данных вызвана к жизни необходимостью обрабатывать на стороне сервера запросы от большого числа удаленных клиентов. Казалось бы, с этой задачей вполне могут справиться и приложения «клиент-сервер», однако в этом случае при большом числе клиентов вся вычислительная нагрузка ложится на сервер БД, который обладает довольно скудным набором средств для реализации сложной бизнес-логики (хранимые процедуры, триггеры, просмотры и т. д.). И разработчики вынуждены существенно усложнять программный код клиентского ПО, а это крайне нежелательно при наличии большого Числа удаленных клиентских компьютеров. Ведь с усложнением клиентского ПО возрастает вероятность ошибок и усложняется его обслуживание.
Многозвенная архитектура приложений БД призвана исправить перечисленные недостатки.
Итак, в рамках этой архитектуры "тонкие" клиенты представляют собой простейшие приложения, обеспечивающие лишь передачу данных, их локальное кэширование, представление средствами пользовательского интерфейса, редактирование и простейшую обработку.
Клиентские приложения обращаются не к серверу БД напрямую, а к специализированному ПО промежуточного слоя. Это может быть и одно звено (простейшая трехзвенная модель) и более сложная структура.
ПО промежуточного слоя называется сервером приложений, принимает запросы клиентов, обрабатывает их в соответствии с запрограммированными правилами бизнес-логики, при необходимости преобразует в форму, удобную для сервера БД и отправляет серверу. Сервер БД выполняет полученные запросы и отправляет результаты серверу приложений, который адресует данные клиентам.
Рисунок 1.7 – Многозвенная архитектура приложений БД
Таким образом, многозвенное приложение БД состоит из:
"тонких" клиентских приложений, обеспечивающих лишь передачу, представление, редактирование и простейшую обработку данных;
одного или нескольких звеньев ПО промежуточного слоя (сервер приложений), которые могут функционировать как на одном компьютере, так и распределенно — в локальной сети;
сервера БД (Oralce, Sybase, MS SQL, InterBase и т. д.), поддерживающего функционирование базы данных и обрабатывающего запросы.
Более простая трехзвенная модель содержит следующие элементы:
Клиентское приложение обеспечивает интерфейс пользователя на пользовательской машине.
Сервер приложений находится в доступном для всех клиентов месте и обеспечивает общую передачу данных. Управление передачей данных обеспечивает так называемый брокер данных.
Удаленный сервер базы данных обеспечивает систему управления базой данных (удаленная СУБД).
Взаимодействие этих уровней осуществляется следующим образом. Пользователь запускает клиентское приложение. Клиент соединяется с сервером приложений (который может определяться как во время исполнения, так и во время создания приложения). Запускается сервер приложений. Клиент получает интерфейс IAppServer от сервера приложений.
Затем клиент запрашивает данные от сервера приложений. В свою очередь сервер приложений запрашивает данные (устанавливая, если необходимо, соединение) в базе данных, упаковывает их для клиента, и возвращает пакет данных клиенту. Клиент расшифровывает пакеты данных и предоставляет их пользователю. Пользователь взаимодействует с клиентским приложением, и данные изменяются. Клиент упаковывает измененные данные в пакеты и отсылает их на сервер приложений.
Сервер приложений расшифровывает пакеты и сохраняет изменения в контексте транзакции. Если запись не может быть сохранена на сервере, сервер пытается согласовать изменения с текущими данными и отделяет данные, которые не могут быть сохранены. Когда процесс обработки измененных данных закончен, сервер возвращает все несохраненные данные клиенту для дальнейшего уточнения.
Клиент уточняет необработанные данные, после чего посылает их снова серверу приложений. Затем клиент обновляет свои данные с сервером.
Обе описанных архитектуры обладают как преимуществами, так и недостатками. Так «клиент серверные» приложения относительно просты в разработке и тестировании, но имеют плохую масштабируемость. Многозвенные приложении хорошо масштабируются, клиенты многозвенной архитектура платформонезависимы от используемой СУБД. Платой за эти преимущества многозвенной архитектуры является сложность разработки и тестирования такой системы.
Разрабатываемый программный комплекс будем строить, основываясь на клиент-серверной архитектуре приложений бах данных в силу легкости разработки и тестирования таких приложений.