Class and Objects

UNIT 1 CLASS AND OBJECTS

Structure Page Nos.
1.0 Introduction 5
1.1 Objectives 5
1.2 Class Fundamentals 6
1.2.1 Creating objects
1.2.2 Assigning object reference variables
1.3 Introducing Methods 10
1.3.1 Static methods
1.3.2 Constructors
1.3.3 Overloading constructors
1.4 this Keyword 16
1.5 Using Objects as Parameters 17
1.5.1 Argument passing
1.5.2 Returning objects
1.6 Method Overloading 20
1.7 Garbage Collection 20
1.8 The Finalize ( ) Method 21
1.9 Summary 23
1.10 Solutions/Answers 23

1.0 INTRODUCTION
Object orientation is based on real life philosophy. In Unit 1 and 2 of Block 1 you are
introduced to basic concepts of Object Oriented technology. It is emphasized that “in
Object Oriented Programming (OOP) more emphasis is given on data” .To achieve
this objective concept of classification is used which results into classes, that are the
major component of object-oriented programming. Object Oriented Programming
forces to think in terms of objects and interaction between objects them.
In this unit you will study how Java supports class, objects, and how objects are used
in problem solving. You will also study how to use methods for communication
between objects. We will use a special kind of methods known as static method in
programs writing .To initialize objects at the time of creation we use constructors.
Also in this unit we will learn the concept of constructor overloading. Further you will
study use of this key word in programs. We will discuss the memory de–allocation
technique used in Java.
Finally we will discuss various arguments (parameters) passing schemes, how an
object is passed as parameter and object return from a function.

1.1 OBJECTIVES
After going through this unit you will be able to explain:

• what is a class and how it is created in Java;

• what are objects and how they are declared;
• what are methods and their uses;
• what are static members;
• how to use constructors;
• how to use different argument passing techniques and use of objects as
arguments in functions;
• how to return objects from function, and
• garbage collection and finalized method in Java.
5
Object Oriented Concepts
and Exceptions Handling 1.2 CLASS FUNDAMENTALS
You have studied class in Block 1 of this course. Now you will learn how classes are
defined and used in Java.

The class construct is what makes Java an object-oriented language. A Java class is a
group of values with a set of operations to manipulate this values. Classes facilitate
modularity and information hiding. Classes are used to define a new data type. Once a
new data type is defined, variables of this data type can be created in program for
solving problems. Variables of a class are known as objects of that class, and carry the
properties of the class with values. Thus it can be said that, “a class is a template for
an object of the properties and object is an instance of a class”.

Before defining a class it must be clear to you for what purpose you are going to
create class. i.e. “ the nature and exact form of the class” should be reflected in class
definition.

Now let us see how a class is defined in Java

General form of a Class:
class className
{
type inst_var1;
type inst_var2;
type inst_var3;
…
…
type inst_varN;
type method_name1(arguments)
{
// body of method
}
type methodname2 (arguments)
{
//body of method
}
…
….
}

You can see that class is declared by the use of the class keyword. Data and methods
are defined within the class. Being the part of the class, data (variables) and methods
are called member of the class. Data are called member data or instance variable of
the class and methods are called member functions of the class. Member functions
are defined within a class and act on the data member of the class.

As we have discussed before defining a class, the data members and member
functions of a class should be decided. If we take Student class and want to display
basic information of the student, first we have to decide the data members required to
represent basic information, then we need a member function to display basic
information.

Now you can see how a class Student is defined

class Student

{
String name;
String course
int roll_no;

6
} Class and Objects

The class Student is not yet complete because in this class only data members are
there. Still a member function to display basic information is needed.

Complete definition of class Student will have three data members-name, course and
age and one member function display_info( ).
//class definition
class Student
{
String name;
String course ;
int age;
void display_info( ) // function for displaying basic information
{
System.out.println(“ Student Information”);
System.out.println(“Name:”+name);
System.out.println(“Course:”+course);
System.out.println(“Age:”+age);
}
}
// end of Student class

As mentioned earlier class defines a new data type. In our case Student is a new data
type. Now Student can be used to declare objects of Student class.
An object of Student class can be created as follows:

Student student_1 = new Student( );

As this statement is executed an object student 1 of Student class is created. You will
see a detailed discussion of this type of statements in a later section of this unit.
Each time you create an object of a class a copy of each instance variables defined in
the class is created. In other words you can say that each object of a class has its own
copy of data members defined in the class. Member functions have only one copy and
shared by all the objects of that class. All the objects may have their own value of
instance variables. As given in Figure1 every object of class Student will have its own
copy of name, course, and age but only one copy of method display_info( ) for all the
objects.

Name: Manoj
Course: CIC
Age: 22

Name: Manoj Display_info ()

Course: BCA

Age: 25

Name: Manoj

Course: MCA

Age: 29

Figure 1: Objects of class Student

7
Object Oriented Concepts Now let us see how objects are declared and used inside a program.
and Exceptions Handling

1.2.1 Creating Objects

An object of a class can be created by performing these two steps.

1. Declare a object of class.

2. Acquire space for and bind it to object.
Why are two steps needed?
In the first step only a reference to an variable is created, no actual object’s exists. For
actual existence of an object memory is needed. That is acquired by using new
operator.

The new operator in Java dynamically allocates memory for an object returns a
reference to object and binds the reference with the object. Here reference to object
means address of object. So it is essential in Java that all the objects must be
dynamically allocated.
Declaring Student object
Step 1:
Student student1; // declaring reference to object

Step 2:
Student1 = new Student( ); // allocating memory

In normal practice these two steps are written in a single statement as

Student student1 = new Student( );

Now you can see a complete Java program for displaying basic information of
students
//program
class Student
{
String name;
String course ;
int age;
void display_info( ) // function for displaying basic information
{
System.out.println(“ Student Information”);
System.out.println(“Name:”+name);
System.out.println(“Course:”+course);
System.out.println(“Age:”+age);
}
}
// end of Student class
class Display_Test
{
public static void main( String para[])
{
Student student1;
student1 = new Student();
sudent1.name = “Mr.Ravi”; //assigning value to name variable of student1 object
student1.course = “MCA”; //assigning value to course variable of student1 object
student1.age = 23; //assigning value to age variable of student1 object
student1.display_info(); // invoking display_info( ) method on student1 object
}
}
The output of this program is:

8
Name:Mr.Ravi Class and Objects
Course:MCA
Age:23

If you observe this program, instance variables of student1 are assigned values. Is
there any other way of assigning value to instance variables? For the questions the
answer is yes. An object created can be used only if its instance variables contain
value. The values of instance variables, represent the state of an objects for example,
student1 object in this program. At present student is representing a student named
Ravi, a MCA student of age 23.If you change the value of any of the instance
variable’s the state of the object will change.

Two approaches can be used for assigning value to the instance variables of the
objects. In first approval create an object and initialize instance variables one by one,
as done in the above program. Initialization of instance variable is done by using dot(
.) operator. Dot(.) operator is used to access members (data and method both) of the
objects.

object_name.variable_name = value;

But this method of initialization of objects is not convenient because all instance
variables of the object must be initialized carefully, and this exercise should be done
for all objects before they are used. In this method of initialization there is a chance of
skipping some variables unassigned where large number of objects are to be
initialized.

To overcome this problem second approach of object initialization with the help of
constructors, can be used. We will discuss how constructors are used in the next
section of this unit.

1.2.2 Assigning Object Reference Variables

One object can be assigned to another object, of same type but it works very different
than a normal assignment. Let us see it with the help of a program.

class Person
{
String name;
int age ;
String address;
void Display( )
{
System.out.println("Person Information:"+name +" ("+age +")"+"\n"+address);
}
}
class Reference_Test
{
public static void main(String[] args)
{
Person p = new Person();
Person q = new Person();
p.name= "Mr.Naveen Kumar";
p.age= 24;
p.address = "248,Sector 22, Noida";
p.Display();
q = p;// q refer to p
q.name = "Mr.Suresh";
q.address = "22,Mahanadi,IGNOU,Maidan Garhi";
p.Display();
9
Object Oriented Concepts q.Display();
and Exceptions Handling }
}

Output of this program is:

Person Information:Mr.Naveen Kumar (24)
248,Sector 22, Noida
Person Information:Mr.Suresh (24)
22,Mahanadi,IGNOU,Maidan Garhi
Person Information:Mr.Suresh (24)
22,Mahanadi,IGNOU,Maidan Garhi

In this program two objects p and q are created. Object p is initialized with some
values, then Display method is called through object p. It displays the information of
object p. Further, object p is assigned to object q as reference variable. You can see in
the figure both object p and object q are referring to the same object. Thus any change
made in object p or q changes will be reflect the both p and q. You can see in the
program that changes made in name and address by q are reflected in p also.
Whenever in a program this type of referencing of variables is used care should be
taken while changing the values of instance variables of object being referred.

An object is a class instance. The class of an object determines what it is and how it
can be manipulated. A class encapsulates methods, data, and implementation of
methods. This encapsulation is like a contract between the implementer of the class
and the user of that class.

 Check Your Progress 1

1) Explain the process of object definition in Java.

……………………………………………………………………………………
……………………………………………………………………………………

2) What is the advantage of having member data and member functions within the
class?

……………………………………………………………………………………
……………………………………………………………………………………

3) When an object be used as reference of another object? What care should be

taken in such kind of referencing?

……………………………………………………………………………………
……………………………………………………………………………………

1.3 INTRODUCING METHODS

A Java class is a group of values with a set of operations. The user of a class
manipulates object of that class only through the methods of that class.

General form of a method is:

type name_of_method (argument_list)
{
// body of method

10
} Class and Objects
type specifies the type of data that will be returned by the method. This can be any
data type including class types. In case a method does not return any value, its return
type must be void. The argument–list is a list of type and identifier pairs separated by
commas. Arguments are basically variables that receive the values at the time of
method invocation. If a method has return type other than void, it returns a value to
the calling point using the following form of statement.
return value;// value is the value to be returned by function.

Suppose we define a class to represent complex numbers. The complex class

definition shown in the program given below illustrates how this can be done. Two
variables real and imag, are declared. These represent the real and imaginary parts of a
complex number (respectively). The program also defines three methods, assignReal
and assign Imag() and showComplexl()that can be used to assign values to the real is
() part imaginary part of a complex number, and to show the real number respectively.
class Complex
{
double real;
double imag;
void assignReal( double r)
{
real = r;
}
void assignImag( double i)
{
imag= i;
}
void showComplex ( )
{
System.out.println("The Complex Number is :"+ real +"+i"+imag);
}
}
class Complex_Test
{
public static void main(String[] args)
{
Complex R1 = new Complex();
R1.assignReal(5);
R1.assignImag(2);
R1.showComplex();
}
}
Output of this program is:
The Complex Number is :5.0+i2.0
Sometimes we need to have the same name of different methods in a class. All these
methods perform different operations of a similar nature. For example of two add
methods in a class one is used for adding two integer variables and the other for
adding two double variables. Methods of the same name in a class are called
overloaded methods, and the process of defining this type of methods is called method
overloading. The concept of overloading we cover in more detail in the next section of
this unit. The concept of overloading can also be used in case of defining constructors.
Constructor overloading we will discuss in section 1.3.3 this unit.
So far we have seen that the initialization of instance variables is done after creating
objects. Now we will use constructors for initialization of instance variables.
1.3.1 Static Methods
Methods and variables that are not declared as static are known as instance methods
and instance variables or in other words you can say that they belong to objects of the
11
Object Oriented Concepts . To refer to instance methods and variables, you must instantiate the class first,
and Exceptions Handling then obtain the methods and variables from the instance.

A static method is a characteristic of a class, not of the objects it has created.

Static variables and methods are also known as class variables or class methods since
each class variable and each class method occurs once per class. Instance methods and
variables occur once per instance of a class or you can say every object is having its
own copy of instance variables.

One very important point to note here is that a program can execute a static method
without creating an object of the class. All other methods must be invoked through an
object, and, therefore an object must exist before they can be used. You have seen that
every Java application program has one main()method. This method is always static
because Java starts execution from this main()method, and at that time no object is
created.

Let us see one example program:

import Java.util.Date;
class DateApp
{
public static void main(String args[])
{
Date today = new Date();
System.out.println(today);
}
}

The last line of the main() method uses the System class from the Java.lang package
to display the current date and time. See the line of code that invokes the println ()
method.

System.out.println(today);
Now look at the details of the argument passed to it.
System.out refers to the out variable of the System class. You already know that, to
refer to static variables and methods of a class, you use a syntax similar to the C and
C++ syntax for obtaining the elements in a structure. You join the class’s name and
the name of the static method or static variable together with a dot (.)

The point which should be noticed here is that the application never instantiated the
System class and that out is referred to directly from the class. This is because out is
declared as a static variable: a variable associated with the class rather than with an
instance of the class. You can also associate methods with a class--static methods--
using static keyword.

1.3.2 Constructors

A constructor initializes object with its creation. It has the same name as the name of
its class. Once a constructor is defined, it is automatically called immediately the
memory is allocated before the new operation completes. Constructor does not have
any return type, it implicit return type is class object. You can see constructor as a
class type. Its job is to initialize the instance variables of an object, so that the created
object is usable just after creation.

In program Complex_Test you have seen that for initializing imaginary and real parts,
two methods have been used. Both the methods have been invoked on the object one
by one. In place of methods if you use constructor for initialization you have to make

12
changes in Complex_Test program. Remove methods used for initializing variables Class and Objects
and use one method having same name of the class, i.e., Complex with two
arguments.
class Complex
{
double real;
double imag;
Complex( double p, double q)
{
System.out.println("Constructor in process...");
real = p;
real = p;
imag = q;
}
void showComplex ( )
{
System.out.println("The Complex Number is :"+ real +"+i"+imag);
}
}
class Complex_Test
{
public static void main(String[] args)
{
Complex R1 = new Complex(5,2);
R1.showComplex();
}
}
The output of this program is:
Constructor in process…
The Complex Number is :5.0+i2.0

If you compare this program and the previous Complex_Test program you will find
that in this program the instance variable of object R1 is initialized with the help of
constructor Complex (5, 2), value 5 has been assigned to the real variable and 2 has
been assigned to the imag variable. In the previous program, to initialize these
variables, methods assignReal() and assignImag() were used.

Constructors can be defined in two ways. First , a constructor may not have parameter.
This type of constructor is known as non-parameterized constructor. The second, a
constructor may take parameters. This type of constructor is known as parameterized
constructor.

If non-parameterized constructor is used for object creation, instance variables of the

object are initialized by fixed values at the time of definition of constructor itself.

You can see this program

class Point
{
int x;
int y;
Point()
{
x= 2;
y= 4;
}
void Display_Point()
{
System.out.println("The Point is: ("+x+","+y+")");
}
13
Object Oriented Concepts }
and Exceptions Handling class Point_Test
{
public static void main( String args[])
{
Point p1 = new Point();
Point p2 = new Point();
p1.Display_Point();
p2.Display_Point();
}
}

Output of this program is:

The Point is: (2,4)
The Point is: (2,4)

Constructor Point is a non-parameterized constructor. Both the objects p1 and p2 are

created by using Point constructor and are initialized by the same value which is
assigned during definition of the constructor. This type of constructors is generally
used for the initialization of those objects for which the initial value of instance
variables is known. If values of the instance variables are given at the time of object
creation, parameterized constructors are used for this.

For example, if you want to create Point class object with your initial values of x and
y coordinates, you can use parameterized constructor. You have to make the following
changes in the previous program.

1. In place of non-parameterized constructor, define parameterized constructor.

2. Pass appropriate values as arguments to constructors.

class Point
{
int x;
int y;
Point(int a, int b)
{
x= a;
y= b;
}
void Display_Point()
{
System.out.println("The Point is: ("+x+","+y+")");
}
}
class Point_1_Test
{
public static void main( String args[])
{
Point p1 = new Point(2,5);
Point p2 = new Point(9,7);
p1.Display_Point();
p2.Display_Point();
}
}

Output of this program is:

The Point is: (2,5)
The Point is: (9,7)

14
In this program you can see that points p1 and p2 are initialized by values of Class and Objects
programmer’s choice by using parameterized constructor.

1.3.3 Overloading Constructors

You may ask whether there can be more than one constructor in a class. Yes, there
may be more than one constructor in a class but all the constructors in a class either
will have different types of arguments or different number of arguments passed to it.
This is essential because without this it wouldn’t be possible to identify which of the
constructors is invoked. Having more than one constructor in a single class is known
as constructor overloading. In the program given below more than one constructor in
class Student are defined.

class Student
{
String name;
int roll_no;
String course;
Student( String n, int r, String c)
{
name = n;
roll_no = r;
course = c;
}
Student(String n, int r )
{
name = n;
roll_no = r;
course = "MCA";
}
void Student_Info( )
{
System.out.println("********* Student Information ***********");
System.out.println("Name:"+name);
System.out.println("Course:"+course);
System.out.println("Roll Number:"+roll_no);
}
}
class Student_Test
{
public static void main(String[] args)
{
Student s1 = new Student("Ravi Prakash", 987770012,"BCA");
Student s2 = new Student("Rajeev ", 980070042);
s1.Student_Info();
s2.Student_Info();
}
}
Output of this program is:
********* Student Information ***********
Name:Ravi Prakash
Course:BCA
Roll Number:987770012
********* Student Information ***********
Name:Rajeev
Course:MCA
Roll Number:980070042

15
Object Oriented Concepts Both the constructors of this program can be used for creating two different types of
and Exceptions Handling objects. Here different types are simply related to the values assigned to instance
variables of objects during their initialization through constructors. By using a
constructor with three arguments all the three instance variables name, roll_no and,
course can be initialized. If a constructor with two arguments is used to create object,
only instance variables name and roll_no can be given initial value through
constructor and the variable course is initialized by a constant value “MCA”.

 Check Your Progress 2

