Field group design: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
==Overview== | |||
<p><var class="product">Model 204</var> supports non-relational, de-normalized data structures. Many <var class="product">Model 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> | <p><var class="product">Model 204</var> supports non-relational, de-normalized data structures. Many <var class="product">Model 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> | ||
Revision as of 23:20, 22 April 2013
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 repeated field groups that let you view and process groups of fields as a logical entity.
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.
So, you could define the following 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 you could define the following fields
- ADDRESS_TYPE
- HOUSE_NUMBER
- STREET
- CITY
- STATE
- 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.
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 (RFG). 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.
This option is only available by setting the FILEORG parameter to X'100'
.
This enhancement changes both the file DDL (as follows) and the User Language 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, 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.
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.
The following syntax is used to define a field group:
Syntax
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:
Syntax
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. When fieldGroupName is indicated as an asterisk (*), it means that the field is included into all field groups defined for this file. - attribute1 attribute2 ... specifies other field attributes.
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 FIELDGROUP 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 that the defined field is associated with (contained in). 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 the default for individually defined fields of REPEATABLE). The other options: REPEATABLE, as well as AT-MOST-ONE may be used.
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 REPEATABLE) overcome the added space overhead described above.
Displaying field group definitions
Field groups may be displayed in alphabetical order as follows:
IN POLICIES DISPLAY FIELDGROUP ALL 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 *** 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)