What is the difference between Max Cardinality and Min Cardinality?

Question

I am having a hard time understanding what is the difference between the Max and Min cardinalities when trying to design a database.

Answer 1

Remember cardinality is always a relationship to another thing.

Max Cardinality(Cardinality) Always 1 or Many. Class A has a relationship to Package B with cardinality of one, that means at most there can be one occurance of this class in the package. The opposite could be a Package has a Max Cardnality of N, which would mean there can be N number of classes

Min Cardinality(Optionality) Simply means "required." Its always 0 or 1. 0 would mean 0 or more, 1 ore more

There are tons of good articles out there that explain this, including some that explain how to even property "diagram". Another thing you can search for is Cardinality/Optionality (OMG Terms) which explains the same thing, Optionality is "Min" Cardinality is "Max",

---

From http://www.databasecentral.info/FAQ.htm

Q: I can see how maximum cardinality is used when creating relationships between data tables. However, I don't see how minimal cardinality applies to database design. What am I missing?

A: You are correct in noticing that maximum cardinality is a more important characteristic of a relationship than minimum cardinality is. All minimum cardinality tells you is the minimum allowed number of rows a table must have in order for the relationship to be meaningful. For example, a basketball TEAM must have at least five PLAYERS, or it is not a basketball team. Thus the minimum cardinality on the PLAYER side is five and the minimum cardinality on the TEAM side is one.

One can argue that a person cannot be a player unless she is on a team, and thus the minimum cardinality of TEAM is mandatory. Similarly an organization cannot be a basketball team unless it has at least five players. The minimum cardinality of PLAYERS is mandatory also. One could argue in the opposite direction too. When a player quits a team, does it cease to be a team until a replacement is recruited? It cannot engage in any games, but does it cease to be a team? This is an example of the fact that each individual situation must be evaluated on its own terms. What is truth in THIS particular instance? The next time a similar situation arises, the decision might be different, due to different circumstances.

Answer 2

Agree with other answers, here's a slightly different view. Think in terms of optionality and multiplicity. Take an example: Person has Address.

Optionality asks: Does every Person need to have an Address? If so the relationship is unconditional - which means minimum cardinality is 1. If not, then min cardinality is 0.

Multiplicity asks: Can any given Person have more than one Address? If not, the maximum cardinality is 1. If so the maximum cardinality is >1. In most cases it's unbounded, usually denoted N or *.

Both are important. Non-optional associations make for simpler code since there's no need to test for existence before de-referencing: e.g.

a=person.address()

instead of

if (person.address !=null) {
  a=person.address()
}

Addresses are a good example of why Multiplicity is important. Too many business applications assume each person has exactly one address - and so can't cope when people have e.g. holiday homes.

It is possible to further constrain the cardinality, e.g. a car engine has between 2 and 12 cyclinders. However those constraints are often not very stable (Bugatti now offers a 16 cylinder engine). So the important questions are optionality and multiplicity.

hth.