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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
❑ Fifth Normal Form: This deals with non-loss and loss decompositions. Essentially, there are certain
situations where you can decompose a relationship such that you cannot logically recompose
it into its original form. Again, these are rare, largely academic, and we won’t deal with
them any further here.
This is, of course, just a really quick look at these — and that’s deliberate on my part. The main reason
you need to know these in the real world is either to impress your friends (or prove to them you’re a
“know it all”) and to not sound like an idiot when some database guru comes to town and starts talking
about them. However you choose to use it, I do recommend against attempting to use it to get dates . . . .
Relationships
Well, I’ve always heard from women that men immediately leave the room if you even mention the
word “relationship.” With that in mind, I hope that I didn’t just lose about half my readers.
I am, of course, kidding — but not by as much as you might think. Experts say the key to successful
relationships is that you know the role of both parties and that everyone understands the boundaries
and rules of the relationship that they are in. I can be talking about database relationships with that
statement every bit as much as people relationships.
There are three different kinds of major relationships:
❑ One-to-one
❑ One-to-many
❑ Many-to-many
Each of these has some variations depending on whether one side of the relationship is nullable or not.
For example, instead of a one-to-one relationship, you might have a zero or one-to-one relationship.
One-to-One
This is exactly what it says it is. A one-to-one relationship is one where the fact that you have a record in
one table means that you have exactly one matching record in another table.
To illustrate a one-to-one relationship, let’s look at a slight variation of a piece of our earlier example.
Imagine that you have customers — just as we did in our earlier example. This time, however, we’re going
to imagine that we are a subsidiary of a much larger company. Our parent company wants to be able
to track all of its customers, and to be able to tell the collective total of each customer’s purchases —
regardless of which subsidiary(s) the customer made purchases with.
Even if all the subsidiaries run out of one server at the main headquarters, there’s a very good chance
that the various subsidiaries would be running with their own databases. One way to track all customer
information, which would facilitate combining it later, would be to create a master customer database
owned by the parent company. The subsidiaries would then maintain their own customer table, but do
so with a one-to-one relationship to the parent company’s customer table. Any customer record created
in the parent company would imply that you needed to have one in the subsidiaries also. Any creation
of a customer record in a subsidiary would require that one also be created in the parent company’s copy.
227