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
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
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
Entity types that do not have key attributes of their own are called weak entity
In contrast, regular entity types that do have a key attribute are called strong entity
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
and we call the relationship type that relates a weak entity type to its owner the identifying relationship of the weak entity type
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
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.