Common Data Model concepts

This topic describes the purpose and structure of the BMC CMDB data model.

Related topics

Common Data Model terminology

The following table lists the various terms used to describe the Common Data Model (CDM).

Term	Definition
Namespace	CDM definitions comprise a namespace and class name. A namespace is a label that identifies classes that serve a similar purpose. It also serves to create unique names. Example, BMC.CORE. You can partition your data model by using namespaces. Namespaces partition classes and attributes in the data model. This allows you to specify the provider or consumer of a certain type of data or make other arbitrary groupings. For instance, all classes in the Common Data Model are in the BMC.CORE namespace, and other classes provided by the BMC CMDB that hold information, such as federated data definitions are in the BMC.CORE.CONFIG namespace. A namespace is prepended to the names of its class forms; but not to its attribute fields. Therefore, a class that is created in one namespace can have the same name as an existing class in another namespace. However, attributes of the same class in different namespaces cannot share the same name. Namespaces can be applied at the attribute level, as well as the class level. This means that some, or even all the attributes of a class, can reside in a different namespace from the class itself. This is useful when you have a class that is used for more than one purpose, but one of those purposes requires an extra attribute.
Class	Classes represent a type of CI or relationship that is stored in the CMDB. Each class equates to a database table or a BMC Remedy AR System form, and each instance of the class equates to an entry in the form or record in the table. For example, the data for the `BMC_ComputerSystem` class, which represents computer system CIs is accessible in the BMC.CORE:BMC_ComputerSystem join form.
Attribute	A class has one or more attributes, each of which specifies a property of the class. For example, `BMC_ComputerSystem` has attributes, such as `HostName` and `Domain` . Each attribute equates to a column on a database table or a field on an BMC Remedy AR System form.
Superclass	A class having underlying classes is called a superclass. For example, BMC.CORE:BMC_ComputerSystem has a subclass called BMC.CORE:BMC_MainFrame. BMC.CORE:BMC_MainFrame contains all of the attributes of BMC.CORE:BMC_ComputerSystem, in addition to the attributes that are specific to mainframes.
Subclass	The subclass inherits all the attributes of its superclass and any superclasses above it in the hierarchy, and can also participate in relationships defined for all superclasses.
Configuration item (CI)	A CI is a physical, logical, or conceptual entity that is part of your IT environment and has configurable attributes. Examples include computer systems, buildings, employees, software, and business services. Each CI is stored in BMC CMDB as an instance of a CI class.
Relationship	A relationship is a connection between two CIs, such as a dependency or membership. Each relationship is stored in BMC CMDB as an instance of a relationship class.

CDM hierarchy

Classes in the CDM are organized into a hierarchy. The CDM has a common base class and all other classes are extensions of the base class. Drilling into the hierarchy reveals specific classes. This is comparable to the way organizations are structured. A typical example of an organizational hierarchy could be a manager under whom there are several team leaders, who in turn have team members under them.

A class having underlying classes is called a superclass. The underlying class is called subclass. CDM hierarchy also governs grouping classes that are similar.

The following instance diagram explains the CDM hierarchy with an example:

The preceding diagram illustrates the hierarchical relationship between the following classes:

BMC_Processor (underlying class) is the subclass and BMC_HardwareSystemComponent is the superclass.
BMC_Processor represents a CPU in a computer. It defines various attributes that are specific to processors, for example, NumberOfCores.
This class is the super class of the BMC_NetworkPort class, which is similar to BMC_Processor, because they are both are hardware components.
BMC_Processor and BMC_NetworkPort are grouped under the BMC_HardwareSystemComponent class.
BMC_SystemComponent is a superclass used to define attributes that are common to all its subclasses. For example, isVirtual indicates that BMC_SystemComponent class is a virtual machine BMC_Processor is used to represent the processors of both physical machines and virtual machines. To represent it as a virtual machines the isVirtual attribute set to True. All the underlying subclasses of BMC_SystemComponent inherit the isVirtual attribute.

Attribute inheritance

The data model is object oriented. A class can have subclasses that inherit its attributes and the ability to participate in the same relationships. Subclasses are used to further classify a type of CI and give specific attributes to the more granular types. For example, BMC_ComputerSystem has subclasses to represent mainframes, printers, and virtual systems. These subclasses inherit HostName and Domain, and all the other attributes of BMC_ComputerSystem. Inheritance of attributes continues to the end of the tree. This continual inheritance means that the subclasses also inherit from BMC_System, the class above BMC_ComputerSystem, and from BMC_BaseElement, the base class above BMC_System. An example of attribute inheritance is shown in the following diagram:

Layered model

CDM is structured in layers, wherein the top layer denotes the services, middle layer denotes applications, and the bottom layer represents servers. The services layer includes business and technical services. The application layer delivers the services in the services layer. The server layer, comprising physical and virtual infrastructure, delivers the application layer. An example of layered model is shown in the following diagram:

The following table describes CDM classes corresponding to each layer, along with examples:

Layer	CDM classes	Examples
Services	BMC_BusinessService	Home banking, Help Desk, Web sites, E-mail
Services	BMC_BusinessService	Web farms
Applications	BMC_Application, BMC_Database	Custom Banking Application, Sharepoint 2010, Remedy Service Desk, Exchange
Applications	BMC_ApplicationSystem, BMC_ApplicationInfrastructure, BMC_ApplicationService	Action Request System, Tomcat Module
Servers	BMC_SoftwareServer	Tomcat, Apache webservers, MS SQL Server 2008, LDAP server
Virtual Computers, Compute, Storage and Network Infrastructure	BMC_ComputerSystem	VMs, LPARs
Physical Computers, Compute, Storage and Network Infrastructure	BMC_ComputerSystem	Servers, desktops, laptops, iPads, routers, switches, firewalls, SAN and NAS storage, ESX servers
Subcomponents of Computer Systems	BMC_OperatingSystem, BMC_Product, BMC_IPEndpoint, BMC_LANEndpoint, BMC_HardwareSystemComponents and subclasses BMC_LogicalSystemComponent and subclasses

This structure is not reflected in every model built using the CDM. Some variation is likely depending on a specific scenario. For example, the virtual hardware layer may not exist. Also the number of application layers could vary depending on the complexity of the application being modeled.

Extensibility

A key aspect of BMC CMDB is a data model that is extensible. To be extensible means that there is no usage distinction between the system-defined and the user-defined data model.

The infrastructure and data that different companies want to track about that infrastructure, is constantly changing. The data model is designed so that it can easily be extended by using the Class Manager or the BMC CMDB APIs. Some BMC applications extend the data model to store data specific to their functionality.