如何在有关汽车服务场景的实体关系图中对实体进行建模？

Question

我是一名初学者数据库设计师，想知道是否有人可以帮助我理解这一点。假设我们要设计一个系统，其中包含一个名为 Vehicle 的实体和另一个名为 Service 的实体。服务是维修/维护。

您如何看待以下关系的基数：

• 一辆车可以维修多次。
• 一项服务是为一辆车。

从汽车端来看，最小基数应该是 0 还是 1？

此外，服务涉及零件、人工和消耗品。

你会如何建模？作为一个独立的实体？或者在服务实体或汽车和服务之间的关系（交叉实体）的一部分？

Answer 1

一般建议：

当您开始学习如何对数据库建模时，最重要的经验法则之一是：对您的系统而言重要的每个有形事物都可能是一个实体类型。

这是开始任何逻辑数据库设计的好地方。如果您预先花一些时间考虑哪些事情对您的系统很重要，那么您就会为构建系统打下坚实的基础。与您的组织用来处理这些事情的业务流程和规则相比，您的组织关心的事情的变化频率要低得多。这就是实体数据模型如此重要的原因。

另一个重要的经验法则是：默认情况下对您的数据模型进行规范化，并且仅在您有（真正）充分的理由时才进行非规范化。 对于事务系统尤其如此。报告系统和数据仓库是另一回事。

具体答案：

基数：如果您考虑一下，很容易就会出现汽车永远无法维修（由您的商店）的情况。因此，最小基数为零是非常合理的。另一方面，当车辆对您的系统很重要时，很可能是因为它已经进行了第一次服务 - 因此最小基数也是合理的。您需要考虑什么业务规则适用于您的组织并相应地建模。例如，我认为汽车经销商的系统中会有很多尚未由经销商维修的汽车，而消声器商店不会关心它没有维修过的汽车。

服务项目：您问：

此外，服务涉及零件、人工和消耗品。

你会如何建模？作为一个独立的实体？或者在服务实体或汽车和服务之间的关系（交叉实体）的一部分？

让我们考虑汽车和服务之间的交集实体……您可能会使用这样的交集来存储有关服务的详细信息，例如使用了多少劳动力、哪些零件和消耗品。

然而，使用交叉点意味着汽车和服务之间的多对多，但您已经声明每个服务（恰好？）一辆汽车。使用交叉实体来跟踪服务项目详细信息将意味着您的模型未正确规范化。

将此模型视为替代方案：

在这个模型中，每项服务都针对一辆车，但每项服务都可以有许多人工、零件和消耗品的实例。这个模型遵循我提到的第一条经验法则，并从系统关心的每个有形事物中生成一个实体类型。这可能是对逻辑模型的一个很好的初步尝试。

上述模型的问题之一是它没有处理您的系统可能希望如何使用数据的一个方面，至少不是很好。在您的系统中跟踪所有这些数据的最重要原因之一是您可以打印分项服务发票。这意味着服务项目本身对您的系统很重要。如果你考虑到这一点，你可能会得到更像这样的结果：

请注意，第二个替代方案SERVICE_LINE_ITEM被识别为实体类型。它是SERVICE和 通用订单项类型之间的交集：SKU。SKU 是超类型实体，可以是部件、消耗品或某种劳动力。您不需要为服务行项目类型设置逻辑超类型，但很多系统都会以这种方式建模，因为它使事务细节变得更加简单。

第二个模型在第一个模型的具体实体之上引入了抽象实体。当您从最初的逻辑模型（主要基于有形事物）转移到物理模型时，引入这样的抽象是容易发生的事情之一。

随着您获得数据建模的经验，您将获得从概念/逻辑模型阶段直接过渡到结构良好的物理模型的良好直觉。