DB Integrity & Transactions Part 2 IS240 – DBMS Lecture #12 – 2010-04-12 M. E. Kabay, PhD, CISSP-ISSMP Assoc. Prof. Information Assurance School of Business & Cyber Studies, Norwich University mailto:mkabay@norwich.edu V: 802.479.7937 Class Notes Copyright © 2004 M. E. Kabay. All rights reserved. Page 1

Objectives Define elements of ACID transactions Atomicity Consistency Isolation Durability Define SQL Isolation Levels What are phantom rows and how do we avoid them? How are internal key values generated and used in updates in the face of concurrency? What is the purpose of database cursors? Copyright © 2004 M. E. Kabay. All rights reserved. Page 2

Topics ACID Transactions SQL 99/2003 Isolation Levels Phantom Rows Generated Keys Database Cursors Sally’s Pet Store Inventory Copyright © 2004 M. E. Kabay. All rights reserved. Page 3

ACID Transactions Atomicity: all changes succeed or fail together. Consistency: all data remain internally consistent (when committed) and can be validated by application checks. Isolation: The system gives each transaction the perception that it is running in isolation. There are no concurrent access issues. Durability: When a transaction is committed, all changes are permanently saved even if there is a hardware or system failure. ACID transactions. The acronym highlights four of the main integrity features required of transactions. Copyright © 2004 M. E. Kabay. All rights reserved. Page 4

SQL 99/2003 Isolation Levels READ UNCOMMITTED Problem: might read dirty data that is rolled back Restriction: not allowed to save any data READ COMMITTED Problem: Second transaction might change or delete data Restriction: Need optimistic concurrency handling REPEATABLE READ Problem: Phantom rows caused by concurrent access SERIALIZABLE Provides same level of control as if all transactions were run sequentially. But, still might encounter locks and deadlocks Remember to LOCK in SAME ORDER and UNLOCK in REVERSE ORDER! Copyright © 2004 M. E. Kabay. All rights reserved. Page 5

Phantom Rows ALICE BOB ALICE SELECT SUM(QOH) FROM Inventory WHERE Price BETWEEN 10 and 20 Result: 5 + 4 + 8 = 17 BOB INSERT INTO Inventory VALUES (121, 7, 16) VALUES (122, 3, 14) 17 8 120 16 7 121 14 3 122 22 119 12 4 118 30 117 6 113 15 5 111 Price QOH ItemID Included in first query Additional or changed rows will be included in the second query, which may cause contradictions in results Phantom rows. The first SELECT statement will select only three rows of data. When the second transaction runs, additional rows will match the criteria, so that the second time the query runs, it will return a different result, because it includes the phantom rows. ALICE SELECT SUM(QOH) FROM Inventory WHERE Price BETWEEN 10 and 20 Result: 5 + 4 + 8 + 7 + 3 = 27 Copyright © 2004 M. E. Kabay. All rights reserved. Page 6

Generated Keys Create an order for a new customer: Customer Table CustomerID, Name, … 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 Order Table OrderID, CustomerID, … Generated keys. Creating an order for a new customer requires generating a CustomerID key that is used in the Customer table and must be stored so it can be used in the Order table. Problem: What if someone concurrently generates another autokey just as you are trying to use the one you created? Generally the DBMS remembers only the latest autokey! Copyright © 2004 M. E. Kabay. All rights reserved. Page 7

Methods to Generate Keys The DBMS generates key values automatically whenever a row is inserted into a table. Drawback: it is tricky to get the generated value to use it in a second table. A separate key generator is called by a programmer to create a new key for a specified table. Drawback: programmers have to write code to generate a key for every table and each row insertion. Overall drawbacks: neither method is likely to be transportable. If you change the DBMS, you will have to rewrite the procedures to generate keys. Copyright © 2004 M. E. Kabay. All rights reserved. Page 8

Auto-Generated Keys Create an order for a new customer: INSERT row into Customer Get the key value that was generated Verify the key value is correct. How? INSERT row into Order Major problem: Step 2 requires that the DBMS return the key value that was most recently generated. How do you know it is the right value? What happens if two transactions generate keys at almost the same time on the same table? Auto-generated keys. The process seems relatively easy when the DBMS automatically generates keys. However, what happens at step 2 if two transactions generate a new key value on the same table at almost the same time? Copyright © 2004 M. E. Kabay. All rights reserved. Page 9

