|This week's theme: Cool Tech Tips|
Extending the Common Data Model of BMC Atrium™ CMDB
The BMC Atrium CMDB includes a Class Manager Console to manage and extend the metadata description of the common data model (CDM). The Class Manager is the interface that manages all of the class definitions for object and relationship classes. This article will discuss how to extend the CDM.
The Class Manager Console provides access to all of the various object and relationship classes of the CMDB. Through the Class Manager Console, you can add new classes or add new attributes to existing classes. Figure 1 shows the user interface for the Class Manager Console.
Note: Click images for full screen view.
|Figure 1 – Class Manager Console|
The Atrium CMDB class structure is object oriented. An object-oriented data model makes it possible to create a new class by extending an existing class. A new subclass will inherit all of the attributes and relationship membership rights of its parent classes. The base object class, from which all other classes are derived, is called BMC_AssetBase. This class contains all of the basic object attributes such as InstanceID, Name, ClassID, Category, Type, Item, etc. For customers moving from earlier versions of Remedy Asset Management, the BMC_AssetBase class schema includes a majority of attributes in common with the AST_Asset schema. This commonality enables the basic migration from the earlier versions of Asset Management, without loss of data.
There are a variety of options available for extending the data model to capture new data as required for your business needs. These options include:
- Using Category, Type, and Item instead of subclassing
- Adding attributes to existing classes
- Creating a Categorization subclass
- Creating an Abstract class
- Creating an Abstract class with data replication
- Marking a class as a "Final" class
- Creating a Subclass
Existing Remedy Asset Management customers will be very familiar with the use of Category, Type and Item attributes. If you need to further categorize a CI class that has the specific attributes you need, consider using the existing Category, Type, and Item (CTI) attributes instead of creating subclasses. These attributes, modeled on the fields by the same name in several Remedy applications, are part of the BMC_AssetBase class and are, thus, inherited by all other object classes.
You can use them to provide three levels of categorization for instances of a class without the performance cost of a subclass. For example, the class BMC_PointingDevice does not distinguish between a wired mouse and a wireless mouse. If you want to make this distinction in your data, you do not need to create subclasses called YourModel_WiredPointingDevice and YourModel_WirelessPointingDevice. Just populate the Category attribute with Wired or Wireless when creating instances of BMC_PointingDevice.
If an existing class describes your CI well, but lacks a few pieces of information, there is no need to create a subclass to hold those extra attributes. Add the attributes to the existing class to save the performance cost of a subclass. If you will need to store some CIs that use these attributes and some that don't, make the entry mode of the attributes Optional.
Adding attributes works well when you have only one variation on a class to accommodate. If you have two or more variations, each with their own set of attributes, you should create subclasses for them instead.
A categorization subclass does not create a new AR System® form to store its attributes. The attributes are added to the form of the parent class. Instances of the parent class leave the subclass attribute fields blank, while instances of the subclass use them. Because of this, no attributes of a categorization subclass can be required attributes.
An abstract class does not create a new AR System form and cannot hold any instances. It exists only to be sub-classed, allowing you to add a layer of organization without a database join.
An abstract class with data replication is like an abstract class, except that instances of its subclasses are replicated to a form that holds only the attributes of the abstract class. This means that while you cannot create instances of the class, you can search on it as you could with any regular class that had subclasses. Searching on an abstract class finds all instances of its subclass that match the search qualification, but only retrieves the attributes of the parent class.
Any of the classes described in the preceding sections have the option to be marked as final. A final class cannot be sub-classed, allowing you to control your data model.
You should create a subclass only when you need to store instances of a distinct class of objects. A new AR Form will be created to store the instances contained in a subclass, so it's important to consider the storage and performance issues when you make the decision to subclass. You also need to look closely at all of the existing subclasses as you make the decision where to initiate your new subclass. As an example, there is no specific class in the core CDM for network printers. Since a network printer has a processor and a network interface it is considered to be a computer system. If you desired to create a specific subclass for network printers, starting with BMC_ComputerSystem as the parent would be an appropriate choice, since the majority of attributes are contained within this parent class.
To better understand when to use each of the above options, a white paper titled "Extending the Common Data Model: Best Practices" is available. Download this today from Supportweb.
Senior Product Manager, Atrium CMDB
Joined Remedy in 1997
Senior Information Developer, Atrium CMDB
Joined Remedy in 1997
"Things should be made as simple as possible, but no simpler." -- Albert Einstein