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

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Wed, 02 Jun 2004 21:00:36 GMT
Message-ID: <Udrvc.4918$py1.426_at_newssvr16.news.prodigy.com>


"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c9l1rc$1c7$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:Comvc.4724$n65.4145_at_newssvr33.news.prodigy.com...
> > "Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> > news:pKOdZaHNSQvAFwH7_at_thewolery.demon.co.uk...
> > > And I'm pretty damn
> > > confident that you can NOT create a theory that will do a reversible
> > > mapping between the real world and relational data.
>
> I agree and figure that we will have a useful theory of this sort when we
> have the same on "how to parent a teenager". However, in some ways, Wol
is
> making a similar argument to mountain man (even if they might not agree
with
> that) in identifying that even if relational theory were good to apply, it
> is useful in a rather small portion of what we do in addressing the "data
> processing" needs of a business.

Possibly, though that depends on how you define data processing, of course. Certainly software concepts like concurrency and distributed computing aren't addressed by relational. When it comes to data, I would say that a presentation language would be a nice relational add-on, as well as the definition of a system catalog. The two of those would make a nice combination.

In any event, Dataphor (and reporting products mAsterdam refers to) infer a great deal already, and to present both UIs and other user-facing artifacts derived from... relations! Why you'd structure your data based on its eventual output is beyond me, since that output is neither unique nor static.

> There are at least the axioms of set theory and then some things were
tossed
> in the mixed without any proof from these axioms, such as restricting the
> sets from which elements can come to sets of scalar values (which has been
> changed now, but 1NF, however defined, would have to be considered an
axiom
> since it does not arise from any other mathematics)

1NF says only that the relational model doesn't treat types specially; it defines the "domain" of the relational model as distinct from the user-definable (therefore extensible) portions. Not sure why that's a problem - in any event, lists can be seen as scalars, as long as you're not requiring the base algebra to in some way acknowledge them. Not sure why you'd want to, since you do have user-definable types and operations.

And as far as data types go, lists are sometimes nice but there are far better ones for most purposes - e.g. relation-valued attributes. For example, let's say that you chose to have a "LineItems" attribute. If you had only lists, you'd have to have several attributes - one for part numbers, one for quantities, etc. And you'd have to adopt the convention that PartNumber[n] corresponds to Quantity[n], with no guarantees that the lists couldn't end up with different sizes, if your code is bad. With a relation LineItems = {Part#, Qty}, not only would you have a guarantee, you could even query that attribute, rather than writing a stupid loop!

So relations give you rich attributes in a far more consistent and powerful way than lists, which are impoverished little suckers. I rarely use them in Java - the other types are far more useful and powerful. They're the type-generators of last resort.

But if you do want to see lists done right, check out any Lisp dialect. Easier processing, nicer syntax, and better reuse than Java.

(and yes, I understand we're mixing code and data again...)

> It think it is worth noting that is far more difficult to retrieve an
> invoice the way it looked originally after chopping it up (that 1NF thing
> again) and then using SQL to show the invoice again.

True, but it's far easier to derive other facts about that invoice, and its relationship to the customer and other invoices and parts and shipments, when it's not all one big blob. Again, if your main task is showing people the invoice, why transform it at all? How do you know when you've gone too far? In other words, what are your normalization rules? Is it just unhooking 2NF from 1NF?

> Without arguing the semantics (and mapping of the data to reality) of this
> particular example, if your invoice looked like this when selling a
> beautiful skirt in white and blue that comes from two of your catalogs, it
> is definitely HARDER than a non-1NF environment, though not impossible, to
> get a SQL statement to show your invoice properly.

That's true, primarily because SQL is a bad reporting tool (in addition to being a bad relational derivative). There are better ones.

> > So what do you want - the invoice paper? Maybe we should just rely on
> > scanners producing JPGs - non-lossy, of course.
>
> No need -- including lists in your data (at least your virtual data!) gets
> you far enough that you don't notice any more big disconnects.

It gets you somewhere, but as I said above, relation-valued attributes get you much further. Why not them?

> SQL Server
> permits lists in their UDFs, while Oracle (to my knowledge) does not allow
> lists returned from their functions (stored procedures)

Does SQL Server's SQL dialect address lists directly?

> > > Dawn was going on about faith. Do you have faith in
> > > business analysts to get the analysis correct, or would you rather
have
> > > a formal, REVERSIBLE and PROVABLE (or testable, falsifiable,
scientific,
> > > whatever term you want to use) logical theory to do it for you?
> >
> > Sure. I also want to fly, eat infinite amounts of ice cream without
> gaining
> > weight, and drive at very fast speeds with no possibility of injury.
>
> As long as we are all aiming for the same things ... smiles. --dawn

True - ease of development and assurance of data integrity are mine. Both benefit the user...

  • erk
Received on Wed Jun 02 2004 - 23:00:36 CEST

Original text of this message