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

Question

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

项目-软件项目

任务-可以分解为许多任务的软件项目

员工-属于该软件的员工

和:

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

可以将员工分配到项目。
(可以将雇员分配到项目。这里仅将雇员分配到项目，而没有分配到项目任务。)

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

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

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



考虑

项目和任务之间的关系1

项目与员工之间的关系2

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

或者

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

Answer 1

TL; DR 您需要所有三种关系类型/表。因为如果您丢掉一个，然后在某些情况下会丢失数据，所以无法使用其余的来回答所有相同的问题。

不同的约束可能意味着我们可以删除关系/表，因为它可以用其他形式表示。对较高NF(标准形式)的规范化告诉我们何时可以用较小/较简单的关系/表替换关系/表。

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

1 Divides_to保存(T, P)行，其中project P divides to task T2 Has保存(E, P)行，其中employee E is assigned to project P3保存(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。

因此，我们需要所有三个关系。

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

对较高NF的规范化指导将关系分解为更简单的其他关系，通过该关系可以代替某些约束来表达该关系。

PS 1这也是为什么我们需要实体类型/表而不仅仅是关系类型/表的原因。 (如果我们无论如何都不希望它们具有特定于实体的属性或只是ER建模约定。)例如，这三个关系无法告诉您未分配给项目，任务和项目的员工。对于任务和项目也是如此。

PS 2我们通过不对它进行project编码来忽略关系代数中的一个属性。我们不通过对select编码来忽略SQL中的列。结果的谓词是属性/列的FOR SOME值，旧的谓词成立。关系natural join给出其关系/谓词为输入关系/谓词的AND的行。在SQL中，没有重复的行，也没有共享的可空列select distinct from natural join。

PS 3按照常识，您的设计满足某些约束:如果一个任务-项目对出现在3中，那么它必须出现在1中；如果一个员工-项目对出现在3中，那么它必须出现在2中。一种在ER中反射(reflect)出来的方法建模是通过将任务-项目和员工-项目之间的关系固定为关联实体，然后用ER所谓的那些实体上的二进制关系替换3。在关系上，关系/表仍然是值的三元组，其中某些子行恰好标识了那些实体。获取受约束的相关二进制3的一种方法是在2中添加一个雇员项目PK(主键)或CK(候选键)id，并用这种id替换3中的复合FK(外键)。然后我们有一个关于实体和值的二进制文件。一些伪ER方法可以做到这一点。

PS 4这种(true Chen)ER图样式通常不使用SQL空值。但是，当发生这种情况时，您可以将所有三个关系替换为3(带空值)。您可以null-扩展二进制关系，并用三进制union它们。像往常一样，null使谓语复杂化。通常，我们添加一个可为空的列作为添加共享无空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。