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

Технология клиент-сервер (Архитектура. Компоненты системы SQL Server 2012. Объекты базы данных SQL Server)

Содержание:

ВВЕДЕНИЕ

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

Поэтому, выбранная тема является и ещё долгое время будет являться актуальной.

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

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

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

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

- ввод и отображение данных (взаимодействие с пользователем);

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

- функции управления ресурсами (файловой системой, БД и т.д.)

Что позволяет решить следующие задачи:

- удаленное централизованное хранение данных, что во многом помогает решить проблему целостности и предотвращения избыточности данных;

- разделяемый доступ к данным;

- разделение функций по управлению данными;

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

- защищенность от сбоев и потери информации при помощи системы отката транзакций.

Целью настоящей работы является представление к изучению технологии «клиент – сервер». Для этого буду решены следующие задачи: рассмотрена технология в общем; представлены и изучено создание клиент-серверных приложений на базе SQL Server 2012; рассмотрен и изучен один из аспектов хранения данных и обмена между клиентом и сервером в реализации CMS.

Объект исследования – технология «клиент - сервер».

Предмет исследования – применение технологии «клиент - сервер».

1. Технология клиент-сервер

Клиент-сервер — это вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через компьютерную сеть посредством сетевых протоколов, но их можно расположить также и на одной машине^[3]. Программы — сервера, ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файлов посредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных) или сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями, просмотр web-страниц во всемирной паутине)^[4]. Поскольку одна программа-сервер может выполнять запросы от множества программ-клиентов, ей может потребоваться высокопроизводительная вычислительная машина. Из-за особой роли этой машины в сети, специфики её оборудования и программного обеспечения её так же называют сервером – Рисунок 1.1.

Рисунок 1.1 – Упрощенная схема взаимосвязей в рамках функционирования технологии клиент-сервер

В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер делящие между собой те функции которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных в качестве которого может выступать Microsoft SQL Server Oracle Sybase и т.п.^[5]

Плюсы технологии клиент сервер^[6]:

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

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

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

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

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

- RPC (Remote Procedure Call) удаленный вызов процедур — система интеграции серверов в виде процедур доступных для вызова удаленным пользователем через унифицированный интерфейс. Интерфейс изобретенный Sun Microsystems для своей операционной системы (SunOS Solaris; Unix-система) в настоящее время используется как в большинстве Unix-систем так и в Windows.

- Серверы удаленного доступа. Серверы удаленного доступа через соответствующую клиентскую программу обеспечивают пользователя консольным доступом к удаленной системе. Для обеспечения доступа к командной строке служат серверы telnet RSH SSH.

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

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

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

- Защита пересылаемых данных только при установлении соединения клиента с сервером.

- Надежная система аутентификации администратора системы.

- Подтверждение подлинности источника данных.

- Использование надежных методов криптографии.

- Подтверждение подлинности источника, целостности и конфиденциальности данных.

- Использование сертифицированных средств защиты.

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

2. Создание клиент-серверных приложений

2.1 Архитектура. Компоненты системы SQL Server 2012. Объекты базы данных SQL Server

Итак, программное обеспечение архитектуры «клиент-сервер» состоит из двух частей: программного обеспечения сервера и программного обеспечения пользователя — клиента. Программа-клиент выполняется на компьютере пользователя и посылает запросы к программе-серверу, которая работает на компьютере общего доступа. Основная обработка данных производится мощным сервером, а на компьютер пользователя возвращаются только результаты выполнения запроса. В такой архитектуре сервер называется сервером баз данных^[7].

Широко известными СУБД, используемыми в архитектуре "клиент-сервер", являются Microsoft SQL Server, Oracle, Sybase SQL Server и др. Эти СУБД являются реляционными SQL-серверами баз данных. СУБД архитектуры «клиент-сервер» может включать собственную клиентскую программу. В то же время в качестве клиентов сервера баз данных могут использоваться другие СУБД. Access также может работать в качестве клиента SQL-сервера^[8].

Для взаимосвязи клиентов с сервером разработано специальное программное обеспечение. Широко используемыми интерфейсами таких взаимосвязей являются ODBC и OLE DB. Access предоставляет несколько способов взаимодействия приложения с данными сервера на основе интерфейса ODBC.

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

Интерфейс ODBC состоит из четырех функциональных компонентов, именуемых уровнями ODBC. Благодаря каждому из них достигается гибкость ODBC, позволяющая взаимодействовать любым ODBC-совместимым клиентам и серверам. Между пользователем и данными, которые он хочет получить, процесс проходит четыре уровня интерфейса ODBC: приложение, диспетчер драйверов, драйвер DLL, источник данных^[9].

С версии 2000 Access включает средства создания клиентских приложений Microsoft SQL Server, которые позволяют не только использовать существующие на сервере базы данных, но и создавать новые и взаимодействовать с ними на основе интерфейса OLE DB. OLE DB — это архитектура компонентов базы данных, реализующая эффективный доступ по сети и через Интернет к источникам данных многих типов, в том числе реляционным источникам данных, почтовым файлам, неформатированным текстовым файлам и электронным таблицам. Набор OLE-интерфейсов обеспечивает универсальный доступ к данным различного формата. В архитектуре OLE DB приложения, получающие доступ к данным, называют потребителями данных, например Access или Visual Basic. Программы, обеспечивающие внутренний доступ к данным, называют средствами доступа к базам данных – провайдерами, например, Microsoft OLE DB Provider for Microsoft SQL Server (рис. 2.1) или Microsoft Jet 4.0 OLE DB Provider для доступа к базе данных Microsoft Access внешнего потребителя.

