Field group design: Difference between revisions

From m204wiki
Jump to navigation Jump to search
 
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==Overview==
==Overview==
<p>
<var class="product">Model&nbsp;204</var> supports non-relational, de-normalized data structures. Many <var class="product">Model&nbsp;204</var> sites have enjoyed significant cost and performance benefits from efficiently processing multiply occurring fields. This concept has been enhanced to introduce <b>physical field groups</b>, which let you view and process a group of fields as a single logical entity.</p>


<p><var class="product">Model&nbsp;204</var> supports non-relational, de-normalized data structures. Many <var class="product">Model&nbsp;204</var> sites have enjoyed significant cost and performance benefits from efficiently processing multiply occurring fields. This concept has been enhanced to introduce repeated field groups that let you view and process groups of fields as a logical entity.</p>
This feature is available as of Model 204 version 7.5.


This feature is available in Version 7 Release 5.
===Traditional approaches to multiply occurring fields===
Consider the following approaches to the same data. A customer might have a number of different addresses (for example, home and postal) with the same data (house number, street, city, state, and postal code) for each.


Take the following approaches to the same data. A customer may have a number of different addresses (for example: home and postal); with the same data: house number; street; city; state; and postal code for each.
You might define these fields:
 
So, you could define the following fields:


:HOME_HOUSE_NUMBER
:HOME_HOUSE_NUMBER
Line 20: Line 21:
:POST_POSTAL_CODE
:POST_POSTAL_CODE


Or you could define the following fields  
Or, by identifying an address type for each address, you might define the following fields, and have your application code maintain the occurrences of the repeatable fields as sets:


:ADDRESS_TYPE
:ADDRESS_TYPE
Line 29: Line 30:
:POSTAL_CODE  
:POSTAL_CODE  


and, by identifying an address type for each address, have your application code maintain the occurrences of the repeatable fields so that they could be managed as sets. Add historical data to this (as the customer might move during his lifetime, and you may want to track this history) maintaining these sets becomes problematic.  
However, if you add historical data (the customer might move during his lifetime, and you may want to track this history), maintaining these sets of fields becomes problematic. And as the records grow, there might also be performance issues: although the application treats them as a logical group, it still must update and retrieve the fields individually.
 
As the records grow, there may also be performance issues as, although the application treats them as a group, it still must update and retrieve the fields individually.  


As of Model 204 V7R5, there is a third option, you can define these fields as part of a [[Repeating Field Group (File Architecture)|Repeating Field Group]] (RFG). This option natively treats the fields as a single entity for retrieving and updating.
===Field group approach to multiply occurring fields===
As of Model 204 version 7.5, there is a third approach to multiply occurring fields: you can define these fields as part of a [[Field group (File architecture)|field group]]. This option natively treats the fields as a single entity for retrieving and updating.


The effect of this is that you can define a Model 204 Record as a container for different relational tables, with the advantages of having them pre-joined (in the one physical record) and being able to maintain them in whatever relative order the application requires.  
The effect of this is that you can define a Model 204 record as a container for different relational tables, with the advantages of having them pre-joined (in the one physical record) and being able to maintain them in whatever relative order the application requires.  


This option is only available by setting the <var>[[FILEORG parameter|FILEORG]]</var> parameter to <code>X'100'</code>.
<p class="note"><b>Note:</b> This option is only available by setting the <var>[[FILEORG parameter|FILEORG]]</var> parameter to <code>X'100'</code>.</p>


This enhancement changes both the file DDL (as follows) and the User Language DML.
This enhancement changes both the file DDL (as follows) and the SOUL DML.


==Field groups and Table B storage considerations==
==Field groups and Table B storage considerations==
<p>Every record in a FILEORG=X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.  
<p>
Every record in a <var>FILEORG</var> X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs. </p>
<p>
As is true of all <var>FILEORG</var> X'100' files, the field name representation (as held in [[Table A (File architecture)|Table A]] and thus in the record) is three bytes in length. Depending on the definitions of the fields within the group, this may be offset by the physical absence of fields defined as part of the group.</p>


