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

"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message news:EtUqc.49042$TT.40732_at_news-server.bigpond.net.au...
> > 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.

The term "management" has at least the same "Goedel-like" incompleteness that you refer to elsewhere, unless you really believe "overview" and "coordination" are precise. My point is simply that I don't know which aspects of "management" you're referring to - it has many definitions, components, and dimensions. Be precise.

However, I do have your papers printed out, and will be reading them shortly - so far I'm only judging by what you've written in these posts.

> 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 fact that they're executing in E2 doesn't imply "subsumption." They are still "objects" of a very different sort than those E2 traditionally "manages." For instance, those stored procedured could be written in arbitrary languages, and executed anywhere. It seems you see their value in their genericity, rather than in where they happen to execute.

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

So why does E1 disregard E2? Don't you think that's short-sighted and incomplete? How would you rectify that? Shouldn't they all be subsumed into E* ("*" as in transitive closure) ?

> This specific arrangement developed however is complete,

In a Goedelian sense? Doubtful.

> and requires no other support to function.

Not even E1?

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

That's no different than any other E3 component, is it? Like a Java program doing JDBC and issuing SQL Strings in exchange for ResultSets?

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

So once E3 components are "subsumed" in E2, what more can be said about them? Specifically, what special properties or powers or whatever do they derived from executing in E2 rather than regarded as part of E3?

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

Could be - why does it matter? They're still code components, not relvars. What difference does it make where they run? I agree with it, don't get me wrong - but I think then you just happen to have E3 components running in E2, which indicates to me that your operational levels are perhaps orthogonal to the real issue of what "types" of components are being "managed".

> Date and the RM are not capable of uttering anything sensible about
> this state of affairs.

What should they say? In contrast to their muteness, say something - anything. I have no idea what you're looking to be said.

> The RM cannot address stored procedure object data, end of story.

So say something, even informally, that should be part of some "RM++" theory. I have no idea what you're hinting at - this argument reminds me of internal auditors at a former company, who could point out things done incorrectly but were not allowed to say a word about what SHOULD be done instead.

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

Perhaps, but you're not helping. If you understand it thoroughly, then your words aren't helping the rest of us... granted that this isn't a "management" class, but some clarification would help.

> This term means the ability, or lack thereof, to
> properly look after everything in that environment.

"Properly look after"? That's clarification?

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

And your theory is Goedel-complete? Doubtful. Let's agree to stop waving Goedel and Occam about, and concentrate on specific areas of incompleteness that matter in both theory and practice...

• erk