Y MAIN3

AIRLINE RESERVATION SYSTEM
The mini project report submitted in partial fulfillment

Of the requirements for 3rdyear(II-semester) of B.Tech Degree
IN
COMPUTER SCIENCE AND ENGINEERING
By
VELAMALA PRAVEEN
YELURI CHAITANYA
VALLABHAJOSYULA ADITYA
VARSHA SUSAN MATHEW
690752113
690752124
690752108
690752112
Under the esteemed guidance of

Ms.A.Kavitha
Asst Professor
Department of C.S.E
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

ANIL NEERUKONDA INSTITUTE OF TECHNOLOGY & SCIENCES
SANGIVALASA, VISAKHAPATNAM 530003
2010-2011
ANIL NEERUKONDA INSTITUTE OF

TECHNOLOGY & SCIENCES
(Affiliated to Andhra University)
SANGIVALASA, VISAKHAPATNAM 530003
2010-2011
CERTIFICATE
This is to certify that the project work done entitled AIRLINE RESERVATION
SYSTEM is a bonified work carried out by YELURI CHAITANYA as a part of
B.Tech 3rd Year 2nd Semester of Computer Science and Engineering of Andhra University
during the Year 2010-2011.
Project Guide
Head of the Department
Ms.A.Kavitha
Dr .Suresh Chandra Satapathy
ACKNOWLEDGEMENT
We are grateful to our guide Ms A.Kavitha, for her unfailing, fostering and
personal involvement, which motivated us to a great extent.
We would like to thank the Head of our Department, Dr. Suresh Chandra
Satapathy, for permitting us in laying the first stone for success. We would also like
to thank him for the lab facilities and other resources he provided us and constant
support he gave us.
We express our deep sense of gratitude to our esteemed institute Anil

Neerukonda Institute of Technology and Sciences, which has provided us an
opportunity to full fill the most cherished desire to reach our goal.
VELAMALA PRAVEEN
YELURI CHAITANYA
VALLABHAJOSYULA ADITYA
VARSHA SUSAN MATHEW
690752113
690752124
690752108
690752112
INDEX
1. ABSTRACT
2. SYSTEM REQUIREMENT SPECIFICATION
2.1
2.2
2.3
2.4
2.5
05
06
INTRODUCTION
FUNCTIONAL REQUIREMENTS
NON FUNCTIONAL REQUIREMENTS
HARDWARE REQUIREMENT SPECIFICATION
SOFTWARE REQUIREMENT SPECIFICATION
06
06
07
07
07
3. CONCEPTUAL SCHEMA DESIGN

3.1
3.2
3.3
3.4
3.5
08
ENTITY RELATIONSHIP MODEL

IDENTIFICATION OF ENTITIES
IDENTIFICATION OF RELATIONS
COMPLETE E-R DIAGRAM
CREATE TABLES FOR ER DIAGRAM
08
13
15
15
16
4. LOGICAL SCHEMA GENERATION
18
4.1 REPRESENTATION OF ENTITIES INTO TABLES
18
5. SCHEMA REFINEMENT
5.1
5.2
5.3
5.4
5.5
20
INTRODUCTION
FUNCTIONAL DEPENDENCIES
NORMALISATION
PROPERTIES OF NORMALIZATION
NORMALIZATION OF TABLES
20
20
21
22
23
6. RELATIONAL MODEL
28
6.1 IDENTIFING ENTITIES

6.2 IDENTIFING ATTRIBUTES
6.3 IDENTIFING CONSTRAINTS OVER RELATIONS
6.4 INTRODUCTION TO ORACLE DATABASE
6.5 ENTITIES TO TABLES
6.6 ESTABLISHING RELATIONSHIPS

6.7 COMPLETE ER DIAGRAM
7. SNAPSHOTS OF TABLES WITH VALID DATA ENTRIES

8. QUERIES
9. CONCLUSION
10. BIBILOGRAPHY
28
28
29
31
32
37
39
40
43
48
49
ABSTRACT
This project is aimed at developing database for airline reservation system to maintain
flights details. The main objective of this project is to render efficient services to the clients and
to reduce the vulnerabilities in the database.
This offers flexibility to the clients in handling transactions on records in a database
system. The manual handling of record is time consuming and highly prone to errors. The main
purpose of this project is to design a database for maintaining air line reservations.
The project deals with identification of flights to help the passengers to retrieve
information about flights and can reserve tickets for specific flights. The database is maintained
with flights identified by their ID along with availability and other required information for
customers and it also maintains the reservation details of passengers reserved for each flight.
2. SYSTEM REQUIREMENT SPECIFICATION

2.1 INTRODUCTION:
While hardware systems vary widely in features and capabilities, certain common
features are necessary for operating system software for working on this platform.
2.1.1 Purpose:
In general, the passenger asks for information about the flight that he would like
to travel. To cope up with rapid developments in data maintaining systems it is essentially
recommended in maintaining the database of complete flights details under the aid of a Database
management system. By using this system we can provide full-fledged information to passenger
about a flight.
2.1.2 Scope:
The main motive in designing this product is to provide a friendly environment
for company and passenger to maintain data in a more efficient manner. The product is mainly
composed of two groups: clients and users (passengers). The agent has full access to the system.
By using this system an agent can access any random passenger information in more efficient
manner. The user can retrieve any details about specific flights at any instance of time.
2.2 FUNCTIONAL REQUIREMENTS:

To maintain complete details about flights and passengers it is essential to maintain the
complete information in the database. Airline Reservation System requires the following data for
maintaining complete information about the flights.
1. Each flights is identified uniquely flights-id, its departure time, date and availability.
Every flight entity contains the flights information like name, date of travel, source,
destination, departure time and fare.
2. The details of each passenger who reserves a seat in a particular flight are maintained in
another table uniquely identified by passenger ID. The reservation entity contains the
passenger information like name, address, email ID, phno along with the specific flight
information he reserved for.
2.3 NON-FUNCTIONAL REQUIREMENTS:

