Autonomous Trigger / Mutating Table Problem

Question

We have a specific problem in one of our applications being developed where by the database needs to enforce a specific business requirement.
We need to use a database trigger to enforce some data integrity which involves more than one table as such cannot use standard constraint. The integrity has to be maintained in the database as the DML statements may be coming from a Java application or PL/SQL code as such we need the logic all in one place.
The problem being that within the trigger we need to examine the state of the table the trigger is associated with as well as one other table. Obviously using a trigger on a table that is being affected by DML statements causes the dreaded mutating table problem.
One suggested solution to this was to make the trigger or the code the trigger called autonomous. This allows the trigger to execute by only showing the trigger the original state of the table before any of the DML statements have affected it.
The problem is this seems to work for single row DML statements but not for multi row DML statements. In multi row the trigger only sees the original state of the table, not the state of the table plus the changes made by any other actions in the same DML statement.
Below I have shown an example of what I'm seeing.
I have grossly simplified the example code below to only refer to a single table and use stupidly simple logic
I do realise i appear to be implementing uniqueness in my own PL/SQL code, this is purely for the example.
CREATE TABLE mutate_test
id INTEGER NOT NULL,
value VARCHAR2(255) NOT NULL
ALTER TABLE mutate_test ADD CONSTRAINT pk_mutate_test PRIMARY KEY(id);
ALTER TABLE mutate_test ADD CONSTRAINT ck_mutate_test CHECK (value = UPPER(value));
CREATE OR REPLACE FUNCTION duplicate_found(in_value IN mutate_test.value%TYPE) RETURN BOOLEAN IS
PRAGMA AUTONOMOUS_TRANSACTION;
v_value_found INTEGER;
BEGIN
SELECT COUNT(*)
INTO v_value_found
FROM mutate_test
WHERE value = in_value;
IF v_value_found > 0 THEN
RETURN TRUE;
ELSE
RETURN FALSE;
END IF;
END;
CREATE OR REPLACE TRIGGER tr_mutate_test BEFORE INSERT OR UPDATE ON mutate_test
FOR EACH ROW
BEGIN
IF duplicate_found(:new.value) = TRUE THEN
RAISE_APPLICATION_ERROR(-20000,'Duplicate value found');
END IF;
END;
INSERT INTO mutate_test (id,value) VALUES (1,'CLIFF');
INSERT INTO mutate_test (id,value) VALUES (2,'SULA');
COMMIT;
SELECT * FROM mutate_test;
-- Should fail as row 1 already has a value of CLIFF
INSERT INTO mutate_test (id,value) VALUES (3,'CLIFF');
COMMIT;
SELECT * FROM mutate_test;
-- Should fail as row 1 is already set to CLIFF
UPDATE mutate_test SET value = 'CLIFF' WHERE id = 2;
COMMIT;
SELECT * FROM mutate_test;
UPDATE mutate_test SET value = 'CLIFFORD' WHERE id = 1;
COMMIT;
SELECT * FROM mutate_test;
INSERT INTO mutate_test (id,value) VALUES (3,'RONNY');
INSERT INTO mutate_test (id,value) VALUES (4,'TIM');
INSERT INTO mutate_test (id,value) VALUES (5,'MONIQUE');
COMMIT;
SELECT * FROM mutate_test;
-- Wanted result would be row 1 would be updated from CLIFFORD to CLIFF
-- and the others raise errors, or all of them raise errors.
UPDATE mutate_test SET value = 'CLIFF' WHERE id IN (1,3,4);
COMMIT;
SELECT * FROM mutate_test;

Answer 1

This is all from a University application that deals with eLearning.
Shell = Mapping from the system to an external eLearning application, ie: unique id of the Blackboard course shell, or WebBoard board.
Term = Academic term
Sector = University sector, ie: Higher Education, TAFE, etc..
Resource = eLearning tool, ie: Blackboard, WebBoard, etc..
Resource Level = Whether the resource is being offered at a Course or Program level
Resource Mapping = Association of a resource to shell
What we are trying to achieve is that shells cannot be used across sector boundaries.
The real table structure is (grossly simplified again)
CREATE TABLE sector (sector_pk INTEGER PRIMARY KEY);
CREATE TABLE sector_pattern (sector_pk INTEGER REFERENCES sector(sector_pk), pattern CHAR(2) NOT NULL UNIQUE CHECK (pattern = UPPER(pattern)));
CREATE TABLE term (term_pk INTEGER PRIMARY KEY, term CHAR(4) NOT NULL UNIQUE CHECK (term = UPPER(term)));
CREATE TABLE resource_level (resource_level_pk INTEGER PRIMARY KEY, term_pk INTEGER REFERENCES term(term_pk));
CREATE TABLE shell_detail (shell_detail_pk INTEGER PRIMARY KEY);
CREATE TABLE resource_mapping (resource_mapping INTEGER PRIMARY KEY, resource_level_pk INTEGER REFERENCES resource_level(resource_level_pk), shell_detail_pk INTEGER REFERENCES shell_detail(shell_detail_pk));
Based on the Ask Tom article linked I'd liked to use a MATERIALIZED VIEW on the following query
SELECT DISTINCT rm.shell_detail_pk,sp.sector_pk
FROM resource_mapping rm, resource_level rl, term t, sector_pattern sp
WHERE rm.resource_level_pk = rl.resource_level_pk
AND rl.term_pk = t.term_pk
AND SUBSTR(t.term,3,2) = sp.pattern;
Then apply a UNIQUE constraint on that VIEW.
But I'm receiving a
SQL Error: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
I'm not sure how to create the MATERIALIZED VIEW LOG entries for the above VIEW.
Any ideas anyone? ;)
Need to do some more reading and research but as Tom says
"I'm asking around about the future of "SQL" as far as enhancments go like that
(will update when I get some feedback), but -- you are not limited to triggers
(in fact, I would avoid triggers as it is virtually IMPOSSIBLE to implement
cross row/cross object constraints with them!!!! at least correctly)"
So I think i'll give up on the TRIGGER approach as it doesn't meet our requirements.