Assignment # 1

Submitted By: Adnan Anjum

Part B: Consider the university enrollment database schema:

Student (regnum: integer, name: string, degree: string, age: integer)

Class (ccode: string, schedule: time, room: string, fid: integer)
Enrollment (regnum: integer, ccode: string)
Faculty (fid: integer, name: string, dept: string)

Enrollment relation has one record per student-class pair such that the student is enrolled in the
class. For each of the following transactions, state the SQL isolation level you would use and explain
why you chose it and why you wouldn't use other isolation levels by citing examples of anomalies
(related to Read-Write, Write-Read, Write-Write).

Transaction 1. Enroll a student identified by regnum into the class ISE430.

Transaction 2. Change enrolment for a student identified by regnum from one class to another class.
Transaction 3. Assign a new faculty member identified by fid to the class with the least number of
students.
Transaction 4. For each class, show the number of students enrolled in the class.

Answer:
Transaction1: Read Uncommitted
We are inserting a new enrolment, so we need not worry about any existing row to be
effected by this insert operation.
Transaction2: Read Committed
As in this transaction, we are updating the enrolment (effecting the existing row) , so we must
ensure no other transaction should read this row before commit takes place. Or we need
exclusive lock on this row.
Transaction3: SERIALIZABLE.
As in this transaction we need to perform two steps
Step#1: Select the class with least number of students.
Step#2: Insert a new faculty member for this class in “Faculty”
Now for step1, we must ensure that there should be no other transaction updating or inserting
the Ennoblement, while we are reading for the class with the least number of students i.e.
Phantom read Problem.
Transaction4: SERIALIZABLE.
Again the same case, while we are selecting the data we don’t want any other transaction to
update and insert.

Part C: Consider a database with the following schema:

Student (regnum: integer, name: string, address: string)

Course (ccode: integer, name: string, level: string)
Result (regnum: integer, ccode: integer, marks: real)
Consider the transactions T1, T2, and T3. T1 has . T2 and T3 have same set and order of
instructions but different isolation levels. We first run T1 concurrently with T2 and then we run T1
concurrently with T3 (with following isolation levels).

Isolation Level of T2 Isolation Level of T3

SERIALIZABLE REPEATABLE READ
REPEATABLE READ READ COMMITTED
READ COMMITTED READ UNCOMMITTED

Give a populated database instance and SQL statements for T1 and T2 such that result of running T2
with the given SQL isolation level is different from running T3. For each situation, also explain why
the results are different.

Answer:
create table student ( regnum integer,
name varchar(100),
address varchar(200))

create table Course ( ccode integer,

name varchar(100),
level varchar(100))

create table result ( regnum integer,

ccode integer,
marks decimal(16,10) )

insert into student values (1,'asif','128abc')

insert into student values (2,'haris','138abc')
insert into student values (3,'amina','148abc')
insert into student values (4,'adeel','126abc')
insert into student values (5,'mehreen','121abc')

insert into course values (1,'DataBases','1st')

insert into course values (2,'OOP','1st')
insert into course values (3,'Networks','2nd')
insert into course values (4,'Dataminng','3rd')
insert into course values (5,'Maths','4th')

insert into result values (1,1,79)

insert into result values (2,1,80)
insert into result values (3,2,75)
insert into result values (4,3,79)
insert into result values (5,1,79)
Case 1:

Transaction 2 (SERIALIZABLE) Transaction 1 (SERIALIZABLE)

/* Query 1 */
SELECT * FROM student
WHERE regno BETWEEN 1 AND 5;
/* Query 2 */
INSERT INTO students VALUES
(6,'ali','12888abc' );
COMMIT;
/* Query 1 */
SELECT * FROM student
WHERE regno BETWEEN 1 AND 5;

Both Transactions will execute in serial fashion. And results of both select
statements will be same

Transaction 3 (REPEATABLE READ) Transaction 1 (SERIALIZABLE)

/* Query 1 */
SELECT count(1) FROM student
WHERE regno BETWEEN 1 AND 5;
/* Query 2 */
INSERT INTO students VALUES
(6,'ali','12888abc' );
COMMIT;
/* Query 1 */
SELECT count(1) FROM student
WHERE regno BETWEEN 1 AND 5;

In transactions 3: The first query result will be 5 and next same query result will
be 6. (phantom reads problem)

Case 2:
Transaction 2 (REPEATABLE READ) Transaction 1 (SERIALIZABLE)
/* Query 1 */
SELECT * FROM student
WHERE regno = 5;
/* Query 2 */
/* Query 2 */
UPDATE student set address = ‘xyz’
WHERE regno = 5;
/* Query 1 */ COMMIT;
SELECT * FROM student
WHERE regno = 5;

In the above transaction both statements in transaction 2 will show same result

Transaction 3 (READ COMMITTED) Transaction 1 (SERIALIZABLE)

/* Query 1 */
SELECT * FROM student
WHERE regno = 5;
/* Query 2 */
UPDATE student set address = ‘xyz’
WHERE regno = 5;
COMMIT;
/* Query 1 */
SELECT * FROM student
WHERE regno = 5;

In the above transaction select first select query will show previous address and
second query will show new address xyz. SERIALIZABLE and REPEATABLE READ
isolation level, the DBMS must return the old value. At READ COMMITTED and
READ UNCOMMITTED, the DBMS may return the updated value.

Case 3:

Transaction 2 (READ COMMITTED) Transaction 1 (SERIALIZABLE)

/* Query 1 */
SELECT * FROM student
WHERE regno = 5;
/* Query 2 */
UPDATE student set address = ‘xyz’
WHERE regno = 5;
/* No commit here */

/* Query 1 */
SELECT * FROM student
WHERE regno = 5;
Rollback
In the above transaction both statements in transaction 2 will show same result
as no commit has been done and roll back will not cause any problem
Transaction 3 (READ UNCOMMITTED) Transaction 1 (SERIALIZABLE)
/* Query 1 */
SELECT * FROM student
WHERE regno = 5;
/* Query 2 */
UPDATE student set address = ‘xyz’
WHERE regno = 5;
/* No commit here */
/* Query 1 */
SELECT * FROM student
WHERE regno = 5;

Rollback; /* lock-based DIRTY READ

*/

Query in transaction 3 will show dirty read problem when the rollback will occur
in transaction 1.