ymain3

65
“AIRLINE RESERVATION SYSTEM” The mini project report submitted in partial fulfillment Of the requirements for 3 rd year(II-semester) of B.Tech Degree IN COMPUTER SCIENCE AND ENGINEERING By VELAMALA PRAVEEN 690752113 YELURI CHAITANYA 690752124 VALLABHAJOSYULA ADITYA 690752108 VARSHA SUSAN MATHEW 690752112 Under the esteemed guidance of Ms.A.Kavitha Asst Professor Department of C.S.E AIRLINE RESERVATION SYSTEM 1

Upload: chaitanya-yeluri

Post on 15-Sep-2015

221 views

Category:

Documents


4 download

DESCRIPTION

Database Mini Project

TRANSCRIPT

AIRLINE RESERVATION SYSTEMThe mini project report submitted in partial fulfillmentOf the requirements for 3rdyear(II-semester) of B.Tech Degree

INCOMPUTER SCIENCE AND ENGINEERINGBy VELAMALA PRAVEEN 690752113 YELURI CHAITANYA 690752124 VALLABHAJOSYULA ADITYA 690752108 VARSHA SUSAN MATHEW 690752112Under the esteemed guidance of Ms.A.KavithaAsst ProfessorDepartment of C.S.E

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERINGANIL NEERUKONDA INSTITUTE OF TECHNOLOGY & SCIENCESSANGIVALASA, VISAKHAPATNAM 5300032010-2011

ANIL NEERUKONDA INSTITUTE OF TECHNOLOGY & SCIENCES(Affiliated to Andhra University)SANGIVALASA, VISAKHAPATNAM 5300032010-2011

CERTIFICATEThis 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 DepartmentMs.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 690752113 YELURI CHAITANYA 690752124 VALLABHAJOSYULA ADITYA 690752108 VARSHA SUSAN MATHEW 690752112

INDEX

