Database design ER建模问题

我有以下问题：

仅使用二进制关系，为以下描述构建实体关系图。包括实体标签、主键字段、关系标签和关系上的多重性

“一家公司经营几家汽车修理和维修车库，每个车库都有自己的唯一号码（gargNo）。当车主联系车库时，他们的详细信息会被记录下来，并被分配给车主号码。他们的汽车也在该车库登记，并被分配了一个参考号码（carNo）。车主可能拥有一辆或多辆汽车，但一辆汽车只能在一个车库登记。当一辆汽车被登记进车库时，会为其制定一个服务计划。该服务计划可能是特定汽车的唯一服务计划（例如，治愈吱吱作响的挡风玻璃雨刮器），也可能是用于许多汽车的服务计划（例如，标准60000英里服务）.任何维修计划都可以包括一个或多个操作（更换机油、拆卸刮水器电机等）。维修计划中的每种操作都有一个唯一的编号（操作编号）

我的答案是：

对于所有的数据库老手来说，你觉得这样可以吗

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

不是作业

---

编辑-为什么人们总是编辑帖子而不做任何更改？

完全基于给定的要求，忽略所有可能的现实复杂情况（例如车主将汽车服务从一个车库搬到另一个车库时发生的情况）：

我不想谈公司。只有一家提到过，没有迹象表明我们正在记录多家公司的数据

车主和车库之间的关系是通过汽车来实现的。车主和车库之间没有直接的关系。（给定多个车库，确保给定的多个车主在系统中出现一次将很难实施。）

汽车和车库之间的关系可能应该是“登记在”。严格的阅读意味着汽车在与车主联系时与车库联系，而不是在引入服务时

您需要实体ServicePlanType[SPT]。大多数SPT是预定义的，多辆车将使用给定的SPT（60000英里调整）。如果需要，将在需要时添加额外的SPT。可以对“标准”和“特殊”子类型进行论证，但我认为它们非常相似（基于操作）这是不需要的。然后：

• 服务计划涉及一辆车和一种服务计划类型
• 服务计划与一种服务计划类型相关
• 服务计划类型与零个或多个服务计划（标准计划列表）相关
• 服务计划类型与一个或多个操作相关（必须定义所有操作）

操作可能与零个或多个服务计划类型相关。鉴于需要临时服务计划，可能需要最初不属于任何给定集合服务计划的操作。（这或他们根据需要添加，这可能是可以接受的。我妹妹的沙鼠在放学回家的路上逃走了一次，他们不得不拆开汽车的一部分将其取出。不收费，可能他们的数据库中没有“提取沙鼠”。（我不是编造出来的。）

我不会将服务计划类型或运营与车库联系起来。假设公司的一个车库可以做到这一点，那么他们都应该能够做到，即使是临时车库

---

您不需要将服务计划与车库关联，因为服务计划所针对的汽车与车库相关。因此，在实际实施时，这样做可能会很好。此外，如果一辆汽车后来被带入第二个车库，则汽车与车库的关系会发生变化，如果没有服务计划与车库的关系，你不知道是谁做了早期的工作。我想你可能会想模拟从汽车到服务到车库的计划，但他们明确指出了“从汽车到车库”。提出这些问题，看看企业主怎么说。

根据问题陈述，我得出以下结论：

为了简单起见，我使用了地址、所有者详细信息等通用字段

编辑：服务计划和操作之间的多对多解释：

“换油”操作是“30K保养”、“60K保养”和“换油”服务计划的一部分

当然，“30K保养”和“60K保养”的维修计划有多个操作（换油、加注制动液、检查轮胎压力、平衡和旋转轮胎）

因此，服务计划和运营之间的关系是一种多对多关系

---

此结构是一个模板，可以应用于VehicleService实例。

我忽略了服务计划和操作之间需要多对多。但我仍然认为需要某种服务计划模板，允许服务计划重用，而不是每个新VehicleService条目都重新定义。