lc78 Flight number belongs in that table; each pair goes with a different flight number (e.g. flight 987 is always Winnipeg to Vancouver) Some dates are repeated; do not correspond to particular flights (or passengers), they do not go in the entity tables If you take a close look at the Price column, flight price is totally predictable according to the flight. Step 4: Split up fields with too much information If field containing both first and last names, split into two separate fields, first Name and Last Name. If flights origindestination were in a single field (with values like Winnipeg Vancouver or EdmontonCalgary), split into two fields Step 5: Choose a primary key for each entity table Look for fields that contain the words ID or Number. Flights table, already a Flight Number that we can probably assume is different for each flight airlines use these as a primary key Passengers, it is more difficult Phone Number field, with no good candidate for a primary key field, we will have to add a new field to the Passengers table, Call it ID AutoNumber Step 6: Give the transaction table a name Table has information about passengers booking flights on airplanes = Bookings Calling it Transactions would be bad answer, not specific enough; other good names may have been Reservations or Ticket Purchases. Step 7: Determine which fields go in the transaction table Need two foreign keys in transaction table, based on the primary keys from the entity tables: Flight Number and Passenger ID Leftovers go in transaction table Step 8: Draw the solution, With lines between the names of the related fields Draw out tables, listing names, the fields in each, which are the primary keys, which are the foreign keys, and the relationships between them.