ER图中的三个实体之间的关系--是否一个三元关系足够了，还是也需要两个二进制文件？

Question

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

• 项目-软件项目
• 任务-可以分解成多个任务的软件项目。
• 雇员-属于本软件的雇员

和：

1. 一个项目可以分为任务。(任务可以由管理用户创建，管理员可以将这些任务分配给选定的项目。这里只分配任务给项目，而不分配员工到项目。)
2. 员工可以被分配到项目中。 (员工可被分配到项目中。这里只分配员工到项目，而不是分配给项目的任务。)
3. 对于选定项目的选定任务，我们可以从2中分配给该项目的员工池中分配员工。(这一次我们必须指定项目、任务和员工；所有3种选择都是强制性的。)

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

对于上面的关系，我创建了这个ERD：

​

​

考虑一下

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

是否需要这两种独立的关系，如ER图中的关系1和关系2？

或

我们可以只使用关系3之间的项目，员工和任务，关系3号，为此也？

Answer 1

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

不同的约束可能意味着我们可以删除关系/表，因为它可以用其他的方式表示。对高级NFs (normal )的规范化告诉我们什么时候可以用更小/更简单的关系/表来替换关系/表。

每个关系表都包含参与关系的行。我们可以通过谓词(语句模板)来描述这种关系：

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

我们能放下一号吗？如果我们在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中的行。可能employee 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。

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

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

对高级NFs的规范化指导将关系分解为更简单的其他关系，通过这些关系可以根据特定的约束来表示关系。

这也是为什么我们需要实体类型/表，而不仅仅是关系类型/表。(如果我们无论如何都不想要它们用于特定于实体的属性，或者仅仅是ER建模约定。)这三种关系不能告诉你没有被分配到一个项目或一个任务和项目的员工。同样，对于任务和项目也是如此。

PS 2我们忽略关系代数中的一个属性，不对其进行project处理。我们忽略了SQL中的列，方法是不对列进行select处理。结果的谓词是，对于属性/列的某些值，旧谓词保持不变。关系natural join给出其关系/谓词是输入关系/谓词的和的行。在SQL中，对于不重复的行&没有共享的可空列，即select distinct from natural join。

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

PS 4这种风格的(真正的Chen) ER图通常不使用SQL nulls。但碰巧的是，您可以用3的变体替换所有三种关系。您可以使用null，-extend，二进制关系，并用三元表示它们。和往常一样，nulls会使谓词复杂化。通常，我们添加一个可空列，以替代添加一个单独的表，共享一个空的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我的一些答案是这样的三元和二进制关系(Ship)类型/表/谓词：

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。