2.3.1 Usability:
The product could be used by two categories of people: agents and customer.
2.3.2 Reliability:
Customers can perform the operations without any constraints regarding the outcome of
the operation. Even the updating transactions provide reliability to the company. The system as a
whole is highly reliable.
2.3.3 Supportability:
All kinds of information which can be supported in the database are supported by the
system and the application supports the utilities of the system over which it is deployed.
2.4 HARDWARE REQUIREMENT SPECIFICATION:

Processor
Pentium 2 or above
RAM
128MB or above
Hard Disk Space
2 GB or above
Floppy Drive
1.44 MB
CD ROM
32X or above
Key board
101 Keys keyboard
Display
VGA Monitor
2.5 SOFTWARE REQUREMENT SPECIFICATION:

Operating System
Windows 2000, Windows XP, Windows NT
Database Support
SQL server 2000 or above
3. CONCEPTUAL DATABASE DESIGN

The information gathered in the requirements analysis step is used to develop a

high-level description of the data to be stored in the database, along with the constraints that are
known to hold over this data. This step is often carried out using the ER-model, or similar highleveldatamodel.
3.1 ENTITY RELATIONSHIP MODEL:

An entity-relationship model (ERM) is an abstract and conceptual representation
of data. Entity-relationship modeling is a database modeling method, used to produce a type
of conceptual schema or semantic data model of a system, often a relational database, and its
requirements in a down fashion. Diagrams created by this process are called entity-relationship
diagrams, ER diagrams, or ERDs.
3.1.1 ENTITIES:
An entity may be defined as a thing which is recognized as being capable of an
independent existence and which can be uniquely identified. An entity is an abstraction from the
complexities of some domain. When we speak of an entity we normally speak of some aspect of
the real world which can be distinguished from other aspects of the real world.
An entity may be a physical object such as a house or a car, an event such as a
house sale or a car service, or a concept such as a customer transaction or order. Although the
term entity is the one most commonly used, following Chen we should really distinguish
between an entity and an entity-type. An entity-type is a category. An entity, strictly speaking, is
an instance of a given entity-type. There are usually many instances of an entity-type. Because
the term entity-type is somewhat cumbersome, most people tend to use the term entity as a
synonym for this term.
Entities can be thought of as nouns. Examples: a computer, an employee, a song, a
mathematical theorem.
REPRESENTATION:
Entities are drawn as rectangles
EXAMPLE:
Or
COMPANY
JOB
3.1.2 ATTRIBUTES:
An entity is described using a set of attributes. All entities in a given entity set have the
same attributes; this is known as similar type. Our choice of attributes reflects the level of detail
at which we wish to represent information about entities. For example, company entity set could
use company_id, company_name for each company.
For each attribute associated with an entity set, we must identify a domain of possible
values. For example domain associated with attribute company_name of company might be a set
of 20-character strings similarly company_id might be integer.
Further, for each entity set, we choose a key. A key is a minimal set of attributes whose
values uniquely identify an entity in the set, generally called as candidate key, there could be
more than one candidate key, if so we designate one of them as primary key. A primary key is
key with which we can identify a tuple uniquely.
TYPES:
Simple Attribute:
A normal attribute defining an entity
Representation:
Name
Multivalued attribute:
Attribute consisting of multiple values.
Example:
Address
Derived attribute:
An attribute which is derived from other attribute.
3.1.3 RELATIONS:
A relationship captures how two or more entities are related to one another. Relationships
can be thought of as verbs, linking two or more nouns. Examples: owns relationship between a
company and a computer, supervises relationship between an employee and a department,

a performs relationship between an artist and a song, a proved relationship between a
mathematician and a theorem.
Entity-relationship diagrams don't show single entities or single instances of relations.
Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The
collection of all songs in a database is an entity set. The eaten relationship between a child and
her lunch is a single relationship. The set of all such child-lunch relationships in a database is a
relationship set. In other words, a relationship set corresponds to a relation in mathematics, while
a relationship corresponds to a member of the relation.
EXAMPLE:
COMPANY
OFFERS
JOB
3.1.4 CARDINALITY:
In the relational model, tables can be related as any of: many-to-many, many-toone (rev. one-to-many), or one-to-one. This is said to be the cardinality of a given table in
relation to another.
For example, considering a database designed to keep track of hospital records. Such a database
could have many tables like:
a Doctor table full of doctor information
a Patient table with patient information
And a Department table with an entry for each department of the hospital.
In that model:
There is a many-to-many relationship between the records in the doctor table and
records in the patient table (Doctors have many patients, and a patient could have several
doctors);
A one-to-many relation between the department table and the doctor table (each doctor
works for one department, but one department could have many doctors).
10
One-to-one relationship is mostly used to split a table in two in order to optimize access or
limit the visibility of some information. In the hospital example, such a relationship could be
used to keep apart doctor's personal or administrative information.
EXAMPLE:
The above ER diagram shows the participation of entities flights and passengers (reservation
chart) in a relationship set reserves.
An entity in flights is associated with any number of entities in reservation chart and an entity in
reservation chart is associated with any number of entities in flights.
3.1.5 Participation Constraints:

The participation of an entity set E in a relationship set r is said to be total if every
entity in E participates at least in one relationship in R. If only some entities in E participate in
relationships in R, the participation of entity set E in relationship R is said to be partial. For
example, we expect every passenger entity to be related to at least one flight through the reserves
relationship. Therefore, the participation of the reserves in the relationship set passenger is total.
Symbols used in ER diagram are:
11
12
3.2 IDENTIFICATION OF ENTITIES:

For construction of database for airline reservation system we need two tables
1. Flights
2. Reservation chart
3.2.1 ATTRIBUTES TO ENTITIES:

