Re: Distributed foreign keys (was Re: Category Types)

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:beaa1d$1atm$1_at_gazette.almaden.ibm.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:0CONa.349$VF5.47393910_at_mantis.golden.net...
> > You seem to suggest the system catalog should directly represent every
value
> > of the full range--that's more than just the extent--of every type known
to
> > the dbms
>
> Directly as a relation literal, or indirectly as a relational expression
over
> type literals used in the type's possible representations.

Since a literal is an expression, we can simplify the above to just a relational expression. I am not satisfied with that, though, because how do we deal with a 64 or 128 or 256 bit integer? A literal would be large. Do we represent it as the cartesian product of 64 or 128 or 256 relation literals each with a range over boolean?

Perhaps it makes sense to have a boolean type and a set of type generators?

> > The cardinality of values in the full range of an interval type or
> > of a tuple type or of a relation type could be huger than huge. I don't
> > think that makes much sense.
>
> Most types would be represented as a relational expression. E.g. the type
> consisting of all intervals of positive integers less than 2^32 could be
> declared to the DMBS by inserting the following relational expression and
> relational expression name into the DBMS catalog.
>
> Assuming the type INTEGERS_0-2^32 is already know to the DBMS (say as a
> relational expression over some inbuilt BIT type?), then
> INTEGER_0-2^32_INTERVALS could be defined by
>
> INSERT INTO RE_TYPES ( Type_Name, Type_RE_Defn)
> VALUES ( "INTEGER_0-2^32_INTERVALS"
> , "SELECT i.i as Bound_Lower, j.i as Bound_Upper
> FROM INTEGERS_0-2^32 i, INTEGERS_0-2^32 j
> WHERE i.i >= j.i"
> )

Doesn't seem to match my concept of interval. That's more like a contiguous interval type.

> If a user then does something like say
> SELECT AVG(Bound_Lower)
> FROM INTEGER_0-2^32_INTERVALS
>
> and the DBMS decides it will need to fully generate the type relation to
> compute the result, then I say the DBMS "safety system" (i.e. the time
> estimate from the query compiler) should restrict such a query from
actually
> running (unless the user has the time spare to wait...)

That assumes the cost of the "safety system" is low and tunable to prohibit costly errors while allowing most costly critical queries. A system that allows an error to run for a long time before giving up is not particularly desirable, and neither is a system that allows a critical costly query to run almost until it is finished. Of course, the safety system might end up being some dba killing a process manually.

While I like the idea of having relation literals for the ranges of some types, I don't necessarily want them for all types, and I don't want to automatically reference one through the name of the type. I would like to have a type Employee and a named relation Employee without any prior assumptions about the relation.

> The same "safety system" argument applies, for me, to the <OR> and <NOT>
> operators of D&D's "A" algebra. I would like to see them supported in the
> database language and leave the computational difficulties to the safety
> system and the query estimator.

While I find A interesting in terms of formalizing relational operations as shorthands using minimal operators, I have not thought of any pressing need for A in an actual dbms. Why would you like to see them implemented?

> > The system catalog must represent the name of the type, the subtypes,
the
> > supertypes, the possible representations and the constraints. I assume
we
> > can treat the operations separately.
> >
> > If the type is parameterized, how does the above change? If the type has
an
> > arbitrary number of parameters, how does the above change? For instance,
how
> > does one describe types like tuples and relations?
>
>
> The tuple and relation type generators are surly defined by the DBMS
outside
> of the database.

You do not think the dbms should self-describe its builtin types? Does that not limit the catalog as a vehicle of discovery for users?

> My scheme might define particular, named tuple and relation
> types using e.g.
>
> The binary tuple type
> TUPLE_X:INTEGER-Y:INTEGER
> could be defined as
> SELECT i.i as X, j.i as Y FROM INTEGERS i, INTEGERS j
>
> The relation type
> RELATION_TUPLE_X:INTEGER-Y:INTEGER
> could be defined using a relation valued attribute (if you will excuse the
> crap syntax) as
> TABLE(POWER_SET(
> SELECT i.i as X, j.i as Y FROM INEGERS i, INTEGERS j
> ))
>
> ?!

If the dbms has type generators, I think the catalog must describe them--especially, if the dbms is extensible by adding user-defined type generators.

> > > Operators are again relation constants or views in the catalog. The
> > relation
> > > name can be used as the operator name. A convention such as the
attribute
> > with
> > > either a standard name such as 'result' or as the same name as the
> > operator
> > > could distinguish the operator result from the operands.
> > > Any operators that are functions would have a functional dependence
> > constraint
> > > on their catalog relation. Functions that have properties such as
being
> > > commutive, associative, reflexctive, identity etc would have
corresponding
> > > relcon constraints.
> >
> > Are you suggesting that the system catalog describes operations and
types
> > exactly the same as it describes relations? I am just not satisfied with
> > that. It seems to me there are logical differences among type, operation
and
> > relation.
>
> It's just the information principle. The total information content of the
> database should be represented as relation values.

Yes, I agree about the information principle. The catalog should describe operations and types using relations, but that does not mean the catalog should describe operations and types as if they were relations.

> I'm not saying that there are no logical differences (at a certain level
of
> abstraction), I'm just saying that they can be all represented as
relations,
> so maybe we should.

Hmmm, that's interesting. The preconditions of an operation are constraints on on the parameter attributes and the post conditions of an operation are constraints on the result attribute. I'll think about that some more. What do we do with the parts of operations requiring a turing-equivalent language?

I am still having problems with types though. It just doesn't seem to me that types are relations. In fact, it seems to me that types are not anything like relations.

> > What are the differences between operations that equate to assignment
vs.
> > operations that do not? How does that get represented in the catalog?
> >
> >
> > > So those two seem a lot easier to get a grip on compared to the ideas
> > around
> > > database algebra (as I think you nicely demonstrated ;-)
> >
> > I think the jury is still out on a database algebra.
>
> I didn't know it had gone to court yet ;-)
>
> > It seems clear that the
> > system catalog has to be at least partially defined operationally, but
then
> > again possible representations comprise operations, don't they? So, that
> > probably is not as significant as it might seem.
> >
> >
> > > Type generators? Maybe 'meta programming' has something to say on this
> > one.
> > > Not sure.
> > >
> > > P.S. I've not gone all that far down the database algebra path,
although
> > one
> > > thing does look clear; that it works better if relvar names are
dropped.
> > > Maybe I'll post my ideas here, although as I said I'm not sure that
this
> > > newsgroup is the ideal outlet. Is there a sourceforge.net for logical
> > > models???
> >
> > Drop the names of relations? How does one refer to them without names?
>
> By their tuple type. Obviously that does mean enforcing POOD however.

That seems like a complex way to refer to a relation compared to using a name. Received on Mon Jul 07 2003 - 04:17:33 CEST