This documentation supports the 19.08 version of BMC 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 CMDB. 

As you evaluate your business environment and plan your data model, you might determine that the Common Data Model (CDM) installed with BMC 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 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 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 Atrium Configuration Management Database (BMC CMDB) data. After referring to the BMC 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



Component | ConsoleUserActionReference
BMC CMDB class managerCMDB AdministratorDefine the properties of the class, which include its type, how it stores data, and (for relationship classes) the relationship type.


Creating or modifying classes by using Class Manager


(optional) Specify permissions. If you do not specify permissions for a class, BMC 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

Learning about the common data model

Managing the Common Data Model

Modifying the data model by using the Class Manager

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

Comments