Consider the following AIRLINE database schema shown in the Figure $5\mathrm{.}8,$ which describes a database for airline flight information. Each FLIGHT is identifiedAIRPORT

FLIGHT

FLIGHT$\_$LEG

LEG$\_$INSTANCE

FARE

AIRPLANE$\_$TYPE

CAN$\_$LAND

AIRPLANE

SEAT$\_$RESERVATION

Figure $5\mathrm{.}8$

The AIRLINE relational database schema. by a Flight$\_$number, and consists of one or more FLIGHT$\_$LEGs with Leg$\_$numbers $1,2,3,$ and so on$.$ Each FLIGHT$\_$LEG has scheduled arrival and departure times, airports, and one or more LEG$\_$INSTANCEs $$ one for each Date on which the flight travels. FAREs are kept for each FLIGHT. For each FLIGHT$\_$LEG instance, SEAT$\_$RESERVATIONs are kept, as are the AIRPLANE used on the leg and the actual arrival and departure times and airports. An AIRPLANE is identified by an Airplane$\_$id and is of a particular AIRPLANE$\_$TYPE. CAN$\_$LAND relates AIRPLANE$\_$TYPEs to the AIRPORTs at which they can land. An AIRPORT is identified by an Airport$\_$code.

Specify all the referential integrity constraints that hold on the schema in the following format:

$($Foreign key$)$ matches $($Primary Key$)$

Example: Flight$\_$number of FLIGHT$\_$ LEG matches Flight$\_$number of FLIGHT

The FKs and PKs are provided below.

FKs:

Flight$\_$number of FLIGHT$\_$ LEG

Flight$\_$number of FARE

Flight$\_$number of LEG$\_$INSTANCE

Flight$\_$number of SEAT$\_$RESERVATION

Arrival$\_$airport$\_$code of FLIGHT$\_$LEG

Departure$\_$airport$\_$code of FLIGHT$\_$LEG

Airport$\_$code of CAN$\_$LAND

Leg$\_$number of LEG$\_$INSTANCE

Leg$\_$number of SEAT$\_$RESERVATION

Airplane$\_$type$\_$name of CAN$\_$LAND

Airplane$\_$type of AIRPLANE

Airplane$\_$id of LEG$\_$STANCE

PKs:

Flight$\_$number of FLIGHT

Leg$\_$number of FLIGHT LEG

Airplane$\_$ id of AIRPLANE

Leg$\_$number of LEG$\_$INSTANCE

Airport$\_$code of AIRPORT

Flight$\_$number of FLIGHT$\_$LEG

Airplane$\_$type$\_$name of AIRPLANE$\_$TYPE

Flight$\_$ number of LEG$\_$INSTANCE