1. ABSTRACT 05 2. SYSTEM REQUIREMENT SPECIFICATION 06 2.1 INTRODUCTION 062.2 FUNCTIONAL REQUIREMENTS 062.3 NON FUNCTIONAL REQUIREMENTS 072.4 HARDWARE REQUIREMENT SPECIFICATION 072.5 SOFTWARE REQUIREMENT SPECIFICATION 073. CONCEPTUAL SCHEMA DESIGN 08 3.1 ENTITY RELATIONSHIP MODEL 083.2 IDENTIFICATION OF ENTITIES 133.3 IDENTIFICATION OF RELATIONS 153.4 COMPLETE E-R DIAGRAM 153.5 CREATE TABLES FOR ER DIAGRAM 164. LOGICAL SCHEMA GENERATION 184.1 REPRESENTATION OF ENTITIES INTO TABLES 185. SCHEMA REFINEMENT 205.1 INTRODUCTION 20 5.2 FUNCTIONAL DEPENDENCIES 205.3 NORMALISATION 215.4 PROPERTIES OF NORMALIZATION 22 5.5 NORMALIZATION OF TABLES 236. RELATIONAL MODEL 286.1 IDENTIFING ENTITIES 28 6.2 IDENTIFING ATTRIBUTES 286.3 IDENTIFING CONSTRAINTS OVER RELATIONS` 29 6.4 INTRODUCTION TO ORACLE DATABASE 316.5 ENTITIES TO TABLES 326.6 ESTABLISHING RELATIONSHIPS 376.7 COMPLETE ER DIAGRAM 397. SNAPSHOTS OF TABLES WITH VALID DATA ENTRIES 408. QUERIES 439. CONCLUSION 4810. BIBILOGRAPHY 49

ABSTRACTThis 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 SPECIFICATION2.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 aboveRAM:128MB or aboveHard Disk Space:2 GB or aboveFloppy Drive : 1.44 MBCD ROM:32X or aboveKey board:101 Keys keyboardDisplay:VGA Monitor2.5 SOFTWARE REQUREMENT SPECIFICATION:Operating System:Windows 2000, Windows XP, Windows NTDatabase Support:SQL server 2000 or above

3. CONCEPTUAL DATABASE DESIGNThe 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 high-leveldatamodel. 3.1 ENTITY RELATIONSHIP MODEL:Anentity-relationship model(ERM) is an abstract and conceptual representation ofdata. Entity-relationship modeling is adatabase modelingmethod, used to produce a type ofconceptual schemaorsemantic data modelof a system, often arelational database, and its requirements in adown fashion. Diagrams created by this process are calledentity-relationship diagrams,ER diagrams, orERDs.3.1.1 ENTITIES: Anentitymay 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 asnouns. Examples: a computer, an employee, a song, a mathematical theorem.REPRESENTATION: Entities are drawn as rectanglesEXAMPLE:

JOB COMPANY Or

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

NameRepresentation: 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 asverbs, linking two or more nouns. Examples: ownsrelationship between a company and a computer, supervisesrelationship between an employee and a department, aperformsrelationship between an artist and a song, aprovedrelationship 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 particularsongis an entity. The collection of all songs in a database is an entity set. Theeatenrelationship 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 arelation in mathematics, while a relationship corresponds to a member of the relation.EXAMPLE:

OFFERS JOBCOMPANY

3.1.4 CARDINALITY:In the relational model, tables can be related as any of:many-to-many,many-to-one(rev.one-to-many), orone-to-one. This is said to be thecardinalityof 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: aDoctortable full of doctor information aPatienttable with patient information And aDepartmenttable with an entry for each department of the hospital.In that model: There is amany-to-manyrelationship between the records in the doctor table and records in the patient table (Doctors have many patients, and a patient could have several doctors); Aone-to-manyrelation between the department table and the doctor table (each doctor works for one department, but one department could have many doctors).One-to-onerelationship 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:

3.2 IDENTIFICATION OF ENTITIES:For construction of database for airline reservation system we need two tables1. Flights2. Reservation chart3.2.1 ATTRIBUTES TO ENTITIES:1. FLIGHTS:

Column NameConstraint Data type

Flight idNUMBER

Dept timePrimary keyTIME

Date DATE

Count1NUMBER

Source NOT NULLCHAR(15)

DestinationNOT NULLCHAR(15)

Flight Name NOT NULLCHAR(15)

DurationNOT NULLTIME

Arriv timeNOT NULLTIME

N.o.sNOT NULLNUMBER

Fare NOT NULLNUMBER

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 nameConstraint Date type

CnameNOT NULLCHAR(30)

AddressNOT NULLCHAR(30)

Email id UNIQUECHAR(30)

Ph noUNIQUENUMBER(12)

Seat noNUMBER(3)

Flight idFOREIGN KEYNUMBER(3)

Dept time (refers to FLIGHTS)TIME

DateDATE

FareNOT NULLNUMBER(10)

SourceNOT NULLCHAR(20)

DestinationNOT NULLCHAR(20)

Arrv timeNOT NULLTIME

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:

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), 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),constraintppl primary key(seatno,fid,time1,d_date));

4. LOGICAL SCHEMA DESIGN4.1 REPRESENTATION OF ENTITIES INTO TABLES:For construction of database for airline reservation system we need two entities.1.Flights2.Reservation chartFLIGHTS :Column NameConstraint Data type

Flight idNUMBER

Dept timePrimary keyTIME

Date DATE

Count1NUMBER

Source NOT NULLCHAR(15)

DestinationNOT NULLCHAR(15)

Flight Name NOT NULLCHAR(15)

DurationNOT NULLTIME

Arriv timeNOT NULLTIME

N.o.sNOT NULLNUMBER

Fare NOT NULLNUMBER

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 nameConstraint Date type

CnameNOT NULLCHAR(30)

AddressNOT NULLCHAR(30)

Email id UNIQUECHAR(30)

Ph noUNIQUENUMBER(12)

Seat noNUMBER(3)

Flight idFOREIGN KEYNUMBER(3)

Dept time (refers to FLIGHTS)TIME

DateDATE

FareNOT NULLNUMBER(10)

SourceNOT NULLCHAR(20)

DestinationNOT NULLCHAR(20)

Arrv timeNOT NULLTIME

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.

5. SCHEMA REFINEMENT5.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 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 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. 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:FIDDTIMEDATECOUNTSOUCEDESTFNAMEDURAATIMENOSFAREDIST

10109:0012/21VHKingfish207005401200600

10114:0012/21VHKingfish212005401200600

10109:0013/21VHKingfish207005401200600

10209:0012/21HVKingfish207005401200600

10214:0012/21HVKingfish212005401200600

10209:0013/21HVKingfish207005401200600

10310:0014/21HVIndian208006001300600

10314:0015/21HV Indian212006001300600

Here the primary key is combination of FID+D.TIME+DATEHere the repeated values are For a particular fid - source destination duration f.name 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:FIDDATEDEPT.TIMEARRL.TIMECOUNTAVILABLE(No. of seats_count)

10112/29:007:001539

10112/214:0012:002538

10113/29:007:004536

10212/29:007:00100440

10212/214:0012:00205335

10213/29:007:00120420

10312/29:007:00300300

10312/214:0012:00100500

10313/29:007:00420180

In this table primary key is: FID+DATE+DEPT.TIMEFLIGHT DETAILS:FIDF.NAMEFAIRNO. OF SEATSSOURCEDESTINATIONDURATIONDISTANCE

101Kingfisher1200540VH2 hrs600

102Kngfisher1200540HV2 hrs600

103Indian1300600HV2 hrs600

In the above table some data like source, destination, distance repeated so once again decompose flight details table. FLIGHT DETAILS:FIDF.NAMEFAIRNO. OF SEATSROUTE ID

101Kingfish1200540191

102Kingfish1200540192

103Indian1300600192

FID primary key

ROUTE DETAILS:RIDSOURCEDESTINATIONDISTANCE

191VH600

HV600

RID primary keyHere the fid given to any flight according to its name,sorce,destination.Now we have tables (1)FLIGHTS (2)FLIGHT DETAILS (3)ROUTE DETAILSHere we join tables FLIGHTS FLIGHT DETAILS Using FidWe join tables FLIGHT DETAILS ROUTE DETAILS Using RidAll these tables in first normal form (No row has two values)Now we can get any value from FLIGHTSUsing 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 RidSo 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.CnameAddrEmidPh noSt noFidD timeDateFareSourcDestA time

If we know fid we can get source, destination, and fare so we remove source, destination, fare from table.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:FidDateD.timeSeat noCustomer nameAddressEmail idPn no

10112-2-20109:001PraveenVizagPaveen@hotmail8008544171

10112-2-20109:[email protected]

10112-2-20109:[email protected]

10113-2-201014:[email protected]

10212-2-20109:[email protected]

10212-2-20109:[email protected] 9826485332

10313-2-201014:[email protected]

10412-2-20109:[email protected]

Here the primary key is: FID+DATE+DTIME+SEATNONo data is repeated is a particular row and its satisfies relation so its in first normal form.The reservation table in second normal form1) It satisfies first normal form2) 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.The combination of these four columns is unique.The reservation table in third normal form1) It satisfies second normal form2) 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 MODELThe 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. FLIGHTS2. FLIGHT DETAILS3. ROUTE DETAILS4. RESERVATION6.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.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 : INTEGERN.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 : STRINGDISTANCE : INTEGER)For instance the field named SOURCE has a domain named STRING.The set of values associated with domain STRING is the set of all character values.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.The set of values associated with domain STRING is the set of all character values.

6.3 IDENTIFING CONSTRAINTS OVER RELATION: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 NAMECONSTRAINTDOMAIN

FIDINTEGER

DATEPRIMARY KEYDATE

DEPT TIMEVARCHAR2

ARRL TIMENOT NULLVARCHAR2

COUNTNOT NULLINTEGER

AVAILABLENOT NULLINTEGER

PRIMARY KEY: Combination of FID, DATE, DEPT TIMEThe combination of above candidate keys uniquely identifies FLIGHTS in the database.

2.FLIGHT DETAILS:COLUMN NAMECONSTRAINTDOMAIN

FID PRIMARY KEYINTEGER

FNAMENOT NULLCHAR

FARENOT NULLINTEGER

NO OF SEATSNOT NULLINTEGER

ROUTE IDNOT NULLINTEGER

PRIMARY KEY: FID FOREIGN KEY: RID(References ROUTES)

3.ROUTE DETAILS:COLUMN NAMECONSTRAINTDOMAIN

ROUTE IDPRIMARY KEYINTEGER

SOURCENOT NULLCHAR

DESTINATIONNOT NULLCHAR

DISTANCENOT NULLINTEGER

PRIMARY KEY: RID 4.RESERVATION:COLUMN NAMECONSTRAINTDOMAIN

FID INTEGER

DATE PRIMARY KEYDATE

DEPT TIME VARCHAR2

SEAT NOINTEGER

PASSENGER NAMENOT NULLCHAR

ADDRESSNOT NULLCHAR

EMAIL IDNOT NULLCHAR

PHONE NUMBERNOT NULLINTEGER

PRIMARY KEY: FID,DATE,DEPT TIME,SEATNO

6.4 INTRODUCTION TO ORACLE DATABASE

TheOracle Database(commonly referred to asOracle RDBMSor simply asOracle) is arelational database management system (RDBMS) produced and marketed byOracle Corporation. As of 2009, Oracle remains a major presence indatabasecomputing. Larry Ellison and his friends and former co-workersBob MinerandEd Oatesstarted the consultancy Software Development Laboratories (SDL) in 1977. SDL developed the original version of the Oracle software. The nameOraclecomes from the code-name of aCIA-funded project Ellison had worked on while previously employed byAmpex.Oracle database conventions refer to defined groups of object ownership (generally associated with a "username") asschemas. 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 usernameScottand the passwordtiger. The name of theSCOTTschema 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,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), 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), DIST number(5));

4. RESERVATION(PASSRESV):

Sql> Create table PASSRESV ( FID number(4), B_DATE date, D_TIME varchar2(5), ST_NO number(4), 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 NameConstraint Data Type

FIDNUMBER

B_DATEPRIMARY KEYDATE

D_TIMEDATE

A_TIMENOT NULLTIME

COUNTNOT NULLNUMBER

AVALNOT NULLNUMBER

PASSENGERS (PASSRESV):Column NameConstraintData Type

FIDNUMBER

B_DATEPRIMARY KEYDATE

D_TIMEVARCHAR

ST_NONUMBER

CNAMENOT NULLCHAR

ADRSNOT NULLVARCHAR

EM_IDNOT NULLVARCHAR

PH_NONOT NULLNUMBER

FLIGHTDETAILS (FLIGHTDET):Column Name ConstraintData Type

FIDPRIMARY KEYNUMBER

FNAMENOT NULLCHAR

FARENOT NULLNUMBER

NOSNOT NULLNUMBER

RIDNOT NULLNUMBER

ROUTE DETAILS (ROUTES):Column Name ConstraintData Type

RIDPRIMARY KEYNUMBER

SOURCENOT NULLCHAR

DESTNOT NULLCHAR

DISTNOT NULLNUMBER

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.

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.

6.7 COMPLETE ENITITY RELATION SHIP DIAGRAM:

7.SNAPSHOT OF TABLES WITH VALID DATA ENTRIES1.FLIGHTSSQL> 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 1809 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 1914 rows selected.

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 1600 198 DELHI BOMBAY 1600 199 VIZAG BANGLORE 1000 200 BANGLORE VIZAG 1000

11 rows selected.

4.RESERVATION(PASSRESV)

SQL> SELECT * FROM PASSRESV;

FID B_DATE D_TIM ST_NO CNAME ADRS EM_ID PH_N0 101 12-FEB-10 09:00 1 aditya.v karshed aditya 9.1988E+11 101 12-FEB-10 09:00 2 praveen srikakulam paveen113 9.1801E+11 101 12-FEB-10 09:00 3 chaitanya vijayawada chaitu 9.1949E+11 101 13-FEB-10 14:00 1 mathus vizag varsha 9.1900E+11 102 12-FEB-10 09:00 1 ranjit srikakulam Varanasi 9.1876E+11 102 12-FEB-10 09:00 2 suresh vizag suresh 9.1877E+11 103 13-FEB-10 14:00 1 manoj vzm manojp 9.1987E+11 7 rows selected.

8. QUERIES1) 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 PH_N0 101 12-FEB-10 09:00 1 aditya.v karshed aditya 9.1988E+11 101 12-FEB-10 09:00 2 praveen srikakulam paveen113 9.1801E+11 101 12-FEB-10 09:00 3 chaitanya vijayawada chaitu 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 B_DATE D_TIM A_TIM AVAL COUNT FARE 102 KINGFISHER 13-FEB-10 9:00 7:00 420 120 1200 103 SPICE 13-FEB-10 9:00 7:00 180 420 13003) 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 wherefid in (select fid from flights where b_date='12-FEB-10'));

RID SOURCE DEST DIST 191 VIZAG DELHI 1200 192 DELHI VIZAG 1200

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 A_TIM COUNT AVAL 101 12-FEB-10 9:00 7:00 7 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 D_TIM A_TIM COUNT AVAL 101 12-FEB-10 9:00 7:00 22 519

5) SQL query to retrieve details of routes those have flight services.SQL> select source, dest from routes;

SOURCE DESTVIZAG DELHIDELHI VIZAGVIZAG HYDERABADHYDERABAD VIZAGHYDERABAD VIZAGVIZAG BOMBAYBOMBAY VIZAGBOMBAY DELHIDELHI BOMBAYVIZAG BANGLOREBANGLORE 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 ST_NO CNAME ADRS EM_ID PH_NO 101 12-FEB-10 9:00 2 praveen srikakulam paveen113 9.1801E+117) 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 2 101 13-FEB-10 09:00 4 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.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 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

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. BIBLIOGRAPHY1. 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.

AIRLINE RESERVATION SYSTEM2