如果不知道确切和完整的需求，我们就无法设计完整的数据模型。让我们假设以下业务规则，它基于您的问题。

• 每个客户可以申请一个或多个房间。
• 每个房间可由一位客户申请
• 每个管理员可以分配一个或多个房间。
• 每个房间必须由一名管理员分配。
• 每个房间必须属于一种房间类型。
• 每个房间类型可以包含一个或多个房间。
• 每个预订必须属于一个日期。
• 每个日期可以包含一个或多个预订。
• 每个房间类型可以包含一个或多个租金。
• 每个租金必须属于一种房型。
• 每个预订必须包括一个或多个房间。
• 每个房间可以包含在一个预订中。
• 每个客户可以持有一个或多个预订。
• 每个预订必须属于一个客户。
• 每个租金可以包含在一个或多个账单中。
• 每份账单必须包括一份租金。
• 每个账单支付必须包括一种支付类型。
• 每个支付类型可以包含一个或多个账单支付。
• 每个日期可以包含一个或多个账单支付。
• 每笔账单支付必须属于一个日期。
• 每个房间可以被评为一个或多个房间评级。
• 每个房间评级必须属于一个房间。
• 每个评级可以包含一个或多个房间评级。
• 每个房间等级必须属于一个等级。

基于上述规则，我们设计了以下数据模型。

该模型是酒店预订系统的一个子集。经过规范化过程（查看我的博客），您将拥有更详细和完整的模型。

在上述模型中，房间租金是根据单人间、双人间、家庭间或会议厅等房间类型计算的，而不是房间内的人数。

并且房间租金会不时更改，因此我们已经包含了开始日期和迄今为止的房间租金历史记录。客户也可以使用多种支付类型，如信用卡、借记卡、现金支付，因此我们包括支付类型实体。

该模型基于假设。我希望这个模型能以某种方式帮助你。

谢谢你。

通过使用描述性名称和标题，从您的查询和设计中消除猜测。 Rooms有People，但我认为这实际上类似于Capacityor Room Size。People这样可以避免与 中已使用的列混淆Forms。当然，这也可以改进......NumberOfGuests现在可能会为您提供更多信息，以及稍后查询您的数据库的任何人。我会仔细检查所有列名和表名，以确保它们简洁明了。

房间没有自动增量，可能是因为您希望使用整数来标识房间。这可能有效，但您可以通过将业务/用户房间标识与数据库逻辑分开来避免问题。当 13 号房间发生可怕的谋杀，使其无法使用时，新经理丝毫不迷信或关心这些事情，将 14 楼的扫帚柜转到 13 号房间，因为它足够大，坦率地说，我们酒店的质量正在下降.... 你完蛋了。使用与您的房间名称分开的数据库密钥，您可以维护所有记录和数据库完整性以及发生重大更改的事实（我们应该支持哪些其他类型的更改跟踪和详细信息？）。Room 13 | RoomPK 13知道是房间 13 但实际上现在Room 13 | RoomPK 132也可以录制。当有人住在 13 号房间时，如果有人试图起诉您，这很重要，整个案件取决于他们住在 13号房间。对不起，您的酒店有很多问题。

最后一个问题是交易在哪里？我希望表单还需要对 Bill(s?) 和 Rooms(s?) 有 FK。人们需要从某个地方签入和签出，我们需要专门针对这种情况和关联向他们收费。一个家庭可能会在两天内得到两个房间，然后早上退房，晚上再入住。然后他们坚持只收到一张账单……或者有人住两晚需要两张账单，因为有两种不同的付款方式（信用卡、现金、工作、个人）。您现在可能需要查找表来支持复杂的计费和预订。人们分摊账单，换房间，并希望再次返回——所有这些你都需要支持。

在设计酒店管理系统时，我们将关注以下一组要求：

系统应支持标准、豪华、家庭套房等不同房型的预订。

客人应该能够搜索房间库存并预订任何可用的房间。

系统应该能够检索信息，例如谁预订了特定房间，或特定客户预订了哪些房间。

如果取消发生在入住日期前 24 小时之前，系统应允许客户取消预订并向他们提供全额退款。

当预订接近入住或退房日期时，系统应该能够发送通知。

系统应维护房间内务日志以跟踪所有内务任务。

任何客户都应该能够添加客房服务和食品。客户可以要求不同的设施。客户应该能够通过信用卡、支票或现金支付账单。

这是酒店预订系统的类图。希望这可以帮助。