- •Содержание.
- •2.1. Область применения субд.
- •2.2. Ручные картотеки – файловые системы – современные субд.
- •2.3. Сравнение локальных субд с субд архитектуры клиент-сервер.
- •2.4. Архитектура клиент-сервер.
- •2.4.1. Клиент.
- •2.4.2. Сервер.
- •2.4.3. Бизнес-правила.
- •2.4.4. Модели архитектуры клиент-сервер.
- •2.5. Знакомство с субд Borland InterBase.
- •2.5.1. История создания и некоторые технические характеристики.
- •2.5.2. Основные компоненты.
- •2.5.3. Физическая организация базы данных.
2.4. Архитектура клиент-сервер.
Типичная архитектура клиент/сервер предусматривает наличие конечного пользователя (клиента), который имеет доступ и возможность обрабатывать данные, сохраняемые на удаленном компьютере — сервере. Не существует никакого стандартного определения того, что такое клиент и чем занимается сервер. Однако можно с уверенностью полагать, что сервер предоставляет некоторый сервис, а клиент запрашивает его у сервера. К одному и тому же серверу может обращаться множество клиентов с требованием предоставить им какой-либо сервис, и именно сервер решает, как обработать подобные запросы. Кроме того, в системе клиент/сервер может существовать и третий элемент. Об этом речь пойдет далее при рассмотрении трехуровневых систем.
В среде клиент/сервер последний играет намного большую роль, чем роль простого распределителя данных. Фактически именно сервер выполняет основную часть работы системы. Он управляет тем, как клиент будет получать доступ и обрабатывать данные. Реально клиентские приложения являются лишь средством представления данных пользователю и получения их от него. Далее в этой главе обязанности клиента и сервера рассматриваются подробнее. Кроме того, речь пойдет о бизнес-правилах, которые определяют способ доступа клиента к данным сервера.
2.4.1. Клиент.
Клиенты представляют собой приложения, обеспечивающие графический или иной интерфейс с пользователем. Delphi 5 позволяет разрабатывать как чисто клиентские приложения, так и серверы среднего уровня в трехуровневых моделях. Приложения-серверы баз данных предпочтительнее разрабатывать с использованием мощных распределенных СУБД, подобных Oracle или InterBase.
Клиентские приложения предоставляют пользователю интерфейс для управления данными на сервере. Именно через клиентское приложение пользователь получает доступ к функциональным возможностям сервера. Примером запрашиваемых действий может быть добавление заказчика, счета или печать отчета. В этом случае клиент просто посылает запрос и предоставляет необходимые для его выполнения данные. Сервер же несет ответственность за обработку запроса. Это не означает, что клиент не может выполнять каких-либо логических действий самостоятельно. Вполне возможно, что клиент реализует большую часть (если не всю) поддержки бизнес-логики приложения. Такое приложение называется толстым клиентом (fat client).
2.4.2. Сервер.
Сервер предоставляет сервис клиенту. Он, по существу, ждет, пока клиент сделает запрос, а затем обрабатывает этот запрос. Сервер должен обладать способностью обрабатывать одновременно несколько запросов от нескольких клиентов, а также уметь распределять эти запросы по приоритетам. Чаще всего серверная программа работает постоянно, обеспечивая не прекращающийся доступ к ее услугам.
2.4.3. Бизнес-правила.
Бизнес-правила — это процедуры управления, которые определяют, как клиент должен получать доступ к данным на сервере. Эти правила реализуются программным текстом клиента, сервера или ими обоими. Например, в Delphi бизнес-правила реализуются в программах на языке Object Pascal. На стороне сервера бизнес-правила реализуются в виде хранимых процедур SQL, триггеров и других объектов, присущих серверным базам данных. В трехуровневой модели бизнес-правила могут быть реализованы на среднем уровне. Важно понимать, что бизнес-правила определяют поведение всей системы. При их отсутствии у вас есть просто данные на одном компьютере и приложение с графическим интерфейсом на другом, однако нет метода их соединения.
На определенном этапе разработки вашей системы необходимо решить, какие процессы должны будут в ней существовать. Например, рассмотрим систему складского учета. Ей свойственны следующие типичные процессы: прием заказа, печать накладной, добавление заказчика и т.п. Как указывалось выше, все правила выполнения этих операций реализуются в коде Object Pascal на стороне клиента или на среднем уровне. Эти бизнес-правила также могут располагаться в виде SQL-кода на сервере или представлять собой комбинацию всех трех вариантов. Если большая часть правил реализована на сервере, то его называют "толстым сервером". Если правила реализуются в основном на стороне клиента, он называется "толстым клиентом". Если правила реализованы на среднем уровне, то сервер также называют "толстым". То, на какой именно стороне реализуются бизнес-правила приложения, определяется объемом и типом требуемых операций управления данными.
В литературе наряду с термином трехуровневая система иногда встречаются термины n-уровневая или многоуровневая (multitier) система, которые порой употребляются некорректно. В трехуровневой модели обычно существует один или более клиентов, бизнес-логика и сервер базы данных. Поддержка бизнес-логики может быть разделена на несколько частей, выполняемых на различных компьютерах или даже на нескольких серверах приложений. Не кажется ли вам абсурдом упоминание 10-, 15- или даже 25-уровневых систем? Мы предпочитаем рассматривать всю поддержку бизнес-логики как один средний уровень, независимо от количества подпрограмм и серверных приложений, потребовавшихся для ее реализации.