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

"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message news:3Nrpc.40241$TT.30435_at_news-server.bigpond.net.au...
> There are 3 software environments:
> E1 = Operating system and network os layer
> E2 = RDBMS layer
> E3 = application layer
>
> The "data" is bound within E2, and although is operated
> on within E2 (hopefully in accordance with the RM), the
> ultimate control for these operations are from the end user
> within an organisation, via the app layer (E3). (GIGO)
>
> [...]
>
> The RM does not reflect the actuality of the above, nor
> make any provision for the management of the E3 layer
> because it is not yet completely evolved.

I disagree, although your use of the term "management" is questionable. E1 provides services for E2; E2 does an analogous thing for E3. E2 provides E3 with data (whatever it means) and inferences about that data; that's its job.

> The catch-cry "the RM is just as applicable to database
> systems today, as it was in the early 1980's" should be
> taken as an indication that something is wrong with it as
> a pedagogic device for 2004.

It's more than a pedagogic device, but it's at least that.

> The reason for this is that E2 and E3 have changed alot
> since 1980, particularly E2, the RDBMS software. Due
> to the emergence of addressable stored procedures in
> the RDBMS, there has been an effective "migration" of
> intelligence (code) from E3 to E2.

You contradict yourself here, as the migration doesn't mean that the previous services supplied by E2 are any more or less different. The code is running in a different place. Date's Intro to DB Systems book discusses various "levels" of the DB schemata - I forget the exact terms he uses, and I don't have the book here. So yes, there is a distinction between "shared" and "app-specific" components, whether they're running in the DBMS or not.

But that doesn't alter the fact that the code "objects" (E2b) in the DBMS are different from the relational "objects" (E2a) in the DBMS. There's still a logical separation, with E2b relying on E2a just like E2 relies on E1, and E3 on E2. Capiche?

I'm still curious what sorts of concepts (other than the vacuous term "management") you think the relational model should include for such things.

> The boundaries between E2 and E3 are now probably
> best described as fractal, whereas in the past they were
> heavily demarked.

They're hardly fractal, and I would say that the layering is more severe in the E2b category. E2a remains solidly relational.

> However in practice, it is a dynamic fluid element that
> must be managed, with the assistance of, but also outside
> the realm of the present applicability of the RM.
>
> Change management is the name given to the bag that holds
> together everything that falls through the cracks of theory
> and out into the world of practice.

I think I'm starting to agree with you on this, but still don't think that's the province of relational - at least not yet. I would like to see discussions on a standard system catalog - in essence, relational statements about relvars! Since the catalog is a set of relvars like the others, yet describes those others, we now have true relational metadata, an interesting topic...

• erk