Analyzing Data › Additional Data Modeling Topics › User-Defined Domains

User-Defined Domains

Complex and user-defined domains were mentioned in the primitive domains section. The user-defined domains define sets of possible values that are shared by multiple attributes.

For example, PRODUCTs are available in a limited number of colors. Elsewhere in the business, there is an entity type EMPLOYEE whose security badge can be one of a number of badge colors.

Assuming a standard list of colors, it is possible to have a common definition for both the PRODUCT attribute Color and EMPLOYEE attribute Badge Color, named simply Color, which has the same:

• Primitive domain
• Length
• List of permitted values

Such a definition is named a user-defined domain. The specification of the user-defined domain Color is as in the following table.

Ask whether the set of permitted values is stable or whether more colors could be added.

Assume that this is unlikely (but not impossible) for badge color but possible for product color. You have another option for modeling this situation: a new entity type COLOR with an attribute Name. The set of COLOR entities includes Red, Blue, and so forth, with the possibility of adding, for example, a Brown entity when the business needs it.

The use of domains provides some benefits over the use of discrete attribute definitions:

• Domain definitions can be shared (using the Copy attribute facility). If, however, the domain changes (a new permitted value is added), the change must be reflected manually in all the separate copied attribute definitions.
• Operations involving attributes from different domains can be restricted to avoid illogical conditions. For example, if there is one domain that is called Price and another named Quantity, it is reasonable to allow multiplication of attributes belonging to the two domains, as in: (ORDER ITEM Amount = PRODUCT Price * ORDER ITEM Quantity).

However, it is probably not reasonable to allow the attributes to be compared (If PRODUCT Price is greater than ORDER ITEM Quantity, …) or added together.

Dates should not be added, multiplied, or divided.

You can represent user-defined domains by observing the following guidelines:

• If possible, use the domain name as the name of the attribute, as in the example that is shown in the following table.

• When this convention cannot be followed easily, domain information could be recorded as part of the description, or the domain name could be included as part of the attribute name. In the following table, two attributes belong to the Color domain, so some additional qualification is required to distinguish between them.

• With reasonable domain names, in practice this convention almost implements itself. In the preceding examples, for instance, the attribute names naturally contain the names of the domains to which they belong. It is difficult to imagine a sensible formation of those attribute names that does not include the domain name. For instance, EMPLOYEE Badge Hue? Or: INVOICE Number of Things?
• An enterprise usefully assemble a set of common domain names. The following table shows some possibilities.

• Copy the definition of the attribute
• To help manipulate attributes, the copy command allows an attribute's definition to be copied to a different entity type. Through judicious use of this command, you can use an attribute in a particular domain as a basis for defining other attributes in the same domain.
• For example, the ORDER ITEM attribute Quantity could be copied to create the attribute Quantity of the entity type INVOICE ITEM. This is done by copying the definition of Quantity from the entity type ORDER ITEM to the entity type INVOICE ITEM.
• Because CA Gen does not enforce the continued use of this definition, this is not a permanent solution if the permitted values are expected to change.