-Transactions in SQL -Constraints and Triggers By: Tay Cavett and Jalyn Cosby

-SERIALIZABILITY -ATOMICITY -TRANSACTIONS -READ ONLY TRANSACTIONS -DIRTY READS -OTHER ISOLATION LEVELS

SQL allows programmer to state that a certain transaction must be serializable with respect to other transactions Serial : one at a time, no overlap Strongest isolation level Statements cannot read data that has been modified but not yet committed by other transactions SERIALIZABILITY

Table 1 EXAMPLE Table 2

Transaction 1 transaction2 Once the first SELECT statement execution is completed, transaction 2 starts . This transaction tries to insert a new record into Exam table and commit the change. But, transaction 2 is prevented since transaction 1 which is not yet committed. Thus, transaction 2 has to wait for transaction 1 to commit. transaction2

Transaction 1 execution continues and transaction 2 is started Transaction 1 execution continues and transaction 2 is started. Transaction 2 has to wait to commit its changes until transaction 1 completes. Now it is completed.

ATOMICITY -Certain combinations of operations need to be done atomically -Atomically meaning either both done or neither is done

TRANSACTIONS -Solution to the problems of serializability and atomicity : group database operations in to transactions -Transaction : collection of one or more operations on the database that must be executed atomically *Note* : As a default SQL requires transactions to be executed in a serializable manner -But the user is allowed to specify a less stringent constraint on interleaving of operations from two or more transactions

TRANSACTIONS Two ways to end transactions : -SQL allows programmer to group several statements into a single transaction Use the SQL command to start transaction: START TRANSACTION TRANSACTIONS Two ways to end transactions : COMMIT : causes the transaction to end successfully, whatever changes occurred to the database before commit are now permanently in database ROLLBACK: causes the transaction to abort, terminate unsuccessfully. Whatever changes were made to database before are now undone and permanently deleted from database

READ-ONLY TRANSACTIONS If you have two transactions trying to read and write at the same time there will be serialization problems When a transaction only reads data and does not write we have more freedom to let the transaction run in parallel READ-ONLY TRANSACTIONS Use syntax : SET TRANSACTION READ ONLY; before the transaction begins

Dirty Data: data written by a transaction that has not yet committed Dirty Read: a read of dirty data written by another transaction The risk of reading the dirty data is that the transaction that wrote it may eventually abort Sometimes this matters and sometimes it doesn’t Thus avoid : Time it takes to prevent dirty reads Loss of parallelism when you wait for a 0% chance of a dirty read to occur DIRTY READS

So if we are wanting to risk the dirty read to improve speed of a processing time, we can specify the isolation level to be read uncommitted Syntax : SET TRANSACTION READ WRITE ISOLATION LEVEL READ UNCOMMITTED; READ- UNCOMMITTED The syntax says that the isolation level is read- uncommitted which means that the transaction is allowed to read dirty data

EXAMPLE T2 is trying to use data written by T1 which actually aborted(permanently deleted the data) so now this would be inaccurate data.

READ- COMMITTED Syntax: SET TRANSACTION ISOLATION LEVEL READ COMMITTED; READ- COMMITTED Forbids the reading of dirty (uncommitted) data Allows a transaction running at this isolation level to issue the same query several times and get different answers as long as the answers reflect committed data

EXAMPLE In read-committed isolation levels, there are no dirty reads allowed. However, there can be non-repeatable reads which could produce different results from reading the same data.

REPEATABLE-READ Syntax: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ If a tuple is retrieved for the first time, then we know we will get an identical tuple if that query is repeated. But it is a possibility that if a second or subsequent execution of that query will retrieve phantom tuples, which result from insertions into the database while our transaction is executing REPEATABLE-READ

Could produce phantoms as T2 is querying the same thing two times in a row. The REPEATABLE READ does not stop insertion of newer records so when we are reading data with this isolation level, there is a chance to get Phantom or Dirty Reads. EXAMPLE

-Foreign Keys aka referential integrity. Keys and Foreign Keys -Foreign Keys aka referential integrity. -These constraints assert that a value appearing in one relation must also appear in the primary key component(s) of another relation.

Declaring Foreign-Key Constraints In SQL we may declare an attribute(s) of one relation to be a foreign key, referencing some attribute(s) of a second relation. The implication of this declaration is twofold: 1. The referenced attributes of the 2nd relation must be declared UNIQUE or PRIMARY KEY for their relation. 2.Values of the foreign key appearing in the 1st relation must also appear in the refenced attributes of some type.

2 ways to declare foreign keys: 1. Use the keyword REFERENCES, after an attribute. -REFERENCES<table> (<attribute>) 2. Use the keyword REFERENCES, as an element of the schema -FOREIGN KEY(<attributes>) REFERENCES <table> (<attributes>) -Referenced attributes must be declared Primary Key ot UNIQUE.

Maintaining Referential Integrity 3 Types of Policy: 1. The Default Policy- SQL’s default policy that any modification violating the referential integrity constraint is rejected. 2. The Cascade Policy- Changes to the referenced attribute(s) are mimicked at the foreign key. 3. The Set-Null Policy- Modification to the referenced relation affects a foreign-key value, the latter is changed to NULL.

Constraints on Attributes and Tuples 2 Kinds of Constraints: 1. Constraint on a single attribute. 2. Constraint on tuple as a whole.

Attribute-Based CHECK Constraints -More Complex constraints can be attached to an attribute declaration by the keyword CHECK with a parenthesized condition that must hold for every value of this attribute. -An attribute-based CHECK constraint is checked whenever any tuple gets a new tuple for this attribute. EX. Player(name, number, position) CHECK (number < 100)

Tuple-Based CHECK Constraints -To declare a constraint on the tuples of a single table, we may add to the list of attributes and key or foreign key declarations, in the CREATE Table statement, the keyword CHECK followed by a parenthesized condition. Ex. Tuple-Based CHECK Constraints

Giving Names to Constraints -In order to modify or delete a constraint it must have a name. -To do this we precede the constraint by the keyword CONSTRAINT and a name for the constraint. -Note: Name constraints even if you do not believe you will ever need to refer to it.

Modification/ Altering Constraints - It is possible to add, modify, or delete constraints at any time. -We can switch the checking of a constraint from immediate to a deferred or vice-versa with a SET CONSTRAINT statement. - Other changes can be made using an Alter Constraint statement. -You may drop a constraint using the keyword DROP. - You may also add a constraint using the keyword ADD.

Sources -https://www.sqlservercentral.com/articles/isolation-levels-in-sql-server -https://www2.cs.duke.edu/courses/fall14/compsci316/lectures/11- transaction.pdf -http://infolab.stanford.edu/~ullman/fcdb/aut07/slides/cons.pdf -DATABASE SYSTEMS The Complete Book Second Edition.