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

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:ocQqc.19366$fG.17278_at_newssvr31.news.prodigy.com...
> "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 term management reflects the mandatory overview of all components in the system, and their coordination. As I have outlined, I have constructed an arrangment whereby all of E3 has been subsumed in the form of stored procedures, within the E2 environment.

The Relational Model and theory cannot distinguish this specific arrangment from any other, because it disregards E3 (application layer) because of its traditional frame of reference, which in historical terms is understandable, but is not so important in today's world.

This specific arrangement developed however is complete, and requires no other support to function. So you see, we may have a large number of stored procedures which act as E3 components, each written is SQL, each syntactically as per Date's exemplary treatment, each relating precisely and specifically to known data structures defined in the RM.

Yet the model can say nothing in its present state. This is an absurd state of affairs for database systems managment.

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

It is an incomplete device.

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

Date has one diagram and a few words to say about the apps environment. Sure, in my argument, as you note, the code is running in a different place. But which place? Inside the RDBMS software environment?

Date and the RM are not capable of uttering anything sensible about this state of affairs. The RM cannot address stored procedure object data, end of story.

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

I understand the inter-dependencies, but you seem not to understand the term management. This term means the ability, or lack thereof, to properly look after everything in that environment.

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

Lookup the term fractal basisn boundary.

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

The relational model was an ideal of Codd and the pioneers that has been promulgated by Date et al. It is at least 30 y/o and is not consistent with technological reality.

It has a Godel-like incompleteness:
http://www.mountainman.com.au/software/history/relational_model_incomplete.htm

Pete Brown
Falls Creek
Oz Received on Thu May 20 2004 - 04:11:48 CEST