Chapter 4:

Interacting with Database

What is JDBC?
JDBC stands for Java Database Connectivity, which is a standard Java API for database-
independent connectivity between the Java programming language and a wide range of databases.
The JDBC library includes APIs for each of the tasks mentioned below that are commonly
associated with database usage.
• Making a connection to a database.
• Creating SQL or MySQL statements.
• Executing SQL or MySQL queries in the database.
• Viewing & Modifying the resulting records.
Fundamentally, JDBC is a specification that provides a complete set of interfaces that allows for
portable access to an underlying database. Java can be used to write different types of executables,
such as −
• Java Applications
• Java Applets
• Java Servlets
• Java ServerPages (JSPs)
• Enterprise JavaBeans (EJBs).
All of these different executables are able to use a JDBC driver to access a database, and take
advantage of the stored data.
JDBC provides the same capabilities as ODBC, allowing Java programs to contain database-
independent code.

Pre-Requisite
Before moving further, you need to have a good understanding of the following two subjects −
• Core JAVA Programming
• SQL or MySQL Database

JDBC Architecture
The JDBC API supports both two-tier and three-tier processing models for database access but in
general, JDBC Architecture consists of two layers −
• JDBC API: This provides the application-to-JDBC Manager connection.
• JDBC Driver API: This supports the JDBC Manager-to-Driver Connection.
The JDBC API uses a driver manager and database-specific drivers to provide transparent
connectivity to heterogeneous databases.
The JDBC driver manager ensures that the correct driver is used to access each data source. The
driver manager is capable of supporting multiple concurrent drivers connected to multiple
heterogeneous databases.
Following is the architectural diagram, which shows the location of the driver manager with respect
to the JDBC drivers and the Java application −
Common JDBC Components

The JDBC API provides the following interfaces and classes −

• DriverManager: This class manages a list of database drivers. Matches connection requests
from the java application with the proper database driver using communication sub protocol.
The first driver that recognizes a certain subprotocol under JDBC will be used to establish a
database Connection.
• Driver: This interface handles the communications with the database server. You will
interact directly with Driver objects very rarely. Instead, you use DriverManager objects,
which manages objects of this type. It also abstracts the details associated with working with
Driver objects.
• Connection: This interface with all methods for contacting a database. The connection
object represents communication context, i.e., all communication with database is through
connection object only.
• Statement: You use objects created from this interface to submit the SQL statements to the
database. Some derived interfaces accept parameters in addition to executing stored
procedures.
• ResultSet: These objects hold data retrieved from a database after you execute an SQL
query using Statement objects. It acts as an iterator to allow you to move through its data.
• SQLException: This class handles any errors that occur in a database application.

Difference between JDBC and ODBC

ODBC:
ODBC is a multidatabase API for programs that use SQL statements to access data. An ODBC-
based program can access heterogeneous databases without needing source code changes-one
program can retrieve and store content in different vendors' databases via the ODBC interface.
ODBC thus provides database-neutral delivery of both SQL and database content. Be aware,
however, that you must load ODBC driver software for each vendor's database you want to access.

JDBC:
JDBC is a collection of database access middleware drivers that provide Java programs with a call-
level SQL API. Java applets and applications can use the drivers' API to connect to databases, store
and retrieve database content and execute stored procedures, thus making JDBC a Java-enabled
delivery mechanism for SQL. JDBC is to Java programs what ODBC is to programs written in
languages other than Java. In fact, JDBC's design is based on ODBC's

SQL Syntax:
Structured Query Language (SQL) is a standardized language that allows you to perform operations
on a database, such as creating entries, reading content, updating content, and deleting entries.

SQL is supported by almost any database you will likely use, and it allows you to write database
code independently of the underlying database.
This chapter gives an overview of SQL, which is a prerequisite to understand JDBC concepts. After
going through this chapter, you will be able to Create, Create, Read, Update, and Delete (often
referred to as CRUD operations) data from a database.

