Relationships
[This content is no longer valid. For the latest information on "M", "Quadrant", SQL Server Modeling Services, and the Repository, see the Model Citizen blog.]
A relationship is a constraint over pairs of linked instances. Instances that participate in a relationship can be in different extents, or if the relationship is self-referencing, in the same extent. Relationships are not symmetric; each related instance in a relationship has a distinct role with respect to the other. Each role has a multiplicity, which defines the number of instances that can play that role with respect to a single instance in the other role. Multiplicity is expressed using an operator: “?” represents the range 0..1, “1” represents 1..1, “*” represents 0..*, and “+” represents 1..*.
Relationships as described here are always binary – involving exactly two instances. More complex N-ary relationships nearly always involve some entity that implements the relationship that can be modeled explicitly as an extent, with binary relationships between each participant and the N-ary relationship entity.
There are three basic relationship patterns that are characterized by the maximum multiplicities of the two roles in the relationship: one-to-one, one-to-many, and many-to-many. Variations of these patterns reflect whether the roles are optional (minimum cardinality is zero) or mandatory (minimum cardinality is one). In addition to these patterns of
Relationships are implemented in a relational design either using a reference from an extent to the related extent or by implementing a relationship extent that holds two references, one to each participating extent. Using a relationship extent makes the link a tangible instance in the design, which can carry additional facts. Although it is a necessary feature of some relationship patterns, using a relationship extent does introduce overhead, so direct references should be used where practical. While relationships are typically bidirectional, it is not normal to implement references from both sides of a relationship as it creates the potential for a referential integrity failure in the design – a reference on one side for which there is no inverse reference. Normally a single reference is used, usually from the ‘many’ to the ‘one’ or from the optional to the mandatory. In a relational implementation a single reference can be ‘navigated’ in either direction by query.
The following topics provide guideline information about aspects of different relationship patterns: