Week10 - Constraints
Week10 - Constraints
Constraints
Constraints enforce rules at the table level and it prevents the deletion of a table if there
are dependencies. The following constraint types are valid:
● NOT NULL
● UNIQUE
● PRIMARY KEY
● FOREIGN KEY
● CHECK
Defining Constraints
Constraints are usually created at the same time as the table. Constraints can be added
to a table after its creation and also temporarily disabled. Constraints can be defined at
one of two levels.
column,...
[CONSTRAINT constraint_name] constraint_type
(column, ...);
Constraint Types
Constraint Description
You can specify the name of the constraint when you specify the constraint:
Unique Constraint
A UNIQUE key integrity constraint requires that every value in a column or set of
columns (key) be unique—that is, no two rows of a table can have duplicate values in a
specified column or set of columns. The column (or set of columns) included in the
definition of the UNIQUE key constraint is called the unique key. If the UNIQUE
constraint comprises more than one column, that group of columns is called a
composite unique key.
UNIQUE constraints allow the input of nulls unless you also define NOT NULL
constraints for the same columns. In fact, any number of rows can include nulls for
columns without NOT NULL constraints because nulls are not considered equal to
anything. A null in a column (or in all columns of a composite UNIQUE key) always
satisfies a UNIQUE constraint.
Primary Key
A PRIMARY KEY constraint creates a primary key for the table. Only one primary key
can be created for each table. The PRIMARY KEY constraint is a column or set of
columns that uniquely identifies each row in a table. This constraint enforces
uniqueness of the column or column combination and ensures that no column that is
part of the primary key can contain a null value. PRIMARY KEY constraints can be
defined at the column level or table level. A composite PRIMARY KEY is created by
using the table-level definition. A table can have only one PRIMARY KEY constraint but
can have several UNIQUE constraints.
Foreign Key
The FOREIGN KEY, or referential integrity constraint, designates a column or
combination of columns as a foreign key and establishes a relationship between a
primary key or a unique key in the same table or a different table. In the example on the
slide, DEPARTMENT_ID has been defined as the foreign key in the EMPLOYEES table
(dependent or child table); it references the DEPARTMENT_ID column of the
DEPARTMENTS table (the referenced or parent table). A foreign key value must match
an existing value in the parent table or be NULL. Foreign keys are based on data values
and are purely logical, not physical, pointers.
FOREIGN KEY constraints can be defined at the column or table constraint level. A
composite foreign key must be created by using the table-level definition. The foreign
key can also be defined at the column level, provided the constraint is based on a single
column. The syntax differs in that the keywords FOREIGN KEY do not appear. For
example:
The foreign key is defined in the child table, and the table containing the referenced
column is the parent table. The foreign key is defined using a combination of the
following keywords:
● FOREIGN KEY is used to define the column in the child table at the table
constraint level.
● REFERENCES identifies the table and column in the parent table.
● ON DELETE CASCADE indicates that when the row in the parent table is
deleted, the dependent rows in the child table will also be deleted.
● ON DELETE SET NULL converts foreign key values to null when the parent
value is removed.
The default behavior is called the restrict rule, which disallows the update or deletion of
referenced data. Without the ON DELETE CASCADE or the ON DELETE SET NULL
options, the row in the parent table cannot be deleted if it is referenced in the child table.
Defined at either the table level or the column level:
Modifying Constraints
Use the ALTER TABLE statement to:
● Add or drop a constraint, but not modify its structure
● Add a NOT NULL constraint by using the MODIFY clause
Add a FOREIGN KEY constraint to the EMPLOYEES table indicating that a manager
must already exist as a valid employee in the EMPLOYEES table.
Table altered.
Dropping a Constraint
● Remove the manager constraint from the EMPLOYEES table.
● ALTER TABLE employees
● DROP CONSTRAINT emp_manager_fk;
● Remove the PRIMARY KEY constraint on the DEPARTMENTS table and drop
the associated FOREIGN KEY constraint on the
EMPLOYEES.DEPARTMENT_ID column.
-- PRACTICE --
1. Add a table-level PRIMARY KEY constraint to the EMP table on the ID column.
The constraint should be named at creation. Name the constraint
my_emp_id_pk. Hint: The constraint is enabled as soon as the ALTER TABLE
command executes successfully.
2. Create a PRIMARY KEY constraint to the DEPT table using the ID column. The
constraint should be named at creation. Name the constraint my_dept_id_pk.
Hint: The constraint is enabled as soon as the ALTER TABLE command
executes successfully.
3. Add a column DEPT_ID to the EMP table. Add a foreign key reference on the
EMP table that ensures that the employee is not assigned to a nonexistent
department. Name the constraint my_emp_dept_id_fk.
5. Modify the EMP table. Add a COMMISSION column of NUMBER data type,
precision 2, scale 2. Add a constraint to the commission column that ensures that
a commission value is greater than zero.