Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Распределенные системы обработки информации (Технология «клиент-сервера» в 1С)

Содержание:

ВВЕДЕНИЕ

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

Позднее, при возникновении новых моделей структуры «Клиент-сервер» (RDA, DBS и AS), модель файлового сервера для локальных сетей (FS) с малым функционалом была упразднена.

Захватив нишу баз данных, технология «Клиент – сервер» стала основной технологией глобальной сети Internet. Технология Intranet появилась в результате внедрения идей сети Internet в среду корпоративных систем. Различие этой технологии от технологии «Клиент-сервер» заключается в том, что она направлена не на данные, а на информацию в ее окончательно готовом к использованию виде. Сконструированные на основе технологии Intranet, вычислительные системы содержат в себе центральные серверы информации и распределенные компоненты представления информации конечному пользователю (программы-поисковики, или браузеры). В Intranet взаимодействие между клиентом и сервером осуществляется с помощью технологий web.

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

Данная тема была выбрана мной в следствии постоянного присутствия технологии «Клиент-сервер» в моей работе, будь то «Банк-клиент», тонкие «терминальные» клиенты, 1С: предприятие и т.д.

Суть технологии «клиент-сервер»

Определение сервер и клиент

Правильное решение предприятий, имеющих крупный «парк» компьютеров – это модель «клиент-сервер». Как правило в такой сети отдельный компьютер подключается к одному или нескольким мощным компьютерам, которые называются серверами.

Сервер - это компьютер, или выполняющаяся на нём программа, которая предоставляет клиентам доступ к общим ресурсам и управляет этими ресурсами[1].

Клиент - пользователь (получатель) услуг и/или ресурсов, которые предоставляет сервер[2].

Общие принципы организации технологии «клиент-сервер»

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

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

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

- правила (протокол) взаимодействия между этими программами.

Технология взаимодействия, в которой одна программа запрашивает выполнение какой-либо совокупности действий ("запрашивает услугу"), а другая ее выполняет, называется технологией "клиент-сервер"[3]. Участники такого взаимодействия называются соответственно клиентом (client) и сервером (server) (см. рис.1). Достаточно часто клиентом (или сервером) называют компьютеры, на которых функционирует то или иное клиентское (или серверное) программное обеспечение.

Запрос

Ответ

Сервер

Рабочая станция

Рис. 1. Клиент -сервер

Следует особо отметить, что набор действий, понимаемых как запрашиваемая услуга, - это не обязательно чтение (получение) объекта. В том числе это может быть сохранение (запись), пересылка объекта и т.д.

Архитектура «клиент-сервер»

Роль клиента и сервера в архитектуре

Роль серверов состоит в обеспечение централизованной защиты и управлении трафиком, а так же в предоставление клиентам ресурсов: информации, приложений и доступа к устройствам совместного пользования (например, к принтерам)[4]. В клиент - серверной среде в роли клиентов выступают настольные ПК (именно ПК, а не неинтеллектуальные терминалы!) под управлением любой операционной системы. Клиент, как правило, использует собственные вычислительные мощности для обработки информации, полученной от сервера, но полагается на сервер в части предоставления необходимых данных и приложений. Такое распределение ролей в обработке информации называется клиентской (front - end) и серверной (back - end) обработки[5].

Наряду с успешным функционированием в собственной «родной» среде, сети модели клиент - сервер могут работать с микрокомпьютерами и мэйнфреймами. Именно эта гибкость вкупе с достаточно низкой (по сравнению с традиционными решениями) стоимостью и обуславливает привлекательность клиент - серверных сетей. Работая в такой среде на компьютере - клиенте, возможно использование трех разных методов обработки информации: автономной работы, взаимодействия с другими ПК сети и подключения к серверу или мэйнфрейму для доступа к хранящейся там информации[6].

Двухуровневая архитектура

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

Технология «Клиент – сервер» - это архитектура программного комплекса, в которой происходит распределение прикладной программы по двум логически различным компонентам (клиент и сервер), взаимодействующим по схеме «запрос-ответ» и решающим свои определенные задачи[7] (см. рис. 2).

Запрос к базе данных

Ответ

Сервер

Рабочая станция

Манипуляция с БД

БД

Рис. 2. Архитектура «Клинт-Сервер»

Компьютер (или программа), управляющий и/или владеющий каким-либо ресурсом, называют сервером этого ресурса[8].

Компьютер (или программа), запрашивающий и пользующийся каким-либо ресурсом, называют клиентом этого ресурса[9].

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

Основной принцип технологии «Клиент-сервер» заключается в разделении функций приложения как минимум на три группы:

- модули интерфейса с пользователем;

