为什么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捕获分析而不是设计.