Multimember Relationships

What is a multimember relationship?

A multimember relationship is a single relationship maintained for more than one child entity type.

A multimember relationship.

Multimember relationships eliminate the overhead of carrying pointers (db-keys) in the parent entity for additional relationships.

However, to retrieve specific entity occurrences in multimember relationships, the database often must access occurrences of unwanted entity types.

Guidelines

Generally, multimember relationships should be used only when:

The different child entity types are usually processed together.
For example, since the ACCOUNT, INVOICE, and PAYMENT entities are usually processed together, you might want to create a multimember relationship to relate these entity types, as shown below.

Applications that use this accounts receivable structure generate statements that contain details of an account's invoices and payments since the last statement, in order by date. If the INVOICE and PAYMENT entities are maintained in separate relationships, an application program will have to merge them into the proper sequence. If the entities are maintained in one relationship, they are already in order.
The different child entity types are mutually exclusive.
Suppose each employee in a corporation is paid on either an hourly or salaried basis. You may want to create a multimember relationship to relate the EMPLOYEE, HOURLY, and SALARIED entities, as shown below.
Child entities are of many types, but each child entity type has only a few occurrences.
In an auto insurance database, a policy may have many riders, each requiring a different format. However, most policies have no more than a few riders attached. If a relationship were maintained between a policy and each potential rider, the policy entity would require at least five sets of pointers, most of them unused, instead of one, as shown below.

In all other cases, you should maintain a separate relationship for each entity type.

Considerations

A multimember relationship cannot be an indexed relationship.
When accessing a multimember relationship through the logical record facility, only one of the child entity types can be accessed in each pass through the relationship. This means that several passes through a relationship might be necessary to access all child entity types.
For further information on accessing a multimember relationship through logical records, see the CA IDMS Logical Record Facility Guide.
Multimember relationships should not include both clustered child entity types and nonclustered child entity types. If both types of entities are included in a multimember relationship, I/O performance will be degraded. The system may have to perform additional I/Os to access the clustered child entity occurrences (because the nonclustered child occurrences are distributed throughout the database).

A comparison of multiple relationships and multimember relationships

The following table presents a comparison of multiple relationships and multimember relationships

Efficiency Considerations	Potential Impact
I/O	No difference.
CPU time	Multimember relationships may require more CPU time to process related entities than multiple relationships.
Space management	Multimember relationships eliminate the overhead of carrying pointers in the parent entity for extra relationships.
Contention	In some situations, multimember relationships may cause more entity contention than multiple relationships. If an entity that participates in a multimember relationship is updated often, locking of a modified occurrence of this entity by one transaction may prevent other transactions from accessing occurrences of other entities in the relationship. Therefore you may want to create a separate relationship for a frequently updated entity.