Virtually all of the database management systems have a triggering method that determines when a particular type of update (e.g., delete) is performed on a particular item (e.g., employee record bb104). The trigger tells us three things:
When to execute some set of business rules
Which business rules to execute
What context to use when evaluating the rules
One of the nice things about database-triggered rules is that you can be assured that they will fire regardless of what process (known or unknown) caused the update to occur. The downside is that the rules must be expressed in the language of the database triggers, which are typically proprietary extensions to SQL, packaged as stored procedures.
The context constraints are often convenience features (they restrict the scope of the context to the very items you wish to deal with). For example, a trigger that updates an accumulator for outstanding orders could be placed on the "order line amount" attribute. In practice you would have three triggers as follows:
Add/create trigger, which would add the order line amount to the accumulator
Delete trigger, which would decrement the accumulator by the old (predelete) value of the order line amount
Change/update trigger, which would add to the accumulator the (possibly negative) value of the difference between the order line amount and the old value of the order line amount
Sometimes you can't conveniently get to all the items you'd like to get to without making some unnatural additions to the database structure.
Unfortunately, there aren't a lot of good alternatives to database triggering. The next most popular arrangement is to have the application call the rule engine when it needs to. This solves the performance and context problems at the expense of integrity.
I'm optimistic that as the message-oriented paradigm takes hold, there will be triggering mechanisms built to execute at the message level, which seems to be the right blend of granularity and guarantee.