ER图——避免一对一关系
ER diagram - avoiding one-to-one relationship
我一直在为大学项目制作 ER 图。这是关于运输公司的。该公司为其他公司做特定的工作，对于每项工作，需要三种类型的文件，并且这些文件在同类文件中具有唯一标识符。所以我所做的是将这些类型的文档作为单独的实体。现在，当我想将它们（称它们为 Doc1、Doc2、Doc3）加入一个实体（称其为 Job）时，它们基本上只为那一份工作而制作，没有其他。此外，这项工作只有这些文件中的每一个，因此看起来文件和工作之间的关系是一对一的。然而，当教授在教我们 ER 模型时，他告诉我们应该始终避免绘制一对一的关系（应该有一种方法可以使这些文档成为工作的一种属性）。所以我想知道的是 - 将这些文档的标识符绘制为作业的属性，然后将它们作为引用文档 table（在关系模型中）中相应字段的外键是否正确？或者是否有任何其他更优雅的方式来连接它们以某种方式避免这些一对一的关系？
另外，如果我这样做，我想我应该让所有 3 列代表文档的标识符在 Job table 中是唯一的，对吧？这样我就可以避免让两个工作具有相同的 Doc1？
谢谢！
要避免一对一的关系，因为它们表明由关系连接的实体实际上是一个。但是，在这里指定的情况下，关系不是一对一的。相反，它是 "one to zero or one"，也称为 "one-to-one optional"。
一个例子是房屋和地块之间的关系。房屋必须位于一个地块上，并且在任何给定的地块上只能有一个房屋，但该地块可以在房屋建造之前就已经存在。如果您正在为这种关系建模，那么 Lot 和 Home 之间会有 "one to zero or one" 关系。它将显示如下：
在你的例子中，你有三个独立的依赖项，所以它看起来像：
在物理上，这些关系可以用两种方式表示：
- "one" 行中的可为空的外键（很多，在我上面的示例中），
或
- "zero or one" 行中的不可空外键（在我上面的示例中为主页）
您可以根据您的应用程序通常导航的方向选择最适合您和最有效的方法。
您可以决定让数据库强制执行唯一性约束（一个地块上只能有一个房屋这一事实）。在某些数据库中，空值参与了唯一性约束（换句话说，唯一性索引只能有一个 Null 条目）。在这样的数据库中，您将只能使用第二种方法。在MySQL中，情况并非如此；唯一性约束会忽略空值，因此您可以选择任何一种方法。第二种方法更常见。
我一直在为大学项目制作 ER 图。这是关于运输公司的。该公司为其他公司做特定的工作，对于每项工作，需要三种类型的文件，并且这些文件在同类文件中具有唯一标识符。所以我所做的是将这些类型的文档作为单独的实体。现在，当我想将它们（称它们为 Doc1、Doc2、Doc3）加入一个实体（称其为 Job）时，它们基本上只为那一份工作而制作，没有其他。此外，这项工作只有这些文件中的每一个，因此看起来文件和工作之间的关系是一对一的。然而，当教授在教我们 ER 模型时，他告诉我们应该始终避免绘制一对一的关系（应该有一种方法可以使这些文档成为工作的一种属性）。所以我想知道的是 - 将这些文档的标识符绘制为作业的属性，然后将它们作为引用文档 table（在关系模型中）中相应字段的外键是否正确？或者是否有任何其他更优雅的方式来连接它们以某种方式避免这些一对一的关系？ 另外，如果我这样做，我想我应该让所有 3 列代表文档的标识符在 Job table 中是唯一的，对吧？这样我就可以避免让两个工作具有相同的 Doc1？ 谢谢！
要避免一对一的关系，因为它们表明由关系连接的实体实际上是一个。但是，在这里指定的情况下，关系不是一对一的。相反，它是 "one to zero or one"，也称为 "one-to-one optional"。
一个例子是房屋和地块之间的关系。房屋必须位于一个地块上，并且在任何给定的地块上只能有一个房屋，但该地块可以在房屋建造之前就已经存在。如果您正在为这种关系建模，那么 Lot 和 Home 之间会有 "one to zero or one" 关系。它将显示如下：
在你的例子中，你有三个独立的依赖项，所以它看起来像：
在物理上，这些关系可以用两种方式表示：
- "one" 行中的可为空的外键（很多，在我上面的示例中）， 或
- "zero or one" 行中的不可空外键（在我上面的示例中为主页）
您可以根据您的应用程序通常导航的方向选择最适合您和最有效的方法。
您可以决定让数据库强制执行唯一性约束（一个地块上只能有一个房屋这一事实）。在某些数据库中，空值参与了唯一性约束（换句话说，唯一性索引只能有一个 Null 条目）。在这样的数据库中，您将只能使用第二种方法。在MySQL中，情况并非如此；唯一性约束会忽略空值，因此您可以选择任何一种方法。第二种方法更常见。