Amendments & Transactions Objectives of the Lecture : To consider amendments to a relation; To consider transactions in SQL.

Relational Amendment l Strictly speaking, relational amendment is unnecessary. We could just use a Delete followed by an Insert. RelVar  Delete ‘set of tuples to be amended’ RelVar  Insert ‘set of tuples that have been amended’ l However it is more convenient for the user to have a single assignment that does the complete amendment. l To achieve this, it must be possible to : l amend a subset of a relation’s tuples; l amend a subset of a tuple’s attributes. ‘Subset of RelVar’  Amend[ amendment to subset of attributes ]

Example of Amendment  Amend[Sal  (1.1 * Sal )] ENo E3 E5 E EName Smith Mitchell Robson M-S S M D Sal ,500 21,000 32, E6 E8 888Blake Jones 888M W 88854,000 68,000 EMPLOYEE ENo E3 E5 E EName Smith Mitchell Robson M-S S M D Sal ,500 21,000 32, E6 E8 888Blake Jones 888M W 88854,000 68,000 EMPLOYEE Sal 23,600 14,250 59,900 75,300 36,250 Amendment Variable Resulting value of variable. All salaries increased by 10% plus £500.

Amendment in Principle ‘Subset of RelVar’  Amend[ ‘set of attribute assignments’ ] This is a subset of any relation in the DB. Each of one or more assignments replaces an attribute value with a new value. The new attribute value may be : - a scalar constant; - an attribute value, of the same type, and taken from the same tuple; - a function or calculation producing a scalar value; - any combination of the above. The set of attribute assignments are executed in parallel. In principle, there can be any number of tuples in the set, including zero !

SQL : Amend l The SQL syntax is :- Update RELATION_NAME Set attribute assignment(s) Where condition ; In the Where phrase, a condition is written that selects the subset of required tuples from RELATION_NAME. These tuples are then amended. l The Where phrase is optional. One can just write Update RELATION_NAME Set attribute assignment(s) ; In this case, all the tuples in RELATION_NAME are amended.

Examples of SQL Amend 1. Amend all the tuples to give everyone a salary increase of 10% plus £500; i.e. the earlier graphical example : Update EMPLOYEE Set Sal = ( 1.1 * Sal ) ; 2. Amend Mitchell’s name to ‘Wilson’, give him/her a new salary of £27,000, and amend their marital status to widowed : Update EMPLOYEE Set Sal = 27000, EName = ‘Wilson’, M-S = ‘W’ ; This changes the three attributes’ values in every tuple affected by the amendment. Oops !! Every tuple in EMPLOYEE is affected by this amendment. Can the effect of this amendment be undone ?

Further Example of SQL Amend Only employee E5‘s attribute values are altered. 111E3555Smith222S22212,500 33E177Robson66D6632,500 E8JonesW68,000 22E566Mitchell44M4421, E6888Blake888M88854,000 ENoENameM-SSal EMPLOYEE 22E566Mitchell44M4421,000 ENoENameM-SSal 66Wilson44W4427,000 ENameM-SSal A candidate key value was used to pick out the correct individual tuple. Update EMPLOYEE Set Sal = 27000, EName = ‘Wilson’, M-S = ‘W’ Where ENo = ‘E5’ ;

Integrity Constraints l A tuple to be inserted into a relation must meet all the integrity constraints for that relation. If it does not, it is rejected with an error message. l An amended version of a tuple must meet all the integrity constraints for that relation. If it does not, it is rejected with an error message. l Even the deletion of a tuple can be rejected (!) if the deletion breaks an integrity constraint, e.g. to keep a fixed number of tuples in the relation.

Time of Validation Checking l It is possible to check some integrity constraints immediately after the update. They are : l data type constraints, l candidate key constraints, l some referential integrity constraints, l some ad hoc constraints. There is no necessity to delay the checking. l It is not possible to check other integrity constraints immediately after the update. They must be deferred to an appropriate time. They are : l some referential integrity constraints, l some ad hoc constraints.

Example of Deferred Checking ENo EName Smith Mitchell Robson 8Blake M-S S M D 8M Sal ,500 21,000 32, ,000 EMPLOYEE JonesW68, E3 E5 E1 4 E6 E RegNo K123 ABC W811 STA JON 1 8V771 PQ Type Corsa 1.3 Starlet GLi Jaguar XK Volvo S80 CAR 22 E3 E5 E1 E6 Owner Referential Integrity means that the new CAR tuple can only be added after the new EMPLOYEE tuple. W333 LNYFocus 1.6LE4 ArcherS40,000E4

Transactions l A transaction is a means of managing updates. At the end of a transaction, the DB must be in a valid state, i.e. all integrity constraints must apply to all relations in the DB. l Definition : a transaction is a complete and indivisible logical unit of work to update the database. It is completely atomic even when it consists of several updates. l All integrity checks, whatever their nature, must be carried out by the end of the transaction, to ensure that the DB remains in a valid state.

Example : a Circular Referential Path Suppose a DB contains 3 relations : Details about projects for departments. Details about departments, including their location. Details about locations, including its project. PROJECT( ProjNo, DeptID, ….. ) DEPARTMENT( Loc, DeptID, …. ) LOCATION( Loc, ProjNo, ….. ) Each relation has a foreign key that references another relation, so they are linked circularly.

Example Transaction with Circularity The 3 relations are shown as tables, with the corresponding referencing and referenced attributes. Transaction BEGIN Update PROJECT Transaction END Update DEPARTMENT Update LOCATION Integrity can only be checked at the transaction’s end.

Timing of Integrity Checks Thus integrity checks can be split into 2 classes, immediate and deferred. l Immediate integrity checks should be done as soon as the update is completed. There is no point in waiting to complete the transaction. As soon as an error is found, the transaction can be terminated without wasting any more time and processing. l Deferred integrity checks must be done by the end of the transaction. They are typically done at the end of the transaction. The transaction must be designed so that the updates put the DB in the correct state by the end of the transaction.

SQL Transactions l A transaction automatically starts whenever the first SQL Insert / Delete / Update statement is met. There is no special command to start a transaction. More Insert / Delete / Update statements, or none, may follow in the transaction. l A transaction ends when a Commit or Rollback statement is met. l Commit ; Ensures any deferred checks are executed; if there are no integrity errors, it makes the updates permanent. l Rollback ; Undoes all the updates to return the DB to its state at the beginning of the transaction.

Deferrability of SQL Checks l In SQL, integrity constraints are deferrable or not deferrable. l Not deferrable constraints are checked immediately. l Deferrable constraints are further defined to be : l I nitially deferred - not checked until a Commit statement is reached. l Initially immediate - checked immediately. l Deferrable constraints can be switched between these two, using the Set Constraint statement. Examples : Set Constraint FKEY1, FKEY9 Deferred ; Set Constraint PKEY6 Immediate;