The first, you should read the NORMALIZATION concepts (1NF,2NF,3NF,...) after that you can use them to verify your dependency diagram. So, I'm talking about some basic steps to help you convert ERD, which I often do:
1- Identify objects (objects are WHO, WHERE, WHAT, WHEN ), you imagine that they are exited
and can be defined.
2- Identify natural keys of objects and their properties,...
3- Identify relationships of objects. The step help you answer some questions:
- What actions?
- Who took place actions?
- Where actions are happened?
- When actions happened
4-If we have many-many relationship, we separate them into an individual table. Otherwise, we use foreign keys or not.
5- Verify our diagram matching which NF.
Now, we come back your ERD and we will convert it to dependency diagram.
Step 1- identify objects: Here, we can understand that we want to manage list of appointments of doctors and patients. So, we have 2 objects Doctor and Patient
Step 2- identify natural keys/properties of objects: you listed out above.
Step 3- identify relationships of objects: As you know, a patient can have zero or many appointments with doctors and a doctor can have zero or many appointments with patients. So, we have a many-many relationship.
Step 4- Because we have a many-many relationship, we create a table here.
Finally, we have a diagram
Doctor(Doc_FEmpID,Doc_Fname,Doc_FCellPhone) Patient(Pat_PatientID,Pat_PatientName,Pat_Phone,Pat_Address,Pat_City) Appointment(App_Num,Doc_FEmpID,Pat_PatientID,App_Date,App_Time)
Step 5- verify the diagram again.
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
The only way I know of is one I can't recommend.
If you convert your EERD into a relational design (with tables, etc.) using some technique like "class table inheritance", you have now disguised the fact that the original EERD contained a generalization/specialization pattern.
If you now turn around and reverse engineer that back to an ERD, you have something that satisfies the requirements of your question. But that's grotesque. It conceals the original intent rather than revealing it. Why would anyone ever want to do that?