книги / Теоретические основы автоматизированного управления

DataBase Connectivity (ODBC) (рис. 7.16). В этом случае сеть образу­ ется путем соединения серверов, которое обеспечивается или средст­ вами СУБД (SQLServer), или мониторами транзакций (TUXEDO).

Обсудим более подробно вариант реализации РБД — архитектуру «клиент—сервер».

Совместно с термином «клиент—сервер» используют три понятия: архитектура — речь идет о концепции построения варианта

РБД;

’технология — говорят о последовательности действий в РБД;

•система — рассматривают совокупность элементов и их взаимо­ действие.

Об архитектуре «клиент—сервер» говорилось ранее. Технология «клиент—сервер» позволяет повысить производи­

тельность труда:

сокращается общее время выполнения запросов за счет мощного сервера;

уменьшается доля и увеличивается эффективность использова­ ния клиентом (для вычислений) центрального процессора;

снижается объем использования клиентом памяти «своего» ком­ пьютера;

сокращается сетевой трафик.

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

Отметим, что архитектуре «клиент — сервер» предшествовала ар­ хитектура «файл-сервер», в которой возможны следующие варианты.

1.На компьютерах-клиентах имеется копия БД. Работа с таким вариантом осложняется двумя обстоятельствами: синхронизацией данных различных копий в конце работы БД; высоким трафиком (по­ токами данных между сервером и клиентами, поскольку в любом слу­ чае передается содержимое всей БД).

2.В СУБД Access, которая изначально создана как локальная, предусмотрен режим деления базы данных. Таблицы остаются на сер­ вере (back-end), а остальные объекты (запросы, отчеты) передаются клиентам (front-end). В этом случае по-прежнему большой трафик, в силу чего при использовании файлов-серверов число подключаемых

клиентов — при их надежной работе — не более четырех.

В то же время требовалось подключение десятков и даже сотен клиентов. Этого удалось достичь в архитектуре (режиме, технологии) «клиент—сервер», при котором трафик резко уменьшается, посколь­ ку по сети передаются только те данные, которые соответствуют за­ просам клиентов [43].

Для этого пришлось построить СУБД, изначально предназначен­ ные для работы в сети. Фирма Microsoft [6,16] была вынуждена в до­ полнение к СУБД Access, которая использовалась с помощью прило­ жения ODBC только для клиентских целей, предложить в качестве сервера Microsoft SQL Server. Такая структура оказалась тяжеловес­ ной и неудобной, так как разработчику требовалось знать уже две СУБД.

Из других предложений очень удачным оказался программный продукт Delphi [12, 51, 64], в рамках которого могут использоваться СУБД dBase, Paradox и при отдельной инсталляции InterBase (режим «клиент—сервер»). При этом СУБД InterBase поддерживается наряду с языком программирования SQL мощным, понятным, простым и широко распространенным языком программирования (Object) Pascal [15], построенным с применением объектно-ориентированно­ го подхода [64].

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

В системе «клиент—сервер» возможно выделить следующие со­ ставляющие: сервер, клиент, интерфейс между клиентом и сервером, администратор.

Сервер осуществляет управление общим для множества клиентов ресурсом. Он выполняет следующие задачи:

•управляет общей БД;

•осуществляет доступ и защиту данных, их восстановление;

•обеспечивает целостность данных.

К БД на сервере предъявляются те же требования, как и к центра­ лизованной многопользовательской БД.

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

Клиент хранит в компьютере свои приложения, с помощью кото­ рых осуществляется запрос данных на сервере. Клиент решает сле­ дующие задачи:

•предоставляет интерфейс пользователю;

•управляет логикой работы приложений;

•проверяет допустимость данных;

•осуществляет запрос и получение данных с сервера. Средством передачи данных между клиентом и сервером является

сеть (коаксиальный кабель, витая пара) с сетевым (сетевая операци­ онная система — СОС) и коммуникационным программным обеспе­ чением.

Вкачестве СОС могут использоваться Windows NT, Novell NetWare. Коммуникационное программное обеспечение позволяет компьютерам взаимодействовать на языке специальных программ — коммуникационных протоколов.

Вобщем случае такое взаимодействие осуществляется с помощью семиуровневой схемы ISO с соответствующими протоколами. Для локальных сетей схема упрощается. Протоколоми для Windows NT служит Transmission Control Program/Intemet Program (TCP/IP), для NetWare — Sequenced Packed eXchange/Intemet Packede eXchaned (SPX/IPX).

Разнообразие сетевых средств делает необходимым создание стандартного промежуточного программного обеспечения клиент — сервер, находящегося на сервере и клиентах. Говорят о прикладном программном интерфейсе (Application Programming Interface — API).

Сюда относятся Open DataBase Connectivity (ODBC) а также Integrated Database Application Programming Interface (IDAPI), кото­ рый используется в приложении Delphi и СУБД InterBase.

Взаимодействие клиентов и сервера можно представить следую­ щим образом.

При обращении пользователя к приложению компьютер-клиент запрашивает у пользователя имя и пароль. После этого (при правиль­ ном ответе) приложение может быть запущено клиентом. Приложе­ ние дает возможность подключиться к серверу, которому сообщают­ ся имя и пароль пользователя.

