You get what you pay for on SO. The advice against using natural keys (names instead of numbers, in this case) is common, but misguided. If you don't believe me, ask your professor.
The number of seats would seem to be a property of the plane, right? The number of booked seats would seem to be the count of seats booked, grouped by flight number.
The arrival and departure cities can be constrained with a
CHECK constraint. You might also want to ensure that departures happen before arrivals (assuming 21st century airport).
Your design is pretty good, better than some of the advice you're getting. Stick with it, don't worry about datatypes for your keys, don't look for fanciness like triggers to implement application logic (and don't fob off real constraints to the application). Do RTFM for
CREATE TABLE several times. If you think of a constraint that can't be declared, I suggest you document it in your project as a flaw in the DBMS.
Do think very carefully about what's unique. I doubt you need BookingID, because PassengerID, Flight#, and Seat would seem to be unique. Passengers are complex (in a real database you'd have a bunch of tables to describe someone) so they need an ID for convenient reference, but still you likely wouldn't want two records sharing name & address.