Unified notation resolves relationship label ambiguity in database diagrams
Look Here or Look Across: Unified Cardinality Constraints for N-ary Relationships
Databases
Summary
In diagrams that show how things relate in a database, labels on lines can be read two opposite ways, causing confusion. The authors show that the common ways to read these labels give completely different meanings, especially when more than two things are related. They propose a new way to write these labels to avoid confusion and handle complicated relationships involving many entities. They also explain how many constraints come from a relationship and how some can be logically inferred. To make this clear, they walk through an example from a business setting.
What this means in practice
- •For database designers: Create clearer database designs by using a notation that avoids misreading relationship constraints in complex entity diagrams.
- •For business analysts: Translate business requirements into fully expressed relationship constraints to improve communication and minimize design errors.
Authors
Huanyi Chen
Abstract
A cardinality constraint written on an edge of an entity-relationship diagram admits two opposite readings. Under the reading used by UML and by Chen's original model, the label is read with the entity set on the same side of the relationship; under the reading used by standard database textbooks, it is read with the entity set on the opposite side. The two readings are exact opposites, so a reader who assumes the wrong one takes away the opposite of what the designer meant. For binary relationships the difficulty is confined to interpretation, because the two constraints a binary relationship set admits can both be drawn. For relationships among three or more entity sets the picture is worse: a ternary relationship set admits twelve cardinality constraints, and a diagram with three edges can carry at most three of them. This paper presents a notation, Card(R; p; q) = (lower, upper), that removes the ambiguity without taking a side in it, and that is not limited to one constraint per edge. We give the number of constraints an n-ary relationship set admits, show which of them a design determines without ever writing them down, and state two inference rules, decomposition and augmentation, that derive one constraint from another, together with the side conditions under which each is sound. We close with a worked case study that turns three business requirements into three explicit constraints and nine more that the design decides on its own.