17.06.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

How It Works<br />

Once you have successfully run the preceding code, run sp_help, and you should see your new constraint<br />

reported under the constraints section of the sp_help information. If you want to get even more to the<br />

point, you can run sp_helpconstraint. The syntax is easy:<br />

EXEC sp_helpconstraint <br />

Run sp_helpconstraint on our new Orders table, and you’ll get information back giving you the<br />

names, criteria, and status for all the constraints on the table. At this point, our Orders table has one<br />

FOREIGN KEY constraint and one PRIMARY KEY constraint.<br />

Our new foreign key has been referenced in the physical definition of our table, and is now an integral<br />

part of our table. As we discussed in Chapter 1, the database is in charge of its own integrity. Our foreign<br />

key enforces one constraint on our data and makes sure our database integrity remains intact.<br />

Unlike primary keys, foreign keys are not limited to just one per table. We can have between 0 and 253<br />

foreign keys in each table. The only limitation is that a given column can reference only one foreign key.<br />

However, you can have more than one column participate in a single foreign key. A given column that is<br />

the target of a reference by a foreign key can also be referenced by many tables.<br />

Adding a Foreign Key to an Existing Table<br />

Just like with primary keys, or any constraint for that matter, there are situations where we want to add<br />

our foreign key to a table that already exists. This process is similar to creating a primary key.<br />

Try It Out Adding a Foreign Key to an Existing Table<br />

Let’s add another foreign key to our Orders table to restrict the EmployeeID field (which is intended to<br />

have the ID of the employee who entered the order) to valid employees as defined in the Employees<br />

table. To do this, we need to be able to uniquely identify a target record in the referenced table. As I’ve<br />

already mentioned, you can do this by referencing either a primary key or a column with a UNIQUE constraint.<br />

In this case, we’ll make use of the existing primary key that we placed on the Employees table<br />

earlier in the chapter:<br />

ALTER TABLE Orders<br />

ADD CONSTRAINT FK_EmployeeCreatesOrder<br />

FOREIGN KEY (EmployeeID) REFERENCES Employees(EmployeeID);<br />

Chapter 6: Constraints<br />

When you run sp_helpconstraint on this table, the word “clustered” will appear<br />

right after the reporting of the PRIMARY KEY. This just means it has a clustered index.<br />

We will explore the meaning of this further in Chapter 9.<br />

Now execute sp_helpconstraint again against the Orders table, and you’ll see that our new constraint<br />

has been added.<br />

161

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!