ENTITIES AND THEIR PROPERTIES Flight : o Flight No This is a unique alphanumeric code which identifies each airplane registered

ed in the system. o Model This is the model number of the airplane. This is defined by the makers of the plane. o Size This defines the dimensions of the plane in terms of volume. o Weight Stores the net weight of the plane. o Weight Limit Stores the maximum weight that the plane should carry. o o Passenger Capacity Stores the maximum number of passengers the plane can seat. Fuel Capacity Stores the fuel capacity of the fuel tank.

Route : o Route No This is a unique alphanumeric code used to define each official route which a flight can take. o Source This is the starting city for the route. o Destination This is the ending city for the route. o o Distance This stores the total distance in Kms traversed by the route. Additional Cities Visited This is a multivalued attribute which stores the list of all cities which serve as stops (for fuel refilling or other purposes) within the route. The multivalued property is resolved by storing it as a separate table as follows:

Route_cities( Route_no, Stage_no, Source_city, Destination_city, Distance) Stage_no Source_city Stores the order in which the cities are visited by breaking the route into stages. Starting city of that stretch

Destination_city Ending city of that stretch Distance Distance covered in that stretch

Flight Schedule : o Flight No This is the Flight No of the plane whose Schedule is being created. o Route No This is the Route No of the route the flight will take. o Date Stores the date of arrival/departure of the flight. o Fuel Needed This is the total amount of fuel needed by the flight to complete the journey. o Scheduled Time of Arrival Stores the time the flight is supposed to arrive at the airport. o Scheduled Time for Departure Stores the time the flight is supposed to depart from the airport. o Terminal No This stores the Airport Terminal at which the Flight is supposed to arrive or depart from. o Flight Fare This is a multivalued attribute which stores the fare for each class in the flight. It is multivalued because the fare is different for each class in the same flight. The multivalued property is resolved by storing it as a separate table as follows: Flight_fare(Flight_no, Route_no, Class, Fare) Class Fare This stores the category of seat which the passenger has booked. (e.g. 1st class, Economy class) Stores the cost of the ticket for that class.

Operational Data : o Flight No This is the Flight No of the plane whose Operational data is being stored. o o Flight Status This field indicates whether the plane is fit for flying or not. Engine Status This field indicates the last checked status of the engine. o Fuel Status This stores the amount of fuel left in the plane. o Hangar No This stores the hangar number in which the plane is currently residing. o Next Refueling Station This stores the name of the city where the fuel tank of the plane needs to be refilled. o Next date for Maintenance This field stores the date when the flight needs to be sent for maintenance.

Reservation Table : o Ticket No This is a unique alphanumeric code generated for each ticket issued to a passenger. Ticket numbers are specific to flights and routes. o Passenger Id This is a unique alphanumeric code given to each passenger who books a ticket. It is used to refer to the customer within the system. o o Passenger Name Stores the name of the passenger. Age Stores the age of the passenger. o Gender Stores the gender of the passenger. o Address Stores the address of the passenger. o Date of Departure Stores the date for which the passenger has bought a ticket.

Class Stores the flight class whose ticket the passenger has bought.

Payment Status Used to indicate whether the payment for the ticket has been fully received. This is useful when the ticket is bought using a debit card or credit card.

Customs Status Used to check whether a passenger has been cleared by Customs. This field is updated when the passenger comes to board a plane.

Cargo : o Tracking Id A unique alphanumeric code assigned to every cargo sent via the system. It is used to track the present location of the cargo. o Type of Item Stores the type of item denoted by the tracking id. (e.g. Fragile items, electronic items, etc.) o Weight Stores the weight of the piece of cargo. o Clearance Status Indicates whether the cargo has been cleared by customs or not. o Cost of Sending Stores the handling charges for the piece of cargo. o o Source Stores the starting city for the cargo. Destination Stores the destination city for the cargo. o Present Location Stores the current location of the piece of cargo.

Staff : o Staff Id This is a unique Access code generated for each employee of the airport. o Staff Name Stores the name of the employee. o Date of Birth Stores the date of birth of the employee.

Address Stores the address of the employee.

Phone No Stores the phone number of the employee.

o o

Date of Joining Stores the date of joining of the employee. Designation Stores the designation of the employee.

Leave Details The leave details of an employee consists three fields: Leave status indicating whether the staff is on leave Last leave date storing the last time the staff was on leave Pending Leave stores the days the staff can take leave Although these fields can be stored as part of the staff database itself, we store it in a separate table as the leave details are much more dynamic and need frequent updates in comparison to the rest of the database. Thus the Leave details are stored as follows: Leave_status(Staff_id, Leave_status, Last_leave_date, Pending_leave)

Training Details This is a multivalued attribute which stores the training details for each employee. It is multivalued because each employee can enroll for any number of training courses. The multivalued property is resolved by storing it as a separate table as follows: Staff_training(Staff_id, Train_Module_id, Training_status) Train_Module_id This stores the training modules the employee has undergone. Training_status Indicates whether the employee completed the training for that training module.

Staff Roster : o Staff Id Contains the Staff Id of the employee for whom the schedule is being created. o Date Stores the date for which the schedule is being made.

Time of Check In Stores the time when the employee came to work.

Duration Stores the time period, in hours, for which the employee has to work.

o o

Division Stores the division or department to which the employee is assigned. Position Stores the nature of job the employee has to perform.

Training Module : o Module Id This is a unique alphanumeric code designated to each training module. o Module Name Stores the name of the training module. o Duration Stores the time, in days, required to complete the training. o Details Stores a brief description of the training module stating its primary objectives.

Training Schedule : o Staff Id This is the Staff id of the employee for which the training schedule has been created. o Module Id This is the Training Module id for which the staff has been enrolled. o Start date Stores the date from which the training is to begin. o End date Stores the scheduled date on which the training should end. This is modified whenever the schedule changes. o Status Stores the percentage completion of the training by the staff.

RELATIONSHIP IDENTIFICATION AND RESOLUTION INTO TABLES Flight Schedule Belongs To Flight In Flight Database o o o o Relation between Fight Schedule and Flight Database Cardinality is 1:1 Participation of Flight Schedule is complete Hence the relationship is represented by making the field Flight_no of Flight Schedule is made to reference the field Flight_no of Flight Database

Flight Allocated To o o o o Relation between Fight Schedule and Route Database Cardinality is n:1 Participation of Flight Schedule is complete Hence the relationship is represented by making the field Route_no of Flight Schedule is made to reference the field Route_no of Route Database

Operational Data Works on Flight o o o o Relation between Operational Data and Flight Database Cardinality is 1:1 Participation of both tables is complete Hence the relationship is represented by making the field Flight_no of Operational data is made to reference the field Flight_no of Flight Database

Cargo Allocated To o o o o o Relation between Cargo Database and Fight Schedule Cardinality is n:1 Participation of Cargo Database is complete Hence the relationship is represented by adding the field Flight_no of Flight Schedule to Cargo Database Hence the schema of Cargo Database is as follows: Cargo (Flight_No, Tracking_Id, Type_of_Item, Weight, Clearance_Status, Cost_of_Sending, Source, Destination, Present_Location)

Passengers Allocated From o Relation between Fight Schedule and Reservation Table o Cardinality is 1:n o Participation of Reservation Table is complete

o o

Hence the relationship is represented by adding the field Flight_no of Flight Schedule to Reservation Table Hence the schema of Reservation Table is as follows: Reservation Table (Ticket_No, Flight_No, Passenger_Id, Passenger_Name, Age, Gender, Address, Date_of_Departure, Class, Payment_status, Customs_status)

Staff Allocated From o o o o

Relation between Fight Schedule and Staff Roster Cardinality is 1:n Participation of neither tables is complete Hence the relationship is represented by creating a new table Flight_staff with the attributes Flight_no from Flight Schedule and Staff_id from Staff Roster. Hence the schema of Flight_staff is as follows: Flight_staff (Flight_no, Staff_id)

Staff Belongs To o o o o Relation between Staff Roster and Staff Database Cardinality is 1:1 Participation of both tables is complete Hence the relationship is represented by making the field Staff_Id of Staff Roster is made to reference the field Staff_Id of Staff Database.

Staff Joins Training o o o o Relation between Staff Database and Training Schedule Cardinality is 1:n Participation of Training Schedule is complete Hence the relationship is represented by making the field Staff_Id of Training Schedule is made to reference the field Staff_Id of Staff Database.

Training Schedule Generated By o o o o Relation between Training Schedule and Training Module Cardinality is n:1 Participation of Training Schedule is complete Hence the relationship is represented by making the field Module_Id of Training Schedule is made to reference the field Module_Id of Training Module.

RELATIONAL SCHEMA

Flight Route Route_cities Flight_Schedule Flight_fare Operational_Data Flight_staff Reservation Table Cargo Staff Leave_status Staff_training Staff Roster Training Module Training Schedule

(Flight_No, Model ,Size, Weight , Weight_Limit, Passenger_Capacity, Fuel_Capacity) (Route_No, Source, Destination, Distance) ( Route_no, Stage_no, Source_city, Destination_city, Distance) (Flight_No, Route_No, Date, Fuel_Needed, Scheduled_Time_of_Arrival, Scheduled_Time_for_Departure, Terminal_No) (Flight_no, Route_no, Class, Fare) (Flight_No, Flight_status, Engine_status, Fuel_status, Hangar_no, Next_Refueling_station, Next_date_for_Maintenance) (Flight_no, Staff_id) (Ticket_No, Flight_No, Passenger_Id, Passenger_Name, Age, Gender, Address, Date_of_Departure, Class, Payment_status, Customs_status) (Flight_No, Tracking_Id, Type_of_Item, Weight, Clearance_Status, Cost_of_Sending, Source, Destination, Present_Location) (Staff Id, Staff Name, Date of Birth, Address, Phone No, Date of Joining, Designation) (Staff_id, Leave_status, Last_leave_date, Pending_leave) (Staff_id, Train_Module_id, Training_status) (Staff_Id, Date, Time_of_Check_In, Duration, Division, Position) (Module_Id, Module_name, Duration, Details) (Staff_Id, Module_id, Start_date, End_date, Status)