1. Chapter 7 Database Integrity and Transactions Based on G. Post, DBMS: Designing & Building Business Applications University of Manitoba Asper School of Business 3500 DBMS Bob Travica Updated 2015

2. DBSYSTEMS 2 of 20 Outline  Code in DB system  Triggers  Transactions  Concurrent Access  Locks & Deadlocks  ACID Transactions  Keys creation  DB cursor

3. DBSYSTEMS 3 of 20 DB System Code as Part of DB System  Create code  As triggers = procedures that support biz processes;  In forms and reports (localized effects)  Functions combined with queries (embedded SQL)  User-defined functions Tables Forms & Reports Triggers If (Click) Then MsgBox... End If If inventory < Minimum Then CREATE POrder End If C++ code: Programs combined with SQL statements if (...) { // embedded SQL SELECT … }

4. DBSYSTEMS 4 of 20 User-Defined Functions* CREATE FUNCTION IncreaseSalary (EmpID INTEGER, Amt CURRENCY) BEGIN INPUT EmpID, Amt IF (Amt > 50000) THEN RETURN -1-- error flag, data validation ELSE UPDATE Employee SET Salary = Salary + Amt WHERE EmployeeID = EmpID; PRINT New Salary END * Function is the code (program) that returns a result of processing. A program for increasing a salary for a certain amount (pseudo code).

5. DBSYSTEMS 5 of 20 Events and Triggers (Expanding the topic) Example on slide 4: BEFORE UPDATE on Salary column, run a trigger that checks if a salary ceiling is respected. An event fires (initiates) a trigger (program, code): Common events: SQL-based on rows: INSERT, DELETE, UPDATE SQL-based on tables: ALTER, CREATE, DROP LOGOFF, LOGON – user’s action SERVERERROR, SHUTDOWN, STARTUP – server’s action

6. DBSYSTEMS 6 of 20 Table and Row Triggers time Before Update on a table (all rows) After Update on the table Before Update of a row After Update of the row Update point SQL events support triggers at two points in time - - BEFORE and AFTER Table Row

7. DBSYSTEMS 7 of 20 An After Row Trigger Example CREATE TRIGGER LogSalaryChanges AFTER UPDATE OF Salary ON Employee REFERENCINGOLD ROW As oldrow NEW ROW As newrow FOR EACH ROW INSERT INTO tblSalaryChanges (EmpID, ChangeDate, UserID, OldValue, NewValue) VALUES (newrow.EmployeeID, CURRENT_TIMESTAMP, CURRENT_USER, oldrow.Salary, newrow.Salary); The trigger logs employee ID, date, user’s ID, old salary, and new salary into table SalaryChanges, after each update on the salary column in the Employee table. Useful for auditing.

8. DBSYSTEMS 8 of 20 Cascading Triggers Sale(SaleID, SaleDate, …) OrderItem(OrderID, ItemID, Quantity, …) Order(OrderID, OrderDate, …) Inventory(ItemID, QOH, …) SaleItem(SaleID, ItemID, Quantity, …) AFTER INSERT UPDATE Inventory SET Inventory.QOH=Inventory.QOH – newrow.Quantity AFTER UPDATE WHEN Inventory.QOH < minQuantity INSERT {new order} INSERT {new OrderItem} Increase scope of automation. Take care of dependencies.

9. DBSYSTEMS 9 of 20 Transactions  Definition: Transaction is a sequence of processing tasks (a process) that succeed or fail altogether.  Each task results in a database change but all must be completed for data change to be valid.  Reason: to protect data accuracy against system failures.  Example on right: 1. customer starts transferring money from savings account to checking account. 2. System crashes after subtracting amount from Savings and the amount is not added to Checking. Transaction 1. Subtract $1000 from Savings. (Then, system crashes) 2. Add $1000 to Checking. (Money not added) SavingsAccount Joe Doe Bal.: 5340.92 Subtract: 1000.00 New Bal.: 4340.92 1. $1000 subtracted from Savings but Balance in Checking not increased! Checking Account Joe Doe Bal.: 1424.27 2. Transfer Fails Checking Account Joe Doe Bal.: 1424.27 Add: 1000 x

10. DBSYSTEMS 10 of 20 Designing Transactions  Transactions are programmed  Mark a transaction start - START TRANSACTION  Determine a point of temporary saving of data changes  Mark a transaction end - COMMIT end-result of processing to database, permanent save.

11. DBSYSTEMS 11 of 20 Designing Transactions: SAVEPOINT START TRANSACTION; SELECT … UPDATE tblCustomer.record SAVEPOINT StartOptional; UPDATE tblOrder.newrecord UPDATE tblInventory.QOH IF error THEN ROLLBACK TO SAVEPOINT StartOptional; END IF COMMIT; time start Run tasks SAVEPOINT StartOptional Risky tasks COMMIT Partial ROLLBACK

12. DBSYSTEMS 12 of 20 Concurrent Access  Concurrent Access  Multiple transactions competing for the same data at the same time.  If Order process reads Balance before Payment process ends, the end balance will be incorrect. $950 is the end balance instead of $750 (600+150). Customer at loss. Table AccountPayable read and update 1) Read Balance800 2) Subtract pmt-200 3) Read balance800 4) Save new bal.600 5) Add order150 6) Write balance950 Order transaction Payment transaction

