Relationships

As an example, a component in manufacturing could be contained in several different assemblies or subassemblies in varying quantities. Component objects could be connected to the various assembly and subassembly objects that contain it. Each time objects are connected with this relationship, the user could be prompted for the quantity value for the relationship instance.

If the component is later redesigned, the older design might become obsolete. When a revision of the component object is then created, the relationship would disconnect from the original and connect to the newer revision. If the component is cloned because a similar component is available, the cloned component might or might not be part of the assembly the original component connects to. The connection to the original should remain and there should be no connection to the cloned component.

For the process to work like this, the relationship definition would include the attribute "quantity." The cardinality would be "many to many" since components could be connected to several assemblies and assemblies can contain many components. The revision rule would be "float" so new revisions would use the connections of the original. The clone rule would be "none" so the original connection remains but no connection is created for the clone.

A relationship can be derived from another relationship. This signifies that the derived relationship is of the same kind as its parent. This arrangement of derived relationships is called a relationship hierarchy. Derived relationships share characteristics with their parent and siblings. This is called relationship inheritance. When creating a derived relationship, other attributes, methods, and triggers can be associated with it, in addition to the inherited ones.

You must be a Business Administrator to define relationships. Relationships are typically initially created through MQL when all other primary administrative objects are defined. However, if a new relationship must be added, it can be created with Business Administrator.

In an MQL schema definition script, relationship definitions should be placed after attributes and types. Before writing the MQL command for adding a relationship definition, the Business Administrator must determine:

• Of the types of business objects that have been defined, which types will be allowed to connect directly to which other types?
• What is the nature and, therefore, the name of each relationship?
• Relationships have two ends. The from end points to the to end. Which way should the arrow (in the Indented and Star Browsers) point for each relationship?
• What is the meaning of the relationship from the point of view of the business object on the from side?
• What is the meaning of the relationship from the point of view of the business object on the to side?
• What is the cardinality for the relationship at the from end? Should a business object be allowed to be on the from end of only one or many of this type of relationship?
• What is the cardinality for the relationship at the to end? Should a business object be allowed to be on the to end of only one or many of this type of relationship?
• When a business object at the from end of the relationship is revised or cloned, a new business object (similar to the original) is created. What should happen to this relationship when this occurs? The choices for revisions and clones are: none, replicate, and float.

  Should the relationship stay on the original and not automatically be connected to the new revision or clone? If so, pick none.

  Should the relationship stay on the original and automatically connect to the new revision or clone? If so, pick replicate.

  Should the relationship disconnect from the original. and automatically connect to the new revision or clone? If so, pick float.

• When a business object at the to end of the relationship is revised or cloned, a new business object (similar to the original) is created. What should happen to this relationship when this occurs? The choices are the same as for the from end.
• What attributes, if any, belong on the relationship? Quantity, Units, and Effectivity are examples of attributes which logically belong on a relationship between an assembly and a component rather than on the assembly or component business object. Each instance, or use of the relationship, will have its own values for these attributes which apply to the relationship between the unique business objects it connects.

You can use a table like the one below to collect the information needed for relationship definitions.

Relationship Name
From Type
From Meaning
From Cardinality
From Rev Behavior
From Clone Behavior
To Type
To Meaning
To Cardinality
to Rev Behavior
To Clone Behavior
Attributes
Dynamic Relationship?

To support major/minor revisioning of business objects, "dynamic" relationships have a pointer to a MajorId representing a minor revision family rather than an individual business object. The TO end of a dynamic relationship resolves to a specific business object by identifying the best-so-far (BSF) object within the minor revision family.

When used with the Add Relationship command, the dynamic keyword implements support for minor-revision insensitivity. This keyword is mutually exclusive with any of the Replicate/Float/None options on the TO end since it defines a built-in dynamic behavior of its to pointer.

Together with best-so-far, the concept of published objects makes it possible unambiguously to identify a single object within a minor revision family in order to resolve dynamic relationships. An object is marked published when it is at an appropriately mature state in its lifecycle. An unambiguous best-so-far object is then either:

• The last object in the family that is marked "published," or
• The last object in the family if none are published.

The to end of a dynamic relationship resolves to a specific business object by identifying the best-so-far (BSF) object within the minor revision family.

The dynamic relationship feature adds an additional requirement for database definition with Oracle installations: the Oracle user (that is, database) must have CREATE VIEW privileges. Run the following command to add this privilege:

 SQL> grant connect, resource, create view to USER:
Grant succeeded.
SQL> commit;
Commit complete.

where USER is the V6 Oracle user.

For more information, see MQL Command Reference: Dynamic Clause.