Home/ Questions/Q 8529227
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T08:59:03+00:00

In every tutorial on entity relationship diagrams, I read that specifying a fixed cardinality

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0