Технологии “Клиент-Сервер”

Содержание:

Введение

Как результат эволюции компьютерных технологий появились компьютерные сети. Само появление компьютерных сетей ознаменовало новый этап в компьютерной технологии.

Самые первые компьютерные сети были довольно примитивными – скорость работы такой сети была очень маленькой по сравнению с современными сетевыми технологиями, но для того времени и это было достижение.

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

Целью курсового проекта является изучение технологии «клиент-сервер».

Глава 1. Теоретичекие основы функционирования технологии "клиент-сервер"

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

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

2. Сервер (программное обеспечение) -- программное обеспечение, принимающее запросы от клиентов (в архитектуре клиент-сервер).

3. Сервер (аппаратное обеспечение) -- компьютер (или специальное компьютерное оборудование) выделенный и/или специализированный для выполнения определенных сервисных функций.

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

Взаимосвязь понятий. Серверное приложение (сервер) запускается на компьютере, так же называемом "сервер", при этом при рассмотрении топологии сети, такой узел называют "сервером". В общем случае может быть так, что серверное приложение запущено на обычной рабочей станции, или серверное приложение, запущенное на серверном компьютере в рамках рассматриваемой топологии выступает в роли клиента (т.е. не является сервером с точки зрения сетевой топологии).

• 1. 1.2 Понятие и назначение технологии «клиент-сервер»

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

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

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

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

Рис. 1. Системы с централизованной архитектурой.

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

Для более четкого представления о ее особенностях необходимо рассмотреть несколько моделей технологии "клиент-сервер", что и будет сделано ниже.

Если предполагается, что проектируемая информационная система (ИС) будет построена по технологии "клиент-сервер", то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер. Иными словами, часть функций прикладной программы (или, проще, приложения) будет реализована в программе-клиенте, другая — в программе-сервере, причем для их взаимодействия будет определен некоторый протокол.

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

Первая группа — это функции ввода и отображения данных.

Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы — открытие счета, перевод денег с одного счета на другой и т.д.).

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

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

В соответствии с этим в любом приложении выделяются следующие логические компоненты:

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

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

Выделяются четыре подхода, реализованные в следующих моделях:

• модель файлового сервера (File Server — FS);
• модель доступа к удаленным данным (Remote Data Access — RDA);
• модель севера базы данных (DataBase Server — DBS);
• модель сервера приложений (Application Server — AS).
  1. Двухуровневая архитектура "клиент-сервер"

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

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

Рисунок 2 – Архитектура «Клиент – сервер»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 1. 1.3 Многоуровневая архитектура "клиент-сервер"

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

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

Сервер приложений - это программное обеспечение, которое является промежуточным пластом между сервером и клиентом.

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

• - Message orientated - яркие представители MQseries и JMS;
• - Object Broker - яркие представители CORBA и DCOM;
• - Component based - яркие представители.NET и EJB.

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

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

• - 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.

Различные модели технологии «Клиент - сервер»

Самой первой основной базовой технологией для локальных сетей была модель файлового сервера (FS). В то время эта технология была весьма распространена среди отечественных разработчиков, использовавших такие системы, как FoxPro, Clipper, Clarion, Paradox и так далее.

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

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

Протокол обмена - это некий набор вызовов, которые обеспечивают приложению вход к файловой системе на файл-сервере.

Положительными сторонами данной технологии являются:

• - простота разработки приложений;
• - удобство администрирования и обновления ПО
• - низкая стоимость оборудования рабочих мест (терминалы или дешевые компьютеры с низкими характеристиками в режиме эмуляции терминала всегда дешевле полноценных ПК).

Но достоинства FS - модели превосходят ее недостатки:

- большая загрузка сети;

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

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

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

Для современных СУБД архитектура «клиент-сервер» стала фактически стандартом. Если предполагается, что проектируемая сетевая технология будет иметь архитектуру «клиент-сервер», то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, то есть часть функций приложений будет реализована в программе-клиенте, другая - в программе-сервере.

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

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

Исходя из этого, выделяются три подхода, каждый из которых реализован в соответствующей модели технологии «Клиент - сервер»:

• - модель доступа к удаленным данным (Remote Date Access - RDA);
• - модель сервера базы данных (DateBase Server - DBS);
• - модель сервера приложений (Application Server - AS).

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

Несмотря на большое распространение, RDA-модель уступает место наиболее технологичной DBS-модели.

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

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

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

