Best practice
We recommend thoroughly evaluating your business requirements and planning your data model carefully. The Common Data Model (CDM) in BMC Helix CMDB is designed to accommodate a wide range of use cases. However, if you want to customize the CDM to meet specific needs, we recommend reviewing the following documentation before creating new classes or attributes:
Whenever you extend the data model, use your own namespace instead of BMC.CORE. This prevents your extensions from being overwritten by new classes when you upgrade to a future version of the CDM.
Never modify the core CDM class attributes because upgrades across versions overwrite these customizations. Modifications to the CDM, such as changing the attribute field length in a class are not preserved during upgrades.
On the other hand, a new class or an extended class with additional attributes is not overwritten during an upgrade. Creating or extending a class may have a significant business impact and you must perform these modifications only after careful planning and consideration of all eventualities.
The following example highlights the key considerations before modifying the common data model:
Example
At Apex Global, Allen Allbrooke, a CMDB administrator, needs to track the model year for devices such as servers, workstations, and routers. The model year is valuable to various consumers of CMDB data.
The administrator first evaluates the options before modifying the data model:
- Federating the Model Year Data: The administrator determines that federation is unsuitable because the model year is critical information about configuration items (CIs), rather than non-CI data like incident requests or non-critical CI details such as service records.
- Using Existing Attributes: The administrator considers the existing Category, Type, and Item attributes but finds these insufficient for storing model year information, as they are designed for classification.
- Leveraging Existing Extensions: The administrator reviews available extensions but notes that model year data is not included in the extensions Apex Global plans to use.
After ruling out these options, Allen decides to extend the data model by adding a new attribute to an existing class.
Upon consulting the Data Model Help, the administrator identifies the BMC_ComputerSystem class as the ideal location for the new attribute. Since subclasses inherit attributes from a superclass, the new attribute would also apply to the subclasses BMC_Mainframe and BMC_Printer. This inheritance ensures the administrator can optionally track the model year for mainframes and printers.
With this plan in place, the administrator extends the data model by adding the new attribute to the BMC_ComputerSystem class, effectively meeting Apex Global’s business requirements.
Your first step in deciding whether to extend your data model should be understanding the CDM and the extensions supplied by BMC products. Study the BMC Helix CMDB Common Data Model Diagram and BMC Helix CMDB Data Model Help in PDFs-and-videos, and the documentation for BMC products that you own that integrate with BMC Helix CMDB. By reading about the classes that you have, you might find existing classes that serve your needs or at least find the best classes to extend.
This section provides the following information related to extending the data model: