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

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:be7h3n$1ckg$1_at_gazette.almaden.ibm.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:o1pNa.287$_T1.36633719_at_mantis.golden.net...
> > I apologize for the length and meandering nature of the following. It
> > represents a train of thought that has to back off a couple of dead-end
> > sidings.
> >
> > I am not sure how a database algebra would affect the catalog.
Representing
> > types, type generators and operations seems like the tricky part to me;
> > although, I have a few ideas germinating. Type generators seem
particularly
> > tricky because they could instantiate a type that changes the known type
of
> > some value already in the database.
>
> Types and Operators look reasonably easy to me. Briefly,
>
> A type is defined by a relation (a relational constant, aka relcon) in the
> catalog with one set of attributes for the components of each possible
> representation of the type, and with one tuple for every value of the
type.
> A subtype is a view over the supertype's relation with a restriction that
> corresponded to the definition by constraint of the subtype, and
optionally an
> extension expression that defines sets of attributes for any possible
> representations unique to the subtype.
> The relation names could be used as the type names. Poss representation
names
> might have to use some attribute name prefix scheme, or some other
metadata
> relation that says which attribute names are part of which possible
> representation. Each set of attributes that are the components of each
poss
> representation would define a candidate key on the relation.
> Further, instead of enumerating all the values of a type in a relation
> literal, types can alternatively be defined by a named relational
expression,
> probably over the relcon(s) of the components of the possible
representation
> of the type.

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

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?

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

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. 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? Received on Sun Jul 06 2003 - 06:37:06 CEST