Performing denormalization of Common Data Model
The following topics provide instructions for denormalizing Common Data Model (CDM) classes and relationships:
The following video (4:41 min) provides the procedure to perform CDM denormalization.
Common Data Model denormalization implementation scenarios
For fresh installation scenario
If you are performing a fresh installation the classes discussed in the Regular classes converted to categorization subclasses section are available as categorization subclasses.
For upgrade scenario
If you are performing an upgrade, you will need to run the CDM denormalization utility after the upgrade procedure is complete.
Similar to fresh install scenario, the classes discussed in the Regular classes converted to categorization subclasses section will be available as categorization subclasses after you run the utility.
See Deploying CDM denormalization package using installer wizard for more details
Common Data Model denormalization strategy
The following points will help you to understand the Common Data Model denormalization strategy. When you denormalize your common data model:
- You don't need to modify the AST Forms (Eg AST:PRODUCT), or any higher level joins in the denormalized classes.
- You don't need to modify the APIs, filters, or webservices level integrations that exist with BMC Atrium CMDB ecosystem.
- The maintenance window is kept to minimal and you don't need to restart the BMC Remedy AR server.
- Denormalization is performed without changing the CDM logical hierarchy and without disturbing the CDM hierarchical object Model.
- Denormalization is achieved by converting the Regular Classes in the class hierarchy to Categorization Sub-Class.
- After denormalization, all attributes will still stay with the class to which they belonged earlier but, the fields corresponding to those attributes move to the immediate regular parent class.
- 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.
- During denormalization, pre and post validation checks are performed which ensure script execution with better control of the process.
The following infographic provides an overview of the performing CDM denormalization.
To denormalize CDM classes and relationships
- Ensure that you have performed the following tasks before you begin denormalizing the Common Data Model:
- Create a staging server
- Minimum version requirements
- BMC Remedy AR System 9.0.00
- BMC Atrium Core 9.0.00
- Deploy the CDM denormalization utility.
The CDM denormalization utility is deployed at the following location:
<install dir>\BMC Software\AtriumCore\cmdb\utils\cdmflattening
- Take the database backup. This step is crucial in case of recovery.
- On the computer where you have installed BMC Atrium Core, run the cdm denormalization utility through UI.
- The cdm denormalization utility is located at the following location:
<install dir>\BMC Software\AtriumCore\cmdb\utils\cdmflattening\bin
- The Atrium UI link will be available to invoke UI to run the Utility in the background.
- The cdm denormalization utility is located at the following location:
- Select check box that you have taken a database backup then only you will be able to click button to run CDM denormalization utility.
The CDM denormalization utility performs pre-validation tasks. Ensure the following during the pre-validation stage.
For 9.0.00.001 pre-validation checks, do the following
Check the log for any pre-validation errors.
Fix the pre-validation errors.
Open the Denormalization utility again and run it.
For pre-validation checks, do the following
- Validation errors occur, and the utility exits.
- Fix the validation errors.
- Open the Denormalization utility again and run it.
For more information on pre-validation checks see, Common Data Model denormalization pre-validation tasks.
- List of the all the classes that are denormalizaed is logged into the log file.
The CDM denormalization process begins. At this stage, various tasks are performed to denormalize the classes. At this stage, you need to factor in the downtime that is required during the denormalization process. See, Common Data Model denormalization execution tasks.
The maintenance window is during the interchange between original and parallel hierarchy. During this stage any query(ies) triggered on denormalized class(es) may give you undesired results. This is because the joins are changed from _(Underscore) form(s) to OBJSTR:CatClassStub thus making _(Underscore) form(s), 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 (which is immediately after flip of original hierarchy with parallel), data is getting moved from _(Underscore) forms to immediate regular parent forms for the fields which are moved to parents. During this period any query(ies) fired on the denormalized class(es) may give undesired results. This is because if data is not moved yet during data migration stage and query is fired for the denormalized classes then query will return blank values for the attributes.
For all the steps prior to flip hierarchy, there is really no change for user. User can work without any issues seamlessly with NO impact to work due to denormalization process.
The overall maintenance window is ~15 minutes for ~2 million CIs.
The overall maintenance window is ~85 minutes for ~10 million CIs.
No. of CIs Maintenance Window for Flip Activity Migration Activity 2 million 10 minutes 5 minutes 10 million 50 minutes 35 minutes
- The cdm denormalization utility performs post-validation tasks. Ensure that post-validation stage is completed successfully.
At this stage, if any post-validation errors are reported, the utility will exit. You must fix the error and re-run the utility. When you re-run the utility, it will skip all the tasks that were completed successfully and resume from the point the error occured.
See, Common Data Model denormalization post-validation tasks.
- (Optional) In the cdmflattenning.log file verify if the CDM classes and relationships are denormalized and the data is migrated to the BMC_BaseElement and BMC_BaseRelationships class.
The log file is located at the following location:
<install dir>\BMC Software\AtriumCore\cmdb\utils\cdmflattening\log\cdmflattenning.log
- Refresh the BMC AR System mid tier. You need to sync the cache.
Migrate the delta data. See, Migrating delta data after Common Data Model denormalization.
After the denormalization process is complete and the data migration is confirmed, you can delete the BMC.CORE:BMC_Product_, BMC.CORE:BMC_Component_, and BMC.CORE:BMC_LogicalSystemComponent_ forms. You can use Developer Studio in base development mode to delete these forms. It does not tamper with the class manager because the forms are independent after denormalization.
For detailed documentation on searching corresponding forms, see .
While running the CDM denormalization utility, if there is any custom CatSubclass below the BMC_Software abstract class with existing attributes of custom CatSubclass then those attributes will 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 an 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. It does not tamper the class manager because the form is independent. Make sure you delete the form from base development mode.