Field attributes: Difference between revisions
mNo edit summary |
m (more conversion cleanup) |
||
Line 1: | Line 1: | ||
==File model feature== | |||
<p>The file manager defines fields and assigns attributes to each field, as described in [[Defining fields manually]]. The field attributes listed on this page are of interest to the application developer.</p> | <p> | ||
<p>You can enforce file-wide constraints on files and fields with two <var class="product">Model 204</var> file models:</p> | The file manager defines fields and assigns attributes to each field, as described in [[Defining fields manually]]. The field attributes listed on this page are of interest to the application developer.</p> | ||
<p> | |||
You can enforce file-wide constraints on files and fields with two <var class="product">Model 204</var> file models:</p> | |||
<table> | <table> | ||
<tr class="head"> | <tr class="head"> | ||
Line 7: | Line 9: | ||
<th>Action...</th> | <th>Action...</th> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>Numeric Validation </td> | <td>Numeric Validation </td> | ||
<td>Causes <var class="product">Model 204</var> to perform numeric data type validation on fields defined as FLOAT or BINARY.</td> | <td>Causes <var class="product">Model 204</var> to perform numeric data type validation on fields defined as FLOAT or BINARY.</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>1NF (First-Normal Form) </td> | <td>1NF (First-Normal Form) </td> | ||
Line 16: | Line 20: | ||
</tr> | </tr> | ||
</table> | </table> | ||
<p>Use the [[FILEMODL parameter]] to set a file model when creating a file. </p> | <p> | ||
Use the [[FILEMODL parameter]] to set a file model when creating a file. </p> | |||
==Field attribute descriptions== | |||
<p>If a field is defined as having the AT-MOST-ONE attribute, <var class="product">Model 204</var> prevents multiple occurrences of that field in any given record. However, unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated. </p> | |||
<p>If a field is not defined as AT-MOST-ONE, then it is REPEATABLE.</p> | ===AT-MOST-ONE and REPEATABLE attributes=== | ||
<p>REPEATABLE is the default except for First-Normal Form files, where AT-MOST-ONE is required on all fields. </p> | <p> | ||
If a field is defined as having the AT-MOST-ONE attribute, <var class="product">Model 204</var> prevents multiple occurrences of that field in any given record. However, unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated. </p> | |||
<p> | |||
<p>Although the names of the UNIQUE and AT-MOST-ONE attributes sound similar, they have very different meanings: </p> | If a field is not defined as AT-MOST-ONE, then it is REPEATABLE.</p> | ||
<p> | |||
REPEATABLE is the default except for First-Normal Form files, where AT-MOST-ONE is required on all fields. </p> | |||
===AT-MOST-ONE versus UNIQUE attributes=== | |||
<p> | |||
Although the names of the UNIQUE and AT-MOST-ONE attributes sound similar, they have very different meanings: </p> | |||
<ul> | <ul> | ||
<li>UNIQUE affects the value of the field</li> | <li>UNIQUE affects the value of the field</li> | ||
<li>AT-MOST-ONE affects the number of field occurrences per record | <li>AT-MOST-ONE affects the number of field occurrences per record | ||
</li> | </li> | ||
</ul> | </ul> | ||
<p>For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE; the UNIQUE attribute ensures that the social security number for every employee is different, and AT-MOST-ONE ensures that each employee has only one social security number. </p> | <p> | ||
<p>Both AT-MOST-ONE and UNIQUE are examples of "field level constraints."</p> | For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE; the UNIQUE attribute ensures that the social security number for every employee is different, and AT-MOST-ONE ensures that each employee has only one social security number. </p> | ||
<p> | |||
<p>If a field is defined with the BINARY-LARGE-OBJECT or CHARACTER-LARGE-OBJECT attribute, only the OCCURS attribute can also be assigned to the field.</p> | Both AT-MOST-ONE and UNIQUE are examples of "field level constraints."</p> | ||
<p>NULL support for Large object data is handled like the NULL support for string data. If you change Large Object data to null using:</p> | ===BINARY-LARGE-OBJECT and CHARACTER-LARGE-OBJECT attributes=== | ||
<p> | |||
If a field is defined with the BINARY-LARGE-OBJECT or CHARACTER-LARGE-OBJECT attribute, only the OCCURS attribute can also be assigned to the field.</p> | |||
====Handling NULL support for Large Object data==== | |||
<p> | |||
NULL support for Large object data is handled like the NULL support for string data. If you change Large Object data to null using:</p> | |||
<ul> | <ul> | ||
<li>Single quotation marks (' '), Table B stores the null and Table E deletes the former value.</li> | <li>Single quotation marks (' '), Table B stores the null and Table E deletes the former value.</li> | ||
<li>A trailing an equal sign (= ), the former value is deleted from both Table B and Table E.</li> | <li>A trailing an equal sign (= ), the former value is deleted from both Table B and Table E.</li> | ||
<li>A source that is zero (0), the former value is deleted from both Table B and Table E. | <li>A source that is zero (0), the former value is deleted from both Table B and Table E. | ||
</li> | </li> | ||
</ul> | </ul> | ||
<p>The FLOAT attribute is typically used if the field stores data in floating point representation. For detailed information about the handling of data for fields defined with the FLOAT attribute, see the File management description of the [[Field design (File management)#FLOAT attribute|FLOAT attribute]].</p> | ===FLOAT attribute=== | ||
<p> | |||
The FLOAT attribute is typically used if the field stores data in floating point representation. For detailed information about the handling of data for fields defined with the FLOAT attribute, see the File management description of the [[Field design (File management)#FLOAT attribute|FLOAT attribute]].</p> | |||
<p>The FOR EACH VALUE attribute maintains a list of all the unique values created for a field. This list can be accessed by using a value loop statement, such as, FOR EACH VALUE, FOR k VALUES, or FIND ALL VALUES. </p> | |||
===FOR EACH VALUE attribute=== | |||
<p>The INVISIBLE attribute is required if the field is to be used in FILE RECORDS statements. It also can be used for other fields that have the KEY, NUMERIC RANGE, or ORDERED attribute. Such fields can be used for retrievals but cannot be used where the VISIBLE attribute is required.</p> | <p> | ||
<p>An INVISIBLE field cannot be used in an arithmetic expression, as a key in a SORT statement, or in the AUDIT, COUNT OCCURRENCES, DELETE EACH, NOTE, PRINT, SET HEADER, and SET TRAILER statements. An INVISIBLE field also cannot be used in any form of the CHANGE or DELETE statement that is not followed by a fieldname = value pair.</p> | The FOR EACH VALUE attribute maintains a list of all the unique values created for a field. This list can be accessed by using a value loop statement, such as, FOR EACH VALUE, FOR k VALUES, or FIND ALL VALUES. </p> | ||
<p>See [[Field design (File management)#VISIBLE and INVISIBLE attributes|VISIBLE and INVISIBLE attributes]] for details on the use of INVISIBLE fields in 1NF (First-Normal Form) files. </p> | |||
===INVISIBLE attribute=== | |||
<p> | |||
<p>The KEY attribute specifies that if the field is to be used in FIND statement conditions of the form: </p> | The INVISIBLE attribute is required if the field is to be used in FILE RECORDS statements. It also can be used for other fields that have the KEY, NUMERIC RANGE, or ORDERED attribute. Such fields can be used for retrievals but cannot be used where the VISIBLE attribute is required.</p> | ||
<p class=" | <p> | ||
An INVISIBLE field cannot be used in an arithmetic expression, as a key in a SORT statement, or in the AUDIT, COUNT OCCURRENCES, DELETE EACH, NOTE, PRINT, SET HEADER, and SET TRAILER statements. An INVISIBLE field also cannot be used in any form of the CHANGE or DELETE statement that is not followed by a fieldname = value pair.</p> | |||
<p> | |||
See [[Field design (File management)#VISIBLE and INVISIBLE attributes|VISIBLE and INVISIBLE attributes]] for details on the use of INVISIBLE fields in 1NF (First-Normal Form) files. </p> | |||
===KEY attribute=== | |||
<p> | |||
The KEY attribute specifies that if the field is to be used in FIND statement conditions of the form: </p> | |||
<p class="syntax"><span class="term">fieldname</span> = <span class="term">value</span> | |||
</p> | </p> | ||
<p>the Table C index is searched, rather than the data in Table B. Thus, the selection of records based on KEY fields is substantially more efficient than selection based on NON-KEY fields.</p> | <p> | ||
<p>In addition, either the KEY attribute or the ORDERED attribute is required if the field is to be used in FILE RECORDS statements. </p> | the Table C index is searched, rather than the data in Table B. Thus, the selection of records based on KEY fields is substantially more efficient than selection based on NON-KEY fields.</p> | ||
<p> | |||
<p>The LENGTH attribute specifies the preallocated length of a field occurrence in a record. See the discussion on preallocated fields in [[Data maintenance#Storing values in preallocated fields|Storing values in preallocated fields]]. </p> | In addition, either the KEY attribute or the ORDERED attribute is required if the field is to be used in FILE RECORDS statements. </p> | ||
<p>The NON-DEFERRABLE attribute causes a KEY, NUMERIC RANGE, or ORDERED retrieval field's index entries to be created immediately when the file is open in deferred update mode. All index entries are created immediately when a file is not in deferred update mode. The field cannot be located until its index entry has been created. | ===LENGTH attribute=== | ||
<p> | |||
The LENGTH attribute specifies the preallocated length of a field occurrence in a record. See the discussion on preallocated fields in [[Data maintenance#Storing values in preallocated fields|Storing values in preallocated fields]]. </p> | |||
<p>The NUMERIC RANGE attribute specifies that if the field is used in a retrieval statement that performs a numeric retrieval, the Table C index is searched, rather than the data in Table B. Numeric retrievals based on fields with the NUMERIC RANGE attribute are more efficient than numeric retrievals based on NON-RANGE fields. A NUMERIC RANGE field cannot be multiply occurring. | |||
===NON-DEFERRABLE attribute=== | |||
<p> | |||
<p>The OCCURS attribute specifies the number of occurrences of a multiply occurring field that are preallocated in a record. See the discussion on preallocated fields in [[Data maintenance#Storing values in preallocated fields|Storing values in preallocated fields]]. </p> | The NON-DEFERRABLE attribute causes a KEY, NUMERIC RANGE, or ORDERED retrieval field's index entries to be created immediately when the file is open in deferred update mode. All index entries are created immediately when a file is not in deferred update mode. The field cannot be located until its index entry has been created. </p> | ||
===NUMERIC RANGE attribute=== | |||
<p>The ORDERED attribute specifies that the Ordered Index can be searched rather than the data in Table B for most types of retrieval. Thus, the selection of records based on ORDERED fields is substantially more efficient than selection based on NON-ORDERED fields.</p> | <p> | ||
<p>A field with the ORDERED attribute also produces other efficiencies in User Language. For example, when the IN ORDER option is used on a FOR EACH RECORD statement, an internal sort is not required if the field is ORDERED.</p> | The NUMERIC RANGE attribute specifies that if the field is used in a retrieval statement that performs a numeric retrieval, the Table C index is searched, rather than the data in Table B. Numeric retrievals based on fields with the NUMERIC RANGE attribute are more efficient than numeric retrievals based on NON-RANGE fields. A NUMERIC RANGE field cannot be multiply occurring. </p> | ||
<p>The ORDERED attribute also allows a field to be used with any value loop statement, such as, FIND ALL VALUES, FOR EACH VALUE, and FOR k VALUES. In addition, either the ORDERED attribute or the KEY attribute is required if a field is to be used in FILE RECORDS statements.</p> | |||
===OCCURS attribute=== | |||
<p>The UNIQUE attribute automatically enforces a uniqueness constraint on fields; it ensures that a given field name = value pair occurs only in one record in a file. </p> | <p> | ||
The OCCURS attribute specifies the number of occurrences of a multiply occurring field that are preallocated in a record. See the discussion on preallocated fields in [[Data maintenance#Storing values in preallocated fields|Storing values in preallocated fields]]. </p> | |||
<p>The VISIBLE attribute is required if the field is to be used in NOTE, PRINT, or SORT statements, or in an arithmetic expression. | |||
===ORDERED attribute=== | |||
<p> | |||
<p>The UPDATE attribute indicates the type of update method that is used when a field is changed. </p> | The ORDERED attribute specifies that the Ordered Index can be searched rather than the data in Table B for most types of retrieval. Thus, the selection of records based on ORDERED fields is substantially more efficient than selection based on NON-ORDERED fields.</p> | ||
<p> | |||
A field with the ORDERED attribute also produces other efficiencies in User Language. For example, when the IN ORDER option is used on a FOR EACH RECORD statement, an internal sort is not required if the field is ORDERED.</p> | |||
<p> | |||
The ORDERED attribute also allows a field to be used with any value loop statement, such as, FIND ALL VALUES, FOR EACH VALUE, and FOR k VALUES. In addition, either the ORDERED attribute or the KEY attribute is required if a field is to be used in FILE RECORDS statements.</p> | |||
===UNIQUE attribute=== | |||
<p> | |||
The UNIQUE attribute automatically enforces a uniqueness constraint on fields; it ensures that a given field name = value pair occurs only in one record in a file. </p> | |||
===VISIBLE attribute=== | |||
<p> | |||
The VISIBLE attribute is required if the field is to be used in NOTE, PRINT, or SORT statements, or in an arithmetic expression. </p> | |||
===UPDATE attribute=== | |||
<p> | |||
The UPDATE attribute indicates the type of update method that is used when a field is changed. </p> | |||
<ul> | <ul> | ||
<li>If UPDATE IN PLACE is specified, changing the value of a field occurrence does not change its position relative to other occurrences of the same field. The file manager usually specifies UPDATE IN PLACE.</li> | <li>If UPDATE IN PLACE is specified, changing the value of a field occurrence does not change its position relative to other occurrences of the same field. The file manager usually specifies UPDATE IN PLACE.</li> | ||
<li>If UPDATE AT END is specified, a change in the value of a field occurrence is accomplished by deleting the existing occurrence and adding a new one following the others. | |||
<li>If UPDATE AT END is specified, a change in the value of a field occurrence is accomplished by deleting the existing occurrence and adding a new one following the others. | |||
</li> | </li> | ||
</ul> | </ul> | ||
<p>Refer to [[Operations on multiply occurring fields#UPDATE field attribute|UPDATE field attribute]] for detailed information on the handling of updates based on the type of update method specified. | <p> | ||
Refer to [[Operations on multiply occurring fields#UPDATE field attribute|UPDATE field attribute]] for detailed information on the handling of updates based on the type of update method specified. </p> | |||
[[Category:SOUL]] | [[Category:SOUL]] |
Revision as of 17:35, 17 January 2014
File model feature
The file manager defines fields and assigns attributes to each field, as described in Defining fields manually. The field attributes listed on this page are of interest to the application developer.
You can enforce file-wide constraints on files and fields with two Model 204 file models:
File model | Action... |
---|---|
Numeric Validation | Causes Model 204 to perform numeric data type validation on fields defined as FLOAT or BINARY. |
1NF (First-Normal Form) | Ensures that the data within a file conforms to the rules for First-Normal Form. |
Use the FILEMODL parameter to set a file model when creating a file.
Field attribute descriptions
AT-MOST-ONE and REPEATABLE attributes
If a field is defined as having the AT-MOST-ONE attribute, Model 204 prevents multiple occurrences of that field in any given record. However, unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated.
If a field is not defined as AT-MOST-ONE, then it is REPEATABLE.
REPEATABLE is the default except for First-Normal Form files, where AT-MOST-ONE is required on all fields.
AT-MOST-ONE versus UNIQUE attributes
Although the names of the UNIQUE and AT-MOST-ONE attributes sound similar, they have very different meanings:
- UNIQUE affects the value of the field
- AT-MOST-ONE affects the number of field occurrences per record
For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE; the UNIQUE attribute ensures that the social security number for every employee is different, and AT-MOST-ONE ensures that each employee has only one social security number.
Both AT-MOST-ONE and UNIQUE are examples of "field level constraints."
BINARY-LARGE-OBJECT and CHARACTER-LARGE-OBJECT attributes
If a field is defined with the BINARY-LARGE-OBJECT or CHARACTER-LARGE-OBJECT attribute, only the OCCURS attribute can also be assigned to the field.
Handling NULL support for Large Object data
NULL support for Large object data is handled like the NULL support for string data. If you change Large Object data to null using:
- Single quotation marks (' '), Table B stores the null and Table E deletes the former value.
- A trailing an equal sign (= ), the former value is deleted from both Table B and Table E.
- A source that is zero (0), the former value is deleted from both Table B and Table E.
FLOAT attribute
The FLOAT attribute is typically used if the field stores data in floating point representation. For detailed information about the handling of data for fields defined with the FLOAT attribute, see the File management description of the FLOAT attribute.
FOR EACH VALUE attribute
The FOR EACH VALUE attribute maintains a list of all the unique values created for a field. This list can be accessed by using a value loop statement, such as, FOR EACH VALUE, FOR k VALUES, or FIND ALL VALUES.
INVISIBLE attribute
The INVISIBLE attribute is required if the field is to be used in FILE RECORDS statements. It also can be used for other fields that have the KEY, NUMERIC RANGE, or ORDERED attribute. Such fields can be used for retrievals but cannot be used where the VISIBLE attribute is required.
An INVISIBLE field cannot be used in an arithmetic expression, as a key in a SORT statement, or in the AUDIT, COUNT OCCURRENCES, DELETE EACH, NOTE, PRINT, SET HEADER, and SET TRAILER statements. An INVISIBLE field also cannot be used in any form of the CHANGE or DELETE statement that is not followed by a fieldname = value pair.
See VISIBLE and INVISIBLE attributes for details on the use of INVISIBLE fields in 1NF (First-Normal Form) files.
KEY attribute
The KEY attribute specifies that if the field is to be used in FIND statement conditions of the form:
fieldname = value
the Table C index is searched, rather than the data in Table B. Thus, the selection of records based on KEY fields is substantially more efficient than selection based on NON-KEY fields.
In addition, either the KEY attribute or the ORDERED attribute is required if the field is to be used in FILE RECORDS statements.
LENGTH attribute
The LENGTH attribute specifies the preallocated length of a field occurrence in a record. See the discussion on preallocated fields in Storing values in preallocated fields.
NON-DEFERRABLE attribute
The NON-DEFERRABLE attribute causes a KEY, NUMERIC RANGE, or ORDERED retrieval field's index entries to be created immediately when the file is open in deferred update mode. All index entries are created immediately when a file is not in deferred update mode. The field cannot be located until its index entry has been created.
NUMERIC RANGE attribute
The NUMERIC RANGE attribute specifies that if the field is used in a retrieval statement that performs a numeric retrieval, the Table C index is searched, rather than the data in Table B. Numeric retrievals based on fields with the NUMERIC RANGE attribute are more efficient than numeric retrievals based on NON-RANGE fields. A NUMERIC RANGE field cannot be multiply occurring.
OCCURS attribute
The OCCURS attribute specifies the number of occurrences of a multiply occurring field that are preallocated in a record. See the discussion on preallocated fields in Storing values in preallocated fields.
ORDERED attribute
The ORDERED attribute specifies that the Ordered Index can be searched rather than the data in Table B for most types of retrieval. Thus, the selection of records based on ORDERED fields is substantially more efficient than selection based on NON-ORDERED fields.
A field with the ORDERED attribute also produces other efficiencies in User Language. For example, when the IN ORDER option is used on a FOR EACH RECORD statement, an internal sort is not required if the field is ORDERED.
The ORDERED attribute also allows a field to be used with any value loop statement, such as, FIND ALL VALUES, FOR EACH VALUE, and FOR k VALUES. In addition, either the ORDERED attribute or the KEY attribute is required if a field is to be used in FILE RECORDS statements.
UNIQUE attribute
The UNIQUE attribute automatically enforces a uniqueness constraint on fields; it ensures that a given field name = value pair occurs only in one record in a file.
VISIBLE attribute
The VISIBLE attribute is required if the field is to be used in NOTE, PRINT, or SORT statements, or in an arithmetic expression.
UPDATE attribute
The UPDATE attribute indicates the type of update method that is used when a field is changed.
- If UPDATE IN PLACE is specified, changing the value of a field occurrence does not change its position relative to other occurrences of the same field. The file manager usually specifies UPDATE IN PLACE.
- If UPDATE AT END is specified, a change in the value of a field occurrence is accomplished by deleting the existing occurrence and adding a new one following the others.
Refer to UPDATE field attribute for detailed information on the handling of updates based on the type of update method specified.