Рисунок 2.1 – Схема взаимодействия проекта Accessи SQL-сервера в сети

При установке Microsoft Office или Microsoft Access автоматически инсталлируются провайдеры OLE DB.

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

Требуемый тип провайдера Microsoft OLE DB Provider for SQL Server выбирается проектом по умолчанию. Эти параметры сохраняются как строка связи с базой данных сервера в проекте Access.

Кроме того, они могут сохраняться в udl-файле Файлы подключения можно использовать просто для организации и управления сведениями, необходимыми для подключения к источникам данных OLE DB. Открывается диалоговое окно Свойства связи с данными (Data Link Properties), выбор типа провайдера Microsoft OLE DB Provider для SQL-сервера выполняется по умолчанию.

Система SQL Server 2012 играет роль платформы данных с возможностью динамической разработки, обширной бизнес-аналитикой, с выходом за пределы реляционной модели, закладывая прочный фундамент, на котором могут строить ИТ инфраструктуру малые, средние и крупные организации^[10]. В состав SQL Server 2012 входят следующие компоненты:

- Служба ядра БД (Database Engine). Основные компоненты БД, уведомлений и репликации. Ядро БД является сердцем SQL Server. Репликация повышает доступность данных, распределяя их по нескольким БД и разделяя нагрузку чтения данных по нескольким выделенным серверам БД.

- Аналитические службы (Analysis Services). Обеспечивают функциональность OLAP (Online Analytical Processing) и анализа данных для приложений бизнес-аналитики. Аналитические службы позволяют организации собирать данные из разных источников, например, реляционных баз данных и обрабатывать их различными способами.

- Службы интеграции (Integration Services). Предназначены для слияния данных из разнородных источников, загрузки данных в хранилища, витрины данных и пр.

- Службы отчетов. Включают диспетчер отчетов и сервер отчетов. Представляют полномасштабную платформу для создания, управления и распространения отчетов. Сервер отчетов построен на стандартных технологиях Microsoft Internet Information Services (IIS) и Microsoft .NET Framework и позволяет использовать для обработки и хранения отчетов сочетание возможностей SQL Server и IIS.

- Service Broker. Ключевая часть БД, обеспечивающая организацию очередей и обмена сообщениями. Очереди используются для упорядочения задач, например, запросов, чтобы они выполнялись по мере высвобождения ресурсов. Сообщения обеспечивают передачу информации от одного приложения БД другому.

Объектами базы данных SQL Server являются таблицы, индексы, представления, хранимые процедуры, триггеры, пользовательские функции^[11].

Таблицы – являются основной формой для сбора информации, содержат все данные в базах данных SQL Server. Каждая таблица представляет собой тип объекта, который имеет смысл для пользователей.

Индекс – структура на диске, связанная с таблицей или представлением, которая ускоряет поиск строк таблицы или представления. Индекс содержит ключи, созданные для одного или нескольких столбцов таблицы или представления. Эти ключи хранятся в виде B-древовидной структуры, что позволяет SQL Server, быстро и эффективно находить строку или строки, связанные с ключевыми индексами. Существуют кластерные и не кластерные индексы.

Представления являются запросами на выборку. Они выполняют извлечение данных из таблиц с помощью инструкции языка SQL SELECT и реализуют одно их основных назначений базы данных – предоставлять информацию пользователю.

Результатом выполнения инструкции SELECT является таблица. Представления – это просто хранящиеся в базе данных SELECT-инструкции. С точки зрения пользователей представление – это таблица, которая не хранится постоянно в базе данных, а формируется в момент обращения к ней.

Хранимая процедура – это сохраненный набор инструкций языка Transact-SQL, выполняемый как единое целое. Хранимая процедура является специальной программой из совместно откомпилированных команд Transact-SQL, сохраняемой в базе данных SQL Server и выполняемой по вызову клиента. В хранимых процедурах могут выполняться любые инструкции Transact-SQL, в том числе инструкции добавления, изменения и удаления данных (INSERT, UPDATE и DELETE). Хранимая процедура может принимать и возвращать параметры.

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

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

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

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

2.2 Этапы разработки клиент-серверных приложений

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

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

Основным инструментом для управления БД и серверами является среда SQL Server Management Studio^[12]. Графический интерфейс этой среды упрощает управление серверами, БД и ресурсами. В этой среде можно создавать базы данных. В выбранной базе данных можно создавать таблицы, представления, хранимые процедуры, функции разных типов. В окне этой среды все объекты представлены в виде дерева. Базы данных сервера, с которыми может работать пользователь, представлены в поддереве объектов SQL Server в папке «Базы данных». Папка «Безопасность» содержит список пользователей, имеющих доступ к серверу.

Разработка проекта начинается с создания на сервере БД «Кадры». В окне обозревателя объектов выполним команду «Создать базу данных».

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

Новые таблицы создаются и изменяются в среде SQL Server Management Studio при помощи инструкций CREATE TABLE и ALTER TABLE. Для создания таблицы в окне БД выполним команду «Создать таблицу».(Рисунок 2.2 - Вид окна «Создание таблицы»)