Create Database
The CREATE DATABASE statement is used for creating a new database. The syntax is −
SQL> CREATE DATABASE DATABASE_NAME;

Example
The following SQL statement creates a Database named EMP −
SQL> CREATE DATABASE EMP;

Drop Database
The DROP DATABASE statement is used for deleting an existing database. The syntax is −
SQL> DROP DATABASE DATABASE_NAME;

Note: To create or drop a database you should have administrator privilege on your database server.
Be careful, deleting a database would loss all the data stored in the database.

Create Table
The CREATE TABLE statement is used for creating a new table. The syntax is −
SQL> CREATE TABLE table_name
(
column_name column_data_type,
column_name column_data_type,
column_name column_data_type
...
);
Example
The following SQL statement creates a table named Employees with four columns −
SQL> CREATE TABLE Employees
(
id INT NOT NULL,
age INT NOT NULL,
first VARCHAR(255),
last VARCHAR(255),
PRIMARY KEY ( id )
);

Drop Table
The DROP TABLE statement is used for deleting an existing table. The syntax is −
SQL> DROP TABLE table_name;

Example
The following SQL statement deletes a table named Employees −
SQL> DROP TABLE Employees;

INSERT Data
The syntax for INSERT, looks similar to the following, where column1, column2, and so on
represents the new data to appear in the respective columns −
SQL> INSERT INTO table_name VALUES (column1, column2, ...);

Example
The following SQL INSERT statement inserts a new row in the Employees database created earlier
−
SQL> INSERT INTO Employees VALUES (100, 18, 'Zara', 'Ali');

SELECT Data
The SELECT statement is used to retrieve data from a database. The syntax for SELECT is −
SQL> SELECT column_name, column_name, ...
FROM table_name
WHERE conditions;

The WHERE clause can use the comparison operators such as =, !=, <, >, <=,and >=, as well as the
BETWEEN and LIKE operators.

Example
The following SQL statement selects the age, first and last columns from the Employees table,
where id column is 100 −
SQL> SELECT first, last, age
FROM Employees
WHERE id = 100;

The following SQL statement selects the age, first and last columns from the Employees table
where first column contains Zara −
SQL> SELECT first, last, age
FROM Employees
WHERE first LIKE '%Zara%';

UPDATE Data
The UPDATE statement is used to update data. The syntax for UPDATE is −
SQL> UPDATE table_name
SET column_name = value, column_name = value, ...
WHERE conditions;

The WHERE clause can use the comparison operators such as =, !=, <, >, <=,and >=, as well as the
BETWEEN and LIKE operators.

Example
The following SQL UPDATE statement changes the age column of the employee whose id is 100 −
SQL> UPDATE Employees SET age=20 WHERE id=100;

DELETE Data
The DELETE statement is used to delete data from tables. The syntax for DELETE is −
SQL> DELETE FROM table_name WHERE conditions;

The WHERE clause can use the comparison operators such as =, !=, <, >, <=,and >=, as well as the
BETWEEN and LIKE operators.

Example
The following SQL DELETE statement deletes the record of the employee whose id is 100 −
SQL> DELETE FROM Employees WHERE id=100;

What is JDBC Driver?

JDBC drivers implement the defined interfaces in the JDBC API, for interacting with your database
server.
For example, using JDBC drivers enable you to open database connections and to interact with it by
sending SQL or database commands then receiving results with Java.
The Java.sql package that ships with JDK, contains various classes with their behaviours defined
and their actual implementaions are done in third-party drivers. Third party vendors implements the
java.sql.Driver interface in their database driver.

JDBC Drivers Types

JDBC driver implementations vary because of the wide variety of operating systems and hardware
platforms in which Java operates. Sun has divided the implementation types into four categories,
Types 1, 2, 3, and 4, which is explained below −

Type 1: JDBC-ODBC Bridge Driver

In a Type 1 driver, a JDBC bridge is used to access ODBC drivers installed on each client machine.
Using ODBC, requires configuring on your system a Data Source Name (DSN) that represents the
target database.
When Java first came out, this was a useful driver because most databases only supported ODBC
access but now this type of driver is recommended only for experimental use or when no other
alternative is available.

