ER图中3个实体之间的关系-是一个三元数还是还需要2个二进制数？

Question

我正在尝试为我的项目管理软件绘制一个ER图，描述以下内容。它包含以下实体：

• 项目-软件项目
• 任务-可以分解为许多任务的软件项目
• 员工-属于此软件的员工

和：

1. 一个项目可以分为任务。（任务可以由管理员用户创建，管理员用户可以将这些任务分配给选定的项目。这里仅将任务分配给项目，而没有将员工分配给项目。）

2. 可以将员工分配到项目。
   （可以将员工分配到项目。这里仅将员工分配到项目，而没有分配到项目任务。）

3. 对于选定项目的选定任务，我们可以从资源池中分配员工-在2中分配给该项目的员工。（这一次，我们必须指定项目，任务和员工；所有3个选择都是必需的。）

上面1、2和3的输入过程可以在系统的单独页面中完成。您可以先选择其中的任何一个。

对于以上关系，我创建了此ERD：

考虑

• 项目与任务之间的关系1
• 项目与员工之间的关系2

是否需要两个单独的关系（如ER图中的关系，关系1和关系2）？

要么

我们还可以仅使用项目，员工和任务之间的关系3，而不使用关系3吗？

Answer 1

TL;DR您需要所有三种关系类型/表。因为如果你丢掉一个，那么在某些情况下你就会丢失数据——没有办法使用剩下的数据来回答所有相同的问题。

不同的约束可能意味着我们可以删除关系/表，因为它可以用其他关系/表来表达。归一化到更高的 NF（范式）告诉我们何时可以用更小/更简单的关系/表替换关系/表。

每个关系表都保存参与关系的行。我们可以通过谓词（语句模板）来描述关系：

1Divides_to保存(T, P)行，其中project P divides to task T
2Has保存(E, P)行，其中employee E is assigned to project P
3 保存(E, T, P)行，其中employee E is assigned to task T on project P

可以掉1吗？如果我们忽略 3 中的员工，那么我们会得到 的行some employee is assigned to task T on project P。但是（根据上面）这不是 1 中的行。也许项目 p1 划分到 1 中的任务 t1，但没有员工被分配到项目 p1 上的任务 t1；那么1中的行(t1, p1)不是3中的子行。并且2中没有任务信息。所以我们不能用3和2来代替1。

可以掉2个吗？类似地：如果我们忽略 3 中的任务，那么我们会得到其中的行employee E is assigned to some task on project P。但是（根据上面）这不是 2 中的行。也许员工 e1 已分配给项目 p1，但未分配给项目 p1 上的任务；那么2中的行(e1, p1)不是3中的子行。并且1中没有员工信息。所以我们不能用3和1来代替2。

可以掉3个吗？使用 1 & 2 我们可以得到 的行employee E is assigned to project P AND project P divides to task T。但是（根据上面）这不是 3 中的行。如果分配给项目的员工未分配给其所有任务，或者项目的任务未分配给其所有员工，则它们会有所不同。没有其他方法可以从 1 & 2 生成 3。所以我们不能用 1 & 2 来代替 3。

所以我们需要这三种关系。

当约束成立时，某些查询表达式总是返回与某些其他查询表达式相同的结果，否则不会返回相同的结果。因此，在不同的约束下，我们可能能够删除关系/表，因为我们可以通过其他人的查询/视图来表达其内容。我们可能会选择不同的关系/表。

归一化到更高的 NF 可以指导将关系分解为更简单的其他关系，从而可以根据某些约束来表达关系。

PS 1 这也是我们需要实体类型/表而不仅仅是关系类型/表的原因。（如果我们不希望将它们用于特定于实体的属性或只是 ER 建模约定。）例如，这三种关系无法告诉您有关未分配给项目或任务和项目的员工的信息。对于任务和项目也是如此。

projectPS 2 我们通过不使用它来忽略关系代数中的属性。select我们通过 not ing来忽略 SQL 中的列。结果的谓词是 FOR SOME 属性/列的值，旧谓词成立。关系natural join给出其关系/谓词是输入关系/谓词的 AND 的行。在 SQL 中，没有重复行且没有共享可为空列select distinct from natural join。

PS 3 根据常识，您的设计满足某些约束：如果任务-项目对出现在 3 中，那么它必须出现在 1 中，如果员工-项目对出现在 3 中，那么它必须出现在 2 中。在 ER 中反映这一点的一种方法建模的方法是将任务-项目和员工-项目关系具体化为关联实体，然后将 3 替换为 ER 所说的这些实体上的二元关系。相对而言，关系/表在值上仍然是三元的，其中某些子行恰好标识这些实体。获得受约束的关系二进制 3 的一种方法是在 2 中添加员工项目 PK（主键）或 CK（候选键）id，并用这样的 id 替换 3 中的复合 FK（外键）。然后我们就有了实体和值的二进制。一些伪 ER 方法可以做到这一点。

PS 4 这种风格的（真正的 Chen）ER 图通常不使用 SQL null。但碰巧的是，您可以将所有三个关系替换为 3 的变体（带有空值）。您可以用null三元关系扩展二元关系和union它们。与往常一样，空值使谓词变得复杂。通常我们添加一个可为空的列作为添加共享无空 CK（候选键）的单独表的替代方案。但这是不同的，没有节省空间或连接；它只会让事情变得复杂。（包括重要的限制。）

    E IS NULL
AND task T is of project P
AND NOT EXISTS E [employee E is assigned to task T of project P]
OR  T IS NULL
AND employee E is assigned to project P
AND NOT EXISTS T [employee E is assigned to task T of project P]
OR  employee E is assigned to task T of project P

（这在 SQL 中也是有问题的，因为 SQL unique、primary key&join不是这些名称的关系事物，因为它们会进行null特殊处理。）

PS 5 我的一些关于三元与二元关系（船舶）类型/表/谓词的答案：
这个 ER 图应该使用三元关系而不是
最佳解决方案 - 三元或二元关系
为什么你不能加入粉丝陷阱？
并重新设计和谓词：
对关系数据库中相同实体之间的多个多对多关系进行
建模实体关系模型和关系模型有什么区别？
是否有任何经验法则可以根据人类可读的描述构建 SQL 查询？

PS 6Has是一个无用的通用关系名称/含义/表。使用有意义的名称，例如Is_assigned_to或Assignment。