Model 204 Overview and Mapping Considerations

In this section:

A Model 204 file can represent one file or a collection of files called a group. A single Model 204 file can contain records that vary in length and format; a record can consist of fields that also vary in length. Fields are the smallest elements or units of data. They can occur more than once per record. A unit of records with identical sets of fields is called a logical record type. A Model 204 file is defined in a Model 204 file description.

In the sections that follow, you will notice that:


Top of page

x
Files With One Logical Record Type

A Model 204 file that contains records with identical sets of fields (the same logical record type) can be represented as a single Master File segment. Each Model 204 field that occurs only once becomes a Master File field. The ALIAS attribute in the Master File identifies the Model 204 field name.

In the Master File, describe the logical record type as a segment. The segment description can include some or all of the Model 204 fields in any order. The corresponding Access File identifies the record type's Model 204 file or group name and its password; the Access File can also include FIELD declarations that specify a TYPE attribute to indicate the appropriate suffix operators for Model 204 key fields. Master File field suffix operators (for example, KEY) identify different types of Model 204 key fields.

Note: A Model 204 field that can occur more than once should be represented as a separate OCCURS segment.

  1. Is one Model 204 file with one logical record type.
  2. Is the equivalent server Master File segment. The Master File field VVIN represents the Model 204 field VIN.

Top of page

x
Files With Multiply Occurring Fields

In Model 204 files, some fields may appear more than once per record. Represent each multiply occurring field separately from the non-repeating fields as a server Master File OCCURS segment. In this case, the Master File contains a parent segment to describe all the non-repeating fields, and a separate dependent OCCURS segment for each multiply occurring field.

When you create a Master File, describe the OCCURS segment only if you need the multiply occurring field for your reports. You are not required to describe every multiply occurring field. Do not describe the OCCURS segment in the corresponding Access File unless its size exceeds the buffer capacity, a situation that is explained in Customizing the Model 204 Environment.


Top of page

x
Describing Files to the Server

The following diagram illustrates one multiply occurring field and its equivalent OCCURS segment:

  1. Is the Model 204 VEHICLES file with one logical record type and one multiply occurring field called OTHER DRIVER that identifies drivers besides the principal driver.
  2. Is the equivalent multi-segment server structure. The parent (or root, in this case) is the VEHICLE segment; it contains all of the non-repeating fields. The dependent segment is the OCCURS segment which contains iterations of the Model 204 OTHER DRIVER field. In the Master File, the segment declaration for the dependent segment must include the OCCURS attribute.

If a Model 204 file contains multiple logical record types, each logical record type corresponds to one segment. You can represent a Model 204 file with several logical record types either:

In a multi-segment Master File, you can include segment descriptions for all of the logical record types or only those you need for your reports. To identify the parent of a dependent segment, specify the PARENT attribute in the segment declaration of the dependent segment.

In the corresponding Access File, for each logical record type you must specify the:

Note: Record type fields identify individual record types that reside in the same Model 204 file. Model 204 files that consist of one logical record type do not require record type fields. In the Access File, the RECTYPE and RECTVAL attributes specify record type fields and the values.


Top of page

x
Mapping Model 204 and Server Relationships

In Model 204, interfile relationships are not coded in the Model 204 file description. This provides a certain degree of flexibility because the Model 204 files can be cross-referenced dynamically. On the other hand, the burden of connecting the Model 204 files falls on the user.

Model 204 relationships between logical record types are cross-referenced using shared key fields. The adapter supports this implementation. You can logically join Model 204 files using the adapter with either of the following techniques:

Both techniques are described in the following sections.


Top of page

x
Dynamic Joins

If there is a shared or common field, you can use the server JOIN command to dynamically Join:

The following diagram illustrates a Model 204 Join and its equivalent Server Join:

  1. Are two Model 204 files, VEHICLES and CLIENTS. Each file contains one logical record type for this example. The common or key field is VIN.
  2. Are two equivalent server segments. Each segment is described in a separate pair of Master and Access Files. The field names for the common field are VEHICLE_IDENTIFICATION_NUMBER and VVIN. The Model 204 key fields are specified with the TYPE=KEY attribute in the Access File.

The JOIN command includes the names of the Master Files and the common field names. To retrieve data from the joined structure, issue a report request that specifies the host (or parent) Master File from the JOIN command.

Note: Since in this example each Model 204 file consists of one logical record type, record type fields are not specified in the Access Files.

The following diagram illustrates a Model 204 file with two record types and the Server Join:

  1. Is the Model 204 CLIENTS file containing two logical record types. The common or key field is POLICY NO. The RECTYPE field contains the value POLICYHOLDER for the HOLDER record type and the value DRIVER for the DRIVER record type.
  2. Are two equivalent Master File segments. Each segment is described in a separate pair of Master and Access Files. The field names for the common field are POLICY_NUMBER and DRIVER_POLICY_NUMBER. The Model 204 key fields are specified with the TYPE=KEY attribute in the Access File. Since both record types reside in the same Model 204 file, each Access File segment declaration also includes RECTYPE (record type) and RECTVAL (record type value) attributes.