1) What is the need of member function in a class? Explain through a program

how member functions are defined in Java.
……………………………………………………………………………………
……………………………………………………………………………………
2) Explain why the main method in Java is always static?
……………………………………………………………………………………
……………………………………………………………………………………

3) Explain the use of constructor with the help of a program.

……………………………………………………………………………………
……………………………………………………………………………………
4) Write a program in Java to create Bank_Account class, which defines two
different constructors to create objects.
……………………………………………………………………………………
……………………………………………………………………………………

1.4 this KEYWORD

If a method wants to refer the object through which it is invoked, it can refer to by
using this keyword. You know it is illegal to have two variables of the same name
within the same scope in a program. Suppose local variables in a method, or formal
parameters of the method, overlap with the name of instance variables of the class, to
differentiate between local variables or formal parameters and instance variables, this
keyword is used. The reason to use this keyword to resolve any name conflict that
might occur between instance variables and local variable is that this keyword can be
used to refer to the objects directly. You can see in this program class Test_This is
having one variable named rate and method. Total_Interest is also having one local
variable named rate. To avoid conflict between both the rate variables keyword has
been used with rate variable of Test_This class.
class Test_This
{
int rate ;
int amount;
int interest;
Test_This( int r, int a)
{
rate = r;
amount =a;
}
void Total_Interest( )

16
{ Class and Objects
int rate = 5;
rate = this.rate+rate;
interest = rate*amount/100;
System.out.println("Total Interest on "+amount+" is: "+interest);
}
}
class This_Test
{
public static void main(String[] args)
{
Test_This Ob1 = new This( 5, 5000);
Ob1.Total_Interest();
}
}
Output of this program is:
Total Interest on 5000 is: 500.

1.5 USING OBJECTS AS PARAMETERS

Objects can be based as parameter and can also be returned from the methods. Let us
look at the two aspects one by one.

1.5.1 Argument Passing

During problem solving you need to pass arguments through methods. Basically by
passing arguments you can generalize a method. During problem solving generalized
methods can be used for performing operations on a variety of data.

You can see in this program below that for find the area of square and rectangle. The
methods Area_S and Area_R for finding area of square and rectangle respectively are
defined.
class Test
{
int Area_S( int i)
{
return i*i;
}
int Area_R(int a,int b)
{
return a*b;
}
}
class Area_Test
{
public static void main(String args[])
{
Test t = new Test();
int area;
area = t.Area_S(5);
System.out.println("Area of Square is : "+area);
area = t.Area_R(5,4);
System.out.println("Area of Rectangle is : "+area);
}
}
Output of this program is:
Area of Square is: 25
17
Object Oriented Concepts Area of Rectangle is: 20
and Exceptions Handling
Can you tell the way of passing parameters in methods Area_S and Area_R? It is call
by value. Right as you have studied about two basic way pass by value and pass by
reference of parameter passing in functions in course: MCS 01.

Now you may ask a question whether parameter passing in Java is by reference or by
value. The answer is everything in Java except value, passed by reference.

Pass-by-value means that when you call a method, a copy of the value of each of the
actual parameter is passed to the method. You can change that copy inside the
method, but this will have no effect on the actual parameters. You can see in the
program given below. The method max has two parameters that are passed by value.
class Para_Test
{
static int max(int a, int b)
{
if (a > b)
return a;
else
return b;
}
public static void main(String[] args)
{
int num1 = 40, num2 = 50, num3;
num3 = max( num1, num2);
System.out.println("The maximum in "+num1 +" and "+num2+" is : "+num3);
}
}
Output of this program is:
The maximum in 40 and 50 is: 50
The values of variables are always primitives or references, never objects. In Java, we
can pass a reference of the object to the formal parameter. If any changes to the local
object that take place inside the method will modify the object that was passed to it as
argument. Due to this reason objects passing as parameter in Java are referred to as
passing by reference. In the program given below object of the class Marks is passed
to method Set_Grade, in which instance variable grade of the object passed is
assigned some value. This reflects that the object itself is modified.
class Marks
{
String name;
int percentage;
String grade;
Marks(String n, int m)
{
name = n;
percentage = m;
}
void Display()
{
System.out.println("Student Name :"+name);
System.out.println("Percentage Marks:"+percentage);
System.out.println("Grade : "+grade);
System.out.println("*****************************");
}
}
class Object_Pass
{
public static void main(String[] args)

18
{ Class and Objects
Marks ob1 = new Marks("Naveen",75);
Marks ob2 = new Marks("Neeraj",45);
Set_Grade(ob1);
System.out.println("*****************************");
ob1.Display();
Set_Grade(ob2);
ob2.Display();
}
static void Set_Grade(Marks m)
{
if (m.percentage >= 60)
m.grade ="A";
else if( m.percentage >=40)
m.grade = "B";
else
m.grade = "F";
}
}
Output of this program is:
*****************************
Student Name :Naveen
Percentage Marks:75
Grade : A
*****************************
Student Name :Neeraj
Percentage Marks:45
Grade : B
*****************************

1.5.2 Returning Objects

Like other basic data types, methods can return data of class type, i.e. object of class.
An object returned from a method can be stored in any other object of that class like
as values of basic type returned are stored in variables of that data type. You can see
in the program below where an the object of class Salary is returned by method the
incr_Salary.
class Salary.
{
int basic ;
String E_id;
Salary( String a, int b)
{
E_id = a;
basic = b;
}
Salary incr_Salary ( Salary s )
{
s.basic = basic*110/100;
return s;
}
}
class Ob_return_Test
{
public static void main(String[] args)
{
Salary s1 = new Salary("I100",5000);
Salary s2;// A new salary object
s1 = s1.incr_Salary( s1);
19
Object Oriented Concepts System.out.println("Current Basic Salary is : "+ s2.basic);
and Exceptions Handling }
}
Output of this program is:
Current Basic Salary is: 5500

Now once again you can return to a discussion of overloading, which was left at
section 1.3 of this unit.

1.6 METHOD OVERLOADING

Sometimes two or more methods which are very similar in nature are required. For
example, you can take methods Area_S and Area_R in a class Test in program of
section 1.3 of this unit. Both the methods are finding area but the argument passed to
them and their implementation is different. All the methods of similar kinds in a class
can have the same name, but remember all the methods will have different prototypes.
This concept is known as method overloading. By matching the type and order of
arguments passed to methods. The exact method that should execute is resolved.
Sometimes overloaded methods may have different return types, the return type alone
is not sufficient to differentiate two overloaded methods. You can see in the program
given below that the area()method is overloaded.

class Test
{
int Area( int i)
{
return i*i;
}
int Area(int a,int b)
{
return a*b;
}
}
class Area_Overload
{
public static void main(String args[])
{
Test t = new Test();
int area;
area = t.Area(5);
System.out.println("Area of Squire is : "+area);
area = t.Area(5,4);
System.out.println("Area of Rectangle is : "+area);
}
}
Output of this program is:
Area of Squire is: 25
Area of Rectangle is: 20.

1.7 GARBAGE COLLECTION

One of the key features of Java is its garbage-collected heap, which takes care of
freeing dynamically allocated memory that is no longer referenced. It shields the
substantial complexity of memory allocation and garbage collection from the
developer. Because the heap is garbage-collected, Java programmers don’t have to
explicitly free the allocated memory.

20
The JVM’s heap stores all the objects created by an executing Java program. You Class and Objects
know Java’s “new” operator allocate memory to object at the time of creation on the
heap at run time. Garbage collection is the process of automatically freeing objects
that are no longer referenced by the program. This frees the programmer from having
to keep track of when to free allocated memory, thereby preventing many potential
bugs and thus reduces the programmer’s botheration.

The name “garbage collection" implies that objects that are no longer needed by the
program are “garbage” and can be thrown away and collects back into the heap. You
can see this process as “memory recycling”. When the program no longer references
an object, the heap space it occupies must be recycled so that the space is available for
subsequent new objects. The garbage collector must somehow determine which
objects are no longer referenced by the program and make available the heap space
occupied by such unreferenced objects.

Advantages and Disadvantages of garbage collection

Giving the job of garbage collection to the JVM has several advantages. First, it can
make programmers more productive. Programming in non-garbage-collected
languages, the programmer has to spend a lot of time in keeping track of the memory
de-allocation problem. In Java, the programmer can use that time more
advantageously in doing other work.

A second advantage of garbage collection is that it ensure program integrity. Garbage

collection is an important part of Java’s security strategy. Java programmers feel free
from the fear of accidental crash of the system because JVM is there to take care of
memory allocation and de–allocation.

The major disadvantage of a garbage-collected heap is that it adds an overhead that

can adversely affect program performance. The JVM has to keep track of objects that
are being referenced by the executing program, and free unreferenced objects on the
fly. This activity will likely take more CPU time than would have been required if the
program explicitly freed unrefined memory. The second disadvantage is the
programmers in a garbage-collected environment have less control over the
scheduling of CPU time devoted to freeing objects that are no longer needed.

1.8 THE FINALIZE () METHOD

Sometimes it is required to take independent resources from some object before the
garbage collector takes the object. To perform this operation, a method named
finalized () is used. Finalized () is called by the garbage collector when it determines
no more references to the object exist.

Finalized()method has the following properties:

1. Every class inherits the finalize() method from Java.lang.Object.

2. The garbage collector calls this method when it determines no more references
to the object exist.

3. The Object class finalize method performs no actions but it may be overridden
by any derived class.

4. Normally it should be overridden to clean-up non-Java resources, i.e. closing a

file, taking file handle, etc.

21
Object Oriented Concepts Writing a finalize() Method
and Exceptions Handling
Before an object is garbage collected, the runtime system calls its finalize() method.
The intent for this to release system resources such as open files or open sockets
before object getting collected by garbage collector.

Your class can provide for its finalization simply by defining and implementing a
finalize() method in your class. Your finalize() method must be declared as follows:

protected void finalize () throws throwable

This class opens a file when its constructed:

class OpenAFile
{
FileInputStream aFile = null;
OpenAFile(String filename)
{
try
{
a File = new FileInputStream(filename);
}
catch (Java.io.FileNotFoundException e)
{
System.err.println("Could not open file " + filename);
}
}
}

To avoid accidental modification or other related problem the OpenAFile

class should close the file when it is finalized. Implementation of finalize ()
method for the OpenAFile class:
protected void finalize () throws throwable
{
if (aFile != null)
{
a File.close();
a File = null;
}
}

The Java programmer must keep in mind that it is the garbage collector that runs
finalizers on objects. Because it is not generally possible to predict exactly when
unreferenced objects will be garbage collected, and to predict when object finalizers
will be run. Java programmers, therefore, should avoid writing code for which
program correctness depends upon the timely finalization of objects. For example, a
finalize of an unreferenced object may release a resource that is needed again later by
the program. The resource will not be made available until after the garbage collector
has run the object finalizer. If the program needs the resource before the garbage
collector has run the finalizer, the program is out of luck.

 Check Your Progress 3

1) What is the need of parameter passing? Show through a program how
parameters are passed to methods.
……………………………………………………………………………………
……………………………………………………………………………………

22
2) What are two major advantages of automatic de-allocation of memory? Class and Objects

……………………………………………………………………………………
……………………………………………………………………………………
3) Write a program in Java, in which a method named add is overloaded. The add method
sums two integer values, one integer value and one double value, two double values.

……………………………………………………………………………………
……………………………………………………………………………………

1.9 SUMMARY

In this unit, the concept of class is discussed. The process of object creation using
class is explained. Every object has its state and behavior. Objects behavior are
defined inside the class in terms of member functions. In this unit are also discussed
about creation of constructors and their advantages. The need of static methods is
explained with the help of the main () method of Java application program, which is
always static. This unit also explained how arguments are passed to a member
function. In the last section of this unit “Garbage Collection” one of the very
important concepts of Java programming is explained.

1.10 SOLUTIONS/ANSWERS

Check Your Progress 1

1) First define the class for the object to be declared. Then using new operator
allocates needed space to the variables of object.
Object definition in Java is a two-step process
i Declare variable of class type.
ii. Using new operator allocate needed space to the object.

For example to define object of Book class do the following:

Book book1 // declaration of object named book1
book1 = new Book(); // allocating memory.

2) Objects used in problem solving are instances of classes. Objects are treated as
black box with public interfaces. Interfaces are provided with the help of
member functions.

Member functions and member data are kept inside the class to ensure that data don’t
get accessed and modified accidentally. Definition of member functions is inside the
class and it provides scope of modification in the definition without affecting outside
world.

3) One object can be used as reference to another object provided both are of the
same class type. Objects should be used as a reference very carefully because if
there is any change in values of instance variables of one object, values of
instance variable of the second object also gets changed.
Check Your Progress 2

1) Member functions in a class are required for providing features of the objects.

In the program given below to display the price of book object member function
Get_Price() is defined.
23
Object Oriented Concepts //program
and Exceptions Handling class Book
{
String Title;
String Author;
int Price;
Book( String t, String a, int p)
{
Title = t;
Author = a;
Price = p;
}
void Get_Price ( )
{
System.out.println("Price of the book is :"+Price);
}
}
class Book_Test
{
public static void main(String args[])
{
Book b1 = new Book("Java Programming","Dr. Rajkumar Singh",250);
b1.Get_Price();
}
}

Output:
Price of the book is: 250

2) A static method can be invoked through the class itself rather than through an
object as in the case of member functions. There is no need of any object to call
a static method. Any static method is part of class not the part of objects. When
main method is called there does not exist any object. Therefore, it become
essential to have main () method as static.

3) Constructors are used to initialize the objects. Objects created by using

constructors are ready to use. The program given below creates objects of
Complex class using constructor defined in this class.

//program
class Complex
{
int real;
int imaginary;
Complex ( int r, int i)
{
real = r;
imaginary = i;
}
void ShowNumber()
{
System.out.println("The Number is :" + real+"+" +imaginary+"i");
}
}
public class Cons_Test
{
public static void main(String args[])
{
Complex c= new Complex(5,3);

24
c.ShowNumber(); Class and Objects
}
}

Output
The Number is :5+3i

4) In this program there are two different constructors of Bank_Account class.

//program
class Bank_Account
{
String Name;
int Account_No;
String Address;
int Init_Bal;
Bank_Account(String n, int a)
{
Name = n;
Account_No = a;
}
Bank_Account (String n, String addr, int a , int b)
{
Name = n;
Address = addr;
Account_No = a;
Init_Bal = b;
}
}
public class Account_Test
{
public static void main( String args[])
{
Bank_Account Ac1 = new Bank_Account("Mr. Naveen", 11002345);
Bank_Account Ac2 = new Bank_Account( "Mr. Suresh", "K-2 MGI Basant Kunj
New Delhi", 12001347, 500);
System.out.println("Account No. of "+Ac1.Name + " is :"+Ac1.Account_No);
System.out.println("Initial Balance in account of "+Ac2.Name+" is
Rs."+Ac2.Init_Bal);
}
}
Output
Account No. of Mr. Naveen is :11002345
Initial Balance in account of Mr. Suresh is Rs.500.
Check Your Progress 3
1) Whenever there is a need to pass some value to a method from outside the
values are passed as arguments to method. Example’ is a method written to
calculate interest on some amount. Interest rate is a variable that can be passed
as argument to the method used for interest calculation.

In the program given below Interst_Calc method is defined

//program
class Interest
{
int amount ;
Interest( int a)
{
amount = a;
25
Object Oriented Concepts }
and Exceptions Handling int Interest_Calc (int rate)
{
return amount * rate / 100;
}
}
public class ParaTest
{
public static void main (String args[])
{
Interest inter = new Interest(5000);
System.out.println("The Inters amount for Rs 5000 at the rate of 10 % for a year is:"+
inter.Interest_Calc(10));
}
}

Output
The Interest amount for Rs 5000 at the rate of 10 % for a year is: 500

2) There are two major advantages of automatic garbage collection

i. Increase programmer productivity.
ii. Ensure program integrity.

3) //Program
class Add_Overload
{
Add_Overload()
{
System.out.println("*******Welcome to Overload Demo********");
}
void add( int i, int j)
{
System.out.println("Inside add(int,int)and the Sum is :"+(i+j));
}
void add( int i, double j)
{
System.out.println("Inside add(int,double)and the Sum is :"+(i+j));
}
void add( double i, double j)
{
System.out.println("Inside add(double,double)and the Sum is:"+(i+j));
}
}
public class OverloadTest
{
public static void main (String args[])
{
Add_Overload Ol = new Add_Overload();
Ol.add(34,35);
Ol.add( 25, 47.67);
Ol.add(12.5,25.5);
}
}

Output:
*******Welcome to Overload Demo********
Inside add(int,int)and the Sum is:69
Inside add(int,double)and the Sum is:72.67
Inside add(double,double)and the Sum is:38.0

26
 Transactions and
UNIT 2 TRANSACTIONS AND Concurrency
Management
CONCURRENCY MANAGEMENT
Structure Page Nos.
2.0 Introduction 35
2.1 Objectives 35
2.2 The Transactions 35
2.3 The Concurrent Transactions 38
2.4 The Locking Protocol 42
2.4.1 Serialisable Schedules
2.4.2 Locks
2.4.3 Two Phase Locking (2PL)
2.5 Deadlock and its Prevention 49
2.6 Optimistic Concurrency Control 51
2.7 Summary 53
2.8 Solutions/ Answers 54

