Solving "COMMIT business rules" on the database server

Question

Headstart Oracle Designer related white paper
"CDM RuleFrame Overview: 6 Reasons to get Framed"
(at //otn.oracle.com/products/headstart/content.html) says:
"For a number of business rules it is not possible to implement these in the server
using traditional check constraints and database triggers. Below you can find two examples:
Example rule 1: An Order must have at least one Order Line ..."
But, one method exists that allows solving "COMMIT rules" completely on the database level.
That method consists of the possibility of delaying the checking of the declarative constraints (NOT NULL, Primary Key, Unique Key, Foreign Key, Check Constraints) until the commit
(that method was introduced first in the version 8.0.).
E.g. we add the field "num_emps" to the DEPT table, which always has the value of the number
of the belonging EMP rows and add DEFERRED CK which uses the values from that field:
ALTER TABLE dept ADD num_emps NUMBER DEFAULT 0 NOT NULL
UPDATE dept
SET num_emps = (SELECT COUNT (*) FROM emp WHERE emp.deptno = dept.deptno)
DELETE dept WHERE num_emps = 0
ALTER TABLE dept ADD CONSTRAINT dept_num_emps_ck CHECK (num_emps > 0) INITIALLY DEFERRED
Triggers that insure the solving of the server side "COMMIT rules" are fairly simple.
We need a packed variable that is set and reset in the EMP triggers and those value
is read in the bur_dept trigger (of course, we could have place the variable in the package
specification and change/read it directly, thus not needing the package body,
but this is a "cleaner" way to do it):
CREATE OR REPLACE PACKAGE pack IS
PROCEDURE set_flag;
PROCEDURE reset_flag;
FUNCTION dml_from_emp RETURN BOOLEAN;
END;
CREATE OR REPLACE PACKAGE BODY pack IS
m_dml_from_emp BOOLEAN := FALSE;
PROCEDURE set_flag IS
BEGIN
m_dml_from_emp := TRUE;
END;
PROCEDURE reset_flag IS
BEGIN
m_dml_from_emp := FALSE;
END;
FUNCTION dml_from_emp RETURN BOOLEAN IS
BEGIN
RETURN m_dml_from_emp;
END;
END;
CREATE OR REPLACE TRIGGER bir_dept
BEFORE INSERT ON dept
FOR EACH ROW
BEGIN
:NEW.num_emps := 0;
END;
CREATE OR REPLACE TRIGGER bur_dept
BEFORE UPDATE ON dept
FOR EACH ROW
BEGIN
IF :OLD.deptno <> :NEW.deptno THEN
RAISE_APPLICATION_ERROR (-20001, 'Can''t change deptno in DEPT!');
END IF;
-- only EMP trigger can change "num_emps" column
IF NOT pack.dml_from_emp THEN
:NEW.num_emps := :OLD.num_emps;
END IF;
END;
CREATE OR REPLACE TRIGGER air_emp
AFTER INSERT ON emp
FOR EACH ROW
BEGIN
pack.set_flag;
UPDATE dept
SET num_emps = num_emps + 1
WHERE deptno = :NEW.deptno;
pack.reset_flag;
END;
CREATE OR REPLACE TRIGGER aur_emp
AFTER UPDATE ON emp
FOR EACH ROW
BEGIN
IF NVL (:OLD.deptno, 0) <> NVL (:NEW.deptno, 0) THEN
pack.set_flag;
UPDATE dept
SET num_emps = num_emps - 1
WHERE deptno = :OLD.deptno;
UPDATE dept
SET num_emps = num_emps + 1
WHERE deptno = :NEW.deptno;
pack.reset_flag;
END IF;
END;
CREATE OR REPLACE TRIGGER adr_emp
AFTER DELETE ON emp
FOR EACH ROW
BEGIN
pack.set_flag;
UPDATE dept
SET num_emps = num_emps - 1
WHERE deptno = :OLD.deptno;
pack.reset_flag;
END;
If we insert a new DEPT without the belonging EMP, or delete all EMPs belonging to a certain DEPT, or move all EMPs of a certain DEPT, when the COMMIT is issued we get the following error:
ORA-02091: transaction rolled back
ORA-02290: check constraint (SCOTT.DEPT_NUM_EMPS_CK) violated
Disvantage is that one "auxiliary" column is (mostly) needed for each "COMMIT rule".
If we'd like to add another "COMMIT rule" to the DEPT table, like:
"SUM (sal) FROM emp WHERE deptno = p_deptno must be <= p_max_dept_sal"
we would have to add another column, like "dept_sal".
CDM RuleFrame advantage is that it does not force us to add "auxiliary" columns.
We must emphasize that in real life we would not write PL/SQL code directly in the database triggers, but in packages, nor would we directly use RAISE_APPLICATION_ERROR.
It is written this way in this sample only for the code clarity purpose.
Regards
Zlatko Sirotic

Answer 1

Zlatko,
You are right, your method is a way to implement "COMMIT rules" completely on the database level.
As you said yourself, disadvantage is that you need an extra column for each such rule,
while with CDM RuleFrame this is not necessary.
A few remarks:
- By adding an auxiliary column (like NUM_EMPS in the DEPT table) for each "COMMIT rule",
you effectively change the type of the rule from Dynamic (depending on the type of operation)
to a combination of Change Event (for updating NUM_EMPS) and Static (deferred check constraint on NUM_EMPS).
- Deferred database constraints have the following disadvantages:
When something goes wrong within the transaction, then the complete transaction is rolled back, not just the piece that went
wrong. Therefore, it becomes more important to use appropriate commit units.
There is no report of the exact row responsible for the violation nor are further violations either by other rows or of other
constraints reported.
If you use Oracle Forms as a front end application, the errors raised from deferred constraints are not handled very well.
- CDM discourages the use of check constraints. One of the reasons is, that when all tuple rules are placed in the CAPI,
any violations can be reported at the end of the transaction level together with all other rule violations.
A violated check constraint would abort the transaction right away, without the possibility of reporting back other rule violations.
So I think your tip is a good alternative if for some reason you cannot use CDM RuleFrame,
but you'd miss out on all the other advantages of RuleFrame that are mentioned in the paper!
kind regards, Sandra