Технология клиент—сервер.

Клиент—сервер — это модель взаимодействия компьютеров в сети.

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

В сети один и тот же компьютер может выполнять и роль клиента, и роль сервера. Например, в АИС, включающей персональные компьютеры, большую ЭВМ и мини-компьютер под управлением UNIX, последний может выступать как в качестве сервера БД, обслуживая запросы от клиентов — персональных компьютеров, так и в качестве клиента, направляя запросы большой ЭВМ [1, 3, 14, 23].

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

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

Однако при этом частые обращения клиента к серверу снижают производительность работы сети, кроме того, приходится решать вопросы информационной безопасности, так как приложения и данные распределены между различными клиентами. Распределенный характер построения системы обусловливает сложность ее настройки и сопровождения. Чем сложнее структура сети с архитектурой клиент—сервер, тем выше вероятность отказа любого из ее компонентов (рис. 4.9) [23].

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

РИСУНОК

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

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

Основной принцип технологии клиент—сервер заключается в разделении функций стандартного интерактивного приложения на четыре группы различной природы. Первая группа — это функции ввода и отображения данных.Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы — открытие счета, перевод денег с одного счета на другой и т. д.). К третьей группе относятся фундаментальные функции хранения и управления ин­формационными ресурсами (БД, файловыми системами и т. д.), Наконец, функции четвертой группы — это служебные функции(играют роль связок между функциями первых трех групп).

В любом приложении выделяются следующие логические компоненты:

• компонент представления, реализующий функции первой
группы;

• прикладной компонент, поддерживающий функции второй
группы;

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

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

Выделяются четыре подхода, реализованные в моделях:

• модель файлового сервера (File Server — FS);

• модель доступа к удаленным данным (Remote Data Access -
RDA);

• модель севера базы данных (DataBase Server — DBS);

• модель сервера приложений (Application Server — AS).

FS-модель является базовой для локальных сетей персональ­ных компьютеров. Не так давно она была очень популярна среди отечественных разработчиков в средах FoxPRO, Clipper, Clarion, Paradox и т. д. Суть модели невероятно проста: один из компью­теров в сети считается файловым сервером и предоставляет услу­ги по обработке файлов другим компьютерам. Файловый сервер работает под управлением сетевой операционной системы (на­пример, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (т. е. к файлам). На других компью­терах

I щены компонент представления и прикладной компонент |(рис. 4.11). Протокол обмена представляет собой набор низко­уровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере

РИСУНОК

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

К технологическим недостаткам модели относят интенсив­ный сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипуляции с данными («данные — это файлы»), отсутствие адекватных средств безо­пасности доступа к данным (защита только на уровне файловой системы) и т. д. Собственно, перечисленное не есть недостатки, но — следствие внутренне присущих FS-модели ограничений, определяемых ее характером. Недоразумения возникают, когда FS-модель используют не по назначению, например, пытаются интерпретировать как модель сервера БД. Место FS-модели в иерархии моделей клиент—сервер — это всего лишь место моде­ли файлового сервера. Именно поэтому невозможно создание на основе FS-модели крупных корпоративных систем, что нередко делалось в прошлом и предпринимается сейчас.

RDA-модель (более технологичная) существенно отличается от FS-модели характером компонента доступа к информацион­ным

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

Клиент направляет запросы к информационным ресурсам (например, к БД) по сети удаленному компьютеру. На нем функционирует ядро СУБД, которое обрабатывает запросы и возвращает клиенту результат, оформленный как блок данных (рис. 4.12).

Сервер баз данных

SQL запрос

Компонент представления

Данные

Рис. 4.12. Модель доступа к удаленным данным

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

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

Основное достоинство RDA-модели — унификация интер­фейса клиент—сервер в виде языка SQL. Действительно, взаимо действие прикладного компонента с ядром СУБД невозможно без стандартизованного средства общения, таким средством и

является язык SQL

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

прикладные).

