Question: I plan on building a web based room booking application for meeting rooms at a company. The requirements are not set in stone and are pretty much left to me, as long as these core ones are met:

1. Users can view monthly schedule for meeting room, so see what days and times there are bookings for a particular room.
2. Users can book a meeting room
3. Users can edit,delete a booking once made.
4. Receptionists have power to cancel bookings, even though they were not the ones that made them.

If I have missed any obvious ones, please point them out.

So with the above in mind, I have come up with the following ERD.

![erd room booking](https://i.stack.imgur.com/xLDZs.jpg)

Can you see any obvious issues with the above ERD? I have gone through the above scenarios / requirements, and I believe the above design satisfies them all, but it is possible that I am very much mistaken (has happened before).

Any help and feedback would be greatly appreciated.

Answer: 
How do you know how long a room is booked for? Your model indicates when a booking starts, but when does it end?

Also, your ERD shows foreign keys from `BOOKING` to `USER` and `ROOM` but these columns aren't acknowledged in your `BOOKING` table. Some other answers have interpreted that as the columns being missing. You should be explicit in your diagram to avoid confusion (or add the FK columns if you missed them!)
I agree with Wiggler Jtag's recommendation. Here's why: 

Describe the relationship between `USER` and `ROOM`. If it is "a user can have zero, one, or more rooms booked" then you have a one to many relationship.

Describe the relationship between `ROOM` and `USER`. If it is "a room can have zero, one, or more bookings by a user" then this is also a one to many relationship.

Using normalization, you would define an intersection table. You have this defined as `BOOKING`. `BOOKING` should contain the PKs (primary keys) from `USER` and `ROOM`. PKs should be unique. The `BOOKING` entity would have attributes `USER_ID`, `ROOM_ID`, `DATETIME`, and `TITLE`. 

If you wish to ensure that only one USER can book a ROOM for a particular `DATETIME`, then you can add a unique concatenated index on `BOOKING` of `ROOM_ID`, `DATETIME`. This will ensure that there will be only one row for a room at a particular time. 

Primary index (or unique index) on the `PKs` of `USER` and `ROOM` will also ensure that you don't have more than one row per user or one row per room.