Strategy to denormalize the Common Data Model

Consider the following points when planning your strategy to denormalize the Common data model.

Do not not modify the AST Forms, for example AST:PRODUCT or any higher level joins in the denormalized classes.
Do not modify the APIs, filters, or webservices level integrations that exist with BMC CMDB.
You must perform denormalization without changing the CDM logical hierarchy and without disturbing the CDM hierarchical object model.
After denormalization, all attributes stay with the class to which they belonged earlier, but the fields corresponding to those attributes move to the immediate regular parent class.
The maintenance window is kept to a minimum and there is no need to restart the Remedy AR System server.
During the actual CDM denormalization process, a parallel hierarchy is created where all the CDM denormalization changes are implemented successfully and then it is switched with the existing hierarchy.
Denormalization also improves reconciliation performance during the loading of data into BMC CMDB.

Additional considerations for your strategy

A categorization subclass is created when you have only a few attributes specific to that class, and most of those attributes are derived from the parent class. The categorization subclass is created in the CMDB to avoid an additional join.

For categorization subclass, attributes specific to the class are created on its parent form. For example, if you create a class "A" of type categorization subclass derived from the ComputerSystem class, which has attributes called Attribute1 and Attribute2, then both attributes are created on the ComputerSystem form and not on categorization subclass "A".

Limitations when using categorization subclasses

The categorization subclass attributes are stored in the parent form. You must ensure that those attributes are not defined as Required or Mandatory because if the attributes are defined as Required, when you create a CI for the parent class, the workflow make it mandatory to enter the attribute values, even if it does not have a context in the parent class. This is a limitation when using the categorization subclass.

While you run the CDM denormalization utility, any custom CatSubclass below the BMC_Software abstract class with existing attributes of custom CatSubclass then those attributes do not get moved to the BaseElement class.
After running the CDM denormalization utility, the related field to those attributes are moved to the BaseElement class. These fields are displayed automatically only for the English locale view.
After running the CDM denormalization utility, the join definition for the deprecated class below the denormalized class does not get updated with form name of parent class.

After the denormalization process is complete, you can delete the database tables corresponding to BMC_Product_, BMC_LogicalSystemComponent_, and BMC_Component_ forms. You can use Developer Studio to delete these forms.

Conversion of regular classes to categorization subclasses

The following regular classes are converted to categorization subclasses:

BMC_LogicalSystemComponent
The following fields related to the attributes of the BMC_LogicalSystemComponent class in Denormalized CMDB Data Storage are moved to BMC_BaseElement class:
- SystemClassid attribute field of BMC_SystemComponent class
- SystemName attribute field of BMC_SystemComponent class
- isVirtual attribute field of BMC_SystemComponent class

BMC_Product
The following fields related to the attributes of the BMC_Product class in Denormalized CMDB Data Storage are moved to BMC_BaseElement class:
- BuildNumber attribute field of BMC_Software class
- ProductType attribute field of BMC_Product class
- BuildType attribute field of BMC_Software class
- LicenseType attribute field of BMC_Software class
- ServicePack attribute field of BMC_Software class
- ConfigurationBasicNumber attribute field of BMC_Software class
- ContractID attribute field of BMC_Software class
- LicensesAvailable attribute field of BMC_Software class
- PatchNumber attribute field of BMC_Software class
- InstallLocation attribute field of BMC_Software class

Example

The following diagram illustrates the comparison between existing CDM classes hierarchy and the CDM classes hierarchy after denormalization.

Before denormalization, the instance information is stored in the BMC_BaseElement, BMC_LogicalSystemComponent, and BMC_Product class tables. Before the instance is created or updated in BMC_BaseElement class, an Insert or Update call is made to the BMC_Product class, the preceding BMC_LogicalSystemComponent regular class, and the BMC_BaseElement class. Three Insert or Update calls are made before the instance is created or updated in the BMC_BaseElement class table.

In the DCDS class hierarchy, when you create or update an instance of the BMC_Product class, the instance data is directly stored in the BMC_BaseElement class because abstract and categorization subclasses do not have storage tables. The Insert or Update call is made directly to the BMC_BaseElement class, thus reducing the number of calls.

Conversion of relationship classes to categorization subclasses

During denormalization, the following relationship classes are converted to categorization subclasses:

BMC_Component

The following fields related to the attributes of the BMC_Component relationship in DCDS are moved to BMC_BaseRelationship class.

IsNext attribute field of BMC_SettingsOf class
IsMaximum attribute field of BMC_SettingsOf class
IsDefault attribute field of BMC_SettingsOf class
IsMinimum attribute field of BMC_SettingsOf class
IsCurrent attribute field of BMC_SettingsOf class
IsPending attribute field of BMC_SettingsOf class

Example

The following diagram illustrates the comparison between existing CDM relationships hierarchy and the CDM relationships hierarchy after denormalization.

In the existing CDM relationship hierarchy, when an instance of BMC_Component relationship class is created or updated, an Insert or Update call is made to BMC_Component and BMC_BaseRelationship classes. Two Insert or Update calls are made before the instance is created in the BMC_BaseRelationship class. The instance data is stored in the BMC_Component, and BMC_BaseRelationship classes.

In the denormalized CDM relationship hierarchy, when you create or update an instance of the BMC_Component relationship class, the instance data is stored directly in the BMC_BaseRelationship because abstract and categorization subclasses do not have storage tables. An Insert or Update call is made directly to the BMC_BaseRelationship, thus reducing the number of calls.

Adding a categorization subclass as a child of an abstract class

By using data replication, you can add a categorization subclass as a child of an abstract class. The fields that correspond to the attributes of the abstract class are created on the form associated to the immediate super (regular) class. You cannot fetch instances of a categorization subclass that is a child of an abstract class with data replication.