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

Все данные из окна можно скопировать, нажав кнопку с соответствующим изображением.

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

Пользователи и права доступа

Данные, хранимые в базе данных секретны, поэтому требуют введения определённой политики безопасности.

Доступ к базе данных могут иметь обладатели должностей:

• сотрудник СПТЗ

• телемеханик

Сотрудник СПТЗ может читать и изменять данные. Телемеханик может только читать, и не все данные.

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

В базе данных проекта было создано две роли:

• db_RequestExecuter (разрешён доступ к процедурам, участвующим в вводе данных по заявке)

• db_SignalsReader (разрешён доступ к процедурам выборки из БД, кроме GetRequestOnSignalFields)

Далее были созданы два пользователя:

• SPTZAdmin – роли db_RequestExecuter и db_SignalsReader

• Telemech – роль db_SignalsReader

Для определения прав доступа из клиентского приложения была написана специальная процедура:

CREATE PROC KnowMyRights

AS

IF (IS_MEMBER('db_RequestExecuter')=1 AND

IS_MEMBER('db_SignalsReader')=1)

RETURN 1

ELSE IF IS_MEMBER('db_SignalsReader')=1

RETURN 2

ELSE

RETURN 0

Эта процедура доступна обладателю любой роли.

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

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

ЗАКЛЮЧЕНИЕ

Итак, разработка физической модели базы данных завершена. Цель достигнута.

В ходе выполнения данного курсового проекта были пройдены все этапы RUP кроме внедрения и эксплуатации. После выбора в качестве средства разработки SQL Server 2005 для поддержки целостности базы данных были установлены соответствующие ограничения, написаны триггеры. Для осуществления бизнес-логики, поддержки бизнес-процессов и формирования выходных форм написаны хранимые процедуры. Анализ входной документации позволил правильно создать входные формы для управления данными системы.

За год разработки проделана большая работа и как результат – работоспособная система.

СПИСОК ЛИТЕРАТУРЫ

1. Хендерсон К. Профессиональное руководство по Transact-SQL.-М., 2006

2. Коннолли Томас, Бегг Каролин. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 3-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 1440 с.: ил. – Парал. тит. англ.;

3. Оутей М., Конте П. SQL Server 2000. – СПб., 200

4. Николаева Н.А. Язык структурированных запросов. Лабораторные работы: учебное пособие / Н.А. Николаева, Т.Ю. Калинина. – Ухта: УГТУ, 2006. – 124 с. ил.

ПРИЛОЖЕНИЕ 1

ПРИЛОЖЕНИЕ 2.1 DFD контекстного уроня

ПРИЛОЖЕНИЕ 2.2 DFD 1-го уровня

ПРИЛОЖЕНИЕ 4. Данные по характеристика сигналов заданного ПЛК

Представляет собой файл электронной таблицы Microsoft Office Excel, состоящий из 4-х листов, оформленного по следующему шаблону:

Лист ТС

Наименование информации	Тип данных	Адрес МЭК		Примечание
		адрес	бит
Телесигнализация

Лист ТУ

Наименование информации	Тип данных	Адрес МЭК		Примечание
		адрес	бит
Телесигнализация

Лист ТИ

Наименование информации	Тип данных	Адрес МЭК	Инж. ранги		Физ. Ранги			Примечание
Телерегулирование

Лист ТР

Наименование информации	Тип данных	Адрес МЭК	Инж. ранги		Физ. Ранги			Примечание
Телерегулирование