The JDBC-ODBC Bridge that comes with JDK 1.2 is a good example of this kind of driver.

Type 2: JDBC-Native API

In a Type 2 driver, JDBC API calls are converted into native C/C++ API calls, which are unique to
the database. These drivers are typically provided by the database vendors and used in the same
manner as the JDBC-ODBC Bridge. The vendor-specific driver must be installed on each client
machine.
If we change the Database, we have to change the native API, as it is specific to a database and they
are mostly obsolete now, but you may realize some speed increase with a Type 2 driver, because it
eliminates ODBC's overhead.
The Oracle Call Interface (OCI) driver is an example of a Type 2 driver.

Type 3: JDBC-Net pure Java

In a Type 3 driver, a three-tier approach is used to access databases. The JDBC clients use standard
network sockets to communicate with a middleware application server. The socket information is
then translated by the middleware application server into the call format required by the DBMS, and
forwarded to the database server.
This kind of driver is extremely flexible, since it requires no code installed on the client and a single
driver can actually provide access to multiple databases

You can think of the application server as a JDBC "proxy," meaning that it
makes calls for the client application. As a result, you need some knowledge of
the application server's configuration in order to effectively use this driver type.
Your application server might use a Type 1, 2, or 4 driver to communicate with the database,
understanding the nuances will prove helpful.

Type 4: 100% Pure Java

In a Type 4 driver, a pure Java-based driver communicates directly with the vendor's database
through socket connection. This is the highest performance driver available for the database and is
usually provided by the vendor itself.
This kind of driver is extremely flexible, you don't need to install special software on the client or
server. Further, these drivers can be downloaded dynamically.
Which Driver should be Used?

If you are accessing one type of database, such as Oracle, Sybase, or IBM, the preferred driver type
is 4.
If your Java application is accessing multiple types of databases at the same time, type 3 is the
preferred driver.
Type 2 drivers are useful in situations, where a type 3 or type 4 driver is not available yet for your
database.
The type 1 driver is not considered a deployment-level driver, and is typically used for development
and testing purposes only.

Import JDBC Packages

The Import statements tell the Java compiler where to find the classes you reference in your code
and are placed at the very beginning of your source code.
To use the standard JDBC package, which allows you to select, insert, update, and delete data in
SQL tables, add the following imports to your source code −
import java.sql.* ; // for standard JDBC programs
import java.math.* ; // for BigDecimal and BigInteger support

Register JDBC Driver

You must register the driver in your program before you use it. Registering the driver is the process
by which the Oracle driver's class file is loaded into the memory, so it can be utilized as an
implementation of the JDBC interfaces.
You need to do this registration only once in your program. You can register a driver in one of two
ways.
Approach I - Class.forName()
The most common approach to register a driver is to use Java's Class.forName() method, to
dynamically load the driver's class file into memory, which automatically registers it. This method
is preferable because it allows you to make the driver registration configurable and portable.
The following example uses Class.forName( ) to register the Oracle driver −
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
}
catch(ClassNotFoundException ex) {
System.out.println("Error: unable to load driver class!");
System.exit(1);
}

