3.Обеспечение целостности бд
Обеспечение целостности базы данных осуществляется за счет декларативной и процедурной целостности.
Декларативная целостность неразрывно связана с физической структурой таблиц БД и осуществляется при помощи некоторых условий (ограничений), налагаемых на столбцы или таблицы. Этот вид поддержания согласованности данных гарантирует, что хранимая информация будет удовлетворять определенным в таблицах правилам. Кроме того, декларативные ограничения целостности обеспечивают высокое быстродействие, что, несомненно, является плюсом.
К декларативным ограничениям, используемым в данном курсовом проекте, относятся:
ограничение PRIMARYKEY
ограничение NOT NULL
ограничение UNIQUE
ограничение CHECK
Ограничение PRIMARYKEYсоздает первичные ключи, при помощи которых обеспечивается связь таблиц.
Первичный ключ не может иметь атрибутов с NULL признаком. Поэтому при создании первичного ключа ограничение NOTNULL на атрибуты, входящие в первичный ключ, назначается автоматически.
Ограничение UNIQUE объявляет столбец или группу столбцов уникальным. Это ограничение необходимо для контроля того, что все названия улиц и организаций будут разными.
Данное ограничение было наложено на атрибуты 2-х таблиц:
для таблицы Street (Улица)
CONSTRAINT NameStreetUnique UNIQUE(NameStreet)
для таблицы Organization(Организация)
CONSTRAINT NameOrganizationUnique UNIQUE (NameOrganization)
При заполнении информации о водоеме или гидранте, необходима проверка, чтобы были введены корректные данные. А именно, необходимо контролировать атрибуты Caliber (таблица Гидрант) и Size (таблица Водоем). Введенные данные не должны быть меньше или равны нулю. Для контроля данных этих атрибутов используется ограничение CHECK.
для таблицы Hydrant (Гидрант)
CONSTRAINT HydrantCaliber CHECK (Caliber>0)
длятаблицыPond(Водоем)
CONSTRAINT PondSize CHECK (Size>0)
Процедурную целостность необходимо использовать, когда нет возможности осуществлять контроль вводимых данных по средствам декларативной целостности.
Остальные бизнес-правила были реализованы при помощи триггеров. Так как в триггере можно сравнивать значения атрибутов из разных таблиц, что нельзя реализовать при помощи ограничения CHECK.
Ниже приведены триггеры, используемые в данном курсовом проекте:
TrDefect – триггер, контролирующий, чтобы не было возможности изменять данные о неисправности, если уже об этой неисправности было направлено письмо в обслуживающую организацию.
TrLetter – триггер, контролирующий, чтобы внесенная дата отправки письма была не раньше, чем дата проверки.
TrLetter2 – триггер, контролирующий, чтобы дата следующей проверки была больше, чем дата проверки и время, отведенное на ремонт.
CREATE TRIGGER TrDefect
ON Defect FOR UPDATE
AS
IF EXISTS
(SELECT 'TRUE'
FROM inserted i LEFT JOIN TestDefect T
ON i.IDDefect=T.IDDefect
LEFT JOIN Inspection Ins
ON T.IDInspection=Ins.IDInspection
LEFT JOIN Letter L
ON Ins.IDInspection=L.IDInspection
WHERE (L.IDLetter IS NOT NULL))
BEGIN
RAISERROR ('Нельзя изменять данные о неисправности!Отправлено письмо!',1,1)
ROLLBACK TRAN
END
CREATE TRIGGER TrLetter
ON Letter
FOR INSERT,UPDATE
AS
IF EXISTS
(SELECT 'TRUE'
FROM Letter L LEFT JOIN Inspection I
ON L.IDInspection=I.IDInspection
WHERE (L.DataSend<I.DateInspection))
BEGIN
RAISERROR ('Дата отправки должна быть не раньше даты проверки!',1,1)
ROLLBACK TRAN
END
CREATE TRIGGER TrLetter2
ON Letter
FOR INSERT,UPDATE
AS
IF EXISTS
(SELECT 'TRUE'
FROM Letter L LEFT JOIN Inspection I
ON L.IDInspection=I.IDInspection
LEFT JOIN TestDefect T
ON I.IDInspection=T.IDInspection
LEFT JOIN Defect D
ON T.IDDefect=D.IDDefect
WHERE (L.DateNextInspection<DATEADD(dd,D.RepairTime,I.DateInspection)))
BEGIN
RAISERROR ('Дата следующей проерки должна быть больше, чем даты проверки и время, отведенное на ремонт!',1,1)
ROLLBACK TRAN
END
