Поможем в ✍️ написании учебной работы

Имя

Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

Выберите тип работыЧасть дипломаДипломная работаКурсовая работаКонтрольная работаРешение задачРефератНаучно - исследовательская работаОтчет по практикеОтветы на билетыТест/экзамен onlineМонографияЭссеДокладКомпьютерный набор текстаКомпьютерный чертежРецензияПереводРепетиторБизнес-планКонспектыПроверка качестваЭкзамен на сайтеАспирантский рефератМагистерская работаНаучная статьяНаучный трудТехническая редакция текстаЧертеж от рукиДиаграммы, таблицыПрезентация к защитеТезисный планРечь к дипломуДоработка заказа клиентаОтзыв на дипломПубликация статьи в ВАКПубликация статьи в ScopusДипломная работа MBAПовышение оригинальностиКопирайтингДругое

Нажимая кнопку "Продолжить", я принимаю политику конфиденциальности

 

На данный момент лидерами среди СУБД корпоративных ресурсов являются 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

 

В данных случаях программная поддержка целостности является единственным способом обеспечения согласованности и корректности хранимых данных.