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

Question

我是一个初学者数据库设计师，想知道是否有人能帮助我理解这一点。假设我们希望设计一个系统，其中包括一个称为Vehicle的实体，另一个称为Service的实体。服务是一种修理/保养。

你如何看待这一关系的红衣主教：

• 一辆汽车可以进行多次维修。
• 服务是一辆车。

最小基数是0还是汽车侧面的最小基数？

此外，服务还包括部件、劳动力和消耗品。

你会怎么模拟这个？作为一个独立的实体？或在服务实体或部分关系(交叉实体)之间的汽车和服务？

Answer 1

--一般建议：

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

这是一个从任何逻辑数据库设计开始的好地方。如果你花一些时间预先思考什么东西对你的系统很重要，那么你就会有一个坚实的基础来构建你的系统。你的组织关心的事情会比你的组织用来处理这些事情的业务流程和规则少得多。这就是为什么一个可靠的数据模型如此重要的原因。

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

的具体答案：

基数:如果你想一想，很容易就会发现，一辆汽车根本不可能(由你的商店)维修。因此，最小基数为零是很有道理的。另一方面，当车辆对你的系统很重要的时候，它很可能是因为它已经有了它的第一次服务-所以一个最小的基数也是合理的。您需要考虑相应的组织和模型的业务规则是什么。例如，我会想，一个汽车经销商系统中会有很多汽车还没有得到经销商的服务，而消音器店却不关心它没有服务过的汽车。

服务项目:您问：

此外，服务还包括部件、劳动力和消耗品。你会怎么模拟这个？作为一个独立的实体？或在服务实体或部分关系(交叉实体)之间的汽车和服务？

让我们考虑一个车和服务之间的交叉点.您可以使用这样的交叉口来存储有关服务的详细信息，例如使用了多少人工、哪些部件和消耗品。

然而，使用一个交叉口意味着在汽车和服务之间有很多对很多，但是您已经说过每个服务都是用于(确切地说？)一辆车。使用交叉实体跟踪服务项详细信息将意味着您的模型没有被正确标准化。

将这一模式视为另一种选择：

在这个模型中，每种服务都是为一辆车服务的，但每一种服务都可以有许多劳动力、零部件和消耗品的实例。这个模型遵循我提到的第一条经验法则，使系统所关心的每一件有形的事情都有一个实体类型。这可能是对逻辑模型的第一次尝试。

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

注意，在第二种选择中，SERVICE_LINE_ITEM被识别为实体类型。它是SERVICE与泛型行项类型：SKU之间的交集。SKU是一种超级实体，它可以是零件、消耗品或某种劳动。您不需要为服务项目类型建立逻辑超级类型，但是许多系统都是这样建模的，因为它使事务细节变得更简单。

第二个模型在第一个模型的具体实体之上引入抽象实体。引入这样的抽象是当您从最初的逻辑模型(主要是基于有形的事物到物理模型)移动时会发生的事情之一。

当您获得数据建模的经验时，您将获得将概念/逻辑模型阶段直接转移到结构良好的物理模型的良好本能。