Re: A Normalization Question

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Tue, 13 Jul 2004 18:34:06 GMT
Message-Id: <pan.2004.07.13.18.34.31.938642_at_REMOVETHIS.pandora.be>


On Tue, 13 Jul 2004 10:44:47 -0700, Neo wrote:

>> > Multiple occurances of the same string is necessarily redundant. It
>> > requires a limited data model and definitions to obscure this fact.
>>
>> This has nothing to do with the data model. The definition of logical
>> redundancy is independent of what data model you choose.
>
> ID Person Color Street
> 1 brown brown brown
>
> One only needs to look at the above tuple to see 'brown' is redundant.
> One can become blind to this obvious fact by seeing things through a
> limited data model.

I'm not seeing things through any data model in particular.

>> > I am not sure what point you
>> > are making, but changing one 'brown' to 'nworb' in a db with multiple
>> > occurances of the same string results in an update anomaly.
>>
>> Not according to the standard definition of update anomaly in
>> normalization theory. It would really help communication if you stopped
>> giving standard terminology your own Neo-meaning.
>
> Then your/RM's standard definition/theory is limited as changing one
> 'brown' to 'nworb' in a db with multiple occurances of that string
> results in unsynchronized data.

That can always happen if you allow changing the database constraints, even in your data model. If that is your definition of update anomaly then you trivialize the notion because all data models will always suffer from update anomalies and that makes this definition worthless.

>> Note, by the way, that in your "normalized" representation you
>> sometimes need two updates (the creation of a new list of characters
>> plus the update of a reference) for what was originally only one update
>> (updating a string).
>
> The number of updates have nothing to do with the fact that string
> 'brown' is redundant in the following tuple:
>
> ID Person Color Street
> 1 brown brown brown

No, but it shows that you are in fact introducing new update anomalies that weren't there before.

>> whereas your example is a bit exotic, to say the least.
>
> It is not for a data model to make a judgement whether something is
> exotic or not.

You are simplifying certain updates that will probably never occur and in doing so you make certain other updates that occur very frequently harder. That's not good data modelling.

  • Jan Hidders
Received on Tue Jul 13 2004 - 20:34:06 CEST

Original text of this message