2.0 INTRODUCTION
One of the main advantages of storing data in an integrated repository or a database is
to allow sharing of it among multiple users. Several users access the database or
perform transactions at the same time. What if a user’s transactions try to access a
data item that is being used /modified by another transaction? This unit attempts to
provide details on how concurrent transactions are executed under the control of
DBMS. However, in order to explain the concurrent transactions, first we must
describe the term transaction.
Concurrent execution of user programs is essential for better performance of DBMS,
as concurrent running of several user programs keeps utilizing CPU time efficiently,
since disk accesses are frequent and are relatively slow in case of DBMS. Also, a
user’s program may carry out many operations on the data returned from DB, but
DBMS is only concerned about what data is being read /written from/ into the
database. This unit discusses the issues of concurrent transactions in more detail.

2.1 OBJECTIVES
After going through this unit, you should be able to:
• describe the term CONCURRENCY;
• define the term transaction and concurrent transactions;
• discuss about concurrency control mechanism;
• describe the principles of locking and serialisability, and
• describe concepts of deadlock & its prevention.

2.2 THE TRANSACTIONS

A transaction is defined as the unit of work in a database system. Database systems
that deal with a large number of transactions are also termed as transaction processing
systems.

What is a transaction? Transaction is a unit of data processing. For example, some of

the transactions at a bank may be withdrawal or deposit of money; transfer of money
from A’s account to B’s account etc. A transaction would involve manipulation of one

35
Structured Query or more data values in a database. Thus, it may require reading and writing of
Language and
Transaction Management
database value. For example, the withdrawal transactions can be written in pseudo
code as:
Example 1:
; Assume that we are doing this transaction for person
; whose account number is X.

TRANSACTION WITHDRAWAL (withdrawal_amount)

Begin transaction
IF X exist then
READ X.balance
IF X.balance > withdrawal_amount
THEN SUBTRACT withdrawal_amount
WRITE X.balance
COMMIT
ELSE
DISPLAY “TRANSACTION CANNOT BE PROCESSED”
ELSE DISPLAY “ACCOUNT X DOES NOT EXIST”
End transaction;

Another similar example may be transfer of money from Account no x to account

number y. This transaction may be written as:

Example 2:
; transfers transfer_amount from x’s account to y’s account
; assumes x&y both accounts exist

TRANSACTION (x, y, transfer_amount)

Begin transaction
IF X AND Y exist then
READ x.balance
IF x.balance > transfer_amount THEN
x.balance = x.balance – transfer_amount
READ y.balance
y.balance = y.balance + transfer_amount
COMMIT
ELSE DISPLAY (“BALANCE IN X NOT OK”)
ROLLBACK
ELSE DISPLAY (“ACCOUNT X OR Y DOES NOT EXIST”)
End_transaction

Please note the use of two keywords here COMMIT and ROLLBACK. Commit
makes sure that all the changes made by transactions are made permanent.
ROLLBACK terminates the transactions and rejects any change made by the
transaction. Transactions have certain desirable properties. Let us look into those
properties of a transaction.

Properties of a Transaction
A transaction has four basic properties. These are:

• Atomicity

• Consistency

• Isolation or Independence

• Durability or Permanence

36
Atomicity: It defines a transaction to be a single unit of processing. In other words Transactions and
Concurrency
either a transaction will be done completely or not at all. In the transaction example 1 Management
& 2 please note that transaction 2 is reading and writing more than one data items, the
atomicity property requires either operations on both the data item be performed or
not at all.
Consistency: This property ensures that a complete transaction execution takes a
database from one consistent state to another consistent state. If a transaction fails
even then the database should come back to a consistent state.

x.balance = 10,000/- Transfer Rs. 5,000/- from x to y x.balance = 5,000/-

y.balance = 20,000/- y.balance = 25,000/-
x.balance = 5,000/-
y.balance = 20,000/-
Inconsistent state
Consistent state Consistent state
Execution
Start of transaction (The database may be in an End of transaction
inconsistent state during
execution of the transaction)
Figure 1: A Transaction execution

Isolation or Independence: The isolation property states that the updates of a

transaction should not be visible till they are committed. Isolation guarantees that the
progress of other transactions do not affect the outcome of this transaction. For
example, if another transaction that is a withdrawal transaction which withdraws an
amount of Rs. 5000 from X account is in progress, whether fails or commits, should
not affect the outcome of this transaction. Only the state that has been read by the
transaction last should determine the outcome of this transaction.

Durability: This property necessitates that once a transaction has committed, the
changes made by it be never lost because of subsequent failure. Thus, a transaction is
also a basic unit of recovery. The details of transaction-based recovery are discussed
in the next unit.

A transaction has many states of execution. These states are displayed in Figure 2.

Error!

Execute

Start Commit

Abort/
Rollback

Figure 2: States of transaction execution

A transaction is started as a program. From the start state as the transaction is

scheduled by the CPU it moves to the Execute state, however, in case of any system

37
Structured Query error at that point it may also be moved into the Abort state. During the execution
Language and
Transaction Management
transaction changes the data values and database moves to an inconsistent state. On
successful completion of transaction it moves to the Commit state where the durability
feature of transaction ensures that the changes will not be lost. In case of any error the
transaction goes to Rollback state where all the changes made by the transaction are
undone. Thus, after commit or rollback database is back into consistent state. In case a
transaction has been rolled back, it is started as a new transaction. All these states of
the transaction are shown in Figure 2.

2.3 THE CONCURRENT TRANSACTIONS

Almost all the commercial DBMS support multi-user environment. Thus, allowing
multiple transactions to proceed simultaneously. The DBMS must ensure that two or
more transactions do not get into each other's way, i.e., transaction of one user doesn’t
effect the transaction of other or even the transactions issued by the same user should
not get into the way of each other. Please note that concurrency related problem may
occur in databases only if two transactions are contending for the same data item
and at least one of the concurrent transactions wishes to update a data value in
the database. In case, the concurrent transactions only read same data item and no
updates are performed on these values, then it does NOT cause any concurrency
related problem. Now, let us first discuss why you need a mechanism to control
concurrency.
Consider a banking application dealing with checking and saving accounts. A
Banking Transaction T1 for Mr. Sharma moves Rs.100 from his checking account
balance X to his savings account balance Y, using the transaction T1:
Transaction T1:

A: Read X
Subtract 100
Write X
B: Read Y
Add 100
Write Y
Let us suppose an auditor wants to know the total assets of Mr. Sharma. He executes
the following transaction:
Transaction T2:

Read X
Read Y
Display X+Y
Suppose both of these transactions are issued simultaneously, then the execution of
these instructions can be mixed in many ways. This is also called the Schedule. Let us
define this term in more detail.
A schedule S is defined as the sequential ordering of the operations of the ‘n’
interleaved transactions. A schedule maintains the order of operations within the
individual transaction.

Conflicting Operations in Schedule: Two operations of different transactions

conflict if they access the same data item AND one of them is a write operation.
For example, the two transactions TA and TB as given below, if executed in parallel,
may produce a schedule:

TA TB
38
 READ X READ X Transactions and
Concurrency
WRITE X WRITE X Management

SCHEDULE TA TB
READ X READ X
READ X READ X
WRITE X WRITE X
WRITE X WRITE X

One possible schedule for interleaved execution of TA and TB

Let us show you three simple ways of interleaved instruction execution of transactions
T1 and T2. Please note that in the following tables the first column defines the
sequence of instructions that are getting executed, that is the schedule of operations.

a) T2 is executed completely before T1 starts, then sum X+Y will show the
correct assets:

Schedule Transaction T1 Transaction T2 Example

Values
Read X Read X X = 50000
Read Y Read Y Y= 100000
Display X+Y Display X+Y 150000
Read X Read X X = 50000
Subtract 100 Subtract 100 49900
Write X Write X X = 49900
Read Y Read Y Y= 100000
Add 100 Add 100 100100
Write Y Write Y Y= 100100

b) T1 is executed completely before T2 starts, then sum X+Y will still show the
correct assets:

Schedule Transaction T1 Transaction T2 Example

Values
Read X Read X X = 50000
Subtract 100 Subtract 100 49900
Write X Write X X = 49900
Read Y Read Y Y= 100000
Add 100 Add 100 100100
Write Y Write Y Y= 100100
Read X Read X X = 49900
Read Y Read Y Y= 100100
Display X+Y Display X+Y 150000

c) Block A in transaction T1 is executed, followed by complete execution of T2,

followed by the Block B of T1.

Schedule Transaction T1 Transaction T2 Example

Values
Read X Read X X = 50000
Subtract 100 Subtract 100 49900
Write X Write X X = 49900
Read X Read X X = 49900
Read Y Read Y Y= 100000
Display X+Y Display X+Y 149900
Read Y Read Y Y= 100000

39
Structured Query Add 100 Add 100 100100
Language and
Transaction Management Write Y Write Y Y= 100100

In this execution an incorrect value is being displayed. This is because Rs.100

although removed from X, has not been put in Y, and is thus missing. Obviously, if
T1 had been written differently, starting with block B and following up with block A,
even then such an interleaving would have given a different but incorrect result.

Please note that for the given transaction there are many more ways of this interleaved
instruction execution.

Thus, there may be a problem when the transactions T1 and T2 are allowed to execute
in parallel. Let us define the problems of concurrent execution of transaction more
precisely.

Let us assume the following transactions (assuming there will not be errors in data
while execution of transactions)

Transaction T3 and T4: T3 reads the balance of account X and subtracts a withdrawal
amount of Rs. 5000, whereas T4 reads the balance of account X and adds an amount
of Rs. 3000
T3 T4
READ X READ X
SUB 5000 ADD 3000
WRITE X WRITE X

Problems of Concurrent Transactions

1. Lost Updates: Suppose the two transactions T3 and T4 run concurrently and
they happen to be interleaved in the following way (assume the initial value of X as
10000):

T3 T4 Value of X
T3 T4
READ X 10000
READ X 10000
SUB 5000 5000
ADD 3000 13000
WRITE X 5000
WRITE X 13000

After the execution of both the transactions the value X is 13000 while the
semantically correct value should be 8000. The problem occurred as the update made
by T3 has been overwritten by T4. The root cause of the problem was the fact that
both the transactions had read the value of X as 10000. Thus one of the two updates
has been lost and we say that a lost update has occurred.

There is one more way in which the lost updates can arise. Consider the following part
of some transactions:

T5 T6 Value of x originally
2000
T5 T6
UPDATE X 3000
UPDATE X 4000
ROLLBACK 2000

40
Here T5 & T6 updates the same item X. Thereafter T5 decides to undo its action and Transactions and
Concurrency
rolls back causing the value of X to go back to the original value that was 2000. In Management
this case also the update performed by T6 had got lost and a lost update is said to have
occurred.
2. Unrepeatable reads: Suppose T7 reads X twice during its execution. If it did
not update X itself it could be very disturbing to see a different value of X in its next
read. But this could occur if, between the two read operations, another transaction
modifies X.

T7 T8 Assumed value of
X=2000
T7 T8
READ X 2000
UPDATE X 3000
READ X 3000

Thus, the inconsistent values are read and results of the transaction may be in error.
3. Dirty Reads: T10 reads a value which has been updated by T9. This update has
not been committed and T9 aborts.

T9 T10 Value of x old value =

200
T9 T10
UPDATE X 500
READ X 500
ROLLBACK 200 ?

Here T10 reads a value that has been updated by transaction T9 that has been aborted.
Thus T10 has read a value that would never exist in the database and hence the
problem. Here the problem is primarily of isolation of transaction.
4. Inconsistent Analysis: The problem as shown with transactions T1 and T2
where two transactions interleave to produce incorrect result during an analysis by
Audit is the example of such a problem. This problem occurs when more than one
data items are being used for analysis, while another transaction has modified some of
those values and some are yet to be modified. Thus, an analysis transaction reads
values from the inconsistent state of the database that results in inconsistent analysis.
Thus, we can conclude that the prime reason of problems of concurrent transactions is
that a transaction reads an inconsistent state of the database that has been created by
other transaction.

But how do we ensure that execution of two or more transactions have not resulted in
a concurrency related problem?

Well one of the commonest techniques used for this purpose is to restrict access to
data items that are being read or written by one transaction and is being written by
another transaction. This technique is called locking. Let us discuss locking in more
detail in the next section.

 Check Your Progress 1

1) What is a transaction? What are its properties? Can a transaction update more
than on data values? Can a transaction write a value without reading it? Give an
example of transaction.
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………

41
Structured Query 2) What are the problems of concurrent transactions? Can these problems occur in
Language and
Transaction Management
transactions which do not read the same data values?
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
3) What is a Commit state? Can you rollback after the transaction commits?
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………

2.4 THE LOCKING PROTOCOL

To control concurrency related problems we use locking. A lock is basically a variable
that is associated with a data item in the database. A lock can be placed by a
transaction on a shared resource that it desires to use. When this is done, the data item
is available for the exclusive use for that transaction, i.e., other transactions are locked
out of that data item. When a transaction that has locked a data item does not desire to
use it any more, it should unlock the data item so that other transactions can use it. If a
transaction tries to lock a data item already locked by some other transaction, it cannot
do so and waits for the data item to be unlocked. The component of DBMS that
controls and stores lock information is called the Lock Manager. The locking
mechanism helps us to convert a schedule into a serialisable schedule. We had defined
what a schedule is, but what is a serialisable schedule? Let us discuss about it in more
detail:

2.4.1 Serialisable Schedules

If the operations of two transactions conflict with each other, how to determine that no
concurrency related problems have occurred? For this, serialisability theory has been
developed. Serialisability theory attempts to determine the correctness of the
schedules. The rule of this theory is:

“A schedule S of n transactions is serialisable if it is equivalent to some serial

schedule of the same ‘n’ transactions”.

A serial schedule is a schedule in which either transaction T1 is completely done

before T2 or transaction T2 is completely done before T1. For example, the following
figure shows the two possible serial schedules of transactions T1 & T2.
S
Schedule A: T2 followed by T1 Schedule B: T1 followed by T2
Schedule T1 T2 Schedule T1 T2
Read X Read X Read X Read X
Read Y Read Y Subtract 100 Subtract 100
Display X+Y Display X+Y Write X Write X
Read X Read X Read Y Read Y
Subtract 100 Subtract 100 Add 100 Add 100
Write X Write X Write Y Write Y
Read Y Read Y Read X Read X
Add 100 Add 100 Read Y Read Y
Write Y Write Y Display X+Y Display X+Y
Figure 3: Serial Schedule of two transactions
Schedule C: An Interleaved Schedule
Schedule T1 T2
Read X Read X
Subtract 100 Subtract 100
Read X Read X

42
 Write X Write X Transactions and
Read Y Read Y Concurrency
Read Y Read Y Management
Add 100 Add 100
Display X+Y Display X+Y
Write Y Write Y

Figure 4: An Interleaved Schedule

Now, we have to figure out whether this interleaved schedule would be performing
read and write in the same order as that of a serial schedule. If it does, then it is
equivalent to a serial schedule, otherwise not. In case it is not equivalent to a serial
schedule, then it may result in problems due to concurrent transactions.

Serialisability
Any schedule that produces the same results as a serial schedule is called a serialisable
schedule. But how can a schedule be determined to be serialisable or not? In other
words, other than giving values to various items in a schedule and checking if the
results obtained are the same as those from a serial schedule, is there an algorithmic
way of determining whether a schedule is serialisable or not?

The basis of the algorithm for serialisability is taken from the notion of a serial
schedule. There are two possible serial schedules in case of two transactions (T1- T2
OR T2 - T1). Similarly, in case of three parallel transactions the number of possible
serial schedules is 3!, that is, 6. These serial schedules can be:

T1-T2-T3 T1-T3-T2 T2-T1-T3

T2-T3-T1 T3-T1-T2 T3-T2-T1

Using the notion of precedence graph, an algorithm can be devised to determine

whether an interleaved schedule is serialisbale or not. In this graph, the transactions of
the schedule are represented as the nodes. This graph also has directed edges. An edge
from the node representing transactions Ti to node Tj means that there exists a
conflicting operation between Ti and Tj and Ti precedes Tj in some conflicting
operations. It has been proved that a serialisable schedule is the one that contains no
cycle in the graph.

Given a graph with no cycles in it, there must be a serial schedule corresponding to it.

The steps of constructing a precedence graph are:

1. Create a node for every transaction in the schedule.

2. Find the precedence relationships in conflicting operations. Conflicting
operations are (read-write) or (write-read) or (write–write) on the same data
item in two different transactions. But how to find them?

2.1 For a transaction Ti which reads an item A, find a transaction Tj that

writes A later in the schedule. If such a transaction is found, draw an
edge from Ti to Tj.
2.2 For a transaction Ti which has written an item A, find a transaction Tj
later in the schedule that reads A. If such a transaction is found, draw
an edge from Ti to Tj.
2.3 For a transaction Ti which has written an item A, find a transaction Tj
that writes A later than Ti. If such a transaction is found, draw an edge
from Ti to Tj.
3. If there is any cycle in the graph, the schedule is not serialisable, otherwise,
find the equivalent serial schedule of the transaction by traversing the
transaction nodes starting with the node that has no input edge.

43
Structured Query Let us use this algorithm to check whether the schedule as given in Figure 4 is
Language and
Transaction Management
Serialisable. Figure 5 shows the required graph. Please note as per step 1, we draw the
two nodes for T1 and T2. In the schedule given in Figure 4, please note that the
transaction T2 reads data item X, which is subsequently written by T1, thus there is an
edge from T2 to T1 (clause 2.1). Also, T2 reads data item Y, which is subsequently
written by T1, thus there is an edge from T2 to T1 (clause 2.1). However, that edge
already exists, so we do not need to redo it. Please note that there are no cycles in the
graph, thus, the schedule given in Figure 4 is serialisable. The equivalent serial
schedule (as per step 3) would be T2 followed by T1.

T1 T2

Figure 5: Test of Serialisability for the Schedule of Figure 4

Please note that the schedule given in part (c) of section 2.3 is not serialsable, because
in that schedule, the two edges that exist between nodes T1 and T2 are:

