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

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:H1hmm5EGEfyAFwYZ_at_thewolery.demon.co.uk...
> In message <ca874t$g9t$1_at_news.netins.net>, Dawn M. Wolthuis
> <dwolt_at_tincat-group.com> writes
> >> > It is an object in and of itself that
> >> > needs no "chopping up", so to speak.
> >>
> >> Yes, it does. "Analysis" means chopping up. We gain power in chopping
up.
> >
> >and putting back together
> >
> >> Our problems are solvable when they're chopped; our solutions are
scalable
> >> and provable when they're chopped.
>
> To give a real-world analogy ... try chopping up a hadron. Physicists
> have tried, and it uses up a HELL of a lot of energy to get you nowhere.
>
> If you don't know what a hadron is, it's things like protons and
> neutrons - basically, anything made of quarks. You can't chop them up,
> because they put themselves together again ...

I didn't - but I'm sure physics software folks chop them up abstractly by assigning attributes. :-)

> But when you chop up, say, an invoice, it can't put itself together
> again. Think about it - given a chunk of data that exists in physical
> form (that piece of paper called an invoice) - once you've put it into
> tables in your relational database, how do you get it back out as a
> "chunk" of data.

Agreed - that's where relational would say "we're done" and delegate that to applications. The reason is simply that the "chunk" you want varies widely; yes, a single invoice is an immediately intuitive and useful chunk, but structuring based on it makes other "chunking" more difficult.

That said, I've argued elsewhere and am still pondering the idea of layering a hierarchical transform over a relational database, to derive an application view (GUI, report, export, etc.)

> Yep, you can define a view (which I would accept) but
> the purists will say that that isn't relational because views
> (currently) aren't closed.

I assume you mean application views, not relational ones? Agreed they're not closed... but then again, I don't think they can be, at least not yet. But perhaps they're closed in the same sense that XQuery is... have to think about that one.

> Plus, if you're going to get the order right,
> you've had to convert the original metadata (implicit order) into real
> data and do a sort (both of which I would say is you creating data and
> then providing it upon extraction - so you haven't actually stored the
> invoice properly in the database!

You're not creating it (it was there implicitly already), but you are making it explicit. Is that bad? I don't think so, but it's debatable. I would again raise the spectre of additional metadata other than order... what else "should" be there in a data model? And how best to represent it?

> When we put an invoice into a Pick database, the data in the db maps
> CLEANLY to the data on the paper. And the db has all the metadata it
> needs to convert this to a relational view should a user so desire.

Except that your query language is less symmetrical as a result of treating assertions about line items differently than other predicates. At this point I'm just repeating myself though...

• erk