--PAGE_BREAK--WHERE NameLogin = SUSER_NAME()
IF @ID_SPTZAdminLogin IS NULL BEGIN
INSERT INTO SPTZAdminsLogins (NameLogin) VALUES
(SUSER_NAME())
SET @ID_SPTZAdminLogin = @@IDENTITY
END
IF EXISTS(SELECT ID_Request FROM Requests
WHERE Prefix = @Prefix AND Number = @Number)
BEGIN
raiserror('Заявка с таким номером и префиксом уже существует в базе данных!', 15, 1)
RETURN
END
INSERT INTO Requests (Prefix, Number, WriteDate, ExecDate,
ID_SPTZAdminLogin)
VALUES (@Prefix,@Number, @WriteDate, GETDATE(),
@ID_SPTZAdminLogin)
SET @ID_Request = @@IDENTITY
Эта процедура возвращает приложению, её вызвавшему ID заявки, по которому оно далее может добавлять, редактировать, удалять сигналы.
В целях предотвращения намеренной подмены даты исполнения заявки на стороне клиента, данная процедура делает подзапрос к процедуре GetCurrentDateTime.
CREATE PROCEDURE GetCurrentDateTime @CurrDateTime DATETIME OUT
AS
SET @CurrDateTime = GETDATE()
Столь небольшой участок кода был выделен в отдельную процедуру из-за того, что он вызывается и со стороны клиентского приложения.
Следующим этапом с использованием InsertTITRSignal, InsertTUTSSignal добавляются сигналы в базу данных, UpdateTITRSignal, UpdateTUTSSignal – обновляются, DeleteSignal – удаляются.
Ниже приведён код некоторых из этих процедур:
REATE PROCEDURE InsertTITRSignal
@NameDataType VARCHAR(20),
@NameSignal VARCHAR(50),
@MEKAdress SMALLINT,
@MaxEnginGrade INT,
@MinEnginGrade INT,
@MaxPhysicGrade INT,
@MinPhysicGrade INT,
@Comment VARCHAR(300) = NULL,
@NameRNU VARCHAR(50),
@NamePLC VARCHAR(50),
@NumberPLC INT,
@ID_Request BIGINT,
@IsTISignal BIT
AS
DECLARE @ID_PLC INT
EXEC @ID_PLC = FindPLCWithInsUpd @NameRNU,
@NamePLC,@NumberPLC
DECLARE @TITRSigCount INT
SELECT @TITRSigCount = COUNT(ID_TITRSignal)
FROM TITRSignals
WHERE ID_PLC = @ID_PLC AND MEKAdress = @MEKAdress AND
IsDeleted = 0
DECLARE @TUTSSigCount INT
SELECT @TUTSSigCount = COUNT(ID_TUTSSignal)
FROM TUTSSignals
WHERE ID_PLC = @ID_PLC AND MEKAdress = @MEKAdress AND
IsDeleted = 0
IF (@TITRSigCount + @TUTSSigCount) > 0 BEGIN
raiserror('Сигнал с Адресом МЭК %d, принадлежащий ПЛК №%d из РНУ %s уже содержится в базе данных! Вставка невозможна.', 16, 1, @MEKAdress, @NumberPLC, @NameRNU)
RETURN
END
DECLARE @ID_DataType INT
EXEC @ID_DataType = FindDataTypeWithInsUpd @NameDataType
INSERT INTO TITRSignals (NameSignal, MEKAdress,
MaxEnginGrade, MinEnginGrade, MaxPhysicGrade,
MinPhysicGrade, Comment, IsDeleted, ID_PLC,
ID_DataType, ID_Request, IsTISignal)
VALUES(@NameSignal,@MEKAdress, @MaxEnginGrade,
@MinEnginGrade, @MaxPhysicGrade,
@MinPhysicGrade, @Comment, 0, @ID_PLC, @ID_DataType,
@ID_Request, @IsTISignal)
CREATE PROCEDURE UpdateTITRSignal
@NameDataType VARCHAR(20),
@NameSignal VARCHAR(50),
@MEKAdress SMALLINT,
@MaxEnginGrade INT,
@MinEnginGrade INT,
@MaxPhysicGrade INT,
@MinPhysicGrade INT,
@Comment VARCHAR(300) = NULL,
@NameRNU VARCHAR(50),
@NamePLC VARCHAR(50),
@NumberPLC INT,
@ID_Request INT,
@IsTISignal BIT
AS
DECLARE @ID_PLC INT
EXEC @ID_PLC = FindPLC @NameRNU, @NumberPLC, 1
IF @ID_PLC = 0 RETURN
DECLARE @ID_ExRequest INT
SELECT @ID_ExRequest = ID_Request
FROM TITRSignals
WHERE MEKAdress = @MEKAdress AND @ID_PLC = ID_PLC AND IsDeleted = 0 AND
IsTISignal = @IsTISignal
IF COUNT(@ID_ExRequest) = 0 BEGIN
raiserror('Обновляемый сигнал с Адресом МЭК %d, принадлежащий ПЛК №%d из РНУ %s не содержится в базе данных', @MEKAdress, @NumberPLC, @NameRNU, 16, 1)
RETURN
END
IF COUNT(@ID_ExRequest) > 1 BEGIN
raiserror('№%d из РНУ %s принадлежит больше одного сигнала с Адресом МЭК %d! Нарушена целостность базы данных', @MEKAdress, @NumberPLC, @NameRNU, 16, 1)
RETURN
END
DECLARE @ExWriteDate SMALLDATETIME
SELECT @ExWriteDate = WriteDate
FROM Requests
WHERE ID_Request = @ID_ExRequest
DECLARE @WriteDate SMALLDATETIME
SELECT @WriteDate = WriteDate
FROM Requests
WHERE ID_Request = @ID_Request
IF DATEDIFF(day, @WriteDate, @ExWriteDate) > 0
BEGIN
raiserror('Характеристики сигнала с Адресом МЭК %d, принадлежащий ПЛК №%d из РНУ %s изменялись по более новой заявке', 16, 1, @MEKAdress, @NumberPLC, @NameRNU)
END
ELSE
BEGIN
DECLARE @ID_DataType INT
EXEC @ID_DataType = FindDataTypeWithInsUpd @NameDataType
UPDATE TITRSignals SET NameSignal = @NameSignal, MEKAdress = @MEKAdress,
MaxEnginGrade = @MaxEnginGrade, MinEnginGrade = MinEnginGrade, MaxPhysicGrade = @MaxPhysicGrade,MinPhysicGrade = @MinPhysicGrade, Comment = @Comment, ID_DataType = @ID_DataType,
ID_Request = @ID_Request
WHERE MEKAdress = @MEKAdress AND @ID_PLC = ID_PLC AND
IsDeleted = 0 AND IsTISignal = @IsTISignal
END
Процедура InsertTITRSignal использует подпрограмму FindPLCWithInsUp, которая возвращает ID ПЛК с заданным номерам, принадлежащий определённому РНУ. Если РНУ или ПЛК не существует, то он создаются. Тоже самое делает и FindDataTypeWithInsUpd, только с типом данных. В этом заключается одно из преимуществ подхода, избранного для автоматизации бизнес-процесса. Все словари заполняются автоматически. Также предусмотрены триггеры очистки словарей от данных, которые не используются в данный момент ни одной записью дочерних отношений.
Для иллюстрации всего вышесказанного приведём код одной из процедур:
CREATE PROCEDURE FindDataTypeWithInsUpd
@NameDataType VARCHAR(20)
AS
BEGIN
DECLARE @ID_DataType INT
SELECT @ID_DataType = ID_DataType
FROM DataTypes
WHERE NameDataType = @NameDataType
IF @ID_DataType IS NULL BEGIN
INSERT INTO DataTypes (NameDataType) VALUES
(@NameDataType)
SET @ID_DataType = @@IDENTITY
END
RETURN @ID_DataType
END
При вводе данных по характеристикам сигналов может возникнуть такая ситуация, что какой-либо сигналов обновляется по заявке, имеющей дату составления более раннюю, чем заявка, по которой редактировался сигнал, уже хранящийся в базе данных. Разумеется, такое изменение не может быть внесено. В таком случае процедура UpdateTITRSignal откатывает всю транзакцию и даёт пользователю возможность исправить ошибку в базе данных SCADA RealFlex, в которую данные неправильные изменения уже были внесены, а затем повторить всё заново. Конечно, такое развитие событий маловероятно, но предусмотреть его всё-таки стоит.
На этом ввод заявки и сопутствующих данных завершается.
Далее рассмотрим, как формируется единственный выходной документ бизнес-процесса «Учёт сигналов телемеханики»: Данные по характеристикам сигналов ПЛК (Приложение 4). В этом участвуют 5 хранимых процедур и вызываются в следующей последовательности:
Пользователь выбирает название РНУ, затем номер ПЛК, ему принадлежащего и в конечном итоге процедуры FetchtTITRSignalsOnPLC и FetchtTUTSSignalsOnPLC возвращают данные по характеристикам затребованных сигналов. В выходной форме сигналы делятся на 4 группы по типу, каждая группа располагается на отдельном листе. Эти хранимые процедуры обеспечивают выборку каждой группы сигналов по отдельности. Таким образом, клиентскому приложению нет необходимости разделять сигналы самостоятельно. Кроме того на каждом листе сигналы сортируются по полю «Адрес МЭК» в возрастающем порядке. Такая форма наиболее удобна для телемехаников.
Почему физическая модель БД включает 4 на первый взгляд по сути одинаковые хранимые процедуры: FetchtTITRSignalsOnPLC, FetchtTUTSSignalsOnPLC, GetTITRSignalsOnPLC, GetTUTSSignalsOnPLC? Отличие первых двух от других заключается в том, что они не предусматривают возможности выборки сигналов только какого-либо одного типа, а особенности организации представления данных в клиентском приложении этого требуют, поэтому были написаны ещё две функции. Вот код одной из них:
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.
В разделе просмотра сигналов присутствуют специфические для сотрудников СПТЗ возможности, недоступные телемеханика. Это действия по удалению ПЛК и РНУ, кнопка включения отображения удалённых сигналов.
Кроме этого сотрудник СПТЗ может выбрать любой сигнал в списке и вызвав действие «Найти заявку» просмотреть данные о последней заявке, по которой изменялись характеристики выделенного сигнала. Пример на рисунке ниже:
Все данные из окна можно скопировать, нажав кнопку с соответствующим изображением.
Таким образом, как результат проектирования мы получили удобный, интуитивно понятный интерфейс.
Пользователи и права доступа Данные, хранимые в базе данных секретны, поэтому требуют введения определённой политики безопасности.
Доступ к базе данных могут иметь обладатели должностей:
· сотрудник СПТЗ
· телемеханик
продолжение
--PAGE_BREAK--