To and From Clauses

• The types of business objects that can have this relationship.
• The meaning of each connection end.
• The rules for maintaining the relationship.

All relationships will occur between two business objects. These objects could be of the same type or different types. When looking at a relationship, the objects are connected TO and FROM one another.

In some relationships, you can assign either object to either end. However, the To and From labels help you identify the reason for the connection.

You must define the connection with one To clause and one From clause in your Add Relationship command. If either clause is missing or incomplete, the relationship will not be created.

Both the To and From clauses use the same set of subclauses because they define the same information about each connected business object. The separate values you use to define each connection end will vary according to the type of connection you are making and the types of objects involved.

When you define one end of a connection, only one subclause is required: type or relationship.

type TYPE_NAME {,TYPE_NAME}

type all

relationship REL_NAME {,REL_NAME}

relationship all

meaning VALUE

cardinality CARDINAL_ID

minorrevision REVISION_RULE

clone CLONE_RULE

[!|not]propagatemodify

• type defines the types of business objects the user can use for each connection end within the relationship.
• relationship defines the types of connections the user can use for each connection end within the relationship.
• meaning (optional) helps the user identify the purpose of the objects being connected. For more information, see About Administrative Object Names.
• cardinality, minorrevision and clone (all optional) deal with the number of relationships that the object can have on each end and how those relationships are maintained when one of the connected objects is revised or cloned. There must be a level of agreement between the clauses for both to work properly. cardinality defaults to MANY, minorrevision and clone default to NONE.
• propagatemodify specifies how modifications to the relationship instance are reflected in the modified timestamp of the objects on each end. This is helpful for monitoring changes made on a certain day or within a specified time period. With this switch on, objects whose only modifications have been to their relationships can be found by queries searching on modification date values. The default is off, so when adding relationships that do not require this feature, the notpropagatemodify clause is not necessary.

When both ends of the connection involve a single type or relationship, the relationship name can reflect the items being connected. For example, a relationship name of “Model and Drawing” might always refer to a connection between an electronic drawing and a physical model made from the drawing.

A name of “Alternative Component” might always refer to a connection between two component objects used interchangeably in an assembly. In both examples, the name reflects the type of objects connected by the relationship.

An Add Relationship command to define the relationships between components, assemblies, and subassemblies, might appear as:

add relationship “Part Usage”
   description “Identifies the objects used in an assembly or subassembly”
   attribute Quantity
   attribute “Installation Time”
   from
     type Assembly, Subassembly
     meaning “Is composed of"
     cardinality n
     minorrevision float
     clone none
   to
     type Component, Subassembly
     meaning “Is used by”
     cardinality n
     minorrevision float
     clone none;

When a connection end can be assigned multiple business types, the name of the relationship needs to be more generic. For example, a relationship named “Part Usage” might have one connection end that is either an Assembly or Subassembly object type. The other connection end is a either a Component or Subassembly object type. While you have only one relationship, you actually have four types of connections you can make:

• Component objects and Subassembly objects
• Component objects and Assembly objects
• Subassembly objects and Subassembly objects
• Subassembly objects and Assembly objects

This enables you to relate all components and subassemblies to their larger subassemblies and assemblies without defining a relationship for each connection type.

In the following example, the relationship Feature Test is created and is allowed between objects of Type Feature and connections of Relationship type Build.

add relationship “Feature Test” from type Feature to relationship Build;

A variation of the Type and Relationship subclauses use the all keyword in place of one or more type names (type all or relationship all). When this keyword is used, all types or relationships defined are allowed with the named relationship. This means that the specified relationship end can have any object or connection type. Be aware that any additional object or relationship types added at a later date will be allowed within the relationship. This can create problems if the new types are incompatible with the relationship ends. Therefore, you should use the type all and relationship all subclauses with care.

The use of the term “object” means both business objects and relationships.

In the example command in Type and Relationship Subclauses, the Meaning clauses identify the arrangement when a Subassembly object is connected to another Subassembly object. The Meaning clauses identify the order.

Even when both objects are equivalent, inserting a Meaning clause is helpful. It tells the user that the order does not matter. For example, assume you wrote a relationship definition to link equivalent components. In the following definition, the Meaning clause states that both objects have the same meaning. While the user might guess the meaning from the relationship name and description, the Meaning clause eliminates doubt.

add relationship “Alternative Components”
   description “Identifies interchangeable components”
   from
     type Component
     meaning “Can be used in place of”
     cardinality 1
     minorrevision none
     clone none
   to
     type Component
     meaning “Can be used in place of”
     cardinality 1
     minorrevision none
     clone none;

When you define the cardinality, it can have one of these values:

• one or 1: The object can only have one connection of this relationship type at any time.
• many:The object can have several relationships of this type simultaneously.

Since cardinality is defined for each end of a connection, it is possible to have three cardinal relationships between the ends:

Revision Rules

The Minorrevision subclause identifies the rule for handling revisions of the connection object. There are three revision rules for handling revised connection ends: None, Float, and Replicate.

None

