Understanding Relationship Cardinality
Cardinality describes the quantitative dimension in the relationship between a pair of entities as viewed from the perspective of the parent entity. Fundamentally, it asks the question, "How many corresponding instances in the child entity might I find for any given primary key value of the parent entity?" The answer can range from zero to many (N).
To illustrate the use of cardinality, we start with the example of Customer and CustomerNote. In this example, customer is the parent to CustomerNote via an identifying relationship. Although a Customer must identify every CustomerNote, this does not mean that every Customer must have a CustomerNote, since this assertion would be impractical. In order to accommodate flexible business practice, we would set cardinality to One-to-Zero or More (each Customer may have zero or more CustomerNotes).
To contrast the use of cardinality, let's now take the example of Order and OrderDetail. Of course, every Order must have at least OrderDetail, otherwise how would we know what a customer has purchased? In this example, we would set cardinality to One-to-One or More (each Order must have at least one OrderDetail).
| Although cardinality is a powerful concept for expressing business rules, you should know that no database can directly enforce cardinality. In order to enforce cardinality constraints, you must effect it through procedural database logic or somewhere other than in the database. |
Cardinality Notation
Cardinality is read as the ratio of related parent and child entity instances. The cardinality ratio for the parent entity depends on whether the relationship is mandatory (one or more) or optional (zero or more). IDEF1X supports four different cardinality ratios for the child entity: zero-or-more, one-or-more (P), zero-or-one (Z), and exactly N (N). The IDEF1X notation is illustrated below: