Understanding the Common Data Model

The Common Data Model (CDM) is the definitional language used to integrate understanding and the exchange of data between Tivoli® management products concerning resources and components of a customer's business. The CDM is the model used to communicate details about resource instances with the IBM® Tivoli Application Dependency Discovery Manager (TADDM) database.

The CDM is entirely composed of data definitions. These definitions are characteristics that identify resources, their meanings, and any restrictions on their lengths or values. The content of the CDM is obtained by the merging of applicable industry information and data model standards and the data models used by our current products into a single, converged model. It incorporates the following standards:
  • Distributed Management Task Force (DMTF) Common Information Model (CIM) standard
  • The following Business Process standards:
    • Business Process Execution Language (BPEL),
    • IT Infrastructure Library (ITIL) specification
    • LDAP directory schema
  • The following domain specific standards:
    • TeleManagement Forum (TMf),
    • Storage Networking Industry Association (SNIA), and more.

The Common Data Model is in use by multiple applications, including TADDM. The applications that use the CDM are able to share definitions and terminology for resource instance data that is common between them, enabling the construction of higher-level applications that encompass the overall management environment and share information between those systems. The CDM describes the input and output contents of the TADDM API, sensors, utility applications, and Discovery Management Console.

The CDM is different from a schema. A schema, is usually associated with a database, includes both the organization of data into a logical model and the specification of how that data is stored in specific columns of specific tables (also known as the physical model of the database). The CDM represents a logical model composed of definitions that enables consistent identification of resource instances, information about them, and relationships between them. The data model links business and IT processes with the systems that provide them, the users that invoke them, the policies that control them, the resources that processes use, and much more. The CDM classifies and organizes the most commonly managed characteristics of users, resources, and business IT information and processes and presents them in a way that all applications can use.

For more details on CDM, see the following information:
The Common Data Model has the following characteristics:
  • It does not define the physical schema, nor does it define how a management system operates.
  • It defines the resources and characteristics of a management environment that the management system monitors, analyzes, and controls.
  • It is also in use when management applications exchange information about resource instances and their relationships to other resources.
  • It standardizes the characteristics, the concepts of classes, attributes, interfaces, naming rules, naming policies and the data types that are in use.
  • It provides consistent definitions of items, best practices for content, and guidelines for mapping resource instance data to the CDM.
