University of Manitoba
Asper School of Business
3500 DBMS
Bob Travica
Chapter 7
Database Integrity and Transactions
Based on G. Post, DBMS: Designing & Building Business Applications
Updated 2016
D
B
S
Y
S
T
E
M
S
Outline
 Code in DB system
 Triggers
 Transactions
 Concurrent Access
 Locks & Deadlocks
 ACID Transactions
 Keys creation
 DB cursor
2 of 20
D
B
S
Y
S
T
E
M
S
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
Programs combined with
SQL statements
Tables DB
System
Triggers
Forms &
Reports
If inventory < Minimum
Then
CREATE POrder
End If
C++ code:
if (. . .) {
// embedded SQL
SELECT …
}
If (Click) Then
MsgBox . . .
End If
3 of 20
D
B
S
Y
S
T
E
M
S
User-Defined Functions*
• A program for increasing a salary for a certain amount (pseudo code).
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 Salary // updated Salary
END
* Function is the code (program) that returns a result of processing.
4 of 20
D
B
S
Y
S
T
E
M
S
Events and Triggers
(Expanding the topic)
• 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
• Example on slide 4: BEFORE UPDATE on Salary column, run
a trigger that checks if a salary ceiling is respected.
5 of 20
D
B
Table
• SQL events support triggers at two points in time - BEFORE and AFTER data change
Row
S
Y
S
T
E
M
S
Table and Row Triggers
Before Update
on a table (all rows)
Before Update
of a row
Update
point
After Update
on the table
After Update
of the row
time
6 of 20
D
B
S
Y
S
T
E
M
S
An After Row Trigger Example
• 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.
CREATE TRIGGER LogSalaryChanges
AFTER UPDATE OF Salary ON Employee
REFERENCING OLD 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);
7 of 20
D
B
Cascading Triggers
• Increase scope of automation. Take care of dependencies.
Sale(SaleID, SaleDate, …)
S
Y
S
T
E
M
S
SaleItem(SaleID, ItemID, Quantity, …)
AFTER INSERT
UPDATE Inventory
SET Inventory.QOH=Inventory.QOH –
newrow.Quantity
Inventory(ItemID, QOH, …)
AFTER UPDATE
WHEN Inventory.QOH < minQuantity
INSERT {new order}
INSERT {new OrderItem}
Order(OrderID, OrderDate, …)
OrderItem(OrderID, ItemID, Quantity, …)
8 of 20
D
B
S
Y
S
T
E
M
S
Transactions
 Definition: Transaction is a sequence of
processing tasks (a process) that
succeed or fail altogether.
Transaction
1. Subtract $1000 from Savings.
(Then, system crashes)
2. Add $1000 to Checking.
(Money not added)
 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.
1.
 Example on right:
1. customer starts transferring money
from savings account to checking
account.
SavingsAccount
Joe Doe
Bal.:
5340.92
Subtract: 1000.00
New Bal.: 4340.92
Checking
Account
Joe Doe
Bal.: 1424.27
Add: 1000
2. Transfer
Fails
2. System crashes after subtracting
Checking
amount from Savings and the
amount is not added to Checking. $1000 subtracted from Account
Savings but Balance in
Checking not increased!
Joe Doe
Bal.: 1424.27
9 of 20
D
B
S
Y
S
T
E
M
S
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.
10 of 20
D
B
Designing Transactions: SAVEPOINT
start
S
Y
S
T
E
M
S
SAVEPOINT
StartOptional
Run simple steps
COMMIT
Riskier steps
time
Partial
ROLLBACK
START TRANSACTION;
SELECT …
UPDATE tblCustomer.record
SAVEPOINT StartOptional;
UPDATE tblOrder.newrecord
UPDATE tblInventory.QOH
IF error THEN
ROLLBACK TO SAVEPOINT StartOptional;
END IF
COMMIT;
11 of 20
D
B
S
Y
S
T
E
M
S
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.
Table AccountPayable
read and update
Payment transaction
Order transaction
1) Read Balance
2) Subtract pmt
3) Read balance
4) Save new bal.
5) Add order
6) Write balance
800
-200
800
600
150
950
$950 is the end balance instead of $750 (600+150). Customer at loss.
12 of 20
D
B
S
Y
S
T
E
M
S
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.
SET TRANSACTION SERIALIZABLE, READ WRITE
Payment transaction
1) Read balance
2) Subtract pmt
3) Save new bal.
800
-200
600
Order transaction, trying to
interfere with Payment at step 3
3) Order transaction
locked out;
System’s message :
“Table is locked”.
13 of 2
D
B
Deadlock
Transaction 1 (T1)
 Deadlock = problem with serialized locks:
S
Y
S
T
E
M
S
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.
• 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.
1) Lock tbl A
2) Read tbl B
Tbl A
Tbl B
Transaction 2 (T2)
1) Lock tbl B
2) Update tbl A
14 of 20
D
B
Solution 2 to Deadlock: Lock Manager
A closed lock-wait loop that blocks all processes (transactions).
Data A
S
Y
S
T
E
M
S
Process1
Process2*
Data B
Lock
Process7
Data E
Lock
Wait
Wait
Lock
Process5
Process6
Data D
Wait
Wait
Process3
Process4
Data C
Wait
Wait
Lock
Lock
Wait
Lock Manager (part of DBMS) monitors all processes. Temporarily
disables some processes to clear the blockage.
15 of 20
D
B
Optimistic Locks
 Opposite to serialization lock (pessimistic lock); a solution
against deadlocks.
S
Y
S
T
E
M
S
 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.
16 of 20
D
B
ACID Transactions
 Atomicity: all changes succeed or fail together, i.e., DBS supports
transactions definition and execution.
S
Y
S
T
E
M
S
 Consistency: all data remain internally consistent (when transactions are
executed) and can be validated (e.g., referential integrity applies).
 Isolation: each transaction is processed separately, i.e., DBS supports
record locking.
 Durability: When a transaction is committed, data changes are
permanently saved; a security capability resting on log files and other
techniques.
17 of 20
D
B
Methods to Generate Keys
1.
S
Y
S
T
E
M
S
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.
18 of 20
D
B
Key Generator
Customer Table
Create an order for a new customer:
S
Y
S
T
E
M
S
(1) Create new key for CustomerID
(2) INSERT row into Customer
(3) Create key for new OrderID
(4) INSERT row into Order
CustomerID, Name, …
Order Table
OrderID, CustomerID, …
19 of 20
D
B
S
Y
S
T
E
M
S
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
Year
1998
1999
2000
2001
Sales
Diff.
104,321
145,998
276,004
362,736
A cursor would read values of sales for the
current and previous year, and calculate the
difference.
20 of 20