По-другому эту группу называют логикой представления. Через эту группу пользователи взаимодействуют с приложением. Ее задача состоит в том, чтобы обеспечить средства для наиболее эффективного обмена информацией между пользователем и информационной системой, независимо от конкретных характеристик логики представления (интерфейс командной строки, сложные графические пользовательские интерфейсы, интерфейсы через посредника).[10]

- модули хранения данных;

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

- модули обработки данных (функции управления ресурсами);

Эту группу по-другому называют логикой доступа к данным или алгоритмами доступа к данным. Они исторически рассматривались как специфический для конкретного приложения интерфейс к механизму постоянного хранения данных наподобие файловой системы или СУБД. За счет модулей обработки данных организуется специфический для приложения интерфейс к СУБД. За счет интерфейса приложение управляет соединениями с базой данных и запросами к ней (перевод специфических для конкретного приложения запросов на язык SQL, получение результатов и перевод этих результатов обратно в специфические для конкретного приложения структуры данных)[12].

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

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

- компонент представления данных;

- прикладной компонент;

- компонент управления ресурсом[13].

В двухуровневой архитектуре клиент-сервер распределяется три основные части приложения по двум физическим модулям. Как правило, прикладной компонент находиться на сервере (например, сервере базы данных), компонент представления данных - на стороне клиента, а компонент управления ресурсом распределяется между клиентской и серверной частями[14]. В этом и заключается главный недостаток классической двухуровневой архитектуры.

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

Во избежание диссонанса различных элементов архитектуры были разработаны две модификации двухуровневой архитектуры «Клиент – сервер»: «Толстый клиент» («Тонкий сервер») и «Тонкий клиент» («Толстый сервер»).

В этих архитектурах разработчики попытались выполнять обработку данных на одной из двух физических частей - либо на стороне клиента («Толстый клиент»), либо на сервере («Тонкий клиент).

Каждый подход имеет свои минусы. В первом случае идет крайне большая нагрузка на сеть, потому что по ней передаются необработанные, избыточные данные. Помимо этого, затрудняется поддержание рабочей системы и ее изменение, ведь изменение алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, а иначе неизбежно возникнут ошибки или разрозненность данных. Так же появляется проблема описания встроенных процедур и их отладки, когда вся обработка данных выполняется на сервере. Так же существенным недостатком является отсутствие возможности переноса системы с обработкой информации на сервере на другую платформу (ОС)[16].

При разработки двухуровневой классической архитектуры «Клиент – сервер», стоит помнить следующее:

- архитектура «Толстый сервер» точная копия архитектуры «Тонкий клиент»[17] (рисунок 3);

Клиенты

Данные

Сервер

Рис.3. Архитектура «Тонкий клиент»

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

- усложняется реализация, так как языки типа SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки[18];

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

- программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;

- получившиеся таким образом программы полностью непереносимы на другие системы и платформы[19].

- архитектура «Тонкий сервер» копия архитектуры «Толстый клиент» (рисунок 4).

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

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

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

- перегружается сеть вследствие передачи по ней необработанных данных;

- слабая защита данных, поскольку сложно правильно распределить полномочия[20].

Клиенты

Данные

Сервер

Рис.4. Архитектура «Толстый клиент»

Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры «Клиент-сервер».

Трехуровневая архитектура

В середине 90-х годов 20-ого века признание специалистов получила трехуровневая архитектура «Клиент – сервер», разделившая информационную систему по функциональным возможностям на три отдельных компонента: логика представления, бизнес-логика и логика доступа к данным. Так же в трехуровневой архитектуре появляется дополнительное звено, которое предназначено для осуществления бизнес-логики, при этом полностью разгружается клиент, который направляет запросы промежуточному программному обеспечению, и максимально используются все возможности серверов - сервер приложений[21].

Клиент, в трехуровневой архитектуре, выполняет свою основную роль системы представления информации, поступающей с сервера приложений, а не загружен функциями обработки данных. Web-технологии - браузера, CGI и Java позволяют использовать данный интерфейс. Это уменьшает объем данных, передаваемых между клиентом и сервером приложений, что позволяет подключать клиентские компьютеры даже по медленным линиям типа телефонных каналов. Кроме того, клиентская часть может быть настолько простой, что в большинстве случаев ее реализуют с помощью универсального браузера. Но если менять ее все-таки придется, то эту процедуру можно осуществить быстро и безболезненно.

Сервер приложений – это программное обеспечение, являющееся промежуточным слоем между клиентом и сервером[22] (рисунок 5).

API

Данные

Сервер

приложений

Клиент

SQL

БД

Сервер

данных

Данные

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

Приложение

