Розробка фізичної моделі бази даних Уч т характеристик сигналів телемеханіки

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

МІНІСТЕРСТВО ОСВІТИ
Ухтинський державний технічний університет
Кафедра ІСТ
КУРСОВИЙ ПРОЕКТ
Дисципліна: «Системи управління базами даних»
Тема:
«Розробка фізичної моделі бази даних« Облік характеристик сигналів телемеханіки »
Виконав: студент групи ІСТ-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) 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
У даних випадках програмна підтримка цілісності є єдиним способом забезпечення узгодженості і коректності даних, що зберігаються.

Підтримка бізнес-логіки і бізнес-правил

При виконанні курсового проекту з дисципліни «Інформаційні технології» була побудована DFD процесу «Облік сигналів телемеханіки» (Додаток 2). На цьому етапі вона була декомпозирована на 4 підпроцесу;
1. Видати дані про незбіжних сигналах
2. Прийняти заявку
3. Видати дані про сигнали
4. Знайти заявку
Провівши аналіз вхідних і вихідних потоків, був складений словник даних, на підставі якого в кінцевому підсумку ми одержали спочатку концептуальну, а потім логічну моделі БД (курсовий проект з дисципліни «Управління даними»). Фізична модель, створена при виконанні даного проекту, підтримує бізнес-логіку даного процесу.
Для введення нових даних за характеристиками сигналів складається спеціальна заявка (Додаток 3). У виконанні даної операції бере участь 12 збережених процедур. Внесення заявки в базу даних виконується в рамках однієї серіалізуємих транзакції. Такий рівень ізоляції був обраний для забезпечення кращої ізоляції оброблюваних даних під час транзакції. Враховуючи те, що заявки виконуються набагато рідше перегляду даних, це виправдане рішення. Якщо під час будь-якої з процедур стався збій, вона відкатує транзакцію.
Нижче вони зображені на діаграмі в тій послідовності, в якій викликаються.

GetTITRSignalsOnPLC
GetTUTSSignalsOnPLC
FindPLC
InsertRequest
GetCurrentDateTime
InsertTITRSignal
InsertTUTSSignal
UpdateTITRSignal
UpdateTUTSSignal
FindPLCWithInsUp
FindDataTypeWithInsUpd
DeleteSignal


Спершу збережені процедури 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 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
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 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 збережених процедур і викликаються в такій послідовності:
FetchRNUs
FetchPLCs
FetchtTITRSignalsOnPLC
FetchtTUTSSignalsOnPLC
FindPLC


Користувач вибирає назву РНУ, потім номер ПЛК, йому належить і в кінцевому підсумку процедури 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. Програма на підставі даних з файлу складає список змін, що плануються до внесення в базу даних проекту на підставі введеної заявки.
1
Овал: 1
2) Тепер всі майбутні зміни відображені на екрані. Для зручності користувача було прийнято рішення відображати поруч з кожним сигналом іконку, що позначає характер зміни: додавання, оновлення, видалення.
Всі зміни розбиті на групи, за типом змінюваного сигналу. Причому якщо в характеристики ні одного із сигналів будь-якого типу не вносяться зміни, то відповідна закладка просто не відображається, як, наприклад, на малюнку нижче доступна тільки вкладка «телевимірювань». Це зроблено, щоб користувач не витрачав час на перегляд порожніх таблиць.
На цьому кроці користувач може вибрати будь-який сигнал і ввести примітки за його редагування у текстовому полі внизу форми. Натиснувши кнопку підтвердження змін або клавішу «Enter» в таблиці автоматично виділяється наступний сигнал. Це прискорює процес введення великої кількості приміток.
2
Овал: 2
4
Овал: 4
3
Овал: 3
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 для підтримки цілісності бази даних були встановлені відповідні обмеження, написані тригери. Для здійснення бізнес-логіки, підтримки бізнес-процесів і формування вихідних форм написані збережені процедури. Аналіз вхідної документації дозволив правильно створити вхідні форми для управління даними системи.
За рік розробки пророблена велика робота і як результат - працездатна система.

СПИСОК ЛІТЕРАТУРИ

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-х аркушів, оформленого за наступним шаблоном:
Лист ТЗ
Найменування інформації
Тип даних
Адреса МЕК
Примітка
адреса
біт
Телесигналізація
Лист ТУ
Найменування інформації
Тип даних
Адреса МЕК
Примітка
адреса
біт
Телесигналізація
Лист ТІ
Найменування інформації
Тип даних
Адреса МЕК
Інж. ранги
Фіз. Ранги
Примітка
Телерегулірованіе
Лист ТР
Найменування інформації
Тип даних
Адреса МЕК
Інж. ранги
Фіз. Ранги
Примітка
Телерегулірованіе
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
82.9кб. | скачати


Схожі роботи:
Розробка фізичної моделі бази даних Уч т витрат на медичні послуги
Нормалізація таблиць в реляційної моделі бази даних
Розробка бази даних для готелю
Розробка бази даних з обліку книг в бібліотеці
Розробка бази даних для програми Радіодеталі
Розробка бази даних для розкладу занять
Розробка і створення презентації бази даних Деканат ВНЗ
Розробка програми генерації тестів з бази даних на мові РНР
Розробка проекту бази даних для АІС Облік Проектів
© Усі права захищені
написати до нас