Understanding Relationship Existence
Existence describes the relationship between a pair of entities from the perspective of the child entity. Fundamentally, it asks the question, "Is a foreign key value always required in the child entity?" The possible answers are:
To illustrate the use of existence, let's take the example of Order and OrderStatus. If you set the relationship existence to optional, then Orders could exist without being assigned an OrderStatus. Thus, you may or may not know whether any given Order is fulfilled, cancelled or on back order, which would certainly complicate business operations and probably lead to poor customer service. In this example, it probably is desirable to set existence to mandatory. However, you must enforce the specification of this information, both through your information systems and business practices.
Relationship Type Settings
- Identifying Relationships: Are always mandatory.
- Non-Identifying Relationships: Can be mandatory or optional. In the IDEF1X notation, optional non-identifying relationships are notated with a hollow diamond at the parent end of the relationship line.
- Non-Specific Relationships: Cannot be enforced in non-specific relationships because we cannot resolve many-to-many relationships.
Effect on Cardinality
Relationship existence also has implications for relationship cardinality. If a relationship is mandatory, then the cardinality must be in the form of one-to-something. If it is optional, then the cardinality would be in the form of zero or one-to-something.
Enforcing Existence in the Physical Design
ER/Studio carries the meaning of relationship to the physical design. To enforce relationship existence rules, it defaults the foreign key columns propagated by a mandatory relationship to NOT NULL. Optional relationships propagate foreign key columns that can be NULL.