Главная » Microsoft SQL Server, Базы данных » Проверка сложных правил бизнес-логики

0

Чаще всего проверка данных осуществляется на уровне ограничений, однако ограничения проверки (а также пользовательские функции) ограничены пределами текущей строки. Сложная проверка данных имеет две особенности.

?               Проверка данных может требовать доступа не только к текущей строке, отвергая таким образом возможность реализации с помощью ограничений.

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

Сложную проверку данных лучше всего реализовывать с помощью триггеров, поскольку они — достаточно гибкие, мощные и на 100% оптимизированные программные элементы.

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

В качестве альтернативы можно сравнивать переменную @@Rowcount транзакции со значением функции с количеством корректных строк в таблице Inserted, однако проверка на наличие некорректных данных обычно проще и работает быстрее.

В качестве примера задачи, требующей сложной проверки данных, можно взять следующее правило для базы данных Cape Hatteras Adventures: любой ответственный за событие экскурсовод должен быть квалифицирован для соответствующего тура.

Экскурсоводы, ответственные за события, перечислены в таблице Event_mm_Guide, поэтому триггер должен проверять данные, вставляемые в эту таблицу.

Чтобы проверить наличие данных, нарушающих данное правило, инструкция SELECT объединяет таблицу Inserted триггера с таблицей Event, чтобы определить идентификатор тура, а затем с таблицей Event_mm_Guide — для проверки квалификации ответственного за событие. Обратите внимание на то, что в инструкции не требуется объединение с таблицей Event_mm_Guide, — все необходимые данные содержатся в таблице Inserted. В завершение инструкция SELECT отсекает строки тех экскурсоводов, кто еще не получил квалификацию или у кого она уже просрочена.

USE СНА2

CREATE TRIGGER LeadQualified ON Event_mm_Guide AFTER INSERT, UPDATE AS

SET NoCount ON IF EXISTS(

SELECT *

FROM Inserted

JOIN dbo.Event

ON Inserted.EventID = Event.EventID LEFT JOIN dbo.Tour_mm_Guide

ON Tour_mm_Guide.TourlD = Event.TourlD

AND Inserted.GuidelD = Tour_mm_Guide.GuidelD

WHERE

Inserted.IsLead = 1 AND

(QualDate > Event.DateBegin OR

RevokeDate IS NOT NULL OR

QualDate IS NULL )

)

BEGIN

RAISERROR(1 Ответственный не квалифицирован.’,16,1)

ROLLBACK TRANSACTION END

В следующих двух запросах мы протестируем созданную реализацию технологии сложной проверю!, попытавшись назначить ответственными за событие как квалифицированного экскурсовода, так и неквалифицированного. В первом запросе мы попытаемся назначить ответственным за тур Gauley River Rafting экскурсовода Джона Джонсона:

INSERT Event_mm_Guide (EventID, GuidelD, IsLead)

VALUES (10, 1, 1)

Получим следующий результат:

Ответственный не квалифицирован.

Если же назначить экскурсовода 5 класса Кена Франка ответственным за тур Gauley River, то триггер разрешит вставку:

INSERT Event_mm_Guide (EventID, GuidelD, IsLead)

VALUES (10, 2, 1)

(1 row(s) affected)

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии