Airline Reservation System

An Airline Reservation System stores the following information (The following description may lead to un-normalized relations normalize them whenever required). The Flight Details It includes the originating flight terminal and destination terminal, along with stops in between, number of seats booked/available seats between two destination etc. Customer Description It includes customer code, name, address and phone number. This information may be used for keeping the records of customer for any emergency or for any other kind of information Reservation Description It includes customer code number, flight number, date of booking, date of traveling, (You may assume any other field/relation, if needed). Let us assume that this distributed system is to be used following application: a. A request for booking/cancellation of flight from any source to any destination, giving connected flights in case no direct flight between the specified Source-Destination pair exists. b. Calculation of high fliers (most frequent fliers) and calculating appropriate reward points for these fliers. Our design includes: i) The global schema, fragmentation schema, allocation schema. ii) SQL commands for above queries/applications iii) How the response for application 1 and 2 will be generated. iv) Implementation of the database using a centralized database management system DISTRIBUTED DATABASE: Distributed database implies that a single application should be able to operate transparently on data that is spread across a variety of different databases and connected by a communication network. A distributed database system consists of a collection of sites, connected together via some kind of communications network, in which 1. Each site is a database system site in its own right,

2. The sites have agreed to work together so that a user at any site can access data anywhere in the network exactly as if the data were all stored at the users own site. It follows that the so-called distributed database is really a kind of virtual objects, whose component parts are physically stored in a number of distinct real database at a number distinct sites. A distributed database system consists of a collection of sites, each of which may participate in the execution of transactions which access data at one site, or several sites. The main difference between centralized and distributed database systems is that, in the former, the data resided in one single location, while in the latter; the data resided in several locations. Each site is able to process local transactions, those transactions that access data only that single site. A site may participate in the executions of global transactions, those transactions that access data in several sites. The execution of global transactions requires communication among the sites. Each site is a database system site in its own right. In other words, each site has its own local real databases, its own local users, its own local DBMS and transaction management software and its own local data communications manager. The distributed database system can thus be regarded as a kind of partnership among individual local DBMS at the individual sites. In the given context there are four sites, i.e., Delhi, Mumbai, Chennai and Kolkata and these sites are geographically dispersed. Each site has its own computer with a database consisting of all the customers and flight details maintained at that site. The database systems at the various sites are based on the relational model. Each branch maintains the relation reservation where Reservation_scheme=(site_code,fl_no,cust_code,travel_date) Site containing information about the four sites maintains the relation (Cite_scheme), where Cite_scheme=(Cite_code,Cite_name) A local transaction is a transaction that accesses information in the one single site, at which the transaction was initiated. A global transaction, on the other hand is one which either access accounts in a site different from the one at which the transaction was initiated, or access several different sites. Then the advantages are surely obvious: The distributed arrangement combines efficiency of processing (the data is stored close to the point where it is most frequently used) with increased accessibility (it is possible to access a Delhi information from Kolkata and vice versa, via the communication network), reliability and availability and speedup of query processing. Allowing the structure of the database to mirror the structure of the enterprise is probably the number one advantage of distributed systems. There are some disadvantages too, of which the biggest is the fact that distributed systems are complex, software development cost, greater potential for bugs and increase processing overhead.

As per commercial implementations, most of todays relational products offer some kind of distributed database support. Some of the best known include, (a) INRESS/STAR , from The ASK Group Inc.s Ingress Division; (b) the distributed database option of ORCALE8 or later from Oracle Corporation and (c) the distributed data facility of DB2 from IBM. It is worth pointing out that all of the systems listed above, both prototypes and products, are relational. OBJECTIVES: 1. Local autonomy 2. No reliance on a central site 3. Continuous operation 4. Location independence 5. Fragmentation independence 6. Replication independence 7. Distributed query processing 8. Distributed transactions management 9. Hardware independence 10. Operating system independence 11. Network independence 12. DBMS independence These above twelve objectives are not all independent of one another, nor are they necessarily exhaustive, nor are they all equally significant. However, they are useful as a basis for understanding distributed technology and as a framework for characterizing the functionality of specific distributed systems.

CLIENT/SERVER SYSTEM:
A client/server system is a distributed system in which, (a) Some sites are client sites and others are serer sites (b) All data resides at the server sites (c) All applications execute at the client sites The term client/server refers primarily to an architecture, or logical division of responsibilities, the client is the application (also known as the front-end), and the server is the DBMS (also known as the backend). A client/server system can be thought of as a distributed system in which all requests originate at one site and all processing is performed at another. In practice the client site might well have its own local databases, but those databases will not play a direct part in the client/server arrangement as such. Client/Server provides a low-priced robust solution to user requirements. This approach permits downsizing production subsystem while allowing the clients and servers the necessary tools and facilitate to control, manage and tune the environment in which they operate. Most client/server solution are also very attentive in matters of security. Access to any resources can be defines to the file level, with such access being controlled through identification and authorization. Logically defined closed use groups can be setup to enable the enhancing of security measures by network administrations.

