1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen Specifying & Enforcing Transition Constraints These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see

2 © Ellis Cohen Overview of Lecture Transition Constraints Transitionalized Relations Transition Assertions Specialized Transition Predicates Relational Transition Constraints Enforcing Transition Constraints Application-Enforced Rejection Rejection & Rollback Application-Enforced Correction Deletion Integrity Constraints Two-Phase Enforcement Enforcing Operation-Independent Transition Constraints Cascading Enforcement Specifying Output-Related Post Conditions Full Transition Assertions

3 © Ellis Cohen Transition Constraints

4 © Ellis Cohen Kinds of System Constraints State Constraints Specifies constraints on the state of the system an invariant property of the database state (something that must always be true and must be able to be checked at ANY ARBITRARY TIME!) Behavior Constraints Specifies constraints on the behavior of the system transition constraints access constraints

5 © Ellis Cohen Behavior Constraints Transition Constraint Characterizes the results to be produced by specified operations or changes Access Constraint Specifies constraints on what a user or operation is permitted to do

6 © Ellis Cohen Generalizing Post-Conditions A Transition Constraint is either a –post-condition –generalized post-condition Two ways to generalize post-conditions Operation-dependent condition for a group of operations, rather than just a specific one Operation-independent condition which doesn’t refer to operations at all, but is just based on database/user/environment

7 © Ellis Cohen Conceptual & Relational Constraints Conceptual Constraint A system constraint, often written informally, in terms of a conceptual model (about entity classes, not tables!) Relational Constraint A system constraint written (often more formally, e.g. using SQL), in terms of a relational model (i.e. tables)

8 © Ellis Cohen Transition Constraints Conceptual Transition Constraints Describe side effects, in plain language, in terms of the conceptual model Relational Transition Constraints Describe side effects, written in a formal SQL-like language, in terms of the relational model

9 © Ellis Cohen Transitionalized Relations (a non-standard SQL extension!)

10 © Ellis Cohen Database-Related Transition Assertions A transition assertion describes a way in which an operation changes the database state To write a Transition Assertion We need to be able to distinguish the state of tables in the database –before execution –after execution

11 © Ellis Cohen Transitionalized Relations Emps Emps& Refers to the state of the Emps table at a particular point in time Refers to the state of the Emps table at two distinct points in time the time just before execution of an action the time just after execution of an action Execution Emps( empno, ename, job, sal ) Emps& has a tuple for every tuple that was in Emps before or after execution

12 © Ellis Cohen Update Action empno' ename' job' sal' 6154 SMITH CLERK SMITH CLERK 1340 empno 6154 Emps&( empno, empno', ename', job', sal', ) UPDATE Emps SET sal = sal WHERE empno = 6154 If (SELECT e.sal' FROM Emps& e WHERE empno = 6154) = 1100 Then (SELECT FROM Emps& e WHERE empno = 6154) = 1340 Attribute(s) for primary key(s) BEFORE AFTER

13 © Ellis Cohen Delete Action empno' ename' job' sal' 6154 SMITH CLERK NULL NULL NULL NULL empno 6154 Emps&( empno, empno', ename', job', sal', ) DELETE FROM Emps WHERE empno = 6154 If the action is the DELETE above, then (SELECT FROM Emps& e WHERE empno = 6154) IS NULL (SELECT FROM Emps& e WHERE empno = 6154) IS NULL BEFORE AFTER

14 © Ellis Cohen Insert Action empno' ename' job' sal' NULL NULL NULL NULL CODY ANALYST 2300 empno 3175 Emps&( empno, empno', ename', job', sal', ) INSERT INTO Emps VALUES( 3175, 'CODY', 'ANALYST', 2300 ) If the action is the INSERT above, then (SELECT e.empno' FROM Emps& e WHERE empno = 3175) IS NULL (SELECT e.sal' FROM Emps& e WHERE empno = 3175) IS NULL BEFORE AFTER

15 © Ellis Cohen Transitionalized Relation Problem Suppose the action is defined as BEGIN INSERT INTO Emps( empno, job, sal ) VALUES( 2468, 'PEON', 650 ); UPDATE Emps SET sal = 2500 WHERE empno = 6519; DELETE FROM Emps WHERE empno = 8718; END; Emps& Fill in the table below. Make up values where needed

16 © Ellis Cohen Transitionalized Relation Solution 1615 'CLERK' NULL 2468 NULL 'PEON' NULL 'ANALYST' NULL 'WRITER' NULL 1600 NULL Emps& Note: changing the value of a primary key (which is a bad idea anyway) is treated as a delete of a tuple (with its original key value) combined with an insert of a tuple (with the new key value) Pink cells have made-up values Blue cells have values determined by the made-up values White cells have values determined by the action

17 © Ellis Cohen Transitionalized PK NULL Comparisons What group of employees are represented by SELECT e.empno FROM Emps& e WHERE e.empno' IS NOT NULL  employees employed before the action SELECT e.empno FROM Emps& e WHERE IS NOT NULL SELECT e.empno FROM Emps& e WHERE e.empno' IS NULL SELECT e.empno FROM Emps& e WHERE IS NULL

18 © Ellis Cohen Groups of Employees SELECT e.empno FROM Emps& e WHERE e.empno' IS NOT NULL  employees employed before the action SELECT e.empno FROM Emps& e WHERE IS NOT NULL  employees employed after the action SELECT e.empno FROM Emps& e WHERE e.empno' IS NULL  employees hired by the action SELECT e.empno FROM Emps& e WHERE IS NULL  employees terminated by the action

19 © Ellis Cohen Transition Assertions

20 © Ellis Cohen Transition Assertions A transition assertion is a boolean (i.e. true/false) extended SQL expression that uses –transitionalized relations (Emps&) –operation parameters, when used with an operation-dependent transition constraint context NOT EXISTS (SELECT * FROM Emps& WHERE = :deptno) NO Emps& e SATISFIES = :deptno No employees are left in department :deptno

21 © Ellis Cohen Example Transition Assertion No employee that was in department 20 is still in department 20 NO Emps& e WHERE e.deptno' = 20 SATISFIES = 20 NOT EXISTS (SELECT * FROM Emps& e WHERE e.deptno’ = 20 AND = 20) All employees that were in department 20 have been moved to department 10 EACH Emps& e WHERE e.deptno' = 20 SATISFIES = 10 NOT EXISTS (SELECT * FROM Emps& e WHERE e.deptno’ = 20 AND != 10 OR IS NULL) )