You can use getInstance() method to work around noncompliant JVMs, but then you'll have to
code for two extra Exceptions as follows −
try {
Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
}
catch(ClassNotFoundException ex) {
System.out.println("Error: unable to load driver class!");
System.exit(1);
catch(IllegalAccessException ex) {
System.out.println("Error: access problem while loading!");
System.exit(2);
catch(InstantiationException ex) {
System.out.println("Error: unable to instantiate driver!");
System.exit(3);
}

Approach II - DriverManager.registerDriver()
The second approach you can use to register a driver, is to use the static
DriverManager.registerDriver() method.
You should use the registerDriver() method if you are using a non-JDK compliant JVM, such as the
one provided by Microsoft.
The following example uses registerDriver() to register the Oracle driver −
try {
Driver myDriver = new oracle.jdbc.driver.OracleDriver();
DriverManager.registerDriver( myDriver );
}
catch(ClassNotFoundException ex) {
System.out.println("Error: unable to load driver class!");
System.exit(1);
}

Database URL Formulation

After you've loaded the driver, you can establish a connection using the
DriverManager.getConnection() method. For easy reference, let me list the three overloaded
DriverManager.getConnection() methods −
• getConnection(String url)
• getConnection(String url, Properties prop)
• getConnection(String url, String user, String password)
Here each form requires a database URL. A database URL is an address that points to your
database.
Formulating a database URL is where most of the problems associated with establishing a
connection occurs.
Following table lists down the popular JDBC driver names and database URL.
RDBMS JDBC driver name URL format
MySQL com.mysql.jdbc.Driver jdbc:mysql://hostname/ databaseName
jdbc:oracle:thin:@hostname:port
ORACLE oracle.jdbc.driver.OracleDriver
Number:databaseName
COM.ibm.db2.jdbc.net.DB2Drive
DB2 jdbc:db2:hostname:port Number/databaseName
r
jdbc:sybase:Tds:hostname: port
Sybase com.sybase.jdbc.SybDriver
Number/databaseName
All the highlighted part in URL format is static and you need to change only the remaining part as
per your database setup.

Create Connection Object

We have listed down three forms of DriverManager.getConnection() method to create a
connection object.

Using a Database URL with a username and password

The most commonly used form of getConnection() requires you to pass a database URL, a
username, and a password:
Assuming you are using Oracle's thin driver, you'll specify a host:port:databaseName value for the
database portion of the URL.
If you have a host at TCP/IP address 192.0.0.1 with a host name of amrood, and your Oracle
listener is configured to listen on port 1521, and your database name is EMP, then complete
database URL would be −
jdbc:oracle:thin:@amrood:1521:EMP

Now you have to call getConnection() method with appropriate username and password to get a
Connection object as follows −
String URL = "jdbc:oracle:thin:@amrood:1521:EMP";
String USER = "username";
String PASS = "password"
Connection conn = DriverManager.getConnection(URL, USER, PASS);

Using Only a Database URL

A second form of the DriverManager.getConnection( ) method requires only a database URL −
DriverManager.getConnection(String url);

However, in this case, the database URL includes the username and password and has the following
general form −
jdbc:oracle:driver:username/password@database

So, the above connection can be created as follows −

String URL = "jdbc:oracle:thin:username/password@amrood:1521:EMP";
Connection conn = DriverManager.getConnection(URL);
Using a Database URL and a Properties Object
A third form of the DriverManager.getConnection( ) method requires a database URL and a
Properties object −
DriverManager.getConnection(String url, Properties info);

A Properties object holds a set of keyword-value pairs. It is used to pass driver properties to the
driver during a call to the getConnection() method.
To make the same connection made by the previous examples, use the following code −
import java.util.*;

String URL = "jdbc:oracle:thin:@amrood:1521:EMP";

Properties info = new Properties( );
info.put( "user", "username" );
info.put( "password", "password" );

Connection conn = DriverManager.getConnection(URL, info);

Closing JDBC Connections

At the end of your JDBC program, it is required explicitly to close all the connections to the
database to end each database session. However, if you forget, Java's garbage collector will close
the connection when it cleans up stale objects.
Relying on the garbage collection, especially in database programming, is a very poor programming
practice. You should make a habit of always closing the connection with the close() method
associated with connection object.
To ensure that a connection is closed, you could provide a 'finally' block in your code. A finally
block always executes, regardless of an exception occurs or not.
To close the above opened connection, you should call close() method as follows −
conn.close();

Explicitly closing a connection conserves DBMS resources, which will make your database
administrator happy.

Once a connection is obtained we can interact with the database. The

JDBC Statement, CallableStatement, and PreparedStatement interfaces
define the methods and properties that enable you to send SQL or PL/SQL
commands and receive data from your database.
They also define methods that help bridge data type differences between Java and SQL data types
used in a database.
The following table provides a summary of each interface's purpose to decide on the interface to
use.
Interfaces Recommended Use
Statement Use the for general-purpose access to your database. Useful when you are
using static SQL statements at runtime. The Statement interface cannot accept
 parameters.
Use the when you plan to use the SQL statements many times. The
PreparedStatement
PreparedStatement interface accepts input parameters at runtime.
Use the when you want to access the database stored procedures. The
CallableStatement
CallableStatement interface can also accept runtime input parameters.

The Statement Objects

Creating Statement Object
Before you can use a Statement object to execute a SQL statement, you need to create one using the
Connection object's createStatement( ) method, as in the following example −
Statement stmt = null;
try {
stmt = conn.createStatement( );
...
}
catch (SQLException e) {
...
}
finally {
...
}

Once you've created a Statement object, you can then use it to execute an SQL statement with one
of its three execute methods.
• boolean execute (String SQL): Returns a boolean value of true if a ResultSet object can be
retrieved; otherwise, it returns false. Use this method to execute SQL DDL statements or
when you need to use truly dynamic SQL.
• int executeUpdate (String SQL): Returns the number of rows affected by the execution of
the SQL statement. Use this method to execute SQL statements for which you expect to get
a number of rows affected - for example, an INSERT, UPDATE, or DELETE statement.
• ResultSet executeQuery (String SQL): Returns a ResultSet object. Use this method when
you expect to get a result set, as you would with a SELECT statement.

Closing Statement Object

Just as you close a Connection object to save database resources, for the same reason you should
also close the Statement object.
A simple call to the close() method will do the job. If you close the Connection object first, it will
close the Statement object as well. However, you should always explicitly close the Statement
object to ensure proper cleanup.
Statement stmt = null;
try {
stmt = conn.createStatement( );
...
}
catch (SQLException e) {
...
}
finally {
stmt.close();
}

For a better understanding, we suggest you to study the Statement - Example tutorial.
The PreparedStatement Objects
The PreparedStatement interface extends the Statement interface, which gives you added
functionality with a couple of advantages over a generic Statement object.
This statement gives you the flexibility of supplying arguments dynamically.

Creating PreparedStatement Object

PreparedStatement pstmt = null;
try {
String SQL = "Update Employees SET age = ? WHERE id = ?";
pstmt = conn.prepareStatement(SQL);
...
}
catch (SQLException e) {
...
}
finally {
...
}

All parameters in JDBC are represented by the ? symbol, which is known as the parameter marker.
You must supply values for every parameter before executing the SQL statement.
The setXXX() methods bind values to the parameters, where XXX represents the Java data type of
the value you wish to bind to the input parameter. If you forget to supply the values, you will
receive an SQLException.
Each parameter marker is referred by its ordinal position. The first marker represents position 1, the
next position 2, and so forth. This method differs from that of Java array indices, which starts at 0.
All of the Statement object's methods for interacting with the database (a) execute(), (b)
executeQuery(), and (c) executeUpdate() also work with the PreparedStatement object. However,
the methods are modified to use SQL statements that can input the parameters.

Closing PreparedStatement Object

Just as you close a Statement object, for the same reason you should also close the
PreparedStatement object.
A simple call to the close() method will do the job. If you close the Connection object first, it will
close the PreparedStatement object as well. However, you should always explicitly close the
PreparedStatement object to ensure proper cleanup.
PreparedStatement pstmt = null;
try {
String SQL = "Update Employees SET age = ? WHERE id = ?";
pstmt = conn.prepareStatement(SQL);
...
}
catch (SQLException e) {
...
}
finally {
pstmt.close();
}

For a better understanding, let us study Prepare - Example Code.

The CallableStatement Objects

Just as a Connection object creates the Statement and PreparedStatement objects, it also creates the
CallableStatement object, which would be used to execute a call to a database stored procedure.

Creating CallableStatement Object

Suppose, you need to execute the following Oracle stored procedure −
CREATE OR REPLACE PROCEDURE getEmpName
(EMP_ID IN NUMBER, EMP_FIRST OUT VARCHAR) AS
BEGIN
SELECT first INTO EMP_FIRST
FROM Employees
WHERE ID = EMP_ID;
END;

NOTE: Above stored procedure has been written for Oracle, but we are working with MySQL
database so, let us write same stored procedure for MySQL as follows to create it in EMP database
−
DELIMITER $$

DROP PROCEDURE IF EXISTS `EMP`.`getEmpName` $$

CREATE PROCEDURE `EMP`.`getEmpName`
(IN EMP_ID INT, OUT EMP_FIRST VARCHAR(255))
BEGIN
SELECT first INTO EMP_FIRST
FROM Employees
WHERE ID = EMP_ID;
END $$

DELIMITER ;

Three types of parameters exist: IN, OUT, and INOUT. The PreparedStatement object only uses the
IN parameter. The CallableStatement object can use all the three.
Here are the definitions of each −
Parameter Description
A parameter whose value is unknown when the SQL statement is created. You bind
IN
values to IN parameters with the setXXX() methods.
A parameter whose value is supplied by the SQL statement it returns. You retrieve
OUT
values from theOUT parameters with the getXXX() methods.
A parameter that provides both input and output values. You bind variables with the
INOUT
setXXX() methods and retrieve values with the getXXX() methods.
The following code snippet shows how to employ the Connection.prepareCall() method to
instantiate a CallableStatement object based on the preceding stored procedure −
CallableStatement cstmt = null;
try {
String SQL = "{call getEmpName (?, ?)}";
cstmt = conn.prepareCall (SQL);
...
}
catch (SQLException e) {
...
}
finally {
...
}

The String variable SQL, represents the stored procedure, with parameter placeholders.
Using the CallableStatement objects is much like using the PreparedStatement objects. You must
bind values to all the parameters before executing the statement, or you will receive an
SQLException.
If you have IN parameters, just follow the same rules and techniques that apply to a
PreparedStatement object; use the setXXX() method that corresponds to the Java data type you are
binding.
When you use OUT and INOUT parameters you must employ an additional CallableStatement
method, registerOutParameter(). The registerOutParameter() method binds the JDBC data type, to
the data type that the stored procedure is expected to return.
Once you call your stored procedure, you retrieve the value from the OUT parameter with the
appropriate getXXX() method. This method casts the retrieved value of SQL type to a Java data
type.

Closing CallableStatement Object

Just as you close other Statement object, for the same reason you should also close the
CallableStatement object.
A simple call to the close() method will do the job. If you close the Connection object first, it will
close the CallableStatement object as well. However, you should always explicitly close the
CallableStatement object to ensure proper cleanup.
CallableStatement cstmt = null;
try {
String SQL = "{call getEmpName (?, ?)}";
cstmt = conn.prepareCall (SQL);
...
}
catch (SQLException e) {
...
}
finally {
cstmt.close();
}

ResultSet:

The SQL statements that read data from a database query, return the data
in a result set. The SELECT statement is the standard way to select rows
from a database and view them in a result set. The java.sql.ResultSet
interface represents the result set of a database query.
A ResultSet object maintains a cursor that points to the current row in the result set. The term
"result set" refers to the row and column data contained in a ResultSet object.
The methods of the ResultSet interface can be broken down into three categories −
• Navigational methods: Used to move the cursor around.
• Get methods: Used to view the data in the columns of the current row being pointed by the
cursor.
• Update methods: Used to update the data in the columns of the current row. The updates
can then be updated in the underlying database as well.
The cursor is movable based on the properties of the ResultSet. These properties are designated
when the corresponding Statement that generates the ResultSet is created.
JDBC provides the following connection methods to create statements with desired ResultSet −
• createStatement(int RSType, int RSConcurrency);
• prepareStatement(String SQL, int RSType, int RSConcurrency);
• prepareCall(String sql, int RSType, int RSConcurrency);
The first argument indicates the type of a ResultSet object and the second argument is one of two
ResultSet constants for specifying whether a result set is read-only or updatable.

Type of ResultSet
The possible RSType are given below. If you do not specify any ResultSet type, you will
automatically get one that is TYPE_FORWARD_ONLY.
Type Description
ResultSet.TYPE_FORWA
The cursor can only move forward in the result set.
RD_ONLY
The cursor can scroll forward and backward, and the result set is not
ResultSet.TYPE_SCROLL
sensitive to changes made by others to the database that occur after
_INSENSITIVE
the result set was created.
ResultSet.TYPE_SCROLL The cursor can scroll forward and backward, and the result set is
_SENSITIVE. sensitive to changes made by others to the database that o

Two Tier Architecture:

The two-tier is based on Client Server architecture. The two-tier architecture is

like client server application. The direct communication takes place between
client and server. There is no intermediate between client and server. Because of
tight coupling a 2 tiered application will run faster. -
The above figure shows the architecture of two-tier. Here the direct
communication between client and server, there is no intermediate between
client and server.
Let’s take a look of real life example of Railway Reservation two-tier architecture:
Let’s consider that first Person is making Railway Reservation for Mumbai to Delhi by Mumbai
Express at Counter No. 1 and at same time second Person is also try to make Railway reservation of
Mumbai to Delhi from Counter No. 2
If staff from Counter No. 1 is searching for availability into system & at the same staff from
Counter No. 2 is also looking for availability of ticket for same day then in this case there is might
be good change of confusion and chaos occurs. There might be chance of lock the Railway
reservation that reserves the first.
But reservations can be making anywhere from the India, then how it is handled?
So here if there is difference of micro seconds for making reservation by staff from Counter No. 1
& 2 then second request is added into queue. So in this case the Staff is entering data to Client
Application and reservation request is sent to the database. The database sends back the
information/data to the client.
In this application the Staff user is an end user who is using Railway reservation application
software. He gives inputs to the application software and it sends requests to Server. So here both
Database and Server are incorporated with each other, so this technology is called as “Client-
Server Technology“.
The Two-tier architecture is divided into two parts:
1) Client Application (Client Tier)
2) Database (Data Tier)
On client application side the code is written for saving the data in the SQL server database. Client
sends the request to server and it process the request & send back with data. The main problem of
two tier architecture is the server cannot respond multiple request same time, as a result it cause a
data integrity issue.
Advantages:
1. Easy to maintain and modification is bit easy
2. Communication is faster
Disadvantages:
1. In two tier architecture application performance will be degrade upon increasing the users.
2. Cost-ineffective

