This documentation supports the 9.1.04 version and its patches of BMC Atrium Core. The documentation for version 9.1 to 9.1 Service Pack 3 and its patches is available here.

To view the latest version, select the version from the Product version menu.

Learning about the common data model

The common data model (CDM) is the set of Configuration Item (CI) and relationship classes that ship with BMC CMDB. These classes represent the physical, logical, and conceptual items of all IT environments that you want to track in a CMDB. When you setup a CMDB for your organization for the first time, you can use the pre-defined classes in the CDM. However, to extend the data model, you must create your own classes or extend a class with additional attributes.

For information about the complete structure and class details of the CDM, see the BMC CMDB CDM Diagram and the BMC CMDB CDM Help in the PDFs and videos page.

The common data model of the BMC CMDB unifies the representation of configuration data. It is designed to store data about the most common configuration items (CIs), such as hardware, software, and services. It helps link the CI information to provide a complete view of all elements in an IT environment and the way in which they affect each other.

For consistency with the industry standards that have been developed to track and manage this type of information, the CDM is based on the Common Information Model (CIM) from the Distributed Management Task Force (DMTF) and Microsoft Windows Management Instrumentation (WMI). The CDM adopted much of the basic design of the CIM and WMI without going into the same depth on the internal workings of systems.

Classes and attributes needed only by a specific BMC product are not part of the CDM. These extensions are installed by the product that consumes data from them and they reside in separate namespaces.

CIs and relationships

The CDM is composed of configuration items (almost always known as CIs) and relationships.

  • CIs are configurable things in an organization that must be managed to deliver an IT or business service. For example, a server in a data center or a software running on a computer. 
  • Relationships represent the connections between CIs. An instance of the relationship class will therefore relate an instance of the first or source CI class to an instance of the second or destination CI class. The two CIs are considered members of the relationship.

Relationship directionality

Relationships, like CIs, have attributes. Relationships also have directionality that identifies source and destination.

The placement of a CI class as the source or destination member of a relationship is not arbitrary. The source or left class provides a group, location, hosting, or other function, and the destination or right class is a member of, is located in, depends on, or is hosted by it. For example, the source member of BMC_HostedSystemComponents is BMC_System, and the destination member is BMC_SystemComponent. The source system hosts the destination component. 

It is always important to have the direction of arrow pointed correctly. The arrow head always point to the destination, and the reverse direction relationship is never possible. For example, if two CIs, A and B have a BMC_Dependency relationship, where A depends on B, then A is the Destination and B is the Source. The arrow would point to A, that is, it would be drawn as A <- B. The reverse, A -> B is never a possibility. If two CIs are interdependent, then those CIs are denoted with a bidirectional arrow. The following examples, explain this concept in detail.


Simple server with an operating system

The diagram on the right represents a server. A server is represented in the CDM with a CI. BMC_ComputerSystem CIs have attributes that give more details about themselves. Each attribute has a name and a value. In the diagram, BMC_ComputerSystem has many attributes. However, for purpose of illustration, only two are shown in the diagram:

The Name attribute of BMC_ComputerSystem is always set to the fully qualified domain name (FQDN) of the host, if that is available. If the FQDN isn't available, alternative values are used. These values are documented in the data model definition if you need to know exactly what to expect.

In the diagram, the top box represents the operating system running on the server. Operating systems are represented by a BMC_OperatingSystem CI that has many attributes. However, for purpose of illustration only Name and OSType are shown here. All CIs have a Name attribute and it is usually populated with something that usefully identifies the CI.

The two CIs, BMC_ComputerSystem and BMC_OperatingSystem, are connected by a line that represents a relationship between them. BMC_HostedSystemComponents relationship connects both these CIs. Relationships, like CIs, have attributes. As explained earlier, directionality of relationships helps identify the source and destination. In this example, BMC_ComputerSystem is the source and BMC_OperatingSystem is the destination.

Two servers with a dependency

If there are two servers to model, then two BMC_ComputerSystem CIs are used to model them. The following diagram shows two servers that have a dependency on one another:

The original server, along with its operating system (Windows), is shown on the left. Another server, with Linux as its operating system is shown on the right. Each BMC_ComputerSystem CI has a relationship with its respective BMC_OperatingSystem CI, just like in the case of a simple server. However, in this case the two BMC_ComputerSystem CIs have certain kind of dependency between them and are related using BMC_Dependency relationship.

The two BMC_ComputerSystem CIs are both of the same class. You don't really need to worry too much about the distinction, but for those that are interested, a class is an abstract concept that represents what it means to be a certain type of CI. For example, the BMC_ComputerSystem class represents what it means to be a server. It doesn't represent any particular server; instead, it says that all servers have names and manufacturers. CIs represent actual servers.

Sample data models using the CDM

The following figures illustrate the use of classes in the CDM to model your data. The boxes represent configuration item (CI) classes and the lines represent relationship classes. The models shown here are simplified and do not necessarily represent best practices.

Sample model for a computer system

The following figure illustrates a typical computer system data model. It has an operating system, a BIOS, a word-processing application, a video card, and uses a network printer.

Classes used for a computer system and components

Sample model for a computer system in a LAN

The following figure illustrates a data model in which a computer system participates in a LAN. The computer system is in an IP subnet that is part of the LAN.

 Classes used for a computer system in a LAN

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


  1. David k Hill

    Some information about the uniqueness of the particular system would be valuable. That is if the computer system's CI record could be duplicate based on a different name e.g. Short name vs FQDN. I have found after reconciliation two records with a short and a FQDN. Should there be only one CI record representing the computer system? Are there defined rules that stipulate this?

    Oct 04, 2019 03:03
    1. Maithili Deshpande

      Hi David, 

      Thank you for your comment. Will check with the SME and respond at the earliest. 



      Oct 04, 2019 09:22
    1. Maithili Deshpande

      Hi David, 

      Yes, there should be only one CI record and there are rules to identify the unique CIs during reconciliation. The Identification rules check for multiple criteria before reconciling any record. For example, the rules are as seen in the screenshot here - 


      Hope this helped.

      Please let me know if you have any other queries.




      Jan 03, 2020 09:36