Key-Generation Routine Create an order for a new customer: Generate a key for CustomerID INSERT row into Customer Generate a key for OrderID INSERT row into Order This method ensures that unique keys are generated You can use the keys in multiple tables because you know the value But none of it is automatic Always requires procedures and sometimes data triggers Key-generation routine. The steps are not difficult, but programmers must add them for every table and every routine that inserts data. Copyright © 2004 M. E. Kabay. All rights reserved. Page 10

Topics ACID Transactions SQL 99/2003 Isolation Levels Phantom Rows Generated Keys Database Cursors Sally’s Pet Store Inventory Copyright © 2004 M. E. Kabay. All rights reserved. Page 11

Database Cursors Purpose Year Sales 1998 104,321 1999 145,998 2000 276,004 2001 362,736 Purpose Track through table or query one row at a time. Data cursor is a pointer to active row. Why? Performance. SQL cannot do everything. Complex calculations. Compare multiple rows. Copyright © 2004 M. E. Kabay. All rights reserved. Page 12

Database Cursor Program Structure DECLARE cursor1 CURSOR FOR SELECT AccountBalance FROM Customer; sumAccount, balance Currency; SQLSTATE Char(5); BEGIN sumAccount = 0; OPEN cursor1; WHILE (SQLSTATE = ‘00000’) FETCH cursor1 INTO balance; IF (SQLSTATE = ‘00000’) THEN sumAccount = sumAccount + balance; END IF END CLOSE cursor1; -- display the sumAccount or do a calculation SQL cursor structure. DECLARE, OPEN, FETCH, and CLOSE are the main statements in the SQL standard. Copyright © 2004 M. E. Kabay. All rights reserved. Page 13

Cursor Positioning with FETCH DECLARE cursor2 SCROLL CURSOR FOR SELECT … OPEN cursor2; FETCH LAST FROM cursor2 INTO … Loop… FETCH PRIOR FROM cursor2 INTO … End loop CLOSE cursor2; FETCH positioning options: FETCH NEXT next row FETCH PRIOR prior row FETCH FIRST first row FETCH LAST last row FETCH ABSOLUTE 5 fifth row FETCH RELATIVE -3 back 3 rows FETCH options. A scrollable cursor can move in either direction. This code moves to the last row and then moves backward through the table. Other FETCH options include FIRST, ABSOLUTE, and RELATIVE. Copyright © 2004 M. E. Kabay. All rights reserved. Page 14

Problems with Multiple Users Original Data Modified Data Name Sales Alice 444,321 Carl 254,998 Donna 652,004 Ed 411,736 Name Sales Alice 444,321 Bob 333,229 Carl 254,998 Donna 652,004 Ed 411,736 New row is added--while code is running. The SQL standard can prevent this problem with the INSENSITIVE option: DECLARE cursor3 INSENSITIVE CURSOR FOR … Transaction concurrency in cursor code. Your cursor code has tracked down through the data to Carl. It then tries to go back to the prior row with FETCH PRIOR. But, if another transaction has inserted a new row (Bob) in the meantime, your code will pick up that one instead of the original (Alice). But this is an expensive approach because the DBMS usually makes a copy of the data. Instead, avoid moving backwards. Copyright © 2004 M. E. Kabay. All rights reserved. Page 15

Changing Data with Cursors DECLARE cursor1 CURSOR FOR SELECT Year, Sales, Gain FROM SalesTotal ORDER BY Year FOR UPDATE OF Gain; priorSales, curYear, curSales, curGain BEGIN priorSales = 0; OPEN cursor1; Loop: FETCH cursor1 INTO curYear, curSales, curGain UPDATE SalesTotal SET Gain = Sales – priorSales WHERE CURRENT OF cursor1; priorSales = curSales; Until end of rows CLOSE cursor1; COMMIT; END Year Sales Gain 2000 151,039 2001 179,332 2002 195,453 2003 221,883 2004 223,748 Sales analysis table. A standard SELECT query can compute and save the sales total by year. You now need to write a cursor-based procedure to compute the sales gain from the prior year. Copyright © 2004 M. E. Kabay. All rights reserved. Page 16

Sally’s Pet Store Inventory Inventory method 1: calculate the current quantity on hand by totaling all purchases and sales every time the total is needed. Drawback: performance Inventory method 2: keep a running balance in the inventory table and update it when an item is purchased or sold. Drawback: tricky code Also, you need an adjustment process for “inventory shrink” Corrections of mistakes Copyright © 2004 M. E. Kabay. All rights reserved. Page 17