Рис.5. Сервер приложений

Существует несколько категорий продуктов промежуточного слоя:

- Message orientated – яркие представители MQseries и JMS;

- Object Broker – яркие представители CORBA и DCOM;

- Component based – яркие представители.NET и EJB[23].

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

Существует несколько серверов приложений от таких знаменитых компаний как Sun Microsystem, Borland, IBM, Oracle и каждый из них отличается набором предоставляемых сервисов (производительность в данном случае учитывать не будем). Эти сервисы облегчают программирование и развертывание приложений масштаба предприятия. Обычно сервер приложений предоставляет следующие сервисы:

- WEB Server – чаще всего включают в поставку самый популярный и мощный Apache;

- WEB Container – позволяет выполнять JSP и сервлеты. Для Apache таким сервисом является Tomcat;

- CORBA Agent – может предоставлять распределенную директорию для хранения CORBA объектов;

- Messaging Service – брокер сообщений;

- Transaction Service – уже из названия понятно, что это сервис транзакций;

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

- Java Mail – данный сервис может предоставлять сервис к SMTP;

- JMS (Java Messaging Service) – обработка синхронных и асинхронных сообщений;

- RMI (Remote Method Invocation) - вызов удаленных процедур.

Многоуровневые клиент-серверные системы достаточно легко можно перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Для создания этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.

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

В данное время применяется только многоуровневая архитектура, «Клиент-сервер», которая превосходит двухуровневую архитектуру. В трехуровневой архитектуре имеется три модификации – RDA, DBS и AS.

Понятие прикладных протоколов