When a connection end uses the None rule, nothing happens to the established connection when the end object is revised. The revised object does not automatically have a relationship attached to it after it is created. If you wanted to connect the revised object to the same object as the unrevised one, you would have to manually connect it with the Connect Business Objects command (for more information, see MQL Concepts: Making Connections Between Business Objects).

The None rule is useful when an object revision removes the need for the connection. For example, when you have a connection between a Training Course object and a Course Evaluation object, the connection might no longer be required or useful if the Training Course object is revised. While you might want to maintain the connection between the old version of the Training Course and the evaluation, the evaluation does not apply to the new version of the Training Course object. Therefore the connection end occupied by the Training Course object would use the None rule. But what of the other connection end?

If the Evaluation object is revised, it is still useful to the Training Course object. The revised object should remain connected to the Training Course object but the unrevised object no longer applies. To handle this situation, you would define the Course Evaluation end with the Float rule.

Float

The Float rule specifies that the relationship should be shifted whenever the object is revised. When the Float rule is used, the unrevised (or older version of the) object loses the connection with its other end. In its place the other end is automatically connected to the revised object. Now the older version of the object will be unattached while the newer version will have the relationship. This floating of the connection ensures that the latest versions of the object(s) are linked together.

But what if you want to maintain the old relationship while still creating a relationship with the new version? This would actually produce two connections: one between the unrevised object and its other end and one between the revised object and its other end. In this case, you would use the Replicate rule.

Replicate

The Replicate rule automatically creates new relationships whenever a connection end is revised. This results in a connection end that might have more than one simultaneous relationship of the same relationship type. Any connection end that uses the Replicate rule must also use a cardinality of “n.” If a cardinality value of 1 (one) is used, Replicate cannot work. For more information, see Cardinality Subclause

The Replicate rule is useful when you want to keep track of former relationships. Since the old relationships are maintained while new ones are created, a user can easily see all versions that are related to a connected object. For example, you might have a relationship between a Specification object and a Specification Change object. As the Specification object is revised, you want to maintain the relationship so that you know that this Specification Change applied to this version of the Specification.

However, you also want the relationship to exist between the revised Specification and the Specification Change. This new relationship enables you to trace the history of the changes made and the reasons for them. In this situation, the Specification object should use the Replicate revision rule while the Specification Change object might use the Float or Replicate rule.

An Add Relationship command for the Specification Change might appear as:

add relationship “Specification Change”
   description “Associates a change notice with a specification”
   from
     type “Specification Change Notice”
     meaning “Contains changes to be made”
     cardinality 1
     revision float
     clone replicate
   to
     type Specification
     meaning “To be changed”
     cardinality n
     revision replicate
     clone none;

In this example, the two connection ends have different revision rules and cardinality. Remember that these values should be determined for each connection end based upon the needs and requirements for that object as it relates to the connection being made. Since you might want only the latest version of the Specification Change Notice to be attached to the Specification, Float is the best choice for the revision rule. If you wanted to keep track of all notices that were attached to the Specification, you could change the revision rule to Replicate.

Most business rules require a clone to be treated much differently than a revision, so you might often select a different rule for clones than for revisions. For example, the None rule is often useful when a connection end is cloned. Consider a Specification Change Notice object that is connected to a Specification object. If the Specification is cloned for a new product that is very similar, it’s unlikely that the Specification Change Notice applies to the cloned Specification. So the original connection between the Specification Change Notice object and Specification object should remain but no new connection is needed for the cloned Specification object.

When not used, changes to the relationship instance do not affect the modified date of the objects. The not (or !) form of the subclause can be used when modifying relationships to turn the setting off, if required. The default is off, so when adding relationships that don’t require this feature, the notpropagatemodify clause is not necessary.

For example:

add relationship BOM
   attribute Quantity
   to
      type Component
   from
      type Assembly
      propagatemodify;

Using the relationship above, changes in the quantity of the component in the assembly will be reflected in the modification date of the Assembly.

You can turn off modification timestamps on a per relationship basis and control the “from” and “to” end of the relationship.

This is particularly useful for “one to many” relationships where the “many” side potentially could have hundreds of objects, connected by multiple users. Such frequent timestamp logging can slow down performance and cause potential concurrency issues. Also, if you query the database for objects that have been modified, you might not want to include every object that has merely participated in a connect/disconnect operation without having their actual definition changed.

The system will run faster and the chance of deadlocks is greatly reduced when both modification timestamps and history are turned off during connect/disconnect operations, since only the relationship tables (not the business object tables) are affected. (For more information, see Enable and Disable History.)

By default, the system updates modification timestamps on business objects every time they participate in a connect/disconnect operation. Use the not ( !) form of the subclause to turn off these updates.

For example, there might be a Specification relationship defined for Feature objects on the “from” end and Document objects on the “to” end. You might turn off the “to” end, but leave the timestamp active on the “from” end. Whenever a connect/disconnect event is performed between these two objects, the Feature object’s timestamp is updated, but the Document object’s is not.

add relationship Specification
   to type Document !propagateconnection
   from type Feature;