Database design 概念建模场景

我对数据库设计非常陌生，我一直在练习尽可能多的问题。我碰巧遇到了下面的问题（不，这不是我的作业！），根据我的理解，我创建了附带的概念模型。模型中缺少一些信息，因为从需求来看，我不清楚应该在哪里添加它们。我强调了我有疑问的行

您已被分配任务，设计一个数据库模式，该模式捕获为游客提供的设施审查服务所需的信息，如住宿、餐厅和计划行程。 关于住宿，该服务保留有关姓名、地址和住宿种类的信息。住宿类型可以是酒店、招待所或床和早餐。我们还需要姓名和地址还有一套可选的设施（应单独列出），如房间类型（单人房、双人房或多人房）、房间内有电视、浴室等。同一地点可使用多个设施还有每晚的费用，可以指定为每人（在旅馆）或每个房间（在酒店、床和早餐；因此，取决于住宿类型）。
对于吃饭的地方，我们有名称和地址（唯一且始终可用）。它们可以是餐馆、酒吧、酒吧、酒馆和自助服务应指定烹饪种类、每顿饭的平均成本（分为4个可能的成本水平）、每日时间表（由开放和关闭时间组成）以及一周中的休息日（一天或多天）。 关于这次旅行，我们想详细列出景点的名称（以及相应的地址，如果有的话）。对于每个旅游景点，我们都有游客参观的时间间隔。 每位客户可以为每个地点（住宿或就餐地点，但不适用于旅游旅行）留下免费文本评论，并指定其昵称（对所有客户来说都是唯一的）、访问日期（或由两个日期指定的日历间隔）和整数分（从0到5）。每个客户都可以多次访问同一地点并留下评论。 绘制数据库概念设计的ER图

这就是我想到的：

这张照片是我能想到的模型。我的疑问是：

1） 我使用这么多概括的方法正确吗？还有别的办法吗

2） 在上面的描述中，斜体和粗体的第一句表示存在某些“可选设施集”。这些属性应该添加到酒店、招待所和B&B实体中，还是添加到一般住宿实体中

3） 在突出显示的第二句话中，是否应该像我所做的那样将成本计入酒店、招待所和B&B？否则，我应该如何进行建模

4） 在第三个突出显示的句子中，指定的属性应该列在每种类型的餐厅下，还是应该添加到通用实体餐厅中

非常感谢您的帮助

我使用这么多概括的方法正确吗？还有别的办法吗

当然还有其他方法。泛化并没有什么错，尽管在一个模型中很少看到如此多的泛化。这并不意味着它是错的，在这种情况下，对与错取决于您的模型在多大程度上代表了业务需求

在上面的描述中，斜体和粗体的第一句表示存在某些“可选设施集”。这些属性应该添加到酒店、招待所和B&B实体中，还是添加到一般住宿实体中

这听起来像是一个一般要求，我会把它与住宿联系起来

请注意，在给定场景中，“设施”有两种用法-用于可访问/查看的地方，以及用于房间的功能。我建议将其中一个术语重命名，以避免混淆

在突出显示的第二句话中，是否应该像我所做的那样将成本计入酒店、招待所和B&B？否则，我应该如何进行建模

你可以按照你的方式来做，或者在住宿中添加一个成本属性（以及每个人/房间的指标）

您应该尽量避免在属性中混合域。我的意思是，所有可能的值都应该是相同类型的，并且在逻辑上可以互换。一种常见情况是在一个属性或EAV表中的值列中混合不同货币的值。这样的设计往往会增加复杂性

将“成本”属性添加到“住宿”中也有类似的味道，将每个房间的成本和每个人的成本合并到一个属性中。不过，如果可以消除一个子类型，我会考虑它。如果我们没有子类型特定的属性、关系或约束，类型可以由属性来表示，从而减少了对每个子类型的显式建模的需要。 在第三个突出显示的句子中，指定的属性应该列在每种类型的餐厅下，还是应该添加到通用实体餐厅中

我看不出有什么理由为每家餐馆单独列出。所有子类型共有的属性、关系和约束应与超类型关联

作为比较，这是我的模型。我是在看你之前做的，所以它采用了一种非常不同的方法

一些注意事项：

• 我将房间设施重命名为功能
• 住宿和餐饮是可选的不相交的设施子类型。这意味着我们可以拥有不属于任何子类型的设施，允许我使用相同的结构处理其他类型旅游景点的评论
• 访问是一种三元关系