Re: Joining data tables and system tables

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<avcjtb$f6s$1_at_sp15at20.hursley.ibm.com>...
> > Are the tables names in the system catalog really pointers?
>
> No they are just names.

Hmm, I'm not totally convinced that they aren't pointers. I guess it depends on your definition of "pointer".  

> Your original query is possible assuming the database user knows the names of
> every relation in the database. I agree that this is not always a reasonable
> assumption and so some method should be provided to directly perform the kind
> of query you mentioned. The only issue, I belive, is on the concensous on
> what the best method(s) would be. I can think of a few options...

As I mentioned before, ANY logical information about the database that you can get from the system catalog could be obtained from just knowing the names of the relations in the database. I've never understood why a system catalog is one of the requirements for a DBMS to be called properly relational - the two concepts seem orthogonal.

A relvars can be thought of as an expression of first-order predicate logic.
The system catalog is a logical expression *about* first-order expressions; thus is it not an expression of second-order predicate logic? And relational theory is just about first-order logic so how can it have a system catalog?

Here's some more concrete thoughts regarding Russell's paradox:

suppose I define a function f:Strings -> {T, F} as follows:

f(s) = {True if s is the name of a relvar and also

                this relvar contains the string s in some
                value of some string-valued attribute
       {False   otherwise

thus we might have a relvar "emp" with some employee called "John Kemp", so f("emp") = True.
I would seem that this function is well-defined; conceptually we just look through the tuples of the relvar checking to see if the string is present.

Now consider CREATE fview AS SELECT * FROM RELVARS WHERE NOT f(relvarname)
where RELVARS is our system catalog and relvarname is the attribute detailing the name of the relvar.

What do I get if I do SELECT * FROM fview? Does this include a tuple for fview itself or not?

The root of the problem here I think is that the definition of fview is self-referential.
But how does the DBMS know this? Syntactically it would appear correct.
What if we have two views each of which references the other? i.e. indirect self-referentiality?
In this case, like with Russell's set theory paradox, spotting the problem is more tricky.

In the set theory case iirc, the resolution was to disallow set definition like s={x:p(x)} where p(x) is some property of x. And instead insist on s={x in U:p(x)} where U is some predefined set. So the analogous thing here would be to allow the system catalog to only list "real" relvars i.e. not the system tables themselves.

If we allowed any interaction between data relvars and system relvars would we come up against the same problem somewhere down the line? In this case, removing the system relvars from being listed in the system catalog themselves would solve the problem I think. But maybe it would cause another?  

Paul.

> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
Received on Wed Jan 08 2003 - 15:14:14 CET