Выучив все модели технологии «Клиент - сервер», можно сделать такой вывод: RDA- и DBS-модели, в основе этих двух моделей лежит двухзвенная схема разделения функций. В RDA-модели прикладные функции переданы клиенту, в DBS-модели их исполнение реализовывается через ядро СУБД. В RDA-модели прикладной компонент сливается с компонентом представления, в DBS-модели интегрируется в компонент доступа к ресурсам.

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

Глава 2. Особенности практического применения технологии "клиент-сервер"

2.1 Достоинства и недостатки использования технологии "клиент-сервер"

К достоинствам системы клиент/сервер следует отнести:

1. сильную централизованную защиту;
2. центральное хранилище файлов;
3. возможность совместного использования серверами доступного технического и программного обеспечения;
4. простую управляемость при большом числе пользователей и
5. централизованную организацию, предотвращающую потерю данных на компьютерах.

    Недостатками же этой системы являются:

1. дорогое техническое обеспечение;
2. дорогие серверные операционные системы и клиентские лицензии;
3. кроме того, часто требуется администратор сети.

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

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

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

2.2 Практика использование технологических решений "клиент-сервер" (привести конкретные примеры применения технологии)

Практические архитектуры технологиями. определяет или имеющиеся между и , которые обмена ( ).

Далее двухзвенную , так как в сети, на сетевых , элементы , чаще на двухзвенной . (two-tier, 2-) она из-за трех двумя ( и сервером).

5	архитектура в системах, где на клиентские и в полном , при используя ресурсы – это , что не вызывает приложения и не к ресурсам для части .

компонентов на или сервера основные их в рамках 2- : сервер — представление ; — доступ к данных и ; сервер БД — данных; — удаленное :

6

С и внедрением на баз данных процедур активного БД. В случае прикладного в виде , выполняемых на . Остальная выполняется на . Протокол — диалект SQL. такого : возможно прикладных ; стоимости (TOC, of ownership) за сервера, а не его ; снижение (т.к. передаются не , а хранимых ). недостаток — разработки по сравнению с уровня.

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

Рисунок 1

7

(N-tier)

Итак, архитектуры «» в разделении на несколько , из которых набор . такого выполняться на , выполняя клиентские . Это повысить , и производительность и сети в .

Пользуясь ППП и ПК, на о наличие и в магазине, в данных ( данных представлена на рис. 8), :

• оборотную по товара в за период (. 9)
• остатков в (рис. 10)

	Имя поля	Тип	десятичных
товара Единица за единицу на начало отч. поступившего проданного	Артикул Остаток	Текстовый Денежный Числовой	2

Рис. 8 таблицы

Наименование товара	Цена	Остаток на начало месяца		Поступило		Продано			Остаток на конец месяца
		Кол-во	Сумма	Кол-во	Сумма	Кол-во		Сумма	Кол-во	Сумма
1	2	3	4	5	6	7		8	9	10

Рис. 9 Оборотная ведомость по движению товаров в магазине

Наименование товара	Артикул	Единица измерения	Цена товара	Количество	Сумма
1	2	3	4	5	6

Рис. 10 Ведомость остатков товаров в магазине

Введите текущее значение даты между таблицей и ее значением. По данным таблиц постройте гистограмму с заголовком, названием осей координат и легендой.

Алгоритм решения задания

1. Запустить табличный процессор MS Exсel.
2. Создать книгу с именем «Ведомость».
3. Лист первый переименовать в «Оборотная ведомость».
4. Лист второй переименовать в «Ведомость остатков».
5. Лист третий переименовываем в «Структура данных таблицы товар».
6. На рабочем листе «Структура данных таблицы товар» формируем таблицу «Реестр основных средств по источникам получения» (рис. 11) .

Рис. 11 Структура данных таблицы товар

1. На листе «Оборотная ведомость» формируем таблицу «Оборотная ведомость по движению товара в магазине» (рис. 12)

Рис. 12 Оборотная ведомость по движению товара в магазине

1. На листе «Ведомость остатков» формируем таблицу «Ведомость остатков товаров в магазине» (рис. 13).

Рис. 13 Ведомость остатков товара в магазине

