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

"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.

> 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).

> 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.

> 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.

• erk