Naming rules

A naming rule is a specification of how to name instances of a particular class, such as resources, people, and systems.

Naming rules contain a set of attributes that are required in order to name a given resource. The usual case for a naming rule is to group attributes together in order to form unique identity. If the name of two instances is the same, the instances are assumed to refer to the same entity. For example, different entities in a Layer 2 network are commonly identified in the same way, using a MAC address, even though the entities are instances of different, possibly unrelated classes. MAC addresses, by their structure, form a space from which all valid names for a station on a Layer-2 network can be assigned.
Note: This is separate from the type of network that is involved, which could be 10-BaseT, 1000-BaseT, or Token Ring.
There are two special cases where naming rules will contain more than just attributes.
  1. Naming Context:

    Sometimes in the naming of a resource instance, there is a minimal amount of information available to uniquely name the instance based on the attributes that are available on the class. In cases such as these, certain naming rules specify a relationship in addition to a set of attributes, as required for the naming rule. These relationships place what is known as a Naming Context on the resource instance, and require a second resource to be in use to contextually identify another resource instance.

    For example:

    • All that is known about a particular instance of an Operating System is the type of Operating System.
    • The attribute representing the type of a Operating System is not unique enough to create a unique resource instance representing the Operating System.
    • In order to use this attribute, the naming rule specifies a required installedOn relationship from the instance of the Operating System to a instance of a ComputerSystem (there is a implied requirement to also create a valid instance of a Computer System in order to create the relationship).
  2. NOT:

    Certain naming rules are in place with a defined set of attributes that are acceptable to uniquely name a resource instance in a majority of circumstances. However, there are cases in the Common Data Model where another naming rule is needed to further refine the identity of a resource, using the same set of attributes in use by another naming rule while adding additional attributes.

    Because the method to create a unique instance is based on satisfying naming rules, it is not desirable to have a naming rule with less specific requirements to generate a identity when more specific attributes are provided. In order to prevent the less specific naming rule from being used, certain naming rules use an OmittedIdentifier statement on a attribute. This is also referred to as NOT in the Common Data Model Web site section on naming rules.
    Note: You can find the Common Data Model Web site in the $COLLATION_HOME/sdk/doc/model directory.
    When this NOT operation is mentioned, the operation shows that the attribute must be null. If any content exists in the attribute mentioned in the OmmittedIdentifier (NOT) operation, the naming rule is not used to uniquely identify a resource. For example:
    • A naming rule exists on the class Activity called ActivityName.
    • This naming rule requires the attribute ActivityName to contain a value.
      • The assumption with this particular naming rule is the name of the activity is globally unique within the customer environment.
    • In the circumstances where Activity names are not unique, there is a second naming rule, called QualifiedActivity.
      • This rule requires the attribute ActivityName and an owns relationship from a instance of the class OrganizationalEntity to the instance of the class Activity
    • Because the naming rules use a common attribute, ActivityName, and one naming rule is a further refinement of another naming rule, only one naming rule should be used to name the instance of Activity.
    • Therefore, the naming rule ActivityName specified the NOT operation on the owns relationship. This means that the owns relationship must not be populated in order to use the ActivityName naming rule.
Identification is based on the generation, use, and sharing of a machine-readable, concise, and unique value for the purpose of processing identification. Resource instances that are represented by the Common Data Model have both names and identifiers:
  • The names are longer, mainly alphabetic strings that people use to refer to the entities.
  • Identifiers are shorter, dense, mainly numeric values that the management system uses to uniquely identify the entities.