x

Within an IDMS data source, physical relationships between record-types are achieved with pointers that correspond to IDMS sets. A set implements a one-to-many relationship between record-types. (The Master File equivalent of a set is the parent/descendant relationship between segments.) In an IDMS set, one record-type acts as the owner (the one side of the relationship) and one or more record-types act as the members (the many side of the relationship). A single IDMS record-type can participate in several set relationships as either the owner or the member. Consider the following illustration of the EMPSS01 subschema:

In this example, the EMPLOYEE record-type participates as a member in the DEPT-EMPLOYEE and OFFICE-EMPLOYEE sets, with owners DEPARTMENT and OFFICE respectively. The EMPLOYEE record-type is also the owner in the EMP-EXPERTISE, EMP-EMPOSITION, and EMP-COVERAGE sets with members EXPERTISE, EMPOSITION, and COVERAGE.

Many-to-many relationships using junction record-types also exist in IDMS data sources. In the example, EMPLOYEE is related to JOBS with EMPOSITION as the junction record-type, since an employee may have many jobs or a specific job can be held by more than one person. A junction record-type is a member in two or more sets with related owners.

The IDMS representation of record-types and set relationships within a data source is called an Entity Relationship diagram. In an Entity Relationship diagram, a record-type is depicted as a box and a set as a line with an arrow. Set names appear as labels beside the arrows. The box that the arrow points to is the member record-type. Triangles indicate indexes. The diagram in this topic is the Entity Relationship diagram for the IDMS network subschema EMPSS01. Sections of this diagram are referenced throughout the chapter (see Adapter for CA-IDMS Samples, for its corresponding Master File EMPFULL).

Seven examples of set-based relationships are depicted. This manual refers to them as simple set, common owner, common member, multi-member, bill-of-materials (simple and multi-tiered), and loop structures. All of these correspond to structures you can define in a Master File and are explained in subsequent topics.

x

The following diagram illustrates the basic mapping principle of a simple set. An IDMS record-type corresponds to a segment in a Master File. A set relationship corresponds to a parent/descendant relationship.

This figure also illustrates a second principle. An IDMS structure can have more than one representation as a hierarchy in a Master File. The type of parent/descendant relationship required in the Master File depends on whether the owner or the member record-type is designated as the parent segment.

The JOB-EMPOSITION set has two possible Master File representations:

1. Shows the JOB record-type, the owner in the set, mapped as the root or entry segment. Since a member record-type is multiply-occurring (for example, several instances of EMPOSITION records per JOB instance, indicating that many positions share one job title and description), the EMPOSITION record-type is displayed as a non-unique descendant.
2. Depicts the reverse. The EMPOSITION record-type is the root or entry segment and JOB is the unique descendant, since an EMPOSITION instance can have only one owner (for example, only one job title and description per position).

Note: Panels 1 and 2 may be the results of a single Master File. Consult Adapter for CA-IDMS Reporting Techniques, for additional information.

x

Given the rules in Simple Set, consider a more complex scenario called a common owner. A common owner structure contains a record-type that is the owner of two or more record-types. Several representations are possible. For example, the following figure depicts three ways to describe the EMPLOYEE, EXPERTISE, and EMPOSITION structure in one Master File:

1. Shows the EMPLOYEE record-type, the owner in both sets, mapped as the root segment of EMPOSITION and EXPERTISE. Since an EMPLOYEE record can have many EMPOSITION and EXPERTISE records, both descendants are non-unique.
2. Depicts the EMPOSITION record-type as the root segment of EMPLOYEE, which acts as the parent of EXPERTISE. Since an EMPOSITION record can have only one owner, EMPLOYEE is a unique descendant; EXPERTISE is a non-unique descendant of EMPLOYEE.
3. Depicts the EXPERTISE record-type as the parent of EMPLOYEE, which acts as the parent of EMPOSITION. EMPLOYEE is a unique descendant and EMPOSITION is a non-unique descendant of EMPLOYEE.

x

When an IDMS record-type is a member of two or more sets, the association of the owner record-type as the parent segment must be abandoned for one or more sets because a segment in a Master File can have only one parent. The following figure displays the possible interpretations for this IDMS configuration:

The EMPLOYEE record-type is a common member in the DEPT-EMPLOYEE and the OFFICE-EMPLOYEE sets. This structure can be described in a Master File in three ways:

