Column-level constraints define more elaborate integrity rules for columns than those defined by simple domain constraints. For example, a column constraint on a column typed as INTEGER may further specify that only values between 0 and 49999 or between 99995 and 99999 are permitted for that column.
A column constraint specifies a simple predicate that applies to one column only. For example, a business rule states that employee numbers in the employee table must be between 10001 and 32001 inclusive. You can specify this rule in the CREATE TABLE statement used to define the emp_no column in the employee table as follows:
CONSTRAINT emp_no CHECK (emp_no >= 10001 AND emp_no <= 32001)
The only column referenced by this constraint is the employee number column, emp_no.
The column constraints for your databases are developed from the ATM Constraints form.
You cannot declare column-level CHECK constraints on any column defined with the XML, JSON, BLOB, CLOB, ARRAY/VARRAY, Period, or Geospatial data types.
You can declare CHECK and UNIQUE constraints on row-level security constraint columns. When defined for a column, these constraints apply to all rows in the table, not only to user-visible rows.
You cannot declare database constraints other than NULL or NOT NULL for global temporary trace tables (see CREATE GLOBAL TEMPORARY TRACE TABLE ).
You can also define column-level and object-level access constraints, or security privileges, on tables (for more information, see Teradata Row Level Security Privileges ).