Hmmmmmm I would disagree that what you have here expresses RI. Sure RI needs to be respected, but it is more of a byproduct, than a core part of the process.

I would also caution against looking at this as 1 step operaton. Also, the assumption is made that when a person is fired, they are deleted from the db. Regardless, lets assume they are in fact deleted. Here is how I see things working:

1. A sales person is fired
2. Begin a transaction
3a. A business rule is invoked to move any associated customers to the mgr
3b. If successful move to 4a
3c. If not successful, move to 5b
4a. delete the delete the sales person
4b. If successful, move to 5a
4c. If not successful, move to 5b
5a. commit transaction
5b. rollback transaction

There is a lot of interplay between the business services tier. In step 3, the business tier initates the request to move the customers, but the data services tier actually does the work. The business services tier then initates the request to delete the salesperson. Once again ,the data services tier actually does the work.

Now, you example has been super-imposed in a n-tier scenario...


>"When a salesman is fired, move all of his customers to his manager". This prevents orphan customer records. This rule may change over time... such as
>"When a salesman is fired, move all of his customers to the newest salesperson".