Re: In an RDBMS, what does "Data" mean?

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:LlhliVDHzeyAFwot_at_thewolery.demon.co.uk...
> In message <4u2yc.7127$n65.4184_at_newssvr33.news.prodigy.com>, Eric Kaun
> <ekaun_at_yahoo.com> writes
> >Heh. You're a scientist, right? Surely much of science is somewhat
> >unnatural, at least until after years learning it? Quantum theory not
even
> >then... but in any event, "naturalness" is a poor criterion for use.
> >
> >> Try describing your tables in terms of natural language. I can
guarantee
> >> you'll end up with a mess ... :-) one may be a noun, another is an
> >> adjectival phrase, another is a bunch of gerunds - what the hell - in
> >> simple intuitive terms - is a table?
> >
> >Each relation is a sentence.
>
> Then what is the relational equivalent of a verb? I notice you didn't
> directly answer the question :-)

Wasn't trying to avoid it; in any event, verbs aren't part of the model, which isn't language-based anyway. If nouns are FILES, and attributes are adjectives (in various kinds) then what in Pick are verbs? Sentences?

Furthmore, what point are any of these questions even making? I assume you're trying to demonstrate value in a close correspondence between data structures and English?

> >OK, I can buy that. But I'm still somewhat wary - you normalize, but not
all
> >the time. You suggest that normalization assists in verifying the
> >correctness of your analysis. So then at some point you de-normalize.
What
> >triggers you to do so? Or do you not denormalize because something in
your
> >analysis causes you not to normalize a specific aspect of the model?
>
> By "normalise", do you mean first normal form, or do you mean "normal
> form"? Because a Pick RECORD would normally equate to what a relational
> theorist would call a "closed view". It's not first normal form because
> it can be the equivalent of two tables linked by a "many" join, but as
> presented to the user I haven't added any data, not even like in a SQL
> view duplicated the "one" table to match the "many" table.
>
> So, if you don't insist on *first* normal form, then no I haven't
> denormalised!

I thought you mentioned a number of design changes which would amount to physical denormalization; maybe I misinterpreted.

> >Perhaps, I'm not sure. It certainly has failed in that regard, although
with
> >a few well-designed views and functions, I've taught some of my users
SQL.
> >But I think there's certainly an application level that sits above
> >relational (and SQL), and hides some of the details that are important
(or
> >else they shouldn't be there) - namely joins.
>
> Ummm.... I think we would differ here quite strongly. I would classify
> joins into several types, and some of them *shouldn't* be there - namely
> those that link a description to the described.

"Description" and "described" are vague to say the least; much of what you've described as attributes I'd classify as something worthy of description in its own right (dependent or no). So much of the discussion comes down to atomic/scalar predicates vs. composite "nouns" (actually a combination of nouns, adjectives, and "relationship clauses" of the "has a" form, as far as I can interpret Pick files)... so perhaps it's just a philosophical divide. As I've said elsewhere, an application view often suggests a hierarchy, but any number of hierarchies (meaningful to different roles) can be superimposed over something decomposed into predicates from the problem statement. So... ah, ran out of gas.

• erk