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.
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
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:
Base Elementobject, where the common fields are saved
Systemobject, where the fields that belong to the System class are saved
Computer Systemsobject, where the fields that belong to the Computer Systems class are saved
Mainframeobject, 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
Any custom field that you add to a CI type is shown on the Customs tab in the Instance Editor.