Note

 

This documentation supports the 20.16.01 version of BMC Remedyforce.

To view the latest or an earlier version, select the version from the Product version menu.

BMC Remedyforce CMDB 1.0 architecture

BMC Remedyforce Configuration Management Database (CMDB) 1.0 enables you to store information about the configuration items (CIs) that you want to track in your IT environment, and the relationships among the CIs. You can also link these CIs to change requests, incidents, problems, releases, tasks, and knowledge articles.

Note

This topic describes the architecture of BMC Remedyforce CMDB 1.0.

Starting from BMC Remedyforce version 20.14.01, an enhanced version of CMDB, referred to as CMDB 2.0, is available out-of-the-box for new installations. For information about the CMDB 2.0 architecture, see BMC Remedyforce CMDB 2.0 architecture. If you have upgraded from BMC Remedyforce 20.13.02 or earlier to version 20.14.01 or later, you must manually upgrade to CMDB 2.0.

BMC recommends that you upgrade to CMDB 2.0 because CMDB 1.0 does not support many features, such as asset management, model and location management, and data normalization. However, if you want to continue using CMDB 1.0, see Configuring CMDB 1.0.


The following topics are provided:

CMDB data model

The BMC Remedyforce CMDB common data model unifies the representation of CI data. It is designed to store data about the most common CIs and provide a mechanism for linking them. It consists of classes, each representing a type of CI that can be stored in the CMDB. These classes represent the physical, logical, and conceptual entities that IT teams track in a CMDB.

A class has one or more attributes, each of which specifies a property of the class. For example, BMC_ComputerSystem has attributes such as HostName and Domain. A class can be of the following types:

  • CI class—Defines a type of CI
  • Relationship class—Defines a type of relationship between two specific CI classes.
    An instance of the relationship class relates an instance of the first, or source, CI class to an instance of the second, or destination, CI class. The two CIs are considered to be members of the relationship.
  • Abstract class—Has attributes, but you cannot create instances of this class. It exists only to organize subclasses, enabling you to add a layer of organization.

CIs can be of many different types of CIs, including computer systems, network hardware, and software servers. In the absence of a data model that accurately reflects these CI types and the types of relationships that can exist between them, your CMDB might store attributes that are not related to these CIs, leave out necessary attributes, making it difficult to search for groups of CIs.

The data model is object oriented, which means it has a hierarchical set of classes in which each class inherits attributes from its superclass—the class above it in the hierarchy—and then adds its own attributes to create a more specific type of object, a subclass. The data model also contains a base class from which all other classes are derived. The benefits of an object-oriented data model include enforcement of common attributes among similar types of CIs and the ability to search within not just a given class of CIs, but within any branch of the hierarchy. From the base class, you can search for all CIs and relationships.

CMDB 1.0 architecture

In CMDB 1.0, different objects are created for different classes. The data that is common to all CIs is stored in the Base Element object. The common field to establish a link between Base Element and other objects is Instance ID.

When users save a CI record, the common fields (shown on the General tab of the Instance Editor) are saved in the Base Element object. The fields that are shown on the Specifications tab are saved in the object for the class for which the CI is added and the parent objects of the CI class.

For example, if you are saving a Mainframe record, the data for the Mainframe CI is saved in the following objects:

  • The Base Element object, where the common fields are saved
  • The System object, where the fields that belong to the System class are saved
  • The Computer Systems object, where the fields that belong to the Computer Systems class are saved
  • The Mainframe object, where the fields that belong to the Mainframe class are saved

All of these records are accessed to show the Mainframe CI record in the Instance Editor.

Hierarchy is established by specifying the level of the class under the Base Element object in the CMDB_Class object.

Any custom field that you add to a CI type is shown on the Customs tab in the Instance Editor.

Was this page helpful? Yes No Submitting... Thank you

Comments