Re: Can we solve this -- NFNF and non-1NF at Loggerheads

From: Alan <alan_at_erols.com>
Date: Mon, 7 Feb 2005 16:25:27 -0500
Message-ID: <36q4mfF4sigpiU1_at_individual.net>


"Dan" <guntermann_at_verizon.net> wrote in message news:1107803035.206779.278690_at_z14g2000cwz.googlegroups.com...
> Alan: "Nonsense. Of course they disagree, that's what we've been
> arguing about. I've cited well-respected, published proof of my
> argument, and until someone can present well-respected published proof
> (and not just on the internet where one could find "proof" of little
> green men from Mars) of their argument, they should keep quiet. Or
> apologize.
>
> Note: please refer to inclusive thread for further context.
>
> Alan,
>
> I have the Elmasri/Navathe text at home as well; and I use it as my
> primary reference of choice along with Date's "Introduction...". I
> think the definition provided by them is totally valid.
>
> However, the definition doesn't really address the issue of how we use
> symbols and languages to communicate meaning. This is left up to the
> user to manage and dictate to a system. A phone number in one sense is
> totally atomic in that it is an address for reaching someone by
> telephone. If this definition suites the user's needs in terms of
> retrievability using RT, then it is atomic by the user's standards.
> However, if a user is going to join area codes with geographic cities,
> then it makes sense that the "database" will have a need for a
> decomposed variant of telephone number.
>
> I think this case is more common than we actually appreciate. And if
> we want to take it in the extreme, there might actually be users who
> are interested in asking questions such as which employees have a home
> phone number where the second digit in the area code is equal to the
> fifth digit of his or her social security number? What do we end up
> with in such a case? Well, Neo's experimental database of course! <g>
> However, decomposing to such an extreme poses real practical
> limitations. Other methods, such as type operations, can do these
> quite effectively without producing a model so mired in minute details
> that the general concepts are totally occluded.
>
> A while back I produced a reference in response to Dawn that quoted
> Codd on his intent concerning the meaning of "atomic" as it applies to
> RT. Parenthetically, he qualified the use of atomic with the
> clarification, "not further decomposable by the database." I can
> reproduce the reference if you wish, but I'm hoping you might remember.
>
>
> I interpret this rather succinct footnote to mean that an element which
> is entirely decomposable in every sense of the word is a sufficient
> condition for 1NF, but it is not a necessary condition. The necessary
> codition comes from the words, "by the database" (and the designer who
> designs it).
>
> Does this make sense?
>
> Regards,
>
> Dan
>
I agree with most of the above, especially the phone number references (I believe I alluded to the same points elsewhere). And, having been a Communications majkor in the past, I am aware of the problems of language. But this is why database design is as much an art as a science, and why designers get the big bucks. I compare database design to detective work. Heck, it is exactly detective work. The designer must ask questions, and not stop until the attributes are defined to the most elementry level. The designer can then decide whether or not to aggregate portions of the elements. This is where atomicity of an attribute is decided (or defined). I think we agree completely on this point. The phone number example is perfect. Sometimes you need each part (or maybe even each digit, in Neo's case), and sometimes all ten digits in one fell swoop is fine (as at my workplace). In any event, atomicity is clearly stated to _not_ be defined as accepting MVAs of any kind, which has been the attempt throughout this discussion. Those are really two different animals. Deciding what is atomic (as in the phone number) is not the same as deciding that it is okay to allow MVAs.

I am not certain what "not further decomposable by the database" means. It rings of implementation, which must be avoided completely in this discussion, as the implementation level, as you know, is not considered during the logical design. Received on Mon Feb 07 2005 - 22:25:27 CET

Original text of this message