As is true of all FILEORG=X'100' files, the field name representation (as held in [[Table A (File Architecture)|Table A]] and thus in the record, are three bytes in length. Depending on the definitions of the fields within the group, this may be offset by the physical absence of fields defined as part of the group.</p>
==Defining a field group ==
<p>
You must define a field group before you define the fields that it contains. As you define them, keep track of the names you assign, because both field groups and fields are stored in Table A of the <var class="product">Model&nbsp;204</var> file, so each name must be unique. </p>


==Defining a field group ==
<p>You must define a field group before you define the fields that it contains. As you define them, keep track of the names you assign, because both field groups and fields are stored in Table A of the <var class="product">Model&nbsp;204</var> file, so each name must be unique. </p>
<p>The following syntax is used to define a field group:</p>
<b>Syntax</b>
<b>Syntax</b>
<p>
The <var>[[DEFINE FIELDGROUP command|DEFINE FIELDGROUP]]</var> command is used to define a field group:</p>
<p class="syntax">DEFINE FIELDGROUP <span class="term">fieldGroupName</span>
<p class="syntax">DEFINE FIELDGROUP <span class="term">fieldGroupName</span>
</p>
</p>
<p>Where <var class="term">fieldGroupName</var> specifies the name of the field group you are defining. The rules for the field group name are the same as for [[Field Design (File Management)#Field Naming|fields]]. </p>
<p>
Where <var class="term">fieldGroupName</var> specifies the name of the field group you are defining. The rules for the field group name are the same as for [[Field design#Field naming|fields]]. </p>


== Defining a field inside a field group ==
==Defining a field inside a field group==
<p>Use the following syntax to define the field(s) for a field group:</p>
<p>
<b>Syntax</b>
Use the following syntax to define the field(s) for a field group:</p>
<p class="syntax">DEFINE FIELD <span class="term">fieldName</span>  
<p class="syntax">DEFINE FIELD <span class="term">fieldName</span>  
   WITH FIELDGROUP <span class="term">fieldGroupName</span> [AND
   WITH FIELDGROUP <span class="term">fieldGroupName</span> [AND [(<span class="term">attribute1 attribute2</span> ...)]]
  [(<span class="term">attribute1 attribute2</span> ...)]]
</p>
</p>
<p>Where:</p>
<p>Where:</p>
<ul>
<ul>
<li><var class="term">fieldName</var> specifies a unique name for a field.</li>
<li><var class="term">fieldName</var> specifies a unique name for a field.</li>
<li>The <code>WITH FIELDGROUP <span class="term">fieldGroupName</span></code> clause identifies the containing field group. When <var class="term">fieldGroupName</var> is indicated as an asterisk (*), it means that the field is included into all field groups defined for this file.</li>
 
<li><var class="term">attribute1 attribute2 </var>... specifies other field attributes.</li>
<li>The <code>WITH FIELDGROUP <i>fieldGroupName</i></code> clause identifies the containing field group.  
<p>
<var>FG</var> is a synonym for <var>FIELDGROUP</var>.</p>
<p>
If <var class="term">fieldGroupName</var> is indicated with an asterisk (<tt>*</tt>), the field is included in all field groups defined for this file.</p></li>
 
<li><var class="term">attribute1 attribute2 </var>... specifies other field attributes.
<p>
Of the [[Field design#AT-MOST-ONE, REPEATABLE, and EXACTLY-ONE attributes|occurrence attributes]] (<var>AT-MOST-ONE</var>, <var>EXACTLY-ONE</var>, and <var>REPEATABLE</var>), <var>EXACTLY-ONE</var> is the default for a field defined within a field group. </p>
<p class="note"><b>Note:</b> The <var>OCCURS</var> attribute may not be specified for a
field group field. </p></li>
</ul>
</ul>
<b>Example</b>
 
====Example====
<p>
<p>
To define a field group <code>MAKEMODEL</code> with fields <code>MAKE</code> and <code>MODEL</code> in it, you would write the following definition:</p>
To define a field group <code>MAKEMODEL</code> with fields <code>MAKE</code> and <code>MODEL</code> in it, you would write the following definition:</p>
<p class="code">DEFINE FIELDGROUP MAKEMODEL
<p class="code">DEFINE FIELDGROUP MAKEMODEL
DEFINE FIELD MAKE WITH FIELDGROUP MAKEMODEL AND ORDERED CHARACTER
DEFINE FIELD MAKE WITH FIELDGROUP MAKEMODEL AND ORDERED CHARACTER
DEFINE FIELD MODEL WITH FIELDGROUP MAKEMODEL
DEFINE FIELD MODEL WITH FG MAKEMODEL
</p>
</p>
<b>Usage</b>
 
<p>Defining fields after defining the containing field group makes it possible to later add fields to an already defined field group, for example:</p>
====Usage====
<ul>
<li>Defining fields after defining the containing field group makes it possible to later add fields to an already defined field group. For example:
<p class="code">DEFINE FIELD MPG WITH FIELDGROUP MAKEMODEL
<p class="code">DEFINE FIELD MPG WITH FIELDGROUP MAKEMODEL
</p>
</p></li>
<p>The keyword <var>AND</var> on field definitions means that a field group name can contain blanks, just like a field name. You must use the <var>AND</var> keyword to separate the field group name from subsequent attributes:</p>
 
<li>The keyword <var>AND</var> on field definitions means that a field group name can contain blanks, just like a field name. You must use the <var>AND</var> keyword to separate the field group name from subsequent attributes:
<p class="code">DEFINE FIELD COLOR WITH FIELDGROUP MAKEMODEL AND ORDERED CHARACTER
<p class="code">DEFINE FIELD COLOR WITH FIELDGROUP MAKEMODEL AND ORDERED CHARACTER
</p>
</p>
<p>The <var>AND</var> is unnecessary if the <code>FIELDGROUP <span class="term">fieldGroupName</span></code> clause is the last field attribute:</p>
<p>
The <var>AND</var> is unnecessary if the <code>FIELDGROUP <span class="term">fieldGroupName</span></code> clause is the last field attribute:</p>
<p class="code">DEFINE FIELD COLOR WITH ORDERED CHARACTER FIELDGROUP MAKEMODEL
<p class="code">DEFINE FIELD COLOR WITH ORDERED CHARACTER FIELDGROUP MAKEMODEL
</p>
</p>
<p class="note"><b>Note:</b> The <code>MAKEMODEL</code> field group must be defined before defining the field(s) and/or field group(s) that belong with it.</p>
<p class="note"><b>Note:</b> The <code>MAKEMODEL</code> field group must be defined before defining the field(s) and/or field group(s) that belong with it.</p></li>
</ul>


==FIELDGROUP (FG) attribute==
==FIELDGROUP (FG) attribute==
<p>The <var>FIELDGROUP</var> attribute specifies the name of the field group that the defined field is associated with (contained in). Once you define a <var>FIELDGROUP</var> value for a field, you cannot redefine the <var>FIELDGROUP</var> value.</p>
<p>
The <var>FIELDGROUP</var> attribute specifies the name of the field group with which a defined field is associated (contained in). For example, <code>DEFINE FIELD MEMBER WITH FG INNER</code>. Once you define a <var>FIELDGROUP</var> value for a field, you cannot redefine the <var>FIELDGROUP</var> value.</p>
 
<b>Syntax</b>
<b>Syntax</b>
<p class="syntax">FIELDGROUP [<var class="term">fieldgroupname</var> | *]
<p class="syntax">FIELDGROUP [<span class="term">fieldgroupname</span> <span class="squareb">|</span> *]
</p>
</p>
<p>The <var>FIELDGROUP</var> attribute does not allow:</p>
<p>The <var>FIELDGROUP</var> attribute does not allow:</p>
Line 97: Line 119:
<li><var>1NF</var> file model</li>
<li><var>1NF</var> file model</li>
</ul>
</ul>
<p>The <var>FIELDGROUP</var> attribute can be used with the <var>STORE-NULL LITERAL</var> attribute.</p>
<p>
<b>Using FIELDGROUP*</b>
The <var>FIELDGROUP</var> attribute can be used with the <var>STORE-NULL LITERAL</var> attribute.</p>
<p>The <var>FIELDGROUP *</var> attribute means that the field will be included into all field groups.</p>
<p>The <var>EXACTLY-ONE</var> attribute conflicts with the <var>FIELDGROUP *</var> attribute.</p>
<b>Other attributes to consider</b>
<p>The default attribute for frequency of occurrence for fields in a field group is <var>EXACTLY-ONE</var> (instead of the default for individually defined fields of <var>REPEATABLE</var>). The other options <var>REPEATABLE</var> and <var>AT-MOST-ONE</var> can also be used.</p>
<p>Because fieldgroups contain sets of data, the setting of a Default Value (DV), the Store Default (SD) and the Store Null (SN) settings can (for field types other than <var>REPEATABLE</var>) overcome the added space overhead described above.</p>


==Displaying field group definitions ==
====Using FIELDGROUP *====
<p>Field groups can be displayed in alphabetical order as follows:</p>
<p>
The <var>FIELDGROUP *</var> attribute means that the field will be included into all field groups.</p>
<p>
The <var>EXACTLY-ONE</var> attribute conflicts with the <var>FIELDGROUP *</var> attribute.</p>
 
====Other attributes to consider====
<p>
The default attribute for frequency of occurrence for fields in a field group is <var>EXACTLY-ONE</var> (instead of <var>REPEATABLE</var>, the default for individually defined fields). The options <var>REPEATABLE</var> and <var>AT-MOST-ONE</var> can also be used.</p>
<p>
Because field groups contain sets of data, the Default Value (DV), Store Default (SD), and Store Null (SN) settings can overcome (for field types other than <var>REPEATABLE</var>) the added space overhead described above.</p>
 
==Displaying field group definitions==
<p>
Field groups can be displayed in alphabetical order as follows:</p>
<p class="code">IN POLICIES DISPLAY FIELDGROUP ALL
<p class="code">IN POLICIES DISPLAY FIELDGROUP ALL
CLAIM
</p>
<p>
This command produces output like the following:
</p>
<p class="output">CLAIM
   (FIELDGROUP VEHICLE)
   (FIELDGROUP VEHICLE)
DRIVER
DRIVER
Line 118: Line 152:
Because the "container group" must be specified before its members, the previous command's output cannot be fed back into <var class="product">Model&nbsp;204</var> to define the field groups in an empty file. Instead, use the <var>DDL</var> option with the display command:</p>
Because the "container group" must be specified before its members, the previous command's output cannot be fed back into <var class="product">Model&nbsp;204</var> to define the field groups in an empty file. Instead, use the <var>DDL</var> option with the display command:</p>
<p class="code">IN POLICIES D FIELDGROUP (DDL) ALL
<p class="code">IN POLICIES D FIELDGROUP (DDL) ALL
<b></b>*** DDL FOR FILE POLICIES
</p>
<p>
This command produces output like the following:
</p>
<p class="output"><b></b>*** DDL FOR FILE POLICIES
<b></b>*** DDL REQUEST DATE/TIME: 10.102  APR 12  12.34.01
<b></b>*** DDL REQUEST DATE/TIME: 10.102  APR 12  12.34.01
DEFINE FIELDGROUP DRIVER -
DEFINE FIELDGROUP DRIVER -
Line 128: Line 166:
</p>
</p>


[[Category:File management]]
==See also==
<ul>
<li>[[Field group (File architecture)]]</li>
 
<li>[[Processing multiply occurring fields and field groups]] </li>
 
<li>[[Data_maintenance#Updating_field_groups|Updating field groups]]</li>
</ul>
 
[[Category:Model 204 files]]

Latest revision as of 18:22, 15 February 2019

Overview

Model 204 supports non-relational, de-normalized data structures. Many Model 204 sites have enjoyed significant cost and performance benefits from efficiently processing multiply occurring fields. This concept has been enhanced to introduce physical field groups, which let you view and process a group of fields as a single logical entity.

This feature is available as of Model 204 version 7.5.

Traditional approaches to multiply occurring fields

Consider the following approaches to the same data. A customer might have a number of different addresses (for example, home and postal) with the same data (house number, street, city, state, and postal code) for each.

You might define these fields:

HOME_HOUSE_NUMBER
HOME_STREET
HOME_CITY
HOME_STATE
HOME_POSTAL_CODE
POST_HOUSE_NUMBER
POST_STREET
POST_CITY
POST_STATE
POST_POSTAL_CODE

Or, by identifying an address type for each address, you might define the following fields, and have your application code maintain the occurrences of the repeatable fields as sets:

ADDRESS_TYPE
HOUSE_NUMBER
STREET
CITY
STATE
POSTAL_CODE

However, if you add historical data (the customer might move during his lifetime, and you may want to track this history), maintaining these sets of fields becomes problematic. And as the records grow, there might also be performance issues: although the application treats them as a logical group, it still must update and retrieve the fields individually.

Field group approach to multiply occurring fields

As of Model 204 version 7.5, there is a third approach to multiply occurring fields: you can define these fields as part of a field group. This option natively treats the fields as a single entity for retrieving and updating.

The effect of this is that you can define a Model 204 record as a container for different relational tables, with the advantages of having them pre-joined (in the one physical record) and being able to maintain them in whatever relative order the application requires.

Note: This option is only available by setting the FILEORG parameter to X'100'.

This enhancement changes both the file DDL (as follows) and the SOUL DML.

Field groups and Table B storage considerations

Every record in a FILEORG X'100' file contains the 4-byte highest allocated field group ID. Every occurrence of a field group has a unique binary ID that occupies from two to five bytes, thus supporting up to four gigabytes of field group IDs.

As is true of all FILEORG X'100' files, the field name representation (as held in Table A and thus in the record) is three bytes in length. Depending on the definitions of the fields within the group, this may be offset by the physical absence of fields defined as part of the group.

Defining a field group

You must define a field group before you define the fields that it contains. As you define them, keep track of the names you assign, because both field groups and fields are stored in Table A of the Model 204 file, so each name must be unique.

Syntax

The DEFINE FIELDGROUP command is used to define a field group:

DEFINE FIELDGROUP fieldGroupName

Where fieldGroupName specifies the name of the field group you are defining. The rules for the field group name are the same as for fields.

Defining a field inside a field group

Use the following syntax to define the field(s) for a field group:

DEFINE FIELD fieldName WITH FIELDGROUP fieldGroupName [AND [(attribute1 attribute2 ...)]]

Where:

  • fieldName specifies a unique name for a field.
  • The WITH FIELDGROUP fieldGroupName clause identifies the containing field group.

    FG is a synonym for FIELDGROUP.

    If fieldGroupName is indicated with an asterisk (*), the field is included in all field groups defined for this file.

  • attribute1 attribute2 ... specifies other field attributes.

    Of the occurrence attributes (AT-MOST-ONE, EXACTLY-ONE, and REPEATABLE), EXACTLY-ONE is the default for a field defined within a field group.

    Note: The OCCURS attribute may not be specified for a field group field.

Example

To define a field group MAKEMODEL with fields MAKE and MODEL in it, you would write the following definition:

DEFINE FIELDGROUP MAKEMODEL DEFINE FIELD MAKE WITH FIELDGROUP MAKEMODEL AND ORDERED CHARACTER DEFINE FIELD MODEL WITH FG MAKEMODEL

Usage

  • Defining fields after defining the containing field group makes it possible to later add fields to an already defined field group. For example:

    DEFINE FIELD MPG WITH FIELDGROUP MAKEMODEL

  • The keyword AND on field definitions means that a field group name can contain blanks, just like a field name. You must use the AND keyword to separate the field group name from subsequent attributes:

    DEFINE FIELD COLOR WITH FIELDGROUP MAKEMODEL AND ORDERED CHARACTER

    The AND is unnecessary if the FIELDGROUP fieldGroupName clause is the last field attribute:

    DEFINE FIELD COLOR WITH ORDERED CHARACTER FIELDGROUP MAKEMODEL

    Note: The MAKEMODEL field group must be defined before defining the field(s) and/or field group(s) that belong with it.

FIELDGROUP (FG) attribute

The FIELDGROUP attribute specifies the name of the field group with which a defined field is associated (contained in). For example, DEFINE FIELD MEMBER WITH FG INNER. Once you define a FIELDGROUP value for a field, you cannot redefine the FIELDGROUP value.

Syntax

FIELDGROUP [fieldgroupname | *]

The FIELDGROUP attribute does not allow:

  • Record security
  • Use for SORT or HASH file
  • 1NF file model

The FIELDGROUP attribute can be used with the STORE-NULL LITERAL attribute.

Using FIELDGROUP *

The FIELDGROUP * attribute means that the field will be included into all field groups.

The EXACTLY-ONE attribute conflicts with the FIELDGROUP * attribute.

Other attributes to consider

The default attribute for frequency of occurrence for fields in a field group is EXACTLY-ONE (instead of REPEATABLE, the default for individually defined fields). The options REPEATABLE and AT-MOST-ONE can also be used.

Because field groups contain sets of data, the Default Value (DV), Store Default (SD), and Store Null (SN) settings can overcome (for field types other than REPEATABLE) the added space overhead described above.

Displaying field group definitions

Field groups can be displayed in alphabetical order as follows:

IN POLICIES DISPLAY FIELDGROUP ALL

This command produces output like the following:

CLAIM (FIELDGROUP VEHICLE) DRIVER () VEHICLE ()

Because the "container group" must be specified before its members, the previous command's output cannot be fed back into Model 204 to define the field groups in an empty file. Instead, use the DDL option with the display command:

IN POLICIES D FIELDGROUP (DDL) ALL

This command produces output like the following:

*** DDL FOR FILE POLICIES *** DDL REQUEST DATE/TIME: 10.102 APR 12 12.34.01 DEFINE FIELDGROUP DRIVER - () DEFINE FIELDGROUP VEHICLE - () DEFINE FIELDGROUP CLAIM - (FIELDGROUP VEHICLE)

See also