Cardinality is the term used in database relations to denote the occurrences of data on either side of the relation. In the common data architecture, cardinality is documented with data integrity but not with data structure.

There are several types of cardinality defining relationships between occurrences of entities on two sides of the line of relationships.

The Link Cardinality is a 0:0 relationship and defined as one side does not need the other to exists. For example, in a person and parking space relationship, it denotes that I do not need to have a person to have a parking space and I don’t need a parking space to have a person either. It also denotes that a person can only occupy one parking space. This relation need to have one entity nominated to become the dominant table and use programs or triggers to limit the number of related records stored inside the other table in the relation.

The Sub-type Cardinality is a 1:0 relationship and defined as having one optional side only. An example would be a person and programmer relation. This is a 1:0 relation meaning that a person can be a programmer but a programmer must always be a person. The mandatory side of the relation, in the case the programmer side, is dominant in the relationship. Triggers and programs are again used in the controlling the database.

The Physical Segment Cardinality is 1:1 relationship and it is demonstrated that both sides of the relationship are mandatory. Example may be a person and DNA patters. This relationship show that a person must only have one set of DNA patterns while the DNA patters as dictated by nature can only be applied on one person.

The Possession Cardinality is a 0:M relation (zero to many) relationship on both sides. For example, a person may own no phone or maybe plenty of phones but a phone may have no owner but has a potential to be owned by a person. In database implementation, a nullable foreign key column in the phone table is used to reference the person in its table.

The Child Cardinality is a 1:M mandatory relationship and is one of the most common relationships used most databases. An example would be a person table and membership table relationship. This relationship denotes that a person can be a member or not but a person can also be a member of many organizations. The foreign key in the membership table has to be mandatory and not null.

The Characteristic Cardinality is a 0:M relationship which is mandatory on both sides. An example would be a person and name table relationship. This denotes that a person should have at least one name but may also many names. The database implantation for this cardinality involves a nullable foreign key in the name table to the person table.

The Paradox Cardinality is 1:M relationship which is mandatory to one side. An example would be a person table and citizenship table relationship. The Paradox is similar to the Physical Cardinality. A person must have a citizenship and citizenship must have a person. But in this case, a person may have multiple citizenships.

The Association Cardinaltiy is a M:M (many to many) relationship which may be optional on both sides. An example would be a person table and employer table relationship where a person may work for several employers or no employer at all. On the other hand, an employer may have no employee too but can have a several employees as well. A database implementation for this is to create a third associate entity.