• T1 writes X which is later read by T2 (clause 2.2), so there exists an edge from T1
to T2.
• T2 reads X which is later written by T1 (clause 2.1), so there exists an edge from
T2 to T1.

Thus the graph for the schedule will be:

T1 T2

Figure 6: Test of Serialisability for the Schedule (c) of section 2.3

Please note that the graph above has a cycle T1-T2-T1, therefore it is not serialisable.

2.4.2 Locks
Serialisabilty is just a test whether a given interleaved schedule is ok or has a
concurrency related problem. However, it does not ensure that the interleaved
concurrent transactions do not have any concurrency related problem. This can be
done by using locks. So let us discuss about what the different types of locks are, and
then how locking ensures serialsability of executing transactions.
Types of Locks
There are two basic types of locks:

• Binary lock: This locking mechanism has two states for to a data item: locked
or unlocked
• Multiple-mode locks: In this locking type each data item can be in three states
read locked or shared locked, write locked or exclusive locked or unlocked.
Let us first take an example for binary locking and explain how it solves the
concurrency related problems. Let us reconsider the transactions T1 and T2 for this
purpose; however we will add to required binary locks to them.

44
 Schedule T1 T2 Transactions and
Concurrency
Lock X Lock X Management
Read X Read X
Subtract 100 Subtract 100
Write X Write X
Unlock X Unlock X
Lock X Lock X
Lock Y Lock Y
Read X Read X
Read Y Read Y
Display X+Y Display X+Y
Unlock X Unlock X
Unlock Y Unlock Y
Lock Y Lock Y
Read Y Read Y
Add 100 Add 100
Write Y Write Y
Unlock Y Unlock Y
Figure 7: An incorrect locking implementation

Does the locking as done above solve the problem of concurrent transactions? No the
same problems still remains. Try working with the old value. Thus, locking should be
done with some logic in order to make sure that locking results in no concurrency
related problem. One such solution is given below:

Schedule T1 T2
Lock X Lock X
Lock Y Lock Y
Read X Read X
Subtract 100 Subtract 100
Write X Write X
Lock X (issued by Lock X: denied as T1 holds the lock.
T2) The transaction T2 Waits and T1
continues.
Read Y Read Y
Add 100 Add 100
Write Y Write Y
Unlock X Unlock X
The lock request of T2 on X can now
be granted it can resumes by locking X
Unlock Y Unlock Y
Lock Y Lock Y
Read X Read X
Read Y Read Y
Display X+Y Display X+Y
Unlock X Unlock X
Unlock Y Unlock Y
Figure 8: A correct but restrictive locking implementation

Thus, the locking as above when you obtain all the locks at the beginning of the
transaction and release them at the end ensures that transactions are executed with no
concurrency related problems. However, such a scheme limits the concurrency. We
will discuss a two-phase locking method in the next subsection that provides sufficient
concurrency. However, let us first discuss multiple mode locks.

45
Structured Query Multiple-mode locks: It offers two locks: shared locks and exclusive locks. But why
Language and
Transaction Management
do we need these two locks? There are many transactions in the database system that
never update the data values. These transactions can coexist with other transactions
that update the database. In such a situation multiple reads are allowed on a data item,
so multiple transactions can lock a data item in the shared or read lock. On the other
hand, if a transaction is an updating transaction, that is, it updates the data items, it has
to ensure that no other transaction can access (read or write) those data items that it
wants to update. In this case, the transaction places an exclusive lock on the data
items. Thus, a somewhat higher level of concurrency can be achieved in comparison
to the binary locking scheme.
The properties of shared and exclusive locks are summarised below:
a) Shared lock or Read Lock

• It is requested by a transaction that wants to just read the value of data item.
• A shared lock on a data item does not allow an exclusive lock to be placed but
permits any number of shared locks to be placed on that item.
b) Exclusive lock

• It is requested by a transaction on a data item that it needs to update.

• No other transaction can place either a shared lock or an exclusive lock on a
data item that has been locked in an exclusive mode.

Let us describe the above two modes with the help of an example. We will once again
consider the transactions T1 and T2 but in addition a transaction T11 that finds the
total of accounts Y and Z.

Schedule T1 T2 T11
S_Lock X S_Lock X
S_Lock Y S_Lock Y
Read X Read X
S_Lock Y S_Lock Y
S_Lock Z S_Lock Z
Read Y
Read Z
X_Lock X X_Lock X. The exclusive lock request on X is
denied as T2 holds the Read lock. The
transaction T1 Waits.
Read Y Read Y
Display X+Y Display X+Y
Unlock X Unlock X
X_Lock Y X_Lock Y. The previous exclusive lock request
on X is granted as X is unlocked. But the new
exclusive lock request on Y is not granted as Y
is locked by T2 and T11 in read mode. Thus T1
waits till both T2 and T11 will release the read
lock on Y.
Display Y+Z Display Y+Z
Unlock Y Unlock Y
Unlock Y Unlock Y
Unlock Z Unlock Z
Read X Read X
Subtract 100 Subtract 100
Write X Write X
Read Y Read Y
Add 100 Add 100

46
 Write Y Write Y Transactions and
Concurrency
Unlock X Unlock X Management
Unlock Y Unlock Y

Figure 9: Example of Locking in multiple-modes

Thus, the locking as above results in a serialisable schedule. Now the question is can
we release locks a bit early and still have no concurrency related problem? Yes, we
can do it if we lock using two-phase locking protocol. This protocol is explained in
the next sub-section.

2.4.3 Two Phase Locking (2PL)

The two-phase locking protocol consists of two phases:

Phase 1: The lock acquisition phase: If a transaction T wants to read an object, it
needs to obtain the S (shared) lock. If T wants to modify an object, it needs
to obtain X (exclusive) lock. No conflicting locks are granted to a
transaction. New locks on items can be acquired but no lock can be
released till all the locks required by the transaction are obtained.

Phase 2: Lock Release Phase: The existing locks can be released in any order but no
new lock can be acquired after a lock has been released. The locks are
held only till they are required.

Normally the locks are obtained by the DBMS. Any legal schedule of transactions that
follows 2 phase locking protocol is guaranteed to be serialisable. The two phase
locking protocol has been proved for it correctness. However, the proof of this
protocol is beyond the scope of this Unit. You can refer to further readings for more
details on this protocol.

There are two types of 2PL:

(1) The Basic 2PL

(2) Strict 2PL

The basic 2PL allows release of lock at any time after all the locks have been
acquired. For example, we can release the locks in schedule of Figure 8, after we
have Read the values of Y and Z in transaction 11, even before the display of the sum.
This will enhance the concurrency level. The basic 2PL is shown graphically in
Figure 10.

Lock acquisition Lock release

Time Æ
Figure 10: Basic Two Phase Locking

However, this basic 2PL suffers from the problem that it can result into loss of atomic
/ isolation property of transaction as theoretically speaking once a lock is released on a
47
Structured Query data item it can be modified by another transaction before the first transaction
Language and
Transaction Management
commits or aborts.

To avoid such a situation we use strict 2PL. The strict 2PL is graphically depicted in
Figure 11. However, the basic disadvantage of strict 2PL is that it restricts
concurrency as it locks the item beyond the time it is needed by a transaction.

Lock acquisition Lock release

Time Æ
Figure 11: Strict Two Phase Locking

Does the 2PL solve all the problems of concurrent transactions? No, the strict 2PL
solves the problem of concurrency and atomicity, however it introduces another
problem: “Deadlock”. Let us discuss this problem in next section.

 Check Your Progress 2

1) Let the transactions T1, T2, T3 be defined to perform the following operations:

T1: Add one to A

T2: Double A
T3: Display A on the screen and set A to one.

Suppose transactions T1, T2, T3 are allowed to execute concurrently. If A has

initial value zero, how many possible correct results are there? Enumerate them.

……………………………………………………………………………………
……………………………………………………………………………………

2) Consider the following two transactions, given two bank accounts having a
balance A and B.
Transaction T1: Transfer Rs. 100 from A to B
Transaction T2: Find the multiple of A and B.
Create a non-serialisable schedule.
……………………………………………………………………………………
……………………………………………………………………………………

3) Add lock and unlock instructions (exclusive or shared) to transactions T1 and

T2 so that they observe the serialisable schedule. Make a valid schedule.
……………………………………………………………………………………
……………………………………………………………………………………

48
 Transactions and
2.5 DEADLOCK AND ITS PREVENTION Concurrency
Management

As seen earlier, though 2PL protocol handles the problem of serialisability, but it
causes some problems also. For example, consider the following two transactions and
a schedule involving these transactions:
TA TB
X_lock A X_lock A
X_lock B X_lock B
: :
: :
Unlock A Unlock A
Unlock B Unlock B

Schedule

T1: X_lock A
T2: X_lock B
T1: X_lock B
T2: X_lock A

As is clearly seen, the schedule causes a problem. After T1 has locked A, T2 locks B
and then T1 tries to lock B, but unable to do so waits for T2 to unlock B. Similarly, T2
tries to lock A but finds that it is held by T1 which has not yet unlocked it and thus
waits for T1 to unlock A. At this stage, neither T1 nor T2 can proceed since both of
these transactions are waiting for the other to unlock the locked resource.

Clearly the schedule comes to a halt in its execution. The important thing to be seen
here is that both T1 and T2 follow the 2PL, which guarantees serialisability. So
whenever the above type of situation arises, we say that a deadlock has occurred,
since two transactions are waiting for a condition that will never occur.

Also, the deadlock can be described in terms of a directed graph called a “wait for”
graph, which is maintained by the lock manager of the DBMS. This graph G is
defined by the pair (V, E). It consists of a set of vertices/nodes V is and a set of
edges/arcs E. Each transaction is represented by node and an arc from Ti Æ Tj, if Tj
holds a lock and Ti is waiting for it. When transaction Ti requests a data item
currently being held by transaction Tj then the edge Ti Æ Tj is inserted in the "wait
for" graph. This edge is removed only when transaction Tjj is no longer holding the
data item needed by transaction Ti.

A deadlock in the system of transactions occurs, if and only if the wait-for graph
contains a cycle. Each transaction involved in the cycle is said to be deadlocked.
To detect deadlocks, a periodic check for cycles in graph can be done. For example,
the “wait-for” for the schedule of transactions TA and TB as above can be made as:

TA TB

Figure 12: Wait For graph of TA and TB

49
Structured Query In the figure above, TA and TB are the two transactions. The two edges are present
Language and
Transaction Management
between nodes TA and TB since each is waiting for the other to unlock a resource
held by the other, forming a cycle, causing a deadlock problem. The above case shows
a direct cycle. However, in actual situation more than two nodes may be there in a
cycle.
A deadlock is thus a situation that can be created because of locks. It causes
transactions to wait forever and hence the name deadlock. A deadlock occurs because
of the following conditions:

a) Mutual exclusion: A resource can be locked in exclusive mode by only one

transaction at a time.
b) Non-preemptive locking: A data item can only be unlocked by the transaction
that locked it. No other transaction can unlock it.
c) Partial allocation: A transaction can acquire locks on database in a piecemeal
fashion.
d) Circular waiting: Transactions lock part of data resources needed and then wait
indefinitely to lock the resource currently locked by other transactions.
In order to prevent a deadlock, one has to ensure that at least one of these conditions
does not occur.
A deadlock can be prevented, avoided or controlled. Let us discuss a simple method
for deadlock prevention.

Deadlock Prevention

One of the simplest approaches for avoiding a deadlock would be to acquire all the
locks at the start of the transaction. However, this approach restricts concurrency
greatly, also you may lock some of the items that are not updated by that transaction
(the transaction may have if conditions).Thus, better prevention algorithm have been
evolved to prevent a deadlock having the basic logic: not to allow circular wait to
occur. This approach rolls back some of the transactions instead of letting them wait.
There exist two such schemes. These are:

“Wait-die” scheme: The scheme is based on non-preventive technique. It is

based on a simple rule:

If Ti requests a database resource that is held by Tj

then if Ti has a smaller timestamp than that of Tj
it is allowed to wait;
else Ti aborts.

A timestamp may loosely be defined as the system generated sequence number that is
unique for each transaction. Thus, a smaller timestamp means an older transaction.
For example, assume that three transactions T1, T2 and T3 were generated in that
sequence, then if T1requests for a data item which is currently held by transaction T2,
it is allowed to wait as it has a smaller time stamping than that of T1. However, if T3
requests for a data item which is currently held by transaction T2, then T3 is rolled
back (die).

T1 T2 T3
Wait Die

Figure 13: Wait-die Scheme of Deadlock prevention

50
“Wound-wait” scheme: It is based on a preemptive technique. It is based on a simple Transactions and
Concurrency
rule: Management
If Ti requests a database resource that is held by Tj
then if Ti has a larger timestamp (Ti is younger) than that of Tj
it is allowed to wait;
else Tj is wounded up by Ti.

For example, assume that three transactions T1, T2 and T3 were generated in that
sequence, then if T1requests for a data item which is currently held by transaction T2,
then T2 is rolled back and data item is allotted to T1 as T1 has a smaller time
stamping than that of T2. However, if T3 requests for a data item which is currently
held by transaction T2, then T3 is allowed to wait.

T1 T2 T3
Wound T2 Wait

Figure 14: Wound-wait Scheme of Deadlock prevention

It is important to see that whenever any transaction is rolled back, it would not make a
starvation condition, that is no transaction gets rolled back repeatedly and is never
allowed to make progress. Also both “wait-die” & “wound-wait” scheme avoid
starvation. The number of aborts & rollbacks will be higher in wait-die scheme than in
the wound-wait scheme. But one major problem with both of these schemes is that
these schemes may result in unnecessary rollbacks. You can refer to further readings
for more details on deadlock related schemes.

2.6 OPTIMISTIC CONCURRENCY CONTROL

Is locking the only way to prevent concurrency related problems? There exist some
other methods too. One such method is called an Optimistic Concurrency control. Let
us discuss it in more detail in this section.

The basic logic in optimistic concurrency control is to allow the concurrent

transactions to update the data items assuming that the concurrency related problem
will not occur. However, we need to reconfirm our view in the validation phase.
Therefore, the optimistic concurrency control algorithm has the following phases:

a) READ Phase: A transaction T reads the data items from the database into its
private workspace. All the updates of the transaction can only change the local
copies of the data in the private workspace.
b) VALIDATE Phase: Checking is performed to confirm whether the read values
have changed during the time transaction was updating the local values. This is
performed by comparing the current database values to the values that were read
in the private workspace. In case, the values have changed the local copies are
thrown away and the transaction aborts.
c) WRITE Phase: If validation phase is successful the transaction is committed and
updates are applied to the database, otherwise the transaction is rolled back.

Some of the terms defined to explain optimistic concurrency contents are:

• write-set(T): all data items that are written by a transaction T
• read-set(T): all data items that are read by a transaction T

51
Structured Query • Timestamps: for each transaction T, the start-time and the end time are kept
Language and
Transaction Management for all the three phases.
More details on this scheme are available in the further readings. But let us show this
scheme here with the help of the following examples:
Consider the set for transaction T1 and T2.

T1 T2
Phase Operation Phase Operation
- - Read Reads the read set (T2). Let say
variables X and Y and
performs updating of local
values
Read Reads the read set (T1) lets - -
say variable X and Y and
performs updating of local
values
Validate Validate the values of (T1) - -
- - Validate Validate the values of (T2)
Write Write the updated values in - -
the database and commit
- - Write Write the updated values in the
database and commit

In this example both T1 and T2 get committed. Please note that Read set of T1 and
Read Set of T2 are both disjoint, also the Write sets are also disjoint and thus no
concurrency related problem can occur.

T1 T2 T3
Operation Operation Operation
Read R(A) -- --
-- Read R(A) --
-- -- Read (D)
-- -- Update(D)
-- -- Update (A)
Validate (D,A) finds OK
-- --
Write (D,A), COMMIT
Validate(A):Unsuccessful
-- --
Value changed by T3
Validate(A):Unsuccessful
-- --
Value changed by T3
ABORT T1 -- --
-- Abort T2 --

In this case both T1 and T2 get aborted as they fail during validate phase while only
T3 is committed. Optimistic concurrency control performs its checking at the
transaction commits point in a validation phase. The serialization order is determined
by the time of transaction validation phase.

 Check Your Progress 3

1) Draw suitable graph for following locking requests, find whether the
transactions are deadlocked or not.

T1: S_lock A -- --
-- T2: X_lock B --
-- T2: S_lock C --

52
 -- -- T3: X_lock C Transactions and
Concurrency
-- T2: S_lock A -- Management
T1: S_lock B -- --
T1: S_lock A -- --
-- -- T3: S_lock A
All the unlocking requests start from here

……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………

2) What is Optimistic Concurrency Control?

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
………………………………………………………………………………….

2.7 SUMMARY

In this unit you have gone through the concepts of transaction and Concurrency
Management. A transaction is a sequence of many actions. Concurrency control deals
with ensuring that two or more users do not get into each other’s way, i.e., updates of
transaction one doesn’t affect the updates of other transactions.

Serializability is the generally accepted criterion for correctness for the concurrency
control. It is a concept related to concurrent schedules. It determines how to analyse
whether any schedule is serialisable or not. Any schedule that produces the same
results as a serial schedule is a serialisable schedule.

Concurrency Control is usually done via locking. If a transaction tries to lock a

resource already locked by some other transaction, it cannot do so and waits for the
resource to be unlocked.

Locks are of two type a) shared lock b) Exclusive lock. Then we move on to a method
known as Two Phase Locking (2PL). A system is in a deadlock state if there exist a
set of transactions such that every transaction in the set is waiting for another
transaction in the set. We can use a deadlock prevention protocol to ensure that the
system will never enter a deadlock state.

Finally we have discussed the method Optimistic Concurrency Control, another

