Can a sublass have two parents (two entity types that are connected with it?) I'm kind of new to ERDs and stuff, just wondering if I'm correct when my (conceptual) entity relationship diagram has two entity types connected to one subclass (so the subclass inherits data from both of it). 



My question here would be: For each entity type connecting to this sublass, does it have its own instance of it? So: Will my room entity type record if its a standard or executive room, and will the booking entity type be able to record if that specific booking was to have decorations or not? 

Sorry, I'm struggling to word this question and I'm sure a few will be confused, but I appreciate any help on the matter.
"Can a subclass have 2 parents(2 entities that connect to it?)".  Yes.  However: Avoid redundant relationships in your ERDs.  For your particular scenario: if the BOOKING entity is connected to STANDARD/EXECUTIVE via ROOM, then you will later be able to write a query whose output tells the user what type of room has been booked.

Regarding your questions:
"For each entity connecting to this sublass, does it have its own instance of it?  So: Will my room entity record if its a standard or executive room, and will the booking entity be able to record if that specific booking was to have decorations or not?" 
ANSWER: Yes, a ROOM can have attributes that determine whether it is a "standard" or "executive" (see the model below).  A booking does not change a room's "decorations".


It would be sufficient to model ROOM -&lt; BOOKING (each room may have one or more bookings, same as you have done).  As for the "room types", I would use an ARC ie an exclusive OR (XOR).  The reasoning behind it: each room is either equipped as STANDARD room (with all the necessary attributes) or it has the EXECUTIVE "package" (including all attributes that you need). 

There is NO need to draw (a) relationship(s) between STANDARD/EXECUTIVE and BOOKING.
A ROOM gets booked (and each room is either a STANDARD or an EXECUTIVE, but this gets recorded in the respective attribute/column -> see the diagrams (ERD above, relational model below). 



If it is possible that a single (unique) booking ID can be used to book several rooms, then you'd have a M:M relationship between ROOM and BOOKING.  (Which would require an intersection.)

(As for the implementation of the XOR - which comes much much later: you can use a CHECK constraint in the ROOMS table in order to force the room to be either "standard" or "executive".)