При подготовке запросов к базе данных

Перенос персональной базы данных на сервер

Сервером.

В качестве сервера может использоваться ядро профессиональной реля­ционной СУБД (например, Informix 7.x и Sybase System 10) или некоторый SQL-сервер (например, Novell NetWare SQL. и Microsoft SQL Server).

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

естественно снижает трафик в сети, ослабляет требования по ресурсам к КК позволяет создавать более эффективные и надежные информационные системы.

При разработке распределенных ИС в организации взаимодействия клиентской и серверной части можно выделить следующие задачи:

• перенос персональной базы данных на сервер для последующего ее коллективного использования как корпоративной базы данных;

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

• разработка клиентского приложения для удаленного доступа к корпоративной базе данных со стороны компьютера- клиента;

• администрирование сервера со стороны клиента. Рассмотрим названные задачи более подробно.

Задача переноса персональной базы данных на сервер может возникать в ситуациях, когда требуется обеспечить коллективный доступ к базе данных, разработанной с помощью персональной СУБД, такой как Мiсгоsоft Ассеss или Мiсгоsоft VisuаI FохРго. Для решения этой задачи в составе названных персональных СУБД имеются соответствующие средства. Так, в Мiсгоsоft Ассеss 2002 имеется Upsizing Wizard (Мастер «наращивания»), предназначенный для преобразования базы данных Ассеss к формату SQL Sегvег. Способы взаимодействия

Подготовка запросов к базе данных на сервере (на языке SQL) со стороны клиентской части может выполняться с помощью некоторой утилиты, напри мер, Queгу Аnа1yzer. Для предоставления пользователю больших возможностей и удобства в подготовке и выполнении запросов создаются клиентские приложения.

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

• технологии ОDВС (совместимости открытых баз данных);

• интерфейса ОLE DВ (связывания и встраивания объектов баз данных);

• технологии АDО (АсtivеХ Dаtа Оbject — объектов данных АсtivеХ).

Названные интерфейсы и технологии могут применяться совместно, например, ОDВС и АDО и ОLЕ DВ. Охарактеризуем подробнее названные подходы к организации взаимодействия клиентской и сервер ной частей баз данных.

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

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

Промежуточное ПО эволюционировало вместе с архитектурой «клиент — сервер». Ранние, но достаточно эффективные как с точки зрения разработки, так и эксплуатации, частные решения предназначались для упрощения доступа к базам в двухзвенной модели, где «толстый» клиент реализует всю логику обработки информации, предоставляемой сервером базы данных. Такие системы вполне удовлетворяли потребностям не больших корпоративных подразделений с ограниченным числом пользователей и невысокой интенсивностью обмена.

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

Развитие этого среднего звена клиент-серверной модели идет в сторону усложнения. Ограничиваясь вначале построением более высокого уровня абстракции для взаимодействия приложения с ресурсами данных, разработчик приложения получал возможность использовать общие АРI, которые скрывали различия специфических интерфейсов коммуникационных протоколов более низкого уровня, напри мер, ТСР/IР, Socket или DECNet. Однако теперь этого уже явно недостаточно для построения сложных распределенных приложений. Современные решения не только обеспечивают межпрограммное взаимодействие, но и являются платформой для реализации сервера приложений, обеспечивая обширный набор необходимых служб: управления транзакциями, именования, защиты и т. д.

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

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

ПО промежуточного уровня можно разделить на две категории.

1. ПО доступа к базам данных (например, ОDВС интерфейсы и SQL -шлюзы).

2. ПО межмодульного взаимодействия — системы, реализующие вызов удаленных процедур (RPC — Remote Ргосеduге Саll); мониторы обработки транзакций (ТР-мониторы); средства интеграции распределенных объектов.

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

Дата добавления: 2015-05-09