*
Concepts
*
Tasks
*
Reference

Relationship Types

Different types of relationships enable you to create different links between pieces of information.

Contents

References One
References Many
Owns Many/Is Owned By
Scopes/Is Scoped By
Other Relationship Types

References One

This simple relationship is used to point to another class, primarily to obtain pertinent information from it. It can provide as much information as you need from the referenced class. The References One relationship will probably work for 95% of the custom relationships you create.
Using a Purchase Order as an example, the Purchase Order class will generally contain several References One relationships to other classes, such as Vendor. This reference to Vendor enables you to add vendor-specific information, such as the vendor’s name and address, to the Purchase Order.

Representation in UI

When the References One relationship is placed on the user interface of the referencing class, an Object Reference control is used to represent it. In APM, Work Order references one asset to work on.
TOP

References Many

This relationship represents a symmetric many-to-many mapping. It can be used only between Persistent classes. A Persistent class can include a References Many relationship to itself.
A good example of how this type of relationship is used is to create a class for Standard Comments for use on a Purchase Order. The relationship would be Purchase Order References Many Standard Comments.

Representation in UI

This relationship results in a Multi-Column List control of the referenced objects. In APM, Asset references many Procedures and documents.
TOP

Owns Many/Is Owned By

The Owns Many relationship links many instances of one class to another owning class. In this relationship, there is a primary class and a secondary class. Objects in the primary class own objects in the secondary class. When an object in the primary class is locked, its owned objects in the secondary class are also locked. When an object in the primary class is deleted, its owned objects in the secondary class, assuming the secondary class is not a Primary Locking Object, are deleted as well. You might find the Owns Many relationship useful between standalone classes.

Representation in UI

The Owns Many relationship appears in the user interface as a multi-column list box. In APM, the Country class owns many States.
TOP

Scopes/Is Scoped By

Scopes is very similar to the Owns Many relationship. The essential difference between these relationships centers on the runtime behavior of the scoping class. Scoping relationships do not drive deep deletion behavior. When a user attempts to delete an object that scopes another object, the delete will fail due to referential integrity. You may find the Scopes relationship useful between standalone classes.

Representation in UI

Scopes also creates multi-column list boxes. In APM, Site scopes Asset.
TOP

Other Relationship Types

These following relationship types are contained in the object model but cannot be used in object model customizations. However, you might encounter these relationship types when navigating the object model to create table configurations, KPIs, or calculated indicators.

Contains One / Is Contained By

The Contains One relationship is used to incorporate one instance of a Dependent class into another class.
For example, in the APM object model there are the classes Employee and Supplier. For each of these types of objects, you want to keep address information. Therefore, each contains a Dependent class called Address Information. The Address Information class contains attributes called City, EmailAddress, PostalCode, and StreetAddress.
The Address Info class does not exist on its own (you cannot create Address Info objects) but provides a standard set of attributes to any class that contains Address Info.

Hierarchy Parent / In Hierarchy Of

The Hierarchy Parent relationship defines a hierarchical structure for a class within itself. This relationship is used when the instances of a class have subordinate hierarchical instances (for example, children) in the same class, with one restriction. A child instance can only have one parent in the relationship. However, a parent can have many children.
A good example of this is the asset hierarchy. In this case, the Asset class has a Hierarchy Parent relationship with itself. An instance of an asset may be linked to other assets who are immediate subordinates in the reporting structure. The Hierarchy Parent relationship appears as a tree control showing the child instances of the parent.
TOP