This documentation supports the 9.1 to 9.1 Service Pack 3 version and its patches of BMC Atrium Core. The documentation for version 9.1.04 and its patches is available here.

To view the latest version, select the version from the Product version menu.

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:

Regular 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.

Regular 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 BMC_ComputerSystem.

Categorization classes

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.

Categorization class

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 BMC_Memory.

Abstract classes

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.

Note

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.

Abstract class

An example of an abstract class in the CDM is BMC_SystemComponent.

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.

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

Comments

  1. Matthew Stromberg

    I have a question regarding the following comment above:  "By searching in the superclass form, you can find instances of both the superclass and the subclass".  Is this the correct behavior from performing searches in the AST forms?  I ask because in 9.1.01 there is a KB article https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=kA214000000gkr0CAA&type=Solution that indicates that the ability to view instances of subclasses from the parent class is a bug.  What is the correct behavior?

    Mar 08, 2017 03:21
    1. Anagha Deshpande

      Hello Matthew,

      I will check this with SME and will write back to you.

      Regards,

      Anagha

       

      Mar 08, 2017 08:49
    1. Chaitanya vikas Ghanta

      Hi Matthew, 

      I have checked with the SME and this behavior is as expected within CMDB. This behavior may of course be different in other applications. Please let us know if you are facing any difficulties due to this behavior. 

      Regards,

      Chaitanya

      Jul 18, 2018 01:16