Рисунок 2.2 – Вид окна «Создание таблицы»

Для создания таблицы «Сотрудники» введем следующую инструкцию:

CREATE TABLE [dbo].[Сотрудники](

[ФИО] [nchar](30) NULL,

[Таб_ном] [int] NOT NULL PRIMARY KEY,

[Ном_подразд] [int] NOT NULL FOREIGN KEY

REFERENCES Подразделения(Ном_подразд) ON DELETE

CASCADE,

[Должность] [nchar](30) NULL,

[Оклад] [money] NULL,

Ограничение FOREIGN KEY устанавливает связи между таблицами и обеспечивает ссылочную целостность. Внешний ключ одной таблицы указывает на потенциальный ключ другой. В таблицу с внешним ключом нельзя добавить строку при отсутствии соответствующего потенциального ключа. Предложение ON DELETE задает действия, производимые при попытке удаления строки, на которую ссылается внешний ключ. CASCADE– все строки с внешним ключом, ссылающимся на удаляемую строку, также удаляются. Ключевое слово REFERENCES указывает, что любое значение в столбце Ном_подразд должно находится в столбце Ном_подразд таблицы «Подразделение».

В нашем примере столбец Ном_подразд таблицы «Сотрудники» внешний ключ. Внешний ключ – это столбец одной таблицы, значения которого совпадают со значениями столбца, являющегося первичным ключом другой таблицы.

Проект Access является клиентским приложением, которое подключается к Microsoft SQL Server, расположенному в сети или на локальном компьютере. Проект Access, реализуя архитектуру "клиент-сервер", функционирует в среде Access и работает только с данными базы на SQL-сервере. Из проекта можно не только получить доступ к базе данных сервера, но и создать новую базу и ее объекты. Проект Access оснащен мощными графическими средствами, как для разработки клиентского приложения, так и базы данных на сервере. Проект Access хранится в файле типа adp (Access Data Project — проект доступа к данным). Он содержит только те объекты, которые составляют приложение: формы, отчеты, макросы и модули. В отличие от базы данных Microsoft Access проект не содержит данных или описаний структур объектов базы данных: таблицы, схемы базы данных, представления, хранимые процедуры и скалярные и табличные функции — объекты базы данных SQL-сервера — только отображаются в проекте Access.

При создании проекта «Отдел кадров» в MS Access выбирается вариант подключения к существующей на сервере базе данных. Таблицы заполняются данными.

Для создания проекта Access, работающего с базой данных, размещенной на Microsoft SQL-сервере, необходимо на открывшемся после запуска Access окне в области «Новая база данных» щелкнуть на значке открытой папки, размещенном справа от поля «Имя файла»: откроется окно «Файл новой базы», в котором нужно выбрать тип файла «Проекты Microsoft Office Access (*.adp)», задать имя и папку для сохранения файла создаваемого проекта. Для завершения работы в этом окне нужно нажать кнопку OK, а в области «Новая база данных» нажать кнопку «Создать». Открывается окно, в котором выбирается один из двух вариантов: подключение к существующей на сервере базе данных или создание новой базы данных на сервере наряду с созданием проекта. Щелчком на кнопке «Да» начинается подключение к существующей на сервере базе данных. При этом открывается окно подключения к серверу «Свойства канала передачи данных» (рис. 2.3), в котором, прежде всего, указывается имя сервера и способ регистрации пользователя на нем.

Рисунок 2.3 – Окно выбора параметров подключения к базе данных сервера

Далее создаются запросы для работы с БД. В проекте поддерживается работа с тремя основными типами запросов, сохраняемыми в базе данных на сервере: представления, хранимые процедуры, пользовательские функции. После создания они появляются в области навигации проекта. Из проекта их можно открывать, выполнять, но вносить изменения можно только на сервере.

Опишем создание встроенной функции, возвращающей табличное значение. Создадим запрос, позволяющий получить сведения о стаже работы сотрудника данного предприятия. В запрос включим поля: ФИО, Таб_номер, Дата_поступ, Стаж, где Стаж – вычисляемое поле. Стаж работы вычисляется по формуле:

iif((MONTH(GetDate())-

MONTH(Анкета.Дата_поступ))>=0,Year(GetDate())-

Year(Анкета.Дата_поступ),Year(GetDate())-

Year(Анкета.Дата_поступ)-1)

Функция GetDate() возвращает текущую дату, функция MONTH – номер месяца, Year – год.

Для создания встроенной функции, возвращающей табличное значение, в среде SQL Server Management Studio в окне обозревателя объектов выберем базу данных «Кадры», откроем узел «Программирование», затем «Функции», щелкнем правой кнопкой узел «Функции, возвращающие табличное значение». В контекстном меню выберем команду «Создать встроенную функцию, возвращающую табличное значение». Указывается имя создаваемой функции (Стаж Работы), параметры не передаются. В предложении RETURNS задается ключевое слово TABLE, указывающее тип возвращаемого значения. Столбцы таблицы, возвращаемые такой функцией, определяются инструкцией SELECT. Тело функции представлено единственной командой RETURN, после выполнения которой работа функции завершается.

CREATE FUNCTION Стаж Работы()

RETURNS TABLE

RETURN

(

SELECT Анкета.ФИО,Анкета.Таб_ном, Анкета.Дата_поступ,

iif((MONTH(GetDate())-

MONTH(Анкета.Дата_поступ))>=0,Year(GetDate())-

Year(Анкета.Дата_поступ),Year(GetDate())-

Year(Анкета.Дата_поступ)-1) ASСтаж

FROMdbo.Анкета

)

Сохраним и выполним этот запрос. Если выполнение пройдет успешно, название функции появится в области навигации проекта. Откроем функцию в режиме таблицы. После сохранения инструкция создания встроенной функции CREATE FUNCTION меняется на инструкцию ALTER FUNCTION– инструкцию изменения встроенной функции.

Как пример опишем создание встроенной функции «Отпуск_за_данный_месяц». В функцию передается параметр – номер месяца и возвращается список сотрудников, уходящих в отпуск в данном месяце. Рисунок 2.4 - Результат функции Отпуск_за_данный_месяц.

CREATE FUNCTION Отпуск_за_данный_месяц

( @Месяцint)

RETURNS TABLE

RETURN

(

SELECT dbo.Сотрудники.ФИО, dbo.Сотрудники.Таб_ном,

dbo.Сотрудники.Ном_подразд,

dbo.Сотрудники.Должность,

dbo.График_отпусков.Начало_отпуска,

dbo.График_отпусков.Кол_дней

FROM dbo.Сотрудники INNER JOIN

dbo.График_отпусков ON dbo.Сотрудники.Таб_ном =

dbo.График_отпусков.Таб_ном

WHERE MONTH(dbo.График_отпусков.Начало_отпуска) = @Месяц

Рисунок 2.4 – Результат функции Отпуск_за_данный_месяц

Теперь опишем создание хранимой процедуры, возвращающей «Список сотрудников данного подразделения». Для создания хранимой процедуры в окне обозревателя объектов выберем базу данных «Кадры», откроем узел «Программирование», щелкнем правой кнопкой узел «Хранимые процедуры». В контекстном меню выберем команду «Создать хранимую процедуру». Резудьтат процедуры – рис.2.5.

В процедуру передается параметр Номер_подразд.

CREATE PROCEDURE СписокСотрудников

@Номер_подразд int

BEGIN

SELECT dbo. Сотрудники.ФИО, dbo. Сотрудники. Таб_ном,

dbo. Сотрудники. Должность, dbo.Сотрудники. Оклад, dbo.

Анкета.Адрес, dbo.Анкета.Телефон,

dbo. Сотрудники.Ном_подразд

FROM dbo. Сотрудники INNER JOIN

dbo.Анкета ON dbo. Сотрудники. Таб_ном = dbo.

Анкета.Таб_номер

WHERE (Сотрудники. Ном_подразд = @Номер_подразд)

ORDER BYСотрудники.ФИО

END

Рисунок 2.5 – Результат процедуры Список сотрудников данного подразделения

Создадим главную форму управления приложением в виде формы с вкладками (рис. 2.6).

Рисунок 2.6 – Вид одной из вкладок главной формы управления приложением

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

Для того чтобы форма открывалась сразу после открытия приложения создадим автоматически запускающийся при этом макрос AutoExec. В макрос включается команда «Открыть Форму» с именем формы «Отдел кадров».

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

Выполнить перенос БД с локального сервера на сетевой можно разными способами, например, выполнив восстановление БД из резервной копии или используя возможности мастера копирования баз данных и т.д.

Рассмотрим первый способ. Первоначально действия производятся на локальном SQL-сервере, с которого осуществляется перенос данных. В среде SQL Server Management Studio в списке баз данных выбираем базу данных «Кадры». Открываем контекстное меню, выбираем пункт «Задачи» и в выпадающем меню выбираем пункт «Создать резервную копию». Резервную копию будем создавать на диске.

Для выбора устройства, куда будет производиться копирование, нажимаем кнопку «Добавить». В открывшемся окне выбираем нужный диск и вводим имя создаваемой копии (рис. 2.7).

Рисунок 2.7 – Вид одной из вкладок главной формы управления приложением

Нажимаем «ОК». При успешном завершении копирования появляется сообщение: «Резервное копирование базы данных «Кадры» успешно завершено».

Дальнейшие действия производятся на сетевом SQL-сервере, на который мы переносим данные.

Сетевой SQL Server 2012 работает под управлением Windows Server 2008. В Windows Server 2008 запускаем утилиту SQL Server Management Studio . В среде MS SQL Server Management Studio открываем контекстное меню на пункте «Базы данных» и выбираем пункт «Восстановить базу данных». В открывшемся окне указываем устройство, с которого будет производиться восстановление базы данных. Нажимаем кнопку с тремя точками и в открывшемся окне нажимаем кнопку «Добавить». Указываем путь к *.bak-файлу резервной копии базы данных «Кадры». После всех настроек нажимаем кнопку «ОК». После удачного восстановления БД системный администратор для работника отдела кадров, отвечающего за работу с базой данных, в домене Windows создает учетную запись. Затем создается имя входа и связывается с этой учетной записью. Определяются роли и разрешения на доступ для данного имени входа. Пользователь, обладающий с данной учетной записью, выбирается в качестве владельца базы данных «Кадры».

Система безопасности SQL Server строится на основе двух концепций: аутентификации и авторизации^[13]. Системный администратор, отвечающий за безопасность SQL Server, создает для каждого пользователя отдельный объект login. Этот объект содержит имя учетной записи пользователя SQL Server, его пароль, полное имя и другие атрибуты, предназначенные для управления доступом к базам данных SQL Server.

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

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

3. Хранение данных и обмен между клиентом и сервером в реализации CMS

3.1. Архитектурные особенности построения системы

Представим и рассмотрим механизм хранения данных в формате XML на серверной стороне и механизм клиент-серверного обмена в разработке CMS с механизмом визуального создания и редактирования документов с применением объектно-ориентированного подхода. Для этого, построим некую модель клиент-серверного взаимодействия и хранения шаблонов для реализации CMS с поддержкой визуального редактирования. Такая модель может использоваться как контейнер для модулей, надстраиваемых веб-приложений (например, при реализации вебинар-платформы или сервисов потокового вещания с применением HTML5 и CSS3).

Основные положения архитектуры заключаются в применении концепции объектно-ориентированного проектирования к иерархии документов. Веб-документы генерируются приложением (PHP-скриптом), но благодаря ЧПУ («человек-понятный URL») для посетителя сайта структура ресурса выглядит как набор директорий и файлов^[14].

Смысл концепции заключается в том, что и для редактора/администратора структура также предстает в виде «виртуальной файловой системы», где в качестве директории выступает некий набор элементов, который характеризует не только принадлежность вложенных документов/файлов и директорий данной директории, но и определяет внешний вид и структуру дочерних элементов^[15].

Фактически элемент «директория», называемый нами как «раздел», содержит HTML и CSS-шаблон, который хранится во внутреннем представлении системы. Каждая дочерняя директория и каждый дочерний документ может (и по умолчанию) наследует свойства родительского раздела, аналогично как наследуемый класс в ООП наследует свойства и методы родительского класса. Аналогично же ООП в нашем случае свойства могут быть переопределены, виртуализированы, добавлены новые для дочернего документа.

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

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

Для возможности управления у CMS также должно присутствовать два режима работы: обычный и административный. Разница с существующими приложениями заключается в том, что административный режим отображает документ также, как и в режиме просмотра, но дополнительно появляется панель инструментов, позволяющих править документы в режиме WYSIWYG, а также управлять вложенностью/наследуемость.

Наиболее интересный пример: создание нового пункта в меню не только добавляет элемент «ссылка», но и создает связанный дочерний документ. Нет потребности добавлять документ отдельно, и указывать на него ссылку отдельно, что делает редактирование значительно user friendly.

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

Для упрощения назовем рассматриваемую нами систему Dynamic View Generator (DVG) см. Рисунок 3.1. Наша система предназначена для удобной генерации HTML страниц с использованием XML для внутреннего представления и наследования. Самая большая структурная часть именуется представлением (view). Представление есть ничто иное как XML документ, хранимый в БД и имеющий свой уникальный для системы идентификатор ViewID (id).

Тело каждого представления состоит из элементов (elements). Каждый элемент имеет свой ElementID (eid), который уникален в рамках своего представления.

Рисунок 3.1 – Схема элементов системы

В листинге 1 (См. Приложение 1) предоставлен минимально требуемый XML код представления. Тэг view корневой и содержит все остальные тэги. В том случае, если это корневое представление, оно обязано содержать маркер будущего элемента – атрибут next-eid, который содержит число – ElementID следующего добавляемого элемента.

После каждого добавления элемента должен инкрементироваться.

Тэг content содержит все наши элементы, которые в дальнейшем будут отображаться в элементе body результирующего HTML.

В листинге 2 (См. Приложение 1) мы видим пример самого простого представления.

Каждый элемент имеет свой атрибут eid, содержащий уникальный для этого представления ElementID.

Наследование представлений. Представление (View) может переопределять ранее созданное представление, то есть иметь родителя (parent). Одно представление может иметь только одного родителя, но при этом количество детей не ограничено.

Так же представление может переопределять представление, которое в свое время то же переопределяет представление.

На схеме – Рисунок 3.2. - у представления с ViewID1 наследников нет, а у представления с ViewID2 целых два наследника – ViewID3 и ViewID4. ViewID4 не имеет наследников, а представление с ViewID3 имеет одного наследника.

Рисунок 3.2 – Схема наследования представлений

Самая главная цель наследования – это то, что наследники получают все элементы (elements) своих предков.

К примеру, ViewID5 с нашей схемы уже имеет в себе все элементы представлений View2 и View3, и, если изменить элемент в представлении View2, это незамедлительно отобразиться на его детях.

Но просто наследование было бы не столь интересно, поэтому наследники могут переопределять либо весь элемент родителя, либо только его атрибуты, либо «удалить» его у себя.

Переопределять можно не только атрибуты и содержимое, но и сам элемент.

К примеру, в родителе это был p, в ребенке стал span. Главное, чтобы сохранился ElementID. При добавлении нового элемента в ребенка, в его родителе инкрементироваться маркер будущего элемента next-eid.

При переопределении элемента в ребенке, никаких действий с маркером не происходит.

В листинге 3 (Приложение 1) мы видим представление, которое наследует представление из листинга 2. Оно обязано иметь атрибут parent и не иметь маркера будущего элемента (атрибута next-eid), так как next-id у него тоже наследуется от родителя. Элемент img с ElementID 6 из листинга 2 здесь отсутствует, а значит он без изменений будет взят из родителя. Элемент b с ElementID 4 из листинга 2 тоже здесь отсутствует, но он совсем пропадет из нашего представления, так как его контейнер – элемент 3 был полностью переопределен.

Символ управления наследованием. Из приведенных листингов видно, что в eid перед каждым ElementID есть символ #. Это символ, управляющий наследованием. Есть несколько возможных вариантов управления наследованием, за каждый из которых отвечает своей символ перед ElementID в атрибуте eid:

1. Отсутствие управляющего символа либо символ # – жесткое (полное) переопределение элемента. Полностью переопределяется как его атрибуты, так и его содержимое. Если в родителе присутствовали атрибуты у элемента, а у наследника их нет, считается что их нет. Если в родителе присутствовали внутренние элементы у элемента, а у наследника их нет, считается что их нет.

2. Символ @ – мягкое переопределение элемента. Если отсутствуют все атрибуты либо только в части, недостающие атрибуты берутся из родительского представления. Если полностью отсутствует содержимое элемента, оно перейдет из родителя. Для возможности мягкого переопределение необходимо, чтобы в элементе отсутствовали текстовые элементы, не входящие в другие элементы, так как в таком случае порядок следования и переопределения элементов будет непредсказуем. Для решения данной проблемы следует ввести дополнительный элемент для описания простого текста.

Маркер будущего элемента. Подведем итоги с маркером будущего элемента – атрибутом next-eid, который содержит число – ElementID следующего добавляемого элемента. После каждого добавления элемента должен инкрементироваться.

1. Маркер храниться в атрибуте next-eid тэга view корневого представления.

2. У представлений, наследующих другие представления такого атрибута нет – они наследуют маркер у корневого родителя.

3. С маркером возможна всего одна операция – инкрементация. Он не может уменьшаться.

4. При добавлении нового элемента в дочерний элемент, родительский маркер так же инкрементироваться. Это необходимо для корректного наследования элементов.

5. Он всегда больше самого большого ElementID данного представления как минимум на единицу. В двух ситуациях он может быть больше, чем на единицу: если элемент с максимальным ID был удален из представления либо если элемент был добавлен в ребенка этого представления.

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

Любой элемент может содержать в себе:

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

2. Любое количество простого текста, но при этом не может содержать другие элементы.

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

Виды элементов. Доступны все элементы, которые доступны в HTML в тэге body, но поведение некоторых скорректировано. Так же добавлены новые элементы со своим поведением.

1. Null – «несуществующий тэг». Необходим, чтобы при наследовании удалить родительский элемент.

2. Parent – «полностью наследуемый тэг». Имеет только один атрибут – eid – и полностью наследует элемент без родителя без изменений.

3. Include – «тэг-включение». Благодаря этому тэгу можно полностью вставить одно представление в другое. Содержит в себе ViewID.

4. Textelement – «текстовый элемент». Может содержать в себе только текст. Не может содержать другие элементы.

5. A – «ссылка». Тот же тэг из HTML, но с небольшим отличием. Вместо атрибута href содержит атрибут href-view, который должен содержать в себе ViewID.

3.2. Клиент-серверное взаимодействие

В то время, как получение документа в режиме чтения, по большей части на прикладном уровне модели OSI/ISO выглядит, как запрос контента методом GET с указанием конкретного ресурса (имитирующего путь к документу в файловой директории в нашей «виртуальной файловой системе), редактирование представляет более сложный процесс в виде распределенного клиент-серверного приложения. На стороне сервера приложение представлено PHP-скриптом на базе фреймворка Laravel, на клиенте JavaScript-приложение, напрямую работающее с деревом DOM, ведущее историю изменений в рамках текущей сессии, получающий и отправляющий на сервер данные об изменениях^[16].

Механизм изменений представлен REST-API с XML в качестве формата взаимодействия на прикладном уровне, таким образом HTTP решает задачи транспорта. Такой подход не вполне укладывается в модель OSI/ISO, так как прикладной уровень сам состоит из двух подуровней: собственно механизм взаимодействия клиент-сервер, и сам протокол HTTP (а в случае шифрованного соединения HTTPS, фактически он и будет использоваться, в особенности в режиме редактирования).

Этапы осуществления взаимодействия. Упрощенно механизм обмена можно описать следующим способом: клиент (редактор) получает от сервера набор XML представления страниц, отрисовывает по ним DOM-дерево, и после визуального редактирования (WYSIWYG) данные в формате XML представления отправляются обратно на сервер^[17].

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

В случае, если создается новый документ, клиент запрашивает у сервера данные о родительской странице, для использования в качестве шаблона (Рис. 3.3 – Приложение 2). Затем, после создания на ее основе новой страницы, данные отправляются на сервер и сохраняются в БД.

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

Если посетитель впервые запрашивает сохраненную в редакторе страницу, на серверной стороне происходит генерация документа – компиляция из внутреннего формата XML файлов HTML и CSS (и при необходимости js). Клиенту уже отправляются сгенерированные статичные файлы (рис.3.5, Блок 3) – Приложение 2). При последующих обращениях посетители будут получать закешированные сгенерированные файлы (рис.3.5, Блок 4) – Приложение 2).