Если подключение осуществлено, начинает работать сервер, вы­ полняющий два вида процессов: переднего раздела и фоновые. Про­ цессы переднего раздела непосредственно обрабатывают запросы, фоновая составляющая связана с управлением процессом обработки.

Работа сервера может иметь следующий порядок.

1.После поступления запроса диспетчер ставит его в очередь по схеме «первым пришел — первым обслужен».

2.Процесс переднего раздела выбирает «самый старый» запрос и начинает его обработку. После завершения результаты помещаются в очередь для передачи клиенту.

3.Диспетчер посылает результаты из очереди соответствующему клиенту.

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

• запись данных из БД в промежуточную (буферную) память ра­ бочей области (при чтении) и обратно (при обновлении);

•запись в журнал транзакций;

•архивация (копирование) групп транзакций;

•аварийное завершение транзакций;

•периодическая запись на диск контрольных точек для обеспече­ ния восстановления данных в РБД после аппаратного сбоя.

Администратор РБД (АРБД) должен решать следующие задачи [62]:

•планирование РБД и распределение памяти;

•настройку конфигурации сети;

•создание РБД;

•работу с разработчиками приложений;

•создание новых пользователей и управление полномочиями;

•регулярную архивацию БД и выполнение операций по ее восста­ новлению;

• управление доступом к БД с помощью ОС и СОС, средств защи­ ты и доступа.

В больших системах АРБД может состоять из ряда лиц, отвечаю­ щих, например, за ОС, сеть, архивацию, защиту.

Таким образом, система «клиент—сервер» своеобразна: с одной стороны, ее можно считать разновидностью централизованной мно­ гопользовательской БД, с другой — она является частным случаем РБД.

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

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

Использование для составления сценария CASE-средств значи­ тельно сокращают трудоемкость работ по проектированию. Иначе эта процедура выполняется вручную с помощью команд языка SQL.

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

Чтобы его снизить, можно воспользоваться следующими реко­ мендациями.

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

2.Целесообразно использовать на сервере хранимые процедуры, совокупность которых можно инкапсулировать в виде пакета (моду­ ля). В результате трафик уменьшится: клиент будет передавать только вызов процедуры и ее параметры, а сервер — результаты выполнения процедуры.

3.В ряде случаев клиентам следует получать уведомления базы данных (например, заведующему складом — о нижнем уровне запа­ сов, при котором следует выполнять новый заказ). Если уведомление производится по запросу клиента, трафик увеличивается. Проще эту (хранимую) процедуру разместить на сервере, который будет автома­ тически уведомлять клиента о возникновении события. В то же время

Рис. 7.17. Одноуровневая («толстый» клиент) и многоуровневая («тонкий» клиент) структуры «клиент—сервер»

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

В режиме «клиент—сервер» выделяютдве разновидности структу­ ры: одноуровневую, о которой шла речь до сих пор, и многоуровне­ вую (рис. 7.17).

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

Рассмотрим вопросы создания и реализации наиболее распро­ страненных реляционных операционных баз данных [6, 16, 32, 51, 64]. Создание объектно-ориентированных баз данных имеет свою специфику [62] и в настоящей работе не рассматривается.

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

Последовательность этапов проектирования показана на рис. 7.18. Рассмотрим этапы более подробно.

Анализ требований. На начальной стадии развития БД считались автономными, поскольку предполагалось построение универсально­ го хранилища данных. Полагали, что все исходные данные известны. В силу этого на данном этапе велся лишь анализ возможностей реали­ зации требований, предъявляемых к проектируемой базе данных.

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

Первый этап получил более точные названия [42,52,54,56], наи­ более удачным из которых, на наш взгляд, является «планирование базы данных».

При этом выявилось [52] два подхода к проектированию БД:

1 ) традиционный (классический), сформировавшийся в 80-е годы XX в. и применяемый до сих пор в информационно-поисковом режиме АСУ;

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

Первый подход преследовал цель автоматизации документооборо­ та. Задача ставилась так. На входе БД имеется одна система докумен­ тов (таблиц), данные для которых получали из разных источников. База данных преобразует систему входных документов в систему вы­ ходных документов, удобных для работы конечного пользователя. Алгоритм преобразования, когда это не вызывает разночтений, будем называть в общем случае алгоритмом приложения.

Второй подход исходит из решения задачи [58], т.е. от алгоритма приложения, на основе которого и создается база данных. Под прило­ жением понимается программа или группа программ, предназначен­ ных для выполнения определенных однотипных работ.

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

Во втором подходе сформировалась такая технология:

•определение цели проектирования;

•выявление логики приложения;

•планирование схемы связей приложения (системы таблиц), иногда называемой DLL-сценарием.

Первый этап второго подхода имеет другую направленность — построение алгоритма приложения и системы данных для него.

Влюбом подходе результатом первого этапа является техническое задание (ТЗ), в котором фиксируются требования, предъявляемые к БД, и которое является основой для работы на последующих этапах проектирования.