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

From: Alan <alan_at_erols.com>
Date: Mon, 7 Feb 2005 10:08:04 -0500
Message-ID: <36peinF540q0pU1_at_individual.net>


"Tom Ivar Helbekkmo" <tih+nr_at_eunetnorge.no> wrote in message news:86ekfskhw2.fsf_at_athene.hamartun.priv.no...
> "Alan" <not.me_at_rcn.com> writes:
>
> >> No, when he said "atomic", he meant something else: he meant that the
> >> objects in question were atomic _with respect to the theory_. That
> >> is, his relational theory was not concerned with what those objects
> >> actually were; as far as the theory went, they were atomic. This does
> >> not mean that they have to be scalar values; they can be _anything_.
> >> However, if the value of an attribute is, say, a relation, there is
> >> nothing in Codd's theory that looks into that relation, and lets its
> >> contents affect operations on the outer, "real", relations.
> >
> > I refer you to the Elmasri/Navathe text, which states quite the
opposite.
> > Paraphrasing it (as I don't have it with me at the moment), 1NF means
that
> > all values are atomic (simple and indivisible - are terms used to
explain
> > "atomic" in the text), and any value must be a single value from the
domain
> > of that attribute. It does not allow nested data. It does not allow
> > multi-valued or composite attributes. These constraints on 1NF are
> > specifically stated in the text. Dawn has a copy. Perhaps she can look
it up
> > (look up First Normal Form).
>
> As far as I can tell, the two paragraphs I'm quoting here are not at
> all in disagreement. In 1NF, attribute values are atomic with respect
> to the theory, meaning that their values have no meaning within the
> relational theory. What those values are is irrelevant, as long as it
> is possible to assign them, compare them for equality, order them for
> sorting, &c. Whether the domain of an attribute is given as "positive
> integers", "character strings", or "blarglefnorts", is not interesting.
>
> Quick check of agreement: if I have a column for telephone numbers,
> and store them as text strings like '555-1234', '(201) 555-1234' &c,
> because that's what my application wants them to look like, you
> wouldn't therefore claim that my table fails to meet 1NF requirements,
> would you? My telephone numbers are _not_ atomic: there's an area
> code encoded within them, and that area code is even optional! :-)
>

(Full) telephone numbers may or may not be atomic. It depends on the business requirements. At soem point in the not-too-distant future, area codes may lose their meaning as a geographic area discriminator. At that time, a full phone number would always be atomic. That being said, we do not store area codes separately, as we do not use area code as an individual piece of information for anything. ALso, 10 digit dialing is required in our area. So, in out case, a phone number is atomic.

> Of course, I fully agree with you that the moment we expand our
> relational model with operators that peek into attribute values,
> treating them as composite objects equivalent to rows, or even tables,
> we can no longer claim that tables containing such attributes satisfy
> the classic definition of 1NF. At this point, new definitions of the
> normal forms are needed, that take the new features into
> consideration.
>
> It seems intuitively obvious to me, though, that this can be done
> without breaking the underlying relational theory.

I'm not sure. To me it seems intuitively obvious that it can't be done without breaking relational theory. Just a quick thought, for example- if MVAs are allowed, how does 3NF make sense? The non-key values in a tuple are supposed to be about the key, the whole key, and nothing but the key. While I can imagine suituations where this would work (with weak entities as MVAs, for example), there are plenty of examples where this would be a recipe for disaster.

>
> -tih
> --
> Don't ascribe to stupidity what can be adequately explained by ignorance.
Received on Mon Feb 07 2005 - 16:08:04 CET

Original text of this message