22 © Ellis Cohen Transition Assertion Exercise All employees that were in department 20 are now unassigned Write transition assertions that correspond to the following: All employees that were in department 20 are no longer employed

23 © Ellis Cohen Terminated Employees EACH Emps& e WHERE e.deptno' = 20 SATISFIES IS NULL NOT EXISTS (SELECT * FROM Emps& WHERE e.deptno’ = 20 AND IS NOT NULL) All employees that were in department 20 are no longer employed

24 © Ellis Cohen Unassigned Employees EACH Emps& e WHERE e.deptno' = 20 SATISFIES IS NULL AND IS NOT NULL NOT EXISTS (SELECT * FROM Emps& WHERE e.deptno’ = 20 AND IS NOT NULL OR IS NULL)) All employees that were in department 20 are now unassigned

25 © Ellis Cohen Lifetime Dependency Exercise Employees in departments that were destroyed are no longer employed Write the transition assertion Hint: It can be written either as EACH Emps& e WHERE … SATISFIES … (using a vector subquery) or EACH Depts& d WHERE … SATISFIES … (using a nested EACH subquery)

26 © Ellis Cohen Lifetime Dependency EACH Depts& d WHERE IS NULL SATISFIES (EACH Emps& e WHERE d.deptno' = e.deptno' SATISFIES IS NULL ) EACH Emps& e WHERE e.deptno' IN (SELECT d.deptno FROM Depts& d WHERE IS NULL ) SATISFES IS NULL Employees that were in departments that were destroyed are no longer employed