concurrency management mechanism.

53
Structured Query
Language and
Transaction Management
2.8 SOLUTIONS / ANSWERS

Check Your Progress 1

1) A transaction is the basic unit of work on a Database management system. It

defines the data processing on the database. IT has four basic properties:

a. Atomicity: transaction is done completely or not at all.

b. Consistency: Leaves the database in a consistent state
c. Isolation: Should not see uncommitted values
d. Durability: Once committed the changes should be reflected.

A transaction can update more than one data values. Some transactions can do
writing of data without reading a data value.

A simple transaction example may be: Updating the stock inventory of an item
that has been issued. Please create a sample pseudo code for it.

2) The basic problems of concurrent transactions are:

• Lost updates: An update is overwritten

• Unrepeatable read: On reading a value later again an inconsistent value is
found.
• Dirty read: Reading an uncommitted value
• Inconsistent analysis: Due to reading partially updated value.
No these problems cannot occur if the transactions do not read the same data
values. The conflict occurs only if one transaction updates a data value while
another is reading or writing the data value.
3) Commit state is defined as when transaction has done everything correctly and
shows the intent of making all the changes as permanent. No, you cannot rollback
after commit.

Check Your Progress 2

1) There are six possible results, corresponding to six possible serial schedules:

Initially: A=0
T1-T2-T3: A=1
T1-T3-T2: A=2
T2-T1-T3: A=1
T2-T3-T1: A=2
T3-T1-T2: A=4
T3-T2-T1: A=3

2)

Schedule T1 T2
Read A Read A
A = A - 100 A = A - 100
Write A Write A
Read A Read A
Read B Read B

54
 Read B Read B Transactions and
Concurrency
Result = A * B Result = A * B Management
Display Result Display Result
B = B + 100 B = B + 100
Write B Write B

Please make the precedence graph and find out that the schedule is not serialisable.
3)
Schedule T1 T2
Lock A Lock A
Lock B Lock B
Read A Read A
A = A - 100 A = A - 100
Write A Write A
Unlock A Unlock A
Lock A Lock A: Granted
Lock B Lock B: Waits
Read B Read B
B = B + 100 B = B + 100
Write B Write B
Unlock B Unlock B
Read A Read A
Read B Read B
Result = A * B Result = A * B
Display Result Display Result
Unlock A Unlock A
Unlock B Unlock B

You must make the schedules using read and exclusive lock and a schedule in strict
2PL.

Check Your Progress 3

1) The transaction T1 gets the shared lock on A, T2 gets exclusive lock on B and
Shared lock on A, while the transactions T3 gets exclusive lock on C.

• Now T2 requests for shared lock on C which is exclusively locked by T3, so

cannot be granted. So T2 waits for T3 on item C.
• T1 now requests for Shared lock on B which is exclusively locked by T2,
thus, it waits for T2 for item B. The T1 request for shared lock on C is not
processed.
• Next T3 requests for exclusive lock on A which is share locked by T1, so it
cannot be granted. Thus, T3 waits for T1 for item A.

The Wait for graph for the transactions for the given schedule is:

T1 T3

T2

55
Structured Query Since there exists a cycle, therefore, the schedule is deadlocked.
Language and
Transaction Management
2) The basic philosophy for optimistic concurrency control is the optimism that
nothing will go wrong so let the transaction interleave in any fashion, but to
avoid any concurrency related problem we just validate our assumption before
we make changes permanent. This is a good model for situations having a low
rate of transactions.

56
 Database Recovery and
UNIT 3 DATABASE RECOVERY AND Security

SECURITY
Structure Page Nos.
3.0 Introduction 57
3.1 Objectives 57
3.2 What is Recovery? 57
3.2.1 Kinds of failures
3.2.2 Failure controlling methods
3.2.3 Database errors
3.3 Recovery Techniques 61
3.4 Security & Integrity 66
3.4.1 Relationship between Security and Integrity
3.4.2 Difference between Operating System and Database Security
3.5 Authorisation 68
3.6 Summary 71
3.7 Solutions/Answers 71

3.0 INTRODUCTION

In the previous unit of this block, you have gone through the concepts of transactions
and Concurrency management. In this unit we will introduce two important issues
relating to database management systems.

A computer system suffers from different types of failures. A DBMS controls very
critical data of an organisation and therefore must be reliable. However, the reliability
of the database system is linked to the reliability of the computer system on which it
runs. In this unit we will discuss recovery of the data contained in a database system
following failure of various types and present the different approaches to database
recovery. The types of failures that the computer system is likely to be subjected to
include failures of components or subsystems, software failures, power outages,
accidents, unforeseen situations and natural or man-made disasters. Database
recovery techniques are methods of making the database consistent till the last
possible consistent state. The aim of recovery scheme is to allow database operations
to be resumed after a failure with minimum loss of information at an economically
justifiable cost.

The second main issue that is being discussed in this unit is Database security.
“Database security” is protection of the information contained in the database against
unauthorised access, modification or destruction. The first condition for security is to
have Database integrity. “Database integrity” is the mechanism that is applied to
ensure that the data in the database is consistent.

Let us discuss all these terms in more detail in this unit.

3.1 OBJECTIVES

At the end of this unit, you should be able to:

• describe the terms RECOVERY and INTEGRITY;

• describe Recovery Techniques;
• define Error and Error detection techniques, and
• describe types of Authorisation.
57
Structured Query
Language and 3.2 WHAT IS RECOVERY?
Transaction Management

During the life of a transaction, that is, a after the start of a transaction but before the
transaction commits, several changes may be made in a database state. The database
during such a state is in an inconsistent state. What happens when a failure occurs at
this stage? Let us explain this with the help of an example:

Assume that a transaction transfers Rs.2000/- from A’s account to B’s account. For
simplicity we are not showing any error checking in the transaction. The transaction
may be written as:

Transaction T1:
READ A
A = A – 2000
WRITE A
Failure
READ B
B = B + 2000
WRITE B
COMMIT

What would happen if the transaction fails after account A has been written back to
database? As far as the holder of account A is concerned s/he has transferred the
money but that has never been received by account holder B.

Why did this problem occur? Because although a transaction is considered to be

atomic, yet it has a life cycle during which the database gets into an inconsistent state
and failure has occurred at that stage.

What is the solution? In this case where the transaction has not yet committed the
changes made by it, the partial updates need to be undone.

How can we do that? By remembering information about a transaction such as when

did it start, what items it updated etc. All such details are kept in a log file. We will
study about log in Section 3.3. But first let us analyse the reasons of failure.
Failures and Recovery
In practice several things might happen to prevent a transaction from completing.
Recovery techniques are used to bring database, which does not satisfy consistency
requirements, into a consistent state. If a transaction completes normally and commits
then all the changes made by the transaction on the database are permanently
registered in the database. They should not be lost (please recollect the durability
property of transactions given in Unit 2). But, if a transaction does not complete
normally and terminates abnormally then all the changes made by it should be
discarded. An abnormal termination of a transaction may be due to several reasons,
including:

a) user may decide to abort the transaction issued by him/ her

b) there might be a deadlock in the system
c) there might be a system failure.

The recovery mechanisms must ensure that a consistent state of database can be
restored under all circumstances. In case of transaction abort or deadlock, the system
remains in control and can deal with the failure but in case of a system failure the
system loses control because the computer itself has failed. Will the results of such
failure be catastrophic? A database contains a huge amount of useful information and

58
any system failure should be recognised on the restart of the system. The DBMS Database Recovery and
should recover from any such failures. Let us first discuss the kinds of failure for Security
identifying how to recover.
3.2.1 Kinds of Failures
The kinds of failures that a transaction program during its execution can encounter
are:
1) Software failures: In such cases, a software error abruptly stops the execution
of the current transaction (or all transactions), thus leading to losing the state of
program excution and the state/ contents of the buffers. But what is a buffer? A
buffer is the portion of RAM that stores the partial contents of database that is
currently needed by the transaction. The software failures can further be
subdivided as:
a) Statement or application program failure
b) Failure due to viruses
c) DBMS software failure
d) Operating system failure

A Statement of program may cause abnormal termination if it does not execute

completely. This happens if during the execution of a statement, an integrity
constraint gets violated. This leads to abnormal termination of the transaction
due to which any prior updates made by the transaction may still get reflected in
the database leaving it in an inconsistent state.

A failure of transaction can occur if some code in a transaction program leads to

its
abnormal termination. For example, a transaction can go into an infinite loop.
In such a case the only way to break the loop is to abort the program. Similarly,
the failure can be traced to the operating system or DBMS and transactions are
aborted abruptly. Thus part of the transaction that was executed before abort
may cause some updates in database, and hence the database is updated only
partially which leads to an inconsistent state of database.
2) Hardware failure: Hardware failures are those failures when some hardware
chip or disk fails. This may result in loss of data. One such problem can be that
a disk gets damaged and cannot be read any more. This may be due to many
reasons. For example, a voltage fluctuation in the power supply to the computer
makes it go off or some bad sectors may come on disk or there is a disk crash.
In all these cases, the database gets into an inconsistent state.
3) External failure: A failure can also result due to an external cause, such as
fire, earthquakes, floods, etc. The database must be duly backed up to avoid
problems occurring due to such failures.
In practice software failures are more common than hardware failures. Fortunately,
recovery from software failures is much quicker.

The basic unit of recovery is a transaction. But, how are the transactions handled
during recovery? Consider that some transactions are deadlocked, then at least one of
these transactions has to be restarted to break the deadlock and thus the partial updates
made by such restarted program in the database need to be undone so that the
database does not go to an inconsistent state. So the transaction may have to be rolled
back which makes sure that the transaction does not bring the database to an
inconsistent state. This is one form of recovery. Let us consider a case when a
transaction has committed but the changes made by the transaction have not been
communicated to permanently stored physical database. A software failure now
occurs and the contents of the CPU/ RAM are lost. This leaves the database in an
inconsistent state. Such failure requires that on restarting the system the database be
brought to a consistent state using redo operation. The redo operation makes the

59
Structured Query changes made by the transaction again to bring the system to a consistent state. The
Language and
database system then can be made available to the users. The point to be noted here is
Transaction Management
that the database updates are performed in the buffer in the memory. Figure 1 shows
some cases of undo and redo. You can create more such cases.

A= 6000
…………

B= 8000
A= 6000 ………
B= 8000

Physical database RAM Buffers CPU

Physical RAM Activity

Database
Case 1 A=6000 A=4000 Transaction T1 has just changed the
B=8000 B=8000 value in RAM. Now it aborts, value in
RAM is lost. No problem. But we are not
sure that the physical database has been
written back, so must undo.
Case 2 A=4000 A=4000 The value in physical database has got
B=8000 B=8000 updated due to buffer management, now
the transaction aborts. The transaction
must be undone.
Case 3 A=6000 A=4000 The value B in physical database has not
B=8000 B=10000 got updated due to buffer management.
Commit In case of failure now when the
transaction has committed. The changes
of transaction must be redone to ensure
transfer of correct values to physical
database.

Figure 1: Database Updates And Recovery

3.2.2 Failure Controlling Methods

Failures can be handled using different recovery techniques that are discussed later in
the unit. But the first question is do we really need recovery techniques as a failure
control mechanism? The recovery techniques are somewhat expensive both in terms
of time and in memory space for small systems. In such a case it is more beneficial to
better avoid the failure by some checks instead of deploying recovery technique to
make database consistent. Also, recovery from failure involves manpower that can be
used in some other productive work if failure can be avoided. It is, therefore,
important to find out some general precautions that help in controlling failure. Some
of these precautions may be:
• having a regulated power supply.
• having a better secondary storage system such as RAID.
• taking periodic backup of database states and keeping track of transactions after
each recorded state.
• properly testing the transaction programs prior to use.
• setting important integrity checks in the databases as well as user interfaces etc.

60
However, it may be noted that if the database system is critical it must use a DBMS Database Recovery and
that is suitably equipped with recovery procedures. Security

3.2.3 Database Errors

An error is said to have occurred if the execution of a command to manipulate the
database cannot be successfully completed either due to inconsistent data or due to
state of program. For example, there may be a command in program to store data in
database. On the execution of command, it is found that there is no space/place in
database to accommodate that additional data. Then it can be said that an error has
occurred. This error is due to the physical state of database storage.

Broadly errors are classified into the following categories:

1) User error: This includes errors in the program (e.g., Logical errors) as well as
errors made by online users of database. These types of errors can be avoided
by applying some check conditions in programs or by limiting the access rights
of online users e.g., read only. So only updating or insertion operation require
appropriate check routines that perform appropriate checks on the data being
entered or modified. In case of an error, some prompts can be passed to user to
enable him/her to correct that error.

2) Consistency error: These errors occur due to the inconsistent state of database
caused may be due to wrong execution of commands or in case of a transaction
abort. To overcome these errors the database system should include routines
that check for the consistency of data entered in the database.

3) System error: These include errors in database system or the OS, e.g.,
deadlocks. Such errors are fairly hard to detect and require reprogramming the
erroneous components of the system software.

Database errors can result from failure or can cause failure and thus will require
recovery. However, one of the main tasks of database system designers is to make
sure that errors minimised. These concepts are also related to database integrity and
have also been discusses in a later section.

3.3 RECOVERY TECHNIQUES

After going through the types of failures and database errors, let us discuss how to
recover from the failures. Recovery can be done using/restoring the previous
consistent state (backward recovery) or by moving forward to the next consistent state
as per the committed transactions (forward recovery) recovery. Please note that a
system can recover from software and hardware failures using the forward and
backward recovery only if the system log is intact. What is system log? We will
discuss it in more detail, but first let us define forward and backward recovery.

1) Backward Recovery (UNDO)

In this scheme the uncommitted changes made by a transaction to a database are

undone. Instead the system is reset to the previous consistent state of database that is
free from any errors.

61
Structured Query
Language and
Transaction Management
Database with
changes
Database
UNDO
without
changes

Before
images

2) Forward Recovery (Redo)

In this scheme the committed changes made by a transaction are reapplied to an
earlier copy of the database.

Database
without
changes REDO Database
with
changes

After
images

In simpler words, when a particular error in a system is detected, the recovery system
makes an accurate assessment of the state of the system and then makes the
appropriate adjustment based on the anticipated results - had the system been error
free.

One thing to be noted is that the Undo and Redo operations must be idempotent, i.e.,
executing them several times must be equivalent to executing them once. This
characteristic is required to guarantee correct behaviour of database even if a failure
occurs during the recovery process.

Depending on the above discussed recovery scheme, several types of recovery

methods have been used. However, we define the most important recovery schemes
used in most of the commercial DBMSs

Log based recovery

Let us first define the term transaction log in the context of DBMS. A transaction log
is a record in DBMS that keeps track of all the transactions of a database system that
update any data values in the database. A log contains the following information about
a transaction:

• A transaction begin marker

• The transaction identification: The transaction id, terminal id or user id etc.

62
• The operations being performed by the transaction such as update, delete, Database Recovery and
insert. Security
• The data items or objects that are affected by the transaction including name of
the table, row number and column number.
• The before or previous values (also called UNDO values) and after or changed
values (also called REDO values) of the data items that have been updated.
• A pointer to the next transaction log record, if needed.
• The COMMIT marker of the transaction.

In a database system several transactions run concurrently. When a transaction

commits, the data buffers used by it need not be written back to the physical database
stored on the secondary storage as these buffers may be used by several other
transactions that have not yet committed. On the other hand, some of the data buffers
that may have updates by several uncommitted transactions might be forced back to
the physical database, as they are no longer being used by the database. So the
transaction log helps in remembering which transaction did which changes. Thus the
system knows exactly how to separate the changes made by transactions that have
already committed from those changes that are made by the transactions that did not
yet commit. Any operation such as begin transaction, insert /delete/update and end
transaction (commit), adds information to the log containing the transaction identifier
and enough information to undo or redo the changes.

But how do we recover using log? Let us demonstrate this with the help of an example
having three concurrent transactions that are active on ACCOUNTS table as:

Transaction T1 Transaction T2 Transaction T3

Read X Read A Read Z
Subtract 100 Add 200 Subtract 500
Write X Write A Write Z
Read Y
Add 100
Write Y

Figure 2: The sample transactions

Assume that these transactions have the following log file (hypothetical) at a point:

Transaction Transaction Operation on UNDO REDO Transaction

Begin Id ACCOUNTS values values Commit
Marker table (assumed) Marker
Y T1 Sub on X 500 400 N
Add on Y 800 Not done yet
Y T2 Add on A 1000 1200 N
Y T3 Sub on Z 900 400 Y

Figure 3: A sample (hypothetical) Transaction log

Now assume at this point of time a failure occurs, then how the recovery of the
database will be done on restart.

Values Initial Just before the failure Operation Recovered

Required Database
for recovery Values
X 500 400 (assuming update has UNDO 500
been done in physical
database also)
Y 800 800 UNDO 800

63
Structured Query A 1000 1000 (assuming update has UNDO 1000
Language and
Transaction Management
not been done in physical
database)
Z 900 900 (assuming update has REDO 400
not been done in physical
database)

Figure 4: The database recovery

The selection of REDO or UNDO for a transaction for the recovery is done on the
basis of the state of the transactions. This state is determined in two steps:

• Look into the log file and find all the transactions that have started. For example,
in Figure 3, transactions T1, T2 and T3 are candidates for recovery.
• Find those transactions that have committed. REDO these transactions. All other
transactions have not committed so they should be rolled back, so UNDO them.
For example, in Figure 3 UNDO will be performed on T1 and T2; and REDO will
be performed on T3.

Please note that in Figure 4 some of the values may not have yet been communicated
to database, yet we need to perform UNDO as we are not sure what values have been
written back to the database.
But how will the system recover? Once the recovery operation has been specified, the
system just takes the required REDO or UNDO values from the transaction log and
changes the inconsistent state of database to a consistent state. (Please refer to
Figure 3 and Figure 4).