1. FLIGHTS:
13
Column Name
Flight id
Dept time
Date
Count
Source
Destination
Flight Name
Duration
Arriv time
N.o.s
Fare
Constraint
Primary key
1
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
Data type
NUMBER
TIME
DATE
NUMBER
CHAR(15)
CHAR(15)
CHAR(15)
TIME
TIME
NUMBER
NUMBER
The flight table stores details of a flight i.e. flight_id , arrival time , departure time , availability
of seats and no.of seats filled.
2. RESERVATION CHART:
Column name
Cname
Address
Email id
Ph no
Seat no
Constraint
NOT NULL
NOT NULL
UNIQUE
UNIQUE
Date type
CHAR(30)
CHAR(30)
CHAR(30)
NUMBER(12)
NUMBER(3)
14
Flight id
Dept time
Date
Fare
Source
Destination
Arrv time
FOREIGN KEY
(refers to FLIGHTS)
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NUMBER(3)
TIME
DATE
NUMBER(10)
CHAR(20)
CHAR(20)
TIME
The reservation chart stores all the information of a customer who has successfully finished their
transaction. It takes the required details from the customer and stores the details like seat no
,email id ,ph no customer name ,fare etc.
We use this table mainly to store the information of a passenger travelling on a particular flight
along with its duration.
3.3 IDENTIFICATION OF RELATIONSHIPS:

The relationship between the entities is many to many. An entity in FLIGHTS is associated with any
number of entities in RESERVATION CHART and an entity in RESERVATION CHART is

associated with any number of entities in FLIGHTS.
3.4 COMPLETE ENTITY RELATIONSHIP DIAGRAM:
15
3.5 CREATE TABLE STATEMENTS FOR ENTITIES:
SQL> create table flights(fid number(4),

time1 varchar2(5),
d_date date,
count number(4),
source char(10),
dest char(10),
fname char(10),
duration varchar2(5),
time2 varchar2(5),
NOS number(4) ,
fare number(7,2),
16
constraint pp primary key(fid,time1,d_date,count));
SQL> create table reservation chart(cname char(10),

addr varchar2(10),
em_id varchar2(20),
ph_no number(12),
seatno number(5),
fid number(4),
time1 varchar2(5),
d_date date,
fare number(7,2),
source char(10),
dest char(10),
time2 varcha2(5),
17
constraintppl primary key(seatno,fid,time1,d_date));
4. LOGICAL SCHEMA DESIGN

4.1 REPRESENTATION OF ENTITIES INTO TABLES:
For construction of database for airline reservation system we need two entities.
1.Flights
2.Reservation chart
FLIGHTS :
Column Name
Flight id
Dept time
Date
Count
Source
Destination
Flight Name
Duration
Arriv time
N.o.s
Fare
Constraint
Primary key
1
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
Data type
NUMBER
TIME
DATE
NUMBER
CHAR(15)
CHAR(15)
CHAR(15)
TIME
TIME
NUMBER
NUMBER
18
The flight table stores details of a flight i.e. flight_id , arrival time , departure time , availability
of seats and no.of seats filled.
RESERVATION CHART :
Column name
Cname
Address
Email id
Ph no
Seat no
Flight id
Dept time
Date
Fare
Source
Destination
Arrv time
Constraint
NOT NULL
NOT NULL
UNIQUE
UNIQUE
Date type
CHAR(30)
CHAR(30)
CHAR(30)
NUMBER(12)
NUMBER(3)
FOREIGN KEY
NUMBER(3)
(refers to FLIGHTS) TIME
DATE
NOT NULL
NUMBER(10)
NOT NULL
CHAR(20)
NOT NULL
CHAR(20)
NOT NULL
TIME
The reservation chart stores all the information of a customer who has successfully finished their
transaction. It takes the required details from the customer and stores the details like seat no,
email id ,ph no customer name ,fare etc.
19
5. SCHEMA REFINEMENT
5.1 INTRODUCTION:
The fourth step in database design is to analyze the collection of relations in our
relational database schema to identify potential problems like dependencies, anomalies, and to
refine it. In contrast to the requirements analysis and conceptual design steps, which are
essentially subjective, schema refinement can be guided by some elegant and powerful theory.
We discuss the theory of normalizing relations restructuring them to ensure some desirable
properties.
5.1.1 Problems Caused by Redundancy:

Storing the same information redundancy, that is, in more than one place within a
database, can lead to several problems: Redundant Storage: Some information is stored
repeatedly. Update anomalies: If one copy of such repeated data is updated, an inconsistency is
created unless all copies are similarly updated. Insertion anomalies: It may not be possible to
store some information unless some other information is stored as well. Deletion anomalies: It
may not be possible to delete some information without losing some other information as well.
5.2 FUNCTIONAL DEPENDENCIES:

A functional dependency (FD) is a kind of IC that generalizes the concept of a key. Let R
be a relation schema and let X and Y be nonempty sets of attributes in R. We say that an instance
r of R satisfies the FD X!Y 1if the following holds for every pair of tuples t1 and t2 in r.
USE OF DECOMPOSITION:
Intuitively, redundancy arises when a relational schema forces an association between
attributes that is not natural. Functional dependencies (and, for that matter, other ICs) can be
used to identify such situations and to suggest refinements to the schema. The essential idea is
that many problems arising from redundancy can be addressed by replacing a relation with a
20
collection of smaller relations. Each of the smaller relations contains a (strict) subset of the
attributes of the original relation. We refer to this process as decomposition of the larger relation
into the smaller relations.
5.3 NORMALIZATION:
Normalization theory is the most important concept of RDBMS. It is basically a
formalization of simple ideas. It has practical applications in area of database design. The
primary goal of normalization is focusing on time dependent properties and to remove redundant
information.
When there is more than one file in a data system, the problem of organizing the data
becomes much more complex. It is helpful to have data model of how the data is organized into
files and how these files are related to one another. The model includes a list of fields in each
record type, the keys used to access the records and how records in one file are related to records
in other file. Normalization is a systematic, reversible transformation if data model to remove
logic structures, which the non-key data item are functionally dependent on their keys.
Normalization is done in series of steps, each of which leaves the model in specific
normal form. Each normal form includes all constraints of the previous normal forms; there are
several levels if normal form, Boyce-codd normal form and Fifth Normal form.
5.3.1 First Normal Form:

