Essentially, creating the Category table is pretty much the same as the Department table you’ve already created, so we’ll move pretty quickly. What makes this exercise special is that you’ll learn how to implement and enforce the One-to-Many relationship between the Category and Department tables.
8213592a117456a340854d18cee57603
1. Using the Database Explorer (Ctrl+Alt+S), open the data connection to the BalloonShop database.
When the database is selected, choose Data ➤ Add New ➤ Table. Alternatively, you can right-click the Tables node under BalloonShop and select Add New Table.
2. Add the columns shown in Table 4-1 using the form that appears.
■ Tip A quick reminder from the previous chapter: you set a column to be the primary key by right-clicking on it and clicking the Set Primary Key item from the context menu. You set it to be an identity column by expanding the Identity Specification item from its Column Properties window, and setting the (Is Identity) node to Yes. At this moment the form should look like Figure 4-5.
Figure 4-5. Creating the Category table
3. Press Ctrl+S to save the table. When asked, type Category for the table’s name.
Table 4-1. Designing the Category Table
Field Name Data Type Other Properties
CategoryID int Primary Key and Identity column
DepartmentID int Don’t allow NULLs
Name varchar(50) Don’t allow NULLs
Description varchar(1000) Allow NULLs
4. While the Category table is still selected, click Table Designer ➤ Relationships. Here is where you specify the details for the foreign key. This works by relating a column of the referencing table (Category) to a column of the referenced table (Department). You need to relate the DepartmentID column in Category with the DepartmentID column of the Department table.
5. In the dialog box that appears, click Add.
6. Select the Tables and Columns Specifications entry and click the “...” button that appears. In the dialog box that opens (see Figure 4-6), choose Department for the Primary key table and DepartmentID for the column on both tables.
Figure 4-6. Creating a new foreign key
7. Click OK and then Close to save the relationship.
■Tip If anything goes wrong, delete the relationship, and then create it again.
8. Press Ctrl+S to save the table again. You’ll be warned about the Category and Department tables being updated and asked for confirmation. This confirms again that a foreign-key relationship affects both tables that take part in the relationship. Click Yes.
How It Works: The One-to-Many Relationship
Okay, so you created and then enforced a relationship between the Category and Department tables. But how does it work, and how does it affect your work and life? Let’s study how you implemented this relationship.
In the Category table, apart from the primary key and the usual CategoryID, Name and Description columns, you added a DepartmentID column. This column stores the ID of the department the category belongs to. Because the DepartmentID field in Category doesn’t allow NULLs, you must supply a department for each category.
Furthermore, because of the foreign-key relationship, the database won’t allow you to specify a nonexistent department.
Actually, you can ask the database not to enforce the relationship. In the Foreign Key Relationships dialog box where you created the relationship, you can set a number of options for your foreign key. We left them with the default value, but let’s see what they do:
• Check existing data on creation: If you set this to Yes, it doesn’t allow the creation of the relationship if the existing database records don’t comply with it. In other words, the relationship can’t be created if orphaned categories are in the database (you have categories with a DepartmentID that references a nonexistent department).
• Enforce For Replication: This option applies to database replication, which is beyond the scope of this book. Replication is a technology that allows the synchronization of data between multiple SQL Servers situated at different locations.
• Enforce Foreign Key Constraint: This is probably the most important of the options. It tells SQL Server to make sure that database operations on the tables involved in the relationship don’t break the relationship.
When this option is selected, by default SQL Server won’t allow you to add categories to nonexistent departments or delete departments that have related categories.
• INSERT and UPDATE specification: These options allow you to fine-tune the way SQL Server behaves when you delete or update data that would break data integrity. For example, if you set the Update Rule to Cascade, changing the ID of an existing department would cause the change to propagate to the Category table to keep the category-department associations intact. This way, even after you change the ID of the department, its categories would still belong to it (you can leave this option set to No Action because you won’t need to change departments IDs.) Setting the Delete Rule to Cascade is a radical solution for keeping data integrity. If this is selected and you delete a department from the database, SQL Server automatically deletes all the department’s related categories. This is a sensitive option and you should be very careful with it. You won’t use it in the BalloonShop project.
In the One-to-Many relationship (and implicitly the FOREIGN KEY constraint), you link two columns from two different tables. One of these columns is a primary key, and it defines the One part of the relationship. In our case, DepartmentID is the primary key of Department, so Department is the one that connects to many categories.
A primary key must be on the One part to ensure that it’s unique—a category can’t be linked to a department if you can’t be sure that the department ID is unique. You must ensure that no two departments have the same ID; other- wise, the relationship wouldn’t make much sense.
Now that you’ve created the Category table, you can populate it with some data. We’ll also try to add data that would break the relationship that you established between the Department and Category tables.