You are on page 1of 3

Constraints

Constraints:
A constraint is a restriction or limitation placed on a file to ensure that data in your database remains
consistent as you add, change, and remove records.
 Unique constraints and primary key constraints let you create enforced unique keys for a
physical file beyond the file access path
 Check constraints provide another check for the validity of your data by testing the data in and
expression.

Setting up constraints for your database :

You can use physical file constraints to control the integrity of data that is maintained in your database.

To add a physical file constraint, use the Add Physical File Constraint (ADDPFCST) command.
To add a unique constraint, specify a value of *UNQCST on the Type parameter. You must also specify
one or more field names for the Key parameter.
To add a primary key constraint, specify a value of *PRIKEY on the Type parameter. The key that you
specify on the command becomes the primary access path of the file. If the file does not have a keyed
access path that can be shared, the system creates one. You must also specify one or more field
names for the Key parameter.
To add a check constraint, specify a value of *CHKCST on the Type parameter. You must also specify a

check constraint expression on the CHKCST parameter. The check constraint expression has the same
syntax as the expression used for check-conditions that are defined using Structured Query Language
(SQL).

Details: Setting up constraints

The following rules apply to all physical file constraints:


The file must be a physical file.
A file can have a maximum of one member, MAXMBR(1).
A constraint can be defined when the file has zero members. A constraint cannot be established,
however, until the file has one, and only one, member.
A file can have a maximum of one primary key constraint, but may have many unique constraints.
There is a maximum of 300 constraint relations per file. This maximum value is the sum of the
following:
- The unique constraints
- The primary key constraint
- The check constraints
- The referential constraints, whether they are participating as a parent or a dependent, and whether
the constraints are defined or established.
Constraint names must be unique in a library.
Constraints cannot be added to files in the QTEMP library.
Referential constraints must have the parent and dependent file in the same auxiliary storage pool
(ASP).

Removing unique, primary key, or check constraints

To remove a physical file constraint, use the Remove Physical File Constraint (RMVPFCST) command.
The full effects of the command depend on the type of constraint you remove and how it is used.
To remove a unique constraint, specify a value of *UNQCST on the Type parameter.
To remove a primary key constraint, specify a value of *PRIKEY on the Type parameter.
To remove a check constraint, specify a value of *CHKCST on the Type parameter.

BAS
Constraints

You can specify any of the values below on the Constraint (CST) parameter for each of the constraint
types listed:
- CST(*ALL) to remove all of the constraints you specify on the Type parameter.
CST(constraint-name) to remove a specific constraint.
- CST(*CHKPND) to remove only those constraints that are in check pending status. Use
CST(*ALL) with TYPE(*ALL) to remove all constraints from the file.

Working with a group of constraints

To display a list of the constraints that exist for a particular file, use the Work with Physical File
Constraints (WRKPFCST) command. From this display, you can change or remove a constraint and
display a list of the records that placed a file constraint into check pending status.

The Work with Physical File Constraints display shows all the constraints defined for the file specified on
the WRKPFCST command. The display lists the constraint names, the file name, and the library name.
In addition, the following information is displayed:
 The Type column identifies the constraint as referential, check, unique, or primary key.
 The State column indicates whether the constraint is defined or established and whether it is
enabled or disabled. The State column only applies to referential and check constraints.
 The Check Pending column contains the check pending status of the constraint. Unique and
primary key constraints do not have a state because they are always established and enabled.

For each of the listed constraints, you can perform the following actions:
 To change a referential or check constraint to any of its permissible states, select Change
(option 2). For example, you can enable a constraint that is currently disabled. This option
performs the same functions as the CHGPFCST command.
 To remove a constraint, select Remove (option 4). This option performs the same functions as
the RMVPFCST command.
 To display the records that are in check pending state, select Display (option 6). This option
performs the same functions as the DSPCPCST command. The DSPCPCST command applies
only to referential and check constraints.

Unique constraints:
 Unique constraints act as controls in a database to ensure that rows are unique. For example,
you can specify a customer identification number as a unique constraint in your database. If

BAS
Constraints

anyone attempts to create a new customer with the same customer number, an error message
is sent to the database administrator.
 Unique constraints identify a field or set of fields in a database file whose values must be
unique across records in the file. The field must be in ascending order, and can be null-
capable.
 A file can have multiple unique constraints, but you cannot duplicate unique constraints. The
same key fields, regardless of order, constitute a duplicate constraint
 Unique constraints can be used as the parent key when adding a referential constraint.

Primary key constraints


 A primary key constraint is a unique key with special attributes that make the key the primary
access path for the file.
 Primary key constraints identify a field or set of fields in a database file whose values must be
unique across records in the file. The field must be in ascending order, and can be null-
capable. If it is null-capable, a check constraint is implicitly added so that null values cannot be
entered in the field. You can define only one primary key constraint for a file.

 A primary key constraint can be used as the parent key when adding a referential constraint.

Check constraints
 You use check constraints to maintain limits on the values of fields so that they conform to
your database requirements.
 Check constraints assure the validity of data during insertions and updates by checking the
data against a check constraint expression that you define.

 For example, you can create a check constraint on a field such that values that are inserted
into that field must be between 1 and 100. If a value does not fall within that range, the insert
or update operation against your database is not processed.

 Check constraints are much like referential constraints in terms of their states:
 Defined and enabled — the constraint definition has been added to the file, and the constraint
will be enforced after the constraint is established.
 Defined and disabled — the constraint definition has been added to the file, but the constraint
will not be enforced.
 Established and enabled — the constraint has been added to the file and all of the pieces of the
file are there for enforcement.
 Established and disabled — the constraint has been added to the file and all of the pieces of
the file are there for enforcement, but the constraint will not be enforced.
 A check constraint, like a referential constraint, can have a check pending status. If the data in
any field violates the check constraint expression, then the constraint is in check pending. For
the insertion or update of a record, if the data violates the check constraint expression, then
the insert or update will not be allowed.
 A check constraint that contains one or more Large Object (LOB) fields is restricted to a
narrower range of operations than a check constraint without LOB fields. When the check
constraint includes one or more LOB fields, the LOB fields can only be involved in direct
comparisons to:
 Other LOB fields of the same type and same maximum length.
 Literal values.
 The null value.

 Operations known as derived operations, such as the Substring or Concat operations, are not
allowed against LOB fields in a check constraint. The diagnostic message CPD32E6 will be sent
when trying to add a check constraint that attempts a derived operation against a LOB field.

BAS

You might also like