Смекни!
smekni.com

«Информационные технологии в экономике» (стр. 5 из 13)

Клиентское приложение может быть реализовано на языке настольных СУБД (MSAccess, FoxPro, Paradox, Clipper и др.). При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер (OpenDataBaseConnectivity), который обеспечивает возможность пересылки и преобразования данных из глобальной БД в структуру БД клиентского приложения.


Представление

данных пользователя Приложение База данных

Централизованная

Система


Архитектура

«Файл-сервер»

Двухуровневая

архитектура

«клиент-сервер»

Трехуровневая

Архитектура

«клиент-сервер»

Многоуровневая

Архитектура

«клиент-сервер»

Рис.2. Варианты клиент-серверной архитектуры КЭИС

Трехуровневая клиент-серверная архитектура позволяет помещать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (ApplicationProgramInterface) устанавливается связь клиентских рабочих станций. Клиентская часть приложения вызывает необходимые функции сервера приложения, называемые «сервисами». Прикладные программы в свою очередь обращаются к серверу БД с помощью SQL запросов. Такая организация позволяет повысить производительность и эффективность КЭИС за счет:

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

- параллельности в работе сервера приложений и сервера БД, причем сервер приложений может быть менее мощным по сравнению с сервером БД;

- оптимизации доступа к БД через сервер приложений из клиентских мест путем диспетчеризации выполнения запросов в сети;

- повышение скорости и надежности обработки данных в результате дублирования ПО на нескольких серверах приложений, которые могут заменять друг друга в сети в случае перегрузки или выхода из строя одного из них;

- переноса функций администрирования системы по проверке полномочий доступа пользователей с сервера БД на сервер приложений.

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

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

4.3. Многоуровневые системы клиент-сервер

Технология клиент-сервер считается одним из "китов" современного мира компьютерных сетей. Но задачи, для решения которых она была разработана, уходят в прошлое. Новые задачи и технологии требуют переосмысления принципов клиент-серверных систем. Одна из таких технологий World Wide Web. Web-технология является развитием архитектуры клиент-серверы, т.е. с помощью одного клиента можно подключиться ко многим серверам. Информационная система, кроме интерфейса, должна иметь уровни обработки данных и их хранения. Проблема разработчиков интерсетей в согласовании работы Web с другими элементами системы, например базами данных. Одним из перспективных способов решения этой проблемы - многоуровневые системы клиент-сервер.

Классическая система клиент-сервер работает по схеме "запрос-ответ" (двухуровневая архитектура). Клиент выполняет активную функцию (запросы), сервер пассивно на них отвечает.


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

Каждая из этих частей может быть реализована независимо от двух других.

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

В классической архитектуре клиент-сервер три основные части приложения распределяются по двум физическим модулям. Обычно ПО хранения данных располагается на сервере (/: сервере базы данных), интерфейс с пользователем - на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями. В этом основной недостаток данной архитектуры. Разбиение алгоритмов обработки данных требует синхронизации действий обеих частей системы. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или "2,5-уровневый клиент-сервер"). Каждый подход имеет свой недостаток: в первом случае неоправданно перегружается сеть, т.к. по ней передаются необработанные (избыточные) данные, усложняется поддержка и изменение системы, так как замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, иначе последует несогласованность данных; во втором случае, когда вся обработка информации выполняется на сервере, возникает проблема описания встроенных процедур и их отладки (описание является декларативным и не допускает пошаговой отладки). Кроме того, систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу.

Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными БД, реализует первую модель ("толстый" клиент), обеспечивающую интерфейс с сервером БД через язык SQL.. Этот вариант, кроме выше перечисленных недостатков, имеет низкий уровень безопасности.

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