Let us consider several transactions with their respective start & end (commit) times
as shown in Figure 5.

T1

T2
T3

T4

t2

Failure time

Figure 5: Execution of Concurrent Transactions

In the figure above four transactions are executing concurrently, on encountering a

failure at time t2, the transactions T1 and T2 are to be REDONE and T3 and T4 will
be UNDONE. But consider a system that has thousands of parallel transactions then
all those transactions that have been committed may have to be redone and all
uncommitted transactions need to be undone. That is not a very good choice as it
requires redoing of even those transactions that might have been committed even
hours earlier. So can we improve on this situation? Yes, we can take checkpoints.
Figure 6 shows a checkpoint mechanism:

64
 Database Recovery and
T1 Security

T2
T3
T4

t1 t2 time

Checkpoint Failure

Figure 6: Checkpoint In Transaction Execution

A checkpoint is taken at time t1 and a failure occurs at time t2. Checkpoint transfers
all the committed changes to database and all the system logs to stable storage (it is
defined as the storage that would not be lost). At restart time after the failure the stable
check pointed state is restored. Thus, we need to only REDO or UNDO those
transactions that have completed or started after the checkpoint has been taken. The
only possible disadvantages of this scheme may be that during the time of taking the
checkpoint the database would not be available and some of the uncommitted values
may be put in the physical database. To overcome the first problem the checkpoints
should be taken at times when system load is low. To avoid the second problem some
systems allow some time to the ongoing transactions to complete without restarting
new transactions.

In the case of Figure 6 the recovery from failure at t2 will be as follows:

• The transaction T1 will not be considered for recovery as the changes made by
it have already been committed and transferred to physical database at
checkpoint t1.
• The transaction T2 since it has not committed till the checkpoint t1 but have
committed before t2, will be REDONE.
• T3 must be UNDONE as the changes made by it before checkpoint (we do not
know for sure if any such changes were made prior to checkpoint) must have
been communicated to the physical database. T3 must be restarted with a new
name.
• T4 started after the checkpoint, and if we strictly follow the scheme in which
the buffers are written back only on the checkpoint, then nothing needs to be
done except restarting the transaction T4 with a new name.

The restart of a transaction requires the log to keep information of the new name of
the transaction and maybe give higher priority to this newer transaction.

But one question is still unanswered that is during a failure we lose database
information in RAM buffers, we may also lose log as it may also be stored in RAM
buffers, so how does log ensure recovery?

The answer to this question lies in the fact that for storing transaction log we follow a
Write Ahead Log Protocol. As per this protocol, the transaction logs are written to
stable storage before any item is updated. Or more specifically it can be stated as; the
undo potion of log is written to stable storage prior to any updates and redo
portion of log is written to stable storage prior to commit.

Log based recovery scheme can be used for any kind of failure provided you have
stored the most recent checkpoint state and most recent log as per write ahead log

65
Structured Query protocol into the stable storage. Stable storage from the viewpoint of external failure
Language and
requires more than one copy of such data at more than one location. You can refer to
Transaction Management
the further readings for more details on recovery and its techniques.

 Check Your Progress 1

1) What is the need of recovery? What is it the basic unit of recovery?

……………………………………………………………………………………
……………………………………………………………………………………
2) What is a checkpoint? Why is it needed? How does a checkpoint help in
recovery?
……………………………………………………………………………………
……………………………………………………………………………………
3) What are the properties that should be taken into consideration while selecting
recovery techniques?
……………………………………………………………………………………
……...……..……………………………………………………………………..

3.4 SECURITY AND INTEGRITY

After going through the concepts of database recovery in the previous section, let us
now deal with an important concept that helps in minimizing consistency errors in
database systems. These are the concepts of database security and integrity.
Information security is the protection of information against unauthorised disclosure,
alteration or destruction. Database security is the protection of information that is
maintained in a database. It deals with ensuring only the “right people” get the right
to access the “right data”. By right people we mean those people who have the right
to access/update the data that they are requesting to access/update with the database.
This should also ensure the confidentiality of the data. For example, in an educational
institution, information about a student’s grades should be made available only to that
student, whereas only the university authorities should be able to update that
information. Similarly, personal information of the employees should be accessible
only to the authorities concerned and not to everyone. Another example can be the
medical records of patients in a hospital. These should be accessible only to health
care officials.
Thus, one of the concepts of database security is primarily a specification of access
rules about who has what type of access to what information. This is also known as
the problem of Authorisation. These access rules are defined at the time database is
defined. The person who writes access rules is called the authoriser. The process of
ensuring that information and other protected objects are accessed only in authorised
ways is called access control. There may be other forms of security relating to
physical, operating system, communication aspects of databases. However, in this
unit, we will confine ourselves mainly to authorisation and access control using
simple commands.
The term integrity is also applied to data and to the mechanism that helps to ensure its
consistency. Integrity refers to the avoidance of accidental loss of consistency.
Protection of database contents from unauthorised access includes legal and ethical
issues, organization policies as well as database management policies. To protect
database several levels of security measures are maintained:

66
 1) Physical: The site or sites containing the computer system must be physically Database Recovery and
secured against illegal entry of unauthorised persons. Security

2) Human: An Authorisation is given to a user to reduce the chance of any

information leakage and unwanted manipulations.
3) Operating System: Even though foolproof security measures are taken to
secure database systems, weakness in the operating system security may serve
as a means of unauthorised access to the database.
4) Network: Since databases allow distributed or remote access through terminals
or network, software level security within the network software is an important
issue.
5) Database system: The data items in a database need a fine level of access
control. For example, a user may only be allowed to read a data item and is
allowed to issue queries but would not be allowed to deliberately modify the
data. It is the responsibility of the database system to ensure that these access
restrictions are not violated. Creating database views as discussed in Unit 1
Section 1.6.1 of this block is a very useful mechanism of ensuring database
security.
To ensure database security requires implementation of security at all the levels as
above. The Database Administrator (DBA) is responsible for implementing the
database security policies in a database system. The organisation or data owners create
these policies. DBA creates or cancels the user accounts assigning appropriate
security rights to user accounts including power of granting and revoking certain
privileges further to other users.

3.4.1 Relationship between Security and Integrity

Database security usually refers to access, whereas database integrity refers to
avoidance of accidental loss of consistency. But generally, the turning point or the
dividing line between security and integrity is not always clear. Figure 7 shows the
relationship between data security and integrity.

USER

Information modification

Security Violation No Security Violation

(Unauthorised modification) (Authorised modification)

No Correct Inadvertently Maliciously Correct

Modification (Usually Incorrect Incorrect
Possible doesn’t exist)

Integrity No
Violation Integrity
Violation

Figure 7: Relationship between security and Integrity

67
Structured Query 3.4.2 Difference between Operating System and Database Security
Language and
Transaction Management
Security within the operating system can be implemented at several levels ranging
from passwords for access to system, to the isolation of concurrent executing
processes with the system. However, there are a few differences between security
measures taken at operating system level as compared to those that of database
system. These are:

• Database system protects more objects, as the data is persistent in nature. Also
database security is concerned with different levels of granularity such as file,
tuple, an attribute value or an index. Operating system security is primarily
concerned with the management and use of resources.
• Database system objects can be complex logical structures such as views, a
number of which can map to the same physical data objects. Moreover different
architectural levels viz. internal, conceptual and external levels, have different
security requirements. Thus, database security is concerned with the semantics –
meaning of data, as well as with its physical representation. Operating system can
provide security by not allowing any operation to be performed on the database
unless the user is authorized for the operation concerned.

Figure 8 shows the architecture of a database security subsystem that can be found in
any commercial DBMS.

USERS

Trusted Front End

Operating System Security Security Kernel

Physical Reference monitor Logical

Untrusted DBMS

Object (files, index files) Tuples (buffers)

Figure 8: Database Security subsystem

3.5 AUTHORISATION

Authorisation is the culmination of the administrative policies of the organisation. As

the name specifies, authorisation is a set of rules that can be used to determine which
user has what type of access to which portion of the database. The following forms of
authorisation are permitted on database items:

1) READ: it allows reading of data object, but not modification, deletion or

insertion of data object.
2) INSERT: allows insertion of new data, but not the modification of existing data,
e.g., insertion of tuple in a relation.
3) UPDATE: allows modification of data, but not its deletion. But data items like
primary-key attributes may not be modified.

68
4) DELETE: allows deletion of data only. Database Recovery and
Security
A user may be assigned all, none or a combination of these types of Authorisation,
which are broadly called access authorisations.

In addition to these manipulation operations, a user may be granted control operations

like

1) Add: allows adding new objects such as new relations.

2) Drop: allows the deletion of relations in a database.

3) Alter: allows addition of new attributes in a relations or deletion of existing

attributes from the database.

4) Propagate Access Control: this is an additional right that allows a user to

propagate the access control or access right which s/he already has to some other,
i.e., if user A has access right R over a relation S, then if s/he has propagate
access control, s/he can propagate her/his access right R over relation S to another
user B either fully or part of it. In SQL you can use WITH GRANT OPTION for
this right.

You must refer to Section 1.5 of Unit 1 of this block for the SQL commands relating
to data and user control.
The ultimate form of authority is given to the database administrator. He is the one
who may authorize new users, restructure the database and so on. The process of
Authorisation involves supplying information known only to the person the user has
claimed to be in the identification procedure.
A basic model of Database Access Control
Models of database access control have grown out of earlier work on protection in
operating systems. Let us discuss one simple model with the help of the following
example:

Security problem: Consider the relation:

Employee (Empno, Name, Address, Deptno, Salary, Assessment)

Assuming there are two users: Personnel manager and general user . What access
rights may be granted to each user? One extreme possibility is to grant an
unconstrained access or to have a limited access.

Unconstrained Object
access Strictly limited
access

One of the most influential protection models was developed by Lampson and
extended by Graham and Denning. This model has 3 components:

1) A set of objects: where objects are those entities to which access must be
controlled.

2) A set of subjects: where subjects are entities that request access to objects.

3) A set of all access rules: which can be thought of as forming an access (often
referred to as authorisation matrix).

69
Structured Query Let us create a sample authorisation matrix for the given relation:
Language and
Transaction Management
Object Empno Name Address Deptno Salary Assessment

Subject
Personnel Read All All All All All
Manager
General Read Read Read Read Not Not
User accessible accessible

As the above matrix shows, Personnel Manager and general user are the two subjects.
Objects of database are Empno, Name, Address, Deptno, Salary and Assessment. As
per the access matrix, Personnel Manager can perform any operation on the database
of an employee except for updating the Empno that may be self-generated and once
given can never be changed. The general user can only read the data but cannot
update, delete or insert the data into the database. Also the information about the
salary and assessment of the employee is not accessible to the general user.

In summary, it can be said that the basic access matrix is the representation of basic
access rules. These rules may be implemented using a view on which various access
rights may be given to the users.

 Check Your Progress 2

1) What are the different types of data manipulation operations and control
operations?
……………………………………………………………………………………
……..…………………………………………………………………………….
………..……..……………………………………………………………………
……………..……..…..………………………………………………………….
……………………..……..……..……………………………………………….
……………………………………………………………………………………
……………………………………………………………………………………

2) What is the main difference between data security and data integrity?

……………………………………………………………………………
……………………………………………………………………………
……………………………………………………………………………
……………………………………………………………………………
……………………………………………………………………………

3) What are the various aspects of security problem?

……………………………………………………………………………………
……..……………………………………………………………………………
………….…..……………………………………………………………………
……………….……..……………………………………………………………

70
4) Name the 3 main components of Database Access Control Model? Database Recovery and
Security
……………………………………………………………………………………
……………………………………………………………………………………
……….………...…………………………………………………………………
……………………………………………………………………………………

3.6 SUMMARY

In this unit we have discussed the recovery of the data contained in a database system
after failures of various types. The types of failures that the computer system is likely
to be subject to include that of components or subsystems, software failures, power
outages, accidents, unforeseen situations, and natural or man-made disasters.
Database recovery techniques are methods of making the database fault tolerant. The
aim of the recovery scheme is to allow database operations to be resumed after a
failure with the minimum loss of information and at an economically justifiable cost.

The basic technique to implement database recovery is by using data redundancy in

the form of logs, and archival copies of the database. Checkpoint helps the process of
recovery.

Security and integrity concepts are crucial since modifications in a database require
the replacement of the old values. The DBMS security mechanism restricts users to
only those pieces of data that are required for the functions they perform. Security
mechanisms restrict the type of actions that these users can perform on the data that is
accessible to them. The data must be protected from accidental or intentional
(malicious) corruption or destruction. In addition, there is a privacy dimension to data
security and integrity.

Security constraints guard against accidental or malicious tampering with data;

integrity constraints ensure that any properly authorized access, alteration, deletion, or
insertion of the data in the database does not change the consistency and validity of
the data. Database integrity involves the correctness of data and this correctness has
to be preserved in the presence of concurrent operations, error in the user’s operation
and application programs, and failures in hardware and software.

3.7 SOLUTIONS/ANSWERS

Check Your Progress 1

1) Recovery is needed to take care of the failures that may be due to software,
hardware and external causes. The aim of the recovery scheme is to allow
database operations to be resumed after a failure with the minimum loss of
information and at an economically justifiable cost. One of the common
techniques is log-based recovery. A transaction is the basic unit of recovery.

2) A checkpoint is a point when all the database updates and logs are written to
stable storage. A checkpoint ensures that not all the transactions need to be
REDONE or UNDONE. Thus, it helps in faster recovery from failure. You
should create a sample example, for checkpoint having a sample transaction
log.

3) The following properties should be taken into consideration:

71
Structured Query • Loss of data should be minimal
Language and
Transaction Management • Recovery should be quick
• Recovery should be automatic
• Affect small portion of database.

Check Your Progress 2

1) Data manipulation operations are:

• Read
• Insert
• Delete
• Update

Data control operations are:

• Add
• Drop
• Alter
• Propagate access control

2) Data security is the protection of information that is maintained in database

against unauthorised access, modification or destruction. Data integrity is the
mechanism that is applied to ensure that data in the database is correct and
consistent.
3)
• Legal, social and ethical aspects
• Physical controls
• Policy questions
• Operational problems
• Hardware control
• Operating system security
• Database administration concerns

4) The three components are:

• Objects
• Subjects
• Access rights

72
 Distributed and Client
UNIT 4 DISTRIBUTED AND CLIENT Server Databases

SERVER DATABASES
Structure Page Nos.
4.0 Introduction 73
4.1 Objectives 73
4.2 Need for Distributed Database Systems 73
4.3 Structure of Distributed Database 74
4.4 Advantages and Disadvantages of DDBMS 78
4.4.1 Advantages of Data Distribution
4.4.2 Disadvantages of Data Distribution
4.5 Design of Distributed Databases 81
4.5.1 Data Replication
4.5.2 Data Fragmentation
4.6 Client Server Databases 87
4.6.1 Emergence of Client Server Architecture
4.6.2 Need for Client Server Computing
4.6.3 Structure of Client Server Systems
4.6.4 Advantages of Client Server Systems
4.7 Summary 91
4.8 Solutions/Answers 92

4.0 INTRODUCTION
In the previous units, we have discussed the basic issues relating to Centralised
database systems. This unit discusses the distributed database systems which are
primarily relational and one important implementation model: the client server model.
This unit focuses on the basic issues involved in the design of distributed database
designs. The unit also discusses some very basic concepts; in respect of client server
computing including the basic structure, advantages/disadvantages etc. It will be
worth mentioning here that almost all the commercial database management systems
follow such a model of implementation. Although in client server model one of the
concepts is the concept of distribution but it is primarily distribution of roles on server
computers or rather distribution of work. So a client server system may be a
centralised database.

4.1 OBJECTIVES

After going through this unit, you should be able to:

• differentiate DDBMS and conventional DBMS;

• define Network topology for DDBMS;
• define the concepts of horizontal and vertical fragmentation;
• define the concepts and rates of client server computing, and
• identify the needs of all these systems.

4.2 NEED FOR DISTRIBUTED DATABASE

SYSTEMS
A distributed database is a set of database stored on multiple computers that appears
to applications as a single database. As a result, an application can simultaneously
access and modify the data in several databases in a network. Each database in the
73
Structured Query system is controlled by its local server but cooperates to maintain the consistency of
Language and
Transaction Management
the global distributed database. The computers in a distributed system communicate
with each other through various communication media, such as high-speed buses or
telephone line. They don’t share main memory, nor a clock, although, to work
properly many applications on different computers might have to synchronise their
clocks. In some cases the absolute time might be important and the clocks might have
to be synchronised with atomic clocks.

The processors in a distributed system may vary in size and function such as small
microcomputers, workstation, minicomputers, and large general-purpose computer
system. These processors are referred to by sites, nodes, computers, and so on,
depending on the context in which they are mentioned. We mainly use the term site, in
order to emphasise the physical distribution of these systems.

A distributed database system consists of a collection of sites, each of which may

participate in the execution of transactions, which access data at one site, or several
sites. The main difference between centralised and distributed database systems is
that, in the former, the data resides in one single Centralised control, while in the
latter, the data resides in several sets under the control of local distributed DBMS
components which are under the control of one DBMS. As we shall see, this
distribution of data is the cause of many difficulties that will be addressed in this unit.

Independent or decentralised systems were normally used in earlier days. There was
duplication of hardware and other facilities. Evolution of computer systems also led to
incompatible procedures and lack of management control. A centralised database
system was then evolved. In a centralised database the DBMS and data reside at a
single database instance. Although for recovery purposes we keep redundant database
information yet it is under the control of a single DBMS. A further enhancement of
the centralised database system may be to provide access to centralised data from a
number of distributed locations through a network. In such a system a site failure
except the central site will not result in total system failure. Although, communication
technology has greatly improved yet the centralised approach may create problems for
an organization that has geographically dispersed operations and data has to be
accessed from a centralised database. Some of the problems may be:

