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

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

( @Месяцint)

RETURNS TABLE

AS

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

AS

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 был полностью переопределен.

---