1. Shows DEPARTMENT as the root segment with EMPLOYEE as its non-unique descendant. OFFICE is the unique descendant of EMPLOYEE.
2. Depicts the reverse. OFFICE is the root segment. EMPLOYEE is its non-unique descendant. DEPARTMENT is the unique descendant of EMPLOYEE.
3. Shows the only other alternative. EMPLOYEE is the parent of OFFICE and DEPARTMENT. Both descendants are unique, since an EMPLOYEE can belong to only one OFFICE and DEPARTMENT.

Notice that the rules for simple sets are still valid:

• If the owner record-type is the parent segment, the member record-type as a descendant segment is non-unique.
• If the member record-type is the parent segment, the owner record-type as a descendant segment is unique.
• A member or an owner record-type may act as a root segment. (It does not matter if the root segment is unique or non-unique.)

It may be helpful to think of the hierarchical depiction of a network structure as its navigational path. From an IDMS standpoint, panel 1 shows that the IDMS data source can be entered at the DEPARTMENT record-type. The corresponding EMPLOYEE record occurrences for a DEPARTMENT record occurrence can be obtained by searching the DEPT-EMPLOYEE set. For each EMPLOYEE record occurrence, the corresponding OFFICE record occurrence is retrieved by obtaining the owner in the OFFICE-EMPLOYEE set. This is a three-segment retrieval hierarchy that maps to Master Files.

x

When there is more than one member record-type, the set is called a multi-member set.

A multi-member set is represented in the Master File exactly like a Multi-Member. The fact that the two relationships are based on the same set is stated in the Access File.

For example, to describe the COVERAGE record-type and its three members of the COVERAGE-CLAIMS set, you may choose one of four ways, as depicted in the following figure:

1. Shows the COVERAGE record-type, owner of the multi-member set, as the root segment. Since several instances of CLAIMS can be reported against one insurance policy (COVERAGE), each member is a non-unique descendant.
2. Depicts HOSPITAL-CLAIM as the parent of COVERAGE, and the other two member record-types as descendants of COVERAGE. In each case, a claim can be reported against only one insurance policy. This explanation applies to panels 3 and 4 as well.

x

Bill-of-materials structures are classified as simple or multi-tiered. In this topic, the simple version is discussed first.

Two record-types linked by more than one set are called a bill-of-materials structure. This structure describes a many-to-many relationship between record occurrences of the same record-type. The member record-type is the junction record-type between the two related owners.

For a simple bill-of-materials structure, the owner record-type must be represented as two or more segments in the Master File with different field names for the identical fields. This ensures that, at retrieval time, the field names you specify in a request will provide the proper navigational path. The following figure illustrates this type of structure:

The EMPLOYEE and STRUCTURE record-types are connected by two sets. This simple bill-of-materials structure can be described two ways:

1. Shows the relationship as employee-to-manager. The EMPLOYEE record-type is the parent segment of the non-unique STRUCTURE segment using the REPORTS-TO set. The STRUCTURE record-type, in turn, is the parent segment of the unique MANAGER segment using the MANAGES set. (The MANAGER segment duplicates the EMPLOYEE segment, and its fields are renamed.)
2. Shows the relationship as employee-to-subordinate. The EMPLOYEE record-type is the parent segment of the non-unique STRUCTURE segment using the MANAGES set. The STRUCTURE record-type is the parent segment of the unique SUBORD segment using the REPORTS-TO set. (The SUBORD segment duplicates the EMPLOYEE segment and its fields are renamed.)

This structure represents a two-tiered employee-to-employee relationship. Multi-tiered relationships are extended bill-of-materials structures. Multi-tiered relationships are created and used for different levels of reporting. The number of levels or tiers should be kept to a minimum.

To determine the number of segments required to describe an n-tiered relationship, use this formula:

Number of segments = (2 x number of tiers) - 1

The following represents a three-tiered version of the previous structure:

1. Combines both views with EMPLOYEE as the parent of two non-unique descendants, S1 and S2. Both S1 and S2, in turn, are parents of unique descendants, MGT and SUB, respectively. (S1 and S2 describe junction records that point to MGT and SUB.)
2. Shows a three-tiered relationship between employees implemented in a five-segment single-path hierarchy. The segments UPRMGT (upper management), 1STLNMGT (first-line management), and NON_MGT (non-management) all describe the EMPLOYEE segment but have renamed fields. (Like S1 and S2 above, STRUCT1 and STRUCT2 contain renamed fields that point to descendant segments.)
3. Depicts the opposite of panel 2.

