为什么 ERD 中不允许使用特定基数？

在有关实体关系图的每个教程中，我都读到不允许为关系指定固定基数。只有对 ERD 的非正式评论才能澄清飞行员的数量exactly 2.

因此，例如，航班和飞行员之间的关系，其中每个航班恰好有 2 名飞行员，必须表示为：

<flight> 0..N <------> 1..N <pilot>

而不是

<flight> 0..N <------> 2 <pilot>

我的记号是0..N= 可选，很多；1..N= 强制，很多，1= 强制，一。

这个限制是普遍的吗？其背后的原因是什么？

编辑：澄清我的符号。

编辑：我可以看到两个关系如何强制执行相同的约束：

         0..N <------> 1
<flight>                 <pilot>
         0..N <------> 1

但是，查看飞行员是否在给定航班上的查询变得非常难看，因为您必须检查两个属性中的每一个。如果属性数量增加（例如，增加到 15 名空乘人员），查询将变得完全难以管理，而架构也几乎无法管理。

其他回复提供了一些有价值的答案。还需要添加两块：

首先，ER 建模不仅仅是 ERD。我们倾向于尝试将整个 ER 模型放在一张图表上。但完整的 ER 建模远远超出了单个图表所能容纳的范围。可能存在将关系的基数限制为不小于 10 且不大于 15 的业务规则。但重要的是要认识到这些必须是“业务规则”（即主题规则），而不是出于实际原因强加的设计限制。完整的 ER 模型可以包含数据上的所有这些业务规则，并且如果需要，可以用简单的英语来表达这些规则。

符号 10..15 是首选，因为它更简洁，除非需要更多细节来阐明规则，例如规则存在的原因。

上面暗示了需要提出的第二点。这就是分析和设计的区别。如果以经典方式使用 ER 建模，那么它是数据分析工具，而不是数据库设计工具。我所说的“数据分析”是指从以数据为中心的角度来分析问题。正规的 CS 或 IT 教育中没有充分教授区分分析和设计、问题特征和解决方案特征。这对于把事情做好绝对至关重要。

即使我们这些意识到差异的人有时也会犯错，将解决方案的特征滑入问题的定义中。这被称为“框内思考”。

如果您想用图表表示数据库设计，请不要使用 ERD。使用关系示意图，前提是您正在设计的数据库是关系型的。关系示意图包含 ERD 不应包含的功能，例如连接表和外键。不要将 ERD 用作“关系精简版”。事实并非如此。

顺便说一句，另一个答案评论说 ERD 应该可以在任何 DBMS 上实现。这是我刚才提出的概念的结果，即 ERD 捕获的是分析而不是设计。