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

Первичные объекты: клиентское бронирование гостевого номера. Назначение комнаты

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

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

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

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

    Client (client_id(PK), Name)
    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 ко многим. Мое бронирование должно обрабатывать несколько назначений номеров? Или мой 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))

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

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


sql database-design one-to-many database-normalization normalization
person rj tubera    schedule 15.02.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

  • Потратьте время на названия каждой таблицы. Мои предложения выше довольно хороши, но вы, вероятно, можете их улучшить. Бронирование является как отношением между другими вещами, так и самим мышлением, по крайней мере, с одним внешним ключом в другой таблице.
  • Вы должны быть в состоянии описать, что представляет собой запись в таблице. Если вы не можете этого сделать, то ваши столы отстой. См. выше, как я могу описать, что такое бронирование и проживание. Ваш дизайн может в конечном итоге отличаться, но когда вы проводите мозговой штурм разных таблиц, убедитесь, что вы можете описать, что на самом деле представляет собой запись в этой таблице.
  • Подумайте о том, чтобы Гость и Клиент находились за одной и той же таблицей. Они оба "Контакты" на самом деле. Кто-то может быть гостем в какой-то момент, но клиентом в следующем месяце. У вас может быть дополнительная таблица данных (от 0 до 1), когда контакт является клиентом. Ваша система потребует только базовую контактную информацию, если кто-то собирается просто действовать как Гость, но больше, если он действует как Клиент.
person Patrick Karcher    schedule 15.02.2012
comment
Да, в каждой комнате должен быть зарегистрирован 1 гость. поэтому в 1 комнате должен быть 1 гость. - person rj tubera; 15.02.2012
comment
сэр, еще один вопрос, где мне взять reservation_id, потому что я планирую добавить резервирование в последнюю очередь. Мой заказ выглядит следующим образом: Комната (уже заполненная значениями/деталями и т. д.), Клиент, Гость, Назначение комнаты и Бронирование. Спасибо за ответы - person rj tubera; 15.02.2012
comment
Сэр, не могли бы вы, пожалуйста, показать его мне. Я не могу ясно понять. Будет лучше, если ты покажешь это, чтобы мне было легче. пожалуйста :))) - person rj tubera; 15.02.2012
comment
Рассмотрите возможность создания резервирования (большая часть его данных не заполнена) в начале процесса. Вы можете не запрашивать данные позже (номер лицензии, номерной знак, получают ли они скидку и т. д.), но запись, вероятно, следует создать заранее. Контакт (гость, клиент и т. д.), безусловно, может быть создан до резервирования, но резервирование должно предшествовать другим вещам. Не то чтобы человек, использующий программное обеспечение, даже знал, что создается резервирование. - person Patrick Karcher; 15.02.2012
comment
Сэр, значит ли это, что я добавлю бронирование перед бронированием и размещением? - person rj tubera; 15.02.2012
comment
Сэр, я отредактировал свое решение, это правильно? Кстати, сэр, я не могу объединить гостя и клиента, так как у них разные данные. В клиенте есть детали, которых у гостя нет. - person rj tubera; 15.02.2012
comment
Таблицы, которые вы добавили выше, верны, поскольку вы поняли мои идеи. Моя идея — хороший пример того, что может быть хорошо для вас, но я, конечно, не уверен, что это именно то, что вам нужно. К тому времени, когда вы закончите, вы, вероятно, получите что-то немного другое. /// Разделение Клиента и Гостя может быть правильным для вас, но рассмотрите таблицу Guest с каждым отдельным пользователем и таблицу Client с дополнительной информацией для гостей, которая на самом деле сделать резервацию. Итак, все являются как минимум Гостьями, но некоторые из них являются также Клиентами. Но да, ты понимаешь. - person Patrick Karcher; 15.02.2012