This documentation applies to the 8.1 version of BMC Atrium Core, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Relationships in the data model

A relationship class defines a type of relationship between two specific Configuration Item (CI) classes. An instance of the relationship class relates 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.

Relationship source and destination members

The placement of a CI class as the source or destination member of a relationship is not arbitrary. The source class provides a group, location, hosting, or other function, and the destination or 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. For examples of the meaning of source and destination in some relationship classes, see the following table.

Examples of source and destination relationship members


Source acts as

Destination acts as



Dependent. Depends on antecedent.



Component. Hosted by host.

Relationship cardinality

Every relationship class has a cardinality that defines how many instances of the source class can be related to each instance of the destination class and vice versa. BMC Atrium CMDB enforces this cardinality.

  • One to one — Each instance of the source class can have this relationship with one instance of the destination class.
  • One to many — Each instance of the source class can have this relationship with multiple instances of the destination class.
  • Many to one — Multiple instances of the source class can have this relationship with each instance of the destination class.
  • Many to many — Each instance of the source class can have this relationship with multiple instances of the destination class, and vice versa.

Fulfilling a many cardinality means that multiple instances of the relationship exist.

Weak relationships

If a relationship is a weak relationship, its destination member, called the weak member, cannot exist without its source member, called the strong member. A weak relationship creates a logical composite object consisting of both member CIs. You can extend this composite object by adding more weak relationships either from the source to other destinations or from the destination, acting as a source this time, to destinations a level below.

You can choose to act on these composite objects during certain reconciliation activities. For example, BMC_HostedSystemComponents is a weak relationship commonly used to relate a computer system to its components. If you copy instances of BMC_ComputerSystem from one dataset to another, you can choose whether instances of BMC_Monitor and other components related to those computer systems are copied automatically to preserve the composite objects, even though BMC_Monitor was not specified as a class to be copied by the activity.

You can also propagate attributes from the strong side to the weak side of a weak relationship. This means that an attribute from the source CI is mapped to an attribute from the destination CI so that for every instance of the relationship, whenever the value changes in that attribute of the source, that value is also written to the corresponding attribute on the destination. This enables you to search for an instance of a destination member, such as a disk drive, and get information about the computer system in which it is installed without having to follow the relationship and read the computer system instance.

For instructions about propagating attributes for weak relationships, see Propagating attributes for weak relationships.

Cascading delete option for relationship classes

Relationship classes with a cardinality of one-to-one or one-to-many have an option called cascading delete. This causes a destination member of the relationship, and all destinations of relationships below it, to be deleted when the source member is deleted. Marking a CI as deleted is also cascaded down to destination CIs when this option is enabled.

This option is particularly useful with composite objects. For example, you could use it with the BMC_HostedSystemComponents relationship class so that when you delete a computer system, all its components, such as disk drives and memory, are also deleted.


Cascading delete does not work in reverse. When you unmark a CI that was previously marked as deleted, only the CI on which you set MarkAsDeleted to NULL or No (BMC recommends NULL) is restored. For example, if you unmark a computer system, it is restored, but its components, such as disk drives and memory, remain deleted. To restore the components as well, you must unmark each of them.

Use cascading delete carefully, because it can have far-reaching effects. Deletions are cascaded all the way down to destination CIs at the end of a relationship chain, and this happens for every instance of a relationship class that has cascading delete enabled.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.