为什么ERD中不允许具体的基数？ [英] Why is a specific cardinality not allowed in the ERD?

问题描述

在每个关于实体关系图的教程中，我读到不允许为关系指定固定的基数。只有对ERD的非正式评论可以澄清，飞行员的数量是恰好是2 。

所以，例如每次飞行中有两名飞行员的飞行员和飞行员之间的关系必须表示为：

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

而不是

 code>< 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是首选，因为它更简洁，除非需要更多的细节来澄清规则，例如规则存在的原因。 / p>

上面提到需要做的第二点。这是分析和设计之间的区别。如果以经典方式使用ER建模，则它是数据分析的工具，而不是数据库设计工具。 数据分析是指以数据为中心的问题分析。区分分析和设计，问题特征与解决方案的特征之间，是在正式的CS或IT教育中没有足够的教训。获取正确的东西绝对是至关重要的。

即使是那些意识到差异的人，也有时会将解决方案的功能滑落到问题的定义中。这被称为在盒子里面思考。

如果要绘制数据库设计图，请勿使用ERD。使用关系原理图，前提是您正在设计的数据库是关系型的。关系原理图包括ERD不应包括的功能，如连接表和外键。不要使用ERD作为关系精简。这不是什么。

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

In every tutorial on entity relationship diagrams, I read that specifying a fixed cardinality for a relationship is not allowed. Only an informal comment on the ERD may clarify that the number of pilots is exactly 2.

So, for example, a relationship between flights and pilots where each flight has exactly 2 pilots present, would have to be represented as:

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

rather than

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

My notation is 0..N = optional, many; 1..N = mandatory, many, 1 = mandatory, one.

Is this restriction universal? What's the reason behind it?

EDIT: clarified my notation.

EDIT: I can see how two relationships would enforce the same constraint:

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

But then a query to see if a pilot is on a given flight becomes really ugly, as you'll have to check each of two attributes. And if the number of attributes grows (say, to 15 flight attendants), the queries become completely unmanageable and the schema only barely manageable.

解决方案

The other responses have provided a few valuable pieces of the answer. Two more pieces need to be added:

First, ER modeling is more than just an ERD. We tend to try to put the entire ER model on one diagram. But complete ER modeling is a lot more than what will fit on a single diagram. There can be business rules that limit the cardinality of a relationship to no less than 10 and no more than 15. But it's important to realize that these must be "Business rules" (i.e. subject matter rules) and not design restrictions imposed for practical reasons. A complete ER model can include all of these business rules on the data and these can be expressed, if necessary, in plain English.

The notation 10..15 is to be preferred because it's more concise, unless more detail is needed to clarify the rule, such as the reason why the rule exists.

The above hints at the second point that needs to be made. It's the difference between analysis and design. If ER modeling is used in the classical manner, it's a tool for data analysis and not a tool for database design. By "data analysis", I mean problem analysis from a data centric point of view. Distinguishing between analysis and design, between features of the problem and features of the solution, is something that is not taught enough in formal CS or IT education. It's absolutely critical to getting things right.

And even those of us who are aware of the difference sometimes slip up and slide features of the solution into the definition of the problem. This is known as "thinking inside of the box".

If you want to diagram the database design, don't use an ERD. Use a relational schematic diagram, provided that the database you are designing is relational. A relational schematic includes features that an ERD ought not to include, like junction tables and foreign keys. Don't use ERD as "relational lite". That's not what it is.

Incidentally, another answer made the comment that an ERD ought to be implementable on any DBMS. That's a consequence of the concept I've just presented, that the ERD captures analysis and not design.

这篇关于为什么ERD中不允许具体的基数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！