First Normal form is achieved when record is designed to be a fixed length. This is
accomplished by removing the repeated group and creating a separate file or relation containing
repeated group. The original records are inter-related by a common data item.
A relation R is in First Normal Form if and only if all the underlying domains contain
atomic values. To go from First Normal Form to Second Normal Form, the analyst must remove
any partially dependent attributes from their first normal form entity and create a new entity.
After that, copy a part of the identifier of original entity into new entity.
5.3.2 Second Normal Form:

Second Normal form is achieved when record is in first normal form and each item in the
record is fully dependent on the primary key for identification. To achieve 2NF, every data item
21
in the record that is not dependent on the primary key of the record should be removed and used
to form a separate relation.
A relation R is in Second Normal Form if and only if it is in first normal form and every
non key attribute is fully dependent on primary key. To go from 2NF to 3NF, the analyst must
remove all independent attributes and put them in an entity of their own. Note that this new
entity will now need a unique identifier and is subjected to previous steps.
5.3.2 Third Normal Form:

Third Normal form is achieved when transitive dependencies are removed from a record. Third
Normal Form removes the transitive dependencies
by splitting the relation into separate
relations.
A relation R is in 3NF if and only if it is in 2NF and no non key attribute is functionally
dependent on another non key attribute. Third normal form is often reached in practice by
inspection in a single step. This level of normalization is widely accepted as initial target for a
design which eliminates redundancy.
5.3.3 Boyce Codd Normal Form:

Boyce Codd Normal Form requires that there be non-trivial functional dependencies of attributes
on something other than a superset of a candidate key.
5.3.4 Fourth Normal Form:

The 4NF requires that be no non-trivial multivalued dependencies of attribute sets on something
other than a superset of a candidate key.
A table is said to be in 4NF if and only if it is in BCNF and multi valued dependencies
are functional dependencies. The 4NF removes unwanted data structures: multi valued
dependencies.
5.3.5 Fifth Normal Form:

Fifth Normal form requires that there are no nontrivial join dependencies that do not follow the
key constraints.
A table is said to be in the 5NF if and only if it is in 4NF and every join dependency in it
is implied by candidate keys.
22
5.4 PROPERTIES OF NORMALIZED RELATIONS:

Ideal relations after normalization should have the following properties so that the
problems mentioned above do not occur for relations in the (ideal) normalized form:
1. No data value should be duplicated in different rows unnecessarily.
2. A value must be specified (and required) for every attribute in a row.
3. Each relation should be self-contained. In other words, if a row from a relation is deleted,
important information should not be accidentally lost.
4. When a row is added to a relation, other relations in the database should not be affected.
5. A value of an attribute in a tuple may be changed independent of other tuples in the relation
and other relations.
5.5 NORMALIZATION OF TABLES:

FLIGHTS TABLE:
FI
D
101
DTIME DATE COUN

T
09:00
12/2
1
SOUC
E
V
DES
T
H
FNAME DUR
A
Kingfish 2
ATIME
FARE DIST
0700
NO
S
540
1200
600
101
14:00
12/2
Kingfish
1200
540
1200
600
101
09:00
13/2
Kingfish
0700
540
1200
600
102
09:00
12/2
Kingfish
0700
540
1200
600
102
14:00
12/2
Kingfish
1200
540
1200
600
102
09:00
13/2
Kingfish
0700
540
1200
600
103
10:00
14/2
Indian
0800
600
1300
600
103
14:00
15/2
Indian
1200
600
1300
600
Here the primary key is combination of FID+D.TIME+DATE

Here the repeated values are
For a particular fid - source
destination
duration
f.name
23
no. of seats
fare
distance
These columns are repeated.
So decrease redundancy let us decompose the table into two tables.
The table is in first normal form
Since there is no row contains two or more values and it is a relation.
Decompose to two different tables namely FLIGHTS and FLIGHT DETAILS.
FLIGHTS:
FID
DATE
DEPT.TIME
ARRL.TIM
E
COUNT
101
101
101
102
102
102
103
103
103
12/2
12/2
13/2
12/2
12/2
13/2
12/2
12/2
13/2
9:00
14:00
9:00
9:00
14:00
9:00
9:00
14:00
9:00
7:00
12:00
7:00
7:00
12:00
7:00
7:00
12:00
7:00
1
2
4
100
205
120
300
100
420
AVILABLE
(No. of
seats_count)
539
538
536
440
335
420
300
500
180
In this table primary key is: FID+DATE+DEPT.TIME

FLIGHT DETAILS:
FID
F.NAME
FAIR
101
Kingfishe
r
Kngfisher
Indian
102
103
SOURC
E
DESTINATION
DURATION
DISTANCE
1200
NO.
OF
SEATS
540
2 hrs
600
1200
1300
540
600
H
H
V
V
2 hrs
2 hrs
600
600
In the above table some data like source, destination, distance repeated so once again decompose
flight details table.
24
FLIGHT DETAILS:
FID
101
102
103
F.NAME
Kingfish
Kingfish
Indian
FAIR
1200
1200
1300
NO. OF SEATS
540
540
600
ROUTE ID
191
192
192
FID primary key
ROUTE DETAILS:
RID
191
SOURCE
V
H
DESTINATION
H
V
DISTANCE
600
600
RID primary key

Here the fid given to any flight according to its name,sorce,destination.
Now we have tables
(1)FLIGHTS
(2)FLIGHT DETAILS
(3)ROUTE DETAILS
Here we join tables
FLIGHTS
FLIGHT DETAILS Using Fid
We join tables
FLIGHT DETAILS
ROUTE DETAILS
Using Rid
All these tables in first normal form (No row has two values)
25
Now we can get any value from FLIGHTS

Using primary key (FID+DATE+D.TIME)
So table FLIGHTS is in second normal form.
Similarly we can get all values from FLIGHT DETAILS using fid and all ROUTE DETAILS
using Rid
So the tables FLIGHTS
FLIGHT DETAILS
ROUTE DETAILS
tables are in second normal form.
THIRD NORMAL FORM:
All the tables are in third normal form since we cant get any data from tables without using a key
attribute.
Means we cant get any Non key attribute.
JOINS:
To join the tables
FLIGHTS and FLIGHT DETAILS
We use Fid[Since its a common column]
To join the tables
FLIGHT DETAILS and ROUTE DETALS
We use Rid[Since its a common column]
Now the second table is reservation table.
C
Addr Emid Ph
name
no
St Fid D
no
time
Date Fare Sourc
Dest
A
time
If we know fid we can get source, destination, and fare so we remove source, destination, fare
from table.
26
If we know fid, date, d.time we can get arrival time so we can remove arrival time.
Now the table contains the columns as follows
RESERVATION TABLE:
Fid Date
D.tim
e
Sea Custome
t no r name
Address
Email id
Pn no
101
101
12-2-2010
12-2-2010
9:00
9:00
1
2
Praveen
krishna
Vizag
Saluru
8008544171
9814314398
101
12-2-2010
9:00
narayana
Nellore
101
102
13-2-2010
12-2-2010
14:00
9:00
1
1
Koti
Yeshwanth
Gunture
kanool
102
12-2-2010
9:00
Chaitanya
Vijayaw
103
104
13-2-2010
12-2-2010
14:00
9:00
3
1
Aditya
Varsha
Vijayaw
Vizag
Paveen@hotmail
krish@gmail.co
m
vanky@ymail.co
m
koti@lvrby.com
yashu@gmail.co
m
chitu@gmail.co
m
aditya@gmail.co
uma@gmail.com
Here the primary key is:
9814314389
8034334380
8008544800
9826485332
9846751233
9855674321
FID+DATE+DTIME+SEATNO
No data is repeated is a particular row and its satisfies relation so its in first normal form.
The reservation table in second normal form
1) It satisfies first normal form
2) We can get all row details by using the primary key (FID+DATE+D.TIME+SEATNO)
Here FID,DATE,D.TIME,SEATNO are not unique itself.
27
The combination of these four columns is unique.

The reservation table in third normal form
1) It satisfies second normal form
2) We can get any non key attribute by using a non key attribute.
We cant get details by using customer name (since its not unique)
We cant get details by using address (since its not unique)
We cant get details by using email id (since its not unique)
We cant get details by using phone number (since its not unique)
So the reservation table in third normal form
6. RELATIONAL MODEL
The main construct for representing data in the relational model is a relation. A relation
consists of relational schema and relational instance. The relational instance is a table, and
relation schema describes the column heads for the table.
An instance of relation is a set of tuples also called records.
6.1 IDENTIFING ENTITIES:

ENTITY:
An entity is an object in the real world that is distinguishable from other objects. A
collection of similar entities is called an entity set.
ENTITIES IN AIRLINE RESRVATION DATABASE
1.
2.
3.
4.
FLIGHTS
FLIGHT DETAILS
ROUTE DETAILS
RESERVATION
6.2 IDENTIFING ATTRIBUTES:

ATTRIBUTE:
A description data in terms of a data model is called a SCHEMA. In the relational model
the schema for a relation specifies its name, the name of each field called ATTRIBUTE.
28
An entity is described using a set of attributes. For each attribute associated with an entity
set, we must identify a domain of possible values. Domain of field is essentially the type of that
field.
ATTRIBUTES FOR ENTITIES IN AIRLINE RESERVATION DATABASE

FLIGHTS (FID :INTEGER, DATE : DATE, DEPT.TIME : TIMEARRL.TIME: TIME,
COUNT: INTEGER, AVAILABLE: INTEGER)
For instance the field named FID has a domain named INTEGER.
The set of values associated with domain INTEGER is the set of all integer values.
FLIGHT DETAILS(FID : INTEGER, FNAME : STRING, FARE : INTEGER
N.S : INTEGER, RID : INTEGER)
For instance the field named FNAME has a domain named STRING.
The set of values associated with domain STRING is the set of all character values.
ROUTE DETAILS(RID : INTEGER, SOURCE : STRING, DESTINATION : STRING
DISTANCE : INTEGER)
For instance the field named SOURCE has a domain named STRING.
RESERVATION(FID : INTEGER, DATE : DATE,DEPT TIME : TIME,
SEAT NO : INTEGER, PASNGR NAME : STRING,
ADDRESS : STRING, EMAIL ID : STRING,
PH NO : INTEGER)
For instance the field named PASS NAME has a domain named STRING.
6.3 IDENTIFING CONSTRAINTS OVER RELATION:

29
An integrity constraint is a condition specified on a database schema and restricts the data
that can be stored in an instance of the database.
A key constraint is statement that a certain minimal subset of the fields of a relation is a
unique identifier for a tuple.
A set of fields that uniquely identifies a tuple according to a key constraint is called a
candidate key.There can be at most one primary key among the candidate keys.
CONSTRAINTS FOR THE TABLE:

