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

In message <d5Gxc.6813$zZ2.831_at_newssvr32.news.prodigy.com>, Eric Kaun <ekaun_at_yahoo.com> writes
>"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
>news:DEv3K2FwTOxAFwzu_at_thewolery.demon.co.uk...
>> In message <5k2xc.6205$4b2.1710_at_newssvr32.news.prodigy.com>, Eric Kaun
>> <ekaun_at_yahoo.com> writes
>> >> A data model that can do this has many advantages.
>> >
>> >That can do what - model arbitrary data in its "natural form", whatever
>that
>> >means? I agree. If you show that to me, I'll use it.
>>
>> And there we have our problem.
>>
>> Yep, I can see where you're coming from, in practical terms. But can't
>> you see where we're coming from? My problem, as I see it, is that
>> 'arbitrary data in its "natural form" ' is NOT amenable to easy coercion
>> into "relational data".
>
>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 :-)
>
>> From that, it follows that relational databases are the wrong tool to
>> model natural data with.
>
>I don't believe natural data exists. It's all unnatural. To simply accept
>the intuitive "sense" of business data as the users see it gives you
>something quickly, but in every case I've ever encountered, that simplicity
>is a limitation not just on future requirements, but on immediate ones as
>well, and on the ability to craft a strong solution to current problems. In
>every case I've ever experienced, abstracting and structuring beyond what
>the users would consider "natural" (and for which we still have no
>definition) has benefitted me in terms of shorter development time, more
>flexibility for future extensions, and better ability to explain nuances of
>their situations to users (e.g. better analysis).

It's all unnatural? As I said above, then surely it doesn't exist ...
>
>> However, as I said, I do feel that it's like the circle/ellipse problem
>> that Copernicus had. IF people are prepared to *look* at real data in
>> its "natural form" and develop a model that really addresses that,
>
>It's difficult to address it when it's so intuitive. I understand this is a
>human discipline, but formal guidelines can be useful in meeting real needs.
>
>> while
>> it will make one hell of a mess of current relational theory, combining
>> a "natural form data" model with the relational model will yield a very
>> powerful database theory.
>
>I doubt it, but am willing to think about it. What is that "natural form"?
>Is it just 1NF? Is that still the linchpin of the argument?
>
>> After all, isn't that exactly what I do when I insist on normalising all
>> my data within Pick FILEs? And I really don't see the problems you do,
>> even if the line-items come from multiple warehouses etc etc.
>
>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.

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?
>
>> 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 :-(

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!

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999