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

Question

在有关实体关系图的每个教程中，我都读到不允许为关系指定固定的基数。只有对 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 名空乘人员），查询将变得完全无法管理，并且架构几乎无法管理。

Answer 1

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

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

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

以上暗示了需要做的第二点。这是分析和设计之间的区别。如果以经典方式使用 ER 建模，它是数据分析的工具，而不是数据库设计的工具。 “数据分析”是指从以数据为中心的角度分析问题。区分分析和设计，区分问题的特征和解决方案的特征，在正规的 CS 或 IT 教育中教得还不够。把事情做好是绝对关键的。

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

如果您想绘制数据库设计图表，请不要使用 ERD。使用关系示意图，前提是您设计的数据库是关系数据库。关系示意图包含 ERD 不应包含的功能，例如联结表和外键。不要将 ERD 用作“关系精简版”。不是这样的。

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

Answer 2

基数规则本身只是“任何和所有可能的一般规则”的特例。能够表达“任何和所有可能的规则”的仅有的两种语言是人类自然语言（无论你怎么努力，它的缺点都是经常模棱两可和不精确），以及形式谓词逻辑的符号语言。

如何在数据建模的上下文中使用后者，是这本极好的（且值得高度赞扬的）“数据库专业人员应用数学”一书的全部主题。

Halpin 的 ORM 试图提出一种建模语言，该语言可以覆盖（即用图形符号来表达）比 E/R 更多种类的业务规则。例如，它有用于表达无环图约束的符号（“没有人是他自己的祖先”）。但即使是这种语言也不能表达一切，必须求助于它称为“其他”的最后一类约束，只能用自然语言来描述。

这是一个语言问题。如果您设计的语言具有极少的符号（矩形、连接线、零、一和乌鸦脚），并且只能以极少数的方式组合，那么您就不能指望这样的语言能够表达任何可以想象的东西。

Answer 3

不是您问题的直接答案，但您可能对如何在实际数据库中实施这种约束感兴趣...

假设您在一个航班上最多可以有 2 名飞行员。您可以简单地创建两个“0..N 到 0..1”的关系：

如果您正好需要 2 个飞行员，只需将 PILOT1_ID 和 PILOT2_ID 设为 NOT NULL（并通过 CHECK 确保它们不同）。

---

但是，正如您已经指出的，这对于更大的基数很快就会变得笨拙，因此需要使用不同的技术。假设您需要将空乘人数限制在 15 人以内，您可以这样做...

...在联结表上具有以下约束：

CHECK (POSITION BETWEEN 1 AND 15)

请注意，{FLIGHT_ID, POSITION} 上有一个 UNIQUE 约束，如上图中的 U1 所示。

从本质上讲，我们是在每次飞行中将乘务员归类到特定位置。在同一航班上，没有两名乘务员可以占据相同的位置（感谢U1），因此由于每个航班正好有 15 个位置，每个航班不能超过 15 名乘务员。 p>

不幸的是，没有很好的方法来强制所有职位都被填补，因此每个航班仍然可能少于 15 名乘务员。如果这很重要，您可能必须从应用程序代码中强制执行。

--- 编辑---

要寻找一个空闲位置（用于下一个 INSERT），即使它是两个已填充位置之间的“洞”，您也可以执行以下操作（将 1 替换为所需的 FLIGHT_ID）：

SELECT DISTINCT *
FROM (
    SELECT POSITION + 1 FREE_POSITION
    FROM FLIGHT_ATTENDANT
    WHERE FLIGHT_ID = 1
    UNION ALL
    SELECT POSITION - 1 FREE_POSITION
    FROM FLIGHT_ATTENDANT
    WHERE FLIGHT_ID = 1
)
WHERE
    FREE_POSITION NOT IN (
        SELECT POSITION
        FROM FLIGHT_ATTENDANT
        WHERE FLIGHT_ID = 1
    )
ORDER BY FREE_POSITION;

此查询可能有以下结果：

• 它可以不返回任何行，表示所有位置都是空闲的，因此只需选择有效范围内的任何一个即可。
• 它可以返回行，其中第一个和最后一个可能超出有效范围，因此如果超出，请忽略它们。使用剩余的行之一。如果没有剩余的行，这表明所有位置都已被填满。

这是 Oracle 下的 working SQL Fiddle example，但同样的技术应该适用于任何 DBMS。有更优雅的、特定于 DBMS 的方法来执行这些类型的查询（特别是如果您想要 所有 个空闲位置，而不仅仅是一些），但即使是这种“通用”解决方案对于大多数实际应用来说也应该绰绰有余目的...

Answer 4

您有唯一索引（如主键）和非唯一索引： 根据您的唯一键定义允许有 1 条记录或多条记录

然后

您有空字段或强制具有值的字段： 这里你可能有 0 或 1 个值

结合这两件事，你应该能够知道，为什么他们总是说 0 或更多

ERD 不能总是强制规则，规则通常可以由数据库设计强制，但它总是需要软件的另一层（或至少存储过程）

顺便说一句，关于您的示例，如果您在每次飞行中始终有 2 名飞行员，并且您想通过数据库设计强制执行此规则，您可以简单地创建从 Pilots 表到 Flight 表的 2 个关系，是的，您将拥有同一张表的 2 个外键，ERD 允许这样做

Answer 5

E-R 图表提供了一种方法来指示每个实体参与关系的次数的限制。
实体集和二元关系集之间的边可以具有关联的最小和最大基数：min...max
min 值 1 表示完全参与。 max 值为1 表示最多参与一次，max 的* 或N 表示没有上限。
现在来回答你的问题。您的建模一开始就是错误的，因为一名飞行员会参加很多次飞行，而不是您似乎暗示的一次。
此外，如果每个航班恰好有 2 名飞行员并且两者都是必需的，那么这不会被建模为 1-N 关系，而是作为航班的 2 个属性（飞行员 ID），因为它们永远不会为空或可选（不能没有航班2 名飞行员）。
因此，常数的上限表明设计中存在一些问题，这些问题不足以对您的系统进行建模。

Answer 6

我遇到过类似的问题。我的场景是让两支足球队参加一场比赛。所以这两个表是“团队”和“夹具”。在夹具表中，我只有一个“team_home”列和一个“team_away”列。我不确定这是否是最好的甚至是正确的方法，但它对我有用。

您是如何实施 max 解决方案的？