Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 6: Constraints
FOREIGN KEY Constraints
Foreign keys are both a method of ensuring data integrity and a manifestation of the relationships between
tables. When you add a foreign key to a table, you are creating a dependency between the table for which
you define the foreign key (the referencing table) and the table your foreign key references (the referenced
table). After adding a foreign key, any record you insert into the referencing table must either have a
matching record in the referenced column(s) of the referenced table, or the value of the foreign key column(s)
must be set to NULL. This can be a little confusing, so let’s do it by example.
When I say that a value must be “set to NULL,” I’m referring to how the actual INSERT statement
looks. As we’ll learn in a moment, the data may actually look slightly different once it gets in the table,
depending on what options you’ve set in your FOREIGN KEY declaration.
Let’s create another table in our Accounting database called Orders. One thing you’ll notice in this CRE-
ATE script is that we’re going to use both a primary key and a foreign key. A primary key, as we will see
as we continue through the design, is a critical part of a table. Our foreign key is added to the script in
almost exactly the same way as our primary key was, except that we must say what we are referencing.
The syntax goes on the column or columns that we are placing our FOREIGN KEY constraint on, and
looks something like this:
FOREIGN KEY REFERENCES ()
[ON DELETE {CASCADE|NO ACTION|SET NULL|SET DEFAULT}]
[ON UPDATE {CASCADE|NO ACTION|SET NULL|SET DEFAULT}]
Try It Out Creating a Table with a Foreign Key
160
For the moment, we’re going to ignore the ON clause. That leaves us, for our Orders table, with a script
that looks something like this:
USE Accounting
CREATE TABLE Orders
(
OrderID int IDENTITY NOT NULL
PRIMARY KEY,
CustomerNo int NOT NULL
FOREIGN KEY REFERENCES Customers(CustomerNo),
OrderDate date NOT NULL,
EmployeeID int NOT NULL
);
Note that the actual column being referenced must have either a PRIMARY KEY or a UNIQUE constraint
defined on it (we’ll discuss UNIQUE constraints later in the chapter).
It’s also worth noting that primary and foreign keys can exist on the same column. You can see an
example of this in the AdventureWorks2008 database with the SalesOrderDetail table. The primary
key is composed of both the SalesOrderID and SalesOrderDetailID columns — the former is
also the foreign key and references the SalesOrderHeader table. We’ll actually create a table later in
the chapter that has a column that is both a primary key and a foreign key.