Databases Reference
In-Depth Information
ModelNumber
GivenNames
RegistrationNumber
Airplane
Passenger
Surname
1
Capacity
EmailAddress
1
Books
FlightNumber
Flies
N
N
Booking
From
N
1
To
Flight
HasBooking
DepartureDate
DepartureTime
ArrivalDate
ArrivalTime
Figure 4-13. The ER diagram of the flight database
but considering the issue more carefully shows that there is a hidden entity here:
the booking itself. We capture this by creating the intermediate entity
Booking
and
1:N relationships between it and the
Passenger
and
Flight
entities. Identifying such
entities allows us to get a better picture of the requirements. Note that even if we
didn't notice this hidden entity, it would come out as part of the ER-to-tables
mapping process we'll describe next in “Using the Entity Relationship Model.”
What it doesn't do
Again, this is a very simple flight database. There are no requirements to capture pas-
senger details such as age, gender, or frequent-flier number.
We've treated the capacity of the airplane as an attribute of an individual airplane. If,
instead, we assumed that the capacity is determined by the model number, we would
have created a new
AirplaneModel
entity with the attributes
ModelNumber
and
Capacity
. The
Airplane
entity would then not have a
Capacity
attribute.
We've mapped a different flight number to each flight between two destinations. Air-
lines typically use a flight number to identify a given flight path and schedule, and they
specify the date of the flight independently of the flight number. For example, there is
one IR655 flight on April 1, another on April 2, and so on. Different airplanes can