Так как это статичное содержимое, CMS будет работать быстро и с возможность обеспечивать работу при высоких нагрузках при использовании вебсервера Nginx.

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

ЗАКЛЮЧЕНИЕ

Проработав теоретические и практические материалы научных статей, учебных пособий, научно-популярные публикации в сети Интернет, мы пришли к следующим выводам:

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

Сеть Интернет построена по технологии «клиент-сервер».

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

Клиенты — это компьютеры или программы, которые используют то, что предлагают серверы, например веб-браузеры или почтовые клиенты.

Основные виды технологии распределенной обработки данных:

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

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

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

4. Технология «клиент-сервер», ориентированная на изменения данных в одном месте. Удаленные серверы не связаны между собой сетью ЭВМ, т.е. отсутствует сервер-координатор. Клиент может изменять данные только в своей локальной базе. Возникает опасность «смертельных объятий», т.е. ситуация, когда задача А ждет записи, заблокированные задачей В, а задача В ждет записи, заблокированные задачей А. Поэтому распределенная СУБД должна иметь средство контроля совпадений противоречивых запросов. Распределение данных реализует метод расчленения; реализуется обработка распределенной транзакции.

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

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

6. Технология «клиент-сервер», ориентированная на сетевую СУБД. Обеспечивает стратегию расчленения и дублирования. Позволяет получить более быстрый доступ к данным. Распределенная СУБД обеспечивает независимость клиента от места размещения сервера, глобальную оптимизацию, распределенный контроль целостности базы, распределенное административное управление.

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

