Дизайн базы данных для бронирования нескольких номеров: один ко многим

Question

Первичные объекты: клиент гость бронирование RoomAssignment

Я хочу реализовать дизайн базы данных с множественным резервированием номеров. Сначала я хочу объяснить сначала концепцию:

1. Клиент - это тот, кто получает бронирование.
2. Клиент может иметь только 1 бронь за раз
3. Клиент может резервировать несколько номеров.

4. Гость - это тот, кто назначен в определенную комнату.

   Итак, для таблицы:

   Client (client_id(PK), Name)<br> Guest (guest_id(PK), Name)

   Reservation (reservation_id(PK), client_id(FK), roomAss_id(FK), checkInDate);
   RoomAssignment (roomAss_id(PK), guest_id(FK), roomno(FK));
   Room(room_id(PK), roomDetails);
   

// Проблема здесь в том, что я не знаю, как реализовать отношение 1 ко многим. Мое бронирование должно обрабатывать Muliple RoomAssignment? Или мое RoomAssignment будет обрабатывать несколько guest_id и roomno, а затем я передам 1 roomass_id в свою таблицу бронирования?

Спасибо, я действительно запутался в отношениях 1 со многими. Я надеюсь, что кто-то так любезен помочь, вместо того, чтобы давать мне отрицательные моменты Т_Т

Еще одна попытка:

Room(room_id(PK), roomDetails);
Client (client_id(PK), Name)
Guest (guest_id(PK), Name)
Reservation (reservation_id(PK), client_id(FK), checkInDate);
Booking(book_id(PK), reservation_id(FK), room_id(FK));
Lodging(lodge_id(PK), guest_id(FK), book_id(FK))

(Клиент, Комната, Гость уже заполнены), добавить Бронирование, добавить бронирование, добавить проживание

Это правильно ??

Answer 1

( Редактировать Изменил мое предложение, подумав об этом больше. Это более глубокая загадка, чем я думал вначале.)

Я бы предпочел, чтобы у Резервирования было многомного отношений (с помощью бриджа) с комнатами.Назовите эту таблицу с внешними ключами ReservationID и RoomID, что-то вроде.,, Бронирование .Может быть, вы можете придумать лучшее имя.Бронирование - это конкретный номер, который бронируется.Затем у меня была бы другая таблица-мост, представляющая отношения между гостем и бронированием.Вы можете назвать это Lodging .Жилье - это конкретный гость, которому назначено конкретное бронирование (забронированный номер).

Это изящная головоломка, которая у вас есть.Ключевым моментом является то, что у вас есть несколько конкретных вещей, которые существуют сами по себе и, очевидно, необходимы (бронь, номер, гость), но также есть и несколько других концепций, каждый из которых имеет свои атрибуты и проистекает из отношений между этими вещами.Если это будет правильно нормализовано, у вас может оказаться больше таблиц, чем вы предполагали.Не думайте, что это становится все сложнее.Наличие достаточного количества надлежащих таблиц - это то, что в конечном итоге упростит этот .Вот некоторые другие предложения:

• Потратьте время на имена каждой таблицы.Мои предложения выше довольно хороши, но вы, вероятно, можете их улучшить.Резервирование - это и отношение между другими вещами, но оно становится самим собой, по крайней мере, с одним внешним ключом на другой таблице.
• Вы должны быть в состоянии описать, что представляет запись в таблице.Если вы не можете этого сделать, то ваши столы отстой.Посмотрите выше, как я могу описать, что такое бронирование и проживание.В итоге ваш дизайн может отличаться, но, когда вы проводите мозговой штурм в разных таблицах, убедитесь, что вы можете описать, что на самом деле представляет собой запись в этой таблице.
• Подумайте о том, чтобы Guest и Client были из одной таблицы.Они оба "Контакты" на самом деле.Кто-то может быть гостем в один момент, но клиентом в следующем месяце.Вы можете добавить дополнительную таблицу данных (от одного до 0 или-1), если контакт является клиентом .Ваша система будет запрашивать основную контактную информацию только в том случае, если кто-то будет действовать как гость, но больше, если он действует в качестве клиента.