概念建模方案

Question

我是数据库设计的新手，我一直在练习尽可能多的问题。我碰巧碰到了下面的问题（不，这不是我的任务！），根据我的理解，我创建了附加的概念模型。模型中缺少一些信息，因为根据要求，我不清楚它们应该添加到哪里。我突出了我怀疑的界限。

  

    

您已被分配任务来设计数据库模式，该模式捕获设施审查服务所需的信息，包括住宿，餐馆和计划旅行等设施。     关于住宿，服务保留有关姓名，地址，住宿类型的信息。住宿类型可以是酒店，旅馆或床和早餐。我们还需要姓名和地址。 还有一套可选设施（应单独列出），例如房间类型（单人，双人或更多人），房间内有电视，浴室等。 / em> 多个设施可适用于同一地点。 还可以指定每人每晚（在宿舍）或每间客房（酒店，住宿和早餐;因此，视住宿类型而定）的费用。
    对于吃饭的地方，我们有名称和地址（独特且始终可用）。他们可能是餐馆，酒吧，酒吧，小酒馆和自助服务。 应该指定菜肴的种类，每餐的平均成本（分为4种可能的成本水平），每日时间表（由开放和关闭时间组成）以及可选的一周停止日期（一天或多天）。     关于旅行，我们想要指定景点的名称列表（以及相应的地址，如果有的话）。对于每个旅行景点，我们都有游客参观的日期间隔。     每个客户都可以在每个地方（住宿或吃饭但不适合旅游）的自由文本中留下评论，指定他/她的昵称（对所有客户都是唯一的），访问日期（或者日历间隔）由两个日期指定）和整数分数（从0到5）。每个客户都可以在同一个地方多次访问并留下评论。     绘制数据库概念设计的ER图。

  

这就是我提出的： Conceptual Model

图像具有我能想到的模型。我的怀疑是：

1）我的方法是否正确使用如此多的概括？还有其他办法吗？

2）在上面的描述中，第一句用斜体和粗体表示有一些“可选的设施”。是否应将这些属性添加到酒店，旅馆和B＆amp; B实体或广义住宿实体？

3）在突出显示的第二句中，是否应该像我所做的那样将费用加到酒店，旅馆和B＆amp; B？否则，我该如何进行建模呢？

4）在第三个突出显示的句子中，是否应在每种类型的餐馆下列出指定的属性，还是应将它们添加到广义实体Eatery中？

非常感谢您的帮助！

Answer 1

  

我的方法是否正确使用如此多的概括？还有其他办法吗？

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

  

在上面的描述中，第一句用斜体和粗体表示有一些“可选的设施”。是否应将这些属性添加到酒店，旅馆和B＆amp; B实体或广义住宿实体？

这听起来像是一般要求，我会将其与住宿联系起来。

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

  

在突出显示的第二句中，是否应该像我所做的那样将费用加到酒店，旅馆和B＆amp; B？否则，我该如何进行建模呢？

您可以按照自己的方式完成，或者向住宿添加费用属性（以及每个人/房间指示符）。

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

向住宿添加成本属性具有类似的气味，将每个房间的成本与单个属性中的每人成本相结合。不过，我会考虑它是否可以消除一组子类型 - 如果我们没有特定于子类型的属性，关系或约束，则可以通过属性指示类型，从而减少显式建模每个子类型的需要。

  

在第三个突出显示的句子中，是否应在每种类型的餐馆下列出指定的属性，还是应将它们添加到广义实体Eatery中？

我认为没有理由为每个餐馆单独列出它。所有子类型共有的属性，关系和约束应与超类型相关联。

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

一些注意事项：

• 我将房间设施重新命名为功能
• 住宿和餐馆是设施的可选不相交的子类型。这意味着我们可以拥有不属于任何一种子类型的设施，这使我能够使用相同的结构处理其他类型的旅游景点的评论。
• 访问是一种三元关系，由用户，旅行和设施决定。因此，每次访问都必须属于旅行，即使它只是一次访问旅行。从好的方面来说，多个用户可以参加同一次旅行。
• 用户可以在不同的旅程中多次访问工厂，但每次旅行不得超过一次。我们可以将访问从关系转换为具有代理键的实体来克服这个问题。

我希望这会有所帮助，请告诉我是否应该澄清一切。