Three-Tier Architecture:
Three-tier architecture typically comprise a presentation tier, a business or data access tier, and a
data tier. Three layers in the three tier architecture are as follows:
1) Client layer
2) Business layer
3) Data layer
1) Client layer:
It is also called as Presentation layer which contains UI part of our application. This layer is used
for the design purpose where data is presented to the user or input is taken from the user. For
example designing registration form which contains text box, label, button etc.
2) Business layer:
In this layer all business logic written like validation of data, calculations, data insertion etc. This
acts as a interface between Client layer and Data Access Layer. This layer is also called the
intermediary layer helps to make communication faster between client and data layer.
3) Data layer:
In this layer actual database is comes in the picture. Data Access Layer contains methods to connect
with database and to perform insert, update, delete, get data from database based on our input data.

Advantages
1. High performance, lightweight persistent objects
2. Scalability – Each tier can scale horizontally
3. Performance – Because the Presentation tier can cache requests, network utilization is
minimized, and the load is reduced on the Application and Data tiers.
4. High degree of flexibility in deployment platform and configuration
5. Better Re-use
6. Improve Data Integrity
7. Improved Security – Client is not direct access to database.
8. Easy to maintain and modification is bit easy, won’t affect other modules
9. In three tier architecture application performance is good.
Disadvantages
1. Increase Complexity/Effort