In which the author illuminates a final set theoretic concept which brings the reader perilously close to the act of relational database design.

Many of the concepts I discuss in blogs involve common sense things that we are all familiar with, but the discussion adds some precision to the thinking, and some nomenclature that eases discussion. With relational database design, most of these concepts are grounded in mathematics.

When it comes to deciding which things get their own table, cardinality is one of the easiest conceptual tools to use. Cardinality is a mathematical word for something simple, the number of objects in a set. Cardinality is sometimes indicated by the vertical bar |. For example the cardinality of {1,2,3} is 3; otherwise expressed as |{1,2,3}| = 3. Why learn a new word for something we already know? Its for precision and brevity of expression. The word itself sets the context for what is being conveyed. For a developer, there are very few discussions that use the word ‘cardinality’ which do not refer to relational database design.

A brief example to assist your understanding. Let’s pretend we are discussing an extremely simple property tax system. We start to model it and come up with a ‘property’ table. The elements of this table represent land parcels that exist in the real world. Then we want to add building information to the table, so we add a building value attribute. After some discussion, we learn that some property parcels can have more than one building.

At this point we can say “The number of properties does not equal the number of buildings.” Its more elegant to say “The cardinality of the properties does not equal the cardinality of buildings.”
And knowing of unequal cardinalities, you generally know that you need two tables. One table cannot accurately depict the information. Thus ends the lesson for today…