13. DBSYSTEMS 13 of 20 Pessimistic Locks (Serialization)  One answer to problems of concurrent access is to disable it by forcing transactions into a sequence one after another.  A transaction places a SERIALIZABLE lock on data so that no other transaction can access it before the first transaction is completed. 3) Order transaction locked out; System’s message : “Table is locked”. Order transaction, trying to interfere with Payment at step 3 SET TRANSACTION SERIALIZABLE, READ WRITE 1) Read balance800 2) Subtract pmt-200 3) Save new bal.600 Payment transaction

14. DBSYSTEMS 14 of 20 Deadlock  Deadlock = problem with serialized locks: When different transactions use multiple tables concurrently. T1 locks tbl A and requests access to tbl B, while tbl B is locked by T2 that, in turn, requests access to T1. Neither transaction can be completed. 1) Lock tbl A 2) Read tbl B 1) Lock tbl B 2) Update tbl A Transaction 1 (T1) Transaction 2 (T2) Transactions lock out each other, create “deadly embrace” (another name for deadlock). Solution 1 to deadlock: Each transaction waits random time, tries again, releases locks if unsuccessful, and runs itself all over again. Tbl ATbl B

15. DBSYSTEMS 15 of 20 Solution 2 to Deadlock: Lock Manager A closed lock-wait loop that blocks all processes. Lock Manager (part of DBMS) monitors all processes. Temporarily disables some processes to clear the blockage.

16. DBSYSTEMS 16 of 20 Optimistic Locks  Opposite to serialization lock (pessimistic lock); a solution against deadlocks.  Logic:  Assuming that collisions are rare  Record state of DB at READ time of any transaction (no locks)  When a transaction tries to write a new value, system reads data again (current data), and compares it with record at start.  If there is a difference, system sends error message and calls the transaction to execute itself again.

17. DBSYSTEMS 17 of 20 ACID Transactions  Atomicity: all changes succeed or fail together.  Consistency: all data remain internally consistent (when new data is committed, transactions fully executed) and can be validated (e.g., referential integrity).  Isolation: system gives each transaction the perception that it is running in isolation. There are no concurrent access problems (locks do the job).  Durability: When a transaction is committed, all changes are permanently saved even if there is a hardware or system failure (use a master log file for new data).

18. DBSYSTEMS 18 of 20 Methods to Generate Keys 1.The DBMS can generate key values automatically whenever a row is inserted into a table (surrogate key). Drawback: concurrent access to DB system can mix up keys that are generated at the same time (e.g., CustomerID In Customer table, which needs to be reused in the Order table). 2.A separate key generator is called by a programmer to create a new key for a specified table. Prevents mix-ups but requires that programmers write code to generate a key for every table and each row insertion.

19. DBSYSTEMS 19 of 20 Key Generator Create an order for a new customer: (1) Create new key for CustomerID (2) INSERT row into Customer (3) Create key for new OrderID (4) INSERT row into Order Customer Table CustomerID, Name, … Order Table OrderID, CustomerID, …

20. DBSYSTEMS 20 of 20 Database Cursor  Cursor = A type of variable (memory space) that holds entire records. A relic from old DB systems ( Declare Cursor… Close Cursor ) – no relationship with screen cursor (user interface).  Purposes: Complex calculations on rows Comparisons between rows YearSales Diff. 1998104,321 1999145,998 2000276,004 2001362,736 A cursor would read values of sales for the current and previous year, and calculate the difference.