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.

Denormalized CMDB Data Storage

The following topics discuss Denormalized CMDB Data Storage (DCDS).

Note

Denormalized CMDB Data Storage is also referred to as CDM Denormalization.

Understanding Denormalized CMDB Data Storage 


 https://youtu.be/MtBvuXEA2OA

The amount of Configuration Item (CI) information in the BMC Atrium CMDB is increasing day by day. The increasing amount of data affects the performance of the different components within the BMC Atrium Core ecosystem while also leading to performance issues for the producers and consumers of CI data. To address the performance issues, you must minimize the number of tables or forms in which different but related pieces of CI data are stored, which can be accomplished using Denormalized CMDB Data Storage (DCDS) concept.

DCDS can be achieved by converting regular classes into categorization classes and storing all related CI data in fewer or a single form or table, thereby optimizing the read and write performance of the database.

The need for Categorization subclass
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. To avoid an additional join, a categorization subclass is created in the  CMDB.

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

The categorization subclass attributes are stored on the parent form. You must ensure that those attributes are not defined as Required or Mandatory. If the attributes are defined as Required, when you create a CI for the parent class, then the workflow will make it mandatory to enter the attribute values, even though they do not really have context in the parent class. This is the main limitation when using the categorization subclass.

DCDS results in optimizing the class join hierarchy by converting regular classes into categorization subclasses thereby improving the create, read, update, delete (CRUD) throughput, and hence the performance of BMC Atrium CMDB.

DCDS also improves reconciliation performance during the loading of data into BMC Atrium CMDB.

Regular classes converted to categorization subclasses

The following regular classes and relationships are converted to categorization subclasses:

Classes in DCDS

  • BMC_LogicalSystemComponent
    The following  fields related to the attributes of the BMC_LogicalSystemComponent class in DCDS 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 DCDS 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

Relationships in DCDS:

  • 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

Adding a categorization subclass as a child of an abstract class

You can now add categorization subclass as a child of abstract class with data replication. When you do so, consider the following factors:

  • 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

Scenarios 

The following scenarios describe how a DCDS can be created.

Scenario for a class in DCDS

The following diagram illustrates the comparison between existing CDM classes hierarchy and the CDM classes hierarchy in DCDS.

In the existing CDM class hierarchy, when you create or update an instance of the BMC_Product class, the following conditions occur:

  • 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 BMC_Product and BMC LogicalSystemComponent classes are categorization subclasses.
  • The instance data is directly stored in the BMC_BaseElement class (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.

Scenario for a relationship in DCDS

 

In the existing CDM relationship hierarchy, when an instance of BMC_Component relationship class is created or updated:

  • The instance data is stored in the BMC_Component, and BMC_BaseRelationship classes.
  • 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.

In the denormalized CDM relationship hierarchy, when you create or update an instance of the BMC_Component relationship class:

  • BMC_Component is the categorization subclass. 
  • The instance data is stored directly in the  BMC_BaseRelationship (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.

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

Comments