DBS-модель реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle); в настоящее время приобретает все большую популярность. Ее основу составляет механизм хра­нимых процедур — средство программирования SQL-сервера. Про­цедуры хранятся в словаре БД, разделяются между несколькими клиентами и выполняются на том же компьютере, где функцио­нирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

В DBS-модели (рис. 4.13) компонент представления выпол­няется на компьютере-клиенте, в то время как прикладной ком­понент оформлен как набор хранимых процедур и функциони­рует на компьютере-сервере БД.

Рис. 4.13. Модель сервера базы данных Там же выполняется компонент доступа к данным, т. е. ядро СУБД. Среди достоинств DBS-модели следует отметить: воз­можность централизованного администрирования прикладных функций и снижение трафика (вместо SQL-запросов по сети на­правляются вызовы хранимых процедур); возможность разделе­ния процедуры между несколькими приложениями; экономию ресурсов компьютера за счет использования единожды создан­ного плана выполнения процедуры. К недостаткам модели отно­сят

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

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

В AS-модели (рис. 4.14) процесс, выполняющийся на компь­ютере-клиенте, отвечает, как обычно, за интерфейс с пользова­телем (т. е. осуществляет функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения {Application Client — AC). При­кладной компонент реализован как группа процессов, выпол­няющих прикладные функции, и называется сервером приложе­ния {Application Server — AS). Все операции над информационны­ми ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов — БД, очере­ди, почтовые службы и др.

Рис. 4.14. Модель сервера приложений

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

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

Триггеры

Триггер- это специальный тип хранимой процедуры, которая автоматически вызывается в случае, когда данные в определенной таблице добавляются, удаляются или изменяются с помощью SQL-предложений INSERT, DELETE или UPDATE.

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

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

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

При установлении флажка «Каскадное обновление (изменение) связанных полей» предполагает при изменении ключевого поля главной таблицы автоматически изменяются и соответствующие значения связанных записей в подчиненной таблице.

При установлении флажка «Каскадное удаление связанных записей» предполагает, что при удалении записи в главной таблице удаляются и все связанные с ней записи в подчиненной таблице.

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

Триггеры создаются с помощью предложения CREATE TRIGGER,

ALTER TRIGGER применяется для изменения текста имеющегося триггера

Предложение DROP TRIGGER удаляет триггер из базы данных.

Хранимые процедуры

Хранимые процедуры-это часто используемые клиентом SQL-запросы, оформленные специальным образом и хранимые в базе данных вместе с таблицами, индексами, триггерами и другими компонентами.

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

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

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

Хранимые процедуры позволяют повысить производительность приложений.

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

Хранимые процедуры создаются с помощью SQL-предложения CREATE PROCEDURE,

ALTER PROCEDURE применяется для изменения уже существующей хранимой процедуры

Предложение DROP PROCEDURE удаляет хранимые процедуры из базы данных.

Индексы

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

n «Значение поля» и

n «Физическое расположение этого поля (или адрес)»

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

Как найти нужную информацию в книге – перелистывая книгу страница за страницей, или находя номер нужной страницы в предметном указателе?. Использование предметного указателя оказывается более эффективным. Если книга большая, то можно сэкономить немало времени.

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

Созданный для таблицы индекс сохраняется отдельно от этой таблицы.

Главным назначением индекса является повышение скорости извлечения данных.

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

Основная функция индексов – обеспечивать быстрый поиск записи в таблице.

Простой индекс – это индекс, создаваемый по данным одного столбца таблицы.

5/12/2011

Синтаксис оператора:

CREATE INDEX имя индекса ON имя таблицы (имя столбца);

Уникальные индексы используются не только для ускорения поиска данных, но и для обеспечения их целостности. Наличие уникального индекса не позволяет ввести в таблицу дубликаты записей

Синтаксис оператора:

CREATE UNIQUE INDEX имя индекса ON имя таблицы (имя столбца);

Составной индекс – это индекс, составленный по значениям нескольких столбцов таблицы.

CREATE UNIQUE INDEX имя индекса ON имя таблицы (имя столбца1, имя столбца2 );

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

Неявные индексы- это индексы, создаваемые автоматически сервером базы данных.

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