Re: Data Display & Modeling

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c7ioke$n22$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:YzQmc.86$Qm5.68_at_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