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 CMDBfor 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.
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:
Nameis set to host1.acme.com.
ManufacturerNameis set to Dell.
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. For more information about these values, see
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
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_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.
For more information about the CI classes and attributes, refer to the BMC Helix CMDB CDM Help file in PDFs and videos (Login required).
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_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