The Common Data Model includes the following objects:
Classes
Have the following characteristics or rules:
  • A Class is a construct used to group related attributes.
  • Classes are the representation of a resource instance type (for example, an OperatingSystem as a type of resource instance).
  • As the basic structure of the model, classes contain attributes, implement interfaces, and can optionally be involved in relationships.
  • Classes are hierarchical and inherit the properties of parent classes.
  • Classes can also explicitly include properties that pertain to a level of detail.
  • Instances of classes represent the actual resource instances, the nouns representing the physical or logical resources in the environment.
  • Instances have attributes and can take part in relationships. For example, in a database management environment, items such as the database server, tables, and connections are Instances.
    Note: Instances also include things that are not limited to being managed but which take part in the management process, such as users or business systems.
  • Out of the various objects in the CDM, Classes are the only ones in use to represent resource instances. There are particular classes mentioned throughout the TADDM documentation that have particular meaning:
    • ModelObject - This class represents the base or root class in the CDM. All classes derive in some way from ModelObject. The term ModelObject is used in the documentation to represent any defined class in the CDM.
    • ManagedElement - This is another representation of a base or root class in the CDM, and directly corresponds to the DMTF Common Information Model representation with the same name. The term ManagedElement is also used in the documentation to represent any defined class in the CDM. The ModelObject and ManagedElement classes are used interchangeably.
    • ManagementSoftwareSystem - Also known as a MSS, this class represents the management products that are providing data to TADDM through some mechanism. Each provider of data (including TADDM's sensors) are represented as a resource instance of the type ManagementSoftwareSystem.
  • The CDM supports specialization through single inheritance, although the use of interfaces gives the model some aspects of multiple inheritance. All classes are organized into a single-rooted, single inheritance hierarchy with the ModelObject class as the root. Every class, with exception of ModelObject, specifies exactly one parent, and the child class inherits all characteristics of the parent class.
  • The CDM additionally includes naming rules for model objects that specify the attributes required to uniquely name objects in TADDM. See the section on Naming instances for more information about naming rules for model objects.
  • Persistent vs. Non-Persistent classes:
    • A persistent class is a class whose instances can be stored in a database, whereas instances of a non-persistent class cannot be stored in a database.
    • When using MQL (Model Query Language), you can only query objects of persistent classes. The only exception is when you query the attribute, "guid" of a ModelObject (non-persistent class), as in the following example:
      • The attribute, "source", is a ModelObject, and the following queries return the same results: 
        SELECT * FROM TransactionalDependency WHERE source.guid == 'E72B13789C9039BFB32E3822FE50C197'
        SELECT * FROM TransactionalDependency WHERE source == 'E72B13789C9039BFB32E3822FE50C197'
    • In the model Javadoc (Javadoc for TADDM's CommonDataModel), if the tag, ‘Persistable', is set to true for a given class, then it is a persistent class. If the tag is not present for a given class, then it is a non-persistent class.
      • Examples of persistent classes: ComputerSystem, SoftwareModule, AppServer
      • Examples of non-persistent classes: ModelObject, Database, LogicalElement
Attributes
Have the following characteristics or rules:
  • An attribute defines a particular property that is valid for a class.
  • Each attribute has a particular meaning or semantic in terms of expected content.
  • Attributes are specified on CDM classes as well as interfaces.
  • Instances of attributes are the adjectives that describe characteristics of instances and serve to differentiate instances of the same class, such as the different Manufacturer of instances of the class ComputerSystem.
  • When a resource instance is created, there is the ability to store data for any attribute valid for a resource instance.
  • Not all attributes are required to contain a value, however, there are some attributes that are in use to represent a unique identity for a resource instance. These attributes are often referred to as identity attributes.
Interfaces
Enable the convenient reuse of a set of attributes and provide increased flexibility in the definition of relationships. For example, the attribute VersionString is a valid attribute for several different (class) types of resource instances. Rather than duplicating the attribute across multiple classes in the CDM, an interface is created to represent the set of attributes that pertain to version data.

Resource instances cannot be based on a interface. Any class that implements a interface automatically receives the set of attributes and relationships from the interface as if they existed on the class. Interfaces are hierarchical and can derive their attributes and relationships in the parent interface from inheritance.

There is a particular interface mentioned throughout the TADDM documentation that has a particular meaning. This interface is called a Configuration Item. The interface Configuration Item is used to denote particular classes in the CDM of which instances act as a Configuration Item defined by the corresponding ITIL term. Certain classes in the CDM, such as financial data, are not defined to be Configuration Items, as the CDM represents aspects from various environments.

Relationships
Have the following characteristics or rules:
  • Associations between two resource instances, showing how resource instances are related to each other.
  • Relationships can only be between classes, and are between classes of the same or different types.
  • Each relationship has a particular definition, or type. These different relationship types carry a certain semantic that pertains to the kind of association between the resource instances.

    For example, one of the relationship types in the CDM is manages. which represents the source instance participates in a controlling role to the target resource instance in the relationship. Another relationship type is installedOn, which represents the source instance as an object that is installed on the target resource instance. Both of these relationships can be valid on resource instances where the source is a instance of the class Agent and the target is a instance of the class OperatingSystem, however the two relationships have very different meanings. There can be multiple relationships between the same two classes (and the same two resource instances). Each relationship forms an association between two instances.

    In the CDM each relationship instance has a source and a target, which are the relationship's roles. The number of instances that can take part in each role is important. Certain relationships only allow one instance to take part. Others allow any number of instances. The number of instances that can participate in each role is known as the cardinality of the relationship.

Data Types
The information contained in attributes and measurements must be presented in a well-known syntax, and for this purpose the CDM defines a set of data types that should be used for representing entity information.

The data types defined in the model do not specify a physical representation for the data, rather they specify the lengths of data and sometimes the encoding or best practice for the content of the data.

The model also includes enumerated data types that enable products to understand the common meaning of certain values