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.

Overview of the Common Data Model

The Common Data Model (CDM) of the BMC Atrium CMDB unifies the representation of configuration data. It is designed to store data about the most common configuration items such as hardware, software, and services and provide a mechanism for linking that information to provide a complete view of all elements of an IT environment and how they affect each other.

CDM is the set of Configuration Item (CI) and relationship classes that ship with BMC Atrium CMDB. These classes are intended to represent the physical, logical, and conceptual items of all IT environments that you want to track in a CMDB. Most of the classes in the CDM reside in the BMC.CORE namespace. The two federation classes reside in the BMC.FED namespace. There is also a BMC.MAINFRAME namespace that has related BMC_StorageSubsystem and BMC_MFCouplingFacility classes.

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.

The following sections provide information about Configuration Items and CI relationships.

CDM is object oriented and extensible. It consists of classes, each representing a type of configuration item (CI) that can be stored in the BMC Atrium CMDB. A class can be either a CI class, which defines a type of configuration item, or a relationship class, which defines a type of relationship between two CIs.

CIs and relationships

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

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:

  • Name is set to
  • ManufacturerName is set to Dell.

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

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