1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 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 http://www.openlineconsult.com/db

2. 2 © Ellis Cohen 2001-2008 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. 3 © Ellis Cohen 2001-2008 Transition Constraints

4. 4 © Ellis Cohen 2001-2008 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. 5 © Ellis Cohen 2001-2008 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. 6 © Ellis Cohen 2001-2008 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. 7 © Ellis Cohen 2001-2008 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. 8 © Ellis Cohen 2001-2008 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. 9 © Ellis Cohen 2001-2008 Transitionalized Relations (a non-standard SQL extension!)

10. 10 © Ellis Cohen 2001-2008 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. 11 © Ellis Cohen 2001-2008 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. 12 © Ellis Cohen 2001-2008 Update Action empno' ename' job' sal' 6154 SMITH CLERK 1100 empno@ ename@ job@ sal@ 6154 SMITH CLERK 1340 empno 6154 Emps&( empno, empno', empno@, ename', ename@, job', job@, sal', sal@ ) UPDATE Emps SET sal = sal + 240 WHERE empno = 6154 If (SELECT e.sal' FROM Emps& e WHERE empno = 6154) = 1100 Then (SELECT e.sal@ FROM Emps& e WHERE empno = 6154) = 1340 Attribute(s) for primary key(s) BEFORE AFTER

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

14. 14 © Ellis Cohen 2001-2008 Insert Action empno' ename' job' sal' NULL NULL NULL NULL empno@ ename@ job@ sal@ 3175 CODY ANALYST 2300 empno 3175 Emps&( empno, empno', empno@, ename', ename@, job', job@, sal', 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. 15 © Ellis Cohen 2001-2008 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; empnoempno'empno@job'job@sal'sal@ 1615 2468 6519 8718 Emps& Fill in the table below. Make up values where needed

16. 16 © Ellis Cohen 2001-2008 Transitionalized Relation Solution empnoempno'empno@job'job@sal'sal@ 1615 'CLERK' 1125 2468 NULL 2468 NULL 'PEON' NULL 650 6519 'ANALYST' 24002500 8718 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. 17 © Ellis Cohen 2001-2008 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 e.empno@ IS NOT NULL SELECT e.empno FROM Emps& e WHERE e.empno' IS NULL SELECT e.empno FROM Emps& e WHERE e.empno@ IS NULL

18. 18 © Ellis Cohen 2001-2008 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 e.empno@ 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 e.empno@ IS NULL  employees terminated by the action

19. 19 © Ellis Cohen 2001-2008 Transition Assertions

20. 20 © Ellis Cohen 2001-2008 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 e.deptno@ = :deptno) NO Emps& e SATISFIES e.deptno@ = :deptno No employees are left in department :deptno

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

22. 22 © Ellis Cohen 2001-2008 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. 23 © Ellis Cohen 2001-2008 Terminated Employees EACH Emps& e WHERE e.deptno' = 20 SATISFIES e.empno@ IS NULL NOT EXISTS (SELECT * FROM Emps& WHERE e.deptno’ = 20 AND e.empno@ IS NOT NULL) All employees that were in department 20 are no longer employed

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

25. 25 © Ellis Cohen 2001-2008 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. 26 © Ellis Cohen 2001-2008 Lifetime Dependency EACH Depts& d WHERE d.deptno@ IS NULL SATISFIES (EACH Emps& e WHERE d.deptno' = e.deptno' SATISFIES e.empno@ IS NULL ) EACH Emps& e WHERE e.deptno' IN (SELECT d.deptno FROM Depts& d WHERE d.deptno@ IS NULL ) SATISFES e.empno@ IS NULL Employees that were in departments that were destroyed are no longer employed

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

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

29. 29 © Ellis Cohen 2001-2008 Specialized Transition Predicates

30. 30 © Ellis Cohen 2001-2008 Using Insert & Delete Predicates Predefined Transition Predicates (if pk is the primary key of the table x refers to) x IS DELETED x.pk@ IS NULL x IS NOT DELETED x.pk@ 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 DELETEDe.empno@ IS NULL

31. 31 © Ellis Cohen 2001-2008 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 e.deptno@ 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. 32 © Ellis Cohen 2001-2008 Predefined Modified Predicates x IS MODIFIED AT attr (e.attr' != e.attr@) OR (e.attr' IS NULL AND e.attr@ IS NOT NULL) OR (e.attr' IS NOT NULL AND e.attr@ 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. 33 © Ellis Cohen 2001-2008 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. 34 © Ellis Cohen 2001-2008 Predefined Unchanged Predicates (opposite of Modified Predicates) x IS UNCHANGED AT attr (e.attr' = e.attr@) OR (e.attr' IS NULL AND e.attr@ 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. 35 © Ellis Cohen 2001-2008 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. 36 © Ellis Cohen 2001-2008 Relational Transition Constraints

37. 37 © Ellis Cohen 2001-2008 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 e.deptno@ = :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. 38 © Ellis Cohen 2001-2008 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. 39 © Ellis Cohen 2001-2008 Relational Transition Constraint FiddleWithDept( :deptno ) RESULTS IN NO Emps& e SATISFIES e.deptno@ = :deptno Constraint Context: Circumstances in which some side effect is supposed to happen Transition Assertion: Formal description of the side effect

40. 40 © Ellis Cohen 2001-2008 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. 41 © Ellis Cohen 2001-2008 Enforcing Transition Constraints

42. 42 © Ellis Cohen 2001-2008 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. 43 © Ellis Cohen 2001-2008 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. 44 © Ellis Cohen 2001-2008 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. 45 © Ellis Cohen 2001-2008 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. 46 © Ellis Cohen 2001-2008 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. 47 © Ellis Cohen 2001-2008 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. 48 © Ellis Cohen 2001-2008 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. 49 © Ellis Cohen 2001-2008 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. 50 © Ellis Cohen 2001-2008 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. 51 © Ellis Cohen 2001-2008 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. 52 © Ellis Cohen 2001-2008 Application-Enforced Rejection

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

54. 54 © Ellis Cohen 2001-2008 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. 55 © Ellis Cohen 2001-2008 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( -20067, '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. 56 © Ellis Cohen 2001-2008 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( -20067, 'Department ' || :deptno || ' is not empty' ); END IF; END; FiddleWithDept( :deptno )

57. 57 © Ellis Cohen 2001-2008 Rejection & Rollback

58. 58 © Ellis Cohen 2001-2008 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. 59 © Ellis Cohen 2001-2008 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. 60 © Ellis Cohen 2001-2008 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( -20067, '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. 61 © Ellis Cohen 2001-2008 Reusable Enforcement Procedure PROCEDURE CheckDeptEmpty( aDeptno int ) IS BEGIN FOR rec IN (SELECT empno FROM Emps WHERE deptno = aDeptno) LOOP RAISE_APPLICATION_ERROR( -20067, '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. 62 © Ellis Cohen 2001-2008 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. 63 © Ellis Cohen 2001-2008 Application-Enforced Correction

64. 64 © Ellis Cohen 2001-2008 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. 65 © Ellis Cohen 2001-2008 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. 66 © Ellis Cohen 2001-2008 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. 67 © Ellis Cohen 2001-2008 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( -20093, '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. 68 © Ellis Cohen 2001-2008 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. 69 © Ellis Cohen 2001-2008 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. 70 © Ellis Cohen 2001-2008 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. 71 © Ellis Cohen 2001-2008 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. 72 © Ellis Cohen 2001-2008 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. 73 © Ellis Cohen 2001-2008 Corresponding Relational Constraint UpdateSalaries( :vary ) RESULTS IN EACH Emps& e WHERE e.job@ = 'CLERK' SATISFIES e.sal@ >= 400 Transition Assertion: After UpdateSalaries, every clerk's salary is 400 or more How is the constraint related to the enforcement code?

74. 74 © Ellis Cohen 2001-2008 Deletion Integrity Constraints

75. 75 © Ellis Cohen 2001-2008 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. 76 © Ellis Cohen 2001-2008 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. 77 © Ellis Cohen 2001-2008 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. 78 © Ellis Cohen 2001-2008 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. 79 © Ellis Cohen 2001-2008 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. 80 © Ellis Cohen 2001-2008 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. 81 © Ellis Cohen 2001-2008 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. 82 © Ellis Cohen 2001-2008 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. 83 © Ellis Cohen 2001-2008 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. 84 © Ellis Cohen 2001-2008 Two-Phase Enforcement

85. 85 © Ellis Cohen 2001-2008 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. 86 © Ellis Cohen 2001-2008 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. 87 © Ellis Cohen 2001-2008 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 e.deptno@ = 10 How could this be enforced?

88. 88 © Ellis Cohen 2001-2008 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. 89 © Ellis Cohen 2001-2008 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. 90 © Ellis Cohen 2001-2008 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. 91 © Ellis Cohen 2001-2008 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. 92 © Ellis Cohen 2001-2008 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. 93 © Ellis Cohen 2001-2008 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( -20049, '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. 94 © Ellis Cohen 2001-2008 Enforcing Operation-Independent Transition Constraints

95. 95 © Ellis Cohen 2001-2008 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. 96 © Ellis Cohen 2001-2008 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. 97 © Ellis Cohen 2001-2008 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. 98 © Ellis Cohen 2001-2008 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@ = e.sal' * 1.1

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

100. 100 © Ellis Cohen 2001-2008 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. 101 © Ellis Cohen 2001-2008 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. 102 © Ellis Cohen 2001-2008 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. 103 © Ellis Cohen 2001-2008 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. 104 © Ellis Cohen 2001-2008 Cascading Enforcement

105. 105 © Ellis Cohen 2001-2008 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. 106 © Ellis Cohen 2001-2008 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. 107 © Ellis Cohen 2001-2008 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. 108 © Ellis Cohen 2001-2008 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. 109 © Ellis Cohen 2001-2008 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. 110 © Ellis Cohen 2001-2008 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. 111 © Ellis Cohen 2001-2008 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. 112 © Ellis Cohen 2001-2008 Specifying Output-Related Post Conditions

113. 113 © Ellis Cohen 2001-2008 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. 114 © Ellis Cohen 2001-2008 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. 115 © Ellis Cohen 2001-2008 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. 116 © Ellis Cohen 2001-2008 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' = a.street@ AND e.city' = a.city@ AND e.zip' = a.zip@ AND e.isPublic' = 'T' An employee can only see another employee's address if it is public

117. 117 © Ellis Cohen 2001-2008 Using Attribute Matching SOME Emps&( ename': :ename, isPublic': 'T', street': a.street@, city': a.city@, zip': a.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': a.street@, city': a.city@, zip': a.zip@ )

118. 118 © Ellis Cohen 2001-2008 Full Transition Assertions

119. 119 © Ellis Cohen 2001-2008 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 e.deptno@ = 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. 120 © Ellis Cohen 2001-2008 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. 121 © Ellis Cohen 2001-2008 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. 122 © Ellis Cohen 2001-2008 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 attr@ -- refers to the value of attr just after the action is fully executed, including enforcement

123. 123 © Ellis Cohen 2001-2008 Full Transition Assertions EACH Emps&& e WHERE e.empno" IS NULL AND e.deptno' = 10 SATISFIES e.deptno@ = 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 e.empno@ 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. 124 © Ellis Cohen 2001-2008 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 e.deptno@ = 66) When an operation deletes a department, all employees left in that department must be moved to dept 66 (the PARTY department!)

125. 125 © Ellis Cohen 2001-2008 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 e.empno@ IS NULL) When an operation deletes a department, all employees left in that department are deleted

126. 126 © Ellis Cohen 2001-2008 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 e.deptno@ IS NULL AND e.empno@ IS NOT NULL) When an operation deletes a department, all employees left in that department become unassigned