1.FLIGHTS:
COLUMN NAME
FID
DATE
DEPT TIME
ARRL TIME
COUNT
AVAILABLE
CONSTRAINT
DOMAIN
INTEGER
DATE
VARCHAR2
VARCHAR2
INTEGER
INTEGER
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
PRIMARY KEY: Combination of FID, DATE, DEPT TIME

The combination of above candidate keys uniquely identifies FLIGHTS in the database.
2.FLIGHT DETAILS:
COLUMN NAME
FID
FNAME
FARE
NO OF SEATS
ROUTE ID
CONSTRAINT
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
NOT NULL
DOMAIN
INTEGER
CHAR
INTEGER
INTEGER
INTEGER
PRIMARY KEY: FID

30
FOREIGN KEY: RID(References ROUTES)
3.ROUTE DETAILS:
COLUMN NAME
ROUTE ID
SOURCE
DESTINATION
DISTANCE
CONSTRAINT
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
DOMAIN
INTEGER
CHAR
CHAR
INTEGER
CONSTRAINT
DOMAIN
INTEGER
DATE
VARCHAR2
INTEGER
CHAR
CHAR
CHAR
INTEGER
PRIMARY KEY: RID

4.RESERVATION:
COLUMN NAME
FID
DATE
DEPT TIME
SEAT NO
PASSENGER NAME
ADDRESS
EMAIL ID
PHONE NUMBER
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
NOT NULL
PRIMARY KEY: FID,DATE,DEPT TIME,SEATNO
6.4 INTRODUCTION TO ORACLE DATABASE
The Oracle Database (commonly referred to as Oracle RDBMS or simply as Oracle) is

a relational database management system (RDBMS) produced and marketed by Oracle
Corporation. As of 2009, Oracle remains a major presence in database computing. Larry Ellison
and his friends and former co-workers Bob Miner and Ed Oates started the consultancy Software
Development Laboratories (SDL) in 1977. SDL developed the original version of the Oracle
software. The name Oracle comes from the code-name of a CIA-funded project Ellison had
worked on while previously employed by Ampex.
31
Oracle database conventions refer to defined groups of object ownership (generally

associated with a "username") as schemas. Most Oracle database installations traditionally came
with a deAfter the installation process has set up the sample tables, the user can log into the
database with the username Scott and the password tiger. The name of the SCOTT schema
originated with Bruce Scott, one of the first employees at Oracle (then Software Development
Laboratories), who had a cat named Tiger.
6.5 ENTITIES TO TABLES: (after Normalization)

1. FLIGHTS:
Sql>Create table FLIGHTS ( FID number(5),

B_DATE date,
32
D_TIME varchar2(6),
A_TIME varchar2(6),
COUNT number(4),
AVAL
number(4),
Constraint primary key(FID,B_DATE,D_TIME));
2. FLIGHT DETAILS:
Sql>Create table fllightdet( FID number(4) primary key,

FNAME char(10),
FARE number(7,2),
NOSEATS number(4),
33
RID number(4)
Constraint adjv foreign key(RID) references routes(RID));
3. ROUTEDETAILS(ROUTES):
Sql> Create table ROUTES (RID number(4) primary key,

SOURCE char(10),
DEST char(10),
34
DIST number(5));
4. RESERVATION(PASSRESV):
Sql> Create table PASSRESV ( FID number(4),

B_DATE date,
D_TIME varchar2(5),
ST_NO
number(4),
35
A_TIME varchar2(5),
ADRS varchar2(10),
EM_ID varchar2(10),
PH_NO number(12),
Primary key(FID,B_DATE,D-TIME,ST_NO));
TABLES (after normalization):

FLIGHTS :
Column Name
FID
B_DATE
D_TIME
A_TIME
COUNT
AVAL
Constraint
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
Data Type
NUMBER
DATE
DATE
TIME
NUMBER
NUMBER
PASSENGERS (PASSRESV):
Column Name
FID
B_DATE
D_TIME
ST_NO
CNAME
ADRS
EM_ID
PH_NO
Constraint
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
NOT NULL
Data Type
NUMBER
DATE
VARCHAR
NUMBER
CHAR
VARCHAR
VARCHAR
NUMBER
FLIGHTDETAILS (FLIGHTDET):
36
Column Name
Constraint
Data Type
FID
FNAME
FARE
NOS
RID
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NUMBER
CHAR
NUMBER
NUMBER
NUMBER
ROUTE DETAILS (ROUTES):

Column Name
Constraint
Data Type
RID
SOURCE
DEST
DIST
PRIMARY KEY
NOT NULL
NOT NULL
NOT NULL
NUMBER
CHAR
CHAR
NUMBER
6.6 ESTABLISHING REALTIONSHIPS BETWEEN ENTITIES:

FLIGHTS-PASSRESV RELATION SHIP:
The relation between FLIGHTS and PASSRESV is many to many relationship. An entity
in FLIGHTS is associated with any number of entities in PASSRESV and an entity in
PASSRESV is associated with any number of entities in FLIGHTS.
37
FLIGHTDETAILS-ROUTES:
The participation of entity flightdetails is total participation on entity routes. Also each
flight can have at most one route id.
FLIGHTS-FLIGHTDETAILS:
The relationship between FLIGHTS and FLIGHTDETAILS is many to one. An entity in
FLIGHTS associated with at most one entity FLIGHT DETAILS. An entity in
FLIGHTDETAILS however can be associated with any number of entities in FLIGHTS.
38
6.7 COMPLETE ENITITY RELATION SHIP DIAGRAM:
39
40
7.SNAPSHOT OF TABLES WITH VALID DATA

