Databases Reference
In-Depth Information
system tuning but without affecting its basic functionality; and to evolve
requirements leading to a change in the systems underlying functionality
(adaptive maintenance) [9]. At a first glance, explicit capturing of business
policies through triggers will certainly help the maintenance of corporate
regulations in the DB system. Triggers support chunks of expertise that are
self-contained, isolated units that can be enlarged, removed, or updated more
easily than when they were previously coded in application programs. How-
ever, that is not the end of the story.
Maintenance of large rule sets can be difficult, and ascertaining the
effects of rule removal or addition is far from straightforward. It is the insidi-
ous ways in which rules can interact that makes addition or removal of a sin-
gle rule whose code looks perfectly satisfactory such a complicated task. A
previously correct rule set can stop enjoying this property after addition or
removal of a rule. Evolution-support tools are required to ease migration and
to determine the impact of additions and deletions.
To illustrate the difficulty of writing correct triggers, consider a policy
whereby when an employee who is teaching a course moves to the next level,
all his or her students should be moved accordingly. On the assumption that
only one class at each level can be under way, a first attempt to support this
policy can lead to the following trigger:
create or replace trigger levelChange
after update of level on employee
for each row
begin
update enrollment
set level = :new.level
where theCourse = 'Computing' and level =
:old.level
end;
If we look carefully at how that rule behaves at run time, we will realize that
the behavior is not as expected. Lets consider that
John follows course Computing, level 1, taught by Employee1
Anne follows course Computing, level 2, taught by Employee2
Employee1 teaches course Computing, level 1
Employee2 teaches course Computing, level 2
