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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 8: Being Normal: Normalization and Other Basic Design Issues<br />

❑ We were able to eliminate an instance of the information for ACME Co. That’s part of the purpose<br />

of moving data that appears in repetitive groups — to just store it once. This both saves us space<br />

and prevents conflicting values.<br />

❑ We moved only repeating groups of data. We still see the same order date several times, but it<br />

doesn’t really fit into a group — it’s just a relatively random piece of data that has no relevance<br />

outside of this table.<br />

So, we’ve dealt with our repeating data; next, we’re ready to move onto the second violation of first normal<br />

form — atomicity. If you take a look at the ItemsOrdered column, you’ll see that there are actually<br />

several different pieces of data there:<br />

❑ Anywhere from one to many individual part numbers<br />

❑ Quantity weight information on each of those parts<br />

Part number, weight, and price are each atomic pieces of data if kept to themselves, but combined into<br />

one lump grouping you no longer have atomicity.<br />

Believe it or not, things were sometimes really done this way. At first glance, it seemed the easy thing to<br />

do — paper invoices often had just one big block area for writing up what the customer wanted, and<br />

computer-based systems were often just as close to a clone of paper as someone could make it.<br />

We’ll go ahead and break things up — and, while we’re at it, we’ll add in a new piece of information in<br />

the form of a unit price, as shown in Figure 8-1. The problem is that, once we break up this information,<br />

our primary key no longer uniquely identifies our rows — our rows are still unique, but the primary key<br />

is now inadequate.<br />

Order No<br />

(PK)<br />

100<br />

100<br />

100<br />

100<br />

101<br />

102<br />

102<br />

102<br />

103<br />

103<br />

103<br />

Figure 8-1<br />

Order Date Customer No Part No Description Qty Unit Price Total Price Wt.<br />

1/1/1999<br />

1/1/1999<br />

1/1/1999<br />

1/1/1999<br />

1/1/1999<br />

1/1/1999<br />

1/1/1999<br />

1/1/1999<br />

1/2/1999<br />

1/2/1999<br />

1/2/1999<br />

54545<br />

54545<br />

54545<br />

54545<br />

12000<br />

66651<br />

66651<br />

66651<br />

54545<br />

54545<br />

54545<br />

1A4536<br />

0R2400<br />

0R2403<br />

4I5436<br />

3X9567<br />

8G9200<br />

8G5437<br />

3H6250<br />

8G9200<br />

2P5523<br />

3X9567<br />

Flange<br />

Injector<br />

Injector<br />

Head<br />

Pump<br />

Fan<br />

Fan<br />

Control<br />

Fan<br />

Housing<br />

Pump<br />

For now, we’ll address this by adding a line item number to our table, as shown in Figure 8-2, so we can,<br />

again, uniquely identify our rows.<br />

5<br />

4<br />

4<br />

1<br />

1<br />

7<br />

1<br />

1<br />

40<br />

1<br />

1<br />

15<br />

27<br />

29<br />

750<br />

62.50<br />

12<br />

15<br />

32<br />

12<br />

165<br />

42<br />

75<br />

108<br />

116<br />

750<br />

62.50<br />

84<br />

15<br />

32<br />

480<br />

165<br />

42<br />

6<br />

.5<br />

.5<br />

3<br />

5<br />

3<br />

3<br />

5<br />

3<br />

1<br />

5<br />

221

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

Saved successfully!

Ooh no, something went wrong!