1. Редактируем тип данных в ячейках таблицы «Оборотная ведомость по движению товара в магазине» опираясь на таблицу «Структура данных таблицы товар». Столбцу «Наименование товара» - задаём тип данных текстовый, столбцу «Цена» - задаём тип данных денежный, столбцам «Остаток на начало месяца», «Поступило», «Продано», «Остаток на конец месяца» - задаём тип данных числовой учитывая, что количество десятичных знаков должно быть равно 2 (рис. 14).

Рис. 14 Смена типа данных

1. Редактируем тип данных в ячейках таблицы «Ведомость остатков» опираясь на таблицу «Структура данных таблицы товар». Столбцам «Наименование товара», «Артикул», «Единица измерения» - задаём тип данных текстовый, столбцу «Цена товара» - задаём тип данных денежный, столбцам «Количество», «Сумма» - задаём тип данных числовой учитывая, что количество десятичных знаков должно быть равно 2 (рис. 15) .

Рис. 15 Смена типа данных

1. Введём текущее значение даты между таблицей и её названием. Для этого в ячейках J2 листа «Оборотная ведомость» введём формулу =СЕГОДНЯ() (рис. 16).

Рис. 16 Ввод значения даты

1. Введём текущее значение даты между таблицей и её названием. Для этого в ячейках F2 листа «Ведомость остатков» введём формулу =СЕГОДНЯ() (рис. 17).

Рис. 17 Ввод значения даты

1. Создадим ещё один лист, на котором будем вводить данные. Назовем его «Данные».
2. Построим на листе «Данные» таблицу «Данные для продолжения» (рис. 18) .

Рис. 18 Данные для продолжения

1. Заполним по этим данным таблицы «Оборотная ведомость по движению товара в магазине». Для этого в ячейку В6 запишем формулу, =Данные!D4, в ячейку С6 формулу =Данные!D4, в ячейку D6 формулу =C6*B6. Теми же приёмами воспользуемся для заполнения других ячеек. Кроме ячейки I6, туда поместим формулу =C6+E6-G6 и размножим до I7 (рис. 19) .

Рис. 19 Оборотная ведомость по движению товара в магазине

16. Заполним таблицу «Ведомость остатков товаров в магазине». Для этого будем использовать функцию =ПРОСМОТР(). В ячейку В5 помести формулу =ПРОСМОТР(A5;Данные!A4:A5;Данные!B4:B5). Аналогично заполним остальные ячейки (рис. 20).

Рис. 20 Ведомость остатков товаров в магазине

17. По таблице «Оборотная ведомость по движению товара в магазине», построим гистограмму (рис. 21).

Рис. 22 Гистограмма

Заключение

развивающимся в информационных в годы программного на архитектуры , с сетью и Intranet, на Web- и язык . , распределенные OMG и ODMG в тенденции, и их. Примечательно, что все систем /, включая Sun, IBM, , , встраивают в поддержку КС .

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

Список использованной литературы

1. Л. Калиниченко. Стандарт систем управления объектными базами данных ODMG 93: краткий обзор и оценка состояния. - СУБД, 1, 1996.
2. Д. Брюхов, В. Задорожный, Л. Калиниченко и др. Интероперабельные информационные системы: архитектуры и технологии. - СУБД, 4, 1995.
3. Вудворд Дж. «Технология совместной работы»
4. Волков В.Б. Понятный самоучитель работы в Windows XP, СПб, Питер, 2004

5. 19.701-90 . алгоритмов, , и систем. и правила .

6. , О.Л. Информационные : для ВУЗов / О.Л. , М.В. , И И. Попов, Т.Л. . - 2-е изд. - М.: ФОРУМ: ИНФРА-М, 2009. - 608 с.

7. Информационные технологии: учебник / под ред. В. В. Трофимова - М.: Издательство Юрайт ; ИД Юрайт, 2011 - 624 с.

8. Исаев, Г.Н. Информационные технологии: учеб, пособие / Г.Н. Исаев. - М.: Изд-во «Омега-Л», 2012. - 464 с.

9. Логунова, О С. Человеко-машинное взаимодействие: теория и практика: учеб, пособие / О С. Логунова. - Ростов н/Д.: Феникс, 2006. - 285 с.

10. Смирнова, Г.Н. Проектирование экономических информационных систем: учебник для ВУЗов / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. - 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2007. - 512 с.

11. Советов, Б.Я. Информационные технологии: учебник для вузов / Б.Я. Советов, В.В. Цехановский. - изд. 6-е. - М.: Высш. школа, 2011- 272 с.

Разме