Необходимо различать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня являются частью (хотя и весьма большой) сетевых приложений. Рассмотрим два примера. Web является сетевым приложением, позволяющим пользователям получать web-документы по запросу и состоящим из множества компонентов, включая стандарт формата документов (HTML), браузеры (Netscape Navigator, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или Netscape), протоколы прикладного уровня. Протокол прикладного уровня для web носит название протокола передачи гипертекста (HyperText Transfer Protocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью web-приложения.

В качестве второго примера рассмотрим приложение электронной почты. Электронная почта Интернета также состоит из множества компонентов: почтовых серверов, содержащих почтовые ящики пользователей, программ для просмотра и создания электронных писем, стандартов, описывающих структуру электронных писем, протоколов прикладного уровня, регламентирующих порядок обмена сообщениями серверов между собой и с оконечными системами пользователей, а также интерпретацию полей, из которых состоят электронные письма. Основным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (Simple Mail Transfer Protocol, SMTP)[24]. Как мы видим, SMTP (RFC 2821) -- лишь часть (хотя и достаточно большая) структуры приложений электронной почты.

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

· типы используемых сообщений, например, запросы и ответы;

· синтаксис каждого из типов сообщений, описывающий поля сообщения и их разделители;

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

· правила, описывающие события, которые вызывают генерацию сообщений.

Некоторые из протоколов прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC[25]. Это означает, что если разработчик нового браузера будет следовать стандарту, то браузер сможет получать документы с любого web-сервера, построенного поэтому же стандарту. Тем не менее существует множество протоколов прикладного уровня, которые не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это характерно для Интернет-телефонии.

Протокол ICMP (Internet Control Message Protocol) - протокол межсетевых управляющих сообщений. С помощью этого протокола компьютеры и устройства сети обмениваются друг с другом управляющей информацией. К примеру, этот протокол используется для передачи сообщений об ошибках, проверки доступности узла и т.д[26].

Протокол FTP (File Transfer Protocol) - протокол передачи файлов. Служит для обмена файлами между компьютерами. Например, вам нужно передать файл на сервер или, наоборот, скачать файл с сервера. Для этого вам нужно подключиться к файловому серверу (он же FTP-сервер) и выполнить необходимую вам операцию скачивания или закачки. Подключение осуществляется с помощью FTP-клиента. Простейший FTP-клиент входит в состав практически любой операционной системы. Кстати, просматривать FTP-серверы могут и обычные браузеры.[27]

Протокол HTTP (Hyper Text Transfer Protocol) - протокол обмена гипертекстовой информацией, то есть документами HTML. Вы, наверное, слышали, что HTML является базовым языком для создания веб-страниц. Так вот, протокол HTTP предназначен для передачи веб-страниц по сети. Таким образом, протокол HTTP используется веб-серверами, а браузеры - программы, служащие для просмотра веб-страниц, - являются HTTP-клиентами.[28]

Протоколы POP и SMTP. Протокол POP (Post Office Protocol) - протокол почтового отделения. Этот протокол используется для получения электронной почты с почтовых серверов. А для передачи электронной почты служит протокол SMTP (Simple Mail Transfer Protocol).[29]

Протокол IMAP. Для чтения почты может использоваться еще один протокол - IMAP. Его отличие от протокола POP состоит в том, что пользователь читает сообщения электронной почты, не загружая их на свой компьютер. Все сообщения хранятся на сервере. При удалении сообщения оно удаляется с сервера.[30]

Протокол SLIP (Serial Line Internet Protocol) - протокол подключения к сети Интернет по последовательной линии. Используется для установления связи с удаленными узлами через низкоскоростные последовательные интерфейсы. В настоящее время вытеснен протоколом РРР и практически не используется.[31]

Протокол РРР (Point-to-Point Protocol) - обеспечивает управление конфигурацией, обнаружение ошибок и повышенную безопасность при передаче данных на более высоком уровне, чем протокол SLIP. Поэтому при настройке сервера рекомендуется использовать именно этот протокол. Протокол РРР рассмотрен в RFC 1547 и RFC 1661.[32]

Протокол RIP (Routing Information Protocol) - используется для маршрутизации пакетов в компьютерных сетях. Для маршрутизации также используется протокол OSPF (Open Shortest Path First), который является более эффективным, чем RIP.[33]

Модели реализации

Модель файлового сервера

В модели файлового сервера все достаточно просто. Эта модель характеризует не столько способ образования фактографической информационной системы. Это общий способ взаимодействия компьютеров в локальной сети. Любой из компьютеров сети определяется файловым сервером, т. е. общим хранилищем любых данных. Суть FS-модели иллюстрируется схемой, приведенной на рис. 6.

Сервер

Компонент доступа к ресурсам

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

Прикладной компонент

Файлы

Рис.6. Модель файлового сервера

В FS-модели все основные компоненты размещаются на клиентской установке. При обращении к данным ядро СУБД, в свою очередь, обращается с запросами на ввод-вывод данных за сервисом к файловой системе. С помощью функций операционной системы в оперативную память клиентской установки полностью или частично на время сеанса работы копируется файл базы данных. Таким образом, сервер в данном случае выполняет чисто пассивную функцию[34].

В данной модели минимальны требования к производительности сервера. Это может быть обычный офисный компьютер. Главное требование модели – объем дискового пространства. Следует также отметить, что программные компоненты СУБД в данном случае не распределены, т. е. никакая часть СУБД на сервере не инсталлируется и не размещается.

При всех плюсах данной модели, очевидны и ее недостатки. Это, прежде всего, высокая нагрузка на сеть, достигающая пиковых значений особенно в момент массового вхождения в систему пользователей, например, в начале рабочего дня. Так же это отсутствие специальных механизмов безопасности файла (файлов) базы данных со стороны СУБД[35]. Иначе говоря, разделение данных между пользователями (параллельная работа с одним файлом данных) осуществляется только средствами файловой системы ОС для одновременной работы нескольких прикладных программ с одним файлом.

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

Модель удаленного доступа к данным

Учет специфики размещения и физического манипулирования данных во внешней памяти для реляционных СУБД – это основа модели удаленного доступа к данным. В RDA-модели компонент доступа к данным в СУБД полностью отделен от двух других компонентов (компонента представления и прикладного компонента) и размещается на сервере системы. SQL-сервер - компонент доступа к данным реализуется в виде самостоятельной программной части СУБД, и инсталлируется на вычислительной установке сервера системы[36]. Функции SQL-сервера ограничиваются низкоуровневыми операциями по организации, размещению, хранению и манипулированию данными в дисковой памяти сервера. Иначе говоря, SQL-сервер играет роль машины данных. Схема RDA-модели приведена на рис.7.

Сервер

Компонент доступа к ресурсам

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

Прикладной компонент

SQL

 Рис.7. Модель удаленного доступа к данным (RDA -модель)

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

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

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

 Другим, может быть неявным, достоинством RDA-модели является унификация интерфейса взаимодействия прикладных компонентов информационных систем с общими данными. Такое взаимодействие стандартизовано в рамках языка SQL уже упоминавшийся специальным протоколом ODBC (Open Database Connectivity - стандартный протокол доступа к данным на серверах баз данных SQL.), играющим важную роль в обеспечении интероперабельности, т. е. независимости от типа СУБД на клиентских установках в распределенных системах. Иначе говоря, специальный компонент ядра СУБД на сервере (так называемый драйвер ODBC) способен воспринимать, обрабатывать запросы и направлять результаты их обработки на клиентские установки, функционирующие под управлением реляционных СУБД других, не «родных» типов. Такая возможность существенно повышает гибкость в создании распределенных информационных систем на базе интеграции уже существующих в какой-либо организации локальных баз данных под управлением настольных или другого типа реляционных СУБД. Специальные драйверы ODBC могут обеспечить возможность использования настольной СУБД в качестве клиента SQL-сервера «тяжелой» многопользовательской клиент-серверной СУБД.

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

Модель сервера базы данных

 Ветвь развития модели удалённого доступа к данным является модель сервера базы данных. Механизм хранения процедур явило собой фундаментом для новой модели. Всё отличие этих моделей заключается в том, что все правила, все процедуры, описанные средствами языка SQL и события, определенные для конкретной предметной области АИС, хранятся непосредственно на сервере и там же выполняются. На рис.8. приведена DBS-модель.

Сервер

Компонент доступа к ресурсам

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

Прикладной компонент

Вызов

API

Рис.8. Модель сервера базы данных (DBS-модель)

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

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

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

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

Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вычислительным установкам, используется модель сервера приложений. Суть AS-модели заключается в переносе прикладного компонента АИС на специализированный в отношении повышенных ресурсов по быстродействию дополнительный сервер системы. Схема AS-модели приведена на рис.9.

Сервер

Компонент доступа к ресурсам

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

SQL

Прикладной компонент

Вызов API

Рис.9. Модель сервера приложений (AS-модель)

 Как и в DBS-модели, на клиентских установках располагается только интерфейсная часть системы, т.е. компонент представления. Однако вызовы функций обработки данных направляются на сервер приложений, где эти функции совместно выполняются для всех пользователей системы. За выполнением низкоуровневых операций по доступу и изменению данных сервер приложений, как в RDA-модели, обращается к SQL-серверу, направляя ему вызовы SQL-процедур, и получая, соответственно, от него наборы данных. Как известно, последовательная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзакцией. В этом отношении сервер приложений от клиентов системы управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют также монитором обработки транзакций (Transaction Processing Monitors — TRM), или просто монитором транзакций.

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

 В еще не устоявшейся до конца терминологии по моделям и технологиям «Клиент-сервер» RDA-модель характеризуют еще как модель с так называемыми «толстыми», а DBS-модель и AS-модель как модели, соответственно, с «тонкими» клиентами. По критерию звеньев системы RDA-модель и DBS-модель называют двухзвенными (двухуровневыми) системами, a AS-модель трехзвенной (трехуровневой) системой.

В практических случаях используются смешанные модели, когда простейшие прикладные функции и обеспечение ограничений целостности данных поддерживаются хранимыми на сервере процедурами (DBS-модель), а более сложные функции предметной области (так называемые «правила бизнеса») реализуются прикладными программами на клиентских установках (RDA-модель) или на сервере приложений (AS-модель).

Технология «клиент-сервера» в 1С

Для наглядного примера я решил взять систему программ «1С: Предприятие» 8.2 в которой один из альтернативных вариантов работы платформы, является клиент — серверный. «Клиент — сервер» выполнен на основе трехуровневой архитектуры.

Архитектура клиент-сервера делит работающую систему на три части, которые обусловленным образом взаимодействуют между собой

· клиентское приложение

· кластер — серверов «1С: Предприятия»

· сервер баз данных.

Клиентское приложение любого пользователя, работая с кластером серверов «1С: Предприятие» 8.2 при необходимости обращается к базе данных на сервере.

При этом совершенно не обязательно чтобы сервер базы данных и кластер серверов «1С: Предприятие» 8.2 находился на одном компьютере, это может быть и другой компьютер. Такие возможности помогут пропорционально разделить нагрузку между серверами.

Применение кластера серверов «1С: Предприятие» 8.2, это возможность сконцентрировать на нем осуществление объемных операций по обработке баз данных. Это могут быть выполнение объемных сложных запросов, и в этом случае программа пользователя получит только необходимую информацию в виде тематической выборки, а вся обработка будет происходить непосредственно на сервере. Такая возможность дает значительно облегчить работу, ведь увеличить мощность кластера намного легче, чем обновление программных систем целого ряда компьютеров.

Еще одно достоинство трехуровневой архитектуры, это возможность свободно администрировать и контролировать доступ всех пользователей к информации базы данных. И совершенно не обязательно пользователю вникать в расположение баз данных или конфигурации, весь доступ происходит через кластер серверов платформы «1С: Предприятие» 8.2. При вводе запроса достаточно указать название информационной базы и имя необходимого кластера, сообщив при этом пароль.

В данном случае платформа «1С: Предприятие» 8.2 для результативной выборки информации сама оперирует всеми базами данных:

· Специальные механизмы запросов направлены на самую максимальную эксплуатацию СУБД для выполнения необходимых видов работ, связанных с расчетами и оформлением отчетов;

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

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

Клиентские приложения.

Работа с клиентским приложением возможна через веб-сервер или напрямую с кластером. При подключении к кластеру толстый клиент и тонкий клиент непосредственно используют для передачи данных протокол TCP/IP. Если подключение осуществляется через веб-сервер тонкий клиент и веб-клиент используют протокол HTTP или HTTPS.

Кластер серверов

Основным компонентом системы «1С: Предприятие» 8.2, с помощью которого взаимодействуют пользователи с системой баз данных при работе с клиент сервером, является кластер серверов.

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

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

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

· База Microsoft SQL Server

· База PostgreSQL

· База IBM DB2

· База Oracle Database

Администрирование клиент-серверного варианта работы 8.2

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

Выполнение на сервере

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

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

Командный интерфейс формируется аналогично на сервере, и все отчеты выводятся на клиенте

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

На сервере выполняются следующее:

· Запросы к базам данных

· Запись всех данных

· Проводка документов

· Разные расчеты

· Проведение обработок

· Формирование готовых отчетов

· Подготовка форм к показу.

На клиенте выполняется следующее:

· Передача и открытие форм

· Показ форм

· Получение пользователем сообщений, предупреждений, т. е. информирование

· Проведение быстрых расчетов по простым формулам (цена Х количество)

· Операции с локальными файлами

· Операции с торговым оборудованием.

Главным отличием системы «1С: Предприятие» 8.2 от предыдущих версий является поддержка СУБД Oracle Database.

Oracle Database — одна из систем управления базами данных, которую поддерживает платформа в клиент-серверном варианте работы.

Однако при всех своих положительных моментах есть и отрицательные — это цена стоимости лицензии на использование сервера «1С: Предприятие».

При чем, что цена на использование 64-разрядного сервера «1С: Предприятие 8.2, 8.1, 8.0» стоит в 2 раза дороже, чем на использование 32-разрядного сервера «1С: Предприятие 8.2, 8.1, 8.0».

Будущее клиентов

На данный момент технология «Клиент-сервер» является одним из наиболее развитых направлений в IT и, конечно же, с увеличением количества пользователей, соединенных компьютерной сетью, началось активное формирование клиент-серверных программ и разработок. В этих случаях имеет место быть экономное и эргономичное использование сервера, который в основном служит для хранения информации и выполнения базовых операций. Именно пользователь (клиент), присоединенный к данной сети, берет на себя основную работу по вычислению и расчету. Успешное построение системы предоставляет возможность максимального использования ресурсов компьютера, учитывая возможность хранения информации непосредственно на компьютере пользователя, а не на чужом сервере. Так же эти технологии дают возможность клиенту работать, используя богатые пользовательские интерфейсы.

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

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

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

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

В 1996 году появляется JavaScript и html-страницы получают неизведанную до этого динамику и уже начинают становиться похожими на стандартные клиентские приложения. Навряд ли они смогут дойти до полноценных клиентских приложений, но страницы оживают и эти «живые» страницы совершают переворот в интернете, и бурное совершенствование скриптовой технологии продолжается, что приводит к рождению в 2005 году AJAX, а именно идеи асинхронного обращения к серверу для получения лишь необходимой части страницы, а не всей страницы. Инновационные решения, основанные на AJAX, типа карт Windows Live Local, приблизили веб-приложения к уровню удобства обычных клиентских программ.

Вот тут веб-страницу можно было уже спутать с обычным клиентским приложением. Но выглядеть как в клиентском приложении, и работать как клиентское приложение – это разные вещи. Все же доступ к ресурсам ограничен, соединение между клиентом и сервером одноразовое – уже просмотренные страницы при следующем обращении необходимо загружать опять. Но это проблемы, которые могут быть решены с появлением нового http-протокола.

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

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

серверной структуры. Здесь надо было срочно искать способы исправить ситуацию.

Корпорация Microsoft не задержалась с предложением и выпустила на рынок программную технологию Microsoft .NET Framework, призванную объединить множество различных служб, написанных на разных языках, для общей совместимости. Эта виртуальная машина может быть установлена на разных семействах Windows, а также на других операционных системах, что позволяет использовать любой из языков NET-семейства для написания работоспособных приложений для всех операционных систем, на которых установлен framework. Одна из проблем, которая так долго преследовала клиентские приложения, частично была решена.

Итак, гонка клиентских и веб-приложений находится на той стадии,

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

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

Так мы плавно перешли от истории к дням сегодняшним и видим, что бесспорного лидера нет, и каждая из технологий имеет свои достоинства и недостатки.

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

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

которой программное обеспечение предоставляется пользователю как Интернет-сервис. При этом пользователь не заботится об архитектуре облака,

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

Такие сервисы на данный момент уже предоставляют Microsoft, Amazon (Elastic Compute Cloud).

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

Ярким примером может служить:

Gmail - почтовый клиент Google, предоставляющий богатый инструментарий для работы с почтой прямо из браузера.

Тем же временем продолжается совершенствование способов приблизить веб в клиентских приложениях. В 2006 году корпорация

Microsoft выпустила плагин к IE – Silverlight, который позволяет запускать приложения, содержащие анимацию, векторную графику и аудио-видеоролики, что характерно для RIA (Rich Internet application).

Софтверные же компании имеют другую позицию – а именно видят будущее в smart client-ах– локальных приложениях, которые всецело ориентированы на потребление всевозможных сервисов из вне.

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

Ключевыми особенностями, отличающими Smart Client, являются:

Богатый пользовательский интерфейс. Чтобы называться «умным»,

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

(drag’n’drop, контекстные меню, дочерние окна, нотификации и т. д.)

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

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

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

(оффлайн) работе.

Примерами существующих смарт-клиентов могут быть:

IssueVision - help desk management application

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

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

— отключаться, поэтому для устранения этого неудобства в Microsoft предложили технологию Live Mesh, позволяющую локально запускать Web-приложения. Звучит немного парадоксально – имеется в виду, что приложение может работать с данными и при следующем подключении уже синхронизировать их с сервером.

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

В ближайшее время, как и последние много лет, основной средой обмена информацией останется интернет. Судя по тенденциям, клиентские и веб приложения будут развиваться параллельно, только немного другим путем – теперь это будут не монолитные порталы, написанные одной командой и использующие ресурсы одной экосистемы. Это будут наряженные ѐлки – один костяк и множество подключенных сервисов, возможно даже разработанные разными фирмами. Это приведет к тому, что основное внимание и львиная доля времени будет расходоваться на разработку сложных сервисов, но потом они легко будут подключаться к всевозможным порталам, приложениях и другим сервисам. Тем самым в скором будущем мы будем находиться не только во всемирной паутине, но еще и каждая ниточка этой паутины будет состоять из такого же сложного смешения различных сервисов, потребляемых различными устройствами. Но это огромное разнообразие сервисов будет полезно после окончательного внедрения нового протокола IPV6, что позволит подключать к интернету даже микроволновые печи, холодильники и т.д. Именно управление таким огромным количеством устройств в сети приведет к созданию множества сервисов и порталов, которые в онлайн режиме помогут управлять вашими электроприборами

Заключение

За последнее время технология «Клиент-сервер», связанная с сетью Internet и системами Intranet, опирающаяся на Web-технологии и язык Java, стала одним из наиболее активно развивающихся направлений в области IT-технологий в разработке программного обеспечения, которое значительно облегчает получение пользователем информации и данных. Объединяясь в общие тенденции, объектные и распределенные технологии консорциумов OMG и ODMG, раскрывают и синтезируют их. Примечательно, что все ведущие производители систем Internet/Intranet, включая Sun, IBM, Netscape, Microsoft, встраивают в свои продукты поддержку КС совместимых протоколов.

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

Библиография

Калабухова Г.В., Титов  В.М. «Компьютерный практикум по информатике. Офисные технологии»: учеб.пособие. – М.:ИД «ФОРУМ»: ИНФРА-М, 2008, - 336с.: ил, - (Высшее образование).

Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

Симонович С.В., Евсеев  Г.А.Алексеев А. Н. Общая информатика.  Учебное пособие. – М.: АСТ–Пресс:  Инфорком–Пресс, 2008.- 277с.

Гвоздева, В. А. «Информатика, автоматизированные информационные технологии и системы»: учебник / В. А. Гвоздева. – Москва: Форум: Инфра-М, 2011. – 541 с.

Н. В. Макарова  и др «Информатика»: учебник для студентов экономических  специальностей высших учебных  заведений ;.. – Москва: Финансы и статистика, 2009. – 765

Брюхов. Д. Интероперабельные информационные системы: архитектуры и технологии/ Д. Брюхов, В. Задорожный, Л. Калиниченко и др. - СУБД, 4, 1995.

Вудворд Дж. «Технология совместной работы»/ Вудворд Дж – изд. Вильямс, Москва 2005

Ладыженский Г. Ingres - современные тенденции в архитектуре сервера базы данных/ Г. Ладыженский, Г. Барон – изд. Открытые Системы, Осень 1993

Машкин М. Н. Информационные технологии Учебное пособие/ М. Н. Машкин - Москва 2008, УДК

Дьяконов В. П. Новые информационные технологии Часть Основы и аппаратное обеспечение/ В. П. Дьяконов, А. Н. Черничин - Под общей редакцией проф. В. П. Дьяконова Смоленск 2003

Горев А. SQL Server 6.5 для профессионалов/ А. Горев ,С. Макашарипов, Ю. Владимиров - изд. “Питер” Санкт-Петербург, 1998

Боуман Д., Практическое руководство по SQL/ Д. Боуман, C. Эмерсон, М. Дарновски - Изд. “Диалектика”, Киев, 1997

  1. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  2. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  3. Гвоздева, В. А. «Информатика, автоматизированные информационные технологии и системы»: учебник / В. А. Гвоздева. – Москва: Форум: Инфра-М, 2011. – 541 с

  4. Гвоздева, В. А. «Информатика, автоматизированные информационные технологии и системы»: учебник / В. А. Гвоздева. – Москва: Форум: Инфра-М, 2011. – 541 с

  5. Калабухова Г.В., Титов В.М. «Компьютерный практикум по информатике. Офисные технологии»: учеб. пособие. – М.:ИД «ФОРУМ»: ИНФРА-М, 2008, - 336с.: ил, - (Высшее образование).

  6. Вудворд Дж. «Технология совместной работы»/ Вудворд Дж – изд. Вильямс, Москва 2005

  7. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с

  8. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с

  9. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с

  10. Машкин М. Н. Информационные технологии Учебное пособие/ М. Н. Машкин - Москва 2008, УДК

  11. Машкин М. Н. Информационные технологии Учебное пособие/ М. Н. Машкин - Москва 2008, УДК

  12. Машкин М. Н. Информационные технологии Учебное пособие/ М. Н. Машкин - Москва 2008, УДК

  13. Ладыженский Г. Ingres - современные тенденции в архитектуре сервера базы данных/ Г. Ладыженский, Г. Барон – изд. Открытые Системы, Осень 1993

  14. Брюхов. Д. Интероперабельные информационные системы: архитектуры и технологии/ Д. Брюхов, В. Задорожный, Л. Калиниченко и др. - СУБД, 4, 1995.

  15. Вудворд Дж. «Технология совместной работы»/ Вудворд Дж – изд. Вильямс, Москва 2005

  16. Брюхов. Д. Интероперабельные информационные системы: архитектуры и технологии/ Д. Брюхов, В. Задорожный, Л. Калиниченко и др. - СУБД, 4, 1995

  17. Брюхов. Д. Интероперабельные информационные системы: архитектуры и технологии/ Д. Брюхов, В. Задорожный, Л. Калиниченко и др. - СУБД, 4, 1995

  18. Боуман Д., Практическое руководство по SQL/ Д. Боуман, C. Эмерсон, М. Дарновски - Изд. “Диалектика”, Киев, 1997

  19. Боуман Д., Практическое руководство по SQL/ Д. Боуман, C. Эмерсон, М. Дарновски - Изд. “Диалектика”, Киев, 1997

  20. Брюхов. Д. Интероперабельные информационные системы: архитектуры и технологии/ Д. Брюхов, В. Задорожный, Л. Калиниченко и др. - СУБД, 4, 1995.

  21. Калабухова Г.В., Титов В.М. «Компьютерный практикум по информатике. Офисные технологии»: учеб.пособие. – М.:ИД «ФОРУМ»: ИНФРА-М, 2008, - 336с.: ил, - (Высшее образование).

  22. Н. В. Макарова и др «Информатика»: учебник для студентов экономических специальностей высших учебных заведений ;.. – Москва: Финансы и статистика, 2009. – 765с

  23. Дьяконов В. П. Новые информационные технологии Часть Основы и аппаратное обеспечение/ В. П. Дьяконов, А. Н. Черничин - Под общей редакцией проф. В. П. Дьяконова Смоленск 2003

  24. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  25. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  26. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  27. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  28. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  29. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  30. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  31. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  32. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  33. Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

  34. Калабухова Г.В., Титов В.М. «Компьютерный практикум по ин-форматике. Офисные технологии»: учеб.пособие. – М.:ИД «ФОРУМ»: ИНФРА-М, 2008, - 336с.: ил, - (Высшее образование).

  35. Горев А. SQL Server 6.5 для профессионалов/ А. Горев ,С. Ма-кашарипов, Ю. Владимиров - изд. “Питер” Санкт-Петербург, 1998

  36. Боуман Д., Практическое руководство по SQL/ Д. Боуман, C. Эмерсон, М. Дарновски - Изд. “Диалектика”, Киев, 1997