SQL Server 2008 R2 : Implementing Data Integrity (part 5) - Using Constraints - Managing Constraints

12/1/2012 4:53:32 PM

Managing Constraints

Managing constraints consists of gathering information about constraints, disabling and re-enabling constraints, and dropping constraints. These actions are discussed in the following sections.

Gathering Constraint Information

You can obtain information about constraints by using the visual tools, system stored procedures, and information_schema views. The visual tools (including the Object Explorer, Table Designer, and database diagrams) were introduced in the previous section. These tools offer a simple, user-friendly means for obtaining information related to constraints. These tools allow you to view a table’s constraints and display the relative information.

The sp_help and sp_helpconstraint system stored procedures are another good source of information about constraints. Like the visual tools, these procedures allow you to gather constraint information about a specific table. The sp_helpconstraint procedure provides the most concise information related to constraints. Figure 7 shows the sp_helpconstraint output for the Sales.Customer table. You need to make sure to enclose the table name in brackets, as shown here, when the schema name is included. The output from sp_helpconstraint includes all the constraints for the table, and it supplies a list of tables that have foreign key references to the table.

Figure 7. Executing sp_helpconstraint on the Customer table.

Catalog views offer a flexible alternative for returning information about constraints.These catalog views allow you to obtain constraint information for more than one table at a time. They are very flexible and allow you to customize the type of data you want to return simply by adjusting the selection criterion.

Listing 4 shows a sample SELECT statement for each of the catalog views related to constraints and the resulting output. The SELECT statements in this example have a WHERE clause in them that limits the results to the SalesTax table, but you can remove this clause to retrieve constraints for all the tables.

Listing 4. Using Catalog Views to Display Constraint Information

select LEFT(name,30) NAME, type from sys.key_constraints
    where object_name(parent_object_id) = 'SalesTaxRate'
    order by 1

select LEFT(name,30) NAME, type from sys.check_constraints
    where object_name(parent_object_id) = 'SalesTaxRate'
    order by 1

select LEFT(name,30) NAME, type from sys.default_constraints
    where object_name(parent_object_id) = 'SalesTaxRate'
    order by 1

/* Results of the previous SELECT statements
NAME                           type
------------------------------ ----
PK_SalesTaxRate_SalesTaxRateID PK

(1 row(s) affected)

NAME                           type
------------------------------ ----
CK_SalesTaxRate_TaxType        C

(1 row(s) affected)

NAME                           type
------------------------------ ----
DF_SalesTaxRate_ModifiedDate   D
DF_SalesTaxRate_rowguid        D
DF_SalesTaxRate_TaxRate        D
(3 row(s) affected)
*/

Dropping Constraints

You can drop constraints by using the visual tools or by using T-SQL. You can right-click a constraint in the Object Explorer and select the Delete option to drop that constraint. The Object Explorer also offers a script option that generates the T-SQL statements used to drop the constraint. The ALTER TABLE command is the T-SQL command you use to make the change. For example, to drop the CK_Employee_Gender constraint on the Employee table, you can use the following command:

ALTER TABLE [HumanResources].[Employee]
DROP CONSTRAINT [CK_Employee_Gender]

You should use caution when dropping constraints because some constraints affect other tables. For example, if you drop the PRIMARY KEY constraint on a table and that table is referenced by foreign keys, the drop statement fails.

Disabling Constraints

You can disable CHECK and FOREIGN KEY constraints by using the NOCHECK clause. This capability allows you to stop the constraints from being checked without removing the constraints from your database. The following ALTER TABLE command allows you to disable the FK_Customer_SalesTerritory_TerritoryID foreign key constraint on the Customer table:

ALTER TABLE Sales.Customer
    NOCHECK CONSTRAINT FK_Customer_SalesTerritory_TerritoryID

When the constraint is disabled, it no longer performs validation. You should disable constraints with caution because the integrity of your data can be compromised. In the previous example, disabling the FOREIGN KEY constraint would allow an invalid TerritoryID to be inserted in the Customer table.

Why would you disable constraints? One possible reason would be to disable the constraints during large data loads. The execution of constraints can slow the load process. To facilitate the fastest load speed, you can disable constraints and then re-enable them when the data load is complete. To re-enable a constraint, you use the CHECK keyword in the ALTER TABLE statement. The following example re-enables the FOREIGN KEY constraint for the Customer table:

ALTER TABLE Sales.Customer
    CHECK CONSTRAINT FK_Customer_SalesTerritory_TerritoryID

Keep in mind that enabling a constraint does not necessarily mean the underlying data is being validated against the constraint. In fact, the default behavior when enabling a constraint in SQL Server 2008 is not to check the data against the constraint when a constraint in enabled. The default behavior when a constraint is added is to validate the data. You can force the data in the table to be validated using the WITH CHECK option. The following WITH CHECK option could be used to force the validation of the underlying data when a constraint is enabled:

ALTER TABLE Sales.Customer
    WITH CHECK CHECK CONSTRAINT FK_Customer_SalesTerritory_TerritoryID

Others