Amendments & Transactions

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

Slide 2 Relational Amendment 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 However it is more convenient for the user to have a single assignment that does the complete amendment. To achieve this, it must be possible to : amend a subset of a relation s tuples; amend a subset of a tuple s attributes. Subset of RelVar Amend[ amendment to subset of attributes ] Note the following : A subset could be all the tuples in a relation / attributes in a tuple, or a proper subset - perhaps just one - tuple in a relation / attribute in a tuple (or even in theory the empty subset, although this would result in no amendments being made!). The amendment is not like a traditional assignment, because we are not assigning tuples to the relvar, but assigning changes to a subset of the relvar.

Slide 3 Example of Amendment EMPLOYEE ENo EName M-S Sal E3 1 Smith 5 2S 12,500 2 E5 2 Mitchell 6 M 4 21,000 46 E1 3 Robson 7 D 6 32,500 6 E6 4 E8 Blake 8 Jones 8M W 54,000 8 68,000 EMPLOYEE ENo EName M-S Sal E3 1 Smith 5 2S 12,500 14,250 2 E5 2 Mitchell 6 M 4 21,000 23,600 46 E1 3 Robson 7 D 6 32,500 36,250 6 E6 4 Blake 8 8M 54,000 59,900 8 E8 Jones W 68,000 75,300 Amend[Sal 500 + (1.1 * Sal )] Variable Amendment Resulting value of variable. All salaries increased by 10% plus 500. The relational variable EMPLOYEE is graphically displayed. The amendment is not a relational value but an instruction to amend an attribute. The instruction is expressed like a traditional programming language assignment. The LHS of this attribute assignment is the name of the attribute whose value is to be amended; the RHS of it is an expression that evaluates to the new value of the attribute that is to replace the original value. In the above example, the new attribute value of Sal is based in part on the old attribute value of Sal. The assignment of a new attribute value is then applied to all the tuples on the LHS of the relational assignment.

Slide 4 Amendment in Principle Subset of RelVar Amend[ set of attribute assignments ] This is a subset of any relation in the DB. The set of attribute assignments are executed in parallel. Each of one or more assignments replaces an attribute value with a new value. In principle, there can be any number of tuples in the set, including zero! 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. As many or as few attributes as required can be amended in the amendment statement. The order in which the amendments are carried out in each tuple does not matter; logically they are all carried out simultaneously in parallel, and independently of each other. Likewise each tuple on the LHS of the relational assignment is logically amended simultaneously in parallel, and independently of each other. The implementation may well have to loop through each tuple in turn, and through each attribute in each tuple in turn to actually do the work, but this will be invisible to the DB user. The RHS of an attribute assignment can be any valid expression, from a simple constant value (e.g. 3, Julie ) to a very complicated calculation. If one or more attribute names appears in the RHS of an attribute assignment, then the values of those named attributes that will be used will be those in the same tuple as that of the attribute value that is being amended.

Slide 5 SQL : Amend 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. 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. In SQL, update is given the more specific meaning of amend. The keyword Update at the beginning of the statement indicates that an amendment is to be carried out. Thus the first 2 words of an amendment statement correspond to the amendment assignment and the LHS relvar, the Set phrase contains the attribute amendment assignments (using = as the assignment symbol) with the following Where phrase specifying which tuples of the relvar are to be amended (and the omission of the Where phrase specifying that all the tuples in the relvar are to be amended). Note that Set here means set the column(s) to ; it is not referring to a mathematical set. The Where phrase is used in an SQL Update in exactly the same way as it is used in an SQL Delete.

Slide 6 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 = 500 + ( 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? Note how the Where phrase (or lack of it) determines which tuples are amended. In the first example above, because the new salary depends on the old salary, although the same calculation will be applied in each tuple, each salary value can be updated to a different value. In the second example above, because the new values of Sal, EName and M-S are constants, every tuple in EMPLOYEE will be updated to a salary of 27,000, a name of Wilson, and a marital status of widowed!

Slide 7 Further Example of SQL Amend Update EMPLOYEE Set Sal = 27000, EName = Wilson, M-S = W Where ENo = E5 ; EMPLOYEE ENo EName M-S Sal E5 2 Mitchell Wilson 6 4M 4W 21,000 27,000 4 E6 4 Blake 8 8M 54,000 8 E1 3 Robson 7 6D 32,500 6 E3 1 Smith 5 2S 12,500 2 E8 Jones W 68,000 Only employee E5 s attribute values are altered. A candidate key value was used to pick out the correct individual tuple. Comparing this with the earlier graphical display of the EMPLOYEE relation, only one tuple in it has now been amended. To be certain of amending one specific tuple, a candidate key must be used in the condition, because it is the only thing guaranteed to identify one particular tuple. It is also possible to amend an attribute so that it becomes null instead of containing a value. For example : Update EMPLOYEE Set Sal = NULL Where ENo = E5 ; This sets the value of E5 s salary to be null. Update EMPLOYEE Set Sal = NULL ; This sets everyone s salary to be null! Note that = is still used for value assignment, even though no value is actually being assigned! (Indeed null could replace a value!) Note that, once again, NULL is a keyword here; so it can be in upper or lower case as long as it is not in speech marks (which will cause it to be treated as just another piece of text).

Slide 8 Integrity Constraints 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. 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. 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. So far, we have assumed none of the insertions, deletions, or amendments break the integrity constraints. In practice this will not always be so. We therefore need to consider this aspect of updating.

Slide 9 Time of Validation Checking It is possible to check some integrity constraints immediately after the update. They are : data type constraints, candidate key constraints, some referential integrity constraints, some ad hoc constraints. There is no necessity to delay the checking. It is not possible to check other integrity constraints immediately after the update. They must be deferred to an appropriate time. They are : some referential integrity constraints, some ad hoc constraints. Update is used here with its general meaning of any alteration of the relation be it due to an insertion, a deletion, or an amendment. From the DB user s point of view, the DBMS will appear to carry out an update, then check all the integrity constraints, and finally undo the update if any constraint is broken. An efficient implementation will validate the update before executing it.

Slide 10 Example of Deferred Checking CAR RegNo K123 5ABC W811 6 STA JON 71 V771 8PQ Type Corsa 1.3 Starlet GLi Jaguar XK Volvo S80 W333 LNY Focus 1.6L Owner E3 E5 2 E1 E6 E4 EMPLOYEE ENo EName M-S Sal E3 1 E5 2 E1 3 Smith 5 Mitchell 6 Robson 7 2S M 4 D 6 12,500 2 21,000 4 32,500 6 E6 4 E8 E4 Blake 8 8M 54,000 8 Jones W 68,000 Archer S 40,000 Referential Integrity means that the new CAR tuple can only be added after the new EMPLOYEE tuple. Suppose a new employee with ENo E5 joins the company and has a car. A tuple in each of the relations EMPLOYEE and CAR will need to be inserted to represent this. If the new CAR tuple were added before the new EMPLOYEE tuple, then the foreign key Owner in CAR would not reference any candidate key value in EMPLOYEE, thereby breaking the referential integrity constraint. If the two tuples were added in the reverse order, there would be no problem; however there is no certainty as to which order will be used, because from the user s point of view, they are both part of one transaction.

Slide 11 Transactions 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. 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. 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. The addition of a new employee and their car is an example of a transaction, as is the addition of a new employee who has no car. Likewise the deletion of an employee, with or without their car, is a transaction. Transactions can involve one relation or many. They can also be require insertions, deletions and/or amendments, of one or many tuples.

Slide 12 Example : a Circular Referential Path Suppose a DB contains 3 relations : Details about projects for departments. Details about locations, including its project. PROJECT( ProjNo, DeptID,.. ) LOCATION( Loc, ProjNo,.. ) Each relation has a foreign key that references another relation, so they are linked circularly. DEPARTMENT( Loc, DeptID,. ) Details about departments, including their location. The PROJECT relation has a foreign key DeptID that references the DEPARTMENT relation. The DEPARTMENT relation has a foreign key Loc that references the LOCATION relation. The LOCATION relation has a foreign key ProjNo that references the PROJECT relation. Thus if there are any updates involving projects for departments in locations, it is likely that all three relations will have to be updated. In this case, it will not even be possible to derive a particular order for updating that will avoid the referential integrity problem, due to the circularity. All three will have to be appropriately updated, and then the validity checks carried out to ensure integrity constraints are maintained.

Slide 13 Example Transaction with Circularity The 3 relations are shown as tables, with the corresponding referencing and referenced attributes. Update PROJECT Update DEPARTMENT Update LOCATION Transaction BEGIN Integrity can only be checked at the transaction s end. Transaction END In principle, it doesn t matter which relation is updated first, or which route round the circle is taken - a circle has no end! - although pragmatic considerations might suggest certain starting points and directions.

Slide 14 Timing of Integrity Checks Thus integrity checks can be split into 2 classes, immediate and deferred. 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. 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 follows these ideas of transactions and integrity checking, as we will see next, although SQL s integrity checking is a little more complex than this. There are other aspects of transactions to do with solving the problems of multiple users trying to update the same data at the same time, but they are beyond the scope of this course.

Slide 15 SQL Transactions 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. A transaction ends when a Commit or Rollback statement is met. Commit ; Ensures any deferred checks are executed; if there are no integrity errors, it makes the updates permanent. Rollback : Undoes all the updates to return the DB to its state at the beginning of the transaction. Thus a simple transaction may look like : Insert Commit ; A more complex transaction may look like : Insert Update Insert Delete Commit ; If at the end of a transaction the integrity constraints are not satisfied, as well as issuing an error message, the Commit statement will roll back the transaction if any insert, delete and/or update statements have already been successfully executed during the transaction, so that the DB returns to the state it was in at the beginning of the transaction. Rollback is important generally for correcting mistakes made in updating. Oracle does have a Set Transaction statement that can be used to initiate a transaction, although that is not its prime raison d etre (which is, via various possible parameters, to manage the transaction in other ways, beyond the scope of this course).

Slide 16 Deferrability of SQL Checks In SQL, integrity constraints are deferrable or not deferrable. Not deferrable constraints are checked immediately. Deferrable constraints are further defined to be : Initially deferred - not checked until a Commit statement is reached. Initially immediate - checked immediately. Deferrable constraints can be switched between these two, using the Set Constraint statement. Examples : Set Constraint FKEY1, FKEY9 Deferred ; Set Constraint PKEY6 Immediate; When an integrity constraint is assigned, it will be one of : not deferrable, i.e. immediate, deferrable, and set to be deferred to start with (i.e. initially), deferrable, but set to be immediate to start with (i.e. initially). The keywords for these three possibilities are : Not Deferrable, Deferrable Initially Deferred, Deferrable Initially Immediate. Put the required keywords immediately after the constraint definition. For example : Constraint PKEY6 Primary Key( ID ) Not Deferrable Not Deferrable is the default; so all constraints seen in slides so far will be immediately checked. After the initial setting of a deferrable constraint, the Set Constraint statement can be used at any time thereafter to switch it between immediate checking and defer-to- Commit-time checking. Note that Set Constraint uses an integrity constraint name or the keyword All to reference constraints, and can only be applied to deferrable constraints. The Set Constraint statement can be issued at any point in a transaction, and remains in force until the end of the transaction or until superseded by another Set Constraint statement.