I think you're creating more tables than necessary.
First, why do you need a table for "bridal couple"? Why not just include the bride and groom fields in wedding_booking table? The only reason to break this out into a separate table would be if you expected to book multiple weddings for the same couple, which seems rather unlikely. If they're getting re-married, it's probably not a second wedding to each other.
Why have tables for "bride" and "groom"? All these do is serve as an extra stepping stone to get from bride and groom id's to their names. Why not just have wedding_booking have fields for bride_name_id and groom_name_id?
Why is name separate from client? Why not just put the name fields in the client table? Okay, you also use name for the employee who does the booking. Really you need an employee table and a client table, with each including a name. With just two fields making up the name, there's little gained by breaking this out into a separate table.
I don't see any reason for room_booking to be a separate table. Booking should simply point to a room.
"Plaza" and "Ballroom" are not fields in suite. They are two different records. Maybe there's "description" that can have the value of "plaza" or "ballroom".
If I understand your intent, every wedding_booking must be linked to a booking. So there's no need to have a client_id in wedding_booking as it's already in booking.
Likewise staff_member in booking appears to be the same thing as booker_id in wedding_booking. It belongs just once, in booking.
Participants, delegates, and guests all appear to be the same idea: how many people are attending this event. I'd combine these into a single field in event_booking.
If a conference can use either a meeting room or a suite, and possibly multiples, it gets awkward to break these into two tables. I'd combine meeting_room and suite into a single table. If weddings and theme nights can book meeting rooms, fine, add a flag in there that says which it is, and then suites are available to all three types of events while meeting rooms are available only to conferences.
Many database designers would challenge me on this, but: I'd seriously consider combining theme night, conference, and wedding into a single table and having a type flag that indicates which it is. Most of what you need to record for these events is the same: how many people are coming, what room or rooms are they using, who's name is it under. A few fields only apply to one or the other, like conferences probably don't have flowers. But if somebody organizing a conference said they wanted to have flowers, would you tell them they can't because it's not a wedding? A conference or a theme night could have an open bar, I would think. Etc. My point is, there's no point limiting the services your hotel can offer to just certain types of events because you think they are unlikely to be wanted at other types of events -- unless there's really some reason why you just can't do it, legal restrictions or something. Also, if you later come up with another type of event you might book -- a birthday party or a bar mitzvah or a politician's victory party or whatever -- you just add another type, you don't have to struggle with creating a whole new table. You can even toss in an "other" type to allow for it so you don't have to scramble to reprogram the first time it happens.
Well, that's probably enough comments for the first round. :-)
Best Answer
Well, having occupation as part of Person isn't very well normalized. One person can have multiple occupations, so that should go in a different table or set of tables, depending on how normalized your schema is.
I am confused - how is a "bank name" an occupation? Or even related to a person?
I would note that while the theory of a Person table is sound, in practice it can get fairly interesting; for example, perhaps you start with U.S. SSNs. Then you get some Canadians with TINs (also U.S. 9 digit federally issued identifiers). And companies with TINs. Then you get some people with Mexican CURP values (18 character alphanumerics). Now you have a person with a CURP and a TIN both. Now you have a person with a Chinese identification number as well.
Let's not even get into truly international addresses :).
You may want to consider normalizing further, but definitely work out how a single human being with multiple roles (employee, vendor, customer) and multiple locations (different addresses or cities or regions or countries) and multiple ID's (TIN, SSN, etc.) is going to work.
Likewise with organizations - perhaps your food service vendor is also a customer, and then comes to work for you part-time.
EDITED TO ADD: I would also note that the "password" field horrifies me. Please read How to securely hash passwords? and replace the password field with fields for the plaintext random per-person salt, the PBKDF2/Bcrypt/Scrypt password hash, and ideally the # of iterations (so it's easy to increase).