27 © Ellis Cohen Affected Tuples Exercise All employees who reported to removed department managers now report to the president (employee #7839) instead. Write the transition assertion

28 © Ellis Cohen Affected Tuples Answer EACH Emps& m WHERE m.job' = 'DEPTMGR' AND <> 'DEPTMGR' OR IS NULL) SATISFIES (EACH Emps& e WHERE e.mgr' = m.empno' SATISFIES = 7839)

29 © Ellis Cohen Specialized Transition Predicates

30 © Ellis Cohen Using Insert & Delete Predicates Predefined Transition Predicates (if pk is the primary key of the table x refers to) x IS DELETED IS NULL x IS NOT DELETED IS NOT NULL x IS INSERTED x.pk' IS NULL x IS NOT INSERTED x.pk' IS NOT NULL So, if e is anEmployee:e IS IS NULL

31 © Ellis Cohen Delete Predicate Examples EACH Emps& e WHERE e.deptno' = 20 SATISFIES e IS DELETED All employees that were in department 20 are no longer employed EACH Emps& e WHERE e.deptno' = 20 SATISFIES IS NULL AND e IS NOT DELETED All employees that were in department 20 are now unassigned EACH Depts& d WHERE d IS DELETED SATISFIES (EACH Emps& e WHERE d.deptno' = e.deptno' SATISFIES e IS DELETED) Employees that were in departments that were destroyed are no longer employed

32 © Ellis Cohen Predefined Modified Predicates x IS MODIFIED AT attr (e.attr' != OR (e.attr' IS NULL AND IS NOT NULL) OR (e.attr' IS NOT NULL AND IS NULL) x IS MODIFIED AT a1, …, an (x IS MODIFIED AT a1) OR … (x IS MODIFIED At an) x IS MODIFIED means that some of x's attributes are modified -- Note: If x is either INSERTED OR DELETED then X is also MODIFIED x IS MODIFIED EXCEPT AT a1, …, an means that some of x's attributes (other than a1, …, an) are modified

33 © Ellis Cohen Predefined Updated Predicate x IS UPDATED AT attr (x IS MODIFIED AT attr) AND (x IS NOT INSERTED) AND (x IS NOT DELETED) x IS UPDATED AT a1, …, an (x IS MODIFIED AT a1, …, an) AND (x IS NOT INSERTED) AND (x IS NOT DELETED) x IS UPDATED (x IS MODIFIED) AND (x IS NOT INSERTED) AND (x IS NOT DELETED) x IS UPDATED EXCEPT AT a1, …, an (x IS MODIFIED EXCEPT AT a1, …, an) AND (x IS NOT INSERTED) AND (x IS NOT DELETED)

34 © Ellis Cohen Predefined Unchanged Predicates (opposite of Modified Predicates) x IS UNCHANGED AT attr (e.attr' = OR (e.attr' IS NULL AND IS NULL) x IS UNCHANGED AT a1, …, an (x IS UNCHANGED AT a1) AND … (x IS UNCHANGED AT an) x IS UNCHANGED means that all of x's attributes are unchanged x IS UNCHANGED EXCEPT AT a1, …, an means that all of x's attributes (other than a1, … an) are unchanged

35 © Ellis Cohen Using Unchanged EACH Depts& d WHERE d IS NOT DELETED SATISFIES (EACH Emps& e WHERE d.deptno' = e.deptno' SATISFIES e IS UNCHANGED) Employees in departments that were not deleted are unaffected by the action

36 © Ellis Cohen Relational Transition Constraints

37 © Ellis Cohen Example Transition Constraint + Conceptual Transition Constraint: As a result of executing FiddleWithDept(:deptno ), department :deptno is left without employees FiddleWithDept( :deptno ) RESULTS IN NO Emps& e SATISFIES = :deptno Relational Transition Constraint Translation: After executing FiddleWithDept( :deptno ), consider all the employees (who were employees either before or after the operation was executed). None of them has a value for deptno at the end of the operation that is equal to :deptno

38 © Ellis Cohen Transition Constraints & Assertions RESULTS IN RESULTS IN The Transition Assertion may reflect –the state preceding the operation(s) –the state following the operation(s) using transitionalized relations (Emps&) When the constraint context is a specific operation or list of operations with parameters, the transition assertion can refer to those parameters We are mostly interested in writing transition constraints for user actions but they can also be written for database actions or procedures in any layer of the implementation

39 © Ellis Cohen Relational Transition Constraint FiddleWithDept( :deptno ) RESULTS IN NO Emps& e SATISFIES = :deptno Constraint Context: Circumstances in which some side effect is supposed to happen Transition Assertion: Formal description of the side effect

40 © Ellis Cohen Example Constraint Contexts A specific user operation TerminateEmp( :empno ) A list of specific user operations TerminateEmp( :empno ), DestroyDept( :deptno, :reldept ) Any operation/query/action ANY ACTION Any operation/query/action for some role ANY OPERATION BY DeptMgr Operation-based contexts with exceptions ANY OPERATION EXCEPT (ANY QUERY BY Employee) Table-based UPDATE OF job ON Emps Operation- Dependent Operation- Independent

41 © Ellis Cohen Enforcing Transition Constraints

42 © Ellis Cohen Use of Transition Constraints Documentation The transition constraint simply documents what the code is expected to already do Can be used for code inspection and validation Enforcement Add code that ensures that the system actually satisfies the constraint

43 © Ellis Cohen Enforcement Approaches (for both existing code & new business rules) Correction: Add code which corrects the database state, so that the constraint becomes enforced  Transition constraints are almost always enforced by correction. Rejection: Add code which checks whether the constraint is enforced. If not, raise an exception!

44 © Ellis Cohen Purpose of Enforcement Error Detection & Correction of Existing System Add code to detect and/or correct implementation errors in enforcing existing business rules Support New Business Rules Support new business rules added after an application has already been built

45 © Ellis Cohen Correction Variations Enforcement by correction can take many forms. Suppose we want to enforce (by correction) the transition constraint associated with some specific action operation Every newly added employee in dept 10 has a salary > 600 How might we add code to the operation to enforce the constraint?

46 © Ellis Cohen Correction Alternatives Graceful correction: If the employee has been added to dept 10 with a salary < 600, reset it to 600 Heavy-handed correction: If the employee has been added to dept 10 with a salary < 600, move them to dept 66 (the PARTY dept) Heavy-handed correction may still be better than rejection, which won't allow the employees to be inserted at all (since the action will be rolled back) Every newly added employee in dept 10 has a salary > 600

47 © Ellis Cohen Mixed Approaches Correction & Rejection are just ends of a spectrum. Mixed Approaches do a combination of these -- e.g. Try graceful correction If some tuples can't be gracefully corrected, try heavy-handed correction for those If some tuples can't be corrected at all, reject the operation (or allow it, but notify the DBA about the problems)

48 © Ellis Cohen Transition Constraint Specificity More specific transition constraints give the developer less leeway in deciding what kind of correction to use: Less specific constraint Every newly added employee is placed in some department other than the largest one More specific constraint Every newly added employee is placed in department 10

49 © Ellis Cohen Enforcing Transition Constraints There are two places to enforce transition constraints Application Enforcement: Enforce transition constraints through code implemented in user actions (in the middle-tier) or stored DB actions (in the data-tier) Database Enforcement: Use built-in database features to automatically enforce transition constraints in the data-tier triggers & on delete

50 © Ellis Cohen Application-Based Enforcement White Box Enforcement –Look at the code of each relevant operation, and modify it in the best possible way to enforce the constraint Black Box Enforcement –Leave the basic operation code alone (except to place information in local variables from modified tuples using RETURNING clauses) –Add code after the base modification code of each relevant operation to enforce the constraint –May also need to add code before the existing code to handle setup for the after code –In some cases, it's possible to place all the enforcement code before the base modification code

51 © Ellis Cohen Why Black Box Enforcement? Supports different developers maintaining base code and constraints Increases maintainability overall Simplifies cases where the constraints (which reflect business rules) are likely to change. Supports reusability if the same kind of enforcement needs to be done in multiple operations Simplifies switching to trigger-based enforcement

52 © Ellis Cohen Application-Enforced Rejection

53 © Ellis Cohen Example Transition Constraint As a result of executing FiddleWithDept(:deptno ), department :deptno is left without employees FiddleWithDept( :deptno ) RESULTS IN NO Emps& e SATISFIES = :deptno

54 © Ellis Cohen Enforcement By Rejection Why are we enforcing this by rejection? 1) We expect that the base code of FiddleWithDept leaves the department empty, but we want to check that, and do so by rejection. 2) This is a new business rule relating to FiddleWithDept. For now, we choose to enforce it by rejection (it’s simpler) Enforcement by Rejection: If the constraint fails, we don't want the changes made by FiddleWithDept to persist

55 © Ellis Cohen Black Box Rejection BEGIN … the code to fiddle the dept is here … but too complicated to show -- now, check if it was done correctly, -- else raise an exception FOR rec IN (SELECT empno FROM Emps WHERE deptno = :deptno) LOOP RAISE_APPLICATION_ERROR( , 'Department ' || :deptno || ' is not empty' ); END LOOP; END; FiddleWithDept( :deptno ) Note this code could instead count how many employees are left in Emps. What would that look like? Black Box Rejection Code

56 © Ellis Cohen Rejection Using Counting DECLARE knt int; BEGIN … the code to fiddle the dept is here … but too complicated to show -- now, check if it was done correctly, -- else raise an exception SELECT count(*) INTO knt FROM Emps WHERE deptno = :deptno; IF knt > 0 THEN RAISE_APPLICATION_ERROR( , 'Department ' || :deptno || ' is not empty' ); END IF; END; FiddleWithDept( :deptno )

57 © Ellis Cohen Rejection & Rollback

58 © Ellis Cohen Rejection and Rollback Raising an exception will only rollback the action (i.e. unfiddle) if it is propagated out of the database server. If the exception is caught (e.g. to display output), then unfiddling will not happen! Ensuring rollback requires either that The exception is not caught within code executed within the database, or If the exception is caught, an explicit ROLLBACK (or RAISE) is done

59 © Ellis Cohen Rejection w Explicit Rollback BEGIN … the code to fiddle the dept is here … but too complicated to show -- now, check if it was done correctly, -- else raise an exception FOR rec IN (SELECT empno FROM Emps WHERE deptno = :deptno) LOOP ROLLBACK; pl( 'Department ' || :deptno || ' is not empty' ); EXIT; END LOOP; END; FiddleWithDept( :deptno ) What happens if an exception is raised by the base code to fiddle a dept? With AUTO- COMMIT ON

60 © Ellis Cohen Consistent Exception Handling BEGIN … the code to fiddle the dept is here … but too complicated to show -- now, check if it was done correctly, -- else raise an exception FOR rec IN (SELECT empno FROM Emps WHERE deptno = :deptno) LOOP RAISE_APPLICATION_ERROR( , 'Department ' || :deptno || ' is not empty' ); END LOOP; EXCEPTION WHEN OTHERS THEN doerr(); END; FiddleWithDept( :deptno ) Displays the error information and does the ROLLBACK 1) Ensures all exceptions are handled consistently 2) Separates identification of errors from way that they are reported to the user (e.g. using HTML) With AUTO- COMMIT ON

61 © Ellis Cohen Reusable Enforcement Procedure PROCEDURE CheckDeptEmpty( aDeptno int ) IS BEGIN FOR rec IN (SELECT empno FROM Emps WHERE deptno = aDeptno) LOOP RAISE_APPLICATION_ERROR( , 'Department ' || aDeptno || ' is not empty' ); END LOOP; END; FiddleWithDept( :deptno ) BEGIN … the code to fiddle the dept is here … but too complicated to show CheckDeptEmpty( :deptno ); EXCEPTION WHEN OTHERS THEN doerr(); END; Define a reusable procedure that can be used in any operation to check whether a dept is empty Displays the error information and does the ROLLBACK

62 © Ellis Cohen Standard Error Handling Routine PROCEDURE doerr IS endpos int; startpos int; len int; str varchar2(400); BEGIN startpos := 2 + instr( SQLERRM, ':' ); endpos := instr( SQLERRM, chr(10), startpos ); len := endpos - startpos; IF endpos = 0 THEN str := substr( SQLERRM, startpos ); ELSE str := substr( SQLERRM, startpos, len ); END IF; pl( '--> ERROR: ' || str ); ROLLBACK; END; In addition to rolling back the transaction, it extracts useful information from the exception string, and prints it out

63 © Ellis Cohen Application-Enforced Correction

64 © Ellis Cohen Correction BEGIN … the code to fiddle the dept is here … but way too complicated to show -- now, delete any employees still in the dept DELETE FROM Emps WHERE deptno = :deptno; EXCEPTION WHEN OTHERS THEN doerr(); END; FiddleWithDept( :deptno ) Correct by simply deleting any employees left in dept :deptno As a result of executing FiddleWithDept(:deptno ), department :deptno is left without employees (even if the department itself still exists) Place the correcting code in a stored procedure instead if it is complicated & can be reused by multiple operations Is there a more graceful approach?

