BMC Remedyforce CMDB architecture

BMC Remedyforce Configuration Management Database (CMDB) 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.

Based on the BMC Remedyforce version that you are working on, you are using one of the following versions of the CMDB.

• 20.13.02 or earlier: CMDB 1.0
• 20.14.01 or later: CMDB 2.0

Both CMDB versions implement the object-oriented architecture in your database. However, there are advantages to using CMDB 2.0. For more information, see Comparison of features in CMDB 1.0 and 2.0. When you upgrade from an earlier version to 20.14.01 or later, you have the option to upgrade to CMDB 2.0. For more information, see Upgrading to CMDB 2.0.

The following topics are provided:

CMDB data model

The BMC Remedyforce data model is a set of CIs and relationships. It consists of classes, each representing a type of CI that can be stored in the CMDB. These classes are intended to represent the physical, logical, and conceptual items that all IT environments 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.

You have many different types of CIs, from computer systems to network hardware to software servers. Without a data model that accurately reflects these types and the types of relationships that can exist between CIs, your CMDB might store attributes that do not pertain to their CIs, leave out necessary attributes, and make it harder to search for groups of CIs.

The data model is object oriented, which means that 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 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 a base class from which all others are derived, you can search for all CIs or all relationships.

Click here to see the hierarchical diagram of all classes in the Common Data Model (CDM), including unique attributes. The CMDB Common Data Model section also provides detailed information about classes and attributes in the CDM.

CMDB 2.0 architecture

CMDB 2.0 provides a flattened structure to store CIs. All the CI records are saved in one table (or object); Base Element. Different field sets, corresponding to the CMDB classes, are provided in the Base Element object. For example, for the Computer System class, the Computer System field set is provided in the Base Element object. However, records of all CIs are saved in the Base Element object.

Hierarchy in classes is maintained by using the CMDB_Class object.

The following points describe how object-oriented architecture is implemented:

• Each class is implemented as a field set in the Base Element object.
• Each attribute is implemented as a field in the Base Element object. Attributes that are common for all classes are grouped in the Base Element field set in the Base Element object. Fields that are specific to a class are grouped under the field set of the class, for example Mainframe.
• The class hierarchy is implemented by using the CMDB_Class object. For each class, an entry is created in the CMDB_Class object that identifies the hierarchical level of the class in the CMDB.

By default, the Base Element field set contains all of the fields that are shown on the General tab in the Instance Editor that you use to view, add, and edit CI records. The fields in this field set are common for all of the CIs. In the Specifications tab, fields from the class-specific field set and the field sets of all of its parent classes (excluding Base Element) are shown. For example, in the hierarchy of Base Element > Systems > Computer Systems > Mainframe, in the Specifications tab of a Mainframe record, fields are shown from the Mainframe, Computer System, and Systems field sets.

The following figure shows the Instance Editor for a Mainframe record.

Related video

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 a CI record is saved, 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.