JongShin, если это схема БД, то на мой взгляд не хватает:
1. Заселение желательно разделить на две сущности:
1.1. Событие заселение
1.2. Список заселенных клиентов
Как распределятся между ними свойства, указанные на схеме (дата заселения/оплата/ИД сотрудника и т.п.) - сильно зависит от поставленной задачи и существующих процессов в гостинице.

Оплата - вообще отдельная сущность, т.к. может проходить в несколько этапов как по одному номеру, так и одной "платежкой" вся гостиница может быть выкуплена, при этом

2. в Номера "убирать" свойство - стоимость, имхо, не хорошо. Лучше сформировать таблицу Прайс-листов, которые будут оперировать понятиями ИД_номера/сезон/акции/скидки и итоговой стоимостью за указанный номер.

3. Клиенты у вас планируются только физические лица? Есть ощущение, что периодически гостиницы сталкиваются с юридическими лицами, с которыми идет взаиморасчет по единому счету, в том числе периодическая постоплата. При этом Юридические лица обычно фиксируют список сотрудников, которые могут использовать "общий" договор.

4. Номерам не хватает, на мой взгляд, таблицы статусов, т.к. номер может в каждый момент времени быть, как минимум:
* на ремонте
* забронирован
* занят
* свободен
* освобожден/готов к уборке
* убираться Cleaning managerom
и в зависимости от указанного текущего статуса возможны те или иные кейсы по его использованию.

Далее уже надо будет новую схему смотреть.