What is the difference between Max Cardinality and Min Cardinality?

I am having a hard开发者_如何学Go time understanding what is the difference between the Max and Min cardinalities when trying to design a database.

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.

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.

Let's work with an example -

Students takes Class. Here both Students and Class are entities.A School may or may not have students enrolled in a particular semester. Think of a school offering courses in summer semester but no student is interested to join in. So, student's cardinality can be (0,N). But if a Class is going on means, it should have at least 1 student registered. So, its cardinality should be (1,N). So, you should check whether the entity participating in the relation is partial or total, which decides it's cardinality in the relation.

Hope it helps.

Maximum Cardinality:
1 to 1, 1 to many, many to many, many to 1

Minimum Cardinality:
Optional to Mandatory, Optional to Optional, Mandatory to Optional, Mandatory to Mandatory

To your question, 'what is the use of optionality in database design?': It becomes very helpful in the scenarios like the following.

When you design 2 tables with 1-to-1 relation, you will be confused to decide where (in which table) to have the foreign key. It's very easy to decide it, if you have optionality 1 for one table and 0 for the other table. The foreign key should be present in the former. There are many other uses for it as well.

Hope it helps.

Maximum Cardinality:- one-one, one-many, many-many

Minimum Cardinality:- zero or one

This link describes my answer, why it is so, what's the representation, and what it is.