65 © Ellis Cohen Graceful Correction BEGIN … the code to fiddle the dept is here … but way too complicated to show -- now, deassign any employees still in the dept UPDATE Emps SET deptno = NULL WHERE deptno = :deptno; EXCEPTION WHEN OTHERS THEN doerr(); END; FiddleWithDept( :deptno ) Correct by deassigning employees As a result of executing FiddleWithDept(:deptno ), department :deptno is left without employees

66 © Ellis Cohen Enforcement Problem What code would you add to UpdateSalaries to enforce this operation-specific transition constraint (i.e. post-condition) by Rejection or Correction UpdateSalaries( :vary ) BEGIN … updates the salaries of employee in some way … which depends upon :vary EXCEPTION WHEN OTHERS THEN doerr(); END; Suppose the post-condition JUST for this operation requires that no clerk end up with a salary less than $400

67 © Ellis Cohen Black Box Rejection BEGIN … the code to update salaries would be here FOR rec IN (SELECT empno FROM Emps WHERE job = 'CLERK' AND sal < 400) LOOP RAISE_APPLICATION_ERROR( , 'Oops! Underpaid Clerks'); END LOOP; EXCEPTION WHEN OTHERS THEN doerr(); END; UpdateSalaries( :vary ) If the application error is raised, it will be caught and doerr() will be called, which will rollback the update print the error information

68 © Ellis Cohen Black Box Correction BEGIN … the code to update salaries would be here UPDATE Emps SET sal = 400 WHERE job = 'CLERK' AND sal < 400; EXCEPTION WHEN OTHERS THEN doerr(); END; UpdateSalaries( :vary ) So, if UpdateSalaries added :vary pct to every employee's salary (:vary can be negative!) what would the code be?

69 © Ellis Cohen Corrective Solution with All Code BEGIN UPDATE Emps SET sal = sal * :vary / 100; UPDATE Emps SET sal = 400 WHERE job = 'CLERK' AND sal < 400; EXCEPTION WHEN OTHERS THEN doerr(); END; UpdateSalaries( :vary ) Base Code Corrective Code Suppose there is a CHECK constraint which checks that all employees have a salary > $350 What will happen if the first UPDATE statement leads to a CLERK having a salary of $340 (even though the second UPDATE statement will reset the salary to $400)?

70 © Ellis Cohen Deferred Constraints CREATE TABLE Emps( empnoint primary key, enamevarchar(30) not null, salnumber(8,2) CHECK( sal > 350 ) INITIALLY DEFERRED, deptnoint references Depts ) Declaring a constraint to be INITIALLY DEFERRED means that any checks that would be made in the middle of a transaction are deferred until the end of the transaction (actually they are re-checked) So if a employee's salary if set to 340 by one statement in an operation, but then reset to 400 by the end of the transaction, no error would be raised.

71 © Ellis Cohen White Box Correction BEGIN UPDATE Emps SET sal = CASE WHEN job = 'CLERK' AND (sal * :vary / 100) < 400 THEN 400 ELSE (sal * :vary / 100) END; EXCEPTION WHEN OTHERS THEN doerr(); END; UpdateSalaries( :vary ) Avoids need for two updates and for deferred checking

72 © Ellis Cohen White vs Black Box Comparison Performance One update statement requires one full scan through the employees table Two update statements (assuming no index on sal or job) requires two full scans Usability & Maintainability One update statement is often (but not always) harder to read & to maintain Separating the two cleanly separates the base & enforcement code

73 © Ellis Cohen Corresponding Relational Constraint UpdateSalaries( :vary ) RESULTS IN EACH Emps& e WHERE = 'CLERK' SATISFIES >= 400 Transition Assertion: After UpdateSalaries, every clerk's salary is 400 or more How is the constraint related to the enforcement code?

74 © Ellis Cohen Deletion Integrity Constraints

75 © Ellis Cohen Deletion Integrity Constraints Deletion Integrity Constraint: a conceptual transition constraint which specifies how to handle the children of a parent entity which has been deleted. Special Deletion Integrity Constraints (supported directly by SQL) Lifetime Dependency Constraint: When an entity (e.g. an invoice) is deleted, all of its children (e.g. its entries) are deleted as well Deassignment Constraint: When an entity (e.g. a department) is deleted, all of its children (e.g. its employees) become unassigned (i.e. not associated with any department)

76 © Ellis Cohen Conceptual Model With Lifetime Dependency Constraint DeptEmployee works for deptno dname empno ename sal location + Conceptual Transition Constraint When a department is deleted, all employees in that department are deleted Doesn't need to be stated explicitly: The constraint is visually represented by the dependent relationship. Lifetime Dependency Constraint

77 © Ellis Cohen CREATE TABLE Emps( empnoint primary key, enamevarchar(30) not null, salnumber(8,2), deptnoint references Depts ON DELETE CASCADE ) Relational Model With Lifetime Dependency Constraint Lifetime Dependency Constraints are supported directly by the relational model

78 © Ellis Cohen Conceptual Model With Deassignment DeptEmployee works for deptno dname empno ename sal location + Conceptual Transition Constraint When a department is deleted, all employees in that department become unassigned Deassignment Constraint

79 © Ellis Cohen CREATE TABLE Emps( empnoint primary key, enamevarchar(30) not null, salnumber(8,2), deptnoint references Depts ON DELETE SET NULL ) Relational Model with Deassignment Deassignment Constraints are supported directly by the relational model