It allows the database management including security, performance, backup, server enforced integrity to be part of the database machine avoiding the requirement to write large number of redundant piece of code dealing with database field validation and referential integrity. The successful organizations have to be marked drives and competitive in the times to come, and they will use Client/Server computing as the enabling technology to add values to their business. Powerful workstations will be available to all end users to be used as clients to access the information on the servers which are distributed globally. The networks of the future will support much higher bandwidth by using technologies like corporate networks will cut across the boundaries of cities or even countries and they will be connected to major networks around the worlds. E-R DIAGRAM: E-R Diagram constitutes a technique for representing the logical structure of a database in a pictorial manner. This analysis is then used to organize data as a relation, normalizing relation and finally obtaining a relation database. Entities: Which specify distinct real-world items in an application? Properties (or): Which specify properties of an entity and relationships. Attributes Relationships: Which connect entities and represent meaningful dependencies between them?

NORMALIZATION: The basic objective of normalization is to be reducing redundancy which means that information is to be stored only once. Storing information several times leads to wastage of storage space and increase in the total size of the data stored. If a Database is not properly designed it can gives rise to modification anomalies. Modification anomalies arise when data is added to, changed or deleted from a database table. Similarly, in traditional databases as well as improperly designed relational databases, data redundancy can be a problem. These can be eliminated by normalizing a database. Normalization is the process of breaking down a table into smaller tables. So that each table deals with a single theme. There are three different kinds of modifications of anomalies and formulated the first, second and third normal forms (3NF) is considered sufficient for most practical purposes. It should be considered only after a through analysis and complete understanding of its implications. FIRST NORMAL FORM (1NF): This form also called as a flat file. Each column should contain data in respect of a single attributes and no two rows may be identical. To bring a table to First Normal Form, repeating groups of fields should be identified and moved to another table.

SECOND NORMAL FORM (2NF):

A relation is said to be in 2NF if it is 1NF and non-key attributes are functionality dependent on the key attributes. A Functional Dependency is a relationship among attributes. One attribute is said to be functionally dependent on another if the value of the first attribute depends on the value of the second attribute. In the given description flight number and halt code is the composite key.

Splitting of relation given in table 1 into 2NF relations FLIGHT DETAILS: AR_FLIGHT_MST FL_NO FL_NAME ORG_CD DES_CD CAPACITY AR_FLIGHT_DET FL_NO HALT_CD DIST_FRM_ORG NO_QUOTA NO_BOOKED JOUR_DATE VARCHAR2(7) NUMBER(3) NUMBER(3) NUMBER(3) NUMBER(3) PRIMARY KEY (REFERENCE AR_FLIGHT_MST.FL_NO) PRIMARY KEY NOT NULL VARCHAR2(7) VARCHAR2(25) NUMBER(3) NUMBER(3) NUMBER(3) PRIMARY KEY NOT NULL NOT NULL NOT NULL NOT NULL

THIRD NORMAL FORM (3NF): Third Normal Form normalization will be needed where all attributes in a relation tuple are not functionally dependent only on the key attribute. A transitive dependency is one in which one in which one attribute depends on second which is turned depends on a third and so on.

FLIGHT DETAILS: AR_FLIGHT_MST FL_NO FL_NAME ORG_CD DES_CD CAPACITY AR_FLIGHT_DET FL_NO HALT_CD DIST_FRM_ORG NO_QUOTA NO_BOOKED JOUR_DATE AR_HALT_MST HALT_CD DESCRIPTION NUMBER(3) VARCHAR2(30) PRIMARY KEY NOT NULL VARCHAR2(7) NUMBER(3) NUMBER(3) NUMBER(3) NUMBER(3) PRIMARY KEY (REFERENCE AR_FLIGHT_MST.FL_NO) PRIMARY KEY NOT NULL VARCHAR2(7) VARCHAR2(25) NUMBER(3) NUMBER(3) NUMBER(3) PRIMARY KEY NOT NULL NOT NULL NOT NULL NOT NULL

DATA DICTIONARY: FLIGHT DETAILS: AR_FLIGHT_MST FL_NO FL_NAME ORG_CD DES_CD CAPACITY AR_FLIGHT_DET FL_NO HALT_CD DIST_FRM_ORG NO_QUOTA NO_BOOKED JOUR_DATE AR_HALT_MST HALT_CD DESCRIPTION CUSTOMER DETAILS: AR_CUST_MST CITE_CODE CUST_CODE NAME ADDRESS1 ADDRESS2 CITY PIN PH_MOBL_NO DIST_TRAVEL CON_PER_NAME ADDRESS CITY VARCHAR2(3) VARCHAR2(6) VARCHAR2(25) VARCHAR2(30) VARCHAR2(30) VARCHAR2(25) VARCHAR2(6) VARCHAR2(15) NUMBER(4) VARCHAR2(25) VARCHAR2(50) VARCHAR2(25) PRIMARY KEY NOT NULL NUMBER(3) VARCHAR2(30) PRIMARY KEY NOT NULL VARCHAR2(7) NUMBER(3) NUMBER(3) NUMBER(3) NUMBER(3) PRIMARY KEY (REFERENCE AR_FLIGHT_MST.FL_NO) PRIMARY KEY VARCHAR2(7) VARCHAR2(25) NUMBER(3) NUMBER(3) NUMBER(3) PRIMARY KEY NOT NULL NOT NULL NOT NULL NOT NULL

