Реферат: Разработка физической модели базы данных "Учёт характеристик сигналов телемеханики"
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПООБРАЗОВАНИЮ
УХТИНСКИЙ ГОСУДАРСТВЕННЫЙТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Кафедра ИСТ
КУРСОВОЙ ПРОЕКТ
Дисциплина: «Системыуправления базами данных»
Тема:
«Разработка физическоймодели базы данных «Учёт характеристик сигналов телемеханики»
Выполнил: студент группы ИСТ-2-04
Демидов А.Н.
Проверила: доцент кафедры ИСТ, к. т. н.
Николаева Н.А.
Ухта 2007
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ. 3
ПОСТАНОВКАЗАДАЧИ… 5
Анализ аналогов. 5
Обоснование выбора автоматизируемого бизнес-процесса. 5
ТЕХНОЛОГИЧЕСКАЯЧАСТЬ. 7
Обоснование выбора средств разработки. 7
Основные методы и способы разработки. 7
Модель жизненного цикла. 7
ОСНОВНАЯЧАСТЬ. 9
Поддержание целостности БД… 9
Поддержание бизнес-логики и бизнес-правил. 13
Проектирование пользовательского интерфейса. 27
Пользователи и права доступа. 32
ЗАКЛЮЧЕНИЕ. 34
СПИСОКЛИТЕРАТУРЫ… 35
ПРИЛОЖЕНИЕ1. 36
ПРИЛОЖЕНИЕ2.1 DFD контекстного уроня. 37
ПРИЛОЖЕНИЕ2.2 DFD 1-го уровня. 38
ПРИЛОЖЕНИЕ4. Данные по характеристика сигналов заданного ПЛК… 39
ВВЕДЕНИЕ
Темой данного курсового проекта являетсяразработка физической модели базы данных для АИС “Учет сигналов объектовтелемеханики”. Модель проектируется для ОАО «Северные магистральныенефтепроводы». Данный процесс рассматривается с точки зрения работника секторапроизводственно-технических задач и телемеханика.
Вышеназванное предприятие занимаетсятранспортировкой нефти, осуществляемой по нефтепроводам. Процесстранспортировки нефти должен обеспечиваться строгим контролем как нанефтеперегонных станциях, так и на отдельных участках нефтепровода. Этоосуществляется посредством специализированных объектов телемеханики(программируемых логических контроллеров (ПЛК)).
Для обслуживания ПЛК телемеханикам требуютсяданные по характеристикам сигналов, которые использует конкретный ПЛК. Такжеони вносят изменения в эти данные. Характеристики сигналов по всем объектамтелемеханики хранятся в файлах электронных таблиц Microsoft Excel на отдельном FTP-сервере с открытым длятелемехаников доступом. Неэффективность такого способа хранения очевидна (болееподробно в разделе анализ аналогов).
Следует отметить, что даже одна ошибка в базесигналов может повлечь за собой аварию на нефтепроводе. В качестве заменысуществующей системы можно предложить создание автоматизированнойинформационной системы.
Данный курсовой проект является логическимпродолжением курсовых проектов по дисциплинам «Информационные технологии» и«Управление данными». На предыдущих этапах работы были построены DFD контекстного и 1-гоуровней, созданы концептуальная и логическая модели БД.
Целью курсового проекта по дисциплине «Системыуправления базами данных» является разработка физической модели базы данных дляАИС “Учет сигналов объектов телемеханики”.
В задачи данной работы входят реализацияподдержки целостности данных, поддержки бизнес-логики процесса средствами СУБД.
Курсовой проект состоит из четырёх глав.
В разделе постановка задачи производится анализаналогов создаваемой АИС и основание выбора автоматизируемого бизнес-процесса
В разделе технологическая часть обосновываетсявыбор средств разработки, основные используемые методы разработки, такжевкратце описывается модель жизненного цикла, согласно которой проводитсяразработка.
В разделе основная часть обосновываютсяиспользованные способы поддержки целостности БД, поддержки бизнес-логики ибизнес-процессов, описывается и обосновывается интерфейс системы,рассказывается о выборе подхода к организации политики безопасности и доступа кБД.
И в заключении подводятся итоги выполненной работы.
ПОСТАНОВКА ЗАДАЧИАнализ аналогов
Аналогов, полностью повторяющих функциональностьразрабатываемой системы не существует.
На предприятии-заказчике на данный момент дляхранения значений характеристик сигналов используются файлы электронных таблиц Microsoft Office Excel. Недостатки такогоспособа хранения заключаются в следующем:
· неподдерживается целостность данных
· отсутствуетконтроль изменений данных
· необходимостьвводить данные два раза, сначала в о SCADA RealFlex, затем в книги Excel, что замедляетисполнение заявок, а также может привести к несогласованности между данными издвух баз
Создаваемая система призвана устранить все этинедостатки.
Обоснование выбора автоматизируемогобизнес-процессаНа этапе анализа требований встала проблемаопределения границ системы. С этой целью была построена DFD контекстного уровня(Приложение 2.1), определён главный процесс и внешние сущности. Затем процессбыл декомпозирован на подпроцессы (Приложение 2.2):
1. Выдатьданные о несовпадающих сигналах
2. Принятьзаявку
3. Выдатьданные о сигналах
4. Найтизаявку
Было решено автоматизировать все подпроцессы,т.к. без какого либо из них система не будет соответствовать функциональнымтребованиям, предъявляемым в техническом задании (курсовая работа по дисциплине«Информационные технологии»).
ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬОбоснование выбора средств разработки
На данный момент лидерами среди СУБДкорпоративных ресурсов являются Microsoft SQL Server и Oracle. Для данного проекта нетпринципиальной разницы в какой из этих СУБД будет реализована физическая модельбазы данных. Они обе поддерживают все необходимые декларативные ограниченияцелостности, а также обладают средствами программной поддержки целостности(хранимые процедуры, триггеры).
Независимые исследования показали, что SQL Server обеспечивает выполнениезапросов быстрее Oracle, зато Oracle обладает более продуманной системой безопасности.
Выбор пал на SQL Server 2005, так как он проще виспользовании, а также обладает визуальными средствами создания БД.
Основные методы и способы разработкиВыбор стоял между созданием базы данныхнаписанием и выполнением запросов и визуальным созданием средствами SQL Server 2005. В конечном итогевсе таблицы, ограничения были заданы с использованием визуальных инструментов.Это позволило существенно сократить затраты времени на разработку проекта.
Модель жизненного циклаРазработка проходила согласно модели жизненногоцикла RUP (Rational Unified Process). Жизненный цикл информационной системы делитсяна следующие стадии:
q Постановка задачи;
q Анализ;
q Проектирование;
q Реализация (кодирование);
q Отладка;
q Тестирование;
q Внедрение;
q Эксплуатация.
Разработка протекала итерационно, т.е. спостоянным возращением с текущего этапа на предыдущие и внесением изменений всоответствующую документацию (требования к системе, архитектура системы ит.п.).
Такой подход очень подходит для неопытногоразработчика, т.к. например, полностью сформулировать требования к системе –задача непосильная, а по мере продвижения по жизненному циклу это оказываетсянамного проще.
ОСНОВНАЯ ЧАСТЬПоддержание целостности БД
Целостность базы данных данного проектаподдерживаться декларативно и программно.
Согласованность и корректность данных на уровнеотношения обеспечивается за счёт назначения первичных и уникальных ключей.Рассмотрим, как это реализуется на примере таблицы РНУ:
CREATE TABLE Requests(
ID_Request int IDENTITY(1,1) NOTNULL,
Prefix char(2) NOT NULL,
Number int NOT NULL,
WriteDate smalldatetime NOT NULL,
ExecDate smalldatetime NOT NULL,
ID_SPTZAdminLogin int NOT NULL,
CONSTRAINT PK_Requests PRIMARY KEY(ID_Request),
CONSTRAINT UK_RequestsPrefixNumberUNIQUE(Prefix,
Number))
Здесь первичным ключом является атрибут ID_Request,а уникальным – комбинация атрибутов Prefix и Number. Суррогатный ключ ID_Requestбыл введён, потому что ключ (Prefix, Number) является составным, занимаетслишком много памяти и при ссылке на него из записей других таблиц будет требоватьсябольше места для их хранения.
Уникальные ключи также были назначены отношениям RNUs (NameRNU), PLCs (NamePLC), DataTypes (NameDataType) и SPTZAdminsLogins (NameLogin).
В рассмотренном отношении не хватает ещё одногоограничения, это:
ALTER TABLE Requests
ADD CONSTRAINT CK_Requests_Dates
CHECK (WriteDate<= ExecDate)
Ограничение CHECK служит для обеспеченияцелостности на уровне кортежа и используется проверки корректности сохраняемыхзаписей. В данном случае оно не позволяет ввести дату исполнения заявкипоследующую дате исполнения заявки.
Данное ограничение также установлено в таблице TITRSignals (MinEnginGrade<MaxEnginGrade,MinPhysicGrade<MaxPhysicGrade.
На уровне атрибутов почти для всех полей былиназначены ограничения целостности NOT NULL. Исключение составляетлишь атрибут Comment таблиц TITRSignals и TUTSSignals, т.к. примечания – это единственное, чтодопускается не сохранять вместе с данными о характеристиках сигнала. Данноеограничение позволяет сохранить информативность данных.
На уровне отношений ссылочная целостностьподдерживается определением внешних ключей с помощью инструкции FOREIGN KEY. Большинство ключейсоздано с использования опций ON DELETE NO ACTION, ON UPDATE NO ACTION. Это сохраняетсогласованность БД, не позволяя удалять данные, например, из словарей, если наних ссылаются записи дочерних таблиц. Но имеется несколько исключений:
ALTER TABLE PLCs
ADD CONSTRAINT FOREIGN KEY (ID_RNU)REFERENCES RNUs
ON DELETE CASCADE
ALTER TABLE TITRSignals
ADD CONSTRAINT FOREIGN KEY (ID_PLC)REFERENCES PLCs
ON DELETE CASCADE
ALTER TABLE TUTSSignals
ADD CONSTRAINT FOREIGN KEY (ID_PLC)REFERENCES PLCs
ONDELETE CASCADE
Такой подход упрощает удаление районных нефтяныхуправлений, т.к. вместе с ними автоматически удаляются связанныепрограммируемые логические контроллеры, а также ПЛК, т.к. с ними удаляются всесвязанные сигналы.
Помимо всех вышеперечисленных ограниченийцелостности декларативно поддерживается целостность на уровне домена. Этиограничения отображены на физической модели БД (Приложение 1). Следуетзаметить, что на атрибуте SignificantBit таблицы TUTSSignals для этого ограничениепришлось задать следующим образом:
ALTER TABLE TUTSSignals ADD CONSTRAINT
СK_TUTSSignals_SignificantBitCHECK (SignificantBit]<8)
Декларативный механизм не позволил задатьнекоторых ограничений целостности. Вместо этого использовались триггеры.
Во-первых, номера ПЛК в пределах одного РНУдолжны быть уникальны.
CREATE TRIGGER UniquePLCNumberInRNU
ON PLCs
FOR INSERT, UPDATE
AS
DECLARE @NumPLCs INT
SELECT @NumPLCs = COUNT(ALLi.ID_PLC)
FROM PLCs p INNER JOIN inserted i
ON p.ID_RNU = i.ID_RNU
WHERE p.NumberPLC = i.NumberPLC
IF @NumPLCs > 0
BEGIN
raiserror(Попыткавнести в базу данных ПЛК с уже занятым номером!', 16, 1)
ROLLBACK TRAN
END
Во-вторых, адреса МЭК сигналов, принадлежащиходному ПЛК должны быть уникальны.
CREATE TRIGGER UniqueMEKAdressOnPLC
ON TITRSignals
FOR INSERT, UPDATE
AS
DECLARE @NumTITRS INT
DECLARE @NumTUTSS INT
SELECT @NumTITRS = COUNT(ALLs.ID_TITRSignal)
FROM TITRSignals s INNER JOINinserted i
ON s.ID_PLC = i.ID_PLC
WHERE s.MEKAdress = i.MEKAdress
SELECT @NumTUTSS = COUNT(ALLs.ID_TUTSSignal)
FROM TUTSSignals s INNER JOINinserted i
ON s.ID_PLC = i.ID_PLC
WHERE s.MEKAdress = i.MEKAdress
IF (@NumTITRS + @NumTUTSS) > 0
BEGIN
raiserror(Попытка внести в базуданных сигнал с уже занятым МЭК адресом для данного ПЛК!', 16, 1)
ROLLBACK TRAN
END
В данных случаях программная поддержкацелостности является единственным способом обеспечения согласованности икорректности хранимых данных.
Поддержание бизнес-логики и бизнес-правилПри выполнении курсового проекта по дисциплине«Информационные технологии» была построена DFD процесса «Учёт сигналовтелемеханики» (Приложение 2). На этом этапе он был декомпозирован на 4подпроцесса;
1. Выдатьданные о несовпадающих сигналах
2. Принятьзаявку
3. Выдатьданные о сигналах
4. Найтизаявку
Произведя анализ входных и выходных потоков, былсоставлен словарь данных, на основании которого в конечном итоге мы получилисначала концептуальную, а затем логическую модели БД (курсовой проект подисциплине «Управление данными»). Физическая модель, созданная при выполненииданного проекта, поддерживает бизнес-логику данного процесса.
Для ввода новых данных по характеристикамсигналов составляется специальная заявка (Приложение 3). В выполнении даннойоперации участвует 12 хранимых процедур. Внесение заявки в базу данныхвыполняется в рамках одной сериализуемой транзакции. Такой уровень изоляции былвыбран для обеспечения лучшей изоляции обрабатываемых данных во время транзакции.Учитывая то, что заявки выполняются намного реже просмотра данных, этооправданное решение. Если во время какой-либо из процедур произошёл сбой, онаоткатывает транзакцию.
Ниже они изображены на диаграмме в тойпоследовательности, в которой вызываются.
/>
Сперва хранимее процедуры GetTITRSignalsOnPLC иGetTUTSSignalsOnPLC возвращают администратору СПТЗ список сигналов соответствующихданному ПЛК.
CREATE proc GetTITRSignalsOnPLC
@NameRNU VARCHAR(50),
@NumberPLC INT
AS
DECLARE @ID_PLC INT
exec @ID_PLC = FindPLC @NameRNU, @NumberPLC,0
SELECT NameDataType, NameSignal,MEKAdress, MaxEnginGrade, MinEnginGrade, MaxPhysicGrade, MinPhysicGrade,IsTISignal
FROM (SELECT *
FROM TITRSignals s
WHERE s.ID_PLC = @ID_PLC ANDisDeleted != 1) s INNER JOIN DataTypes d
ON s.ID_DataType = d.ID_DataType
Затем, используя предоставленный клиентскимприложением интерфейс, пользователь назначает изменяемым сигналам примечания.Стартует транзакция внесения заявки в БД.
Сначала вносятся данные по заявке.
CREATE PROCEDURE InsertRequest
@Prefix CHAR(2),
@Number BIGINT,
@WriteDate DATETIME,
@ID_Request BIGINT OUT
AS
DECLARE @ID_SPTZAdminLogin INT;
SELECT @ID_SPTZAdminLogin =ID_SPTZAdminLogin
FROM SPTZAdminsLogins
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 FROMRequests
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 ANDMEKAdress = @MEKAdress AND
IsDeleted = 0
DECLARE @TUTSSigCount INT
SELECT @TUTSSigCount =COUNT(ID_TUTSSignal)
FROM TUTSSignals
WHERE ID_PLC = @ID_PLC ANDMEKAdress = @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)
CREATEPROCEDURE UpdateTITRSignal
@NameDataTypeVARCHAR(20),
@NameSignalVARCHAR(50),
@MEKAdressSMALLINT,
@MaxEnginGradeINT,
@MinEnginGradeINT,
@MaxPhysicGradeINT,
@MinPhysicGradeINT,
@CommentVARCHAR(300) = NULL,
@NameRNUVARCHAR(50),
@NamePLCVARCHAR(50),
@NumberPLCINT,
@ID_RequestINT,
@IsTISignalBIT
AS
DECLARE@ID_PLC INT
EXEC @ID_PLC =FindPLC @NameRNU, @NumberPLC, 1
IF @ID_PLC = 0RETURN
DECLARE@ID_ExRequest INT
SELECT@ID_ExRequest = ID_Request
FROMTITRSignals
WHEREMEKAdress = @MEKAdress AND @ID_PLC = ID_PLC AND IsDeleted = 0 AND
IsTISignal =@IsTISignal
IFCOUNT(@ID_ExRequest) = 0 BEGIN
raiserror('Обновляемыйсигнал с Адресом МЭК %d, принадлежащий ПЛК №%d из РНУ %s не содержится в базеданных', @MEKAdress, @NumberPLC, @NameRNU, 16, 1)
RETURN
END
IFCOUNT(@ID_ExRequest) > 1 BEGIN
raiserror('№%dиз РНУ %s принадлежит больше одного сигнала с Адресом МЭК %d! Нарушенацелостность базы данных', @MEKAdress, @NumberPLC, @NameRNU, 16, 1)
RETURN
END
DECLARE@ExWriteDate SMALLDATETIME
SELECT@ExWriteDate = WriteDate
FROMRequests
WHEREID_Request = @ID_ExRequest
DECLARE@WriteDate SMALLDATETIME
SELECT@WriteDate = WriteDate
FROMRequests
WHEREID_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
UPDATETITRSignals SET NameSignal = @NameSignal, MEKAdress = @MEKAdress,
MaxEnginGrade= @MaxEnginGrade, MinEnginGrade = MinEnginGrade, MaxPhysicGrade =@MaxPhysicGrade,MinPhysicGrade = @MinPhysicGrade, Comment = @Comment,ID_DataType = @ID_DataType,
ID_Request =@ID_Request
WHEREMEKAdress = @MEKAdress AND @ID_PLC = ID_PLC AND
IsDeleted = 0AND IsTISignal = @IsTISignal
END
Процедура InsertTITRSignal использует подпрограммуFindPLCWithInsUp, которая возвращает ID ПЛК с заданным номерам, принадлежащий определённому РНУ. Если РНУ или ПЛК несуществует, то он создаются. Тоже самое делает и FindDataTypeWithInsUpd, толькос типом данных. В этом заключается одно из преимуществ подхода, избранного дляавтоматизации бизнес-процесса. Все словари заполняются автоматически. Такжепредусмотрены триггеры очистки словарей от данных, которые не используются вданный момент ни одной записью дочерних отношений.
Для иллюстрации всего вышесказанного приведём кододной из процедур:
CREATE PROCEDUREFindDataTypeWithInsUpd
@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
@NameRNUVARCHAR(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
ORDERBY MEKAdressASC
Помимо ввода данных по заявке и генерациивыходной формы физическая модель БД также обеспечивает доступ к данным опоследней заявке, по которой в характеристики определённого сигнала вносилисьизменения. Реализуется это с помощью следующей хранимой процедуры:
ALTER PROCEDURE [dbo].[GetRequestOnSignalFields]
@NameRNUVARCHAR(50),
@NumberPLCINT,
@MEKAdressSMALLINT,
@PrefixCHAR(2) OUT,
@NumberINT OUT,
@WriteDateSMALLDATETIME OUT,
@ExecDateSMALLDATETIME OUT,
@LoginNameVARCHAR(256) OUT
AS
BEGIN
BEGIN TRAN
DECLARE@ID_PLC INT
@ID_SignalINT
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
FROMTITRSignals
WHEREID_PLC = @ID_PLC AND MEKAdress = @MEKAdress
IFCOUNT(@ID_Signal) = 0 BEGIN
SELECT@ID_Signal = ID_TUTSSignal, @ID_Request = ID_Request
FROMTUTSSignals
WHEREID_PLC = @ID_PLC AND MEKAdress = @MEKAdress
END
IFCOUNT(@ID_Signal) > 1 BEGIN
raiserror('Вбазе данных хранится несколько сигналов с Адресом МЭК = %d,
принадлежащихПЛК №%d из РНУ %s не содержится в базе данных!
Нарушеноограничение целостности базы данных!', 15, 1, @MEKAdress, @NumberPLC, @NameRNU)
RETURN
END
IFCOUNT(@ID_Signal) = 1 BEGIN
SELECT@Prefix = Prefix, @Number = Number, @WriteDate = WriteDate,
@ExecDate= ExecDate,
@ID_SPTZAdminLogin= ID_SPTZAdminLogin
FROMRequests
WHEREID_Request = @ID_Request
SELECT@LoginName = NameLogin
FROMSPTZAdminsLogins
WHEREID_SPTZAdminLogin = @ID_SPTZAdminLogin
END
ELSEBEGIN
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 IFIS_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 DFD1-гоуровня
/>ПРИЛОЖЕНИЕ 4. Данные по характеристика сигналовзаданного ПЛК
Представляет собой файл электронной таблицы Microsoft Office Excel, состоящий из 4-хлистов, оформленного по следующему шаблону:
Лист ТС
Наименование информации Тип данных Адрес МЭК Примечание адрес бит Телесигнализация /> /> /> /> />Лист ТУ
Наименование информации Тип данных Адрес МЭК Примечание адрес бит ТелесигнализацияЛист ТИ
Наименование информации Тип данных Адрес МЭК Инж. ранги Физ. Ранги Примечание /> /> Телерегулирование /> /> /> /> /> /> /> /> /> /> /> /> />
Лист ТР
Наименование информации Тип данных Адрес МЭК Инж. ранги Физ. Ранги Примечание /> /> Телерегулирование /> /> /> /> /> /> /> /> /> />