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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
This kind of relationship usually sets up what is called a domain relationship. A
domain is a limited list of values that the dependent table must choose from —
nothing outside the domain list is considered a valid option. The table that holds the
rows that make up the domain list is commonly referred to as a domain or lookup
table. Nearly all databases you create are going to have at least one, and probably
many, domain tables in them. Our Shippers table is a domain table — the purpose
of having it isn’t just to store the information on the name and phone number of the
shipper, but also to limit the list of possible shippers in the Orders table.
In SQL Server, we can enforce this kind of relationship through two methods:
❑ FOREIGN KEY constraint: You simply declare a FOREIGN KEY constraint on the table that serves
as the “many” side of the relationship, and reference the table and column that is to be the “one”
side of the relationship (you’ll be guaranteed only one in the referenced table since you must
have a PRIMARY KEY or UNIQUE constraint on the column(s) referenced by a foreign key).
❑ Triggers: Actually, for all the early versions of SQL Server, this was the only option for true referential
integrity. You actually need to add two triggers — one for each side of the relationship.
Add a trigger to the table that is the “many” side of the relationship and check that any row
inserted or changed in that table has a match in the table it depends on (the “one” side of the
relationship). Then, you add a delete trigger and an update trigger to the other table — this trigger
checks records that are being deleted (or changed) from the referenced table to make sure that it
isn’t going to orphan (make it so it doesn’t have a reference).
We’ve previously discussed the performance ramifications of the choices between the two in Chapter 6.
Using a FOREIGN KEY constraint is generally faster — particularly when there is a violation. That being
said, triggers may still be the better option in situations where you’re going to have a trigger executing
anyway (or some other special constraint need).
Many-to-Many
In this type of relationship, both sides of the relationship may have several records — not just one — that
match. An example of this would be the relationship of products to orders. A given order may have many
different products in the order. Likewise, any given product may be ordered many times. We still may,
however, want to relate the tables in question — for example, to ensure that an order is for a product
that we know about (it’s in our Products table).
SQL Server has no way of physically establishing a direct many-to-many relationship, so we cheat by
having an intermediate table to organize the relationship. Some tables create our many-to-many relationships
almost by accident as a normal part of the normalization process — others are created entirely from
scratch for the sole purpose of establishing this kind of relationship. This latter “middleman” kind of
table is often called either a linking table, an associate table, or sometimes a merge table.
First, let’s look at a many-to-many relationship that is created in the normal course of normalization. An
example of this can be found in the Accounting database’s OrderDetails table (we created the Accounting
database in Chapters 5 and 6), which creates a many-to-many relationship between our Orders and
Products tables, shown in Figure 8-5.
231