TL;DR 您需要所有三种关系类型/表。因为如果你丢掉一个，那么在某些情况下你会丢失数据——没有办法用剩下的来回答所有相同的问题。
不同的约束可能意味着我们可以删除一个关系/表，因为它可以用其他人来表达。 规范化到更高的 NF（正常形式）告诉我们什么时候可以用更小/更简单的关系/表格替换关系/表格。
每个关系表都包含参与关系的行。我们可以通过谓词（语句模板）来描述这种关系：
1 Divides_to 包含 (T, P) 行，其中 project P divides to task T
2 Has 包含 (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 建模约定。）例如，这三个关系无法告诉您未分配到项目或任务和项目的员工。对于任务和项目也是如此。
PS 2 我们忽略了关系代数中的一个属性，而不是projecting。我们通过不selecting 来忽略 SQL 中的列。结果的谓词是属性/列的某些值，旧谓词成立。关系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 空值。但是碰巧你可以用一个带有空值的 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 我的一些答案是关于三元与二元关系（船）类型/表/谓词：
Should this ER diagram use a ternary relationship instead
Best Solution - Ternary or Binary Relationship
Why can't you just join in fan trap?
并重新设计&谓词：
Modeling multiple many to many relationships between the same entities in a relational database
What is the difference between an entity relationship model and a relational model?
Is there any rule of thumb to construct SQL query from a human-readable description?
PS 6 Has 是一个无用的通用关系名称/含义/表。使用有意义的名称，例如 Is_assigned_to 或 Assignment。