Quote:
Originally posted by mlbl
I've seen examples of normalization and i'm a little confused as there appears to be two different ways of doing it (from what i've observed) :
Style 1: http://www.gslis.utexas.edu/~l384k11w/normover.html
(in 1NF, the table is already separated)
Style 2: http://www.databasejournal.com/sqlet...6861_1428511_4
(in 1NF, only the primary keys are identified and only 1 table)
Which is the correct way? I'd like to normalize this :
order (cust-No, cust-Name, cust-Address, cust-City, cust-State, cust-Postcode, invoice-No, invoice-Date, order-No, order-Date, product-No, product-Desc, qty-Ord, prod-unitprice, prod-qtyship, prod-qtyback, total-price, disc-rate)
Can anyone help me normalize it up to 3NF?
|
There is not "one true way" to normalise. These sources show different approaches, but what is important is the goal: a set of normalised relations.
Normalisation is really a formalisation of common sense. I would look at your order table and say:
cust-No: sounds fair enough as an attribute of order
cust-Name: obviously, this is an attribute of the customer, not the order: create a customer table (cust-No (key), cust-Name) and remove cust-Name from order.
cust-Address, city, state, etc.: similar to cust-Name. However, you have to consider the business rules here: do you want to keep the address with the customer, or allow for variations on each order? i.e. is this really the customer's permanent address, or the address to which THIS order should be dispatched? Maybe you want both...
Carry on like that and see what you get. The hard part is not normalising the tables given the functional dependencies - it is finding out
what the functional dependencies are. There is no 10-step automatic process for doing that!