ENTRIES
1.FLIGHTS
SQL> SELECT * FROM FLIGHTS;
FID
B_DATE
D_TIME
A_TIME
COUNT
AVAL
101
12-FEB-10
09:00
07:00
001
539
101
12-FEB-10
14:00
12:00
002
538
101
13-FEB-10
09:00
07:00
004
536
102
12-FEB-10
09:00
07:00
100
440
102
12-FEB-10
14:00
12:00
205
305
102
13-FEB-10
09:00
07:00
120
420
103
12-FEB-10
09:00
07:00
120
420
103
12-FEB-10
14:00
12:00
100
500
103
13-FEB-10
09:00
07:00
420
180
9 rows selected.
2.FLIGHT DETAILS(FLIGHTDET):
SQL> SELECT * FROM FLIGHTDET;
FID
FNAME
FARE
NOS
RID
101
KINGFISHER
1200
540
191
102
KINGFISHER
1200
540
192
103
SPICE JET
1300
600
192
104
SPICE JET
1300
600
191
4 rows selected.
41
3.ROUTE DETAILS(ROUTES)
SQL> select * from routes;
RID
SOURCE
DEST
DIST
191
VIZAG
DELHI
1200
192
DELHI
VIZAG
1200
193
VIZAG
HYDERABAD
600
194
HYDERABAD
VIZAG
600
195
HYDERABAD
VIZAG
600
196
VIZAG
BOMBAY
1400
197
BOMBAY
VIZAG
1400
197
BOMBAY
DELHI
198
DELHI
BOMBAY
1600
199
VIZAG
BANGLORE
1000
200
BANGLORE
VIZAG
1000
1600
11 rows selected.
42
4.RESERVATION(PASSRESV)
SQL> SELECT * FROM PASSRESV;
FID
B_DATE
D_TIM
101
12-FEB-10
09:00
aditya.v
karshed
101
12-FEB-10
09:00
praveen
srikakulam paveen113
101
12-FEB-10
09:00
chaitanya vijayawada chaitu
9.1949E+11
101
13-FEB-10
14:00
mathus
9.1900E+11
102
12-FEB-10
09:00
ranjit
srikakulam Varanasi
9.1876E+11
102
12-FEB-10 09:00
suresh
vizag
suresh
9.1877E+11
103
13-FEB-10
manoj
vzm
manojp
9.1987E+11
14:00
ST_NO CNAME ADRS
vizag
EM_ID
aditya
varsha
PH_N0
9.1988E+11
9.1801E+11
7 rows selected.
43
8. QUERIES
1) SQL query to display the reservation details of a particular flight(101) on 12-feb-2010 at
9:00 am.
SQL> select * from passresv where fid=101 and b_date='12-feb-10' and d_time='9:00';
FID
B_DATE
D_TIM
ST_NO CNAME ADRS
EM_ID
101
12-FEB-10
09:00
aditya.v
karshed
101
12-FEB-10
09:00
praveen
srikakulam paveen113
101
12-FEB-10
09:00
chaitanya vijayawada chaitu
PH_N0
aditya
9.1988E+11
9.1801E+11
9.1949E+11
2) SQL query to retrieve flight details which are run on 13-feb-2010 from Delhi to vizag.
SQL> select f.fid,fname,b_date,d_time,a_time,aval,count,fare from flights f,flightdet d where
f.fid=d.fid and f.b_date='13-feb-2010' and d.rid=(select rid from routes where source='DELHI'
and dest='VIZAG');
FID
FNAME
102
103
B_DATE
D_TIM
A_TIM
KINGFISHER 13-FEB-10
9:00
7:00
420
120
1200
SPICE
9:00
7:00
180
420
1300
13-FEB-10
AVAL
COUNT
FARE
3) SQL query to retrieve the route details those have flights on 13-feb-2010?
SQL> select * from routes where rid in(select distinct rid from flightdet where
fid in (select fid from flights where b_date='12-FEB-10'));
RID
SOURCE
DEST
DIST
191
VIZAG
DELHI
1200
192
DELHI
VIZAG
1200
44
4) Procedure to update the columns count and available in flights table when
fid,departuretime,date and no.of seat reservations are given?
SQL> create or replace procedure reserve(p_id in flights.fid%type,p_date in flights.b_date
%type,p_time in flights.d_time%type,p_n in flights.count%type)
2 is
3 begin
4 update flights set count=count+p_n where fid=p_id and b_date=p_date and
d_time=p_time;
5 update flights set aval=aval-p_n where fid=p_id and b_date=p_date and
d_time=p_time;
6 commit;
7* end;
SQL> /
Procedure created.
SQL> select * from flights where fid=101 and b_date='12-feb-10' and d_time='9:00';
FID
B_DATE
D_TIM
101
12-FEB-10
9:00
A_TIM
COUNT
7:00
AVAL
534
SQL> execute reserve(101,'12-feb-10','9:00',15);

PL/SQL procedure successfully completed.
SQL> select * from flights where fid=101 and b_date='12-feb-10' and d_time='9:00';
FID
B_DATE
101
12-FEB-10
D_TIM
A_TIM
COUNT
AVAL
9:00
7:00
22
519
45
5) SQL query to retrieve details of routes those have flight services.

SQL> select source, dest from routes;
SOURCE
DEST
VIZAG
DELHI
DELHI
VIZAG
VIZAG
HYDERABAD
HYDERABAD
VIZAG
HYDERABAD
VIZAG
VIZAG
BOMBAY
BOMBAY
VIZAG
BOMBAY
DELHI
DELHI
BOMBAY
VIZAG
BANGLORE
BANGLORE
VIZAG
11 rows selected.
6) SQL query to retrieve details about customer who travels in kingfisher airways on
12-feb-2010 at 9:00 am from vizag to Delhi whose seat number is 02.
SQL> select * from passresv where b_date='12-feb-10' and d_time='9:00' and
st_no=2 and fid=(select fid from flightdet where fname='KINGFISHER' and rid=
(select rid from routes where source='VIZAG' and dest='DELHI'));
FID
B_DATE
D_TIM
101
12-FEB-10
9:00
ST_NO
2
CNAME
praveen
ADRS
srikakulam
EM_ID
PH_NO
paveen113 9.1801E+11
46
7) SQL Query to retrieve the no of seats filled for a particular flight.

