ER 图中 3 个实体之间的关系——一个三元就足够了还是还需要 2 个二进制？
relationships between 3 entities in ER diagram--is a ternary enough or are 2 binaries also needed?
我正在尝试为我的项目管理软件绘制 ER 图
描述如下。它包含这些实体：
- 项目 - 软件项目
- 任务 - 可以分解为多个任务的软件项目
- employees - 属于该软件的员工
并且：
一个项目可以分成任务。
（任务可以由管理员用户创建，管理员用户可以将这些任务分配给selected项目。这里只有任务分配给项目，没有分配员工给项目。）
可以将员工分配给项目。
（员工可以分配到项目，这里只是分配员工到项目，不是分配到项目的任务。）
对于 selected 项目的 selected 任务，我们可以从池中分配员工——在 2 中分配给该项目的员工。
（这次我们必须指定项目、任务和员工；所有 3 selection 都是必需的。）
上述1、2、3的输入过程可以在系统的不同页面中完成。
您可以先select其中任何一个。
对于上述关系，我创建了这个 ERD：
考虑
- 项目和任务之间的关系 1
- 项目与员工之间的关系 2
是否需要ER图中的两个独立关系，
第一关系和第二关系？
或
我们可以只使用项目、员工和任务之间的关系 3，也就是关系 3 吗？
TL;DR 你需要所有三个关系 types/tables。因为如果您丢弃一个，那么在某些情况下您会丢失数据——无法使用剩余的数据来回答所有相同的问题。
不同的约束可能意味着我们可以删除一个relationship/table，因为它可以用其他方式来表达。 标准化 到更高的 NF（规范形式）告诉我们何时可以用 smaller/simpler 替换 relationship/table。
每个关系 table 包含参与该关系的行。我们可以通过谓词（语句模板）来描述关系：
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。
所以我们需要所有三个关系。
当约束成立时，某些查询表达式总是 return 与某些其他查询表达式的结果相同，否则不会。因此，在不同的约束下，我们可能会删除 relationship/table，因为我们可以通过其他人的 queries/views 来表达其内容。我们可能会选择不同的 relationships/tables.
对更高 NF 的规范化指导将关系分解为更简单的其他关系，通过这些关系可以根据某些约束来表达。
PS 1 这也是我们需要实体 types/tables 而不仅仅是关系 types/tables 的原因。 （如果我们无论如何都不希望它们用于特定于实体的属性或只是 ER 建模约定。）例如，这三种关系无法告诉您有关未分配给项目或任务和项目的员工。对于任务和项目也是如此。
PS 2 我们通过不 project 忽略关系代数中的属性。我们通过不 select 忽略 SQL 中的列。结果的谓词是 attribute/column 的 FOR SOME 值，旧谓词成立。关系 natural join 给出 relationship/predicate 是输入 relationships/predicates 的 AND 的行。在 SQL 中，没有重复行且没有共享可为空的列，即 select distinct from natural join.
PS 3 在常识下你的设计满足一定的约束条件：如果任务-项目对出现在 3 中，那么它必须出现在 1 中，如果员工-项目对出现在 3 中，那么它必须出现在2. 在 ER 建模中反映这一点的一种方法是将任务-项目和员工-项目关系具体化为关联实体，然后将 3 替换为 ER 所说的那些 实体 上的二元关系。在关系上，relationship/table 在值上仍然是三元的，其中某些子行恰好标识这些实体。获得约束关系二进制 3 的一种方法是在 2 中添加一个 employee-project PK（主键）或 CK（候选键）id，并用这样的 id 替换 3 中的复合 FK（外键）。然后我们有一个关于实体和值的二进制文件。一些伪 ER 方法可以做到这一点。
PS 4 这种风格的（真陈）ER 图通常不使用 SQL 空值。但碰巧你可以用 3 的变体替换所有三个关系。您将 null-扩展二元关系并 union 它们与三元关系。像往常一样，空值使谓词复杂化。通常我们添加一个可为空的列作为添加单独的 table 共享无空 CK（候选键）的替代方法。但这是不同的，没有 space 或加入的节省；它只会使事情复杂化。 （包括重要的约束条件。）
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 我的一些答案关于这种三元与二元关系（船）types/tables/谓词：
Should this ER diagram use a ternary relationship instead
Why can't you just join in fan trap?
并重新设计和谓词：
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 是无用的通用关系 name/meaning/table。使用有意义的名称，例如 Is_assigned_to 或 Assignment.
我正在尝试为我的项目管理软件绘制 ER 图 描述如下。它包含这些实体：
- 项目 - 软件项目
- 任务 - 可以分解为多个任务的软件项目
- employees - 属于该软件的员工
并且：
一个项目可以分成任务。 （任务可以由管理员用户创建，管理员用户可以将这些任务分配给selected项目。这里只有任务分配给项目，没有分配员工给项目。）
可以将员工分配给项目。
（员工可以分配到项目，这里只是分配员工到项目，不是分配到项目的任务。）对于 selected 项目的 selected 任务，我们可以从池中分配员工——在 2 中分配给该项目的员工。 （这次我们必须指定项目、任务和员工；所有 3 selection 都是必需的。）
上述1、2、3的输入过程可以在系统的不同页面中完成。 您可以先select其中任何一个。
对于上述关系，我创建了这个 ERD：
考虑
- 项目和任务之间的关系 1
- 项目与员工之间的关系 2
是否需要ER图中的两个独立关系， 第一关系和第二关系？
或
我们可以只使用项目、员工和任务之间的关系 3，也就是关系 3 吗？
TL;DR 你需要所有三个关系 types/tables。因为如果您丢弃一个，那么在某些情况下您会丢失数据——无法使用剩余的数据来回答所有相同的问题。
不同的约束可能意味着我们可以删除一个relationship/table，因为它可以用其他方式来表达。 标准化 到更高的 NF（规范形式）告诉我们何时可以用 smaller/simpler 替换 relationship/table。
每个关系 table 包含参与该关系的行。我们可以通过谓词（语句模板）来描述关系：
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。
所以我们需要所有三个关系。
当约束成立时，某些查询表达式总是 return 与某些其他查询表达式的结果相同，否则不会。因此，在不同的约束下，我们可能会删除 relationship/table，因为我们可以通过其他人的 queries/views 来表达其内容。我们可能会选择不同的 relationships/tables.
对更高 NF 的规范化指导将关系分解为更简单的其他关系，通过这些关系可以根据某些约束来表达。
PS 1 这也是我们需要实体 types/tables 而不仅仅是关系 types/tables 的原因。 （如果我们无论如何都不希望它们用于特定于实体的属性或只是 ER 建模约定。）例如，这三种关系无法告诉您有关未分配给项目或任务和项目的员工。对于任务和项目也是如此。
PS 2 我们通过不 project 忽略关系代数中的属性。我们通过不 select 忽略 SQL 中的列。结果的谓词是 attribute/column 的 FOR SOME 值，旧谓词成立。关系 natural join 给出 relationship/predicate 是输入 relationships/predicates 的 AND 的行。在 SQL 中，没有重复行且没有共享可为空的列，即 select distinct from natural join.
PS 3 在常识下你的设计满足一定的约束条件：如果任务-项目对出现在 3 中，那么它必须出现在 1 中，如果员工-项目对出现在 3 中，那么它必须出现在2. 在 ER 建模中反映这一点的一种方法是将任务-项目和员工-项目关系具体化为关联实体，然后将 3 替换为 ER 所说的那些 实体 上的二元关系。在关系上，relationship/table 在值上仍然是三元的，其中某些子行恰好标识这些实体。获得约束关系二进制 3 的一种方法是在 2 中添加一个 employee-project PK（主键）或 CK（候选键）id，并用这样的 id 替换 3 中的复合 FK（外键）。然后我们有一个关于实体和值的二进制文件。一些伪 ER 方法可以做到这一点。
PS 4 这种风格的（真陈）ER 图通常不使用 SQL 空值。但碰巧你可以用 3 的变体替换所有三个关系。您将 null-扩展二元关系并 union 它们与三元关系。像往常一样，空值使谓词复杂化。通常我们添加一个可为空的列作为添加单独的 table 共享无空 CK（候选键）的替代方法。但这是不同的，没有 space 或加入的节省；它只会使事情复杂化。 （包括重要的约束条件。）
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 我的一些答案关于这种三元与二元关系（船）types/tables/谓词：
Should this ER diagram use a ternary relationship instead
Why can't you just join in fan trap?
并重新设计和谓词：
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 是无用的通用关系 name/meaning/table。使用有意义的名称，例如 Is_assigned_to 或 Assignment.