Re: Newbie question about db normalization theory: redundant keys OK?

Possibly duplicate post - (didn't see it appear in the newsgroup)

raylopez99 wrote:
> mAsterdam wrote:
>> raylopez99 wrote:
>>
>>> With a few hours of theory under my belt, I'd like to ask if
>>> there's ever a time that you don't want a completely normalized
>>> dB, that is, a normalized database being a
>>> dB that has no redundant information (my
>>> understanding of what a normalized database is).

>> This question is very well put.
>>
>> First, about your understanding.
>> The goal of normalizing is not to get rid of redundancies
>> but to get rid of update anomalies.
>> If, when in the real world your database is
>> modeling one thing changes and you have to change several pieces of
>> data in your database to keep it up to date, this means you have an
>> update anomaly.
>>
>> Several (mostly increasingly strict) normal forms exist to check if
>> your set of relations suffers from some anomaly with recepies of
>> changes to it to make it comply. Just google for normal form if you
>> didn't already.
>
> Thanks; I did Google it,and learned a bit about 1NF, 2NF, 3NF here:
> http://defiant.yk.psu.edu/~lxn/IST_210/normal_form_definitions.html
>
> While I didn't really understand the differences between the three
> types of NF (for one thing, it seems that they were dealing with a
> situation where the primary key was a 'compound key' that
> that depended on several fields, and since
> I like to use GUIDs as the primary key
> almost exclusively, I don't really suffer from this problem*),

You do (suffer). You just do not know it. Unlearning stuff brought to you by crappy products will be a major part of your effort in the coming weeks (if you are smart, serious and open) - ok somewhat longer if you include the loads of misconceptions in books on software written by established authors.

> it also seems that even with a fully
> normalized database (in 1,2 or 3NF), you
> will always have an UPDATE problem.

Please be more specific about the problem. (Let's analyze before attempting to solve; you did say you have a background in science, no?).

> The 'solution' is to minimize
> your hierarchy of UPDATES by employing a "star" configuration" or
> "cluster", as suggested or implied by David Cressey.

No, this is not at all what David suggested. (He'd most probably correct me if I 'd be wrong.)

I'l requote what you snipped - please re-read carefully:

>> if you are relieved of the burdon to keep 
>> your database up to date, and your main 
>> interest is in only a subset of what your
>> database contains, you don't worry about normalization. 

> This is where there is never more than two tables linked
> by the same key, which makes programming easlier

Let's not improve the efficiency of giving wrong answers.

BTW thinking of foreign keys as links is a common hard-to-get-rid-of misconception; Unlearn it, they really are different. Links point, foreign keys constrain.

> (that is, you don't have to program the
> UPDATE anomalies recursively, but simply program the almost trivial
> parent-child UPDATE case). But, as a practical matter,
> sometimes it's hard to not have the same key
> propigate to a third table, so even as I
> type this I realize this advice is not practical.

Good.

-- 
What you see depends on where you stand.