Схема взаимоотношений сущностей - Гостиница

Question

Я создаю ERD для отеля, и я новичок в реляционных базах данных. Я борюсь с отношениями и где связать сущности. Вот мое грубое заблуждение: Ссылка на изображение для ERD

Вопросы, которые у меня на уме:

Как оплачивается обслуживание номеров для оплаты через номер? Нужен ли мне объект доступности? Должен ли я связать номер или бронирование с счетом вместо гостей? Будут ли услуги бара прямо к чеку или счету? Должен ли я добавить roomType к объекту бронирования?

Вот описание, данное:

Предварительное исследование требований к системе выявило следующие факты:

• Номера пронумерованы от 101 до 359 (хотя их всего 20, они на 3 этажах)
• Некоторые номера доступны для инвалидов-колясочников, а другие - не
• Номера бывают трех типов:
  1. Одноместный - взимается по 40 фунтов стерлингов за ночь
  2. Двухместный - взимается по £ 52 за ночь
  3. Люкс (подходит для семьи из четырех человек) - плата составляет 95 фунтов стерлингов за ночь. •

С клиентов взимается плата за номер по стандартному тарифу, хотя ведется учет количества людей в номере

Клиентам присваивается уникальный «идентификатор клиента», а их информация в настоящее время хранится в картотеке

Клиенты могут заказать определенные предметы, которые могут быть списаны со своего номера в качестве дополнительных средств в их счете Они взимаются по стандартным ставкам следующим образом:

• Традиционный завтрак - взимается в £ 10
• Континентальный завтрак - 5 фунтов стерлингов
• Ужин - взимается 25 фунтов стерлингов с человека
• Диапазон закусок в баре - взимается в £ 15
• Обслуживание в номерах - плата за £ 30 •
  Клиенты могут покупать другие вещи, например, напитки в баре, но они оплачиваются индивидуально и не оплачиваются в номере клиента. В настоящее время в отеле Sunshine Coast используются предварительно напечатанные канцелярские товары, а сотрудники стойки регистрации выписывают счета клиентам, когда они уходят.

Answer 1

Пара вещей, которые я заметил:

• FloorNumber устанавливается дважды. В комнате Тип и комната. Он не должен быть установлен в roomType.
• Зачем ставить BookingID FK в номер? Запись о бронировании связана с комнатой через таблицу доступности. Бронирование не является атрибутом номера.
• roomType не требуется RoomNumber FK. Комната как тип. Типу нет комнаты.
• Так что для вашего ФК, спросите себя, какой объект имеет какой другой? Они не должны быть установлены в обоих направлениях.

Большинство ваших ERD имеет смысл, хотя roomServices находится не в нужном месте. Если вы связали это непосредственно с комнатой, как вы это сделали, как вы узнаете, что гость №1 в тот день в этой комнате что-то заказал? roomServices должен быть привязан к счету, как вы сделали для barServices. Таким образом, когда вы выставляете счет, вы получаете:

• детали бронирования
• Бар Услуги
• Помещения Услуги

Я бы строил roomServices с комнатным FK и связывал его с чеком через чек типа barServices. Также не стоит забывать, что у ваших roomServices есть тип, с разными ценами. Итак, еще одна столовая комната ServicesType. RoomService описывает один заказ на 1 вид услуг.

Я иду так:

• определить мои объекты (т.е. таблицы). Они должны представлять 1 и только 1 элемент в задаче.
• определить мои ссылки (т.е. отношения). В зависимости от типа отношения (1-1, 1-n, m-n) я использую FK или таблицу ссылок (я не помню официальное имя информатики, но нравится то, что вы сделали с доступностью).
• затем я определяю каждый атрибут, который имеют мои объекты (то есть строки в таблицах). Это когда я удостоверяюсь, что атрибут никогда не определен в более чем 1 таблице.
• тогда я пробую пару запросов в уме. Как: гость уходит, как я узнаю, за что ему нужно выставить счет? Гость заказывает ужин, я записываю его? ...