The JOIN command includes the names of the Master Files and the common field names. To retrieve data from the joined structure, issue a report request that specifies the host (or parent) Master File from the JOIN command.


Top of page

x
Embedded Joins

You can also implement Join relationships by describing a multi-segment FOCUS structure in a single pair of Master and Access Files. If there is a shared or common field, you can create an Embedded Join for:

Embedded Joins offer two advantages:

When you create a Master File, describe the Model 204 logical record types or files as a hierarchy. Start first by choosing a record type or file to be the root segment. The root segment has dependent segments which, in turn, may have dependent segments. The dependent segments identify the superiors (or parents) with the PARENT attribute. Any record type can act as a dependent provided that its shared field is a key field.

In the associated Access File, for each pair of related segments, specify the shared field from the parent and dependent segments with the KEYFLD and IXFLD attributes. The Interface implements the relationship by matching values at run time.

The Embedded Join is executed automatically when you issue a report request that references fields from two related segments. You do not specify the shared field in your report request; the selection of the shared field is transparent.

Note: It is possible to join unrelated Model 204 files and record types that do not have common fields by describing a DUMMY segment.

The following diagram illustrates an Embedded Join for two Model 204 files:

  1. Are two Model 204 files, VEHICLES and CLIENTS. Each file contains one logical record type for this example. Since they exist as physically separate files, they do not contain a Model 204 record type field. The common or key field is VIN.
  2. Are two equivalent FOCUS segments described in one pair of Master and Access Files. The field names for the common field are VEHICLE_IDENTIFICATION_NUMBER and VVIN. The Model 204 key fields are specified with the TYPE=KEY attribute in the Access File.

    To create a parent/child relationship, describe the HOLDER segment as the parent (or root) and the VEHICLE segment as the dependent in the Master File. Include the PARENT=HOLDER attribute in the segment declaration for VEHICLE. In the Access File, specify the KEYFLD and IXFLD attributes to create the Embedded Join.

The following diagram illustrates an Embedded Join for a Model 204 file with two record types:

  1. Is the Model 204 CLIENTS file containing two logical record types. The common or key field is POLICY NO. The RECTYPE field contains the value POLICYHOLDER for the HOLDER record type and the value DRIVER for the DRIVER record type.
  2. Are two equivalent FOCUS segments described in one pair of Master and Access Files. The field names for the common field are POLICY_NUMBER and DRIVER_POLICY_NUMBER. The Model 204 key fields are specified with the TYPE=KEY attribute in the Access File. Since both record types reside in the same Model 204 file, the Access File segment declarations also include the RECTYPE (record type) and RECTVAL (record type value) attributes.

    To create a parent/child relationship, describe the HOLDER segment as the parent (or root) and the DRIVER segment as the dependent in the Master File. Include the PARENT=HOLDER attribute in the segment declaration for DRIVER. In the Access File, specify the KEYFLD and IXFLD attributes in the DRIVER segment declaration to create the Embedded Join.


Top of page

x
Joining Unrelated Files

You can describe unrelated Model 204 files or logical record types as Embedded Joins even if a shared field does not exist. To do so, describe a special dummy segment (SEGNAME=DUMMY) as the root in the Master File. Then, specify the unrelated segments as parallel dependents of the dummy root. Since the dummy segment is a virtual segment, do not describe fields for it in the Master File, and do not include a corresponding segment declaration for it in the Access File.

If your report request includes fields from two or more segments, FOCUS makes only one retrieval pass over the answer set returned by the Model 204 DBMS. Fields specified for sort phrases (BY and ACROSS) and screening tests (IF and WHERE) must lie on the same retrieval path as the other requested fields. You cannot use a field from one unrelated segment to sort the data in other segments.

The following diagram illustrates two Model 204 files, the CLIENTS file and the VEHICLES file. These two files are joined using a FOCUS dummy segment:

  1. Are two Model 204 files, CLIENTS and VEHICLES. The record type field in the DRIVER segment identifies all client records that have the value 'DRIVER'. A dummy segment is needed because there is no shared field to cross-reference or join these files.
  2. Is an equivalent multi-segment FOCUS structure. The root is a DUMMY segment. The two dependents are related to the root. They are not related to each other because a common field does not exist.

To create a Master File for this structure, specify the segment declaration for the dummy segment (SEGNAME=DUMMY) first, so it functions as the root. Do not describe fields for it. Then, describe the dependent segments, and include the PARENT=DUMMY attribute to identify the dummy segment as the parent. In the associated Access File, do not specify a segment declaration for the dummy segment; include segment declarations only for the dependent segments. The record type field is required in the DRIVER segment since the DRIVER segment comes from a Model 204 file, CLIENTS, that contains two logical record types. Do not specify KEYFLD/IXFLD values.


Top of page

x
Summary of Mapping Rules

Model 204 and FOCUS use similar elements:

Model 204 Entities

FOCUS Entities

Model 204 field

FOCUS field

Logical record type

FOCUS segment

Individual record

Segment instance

Model 204 file with one record type

FOCUS segment

Multiply-occurring Model 204 fields in a record

FOCUS OCCURS segment

Some general rules for describing Model 204 files are:


iWay Software