Relationships represented in a data model diagram

A relationship class defines a type of relationship between two specific 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 as members of the relationship.

You can understand the definitions related to relationships and the nomenclature used to represent relationships in a data model diagram. The diagrams in this section show you ways to model an entity in a real-world business environment. Boxes in the diagrams represent CIs that contain attributes of a class or its parent class. Key attributes shown in the box depict a specific class and, in some cases, include the recommended value of those attributes.

Colors help you distinguish the relationship types that are recommended to model a business object. The source and destination of each relationship are represented by the letters S and D, respectively. Arrows are used to show the direction of the relationship from source to destination.

Dependency relationships

Dependency relationships are represented by red lines with an arrow to show the direction of the relationship. For example, in a BMC_Dependency relationship, the arrow points from A (source) to B (destination). In this relationship, entity B is dependent on entity A, and entity A impacts entity B.

Component relationship

In a component relationship, the source CI is a group that has a component or part, which is the destination CI. In the following example, entity A is a group (source) that has a component B (destination). Component relationships are represented by green lines.

Collection relationship

In the following diagram, BMC_MemberOfCollection relationship is represented by black lines. A is the collection class (source) and B is the member class (destination). The collection class uses properties of the member class.

Weak relationships

A weak relationship between two instances is indicated by the letter W in the diagrams. In a weak relationship, a 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 the 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 at a level below.

BMC_HostedSystemComponents is a weak relationship commonly used to relate a computer system to its components. You can copy instances of BMC_ComputerSystem from one dataset to another during certain reconciliation activities. 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 member to the weak member. This means that an attribute from the source CI is mapped to an attribute from the destination CI. Therefore, for every instance of the relationship, whenever source attribute changes, the corresponding destination attribute also changes. You can 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 Best-practices-for-propagating-attributes-to-weak-relationships.

Cardinality in relationships

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. The converse is also true. Cardinality is shown at the end of the relationship lines as one of the following types:

1:1 (one to one)
1:* (one to many)
*:1 (many to one)
: (many to many)

Relationship between 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, while the destination class is a member of, is located in, depends on, or is hosted by the source class.

For example, the source member of BMC_HostedSystemComponents is BMC_System, and the destination member is BMC_SystemComponent.

Examples of source and destination relationship members

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 option causes a destination member of the relationship and all relationships below it to be deleted when the source member is deleted. If you enable the cascading delete option and if you mark a CI as deleted, it is also cascaded down to destination CIs.

You can use the cascading delete option with composite objects. For example, you could use the cascading delete option 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 order. For example, if you restore a computer system that was previously marked for delete, only the computer system is restored, but its components, such as disk drives and memory, remain deleted. To restore all of the components, you must restore each one of them individually.

When you enable the cascading delete option, 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 the cascading delete option enabled.

Relationship directionality

Relationships, like CIs, have attributes. Relationships have directionality that identifies the source and destination.

In the diagram, it is important to have the direction of the arrow pointed correctly. The arrowhead always points to the destination, and the reverse direction for a relationship cannot be assigned. 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 clearly.

Examples of relationship directionality

Simple server with an operating system

The following diagram represents a server. A server is represented in the common data model as a configuration item (CI) belonging to the BMC_ComputerSystem class. Each CI has attributes and each attribute has a name and a value. In the diagram, BMC_ComputerSystem has many attributes. However, for the purpose of illustration, only two attributes are shown in the diagram:

Name is set to host1.acme.com.
ManufacturerName is set to Dell.

The 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 is not available, alternative values are used. For more information about these values, see the CDM Help in the PDFs-and-videos documentation.

Operating systems are represented by an instance of the BMC_OperatingSystem class with many attributes. However, for the purpose of illustration, only Name and OSType are shown here. All the CIs have a Name attribute.

The two CIs, BMC_ComputerSystem and BMC_OperatingSystem, are connected by a line that represents a relationship between them. BMC_HostedSystemComponents relationship connects both these CIs. Like CIs, relationships also have attributes. As explained earlier, the 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, two BMC_ComputerSystem CIs are required to model them. The following diagram shows two servers that have a dependency on one another:

Two server dependency.png

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 are dependent on each other and hence are related by using the BMC_Dependency relationship. The two 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.