5.3. Uniqueness Constraints and Standard ID Attributes

An ID (or unique) attribute or attribute combination, also called key, has unique values that can be used for identifying an entity. An ID attribute represents a uniqueness constraint requiring that an attribute's value is unique among all entities of the given type.

For instance, in a UML class diagram representing a design model and containing the entity type Book we can define its isbn attribute and its doi attribute (holding the digital object identifier of the book) to be unique, or, in other words, to be a key, by appending the keyword "key" in curly braces to the attribute's definition in the Book class rectangle, as shown in Figure 5-5.

Figure 5-5. A design model class with two unique (or key) attributes.

A standard ID attribute (combination), also called primary key, is a mandatory unique attribute (combination) that has been chosen among the ID attributes of the given class for providing the standard ID of an entity.

In a UML class diagram representing a design model, the standard ID attribute (combination) is marked up with the keyword "id" (as a ' property modifier') enclosed in curly braces.

Since the doi attribute is optional, it cannot be used as the standard ID attribute. Only the isbn attribute satisfies the requirements of a standard ID attribute and is designated as such in Figure 5-6.

Figure 5-6. A class with a (mandatory) standard ID attribute *isbn* and an optional unique attribute *doi*.

All entity types in a design model must have a standard ID attribute (combination). Since the subtypes of a type hierarchy inherit the standard ID attribute (combination) from their supertypes, there is no need to define one for them, as shown in Figure 5-7.

Some entity types may come with a natural ID attribute in a conceptual model. For instance, the entity type books would be modeled with an isbn attribute, the values of which are unique book numbers. Whenever there is such a natural ID attribute, It is preferable to use it as the standard ID attribute of en entity type.

For other entity types, an artificial ID attribute has to be added for obtaining standard IDs for their instances. Such an attribute (sometimes called a surrogate key) is often defined as an automatically incremented sequence number. But it could also hold any alphanumeric code values.

For instance, in Figure 5-7, the class Person has a natural standard ID attribute, socSecNo, holding social security numbers, while Movie does not have such an attribute and, therefore, an artificial (integer-valued) standard ID attribute, called "id", has been added to its set of attributes.

Figure 5-7. The entity types "Director" and "Actor" inherit the standard ID attribute "socSecNo" from "Person".

Notice that a standard ID declaration implies both a mandatory value and a uniqueness constraint on the attribute(s) concerned.

Composite Standard IDs

Often, practitioners recommended not using a composite ID as a standard ID, since composite IDs are more difficult to handle and not always supported by tools. Whenever the instances of an entity type do not have a simple ID, but only a composite one, it may therefore be preferable to add an artificial standard ID attribute (also called surrogate key) to the entity type.

However, each additional surrogate key has a price: it creates some cognitive and computational overhead. Consequently, in the case of a simple composite ID, it may be preferable not to add a surrogate key, but use the composite ID as the standard ID.

There is also an argument against using any natural attribute, such as the "isbn" attribute in the case of books, for a standard ID. The argument points to the risk that the values even of natural ID attributes like "isbn" may have to be changed during the life time of a business object, and any such change would require an unmanageable effort to change also all corresponding ID references. However, the business semantics of natural ID attributes implies that they are frozen. Thus, the need of a value change can only occur in the case of a data input error. But such a case is normally detected early in the life time of the object concerned, and at this stage the change of all corresponding ID references is still manageable.