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

Найчастіше перевірка даних здійснюється на рівні обмежень, проте обмеження перевірки (а також користувальницькі функції) обмежені межами поточного рядка Складна перевірка даних має дві особливості

■ Перевірка даних може вимагати доступу не тільки до поточного рядка, відкидаючи таким чином можливість реалізації з допомогою обмежень

■ Перевірка даних може бути різною для різних клієнтів, компаній, підрозділів тощо до того ж вона може варіюватися з часом Процедури перевірки даних можуть довантажувати вимоги з таблиць конфігурації, дозволяючи адміністратору бази даних змінювати їх, не зачіпаючи схему

Складну перевірку даних найкраще реалізовувати за допомогою тригерів, оскільки вони – досить гнучкі, потужні і на 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 dboEvent

ON InsertedEventID = EventEventID LEFT JOIN dboTour_mm_Guide

ON Tour_mm_GuideTourlD = EventTourlD

AND InsertedGuidelD = Tour_mm_GuideGuidelD

WHERE

InsertedIsLead = 1 AND

(QualDate &gt EventDateBegin 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 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*