a. loss of messages between a local and central site;

b. failure of communication links between local and central site. This would make
the system unreliable;
c. excessive load on the central site would delay queries and accesses. A single
site would have to bear a large number of transactions and hence would require
large computing systems.
The problems as above could be addressed using distributed database systems. It
improves the reliability and sharability of data and the efficiency of data access.
Distributed Database Systems can be considered a system connected to intelligent
remote devices each of which can itself act as a local database repository. All data is
accessible from each site. The distributed system increases the efficiency of access
because multiple of sites can co-ordinate efficiently to respond to a query and control
& processing is limited to this DBMS.

4.3 STRUCTURE OF DISTRIBUTED DATABASE

A distributed database system consists of a collection of sites, each of which

maintains a local databases system. Each site is able to process local transactions,
those transactions that access data only in that single site. In addition, a site may

74
participate in the execution of global transactions, those transactions that access data Distributed and Client
Server Databases
at several sites. The architecture of Distributed Database systems is given in Figure 1

Figure 1: Three different database system architectures. (a) No database sharing architecture.
(b) A networked architecture with a centralised database.
(c) A distributed database architecture

75
Structured Query The execution of global transactions on the distributed architecture requires
Language and
Transaction Management
communication among the sites. Figure 2 illustrates a representative distributed
database system architecture having transactions. Please note that both the
transactions shown are global in nature as they require data from both the sites.

Figure 2: Distributed Database Schema and Transactions

Some of the key issues involving DDBMS are:

• How the data is distributed?

• Is this data distribution hidden from the general users?
• How is the integration of data and its control including security managed locally
and globally?
• How are the distributed database connected?

Well we will provide the basic answers to most of these questions during the course of
this unit. However, for more details, you may refer to further readings.

76
The sites in a distributed system can be connected physically in a variety of ways. The Distributed and Client
Server Databases
various topologies are represented as graphs whose nodes correspond to sites. An edge
from node A to node B corresponds to a direct connection between the two sites.

Some of the most common connection structures are depicted in Figure 3. The major
differences among these configurations involve:

• Installation cost. The cost of physically linking the sites in the system
• Communication cost. The cost in time and money to send a message from site
A to site B.

• Reliability. The frequency with which a link or site fails.

• Availability. The degree to which data can be accessed despite failure of some
links or sites.

These differences play an important role in choosing the appropriate mechanism for
handling the distribution of data The sites of a distributed database system may be
distributed physically either over a large geographical area (such as all over India), or
over a small geographical area such as a single building or a number of adjacent
buildings). The former type of network is based on wide area network, while the latter
uses local-area network.

Figure 3: Some interconnection Networks

77
Structured Query Since the sites in wide area networks are distributed physically over a large
Language and
Transaction Management
geographical area, the communication links are likely to be relatively slow and less
reliable as compared with local-area networks. Typical wide area links are telephone
lines, microwave links, and satellite channels. Many newer enhanced communication
technologies including fiber optics are also used for such links. The local-area
network sites are close to each other, communication links are of higher speed and
lower error rate than their counterparts in wide area networks. The most common
links are twisted pair, base band coaxial, broadband coaxial, and fiber optics.

A Distributed Transaction
Let us illustrate the concept of a distributed transaction by considering a banking
system consisting of three branches located in three different cities. Each branch has
its own computer with a database consisting of all the accounts maintained at that
branch. Each such installation is thus a site. There also exists one single site which
maintains information about all the other branches of the bank. Suppose that the
database systems at the various sites are based on the relational model. Each branch
maintains its portion of the relation: DEPOSIT (DEPOSIT-BRANCH) where

DEPOSIT-BRANCH = (branch-name, account-number, customer-name, balance)

A site containing information about the four branches maintains the relation branch-
details, which has the schema as:

BRANCH-DETAILS (branch-name, Financial_ health, city)

There are other relations maintained at the various sites which are ignored for the
purpose of our example.

A local transaction is a transaction that accesses accounts in one single site, at which
the transaction was initiated. A global transaction, on the other hand, is one which
either accesses accounts in a site different from the one at which the transaction was
initiated, or accesses accounts in several different sites. To illustrate the difference
between these two types of transactions, consider the transaction to add Rs.5000 to
account number 177 located at the Delhi branch. If the transaction was initiated at the
Delhi branch, then it is considered local; otherwise, it is considered global. A
transaction to transfer Rs.5000 from account 177 to account 305, which is located at
the Bombay branch, is a global transaction since accounts in two different sites are
accessed as a result of its execution. A transaction finding the total financial standing
of all branches is global.

What makes the above configuration a distributed database system are the facts that:

• The various sites may be locally controlled yet are aware of each other.

• Each site provides an environment for executing both local and global
transactions.

However, a user need not know whether on underlying application is distributed or

not.

4.4 ADVANTAGES AND DISADVANTAGES OF

DDBMS
There are several reasons for building distributed database systems, including sharing
of data, reliability and availability, and speedup of query processing. However, along
with these advantages come several disadvantages, including software development

78
cost, greater potential for bugs, and increased processing overheads. In this section, Distributed and Client
Server Databases
we shall elaborate briefly on each of these.

4.4.1 Advantages of Data Distribution

The primary advantage of distributed database systems is the ability to share and
access data in a reliable and efficient manner.

Data sharing and Distributed Control

The geographical distribution of an organization can be reflected in the distribution of
the data; if a number of different sites are connected to each other, then a user at one
site may be able to access data that is available at another site. The main advantage
here is that the user need not know the site from which data is being accessed. Data
can be placed at the site close to the users who normally use that data. The local
control of data allows establishing and enforcement of local policies regarding use of
local data. A global database administrator (DBA) is responsible for the entire system.
Generally, part of this responsibility is given to the local administrator, so that the
local DBA can manage the local DBMS. Thus in the distributed banking system, it is
possible for a user to get his/her information from any branch office. This external
mechanism would, in effect to a user, look to be a single centralised database.

The primary advantage of accomplishing data sharing by means of data distribution is

that each site is able to retain a degree of control over data stored locally. Depending
upon the design of the distributed database system, each local administrator may have
a different degree of autonomy. This is often a major advantage of distributed
databases. In a centralised system, the database administrator of the central site
controls the database and, thus, no local control is possible.

Reflects organisational structure

Many organizations are distributed over several locations. If an organisation has
many offices in different cities, databases used in such an application are distributed
over these locations. Such an organisation may keep a database at each branch office
containing details of the staff that work at that location, the local properties that are
for rent, etc. The staff at a branch office will make local inquiries to such data of the
database. The company headquarters may wish to make global inquiries involving
the access of data at all or a number of branches.

Improved Reliability
In a centralised DBMS, a server failure terminates the operations of the DBMS.
However, a failure at one site of a DDBMS, or a failure of a communication link
making some sites inaccessible, does not make the entire system inoperable.
Distributed DBMSs are designed to continue to function despite such failures. In
particular, if data are replicated in several sites, a transaction needing a particular data
item may find it at several sites. Thus, the failure of a site does not necessarily imply
the shutdown of the system.

The failure of one site must be detected by the system, and appropriate action may be
needed to recover from the failure. The system must no longer use the services of the
failed site. Finally, when the failed site recovers or is repaired, mechanisms must be
available to integrate it smoothly back into the system. The recovery from failure in
distributed systems is much more complex than in a centralised system.

Improved availability

The data in a distributed system may be replicated so that it exists at more than one
site. Thus, the failure of a node or a communication link does not necessarily make the
data inaccessible. The ability of most of the systems to continue to operate despite the
failure of one site results in increased availability which is crucial for database

79
Structured Query systems used for real-time applications. For example, loss of access to data in an
Language and
airline may result in the loss of potential ticket buyers to competitors.
Transaction Management
Improved performance
As the data is located near the site of its demand, and given the inherent parallelism
due to multiple copies, speed of database access may be better for distributed
databases than that of the speed that is achievable through a remote centralised
database. Furthermore, since each site handles only a part of the entire database, there
may not be the same contention for CPU and I/O services as characterized by a
centralised DBMS.

Speedup Query Processing

A query that involves data at several sites can be split into sub-queries. These sub-
queries can be executed in parallel by several sites. Such parallel sub-query evaluation
allows faster processing of a user's query. In those cases in which data is replicated,
queries may be sent to the least heavily loaded sites.
Economics
It is now generally accepted that it costs less to create a system of smaller computers
with the equivalent power of a single large computer. It is more cost-effective to
obtain separate computers. The second potential cost saving may occurs where
geographically remote access to distributed data is required. In such cases the
economics is to minimise cost due to the data being transmitted across the network
for data updates as opposed to the cost of local access. It may be more economical to
partition the application and perform the processing locally at application site.
Modular growth
In distributed environments, it is easier to expand. New sites can be added to the
network without affecting the operations of other sites, as they are somewhat
independent. This flexibility allows an organisation to expand gradually. Adding
processing and storage power to the network can generally result in better handling of
ever increasing database size. A more powerful system in contrast, a centralised
DBMS, would require changes in both the hardware and software with increasing size
and more powerful DBMS to be procured.

4.4.2 Disadvantages of Data Distribution

The primary disadvantage of distributed database systems is the added complexity
required to ensure proper coordination among the sites. This increased complexity
takes the form of:
• Higher Software development cost: Distributed database systems are
complex to implement and, thus, more costly. Increased complexity implies
that we can expect the procurement and maintenance costs for a DDBMS to be
higher than those for a centralised DBMS. In addition to software, a distributed
DBMS requires additional hardware to establish a network between sites.
There are ongoing communication costs incurred with the use of this network.
There are also additional maintenance costs to manage and maintain the local
DBMSs and the network.

• Greater potential for bugs: Since the sites of a distributed system operate
concurrently, it is more difficult to ensure the correctness of algorithms. The art
of constructing distributed algorithms is an active and important area of
research.

• Increased processing overhead: The exchange of messages and the additional

computation required to achieve coordination among the sites is an overhead
that does not arise in centralised systems.

80
• Complexity: A distributed DBMS that is reliable, available and secure is Distributed and Client
Server Databases
inherently more complex than a centralised DBMS. Replication of data
discussed in the next section, also adds to complexity of the distributed DBMS.
However, adequate data replication is necessary to have availability, reliability,
and performance.

• Security: In a centralised system, access to the data can be easily controlled.

However, in a distributed DBMS not only does access to replicated data have to
be controlled in multiple locations, but also the network needs to be secured.
Networks over a period have become more secure, still there is a long way to
go.

• Lack of standards and experience: The lack of standards has significantly

limited the potential of distributed DBMSs. Also, there are no tools or
methodologies to help users convert a centralised DBMS into a distributed
DBMS.

• General Integrity control more difficult: Integrity is usually expressed in

terms of constraints or the rules that must be followed by database values. In a
distributed DBMS, the communication and processing costs that are required to
enforce integrity constraints may be very high as the data is stored at various
sites. However, with better algorithms we can reduce such costs.

• Purpose: General-purpose distributed DBMSs have not been widely accepted.

We do not yet have the same level of experience in industry as we have with
centralised DBMSs.

• Database design more complex: Besides the normal difficulties of designing a

centralised database, the design of a distributed database has to take account of
fragmentation of data, allocation of fragments to specific sites, and data
replication. The designer of distributes systems must balance the advantages
against the disadvantages of distribution of data.

 Check Your Progress 1

1) What are the advantages of distributed databases over centralised Databases?

……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
2) Differntiate between global and local transaction.
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………

4.5 DESIGN OF DISTRIBUTED DATABASES

The distributed databases are primarily relational at local level. So a local database
schema is the same as that of a centralised database design. However, a few more
dimensions have been added to the design of distributed database. These are:

• Replication: It is defined as a copy of a relation. Each replica is stored at a

different site. The alternative to replication is to store only one copy of a
relation which is not recommended in distributed databases.

81
Structured Query • Fragmentation: It is defined as partitioning of a relation into several fragments.
Language and
Transaction Management Each fragment can be stored at a different site.

The distributed database design is a combination of both these concepts. Let us

discuss them in more detail in the following subsections.

4.5.1 Data Replication

“If a relation R has its copies stored at two or more sites, then it is considered
replicated”.
But why do we replicate a relation?
There are various advantages and disadvantages of replication of relation
• Availability: A site containing the copy of a replicated relation fails, even then
the relation may be found in another site. Thus, the system may continue to
process at least the queries involving just read operation despite the failure of
one site. Write can also be performed but with suitable recovery algorithm.

• Increased parallelism: Since the replicated date has many copies a query can
be answered from the least loaded site or can be distributed. Also, with more
replicas you have greater chances that the needed data is found on the site where
the transaction is executing. Hence, data replication can minimise movement of
data between sites.

• Increased overheads on update: On the disadvantage side, it will require the

system to ensure that all replicas of a relation are consistent. This implies that
all the replicas of the relation need to be updated at the same time, resulting in
increased overheads. For example, in a banking system, if account information
is replicated at various sites, it is necessary that the balance in a particular
account should be the same at all sites.
The problem of controlling concurrent updates by several transactions to replicated
data is more complex than the centralised approach of concurrency control. The
management of replicas of relation can be simplified by choosing one of the replicas
as the primary copy. For example, in a banking system, the primary copy of an
account may be the site at which the account has been opened. Similarly, in an airline
reservation system, the primary copy of the flight may be associated with the site at
which the flight originates. The replication can be classified as:
Complete replication: It implies maintaining of a complete copy of the database at
each site. Therefore, the reliability and availability and performance for query
response are maximized. However, storage costs, communication costs, and updates
are expensive. To overcome some of these problems relation, snapshots are sometimes
used. A snapshot is defined as the copy of the data at a given time. These copies are
updated periodically, such as, hourly or weekly. Thus, snapshots may not always be
up to date.
Selective replication: This is a combination of creating small fragments of relation
and replicating them rather than a whole relation. The data should be fragmented on
need basis of various sites, as per the frequency of use, otherwise data is kept at a
centralised site. The objective of this strategy is to have just the advantages of the
other approach but none of the disadvantages. This is the most commonly used
strategy as it provides flexibility.

4.5.2 Data Fragmentation

“Fragmentation involves decomposing the data in relation to non-overlapping
component relations”.
Why do we need to fragment a relation? The reasons for fragmenting a relation are:

82
Use of partial data by applications: In general, applications work with views Distributed and Client
Server Databases
rather than entire relations. Therefore, it may be more appropriate to work with
subsets of relations rather than entire data.
Increases efficiency: Data is stored close to most frequently used site, thus retrieval
would be faster. Also, data that is not needed by local applications is not stored, thus
the size of data to be looked into is smaller.
Parallelism of transaction execution: A transaction can be divided into several
sub-queries that can operate on fragments in parallel. This increases the degree of
concurrency in the system, thus allowing transactions to execute efficiently.
Security: Data not required by local applications is not stored at the site, thus no
unnecessary security violations may exist.
But how do we carry out fragmentation? Fragmentation may be carried out as per the
following rules:
a) Completeness: This rule ensures that there is no loss of data during
fragmentation. If a relation is decomposed into fragments, then each data item
must appear in at least one fragment.
b) Reconstruction: This rule ensures preservation of functional dependencies.
It should be possible to define a relational operation that will reconstruct the
relation from its fragments.

c) Disjointness: A data item that appears in a fragment should not appear in

any other fragment. However, a typical fragmentation called vertical
fragmentation is an exception to this rule. In vertical fragmentation the primary
key attributes must be repeated to allow reconstruction of original relation.
This rule ensures minimization of data redundancy.
What are the different types of fragmentation?
There are two main types of fragmentation: horizontal and vertical. Horizontal
fragments, as the name suggests are subsets of tuples and vertical fragments are
subsets of attributes (refer to Figure 4). There are also two other types of
fragmentation: mixed, and derived–a type of horizontal fragmentation, are just
introduced. A detailed discussion on them is beyond the scope of this unit.

(a) Horizontal Fragmentation

(b) Vertical Fragmentation

Figure 4: Horizontal and Vertical Fragmentation

Horizontal Fragmentation
Horizontal fragmentation groups together the tuples in a relation that are collectively
used by the important transactions. A horizontal fragment is produced by specifying a
WHERE clause condition that performs a restriction on the tuples in the relation. It
can also be defined using the Selection operation of the relational algebra.
83
Structured Query Example:
Language and
Transaction Management
Let us illustrate horizontal fragmentation with the help of an example.

DEPOSIT (branch-code, account-number, customer-name, balance)

A sample relation instance of the relation DEPOSIT is shown in Figure 5.

Branch-code Account number Customer name Balance

1101 3050 Suresh 5000
1101 2260 Swami 3360
1102 1170 Swami 2050
1102 4020 Khan 10000
1101 1550 Khan 620
1102 4080 Khan 1123
1102 6390 Khan 7500

Figure 5: Sample DEPOSIT relation

Mathematically a fragment may be defined as a selection on the global relation R. The

reconstruction of the relation R can be obtained by taking the union of all fragments.

So let us decompose the table in Figure 5 into horizontal fragments. Let us do these
fragments on the branch-code as 1101 and 1102

DEPOSIT1 obtained by selection on branch-code as 1101

Branch-code Account number Customer name Balance
1101 3050 Suresh 5000
1101 2260 Swami 3360
1101 1550 Khan 620
DEPOSIT2 obtained by selection on branch- code as 1102
Branch-code Account number Customer name Balance
1102 1770 Swami 2050
1102 4020 Khan 10000
1102 4080 Khan 1123
1102 6390 Khan 7500

Figure 6: Horizontal fragmentation of relation DEPOSIT