SQL> select fid,b_date,d_time,count as filled from flights;
FID
B_DATE
D_TIM
FILLED
101
12-FEB-10
09:00
22
101
12-FEB-10
14:00
101
13-FEB-10
09:00
102
12-FEB-10
09:00
100
102
12-FEB-10
14:00
205
102
13-FEB-10
09:00
120
103
12-FEB-10
09:00
120
103
12-FEB-10
14:00
100
103
13-FEB-10
09:00
420
9 rows selected.
8) Trigger to initialize count to zero.
SQL> Create or Replace trigger init_count
2 Before insert on FLGHTS
3 Declare
4 Count number;
5 Begin
6 Count:=0;
7* End;
SQL> /
Trigger created.
47
9) SQL query to retrieve flight details which have fare less than 2000 and running between vizag
to Delhi on 13-FEB-2010.
SQL>Select * from flights where B_date=13-FEB-2010 and fid in(select fid from flightdet
where fare<1250 and rid in(select rid from routes where source=vizag and dest=delhi));
FID
B_DATE
101
13-FEB-10
D_TIME
A_TIME
COUNT
AVAL
09:00
07:00
004
536
10) SQL query to retrieve availability for a flight running between vizag to delhi on 13-FEB-2010 at
9:00 am.
SQL> Select aval from flights where B_date=13-FEB-2010 and D_time=9:00 and fid=( select
fid from flightdet where rid in(select rid from routes where source=vizag and dest=delhi));
AVAL
536
9. CONCLUSION
48
The Airline Reservation System is developed using ORACLE DATABASE and fully
meets the objectives of the system which it has been developed. The system has reached a steady
state where all bugs have been eliminated. The system is operated at a high level of efficiency
and all the agents and passengers associated with the system understand its advantage. The
system solves the problem. It was intended to solve as requirement specification.
10. BIBLIOGRAPHY
49
1. Database Management Systems-Third Edition (IE) - Raghu Ramakrishnan, Johannes

Gerkhe, McGraw Hill Edition.
2. Database System concepts-Fifth Edition (IE) -Abraham Silberschatz, Henry F.Korth,
S.Sudarshan, McGraw Hill Edition.
3. Fundamentals of Database Systems-Fifth Edition (IE) RamezElamasri,
ShamkanthB.Navathe, Pearson Education.
4. Oracle 9i, The Complete Reference Oracle Press - Kevin Loney, George Koch, Tata
McGraw Hill Edition.
50

Y MAIN3

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Y MAIN3

Enviado por

Direitos autorais:

Formatos disponíveis

AIRLINE RESERVATION SYSTEM

The mini project report submitted in partial fulfillment

Under the esteemed guidance of

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

AIRLINE RESERVATION SYSTEM

ANIL NEERUKONDA INSTITUTE OF

Head of the Department

Dr .Suresh Chandra Satapathy

AIRLINE RESERVATION SYSTEM

We express our deep sense of gratitude to our esteemed institute Anil

AIRLINE RESERVATION SYSTEM

3. CONCEPTUAL SCHEMA DESIGN

ENTITY RELATIONSHIP MODEL

4. LOGICAL SCHEMA GENERATION

4.1 REPRESENTATION OF ENTITIES INTO TABLES

6.1 IDENTIFING ENTITIES

6.6 ESTABLISHING RELATIONSHIPS

7. SNAPSHOTS OF TABLES WITH VALID DATA ENTRIES

2. SYSTEM REQUIREMENT SPECIFICATION

2.2 FUNCTIONAL REQUIREMENTS:

2.3 NON-FUNCTIONAL REQUIREMENTS:

2.4 HARDWARE REQUIREMENT SPECIFICATION:

Hard Disk Space

101 Keys keyboard

2.5 SOFTWARE REQUREMENT SPECIFICATION:

Windows 2000, Windows XP, Windows NT

SQL server 2000 or above

3. CONCEPTUAL DATABASE DESIGN

The information gathered in the requirements analysis step is used to develop a

3.1 ENTITY RELATIONSHIP MODEL:

AIRLINE RESERVATION SYSTEM

company and a computer, supervises relationship between an employee and a department,

a Doctor table full of doctor information

a Patient table with patient information

AIRLINE RESERVATION SYSTEM

3.1.5 Participation Constraints:

Symbols used in ER diagram are:

AIRLINE RESERVATION SYSTEM

AIRLINE RESERVATION SYSTEM

3.2 IDENTIFICATION OF ENTITIES:

3.2.1 ATTRIBUTES TO ENTITIES:

AIRLINE RESERVATION SYSTEM

3.3 IDENTIFICATION OF RELATIONSHIPS:

number of entities in RESERVATION CHART and an entity in RESERVATION CHART is

3.4 COMPLETE ENTITY RELATIONSHIP DIAGRAM:

AIRLINE RESERVATION SYSTEM

3.5 CREATE TABLE STATEMENTS FOR ENTITIES:

SQL> create table flights(fid number(4),

AIRLINE RESERVATION SYSTEM

constraint pp primary key(fid,time1,d_date,count));

SQL> create table reservation chart(cname char(10),

constraintppl primary key(seatno,fid,time1,d_date));

4. LOGICAL SCHEMA DESIGN

AIRLINE RESERVATION SYSTEM

AIRLINE RESERVATION SYSTEM

5.1.1 Problems Caused by Redundancy:

5.2 FUNCTIONAL DEPENDENCIES:

5.3.1 First Normal Form:

5.3.2 Second Normal Form:

5.3.2 Third Normal Form:

5.3.3 Boyce Codd Normal Form:

5.3.4 Fourth Normal Form:

5.3.5 Fifth Normal Form: