Airline database prototype

Question

I am designing an airline database (the outline of one anyway) for an assignment and seem to be running around in circles.

Three tables are concerned:

Customer        Booking_Reference        Flight

cust_id(pk)     reference_id(pk)         Flight_id(pk)
                cust_id(fk)

A booking reference can have many flights.

A flight will have many booking references.

I am trying to break up the many to many relationship. Is it possible to have a relational table with the flight_id as the attributes (columns) and the booking_reference as the rows (data)? If so there can be no primary key, which is a no-go as I understand.

Alternatively I could make the booking_reference/flight relational table with 2 attributes and a compound primary key of booking_reference/flight, which would result in both entities being duplicated but the primary key being unique (half of it anyway). Is this acceptable design practice?

I was going to just list a max number of 8 flights as columns in the booking reference table (with NULL for the entries where there is less than 8 flights) and give customers with more than 8 flights a new reference_id, but this seems to be more ridiculous as i learn more about databases, resulting in more reference ids and more NULL data.

Any ideas on which route to take?

Answer 1

Rather than having eight (or any arbitrary number of) columns, create what's sometimes called a join table, with three columns:

Table: references_flights

id (Primary key)

reference_id (fk)

flight_id (fk)

You should then be able to query data across them with the right JOINs, but I'll leave that for someone with more database expertise.