Path: newssvr20.news.prodigy.com!newsmst01a.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr32.news.prodigy.com.POSTED!b137e2aa!not-for-mail
From: "Eric Kaun" <ekaun@yahoo.com>
Newsgroups: comp.databases.theory
References: <c7e3hr$t0c$1@news.netins.net> <pan.2004.05.06.19.41.06.68201@dutra.fastmail.fm> <c7enir$d77$1@news.netins.net> <pan.2004.05.07.01.38.19.984939@dutra.fastmail.fm> <c7eulr$iqb$1@news.netins.net> <YzQmc.86$Qm5.68@newssvr32.news.prodigy.com> <c7ioke$n22$1@news.netins.net>
Subject: Re: Data Display & Modeling
Lines: 83
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Message-ID: <yeqoc.1165$qr1.246@newssvr32.news.prodigy.com>
NNTP-Posting-Host: 216.151.76.34
X-Complaints-To: abuse@prodigy.net
X-Trace: newssvr32.news.prodigy.com 1084370974 ST000 216.151.76.34 (Wed, 12 May 2004 10:09:34 EDT)
NNTP-Posting-Date: Wed, 12 May 2004 10:09:34 EDT
Organization: SBC http://yahoo.sbc.com
X-UserInfo1: [[OYR[CE@RUS@^@[ABJV_UPC[X_LPO@FKY\@LWQHBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN
Date: Wed, 12 May 2004 14:09:34 GMT
Xref: newssvr20.news.prodigy.com comp.databases.theory:26450

"Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in message
news:c7ioke$n22$1@news.netins.net...
> "Eric Kaun" <ekaun@yahoo.com> wrote in message
> news:YzQmc.86$Qm5.68@newssvr32.news.prodigy.com...
> > And I should add that Levene contributed to the "Nested Relational Data
> > Model", which I believe Date discusses in Intro-DB Systems as
unnecessary,
> > and proceeds to show why the basic relational model can tackle the same
> > problem domains without modification (and with additional benefits). I
> can't
> > remember the details - Dawn?
>
> Although Date talks about relation-valued attributes in Intro-DB, I
haven't
> found anything describing a nested relational model (but I've not read all
> the way through).  Instead he adds in the GROUP and UNGROUP operators in
D.
> However, there are a couple of papers that you can pay for and download
from
> dbdebunk.com where Date discusses nested structures and asks questions
about
> MultiValue (PICK) systems and then by Pascal who gives reasons not to use
> relational-valued attributes even though they are not outside of the scope
> of relational theory (anymore).

I have "What First Normal Form REALLY Means" here, and it's worth buying,
even for MVers. Some salient quotes from it, chosen for shock value:

"... the notion of atomicity has no absolute meaning..." [and of course,
atomicity is central to defining 1NF]
"... a set like {P2, P4, P5} is no more or less decomposable by the DBMS
than a character string is."
"... relations are always in 1NF!"
"It's certainly true that RVAs [relation-valued attributes] can be useful in
reports."
"Domains, and therefore attributes or columns, can contain anything (any
values, that is)."
"... hierarchic designs usually arise from a limited perspective on the
overall problem..."
"... the hierarchic representation isn't suitable for all of the kinds of
processing that we might need to do on the data."
"You can't tell whether a given table is in 1NF just by looking at it..."
"Supporting RVAs involves little in the way of additional learning... if we
were to introduce, say, arrays 'on the inside', then users would necessarily
have to understand arrays..."

Obviously you can abuse this notion, but I thought you might enjoy this
paper. It's certainly interesting, and not what's often argued with regard
to 1NF.

> > Not evidence of anything, except perhaps willingness to invent novelties
> > rather than exploiting what's already available
>
> Of course, that is what Codd did.

True, although in my opinion he sticks closely to a very applicable and
implementable theory. Higher-order logics are very useful, but first we
should get our money's worth from first-order, which has a few miles left in
it, right? Relational is a fairly direct application of predicate logic
without frills and extras, in my opinion, but I could of course be biased.
Perhaps the DBs he helped replace lacked theory, and thus any theory would
work, but I don't think that's it at all. He sticks to something simple, and
that's important - there are many mathematical systems that we wouldn't
dream of using for databases, so there have to be some meta-criteria for
selecting them. Topology? Statistics? While applicable to systems of
systems, I think they're out of line for business apps.

> > and solid.
>
> mathematically solid or history-of-savingcompanies-big-bucks-solid?

Unfortunately, many vendors could argue the same thing. Oracle, Microsoft,
IBM, Red Hat, blah blah blah. Depends on who funds the study. But I'll agree
with your experience and say that it sounds like your Pick systems have a
good development environment. I still think that if I were using it, I'd be
using relational as my guide, and I think you do the same - it's only on
display-only attributes where we disagree on 1NF. For that reason, I'd
highly suggest buying the paper above (no, I have no stake in the success of
their web site).

- erk


