alex228,
Вам надо разобраться с сущностями, которые вы желаете отобразить в БД, и их взаимной приоритетностью (это первое, с чего надо начинать). С моей точки зрения, главная сущность в вашей задаче - это комната. Потому что она единственная, которая является постоянной (почти константой). Все остальные сущности вертятся вокруг неё. А у вас в центре почему-то заявка (application).

Я бы делал так:

rooms: id.
apllications: id, Room_id, ActualRoom_id (?), User_id
invoices: id, Room_id, User_id, Application_id
users: id, UserRole

Открытый вопрос - связывать ли заявку со счётом и как это делать: а) не каждая заявка превращается в счёт (например, клиент отвалился); б) не всякая заявка превращается в счёт с тем же id комнаты. Т.е. де-факто у нас заявки и счета могут быть по бизнес-процессу только частично связаны друг с другом.
Решение зависит от того, надо вам фиксировать этот нюанс или нет. Если нет, тогда можно оставить как есть. Если надо (что, мне кажется, грамотнее), тогда в таблицу applications можно добавить еще одно поле ActualRoom_id. В заполненной пользователем заявке устанавливаете Room_id = ActualRoom_id, если комната де-факто будет другая, не та, которую выбрал клиент, админ оставляет Room_id как есть, а в ActualRoom_id записывает то, что есть в наличии, и на основании скорректированной заявки выставляет счёт, куда уже идёт ActualRoom_id. Так мы достигаем несколько целей: в примитивном виде храним историю (заказали одно, по факту другое), можем уведомлять клиента об изменениях в заявке, т.е. клиент видит, что в его заявке изменения на другую комнату, и у нас счёт и заявка всегда содержат взаимно корректную информацию.

В идеале да, но если представить себе, что ситуация может меняться уже после бронирования, например, клиент был один, а потом их стало двое или трое. Это потребует разработку механизма отмены, перезаказа и т.п. К тому же, ситуация может измениться и на стороне гостиницы, например, комната внезапно стала нежилой из-за протечки, отсутствия электричества, ремонта и т.п., что бывает не так уж и редко. И необходимо принудительно менять размещение с уведомлением клиента.
Тем не менее, система с управлением заявкой в обе стороны (админом и клиентом) предпочтительнее, но она требует более высокой квалификации разработчика. Пока что БД автора выглядит как учебный проект.