注册
登录
概念模型
概念建模场景
返回
概念建模场景
作者:
春风助手
发布时间:
2024-07-20 10:35:56 (7天前)
<p>我是数据库设计的新手，我一直在练习尽可能多的问题。我碰巧遇到了以下问题（不，这不是我的任务！），据我所知，我创建了所附的概念模型。该模型中缺少一些信息，因为从需求来看，我不清楚应该在哪里添加它们。我已经强调了我怀疑的内容。</p><p>您已分配了一项任务，以设计一个数据库架构，该架构可捕获为游客提供的设施检查服务，住宿，餐厅和计划行程之类的设施所需的信息。关于住宿，服务保留有关住宿的名称，地址和种类的信息。住宿类型可以是酒店，旅馆或住宿加早餐旅馆。我们还需要名称和地址。还有一组可选的设施（应单独列出），例如房间的类型（单人，双人间或供更多人使用），房间中有电视，浴室等。可以使用多个设施到同一个地方。还有每晚的费用，可以指定每人（在旅馆中）或每间客房（在酒店，床和早餐；因此，取决于住宿类型）。<br/>对于吃饭的地方，我们有名称和地址（唯一且始终可用）。它们可能是餐馆，酒吧，酒馆，小酒馆和自助服务。应该指定美食的种类，每餐平均费用（分为4种可能的费用水平），每日时间表（由营业时间和营业时间组成），还可以选择一周中的停顿天（一天或多天） 。 关于旅行，我们要指定景点名称列表（以及相应的地址，如果有的话）。对于每个旅行景点，我们都有游客参观的日期间隔。每个客户都可以在每个地方（住宿或就餐场所，而不是旅游行程）的自由文本中留下评论，并指定他/她的昵称（这对所有客户而言都是唯一的），访问日期（或日历间隔）由两个日期指定）和一个整数分数（从0到5）。每个客户可以多次访问同一地点并留下评论。绘制ER图以进行数据库的概念设计。</p><p>这是我想出的： 概念模型</p><p>该图像具有我能想到的模型。我的怀疑是：</p><p>1）我的方法使用这么多概括是否正确？还有其他办法吗？</p><p>2）在上面的描述中，第一句用斜体和粗体表示存在某些“可选的功能集”。是否应将这些属性添加到酒店，旅馆和B＆B实体或广义住宿实体？</p><p>3）在突出显示的第二句话中，是否应该像我一样将费用添加到酒店，旅馆和B＆B？否则，我应该如何进行建模？</p><p>4）在突出显示的第三句中，应将指定的属性列出在每种餐馆的下面，还是应将它们添加到广义实体Eatery？</p><p>非常感谢您的事先帮助！</p>
收藏
举报
2 条回复
1#
回复此人
只怕再见是故人
|
2020-08-11 16-06
我的方法使用这么多概括是否正确？还有其他办法吗？ 当然还有其他方法。泛化没有什么错，尽管在一个模型中很少看到泛化。在这种情况下，这并不意味着它的错误，对与错取决于您的模型代表业务需求的程度。 在上面的描述中，第一句用斜体和粗体表示存在某些“可选的功能集”。是否应将这些属性添加到酒店，旅馆和B＆B实体或广义住宿实体？ 听起来像是一项一般性要求，我将其与“住宿”相关联。 请注意，在给定场景中，“设施”有两种用法-可以访问/查看的地方以及房间的特征。我建议重命名其中一项以避免混淆。 在突出显示的第二句中，是否应该像我一样将费用添加到酒店，旅馆和B＆B？否则，我应该如何进行建模？ 您可以按照自己的方式进行操作，也可以在“住宿”中添加费用属性（以及每人/房间指示器）。 您应避免在属性中混用域。我的意思是，所有可能的值应为同一类型，并且在逻辑上可以互换。一种常见情况是在一个属性或EAV表中的value列中混合使用不同货币的值。这样的设计倾向于增加复杂度。 在住宿中添加成本属性具有类似的味道，将每个房间的成本和人均成本合并在一个属性中。但是，如果可以消除一组子类型，我会考虑-如果我们没有特定于子类型的属性，关系或约束，则类型可以由属性表示，从而减少了对每个子类型进行显式建模的需要。 在突出显示的第三句中，应将指定的属性列出在每种餐厅的下面，还是应将它们添加到广义实体Eatery？ 我认为没有理由为每个餐厅单独列出它。所有子类型共有的属性，关系和约束应与超类型相关联。 为了进行比较，这是我的模型。我是在看您之前做过的，因此采取了非常不同的方法。 设施评论ERD 一些注意事项： 我将房间设施重命名为功能 住宿和小餐馆是设施的可选不连贯子类型。这意味着我们可以拥有不属于任何一个子类型的设施，从而使我能够使用相同的结构来处理其他类型的旅游景点。 访问是一种三元关系，由用户，旅行和设施确定。因此，即使只是一次访问，每次访问也必须属于一次旅行。从正面看，多个用户可以参与同一行程。 用户可以在不同的行程中多次访问设施，但每次行程不能超过一次。我们可以使用代理键将Visit从关系转换为实体，以克服这一问题。 希望对您有所帮助，请让我知道是否需要澄清。
编辑
登录
后才能参与评论
