gpt4 book ai didi

database-design - ER 建模问题

转载 作者:行者123 更新时间:2023-12-04 20:46:09 27 4
gpt4 key购买 nike

我有以下问题:

仅使用二元关系,构建实体关系图用于以下描述。包括实体标签、主键字段、关系标签和关系的多重性。

“一家公司经营着几个汽车维修和服务车库,每个车库都有自己的唯一编号 (gargNo)。当车主联系车库时,他们的详细信息会被记录下来并被分配一个 ownerNo。他们的汽车也在该车库注册,并且是分配一个引用编号(carNo)。车主可以拥有一辆或多辆汽车,但一辆汽车只能在一个车库登记。当汽车被预订到车库时,会为其制定服务计划。服务计划可以对于特定的汽车是独一无二的(例如,治疗吱吱作响的挡风玻璃刮水器),或者它可以用于许多汽车(例如,标准的 60000 英里服务)。任何服务计划都可以包含一个或多个操作(换油、拆解雨刮器电机等)服务计划中的每种操作类型都有一个唯一编号(operationNo)。

这是我的回答:

enter image description here

对于所有数据库老手来说,这对您来说是否合适?

此外,任何其他意见反馈将不胜感激...

不是家庭作业

编辑 - 为什么人们不断编辑帖子但不做任何更改?

最佳答案

完全基于给定的要求,不考虑所有可能的现实世界的复杂性(例如当车主将他们的汽车服务从一个车库转移到另一个车库时会发生什么):

我会离开公司。只有一个曾经提到过,并且没有迹象表明我们正在为多家公司记录数据。

车主和车库之间的关系是通过汽车。车主和车库之间没有直接关系。 (给定多个车库,确保给定的多车主在系统中出现一次将很难执行。)

汽车和车库之间的关系或许应该“注册于”。严格的解读意味着汽车在与车主联系时与车库相关联,而不是在进行维修时。

您需要实体服务计划类型 [SPT]。大多数 SPT 是预定义的,多辆汽车将使用给定的 SPT(60,000 英里调整)。如果需要,将在何时以及根据需要添加额外的 SPT。可以就“标准”与“临时”子类型进行争论,但我认为它们非常相似(基于操作),因此不需要这样做。然后:

  • 服务计划涉及一辆车,一种服务计划类型
  • 服务计划涉及一种服务计划类型
  • 服务计划类型涉及零个或多个服务计划(标准计划列表)
  • 服务计划类型与一项或多项操作有关(必须定义所有操作)

  • 操作可能涉及零个或多个服务计划类型。鉴于需要临时服务计划,可能需要最初不属于任何给定服务计划的操作。 (或者他们根据需要添加,这可能是可以接受的。我姐姐的沙鼠在放学回家的路上逃过一次,他们不得不拆开汽车的一部分才能把它拿出来。不收费,也许他们没有在他们的数据库中“提取沙鼠”。)(我不是编造的。)

    我不会将服务计划类型或操作与车库联系起来。想必如果公司的一个车库能做到,他们应该都能做到,即使是临时的。

    您不需要将维修计划与车库相关联,因为维修计划所针对的汽车与车库相关。话虽如此,当需要进行物理实现时,这样做可能会很好。此外,如果一辆车后来被带到第二个车库,那么汽车与车库的关系就会发生变化,如果没有车库关系的服务计划,你就会忘记谁做了早期的工作。正确地,我认为您想将 owenr 建模为汽车到车库的服务计划,但他们特别说明了“汽车到车库”。提出这些问题,看看企业主怎么说。

    关于database-design - ER 建模问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5778628/

    27 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com