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

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:7wh5nhII+5xAFwnD_at_thewolery.demon.co.uk...
> In message <d5Gxc.6813$zZ2.831_at_newssvr32.news.prodigy.com>, Eric Kaun
> <ekaun_at_yahoo.com> writes
> >My point is that data has no natural form, plain and simple. I've
> >encountered too many cases over the years where accepting the "natural
form"
> >as the users stated it would have resulted in brittle design - where
> >abstraction and extension yielded immediate results.
>
> Fine. But if data has no "natural form", then in the real world there is
> no such thing as data. Therefore there is no point in building a system
> to model it :-)

Cute... but the whole point of building a system is to impart some form to the data, to render it manipulable. Otherwise we can stick with pieces of paper in filing cabinets, if that meets the users' needs.

On second thought, you're right - there is no such thing in the real world as data. Data is our model of the real world, or at least part of that model. "Data modeling" is thus a misnomer, though I can't think of a better gerund than "modeling". "Data creation" might be confused with the actual population of a database.

> >OK, I'll accept that - it just sounds like a massive pile of aggravation
to
> >me. Predicates can expand as requirements do (and as you learn more about
> >them), which is where normalization acquires its power. To just pile on
> >attribute after attribute or sub-attribute after sub-attribute, and to
have
> >to keep straight (for myself and future developers) which of those are
> >correlated with others just sounds like a leap of faith that's both
annoying
> >and unnecessary.
>
> Except that actually, it works EXTREMELY WELL in practice. We think in
> terms of language. To me a "table" is a noun. A field (your "column") is
> typically an adjective, or grouped into an adjectival clause. It can
> also be a gerund (your foreign key) which is, sort of, an adjective.
>
> Basically, it fits the way nature has designed our brains to work. So
> the practice is simple. By imposing abstraction, the relational model is
> forcing the data into a framework that our brains are not designed to
> understand.

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.

> >> If the
> >> relational analyst didn't foresee that, you're going to end up in an
> >> equally big mess (experience says "even bigger" mess) than a Pickie, if
> >> both are faced with the same analysis failure.
> >
> >Perhaps that's true - I can't say it is, but don't have a strong
> >counter-argument - but in my experience, analysis failures are much less
> >destructive when you've normalized properly.
> >
> Which is why I'm such a fan of normalising within a Pick FILE. It forces
> you to analyse properly, and reduces the likelihood of an analysis
> failure. Supporting our Pick systems at work can be a real pain, I
> admit. But EVERY screwup can be attributed - directly - to an analysis
> failure that was just plain sloppy, or poor programming practice like
> not separating updates from reports :-(

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?

> Unfortunately, that's typical of Pick systems - so many systems are
> *written* by USERS for USERS, so that while they work extremely well
> they also have the computer pros tearing their hair out.
>
> But surely that says something - wasn't the design aim of SQL to be "so
> easy that users can use it"? Pick has actually achieved that aim!

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.

• Eric