>John,
>
>Lurker here jumping in ... :-)
>

LOL.... :)


>2nd NF: All attributes in the entity are dependant on the entire primary key.
>
>Example;
>
>Invoice Detail Lines Entity
>
>Structure:
>
>Fields
>InvoiceNumber (PK part 1)
>LineNumber (PK part 2)
>CustomerID (non-key attribute)
>...
>
>The 2nd NF is violated because the CustomerID is NOT dependant on the ENTIRE PK of the entity, it is dependant only on part of it (InvoiceNumber) and is unaffected by the other part (LineNumber).
>
>OK, that's for 2nd Normal Form.

A statement of fact. One that I cannot argue with. And, you explained it in a clear and concise manner...


>
>You are correct in that the entire process of normalization tends to remove redundant data from the design, however, there is no Normal Form that states anything directly about redundant data.
>

Whether it is stated directly or indirectly has never been an issue to me. What is the issue is the intent, what the end result is, what the goals of normalization are.

>
The problem with your original example way back up the line was that the two fields you chose as your example were not redundant as they had different domains definitions. One was the current address and the other was the address at the time of the invoice.
>


You are using the same line of reasoning, I think, that Erik is making. And FWIW, I don't entirely disagree. This whole discussion started with whether de-normalization is a valid term of art for this scenario. If it is not de-normalization, what is it?


>
The same problem arises when you consider tax rates. Your have a tax rate field in the customer table that is the customer's current tax rate and there is a tax rate field in the invoice table that is the tax rate at the time of the invoice. Do these two fields represent a denormalized structure? Are they redundant data storage? No they are neither as they have completely different domain definitions and therefore are completely different pieces of data.
<

I gather you reach this conclusion that once a tax rate has been dropped into a line item, the tax rate actually morphs into a different entity. I can't argue with that.

While I would agree that the tax rate may not be redundant with respect to a tax-rates table. It is redundant with respect to the lineitems table. And that takes you back to deal with the 2NF. FWIW, I don't think this is a big deal since the implication is that you have already addressed the 2NF issue earlier in your analysis. Now, with respect to elements like item description, tax rates, etc, you are doing something different. You are attempting to accomplish a different goal.


Good discussion...

< JVP >