Continuing with the language of tables to distinguish between mandatory and optional relationships, an optional relationship exists for a table when there is no requirement for any records to exist in that table before any records can be added to the associated table. Consider the following example, with a focus on the italicized portion:
A customer may place many orders; every order is placed by a customer.
According to this rule, a customer may place
many orders, or place just
one order,
or never place an order at all (potential customers are often found in databases, as are potential suppliers).
All three possibilities are options for actual customers who exist in the Customers table.
Put simply, it is not necessary for any records to exist in the Orders table before customers can be entered into the Customers table.
Reverting again to the language of entities, the type of participation for the ORDER entity in the CUSTOMER:ORDER relationship is designated as
optional. The optional entity is termed a
weak entity.
To understand how important it is to know that CUSTOMER is a
mandatory entity[1] and ORDER is a
weak entity, consider once more the general rule for 1:N (one-to-many) relationships:
A
one-to-many (1:N) relationship exists when, for one instance of entity A, there exists zero, one, or many instances of entity B; but for one instance of entity B, there exists zero or one instance of entity A.
Now plug in the entities from the CUSTOMER:ORDER relationship, again focusing on the italicized portion:
A 1:N relationship exists when, for one instance of CUSTOMER, there exists zero, one, or many instances of ORDER; but for one instance of ORDER
there exists zero or one instance of CUSTOMER.
To accommodate the weak entity ORDER, the “zero” must be removed from the italicized portion; it is mandatory that one instance of CUSTOMER exist. That is why CUSTOMER has
mandatory participation.
[2]
Entity types that do not have key attributes of their own are called
weak entity types.
In contrast, regular entity types that do have a key attribute are called
strong entity types.
Entities belonging to a weak entity type are identified by being related to specific entities from another entity type in combination with one of their attribute values. We call this other entity type the identifying or
owner entity type,
[3] and we call the relationship type that relates a weak entity type to its owner the identifying relationship of the
weak entity type.
[4]
A weak entity type always has a total participation constraint (existence dependency) with respect to its identifying relationship because a weak entity cannot be identified without an owner entity. However, not every existence dependency results in a weak entity type. For example, a DRIVER_LICENSE entity cannot exist unless it is related to a PERSON entity, even though it has its own key (License_number) and hence is not a weak entity.
Mandatory participation describes a relationship in which at least one record in a table must exist before any records can be added to its associated table.
Entity Patterns
Mandatory and
optional participation[5] are important considerations when establishing relationship constraints (discussed in the next module).
In a 1:1 relationship, if one entity has optional participation and the other has mandatory participation, the weak entity (the entity with optional participation) receives the key attribute from the mandatory entity to establish the link.
The following graphic illustrates the relationship between weak and mandatory entities with respect to the key attribute.