80 © Ellis Cohen Specialized Deletion Integrity Constraint (not directly supported by SQL) DeptEmployee works for deptno dname empno ename sal + Conceptual Transition Constraint When a department is deleted, all employees left in that department must be moved to dept 66 (the PARTY department, which we will assume is never deleted) General Deletion Integrity Constraint not supported directly by SQL

81 © Ellis Cohen Enforcement for Vandalize BEGIN -- Vandalize's complicated code is here -- It does lots of complicated stuff -- including possibly deleting some depts EXCEPTION WHEN OTHERS THEN doerr(); END; Vandalize There may be an number of operations which may delete departments. Let's consider enforcement of the constraint for one of them, Vandalize

82 © Ellis Cohen Graceful Enforcement Code BEGIN -- Vandalize's complicated code is here -- If dept was deleted, -- Move its employees to dept 66 UPDATE Emps SET deptno = 66 WHERE deptno NOT IN (SELECT deptno IN Depts) EXCEPTION WHEN OTHERS THEN doerr(); END; Vandalize Checks whether dept was deleted But how can a dept even be deleted if it still has employees (unless it has an ON DELETE clause, which would already handle its employee)?

83 © Ellis Cohen CREATE TABLE Emps( empnoint primary key, enamevarchar(30) not null, salnumber(8,2), deptnoint references Depts INITIALLY DEFERRED ) Using INITIALLY DEFERRED If a deletion integrity constraint involves ANY side effect that you intend to enforce after the base code, you must specify INITIALLY DEFERRED, to defer the referential integrity check until the end of the transaction, otherwise the deletion of the parent will not be allowed. Deferring it means it is re-checked at the end of the transaction (i.e. operation) by which time all of the employees in the deleted departments have been moved

84 © Ellis Cohen Two-Phase Enforcement

85 © Ellis Cohen Two-Phase Constraint Implementation Sometimes black box enforcement of a transition constraint requires two phases: 1.Collect information at the start of the action (in local variables, package variables, or temporary tables) 2.Use that information at the end of the action to figure out whether there is a violation, and if so, reject or correct.

86 © Ellis Cohen Two-Phase Enforcement Problem BEGIN … mucks with department :deptno … in some complicated way EXCEPTION WHEN OTHERS THEN doerr(); END; MuckWithDept( :deptno ) Suppose the post-condition for this operation requires that any employee that was in dept :deptno and that was not deleted, must be moved to department 10 (however MuckWithDept may add new employees to the department!)

87 © Ellis Cohen Relational Transition Constraint As a result of executing MuckWithDept(:deptno ), any employee that was in dept :deptno and that was not deleted, must be moved to department 10 MuckWithDept( :deptno ) RESULTS IN EACH Emps& e WHERE e.deptno' = :deptno AND e IS NOT DELETED SATISFIES = 10 How could this be enforced?

88 © Ellis Cohen Enforcement Approach If any employees that were in department :deptno are not either deleted or in dept 10 Rejection –raise an exception Heavy-handed correction –delete them Gentle correction –move them to department 10

89 © Ellis Cohen Two-Phase Implementation Before basic mucking: oremember all the employees that were in :deptno at the start of MuckWithDept After basic mucking: ocheck whether all those employees were reassigned to department 10. If not oIf rejecting, raise an exception oIf correcting, delete or move 'em! Enforcing this constraint requires knowing who was in department :deptno at the beginning of the operation

90 © Ellis Cohen Using Temporary Tables BEGIN INSERT INTO OldEmps SELECT empno FROM Emps WHERE deptno = :deptno; … the basic MuckWithDept code goes here UPDATE Emps e SET deptno = 10 WHERE empno IN ( SELECT empno FROM OldEmps); EXCEPTION WHEN OTHERS THEN doerr(); END; MuckWithDept( :deptno ) Does correction Assume OldEmps has been defined as a temporary table Remembers employees in dept :deptno

91 © Ellis Cohen Temporary Tables CREATE GLOBAL TEMPORARY TABLE OldEmps ( … ) ON COMMIT DELETE ROWS; ON COMMIT PRESERVE ROWS retains the session's data from transaction to transaction (just like permanent tables) ON COMMIT DELETE ROWS automatically empties the session's data at the end of every transaction (this is the default!) When you create a global temporary table, the definition of the table is persistent, but every session gets its own independent copy of the data in the table!

92 © Ellis Cohen Enforcement Question BEGIN INSERT INTO OldEmps SELECT empno FROM Emps WHERE deptno = :deptno; … the basic MuckWithDept code goes here UPDATE Emps e SET deptno = 10 WHERE empno IN ( SELECT empno FROM OldEmps); EXCEPTION WHEN OTHERS THEN doerr(); END; MuckWithDept( :deptno ) How would this code need to be changed if the post-condition were: any employee that was in dept :deptno must be moved to department 10

93 © Ellis Cohen Reject on Delete BEGIN INSERT INTO OldEmps SELECT empno FROM Emps WHERE deptno = :deptno; … the basic MuckWithDept code goes here FOR rec IN (SELECT empno FROM OldEmps MINUS SELECT empno FROM Emps) LOOP RAISE_APPLICATION_ERROR( , 'Employee ' || rec.empno || ' improperly deleted' ); END LOOP; UPDATE Emps e SET deptno = 10 WHERE empno IN ( SELECT empno FROM OldEmps); EXCEPTION WHEN OTHERS THEN doerr(); END; MuckWithDept( :deptno )

94 © Ellis Cohen Enforcing Operation-Independent Transition Constraints

95 © Ellis Cohen Generalizing Post-Conditions A Transition Constraint is either a –post-condition –generalized post-condition Two ways to generalize post-conditions Operation-dependent condition for a group of operations, rather than just a specific one Operation-independent condition which doesn’t refer to operations at all, but is just based on database/user/environment

96 © Ellis Cohen Implementing Operation-Independent Transition Constraints 1.Determine which operations can affect the transition constraint. 2.Add code (e.g. a call to a reusable procedure, especially if there is more than one) to each of them to enforce it.

97 © Ellis Cohen Example Enforcement General Transition Constraint RaiseDeptMgrSal: Whenever an existing employee is made a dept mgr, then their salary is increased by 10%. Operations Affected ChangeJob – changes job of an employee ChangePosition – changes dept/job/mgr of an employee

98 © Ellis Cohen Operation-Specific Relational Transition Constraint ChangeJob( :empno, :job ) ChangePosition( :empno, :deptno, :mgr, :job ) RESULTS IN EACH Emps& e WHERE e.empno = :empno AND e.job' <> 'DEPTMGR' AND :job = 'DEPTMGR' SATISFIES = e.sal' * 1.1

99 © Ellis Cohen Operation-Independent Relational Transition Constraint ANY ACTION RESULTS IN EACH Emps& e WHERE e.job' <> 'DEPTMGR' AND = 'DEPTMGR' SATISFIES = e.sal' * 1.1

100 © Ellis Cohen Enforcement Procedure -- raises salary of employee anEmpno -- by 10% PROCEDURE RaiseSal( anEmpno int ) IS BEGIN UPDATE Emps SET sal = sal *1.1 WHERE empno = anEmpno; END;

101 © Ellis Cohen Black Box Implementation ChangeJob( :empno, :job ) BEGIN … base code to change the employee's job... is here but not shown IF :job = 'DEPTMGR' THEN RaiseSal( :empno ); END IF; EXCEPTION WHEN OTHERS THEN doerr(); END; And similarly for ChangePosition Probably ought to also check that the job was not previously DEPTMGR. How?

102 © Ellis Cohen Checking Old Salary ChangeJob( :empno, :job ) DECLARE empjob Emps.job%TYPE; BEGIN empjob := GetJob( :empno ); … base code to change the employee's job... is here but not shown IF :job = 'DEPTMGR' AND empjob != 'DEPTMGR' THEN RaiseSal( :empno ); END IF; EXCEPTION WHEN OTHERS THEN doerr(); END; Gets employee's job Assumes job cannot be NULL

103 © Ellis Cohen Simplifying ChangeJob ChangeJob( :empno, :job ) DECLARE empjob Emps.job%TYPE; BEGIN empjob := GetJob( :empno ); … base code to change the employee's job... is here but not shown RaiseSal( :empno, :job, empjob ); EXCEPTION WHEN OTHERS THEN doerr(); END; Write a version of RaiseSal, which takes the old & new job as parameters, and moves the testing code out of ChangeJob

104 © Ellis Cohen Cascading Enforcement

105 © Ellis Cohen Cascading Enforcement If a constraint is enforced by correction, The correction code may itself be relevant to some other constraint So the correction code would itself need to enforce that other constraint!

106 © Ellis Cohen Enforcement Example General Transition Constraint SetNewDeptMgrOnLoss: Whenever a department loses its department manager, then the employee in the department (if any) who has been with the company the longest becomes the new dept manager. Operations Affected TerminateEmp – terminates an employee ChangeJob – changes job of an employee ChangePosition – changes dept and/or job and/or mgr of employee

107 © Ellis Cohen Black Box Implementation TerminateEmp( :empno ) DECLARE empdept int; ejob Emps.job%TYPE; BEGIN SELECT deptno, job INTO empdept, ejob FROM Emps WHERE empno = :empno; -- this could be combined with deleting :empno … base code to terminate the employee is … here, but not shown IF ejob = 'DEPTMGR' THEN SetNewDeptMgr ( empdept ); END; EXCEPTION WHEN OTHERS THEN doerr(); END;

108 © Ellis Cohen Cascading Example TerminateEmp, ChangePosition & ChangeJob can all result in loss of a DeptMgr  Call SetNewDeptMgr from each of them (to potentially promote an employee to dept mgr) SetNewDeptMgr can promote an employee to a dept mgr  Call RaiseSal from SetNewDeptMgr (to raise the salary of the newly promoted dept mgr)

109 © Ellis Cohen Enforcement Procedure PROCEDURE SetNewDeptMgr( aDeptno int ) IS newmgr int; BEGIN FOR rec IN (SELECT empno FROM Emps WHERE deptno = aDeptno AND job = 'DEPTMGR') LOOP -- return if the dept has a DeptMgr RETURN; END LOOP; -- find longest hired employee in dept SELECT max(empno) INTO newmgr FROM Emps WHERE deptno = aDeptno AND hiredate = (SELECT min(hiredate) FROM Emps WHERE deptno = aDeptno); -- make that employee the new dept mgr UPDATE Emps SET job = 'DEPTMGR' WHERE empno = newmgr; -- don't forget to raise the salary of new dept mgrs RaiseSal( newmgr ); END; Cascading enforcement

