Denormalization of the Common Data Model

With an increasing number of CIs getting stored in the CMDB over time, the performance of the different components within the CMDB gets degraded, resulting in 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. Denormalization is a strategy that can be implemented to optimize the read performance of the database.

Common Data Model (CDM) denormalization, which is also referred to as denormalized CMDB data storage or CDM Flattening, is achieved by converting regular classes into categorization classes and storing all related CI data in fewer or single forms or in tables. CDM denormalization can be understood clearly with the help of the following example.

Scenarios for performing denormalization

If you have BMC Helix CMDB version earlier than 9.0, and you perform an upgrade to a version of CMDB 9.0 or later, only in that case you must perform denormalization after upgrade. If you already have BMC Helix CMDB version 9.0 or later installed on your system as a fresh installation, and you want to upgrade to any other later version, you need not perform denormalization. 

Example

In the existing CDM class hierarchy that is shown in the following figure, when you create or update an instance of the BMC_Product class, the instance information is stored in the tables of BMC_Product and all the preceding parent classes. This means that for every insert or update call that is made to an instance of the BMC_Product class, three insert or update calls are made before the instance is created or updated in the BMC_BaseElement class. 

The solution is to denormalize the BMC_Product class by converting it into a categorization class because categorization classes do not have storage, and their values are stored in the immediate parent class. When you denormalize the BMC_product class and the BMC_LogicalSystem component class, the instance data is directly stored in the BMC_BaseElement class because the abstract and categorization sub classes do not have any storage tables.

By converting a regular class into a categorization sub class, the class join hierarchy is denormalized because of which the insert, delete, and update calls are reduced when you create instances. In this example, when you create or update an instance of the BMC_Product class, insert or update calls are made directly to the BaseElement class, which means that only one insert or update call is made. Due to reduction in the number of calls, the performance of CMDB is improved significantly. If the BMC_Product class has one million CIs, three million CI calls were made before denormalization but after denormalization, only one million calls are made, which helps to improve the performance.

After denormalization, all the attributes, except the fields corresponding to those attributes, still stay with the class that they belonged to earlier. The fields corresponding to the attributes move to the immediate regular parent class, which, in this example, is the BMC_BaseElement class.

Denormalization is performed without changing the CDM logical hierarchy and without impacting the CDM hierarchical object model. Denormalization also improves reconciliation performance when data is loaded into CMDB.

The following video provides an overview of CDM denormalization:

 https://youtu.be/MtBvuXEA2OA