Применительно к CMS используется обычно двух-трёхзвенная архитектура клиент/сервер. Например, трехзвенная архитектура разбивает процесс обработки данных между клиентом, сервером приложений и хранилищем данных. В отличие от традиционной двухзвенной архитектуры здесь присутствует сервер приложений как промежуточное звено между клиентом и хранилищем данных.

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

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

Преимущества технологии «клиент-сервер»:

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

- добавление сервера или рабочей станции повышает общую мощность системы;

- пользователь имеет большой выбор платформ;

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

Недостатки технологии «клиент-сервер»:

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

- поддержка работы данной системы требует отдельного специалиста — системного администратора;

- высокая стоимость оборудования.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Абдуллаева Н.И. Распределённая система с многофункциональной клиентской частью / Н.И. Абдуллаева // SCIENCE TIME, Номер: 10 (34) Год: 2016 Страницы: 8-13
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №4: Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5511?page=1 (доступ на 18.04.2018)
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №4: Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5511?page=2 (доступ на 18.04.2018)
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №5: Базовые объектные архитектуры распределенных систем. Технологии .NET, (D)COM+, CORBA, EJB // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5513?page=2 (доступ на 18.04.2018)
Исаев Е.А. Использование трехзвенной архитектуры "клиент-сервер" в современных системах обработки информации / Е.А. Исаев, П.А. Тарасов, В.В. Корнилов, Г.В. Детков // Известия института инженерной физики, Том: 3 Номер: 37 Год: 2015 Страницы: 38-43
Лисьев Г.А. Программное обеспечение компьютерных сетей и web-серверов. Учебное пособие / Г.А. Лисьев, П.Ю. Романов, Ю.И. Аскерко. М.: Инфра-М, 2018г. – 145с
Маркин Е.И. Разработка web-приложения с использованием архитектуры "клиент-сервер" / Е.И. Маркин, К.М. Рябова, Е.А. Артюшина // Международный студенческий научный вестник, Номер: 3-1 Год: 2016 Страницы: 84-86
Медведев Ю.С. Проектирование интерактивных web-приложений / Ю.С. Медведев, В.В. Терехов // Современные проблемы науки и образования, Номер: 1-1 Год: 2015 Страницы: 43
Минаси Марк Windows Server 2012 R2. Полное руководство. Том 1: Установка и конфигурирование сервера, сети, DNS, Active Directory и общего доступа к данным / Минаси Марк, Грин Кевин, Бус Кристиан. М: Диалектика / Вильямс, 2015г. – 960с
Минаси Марк Windows Server 2012 R2. Том 2: Дистанционное администрирование, установка среды с несколькими доменами, виртуализация, мониторинг и обслуживание сервера. Полное руководство / Минаси Марк, Грин Кевин, Бус Кристиан. М: Диалектика / Вильямс, 2018г. – 864с
Нестеров Г.Д. Трехзвенная клиент-серверная информационная система по конфигурированию баз данных // Политематический сетевой электронный научный журнал кубанского государственного аграрного университета, Номер: 110 Год: 2015 Страницы: 308-317
Николаев В.В. Особенности реализации домена с тонкими клиентами на базе Microsoft Windows Server 2012 R2 // Технические науки - от теории к практике, Номер: 57 Год: 2016 Страницы: 70-77
Николаев В.Н. Метод и устройство управления информационно-вычислительными ресурсами вида "клиент-сервер" / В.Н. Николаев // Известия юго-западного государственного университета. серия: управление, вычислительная техника, информатика. медицинское приборостроение, Номер: 1 Год: 2013 Страницы: 208-211
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г. - 536с
Основы работы в Dreamweaver. Урок №5: Перемещение данных между страницами // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/ courses/1097/149/lecture/4129?page=1 (доступ на 21.04.2018)
Прибылов А.Ю. Структура баз данных с использованием веб-интерфейса / А.Ю. Прибылов // Информатика и прикладная математика: межвузовский сборник научных трудов, Номер: 21 Год: 2015 Страницы: 84-87
Проектирование информационных систем. Лекция 1: Основные понятия технологии проектирования информационных систем (ИС) // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/professional_skill_ improvements/1901/courses/55/lecture/1618?page=3 (доступ на 17.04.2018)
Сычев А.В. Web-технологии / А.В. Сычев / Режим доступа: http://window.edu.ru/resource/423/61423 (доступ на 20.04.2018)
Тарханова О.В. Системы "клиент-сервер" для автоматизации процессов взаимодествия в локальной сети / О.В. Тарханова // Научный альманах, Номер: 2-2 (28) Год: 2017 Страницы: 205-208
Тимошенко А.И. Клиент-серверные сетевые видеоигры. проблема синхронизации по времени // Актуальные научные исследования в современном мире, Номер: 7-1 (15) Год: 2016 Страницы: 42-47
Трофимов В.В. Синхронизация списков данных в клиент-серверных системах / В.В. Трофимов, Д.В. Завьялов // Известия волгоградского государственного технического университета, Номер: 6 (163) Год: 2015 Страницы: 87-90
Федоров С.В. Клиент-серверные расчеты по e-mail / С.В. Федоров // Прикладная математика и фундаментальная информатика, Номер: 3 Год: 2016 Страницы: 203-207

