BMC Atrium CMDB data storage methods
BMC Atrium CMDB stores instance data by a method defined by the type of class containing each instance. BMC Atrium CMDB provides the following types of classes:
A regular class stores the data for its attributes in its own BMC Remedy AR System form. If it is a subclass, that form is a join form that joins the attributes of the superclass with the attributes unique to the subclass.
The following figure shows the forms for a new regular class, with the lines representing a join between the superclass and the form containing the uninherited attributes of the new class.
By searching in the superclass form, you can find instances of both the superclass and the subclass. This is a useful way to search when you do not know which class an instance is stored in. However, you must then go to the subclass form to see all attributes of the instance.
An example of a regular class in the Common Data Model (CDM) is
A categorization class does not have its own BMC Remedy AR System regular form. Its uninherited attributes are added to the form of its immediate concrete superclass. Instances of the superclass leave these subclass attribute fields blank, whereas instances of the subclass use them. Because of this, no attributes of a categorization class can be required attributes.
A categorization class does have its own join form, though this is only for the purpose of providing a form (and SQL view) that uses the actual class name. The join form is a join of the superclass form and a stub form with no records, and is not part of the inheritance tree. Any subclasses of the categorization class are joined to the superclass form, and not to the join form.
The following figure shows the forms for a new categorization class. The superclass form has one column containing an attribute from the categorization class. The instance of the superclass does not have a value in this column, whereas the instances of the new class do.
This data storage method avoids adding a database join to its subclasses. A join form is still created for the purpose of giving the categorization class a form (and therefore a database view) that uses its name, but that form is joined to a stub form and is not used by any subclasses.
As with a regular class, you can search in the superclass form of a categorization class and find instances of both the superclass and the subclass. But with a categorization class, you have access to all the attributes of that subclass.
An example of a categorization class in the CDM is
An abstract class does not have its own BMC Remedy AR System form and cannot hold any instances. It exists only to organize subclasses, enabling you to add a layer of organization without a database join.
Abstract classes are not commonly used. They are intended for special cases.
The following figure shows the forms for a new abstract class with two regular subclasses. The lines represent the joins between the superclass and the forms containing the new subclasses' attributes.
An example of an abstract class in the CDM is
Abstract classes with data replication
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 only when you want the benefits of an abstract class and also need the ability to search all its subclasses in one place.
The following figure shows the forms for a new abstract class with data replication and two subclasses created from it. The lines without arrows represent the joins between the superclass and the forms containing the new subclasses' attributes, and the lines with arrows represent data being replicated up to the level of the new class.
Abstract class with data replication
There are no examples of an abstract class with data replication in the CDM.