ВВЕДЕНИЕ
Темой данного курсового проекта является разработка физической модели базы данных для АИС “Учет сигналов объектов телемеханики”. Модель проектируется для ОАО «Северные магистральные нефтепроводы». Данный процесс рассматривается с точки зрения работника сектора производственно-технических задач и телемеханика.
Вышеназванное предприятие занимается транспортировкой нефти, осуществляемой по нефтепроводам. Процесс транспортировки нефти должен обеспечиваться строгим контролем как на нефтеперегонных станциях, так и на отдельных участках нефтепровода. Это осуществляется посредством специализированных объектов телемеханики (программируемых логических контроллеров (ПЛК)).
Для обслуживания ПЛК телемеханикам требуются данные по характеристикам сигналов, которые использует конкретный ПЛК. Также они вносят изменения в эти данные. Характеристики сигналов по всем объектам телемеханики хранятся в файлах электронных таблиц Microsoft Excel на отдельном FTP-сервере с открытым для телемехаников доступом. Неэффективность такого способа хранения очевидна (более подробно в разделе анализ аналогов).
Следует отметить, что даже одна ошибка в базе сигналов может повлечь за собой аварию на нефтепроводе. В качестве замены существующей системы можно предложить создание автоматизированной информационной системы.
Данный курсовой проект является логическим продолжением курсовых проектов по дисциплинам «Информационные технологии» и «Управление данными». На предыдущих этапах работы были построены DFD контекстного и 1-го уровней, созданы концептуальная и логическая модели БД.
Целью курсового проекта по дисциплине «Системы управления базами данных» является разработка физической модели базы данных для АИС “Учет сигналов объектов телемеханики”.
В задачи данной работы входят реализация поддержки целостности данных, поддержки бизнес-логики процесса средствами СУБД.
Курсовой проект состоит из четырёх глав.
В разделе постановка задачи производится анализ аналогов создаваемой АИС и основание выбора автоматизируемого бизнес-процесса
В разделе технологическая часть обосновывается выбор средств разработки, основные используемые методы разработки, также вкратце описывается модель жизненного цикла, согласно которой проводится разработка.
В разделе основная часть обосновываются использованные способы поддержки целостности БД, поддержки бизнес-логики и бизнес-процессов, описывается и обосновывается интерфейс системы, рассказывается о выборе подхода к организации политики безопасности и доступа к БД.
И в заключении подводятся итоги выполненной работы.
ПОСТАНОВКА ЗАДАЧИ
Анализ аналогов
Аналогов, полностью повторяющих функциональность разрабатываемой системы не существует.
На предприятии-заказчике на данный момент для хранения значений характеристик сигналов используются файлы электронных таблиц Microsoft Office Excel. Недостатки такого способа хранения заключаются в следующем:
· не поддерживается целостность данных
· отсутствует контроль изменений данных
· необходимость вводить данные два раза, сначала в о SCADA RealFlex, затем в книги Excel, что замедляет исполнение заявок, а также может привести к несогласованности между данными из двух баз
Создаваемая система призвана устранить все эти недостатки.
ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
Модель жизненного цикла
Разработка проходила согласно модели жизненного цикла 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
AS
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
AS
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
В данных случаях программная поддержка целостности является единственным способом обеспечения согласованности и корректности хранимых данных.
ЗАКЛЮЧЕНИЕ
Итак, разработка физической модели базы данных завершена. Цель достигнута.
В ходе выполнения данного курсового проекта были пройдены все этапы 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-х листов, оформленного по следующему шаблону:
Лист ТС
| Наименование информации | Тип данных | Адрес МЭК | Примечание | |
| адрес | бит | |||
| Телесигнализация | ||||
|
|
|
|
|
|
Лист ТУ
| Наименование информации | Тип данных | Адрес МЭК | Примечание | |
| адрес | бит | |||
| Телесигнализация | ||||
|
|
|
|
|
|
Лист ТИ
| Наименование информации | Тип данных | Адрес МЭК | Инж. ранги | Физ. Ранги | Примечание | |||
| Телерегулирование | ||||||||
|
|
|
|
|
|
|
|
| |
Лист ТР
| Наименование информации | Тип данных | Адрес МЭК | Инж. ранги | Физ. Ранги | Примечание | |||
| Телерегулирование | ||||||||
|
|
|
|
|
|
|
|
| |
ВВЕДЕНИЕ
Темой данного курсового проекта является разработка физической модели базы данных для АИС “Учет сигналов объектов телемеханики”. Модель проектируется для ОАО «Северные магистральные нефтепроводы». Данный процесс рассматривается с точки зрения работника сектора производственно-технических задач и телемеханика.
Вышеназванное предприятие занимается транспортировкой нефти, осуществляемой по нефтепроводам. Процесс транспортировки нефти должен обеспечиваться строгим контролем как на нефтеперегонных станциях, так и на отдельных участках нефтепровода. Это осуществляется посредством специализированных объектов телемеханики (программируемых логических контроллеров (ПЛК)).
Для обслуживания ПЛК телемеханикам требуются данные по характеристикам сигналов, которые использует конкретный ПЛК. Также они вносят изменения в эти данные. Характеристики сигналов по всем объектам телемеханики хранятся в файлах электронных таблиц Microsoft Excel на отдельном FTP-сервере с открытым для телемехаников доступом. Неэффективность такого способа хранения очевидна (более подробно в разделе анализ аналогов).
Следует отметить, что даже одна ошибка в базе сигналов может повлечь за собой аварию на нефтепроводе. В качестве замены существующей системы можно предложить создание автоматизированной информационной системы.
Данный курсовой проект является логическим продолжением курсовых проектов по дисциплинам «Информационные технологии» и «Управление данными». На предыдущих этапах работы были построены DFD контекстного и 1-го уровней, созданы концептуальная и логическая модели БД.
Целью курсового проекта по дисциплине «Системы управления базами данных» является разработка физической модели базы данных для АИС “Учет сигналов объектов телемеханики”.
В задачи данной работы входят реализация поддержки целостности данных, поддержки бизнес-логики процесса средствами СУБД.
Курсовой проект состоит из четырёх глав.
В разделе постановка задачи производится анализ аналогов создаваемой АИС и основание выбора автоматизируемого бизнес-процесса
В разделе технологическая часть обосновывается выбор средств разработки, основные используемые методы разработки, также вкратце описывается модель жизненного цикла, согласно которой проводится разработка.
В разделе основная часть обосновываются использованные способы поддержки целостности БД, поддержки бизнес-логики и бизнес-процессов, описывается и обосновывается интерфейс системы, рассказывается о выборе подхода к организации политики безопасности и доступа к БД.
И в заключении подводятся итоги выполненной работы.
ПОСТАНОВКА ЗАДАЧИ
Анализ аналогов
Аналогов, полностью повторяющих функциональность разрабатываемой системы не существует.
На предприятии-заказчике на данный момент для хранения значений характеристик сигналов используются файлы электронных таблиц Microsoft Office Excel. Недостатки такого способа хранения заключаются в следующем:
· не поддерживается целостность данных
· отсутствует контроль изменений данных
· необходимость вводить данные два раза, сначала в о SCADA RealFlex, затем в книги Excel, что замедляет исполнение заявок, а также может привести к несогласованности между данными из двух баз
Создаваемая система призвана устранить все эти недостатки.
Обоснование выбора автоматизируемого бизнес-процесса
На этапе анализа требований встала проблема определения границ системы. С этой целью была построена DFD контекстного уровня (Приложение 2.1), определён главный процесс и внешние сущности. Затем процесс был декомпозирован на подпроцессы (Приложение 2.2):
1. Выдать данные о несовпадающих сигналах
2. Принять заявку
3. Выдать данные о сигналах
4. Найти заявку
Было решено автоматизировать все подпроцессы, т.к. без какого либо из них система не будет соответствовать функциональным требованиям, предъявляемым в техническом задании (курсовая работа по дисциплине «Информационные технологии»).
ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
Дата: 2019-05-29, просмотров: 194.
