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
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.
- CIs are configurable things in organization that must be managed in order to deliver an IT or business service. For example, a server in a data center or a software running on a computer. For more information on CIs, see Configuration items in an ITIL CMDB and Configuration item classes in the Common Data Model
- 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. For more information on relationships, see Relationships among CIs in a CMDB and Relationship classes in the Common Data Model
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. 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
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.
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_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.