ПРИЛОЖЕНИЕ 1

<?xml version="1.0" encoding="UTF8" ?>

</content>

</view>

Листинг 1 - Минимально требуемый код представления

<?xml version="1.0" encoding="UTF8" ?>

<h2 eid="5">Приветствую, мир!</h2>

<b eid="4">Consectetur</b>

</p>

</div>

</content>

</view>

Листинг 2 - Пример представления с контентом

<?xml version="1.0" encoding="UTF8" ?>

<h2 eid="#5">О нашем сайте</h2>

Ab aperiam architecto beatae eligendi hic sit.

</span>

</div>

</content>

</view>

Листинг 3 - Пример представления – наследника

ПРИЛОЖЕНИЕ 2

Рисунок 3.3 - Механизм обмена в случае создания новой дочерней страницы

Рисунок 3.4 - Механизм обмена для редактирования страницы

Рисунок 3.5 - Механизм обмена при запросе страниц посетителем: 3) первый запрос, 4) последующие

Тарханова О.В. Системы "клиент-сервер" для автоматизации процессов взаимодействия в локальной сети / О.В. Тарханова // Научный альманах, Номер: 2-2 (28) Год: 2017 с.206 ↑
Николаев В.Н. Метод и устройство управления информационно-вычислительными ресурсами вида "клиент-сервер" / В.Н. Николаев // Известия юго-западного государственного университета. серия: управление, вычислительная техника, информатика. медицинское приборостроение, Номер: 1 Год: 2013 с.208 ↑
Нестеров Г.Д. Трехзвенная клиент-серверная информационная система по конфигурированию баз данных // Политематический сетевой электронный научный журнал кубанского государственного аграрного университета, Номер: 110 Год: 2015 с.309 ↑
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №4: Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5511?page=2 (доступ на 18.04.2018) ↑
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г. ↑
Исаев Е.А. Использование трехзвенной архитектуры "клиент-сервер" в современных системах обработки информации / Е.А. Исаев, П.А. Тарасов, В.В. Корнилов, Г.В. Детков // Известия института инженерной физики, Том: 3 Номер: 37 Год: 2015 с: 38-43 ↑
Николаев В.Н. Метод и устройство управления информационно-вычислительными ресурсами вида "клиент-сервер" / В.Н. Николаев // Известия юго-западного государственного университета. серия: управление, вычислительная техника, информатика. медицинское приборостроение, Номер: 1 Год: 2013 с 208-211 ↑
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г ↑
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г. ↑
Минаси Марк Windows Server 2012 R2. Полное руководство. Том 1: Установка и конфигурирование сервера, сети, DNS, Active Directory и общего доступа к данным / Минаси Марк, Грин Кевин, Бус Кристиан. М: Диалектика / Вильямс, 2015г ↑
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №5: Базовые объектные архитектуры распределенных систем. Технологии .NET, (D)COM+, CORBA, EJB // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5513?page=2 (доступ на 18.04.2018) ↑
Минаси Марк Windows Server 2012 R2. Полное руководство. Том 1: Установка и конфигурирование сервера, сети, DNS, Active Directory и общего доступа к данным / Минаси Марк, Грин Кевин, Бус Кристиан. М: Диалектика / Вильямс, 2015 ↑
Минаси Марк Windows Server 2012 R2. Полное руководство. Том 1: Установка и конфигурирование сервера, сети, DNS, Active Directory и общего доступа к данным / Минаси Марк, Грин Кевин, Бус Кристиан. М: Диалектика / Вильямс, 2015 ↑
Сычев А.В. Web-технологии / А.В. Сычев / Режим доступа: http://window.edu.ru/resource/423/61423 (доступ на 20.04.2018) ↑
Основы работы в Dreamweaver. Урок №5: Перемещение данных между страницами // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/ courses/1097/149/lecture/4129?page=1 (доступ на 21.04.2018) ↑
Маркин Е.И. Разработка web-приложения с использованием архитектуры "клиент-сервер" / Е.И. Маркин, К.М. Рябова, Е.А. Артюшина // Международный студенческий научный вестник, Номер: 3-1 Год: 2016 с.85 ↑
Основы работы в Dreamweaver. Урок №5: Перемещение данных между страницами // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/ courses/1097/149/lecture/4129?page=1 (доступ на 21.04.2018) ↑