Re: A Normalization Question

From: Alan <alan_at_erols.com>
Date: Tue, 13 Jul 2004 10:21:07 -0400
Message-ID: <2li9ehFd1664U1_at_uni-berlin.de>


"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0407121520.57b3f62_at_posting.google.com...
> > > However, regardless of whether the string 'brown' is categorized as a
> > > fact or not by your definition, they still represent the same thing,
> > > the string 'brown'. Having three things that represent the same thing
> > > in one db is redundant.
> >
> > It's physically redundant, not logically redundant.
>
> As some have repeated here, RM is a logical model. In general, its
> implementations doesn't expose the physical layer. The three 'brown'
> strings stored in a relational database are logically redundant and
> are subject to update anomalies.

Stefan has explained it in another message. You continue to confuse the physical and logical. Let me try again:

Storing the string "Brown" more than one time is physically redundant, not logically. The word has a different meaning in each context. What you are doing is the equivalent of this:

Brown = 1

He has <1> hair.
They live on <1> Street.
His name is Mr. <1>.

You have replaced one symbol that is easily understood with another that is not. Furthermore, in your world, every word that exists would ultimately need to be replaced with another symbol because eventually, every word will be stored more than once. So, you wind up with a bunch of replacements for the real words. The replacements for any single word would all be the same value. So, you are still storing the same "redundant" items, just in different symbols (as pointers). You have not eliminated any redundancy at all, and have, in fact, added an unneccessary layer of complication. In another sense, you will have created, by translation, another language that no one understands, and must always be looked up in a dictionary to use it. Even if you migrate this notion to the world of computers, it is still not as efficient as existing means (E.g., an index and table). Received on Tue Jul 13 2004 - 16:21:07 CEST

Original text of this message