The two fragments can be defined in relational algebra as:

DEPOSIT1 = σ branch-code= 1101 (DEPOSIT)

DEPOSIT2 = σ branch-code= 1102 (DEPOSIT)

These two fragments are shown in Figure 6. Fragment 1 can be stored in the branch
whose code is 1101 while the second fragment can be stored at branch 1102.

In our example, the fragments are disjoint. However, by changing the selection
predicates used to construct the fragments; we may have overlapping horizontal
fragments. This is a form of data replication.

Vertical Fragmentation
Vertical fragmentation groups together only those attributes in a relation that are used
jointly by several important transactions. A vertical fragment is defined using the
Projection operation of the relational algebra. In its most simple form, vertical

84
fragmentation is the same as that of decomposition. In general, a relation can be Distributed and Client
Server Databases
constructed on taking Natural join of all vertical fragments.

More generally, vertical fragmentation is accomplished by adding a special attribute

called a tuple-number to the scheme R. A tuple-number is a physical or logical
address for a tuple. Since each tuple in R must have a unique address, the tuple-
number attribute is a key to the new fragments obtained (please refer to Figure 7).

Branch-code Account number Customer name Balance Tuple-number

1101 3050 Suresh 5000 1
1101 2260 Swami 3360 2
1102 1170 Swami 2050 3
1102 4020 Khan 10000 4
1101 1550 Khan 620 5
1102 4080 Khan 1123 6
1102 6390 Khan 7500 7

Figure 7: The relation DEPOSIT of figure 5 with tuple- numbers

This relation now can be decomposed into two fragments as: shows a vertical
decomposition of the scheme Deposit-scheme tuple number into:

DEPOSIT3 = ∏ (branch-code. customer-name, tuple-number) (DEPOSIT)

DEPOSIT4 = ∏ (account-number, balance, tuple-number) (DEPOSIT)

The example of Figure7 on this basis would become:

DEPOSIT3
Branch-code Customer-name Tuple-number
1101 Suresh 1
1101 Swami 2
1102 Swami 3
1102 Khan 4
1101 Khan 5
1102 Khan 6
1102 Khan 7
DEPOSIT4
Account number Balance Tuple-number
3050 5000 1
2260 3360 2
1170 2050 3
4020 10000 4
1550 620 5
4080 1123 6
6390 7500 7
Figure 8: Vertical fragmentation of relation DEPOSIT

How can we reconstruct the original relation from these two fragments? By taking
natural join of the two vertical fragments on tuple-number. The tuple number allows
direct retrieval of the tuples without the need for an index. Thus, this natural join may
be computed much more efficiently than typical natural join.
However, please note that as the tuple numbers are system generated, therefore they
should not be visible to general users. If users are given access to tuple-number, it
becomes impossible for the system to change tuple addresses.
85
Structured Query Mixed fragmentation
Language and
Transaction Management Sometimes, horizontal or vertical fragmentation of a database schema by itself is
insufficient to adequately distribute the data for some applications. Instead, mixed or
hybrid fragmentation is required. Mixed fragmentation consists of a horizontal
fragment that is vertically fragmented, or a vertical fragment that is then horizontally
fragmented.

Derived horizontal fragmentation

Some applications may involve a join of two or more relations. If the relations are
stored at different locations, there may be a significant overhead in processing the
join. In such cases, it may be more appropriate to ensure that the relations, or
fragments of relations, that are joined together are at the same location. We can
achieve this using derived horizontal fragmentation.
After going through the basis of concepts relating to distributed database systems, let
us sketch the process of design of distributed database systems.

A step-wise distributed database design methodology

Following is a step-wise methodology for distributed database design.

(1) Examine the nature of distribution. Find out whether an organisation needs to
have a database at each branch office, or in each city, or possibly at a regional
level. It has direct implication from the viewpoint of fragmentation. For
example, in case database is needed at each branch office, the relations may
fragment on the basis of branch number.
(2) Create a detailed global E-R diagram, if so needed and identify relations from
entities.
(3) Analyse the most important transactions in the system and identify where
horizontal or vertical fragmentation may be desirable and useful.
(4) Identify the relations that are not to be fragmented. Such relations will be
replicated everywhere. From the global ER diagram, remove the relations that
are not going to be fragmented.
(5) Examine the relations that are on one-side of a relationship and decide a
suitable fragmentation schema for these relations. Relations on the many-side
of a relationship may be the candidates for derived fragmentation.
(6) During the previous step, check for situations where either vertical or mixed
fragmentation would be needed, that is, where the transactions require access to
a subset of the attributes of a relation.

 Check Your Progress 2

1) What are the rules while fragmenting data?
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
2) What is Data Replication? What are its advantages & disadvantages?
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
…………………………………………………………………………………………….

86
 Distributed and Client
4.6 CLIENT SERVER DATABASES Server Databases

The concept behind the Client/Server systems is concurrent, cooperative processing. It

is an approach that presents a single systems view from a user's viewpoint. It involves
processing on multiple, interconnected machines. It provides coordination of activities
in a manner transparent to end-users. Remember, client-server database is distribution
of activities into clients and a server. It may have a centralised or distributed database
system at the server backend. It is primarily a very popular commercial database
implementation model.

4.6.1 Emergence of Client Server Architecture

Some of the pioneering work that was done by some of the relational database
vendors allowed the computing to be distributed on multiple computers on network
using contemporary technologies involving:

• Low Cost, High Performance PCs and Servers

• Graphical User Interfaces
• Open Systems
• Object-Orientation
• Workgroup Computing
• EDI and E-Mail
• Relational Databases
• Networking and Data Communication.

4.6.2 Need for Client Server Computing

Client/Server (C/S) architecture involves running the application on multiple
machines in which each machine with its component software handles only a part of
the job. Client machine is basically a PC or a workstation that provides presentation
services and the appropriate computing, connectivity and interfaces while the server
machine provides database services, connectivity and computing services to multiple
users. Both client machines and server machines are connected to the same network.
As the number of users grows, client machines can be added to the network while as
the load on the database server increases more servers can be connected through the
network. Thus, client-server combination is a scalable combination. Server machines
are more powerful machines database services to multiple client requests.

The client-server systems are connected though the network. This network need not
only be the Local Area Network (LAN). It can also be the Wide Area Network
(WAN) across multiple cities. The client and server machines communicate through
standard application program interfaces (called API), and remote procedure calls
(RPC). The language through which RDBMS based C/S environment communicate is
the structured query language (SQL).

4.6.3 Structure of Client Server Systems

In client/server architecture, clients represent users who need services while servers
provide services. Both client and server are a combination of hardware and software.
Servers are separate logical objects that communicate with clients over a network to
perform tasks together. A client makes a request for a service and receives a reply to
that request. A server receives and processes a request, and sends back the required
response. The client/server systems may contain two different types of architecture -
2-Tier and 3-Tier Client/Server Architectures
Every client/server application contains three functional units:
• Presentation logic which provides the human/machine interaction (the user
interface). The presentation layer handles input from the keyboard, mouse, or
87
Structured Query other input devices and provides output in the form of screen displays. For
Language and
Transaction Management
example, the ATM machine of a bank provides such interfaces.

• Business logic is the functionality provided to an application program. For

example, software that enables a customer to request to operate his/her balance
on his/her account with the bank is business logic. It includes rules for
withdrawal, for minimum balance etc. It is often called business logic because it
contains the business rules that drive a given enterprise.

• The bottom layer provides the generalized services needed by the other layers
including file services, print services, communications services and database
services. One example of such a service may be to provide the records of
customer accounts.

These functional units can reside on either the client or on one or more servers in the
application:

Figure 9: A client-server system

In general two popular client/server systems are:

• 2-Tier client Server Models

• 3-Tier client server Model

2-Tier Client/Server Models

Initial two-tier (client/server) applications were developed to access large databases
available on the server side and incorporated the rules used to manipulate the data
with the user interface into the client application. The primary task of the server was
simply to process as many requests for data storage and retrieval as possible.

88
Two-tier client/server provides the user system interface usually on the desktop Distributed and Client
Server Databases
environment to its users. The database management services are usually on the server
that is a more powerful machine and services many clients. Thus, 2-Tier client-server
architecture splits the processing between the user system interface environment and
the database management server environment. The database management server also
provides stored procedures and triggers. There are a number of software vendors that
provide tools to simplify the development of applications for the two-tier client/server
architecture.

In 2-tier client/server applications, the business logic is put inside the user interface on
the client or within the database on the server in the form of stored procedures. This
results in division of the business logic between the client and server. File servers and
database servers with stored procedures are examples of 2-tier architecture.

The two-tier client/server architecture is a good solution for distributed computing.

Please note the use of words distributed computing and not distributed databases. A 2-
tier client server system may have a centralised database management system or
distributed database system at the server or servers. A client group of clients on a
LAN can consist of a dozen to 100 people interacting simultaneously. A client server
system does have a number of limitations. When the number of users exceeds 100,
performance begins to deteriorate. This limitation is a result of the server maintaining
a connection via communication messages with each client, even when no work is
being done.

A second limitation of the two-tier architecture is that implementation of processing

management services using vendor proprietary database procedures restricts flexibility
and choice of DBMS for applications. The implementations of the two-tier
architecture provides limited flexibility in moving program functionality from one
server to another without manually regenerating procedural code.

Figure 10: 2-tier and 3 tier client server systems

89
Structured Query Some of the major functions performed by the client of a two-tier application are:
Language and
Transaction Management
present a user interface, gather and process user input, perform the requested
processing, report the status of the request.

This sequence of commands can be repeated as many times as necessary. Because

servers provide only access to the data, the client uses its local resources to perform
most of the processing. The client application must contain information about where
the data resides and how it is organised in the server database. Once the data has been
retrieved, the client is responsible for formatting and displaying it to the user.

3-tier architecture

As the number of clients increases the server would be filled with the client requests.
Also, because much of the processing logic was tied to applications, changes in
business rules lead to expensive and time-consuming alterations to source code.
Although the ease and flexibility of two-tier architecture tools continue to drive many
small-scale business applications, the need for faster data access and rapid
developmental and maintenance timelines has persuaded systems developers to seek
out a new way of creating distributed applications.

The three-tier architecture emerged to overcome the limitations of the two tier
architecture (also referred to as the multi-tier architecture). In the three-tier
architecture, a middle tier was added between the user system interface client
environment and the database management server environment. The middle tier may
consist of transaction processing monitors, message servers, or application servers.

The middle-tier can perform queuing, application execution, and database staging. For
example, on a middle tier that provides queuing, the client can deliver its request to
the middle layer and simply gets disconnected because the middle tier will access the
data and return the answer to the client. In addition the middle layer adds scheduling
and prioritisation for various tasks that are currently being performed.

The three-tier client/server architecture has improved performance for client groups
with a large number of users (in the thousands) and improves flexibility when
compared to the two-tier approach. Flexibility is in terms of simply moving an
application on to different computers in three-tier architecture. It has become as
simple as “drag and drop” tool. Recently, mainframes have found a new use as servers
in three-tier architectures:

In 3-tier client/server applications, the business logic resides in the middle tier,
separate from the data and user interface. In this way, processes can be managed and
deployed separately from the user interface and the database. Also, 3-tier systems can
integrate data from multiple sources.

4.6.4 Advantages of Client Server Computing

Client/Server systems have following advantages:

• They provide low cost and user-friendly environment

• They offer expandability that ensures that the performance degradation is not so
much with increased load.
• They allow connectivity with the heterogeneous machines deals with real time
data feeders like ATMs, Numerical machines.
• They allow enforcement of database management activities including security,
performance, backup, integrity to be a part of the database server machine. Thus,
avoiding the requirement to write a large number of redundant piece of code
dealing with database field validation and referential integrity.

90
• One major advantage of the client/server model is that by allowing multiple users Distributed and Client
Server Databases
to simultaneously access the same application data, updates from one computer
are instantly made available to all computers that had access to the server.

Client/server systems can be used to develop highly complex multi-user database

applications being handled by any mainframe computer.

Since PCs can be used as clients, the application can be connected to the spreadsheets
and other applications through Dynamic Data Exchange (DDE) and Object Linking
and Embedding (OLE). If the load on database machine grows, the same application
can be run on a slightly upgraded machine provided it offers the same version of
RDBMSs.

A more detailed discussion on these topics is beyond the scope of this unit. You can
refer to further readings for more details.

 Check your Progress 3

1) What are the advantages of Client/Server Computing?

………………………………………………………………………………….
………………………………………………………………………………….
2) Describe the Architecture of Client/Server system.

………………………………………………………………………….
………………………………………………………………………….

4.7 SUMMARY

A distributed database system consists of a collection of sites, each of which

maintains a local database system. Each site is able to process local transactions–those
transactions that access data only at that single site. In addition, a site may participate
in the execution of global transactions–those transactions that access data at several
sites. The execution of global transactions requires communication among the sites.

There are several reasons for building distributed database systems, including sharing
of data, reliability and availability, and speed of query processing. However, along
with these advantages come several disadvantages, including software development
cost, greater potential for bugs, and increased processing overheads. The primary
disadvantage of distributed database systems is the added complexity required to
ensure proper co-ordination among the sites.

There are several issues involved in storing a relation in the distributed database,
including replication and fragmentation. It is essential that the system minimise the
degree to which a user needs to be aware of how a relation is stored.

Companies that have moved out of the mainframe system to Client/Server architecture
have found three major advantages:

• Client/Server technology is more flexible and responsive to user needs

• A significant reduction in data processing costs
• An increase in business competitiveness as the market edge turns towards
merchandising.

91
Structured Query
Language and
Transaction Management
4.8 SOLUTIONS/ANSWERS

Check Your Progress 1

1) The advantages of DDBMS are:

• The primary advantages of distributed database systems is the ability to

share and access data in a reliable and efficient manner. A user at one site
may be able to access data that is available at another site.
• Each site is able to retain a degree of control over data stored locally.
• It reflects organisational structure
• If distributed over several locations then improved availability of DBMS.
A failure of a communication link making some sites inaccessible does
not make the entire system inoperable. The ability of most of the systems
to continue to operate despite failure of onesite results in increased
availability, which is crucial for database systems used for real-time
applications.
• Speed of database access may be better than that achievable from a remote
centralised database. Parallel computation allows faster processing of a
user’s query.
• It costs much less to create a system of smaller computers with lower
equivalent a single large computer. It is much easier to expand. New
sites can be added to the network without affecting the operations of other
sites.

2)

Global Transactions Local Transactions

Involves multiple sites Can be performed locally
Uses data communication links Performed locally
Takes longer to execute, in general Faster
Performance depends on global Performance is governed by local
schema objects available schema objects like local indexes
Just 20-25 % of total Most transactions are local

Check Your Progress 2

1) Fragmentation cannot be carried out haphazardly. There are three rules that must
be followed during fragmentation.

a) Completeness: If a relation R is decomposed into fragments R1, R2,.. Rn,

each data item that can be found in R must appear in at least one fragment.
b) Reconstruction: It must be possible to define a relational operational that will
reconstruct the relation R from the fragments.
c) Disjointness: If a data item d appears in fragment R1 then it should not appear
in any other fragment. Vertical fragmentation is the exception to this rule,
where primary key attributes must be repeated to allow reconstruction.

2) If relation R is replicated a copy of relation R is stored in two or more sites.

There are a number of advantages and disadvantages to replication.

92
 Availability: If one of the sites containing relation R fails, then the relation R Distributed and Client
Server Databases
may found in another site.
Increased parallelism: In cases where the majority of access to the relation R
results in only the reading of the relation, several sites can process queries
involving R in parallel.
Increasing overhead on update: The system must ensure that all replicas of a
relation R are consistent, otherwise erroneous computations may result. This
implies that whenever R is updated, this update must be propagated to all sites
containing replicas, resulting in increased overheads.

Check Your Progress 3

1) Advantages of client/server computing are as follows:
• C/S computing caters to low-cost and user-friendly environment.
• It offers expandability.
• It ensures that the performance degradation is not so much with increased
load.
• It allows connectivity with the heterogeneous machines and also with real
time data feeders.
• It allows server enforced security, performance, backup, integrity to be a
part of the database machine avoiding the requirement to write a large
number of redundant piece of code dealing with database field validation
and referential integrity, allows multiple users to simultaneously access
the same application data.
• Updates from one computer are instantly made available to all computers
that had access to the server.
• It can be used to develop highly complex multi-user database applications
being handled by any mainframe computer. If the load on database
machine grows, the same application can be run on a slightly upgraded
machine.

2) 2-Tier client/Server Models

With two-tier client/server, the user system interface is usually located in the
user’s desktop environment and the database management services are usually
in a server. Processing management is spilt between the user system interface
environment and the database management server environment. The database
management server provides stored procedures and triggers. In 2-tier
client/server applications, the business logic is buried inside the user interface
on the client or
within the database on the server in the form of stored procedures.
Alternatively, the business logic can be divided between client and server.
3-tier architecture
The three-tier architecture (also referred to as the multi-tier architecture) emerged to
overcome the limitations of the two-tier architecture. In the three-tier architecture, a
middle tier was added between the user system interface client environment and the
database management server environment. There are a variety of ways of
implementing this middle tier, such as transaction processing monitors, message
servers, or application servers. The middle tier can perform queuing, application
execution, and database staging. In addition the middle layer adds scheduling and
prioritization for work in progress. The three-tier client/server architecture has been
shown to improve performance for groups with a large number of users (in the
thousands) and improves flexibility when compared to the two-tier approach.

93
Structured Query In 3-tier client/server application, the business logic resides in the middle tier, separate
Language and
Transaction Management
from the data and user interface. In this way, processes can be managed and deployed
separately from the user interface and the database. Also, 3-tier systems can integrate
data from multiple sources.

94