Inventory QuantityOnHand Merchandise ItemID Description QuantityOnHand ListPrice Category Add items purchased Subtract items sold Adjust for shrink SaleItem SaleID ItemID Quantity SalePrice Processing inventory changes. When an item is sold, the quantity sold is entered into the SaleItem table. This value has to be subtracted from the QuantityOnHand in the Merchandise table. Copyright © 2004 M. E. Kabay. All rights reserved. Page 18

Inventory Events A USER MAY Add a row. Delete a row. Update Quantity. SaleItem For a new sale, a row is added to the SaleItem table. A sale or an item could be removed because of a clerical error or the customer changes his or her mind. A SaleItem row will be deleted. An item could be returned, or the quantity could be adjusted because of a counting error. The Quantity is updated in the SaleItem table. An item is entered incorrectly. ItemID is updated in the SaleItem table. SaleID ItemID Quantity SalePrice A USER MAY Add a row. Delete a row. Update Quantity. Update ItemID. SaleItem events. Driven by business operations, four major events can arise in the SaleItem table. The QuantityOnHand must be altered in the Merchandise table for each of these events. Copyright © 2004 M. E. Kabay. All rights reserved. Page 19

New Sale: Insert SaleItem Row CREATE TRIGGER NewSaleItem AFTER INSERT ON SaleItem REFERENCING NEW ROW AS newrow FOR EACH ROW UPDATE Merchandise SET QuantityOnHand = QuantityOnHand – newrow.Quantity WHERE ItemID = newrow.ItemID; New Sale trigger. Inserting a new row triggers the event to subtract the newly entered quantity sold from the quantity on hand. Copyright © 2004 M. E. Kabay. All rights reserved. Page 20

Delete SaleItem Row CREATE TRIGGER DeleteSaleItem AFTER DELETE ON SaleItem REFERENCING OLD ROW AS oldrow FOR EACH ROW UPDATE Merchandise SET QuantityOnHand = QuantityOnHand + oldrow.Quantity WHERE ItemID = oldrow.ItemID; Delete Row trigger. This trigger reverses the original subtraction by adding the Quantity back in. Copyright © 2004 M. E. Kabay. All rights reserved. Page 21

Inventory Update Sequence SaleItem Clerk Event Code Merchandise SaleID 101 ItemID 15 Quantity 10 Quantity 8 Enter new sale item, enter Quantity of 10. 3. Change Quantity to 8. 2. Subtract Quantity 10 from QOH. 4. Subtract Quantity 8 from QOH. QOH 50 QOH 40 QOH 32 Solution that corrects for change 4. Add original Quantity 10 back and subtract Quantity 8 from QOH. QOH 42 OOPS Errors arise if you do not handle changes in quantity. If Quantity is changed, you must add back the old value and then subtract the new value. The top steps show the error in QOH if you do not handle changes. Copyright © 2004 M. E. Kabay. All rights reserved. Page 22

Quantity Changed Event CREATE TRIGGER UpdateSaleItem AFTER UPDATE ON SaleItem REFERENCING OLD ROW AS oldrow NEW ROW AS newrow FOR EACH ROW UPDATE Merchandise SET QuantityOnHand = QuantityOnHand + oldrow.Quantity – newrow.Quantity WHERE ItemID = oldrow.ItemID; Update Quantity trigger. If Quantity is changed, you must add back the old value and then subtract the new value. Copyright © 2004 M. E. Kabay. All rights reserved. Page 23

ItemID or Quantity Changed Event CREATE TRIGGER UpdateSaleItem AFTER UPDATE ON SaleItem REFERENCING OLD ROW AS oldrow NEW ROW AS newrow FOR EACH ROW BEGIN UPDATE Merchandise SET QuantityOnHand = QuantityOnHand + oldRow.Quantity WHERE ItemID = oldrow.ItemID; SET QuantityOnHand = QuantityOnHand – newRow.Quantity WHERE ItemID = newrow.ItemID; COMMIT; END Final update trigger. If the ItemID is changed, you must restore the total for the original item and subtract the new quantity from the new ItemID. Copyright © 2004 M. E. Kabay. All rights reserved. Page 24

DISCUSSION Copyright © 2004 M. E. Kabay. All rights reserved. Page 25