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

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

как выполняется в каждой из систем SQL-запрос, который мы приводили в качестве примера, в разделе шенном индексам;

SELECT L-oloiiibrs WHERE CijstorfierID = JONSCON

В первом случае ватели работают с базой данных по сети) механизм баз данных Microsoft Jet прочитает индекс (разумеется, если он существует), определит запись, удовлетворяющую критерию запроса, и найдет эту запись в базе данных. Во втором случае (клиент-серверная система) с клиентской рабочей станиии запрос будет отправлен на SQL Server, после чего сервер вернет обратно на клиентский компьютер результат его выполнения - соответствующую запись, (Безусловно, это упрощенная модель, в действительности все гораздо сложнее.)

Когда речь идет о выполнении таких простых запросов, различие

в производительности между базой данных, использующей сетевой

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

систем с одноуровневой архитектурой.

Использование клиент-серверной системы позволяет существенно улучшить время отклика по сравнению с одноуровневой архитектурой за счет того, что вычисление аделн ются между клиентской рабочей станцией и сервером. В то время как сервер обрабатывает запрос, поступивший от клиента, на рабочей станции могут выполняться другие операции, например обрабатываться дополнительные запросы пользователей. И наоборот, пока рабочая станция выдает пользователю ответ на какие-либо его действия (или просто ожидает ввода данных), сервер баз данных может другие запросы. SQL Server - несравненно более сложная и ресурсоемкая система, но он способен обеспечить значительно меньшее время отклика, чем Microsoft Jet. А значит, может обслуживать гораздо больше пользователей, чем база данных с сетевым доступом к данным.

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

пользователи работают по сети, имеет смысл хранить запросы на ло-

ЧАСТЬ еляциокных систем баз данных

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

Если доступ к данным на SQL Server осуществляется при помощи Access, следует проявлять осторожность при использовании SQL-зан-росов, которые успешно работали на локальном компьютере. Например, оператор ЕСТ, который содержит пользовательскую функцию, будет выполняться на локальном компьютере в Access, а не на SQL Server, поскольку SQL Server не поддерживает пользовательские функции в операторах SELECT. (Их не поддерживает и Microsoft Jet; вот почему запрос, который содержит пользовательскую функцию, невозможно выполнить из Visual Basic, даже если он сохранен в файле

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

Многоуровневая архитектура

В хорошо спроектированной двухуровневой системе можно добиться

существенного увеличения производительности и снижения времени отклика но сравнению с одноуровневой. Такой эффект достигается

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

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

К сожалению, с увеличением числа уровней в системе сложность реализации возрастает экспоненциально. При переходе от двухуровневой архитектуры к трех- и четырехуровневой .ощес!венно усложняются доступ к данным, защита данных, управление Во многих случаях эти процессы настолько сложными и ресурсоемкими, что требуют выделения дополнительных серверов (например, Microsoft Transaction Server). Возможно, именно поэтому их

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

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

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

Интернет и интранет-архитектура

База данных в Интернет- или интранет-среде - особая разновидность многоуровневой архитектуры. Здесь применяются свои технологии - для передачи данных используется протокол HTTP, а пользователи работают с системой не с помощью Access, а посредством Internet Explorer или другого браузера. Но концептуально архитектуры этих систем очень похожи на обычные многоуровневые системы.

Наиболее существенное различие между системой баз данны.х, создаваемой для работы в Интернете, и системой для локальных сетей - для Интернет-среды отсутствует понятие состояния (state). В обычной клиент-серверной среде приложение запрашивает имя пользователя и пароль при запуске и затем использует эти данные при подключении к SQL Server. После того как соединение с сервером установлено, а имя пользователя и пароль успешно прошли проверку, сервер поддерживает соединение на протяжении всей сессии, Пока поддерживается соединение, сервер хранит информацию о пользователе, и если пользователь отправляет серверу запрос, то сервер отвечает на него. Эта информация о пользователе, поддерживаемая сервером баз данных на протяжении сессии, и называется состоянием,

Если же система проектируется для работы в Интернете, сервер баз данных не может постоянно поддерживать данные о состоянии.

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

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

Для большинства приложений, разрабатываемых для Интернета,

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

как правило, на нем размещается лишь пользовательский интерфейс.

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