NOT NULL

RESERVATION DETAILS: AR_RESERV_DET CITE_CODE CUST_CODE FL_NO ORG_CD DES_CD DIST_TRAVEL BOOK_DATE TRAVEL_DATE STATUS AR_CITE_MST CITE_CODE CITE_NAME SQL COMMANDS: To develop the given application the below activities are followed in an order: Creation of Database Creation of Tables Creation of Database Triggers Creation of Stores Procedures Creation of Server Enforced validation checks Create of Indexes Creation of view Creation of synonyms The following are some of the SQL commands used to implement this application : CREATION OF TABLES: (a) CREATE TABLE AR_FLIGHT_MST (FL_NO VARCHAR2(7), FL_NAME VARCHAR2(3) VARCHAR2(30) PRIMARY KEY NOT NULL VARCHAR2(3) VARCHAR2(6) VARCHAR2(7) NUMBER(3) NUMBER(3) NUMBER(4) DATE DATE CHAR(1) NOT NULL NOT NULL NOT NULL NOT NULL NOT NULL

VARCHAR2(25), ORG_CD NUMBER(3),DES_CD NUMBER(3),CAPACITY NUMBER(3));

(b) CREATE TABLE AR_FLIGHT_DET (FL_NO VARCHAR2(7),HALT_CD NUMBER(3), DIST_FRM_ORG NUMBER(3),NO_QUOTA NUMBER(3),NO_BOOKED NUMBER(3),JOUR_DATE DATE); (c) CREATE TABLE AR_HALT_MST (HALT_CD NUMBER(3),DESCRIPTION

VARCHAR2(30)); (d) CREATE TABLE AR_CUST_MST (CITE_CODE VARCHAR(3),CUST_CD VARCHAR2(25), VARCHAR2(15),DIST_TRAVEL VARCHAR2(25),ADDRESS VARCHAR2(50),

VARCHAR2(6),NAME VARCHAR2(6),PH_MOBL_NO NUMBER(4),CON_PER_NAME CITY VARCHAR2(25));

ADDRESS1 VARCHAR2(30),ADDRESS2 VARCHAR2(30),CITY VARCHAR2(25),PIN

(e) CREATE TABLE AR_RESERV_DET (CITE_CODE VARCHAR2(3), CUST_CODE VARCHAR2(6), ORG_CD NUMBER(3), NUMBER(4),BOOK_DATE STATUS CHAR(1)); (f) CREATE TABLE AR_CITE_DET (CITE CODE VARCHAR2(3),CITE_NAME FL_NO DES_CD DATE,TRAVEL_DATE VARCHAR2(7), NUMBER(3),DIST_TRAVEL DATE,

VARCHAR2(30)); SELECT COMMANDS : (a) To know the information of flight-wise originating and destination terminals SELECT FL_NO,FL_NAME, ORG_CD,DES_CD FROM AR_FLIGHT_MST ; (b) To get the flight, date wise available seats SELECT FL_NO,FL_NAME,JOUR_DATE (NO_QUOTA-NO_BOOKED)

AVAILABLE FROM AR_FLIGHT_DET ORDER BY FL_NO;

(c) To count the number of flights SELECT COUNT(FL_NO) FROM AR_FLIGHT_MST; a) To find the halt code and names in alphabetic order SELECT HALT_CD,DESCRIPTION FROM AR_HALT_MAST ORDER BY DESCRIPTION; (e) To find out the details of seats available by flight,halt wise SELECT FL_NO,HALT_CD,JOUR_DATE,NO_QUOTA,NVL(NO_QUOTANO_BOOKED) FROM AR_FLIGHT_DET GROUP BY FL_NO,HALT_CD; (f) To find out the details of seats available by halt wise,flight SELECT HALT_CD,FL_NO, JOUR_DATE,NO_QUOTA,NVL(NO_QUOTANO_BOOKED) FROM AR_FLIGHT_DET GROUP BY HALT_CD, FL_NO (g) To list the customers and their information SELECT CUST_CODE,NAME,CITY,PH_MOBL_NO FROM AR_CUSTOMER; (h) city wise reservation(transaction) details SELECT E.CITE_NAME,D.NAME,B.FL_NAME,A.ORG_CD,A.DESC_CD,C.DESCRIPTION, A.DIST_TRAVLE,A.BOOK_DATE,A.TRAVEL_DATE A,AR_FLIGHT_MST B,AR_HALT_MST FROM AR_RESRV_DET D,AR_CITE_MST E C,AR_CUST_MST

WHERE A.CITE_CODE=E.CITE_CODE AND A.CUST_CODE=D.CUST_CODE AND (A.ORG_CD=C.HALT_CD OR A.DES_CD=C.HALT_CD) AND A.FL_NO=B.FL_NO GROUP BY E.CITE_NAME,B.FL_NAME;