- •Оглавление
- •Введение
- •1. Планово-экономическая информация
- •1.1. Понятие экономической информации
- •1.2. Структура экономической информации
- •1.3. Группировка экономической информации
- •1.4. Классификаторы экономической информации
- •2.2. Носители информации
- •2. Представление экономической информации
- •2.1. Что понимается под представлением информации?
- •2.2.1. Гибкие магнитные диски
- •2.2.3. Магнитооптические диски (мо)
- •2.2.4. Сменные магнитные диски
- •2.3. Кодировка экономической информации
- •3. Главные этапы автоматизации
- •3.1. Обоснование целесообразности автоматизации решения задачи
- •3.2. Разработка постановки задачи и оформление документации
- •3.3. Выполнение работ по программированию задачи
- •3.4. Разработка и решение контрольного примера решения задачи
- •3.5. Испытания и отладка
- •3.6. Подготовка первичных массивов
- •3.7. Заказ и получение материалов
- •3.8. Составление рабочих инструкций для персонала
- •3.9. Подготовка персонала
- •3.10. Выбор, заказ и получение технических средств автоматизации
- •3.11. Подготовка помещений
- •3.12. Ввод задачи в опытную эксплуатацию
- •3.13. Сдача задачи в промышленную эксплуатацию. Эксплуатация. Сопровождение
- •4. Формы внедрения автоматизации
- •4.1. Метод “шахт”
- •4.1.1. Преимущества метода “шахт”
- •4.1.2. Недостатки метода “шахт”
- •4.2. Метод “пласта”
- •Заключение
- •5. Автоматизированные системы управления
- •5.1. Понятие и принципы построения
- •5.2. Структура и особенности построения
- •6. Автоматизированное рабочее место
- •6.1. Классификация арм
- •6.2. Принципы конструирования арм
- •6.3. Типовая структура арм
- •6.4. Требования к разрабатываемому арм
- •6.5. Арм на предприятии
- •6.6. Арм в управленческой деятельности
- •6.7. Арм специалистов
- •6.8. Арм в планово-экономическом отделе
- •6.9. Качество разработанного программного изделия
- •6.9.1. Надежность программного изделия
- •6.9.2. Эффективность программного изделия
- •6.9.3. Оценка экономической эффективности системы
- •7. Базы и банки данных
- •7.1. Основные компоненты банка данных
- •Функции администратора банка данных
- •7.2. Пользователи банков данных
- •7.3. Классификация банков данных
- •7.3.1. Классификация БнД по экономико-организационным признакам
- •7.3.2. Классификация баз данных
- •7.3.3. Классификация субд
- •7.4. Модели данных
- •7.4.1. Общие понятия
- •7.4.2. Основные операции над данными
- •7.4.3. Ограничения целостности
- •7.4.4. Сетевая модель данных
- •7.4.5. Иерархическая модель данных
- •7.4.6. Реляционная модель данных
- •Фундаментальные свойства отношений
- •Общая характеристика реляционной модели данных
- •7.4.7. Технология и модели "клиент-сервер"
- •8. Локальные вычислительные сети (лвс)
- •8.1. Базовая модель osi
- •8.2. Сетевые устройства и средства коммуникаций
- •8.3. Топологии вычислительной сети
- •8.4. Типы построения сетей
- •9.1. Возможности Internet
- •9.2. Структура и основные принципы
- •9.3. Поиск информации в Internet
- •9.4. Источники специализированной информации
7.4.7. Технология и модели "клиент-сервер"
"Клиент-сервер" - это определенный тип взаимодействия компьютеров в сети. Как правило, компьютеры не являются равноправными. Каждый из них имеет свое, отличное от других, назначение, играет свою роль. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса, а компьютер, желающий им воспользоваться - клиентом. Конкретный сервер определяется видом ресурса, которым он владеет.
Примерами серверов могут служить:
сервер телекоммуникаций - обеспечивает услуги по связи данной локальной сети с внешним миром;
вычислительный сервер - производит вычисления, которые невозможно выполнить на рабочих станциях;
дисковый сервер - обладает расширенными ресурсами внешней памяти и предоставляет их в использование рабочим станциям и, возможно, другим серверам;
файловый сервер - поддерживает общее хранилище файлов для всех рабочих станций;
сервер баз данных - фактически обычная СУБД, принимающая запросы по локальной сети и возвращающая результаты.
В сети один и тот же компьютер может выполнять роль как клиента, так и сервера.
Этот же принцип распространяется и на взаимодействие программ. Если одна из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, то такая программа выступает в качестве сервера. Программы, которые пользуются этими услугами, принято называть клиентами. Так, ядро реляционной SQL-ориентированной СУБД часто называют сервером базы данных, или SQL-сервером, а программу, обращающуюся к нему за услугами по обработке данных, - SQL-клиентом.
Первоначально СУБД имели централизованную архитектуру. В ней сама СУБД и прикладные программы, которые работали с базами данных, функционировали на центральном компьютере (большая ЭВМ или мини-компьютер). Там же располагались базы данных. К центральному компьютеру были подключены терминалы, выступавшие в качестве рабочих мест пользователей. Все процессы, связанные с обработкой данных, как то: поддержка ввода, осуществляемого пользователем, формирование, оптимизация и выполнение запросов, обмен с устройствами внешней памяти и т.д. - выполнялись на центральном компьютере, что предъявляло жесткие требования к его производительности.
При использовании в информационной системе технологии "клиент-сервер", прикладные программы, реализованные в ее рамках, имеют распределенный характер, т.е. часть функций прикладной программы реализована в программе-клиенте, другая - в программе-сервере, причем для их взаимодействия определен некоторый протокол.
Основной принцип технологии "клиент-сервер" заключается в разделении функций стандартного интерактивного приложения на четыре группы, имеющие различную природу. Первая группа - это функции ввода и отображения данных. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы - открытие счета, перевод денег с одного счета на другой и т.д.). К третьей группе относятся фундаментальные функции хранения и управления информационными ресурсами (базами данных, файловыми системами и т.д.). Функции четвертой группы - это служебные функции (играющие роль связок между функциями первых трех групп.
В соответствии с этим в любом приложении выделяются следующие логические компоненты:
компонент представления, реализующий функции первой группы;
прикладной компонент, поддерживающий функции второй группы;
компонент доступа к информационным ресурсам, поддерживающий функции третьей группы, а также вводятся и уточняются соглашения о способах их взаимодействия (протокол взаимодействия).
Различия в реализациях технологии "клиент-сервер" определяются четырьмя факторами:
1) в какие виды программного обеспечения интегрированы каждый из этих компонентов;
2) какие механизмы программного обеспечения используются для реализации функций всех трех групп;
3) как логические компоненты распределяются между компьютерами в сети;
4) какие механизмы используются для связи компонентов между собой.
Р
ис.4.
Система с централизованной архитектурой
Выделяются четыре подхода, реализованные в моделях:
модель файлового сервера (File Server - FS);
модель доступа к удаленным данным (Remote Data Access - RDA);
модель сервера базы данных (DataBase Server - DBS);
модель сервера приложений (Application Server - AS).
FS-модель
является базовой для локальных сетей
персональных компьютеров. Суть модели
заключается в следующем. Один из
компьютеров в сети считается файловым
сервером и предоставляет услуги по
обработке файлов другим компьютерам.
Файловый сервер работает под управлением
сетевой операционной системы и играет
роль компонента доступа к информационным
ресурсам (т.е. к файлам). На других
компьютерах в сети функционирует
приложение, в кодах которого совмещены
компонент представления и прикладной
компонент. Протокол обмена представляет
собой набор низкоуровн
евых
вызовов, обеспечивающих приложению
доступ к файловой системе на файл-сервере.
Рис.5. Модель файлового сервера.
FS-модель послужила фундаментом для расширения возможностей персональных СУБД в направлении поддержки многопользовательского режима. В таких системах на нескольких персональных компьютерах выполняется как прикладная программа, так и копия СУБД, а базы данных содержатся в разделяемых файлах, которые находятся на файловом сервере. Когда прикладная программа обращается к базе данных, СУБД направляет запрос на файловый сервер. В этом запросе указаны файлы, где находятся запрашиваемые данные. В ответ на запрос файловый сервер направляет по сети требуемый блок данных. СУБД, получив его, выполняет над данными действия, которые были декларированы в прикладной программе.
К технологическим недостаткам подобного типа взаимодействия относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипуляции с данными ("данные - это файлы"), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т.д.
В RDA-модели компонентом доступа к информационным ресурсам является SQL-сервер. Коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается либо операторами специального языка (языка SQL, например, если речь идет о базах данных), либо вызовами функций специальной библиотеки (если имеется соответствующий интерфейс прикладного программирования - API).
Клиент направляет запросы к информационным ресурсам (например, к базам данных) по сети удаленному компьютеру. На нем функционирует ядро СУБД, которое обрабатывает запросы, выполняя предписанные в них действия, и возвращает клиенту результат, оформленный как блок данных. При этом инициатором манипуляций с данными выступают программы, выполняемые на компьютерах-клиентах, в то время как ядру СУБД отводится пассивная роль - обслуживание запросов и обработка данных.
RDA-модель избавляет от недостатков, присущих как системам с централизованной архитектурой, так и системам с файловым сервером.
Рис.6. Модель доступа к удаленным данным.
Перенос компонента представления и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД, сводя к минимуму общее число процессов операционной системы. Сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций.
Основное достоинство RDA-модели - унификация интерфейса "клиент-сервер" в виде языка SQL.
Н
едостатки:
во-первых, взаимодействие клиента и
сервера посредством SQL-запросов
существенно загружает сеть; во-вторых,
удовлетворительное администрирование
приложений в RDA-модели практически
невозможно из-за совмещения в одной
программе различных по своей природе
функций (функции представления и
прикладные).
Рис.7. Модель сервера базы данных
Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель. Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.
В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, т.е. ядро СУБД. Достоинства DBS-модели очевидны: это и возможность централизованного администрирования прикладных функций, и снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур), и возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. К недостаткам модели можно отнести ограниченность средств, используемых для написания хранимых процедур, которые представляют собой разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения, такими, как C или Pascal. Сфера их использования ограничена конкретной СУБД, в большинстве СУБД отсутствуют возможности отладки и тестирования разработанных хранимых процедур.
На практике часто используется смешанные модели, когда обеспечение целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель). Так или иначе современные многопользовательские СУБД опираются на RDA- и DBS-модели и при создании ИС, предполагающем использование только СУБД, выбирают одну из этих двух моделей либо их разумное сочетание.
Рис.8. Модель сервера приложений.
В AS-модели процесс, выполняемый на компьютере-клиенте, отвечает, как обычно, за интерфейс с пользователем (т.е. осуществляет функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client - AC). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов: базы данных, очереди, почтовые службы и др.
RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций, которые выделяются как особый вид программного обеспечения.
