ВВЕДЕНИЕ
Темой данного курсового проекта является разработка физической модели базы данных для АИС “Учет сигналов объектов телемеханики”. Модель проектируется для ОАО «Северные магистральные нефтепроводы». Данный процесс рассматривается с точки зрения работника сектора производственно-технических задач и телемеханика.

Вышеназванное предприятие занимается транспортировкой нефти, осуществляемой по нефтепроводам. Процесс транспортировки нефти должен обеспечиваться строгим контролем как на нефтеперегонных станциях, так и на отдельных участках нефтепровода. Это осуществляется посредством специализированных объектов телемеханики (программируемых логических контроллеров (ПЛК)).

Для обслуживания ПЛК телемеханикам требуются данные по характеристикам сигналов, которые использует конкретный ПЛК. Также они вносят изменения в эти данные. Характеристики сигналов по всем объектам телемеханики хранятся в файлах электронных таблиц 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) NOT NULL,

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_RequestsPrefixNumber UNIQUE(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

ON DELETE CASCADE

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

Помимо всех вышеперечисленных ограничений целостности декларативно поддерживается целостность на уровне домена. Эти ограничения отображены на физической модели БД (Приложение 1). Следует заметить, что на атрибуте SignificantBit таблицы TUTSSignals для этого ограничение пришлось задать следующим образом:

ALTER TABLE TUTSSignals ADD CONSTRAINT

СK_TUTSSignals_SignificantBit CHECK (SignificantBit]<8)

Декларативный механизм не позволил задать некоторых ограничений целостности. Вместо этого использовались триггеры.

Во-первых, номера ПЛК в пределах одного РНУ должны быть уникальны.

CREATE TRIGGER UniquePLCNumberInRNU

ON PLCs

FOR INSERT, UPDATE

DECLARE @NumPLCs INT

SELECT @NumPLCs = COUNT(ALL i.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

DECLARE @NumTITRS INT

DECLARE @NumTUTSS INT

SELECT @NumTITRS = COUNT(ALL s.ID_TITRSignal)

FROM TITRSignals s INNER JOIN inserted i

ON s.ID_PLC = i.ID_PLC

WHERE s.MEKAdress = i.MEKAdress

SELECT @NumTUTSS = COUNT(ALL s.ID_TUTSSignal)

FROM TUTSSignals s INNER JOIN inserted 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

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 AND isDeleted != 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

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 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

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

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

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)

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

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

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

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

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

Было принято решение отказаться от меню по причине того, что количество команд, доступных одновременно пользователю невелико (от 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

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-х листов, оформленного по следующему шаблону:

Лист ТС

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

Лист ТУ

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

Лист ТИ

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

Телерегулирование

Лист ТР

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

Телерегулирование