先决条件 – 范式
数据库的设计按以下方式进行：
- 与我们为其设计数据库的利益相关者交谈。获取所有需求，需要存储哪些属性，并在给定的属性集上建立功能依赖关系。
- 在需求分析的基础上绘制实体关系图。
- 将 ER 图转换为关系模型，最后将这些关系创建到具有适当约束的数据库中。
我们几乎知道如何绘制 ER 图。但是，当我们提出诸如满足第一范式 (1NF) 需要多少最小关系之类的问题时，有时会让人感到困惑。我们建立了一些简单的规则，这些规则是在对每个案例进行深入分析后形成的，因此可以直接使用。
注意 –不鼓励大肆渲染规则，而是理解每个案例背后的逻辑将帮助您轻松且长时间地记住它们。
备注 –
- 如果双方完全参与；
将涉及的两个实体和关系合并到 1 个表中。 - 否则，一方完全参与，一方部分参与；
- M:N合并总参与方的关系。
- 1:N合并总参与方的关系。
- 1:1将涉及的两个实体和关系合并到 1 个表中。
- else if，双方都是部分参与；
- M:N每个实体和关系的单独表。因此，3张桌子。
- 1:N使用外键引用 1 端合并 N 端的关系。
- 1:1使用外键将关系和一个实体合并到 1 个表中，将另一个实体合并到 1 个表中。
现在，你肯定会有一个问题，我们是如何形成这样的规则的?这是非常容易和合乎逻辑的。让我们了解一个案例背后的逻辑，您也可以类似地建立其他案例的结果。
我们已经给出了一个具有两个实体 E1(ABC) 和 E2(DEF) 的 1:N 关系的场景，其中 A 和 D 分别是主键。 E1 部分参与，而 E2 完全参与关系 R。
基于上述场景，我们在 E1 中创建了某些元组：
| A | B | C |
|---|---|---|
| a1 | b1 | c1 |
| a2 | b2 | c2 |
| a3 | b3 | c3 |
同样，为 E2 创建某些元组：
| D | E | F |
|---|---|---|
| d1 | e1 | f1 |
| d2 | e2 | f2 |
| d3 | e3 | f3 |
现在，创建满足上述条件的关系R，即E1 为部分参与，E2 为全部参与，E1 到E2 为1:N 关系。
| A | D |
|---|---|
| a1 | d1 |
| a1 | d2 |
| a2 | d3 |
想想可能性，我们如何合并?
- 方式 1：将两个实体和关系合并到一个表中。这是不正确的，因为 (AD) 将成为该表的主键，但主键永远不能有 NULL 值。
A B C D E F a1 b1 c1 d1 e1 f1 a1 b1 c1 d2 e2 f2 a2 b2 c2 d3 e3 f3 a3 b3 c3 NULL NULL NULL - 方式 2：在 1 侧合并关系。这是不正确的，因为 (AD) 将成为该表的主键，但主键永远不能有 NULL 值。
A B C D a1 b1 c1 d1 a1 b1 c1 d2 a2 b2 c2 d3 a3 b3 c3 NULL - 方式3：在N端合并关系。这是对的。
D E F A d1 e1 f1 a1 d2 e2 f2 a1 d3 e3 f3 a2 出于同样的原因，您是否可以考虑为什么我们允许将两个实体和关系合并到 1 个表中，当它是 1:1 关系时?简单地说，我们不会在那里有一个复合主键，所以我们肯定会有一个没有 NULL 值的主键。再强调一下，为什么我们允许合并实体和关系，双方完全参与?原因是即使我们有这样的合并表的复合主键，我们也确信它的主键永远不会有任何 NULL 值。
注意 –您可以按照上述相同的步骤来确定所有结果。