110 © Ellis Cohen A Related Enforcement Example General Transition Constraint SetNewDeptMgrOnGain: Whenever an empty department gains new employees (but not a dept manager), then the employee in the department who has been with the company the longest becomes the new dept manager. Operations Affected AddEmp – hires a new employee ChangePosition – changes dept of an employee DestroyDept – destroys dept, possibly moving its employees to another dept

111 © Ellis Cohen Black Box Implementation AddEmp( :empno, :ename, :sal, :job, :mgr, :deptno ) BEGIN … base code to add the employee is here... but not shown SetNewDeptMgr( :deptno ); EXCEPTION WHEN OTHERS THEN doerr(); END; And similarly for ChangePosition & DestroyDept

112 © Ellis Cohen Specifying Output-Related Post Conditions

113 © Ellis Cohen Types of Post-Conditions State-Related Post-Conditions characterizes resulting changes to the database state -- e.g. the candidate's job entries must have all been deleted Output-Related Post-Conditions characterizes resulting properties of the operation output -- usually situations under which less information than expected was displayed External Post-Conditions characterizes resulting changes to the external environment -- e.g. a message was sent, etc.

114 © Ellis Cohen Output Post-Condition for Documentation SELECT empno, ename, sal FROM Emps WHERE empno = :curuser OR mgr = :curuser ShowSals + Output-Related Post-Condition (for Documentation): An employee can only see their own salary and the salaries of employees they manage

115 © Ellis Cohen Specifying Output-Related Post-Conditions Transition Constraints and State-Related Post-Conditions are described in terms of the state of tables We can use the same approach to describe Output-Related Post-Condition if we treat the OUTPUT as equivalent to one or more tables.

116 © Ellis Cohen Output-Related Post-Condition ShowAddrs( :ename ) OUTPUT Addresses( street, city, zip ) RESULTS IN EACH Addresses& a SATISFIES SOME Emps& e SATISFIES e.ename' = :ename AND e.street' = AND e.city' = AND e.zip' = AND e.isPublic' = 'T' An employee can only see another employee's address if it is public

117 © Ellis Cohen Using Attribute Matching SOME Emps&( ename': :ename, isPublic': 'T', street': city': zip': ) can be read as: There is some tuple in Emps& whose ename had the value :ename, etc. This allows us to write the constraint as ShowAddrs( :ename ) OUTPUT Addresses( street, city, zip ) RESULTS IN EACH Addresses& a SATISFIES SOME Emps&( ename': :ename, isPublic': 'T', street': city': zip': )

118 © Ellis Cohen Full Transition Assertions

119 © Ellis Cohen Limitations of Transition Assertions Transition assertions describes the required state after the action and the enforcement, but it is not easy to specify the details of the base action that actually caused that enforcement EACH Emps& e WHERE e.empno' IS NULL SATISFIES = 20 This specifies that every employee inserted is placed in dept 20. But there's no way to describe the exact circumstances that would cause that.

120 © Ellis Cohen Intermediate State To write more detailed transition assertions which specify when and how assertions are enforced, we need to be able to refer to the state after the base code of the operation is executed, but before the enforcement code executes base code enforcement code state before the action state after the action, including enforcement state before enforcement

121 © Ellis Cohen Fully Transitionalized Relations Emps Emps&& Refers to the state of the Emps table at a particular point in time Refers to the state of the Emps table at three distinct points in time 1.the time just before execution of an action 2.after base code execution, but before enforcement 3.after execution of the entire action Emps( empno, ename, job, sal ) Emps&& has a tuple for every tuple that was in Emps at any of these three points

122 © Ellis Cohen Fully Transitionalized Attributes For an employee e in Emps&& attr" – refers to the value of attr just before the action is executed attr' – refers to the value of attr after the base code is executed, but before the enforcement code is executed -- refers to the value of attr just after the action is fully executed, including enforcement

123 © Ellis Cohen Full Transition Assertions EACH Emps&& e WHERE e.empno" IS NULL AND e.deptno' = 10 SATISFIES = 20 If the base code of an action inserts an employee into dept 10, then at the end of the action, that employee is moved to dept 20. EACH Emps&& e WHERE e.empno" IS NULL AND e.empno' IS NOT NULL SATISFIES IS NULL Any employees inserted by the basic code of an action is deleted by the enforcement code. Transition Assertions based on fully transitionalized relations

124 © Ellis Cohen Specialized Deletion Integrity Constraint ANY ACTION RESULTS IN EACH Depts&& d WHERE d.deptno" IS NOT NULL AND d.deptno' IS NULL SATISFIES ( EACH Emps&& e WHERE e.deptno' = d.deptno" AND e.empno' IS NOT NULL SATISFIES = 66) When an operation deletes a department, all employees left in that department must be moved to dept 66 (the PARTY department!)

125 © Ellis Cohen Relational Lifetime Dependency Constraint ANY ACTION RESULTS IN EACH Depts&& d WHERE d.deptno" IS NOT NULL AND d.deptno' IS NULL SATISFIES ( EACH Emps&& e WHERE e.deptno' = d.deptno" SATISFIES IS NULL) When an operation deletes a department, all employees left in that department are deleted

126 © Ellis Cohen Relational Deassignment Constraint ANY ACTION RESULTS IN EACH Depts&& d WHERE d.deptno" IS NOT NULL AND d.deptno' IS NULL SATISFIES ( EACH Emps&& e WHERE e.deptno' = d.deptno" SATISFIES IS NULL AND IS NOT NULL) When an operation deletes a department, all employees left in that department become unassigned