This documentation supports the 21.05 version of BMC Helix CMDB.To view an earlier version, select the version from the Product version menu

Modification of your data model


This use case describes how to extend your data model with the class manager in BMC Helix CMDB

As you evaluate your business environment and plan your data model, you might determine that the Common Data Model (CDM) installed with BMC Helix CMDB is not sufficient to store information for some of your assets.

Data model modification scenarios

Scenarios

The following example illustrates how you might update the data model for your particular needs.

Suppose you are a BMC Helix CMDB administrator at the fictional company Calbro Services and you want to track the model year of several of the devices on the network, such as servers, workstations, and routers. Because the model year is a critical piece of information, you want to include it in the data model. You have reviewed the recommendations in Planning-the-data-model, and have decided that the best approach is to extend the data model by adding a new attribute to an existing class.

After referring to the BMC Helix CMDB Data Model Help, you determine that the new attribute should be added to the BMC_ComputerSystem class. Because each subclass inherits attributes from its superclass, the BMC_Mainframe and BMC_Printer classes also use the new attribute.
However, not every element that can be tracked by the BMC_ComputerSystem class and its subclasses needs a model year attribute. For example, the model year is not important for load balancers and firewalls. You decide that the attribute should be optional.

Using Class Manager, you can add a new, optional attribute to the BMC_ComputerSystem class.

Note

Before extending the CDM, review the recommendations in Planning-the-data-model. Adding new classes and attributes are among the last things you should consider.

The following example shows how a fictional company Calbro Services extends the data model to track the model year of several network devices.

Calbro Services wants to track the model year of several of the devices on the network, such as servers, workstations, routers, and so on. Because the model year is a critical piece of information, the administrator wants to include it in the data model.

Working through the preferred means of building the data model, the Calbro Services administrator first considers federating the model year data. This data is not information related to configuration items (CIs), such as incident requests. Neither is it non-critical detailed information about CIs, such as service records. The model year is a critical piece of information about computer equipment used throughout the company, so the administrator discards federation as an option.

Second, the administrator considers using the existing CategoryType, and Item attributes to store the model year data. These attributes are used for classification, and are insufficient for storing model year information.

Third, the administrator considers using an existing BMC Software extension to the data model, but the model year is not included in extensions Calbro Services intends to use.

Next, the administrator considers adding a new attribute to an existing class. The model year is important to different consumers of BMC Helix CMDB data. After referring to the BMC Helix CMDB Data Model Help, the administrator learns that the new attribute could be added to the BMC_ComputerSystem class. Because each subclass inherits attributes from its superclass, the BMC_Mainframe and BMC_Printer classes could also use the new attribute. The administrator would like the option of tracking the model year of mainframes and printers, and so decides that the best approach is to extend the data model by adding a new attribute to the existing BMC_ComputerSystem class.

Workflow of data model modification by creating or modifying classes

image2019-8-23_9-52-9.png

Component | Console

User

Action

Reference

Class manager

CMDB Administrator

Define the properties of the class, which include its type, how it stores data, and (for relationship classes) the relationship type.

(optional) Specify permissions. If you do not specify permissions for a class, BMC Helix CMDB assigns default permissions.

Define one or more CI and relationship class attributes.

(optional) Propagate attributes in a weak relationship. This step is necessary only if you have created a relationship class that has a weak relationship in which the attributes from one class should be propagated to another class. 

(optional) Specify indexes. Indexing can reduce database query time, so index attributes that you expect users to use in queries frequently.

optional) Configure instance auditing for the class. Auditing enables you to track the changes made to instances of a class.

Audit of the results

The Calbro Services administrator knows that changes to the service model can be disruptive to the customers using those services. To help identify all of the changes to business services and the supporting technical services, the administrator decides to audit the BMC_BusinessService class.

Copy auditing this class should not affect overall system performance because changes to the BMC_BusinessServiceclass should be few in number. Copy auditing also enables greater ability to search for changes to the class. For these reasons, the administrator configures copy auditing instead of log auditing.

Related topics

Common-data-model

Managing-the-common-data-model

Modifying-the-data-model-by-using-Class-Manager

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*