Common Data Model concepts
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 Helix 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 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 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 Helix 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 Helix 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 Helix 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 Helix CMDB APIs. Some BMC applications extend the data model to store data specific to their functionality.