Performing the CDM denormalization execution tasks
When the CDM denormalization process is performed, all the CDM denormalization changes are first implemented in the parallel hierarchy (Step 1 to Step 7) and then the parallel hierarchy is interchanged with the existing CDM hierarchy (Step 8 to Step 10).
The maintenance window is during the interchange between original and parallel hierarchy. During this stage any queries triggered on denormalized classes may give you undesired results. This is because the joins are changed from _(Underscore) forms to OBJSTR:CatClassStub thus making _(Underscore) forms, namely BMC_Product_, BMC_LogicalSystemComponent_, BMC_Component_ orphan. The data is stored in _(Underscore) form(s) and values for related fields in regular parent form (in this case BaseElement and BaseRelationship) are blank.
During data migration stage, the data is moved from _(Underscore) forms to the immediate regular parent forms for fields which are moved to the parent forms. During this period, queries fired on the denormalized classes might return undesired results. This is because if the data is not yet moved during the data migration stage, and a query is fired for the denormalized classes, the query returns blank values for the attributes.
For all the steps prior to interchange of hierarchy, there is no impact to work due to the denormalization process.
The following tasks are performed:
| No | Task | Description |
|---|---|---|
| 1 | Export existing flatten class definitions | The following definitions of the classes to be denormalized are exported to the backup folder. This is a file system backup.
|
| 2 | Create parallel class hierarchy | A parallel hierarchy of the classes to be denormalized is created with the appropriate class type as categorization sub class. This tasks helps to minimize downtime. The following classes are flattened:
|
| 3 | Move all related attributes | All the related attributes of the classes to be denormalized are moved the immediate regular class. Attributes of following classes in the parallel hierarchy are moved:
|
| 4 | Export existing refresh class definitions | Forms/views/worlfkow definitions of classes which are immediate children of the denormalized classes are exported. For regular class, the following are included:
For relationship regular class, the following are included:
|
| 5 | Export new class definitions | The class definitions of the new categorization sub classes that are created as part of parallel class hierarchy are exported to the backup folder.
|
| 6 | Modify exported new class defintions | The exported new class definitions are modified.
For example, the form name of TMP_Product form created as part of the parallel hierarchy is modified to BMC_Product from which is the actual form name. |
| 7 | Modify refresh class definitions | The refresh class definitions are updated if join definition of the classes are modifed to include immediate parent class instead of _ form. For example, Before flattening: The secondary form of the BMC_DiskPartition class is BMC_LogicalSystemComponent After flattening: The secondary form of the BMC_DiskPartition class is BMC_BaseElement
|
| 8 | Import the modified new and refresh class definitions | The modified new and refresh class definitions are imported from the parallel hierarchy to the actual hierarchy. The new and refresh class definitions replace the existing class definitions. The class types are refreshed to reflect the flattened classes.
|
| 9 | Update CMDB metadata to reflect the correct class type for flattened classes. | The BMC CMDB metadata is updated to reflect the correct class type for denormalized classes. For example, the name of the OBJSTR:Class form of the flattened class shows
|
| 10 | Perform data migration | Perform Data movement for the attributes which are moved to the immediate regular parent. Attributes of the denormalized classes are moved to the immediate parent regular class. Data is migrated from the _forms BMC_product to BMC_BaseElement form.
|
Comments
Log in or register to comment.