How additional subclasses extend the data model
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
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.
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 in Naming and numbering rules for new classes and attributes.
When you add classes to your data model, the new classes are not automatically picked up by BMC Software products that use BMC Atrium CMDB, such as BMC Impact Solutions or BMC Asset Management. To use the new classes with one of these applications, you must customize the application. For more information, see Making data model changes visible to applications.
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.
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 Atrium 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.