Analyzing Data › Defining Entity Types, Relationships, and Attributes › Defining Entity Type Attributes › Attribute Optionality

Attribute Optionality

The optionality of an attribute indicates whether each entity of the entity type that is described by the attribute must have a known value for the attribute under consideration.

There are two options for attributes:

• Mandatory—Attributes for which each entity must have a value
• Optional—Attributes for which each entity does not need to have a value

Consider the attributes of the entity type CUSTOMER:

• Number—Each customer is always assigned a Number when the business is made aware of the customer.
• Name—Each customer with which the business deals must have a Name.
• Address
  • A customer have more than one Address.
  • A customer’s Address may not yet be known to the enterprise.
  • The customer announce a change of address, and the business may need to know the value of a former address. If so, Address is multi-valued, this is discussed later in Additional Data Modeling Topics, or clearly defined as being the current address only.
• Phone Number
  • A customer may have no telephone, or that the Phone Number is not yet known to the enterprise. If the business accepts customers with no telephones, then some customer entities exist with no value for their Phone Number attribute.
  • A customer may have more than one Phone Number.
• Status—Each customer is always assigned a Status when the business is made aware of the customer.
• Credit Rating—Some customers may not require credit, preferring instead to pay cash for all purchases. In such a case, the attribute Credit Rating would not have a value.
• Date Known—The date on which the business became aware of the customer always be present.
• Outstanding Orders Value—The Outstanding Orders Value for a customer always has some value, even if it is zero.

Of the attributes for the entity type CUSTOMER, five are mandatory and three are optional as summarized in the following table.

As with relationship memberships, the optionality of an attribute can sometimes be affected by a combination of values of other relationships and attributes. In this case, the combination can be represented as an optionality condition.

There are three types of attribution optionality conditions:

• Required—A pairing must exist if the condition is true.
• Forbidden—A pairing may not exist if the condition is true.
• Unrestricted—The pairing can exist regardless of other values.

For example, assume that the attribute Status can have an attribute value of Cash Only and that only CUSTOMERs with that Status are allowed to have no Credit Rating. The following optionality condition would apply to Credit Rating: Required when Status is not equal to Cash Only.

Forbidden conditions are not nearly as common as Required ones, but they are possible. Consider the case where another possible value of Status is Highly Credit Worthy. Assume that the business wants to avoid offending such CUSTOMERs with queries about their credit worthiness and to forbid the inclusion of a value for Credit Rating for them. Further assume that the previous Cash Only optionality condition is true.

The new optionality conditions for Credit Rating are:

• Required when Status is not equal to Cash Only and Status is not equal to Highly Credit Worthy
• Forbidden when Status is equal to Highly Credit Worthy

When you find that the same integrity condition determines the existence of several optional attributes and relationship memberships, it is worth considering defining a subtype or another entity type and moving the affected attributes and relationships so that they describe only entities of that subtype.

Using CA Gen, optionality conditions for an attribute is specified as part of its description.

More information:

Defining Partitioning