Methods to extend the data model

You may find certain scenarios in your environment that require extending the existing data model. There are multiple ways in which you can extend the data model.

For a data model with the greatest simplicity and performance, some of the methods to extend the data model are ranked in this order:

1. Federation 
2. Use of Category, Type, and Item attributes 
3. Installation of a data model extension package
4. Additional attributes 
5. Additional subclasses

Federation 

Just as important as knowing how to extend the CDM is knowing when to extend it. Some situations are better addressed by storing data somewhere other than your CMDB or by using existing classes and attributes.

The CMDB should hold only common CIs and their relationships. Adding classes and attributes for unimportant CIs taxes your CMDB. Also, creating too many subclasses can leave you with classes so narrowly defined that they hold very few instances. Balance the need for categorization with the need to store similar CIs together.

Use of Category, Type, and Item attributes 

To further categorize a configuration item (CI) class that has the specific attributes that you need, consider using the existing Category, Type, and Item attributes instead of creating attributes or subclasses. These attributes are part of the BMC_BaseElement class and are thus inherited by all other CI classes. You can use them to provide 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. To make this distinction in your data, you do not need to create subclasses called YourModel_WiredPointingDevice and YourModel_WirelessPointingDevice. Just populate the Item attribute with Wired or Wireless when creating instances of BMC_PointingDevice.

Installation of a data model extension package

BMC CMDB includes classes and attributes to describe a wide variety of IT configuration items. However, you can extend the Common Data Model (CDM) and add more classes and attributes. For more information about extending the CDM, see Modifying the data model by using the class manager. 

After you extend the CDM, you can package the modified CDM by using the BMC Remedy Deployment Management console. For more information about how to package the CMDB extensions, see  Creating and deploying a package using BMC Remedy Deployment Application . After you package the extensions, you can deploy this package easily across multiple environments and servers. 

Additional attributes 

If an existing class describes your configuration item (CI) well but lacks a few pieces of information, add attributes to the existing class to store that information and avoid the performance cost of a subclass. To store some CIs that use these attributes and some that do not, 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, consider creating subclasses for them instead.

Before creating an attribute for a CI class, determine whether you want to store configuration data or lifecycle data for the CI in the new attribute. You must create a new attribute to store only configuration data for the CI. To store lifecycle data for the CI, you must add a field on the BMC Remedy ITSM Foundational form, AST:Attributes.

If you decide to add attributes, follow the Field ID rule in Naming and numbering rules for new classes and attributes in Best practices for extending the data model.

Additional subclasses

Before extending the data model, you should first make sure that an alternative would not work for problematic configuration items (CIs) and relationships. Then, you should review how the different class types extend the data model.

Considerations for extending the CDM

Before you add classes for configuration items (CIs) and relationships, consider the alternatives, such as using federation, using the Category, Type, and Item attributes, installing an extension, and adding attributes. When one of these alternatives can address your problem, it is almost always better than adding subclasses to the common data model (CDM).

But there are situations in which none of those alternatives meets your needs, such as when you need to take the following actions:

• Refine your classification.
• Add new attributes that are not general enough for existing classes.
• Further restrict the types of CI classes that can participate in a given relationship or vice versa.

For example, BMC_HostedSystemComponent is a relationship class that relates a system to a system component, but if you needed more specific relationship types, you could create subclasses. You could create one subclass of BMC_HostedSystemComponent that relates a computer system to a disk drive and another that relates a computer system to a memory card.

You can create subclasses of both CI classes and relationship classes. When creating new classes, consider using categorization and abstract classes instead of regular classes because regular classes require more system resources, and an abundance of regular classes in your data model can slow system performance.

If you decide to create subclasses, follow the class naming rule mentioned in Best practices for extending the data model.

Regular class extentions to the data model

Creating a regular class is the most straightforward way to create a subclass, but it has the potential to affect database performance if you create too many levels of joins. The recommendation is to go no deeper than five join levels.

Use regular classes for CIs or relationships that have more than five uninherited attributes or that have any uninherited attributes that must be populated in every instance. Use a regular class for any class that you expect to contain at least as many instances as its superclass. If you expect the class to contain at least 1,000 instances, regardless of how many its superclass will contain, you might want to make it a regular class because that enables you to create indexes on it to improve search performance.

Categorization class extentions to the data model

Use categorization classes for CIs that have five or fewer uninherited attributes--none of which are required--and that have relationships to different classes. Use them for most of your relationship subclasses, because those subclasses often have no uninherited attributes. Use them also when you want to be able to access all attributes of a subclass when searching it from the form of its superclass.

Abstract class extentions to the data model

Use abstract subclasses when you need a logical class at a particular organizational level, but only to provide some common attributes that subclasses can inherit or to provide a common relationship type for those subclasses. To work with any instances of the class, use an abstract class with data replication.

The classes BMC_System and BMC_SystemComponent are examples of abstract classes created to provide a common relationship type for their subclasses. You can create a BMC_HostedSystemComponent relationship between instances of any subclass of BMC_System and any subclass of BMC_SystemComponent, because these two abstract CI classes were defined as the endpoints of that relationship class.

Abstract class with data replication extentions to the data model

An abstract class with data replication avoids a database join, thus improving performance when searching its subclasses and retrieving their instances. However, it results in slower performance when creating and modifying subclass instances, so unless you really need to search the abstract class, you should create it without data replication.

Use abstract subclasses with data replication when you want the benefits of an abstract class but also need the ability to search all its subclasses in one place.

Final class option

Use a final class when you want to prevent others from creating subclasses of a class you create. For example, if you build a C API program that performs tasks against a particular class, or use custom workflow with a particular class, you might mark it as Final so that your program or workflow does not have to account for subclass data stored with the class.

Singleton class option

Use a singleton class when you have a unique CI or relationship that you want to store in BMC CMDB. For example, you might use a singleton class for your company's CEO so that you can model the impact of particular IT resources on the CEO.

Example of extending the data model

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 Category, Type, 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 CMDB data. After referring to BMC CMDB Data Model Help in the PDFs and videos page, 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.

Related topics

Planning to use federated data