Смекни!
smekni.com

Разработка физической модели базы данных "Учёт характеристик сигналов телемеханики" (стр. 3 из 4)

CREATE PROC FetchtTITRSignalsOnPLC

@NameRNU VARCHAR(50),

@NumberPLC INT,

@isTISignal BIT

AS

DECLARE @ID_PLC INT

exec @ID_PLC = FindPLC @NameRNU, @NumberPLC, 1

IF @ID_PLC = 0 RETURN

SELECT NameSignal [Наименование сигнала], NameDataType

[Тип данных], MEKAdress [Адрес МЭК], MaxEnginGrade

[Max инж. ранг], MinEnginGrade [Min инж. ранг],

MaxPhysicGrade [Max физ. ранг], MinPhysicGrade

[Min физ. ранг], Comment [Примечания]

FROM (SELECT *

FROM TITRSignals s

WHERE s.ID_PLC = @ID_PLC AND

isDeleted != 1 AND isTISignal = @isTISignal) s

INNER JOIN DataTypes d

ON s.ID_DataType = d.ID_DataType

ORDER BY MEKAdress ASC

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

ALTER PROCEDURE [dbo].[GetRequestOnSignalFields]

@NameRNU VARCHAR(50),

@NumberPLC INT,

@MEKAdress SMALLINT,

@Prefix CHAR(2) OUT,

@Number INT OUT,

@WriteDate SMALLDATETIME OUT,

@ExecDate SMALLDATETIME OUT,

@LoginName VARCHAR(256) OUT

AS

BEGIN

BEGIN TRAN

DECLARE @ID_PLC INT

@ID_Signal INT

DECLARE @ID_Request INT

DECLARE @ID_SPTZAdminLogin INT

EXEC @ID_PLC = FindPLC @NameRNU, @NumberPLC, 1

IF @ID_PLC = 0 BEGIN

RETURN

END

SELECT @ID_Signal = ID_TITRSignal, @ID_Request = ID_Request

FROM TITRSignals

WHERE ID_PLC = @ID_PLC AND MEKAdress = @MEKAdress

IF COUNT(@ID_Signal) = 0 BEGIN

SELECT @ID_Signal = ID_TUTSSignal, @ID_Request = ID_Request

FROM TUTSSignals

WHERE ID_PLC = @ID_PLC AND MEKAdress = @MEKAdress

END

IF COUNT(@ID_Signal) > 1 BEGIN

raiserror('В базе данных хранится несколько сигналов с Адресом МЭК = %d,

принадлежащих ПЛК №%d из РНУ %s не содержится в базе данных!

Нарушено ограничение целостности базы данных!', 15, 1, @MEKAdress, @NumberPLC, @NameRNU)

RETURN

END

IF COUNT(@ID_Signal) = 1 BEGIN

SELECT @Prefix = Prefix, @Number = Number, @WriteDate = WriteDate,

@ExecDate = ExecDate,

@ID_SPTZAdminLogin = ID_SPTZAdminLogin

FROM Requests

WHERE ID_Request = @ID_Request

SELECT @LoginName = NameLogin

FROM SPTZAdminsLogins

WHERE ID_SPTZAdminLogin = @ID_SPTZAdminLogin

END

ELSE BEGIN

raiserror('Сигнал с Адресом МЭК = %d, принадлежащий ПЛК №%d из РНУ %s не содержится в базе данных!', 15, 1, @MEKAdress, @NumberPLC, @NameRNU)

END

END

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

Проектирование пользовательского интерфейса

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

Было принято решение отказаться от меню по причине того, что количество команд, доступных одновременно пользователю невелико (от 4-х до 7-ми) и выполнение всех их можно назначить кнопкам, расположенным на форме. Использование меню только увеличило бы количество щелчков мышью.

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

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

Рассмотрим процесс исполнения заявки сотрудником СПТЗ. Он включает 4 шага, изображённых на рисунках ниже.

1) Пользователь нажимает кнопку «Считать сигналы» и выбирает текстовый файл с данными по сигналам, экспортированный из SCADA Realflex. Программа на основании данных из файла составляет список изменений, планируемых к внесению в базу данных проекта на основании вводимой заявки.

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

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

На данном шаге пользователь может выбрать любой сигнал и ввести примечания по его редактированию в текстовом поле внизу формы. Нажав кнопку подтверждения изменений или клавишу «Enter» в таблице автоматически выделяется следующий сигнал. Это ускоряет процесс ввода большого количества примечаний.

3) Далее пользователь вводит остальные данные по заявке, такие как префикс, порядковый номер, дата составления. Для выбора даты предусмотрено специализированное окошко, упрощающее это действие. Этот компонент поставляется с IDE CBuilder 6.

Следует отметить ещё одну деталь. В правом верхнем углу во избежание ошибок отображается имя ПЛК, в характеристики сигналов которого вносятся изменения и РНУ, которому он принадлежит.

4) Пользователю остаётся нажать на кнопку «Исполнить заявку» на панели действий. После успешного внесения заявки в статусной строке внизу формы отображается соответствующее сообщение. Эта строка специально предусмотрена для этого.

Рассмотрим процесс получения телемехаником выходного документа, содержащего данные по характеристикам сигналов определённого ПЛК.

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

После выбора ПЛК справа отображаются значения характеристик его сигналов, разбитых по вкладкам. Причём вкладки с именем типа, сигналов которого ни одного не сопоставлено с выбранным ПЛК, не отображаются.

Далее телемеханик выбирает одно из двух действий: «Печатать» или «Сохранить в Excel», что приводит к генерации выходного документа и либо его вывода на печать, либо передаче в приложение Microsoft Office Excel.

В разделе просмотра сигналов присутствуют специфические для сотрудников СПТЗ возможности, недоступные телемеханика. Это действия по удалению ПЛК и РНУ, кнопка включения отображения удалённых сигналов.

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

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

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

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

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

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

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

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

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

Было принято решение запретить всем пользователям доступ ко всем объектам БД, кроме хранимых процедур (разрешение 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 для поддержки целостности базы данных были установлены соответствующие ограничения, написаны триггеры. Для осуществления бизнес-логики, поддержки бизнес-процессов и формирования выходных форм написаны хранимые процедуры. Анализ входной документации позволил правильно создать входные формы для управления данными системы.