x

Loop structures in IDMS implement complicated relationships between record-types. For the Master File depiction of a loop, you must select a record-type to be the parent in the relationship.

Consider the following loop structure:

An INVOICE record occurrence has an owner record occurrence (INVENTORY-ITEMS) only if the invoice order is pending or has not been delivered. The INVO-LOCATION set lists the location where an invoice item will be or was delivered.

Panel 1 translates this structure as a multi-tiered structure with one tier of renamed segments. The INVENTORY-ITEMS record-type, in this case, acts as the root INVENTORY. The LOCATION record-type is mapped as the CURRLOC segment, which lists the location of items currently in stock. The INVOICE record-type is mapped as the PENDINVO segment, which lists pending invoice orders. Segments ORGINVO and FUTRELOC are required segments that rename the data in record-types INVOICE and LOCATION. The segment ORGINVO contains historical information for an inventory item. The segment FUTRELOC indicates where an ordered item will be delivered.

x

Logical relationships, unlike physical ones, are based on the occurrence of the same data value in two different record-types. To make the parent/descendant connection, the adapter uses CALC fields or indexes to locate the related record occurrences. The related fields are not required to have the same name in both record-types, but the field format must be the same. See Adapter for CA-IDMS Master Files for additional information on format conversions.

• Selection criteria on CALC fields and indexes are also used to generate CALC and index calls to IDMS. This topic is discussed in detail in CA-IDMS Record Retrieval Intervals.
• CALC or index fields can also be groups consisting of fields contiguous in both parent and descendant segments. The format types and lengths of the GROUP and its fields must be comparable in both parent and descendant segments. Consult Adapter for CA-IDMS Master Files, for more information.

The adapter currently supports IDMS Integrated Indexes. As of IDMS Release 12, indexes can be integrated with the database management system (DBMS). The DBMS handles all index access and maintenance for Integrated Indexes.

Like set-based descendants, CALC- and index-based descendants are unique or non-unique, but this depends largely on how the DUPLICATES attribute is specified in the Access File. (The SEGTYPE attribute for the descendant must also reflect the DUPLICATES attribute. For example, if CLCDUP=N, SEGTYPE=U.) Unique descendants are treated in the same manner regardless of what underlies the parent/descendant relationship: set, index, or CALC field.

Note: Inversions that reverse CALC- or index-based segments result in an error message if the segments are referenced in a report request.

The COVERAGE and INSURANCE-PLAN record-types in Set-Based Relationships illustrate a logical relationship. The field PLAN-CODE is common to both record-types. The parent/descendant relationship can be described in the Master File if:

• The INSURANCE-PLAN record-type has an index on PLAN-CODE.
• The INSURANCE-PLAN record-type is an IDMS CALC record-type with PLAN-CODE as the CALC key.

The following figure depicts the Master File representation of the set-based relationship using the CALC field method. COVERAGE is the parent segment and INSURANCE-PLAN is the descendant. Since the DUPLICATES parameter is set to N (CLCDUP=N), the INSURANCE segment is unique:

x

As illustrated in previous examples, there are four ways to implement a network relationship. Each can be described as a parent/descendant relationship:

• Owner/member
• Member/owner
• Field or GROUP/CALC field
• Field or Integrated Index

All four can be intermixed in one Master File. The actual underlying connection (set, CALC, index) between parent and descendant is not apparent to end users who only need to know Master File field names. In addition, a Master File can list record-types from multiple subschemas, data sources, and dictionaries.

It is important to remember that your Master File is a default description. You can manipulate your Master File at execution time through file inversion. File inversions and their implications are described in Adapter for CA-IDMS Reporting Techniques.

In report processing, the identity of the record-type behind a segment is invisible. The retrieval technique is followed in all cases as if all segments were represented by distinct records. Within IDMS, currencies are maintained by storing the DBKEYs of record-types and retrieving the record occurrence again, when needed.

The top-to-bottom order in which segments are defined, the chains of parent/descendant relationships, corresponds to structural relationships among the IDMS record-types. This top-to-bottom order is logically significant. The left-to-right order is not.