Quick Review of Apr 24 material Sorting (Sections 13.4) Sort-merge Algorithm for external sorting Join Operation implementations (sect. 13.5) –Size estimation –Nested-loop method (and cost) –Sort-Merge Join (and cost) –Hash Join (and cost) –Indexed Join (and cost) –3-way Join

Remaining Material Read over sections the remainder of chapter 13 on your own (you are responsible for the material) We’re going to look at section 14.3 today (following slides) We’ve covered a significant part of the material in chapter 14 already, mixed in with the chapter 13 material in the class notes. Read through chapter 14 yourself; you are responsible for the material. We have five classes remaining (counting today) –the bulk of it will be spent on chapter 15 (15.1-5, 15.9) –additional material will be sections 16.1 (lock-based protocols) –and section 17.4 (log-based recovery) –if possible, we will attempt to finish up in time to use May 13 as a review –May 15? Optional Study Class?

Transformation of Relational Expressions (Section 14.3) Two relational algebra expressions are equivalent if they generate the same set of tuples on every legal database instance. –Important for optimization –Allows one relational expression to be replaced by another without affecting the results –We can choose among equivalent expressions according to which are lower cost (size or speed depending upon our needs) –An equivalence rule says that expression A is equivalent to B; we may replace A with B and vice versa in the optimizer.

Equivalence Rules (1) In the discussion that follows: E x represents a relational algebra expression  y represents a predicate L z represents a particular list of attributes  and  are selection and projection as usual cascade of selections: a conjunction of selections can be deconstructed into a series of them   1  2 (E) =   1 (   2 (E)) selections are commutative   1 (   2 (E)) =   2 (   1 (E))

Equivalence Rules (2) cascade of projections: only the final ops in a series of projections is necessary  L1 (  L2 (…(  L3 (E))…)) =  L1 (E) selections can be combined with Cartesian products and theta joins   (E 1 X E 2 ) = E 1 |X|  E 2   1 (E 1 | X|  2 E 2 ) = E 1 |X|  1  2 E 2 joins and theta-joins are commutative (if you ignore the order of attributes, which can be corrected by an appropriate projection) E 1 |X|  E 2 = E 2 |X|  E 1

Equivalence Rules (3) joins and cross product are associative (E 1 |X|  1  3 E 2 ) |X|  2 E 3 = E 1 |X|  1 (E 2 |X|  2  3 E 3 ) (where  2 involves attributes from only E 2 and E 3. ) (E 1 |X| E 2 ) |X| E 3 = E 1 |X| (E 2 |X| E 3 ) (E 1 X E 2 ) X E 3 = E 1 X (E 2 X E 3 ) (the above two equivalences are useful special cases of the first one)

Equivalence Rules (4) selection distributes over join in two cases: –if all the attributes in  1 appear only in one expression (say E 1 )   1 (E 1 |X|  E 2 ) = (   1 (E 1 )) |X|  E 2 –if all the attributes in  1 appear only in E 1 and all the attributes in  2 appear only in E 2   1   2 (E 1 |X|  E 2 ) = (   1 (E 1 )) |X|  (   2 ( E 2 )) (note that the first case is a special case of the second)

Equivalence Rules (5) projection distributes over join. Given L 1 and L 2 being attributes of E 1 and E 2 respectively: –if  involves attributes entirely from L 1 and L 2 then  L1  L2 (E 1 |X|  E 2 ) = (  L1 (E 1 )) |X|  (  L2 ( E 2 )) –if  involves attribute lists L3 and L4 (both not in L 1  L 2 ) from E 1 and E 2 respectively  L1  L2 (E 1 |X|  E 2 ) =  L1  L2 (  L1  L3 (E 1 )) |X|  (  L2  L4 ( E 2 ))

Equivalence Rules (6) union and intersection are commutative (difference is not) E 1  E 2 = E 2  E 1 E 1  E 2 = E 2  E 1 union and intersection are associative (difference is not) (E 1  E 2 )  E 3 = E 1  (E 2  E 3 ) (E 1  E 2 )  E 3 = E 1  (E 2  E 3 ) selection distributes over union, intersection, set difference   (E 1  E 2 ) =   (E 1 )    (E 2 )   (E 1  E 2 ) =   (E 1 )    (E 2 )   (E 1  E 2 ) =   (E 1 )  E 2   (E 1 - E 2 ) =   (E 1 ) -   (E 2 )   (E 1 - E 2 ) =   (E 1 ) - E 2

Chapter 15: Transactions A transaction is a single logical unit of database work -- for example, a transfer of funds from checking to savings account. It is a set of operations delimited by statements of the form begin transaction and end transaction To ensure database integrity, we require that transactions have the ACID properties –Atomic: all or nothing gets done. –Consistent: preserves the consistency of the database –Isolated: unaware of any other concurrent transactions (as if there were none) –Durable: after completion the results are permanent even through system crashes

ACID Transactions Transactions access data using two operations: –read (X) –write (X) ACID property violations: –Consistency is the responsibility of the programmer –System crash half-way through: atomicity issues –Another transaction modifies the data half-way through: isolation violation –example: transfer $50 from account A to account B T: read(A); A:=A-50; write (A); read (B); B:=B+50; write (B)

Transaction States Five possible states for a transaction: –active (executing) –partially committed (after last statement’s execution) –failed (can no longer proceed) –committed (successful completion) –aborted (after transaction has been rolled back

Transaction States Committed or Aborted transactions are called terminated Aborted transactions may be –restarted as a new transaction –killed if it is clear that it will fail again Rollbacks –can be requested by the transaction itself (go back to a given execution state) –some actions can’t be rolled back (e.g., a printed message, or an ATM cash withdrawal)

Concurrent Execution Transaction processing systems allow multiple transactions to run concurrently –improves throughput and resource utilization (I/O on transaction A can be done in parallel with CPU processing on transaction B) –reduced waiting time (short transactions need not wait for long ones operating on other parts of the database) –however, this can cause problems with the “I” (Isolation) property of ACID

Serializability Scheduling transactions so that they are serializable (equivalent to some serial schedule of the same transctions) ensures database consistency (and the “I” property of ACID) serial schedule is equivalent to having the transactions execute one at a time non-serial or interleaved schedule permits concurrent execution

Serial Schedule To the right T1 and T2 are on a serial schedule: T2 begins after T1 finishes. No problems.

Interleaved Schedule This is an example of an interleaved concurrent schedule that raises a number of database consistency concerns.