Relationship Definition

A relationship family corresponds to a database table that is used to relate two entity family tables. A relationship definition, for a given relationship family, is a rule that specifies which two entity families are related, which family is the predecessor, which family is the successor, and the cardinality of each. By setting up relationship definitions, you can define the various types and levels of connections that exist between entities.

After you have associated entity families with one another using relationship definitions, you can create business rules based on those relationships. In this way, individual entities, which are stored separately within the database can interact with, use information from, and can even be updated based on changes made to other, related entities.

You can set up and maintain relationship definitions via the Configuration Manager. When deciding how many relationships to create, remember that too many relationships can create unnecessary system overhead. Too few relationships, on the other hand, will prevent you from defining them specifically enough to be useful to the end user.

Creating relationship definitions allow you to define, for a relationship family, which entity families are related to one another through that relationship.

While defining a relationship definition, make sure that they do not spread to subfamilies. In other words, you must create relationship definitions for each specific predecessor and successor family that you want to participate in the relationship. For example, if the Manufacturer family has two subfamilies, Chinese Manufacturer and Canadian Manufacturer, and you want to be able to link Chinese Manufacturer records and Canadian Manufacturer records to Equipment records, you must create a relationship definition for both the Chinese Manufacturer family and the Canadian Manufacturer family. Defining a relationship for the Manufacturer family alone would not be sufficient.

After you create relationship definitions, you must make sure that you assign family-level privileges, such that the users have permission to access all the families involved in the relationship definition, including the relationship family. Granting permission to only some of the families in a relationship will grant a user only partial access to the records that are linked to one another through that relationship.

Before creating a relationship definition, you must first decide which two families will participate in the relationship. Then, you must decide which family will be the predecessor and which will be the successor in the relationship.

In many cases, the predecessor is the single part of the relationship equation and the successor is the multiple part. For example, if the relationship is Has Failure, and you determine that a piece of equipment, such as a pump, has a failure, then the pump experiencing the failure is the predecessor because there is one pump, whereas the failure is the successor because a pump might have many failures.

Another way to look at predecessors and successors is to consider that the predecessor comes before the successor. For example, using this guideline, a piece of equipment could be the predecessor and a repair could be the successor because the equipment was in place before it was repaired.

Cardinality for a particular relationship definition specifies how many links can be created between records of the predecessor and successor families. Consider an example where the Has Maintenance relationship relates the Axial Compressor family to the Work Order family. Within this relationship definition, the cardinality would specify how many Work Order records could be linked to a given Axial Compressor record, and vice versa.

The following list provides descriptions of the cardinality rules that can be defined for successors and predecessors. For the purposes of our examples, assume that the Axial Compressor family is the predecessor and the Work Order family is the successor in the Has Maintenance relationship.

• One To One: One and only one predecessor record can be linked to one and only one successor record. For example, one and only one Axial Compressor record can be linked to one and only one Work Order record. Axial Compressor A can be linked to Work Order 1, but Axial Compressor A cannot be linked to any other Work Orders.
• One To Many: One and only one predecessor record can be linked to many successor records. For example, one and only one Axial Compressor record can be linked to many Work Order records. Axial Compressor A can be linked to Work Order 1, Work Order 2, and Work Order 3, and so on.
• Many to One: Many predecessor records can be linked to one and only one successor record. For example, many Axial Compressor records can be linked to one and only one Work Order record. Axial Compressor A and Axial Compressor B could be linked to Work Order 1.
• Many To Many: Many predecessor records can be linked to many successor records. For example, many Axial Compressor records can be linked to many Work Order records. Axial Compressor A and Axial Compressor B can be linked to Work Order 1, and Axial Compressor A and Axial Compressor B can be linked to Work Order 2.

Depending on the entity families and the relationship family involved in the relationship definition, some cardinality options may not be logical for your implementation. Via the Configuration Manager, administrative users can configure the cardinality between entity families according to your company's workflow.

Based on the cardinality defined between entity families through a given relationship family, you will be limited to the number of links that you can create between records when working with the records in the APM. For example, if your system is configured such that a Work Order record can be linked to only one piece of equipment, such as a Pump, you could create a link between Pump 101 and Work Order 1, but you could not link Work Order 1 to any other equipment records. If you tried to do so, APM would generate an error. In this way, cardinality prevents you from creating relationships that should not exist.

One thing to consider when configuring relationships is whether or not information about the relationship will need to be stored. If so, fields can be defined for that relationship family, and a datasheet can be configured. Each time records are linked via the APM, specific information about the link can be recorded in that datasheet.

For example, suppose a pipe is connected to a pump in your facility. You record various types of information for the pipe in a Pipe record and different information for the pump in a Pump record. But when you link the Pipe record to the Pump record, you need to store information specific to that connection, such as weld type and material.

Fields are defined at the relationship family level and are stored as columns in the relationship family table. Any relationship field that you define, therefore, will be available for any link between any predecessor and successor. So, you might need to create more specific relationship families if you plan to use relationship fields.