ER 建模问题
我有以下问题：
仅使用二元关系，为以下描述构建实体关系图。包括实体标签、主键字段、关系标签和关系的多重性。
“一家公司经营多个汽车维修和服务车库，每个车库都有自己的唯一编号 (gargNo)。当车主联系车库时，他们的详细信息会被记录，并为他们分配一个车主号。他们的汽车也在该车库注册，并且车主可以拥有一辆或多辆汽车，但一辆车只能在一个车库登记。当一辆车被预订到车库时，可以为其制定一份服务计划。对于特定的汽车来说是唯一的（例如，治疗发出吱吱声的挡风玻璃刮水器），或者它可以是用于许多汽车的（例如，标准的 60000 英里服务） 任何服务计划都可以包含一项或多项操作（更换机油、拆卸发动机）。雨刮器电机等）。服务计划中的每种操作都有一个唯一的编号（操作编号）：
<
img src="https://i.sstatic.net/ijdsc.gif" alt="enter图片描述在这里>
对于所有数据库老手来说，这对你来说合适吗？
此外，任何其他评论反馈将不胜感激...
不是家庭作业
编辑 - 为什么人们不断编辑帖子但不做任何更改？
I have the following question:
Using only binary relationships, construct an entity relationship diagram for the following description. Include entity labels, primary key fields, relationship labels, and the multiplicities on relationships.
"A company runs several car repair and service garages, each having its own unique number (gargNo). When a car owner contacts a garage, their details are recorded and they are assigned an ownerNo. Their car is also registered with that garage and is assigned a reference number (carNo). An owner may own one or more cars, but a car can only be registered with one garage. When a car is booked into a garage, a service plan is drawn up for it. The service plan may be unique for a particular car (eg, cure squeaking windscreen wipers) or it may be one used for many cars (eg, a standard 60000 mile service). Any service plan can consist of one or more operations (change the oil, dismantle the wiper motor, etc). Each type of operation on a service plan has a unique number (operationNo).
This is my answer:
For all Database veterans, does this look ok to you?
Also any other comments feedback would be appreciated...
NOT HOMEWORK
EDIT - Why do people keep editing posts but making no changes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
完全基于给出的要求，忽略现实世界中所有可能的复杂情况（例如当车主将汽车服务从一个车库转移到另一个车库时会发生什么）：
我会排除公司。只有提到的一家公司，没有迹象表明我们正在为多家公司记录数据。
车主和车库之间的关系是通过汽车建立的。车主和车库之间没有直接关系。 （给定多个车库，确保给定的多车所有者在系统中出现一次将很难执行。）
汽车和车库之间的关系也许应该“注册”。严格的解读意味着汽车是在车主联系时与车库关联的，而不是在送去维修时关联的。
您需要实体ServicePlanType [SPT]。大多数 SPT 都是预先定义的，多辆汽车将使用给定的 SPT（60,000 英里调整）。如果需要的话，将会添加额外的 SPT。可以对“标准”与“临时”子类型进行争论，但我认为它们非常相似（基于操作），因此不需要这样做。那么：
可能与零个或多个服务计划类型相关。考虑到对临时服务计划的需要，可能需要最初不属于任何给定设定服务计划的操作。 （那个或者根据需要添加，这可能是可以接受的。我姐姐的沙鼠有一次在放学回家的路上逃跑了，他们不得不拆开部分汽车才能把它拿出来。不收费，也许他们没有在他们的数据库中“提取沙鼠”。）（这不是我编造的。）
我不会将服务计划类型或操作与车库联系起来。想必如果公司的一个车库能做到，那么他们都应该能做到，即使是临时的。
您不需要将服务计划与车库相关联，因为服务计划所针对的汽车与车库相关联。话虽如此，在实际实施时这样做可能会更好。此外，如果稍后将汽车放入第二个车库，则汽车与车库的关系会发生变化，并且如果没有服务计划与车库的关系，您将无法跟踪谁做了早期的工作。正确地说，我认为您想要对汽车到车库的服务计划进行建模，但他们特别说明了“汽车到车库”。提出这些问题，看看企业主怎么说。
Based solely and entirely on the requirements given, disregarding all possible real-world complications (such as what happens when an owner moves their car service from one garage to another):
I would leave out company. There’s only the one ever mentioned, and no indication that we are recording data for multiple companies.
The relationship between car owner and garage is through the car. There is no direct relationship between car owner and garage. (Given multiple garages, ensuring a given multiple-car owner appears once in the system is going to be tricky to enforce.)
The relationship between car and garage should perhaps be “registered at”. A strict reading implies that the car gets associated with the garage upon owner contact, not upon bringing in for service.
You need entity ServicePlanType [SPT]. Most SPTs are pre-defined, and multiple cars would use a given SPT (60,000 mile tuneup). Additional SPTs would be added if, when, and as required. An argument could be made for “standard” vs. “ad hoc” subtyping, but I think they’d be so similar (based on Operations) that this isn’t called for. Then:
Operation may relate to zero or more service plan types. Given the need for ad hoc service plans, there may be a need for operations that do not initially belong to any given set service plan. (That or they get added as needed, which may be acceptable. My sister’s gerbil got escaped once on the way home from school, and they had to disassemble part of the car to get it out. No charge, maybe they didn’t have “extract gerbil” it in their database.) (I am so not making that up.)
I would not relate sevice plan type or operation with garage. Presumably if one garage of the company can do it, they should all be able to do it, even the ad hoc ones.
You do not need to relate service plan with garage, as the car the service plan is for is related with garage. With that said, it might be good to do so when it comes time for physical implementation. Also, if a car is later brought into a second garage the car-to-garage relationship changes, and without the service plan to garage relationship, you lose track of who did the earlier work. Properly, I’d think you’d want to model owenr to car to service plan to garage, but they specifically spelled out “car to garage”. Raise these questions, see what the business owner says.
根据问题陈述，我提出了以下内容：
我使用了地址、OwnerDetails 等通用字段等，为了简单起见。
编辑：服务计划和操作之间的多对多解释：
“换油”操作是“30K 维护”、“60K 维护”和“换油”服务计划的一部分。
当然，“30K保养”和“60K保养”的服务计划有多种操作（换油、加注制动液、检查轮胎压力、平衡和旋转轮胎）。
因此，Service Plan和Operation之间是多对多的关系。
该结构是一个模板，可以应用于 VehicleService 实例。
Based on the problem statement, I have come up with the following:
I used generic fields like Address, OwnerDetails, etc. for the sake of simplicity.
Edit: Many to Many between Service plan and Operation explained:
The Operation "Change Oil", is a part of the Service Plans "30K maintenance", "60K Maintenance" and "Oil change".
Of course, a Service plan for "30K maintenance" and "60K Maintenance" has multiple Operations (Change Oil, Refill Brake fluid, Check Tire Pressure, Balance and Rotate Tires).
Therefore, the relationship between Service Plan and Operation is a many-to-many relationship.
This structure is a template that can then be applied to a VehicleService instance.