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.

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.

 https://youtu.be/JKxfwbxJJmo

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

  1. Ensure that you have performed the following tasks before you begin denormalizing the Common Data Model:
    1. Create a staging server
    2. Minimum version requirements
      • BMC Remedy AR System 9.0.00
      • BMC Atrium Core 9.0.00
    3. Deploy the CDM denormalization utility.
      The CDM denormalization utility is deployed at the following location:
      <install dir>\BMC Software\AtriumCore\cmdb\utils\cdmflattening
    4. Take the database backup. This step is crucial in case of recovery.
  2. On the computer where you have installed BMC Atrium Core, run the cdm denormalization utility through UI. 
    1. The cdm denormalization utility is located at the following location:
      <install dir>\BMC Software\AtriumCore\cmdb\utils\cdmflattening\bin
    2. The Atrium UI link will be available to invoke UI to run the Utility in the background.
  3. 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

    1. Check the log for any pre-validation errors.

    2. Fix the pre-validation errors.

    3. Open the Denormalization utility again and run it.

    For pre-validation checks, do the following

    1. Validation errors occur, and the utility exits.
    2. Fix the validation errors.
    3. Open the Denormalization utility again and run it.

    For more information on pre-validation checks see, Common Data Model denormalization pre-validation tasks.

  4. List of the all the classes that are denormalizaed  is logged into the log file. 
  5. 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.

    Observation:
    The overall maintenance window is ~15 minutes for ~2 million CIs.
    The overall maintenance window is ~85 minutes for ~10 million CIs.

    No. of CIsMaintenance Window for
    Flip ActivityMigration Activity
    2 million10 minutes5 minutes
    10 million50 minutes35 minutes
  6. 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
  7. (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
  8. Refresh the BMC AR System mid tier. You need to sync the cache.
  9. Migrate the delta data. See, Migrating delta data after Common Data Model denormalization.

    Note

    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 The main data table for a form .

Limitations

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

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

Comments

  1. Thomas Hammer

    Please correct version information in diagram.

    8.9 is not an official version

     

    Thank you.

    Jan 18, 2016 08:34
    1. Kamalakannan Srinivasan

      Hi Thomas,

      Thank you for your comment. We will make the necessary changes shortly.

      Regards,

      Kamal

      Jan 18, 2016 10:32
    1. Kamalakannan Srinivasan

      Hi Thomas,

      The version number has been changed in the diagram.

      Regards,

      Kamal

      Jan 20, 2016 10:26
  2. Milan Franzkowski

    I also commented on the same topic for version 9.0, but I will add the even more detailed comment here again.

     

    There is a typo in the note box about deleting DB tables, it has to be "BMC_LogicalSystemComponent_".

     

    Also about deleting the tables - I just ran the tool on 9.1 patch 1 and the regular forms BMC_Product_, BMC_LogicalSystemComponent_, and BMC_Component_ are still there and also holding data. If I delete the underlying database tables now, it will leave an inconsistent state of the system as the forms metadata are still present.

    Is it safe to just use the Dev Studio and delete the forms or will that tamper with the class manager / CDM?

    Jul 27, 2016 04:36
    1. Anagha Deshpande

      Hello Milan,

      I have updated the topic.

       

      Regards,

      Anagha 

      Aug 02, 2016 06:02